Docker Compose: del desarrollo a la producción

Traducción de la transcripción del podcast preparado con antelación al inicio del curso "Administrador de Linux"

Docker Compose es una herramienta increíble para crear escritorio
entorno para la pila utilizada en su aplicación. Te permite definir
cada componente de su aplicación, siguiendo una sintaxis clara y sencilla en YAML-
archivos.

Con la llegada de ventana acoplable componer v3 estos archivos YAML se pueden usar directamente en el entorno de producción, cuando se trabaja con
grupo Enjambre Docker.

Pero, ¿eso significa que puede usar el mismo archivo docker-compose en
proceso de desarrollo y entorno de producción? O use el mismo archivo para
¿puesta en escena? Bueno, en general, sí, pero para dicha funcionalidad necesitamos lo siguiente:

• Interpolación de variables: uso de variables de entorno para algunos
  valores que cambian en cada entorno.
• Anulación de configuración: la capacidad de definir un segundo (o cualquier
  otro archivo de seguimiento) docker-compose que cambiará algo con respecto a
  el primero, y docker compose se encargará de fusionar ambos archivos.

Diferencias entre archivos de desarrollo y producción

Durante el desarrollo, lo más probable es que desee verificar los cambios de código en
modo de tiempo real. Para ello, normalmente, se monta el volumen con el código fuente en
un contenedor que contiene el tiempo de ejecución de su aplicación. Pero para un entorno de producción
esta forma no es adecuada.

En producción, tiene un clúster de varios nodos y el volumen es local.
en relación con el host en el que se ejecuta su contenedor (o servicio), por lo que no
puede montar el código fuente sin operaciones complejas, que incluyen
sincronización de códigos, señales, etc.

En su lugar, normalmente queremos crear una imagen con una versión específica de su código.
Es costumbre marcarlo con la etiqueta adecuada (puede usar semántica
control de versiones u otro sistema de su elección).

Anulación de configuración

Dadas las diferencias y que sus dependencias pueden diferir en escenarios
desarrollo y producción, está claro que necesitaremos diferentes archivos de configuración.

Docker compose admite la combinación de diferentes archivos de composición para
obtener la configuración final. Cómo funciona se puede ver en un ejemplo:

$ cat docker-compose.yml
version: "3.2"

services:
  whale:
    image: docker/whalesay
    command: ["cowsay", "hello!"]
$ docker-compose up
Creating network "composeconfigs_default" with the default driver
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ________
whale_1  | < hello! >
whale_1  |  --------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Como se ha dicho, docker compose admite la combinación de varias composiciones.
archivos, esto le permite anular varias opciones en el segundo archivo. Por ejemplo:

$ cat docker-compose.second.yml
version: "3.2"
services:
  whale:
    command: ["cowsay", "bye!"]

$ docker-compose -f docker-compose.yml -f docker-compose.second.yml up
Creating composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Esta sintaxis no es muy conveniente en el proceso de desarrollo, cuando el comando
hay que hacerlo varias veces.

Afortunadamente, docker compose busca automáticamente un archivo especial llamado
docker-compose.override.yml para anular los valores docker-compose.yml. Si
cambie el nombre del segundo archivo, obtendrá el mismo resultado, solo usando el comando original:

$ mv docker-compose.second.yml docker-compose.override.yml
$ docker-compose up
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Está bien, eso es más fácil de recordar.

Interpolación de variables

Soporte de archivos de configuración interpolación
variables y valores predeterminados. Es decir, puedes hacer lo siguiente:

services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
...

y si lo haces compilación docker-compose (o inserción) sin variable de entorno
$MI_SERVICIO_VERSION, se utilizará el valor más recientepero si te pones
el valor de la variable de entorno antes de la compilación, se usará al compilar o empujar
registrarse registro.privado.mio.

Mis principios

Los enfoques que son convenientes para mí pueden ser útiles para usted. sigo esto
reglas simples:

• Todas mis pilas para producción, desarrollo (u otros entornos) se definen a través de
  Docker-compose archivos.
• Los archivos de configuración necesarios para cubrir todos mis entornos, máx.
  evitar la duplicación.
• Necesito un comando simple para trabajar en todos los entornos.
• La configuración principal se define en el archivo. docker-compose.yml.
• Las variables de entorno se utilizan para definir etiquetas de imagen u otros
  variables que pueden cambiar de un entorno a otro (puesta en escena, integración,
  producción).
• Los valores de las variables para la producción se utilizan como valores por
  por defecto, esto minimiza los riesgos si ejecuta la pila en producción sin
  establecer la variable de entorno.
• Para iniciar un servicio en un entorno de producción, utilice el comando docker stack deployment - componer archivo docker-compose.yml - with-registry-auth my-stack-name.
• El entorno de trabajo se inicia con el comando docker-componer up -d.

Veamos un ejemplo sencillo.

# docker-compose.yml
...
services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
    environment:
      API_ENDPOINT: ${API_ENDPOINT:-https://production.my-api.com}
...

И

# docker-compose.override.yml
...
services:
  my-service:
    ports: # This is needed for development!
      - 80:80
    environment:
      API_ENDPOINT: https://devel.my-api.com
    volumes:
      - ./:/project/src
...

Puedo usar docker-compose (docker-componer arriba)para ejecutar la pila en
modo de desarrollo con código fuente montado en /proyecto/origen.

¡Puedo usar los mismos archivos en producción! Y podría usar exactamente
mismo archivo docker-compose.yml para puesta en escena Para ampliar esto a
producción, solo necesito construir y enviar la imagen con una etiqueta predefinida
en la etapa de CI:

export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml push

En producción, esto se puede ejecutar con los siguientes comandos:

export MY_SERVICE_VERSION=1.2.3
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

Y si quieres hacer lo mismo en el escenario, solo necesitas definir
Variables de entorno necesarias para trabajar en el entorno de ensayo:

export MY_SERVICE_VERSION=1.2.3
export API_ENDPOINT=http://staging.my-api.com
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

Como resultado, usamos dos archivos docker-compose diferentes que, sin
¡Se pueden usar configuraciones duplicadas para cualquiera de sus entornos!

Más información sobre el curso "Administrador de Linux"

Fuente: habr.com