The settings of an instance in a container are the settings of the Linux package installation, and the container adds its own layer: where the configuration file lives, which variables the start-up script reads and which ports the host publishes.
Applying a configuration change
The configuration file is /etc/gitlab/gitlab.rb on the configuration volume, that is /srv/code/config/gitlab.rb on the host. Edit it on the host, or in the container:
docker exec -it code editor /etc/gitlab/gitlab.rbApply the change without stopping the container:
docker exec code gitlab-ctl reconfigureA restart has the same effect, because every start of the container runs the configuration:
docker restart codeInterface language, SMTP, worker counts and backup retention are the same settings as on a host installation; what each of them does is described in Post-installation setup.
Start-up variables
The start-up script reads its variables when the container starts, so a change to any of them means creating the container anew with the same volumes.
| Variable | What it does |
|---|---|
GITLAB_OMNIBUS_CONFIG |
Holds configuration lines, which are evaluated before /etc/gitlab/gitlab.rb is read. A setting present in the file overrides the same setting in the variable. |
GITLAB_SKIP_RECONFIGURE |
With the value true on an already configured instance, the start skips gitlab-ctl reconfigure, and configuration changes stay unapplied until the next configuration run. |
GITLAB_SKIP_PG_UPGRADE |
With the value true, the start does not run gitlab-ctl pg-upgrade and the database stays on its current PostgreSQL version. |
GITLAB_DISABLE_OPENSSH |
With the value true, the start does not prepare the sshd service, and Git over SSH is unavailable. |
GITLAB_SKIP_TAIL_LOGS |
With the value true, the service logs are not written to the container output; they stay on the log volume. |
GITLAB_PRE_RECONFIGURE_SCRIPT |
When set, its value runs as a shell command before the services start. |
GITLAB_POST_RECONFIGURE_SCRIPT |
When set, its value runs as a shell command after the PostgreSQL step. |
GITLAB_ALLOW_SHA1_RSA |
With the value true, the sshd configuration accepts the ssh-rsa host key algorithm and public key type. |
OPENSSL_FORCE_FIPS_MODE |
Its value is written to the environment of the sshd service. |
SSH host keys
The RSA, ECDSA and Ed25519 host keys are generated on the first start into /etc/gitlab and linked into /etc/ssh, where the instance reads them. They are on the configuration volume, so a container replaced during an upgrade keeps them and Git clients see the same host key as before. A new configuration volume means new keys, and every client reports a changed host key on the next connection.
Git over SSH uses the keys that users add in the web interface: sshd in the container listens on port 22, accepts the git user only and has password authentication turned off.
Memory and workers
The container gets the memory of the host unless --memory limits it at creation, and it needs --shm-size 256m as described in Requirements.
On a host with 6–8 GB of RAM, fix the number of workers instead of leaving it to autotuning. The settings go into /etc/gitlab/gitlab.rb or into GITLAB_OMNIBUS_CONFIG, and their values are described in Post-installation setup:
puma['worker_processes'] = 2
sidekiq['concurrency'] = 10Ports and the host firewall
Ports 80, 443 and 22 are published when the container is created. A host port may differ from the container port, as in -p 8080:80 -p 8443:443 -p 2222:22.
The address of the instance names the host port that users open; the SSH port that the web interface shows in clone URLs is the gitlab_rails['gitlab_shell_ssh_port'] setting, described in SSH port.
Open the published ports on the host for the networks of the users; the commands for firewalld and ufw are in Post-installation setup. Docker publishes ports through its own iptables rules, so check the ports from a workstation after each change of the firewall rules:
curl -sI http://<HOSTNAME>/ | head -n 1
ssh -T -p 22 git@<HOSTNAME>Advanced search (OpenSearch)
The OpenSearch connection is the gitlab_rails['fe_search'] setting and the Sidekiq routing rule described in Advanced search (OpenSearch). Put them into /etc/gitlab/gitlab.rb in the configuration volume or into GITLAB_OMNIBUS_CONFIG, then restart the container or run docker exec code gitlab-ctl reconfigure.