PROTOCOL_ID: XP-07 CLASS: CONTROL_PLANE_DELIVERY
Conseil Crossplane
Nous concevons et livrons le control plane, aux côtés de vos ingénieurs, pas à leur place.
Difficulté: 3 / 3
Vue d'ensemble
Une mission commence par la question que la plupart des projets Crossplane évitent : que doit savoir un développeur ? Chaque composition que vous écrivez y répond. Bien posée, une équipe provisionne une base de données en six lignes. Mal posée, vous avez reconstruit Terraform avec plus de YAML et une boucle de réconciliation.
Ensuite nous construisons. Des composite resource definitions qui modélisent votre domaine plutôt que le catalogue du fournisseur, des compositions qui restent lisibles après le troisième changement de besoin, et une configuration provider qui survit à la rotation des secrets. Quand le provider nécessaire n'existe pas, nous l'écrivons. Nous l'avons fait pour OVHcloud et documenté la démarche publiquement.
Le delivery passe par GitOps, parce qu'un control plane qui dérive est pire que pas de control plane. Argo CD réconcilie les compositions, Kyverno tient la frontière de politique, et chaque changement de votre équipe plateforme est un commit relisible. Vos ingénieurs travaillent en binôme avec les nôtres tout du long, pour que la connaissance reste chez vous après notre départ.
Schéma illustratif, hors télémétrie réelle
Outils de cet engagement
Outils de cet engagement
- Crossplane
- crossplane-cli
- Argo CD
- Kyverno
- Kubernetes
- Go
De l'audit à la production
- 01
Modélisation du domaine
Cartographier ce que vos équipes provisionnent aujourd'hui et ce qui mérite une API plutôt qu'un ticket.
- 02
Conception XRD et compositions
Définir d'abord le contrat exposé aux développeurs, puis la composition qui le satisfait. Pas l'inverse.
- 03
Travail sur les providers
Configurer les providers upstream, ou en construire un sur mesure quand votre plateforme dépend d'une API que personne n'a encore couverte.
- 04
Delivery GitOps
Câbler réconciliation, politique et promotion pour que le control plane ne puisse pas dériver de ce qui est dans Git.
- 05
Durcissement production
Modes de panne, chemin de mise à jour, et ce qui se passe quand une composition est fausse à trois heures du matin.
Écosystèmes, outillage et livrables
| Écosystèmes cibles |
|
|---|---|
| Outillage |
|
| Livrables |
|
| Prérequis |
|
Réponses directes
Questions fréquentes
Que reste-t-il concrètement à la fin d'une mission ?
Des composite resource definitions qui modélisent votre domaine, des compositions relues et documentées dans votre propre dépôt, un pipeline GitOps avec ses garde-fous de politique, et un provider sur mesure là où l'écosystème avait un manque. Le vrai livrable, c'est une équipe capable d'étendre tout cela sans nous appeler.
Notre cloud n'a pas de provider Crossplane. Pouvez-vous en écrire un ?
Oui. Nous l'avons fait pour OVHcloud et avons documenté toute la démarche publiquement, ce qui vous permet de voir comment nous travaillons avant de nous engager. L'écriture de provider fait partie de la mission dès que votre plateforme dépend d'une API que personne n'a encore couverte.
Comment évitez-vous que les compositions deviennent ingérables ?
En définissant le contrat exposé aux développeurs avant la composition qui le satisfait, et non l'inverse. Chaque champ exposé est une promesse à tenir : la frontière se trace délibérément et se défend. Le delivery passe ensuite par GitOps, Argo CD réconciliant et Kyverno tenant la ligne de politique, pour que rien ne dérive de ce qui est dans Git.