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 VM GitLab sans la BDD postgreSQL :
- le stockage pour
Gitaly
(dépôt git) sera sur un volume Cinder (système de fichier) ; - 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).
- 1 VM avec la BDD postgreSQL :
- sur un volume Cinder.
- 1 VM pour les GitLab Pages :
- stockage objet S3.
- 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.
Télécharger le Schéma d'architecture de l'éco-système GitLab-forge
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) :
- 2 VM Vault (2 est un minimum) ;
- 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.
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 VM Prometheus ;
- 1 VM Grafana ;
- 1 VM Loki ;
- 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).
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 viarclone
(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 :
- soit :
ssh admin
dédié administration (bastion) ouvert sur intranet ;ssh web
dédié application (git) ouvert sur intra puis internet ;web
pour HTTPS ouvert sur intra et internet.- soit (plus simple) :
ssh
dédié administration (bastion) ouvert sur intranet ;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.
Télécharger le Schéma d'architecture du réseau
Tenant Runners¶
Runners¶
Un cluster de VM est nécessaire :
- 1 VM bastion pour l'administration ;
- 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
; - 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) ;
- 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) ;
- 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.
Télécharger le Schéma d'architecture des runners