Cloud native GitLab Docker Images

Most images are based on the Debian Linux, using the official bullseye-slim image. A few smaller, quick running tasks are based on Alpine Linux, using the official image.

Built using the official source installation instructions with some Alpine specific fixes and some dependency compilation tweaks picked up from from the omnibus build packages.

Each directory contains the Dockerfile for a specific component of the infrastructure needed to run GitLab.

• rails - The Rails code needed for both API and web.
• webservice - The webservice container that exposes Rails webservers (Puma).
• workhorse - The GitLab Workhorse container providing smart-proxy in front of Rails.
• sidekiq - The Sidekiq container that runs async Rails jobs.
• shell - Running GitLab Shell and OpenSSH to provide git over ssh, and authorized keys support from the database
• gitaly - The Gitaly container that provides a distributed git repos
• gitlab-kas - The backend for the GitLab Agent for Kubernetes
• toolbox - The toolbox container provides utilities for direct interaction with the application suite, without interruping service containers.

Using the images in Helm

See Deploying in Helm

Dev environment using Docker Compose

A dev test environment is provided with docker-compose.

To run the environment:

# Grab the latest Images
docker-compose pull
# Start GitLab
docker-compose up

The instance should then be reachable at http://localhost:3000

Registry access

As the docker-compose deployment does not make use of TLS, docker will be "unhappy". To address this, you can add the following to /etc/docker/daemon.json and then restart the service. It will allow any hostname that resolves to 127.0.0.1 to be handled as insecure.

{
  "insecure-registries" : [ "127.0.0.1" ]
}

Design of the Containers

Configuration

Support for configuration is intended to be as follows:

1. Mounting templates for the config files already supported by our different software (gitlab.yml, database.yml, resque.yml, etc)
2. Additionally support the environement variables supported by the software, like https://docs.gitlab.com/ce/administration/environment_variables.html (support them by not doing anything that would drop them from being passed to the running process)
3. Add ENV variables for configuring the custom code we use in the containers, like the rendering in or of templates, and any wrapper/helper commands

Templating languages supported:

1. ERB, following traditional standards (<% %>) will be available in all Ruby-based application containers.
2. gomplate, using {% %} non-standard delimiters (ensuring compatibility with Helm's internal use of {{ }}) will be available in all GitLab originated containers.
   • NOTE: datasource usage via -d is not supported. For more advanced usage see the gomplate functions.

For Kubernetes specifically we are mostly relying on the mounting the config files from ConfigMap objects. With the occasional ENV variable to control the custom container code.

Links

1. Building Images