ments. These images then combine all configuration information for specific envi‐ ronments and can be versioned like any other container image. Creating such a data image is trivial, as it is a simple container image that contains only data. The challenge is the linking step during startup. We can use various approaches, depending on the platform. Before looking at Kubernetes, let’s go one step back and consider the vanilla Docker case. In Docker, it is possible for a container to expose a  volume  with data from the container. With a  VOLUME  directive in a Dockerfile, you can specify a directory that can be shared later. During startup, the content of this directory within the container is copied over to this shared directory. As shown in Figure 20-1, this volume linking is an excellent way to share configuration information from a dedicated configuration container with another application container. Let’s have a look at an example. For the development environment, we create a Docker image that holds the developer configuration and creates a volume  /config . We can create such an image with  Dockerfile-config  as in Example 20-1. Figure 20-1. Immutable configuration with Docker volume Example 20-1. Dockerfile for a configuration image Add the specified property Create volume and copy property into it We now create the image itself and the Docker container with the Docker CLI in Example 20-2. FROM scratch ADD app-dev.properties /config/app.properties VOLUME /config 158  |  Chapter 20: Immutable Configuration Docker Volumes