How to Version Docker Images When Updating for Security Patches?
Asked by
CuriousCoder82
Hey all! We've just switched our infrastructure to utilize Kubernetes for production and staging environments. We follow trunk-based development and use semantic versioning for our API releases. Now that staging is added, I'm needing to implement `-rc` tags for release candidates. Here's the thing: we currently tag our Docker images with the same version as our app, like 1.1.0. However, if a security update comes in for the OS, I want to update the Docker image without changing the app version. I considered using build metadata, but I've read that doesn't help in indicating a newer image.
For example, if we have 1.1.0+20251020, it won't show up as newer than just 1.1.0 according to ArgoCD's image updater. How do you all handle this type of situation? Do you have to force a new app version every time there's an OS update? It seems inefficient. Should I just switch to a custom tag like 1.0.0-osbuild.20251020 or 1.1.0-rc-osbuild.20251020 and leverage regex in ArgoCD for managing images? I'm curious about the practices other companies adopt for this issue, especially since we have a fully automated CI/CD process. Thanks for any insights!
Answers
In our company, we follow a pattern like ---. The candidate types help us classify our releases and streamline the build process. This way, there's little confusion, as each tag provides extensive detail on the version and environment it was built for.
Reply to this answer
In our setup, we treat the Docker image and app versions as closely linked. If we make any changes—be it a security update or new features—it mandates a new version number for the app. We always ensure our versioning reflects any change in the system appropriately.
Reply to this answer
I suggest focusing on versioning the build artifacts rather than the app itself. Since the container image is your primary artifact, any time it changes (like a different base image), you should increment the version due to the different image hash. This keeps everything tighter and reduces confusion.
Reply to this answer
Honestly, you might be overcomplicating things! Automated versioning isn't a hassle and doesn’t have to be intuitive. Whether you decide to add timestamps to your tags or bump the minor version, the main goal is to keep the process smooth.
Reply to this answer
We have a pretty straightforward approach: any change—whether it's in the Dockerfile or tests—results in a git tag that bumps the app's version. In my experience, any modification should be ready for production right away, but I get that with rapid changes, it can become tricky.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions