Quel est le cas d'utilisation? La plupart des utilisations suggérées que j'ai vues étaient des anti-modèles.

Vous pouvez voir certains des nombreux cas d'utilisation en cliquant sur le lien fourni. Comme vous pouvez le voir, de nombreux abonnés la considèrent comme une fonctionnalité vraiment utile au lieu de "antipattern"

Oups, maintenant je vois "quelque chose" est arrivé au numéro 2105 car il n'y a plus de commentaires du tout ...
Peut-être ai-je fourni un mauvais lien ...

donc, je trouve vraiment utile de copier certains fichiers de configuration / initialisation dans un conteneur. Par exemple, des trucs * .sql pour les conteneurs db, du contenu html / js / css pour les conteneurs apache / nginx ou même un fichier jar pour le conteneur java. Cela le rendra disponible / exécutable "globalement" non seulement sur la machine où il a été composé comme dans le cas de volume (s) de montage. Il s'agira principalement d'une combinaison de fichiers locaux de l'hôte et contenus dans le conteneur. En fait, tout conteneur peut être considéré comme inutile sans aucune configuration ni initialisation

c'est le lien correct: https://github.com/docker/compose/issues/1664

+1

Cela le rendra disponible / exécutable "globalement" non seulement sur la machine où il a été composé comme dans le cas de volume (s) de montage

Le problème avec ceci est qu'il est incroyablement myope (d'où le terme "anti-pattern"), car cela vous obligera à répéter l'opération à chaque fois que les conteneurs seront recréés. Sans parler du fait qu'il évolue très mal (et si vous avez 10 conteneurs? 20? 100?)

La solution réelle à votre problème consiste à inclure ces fichiers nécessaires dans votre build (Dockerfile) et à reconstruire lorsqu'une mise à jour est nécessaire.

bien sûr, s'il est composé de tout le contenu "partagé" dans un conteneur, la mise à l'échelle de 10-20-100 conteneurs serait beaucoup plus facile. Tout ce dont vous avez besoin est de le retirer du référentiel et de monter (oui, dans ce cas, monter) uniquement la configuration spécifique au nœud. Et encore plus, vous n'avez pas besoin d'exécuter docker-compose sur chaque nœud.
Bien sûr, nous pouvons utiliser docker-compose en combinaison avec build: & Dockerfile, mais les choses deviennent un peu plus complexes et la configuration yaml dans docker-compose est beaucoup plus "élégante": o)

Je rencontre un problème où la copie serait utile (au moins en tant que remplacement). Je développe principalement sur mac, donc je ne vois presque jamais de problème avec les commandes exécutées en tant que root dans le conteneur et exportées vers un volume monté. Cependant, l'utilisation récente du même flux de travail sur un CentO a causé des problèmes majeurs car les fichiers appartenant à l'utilisateur root sont ajoutés à l'hôte via le volume monté. Je voudrais dans ces cas être simplement capable de copier les fichiers hôtes dans le conteneur au lieu de les monter.

Le problème connexe: # 1532

mettre à jour

Je pense que dans mon cas, je peux m'en tirer en utilisant COPY dans le Dockerfile et en ayant plusieurs fichiers docker-compose dont l'un utilise un montage de volume.

Cas d'utilisation:
Je veux utiliser le répertoire du système de fichiers en lecture seule à l'intérieur du conteneur. L'application crée de nouveaux fichiers dans ce répertoire, mais comme le système de fichiers est en lecture seule, cela provoque des erreurs.

Je ne peux pas utiliser le volume rw, car le système de fichiers est en lecture seule.
Je ne peux pas utiliser le volume ro, car l'effet sera le même.

Ce serait génial de faire des écritures qui ne persistent que lorsque le conteneur s'exécute. Je peux créer un wrapper (https://stackoverflow.com/questions/36362233/can-a-dockerfile-extend-another-one) uniquement COPY fichiers volume , ce serait mieux

Cas d'utilisation: démarrer simultanément plusieurs conteneurs docker à partir de .gitlab-ci.yml qui doivent écrire dans le répertoire du référentiel git.

Si le processus à l'intérieur d'un conteneur échoue ou si le travail ci est annulé avant que le conteneur ne soit nettoyé après lui-même, les fichiers restants ne peuvent pas être supprimés par gitlab-runner en raison d'un manque d'autorisations. Maintenant, je pourrais copier les fichiers du conteneur hors du volume dans un autre répertoire, mais ce serait un anti-modèle, n'est-ce pas?

Est-ce différent de volumes: - ./folder_on_host/ :/folder_in_container/ ?
Je suis capable de copier des fichiers de l'hôte vers le conteneur (équivalent de COPY) de cette façon dans mon fichier de composition

@harpratap vous avez raison, mais l'inconvénient est que / folder_in_container ne doit pas exister ou doit être vide sinon il sera écrasé. Si vous avez un script bash comme point d'entrée, vous pouvez contourner cela en liant symboliquement vos fichiers dans le répertoire initialement prévu après avoir créé un volume à / some_empty_location

+1 pour avoir une fonctionnalité COPY. Notre cas d'utilisation est la mise en place rapide d'environnements de développement locaux et la copie dans les configurations pour les paramètres de développement.

+1 pour COPY. Ce serait vraiment une fonctionnalité utile.

Cas d'utilisation: en mode swarm, j'ai un service utilisant l'image mysql. J'ai besoin de copier mon script d'initialisation dans /docker-entrypoint-initdb.d/ afin que MySQL puisse les exécuter.

Bien qu'il soit possible de créer une image au-dessus de mysql, copiez les fichiers et utilisez-le ou connectez-vous au mysql
tâche en essaim, puis exécutez manuellement les scripts, c'est un peu inutile à mon avis.

+1 pour COPY / ADD,

Cas d'utilisation:
Fluentd nécessite que les fichiers de configuration soient déplacés dans le conteneur pendant l'exécution. Ces fichiers de configuration sont créés lors de l'exécution par notre moteur Jenkins et sans COPY / ADD dans le docker, la composition échoue tout simplement.

+1 pour COPY

Supposons que l'on ait un fichier de configuration partagé sur un certain nombre de machines docker, avec leurs fichiers Docker dans les sous-répertoires respectifs sous le répertoire docker-compose. Comment copiez-vous cette configuration partagée dans chaque image? Je ne peux pas créer un lien symbolique vers ../ depuis le contexte Dockerfile sans obtenir COPY failed: Forbidden path outside the build context

Dans ce cas, lors de l'exécution de la construction de docker-compose, j'aimerais copier les fichiers de configuration du contexte docker-compose avant d'exécuter les étapes de construction de docker.

Je suis heureux si quelqu'un peut suggérer une solution de contournement propre bien sûr.

Ce serait bien d'avoir une fonctionnalité !!

Veuillez ne pas commenter avec seulement +1 - c'est une perte de temps pour tout le monde. Si vous avez des informations supplémentaires à fournir, veuillez le faire; sinon, ajoutez simplement un pouce vers le haut au problème d'origine.

A quoi sert d'insister dogmatiquement sur le fait qu'il est anti-modèle, simplement parce que dans _ certains_ cas, cela pourrait éventuellement causer des problèmes? Cela a certainement une bonne utilité car vous pouvez ajouter une ligne à un fichier existant, au lieu d'avoir à créer un dossier et un fichier supplémentaires, puis de déplacer le fichier à y ajouter. Cette création inutile et bureaucratique de petits fichiers est le véritable anti-modèle, empêchant les utilisateurs de créer des fichiers docker-compose simples et faciles à entretenir.

Si les utilisateurs veulent faire des choses nuisibles avec Docker, ils trouveront un moyen, peu importe ce que vous faites. Refuser d'ajouter des fonctionnalités légitimes simplement parce que quelqu'un pourrait en abuser un jour est insensé.

Je pense que ce que vous faites est en fait la bonne façon de procéder, dans ce cas.

Le problème ici qui a été soulevé était plutôt du type, supposons que le fichier mongo.conf soit partagé entre trois images docker qui sont orchestrées par un fichier docker-compose. Comment vous assurez-vous qu'il est identique dans chaque sous-répertoire de construction de docker?

Si vous utilisez des liens symboliques par exemple, docker se plaint que le fichier est externe à l'environnement de construction, par exemple, la construction de docker manque d'un sens de reproductibilité car des modifications en dehors de ce répertoire pourraient altérer la construction.

Donc, la seule façon d'orchestrer cela est avec une copie de fichier, ce qu'il faut actuellement faire avec un Makefile ou un script shell avant d'exécuter docker-compose, donc cela semblait être une idée de discuter si c'était une fonctionnalité que docker-compose pourrait faire, car c'est sûrement un cas d'utilisation courant.

Le problème que vous soulevez semble être davantage lié à l'injection à l'exécution (au lancement) d'une modification de fichier local.

Je pense que vous êtes vraiment très bien dans ce que vous faites, ce que vous avez dit ci-dessus est juste comment cela se fait. Une image docker peut toujours être construite pour accepter des variables d'environnement pour répondre à des questions telles que où se trouve le répertoire de configuration, et ce répertoire de configuration peut être "injecté" à l'aide d'un volume au moment de l'exécution - mais cela dépend de la conception de l'image du docker, en tirant parti variables d'environnement et mappages de volume (qui sont des fonctionnalités prises en charge par docker en tant que modification de la configuration d'exécution.)

J'espère que je n'ai pas mal interprété votre commentaire et que ma réponse est utile.

@jpz - J'ai en quelque sorte supprimé mon commentaire original - yikes - désolé! Merci - oui, c'est utile.

Mon commentaire initial allait dans le sens de:

Mon cas d'utilisation est que je souhaite déclarer un service en utilisant mongo sans avoir à créer ma propre image personnalisée juste pour copier un fichier de configuration comme /etc/mongod.conf .

MISE À JOUR: j'ai utilisé volumes . Il y a un an ou deux - je pensais avoir essayé cela avec une mauvaise expérience ... mais cela semble bien.

+1 pour COPY

J'ai créé un bref résumé pour cela. Cela suppose que le service de composition de docker est nommé phpfpm , mais vous pouvez le changer comme vous le souhaitez. n'hésitez pas à modifier.
https://gist.github.com/markoshust/15efb29aa5eebf8adae402af18b2e674

Bonjour, je voudrais savoir comment est la progression de ce numéro. Maintenant, j'utilise Windows 10 Home avec docker-toolbox. Cela semble principalement une erreur lorsque j'essaye de bnd le fichier de montage en tant que volume dans un conteneur. Ce serait bien d'avoir des capacités de copie dans docker-compose

COPY / ADD serait certainement une fonctionnalité bienvenue.

Un cas d'utilisation: exécuter une instance Graylog dans Docker à des fins de développement. Pour lancer automatiquement une entrée, une spécification JSON doit être placée dans / usr / share / graylog / data / contentpacks
Avec la fonction COPY / ADD, ce sera aussi simple qu'une seule ligne dans YML.

Pour le faire fonctionner maintenant (le 16 octobre 2018), vous devez monter un volume à ce point ET copier le contenu d'origine de ce dossier sur le volume persistant. Ce qui est peu pratique.

J'en profiterais, j'ai un ensemble d'outils qui importent une graine de base de données dans un conteneur, puis j'exécute l'importateur de base de données devtools basé sur ce fichier. Je ne veux pas avoir à faire:

docker cp "${seed_file}" $(docker-compose ps -q devtools):/tmp/seed_file

pour pouvoir importer ma semence. Et non, je ne compilerai pas mes images de développement avec un schéma fixe, cela va à tout le moins à l'encontre du modèle de développement Web. Les conteneurs doivent être destinés à la portabilité des applications, pas aux données.

Il serait beaucoup plus logique de faire:

docker-compose cp "${seed_file}" devtools:/tmp/seed_file

Dans l'ensemble, c'est juste un raccourci qui fait fondamentalement la même chose, mais il semble préférable de tirer parti de docker-compose partout que de mélanger des choses ...

1) cela semble être un double de # 3593
2) Je suis d'accord avec @ shin- que les cas d'utilisation élaborés suivent un anti-modèle
3) mais encapsuler la commande cp Docker est logique, imo

@funkyfuture Si vous pensez que ces cas d'utilisation suivent un

Qu'en est-il de la "section de données" de type k8s ?
Par exemple:

services:
  service1:
    image: image.name
    data:
      filename1.ini: |
        [foo]
        var1=val1
        [bar]
        var2=val2
      filename2.yml: |
        foo:
          bar: val1

ou peut-être la même chose mais pour la section volumes:

volumes:
  service_config:
    data:
      filename1.ini: |
        [foo]
        var1=val1
        [bar]
        var2=val2

services:
  service1:
    image: image.name
    volumes:
      - service_config:/service/config

@tibia-

Le problème avec ceci est qu'il est incroyablement myope (d'où le terme "anti-pattern"), car cela vous obligera à répéter l'opération à chaque fois que les conteneurs seront recréés. Sans parler du fait qu'il évolue très mal (et si vous avez 10 conteneurs? 20? 100?)

Le problème réel ici est que certaines personnes sont trop rapides pour dissiper les fonctionnalités demandées car cela entre en conflit avec leur vision limitée des scénarios d'utilisation réels.

Ici, je cherche un moyen de copier mon fichier de configuration dans un conteneur que je viens de recevoir de dockerhub. Je n'ai pas accès au Dockerfile d'origine et ce serait très pratique d'avoir cette fonctionnalité (au lieu d'essayer de créer une autre couche par-dessus, ce qui fonctionnerait, mais ce n'est pas pratique, je ne veux pas reconstruire quand je change quelque chose).

Cas d'utilisation:

J'exécute une base de données dans un environnement de test d'intégration et je souhaite que les données soient réinitialisées à chaque itération, lorsque les conteneurs sont démarrés. L'intégration des données dans une image personnalisée fonctionnerait, mais le montage d'un volume est fastidieux, car les données sur l'hôte doivent être réinitialisées.

Nous maintenons les données de manière indépendante et il serait plus pratique d'utiliser simplement l'image de base de données standard - en copiant les données dessus avant qu'elle ne commence à s'exécuter. Actuellement, cela ne semble pas possible avec docker-compose.

J'ai un cas d'utilisation en tête. Je souhaite baser mon image à partir d'une image standard, telle qu'un serveur Apache générique. Je souhaite copier mon html lors de la création de l'image. De cette façon, je peux mettre à jour mon image de base à tout moment et la directive de copie garantira que mon contenu est inclus dans la nouvelle image.

BTW J'utilise actuellement dockerfiles et une directive de construction dans mon docker-compose.yaml pour ce faire. Ce serait bien si je n'avais pas besoin des fichiers docker.

@tvedtorama -

Cas d'utilisation:

J'exécute une base de données dans un environnement de test d'intégration et je souhaite que les données soient réinitialisées à chaque itération, lorsque les conteneurs sont démarrés. L'intégration des données dans une image personnalisée fonctionnerait, mais le montage d'un volume est fastidieux, car les données sur l'hôte doivent être réinitialisées.

Nous maintenons les données de manière indépendante et il serait plus pratique d'utiliser simplement l'image de base de données standard - en copiant les données dessus avant qu'elle ne commence à s'exécuter. Actuellement, cela ne semble pas possible avec docker-compose.

Ce problème traite du désir de copier des fichiers au moment de la création de l'image, pas au moment de l'exécution. Je suggérerais de soulever un billet séparé pour discuter du bien-fondé de cela? Cela peut confondre cette discussion pour digresser dans la discussion de l'injection de fichier d'exécution (dont j'interprète ce dont vous parlez.)

@ c0ze -

Qu'en est-il de la "section de données" de type k8s ?
Par exemple:

...

Je ne suis pas totalement au courant de ce que fait cette configuration, mais oui, cela semble être une solution. Fondamentalement, lorsque vous avez des secrets (par exemple, quel est le nom d'utilisateur / pwd / port de connexion à la base de données), comment puis-je l'injecter dans mes images docker - clients et serveurs - sans écrire une charge de code?

Quelque chose comme la section de données kubernetes pourrait fonctionner - car ce serait une source unique de vérité. Sinon, on peut constater qu'ils ont les mêmes secrets maintenus plusieurs fois sur plusieurs images docker.

Il existe également un état de la technique qui aide à faire avancer la conversation pour déterminer si c'est réellement une bonne idée qui vaut la peine d'être adoptée ou non.

Pour moi, tout a commencé par vouloir partager un fichier de configuration invariant entre les conteneurs, et en réalisant qu'il n'y avait aucun moyen de le faire sans script externe pour docker-compose, et en écrivant la configuration à partir d'une seule source de vérité dans chacun des les dossiers Docker sous le dossier docker-compose. Bien sûr, j'obtiens l'argument d'immutabilité pour Docker (par exemple, le répertoire Dockerfile décrit complètement et complètement comment créer l'image), donc demander à l'automatisation de copier des éléments dans ce répertoire semble aller légèrement à l'encontre de ces principes.

Je suppose que la discussion est de savoir à quel point docker-compose peut-il être intrusif? Est-ce un cas d'utilisation assez courant pour justifier une telle automatisation? Si ce n'est pas le cas, alors nous semblons alourdir les mécanismes de passage des variables d'environnement avec la responsabilité d'injecter des secrets de l'extérieur à partir d'une seule source de vérité, tardivement (par exemple au moment de l'exécution). J'espère que mes points sont suffisamment cohérents ici.

Ce n'est pas très important pour moi, mais je pense que le cas d'utilisation vaut la peine d'être discuté.

Cela me serait extrêmement utile. Au travail, le logiciel antivirus bloque la possibilité pour Windows 10 de partager des volumes avec des conteneurs. C'est une organisation énorme et il est inutile de les amener à changer en raison d'une politique définie sur un autre continent.

Bonjour, mon cas d'utilisation: j'utilise la configuration open source de docker-compose Prometheus (le dépôt est maintenu par d'autres personnes). Il a des configurations qui sont montées dans des conteneurs. PROBLÈME: Je ne peux pas faire de docker-composer sur une machine distante (comme aws docker-machine ou à l'intérieur de CI / CD runner) car il ne peut pas monter les configurations correctement. Dans ce cas, j'aimerais les copier / les intégrer. Pour les données RW, il y a des volumes, pour RO -?

L'autre option est d'avoir des volumes RO avec possibilité de définir les données initiales.

Solution actuelle: connectez-vous à l'hôte docker via ssh, clonez / mettez à jour le repo et exécutez docker-compose up. Cela fonctionne pour le cas manuel, mais c'est pénible pour l'automatisation :(

+1

Cas d'utilisation: j'ai une machine docker de développement qui exécute une base de données et chaque fois que je la configure, j'ai besoin d'un vidage récent de la base de données à installer. En fait, cela signifie:

1. Extrayez l'image du docker de la base de données de l'externe.
2. Copiez et extrayez le ZIP dans l'image en cours d'exécution.
3. Exécutez db-restore dans le volume.
4. Supprimer le vidage de la base de données.

Maintenant, le gros problème est que l'étape 2 sera toujours différente pour chaque développeur, car il existe de nombreuses versions de vidage différentes de cette base de données, le plus simple serait donc que chaque développeur ait son propre fichier de composition avec son emplacement / version de vidage spécifique, puis demandez à docker d'assembler l'image avec cet emplacement de fichier spécifique lors de la composition, qui peut ensuite être modifiée à la volée lorsqu'une version différente est requise.

Mon cas d'utilisation est simple. Je ne veux pas de volumes et je ne veux pas rouler ma propre image. Je veux juste mettre une simple copie défensive d'un fichier de configuration dans un conteneur après sa création et avant son démarrage.

est-ce toujours un problème?
J'ai une application django avec un très long fichier de paramètres. Pour moi, il serait bien plus facile de créer une image docker et de copier un seul fichier de configuration dans chaque conteneur.
Passer tous les réglages comme ENV est pour moi l'anti-modèle. Prend beaucoup de code, est difficile à maintenir et peut être résolu avec une seule commande de copie.

J'ai ouvert le # 6643 et j'aimerais avoir des commentaires sur la façon dont cela serait considéré comme un anti-pattern. Surtout, dans un environnement où de nombreux fichiers de configuration pourraient avoir besoin d'être ajoutés / modifiés à la volée.

@tibia-

Le problème avec ceci est qu'il est incroyablement myope (d'où le terme "anti-pattern"), car cela vous obligera à répéter l'opération à chaque fois que les conteneurs seront recréés. Sans parler du fait qu'il évolue très mal (et si vous avez 10 conteneurs? 20? 100?)

Comment fonctionne docker-compose exec avec plusieurs conteneurs?

    --index=index     index of the container if there are multiple
                      instances of a service [default: 1]

Ne devrions-nous pas essayer d'obtenir le même comportement avec cp ?

IMHO exec est autant éphémère que le serait cp . Mais je considère toujours que c'est des commandes de "développement" de toute façon, les environnements de développement doivent être éphémères, n'est-ce pas?

Je n'avais pas vu le commentaire sur beaucoup de développeurs ici disant qu'ils sont myopes en essayant trop rapidement de résoudre ce problème en demandant cette fonctionnalité. Je pense que c'est un peu dur et condescendant. S'il y a une chose que j'ai apprise de mes années de développement, c'est la suivante:

Ce n'est pas ce que fait votre logiciel, c'est ce que l'utilisateur en fait qui compte

Évidemment, je comprends que vous avez un rôle à jouer pour empêcher les choses de devenir folles, mais ce n'est pas parce que quelqu'un utilise un outil incorrectement basé sur votre vision que tout le monde commencera à le faire de cette façon et que tout l'enfer se déchaînera.

Tous les cas particuliers que j'ai vus ici sont très appropriés la plupart du temps. Et, la plupart de ces cas spéciaux ne devraient pas et ne se produiraient pas sur le système de production, ils sont, par exemple, comme mon cas que j'ai expliqué il y a quelque temps, pour personnaliser un environnement de développement et exécuter des fichiers spéciaux dans un conteneur qui ne peut pas utiliser un mappage de volume. La plupart des exemples indiquent clairement qu'ils ne veulent pas cuire dans des schémas, des données ou des fichiers de configuration et ne peuvent pas utiliser le mappage de volume, donc je ne vois pas pourquoi c'est tellement un inconvénient que d'utiliser le terme «à courte vue».

Je pense que vous devriez peser soigneusement vos mots lorsque vous dites des choses comme ça ...

1. Je n'ai vraiment pas besoin d'une conférence sur ce que j'ai le droit de dire ou d'écrire. Je suis désolé que "myope" vous offense. Il est toujours exact de dire que ces éléments appartiennent au Dockerfile par conception.
2. Je ne suis plus un mainteneur. S'il vous plaît, arrêtez de me parler de choses sur lesquelles je n'ai plus aucun contrôle.

1. Je dois dire que je suis du côté de crazycodr ici ... Rejeter des cas d'utilisation parfaitement valables du monde réel comme "anti-pattern", sans donner d'alternatives pratiques et réalistes utiles est une approche peu amicale des développeurs, et très honnêtement même un peu impolie.
2. Mainteneur ou non, si vous avez participé à la partie discussion de github, vous devez essentiellement vivre avec des gens qui commentent vos commentaires. C'est comme ça que ça marche. Faites avec...

Ramenons-le. Question technique honnête ici. Avec docker stack, nous avons une option "configs". C'est une fonctionnalité native de docker mais c'est pour les services, pas les conteneurs. Quelle est la viabilité de faire fonctionner quelque chose comme ça au niveau du conteneur plutôt qu'au niveau du service? Comment docker stack implémente-t-il l'approvisionnement de la configuration? Cette implémentation peut-elle être répliquée spécifiquement pour docker-compose?

Au moins la moitié des cas d'utilisation mentionnés ici concernent les configurations, donc beaucoup de gens seraient satisfaits si seulement cette démangeaison était rayée.

Un autre cas d'utilisation simple est des choses comme la validation de domaine googles. Si vous utilisez l'image wordpress, vous ne pouvez pas ajouter un fichier que Google vérifiera. Vous devez créer une toute nouvelle image pour le faire.

Aussi ces commentaires disant que les choses sont "anti-schémas" n'ont guère de sens, sentent l'élitisme.

EDIT: yikes, lisez plus, Dieu merci, il n'est plus le mainteneur

Donc, vous me dites que si je veux copier un petit fichier de configuration dans une image prédéfinie (par exemple, nginx ou mariadb ), je dois maintenant gérer ma propre configuration de construction d'image et la dupliquer l'espace disque utilisé (image d'origine et image configurée)?

Cela devrait être une caractéristique.

dupliquer l'espace disque utilisé

vous n'êtes pas lorsque vous utilisez Docker.

J'aime la façon dont vous tirez sur une chose de ce qu'il a dit, qui est la chose la plus mineure dans tout cela. Cela devrait être une fonctionnalité. Ce problème ne fera que croître et se développer à cause des gens qui arrivent ici à mesure que docker se développe, car c'est un cas d'utilisation courant et les gens s'attendront simplement à ce qu'il existe à cause du bon sens, ce que les responsables actuels et actuels semblent manquer.

J'aime la façon dont vous tirez sur une chose de ce qu'il a dit, qui est la chose la plus mineure dans tout cela.

un argument non valide doit être noté comme tel.

Je pense que la chose ici est que l'argument "anti-pattern" peut être valide étant donné une certaine stratégie commerciale (voir le point @washtubs ). nous pouvons ne pas être d'accord avec cette stratégie, mais cela ne justifie pas d'attaques personnelles. à la fin, ce sont les efforts passés de @ shin- avec docker-py qui vous permettraient d'implémenter une alternative à docker-compose .

Quel argument "anti-pattern"? Il n'y a aucun argument avancé. C'est juste un "non, car anti-pattern" sans aucune logique derrière, juste le dire sans rien de sauvegarder. C'est comme si les gens disaient qu'ils pensaient au pire scénario sur leur tête, décidaient que ce scénario était un anti-modèle, puis rejetaient tout comme tel sans même écrire sur leur soi-disant scénario anti-modèle.

C'est juste de l'élitisme. De nombreux commentaires ici ont porté sur le ridicule du raisonnement pour ne pas l'ajouter et ils sont tous ignorés.

Le bon sens et la logique se moquent de vos sentiments ou de votre élitisme. Ou vos anti-modèles inventés.

Ouais, @robclancy , s'il vous plaît, gardez-le civil FFS. Je veux cette fonctionnalité, mais si tout ce que vous voulez faire est de parler de la merde aux responsables, allez-y sur reddit s'il vous plaît. La correction antérieure de @funkyfuture est entièrement justifiée.

En fin de compte, ce sont les efforts passés de @ shin- avec docker-py qui vous permettraient d'implémenter une alternative à docker-compose.

Je ne veux évidemment pas un fork de docker-compose, si c'est ce que vous suggérez, en particulier pour une amélioration aussi infime. C'est la seule autre façon dont cela se produira, et ce serait mauvais pour la communauté.

Si quelqu'un soumettait un PR, serait-il réellement considéré? Ou est-ce quelque chose que l'équipe de docker-compose vient de décider fermement de ne pas accepter? Est-ce que quelque chose comme l'ajout d'une section de configuration compatible avec les configurations de pile de docker serait quelque chose que vous envisageriez?

Cela a déraillé ... «anti-pattern» sans explication transforme «anti-pattern» en une définition très large contre laquelle il est impossible d'argumenter. Il n'y a pas non plus de direction claire sur le côté de «l'anti-motif»; docker ou docker-compose.

Une définition claire des réponses anti-pattern serait fantastique et très appréciée.

La communauté va continuer de croître, donc un ensemble établi de définitions doit exister.

Je veux l'utiliser pour copier des artefacts générés par un pipeline jenkins s'exécutant sur une pile de composition docker. Et puis, le nom du conteneur peut être aléatoire, donc je ne peux pas utiliser docker cp .

Aujourd'hui je dois utiliser

docker cp $(docker-compose -f docker-compose.development.ci.yml ps -q test):/app/tests_output ./tests_output

Est-ce différent de volumes: - ./folder_on_host/ :/folder_in_container/ ?
Je suis capable de copier des fichiers de l'hôte vers le conteneur (équivalent de COPY) de cette façon dans mon fichier de composition

J'essaye de faire de même. J'ai un dossier avec un fichier csv et je voudrais le fournir à logstash.
Comment puis je faire ça. ou quel dossier dans le conteneur?
pour le moment, j'ai quelque chose comme ça:
./path/to/storage:/usr/share/logstash/ data: ro

Toute suggestion serait utile

@ shin- Ce billet a maintenant 1,5 ans. Quand 160 personnes vous disent que vous vous trompez, vous avez probablement tort.

De quoi avez-vous besoin d'autre pour vous convaincre que cela devrait être mis en œuvre?

@isapir , les entreprises qui n'écoutent pas leurs clients, ont tendance à se retirer assez tôt. Je suppose donc que nous devrions voir des alternatives de docker prêtes pour la production dans un proche avenir.

@ shin- Ce billet a maintenant 1,5 ans. Quand 160 personnes vous disent que vous vous trompez, vous avez probablement tort.

😆 🤣 💯 🥇 😲 😮

Également,

Je ne suis plus un mainteneur. S'il vous plaît, arrêtez de me parler de choses sur lesquelles je n'ai plus aucun contrôle.

@sfuerte Il existe un petit projet nommé Kubernetes qui a déjà remplacé Docker-Compose. Je me demande si cela se serait produit si l'attitude envers les commentaires des utilisateurs avait été plus positive.

Nous avons besoin d'un mot à la mode pour contrer leurs mots à la mode. C'est tout ce qu'ils peuvent gérer.

Cette fonctionnalité serait totalement pro-pattern . Ça devrait le faire. La différence est que même si j'ai fait cette chose stupide, il y a de nombreux commentaires dans ce numéro qui montrent les avantages de cela d'une manière qui est clairement des cas d'utilisation courants. Et il n'y a pas une seule instance d'un anti-pattern .

@ shin- vous êtes tagué là-dedans parce que vous avez commencé cette merde anti-modèle sans aucun fondement dans la réalité. Alors arrête de pleurer à propos de quelque chose que tu as causé.

k s'amuser

Mon cas est:

• Pendant le "dev", je veux que mon code source soit construit en tant que "volume" pour qu'il se mette à jour automatiquement pendant le développement
• Lorsque l'application est prête à être publiée et que j'ai besoin de «déployer», je souhaite copier les fichiers copiés au lieu d'être des volumes.

Je pense que le moyen le plus simple de résoudre ce problème est d'avoir 1 fichier de composition pour le développement et 1 fichier de composition pour la production.

Le problème ici est que je peux spécifier "volumes" sur le fichier docker, mais je ne peux pas spécifier "copie" sur le fichier docker?

Quelqu'un est-il dans le même cas que moi? Est-ce que je manque quelque chose?

@ shin- est-ce un anti-motif? comment allez-vous résoudre ce problème?

@hems , dans un monde parfait, vous voulez que votre application soit déployée en tant qu'image docker autonome. Donc, si vous écrivez une application, le code source que vous avez l'intention de déployer devrait probablement faire partie de Dockerfile , donc l'image contient toute votre application. Donc dans le Dockerfile , si vous vouliez votre source dans / var / www vous mettriez

COPY my-app-src /var/www

Votre source n'est pas spécifique à l'environnement, elle appartient donc simplement à l'image du docker. Facile.

La plupart d'entre nous souhaitent inclure un fichier de configuration spécifique à l'environnement dans les conteneurs pour qu'une image existante fonctionne correctement avec une configuration de docker-compose particulière. Et nous voulons pouvoir le faire sans créer de volume pour un petit fichier, ni rouler une nouvelle image.

Quelqu'un de l'équipe de docker-compose peut-il s'il vous plaît jeter un coup d'œil sérieux et impartial à cela et tirer un verdict final (espérons-le, un verdict qui ignore toutes les personnes immatures)? Ce numéro est ouvert depuis toujours. Le résultat est important, mais personnellement j'en ai assez de recevoir des notifications.

COPY my-app-src /var/www

c'est ce que je dis, en développement, je veux utiliser mon fichier docker-compose pour monter des VOLUMES dans les images et pendant la production, je veux COPIER des fichiers dans les images, d'où je pense que nous devrions pouvoir COPIER et monter VOLUMES en utilisant le fichier docker-compose, je peux donc avoir 1 fichier de composition pour le développement et 1 pour la version de production.

Je travaille dans l'équipe qui gère Compose et je suis heureux de participer à cette discussion. Pour commencer, je vais décrire comment nous voyons les responsabilités des fichiers Dockerfiles et Compose.

Les fichiers Docker sont la recette pour créer des images et doivent ajouter tous les binaires / autres fichiers dont vous avez besoin pour faire fonctionner votre service. Il y a quelques exceptions à cela: les secrets (c'est-à-dire: les informations d'identification), les configurations (c'est-à-dire les fichiers de configuration) et les données d'état de l'application (par exemple: les données de votre base de données). Notez que les secrets et les configurations sont en lecture seule.

Les fichiers de composition sont utilisés pour décrire comment un ensemble de services est déployé et interagit. Le format Compose est utilisé non seulement pour un seul moteur (ie: docker-compose ) mais aussi pour les environnements orchestrés comme Swarm et Kubernetes. L'objectif du format Compose est de faciliter l'écriture d'une application et de la tester localement, puis de la déployer dans un environnement orchestré avec peu ou pas de modifications. Cet objectif limite ce que nous pouvons changer dans le format en raison de différences fondamentales telles que la façon dont chaque environnement gère les volumes et le stockage des données.

La réduction des responsabilités du fichier Dockerfile et du fichier Compose comme celle-ci nous donne une bonne séparation des préoccupations: que contient chaque image de conteneur (Dockerfile), comment les services sont déployés et interagissent (fichier Compose).

Je vais maintenant passer en revue chacune des exceptions à ce que vous stockez dans une image. Pour les secrets, vous ne voulez pas qu'ils soient cuits dans des images car ils pourraient être volés et parce qu'ils peuvent changer avec le temps. Les secrets Docker sont utilisés pour résoudre ce problème. Celles-ci fonctionnent légèrement différemment selon l'environnement dans lequel vous déployez, mais essentiellement l'idée est que vous pouvez stocker les informations d'identification dans un fichier qui sera monté en lecture seule dans un répertoire tmpfs dans le conteneur au moment de l'exécution. Notez que ce répertoire sera toujours /run/secrets/ et le fichier sera le nom du secret. Les secrets sont pris en charge sur Swarm, moteur uniquement ( docker-compose ) et Kubernetes.

Pour les fichiers de configuration ou les données d'amorçage, il existe Docker Configs . Ceux-ci fonctionnent de la même manière que les secrets mais peuvent être montés n'importe où. Ceux-ci sont pris en charge par Swarm et Kubernetes, mais pas par docker-compose . Je pense que nous devrions ajouter une prise en charge pour ceux-ci et cela aiderait avec certains des cas d'utilisation répertoriés dans ce numéro.

Enfin, il existe des données d'état de l'application qui doivent être stockées en externe. Je ne vais pas m'y plonger car ce n'est pas lié à ce problème.

Avec ce cadrage, je peux répondre à quelques questions:

• Ajoutons-nous un champ copy au format Compose? Non, je ne pense pas que nous le ferons car cela n'a pas de sens dans des environnements orchestrés.
• Allons-nous ajouter configs support à docker-compose ? Oui, je pense que nous devrions.
• Allons-nous ajouter un docker-compose cp ? Peut-être que je ne suis pas encore sûr de cela. Ce serait essentiellement un alias pour un docker container cp .

Compte tenu de cela, il existe quelques outils qui peuvent être utilisés ici:

• Constructions en plusieurs étapes qui vous permettent d'ajouter conditionnellement des fichiers à une image à l'aide de cibles.
• Secrets qui vous permettent de transmettre des informations d'identification à un service lors de l'exécution.
• Configurations qui vous permettent de transmettre des informations de configuration à un service lors de l'exécution.

Je pense que ces outils résolvent tous les problèmes soulevés dans ce fil.

Ce fil est assez échauffé. N'oubliez pas qu'il y a une vraie personne en direct derrière chaque handle de GitHub et qu'ils essaient probablement de faire de leur mieux (même si leur frustration est visible). Nous sommes tous passionnés par Compose et souhaitons que le projet continue de prospérer.

Allons-nous ajouter un docker-compose cp ? Peut-être que je ne suis pas encore sûr de cela.

Je trouverais cela une commodité utile comme docker-compose exec .

@ chris-crone Réponse incroyable, merci!

Je sais que je ne parle pas pour tout le monde , mais j'ai l'impression que le support configs satisfait la grande majorité des intérêts ici. Un numéro sera-t-il ouvert pour cela?

Et merci de proposer des approches alternatives. Je ne connaissais pas les builds en plusieurs étapes jusqu'à présent.

J'ai l'impression que le support configs satisfait la grande majorité des intérêts ici.

j'en doute car je soupçonne que la majorité ici n'utilise pas Swarm et afaik que la fonctionnalité config l'exige.

Oui, actuellement Swarm est requis, mais d'après le commentaire de @ chris-crone ...

Ceux-ci sont pris en charge par Swarm et Kubernetes, mais pas par docker-compose. Je pense que nous devrions ajouter une prise en charge pour ceux-ci et cela aiderait avec certains des cas d'utilisation répertoriés dans ce numéro.

... je lis que cela peut être implémenté dans docker-compose (sans Swarm)

L'objectif du format Compose est de faciliter l'écriture d'une application et de la tester localement, puis de la déployer dans un environnement orchestré avec peu ou pas de modifications.

Dans les applications complexes, nous pouvons avoir pas mal de fichiers de configuration qui doivent être modifiés à la volée. À l'heure actuelle, le moyen le plus efficace (en termes de temps et de coût) de le faire est de remplir la clé des volumes (car aucune personne sensée ne créera une image différente tout en testant plusieurs configurations ... à moins d'avoir un patron qui adore dépenser de l'argent sur les heures de développement).

Swarm et config ne vont pas vraiment répondre à plusieurs des cas d'utilisation répertoriés. La "séparation des préoccupations" n'est pas non plus applicable car compose fait déjà ce que vous pouvez faire dans docker, mais le simplifie. Un wrapper n'est pas une séparation ... nous vous demandons simplement de l'étendre un peu plus ...

https://github.com/docker/compose/issues/6643

Obtenez le piratage avec lui .. étendez la fonctionnalité de volume où chaque fichier sous la nouvelle clé est lié dynamiquement à un volume singulier et mappé à leurs chemins internes respectifs ...

Je pense qu'il y a ici deux scénarios qui sont parfaitement valables, l'un concerne
environnements de développement. Les gens créent des environnements flexibles avec la source
code monté dans leurs images. Le code source évolue au fur et à mesure du développement
se produit et vous ne pouvez pas reconstruire l'image en permanence ou vous gaspillez simplement
énormément de temps. C'est exactement mon scénario et je peux voir que ça
Le scénario s'applique à beaucoup d'autres personnes.

Le second concerne les images de production où vous créez votre code source
(au cas où vous travaillez avec des scripts non compilés) dans votre image (et
puis encore, je ne l'étais pas, je le montais toujours de mon côté) ou toi juste
compilez votre application et copiez-la dans l'image finale. À ce moment,
l'application devient extrêmement portable.

Je pense que tout le monde comprend ça! La question est, faites le docker-compose
dev a pris le temps de lire les cas et de comprendre les besoins? Il y a
pas d'anti-patterns ici en théorie, juste des développeurs qui ont un besoin et aimeraient
être respecté.

Nous aimons docker, docker-compose et tout l'écosystème, nous l'utilisons parce que nous
l'adore et parce que nous l'utilisons, vous avez des emplois (au moins certains d'entre vous sont payés
pour cela j'espère).

Quelque chose que j'ai appris ces dernières années et que j'aime ramener ici et
il y a ce qui suit et cela s'applique très bien à ce scénario:

Ce n'est pas ce que fait votre logiciel qui compte, c'est ce que font vos utilisateurs
avec ça qui compte

Bravo et bonne continuité!
ᐧ

Le jeu.6 juin 2019 à 10:55, jadon1979 [email protected] a écrit:

L'objectif du format Compose est de faciliter l'écriture d'une application
et testez-le localement, puis déployez-le dans un environnement orchestré avec
peu ou pas de changements.

Dans les applications complexes, nous pouvons avoir un certain nombre de fichiers de configuration qui nécessitent
peaufiner à la volée. À l'heure actuelle, le moyen le plus efficace (en termes de temps et de coût)
faire cela est de remplir la clé des volumes (car aucune personne sensée ne va
pour créer une image différente tout en testant plusieurs configurations .. sauf si
ils ont un patron qui adore dépenser de l'argent en heures de développement).

Swarm et config ne vont pas vraiment répondre à plusieurs des cas d'utilisation
répertorié. «Séparation des préoccupations» n'est pas non plus applicable car compose déjà
fait ce que vous pouvez faire dans docker, mais le simplifie. Un wrapper n'est pas
séparation ... nous vous demandons juste de l'étendre un peu plus ...

6643 https://github.com/docker/compose/issues/6643

Obtenez le piratage avec lui .. étendez la fonctionnalité de volume où chaque fichier sous le
la nouvelle clé est liée dynamiquement à un volume singulier et mappée à leur
chemins internes respectifs ...

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=ABBR3OMQH62242SM4QN5Y7TPZEQP7A5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXG63
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABBR3OMOZFZ47L6ITHPF2TDPZEQP7ANCNFSM4EKAVONA
.

Je veux lancer un environnement Tomcat docker pour exécuter mon application à partir d'un .war qui n'est pas nommé ROOT.war . Pour ce faire, je dois le copier dans le répertoire webapps de Tomcat et le renommer en ROOT afin qu'il fonctionne sur les ports actuellement liés 8005/9. Tout le reste échoue en raison de problèmes de reliure sur les ports avec des erreurs sur «l'accès illégal». Ce sont des versions de test éphémères, donc il ne peut pas aller dans le Dockerfile. C'est pourquoi je le veux en docker-compose

@washtubs

Je sais que je ne parle pas pour tout le monde, mais j'ai l'impression que le support des configurations satisfait la grande majorité des intérêts ici. Un numéro sera-t-il ouvert pour cela?

S'il n'y a pas encore de problème pour cela, veuillez en créer un et le lier ici. J'ai ajouté quelque chose dans notre tracker d'équipe privé.

@washtubs @funkyfuture

... je lis que cela peut être implémenté dans docker-compose (sans Swarm)

Nous avons déjà un support secret rudimentaire et les configurations pourraient être implémentées de la même manière.

Certainement une fonctionnalité manquante. Le seul "antipattern" est lorsque vous devez contourner le fait que cela est difficile à faire par d'autres moyens, comme par exemple la modification du script de point d'entrée du fichier dockerfile ou la liaison des fichiers de montage dans le conteneur.

Ce que vous voulez, c'est un conteneur qui est construit une fois, de préférence officiellement) et configurable pour le cas d'utilisation, au point d'utilisation, c'est-à-dire docker-compose.

Autant que je puisse voir ce que les gens des dockers ne réalisent pas, c'est que le "Dockerfile" est le plus grand anti-modèle de tout le concept de docker, d'autant plus que tout est totalement illisible et impossible à maintenir. Cela me fait vraiment rire quand quelqu'un connecté avec docker jette le mot «antipattern» comme ils le sauraient!

Le Dockerfile empêche en fait le débogage et le rangement normaux qui seraient disponibles si vous utilisiez un script de construction, ou quelque chose de réellement conçu pour créer des éléments, comme ... un gestionnaire de paquets ou make.

Pour moi, j'utilise le même DockerFile pour tous les cas d'utilisation (ce qui en fait un modèle!) Suggérant que je change mon DockerFile pour chaque utilisation différente, c'est vraiment un anti-modèle.

Et aucun "support de configuration" ne le coupe du tout, imposant une structure là où ce n'est tout simplement pas nécessaire.

Le problème fondamental est que si vous liez mount à dire / etc / nginx, il doit être rw pour permettre l'exécution de scripts qui ajustent les configurations (aka. Envsubst). Et cela modifie ensuite la configuration d'entrée (qui doit rester immuable) ... Vous n'obtenez pas beaucoup plus d'anti-modèle qu'un conteneur écrivant sur toute sa configuration, donc une option pour copier des fichiers dans le conteneur au moment de la recréation est nécessaire Solution.

En d'autres termes, il s'agit d'un répertoire de montage de liaison rw dans le conteneur, mais ro sur l'hôte. Sérieusement, cela vous tuerait-il de permettre cela?

Certainement une fonctionnalité manquante. Le seul "antipattern" est lorsque vous devez contourner le fait que cela est difficile à faire par d'autres moyens, comme par exemple la modification du script de point d'entrée du fichier dockerfile ou la liaison des fichiers de montage dans le conteneur.

Ce que vous voulez, c'est un conteneur qui est construit une fois, de préférence officiellement) et configurable pour le cas d'utilisation, au point d'utilisation, c'est-à-dire docker-compose.

Autant que je puisse voir ce que les gens des dockers ne réalisent pas, c'est que le "Dockerfile" est le plus grand anti-modèle de tout le concept de docker, d'autant plus que tout est totalement illisible et impossible à maintenir. Cela me fait vraiment rire quand quelqu'un connecté avec docker jette le mot «antipattern» comme ils le sauraient!

Le Dockerfile empêche en fait le débogage et le rangement normaux qui seraient disponibles si vous utilisiez un script de construction, ou quelque chose de réellement conçu pour créer des éléments, comme ... un gestionnaire de paquets ou make.

Pour moi, j'utilise le même DockerFile pour tous les cas d'utilisation (ce qui en fait un modèle!) Suggérant que je change mon DockerFile pour chaque utilisation différente, c'est vraiment un anti-modèle.

Et aucun "support de configuration" ne le coupe du tout, imposant une structure là où ce n'est tout simplement pas nécessaire.

Le problème fondamental est que si vous liez mount à dire / etc / nginx, il doit être rw pour permettre l'exécution de scripts qui ajustent les configurations (aka. Envsubst). Et cela modifie ensuite la configuration d'entrée (qui doit rester immuable) ... Vous n'obtenez pas beaucoup plus d'anti-modèle qu'un conteneur écrivant sur toute sa configuration, donc une option pour copier des fichiers dans le conteneur au moment de la recréation est nécessaire Solution.

En d'autres termes, il s'agit d'un répertoire de montage de liaison rw dans le conteneur, mais ro sur l'hôte. Sérieusement, cela vous tuerait-il de permettre cela?

Quelque chose comme ça:

''

si fichier alors écraser

si le répertoire écrase / ajoute le contenu de la destination

avec le contenu de la source pour conserver la structure de destination d'origine

source: fichier : autorisation: propriétaire : groupe

svc:
copie:
- './source/filename:/path/ filename: ro : www-data'
- './source/dir:/path/ dir: ro : www-data'

# ou
svc:
copie:
- source: './source/file'
destination: '/ destination'
permission: ro
propriétaire: propriétaire
groupe: groupe
- source: './source/directory'
destination: '/ destination'
permission: ro
propriétaire: propriétaire
groupe: groupe```

Cas d'utilisation: Nous avons une solution de conteneur non orchestrée dans laquelle nous avons les fichiers docker-compose de notre application, y compris. Certificats SSL, etc. dans un référentiel Git et le tirant sur une VM. Ensuite, nous faisons démarrer le service et voulons déplacer par exemple les certificats SSL, les fichiers de configuration, etc. dans le volume du conteneur. Ceci n'est actuellement pas possible sans un Dockerfile associé avec une commande COPY en vedette. Nous ne voulons pas déranger les fichiers dans le référentiel git cloné. Si l'application modifiait les fichiers, nous devions nettoyer le dépôt à chaque fois.

@MartinMajewski alors vous pouvez monter le répertoire avec des certificats en tant que volume et le pointer dans votre configuration d'application.

Cas d'utilisation (et question pratique à la fois):
J'ai une image postgres avec une seule variable d'environnement à définir au début: POSTGRES_PASSWORD . Je veux le configurer via Docker Secret. Ce que je dois faire, c'est simplement mettre mon propre entrypoint.sh qui exportera le secret attaché dans la variable d'environnement du conteneur en cours d'exécution. Je dois ajouter ce point d'entrée d'une manière ou d'une autre dans mon conteneur au lancement. Sans Dockerbuild à deux lignes - je ne peux pas. Copie d'un seul fichier - impossible.

PS postgres est un exemple. Supposons qu'il ne supporte pas les variables _FILE env.

Problème de suivi interne https://docker.atlassian.net/browse/COMPOSE-89

Cas d'utilisation: Karaf
En utilisant une image de base karaf que je ne souhaite pas reconstruire à chaque fois que je construis mon projet, je souhaite pouvoir déployer rapidement mon application et reconstruire le conteneur pour chaque build. Cependant, je dois copier un _features.xml_ et un _jar_ dans le répertoire de déploiement lors du démarrage du conteneur.

Ma solution jusqu'à présent consistait à utiliser l'image karaf comme image de base dans un autre Dockerfile (en s'appuyant sur overlayfs - qui finit par manquer de superpositions, forçant une suppression manuelle de l'image) et avast / gradle-docker-compose-plugin. Alors que les commandes init peuvent sûrement être passées en tant que variable d'environnement, le contenu de features.xml ne le peut pas. Il doit être stocké sous forme de fichier dans un emplacement spécifique du conteneur. Pour le moment, je ne peux utiliser qu'un montage de liaison de volume pour ce faire. Comment puis-je insérer des éléments dans ce volume sur une machine distante? J'ai besoin de plus de logique dans mon script de construction (par exemple org.hidetake.groovy.ssh, qui complique également le script de construction avec une logique de mot de passe / clé secrète). Si un cp docker-compose était disponible, je pourrais simplement ajouter la commande de copie nécessaire au docker-compose.yml. avast / gradle-docker-compose-plugin gérerait la construction du conteneur et la copie des fichiers de ma sortie de construction directement dans le conteneur sans aucune logique d'accès au système de fichiers distant supplémentaire.

Ce Dockerfile est ajouté à ma partie de construction docker-compose.yml du script. Si quoi que ce soit, c'est un anti-modèle, car il ajoute simplement des superpositions à l'image du docker en amont avec chaque build (jusqu'à ce que je sois obligé de supprimer manuellement l'image - ce qui rend les builds beaucoup plus lents).

FROM myregistry:443/docker/image/karaf-el7:latest

COPY karafinitcommands /usr/local/karaf/etc/

COPY features.xml \
     *.jar \
     /usr/local/karaf/deploy/

Je trouve frustrant que docker cp fonctionne correctement pour la copie d'exécution, mais docker-compose n'a pas de mécanisme équivalent.

Je pensais que l'idée était de lier le montage d'un répertoire local à / usr / local / karaf / deploy et d'y déposer vos fichiers. Je ne m'attendrais pas à devoir reconstruire l'image ou utiliser un fichier docker pour y parvenir.

Je pensais que l'idée était de lier le montage d'un répertoire local à / usr / local / karaf / deploy et d'y déposer vos fichiers. Je ne m'attendrais pas à devoir reconstruire l'image ou utiliser un fichier docker pour y parvenir.

C'est certainement réalisable de cette façon. Relisez et notez que c'est purement un problème de commodité: Le conteneur est reconstruit par gradle build, la prochaine étape logique est: Comment déplacer les nouveaux fichiers de construction dans le "répertoire local" monté sur / usr / local / karaf / deploy? Dans mon cas, un "répertoire local" est plus précisément un "répertoire hôte" où l'hôte est un hôte distant. Je dois donc ajouter rsync ou autre chose à mon script de construction juste pour y récupérer les fichiers et m'assurer que les anciens sont remplacés et que les autres sont supprimés. Ce serait inutile si docker-compose cp était disponible. Je pourrais utiliser mon client docker existant à la connexion du démon docker, que j'ai configuré sur la redirection de port.

Les volumes Docker peuvent être supprimés à chaque build. Impossible de lier les volumes de montage. Ils ne seront repeuplés que s'ils sont vides (mécanisme de protection contre la persistance). Bien sûr, vider un montage de liaison sur une machine distante nécessite certaines autorisations et une logique d'accès qui pourraient toutes être évitées avec un cp docker-compose.

Encore une fois, une copie dans un environnement d'exécution peut être réalisée avec docker cp. C'est la partie frustrante.

Ah, ok je suis trop habitué à ma propre configuration. J'utilise http://github.com/keithy/groan un script bash qui déploie lui-même les éléments sur des serveurs distants, puis nous invoquons docker.

Cas d'utilisation: création de Google Cloud et création d'artefacts

Artefact nécessaire: le client Web (généré automatiquement) réagit aux liaisons graphql. Vous avez besoin du serveur en cours d'exécution pour créer les fichiers nécessaires à la compilation du client. L'image cliente dispose des outils pour créer les liaisons, à partir d'une adresse de serveur. Vous démarrez donc l'image du serveur dans l'arrière-plan et devez maintenant exécuter le conteneur client pointant vers le serveur. Maintenant, comment extraire les fichiers générés du conteneur et les placer dans le répertoire hôte "workspace"? Le montage de répertoires n'est pas autorisé, car vous êtes déjà dans un répertoire monté dans un conteneur Docker. Être capable de docker-compose cp soulagerait l'étape très pénible consistant à obtenir l'ID du conteneur.

S'appuyer sur $(docker-compose ps -q SERVICE) pour cibler le bon conteneur permet d'utiliser le simple docker cli pour de telles opérations centrées sur le conteneur. L'introduction d'une nouvelle commande la simplifierait certainement pour les quelques cas d'utilisation qui la demandent, mais ce n'est pas obligatoire. Pour éviter plus de duplication de code entre compose et docker CLI, je pense que ce problème devrait être fermé.

Il existe un problème ouvert où le cache de construction entre compose et plain docker est différent, en raison de la version du démon docker que compose utilise, ce qui signifie que vous devez utiliser pure compose pour ne pas casser les caches dans les environnements CI (https: // github .com / docker / compose / issues / 883) donc jusqu'à ce que ces problèmes soient résolus, le mélange de commandes docker simples avec des commandes de composition brise les caches. La configuration compose spécifie toutes sortes de baked dans la configuration, ce qui évite de devoir spécifier manuellement la configuration dupliquée avec des commandes simples docker .

S'appuyer sur $(docker-compose ps -q SERVICE) pour cibler le bon conteneur permet d'utiliser le simple docker cli pour de telles opérations centrées sur le conteneur. L'introduction d'une nouvelle commande la simplifierait certainement pour les quelques cas d'utilisation qui la demandent, mais ce n'est pas obligatoire. Pour éviter plus de duplication de code entre compose et docker CLI, je pense que ce problème devrait être fermé.

Cela va beaucoup plus loin que "Peu de cas d'utilisation mentionnés" parce que ces scénarios sont assez courants et que modifier, créer une image, modifier à nouveau, créer une image, etc. L'argument "vous pouvez le faire dans le docker cli alors faites-le simplement ici" annule à peu près de nombreuses autres choses qui ont été ajoutées à docker-compose.

Ce numéro est ouvert depuis près d'un an et il y a de nombreuses autres discussions à ce sujet en dehors de cette question. Il ne devrait certainement pas être fermé à moins qu'il ne soit réellement résolu.

@dionjwa # 883 doit vraiment être étudié (s'il est toujours pertinent) car docker-compose doit être aligné avec docker CLI.

@ jadon1979 Je
Je dis simplement que, d'après les commentaires sur cette demande de fonctionnalité, et le manque d'effort de développement pour offrir une «meilleure façon», la solution de contournement proposée consiste à utiliser une combinaison de docker-compose et de docker cli, que vous pouvez facilement alias dans votre environnement pour le garder simple à utiliser, est une solution de contournement raisonnable.
Maintenant, si quelqu'un ouvre un PR pour offrir une nouvelle commande cp je serai heureux de l'examiner.

Personne n'a contribué car on a dit à tout le monde que chaque cas d'utilisation était un
anti-motif. Et tous les quelques jours, nous avons de nouveaux cas d'utilisation publiés, aucun
anti-modèles.

Le lun 18 nov 2019 à 17:31 Nicolas De loof [email protected]
a écrit:

@dionjwa https://github.com/dionjwa # 883
https://github.com/docker/compose/issues/883 doit vraiment être
étudié (si toujours pertinent) car docker-compose doit être aligné avec
CLI de docker.

@ jadon1979 https://github.com/jadon1979 Je n'essaye pas de bloquer cela
demande de fonctionnalité, vient de remarquer qu'elle a été ouverte il y a plus d'un an, et
aucun des principaux responsables de la maintenance ne l'a considéré comme suffisamment important pour
introduire une nouvelle commande, aucun contributeur n'a non plus proposé de PR pour celle-ci.
Je dis simplement que, d'après les commentaires sur cette demande de fonctionnalité,
et le manque d'effort de développement pour offrir une «meilleure façon», la proposition
solution de contournement pour utiliser une combinaison de docker-compose et docker cli, que vous
peut facilement créer des alias dans votre environnement pour le garder simple à utiliser, est un
solution de contournement raisonnable.
Maintenant, si quelqu'un ouvre un PR pour proposer une nouvelle commande cp, je serais heureux de
révise le.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=AAGRIF2NS64IYANNVTGFTULQUL3TZA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVBVREXG43TUL52HS4DFVREXG43TUL52HS4S4DFVREXG43TUL52HS4DFVREXG43TUL52HS4DFVREXG43TUL52HS4DFVREXG43TUL52HS4DFVREXG43TUL52HS4DFVREXG43TUL52HS4DFVREXG43TUL52HS4DFVREXG43TUL52HS4DFVREXG43TUL52HS4DFVREXG43TUL52HS4DFVVREX63
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAGRIFY7CULCUS3TDDTTHZLQUL3TZANCNFSM4EKAVONA
.

Mon cas d'utilisation ne copie pas les choses _dans_ un conteneur, il les copie _out_ du conteneur après son exécution. Cela peut être fait à partir de l'interface de ligne de commande en utilisant une solution de contournement maladroite qui produit des fonctionnalités sans doute dégradées . Détails complets ci-dessous.

Je suis ingénieur DevOps et je compte beaucoup sur les conteneurs comme alternative à l'enfer de la dépendance des agents de construction bare-metal. Lorsque mon système CI teste un dépôt, il commence par construire à partir d'un Dockerfile dans ce même dépôt et en exécutant toutes les vérifications ( bundle exec rspec , npm test , etc.) _à l'intérieur du conteneur_. S'il y a des artefacts de construction créés comme de la documentation ou des résultats de test, je les copie simplement hors du conteneur avec docker cp .

Pour les tests d'intégration, nous avons commencé à utiliser docker-compose pour fournir des dépendances de service (par exemple un serveur de base de données) au conteneur exécutant les tests. Malheureusement, la «solution de contournement CLI de docker» est moins utile dans ce cas pour copier des fichiers.

Considérez cette configuration: docker-compose-minimal.yml

version: "3"
services:
  artifact-generator:
    image: busybox

Je vais créer le conteneur, exécuter une commande dans ce conteneur, obtenir l'ID du conteneur et essayer d'extraire le fichier en utilisant docker cp

$ # Prepare the images and (stopped) containers.  In this case there is only one.
$ docker-compose --file docker-compose-minimal.yml up --no-start
Creating network "docker-compose-cp-test_default" with the default driver
Creating docker-compose-cp-test_artifact-generator_1 ... done
$ # Determine the ID of the container we will want to extract the file from
$ docker-compose --file docker-compose-minimal.yml ps -q artifact-generator
050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88
$ # Generate the artifact in the container
$ docker-compose --file docker-compose-minimal.yml run artifact-generator touch hello.txt
$ # Check that container ID again, just to be sure
$ docker-compose --file docker-compose-minimal.yml ps -q artifact-generator
050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88
$ # OK, that looks like the only answer we're going to get.  Can we use that to copy files?
$ docker cp $(docker-compose --file docker-compose-minimal.yml ps -q artifact-generator):hello.txt ./hello-artifact.txt
Error: No such container:path: 050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88:hello.txt
$ # Nope.  Let's take a look at why this is
$ docker container ls -a
CONTAINER ID        IMAGE                        COMMAND                   CREATED              STATUS                          PORTS               NAMES
9e2cb5d38ba0        busybox                      "touch hello.txt"         About a minute ago   Exited (0) About a minute ago                       docker-compose-cp-test_artifact-generator_run_dd548ee686eb
050753da4b0a        busybox                      "sh"                      2 minutes ago        Created                                             docker-compose-cp-test_artifact-generator_1

Comme vous pouvez le voir, docker-compose ps n'a vraiment aucune connaissance de l'ID de conteneur mis à jour. C'est malheureux. Ce ne serait pas si mal s'il y avait un moyen pour moi de savoir que run_dd548ee686eb était en quelque sorte lié au docker-compose run j'ai exécuté, mais je ne vois aucun moyen d'y parvenir.

Il existe une solution de contournement maladroite pour cette solution de contournement, qui consiste à ajouter --name à la commande d'exécution:

$ docker-compose --file docker-compose-minimal.yml run --name blarg artifact-generator touch hello.txt
$ docker cp blarg:hello.txt ./hello-artifact.txt
$ ls 
docker-compose-minimal.yml  hello-artifact.txt

Succès! ... un peu

Le problème ici est que si j'ai plusieurs builds exécutés en parallèle, je dois me donner la peine de rendre les --name uniques au monde. Sinon, j'obtiendrai des collisions bruyantes dans le meilleur des cas et des résultats corrompus (pas d'erreur, mais un mauvais fichier extrait) dans le pire des cas. C'est donc maladroit car je dois maintenant réinventer la génération d'ID de conteneur plutôt que d'utiliser simplement celui que Docker a déjà créé.

Au strict minimum, j'aimerais avoir un moyen de connaître l'ID du conteneur qui résulte de la commande docker-compose run .

@ndeloof

En s'appuyant sur $ (docker-compose ps -q SERVICE) pour cibler le bon conteneur, il est possible d'utiliser le simple docker cli pour de telles opérations centrées sur le conteneur.

Faux, voir la démonstration dans le commentaire précédent.

Nous aurons de nouveaux cas d'utilisation pendant des années ici. Attends, je veux dire un nouvel anti
motifs...

Le vendredi 13 décembre 2019, 11 h 40, Ian, [email protected], a écrit:

@ndeloof https://github.com/ndeloof

S'appuyer sur $ (docker-compose ps -q SERVICE) pour cibler le bon conteneur
permettent d'utiliser le simple docker cli pour de tels conteneurs
opérations.

Faux, voir la démonstration dans le commentaire précédent.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=AAGRIF2NFPTKY3QKRIXQ5RTQYONHLA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREX63EGRIF2NFPTKY3QKRIXQ5RTQYONHLA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREX63EGRIF2HS4DFVREX63
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAGRIF3S4UHF5NG3VKYXJB3QYONHLANCNFSM4EKAVONA
.

Qui pouvons-nous mentionner pour contacter les responsables? Cette question est inutile jusqu'à ce qu'ils commencent à nous parler. Cela pourrait être simple "cela ne peut pas être fait en raison de l'architecture actuelle du logiciel", peu importe. Mais laisser un tel problème inerte n'est pas quelque chose que vous aimeriez voir dans cette solution très populaire comme Docker ...

Notre déploiement construit l'image Docker avec bazel, la télécharge dans notre registre Docker, puis utilise des ressources Terraform docker_container avec des strophes upload pour copier les fichiers de configuration dans le conteneur. Je dois migrer ce processus de déploiement pour utiliser docker-compose au lieu de Terraform. Je suis surpris que docker-compose ne fournisse aucune fonction pour la configuration par conteneur.

Ce numéro est ouvert depuis 2 ans. Est-ce la raison pour laquelle Kubernetes dépasse Docker en popularité? Kubernetes fournit des fonctions de configuration et de secrets. Équipe Docker, veuillez au moins ajouter une fonctionnalité de configuration.

tbf docker-compose n'est pas exactement comparable à k8 et n'est pas recommandé pour une utilisation en production. Il est destiné au développement et aux tests rapides. docker swarm est la chose à comparer aux k8 et bien qu'il soit également très simpliste, il possède des fonctionnalités telles que des configurations et des secrets.

Si cela est destiné uniquement au développement, c'est encore plus la raison pour laquelle ce problème
devrait marcher. Les règles "anti-pattern" merdiques ne devraient même pas être ça
important (je dis merdique car c'est clair par l'abondance d'utilisation normale
cas que cela ne ressemble en rien à un anti-pattern).

Le mar 3 mars 2020 à 12 h 56 David Milum [email protected]
a écrit:

tbf docker-compose n'est pas exactement comparable à k8s, et n'est pas recommandé
pour une utilisation en production. Il est destiné au développement et aux tests rapides. docker
swarm est la chose à comparer aux k8 et bien qu'il soit aussi très
simpliste, il possède des fonctionnalités telles que des configs et des secrets.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=AAGRIFZTKGRWMZZ5H6DG3FDRFUSEJA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREX63MNVWWK3TUL52HS4DFVREX63MZVWWK3TUL52HS4DFVREX63MZWWWK3TUL52HS4DFVROX63
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAGRIF4NTQQSR2QQWPJT6PLRFUSEJANCNFSM4EKAVONA
.

Un autre "anti-pattern":

J'utilise docker-compose pour l'orchestration de conteneurs pendant le développement local et k8s pour la production.

Selon les conseils de Docker , j'ai implémenté le script wait-for-it.sh afin de gérer l'ordre de démarrage / arrêt du service.

Dans l'état actuel des choses, à moins que je veuille monter un volume dans chaque service pour ce seul fichier, cela nécessite une copie du script dans le répertoire contenant Dockerfile de chaque service.

Au lieu de cela, j'aimerais conserver une seule copie du script wait-for-it dans un répertoire de niveau supérieur que docker-compose copie ensuite dans chaque conteneur lors de l'exécution localement, car de telles préoccupations sont autrement gérées dans k8s, ce qui signifie que je ne veux pas que ces préoccupations polluent mes services ' Dockerfile s.

Comme l'a écrit Emerson: "Une consistance insensée est le hobgobelin des petits esprits, adoré par les petits hommes d'État, les philosophes et les théologiens."

Il est peut-être temps d'écouter vos utilisateurs ...

@Phylodome ne pouvez-vous pas utiliser les vérifications de l'état des conteneurs et docker-compose depends_on ? C'est ainsi que j'assure des dépendances de démarrage de conteneur saines.

Je crois comprendre que wait-for-it.sh est vraiment un hack, puisque vos services eux-mêmes devraient être résilients aux dépendances qui vont et viennent. Le démarrage n'est qu'un cas individuel de cela.

@ianfixes Est-ce que "vos services" est censé faire référence aux services docker-compose eux-mêmes, ou "nos" services, comme dans, les services écrits par nous qui utilisons docker-compose? Je ne sais pas si vous écrivez dans le rôle d'un "utilisateur" ou d'un développeur docker-compose.

Est-ce que "vos services" est censé faire référence aux services docker-compose eux-mêmes, ou "nos" services, comme dans les services écrits par nous qui utilisons docker-compose?

Les services que vous créez en tant que développeur doivent être résilients. C'est selon ces documents: https://docs.docker.com/compose/startup-order/

Le problème d'attendre qu'une base de données (par exemple) soit prête n'est en réalité qu'un sous-ensemble d'un problème beaucoup plus vaste des systèmes distribués. En production, votre base de données peut devenir indisponible ou déplacer des hôtes à tout moment. Votre application doit être résiliente à ces types de pannes.

Pour gérer cela, concevez votre application pour tenter de rétablir une connexion à la base de données après un échec. Si l'application retente la connexion, elle peut éventuellement se connecter à la base de données.

La meilleure solution consiste à effectuer cette vérification dans le code de votre application, à la fois au démarrage et à chaque fois qu'une connexion est perdue pour une raison quelconque. Cependant, si vous n'avez pas besoin de ce niveau de résilience, vous pouvez contourner le problème avec un script wrapper:

Et il continue en mentionnant divers scripts d'attente.

Je pourrais faire un certain nombre de choses. Mais parce que c'est juste pour le développement local, et parce que j'ai d'autres stratégies pour gérer les chèques du service de production dans les k8, je préférerais la mise en œuvre locale la plus simple et la moins intrusive, pas des conseils génériques de personnes qui ne connaissent pas les détails de pourquoi je '' d aime faire cela (par exemple, des problèmes avec le montage de volume afin d'effectuer le développement d'interface utilisateur via le serveur de développement de Webpack).

Dans tous les cas, ce n'est qu'un autre dans la longue liste de cas d'utilisation de cette fonctionnalité potentielle qui devrait être laissée à la discrétion de l'utilisateur.

J'entends de la colère dirigée contre moi, et je comprends pourquoi il serait frustrant d'entendre des «conseils» non sollicités pour votre approche. Mais je ne sais même pas comment m'excuser; J'ai cité le texte de l'URL que vous avez vous-même appelé «le propre conseil de Docker», qui dit «explicitement» que le script d'attente est un moyen de «contourner le problème». Pour ce que ça vaut, je suis désolé quand même.

Vous n'entendez pas de colère. Vous entendez le ton exaspéré de quelqu'un qui, après avoir recherché sur Google ce qui devrait être une fonctionnalité assez évidente, est tombé sur un fil de cent commentaires dans lequel un ensemble de mainteneurs continuellement fréquenté et rejeté les appels de la communauté pour une fonctionnalité entièrement valide.

Je n'ai pas partagé mon expérience ici car je voulais des excuses. Je l'ai partagé simplement pour ajouter à la longue liste de preuves que les utilisateurs de Docker souhaiteraient une flexibilité supplémentaire lors de l'utilisation de compose .

Bien sûr, comme tout outil, cette flexibilité s'accompagne d'un potentiel d'abus. Mais ce même potentiel, sinon pire, existe lorsque vos utilisateurs doivent trouver des solutions de contournement à résoudre pour leurs cas d'utilisation spécifiques qui pourraient être résolus beaucoup plus simplement en ajoutant simplement cette fonctionnalité.

De plus, donner des excuses à vos utilisateurs est un mauvais regard.

Je ne suis ni un mainteneur ni un contributeur de ce projet, et je m'excuse pour toute confusion. Il semble que le peu d'aide que je pensais pouvoir offrir était indésirable et inutile, et je suis désolé de perdre votre temps.

Je veux cette fonctionnalité pour un conteneur Go qui fait partie de mon application distribuée. Étant donné que le fichier .env doit être inclus dans la racine de l'application Go, je vais devoir créer un .env séparé pour cela ... Alors que si j'avais cette fonctionnalité, je pourrais avoir mon fichier de niveau supérieur .env et le copier dans le conteneur Go lorsque je construis. Cela signifierait moins de choses dont j'ai besoin pour garder une trace ...

Ma solution de contournement pourrait être de créer ce fichier via le conteneur Go Dockerfile ou simplement de créer un fichier .env pour ce conteneur. Mais quand même, à chaque fois que j'ajoute une nouvelle variable d'environnement, je devrai la mettre à jour, éventuellement, à deux endroits. Bon cas d'utilisation ici. Ou je pourrais simplement utiliser un script shell pour cp le fichier pour moi ...

+1 pour la fonction COPY

nous y parvenons déjà dans Kubernetes avec des side-cars, et il existe de nombreux cas d'utilisation. Ce n'est PAS un anti-motif, juste l'une des fonctionnalités permettant de garder la composition de docker.

Il me manque peut-être quelque chose, mais pour le moment, lorsque nous construisons notre application pendant 5 minutes, tout ce temps, le dossier de construction est "en flux" et l'application ne démarre pas en raison d'une incohérence.
Je préférerais _copier_ un dossier de construction dans un conteneur, donc quand il sera temps de démarrer le conteneur, il prendra le relais du conteneur interne. De cette façon, l'application n'est hors ligne que pendant une seconde environ, lors de l'arrêt / du démarrage du conteneur.

En quoi est-ce un anti-pattern alors que docker prend déjà en charge? Il serait logique que docker-compose suive l'utilisabilité de docker proche - ne pas le faire est en soi un anti-pattern.

Le problème avec ceci est qu'il est incroyablement myope (d'où le terme "anti-pattern"), car cela vous obligera à répéter l'opération à chaque fois que les conteneurs seront recréés. Sans parler du fait qu'il évolue très mal (et si vous avez 10 conteneurs? 20? 100?)

Je pense que c'est au développeur. La simple copie d'un seul fichier de configuration local a une surcharge insignifiante. Ne blâmez pas le couteau.

PS Mon cas d'utilisation; Je souhaite ajouter une configuration à un conteneur Nginx dans un projet sans Dockerfiles.

Qui en sait même plus.
J'avais besoin de mettre en place un nouveau projet et recherché un nouveau
outils, Lando est tellement mieux que ça, c'est fou. J'aimerais l'utiliser
plus tôt.
C'est plus rapide, plus facile à comprendre, un meilleur support prêt à l'emploi et
n'a pas de (ex) mainteneurs / contributeurs condescendants.

@ chris-crone concernant votre commentaire ...

Pour les fichiers de configuration ou les données d'amorçage, il existe Docker Configs. Ceux-ci fonctionnent de la même manière que les secrets mais peuvent être montés n'importe où. Ceux-ci sont pris en charge par Swarm et Kubernetes, mais pas par docker-compose. Je pense que nous devrions ajouter une prise en charge pour ceux-ci et cela aiderait avec certains des cas d'utilisation répertoriés dans ce numéro.

Docker-compose est-il intéressé par l'implémentation du support de configuration pour la parité avec les configurations swarm?

S'il y a un ticket pour cela (ou si je dois en créer un qui convient aussi), je voudrais m'y abonner et me désabonner de ce feu de poubelle. Personnellement, je fermerais ceci et établirais un lien vers cela, mais ce n'est que moi.

@harpratap vous avez raison, mais l'inconvénient est que / folder_in_container ne doit pas exister ou doit être vide sinon il sera écrasé. Si vous avez un script bash comme point d'entrée, vous pouvez contourner cela en liant symboliquement vos fichiers dans le répertoire initialement prévu après avoir créé un volume à / some_empty_location

+1 pour avoir une fonctionnalité COPY. Notre cas d'utilisation est la mise en place rapide d'environnements de développement locaux et la copie dans les configurations pour les paramètres de développement.

Exactement. Nous n'évoluons pas tous de la même manière. Mon entreprise utilise SALT pour créer les fichiers .conf requis pour une variété d'applications. Une version - avec les bases - puis docker-compose pour créer les instances individuelles en fonction de leurs parties uniques: adresse MAC, IP, port, licences, modules, etc. Cela POURRAIT être fait à partir d'une ligne de commande - mais beaucoup plus facile et moins source d'erreur de docker-compose.

J'ai un cas d'utilisation. Nous avons une version de test qui nécessite la configuration de ssl. Les certificats sont générés par un service dans le docker-compose ... Je dois ensuite ajouter ces certificats aux conteneurs clients ... si je monte, je perds les certificats existants et je ne peux pas les mettre dans la construction du docker car ils ne le font pas n'existe pas encore.

Par conséquent, je dois exécuter 2 docker-compose - 1 pour lancer les services pour créer les certificats, puis un autre pour créer les services et exécuter les tests. Désordonné.

J'ai vu beaucoup de problèmes ici, où les utilisateurs ont suggéré beaucoup de cas d'utilisation pour une fonctionnalité, mais ils sont abattus parce qu'un responsable pense, c'est un anti-modèle, ou les gens ne l'utiliseraient pas ou une autre histoire .

Bien que cela puisse sembler un anti-pattern pour une personne, je suis sûr que les 1000 personnes qui demandent la fonctionnalité, qui pensent le contraire, doivent également être entendues. Si un peu d'aide est nécessaire pour développer la fonctionnalité, je pense que beaucoup de gens peuvent donner un coup de main.

Mon cas d'utilisation: En plus des configurations, j'ai quelques bibliothèques (RPM) dont j'ai besoin installées dans 5 de mes conteneurs d'applications Rails (Debian). Différentes versions de Ruby / Rails, donc je ne peux pas utiliser la même image de base, donc je devrais être en mesure de stocker les fichiers à un seul endroit et de les copier dans un conteneur lors de la construction, car je ne veux pas télécharger 1,5 Go de données en construisant.

@gauravmanchanda

Mon cas d'utilisation: En plus des configurations, j'ai quelques bibliothèques (RPM) dont j'ai besoin installées dans 5 de mes conteneurs d'applications Rails (Debian). Différentes versions de Ruby / Rails, donc je ne peux pas utiliser la même image de base, donc je devrais être en mesure de stocker les fichiers à un seul endroit et de les copier dans un conteneur lors de la construction, car je ne veux pas télécharger 1,5 Go de données en construisant.

Avez-vous examiné les versions à

Les builds à plusieurs niveaux vous permettent d'utiliser le même Dockerfile pour plusieurs images. Cela vous permet de les factoriser et d'inclure uniquement les bits dont vous avez besoin dans chaque image.

Un bon exemple de celui-ci est celui que nous utilisons pour créer Docker Compose . Cela se construit en utilisant Debian ou Alpine mais nous permet de prendre en compte le code commun.

Dans notre configuration, nous montons une douzaine de simulateurs avec docker-compose. Les simulateurs sont par ailleurs les mêmes, mais un fichier init est différent pour chaque cible et ce fichier est consommé au démarrage (il est supprimé lorsque le serveur est opérationnel). Proposez-vous vraiment de créer une douzaine d'images presque identiques simplement parce qu'un fichier diffère? Cela n'a pas de sens IMO.

Avec docker, l'indicateur --copy-service peut être utilisé pour y parvenir. Existe-t-il des alternatives que nous pouvons utiliser avec docker-compose?

Salut @megaeater ,

nous montons une douzaine de simulateurs avec docker-compose. Les simulateurs sont par ailleurs les mêmes, mais un fichier init est différent pour chaque cible et ce fichier est consommé au démarrage (il est supprimé lorsque le serveur est opérationnel).

C'est un cas d'utilisation intéressant; Quelques questions: Ces simulateurs (ou des parties d'entre eux) ont-ils déjà été exécutés en production (c'est-à-dire: pas sur la machine du développeur ou un CI)? Si le code est ouvert (ou si un système similaire l'est), pourriez-vous me lier pour que je puisse y jeter un œil?

Il serait également intéressant de savoir pourquoi vous voudriez une copie au lieu d'un montage lié ou un volume pour ces fichiers?

Proposez-vous vraiment de créer une douzaine d'images presque identiques simplement parce qu'un fichier diffère? Cela n'a pas de sens IMO.

Les images sont basées sur des calques exactement pour cette raison: toutes les images référenceront les mêmes calques à l'exception du calque qui comprend les différents fichiers.

Le problème avec des choses comme une copie lors de la création d'un conteneur est qu'il rend difficile de prendre le même code et de l'exécuter en production (c'est-à-dire nécessitant une réécriture logique majeure) car le modèle sera fragile ou impossible dans les environnements orchestrés.

Cela ne veut pas dire que nous ne devrions jamais implémenter quelque chose comme ça dans Compose. Plutôt que lorsqu'un changement signifie que les utilisateurs ne pourront pas réutiliser quelque chose qui fonctionne localement en production, nous aimons faire une pause et voir s'il existe un moyen plus robuste d'atteindre le même objectif.

Merci pour le commentaire @ chris-crone

Nous n'utilisons pas docker en production, c'est juste à des fins de développement. Le problème avec l'utilisation du volume (si je comprends bien) est que le simulateur (tiers) a ce script de démarrage qui supprime le fichier au démarrage. L'exécution du script s'arrête si la suppression échoue, nous devrons donc le monter en tant que rw. Et si la suppression de fichiers est autorisée, nous aurions besoin d'un mécanisme pour créer un répertoire temporaire pour fournir ces fichiers afin que les originaux ne soient pas supprimés. Nous aurions donc besoin d'une sorte de scripts superflus pour accélérer la composition en plus de docker-compose.

@ chris-crone Merci pour les liens. Je vais jeter un œil et voir si cela fonctionne pour nous 👍

Hey @ chris-crone J'ai essayé d'utiliser des versions multi-étapes, et cela nous a aidés à garder les bibliothèques / config à un seul emplacement et à les copier, mais maintenant il y a des problèmes avec .dockerignore ignorés, peu importe où Je le place.

Cela fonctionne lorsque j'utilise simplement Docker avec la nouvelle option DOCKER_BUILDKIT , mais ne fonctionne pas avec docker-compose, j'ai essayé COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build , mais cela ne fonctionnait toujours pas. Des idées?

Je me demandais s'il y avait une option pour spécifier où chercher le .dockerignore dans compose, quand je suis tombé sur ce problème https://github.com/docker/compose/issues/6022 , qui encore, a été fermé, coz 1 contributeur pense que ce n'est pas utile.

C'est assez frustrant si je suis honnête ici !!

Ceci est essentiel sur MacOS, car il est d'une importance primordiale de rapprocher au maximum vos cycles de développement de la production; évidemment pour les bonnes pratiques de livraison continue. par exemple, construisez le conteneur, puis liez montez votre nouvelle version du logiciel sur lequel vous travaillez actuellement dans le conteneur pour économiser sur les temps de cycle de construction. Malheureusement, les montures de liaison sont extrêmement coûteuses, étant 3 à 5 fois plus lentes.

À titre d'exemple, le temps de démarrage de tomcat est d'environ 3 secondes pour mon application dans un conteneur. Ajoutez un montage de liaison de ~ / .bash_history et c'est 4s. Ajoutez un montage de liaison de mon application et il est généralement d'environ 18 à 20 secondes. Sous Linux, les performances de montage en liaison sont similaires à celles d'un système de fichiers local, mais pas sous MacOS. Échelle à 100 fois par jour et c'est important.

Cela n'inclut pas la lenteur qui persiste lors de l'accès à l'application pour la première fois; jusqu'à ce que les fichiers de code soient mis en cache. Pour moi, cela signifie 3 minutes, y compris le décalage sur Internet pour la connexion à la base de données oracle monolithique pour changer une petite phrase en autre chose, et voir si cela semble toujours bien. Putain de covid-19, lol.

Idéalement, j'aimerais pouvoir exécuter à nouveau docker-compose et "mettre à jour" mon application dans le conteneur en cours d'exécution, et demander à tomcat de recharger. Je pourrais utiliser le gestionnaire tomcat pour télécharger la modification, mais nous avons également une application back-end qui n'utilise aucun conteneur géré, nous devrons donc utiliser une solution différente pour cela.

Ce serait bien si docker-compose était également orienté vers le développement, pas seulement vers un déploiement de production.

Ce cas d'utilisation est pertinent pour la discussion: https://github.com/docker/compose/issues/3593#issuecomment -637634435

@ chris-crone

@gauravmanchanda

Mon cas d'utilisation: En plus des configurations, j'ai quelques bibliothèques (RPM) dont j'ai besoin installées dans 5 de mes conteneurs d'applications Rails (Debian). Différentes versions de Ruby / Rails, donc je ne peux pas utiliser la même image de base, donc je devrais être en mesure de stocker les fichiers à un seul endroit et de les copier dans un conteneur lors de la construction, car je ne veux pas télécharger 1,5 Go de données en construisant.

Avez-vous examiné les versions à

Les builds à plusieurs niveaux vous permettent d'utiliser le même Dockerfile pour plusieurs images. Cela vous permet de les factoriser et d'inclure uniquement les bits dont vous avez besoin dans chaque image.

Un bon exemple de celui-ci est celui que nous utilisons pour créer Docker Compose . Cela se construit en utilisant Debian ou Alpine mais nous permet de prendre en compte le code commun.

Les builds à plusieurs niveaux sont sympas, mais ils souffrent de leurs propres problèmes, pour une, vous devez exécuter toutes les étapes dans le même contexte, ce qui n'est pas toujours possible. Aussi, pour autant que je sache, vous ne pouvez pas facilement utiliser COPY --from avec des images définies dans un autre Dockerfile et construites avec docker-compose build (je suppose que vous pouvez le faire en les construisant et en les étiquetant manuellement).

COPY en lui-même est très limité dans la mesure où vous ne pouvez importer que depuis votre contexte de construction. docker cp peut copier de n'importe où à n'importe où, sauf qu'il ne peut pas copier entre l'image et le conteneur (un peu comme COPY --from ).

Mon propre cas d'utilisation est un peu différent (à part la copie de fichiers de configuration en lecture seule, les montages de volumes locaux ne sont pas la meilleure idée lorsque vous déployez sur une autre machine) et je dirais que ce que je fais en ce moment est un anti-modèle ... . J'ai potentiellement plusieurs images différentes qui, lors de la construction, génèrent des ensembles d'actifs JS + HTML + compilés et minifiés (pensez aux petites applications angulaires), et un seul serveur nginx qui les sert tous (nb construit à partir d'une image personnalisée à cause des plugins).

Actuellement, ce que je dois faire est de copier les packages "deploy" à partir des images "build" au démarrage. Idéalement, cela devrait être fait soit lors de la création du conteneur, soit lors de la construction, mais cette dernière nécessiterait de créer une autre image au-dessus du "nginx modifié".

Imaginez la mise en page du projet suivante (les sous-projets peuvent vivre dans des référentiels séparés et ne pas se connaître):

app1/
  src/
    ...
  Dockerfile
app2/
  src/
    ...
  Dockerfile
app3/
  src/
    ...
  Dockerfile
nginx/
  ...
  Dockerfile
docker-compose.yml

Chacun des fichiers app{1,2,3}/Dockerfile contient une cible / étape build qui construit l'application en /usr/src/app/dist . nginx/Dockerfile a une seule étape et construit une image similaire à nginx/nginx , mais avec tous les plugins requis (pas de configuration).

docker-compose.yml:

version: '3.8'
services:
  app1-build:
    build:
      context: app1/
      target: build
    image: app1-build
    entrypoint: ["/bin/sh", "-c"]
    command:
      - |
        rm -vfr /dist-volume/app1 \
        && cp -vr /usr/src/app/dist /dist-volume/app1 \
        && echo "Publishing successful"
    volumes:
      - 'dist:/dist-volume'

  app2-build:
    build:
      context: app2/
      target: build
    image: app2-build
    entrypoint: ["/bin/sh", "-c"]
    command:
      - |
        rm -vfr /dist-volume/app3 \
        && cp -vr /usr/src/app/dist /dist-volume/app3 \
        && echo "Publishing successful"
    volumes:
      - 'dist:/dist-volume'

  #... same thing for app3-build

  nginx:
    build:
      context: nginx/
    image: my-nginx
    volumes:
      - 'dist:/var/www'
      - # ... (config files etc)

volumes:
  dist:

Maintenant, ce n'est évidemment pas idéal, chaque image de création d'application est inutilement exécutée et se termine rapidement, les images déployées résident sur un volume partagé (je suppose que cela a un impact négatif sur les performances, mais je n'ai pas encore pu le vérifier). Si un copy ou copy_from était une option docker-compose, la même chose pourrait s'écrire:

version: '3.8'
services:
  # assuming the images have default entrypoint and cmd combination that immediately returns with success.
  app1-build:
    build:
      context: app1/
      target: build
    image: app1-build

  #... same thing for app2-build app3-build

  nginx:
    build:
      context: nginx/
    image: my-nginx
    copy:
      - from: app1-build  # as image or service, both have their pros and cons, service would mean an image associated with this service
         source: /usr/src/app/dist
         destination: /var/www/app1
      - from: app2-build
         source: /usr/src/app/dist
         destination: /var/www/app2
      - from: app3-build
         source: /usr/src/app/dist
         destination: /var/www/app3
    volumes:
      - # ... (config files etc)

Mon cas d'utilisation n'est pas dans l'étape de construction ou l'étape de démarrage. Je récupère les fichiers générés à l'intérieur d'un conteneur ou de tous les conteneurs d'un service, ces conteneurs sont exécutés sur un Docker Engine distant. Jusqu'à présent, je me retrouve à faire quelque chose comme docker-compose ps -qa <service> | xargs -i docker cp {}:<there> <here> . Je souhaite juste que je puisse m'en tenir à docker-composer uniquement dans mon script.

@ chris-crone

Il serait également intéressant de savoir pourquoi vous voudriez une copie au lieu d'un montage lié ou un volume pour ces fichiers?

Aimez-vous l'auto flagellation? Si tel est le cas, je recommande d'exécuter une application à l'aide d'un montage de liaison sur MacOS. 🤣 Voir mon précédent post pour les détails.

Cela ne veut pas dire que nous ne devrions jamais implémenter quelque chose comme ça dans Compose. Plutôt que lorsqu'un changement signifie que les utilisateurs ne pourront pas réutiliser quelque chose qui fonctionne localement en production, nous aimons faire une pause et voir s'il existe un moyen plus robuste d'atteindre le même objectif.

@ chris-crone Je pense que c'est un grand sentiment, car trop souvent les gens se lancent dans la mise en œuvre d'anti-patterns pour docker, comme ne pas gérer la configuration et les données de manière éphémère.

Je me demande si nous pourrions en quelque sorte amener docker et Apple à travailler ensemble pour résoudre les problèmes de performances avec les montages de liaison. Pour moi au moins, je n'aurais plus besoin d'une option docker compose cp, car j'utiliserais des montages de liaison pour le développement. Pour le moment, il est juste trop douloureux d'utiliser des montures de liaison. Je peux passer à une machine virtuelle avec Linux, car mon Mac ne contient que des octets.

@megaeater

Nous n'utilisons pas docker en production, c'est juste à des fins de développement. Le problème avec l'utilisation du volume (si je comprends bien) est que le simulateur (tiers) a ce script de démarrage qui supprime le fichier au démarrage. L'exécution du script s'arrête si la suppression échoue, nous devrons donc le monter en tant que rw. Et si la suppression de fichiers est autorisée, nous aurions besoin d'un mécanisme pour créer un répertoire temporaire pour fournir ces fichiers afin que les originaux ne soient pas supprimés. Nous aurions donc besoin d'une sorte de scripts superflus pour accélérer la composition en plus de docker-compose.

Hmm .. Si vous pouviez vous engager avec le fournisseur du simulateur, je pense que c'est la meilleure façon de résoudre ce problème. Vous pouvez peut-être contourner ce problème avec un script de point d'entrée pour le simulateur qui déplace les fichiers selon les besoins; accordé ce serait désordonné.

@gauravmanchanda

cela nous a aidés à garder les bibliothèques / config à un seul emplacement et à les copier, mais maintenant il y a des problèmes avec .dockerignore ignorés, peu importe où je les place.
Cela fonctionne lorsque j'utilise simplement Docker avec la nouvelle option DOCKER_BUILDKIT , mais ne fonctionne pas avec docker-compose, j'ai essayé COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build , mais cela ne fonctionnait toujours pas. Des idées?

Heureux les builds à plusieurs étages aidés! Quelle version de Docker et de docker-compose utilisez-vous? J'essaierais avec la dernière et verrais si le problème est toujours là. Il doit respecter le fichier .dockerignore.

@Marandil , il semble que docker build ne gère pas la structure de votre projet (ie: la structure des répertoires), ce qui est le problème. Vous pourrez peut-être utiliser quelque chose comme docker buildx bake (https://github.com/docker/buildx) pour résoudre ce cas d'utilisation. Notez que buildx est en cours de développement, il n'est donc pas encore très stable, mais il vise à résoudre une partie de ce que vous rencontrez.

@itscaro , merci pour votre contribution! Ce que nous faisons en interne pour générer des éléments dans des conteneurs, c'est d'utiliser docker build pour générer le résultat d'une image FROM scratch . Cela ne fonctionne que dans les cas où vous avez besoin de la sortie d'un seul conteneur.

@TrentonAdams nous avons travaillé sur l'amélioration des performances du système de fichiers pour Docker Desktop, mais c'est délicat. Le problème sous-jacent traverse la limite de la VM. Les bits de partage de fichiers ont été récemment réécrits (vous pouvez activer la nouvelle expérience en utilisant la bascule "Utiliser gRPC FUSE pour le partage de fichiers" dans les préférences) et cela devrait résoudre certains des problèmes d'utilisation élevée du processeur que les gens avaient constatés. Nous avons de la documentation sur le réglage des performances ici et ici .

@ chris-crone

@Marandil , il semble que docker build ne gère pas la structure de votre projet (ie: la structure des répertoires), ce qui est le problème. Vous pourrez peut-être utiliser quelque chose comme docker buildx bake (https://github.com/docker/buildx) pour résoudre ce cas d'utilisation. Notez que buildx est en cours de développement, il n'est donc pas encore très stable, mais il vise à résoudre une partie de ce que vous rencontrez.

Merci, je vais examiner docker buildx bake . Cela semble prometteur, mais je n'ai pas trouvé de bonne référence ni de documentation à ce sujet, et les pages sur docs.docker.com sont plutôt nues (cf. https://docs.docker.com/engine/reference/commandline/buildx_bake /). Jusqu'à présent, j'ai trouvé https://twitter.com/tonistiigi/status/1290379204194758657 faisant référence à quelques exemples (https://github.com/tonistiigi/fsutil/blob/master/docker-bake.hcl, https: // github .com / tonistiigi / binfmt / blob / master / docker-bake.hcl), cela peut être un bon point de départ, mais pas une bonne référence.

@TrentonAdams nous avons travaillé sur l'amélioration des performances du système de fichiers pour Docker Desktop, mais c'est délicat. Le problème sous-jacent traverse la limite de la VM. Les bits de partage de fichiers ont été récemment réécrits (vous pouvez activer la nouvelle expérience en utilisant la bascule "Utiliser gRPC FUSE pour le partage de fichiers" dans les préférences) et cela devrait résoudre certains des problèmes d'utilisation élevée du processeur que les gens avaient constatés. Nous avons de la documentation sur le réglage des performances ici et ici.

@ chris-crone Hell oui, merci beaucoup! Il y a une amélioration 3-4s avec la nouvelle option, et l'utilisation de "cached" me donne les mêmes performances que de courir en dehors du conteneur, donc c'est ÉNORME pour moi. Je vois des temps de démarrage aussi bas que 2800 ms pour notre application, donc ce n'est plus 11-18s. YAY! Je n'ai besoin de rien d'autre que de la mise en cache, car je ne fais que recréer les conteneurs à chaque fois.

@ chris-crone Y a-t-il un endroit où je devrais publier des informations sur les performances pour m'aider à optimiser les performances et les commentaires sur MacOS? Je me demande pourquoi un conteneur fraîchement démarré avec un montage en liaison serait lent s'il n'utilise pas cached . Il doit y avoir quelque chose d'étrange où il va et vient vérifier chaque fichier au démarrage s'ils sont synchronisés, même s'il est tout neuf?

Cas d'utilisation: j'exécute un conteneur et il modifie un fichier (en particulier, Keycloak modifie son fichier de configuration en fonction des variables d'environnement, etc.). Je veux une copie de ce fichier sur mon disque local afin de pouvoir vérifier le résultat de cette modification et suivre ma progression au fil du temps lorsque je modifie les scripts du conteneur. Actuellement, je dois trouver le nouvel ID de conteneur à chaque fois afin de pouvoir utiliser docker cp .

Cas d'utilisation:
développement dans docker.
J'ai besoin de propager mon fichier de verrouillage sur la machine hôte ou il est écrasé lorsque le conteneur monte le dossier du projet.

Cas d'utilisation: j'ai besoin de copier un fichier contenant une clé secrète. L'application qui s'exécute à l'intérieur du conteneur lit ce fichier en mémoire et le supprime du disque.

Cas d'utilisation: j'exécute des tests unitaires C ++ dans un conteneur docker. Je veux simplement copier le code sur une image existante à chaque exécution.

1) Faire cela avec un fichier dockerfile séparé COPY signifie que le code est écrit dans une nouvelle image inutile et je dois supprimer cette image pour m'assurer que la prochaine exécution crée une nouvelle image avec le dernier code.

2) Faire cela avec docker-compose volumes yaml config signifie que Docker classe le code source comme root:root (tuant totalement mon IDE de faire des modifications jusqu'à ce que je le retire!)

@ shin- suis-je en train de suivre un anti-pattern en exécutant des tests unitaires dans un conteneur? Quelle est la manière non anti-modèle de résoudre ce problème?

.... Je m'en tiens à l'option 1 car c'est la moins douloureuse. Mais je vois que docker-compose supportant une configuration de copie est une amélioration tellement impressionnante! au moins pour ce flux de travail!

@soulseekah L' utilisation de secrets dans la composition n'est-elle pas meilleure pour ce cas d'utilisation?

J'ai trouvé une solution de contournement qui fonctionne pour moi:

1. Créez le Dockerfile avec
   COPY a_filename .
2. Construire l'image à l'aide du Dockerfile
   docker build -t myproject:1.0 .
3. Modifiez le menu fixe pour utiliser l'image que vous venez de créer

version: "3.7"
services:
  app:
    image: myproject:1.0
    ports:
      - 3000:3000
    networks:
       - mynetwork
       - internal
    environment:
      MYSQL_HOST: mysql
      MYSQL_USER: root
      MYSQL_PASSWORD: not_so_secret_password # don't do this 
      # https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/
      MYSQL_DB: appdb
    deploy:
      resources:
        limits:
          cpus: '0.75'
          memory: 100M

Ce n'est pas une solution de contournement parfaite, mais cela fonctionne dans mon cas d'utilisation.

@soulseekah L' utilisation de secrets dans la composition n'est-elle pas meilleure pour ce cas d'utilisation?

Malheureusement, cela nécessite un essaim la dernière fois que j'ai essayé :(

@soulseekah L' utilisation de secrets dans la composition n'est-elle pas meilleure pour ce cas d'utilisation?

Malheureusement, cela nécessite un essaim la dernière fois que j'ai essayé :(

@soulseekah Peut-être utiliser la solution de contournement que j'utilise (au-dessus de vous)?

@ChristophorusReyhan le problème avec ce contournement est indiqué dans le commentaire @zoombinis :

Faire cela avec une copie de fichier dockerfile distincte signifie que le code est écrit dans une nouvelle image inutile et je dois supprimer cette image pour m'assurer que la prochaine exécution crée une nouvelle image avec le dernier code.

Bien qu'il s'agisse d'une solution fonctionnelle, cela peut entraîner une maintenance indésirable. Par exemple, pour nettoyer l'image indésirable _ tout en préservant les images qui vous intéressent_:

docker-compose up && docker-compose down --rmi local

Mais assurez-vous que toutes les images qui vous intéressent ont une balise personnalisée et que l'image test / factice ne le fait pas