The Do’s and Don’ts of Container Registries
Container image registries are a key part of the container stack if you want to run large-scale workloads. But when it comes to setting up and managing an image registry, there are things you should and shouldn’t do.
Registries are important because they provide a centralized place to store container images. Being able to pull an image and start spinning up containers with just a few commands is part of what makes Docker so handy.
Image Registry Do’s and Don’ts
But before you go installing the first registry you see and packing images into it, keep in mind these guidelines for getting the most out of your container image registry.
Do:
- Choose the right registry. There are at least a dozen registries out there. (Here’s a good list of the well-known and less-well-known options.) In some cases, you may not have much freedom to choose a registry because you’ll have to use whatever is supported by the other parts of your container stack. This is the case if you are running your containers on AWS ECS, for example, which comes with its own registry built in. But in most instances you can choose whichever registry you want. So choose the registry that’s right for you by weighing factors such as how much access control it should have; whether you want to deploy on-premises, in the cloud or both; how scalable the registry needs to be; and so on.
- Secure your registry. Whether your registry is hosted in the cloud or on your own private servers, don’t neglect security. This is an especially important point to make because in some cases, the address of your registry will be publicly accessible even if you don’t advertise it outside of your organization. It will, therefore, be easy for you to assume that unauthorized parties won’t access the registry simply because they won’t know where to find it. But that’s security through obscurity, and that never works well. So be sure to lock down your registry by setting up the proper access controls, restricting access at the firewall level and hardening the host server—even if, in theory, no outsiders should be able to find the registry.
Don’t:
- Use your registry as a general-purpose data repository. Container image registries are designed to do one thing and one thing only: host container images. Although you could use to store other types of data by packing it inside container images, resist the temptation to use your registry for hosting information that shouldn’t be there. This is a lesson that Vine learned the hard way last year, when it was using a registry to host source code inside a container image.
- Give everyone on your team access to all container images. Part of the point of using a registry—instead of, say, dumping all your container images onto a network file system and letting anyone on your team pull them from there—is that (in the cases of most registries, at least) you get control over who can access which container images. Take advantage of access control features to ensure that only the people who need to access certain images can. For example, your development team probably doesn’t need to have access to production images, and IT Ops doesn’t need to use development images. Making access too broad creates security issues.
It can be easy to take registries for granted because the task they perform—hosting and serving container images—appears relatively straightforward on the surface. But there are lot of nuances, and it’s important to keep them in mind to get the most from your registry.
