Docker Compose: uma aplicação com a sua base de dados

O Docker Compose descreve num único ficheiro uma aplicação inteira: o programa, a base de dados, as redes entre eles e os volumes onde os dados ficam. Um comando, docker compose up -d, levanta tudo. Fica aqui um exemplo com a aplicação e o PostgreSQL, num VPS com o Docker já instalado (veja como). A mesma estrutura serve para MariaDB ou MySQL: muda a imagem e as variáveis.

Montar o projecto

1 Crie uma pasta só para o projecto e entre nela: mkdir meu-projecto && cd meu-projecto. O nome da pasta torna-se o nome do projecto no Compose.
2 Crie o ficheiro .env com as palavras-passe, e proteja-o: DB_PASSWORD=ponha-aqui-uma-palavra-passe-longa-e-aleatoriachmod 600 .env. Se usar Git, ponha o .env no .gitignore. Nunca o publique.
3 Crie o ficheiro compose.yaml (o nome docker-compose.yml também funciona):services:
  app:
    build: .
    restart: unless-stopped
    env_file: .env
    environment:
      DB_HOST: db
    ports:
      - "127.0.0.1:3000:3000"
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: appdb
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
      interval: 10s
      timeout: 5s
      retries: 5
volumes:
  db_data:
4 Levante tudo e veja o estado: docker compose up -d
docker compose ps
docker compose logs -f app
O Compose cria uma rede privada para o projecto.

O que cada parte faz

Parte O que faz Porquê assim
DB_HOST: db A aplicação encontra a base de dados pelo nome do serviço. Dentro da rede do Compose não se usa localhost nem o IP: cada serviço é um computador à parte.
127.0.0.1:3000:3000 Publica a porta da aplicação só no próprio servidor. Quem a mostra ao mundo é um proxy com HTTPS: veja nginx como proxy inverso.
Nenhuma porta no db A base de dados não é alcançável de fora. É o desejado. Os outros serviços chegam-lhe pela rede interna.
db_data (volume) Onde ficam os dados da base de dados. Sem volume, apagar o contentor apaga os dados.
healthcheck e service_healthy A aplicação só arranca quando a base de dados já aceita ligações. depends_on sozinho só espera que o contentor exista, não que esteja pronto.

O endereço de ligação, dentro da aplicação, fica assim: postgres://appuser:PALAVRA-PASSE@db:5432/appdb. Se a palavra-passe tiver caracteres especiais (@, :, /), têm de ir codificados no endereço, ou escolha uma sem eles.

As variáveis POSTGRES_* só valem na primeira vez. Servem para criar a base de dados quando o volume está vazio. Se mudar a palavra-passe no ficheiro depois de a base existir, a base de dados não muda, e a aplicação deixa de entrar. Muda-se com um comando dentro da base de dados. E o docker compose down -v apaga os volumes, ou seja, os dados: sem o -v, um down só remove os contentores.
Escolha uma versão da imagem da base de dados e fixe-a (postgres:16 em vez de postgres:latest). Passar de uma versão principal para a seguinte não se faz mudando só o número: exige uma cópia e uma restauração. Veja cópias com mysqldump e pg_dump, e como actualizar sem perder nada em actualizar uma aplicação Docker. A escolha entre motores está em PostgreSQL ou MySQL.

O VPS tem de ser seu, com root. Se ainda não tem, veja os planos: o Docker e a aplicação ficam à sua conta, e a rede e o servidor à nossa.

Ver os servidores VPS

VEJA TAMBÉM

Nginx como proxy inverso à frente de um contentor

Actualizar uma aplicação Docker sem perder dados

Cópias com mysqldump e pg_dump, e restaurar a cópia

PRODUTO RECOMENDADO

Alojamento de sites com cPanel

Domínio e SSL incluídos, cópias diárias e o painel que já conhece. desde 321,75 MT/mês (plano de 3 anos, com cupão)

Ver planos
  • 0 Utilizadores acharam útil
Esta resposta foi útil?