DEV Community: Marcelo Lino

More Power in Your Docker Compose

Marcelo Lino — Fri, 17 Jul 2026 10:27:43 +0000

It is safe to assume that Docker shows up at some point in every developer's life. We often reach for compose.yaml files to run our applications and their dependencies locally, and sometimes even in production.

Real projects tend to need more than "start these containers". You may need to run a database migration before the app boots, guarantee the database is actually ready to accept connections, spin up only a subset of your dependencies, and so on. In many teams I have seen these requirements solved with shell scripts that not everyone is comfortable with, which creates friction and a fear of touching them. With that in mind, I want to shine a light on a few Docker Compose features that are frequently overlooked, and put them together following current best practices.

Before the good parts, a quick note on the conventions used throughout this article.

Conventions used here

Files are named compose.yaml and invoked with the docker compose plugin.
There is no top-level version key. Compose validates against the latest Compose Specification automatically, so it is not needed.
The dependency conditions shown below require Compose v2.20 or newer.

With that out of the way, let's get into the good parts.

Healthcheck

The Compose Specification lets you define a healthcheck to verify that a service is not just running, but actually operational. This matters when you want a service to start only after another one is fully up and able to do its job.

services:
  db:
    image: postgres:18-alpine
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s

volumes:
  db_data:

A few things worth pointing out about this setup:

Pin your image tags. postgres:alpine floats and can change under you. Prefer an explicit major version like postgres:18-alpine so builds stay reproducible.
start_period is your friend. During this grace period, failing checks do not count against the retry limit. A successful check ends the grace period early. Databases can take a while to initialize, so give them room (30s or more).
start_interval (Docker Engine 25.0+) lets you probe more frequently during the start period without hammering the container for its whole life. It is a nice touch for services with long, variable startup times.
The double $$ escapes the variable so it is expanded inside the container, by the shell, and not by Compose at parse time.

depends_on with conditions

Defining the healthcheck is only half the story. The other half is telling dependent services to wait for it. This is where depends_on with a condition comes in.

Compose supports three conditions:

service_started (the default): waits only until the container is running.
service_healthy: waits until the dependency's healthcheck passes.
service_completed_successfully: waits until the dependency runs to completion and exits with code 0.

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8000:8000"
    command: "gunicorn -b 0.0.0.0:8000 -k gevent sample.main:create_app() --access-logfile=- --preload -w 4"
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      test: ["CMD-SHELL", "python -c \"import urllib.request,sys; sys.exit(0 if urllib.request.urlopen('http://localhost:8000/healthcheck').status==200 else 1)\""]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s

  db:
    image: postgres:18-alpine
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s

volumes:
  db_data:

Two pitfalls that are very easy to hit here:

The condition is service_healthy, not service_health. That single missing letter is a classic silent failure.
A common mistake is using curl for the app healthcheck. Many slim base images do not ship curl, so the check fails not because the app is down but because the binary is missing. Above I use a small Python one-liner instead, which is always available in a Python image. If your image does have curl, ["CMD", "curl", "-f", "http://localhost:8000/healthcheck"] is fine too. The point is: use a tool that actually exists in the container.

The migration pattern

service_completed_successfully is the piece that lets you retire most of those startup shell scripts. A common need is "run the database migration, and only then start the app". You can model that directly:

services:
  migrate:
    build:
      context: .
      dockerfile: Dockerfile
    command: "alembic upgrade head"   # or: python manage.py migrate
    depends_on:
      db:
        condition: service_healthy

  app:
    build:
      context: .
      dockerfile: Dockerfile
    command: "gunicorn -b 0.0.0.0:8000 sample.main:create_app() -w 4"
    depends_on:
      migrate:
        condition: service_completed_successfully
      db:
        condition: service_healthy

The migrate service waits for the database to be healthy, runs once, and exits. The app service waits for that exit to be successful before it even starts. No bespoke wait-for-it.sh needed.

Profiles

Sometimes you open a compose.yaml with a dozen service definitions, but the feature you are working on only needs a handful of them. That is what profiles are for.

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8000:8000"
    command: "gunicorn -b 0.0.0.0:8000 sample.main:create_app() -w 4"
    profiles:
      - web
      - full
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      test: ["CMD-SHELL", "python -c \"import urllib.request; urllib.request.urlopen('http://localhost:8000/healthcheck')\""]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s

  db:
    image: postgres:18-alpine
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres
    profiles:
      - dependencies
      - web
      - full
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  db_data:

Note the indentation: profiles is a top-level key of the service, at the same level as depends_on and healthcheck. A frequent mistake is nesting it inside depends_on, which is invalid.

To start only the database, you can either use the flag:

docker compose --profile dependencies up

or the environment variable, which is handy in scripts:

COMPOSE_PROFILES=dependencies docker compose up

You can pass multiple profiles too: docker compose --profile web --profile full up.

Reusing definitions

The same codebase is often run in different shapes: a web app, an async worker, a one-off command. It is convenient to define a common base and specialize it per use case. Compose gives you two ways to do this.

YAML anchors

The YAML spec supports anchors and aliases for reusing definitions. Combined with Compose's convention that any top-level key starting with x- is treated as an extension field (and ignored by the parser), you can build a shared base and merge it into each service:

x-app: &app
  build:
    context: .
    dockerfile: Dockerfile
  depends_on:
    db:
      condition: service_healthy
    queue:
      condition: service_healthy
    cache:
      condition: service_healthy

services:
  app:
    <<: *app
    ports:
      - "8000:8000"
    command: "gunicorn -b 0.0.0.0:8000 sample.main:create_app() -w 4"
    profiles:
      - web
      - full
    healthcheck:
      test: ["CMD-SHELL", "python -c \"import urllib.request; urllib.request.urlopen('http://localhost:8000/healthcheck')\""]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s

  worker:
    <<: *app
    command: "celery -A sample.main:celery_app worker"
    environment:
      CELERY_RESULT_BACKEND: redis://cache:6379/0
      CELERY_BROKER_URL: amqp://guest:guest@queue:5672//
    profiles:
      - background
      - full

  db:
    image: postgres:18-alpine
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres
    profiles:
      - dependencies
      - full
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5

  queue:
    image: rabbitmq:4-management-alpine
    profiles:
      - dependencies
      - full
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"]
      interval: 30s
      timeout: 30s
      retries: 3

  cache:
    image: redis:8-alpine
    profiles:
      - dependencies
      - full
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 30s
      timeout: 30s
      retries: 3

volumes:
  db_data:

The `extends` keyword

Anchors are pure YAML and only work within a single file. If you want to share definitions across files, Compose has its own extends keyword:

# common.yaml
services:
  base:
    build:
      context: .
    env_file:
      - .env

# compose.yaml
services:
  app:
    extends:
      file: common.yaml
      service: base
    command: "gunicorn -b 0.0.0.0:8000 sample.main:create_app() -w 4"

Use anchors for local reuse, extends for reuse across files.

What else you can add

The features so far cover startup order, readiness, and reuse. Here is what I would add on top to make a Compose setup genuinely production-minded.

Compose Watch: hot reload

The develop.watch block keeps your running containers in sync with local changes, syncing files or rebuilding the image automatically as you edit.

services:
  app:
    build:
      context: .
    command: "uvicorn sample.main:app --host 0.0.0.0 --port 8000 --reload"
    ports:
      - "8000:8000"
    develop:
      watch:
        # Sync source changes straight into the running container
        - action: sync
          path: ./sample
          target: /app/sample
          initial_sync: true
          ignore:
            - __pycache__/
        # Rebuild the image when dependencies change
        - action: rebuild
          path: ./pyproject.toml

Start it with docker compose up --watch (or docker compose watch to keep sync events out of your app logs). The sync action copies changed files into the container without a rebuild, rebuild recreates the image, and sync+restart syncs then restarts the process. The initial_sync: true flag copies everything on startup so the container never runs stale code, and there is really no reason not to use it.

A couple of requirements: the watched container's user must be able to write to the target path, and sync needs common executables present in the image.

Restart policies

Tell Compose what to do when a container exits. For long-running services, unless-stopped is a sensible default: it restarts on failure and on daemon restart, but respects a manual stop.

services:
  app:
    restart: unless-stopped

Options are no (default), always, on-failure, and unless-stopped. Do not put this on your one-off migrate service, or it will loop.

Resource limits

Without limits, a single misbehaving container can starve everything else on the host. Compose honors deploy.resources for docker compose up, no Swarm required:

services:
  app:
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M

limits is the ceiling, reservations is the guaranteed minimum.

Security hardening

Containers run as root by default, which is more privilege than most apps need. A hardened service looks like this:

services:
  app:
    image: myapp:1.4.2          # pinned, never :latest in production
    user: "1000:1000"           # non-root
    read_only: true             # immutable root filesystem
    tmpfs:
      - /tmp                     # writable scratch space that is not persisted
    cap_drop:
      - ALL                      # drop every Linux capability
    cap_add:
      - NET_BIND_SERVICE         # add back only what you actually need
    security_opt:
      - no-new-privileges:true   # block privilege escalation via setuid
    ports:
      - "127.0.0.1:8000:8000"    # bind to localhost, not 0.0.0.0

The principle is least privilege: drop all capabilities and add back only the ones your app needs, keep the filesystem read-only with a small tmpfs for scratch files, forbid privilege escalation, and bind ports to 127.0.0.1 when the port does not need to be exposed to the world. And never use privileged: true as a shortcut. It disables essentially every one of these protections at once.

Secrets instead of plaintext env vars

Passing a database password through environment leaves it visible in docker inspect, in your shell history, and often committed to git. Compose secrets mount the value as a file instead:

services:
  db:
    image: postgres:18-alpine
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt

Postgres (and many other official images) support the _FILE convention specifically for this. Add secrets/ to your .gitignore.

Env files and interpolation with defaults

Keep configuration out of the file and provide sane fallbacks with the ${VAR:-default} syntax:

services:
  app:
    image: myapp:${APP_TAG:-latest}
    env_file:
      - .env
    environment:
      LOG_LEVEL: ${LOG_LEVEL:-info}

Compose reads a .env file next to compose.yaml automatically for interpolation. Do not commit it.

Network isolation

By default all services share one network and can talk to each other freely. If your database never needs to be reached from outside, put it on an internal network so it has no route to the host or the internet:

services:
  app:
    networks:
      - frontend
      - backend
  db:
    networks:
      - backend        # only reachable by services on backend

networks:
  frontend:
  backend:
    internal: true     # no external connectivity

This limits lateral movement if one container is ever compromised.

The `include` directive (with a security note)

Large setups can be split into fragments and pulled together with include:

include:
  - path: ./services/database.yaml
  - path: ./services/observability.yaml

It can even pull fragments from Git or OCI registries. One caveat worth knowing: CVE-2025-62725 was a path traversal vulnerability in include when using OCI artifacts. If you use that feature, make sure you are on Compose v2.40.2 or newer.

`pull_policy`

Control when Compose pulls an image versus using the local one. Useful in CI, or when you build locally and do not want Compose reaching for a registry:

services:
  app:
    build: .
    pull_policy: build   # or: always, missing, never

Putting it together

Here is a compact setup that combines these ideas: a FastAPI app, a Celery worker, and their dependencies, with a migration step, profiles, healthchecks, secrets, and watch mode for development.

x-app: &app
  build:
    context: .
    dockerfile: Dockerfile
  env_file:
    - .env
  depends_on:
    db:
      condition: service_healthy
    cache:
      condition: service_healthy
  restart: unless-stopped

services:
  migrate:
    <<: *app
    restart: "no"
    command: "alembic upgrade head"
    depends_on:
      db:
        condition: service_healthy
    profiles: [web, full]

  app:
    <<: *app
    command: "uvicorn sample.main:app --host 0.0.0.0 --port 8000"
    ports:
      - "127.0.0.1:8000:8000"
    depends_on:
      migrate:
        condition: service_completed_successfully
      db:
        condition: service_healthy
      cache:
        condition: service_healthy
    healthcheck:
      test: ["CMD-SHELL", "python -c \"import urllib.request; urllib.request.urlopen('http://localhost:8000/healthcheck')\""]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: 512M
    profiles: [web, full]
    develop:
      watch:
        - action: sync
          path: ./sample
          target: /app/sample
          initial_sync: true
          ignore: [__pycache__/]
        - action: rebuild
          path: ./pyproject.toml

  worker:
    <<: *app
    command: "celery -A sample.main:celery_app worker"
    environment:
      CELERY_RESULT_BACKEND: redis://cache:6379/0
      CELERY_BROKER_URL: amqp://guest:guest@queue:5672//
    depends_on:
      queue:
        condition: service_healthy
      cache:
        condition: service_healthy
    profiles: [background, full]

  db:
    image: postgres:18-alpine
    environment:
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - backend
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s
    profiles: [dependencies, web, background, full]

  cache:
    image: redis:8-alpine
    networks:
      - backend
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 30s
      timeout: 10s
      retries: 3
    profiles: [dependencies, web, background, full]

  queue:
    image: rabbitmq:4-management-alpine
    networks:
      - backend
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"]
      interval: 30s
      timeout: 30s
      retries: 3
    profiles: [dependencies, background, full]

volumes:
  db_data:

networks:
  backend:
    internal: true

secrets:
  db_password:
    file: ./secrets/db_password.txt

Bring up just the dependencies while you work on something else:

docker compose --profile dependencies up

Run the full stack with live reload:

docker compose --profile full up --watch

Wrapping up

Compose can express startup order, readiness, per-service reuse, hot reload, resource limits, and a solid security baseline, all declaratively, without a pile of shell scripts that scare half the team. Lean on these features and your setup gets more dynamic, more reproducible, and safer.

Argumentos Opcionais Mutáveis em Python

Marcelo Lino — Mon, 27 Feb 2023 18:30:18 +0000

Argumentos deveriam ser coisas simples, não é mesmo? Você passa um valor para a função e ela faz o que você espera. Mas o que acontece quando a sua função não te obriga a passar um valor e trabalha com um valor padrão?

Uma função de soma que recebe dois valores e retorna a soma deles, porém caso nenhum valor seja inserido os argumentos assumem o valor 10 para cada um, retornando assim 20.

def soma(a=10, b=10):
    return a + b

Nesse exemplo os valores padrões são imutáveis, então a cada operação não há modificação no seu conteúdo.

Agora o que acontece se modificamos o valor padrão para uma lista ou um dicionário?

Problema

from random import randint

def mutable_arguments(a_list=[], a_dict={}):
    a_list.append(randint(0, 100))
    a_dict[randint(0, 100)] = randint(0, 100)

    print(f"A lista agora contém os seguintes items: {a_list}")
    print(f"O dicionário agora contém os seguintes items: {a_dict}", end="\n\n")

mutable_arguments()
mutable_arguments()
mutable_arguments()

Essa execução gera a seguinte saída:

The local list a_list now contains: [43]
The local dict a_dict now contains: {50: 61}

The local list a_list now contains: [43, 74]
The local dict a_dict now contains: {50: 61, 128: 69}

The local list a_list now contains: [43, 74, 42]
The local dict a_dict now contains: {50: 61, 128: 69, 86: 79}

Note que a cada execução a lista e o dicionário são modificados, isso acontece porque o interpretador do Python aloca cada função ou método na inicialização do programa, caso essa assinatura contenha inicializadores de objetos eles então serão instanciados e alocados em memória durante a inicialização.

Sendo assim, quando você executa seu código e altera esses mesmos valores, está alterando objetos já alocados e não criando novos a cada execução. O que pode ao final do programa gerar resultados inesperados.

Solução

Existem duas formas de resolver esse problema, a primeira é passar None como valor padrão e então verificar se o valor é None e então atribuir o valor padrão.

from random import randint

def immutable_arguments(a_list=None, a_dict=None):
    if a_list is None:
        a_list = []
    if a_dict is None:
        a_dict = {}

    a_list.append(randint(0, 100))
    a_dict[randint(0, 100)] = randint(0, 100)

    print(f"A lista agora contém os seguintes items: {a_list}")
    print(f"O dicionário agora contém os seguintes items: {a_dict}", end="\n\n")

immutable_arguments()
immutable_arguments()
immutable_arguments()

Outra abordagem é reatribuir o valor padrão ou então um objeto mutável vazio.

from random import randint

def immutable_arguments(a_list=None, a_dict=None):
    a_list = a_list or []
    a_dict = a_dict or {}

    a_list.append(randint(0, 100))
    a_dict[randint(0, 100)] = randint(0, 100)

    print(f"A lista agora contém os seguintes items: {a_list}")
    print(f"O dicionário agora contém os seguintes items: {a_dict}", end="\n\n")

immutable_arguments()
immutable_arguments()
immutable_arguments()

Em ambos os casos a saída será a seguinte:

A lista agora contém os seguintes items: [44]
O dicionário agora contém os seguintes items: {7: 37}

A lista agora contém os seguintes items: [39]
O dicionário agora contém os seguintes items: {28: 50}

A lista agora contém os seguintes items: [40]
O dicionário agora contém os seguintes items: {40: 99}

Perceba que agora a cada execução os valores são reatribuídos e não mais modificados.

Migrações no Django sem Downtime

Marcelo Lino — Wed, 04 Jan 2023 15:16:01 +0000

Uma das coisas mais ferramentas mais poderosas do framework Django é o seu ORM e o gerenciamento de migrações. Porém quando enfrentamos um ambiente produtivo, por diversas vezes temos que executar migrações que adicionam, removem ou alteram colunas, o que causa uma indisponibilidade no sistema, até que o novo código que comporte essa nova estrutura do modelo esteja disponível para atender as requisições.

O fluxo de implantação de um novo código de aplicação Django geralmente consiste em:

O problema acontece pois entre a Execução da Migração e a Execução do Novo Código o Código Atual ainda estará em execução até que o novo possa assumir, fazendo com que o Django dispare um IntegrityError deixando todas as suas gravações de dados indisponíveis nesse período de tempo.

Pra solucionar esse problema temos alguns procedimentos que podemos seguir.

Adicionando Campos ou Tabelas

Adicionar um campo `NULL` ou nova tabela

Crie o modelo ou a coluna no seu código;
Gere as respectivas migrações com python manage.py makemigrations;
Faça duas Pull Requests, uma contendo a alteração do modelo e outra com a respectiva migração;
Faça o Merge e a implantação da Pull Request com a migração;
Execute a migração no seu banco de dados de produção. Adição de campos não deve causar problemas se o modelo em produção não esperar que esses campos estejam lá;
Faça o Merge da Pull Request com a mudança no modelo;
Implante o código com a mudança do modelo. A partir de agora o código vai começar a ler e escrever na nova coluna.

Adicionando um campo `NOT NULL`

Para iniciar a adição de um campo NÂO NULO, primeiro siga os passos acima adicionando ele como NULO inicialmente

Altere a coluna no modelo para null=False. Certifique-se que no seu código você não está inserindo ou atualizando esse campo com valores nulos;
Gere as respectivas migrações com python manage.py makemigrations;
Faça duas Pull Requests, uma contendo a alteração do modelo e outra com a respectiva migração;
Faça o Merge da Pull Request com a mudança no modelo;
Implante o código com a mudança do modelo. A partir de agora o código vai começar a gravar na nova coluna.
Faça o Merge e a implantação da Pull Request com a migração;
Execute a migração no seu banco de dados de produção.

Adicionando `NOT NULL` em tabelas com muitos dados

As migrações do Django insistem que se exista um valor default para colunas com a constraint NOT NULL. Esse valor será usado para popular as colunas vazias durante a migração. Esse processo de atualização efetuará um LOCK na tabela para escrita até que a atualização esteja concluída. Para tabelas pequenas com menos de 100.000 linhas, provavelmente não haverá problemas, porém para colunas com mais dados isso pode causar uma indisponibilidade do sistema até que a tabela esteja novamente disponível.

Afim de evitar esse comportamento, podemos executar Migrações Não Atômicas, simplesmente adicionando o atributo atomic = False a sua migração, como no exemplo a seguir.

from django.db import migrations

class Migration(migrations.Migration):
    atomic = False

Removendo Campos ou Tabelas

Removendo um campo `NULL` ou uma Tabela

Basicamente é o mesmo procedimento de adição, porém com os passo em uma ordem um pouco diferente.

Remova todas as utilizações do modelo ou coluna a serem removidas da sua aplicação;
Faça a implantação de uma versão que ainda tenha a definição da coluna ou modelo a ser removida, porém que não tenha mais a sua utilização;
Faça a remoção da coluna ou modelo do seu código;
Gere a migração para a remoção com python manage.py makemigrations;
Faça o Merge da mudança do modelo;
Implante o código da mudança do modelo. Certifique-se que não está ocorrendo nenhum erro por ainda existir alguma referência ao código que não mais existe;
Faça o Merge da migração;
Implante o código da migração;
Execute a migração no seu banco de dados.

Removendo um campo `NOT NULL`

Para remover um campo não nulo, primeiramente você tem que transformá-lo em um campo nulo, então seguir os passos a cima para remover um campo não nulo. Os passos para transformar o campo não nulo em nulo são:

Alterar o seu campo para null=True;
Criar as migrações para esse mudança;
Criar duas Pull Requests separadas, uma para a mudança no modelo e outra para migração;
Fazer o Merge e implantar o Pull Request com a migração;
Execute a migração no banco de dados;
Faça o Merge e a implantação da mudança do modelo;
Execute os passos para remover um campo nulo

Mais poder no seu Docker Compose

Marcelo Lino — Mon, 26 Sep 2022 14:45:47 +0000

Já podemos dar como certo que o docker está em um momento ou outro na vida de um programador, e muitas vezes nos utilizamos de arquivos docker-compose.yaml para executarmos localmente nossas aplicações e suas dependências e algumas vezes até em produção.

Por vezes temos que executar coisas mais complexas como executar uma migração de banco de dados antes da nossa aplicação executar, garantir que o banco de dados já esteja pronto para receber conexões, executar um subconjunto de dependências e assim por diante. Em muitas das minhas experiências vi esses requisitos serem executados através de scripts shell que nem sempre são familiares a todos os membros da equipe o que sempre gera uma estranheza e medo de extender tais funcionalidades, pensando nisso resolvi deixar mais evidentes algumas funcionalidades do Docker Compose que por muitas vezes são ignoradas.

Healthcheck

A especificação do Docker Compose conta com uma forma de healthcheck que podemos utilizar para garantir que nossa aplicação não só está rodando, mas como ela está operacional, essa checagem é útil quando queremos garantir que um serviço de ser executado somente após outro serviço estar totalmente operacional.

version: '3'

services:
  db:
    container_name: db
    image: postgres:alpine
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_DB=postgres
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

Definindo o banco de dados com esse healthcheck quando adicionarmos a definição da nossa aplicação podemos dizer que ao depender do banco ela só inicie após o serviço dependente estar de pé e saudável.

version: '3'

services:
  app:
    container_name: app
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/app
    ports:
      - "8000:8000"
    command: "gunicorn -b 0.0.0.0:8000 -k gevent sample.main:create_app() --access-logfile=- --preload -w 4"
    depends_on:
      db:
        condition: service_health
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/healthcheck"]
      interval: 5s
      timeout: 30s
      retries: 5

  db:
    container_name: db
    image: postgres:alpine
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_DB=postgres
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

Profiles

As vezes nos deparamos com arquivos docker-compose.yaml extensos e com várias definições de serviço, porém ao desenvolver alguma funcionalidade necessitamos somente de um subconjunto desses serviços afim de testarmos nosso código, para isso temos os profiles

version: '3'

services:
  app:
    container_name: app
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/app
    ports:
      - "8000:8000"
    command: "gunicorn -b 0.0.0.0:8000 -k gevent sample.main:create_app() --access-logfile=- --preload -w 4"
    depends_on:
      db:
        condition: service_healthy
      profiles:
      - web
      - full
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/healthcheck"]
      interval: 5s
      timeout: 30s
      retries: 5

  db:
    container_name: db
    image: postgres:alpine
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_DB=postgres
    profiles:
      - dependencies
      - web
      - full
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

Com essa definição podemos utilizar o comando docker-compose --profile dependencies up para iniciar somente a nossa base de dados.

Extensão

A mesma base de código muitas vezes pode ser utilizada para executar serviços em diferentes contextos, uma aplicação web, um serviço assíncrono de tarefas, uma execução única de linha de comando. Sendo assim é interessante para nós desenvolvedores definirmos uma base comum e somente personalizarmos para cada caso de uso.

Para atingir tal objetivo no Docker Compose temos a opção de usar um feature da própria

Ancora YAML

A especificação do YAML permite que criemos ancoras para reaproveitamento de definições, assim podemos criar uma base comum para um serviço para depois especializarmos.

version: '3'

x-app: &app
  build:
      context: .
      dockerfile: Dockerfile
  depends_on:
    db:
      condition: service_healthy
    queue:
      condition: service_healthy

services:
  app:
    <<: *app
    container_name: app
    volumes:
      - .:/app
    ports:
      - "8000:8000"
    command: "gunicorn -b 0.0.0.0:8000 -k gevent sample.main:create_app() --access-logfile=- --preload -w 4"
    profiles:
      - web
      - full
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/healthcheck"]
      interval: 5s
      timeout: 30s
      retries: 5

  background:
    <<: *app
    container_name: background
    command: "celery -A sample.main:celery_app worker"
    environment:
      - CELERY_RESULT_BACKEND=redis://cache:6379/0
      - CELERY_BROKER_URL=amqp://guest:guest@queue:5672//
    profiles:
      - background
      - full

  db:
    container_name: db
    image: postgres:alpine
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_DB=postgres
    profiles:
      - dependencies
      - full
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

  queue:
    container_name: queue
    image: rabbitmq:3-management-alpine
    profiles:
      - dependencies
      - full
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"]
      interval: 30s
      timeout: 30s
      retries: 3

  cache:
    container_name: cache
    image: redis:alpine
    profiles:
      - dependencies
      - full
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 30s
      timeout: 30s
      retries: 3

volumes:
  db_data:

Essas são algumas formas de deixar seu Docker Compose um pouco mais dinâmico e inteligente.

Fonte

DEV Community: Marcelo Lino

More Power in Your Docker Compose

Conventions used here

Healthcheck

depends_on with conditions

The migration pattern

Profiles

Reusing definitions

YAML anchors

The extends keyword

What else you can add

Compose Watch: hot reload

Restart policies

Resource limits

Security hardening

Secrets instead of plaintext env vars

Env files and interpolation with defaults

Network isolation

The include directive (with a security note)

pull_policy

Putting it together

Wrapping up

Argumentos Opcionais Mutáveis em Python

Problema

Solução

Migrações no Django sem Downtime

Adicionando Campos ou Tabelas

Adicionar um campo NULL ou nova tabela

Adicionando um campo NOT NULL

Adicionando NOT NULL em tabelas com muitos dados

Removendo Campos ou Tabelas

Removendo um campo NULL ou uma Tabela

Removendo um campo NOT NULL

Mais poder no seu Docker Compose

Healthcheck

Profiles

Extensão

Ancora YAML

The `extends` keyword

The `include` directive (with a security note)

`pull_policy`

Adicionar um campo `NULL` ou nova tabela

Adicionando um campo `NOT NULL`

Adicionando `NOT NULL` em tabelas com muitos dados

Removendo um campo `NULL` ou uma Tabela

Removendo um campo `NOT NULL`