Go to Hackademy website

Installer Gitlab CE et Gitlab CI

Théo Delaune

Posté par Théo Delaune dans les catégories outils

Aujourd’hui, nous allons découvrir ensemble l’installation de Gitlab CE et Gitlab CI.

Gitlab, dans sa version Community Edition est une application permettant gérer des dépôts Git, elle permet d’héberger les dépôts sur un serveur dédié contrairement à ce que propose Github.

Gitlab fourni une interface web conviviale dans laquelle il est possible de naviguer dans le code, suivre les tickets créés, mettre en place un wiki, gérer le rôle et le groupe des utilisateurs, mettre des commentaires sur des commits…

Gitlab propose également un outil d’intégration continue, il permet de lancer des tâches automatisées sur un dépôt pour un événement donné. Il pourra par exemple lancer tout nos tests sur une application Rails à chaque push.

Le but aujourd’hui est de mettre en place l’application Gitlab ainsi que son outil d’intégration continue pour pouvoir jouer les tests d’une application Rails lors de chaque push.

Gitlab CE

Pré-requis

Un utilisateur dédié est nécessaire car lors de l’installation de Gitlab, son répertoire sera utilisé pour vos dépôts Git.

exemple:
Git@Git.domain.tld:synbioz/mon_projet.Git

synbioz représente ici l’utilisateur dédié à l’utilisation de Gitlab, il est donc conseillé de créer un utilisateur pertinent si les dépôts sont publics :

adduser pseudonyme

Installation

Depuis quelques mois Gitlab propose une installation via un package en .deb (ubuntu, debian). C’est celui-ci que nous utiliserons aujourd’hui.

Pour l’installation je vous invite à vous rendre sur la page de téléchargement de Gitlab et à sélectionné votre système actuel.

Mise en place de Gitlab pour un système Debian

# Script permettant d'ajouter gitlab comme source de paquets.
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

# installation de gitlab ce
sudo apt-get install gitlab-ce

Mise en route

Pour que Gitlab soit pleinement opérationnel, il faut modifier le fichier /etc/gitlab/gitlab.rb pour y spécifier l’adresse http de ce dernier :

# /etc/gitlab/gitlab.rb
external_url 'http://git.domain.tld'

Nous pouvons maintenant lancer le service de configuration de Gitlab qui lancera par la même occasion l’application :

sudo gitlab-ctl reconfigure

Une fois la configuration chargée il ne reste plus qu’à se connecter sur le Gitlab fraîchement installé. Les identifiants de base sont :

  • identifiant: root
  • password: 5iveL!fe

Une fois connecté voici la page qui sera présentée. Elle permet de créer de nouveaux projets et donc de les héberger sur la plate-forme nouvellement crée.

GitlabCE

Pour aller plus loin

Après avoir découvert toute l’étendu des possibilités offertes par Gitlab et dans l’optique de l’utiliser en production, je vous conseille vivement de mettre en place des certificats pour que Gitlab soit en https.

Par ailleurs, il ne faut pas oublier de configurer le serveur smtp pour l’envoi des emails de notification.

Ces deux configurations pourront se retrouver dans le fichier /etc/gitlab/gitlab.rb. Il faut relancer l’outil de configuration de Gitlab après chaque changement dans ce fichier :

sudo gitlab-ctl reconfigure

Gitlab CI

Pré-requis

L’outil Gitlab CI a besoin d’un service dit runner, ce service va effectuer chaque test de commit en arrière plan.

Ce service utilise Docker, il doit être installé sur le serveur :

curl -sSL https://get.docker.com/ | sh

Une fois Docker installé, veillez à ce qu’il soit bien démarré pour la suite de notre article.

# Vérifier si le service est démarré
service docker status

# Lancer le service si il n'est pas démarré
service docker start

Configuration

Gitlab CI fait parti de l’application Gitlab CE depuis quelques versions. Il faut donc l’activer au sein du fichier de configuration Gitlab : /etc/gitlab/gitlab.rb

# Proche de la ligne 415 du fichier

# Décommenter et compléter avec l'url souhaitée pour cet outil
ci_external_url 'http://ci.domain.tld'

Reconfigurer Gitlab:

sudo gitlab-ctl reconfigure

Nous avons maintenant accès à notre page http://ci.domain.tld qui indique les étapes à suivre pour lier Gitlab CE avec Gitlab CI.

Depuis Gitlab CE, il faut se rendre dans la section Administration -> Applications ou http://git.domain.tld/admin/applications.

Il est nécessaire d’ajouter une url de retour pour que Gitlab CI fasse la relation avec Gitlab CE.

Créer une nouvelle application:

  • name: gitlab ci
  • redirect URI: http://ci.domain.tld/user_sessions/callback

Une fois cette redirection créée, il faut modifier le fichier /etc/gitlab/gitlab.rb en y ajoutant l’app_id et le secret_id fourni lors de la création de l’application gitlab ci :

# Proche de la ligne 422

# Compléter avec le app_id et le secret_id
gitlab_ci['gitlab_server'] = { "url" => 'http://git.domain.tld', "app_id" => 'APP_ID', "app_secret" => 'APP_SECRET' }

Une page similaire à celle-ci devrait être visible lorsque vous vous connecterez à l’application web de CI http://ci.domain.tld:

GitlabCI

Nous devons synchroniser les projets pour pouvoir les ajouter sur ce nouvel outil d’intégration continue.

Il ne manque plus qu’un runner pour faire tourner les tests sur Gitlab CI.

Mise en place d’un runner

Nous allons pour cela utiliser gitlab-ci-multi-runner qui est un exécutable permettant de lancer les tests et de choisir sous quelle forme le lancer.

Voici la procédure d’installation de cet exécutable :

Script permettant d'ajouter le runner comme source pour vos paquets.
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb | sudo bash

# Installation
apt-get install gitlab-ci-multi-runner

# Configuration
cd ~gitlab_ci_multi_runner

gitlab-ci-multi-runner register

Pour l’enregistrement d’un runner, pour ce tutoriel nous utiliserons l’executor de type docker qui est le plus propre car il permet de bien cloisonné notre runner.

Le token demandé pour le runner se trouve sur la page d’administration de Gitlab CI: http://ci.domain.tld/admin/runners

Pour utiliser un MySQL ou PostgreSQL il suffit de donner le numéro de version souhaité ou tout simplement de demander la dernière version en spécifiant latest. Dans le cas où ces services ne sont pas nécessaires vous pouvez passer à l’étape suivant en utilisant la touche Enter.

Une fois ce runner configuré il est possible de le lancer avec la commande :

gitlab-ci-multi-runner run

Configuration des jobs

Il faut préalablement ajouter un projet à l’outil de CI, au niveau de la page principale synchroniser depuis le Gitlab CE et ajouter un projet.

Nous avons besoin de nous rendre sur la page Jobs du projet au sein de Gitlab CI et de compléter ou ajouter un nouveau Job pour que le test d’intégration soit fonctionnel.

Voici une configuration basique pour un projet Rails tournant sur Rspec et sur SQLite:

apt-get update -qq
apt-get install -y -qq cmake nodejs

bundle install
bundle exec rake db:create RAILS_ENV=test
bundle exec rake db:migrate RAILS_ENV=test
bundle exec rspec

Il ne reste maintenant qu’a pusher un nouveau commit sur Gitlab CE pour que celui-ci soit testé dans l’outil d’intégration continue.

Pour allez plus loin

N’oubliez pas de passer Gitlab CI en https si jamais vous l’utilisez intensivement ou pour des projets en production.

Comme pour Gitlab CE toute la configuration se fait au sein du fichier /etc/gitlab/gitlab.rb.

Conclusion

En espérant que cet approche de Gitlab CE et Gitlab CI vous aie plu et vous donne envie de monter votre propre serveur pour gérer vos dépôts Git et votre intégration continue.

Je vous laisse donc découvrir les autres possibilités qu’offre Gitlab CE et CI lors de son utilisation.

L’un des points les plus attirant pour moi est sa mise en place de la livraison continue lors d’un build réussi sur le CI, mais il vous en reste encore plein d’autres à découvrir.


L’équipe Synbioz. Libres d’être ensemble.

Articles connexes

Un plugin Vim à la mimine

03/01/2019

Dans l’article précédent, intitulé une assez bonne intimité, je vous présentais GPG et le chiffrement de courriels. Nous avons alors remarqué que le contenu d’un courriel était encodé de sorte que le...

Une assez bonne intimité

20/12/2018

Si vous êtes utilisateur de MacOS, il y a de fortes chances que vous utilisiez Apple Mail pour échanger des courriels. Et comme vous êtes sensible à la confidentialité des informations que vous...

Tests end to end avec Jest et Puppeteer

05/07/2018

Dans cet article, on va partir sur des tests end to end. Pour planter le décor, un test end to end (e2e) est un test logiciel qui a pour but de valider que le système testé répond correctement à un...

Chasser les requêtes N+1 avec Bullet

05/04/2018

Aujourd’hui nous allons parler des requêtes N+1 dans une application Rails : vous savez ces lignes quasiment identiques, qui s’ajoutent de manière exponentielle aux logs, dès lors que l’on appelle...