GitLab has recently introduced its integrated Docker container registry, which aims to integrate the use of Docker container images within GitLab's continuous integration tools, writes GitLab engineer Mark Pundsack.
Using GitLab CI developers can now fully automate building, testing, and deploying Docker container images to GitLab Container Registry, where they can be easily accessed by developers. The following is an example configuration file for GitLab CI that builds an image, runs tests, and in the case they are successful, creates a tag for the build and pushes the image to GitLab integrated repository:
build_image:
image: docker:git
services:
- docker:dind
script:
- docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN gitlab.com:5005
- docker build -t my-group/my-project .
- docker run my-group/my-project /script/to/run/tests
- docker tag my-group/my-project
gitlab.com:5005/my-group/my-project:latest
- docker push gitlab.com:5005/my-group/my-project:latest
only:
- master
According to Pundsack, the main benefit of using GitLab Container Registry is its being ready for use without requiring to set up and administer another service or use a public registry. This means, for example:
- GitLab registry relies on GitLab's authentication and thus preserves user and group definitions.
- You do not need to create repositories in the registry since everything is already set up.
- There is no need to install additional software.
GitLab Container Registry can be accessed through a new tab that lists all images related to the current project. The container registry is by default on for each project, so developers can handle their own private registries, but can be turned off per-project. It is available for free on GitLab.com for an unlimited number of private projects and is also available for on-premises installation.
InfoQ has spoken with Mark Pundsack, head of product at GitLab, to learn more about how Docker and GitLab Container Registry can help developers.
Can you explain how GitLab Container Registry can help developers?
There’s two aspects to that: 1) the container registry concept itself, and 2) GitLab’s integrated container registry.
A container registry is useful for sharing and automating various developer workflows. For example, pushing an image to a container registry allows anyone else on the team- and if it’s public, anyone else that needs it- to download or otherwise a completely built version of your software. So rather than having to download source code and compile it yourself, you grab a complete image. But it’s not just an image of the compiled code, it’s an image containing a specific operating system version, specific required tooling etc; everything you need to run the software so there’s no chance of having a slight difference in your laptop or cloud instance affecting the way the software works.
GitLab has integrated the container registry into the entire GitLab workflow to make everything seamless. You just need to manage one set of users and one canonical project. When you connect to the registry, you’ll have access to all the images you're supposed to have access to. Even more importantly for enterprise on-premises users, there’s nothing additional to install or maintain.
There are several emerging practices for integrating Docker into your workflow. Three common ones are: 1) build and test everything outside of docker, then create a Docker image from the results, and 2) build a docker image, then test the image, and 3) build a docker image, test the image alone, then do an integration test using docker-compose to run multiple images at the same time so you can see how everything interacts. The latter case is great for organizations embracing microservices.
In which scenarios do you expect GitLab Container Registry to deliver the most benefits?
One of Docker’s main strengths is to be able to have a single image be used in development, testing, and deployment. This helps reduce surprises when things go into production and suddenly finding a slightly different, incompatible version of the underlying operating system or other tools. For example, it’s common for developers to write their code on a Mac, but then ship to production on Linux. Most of the time this isn’t a problem. But every once in a while it is. Organizations that take their site reliability seriously value having what’s known as dev-prod parity, meaning the development and production environments are as similar as possible.
Microservices is another case where Docker excels because it’s designed to handle and coordinate between multiple services. Before docker, if a developer wanted to test a system with five components, it was very cumbersome to get running on your local laptop. But Docker- especially with docker-compose- makes it so much easier.
A container registry is a central piece to making any of this work.
What is the advantage of an integrated container registry compared to using any third-party Docker registry, such as Docker Hub and others?
The most obvious advantages are cost and convenience. We don’t charge anything additional to run the container registry (including unlimited private projects for personal or business use), and it’s already installed with GitLab. The key piece of integration is that you have integrated authentication and authorization of GitLab that follow your groups and members assigned to your GitLab projects, making it easy to have private container repositories stored on registry.
If you were to use Docker Hub, for example, you’d need to either make your project public, or pay to make it private. If you want it on-premises, like a lot of enterprises do, then you need to pay for Docker Trusted Registry. Either way, you’d still have to manually administer who can collaborate on the images.
GitLab Container Registry requires GitLab 8.8+ and is already freely available on GitLab.com.
