Hey everyone! I've just set up my first GitHub action that pushes Docker images to the packages section of my repo. I'm managing my Docker stacks using Portainer on an internal network and I'm aiming to trigger updates securely with webhooks from GitHub. My question is about tagging Docker images effectively. I need to differentiate between my development and production environments in Portainer, but I'm unsure of the best tagging strategy to use. Right now, my images are stored in GitHub packages. Any suggestions on how to manage these tags so my stacks can accurately pull the right images? By the way, I'm using Docker Compose for structuring these stacks. Thanks in advance!
2 Answers
If you're looking for resources to help with your learning journey, check out this GitHub repository: [DevOps-Learn-By-Doing](https://github.com/dth99/DevOps-Learn-By-Doing). It's a great collection of free labs and projects that promote learning by actually doing things. It might be useful for your setup!
When tagging Docker images, consider these strategies from least to most effective:
1. **:latest**: This is super easy to use but can lead to lots of issues if you're not careful.
2. **Git SHA**: This provides a unique identifier but isn’t very human-readable.
3. **Timestamp**: Use a second-level timestamp (like `20250607161523`), which gives you precision.
4. **Semantic Versioning (SemVer)**: This is your best bet! It clearly indicates versions (like v1.2.3) and helps you manage updates without confusion.
Basically, you want to keep track of which versions your staging and production environments are running, e.g., staging on v3.12.7 and production on v3.12.5. This helps ensure smooth deployments without unexpected updates.
Totally agree! Avoid using :latest whenever you can—it just opens up a can of worms. We've had so many issues when someone unintentionally used an updated image because it was tagged with :latest.
Also, implementing Semantic Versioning is much easier if you're already versioning your code with tools like Maven or npm.
Exactly! I would always recommend building a singular image for both environments. The idea is to keep deployment consistent across staging and production.