Deploying your App - Deploy Time

[PascalSenn]

Deploy Time

In containerized applications, you may prefer not to embed secrets in your container image at build time. Doing so could expose these secrets to anyone who gains access to the container image. Instead, you might choose to construct the container with configuration files that contain variable placeholders, replacing these with actual values when you initiate the container.

There are primarily two methods for this approach:

1. Resolve variables upon container startup.
2. Resolve variables when you decide to deploy the app.

Details about resolving variables at runtime (method 1) are covered in the Runtime section. This section will focus on the second method.

Procedure

To replace variables before deploying the application, follow these steps in your release pipeline:

1. Prepare Variables: Checkout the code and run the confix prepare command. This command comunicates with variable providers to read all necessary variables, creating a JSON file that contains just the secret values.

2. Pass Variables to Container: The JSON file needs to be transferred to the running container. This can be achieved by mounting the file into the container, or by using a Kubernetes secret to pass it as an environment variable.

3. Build with Variables: Run the confix build command with the --variables </path/to/json or environment_variable> options before initiating the container. This will substitute variables in your configuration files with their actual values.

In a Kubernetes setup, you can use an init container that has the configuration files mounted to execute the replacement command. Alternatively, you can directly integrate Confix into your Dockerfile.

If the container's source code is inaccessible in the release pipeline, you can also run the prepare command in the release pipeline within inside init Docker container. When you specify the --print options, the command will print the JSON file to the standard output. You can read this output and pass it later to the container as an environment variable.

Pros:

1. Consistent container image across environments: This approach lets you use the same container image for all your environments.
2. Independence from variable providers: The application does not need to have access to the variable providers.
3. Tolerant to provider downtime: The variable providers can be down when you restart or rollback the app.
4. Consistent variables across deployments: You can rollback a deployment and still have the same variables as the last time you deployed the app.

Cons:

1. Increased complexity: You need to prepare the variables before deploying the app, which adds an extra layer of complexity to your release pipeline.

[TimHolzherr]

I am confused by the following two sentences:

In a Kubernetes setup, you can use an init container that has the configuration files mounted to execute the replacement command.

Tolerant to provider downtime: The variable providers can be down when you restart or rollback the app`

Aren't those two contradicting each other? Init containers are always run before the actual container, so when the app restarts its init container will also run again.