Aller au contenu

Architecture cible GitLab-forge à base de VM

Compte-rendu de la Réunion du 22/02/2022 (14h à 16h30).

Présents :

  • Didier Richard
  • Gabin Chambon
  • Geoffrey Arthaud
  • Michel Gibelli
  • Mirsal Enaime
  • Pascal Bastien

GitLab-forge sera réparti sur 2 tenants distincts: le tenant GitLab et celui des Runners.

Tenant GitLab

Ce tenant comprends les services :

  • GitLab ;
  • Coffre-fort ;
  • Surveillance et alertes.

Les VM sont sur Debian stable (Bullseye).

Bastion

Les bastions sont censés être éteint en exploitation et démarrés en cas de besoin de maintenance système sur les applications.

Todo

les tailles des VMs sont à documenter.

GitLab

Actuellement (2022), toutes les données sont sur des volumes Cinder (dans des répertoires distincts).

Un premier cluster avec 4 machines virtuelles qui sont dédiées au service GitLab :

  1. 1 VM GitLab sans la BDD postgreSQL :
  2. le stockage pour Gitaly (dépôt git) sera sur un volume Cinder (système de fichier) ;
  3. le reste des données sera sur du stockage objet S3 crée dans le tenant (un bucket par type de données, registry, package registry, etc).
  4. 1 VM avec la BDD postgreSQL :
    • sur un volume Cinder.
  5. 1 VM pour les GitLab Pages :
    • stockage objet S3.
  6. 1 Bastion pour se connecter et administrer les machines de ce tenant.

Pour la résilience et la séparation des fonctions

  • 1 VM dédiée pour le GitLab registry ?
    • sur du stockage objet S3 ;
    • Critères de décision :
      • Garder en mémoire l'éco-conception d'architecture (trop de VMs, plein de carbone) ;
      • Considérer une certaine complexité de re-construction et d'upgrade de versions GitLab (qui reste à mesurer) ;
      • Accepter le risque sur la VM GitLab par l'équipe produit (en attendant).
  • Gitaly, Gitlab Shell : même questionnement.

Schéma Architecture GitLab

Télécharger le Schéma d'architecture de l'éco-système GitLab-forge

Schéma volumes

Télécharger le Schéma d'architecture des volumes

Coffre-fort

Un second cluster pour le Vault (coffre-fort) et Consul (BDD distribuée) :

  1. 2 VM Vault (2 est un minimum) ;
  2. 3 VM Consul (BDD distribuée, 3 noeuds est un minimum, données en mémoire) :
    • stockage objet S3.

Info

  • La sauvegarde des données Consul est à mettre en place ;
  • le besoin d'un accès ssh pour l'administration est à considérer (Cf. Réseaux) ;
  • Seul le Vault a besoin d'une facade externe en HTTPS ;
  • Les interfaces web en HTTPS (port forward) sont uniquement sur intranet.

Point de vigilance

Si un runner est à l'extérieur, faut-il ouvrir Vault à l'extérieur ? A priori non, car le runner "importe" à partir de GitLab l'ensemble des éléments y compris les secrets lors de son lancement.

Schéma Architecture Coffre-fort

Télécharger le Schéma d'architecture du coffre-fort

Surveillance et Alertes

La pile logicielle utilisée est Prometheus/Grafana/Loki et AlertManager associée à PromTail (récupération des logs). Pour toutes les VMs, les logs sont configurés sur journald, PromTail (installé sur chaque VM) les récupère et les envoie à Loki.

Le troisième cluster pour la surveillance est constitué de :

  1. 1 VM Prometheus ;
  2. 1 VM Grafana ;
  3. 1 VM Loki ;
  4. 1 VM AlertManager (petite VM).

Les logs sont écrits et lus sur le système de fichiers. Les logiciels sont installés sur l'OS directement, si trop de soucis, alors on passera par Docker.

Warning

Combien de temps on gardera les métriques, les logs ? Ce sont des données particulières (accumulation au cours du temps ...) Politique d'archivage à réfléchir Puits de logs à mettre en place

Les tableaux de bord restent internes. Le PSIN doit pouvoir surveiller l'éco-système GitLab (via les tableaux de bord et scenarii à fournir).

Schéma Architecture Surveillance

Télécharger le Schéma d'architecture de la pile logicielle de surveillance et d'alerte

Sauvegardes

Ce sera sur du B3 :

  • restic sauvegarde/restaure toutes les données des volumes cinder ainsi que le dump de la base Postgresql ;
  • restic sauvegarde/restaure également les données des stockage objets S3 via rclone (restic ne permettant pas de sauvegarder du S3 sur du S3).

Warning

La sauvegarde des logs (attaques/rejeux) : on profite de la surveillance pour sauvegarder les traces applicatives.

Suite aux premiers tests de sauvegardes, il apparaît nécessaire de dédier une VM pour la sauvegarde afin de soulager la VM GitLab. Cette instance de pilotage de la sauvegarde serait up/down via le runner infrastructure.

Réseaux

Les réseaux externes suivants sont nécessaires :

  1. soit :
  2. ssh admin dédié administration (bastion) ouvert sur intranet ;
  3. ssh web dédié application (git) ouvert sur intra puis internet ;
  4. web pour HTTPS ouvert sur intra et internet.
  5. soit (plus simple) :
  6. ssh dédié administration (bastion) ouvert sur intranet ;
  7. web pour HTTPS et SSH ouvert sur intra et internet (pour le tenant GitLab et pour la VM GitLab via security policy).

L'équipe choisirait la solution 2 si c'est possible côté IaaS (complexité côté MSP/DIS). La complexité se situera au niveau du RP legacy pour ssh.

Schéma Architecture Réseau

Télécharger le Schéma d'architecture du réseau

Tenant Runners

Runners

Un cluster de VM est nécessaire :

  1. 1 VM bastion pour l'administration ;
  2. 1 VM proxy séparée (ou un routeur OpenStack) pour permettre la sortie vers Internet (https -- squid -- et ssh/sftp -- netfilter --) via le réseau privé applicatif web ;
  3. 1 VM Runner qui est un hôte Docker ou équivalent pour chaque groupe (racine ou sous-groupe) -- 2vCPU, 8Go, 25Go HDD --, 1 concurrent (environ une vingtaine de VM) ;
  4. 1 VM "RunnerInfra" qui up/down via un repo qui contiendra les informations des runners à gérer par CI/CD, ainsi que la VM de sauvegarde (en mode schedule) ;
  5. 2 VM runners global partagées.

Les runners vont devoir s'éteindre/s'allumer (coût carbone !).

Info

Pas de runner shell pour l'instant, mais l'architecture le permettrait.

Hub Docker

Avec les VMs runner, le rate limit de Docker Hub risque d'être atteint ... Mettre en place un proxy/cache pour ces images (transparent) ? Pousser à l'usage du DEPENDENCY_PROXY_(DIRECT_)GROUP pour les images de base.

Todo

Optimisation : snapshot des VMs pour les upper plus rapidement plutôt que de créer/détruire.

Schéma Architecture Runner

Télécharger le Schéma d'architecture des runners