GitLab/Operations
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):
- Howto install Gitlab on top of opensuse 12.3 32bit
- Install GitLAB OpenSUSE 12.3
- Installation-guide-for-GitLab6-on-SLES11
- openSUSE 12.3 Installation of GitLab, Nginx, Apache and Drupal PHP
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
- See what Sidekiq background jobs are being processed: http://gitlab.example.com/admin/background_jobs.
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