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 container 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|
|Passed Tests (Contract, Integration, Service)||
|Deployed to Production + Smoke Tests Passed||
||“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 container 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
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.
Once an app container has been replaced by it’s subsequently upgraded version, the previous container 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 container is retired like “retired-<RETIRED_DATE>”. Then, a reaping processes could take advantage of this new tag and only remove containers that are X days old.
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.