Moby: Ajout de la prise en charge de la fonctionnalité « extends » dans Compose v3 / déploiement de la pile docker

J'ai ajouté quelques notes https://github.com/docker/compose/issues/4315#issuecomment -280617251 pour me rapporter les extensions telles qu'elles existent jusqu'à la version 2.1 du fichier docker compose n'est pas une bonne idée mais la fonctionnalité principale que j'ai miss est de pouvoir déclarer des services abstraits (qui ne devraient jamais être exécutés mais pourraient être utilisés pour regrouper les propriétés communes des services pour plus de commodité).

D'accord sur les commentaires de docker/compose#4315 que la façon dont extends fonctionnait était un peu spartiate.

Je ne recommanderai pas de solution, mais FWIW, pour montrer l'étendue des abus, voici les conventions qui ornent le haut de notre fichier de composition :

#
# Docker Compose configuration
#
# Due to lack of "expressivity" in Compose, we define our own couple of service
# "pseudo-types":
#
#   - image-only services (name: *-image)
#
#     The only goal of these is to build images. No other services build images.
#
#     These have entrypoint overridden to exit immediately.
#
#   - base services (name: *-base)
#
#     These contain common configuration and are intended to be extended.
#
#     Their command (not entrypoint, to keep the original one) is overridden to
#     exit immediately. Service must support a command to exit immediately.
#
#   - task services (name: *-task)
#
#     These are intended for running one-off commands.
#
#     Their default command is overridden to exit immediately. Service must
#     support a command to exit immediately.
#
#   - "real" services
#
#     These are actual services that stay up and running.
#
version: '2'
services:
  ...

Je pense que l'extension comme dans la v2.1 est un bon choix. Extends est en fait simple et compréhensible, c'est aussi une bonne pratique pour chaque environnement d'avoir une petite transformation lisible entre dev, prod et env.

En fait, j'ai

• un fichier docker-compose commun qui présente les règles de base
• un docker dev compose l'étendant et avec des facilités pour le développeur
• un docker de mise en scène compose l'extension commune aussi et avec des installations pour cet environnement
• un docker de production compose également une extension commune et avec des fonctionnalités pour cet environnement, notamment la réplication de conteneurs, les règles de redémarrage, etc...

Cela fonctionne, et je ne comprends pas pourquoi nous devrions rechercher dans ce ticket une réécriture complète, mais plus le maintien d'une fonctionnalité intéressante. Extends est une bonne partie avec des cas d'utilisation spéciaux que d'autres techniques ne peuvent pas résoudre facilement. Je suis content des possibilités étendues.

Nous empêchant également de passer au format v3.x.

Nous gardons nos définitions de conteneur Docker dans une disposition dossier par instance, où chaque dossier contient un docker-compose.yml qui définit les spécificités d'environnement pour l'instance de conteneur à portée de main. Pour factoriser les éléments communs (DRY), nous utilisons des définitions de service de base dans un dossier parent et utilisons extend .

Ainsi, lorsque j'ai besoin de gérer une instance de conteneur particulière, j'ai juste besoin de cd dans le bon dossier et je peux ensuite exécuter directement les commandes docker-compose sans autre configuration (aucun indicateur -f n'est requis que les membres de l'équipe besoin de rechercher ou de savoir, fonctionne comme prévu dès le départ).

Je ne peux pas utiliser les fichiers de composition de la version 3.

J'utilise services.yml pour définir la disposition de base de mes services, puis je l'étends avec dev.services.yml pour mon environnement de développement (principalement en ajoutant des volumes) mais j'aime la réutilisabilité (DRY) d'extend quand c'était ajoutée. Ce n'est pas un compromis, mais cela m'empêcherait de passer à la version 3 à moins qu'il n'y ait une fonctionnalité indispensable.

Je ne suis pas contre l'amélioration de la solution "d'extensions" de la v2.1 avec quelque chose de plus approprié. Quelque chose comme les services abstraits pourrait être à la fois plus sûr à utiliser et plus puissant.

Par exemple (puisque c'est abstrait), je pourrais imaginer prendre en charge des volumes/points de montage/réseaux abstraits, où le service de base abstrait définit un point de montage local ou un réseau requis pour un service, sans définir la partie hôte - ce qui signifie qu'un service dérivé pourrait alors définir/ mapper la partie hôte des montages/volumes et réseaux à ce qui est approprié dans son environnement hôte/stage.

C'est un exemple de quelque chose que nous ne pouvons pas faire maintenant avec « extends » pour autant que je sache, et qui ouvrirait des possibilités intéressantes.

La suppression de la fonctionnalité d'extension n'a pas été utile du tout. De nombreux services Web ont démarré avec les mêmes volumes mappés, les mêmes variables d'environnement et les mêmes étiquettes. Ils ont également les mêmes politiques de bilan de santé. Et sans parler des ports. La combinaison de fichiers de composition à l'aide de plusieurs options -f est fastidieuse et sujette aux erreurs si vous traitez plusieurs projets sur le même hôte.

@shin- cela sera-t-il ramené sur le schéma 3.2 ?

J'aimerais vraiment, vraiment, récupérer extends dans le format de fichier. Je l'ai utilisé pour affiner davantage les services abstraits pour un certain nombre de projets. Je comprends que plusieurs options -f correspondent presque à la facture, mais cela ne fonctionne pas toujours. Par exemple, je change assez souvent le nom du service abstrait en quelque chose de plus significatif dans le contexte du projet en cours. C'est quelque chose que la substitution qui se produit avec plusieurs options -f ne prend pas en charge.

Cela ne me dérangerait pas de perdre le extends exact, tant qu'il existe un autre moyen "d'instancier" un service abstrait dans un fichier.

J'ai une configuration avec un fichier de service commun et un tas de services qui l'étendent, changeant principalement les volumes, donc je dirais que je m'appuie sur la fonctionnalité extends et que je ne vois pas d'autre bonne façon de décrire ma configuration.

--frustrated

+1
Je peux voir la logique derrière la recommandation d'aplatir les fichiers docker-compose, mais je n'aime pas l'idée de dupliquer le code qui définit notre topologie de service de développement sur plusieurs projets. Nous utiliserons la solution de contournement -f pour le moment, avec des scripts shell afin que les développeurs n'aient pas à se rappeler quels services inclure dans quels cas.

J'espère qu'une solution satisfaisante pourra être trouvée ici pour permettre une meilleure factorisation des structures de composition !

En haut de ma liste de cas d'utilisation, il y a de DRYup ma réserve de services gérée par la configuration. J'ai pensé que je pourrais profiter des "extensions" si la v3. Je ne veux pas revenir à la v2... et je ne veux pas avoir de cas particuliers où je dois utiliser la solution de contournement du processus -f.

Hé, est-ce que quelqu'un a commencé à travailler là-dessus ? Je ne trouve pas de RP pour suivre. Cela simplifierait beaucoup certaines choses pour nous ici également (cas d'utilisation très similaire à certains décrits ci-dessus).

Étant donné que la version 3 est gelée et que j'avais besoin d'un moyen de partager une configuration commune, j'ai piraté une petite solution de contournement, que je pense pouvoir partager ici (je ne sais pas si c'est le bon endroit mais n'hésitez pas à me dire où je peux partagez cette information :))

Je ne vais pas m'étendre là-dessus ici, car il y a un fichier readme dans le repo.
Bonne soirée à tous ☮️

Éditer:

Désolé, voici le lien :D

+1

+1

+1

Merci pour les +1
En attendant, j'ai trouvé une autre image docker noop , qui est plus petite d'un facteur 10^3 (en raison du noop réel écrit en assembleur).

Malheureusement, il n'y a pas de licence dans ce référentiel. J'ai déjà écrit un message au propriétaire sur facebk mais il n'a pas encore répondu. Peut-être qu'il ajoutera une licence si plus de personnes l'interrogent à ce sujet :)

Quelque chose qui pourrait aider certains des cas d'utilisation étendus (ceux dans un seul fichier) serait la prise en charge des ancres YAML : https://learnxinyminutes.com/docs/yaml/

Il semble que le schéma JSON ne soit pas validé sur eux service must be a mapping, not a NoneType. .

Hé, @grayside , les ancres yaml fonctionnent, du moins pour moi. Voir mon commentaire ci-dessus pour savoir comment je les utilise.

Ok mais c'est trop triste d'utiliser un service noop non ?

Surtout pour les vars env, quel type de valeurs ces vars env gèrent-elles ? S'il s'agit de secrets, utilisez la fonction de secrets d'essaim (ou toute autre solution de secrets). S'il s'agit de paramètres, nous sommes d'accord pour dire que la plupart du temps, les paramètres sont spécifiques aux applications/services, et ne sont pas destinés à être partagés entre les services.

Si vous avez besoin de partager des paramètres entre services, la plupart du temps, c'est lorsque vous lancez la même image de conteneur mais à des fins/tâches d'exécution différentes (consommateur, producteur, travailleur http, ...).

S'il s'agit de paramètres, nous sommes d'accord pour dire que la plupart du temps, les paramètres sont spécifiques aux applications/services, et ne sont pas destinés à être partagés entre les services.

J'ai tendance à être en désaccord. Dans le projet sur lequel je travaille actuellement, je l'utilise par exemple pour les volumes :

# Volume paths
environment:
  - &volume_a        volume-a:/usr/share/my_project/volumes/volume-a
  - &volume_b        volume-b:/usr/share/my_project/volumes/volume-b
  - &volume_c        volume-c:/usr/share/my_project/volumes/volume-c
  - &volume_d        volume-d:/usr/share/my_project/volumes/volume-d

Maintenant, je peux spécifier ces volumes comme ça :

volumes:
  - volume-a:
  - volume-b:
  - volume-c:
  - volume-d:

services:
  some-service:
    image: some-image
    volumes:
      - *volume_a
      - *volume_b

  some-other-service:
    image: some-other-image
    volumes:
      - *volume_b
      - *volume_c

  some-third-service:
    image: yet-another-image
    volumes:
      - *volume_a
      - *volume_b
      - *volume_c
      - *volume_d

Cela facilite grandement la navigation dans les différents volumes sans avoir à penser au conteneur dans lequel vous vous trouvez. À mon humble avis, c'est un moyen de rendre votre configuration de docker-compose plus cohérente et plus facile à utiliser et à entretenir.

Ok oui je comprends @JanNash mais dans votre exemple ci-dessous, vous n'avez pas de service noop, n'est-ce pas ?

Mais les ancres ne suffisent pas dans de nombreux cas.

Mon cas consiste à supporter plusieurs environnements pour un même projet. Vous pouvez voir un échafaudage pour nos projets ici .

Lorsque vous développez, vous utilisez devel.yaml , mais en production, vous utilisez prod.yaml . Il y a aussi test.yaml . Tous héritent de common.yaml et obtiennent des variables communes d'un fichier .env .

Chacun a ses propres particularités :

• devel vise la vitesse de développement, il utilise donc des arguments de génération qui produisent des versions plus rapides, monte des volumes avec le code de l'application à partir de l'ordinateur du développeur et ajoute des services factices qui isolent l'application du monde extérieur.
• prod vise plutôt la stabilité, donc il télécharge et compile tout le code, et le regroupe dans l'image elle-même au lieu d'utiliser des volumes. Les builds sont plus lents, mais plus sécurisés.
• test vise à être exactement comme prod, mais isolé des services externes, pour éviter de polluer le monde extérieur.

Cette séparation simple permet d'avoir un pipeline DevOps très agile et flexible, où tout le monde utilise le même code entre différentes étapes, avec juste de petits ajustements en fonction de l'environnement utilisé.

J'ai essayé de passer au format de fichier v3, mais non seulement extends n'est pas pris en charge, mais aussi .env , donc en ce moment ce serait un cauchemar de maintenance (plus à cause du manque de .env , pour être honnête). Au moment de choisir entre Swarm et DRY, nous avons choisi DRY pour le moment, mais un jour nous aurons besoin de Swarm et j'espère que ce jour-là les deux fonctionnalités seront à nouveau prises en charge... ☺️

... ou au moins nous avons un moyen de générer un format DRY-less valide à partir d'une solution DRY-ful. Je pensais que docker-compose bundle était pour ça, mais ça semble être voué à l'abandon en ce moment...

... ou nous avons un autre outil qui fait tout (je garde aussi un œil sur ansible-container ). Mais ce n'est sûrement pas "la solution".

Le lien dans https://github.com/moby/moby/issues/31101#issuecomment-301212524 inclut un README avec l'exemple fonctionnel des ancres YAML. En l'examinant et en l'essayant à nouveau aujourd'hui, cela fonctionne très bien. Je ne sais pas ce que je fais différemment.

@JanNash

@Yajo je vous entends et comme dit, c'est une solution de contournement et ce serait mieux d'un ordre de grandeur s'il y avait une bonne solution DRY intégrée fournie par docker/moby/docker-compose (quelle que soit la bonne référence) . Espérons tous que ça viendra bientôt car à part ça, je suis plutôt content de docker compose 👍

~ Par souci de manquer le support .env, j'ai également piraté une solution de contournement (mon projet n'est pas encore en production, donc mon discours est un peu bon marché, je sais :)). Pour prendre en charge différents ensembles de variables d'environnement (dépendance et versions/tags d'image, par exemple) dans différents environnements (pour moi en ce moment, c'est le développement local et un petit serveur de développement), j'utilise deux fichiers, local.env et development.env et au lieu d'exécuter mes commandes avec seulement docker-compose <command> , soit je source le fichier .env respectif dans mon shell avant, soit je l'exécute comme ceci : (. local.env && docker-compose <command>) . Encore un hack, mais pour l'instant, j'en suis assez content.~

Bon courage à tous

Peut-être même deux ordres de grandeur :D

@JanNash attends ! .env n'est-il plus pris en charge dans 3 ?

En fait, je ne sais pas, je viens de lire dans un commentaire que ce n'était pas le cas.
J'ai utilisé les procédures local.env et development.env principalement parce que je ne connaissais pas autoenv lorsque je l'ai implémenté :D
Désolé pour la confusion possible.

Ah, @Yajo a mentionné le manque de support .env dans ce commentaire .
Pourriez-vous développer, @Yajo ?

Oh désolé, ma faute. Ce n'est pas que cela ne fonctionne pas, c'est juste que vous devez le spécifier avec env_file: .env , au lieu d'être détecté automatiquement comme avant. Revenons au problème initial.

La discussion doit-elle laisser tomber extends n'importe où ? J'aimerais le lire avant de donner notre cas d'utilisation car je pense qu'il est bien compris que c'était une fonctionnalité assez utilisée.

Salut, j'ai une question - quand ? Quand le support « étend » sera-t-il de retour dans la v3 ?

@JanNash, vous pouvez devenir beaucoup plus petit que cela. Je viens de déposer un problème dans github contre votre dépôt, je suis tombé à 1200 octets à partir de 750k sur ma machine.

Je vois que je ne peux pas utiliser extend pour le moment dans swarm.
des idées sur la façon de lancer le même service avec les mêmes ports de publication et avec un conteneur sur le service qui a 1 variable d'environnement supplémentaire ?

+1 pour étendre la prise en charge dans le déploiement de la pile d'essaim

Salut,
Nous exécutons une application de microservices répartie dans plusieurs référentiels git (chacun ayant son fichier docker-compose).
Le déploiement est dirigé par un fichier docker-compose "root" qui étend chaque service : pour nous, cette fonctionnalité extends est vraiment nécessaire pour le déploiement de la pile.
Donc aussi +1 pour étendre la prise en charge dans le déploiement de la pile d'essaim
Merci.

Vous pouvez utiliser l'héritage simple YAML (voir &default , <<: *default ) comme solution temporaire :

version: '3'
services:
  worker: &default
    build: .
    command: bundle exec rake jobs:work
    env_file:
      - .env
    volumes:
      - .:/app
    depends_on:
      - db
      - redis
    links:
      - db:postgres
  web:
    <<: *default
    command: bundle exec puma -C config/puma.rb -p 3000
    ports:
      - "3000:3000"
  spring:
    <<: *default
    command: bundle exec spring server

Bien sûr, la fonctionnalité extends est meilleure

Et si vous étendiez un fichier différent ?

Yaml n'a pas de fonctionnalité d'extension de fichier :(

Y a-t-il une mise à jour sur cette fonctionnalité d'un contributeur à Docker ? Est-ce que cela est prévu pour être réintroduit? Si non, y a-t-il des plans pour quelque chose de similaire ? Si non, pourquoi pas..?

@quolpr , je crains que votre code " YAML simple héritage " ne remplace extends dans la plupart des cas car le "prototype" (c'est- &default dire worker . Quel service a) doit donc être bien défini, b) pourrait être indésirable.

Quoi qu'il en soit, certainement une fonctionnalité intéressante.

@laugimethods, vous pouvez également utiliser des références YAML :

version: '3'
services:
  spring:
    build: ./app
    command: /bin/sh -c "bundle exec spring server"
    volumes: &default_volumes
      - ./app:/app:delegated
      - bundle:/bundle:nocopy
  worker:
    build: ./app
    command: bundle exec sidekiq -v -C config/sidekiq.yml
    volumes: *default_volumes

(faites attention à &default_volumes et *default_volumes )

Mais je ne comprends vraiment pas pourquoi la fonctionnalité extends été supprimée 🤔

Pour info, pour remplacer la fonctionnalité "extensions" manquante, j'utilise maintenant une composition/fusion de fichiers .yaml :
https://github.com/Logimethods/smart-meter/blob/master/README.md#docker -compose

s'étend fonctionne, est simple et mature, je pense que si quelqu'un voit s'étendre comme un anti-modèle, alors ne l'utilisez pas, mais s'il vous plaît, ne le coupez pas

Puis-je demander une explication claire de l'approche envisagée sans utiliser extends ? Je l'utilise abondamment, en particulier lors de l'héritage de fichiers contenus dans les sous-modules Git, permettant une définition d'un méta-projet gérant le câblage réseau inter-applications, etc. Bien que je sois bien conscient que je peux spécifier plusieurs fichiers docker-compose.yml et les faire remplacer, cela signifie-t-il que je devrais spécifier les interconnexions sur la ligne de commande, plutôt que de pouvoir les vérifier dans le contrôle de source à l'aide de extends ? Ou ai-je raté une nouvelle fonctionnalité quelque part dans la v3 ?

J'utilise beaucoup extends dans plusieurs projets pour hériter d'un ensemble commun d'attributs de service pour différents environnements et différents hôtes (lire : j'utilise extends pour hériter d'un fichier différent).

Après avoir lu avec stupeur la suppression du mot-clé extends et essayé de trouver un remplacement qui ne nécessite pas de connexion en série -f docker compose des fichiers, je suis très curieux de savoir quelle est la raison de la suppression de extends .

Je comprends le problème avec links et volume-from mais s'abstenir de les utiliser dans les fichiers yml de base semble la meilleure chose à faire.

Il serait improbable d'enlever la roue d'une voiture juste parce qu'elle _pourrait_ s'habituer à mettre la voiture à l'envers… non ?

PS : noop and anchors a l'air intéressant mais cela ajoute une complexité inutile aux projets les plus simples...

Un exemple très très simple :

common/common.yml

services:
  web:
    image: alpine:3.6
    build: .
    environment:
      DOMAIN:
      PREFIX:

dev/docker-compose.yml

services:
  web:
    extends: ../common/common.yml
    service: web
  ports:
    - "8080:8080"

prod/docker-compose.yml

services:
  web:
    extends: ../common/common.yml
    service: web
  image: the-prod-image:latest-release
  ports:
    - "80:80"
    - "80:443"
  environment:
    NEW_RELIC_KEY:

Comment garder les principes DRY sans extends ?

Actuellement, je ne vois aucune raison de passer de la version 2.1 à cause de cela.

@teodorescuserban ,

chaînage en série -f docker composer des fichiers

C'est quoi le problème ? Vous pouvez créer vos propres scripts avec des alias courts pour appeler docker-compose.

Utilisez la structure suivante :

commun/commun.yml

services:
  web:
    image: alpine:3.6
    build: .
    environment:
      DOMAIN:
      PREFIX:

dev/docker-compose.yml

services:
  web:
    ports:
      - "8080:8080"

prod/docker-compose.yml

services:
  web:
    image: the-prod-image:latest-release
    ports:
      - "80:80"
      - "80:443"
    environment:
      NEW_RELIC_KEY:

Commandes

docker-compose -f common/common.yml -f dev/docker-compose.yml -p myproject up --build

docker-compose -f common/common.yml -f prod/docker-compose.yml -p myproject up --build

Je ne connaissais pas cette fonctionnalité. Bien que cela fasse de votre CLI un , cela peut fonctionner.

Je pense que si cela doit être le remplacement officiel de extends , alors il devrait y avoir un moyen de le rendre plus facile.

Par exemple:

docker-compose.yml

version: "3"  # or whatever
extend:
  - ./common/common.yml
  - ./dev/docker-compose.yml
services: # Not required now
  # etc.

De cette façon, vous pouvez pointer vers un seul fichier docker-compose.yml qui fait tout ce dont vous avez besoin.

Une alternative utile serait de prendre en charge plusieurs fichiers de composition dans la var COMPOSE_FILE env.

@Yajo

Une alternative utile serait de prendre en charge plusieurs fichiers de composition dans la variable d'environnement COMPOSE_FILE.

Depuis https://docs.docker.com/compose/reference/envvars/#compose_file :

Cette variable prend en charge plusieurs fichiers Compose séparés par un séparateur de chemin (sous Linux et macOS, le séparateur de chemin est : , sous Windows il est ; ). Par exemple : COMPOSE_FILE=docker-compose.yml:docker-compose.prod.yml . Le séparateur de chemin peut également être personnalisé à l'aide de COMPOSE_PATH_SEPARATOR .

@dermeister0 Vous pouvez également fusionner définitivement ces fichiers avec des outils tels que https://github.com/ImmobilienScout24/yamlreader :

> yamlreader common/common.yml prod/docker-compose.yml > docker-compose-prod.yml
> docker-compose -f docker-compose-prod.yml -p myproject up --build

> cat docker-compose-prod.yml
services:
    web:
        build: .
        environment:
            DOMAIN: null
            NEW_RELIC_KEY: null
            PREFIX: null
        image: the-prod-image:latest-release
        ports:
        - 80:80
        - 80:443

@dermeister0 merci pour votre suggestion malheureusement c'est un moyen maladroit de s'en sortir. L'utilisation de extends supprime le besoin de savoir exactement comment vous devez les connecter en série. Bien que je puisse vivre avec le fait de le faire moi-même, je ne pourrais jamais appliquer cette solution à mes chers développeurs.

Cependant, je ne savais pas que la variable env COMPOSE_FILE peut contenir plusieurs valeurs. Merci @gsong ! C'est génial et je peux l'utiliser (je le définis dans le fichier .env ). Il y a un seul problème ici : dans les fichiers de base/communs, je peux également avoir certains services dont je n'ai pas besoin.

Prenons par exemple un fichier plat commun définissant une base de données et des conteneurs Web. Lors de la mise en scène, vous voulez qu'ils soient tous regroupés, mais sur prod, vous voudriez des hôtes séparés pour la base de données et pour le Web.

De plus, docker-compose.override.yml est chargé par défaut.

https://docs.docker.com/compose/extends/#understanding -multiple-compose-files

J'utilise cette approche avec la version 3.3 :

• mettre les options de configuration et les services communs dans docker-compose.yml ;
• utiliser docker-compose.override.yml pour une configuration de développement et des services spécifiques (comme xdebug par exemple) ;
• utilisez docker-compose.staging.yml pour des options de configuration de transfert spécifiques.

Remarque : je n'exécute pas Docker en production.

En utilisant cette approche, je peux facilement construire localement en utilisant docker-compose build et lorsque je déploie sur la mise en scène, j'utilise :

docker-compose -f docker-compose.staging.yml -f docker-compose.yml build

J'utilise Apache et je n'ai pas de fichiers hôtes virtuels séparés pour le développement et la mise en scène. J'ai dépensé pas mal de temps pour éviter d'avoir des fichiers différents. Au final, j'ai vu que la seule approche valide consiste à utiliser <IfDefine> et des variables d'environnement (que j'ai définies dans la section environnement des fichiers yml), pour inclure la configuration SSL par exemple. Et j'utilise TLD et le préfixe de domaine, donc je peux avoir quelque chose comme www.example.local http://www.example.local/ :8080 et www.staging.example.com http://www.staging.example.com / . Localement, les sites Web fonctionnent sous http et en transit sur https. Avec cette approche, je n'ai pas à gérer différentes versions des fichiers. Je pense que la même chose pourrait être faite en production, mais comme je l'ai dit, je préfère éviter Docker en production, atm.

Les chemins sont tous apparentés, les conteneurs fonctionneront donc dans n'importe quel environnement.

Mes 2 centimes

-Philippe

Dans mon cas, j'utilisais auparavant quelque chose comme ceci :

• commun.yml
• devel.yml -> extension de common.yml
• prod.yml -> extension de common.yml
• docker-compose.yml -> local, git-ignored, lien symbolique vers l'environnement souhaité (devel ou prod).

Merci à https://github.com/moby/moby/issues/31101#issuecomment -329482917 et https://github.com/moby/moby/issues/31101#issuecomment -329512231, que je ne connaissais pas, maintenant je peux passer à la v3 en utilisant un schéma différent :

• docker-compose.yml -> ce qui était auparavant common.yml
• devel.yml -> remplacement de docker-compose.yml
• prod.yml -> remplacement de docker-compose.yml
• docker-compose.override.yml -> local, git-ignored, lien symbolique vers l'environnement souhaité (devel ou prod).

Je peux également faire tous les hacks nécessaires en utilisant la variable env, donc dans mon cas, le problème est résolu. Merci! 🎉 (Désolé, j'aurais dû lire correctement la nouvelle doc avant de me plaindre).

PS : Pourtant, extends serait une bonne chose à récupérer, mais au moins nous avons une alternative assez juste. ??

@shin- D'abord, j'ai été très déçu de voir la fonctionnalité extends manquante dans 3.0 , mais les ancres YAML (exemple : https://github.com/JanNash/docker-noop) seraient un remplacement plus que suffisant.

La seule chose est que, comme dans l'exemple ci-dessus, vous devez mettre vos ancres dans une section valide de votre fichier docker-compose.yml .

Pourrions-nous obtenir une propriété templates (de niveau supérieur) ou des clés cachées comme dans GitLab pour être plus flexible dans la manière de définir les ancres ?

@ schmunk42 consultez https://github.com/docker/cli/pull/452

Le problème avec docker-compose.override.yml est qu'il présuppose que vous n'avez qu'un seul type de remplacement à inclure et une couche de remplacements.

Dans mon cas, je souhaite avoir certains comportements communs à tous les développements locaux, mais j'aurais peut-être besoin qu'ils soient légèrement différents si le développeur exécute Windows, OSX ou Linux. Pour que cela reste gérable dans un contexte docker-compose v3, j'ai des utilisateurs de Linux qui fonctionnent sur le même comportement que l'environnement de transfert, ce qui fonctionne mais signifie qu'ils sont légèrement en décalage avec les autres développeurs.

J'évite d'utiliser -f pour le développement local car j'ai trouvé qu'il est très sujet aux erreurs humaines, et s'en servir comme bascule pour trop de choses cause des problèmes. La sélection d'un fichier semble raisonnable, la sélection de plusieurs est quelque chose que j'évite soigneusement d'imposer.

Pour info, je pense qu'une fois le hack avec x- mentionné ci-dessus, et aussi le chaînage des fichiers docker-compose en utilisant la variable COMPOSE_FILE dans le fichier de projet .env , en ajoutant le docker- compose.override.yml devrait résoudre tous les cas d'utilisation que j'ai rencontrés jusqu'à présent.

Les ancres yml sont également une chose astucieuse que j'ai l'intention d'utiliser dans un proche avenir.

Pas très content de la beauté du hack x- mais je peux vivre avec ça.

Merci les gars pour votre contribution!

Il semble que la suppression de extends provoque beaucoup de brûlures d'estomac et bloque le passage à la v3 ou le recours à des hacks. J'aime la possibilité de définir un service "modèle" (ou abstrait) qui peut contenir des choses courantes (par exemple, des politiques de mise à jour)

Je travaille sur un simple utilitaire de filtre de golang qui peut pré-traiter un fichier de composition docker avec extends et cracher un fichier v3 propre avec les extensions résolues :
résoudre-composer docker stack deploy -c docker-compose.yaml
(ou docker-compose up)

Cela fonctionnera-t-il pour au moins certains de vos cas d'utilisation / pourquoi des pièges ?

@pnickolov Ce serait magnifique pour moi.

J'ai cherché ansible-container (j'utilise ansible personnellement, mais pas encore au travail), qui semble faire tout ce dont j'ai besoin, mais un script comme le vôtre serait plus préférable (moins de désabonnement)

Tant qu'il peut traiter de manière récursive les clés extends: , je serais heureux !

Ok, on dirait que nous avons trouvé des alternatives à extends ... 👍

Ce qui est troublant, c'est le fait que la gestion de projet de Moby ne semble pas considérer le maintien de la compatibilité comme un élément clé. La compatibilité ascendante est essentielle pour une adoption plus large, en particulier pour les grandes applications déployées en production. Comment pourrions-nous pousser pour Docker Swarm / Docker EE alors qu'il n'y a aucune garantie que les fonctionnalités de base comme extends resteront ? ??
Une bonne réputation est difficile à gagner et facile à perdre...

Personnellement, je préférerais m'appuyer sur les fonctionnalités YAML natives pour accomplir la tâche qui est gérée par extends dans la syntaxe v2 , plutôt qu'un script personnalisé ou une solution plus large comme ansible. J'avais des problèmes similaires plus tôt et j'ai commencé à écrire mon propre convertisseur avant qu'il n'y ait une solution comme l'utilisation de plusieurs fichiers .yml, etc. (https://github.com/schmunk42/yii2-yaml-converter-command) - mais ce n'était pas le cas une solution viable.

Pour moi, c'est aussi bien de déprécier des fonctionnalités, si cela est fait avec une politique de gestion des versions ; vous ne pouvez pas transporter de vieux trucs pour toujours, même si cela signifie du travail de notre côté.

@ schmunk42 La dépréciation des fonctionnalités est

• la fonctionnalité supprimée n'est plus vraiment utilisée ou est un vrai bloqueur pour les évolutions
• c'est annoncé à l'avance
• un chemin de migration est fourni tout de suite

Malheureusement, aucune de ces exigences (dans mon livre) ne s'applique à la dépréciation de extends ...

@laugimethods Quelle est la raison pour laquelle vous devez utiliser v3 ?

@ schmunk42 À cause de Swarm :

La version 3.x, la version la plus récente et recommandée, conçue pour être compatible entre Compose et le mode essaim du moteur Docker. Ceci est spécifié avec une version : '3' ou version : '3.1', etc., entrée à la racine du YAML.

La commande docker stack deploy prend en charge tout fichier Compose de version "3.0" ou supérieure

Au fait, mon commentaire n'est pas seulement lié à extends , mais à toute dépréciation (douloureuse) qui pourrait survenir à l'avenir...

Oui, nous sommes confrontés au même problème à cause du mode essaim.

Je me suis demandé en premier lieu, pourquoi diable le docker CLI est maintenant capable d'utiliser l'entrée --composer-file . Mais d'après nos apprentissages avec docker/swarm il semble assez compliqué d'exécuter des piles sur un essaim (autogéré) et il y a plusieurs bonnes raisons pour lesquelles cela a été déplacé vers le moteur.

Juste pour noter quelques unes de mes découvertes ici... la transition de v2 à v3.4 est loin d'être facile.

Certains de mes problèmes :

• il existe d'autres options non prises en charge comme volumes_from , plutôt faciles à contourner, car nous voulions quand même supprimer cela
• .env fichiers docker-compose ) n'ont aucun effet avec Docker CLI
• spécifier plusieurs fichiers de composition ( docker stack deploy -c docker-compose.yml -c docker-compose.override.yml doro ) ne semble pas fonctionner correctement, il n'y a pas d'erreur, mais il me semble qu'ils ne sont pas non plus fusionnés correctement - mais il n'y a pas non plus de commande comme docker-compose config pour le vérifier
• il n'y a pas de binaire "facile à installer" (pré-version) pour docker-compose qui prend en charge la syntaxe v3.4 ; comme Docker Edge
• les réseaux externes doivent être créés avec --scope swarm

CC : @handcode

Utiliser les dernières versions

• docker 17.09.0-ce
• docker-compose 1.17.0dev

J'utilise maintenant ce pipeline de configuration pour remplacer mon utilisation de _extend_ et _noop_
Garde les choses un peu plus AU SEC
J'espère que cela aide quelqu'un

base.yml (définitions partagées, il s'agit d'un document yaml valide, donc fusionnable à l'aide de _docker-compose config_)

version: '3.4'
networks:
  net_back:
    external: true

base-inject.yml (les définitions d'ancres partagées ne peuvent malheureusement pas être ajoutées à base.yml car les ancres ne peuvent pas être référencées dans différents fichiers yaml, elles sont plutôt injectées sous forme de texte dans foo.yml , ce n'est pas un moyen idéal de le faire)

x-logging: &logging
  driver: json-file
  options:
    max-size: "50m"
    max-file: "2"

foo.yml (définition de pile générique, références aux objets de base.yml , ancres de base-inject.yml et objets remplacés dans foo-dev.yml )

version: '3.4'
[[base-inject]]
services:
  foo:
    image: ${DOCKER_REGISTRY}/foo:${IMAGE_VERSION}
    volumes:
      - type: volume
        source: "volfoo"
        target: "/foo"
    networks:
     - net_back
    logging:
      <<: *logging

foo-dev.yml (par définition de pile d'environnement)

version: '3.4'
services:
  foo:
    ports:
      - "8080:80"
volumes:
  volfoo:
    name: '{{index .Service.Labels "com.docker.stack.namespace"}}_volfoo_{{.Task.Slot}}'
    driver: local

Puis la commande de déploiement :

docker stack rm stack_foo && echo "waiting..." && sleep 3 &&
  cat foo.yml | sed -e '/base-inject/ {' -e 'r base-inject.yml' -e 'd' -e '}' > ./foo-temp1.yml &&
  export $(sed '/^#/d' ./dev.env | xargs) &&
  docker-compose -f base.yml -f ./foo-temp1.yml -f foo-dev.yml config > ./foo-temp2.yml
  docker stack deploy --with-registry-auth --prune --compose-file ./foo-temp2.yml stack_foo

1. Supprimer l'ancienne pile
2. Attendez que la pile amovible se propage
3. Injecter des ancres dans la définition générique, enregistrer dans un fichier tmp
4. Lire + définir les variables du fichier env à partir du fichier
5. Utilisez docker-compose pour fusionner les trois fichiers ensemble
6. Déployer le fichier fusionné

Pour ceux d'entre vous qui ont envie de extends dans la composition de 3+ fichiers, je viens de mettre la main sur un outil appelé baclin . baclin linéarise ces directives, remplaçant récursivement toutes les directives extends par leur contenu. Il s'agit d'un logiciel alpha, le code fait partie de ma machinerie car j'écris actuellement du code pour prendre en charge le mode Swarm et le déploiement des piles. Les binaires de plate-forme d'une première version de baclin sont disponibles ici . Veuillez signaler tout commentaire ou problème ici .

C'est vraiment déroutant !
La v17.09 v17.06 lecture de v17.09 ) et aussi v17.06 version doc cette fonctionnalité devrait être disponible.

$ head -n1 docker-compose.yml
version: '3'

Mais compose up rapporte

ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.admin_application: 'extends'

lorsque vous utilisez le mot-clé extends .
De plus, je ne trouve rien sur la suppression de extends dans le journal des modifications compose .

Maintenant c'est quoi ?!
Des informations cruciales comme celle-ci ne devraient pas être difficiles à trouver ou cachées dans un problème obscur de github.

$ docker --version
Docker version 17.09.0-ce, build afdb6d4

$ docker-compose --version
docker-compose version 1.16.1, build 6d1ac21

@jottr , Voir docs :

Le mot-clé extend est pris en charge dans les formats de fichier Compose antérieurs jusqu'à la version de fichier Compose 2.1 (voir extend dans v1 et extend dans v2), mais n'est pas pris en charge dans Compose version 3.x.

Donc, si vous voulez utiliser extends vous devez vous en tenir à version: '2.1' .

Ma faute. Il devrait toujours être en haut de la doc avec un panneau d'avertissement de dépréciation rouge.

Ma faute. Il devrait toujours être en haut de la doc avec un panneau d'avertissement de dépréciation rouge.

@jottr Utilisez simplement Github pour créer un problème distinct pour cela ou même créer un PR pour cela. Je viens de créer le problème ici : https://github.com/docker/docker.github.io/issues/5340

Dans mon cas, j'ai le docker-compose-override.yml comme suit :
yaml version: "3.4" services: common: extra_hosts: - "host1:172.28.5.1" - "host2172.28.5.2" - "host3:172.28.5.3" networks: default: external: name: "common-network"
Et j'ai plusieurs autres fichiers docker-compose.yml qui doivent partager le réseau et extra_hosts. Comment faire cela en utilisant la fonction sans extension ?

yaml version: "3.4" services: mongo: image: "mongo" container_name: "mongo" hostname: "mongo" volumes: - "/opt/docker/mongo/default.conf:/usr/local/etc/mongo/mongod.conf" - /opt/data/mongo:/data/db" ports: - "27017:27017" command: "mongod --config /usr/local/etc/mongo/mongod.conf" networks: default: ipv4_address: "172.28.5.4"
Ce serait formidable si docker-compose prenait en charge l'ancre yaml et les références entre différents fichiers. Peut-être, en appliquant une ancre et des références après la fusion de fichiers.
Par exemple:
yaml version: "3.4" services: common: &common extra_hosts: ... networks: ...
yaml version: "3.4" services: mongo: <<: *common image: "mongo" container_name: "mongo" ...
Le résultat doit être :
yaml version: "3.4" services: mongo: image: "mongo" container_name: "mongo" extra_hosts: // EXTRA HOSTS HERE networks: ...

@sandro-csimas c'est possible avec : https://docs.docker.com/compose/compose-file/#extension -fields
@shin- ce ticket pourrait-il être fermé ?

@rdxmb Je ne pense pas. D'après ce que je peux voir, vous ne pouvez pas étendre à partir d'un autre fichier docker-compose

Ai-je raison de penser que c'est un problème pour https://github.com/docker/compose/issues ?

Quelques débogages :

# cat docker-compose.yml 
version: "3.4"
services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR 

x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

Cela fonctionne avec
docker stack deploy -c docker-compose.yml test

Lors de l'utilisation de docker-compose :

# docker-compose up 
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./docker-compose.yml", line 4, column 10

Changer le fichier yml en :

version: "3.4"

x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR

fonctionne également avec docker-compose.

J'ai donc pensé que cela devrait également fonctionner avec plusieurs fichiers, ce qui n'est pas le cas :

# docker-compose -f compose-services.yml -f compose-default.yml config > docker-compose.yml
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./compose-services.yml", line 5, column 10
t# docker-compose -f compose-default.yml -f compose-services.yml config > docker-compose.yml
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./compose-services.yml", line 5, column 10

# cat compose-services.yml 
version: "3.4"

services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR 

# cat compose-default.yml 
x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

Cependant, bien sûr, la fusion est possible avec une simple utilisation de cat :

# cat compose-default.yml compose-services.yml > docker-compose.yml && docker-compose up -d
WARNING: The Docker Engine you're using is running in swarm mode.

Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node.

To deploy your application across the swarm, use `docker stack deploy`.

Creating network "test_default" with the default driver
Creating test_foo-bar_1 ... 
Creating test_foo-not-bar_1 ... 
Creating test_foo-bar_1
Creating test_foo-bar_1 ... done

Fonctionnant sur xenial avec les versions :

# docker --version
Docker version 17.11.0-ce, build 1caf76c
# docker-compose --version
docker-compose version 1.17.0, build ac53b73

@rdxmb , merci !
Je devrais donc fusionner les fichiers de composition à l'aide de la commande "cat" et exécuter le fichier final.

J'utilise également le docker-compose config pour ce faire. Un exemple de paramètres spécifiques à l'environnement :

Ceci est exécuté par le pipeline CI : docker-compose -f docker-compose.yml -f docker-compose.override.prod.yml config > docker-compose.prod.yml puis j'utilise docker stack deploy -c .\docker-compose.prod.yml my-stack

Votez pour cela, l'extension est très utile pour la v3.

Je l'ai beaucoup utilisé avec la v2, très utile en effet !
+1

J'aimerais voir le support de extends dans la v3. Cela aiderait beaucoup à SÉCHER mon fichier docker-compose.yml .

Cela fait près d'un an que ce problème a été présenté et il est vraiment évident qu'une tonne de personnes ont besoin de cette fonctionnalité. Pourtant, je n'ai pas du tout lu de réponse des développeurs de Docker à cette demande, ni d'explication des raisons pour lesquelles elle n'a pas été incluse dans docker-compose v3 avant sa sortie.

Triste état du logiciel si nous ne pouvons même pas communiquer ou maintenir des fonctionnalités pour nos clients qui font confiance à une nouvelle technologie.

Une interprétation possible (et peut-être aussi un résumé du fil de discussion actuel) de la situation est la suivante :

• Les ancres/références YAML plus les champs d'extension de 3.4 permettent d' obtenir presque la même chose.
• multi-fichier peut être fait pour fonctionner. Voir le simple cat et l' approche avancée dans ce fil. Le commentaire d'approche simple montre un problème de docker-compose chargeant plusieurs fichiers vers la fin (quelqu'un a-t-il créé un problème pour cela ?). Si cela était corrigé dans docker-compose, vous n'auriez même pas besoin du tout de fusionner le fichier. Donc, pour moi, les personnes souhaitant une prise en charge multi-fichiers devraient continuer dans docker/compose/issues comme @rdxmb l'a proposé.
• Ramener extends été envisagé (voir les événements du projet GitHub , belle transparence ici de la part de l'équipe Docker, merci!) toujours écrire une pull request pour extends je suppose.

Pour moi, c'est un point de vue parfaitement compréhensible.

@aCandidMind d' accord.

À mon humble avis , même si les approches mentionnées par extends .
C'est peut-être moi, mais déplacer une configuration d'extensions modérément complexe vers des champs d'extension devient beaucoup plus difficile à lire et à maintenir.
Après avoir lu de nombreux commentaires et publications, je ne comprends toujours pas pourquoi les extensions ont été abandonnées et quels sont les avantages de cette régression des capacités.

Il est possible avec un peu de magie de bash que je mette en place un dépôt de test afin que vous puissiez l'essayer vous-même.

Structurez simplement votre commande stack deploy comme ceci :

docker stack deploy --compose-file=<(docker-compose -f docker/prod.yml -f docker/dev.yml config) <stackname>

@tylerbuchea - le seul inconvénient de cette magie de bash est que vous pourriez obtenir un WARNING: Some services (<service-name(s)>) use the '<key>' key, which will be ignored. Compose does not support '<key>' configuration . Cela peut causer une certaine confusion. Mais bon, ça marche

@dnmgns tu as raison ! Merci d'avoir fait remarquer cela. Comme @joaocc l'a dit, rien ne battra le support natif, mais la solution que j'ai mentionnée ci-dessus est la meilleure que j'ai pu trouver étant donné qu'il n'y a pas de dépendances autres que bash.

@tylerbuchea Un moyen sale consiste simplement à rediriger stderr vers /dev/null :)
docker stack deploy --compose-file=<(docker-compose -f docker/prod.yml -f docker/dev.yml config 2> /dev/null) <stackname>

Il n'y a pas de honte à ça

Je pense que la documentation devrait être plus explicite sur cette confusion autour de extend .
La description de extend redirige l'utilisateur vers les documents de mise à niveau, et les documents de mise à niveau renvoient à la description de extend pour plus d'informations. Ce n'est pas assez utile : en tant qu'utilisateur, j'attendrais de l'aide sur la façon de traiter tout ce problème, les options dont je dispose et ce que je devrais considérer. Je suis sûr qu'il y avait une idée claire derrière la décision de supprimer extend de la v3.

Voir:
https://docs.docker.com/compose/extends/#extending -services
https://docs.docker.com/compose/compose-file/compose-versioning/#upgrading

En ce qui concerne
Malheureusement, il ne prend pas en charge certaines fonctionnalités avancées de la pile Docker :

WARNING: Some services (web) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.
WARNING: Some services (web) use the 'configs' key, which will be ignored. Compose does not support 'configs' configuration - use `docker stack deploy` to deploy to a swarm.

Non pas que depuis la fusion de https://github.com/docker/cli/pull/569 , à partir du 18.03, docker stack deploy prendra en charge la fusion de plusieurs fichiers de composition en un seul. Il ne remplace pas complètement la clé extends du format composefile v2 mais j'espère qu'il couvre bien plus de cas d'utilisation 👼

Ma propre solution de contournement consistait à utiliser yq (peut être combiné en une seule ligne si vous utilisez Bash):

yq merge --overwrite docker-stack.yml docker-stack.preprod.yml > merged-docker-stack.yml
docker stack deploy -c merged-docker-stack.yml preprod

@Lucas-C ce ne sont que des avertissements que la sortie inclura toujours vos clés deploy et config . Vous pouvez le vérifier si vous exécutez docker-compose -f docker/prod.yml -f docker/dev.yml config

C'est pour composer des fichiers v3.4 et supérieur. Il prend en charge les références cross yaml (partielles). J'ai terminé avec ce script zsh alias/perl :

alias regen=$'perl -MFile::Slurp=read_file -MYAML=Load,Dump -MHash::Merge::Simple=merge -E \'
  local $YAML::QuoteNumericStrings = 1;
  $n=read_file("/data/docker-compose.yml");
  $s=Dump(merge(map{Load($n.read_file($_))}@ARGV));
  local $/ = undef;
  $s =~ s/\\bno\\b/"no"/g;
  say $s;
  \' $(find /data -mindepth 2 -maxdepth 4 -name docker-compose.yml) >! /data/x-docker-compose.yml'
regen
export COMPOSE_FILE=/data/x-docker-compose.yml

1. lire /data/docker-compose.yml avec la partie commune.
2. trouver tous les docker compose de manière récursive (par exemple, il y a environ 40 fichiers conteneurs/docker-compose.yml différents dans ce projet)
3. ajouter chaque docker-compose.yml avec le contenu /data/docker-compose.yml
4. fusionner
5. enregistrer le résultat dans /data/x-docker-compose.yml

Avantages : perl est un outil commun, tous les modules perl aussi, la génération est rapide.
Inconvénients : Je déteste les hacks mais il n'y a pas d'autre moyen pour DRY. Docker-compose final est d'environ 900 lignes. Voulez-vous vraiment que je le supporte en tant que fichier unique depuis le début ? Il est dommage d'avoir un docker binaire enveloppé avec python docker-compose enveloppé avec perl hack.

Comment pouvez-vous simplement retirer une fonctionnalité comme les extensions ? Cela semble être une fonctionnalité essentielle.

L'utilisation de docker-compose config redirigé vers l'option d'entrée standard de docker stack deploy -c - a résolu le problème pour moi :

docker-compose -f docker-compose.yml \
               -f docker-compose.extended.yml \
               config \
| docker stack deploy -c - my-stack

Je n'ai pas essayé cela, mais je viens également de le remarquer dans la documentation docker stack deploy :

Si votre configuration est divisée entre plusieurs fichiers Compose, par exemple une configuration de base et des remplacements spécifiques à l'environnement, vous pouvez fournir plusieurs indicateurs --compose-file .

Avec ceci comme exemple :

docker stack deploy --compose-file docker-compose.yml -f docker-compose.prod.yml vossibility

https://docs.docker.com/engine/reference/commandline/stack_deploy/#compose -file

La justification de la suppression de extends documentée quelque part ? Cela ne semble pas être expliqué dans les documents officiels, par exemple ici : https://docs.docker.com/compose/extends/#extending -services
Si les utilisateurs pouvaient comprendre la justification, alors les utilisateurs pourraient se faire une meilleure idée de la façon de réagir à la suppression. Merci.

@shaun-blake J'ai fini par utiliser les multiples fichiers de composition. Cela semble être l'approche que les gens utilisent. Plutôt qu'un héritage, c'est plus comme un mix-in. Lors de la construction ou de l'exécution, je copie le modèle yaml de l'environnement correct dans docker-compose.override.yml.

Plusieurs fichiers de composition docker (par exemple : base.yml , local.yml , prod.yml ) ne permettent pas au service d'utiliser les ancres YAML d'autres fichiers, de sorte que les définitions de service factorisées n'ont pas pu être définies parmi plusieurs fichiers yml .
Attention, ce numéro est le 13ème le plus commenté : https://github.com/moby/moby/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc et le 3ème le plus aimé .

Si les utilisateurs pouvaient comprendre la justification, alors les utilisateurs pourraient se faire une meilleure idée de la façon de réagir à la suppression. Merci.

+1 sur la documentation sur la justification de la suppression de extends en premier lieu...

Toujours pas d'extensions après presque 1 an et demi plus tard. Allez, les développeurs, vous ne supprimez pas qc sans donner une alternative.

Ils l'ont fait, ils proposent une alternative appelée composition. S'il vous plaît lire ma réponse dans le fil.

-Philippe

Le 30 juillet 2018, à 09h41, Xiaohui Liu [email protected] a écrit :

Toujours pas de prolongation après presque 1 an et demi plus tard. Allez, les développeurs, vous ne supprimez pas qc sans donner une alternative.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub https://github.com/moby/moby/issues/31101#issuecomment-408790200 , ou coupez le fil de discussion https://github.com/notifications/unsubscribe-auth/AAS_0AOynjpfVnVo4ZqciMbmjBmkcMbNq4ks5MDuLs .

@dedalozzo , "dans le fil" == ?

S'il vous plaît voir mon commentaire ici:

https://github.com/moby/moby/issues/31101#issuecomment -329527600 https://github.com/moby/moby/issues/31101#issuecomment-329527600

Fondamentalement, vous devez utiliser une chaîne de fichiers .yml pour remplacer ou modifier la configuration de vos conteneurs.

Veuillez lire « Spécification de plusieurs fichiers de composition »

Vous pouvez fournir plusieurs fichiers de configuration -f. Lorsque vous fournissez plusieurs fichiers, Compose les combine en une seule configuration. Compose crée la configuration dans l'ordre dans lequel vous fournissez les fichiers. Les fichiers suivants remplacent et s'ajoutent à leurs prédécesseurs.

https://docs.docker.com/compose/reference/overview/ https://docs.docker.com/compose/reference/overview/

Cette approche utilise la composition plutôt que l'héritage pour obtenir, plus ou moins, le même résultat.

Le 30 juillet 2018, à 15h23, Serban Teodorescu [email protected] a écrit :

@dedalozzo https://github.com/dedalozzo , "dans le fil" == ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/moby/moby/issues/31101#issuecomment-408880809 , ou coupez le fil https://github.com/notifications/unsubscribe-auth/AAS_0FZO30NplqHRid_Id8VBOJW7nk5Iks5uLx4biga

Ne serions-nous pas en mesure de récupérer la même extensibilité si nous combinons
champs d'extension yaml (composer 2.1+/3.4+)
en autorisant ces champs x- à référencer d'autres fichiers ?

Nous pourrions donc autoriser une liste racine include pour spécifier les fichiers à charger.
ils seraient placés dans un x-include et seraient instantanément utilisables via les ancres et la fusion YAML standard.

# /docker-compose.yml
version: '2.1'

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    extends:
      file: reverse_proxy/docker-compose.yml
      service: proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    extends:
      file: reverse_proxy/docker-compose.yml
      service: proxy
    restart: 'always'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    extends:
      file: webservice/docker-compose.yml
      service: app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    extends:
      file: webservice/docker-compose.yml
      service: app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

# /proxy/docker-compose.yml
version: '2.1'
services:
  proxy:
    build: ./
    volumes:
      - /certs:/certs:ro

# /webservice/docker-compose.yml
version: '2.1'
services:
  app:
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1

# /proxy/docker-compose.yml
version: '3.9'
services:
  proxy:
    &proxy
    build: ./
    volumes:
      - /certs:/certs:ro

# /webservice/docker-compose.yml
version: '3.9'
services:
  app:
    &app
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1

# /docker-compose.yml
version: '3.9'
include:
  - /proxy/docker-compose.yml
  - /webservice/docker-compose.yml

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    restart: 'always'
    << : *proxy
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    restart: 'no'
    extends:
      file: web1/docker-compose.yml
      service: app
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

@@ /proxy/docker-compose.yml @@
-version: '2.1'
+version: '3.9'
 services:
   proxy:
+    &proxy
     build: ./
     volumes:
       - /certs:/certs:ro
 ```

 ```diff
 @@ /webservice/docker-compose.yml @@
-version: '2.1'
+version: '3.9'
 services:
   app:
+    &app
     build:
       context: ./folder
       args:
         LINUX_VERSION: 20.s
         LINUX_FLAVOR: dash
     environment:
       - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
       - bootstrap.memory_lock=true
     ulimits:
       memlock:
         soft: -1
         hard: -1
 ```

 ```diff
 @@ /docker-compose.yml @@
-version: '2.1'
+version: '3.9'
+include:
+  - /proxy/docker-compose.yml
+  - /webservice/docker-compose.yml

 volumes:
   nginx_file_sockets:
     external: false
     driver: local

 services:
   reverse_proxy:
-    extends:
-      file: reverse_proxy/docker-compose.yml
-      service: proxy
+    << : *proxy
     restart: 'always'
     ports:
       - "80:80"
       - "443:443"
     volumes:
       - nginx_file_sockets:/sockets/nginx

   reverse_proxy_test:
-    extends:
-      file: reverse_proxy/docker-compose.yml
-      service: proxy
+    << : *proxy
     restart: 'no'
     ports:
       - "8080:80"
       - "8443:443"
     volumes:
       - nginx_file_sockets:/sockets/nginx

   web:
-    extends:
-      file: webservice/docker-compose.yml
-      service: app
+    << : *app
     restart: 'always'
     environment:
       ENVIRONMENT: 'production'
       DB_USER: ${WEB1_DB_USER}
       DB_PASSWORD: ${WEB1_DB_PASS}
     volumes:
       - nginx_file_sockets:/sockets/nginx

   web_staging:
-    extends:
-      file: webservice/docker-compose.yml
-      service: app
+    << : *app
     restart: 'no'
     environment:
       ENVIRONMENT: 'staging'
       DB_USER: ${WEB1_DB_USER}
       DB_PASSWORD: ${WEB1_DB_PASS}
     volumes:
       - nginx_file_sockets:/sockets/nginx
 ```
<hr>
Resulting in the final version, which should be already yaml parsable:

```yml
# /docker-compose.yml
version: '3.9'
#include:
#  - /proxy/docker-compose.yml
#  - /webservice/docker-compose.yml
x-include:
  /proxy/docker-compose.yml:
    version: '3.9'
    services:
      proxy:
        &proxy
        build: ./
        volumes:
          - /certs:/certs:ro
  /webservice/docker-compose.yml:
    version: '3.9'
    services:
      app:
        &app
        build:
          context: ./folder
          args:
            LINUX_VERSION: 20.s
            LINUX_FLAVOR: dash
        environment:
          - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
          - bootstrap.memory_lock=true
        ulimits:
          memlock:
            soft: -1
            hard: -1

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    << : *proxy
    restart: 'no'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    << : *app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

AFAIK, c'est une fonctionnalité YAML, intégrée dans la spécification de langue elle-même, pour éviter de répéter des parties dans le même fichier. Lorsque vous utilisez différents fichiers, c'est fondamentalement impossible.

Vous devez proposer cette fonctionnalité à la spécification YAML elle-même.

Cette discussion brûle :

• Comment docker-compose -f file.yml est-il tellement meilleur que docker-compose -f file.yml -f file_extension.yml ?
• Ou : câblage au niveau commande _vs_ câblage au niveau fichier.

Ce n'est que lorsque l'on travaille sur la ligne de commande que l'inconvénient devient notable. Nous devons le reconnaître un instant. Tout le reste est scriptable, de toute façon.

Si c'est le vrai argument, alors docker-compose up service a une meilleure sémantique que docker-compose -f service.yml up : définissez tout ce qui est nécessaire pour le développement local (aka sur la ligne de commande) dans docker-compose.override.yml .

La sémantique donnée est très propre et bien pensée. Adopter service.yml _pour la ligne de commande use_ signifie probablement abaisser l'UX. Il y a un autre argument : bien qu'il soit clair à première vue, ce qu'est un docker-compose.yml , un service.yml peut être n'importe quoi, vraiment n'importe quoi.

Avis de non-responsabilité : une opinion provocatrice. :wink: Je n'ai pas pris en compte tous les cas d'utilisation possibles...

Après cette longue discussion, je ne sais pas si cela arrivera un jour. À mon humble avis, les extensions étaient cool et ont dû être au moins soigneusement désapprouvées, puis discutées au lieu de simplement les laisser tomber.

Je pense qu'une chose que nous pourrions faire est d'améliorer l'histoire de la documentation sur la v2 par rapport à la v3. Beaucoup supposent que la v3 a remplacé la v2, mais ce n'est pas tout à fait vrai. Les deux reçoivent de nouvelles fonctionnalités qui se concentrent sur leurs cas d'utilisation. Ce problème GH a été lancé afin que nous puissions discuter des futures fonctionnalités nécessaires pour passer de docker-compose à Swarm, et comment améliorer la documentation pour utiliser docker-compose, le format de fichier de composition et les piles Swarm ensemble. Extends fonctionne toujours très bien dans la mise à jour v2.4. J'espère pouvoir vous aider à fournir des informations sur les solutions que nous avons aujourd'hui :

v2 : pour la cli docker-compose uniquement. Flux de travail de développement axé sur une seule machine et un seul moteur. Convient également aux workflows de build/test CI. Cette branche de version a reçu de nouvelles fonctionnalités aussi récentes que décembre 2017 dans la v17.12

v3 : Idéal pour les piles Swarm/Kube, avec des concepts multi-nœuds et maintient la prise en charge de la plupart des fonctionnalités cli de docker-compose.

Si vous n'utilisez pas les piles Swarm ou Docker Enterprise Kubernetes, il n'y a aucune raison d'utiliser la v3 . Restez avec la v2.4, et vous obtenez toutes les fonctionnalités cli de docker-compose, y compris les extensions, les depend_on, les champs d'extension et même les depend_on avec les contrôles de santé (pour éviter les scripts d'attente).

La v3 a été créée pour essayer de fusionner les fonctionnalités d'un monde cli docker-compose à moteur unique avec un monde de cluster multi-nœuds. Toutes les fonctionnalités v2 (comme depend_on) n'ont pas de sens dans un cluster. D'autres fonctionnalités (comme extend) n'ont tout simplement pas été intégrées à la v3, probablement parce qu'avant l'existence de la v3, tout le code était dans Docker-compose Python, et pour que la v3.0 prenne en charge Swarm, ils ont dû le réécrire dans docker cli Go, et maintenant ils l'écrivent à nouveau dans le démon du moteur pour éventuellement créer une API de piles Swarm, qui n'existe pas encore.

Pour ceux qui découvrent ce problème, notez également une grande partie du travail effectué pour résoudre divers problèmes de configuration, de modèles et de workflow d'équipe depuis la version 3.0 :

• 3 fonctionnalités que j'aborde brièvement dans cet article (env vars, templates et compose scope)
• remplacer les fichiers, docker-compose config et les fichiers .env
• docker-app modèle expérimental et emballage cli. REGARDE ÇA
• prochaine interface graphique de docker-compose (teaser à la keynote DockerCon 2018)

Les documents sur https://docs.docker.com/compose/extends/#extending -services doivent souligner en rouge le fait que le mot-clé extend est supprimé dans la v3, car il est plus important qu'une simple _note_.
J'ai migré et parcouru les documents pour savoir pourquoi cela ne fonctionnait plus, puis j'ai suivi plusieurs problèmes fermés avant de me retrouver ici, puis je suis revenu aux documents d'origine et j'ai remarqué le libellé.

Le mot-clé extend est pris en charge dans les formats de fichier Compose antérieurs jusqu'à la version de fichier Compose 2.1 (voir extend dans v1 et extend dans v2), mais n'est pas pris en charge dans Compose version 3.x.

Pourrait être reformulé comme :

Le mot-clé extend a été supprimé dans Compose version 3.x, mais est toujours pris en charge dans les formats de fichier Compose antérieurs jusqu'à la version 2.1 du fichier Compose (voir extend dans v1 et extend dans v2).

C'est une petite différence, mais qu'il est facile de négliger lors de l'écrémage des documents.

@krisrp PR a commencé ^^^

Merci @BretFisher

Est-il prévu de renommer la v2 en « version : docker-cli » et la v3 en « version : swarm/kube » ?
Il serait plus logique de les différencier de cette manière, compte tenu de la façon dont la v3 remplace la v2 dans la plupart des autres schémas de version. À l'heure actuelle, les deux sont maintenus et divergents, donc à moins que je ne me trompe, il semble qu'ils seront tous les deux dans les parages pendant un certain temps.

@krisrp Au contraire, la raison de l'incrémentation d'un numéro de version majeur est de signaler la divergence de compatibilité.

@ cpuguy83 Je ne voulais pas dire le contraire. Désolé de ne pas avoir été plus clair ou explicite.
IIRC Gnome 2 & 3 a également eu cette confusion il y a des années lorsque des fourches indépendantes de chacun ont été maintenues.

Je ne veux pas faire dérailler ce fil pour discuter de la sémantique du versioning (mauvais jeu de mots), donc je vais en rester là. Le post de @BretFisher la semaine dernière sur l'amélioration de la documentation sur v2 vs v3 m'aurait aidé et probablement d'autres.

@ shin- @cpuguy83 En regardant ce problème plus d'un an plus tard, quelle _est_ la raison pour ne pas l'ajouter dans la version 3 ?

Je n'ai pas trouvé grand-chose à ce sujet, à part "nous pourrions le faire différemment" (mais aucune meilleure solution n'est proposée)
Y a-t-il une limitation technique ? Ou simplement un manque de pull request ?

Après tout, mes fichiers de composition 2.1 fonctionnent toujours correctement.

Non seulement cela, mais le journal des modifications indique "cela a été supprimé, voir "comment mettre à niveau" pour plus de détails". Je regarde "comment mettre à niveau" pour, vous savez, des détails sur la façon de mettre à niveau, et ce que cela dit est "voir" étendre les services "pour plus de détails". Je vais dans "extension des services" en pensant que je verrai enfin un moyen d'étendre mes fichiers, seulement pour voir "cela a été supprimé, voir le journal des modifications pour plus de détails".

À ce stade, cela semble être une blague cruelle que joue le rédacteur de la documentation.

En fin de compte, le format "pile" n'est pas contrôlé ici et fait partie de la Docker CLI.

Personnellement, je ne sais pas pourquoi il a été exclu de la v3... Je ne pense pas non plus avoir vu quelqu'un essayer de l'ajouter.
Il serait peut-être préférable d'aborder cela dans docker/cli... peut-être même juste un PR avec un changement de document de haut niveau qui agit comme si la fonctionnalité était là afin qu'elle puisse être discutée et que la mise en œuvre puisse être ajoutée une fois la conception approuvée .

En gros, si quelqu'un le veut, faites un PR. Je suggère le changement de doc juste pour vous assurer que vous ne perdez pas une tonne de temps au cas où il serait rejeté... car encore une fois, je ne sais pas pourquoi il a été omis de la v3.

Comme ci-dessus. Attendez que cela soit résolu avant d'utiliser à nouveau docker-compose.

+1 s'il vous plaît corrigez ce problème, nous avons des fichiers de composition basés sur l'extension et ne pouvons pas utiliser composer pour swarm à cause de cela.

+1 pour la fonctionnalité d'extension

des nouvelles à ce sujet?

Je l'attends toujours

Pareil ici. Toujours en attente.

Toute mise à jour?

Y a-t-il déjà eu une raison pour laquelle il a été retiré ?

Le lundi 5 août 2019, à 11 h 10, Jaykishan, [email protected] a écrit :

Toute mise à jour?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/moby/moby/issues/31101?email_source=notifications&email_token=ABOE6GA4CXY6ESMZMTDSFGDQC74CZA5CNFSM4DANZGS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX2HJKLOTN5WRLZHJKLORBW
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABOE6GCEFFJ3SOLDWRWX2IDQC74CZANCNFSM4DANZGSQ
.

Toute mise à jour?

alors... ça fait presque 3 ans...
mais j'ai encore espoir qu'il atterrira :D

Il doit y avoir une sorte d'alternative aux extensions si cela ne revient pas. Pourquoi ne pas autoriser les services abstraits ? Le format de fichier serait plat et toutes les déclarations de service seraient dans un seul fichier. Vous pouvez utiliser des services abstraits en conjonction avec la capacité de yaml à ajouter des alias pour un nœud (via un & ) réutiliser ces alias via l'opérateur <<: .

Pourquoi 3 ans !! il semble que vous travaillez et que vous vous concentrez sur des choses dont personne ne se soucie

Une mise à jour pour ceci?

C'est pathétique. Terraform utilise la composition - c'est donc faisable, pourquoi composer n'est pas capable de suivre cette bonne pratique de conception ?!
Composition des modules Terraform
Meilleures pratiques Terraform

"pathétique", sympa.

@Cristian-Malinescu Allez-y, mettez-le en œuvre s'il vous plaît.
Il s'agit d'un logiciel gratuit et open source.

Au lieu de se plaindre comme tout le monde dans ce chat.
Cela n'ajoute tout simplement aucune valeur ici, vraiment.
Comme dit à plusieurs reprises, personne n'a voulu mettre cela en œuvre jusqu'à présent,
donc c'est juste un problème que quelqu'un d'autre devrait résoudre k, merci.

@luckydonald Merci de repousser @Cristian-Malinescu avec une réponse facile/passive-agressive, c'est, comme toujours, ne pas aider. @Cristian-Malinescu C'est faisable car cela a déjà été fait auparavant mais supprimé, il doit (j'espère) y avoir une raison. Y a-t-il quelqu'un sur ce fil actuellement dans l'équipe docker-compose afin qu'il/elle puisse faire la lumière sur le question?

Le fil de discussion a été parcouru et l'exploitation des fonctionnalités YAML prises en charge a été mentionnée.

J'ai pensé que cet exemple pourrait aider.

@nomasprime merci pour cette trouvaille ! Je décidais entre v2 et v3 pour mon projet, et cela a résolu le grand dilemme dans ce fil. Surpris que ces solutions alternatives ne soient pas mentionnées dans la documentation officielle de la

Bien, cela semble être une bonne occasion d'utiliser le lien Request docs changes dans la barre de navigation de droite de la page de documentation.

@nomasprime Oui, cette idée était déjà présente dans ce fil.

Si cela pouvait être combiné à un mécanisme de chargement de fichiers pour d'autres fichiers yml, c'est tout ce qu'il faut vraiment pour avoir toutes les anciennes fonctionnalités depends .

Voir ci-dessus, par exemple https://github.com/moby/moby/issues/31101#issuecomment -413323610

Ce ne serait pas très _lisible_, mais ce serait au moins _possible_.

@nomasprime merci pour cette trouvaille ! Je décidais entre v2 et v3 pour mon projet, et cela a résolu le grand dilemme dans ce fil.

@arseniybanayev L'article sur le support ne parle que de la v3, mais les versions plus récentes de la v2 prennent également en charge les ancres et les champs d'extension . Dans mon cas, je choisis la v2 (2.4 plus précisément) car j'utilise docker-compose et non swarm (et la v3 ne prend pas en charge certaines fonctionnalités de la v2 comme la limitation de la mémoire du conteneur )

et la v3 ne prend pas en charge certaines fonctionnalités de la v2 comme la limitation de la mémoire du conteneur

v3 prend en charge la limitation de la mémoire, mais le champ est inférieur à deploy -> resources -> limits https://docs.docker.com/compose/compose-file/#resources

@thaJeztah Je veux dire, pour docker-compose (parce que je n'utilise pas swarm dans le projet auquel je

Serait-il judicieux de créer une configuration distincte pour swarm et local ? On dirait que ces deux sont en conflit l'un avec l'autre. Naturellement, Docker aimerait que l'utilisation de Swarm soit augmentée, mais beaucoup de gens n'utilisent compose que pour le développement local.

Pour ma part, je n'ai jamais utilisé de conteneurs swarm and run en production avec ECS, k8s ou GAE.

La plupart des options doivent être traduisibles/utilisables à la fois pour les services swarm/kubernetes et pour les conteneurs déployés via compose. Je devrais vérifier pourquoi les limites de memory ne seraient pas applicables pour docker-compose

il manque toujours la fonctionnalité d'extension, mais pour mon cas d'utilisation principal, je suis passé à plusieurs fichiers de composition docker via le COMPOSE_FILE env. Je l'utilise principalement pour utiliser la même base docker-compose.yml pour dev et prod avec des mots de passe ou une configuration différents.

Exemple:

• sur dev : export COMPOSE_FILE= docker-compose.yml` # par défaut
• sur prod : export COMPOSE_FILE= docker-compose. yml:docker-compose.prod.yml ` # utilise les deux fichiers yaml

Dans docker-compose.prod.yml je viens d'écraser les vars env avec les mots de passe prod.

Cette configuration est simple et je n'ai pas besoin de toujours ajouter plusieurs "-f" à la commande docker-compose . J'ai juste besoin de définir la variable env COMPOSE_FILE différente sur l'ordinateur de développement et le serveur et git ignorer le fichier docker-compose.prod.yml.

Toujours en attente :)

J'ai utilisé ceci comme un moyen d'étendre:

docker-compose \
  -f ./docker/base.yml \
  -f ./docker/extended.yml \
  up

Mais étendre dans le fichier serait plus agréable, pas besoin d'un script bash supplémentaire.

J'ai également utilisé ceci pour étendre dynamiquement le script bash :

extended_docker_compose="
  version: '3.5'
  services:
    my-service:
      restart: always
"

echo "$extended_docker_compose" | docker-compose \
  -f ./docker/base.yml \
  -f /dev/stdin \
  up

@dave-dm ce sont de vieilles dérogations !

Je pense qu'il s'agit d'un cas d'utilisation potentiellement valide pour les extensions

https://github.com/NerdsvilleCEO/devtools/blob/master/doctl/docker-compose.yml#L10

J'ai un wrapper docker-compose que j'utilise pour un env de services https://github.com/nowakowskir/docker-compose-wrapper

EDIT : un autre cas d'utilisation possible est que quelqu'un a une pile LAMP/LEMP et qu'il souhaite étendre ces services pour les utiliser avec un service spécifique tel que wordpress

Toujours en attente depuis 2017 tout en explorant les alternatives de Docker Compose.

@nomasprime Oui, cette idée était déjà présente dans ce fil.

Si cela pouvait être combiné à un mécanisme de chargement de fichiers pour d'autres fichiers yml, c'est tout ce qu'il faut vraiment pour avoir toutes les anciennes fonctionnalités depends .

Voir ci-dessus, par exemple #31101 (commentaire)

Ce ne serait pas très _lisible_, mais ce serait au moins _possible_.

@luckydonald merci de l'avoir signalé. Bizarre, il n'y a pas de fonctionnalité d'inclusion de YAML intégrée , cela résoudrait certainement beaucoup de problèmes.

On dirait qu'il serait assez facile de mettre en œuvre une solution tierce, donc je ne sais pas pourquoi cela n'a pas été transféré à la v3 🤷‍♂

Un petit rappel que beaucoup de gens aimeraient cette fonctionnalité :)

Quelle est la raison de ne pas le porter sur la v3 d'ailleurs ?

J'ai oublié, mais y a-t-il une raison réelle pour laquelle il a été retiré ?

Le mer. 6 mai 2020, 23:14 Julien Marechal, [email protected] a écrit :

Un petit rappel que beaucoup de gens aimeraient cette fonctionnalité :)

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/moby/moby/issues/31101#issuecomment-624919070 , ou
Se désabonner
https://github.com/notifications/unsubscribe-auth/ABOE6GGDIVGATP734YJA4UTRQHOLJANCNFSM4DANZGSQ
.

La façon dont les ancres yaml gèrent ce cas d'utilisation est un peu gênante par rapport à extend . Son pouvoir, à mon avis, provenait en grande partie de la fusion récursive d'éléments. Les ancres vous amènent peut-être 75% du chemin - elles ne fusionnent pas yaml de manière récursive ; toutes vos fusions se font au plus haut niveau. Le référencement d'un modèle de service ancré, puis la redéfinition du bloc environment entraîneront l'écrasement du bloc d'environnement du service ancré au lieu de la fusion. Vous devrez ancrer et référencer chaque dictionnaire dans une arborescence récursive de dictionnaires afin de correspondre au comportement du mot-clé extend .

Un exemple:

# anchors for the service, environment, deploy, and deploy.placement blocks
# you'll need an anchor for every dict that you want to merge into
x-common-app: &common-app
  image: app:1.0
  environment: &common-app-environment
    common_option: a
    overwrite_option: b
  deploy: &common-app-deploy
    max-replicas-per-host: 3
    placement: &common-app-deploy-placement
      constraints:
        - 'node.labels.app_host==true'

services:
  myapp: << *common-app
    environment: << *common-app-environment
      foo: bar
      baz: xyzzy
      overwrite_option: quz
    deploy: << *common-app-deploy
      replicas: 15
      placement: << *common-app-deploy-placement
        preferences:
          - spread: node.labels.region

# The above yields the following:
services:
  myapp:
    image: app:1.0
    environment:
      common_option: a
      overwrite_option: quz
      foo: bar
      baz: xyzzy
    deploy:
      replicas: 15
      max-replicas-per-host: 3
      placement:
        constraints:
          - 'node.labels.app_host==true'
        preferences:
          - spread: node.labels.region

Cela peut ne pas sembler si ennuyeux dans cet exemple, mais cela devient ennuyeux et moins lisible si vous modélisez plusieurs services (10+) à partir d'un bloc d'extension.

Dans mon esprit, un scénario idéal est une combinaison de l'approche d'ancrage yaml et de l'approche extend --autorisez extend ing uniquement à partir d'un bloc de champ d'extension préfixé x- niveau supérieur, avec les caractéristiques de fusion les plus intelligentes.

Dans mon organisation, nous avons trouvé que les ancres yaml étaient un peu bâclées sur le plan syntaxique, nous avons donc réimplémenté la fonctionnalité extend dans un script python externe. Cela fonctionne pour nous, mais c'est une façon boiteuse d'avoir à faire face à quelque chose. De même, nous avons dû créer notre propre outil externe pour gérer la suppression de depends_on pour les piles v3/Swarm.

J'ai fait beaucoup de gitlab CI YAML ces derniers temps. Il possède exactement ces fonctionnalités, qui sont tellement agréables pour obtenir des modèles et des configurations finales lisibles et gérables :

• Vous pouvez inclure d' autres fichiers YAML (idéal pour les modèles)
• Vous pouvez étendre (même à travers des projets/en utilisant des ressources distantes via https). La documentation d'extension décrit exactement ce que @a-abella décrit pour le format de composition.
• Vous pouvez également vous « cacher » pour ne pas être considéré comme la vraie substance. Au format de composition, c'est x- , dans gitlab CI c'est un . initial

C'est l'ensemble exact de fonctionnalités qui rend ces fichiers supportables.

Je suis arrivé à ce problème à partir de la documentation de docker, dans mon cas, je voulais modéliser ma configuration docker-compose , et comme "solution de contournement", j'ai suivi les conseils ci-dessus et j'ai décidé de rechercher un programme de modèles existant. Je ne récupérerai pas ces heures, alors je détaille un peu ce que j'ai trouvé ici, indépendamment de toute discussion sur cette demande de fonctionnalité réelle, cependant, il se peut que les personnes impliquées ressentent l'utilisation d'un système de modèles basé sur YAML pour générer un fichier de composition plutôt que d'intégrer cette fonctionnalité dans docker-compose lui-même pourrait être plus approprié en termes d'encapsulation et de choix du bon outil pour le travail.

Pour certains contextes, j'utilise un proxy inverse de base avec Let's Encrypt et plusieurs conteneurs d'applications (Nextcloud pour l'instant, un pour moi et quelques-uns séparés pour les amis) - dans ce cas, je voulais créer un modèle des conteneurs Nextcloud afin que j'évite les erreurs et les doublons avec les frappes pour des configurations très similaires. J'ai essayé les packages suivants :

• ytt
• Dhall
• SIGNAL
• Jsonnet

ytt semble très complet et est la seule option pour utiliser YAML nativement. Il semblait puissant et le bon outil pour le travail, et il utilise Starlark, un sur-ensemble de Python, directement dans le fichier YAML pour effectuer le traitement. Cependant, après peu de temps, le modèle est devenu très désordonné, et la litière de fragments de code et de fragments de YAML, ainsi que le mélange de types de données Python comme des dictionnaires et des tableaux et des fragments YAML (qui semblent être quelque peu traités comme du texte, un peu comme utiliser un moteur de modèle HTML qui génère des balises telles que des chaînes) a finalement entraîné trop d'erreurs et un fichier trop désordonné. Dhall semble également très complet et utilise une langue native unique qui peut être sortie dans une variété de formats ; Cela ressemble plus à un langage de métaprogrammation qu'à un système de template, cependant étant donné que la syntaxe est fonctionnelle et qu'elle est assez strictement typée, elle est rapidement devenue plus complexe qu'il n'en valait pour un simple template pour YAML non structuré. Comme ce qui ressemble un peu à un mélange de JSON et de Haskell, il a fallu trop de réflexion pour intégrer ce dont j'avais besoin dans le langage.

Fait intéressant, quelque chose qui était difficile à la fois avec Dhall et ytt utilisait des noms de champs paramétrés, les deux auraient assez bien fonctionné autrement, mais je dois faire apparaître le nom de mon instance dans les noms de services et les noms de volume, et dans les deux atteindre c'était un peu laid ; utiliser des arguments pour les valeurs dans un hachage est facile, mais utiliser ces arguments dans les noms des clés était compliqué ou je ne pouvais pas trouver comment le faire proprement, de plus Dhall applique la sécurité de type et cela va tout simplement à l'encontre de ce concept. Avec Jsonnet, c'était aussi simple que de mettre l'expression entre crochets.

CUE et Jsonnet sont tous deux orientés JSON, mais les exécuter via un convertisseur n'est pas difficile du tout, et il semble encore une fois, comme Dhall, CUE a beaucoup de fonctionnalités puissantes et est né des lacunes de Jsonnet, mais à mi-chemin dans la documentation , il est devenu évident que c'était déjà exagéré ; peut-être qu'avec beaucoup plus de temps pour l'apprendre correctement, ce serait l'option supérieure, mais il semble que CUE soit plus orienté vers la validation et les schémas qu'un simple travail de modèle et je suis donc rapidement passé à Jsonnet et j'ai terminé le travail assez rapidement.

Enfin, ce n'est qu'après avoir terminé tout cela que j'ai réalisé tout le temps que j'avais comparé ces outils à la simplicité des balises Liquid ou des modèles HTML similaires, que j'aurais probablement pu utiliser Liquid en premier lieu. Je ne l'ai utilisé que dans le contexte d'un site Jekyll, il ne m'est donc jamais arrivé d'obtenir un package autonome, mais avec des boucles et des listes de base, et la possibilité d'évaluer les expressions directement en texte sur place, cela aurait probablement été un bien meilleur aussi pour le travail; Jsonify est probablement supérieur pour JSON, mais Liquid pourrait fonctionner en YAML pur et ainsi le fichier redeviendra plus lisible.

+1 docker-compose a été l'une des inspirations de la solution sur mesure que j'ai implémentée au travail depuis que ce ticket a été créé pour prendre en charge la migration d'un grand nombre d'environnements de test vers k8. J'ai fait très attention à éviter les cloches et les sifflets mais j'ai assez rapidement justifié une fonctionnalité analogue. La discussion philosophique (composition versus héritage etc.) m'apparaît comme une distraction du bon sens (avec le bénéfice du recul - toujours non résolu près de 3 ans plus tard). De toute évidence, il est requis par les personnes qui pourraient continuer à utiliser docker-compose.

+1 :+1:

J'ai beaucoup utilisé cette fonctionnalité auparavant pour les environnements dev / test / ci , où je pouvais étendre à partir d'un fichier de composition dans des chemins de sous-répertoire de ./config/{dev,test,ci}/compose.yaml . J'aurais un .env qui avait COMPOSE_ENV=dev , mais les développeurs pourraient remplacer, et évidemment je remplacerais en ci .

Je suis choqué de déprécier la fonctionnalité et de ne pas la remplacer par quelque chose qui peut faire quelque chose de similaire. Peut-être nous permettons-nous simplement d'utiliser jinja2 et de faire ce que nous voulons. J'espère que Docker-Compose serait moins anti-DRY. :'(

Il semble que extends soit pris en charge par docker-compose depuis la v1.27 (https://github.com/docker/compose/pull/7588).

Un cas d'utilisation où j'utilise beaucoup la fonctionnalité consiste à versionner les images Docker en code. Mes fichiers docker dev et prod composent s'étendent tous deux de docker-images.yml où seul le service de base est répertorié et une version étiquetée de l'image du service.

Je n'ai pas trouvé de solution de contournement facile pour cela dans la v3.