De la destruction d'un disque dur au déploiement d'un serveur gitlab
Qu'est ce que Gitlab?
Il s'agit d'une plateforme permettant aux développeurs d'échanger leurs modifications de code source, de le versionner, mais également de discuter autour du travail de chacun.
Gitlab propose également un accès facile à tout un tas d'outils servant à lancer plusieurs opérations programmées lorsqu'un développeur publie son travail. On parle ici d'intégration continue, qui correspond à la partie gauche de l'image.
Un développeur programme dans le langage de son choix, publie son code sur gitlab. Son code est compilé, et testé.
Dans partie droite de l'image, on trouve la partie déploiement continu. Toujours dans gitlab, les tâches prévues lors d'une publication de code source peuvent également être la création d'une image docker, la publication de cette image dans un registry de notre choix, puis son déploiement sur un CaaS comme Kubernetes, ou un PaaS comme Openshift, cette introduction à gitlab se perd et est beaucoup trop longue.
Bref, Gitlab est un outil extrêmement puissant, proposant un grand nombre de fonctionnalités essentielles aux développeurs d'aujourd'hui.
Ces fonctionnalités sont gratuites et disponibles directement sur gitlab.com. Quelle peut donc être l'utilité d'en déployer une instance chez soi dans ce cas là? Déjà c'est très intéressant (c'est ce qui m'a motivé initialement à me lancer). J'ai pu apprendre beaucoup de choses sur le fonctionnement de Nginx, let's encrypt avec Certbot, ainsi que la manière de configurer de zéro une instance gitlab. Mais c'est surtout la garantie d'héberger son code source chez soi, et donc d'être sûr de ce qui lui arrive.
En effet sur gitlab, on trouve la notion de projet ou groupe privé. Cela permet de garantir que son code ne soit visible que par soi ou ses collaborateurs, et donc pas n'importe quel autre développeur. Mais cela a ses limites en terme de quota, et héberger son instance permet de s'en affranchir totalement.
Bon et le disque dur dans le titre alors, quel rapport?
Et bien la semaine dernière, j'ai décidé de commencer à me pencher sur le comment de cette mise en ligne de mon instance gitlab. J'ai effectué l'installation sur un raspberry pi 4 4GB:
La page consacrée à l'installation sur ce périphérique mentionnait l'utilisation préférentielle d'un disque dur externe pour le stockage des données (pas directement sur la carte SD). Je me suis donc mis en quête d'un disque dur fonctionnel, et je me suis souvenu de ma commande de 2017 d'un disque dur qui dans mes souvenirs n'avait jamais fonctionné. Je l'ai retrouvé, et il ne m'a pas fallu longtemps (après de nombreuses tentatives de fsck et de repartitionnement avec gparted) pour arriver à ce résultat:
Après avoir donc pu contempler l'intérieur d'un disque dur (magnifique), j'ai commandé un nouveau disque Maxtor de 1TO, qui avait de très bons avis.
C'est là que la partie plus technique commence.
Le déploiement du service
Le déploiement du service sur un raspberry pi 4 (4GB) est assez rapide. Il suffit de se rendre sur cette page, et de récupérer la dernière version du paquet (récupérer la commande wget en bas de la page à droite, et l'exécuter dans un terminal sur le raspberry (en ssh par exemple).
Il est recommandé, d'après cette page, d'installer les données de gitlab sur un disque dur externe, la carte SD n'étant pas une source de données fiable dans le temps. Pour ce faire, j'ai donc connecté mon nouveau disque dur de 1TO, et j'ai modifié le fichier /etc/fstab servant à indiquer les volumes à monter au démarrage du système, en ajoutant cette ligne:
PARTUUID=76e43493-01 /var/opt/gitlab ext4 defaults,noatime 0 1
Le paramètre "PARTUUID" est l'identifiant de la partition à monter, et peut être trouvé grâce à la commande blkid:
/dev/sda1: LABEL="storage" UUID="76df910e-9801-88de-aadf-67efcd6728da" TYPE="ext4" PARTUUID="76e43493-01"
Pour appliquer les changements faits dans fstab sans redémarrer, et surtout vérifier que la configuration est bonne, il est important d'appliquer sa configuration grâce à mount -a. Si la configuration fstab est mauvaise, il sera impossible de faire booter à nouveau le raspberry.
Une fois tout cela fait, il ne reste plus qu'à installer le paquet debian de gitlab:
sudo dpkg -i LeFichierObtenuGrâceAWget
permet de lancer l'installation de l'instance Gitlab.
Une fois l'installation terminée, j'ai fini d'appliquer les conseils restants donnés sur cette page, et j'ai finalement pu me connecter à mon instance gitlab.
Il restait tout de même un problème, gitlab expose son propre serveur nginx, hors j'en avais déjà un actif pour le frontend de ce blog. J'ai donc du mettre en place de nouvelles routes en m'inspirant de ce fichier de configuration.
Au final, la partie qui m'aura demandé le plus de temps aura été la configuration de nginx, mais également l'activation du registry pour le stockage de mes images docker.
