GitLab

Author: Jase Batchelor

Install GitLab on a Lima VM instance running Debian.

This document shows how to set up a minimal instance with the following:

  • configured for memory constrained environment
  • single group and a developer user
  • container registry
  • Maven repository

This is primarily used for demos and to show modern CI / CD practices and tooling.

 

Sections

 

Installation

Add the GitLab repository to Apt sources

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

Example output

#   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
#                                  Dload  Upload   Total   Spent    Left  Speed
# 100  6865  100  6865    0     0   5487      0  0:00:01  0:00:01 --:--:--  5483
# Detected operating system as debian/bullseye.
# Checking for curl...
# Detected curl...
# Checking for gpg...
# Detected gpg...
# Running apt-get update... done.
# Installing debian-archive-keyring which is needed for installing 
# apt-transport-https on many Debian systems.
# Installing apt-transport-https... done.
# Installing /etc/apt/sources.list.d/gitlab_gitlab-ee.list...done.
# Importing packagecloud gpg key... done.
# Running apt-get update... done.
# 
# The repository is setup! You can now install packages.

 

Install GitLab

Install GitLab using Apt

  • Set root password GITLAB_ROOT_PASSWORD
  • Set external URL EXTERNAL_URL - note for local it is just using HTTP
# sudo apt-get install gitlab-ee
sudo GITLAB_ROOT_PASSWORD="password" EXTERNAL_URL="http://192.168.105.2" apt-get install gitlab-ee

Example output

# Reading package lists... Done
# Building dependency tree... Done
# Reading state information... Done
# The following additional packages will be installed:
#   libatomic1
# The following NEW packages will be installed:
#   gitlab-ee libatomic1
# 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
# Need to get 1381 MB of archives.
# After this operation, 4407 MB of additional disk space will be used.
# Do you want to continue? [Y/n] y
# Get:1 http://deb.debian.org/debian bullseye/main arm64 libatomic1 arm64 10.2.1-6 [9468 B]
# Get:2 https://packages.gitlab.com/gitlab/gitlab-ee/debian bullseye/main arm64 gitlab-ee arm64 16.1.0-ee.0 [1381 MB]
# Fetched 1381 MB in 1min 40s (13.8 MB/s)                                                                                                                   
# Selecting previously unselected package libatomic1:arm64.
# (Reading database ... 26540 files and directories currently installed.)
# Preparing to unpack .../libatomic1_10.2.1-6_arm64.deb ...
# Unpacking libatomic1:arm64 (10.2.1-6) ...
# Selecting previously unselected package gitlab-ee.
# Preparing to unpack .../gitlab-ee_16.1.0-ee.0_arm64.deb ...
# Unpacking gitlab-ee (16.1.0-ee.0) ...
# Setting up libatomic1:arm64 (10.2.1-6) ...
# Setting up gitlab-ee (16.1.0-ee.0) ...
# It looks like GitLab has not been configured yet; skipping the upgrade script.
# 
#        *.                  *.
#       ***                 ***
#      *****               *****
#     .******             *******
#     ********            ********
#    ,,,,,,,,,***********,,,,,,,,,
#   ,,,,,,,,,,,*********,,,,,,,,,,,
#   .,,,,,,,,,,,*******,,,,,,,,,,,,
#       ,,,,,,,,,*****,,,,,,,,,.
#          ,,,,,,,****,,,,,,
#             .,,,***,,,,
#                 ,*,.
#   
# 
# 
#      _______ __  __          __
#     / ____(_) /_/ /   ____ _/ /_
#    / / __/ / __/ /   / __ `/ __ \
#   / /_/ / / /_/ /___/ /_/ / /_/ /
#   \____/_/\__/_____/\__,_/_.___/
#   
# 
# Thank you for installing GitLab!
# GitLab was unable to detect a valid hostname for your instance.
# Please configure a URL for your GitLab instance by setting `external_url`
# configuration in /etc/gitlab/gitlab.rb file.
# Then, you can start your GitLab instance by running the following command:
#   sudo gitlab-ctl reconfigure
# 
# For a comprehensive list of configuration options please see the Omnibus GitLab readme
# https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md
# 
# Help us improve the installation experience, let us know how we did with a 1 minute survey:
# https://gitlab.fra1.qualtrics.com/jfe/form/SV_6kVqZANThUQ1bZb?installation=omnibus&release=16-1
# 
# Processing triggers for libc-bin (2.31-13+deb11u6) ...

 

Configuration

Configure GitLab for memory constrained environment and enable the container registry

Example: gitlab.rb

external_url 'http://192.168.105.2'
gitlab_rails['gitlab_email_enabled'] = false

# https://docs.gitlab.com/ee/administration/packages/container_registry.html
# Port 5000 by default
registry_external_url 'http://192.168.105.2:5000'
registry['enable'] = true

# https://docs.gitlab.com/omnibus/settings/memory_constrained_envs.html
puma['worker_processes'] = 0
postgresql['shared_buffers'] = "256MB"
# Author: https://twitter.com/nateberkopec/status/1370420826563096583
sidekiq['max_concurrency'] = 2
prometheus_monitoring['enable'] = false
gitlab_rails['env'] = {
  'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'
}

Update /etc/gitlab/gitlab.rb and restart / reconfigure GitLab

sudo cp gitlab/gitlab.rb /etc/gitlab/gitlab.rb
sudo gitlab-ctl reconfigure

 

Provision demo configuration

Login as the root user with the password you configured during installation.

Create a personal access token as per the steps in this guide:

Using the GitLab REST API this script will create the following:

  • add a default group - (docs)
  • add default project labels - (docs)
  • add default project(s) - (docs)
  • add default project board(s) - (docs)
  • add a user with developer permissions - (docs)
  • add Lima VM SSH key to the user profile - (docs)

Run the gitlab-defaults.sh script

#./gitlab-defaults.sh <IP Address> <GitLab Token>
./gitlab-defaults.sh 192.168.105.2 deadbeef

 

Validate Git repository access

Verify we can clone a repository.

From laptop, setup SSH to reuse the key created by Lima VM

# Add to SSH Agent
eval "$(ssh-agent -s)"
ssh-add ~/.lima/_config/user

Clone a repository

cd $HOME
git clone [email protected]:nakame/ci-templates.git

Troubleshoot SSH keys
Use the following commands to list SSH keys in use:  
ssh -vT [email protected]  
ssh -i ~/.lima/_config/user -vT [email protected]

 

Validate container registry access

https://docs.gitlab.com/ee/user/packages/container_registry/build_and_push_images.html You can use Docker commands to build and push container images to your Container Registry: Authenticate with the Container Registry. Run the Docker command to build or push. For example: To build: docker build -t registry.example.com/group/project/image .

To push: docker push registry.example.com/group/project/image

https://forum.gitlab.com/t/how-do-i-setup-an-insecure-gitlab-container-registry-on-an-instance-of-the-gitlab-omnibus-docker-container/26988/2

https://gitlab.com/gitlab-org/gitlab/-/issues/221259#proposal https://docs.docker.com/registry/insecure/ https://stackoverflow.com/questions/42211380/add-insecure-registry-to-docker https://www.oreilly.com/library/view/kubernetes-in-the/9781492043270/app03.html https://rakeshjain-devops.medium.com/set-up-a-private-docker-registry-insecure-on-ubuntu-18-04-part-1-bd320ff80e7 https://docs.docker.com/registry/ https://www.docker.com/blog/docker-registry-api-standardized-oci/ https://github.com/distribution/distribution https://www.docker.com/blog/how-to-use-your-own-registry-2/ Verify container registry

Use the Docker V2 API to verify the endpoint exists.

This will return an authentication error, but verifies endpoint existence

curl 192.168.105.2:5000/v2/_catalog
# {"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"registry","Class":"","Name":"catalog","ProjectPath":"","Action":"*"}]}]}

 

Use the Docker CLI to verify the endpoint exists.

Again, this will return an authentication error, but verifies endpoint existence

docker login -u jase -p "glpat-deadbeef" 192.168.105.2:5000
# WARNING! Using --password via the CLI is insecure. Use --password-stdin.
# Error response from daemon: Get "https://192.168.105.2:5000/v2/": http: server gave HTTP response to HTTPS client

 

Configure the Docker CLI to access an insecure repository.

Edit ~/.docker/daemon.json

vi ~/.docker/daemon.json

Add the insecure-registries entry as per below:

{
  "experimental": false,
  "insecure-registries": [
      "http://192.168.105.2:5000"
  ]
}

Log in again using the Docker CLI

docker login -u jase -p "glpat-deadbeef" 192.168.105.2:5000
# WARNING! Using --password via the CLI is insecure. Use --password-stdin.
# Login Succeeded

Test the repository

docker pull redhat/ubi8-micro:8.8-1@sha256:1910a0c45d71a1e4041a0aef43a147a1c2590b6bf1df0645ddf66d96a943b507

 

Validate Maven repository access

This one is kind of chicken and egg…

The response will not be valid until we deploy an artifact to the repository

The Maven package path, in the format: //. Replace any . in the groupId with /.

file_name string yes The name of the Maven package file.

curl -L -H "Private-Token: glpat-deadbeef" http://192.168.105.2/api/v4/packages/maven/nakame/spring-demo/1.0.0
# {"message":"403 Forbidden"}

GitLab offers the ability to use Maven repositories (package repositories actually) at 3 different levels - namely instance, group and project.

Each requires slightly different configuration. See these links for examples:

 

Installation

Container registry

General


gitlab
container
oci
debian