Docker Compose

Implante um docker-compose.yml como um único aplicativo do sh0: cada serviço vira um contêiner em uma rede privada, com volumes nomeados e um único endereço público.

Visão geral

O sh0 importa um arquivo Compose como um único aplicativo. Cada serviço vira um contêiner iniciado a partir da sua image, na ordem dada por depends_on. Os serviços não podem ser construídos: um serviço que declara build: é recusado; construa a imagem em outro lugar ou implante-o como um aplicativo separado a partir do repositório Git.

Implantar uma pilha

No painel, abra uma pilha, clique em Adicionar app, escolha Docker Compose, dê um nome ao aplicativo, cole o arquivo em docker-compose.yml e clique em Implantar. Pela CLI, sh0 compose validate verifica um arquivo e sh0 compose deploy o implanta. Exemplo com um serviço web e um cache Redis:

services:
  web:
    image: traefik/whoami:v1.10
    ports:
      - "8080:80"
    environment:
      REDIS_URL: redis://cache:6379
    depends_on:
      - cache
    deploy:
      resources:
        limits:
          memory: 64M
          cpus: "0.25"
    healthcheck:
      test: ["CMD", "true"]
  cache:
    image: redis:7-alpine
    mem_limit: 128m
    cpus: 0.5
    volumes:
      - cache-data:/data
volumes:
  cache-data:

$ sh0 compose validate docker-compose.yml
[ok] Compose file is valid
  Services: web, cache

$ sh0 compose deploy --app-name my-stack --wait docker-compose.yml
[*] Deploying compose file 'docker-compose.yml' as 'my-stack'...
[ok] Compose stack 'my-stack' deployed (app ID: 79389ae4-4a59-42a5-b8f6-37a018c95ddc, status: deploying)
[*] Waiting for deployment to complete...
[ok] Deployment completed successfully

--var CHAVE=VALOR (repetível) substitui o valor da variável de ambiente CHAVE em cada serviço que a define.

O que a validação verifica

Um arquivo é recusado se não tiver serviços, se um serviço não tiver image, declarar build:, tiver uma porta inválida ou um comando ilegível, ou montar um caminho do host (/srv/data:/data, ./data:/data): só volumes nomeados são aceitos. As chaves que o sh0 não lê não são apontadas: o exemplo acima passa na validação, embora seus blocos deploy e healthcheck sejam ignorados.

Chaves do Compose

Chaves lidas pelo sh0:

• image: obrigatória, baixada do Docker Hub ou de qualquer registro.
• ports: só a porta do contêiner é usada. O primeiro serviço, na ordem do arquivo, que declara uma porta recebe o endereço público do aplicativo pelo proxy reverso. A porta do host que você escreve não é aberta no servidor.
• environment: em forma de mapa ou de lista.
• volumes: apenas volumes nomeados. Um volume cache-data do aplicativo my-stack é criado como sh0-my-stack-cache-data e persiste entre reinícios.
• depends_on: ordem de inicialização, em forma de lista ou estendida.
• command: string ou lista.
• mem_limit e cpus: limites de memória e de CPU do serviço. São as únicas chaves de recursos que o sh0 lê.

Chaves ignoradas

deploy (incluindo deploy.resources), healthcheck, entrypoint, restart, labels e networks são aceitas e ignoradas. Todo contêiner recebe a política de reinício unless-stopped, e um serviço sem mem_limit nem cpus recebe os limites padrão. Na pilha de exemplo, o limite de 64 MB escrito em deploy.resources não foi aplicado, enquanto mem_limit: 128m foi:

$ docker inspect -f "{{.Name}} mem={{.HostConfig.Memory}} nanocpus={{.HostConfig.NanoCpus}} restart={{.HostConfig.RestartPolicy.Name}}" \
    sh0-17b83e1c-my-stack-web sh0-17b83e1c-my-stack-cache
/sh0-17b83e1c-my-stack-web mem=536870912 nanocpus=1000000000 restart=unless-stopped
/sh0-17b83e1c-my-stack-cache mem=134217728 nanocpus=500000000 restart=unless-stopped

Rede

Os serviços de uma pilha compartilham uma rede privada e se alcançam pelo nome do serviço: no exemplo, o contêiner cache recebe resposta de http://web:80. Só o serviço que tem o endereço público é acessível de fora.

Gerenciar os serviços

A pilha aparece como um único aplicativo em sh0 apps e no painel. Os serviços são listados por GET /api/v1/apps/<app-id>/services e podem ser reiniciados, parados ou iniciados um a um com POST /api/v1/apps/<app-id>/services/<service-id>/restart (ou /stop, /start).

Alterar uma pilha implantada

A versão 1.10.2 não permite aplicar uma nova versão do arquivo Compose a uma pilha existente. Implantar o arquivo de novo com o mesmo nome é recusado, e reimplantar o aplicativo falha porque ele não tem repositório:

$ sh0 compose deploy --app-name my-stack docker-compose.yml
[*] Deploying compose file 'docker-compose.yml' as 'my-stack'...
Error: An app with name 'my-stack' already exists (VALIDATION_ERROR)

$ sh0 deploy my-stack --wait
[*] Deploying my-stack...
  Deployment ID: 34f99c19-adda-4a30-a1dc-4e670a3ff505
  Status:        queued
[*] Waiting for deployment to complete...
error: Deployment failed.

# Build log of that deployment:
[STEP 1/6] Cloning repository
[ERROR] App has no repository URL configured

Essas falhas não afetam os serviços em execução. Para alterar a pilha, implante o novo arquivo com outro nome, mova o tráfego e os dados e depois apague o aplicativo antigo; sh0 delete remove um aplicativo e seus recursos.