Le nom du projet n'est pas important. J'aime l'idée d'un nom de projet aléatoire. Mieux encore - pourrions-nous générer un hachage du chemin vers fig.yml et l'utiliser?

Je pense en fait que le nom du projet est assez important. Si vous voulez pouvoir faire quoi que ce soit avec les images dans un pipeline CI, vous devez connaître le nom du projet pour pouvoir les renommer comme autre chose.

Le fait de pouvoir remplacer le nom du projet à partir des variables d'environnement permet de conserver ces variables uniques et prévisibles. Je pense que quoi qu'il arrive, nous devons prendre en charge le remplacement des variables d'environnement.

J'aime l'idée de rendre le nom du projet configurable à partir d'un fichier. Je pense qu'une discussion similaire a eu lieu dans (# 45). Avoir le nom du projet dans .fig/project-name semble conduire à beaucoup de très petits fichiers. Je pense qu'il serait plus facile de simplement le mettre dans le fig.yml lui-même (comme cela est suggéré dans # 45, et l'une des propositions de composition de docker).

Quels sont les avantages de le placer dans un répertoire et un fichier séparés?

La raison de le mettre dans un fichier séparé a un certain nombre de raisons, je vais essayer d'expliquer ma pensée derrière cela;

• Pour conserver le nom qui a été utilisé pour _démarrer_ le projet (ie, --project-name=foobar ), qui peut être différent du nom de projet automatique.
• Avoir plusieurs instances ou _versions_ d'un projet en cours d'exécution sur le même serveur, sans qu'elles ne soient en conflit
• Ou, en bref, le .fig/project-name contient le nom de _cette instance_ du projet.

Peut-être que le fichier devrait s'appeler instance-name ou similaire.

J'aime l'idée de rendre le nom du projet configurable à partir d'un fichier

Bien que _possible_ de le faire avec cette proposition (en créant manuellement le fichier project-name ), mon cas d'utilisation principal était de demander à _fig_ de créer le fichier afin d'enregistrer le nom utilisé.

conduira à beaucoup de très petits fichiers.

Certes, l'alternative est d'ignorer le répertoire .fig , cependant, si des éléments supplémentaires sont nécessaires à l'avenir, des fichiers supplémentaires peuvent être ajoutés sans encombrer la racine de votre projet. Git fait de même et je pense que c'est une approche propre.

Je pense qu'il serait plus facile de le mettre simplement dans la fig.yml

Je pense que les deux options peuvent être complémentaires; utilisez le nom de fig.yml par défaut si le nom n'est pas remplacé par un indicateur ou une variable d'environnement. Mettez le nom qui est réellement utilisé pour _démarrer_ le projet dans le .fig/project-name

Le fait de pouvoir remplacer le nom du projet à partir des variables d'environnement permet de conserver ces variables uniques et prévisibles. Je pense que quoi qu'il arrive, nous devons prendre en charge le remplacement des variables d'environnement.

Curieuse; comment gérez-vous la gestion de plusieurs projets? Ie cd project-a && fig ps puis cd project-b fig <something> ?

Merci pour vos commentaires!

Curieuse; comment gérez-vous la gestion de plusieurs projets?

Je lance généralement fig partir de python-tox , ce qui me permet de définir l'environnement, donc je ne le configure jamais vraiment dans mon shell. J'ai aussi tendance à utiliser tmux, donc j'ai des shells différents pour chaque projet.

Je pense que les deux options peuvent être complémentaires

Cool, je suis d'accord.

Je ne sais pas si je suis vendu sur .fig/instance-name vs disons .fig-instance.yml qui pourrait contenir des remplacements spécifiques à une instance, mais je pense que c'est plus un point mineur.

En pensant au nom du projet; Si je comprends bien votre situation, il est important de pouvoir contrôler les _images_ produites, par exemple myapp:build12345 , ou également les noms des _conteneurs_? Juste pour avoir une "idée" de votre situation.

Ma pensée derrière les noms de projets "aléatoires" était que, tant que Fig est capable de localiser les conteneurs pour un projet, les noms attrayants ne sont pas importants. Si, en tant qu'utilisateur, je peux accéder au conteneur d'un service via son nom de service (par exemple fig stop web ), le nom du conteneur réel n'a pas d'importance.

J'ai même pensé que fig pourrait garder une trace des conteneurs par ID dans un stockage local à l'intérieur du répertoire .fig (ce qui pourrait être un gain de performance sur les machines avec beaucoup de conteneurs en cours d'exécution). Mais c'est vraiment quelque chose pour une question distincte.

Des réflexions sur la création "implicite" du fichier 'project-name' ou "explicitement" via fig init ? Peut-être que si j'ai un peu de temps pendant les vacances à venir, je peux expérimenter un peu (jamais rien codé en Python, donc ce sera _ vraiment_ expérimental :))

il est important de pouvoir contrôler les images produites, par exemple myapp: build12345 , ou aussi les noms des conteneurs?

Je suppose que l'image est la plus importante, mais être en mesure de garantir que les noms de conteneurs ne sont pas en conflit est également très important sur les hôtes partagés. Je vois que cette proposition vise en fait à traiter cette question également.

Mais je pense que les noms prévisibles des conteneurs sont toujours importants. Je peux penser à quelques tâches où il est important pour les systèmes externes (pas seulement fig) de pouvoir identifier un conteneur par son nom:

• scripts de nettoyage pour supprimer les anciens conteneurs, être capable d'identifier quel projet a créé un conteneur
• débogage / inspection des conteneurs

Les deux sont assez faciles pour le moment car je sais déjà quel sera le nom du conteneur. Si je dois chercher un nom, c'est un peu plus compliqué.

J'ai même pensé que fig pourrait garder une trace des conteneurs par ID dans un stockage local à l'intérieur du répertoire .fig

Il est vrai que cela pourrait être un gain de performances, mais je crains que ce ne soit la mauvaise approche. L'ajout d'un état persistant à fig introduit la possibilité de nombreux bogues (qui accompagnent l'état). Je préférerais de beaucoup voir cela géré par un système d'étiquetage dans dockerd. Si fig est capable d'étiqueter simplement les conteneurs, puis de rechercher tous les conteneurs avec cette étiquette, il conserve tout l'état en un seul endroit (dockerd). Je sais qu'on en a parlé à un moment donné, je ne sais pas si cela figure sur la feuille de route.

Des réflexions sur la création "implicite" du fichier 'project-name' ou "explicitement" via fig init?

Je suppose que ce serait implicitement plus compatible avec les versions antérieures. Je voudrais éviter un fig init sauf si c'est absolument nécessaire. Au lieu d'utiliser le basedir, je pouvais le voir créer implicitement un nom de projet de <basename>-<4 digit random id>

Je peux seulement dire que si fig commence à générer des noms aléatoires maintenant, je vais m'en éloigner car je lance plus de 1000 conteneurs sur un seul hôte et quand je ne peux plus les identifier par leur nom, ce n'est plus rien pour moi.

@ frank-dspeed merci d'avoir ajouté votre cas d'utilisation. Si je comprends bien, vous _démarrez_ vos conteneurs avec fig, mais _ les "gérez" _ directement via Docker après cela, en utilisant la convention de dénomination que Fig utilise?

Peut-être que cela vous intéresse également: https://github.com/docker/docker/pull/9882 - avoir des méta-données offrirait plus de façons d'identifier les conteneurs, pas seulement leur nom.

ah oui j'ai beaucoup fait de telles propositions, par exemple en ajoutant simplement de nouveaux filds et ça mais j'ai fini dans ce cas avec simplement ajouter un ENV et puis j'ai ça comme costum fild je peux l'analyser: dart:

Je pense que la gestion de la clarté du nom du projet ne devrait pas être la responsabilité de fig.

lorsque j'ai bien compris votre proposition, la génération d'un nom aléatoire rendrait les options FIG_PROJECT_VARIABLE et --project-name inutiles. ce qui est pratique pour les services de «création de modèles».

Je pense que la gestion de la clarté du nom du projet ne devrait pas être la responsabilité de fig.

Je ne suis pas si sûr; Fig "silencieusement" écraser les conteneurs d'un autre projet parce que s'il se trouve dans un répertoire avec le même nom est parfois désagréable.

quand j'ai bien compris votre proposition, la génération d'un nom aléatoire rendrait la FIG_PROJECT_VARIABLE et l'option --project-name-option inutiles. ce qui est pratique pour les services de «création de modèles».

Suite à la discussion ci-dessus, je pense que quelque chose comme ça fonctionnerait

• Si --project-name est fourni, utilisez-le (et écrivez / mettez à jour le .project-name ? Pas sûr)
• Aucun --project-name n'est fourni, mais FIG_PROJECT_NAME est, utilisez FIG_PROJECT_NAME (et écrivez / mettez à jour vers .project-name ?)
• Aucune des réponses ci-dessus, mais .project-name est défini, utilisez .project-name
• Aucune de ces réponses; créez un nom _ aléatoire_ et écrivez-le dans .project-name

du point de vue de quelqu'un qui utilise fig dans des scripts qui prennent soin d'un nom et le transmettent à fig, stocker un nom dans l'emplacement du projet (qui est dans mon cas plutôt un modèle) n'a aucun sens.

et pourtant, j'ai senti très intuitivement que le nom du répertoire est utilisé dans le nom des conteneurs résultants lorsque je viens de lancer fig up .
et disons, vous regardez docker ps -a , ce ne sera pas très utile s'il est rempli de noms aléatoires.

Une option --random-name aiderait-elle dans votre situation?
à côté de cela, je pense que la possibilité d'ajouter des [a-zA-Z0-9_].* pour refléter un certain espace de noms serait utile pour des déploiements plus larges.

Pourquoi ne pas utiliser fig.yml pour stocker de telles informations?

schema-version: 1.1
project_name: foo
containers:
  web:
    build: .
   command: python app.py
    links:
     - db
    ports:
     - "8000:8000"
  db:
    image: postgres

Et pour garder BC, dans compose / project.py :: from_config

<strong i="9">@classmethod</strong>
    def from_config(cls, name, config, client):
        if 'schema-version' not in config:
            config = {
                'schema-version': '1.0',
                'containers': config
            }
        dicts = []
        for service_name, service in list(config.containers.items()):
            if not isinstance(service, dict):
                raise ConfigurationError('Service "%s" doesn\'t have any configuration options. All top level keys in your docker-compose.yml must map to a dictionary of configuration options.' % service_name)
            service['name'] = service_name
            dicts.append(service)
        return cls.from_dicts(name, dicts, client)

@jderusse Je suis très

de toute façon en venir à une résolution sur ce billet? Il semble que le # 1233 proposé vous donne le meilleur des deux mondes en laissant l'utilisateur décider de l'action envisagée à entreprendre sans rompre la rétrocompatibilité.

À l'origine, je voulais le nom dans le docker-compose.yml , mais après y avoir réfléchi davantage, j'aime beaucoup l'idée d'un fichier séparé.

Un fichier séparé vous donne la possibilité de le garder hors du contrôle de version si vous le souhaitez (pour les cas où vous souhaitez que chaque utilisateur puisse avoir un nom de projet différent).

Avec le nouveau support réseau, il y a une demande de fonctionnalité pour pouvoir également configurer le nom du réseau (il est par défaut le nom du projet). Donc, avec un fichier de configuration séparé, nous pourrions inclure des éléments comme le nom du réseau par défaut, l'échelle par défaut, etc. Toute la méta-configuration qui ne fait pas partie de la définition de l'application, mais qui est toujours pertinente pour l'exécution de la composition.

Je suis d'accord avec ce qu'a dit Dnephin. Que diriez-vous d'un fichier .docker-compose ? Nous pourrions y lister les options par défaut pour tous les arguments de ligne de commande.

@dnephin sgtm

@mikehaertl J'ai utilisé un dossier .docker-compose dans mon exemple, mais un fichier pourrait également fonctionner, en fonction de la quantité d'informations que nous voulons stocker

@thaJeztah Oh, d'accord, désolé. J'ai manqué ça.

@mikehaertl vient de les renommer de .fig à .docker-compose ;-)

Droite :)

En fait, je préfère un simple fichier. Et le style ini? Options globales en haut, commande des options spécifiques dans une section:

project-name = blabla

[build]
no-cache

Quelques idées d'informations semi-liées que nous souhaitons peut-être stocker soit dans le même fichier, soit dans le même répertoire:

• nom du réseau (les utilisateurs peuvent souhaiter un nom de réseau différent du nom du projet. Nous avons déjà reçu une demande pour cela.)
• version de l'api du client
• hôte docker
• valeur d'échelle par défaut

Maintenant que nous prenons en charge plusieurs fichiers de composition, il peut également être intéressant d'inclure les chemins vers les fichiers de composition à utiliser comme configuration.

version de l'api du client

éventuellement docker_host ?

Cela sonne aussi bien (ajouté)

Je viens de rencontrer ce problème.

J'en suis à un point où la structure de base de notre configuration de docker a été réglée, et maintenant je la réplique vers d'autres services. Puisque tous les projets ont la même structure, ils utilisent tous le même sous-répertoire (et par conséquent, le nom de projet par défaut). Ce qui signifie que je ne peux pas mettre en file d'attente en toute sécurité 2 services sur le même hôte.

Il se peut que je doive changer la structure pour que le nom du répertoire du projet soit la valeur par défaut, mais je ne suis pas sûr à 100% de ce que cela fait de la copie de fichiers au moment de la création de l'image.

Idem ici, j'ai résolu un problème similaire avec les cibles Makefile . Mais quand même, lorsque vous souhaitez exécuter des commandes personnalisées docker-compose , vous devez utiliser -p customname .

En ce moment, j'essaie de comprendre comment empêcher les configurations de docker-compose dans /home/alice/myproject et /home/bob/myproject de marcher sur les conteneurs de l'autre. Existe-t-il un moyen de dériver les noms de conteneurs à partir du chemin d'accès complet au fichier au lieu du seul nom du dernier répertoire?

@ chris-martin Ceci est juste une solution de contournement ...

alias docker-compose="docker-compose -p ${PWD}"

docker-compose supprime / des noms de projet, cependant?

Les caractères autorisés dans les noms de projet sont-ils documentés?

J'ai fini par changer la structure de mes répertoires et mettre docker-compose.yml à la racine du projet, ce qui est une solution de contournement assez décente

Cela accorde une certaine protection, si vous avez tendance à mettre tous vos référentiels git dans le même répertoire (par exemple, $ HOME ou $ HOME / projects), mais cela devient gênant si vous utilisez une autre structure (par exemple, un répertoire par organisation, comme je souvent), ou si votre machine utilise boot2docker, qui a tendance à divulguer des informations entre les utilisateurs sur la même boîte, à moins que vous ne veilliez à ce que docker-machine vous donne des VM distinctes.

Je pense que # 2294 ou simplement être plus hygiénique avec docker-machine résoudrait également mes problèmes.

Je recommanderais également de le mettre à la racine du projet et d'avoir un nom de dossier différent.

Dans mon cas, j'aimerais définir le nom initial du projet car j'ai une machine partagée sur AWS et bien que j'ai le docker-compose.yml à la racine, un utilisateur peut cloner le référentiel dans un répertoire avec un nom différent. Si cela se produit actuellement, ils rencontrent des problèmes pour démarrer / arrêter les conteneurs.

Avec la nouvelle syntaxe v2 cela pourrait être implémenté comme mentionné dans https://github.com/docker/compose/issues/745#issuecomment -74028861

C'est en fait juste un container_name_prefix , n'est-ce pas?

@ schmunk42

C'est en fait juste un préfixe nom_conteneur, n'est-ce pas?

Il est également utilisé comme volume_name_prefix , image_name_prefix et network_name_prefix , donc je suppose que project_name est un terme plus générique.

.docker-compose semble familier à docker-compose.override.yml à bien des égards. De plus, pourquoi introduire un autre format de configuration (par exemple ini) alors que nous avons déjà YAML?
Je suis donc favorable à la suggestion de # 745 (commentaire) d'ajouter une clé project_name au docker-compose.yml , pour activer le cas d'utilisation de @JosephEarl.

La personnalisation spécifique à l'utilisateur peut déjà être implémentée en utilisant docker-compose.override.yml et en l'excluant via .gitignore .
Si un troisième fichier de remplacement explicitement spécifique à l'utilisateur est souhaité, je suggérerais .docker-compose.local-override.yml .

En ce qui concerne la structure du YAML, je suggère de créer une nouvelle clé de niveau supérieur appelée project , qui contient project_name , et pourrait contenir d'autres variables à l'avenir. Cela évite de polluer l'espace de noms de niveau supérieur. Pour illustrer:

project:
  project_name: "your-project"
  network_prefix: "abc"

Notez qu'au lieu d'utiliser network_prefix , il peut être plus compréhensible de personnaliser directement les noms des réseaux eux-mêmes. Si je comprends bien, il y a deux cas:

• Le premier cas est "donnez simplement aux réseaux un nom unique, mais je me fiche de celui qui est exactement". Dans ce cas, project_name suffit.
• L'autre cas concerne les réseaux auxquels se réfèrent des systèmes externes. Dans ce cas, il est probablement préférable de spécifier explicitement les noms de réseau eux-mêmes.

La proposition suggérée ci-dessus me semble bonne, je suis d'accord que nous ne voulons pas introduire de fichiers de configuration supplémentaires

+1 sur le concept de ce numéro
Mais aussi +1 sur l'utilisation d'une clé dans docker-compose.yml au lieu d'ajouter un autre fichier à nos dépôts.

Pour résumer les commentaires précédents: Une proposition pour la séquence de recherche du nom du projet serait la suivante; les éléments précédents ont priorité sur les suivants:

1. Utilisez --project-name si spécifié
2. Utilisez COMPOSE_PROJECT_NAME si spécifié.
3. Utilisez la clé project_name partir de docker-compose.yml (ou partout où ce paramètre est stocké).
4. Utilisez le basename du répertoire du projet

Je ne suis pas sûr de la priorité de 2 contre 3:

• Par souci de cohérence avec --project-name , COMPOSE_PROJECT_NAME devrait définitivement remplacer project_name: .
• Mais: Faire de COMPOSE_PROJECT_NAME priorité sur project_name: permet d'utiliser accidentellement le mauvais nom de projet en raison de la variable d'environnement définie; cela peut être difficile à déboguer. Peut-être qu'un message d'avertissement peut poser problème dans ce cas?

Pourquoi ne pas introduire une nouvelle propriété container_name_pattern avec la valeur par défaut %(project_name)s_%(service_name)s_%(instance_number)s pour conserver BC
ce paramètre nous permet de le changer en hardcodedproject_%(service_name)s_%(instance_number)s et de résoudre définitivement ce problème

Je viens d'arriver ce problème après avoir recherché cette fonctionnalité pendant 10 minutes.

La première chose que j'ai faite a été de rechercher la bonne clé dans le document de référence de fichier de composition, donc +1 pour project_name clé dans docker-compose.yml

: +1: pour la stratégie @ cr7pt0gr4ph7

+1 pour la stratégie @ cr7pt0gr4ph7

Compose a une syntaxe pour la substitution d'environnement. Plutôt que d'utiliser une variable d'environnement pour le nom du projet, peut-être laisser les gens le faire eux-mêmes s'ils s'en soucient?

D'un autre côté, la machine docker utilise la fin pour décider sur quelle machine une compilation de composition sera construite, donc peut-être que le nom du projet et la cible devraient fonctionner de la même manière. Hmm, c'est difficile.

https://github.com/docker/compose/issues/745#issuecomment -182296139 sonne bien. La variable d'environnement a priorité sur la valeur du fichier de composition, qui agit par défaut (en supposant que le nom du projet appartient au fichier de composition).

Quelque chose à considérer, que se passe-t-il lorsque vous utilisez plusieurs fichiers de composition qui définissent chacun un nom de projet?

Je ne pense pas que ce devrait être une erreur, qui forcerait les fichiers à être soit "primaires", soit "extras", ce qui n'est pas le cas actuellement. Tout fichier peut être utilisé isolément ou en combinaison avec d'autres.

Peut-être qu'un avertissement est raisonnable, ou peut-être que nous l'ignorons complètement (puisque la valeur peut être ignorée en définissant également une option ou une variable d'environnement).

Quelque chose à considérer, que se passe-t-il lorsque vous utilisez plusieurs fichiers de composition qui définissent chacun un nom de projet?

Si vous faites quelque chose comme docker-compose -f compose1.yml -f compose2.yml up et que les deux fichiers définissent le nom du projet, le nom utilisé doit être de compose2.yml .

Je pense que tout le monde est sur une solution que j'aime déjà: -) Ie project_name dans docker-compose.yaml. Je veux juste mentionner un autre cas d'utilisation pour avoir le nom du projet dans le fichier docker-compose.yaml:

Dans les pages HTTP 500 Internal Server Error de mon projet, je dis au développeur comment résoudre ou dépanner le problème, par exemple je lui dis qu'il / elle peut zcat database-dump.tgz | docker exec -i projectname_db_1 psql si le serveur remarque qu'aucune base de données PostgreSQL et l'utilisateur a été créé - et ensuite je veux choisir moi-même projectname , sinon les messages d'aide ne peuvent pas être copiés dans la console.

Acceptez qu'il devrait y avoir un avertissement lorsque COMPOSE_PROJECT_NAME remplace le nom du projet dans le compose.yml - ce comportement est logique en fonction des commandes Docker existantes, mais n'est pas particulièrement logique ou évident pour un nouveau venu.

+1 pour la stratégie @ cr7pt0gr4ph7

J'ai essayé de chercher quelque chose avant d'ouvrir un problème moi-même car je ne trouvais rien.
+1 pour project_name dans le fichier docker.compose.yml. Avec la v2, je suppose que cela a de plus en plus de sens.

Acceptez qu'il devrait y avoir un avertissement lorsque COMPOSE_PROJECT_NAME remplace le nom du projet dans le compose.yml - ce comportement est logique en fonction des commandes Docker existantes, mais n'est pas particulièrement logique ou évident pour un nouveau venu.

C'est un comportement assez normal pour les variables d'environnement de remplacer les paramètres de configuration et pour les arguments de ligne de commande de remplacer les paramètres de configuration et les variables d'environnement.
Avons-nous vraiment un avertissement pour cela? Ce n'est pas comme si quelqu'un créait accidentellement une variable d'environnement nommée COMPOSE_PROJECT_NAME .

Serait-il acceptable de créer un PR qui utilise simplement le project_name de docker-compose.yml pour y arriver? Ou voulons-nous des trucs supplémentaires comme l'utilisation de la project_name du dernier fichier yml référencé immédiatement?

Que dis-tu de ça?

version: "2"
project:
    default_name: "app"

Je changerai mon implémentation (https://github.com/docker/compose/pull/3118) pour ce format. Mais je ne suis pas sûr que la section project soit nécessaire ....

+1 être désireux de voir cette fonctionnalité

@timgriffiths , il semble que cela soit possible dans la dernière RC en ajoutant un fichier d'environnement à votre projet:

• https://docs.docker.com/compose/env-file/
• https://github.com/docker/compose/releases/tag/1.7.0-rc1

@deizel J'ai donc regardé le fichier d'environnement, mais je pense toujours qu'il y a un bon cas d'utilisation pour pouvoir définir le nom du projet dans le fichier de composition.

Dans notre situation, nous avons Prod, Staging, UAT, Dev composent des fichiers juste pour que nous puissions démarrer une version différente de notre pile d'applications, et parfois nous voulons mettre en place un environnement Staging et UAT sur le même essaim, afin que je puisse utiliser l'environnement variables ou quoi que ce soit, mais cela dépend de l'utilisateur qui se souvient tous de définir cela, où, comme si c'était dans le fichier de composition, tout serait archivé dans le dépôt et nous pourrions tout garder en ligne et simple à expliquer à tous les utilisateurs.

+1 Nous avons une situation où notre fichier de composition a des références à des volumes distants préconfigurés. Compose ajoute automatiquement le nom du projet aux noms de volume dont le montage échoue en raison de noms incompatibles. Le fait de pouvoir définir explicitement le nom du projet dans le fichier yml de composition rendrait la convention de dénomination beaucoup plus évidente pour les autres personnes impliquées dans le projet plutôt que de masquer les variables d'environnement dans des fichiers externes obscurs qui pourraient varier d'un environnement à l'autre.

@edevenport dans votre cas, vous pouvez utiliser l'option externe des volumes nommés:

# docker-compose.prod.yml
volumes
  dbdata:
    external:
      name: my-project-db-data

Merci @fesor - J'aurais dû entrer plus en détail. Je suis en train de monter des volumes glusterfs en utilisant une configuration similaire à celle-ci:

    ...
    volumes:
      - media:/data/media:ro

volumes:
  media:
    driver: glusterfs

Dans ce cas, media devient projectname_media sur l'hôte et ne parvient pas à monter à moins que le volume glusterfs ne soit créé à l'avance avec le nom du projet. J'avais pensé monter manuellement les volumes glusterfs sur l'hôte et utiliser external dans le fichier docker-compose, mais je préférerais ne pas avoir à le faire manuellement sur tous les nœuds à l'avance.

@edevenport Je comprends cela. Mais vous pouvez simplement ajouter ce volume manuellement avec docker volume create et l'utiliser:

    volumes:
      - media:/data/media:ro

volumes:
  media:
    external:
      name: my-glusterfs-media

Il n'est donc pas nécessaire de changer de projet et de supprimer les préfixes.

Le cas de @timgriffiths est quelque chose de plus complexe, et il n'a aucune solution de contournement. J'utilise un wrapper simple autour de docker-compose juste pour ne pas me souvenir des noms de projet.

@fesor donc nous avons contourné le problème en collant simplement les fichiers de composition dans des noms de dossier descriptifs, cela contourne cette limitation. Mais ce serait très agréable de le voir ajouté dans les versions ultérieures

@timgriffiths J'ai fait un PR (https://github.com/docker/compose/pull/3118) - peut-être que cela aiderait. Mais cela ne gère pas votre cas si vous avez plusieurs fichiers de composition.

@fesor que les relations publiques seraient parfaites, est-ce une possibilité de les fusionner?

Maintenant, Compose fournit un fichier d'environnement , de sorte que le nom du projet peut y être conservé.

@mkuzmin c'est triste qu'il y ait COMPOSE_FILE mais il n'y a pas de COMPOSE_OVERRIDE_FILE .

@fesor AFAIK vous pouvez spécifier plusieurs fichiers

@ schmunk42 Je pourrais spécifier le nom du projet non plus. Mais cela ne résout pas le problème. Je veux avoir dans le script de déploiement quelque chose comme ceci:

docker-compose up -d

au lieu de

docker-compose -f $COMPOSE_FILE -f $COMPOSE_OVERRIDE_FILE \
            up -d

COMPOSE_PROJECT_NAME dans l'exemple ci-dessus est spécifié par CI. Et une fonctionnalité comme .env file est cool mais ... inutile en cas de persistance du nom du projet.

J'utilise .env pour DRY env variables (et pour docker-compose <1.7 j'ai un simple wrapper), mais cela ne résout aucun autre problème. @timgriffiths a déjà souligné le cas avec déploiement sur un cluster d'essaim.

COMPOSE_FILE=one.yml:two.yml explique comment définir plusieurs fichiers. Donc, incluez simplement le fichier de remplacement dans $COMPOSE_FILE

@dnephin a raté cette fonctionnalité, cool.

Eh bien ... à propos du déploiement swarm, je gère déjà cela via COMPOSE_PROJECT_NAME dans les variables ENV de mon travail de jenkin, donc des problèmes uniquement avec le déploiement manuel. Et mon implémentation ne permet pas de remplacer le nom de projet par défaut, donc ...

Ce problème date de presque 2 ans et n'est toujours pas résolu. Je me demande ce qui empêche l'équipe des dockers d'ajouter enfin un correctif approprié. Est-il vraiment si difficile d'ajouter une nouvelle directive de configuration simple pour les fichiers docker-compose.yml ?

Bien que la solution de contournement avec .env soit agréable, elle n'est pas toujours utilisable (le fichier .env peut déjà être utilisé par votre application). Et c'est aussi toujours une solution de contournement.

Et j'ai même vu d'autres nouveaux problèmes qui peuvent être liés au nom du projet s'insinuer dans les dernières versions (# 3966).

Alors, quel est vraiment le problème?

Est-il vraiment si difficile d'ajouter une nouvelle directive de configuration simple pour les fichiers docker-compose.yml ?

Non! Le problème n'a jamais été la difficulté de mise en œuvre.

Bien que la solution de contournement avec .env soit agréable, elle n'est pas toujours utilisable (le fichier .env peut déjà être utilisé par votre application). Et c'est aussi toujours une solution de contournement.

Ce n'est pas une solution de contournement, c'est une solution! Le fichier .env contient des variables d'environnement qui doivent être lues par Compose. Si vous avez des variables d'environnement qui doivent être lues par votre application, placez-les dans un autre fichier (disons app.env ) et référencez-le en utilisant l'option env_file .

Alors, quel est vraiment le problème?

L'ajout du nom du projet à un fichier docker-compose.yml le rend moins portable, ce que nous ne voulons pas encourager. Maintenant qu'il existe un moyen (avec .env ) de spécifier de manière persistante le nom du projet sans sacrifier la portabilité de docker-compose.yml , le cas pour l'ajouter en tant qu'option de configuration est plus faible. C'est la principale raison pour laquelle ce problème n'a pas bougé.

L'ajout du nom du projet à un fichier docker-compose.yml le rend moins portable,

Cela ne pourrait-il pas être facultatif? Personnellement, je ne vérifie jamais mon docker-compose.yml mais je ne fournis qu'un docker-compose-example.yml dans mon repo que je peaufine localement. Par exemple, pendant le développement, je peux ajouter des variables d'environnement supplémentaires ou mapper des volumes supplémentaires dans mon conteneur. Pourquoi ne pas nous donner également la possibilité de spécifier le nom du projet?

Suite à votre argumentation, vous devez également déplacer toutes les options network vers .env car elles ne sont généralement pas du tout portables et dépendent de la configuration réseau de votre machine hôte.

En d'autres termes: qu'est-ce qui rend le nom du projet si spécial? Il existe déjà de nombreuses autres options dans le docker-compose.yml qui ne sont pas vraiment portables. Pourquoi ne pas donner au développeur la possibilité de choisir ce qui convient le mieux à son cas d'utilisation?

Je pense également que l'option devrait être offerte. À mesure que l'utilisation de Docker se répand, les projets avec un seul développeur utilisant la conteneurisation dans leur flux de travail deviendront de plus en plus courants. Dans ces cas d'utilisation, le nom du projet étant constant est très bien. Un bon exemple d'un autre projet permettant une telle flexibilité est vagabond avec leur Vagrantfile . Ils se rendent compte qu'il existe certainement des cas d'utilisation pour les grandes équipes, mais reconnaissent également les scénarios de développeur de loup solitaire.

Je pense que la mise en œuvre d'une option de nom de projet ici est importante pour l'adoption. Cela pourrait décourager les développeurs solo qui ne se soucient pas d'une "stratégie de configuration de nom de projet évolutive".

L'ajout du nom du projet à un fichier docker-compose.yml le rend moins portable, ce que nous ne voulons pas encourager. Maintenant qu'il existe un moyen (avec .env) de spécifier de manière persistante le nom du projet sans sacrifier la portabilité de docker-compose.yml, les arguments pour l'ajouter en tant qu'option de configuration sont plus faibles. C'est la principale raison pour laquelle ce problème n'a pas bougé.

Comment l'ajout du nom du projet au docker-compose.yml rend-il moins portable?

IMHO c'est en fait le contraire, comme le montre # 3966 créé par @mikehaertl. Ce problème montre clairement que ne pas avoir le nom du projet stocké dans docker-compose.yml rend les choses en fait moins portables (comme dans: avoir une plus grande probabilité d'entrer en conflit avec d'autres projets de composition démarrés à partir de la même machine) puisque Compose repose sur une convention sur le nom du dossier du conteneur que beaucoup de gens, du moins au début, ne connaîtront pas.

L'ajout d'un fichier .env ajoute non seulement une chose supplémentaire à apprendre pour les nouvelles personnes qui souhaitent adopter Compose, mais puisque je devrais également l'ajouter à mon repo à côté de docker-compose.yml pour éviter cela collisions Je ne vois pas en quoi ce serait différent du point de vue de la portabilité que de simplement définir le nom du projet dans docker-compose.yml .

Je suis également pour ajouter le nom dans docker-compose.yml. Le fichier .env est utilisé dans d'autres frameworks que j'utilise et il est important qu'il reste hors du référentiel. Cependant, pour maintenir des conteneurs localisés dans mes développeurs, moins ils en savent sur docker (au début), mieux c'est. Je veux un point d'entrée simple qui n'entrera pas en conflit avec d'autres projets. Je ne veux pas expliquer pourquoi les choses sont telles qu'elles sont. Juste un simple

clone repo
docker-composer

Ma solution de contournement consiste maintenant à créer le fichier proposé par @ schmunk42 .

Le conteneur lui-même ne devrait pas se soucier du nom du projet. Pourquoi utiliser les variables d'environnement comme un mécanisme uniquement destiné à l'hôte?

J'adorerais voir le support pour cela dans le fichier docker-compose.yml . Si on a besoin de le définir via une variable d'environnement, il peut être défini dans le fichier .env (s'il n'est pas défini directement sur l'hôte) et utilisé via une substitution de variable dans le fichier docker-compose.yml .

Si les conteneurs nommés sont autorisés, pourquoi les projets nommés ne seraient-ils pas autorisés?

Le cas d'utilisation où une définition de nom de projet dans le fichier .yml serait utile est le suivant:
Nous avons le même fichier docker-compose pour différents serveurs Web (différentes informations d'identification de base de données, différents volumes de données, quelques petites différences comme le logo, etc.). Il existe 3 services par application en cours d'exécution, et ils sont configurés dans un fichier de composition. Lorsque plusieurs serveurs sont exécutés l'un à côté de l'autre, il serait bien de voir quel service appartient à quel projet.

La substitution de variable dans le nom du conteneur est pratique, avec le $ COMPOSE_PROJECT_NAME comme préfixe. Eh bien, je comprends la solution .env-file, mais cela ne la rend pas plus «conviviale pour les développeurs» dans un environnement de déploiement (CI).

Avoir un conteneur de kill docker-compose d'un docker-compose totalement différent parce qu'il n'y avait pas de jeu de variables -p ou d'environnement et que vous avez créé le docker-compose dans un sous-dossier "docker" est un bogue critique à mon avis.

Il y a tout simplement trop de place pour l'erreur dans les déploiements sérieux. Oubliez simplement de spécifier le nom du projet, que ce soit dans -p, .env ou ailleurs: vous vous déconnectez pendant un certain temps jusqu'à ce que vous remarquiez ce qui s'est passé. Pire encore: le service en collision est déconnecté, pas celui sur lequel vous travaillez. Vous passerez une bonne journée :(

@dnephin Qu'est-ce qui

Peut-être suis-je le seul ici à avoir des inquiétudes à ce sujet, mais quoi qu'il en soit.
Dans notre configuration, nous modifions uniquement les fichiers .env et app.env pour changer d'environnement, mais cela repose sur le fait d'avoir plusieurs fichiers et de fusionner les fichiers yml .

Si cela est mis en œuvre, pensez à BC.

Par exemple. si un nom de projet est défini dans docker-compose.yml et .env ce dernier doit avoir la priorité. Sinon, les personnes qui comptent sur la gestion de cela via .env , rencontrent des problèmes similaires avec des piles qui se chevauchent, comme avec le flux de travail actuel et en s'appuyant sur les noms de dossier.

@ schmunk42 Nous ne disons pas que la fonctionnalité .env doit être supprimée. Si vous préférez avoir le nom de votre projet dans .env ne le configurez tout simplement pas dans docker-compose.yml .

Mais d'autres préfèrent l'avoir dans leur docker-compose.yml comme le montre clairement la discussion ici. Ils devraient pouvoir le faire, s'ils le souhaitent. C'est une fonctionnalité facultative. Ce qui prévaut si les deux sont configurés est une question de définition d'une convention simple.

Srsly, veuillez ajouter des projets nommés. Cas d'utilisation:
Projet un:
docker-compose up --build --remove-orphans

• nginx
• contenu statique
  Projet deux:
  docker-compose up --build --remove-orphans
• nginx
• contenu statique

Lorsque le projet 2 démarre, il tue les conteneurs du projet avec une sortie 137 (code 128 + niveau 9).

Maintenant, je dois exécuter docker system prune et reconstruire les réseaux chaque jour pour m'empêcher d'avoir des dizaines de conteneurs morts.

export COMPOSE_PROJECT_NAME=somethingnew

Quelqu'un de l'équipe principale peut-il enfin expliquer ce qui retarde cette fonctionnalité? C'est tellement frustrant, comment les choses qui sont si faciles à réparer sont bloquées sans raison.

Le seul argument jusqu'à présent était de garder le portable docker-compose.yml . Cela n'a aucun sens, car

• le nom du projet dans le fichier du compositeur ne le rend plus automatiquement portable
• tout le monde n'a même pas cette exigence
  
  
  
  • nous avons déjà d'autres options qui peuvent limiter la portabilité de la même manière: networks , port , ...
  
  

Tout dépend beaucoup du cas d'utilisation spécifique. Mais ce n'est pas parce que certains ne veulent pas de cette option que tout le monde doit suivre son opinion!

@mikehaertl Vous avez déjà des noms de projet persistants. Il suffit de mettre le fichier .env et d'y définir la variable COMPOSE_PROJECT_NAME . Je ne vois plus aucun avantage dans le nom du projet dans le fichier de composition.

@fesor Je n'ai généralement pas .env fichiers docker-compose.yml .

@fesor : Je pense que @thasmo a raison à ce sujet. Le nom du projet doit avoir la possibilité d'être spécifié dans le fichier compose.yml car s'il est pertinent pour tous les développeurs utilisant le projet, il doit être dans le contrôle de version.

@fesor Je suis désolé, mais je ne pense pas que la préférence personnelle soit un véritable argument. La vraie question n'est pas de savoir pourquoi nous ne voulons pas utiliser .env ou une variable d'environnement. C'est l'inverse: pourquoi n'a-t-il pas été mis dans le fichier de configuration à sa place?

Presque toutes les options que vous pouvez passer à docker sur la ligne de commande peuvent être spécifiées dans ce fichier. Seul le nom du projet est exclu pour certaines raisons mystérieuses. Est-ce une forme d'apartheid parmi les arguments? : PI revendique l'égalité des droits pour tous! Laissez le développeur décider et ne lui imposez pas de contraintes artificielles.

Et encore: personne ne vous enlève l'ancienne option - nous ne voulons finalement que cette option supplémentaire. C'est juste.

@dnephin : Il semble que vous et tout le monde êtes satisfaits de la solution indiquée dans le raffinement de ce problème par

Seriez-vous prêt à accepter une pull request qui l'implémente, ou avez-vous l'intention de demander à l'un des responsables de l'écrire?

@ cr7pt0gr4ph7

@dnephin @fesor ayant le nom du projet dans le * compose.yml facilite un schéma de configuration unifié

Je ne vois pas pourquoi le nom du projet est important. Aucune partie du fichier de configuration ne doit reposer sur un nom de projet spécifique.

La seule qualité importante du nom du projet est qu'il n'est pas en conflit avec le nom d'un autre projet, ce qui est en fait un argument contre son insertion dans le fichier docker-compose.yml . Un développeur sur un projet utilisera souvent un nom de répertoire différent pour chaque projet, donc la valeur par défaut est souvent correcte pour la plupart des cas d'utilisation.

Lorsque la valeur par défaut n'est pas correcte, le développeur peut la remplacer ( -p , ou COMPOSE_PROJECT_NAME ), qui peut être soit des alias, soit être placée dans le fichier .env .

Je ne suis pas contre un fichier de projet qui définirait le nom du projet, je voudrais juste comprendre pourquoi cette fonctionnalité est si critique pour certains. Si c'est parce que le fichier Compose nécessite un nom de projet spécifique, je vois cela comme un problème distinct qui devrait être traité différemment,

Je voulais avoir 4 fichiers de composition dans 1 répertoire. Le nom du répertoire est incorrect par défaut ici. La seule option que j'ai est .env qui ne fonctionne que pour 1 fichier de composition dans 1 répertoire.

_Pourquoi j'écarte COMPOSE_PROJECT_NAME et -p: _
Le COMPOSE_PROJECT_NAME et le -p ne sont pas à mon avis sauvegardés en production car vous devez vous rappeler de les définir. Ou créez un script de démarrage et n'oubliez pas de ne pas utiliser directement la composition de docker. Lorsque la personne A s'appuie sur ce mécanisme et que la personne B ne le sait pas, c'est un certain échec.
(Je l'ai déjà détaillé ci-dessus)

@dnephin Pour moi et mon équipe, la logique d'application est généralement stockée dans un dossier htdocs dans notre dossier de projet. Cela nous permet de conserver d'autres documents / ressources liés ensemble dans un même répertoire. En tant que développeur travaillant avec des développeurs distants. Il est facile pour moi de leur faire adopter Docker si je n'ai rien à assumer sur la structure de leurs dossiers. Je l'ai dit dans le passé, .env n'est pas une option pour moi car il ne fait généralement pas partie du repo que nous partageons tous.

Je ne vois pas pourquoi le nom du projet est important. Aucune partie du fichier de configuration ne doit reposer sur un nom de projet spécifique.

Il m'est arrivé plus d'une fois que j'ai fait un 'docker-composer vers le bas' sur un hôte - et j'ai fait descendre un conteneur différent de celui que je voulais! Juste parce que je ne me souvenais pas, qu'il y avait aussi une configuration dans un fichier .env .

La seule qualité importante du nom du projet est qu'il n'est pas en conflit avec le nom d'un autre projet, ce qui est en fait un argument contre son insertion dans le fichier docker-compose.yml. Un développeur sur un projet utilisera souvent un nom de répertoire différent pour chaque projet, donc la valeur par défaut est souvent correcte pour la plupart des cas d'utilisation.

C'est peut-être vrai pour vous - ce n'est pas pour moi et pour beaucoup d'autres. La structure de mon application est comme myapp/app/docker-compose.yml . Ainsi, toutes mes applications partagent le nom du répertoire app . Et j'ai plus d'un conteneur sur un hôte.

Lorsque la valeur par défaut n'est pas correcte, le développeur peut la remplacer (-p ou COMPOSE_PROJECT_NAME), qui peut être soit des alias, soit être placée dans le fichier .env.

Sérieusement, je commence à avoir l'impression d'être dans un roman de Kafka ici. N'est-il pas évident que vous pouvez mettre pratiquement toutes les options de ligne de commande pour docker dans un docker-compose.yml - à l'exception de cette seule grande exception?

Au lieu de nous demander encore et encore et d'ignorer nos réponses, pourquoi quelqu'un ne peut-il pas enfin justifier la résistance. Et non: "... mais je n'en ai pas besoin" n'est pas un argument valable!

@dnephin J'ai plusieurs projets dans leurs propres dépôts git et afin de garder les répertoires du projet racine propres, j'ai mis tous les éléments liés au docker dans un sous-dossier appelé docker (le contexte de construction devient simplement .. , tout fonctionne à merveille).

Pour exécuter plusieurs projets sur un seul serveur, je dois actuellement créer docker/.env.dist dans chaque repo et cp docker/.env.dist docker/.env après git clone . Sinon, le nom du projet est juste docker , ce que je ne veux évidemment pas. Dans quelques cas, .env contient des mots de passe, etc., donc la copie de .env.dist est de toute façon nécessaire, mais dans la plupart des cas .env existe simplement parce qu'il n'y a aucun moyen de définir COMPOSE_PROJECT_NAME en docker-compose.yml .

Je comprends qu'il peut y avoir des problèmes dans la manière dont les conteneurs sont démarrés et arrêtés si le même COMPOSE_PROJECT_NAME est utilisé deux fois dans docker-compose.yml , mais cela se produit déjà si j'oublie de copier .env.dist ou lorsque j'attribue accidentellement le même nom dans deux fichiers .env sur le même serveur. Pour moi, ce serait idéal si je pouvais définir default_compose_project_name droit dans docker-compose.yml , puis remplacer la valeur dans .env si, disons que je veux exécuter une copie intermédiaire d'un projet . Ce serait 100% BC, mais plus pratique.

Je l'ai dit dans le passé, .env n'est pas une option pour moi car il ne fait généralement pas partie du repo que nous partageons tous.

Peut-être que c'est la cause principale de tout cela, j'ai déjà dit que docker-compose "a détourné" ce fichier et nous avons été obligés de renommer nos trucs en app.env .

Peut-être que docker-compose.env aurait été le bon choix.

FWIW: Nous ne changeons que les fichiers .env en production, les fichiers yml sont fusionnés avec un docker-compose.override.yml si nécessaire.

Une solution de contournement consiste également à définir vos fichiers yml de manière à ce qu'ils ne démarrent pas sans un fichier .env , par exemple. en utilisant une variable image: $IMAGE .

Ceci est une solution de contournement pour mes 4 fichiers docker-compose dans 1 cas de répertoire ci-dessus @ schmunk42 ? Vraiment?

@RobIsHere Mais vous devez quand même utiliser -f , non?

En réponse à @dnephin dans ce commentaire :

Je ne vois pas pourquoi le nom du projet est important.

C'est important car cela affecte le nom des conteneurs Docker que docker-compose gère. Si vous oubliez de définir le nom du projet, docker-compose ps ne trouvera pas les conteneurs que vous avez créés auparavant avec docker-compose --project-name <project_name> up -d <container_name> .

De plus, lorsque vous exécutez la commande globale docker ps , le nom du projet sera inclus dans la liste des conteneurs en cours d'exécution, vous savez donc d'où ils viennent. Par exemple, si vous testez plusieurs projets de code à la fois qui utilisent tous MySQL et qu'ils ont chacun un conteneur mysql , alors docker ps affichera une liste ambiguë de conteneurs. Ainsi, le nom du projet est important dans le contexte de nombreux projets Docker s'exécutant sur la même machine.

Aucune partie du fichier de configuration ne doit reposer sur un nom de projet spécifique.

Devoir définir le nom du projet à un endroit différent de _toutes les autres variables associées au projet Docker Compose_ n'a pas de sens.

La seule qualité importante du nom du projet est qu'il n'est pas en conflit avec le nom d'un autre projet, ce qui est en fait un argument contre son insertion dans le fichier docker-compose.yml.

Pour les raisons exposées dans mon premier paragraphe, ce n'est pas la _ "seule qualité importante du nom du projet" _. C'est pour la facilité d'utilisation et la compréhension.

Un développeur sur un projet utilisera souvent un nom de répertoire différent pour chaque projet, donc la valeur par défaut est souvent correcte pour la plupart des cas d'utilisation.

Dans le cas autre que celui par défaut où un développeur place _tous_ les fichiers Docker liés dans le répertoire docker , ce qui est un moyen parfaitement raisonnable d'organiser un projet Docker, la magie qui définit le nom du projet créera des noms de projet en conflit. Ainsi, les mêmes conflits que vous évoquez se produisent dans ce cas particulier. Vous n'avez pas besoin de protéger le développeur contre les collisions de nom de projet lorsqu'il définit de toute façon explicitement le nom du projet.

Lorsque la valeur par défaut n'est pas correcte, le développeur peut la remplacer (-p ou COMPOSE_PROJECT_NAME), qui peut être soit des alias, soit être placée dans le fichier .env.

La définition des variables d'environnement est un niveau supplémentaire de complexité qui n'est pas nécessaire. Lorsque vous partagez un projet entre développeurs avec le contrôle de version, il est logique de n'utiliser que des fichiers. Avoir à inclure des paramètres de ligne de commande à chaque appel est fastidieux et sujet aux erreurs. Et le fichier .env ne peut pas être partagé dans le contrôle de version car il est censé contenir des variables spécifiques à l'utilisateur et non spécifiques au projet. Par conséquent, les méthodes actuelles pour définir un nom de projet sont insuffisantes.

Je ne suis pas contre un fichier de projet qui définirait le nom du projet, je voudrais juste comprendre pourquoi cette fonctionnalité est si critique pour certains. Si c'est parce que le fichier Compose nécessite un nom de projet spécifique, je vois cela comme un problème distinct qui devrait être traité différemment,

Toutes les variables qui affectent le fonctionnement de docker-compose doivent aller au même endroit, le fichier docker-compose.yml . Les méthodes actuelles de définition d'un nom de projet introduisent une complexité inutile.

Presque tous les abonnés à ce numéro sont d'accord avec ces points.

L'ajout de la possibilité de définir le nom du projet dans docker-config.yml n'entrera même pas en conflit avec les fonctionnalités actuelles. Il n'y a aucune raison de ne pas le mettre en œuvre.

@ schmunk42 La dernière fois que j'ai vérifié, docker ne nous a pas permis de choisir le nom de notre fichier .env. Ai-je manqué quelque chose (il est difficile de suivre les changements). Le changer en quelque chose comme docker-compse.env le corrigerait pour mon cas d'utilisation. Le problème que j'ai est que j'utilise deux technologies très populaires qui nécessitent toutes deux un fichier .env. Le framework PHP Laravel ne suit pas ce fichier dans le référentiel et dans les environnements de production, il n'existe parfois pas.

J'ai trouvé que c'était un véritable bloc de stubbling lors de la première adoption de Docker, car comme @RobIsHere l' illustre. Tous mes répertoires de projets sont au format myapp/htdocs/docker-compose.yml . Au début, en adoptant Docker, j'ai accidentellement supprimé d'autres conteneurs que je n'avais pas l'intention de faire. Il serait préférable que docker nomme son projet au hasard plutôt que d'utiliser le nom du dossier dans mon cas.

J'ai plusieurs autres développeurs distants qui commencent à adopter Docker. En tant qu'équipe, il m'est toujours plus facile de demander à ces développeurs de toujours / seulement docker-compose up pour faire fonctionner ces applications. Moins ces premiers utilisateurs en savent sur Docker, mieux c'est. Une fois qu'ils verront le pouvoir derrière cela, ils reprendront d'eux-mêmes.

Donc, pour résumer, les cas d'utilisation semblent être ceux où la valeur par défaut n'est pas appropriée. Il existe déjà des moyens de remplacer la valeur par défaut, mais ceux-ci peuvent être sujets aux erreurs et ne pas être évidents pour les premiers utilisateurs.

Les cas où la valeur par défaut n'est pas appropriée sont:

• plusieurs fichiers de composition dans le même répertoire (vous oblige déjà à spécifier -f pour les exécuter)
• en utilisant le même nom de répertoire pour tous les projets (je suppose que cela vous oblige également à spécifier -f , la solution de contournement possible est d'utiliser un nom de répertoire unique).

@dnephin j'ajouterais, une pierre d'achoppement en moins possible pour les premiers utilisateurs de Docker.

@dnephin Vous avez également eu ces préoccupations dans ce commentaire :

À l'origine, je voulais le nom dans le fichier docker-compose.yml, mais après y avoir réfléchi davantage, j'aime beaucoup l'idée d'un fichier séparé. Un fichier séparé vous donne la possibilité de le garder hors du contrôle de version si vous le souhaitez (pour les cas où vous souhaitez que chaque utilisateur puisse avoir un nom de projet différent).

Définir l'ordre de priorité de résolution des noms de projet comme ceci résoudra ce problème (les plus grands nombres remplacent les plus petits):

1. docker-compose.yml
2. La variable d'environnement COMPOSE_PROJECT_NAME
3. L'option de ligne --project-name commande

La dernière fois que j'ai vérifié, docker ne nous a pas permis de choisir le nom de notre fichier .env.

@fiveanddone AFAIK vous ne pouvez pas faire cela, mais cela ne ferait que déplacer le problème, car vous devrez alors savoir de quel fichier ENV vous auriez besoin pour le projet.

Dans notre cas avec phd5 , nous avons déplacé le (app) -environment vers src/ et .env est uniquement le "control-environment-file", j'ai essayé d'expliquer cela ici .
Je n'aime pas ça et je ne l'aurais pas changé tout seul. Je sais que cela pourrait ne pas être possible pour beaucoup de projets.
Mais avoir un .env de votre application au même niveau que votre docker-compose.yml devient super ennuyeux, car a) vous obtenez des variables dans votre "environnement de contrôle" qui n'y appartiennent pas et b) vous devez transmettre ces variables à votre conteneur, si vous en avez besoin et c) vous ne pouvez plus les remplacer / les modifier dans votre fichier app.env .

@dnephin Pourquoi ne pas introduire docker-compose.env comme fichier env préféré et utiliser .env comme solution de secours. Vous avez fait la même chose avec fig.yml une fois.

Je ne pense pas que cela résout le problème pour tout le monde. La dénomination du fichier .env me semble être un problème différent.

Je pense que le nœud du problème est le suivant:

La conception originale de docker-compose up était d'être une seule (courte) commande que vous pouviez exécuter pour faire fonctionner les services. C'est ce que les développeurs en attendent. Cependant, ce comportement ne peut pas être atteint pour certains utilisateurs (dans ces cas ).

Il existe de nombreuses façons de contourner le problème, mais aucune ne semble fonctionner pour tout le monde.

Je pense que l'ordre de priorité (du plus élevé au plus bas) doit être quelque chose comme ceci:

1. --project-name (remplace toujours)
2. COMPOSE_PROJECT_NAME variable d'environnement
3. Une valeur par défaut définie par l'utilisateur, distincte de tout fichier versionné
4. Une valeur par défaut définie par le projet, qui peut être archivée
5. Le nom du répertoire (par défaut lorsque rien n'est spécifié)

(3) pourrait être réalisé avec un fichier .docker/project-name (comme proposé dans l'OP)
(4) pourrait être réalisé avec un champ dans le fichier docker-compose.yml

Il est regrettable qu'il doive y avoir autant de façons différentes de définir le nom du projet.

@dnephin concernant 3, laisser un utilisateur définir une valeur par défaut, c'est à cela que servent les variables d'environnement, pas besoin de créer un fichier

Hmm ... Et si nous généralisions un peu le problème et introduisions simplement la section default_environment dans docker-compose.yml ? De cette façon, nous pourrons définir COMPOSE_PROJECT_NAME sans introduire de champ spécial dans le yaml, mais nous pourrons également définir d'autres variables par défaut, qui sont susceptibles d'être présentes ailleurs dans le fichier. Cela réduira le nombre de cas où .env.dist doit être copié dans .env et le coût de l'oubli sera moindre.

Exemple d'utilisation:

# ~/projects/sketches/sketch-42/docker/docker-compose.yml
version: "2"
default_environment:
  - SUBDOMAIN=sketch-42
  - ROOT_HOST=example.com
  - COMPOSE_PROJECT_NAME=sketch-42
services:
  web:
    build:
      context: ../
      dockerfile: docker/Dockerfile
    environment:
      - VIRTUAL_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - VIRTUAL_PORT=80
      - VIRTUAL_NETWORK=proxy
      - LETSENCRYPT_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - LETSENCRYPT_EMAIL=admin@${ROOT_HOST}
    restart: always
    networks:
      - proxy

networks:
  proxy:
    external:
      name: proxy

Ce yaml est très similaire à ce que j'ai très souvent - il décrit un croquis vis, qui a toujours un service appelé web , mais peut également être sauvegardé par un mini serveur API et peut-être un conteneur avec une base de données. On suppose que https://github.com/jwilder/nginx-proxy se trouve à l'avant de tout et écoute les vrais ports 80 et 443.

Pour le moment, peu importe si je suis sur une machine locale ou sur un serveur distant, je dois me rappeler de maintenir .env et aussi de m'assurer que toutes les variables d'environnement y sont définies. Si, disons, j'ai oublié SUBDOMAIN , le conteneur démarre, mais le serveur Web reste en panne.

Avec la section default_environment à ma disposition, je pourrais avoir toutes mes variables de production en place dans un seul fichier et je n'aurais pas à copier .env.dist sur le serveur. Sur la machine locale, dans l'exemple ci-dessus, je mettrais simplement une seule variable dans .env , ce qui serait ROOT_HOST=example.com.dev (ou peut-être que je pourrais même export ROOT_HOST=example.com.dev dans le profil bash? )

Pour résumer, la section default_environment dans docker-compose.yml peut non seulement résoudre le problème dont nous discutons actuellement, mais peut également permettre quelques astuces supplémentaires, tout en étant 100% BC et facile à comprendre!

WDYT?

Cela semble bien, cela peut être utile pour moi dans certains scénarios.

Cependant, sachez qu'à la lumière de la discussion (animée) ci-dessus, votre
solution se traduit en gros par ceci: «Au lieu d'ajouter un nouveau fichier à la
yml, que diriez-vous d'ajouter une nouvelle section? " :)

Le mar 28 février 2017, 00:02 Alexander Kachkaev [email protected]
a écrit:

Hmm ... Et si nous généralisions un peu le problème et introduisions simplement
section default_env dans docker-compose.yml. De cette façon nous définissons
COMPOSE_PROJECT_NAME sans introduire de champ spécial dans le yaml, mais
sera également capable de définir d'autres variables par défaut, susceptibles d'être
présent ailleurs tout au long du dossier. Cela réduira le nombre de cas
lorsque .env.dist doit être copié dans .env et le coût de l'oubli de
le faire sera moins.

Exemple d'utilisation:

~ / projects / sketches / sketch-42 / docker / docker-compose.yml

version 2"
default_env:
SOUS-DOMAINE = sketch-42
ROOT_HOST = example.com
COMPOSE_PROJECT_NAME = sketch-42
prestations de service:
la toile:
construire:
le contexte: ../
dockerfile: docker / Dockerfile
environnement:
- VIRTUAL_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST}, www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- VIRTUAL_PORT = 80
- VIRTUAL_NETWORK = proxy
- LETSENCRYPT_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST}, www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- LETSENCRYPT_EMAIL = admin @ $ {ROOT_HOST}
redémarrer: toujours
réseaux:
- Procuration

réseaux:
Procuration:
externe:
nom: proxy

Ce yaml est très similaire à ce que j'ai très souvent - il décrit un vis
sketch, qui a toujours un service appelé web, mais peut également être sauvegardé
par un mini serveur API et peut-être un conteneur avec une base de données. Il est supposé
que https://github.com/jwilder/nginx-proxy est assis à l'avant et écoute
aux ports réels 80 et 443.

Pour le moment, peu importe si je suis sur une machine locale ou sur un serveur distant,
Je dois me rappeler de maintenir .env et aussi de m'assurer que tout
les variables d'environnement y sont définies. Si, disons, j'ai oublié
SUBDOMAIN, le conteneur démarre, mais le serveur Web reste en panne.

Avec la section default_env à ma disposition, je pourrais avoir toute ma production
variables en place et je n'aurais pas à copier .env.dist sur le serveur.
Sur la machine locale, je mettrais juste une variable dans .env, ce qui serait
ROOT_HOST = example.com.dev (ou peut-être que je pourrais même exporter
ROOT_HOST = example.com.dev dans le profil bash?)

Pour résumer, la section default_env de docker-compose.yml ne peut pas seulement
résoudre le problème dont nous discutons maintenant, mais peut également permettre une utilisation plus agréable
scénarios!

WDYT?

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/docker/compose/issues/745#issuecomment-282885661 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AAQJJZumr10j3i17gPxrSyA-n8CwvsXTks5rg1X_gaJpZM4DLBNs
.

Avoir le "nom_projet" dans le fichier docker-compose.yml résoudrait un problème avec notre pile.
Nous avons un référentiel monolithique avec une arborescence standardisée gérant plusieurs projets, qui ressemble plus ou moins à ceci:

projectA/infrastructure/docker-compose.yml
projectB/infrastructure/docker-compose.yml
...

C'est évidemment plus complexe que cela dans le monde réel, nous ne pouvons donc pas simplement déplacer le fichier docker-compose.yml vers le dossier "projectA / projectB".

Nous avons une CLI à la racine qui demande quels projets démarrer, et comme le nom du projet dépend directement du dossier parent de docker_compose.yml, nous sommes confrontés à des conflits.

Comme nous n'écrivons pas nous-mêmes la commande docker-compose (enveloppée dans notre script CLI), nous ne pouvons pas simplement ajouter l'argument "-p" à la commande manuellement.
Une solution pour nous serait de toujours générer un nom_projet dans le script CLI afin que nous ayons toujours un "-p" lors de l'appel de docker-compose, basé sur le chemin absolu, mais cela semble bizarre.

Un gars ici a dit "ça marche la plupart du temps" parce que sur la plupart des projets, le docker-compose.yml est situé dans le dossier racine du projet, et les projets ont un nom différent, évitant les conflits ", je ne peux pas être d'accord sur ce. Ce n'est pas toujours dans le dossier racine.

Pourquoi est-il possible de définir le "nom_conteneur" dans un fichier docker-compose.yml (désactivation de la mise à l'échelle) pour un service, mais ne peut pas définir un "nom_projet" pour le fichier docker-compose.yml lui-même, au même niveau que "version" / "services" / "réseaux" / "volumes"?

Cela semble nécessaire avec l'utilisation de scale pour que les noms de conteneurs soient évidents. (par exemple <project_name>_<container_name>_1 ).

Cela vous aidera lors de l'utilisation du nom du conteneur pour dns.

Je suis venu ici en espérant que cela soit fait. Gauche déçu. 3 ans +

Ouais, c'est l'un des problèmes de convivialité les plus stupides de Docker et cela reste sans réponse.

Nous avons passé tellement de temps à nous disputer avec les développeurs à ce sujet, et même s'il y avait consensus, personne n'a admis que c'était une mauvaise conception.

C'est frustrant car il y a un support utilisateur évident pour cela, mais comme cela ne correspond pas aux propres cas d'utilisation des développeurs, nous sommes en train de ressasser cette année après année.

Quel est l'intérêt de docker-compose si nous devons ajouter des options à l'aide de cli?
J'ai eu quelques conteneurs écrasés grâce au schéma de nommage.

Aujourd'hui, je mettais en place un autre projet docker-compose avec un autre fichier .env pour donner au projet un nom persistant. J'ai donc pensé vérifier ce problème depuis quelques années depuis ma dernière vérification. Mais rien de nouveau ici pour autant que je puisse voir? Je suppose que je vais devoir continuer à utiliser la solution .env contournement

Devoir spécifier le nom du projet en externe (par ligne de commande ou variable) mais être incapable de le définir dans le fichier docker-compose.yml - le fichier qui spécifie absolument tout le reste - est tout simplement insensé. Il existe de nombreux cas où un processus peut avoir besoin d'adresser une pile de services spécifique basée sur un fichier arbitraire docker-compose.yml indépendamment du nom du répertoire parent, de l'environnement shell ou de la présence d'une ligne spécifique dans un .env spécifique docker-compose.yml pour que mes travaux puissent l'extraire et l'utiliser.

Cela semble se produire maintes et maintes fois avec ce projet. Docker est une technologie merveilleuse, mais parfois je me demande si les développeurs ont réellement une expérience du monde réel, ou sont-ils tous des hackers de 18 ans qui pensent qu'ils savent le mieux? Les gens veulent utiliser ces trucs pour un vrai travail, pas passer leur temps constamment à chercher des solutions de contournement.

Je suppose que l'équipe ignore entre-temps ce problème. Essayer de convaincre les développeurs de docker peut être une vraie douleur pour le dire légèrement.

Les arguments clairs sont contrés par une logique étrange qui n'a pas beaucoup de sens. L'opinion des utilisateurs du monde réel qui viennent tous ici pour la même raison est ignorée. C'est dommage.

Je ne veux pas que mes travaux CI doivent continuellement «comprendre» le nom du projet - il devrait être clairement indiqué dans le fichier docker-compose.yml afin que mes travaux puissent l'extraire et l'utiliser.

Avez-vous le problème que votre pile s'appelle "build1234" et / ou comment aimeriez-vous utiliser le nom de la pile à un autre endroit, comme docker exec build1234_myservice script.sh ?

Cela ne convient peut-être à aucun cas d'utilisation, mais pour l'avoir dit ...

Dans nos configurations, nous ne modifions .env lors de la configuration d'un projet (cloné). Si nous avons besoin de modifications ou d'une configuration dynamique, nous réutilisons les variables de .env dans docker-compose.yml . Un avantage est que docker-compose vous avertit (ou échoue) si une variable est manquante.

Je ne veux pas vous dire que vous devez modifier vos flux de travail, car j'ai également été ennuyé par ce problème.
C'est essentiellement quelque chose comme, nous traitons les changements de docker-compose.yml plus comme des changements de code source, tandis que .env est uniquement la configuration. Mais je suis également d'accord qu'il existe plusieurs options dans docker-compose.yml , comme network qui dépendent fortement du projet. Revenant à ce qui précède; Je définirais une variable .env pour le réseau. 🤐

Je ne veux pas vous dire que vous devez modifier vos flux de travail, car j'ai également été ennuyé par ce problème.

J'ai encore réfléchi à ma propre situation. Je n'ai pas de problème avec la définition externe du nom du projet, et en fait je le fais avec l'indicateur -p <project_name> , ce qui permet d'isoler des instances uniques de la pile dans CI et d'exécuter plusieurs piles simultanément si nécessaire. Seule cette chaîne CI a besoin de connaître ce nom de projet afin qu'il puisse être généré automatiquement ou aléatoire (mais connu), pas de problème. Je n'ai pas non plus de problème avec l'utilisation d'une variable d'environnement pour remplacer le nom par défaut, mais je trouve que l'astuce .env n'est pas évidente.

Cependant, il existe d'autres situations où il est utile d'avoir le _ nom par défaut_ du projet explicitement défini quelque part. Alors pourquoi prend-il le nom du répertoire parent comme source de ce nom? Tel est, pour moi, le point faible ici. Il pourrait être pris de n'importe où - le choix d'un répertoire parent semble juste arbitraire et sans grande raison (par exemple dans presque tous mes projets, le fichier docker-compose.yml trouve dans un sous-répertoire appelé docker ). Donc, si cela doit être arbitraire, stockez-le dans un endroit plus explicite, comme le fichier yml, plutôt que de créer des effets secondaires externes en influençant les noms de répertoire parent qui, dans de nombreux cas, devraient être complètement indépendants du contenu du répertoire (basé sur des années d'expérience de travail avec des ressources réutilisables).

Il pourrait être pris de n'importe où - le choix d'un répertoire parent semble simplement arbitraire et sans grande raison (par exemple dans presque tous mes projets, le fichier docker-compose.yml se trouve dans un sous-répertoire appelé docker).

Si vous avez besoin d'autre chose qu'un identifiant aléatoire, je ne vois aucune alternative réelle au répertoire parent. Au moins, vous avez la chance de savoir d'où «vient» votre pile.
Mais je suis également d'accord avec vous, car dans nos projets, nous testons des piles dans des dossiers tests qui - sans un fichier .env - se heurteraient également fortement les uns aux autres. C'est pourquoi j'ai proposé de préférer un fichier appelé docker-compose.env qui serait beaucoup plus clair à mon humble avis.

Voulez-vous simplement fermer ce bogue en admettant que vous ne vous en souciez pas, ou implémenter la chose incroyablement simple que la grande majorité d'entre nous souhaite? C'est 2,86 ans plus tard. Sortez du pot. Prenez vos décisions ou corrigez vos erreurs. Comment vous voulez le regarder. Faites plus que rien.

@matsaman et toutes les personnes qui donnent son commentaire le pouce levé:

Voulez-vous simplement fermer ce bogue en admettant que vous ne vous en souciez pas, ou implémenter la chose incroyablement simple que la grande majorité d'entre nous souhaite? C'est 2,86 ans plus tard. Sortez du pot. Prenez vos décisions ou corrigez vos erreurs. Comment vous voulez le regarder. Faites plus que rien.

Qui êtes-vous les gars? En open source, la communauté possède les décisions et corrige les erreurs des autres. Docker est open source. Envisagez de soumettre une pull request au lieu de pleurnicher.

Je suis moi aussi triste que cela n’ait pas encore été mis en œuvre. Mais, en open source, nous contribuons ou attendons patiemment.

Argument CLI:

$ cd foo
$ docker-compose up
$ docker-compose -p bar up
... some time later wanting to take down bar forgetting '-p'
$ docker-compose down
Stopping foo_nginx_1 ... done
Stopping foo_mysql_1 ... done
Removing foo_nginx_1 ... done
Removing foo_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

Échouer.

Fichier Env:

$ cd foo
$ source foo.env
$ docker-compose up
$ source bar.env
$ docker-compose up
... some time later wanting to take down foo forgetting to `source .foo.env`
$ docker-compose down
Stopping bar_nginx_1 ... done
Stopping bar_mysql_1 ... done
Removing bar_nginx_1 ... done
Removing bar_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

Échouer.

Solutions proposées avec le nom du projet dans le fichier yml:

$ cd foo
$ docker-compose -f foo.yml up
$ docker-compose -f bar.yml up
... some time later
$ docker-compose down
ERROR:
        Can't find a suitable configuration file in this directory or any
        parent. Are you in the right directory?

        Supported filenames: docker-compose.yml, docker-compose.yaml

Yay!

$ COMPOSE_PROJECT_NAME=foo docker-compose up -d
$ COMPOSE_PROJECT_NAME=bar docker-compose up -d
... some time later
$ docker-compose down -v
Removing network project_default
WARNING: Network project_default not found.

O /

Qui êtes-vous les gars?

@benjaminwood Ce sont les responsables de ce projet. Votre argument aurait du sens si nous parlions d'un changement complexe et que personne ne trouverait le temps de le faire.

Ce n'est pas le cas ici assez évident: l'implémentation serait probablement très facile pour ceux qui connaissent la base de code et beaucoup plus difficile pour quelqu'un de l'extérieur. Ce n'est donc pas que personne n'ait le temps de le faire, mais plutôt que les responsables ne veulent pas le faire. Et c'est ce que les supporters ici trouvent extrêmement ennuyeux, étant donné la longue période pendant laquelle ce numéro est ouvert maintenant et la masse de: +1: ici.

Les solutions de contournement publiées encore et encore ici sont toutes bien connues mais ne s'appliquent pas à tout le monde. Et je ne trouvais toujours pas de réponse à la question de savoir pourquoi, de toutes choses, presque seul le nom du projet était omis dans les fonctionnalités de docker-compose.yml . Si quelqu'un pense que cela n'a pas sa place, alors ne l'utilisez pas! Mais n'obstruez pas votre opinion sur les autres si la demande est si évidente.

Voyons cela d'un autre point.

Si je suis dans un dossier contenant un fichier docker-compose.yml , comment puis-je trouver le nom de projet de ma pile?
C'est une question assez basique, mais il n'y a pas de réponse facile.

Actuellement, c'est (trié par priorité):

• la valeur de -p
• la valeur de COMPOSE_PROJECT_NAME de votre environnement
• la valeur de COMPOSE_PROJECT_NAME de votre fichier .env
• le nom du répertoire courant

Pour être l'avocat du diable, pourquoi ajouter un 5ème à cette configuration déjà déroutante?

Malgré la décision de cela, il devrait y avoir une information «exécutable à sec» sur le nom actuel. Ni docker-compose config n'a cela, ni docker-compose ps si la pile n'est pas en cours d'exécution.
Peut-être que docker-compose create est la meilleure option actuellement disponible, mais loin d'être parfaite.

Il devrait y avoir au moins quelque chose comme docker-compose config --project-name . Actuellement, j'ai besoin de connaître les emplacements ci-dessus et de les vérifier dans le bon ordre.

Si je me trouve dans un dossier contenant un fichier docker-compose.yml, comment puis-je trouver le nom de projet de ma pile?

Encore une fois: si vous ne voulez pas l'utiliser, ne l'utilisez pas! Si vous êtes satisfait de votre solution, tant mieux! Rien ne changera pour vous, vous ne serez donc pas du tout confus!

Mais ne pouvez-vous pas accepter que les autres aient des exigences différentes? Tout ce que nous voulons, c'est que cette pièce logiquement manquante soit enfin ajoutée.

Pour être l'avocat du diable, pourquoi ajouter un 5ème à cette configuration déjà déroutante?

La seule raison pour laquelle cela peut prêter à confusion est que le nom du projet a été laissé en dehors de docker-compose.yml en premier lieu. Sinon, tout serait dans ce fichier maintenant. Nous pouvons définir une liste de priorité - pas un problème.

Actuellement, j'ai besoin de connaître les emplacements ci-dessus et de les vérifier dans le bon ordre.

Pourquoi ne connaissez-vous pas le nom du docker de votre projet et pourquoi est-ce même pertinent pour vous? Et pourquoi n'utilisez-vous pas le même mécanisme dans tous vos projets si cela vous déroute tellement?

Encore une fois: si vous ne voulez pas l'utiliser, ne l'utilisez pas! Si vous êtes satisfait de votre solution, tant mieux! Rien ne changera pour vous, vous ne serez donc pas du tout confus!

Ma question ne portait pas sur l'utilisation d'une nouvelle fonctionnalité, mais sur l'absence d'une fonctionnalité existante. Le nom du projet est la seule et unique information pertinente que docker-compose utilise pour démarrer et arrêter un certain ensemble de conteneurs.
Les personnes de ce thread se plaignent d'avoir tué les mauvais conteneurs, car le nom du projet ne fait pas partie de la pile.

Mais ne pouvez-vous pas accepter que les autres aient des exigences différentes? Tout ce que nous voulons, c'est que cette pièce logiquement manquante soit enfin ajoutée.

Si vous ajoutez cela, les gens se plaindront de tuer les mauvais conteneurs, car ils font partie de la pile, car ils utilisaient auparavant le nom du répertoire.

La seule raison pour laquelle cela peut prêter à confusion est que le nom du projet a été laissé en dehors de docker-compose.yml en premier lieu. Sinon, tout serait dans ce fichier maintenant. Nous pouvons définir une liste de priorité - pas un problème.

En fait, vous ne pouvez pas l'ajouter de manière BC, car il devrait avoir une priorité inférieure en tant que nom de répertoire, ce qui le rendrait inutile. C'est pourquoi je demandais "comment obtenir le nom du projet".

Pourquoi ne connaissez-vous pas le nom du docker de votre projet et pourquoi est-ce même pertinent pour vous?

Parce que j'utilise généralement le nom du répertoire, mais parfois une valeur personnalisée dans .env - c'est pertinent car le nom du projet définit les conteneurs sur lesquels les actions sont exécutées.

cd /some/path/test
docker-compose up -d
cd /a-completely-different-path
docker-compose -p test down -v --remove-orphans

Cela tuera votre première pile, ce serait la même chose avec le nom du projet dans le fichier yml .

Et pourquoi n'utilisez-vous pas le même mécanisme dans tous vos projets si cela vous déroute tellement?

Oui, j'utilise simplement les fonctionnalités par défaut docker-compose ; la plupart du temps, le nom du répertoire est correct, mais au cas où je devrais le renommer, mais que je voudrais continuer à travailler avec le même ensemble de conteneurs, j'ajoute un fichier .env .

Si vous ajoutez cela, les gens se plaindront d'avoir tué les mauvais conteneurs, car ils font partie de la pile, car ils utilisaient auparavant le nom du répertoire.

Cela n'a pas de sens. Si quelqu'un n'ajoute pas le nom du projet à docker-compose.yml rien ne changera. Et s'ils l'ajoutent, c'est parce qu'ils le veulent là-bas! Personne ne l'ajoutera à moins d'en avoir besoin.

Et même s'ils le font, tout va bien. Je ne comprends pas quel problème vous essayez de construire ici. Vous compliquez trop les choses.

Si vous mélangez toutes les options où un nom de projet pourrait être configuré, je dirais que c'est votre problème. Vous ne devriez pas du tout faire ça.

3 des 4 options de l'arborescence des priorités sont sans valeur une fois que vous avez plusieurs fichiers de composition nommés dans un répertoire. Ne me dites pas de créer des sous-répertoires, car je partage toujours un fichier .env entre eux.

Ne me dites pas de créer des sous-répertoires, car je partage toujours un fichier .env entre eux.

Partagez-vous un fichier .env spécifique env_file ?
Ou celui que docker-compose utilise?
Ou les mélangez-vous?

Cela n'a pas de sens. Si quelqu'un n'ajoute pas le nom du projet à docker-compose.yml, rien ne changera.

Ce n'est pas le problème, mais quand il serait ajouté, le comportement change radicalement.

Lorsque nous copions une pile dans un nouveau répertoire pour générer une instance temporaire (c'est-à-dire pour tester une mise à jour), nous n'avons pas du tout à toucher docker-compose.yml . Mais si cela fait partie de la pile, nous devrons décider si nous le remplaçons par .env ou si nous le changeons en docker-compose.yml .

Oui, il se peut que cela n'aurait pas dû être ajouté en premier lieu, mais avoir une autre option ici ne rend pas les choses plus faciles et plus concises.

J'ai un fichier .env unique commun que 4 fichiers de composition nommés (dans le même répertoire) utilisent. Aucune variable d'environnement. Pas de scripts shell. J'utilise juste composer.

Je préférerais ça

docker-compose -f service1.yml up -d

Au lieu de cela, c'est plus comme ça

docker-compose -f service1.yml up -d
# F#&$, forgot the -p flag.   Curse the compose devs for 3 years of c#*$blocking
docker-compose -f service1.yml down
docker-compose -f service1.yml -p service1 up -d

@ schmunk42 vous pensez sérieusement que c'est une solution pour taper 'COMPOSE_PROJECT_NAME = ...' à chaque fois pour chaque commande docker-compose, éventuellement en plus du nom de fichier compose? Cela vous oblige également à connaître et à retenir le nom du projet. Pouvoir spécifier le nom du projet dans une variable d'environnement a son utilité à coup sûr, mais dans certains cas, vous voulez simplement avoir un répertoire avec quelques fichiers yml et être en mesure de gérer facilement les projets de manière infaillible sans avoir à le faire. souvenez-vous des noms de projet que vous avez choisis il y a des mois et sans avoir à vous souvenir d'exporter les variables d'environnement.

Vous ne pouvez pas utiliser un dossier par service et avoir toujours un fichier .env dans le dossier supérieur?

docker-compose -f service1/docker-compose.yml up -d
docker-compose -f service2/docker-compose.yml up -d

Écrivez simplement le nom du projet dans le fichier (-path) 😉

J'abandonne. Il est évident que la clientèle pour cela a changé.

Faites-moi savoir ce qui ne va pas avec la proposition que je vous ai faite.

J'avais les mêmes préoccupations au début, mais nous avons ajusté nos flux de travail aux fonctionnalités disponibles.

Je ne me souviens pas d'avoir tué accidentellement un tapis au cours des 2 dernières années, par personne de notre équipe. Nous exécutons plus de 200 piles avec environ 1000 conteneurs et 1000 redéploiements automatiques ou manuels de cette façon.

Je ne veux pas vraiment m'impliquer ici ... mais je ne peux pas résister.

Il y a une différence très importante entre une «solution» étant donné la situation actuelle, et la «bonne» solution étant donné les possibilités qui existent. Ce sur quoi cette question devrait se concentrer, c'est de trouver la «bonne» solution, ce qui en ce qui me concerne est assez évident, bien que certains puissent encore être en désaccord.

@ schmunk42 et @mikehaertl

Je ne me souviens pas d'avoir tué accidentellement un tapis au cours des 2 dernières années, par personne de notre équipe .

Je dois demander. Je vois que vous faites tous les deux partie de l'organisation codemix . Êtes-vous des collègues? Commencer à se demander si dans les coulisses vous êtes tous les deux rotfl.

Actuellement, c'est (trié par priorité):

1. la valeur de -p
2. la valeur de COMPOSE_PROJECT_NAME de votre environnement
3. la valeur de COMPOSE_PROJECT_NAME de votre fichier .env
4. le nom du répertoire courant

Pour être l'avocat du diable, pourquoi ajouter un 5ème à cette configuration déjà déroutante?

Le problème, tel que je le vois, est que chaque valeur unique actuellement disponible est spécifique à l'environnement. Il n'y a aucun moyen de fournir une option spécifique au projet.

1 + 2. Doit être fourni manuellement par l'utilisateur qui appelle la commande.

1. _Pourrait_ être partagé, mais en pratique .env devrait être ignoré et non partagé pour une bonne raison. (Je contourne ce problème en partageant .env.example , mais cela nécessite toujours une étape manuelle supplémentaire.)
2. Est effectivement aléatoire et est spécifique à l'utilisateur / à l'environnement. (Je considère également cela comme une solution de secours, car composer _nécessite_ un nom de projet. Ce n'est même pas une très bonne solution de secours, car il pourrait y avoir des projets dans différents répertoires nommés de la même manière qui seraient en conflit.)

À mon avis, et pour beaucoup de ceux de ce fil, il devrait y avoir une option qui vit entre 3 et 4, où un nom de projet par défaut _peut_ être fourni dans n'importe quel fichier docker-compose utilisé pour ce projet et utilisé comme premier se retirer. Cette valeur serait ensuite partagée par toute personne déployant ce projet. Les options 1 à 3 remplaceraient cette valeur et l'option 4 ne serait utilisée que si elle n'était pas fournie.

@benjaminwood Je peux vous assurer que personne ne rit de ce problème. Oui, nous nous connaissons depuis un certain temps et ce n'est pas la première fois que nous sommes fondamentalement en désaccord. Cela peut sembler ennuyeux pour plusieurs utilisateurs ici, mais ce n'est pas mon intention. En fait, j'aimerais partager mes expériences et proposer des solutions. Je crois avoir une vaste expérience sur ce sujet. Si la fonctionnalité était introduite comme proposé, cela introduirait une énorme source d'erreurs possibles dans notre configuration.

@joshuajabbour

1. Peut être partagé, mais dans la pratique, .env doit être ignoré et non partagé pour une bonne raison.

Cela dépend de votre configuration, nous l'avons ignoré dans tous nos référentiels de projet.
Mais nous ne l'ignorons pas dans nos référentiels de staging et de production uniquement. Si vous partagez le nom commis dans docker-compose.yml vous pouvez également commettre .env (ce fichier est uniquement pour la commande docker-compose - rien d'autre)

1. Est effectivement aléatoire et est spécifique à l'utilisateur / à l'environnement.

Ce n'est pas plus ou moins aléatoire qu'une valeur dans docker-compose.yml , vous devez afficher la configuration de la pile comme un dossier, pas un seul fichier. Si vous faites cela, vous pouvez avoir le nom en .env ou un nom de sous-dossier.

J'ai une dernière alternative pour vous tous:

docker stack deploy -c docker-compose.yml the-project-name

(*) Uniquement disponible en mode essaim

Je ne vois pas comment un nom de projet pourrait être placé dans le fichier yml à l'avenir, cela contredirait totalement l'idée d'une définition de pile.

Merci @ schmunk42. Je crois que vous et je pense que vous avez très bien géré les choses parmi toutes les opinions fortes affichées dans ce fil.

cela introduirait une énorme source d'erreurs possibles dans notre configuration.

Voilà le hic. Fermez le problème.

Cela dépend de votre configuration, nous l'avons ignoré dans tous nos référentiels de projet. Mais nous ne l'ignorons pas dans nos référentiels de staging et de production uniquement.

Donc, cette fonctionnalité que tout le monde veut ne devrait pas être introduite car elle briserait votre architecture de référentiel inhabituelle?

Si vous souhaitez partager le nom engagé dans docker-compose.yml vous pouvez également valider .env (ce fichier est uniquement pour la commande docker-compose - rien d'autre).

Eh bien, si la seule chose dans mon fichier .env était COMPOSE_PROJECT_NAME , alors oui. Mais il est rempli de nombreuses autres variables _secure_ que je ne veux pas commettre. Et je les importe dans docker-compose en utilisant la propriété environment . C'est à cela que servent généralement les fichiers .env ...

Je ne comprends toujours vraiment pas comment cela casserait votre configuration, car dans ma proposition, cela ne remplace que le nom du projet par défaut extrait du répertoire. Et si vous en dépendez (parce qu'il s'agit d'un répertoire engagé _ dans votre dépôt par opposition au répertoire dans lequel votre dépôt est cloné), comment pourrait-il être remplacé par le paramètre docker-compose.yml (car il est également validé à votre repo; vous contrôlez les deux choses dans votre scénario)?

@ schmunk42 Ce que vous dites, c'est "Je ne veux pas de nouvelles fonctionnalités, sinon je ne comprends plus la configuration de mon projet".

Sérieusement? C'est votre argument pourquoi vous voulez que tous les autres qui en ont besoin s'en passent?

Juste pour information: je suis ici aussi. N'hésitez pas à clôturer le problème. La discussion ici est devenue inutile.

Donc, cette fonctionnalité que tout le monde veut ne devrait pas être introduite car elle briserait votre architecture de référentiel inhabituelle?

J'exprime mes inquiétudes quant au fait que cela pourrait introduire des sources supplémentaires d'erreurs.

Eh bien, si la seule chose dans mon fichier .env était COMPOSE_PROJECT_NAME, alors oui. Mais il est rempli de nombreuses autres variables sécurisées que je ne veux pas voir validées. Et je les importe dans docker-compose en utilisant la propriété environment.

Utilisez un secrets.env pour ceux-ci et importez-le via env_file .
Comment cela affecterait-il votre flux de travail?

C'est à cela que servent généralement les fichiers .env ...

C'est vrai ... mais je pense toujours que le problème est que docker-compose détourne le fichier .env .

Comment serait-ce, si vous pouviez définir ces variables plus celles utilisées dans les niveaux supérieurs de docker-compose.yml , comme IMAGE_VERSION , dans un fichier appelé docker-compose.env ?

Je n'ai jamais osé proposer COMPOSE_COMMAND_ENV_FILENAME=.env - jusqu'à présent :)

Je ne comprends toujours vraiment pas comment cela briserait votre configuration, ...

Il est vrai que cela ne casse pas immédiatement, mais il ne s'agit que de mon premier point - et d'introduire encore plus d'options.

Pensez à utiliser plusieurs fichiers -f docker-compose.A.yml -f docker-compose.B.yml , disons que A est votre projet et s'appuie sur le nom du projet par répertoire (nous le faisons, puisque nous le contrôlons!), Tandis que B est un ensemble de services supplémentaires avec project_name: extra , introduits accidentellement lors du test dans un dossier contenant .env fichier COMPOSE_PROJECT_NAME=testing .

Mais maintenant, tout projet, qui est démarré sans fichier .env , serait nommé extra . 💥

Nous fusionnons des fichiers sur plusieurs niveaux, y compris plusieurs fichiers *.env , c'est un cas d'utilisation très valide.

Sérieusement? C'est votre argument pourquoi vous voulez que tous les autres qui en ont besoin s'en passent?

Attention: légèrement hors sujet, mais toujours lié au docker ...

• "Je ne pense pas que nous en ayons vraiment besoin"
• "a plus de couches que nécessaire. plus de complexité"

@mikehaertl Je me demande vraiment que vous le voyez de cette façon;)

Salut les gens,

Nous avons repris la discussion passionnée dans ce fil (merci à ceux d'entre vous qui l'ont gardé courtois et cordial!) Et même si nous croyons toujours fondamentalement que le nom du projet n'appartient pas à un fichier Compose, nous avons trouvé ce que nous pensons être un juste milieu avec le PR suivant: # 5378. Cela dit, nous apprécierions vos commentaires à ce sujet pour nous assurer qu'il répond à vos besoins.

Voici l'essentiel:

• Vous pouvez ajouter une entrée x-project-name dans votre fichier Compose. Cette clé est ignorée par défaut.
• Lorsque COMPOSE_X_PROJECT_NAME est défini dans votre environnement (ou .env fichier), Compose tentera de récupérer le nom du projet à partir de l'entrée x-project-name dans votre fichier Compose.
• Cette option a une priorité inférieure à COMPOSE_PROJECT_NAME et --project-name

Heureux de répondre à toutes vos questions ou préoccupations à ce sujet.

@ shin- Donc COMPOSE_X_PROJECT_NAME devrait être réglé sur 1 pour activer la fonctionnalité?

Si tel est le cas, COMPOSE_ENABLE_X_PROJECT_NAME pourrait aussi être un nom à prendre en compte, mais ce ne sont que mes 2 cents - je ne l'utiliserai pas de toute façon 😄

@ schmunk42 Toute valeur "vérité-y" fonctionnera , mais oui, c'est l'idée.

@matsaman Cool, merci pour les commentaires utiles et exploitables.

Au lieu de nous dire que nous devrons dire aux utilisateurs finaux de définir une variable ou d'appeler un paramètre, vous nous dites que nous devrons dire aux utilisateurs finaux de définir une variable ou d'appeler un paramètre.

Honnêtement, et vraiment pas pour rien, je ne peux pas imaginer comment vous avez considéré cela comme une solution de quelque manière que ce soit.

@ shin- Je vais vous expliquer en quoi ce changement ne fait aucune différence utile:

Le fait de devoir définir une variable d'environnement pour permettre la recherche du nom du projet dans le fichier de composition équivaut à peu près {quantité de travail, risque d'oubli et commodité} à définir une variable d'environnement pour le nom du projet lui-même.

Tout l'intérêt de définir le nom du projet dans le fichier de composition est d'éviter d'avoir à utiliser des variables d'environnement. Vous pouvez utiliser la priorité sur la variable d'environnement de nom de projet pour donner aux utilisateurs la possibilité de remplacer le nom de projet dans le fichier de composition.

Je pense que c'est une très bonne solution, car cela ne cassera pas BC et cela évitera d'introduire des erreurs lors de la fusion comme je l'ai décrit ci-dessus.

Le fait de devoir définir une variable d'environnement pour permettre la recherche du nom du projet dans le fichier de composition équivaut à peu près {quantité de travail, risque d'oubli et commodité} à définir une variable d'environnement pour le nom du projet lui-même.

Ce n'est pas le cas, vous pouvez effectuer ce paramètre une fois, globalement dans votre environnement - vous n'avez pas besoin de le faire dans chaque projet.

Ce n'est pas le cas, vous pouvez effectuer ce paramètre une fois, globalement dans votre environnement - vous n'avez pas besoin de le faire dans chaque projet.

Je suppose que vous voulez dire globalement dans toutes vos coquilles que vous créez sur votre ordinateur. Si vous faites cela, vous pourriez avoir un comportement indésirable dans des projets totalement indépendants. Cela entraînera également de la confusion lorsqu'un développeur extrait un projet du contrôle de version et oublie de définir la variable d'environnement.

L'un des objectifs les plus importants d'avoir le nom du projet dans le fichier de composition est de garantir que chaque variable liée au projet de composition est stockée dans le contrôle de version.

@nhooey @matsaman
Il est spécifiquement destiné à aider les personnes qui ont plusieurs fichiers de composition dans le même répertoire, pour qui la solution de fichier .env n'est pas une option. Si cela doit toujours être activé pour vos projets, il est facile de le définir dans votre fichier .env , votre .profile , ou partout ailleurs qui garantira que x-project-name sera toujours pris en compte.

Au lieu de nous dire que nous devrons dire aux utilisateurs finaux de définir une variable ou d'appeler un paramètre, vous nous dites que nous devrons dire aux utilisateurs finaux de définir une variable ou d'appeler un paramètre.

Notre principale préoccupation à ce sujet a toujours été que «l'utilisateur final» ait ses propres projets et qu'il veuille éviter à tout prix les conflits de noms. À cet égard, ils devraient contrôler le nom du projet et non le distributeur. Si vous expédiez des projets «clé en main» aux clients, il est tout aussi trivial de définir COMPOSE_X_PROJECT_NAME dans le fichier associé .env - donc je ne sais pas quelle partie de ceci est une préoccupation pour être honnête.

Si vous faites cela, vous pourriez avoir un comportement indésirable dans des projets totalement indépendants.

Pouvez-vous donner un exemple? Je ne peux penser à aucun comportement indésirable simplement en définissant COMPOSE_X_PROJECT_NAME dans mon shell.

L'un des objectifs les plus importants d'avoir le nom du projet dans le fichier de composition est de garantir que chaque variable liée au projet de composition est stockée dans le contrôle de version.

Pourquoi ne pouvez-vous pas utiliser .env pour cela? Personne n'interdit de stocker .env dans le contrôle de version (oui, ce n'est pas courant).

Nous avions .env au départ. Vous avez clairement manqué toute la conversation.

@matsaman Vous devez sérieusement atténuer votre attitude. Vous avez été méchant depuis que vous avez commencé à commenter dans ce fil et cela n'a fait qu'empirer la conversation en conséquence. Si vous ne pouvez pas être courtois lorsque vous partagez vos pensées, nous pouvons nous passer de votre opinion.

Pour clarifier une partie de la confusion

Tu peux déjà faire ça

Auparavant, vous pouviez définir un nom de projet à l'aide d'une variable d'environnement. La nouvelle variable d'environnement n'est pas un nom, c'est une bascule qui a activé une fonctionnalité qui vous permet de définir un nom de projet dans le fichier de composition.

Je suppose que vous voulez dire globalement dans toutes vos coquilles que vous créez sur votre ordinateur. Si vous faites cela, vous pourriez avoir un comportement indésirable dans des projets totalement indépendants.

Si vous voulez dire "d'autres projets" comme-in, "quelque chose qui n'est pas composé pourrait lire ceci et casser" Je pense que ce n'est pas réaliste. Il y a beaucoup de variables d'environnement définies dans chaque shell. La variable d'environnement est correctement nommée "COMPOSE_X_".

Si vous voulez dire "d'autres projets de composition", alors je pense que vous faites en fait un argument pour expliquer pourquoi cette variable est nécessaire. Si la fonctionnalité était activée par défaut, toute personne se basant sur le comportement par défaut actuel serait interrompue.

Si ce n'est ni l'un ni l'autre, veuillez clarifier.

Cela entraînera également de la confusion lorsqu'un développeur extrait un projet du contrôle de version et oublie de définir la variable d'environnement.

Si un projet ne fonctionne qu'avec un nom de projet spécifique, je pense qu'il y a d'autres problèmes. Il ne devrait jamais y avoir de cas où un projet ne fonctionne qu'avec un seul nom.

Je vois cela comme un autre argument pour ne pas mettre le nom du projet dans le fichier Compose. Si le nom du projet se trouve dans le fichier de composition, deux projets peuvent utiliser le même nom, provoquant un conflit qui interromprait les deux projets. Le nom doit vraiment être défini par le développeur qui sait quels autres noms de projet sont déjà utilisés.

Malheureusement, cela ne m'aidera pas non plus pour les raisons que j'ai déjà mentionnées il y a plus d'un an.

Une solution qui implique des variables environnementales exigerait des utilisateurs qui doivent savoir comment les créer en premier lieu. Je sais que cela peut sembler difficile à croire, mais tout le monde ne travaille pas à l'intérieur du terminal. Encore une fois, mettre un .env dans le référentiel n'est pas une option pour moi.

La beauté de docker-compose est up . Pas d'instructions sur la façon de configurer cet appel.

@fiveanddone

Encore une fois, mettre un .env dans le référentiel n'est pas une option pour moi.

Pouvez-vous développer? Je vous entends totalement sur les utilisateurs ayant des connaissances techniques inférieures, mais s'ils ne sont pas censés interagir avec le code ou l'environnement, pourquoi est-ce un problème d'inclure un fichier .env avec le projet?

@ shin- Ouais, pas de problème.

J'ai dans certains cas inclus ce fichier dans le référentiel mais cela ne fonctionne pas tout le temps. Mes cas d'utilisation concernent principalement le développement Web où les connaissances techniques des développeurs peuvent varier considérablement.

Le .env contient des paramètres qui sont utilisés dans d'autres frameworks. Certaines des variables à l'intérieur de mon .env sont des informations d'identification pour des services externes comme SMTP. La plupart des développeurs de mon équipe pointent ces services vers leurs propres points de terminaison en utilisant leur propre fichier .env . Si le .env n'est pas là, j'ai des valeurs par défaut.

Pour les développeurs moins techniques qui veulent peut-être simplement changer du CSS, l'application fonctionne bien sans le fichier .env . Cela suppose qu'ils ne nomment pas tous les dossiers de projet de la même manière. :)

Cela peut ne pas sembler beaucoup, mais lorsque vous travaillez avec plusieurs développeurs et concepteurs qui couvrent le pays, le plus simple sera le mieux.

Docker m'a tellement simplifié la vie et je suis très reconnaissant pour ce projet, mais je peux comprendre les frustrations autour de ce fil.

@fiveanddone Merci pour la perspicacité! Donc, si le fichier .env était appelé docker-compose.env (ou similaire) à la place, est-ce que cela atténuerait vos inquiétudes?

@tibia-

Oui, ce serait pour mes cas d'utilisation.

Le fichier env est-il chargé automatiquement par Docker Compose?

Sinon, docker-compose.env pourrait-il être chargé automatiquement?

@nhooey Le fichier env est chargé automatiquement s'il est nommé .env . Et vous pouvez également spécifier le fichier env pour chaque service individuellement. Voir la documentation .

Le fichier env est chargé automatiquement s'il est nommé .env. Et vous pouvez également spécifier le fichier env pour chaque service individuellement. Voir la documentation.

Ne pas être le pinailleur ici, mais ce n'est pas vraiment correct. Et à mon humble avis, la plus grande source de malentendu sur l'ensemble du sujet.

Aucune des variables de .env n'est transmise à un conteneur / service, si vous ne le transférez pas explicitement , en utilisant soit

env_file: 
  - .env

ou

environment:
  - VAR_FROM_DOTENV
  - FOO=${ANOTHER_VAR_FROM_DOTENV}

Le fichier .env est chargé automatiquement, oui, mais sans configuration supplémentaire, il ne s'applique qu'à ces variables d'environnement de la CLI Compose .

Je soutiendrais fortement de renommer cela en docker-compose.env par défaut et encore mieux - une variable pour cela , donc cela pourrait être utilisé de manière BC en définissant juste un ENV-var.

(merci à ceux d'entre vous qui l'ont gardé civil et cordial!)

Je vous entends et je suis sûrement coupable de ne pas toujours garder mon sang-froid. Désolé. Certains commentaires me permettent parfois de vraiment démarrer ... travailleront là-dessus.

Si le nom du projet se trouve dans le fichier de composition, deux projets peuvent utiliser le même nom, provoquant un conflit qui interromprait les deux projets.

Notre principale préoccupation à ce sujet a toujours été que «l'utilisateur final» ait ses propres projets et qu'il veuille éviter à tout prix les conflits de noms. À cet égard, ils devraient contrôler le nom du projet et non le distributeur.

@ shin- Cela semble comme il est communément admis que docker-compose.yml fait toujours partie d'un projet et vit dans le référentiel du projet. Je dirais que ce n'est pas forcément vrai. Certains d'entre nous ne partagent docker-compose.yml mais souhaitent conserver leur version locale avec des personnalisations locales (par exemple, les paramètres de développement, les essais, etc.).

Et concernant "éviter les conflits de nom": au lieu d'un conflit de nom avec le nom du projet, nous avons maintenant un conflit de nom beaucoup plus critique (IMO) au niveau du système de fichiers: .env est un nom commun que les projets utilisent pour définir leur paramètres spécifiques à l'application. Il ne devrait pas être pollué avec les paramètres du docker à moins qu'un développeur ne veuille vraiment le faire. Mais cette décision devrait être laissée au développeur.

Voici une suggestion: que diriez-vous d'ajouter deux autres options pour le nom du projet et de déconseiller l'utilisation de .env dans la V4 de docker-compose.yml ? L'un est project_name in docker-compose.yml , l'autre est un fichier .dockerproject qui ne contient que le nom et ne doit

Voici ma suggestion de priorité (la plus élevée en premier):

• -p Argument CLI
• .dockerproject fichier
• project_name in docker-compose.yml (à éviter si docker-compose.yml est distribué avec le projet)
• COMPOSE_PROJECT_NAME de l'environnement
• COMPOSE_PROJECT_NAME from .env (obsolète)
• nom du répertoire

De cette façon, les utilisateurs finaux peuvent toujours remplacer un nom de projet dans .dockerproject même si quelqu'un l'a codé en dur dans un docker-compose.yml distribué.

MISE À JOUR: Je pourrais aussi vivre avec l'utilisation de .dockerenv ou docker.env au lieu de .dockerproject . Mais il devrait avoir une priorité plus élevée pour résoudre le problème, que certains ici doivent remplacer les noms de projet codés en dur dans docker-compose.yml .

Salut à tous,

Tout d'abord, merci @dnephin et @ shin- pour avoir examiné ce cas. Le changement que @ shin- a soumis semble être un grand pas en avant pour résoudre ce problème.

J'ai validé le PR 5378 sur le projet de test pour le cas d'utilisation suivant: A default project name defined by the project, that can be checked in (https://github.com/docker/compose/issues/745#issuecomment-282858900). Pour cela j'ai fait un repo git illustrant différentes possibilités: https://github.com/estarter/compose_745

J'ai trouvé PR # 5378 couvrant partiellement le cas d'utilisation. Le problème est que la solution nécessite la variable COMPOSE_X_PROJECT_NAME env. Solutions possibles:

1. conserver la variable env dans le dossier du projet. J'ai essayé le fichier .env mais cela ne fonctionne pas lorsque docker-compose est appelé depuis un autre emplacement (voir l' exemple de commandes , composer des fichiers )
2. définir COMPOSE_X_PROJECT_NAME globalement (.profile ou équivalent). Cela fonctionnerait mais cela ne peut pas être spécifié dans le projet, c'est à dire que ce n'est pas une solution pour notre cas d'utilisation defined by the project, that can be checked in
3. y a-t-il une autre option?

J'espère que j'ai réussi à illustrer le cas d'utilisation qui est abordé ici.

Chers responsables, veuillez considérer comment le cas d'utilisation est résolu par PR # 5369 qui introduit la propriété optionnelle project_name dans le fichier docker-compose. Cette propriété est de faible priorité mais ne dépend pas de l'environnement ou du répertoire de travail.

1. y a-t-il une autre option?

Il existe cette option docker-compose --project-directory <PATH> (Spécifiez un autre répertoire de travail). Devrait également fonctionner avec un fichier .env .

Pour ajouter un autre cas d'utilisation nuancé au mix:
Dans mon cas d'utilisation, j'ai deux référentiels, un pour le projet principal (utilisé pour construire / déployer) et un pour devops (contenant le Dockerfile, docker-compose.yml, etc.)
Dans notre configuration actuelle, le dépôt principal du projet est à la racine ./ et le dépôt devops est extrait dans un sous-répertoire ./devops/

Dans cette configuration, l'utilisation d'un fichier .env ne fonctionne pas car il doit être:

placé dans le dossier où la commande docker-compose est exécutée (répertoire de travail courant).
(réf doc)

Ce qui ne fonctionne pas, car il est appelé comme: docker-compose -f devops/docker-compose.yml
Bien sûr, nous pouvons ajouter le paramètre -p ici, qui est ce que nous utilisons actuellement, mais il est sujet à l'erreur humaine comme cela a été mentionné ci-dessus.

Si le fichier .env (ou proposé docker-compose.env) pouvait être lu à partir du même répertoire où réside le docker-compose.yml, alors définir le nom du projet là-bas fonctionnerait pour moi.

L'utilisation de la directive env_file dans le fichier docker-compose.yml ne fonctionne pas, car ces variables d'environnement ne sont appliquées qu'à l'intérieur du conteneur, pas à la création des conteneurs.

En fin de compte, mon objectif est de garder mes fichiers liés aux devops autonomes d'une manière qui ne pollue pas la base de code de mon projet, mais qui peut toujours être accédée / exécutée en parallèle avec ce dépôt.

Il y a cette option docker-compose --project-directory(Spécifiez un autre répertoire de travail). Devrait également fonctionner avec un fichier .env.

@ schmunk42 pourrait être une bonne --project-directory ne fonctionne pas pour le fichier .env. J'ai essayé comme suit, le fichier .env a été ignoré ( fichiers de projet ):

docker-compose -f PR_5378/docker-compose.yml -f PR_5378/docker-compose2.yml --project-directory PR_5378 down

À l'avenir, je supprimerai les commentaires qui ne contribuent pas à la conversation de manière constructive. Je n'ai aucun intérêt à interagir avec les enfants.

En ayant un nom .env réglable
Le problème avec une variable d'environnement désignant le fichier .env à utiliser est qu'il s'agit essentiellement d'une dépendance circulaire. Nous devrions introduire une exception dans la manière dont les variables d'environnement sont interprétées, ce qui, bien que raisonnable, est intrinsèquement contre-intuitif.

Sur le nom .env lui-même
Il est maintenant évident que le nom .env est utilisé par une multitude de logiciels et de frameworks, et n'est généralement pas destiné à être validé dans le contrôle de version. Nous sommes très sensibles aux changements de rupture, mais nous pourrions introduire un nom alternatif (par exemple docker-compose.env ) avec un retour au fichier .env si l'ancien n'existe pas, avec l'intention que il peut être partagé avec d'autres utilisateurs.

Lors de l'ajout de project_name au fichier de composition
Nous avons déjà réitéré notre position à ce sujet à plusieurs reprises - voir le dernier commentaire de Daniel pour certaines des raisons pour lesquelles nous nous opposons à ce changement. Ce n'est pas que ce soit difficile. Ce n'est pas que nous n'y avons pas pensé. Nous avons passé beaucoup de temps à l'évaluer, et nous pensons que la qualité du projet en souffrirait trop pour justifier son ajout (sous cette forme). De manière réaliste, # 5378 est probablement la meilleure concession que nous puissions faire pour que cela fonctionne d'une manière opt-in et rétrocompatible (EDIT: Bien sûr, je suis ouvert aux suggestions qui améliorent cette proposition dans ces paramètres)

Sur --project-directory
Un peu tangente, mais je sais que cette option est un peu cassée en ce moment. Rétrospectivement, j'aurais préféré ne pas l'ajouter du tout, car cela crée plus de problèmes qu'il n'en résout. Je vais essayer de passer un peu de temps pour voir si c'est réparable, mais il y a beaucoup de cas de bord étranges qui le rendent vraiment peu fiable.

Cela dit, y a-t-il quelqu'un pour qui docker-compose.env + # 5378 ne serait pas une solution satisfaisante? Je comprends que ce n'est peut-être pas votre solution préférée, mais je vous demande si vous faites des concessions raisonnables auxquelles vous pouvez faire face.

Blague à part ...

Je ne comprends toujours pas comment le dernier commentaire de Daniel se rapporte à la "qualité du projet". De plus, c'est une règle générale selon laquelle l'ajout d'une clé à un dictionnaire ne devrait jamais entraîner de rupture de compatibilité descendante. Il y a toujours des cas où les programmeurs ont mis en œuvre des choses d'une manière que ce n'est pas le cas, mais je m'éloigne du sujet.

Je pense que le camp qui veut le champ project-name (ou autre) est justifié, car le "nom" du projet est fondamental pour de nombreux aspects de l'outillage. Les personnes de ce camp voudront peut-être simplement écrire ce nom quelque part dans la pierre pour éviter les problèmes avec des solutions plus temporaires telles que des variables d'environnement ou des commandes telles que des indicateurs.

J'espère que cela a été constructif.

@estarter Je considérerais cela comme un bogue, cela vaut peut-être la peine d'ouvrir un problème séparé pour cela

En fait, je m'attendrais à ce que cela fonctionne avec le fichier .env dans le répertoire PR_5378 :

docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

Lors de l'ajout de nom_projet au fichier de composition

@ shin- Il semble que la décision soit déjà prise. Mais j'essaie toujours de comprendre le contexte. J'ai déjà posé cette question et je n'ai jamais obtenu de réponse (ce qui est l'une des raisons pour lesquelles la discussion m'a semblé si ennuyeuse).

Pourriez-vous s'il vous plaît m'aider à comprendre, pourquoi nous avons container_name et même network dans docker-compose.yml ? Le premier pourrait également être source de conflits potentiels. Et ce dernier est très spécifique à l'hôte. Selon votre logique, ces deux (et d'autres) ne devraient pas être là non plus. Je ne vois pas la différence avec project_name .

S'il vous plaît, n'ignorez plus cette question.

@ michael-k Dites-vous que project_name est identique à container_name ? Si vous le dites, je voudrais vous informer qu’un projet peut être constitué de plusieurs conteneurs. Ou vous ai-je mal compris?

Alors que pour network , ce n'est pas nécessairement spécifique à l'hôte. Il existe de nombreux cas où un projet nécessite un réseau central isolé dans lequel un conteneur interagit avec un autre réseau. Et ses configurations sont stockées dans le docker-compose.yml .

@AyushyaChitransh Vous avez mal compris. La question est la suivante: pourquoi container_name , network et autres dans docker-compose.yml alors que project_name ne devrait pas être autorisé à y être? Ils partagent tous le même potentiel de conflit ou de configuration spécifique à l'hôte qui ne doit pas être partagé.

@aan et je connais cette opportunité. De plus, on pourrait dire la même chose des noms de conteneurs, mais nous avons la possibilité de définir le nom du conteneur dans le fichier de composition, non?

Oui, mais je ne pense pas que l'ajout soit une bonne idée.

À partir d'une discussion connexe Spécifiez le nom du réseau dans le fichier docker-compose .

@estarter Je considérerais cela comme un bogue, cela vaut peut-être la peine d'ouvrir un problème séparé pour cela

@ schmunk42 je vois que les responsables en sont conscients - voir On --project-directory dans le commentaire de Joffrey plus # 4709, # 4933 et # 4841

En fait, je m'attendrais à ce que cela fonctionne avec le fichier .env dans le répertoire PR_5378:
docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

Vous avez supposé que --project-directory affecte le paramètre -f .
En fait ce n'est pas le cas, cette commande donne IOError: [Errno 2] No such file or directory: u'./docker-compose.yml'

C'est très bien que --project-directory n'affecte pas -f - sinon imaginez ce que serait un cauchemar d'utiliser --project-directory et plusieurs fichiers docker-compose dans des répertoires différents.

Je suis très surpris de voir autant de délibérations sur quelque chose que je considère comme un problème résolu.

Voici l'ordre de priorité que j'ai l'habitude de voir:

1. codé en dur
2. option cli
3. environnement
4. project.rc
5. défaut sensé

Pour project_name nous n'avons actuellement ni l'option # 1 ni l'option # 4. C'est le problème fondamental auquel les gens sont confrontés et il semble facile à résoudre d'une manière rétrocompatible.

Nous semblons avoir des arguments philosophiques sur la pureté qui pourraient ne pas être utiles. L'utilisation d'un schéma de configuration en cascade OSS très courant, en revanche, est très utile.

Nous semblons avoir des arguments philosophiques sur la pureté qui pourraient ne pas être utiles.

Cependant, avoir cet argument n'est vraiment pas le but. Dès le départ , nous avons été très clairs sur notre position concernant la définition du nom du projet dans le fichier Compose.

Mais laissez-moi être transparent à ce sujet. Cela ne se produira jamais dans docker-compose . Si c'est le seul chemin de résolution que vous êtes prêt à accepter pour ce problème, vous devrez alors suivre le processus même de l'OSS qui consiste à créer le projet et à le faire vous-même. Le code est disponible et partagé avec une licence très permissive.

Pourriez-vous s'il vous plaît m'aider à comprendre, pourquoi nous avons container_name et même network dans docker-compose.yml? Le premier pourrait également être source de conflits potentiels. Et ce dernier est très spécifique à l'hôte. Selon votre logique, ces deux (et d'autres) ne devraient pas être là non plus. Je ne vois pas la différence avec project_name.

Pour container_name , cette option a été introduite très tôt dans la durée de vie du projet. Comme @ schmunk42 l'a souligné, si nous devions tout recommencer, ce ne serait certainement pas dans les spécifications. Il est constamment mal utilisé et a été la source d'innombrables problèmes pour les utilisateurs au fil des ans.
Quant à network , je ne suis pas tout à fait sûr de savoir comment cela se compare dans votre esprit?

Qu'en est-il de l'option 4 que j'ai mentionnée? J'ai vu des discussions sur l'introduction d'un .docker-compose pour les paramètres spécifiques au répertoire local. Ce serait de loin préférable (imo) à l'introduction des indicateurs d'environnement _x_ (qui nécessitent toujours une gestion d'environnement).

Ce serait comme ça:

# <my-project-dir>/.docker-compose
project_name: foobar

Ce qui précède est distinct de l'option de variable d'environnement et est inférieur dans la liste de priorité.

Cela résout bien mon cas d'utilisation et coche un autre chemin de configuration standard de la liste.

@thedeeno Dans notre esprit, COMPOSE_PROJECT_NAME dans le fichier .env accomplit déjà cela (avec le même ordre de priorité que dans votre plan). Cependant, nous vous avons entendu dire que .env est un mauvais choix de nom, c'est pourquoi nous considérons docker-compose.env comme alternative. Cela marcherait-il pour toi?

Dans notre esprit, COMPOSE_PROJECT_NAME dans le fichier .env accomplit déjà cela

@ shin- c'est là que nous ne sommes pas d'accord. Je ne pense pas que ce soit le cas.

Personnellement, j'aime que nous recherchions le fichier .env . C'est un endroit très conventionnel pour mettre des secrets locaux et d'autres configurations spécifiques au matériel local.

Cela fonctionne très bien pour aider avec number 3 ci-dessus, la configuration basée sur l'environnement.

Cela ne nous donne pas de hachures d'échappement ( number 4 ) lorsque nous ne voulons pas que l'environnement possède le nom du projet.

Dans mon cas, nos développeurs auront chacun leur propre fichier .env (pas VC). Il contient des secrets à injecter dans docker-compose.yaml . Aime ça.

Nous ne voulons cependant pas que les développeurs aient le contrôle sur le nom du projet, car il est fortement couplé à certains outils. Puisque .env n'est pas dans le contrôle de version, nous devons demander à nos développeurs de définir manuellement COMPOSE_PROJECT_NAME avec cette approche; et c'est la _une chose_ pas comme les autres, car ce n'est pas un secret.

Malheureusement non, changer simplement le chemin source par défaut du .env ne nous aiderait pas ici. Nous adorons le fait que .env provienne automatiquement. Nous ne voulons tout simplement pas spécifier le nom du projet de cette façon.

Je vais montrer un cas d'utilisation de ma pratique:

J'utilise le fichier .env pour spécifier la version de l'image, et pour éviter une analyse étrange de sed / awk / perl / quelle que soit l'analyse, je remplace simplement la valeur dans CI:

    echo APP_VERSION=$CI_COMMIT_REF_NAME > .env
    docker-compose pull
    docker-compose up -d

plus tard dans docker-compose.yml , l'image est spécifiée comme suit:

    image: my.registry.example.net/app:${APP_VERSION}

maintenant, si j'ai besoin de plus de variables de ce type, je dois faire quelques analyses, sauf si plusieurs fichiers .env sont pris en charge.

alors, peut-être aussi ajouter le support "répertoire", comme: docker-compose.env.d/* ou .docker-compose.env.d/* ou docker-compose.d/* .

mais en tant que tel, glob peut créer instantanément des problèmes de sauvegarde de l'éditeur correspondant ( *~ , *.bak ), il est préférable d'utiliser une extension à la place: docker-compose.env.d/*.sh

... mais là encore, peut-être simplement le rendre configurable dans docker-compose.yml quels fichiers au niveau racine .env sont chargés, ou cela introduirait un problème d'oeuf de poule? je ne sais pas comment fonctionne l'analyseur de configuration :)

un peu hors-sujet, mais COMPOSE_PROJECT_NAME env ne permet pas de contrôler entièrement le préfixe, il serait toujours dépouillé pour correspondre à A-Za-z0-9_ ... je voulais utiliser - dans mon préfixe. (Je ne trouve pas où j'ai signalé cela pour le moment, mais afaik ce n'est pas abordé)

il serait logique d'autoriser les mêmes caractères auxquels docker se limite.

@glensc C'est beaucoup d'infrastructure pour gérer l'environnement. Personnellement, je ne pense pas que ce soit la responsabilité de docker-compose .

La seule chose que j'ai vue d'autres projets est de générer automatiquement .env

@glensc @thedeeno Donc, idéalement, nous aurions deux fichiers *.env , l'un destiné à être partagé avec d'autres utilisateurs, et l'autre gardé privé, le dernier remplaçant le premier lorsque les deux définissent la même variable?

J'ai abordé les noms configurables .env dans mon commentaire la semaine dernière.

Avoir un docker-compose.env (tout en étant toujours privé de sourcing automatique .env ) fonctionnerait très bien pour nous!

Nous le traiterions comme un fichier rc et le confierions au contrôle de source.

Je pense qu'avoir des fichiers env publics / privés résout probablement la plupart des cas d'utilisation mentionnés ici. si - était également autorisé dans le nom du projet, ce serait génial.

@thedeeno @glensc Pourriez-vous s'il vous plaît donner un cas d'utilisation où vous avez besoin d' un fichier ENV privé remplaçant les valeurs dans le fichier public?

Les secrets ne doivent pas être définis dans docker-compose.env , car ils ne seront pas transmis automatiquement aux conteneurs. Vous pouvez toujours utiliser un fichier .env et en faire ce que vous voulez. Mais il me semble déroutant de mélanger les paramètres pour docker-compose et les conteneurs dans la pile.

@ schmunk42 Je n'ai pas ce cas d'utilisation donc je ne serai pas d'une grande aide. J'ai juste besoin de valider le project_name pour le contrôle de version. docker-compose.env résout cela.

Je ne suis pas sûr de suivre votre deuxième paragraphe. Nous utilisons .env pour les secrets et les injectons manuellement dans docker-compose.yaml .

@ schmunk42 https://github.com/docker/compose/issues/745#issuecomment -346491062

c'est juste parce que le SEUL endroit pour définir la ${variables} pour image semble être .env fichier

@glensc D'accord!

Mais à la place, je proposerais docker-compose.override.env pour l'aligner avec la fonctionnalité de remplacement actuelle pour les fichiers yml .

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

Je ne suis pas sûr de suivre votre deuxième paragraphe. Nous utilisons .env pour les secrets et les injectons manuellement dans docker-compose.yaml.

@thedeeno Je suppose que vous faites ceci:

environment:
  - ${SECRET_VAR_FROM_DOTENV}

ce qui devrait également être possible avec docker-compose.override.env . Ou vous pouvez faire:

env_file:
  - .env

Suggérez-vous de supprimer .env en faveur d'une composition plus spécifique à docker
chemin?

Si nous sautons le sourcing automatique de .env, cela aura un impact négatif sur mon
flux de travail de l'équipe. Nous nous appuyons sur ce fichier pour d'autres outils. Nous finirions
mettre nos secrets en deux (.env et cet autre fichier que vous suggérez)
place si docker-compose arrête de regarder .env.

Le jeu.23 novembre 2017 à 01:15 Tobias Munk [email protected]
a écrit:

@glensc https://github.com/glensc D'accord!

Mais à la place, je proposerais docker-compose.override.env pour l'aligner avec
la fonctionnalité de remplacement actuelle pour les fichiers yml.

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

Je ne suis pas sûr de suivre votre deuxième paragraphe. Nous utilisons .env pour les secrets et
injectez-les manuellement dans docker-compose.yaml.

@thedeeno https://github.com/thedeeno Je suppose que vous faites ceci:

environnement:

• $ {SECRET_VAR_FROM_DOTENV}

ce qui devrait également être possible avec docker-compose.override.env. Ou toi
pourrait faire:

env_file:

• .env

-
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/745#issuecomment-346538315 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AAFIdxtbI7y3wW2TFa401Go6Msj0gC74ks5s5Q1vgaJpZM4DLBNs
.

Suggérez-vous de supprimer .env en faveur d'une composition plus spécifique à docker
chemin?

Pas nécessairement, pour BC docker-compose pourrait toujours regarder .env si les autres ne sont pas trouvés, comme pour fig.yml une fois. Bien qu'il puisse être difficile de décider des cas suivants:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

.env ne serait pas utilisé dans le dernier cas, mais je ne sais pas comment gérer les deux premiers, car certains utilisateurs utiliseraient .env comme remplacement, d'autres comme solution de secours.

Pour moi .env devrait être utilisé dans tous les cas. C'est un fichier avec une signification particulière
dans l’écosystème plus large.

Dans votre troisième cas, c'est juste le fichier avec la priorité la plus basse.

Tout ce dont j'ai besoin est un moyen de valider le nom de mon projet dans le contrôle de code source. Je ne
attention particulière à l'environnement en cascade plus sophistiqué
la gestion. Je préférerais en fait que cette stratégie de nom de projet n'ait rien à
faire avec les variables d'environnement.

Si un fichier de configuration est hors de la table et qu'il existe un moyen de valider mon
nom_projet avec cette cascade d'env que vous parlez, je vais l'utiliser avec plaisir
bien que!

Le jeu.23 novembre 2017 à 01:31 Tobias Munk [email protected]
a écrit:

Suggérez-vous de supprimer .env en faveur d'une composition plus spécifique à docker
chemin?

Pas nécessairement, pour BC, docker-compose pourrait toujours regarder .env si le
d'autres ne sont pas trouvés, comme avec fig.yml une fois. Bien que cela puisse être
difficile de décider les cas suivants:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

.env ne serait pas utilisé dans le dernier cas, mais je ne sais pas comment gérer
aux deux premiers, puisque certains utilisateurs utiliseraient .env comme remplacement, d'autres comme
se retirer.

-
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/745#issuecomment-346539891 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AAFId95kZQIsiWp488JyPQOtGJju0OPbks5s5RFbgaJpZM4DLBNs
.

Quant au réseau, je ne suis pas tout à fait sûr de savoir comment il se compare dans votre esprit?

@tibia-

services:
    web:
        build: ./
        networks:
            - my_project_network_on_my_localhost
networks:
    my_project_network_on_my_localhost:
        external: true

Je suppose que je me trompe, car je n'engage jamais mon docker-compose.yml dans mon repo. Il contient toujours des paramètres très spécifiques à l'hôte. Il peut avoir un contenu assez différent lors du développement d'une production.

Je suis fan de "4 project.rc" même si j'utiliserais probablement quelque chose comme docker-project.yaml au lieu d'un format différent. C'est exactement ce que décrit le problème d'origine. En ce qui me concerne, toute discussion sur l'insertion du nom du projet dans le fichier de composition devrait faire l'objet d'un autre numéro.

Tout ce dont j'ai besoin est un moyen de valider le nom de mon projet dans le contrôle de code source.

C'est encore un point que je ne comprends pas. Il ne devrait y avoir aucune raison d'exiger un seul nom de projet codé en dur. S'il existe un outil externe qui attend un nom cohérent, pourquoi cet outil ne définit-il pas un nom de projet avant d'appeler docker-compose ?

my_project_network_on_my_localhost me semble faux. Pourquoi avez-vous besoin du nom du projet dans un réseau externe? Il n'a pas besoin de correspondre au nom du projet de composition.

my_project_network_on_my_localhost me semble faux.

Ce n'était qu'un exemple. J'ai une configuration de réseau différente sur ma machine de développement locale que sur un serveur de production. De nombreux autres paramètres dans mon docker-compose.yml diffèrent également régulièrement de la production, par exemple j'ai des conteneurs utilitaires définis là pour construire des éléments spécifiques au projet ou maintenir une base de données ou autre.

Si j'ai bien compris, l'idée principale derrière docker-compose (ou mieux fig ) était de bien organiser toutes ces longues options de ligne de commande docker pour une configuration de conteneur complexe dans un fichier yaml simple. C'est pourquoi cela semble si étrange, qu'il n'y ait qu'une seule option laissée de côté. Mais il semble que j'ai manqué d'une manière ou d'une autre que ce n'est plus l'idée principale derrière tout cela.

De nombreux autres paramètres dans mon docker-compose.yml diffèrent également régulièrement de la production, par exemple, j'ai des conteneurs utilitaires définis pour créer des éléments spécifiques au projet ou maintenir une base de données ou autre.

Nous avons le même flux de travail ici. Dans notre cas, la définition «commune» de docker-compose ne résume presque rien , mais ce sont les seules choses qui sont vraiment partagées entre le développement, les tests, la mise en scène et la production.
Les principales parties des paramètres de développement sont définies dans un fichier séparé, la fusion automatique se fait via un fichier .env . C'est la même chose pour la configuration de test .

Parce que c'est dans un dossier dans notre cas, nous pouvons faire quelque chose comme

(cd tests && docker-compose up -d)
(cd tests && docker-compose ps)
(cd tests && docker-compose run php codecept run)

pour tester ... ou ceci

(cd production && docker-compose logs -f --tail 100)

pour la production (Bonus: vous pouvez définir DOCKER_HOST en production pour pointer vers une autre machine, mais uniquement avec docker-compose ).

Mais oui, c'est un dossier, pas un fichier - et nécessite cp .env-dist .env dans deux endroits pour travailler, sinon il échoue avec un fichier de composition invalide. En fait, je voulais juste partager ce flux de travail soigné IMHO.

C'est encore un point que je ne comprends pas. Il ne devrait y avoir aucune raison d'exiger un seul nom de projet codé en dur. S'il existe un outil externe qui attend un nom cohérent, pourquoi cet outil ne définit-il pas un nom de projet avant d'appeler docker-compose?

@dnephin Il y a des raisons.

Oui, il y a des solutions de rechange. La demande est de le rendre plus pratique et prévisible.

Voici un exemple où un nom de projet codé en dur aide: la configuration du docker de traefik crée par défaut des règles d'hôte pour les conteneurs au format suivant: <service>.<project>.<domain> . Ce formatage n'est pas facile à modifier. Il est très avantageux pour nos développeurs d'utiliser les mêmes fqdns pour nos services docker-compose. Ce serait formidable si nous pouvions utiliser la configuration sans configuration, car elle est la seule façon de garantir la cohérence est de: a) les forcer à utiliser un nom de répertoire spécifique pour leur clone b) spécifier manuellement les règles pour traefik. Les deux sont nulles.

En voici une autre: faire référence à des images créées avec docker-compose. Si nous ne pouvons pas garantir le nom du projet, nous ne pouvons pas garantir ces noms d'image et ne pouvons pas les référencer avec confiance. Bien sûr, nous pouvons coder en dur le image_name pour chaque définition, mais cela semble franchement redondant parce que nous _voulons utiliser la convention_, mais nous craignons simplement que les développeurs qui choisissent d'utiliser des noms de fichiers différents aient des échecs très surprenants dans nos outils.

Les gars, tant de discussions ... quel est le statut de cela, puis-je définir le nom de projet par défaut dans mon fichier .docker-compose ?
Ou encore besoin de plus de discussions dans ce fil?

Stocker le nom du projet dans docker-compose.yml fichier

Ce serait formidable de le stocker dans le même fichier YAML mais éventuellement de le remplacer si nécessaire.

Je pense que le cœur de ce problème vient du fait que le nom du projet par défaut est simplement (devrais-je dire _naively_?) Pris comme nom de base du répertoire actuel. Cela compresse efficacement l'espace de noms du système de fichiers (hiérarchique) en un espace plat, ce qui pose problème en raison des conflits de noms. Par exemple, cela pose des problèmes aux personnes exécutant des services dans ~/fooproject/master et ~/barproject/master .

Je pense que les noms de projets sont sans importance. Alors peut-être qu'un moyen de rendre docker-compose robuste est de générer des noms de projets basés sur le chemin complet (ie home_flaviovs_fooproject_master )?

J'aime l'idée persistante, cependant. Pouvoir valider le nom du projet dans Git est un cas d'utilisation courant. Peut-être que lire un fichier .env.default avant .env est une solution simple pour cela (quel BTW prendrait également en charge le # 210 de longue date)?

J'ai résolu ce problème en enveloppant le binaire docker-compose avec ma propre fonction afin que je puisse appeler la fonction de n'importe où. Cela charge le fichier .env et utilise le bon fichier docker-compose n'importe où.

Évidemment, vous pouvez étendre cela pour avoir une fonction par projet ou quelque chose. Je pense qu'il pourrait y avoir des inconvénients, mais je ne les ai pas découverts.

DEFAULT_DOCKER_COMPOSE=~/my-project

function dcompose() {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    /usr/local/bin/docker-compose $@;
    popd &> /dev/null;
}
## maintain auto complete
function _dc {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    _docker_compose;
    popd &> /dev/null;
}

complete -F _dc dcompose

J'ai un problème avec la collision d'images, et il semble vraiment étrange que je ne puisse pas définir project_name dans le docker-compose.yml car cela semble très logique et une solution directe. En fait, prendre le nom du dossier du projet en premier lieu était une mauvaise idée. Dans de nombreux cas, les dossiers de projets peuvent être comme / home / project1 / repository, / home / project2 / repository et ainsi de suite, dans ce cas, docker a généré les mêmes noms d'images que repository_app.

@vedmant Vous pouvez définir le nom de l'image dans docker-compose.yml , utilisez simplement image et build .

Alors ... Que diriez-vous maintenant séparés par des projets sur un dossier du même nom?

docker-compose -f /foo/bar up -d
docker-compose -f /foo/foo/foo/bar down

Peut-être que cela a déjà été proposé. mais pourquoi ne pas faire un changement radical dans version: 4 et ajouter un nouveau mot-clé pour permettre de définir le nom du projet à partir de docker-compose.yml ?

mon .docker-compose / nom-de-projet n'a pas fonctionné ...
--project-name a fonctionné

Je voudrais également définir le nom du projet dans le fichier docker-compose.yml.

Mon cas d'utilisation est, j'ai un fichier docker-compose.yml qui a une application Web et un service de base de données postgress.
Je veux aussi des fichiers docker-compose.yml séparés pour les tâches adhoc - décrivant essentiellement les tâches adhoc que j'aimerais orchestrer avec docker-compose. Ces tâches ad hoc doivent tirer parti des mêmes services / réseaux / volumes que ceux utilisés dans le projet principal.

Un exemple de tâche ad hoc que j'aimerais orchestrer avec docker-compose pourrait être. migration des données dans la base postgress données

Donc, pour y parvenir, je peux créer un fichier docker-compose.adhoctask.yml séparé pour représenter la tâche, afin que je puisse exécuter cette tâche à la demande uniquement lorsque cela est nécessaire. Parce qu'il se trouve dans le même répertoire que le fichier original de docker-compose, il obtient le même nom de projet par défaut et a donc accès aux mêmes réseaux, volumes, etc.? et tout fonctionne.

Cependant, le problème survient lorsque je ne veux pas que ce fichier yml de tâche adhoc vive dans le même répertoire de niveau supérieur (ou même le même dépôt) que le docker-compose.yml . Par exemple, je veux peut-être mettre la tâche ad hoc docker-compose.adhoc.yml dans un sous-dossier, avec les DOCKERFILE et les actifs dont la tâche a besoin bien isolés / regroupés, car c'est sa propre préoccupation. Dès que je le déplace dans un sous-dossier, son nom de projet ne correspond plus. Cela signifie qu'il n'a plus accès aux mêmes volumes / réseaux, etc. définis dans le projet principal.

Si je pouvais spécifier les projectname dans les docker-compose.yml et docker-compose.adhoc.yml - alors je pourrais les structurer comme je veux (même les mettre dans des repo séparés) et toujours les exécuter sans avoir à Spécifiez constamment des arguments de ligne de commande supplémentaires ou changez de variables d'environnement.

C'est un vrai problème pour moi, car cela provoque des conflits de noms

J'ai plusieurs projets dans la structure

/company
    /ab   # project prefix
        /backend   # actual project
        /webapp
    /cd
        /backend
        /webapp

maintenant, lorsque je lance un docker-compose dans un projet, il crée un réseau backend_default et des préfixes de conteneurs qui ne sont pas explicitement nommés avec backend_ .. maintenant Si je veux démarrer l'autre projet, j'ai pour revenir au bon dossier et exécuter d'abord docker-compose down pour éviter les conflits - sinon, il créerait de nouveaux conteneurs dans le même réseau, puis en les désactivant, il se plaindrait d'orhans, quand il n'y en a pas.

Aussi un problème pour moi. J'ai plusieurs projets et j'utilise docker-compose pour des stands de démonstration dynamiques sur une seule machine, un support par branche.

/project-1
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside
    /feature
        /new-feature # docker-compose.yml inside
/project-2
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside

Ainsi, "maîtres" et "développeurs" sont en conflit entre les projets. Un fichier .docker-compose pourrait résoudre ce problème.

@simplesmiler Au risque de me répéter, un .env résout déjà cela.

@ shin- .env est souvent utilisé pour les secrets qui ne sont pas dans le contrôle de version.

Ce que @simplesmiler veut, c'est un moyen de valider le nom du projet dans le contrôle de version _ tout en gardant .env dehors du contrôle de version_.

Pour autant que je sache, il n'y a toujours aucun moyen de le faire facilement.

@thedeeno ce n'est pas ce que leur message dit. Travaillez-vous ensemble? Sinon, nous ne devrions pas présumer que le cas d'utilisation de quelqu'un d'autre est au-delà de ce qui est explicitement écrit.

Nous ne travaillons pas ensemble. C'est mon interprétation de leur problème. Tout à fait juste, je me trompe peut-être et je présume.

J'aurais aimé que nous travaillions ensemble pour que nous puissions prendre un café. J'espère que vous ne pensez pas que je suis un imbécile ici.

Peut-être que je me souviens de ce fil de manière incorrecte: existe-t-il un moyen de valider le nom du projet dans le contrôle de version tout en gardant .env ignoré?

Existe-t-il un moyen de valider le nom du projet dans le contrôle de version tout en gardant .env ignoré? Ou est-ce toujours une capacité manquante?

Pas actuellement. Comme je l'ai mentionné il y a quelques mois ^ 1, le plan est d'avoir docker-compose.env comme fichier d'environnement secondaire pouvant être inclus dans le contrôle de version. Il a quelque peu glissé dans la liste des priorités, mais j'espère y arriver bientôt.

1 / https://github.com/docker/compose/issues/745#issuecomment -345054893

Ce sont de bonnes nouvelles! Accepter les RP?

J'ai perdu espoir il y a longtemps, mais essayons à nouveau:

Je pense que beaucoup ici ne comprennent toujours pas pourquoi nous sommes obligés de maintenir un deuxième fichier pour ce paramètre.

Si je comprends bien, pour quelques-uns ici, cela rompt la configuration de leur projet. Mais pour la majorité dans ce fil, ce ne serait

Cela n'a même pas de sens en toute logique: l'absence de ce paramètre dans docker-compose.yml est si évidente que je ne pouvais même pas croire que cette option était manquante lorsque je l'ai recherchée dans le manuel. Presque tous les autres aspects de votre configuration peuvent y être configurés. Pour moi, c'est une rupture si claire dans la logique de configuration.

Je pense que l'on pourrait dire que (presque) tous les paramètres de docker-compose.yml sont "étendus" par le nom du

Comme suggéré dans # 4841, une option pour spécifier quel fichier .env utiliser (ie --env-file ) devrait être très utile.

@roipoussiere voir https://github.com/docker/compose/issues/4841#issuecomment -414543951

Merci @ schmunk42.
Mais cela signifie que je dois créer une hiérarchie comme:

.
├── project_a
│   ├── .env
├── project_b
│   ├── .env

au lieu de quelque chose de plus simple comme:

.
├── a.env
├── b.env

Oui, voir aussi https://github.com/docker/compose/issues/745#issuecomment -345054893 - vous devrez peut-être l'ouvrir dans une nouvelle fenêtre, car elle est parfois cachée ici : nerd_face:

J'appuie la proposition --env-file . J'ai fait un ticket juste pour ça. Allez-y et aimez-le si vous voulez cette option.

Je n'ai donc lu que quelques commentaires sur ce bogue / fonctionnalité, et le fait que la discussion se poursuive et qu'elle soit ouverte m'amène à la conclusion que cela fait 4 ans que cela a été initialement ouvert et qu'il n'y a toujours pas de solution? Pouvons-nous prendre une décision partielle et ensuite aller de l'avant ..?

J'admets que je n'ai pas lu tout ce numéro et toutes les questions connexes, mais il y a des problèmes intéressants autour de ce sujet qui rendent cela plus compliqué qu'il n'y paraît à première vue. Par exemple, comme nous le savons tous, .env est couramment utilisé pour les valeurs secrètes, donc vous l'ignorez généralement du contrôle de version.

Mais disons que vous travaillez avec Stripe, ce qui vous permet d'avoir des clés de test et des clés live, AKA. 2 jeux de clés avec lesquels travailler. En développement, il serait très courant que vous utilisiez les clés de test, et en production, vous finiriez par utiliser les clés dynamiques.

Cela signifie automatiquement que vous ne pouvez pas utiliser .env seul pour traiter les valeurs secrètes, car vous aurez des clés différentes dans chaque environnement, et vous ne voulez pas avoir à changer les valeurs de votre fichier entre l'exécution de votre app en dev ou prod (ce serait fou et très sujet aux erreurs).

Ce que vous finirez probablement par créer à la fois un fichier .env et .env.prod et ignorer les deux depuis le contrôle de version. De cette façon, vous pouvez avoir vos clés de test / dev en développement, puis les référencer avec env_file dans votre fichier de composition de développement.

Mais alors en production, vous faites référence à la fois .env et .env.prod dans votre fichier de composition de production.

Mais voyez-vous où cela va? Pour le moment, Docker Compose ne vous permet pas d'avoir des fichiers optionnels env_file . Si le fichier n'existe pas, Docker Compose va exploser dès que vous essayez d'exécuter Docker Compose.

Donc, vous avez automatiquement besoin d'un fichier .env pour exister à la fin si vous prévoyez de l'utiliser avec env_file et ce n'est pas limité à Stripe non plus. De nombreux frameworks Web ont certains paramètres spécifiques à l'environnement mais qui changeraient à la fois en développement et en production (par exemple SERVER_NAME avec Flask).

Cela signifie que nous sommes limités à avoir quelque chose comme un fichier .env_example que vous engagez dans le contrôle de version et il est prévu que l'utilisateur final renomme ce fichier en .env , puis à l'intérieur de ce fichier contiendra notre vieil ami COMPOSE_PROJECT_NAME .

Ce qui soulève maintenant la question. Avons-nous réellement besoin d'une autre manière de définir le nom du projet? Je ne suis pas convaincu que ce soit le cas, mais je suis convaincu que la définition d'un nom de projet personnalisé est une bonne idée dans n'importe quel projet, ou du moins autre chose que le nom du dossier, car vous pouvez facilement rencontrer des conflits de nom.

Ce problème est-il sur une feuille de route s'il vous plaît?

Le cas d'utilisation pour cela serait de modifier le COMPOSE_PROJECT_NAME dans le cas où votre projet a plusieurs fichiers docker-compose (par exemple un pour dev, test, peut-être une base, peut-être un test local, etc.) Vous pourriez avoir besoin de tourner jusqu'à 2 environnements très différents et séparés les uns des autres.

Dans notre cas, nous pouvons contourner cette limitation de docker-compose en créant le COMPOSE_PROJECT_NAME dans notre makefile.

Je voudrais voir cela configurable à partir du composant yaml lui-même.

Est-ce toujours ouvert? Oh mon Dieu...

Abonné. Je veux également pouvoir définir le nom du projet sur le fichier yaml de composition.

Cela prend une éternité 🤦‍♂

serait très utile d'avoir cette fonctionnalité

cette fonctionnalité serait la bienvenue dans le projet sur lequel je travaille

Ok, donc à partir de ce long fil de discussion, nous pouvons conclure que le nom du projet ne sera pas dans le fichier docker-compose.yml, car les principaux développeurs sont contre cela et ne fusionneront aucune requête de ce type.

Alors, pouvons-nous s'il vous plaît revenir à la proposition originale en haut de ce numéro: rendre le nom du projet persistant. Utiliser un fichier .docker-compose ou un répertoire .docker-compose me convient parfaitement. Mais ce serait bien si nous pouvions enfin progresser dans la mise en œuvre de cela.

J'ajouterais une variable ENV à cette liste d'alternatives.

Une racine substantielle de tout le désaccord est que ce fil / problème est que pour beaucoup de gens cela ne fonctionne pas s'il est dans une variable ENV. Ils veulent pouvoir le valider dans un repo (facultatif bien sûr, la recommandation standard peut être de ne pas le valider.)

L'avoir ENV plutôt que le contenu de yaml est en contradiction avec la philosophie de partage de fichiers yaml entre différents projets. En fait, il est officiellement documenté: https://docs.docker.com/compose/extends/ (voir "Exemples de cas d'utilisation" par exemple). Si vous utilisez un fichier yaml de base unique, puis remplacez les fichiers pour dev, test et prod, et que Dieu sait quoi d'autre, cela n'a aucun sens de l'exécuter sous le même nom de projet ou de définir le nom du projet par ENV / cli. Il créera simplement N * N combinaisons tandis que sur N sont valides.

J'ai parcouru plusieurs de ces discussions et j'ai vu une tonne de commentaires de personnes souhaitant que le nom du projet soit configurable dans le fichier YML. Mais pas un seul commentaire expliquant pourquoi cela ne devrait pas être fait. Ces discussions remontent à un long chemin.

En tant que personne à la recherche d'une solution facile à utiliser et constatant qu'il n'y a pas de moyen facile de définir le nom du projet qui ne nécessite pas une attention particulière de l'utilisateur à la ligne de commande exécutée (qui est en concurrence avec l'idée de base d'un outil pour lequel vous passer up et démarrer comme par magie un cluster complet de serveurs) - Je suis choqué que ce soit une question ouverte. S'il y avait une explication claire des raisons pour lesquelles la mise en œuvre est problématique ou préoccupante, je serais intéressé.

une solution élégante pourrait être d'utiliser un espace réservé dans la propriété container_name (et d'autres noms dynamiques tels que volume, réseau, ...)

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

avec une telle configuration, on pourrait utiliser

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

edit: ce n'est pas une solution parfaite, car cela va entrer en conflit pour les personnes qui utilisent 2 projets distingués dans le même nom de dossier

@jderusse

une solution élégante pourrait être d'utiliser un espace réservé dans la propriété container_name (et d'autres noms dynamiques tels que volume, réseau, ...)

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

avec une telle configuration, on pourrait utiliser

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

edit: ce n'est pas une solution parfaite, car cela va entrer en conflit pour les personnes qui utilisent 2 projets distingués dans le même nom de dossier

Je fais également cela et je pensais que cela résoudrait le problème de conflit, bien que nous devions toujours définir la variable COMPOSE_PROJECT_NAME sur une valeur unique sur le fichier .env .

À ce stade, je veux vraiment comprendre la raison pour laquelle les responsables rejettent les solutions. Il existe déjà une pull request pour une solution.

Une fois que nous savons ce qui ne va pas, nous pouvons travailler à le réparer. À ce stade, je ne vois aucun commentaire autre que «rejeté».

Nous avons ces 2 commentaires:

https://github.com/docker/compose/issues/745#issuecomment -345054893
https://github.com/docker/compose/issues/745#issuecomment -346487757

Mais je dois admettre que même en lisant ces commentaires, je ne comprends pas tout à fait pourquoi ne pas simplement ajouter le nom_projet au fichier yaml. Pour ceux qui pensent que cela rend leurs fichiers docker-compose.yaml moins généraux, ils ne devraient tout simplement pas mettre le nom dans le fichier yaml, mais laissez le reste d'entre nous avoir la possibilité de le faire.

OK, je fais de mon mieux pour lire les références à d'autres commentaires; J'apprécierais vraiment au moins une courte présentation faisant référence au contenu de la référence, en plus de la référence pour m'assurer que je lis la bonne chose et que j'obtiens le bon contenu.

Permettez-moi de résumer ce que je vois sont les préoccupations. Toute aide pour clarifier cela serait appréciée.

(1) L'ajout d'un nom de projet au fichier YML peut rendre le projet moins réutilisable car cela empêcherait, ou au moins compliquerait, l'exécution d'un fichier YML avec plus d'un nom de projet.
(2) "la qualité du projet en souffrirait trop pour justifier son ajout (sous cette forme)"
(3) "Si le nom du projet est dans le fichier de composition, deux projets pourraient utiliser le même nom, provoquant un conflit, ce qui interromprait les deux projets."

J'ai des réflexions à ce sujet, mais je vais attendre mes commentaires jusqu'à ce que nous puissions nous mettre d'accord sur les préoccupations à régler. Est-ce raisonnable?

(4) Implémentation de manière rétrocompatible (priorité / ordre des valeurs)

(1) L'ajout d'un nom de projet au fichier YML peut rendre le projet moins réutilisable car cela empêcherait, ou au moins compliquerait, l'exécution d'un fichier YML avec plus d'un nom de projet.

Encore une fois, il existe un moyen officiel de diviser la configuration en base et en fichier et héritée - https://docs.docker.com/compose/extends/. On n'a pas pu configurer le nom du projet dans la configuration de base.

Pour moi, le cas d'utilisation principal que je recherche est la capacité à exécuter plusieurs instances du projet localement (développement, environnements de test, etc.).

Peut-être que la solution est de vous permettre de définir le nom du projet explicitement ou un chemin de parcours.

Si je définis explicitement le nom du projet dans le fichier yaml comme my-project je peux simplifier les choses pour une seule instance d'un projet ou lorsque je fais quelque chose comme ajouter tous mes fichiers docker dans un dossier docker sur plusieurs projets.

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name: my-project)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name: some-other-project)

Mais cela n'aide pas avec plusieurs instances du même projet, alors que diriez-vous de faire quelque chose avec le parcours de chemin

project_name: ../(*) donc avec le même exemple

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_a)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b)
├── project_b_copy
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b_copy)

de même project_name: ../(../*)

.
├── dev
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=dev_project_a)
├── test
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=test_project_a)

comment spécifier le parcours devrait probablement être pensé un peu plus en profondeur que mon pouce, mais au moins en faisant cela, je pense que nous avons la flexibilité de couvrir tous les cas d'utilisation.

Seulement à moitié en plaisantant: cela signifie que pour configurer un nom fixe dans mon docker-compose.yml, je créerais un fichier avec le nom que je veux, puis définirais project_name: name-of-the-file-named-like-the-name-i-want ?

J'ai actuellement une charge de fichiers docker-compose dans le même répertoire. Comme dc-work.yml , dc-server.yml , etc., qui chargent tous des services différents et non liés.

Quand j'exécute docker-compose up dc-A.yml , puis que j'exécute docker-compose up dc-B.yml , Docker me dit qu'il y a des services orphelins en cours d'exécution (bien sûr qu'il n'y en a pas, c'est à cause du nom du projet).

N'y a-t-il vraiment aucun moyen de résoudre ce problème? Déplacer chaque fichier dc-A|B|C|etc.yml dans son propre répertoire, puis parcourir chacun pour charger tous mes services semble être une véritable perte de temps, ou est-ce que je manque quelque chose?

Pourquoi ce problème n'a-t-il pas été résolu? La solution claire et simple a été présentée par @ cr7pt0gr4ph7 ici: https://github.com/docker/compose/issues/745#issuecomment -182296139. Il a reçu beaucoup de votes. Chaque préoccupation a été abordée dans la discussion. Et, plus important encore, cela résout de nombreux problèmes pour beaucoup de gens. Ce qui donne?

Nous rencontrons également ce problème car nous utilisons une structure de répertoire de projet fixe avec un dossier .docker qui contient tous les éléments liés à docker, donc je me retrouve avec beaucoup de noms de projet .docker - je travaille sur une architecture de microservices il est donc normal d'en avoir plusieurs ... mais cette petite chose ne cesse de gêner -> aussi, PHPStorm etc. n'a pas la possibilité de passer l'argument -p / - project-dir et je ne peux pas vraiment utiliser un .env pour cela car, croyez-moi, définir la bonne valeur sera oublié ...

Développeurs, veuillez nous indiquer comment vous souhaitez qu'il soit résolu.

Peut-être ajouter une propriété au fichier docker-compose pour définir le nom du projet?

@AyushyaChitransh

Développeurs, veuillez nous indiquer comment vous souhaitez qu'il soit résolu.

Voici le meilleur résumé:
https://github.com/docker/compose/issues/745#issuecomment -182296139

Il y a eu beaucoup de discussions. Il n'est pas nécessaire de poursuivre la discussion. Les responsables du projet ont juste besoin de lire les threads (pluriel) et de faire le nécessaire.

Pour moi, c'est toujours ça: https://github.com/docker/compose/issues/745#issuecomment -248644429

Pour moi c'est toujours ça: # 745 (commentaire)

Oui, il existe une solution existante, mais médiocre. Ces commentaires ont été rejetés et les problèmes ont été clairement énoncés par beaucoup. Les commentaires liés ne répondent tout simplement pas à la plupart des préoccupations légitimes soulevées dans ces fils.

Tbh, c'est un peu discutable. Beaucoup d'entre nous sont passés à Kubernetes pour docker-compose fonctionnalité de type

@AyushyaChitransh
Nous voulons utiliser un mécanisme pour définir le nom du projet comme décrit ici: https://github.com/docker/compose/issues/745#issuecomment -182296139

1. Ligne de commande arg.
2. Variable d'environnement (fichier .env)
3. Dans le fichier Compose directement
4. Chemin du dossier

Ne pensez pas qu'il y ait d'objection à cela.

Il y a, il s'agit de portabilité, comme mentionné ci-dessus, en quelque sorte similaire lors de l'utilisation de container_name , qui ne devrait pas non plus faire partie du docker-compose.yml . Vous ne pouvez pas réutiliser la même configuration avec les paramètres existants.

Si votre flux de travail doit s'appuyer sur le chemin du dossier et que project-name est injecté dans votre configuration, par exemple. grâce à la fusion, plusieurs fichiers de composition, modèles, ... - vous vous retrouverez avec le même problème - écraser les piles existantes.

Désolé de dire cela, mais cela devrait être fermé comme wontfix .. (modifier) ​​ou publier une nouvelle version MAJEUR (!)

@ schmunk42

Si votre flux de travail repose sur le chemin du dossier et que le nom du projet est injecté dans votre configuration, par exemple. grâce à la fusion, plusieurs fichiers de composition, modèles, ... - vous vous retrouverez avec le même problème - écraser les piles existantes.

Premièrement, le nom du projet ne serait défini dans les fichiers de composition que par ceux qui en ont besoin et c'est précisément parce qu'ils veulent que les fichiers de composition fonctionnent avec les piles existantes. Vous pouvez ajouter votre avertissement aux documents autour de ce paramètre.
Deuxièmement, pour ceux qui reposent sur un nom de projet spécifique, considérez ceci:

1. Que faire si le fichier de composition est téléchargé à partir d'un dépôt git, puis lors du prochain commit, le propriétaire du dépôt le déplace vers un sous-dossier différent? Ou renommé le dossier dans lequel il se trouve? L'impact sur le flux de travail est déjà présent car les fichiers peuvent être déplacés et cela affecte le nom du projet.
2. Si vous comptez sur un nom de projet spécifique, nous avons proposé le mécanisme pour le garantir, soit en utilisant la variable d'environnement (fichier .env), soit en utilisant la ligne de commande arg lors de l'exécution de Docker compose - les deux remplaceraient toute valeur qui se trouvait dans le fichier de composition (si un fichier a été ajouté pour une raison quelconque).

Fermer ceci comme wontfix n'est pas très utile sans expliquer pourquoi ce qui précède n'est pas assez bon .. ou offrir un chemin vers une solution.

Je ne veux pas que mon flux de travail (ou plutôt le flux de travail de toute mon équipe) dépende du nom du dossier dans lequel ils extraient le code.

Mon principal problème avec la solution de fichier .env est que ce fichier doit être dans le répertoire de travail de l'exécution de la commande - alors que docker-compose résout le fichier de composition dans un répertoire parent. Il devient donc essentiel que tous les développeurs (A) extraient le code dans le dossier du même nom (en supposant un fichier docker-compose.yml à la racine d'un référentiel de code) ou (B) exécutent uniquement les commandes docker-compose dans le dossier racine du dépôt crée sinon des piles en conflit ou (C) ils ont des noms de pile différents et toute la documentation et les scripts doivent dire replace stack name here .

Si (C) est ce que docker suggère comme solution `` portable '' recommandée, la CLI docker-compose doit être complète avec les commandes CLI de docker et, même dans ce cas, je vois toujours un cas d'utilisation pour cette fonctionnalité.

Si votre flux de travail repose sur le chemin du dossier et que le nom du projet est injecté dans votre configuration, par exemple. grâce à la fusion, plusieurs fichiers de composition, modèles, ... - vous vous retrouverez avec le même problème - écraser les piles existantes.

Si un nom de projet est ajouté au fichier docker-compose, il est certainement là pour une raison (comme toutes les autres lignes d'un fichier docker-compose). Malheureusement, en ce moment, même en renommant simplement mon dossier extrait (sans effectuer de modifications suivies dans git), j'obtiens également un système cassé.

Je ne peux pas croire que nous sommes en 2020 et nous n'avons toujours pas résolu cet énorme cas d'utilisation. Ce n'est pas un changement radical, c'est une fonctionnalité totalement optionnelle et qui a tout son sens. Étant donné que Kubernetes est maintenant l'outil de déploiement par défaut pour docker, j'imagine que docker-compose pour voir principalement l'utilisation dans le développement / les déploiements locaux et avoir un fichier docker-compose à la racine d'un référentiel pour exécuter le code dans le dépôt localement est un très populaire cas d'utilisation.

@ dc-pm a écrit: "Étant donné que Kubernetes est maintenant l'outil de déploiement de facto pour docker"

Je n'écris plus de fichiers docker-compose. Il n'y a pas assez d'avantages pour quelque chose qui ne verra pas la production. Kubernetes a aussi ses bizarreries. Mais il est largement pris en charge par les fournisseurs de cloud.

À vrai dire, même gérer les conteneurs dans mon environnement de développement est trop compliqué au quotidien. Je viens de lancer les programmes ...

@ dc-pm a écrit:

Je ne peux pas croire que nous sommes en 2020 et nous n'avons toujours pas résolu cet énorme cas d'utilisation.

Ce n'est pas seulement que cela n'a pas été corrigé, mais que les développeurs refusent activement de le réparer.

Le problème, je soupçonne, est que les adolescents qui développent ce logiciel n'ont pas l'expérience approfondie pour comprendre les implications de ce cas d'utilisation, ou écouter le grand nombre de leurs utilisateurs plus expérimentés qui demandent qu'il soit traité. À ce stade, je doute qu'ils aient travaillé dans un environnement avec plus d'un stack, ou peut-être même en équipe. Sinon, franchement, _ ce serait une amélioration parfaitement évidente! _

Quelques rappels amicaux ...
Les développeurs open source ne sont pas vos "employés / collèges", dans la plupart des cas, ils travaillent principalement gratuitement.
Si c'est clairement un problème pour vous, prenez le temps de rechercher des solutions (et de pousser un PR).

Le blâme n'est pas la solution.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

C'est assez difficile de pousser un changement quand les développeurs y sont opposés ...

Le sam, 14 mars 2020 à 03:19, Antoine Gravelot [email protected]
a écrit:

Quelques rappels amicaux ...
Dans la plupart des cas, les développeurs Open Source ne sont pas vos «employés / collèges»
ils travaillent principalement gratuitement.
Si c'est clairement un problème pour vous, prenez le temps de rechercher des solutions
et pousser un PR.

Le blâme n'est pas la solution.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/docker/compose/issues/745#issuecomment-598991880 , ou
Se désabonner
https://github.com/notifications/unsubscribe-auth/ABAXP2DRD7H4YI7KQ7B2URLRHLLQ5ANCNFSM4AZMCNWA
.

@agravelot Je pense qu'il y a eu des PR, ce n'est peut-être pas l'idéal. Mais à travers toutes les discussions, les propriétaires s'attendent très clairement à ne pas vouloir cette fonctionnalité. Ce n'est pas une question de codage.

@agravelot désolé pour le retard. Et je ne voulais vraiment pas manquer de respect aux nombreuses personnes formidables et talentueuses qui contribuent ici. Mais blâmer un manque d'effort n'est pas non plus utile.

Je souligne simplement le soutien d'une idée qui n'a pas été écoutée à maintes reprises malgré un soutien clair sur une très longue période. Le point entier de ceci (et OSS en général) tel que défini dans notre code de conduite est de permettre aux gens de contribuer au code et d'être respectueux de toutes les idées.

Il y a déjà eu plusieurs pull requests créées mais si cela peut aider la situation, je suis très heureux d'en créer une autre.

Quelle serait une voie à suivre plus constructive?

Il y a déjà eu plusieurs pull requests créées mais si cela peut aider la situation, je suis très heureux d'en créer une autre.

Oui, les développeurs devraient continuer à les passer en revue, ou fermer ceci comme "Won't fix" (peut-être en argumentant) ... Garder cela ouvert pendant des années, sans commentaires officiels, c'est juste perdre le temps des contributeurs (au sens le plus large) ). C'est aussi un manque de respect, OMI.

Hé, les gars, en tant qu'utilisateur, je voulais simplement partager mon cas d'utilisation. J'ai donc 2 fichiers docker-compose.yml, un pour l'environnement de développement, un pour la production. Ils sont situés dans le même dossier. Ils ont tous deux un service avec le même nom - appelé "base de données". J'aimerais déployer ces deux services en même temps - simplement parce que je le peux, c'est de la conteneurisation dont nous parlons, je peux évoluer autant que je veux. Cependant, ils ont des valeurs "container_name" différentes.

Alors je cours:

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-server_autocat-dev" with the default driver
Creating database-dev ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-server_autocat-prod" with the default driver
Recreating database-dev ... done

Notez comment il est dit "Recréer la base de données-dev" alors que je fais clairement référence au service situé dans le projet "prod". Remplace en fait le conteneur existant. La base de données se termine et le conteneur est remplacé par ce dernier.

Je fais cela en partant du principe que des fichiers séparés "docker-compose.yml" signifient des projets séparés, mais apparemment ce n'est pas une chose dans la vraie vie. Le projet sur lequel le service est déployé est déterminé par l'emplacement du "docker-compose.yml". Pour les faire faire partie de projets séparés, je dois spécifier séparément le nom du projet dans une variable d'environnement. Cela fonctionne enfin avec ceci:

macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-prod docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-prod_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-dev docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-dev_autocat-dev" with the default driver
Creating database-dev ... done

Voilà pour le déploiement à commande unique, quelle blague absolue. À mon avis, .yml est l'endroit idéal pour spécifier le nom du projet dans ce contexte.

Alternativement, j'ai pu placer les services dans un seul projet - en leur donnant des noms différents: "database-dev" et "database-prod". Le seul problème avec cette approche est qu'il existe un avertissement indiquant que le service précédemment instancié devient orphelin car il n'est pas mentionné dans l'autre docker-compose.yml.

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database-prod                
Creating network "autocat-server_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database    
WARNING: Found orphan containers (database-prod) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Creating database-dev ... done

Cela n'a aucun sens, pourquoi doit-il être comme ça. Pourquoi faut-il en fait qu'il en soit ainsi?

EDIT1: @ dc-pm @CharlieReitzel que pensez-vous? pouvez-vous donner un commentaire sur mon cas d'utilisation, juste au cas où il serait invalide :)
EDIT2: j'ai mis les deux fichiers de composition dans des répertoires séparés et le tour est joué

sooo?

mainteneurs, quelqu'un ici?
les développeurs attendent pendant 6 ans!

Salut! J'ai créé un problème dans la spécification de composition pour ajouter le nom du projet au schéma de composition, car cela régit ce que nous pouvons ajouter au fichier de composition.
Une fois la propriété project-name ajoutée à la spécification de composition, nous pouvons démarrer l'implémentation dans docker-compose.