DEV Community: Vecha Sumanth

Gitlab - Registry Setup

Vecha Sumanth — Wed, 23 Apr 2025 14:36:07 +0000

A Registry is the source of truth for any container image you use. It's a secure way to store and fetch the images you need.

To simplify it even further, think of it as a warehouse for container images. Let’s set it up and give it a run.

Before we start setting up the Registry VM, we need to tweak some settings on the GitLab Server VM.

Step 1 : Configure Gitlab Server VM

Edit /etc/gitlab/gitlab.rb with the registry details:

################################################################################
## Container Registry settings
##! Docs: https://docs.gitlab.com/ee/administration/packages/container_registry.html
################################################################################

registry_external_url 'http://<YOUR_REGISTRY_IP>:80'

### Settings used by GitLab application
gitlab_rails['registry_enabled'] = true
gitlab_rails['registry_host'] = "http://<YOUR_REGISTRY_IP>:80"
gitlab_rails['registry_port'] = "80"
gitlab_rails['registry_path'] = "/var/opt/gitlab/gitlab-rails/shared/registry"

###! Notification secret, it's used to authenticate notification requests to GitLab application
###! You only need to change this when you use external Registry service, otherwise
###! it will be taken directly from notification settings of your Registry
# gitlab_rails['registry_notification_secret'] = nil

###! **Do not change the following 3 settings unless you know what you are
###!   doing**
gitlab_rails['registry_api_url'] = "http://<YOUR_REGISTRY_IP>:80"
gitlab_rails['registry_key_path'] = "/var/opt/gitlab/gitlab-rails/certificate.key"
gitlab_rails['registry_issuer'] = "omnibus-gitlab-issuer"

This generates the certificate.key, which will come in handy later. Now, let's move on to the Registry VM

Step 2 : Setup Docker Dependencies

yum install containerd.io docker-ce-cli docker-ce
systemctl daemon-reload
systemctl enable --now docker

Step 3 : Create Registry Configuration Directories

We’ll store our Registry configs in /etc/docker/registry.

mkdir -p /etc/docker/registry
chmod 700 /etc/docker/registry

This will include:

gitlab-registry.crt
config.yml.

Generate gitlab-registry.crt on the Gitlab Server like this:

openssl req -key /var/opt/gitlab/gitlab-rails/certificate.key \
            -new -x509 \
            -out gitlab-registry.crt \
            -subj "/CN=omnibus-gitlab-issuer"

Here’s a basic config.yml template you can customize:

version: 0.1
log:
  fields:
    service: registry
  level: info
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
  delete:
    enabled: true
http:
  addr: 0.0.0.0:80
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
auth:
  token:
    realm: https://<YOUR_GITLAB_IP>:80/jwt/auth
    service: container_registry
    issuer: omnibus-gitlab-issuer
    rootcertbundle: /etc/docker/registry/gitlab-registry.crt

Add the config files:

vi gitlab-registry.crt
chmod 600 gitlab-registry.crt
vi config.yml
chmod 600 config.yml

Step 4 : Pull the GitLab Container Registry Image.

I have Gitlab v17.10.4 setup. Check for your registry version here.

docker pull registry.gitlab.com/gitlab-org/build/cng/gitlab-container-registry:v4.15.2-gitlab

Step 5 : Run the Registry Image

docker run --user root -d --name registry --restart=always -v /etc/docker/registry:/etc/docker/registry -p 80:5000 registry.gitlab.com/gitlab-org/build/cng/gitlab-container-registry:v4.15.2-gitlab

Before you go to Gitlab and test it out, the runner will need a slight tweak -

Step 6 : Configure Gitlab Runner VM

Make sure to add an insecure registry entry in the Gitlab Runner VM /etc/docker/daemon.json as shown below.

{
    "insecure-registries" : [ "<YOUR_RUNNER_IP>:5000" ]
}

Restart Daemon & Docker Services

systemctl daemon-reload
systemctl restart docker

Finally, run a quick docker login using your GitLab credentials to confirm everything’s wired up correctly.

docker login <YOUR_REGISTRY_IP>:80

And that's it! You’ve now got a fully functioning private container registry as part of your DevOps setup.

In case you got stuck somewhere, feel free to drop a comment — I’ll try to answer as best as I can.

You can also checkout gitlab forum for any additional help or queries.

Gitlab - Runner Setup

Vecha Sumanth — Sun, 20 Apr 2025 13:37:56 +0000

The Runner is a super important part of the GitLab ecosystem. Builds, tests, deployments — you name it, and the Runner’s got you covered.

In simple terms, Runners are agents that execute GitLab CI/CD jobs in your pipeline. So if you're setting up GitLab in a meaningful way, you'll definitely need one. Fortunately, installing a Runner is pretty straightforward—just like setting up the GitLab server.

Step 1 : Setup Docker Dependencies

yum install containerd.io docker-ce-cli docker-ce
systemctl daemon-reload
systemctl enable --now docker

Step 2 : Setup Gitlab Runner Repository

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo -E bash

Step 3 : Install Gitlab Runner

yum -y --disablerepo='*' --enablerepo='gitlab_gitlab-runner' install gitlab-runner-17.10.1-1.x86_64

Step 4: Register the Runner

Head over to http://<YOUR_GITLAB_URL>/admin/runners
Click New Instance Runner
Enable Run untagged jobs and Paused
Hit Create Runner to generate your token

gitlab-runner register --non-interactive --url {GITLAB_URL} --token {RUNNER_TOKEN} --description "{RUNNER_NAME}" --executor docker

Go to Gitlab - http:///admin/runners and check for the new runner.

Congratulations! You've successfully created your Runner!

In case you got stuck somewhere, feel free to drop a comment — I’ll try to answer as best as I can.

You can also checkout gitlab forum for any additional help or queries.

Gitlab - Self Managed Server Setup

Vecha Sumanth — Sat, 19 Apr 2025 06:08:57 +0000

It’s been a while since I’ve put any of my learnings online — and I’ve realised I should do it more often. Starting now, I’m committing to writing two articles per week to stay consistent with blogging.

Most of my writing will revolve around the OG DevOps platform, GitLab — with the occasional detour into Carl Jung’s theory of the unconscious. Don’t worry, I’m just capping. For any existential spirals, follow @vechasays.

In this first article, we’ll walk through how to set up a GitLab CE self-managed server on your VM.

For a solid DevOps foundation, I recommend setting up your GitLab environment with the following components:

Server
Runner
Registry

In this guide, we’ll set up the main server — I’ll cover the runner and registry in the next ones.

Server Setup

There’s only one prerequisite: access to a VM.

Want to make it instantly usable for your team? Set it up on the cloud.

Since this is a beginner-friendly guide, I’ll skip the advanced requirements and keep things as minimal as possible.

I’ll be using RHEL8 for the rest of this guide, but feel free to use any Linux distribution you prefer.

Step 1 : Opening up the firewall

firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
systemctl reload firewalld

Step 2 : Set Environment Variables

echo "LC_ALL=en_US.UTF-8" > /etc/environment
echo "LANG=en_US.UTF-8"  >> /etc/environment
echo LC_CTYPE="en_US.UTF-8" >> /etc/environment
source /etc/environment

Step 3 : Setup Gitlab-CE Server Repository

curl -L https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh > /tmp/script.rpm.sh
bash -x /tmp/script.rpm.sh

Step 4 : Install Gitlab-CE

yum -y --disablerepo='*' --enablerepo='gitlab_gitlab-ce' install gitlab-ce-17.10.4-ce.0.el8.x86_64

Step 5 : Edit config file /etc/gitlab/gitlab.rb

Make sure that the external_url is set to your Load Balancer IP Address.

#Make a Copy
cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.template

#Edit external_url
vi /etc/gitlab/gitlab.rb

.
.
external_url 'http://<LOAD_BALANCER_IP>:80'
.
.

Step 6 : Hit Reconfigure

This will take some time as it brings the install to life by creating directories and starting up services.

gitlab-ctl reconfigure

Go to http://<LOAD_BALANCER_IP>:80/ on your browser and login with the admin credentials.
Username : root

/etc/gitlab/initial_root_password has your password

Congratulations! You've successfully setup your own DevOps Platform!

In case you got stuck somewhere, feel free to drop a comment — I’ll try to answer as best as I can.

You can also checkout gitlab forum for any additional help or queries.

Understanding the Docker Registry Structure - Gitlab

Vecha Sumanth — Wed, 20 Sep 2023 13:46:35 +0000

Overview

With the Docker container registry image, Gitlab allows the chosen few (Hail DevOps) to integrate a private container registry seamlessly. A couple of edits in the gitlab.rb file and you should be good to go.

The Docker container registry is a pretty stable and reliable piece of software which makes the life of a DevOps Engineer slightly easy. Although there would be some cases where you'd like to play with it. (ensuring chaos ensues)

Finding the treasure

When the Container Registry Image is run by default the rootdirectory set as /var/docker/registry. Which should be the same in most cases.

On mild forensics the file structure comes out to be as shown as below -

- /var/docker/registry
    - v2
        - blobs
        - repositories

v2 corresponds to the Docker Registry API version which Version 2 in this case.

On further digging the repositories directory hosts the following sub-directories -

- repositories
    - gitlab-test-user
        - gitlab-test-repo
            - _layers
            - _manifests
                - revisions
                - tags
                    - sample-tag
                        - current
                            - link
                        - index
            _ _uploads

Phew! That's a long list, but the most important of all is the link component. The link itself is not the image but an ID.

"Then where is the Image?", you ask.

The "Image Data" is stored in the blobs directory under the v2 directory. Opening up blobs gives us the this -

- blobs
    - sha256
        - 3b
        - cb
        - f6
            - f662ea83eddb8ce7e979cb6c09527feace32d32500e027fa87bf5362d732af16
                - data

Haha, Finally the data!
Uhmmm not yet.

{
    "schemaVersion": 2,
    "mediaType": "application/vnd.docker.distribution.manifest.v2+json"
    "config": {
        "mediaType": "application/vnd.docker.container.image.v1+json"
        "size": 1619,
        "digest"; "sha256:3b0372d60921e1cc0c017732ff6d41f8e4880246a6d9c8c9d101edc1726a79ab"
    },
    "layers": [
        {
            "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
            "size": 2813316,
            "digest": "sha256:cbdbe7a5bc2a134caBec91be58565ec07d037386d1f1d8385412d224deafca08"
        }
    ]
}

This is rather a JSON document containing details of the image.

The config digest ("sha256:3b0372d60921e1cc0c017732ff6d41f8e4880246a6d9c8c9d101edc1726a79ab") is a link to a document that will instruct docker on how to build the image. It can be found under blobs/sha256/3b.

One thing to understand is that a Docker Image is not a single chunk of data rather it is a collection of layers. This is a really efficient technique to store data as this helps in not storing redundant pieces of information as we will see later.

Now moving on to the second part of the above "data" file is the link to where the layers of the image are stored. Here we have the digest as "sha256: cbdbe7a5bc2a134caBec91be58565ec07d037386d1f1d8385412d224deafca08" which again can be found under blobs/sha256/cb, you can now see the Image in its layers form. Since we have only one layer here, that itself is the image or rather the ingredient of the image which will be used by docker to create the image.

The layers themselves are single pieces but when combined make up the image. This helps in saving up space.

Take a scenario where the same image is being pushed into the registry, this time rather than again storing the redundant piece of data, docker will link to the same image layer as the previous one. Saving us with some space.

Considering the case where the are some changes to the image and is pushed to the same or a different repository, docker will create a new layer which is the diff (just the modified part) part of the new image and simply create a link and add this to the configuration file which we saw earlier.

{
    "schemaVersion": 2,
    "mediaType": "application/vnd.docker.distribution.manifest.v2+json"
    "config": {
        "mediaType": "application/vnd.docker. container. image.v1+json"
        "size": 1619,
        "digest"; "sha256:3b0372d60921e1cc0c017732ff6d41f8e4880246a6d9c8c9d101edc1726a79ab"
    },
    "layers": [
        {
            "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
            "size": 2813316,
            "digest": "sha256:cbdbe7a5bc2a134caBec91be58565ec07d037386d1f1d8385412d224deafca08"
        },
        {
            "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
            "size": 109,
            "digest": "sha256:5110abe04d9e848d121feb3cc36dd0ec20465f6f67f6dc49699ea408bc244188"
        }
    ]
}

The modified part of the image forms a new layer and the link to that layer has been added to the file.

Summing up, whenever we do a docker pull to the registry it will go and fetch the link under the respective repository, which points towards the manifest file in blobs containing the recipe (instructions) and the ingredients (layers) which docker will then use to make the image.

For further explanation - Reference