Commands

This command compiles a cluster catalog. This is the main mode of operation for Commodore when managing clusters.

This command will first collect all required components and hierachical configuration and prepare the inventory for Kapitan.

Then, the command will process the compiled inventory, and create secret references in catalog/refs/ for any secret references it finds in the inventory.

After the inventory and all references are in place, Kapitan is called to render the templates as specified by the compiled inventory.

After Kapitan has rendered all templates, any defined postprocessing filters are applied to the output of Kapitan, before the fully processed manifests are copied into the cluster catalog at catalog/manifests/.

This command deletes all the data which is managed by Commodore, listed below.

This command doesn’t check whether any local modifications exist and doesn’t check with the user whether they really want to remove the items listed above.

This command creates a new component repository under dependencies/ in Commodore’s working directory. The component repository is created using a Cookiecutter template which provides a skeleton for writing a new component. The command requires the argument SLUG to match the regular expression ^[a-z][a-z0-9-]+[a-z0-9]$. Optionally, the template can be used to add a component library and postprocessing filter configuration.

The command expects to run in a directory which already holds a Commodore directory structure. The command makes sure to create symlinks for the new component’s classes and creates a new Kapitan target for the component. The command also adds the new component as a dependency in jsonnetfile.json and runs jsonnet-bundler to symlink the new component into vendor/.

The template also provides many meta-files in the component repository, such as the readme and changelog, standardized license, contributing and code of conduct files, a documentation template, and GitHub issue templates and actions configuration.

This command removes a component directory from under dependencies/ in Commodore’s working directory. The command will require confirmation before performing destructive operations, unless it’s passed the --force option.

The command expects to run in a directory which already holds a Commodore directory structure. The command makes sure to remove symlinks for the new component’s classes and deletes the Kapitan target for the component. The command also removes the deleted component as a dependency in jsonnetfile.json and runs jsonnet-bundler to remove the symlink to the deleted component in vendor/.

This command compiles a single component.

This is the main mode of operation for developing new components, as it allows fast iteration while working on a component.

This command will create a fake inventory which mocks out all the infrastructure which a component would expect to be available when it’s included in a cluster’s configuration.

The command takes so called values files which provide custom configuration values for any configuration that could be provided from the hierarchical configuration repositories.

The option --alias (or -a) can be used to compile an instance-aware component with a specific instance.

This command lists all the components defined in parameters.components in the Commodore hierarchy in directory GLOBAL_CONFIG. If provided, the command also takes into account the tenant repo in directory TENANT_CONFIG.

The component takes a repeatable argument -f / --values which allows the user to specify additional files that should be used as classes when rendering the contents of parameters.components.

When providing a tenant repo, users must specify the tenant ID and cluster ID for which the inventory should be rendered in a value class to obtain accurate results. See a sample cluster-info.yaml which can be used for this purpose below.

The command supports both YAML and JSON output.

This command provides linting for Commodore inventory classes.

Currently, the command only lints component specifications. It treats component specifications without explicit version field as errors.

The command takes zero or more paths to files or directories to lint as command line arguments. It silently skips files which aren’t valid YAML, as well as empty files and files containing multi-document YAML streams. All other files are assumed to be Commodore inventory classes.

When linting directories, any hidden files (prefixed with a dot) are ignored. Directories are linted recursively and the same skipping logic as for individual files is applied.

If no errors are found the command exits with return value 0. If any errors are found the command exits with return value 1.