Container registries serve as libraries to store and access third-party container images required during the build phase of the SDLC and the images produced for deployment to test, staging, and production environments. While public container registries are accessible and convenient, private registries can better integrate into existing CI/CD workflows, offer greater control over access and security, as well as help ensure build repeatability and reliability. This Refcard covers key container concepts and terminology; common use cases; and guidelines for container registry configuration, operation, security, and storage.
Docker Manifest – An Experimental Feature!
The image manifest provides a configuration and a set of layers for a container image.
This is an experimental feature. To enable this feature in the Docker CLI, one can edit the config.json file found in ~/.docker/config.json like :
What is Docker Buildx?
Docker Buildx can be defined as a CLI plugin that provides us with the extra features supported by the Moby BuildKit builder toolkit along with the features of the normal docker commands. Furthermore, it also provides us with the same user experience as building with the docker build command.
Also, along with some new extra features added over it like building against multiple nodes with multi-arch images concurrently, builder instances, etc. In addition to that, buildx also supports new features that are not yet available for regular docker build like building manifest lists, distributed caching, etc.
Design Docker images with a heirarchy in mind.
Over the past few years, I’ve had the need to create Docker images for various applications/microservices. In my case, the most predominant use cases were Java and Python. Of course, there are a myriad of Java and Python images available on Docker Hub, and often these images can be used as a good basis for applications. However, as time goes on, I found myself having to manage multiple applications requiring different versions of these platforms.
It’s easy enough to reuse and customize a base image, but it tends to lead to repetitive work in configuration. Over time, like many open source projects, Docker Hub images evolve. That is to be expected. However, challenges arise when that change breaks the way dependent images are assembled or required versions aren’t available. In addition, I have also worked in environments where regulatory considerations were a priority and pulling images from Docker Hub tended to generate questions regarding the source and assurances of meeting specified guidelines. Anyone whose been involved in compliance and security audits understands that the use of external resources always requires some type of additional validation demonstrating the authenticity of the source. It can be done, but, with audits, the fewer questions raised are and the more straightforward the process.
