Docker Community Forums

Share and learn in the Docker community.

How to differentiate test build and production build

Hi All,

We have created two private containers on docker hub.(test and production).

We have tag test container to production container.It is working fine,but we want build difference while releasing production application container from test application container .

For example,
In test application container printing message “test_version_latest”

after tag test container to production container ,it also printing same as test container printing “test_version_latest”
But we want to print “production_version_latest” after tag to production

Please suggest any way to do that

I think there is a bit of confusion in your wording, so I’ll clear that up to start. A Docker image is an artifact of a build which has everything needed in order to run your application. A container is a running instance of your image. So it seems you have created two private images on Docker Hub, but you want to only have a single image, which deploys to both test and production, but has different versions embedded in them.

You can use environment variables to set some of this data. So the environment variable could be ENV=test or ENV=production. Then for the version, that would be something generated at build time. Then, when you concatenate them together you get test_version_latest and production_version_latest, as you want.

Alternatively, I figure there are likely other identifiers that denote you are in a test or production environment, so you could use those rather than using an environment variable to embed the environment in your application. Of course I don’t know all of your situation, but just throwing it out there that you might be adding duplication information this way.

It is typically an anti-pattern to create a separate docker IMAGE per environment (test and prod in your case). Docker images are considered to be immutable. You use tags to differentiate version (1.0.0, 1.0.1, 1.1.0, 1.1.1, or some other prototype if you don’t like semvar for some reason). The normal development life-cycle is that you build your image and test it in your lower environment. When you are happy that everything works as expected, you make that SAME image available to your higher environment(s), you definitely do not rebuild it or re-tag it. It is the same artefact, the same one you tested earlier, you want to use this one image across all your environments (it’s the most often quoted reason for NOT using a tag of ‘latest’).

Of course you MAY want some aspect of the RUN-TIME behaviour of the CONTAINER that is launched for your one image to be dynamic, and there are a lot of ways that you can do that (from env vars, volume mounts, using a start-up script as your ENTRYPOINT, and so on). But all that is to do with RUN not BUILD. Build is the stage where the image is created, RUN is when you create a container to execute its functionality.