Docker

eodia analytics se construit en une seule image à partir du Dockerfile du dépôt. Elle contient l’API (qui sert aussi le script et le point de collecte), l’interface et le worker ; l’argument donné au conteneur choisit ce qu’il fait tourner. docker-compose.prod.yml assemble cette image avec PostgreSQL et Caddy. Toute la configuration passe par des variables d’environnement.

L’image

docker build -t eodia-analytics .

Elle repose sur Node 22. Les applications s’exécutent depuis leurs sources TypeScript avec tsx ; l’interface (next build) et le script (/a.js, /p.js, par esbuild) sont compilés au moment du build. En option, le build télécharge la base des pays DB-IP Lite (licence CC BY 4.0), que GEOIP_DB désigne ensuite.

Rôle	Commande	Port	Ce qu’il fait
`api`	`docker run eodia-analytics api`	4600	REST `/api/v1`, authentification, `/a.js`, `/p.js`, `/collect`, `/collect/server`
`web`	`docker run eodia-analytics web`	3600	l’interface Next.js
`worker`	`docker run eodia-analytics worker`	—	la file de jobs : partitions, conservation, sel du jour, vues générées, demandes d’export et d’effacement
`all` (défaut)	`docker run eodia-analytics`	3600, 4600	`api`, `web` et `worker` dans un seul conteneur

En mode all, un petit superviseur lance les trois processus, préfixe leurs journaux ([api], [web], [worker]), relaie l’arrêt, et arrête tout le conteneur dès que l’un d’eux meurt : l’orchestrateur le relance alors entier.

Le déploiement de production

docker-compose.prod.yml fait tourner un service par rôle :

Service	Image	Rôle
`db`	`postgres:17-alpine`	la base : paramétrage, données brutes, vues (volume de données)
`api`	`eodia-analytics`	l’API et la collecte ; applique les migrations au démarrage
`worker`	`eodia-analytics`	les jobs (`INPROCESS_WORKER=0` pour l’API)
`web`	`eodia-analytics`	l’interface
`caddy`	`caddy:2-alpine`	HTTPS automatique, ports 80 et 443

docker compose -f docker-compose.prod.yml up -d --build   # construire et démarrer
docker compose -f docker-compose.prod.yml logs -f api     # suivre l’API
docker compose -f docker-compose.prod.yml ps              # état et santé des services
docker compose -f docker-compose.prod.yml down            # arrêter (les volumes restent)

Caddy

docker/Caddyfile sert DOMAIN en HTTPS (Let’s Encrypt ; ACME_EMAIL en contact), compresse les réponses, pose HSTS et quelques en-têtes de sécurité, puis répartit :

Chemin	Vers
`/a.js`, `/p.js`	`api:4600` : le script, et le dessin du mode aperçu
`/collect`, `/collect/*`	`api:4600` : le point de collecte public et la collecte côté serveur
`/api/*`	`api:4600` : REST et authentification
le reste	`web:3600`

Caddy ne tient aucun journal d’accès : il garderait l’adresse IP des visiteurs. Si vous mettez un autre proxy devant, coupez aussi son journal d’accès pour /collect, ou retirez-en les adresses.

Écritures et répliques

Les écritures sont groupées dans le processus qui reçoit : un lot par seconde (COLLECT_FLUSH_MS) ou tous les 500 événements. Un arrêt propre (SIGTERM) vide le tampon ; un arrêt brutal perd au plus une seconde d’événements.
Plusieurs répliques de l’API peuvent recevoir ensemble : le sel du jour est en base, le hachage est le même partout. Les visites, elles, sont attribuées en mémoire : derrière un équilibreur sans affinité, une visite peut se couper en deux. Préférez une affinité par adresse.
Plusieurs workers peuvent tourner ensemble : chacun prend ses jobs par FOR UPDATE SKIP LOCKED.

Les données dans le temps

Les données brutes (collect) sont partitionnées par mois ; le worker crée les partitions trois mois à l’avance. Une partition DEFAULT sert de filet et doit rester vide : Administration › Réglages › Collecte le surveille.
La durée de conservation de chaque site (25 mois au plus) est appliquée chaque nuit.

Sauvegarder

Deux choses suffisent à reconstruire une instance :

la base (db), par exemple avec pg_dump — les vues et le rôle de lecture se recréent par les migrations ;
la clé SECRET_KEY : sans elle, les secrets des sites sont illisibles.

eodia analytics est un logiciel libre d’Eodia.