Installation de GitLab sur Debian

Le partage, un des maitres-mots du mouvement DevOps, commence par l’usage d’un référentiel (Repository pour les anglophones) communautaire. Il sert bien sûr pour partager des sources de codes que chacun pourra corriger et améliorer, mais il sert aussi au perfectionnement des configurations. La mise en commun des configurations, ce grand travail collectif précédemment abordé, permet une mise en lumière sur des besoins spécifiques, les dépendances de certains packages ou certaines versions de logiciels, ou encore certains paramétrages d’intergiciel (middleware pour les anglophones), ou les paramétrages des équipements réseaux. Quant une équipe mets en place un logiciel utilisant un port particulier autant qu’elle l’insère elle-même directement dans le fichier de configuration des plages de ports à ouvrir. A contrario de l’usage propriétaire où il faut opérer à une demande auprès de l’équipe réseau pour reprendre l’exemple, cette démarche de modification par tous -et pour tous- n’est possible que dans une dynamique communautaire.

Un des plus célèbres référentiels communautaires est GitHub.com, or pour différentes raisons, entre autre de confidentialité, il peut être interdit d’usage dans certaines sociétés (OVH : Pourquoi j’ai interdit GitHub ?). Il est donc intéressant de trouver une solution interne. Un de ces gestionnaires de référentiel Git est GitLab qui propose une Community Edition (CE) et une Enterprise Edition (EE), ainsi qu’une Continuous Integration qui sort de notre actuel sujet. Voyons dans cet article comment installer GitLab CE.

Du Package

Au 31 mars de cette année 2014, le packaging pour Debian était sur le NewContributorGame de DebianFrance, et une recherche sur packages.debian.org reste sans réponse. Il est clair que les dépendances avec des versions précises d’autres paquets tels que Ruby et python, ne facilitent pas la tâche.

L’omnibus project vise à packager une installation facile.
Télécharger le deb à partir de : gitlab.com/downloads . Je n’ai malheureusement trouvé aucun current ou stable qui permette de pérenniser la méthode. Puis il suffit de procéder à :

sudo apt-get install openssh-server
sudo apt-get install exim4-daemon-light
sudo dpkg -i gitlab-x.y.z.deb # this is the .deb you downloaded
sudo gitlab-ctl reconfigure

Or si cette installation est rapide en terme d’instructions, elle est directive puisqu’elle force une solution postgresql pour la base de données, nginx pour le serveur web, et exim pour le SMTP.

Install me if you can

Retroussons nos manches pour mieux maitriser notre installation en procédant par des étapes aux options choisies. On va procéder à l’installation de :

  • Un compte de service
  • pré-requis avec git
  • Python 2
  • Ruby 2+
  • Shell GitLab
  • MySql version 5.5.14 or later
  • Gitlab
  • Nginx

Gitlab Installation Helper

Autant vous le dire tout de suite, j’ai produit un petit script sans prétention qui reprend la plupart de ces commandes. Il vous suffira de le récupérer et d’adapter les constantes en début de script à votre convenance. Cet outil permet une installation en deux fois. A l’issue de la première partie il sera noter les fichiers de configuration qu’il faut retoucher avant de relancer le même script qui passera à la fin par un jeu de flag.
Les valorisations que j’utilise dans ces fichiers sont mises en relief dans le présent article.

Disponible sur : https://github.com/oloc/scripts

Autant faire propre

Comme souvent, je commence par la création du compte de service gitlab (à noter que les documentations choisissent git), sans connexion au serveur mais qui prendra tout en charge. Les utilisateurs extérieurs n’auront pas à être déclarés sur le système, mais seulement dans l’application GitLab. A noter qu’il faudra renseigner ce compte dans le config.yml, comme on le verra plus loin. Sa création passe par la commande :

sudo adduser --disabled-login --gecos 'GitLab' gitlab

De plus, je préfère que cette installation suive le Filesystem Hierarchy Standard (FHS). Et donc contrairement aux documentations qui présentent une installation dans le $HOME de ce compte de service, je procéderai à l’installation dans le /opt à l’aide d’une variable par souplesse. De même, je reporterai les logs vers le /var/log/.

export InstDir=/opt
sudo mkdir /var/log/gitlab && sudo chown gitlab:gitlab /var/log/gitlab

La cerise sur le git-core

Une première salve d’installation de prérequis en tout genre (les *-dev servant aux make à venir) précédée d’une classique mise à niveau, close par l’installation de git, c’est la moindre des choses.

sudo apt-get update -y && sudo apt-get upgrade -y
sudo apt-get install -y build-essential zlib1g-dev libyaml-dev libssl-dev libgdbm-dev libreadline-dev libncurses5-dev libffi-dev curl openssh-server redis-server checkinstall libxml2-dev libxslt-dev libcurl4-openssl-dev libicu-dev logrotate
sudo apt-get install -y git-core

2 Pythons valent mieux que Python3 tu l’auras

Ensuite, on installe Python dans sa version 2, puisque la 3 n’est pas supportée par GitLab, comme souvent avec le troisième opus du reptile. Pour cela on installe la version en cours, suivant d’une version dédiée (ici la 2.7). Puis on s’assure que python2 réponde bien en créant un lien. Enfin on installe le paquet Documentation Utilities, pour les mises en forme de texte des formats balisés.

sudo apt-get install -y python
sudo apt-get install -y python2.7
sudo ln -s /usr/bin/python /usr/bin/python2
sudo apt-get install -y python-docutils

My name is Jack, Jack Ruby

D’après la documentation Requirements, GitLab demande une version de Ruby en 2.0 ou 2.1. Et en imaginant que ce ne sera pas régressif, j’extrapole en récupérant la dernière version stable en cours (stable-snapshot), suivi d’un configure / make / make install à l’ancienne. On finalise avec l’installation du bundler gem qui facilite le déploiement des applications Ruby et leurs dépendances.

mkdir /tmp/ruby && cd /tmp/ruby
curl --progress ftp://ftp.ruby-lang.org/pub/ruby/stable-snapshot.tar.gz | tar xz
cd *
./configure --disable-install-rdoc
make
sudo make install
sudo gem install bundler --no-ri --no-rdoc

Shell GitLab

GitLab dispose de son propre shell qui passe sur du SSH. On va donc l’installer dans le HOME du compte de service (pour moi gitlab), et on va s’y substituer par l’usage de sudo -u <user>. La dernière branche stable est à l’heure actuelle la 1.9.0, et je préfère la forcer.

cd $InstDir
sudo -u gitlab -H git clone https://github.com/gitlabhq/gitlab-shell.git -b v1.9.0
cd gitlab-shell
sudo -u gitlab -H cp config.yml.example config.yml

Il faut modifier le config.yml à votre convenance. Voici les quelques valeurs que j’utilise.

config.yml
user: gitlab
gitlab_url: "http://localhost/"
repos_path: "/var/gitlab/repositories"
auth_file: "/home/gitlab/.ssh/authorized_keys"
log_file: "/var/log/gitlab/gitlab-shell.log"

Une fois que tout est prêt, on procède au déploiement :

sudo -u gitlab -H ./bin/install

Base de données MySQL

Installation classique déjà décrite un peu partout. A noter qu’elle demande un mot de passe pour le compte root, celui de la base de données, pas celui du système ! Puis, une petite sécurisation de l’installation. Et pour finir une connection à mysql pour passer différentes commandes.

sudo apt-get install -y mysql-server mysql-client libmysqlclient-dev
sudo mysql_secure_installation
mysql -u root -p

Le prompt mysql> n’est décrit ici que pour marquer la différence. De même <mot de passe> est à remplacer par la valeur de votre choix, entre simple quote mais sans les <>. En manque total d’imagination, je laisse le nom de base proposée dans les documentations gitlabhq_production.

mysql> CREATE USER 'gitlab'@'localhost' IDENTIFIED BY '<mot de passe>';
mysql> SET storage_engine=INNODB;
mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
mysql> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO 'gitlab'@'localhost';
mysql> quit

Un petit test de connexion en renseignant le <mot de passe>. A noter que le premier utilisateur gitlab est celui du système et le second celui du mysql.

sudo -u gitlab -H mysql -u gitlab -p -D gitlabhq_production
mysql> quit

Installation de GitLab

Une fois qu’on a installé tout le nécessaire, on peut s’atteler à la tâche principale de cette installation. Pour cela on récupère le git que l’on déploie, on ajoute quelques répertoires avec leur droits, on redirige les logs comme il se doit, et enfin on prépare le rack_attack, gitlab.yml et unicorn.rb pour les configurer.

cd $InstDir
sudo -u gitlab -H git clone https://github.com/gitlabhq/gitlabhq.git -b 6-4-stable gitlab
cd $InstDir/gitlab
sudo -u gitlab -H mkdir tmp/pids/ && sudo chmod -R u+rwX tmp/pids/
sudo -u gitlab -H mkdir tmp/sockets/ && sudo chmod -R u+rwX tmp/sockets/
sudo -u gitlab -H mkdir public/uploads && sudo chmod -R u+rwX public/uploads
sudo -u gitlab -H mv log log.old && sudo -u gitlab -H ln -s /var/log/gitlab/ log
sudo -u gitlab -H mkdir $InstDir/gitlab-satellites
sudo -u gitlab -H cp config/initializers/rack_attack.rb.example config/initializers/rack_attack.rb
sudo -u gitlab -H cp config/gitlab.yml.example config/gitlab.yml
sudo -u gitlab -H cp config/unicorn.rb.example config/unicorn.rb
sudo -u gitlab -H cp config/database.yml.mysql config/database.yml
sudo -u gitlab -H chmod o-rwx config/database.yml

A ce stade il faut prendre le temps de configurer les fichiers :

  • $InstDir/gitlab/config/gitlab.yml
  • $InstDir/gitlab/config/unicorn.rb
  • $InstDir/gitlab/config/database.yml

Voici les quelques valorisations que je revoie. Le $InstDir est dans la documentation /home/git/ (donc peu de changement) pour ma part c’est /opt.

gitlab.yml
gitlab:
host: localhost
port: 80
user: gitlab
email_from: gitlab@olivierlocard.com
satellites:
path: $InstDir/gitlab-satellites/
gitlab_shell:
path: $InstDir/gitlab-shell/
repos_path: /var/gitlab/repositories/
hooks_path: $InstDir/gitlab-shell/hooks/

unicorn.rb
working_directory "$InstDir/gitlab"
listen "$InstDir/gitlab/tmp/sockets/gitlab.socket", :backlog => 64
pid "$InstDir/gitlab/tmp/pids/unicorn.pid"
stderr_path "$InstDir/gitlab/log/unicorn.stderr.log"
stdout_path "$InstDir/gitlab/log/unicorn.stdout.log"

database.yml
username: gitlab
password: baltig

Configuration du git

On configure l’outil git au regard de ce qu’on aura renseigné dans le gitlab.yml par la série de commande :

sudo -u gitlab -H git config --global user.name "GitLab"
sudo -u gitlab -H git config --global user.email "gitlab@localhost"
sudo -u gitlab -H git config --global core.autocrlf input

Le déploiement

Comme le précise la documentation, vous noterez que pour mysql, c’est without postgres… On met en place le script d’initialisation, avec démarrage automatique, ainsi que la rotation des logs.

cd $InstDir/gitlab
sudo -u gitlab -H bundle install --deployment --without development test postgres aws
sudo -u gitlab -H bundle exec rake gitlab:setup RAILS_ENV=production
sudo cp lib/support/init.d/gitlab /etc/init.d/gitlab
sudo chmod +x /etc/init.d/gitlab
sudo update-rc.d gitlab defaults 21
sudo cp lib/support/logrotate/gitlab /etc/logrotate.d/gitlab

Vérification et démarrage

sudo -u gitlab -H bundle exec rake gitlab:env:info RAILS_ENV=production
sudo service gitlab start

Nginx

sudo apt-get install -y nginx
sudo cp lib/support/nginx/gitlab /etc/nginx/sites-available/gitlab
sudo ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab

On met à jour le /etc/nginx/sites-available/gitlab


server unix:$InstDir/gitlab/tmp/sockets/gitlab.socket;
server_name gitlab.olivierlocard.com;
root $InstDir/gitlab/public;

Enfin, on peut relancer le service.

sudo service nginx restart

Sources :
http://doc.gitlab.com/ce/
https://www.gitlab.com/downloads/

9 réflexions au sujet de « Installation de GitLab sur Debian »

    • Désolé de répondre avec autant de latence. Période de vacances…

      L’utilisateur gitlab n’a pas les droits pour créer le répertoire gitlab-shell là où vous le souhaitiez. Etant donné que je ne sais pas exactement où vous comptiez installer ce shell, je vais présenter une solution en espérant que vous puissiez vous en inspirer.

      J’ai pour habitude de mettre un propriétaire (owner) aux objets de mon application, et pour cette installation, le profil gitlab. Mais d’un autre côté, je suis farouchement opposé aux méthodes « met tout en 777 » (en référence à un sudo chmod 777 *).
      Pour ma part, j’ai pris l’habitude d’installer ces applications à l’installation délicate (ne relevant pas d’un simple apt-get install ou aptitude install) dans le répertoire /opt . Et pour « ouvrir » les droits à un groupe dédié, j’ai créé un groupe d’utilisateur opt que j’ai affecté avec des droits +rwx sur le répertoire /opt.

      Enfin, j’ajoute les propriétaires de ces applications dans ce groupe. Dans notre exemple gitlab est dans le groupe opt ayant les droits suffisants.

      Aucune idée si c’est une meilleure pratique (best practice) mais c’est ainsi que je procède.

  1. Tout d’abord pour ce tuto très clair c’est agréable.

    En le suivant j’ai eu une erreur au moment d’effectuer le `bundle install` de gitlab.
    Could not find modernizr-2.6.2 in any of the sources

    Après recherche c’est un problème courant (https://github.com/gitlabhq/gitlabhq/issues/6687) et pour ma part le remplacement de modernizr 2.6.2 par modernizr 2.7.1 comme décrit ici : https://github.com/gitlabhq/gitlabhq/issues/6687 a fonctionné 🙂

    Je laisse l’info pour les prochains.

    Encore merci

  2. Bonjour,

    Très bon tutoriel, bien détaillé et tout ça fais plaisir 🙂

    En revanche, j’ai suivi deux tutos en parallèle et une erreur m’arrive en plain dans la face (http://prntscr.com/81uuff) lors de l’execution de la commande « sudo -u gitlab -H bundle exec rake gitlab:check RAILS_ENV=production ».

    Merci de bien vouloir m’aider ! 😉

    Cordialement, Cyril.

    • Désolé de répondre avec une telle latence. Votre commentaire pertinent était caché dans une forêt d’inepties.

      Et malheureusement, je ne peux vous répondre avec précision dans la mesure où cela fait bien longtemps que j’ai réalisé ce projet. Je suis passé à une installation par Puppet (Cf. mon projet G10B), pour abandonner Gitlab que je juge bien trop gourmand pour un service de repo personnel.

      Je vous propose donc une piste à explorer: a priori l’erreur provient d’une double quotes ajoutée autour de « project ». Auriez-vous redéfini un nommage ? Dans les yamls ?
      Un grep -R "project" ${InstDir} (par défaut /opt) pourrait vous aider à le déloger.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *