6 ms·
Tagging Docker images for fun and profit
- techntoke 6y agoWhy not just use labels? How does labeling by date help improve order in the registry?
- stepbeek 6y agoIn all honesty I've never used labels before - thanks!
- NegativeLatency 6y ago> While this doesn’t give us great granularity in terms of order of changes within a single day Use hours, minutes and seconds?
- stepbeek 6y agoI like being able to use the image in later pipeline steps without having to pass a variable around. This would be tough to do with time, but it's easy to do with date since we only really run those pipeline during work hours.
- theamk 6y agoDon't you need partial SHA anyway? This needs a variable. And if you have a git checkout around, you can use git commit timestamp - time up to seconds and does not need anything except the source tree.
- miked85 6y agoThis will result in using the same tag for all builds that day - which defeats the purpose of a unique version to a large degree If you are planning on testing or deploying a specific version.
- Spivak 6y agoI think you’re looking for manifest annotations. https://github.com/opencontainers/image-spec/blob/master/specs-go/v1/annotations.go https://github.com/opencontainers/image-spec/blob/master/spe... Docker considers it experimental but buildah doesn’t. https://docs.docker.com/engine/reference/commandline/manifest_annotate/ https://docs.docker.com/engine/reference/commandline/manifes... https://github.com/containers/buildah/blob/master/docs/buildah-manifest-annotate.md https://github.com/containers/buildah/blob/master/docs/build...
- kube-system 6y agoIn GitLab CI, we solve this by using the pipeline number in the tag. They're always in order, and it is available as a variable anywhere in the pipeline.
- GordonS 6y agoI do the same thing with Azure DevOps, as pipelines there also have an incrementing integer ID
- stepbeek 6y agoNeat! We're using gitlab too and I never thought about this.
- kube-system 6y agoIt's $CI_PIPELINE_ID if you want to try it out.
- cytzol 6y agoI do this as well — "Upgrade from image b1257 to b1262". As a bonus, you can tell every tag that doesn't fit the b-then-a-build-number naming convention hasn't come from CI.
- oweiler 6y agoWe use `git rev-list --count HEAD` on master, which basically gives you the number of commits.
- 6y ago
- stevebmark 6y ago> It’s enabled us to have more confidence that our dev environments match production How does Docker help you know your production code is like your development code? _Maybe_ for the code itself, but I highly doubt it, because you probably have different build targets for dev and production, different ports, networking, environment variables, asset serving, debugging, etc. And certainly the docker-compose, maybe Swarm, setup you run locally looks nothing like production? And of course your databases and other services are set up completely different locally.
- Spivak 6y agoBecause the sandboxing various container stacks provide create a much clearer line of demarcation between what is the responsibility of your ops team and your developers. It makes it much harder to accidentally depend on the state of the world. * There are two networking stacks. Developers only see and care about the "inner" stack while the ops team is free to do anything to the "outer" or real network. Devs never see that the ports are actually different in prod. * All the "environment" has to be passed explicitly. You can't accidentally depend on variables, files, programs, libraries, that just happen to be on the host system. Simultaneously, the ops team is now free to configure and manage or change the host system in any way they see fit. * Devs only care that they're deploying to a swarm not any of the details of how that swarm exists in prod. * Devs see shared storage just appear in their containers. To them it doesn't matter in the slightest that it comes from NFS, Gluster or Ceph. * Devs just see traffic hit their app. They don't know or care anything about our LB or caching setup. * Logs and metrics are sent to magic addresses and names on the inner network that map to the real vms outside. * Same with the DB, Redis, Memcache, Queues, etc..
- muxator 6y ago> * devs see shared storage just appear in their containers. To them it doesn't matter in the slightest that it comes from NFS, Gluster or Ceph. > devs just see traffic hit their app. They don't know or care anything about our LB or caching setup. > [...] > * Same with the DB, Redis, Memcache, Queues, etc... I am a bit scared by these devs only caring about themselves
- remram 6y agoThis seems like another group standing up against semver. Nothing in that post is specific to Docker. Also Git provides a `git describe` command, that builds a short identifier including a incrementing number and the commit hash (as well as the last tag). It's standard enough and used by a lot of people (e.g. Linux distros). It has the benefit of being instantly parsable by Git. What's wrong with that?
- raghava 6y agoI have just used calver (https://calver.org/ https://calver.org/) to keep it simple - and I use the date[ddmmyyyy]hour,min,second stamps of build time as a marker in the version. I have had to deal with the build basically being a recipe of taking multiple ingredients (libs, apps - each with their own lifecycles) and putting'em together in one image to get stuff running. The image version in my case is a tracker of the last-known-good-set (of various ingredients) - as validated by the quick, pre-build tests. I haven't had any major problems till now; may be I am just lucky to not have encountered the hassles w.r.t calver till now. I stumbled upon one similar approach too, recently. https://worklifenotes.com/2020/02/27/automatic-version-increments-with-reliza-hub-2-strategies/ https://worklifenotes.com/2020/02/27/automatic-version-incre...