Installer et configurer GitLab CE sur VPS Linux

Pour installer GitLab CE sur VPS Linux, il est essentiel de partir sur une base technique robuste : ressources matérielles adaptées, système d'exploitation récent et réseau stable. GitLab Community Edition est une plateforme DevOps open source complète qui intègre dépôt Git, CI/CD, registre de conteneurs et gestion de projet. Ce tutoriel 2026 détaille chaque étape, de la préparation de votre serveur VPS Linux OmegaCloud jusqu'à la mise en production sécurisée de GitLab CE.

Prérequis matériels et système pour installer GitLab CE VPS Linux

GitLab CE requiert des ressources substantielles pour fonctionner correctement. Un VPS avec au moins 4 Go de RAM est le strict minimum pour une instance de test ; pour un usage en production avec plusieurs utilisateurs et pipelines CI/CD actifs, visez 8 Go de RAM ou plus. Le processeur doit disposer d'au moins 2 cœurs dédiés pour garantir la réactivité de l'interface web et l'exécution parallèle des jobs CI/CD.

Côté stockage, GitLab génère de nombreuses données : dépôts Git, artefacts de build, registre Docker, backups. Un volume SSD SAS d'au moins 50 Go est recommandé pour démarrer, avec possibilité d'extension ultérieure. Les VPS OmegaCloud offrent un stockage SSD SAS et des snapshots intégrés, pratiques pour sauvegarder l'état de votre GitLab avant une mise à jour.

Pour le système d'exploitation, GitLab CE supporte officiellement Ubuntu 22.04 LTS, Debian 11/12, Rocky Linux 9 et AlmaLinux 9. Ce tutoriel utilise Ubuntu 22.04 LTS, distribution largement adoptée et documentée. Assurez-vous que le serveur dispose d'un nom de domaine ou sous-domaine pointant vers l'IP publique du VPS, nécessaire pour l'URL externe et le certificat SSL.

Enfin, vérifiez la bande passante et la latence. GitLab héberge des clones de dépôts fréquents et des transferts d'artefacts : une connexion réseau stable avec plusieurs Gbps garantit une bonne expérience utilisateur. Les datacenters OmegaCloud en Europe offrent un uplink redondant et une protection anti-DDoS incluse, évitant les interruptions liées aux attaques volumétriques.

Installation pas à pas de GitLab CE sur Ubuntu 22.04

Mise à jour du système et installation des dépendances

Connectez-vous en SSH avec vos clés d'authentification (désactivez l'authentification par mot de passe pour renforcer la sécurité). Mettez à jour les paquets système avant toute installation :

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl ca-certificates openssh-server postfix tzdata perl

Le paquet postfix permet à GitLab d'envoyer des notifications par email. Lors de l'installation, choisissez « Internet Site » et indiquez le nom de domaine de votre serveur. Le daemon SSH doit être actif ; vérifiez avec sudo systemctl status ssh.

Ajout du dépôt officiel GitLab

GitLab fournit un script Bash qui configure automatiquement le dépôt APT. Téléchargez et exécutez ce script en une commande :

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Ce script ajoute la clé GPG de signature et le fichier de sources dans /etc/apt/sources.list.d/. Vérifiez ensuite que le dépôt est bien disponible avec sudo apt update.

Installation du paquet GitLab CE

Définissez l'URL externe de votre instance via une variable d'environnement, puis installez le paquet. Remplacez gitlab.example.com par votre domaine réel :

sudo EXTERNAL_URL="https://gitlab.example.com" apt install -y gitlab-ce

L'installation dure plusieurs minutes : le paquet configure automatiquement Nginx, PostgreSQL, Redis, Sidekiq et les autres composants. À la fin, GitLab affiche un message de configuration réussie et génère un mot de passe root initial stocké dans /etc/gitlab/initial_root_password. Conservez ce fichier précieusement ou copiez le mot de passe immédiatement.

Première connexion et configuration SSL

Ouvrez votre navigateur et accédez à https://gitlab.example.com. GitLab tente d'obtenir automatiquement un certificat Let's Encrypt si le domaine pointe correctement vers l'IP du VPS et que les ports 80/443 sont ouverts. Si la configuration automatique échoue, éditez /etc/gitlab/gitlab.rb :

external_url 'https://gitlab.example.com'
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['[email protected]']

Puis reconfigure GitLab pour appliquer les changements :

sudo gitlab-ctl reconfigure

Connectez-vous avec le compte root et le mot de passe initial. Changez immédiatement ce mot de passe depuis User Settings → Password. Créez ensuite des comptes utilisateurs nominatifs et désactivez l'inscription publique dans Admin Area → Settings → General → Sign-up restrictions.

Sécurisation et optimisation de votre instance GitLab

Pare-feu et règles réseau

Limitez l'accès réseau aux seuls ports nécessaires. Utilisez ufw (Uncomplicated Firewall) pour configurer des règles simples :

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Le port 22 (SSH) doit rester accessible pour l'administration. Si vous utilisez un port SSH non standard, adaptez la règle en conséquence. L'anti-DDoS volumétrique est géré automatiquement par OmegaCloud au niveau datacenter, transparentent pour votre instance GitLab.

Authentification SSH par clés et 2FA

Désactivez l'authentification par mot de passe SSH dans /etc/ssh/sshd_config :

PasswordAuthentication no
PubkeyAuthentication yes

Rechargez le daemon SSH avec sudo systemctl reload ssh. Pour GitLab, activez l'authentification à deux facteurs (2FA) obligatoire pour tous les utilisateurs : Admin Area → Settings → General → Sign-in restrictions → Require two-factor authentication. Chaque utilisateur devra ensuite enregistrer une application TOTP (Google Authenticator, Authy, etc.) depuis son profil.

Fail2Ban pour limiter les tentatives d'intrusion

Installez Fail2Ban pour bloquer automatiquement les adresses IP qui tentent des connexions SSH en force brute :

sudo apt install -y fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Créez une jail personnalisée dans /etc/fail2ban/jail.local pour protéger également l'interface web de GitLab contre les tentatives de connexion répétées. GitLab enregistre les échecs dans /var/log/gitlab/gitlab-rails/application.log.

Tuning des performances et monitoring

GitLab embarque Prometheus et Grafana pour le monitoring interne. Activez-les dans /etc/gitlab/gitlab.rb :

prometheus_monitoring['enable'] = true
grafana['enable'] = true

Puis sudo gitlab-ctl reconfigure. Accédez à Grafana via https://gitlab.example.com/-/grafana (connexion root/root, changez le mot de passe immédiatement). Le panel OmegaCloud fournit également un dashboard temps réel du VPS : CPU, RAM, SSD, réseau, permettant de détecter les saturations avant qu'elles n'impactent GitLab.

Pour optimiser les ressources, limitez le nombre de workers Sidekiq et Puma dans /etc/gitlab/gitlab.rb si votre VPS dispose de RAM limitée :

puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 10

Appliquez avec sudo gitlab-ctl reconfigure. Surveillez la consommation mémoire avec free -h et ajustez si nécessaire.

Sauvegardes automatiques

GitLab propose un mécanisme de backup intégré. Configurez une cron pour exécuter une sauvegarde quotidienne :

sudo crontab -e

Ajoutez la ligne suivante pour un backup chaque nuit à 2h :

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1

Les archives sont stockées par défaut dans /var/opt/gitlab/backups/. Copiez régulièrement ces backups vers un espace de stockage externe ou utilisez les snapshots OmegaCloud pour capturer l'état complet du VPS en un clic, restaurable en quelques minutes.

Intégration CI/CD et workflows DevOps avancés

Configuration du GitLab Runner

Pour exécuter les pipelines CI/CD, installez GitLab Runner sur le même VPS ou sur un serveur dédié. Installation sur Ubuntu :

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
sudo apt install -y gitlab-runner

Enregistrez le runner auprès de votre instance GitLab. Récupérez le token d'enregistrement depuis Admin Area → CI/CD → Runners, puis exécutez :

sudo gitlab-runner register

Renseignez l'URL de votre instance, le token, une description et l'executor (shell, docker, kubernetes). Pour des pipelines isolés, l'executor docker est recommandé. Installez Docker si nécessaire :

sudo apt install -y docker.io
sudo usermod -aG docker gitlab-runner
sudo systemctl restart gitlab-runner

Pipeline exemple : build et test d'une application Node.js

Créez un fichier .gitlab-ci.yml à la racine de votre dépôt :

stages:
  - build
  - test

build_job:
  stage: build
  image: node:18
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/

test_job:
  stage: test
  image: node:18
  script:
    - npm install
    - npm test

Chaque commit déclenche automatiquement le pipeline. Les artefacts (dossier dist/) sont conservés et téléchargeables depuis l'interface GitLab. Pour les projets volumineux, augmentez le quota d'artefacts dans Admin Area → Settings → CI/CD → Continuous Integration and Deployment.

Déploiement automatisé via SSH

Intégrez une étape de déploiement pour pousser automatiquement votre application vers un serveur de production. Ajoutez une clé SSH privée comme variable CI/CD protégée (Settings → CI/CD → Variables), puis ajoutez un stage deploy :

deploy_job:
  stage: deploy
  only:
    - main
  before_script:
    - 'command -v ssh-agent >/dev/null || ( apt-get update -y && apt-get install openssh-client -y )'
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
  script:
    - scp -o StrictHostKeyChecking=no -r dist/* user@prod-server:/var/www/app/
    - ssh -o StrictHostKeyChecking=no user@prod-server "systemctl restart app"

Ce pipeline automatise le transfert des fichiers buildés vers le serveur de production et relance le service applicatif. Pour une approche plus moderne, utilisez des conteneurs Docker et poussez les images vers le registre intégré GitLab, activable dans /etc/gitlab/gitlab.rb via registry_external_url 'https://registry.example.com'.

Webhooks et intégration avec des outils externes

GitLab peut notifier des services externes (Slack, Discord, systèmes de ticketing) via webhooks. Configurez un webhook dans Settings → Webhooks de votre projet. Les événements push, merge request, pipeline failure déclenchent des requêtes HTTP POST vers l'URL configurée. Pour intégrer GitLab dans des workflows complexes, exploitez l'API REST OmegaCloud pour provisionner automatiquement des VPS runner ou gérer les snapshots lors des déploiements.

Conclusion

Installer GitLab CE sur un VPS Linux est une opération structurée qui, suivie rigoureusement, garantit une plateforme DevOps performante et sécurisée. En combinant ressources matérielles adaptées, système durci (fail2ban, ufw, SSH par clés), monitoring actif et pipelines CI/CD automatisés, vous disposez d'un environnement complet pour vos projets de développement. Les snapshots, l'anti-DDoS transparent et le panel de gestion simplifient l'administration quotidienne, libérant du temps pour innover.

FAQ

Quelle quantité de RAM minimale pour héberger GitLab CE en production avec 10 utilisateurs actifs ?

Pour 10 utilisateurs actifs exécutant régulièrement des pipelines CI/CD, prévoyez au moins 8 Go de RAM. GitLab CE consomme environ 2 à 3 Go au repos ; chaque pipeline actif mobilise de la mémoire supplémentaire. Surveillez la métrique MemAvailable avec free -h et envisagez 12 ou 16 Go si vous activez le registre Docker intégré et Grafana.

Comment migrer une instance GitLab existante vers un nouveau VPS sans perte de données ?

Créez un backup complet sur l'ancien serveur avec sudo gitlab-backup create, récupérez l'archive dans /var/opt/gitlab/backups/ et les fichiers de configuration /etc/gitlab/gitlab.rb et /etc/gitlab/gitlab-secrets.json. Installez GitLab CE sur le nouveau VPS avec la même version, copiez les fichiers de configuration et l'archive de backup, puis exécutez sudo gitlab-backup restore BACKUP=timestamp_du_fichier. Enfin, sudo gitlab-ctl reconfigure et sudo gitlab-ctl restart. Pointez le DNS vers la nouvelle IP une fois les tests validés.

Peut-on héberger GitLab Runner sur un VPS séparé pour isoler les pipelines ?

Oui, et c'est même recommandé pour des raisons de sécurité et de performance. Installez gitlab-runner sur un second VPS, enregistrez-le avec le token de votre instance GitLab principale, et choisissez l'executor docker pour isoler chaque job dans un conteneur. Cette architecture empêche qu'un pipeline malveillant n'accède aux données de GitLab et répartit la charge CPU/RAM entre plusieurs serveurs. Utilisez un VPS Linux OmegaCloud dédié aux runners pour scaler facilement en fonction du nombre de pipelines concurrents.