Docker Compose: do desenvolvimento à produção

A tradução da transcrição do podcast foi preparada antes do início do curso Administrador Linux

Docker Compose é uma ferramenta incrível para criar um
ambiente para a pilha usada em seu aplicativo. Ele permite que você defina
cada componente de seu aplicativo, seguindo uma sintaxe clara e simples em YAML.
Com a chegada do.

docker compose v3, esses arquivos YAML podem ser usados diretamente em um ambiente de trabalho, ao trabalhar com um cluster.
Docker Swarm Mas isso significa que você pode usar o mesmo arquivo docker-compose no.

processo de desenvolvimento e em um ambiente de produção? Ou usar este mesmo arquivo para
estágio? Bem, de modo geral, sim, mas para tal funcionalidade precisamos do seguinte:
Interpolação de variáveis: uso de variáveis de ambiente para alguns

• valores que mudam em cada ambiente.
  Sobrescrição de configurações: a capacidade de definir um segundo (ou qualquer
• outro arquivo docker-compose subsequente) que altere algo em relação ao
  primeiro, e o docker compose cuidará da mesclagem de ambos os arquivos.
  Diferenças entre arquivos para desenvolvimento e produção

Durante o desenvolvimento, você provavelmente irá querer verificar as mudanças de código em

tempo real. Para isso, normalmente, o volume com o código-fonte é montado no
container que contém o runtime para seu aplicativo. Mas para o ambiente de produção,
esse método não é adequado.
Na produção, você tem um cluster com vários nós, e o volume é local em

relação ao nó onde seu container (ou serviço) está sendo executado, portanto você não
pode montar o código-fonte sem operações complicadas, que envolvem
sincronização de código, sinais, etc.
Ao invés disso, geralmente, queremos criar uma imagem com uma versão específica do seu código.

Isso é normalmente marcado com uma tag correspondente (pode-se usar versionamento semântico
ou outro sistema de sua escolha).
Sobrescrição de configurações

Considerando as diferenças e que suas dependências podem variar em cenários

de desenvolvimento e produção, é claro que precisaremos de diferentes arquivos de configuração.
O Docker Compose suporta a mesclagem de diferentes arquivos compose para

obter a configuração final. Como isso funciona pode ser visto no exemplo:
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  | 
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 foi mencionado, o docker compose suporta a combinação de vários compose-
arquivos, permitindo sobrepor diferentes 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  | 
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

Essa sintaxe não é muito conveniente durante o desenvolvimento, quando um comando
precisa ser executado várias vezes.

Felizmente, o docker compose procura automaticamente um arquivo especial chamado
docker-compose.override.yml para sobrepor valores docker-compose.yml. Se
renomear o segundo arquivo, o mesmo resultado será obtido, mas com 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  | 
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

Isso é bom, torna mais fácil de lembrar.

Interpolação de variáveis

Os arquivos de configuração suportam a interpolação
de 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ê executar docker-compose build (ou push) sem a variável de ambiente
$MY_SERVICE_VERSION, o valor latest, será usado, mas se você definir
o valor da variável de ambiente antes da construção, ele será utilizado durante a construção ou o push
para o registro private.registry.mine.

Meus princípios

As abordagens que são convenientes para mim podem ser úteis para você. Eu sigo estas
regras simples:

• Todos os meus stacks para produção, desenvolvimento (ou outros ambientes) são definidos através de
  arquivos docker-compose.
• Os arquivos de configuração, necessários para abranger todos os meus ambientes, evitam ao máximo
  a duplicação.
• Preciso de um único comando para trabalhar em cada ambiente.
• A configuração principal é definida no arquivo docker-compose.yml.
• As variáveis de ambiente são usadas para definir tags de imagens ou outras
  variáveis que podem mudar de ambiente para ambiente (staging, integração,
  produção).
• Os valores das variáveis para a produção são usados como valores padrão, isso minimiza riscos caso o stack seja iniciado na produção sem
  uma variável de ambiente definida.
  Para iniciar o serviço em um ambiente de produção usa-se o comando
• docker stack deploy --compose-file docker-compose.yml --with-registry-auth my-stack-name O ambiente de trabalho é iniciado com o comando.
• Vamos ver um exemplo simples. docker-compose up -d.

E

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

eu posso usar

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

docker-compose (docker-compose up) , para iniciar o stack emmodo de desenvolvimento com o código-fonte montado em
Posso usar esses mesmos arquivos na produção! E eu poderia usar exatamente /project/src.

o mesmo arquivo
para staging. Para implantar isso na docker-compose.yml produção, eu só preciso construir e enviar a imagem com a 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 com 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 estágio, basta definir

as variáveis de ambiente necessárias para funcionar no ambiente de staging:
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

No final, usamos dois arquivos docker-compose diferentes, que sem

duplicação de configurações podem ser usados para qualquer um dos seus ambientes!
Saiba mais sobre o curso

Pi-KVM — projeto de IP-KVM aberto no Raspberry Pi Administrador Linux

Fonte: habr.com