Estoy tratando de envolver mi cabeza alrededor de Docker, pero me está costando entenderlo. Traté de implementarlo en mi pequeño proyecto (pila MERN), y estaba pensando en cómo distinguir entre entornos de desarrollo (quizás puesta en escena) y producción.
Vi un ejemplo en el que usaron 2 archivos Docker y 2 archivos docker-compose (cada par para un entorno, por lo que Dockerfile + docker-compose.yml para prod, Dockerfile-dev + docker-compose-dev.yml para dev) .
Pero esto me parece un poco exagerado. Preferiría tenerlo solo en dos archivos.
También uno de los problemas es que, por ejemplo, para el desarrollo quiero instalar nodemon globalmente, pero no para la producción.
En solución perfecta me imagino ejecutando algo así
docker-compose -e ENV=dev build docker-compose -e ENV=dev upTenga en cuenta que todavía no entiendo completamente la ventana acoplable, por lo que si captó algunos de mis conceptos erróneos sobre la ventana acoplable, puede señalarlos.
Podría tomar algunas pistas de " Uso de Compose en producción "
Es casi seguro que querrá realizar cambios en la configuración de su aplicación que sean más apropiados para un entorno en vivo. Estos cambios pueden incluir:
- Eliminar los enlaces de volumen para el código de la aplicación, de modo que el código permanezca dentro del contenedor y no se pueda cambiar desde el exterior.
- Enlace a diferentes puertos en el host
- Establecer variables de entorno de manera diferente (p. ej., para disminuir la cantidad de detalles del registro o para habilitar el envío de correos electrónicos)
- Especificar una política de reinicio (por ejemplo, reiniciar: siempre) para evitar el tiempo de inactividad
- Agregar servicios adicionales (p. ej., un agregador de registros)
El consejo entonces no es muy similar al ejemplo que mencionas:
Por este motivo, probablemente desee definir un archivo Compose adicional, digamos
production.yml, que especifica la configuración adecuada para la producción. Este archivo de configuración solo necesita incluir los cambios que desea realizar desde el archivo original de Compose.docker-compose -f docker-compose.yml -f production.yml up -d
Este mecanismo de anulación es mejor que tratar de mezclar la lógica de desarrollo y producción en un archivo de composición, con una variable de entorno para probar y seleccionar uno.
Nota: Si nombra su segundo dockerfile docker-compose.override.yml , un simple docker-compose up leerá las anulaciones automáticamente.
Pero en tu caso, un nombre basado en el entorno es más claro.
Docker Compose leerá docker-compose.yml y docker-compose.override.yml de forma predeterminada. Entendiendo-Múltiples-Componer-Archivos
Puede configurar un docker-compose.yml predeterminado y un archivo de composición de sobrescritura diferente. Por ejemplo, docker-compose.prod.yml docker-compose.test.yml . Manténgalos en el mismo lugar.
Luego, cree un enlace simbólico llamado docker-compose.override.yml para cada entorno.
Realice un seguimiento de los archivos docker-compose.{env}.yml y agregue docker-compose.override.yml a .gitignore .
En entorno de producción: ln -s ./docker-compose.prod.yml ./docker-compose.override.yml
En entorno de prueba: ln -s ./docker-compose.test.yml ./docker-compose.override.yml
La estructura del proyecto se verá así:
project\ - docker-compose.yml # tracked - docker-compose.prod.yml # tracked - docker-compose.test.yml # tracked - docker-compose.override.yml # ignored & linked to override composefile for current env - src/ - ... Entonces lo has hecho. En cada entorno, puede usar el archivo de redacción con el mismo comando docker-compose up
Si no está seguro, use docker-compose config para verificar si se anuló correctamente.