Eigenes dediziertes Gitlab Repository

Wer mit git arbeitet, braucht neben den dezentralen auch einen zentralen Repository Speicherort, welches als Quelle für gemeinsame Entwicklung dienen soll. Erste Anlaufstelle für OpenSoure Projekte ist Github. Wer jedoch eine eigenes dediziertes Repository braucht, kann dies mit einer lokalen Gitlab Intanz bewerkstelligen.

Schematischer Aufbau

In diesem Aufbau wurde Gitlab auf einem Raspberry Pi installiert. Zur Authentifizierung mittels LDAP läuft eine virtuelle Windows 2012 R2 Instanz als Domain Controller. Auf dem Client Laptop sind neben Git Bash für Windows auch die aktuelle Eclipse (Neon) Entwicklungsumgebung.

Sorgenfreie Installation

Wer eine sorgenfreie Installation bevorzugt, kann mit dem Paketsystem Omnibus sich eine komplette Gitlab Instanz für sein Betriebssystem herunterladen.

Link: https://about.gitlab.com/downloads/

Manuelle Installation von GitlabHQ

Folgende Grundpakete braucht man nach einer minimalen Debian Installation:

apt-get install sudo vim dialog build-essential zlib1g-dev curl git-core openssh-server mysql-server mysql-client libmysqlclient-dev redis-server checkinstall libyaml-dev libssl-dev libgdbm-dev libreadline-dev libncurses5-dev libffi-dev libxml2-dev libxslt-dev libcurl4-openssl-dev libicu-dev libkrb5-dev python-pkgconfig python-docutils cmake nodejs nginx

Installation Ruby Paket

Gitlab basiert auf die objektorientierte Programmiersprache Ruby. Hierzu wird das aktuelle Paket von der Ruby Projektseite heruntergeladen und auf dem lokalen Server kompiliert.

mkdir -p /opt/ruby
cd /opt/ruby
wget -c https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.1.tar.gz
tar xif ruby-2.3.1.tar.gz
cd ruby-2.3.1/
./configure
make
make install

Installation von RubyGem Paketen

Zur besseren Verwaltung von Ruby Bibliotheken (Gems) wird neben das Verwaltungstool Bundler, weitere benötigte Ruby Programme installiert.

gem install bundler --no-ri --no-rdoc
gem install rugged -v '0.24.0'
gem install timfel-krb5-auth -v '0.8.3'
gem install charlock_holmes --version '0.7.3'

Gitlab shell und Workhorse Umgebung

Vor dem Download und Konfiguration von gitlab müssen erst ein Systemuser „git“ für den Dienst angelegt werden.

adduser --disabled-login --gecos 'GitLab' git
cd /home/git
su git

Mit dem User git wird eine aktuelle Version von gitlab Shell Source aus dem GithubHQ Repository geklont und auf dem Server installiert.

git clone https://github.com/gitlabhq/gitlab-shell.git
cd gitlab-shell
git checkout v3.4.0
cp config.yml.example config.yml
vi config.yml (optional)
./bin/install
exit

 

Zum besseren Handling von push/pull Funktionen über HTTP (Hypertext Transfer Protocol), wird zusätzlich der Reverse Proxy Workhorse installiert.

su git
cd /home/git
git clone https://gitlab.com/gitlab-org/gitlab-workhorse.git
cd gitlab-workhorse/
git checkout v0.7.10
make

 

Als letztes sollten folgende globale git Umgebungsvariablen gesetzt werden.

su git
git config --global user.name "GitLab"
git config --global user.email "gitlab@OUTBACK"
git config --global core.autocrlf input

 

Grundinstallation Gitlab

Ab dieser Phase kann endlich das eigentliche Gitlab vom Github geklont und angepasst werden.

su git
git clone https://github.com/gitlabhq/gitlabhq.git gitlab
cd /home/git/gitlab
git checkout 8-11-stable
cp config/gitlab.yml.example config/gitlab.yml
vi config/gitlab.yml
exit

 

Nach dem Klonen muss vor dem ersten Aufruf das Template von der Konfigurationsdatei wie folgt angepasst werden. Neben dem Hostnamen wird hier zusätzlich eine LDAP (Lightweight Directory Access Protocol) Authentifizierung gegenüber einem Windows Active Directory Server etabliert. Somit können Windows User sich auch automatisch unter Gitlab anmelden. Als letzte Änderung gegenüber dem Template verlege ich das Verzeichnis für die abgelegten Repositories auf ein separate Partition. In dem Fall ist dieser als Verzeichnis /repositories gemountet.

...
host: debian-gitlab
port: 80 
https: false
...
…
ldap:
  enabled: true
  sync_time:
  host: 'windows2012DC'
  port: 389
  uid: 'sAMAccountName'
  method: 'plain' # "tls" or "ssl" or "plain"
  bind_dn: 'CN=gitlabuser,CN=Users,DC=OUTBACK'
  password: 'PASSWORD'
  allow_username_or_email_login: true
  base: 'ou=ACCOUNTS,dc=OUTBACK'
…
  repositories:
    storages: {"default":"/repositories"}
…

 

Anpassung Verzeichnisstruktur

Für die weitere Installation müssen folgende bestehenden Verzeichnisse angepasst werden.

cd /home/git/gitlab
chown -R git log/
chown -R git tmp/
chmod -R u+rwX  log/
chmod -R u+rwX  tmp/

Weiterhin müssen folgende Verzeichnisse angelegt werden.

mkdir /home/git/gitlab-satellites
mkdir /home/gitlab/public/uploads
mkdir /home/git/gitlab/tmp/pids
mkdir /home/git/gitlab/tmp/sockets

 

MySQL Datenbank für Gitlab vorbereiten

Für das Befüllen der Gitlab Tabellen muss in MySQL eine Gitlab Datenbank und einen Datenbankuser angelegt werden.

mysql -u root -p
mysql> CREATE DATABASE IF NOT EXISTS `gitlabDB` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
mysql> GRANT ALL ON `gitlabDB`.* TO 'gitlab'@'localhost' identified by 'FxncN8qRtSIv';
mysql> exit

 

Damit Gitlab sich mit der angelegten MySQL Datenbank verbinden kann, muss die entsprechende Template der Konfigurationsdatei angepasst werden.

cd /home/git/gitlab
cp config/database.yml.mysql config/database.yml
vi config/database.yml
chmod o-rwx config/database.yml

database: gitlabDB
username: gitlab
password: "FxncN8qRtSIv"

 

Anpassung Unicorn Konfiguration

Gitlab benötigt den unter Ruby und C geschriebenen HTTP Server Unicorn, um HTTP Anfragen verarbeiten zu können.

su git
cd /home/git/gitlab
cp config/unicorn.rb.example config/unicorn.rb
vi config/unicorn.rb

 

Ruby on Rails Umgebungsvariable

Nun muss Rails Umgebungsvariable auf Produktion gesetzt werden.

su git
cd /home/git/gitlab
bundle install --deployment --without development test postgres aws
bundle exec rake gitlab:setup RAILS_ENV=production
bundle exec rake gitlab:env:info RAILS_ENV=production

 

Anpassung NGINX Konfiguration

rm -f /etc/nginx/sites-enabled/default
cp /home/git/gitlab/lib/support/nginx/gitlab /etc/nginx/sites-available/gitlab
ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab
vi /etc/nginx/sites-available/gitlab

 

Gitlab Runlevel anlegen

Zum automatischen Starten des Daemons muss das Gitlab init Skript ins Runlevel Verzeichnis /etc/init.d kopiert und ausführbar gemacht werden.

cp /home/git/gitlab/lib/support/init.d/gitlab /etc/init.d/gitlab
chmod +x /etc/init.d/gitlab
update-rc.d gitlab defaults 21

Synchronisation mit Git Bash für Windows

Nachdem man ein erstes Projekt auf dem eigenen Gitlab erstellt hat, kann man über Git Bash für Windows ein Push sein lokales git Repository hoch geladen werden. In dem Beispiel nehme ich gerne alte Programmierübungen von Lehrbüchern. Als erstes muss der exakte HTTP Pfad des neu angelegten Projektes ermittelt werden. Neben HTTP können auch SSH (Secure Shell) als Kommunikationswege verwendet werden. Zum ersten Test reicht aber eine HTTP Übertragung.

Nun muss dem lokalen git Repository der neue Remote Pfad angeben werden. Falls schon ein Remote Pfad in dem Repository existiert, muss dieser in der Datei .git/config enfernt werden.

...
[remote "origin"]
        url = http://debian-gitlab.OUTBACK/Carlos/Erlenkoetter.Java.git
        fetch = +refs/heads/*:refs/remotes/origin/*
...

 

Über die Konsoleneingabe im Git Bash kann dann das lokale Repository hoch geladen werden.

git remote add origin http://debian-gitlab.OUTBACK/Carlos/Erlenkoetter.Java.git
git push -u origin master

 

Klonen eines Gitlab Projekts mit Entwicklungsumgebung Eclipse

Nachdem die ersten Java Programme auf dem Gitlab Projekt hoch geladen wurde, kann man mit Ecplise sich diese als Remote Repository einbinden. Hierbei benötigt die Eclipse Grundinstallation zusätzlich das AddOn „Eclipse Git Team provider“ zur Synchronisation mit einem Git Repository.