Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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?

like image 464
arun Kaliappan Avatar asked Feb 21 '18 19:02

arun Kaliappan


People also ask

Which of the following is a recommended practice for building Docker images?

Most docker images use a base image of some sort by specifying the FROM command in the Dockerfile. As a best practice, we should always pull images from trusted sources. Docker images are no different from any other software applications.

What is Docker image promotion?

Docker Image Promotion is the process of promoting Docker Images between registries to ensure that only approved and verified images are used in the right environments, such as production. In ProGet, images can be promoted from one registry to another and tracked throughout the process.

Should you use the same Dockerfile for Dev staging and production builds?

In fact, they should not be. You don't need testing dependencies or direct access. They should be as similar as possible, differing only in the environment variables provided to each. Automated tests are executed on staging, but they should not require the setup to be different from production.


1 Answers

You can promote an image from one docker image repository to another by retagging your image and pushing:

docker build -t my-test .
docker tag my-test your-image-repository-dev/test:10
docker login "your-image-repository-url"
docker push your-image-repository-dev/test:10
# ... deploy/test your image in dev
docker pull your-image-repository-dev/test:10
docker tag your-image-repository-dev/test:10 \
           your-image-repository-qa/test:10
docker push your-image-repository-qa/test:10

You will then have the same image in a QA docker image repository. This makes sense for images that have passed a base level of unit/functional/user acceptance tests which are distinct from images that have not! The key concept here being the timing at which you retag and push your image. Further, specifying image pull credentials for each docker image repository can help you limit the images that can actually make it to specific environments.

An alternative to the strategy above is that, you might not have separate docker image repositories, and may opt for changing the image name instead of the repository. In this case, you might do the following.

docker build -t my-test .
docker tag my-test your-image-repository/test:10
docker login "your-image-repository-url"
docker push your-image-repository/test:10
# ... deploy/test your image in dev
docker pull your-image-repository/test:10
docker tag your-image-repository/test:10 \
           your-image-repository/test-qa:10
docker push your-image-repository/test-qa:10
like image 138
rjminchuk Avatar answered Oct 14 '22 13:10

rjminchuk