Harnessing the power of the GitLab Container Registry

If you’re building containers for your projects, chances are that you are using some brand of container registry such as Docker Hub or the many others provided by different companies. You may even have a container registry set up in your infrastructure that you manage. If you’re using GitLab (SaaS or self-hosted) for your CI/CD pipelines and you’re not using the Container Registry they provide then you’re missing out.

There are many reasons why I think you should be using the Container Registry built into GitLab and I’m going to go over them here.

Registry management becomes a piece of cake

The Container Registry tooling in GitLab is designed to integrate into your groups and projects. This means that projects automatically have access to the registry belonging to them. There is also visibility all the way up the group structure (in GitLab, a project can belong to a group that itself can belong to a group) giving you a single-pane view of all registries in a group.

This means the registry URL and credentials, to push to and pull from these registries, are automatically available via the predefined variables surfaced to pipelines.

Registries can potentially run alongside your pipelines

This really depends on where and how your GitLab Runners are configured. At LSD, we deploy GitLab on Kubernetes which means the Runners we deploy generally run in the same Kubernetes cluster as the registry. What this means for you is that pushing and pulling to these registries has incredibly low latency which is money in your pocket… or at least time in your pocket which can sometimes be more valuable than money.

Jokes aside, if your pipeline doesn’t need to call out to the internet, you're removing any potential man-in-the-middle attacks, saving on bandwidth and also allows your pipeline to run in an air-gapped environment.

Keeping your images away from public networks

If you’re a company that requires any amount of security (which is most companies), having a private registry creates an additional layer of security. It makes sure that the images you run your workloads on (and may contain sensitive data - although they shouldn’t) never touch a public network even if the images are marked as private on that registry.

GitLab also provides container vulnerability scanning solutions that can be used inside the CICD pipelines. Alternatively, you can also bring your own.

The little known feature of the GitLab Dependency Proxy

This isn’t entirely connected to the Gitlab Container Registry but it does form part of the container solutions that GitLab provides. Along with providing a hosted container registry, GitLab provides the Dependency Proxy which allows you to cache often used images alongside your GitLab setup.

It’s an optimisation that we believe decreases build time and it’s especially true on non-containerised installations. However, even if you’re running Kubernetes, making sure that a central proxy for an image is available across all nodes and doesn’t get pruned is very valuable.

For the LSDautomate managed solution that LSD offers, the GitLab Container Registry is a core part of the offering as it is where the range of base images go that are provided to all customers. These images are optimised to work in a range of customer environments which is helpful when there are custom CA certificates or proxies that need to be built into your build, deploy and runtime containers. Using the Container Registry means our customers aren’t forced to pull from the LSD container registry which exists outside their network.