- Module - App definition containing Kubernetes CUE templates and configuration schema, distributed as OCI artifacts.
- Instance - App instantiation referencing the module and workloads deployed on a Kubernetes cluster.
- Bundle - App composition bundling multiple modules and configurations into a deployable unit.
- Artifact - Packaging format used for distributing modules and bundles to container registries.
Module
A Timoni module contains a set of CUE definitions and constraints organized into a CUE module with an opinionated structure. A module accepts a set of values supplied by users, and outputs a set of Kubernetes objects that Timoni deploys on Kubernetes clusters. Commands for working with local modules:timoni mod init <module-name>timoni mod vet <path/to/module>timoni build <name> <path/to/module> -n <namespace>timoni apply <name> <path/to/module> -f <path/to/values.cue> --dry-run --diff
timoni mod vendor k8s --version latesttimoni mod vendor crds -f <path/to/crds.yaml>
Instance
A Timoni instance represent a module instantiation on a Kubernetes cluster. A module can be installed multiple times on a cluster by giving its instances unique names per namespace. When instantiating a module, users can supply their ownvalues.cue
that gets merged with the defaults included in the module:
timoni install <name> oci://<module-url> -v <semver> -n <namespace>timoni upgrade <name> oci://<module-url> -v <semver> -f <path/to/values.cue>timoni uninstall <name> -n <namespace>timoni list -n <namespace>timoni inspect [module|values|resources] <name> -n <namespace>timoni status <name> -n <namespace>
install and upgrade commands are aliases of timoni apply.
To apply the Kubernetes resources belonging to a module instance,
Timoni uses Kubernetes server-side apply and
Flux’s drift detection.
The apply command validates all resources with a dry-run apply,
and reconciles only the ones with changes to the cluster state.
Timoni’s garbage collector keeps track of the applied resources
and prunes the Kubernetes objects that were previously applied
but are missing from the current revision.
On upgrade, Timoni records the new revision as pending in the instance
storage before touching the cluster, and marks it as applied only after
the reconciliation has succeeded. If an upgrade is interrupted, the next
run resumes from the recorded state, and timoni delete cleans up both revisions.
After an installation or upgrade, Timoni waits for the
applied resources to be fully reconciled by checking the ready status
of deployments, jobs, services, ingresses, and Kubernetes custom resources.
Bundle
Timoni bundles offer a declarative way of managing the lifecycle of applications and their infra dependencies. A Timoni bundle is a CUE file for defining a group of instances together with their values and module references:timoni bundle apply -f bundle.cue --runtime runtime.cue --difftimoni bundle build -f bundle.cue -f bundle_extras.cuetimoni bundle delete -f bundle.cuetimoni bundle vet -f bundle.cue
Artifact
Timoni modules and bundles are distributed to container registries as Open Container Initiative (OCI) artifacts. The OCI artifacts produced by Timoni have the following media types:- Image media type
application/vnd.oci.image.manifest.v1+json - Config media type
application/vnd.timoni.config.v1+json - Layer media type
application/vnd.timoni.content.v1.tar+gzip
timoni registry login <registy-host> -u <user> -p <password>timoni registry logout <registy-host>
timoni mod push <path/to/module> oci://<module-url> -v <semver> --signtimoni mod pull oci://<module-url> -v <semver> -o <path/to/module> --verifytimoni mod list oci://<module-url>
timoni artifact push oci://<artifact-url> -t <tag> -f <path/to/dir>timoni artifact pull oci://<artifact-url> -o <path/to/dir>timoni artifact list oci://<artifact-url>timoni artifact tag oci://<artifact-url>:<tag> -t <new-tag>