Docker Compose est la lingua franca des applications multi-conteneurs. Chaque projet open source livre un docker-compose.yml. Chaque développeur en a utilisé un. Et chaque PaaS qui ignore Compose force ses utilisateurs à traduire leurs configurations existantes dans un format propriétaire.
Nous avions déjà un système de templates capable de déployer des applications multi-services depuis un YAML personnalisé. La question était : pouvions-nous accepter des fichiers Docker Compose standard, les parser avec toutes leurs idiosyncrasies, et les canaliser dans le même pipeline de déploiement ?
Parsing de Compose v3 : le champ de mines des types
La spécification Docker Compose est d'une complexité trompeuse. Les variables d'environnement peuvent être un map ou une liste. depends_on peut être une liste de chaînes ou un map avec des clés de condition. Les commandes peuvent être une chaîne ou un tableau. L'attribut #[serde(untagged)] était critique pour gérer ces variantes.
Validation
La validation vérifie : présence d'image, références de dépendances, dépendances circulaires (DFS), et format des ports. 19 tests unitaires couvrent chaque chemin de validation.
Conversion vers la représentation interne
Le convertisseur transforme les instances ComposeService en structs ResolvedService -- le même type que notre pipeline de déploiement de templates consomme. Zéro logique de déploiement dupliquée.
Réutilisation du pipeline de templates
Sept fonctions ont été rendues pub(crate). Le handler Compose les appelle dans le même ordre que le handler de templates. Quand nous corrigeons un bug dans la création de conteneur ou améliorons la configuration de routage Caddy, les deux chemins de code en bénéficient automatiquement.
Prochain dans la série : Moteur de sauvegarde : AES-256-GCM, 13 fournisseurs de stockage, et cauchemars FTP.