github.com ist ein großartiges Tool für Open Source Projekte auf der ganzen Welt. Es stellt einfachen Zugriff auf das git-Versionierungssystem zur Verfügung, ohne dass man sich um die Befehle für das Erstellen und Warten eines solchen Repos Gedanken machen müsste.
Das ist toll, allerdings hat github einen Nachteil: für private Repositories – also solche, bei denen der Code nicht der ganzen Welt zur Verfügung steht – werden (relativ hohe) Gebühren fällig. Somit ist dieses Tool für kommerzielle Zwecke nur bedingt geeignet, falls man nicht die „Plans“ (github: Plans & Pricing) in Anspruch nehmen möchte.
Lange Zeit gab es keine Softwarelösung, die man sich auf dem eigenen Server installieren konnte, und die ähnlichen Komfort wie github zu bieten hatte. Doch seit einiger Zeit etabliert sich eine solche Lösung: Gitlab. Das Tool steht github kaum noch in etwas nach und kann kostenfrei auf (fast) jedem Rootserver betrieben werden:
- Ubuntu Linux
- Debian/GNU Linux
- Fedora
- CentOs
- RedHat.
Zur Installation reichen je nach Komplexität der Installation einige wenige Schritte aus, mehr Komfort gibt es – wie immer – mit mehr Schritten. Doch zunächst das Basis-Setup:
Wer ein paar Basis-Programme nicht installiert hat, muss dies zuerst nachholen:
1
| sudo apt-get install wget git git-core build-essential libyaml-dev |
sudo apt-get install wget git git-core build-essential libyaml-dev
Als Nächstes laden wir das Installscript von gitlab herunter und installieren es, was uns viel Arbeit erspart. Es ist dabei von Vorteil, noch kein RubyOnRails installiert zu haben (falls Ruby schon installiert ist, muss es zwingend Ruby 1.9.2 oder besser sein). Ansonsten muss das Script angepasst werden, die Befehle sind relativ selbsterklärend. Hier nun die Variante mit Script (Download-Adresse aktualisiert 19.10.2012):
1
2
3
| wget https://raw.github.com/gitlabhq/gitlab-recipes/master/install/debian_ubuntu.sh
chmod +x debian_ubuntu.sh
./debian_ubuntu.sh |
wget https://raw.github.com/gitlabhq/gitlab-recipes/master/install/debian_ubuntu.sh
chmod +x debian_ubuntu.sh
./debian_ubuntu.sh
Alternativ sind Schritte 1-4 dieser Anleitung auszuführen.
Nun setzen wir die Komponenten für den Ruby-Server auf:
1
2
3
4
5
6
7
| sudo gem install charlock_holmes
sudo pip install pygments
sudo gem install bundler
cd /home/gitlab
sudo -H -u gitlab git clone git://github.com/gitlabhq/gitlabhq.git gitlab
cd gitlab
sudo -u gitlab cp config/gitlab.yml.example config/gitlab.yml |
sudo gem install charlock_holmes
sudo pip install pygments
sudo gem install bundler
cd /home/gitlab
sudo -H -u gitlab git clone git://github.com/gitlabhq/gitlabhq.git gitlab
cd gitlab
sudo -u gitlab cp config/gitlab.yml.example config/gitlab.yml
1
2
3
| sudo -u gitlab cp config/database.yml.sqlite config/database.yml
ODER
sudo -u gitlab cp config/database.yml.example config/database.yml |
sudo -u gitlab cp config/database.yml.sqlite config/database.yml
ODER
sudo -u gitlab cp config/database.yml.example config/database.yml
Nachdem die Datenbank-Konfiguration kopiert wurde, müssen bei MySQL die Verbindungsparameter angepasst werden. SQLite läuft sofort „out of the box“.
Im folgenden Schritt initialisieren und konfigurieren wir Gitlab für den Ruby-Server, anschließend testen wir die Umgebung:
1
2
3
| sudo -u gitlab -H bundle install --without development test --deployment
sudo -u gitlab bundle exec rake gitlab:app:setup RAILS_ENV=production
sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production |
sudo -u gitlab -H bundle install --without development test --deployment
sudo -u gitlab bundle exec rake gitlab:app:setup RAILS_ENV=production
sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production
1
2
3
4
5
6
7
8
9
10
11
12
| Starting diagnostic
config/database.yml............exists
config/gitlab.yml............exists
/home/git/repositories/............exists
/home/git/repositories/ is writable?............YES
remote: Counting objects: 603, done.
remote: Compressing objects: 100% (466/466), done.
remote: Total 603 (delta 174), reused 0 (delta 0)
Receiving objects: 100% (603/603), 53.29 KiB, done.
Resolving deltas: 100% (174/174), done.
Can clone gitolite-admin?............YES
UMASK for .gitolite.rc is 0007? ............YES |
Starting diagnostic
config/database.yml............exists
config/gitlab.yml............exists
/home/git/repositories/............exists
/home/git/repositories/ is writable?............YES
remote: Counting objects: 603, done.
remote: Compressing objects: 100% (466/466), done.
remote: Total 603 (delta 174), reused 0 (delta 0)
Receiving objects: 100% (603/603), 53.29 KiB, done.
Resolving deltas: 100% (174/174), done.
Can clone gitolite-admin?............YES
UMASK for .gitolite.rc is 0007? ............YES
Der Output des Testbefehls sollte keine „failed“- oder „no“- Einträge haben. Falls alle Zeichen auf „grün“ stehen können wir den Server starten.
1
2
| sudo -u gitlab bundle exec rails s -e production -d
./resque.sh |
sudo -u gitlab bundle exec rails s -e production -d
./resque.sh
Der Server läuft nun und ist über Port 3000 bereits zugreifbar (nicht wundern, der erste Seitenaufruf dauert ziemlich lange). Wem das reicht, der ist bereits fertig.
Ich selbst mag meine Web-Anwendungen alle über HTTP(S) abrufen, so auch gitlab. Dazu nutze ich nicht die vom Tutorial vorgeschlagene Variante nginx + Unicorn sondern Passenger für Apache (weil Apache bei mir für alle Webanwendungen genutzt wird und Unicorn viel zu umständlich für kleine bis mittlere Installationen ist):
1
2
| gem install passenger
passenger-install-apache2-module |
gem install passenger
passenger-install-apache2-module
Bei der Installation einfach den Anweisungen folgen, es sind ja nicht viele. Danach kann ein VirtualHost für gitlab angelegt werden, wichtig dabei: DocumentRoot muss auf das „public“-Verzeichnis von gitlab zeigen! Schon kann man z.B. über http(s)://gitlab.yourdomain.com auf gitlab zugreifen und loslegen.
Wichtig: Passenger ersetzt quasi den Deploy-Prozess von gits bundle exec, d.h. der Server auf dem Port 3000 muss dann nicht mehr laufen. Wenn man die Wartezeit für den ersten Besucher von gitlab nach dem Serverstart verkürzen will kann man den Apache wie folgt konfigurieren:
1
2
3
4
5
6
7
8
9
| PassengerPreStart https://git.yourdomain.com/
<VirtualHost ip:443 >
ServerName git.yourdomain.com
UseCanonicalName Off
DocumentRoot /home/gitlab/gitlab/public
PassengerMinInstances 1
... |
PassengerPreStart https://git.yourdomain.com/
<VirtualHost ip:443 >
ServerName git.yourdomain.com
UseCanonicalName Off
DocumentRoot /home/gitlab/gitlab/public
PassengerMinInstances 1
...
Als optionalen Schritt kann man nun noch ein Shell-Script für init.d schreiben, damit man resque nach einem Neustart nicht immer von Hand aufrufen muss:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
| #! /bin/bash
### BEGIN INIT INFO
# Provides: gitlab
# Required-Start: $local_fs $remote_fs $network $syslog redis-server
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: resque service for gitlab
# Description: resque service for gitlab
### END INIT INFO
NAME=resque
DESC="resque service"
RESQUE_PID=/home/gitlab/gitlab/tmp/pids/resque_worker.pid
case "$1" in
start)
CD_TO_APP_DIR="cd /home/gitlab/gitlab"
START_RESQUE_PROCESS="./resque.sh"
echo -n "Starting $DESC: "
if [ `whoami` = root ]; then
sudo -u gitlab sh -l -c "$CD_TO_APP_DIR > /dev/null 2>&1 && $START_RESQUE_PROCESS"
else
$CD_TO_APP_DIR > /dev/null 2>&1 && $START_RESQUE_PROCESS
fi
echo "$NAME."
;;
stop)
echo -n "Stopping $DESC: "
kill -QUIT `cat $RESQUE_PID`
echo "$NAME."
;;
restart)
echo -n "Restarting $DESC: "
kill -USR2 `cat $RESQUE_PID`
echo "$NAME."
;;
reload)
echo -n "Reloading $DESC configuration: "
kill -HUP `cat $RESQUE_PID`
echo "$NAME."
;;
*)
echo "Usage: $NAME {start|stop|restart|reload}" >&2
exit 1
;;
esac
exit 0 |
#! /bin/bash
### BEGIN INIT INFO
# Provides: gitlab
# Required-Start: $local_fs $remote_fs $network $syslog redis-server
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: resque service for gitlab
# Description: resque service for gitlab
### END INIT INFO
NAME=resque
DESC="resque service"
RESQUE_PID=/home/gitlab/gitlab/tmp/pids/resque_worker.pid
case "$1" in
start)
CD_TO_APP_DIR="cd /home/gitlab/gitlab"
START_RESQUE_PROCESS="./resque.sh"
echo -n "Starting $DESC: "
if [ `whoami` = root ]; then
sudo -u gitlab sh -l -c "$CD_TO_APP_DIR > /dev/null 2>&1 && $START_RESQUE_PROCESS"
else
$CD_TO_APP_DIR > /dev/null 2>&1 && $START_RESQUE_PROCESS
fi
echo "$NAME."
;;
stop)
echo -n "Stopping $DESC: "
kill -QUIT `cat $RESQUE_PID`
echo "$NAME."
;;
restart)
echo -n "Restarting $DESC: "
kill -USR2 `cat $RESQUE_PID`
echo "$NAME."
;;
reload)
echo -n "Reloading $DESC configuration: "
kill -HUP `cat $RESQUE_PID`
echo "$NAME."
;;
*)
echo "Usage: $NAME {start|stop|restart|reload}" >&2
exit 1
;;
esac
exit 0
Diese Datei speichern wir unter /etc/init.d/resque und machen es mit
1
| sudo chmod +x /etc/init.d/resque |
sudo chmod +x /etc/init.d/resque
ausführbar. Danach noch einen symbolischen Link nach /etc/rc2.d/ anlegen
1
2
| cd /etc/rc2.d
ln -s /etc/init.d/resque S99resque |
cd /etc/rc2.d
ln -s /etc/init.d/resque S99resque
Fertig.
Achtung: Das von Gitlab angelegte Admin-Passwort ist immer gleich, d.h. es ist zu empfehlen, sich einen eigenen Account mit Administrationsrechten anzulegen und den Admin-Account dann zu blocken, oder das Passwort des Admin-Accounts zu ändern.
