DevOps with OpenShift

Chapter 5. Configuration Management

In software engineering it is recommended to separate dynamic configuration from static runtime software. This allows developers and operations engineers to change the configuration without having to rebuild the runtime.

In OpenShift it is recommended to only have runtime software packaged into a container image and stored in the registry. Configuration is then injected into the image at runtime during the initialization stage. A substantial benefit of this approach is that the runtime image can be built once while the configuration can change as the application is promoted between different environments (e.g., dev to test to production).

OpenShift has a number of mechanisms by which configuration can be added to a running pod:

• Secrets

• Configuration maps

• Environment variables

• Downward API

• Layered builds

In the following sections we will go through the pros and cons of each mechanism.

Secrets

As the name suggests, secrets are a mechanism by which sensitive information (e.g., usernames/passwords/certificates) can be added to pods.

Secret Creation

To create a secret, use the oc secret command:

$ oc secret new test-secret cert.pem

secret/test-secret

With multiple files contained in the secret:

$ oc secret new ssl-secret keys=key.pem certs=cert.pem

secret/ssl-secret

Note

When creating secrets with multiple fields, the keys used to identify the individual files need to correspond to the following convention rfc1035/rfc1123 subdomain ...