Mi archivo docker-compose es el siguiente:
version: '3' services: database: image: postgres restart: always environment: POSTGRES_PASSWORD: qwerty POSTGRES_USER: qwerty backend: depends_on: - database build: #Dockerfile used here will use python image,build the django project and run using uwsgi in port 4000 context: . dockerfile: dockerfile_uwsgi ports: - "4000:4000" image: backend_img environment: DB_HOST: database DB_NAME: qwerty DB_USER: qwerty DB_PASSWORD: qwerty migration: depends_on: - backend image: backend_img entrypoint: ["sh", "-c"] command: [" python manage.py collectstatic --noinput; python manage.py makemigrations; python manage.py migrate;"] environment: DB_HOST: database DB_NAME: qwerty DB_USER: qwerty DB_PASSWORD: qwerty frontend: depends_on: - backend build: #The dockerfile used her uses nginx image, it is configured to act as reverse proxy and serve static files. context: . dockerfile: dockerfile_nginx ports: - "9443:8443" Explicación sobre docker-compose.yaml : aquí, el contenedor backend configura el proyecto django y sirve el proyecto usando uwsgi, usando la misma imagen, el contenedor de migración recopilará los archivos estáticos de todos los directorios de la aplicación y los llenará en el directorio de trabajo actual del contenedor. . El contenedor frontend es un nginx, que actúa como proxy inverso. También me gustaría servir archivos estáticos desde el contenedor nginx.
El problema al que me enfrento aquí es que quiero que los archivos estáticos creados por el contenedor de migración aparezcan en el contenedor frontend. Para que nginx pueda servir los archivos estáticos. ¿Cómo se podría hacer esto?. Si se supone que el diseño no debe ser como se muestra aquí, sugiérame cómo podría rediseñarse para cumplir con el requisito.
Sé que usando el volumen compartido esto podría hacerse. Pero no quiero usar un volumen compartido, ya que los datos que se completan en el volumen compartido persistirán en él y supongamos que si el desarrollador modifica el contenido estático en la carpeta de la aplicación, los cambios no se completarán en el volumen, a menos que el punto de montaje del volumen esté vacío. . Esto se basa en lo que he observado, corríjame si me equivoco.
Lo que sea que esté sirviendo a sus recursos en la capa acoplable (gunicorn, uwsgi, lo que sea), probablemente admitirá el servicio de activos estáticos, y puede hacerlo de manera significativamente más eficiente que el propio django.
En su situación, nginx es esencialmente externo a su aplicación. En lugar de intentar "conseguir sus activos estáticos en nginx", deje que los clientes hagan ese trabajo y los almacenen en caché en nginx una vez que estén en proxy. Nginx tiene un buen soporte de almacenamiento en caché.
Si realmente desea obtener los recursos estáticos en un archivo , puede COPY --from=... como en https://docs.docker.com/develop/develop-images/multistage-build/ para copiar los recursos estáticos en su contenedor nginx personalizado. Use el contenedor django como fuente; deberá asegurarse de que esté construido después de su contenedor django. Es posible que esto no sea posible completamente dentro de docker-compose. Hay una fricción legítima allí; tendrá la misma fricción cuando/si intenta construir e implementar artefactos acoplables en servidores de producción.