9 min to read
What is GitLab, GitLab Runner?
A comprehensive guide to GitLab, GitLab Runner installation and configuration

Overview
Let’s explore GitLab, a comprehensive DevOps platform that provides tools for software development, deployment, and collaboration. GitLab helps teams efficiently plan, create, test, and deploy their software projects.
What is GitLab?
GitLab is a web-based DevOps platform that provides an all-in-one solution for software development and collaboration. It offers tools and features that help teams plan, create, build, test, and deploy software projects more efficiently.
GitLab combines version control, issue tracking, CI/CD pipelines, and more into a single, integrated platform.
Key Features:
Installation Guide (Ubuntu 18.04/20.04/22.04)
1️⃣ System Update & Package Installation
# Update System
sudo apt update
sudo apt upgrade -y
# Install Required Packages
sudo apt install -y ca-certificates curl openssh-server tzdata
2️⃣ Add GitLab CE Repository
# Install Dependencies
sudo apt install curl debian-archive-keyring lsb-release ca-certificates apt-transport-https software-properties-common -y
# Add GitLab Repository
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
3️⃣ Install and Configure GitLab
# Install GitLab CE
sudo EXTERNAL_URL="https://gitlab.example.com/" apt-get install gitlab-ce
# Configure SSL (Cloud Environment)
echo "letsencrypt['enable'] = false" | sudo tee -a /etc/gitlab/gitlab.rb
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
Important Directories
-
/var/opt/gitlab/gitlab-rails/shared/lfs-objects
Efficiently handles Git Large File Storage (LFS) objects, reducing repository size while enabling the management of large binary files. -
/var/opt/gitlab/git-data
Houses actual Git repositories, serving as the root directory for all project-related data and repository operations.
Recommended Storage Configuration
# Example Storage Mount
/dev/xvdb1 2.0T 310G 1.6T 17% /var/opt/gitlab/gitlab-rails/shared/lfs-objects
/dev/xvdc1 984G 273G 661G 30% /var/opt/gitlab/git-data
Basic Management Commands
# Reconfigure GitLab
sudo gitlab-ctl reconfigure
# Restart GitLab
sudo gitlab-ctl restart
# Check GitLab Status
sudo gitlab-ctl status
# View Initial Root Password
sudo cat /etc/gitlab/initial_root_password
Backup and Restore
# Create a backup (default location: /var/opt/gitlab/backups)
sudo gitlab-backup create
# Create a backup with specific options
sudo gitlab-backup create STRATEGY=copy SKIP=uploads,repositories,builds GZIP_RSYNCABLE=yes
# Restore from a backup (for GitLab 14.0+)
sudo gitlab-backup restore BACKUP=1640289825_2021_12_23_14.6.3
# Backup GitLab configuration files
sudo cp /etc/gitlab/gitlab-secrets.json /var/opt/gitlab/backups/gitlab-secrets.json
sudo cp /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/gitlab.rb
Performance Tuning
For larger installations, you can optimize GitLab performance by editing /etc/gitlab/gitlab.rb
# CPU and memory optimization
puma['worker_processes'] = 4
puma['max_threads'] = 4
sidekiq['concurrency'] = 20
# PostgreSQL optimization
postgresql['shared_buffers'] = "2GB"
postgresql['work_mem'] = "128MB"
postgresql['maintenance_work_mem'] = "256MB"
# Redis optimization
redis['tcp_timeout'] = 60
redis['tcp_keepalive'] = 300
# Apply changes
# sudo gitlab-ctl reconfigure
GitLab Runner
🔍 What is GitLab Runner?
GitLab Runner is a CI tool that works with GitLab to automatically build, test, and deploy code changes. It’s an open-source project that executes jobs in CI/CD pipelines on systems called Runners.
GitLab Runner can be installed on various operating systems and platforms, including Linux, macOS, Windows, and Kubernetes clusters.
How GitLab Runner Works:
- When code changes are pushed to a GitLab repository with CI/CD pipeline configured
- GitLab creates a new pipeline with one or more jobs
- GitLab Runner periodically checks for new jobs
- Runner executes the job steps defined in
.gitlab-ci.yml
- Runner sends real-time updates and logs back to GitLab
Types of Runners
-
Shared Runners
Available to all projects in a GitLab instance, managed by GitLab administrators. Ideal for common build environments. -
Group Runners
Dedicated to specific project groups and managed by group administrators. Provides better resource control for group projects. -
Specific Runners
Dedicated to single projects, also known as Project Runners. Offers exclusive resources for specific projects.
Runner Executor Types
-
Shell
Executes jobs directly on the host machine. Simple but less isolated. -
Docker
Runs each job in a separate Docker container. Provides good isolation and reproducibility. -
Kubernetes
Creates pods in a Kubernetes cluster for each job. Highly scalable and flexible. -
Virtual Machine
Uses VMs to run jobs. Maximum isolation but higher resource requirements. -
SSH
Connects to remote machines via SSH to execute jobs. Good for specialized environments.
Installation Guide (Helm)
1️⃣ Prerequisites
# Add GitLab Helm Repository
helm repo add gitlab https://charts.gitlab.io/
helm repo update
2️⃣ Create values.yaml
3️⃣ Install GitLab Runner
# Create namespace
kubectl create namespace gitlab-runner
# Install Runner
helm install gitlab-runner -n gitlab-runner -f values.yaml gitlab/gitlab-runner
# Upgrade Runner
helm upgrade gitlab-runner -n gitlab-runner -f values.yaml gitlab/gitlab-runner
Basic GitLab Runner CLI Commands
Example .gitlab-ci.yml
File
Here’s a basic .gitlab-ci.yml
file to get started with CI/CD:
Advanced Runner Configuration
Cache Configuration
Optimize build times by caching dependencies:
# In .gitlab-ci.yml
cache:
key: '${CI_COMMIT_REF_SLUG}'
paths:
- node_modules/
- .npm/
- vendor/
- .gradle/
# Runner config.toml cache settings
[runners.cache]
Type = "s3"
Path = "gitlab-runner"
Shared = true
[runners.cache.s3]
ServerAddress = "s3.amazonaws.com"
AccessKey = "AWSACCESSKEY"
SecretKey = "AWSSECRETKEY"
BucketName = "my-bucket"
BucketLocation = "us-east-1"
Auto-scaling Runners on Kubernetes
For efficient resource usage, configure auto-scaling:
# In Helm values.yaml
concurrent: 10
checkInterval: 30
runners:
config: |
[[runners]]
[runners.kubernetes]
image = "ubuntu:20.04"
privileged = true
namespace = "gitlab-runner"
poll_timeout = 600
cpu_request = "300m"
cpu_limit = "1000m"
memory_request = "500Mi"
memory_limit = "2Gi"
service_cpu_request = "100m"
service_cpu_limit = "200m"
service_memory_request = "100Mi"
service_memory_limit = "200Mi"
helper_cpu_request = "100m"
helper_cpu_limit = "200m"
helper_memory_request = "100Mi"
helper_memory_limit = "200Mi"
Troubleshooting
Common GitLab Issues and Solutions:
1. GitLab Service Issues: - Check service status:
sudo gitlab-ctl status
- View logs:
sudo gitlab-ctl tail
- Check specific component logs:
sudo gitlab-ctl tail nginx
- Check disk space:
df -h
2. Database Problems: - Check PostgreSQL:
sudo gitlab-rails dbconsole
- Database migrations:
sudo gitlab-rake db:migrate:status
- Repair database:
sudo gitlab-rake db:migrate
3. Runner Connection Issues: - Check network connectivity between runner and GitLab
- Verify registration token
- Check runner logs:
sudo gitlab-runner --debug run
- Verify SSL certificates if using HTTPS
4. Pipeline Failures: - Validate
.gitlab-ci.yml
syntax locally- Check if the runner has the right tags
- Verify environment variables are set correctly
- Increase resource limits for demanding jobs
GitLab Runner Debug Commands
# Run runner with debug output
sudo gitlab-runner --debug run
# Show detailed runner information
sudo gitlab-runner verify --verbose
# Check runner config file
cat /etc/gitlab-runner/config.toml
# Test runner connection
gitlab-runner verify --name YOUR_RUNNER_NAME
# Check pod status (for Kubernetes runners)
kubectl get pods -n gitlab-runner
# Check runner pod logs
kubectl logs -n gitlab-runner $(kubectl get pods -n gitlab-runner -l app=gitlab-runner -o name)
Best Practices
GitLab Best Practices:
1. Security: - Enable 2FA for all users
- Regularly update GitLab instance
- Use SSH keys instead of passwords
- Implement proper access controls and permissions
- Enable container scanning in CI pipelines
2. Performance: - Use PostgreSQL optimization for large instances
- Implement Gitaly for repository storage
- Configure proper caching mechanisms
- Use object storage for artifacts, LFS, etc.
- Schedule maintenance during off-hours
3. CI/CD Pipeline: - Keep pipelines fast and efficient
- Use caching for dependencies
- Implement parallel jobs when possible
- Use staged rollouts for deployments
- Implement proper test coverage
4. Runners Management: - Use runner tagging to direct specific jobs
- Implement auto-scaling for cost efficiency
- Separate production and testing runners
- Monitor runner resources and performance
- Regularly clean up runner cache
Comments