sapl/docs/CONFIGURACAO_BD_REMOTO.md

Configuração do SGVP com Banco de Dados Remoto

Este documento explica como configurar o SGVP para usar um banco de dados PostgreSQL remoto.

Atualizado em 13/08/2026. Duas correções: o host sgvp.com.br:5432 não responde mais — o banco remoto ativo é demo.legisinc.com.br:5432 (base demo) — e as credenciais que estavam em claro neste documento foram rejeitadas pelo servidor. Peça as credenciais atuais ao responsável pelo ambiente e mantenha-as fora do repositório (sapl/.env, que é gitignored, ou variáveis de ambiente do host). Para subir só o Django em desenvolvimento, sem o compose completo, veja LOCALHOST_SETUP.md.

Leia antes a seção O que o usuário remoto precisa poder fazer: o start.sh executa DDL na inicialização, e um usuário só de leitura/escrita de dados — como o disponível hoje no demo — derruba o container no boot. Nesse caso o caminho é a cópia local do banco, descrita na seção 4 do LOCALHOST_SETUP.md.

Problemas Corrigidos

1. Erro 404 ao acessar http://localhost:8000/

Causa: O gunicorn não estava iniciando por dois motivos:

• Permissões incorretas no arquivo de migration do TCE
• Configuração duplicada do socket Unix no gunicorn

Soluções aplicadas:

a) Correção do arquivo gunicorn.conf.py

Arquivo: docker/startup_scripts/gunicorn.conf.py

Antes:

SOCKFILE = f"unix:{DJANGODIR}/run/gunicorn.sock"
bind = f"unix:{SOCKFILE}"  # Resulta em: unix:unix:/var/interlegis/sapl/run/gunicorn.sock

Depois:

SOCKFILE = f"{DJANGODIR}/run/gunicorn.sock"
bind = f"unix:{SOCKFILE}"  # Correto: unix:/var/interlegis/sapl/run/gunicorn.sock

b) Correção de permissões de migrations

Caso encontre erro de permissão em arquivos de migration, execute:

docker exec sapl chmod 644 /var/interlegis/sapl/sapl/*/migrations/*.py

Configuração do Banco de Dados Remoto

Passo 1: Editar o docker-compose.yaml

Arquivo: docker/docker-compose.yaml

Adicione a variável DATABASE_URL nas variáveis de ambiente do serviço sapl:

  sapl:
    build:
      context: ../
      dockerfile: ./docker/Dockerfile
    container_name: sapl
    restart: always
    environment:
      ADMIN_PASSWORD: interlegis
      ADMIN_EMAIL: email@dominio.net
      DEBUG: 'False'
      DATABASE_URL: postgresql://<usuario>:<senha-url-encoded>@demo.legisinc.com.br:5432/demo
      # ... outras variáveis

Prefira injetar a DATABASE_URL por variável de ambiente do host (ou por um .env gitignored) em vez de escrevê-la no docker-compose.yaml, que é versionado.

IMPORTANTE: Se a senha contiver caracteres especiais como @, eles devem ser codificados:

• @ → %40
• : → %3A
• / → %2F

Exemplo: S3nh@2026 vira S3nh%402026

Passo 2: Remover dependência do banco local

No mesmo arquivo, remova sapldb das dependências:

Antes:

    depends_on:
      - sapldb
      - saplsolr
      - onlyoffice

Depois:

    depends_on:
      - saplsolr
      - onlyoffice

Passo 3: Testar a conexão com o banco remoto

Antes de iniciar o SGVP, teste a conexão:

docker run --rm postgres:17-alpine psql \
  "postgresql://<usuario>:<senha-url-encoded>@demo.legisinc.com.br:5432/demo" \
  -c "\dt"

Se listar as tabelas, a conexão está funcionando — mas conectar não basta: veja a seção seguinte antes de subir o compose.

O que o usuário remoto precisa poder fazer

Conexão bem-sucedida não garante boot. O docker/startup_scripts/start.sh roda, nesta ordem, duas etapas que exigem privilégio além de ler e gravar dados:

Etapa no start.sh	Comando	Privilégio exigido	Se falhar
configure_pg_timezone	ALTER DATABASE … SET timezone e ALTER ROLE … SET timezone	dono do banco / superusuário	exit 1 — o container morre no boot
migrate_db	manage.py migrate --noinput	CREATE no schema public (quando há migration pendente)	erro e boot interrompido

O configure_pg_timezone só é pulado se o banco já responder UTC em show time zone (linhas 45-49 do start.sh). O demo responde America/Sao_Paulo, então a etapa não é pulada e o ALTER DATABASE é tentado de verdade.

Verifique os três pontos antes de subir:

DB="postgresql://<usuario>:<senha-url-encoded>@demo.legisinc.com.br:5432/demo"
docker run --rm -e PGURL="$DB" postgres:17-alpine sh -c 'psql "$PGURL" \
  -Atc "show time zone;" \
  -c "select has_schema_privilege(current_user, '"'"'public'"'"', '"'"'CREATE'"'"');" \
  -c "select pg_get_userbyid(datdba) as dono_do_banco, current_user as voce
      from pg_database where datname = current_database();"'

Situação verificada em 13/08/2026 com o usuário kasepulvida no demo: timezone America/Sao_Paulo, CREATE no schema = f, dono do banco = postgres (não é o usuário). Ou seja, este documento não sobe hoje com essas credenciais — o boot para no ALTER DATABASE. As saídas:

ALTER DATABASE "demo" failed. Need DB owner or superuser.
django.db.utils.ProgrammingError: permission denied for schema public

Três caminhos, em ordem de preferência:

1. Cópia local do banco — você vira dono e nada disso trava. Procedimento na seção 4 do LOCALHOST_SETUP.md.
2. Pedir os privilégios ao dono do banco (GRANT CREATE ON SCHEMA public e as ALTERs de timezone aplicadas por ele) — só faz sentido se o banco remoto for mesmo o alvo; lembre que ele é compartilhado.
3. Rodar só o Django, sem o compose — o runserver não executa o start.sh, então nenhuma das duas etapas acontece. Serve quando não há migration pendente e você só precisa ler/gravar dados. Ver LOCALHOST_SETUP.md.

Passo 4: Reconstruir a imagem Docker

cd ~/dev/sapl/docker
docker-compose build sapl

Passo 5: Iniciar os containers

docker-compose up -d

Passo 6: Verificar os logs

docker logs sapl -f

Aguarde até ver:

[YYYY-MM-DDThh:mm:ss-03:00] Starting gunicorn...
[YYYY-MM-DDThh:mm:ss-03:00] Starting nginx...

Passo 7: Testar o acesso

curl -I http://localhost:8000/

Deve retornar: HTTP/1.1 200 OK

Acessando o Sistema

URL

http://localhost:8000/

Usuários disponíveis

O sistema cria automaticamente dois usuários locais:

• Usuário: interlegis | Senha: interlegis (ou valor de ADMIN_PASSWORD)
• Usuário: admin | Senha: interlegis (ou valor de ADMIN_PASSWORD)

Se estiver usando um banco remoto existente, use os usuários já cadastrados nesse banco.

Estrutura dos Containers

┌─────────────────┐
│      SGVP       │ → Porta 8000:80
│  (Aplicação)    │
└────────┬────────┘
         │
         ├──→ demo.legisinc.com.br:5432 (PostgreSQL 17 Remoto)
         │
         ├──→ SOLR (Porta 8983)
         │
         └──→ OnlyOffice (Porta 8002)

Solução de Problemas

Gunicorn não inicia (sem socket criado)

# Verificar logs detalhados
docker exec sapl cat /var/log/sapl/error.log

# Verificar permissões
docker exec sapl ls -la /var/interlegis/sapl/run/

Erro de conexão com banco de dados

# Verificar variáveis de ambiente
docker exec sapl env | grep DATABASE_URL

# Testar conexão manualmente
docker run --rm postgres:17-alpine psql \
  "postgresql://usuario:senha@host:5432/database" \
  -c "SELECT version();"

Use um cliente psql de versão maior ou igual à do servidor (o demo roda PostgreSQL 17.10); um cliente antigo falha no pg_dump/pg_restore.

ALTER DATABASE "…" failed. Need DB owner or superuser.

O container morre no boot, antes das migrations. O usuário do DATABASE_URL não é dono do banco nem superusuário, e o banco não está em UTC — então o configure_pg_timezone do start.sh tenta o ALTER DATABASE e aborta com exit 1. Ver O que o usuário remoto precisa poder fazer.

permission denied for schema public

django.db.utils.ProgrammingError: permission denied for schema public
LINE 1: CREATE TABLE "..." ("id" serial NO...

Há migration pendente e o usuário não tem CREATE no schema public. A migration roda em transação, então a tentativa recusada não deixa resíduo no banco. Confirme com:

docker exec sapl python3 manage.py showmigrations | grep '\[ \]'

Solução: cópia local do banco (seção 4 do LOCALHOST_SETUP.md) ou GRANT CREATE ON SCHEMA public concedido pelo dono do banco.

Erro 404 no nginx

# Verificar se o socket existe
docker exec sapl ls -la /var/interlegis/sapl/run/gunicorn.sock

# Se não existir, verificar por que o gunicorn não iniciou
docker logs sapl 2>&1 | grep -i error

Comandos Úteis

# Ver status dos containers
docker-compose ps

# Reiniciar o SGVP
docker-compose restart sapl

# Ver logs em tempo real
docker logs sapl -f

# Parar todos os containers
docker-compose down

# Iniciar todos os containers
docker-compose up -d

# Reconstruir e iniciar
docker-compose up -d --build sapl

# Executar comando no container
docker exec -it sapl bash

Estrutura de Arquivos Importantes

sapl/
├── docker/
│   ├── docker-compose.yaml          # Configuração principal
│   ├── Dockerfile                   # Imagem do SGVP
│   └── startup_scripts/
│       ├── gunicorn.conf.py         # Configuração do gunicorn
│       ├── start.sh                 # Script de inicialização
│       └── create_admin.py          # Criação de usuários admin
├── sapl/
│   └── settings.py                  # Configurações Django
└── requirements/
    └── requirements.txt             # Dependências Python

Notas Finais

• O banco de dados local (container postgres) não é mais necessário quando usando banco remoto
• As migrations são aplicadas automaticamente na inicialização (migrate_db no start.sh) — o que também significa que não há como subir o compose sem tentar migrar: se houver migration pendente e o usuário não tiver CREATE, o boot falha
• O timezone do banco é configurado automaticamente para America/Sao_Paulo via ALTER DATABASE/ALTER ROLE — exige dono do banco ou superusuário, e o start.sh só pula essa etapa se o banco já estiver em UTC
• Os arquivos de media e data ficam em volumes Docker separados