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?

  • Docker does not want to install vim into my container image
  • Atom editor PHP link from Docker container
  • Why is /etc/hosts file empty in my docker container?
  • Docker FTP Server Container Create Accessible Sub-directories
  • Springboot client unable register with Eureka using Docker container id
  • Fedora 22: ERROR: No module named '_rpmb' while building docker
  • from an ec2 instance spin up another ec2 instance and push a csv file on it
  • Mount non-existing host directory into non-root container
  • When and when not to use tty in Docker Remote API
  • How to run a full laravel on kubernetes?
  • Using im2rec in MXnet to create dataset with png images
  • Fail building a Docker container early with bad list of packages for yum install
  • 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.