Commands

Catalog Compile

commodore catalog compile CLUSTER

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/.

Catalog Clean

commodore catalog clean

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

  • the downloaded and potentially modified catalog in catalog/

  • all the downloaded and potentially modified components in dependencies/

  • the generated inventory in inventory/

  • Kapitan’s output in compiled/

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.

Component New

commodore component new SLUG

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.

Component Delete

commodore component delete COMPONENT_NAME

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/.

Component Compile

commodore component compile PATH

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.

Inventory Components

commodore inventory components GLOBAL_CONFIG [TENANT_CONFIG]

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 command doesn’t currently support cloning either the global or tenant repository from a Git repo URL.

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.

cluster-info.yaml
parameters:
  cluster:
    name: c-cluster-id-1234 (1)
    tenant: t-tenant-id-1234 (2)
1 Specify the cluster ID for which the inventory should be rendered
2 Specify the tenant ID. This must match the tenant ID associated with the provided tenant repo for accurate results.

The command supports both YAML and JSON output.

Inventory Lint

commodore inventory lint [PATH]...

This command provides linting for Commodore inventory classes.

Currently, the command can lint component specifications and deprecated parameters.

The component specification linter treats component specifications without explicit version field as errors.

The deprecated parameter linter treats any occurrences of the reclass parameters ${customer:name}, ${cloud:provider}, ${cloud:region} and ${cluster:dist} 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.

Login

commodore login

This command allows you to authenticate yourself to Lieutenant using OIDC, if OIDC integrations is enabled for your Lieutenant instance.

The command will open a web-browser where you can authenticate yourself to the configured IdP. Commodore will use the returned token for future commands if no other token is explicitly provided.

Fetch Token

commodore fetch-token

This command prints the OIDC token for the specified Lieutenant API to stdout. If necessary, the command will call commodore login internally to fetch a valid token for the provided API URL.

Package New

commodore package new SLUG

This command creates a new config package repository. If not specified explicitly, the command will create the new package under inventory/classes/ in Commodore’s working directory. The package repository is created using a Cookiecutter template which provides a skeleton for writing a new package. The command requires the argument SLUG to match the regular expression ^[a-z][a-z0-9-]+[a-z0-9]$. Additionally, the command prevents users from creating packages using reserved names or prefixes.

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.

Package Compile

package compile PATH TEST_CLASS

This command allows user to configure configuration packages standalone.

The command takes two command line arguments, the path to the package and the test class in the package to compile.

By default, the command creates a temp directory in /tmp which is used as the working directory for compiling the package. To keep an automatically created temp directory for subsequent compilations, users can specify --keep-dir to skip deleting the temp directory created by the command. Users can specify a custom temp directory location with flag --tmp-dir. If the path provided with --tmp-dir doesn’t exist, Commodore will create it as a directory.