1
resposta

[Sugestão] Problema ao fazer compose up

Ao fazer o "docker compose up", tanto com o zip quanto com o projeto do github recebi o erro abaixo:

Attaching to app-1, postgres-1
postgres-1 | Error: in 18+, these Docker images are configured to store database data in a
postgres-1 | format which is compatible with "pg_ctlcluster" (specifically, using
postgres-1 | major-version-specific directory names). This better reflects how
postgres-1 | PostgreSQL itself works, and how upgrades are to be performed.
postgres-1 |
postgres-1 | See also https://github.com/docker-library/postgres/pull/1259
postgres-1 |
postgres-1 | Counter to that, there appears to be PostgreSQL data in:
postgres-1 | /var/lib/postgresql/data (unused mount/volume)
postgres-1 |
postgres-1 | This is usually the result of upgrading the Docker image without
postgres-1 | upgrading the underlying database using "pg_upgrade" (which requires both
postgres-1 | versions).
postgres-1 |
postgres-1 | The suggested container configuration for 18+ is to place a single mount
postgres-1 | at /var/lib/postgresql which will then place PostgreSQL data in a
postgres-1 | subdirectory, allowing usage of "pg_upgrade --link" without mount point
postgres-1 | boundary issues.
postgres-1 |
postgres-1 | See https://github.com/docker-library/postgres/issues/37 for a (long)
postgres-1 | discussion around this process, and suggestions for how to do so.
postgres-1 exited with code 1
app-1 |
app-1 | 2026/05/29 17:32:29 /app/database/db.go:23
app-1 | [error] failed to initialize database, got error failed to connect to host=postgres user=root database=root: hostname resolving error (lookup postgres on 127.0.0.11:53: server misbehaving)
app-1 | 2026/05/29 17:32:29 Erro ao se conectar com o banco de dados
app-1 | panic: Erro ao se conectar com o banco de dados
app-1 |
app-1 | goroutine 1 [running]:
app-1 | log.Panic({0xc00013de70?, 0xc00068e000?, 0x0?})
app-1 | /usr/local/go/src/log/log.go:432 +0x5a
app-1 | github.com/guilhermeonrails/api-go-gin/database.ConectaComBancoDeDados()
app-1 | /app/database/db.go:25 +0x30c
app-1 | main.main()
app-1 | /app/main.go:9 +0xf
app-1 exited with code 2

Tive sucesso ao fazer algumas alterações no .yaml para que ele ficasse assim:

services:
postgres:
image: "postgres"
environment:
- POSTGRES_USER=root
- POSTGRES_PASSWORD=root
- POSTGRES_DB=root
ports:
- 5432:5432
volumes:
- ./postgres-data:/var/lib/postgresql # note: no '/data'
healthcheck:
test: ["CMD-SHELL", "pg_isready -U root -d root"]
interval: 5s
timeout: 5s
retries: 5

app:
build:
context: .
target: production
ports:
- 8080:8080
environment:
- DB_HOST=postgres
- DB_USER=root
- DB_PASSWORD=root
- DB_NAME=root
- DB_PORT=5432
depends_on:
postgres:
condition: service_healthy

1 resposta

Olá, Felipe. Como vai?

Excelente contribuição! Parabéns pela proatividade em investigar o erro e compartilhar a solução mapeada diretamente no seu arquivo docker-compose.yml. Esse é o tipo de tópico que poupa muito tempo de outros estudantes que estão iniciando o projeto.

O problema que você encontrou aconteceu por conta de uma mudança estrutural importante que a imagem oficial do PostgreSQL sofreu a partir de suas versões mais recentes (especificamente da versão 18 em diante).

O motivo do erro original

Antigamente, a imagem oficial do Postgres salvava as tabelas e arquivos do banco diretamente no caminho interno /var/lib/postgresql/data. O projeto inicial do curso provavelmente mapeava um volume local apontando para esse diretório.

Nas versões atuais da imagem, os mantenedores alteraram esse comportamento para facilitar o processo de atualização de versões do banco (o pg_upgrade). Agora, se você tenta montar um volume direto na pasta /data contendo dados residuais antigos, o container barra a inicialização para evitar a corrupção do seu banco.

Por que a sua solução foi perfeita?

Você foi cirúrgico em duas alterações fundamentais do seu arquivo:

  • Ajuste do Volume: Você alterou o mapeamento para - ./postgres-data:/var/lib/postgresql. Ao apontar para a pasta raiz /var/lib/postgresql (sem o /data), o Docker permite que o próprio Postgres gerencie seus subdiretórios de versão de maneira segura.
  • Inclusão do Healthcheck: A aplicação em Go (app) tentava subir e caía em panic porque o banco de dados ainda estava inicializando o sistema de arquivos no primeiro segundo e não conseguia responder ao hostname. Adicionar o healthcheck usando o comando pg_isready associado à condição condition: service_healthy garante que a aplicação Go só tentará conectar quando o Postgres estiver 100% pronto para receber conexões.

Dica extra de boas práticas: Como você utilizou a tag de imagem genérica image: "postgres", o Docker sempre vai baixar a versão mais recente disponível no Docker Hub (a latest). Para evitar que o seu ambiente de testes ou pipelines do GitHub Actions quebrem de surpresa no futuro por conta de novas atualizações da imagem, uma boa prática de QA e DevOps é travar a versão utilizando uma tag específica, como por exemplo:

services:
  postgres:
    image: "postgres:16-alpine" # Exemplo de versão travada e leve

Obrigado por registrar a solução detalhada aqui no fórum! Com certeza vai ajudar muitos alunos que passarem pelo mesmo cenário ao rodar o laboratório local.

Espero que possa ter lhe ajudado!