Creating a Docker UAT/Production image

Just a quick question about best practices on creating Docker images for critical environments. As we know in the real world, often times the team/company deploying to internal test is not the same as who is deploying to client test environments and production. There becomes a problem because all app configuration info may not be available when creating the Docker UAT/production image e.g. with Jenkins. And then there is the question about passwords that are stored in app configuration.

So my question is, how “fully configured” should the Docker image be? The way I see it, it is in practice not possible to fully configure the Docker image, but some app passwords etc. must be left out. But then again this slightly defies the purpose of a Docker image?

  • Recommend way to Artisan on Docker
  • Can't acces docker container by IP address
  • Docker: Is it necessary to mount a new partition
  • IdentityServer4: How to load Signing Credential from Cert Store when in Docker
  • Is Docker capable of providing container with gigabit network?
  • How to communicate (network) with Docker at DigitalOcean?
  • Docker: Cannot locate specified Dockerfile error
  • DRY Config for Docker build and App
  • How can I solve “crontab: your UID isn't in the passwd file. bailing out.”?
  • Writing Elasticsearch logs from Docker to an external volume
  • Installing rancher 1.6.2 on centos 7
  • Which Docker base image should be used to install Apps in a container without any additional OS?
  • One Solution collect form web for “Creating a Docker UAT/Production image”

    how “fully configured” should the Docker image be? The way I see it, it is in practice not possible to fully configure the Docker image, but some app passwords etc. must be left out. But then again this slightly defies the purpose of a Docker image?

    There will always be tradeoffs between convenience, security, and flexibility.
    An image that works with zero runtime configuration is very convenient to run but not very flexible and sensitive config like passwords will be exposed.
    An image that takes all configuration at runtime is very flexible and doesn’t expose sensitive info, but can be inconvenient to use if default values aren’t provided. If a user doesn’t know some values they may not be able to use the image at all.

    Sensitive info like passwords usually land on the runtime side when deciding what configuration to bake into images and what to require at runtime. However, this isn’t always the case. As an example, you may want to build test images with zero runtime configuration that only point to test environments. Everyone has access to test environment credentials anyways, zero configuration is more convenient for testers, and no one can accidentally run a build against the wrong database.

    For configuration other than credentials (e.g. app properties, loglevel, logfile location) the organizational structure and team dynamics may dictate how much configuration you bake in. In a devops environment making changes and building a new image may be painless. In this case it makes sense to bake in as much configuration as you want to. If ops and development are separate it may take days to make minor changes to the image. In this case it makes sense to allow more runtime configuration.

    Back to the original question, I’m personally in favor of choosing reasonable defaults for everything except credentials and allowing runtime overrides only as needed (convention with reluctant configuration). Runtime configuration is convenient for ops, but it can make tracking down issues difficult for the development team.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.