Compose: Ajouter `copy` à la configuration yaml

Quelle est la sémantique de copy ici? Copions-nous des fichiers à partir de l'hôte où docker-compose est exécuté dans le nouveau conteneur en cours d'exécution en utilisant docker cp ?

AFAIK il n'y a aucune manière actuelle de faire ceci:

Voir:

`` #! bash
$ docker cp -h

Utilisation: docker cp [OPTIONS] CONTAINER: PATH HOSTDIR | -

Copiez les fichiers / dossiers d'un PATH sur le conteneur vers un HOSTDIR sur l'hôte
exécuter la commande. Utilisez '-' pour écrire les données sous forme de fichier tar dans STDOUT.

--help = false Utilisation de l'impression
''

Quelle est la sémantique de la copie ici? Copions-nous des fichiers depuis l'hôte depuis lequel docker-compose est exécuté dans le nouveau conteneur en cours d'exécution à l'aide de docker cp?

Oui

AFAIK il n'y a pas de moyen actuel de le faire:

Je vois que la commande docker cp est incapable de le faire. Pourtant, c'est toujours possible en accédant aux données du conteneur côté hôte (ce qui, je pense, est moche)

http://stackoverflow.com/a/24805696/210090

Ouais, je ne vais pas du tout recommander de faire ça. Cela brisera beaucoup de choses et d'hypothèses sur Docker. Cela dépend également fortement du pilote de stockage sous-jacent utilisé. Docker se veut agnostique. Je pense que nous devrions _faire_ une solution différente à votre problème :)

Maintenant que docker-1.8 a ajouté la prise en charge de la copie dans un conteneur via docker cp et que swarm-0.4.0-rc2 a ajouté la prise en charge de docker cp , ce serait bien de revoir ce problème au niveau de la composition. Voici le cas d'utilisation (qui reflète ce que nous faisons actuellement dans la production _ presque_):

Un fichier docker-compose.yml qui mentionne de nombreux conteneurs par balise d'image construite en CI (c'est-à-dire que nous n'utilisons pas build: en production; peut-être que nous pourrions maintenant mais cela ne fonctionnait pas bien avec swarm dans les versions précédentes) qui ont tous besoin, par exemple, de fichiers de configuration hadoop statiques mappés dans lesquels correspondent exactement à l'environnement de déploiement. Actuellement, il faut synchroniser manuellement le répertoire dans lequel réside docker-compose.yml avec le chemin exact sur _each_ target docker-machine dans l'essaim. Puis on ajoute une pile de volume: lignes.

La prise en charge de docker cp permettrait la suppression d'une synchronisation de fichier de configuration personnalisée dans notre méthode de déploiement système et permettrait un meilleur contrôle du moment où les modifications de configuration sont injectées (car toute personne modifiant les fichiers mentionnés dans les lignes volume: affecte tous les conteneurs précédemment déployés (et quelle que soit l'heure à laquelle les implémentations internes relisent ladite configuration, peut-être uniquement lors du prochain redémarrage du conteneur, peut-être lorsque divers outils à l'intérieur du conteneur démarrent; ce qui peut être inattendu) et à l'avenir (ce qui est attendu).

OTOH, (comme mentionné brièvement ci-dessus) peut-être devrions-nous utiliser build: . L'inconvénient ici est que nous devons écrire un Dockerfile supplémentaire par type de conteneur de déploiement. Un pour les images construites en CI et un second pour l'injecteur de fichier de configuration statique. copy: dans la composition soutenue par les changements récents de docker cp nous permettrait parfaitement d'éviter toute cette duplication.

Il semble toujours que l'utilisation d'un volume soit une meilleure façon de le faire. Il n'est pas nécessaire qu'il s'agisse d'un volume hôte, il doit fonctionner avec un conteneur de volume de données.

Bedies docker-machine a de toute façon docker-machine scp que vous pouvez faire avec la préparation de la machine; et ensuite vous pouvez faire des volumes d'hôte de la manière normale avec docker ou docker-compose

"Il semble toujours que l'utilisation d'un volume est une meilleure façon de faire cela. Il n'est pas nécessaire que ce soit un volume hôte, cela devrait fonctionner avec un conteneur de volume de données."
Je ne vois pas comment cela est le mieux lorsque la cible est un essaim. AFAICS, on n'a aucun moyen d'exprimer qu'un conteneur de volume de données devrait exister à chaque nœud d'essaim possible.

De toute façon, ne pouvez-vous pas déployer un conteneur de volume de données sur un nœud même via l'essaim lui-même, comme vous pouvez le faire avec n'importe quelle autre stratégie de planification de conteneur ala?

"Bedies docker-machine a de toute façon docker-machine scp que vous pouvez faire avec la préparation de la machine; et alors vous pouvez faire des volumes d'hôte de la manière normale avec docker ou docker-compose"
Je fais actuellement cela. C'est pénible. Les personnes gérant les déploiements oublient de déplacer les fichiers de configuration. S'il était pris en charge dans docker-compose yml, cela se produirait chaque fois qu'un conteneur était recréé sans les étapes manuelles.

"De toute façon, ne pouvez-vous pas déployer un conteneur de volume de données sur un nœud même via l'essaim lui-même, comme vous pouvez le faire avec n'importe quelle autre stratégie de planification de conteneur?"
Peut-être que nous pourrions mais j'avoue que je ne vois pas comment à la lumière de la mise à l'échelle.

"De toute façon, ne pouvez-vous pas déployer un conteneur de volume de données sur un nœud même via l'essaim lui-même, comme vous pouvez le faire avec n'importe quelle autre stratégie de planification de conteneur?"
Humm, si je sais que mon essaim est de taille 10 nœuds; puis-je simplement mettre à l'échelle le conteneur de volume de données pour qu'il soit de taille 10 avec une politique selon laquelle aucune duplication n'est autorisée sur un nœud de moteur Docker donné? Le problème (sauf si j'ai manqué quelque chose) est que, par exemple, les conteneurs qui doivent référencer ce volume de données n'ont aucun moyen de --volume-à partir d'un conteneur avec un index qui correspond. Les gars, je regarde ce problème depuis 2 mois maintenant. Le mieux que je puisse faire est de créer un script qui utilise docker-machine scp . Mais c'est une étape manuelle après la modification d'un fichier de configuration et avant docker-compose up . Cela nécessite également que l'on puisse écrire le chemin exact sur les machines cibles de l'essaim en tant que racine du docker-compose.yml (c'est-à-dire que ça sent comme un hack majeur).

Peut-être que mes efforts en usine peuvent aider à automatiser ce processus de démarrage des machines docker et d'essaim de clsuters avec les «bonnes» données prêtes à l'emploi? (_ bien qu'il soit encore en développement et je l'utilise pour combiner docker-machine et docker-compose en un seul setp_0.

copy est une opération, ne fait pas partie de la configuration du service, donc elle n'appartient pas au fichier de composition.

Docker 1.9 ajoute une nouvelle API de volumes, et les pilotes de volume sont déjà disponibles. Les volumes sont vraiment la bonne façon de supporter cela. Ne pas essayer de copier des fichiers.

Merci pour la suggestion! mais je ne pense pas que cela corresponde vraiment à la conception de composer en ce moment.

la copie est une opération qui ne fait pas partie de la configuration du service, elle n'appartient donc pas au fichier de composition.

Et si l'on veut copier juste un fichier de configuration? (à un essaim de dockers, donc volume_from ne fonctionnerait pas)

J'ai exactement la même situation, je veux copier des fichiers de configuration personnalisés mysql, nginx, haproxy, etc., nous avons des clusters en production et au lieu d'utiliser simplement une commande de copie pour copier les configurations de local à distant

Je dois utiliser des images, construire, tirer à chaque fois, alors que ce n'est pas nécessaire et que la simple commande de copie économisera beaucoup de temps de déploiement et de développement

C'est très surprenant pour moi que plus de gens n'aient pas de problème avec ce ne pas être facilement scriptable. Est-ce que je pense mal à Docker? Je pense que ma solution serait maintenant d'utiliser ansible pour copier les fichiers de configuration sur l'hôte, puis de monter le volume de l'hôte vers le (s) conteneur (s) qui en ont besoin

Frapper le même problème. Je réutilise un Dockerfile pour N services différents et je ne veux pas créer N différents Dockerfiles avec leur propre commande COPY ou créer un volume juste pour cela.

Btw je résous actuellement cela en exécutant des dizaines de lignes de commandes sed - http://unix.stackexchange.com/questions/112023/how-can-i-replace-a-string-in-a-files

Peut-être pas une solution optimale, mais cela fonctionne étant donné que docker-compose ne prend pas en charge la copie de fichiers.

Btw montage et copie bien sûr possible mais cela va à l'encontre des offres d'automatisation de docker-compose - si je préférais tout faire manuellement, je n'utiliserais pas docker-compose, n'est-ce pas?

Plus j'ai creusé dans Docker, plus il semble que beaucoup de ces outils soient bons pour "bonjour le monde" / "regardez à quelle vitesse je peux faire tourner ce truc cool avec \ shell \ commandes \ comme \ this \" sur un cas d'utilisation de type de machine unique (docker-compose inclus). Si cela va bien au-delà, les choses commencent à devenir assez compliquées et l'OMI s'effondre un peu, c'est là que les outils de provisioning traditionnels peuvent entrer et sauver la mise lorsqu'ils sont utilisés de manière appropriée.

J'ai trouvé que l'utilisation d'Ansible pour configurer des machines de manière idempotente était très facile lorsque j'ai des volumes, des fichiers et des fichiers de configuration spécifiques à la machine qui doivent exister pour que l'image docker démarre. Ensuite, à la fin, je peux utiliser Ansible pour appeler docker-compse ou même utiliser le module docker Ansible dont la syntaxe est presque la même que celle de docker compose avec quelques fonctionnalités bonus supplémentaires.

À la fin de la journée, l'approche ci-dessus permet à tout d'être scripté, idempotent et surtout vérifié dans le contrôle de code source.

@dnephin, certaines personnes ci-dessus ont suggéré le cas d'utilisation de CP faisant partie de la configuration, serait-il logique de revoir l'hypothèse que CP est uniquement pour les opérations et non pour la configuration.

Un exemple simple est la création d'un conteneur, la copie de la configuration au bon endroit, le démarrage du conteneur une fois la configuration copiée.

Cela permet la création d'images qui n'intègrent pas la configuration réelle et ne déploient la configuration qu'au démarrage du conteneur.

Ce sera certainement très utile. Je travaille avec l'image postgres comme back-end de base de données maintenant et je ne veux pas la reconstruire, juste pour mettre à jour un script dans le dossier /docker-entrypoint-initdb.d .

Pourquoi ne rouvrez-vous pas ce problème jusqu'à ce que la fonctionnalité soit implémentée ou qu'une solution viable soit trouvée que les gens aiment, puisque personne ici n'aime les options suggérées?

Ce numéro devrait être rouvert, comme @ctindel l'a mentionné.

+1 pour avoir rouvert le problème

+1 pour l'ouverture également.

+1 pour la réouverture.

+1 pour la réouverture.

+1 pour la réouverture.

+1 pour la réouverture.

+1 pour la réouverture.

+1 pour la réouverture.

Quel est le problème avec un volume en lecture seule?

myservice:
    image: foo/bar
    volume:
        - src:dest:ro

@michaelarnauts voit ça .

👍 pour la réouverture

+1 pour la réouverture.

+1 pour la réouverture.

+1 pour la réouverture

+1 pour la réouverture

+1 pour la réouverture

+1 pour la réouverture

+1 pour la réouverture

+1 pour la réouverture

Voici ma justification pour autoriser une copie dans Compose.

J'ai une application qui fonctionne sur de nombreux conteneurs. Par souci d'argumentation, stipulons qu'ils exécutent tous Apache. Ils ont tous des définitions DocumentRoot pointant vers des choses comme "/ var / www / partX". Le Dockerfile ne sait rien du contenu de la configuration Apache, et le Compose définit la référence de volume pour / var / www / partX. Cela fonctionne très bien pour le développement, car je peux déboguer et modifier le code sans modifier le contenu du conteneur.

Le hic, c'est quand je veux déployer. L'une des principales attractions de Docker est que je peux déployer un conteneur qui est son propre univers. Pour tout récupérer dans le conteneur, je dois copier les fichiers, ce qui signifie que je devrais avoir des définitions Dockerfile et Compose distinctes de celles que j'utilise pour le développement. Sur un grand projet, cela signifie que je dois maintenir deux ensembles de fichiers de définition, ce qui introduit plus de possibilités d'erreurs.

Ma préférence serait de conserver un seul ensemble de fichiers Dockerfiles et de faire l'orchestration sur le fichier Compose. Compose serait l'endroit où je définirais si je vais configurer / var / www / partX en tant que volume partagé ou si je copie des fichiers dans le conteneur.

Le déploiement avec des volumes partagés semble être une boîte de vers. Si je mets à jour une version existante en production qui dépend d'un volume partagé, je ne peux pas mettre à jour ce volume partagé sans configurer une fenêtre de maintenance ou proposer un schéma de version de mon volume partagé. Je suis en train de coupler étroitement les conteneurs avec des fichiers externes, et si j'introduis ce type de complexité, je nie certains des avantages de l'utilisation de Docker.

Il semble que je pourrais écrire des modifications aux définitions de Dockerfile pour copier des fichiers de manière conditionnelle, mais il semble plus "logique" de gérer toute ma logique Docker dans l'univers Docker, et Compose semble être un endroit logique pour le faire.

+1 pour la réouverture.

+1. Il serait très utile de copier un fichier de configuration dans un fichier docker-compose.yml au lieu de Dockerfile .

+1. Je l'ai juste rencontré en essayant de fournir un fichier de configuration pour le service. Le volume en lecture seule semble être une option, mais préfère le copier.

Le simple montage d'un volume peut faire l'affaire:

version: '2'
services:
  foobar:
    image: 'postgres:9.6-alpine'
    volumes:
      - './docker/schemas/foobar:/docker-entrypoint-initdb.d'

@raszi - Yah, la configuration montée est la direction que nous allons prendre pour le moment. L'une des choses que j'ai vraiment aimées à propos de Docker était la notion d'un conteneur autonome sur lequel je pourrais exécuter des tests d'intégration, sans aucun souci pour les dépendances externes (comme la configuration liée). Si je fais des déploiements bleu / vert ou A / B et qu'il existe des différences dans les configurations utilisées par les différentes versions de conteneurs, les choses peuvent devenir un peu fragiles. Je peux contourner ce problème en faisant des choses comme la gestion des versions des fichiers de configuration dans un volume partagé de chacun de mes environnements, mais cela semble juste plus complexe ou fragile qu'il ne pourrait l'être.

"Les conteneurs Docker enveloppent un logiciel dans un système de fichiers complet qui contient tout le nécessaire pour s'exécuter: code, runtime, outils système, bibliothèques système - tout ce qui peut être installé sur un serveur. Cela garantit que le logiciel fonctionnera toujours de la même manière, indépendamment de son environnement. " Pour moi, cela inclurait idéalement la configuration. Compose est en quelque sorte un "build / compile and run", je pense que certains d'entre nous souhaitent que Compose puisse faire un "build / compile, link and run". Ce n'est pas comme ça que ça marche aujourd'hui, et je peux comprendre le manque d'enthousiasme pour emprunter cette voie, mais bon, c'est un forum, ça ne fait pas de mal de demander;)

Je suis d'accord, ce serait formidable d'avoir cette fonctionnalité. Je viens de publier ma solution pour aider les autres.

+1 pour la réouverture.

+1

+1 pour réouverture ou solution différente sans volumes.

Utilisation actuelle des variables d'environnement dans docker-compose.yml et j2 dans docker-entrypoint.sh pour les analyser en fichiers de configuration avant d'exécuter l'application principale du conteneur. Fonctionne pour moi, bien que ce soit une image personnalisée et qu'elle ne puisse pas être utilisée avec des images complètes déjà disponibles.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 pour la réouverture

Pour ajouter la possibilité d'avoir un fichier yaml différent pour chaque conteneur au lieu d'une configuration basée sur des variables d'environnement

+1 fonctionnalité très nécessaire

+1, agréable d'avoir une fonctionnalité!

+1

+1

+1

+1

+1 réouverture. Favoris

+1 c'est une fonctionnalité indispensable.

S'il y avait un moyen de marquer un volume partagé en tant que couche, de sorte que le volume reste RO mais les écritures appliquées à une couche au sommet, je vivrais heureux sans une directive copy . Je voudrais partager, par exemple, un artefact de construction extrait, mais le service écrit dans ce répertoire (journaux ou fichier PID, etc.).

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 Pour la réouverture car ce serait une fonctionnalité très utile

Peut-être que la fonctionnalité de modèle de https://github.com/jwilder/dockerize peut aider certains d'entre vous

+1

+1

+1

+1

+1

+1 pour rouvrir le problème

+1

Utilisez des secrets de docker, dans cet exemple, les secrets sont utilisés avec l'image nginx pour copier le certificat du serveur et le fichier de configuration
https://docs.docker.com/engine/swarm/secrets/#intermediate -example-use-secrets-with-a-nginx-service

C'est un bon point. Honnêtement, il semble que puisque nous avons déjà des secrets, nous devrions avoir une copie, car les secrets ne sont, en quelque sorte, qu'un type spécifique de fichier que vous copieriez. À savoir, celui qui est plus soigneusement provisionné, dont nous n'avons pas besoin pour les fichiers de configuration.

Il bat l'hôte qui monte un volume pour chaque fichier de configuration que vous souhaitez inclure.

Comme dit précédemment:

...
volumes:
- ./nginx/default.conf:/etc/nginx/conf.d/default. conf: ro
- ./nginx/nginx.conf:/etc/nginx/nginx. conf: ro
...

La raison pour laquelle la copie est meilleure, a) dans les environnements swarm, où les hôtes sont en fait des machines séparées, vous ne devriez pas avoir à avoir exactement le même fichier au même endroit sur chaque machine. b) La copie peut également être limitée au dossier dans lequel se trouve la composition, alors qu'un montage hôte nécessite un chemin absolu. c) Je pense que le but de docker est de minimiser le nombre d'endroits où l'application contenue se brise dans l'hôte. Les montages d'hôte, même lorsqu'ils sont configurés en lecture seule, créent une responsabilité sur l'hôte pour avoir et conserver les fichiers. Nous ne devrions pas avoir à utiliser des montages d'hôte pour résoudre ce problème simple.

Je pense que la copie pourrait être modélisée de la même manière que le processus docker build , où le Dockerfile est généralement expédié dans un référentiel git, avec tous les fichiers qu'il doit envoyer au contexte de construction. Le Dockerfile n'est pas autorisé à envoyer tout ce qui existe en dehors de sa structure de répertoire, même s'il est correctement lié symboliquement. Nous pourrions avoir une chose similaire avec compose, où src est limité au répertoire (et à ceux ci-dessous) du docker-compose.yml . Fondamentalement, le flux de travail serait, docker-compose crée le conteneur, puis pour chaque paire src:dst , recherchez le src sous le répertoire actuel et copiez-le dans le conteneur non démarré, puis démarrez le conteneur.

Actuellement, il est possible d'éviter les montages d'hôte en ajoutant des Dockerfiles supplémentaires et en construisant les fichiers conf en images modifiées, mais cela me semble exagéré, car cela implique de redéfinir une nouvelle image ou de forcer les utilisateurs pour utiliser l'attribut docker-compose build au lieu de l'attribut le plus préférable (IMO) image . Si vous utilisez déjà l'attribut build dans votre définition de service, et que vous voulez faire les choses de cette façon, vous êtes obligé de polluer votre générateur d'image autrement agnostique avec un fichier de configuration hautement avisé qui devrait appartenir à la composition et le processus de déploiement.

+1 pour la fonction de copie docker-compose

+1

+1

+1

+1 pour copie.

+1 pour la fonction de copie de docker-compose. Je pense que les arguments en faveur ci-dessus sont convaincants.

+1 pour copie

+1 pour copie.

Bien que dans mon POV. Cela peut devenir pratique, mais il peut aussi devenir incontrôlable ou abusé pour de nombreux utilisateurs et peut même rendre le volume obsolète. Si vous avez juste besoin de mettre des fichiers dans le conteneur, en particulier pour swarm, vous pouvez simplement utiliser des configs ou des secrets; Mais pour mon cas, comme placer des dossiers statiques dans un conteneur nginx, je dois utiliser des builds en plusieurs étapes dans mon Dockerfile pour placer ces dossiers statiques dans le conteneur, ce qui nécessite beaucoup de processus avant que mon objectif ne soit atteint. Je pense donc que l'ajout d'une option de copie pourrait être très utile

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 pour la réouverture

+1

+1 pour la réouverture

Une fonctionnalité qui opère sur un volume après que le conteneur (ou lui-même) ait atteint un certain état ne fonctionnerait-elle pas?
Cela pourrait être un drapeau comme lecture seule, mais copie uniquement à la place! Ensuite, vous auriez le pipeline / syntaxe d'opérations de volumes réguliers avec la fonctionnalité supplémentaire de suppression du lien après qu'un état de synchronisation est atteint à l'intérieur du conteneur ...

+1 pour la réouverture. Le montage en volume n'est pas toujours une option. C'est pourquoi je poste ici aujourd'hui. Je dois modifier à la main un grand nombre de conteneurs pour copier des fichiers en raison d'un scénario unique où le montage de volume est interdit.

+!

+1

+1 pour la fonction de copie docker-compose

+1

+1

Je commence à penser que c'est inutile. Docker n'ajoute que des fonctionnalités autour du cas d'utilisation particulier pour lequel il a construit le docker - c'est l'une des fonctionnalités en dehors de leur cas d'utilisation, donc ils ne l'ajouteront probablement jamais.

+1

@stuaxo Ce footguns que nous devons les implémenter automatiquement.

Dans ce cas, les fichiers requis par un service pour s'exécuter doivent soit être intégrés à la construction (déclarés dans Dockerfile), rendus disponibles via des volumes, soit (dans le cas du mode docker stack / Swarm) exister en tant que configuration ou des objets secrets. La copie de fichiers dans des destinations potentiellement multiples au moment de l'exécution est lente, sujette aux erreurs et non résiliente aux pannes.

Bravo, excuses si cela vous paraissait grincheux.
Quand vous dites "exécuter un service", je suppose que vous voulez dire une chose de longue durée comme un service Web, Docker a bien couvert cela.

La superposition et la mise en cache des dockers sont utiles pour d'autres choses;

J'ai mis mon ancien blog WordPress dans le docker, mais je ne l'exécute que parfois pendant quelques minutes pour pouvoir exporter des données ou vérifier à quoi ressemblait un article.

Cela a pris un peu de travail pour utiliser docker compose pour séparer MySQL et Apache, mais je ne me soucierais pas qu'ils soient tous brouillés ensemble.

La mise en cache des dockers est amusante lors de l'expérimentation de la création de bibliothèques de bureau comme Cairo. J'ai oublié les détails de la plupart des choses que j'essayais de faire, mais elles concernent davantage la construction de quelque chose que tout ce qui concerne les services en cours d'exécution.

Une copie de docker-compose doit être ajoutée. Il permet un flux beaucoup plus facile des fichiers de configuration et des mises à jour des conteneurs.

Utiliser docker cp et docker config

Le vendredi 2 mars 2018 à 21:19, James Hahn [email protected] a écrit:

Une copie de docker-compose doit être ajoutée. Cela permet un écoulement beaucoup plus facile
des fichiers de configuration et des mises à jour des conteneurs.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/docker/compose/issues/1664#issuecomment-370055493 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABOv-q5VO9n9HDvBP6YJ1BCePz5tGu-pks5tabdrgaJpZM4FTTPg
.

>

James Mills / prologique

E: [email protected]
W: prologic.shortcircuit.net.au

+1 pour la copie docker-compose. L'idée est d'avoir copie uniquement pour les fichiers comme décrit ici

+1

+1

Dans ce cas, les fichiers requis par un service pour s'exécuter doivent soit être intégrés à la construction (déclarés dans Dockerfile), rendus disponibles via des volumes, soit (dans le cas de la pile de docker / mode Swarm) exister en tant qu'objets de configuration ou secrets. La copie de fichiers dans des destinations potentiellement multiples au moment de l'exécution est lente, sujette aux erreurs et non résiliente aux pannes.

Sauf dans de nombreux cas, tout ce que vous voulez est de mettre à jour un seul fichier de configuration, auquel cas la création de votre propre image d'une image officielle standard est une mauvaise pratique et génère beaucoup de dette technique pour le futur, les volumes sont exagérés X10 et vous ne le faites pas. voulez ou avez besoin que les fichiers continuent à se synchroniser, sans parler des problèmes liés au fait de devoir traiter l'ensemble du dossier et pas seulement un seul fichier dans un emplacement par défaut, et vous devez mettre à jour un fichier système et pas seulement obtenir un paramètre de configuration.

Je comprends vos préoccupations, mais le simple fait de dire à tout le monde que son besoin n'est pas réel ne fera que éloigner les gens de votre projet et de la communauté qui veut l'utiliser et soutenir votre travail. Nous voulons travailler avec vous ici pour trouver une solution qui fonctionne, mais tout ce que vous voulez dire, c'est que nous n'avons pas besoin de ce dont nous pensons avoir besoin.

Wow, je ne peux pas croire que cela n'a pas encore été fait. Je pensais que cette fonctionnalité de base aurait été maintenant dans docker-compose. Oh, la beauté des projets OSS ...

Résolu avec docker-compose --force-recreate --rebuild , il copie les nouveaux fichiers s'ils ont changé (ou du moins il semble). Pas idéal, mais ça marche.

+1

+1

+1

+1

+1 c'est discret qui me rend fou, il semble idiot de devoir monter un volume juste pour un fichier de configuration.

+1

Nous avons un moyen d'ajouter des fichiers à un conteneur à l'aide de docker compose avec des volumes. J'ai remarqué que la documentation Compose a maintenant un paramètre configs , donc nous pouvons également ajouter des fichiers uniques.

https://docs.docker.com/compose/compose-file/#configs

Cependant, ce que je pense que les gens veulent, c'est un moyen de fusionner les fichiers de l'hôte dans un répertoire du conteneur, la préférence étant overwrite if exists , comme vous vous attendez à ce qu'une copie fonctionne.

Il m'est étrange que la configuration volumes dans le fichier de composition ait une option nocopy :

https://docs.docker.com/compose/compose-file/#volumes

volumes:
  - type: volume
  source: mydata
  target: /data
  volume:
    nocopy: true

Ce qui est décrit comme ceci:
volume: configure additional volume options
nocopy: flag to disable copying of data from a container when a volume is created

Donc, il désactive exactement ce qui est souhaité?

Mon cas d'utilisation souhaité concerne les applications Web pour le développement. Je veux que l'image contienne tout ce dont elle a besoin pour servir un site Web, y compris un site Web par défaut à servir, mais j'ai la possibilité de fusionner / écraser ces fichiers avec l'état de fonctionnement actuel d'un site Web sans autre configuration (la clé) au-delà d'avoir les fichiers dans le bon endroit sur l'hôte. Des fichiers qui, une fois copiés dans le conteneur, sont éphémères. Ce qui signifie pas dans un partage réseau.

Un exemple de cadre qui en bénéficierait est quelque chose comme Laravel. Où je crée une image qui sera capable de servir la page de démarrage Laravel sans autre configuration (volumes, partages réseau, etc.), mais le fichier de composition est écrit pour copier les fichiers de l'hôte vers la racine Laravel du conteneur afin qu'ils puissent être écrasé.

Utiliser un partage réseau pour cela est une maintenance supplémentaire pour un environnement éphémère (le développement n'est pas toujours constant). L'utilisation d'un montage de volume pour cela, avec un framework tel que Laravel, nécessite la construction de l'application dans ce volume, ce qui signifie installer PHP et composer sur l'hôte ou partager l'emplacement sur l'hôte sur lequel l'application serait créée. Les deux créent plus de maintenance.

Éditer:

Après les tests, il semble que lorsque vous montez un volume, les fichiers qui existaient dans l'image à cet emplacement sont copiés sur le volume persistant de préférence au contenu d'origine du volume. Cela signifie qu'il n'écrase pas.

Je pense en fait que c'est une solution pour le résultat souhaité.

Hé, les gars, juste pour info, il vaut mieux donner une réaction positive au message principal sur ce problème que d'ajouter un commentaire "+1", car les problèmes peuvent être triés en fonction du nombre de réactions qu'ils ont reçues.

+1

+1 Veuillez l'équipe Docker, considérez votre communauté.

@ shin- Le problème actuellement est que la fonction de volumes rend impossible le branchement d'un seul fichier de configuration d'un volume externe dans un conteneur.

Supposons que je veuille brancher un fichier de configuration nginx dans /etc/something/whatever.conf sans anéantir tout ce qui se trouve dans ce dossier. Vous ne pouvez pas créer un volume nommé pour un seul fichier (voir moby / moby # 30310), et vous ne pouvez pas non plus créer un volume de répertoire contenant un seul fichier, puis monter ce fichier particulier dans le conteneur (voir moby / moby # 32582).

La seule option qui vous reste est de polluer les emplacements fixes de votre hôte Docker réel avec les fichiers de configuration, puis de les monter en liaison. Cela se brise bien sûr si vous souhaitez vous déplacer entre les hôtes Docker ou travailler avec un Docker hôte auquel vous n'avez pas accès au système de fichiers (par exemple, CI en ligne), ou même exécutez simplement plusieurs piles en parallèle.

Quelque chose doit céder ici, soit la fonctionnalité des volumes de Docker doit changer pour que nous puissions réellement l'utiliser pour injecter des fichiers de configuration dans notre pile, soit nous devons le contourner en composant en utilisant quelque chose comme copy Option

FWIW Je ne suis plus un mainteneur de Compose, mais il me semble que ce cas d'utilisation serait mieux servi en injectant le fichier de configuration au moment de la construction à l'aide d'un Dockerfile.

@ shin- Malheureusement, les fichiers de configuration ne sont pas connus au moment de la construction, les images sont préparées sur un serveur CI bien avant que nous sachions où nous allons les déployer et dans quelle configuration.

Je suis avec @masaeedu , je comprends l'idéal conceptuel d'empêcher la fonction de composer de ramper et donc de ne pas vouloir ajouter cette fonctionnalité, mais dans la vraie vie la perte de cette fonctionnalité réduit GRANDEMENT les circonstances où composer peut être utilisé sans

A) devoir bricoler une sorte de travail de script hideux pour tenir les conteneurs en question (la chose même que composer était destinée à aider à normaliser et à nous éviter d'avoir à faire),

B) avoir à ajouter un autre outil qui gère l'ensemble de notre configuration (qui, bien que réalisable, ajoute une énorme quantité de frais généraux pour les projets de petite à moyenne taille qui ont vraiment juste besoin de copier un .conf et .env spécifiques dans chaque conteneur, quelque chose que vous ne voulez pas faire au moment de la construction de l'image, cela équivaut à dire que plutôt que votre logiciel ayant un fichier de configuration, vous devez coder en dur toutes vos options dans le C ++, cela conduit à des dizaines d'images supplémentaires à maintenir), ou

C) devoir maintenir une image séparée pour chaque configuration possible d'un logiciel donné dont nous aurons besoin / créer une image personnalisée à chaque fois que nous devons apporter un changement de configuration mineur .... ce qui est à la fois irréalisable dans le monde réel de logiciels de production, et rend également impossible d'avoir le type de pipeline d'assurance qualité et de test robuste dont nous avons besoin pour les logiciels de production.