Sistema de Apoio ao Processo Legislativo

3.4 KiB

Raw Blame History

Subir o SAPL em localhost

A abordagem recomendada usa Docker, pois replica fielmente o ambiente de produção.

Há dois modos de operação:

Modo	Quando usar
Localhost completo (banco local)	Desenvolvimento do zero, sem dependência de banco remoto
Banco remoto	Testar com dados reais de produção/homologação

Modo 1: Localhost completo (banco PostgreSQL local)

Sobe a aplicação e o banco juntos, sem precisar de .env nem banco externo.

cd /root/dev/sapl
docker compose -f docker/docker-compose-local.yml up --build

Na primeira vez, rode as migrations dentro do container:

docker exec -it sapl-dev python manage.py migrate
docker exec -it sapl-dev python manage.py createsuperuser

Servidor disponível em: http://localhost:8000 Banco disponível em: localhost:5432 (usuário: sapl / senha: sapl / banco: sapl)

Para parar:

docker compose -f docker/docker-compose-local.yml down

Os dados do banco ficam no volume Docker sapl-pgdata e persistem entre reinicializações. Para apagar tudo: docker compose -f docker/docker-compose-local.yml down -v

Modo 2: Banco remoto (apontando para banco externo)

O banco é controlado pelo sapl/.env. Basta trocar o DATABASE_URL e reiniciar o container.

1) Configurar o `sapl/.env`

Edite sapl/.env com as credenciais do banco desejado:

DATABASE_URL=postgresql://usuario:senha@host:5432/banco
SECRET_KEY=<sua-chave-secreta>
DEBUG=True
EMAIL_USE_TLS=True
EMAIL_PORT=587

Dica: para trocar de banco, basta editar DATABASE_URL e reiniciar — sem alterar nenhum outro arquivo. Atenção: não rode migrate se o banco for de produção.

2) Subir o ambiente com Docker

cd /root/dev/sapl
docker compose -f docker/docker-compose-dev.yml --env-file sapl/.env up --build

O código-fonte é montado como volume — alterações em .py são recarregadas automaticamente.

Servidor disponível em: http://localhost:8000

3) Parar o ambiente

docker compose -f docker/docker-compose-dev.yml down

4) Rodar comandos Django no container

docker exec -it sapl-dev python manage.py showmigrations --plan
docker exec -it sapl-dev python manage.py shell

Por que Docker em vez de venv + runserver direto?

	venv + runserver	Docker (recomendado)
`DEBUG=True` no .env	Não funcionava (settings.py lia `DJANGO_DEBUG`)	✅ Corrigido, funciona
Banco remoto	Funciona se a porta estiver acessível	✅ Funciona via `extra_hosts: host-gateway`
Proximidade com prod	❌ Diferenças de config e WSGI	✅ Mesmo Dockerfile

Alternativa: venv + runserver (sem Docker)

cd /root/dev/sapl
source .venv/bin/activate
pip install -r requirements/requirements.txt
python manage.py runserver 0.0.0.0:8000

O settings.py foi corrigido para aceitar DEBUG=True (além do legado DJANGO_DEBUG=True).

Problemas comuns

Container não alcança o banco remoto

O docker-compose-dev.yml já configura extra_hosts: host-gateway. Se ainda assim falhar:

nc -zv <host-do-banco> 5432

`DEBUG=True` não ativa o modo debug

O settings.py foi corrigido para aceitar tanto DEBUG quanto DJANGO_DEBUG. Certifique-se que o valor está sem aspas: DEBUG=True.

Static files não carregam com Gunicorn

docker exec -it sapl-dev python manage.py collectstatic --noinput

3.4 KiB Raw Blame History