Aller au contenu principal

Premier Démarrage

À faire une seule fois, après l'installation d'un serveur neuf.

1. Vérifier les conteneurs​

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

Le journal du backend doit montrer les étapes de l'entrypoint : clés JWT, base de données, migrations, permissions, cache.

2. Base de données​

Les migrations sont jouées automatiquement au démarrage du backend. Pour vérifier :

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

Pour reprendre une base existante (migration d'un serveur), restaurer un dump plutôt que repartir de zéro : voir Restauration.

3. Clés JWT​

En préproduction, l'entrypoint crée la paire de clés dans backend/config/jwt/ si elle manque, avec JWT_PASSPHRASE. En production, ce répertoire est monté en lecture seule : créer les clés sur l'hôte avant le premier démarrage (commandes dans Authentification JWT). Ces clés sont propres au serveur : ne les copiez pas d'un serveur à l'autre et ne les écrasez pas lors d'un déploiement.

4. Données de référence​

docker exec -u www-data pch_backend php bin/console app:init-geo-data            # régions, secteurs, communes, localités
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

Le reste (projets, programmes, méthodes PMT, workflows des plaintes, nomenclature) se configure dans Paramètres.

5. Premier administrateur​

docker exec -u www-data pch_backend php bin/console app:create-user <email> '<mot de passe>' <Nom> <Prénom> --role=ROLE_ADMIN

Le mot de passe se choisit hors de toute conversation ou ticket, et se range dans le gestionnaire de secrets. Pour une réinitialisation :

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

Ensuite, dans l'application : rattacher l'administrateur à son institution et à ses projets (Paramètres → Utilisateurs). Un compte sans rattachement ne voit aucune donnée. La commande app:perimetre:initialiser le fait en masse.

6. Tâches planifiées (cron de l'hôte)​

# Digest des plaintes en retard, 08:00
0 8 * * * docker exec pch_backend php bin/console app:plaintes:send-digest >> /var/log/plainte-digest.log 2>&1
# Base documentaire de l'assistant 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

Les autres tâches planifiées (escalade des plaintes, alertes) sont exécutées par le worker scheduler_plaintes du conteneur backend, qui consomme aussi scheduler_transferts (récurrence des transferts, chaque jour à 6 h).

7. Documentation et assistant​

Déployer le build de la documentation dans ~/pch-sig/documentation/build, puis indexer :

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

8. Contrôle final​

  • https://<domaine>/ affiche l'écran de connexion, https://<domaine>/api/health répond 200.
  • Connexion avec le compte administrateur, puis déconnexion.
  • Un e-mail de test part (création d'un compte de test : e-mail de bienvenue) et la file failed reste vide.
cache:clear

Ne lancez jamais cache:clear avec docker exec en root : le cache recréé appartient à root et php-fpm (www-data) ne peut plus écrire, d'où des erreurs 500. Utilisez -u www-data, ou recréez le conteneur.