Labelling problems with Docker automated builds
Update: there is now a solution allowing us to generate labels at build time.
Docker labels are a powerful mechanism for adding metadata to your containers and as the New Stack says there are now some good practises for using them at label-schema.org.
Metadata plays a vital role in managing containers at scale. It provides context on what your running containers are actually doing and enables collaboration between teams and between tools.
Automated Builds
Automated registry builds for container images are another powerful tool in our toolbox. The container image on the container registry is linked to a git repository and whenever a commit or a tag is pushed the image is rebuilt. This automates a boring manual task and makes sure that the version in the registry is kept up to date.
Automated builds also help with security. Container images should be rebuilt regularly, otherwise they can contain security vulnerabilities. These vulnerabilities can be in libraries used in the image or in the base image. The base image is especially important as it’s usually based on an operating system distribution. So your image needs the security patches released by the vendor.
OK great features, so what’s the problem?
Adding dynamic labels to automated builds is currently not possible.
Most of the metadata associated with an image is pretty static. Something like the URL associated with an image won’t change often. However some dynamic labels are very important. A couple of examples are the build date for the image or the git commit it is based upon.
For very valid reasons Docker has decided not to allow dynamic code to be executed in Dockerfiles. The solution that has been implemented is to use the ARG command to pass values into a Dockerfile.
So, for non-automated builds it’s pretty straightforward to automate populating the arguments and passing them in to the Dockerfile. For our microscaling image we use a Makefile and put up with the weirdness of the Makefile format.
But for automated builds on Docker Hub or Quay.io this is not so easy. The build process is mainly out of our control. So, there isn’t a way to provide the ARG values to the build.
This is an unsolved problem for now but here are some possible solutions.
- Docker Registries
Docker Hub or Quay.io could set environment variables which can be used in the Dockerfile. It looks like Docker Cloud has support for this.
Long term this would be our preferred approach. We think this is the right thing for registries to do.
2. Pre-processing the Dockerfile
Running a pre-processor over your Dockerfile before it is checked in is another alternative. This works well for the build date but the commit SHA is trickier, as the Dockerfile needs to be committed. So we’re in a chicken-and-egg situation. However, it’s a step forward.
3. Build tools
Build tools like Habitus or Rocker could add sophisticated support for dynamic labels.
Solution
Right now there is no standard solution to the problem of dynamic labels for automated builds but we are hoping one will arrive and when it does we’ll let you know at MicroBadger.com!
Please hit the Recommend button below if you found this article interesting or helpful, so that others might be more likely to find it.
Check out MicroBadger to explore image metadata, and follow Microscaling Systems on Twitter.
