Manage Configurations

Configurations are key/value pairs, often used as settings.

tip

Codiac stores configurations as opaque secrets. Configurations are 100% encrypted at rest.

Usage and Options

Use codiac config -h to see all the available options:

Adds a key value pair to the app config

USAGE
  $ codiac config COMMAND

TOPICS
  config settings  Shows the list of clusters.

COMMANDS
  config add     Adds a key value pair to the app config
  config delete  Removes the given keys from the app config
  config deploy  Deploys a given asset to a given cabinet.  Defaults to current version.
  config import  Adds a key value pair to the app config
  config set     Adds a key value pair to the app config
  config view    Shows the values that are explicitly set in the given config

Add a config

Use codiac config set to edit or add a configuration:

codiac config set

The available pre-defined configs are:

• file
• env
• filestore
• footprint
• helm
• annotation
• label
• probing

To use a script to add a config, use the --to-script flag. This runs the command without an interactive prompt:

codiac config set --to-script

tip

Do you have an existing configuration you want to copy over to a new asset? Use pipes!

Edit a config

Use codiac config set to edit or add a configuration:

codiac config set

To use this command in a script, add the --to-script flag. This runs the command without an interactive prompt:

codiac config set --to-script

Copy a config

Use pipes with the codiac config settings get command to copy configs into a different cabinet, environment, or enterprise.

For example, the command to copy the fav-color config at the dev environment level to the qa cabinet (on the my-api asset in the main enterprise) is:

codiac config settings get --enterprise main -a my-api -e dev --setting fav-color | cod config set -a my-api -c qa

tip

Use codiac config setings get --to-script to help you automatically assemble the command arguments.

See Piping configs for more detailed information.

Delete a config

Use codiac config delete to delete a configuration.

codiac config delete

To use this command in a script, add the --to-script flag. This runs the command without an interactive prompt:

codiac config delete --to-script

Piping configs

Pipes let you use the output of one command as the input for another.

tip

Use codiac config setings get --to-script to help you automatically assemble the command arguments.

Example 1: Pipe configs from one env to another

You can use pipes to copy Codiac configs from one environment into another. For example:

1. The following command retrieves all the configs at the environment level for the dev environment:

codiac config settings get -a my-api -e dev -f app-config.json

2. Next, build on that command by using pipes to copy the configs from the dev environment into the qa environment:

codiac config settings get -a my-api -e dev -f app-config.json | cod config set -a my-api -f app/app-config.json -e qa 

Example 2: Pipe configs into a file

You can also pipe configs into a file. This lets you examine and edit the values before you copy them into a new environment.

This command writes the configs for the dev environment into a file named temp-configs.json:

codiac config settings get -a my-api -e dev -f app-config.json > temp-configs.json

1. Open the file temp-configs.json and edit the values. In this example, we change Hometown to Chicago. We also change the user and password to reference the secrets for the qa environment:

   {
     "hometown": "Chicago",
     "db": {
       "server": "mongo.qa.ourcompany.com",
       "name": "growing",
       "user": "#REF|our-secret-store|growdb-qa-user",
       "password": "#REF|our-secret-store|growdb-qa-password"
     }
   }

2. Save and exit the file.

3. Pipe the contents of temp-configs.json into a codiac config set command to copy the configs into the qa environment.:

cat temp-configs.json | codiac config set -a my-api -f app/app-config.json -e qa

4. Refresh the qa cabinet to see the new configs:

codiac config deploy -a my-api -f app-app-config.json -c sprint15

Notes on piping configs

1. The commands codiac config delete and codiac config set only affect config/value pairs. You have to set the destinations (e.g., asset, file, cabinet, etc) on these commands to declare where they will be written, no matter where the piped input came from.

2. TTY User interaction is deactivated when you pipe stdin. The --silent flag is set automatically. This means you must set up your command correctly before you execute it.

3. the --setting argument is multi-use on codiac config delete. It also supports globbing. eg: --setting 'db.*'.

warning

USE LITERAL QUOTATIONS WHEN GLOBBING. Otherwise, your shell may execute the glob in the current working directory before Codiac can interpret it. Your shell may automatically pass a list of local files matching your glob to the Codiac CLI instead of the glob pattern itself.

Dynamic environment configs

Dynamic environment configs let you use a dynamic variable as an environment config. The dynamic variable is set when the container instance is created. Use the #FROM replica syntax in the setting's value to invoke this special behavior.

Dynamic variables

Use the syntax $VARIABLE_NAME to set a variable. For example, the following syntax updates the asset and cabinet variables:

api-url = http://${asset}.${cabinet}.mydomain.com

Available variables:

• asset
• cabinet
• cluster
• enterprise
• environment
• tenant
• version

An example of these variables in use:

tenant: "abc",
enterprise: "main", 
environment: "dev",
cluster: "my-cluster-east-1-eks",
cabinet: "dev-beta",
asset: "our-api",
version: "1.2.3-4"

Example

This example uses a dynamic variable for the HOST_IP environment configuration:

When the container instance is created, this environment config is dynamically set to the host IP address.

Syntax

Use the #FROM replica syntax in the setting's value to invoke this special behavior. For example:

#FROM|replica|HostIP

warning

These options are case-sensitive.

The #FROM|replica syntax supports the following options:

Option	Value	Description
annotations	KEY	The annotations option requires an additional segment, KEY, to declare which label to reference. For example: #FROM|replica|labels|my-category.
hostIP	n/a	The primary IP address of the machine running the container.
k8s.namespace	n/a	The name of the Kubernetes namespace where the container instance is deployed.
labels	KEY	The labels option requires an additional segment, KEY, to declare which label to reference. For example: #FROM|replica|annotations|prometheus.io/port=9153.
name	n/a	The name of the replica.
nodeName	n/a	The name of the machine running the container.
IP	n/a	The primary IP address of the replica.
IPs	n/a	List of all IP addresses assigned to a replica.
serviceAccountName	n/a	The security identity under which the container is being run.