Pular para o conteúdo principal

Primeiro Arranque

A fazer uma única vez, após a instalação de um servidor novo.

1. Verificar os contentores​

cd ~/pch-sig
docker compose -f docker-compose.prod.yml ps
docker compose -f docker-compose.prod.yml logs backend | tail -30

O registo do backend deve mostrar as etapas do entrypoint: chaves JWT, base de dados, migrações, permissões, cache.

2. Base de dados​

As migrações são executadas automaticamente no arranque do backend. Para verificar:

docker exec -u www-data pch_backend php bin/console doctrine:migrations:status

Para retomar uma base existente (migração de um servidor), restaurar um dump em vez de partir do zero: ver Restauro.

3. Chaves JWT​

Em pré-produção, o entrypoint cria o par de chaves em backend/config/jwt/ se faltar, com JWT_PASSPHRASE. Em produção, esta pasta está montada só de leitura: criar as chaves no anfitrião antes do primeiro arranque (comandos em Autenticação JWT). Estas chaves são próprias do servidor: não as copie de um servidor para outro nem as sobrescreva durante uma implantação.

4. Dados de referência​

docker exec -u www-data pch_backend php bin/console app:init-geo-data            # regiões, setores, comunas, localidades
docker exec -u www-data pch_backend php bin/console app:init-categories-reclamation
docker exec -u www-data pch_backend php bin/console app:init-eligibility-templates

O resto (projetos, programas, métodos PMT, fluxos das reclamações, nomenclatura) configura-se em Definições.

5. Primeiro administrador​

docker exec -u www-data pch_backend php bin/console app:create-user <email> '<palavra-passe>' <Apelido> <Nome> --role=ROLE_ADMIN

A palavra-passe escolhe-se fora de qualquer conversa ou pedido de suporte e guarda-se no gestor de segredos. Para uma reposição:

docker exec -u www-data pch_backend php bin/console app:reset-user-password <email> '<nova palavra-passe>'

Depois, na aplicação: vincular o administrador à sua instituição e aos seus projetos (Definições → Utilizadores). Uma conta sem vínculo não vê nenhum dado. O comando app:perimetre:initialiser faz isto em massa.

6. Tarefas planeadas (cron do anfitrião)​

# Resumo das reclamações em atraso, 08:00
0 8 * * * docker exec pch_backend php bin/console app:plaintes:send-digest >> /var/log/plainte-digest.log 2>&1
# Base documental do assistente Bemba, 03:15
15 3 * * * docker exec -u www-data pch_backend php bin/console app:assistant:indexer --max-appels=15 >> /home/ubuntu/assistant-indexer.log 2>&1

As outras tarefas planeadas (escalonamento das reclamações, alertas) são executadas pelo worker scheduler_plaintes do contentor backend, que consome também scheduler_transferts (recorrência das transferências, todos os dias às 6 h).

7. Documentação e assistente​

Implantar o build da documentação em ~/pch-sig/documentation/build e depois indexar:

docker exec -u www-data pch_backend php bin/console app:assistant:indexer --etat

8. Controlo final​

  • https://<domínio>/ mostra o ecrã de início de sessão, https://<domínio>/api/health responde 200.
  • Início de sessão com a conta de administrador, depois fim de sessão.
  • Um e-mail de teste é enviado (criação de uma conta de teste: e-mail de boas-vindas) e a fila failed fica vazia.
cache:clear

Nunca execute cache:clear com docker exec como root: a cache recriada pertence a root e o php-fpm (www-data) deixa de poder escrever, daí erros 500. Use -u www-data, ou recrie o contentor.