7 pièges YAML laids à éviter et comment les éviter

Le langage de configuration YAML (« YAML n’est pas un langage de balisage ») est au cœur de nombreuses applications modernes, notamment Kubernetes, Ansible, CircleCI et Salt. Après tout, YAML offre de nombreux avantages, tels que la lisibilité, la flexibilité et la possibilité de travailler avec des fichiers JSON. Mais YAML est aussi une source d’embûches et de pièges pour les non-initiés ou les imprudents.

De nombreux aspects du comportement de YAML permettent une commodité momentanée, mais au prix de zigs ou de zags inattendus plus tard sur la ligne. Même les personnes ayant beaucoup d’expérience dans l’assemblage ou le déploiement de YAML peuvent être mordues par ces problèmes, qui apparaissent souvent sous le couvert d’un comportement apparemment inoffensif.

Voici sept étapes que vous pouvez suivre pour vous prémunir contre les pièges les plus gênants de YAML.

En cas de doute, mettez les chaînes entre guillemets

La pratique défensive la plus puissante que vous puissiez adopter lors de l’écriture de YAML : Citez tout ce qui est censé être une chaîne.

L’une des bizarreries les plus connues de YAML est que vous pouvez écrire des chaînes sans guillemets :

- movie:
    title: Blade Runner
    year: 1982

Dans cet exemple, les touches movie, titleet year seront interprétés comme des chaînes, tout comme la valeur Blade Runner. La valeur 1982 sera analysé comme un nombre.

Mais que se passe-t-il ici ?

- movie:
    title: 1979
    year: 2016

C’est vrai, le titre du film sera interprété en tant que nombre. Et ce n’est même pas la pire chose qui puisse arriver :

- movie:
    title: No
    year: 2012

Quelles sont les chances que ce titre soit interprété comme un booléen ?

Si vous voulez être absolument sûr que les clés et les valeurs seront interprétées comme des chaînes, et vous prémunir contre toute ambiguïté potentielle (et un parcelle d’ambiguïtés peuvent se glisser dans YAML), puis citez vos chaînes :

- "movie":
    "title": "Blade Runner"
    "year": 1982

Si vous ne parvenez pas à citer des chaînes pour une raison quelconque, vous pouvez utiliser un préfixe abrégé pour indiquer le type. Celles-ci rendent YAML un peu plus bruyant à lire que les chaînes entre guillemets, mais elles sont tout aussi claires que les guillemets :

movie: !!str Blade Runner

Méfiez-vous des chaînes multilignes

YAML a plusieurs façons de représenter les chaînes multilignes, selon la façon dont ces chaînes sont formatées. Par exemple, les chaînes sans guillemets peuvent simplement être réparties sur plusieurs lignes lorsqu’elles sont préfixées par un >:

long string: >
    This is a long string
    that spans multiple lines.

Notez que l’utilisation > ajoute automatiquement un n en bout de chaîne. Si vous ne voulez pas la nouvelle ligne de fin, utilisez >- à la place de >.

Si vous utilisez des chaînes entre guillemets, vous devez faire précéder chaque saut de ligne d’une barre oblique inverse :

long string: "This is a long string 
    that spans multiple lines."

Notez que tous les espaces après un saut de ligne sont interprétés comme une mise en forme YAML, et non comme faisant partie de la chaîne. C’est pourquoi l’espace est inséré avant de la barre oblique inverse dans l’exemple ci-dessus. Il assure les mots string et that ne courez pas ensemble.

Attention aux booléens

Comme indiqué ci-dessus, l’un des autres gros pièges de YAML est les valeurs booléennes. Il existe tellement de façons de spécifier des booléens dans YAML qu’il est trop facile pour une chaîne voulue d’être interprétée comme un booléen.

Un exemple notoire de ceci est le problème du code de pays à deux chiffres. Si votre pays est US ou UK, bien. Si votre pays est la Norvège, dont le code pays est NOqui n’est plus une chaîne – c’est un booléen qui évalue à false!

Dans la mesure du possible, soyez délibérément explicite avec les deux valeurs booléennes et des chaînes plus courtes qui pourraient être interprétées à tort comme des booléens. Le préfixe abrégé de YAML pour les booléens est !!bool.

Méfiez-vous des multiples formes d’octal

C’est un piège à l’écart, mais cela peut être gênant. YAML 1.1 utilise une notation différente pour les nombres octaux que YAML 1.2. Dans YAML 1.1, les nombres octaux ressemblent à 0777. Dans YAML 1.2, ce même octal devient 0o777. C’est beaucoup moins ambigu.

Kubernetes, l’un des plus gros utilisateurs de YAML, utilise YAML 1.1. Si vous utilisez YAML avec d’autres applications qui utilisent la version 1.2 de la spécification, faites très attention à ne pas utiliser la mauvaise note octale. Étant donné que l’octal n’est généralement utilisé que pour les autorisations de fichiers de nos jours, c’est un cas particulier par rapport aux autres pièges YAML. Pourtant, l’octal YAML peut vous mordre si vous ne faites pas attention.

Méfiez-vous du YAML exécutable

Exécutable YAML ? Oui. De nombreuses bibliothèques YAML, telles que PyYAML pour Python, ont permis l’exécution de commandes arbitraires lors de la désérialisation de YAML. Étonnamment, ce n’est pas un bogue, mais une fonctionnalité YAML a été conçu autoriser.

Dans le cas de PyYAML, le comportement par défaut de la désérialisation a finalement été modifié pour ne prendre en charge qu’un sous-ensemble sûr de YAML qui n’autorise pas ce genre de chose. Le comportement d’origine peut être restauré manuellement (voir le lien ci-dessus pour plus de détails sur la façon de procéder), mais vous devez éviter d’utiliser cette fonctionnalité si vous le pouvez et la désactiver par défaut si elle n’est pas déjà désactivée.

Méfiez-vous des incohérences lors de la sérialisation et de la désérialisation

Un autre problème potentiel avec YAML est que différentes bibliothèques de gestion YAML dans différents langages de programmation génèrent parfois des résultats différents.

Considérez : Si vous avez un fichier YAML qui inclut des valeurs booléennes représentées comme true et falseet vous le re-sérialisez en YAML en utilisant une bibliothèque différente qui représente les booléens comme y et n ou on et off, vous pourriez obtenir des résultats inattendus. Même si le code reste fonctionnellement le même, il peut sembler totalement différent.

N’utilisez pas YAML

Le moyen le plus général d’éviter les problèmes avec YAML ? Ne l’utilisez pas. Ou du moins, ne l’utilisez pas directement.

Si vous devez écrire YAML dans le cadre d’un processus de configuration, il peut être plus sûr d’écrire le code en JSON ou en code natif (par exemple, des dictionnaires Python), puis de le sérialiser en YAML. Vous aurez plus de contrôle sur les types d’objets et vous serez plus à l’aise avec un langage avec lequel vous travaillez déjà.

À défaut, vous pouvez utiliser un linter tel que yamllint pour vérifier les problèmes YAML courants. Par exemple, vous pouvez interdire les valeurs véridiques comme YES ou offen faveur de simplement true et falseou pour appliquer les guillemets de chaîne.