Docker Compose es una forma eficiente y fácil de implementar contenedores Docker en un host. Componer toma un archivo yaml y crea contenedores de acuerdo con sus especificaciones. La especificación incluye qué imágenes se necesitan para implementarse, qué puertos específicos se necesitan para ser expuestos, volúmenes, CPU y límites de uso de memoria, etc.

Es una manera fácil de configurar la implementación automatizada de la aplicación con una frontend, una base de datos y algunas contraseñas y claves de acceso en buena medida. Cada vez que ejecuta Docker-Compose desde dentro de un directorio que contiene un Docker-Compose.YML pasa por el archivo e implementa su aplicación como se especifica.

Para ayudarlo a escribir su propio Docker-Compose.YML Aquí hay 5 fragmentos de Yaml simples y, con suerte, útiles que puedes mezclar y combinar.

1. Nginx proxy inverso

Probablemente la aplicación más común que se implementa como contenedor Docker es Nginx. NGINX puede servir como servidor proxy inverso y como punto de terminación SSL para sus aplicaciones web. Diferentes sistemas de administración de contenido como Ghost y WordPress se pueden alojar detrás de un solo servidor de proxy inverso NGINX y, por lo tanto, tiene sentido tener un fragmento de servidor NGINX a mano en todo momento. Lo primero que necesitaría es un archivo de configuración de Nginx. Si elige no crear uno, el servidor HTTP predeterminado es lo que obtendrá.

Por ejemplo, crearía una carpeta Nginx Configuración en mi carpeta de inicio. El archivo de configuración nginx.Conf estará presente dentro de esta carpeta, junto con otros directorios de archivos que Nginx esperaría en /etc /nginx. Esto incluye certs y claves SSL, y nombres de host para los servidores de backend donde el tráfico debe reenviarse.

Esta carpeta se puede montar dentro del contenedor NGINX AT /ETC /NGINX (con permiso de solo lectura si prefiere precaución adicional) y puede ejecutar el servidor como contenedor, pero puede configurarlo localmente desde su directorio de inicio sin tener que iniciar sesión en el contenedor.

Esta es una muestra:

Versión: '3'
servicios:
Nginx:
Imagen: Nginx: Último
Volúmenes:
- /Home/User/Nginx Configuración:/etc/nginx
Puertos:
- 80:80
- 443: 443

Blog Ghost

Ghost es un CMS escrito principalmente en el nodo.JS y es simplista, rápido y elegante en diseño. Se basa en Nginx para enrutar el tráfico y utiliza mariadb o a veces sqlite para almacenar datos. Puede implementar una imagen Docker rápida y sucia para Ghost usando un fragmento simple como se muestra a continuación:

Versión: '3'
servicios:
fantasma:
Imagen: Ghost: Último
Puertos:
- 2368: 2368
Volúmenes:
- Ghost-data:/var/lib/fantasma/contenido/
Volúmenes:
Data fantasma:

Esto crea un nuevo volumen y lo monta dentro del contenedor para almacenar el contenido del sitio web de manera persistente. Puede agregar el servicio de proxy inverso de Nginx anterior a este archivo de composición y tener un blog de fantasma de grado de producción en cuestión de minutos, siempre que haya configurado Nginx para enrutar el tráfico relevante desde el puerto 80 o 443 al puerto 2368 en el fantasma envase.

Mariada

MariadB es un software bastante útil para no estar disponible en un momento en su servidor. Sin embargo, las bases de datos crean muchos registros, los datos reales tienden a extenderse por todo el lugar y configurar servidores de bases de datos y/o clientes nunca se vuelven sin problemas. El archivo Docker-compuesto cuidadosamente elaborado puede mitigar algunos de los problemas tratando de almacenar todos los datos relevantes en un solo volumen de Docker, mientras que la base de datos software y sus complejidades están escondidas en el contenedor A:

Versión: '3'
servicios:
MyDB:
Imagen: mariadb
ambiente:
- Mysql_root_password = my-secret-pw

Puede crear un nuevo contenedor de base de datos para cada nueva aplicación, en lugar de crear más usuarios en la misma base de datos, configurar privilegios y pasar por un rigmarole doloroso para garantizar que cada aplicación y usuario permanezcan en su propio césped. Tampoco tendrá que abrir puertos en el sistema de host, ya que el contenedor de la base de datos se ejecutará en su propia red aislada y puede tenerlo para que solo su aplicación pueda ser parte de esa red y, por lo tanto, acceder a la base de datos.

Pila de WordPress

Una culminación de todas las diversas partes desde el uso de variables de entorno hasta ejecutar un servidor web frontend y una base de datos de backend se puede combinar en un archivo Docker-compuesto para un sitio web de WordPress, como se muestra a continuación:

Versión: '3.3 '
servicios:
DB:
Imagen: MySQL: 5.7
Volúmenes:
- db_data:/var/lib/mysql
reiniciar: siempre
ambiente:
Mysql_root_password: SomeWordPress
Mysql_database: WordPress
Mysql_user: WordPress
Mysql_password: WordPress
WordPress:
depende de:
- db
Imagen: WordPress: Último
Puertos:
- "8000: 80"
reiniciar: siempre
ambiente:
WordPress_DB_Host: DB: 3306
WordPress_DB_user: WordPress
WordPress_DB_Password: WordPress
Volúmenes:
db_data:

Este es el ejemplo más popular y también se menciona en la documentación oficial de Docker-Compose. Lo más probable es que no implementará WordPress, pero el archivo de composición aquí aún puede servir como una referencia rápida para pilas de aplicaciones similares.

Docker-compuesto con Dockerfiles

Hasta ahora solo hemos estado lidiando con el lado de implementación pura de Docker-Compose. Pero es probable que use Compose para no solo implementar, sino desarrollar, probar y entonces implementar aplicaciones. Ya sea que se ejecute en su estación de trabajo local, o en un servidor CD/CI dedicado, Docker-Compose puede construir una imagen utilizando el DockerFile presente en la raíz del repositorio con respecto a su aplicación o parte de la aplicación:

Versión: '3'
servicios:
Interfaz:
construir: ./Código frontend
back-end:
Imagen: mariadb
…

Habrá notado que, si bien el servicio de backend está utilizando una imagen preexistente de MariadB, la imagen frontend se construye primero desde el Dockerfile ubicado en el interior ./directorio de código frontend.

Bloques de LEGO de Docker-Compose

Toda la funcionalidad de Docker-Compose es bastante fácil de comprender si solo nos preguntamos por primera vez qué es lo que estamos tratando de construir. Después de algunos errores tipográficos y un intento fallido, se le dejará un conjunto de fragmentos que funcionan sin problemas y se pueden juntar como bloques de construcción de LEGO para definir su implementación de aplicaciones.

Espero que los pocos ejemplos anteriores te den una buena ventaja con eso. Puede encontrar la referencia completa para escribir el archivo de composición aquí.