GitLab est une plate-forme leader pour l’hébergement de référentiels Git, de pipelines CI et de flux de travail DevOps. Il est disponible en tant qu’offre SaaS sur GitLab.com ou en tant que distribution autogérée pour un usage privé sur votre propre matériel.
GitLab est un système complexe formé d’un réseau de composants et de dépendances distincts. L’installation de packages GitLab directement sur votre système d’exploitation ajoutera de nouveaux services importants à votre machine, notamment PostgreSQL, Redis, Gitaly et la principale application Web GitLab basée sur Rails.
Déployer GitLab en tant que conteneur Docker est un moyen d’éviter de polluer votre environnement avec tous ces composants. Tout ce qui concerne GitLab vivra dans le conteneur, séparément du système de fichiers de votre hôte.
Dans ce guide, nous utiliserons Docker pour déployer une instance GitLab prête pour la production que vous pourrez utiliser pour héberger votre code source et collaborer sur des projets. Une chose à considérer avant de continuer est que Docker n’élimine pas les exigences matérielles de base de GitLab : vous aurez besoin d’au moins 4 Go de RAM libre et d’environ 10 Go de stockage inutilisé.
L’image Docker officielle
GitLab propose une image Docker pré-construite qui contient tout ce dont vous avez besoin pour déployer le logiciel. Nous nous concentrons sur cette image dans ce didacticiel, mais il convient de prêter attention à ses limites.
L’image est de nature monolithique, regroupant tous les composants GitLab afin qu’ils s’exécutent dans un seul conteneur. Cela simplifie la configuration, mais complique la mise à l’échelle de votre installation à l’avenir. Cela va à l’encontre des meilleures pratiques de conteneurisation en exécutant plusieurs composants distincts dans le conteneur.
Cela signifie que l’image de stock peut ne pas être idéale pour les installations occupées. Comme alternative, vous pouvez utiliser le graphique Helm de GitLab pour déployer sur un cluster Kubernetes. Cela lance chaque service en tant que son propre pod conteneurisé afin que vous puissiez mettre à l’échelle les composants individuellement.
Déployer GitLab avec Docker
Installez Docker et configurez un enregistrement DNS A pour votre nom de domaine GitLab avant de continuer. Vous devez faire pointer l’enregistrement DNS vers l’adresse IP de votre hôte Docker. Nous utiliserons gitlab.example.com comme domaine dans le reste de ce guide.
Vous pouvez démarrer GitLab en exécutant la commande suivante :
docker run -d -p 22:22 -p 80:80 -p 443:443
--name gitlab
--hostname gitlab.example.com
--restart unless-stopped
--shm-size 256m
-v gitlab_config:/etc/gitlab
-v gitlab_logs:/var/log/gitlab
-v gitlab_data:/var/opt/gitlab
gitlab/gitlab-ce:14.7.0-ce.0
Docker téléchargera l’image GitLab Community Edition (CE) et démarrera un nouveau conteneur en l’utilisant. Il est recommandé d’épingler une version spécifique de GitLab en sélectionnant sa balise d’image correspondante, 14.7.0-ce.0 dans ce cas. Voici une explication des drapeaux utilisés dans la commande :
-d– Détachez le terminal du conteneur pour qu’il s’exécute en arrière-plan.-p– Liez les ports 22, 80 et 443 du conteneur aux ports correspondants sur votre hôte ; cela permet à GitLab de recevoir le trafic Git et Web via SSH et HTTP/S lorsqu’il est dirigé vers votre hôte.--name– Attribuez au conteneur un nom convivial afin de pouvoir le référencer facilement lors de l’exécution future des commandes Docker CLI.--hostname– Définissez le nom d’hôte du conteneur ; cela doit correspondre au domaine que vous utilisez pour accéder à GitLab.--restart– Attribuez au conteneur une stratégie de redémarrage afin qu’il soit automatiquement redémarré lorsqu’il se termine en raison d’une panne ou d’un redémarrage de l’hôte.--shm-size– Ceci est expliqué dans la section suivante.-v– Configurez des volumes Docker pour stocker de manière persistante les fichiers de configuration, les journaux et les données utilisateur générées de GitLab en dehors du conteneur. C’est vital pour ne pas perdre vos données lorsque le conteneur s’arrête !
Attendez quelques minutes pour que la configuration de la première exécution de GitLab se termine. A terme, vous devriez pouvoir visiter gitlab.example.com pour voir la page de connexion. Se connecter en tant que root; le mot de passe du compte est automatiquement généré et peut être récupéré en exécutant la commande suivante :
docker exec -it <gitlab-container-name> grep 'Password:' /etc/gitlab/initial_root_password
Remplacer <gitlab-container-name> avec le nom que vous avez attribué lors de la création de votre conteneur. C’était gitlab dans l’exemple ci-dessus.
Examen des problèmes de déploiement
Il est normal que les scripts d’installation prennent beaucoup de temps à se terminer. GitLab a beaucoup de composants à configurer avant que le service puisse commencer à fonctionner. Vous pouvez surveiller la progression en consultant les journaux du conteneur :
docker logs gitlab --follow
Le meilleur plan d’action si l’interface utilisateur Web de GitLab n’est pas disponible est simplement d’attendre un peu plus longtemps et de laisser la procédure de configuration se terminer. Si quelque chose s’est mal passé, vous voyez 500 erreurs dans votre navigateur et les journaux du conteneur n’affichent aucune nouvelle activité, en redémarrant le conteneur avec docker restart gitlab peut parfois aider.
Un message d’erreur courant que vous pouvez voir dans les journaux ressemble à ceci :
writing value to /dev/shm/gitlab/... failed with unmapped file
Cela se produit parce que les services fournis avec GitLab écrivent des quantités importantes de données sur le /dev/shm système de fichiers. Docker alloue uniquement des conteneurs a /dev/shm espace de 64 Mo par défaut. C’est rarement suffisant pour maintenir la collecte de métriques de GitLab via Prometheus, responsable de la plupart des écritures sur le système de fichiers.
La capacité de /dev/shm peut être augmenté à l’aide de --shm-size drapeau lorsque vous créez votre conteneur avec docker run. Ceci est illustré dans l’exemple de déploiement ci-dessus où 256 Mo sont alloués, le minimum recommandé par GitLab. Les installations très actives peuvent avoir besoin d’utiliser une taille plus grande.
Un autre problème concerne les fichiers journaux de GitLab : ils deviennent rapidement volumineux, ce qui peut entraîner buffer overflow detected erreurs lors du démarrage de Docker. Cela peut être évité en effaçant périodiquement les anciens fichiers du /var/log/gitlab répertoire depuis votre conteneur GitLab :
docker exec -it gitlab rm /var/log/gitlab/*
Les fichiers journaux que Docker collecte à partir des flux de sortie du conteneur et les conservent sur votre hôte atteindront également rapidement des tailles importantes. La valeur par défaut de Docker json-file le pilote de stockage de journaux n’est pas adapté à une utilisation avec une instance GitLab de production. Les fichiers JSON qu’il crée sont lourds, verbeux et jamais compressés ni pivotés. Basculez vers un autre pilote de stockage tel que local ou journald pour assurer une rotation régulière des journaux.
Configuration de GitLab
Vous pouvez fournir des extraits de fichier de configuration GitLab lorsque vous créez votre conteneur en définissant le GITLAB_OMNIBUS_CONFIG variables d’environnement. Il doit s’agir d’une chaîne Ruby valide qui sera ajoutée au /etc/gitlab/gitlab.rb fichier à l’intérieur du conteneur :
docker run -e GITLAB_OMNIBUS_CONFIG="gitlab_rails['allowed_hosts'] = ['gitlab.example.com]; nginx['redirect_http_to_https'] = true;"
Vous pouvez également modifier /etc/gitlab/gitlab.rb depuis l’intérieur du conteneur une fois qu’il est en cours d’exécution. Lorsque vous avez terminé d’apporter des modifications, vous devez redémarrer le conteneur pour les appliquer :
docker restart gitlab
L’image GitLab Docker exécute automatiquement le script de reconfiguration Omnibus à chaque démarrage. Cela prend la configuration actuelle de votre gitlab.rb et l’applique à votre installation. Il est normal que GitLab soit inaccessible pendant quelques secondes après le redémarrage de votre conteneur pendant que ce processus se termine.
Application des mises à jour GitLab
Les mises à jour de GitLab sont facilement appliquées en arrêtant votre conteneur et en en démarrant un nouveau avec la même configuration.
Extrayez la nouvelle image correspondant à la version de GitLab que vous avez choisie :
docker pull gitlab/gitlab-ce:14.7.1-ce.0
Supprimez votre conteneur existant :
docker rm gitlab
Enfin, démarrez un nouveau conteneur, en répétant vos drapeaux d’origine mais en modifiant la référence de l’image :
docker run -d -p 22:22 -p 80:80 -p 443:443
--name gitlab
...
gitlab/gitlab-ce:14.7.1-ce.0
Vos données seront intactes car les volumes de l’ancien conteneur seront rattachés au nouveau.
Vous pouvez éviter la répétition de votre docker run flags en encapsulant votre configuration dans un docker-compose.yml fichier:
version: "3" services: gitlab: image: gitlab/gitlab-ce:14.7.0-ce-0 hostname: gitlab.example.com ports: - 22:22 - 80:80 - 443:443 volumes: gitlab_config:/etc/gitlab gitlab_logs:/var/log/gitlab gitlab_data:/var/opt/gitlab restart: unless-stopped volumes: gitlab_config: gitlab_logs: gitlab_data:
Lorsque vous utilisez Docker Compose, vous pouvez afficher votre instance GitLab en exécutant docker-compose up -d. Pour mettre à jour vers une nouvelle version, modifiez le image champ en conséquence et répétez la commande. Docker Compose automatisera le processus de remplacement des conteneurs.
Quel que soit le mécanisme que vous utilisez, il est important de vous assurer que vos chemins de mise à niveau s’alignent sur les routes prises en charge par GitLab. Parfois, vous devrez peut-être effectuer des actions manuelles après la mise à niveau pour terminer la migration.
Sauvegarde de votre installation
Des sauvegardes régulières sont essentielles pour un déploiement réussi de GitLab. Le rôle typique de GitLab en tant que source unique de vérité de votre organisation signifie que dans le pire des cas, tout votre travail pourrait disparaître à jamais à moins que des sauvegardes ne soient effectuées.
GitLab dispose d’un utilitaire de sauvegarde intégré qui peut être utilisé pour créer une archive complète de votre installation. Ceci est accessible dans l’image Docker via le gitlab-backup commander:
docker exec -t gitlab gitlab-backup create
Les sauvegardes sont enregistrées dans le /var/opt/gitlab/backups répertoire par défaut. Cela signifie qu’ils seront stockés à l’extérieur du conteneur, dans l’un de vos volumes Docker montés. Pour plus de sécurité, vous devez configurer GitLab pour télécharger des sauvegardes vers un fournisseur de stockage d’objets distant en ajoutant ces lignes à votre fichier de configuration :
gitlab_rails['backup_upload_connection'] = "provider" => "AWS", "region" => "eu-west-1", "aws_access_key_id" => "access_key", "aws_secret_access_key" => "secret_key", # "endpoint" => "https://..."
Maintenant le gitlab-backup create chargera automatiquement les fichiers d’archive qu’elle génère, en les séparant de votre conteneur GitLab et de votre hôte Docker. Votre dernière étape devrait être d’ajouter un cron tâche sur votre système qui exécute périodiquement le script de sauvegarde :
0 * * * * docker exec -t gitlab gitlab-backup create
Sommaire
GitLab est un logiciel complexe qui se déploie facilement avec Docker. le docker run L’exemple présenté dans ce guide convient à une utilisation en production lorsqu’il est combiné avec les changements de configuration des meilleures pratiques expliqués ci-dessus. Vous devez également auditer la sécurité du démon Docker et de votre hôte pour vous assurer que vos données sont correctement protégées.
Un déploiement Dockerized GitLab est un bon moyen de tester rapidement la plateforme. C’est également une stratégie efficace pour lancer et maintenir un serveur GitLab plus petit pour une utilisation à long terme. D’autres options telles que GitLab Omnibus sur un serveur dédié ou une installation Kubernetes native dans le cloud sont généralement mieux adaptées aux exigences plus importantes et à l’adoption soutenue par les entreprises.