Compose: Définir les services qui ne sont pas démarrés par défaut

+1 pour l'option 1

Je pense que l'ajout de services qui ne font pas réellement partie d'une composition, mais qui doivent simplement s'y lier / s'y attacher, est un mauvais choix de conception. Il existe quelques autres cas d'utilisation qui pourraient être résolus en autorisant une forme de syntaxe d'inclusion. Résoudre plusieurs problèmes avec une seule fonctionnalité est toujours agréable.

Certains de ces problèmes (ceux qui concernent les conteneurs de données uniquement, # 942, le dernier commentaire de @ cpuguy83) sont en fait déjà résolus par # 1754, je ne pense pas que nous devions les considérer comme un problème (après 1.5 ).

Nous développons des extensions Magento. Pour ce faire, nous avons besoin d'un moyen simple d'exécuter une boutique en ligne sur une pile LAMP. Compose rend cela facile. Mais nous voulons aussi exécuter phpunit, divers outils d'analyse statique, des constructeurs de documentation, etc. En fait, la grande majorité de nos "services" ne sont que des commandes, comme docker-compose run --rm phplint . Idéalement, une commande non qualifiée comme

docker-compose up -d

ne démarrerait qu'un service de longue durée (les _services_ réels), et ne déclencherait pas d'autres effets comme phpunit, inutilement. (Il est également important de ne pas déclencher des choses dans le désordre, comme l'exécution de tests Selenium avant la mise en service du service Web.)

Tout ce que nous essayons vraiment de faire est d'éliminer la douleur de la gestion de l'environnement des développeurs, et non d'exécuter des services de production. Je ne sais pas si le commentaire de @dnephin est représentatif de la direction que Compose prend ou non, mais il me semble ambigu de savoir si Compose envisage toujours de servir le créneau dans lequel Fig a commencé. (Parce que, pour être clair, je pense que l'option 1 ne prend pas en charge la facilité d'utilisation dont les développeurs ont besoin pour l'utiliser comme Fig apparemment prévu.) Je comprends tout à fait si Compose ne veut pas avoir plusieurs responsabilités, mais j'espère que quelqu'un pourra nous le faire savoir, clairement, si ceux d'entre nous qui utilisent ce produit pour des environnements de développement rapides et isolés doivent prendre une autre direction.

@kojiromike , de quoi s'agit-il (1) qui ne convient pas à votre cas d'utilisation? S'agit-il uniquement de la sémantique des commandes ( docker-compose run --rm phplint vs docker-compose --file phplint.yml up )?

C'est que docker-compose up -d essaie de «démarrer» phplint et docker-compose ps signale que le «service» phplint est en panne. En réalité, ce n'est pas un conteneur de services, c'est un conteneur d'outils, il ne devrait avoir aucun concept de haut / bas. J'ai cru comprendre que les conteneurs d'outils sont adoptés par docker (c'est ainsi que vous exécuteriez quelque chose comme redis-cli, clairement pas un «service») et bien que je les utilise davantage en développement, je pense qu'ils ont aussi une place pour la production; comme pourquoi disons que awk installé sur des machines de production ou dans des conteneurs, pourquoi ne pas l'exécuter via un conteneur avec des liens pour en tirer un comportement prévisible.

: +1: Je me retrouve régulièrement à vouloir créer un conteneur tests côté de mes autres services pour encapsuler des tests unitaires en cours d'exécution. Ma "solution de contournement" consiste à définir la commande sur "/ bin / true" et à exécuter le conteneur avec la commande de test unitaire spécifiée sur la CLI. Pouvoir spécifier quels conteneurs doivent commencer à up time serait génial!

(btw, beau travail tout autour, les gars)

cc @jameydeorio

@ryneeverett La sémantique en fait partie. C'est un problème d'auto-documentation et de trouvabilité. Actuellement, nous disons aux développeurs docker-compose run --rm foo bar . Nous les invitons à créer une fonction shell ou un alias, mais nous ne maintenons pas d'alias / rcfile standard pour les projets. (Nous ne voulons pas standardiser les choses en dehors des conteneurs; nous voulons utiliser Docker _to_ standardize.) L'ajout d'un nouveau fichier pour certaines commandes crée une hiérarchie d'importance: le fichier docker-compose.yml devient le fichier "par défaut" pour les choses, et le fichier «autre» devient moins important.

L'autre chose est simplement que le maintien des relations entre les services devient plus onéreux. Ce n'est pas parce que nous voulons que quelque chose ne s'exécute pas par défaut qu'il n'utilise pas un link ou un volume d'un service de longue durée. extends ne fournit pas réellement toutes les facilités dont nous aurions besoin pour lier des services à des "commandes" (services à exécution unique). Même si c'est le cas, si nous devons utiliser plusieurs fichiers yaml, nous serons obligés d'utiliser extends là où nous n'aurions pas besoin de le faire autrement.

extend ne fournit pas réellement toutes les fonctionnalités dont nous aurions besoin pour lier des services à des «commandes» (services à exécution unique). Même si c'était le cas, si nous devons utiliser plusieurs fichiers yaml, nous serons obligés d'utiliser des extensions là où nous n'aurions pas besoin de le faire autrement.

@kojiromike C'est ce que je soupçonnais. Je me demande si vous seriez satisfait de l'amélioration du support extends + un moyen de faire des sous-commandes (qui seraient fonctionnellement identiques à extends ) dans un seul docker-compose.yml . Mais peut-être que ce dernier est le même que (4).

2) Ajouter une option aux services pour les empêcher de démarrer par défaut

Je vote pour l'option 2. Par exemple, quelque chose comme une directive start: false . Les avantages sont que nous évitons le besoin de plusieurs fichiers compose.yml ou de fichiers de configuration supplémentaires, vous pouvez simplement lire un compose.yml pour avoir la sensation de l'ensemble de la pile d'applications.

Je pense que notre solution proposée pour https://github.com/docker/compose/issues/1987#issuecomment -139632238 gérera cela. Les services "admin" peuvent être définis dans une configuration séparée, et ajoutés avec -f lorsqu'une commande admin doit être exécutée sur une composition.

@dnephin La solution dans # 1987 (commentaire) _does_ gère les "services d'administration", mais elle _ne_ gère pas_ les "conteneurs de données uniquement", non? Vous devrez toujours utiliser la solution command: /bin/true contournement

Vous ne devriez pas avoir besoin de conteneurs de données uniquement avec compose car compose gérera l'échange des volumes contre des conteneurs recréés pour vous.

@ cpuguy83 Dans l'exemple suivant, le conteneur de données n'est pas vraiment nécessaire, mais si je veux changer le volume, je n'ai besoin de regarder qu'un seul endroit désigné.

nginx:
  image: nginx:1.9
  volumes_from:
  - data

php:
  image: php:5.6-fpm
  volumes_from:
  - data

data:
  image: debian:jessie
  volumes:
  - ./:/app

Cependant, je conviens qu'il s'agit d'un cas secondaire et que l'ajout d'une syntaxe supplémentaire n'en vaut probablement pas la peine. Je dis simplement que la solution proposée ne gère pas ce cas.

Certes, certaines commandes sont toujours requises pour les volumes de données, vous devrez donc utiliser une image minimale pour prendre en charge cette commande.

Je ne suis pas complètement à jour avec la nouvelle API de volumes qui sort, mais j'espère que nous pourrons ajouter une section volumes: à composer qui gérera mieux le volume de données. (au lieu d'exiger un conteneur pour eux).

Cela n'en fait pas nécessairement le bon choix, mais je pense que la courbe d'apprentissage / la facilité de compréhension devraient être envisagées.

J'ai l'impression que (2) est le plus simple à comprendre. Je n'ai pas vraiment de moyen de le confirmer, mais mon instinct dit que la plupart des gens qui ne sont pas intimement familiers avec toutes les options de docker-compose qui se heurtent au problème que nous essayons de résoudre ici disent: "J'aurais aimé qu'il y ait un moyen d'amener ce conteneur à _pas démarrer_ quand j'exécute docker-compose up ," et ils voient start: false et bam, nous avons terminé et heureux.

Ils ne disent pas: "Si seulement il y avait un moyen de créer un deuxième fichier avec une histoire de lien maladroite pour résoudre cela ..." (bien que je réalise que https://github.com/docker/compose/issues/ 1987 # issuecomment-139632238 aide avec "l'histoire de liaison maladroite", hein?).

(4) était un peu vague, mais une avenue dédiée à la voie pour les scripts et les one-offs comme celui-ci correspond à ce projet de loi «logique».

Aujourd'hui, je cherchais exactement (2) mais j'ai fini avec ma solution la moins préférée, un deuxième fichier YML. Mon cas d'utilisation:

J'ai quelques conteneurs et tous sont liés au même conteneur mongo . Je voudrais offrir à moi-même et à l'équipe la possibilité de charger des appareils dans la base de données mongo et j'ai pensé que le moyen le plus simple de le faire était de charger le conteneur mongo sous un nom différent fixtures que lui-même se lient à mongo puis exécutez mongorestore --host mongo --port 27017 --drop /dump . Puisque nous ne voulons pas charger les appareils à tout moment, il semblait naturel de l'avoir avec un start: false mais nous avons fini par avoir un fichier YML séparé pour les deux conteneurs fixtures et mongo .

Fonctionne bien mais start: false est beaucoup plus propre IMO. Si j'avais 10 permutations ou plus de ce soi-disant conteneur de luminaires, alors oui start: false serait une mauvaise idée et j'irais avec (1) .

Juste eu à créer un fichier de composition où certains services ne devraient pas être exécutés avec la commande docker-compose up -d . Pour moi, l'option (2) serait la meilleure solution à mon problème.

J'ai aussi rencontré ça. Je ne sais pas quelle est la meilleure solution à mon avis, mais ce que cela signifie pour moi, c'est que j'ai besoin de la capacité de créer des images qui sont utilisées dans le cadre d'une composition. Ils sont destinés aux conteneurs éphémères, mais j'ai besoin que l'image soit prête à l'emploi pour pouvoir exécuter le conteneur à la demande.

Salut! même problème ici, heureux qu'il y ait un joli problème de regroupement, excellent travail!

Dans mon cas, j'ai une pile python fonctionnant avec quelques conteneurs avec des services. Tout fonctionne bien, mais je viens de trouver un cas hors de la pile. Je gère des dépendances statiques avec bower et je veux exécuter la commande bower dans un conteneur, c'est juste un script que nous exécutons de temps en temps.

Ce serait génial d'exécuter ce script dans la structure de composition que nous avons. J'imagine quelque chose comme:
installation de docker-compose run node bower

Donc j'aime la 2ème de la 4ème option. Il suffit que le service ne démarre pas, ce n'est pas nécessaire: P

S'il y a un consensus, je pourrais essayer d'envoyer un pull-req pour quelque chose comme "redémarrer"
début: toujours
peut-être ... je sais pas.

Un autre vote pour l'option 2.

Je préférerais également l'option 2. Les nouveaux conteneurs de données Docker peuvent être spécifiés dans un fichier docker-compose, mais ils n'ont pas besoin d'être en cours d'exécution pour être utilisés.

Option 2 pour moi aussi

L'option 2 serait géniale.

+1 pour l'option 2

+1 pour l'option 2. La gestion de plusieurs fichiers et la saisie de leurs noms est une perte de temps. Un seul drapeau booléen les régirait tous. :bières:

+1 pour l'option 4,
Si je dois choisir un deuxième favori, son option 2.

C'est vrai que la meilleure option est 2,4 si je peux +1 les deux alors c'est ce que je fais sinon je vais avec la majorité et je vote pour 2.

Voter pour 2

2 et 4 sont agréables à avoir.
+1 pour 2

Je ne pense pas qu'il soit nécessaire d'introduire un nouveau concept de tâches. Celles-ci se lisent très bien à mon avis et sont possibles sans beaucoup de modifications:

// 'task' being a service that manages all my tasks, probably with some custom entrypoint script
docker-compose run task tests

// 'tests' being a service specifically for testing with the default command set to run my tests
docker-compose run tests

La "solution" actuelle avec le fichier de composition séparé n'est pas vraiment une solution à mon avis. Comme @xaka l'a dit, personne ne veut taper tout cela:

docker-compose -f default-file.yml -f additional-tasks-file.yml  run task myTask

Vous vous retrouverez avec un script ./run-task qui ajoute tout le passe-partout avant myTask pour vous. Mais maintenant, vous avez ajouté un autre point d'entrée et une autre interface à votre application multi-conteneurs. Les développeurs voient docker-compose.yml et pensent: _ "Oh génial, une application de composition. Je sais comment gérer cette chose!" _ Et maintenant vous devez leur dire: _ "D'accord, vous pouvez le gérer avec docker-compose comme toutes les autres applications de composition ... oh, mais attendez ... il y a aussi ce script supplémentaire que vous devez savoir ... "_

start: false / up: false / some-additional-flag-to-a-service: false est probablement la chose la plus simple à implémenter, mais probablement aussi la plus claire et la plus facile à comprendre. Et cela améliorerait tellement la convivialité.

ce que @sherter a dit. : arrow_up:

: +1: pour ça. un fichier docker séparé est une énorme douleur, surtout lorsque des réseaux sont impliqués

L'approche start: true|false est trop limitée. Que faire si certains services sont utilisés pour les tests, d'autres pour l'administrateur et le reste pour un fonctionnement normal?

Je préférerais ajouter la notion de regroupement aux services.

    myservice:
       group: `admin`

Si l'attribut group n'est pas défini, default est supposé.
De cette façon, nous pourrions démarrer les services par défaut et d'administration en utilisant docker-compose up -g admin -d .

Mieux encore, faites groups un tableau.

Créer des classes de groupe de services semble être une fonctionnalité puissante, mais cela semble également tangentiel à ce problème.

Sur la version 2 de docker-compose, chaque conteneur est déclaré dans l'élément de niveau supérieur services: .
Déclarer un service, avec start: never pour exécuter un script semble incorrect.
Donc, compte tenu du nouveau format, ne devrions-nous pas déclarer un élément supplémentaire de premier niveau en dehors de _services_, _volumes_ et _networks_?

Ma proposition:

• ajoutez un nouvel élément de niveau supérieur scripts: , transients: (ou pensez à un meilleur nom) à la v2.
• à l'intérieur des transitoires, vous pouvez définir un conteneur comme vous le feriez avec n'importe quel service
• la seule différence est qu'ils ne vont pas _démarrer par défaut_, car ils sont destinés à un usage transitoire uniquement.

Exemple:

version: "2"

services:
  web:
    image: myapp
    networks:
      - front
      - back
    volumes:
      - /usr/src/app/
  redis:
    image: redis
    volumes:
      - redis-data:/var/lib/redis
    networks:
      - back

scripts:
  bower:
    image: my_image_with_bower
    volumes_from: web
    working_dir: /usr/src/app/static
    command: "bower"
// maybe would be great to place something like "bower $@"
// to define where you want the cli arguments to be placed, by default at the end.

volumes:
  redis-data:
    driver: flocker

networks:
  front:
    driver: overlay
  back:
    driver: overlay

Et puis vous pouvez exécuter:

docker-compose script bower <EXTRA_CMD_ARGUMENTS |  default nothing>

docker-compose script bower install

Préoccupations:

• Cela semble surpuissant de créer un autre élément de niveau supérieur uniquement dans le but de gérer le démarrage, mais il est dérivé du fait que le nouveau format déclare le comportement au niveau supérieur.
• J'essaie d'imaginer une flexibilité supplémentaire (et des problèmes) que cela peut ajouter.

Enfin, sur la fonctionnalité _groups_, cela semble bien, mais si vous avez autant de regroupements, je ne vois pas le problème de créer des fichiers docker-compose pour chacun d'entre eux. Probablement la fonctionnalité que vous voulez est l' héritage de fichier docker-compose , ce serait génial!

PD: @bfirsh peut-être si vous aimez l'idée, vous pouvez l'ajouter aux "Suggestions possibles"

En deuxième lieu, il s'agit d'une refonte de la 4ème suggestion en raison du nouveau format imminent de déclaration des services.

Voter pour l'option 2: la plus claire, la plus facile à lire et pas besoin d'apprendre de nouveaux concepts
Je veux juste un service qui ne démarre pas par défaut

Et quelque chose comme disabled: true

@ cpuguy83 Cela semblerait impliquer que tout le service est désactivé, même pour run . Je trouverais cela déroutant.

@qcho hmm, maintenant que je me suis familiarisé avec Docker depuis la version 1.6, je peux voir de quoi vous et @gittycat parlez. En ce sens, j'aime vraiment l'approche de @gittycat . J'imagine (ciel bleu) une interface comme:

groups: # if no groups, all services are in the "default" group by…default
    - foo
    - bar
services:
  foo:
    image: imagine
    groups: foo
  bar:
    image: energy
    groups: bar
  baz:
    image: money
    # no groups, so "default"
   quux:
    image: word
    groups:
      - bar
      - default

Pendant ce temps, dans la coquille…

docker-compose up -d # Up all services in default group, so 'baz' and quux
docker-compose up -d --groups foo # Up all services in the foo group
docker-compose up -d --groups foo,default # You get the idea
docker-compose run --rm bar somecommand # We never started 'bar', so it can be a one-off command

Une approche comme celle-ci serait géniale et éviterait le besoin de ce ticket, mais va au-delà de sa portée.

@kojiromike Je ne pense pas. C'est ainsi que les systèmes init font référence à des services qui ne devraient pas démarrer automatiquement.

C'est aussi simple et toute "confusion" peut être résolue avec de la documentation.
Je trouve aussi cela beaucoup moins déroutant que ce regroupement, qui n'a aucun rapport avec le concept de démarrage de service.

@ cpuguy83 Je pense que la sémantique des "services" est exactement ce qui est déroutant en premier lieu. Je suis d'accord que le regroupement est le fluage de la portée. En ce sens, je préfère l'approche de l'option 4 / @qcho , où ils différencient clairement les «services» des «choses qui ne sont pas des services».

C'est le point, pourquoi devrais-je mettre un conteneur qui n'exécutera jamais un service dans une catégorie «service ... désactivé». Cela ressemble à un patch moche que quelqu'un a fait et ce n'est pas intuitif.

Peut-être que la «version 2» du format aurait dû prendre ce problème en compte. Par exemple, une autre spécification pourrait être

version: 3?
containers:
  webserver:
    ...
  database:
    ...
  cache:
    ...
  some_script_container:

services: (they are groups):
  production:
    webserver:
      ...
    database:
      ...
    cache:
      ...
  development:
    webserver:
      ... DEFINE SOME CUSTOM DEV STUFF ABOVE basic container definition
    database:
      ...
    cache:
      ...     

Ok maintenant nous avons des services appropriés, avec la définition des groupes. Je peux démarrer un groupe de services de production ou de développement. Ou exécutez simplement un script dans some_script_container. puisqu'il n'est défini dans aucun service, personne ne sera démarré

@qcho Dépend de la définition d'un service, mais dans tous les cas - je remettrais en question quelque chose qui ne devrait être exécuté qu'occasionnellement, et le seul un humain peut déterminer s'il doit être exécuté ou non.

Disons que compose adopte quelque chose comme un objet job .

1. les tâches ne sont exécutées qu'une seule fois
2. les travaux sont lancés après les services
3. les emplois devraient disparaître
4. ???

Maintenant, compose doit également garder un état local sur le travail, ce qu'il ne fait pas du tout actuellement.

C'est pourquoi l'ajout d'un simple auto-up: false ou autorun: false est le moyen le plus simple et le moins effrayant (de même manière) de gérer cela.

@ cpuguy83 Je pense que vous étendez ce que je dis avec quelque chose de plus complexe. Je n'ai pas l'intention de docker-compose de connaître un travail ou un flux de travail. Des scripts externes peuvent être créés pour cela. Ce que j'ai l'intention est que docker-compose devrait définir la pile entière pour qu'une application s'exécute.

Je peux m'imaginer en train de créer un script et de garder l'état que vous dites. Même appel du script avant le démarrage du service, pas seulement après. Ce que je n'imagine pas, c'est moi-même analyser le fichier du compositeur parce que je dois vérifier quels volumes je dois importer, ou quelle configuration je dois en extraire sur un conteneur inconnu pour exécuter un script qui s'applique à lui. Je pense donc que docker-compose devrait me donner ce conteneur; exécuter le script et garder l'état est mon problème.

Je ne vois pas pourquoi les gens continuent de dire ça

services:
  my-script-container:
    auto-up:false

Est plus simple que:

scripts/containers/transients/you_name_it:
  my-script-container:

C'est le même niveau de complexité. Mais moins hacky sémantiquement.

Pour obtenir les idées sur un fil, référence # 2803

Cas d'utilisation: Vous avez un projet avec de nombreux composants et les utilisateurs que choisir et choisir lequel installer mais il compose le fichier les installe tous.

Proposition: Nous ajoutons une option pour mettre dans le docker-cmpose.overrider.yml pour exclure une image définie dans le docker.compose

c'est à dire

une image:
exclure: oui

Le comportement serait d'ignorer cette entrée dans le fichier docker-compose.yml

Pouvez-vous me dire ce que pense l'équipe, je serais intéressé à faire le changement.

Voter pour le n ° 2 aussi ... vient de rencontrer ce besoin aujourd'hui.

La proposition de @jimzucker fonctionnerait également, bien que j'aime l'idée de voir "start: false" dans le fichier principal .yaml pour vous indiquer immédiatement que ce "service" ne fonctionnera que si vous l'appelez explicitement. Sinon, vous (ou dans mon cas l'utilisateur final / développeur à qui vous avez remis les fichiers docker-compose) devez vous rappeler de rechercher un fichier de remplacement.

+1 pour 2. J'ai une situation où j'ai besoin de créer une image de docker dans le cadre de la composition mais elle ne fonctionne pas en tant que service. Les autres services (qui ont un docker sock monté à l'intérieur) exécutent des conteneurs à partir de l'image de temps en temps.

+1 pour 2. Et +1 pour "auto-up" ou "auto-run" comme libellé.

Et les cas pour les groupes de services (comme expliqué par @gittycat) ne peuvent-ils pas être traités via des variables d'environnement ala "auto-up: $ {ADMIN}"?

Je vois aussi de vrais cas d'utilisation pour marquer les services dans le docker-compose.yml pour ne pas être démarrés automatiquement avec un simple docker-compose up mais au lieu de cela être démarré uniquement explicitement.

La solution 1) est une solution possible maintenant mais à mon avis trop lourde car il faut spécifier un ou plusieurs fichiers yml au lieu de simplement appeler docker-compose up et de devoir diviser ou même dupliquer les fichiers.

Puisque j'aimerais vraiment voir quelque chose comme la solution 2) (comme beaucoup d'autres le font aussi), j'ai implémenté une preuve de concept de ceci dans # 3047 afin que vous puissiez jouer un peu avec pour voir si cela pourrait être viable Solution.

+1 pour l'option 2

+1 pour l'option 2

+1 pour l'option 2

+1 pour les deux options 2 et 4

+1 pour les options 2 et 4

+1 pour l'option 4. certaines configurations ne devraient pas être autorisées pour les scripts (par exemple: redémarrer: toujours)

avec l'option 2, cela pourrait avoir ce cas étrange:

service:
  run_tests:
    build: ./tests/
    restart: always
    auto-start: "false"

qu'est-ce que cela signifierait?

@mathroc : Cela signifie: "Ne pas démarrer automatiquement ce conteneur lorsque la composition est exécutée. Lorsque ce conteneur s'arrête (après avoir été démarré explicitement), redémarrez quel que soit le code de sortie." Qu'est-ce qui est bizarre à ce sujet?

@niko oh

changer mon "vote" en +1 pour l'option 2

+1 pour l'option 2, j'en ai eu besoin dans plusieurs projets.

ping à @bfirsh @dnephin :
Pourriez-vous donner une mise à jour concernant ce problème? Puisque la plupart des commentaires ici sont en faveur de l'option 2, existe-t-il actuellement des plans pour mettre en œuvre quelque chose comme ça (ou l'option 3/4)?
Je pourrais peaufiner ma pull request (# 3047) et la compléter avec des tests et de la documentation si vous envisagiez de la fusionner ensuite.

Je vous remercie.

+1 pour l'option 2

+1 pour l'option 2

+1 pour l'option 2

Je pense que l'option 1 pourrait fonctionner, mais nous avons besoin d'un meilleur moyen de réduire la verbosité de:

docker-compose -f docker-compose.yml -f docker-compose.tests.yml up

Peut-être pourrait-on ajouter un drapeau simplifié / augmenté? docker-compose --augment tests up et se résout automatiquement s'il s'agit d'une variation de docker-compose.yml - sinon l'utilisateur devra être explicite.

J'aime beaucoup l'idée d'un nouveau mot-clé de premier niveau, peut-être suites et commands ?

La configuration suivante permettrait:

docker-compose run -s application
docker-compose run -c cache-clear

suites:
    application:
        services:
            - database
            - memcached
            - application
    tests:
        extends: application
        services:
            - application

commands:
    cache-clear:
        service: application
        workdir: /var/www
        command/entrypoint: php app/console ca:cl

Je peux voir dans le code qu'il existe déjà la notion de services "oneoff" (IMHO utilisé uniquement lorsque docker-compose run est appelé.
Pourrait-il être réutilisé?
Si j'étiquette un conteneur avec com.docker.compose.oneoff=True , essaiera-t-il de le démarrer?

Sinon, je vote pour l'option 2.

Je viens de trébucher dessus, alors voici mes deux cas d'utilisation:

1. Variables d'environnement "globales": L'approche suggérée ici est d'utiliser extends , ce qui me convient ... mais maintenant j'ai besoin de définir un image pour ce que j'étends , et ne peut même pas utiliser scratch (donc fini avec https://hub.docker.com/r/tianon/true/).
2. services de "mise à l'échelle": par défaut, j'ai une instance MongoDB, mais pour certains tests, j'aimerais en définir une seconde inactive, que je peux faire apparaître pour ces tests. Ici, l'utilisation de extends dans un fichier différent ressemble à une idée viable (toujours en train d'apprendre sur docker / docker-compose et les meilleures pratiques impliquées).

+1 pour l'option 2

+1 pour l'option 2

+1 pour l'option 2
Cela ressemble à un simple changement ...

+1 option 2,

dans le cas d'utilisation de plusieurs conteneurs partageant un ensemble d'environnements et de configurations communs, il est logique de créer un conteneur de base à partir duquel s'étendre, mais de ne jamais démarrer le conteneur

auto-start:true|false

Ayant une bonne solution depuis septembre dernier appelée rocker-compose , je recommanderais de courir: _always_ | _once_ | _jamais_. J'aime aussi l'état: _running_ | _ran_ | _created_ aussi.

Je ne suis pas fan de l'utilisation d'un projet séparé uniquement pour cette fonctionnalité, j'ai fini par voler la commande True asm code hors du projet tianon / true jusqu'à ce que cela soit implémenté

Au départ, j'ai également pensé que l'option 2 serait la meilleure, mais maintenant je commence à penser qu'elle serait trop restrictive et assez tôt après l'avoir ajoutée, un besoin de tâches à exécution unique apparaîtrait. En fait, je travaille actuellement sur un projet où j'ai besoin des cas d'utilisation suivants:

• dans la pile, je veux pouvoir définir des conteneurs qui s'exécutent une fois lors du déploiement initial et toutes les futures exécutions ne sont déclenchées qu'en externe (par exemple, planification / événement, via un appel API, etc.) afin qu'ils puissent initialiser / mettre à jour l'état du conteneur de service principal dans la même pile (par exemple, données / schéma de base de données, remplissage de volumes de données, etc.)
• au sein de la pile, je veux pouvoir définir des conteneurs qui ne sont déclenchés qu'en externe afin qu'ils puissent être utilisés pour encapsuler des tâches utilitaires / d'administration (par exemple, inspection d'état / de données, etc.) et des processus qui sont déclenchés dans les délais (par exemple, sauvegarde) ou par des événements externes (par exemple, déclencher un processus sur les modifications d'un compartiment S3)

Dans mon cas, la distinction entre state: created (exécuté 0 fois) et state: ran (exécuté> = 1 fois) est importante car certaines des tâches utilitaires / d'administration peuvent être destructives et ne doivent être utilisées dans certaines circonstances comme la migration des services.

Étant donné que je me penche maintenant davantage vers state: running | ran | created comme dans le rocker-compose ou l'option 4 avec objet _task_ ou _job_ de niveau supérieur + capacité à exprimer une dépendance afin qu'un service puisse déclencher une tâche à exécuter avant / après lui-même .

Je voudrais mentionner que cela est important pour mon cas d'utilisation. J'utilise docker-compose pour créer un environnement de test et exécuter une suite de tests. Le problème avec le démarrage de tous les conteneurs à la fois est que je ne peux pas facilement permettre aux conteneurs de service (comme les bases de données ou les céleri travailleurs) de s'initialiser avant d'exécuter la suite de tests.

Il serait préférable de pouvoir accomplir quelque chose comme:

$ docker-compose --file="docker-compose-testing.yml" up -d --exclude=tests
$ sleep 5
$ docker-compose --file="docker-compose-testing.yml" run --rm tests

Vous pouvez imaginer que quelque chose de plus élaboré que sleep 5 pourrait être écrit pour vérifier que l'initialisation a eu lieu, mais ce n'est pas nécessaire pour l'exemple d'extrait.

Je n'ai pas lu une option sur un drapeau cli. Je proposerais donc qu'un drapeau --exclude soit ajouté à la liste des options. L'indicateur --exclude indiquerait à la commande up ne pas démarrer le conteneur spécifié. L'indicateur --exclude serait analysé de telle sorte que plusieurs conteneurs puissent être exclus du démarrage si nécessaire.

: +1:

Pesée avec un autre cas d'utilisation où l'option 2 serait une solution appropriée: itérer sur un nouveau sous-service au sein d'une application existante. La plupart des développeurs du projet n'auront pas encore besoin du nouveau service, et vous ne voulez certainement pas que cela gêne leur travail, mais vous pouvez également éviter de maintenir une branche hors de l'arborescence pendant une période prolongée de temps.

Un fichier distinct "docker-compose-experimental.yml" _pourrait_ fonctionner, mais cela signifie que toute la documentation pour travailler sur ce composant doit être écrite dans un sens pendant que le composant est encore expérimental, puis révisée une fois qu'il fait partie de l'ensemble standard des services.

+1 à l'option 2

+1 pour l'option 2

+1 pour l'option 2

+1 pour l'option 2

+1 pour l'option 2

@acran J'aimerais vous voir soumettre votre pull request pour voir si nous pouvons obtenir un peu de traction pour faire avancer les choses, peut-être que si vous rebasez pour éliminer le conflit sur # 3047, il sera repris, je ne sais pas comment attirer l'attention sur cela.

@jimzucker well # 3047 est déjà une pull request et j'attends toujours quelques commentaires à ce sujet de la part des développeurs: déçu:

Voir mon commentaire ci -

+1 option 2

@acran , j'aimerais vous aider à mettre à jour les documents et les cas de test associés. Est-ce que c'est bon ?

+1 option 2

ou peut-être définir une sorte de Job, comme dans Kubernetes?

+1 pour l'option 2

Nous avons un docker-compose avec plusieurs services et l'un d'eux (la base de données) doit être lancé sur l'environnement de développement mais pas sur l'environnement de production. Par conséquent, nous devons conserver deux fichiers docker-compose. L'option 2 est exactement ce que nous recherchons!

: +1: pour l'option 2

+1 option 2

@acran Je suis en train de contacter des connexions ici à SF pour trouver le bon processus / canal pour obtenir des commentaires afin que cela puisse avancer, restez à l'écoute;)

👍 pour l'option 2

+1 pour l'option 2

+1 option 2

+1 option 2

Je vote aussi pour l'option 2

Une autre idée: maintenant nous avons networks et volumes , nous pourrions également ajouter une option images . Ce serait un indice pour Compose que ces images doivent être extraites ou construites pour que l'application fonctionne, mais elles ne seront pas exécutées lorsque vous faites docker-compose up .

Cela fonctionnerait pour deux cas d'utilisation, du haut de ma tête:

1) Le problème commun ici, où vous voulez qu'une sorte de commande de gestion s'exécute. docker-compose run pourrait revenir à l'exécution d'images si le service n'existe pas.
2) Des applications comme celle-ci qui exécutent des images Docker mais qui ne fonctionnent pas tout le temps.

/ cc @dnephin @aanand @

Sauf que ce serait bien de pouvoir configurer toutes les options dont un conteneur à court terme aurait besoin (c'est-à-dire les volumes / points de montage, réseaux, liens, nom, etc.) dans le fichier docker-compose pour ne pas devez continuer à les ajouter à chaque fois que vous devez exécuter ce conteneur ...

Le 13 septembre 2016 03:58:41 AM CDT, Ben Firshman [email protected] a écrit:

Autre idée: maintenant nous avons networks et volumes , nous pourrions
ajoutez également une option images . Ce serait un indice pour comprendre que ces
les images doivent être extraites ou créées pour que l'application fonctionne, mais elles
ne serait pas exécuté lorsque vous faites docker-compose up .

Cela fonctionnerait pour deux cas d'utilisation, du haut de ma tête:

1) Le problème commun ici, où vous voulez une sorte de gestion
commande à exécuter. docker-compose run pourrait revenir aux images en cours d'exécution
si le service n'existe pas.
2) Applications commece qui court
Images Docker mais elles ne fonctionnent pas tout le temps.

/ cc @dnephin @aanand @

Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou affichez-le sur GitHub:
https://github.com/docker/compose/issues/1896#issuecomment -246618909

Envoyé depuis mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Je suis d'accord avec @mgriego à ce sujet. Pensez à un conteneur de génération de build - il serait préférable que la commande et les options soient toutes configurées et juste docker-compose up foo et qu'il fasse la construction et la sortie.

Essayer d'obtenir plus de compréhension ici: L'option 2) est-elle juste un cas spécialisé du plus général "nous voulons une initial_scale en docker-compose.yml "? (voir # 1661, # 2496 et. al.)

@ankon pas du tout.

ajouter une [section] images

@bfirsh cela commence à bouger dans la direction que j'ai prise avec https://github.com/dnephin/dobi. J'ai abandonné les «sections» (et utilisé à la place des éléments de premier niveau pour chaque ressource). Je pense qu'il serait difficile de faire fonctionner cela avec le modèle Compose.

1. networks et volumes ne sont jamais vraiment exploités directement, ils sont juste créés selon les besoins par un conteneur. Diviser les images dans leur propre section ne changera pas le comportement que nous avons maintenant, cela compliquerait simplement la configuration de Compose. Si vous vouliez simplement créer une image, exécutez docker-compose build .
2. Je ne pense pas que cela résout réellement les problèmes identifiés dans ce problème. Les gens veulent des conteneurs, pas seulement l'image

En relisant le fil de discussion et la discussion dans # 2496 sur la déclaration des contraintes de mise à l'échelle dans le fichier de composition, j'arrive à préférer l'option 4 (c'est-à-dire une nouvelle section de niveau supérieur) à l'option 2.

Plus précisément, un nom de section comme utilities serait un bon choix: des composants qui ne sont normalement pas nécessaires, mais lorsque vous en avez besoin, vous voulez avoir préconfiguré les autres composants auxquels ils sont liés plutôt que d'avoir à le faire. amener les gens à construire eux-mêmes une incantation docker run appropriée.

Cette approche couvrirait alors non seulement les commandes d'administration ponctuelles, mais également les services auxiliaires de débogage et d'introspection comme pgweb et Celery Flower (qui sont très pratiques pour être exécutés en développement, mais vous ne voudriez généralement pas en production en raison de la sécurité supplémentaire. surface de menace qu'ils créent).

La définition de la sémantique de ces nouveaux "pas de services" devient également beaucoup plus facile: ils sont _exactement_ identiques à services (y compris toutes les modifications futures de ce format), à la seule exception que les commandes non qualifiées comme docker-compose build , docker-compose pull et docker-compose up ignorent entièrement - si vous voulez qu'un composant répertorié dans "utilitaires" plutôt que "services" soit traité, vous devez le nommer spécifiquement (bien qu'il pourrait peut-être être une option --all , similaire à celle actuelle pour docker-compose rm ). Cependant, la CLI pour interagir avec ces utilitaires par nom serait identique à celle pour interagir avec les services normaux (contrairement au statu quo, où vous devez spécifier le fichier de configuration de l'utilitaire supplémentaire), et docker-compose prendrait soin d'éviter les conflits de nom entre les définitions de service et d'utilité.

Alors que la proposition de mise à l'échelle dans # 2496 pourrait potentiellement être (ab) utilisée pour obtenir ce comportement, cela ressemble toujours à une solution de contournement plutôt qu'à une fonctionnalité correctement conçue.

J'aime ce design, @ncoghlan.

Au lieu de utilities qu'en est-il simplement de le nommer .services ? Cela signifie naturellement que services et .services utilisent exactement la même sémantique, la seule différence est que .services ne sont pas exécutés par défaut. C'est un analogue assez proche des noms de fichiers qui ne sont pas affichés par défaut. Je suppose que l'inconvénient est que la distinction entre les deux est un peu subtile.

J'aime l'idée de base dont @ncoghlan en parle, mais…

1. N'acceptez pas que toutes les commandes non qualifiées doivent ignorer ces utilitaires par défaut. À mon avis, toutes les commandes devraient s'exécuter normalement sauf celles qui entraîneraient un conteneur en cours d'exécution. (Donc en gros, up et start .)
2. En ce qui @dsem , j'aime mieux la sémantique de «utilitaire» que de «.services». Je comprends le raisonnement des fichiers cachés Unixy, mais ces choses ne sont pas simplement des services cachés, ce sont des assistants de service.

@bfirsh @ncoghlan Je suis entièrement d'accord avec @dnephin :

Je ne pense pas que cela résout réellement les problèmes identifiés dans ce problème. Les gens veulent des conteneurs, pas seulement l'image

Ce dont j'ai - et je pense que la plupart des gens ici - ont besoin pour mon flux de travail souhaité, ce sont des services simples; ils sont définis comme n'importe quel service normal, ils sont démarrés / arrêtés comme des services normaux, etc.
La seule différence est qu'ils ne sont pas automatiquement démarrés par un simple docker-compose up par défaut, mais uniquement lorsqu'ils sont spécifiés explicitement (ou extraits en tant que dépendance).

Par conséquent, je ne vois aucune nécessité pour une nouvelle section de niveau supérieur ou un concept complètement nouveau pour ces conteneurs uniques, mais seulement un paramètre de configuration de service facultatif.
J'ai implémenté cela dans ma pull request # 3047 comme preuve de concept. C'est un tout petit changement mais qui satisferait pleinement mes cas d'utilisation. Donc, s'il y a quelque chose de plus que je peux faire, pour obtenir cette fusion, veuillez me le faire savoir (=

Pour tous ceux qui souhaitent tester cela, voici les commandes pour construire et exécuter docker-compose dans un conteneur:

# download and build
git clone [email protected]:acran/compose.git -b auto_up
cd compose
docker build -t docker-compose .

# create an example docker-compose.yml
cat > docker-compose.yml <<EOF
version: "2"
services:
  foo:
    image: busybox
    auto_up: false
    command: echo foo
  bar:
    image: busybox
    auto_up: false
    command: echo bar
    depends_on:
      - foo
  baz:
    image: busybox
    command: echo baz
EOF

# start all default services only, i.e. baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up

# start service foo only
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up foo

# start service bar, foo is pulled in as a dependeny
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up bar

# clean up all services, i.e. foo, bar and baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose down

@acran , j'aimerais vous aider à mettre à jour les documents et les cas de test associés. Est-ce que c'est bon ?

@ dattran-vn01 bien sûr, je serais heureux: smiley:

@acran dans votre exemple, la seule commande qui a un comportement différent de celui de Compose actuel est la première, et ce comportement peut être accompli en utilisant up baz .
Vous pouvez également accomplir la même chose en utilisant plusieurs fichiers de composition.

Faire fonctionner certaines commandes sur une liste différente de services par défaut semble très déroutant, et c'est l'une des raisons pour lesquelles je n'aime pas cette fonctionnalité.

@acran dans votre exemple, la seule commande qui a un comportement différent de Compose actuel est la première, et ce comportement peut être accompli en utilisant up baz.
Vous pouvez également accomplir la même chose en utilisant plusieurs fichiers de composition.

@dnephin oui, exactement, je sais, et dans cet exemple, ce serait le moyen le plus simple.
Mais imaginez cela avec 10 services et un seul service unique (comme "init" ou "backup" / "dump"): dans ce cas, vous devrez lister tous les services sur la ligne de commande sauf celui-là. hors service comme docker-compose up service1 service2 ... service10 (voir ci-dessous). Surtout, vous devez vous souvenir de tous les services et suivre manuellement tout changement dans le docker-compose.yml .

Je connais également la possibilité d'utiliser plusieurs fichiers YAML, voir mon premier commentaire ci -

Voici un autre exemple docker-compose.yml pour visualiser le problème:

version: "2"
services:
  init:
    image: busybox
    auto_up: false
    command: echo "I do one-time initializing"
  service1:
    image: busybox
    command: echo "I'm service #1"
  service2:
    image: busybox
    command: echo "I'm service #2"
  service3:
    image: busybox
    command: echo "I'm service #3"
  service4:
    image: busybox
    command: echo "I'm service #4"
  service5:
    image: busybox
    command: echo "I'm service #5"
  service6:
    image: busybox
    command: echo "I'm service #6"
  service7:
    image: busybox
    command: echo "I'm service #7"
  service8:
    image: busybox
    command: echo "I'm service #8"
  service9:
    image: busybox
    command: echo "I'm service #9"
  service10:
    image: busybox
    command: echo "I'm service #10"

Un simple docker-compose up _avec_ l'attribut auto_up commence ici tous les services sauf le service init . Pour obtenir la même chose sans cela, il faudrait taper une commande beaucoup plus longue avec 10 services ou diviser le fichier YAML et spécifier plusieurs fichiers.

Donc, la fonctionnalité demandée ici est plus une question de commodité et moins de frappe sur le cli et non une fonctionnalité complètement nouvelle.

En ce qui concerne l'option "utiliser plusieurs fichiers de configuration" (qui est en effet la meilleure option actuellement disponible), le problème d'utilisation avec cela est qu'elle ressemble à ceci en pratique:

$ docker-compose up one-shot-command
ERROR: No such service: one-shot-command
$ docker-compose up -f docker-compose.yml -f docker-compose-utils.yml one-shot-command
# Actually goes & does the requested thing

L'écart infecte alors _tout_ la documentation et l'automatisation de votre projet: vous devez vous assurer que _deux_ fichiers de composition sont disponibles pour quiconque souhaite exécuter des commandes utilitaires, vous devez vous assurer que l'appel complet est donné pour les commandes dans le fichier utilitaire, et si une commande ou si le service est rétrogradé de "toujours en cours d'exécution" à "uniquement exécuté sur demande explicite", vous devez rechercher toute invocation qui ne fournit pas les noms de fichier de configuration et les ajouter.

C'est tout _doable_, c'est juste ennuyeux par rapport au fait de pouvoir dire dans le fichier de composition "Ne lancez ceci que lorsque je vous le demande explicitement, ne l'exécutez jamais par défaut".

Quelqu'un m'a dit un jour: _ "Si plusieurs personnes intelligentes ne peuvent pas décider quelle approche est la meilleure, en général, ni l'une ni l'autre n'est assez mauvaise. Le pire est de ne rien faire." _

Cette carte semble être un excellent exemple de ceci :)

Étant donné que docker prend désormais en charge le concept de service de manière native pour les commandes de longue durée, je pense que la meilleure approche serait d'ajouter une nouvelle section appelée commandes qui permet les mêmes fonctionnalités que les services, à l'exception des politiques de redémarrage, qui devraient être interdites.

Dans ma configuration, j'ai des services dans le docker-compose qui sont nécessaires pour faire fonctionner mon infrastructure (nginx, base de données, serveur Web, files d'attente de messages ...). J'ai également défini des services supplémentaires dont je n'ai besoin que pour des raisons de débogage (par exemple une interface graphique de base de données).

Je voudrais que les services de "débogage" ne démarrent PAS automatiquement, mais si je veux les ajouter, je peux le faire avec un simple docker-compose up -d database-gui et il vient d'être ajouté.

Aussi: Parfois, je change d'avis et je veux qu'un de ces services démarre toujours ... => Avec l'option 2) je peux simplement changer cet indicateur

=> Votez pour la deuxième option, car elle est simple et semble répondre aux exigences de tout le monde ici. Toute autre solution me semble une sur-ingénierie ... Ajouter de la complexité à la configuration basée sur des cas d'utilisation rares ou imaginaires, et non sur des besoins pratiques.

Juste ici pour ajouter mon +1. J'exécute sur des applications Django et lors de leur exécution dans docker, ce serait bien d'avoir un conteneur qui exécuterait le shell ou des tests ou d'ailleurs migrerait des commandes. Mais je ne souhaite en exécuter aucun à chaque fois que je lance l'application. Bien que l'utilisation de plusieurs fichiers de configuration fonctionnerait, cela nécessiterait de taper, d'écrire des scripts ou d'aliaser des lignes de commande de plusieurs kilomètres. Si je voulais faire cela, je n'utiliserais pas du tout compose, je ferais juste un script shell mes conteneurs (ou python les script ... peut-être ajouter un fichier YAML unificateur pour stocker les configurations de conteneurs ... attendez ...) Je ne veux rien faire comme docker-compose -f common.yml -f dev.yml -f local.yml -f commands.yml up migrate juste pour exécuter des migrations de bases de données sur mon conteneur. L'alternative est d'utiliser /bin/true comme commande et de faire quelque chose comme docker-compose -f common.yml -f dev.yml -f local.yml up commands 'python3 manage.py migrate' qui n'est pas non plus très élégant. Donc, avoir des commandes uniques stockées quelque part dans la configuration me serait très utile. Toutes les options 2, 3 et 4 fonctionneraient pour moi.

Je voudrais vous suggérer de jeter un coup d'œil à dobi , un outil sur lequel j'ai travaillé en partie sur la base des commentaires de ce fil.

compose est conçu pour démarrer des services de longue durée qui forment un «environnement».
dobi se concentre sur les taks de construction de projets séquentiels.

Les choses que vous recherchez (exécuter un shell, exécuter des tests unitaires, exécuter une migration) sont toutes des tâches de projet, elles s'intègrent donc beaucoup mieux dans le modèle dobi.

dobi et compose fonctionnent assez bien ensemble, vous pouvez lancer compose depuis dobi en utilisant une ressource de composition .

compose=dev-environment:
  files: [docker-compose.yml, local.yml]
  project: 'theprojectname'

que vous pouvez exécuter en utilisant:

dobi dev-environment

Il y a un exemple de l'intégration de compose et des migrations de db en cours d'exécution ici: https://github.com/dnephin/dobi/tree/master/examples/init-db-with-rails

Il existe des exemples de nombreux flux de travail (y compris l'exécution de tests, le démarrage d'un shell interactif, la publication et la création d'images minimales) ici: http://dnephin.github.io/dobi/examples.html

+1 pour 2). De notre point de vue, il est inutile de réfléchir et de discuter de cas d'utilisation inhabituels comme des commandes ponctuelles, mais nous voulons juste avoir de vrais services qui sont créés et prêts à être utilisés, mais peuvent être démarrés à la demande en cas de besoin (et par défaut, ne consommez pas Ressources).

"cas d'utilisation rares"? exécutez-vous des migrations de bases de données? exécutez-vous des tests unitaires? exécutez-vous des peluches? webpack?

Oui, je cours mais cela peut être obtenu et contrôlé à l'intérieur de conteneurs, à mon avis. Mais je ne veux pas nuire à votre point de vue ou à vos demandes, n'allumons pas cette discussion. Nos exigences en matière de composition de docker ne sont pas nécessairement en conflit.

Je viens de tomber sur ce fil en essayant de trouver un moyen de créer un conteneur docker-compose pour un script qui efface la base de données de mon conteneur mysql et recharge le schéma à partir d'un vidage téléchargé. C'est un processus très long et destructeur, donc je ne veux pas qu'il s'exécute à chaque fois que je lance les services, mais il doit également s'exécuter dans l'ensemble composé de conteneurs en utilisant son propre fichier docker.

Appelez-les tâches, commandes, peu importe, mais je suis un peu SOL sans cela.

Je suis tombé sur cela à la recherche d'autre chose, je voulais juste faire une puce dans un cas d'utilisation ... Nous avons constaté que nos développeurs étaient les plus capables de définir les données à sauvegarder à partir de leurs services. Comme le fichier docker-compose.yml est entre leurs mains et que des volumes nommés sont utilisés, nous avons décidé de l'utiliser pour définir les stratégies de sauvegarde ... Voici un exemple résumé de notre ancien docker-compose.yml que nous utilisions.

version: '2'
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    restart: always
    ports:
      - "5555:5555"
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
      - certificates:/etc/gitlab/ssl
      - registry_data:/var/opt/gitlab/gitlab-rails/shared/registry
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    restart: always
    volumes:
      - certificates:/etc/gitlab-runner/certs
      - /var/run/docker.sock:/var/run/docker.sock
volumes:
    gitlab_config:
      driver: local
    gitlab_logs:
      driver: local
    gitlab_data:
      driver: local
    certificates:
      driver: local
    registry_data:
      driver: local

Pour pouvoir sauvegarder les données des volumes, nous avons décidé d'utiliser un conteneur busybox pour tarer les données nécessaires, mais il doit être flexible et ne faire que les volumes que les développeurs souhaitent sauvegarder. Enfin, nous devrions pouvoir sauvegarder chaque volume séparément. Pour ce faire, nous avons ajouté 3 services à tous nos docker-compose.yml

  boot:
    image: busybox
    depends_on:
      - gitlab
      - gitlab-runner

  backup:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type d -maxdepth 1 -mindepth 1 -exec tar cvf /backup/{}.tar {}  \;
    working_dir: /backup

  restore:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type f -iname "*.tar" -maxdepth 1 -mindepth 1 -exec tar xvf {} \;
    working_dir: /backup

Les services de sauvegarde et de restauration doivent simplement être configurés à l'aide des volumes, les commandes feront le reste. Nous prévoyons d'ajouter un peu de configuration pour pouvoir choisir les volumes à sauvegarder ou à restaurer mais pour l'instant, nous les faisons tous ... Puisque nous ne voulons pas que ces 2 services démarrent à chaque docker-compose up, nous devions spécifier tous les services que nous voulions, ce qui peut être fastidieux ... Nous avons donc ajouté un service factice appelé boot, tout ce qu'il fait est de dépendre de tous les services à exécuter et nous appelons simplement celui-ci lorsque nous docker-composer.

Ceci est plein de petits hacks, mais nous permet d'exécuter facilement docker-compose up backup pour avoir notre sauvegarde stockée sur l'hôte / backups / latest et à partir de là, nous exécutons notre logique de versionnage / élagage.

J'espère que cela aide quelqu'un qui essaie de réaliser quelque chose de similaire ... Mais à la fin, étant capable de dire simplement à docker-compose de ne pas démarrer ces 2 services, nous n'aurions pas besoin d'un troisième et compliquerons notre docker-compose up commandes.

En développement, nous avons actuellement 4 fichiers docker-compose:

• docker-compose.yml : définit les services de base nécessaires pour faire fonctionner pleinement notre application, par exemple redis, MySQL, php-fpm, processeur de file d'attente Laravel, nginx, Solr
• docker-compose-utils.yml : définit les services utilitaires nécessaires pour exécuter les tâches de développement, par exemple gulp, npm, artisan (Laravel), composer, redis-cli, généralement exécutés avec les services ci-dessus
• 2 autres fichiers docker-compose pour définir l'environnement et les volumes des services ci-dessus

Cette configuration fonctionne bien car, en dehors de Docker, nous avons des dépendances minimales pour notre environnement de développement. L'inconvénient est la lourdeur des lignes de commande nécessaires pour spécifier tous les fichiers .yml nécessaires pour exécuter des utilitaires simples.

Nous développons sur macOS, Windows et Linux. De plus, beaucoup de nos tâches de développement nécessitent une sorte de paramétrage (par exemple, créer une migration de base de données, exécuter une commande composer / artisan / npm avec ses propres arguments), j'ai donc créé schmich/runx comme une croix d'installation zéro Platform Task Runner pour regrouper nos tâches de développement communes.

Par exemple, cela nous permet de dire runx migrate: make create_some_table pour exécuter efficacement docker-compose -f docker-compose.yml -f docker-compose-utils.yml -f docker-compose-dev.yml -f docker-compose-utils-dev.yml run --rm artisan migrate:make create_some_table , ou runx npm obsolète pour afficher nos dépendances JS obsolètes.

Je n'ai pas utilisé dobi mentionné ci-dessus, mais runx semble similaire dans l'esprit, bien que moins adapté à un environnement Docker. En fin de compte, je veux éviter les dépendances partout sauf là où c'est absolument nécessaire: pour les services eux-mêmes et pour les scripts utilitaires nécessaires au développement.

Des nouvelles? Je pense que cette fonctionnalité serait vraiment agréable à avoir! Je vote pour la solution d'une configuration de niveau supérieur comme default où nous pouvons spécifier quel service doit être exécuté.
Le service factice boot est sympa, mais je préfère laisser le processus au premier plan, donc lorsque j'ai terminé ce travail, je peux simplement fermer le terminal pour tout arrêter. C'est aussi bien d'avoir la sortie jointe par défaut et cela ne se produit pas avec le service factice.

Depuis que noboby a commenté des cas d'utilisation utilisant des fichiers .env, voici le mien:

J'ai 4 fichiers de composition: docker-compose.yml, docker-compose.local.yml, docker-compose.prod.yml et docker-compose.ci.yml. Pour chaque environnement, j'ai un .env différent:

CI .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.ci.yml
WEB_PORT=8081
...

Test/dev/etc .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.local.yml
WEB_PORT=80
...

Etc...

Les utilisateurs et / ou les scripts n'ont pas à se soucier des fichiers de composition à utiliser car les environnements sont déjà configurés individuellement.

Mais j'ai une instance de maintenance à exécuter éventuellement, elle ne peut pas être configurée à l'intérieur du docker-compose.yml principal et une solution serait de créer un docker-compose.worker.yml et d'exécuter une ligne de commande avec 3 options "-f" qui changent avec chaque environnement. C'est trop sujet aux erreurs pour être une option utilisable.

La solution que j'ai trouvée était de créer un répertoire "worker", d'y placer le fichier yml, de lier le fichier .env supérieur à ce répertoire et de créer des fichiers docker-compose vides. [Ci | local | prod] .yml (sinon j'aurais pour changer la valeur de la variable COMPOSE_FILE).

Cela fonctionne bien, mais c'est loin d'être optimal. Toute autre solution de l'OP résoudrait cela sans aucun gâchis.

Je pense que la discussion ici, les nombreux exemples de cas d'utilisation ainsi que le fait qu'il y a fréquemment des problèmes en double dans cette ouverture montrent clairement qu'il y a une réelle demande de la part de nombreux utilisateurs pour une possibilité de "Définir des services qui ne sont pas démarrés par défaut ".

Par conséquent, j'aimerais vraiment déplacer la discussion ici de _si_ cela devrait être implémenté davantage à _comment_ cela devrait être implémenté. Pouvons-nous tous être d'accord là-dessus ?

En ce qui concerne _comment_ cela pourrait être réalisé, @bfirsh a énuméré certaines options dans le commentaire d'ouverture:

1) Recommander aux utilisateurs d'utiliser un fichier Compose distinct

Il s'agit de la seule solution actuellement disponible pour ce cas d'utilisation. Mais comme indiqué ci-dessus, il s'agit dans ce cas plus d'une solution de contournement car il nécessite de taper manuellement de longues lignes de commande et de se rappeler quels fichiers Compose inclure pour quelle commande exécuter.
Bien sûr, dans une configuration CI ou un déploiement automatisé en production, ce n'est pas un problème, car la ligne de commande ne doit être définie qu'une seule fois et ne doit jamais être saisie manuellement. Il s'agit donc uniquement de commodité dans des environnements non automatisés, c'est-à-dire de développement, qui est selon le manuel de docker-compose l' un des principaux cas d'utilisation de Compose lui-même:

Ensemble, ces fonctionnalités offrent aux développeurs un moyen pratique de se lancer dans un projet. Compose peut réduire un «guide de démarrage du développeur» de plusieurs pages à un seul fichier Compose lisible par machine et à quelques commandes.

Devoir taper quelque chose comme docker-compose -f docker-compose.yml -f docker-compose-utils.yml run init juste pour initialiser une configuration locale ne me semble pas _convenient_ mais plutôt quelque chose qui se trouve dans _un guide de démarrage du développeur sur plusieurs pages _.

Et pour considérer l'option 1b) ici:

Recommander aux utilisateurs d'utiliser un script / outil wrapper pour utiliser des fichiers de composition séparés

Si je dois intégrer des outils et des dépendances supplémentaires juste pour cela, pourquoi utiliser docker-compose en premier lieu? Puisque tout ce que docker-compose fait pourrait - en théorie - aussi être fait avec juste un script shell personnalisé et le client natif docker directement.
Je vois le principal avantage de docker-compose dans son interface utilisateur standardisée (je clone un projet, je vois un docker-compose.yml là-dedans et je sais que je dois juste exécuter docker-compose up pour commencer) . Il faut toujours savoir quel fichier de composition utiliser pour ce qui affaiblit considérablement cet avantage.

2) Ajouter une option aux services pour les empêcher de démarrer par défaut
3) Ajouter une option de configuration de niveau supérieur pour définir les services par défaut

Ces deux options font fondamentalement la même chose: définir quels services doivent (ne pas) être démarrés par défaut dans un fichier de composition , option 2) en mettant sur une liste noire des services individuels, option 3) en mettant globalement sur liste blanche un ensemble de services.
Étant donné que la plupart du temps, il y a plus de services par défaut que de "services ponctuels" dans un seul fichier de composition, il est probablement plus facile de mettre un service sur liste noire que de devoir mettre tous les autres sur liste blanche et de mettre à jour la liste blanche chaque fois qu'un service par défaut est ajouté ou supprimé. Également avec l'option 2), la fusion de plusieurs fichiers de composition est probablement plus facile.

4) Ajouter un concept de chose comme un service, mais c'est juste pour les commandes ponctuelles ("scripts", "tâches", etc ...)

Je pense que l'option 4) est juste une spécialisation de l'option 2) ou 3) car dans la plupart des exemples ci-dessus, les conteneurs uniques souhaités sont fondamentalement définis comme n'importe quel autre service et ne font rien de plus ou moins comme des services normaux - sauf qu'ils ne sont pas démarrés par défaut. (Ou ai-je manqué une différence significative à un "service").

Donc, à mon avis, l'option 2) est le meilleur choix ici, car elle nécessite le moins de changement mais en même temps est suffisamment flexible pour satisfaire la plupart (ou tous?) Des cas d'utilisation mentionnés ici et être très pratique à utiliser en même temps.
Néanmoins, je serais également heureux de voir quelque chose comme l'option 3) ou 4) fusionnée en amont. Donc, après plus d'un an de discussion ici, y a-t-il un calendrier quand ou si cela se produira?

Je conviens que l'option 2 est probablement la moins invasive. La seule fonctionnalité que je vois que l'option 4 pourrait fournir est une capacité à exécuter des commandes sur des conteneurs existants (en utilisant le mécanisme d'exécution docker). Par exemple, si tout ce que je veux est d'exécuter une migration de base de données ou des tests unitaires, il peut n'y avoir aucune raison de créer un conteneur entièrement séparé pour celui-ci si j'ai déjà un conteneur exécutant mon application. Cela dit, les conteneurs sont légers et je serais parfaitement satisfait de l'option 2.

@MadWombat J'ai le même sentiment sur l'option 4, c'est pourquoi j'ai proposé une autre fonctionnalité pour ce cas d'utilisation: # 4096. il y a un chevauchement avec la fonctionnalité décrite ici, mais je pense qu'elle pourrait être utile seule ou en plus de celle-ci

@mathroc J'ai mentionné l'option 4 en utilisant docker exec, car @acran a demandé s'il y avait une différence significative entre les options 2 et 4. Je ne peux pas, cependant, proposer un cas d'utilisation réel où vous voudriez spécifiquement exécuter une commande sur un conteneur existant plutôt que d’apporter un autre conteneur similaire à cette fin. Il peut y avoir un scénario avec des connexions persistantes limitées à un service ou à une autre ressource limitée qui est déjà utilisée par les conteneurs existants, mais je ne peux pas penser à un.

La seule fonctionnalité que je vois que l'option 4 pourrait fournir est une capacité à exécuter des commandes sur des conteneurs existants (en utilisant le mécanisme d'exécution docker).

C'est en effet un nouveau cas d'utilisation qui justifierait (et exigerait) l'introduction d'un nouveau concept de haut niveau différent des services. Mais tant que les commandes n'ont pas besoin d'être exécutées via docker exec dans le conteneur de services déjà existant, le concept de service existant devrait être suffisant.

Cependant, je ne peux pas proposer un cas d'utilisation réel dans lequel vous souhaiteriez spécifiquement exécuter une commande sur un conteneur existant plutôt que de créer un autre conteneur similaire à cette fin.

Le cas le plus proche auquel je puisse penser est quelque chose comme la modification d'un fichier de configuration dans le conteneur et le déclenchement d'un rechargement par l'application; en utilisant l'exemple de @mathroc de # 4096:

version: "2"
services:
  my_service:
    image: my/service
shortcuts:
  start-debugging:
    service: my_service
    command: echo "debug=true" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config
  stop-debugging:
    service: my_service
    command: echo "debug=false" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config

Bien que lié à ce problème, # 4096 a ses propres cas d'utilisation et peut-être l'option 4) pourrait-elle être déplacée là-bas?

Cela fait plus d'un an de discussions et nous ne semblons plus en avance pour prendre une décision. @bfirsh devrait simplement choisir un style et aller avec: sourire:

+1

+1, ce serait une fonctionnalité très utile à avoir.

Et un autre +1 pour l'option 2, avec quelque chose comme auto-start: false ou enabled: false .

Mon cas d'utilisation est l'extension des services. Il n'est pas possible d'étendre des services qui ont depends_on set, donc ce que je voudrais faire est de définir un modèle de service, puis d'étendre plusieurs services à partir de celui-ci. De toute évidence, le modèle doit être construit, mais pas exécuté automatiquement.

J'ai créé ma propre solution, je peux l'utiliser gratuitement.
Il est toujours en version bêta :)

https://github.com/jonathanborges/picles-docker

Beaucoup de bonnes options ici. Le besoin de cette fonctionnalité est réel.

L'option 2 est clairement la plus populaire des occurrences:

1 -> 4
2 -> 52
3 -> 3
4 -> 10

Un autre 👍 pour l'option 2

Nous pouvons gérer cela assez facilement dans un service "outils" avec un point d'entrée initial ou une commande qui revient simplement. Ensuite, nous exécutons ce service avec une commande alternative pour faire ce que nous voulons (par exemple tester ou amorcer les données). Par exemple

docker-compuse up -d
docker-compose run tools tests

Oui, le service d'outils apparaîtra comme "arrêté" dans docker-compose ps . Si cela n'est pas acceptable, alors l'option multi-fichiers de https://github.com/docker/compose/pull/2051 fonctionne. par exemple

docker-compose -f docker-compose.yml -f docker-compose-tools.yml up -d
docker-compose -f docker-compose-tools.yml logs -f tools

Bien qu'il semble que beaucoup d'aides à l'orchestration soient écrites pour ce besoin et que je suis coupable de travailler sur un aussi :).

Personnellement, je pense qu'il existe suffisamment de solutions de contournement (telles que les deux ci-dessus; faire preuve de créativité avec vos points d'entrée / conteneurs et / ou utiliser l'approche multifile avec un alias / assistant de shell), et composer peut rester simple.

@briceburg voir la discussion ci -

C'est une question de commodité, de ne pas avoir à taper docker-compose -f docker-compose.yml -f docker-compose-tools.yml up à la main sur le cli, de ne pas avoir à se souvenir si c'était docker-compose run tools tests ou docker-compose run utils tests ou même de compter sur un _multi-page “guide de démarrage du développeur” _ mais à la place ayant une interface unifiée et simple pour le développeur.

Encore une fois, CCing @bfirsh , @dnephin : pourriez-vous s'il vous docker-compose ??

@briceburg pour un environnement simple peut-être qu'une solution de contournement est acceptable, mais parfois ce n'est pas le cas. Regardez ma configuration:

rancher<strong i="7">@rancher</strong>:~/servers/sgi/docker$ ls -l 
total 64
-rwxrwxr-x 1 rancher rancher  303 Dec  8 20:05 cleanup.sh
drwxrwxr-x 3 rancher rancher 4096 Dec 16 15:26 conf
drwxrwxrwx 4 rancher rancher 4096 Dec 15 20:03 data
-rw-rw-r-- 1 rancher rancher   94 Dec 14 19:40 docker-compose.amt.yml
-rw-rw-r-- 1 rancher rancher  295 Dec  8 20:05 docker-compose.auth.yml
-rw-rw-r-- 1 rancher rancher  332 Dec  8 20:05 docker-compose.ci.yml
-rw-rw-r-- 1 rancher rancher  112 Dec  8 20:05 docker-compose.dbext.yml
-rw-rw-r-- 1 rancher rancher  347 Dec 14 19:40 docker-compose.dbint.yml
-rw-rw-r-- 1 rancher rancher  688 Dec 15 16:31 docker-compose.full.yml
-rw-rw-r-- 1 rancher rancher   81 Dec  8 20:05 docker-compose.local.yml
-rw-rw-r-- 1 rancher rancher  288 Dec 15 16:31 docker-compose.yml
-rwxrwxr-x 1 rancher rancher  721 Dec 14 19:40 redeploy.sh
-rwxrwxr-x 1 rancher rancher  861 Dec  8 20:05 setup.sh
-rwxrwxr-x 1 rancher rancher   66 Dec  8 20:05 shutdown.sh
-rwxrwxr-x 1 rancher rancher  269 Dec 14 19:40 startup.sh
drwxrwxr-x 2 rancher rancher 4096 Dec 14 19:40 worker

J'ai 8 fichiers de composition (que j'utilise dans plusieurs combinaisons) en plus de ceux qui se trouvent dans le répertoire worker , où je configure les conteneurs «ne pas démarrer par défaut». Le répertoire worker (avec un fichier .env lié au parent et des fichiers de composition vides pour la conformité avec la variable .env COMPOSE_FILE du parent) est ma solution de contournement, mais ma vie sera beaucoup plus facile lorsque nous aurons une solution pour ce problème.

@vipseixas, il est difficile d'évaluer le bon sens de cette solution à partir d'une liste de fichiers - même si oui, je suis d'accord qu'il est possible de ne pas démarrer automatiquement un service. Je suggère seulement que vous utilisiez un point d'entrée / commande par défaut qui ne fait rien pour les services que vous préférez _pas_ au démarrage automatique. Par exemple, le conteneur se ferme simplement par défaut ... et pour exécuter ces services avec une commande alternative via une exécution suivante de docker-compose.

Dans la plupart des cas, vous voudrez vous assurer que les contrôles de santé passent sur les services / conteneurs dépendants avant d'exécuter les tests - par exemple, jenkins est actif et en cours d'exécution (acceptant les connexions sur: 8080 ou autre) avant que ces tests ne s'exécutent. Dans le passé, j'ai utilisé dockerize pour cela.

Si je devais proposer une solution miracle, ce serait de permettre de définir un profil de composition via des variables d'environnement (par exemple DOCKER_COMPOSE_PROFILE = "tests"), et de permettre aux services d'être dépendants d'un profil - où tous les services par défaut sont "par défaut" "profil ou autre. Je voudrais également m'assurer que les services qui dépendent d'un autre service sont également _dependent_ sur HEALTHCHECK de ces services. Donc quelque chose comme

app:
  image: myapp:v1

tests:
  image: myapp:tests
  dependencies:
    - profile: "tests"
    - service: "app"
      healthcheck: true

# run the things
docker-compose up -d

# test the things
DOCKER_COMPOSE_PROFILE="tests" docker-compose up -d
DOCKER_COMPOSE_PROFILE="tests" docker-compose logs -f

+1 pour l'option 2.

Beaucoup ici ont proposé de nouvelles fonctionnalités intéressantes, mais quel est le cœur du problème ici? Je vote pour que ce soit aussi simple que possible.

Dans l'état actuel des choses, nous supposons que tous les services de notre docker-compose.yml seront mis en place sur docker-compose up . Nous travaillons tous avec nos propres scripts de bootstrap personnalisés, makefiles, outils de construction, etc., et heureusement, docker-compose et docker exposent une API complète pour la gestion des conteneurs individuels une fois que l'évier de cuisine est `` en place ''.

Mon seul besoin, le besoin de base qui m'a amené à cette discussion, est de préciser que l'un de ces services que j'ai définis n'est pas quelque chose que je veux «up» par défaut, pour une raison quelconque.

Quelle est la fonctionnalité la plus simple possible qui «réussit» pour nous tous? C'est une petite mise à jour de la spécification docker-compose.yml ( @bfirsh idée originale n ° 2) dans laquelle un service peut spécifier autostart: false

Je vote pour: "FAITES QUELQUE CHOSE POUR NOUS, MERCI." Nous votons, il nous faut maintenant au moins une réponse. 4 DIEU!

Quelle est la fonctionnalité la plus simple possible qui «réussit» pour nous tous? C'est une petite mise à jour de la spécification docker-compose.yml ( @bfirsh idée originale n ° 2) dans laquelle un service peut spécifier autostart: false

C'est bien mieux que toute autre alternative :)

C'est tellement simple.
scale: 0
https://github.com/docker/compose/issues/1661

@ dessiné-r quoi?

@ jonathanborges1542 C'est docker-compose scale servname=2 . Il n'y a pas d'équivalent dans le fichier docker-compose.yml .

@ drew-r scale: 0 indique actuellement au démon docker d'envoyer SIGTERM / SIGKILL à tous les conteneurs du service. Cela tuerait tout travail de maintenance même s'il n'a pas encore terminé son travail. C'est le comportement attendu. Changer cela serait un mauvais cas de surcharge de ce qui est un comportement clair en ce moment.

@gittycat Je comprends, mais ce que nous voulons ici, c'est de taper "docker-compose up" et tout sera prêt. Dans ce cas, cela ne fonctionnerait pas.

Je suis ce sujet depuis plus d'un an maintenant (la plupart des articles sont du côté des dockers).
Je crois qu'un nouveau «travail» de haut niveau vivant à côté des «services», des «volumes» et des «réseaux» est la meilleure option. C'est l'option 4 dans la liste OP ci-dessus.
C'est aussi une proposition au repo Docker.
https://github.com/docker/docker/issues/23880

@briceburg

il est difficile d'évaluer la validité de cette solution à partir d'une liste de fichiers

L'intention était simplement de montrer que j'ai de nombreuses combinaisons de fichiers et que l'utilisation de plusieurs options "-f" est trop sujette aux erreurs pour être effectuée manuellement.

Je suggère seulement que vous utilisiez un point d'entrée / commande par défaut qui ne fait rien pour les services que vous préférez ne pas démarrer automatiquement.

Parfois, il n'y a pas d'échappatoire à la catastrophe. Mais je préfère ma solution: j'utilise un répertoire différent qui ne sera jamais "composé" donc il n'y aura pas de conteneurs arrêtés inutiles polluant mon environnement. C'est pourquoi j'ai un répertoire de travail avec un ".env" lié au parent ".env".

Si je devais proposer une solution miracle, ce serait pour permettre de définir un profil de composition via des variables d'environnement (par exemple DOCKER_COMPOSE_PROFILE = "tests")

Ce serait la meilleure solution. Mais je ne pense pas que les développeurs soient enclins à augmenter la complexité ...

Je veux construire une image de base, "étendre" ceci dans le même docker-compose.yml et ne démarrer que la deuxième image, ce qui n'est pas faisable en une seule étape pour le moment. Avec l'option 2, ce sera le cas, mais peut-être que la meilleure et la plus propre manière est d'avoir une "étape de construction" et une "étape d'exécution", où la création des images de base est faite. Pour le moment, je dois exécuter 2 commandes et pas une seule.

+1 @ drew-r # 1661

Ce problème va-t-il être implémenté à un moment donné ou est-ce simplement quelque chose que les développeurs de composition ne veulent pas faire? Ce serait bien de le savoir pour que la communauté puisse commencer à chercher une autre solution.

Au fait, je vote pour l'option 2.

Je vous remercie

+1 pour l'option 2.
Respecterait-il cependant les dépendances explicites ... links etc?

Si je spécifie quel service mettre en place avec docker-compose up [service] il est rare que je veuille démarrer des services autres que le service en question et ses dépendances.

Un autre vote pour l'option 2. Il y a même un PR pour cela (https://github.com/docker/compose/pull/3047) que @acran a eu la gentillesse de créer, donc l'effort des développeurs de composition devrait être assez petit, car ils ont seulement besoin de le revoir (et c'est assez court et simple) et de ne pas écrire de code.

Si les développeurs de composition ne veulent pas faire cela, ils doivent le déclarer une fois pour toutes, puis fermer le ticket et le verrouiller pour éviter les commentaires.

@msabramo compose est essentiellement entravé par ce qui est décidé au niveau du moteur docker.

La demande est suivie au repo du moteur docker https://github.com/docker/docker/issues/23880
C'est de là que viendra la décision / le travail.

Je suggère que ce problème soit clos.

@gittycat compose peut toujours avoir la possibilité d'indiquer au moteur de démarrer un service ou non. C'est encore une demande très valable.

J'abandonne docker sur la production, il y a beaucoup de problèmes. Puis je migre vers un vagabond.

Un autre vote pour 2)

Un autre vote pour 2 et 4.

Juste pour souligner un cas d'utilisation, certains services ont des dépendances circulaires, la nécessité de générer des fichiers de configuration, d'exécuter des suites de tests parmi de nombreuses autres possibilités. Nous pouvons le découpler de Docker ou utiliser d'autres outils, mais cela ajoute une complexité inutile à la configuration du projet.

Avoir une simple commande pour la configuration et / ou pour les tests rendrait les choses beaucoup plus propres.

Un autre vote pour 2!

J'avais lu ce fil mais j'ai décidé de créer un nouveau post (https://github.com/docker/compose/issues/4650), qui s'est fermé et j'ai été référé ici. le point que je voulais faire est que si la plupart de la discussion dans ce fil concerne les indicateurs pour désactiver les conteneurs en cours d'exécution, mon cas d'utilisation est d'un troisième état: la création de conteneurs.

Je voudrais non seulement empêcher un conteneur d'être exécuté, mais être en mesure de ne jamais créer le conteneur en premier lieu (dans mon cas d'utilisation, j'ai un processus piloté par l'utilisateur qui accomplit cela)

@ekkis Je suis curieux de savoir comment cela s'est passé. Mon cas d'utilisation consiste à faire référence à l'image principale du conteneur et à configurer des «actions» alternatives, cela pourrait être fait en utilisant quelque chose comme bash, mais il est plus logique d'utiliser Docker.

Auriez-vous l'amabilité de donner plus de détails sur votre problème?

@frnco , je ne suis pas sûr de comprendre sur quoi vous aimeriez plus de détails. il existe des cas où vous souhaitez créer une image sans avoir besoin de créer des conteneurs. le mien en est un. Je veux une image donnée construite avec un tas d'autres images, mais celle-ci va être utilisée par un processus que j'ai écrit. Je ne veux pas avoir deux processus distincts pour la construction et avoir un indicateur pour build-only pourrait résoudre ce problème

@ekkis Je vous suggère de jeter un oeil à # 963, semble lié à ce que vous recherchez.

+1 pour l'option 2

+1 pour l'option 2

+1 pour l'option 2

+1 pour l'option 2

+1 pour l'option 2

+1 pour l'option 2

: +1: pour l'option n ° 2 avec une question sur une estimation sur cette fonctionnalité? Quelle est la meilleure solution de contournement? Autant que je puisse imaginer besoin de lister tous mes services comme:

docker-compose up service1 service2 service3

... et omettez ceux que je ne veux pas démarrer par défaut

Existe-t-il un moyen pour nous, dans la communauté open source, de contribuer à cette fonctionnalité qui semble fortement demandée?

+1 pour l'option 2.
Un moyen de spécifier «stade» serait génial. Dites, le service ne fonctionnera qu'en production.

+1 pour l'option 2.

Votez pour l'option 2

up le filtrage des commandes sera parfait - docker-compose up service1 service3

: +1: pour les options 2 et 4

À ce stade, il semble évident que l'option 2 est ce que les utilisateurs veulent. Quelles sont les prochaines étapes pour y parvenir?

Ici, à +1 pour l'option 2, je suis tombé sur ce problème en espérant que cette fonctionnalité existait déjà.

+1 sur l'option 2

... et un +1 de plus pour l'option 2

+1 pour l'option 2

+1 pour l'option 2 :-)

+1 pour les options 2 et 4

Salut à tous,
+1 option 2

À mon humble avis, l'option sera très utile sur les environnements locaux, lorsque vous avez une application basée sur des micro-services ou avec une architecture hexagonale; en tant que développeur, je ne peux exécuter que les éléments nécessaires pour mon travail le plus proche;

L'option 2 est celle que la plupart des utilisateurs souhaitent. La décision à ce sujet doit-elle encore être prise ou le développement à ce sujet a-t-il commencé et est-il suivi ailleurs?

Je pense que lorsque je terminerai l'université dans quelques mois et que j'aurai plus de temps, il sera beaucoup plus rapide d'implémenter cette fonctionnalité par moi-même (bien que je n'ai pas appris Python, dans lequel je pense que compose est écrit), mais j'ai vu que une énorme quantité de votes et de demandes, pendant deux ans, sans aucune avancée, et l'auto-implémentation semble être la solution pour les 5 prochaines années (jusqu'à ce que cette fonctionnalité soit mise en œuvre officiellement).

bien sûr +1000 pour l'option 2

+1 option 2

Cela ferait-il une différence si je votais pour l'option 2? 'semble peu probable que ce soit le cas.

Les commentaires ici sont devenus acerbes ces derniers temps, et aucun nouveau retour n'a vraiment fait surface, ce qui me pousse à envisager de verrouiller ce fil. Veuillez rester courtois lorsque vous interagissez ici.

Telle est la position officielle actuelle de l'équipe de maintenance à ce sujet. Bien qu'il soit toujours à l'étude si nous voulons ajouter cette fonctionnalité, ou une fonctionnalité similaire, comme option de commodité, ce n'est pas une priorité pour les raisons mises en évidence et parce qu'il existe d'autres outils plus adaptés.

@ shin- Avant de verrouiller cela, puis-je obtenir la clarté sur la volonté de la communauté de se développer. L'équipe principale la fusionnerait-elle si elle répond aux normes de l'équipe? Dans les fils de discussion, il y a une implémentation et un membre de la communauté prêt à le terminer, ils cherchaient juste une confirmation que ce ne serait pas un gaspillage de leur investissement. Si nous pouvons obtenir des commentaires, je traquerai ces fils pour voir si nous pouvons déplacer cela vers la clôture.

@jimzucker Non - parce que le problème ici n'est pas la mise en œuvre; une mise en œuvre de base de cela prendrait une demi-journée pour votre développeur moyen. Ce qui nous préoccupe ici, c'est un problème de conception fondamental.

1. Qu'est-ce qu'un service? De par sa conception, un service est un processus de longue durée clairement défini qui interagit avec d'autres services pour former une application. C'est l'hypothèse de base sur laquelle Compose fonctionne et guide notre conception pour la plupart, sinon toutes les fonctionnalités que nous implémentons.
2. Selon cette définition, un "service qui n'est pas démarré par défaut" n'est pas vraiment un service [1] - il s'agit plus d'une tâche prédéfinie, exécutée dans un conteneur et agissant sur l'application, plutôt que d'en faire partie .
3. Par conséquent, il est erroné (fondamentalement par conception) de l'appeler un service. À ce stade, nous devons envisager de créer un nouveau type de définition dans votre fichier Compose (je l'appellerai "tâche" par souci de concision, la terminologie exacte n'a pas d'importance ici).
4. Étant donné que les tâches sont par nature des processus d'exécution courts, elles utilisent un ensemble d'options différent de celui des services. Par exemple, nous pouvons comprendre que les tâches n'ont pas besoin d'exposer les ports [2]. D'un autre côté, une option comme le fichier CID qui est généralement inutile pour les services pourrait être vraiment utile pour les tâches.
5. Maintenant, dans la plupart des projets, les tâches ont tendance à avoir des chaînes de dépendances (c'est pourquoi dans le monde traditionnel, sans conteneur, nous avons des Makefiles) - nous devons donc avoir au moins une implémentation de base des chaînes de dépendances, avec parallélisme, et être capable de dire si cette tâche de génération JAR qui prend toujours 10 minutes doit vraiment être exécutée à nouveau.
6. Ensuite, certains services dépendent en fait des tâches qui ont été exécutées avant de pouvoir démarrer, ajoutant un autre niveau de complexité à la façon dont nous calculons et gérons les dépendances.
7. Et certaines tâches ont besoin de certains services pour être exécutés (par exemple, la migration de la base de données).

À ce stade, cela est devenu un morceau de code entièrement nouveau qui correspond ou dépasse probablement cmake en termes de portée et de complexité. C'est pourquoi nous avons résisté à l'implémentation pendant si longtemps - en partie parce que ce n'est pas du tout ce pour quoi Compose est conçu, mais aussi parce que nous [3] n'avons tout simplement pas le temps ou les ressources pour implémenter ou maintenir ce que cette fonctionnalité devrait devenir pour être vraiment utile aux gens.

Espérons que cela clarifie un peu plus les choses. Je sais que les gens ont été contrariés et déçus de la réponse (ou de l'absence de réponse) sur ce fil, et je ne suis pas sûr que cela atténuera cela de quelque manière que ce soit, mais c'est le cas.

[1] Certaines personnes mentionnent vouloir avoir des "services optionnels", mais ce n'est pas le cas d'utilisation le plus courant mentionné dans ce fil. La plupart des gens veulent la fonction «tâche», pour autant que je sache.
[2] Je suis sûr que quelqu'un me contredira avec un exemple de tâche qui nécessite d'exposer les ports, ce qui ne fera que montrer que l'exercice de décider quelles options sont applicables à chaque ensemble n'est pas trivial.
[3] Et à ce stade, je veux dire "je", car je suis le seul mainteneur à travailler activement sur docker-compose en ce moment.

@ shin- je vois le point. Ce que je recherche, ce sont des "services optionnels" dans vos notes de bas de page et les cas d'utilisation pour cela, et non l'idée de tâches, pouvons-nous en quelque sorte nous mettre d'accord sur la façon dont nous pouvons progresser sur ce point, car c'était la partie du fil que j'essaie de défendre et mes billets clairement sur ce chemin étaient fermés en faveur de ce fil. Si nous pouvons séparer cela des points que vous avez clairement définis comme des «tâches», nous pouvons faire des progrès. Lorsque les gens font un +1 pour l'option 2 dans ma lecture, c'est au service optionnel. Heureux de mettre cela hors ligne pour discuter et nous pouvons ensuite revenir sur le forum, je suis à [email protected]

@ shin- votre point n ° 2 est faux. un service est un service, qu'il soit en cours d'exécution ou non. il existe d'innombrables cas d'utilisation où les services dépendants modifieront le comportement lorsque la dépendance n'est pas disponible, de sorte que votre couche d'application peut ne pas, ne doit pas, exiger que tous les «services» soient disponibles à tout moment

si vous y pensez dans les termes les plus traditionnels, considérez qu'un serveur web est un "service" mais il peut être arrêté ou configuré pour ne pas démarrer par défaut sur un hôte donné mais personne ne le considérerait autre chose qu'un service

Je pense que beaucoup de personnes qui demandent cette fonctionnalité ne veulent pas exécuter des tâches mais des services optionnels. Par exemple, si vous avez un ensemble de microservices fonctionnant en tant que conteneurs Docker et que vous les déployez tous comme un service complet, peut-être qu'un jour vos exigences changent et vous n'avez pas besoin d'exécuter tous les conteneurs de tous vos serveurs car dans ce cas, vous n'ont pas besoin d'une fonctionnalité spécifique incluse dans un conteneur non obligatoire.

De plus, je pense que c'est une fonctionnalité intéressante pour l'environnement de développement; si vous corrigez un bogue dans un conteneur spécifique, vous n'avez pas besoin de démarrer tous les conteneurs correspondant.

Exactement, avec un simple champ booléen, nous pourrions facilement activer / désactiver les services du fichier .env et éviter d'éditer le fichier yaml.

@ekkis Je pense que vous confondez quelque peu tolérance aux fautes et dispense. Voir également ma note de bas de page sur le sujet, où je reconnais que certains cas d'utilisation existent.

Tout le monde: veuillez garder à l'esprit que si certains services sont optionnels pour votre application, il est déjà possible de gérer cela avec les fonctionnalités actuelles. La méthode recommandée pour ce faire est d'avoir un fichier de composition distinct qui peut être inclus ou exclu à l'aide de l'indicateur -f . Ils ne sont pas un argument très convaincant pour ajouter cette option.

@ shin- J'apprécie que vous ayez pris le temps d'avoir ce dialogue avec nous. Je suis d'accord qu'il existe plusieurs façons de le faire, car vous suggérez plusieurs fichiers yml, vous pouvez également transmettre une liste de services, mais ceux-ci ne sont pas pratiques et entraînent une erreur de l'utilisateur créant un risque opérationnel. Surtout dans le cas d'un produit commercial, nous voulons distribuer un fichier de composition et obtenir par défaut le comportement commun souhaité et donner des instructions pour les options avancées, un fichier rend tout cela beaucoup plus net pour le développement, le CI / CD et la distribution. L'ajout de variables ENV avec des valeurs par défaut nous a été d'une grande aide et a éliminé le besoin d'avoir de nombreux fichiers yml, ce sera une étape de plus vers la gestion d'un seul fichier décrivant le déploiement.

Y a-t-il une forme que l'équipe de base serait disposée à accepter une contribution sur ce LMK.

@shin , je n'ai fait aucune référence à la tolérance aux pannes ou à la dispensabilité. J'ai simplement fait une remarque sur la définition d'un "service", à savoir que le fait que le service soit exécuté ou non n'est pas inhérent à la définition

@ shin- Je suis tout à fait d'accord avec @ekkis : ne pas être démarré _par défaut_ ne viole pas la définition d'être un service, donc votre point 2. est une hypothèse qui n'est pas _nécessairement_ vraie et les points consécutifs le sont aussi puisqu'ils sont basés sur l'hypothèse de 2.

Par exemple: lorsque je développe une application en utilisant une base de données mysql, je définis généralement un _service_ supplémentaire phpmyadmin . C'est un vrai service: des ports exposés de longue durée, dépendants d'autres services.
Mais je ne veux pas démarrer ce service _par défaut_ mais seulement _à la demande_ / en développement.
Actuellement, je réalise cela en mettant ce service dans un docker-compose.yml supplémentaire et en le démarrant en fournissant les deux fichiers à docker-compose - comme vous l'avez suggéré ci-dessus.

Donc, oui, il existe déjà des moyens possibles pour y parvenir; que ce soit en divisant les services en plusieurs fichiers ou simplement en utilisant un outil autre que docker-compose . Mais comme je l'ai déjà écrit ci - commodité , en particulier dans les environnements de développement .
Devoir taper docker-compose -f docker-compose.yml -f docker-compose-tools.yml up est tout sauf pratique et donc docker-compose ne tient pas ses propres promesses :

Ensemble, ces fonctionnalités offrent aux développeurs un moyen réduire un «guide de démarrage du développeur» de plusieurs pages à un seul fichier Compose lisible par machine et à quelques commandes.

Quels services démarrer ou quels yml fichiers à utiliser dans quel environnement se trouve généralement dans le _multi-page «guide de démarrage du développeur» _ - s'il y en a du tout ...

Donc, à mon avis et comme @jimzucker l'a écrit, la plupart des +1 sont ici en réalité pour des "services optionnels" plutôt qu'un nouveau concept de tâches. Au moins tous sont mieux lotis avec un simple booléen pour marquer un _service_ à démarrer par défaut ou non.

Comme le montre mon PoC , le changement de code requis - pour les «services optionnels» - est tout à fait gérable et offre à la plupart des gens ici un énorme avantage en termes de commodité. L'option 2 - lue comme "_possibilité de marquer un service optionnel_" - est un compromis raisonnable pour résoudre ce problème.

@ shin- ne seriez-vous pas d'accord sur le fait que donner aux utilisateurs la possibilité de marquer des services comme facultatifs - mais qu'il s'agit toujours de services - les aiderait grandement?
Lorsqu'il est réduit à "marquer les _services_ comme facultatifs / non démarrés par défaut", ce problème / une demande d'extraction pour cela serait-il accepté et fusionné?

@shin , pour ajouter au point de utilisant des noms . considérez que chaque fois que je fais "up", j'obtiens un tas de "services" nommés project_app_1 , project_otherapp_1 , etc. cela n'a aucun sens car ils doivent être exécutés en utilisant les informations d'une base de données (j'ai un service principal qui les lance) . donc je dois toujours aller les tuer. donc pour moi un drapeau NO_RUN ou BUILD_ONLY a tout son sens. ce serait pratique

@acran

n'êtes-vous pas d'accord sur le fait que donner aux utilisateurs la possibilité de marquer des services comme facultatifs - mais qu'il s'agit toujours de services - les aiderait grandement?

Je ne suis pas d'accord sur la façon dont cela aiderait - je pense que «grandement» est surestimé. Dans votre exemple, le simple fait d'avoir un docker-compose.phpmyadmin.yml qui peut éventuellement être inclus n'est pas plus fastidieux ou complexe (en termes d'instructions "guides du développeur") que de définir une variable d'environnement / de modifier une définition de service dans le fichier principal.
J'envisage également le compromis de donner aux développeurs des

Lorsqu'il est réduit à "marquer les services comme facultatifs / non démarrés par défaut", ce problème / une pull request pour cela serait-il accepté et fusionné?

Voir ci-dessus - dès que cette fonctionnalité sera disponible, les gens commenceront à l'utiliser pour des choses autres que son objectif prévu et s'attendent à ce que nous implémentions un nouvel ensemble de fonctionnalités pour la prendre en charge. Aussi cc @jimzucker ; Je ne peux actuellement pas penser à une implémentation qui empêcherait ce scénario de se dérouler. Si je pouvais, ce problème aurait été clos il y a longtemps.

@ekkis Si vous ne voulez jamais démarrer ces services vous-même, pourquoi est-ce exactement un problème de les isoler dans un fichier séparé? Je ne comprends vraiment pas pourquoi c'est un tel blocage ici.

@shin si un docker-compose.yml peut être utilisé pour créer un service, c'est un outil très utile pour centraliser mon processus de construction. il est en fait très logique que je veuille (conditionnellement) créer un service avant de l'exécuter, et j'applaudis cette fonctionnalité

donc le fichier docker-compose est aussi mon makefile . mais ce n'est pas parce que je construis quelque chose que je veux l'exécuter. cela n'a aucun sens pour docker-compose de supposer que je veux exécuter un service, inventer un nom pour lui et l'exécuter sans paramètres / variables d'environnement / etc appropriés.

franchement, je ne suis pas sûr de comprendre quelle est l'objection à ce simple patch. ça me serait grandement utile

J'ai clairement indiqué dans mon article précédent pourquoi la position officielle de l'équipe était de ne pas utiliser votre fichier Compose comme un Makefile. Si vous pensez que nous nous trompons sur ce point et que vous voulez toujours le faire, c'est votre prérogative, mais il est un peu absurde d'insister pour que nous ajoutions des fonctionnalités pour le supporter.

@tibia-

Dans votre exemple, le simple fait d'avoir un docker-compose.phpmyadmin.yml qui peut éventuellement être inclus n'est pas plus fastidieux ou complexe (en termes d'instructions «guides du développeur») que de définir une variable d'environnement / modifier une définition de service dans le fichier principal.

En fait, je n'ai pas encore pensé à impliquer des variables d'environnement ici. Mon flux de travail souhaité "services optionnels" permettrait enfin est le suivant:

• Je copie / clone un nouveau projet
• Je vois qu'il y a un (seul) fichier docker-compose.yml dedans, donc je sais, tout ce que j'ai à faire est d'exécuter docker-compose up et l'application est construite et exécutée
• Maintenant, je veux démarrer l'un des services optionnels à des fins de développement (par exemple, un débogage supplémentaire, phpMyAdmin). Tout ce que j'ai à faire est de docker-compose up phpmyadmin .

Pour moi, c'est beaucoup plus pratique que d'utiliser plusieurs fichiers docker-compose.yml , et comme je le comprends pour la plupart des autres personnes ici aussi. L'avantage d'avoir ici des "services optionnels" est

• pour le développeur de ne pas avoir à dupliquer quoi que ce soit entre plusieurs fichiers ou de considérer attentivement quelles définitions mettre dans quel fichier, mais n'ayant à définir qu'un seul indicateur booléen ( auto_up: false ) sur un service
• pour l'utilisateur n'ayant pas à savoir / se souvenir quels fichiers inclure pour quels services: dois-je exécuter
  
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml up
  
  
  • docker-compose -f docker-compose.yml -f docker-compose.phpmyadmin.yml up ou même
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml -f docker-compose.yml up ?
  
  
• au lieu de cela, la seule chose dont l'utilisateur a besoin _connaître_ est qu'il existe un service appelé phpmyadmin et que l'utilisateur sait immédiatement comment le démarrer.

Voir ci-dessus - dès que cette fonctionnalité sera disponible, les gens commenceront à l'utiliser pour des choses autres que son objectif prévu, et s'attendent à ce que nous implémentions un nouvel ensemble de fonctionnalités pour la prendre en charge

Ne vous méprenez pas, je comprends non seulement votre préoccupation ici, mais je suis d'accord avec elle: il y aura toujours des utilisateurs qui plieront cette fonctionnalité - ou toute autre (!) - fonctionnalité pour s'adapter à leurs flux de travail souhaités, même si les fonctionnalités n'ont jamais été censées être utilisé comme ça.
MAIS pour toute demande sur les "services optionnels" des fonctionnalités manquantes d'une "tâche", vous pouvez alors facilement affirmer que les services ne sont pas des tâches et que les tâches doivent d'abord être introduites comme un nouveau concept et ne sont donc pas (encore) prises en charge. C'est-à-dire que rien de plus que de simplement marquer un service comme facultatif est un pas vers le concept de tâches (par exemple, option 4) et il y a une nette distinction entre les deux.

Avec la fonctionnalité de marquer un _service_ comme facultatif, nous sommes toujours sur le côté droit de cette coupe. "La fonctionnalité en soi n'est pas trop complexe à implémenter mais elle _pourrait_ inciter les utilisateurs à l'utiliser à tort" étant actuellement le seul argument réel (bien que valide!) Contre cette fonctionnalité est une raison peu satisfaisante pour ne pas l'implémenter - du moins pour les utilisateurs qui pourraient en tirer beaucoup de confort tout en l'utilisant correctement ™.

Je suis prêt à rebaser ma demande d'extraction # 3047 au maître actuel et à faire tout le polissage nécessaire pour que cela soit accepté, veuillez simplement me le faire savoir;)

Mon cas d'utilisation est que nous ne poussons pas toutes nos images vers le hub ou le quai de docker, nous n'avons pas non plus notre propre registre, et le fait de pouvoir marquer un service comme n'étant pas à exécuter par défaut signifie que nous pouvons avoir une image de base définie dans docker-compose.yml qui ne démarre pas, puis d'autres conteneurs l'utilisant ou en s'appuyant sur elle.

Je serais enclin à utiliser un fork de docker-compose qui implémente cette fonctionnalité uniquement pour cette fonctionnalité singulière.

@ shin- Bien que je pense que nous comprenons tous votre point et que nous sympathisons avec lui, je ne pense pas que "il pourrait être mal utilisé" est un bon argument pour quelque chose avec - clairement - de nombreux cas d'utilisation viables. Bien sûr, il sera mal utilisé. C'est exactement ainsi que les logiciels et les nouvelles idées se développent; d'utiliser la technologie pas entièrement comme elle le devrait. Le Web ne serait pas ce qu'il est aujourd'hui si nous n'avions pas abusé de toutes les technologies fournies au cours des 25 dernières années.

En tous cas.
Selon vous - simplifié - la différence entre un service et une tâche est la durée de vie. Cela a du sens, et je comprends que vous les considérez comme deux concepts différents et que vous pensez que c'est une boîte potentielle de vers. Mais cette distinction n'est nulle part clarifiée ou expliquée dans la documentation. Il n'est pas non plus indiqué nulle part que docker n'est pas destiné à être utilisé pour accélérer des processus temporels.
Ce que je veux dire, c'est que si l'équipe des dockers a une position ferme à ce sujet, cela devrait être clair dès le départ.
Également. Tâche ou service, il y a clairement un chevauchement. Et marquer un service comme facultatif n'est certainement pas quelque chose qui appartient uniquement au côté tâche.
D'un point de vue pratique, je suis tout à fait d'accord avec @acran - avoir un seul fichier docker-compose est bien meilleur DX, simplifie beaucoup et est moins sujet aux erreurs que d'avoir plusieurs fichiers docker-compose.

Hehe, je me souviens des discussions féroces que nous avons eues lorsque nous faisions du lobbying pour permettre aux "navigateurs" d'afficher des images, l'argument principal des opposants étant que cela s'appelait le protocole de transfert d'hyper texte .
Désolé pour les souvenirs OT d'un vieux pet.

@ shin- si le docker-compose ne doit pas être utilisé comme un makefile, alors il ne doit pas fournir de fonctionnalité de makefile. si ça me permet de construire mes projets (bravo!) alors prendre la position que ce n'est pas un makefile est ridicule

@ shin- look, vous n'avez pas à implémenter une fonctionnalité que vous ne voulez pas, peu importe à quel point vos raisons sont déraisonnables ou l'utilité de la fonctionnalité. c'est simplement que cela rend l'outil moins utile à ceux d'entre nous qui l'utilisent. nous sommes les utilisateurs, nous connaissons les cas d'utilisation - et les outils ne sont aussi utiles et précieux que pour les cas d'utilisation

cela pour moi n'est qu'une irritation mineure, je dois tuer manuellement un tas de trucs qui sont engendrés sans raison valable chaque fois que je monte mes services. pour d'autres, cela peut être un obstacle, l'irritation variera en gravité

Je comprends que la position officielle est que nous devrions utiliser dobi, même si c'est excessif pour ce dont nous avons besoin. mais cette position officielle n'explique pas la base de votre réticence à accepter un PR utile. nous pouvons toujours utiliser dobi lorsque la demande sur docker-compose est trop grande ou le chevauchement suffisant pour migrer, mais c'est un tout petit changement qui rendrait toutes nos vies bien meilleures

et accessoirement, je ne suis pas "acerbe" mais verrouiller le fil pour empêcher de nouvelles discussions serait simplement antidémocratique et autoritaire. l'open source est construit sur le principe de l'ouverture et je serais triste de voir ce projet géré en utilisant la censure et les tactiques dictatoriales

@rysiekpl C'est un problème que nous cherchons à résoudre d'une manière différente, voir https://github.com/docker/cli/pull/452 (une fois la syntaxe délibérée, elle se retrouvera dans Compose et v2 comme bien)

@creynders Je pense que c'est un peu une mauvaise caractérisation - personne ne dit que les services optionnels ne devraient pas exister (et en fait, comme je l'ai souligné, il existe des moyens de les déclarer en utilisant des fichiers séparés). Cela revient plus à se demander si la non-fermeture explicite d'une balise <img> est valide et si notre navigateur spécifique doit la prendre en charge ou non.

Aussi, à votre point:

Mais cette distinction n'est nulle part clarifiée ou expliquée dans la documentation. Il n'est pas non plus indiqué nulle part que docker n'est pas destiné à être utilisé pour accélérer des processus temporels.

C'est en fait le premier paragraphe de la page https://docs.docker.com/compose/overview/ (c'est moi qui souligne):

Compose est un outil permettant de définir et d'exécuter des applications Docker multi-conteneurs. Avec Compose, vous utilisez un fichier Compose pour configurer les services de votre application. Ensuite, à l'aide d'une seule commande, vous créez et démarrez tous les services à partir de votre configuration.

@ekkis Je suis vraiment content que Compose soit en fait utile pour vos projets! J'espère que je ne suis pas aussi sincère dans tout cela, ce n'est absolument pas grave si c'est la façon dont vous souhaitez utiliser le logiciel. Ce que je dis, cependant, c'est qu'aller plus loin dans cette direction aggraverait probablement la situation à long terme. Nous savons tous ce qui arrive aux applications qui essaient de faire trop de choses (même si je suppose qu'Emacs a réussi: stuck_out_tongue :)

Je ne pense pas que j'étais "autoritaire", mais peut-être que je ne me suis pas exprimé correctement. Mon intention était d'encourager les gens à rester civils et positifs dans leurs interactions. Le fil est toujours déverrouillé et continuera de l'être aussi longtemps que les gens s'abstiendront d'être méchants ou impolis.

vous créez et démarrez tous les services à partir de votre configuration.

et je suppose que notre argument est que cela aurait dû lire "créer et / ou démarrer", bien que pour être juste avec le langage, il n'est pas nécessaire d'indiquer le OU parce qu'il est implicite dans le ET. en d'autres termes, il est vrai que vous pouvez à la fois créer et démarrer un service, mais rien n'implique qu'il doit faire les deux

Nous savons tous ce qui arrive aux applications qui essaient de faire trop de choses

oui, je peux comprendre que vous gérez les frontières du domaine

Je ne pense pas que j'étais "autoritaire"

J'adore le mouvement open source. nous pouvons avoir nos désaccords mais nous sommes toujours dans le même bateau. les guerres au sein de la communauté bitcoin étaient épouvantables et je suppose que je suis toujours sous le choc, alors merci de rester du côté de la civilité

en guise de séparation, je vous demanderais de revoir https://github.com/docker/compose/issues/4650 qui n'est pas la même que la demande sur ce fil (comme vous l'avez indiqué en le fermant) mais convient à mon utilisation cas, à savoir que le drapeau discuté ici n'est pas binaire mais trinaire

J'aime beaucoup l'idée de définir plusieurs fichiers. Cependant, inclure tous les fichiers avec plusieurs -f y compris l'original, semble être une exagération totale.

Il existe en fait un moyen plus pratique, qui fonctionne pour moi (voir PS ci-dessous): mettez tout le service que vous ne voulez pas exécuter dans docker-compose.override.yml . Et utilisez docker compose -f docker-compose.yml up pour un démarrage normal (notez qu'il s'agit d'une commande unique). Sur tous les appels consécutifs, la dérogation sera générée ...

Dans l'ensemble, tout cela est très peu intuitif et un peu insatisfaisant. Ajout d'un supplémentaire:

• une option de désactivation des services a du sens, en particulier pour les remplacements plus complexes

• L'option -f est minime mais pas très intuitive, une autre option -F <name> qui ajoute simplement des remplacements supplémentaires serait très accueillante (ie docker-compose..yml. Une alternative consisterait à utilisercomme un répertoire dans lequel tous les fichiers .yml proviennent: avec les liens symboliques, cela serait aussi puissant que /etc/apache/sites.available -> /etc/apache/sites.enabled

D'un autre côté: n'importe qui pourrait fournir un script (fonction) wrapper simpe pour que son shell émule ce comportement ...

PS: mon cas d'utilisation est que je définis un débogueur comme un service. Évidemment, ce service n'est pas nécessaire tout le temps mais a besoin des liens (également pour des raisons de sécurité) pour fonctionner correctement.

Un autre cas d'utilisation pour lequel l'option 2 est excellente:

Disons que vous avez une équipe de personnes travaillant sur le même projet. Certains d'entre eux ont accès aux services gérés AWS, mais certains d'entre eux doivent exécuter les ressources correspondantes en tant que conteneurs locaux. Donc, en fonction de mon flux de travail, j'aurai _always_ ou _never_ besoin de conteneurs Redis et MySQL dans ma constellation de composition.

Je vais affirmer catégoriquement que la gestion de plusieurs fichiers de composition est stupide pour ce cas d'utilisation. La quantité de chevauchement est comique. La maintenance de plusieurs fichiers est un jeu d'enfant - ils _seront_ désynchronisés et créeront de la confusion. Je suis franchement un peu choqué que quiconque ait pris cette option au sérieux pour n'importe quel cas d'utilisation.

Être capable d'activer et de désactiver rapidement des services, sans commenter de gros blocs de configuration (gênant en YAML, très compliqué si commis accidentellement), est excellent en soi. Mais si composer un jour obtient la possibilité d'interpoler des variables dans la configuration, cette fonctionnalité devient automatiquement exponentiellement plus puissante. Jusque-là, c'est sacrément utile.

Complètement d'accord avec @campadrenalin.

Toute cette discussion, si je comprends bien, concerne essentiellement un grand nombre de personnes fournissant un grand nombre de très bonnes raisons de mettre en œuvre l'option 2, et les développeurs refusant parce que quelqu'un pourrait hypothétiquement mal interpréter l'existence de cette fonctionnalité et demander d'autres fonctionnalités non liées. .

OT:

Mais si composer un jour obtient la possibilité d'interpoler des variables dans la configuration, cette fonctionnalité devient automatiquement exponentiellement plus puissante.

Cette fonctionnalité n'est-elle pas disponible depuis longtemps? Voir https://docs.docker.com/compose/compose-file/#variable -substitution. Je l'utilise pour permettre la personnalisation de notre environnement de développement Compose en utilisant le fichier .env - par exemple, l'emplacement du code source, le mappage de port, etc. Depuis la version 2.1 du fichier de composition, même la variable de style shell default ( ${VARIABLE:-default} / ${VARIABLE-default ) est pris en charge.

Toute cette discussion, si je comprends bien, concerne essentiellement un grand nombre de personnes fournissant un grand nombre de très bonnes raisons de mettre en œuvre l'option 2, et les développeurs refusant parce que quelqu'un pourrait hypothétiquement mal interpréter l'existence de cette fonctionnalité et demander d'autres fonctionnalités non liées. .

Je trouve que c'est - peut-être un ton un peu dur, mais valable en substance - un très bon résumé de @rysiekpl.
Alors, @ shin-, nous sommes-nous rapprochés d'une décision concernant cette question? Que ce soit pour le fermer ou pour mettre en œuvre / accepter un PR pour l'option 2?

Je vois et comprends totalement vos préoccupations, mais je vois aussi que les avantages l'emportent sur le risque que quelqu'un abuse potentiellement de cela, car il s'agit d'un changement plutôt minime mais offre à beaucoup de gens beaucoup plus de possibilités pour des flux de travail beaucoup plus pratiques.

Comme docker-compose semble être abandonné à long terme en faveur de docker stack de toute façon, je suggère que tout le monde passe au nouveau format v3 et docker stack outil

En utilisant une pile sur un essaim (même sur 1 nœud), vous pouvez spécifier ceci:

        deploy:
            mode: replicated
            replicas: 0

Le fait de n'avoir aucun réplicas désactive essentiellement l'exécution du service.

Vous aurez juste besoin d'un autre outil pour générer ce yml si vous souhaitez appliquer des substitutions de variables d'environnement, comme envsubst.

Vous pouvez ensuite utiliser un espace réservé dans votre yml:

        deploy:
            mode: replicated
            replicas: ${R}

Et traitez-le de cette façon:

export R=0
docker stack deploy stack1 --compose-file=<(envsubst <docker-compose.yml) 

Donc, si docker-compose va être obsolète à long terme, quel est exactement le problème avec la fusion de la pull request qui existe déjà ? Je veux dire, si docker-compose va dans le sens du dodo, en quoi "quelqu'un demandera des fonctionnalités étranges" est-il un vrai problème?

Comme docker-compose semble être abandonné à long terme au profit de docker stack

Donc, si docker-compose va être obsolète à long terme

attendez, wat? docker-compose est au cœur de beaucoup de gens pour leur flux de travail de développement, qui n'a guère besoin d'un gestionnaire d'essaim. Pourriez-vous me signaler une déclaration officielle de Docker à ce sujet?

Je lis peut-être mal, mais il semble que l'essaim de docker et la pile de docker soient étroitement associés aux services de cloud docker. Ces éléments sont-ils configurables sur un système autonome hors ligne?

Ces éléments sont-ils configurables sur un système autonome et hors ligne

oui, vous pouvez les utiliser hors ligne.

Pour moi, il semble que les piles sur docker-swarm seront finalement un sur-ensemble des fonctionnalités de docker-compose. Je pense que les fichiers descripteurs sont déjà très similaires. Espérons que cette transition ne sera pas trop difficile. Le plus gros ennui que je puisse voir est de gérer l'essaim séparément de la ou des piles. Plus de frais généraux pour moi car je n'ai aucun intérêt à exécuter des applications composées sur plus d'un nœud.

Ou peut-être que je ne comprends pas tout ...?

+1 sur l'option 2!
Et je pense que la baisse de la composition de docker en faveur de la pile d'essaim sera un gros inconvénient pour la communauté. Docker compose est si simple et facile à utiliser !!

@tberne Je suis d'accord avec ça. docker-compose est simple et simple est une bonne chose. on devrait voter pour le garder

Hé, quelle discussion approfondie! Ne faites pas trop attention à ce commentaire, juste mes deux cents.

Au début, j'étais d'accord avec la majorité pour simplement ajouter une sorte de drapeau enabled .
Ensuite, j'ai vu une proposition de regrouper les définitions par groupes et je l'ai considérée comme une bonne idée.
Ensuite, j'ai lu sur Dobi, je l'ai essayé, je me suis assuré qu'il ne pouvait pas être utilisé dans mon projet pour le moment et j'ai continué à lire.
Ensuite, j'ai lu les arguments de @ shin- et je les ai jugés assez bons, bien que je sois également d'accord avec certains contre-arguments.

Ma solution actuelle est de créer des yamls docker-compose et d'écrire des scripts d'encapsulation bash pour ne pas exécuter docker-compose à la main.

Par exemple, voici comment j'exécute des conteneurs qui exécutent un site Web ( ./docker/scripts/up script):

#!/usr/bin/env bash

def_opts="-d"

cd "$(dirname "$0")"/../

# A separate bash file with functions like: get_args, add_hosts...
. ./functions.sh

docker-compose -p ${PROJECT} up ${def_opts} $(get_args "options services" "$@") && \

# Adding host to /etc/hosts
add_hosts "$HOSTS" web && \
add_hosts "$HOSTS_MAIL" mail

Big +1 à l'option 2 ou 3.

+1 pour l'option 2 ou 3.

Le concept de "groupe" proposé semble également intéressant!

+1 pour l'option 2

_Il y a tellement de +1 on option x que je ne trouve même pas la déclaration originale. Veuillez utiliser les boutons de réaction sous les messages à la place._

Pour ajouter une nouvelle idée:

Ne pouvons-nous pas simplement définir une échelle par défaut sur 0 ?

web:
  image: busybox:latest
  command: echo 'scaled'
  scale: 0

Vous devriez juste faire l'option 2 (mais peut-être ne pas démarrer à la place ou quelque chose comme ça) parce que les gens attendent depuis des années maintenant, puis encapsuler docker-compose avec leurs propres gestionnaires de configuration parce que l'outil est trop limité, ce qui va à l'encontre du but car il fait ce que docker compose devrait faire. Dans deux ans, quelqu'un pourrait également créer son propre docker-compose plus puissant. Cela fait beaucoup de temps que ce problème est ouvert.

À long terme, il faudrait envisager un véritable regroupement d'options. Certains ne sont pertinents que pour la construction, certains uniquement pour exécuter et certains sont mutuels (vous voulez vraiment une couche d'imbrication au moins pour l'exécution ou simplement se séparer et avoir une section de construction, problème résolu). Actuellement, bien que beaucoup de choses posent problème dans la configuration, je suis tout à fait pour tout refaire dans la version 5, mais bien faire les choses à ce moment-là (principalement en représentant le réel sur un domaine de niveau technique plutôt que d'essayer de le faire mapper un usage basé sur un domaine ou trop simple, créez plutôt une couche de configuration pour ces objectifs en plus du bon, vous ne pouvez pas le faire à l'envers). Je pense qu'en raison de cet état de fait, la solution miracle est justifiée.

+1 pour l'option 2 ou 4

S'il n'est pas prévu d'ajouter cette fonctionnalité actuellement, je souhaite que la manière d'exécuter ces services (ou tâches) dans une composition soit écrite dans les documents de docker-compose.

Ceci est un ancien thread, et je suis d'accord que docker-compose ne se souciera

Mais j'ajoute aussi couramment un service test , alors voici ce que j'ai fait:

1. Remplacez le entrypoint du service.

2. Dans le nouveau entrypoint , vérifiez s'il y a un tty disponible ( docker-compose run utilise --tty par défaut alors que up ne le fait pas).

   # Check if there is a tty
   if [ ! -t 1 ] ; then
     echo "No tty available."
     exit 0
   fi
   

   Cela fera toujours quitter le service lorsqu'il est exécuté sans tty (avec docker-compose up , par exemple) tout en s'exécutant comme prévu avec docker-compose run

@paulodiovani Cela ressemble plus à un hack qu'à une solution.

+1 pour une demande de fonctionnalité.
des hacks comme avoir des commandes qui ne font rien signifie que même si le conteneur ne fonctionne pas, il doit encore être construit, initialisé etc.

J'ai résolu cela dans mon projet en fournissant un script bash simple qui appelle la commande docker-compose appropriée en fonction des arguments fournis.

Maintenant, si je fais ./docker-compose.sh -e testing up , le résultat est le même que si je faisais docker-compose -f docker-compose.yml -f docker-compose.testing.yml up .
Si je fais juste ./docker-compose.sh up , j'obtiens, comme vous vous en doutez, des docker-compose up réguliers.

Par conséquent, mon option -e ${environment} (un raccourci pour --env ) est fondamentalement un alias de -f docker-compose.yml -f docker.compose.${environment}.yml . Il en résulte que docker-compose.yml est le fichier de composition de base / par défaut et des fichiers comme docker-compose.testing.yml sont ses extensions.

Cela résout quelque peu le problème de @acran de l'utilisateur ne sachant pas quels fichiers inclure (et dans quel ordre) à la commande docker-compose en appliquant des valeurs par défaut saines. Ce n'est pas une solution très robuste car certains peuvent utiliser des combinaisons de fichiers de composition plus complexes, mais je pense que docker-compose devrait être capable de faire quelque chose de similaire. La plupart des fichiers docker-compose sont susceptibles de commencer par docker-compose. et de finir par .yml toute façon, alors pourquoi dois-je toujours taper une commande aussi longue ( docker-compose -f docker-compose.yml -f docker-compose.testing.yml up ) si j'ai juste besoin d'un seul service supplémentaire pour mon environnement de test?

Pas besoin d'envsubst, la configuration docker-compose fait les variables d'environnement, puis docker stack le prend à partir de stdin:

docker-compose config | docker stack deploy --prune --compose-file -

Utilisons également les substitutions .env docker-compose.

@kogli Je pense que le problème ici est de choisir une option. Tous ont des avantages et des inconvénients. Comme je le disais avant:

Chaque solution sera meilleure pour certains cas d'utilisation, et pire (voire inutile) pour d'autres. Si le quelque chose est mis en œuvre, ce dernier le maintient pour toujours, donc je pense qu'il est sage de prendre son temps avec lui.

@ shin- Je suppose que vous êtes le seul à demander: est-il même logique d'envisager cela? Compte tenu de la position actuelle de l'équipe, de la difficulté de la concevoir et des nombreux outils disponibles, ne serait-il pas plus facile de dire simplement aux gens que cela n'arrivera pas? La plupart des gens, sinon tous ceux qui ont commenté ici, ont trouvé un moyen de le gérer.

Clôturer cela semble plutôt bien, en plus vous pouvez vous concentrer sur les choses qui comptent, et personne ne se demande s'il doit faire une pull request et comment répondre à tous ces besoins en même temps. Ils peuvent simplement aller construire quelque chose d'autre, et peut-être même le publier pour aider les autres.

Juste pour mémoire : ma solution n'était pas parfaite, mais bien meilleure que les 2 jours qu'il m'a fallu pour installer les dépendances et réparer une foule de choses et faire fonctionner le projet (et il utilisait déjà Docker). Seulement 3 commandes, avec Docker et Docker Compose comme seules dépendances. Oui, il y avait plus de code que je ne voulais. Oui, il y a un ordre de merde pour exécuter des commandes. Et oui, il y a un petit peu plus à garder à l'esprit. Une page Wiki a couvert ces derniers. Bien, si je le dis moi-même, ce qui signifie que Docker Compose a fait son travail , j'avais juste besoin d'autre chose .

Le fait est que si c'est hors de portée, c'est une perte de temps de continuer à en discuter. Beaucoup de gens s'arrêtent ici pour poser des questions à ce sujet et donner leur avis, avant d'essayer de décider quoi faire. Ils trouveront ou construiront toujours quelque chose d'autre si celui-ci est fermé, juste plus rapidement. Et vous obtenez un fil de moins pour garder les enfants.

" question ", juste une idée.

Je ne vois aucune raison d'encombrer la liste des problèmes, je pense que de nombreuses idées ici sont bonnes, mais je pense qu'elles appartiennent ailleurs, pour le meilleur ou pour le pire. Cela fait presque 3 ans, et si la situation change un jour, vous pouvez toujours le rouvrir ou ouvrir un nouveau numéro à ce sujet.

Cette fonctionnalité prend environ une journée à mettre en œuvre car elle est vraiment simple. Cependant, après 2 ans de discussions, toujours rien. Triste.

@rubycut Ouais, c'est ce qui se passe lorsque les soi-disant «principes supérieurs» prennent le relais de la convivialité et de la convivialité. Je comprends parfaitement que les développeurs ne veulent pas obstruer le produit avec des fonctionnalités illogiques. Cependant, cette fonctionnalité particulièrement demandée semble en fait logique. C'est triste quand les développeurs pensent qu'ils savent mieux que leurs utilisateurs. (Encore une fois, ils le font généralement. Mais pas toujours. Pas cette fois.)

@rubycut Talk est bon marché, montrez-moi le code. Si vous pouvez, envoyez votre PR, si vous ne pouvez pas, signalez-le et attendez.

@wangwenpei Vous vous

Juste pour info, "le code" est déjà là: # 3047

@wangwenpei bien, # 3047, il y a la pull request ...
en attente d'avoir au moins quelques retours à ce sujet depuis plus de deux ans maintenant. Il a été fermé récemment

pour les raisons mises en évidence dans https://github.com/docker/compose/issues/1896#issuecomment -322285976

ce qui me met assez en colère pour être honnête car les arguments donnés dans https://github.com/docker/compose/issues/1896#issuecomment -322285976 ne sont en aucun cas liés à la pull request:

1. Qu'est-ce qu'un service? De par sa conception, un service est un processus de longue durée clairement défini qui interagit avec d'autres services pour former une application. C'est l'hypothèse de base sur laquelle Compose fonctionne et guide notre conception pour la plupart, sinon toutes les fonctionnalités que nous implémentons.
2. Selon cette définition, un "service qui n'est pas démarré par défaut" n'est pas vraiment un service [1] - il s'agit plus d'une tâche prédéfinie, exécutée dans un conteneur et agissant sur l'application, plutôt que d'en faire partie.

Je ne vois pas l'assertion By that definition, a "service that is not started by default" is not really a service vraie. Un service qui n'est pas démarré par défaut est juste un service qui n'est pas démarré par défaut, rien de plus, rien de moins à ce stade. Être démarré par défaut ou non ne dit rien sur le fait que le service soit de longue durée ou non, qu'il fasse partie de l'application ou non, cela dit seulement que cela ne doit pas être démarré par défaut.

Et c'est aussi exactement ce que fait le changement dans la pull request: ajouter la possibilité de marquer un service à démarrer par défaut ou non.
Il n'est pas nécessaire d'introduire un nouveau concept tel que des tâches pour ce faire. En fait, tous les autres arguments de https://github.com/docker/compose/issues/1896#issuecomment -322285976 découlent de la fausse prémisse de 2. et ne sont donc pas applicables à la pull request qui n'essaye pas de faire quoi que ce soit autre.

Juste pour être complet:

[1] Certaines personnes mentionnent vouloir avoir des "services optionnels", mais ce n'est pas le cas d'utilisation le plus courant mentionné dans ce fil. La plupart des gens veulent la fonction «tâche», pour autant que je sache.

Oui, il y avait des exemples de tâches ponctuelles, mais il y avait aussi des exemples de services _real_ selon votre définition, c'est-à-dire des cas d'utilisation légitimes de cette fonctionnalité.
Être capable de l'utiliser pour _aussi_ exécuter des tâches ponctuelles, je ne peux pas vraiment accepter comme argument valable contre cela. Il est déjà possible de définir un _service_ qui ne dure pas longtemps, n'expose aucun port et n'est pas une partie essentielle de l'application dans un docker-compose.yml totalement valide.

En fait, c'est également l'une des solutions de contournement suggérées! Divisez simplement les _tâches_ en un docker-compose.yml séparé.
Les autres solutions de contournement mentionnées sont d'utiliser vos propres scripts faits maison (dépendants de la plate-forme), ce qui contredit totalement l'objectif auto-déclaré de docker-compose, voir mon commentaire ci -

Le seul vrai argument soulevé contre l'implémentation la plus basique de l'option 2 - c'est-à-dire avoir _une manière_ de dire à docker-compose de ne pas démarrer un service particulier par défaut, et rien de plus, pas de nouveaux concepts ou quoi que ce soit - est que cela pourrait be_somehow_ être mal utilisé par _some_ utilisateurs.
Mais cet argument est assez faible par rapport à la demande et aux cas d'utilisation légitimes évoqués ici ...

@tibia-

mais aussi parce que nous [3] n'avons tout simplement pas le temps ou les ressources pour implémenter ou maintenir ce que cette fonctionnalité devrait devenir pour être vraiment utile aux gens.
[3] Et à ce stade, je veux dire "je", car je suis le seul mainteneur à travailler activement sur docker-compose en ce moment.

D'une part, souligner qu'il n'y a qu'un seul mainteneur actif tout en ignorant simplement les pull requests et donc gaspiller toute opportunité d'impliquer d'autres développeurs dans le projet n'est pas quelque chose que je pourrais comprendre.
Les changements de code fournis dans # 3047 implémentent déjà _do_ une fonctionnalité qui serait _ vraiment utile à [beaucoup] de personnes_ - peut-être pas _toutes_ les personnes avec _tous_ leurs_ cas d'utilisation, mais la plupart des gens ici.

Toutes les exigences supplémentaires - devoir introduire des concepts complètement nouveaux, une nouvelle gestion des dépendances, jusqu'à une complexité semblable à cmake - découlent simplement d'une fausse prémisse!

Je suis tombé sur ce problème il y a quelques jours à peine, car je cherchais une fonctionnalité comme celle-ci.

Comme il n'est malheureusement pas implémenté, et d'après ce que j'ai pu comprendre, l'alternative officiellement prise en charge est d'utiliser plusieurs fichiers yaml.

Eh bien, je trouve que l'idée d'utiliser plusieurs fichiers yaml pour les services non exécutés par défaut est une mauvaise alternative par rapport à l'utilisation d'un fichier yaml pour tous les services contenant un paramètre supplémentaire pour chaque service non exécuté par défaut.

Alors, voici mon +1.