GitLab/Operations

aus www.kruedewagen.de, Homepage von Ralf und Judith Krüdewagen (Kruedewagen)
Zur Navigation springen Zur Suche springen
GitLab Architecture, Source: GitLab

This page describes operational tasks for maintaining a GitLab platform.

Installation

The installation under openSUSE must be done almost manually, since there are no installation packages available for openSUSE. However, on the one hand you learn the best when installing manually, on the other hand the manual installation is quite the same than under the official generic description for Debian. Linux is Linux - and it should not matter which distribution you use unless it's actual enough.

Weblinks

The following link has been used as installation procedure:

Special notes about openSUSE (could party help for handling specific topics like gitlab-shell installation):

This page is useful for understanding the architecture:

Additional repositories

In order to install actual ruby 2 packages (incl. rubygem-bundler), the following repository has been used:

Note: Ruby >= 2.1.6 needed for GitLab 7.14 [1]

Special Notes

Here are some special notes about the installation procedure.

MySQL and Apache

Instead of using the recommended PostgreSQL (as database) and Nginx (as reverse proxy) we use MySQL and Apache, because they are already in use and our standard packages. Using Apache and MySQL is quite well supported and documented (partly by community).

Directories

Instead of /home/git the directory /srv/git has been used as home directory of GitLab.

gitlab-shell

gitlab-shell has been installed by manually cloning the Git repo, described in the links about openSUSE.

charlock_holmes

  • charlock_holmes 0.6.9.4 needs to be installed (not the latest)
  • When a libmagic.a error occurs during bundle install compilation, you need to unset the CONFIG_SITE variable.
unset CONFIG_SITE

Boot integration

The following init scripts have been manually installed and activated:

/etc/init.d/gitlab

In addition, the following init script has been activated:

/etc/init.d/redis

Configuration

MySQL

  • MySQL database: gitlabdb
  • MySQL user: gitlab

Configuration files

The following configuration files are important:

  • ~git/gitlab/config/database.yml
  • ~git/gitlab/config/gitlab.yml
  • ~git/gitlab/config/unicorn.rb
  • ~git/gitlab-shell/config.yml
  • ~git/gitlab/config/application.rb
  • ~git/gitlab/config/environments/production.rb
  • ~git/gitlab/config/initializers/rack_attack.rb
  • /etc/redis/default.conf

Web path

It's not recommended (and not fully supported) to run GitLab within a relative URL path like http://www.example.com/gitlab. If you need to run it like that, have a look to the parameter relative_url_root in config file ~git/gitlab/config/gitlab.yml. See also:

gitlab-shell

The gitlab-shell URL in variable gitlab_url is addressed only internally:

gitlab_url: "http://gitlab.example.com:8090/"

Therefore, whn not using localhost you need to add gitlab.example.com to /etc/hosts:

127.0.0.1       localhost gitlab.example.com

Unicorn

The standard Unicorn configuration is that the reverse proxy - running on the same host - handles the static web content, which includes CSS files, the uploaded files, user images etc.

If the reverse proxy (like in our setup) is located on another host, it normally can't handle those static files. Therefore, Unicorn needs to be configured to handle this static content [1]. The setting is made in ~git/gitlab/config/environments/production.rb:

config.serve_static_assets = false

In order to access the web service from the "external" reverse proxy, you also need to change the listen parameter in ~git/gitlab/config/unicorn.rb [2]:

listen "8090", :tcp_nopush => true

Network parameters

  • The Unicorn web server listens on port 8090 - on all interfaces (for reverse proxy integration when the reverse proxy does not run on same host)
  • Redis listens on standard port 6379.
  • The gitlab-shell is using the standard SSH port 22.

SSH keys

The SSH keys added via the user profile interface are added to

~git/.ssh/authorized_keys

Reverse Proxy integration

In order to access the GitLab GUI and Git repositories via HTTP on a standard port like 80, a proper integration to Nginx or Apache needs to be performed. This is outlined in the GitLab documentation GitLab recipes - Apache.

See also Notes about static web content provided by Unicorn, see also notes about the Unicorn configuration.

Weblinks:

Useful commands

See also maintenance.md.

gitlab-shell

Check proper gitlab-shell configuration and integration:

~git/gitlab-shell/bin/check

Result:

Check GitLab API access: OK
Check directories and files: 
        /srv/git/projects: OK
        /srv/git/.ssh/authorized_keys: OK
Test redis-cli executable: redis-cli 2.6.14
Send ping to redis server: PONG

Note: The gitlab-shell URL in variable gitlab_url is addressed only internally.

GitLab application

Environment

Checking the environment:

cd ~git/gitlab/
bundle exec rake gitlab:env:info RAILS_ENV=production

Output like:

System information
System:         openSUSE project 13.1
Current User:   git
Using RVM:      no
Ruby Version:   2.0.0p247
Gem Version:    2.0.3
Bundler Version:1.6.2
Rake Version:   10.1.1
Sidekiq Version:2.17.0

GitLab information
Version:        6.8.2
Revision:       bfdcbc5
Directory:      /srv/git/gitlab
DB Adapter:     mysql2
URL:            http://gitlab.example.com
HTTP Clone URL: http://gitlab.example.com/some-project.git
SSH Clone URL:  git@gitlab.example.com:some-project.git
Using LDAP:     no
Using Omniauth: no

GitLab Shell
Version:        1.9.4
Repositories:   /srv/git/projects/
Hooks:          /srv/git/gitlab-shell/hooks/
Git:            /usr/bin/git

Extended check

Checking even more:

cd ~git/gitlab/
bundle exec rake gitlab:check RAILS_ENV=production

Assets

In order to re-create the GitLab assets (web components), e.g. after you made some configuration changes, you need to perform:

cd ~git/gitlab/
bundle exec rake assets:clean assets:precompile cache:clear RAILS_ENV=production

Notes:

  • You can also just use e.g. cache:clear to only run one command.
  • After a cache:clear all user GUI sessions are cleared too.
  • The cache:clear command can be used to re-calculate the repository sizes outlined in the GUI.

Logging

GitLab (includes Unicorn and Sidekiq logs):

~/gitlab/log/

gitlab-shell:

~git/gitlab-shell/gitlab-shell.log

Redis:

/var/log/redis/default.log

Logrotate

  • /etc/logrotate.d/gitlab:
# GitLab logrotate settings
# based on: http://stackoverflow.com/a/4883967

/srv/git/gitlab/log/*.log {
    daily
    missingok
    rotate 90
    compress
    notifempty
    copytruncate
}

/srv/git/gitlab-shell/gitlab-shell.log {
    daily
    missingok
    rotate 90
    compress
    notifempty
    copytruncate
}
  • /etc/logrotate.d/redis (from distribution)

Monitoring

Monitoring proper GitLab system and service availability can be done via Icinga.

Following checks should been integrated:

  • checking HTTP Port 80 availability on reverse proxies
  • checking HTTP Port 8090 availability on direct interfaces
  • checking MySQL database
  • checking processes are running: Unicorn, Redis, Sidekiq


Sidekiq

Postfix Integration

Try this setting /instead of default "login" value) if you can't authenticate towards a regular user in Postfix:

gitlab_rails['smtp_authentication'] = "plain"

Backup

You need to backup

  • The git user home dir (containing software, config and repos)
/srv/git
  • Other configurations (Redis, MySQL, Apache, etc.)
/etc
  • Redis dump file(s) in dir
/var/lib/redis/default
  • MySQL database

References