Qu’est-ce que GitLab ?
GitLab 28.06.2023
Comment déployer GitLab self-managed sur les plateformes cloud ?
GitLab peut être installé sur Amazon Web Services, Google Cloud Platform, Microsoft Azure et d’autres systèmes compatibles Linux.
Cet article présente les différentes méthodes pour installer GitLab sur des plateformes cloud spécifiques. Nous expliquons également comment déployer facilement la solution pour les entreprises comptant jusqu’à 500 utilisateurs, en fonction de leurs besoins précis. Pour maîtriser les fondamentaux de la plateforme avant tout déploiement, n’hésitez pas à consulter notre présentation détaillée sur ce qu’est GitLab.
Voici les principales méthodes d’installation disponibles :
Package Linux officiel
GitLab recommande l’utilisation du package Linux Omnibus pour déployer efficacement une version autonome de GitLab sur diverses plateformes cloud telles que GCP, AWS et Azure. Cette méthode est adaptée pour un maximum de 1 000 utilisateurs. Elle garantit la mise en œuvre rapide et fiable d’une plateforme DevSecOps complète, conçue pour optimiser les bonnes pratiques du cycle de vie du développement logiciel (SDLC). Le package Omnibus intègre tous les services et outils nécessaires pour assurer un fonctionnement ininterrompu, une administration simplifiée et des mises à jour régulières.
Architectures de référence
GitLab a développé et testé des architectures de référence uniques, optimisées pour des déploiements à grande échelle. Ces packages d’architectures de référence peuvent répondre aux besoins de nombreux utilisateurs — de 1 000 à 50 000. Toutefois, si votre objectif est de concevoir un environnement pour un nombre plus restreint d’utilisateurs (jusqu’à 3 000), nous vous recommandons d’utiliser une autre méthode. En effet, l’architecture de référence impose un équilibre de haute disponibilité pour que chaque composant du système GitLab reste opérationnel en cas de panne grâce à différents mécanismes. Atteindre ce niveau de résilience est complexe, et la mise en place d’un tel environnement s’avère particulièrement chronophage et exigeante. Pour des configurations aussi complexes, la gestion des rôles personnalisés GitLab devient un élément essentiel pour maintenir un contrôle d’accès sécurisé.
Chart Helm GitLab (Kubernetes)
Le Chart Helm intègre tous les composants nécessaires pour un démarrage rapide et peut s’adapter à des déploiements de grande envergure. Si vous prévoyez d’installer GitLab sur la plateforme OpenShift, il est recommandé d’utiliser l’Opérateur GitLab. Dans les autres cas de figure, vous devrez configurer vous-même les restrictions du contexte de sécurité. Cependant, GitLab ne recommande pas cette approche pour les environnements de production, car elle déploie l’ensemble des services GitLab au sein d’un même cluster. Pour garantir un fonctionnement optimal et fiable de GitLab, des composants tels que PostgreSQL ou Gitaly doivent être exécutés en dehors du cluster. Cette configuration assure l’évolutivité et la fiabilité de la gestion des charges de travail dans l’environnement GitLab. Si vous utilisez Kubernetes, GitLab conseille de déployer l’architecture de référence dédiée à Kubernetes, appelée Cloud Native Hybrid.
Cloud Native Hybrid
Cette approche repose sur une architecture de référence avec une différence majeure : afin de garantir les performances optimales de vos workflows, tous les services ne sont pas placés au sein du même cluster. L’ensemble des composants de stockage de données doit fonctionner en dehors du cluster. GitLab développe activement l’Infrastructure as Code (IaC), ce qui vous permet de personnaliser l’association du Chart Helm avec des infrastructures cloud supplémentaires telles que Google Kubernetes Engine (GKE) ou Amazon Elastic Kubernetes Service (EKS), offrant ainsi une flexibilité et une évolutivité accrues lors du déploiement.
Comment installer GitLab et configurer les paramètres de base pour démarrer ?
Nous nous concentrerons sur la méthode la plus simple et la plus courante : le package officiel pour Linux.
GitLab self-managed se décline en deux éditions :
- GitLab CE (Community Edition).
- GitLab EE (Enterprise Edition).
Ces deux éditions présentent de légères différences et restent gratuites tant que vous n’achetez pas de licence. La différence majeure réside dans le fait que GitLab CE est une version gratuite qui ne peut pas recevoir de licence. Par conséquent, si votre entreprise prévoit d’utiliser des fonctionnalités payantes, il est recommandé d’installer directement GitLab EE afin d’éviter les coûts liés à une future migration.
Pour commencer, il faut choisir le serveur sur lequel GitLab sera déployé. Voici les recommandations de GitLab concernant le choix d’un serveur sur les plateformes AWS, GCP et Azure :
Compte tenu des spécifications recommandées par GitLab pour une machine opérationnelle et de leur suggestion d’ajouter 2 Go d’espace SWAP, nous vous conseillons de choisir un appareil doté d’au moins 8 Go de RAM et d’ajouter 4 Go d’espace SWAP pour garantir une administration fluide. Lors de l’installation et des mises à jour du système, une charge importante peut interrompre le processus. Le temps gagné en évitant de résoudre de tels problèmes justifie largement la différence de prix de la machine. Une fois la machine créée avec le système d’exploitation choisi, par exemple Ubuntu 22.04, nous commençons l’installation et la configuration des dépendances requises.
Nous commençons par installer et configurer les dépendances appropriées.
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install -y curl openssh-server ca-certificates tzdata perl
Conformément aux recommandations de GitLab, l’étape suivante consiste à installer Postfix pour envoyer des notifications par e-mail. Toutefois, si vous préférez utiliser un autre outil, vous pouvez ignorer cette étape et configurer un serveur SMTP externe après l’installation de GitLab. Vous trouverez des instructions détaillées sur la configuration de cette option dans la documentation de GitLab.
sudo apt-get install -y postfix
Ensuite, Postfix ouvre l’écran de configuration où nous devons sélectionner le type de site web :
Ensuite, nous spécifions le domaine de notre GitLab <gitlab.example.com> :
Pour toutes les autres questions, cliquez sur OK pour accepter toutes les valeurs par défaut.
Ajoutez et installez le dépôt de packages GitLab.
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
Ensuite, installez GitLab.
sudo apt-get install gitlab-ee
Après l’installation, un mot de passe pour l’utilisateur root sera automatiquement généré et stocké pendant 24 heures dans /etc/gitlab/initial_root_password.
Attention : il est fortement recommandé de modifier le mot de passe immédiatement après l’installation.
À ce stade, nous allons configurer et activer le pare-feu de votre système d’exploitation, en supposant que vous utilisez Ubuntu 22.04. Si vous avez déjà accès au serveur, vous pouvez ignorer cette étape.
Tout d’abord, nous devons accorder les droits d’accès au serveur :
1| sudo ufw allow http
2| sudo ufw allow https
3| sudo ufw allow OpenSSH
Activez le pare-feu :
sudo ufw enable
Ouvrez maintenant le fichier de configuration de GitLab pour le modifier. Le fichier de configuration gitlab.rb se trouve dans /etc/gitlab/gitlab.rb :
sudo vim /etc/gitlab/gitlab.rb
ou
sudo nano /etc/gitlab/gitlab.rb
Vous devez spécifier votre adresse IP sur la ligne suivante :
external_url <‘http://51.120.241.152’>
sudo gitlab-ctl reconfigure
Vous devez ensuite attendre le message suivant, ce qui peut prendre un certain temps :
Une fois cette procédure de reconfiguration terminée, accédez à votre adresse IP et vérifiez que GitLab est correctement installé et opérationnel :
Retournez ensuite dans le fichier de configuration gitlab.rb et apportez les modifications suivantes, en ajustant les lignes nécessaires :
sudo vim /etc/gitlab/gitlab.rb
ou
sudo nano /etc/gitlab/gitlab.rb
external_url — le domaine du serveur sur lequel GitLab est installé. Vérifiez bien qu’il indique https://
- letsencrypt[‘enable’]= true – utilisation du certificat Let’s Encrypt
- letsencrypt[‘contact_emails’] – adresse e-mail pour l’enregistrement
- letsencrypt[‘auto_renew’]= true – renouvellement automatique du certificat Let’s Encrypt
- letsencrypt[‘auto_renew_hour’]= “12” – heure de renouvellement
- letsencrypt[‘auto_renew_minute’]= “30” – minute de renouvellement
Assurez-vous que les modifications dans le fichier gitlab.rb ressemblent à ceci. Notez que ce fichier étant assez volumineux, ces différentes lignes peuvent être éloignées les unes des autres.
external_url ‘https://gitlab.example.com’
letsencrypt[‘enable’] = true
letsencrypt[‘contact_emails’] = [‘example@com’]
letsencrypt[‘auto_renew’] = true
letsencrypt[‘auto_renew_hour’] = “12”
letsencrypt[‘auto_renew_minute’] = “30”
letsencrypt[‘auto_renew_day_of_month’] = “*/7”
Enregistrez vos modifications et appliquez-les :
sudo gitlab-ctl reconfigure
Après avoir reçu ce message, ce qui peut nécessiter un certain temps d’attente, notamment en cas d’erreur 502, vous pourrez vous connecter à GitLab avec succès.
Le mot de passe généré se trouve dans le fichier correspondant de GitLab.
sudo cat /etc/gitlab/initial_root_password
Nous obtenons le résultat suivant :
Dans le champ Username or email, saisissez l’utilisateur root, et dans le champ Password, entrez le mot de passe figurant dans le fichier /etc/gitlab/initial_root_password. Une fois l’authentification réussie, nous pouvons accéder à notre compte GitLab.
Il est essentiel de modifier votre mot de passe immédiatement ! Pour ce faire, accédez à votre profil en cliquant sur votre avatar dans le coin supérieur droit de l’écran.
Cliquez sur Edit profile -> Password.
L’installation de GitLab est désormais terminée. Passons maintenant aux paramètres supplémentaires. Comme le montre l’exemple, GitLab permet de désactiver la création de nouveaux comptes pour toute personne connaissant notre domaine. Par défaut, n’importe qui peut créer un compte (bien que l’administrateur doive encore l’approuver).
Décochez la case :
Vous pouvez également configurer immédiatement une autorisation d’inscription pour votre organisation :
Cliquez sur Save changes.
Un GitLab vide consomme les ressources suivantes :
Vous pouvez désormais profiter pleinement des fonctionnalités de GitLab. Il ne vous reste plus qu’à configurer le serveur SMTP pour recevoir correctement les notifications, et vous serez prêt à construire votre espace de travail. Vous avez ainsi finalisé une installation qui répond globalement aux besoins de la plupart des entreprises.
Conclusion
Le choix entre le déploiement d’un GitLab self-managed sur des plateformes cloud telles que GCP, AWS et Azure, et l’utilisation de la version SaaS, dépend de l’entreprise cliente. Il faut notamment tenir compte des exigences légales de certains pays concernant le stockage des projets dans le cloud. Toutefois, si aucune restriction légale ne s’y oppose, nous privilégions la version SaaS de GitLab.
Cette approche présente plusieurs avantages indéniables :
- Réduction des coûts de maintenance de l’infrastructure cloud.
- Gain de temps et d’efforts généralement nécessaires à l’administration du système.
- Élimination des configurations complexes, souvent chronophages et coûteuses.
- Configuration automatique du SMTP pour les notifications.
- Accès continu aux mises à jour et aux autres avantages de la plateforme.
Cependant, GitLab self-managed reste une option viable. Il exige simplement plus d’attention, d’efforts et de ressources pour être pleinement efficace. Cette version convient particulièrement aux entreprises ayant des exigences spécifiques, des normes de sécurité strictes ou un besoin de contrôle absolu sur leurs données.
GitLab et Cloudfresh
Cloudfresh est un partenaire GitLab certifié pour le conseil, le support et l’implémentation. Nous aidons les entreprises à tirer le meilleur parti des solutions GitLab. Grâce à notre expertise, des centaines d’équipes optimisent leur SDLC. Découvrez nos services professionnels GitLab.
Nos experts GitLab vous conseillent, pilotent et déploient des services d’implémentation GitLab de haute qualité, et assurent le support technique de vos projets de migration GitLab.
Utilisez ce lien pour bénéficier d’un essai gratuit de 30 jours des licences GitLab self-managed, incluant un onboarding professionnel, des conseils, une expertise et le support technique de Cloudfresh.
Accélérons ensemble votre transformation DevSecOps !
