CODEWITHSUNDEEP
dockerdocker-registrydocker-stack
FishingIsLife
FishingIsLife

Reputation: 2372

Docker image versioning with docker stack

I've setup a staging and a production server. The flow is as follows. I develop and push my new image to the staging registry. There the code is tested and if everything fits I want to push the image to the production server. I also want to use versioning. I thought about incrementing the image tag.( Not just ass latest) I deploy my application with docker stack and a compose file.

Now I want to ask about a best practice.

Example: current image: xyz:0.1 new image: xyz:0.2

In my compose file I referance the image xyz:auto_lastest_version_here

I want to be able to see the version string and not just the latest Tag. Is there already a mechanism or a way to reduce an update to docker pull - > pull the latest version available stack deploy ... to update the specific container.

EDIT: I guess I can write a script where I extract the latest Tag from the images and refer the this by using an env var in my compose file. I just thought there might be an easier way or standard way provided by docker.

Upvotes: 0

Views: 797

Answers (1)

Steve Bennett
Steve Bennett

Reputation: 61

Image repository names and tags are just strings attached to a blob which is the actual image data. Docker and the docker registry don't really have a concept of the most recent version of a blob -- the ":latest" tag doesn't even have internal significance - it's just a string which is used by default when building, and there's nothing preventing you from tagging an older image as :latest.

Fortunately, you can tag an image with multiple tags, and that provides a reasonable solution. For me, I tag with a string identifying the version I want on my production server, like ":live" or ":production", in addition to tagging with the actual version number. Thus, lets say you have images myimage:1.0.0, myimage:1.0.1, and myimage:1.1.0, you could run:

docker tag "myimage:1.1.0" "myimage:production"

...to add a production tag to it. The stack file you deploy on the production server would always then refer to myimage:production.

The real advantage to that is that if users start complaining about problems when you switch to 1.1.0, you can simply tag myimage:1.0.1 as myimage:production and redeploy, and it would switch back to the older version.

Not sure if this is the "best" practice, but it's the one I use.

Upvotes: 2

Related Questions