Aller au contenu principal

GitLab

GitLab héberge le code, la documentation (via Pages) et les pipelines de l'équipe. Depuis le 2026-11-04, il tourne sur Proxmox, derrière OPNsense, sous le nom gitlab.formuleets.ca.

En bref​

Adressehttps://gitlab.formuleets.ca (l'ancien nom gitlab2.formuleets.ca marche toujours)
Registry Dockerregistry.gitlab.formuleets.ca
Pageshttps://<groupe>.pages.formuleets.ca/<projet>, ou un domaine personnalisé comme cette documentation (https://doc.formuleets.ca)
MachineVM 120 gitlab sur formule-pve-02, Ubuntu 22.04, 4 vCPU, 16 Go, disque de 300 Go
VersionGitLab CE 19.5.3 (installation Omnibus)
CertificatLet's Encrypt, obtenu et renouvelé par Caddy sur OPNsense (GitLab lui-même ne fait plus de HTTPS depuis le 2026-11-05)
CodeVM décrite dans le dépôt infra/infra (vms-existantes.tf), protégée contre la destruction

Réseau​

Internet / école ──► 142.137.247.115 (OPNsense, interface DMZ)
                         │
                         ├─ 80, 443 ─► Caddy (HTTPS) ─► GitLab 192.168.1.10:80 (registry :5050)
                         └─ 22 ──────► GitLab 192.168.1.10:22 (SSH git, redirection directe)
  • L'IP publique 142.137.247.115 est portée par OPNsense, avec la MAC qu'avait GitLab sur ce port de l'école. Le web (80, 443) arrive sur Caddy, le SSH git (22) est redirigé directement vers GitLab.
  • GitLab est sur le LAN d'OPNsense (192.168.1.10) et sort vers Internet par OPNsense.
  • Accès d'administration temporaire : GitLab a encore une IP sur le réseau de l'école (ens160, en DHCP, aujourd'hui 10.194.24.50) pour le SSH. Elle contourne OPNsense et sera retirée quand le VLAN du club arrivera au bureau.
  • Le firewall local ufw autorise les ports 80 et 443 depuis partout, le 5050 (registry) et le 8091 (Pages, domaines personnalisés) depuis OPNsense (192.168.1.1), et le 22 depuis les réseaux de l'école (10.0.0.0/8).
Les réponses doivent repartir par la DMZ

Les règles OPNsense qui laissent entrer le trafic sur la DMZ forcent la passerelle de réponse DMZ_GW. Sans elle, les règles semblent bonnes mais personne ne reçoit de réponse. Voir Réseau : VLAN et OPNsense.

Derrière Caddy​

Depuis le 2026-11-05, Caddy (sur OPNsense) gère le HTTPS de GitLab, du registry et de Pages. GitLab ne fait plus que du HTTP sur le LAN. Les réglages ajoutés à /etc/gitlab/gitlab.rb :

  • letsencrypt['enable'] = false : c'est Caddy qui obtient les certificats ;
  • nginx['listen_port'] = 80 et nginx['listen_https'] = false, pareil pour pages_nginx, et registry_nginx sur le port 5050 ;
  • proxy_set_headers avec X-Forwarded-Proto = https : GitLab sait que le visiteur est en HTTPS et génère des liens corrects ;
  • real_ip_trusted_addresses = 192.168.1.1 et real_ip_header = X-Forwarded-For : GitLab voit la vraie IP des visiteurs (journaux, limites de requêtes), et pas celle d'OPNsense.

L'ancienne configuration est sauvegardée dans /root/gitlab.rb.avant-caddy. Le script /root/retour-avant-caddy.sh la remet en place si besoin.

GitLab répond 502 pendant une minute après un reconfigure

Après un gitlab-ctl reconfigure, Puma redémarre et Caddy affiche « GitLab is not responding ». Attends environ une minute avant de chercher plus loin.

Domaine personnalisé pour un site Pages​

Depuis le 2026-11-10, cette documentation est servie sur https://doc.formuleets.ca. L'ancienne adresse https://general.pages.formuleets.ca/documentation/ redirige vers elle (code 308).

Le nginx de GitLab ne sert Pages que pour les noms en *.pages.formuleets.ca. Pour un autre nom, Caddy envoie les requêtes directement au démon Pages, qui écoute à part sur 192.168.1.10:8091 :

# /etc/gitlab/gitlab.rb (version précédente : /root/gitlab.rb.avant-doc)
gitlab_pages['external_http'] = ['192.168.1.10:8091']

Pour ajouter un domaine à un autre site Pages, par exemple exemple.formuleets.ca :

  1. Cloudflare : un enregistrement A exemple vers 142.137.247.115, en DNS only.
  2. GitLab, dans le projet → Déployer → Pages → Domaines & paramètres → Ajouter un domaine : exemple.formuleets.ca, sans certificat (c'est Caddy qui fait le HTTPS). GitLab affiche un enregistrement TXT de vérification (_gitlab-pages-verification-code.exemple) : l'ajouter dans Cloudflare, puis cliquer sur Vérifier.
  3. Caddy : un domaine exemple.formuleets.ca (Auto HTTPS, défi DNS-01), et un manipulateur reverse_proxy vers http://192.168.1.10, port 8091. Puis Appliquer.
  4. Si le site est fait pour une adresse à la racine (Docusaurus : url et baseUrl: '/'), mettre à jour sa configuration et le redéployer.
  5. GitLab, même page : Domaine principal = le nouveau domaine. Les anciennes adresses redirigent alors vers lui.
Ne coche pas « Forcer le HTTPS » dans Pages

Pages n'a pas de certificat : c'est Caddy qui fait le HTTPS. GitLab propose donc le domaine principal en http://, et la redirection passe par http://, puis Caddy bascule en https://. C'est normal.

La vérification échoue alors que l'enregistrement TXT est bon

GitLab interroge le DNS de l'école, qui garde en mémoire une réponse « n'existe pas » jusqu'à 30 minutes. Attends, ou force temporairement un autre résolveur sur GitLab : sudo resolvectl dns ens160 1.1.1.1 8.8.8.8 && sudo resolvectl flush-caches (le réglage disparaît au redémarrage). Les postes du club ont le même délai pour voir un nouveau nom : ipconfig /flushdns, puis attendre.

Changement d'adresse (2026-11-04)​

GitLab est passé de gitlab2.formuleets.ca à gitlab.formuleets.ca. Il répond toujours sous l'ancien nom, sans redirection : Caddy a un certificat pour chacun des deux noms. Les clones existants continuent donc de marcher avec les identifiants déjà enregistrés.

  • Ne supprime pas l'enregistrement DNS gitlab2 tant que des clones l'utilisent.
  • Pour mettre à jour un clone (facultatif), dans le dossier du dépôt : 
    git remote set-url origin "$(git remote get-url origin | sed 's/gitlab2\.formuleets/gitlab.formuleets/')"
    Git redemandera une fois tes identifiants pour le nouveau nom.
  • Le registry n'a qu'un seul nom : registry.gitlab.formuleets.ca. Les images référencées en registry.gitlab2… doivent être mises à jour. Dans les pipelines, $CI_REGISTRY est déjà correct.

Runner​

Le runner de l'instance (Christiannnne, tag formule) tourne encore sur VMware (10.194.24.34). Dans sa config, extra_hosts force gitlab.formuleets.ca et registry.gitlab.formuleets.ca vers 142.137.247.115 : les jobs passent par OPNsense. Détails dans Infra as Code.

Sauvegardes​

À compléter

Pas encore de sauvegarde automatique de la VM. Une sauvegarde GitLab (gitlab-backup, sans le registry) et la config (/etc/gitlab) ont été faites avant la migration. À mettre en place : sauvegarde de la VM 120 (vzdump, puis Proxmox Backup Server). Tâche OpenProject #136.

Ce qu'on a appris de la migration​

  • L'assistant d'import ESXi de Proxmox n'était pas utilisable ici : moins de 3 Mo/s (il lit le disque via l'interface web de l'ESXi), et il échoue sur une VM qui a un snapshot.
  • Ce qui a marché : supprimer les snapshots dans l'ESXi, créer la VM vide sur Proxmox avec les mêmes MAC, puis copier le disque par SSH en 4 copies parallèles, chacune sur un quart du disque (environ 39 Mo/s, 2 h 30 pour 300 Go).
  • Avant toute migration, la config réseau doit reconnaître les cartes par leur adresse MAC (netplan match: macaddress). Les noms des cartes changent entre VMware et Proxmox.
  • Une IP en DHCP n'est pas fiable pour un serveur : celle de GitLab a changé en cours de route. Demande à l'école une réservation ou une IP fixe.
  • Les changements matériels en attente (MAC, agent QEMU) ne s'appliquent qu'à un arrêt puis un démarrage depuis Proxmox, pas avec un reboot lancé dans la VM.