Compose: propriétés spécifiées par l'utilisateur et/ou où stocker les métadonnées (auteur, description)

Créé le 17 févr. 2016  ·  3Commentaires  ·  Source: docker/compose

Avec les fichiers de la version 1, j'ai deux commentaires au début du fichier docker-compose :

# author: Anthon van der Neut <[email protected]>
# description: mongo container

que j'ai ensuite extrait dans dc2service utilisant ruamel.yaml et inclus ces informations dans le fichier de service pour Systemd/Upstart . Bien sûr, je pourrais suivre le principe YACF (Yet Another Configuration File) si souvent vu dans les projets python, mais avec la 1.6.0 et le format de fichier de la version 2.0, je pourrais facilement faire :

version: '2'
user-data:
  author: Anthon van der Neut <[email protected]>
  description: mongo container
services:
   .......

Malheureusement, docker-compose plaint que user-data soit une propriété supplémentaire inattendue.

Pour le mappage de niveau supérieur dans la version 2, je propose que nous obtenions une ou plusieurs clés réservées aux données spécifiques à l'utilisateur, la seule exigence étant que la valeur correspondante soit une construction YAML valide, c'est-à-dire que l'ensemble du fichier reste analysable YAML. Cela pourrait être une clé, avec la recommandation que sa valeur correspondante est un mappage (pour la flexibilité), ou bien docker-compose pourrait ignorer toutes les clés de niveau supérieur qui ont un certain préfixe ("user-data-")

Quelque chose de similaire est par exemple fait dans des formats de fichiers conteneurs comme TIFF pour permettre l'inclusion d'informations supplémentaires (spécifiques au fournisseur). Le nom de cette clé devrait bien sûr être quelque chose qui ne sera certainement pas utilisé dans docker-compose, donc "user-data", "non-dc-data".

Les développeurs de docker-compose pourraient alors toujours sélectionner les informations qu'ils considèrent utiles pour d'autres projets (espérons-le comme mon auteur/description) et décider de les insérer sous une autre propriété, ou peut-être même justifier leur propre propriété de niveau supérieur.

Commentaire le plus utile

J'ai fermé d'autres problèmes en tant que doublons de celui-ci.

Je pense que nous devrions autoriser les clés x-* au niveau supérieur dans la prochaine version des schémas 2.x et 3.x

Tous les 3 commentaires

Je pense que cela chevauche les #1655 et #2578

Cela serait exceptionnellement utile pour les outils qui fonctionnent avec des fichiers docker-compose.yml .

J'ai fermé d'autres problèmes en tant que doublons de celui-ci.

Je pense que nous devrions autoriser les clés x-* au niveau supérieur dans la prochaine version des schémas 2.x et 3.x

Cette page vous a été utile?
0 / 5 - 0 notes