Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

294
Vistas
Sirviendo nuevos archivos estáticos a través de nginx almacenados en el contenedor php-fpm después de la actualización

Tengo los siguientes contenedores:

  • nginx:latest
  • contenedor myapp (derivado de php-fpm:alpine)

Actualmente tengo un proyecto ficticio con canalización de CI que, en tiempo de compilación, compila la variante de producción de recursos (images/js/css,...). Los archivos de compilación terminan en (/public/build). Al final de la canalización de CI, empaqueto todo en imágenes de Docker y lo cargo en Hub.

Tanto nginx como myapp tienen el volumen (no el montaje enlazado) configurado y apuntando a /opt/ci-test/public/build .

Esto funciona, por primera vez.

Pero digamos que agrego un nuevo archivo new.css : mi nueva versión de la imagen acoplable contendrá una variante de compilación de new.css .

La ejecución de un nuevo contenedor con un volumen preexistente no revela nuevos archivos y entiendo que no debería hacerlo. . Puedo crear un nuevo volumen my_app_v2 .

En este punto, nginx no ve este nuevo volumen y debe eliminarse y volver a ejecutarse (con un nuevo volumen) para que surta efecto.

¿Hay una manera fácil de superar esto?

Mi intención es usar el contenedor nginx para múltiples aplicaciones PHP y debo abstenerme de eliminarlo cada vez que actualizo una de las aplicaciones que se están sirviendo. ¿Es esta una mala decisión?

EDITAR:

Una solución que logré encontrar es eliminar todos los archivos del volumen adjunto e iniciar un nuevo contenedor myapp . Esto refleja todos los archivos más recientes en el volumen. Pero esto se siente sucio...

EDIT2:

Problema relacionado (caso 3): https://github.com/moby/moby/issues/18670#issuecomment-165059630

EDIT3:

Dockerfile

 FROM php:7.2.30-fpm-alpine3.11 COPY . /opt/ci-test WORKDIR /opt/ci-test VOLUME /opt/ci-test/public/build

Hasta ahora, no tengo docker-composer y ejecuto los contenedores manualmente a través de comandos:

 docker run -it -d --name php71alp -v shr_test:/opt/ci-test/public/build -p 9000:9000 <myaccount>/citest docker run -it -d --name nginx -v shr_test:/var/www/citest -p 80:80 nginx:latest
over 4 years ago · Santiago Trujillo
2 Respuestas
Responde la pregunta

0

Primera opción: no usar un volumen. Si desea tener acceso a los archivos desde la compilación de la imagen y no necesita persistencia, entonces el volumen no está ayudando con su flujo de trabajo.

Segunda opción: elimine el volumen anterior entre ejecuciones y use un volumen con nombre, cuya ventana acoplable se inicializará con el contenido de la imagen.

Tercera opción: modifique la compilación de la imagen y el punto de entrada del contenedor para guardar el directorio en una ubicación diferente durante la compilación y restaurar esa ubicación en el volumen al iniciarse el contenedor en el punto de entrada. Tengo una implementación de esto en los scripts save-volume y load-volume en mi imagen base . Se vuelve más complicado cuando desea fusionar el contenido del volumen con el contenido del host, y deberá decidir cómo manejar los archivos que se eliminan y qué cambios guardar de las ejecuciones anteriores.

over 4 years ago · Santiago Trujillo Denunciar

0

Simplemente no utilice un volumen para esto.

Debe tratar las imágenes de la ventana acoplable como "paquetes monolíticos" que contienen sus dependencias (nginx) y los archivos de su aplicación (imágenes, js, css...). No hay necesidad de tratar los archivos de su aplicación de manera diferente a nginx, todo es parte de la imagen de la ventana acoplable única.

Sin un volumen, ejecuta v1 de su imagen, nginx ve los archivos v1. Ejecutas v2 de tu imagen, nginx ve los archivos v2.

Los volúmenes están destinados a usarse cuando realmente desea mantener archivos entre versiones de contenedores (como bases de datos, cargas de archivos...). No para los activos estáticos de su sitio.

Mi intención es usar el contenedor nginx para múltiples aplicaciones PHP y debo abstenerme de eliminarlo cada vez que actualizo una de las aplicaciones que se están sirviendo. ¿Es esta una mala decisión?

Sí, este es un mal diseño. Si desea ejecutar varias aplicaciones, debe ejecutar 1 contenedor Docker por aplicación. De esa forma, cuando lanza una nueva versión de una aplicación, solo necesita reiniciar ese contenedor. No se supone que los contenedores se traten como máquinas virtuales tradicionales en las que "entra SSH" y configura las cosas manualmente. Los contenedores son "desechables". ¿Nueva versión de la aplicación? simplemente reemplace el contenedor por uno nuevo con una imagen más nueva.

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda