Une infrastructure CI/CD auto-hébergée, gouvernée par ses propres contrôles

Contexte

J’exploite ma propre chaîne d’intégration continue plutôt que de m’appuyer sur des services cloud : forge Git, exécuteurs CI, qualité de code, sécurité. Trois raisons à ce choix :

• Souveraineté

  Aucun code ne transite par un service tiers dont je ne maîtrise ni les conditions d’usage ni la pérennité.

• Maîtrise

  Un environnement de construction figé et reproductible, dont chaque dépendance est connue et versionnée.

Contraintes techniques

Toute la pile est open source : c’est une contrainte de licence choisie, pas une préférence, et elle détermine directement certains choix d’outillage (voir plus bas). L’ensemble tourne sur une machine à ressources limitées, ce qui pèse sur chaque décision d’architecture CI/CD — un budget mémoire et CPU serré force des arbitrages qu’un cluster surdimensionné n’impose pas.

Démarche

Chaque décision structurante est écrite en ADR (contexte, décision, conséquences favorables et défavorables, alternatives écartées, coût de retour en arrière). Une trentaine à ce jour. Quelques-unes illustrent la méthode :

• Conteneurs plutôt qu’hyperviseur

  Sur une itération précédente, des services installés à même l’hôte se cassaient mutuellement par partage de bibliothèques système. J’ai isolé chaque service en conteneur, piles versionnées indépendamment. Un hyperviseur aurait imposé de réinstaller l’hôte et de repartitionner un stockage déjà quasi plein et sans sauvegarde : le risque dépassait le bénéfice à ce stade.

• Une forge tout-en-un

  GitLab CE plutôt qu’un empilement (dépôt Git + moteur CI + registre séparés), avec un réglage explicite qui ramène sa consommation mémoire d’environ 8 à 4 Go — nécessaire sur une machine aux ressources comptées. Un assemblage aurait été plus économe en régime permanent, mais il impose d’intégrer et de maintenir soi-même ce que GitLab fournit déjà assemblé : pour un opérateur seul dont le temps est la ressource rare, l’arbitrage va à l’intégré.

• Qualité C++ par greffon communautaire

  Faute d’analyseur propriétaire compatible avec la contrainte open source, j’assume et je documente la limite plutôt que de la taire : la couverture des défauts est exactement celle des analyseurs statiques importés (cppcheck, clang-tidy), sans analyse inter-procédurale propriétaire. Une couverture partielle mais connue vaut mieux qu’une fausse impression d’exhaustivité.

• Isolement réseau qualifié avec exactitude

  Le projet visait au départ un fonctionnement complètement coupé du réseau. Le relevé de l’état réel a montré que ce n’était pas le cas : l’hôte garde une sortie Internet nécessaire aux mises à jour et à certaines dépendances de build. J’ai requalifié l’objectif — « souverain, privé et non exposé, à chaîne de construction hermétique » — plutôt que de laisser une affirmation inexacte dans la documentation.

Réalisations

La chaîne repose sur trois briques principales, chacune choisie et documentée séparément :

• La forge

  GitLab CE et son exécuteur (Runner) : hébergement du code, registre d’images de conteneurs, orchestrateur de pipeline. Image Docker épinglée à une version précise, jamais un tag flottant.

• La qualité de code

  SonarQube Community, avec un greffon communautaire d’analyse C++ qui importe les rapports de cppcheck et clang-tidy plutôt que de dépendre d’un analyseur propriétaire. Compatible avec la contrainte 100 % open source du projet.

• Le réseau

  Traefik en reverse proxy, TLS automatisé sur les services exposés en interne.

• Pipeline d’intégration continue

  Cinq étapes — build, test, couverture, analyse statique, remontée SonarQube — avec une porte de qualité bloquante.

• Outillage de vérification

  Versionné à la racine du dépôt : détection de secrets ( gitleaks), lint de documentation, détection de liens morts, déclenchés en CI. Plus de trente scripts de contrôle en lecture seule, un test par affirmation documentaire.