ProHoster > Blog > administração > Docker Compose: do desenvolvimento à produção

Docker Compose: do desenvolvimento à produção

Tradução da transcrição do podcast preparada antes do início do curso "Administrador Linux"

Docker Compose: do desenvolvimento à produção

Docker Compose é uma ferramenta incrível para criar um ambiente funcional
ambiente para a pilha usada em seu aplicativo. Ele permite que você defina
cada componente da sua aplicação, seguindo uma sintaxe clara e simples em YAML-
arquivos.

Com o advento de docker compor v3 esses arquivos YAML podem ser usados ​​diretamente no ambiente de produção ao trabalhar com
conjunto Docker swarm.

Mas isso significa que você pode usar o mesmo arquivo docker-compose em
processo de desenvolvimento e no ambiente de produção? Ou use o mesmo arquivo para
encenação? Bem, em geral sim, mas para esta funcionalidade precisamos do seguinte:

  • Interpolação de variáveis: usando variáveis ​​de ambiente para alguns
    valores que mudam em cada ambiente.
  • Substituição de configuração: capacidade de definir um segundo (ou qualquer
    outro arquivo docker-compose subseqüente que mudará algo em relação
    primeiro, e o docker compose cuidará da mesclagem dos dois arquivos.

Diferenças entre arquivos de desenvolvimento e produção

Durante o desenvolvimento, você provavelmente desejará verificar as alterações de código em
tempo real. Para fazer isso, normalmente o volume com o código fonte é montado em
contêiner que contém o tempo de execução do seu aplicativo. Mas para um ambiente de produção
Este método não é adequado.

Na produção, você tem um cluster com muitos nós e o volume é local
em relação ao nó no qual seu contêiner (ou serviço) está sendo executado, para que você não
você pode montar o código-fonte sem operações complexas que incluem
sincronização de código, sinais, etc.

Em vez disso, geralmente queremos criar uma imagem com uma versão específica do seu código.
É costume marcá-lo com a tag apropriada (você pode usar semântica
versionamento ou outro sistema a seu critério).

Substituição de configuração

Dadas as diferenças e que suas dependências podem diferir em cenários
desenvolvimento e produção, é claro que precisaremos de diferentes arquivos de configuração.

Docker compose suporta mesclar diferentes arquivos de composição para
obter a configuração final. Como isso funciona pode ser visto 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 dito, docker compose suporta a combinação de múltiplas composições -
arquivos, isso permite substituir vários parâmetros no segundo arquivo. 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 não é muito conveniente durante o desenvolvimento, quando o comando
precisará ser feito muitas vezes.

Felizmente, o docker compose procura automaticamente um arquivo especial chamado
docker-compose.override.yml para substituir valores docker-compose.yml. Se
renomeie o segundo arquivo, você obterá o mesmo resultado, apenas usando o 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

Ok, isso é mais fácil de lembrar.

Interpolação de Variáveis

Suporte a arquivos de configuração interpolação
variáveis e valores padrão. Ou seja, você pode fazer o seguinte:

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

E se você fizer compilação docker-compose (ou push) sem variável de ambiente
$MY_SERVICE_VERSION, o valor será usado mais recentemas se você definir
o valor da variável de ambiente antes da construção, ela será usada ao construir ou enviar
para o registro private.registry.mine.

Meus principios

As abordagens que funcionam para mim podem funcionar para você também. Eu sigo estes
regras simples:

  • Todas as minhas pilhas para produção, desenvolvimento (ou outros ambientes) são definidas através
    arquivos docker-compose
  • Arquivos de configuração necessários para cobrir todos os meus ambientes, tanto quanto possível
    evite duplicação.
  • Preciso de um comando simples para funcionar em cada ambiente.
  • A configuração principal está definida no arquivo docker-compose.yml.
  • Variáveis ​​de ambiente são usadas para definir tags de imagem ou outras
    variáveis ​​que podem variar de ambiente para ambiente (preparação, integração,
    Produção).
  • Os valores das variáveis ​​de produção são usados ​​como valores para
    por padrão, isso minimiza os riscos se a pilha for lançada em produção sem
    definir variável de ambiente.
  • Para iniciar um serviço em um ambiente de produção, use o comando implantação da pilha do docker - compose-file docker-compose.yml -with-registry-auth meu-nome da pilha.
  • O ambiente de trabalho é iniciado usando o comando docker-compose up -d.

Vejamos um exemplo simples.

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

Eu posso usar docker-compose (docker-compose up)para executar a pilha
modo de desenvolvimento com código-fonte montado em /projeto/src.

Posso usar esses mesmos arquivos na produção! E eu definitivamente poderia usar
mesmo arquivo docker-compose.yml para encenação. Para expandir isso para
produção, só preciso construir e enviar a imagem com uma tag pré-definida
na fase CI:

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

Na produção, isso pode ser executado 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 você quiser fazer o mesmo no palco, basta definir
variáveis ​​de ambiente necessárias para trabalhar no ambiente de teste:

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 dois arquivos docker-compose diferentes, que sem
Configurações duplicadas podem ser usadas para qualquer ambiente que você tiver!

Saiba mais sobre o curso "Administrador Linux"

Fonte: habr.com

Adicionar um comentário