Application Configuration Changes Across Different Environments

In the last section, we created containers based on the same Docker image in each environment. A microservice will have configuration settings that likely need to change per environment, like feature flags to dynamically control service capabilities (turn on or off product recommendations), API keys for third-party services, or connection strings to dependent services like a web front end, database, or a logging service. These configuration settings can be changed per environment in a number of ways:

• Use a Docker volume-mounted configuration file (for example, myservice.conf) that is deployed along with the container and is unique to each environment, similar to the example in chapter 2.

• Use environment variables to set per-environment configuration settings, as discussed in chapter 4.

• Use tools like Puppet and Chef, which both include ways to set up per-environment configuration settings.

• Use a dynamic configuration service like Apache Zookeeper, or HashiCorp’s Consul, which provide APIs to store and retrieve configuration information. Consul provides both an API to retrieve configuration and a DNS lookup service. The DNS service enables you to have a set URI to something like a logging server at http://teamlog, which can stay the same across environments, but the DNS resolution service would resolve the URI to the appropriate address per environment, for example, http://dev.server01/teamlog.

• For secrets, like passwords or API keys, you can use Azure’s Key Vault service or HashiCorp’s Vault service to store and retrieve secrets.

Let’s now take a deeper look at each stage in the continuous delivery process.