What is the best way to maintain Images for different environments and why?

Option : 1 Create diff images for the specific environment dev, stg, prod. we have to tell Jenkin job for which environment we are building the image and spring boot will load the specific configuration files. advantages : Environment specif images.
disadvantages : Every environment will have diff images so we have to build it everytime.

Option : 2 Build 1 image, externalize the config file. While building the image create a shared/mount path place an appropriate config file. While initialization load the config file. advantages: One image can be used by all the environment. disadvantages : Custom Configuration handling. Need coordination between 2 teams.

Let me know if there are other options and whats the advantages and disadvantages above approach or any other approach are present.

CodePudding user response：

Build once and deploy anywhere is considered as the fundamental principles of the continuous delivery (Google it for its advantages). So I would build the same image for all environments . And when running the image , it needs to have some ways to allow configuring these configurations based on the environment.

In term of docker , it allows to configure the environment variables when running a container (e.g see this in case of docker-compose)

In term of spring-boot, the OS environment variables will override the application properties in the app.

CodePudding user response：

When designing your images, split the filesystem and environment into 3 pieces.

1. Binaries, runtime, libraries, code needed to run the application. This belongs in your image.
2. Configurations and secrets that will differ for different users of the image. These belong in configuration files and environment variables that are injected at runtime (either as a bind mount, docker-compose.yml env vars, k8s config map, etc).
3. Data. This should be mounted as a volume, or in an external database accessed with a configuration/secret.

This keeps with the 12 factor design and enables portability, easier testing, and less risk with deploying something into production that is different from what was tested in CI.