Les interrogations sur l’usage de templates YAML
- La question est posée de savoir depuis quand l’usage de templates YAML est considéré comme normal, et comment cela a pu être accepté.
- Présentation à cfgmgmtcamp 2019 sur la nécessité de la gestion de configuration Kubernetes et sur la solution kr8.
- Pendant la présentation, une remise en question des templates YAML a suscité des discussions animées en ligne et lors de la conférence.
Le problème de la configuration
- Lorsque les applications et l’infrastructure dépassent une certaine taille, on se heurte au problème de la complexité de la configuration.
- La configuration d’applications déployées dans différents environnements (développement, staging, production) ou différentes régions (Europe, Amérique du Nord) peut varier.
- Les administrateurs système et ingénieurs DevOps connaissent bien la complexité de la gestion de configuration, et chaque outil utilise YAML pour tenter de résoudre ce problème.
Avons-nous régressé ?
- Avec l’évolution des besoins de l’industrie liée au cloud computing, de nouveaux outils sont apparus.
- Des outils comme CloudFormation et Helm sont d’excellents outils de configuration, mais l’auteur estime que l’industrie dans son ensemble a commis une erreur dans la manière de concevoir les templates YAML.
- L’explication s’appuie sur l’exemple d’un chart Helm recevant des paramètres de personnalisation.
Les charts Helm
- Les charts Helm reçoivent des paramètres externes via le fichier
values.yaml pour rendre le chart.
- Le texte explique la complexité qui apparaît lorsqu’on part de simples paramètres de chaîne de caractères pour aller vers des champs optionnels, des tableaux ou des maps.
- Il souligne les exigences strictes de YAML en matière d’espacement et les limites des systèmes de templates.
JSON, Jsonnet et YAML
- YAML est un sur-ensemble de JSON, et la conversion entre les deux formats est simple.
- Jsonnet est un langage de templates de données conçu pour générer des configurations JSON.
L’église de Jsonnet
- Jsonnet est un langage récent, peu connu en dehors de la communauté Kubernetes.
- Jsonnet permet de générer facilement des configurations JSON en utilisant des variables externes.
- Le texte explique comment gérer les champs optionnels, les maps, les paramètres, ainsi que les fonctionnalités supplémentaires de Jsonnet.
Kr8
- Kr8 utilise toutes les méthodes permettant de créer et manipuler facilement et simplement la configuration de plusieurs clusters Kubernetes.
- Si les idées présentées ici vous parlent, il est recommandé de jeter un œil à Kr8.
L’avis de GN⁺
- La complexité des templates YAML : cet article met en lumière la complexité et les limites des templates YAML, et montre bien les problèmes auxquels l’industrie est confrontée en matière de gestion de configuration.
- Les avantages de Jsonnet : Jsonnet est présenté comme une alternative aux templates YAML, en soulignant sa simplicité d’usage et sa flexibilité, ce qui peut susciter l’intérêt pour de nouveaux outils.
- L’avenir de la gestion de configuration : cet article offre un éclairage sur l’avenir de la gestion de configuration et donne aux ingénieurs DevOps comme aux administrateurs système l’occasion d’explorer de nouvelles approches.
1 commentaires
Discussion sur Hacker News
Beaucoup de plaintes concernent les fichiers de configuration YAML. C’est aussi considéré comme la pire partie de GitHub Actions, et le même ressenti existe vis-à-vis d’autres langages de configuration propriétaires (HCL, ASL, etc.). Les API déclaratives sont appréciées, mais il existe une demande pour pouvoir générer les déclarations de manière programmatique.
Déclarer et générer la configuration sous forme de code offre une meilleure expérience. AWS CDK a bien compris cet enjeu, en permettant d’écrire des définitions déclaratives de configuration et d’infrastructure cloud avec des langages sûrs du point de vue des types et le support de l’IDE.
Accord sur le fait que le templating YAML est irrationnel, et que lorsqu’une logique complexe est nécessaire, il faut utiliser un vrai langage de programmation pour générer du YAML/JSON, etc. Cela peut résoudre de nombreux problèmes.
Il y a eu une discussion sur Kubernetes : bien que son API dispose d’un schéma JSON intuitif et bien défini, les gens passent beaucoup de temps à apprendre à utiliser les charts Helm. Jsonnet, Ksonnet, Nu et CUE n’ont pas connu un grand succès, et la plupart des gens semblent utiliser Kustomize, intégré à kubectl.
Certains soulignent que les développeurs ne réfléchissent pas assez à la bonne manière de traiter la configuration. On peut dire que toute programmation est en fait un problème de configuration, et que toute configuration finit par être transmise comme paramètre à une fonction. Il serait peut-être préférable de stocker la configuration dans une base de données centralisée.
En CI/CD, YAML est parfois utilisé presque comme un langage de programmation, ce qui est jugé très verbeux, peu intuitif et comme un langage mal défini, spécifique à un fournisseur.
Regret de voir Helm l’avoir emporté. Travailler avec des charts Helm est très pénible, l’éditeur ne peut pas vraiment aider, et il faut aligner correctement toutes les données avec
indent 4. Certains prédisent que Helm entraînera la fin de Kubernetes.Il y a aussi une philosophie personnelle selon laquelle il n’est pas souhaitable d’utiliser l’interpolation de chaînes pour générer du code lisible par une machine. Cela continuera à provoquer des problèmes comme les injections SQL et le cross-site scripting. Selon ce point de vue, il ne faudrait pas utiliser de fichiers de templates pour générer du HTML.
Certains estiment que les personnes qui choisissent YAML ne perçoivent pas le problème. Il existe un conflit direct entre les représentations de données centrées sur l’humain et celles centrées sur la machine. YAML et JSON sont en réalité des formats de données différents.
Certains disent aimer YAML, tout en le maudissant chaque jour lorsqu’ils travaillent sur des charts Helm. Ils détestent Helm, mais continueront à l’utiliser parce que tout le monde l’utilise.
Certains envisagent de passer à cuelang, qu’ils jugent mieux conçu que Jsonnet. Kubernetes dispose déjà d’une fonction de réconciliation d’état ; il ne manquerait plus qu’une fonction de suppression.