Continuous delivery is difficult, but if your applications are containerized with Docker you’re moving in the right direction to make things easier! Containers provide a ton of flexibility and portability, but they can become a nightmare once you realize the pain of container management. One thing to make it easier is to have a standard container tagging strategy to provide common assumptions and vernacular amongst the team.
Do I Need a Better Tagging Strategy?
You might want to rethink your Docker Image tagging strategy if you don’t immediately know the answer to the following questions:
- “What git commit hash of our app is currently running in production?”
- “Which container version in our registry is currently running in production?”
Strategy: Release Candidate Lifecycle Tagging
The tagging method I find most attractive is what I call “Release Candidate Lifecycle Tagging”. The tag values should follow a flavor of release candidate terminology along the delivery pipeline similar to:
| Build Stage | Tag Value | Development Stage |
|---|---|---|
| Initial Build |
|
“Alpha” |
| Passed Tests (Contract, Integration, Service) |
|
“Release Candidate” |
| Deployed to Production + Smoke Tested |
|
“GA” (General Availability) |
What it Looks like in a Build Pipeline:
In the following example of a release of the app “app”, the current git checkout sha hash is “ff613f”. Initially building the Docker Image with the git sha hash is a pivotal piece that allows teams to know where/how to checkout the application for local or remote debugging of the exact version of the application.
Taking it Further
Post-production Tags
With canary or blue/green deployments, additional tagging stages could be added incrementally to not only reflect that containers have made it to production, but that they reached levels of validity or traffic based performance metrics.
Retiring Images
Once an app image has been replaced by it’s subsequently upgraded version, the previous image needs to remain in the docker registry for an arbitrary amount of time in case a rollback is required. This can be accomplished by adding another tag after the image is retired like “retired-<RETIRED_DATE>”. Then, a reaping processes could take advantage of this new tag and only remove imagess that are X days old.
Credit
I want to give a shout out to Daniel Nephin, as his detailed and explanatory Github comments and issue discussions have led me to resolving many issues around Docker and container strategy.
Parker Gordon | Software Engineering 