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?

  • Multi host Container communication with kubernetes and flannel
  • How can my docker harddrive be bigger than the hosts?
  • Docker 'WARNING: permission denied' on ubuntu
  • Mirroring private docker registry
  • Dockerize Spring Boot Java app with Kafka, Zookeeper, and MongoDB [closed]
  • docker postgres with initial data is not persisted over commits
  • nginx default_site doesn't appear to be working
  • How to logging in Amazon Web Service ( AWS )?
  • How to make docker fail or check version exists
  • Escaping Docker attach one started from bash script
  • pod routes don't match IP
  • Not dockerized nginx load balancing to gitlab dockerized
  • 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.