Compose: Depends_on en la versión3

depends_on todavía existe en v3, pero las dependencias de chequeo de salud (y como resultado, la sintaxis extendida) no serán portadas.

HTH

Pero escribí un docker-compose v3 y trato de implementar en swarm, pero depend_on no funciona porque el contenedor no se está iniciando en la forma en que deben iniciarse.

¿Está usando docker-compose o docker stack deploy ?

Estoy usando docker stack deploy
y trato de implementarlo en un enjambre de 7 máquinas

¿Cuál sería el equivalente en docker-compose v3 para lograr algo como dependencias de chequeo de salud? Si va a eliminar esa funcionalidad en la v3, básicamente nunca debería usarla, o al menos debería haber una ruta de migración para esto.

¿Cuáles son las intenciones de introducirlo en un nuevo docker-compose v2.1 y luego eliminarlo para v3? Actualmente estoy configurando diferentes archivos de redacción para nuestras aplicaciones, pero no quiero usar funciones que se eliminarán en la próxima versión y, por lo tanto, evito que el uso se actualice a una versión más reciente del archivo de composición de docker.

Por el momento, debe asumir que la nueva sintaxis depends_on no se trasladará a v3, ya que no tenemos planes para hacerlo.

Sé que esa no es la respuesta que mucha gente quiere, pero espero que al menos ayude a dar algo de claridad.

¿Puedo preguntar por qué no está en los planes? Supongo que sería muy útil hacerlo.

Da claridad, pero no explica. ¿Puede explicar el por qué? ¿Y sobre las alternativas (si existen)?
Depende_on nos brinda una manera realmente fácil de depender de un servicio, en lugar de manejarlo dentro del contenedor (lo que podría significar envolver una imagen de terceros con un script de espera y tener que mantenerlo).

@ shin- ¿por qué lo implementaste en 2.1, entonces? Si la gente lo usa y llega a depender de él, nunca podrá actualizarlo. Con el debido respeto, parece una planificación muy pobre por parte de sus muchachos.

Entonces, ¿cuál es la sintaxis de dependencias admitida para v3? https://docs.docker.com/compose/compose-file/#version -3 no menciona depende_en, y cuando uso docker-compose v1.10 para implementar una aplicación, ni la versión2 ni la versión 2.1 dependen_on funcionan para yo en un archivo de redacción v3 ...

@mustafaakin

¿Puedo preguntar por qué no está en los planes? Supongo que sería muy útil hacerlo.

@hsmade

¿Puede explicar el por qué? ¿Y sobre las alternativas (si existen)?

De https://github.com/docker/docker/issues/30404#issuecomment -274825244

depends_on es una operación cuando se usa con docker stack deploy . Los servicios del modo Swarm se reinician cuando fallan, por lo que no hay razón para retrasar su inicio. Incluso si fallan algunas veces, eventualmente se recuperarán.

@brettmc

Entonces, ¿cuál es la sintaxis de dependencias admitida para v3?

Cuando se usa docker-compose , la sintaxis admitida para v3 es la sintaxis de lista (similar a la que se usa para 2.0). Si está usando docker stack deploy , las dependencias no serán respetadas (vea arriba para justificación)

El formato de la versión 3 es el primer paso para alejarse de la herramienta externa docker-compose hacia la solución integrada docker stack . La implementación actual tiene sus peculiaridades en las que se está trabajando. El soporte para el formato de la versión 3 en docker-compose está destinado a ayudar en esa transición. Muchas cosas han cambiado y mejorado en Docker desde que fig / Compose se introdujo por primera vez, y eso significa que muchas de las cosas que solían tener sentido ahora se han vuelto obsoletas. docker stack es un nuevo comienzo usando nuevos conceptos y elimina algunos de los conceptos y sintaxis más difíciles de manejar, desde volumes_from hasta depends_on .
Si tiene inquietudes particulares acerca de algunos de esos cambios, infórmelos en el repositorio de la
Si aún no está listo para la transición a los servicios de Docker y docker stack , no dude en seguir usando el formato v2. Si bien es razonable suponer que el proyecto finalizará en algún momento en el futuro, se anunciará con mucha anticipación. Y después de eso, el código permanecerá disponible y de código abierto.

Gracias. Ahora tiene sentido.

Los servicios del modo Swarm se reinician cuando fallan, por lo que no hay razón para retrasar su inicio. Incluso si fallan algunas veces, eventualmente se recuperarán.

En mi humilde opinión, este no es un buen enfoque. No todos los servicios pueden detectar correctamente que los otros servicios de los que dependen no están listos, lo intentan muchas veces y luego fallan, por lo que el contenedor podría morir más tarde. Todavía necesitamos introducir scripts de envoltura de punto de entrada, lo cual no es muy agradable. La dependencia de control saludable fue muy buena, pero simplemente no es compatible con el modo enjambre.

Los servicios del modo Swarm se reinician cuando fallan, por lo que no hay razón para retrasar su inicio. Incluso si fallan algunas veces, eventualmente se recuperarán.

¡Hola a todos!
¿Significa que si, por ejemplo, tengo un servicio que se ejecuta y termina su trabajo muy rápidamente (y debería ejecutarse solo una vez por diseño), se iniciará una y otra y otra vez ... repetidamente?

@ Marvel77 De forma predeterminada, sí, pero puede anular ese comportamiento usando la sección deploy.restart_policy : https://docs.docker.com/compose/compose-file/#restartpolicy

@ shin- ¡Muchas gracias!

@mustafaakin En realidad, la mejor práctica es (en mi humilde opinión) tener una conexión tolerante a fallas con los servicios de los que depende. Por ejemplo, si usa una base de datos, puede retrasar el inicio hasta que responda. Pero, ¿cómo maneja un reinicio de la base de datos? Su aplicación debería poder recuperarse de esto, y luego tampoco necesita depender de 'depend_on'.
En cierto sentido, la desaprobación es algo bueno. Estas comodidades nos vuelven perezosos.

@hsmade Pero casi todos los init (upstart, systemd) dependen de la relación. Entonces no es que ser vago, es lo que tiene sentido. El demonio SSHD no se inicia hasta que tenga listo su dispositivo de red. No tengo control sobre todos los sistemas que tengo, sí, puedo hacer que mis sistemas sean tolerantes a fallas. Pero suponga que A depende de B. A tarda un poco en inicializarse, no es muy determinista. Entonces, ¿cómo se puede escribir una política de reinicio en B? reiniciar para siempre? ¿Y si no quieres eso?

Este es un problema mayor que Compose, Compose simplemente los inicia. Swarm es lo que los hace correr, así que creo que Swarm debería manejar esta relación de dependencia de la salud.

@mustafaakin No creo que pueda comparar la ejecución de

Pero, de nuevo, estos son mis pensamientos al respecto, y podría estar equivocado;)

Sí, no tiene sentido para los microservicios, pero no todo es un microservicio, ejecuto Hadoop en un contenedor. Docker no es solo para microservicios. Como dije, es genial para los entornos que tengo control, pero en las cosas que no tengo control, requiere envolver el punto de entrada de los servicios. Simplemente se resolvió con depede_on con healtcheck, creo que sería genial tenerlo también en Swarm. Reiniciar de forma continua es solo la elección de un perezoso.

Chicos

Creo que hay una especie de concepto erróneo de "tolerancia a fallas" y una especie de "inicialización por primera vez".
Acepte que el enfoque suena lo suficientemente bien para el primero, pero el segundo es un verdadero dolor de cabeza.
Me imagino que no solo yo, sino que en general uno necesitaría comenzar los servicios en un orden particular, ya que dependen unos de otros más o menos.

Tener reinicios continuos en la fase de inicialización y esperar a que los servicios en algún momento comiencen en el orden correcto por sí mismos es como una pesadilla: no se puede planificar ningún "tiempo de inactividad" para el proceso de inicio en caso de que ocurra lo peor. No solo lo peor, sino que a veces hay un tiempo de "mantenimiento" cuando algo debe cambiar y nadie podría predecir cuánto tiempo tardaría el sistema en iniciarse, porque los diferentes servicios se reinician por enjambre una y otra vez. nuevamente esperando el orden correcto.
Lo intenté y esperé para ver cómo iba con 7 contenedores y durante 20 minutos _swarm_ todavía no lo ha descubierto y todo el servicio seguía sin funcionar.
Por lo tanto, ni siquiera se puede decir cuánto tiempo tomaría recuperar y restaurar toda la infraestructura, ya que realmente se desconoce cuánto tiempo tomaría el _ arranque inicial_.
Me suena absurdo.

No creo que pueda entrar en la "producción" sin tal previsibilidad, aunque se supone que suceda raras veces (completamente), lo mejor es que nunca suceda.
Pero exactamente si todavía sucede, estaría en el lugar y tendré el desafío de restaurar lo antes posible y, justo en ese momento y presión, no tendría ni idea de cuánto tiempo comenzarían mis contenedores solo porque continúan reiniciándose durante el _startup._

@ozlatkov Esto realmente debería publicarse en el rastreador de problemas de la

@ shin- ¡Gracias! Lo moví a docker / docker tracker:

https://github.com/docker/docker/issues/31333

Creo que es realmente malo que el equipo de Docker asuma que se usa Docker Swarm. Se supone que Redactar es una herramienta independiente totalmente funcional.

Sin embargo, usamos mucho Docker Compose en nuestras canalizaciones de prueba y una ELIMINACIÓN tan fundamental de características (sin ofrecer una alternativa viable) realmente está teniendo efectos negativos dramáticos en sus usuarios.

Actualmente estoy revisando un RP muy feo de los miembros de mi equipo donde están tratando de encontrar todo tipo de soluciones para esto (ya que dependemos en gran medida de esta funcionalidad), incluida la permanencia en Compose 2.X por toda la eternidad.

Se supone que Docker nos ayuda a alcanzar nuestros objetivos, no lo dificulta al eliminar funciones críticas en las que muchos equipos ya confían.

Reconsidere la posibilidad de migrar todo esto a Docker Compose 3.

Muy apreciado.

Por centésima vez ahora: no hay razón para usar el formato v3 si no tiene la intención de usar servicios de enjambre.

¿Significa eso que el equipo se compromete a admitir los formatos 2.X para aquellos que utilizan componer como una herramienta de desarrollo independiente?

Exactamente mi pregunta: ¿el equipo de Compose está comprometido a soportar el formato v2 para siempre?

No podemos estandarizar en Docker Compose si el formato v2 está programado para su desaprobación en cualquier momento.

Siento que esto fuerza a todos los contenedores a un patrón init container , elimina la política de reinicio de la ventana acoplable y crea un enfoque hacky para el orden de inicio. ¿Debería asumirse que> = v3 de compose se moverá en esta dirección para centrarse en las pilas y crear paquetes de aplicaciones? Y si eso es correcto, ¿podría indicarme cómo mantener el orden de inicio en una pila de docker? ¿Es wait-for-it.sh o dockerize el enfoque allí?

¿Cuál es el equivalente declarativo de docker-compose.yml para una pila?

Hola chicos, ¿cuál es la mejor práctica si tengo la intención de usar la pila de docker y deshacerme de docker-compose?

Esta parece ser la solución, pero tener una especie de scripts hacky para iniciar contenedores no parece una buena práctica. ¿Lo hace?

Gracias.

@mustafaakin ¡ Gracias por tu

@VinceOPS No estoy seguro acerca de las "mejores prácticas", pero he estado usando chequeos de salud y restart: always por lo que solo funciona hasta que funciona ¯ \ _ (ツ) _ / ¯

@hutchic Pero como se mencionó en la conversación anterior, no podría tener una fecha de finalización, una especie de reinicio circular en caso de falla.

¿Por qué el equipo de Docker elimina esta función en la versión 3 y rechaza agregarlas?

@ tianhao-au vea la discusión en https://github.com/moby/moby/issues/31333 (y https://github.com/moby/moby/issues/31333#issuecomment-409143581)

Para redactar, también dejé una sugerencia en https://github.com/moby/moby/issues/31333#issuecomment -333265696 (tenga un x-depends_on )

Este cambio de función es, literalmente, la razón por la que ya no uso docker-compose. Si estoy usando Docker en producción y Docker-compose localmente para entornos de desarrollo, ahora debo hacer que mis contenedores Docker se comporten radicalmente diferentes en desarrollo que en producción. En producción, confío en un sistema de orquestación para asegurar la salud y el orden de mis implementaciones. En dev land, la orquestación la realizaba docker-compose. Ahora estoy escribiendo un montón de scripts destrozados para comprobar el estado de las cosas para orquestar mi sistema. Si voy a hacer eso, ¿por qué no escribir un golang para administrar mis acopladores y terminar con eso? Un poco desanimado se cayó. Solo mi 2p

Tratando de usar la última versión de Docker-Comose para hacer las cosas más preparadas para el futuro y tropecé con este problema. Esto es triste.