Module Concept - stefanprodan/timoni

A module in Timoni, an opinionated structure for deploying applications to Kubernetes, is a reusable code block that can be invoked multiple times during the execution of the calling module. It is the equivalent of a Helm chart or a Terraform module. Timoni modules are distributed as OCI artifacts and can be stored in container registries.

A module contains a set of CUE definitions and constraints organized into a CUE module. It accepts a set of values supplied by the user as values.cue files and outputs a set of Kubernetes objects that Timoni deploys on Kubernetes. The module structure includes a timoni.cue entry point, templates for Kubernetes objects, and values.cue for placeholder values.

Timoni relies on cuelang’s type safety, code generation, and data validation features to offer a better experience of creating, packaging, and delivering apps to Kubernetes. It uses input variables to accept values from the calling module, output values to return results to the calling module, and resources to define one or more infrastructure objects that the module will manage.

Modules can be nested, with nested modules being a reference to invoke another module from the current module. Nested modules can be located externally and are referred to as “child modules”, or embedded inside the current workspace and are referred to as “submodules”. However, nesting modules should be done with caution to limit introducing errors.

Timoni modules can be built, pushed, pulled, and listed using the timoni mod commands. For example, timoni mod init <module-name> initializes a new Timoni module, timoni mod push <path/to/module> oci://<module-url> -v <semver> pushes a Timoni module to a container registry, and timoni mod pull oci://<module-url> -v <semver> -o <path/to/module> pulls a Timoni module from a container registry.

To learn more about Timoni modules, please read the documentation at https://timoni.sh/docs.

Sources: