Manage Configurations

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

tip

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

Web

Add a config

tip

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

1. Go to Asset Configuration.

2. Select the asset you want to configure.

3. Click + to add the configuration.

4. Add a value, secret, volume, or resource footprint.

5. Click Save.

This example adds a key:value pair of tree: spruce:

Edit a config

1. Go to Asset Configuration.

2. Select the asset with the configuration you want to edit.

3. Click > to expand the configuration you want to edit.

4. Edit the configuration.

5. Click Save.

This example changes the key/value pair from tree:spruce to tree:birch:

Copy a config

Use the following process to copy a config into a different cabinet, environment, or enterprise:

1. Go to Asset Configuration.

2. Select the asset with the configuration you want to copy.

3. Grab the configuration you want to copy. Drag it in to its destination.

This example copies the key/value pair tree:birch from the enterprise Main to the environment TODO-DEMO:

Delete a config

1. Go to Asset Configuration.

2. Select the asset with the configuration you want to delete.

3. Click : Delete.

This example deletes the key/value pair tree:birch from the enterprise Main.

CLI

Add 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

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

warning

This section is out of date and may need revision.

Interactively

cod config delete

Without the need for prompts

cod config delete --asset my-api --file app/app-config.json --enviro dev \
  --setting hometown --setting favorite-color --setting db.username --setting db.secret --setting db.name --setting db.server

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.

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

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