Registry and Gitlab are running as Containers on the same host. Both are connected to a shared docker network. Neither are externally reachable. There is a Reverse Proxy handling all incoming connections to the host (I use HAProxy). Docker-compose.yml: (only the relevant parts, this will not give you a functional setup). Per-job: To configure one job to access a private registry, add DOCKERAUTHCONFIG as a CI/CD variable. Per-runner: To configure a runner so all its jobs can access a private registry, add DOCKERAUTHCONFIG as an environment variable in the runner’s configuration. See below for examples of each. Determine your DOCKERAUTHCONFIG data.
Container orchestration solutions such as Kubernetes allow development teams to be quick and agile with their software deployments. The main feature of these orchestration tools is the ability to reduce the deployment of version piece of software down to a simple tag name on the end of a string. For example
This opens the doors to streamlined deployments, but creates another problem. How do we streamline? We can do this manually, but it’s not very streamlined. Or we can do this automatically, but we need to be smart. We can’t just deploy as soon as a new version is released. We need to check it first. This is where container registries and CI/CD come in.
GitLab can store up to 10 GB in a container registry for projects. You can incorporate the building of these containers into your own CI/CD pipeline or you can use Gitlab’s own CI/CD functionality to do this for you. For this tutorial, you will do this by hand so you can get a grasp of the process.
Find yourself a healthy Kubernetes cluster. If you don’t have access to one, install MicroK8s on your laptop at no cost. If you’re on Windows or Mac you may need to follow the Multipass guide first to get a VM with Ubuntu before you start.