'Best practices to promote docker images across dev,qa,uat and production

Our application is containerized and using docker swarm as an orchestrator. I wanted to understand how do we promote docker images from dev, qa, uat and to production. For example, if I have an image created in dev as test:10 (10 is the build number generated by jenkins). How can I promote the same image to qa, uat and production? We are currently using NEXUS as a docker repository. What I don't understand is how will I pull the exact image which is being used in the dev environment. Can anyone help with this?

dockernexuscontinuous-deploymentdocker-imageswarm


Solution 1:[1]

One approach to this problem is to use a CI/CD tool such as Jenkins or even some CI/CD bash scripts and have a sort of tagging strategy. As you may know, you can tag the same image differently. For instance, you can have a built image ID of 0000 and tag that many times as follow:

Day 1:
| TAG         | IMAGE ID |
| test:10     | 00000000 |
| test:dev-latest | 00000001 |
| test:qa-latest  | 00000001 |
| test:prod-latest| 00000001 |    

Day 2:
| TAG             | IMAGE ID |
| test:10         | 00000000 |
| test:11         | 00000001 |
| test:dev-latest | 00000001 |
| test:qa-latest  | 00000001 |
| test:prod-latest| 00000001 |

And your orchestrator can always wait for the new images to be tagged. This method theoretically is useful. However, based on your container orchestrator specific feature you can slightly refine this approach to use those specific features. For instance, image pulling policies, or rollout and rollback feature, features to implement blue/green strategy, etc.

Solution 2:[2]

The key is to use some form of metadata in your image tags to indicate which step of your deploy process an image corresponds to. There are many potential ways to do this, but maybe look at SemVer first, as it is a well documented and fiarly widely used option.

https://semver.org/

The main thing to pay attention to in semver is the use of a - marker in a version, which indicates that something is a "pre-release" version.

With this in mind, it's easy to separate production and non-production images:

  • Production version: nginx:1.2.3
  • Non-production version: nginx:1.2.3-10

From there, you can break down your non-production versions further if needed through the use of "dot-separated pre-release identifiers"

  • dev: nginx:1.2.3-dev.10
  • qa: nginx:1.2.3-qa.10
  • uat nginx:1.2.3-uat.10

There's other tagging methods you could use, but SemVer is well documented, widespread, and solves the problem.

Solution 3:[3]

A best practice is to have a separate container repository for each environment. Docker pull onto the build/release agent may not be required with Azure Container Registry. I have written a article on this promoting-container-images-to-production-using-azure-devops

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Maziar Aboualizadehbehbahani
Solution 2 Swiss
Solution 3 samdinesh

Related Questions