Compose: El esquema de nomenclatura predeterminado para los contenedores creados por Compose

Lamentablemente no, lo siento.

Lo mismo aqui. Esta función de babosa debería ser opcional. ¿Qué tan difícil es pasar una bandera en el comando up o build para apagarlo?

Estoy de acuerdo, esto debería ser opcional. Varios programas que utilizan Docker Compose ahora solo se ejecutan si se cambia a 1.22.

Estoy de acuerdo, esto debería ser opcional. No necesitamos esta función de slug en absoluto y muchos scripts de bash están usando formatos de nombres antiguos.

Lo mismo para nosotros, debemos permanecer en 1.22 ya que usamos la función "volúmenes desde" y confiamos en el esquema de nombres antiguo. Por favor, conviértalo en una característica opcional en 1.24.

Esta característica hace que sea difícil hacer referencia a los contenedores después de que se hayan aumentado.

No entiendo el sentido de este cambio. Actualmente, ni Docker ni Compose ofrecen descubrimiento de servicios. Entonces, si quiero obtener un nombre de host del interior del contenedor, ¿qué se supone que debo hacer? ¿Lanzar mi propio descubrimiento de servicios?

Por cierto, ¿cuáles son los beneficios de este cambio? ¿Realmente vale la pena romper la compatibilidad con versiones anteriores?

El cambio de nombre de _slug predeterminado es el enfoque correcto, pero no tener una forma de deshabilitarlo a través de una variable de entorno o una opción de línea de comando rompe muchos flujos de trabajo existentes. Considere esto como una solicitud de función para agregar un indicador de algún tipo para recuperar el comportamiento de nomenclatura de composición de ventana acoplable <= 1.22.0.

Lo sentimos, pero los "enlaces_externos" no se pueden utilizar ahora. Tengo que saber el nombre de un contenedor para vincularlo.
+1 por hacerlo opcional

@ shin- este nuevo comportamiento arruina por completo muchas cosas. Antes de ese slug aleatorio, era posible abordar un contenedor lanzado desde un archivo docker-compose dentro de otro archivo como

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

Y eso es. Ahora, esto no funcionará en absoluto.

¿Cómo esto no es opcional al menos?

Otro paso hacia la muerte de docker-compon, creo.

Entonces, hay una solución. container_name parámetro slug no se usa en él. Al menos eso ayuda.

@ shin- por favor, no consideres que esto es un informe de error acerca de que slug no se está usando con container_name . Déjalo así. Literalmente estoy empacando aquí.

¡Oh chico! https://github.com/ansible/ansible/issues/47978

Si bien entiendo el incentivo detrás del cambio, es muy perturbador, especialmente porque no hay un período de gracia para al menos dar tiempo a los desarrolladores para ajustar su script. Se escribieron muchos guiones con esta convención de nomenclatura en mente que existió literalmente para siempre. Básicamente, este cambio hace que docker-compose 1.23 no sea compatible con versiones anteriores de cualquier otro docker-compose.

@ shin- Usted personalmente y todo el equipo de docker-compose y docker ya deberían aprender qué es el cambio incompatible hacia atrás y cómo llevarlo a un proyecto ampliamente adoptado en el que confía toda la industria.

Primero, el cambio incompatible hacia atrás no se trata de que usted rompa lo que ha garantizado anteriormente para no hacerlo. A nadie le importa si nadie usa esta cosa.

El cambio incompatible hacia atrás es cuando rompe algo en lo que su base de usuarios realmente confía. Y no importa qué garantías fueron porque es Apache 2.0 después de todo y todo el proyecto provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND . Tus usuarios deciden en qué confían. Y usted (todo el equipo) debería comenzar a aprender a saber quién usa su proyecto, por qué y cómo.

En segundo lugar, debe aprender a introducir dicho cambio en su base de usuarios. Esta "cosa de sufijo aleatorio" definitivamente rompe la forma en que sus usuarios usan external_links y volumes_from . Por lo tanto, la advertencia de desaprobación en caso de que no haya un conjunto explícito de container_name o cuando lo parezca sería muy apreciado. Por favor, considere estos documentos para familiarizarse con "lo que hacen los demás":

• 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

En tercer lugar, @ shin-, usted personalmente debe aprender a hablar con personas que no son contribuyentes directos a su proyecto y que son solo sus usuarios, pero al mismo tiempo son personas muy ocupadas que son leales a su proyecto lo suficiente como para invertir su valioso tiempo para presentar solicitudes y participar en discusiones aquí con la única esperanza de darle algo de sentido al desarrollo futuro del proyecto y tratar de evitar invertir más recursos en la migración hacia otra solución.

En cuarto lugar, el equipo de Docker está tratando de ganar dinero con Docker, pero no se trata de Docker en sí. La única forma en que Docker puede ser algo bueno para pagar es si toda la infraestructura de Docker prueba que vale la pena pagar. No veo cómo es un producto orientado al éxito del usuario si el equipo de desarrollo da la espalda a la comunidad la mayor parte del tiempo.

Quinto, una vez más, todos aquí somos sus universidades y amigos en lugar de enemigos y realmente estamos tratando de ayudarlo con todo esto. Y debido a que somos tus amigos, el éxodo de la ventana acoplable será doloroso, pero en el camino, continúa, esa despedida no parece nada irreal.

Esta es una implementación terrible de un cambio importante que rompe la versión, rompe por completo la capacidad de implementar nuestro marco y ni siquiera puedo imaginar cuántos otros experimentarán exactamente el mismo problema, sin ninguna advertencia previa; a menos que alguien busque manualmente los registros de cambios más recientes para Docker, no tendrían idea de esto, e imagino que la mayoría de la gente no lo hará

@ shin: este cambio es muy perjudicial para los flujos de trabajo existentes y debe proporcionarse una bandera para no generar slugs. Se han dedicado miles de horas de tiempo de desarrollo a la escritura de scripts y a la automatización de servicios que dependen de la predictibilidad de docker-compose. Sin el descubrimiento del servicio adecuado, ¿cuál es el plan del equipo para permitir la segmentación automatizada de contenedores individuales?

Intenté usar la directiva docker-compose container_name pero no surtió efecto en GitLab.
Pero parece que en mi última versión de docker-compose en Mac Os Mojave está funcionando. No estoy seguro de qué está ocurriendo :)

Mi archivo .gitlabci.yml está descargando la última imagen de tmaier (debería ser 1.23.1).

Hola a todos, algunos comentarios generales que espero aborden algunas de las preocupaciones expresadas aquí:

• Definitivamente entiendo que esto rompe algunos guiones. Nuestras notas de la versión desde 1.23.0-rc1 lo dicen en la parte superior. Esta es una situación del tipo "arrancar la tirita" en la que el dolor momentáneo nos ayuda a avanzar con una base más saludable.
• Los beneficios de la solución actual son numerosos y se expresan en parte en este problema de larga data: # 1516 - y el problema con docker-compose run especialmente se ha informado varias veces aquí: # 4688 # 4549 # 5240
• El descubrimiento de servicios no debería ser un problema, ya que debería manejarse utilizando nombres de servicios (en lugar de nombres de contenedores) y alias de red, que son estáticos en su red asociada. Puede leer los documentos de redes para obtener más detalles sobre eso específicamente
• Creo que esto hace que volumes_from y external_links en los proyectos de Compose sean más difíciles de usar. Tenga en cuenta que incluso antes de este cambio, no había garantía de que Compose respetara el formato "esperado" para un nombre de contenedor determinado (consulte, por ejemplo, # 6155 o el prefijo que se menciona en el # 3415), por lo que es una solución defectuosa propensa a ejecutarse en temas oscuros a largo plazo.
  
  
  
  • La forma recomendada de permitir que los contenedores de diferentes proyectos se comuniquen es que compartan una red external y utilicen los alias del otro servicio. De manera similar, volumes_from todos los proyectos deberían aprovechar los volúmenes nombrados external .
  
  
• Estoy interesado en sugerencias sobre cómo este cambio podría haberse comunicado mejor. Como referencia, el cambio ha sido mencionado en nuestras notas de la versión y está disponible para pruebas desde 1.23.0-rc1, que se lanzó el 26 de septiembre. 1.23.0 GA se lanzó más de un mes después, y saber que el cambio sería controvertido. lo ponemos como una gran advertencia en la parte superior del registro de cambios. Si hay algo más que podría haber hecho para que este cambio sea visible, me complace escuchar y hacer estas cosas la próxima vez que consideremos un cambio arriesgado como este.
  
  
  
  • Por otro lado, si la conclusión general aquí es "no hagas ningún cambio importante o déjame excluirme de todos ellos de forma indefinida", estoy seguro de que la mayoría de ustedes se dan cuenta de que no es una manera saludable y razonable de hacerlo. sobre el mantenimiento de un proyecto de software del tamaño de Compose, que ya supera muchos obstáculos para mantener la compatibilidad con versiones anteriores de una amplia gama de versiones de Docker Engine, formatos de archivo Compose y modismos obsoletos.
  
  

Avísame si hay algo que no esté abordado aquí. Entiendo que este es un obstáculo importante para muchos de ustedes y que los ánimos pueden estallar cuando nos enfrentamos a circunstancias imprevistas. Tómate el tiempo que necesites para realizar la actualización y anclar tu versión de Compose por el momento. Feliz de ayudar con preguntas como "¿Cómo hago XYZ sin nombres predecibles?" hasta entonces, en este hilo o en Slack. Y sea considerado en la forma en que interactúa con otros en estos foros, verifique que la información que está compartiendo sea correcta (ya he visto un par de hilos que se mencionan o se redirigen allí que no tienen nada que ver con este cambio , que crea una sensación de alarma innecesaria y no ayuda a las personas con el problema que están siendo desviadas aquí), y no descarrile la conversación. gracias por tu tiempo y paciencia.

En la parte de comunicaciones, esperaría que un cambio como este sea comunicado y explicado a través de algún canal de comunicación de antemano, básicamente de la forma en que lo acabas de hacer aquí en este hilo, explicando por qué y qué hacer por ahora, pero haciéndolo antes. todas las secuelas.

@ shin- No has leído mi último comentario y los enlaces que he proporcionado, ¿verdad?

El último tuyo se ve amable pero se siente igual.

Estoy interesado en sugerencias sobre cómo este cambio podría haberse comunicado mejor.

TL; DR

• Introduzca el nuevo version del docker-compose.yml
• Agregue DeprecationWarning por external_links con un enlace a un documento que describe la actualización y proporciona una solución de muestra para quienes deseen migrar.
• Admite el comportamiento anterior para todas las versiones de formato de archivo de redacción anteriores a la nueva.

Como referencia, el cambio se ha mencionado en nuestras notas de la versión.

El registro de cambios es cosa de contribuyentes. Los usuarios no lo leen. Un usuario instala docker-compose y reza para que siga funcionando después de ayer.

Por otro lado, si la conclusión general aquí es "no hagas ningún cambio importante o déjame excluirme de todos ellos de forma indefinida", estoy seguro de que la mayoría de ustedes se dan cuenta de que no es una manera saludable y razonable de hacerlo. sobre el mantenimiento de un proyecto de software del tamaño de Compose, que ya supera muchos obstáculos para mantener la compatibilidad con versiones anteriores de una amplia gama de versiones de Docker Engine, formatos de archivo Compose y modismos obsoletos.

Tengo buenas noticias para ti. Ya tienes garantizado "no hagas ningún cambio importante o déjame excluirme de todos ellos indefinidamente". Y más, tienes una función para esto. Es el archivo version en docker-compose.yml . Por lo tanto, considere revertir este cambio lo antes posible e introducirlo para el próximo version .

Feliz de ayudar con preguntas como "¿Cómo hago XYZ sin nombres predecibles?" hasta entonces, en este hilo o en Slack.

Por favor, proporcione la solución para external_links y volúmenes externos sin container_name definidos (ya que vemos que no siempre funciona) en otro docker-compose.yml en este hilo.

Esta es una forma popular en que sus usuarios usan su proyecto. La mayoría de sus usuarios utilizan docker-compose para el desarrollo local. A menudo, uno tiene varios proyectos interconectados en desarrollo. En tal caso, es una práctica común dirigir varios archivos de composición acoplable a la misma red y definir external_links para que los servicios de diferentes proyectos puedan comunicarse entre sí en la máquina del desarrollador.

no descarrile la conversación

@ shin- Todas las conversaciones que he leído hasta ahora sobre ti se descarrilan porque no haces nada para resolver los problemas que tiene la gente.

En serio, con tal actitud, niega constantemente las solicitudes de los usuarios y obliga a tu comunidad a luchar cuando puedes evitar que sea mejor que le pases este proyecto a otra persona.

PD: Perdón por otro comentario "fuera de tema". No dude en bloquear este problema ya que también está acostumbrado.

Por favor, proporcione la solución para external_links y volúmenes externos sin container_name definido (como vemos que no siempre funciona) en otro docker-compose.yml en este hilo.

Ya lo hice, consulte mi comentario anterior:

La forma recomendada de permitir que los contenedores de diferentes proyectos se comuniquen es que compartan una red external y utilicen los alias del otro servicio. De manera similar, volumes_from todos los proyectos debería aprovechar los volúmenes nombrados external .

El resto de su publicación es innecesariamente contradictorio y no responderé. Estoy aquí y dispuesto a tener una discusión, pero no tengo que aceptar tu acoso.

Honestamente, @ shin-

Estoy interesado en sugerencias sobre cómo este cambio podría haberse comunicado mejor

No veo que esté "interesado". Cerrar el ticket sobre extraer una imagen antes de crear un archivo de redacción y marcarlo como "spam" (risas) me dice que definitivamente no está interesado en lo que sugiere la comunidad. Realmente no sé qué es lo que quiere lograr, pero creo que otra persona debería mantener una relación con la comunidad.

Estoy aquí y dispuesto a tener una discusión.

Incluso si proporcionamos argumentos meritorios puros, simplemente ignórelos. ¿Entonces, para qué molestarse?

PD. Marque esto como fuera de tema, adelante, muéstrenos cómo respeta nuestra opinión. ¿Ver tantos votos a favor sobre diferentes opiniones duele?

Ya lo hice, consulte mi comentario anterior:

No veo una solución de muestra que funcione, lo siento.

El resto de su publicación es innecesariamente contradictorio y no responderé. Estoy aquí y dispuesto a tener una discusión, pero no tengo que aceptar tu acoso.

Lo siento, si te sientes así. Por favor, considere la posibilidad de admitir el comportamiento anterior para las versiones de archivo de la ventana acoplable actual e introduzca la nueva versión de formato que se comportará de la nueva forma. Esta es la única opción que tiene para proporcionar una buena solución a su base de usuarios.

Por favor. Considere leer estos dos comentarios nuevamente con la idea de que estoy dispuesto a ayudar en el proyecto en su mente:

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

Con respecto a las comunicaciones: obtuvimos la actualización a través de Docker para Mac, y no parecía mostrar ningún tipo de registro de cambios que señalara este cambio, por lo que tomó un poco de tiempo descubrir por qué nuestras variables de entorno habían cambiado.

Una vez que me di cuenta de esto, lo tomé como una oportunidad para actualizar nuestra configuración de v1 a v3 y vincularla usando nombres de servicio en lugar de variables de entorno, y en realidad ha hecho las cosas mucho más limpias 👍

FWIW, un truco compatible con versiones anteriores para ejecutar en un contenedor creado por compose:

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

Una vez que me di cuenta de esto, lo aproveché como una oportunidad para actualizar nuestra configuración de v1 a v3 y vincularla usando nombres de servicio en lugar de variables de entorno, y en realidad ha hecho las cosas mucho más limpias.

¿Podría proporcionar un breve ejemplo aquí para el enlace del nombre del servicio a través de diferentes enfoques de archivos docker-compose?

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

Sin embargo, esto no tiene nada que ver con docker-compose.

@lig Esto expected nombre creado por docker-compose. Esta solución alternativa no existiría si no fuera por el cambio en el esquema de nombres.

@joebowbeer, el principal problema después de este cambio es la vinculación entre archivos de composición acoplable. Ya veo, hay una manera de encontrar un contenedor lanzado por docker-compose a través de docker cmd. Pero esto es una pequeña ayuda sobre el tema :(

@ shin- Creo que todavía estamos esperando la explicación de por qué necesitamos docker composer para generar nombres de contenedores de línea de enjambre.

Para mí, está bastante claro que nadie en su sano juicio necesitaría usar el compositor para fines de producción. Compose es un proyecto poderoso para acelerar y probar localmente. No veo el atractivo de obtener una ventaja / funcionalidad de enjambre de docker para una herramienta que se usa masivamente para pruebas solo locales. Si necesitáramos un nombre similar a un enjambre para los contenedores, usaríamos enjambre. ¿Correcto?

La segunda gran pregunta aquí es: ¿Por qué esto no se incluyó como una característica de opción a través de un argumento? No veo en mis foros y comunidades personas apelando a tener este comportamiento como predeterminado. Así que probablemente deberíamos presentarlo como un nuevo argumento: docker-compose up --slug . Simple, elegante y no rompería los guiones de nadie.

  * 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.

Trabajando en la empresa, en el pasado, tendíamos a tener una regla de "dos versiones principales" para romper los cambios: desaprobar en una, eliminar en la siguiente. No estoy realmente seguro de cómo se pudo haber habilitado esto, pero una exclusión voluntaria _temporal_ habría sido muy apreciada.

Docker-compose no parece tener un concepto de versiones principales, pero no veo cómo una opción temporal "deshabilitar esto" (ya sea desde la línea de comando o en el archivo de redacción) limitada a una o dos versiones (1.23 y posiblemente 1,24) constituiría "indefinidamente".

Dado que esto parece estar relacionado con las actualizaciones automáticas para los usuarios que no son de Linux, muchas personas fueron tomadas por sorpresa, y en lugar de tener el resto del trimestre para "ejecutar con esta bandera de línea de comando mientras actualizamos nuestro scripting" tenemos un montón de desarrolladores que tienen que degradar manualmente y / o eliminar lo que están haciendo para actualizar los scripts.

Este cambio radical es un desastre. Se rompió un montón de despliegue automático de repente. Por favor, no vuelvas a hacer eso.

* 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.

Tiene demasiado sentido ... no tengo idea de por qué no se hace de esta manera.

Estoy aquí y dispuesto a tener una discusión, pero no tengo que aceptar tu acoso.

@ shin- es bastante obvio que no hay discusión aquí ya que no está considerando las sugerencias racionales presentadas. Además, si alguien está intimidando, usted lo es, con este cambio radical, está intimidando a numerosos desarrolladores de todo el mundo.

Mucha gente (probablemente alguna otra persona y yo) no usa componer para el modo de enjambre. Especifico una versión más baja para mis archivos de redacción debido a problemas que he tenido en el pasado donde la suposición es que se usa un archivo de redacción para definir servicios para enjambres. Pensé que la versión que especifiqué estaba vinculada a los resultados que produjo en mi nodo de la ventana acoplable y, al bloquear la versión en algo bajo, podría obtener resultados consistentes y aún tomar actualizaciones para componer para mantener la compatibilidad con la versión de la ventana acoplable. Estoy corriendo. Aparentemente, no puedo esperar una versión adecuada aquí.

¿Podemos dockerizar el docker-compose para asegurarnos de que no rompan de repente nuestras cosas?

Creo que la mejor solución sería introducir una nueva opción de configuración en el archivo docker-compose.yml donde se podría deshabilitar la adición de la parte slug a los nombres del contenedor.

s / deshabilitado / habilitado /. Al menos en las versiones de archivos de redacción existentes.

Este comportamiento debe estar vinculado al número de versión del archivo de redacción. Independientemente de si este comportamiento fue "especificado", se usa bastante y, por lo tanto, es un cambio incompatible con versiones anteriores. ¿Por qué versionar la especificación en ese punto de todos modos si no se garantiza que lo que hace un archivo de redacción funcione de la misma manera cuando actualizo mi binario? Depreciar una especificación de archivo de redacción (con muchas advertencias cuando se ejecuta docker-compose por supuesto) y luego eliminarla, definitivamente sería mi culpa que todas mis cosas ya no funcionen, pero espero que lea su versión notas para un programa que tiene el privilegio de imprimirme mensajes de advertencia en mi cara?

Hacer cambios como este parece una buena motivación para versionar el comportamiento de la especificación además de su formato: puede desaprobar las suposiciones del código de otros con una advertencia. Creo que la cantidad de problemas externos que mencionan este problema habla de lo sorprendente que fue para mucha gente. Es realmente genial ver cómo se destruye el comportamiento heredado para que el código no se complique, pero cambios como ese no se pueden aplicar todos a la vez. ¿Puedo esperar que se rompan otras suposiciones sobre la composición de nombres de contenedores? ¿El nombre del servicio estará siempre en el nombre del contenedor o se puede eliminar como los nombres predecibles?

Esto realmente me recuerda cuando la denominación de dispositivos de red coherente recibió una adopción generalizada en Linux (pero esto es lo opuesto con la denominación ... idk). Se codificó una gran cantidad de código para ethN (y todavía se encuentra en algunos lugares sorprendentes) y eso realmente no ha cambiado. Sin embargo, existe una manera de recuperar el comportamiento anterior en los sistemas systemd (y en otros sistemas, pero puede variar) agregando net.ifnames=0 a los argumentos del kernel.

(Perdón por la perorata del segundo pase, pero no creo que el primero haya sido muy constructivo).

Parece que este cambio hace que la opción --scale inútil. porque se debe saber que el sufijo aleatorio alcanza instancias escaladas de un servicio.

Por ejemplo, varias instancias de servicio como servidores ascendentes para Nginx.

Editar: consulte el n. ° 6365 para obtener más información

Vaya, qué cambio tan terrible. 👎

¿Cómo se supone que obtengamos la cadena generada aleatoriamente para su uso en scripts?

También me encontré con este problema y me gustaría expresar mi recomendación para futuros cambios incompatibles con versiones anteriores. Nosotros también tenemos scripts que se basan en el formato project_service_index, y muchas personas usan esos scripts en Mac. En un mundo ideal, podríamos controlar la versión de Docker para Mac que usa la gente, pero por ahora la gente actualiza cuando aparece el cuadro de diálogo de actualización automática.

Mis problemas y recomendaciones son:

1) El cuadro de diálogo de actualización no tenía ninguna indicación de este cambio significativo, por lo que no teníamos ningún aviso obvio sobre este cambio. En un mundo ideal, verificaríamos todas las notas de la versión de cada actualización, pero no lo hacemos por el momento. Por lo tanto, sería muy apreciado si se llamara explícitamente a algo significativo como esto en el cuadro de diálogo de actualización.

2) Debido a 1), no hubo ninguna advertencia obvia. Sería genial si se hiciera un cambio como este en la actualización anterior. Por ejemplo, la actualización anterior a la última diría algo como "el esquema de nomenclatura de contenedores está cambiando en la próxima versión, actualice sus scripts".

3) Entiendo que, después de leer este hilo, el esquema de nomenclatura que estamos usando no está garantizado, y me doy cuenta de que hay mejores formas en las que podemos referirnos a los contenedores. Sin embargo, todos tenemos una vida laboral ocupada y necesitamos planificar nuestras tareas, por lo que, como responsable de mantener nuestros scripts, no puedo convertir nuestro uso de los nombres de contenedores en algo mejor de inmediato. Me complace utilizar las mejores prácticas recomendadas, pero necesito tiempo para migrar nuestro código. Por lo tanto, sería genial tener una estrategia de depreciación para un cambio como este.

La conclusión clave aquí es que la mayor parte del mundo asume un esquema de nomenclatura de contenedores que es fundamental para su uso de la ventana acoplable, y cambiar el comportamiento predeterminado sin una estrategia de depreciación obvia puede ser perjudicial para estos flujos de trabajo.

La gente no siempre usa el software exactamente de la manera en que fue diseñado, y la propiedad está en esas personas para arreglar las cosas cuando sus suposiciones fallan. Sin embargo, unas pocas comunicaciones simples pueden ayudarnos a prepararnos para cambios futuros y ayudarían a motivarnos a pasar a las mejores prácticas más recientes.

Si anteriormente dependía de docker container exec -it project_php_1 bash , ya no puede usar esto.

Tienes que usar docker ps para encontrar el ID de servicio.

Sin embargo, no puede usar docker ps -q --filter=name=project_php porque coincidirá con los servicios denominados project_php y project_php_xdebug o cualquier otra cosa que coincida con project_php .

Los docker container exec -it project_php_1 bash previamente legibles ahora tienen que convertirse en esto:

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

Este fue un cambio mal pensado.

@jtreminio FWIW, desde el proyecto aún puedes hacer docker-compose exec php

Gracias a todos los que se tomaron el tiempo para compartir sus pensamientos sobre el cambio. Estamos de acuerdo en que esto fue mal manejado y un poco demasiado entusiasta de nuestra parte, y se ha revertido parcialmente en Compose 1.23.2 (mantenemos sufijos aleatorios para los contenedores creados por docker-compose run , lo que nos permite manejarlos con más elegancia : # 4688 # 4549 # 5240, como se pretendía inicialmente).

Avíseme si hay algún problema pendiente que deba abordarse.

¿Hay algún plan para agregar una opción de línea de comando para desactivar esto --no-slug o más preferiblemente --slug para que el valor predeterminado sea funcionar como solía hacerlo?

1.23.2 volver a como era antes.

Solo se revirtió por docker-compose up pero no por docker-compose run

¡Gracias por la rápida resolución de esto!

El 28 de noviembre de 2018, a las 8:09 p.m., Joffrey F [email protected] escribió:

Gracias a todos los que se tomaron el tiempo para compartir sus pensamientos sobre el cambio. Estamos de acuerdo en que esto se manejó mal y un poco demasiado entusiasta de nuestra parte, y se ha revertido parcialmente en Compose 1.23.2 (mantenemos sufijos aleatorios para los contenedores creados por docker-compose run, lo que nos permite manejarlos con más elegancia: # 4688 # 4549 # 5240, como se pretendía inicialmente).

Avíseme si hay algún problema pendiente que deba abordarse.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

@ shin- Supongo que esto se devolverá en algún momento, posiblemente en 1.24 (¿ya que es un cambio tan importante?). Si es así, ¿podría trabajar con la comunidad para comprender y recomendar mecanismos ligeros alternativos para las personas que los usaban sin babosas? No estoy seguro del mejor lugar para tener esa conversación.

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

cambió de <project>_<service>_<index> a <project>_<service>_<index>_<slug>

Esto es un error, no una característica.
¡Gracias!
Piense en los libros de jugadas ansible que se ejecutan con ansible_connection=docker ... 😔 !!
¿Deberíamos dar explícitamente container_name ? ¿O seguiremos actualizando nuestro inventario con el aleatorio <slug> !!.
¡Realmente muy mal!