Un récit de terrain · OpenStack · Starter
Une équipe, une plateforme,
sur son propre cloud
Les dix composants qu’achète un abonnement Starter, déployés sur un cloud OpenStack privé et utilisés comme une équipe produit les utiliserait. Voici comment s’est passée la journée.
L’application
Nous avons un projet web à construire
Nous sommes une petite équipe produit, et nous avons une application web à livrer. Elle tourne sur nginx et garde ses données dans PostgreSQL — la forme ordinaire d’un projet web.
La plateforme nous a donné ce projet déjà debout : le tiers web qui répond, la base de données derrière, et une page en façade qu’on voit se remplir à mesure que les gens l’utilisent. Rien à installer d’abord sur l’ordinateur de qui que ce soit.
Ce que nous construisons
L’application est une petite boutique en ligne : un catalogue, des commandes, un total qui court. Elle tient lieu de ce qu’une équipe construit vraiment.
Ce qui compte, c’est que la plateforme nous remet les pièces pour la faire tourner — le serveur web, la base de données, la page — et les moyens de la surveiller, plutôt qu’une description de tout cela. À partir de là, l’équipe peut commencer à écrire du code contre quelque chose qui marche déjà.
Les outils
Un endroit pour le code, de quoi le construire
Avant d’écrire grand-chose, il nous faut un endroit pour le code et une machine pour le construire. La plateforme déploie pour nous GitLab et un runner, et le runner s’enregistre de lui-même auprès du GitLab voisin.
Dès le premier commit, le pipeline tourne tout seul : il récupère une dépendance dans notre Nexus, compile, et republie le résultat. Nous n’avons rien câblé à la main.
Le runner est le nôtre, pas un pool partagé. Il s’enregistre auprès de notre propre GitLab, tourne sur une machine de notre compte, et nous pouvons le voir, le mettre en pause ou le remplacer. Notre code n’est jamais construit sur une infrastructure que nous ne maîtrisons pas.
Les personnes
Faire entrer l’équipe, avec les bons accès
Notre responsable doit faire entrer des personnes sur le projet — des développeurs front-end et back-end — et donner à chacun les accès dont son travail a besoin, et pas plus.
Keycloak est déployé comme authentification unique de l’équipe. Chacun se connecte une fois, sur un realm qui appartient à ce projet, et la même identité vaut dans tous les outils. Ajouter un développeur, ou le déclarer front-end ou back-end, c’est gérer un profil à un seul endroit plutôt qu’un compte dans chaque service.
Le travail
Puis la construction commence pour de bon
Le travail s’intensifie. Les commits arrivent tout au long de la journée, et le runner compile presque sans arrêt. C’est là qu’une plateforme se fait oublier, ou qu’elle gêne.
Le dashboard du runner montre les jobs qui passent, leur durée, et ses journaux. Quand l’équipe tourne à plein régime, on voit le régime.
GitLab a son propre dashboard à côté de celui du runner : la file de la CI, et le PostgreSQL, le Redis et le Sidekiq derrière elle. Quand un build ralentit, on sait si c’est le runner ou le serveur, sans deviner.
Ce qui casse
Toutes les erreurs, sans quitter un seul écran
Dans le travail ordinaire, des choses tournent mal : une requête erronée du front-end, un service qui se tait, un runner qui cale. Nous préférons les trouver nous-mêmes plutôt que d’en entendre parler.
Chaque composant rend compte au même Grafana. Le dashboard web montre de vraies réponses 4xx et 5xx à côté du débit de requêtes, avec les journaux d’accès et d’erreurs en dessous. Un problème apparaît comme une ligne sur un graphique et une ligne dans un journal, au même endroit.
La vue d’ensemble
Où en est le travail, et comment le partager
Notre responsable veut plus que « ça tourne » : savoir comment le travail avance, pour le partager avec les personnes à qui l’équipe rend des comptes.
Le même Grafana donne cette vue à partir de l’activité de build et de déploiement. Et pour le travail lui-même — ce qui se fait, heure par heure — nous pouvons placer devant lui un service d’activité : une simple page qui montre l’état actuel, le journal au fil de l’eau, et la charge sur la journée.
Le journal quotidien est la forme à partager : une page par jour — un titre, les chiffres, et les images de ce qui a réussi — que notre responsable peut remettre aux personnes à qui l’équipe rend des comptes, sans donner d’identifiants à personne.
Le bilan de la journée
- Composants
- 10, chacun sa machine
- Cloud
- OpenStack 2026.1, deux hyperviseurs que nous exploitons
- Pipelines
- 13 builds réussis de GNU hello depuis Nexus
- Observabilité
- Le dashboard de chaque composant, métriques et journaux
- Secrets dans les données de démarrage
- Aucun : déposés par SSH par le pipeline