En mi aplicación tengo un contenedor nginx que quiero usar para servir archivos estáticos de aplicaciones web. Estos archivos de aplicación web existen en un contenedor separado llamado "aplicación web".
¿Cuál es la forma recomendada de montar el contenedor de la aplicación web en el contenedor nginx? Mi enfoque actual se ve así:
version: '2' services: nginx: volumes_from: - webapp webapp: image: someimageurlY en Dockerfile para la aplicación web, expongo un volumen en la misma ruta que está sirviendo el contenedor nginx.
Esto funciona muy bien, pero el problema es que en docker-compose v3, "volumes_from" se elimina y se reemplaza con volúmenes con nombre. Entonces mi nueva configuración se vería así:
version: '3' volumes: static-webapp: services: nginx: volumes: - static-webapp:/opt/webapp webapp: image: someimageurl volumes: - static-webapp:/opt/webappEl problema con esto es que los datos del contenedor de la aplicación web solo se copiarán en el volumen 'static-webapp' una vez. Después de cambiar el contenido y volver a ejecutar docker-compose up, el contenido del volumen no cambia. Entiendo que esto es por diseño, para no sobrescribir datos persistentes.
Mi pregunta es: ¿Cómo debo hacer esto con v3 de docker-compose? Básicamente, quiero un volumen sin nombre que pueda montar en varios contenedores.
Las soluciones que he pensado son:
1.) Agrupe el contenido estático en el contenedor nginx. No me gusta esto porque entonces no puedo mantener los requisitos separados.
2.) Podría eliminar manualmente el volumen 'static-webapp' después de cada ejecución de docker-compose. Esto tampoco parece ideal.
La forma recomendada es eliminar las dependencias entre contenedores, ya que estas dependencias no se aplican lógicamente al enjambre donde los contenedores pueden ejecutarse en diferentes hosts donde no pueden compartir archivos (es por eso que se eliminó volúmenes de la versión 3 formato). Los contenedores de datos ya habían quedado obsoletos después de la introducción de los volúmenes con nombre, a pesar de que alguna documentación desactualizada sugería lo contrario.
Las opciones que puedo pensar en la parte superior de mi cabeza incluyen:
Usar un archivo de composición de la versión 2 y no usar el modo de enjambre. No es necesario actualizar al formato de la versión 3 si no lo está utilizando con el modo de enjambre.
Agregue directamente sus datos a cada contenedor.
Rediseñe su aplicación para separar los componentes de manera diferente. No tengo claro el caso de uso del código de la aplicación tanto en nginx como en otro contenedor, parece que solo debería ser uno u otro.
Cree un contenedor de utilidad de sincronización de datos que tenga todos los datos de la aplicación, se ejecute globalmente en el enjambre y envíe cambios a los volúmenes en cada uno de los nodos del enjambre al inicio. Esto también podría sondear algo como un repositorio git y actualizar constantemente el volumen local sobre cualquier cambio. Sus otros contenedores luego apuntan a este volumen local con nombre.
Dirija los contenedores a un volumen remoto, como NFS, por lo que solo necesita actualizar los datos una vez desde cualquier host y eliminar cualquier host que no esté sincronizado, pero también agregar latencia adicional en cualquier lectura.