Compose: Le schéma de dénomination par défaut pour les conteneurs créés par Compose

Malheureusement non, désolé.

Même chose ici. Cette fonctionnalité de slug doit être facultative. Est-il difficile de passer un indicateur sur la commande up ou build pour le désactiver?

Je suis d'accord - cela devrait être facultatif. Plusieurs programmes utilisant Docker Compose ne s'exécutent désormais que si vous passez à la version 1.22.

Je suis d'accord, cela devrait être facultatif. Nous n'avons pas du tout besoin de cette fonctionnalité de slug et beaucoup de scripts bash utilisent l'ancien format de dénomination.

Pareil pour nous, nous devons rester sur 1.22 car nous utilisons la fonctionnalité "volumes from" et nous nous appuyons sur l'ancien schéma de dénomination. Veuillez en faire une fonctionnalité facultative dans la version 1.24.

Cette fonctionnalité rend difficile la référence aux conteneurs une fois qu'ils ont été augmentés.

Je ne comprends pas le but de ce changement. Actuellement ni docker ni compose n'offrent aucune découverte de service. Donc, si je veux obtenir un nom d'hôte à l'intérieur du conteneur, que dois-je faire? Lancer ma propre découverte de service?

BTW, quels sont les avantages de ce changement? Vaut-il vraiment la peine de rompre la rétrocompatibilité?

Le changement de nom _slug par défaut est l'approche correcte, mais ne pas avoir de moyen de le désactiver via une variable d'environnement ou une option de ligne de commande rompt de nombreux flux de travail existants. Veuillez considérer ceci comme une demande de fonctionnalité pour ajouter un indicateur quelconque pour ramener le comportement de nommage <= 1.22.0 docker-compose.

Désolé, mais "external_links" est désormais inutilisable. Je dois connaître le nom d'un conteneur pour le lier.
+1 pour le rendre facultatif

@ shin- ce nouveau comportement ruine complètement beaucoup. Avant cet aléatoire slug il était possible d'adresser un conteneur lancé à partir d'un fichier docker-compose dans un autre fichier comme

services:
  app:
    image: app
    external_links:
      - "other-project_other-app_1:other-app"
networks:
  default:
    external:
      name: other-project_default

Et c'est tout. Maintenant, cela ne fonctionnera pas du tout.

Comment cette chose n'est-elle pas au moins facultative?

Une autre étape vers la mort des dockers, je crois.

Il existe donc une solution de contournement. container_name paramètre slug n'est pas utilisé dessus. Au moins, cela aide.

@ shin- s'il vous plaît, ne considérez pas ceci comme un rapport de bogue à propos de slug n'est pas utilisé avec container_name . Le laisser tel qu'il est. J'emballe littéralement ici.

Oh mec! https://github.com/ansible/ansible/issues/47978

Bien que je comprenne la motivation derrière le changement, il est très perturbant, d'autant plus qu'il n'y a pas de période de grâce pour au moins donner aux développeurs le temps d'ajuster leur script. Beaucoup de scripts ont été écrits avec cette convention de dénomination à l'esprit qui existait littéralement pour toujours. Fondamentalement, cette modification rend docker-compose 1.23 non rétrocompatible avec tout autre docker-compose.

@ shin- Vous personnellement et toute l'équipe de docker-compose et docker devriez déjà apprendre ce qu'est un changement rétrocompatible et comment l'amener à un projet largement adopté sur lequel toute l'industrie s'appuie.

Premièrement, un changement incompatible avec les versions antérieures ne consiste pas à rompre ce que vous avez garanti précédemment de ne pas le faire. Personne ne se soucie si cette chose n'est utilisée par personne.

Un changement rétrocompatible se produit lorsque vous cassez quelque chose sur lequel votre base d'utilisateurs compte réellement. Et peu importe les garanties, car après tout, c'est Apache 2.0 et l'ensemble du projet provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND . Vos utilisateurs décident sur quoi ils comptent. Et vous (toute l'équipe) devriez commencer à apprendre à savoir qui utilise votre projet, pourquoi et comment.

Deuxièmement, vous devez apprendre à introduire un tel changement dans votre base d'utilisateurs. Cette "chose de suffixe aléatoire" rompt définitivement la façon dont vos utilisateurs utilisent external_links et volumes_from . Donc, l'avertissement de dépréciation au cas où il n'y aurait pas de jeu container_name explicite ou quand cela en a l'air serait très apprécié. Veuillez considérer ces documents pour vous familiariser avec «ce que font les autres»:

• https://www.python.org/dev/peps/pep-0004/
• http://api.mongodb.com/python/current/compatibility-policy.html
• https://docs.openstack.org/python-novaclient/pike/reference/deprecation-policy.html
• https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation -policy

Troisièmement, @ shin-, vous devriez personnellement apprendre à parler à des personnes qui ne sont pas des contributeurs directs à votre projet et qui ne sont que vos utilisateurs, mais qui sont en même temps des personnes très occupées qui sont suffisamment fidèles à votre projet pour investir leur précieux le temps de déposer des demandes et de participer à des discussions ici avec le seul espoir d'apporter un sens au développement futur du projet et d'essayer d'éviter d'investir plus de ressources dans la migration vers une autre solution.

Quatrièmement, l'équipe Docker essaie de gagner de l'argent avec Docker, mais il ne s'agit pas de Docker lui-même. La seule façon dont Docker peut être une bonne chose à payer est si l'ensemble de l'infrastructure Docker prouve que cela en vaut la peine. Je ne vois pas en quoi c'est un produit orienté vers la réussite des utilisateurs si l'équipe de développement tourne le dos à la communauté la plupart du temps.

Cinquièmement, encore une fois, nous sommes tous ici vos collèges et amis plutôt que des ennemis et nous essayons vraiment de vous aider avec tout cela. Et parce que nous sommes vos amis, l'exode de la pile de dockers sera douloureux, mais de la manière, ça se passe maintenant, cet adieu n'a pas du tout l'air irréaliste.

C'est une implémentation terrible d'un changement majeur de rupture de version, cela rompt complètement la capacité de déployer notre framework et je ne peux même pas imaginer combien d'autres connaîtront exactement le même problème, sans aucun avertissement préalable; à moins que quelqu'un ne cherche manuellement les derniers changelogs pour docker, il n'en aurait aucune idée, et j'imagine que la plupart des gens ne le feront pas

@ shin - Ce changement est très perturbateur pour les flux de travail existants et il devrait y avoir un indicateur fourni pour ne pas générer de slugs. Des milliers d'heures de développement ont été consacrées à l'écriture de scripts et à l'automatisation de services qui reposent sur la prévisibilité de docker-compose. Sans une découverte de service appropriée, quel est le plan de l'équipe pour permettre le ciblage automatisé de conteneurs individuels?

J'ai essayé d'utiliser la directive docker-compose container_name mais cela n'a pas pris effet sur GitLab.
Mais il semble que sur ma dernière version de docker-compose sur Mac Os Mojave, cela fonctionne. Je ne sais pas ce qui se passe :)

Mon fichier .gitlabci.yml télécharge la dernière image de tmaier (cela devrait être 1.23.1).

Bonjour à tous, quelques commentaires généraux qui, je l'espère, répondent à certaines des préoccupations exprimées ici:

• Je comprends vraiment que cela casse certains scripts. Nos notes de version depuis la version 1.23.0-rc1 le disent tout en haut. C'est vraiment une situation de type "arracher le pansement" où la douleur momentanée nous aide à avancer avec une base plus saine.
• Les avantages de la solution actuelle sont nombreux et exprimés en partie dans ce numéro de longue date: # 1516 - et le problème avec docker-compose run particulier a été signalé plusieurs fois ici: # 4688 # 4549 # 5240
• La découverte de service ne devrait pas être un problème car elle devrait être gérée à l'aide de noms de service (plutôt que de noms de conteneur) et d'alias de réseau, qui sont statiques sur leur réseau associé. Vous pouvez lire la documentation sur le
• Je pense que cela rend volumes_from et external_links dans les projets Compose plus difficiles à utiliser. Veuillez considérer qu'avant même ce changement, il n'y avait aucune garantie que Compose respecterait le format "attendu" pour un nom de conteneur donné (voir par exemple # 6155 ou le préfixe mentionné dans # 3415), ce qui en fait une solution défectueuse susceptible de s'exécuter dans des problèmes obscurs à long terme.
  
  
  
  • La méthode recommandée pour permettre aux conteneurs de différents projets de communiquer est de partager un réseau external et d'utiliser le ou les alias de l'autre service. De même, volumes_from dans tous les projets devrait à la place tirer parti des volumes nommés external .
  
  
• Je suis intéressé par des suggestions sur la façon dont ce changement aurait pu être mieux communiqué. Pour référence, le changement a été annoncé dans nos notes de publication et disponible pour test depuis la version 1.23.0-rc1, qui a été publiée le 26 septembre. La version 1.23.0 GA a été publiée plus d'un mois plus tard, et sachant que le changement serait controversé, nous l'avons mis comme un gros avertissement en haut du changelog. S'il y a quelque chose que j'aurais pu faire de plus pour rendre ce changement visible, je suis heureux d'écouter et de faire ces choses la prochaine fois que nous envisagerons un changement risqué comme celui-ci.
  
  
  
  • D'un autre côté, si le point général à retenir ici est "ne faites jamais de changement radical ou laissez-moi les désactiver tous indéfiniment", je suis sûr que la plupart d'entre vous se rendent compte que ce n'est pas une solution saine et raisonnable. sur le maintien d'un projet logiciel de la taille de Compose, qui saute déjà à travers de nombreux obstacles pour maintenir la compatibilité descendante avec un large éventail de versions de Docker Engine, de formats de fichiers Compose et d'idiomes obsolètes.
  
  

Faites-moi savoir s'il y a quelque chose qui n'est pas abordé ici. Je comprends que c'est un ralentissement majeur pour beaucoup d'entre vous et que les esprits peuvent s'enflammer lorsque nous avons affaire à des circonstances imprévues. Prenez le temps dont vous avez besoin pour effectuer la mise à niveau et épingler votre version Compose pour le moment. Heureux de vous aider avec des questions telles que "Comment faire XYZ sans noms prévisibles?" jusque-là, dans ce fil ou sur Slack. Et s'il vous plaît soyez prévenant dans la façon dont vous interagissez avec les autres sur ces forums, vérifiez que les informations que vous partagez sont correctes (j'ai déjà vu quelques fils mentionnés ou redirigés là-bas qui n'avaient rien à voir avec ce changement , ce qui crée un sentiment d'alarme inutile et n'aide pas les personnes avec le problème qui sont mal dirigées ici), et ne faites pas dérailler la conversation. Merci pour votre temps et votre patience.

En ce qui concerne les communications, je m'attendrais à ce qu'un changement comme celui-ci soit communiqué et expliqué à l'avance via un canal de communication, essentiellement de la manière dont vous venez de le faire ici dans ce fil, en expliquant pourquoi et ce qu'il faut faire pour le moment, mais en le faisant avant toutes les conséquences.

@ shin- Vous n'avez pas lu mon dernier commentaire et les liens que j'ai fournis, n'est-ce pas?

Le dernier de vous a l'air gentil mais ressent la même chose.

Je suis intéressé par des suggestions sur la façon dont ce changement aurait pu être mieux communiqué.

TL; DR

• Introduisez le nouveau version du docker-compose.yml
• Ajoutez DeprecationWarning pour external_links avec un lien vers un document qui décrit la mise à jour et fournit un exemple de solution pour ceux qui souhaitent migrer.
• Prend en charge l'ancien comportement pour toutes les versions de format de fichier de composition antérieures à la nouvelle.

Pour référence, le changement a été annoncé dans nos notes de publication

Le changelog est une chose pour les contributeurs. Les utilisateurs ne le lisent pas. Un utilisateur installe docker-compose et prie qu'il fonctionne toujours après hier.

D'un autre côté, si le point général à retenir ici est "ne faites jamais de changement radical ou laissez-moi les désactiver tous indéfiniment", je suis sûr que la plupart d'entre vous se rendent compte que ce n'est pas une solution saine et raisonnable. sur le maintien d'un projet logiciel de la taille de Compose, qui saute déjà à travers de nombreux obstacles pour maintenir la compatibilité descendante avec un large éventail de versions de Docker Engine, de formats de fichiers Compose et d'idiomes obsolètes.

J'ai une bonne nouvelle pour toi. Vous avez déjà garanti "ne jamais faire de changement de rupture, ou laissez-moi me retirer indéfiniment de tous". Et de plus, vous avez une fonctionnalité pour cela. C'est le fichier version dans docker-compose.yml . Donc, envisagez d'annuler ce changement dès que possible et de l'introduire pour le prochain version .

Heureux de vous aider avec des questions telles que "Comment faire XYZ sans noms prévisibles?" jusque-là, dans ce fil ou sur Slack.

Veuillez fournir la solution pour external_links et les volumes externes sans container_name définis (comme nous le voyons, cela ne fonctionne pas toujours) dans un autre docker-compose.yml dans ce fil.

Il s'agit d'une manière populaire dont vos utilisateurs utilisent votre projet. La plupart de vos utilisateurs utilisent docker-compose pour le développement local. On a souvent plusieurs projets interconnectés en cours de développement. Dans un tel cas, il est courant de diriger plusieurs fichiers docker-compose vers le même réseau et de définir external_links pour les services de différents projets afin de pouvoir se joindre sur la machine du développeur.

ne fait pas dérailler la conversation

@ shin- Toutes les conversations que j'ai lues jusqu'à présent et vous impliquant sont déraillées parce que vous ne faites rien pour résoudre les problèmes des gens.

Sérieusement, avec une telle attitude refusant constamment les demandes des utilisateurs et forçant votre communauté à se débattre lorsque vous pouvez éviter que vous fassiez mieux de transmettre ce projet à quelqu'un d'autre.

PS: Désolé pour un autre commentaire "offtopic". N'hésitez pas à verrouiller ce problème car vous êtes également utilisé.

Veuillez fournir la solution pour les liens externes et les volumes externes sans nom_conteneur défini (comme nous le voyons, cela ne fonctionne pas toujours) dans un autre docker-compose.yml de ce fil.

Déjà fait, veuillez vous référer à mon commentaire précédent:

La méthode recommandée pour permettre aux conteneurs de différents projets de communiquer est de partager un réseau external et d'utiliser le ou les alias de l'autre service. De même, volumes_from dans tous les projets devrait à la place tirer parti des volumes nommés external .

Le reste de votre message est inutilement contradictoire et je n'y répondrai pas. Je suis ici et je suis prêt à avoir une discussion, mais je n'ai pas à accepter votre intimidation.

Honnêtement, @ shin-

Je suis intéressé par des suggestions sur la façon dont ce changement aurait pu être mieux communiqué

Je ne vois pas que vous êtes «intéressé». Fermer le ticket sur l'extraction de l'image avant de créer le fichier de composition et le marquer comme «spam» (lol) me dit que ce que la communauté suggère ne vous intéresse certainement

Je suis ici et je veux avoir une discussion

Même si nous fournissons de purs arguments méritoires, vous les ignorez simplement. Alors pourquoi s'embêter?

PS. Marquer ceci comme hors-sujet, allez-y, montrez-nous comment respectez-vous notre opinion. Voir autant de votes positifs sur des opinions différentes fait mal?

Déjà fait, veuillez vous référer à mon commentaire précédent:

Je ne vois pas d'exemple de solution fonctionnel, désolé.

Le reste de votre message est inutilement contradictoire et je n'y répondrai pas. Je suis ici et je suis prêt à avoir une discussion, mais je n'ai pas à accepter votre intimidation.

Désolé, si vous vous sentez comme ça. S'il vous plaît, pensez à prendre en charge l'ancien comportement pour les versions actuelles du fichier de composition du docker et introduisez la nouvelle version de format qui se comportera de la nouvelle manière. C'est la seule option dont vous disposez pour fournir une bonne solution à votre base d'utilisateurs.

S'il vous plaît. pensez à relire ces deux mes commentaires avec l'idée que je suis prêt à aider le projet dans votre esprit:

• https://github.com/docker/compose/issues/6316#issuecomment -438564025
• https://github.com/docker/compose/issues/6316#issuecomment -438934935

Concernant les communications: nous avons obtenu la mise à jour via Docker pour Mac, et il ne semblait pas afficher de journal des modifications indiquant ce changement, il a donc fallu un peu de temps pour comprendre pourquoi nos variables d'environnement avaient changé.

Une fois que j'ai pris conscience de cela, j'ai saisi l'occasion de mettre à niveau notre configuration de la v1 à la v3 et de créer un lien en utilisant des noms de service au lieu de variables d'environnement, et cela a en fait rendu les choses beaucoup plus propres 👍

FWIW, un hack rétrocompatible à exécuter dans un conteneur créé par compose:

docker container exec -it $(docker container ls -f name=expected -q) cmd

Une fois que j'ai pris conscience de cela, j'ai saisi l'occasion de mettre à niveau notre configuration de la v1 à la v3 et de créer un lien en utilisant des noms de service au lieu de variables d'environnement, et cela a en fait rendu les choses beaucoup plus propres

Pourriez-vous s'il vous plaît fournir un court exemple ici pour la liaison de nom de service entre différentes approches de fichiers docker-compose?

docker container exec -it $(docker container ls -f name=expected -q) cmd

Cela n'a rien à voir avec docker-compose cependant.

@lig Cela fonctionne autour de la modification du nom expected créé par docker-compose. Cette solution de contournement n'existerait pas sans la modification du schéma de dénomination.

@joebowbeer, le principal problème après ce changement concerne la liaison entre les fichiers docker-compose. Je vois, il existe un moyen de trouver un conteneur lancé par docker-compose via docker cmd. Mais c'est un peu d'aide sur le sujet :(

@ shin- Je pense que nous attendons tous encore l'explication de la raison pour laquelle nous avons besoin de docker composer pour générer des noms de conteneurs de lignes en essaim.

Pour moi, il est assez clair que personne dans son état sain d'esprit n'aurait besoin d'utiliser le compositeur à des fins de production. Compose est un projet puissant à tester localement. Je ne vois pas l'intérêt d'obtenir un avantage / une fonctionnalité de docker swarm pour un outil qui est massivement utilisé pour les tests locaux uniquement. Si nous avions besoin d'un nom de type essaim pour les conteneurs, nous utiliserions swarm. Droite?

La deuxième grande question ici est la suivante: pourquoi cela n'a pas été inclus comme une option via un argument? Je ne vois pas sur mes forums et communautés des personnes qui font appel à ce comportement par défaut. Nous devrions donc probablement l'introduire comme un nouvel argument: docker-compose up --slug . Simple, élégant et ne briserait aucun script.

  * On the flipside, if the general takeaway here is "don't make any breaking change ever, or let me opt out of all of them indefinitely", I'm sure most of you realize that it's not a healthy, reasonable way to go about maintaining a software project the size of Compose, which already jumps through a lot of hoops to maintain backward-compatibility with a wide array of Docker Engine versions, Compose file formats, and deprecated idioms.

En travaillant en entreprise, dans le passé, nous avions tendance à avoir une règle des «deux versions majeures» pour interrompre les modifications - obsolète dans l'une, suppression dans la suivante. Je ne sais pas vraiment comment cela aurait pu être opt-in, mais un opt-out _temporaire_ aurait été vraiment apprécié.

Docker-compose ne semble pas avoir de concept de versions majeures, mais je ne vois pas comment une option temporaire "désactiver cette" (que ce soit à partir de la ligne de commande ou dans le fichier de composition) limitée à une ou deux versions (1.23 et peut-être 1.24) constituerait «indéfiniment».

Étant donné que cela semble être lié aux mises à jour automatiques pour les utilisateurs non Linux, beaucoup de gens ont été pris par surprise, et au lieu d'avoir le reste du trimestre à «exécuter avec cet indicateur de ligne de commande pendant que nous mettons à jour nos scripts» nous avons tout un tas de développeurs qui doivent soit rétrograder manuellement et / ou abandonner ce qu'ils font pour mettre à jour les scripts.

Ce changement radical est un désastre. Rupture soudaine du déploiement automatique. Merci de ne plus recommencer.

* Introduce the new `version` of the `docker-compose.yml` 
* Add `DeprecationWarning` for `external_links` with a link to a document which describes the update and provides a sample solution for those willing to migrate.
* Support the old behavior for all compose file format versions prior the new one.

Cela a trop de sens ... aucune idée pourquoi ce n'est pas fait de cette façon.

Je suis ici et je suis prêt à avoir une discussion, mais je n'ai pas à accepter votre intimidation.

@ shin- il est tout à fait évident qu'il n'y a aucune discussion ici car vous ne considérez pas les suggestions rationnelles présentées. De plus, si quelqu'un est intimidé - vous l'êtes - avec ce changement radical, vous intimidez efficacement de nombreux développeurs à travers le monde.

Beaucoup de gens (moi et une autre personne probablement) n'utilisent pas la composition pour le mode essaim. Je spécifie une version inférieure pour mes fichiers de composition en raison de problèmes que j'ai rencontrés dans le passé où l'hypothèse est qu'un fichier de composition est utilisé pour définir des services pour les essaims. J'ai pensé que la version que j'avais spécifiée était liée aux résultats qu'elle produisait sur mon nœud docker et qu'en verrouillant la version à quelque chose de bas, je pourrais obtenir des résultats cohérents et toujours prendre des mises à jour pour composer pour rester compatible avec la version de docker Je suis entrain de courir. Apparemment, je ne peux pas m'attendre à une version appropriée ici.

Pouvons-nous dockerize le docker-compose, pour nous assurer qu'ils ne cassent pas soudainement nos affaires?

Je pense que la meilleure solution serait d'introduire une nouvelle option de configuration dans le fichier docker-compose.yml où l'ajout de la partie slug aux noms de conteneurs pourrait être désactivé.

s / désactivé / activé /. Au moins sur les versions de fichier de composition existantes.

Ce comportement doit être lié au numéro de version du fichier de composition. Indépendamment du fait que ce comportement ait été «spécifié», il est assez largement utilisé et constitue donc un changement incompatible avec les versions antérieures. Pourquoi la version de la spécification à ce stade de toute façon si ce que fait un fichier de composition n'est pas garanti de fonctionner de la même manière lorsque je mets à niveau mon binaire? Abandonner une spécification de fichier de composition (avec beaucoup d'avertissement lorsque docker-compose est exécuté bien sûr), puis la supprimer, ce serait certainement de ma faute que tout mon contenu ne fonctionne plus, mais je m'attends à ce que je lise votre version. remarques pour un programme qui a le privilège de m'imprimer des messages d'avertissement sur mon visage?

Faire des changements comme celui-ci semble être une assez bonne motivation pour la gestion des versions du comportement de la spécification en plus de son format: vous pouvez déprécier les hypothèses du code des autres avec un avertissement. Je pense que le nombre de problèmes externes qui ont laissé tomber ce problème montre à quel point cela a été surprenant pour beaucoup de gens. C'est vraiment génial de voir le comportement hérité être brisé pour que le code ne se complique pas, mais des changements comme celui-ci ne peuvent pas être appliqués en même temps. Puis-je m'attendre à ce que d'autres hypothèses concernant la composition des noms de conteneurs se rompent? Le nom du service sera-t-il toujours dans le nom du conteneur ou peut-il être supprimé comme les noms prévisibles?

Cela me rappelle vraiment le moment où la dénomination cohérente des périphériques réseau a été largement adoptée sous Linux (mais c'est le contraire de la dénomination ... idk). Beaucoup de code a été codé en dur pour ethN (et l'est toujours dans des endroits surprenants) et cela n'a pas vraiment changé. Il existe cependant un moyen de récupérer l'ancien comportement sur les systèmes systemd (et sur d'autres systèmes, mais cela peut varier) en ajoutant net.ifnames=0 aux arguments du noyau.

(Désolé pour le coup de gueule du deuxième passage, mais je ne pense pas que mon premier soit très constructif.)

Il semble que ce changement rend l'option --scale inutile. car le suffixe aléatoire doit être connu pour atteindre les instances mises à l'échelle d'un service.

Par exemple, plusieurs instances de service en tant que serveurs en amont pour Nginx.

Edit: voir # 6365 pour plus d'informations

Wow, quel horrible changement. 👎

Comment sommes-nous censés obtenir la chaîne générée aléatoirement pour une utilisation dans les scripts?

J'ai également rencontré ce problème et j'aimerais exprimer ma recommandation pour de futurs changements incompatibles vers l'arrière. Nous avons aussi des scripts reposant sur le format project_service_index, avec de nombreuses personnes utilisant ces scripts sur Mac. Dans un monde idéal, nous pourrions contrôler la version de Docker pour Mac que les gens utilisent, mais pour l'instant, les gens mettent à niveau lorsque la boîte de dialogue de mise à niveau automatique apparaît.

Mes problèmes et recommandations sont:

1) La boîte de dialogue de mise à niveau n'avait aucune indication de ce changement significatif, donc nous n'avions aucune indication évidente sur ce changement. Dans un monde idéal, nous vérifierions toutes les notes de publication pour chaque mise à jour, mais ce n'est pas le cas pour le moment. Donc, il serait grandement apprécié que quelque chose d'important comme celui-ci soit appelé explicitement dans la boîte de dialogue de mise à jour.

2) En raison de 1), il n'y avait pas d'avertissement évident. Ce serait formidable si un changement comme celui-ci était annoncé dans la mise à jour précédente. Par exemple, la mise à niveau antérieure à la dernière indique quelque chose comme "Le schéma de dénomination des conteneurs est en train de changer dans la prochaine version, veuillez mettre à jour vos scripts"

3) Je comprends qu'après avoir lu ce fil, le schéma de dénomination que nous utilisons n'est pas garanti, et je me rends compte qu'il existe de meilleures façons de faire référence aux conteneurs. Cependant, nous avons tous une vie de travail bien remplie et devons planifier nos tâches, donc en tant que mainteneur de nos scripts, je ne suis pas en mesure de convertir immédiatement notre utilisation des noms de conteneurs en quelque chose de mieux. Je suis heureux d'utiliser les meilleures pratiques recommandées, mais j'ai besoin de temps pour migrer notre code. Par conséquent, ce serait formidable d'avoir une stratégie de dépréciation pour un changement comme celui-ci.

La principale chose à retenir ici est que la plupart des pays du monde supposent un schéma de dénomination des conteneurs qui est fondamental pour leur utilisation de docker compose, et changer le comportement par défaut sans stratégie de dépréciation évidente peut être préjudiciable à ces flux de travail.

Les gens n'utilisent pas toujours les logiciels exactement de la manière dont ils ont été conçus, et c'est à eux qu'il appartient de réparer les choses lorsque leurs hypothèses échouent. Cependant, quelques communications simples peuvent nous aider à nous préparer aux changements futurs et nous motiveraient à adopter les dernières meilleures pratiques.

Si vous dépendiez auparavant de docker container exec -it project_php_1 bash , vous ne pouvez plus l'utiliser.

Vous devez utiliser docker ps pour trouver l'ID de service.

Cependant, vous ne pouvez pas utiliser docker ps -q --filter=name=project_php car cela correspondra aux services nommés project_php et project_php_xdebug ou tout autre élément qui correspond à project_php .

Les docker container exec -it project_php_1 bash précédemment lisibles doivent maintenant devenir ceci:

docker container exec -it \
    $(docker ps -q \
        --filter label=com.docker.compose.project=project \
        --filter label=com.docker.compose.service=php) \
    bash

C'était un changement mal pensé.

@jtreminio FWIW, à partir du projet, vous pouvez toujours faire docker-compose exec php

Merci à tous ceux qui ont pris le temps de partager leurs réflexions sur le changement. Nous convenons que cela a été mal géré et un peu trop zélé de notre part, et cela a été partiellement inversé dans Compose 1.23.2 (nous docker-compose run , ce qui nous permet de les gérer plus gracieusement. : # 4688 # 4549 # 5240, comme initialement prévu).

Faites-moi savoir s'il y a des problèmes en suspens qui doivent être réglés.

Y a-t-il un plan pour ajouter une option de ligne de commande pour désactiver cette option --no-slug ou plus préférablement --slug afin que la valeur par défaut soit de fonctionner comme avant.

1.23.2 revient à ce qu'il était avant.

Il n'a été annulé que pour docker-compose up mais pas pour docker-compose run

Merci pour la résolution rapide de ce problème !!

Le 28 novembre 2018, à 20h09, Joffrey F [email protected] a écrit:

Merci à tous ceux qui ont pris le temps de partager leurs réflexions sur le changement. Nous convenons que cela a été mal géré et un peu trop zélé de notre part, et cela a été partiellement inversé dans Compose 1.23.2 (nous conservons des suffixes aléatoires pour les conteneurs créés par docker-compose run, ce qui nous permet de les gérer plus gracieusement: # 4688 # 4549 # 5240, comme prévu initialement).

Faites-moi savoir s'il y a des problèmes en suspens qui doivent être réglés.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

@ shin- Je présume que cela sera retourné à un moment donné - peut-être en 1.24 (puisque c'est un changement si important?). Si c'est le cas, pourriez-vous travailler avec la communauté pour comprendre et recommander des mécanismes légers alternatifs pour les personnes qui les utilisaient sans slugs? Je ne suis pas sûr du meilleur endroit pour avoir cette conversation.

https://github.com/docker/compose/issues/6316#issuecomment -442666873

changé de <project>_<service>_<index> à <project>_<service>_<index>_<slug>

Ceci est un bogue pas une fonctionnalité.
Merci!
Pensez aux playbooks ansibles qui fonctionnent avec ansible_connection=docker ... 😔 !!
devons-nous donner explicitement container_name ? ou devons-nous continuer à mettre à jour notre inventaire avec le aléatoire <slug> !!.
Vraiment très mauvais!