ProHoster > Blog > Administración > Docker Compose: dende o desenvolvemento ata a produción

Docker Compose: dende o desenvolvemento ata a produción

Tradución da transcrición do podcast elaborada en previsión do comezo do curso "Administrador Linux"

Docker Compose: dende o desenvolvemento ata a produción

Docker Compose é unha ferramenta incrible para crear un traballo
ambiente para a pila utilizada na súa aplicación. Permite definir
cada compoñente da súa aplicación, seguindo unha sintaxe clara e sinxela en YAML-
arquivos.

Coa chegada de docker compose v3 estes ficheiros YAML pódense usar directamente no ambiente de produción cando se traballa con eles
clúster Enxame Docker.

Pero isto significa que podes usar o mesmo ficheiro docker-compose?
proceso de desenvolvemento e no ambiente de produción? Ou use o mesmo ficheiro para
posta en escena? Ben, en xeral, si, pero para esta funcionalidade necesitamos o seguinte:

  • Interpolación de variables: utilizando variables de ambiente para algúns
    valores que cambian en cada ambiente.
  • Anulación de configuración: capacidade de definir un segundo (ou calquera
    outro ficheiro posterior) docker-compose que cambiará algo ao respecto
    primeiro, e docker compose encargarase de combinar ambos ficheiros.

Diferenzas entre ficheiros de desenvolvemento e produción

Durante o desenvolvemento, o máis probable é que queira comprobar os cambios no código
tempo real. Para iso, normalmente se monta o volume co código fonte
contenedor que contén o tempo de execución para a súa aplicación. Pero para un ambiente de produción
Este método non é adecuado.

En produción, tes un clúster con moitos nodos e o volume é local
en relación ao nodo no que se está a executar o teu contedor (ou servizo), polo que non o fas
pode montar o código fonte sen operacións complexas que inclúan
sincronización de códigos, sinais, etc.

En cambio, normalmente queremos crear unha imaxe cunha versión específica do teu código.
É habitual marcalo coa etiqueta axeitada (podes usar a semántica
versión ou outro sistema ao seu criterio).

Anulación da configuración

Dadas as diferenzas e que as súas dependencias poden diferir nos escenarios
desenvolvemento e produción, está claro que necesitaremos diferentes ficheiros de configuración.

Docker Composite admite a combinación de diferentes ficheiros de composición
obter a configuración final. Como funciona isto pódese ver no exemplo:

$ 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 dixo, docker compose admite a combinación de varias composicións:
ficheiros, isto permítelle anular varios parámetros no segundo ficheiro. Por exemplo:

$ 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 sintaxe non é moi conveniente durante o desenvolvemento, cando o comando
haberá que facer moitas veces.

Afortunadamente, docker compose busca automaticamente un ficheiro especial chamado
docker-compose.override.yml para anular valores docker-compose.yml. Se
renomear o segundo ficheiro, obterás o mesmo resultado, só usando o comando orixinal:

$ 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

Vale, é máis fácil de lembrar.

Interpolación de variables

Soporte de ficheiros de configuración interpolación
variables e valores predeterminados. É dicir, podes facer o seguinte:

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

E se o fas compilación docker-compose (ou push) sen variable de ambiente
$MY_SERVICE_VERSION, utilizarase o valor últimapero se estableces
o valor da variable de ambiente antes da compilación, utilizarase ao construír ou empurrar
ao rexistro rexistro.privado.mine.

Os meus principios

Os enfoques que me funcionan poden funcionar para ti tamén. Eu sigo estes
regras sinxelas:

  • Todas as miñas pilas para produción, desenvolvemento (ou outros ambientes) están definidas
    ficheiros docker-compose
  • Ficheiros de configuración necesarios para cubrir todos os meus ambientes, na medida do posible
    evitar a duplicación.
  • Necesito un comando sinxelo para traballar en cada ambiente.
  • A configuración principal está definida no ficheiro docker-compose.yml.
  • As variables de ambiente úsanse para definir etiquetas de imaxe ou outras
    variables que poden variar dun ambiente a outro (escenificación, integración,
    produción).
  • Os valores das variables de produción utilízanse como valores para
    por defecto, isto minimiza os riscos se a pila se lanza en produción sen
    establecer a variable de ambiente.
  • Para iniciar un servizo nun ambiente de produción, use o comando implementación de pila docker - ficheiro de composición docker-compose.yml -with-registry-auth o meu-nome-pila.
  • O ambiente de traballo iníciase mediante o comando docker-compose -d.

Vexamos un exemplo sinxelo.

# 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
...

Podo usar docker-compose (docker-compose)para executar a pila
modo de desenvolvemento co código fonte montado en /proxecto/src.

Podo usar estes mesmos ficheiros na produción! E definitivamente podería usar
mesmo ficheiro docker-compose.yml para a posta en escena. Para ampliar isto a
produción, só teño que construír e enviar a imaxe cunha etiqueta predefinida
na fase de CI:

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

En produción, pódese executar usando os seguintes comandos:

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

E se queres facer o mesmo no escenario, só tes que definir
variables de ambiente necesarias para traballar no ambiente de preparación:

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 dous ficheiros docker-compose diferentes, que sen
As configuracións duplicadas pódense usar para calquera ambiente que teñas.

Máis información sobre o curso "Administrador Linux"

Fonte: www.habr.com

Engadir un comentario