Files
lidar_rendu/docker-compose.worker.yml
Antoine Jacquin 0a2ccee958 Porter la génération de tuiles dans lidar-maps et retirer l'ancienne webapp
La carte à tuiles XYZ devient la seule interface : l'API de génération
(preview, generate, status, stop, file, cell), le job unique + file
persistante, la délégation LIDAR_GENERATION_URL et les garde-fous
(token, LIDAR_REGEN_CIDR) passent de webapp.py à mapserve.py ; l'interface
gagne les boutons + Zone / ⤒ Compléter / régénération à la dalle, les
options de run et la progression cadre par cadre. mapserve sert aussi
l'inventaire /api/tiles et les dalles en statique versionné : le worker
image complète remplace la webapp sur le 8973 du générateur, le Pi
n'exécute plus que lidar-maps. index.py se réduit aux registres partagés
+ vignettes/sous-tuiles/inventaire (l'UI HTML/JS et les mosaïques
d'overview partent avec export.py et les compose/scripts de la webapp).
2026-09-23 23:21:05 +02:00

67 lines
2.6 KiB
YAML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Machine de traitement — générateur de tuiles (cf. docs/DEPLOY_WEBAPP.md).
#
# Tourne sur la machine puissante (GPU + PDAL) et expose l'API que les
# cartes distantes (Raspberry Pi, docker-compose.maps.yml + LIDAR_GENERATION_URL)
# appellent : dessin d'une zone → téléchargement IGN + traitement GPU ici,
# dalles et tuiles servies aux machines légères (/api/tiles + statiques,
# /tiles/XYZ).
#
# docker compose -f docker-compose.worker.yml up -d --build
# docker compose -f docker-compose.worker.yml logs -f worker
# docker compose -f docker-compose.worker.yml down
#
# Traitement batch ponctuel des dalles présentes dans input/ :
# docker compose -f docker-compose.worker.yml run --rm --build process [-r 0.5,0.2 | --force]
services:
# Générateur de tuiles : carte XYZ + API de génération (image complète, GPU)
worker:
build: .
image: lidar-lidar
container_name: lidar-worker
init: true
user: "1000:1000"
gpus: all # retirer cette ligne sur une machine sans GPU
ports:
- "8973:8973" # joignable par les cartes distantes (LIDAR_GENERATION_URL
# et LIDAR_SOURCE_URL pointent ici)
volumes:
# input/ en écriture : l'API y télécharge les dalles IGN manquantes
- ./input:/data/input
- ./output:/data/output
environment:
- TZ=Europe/Paris
- LIDAR_INPUT_DIR=/data/input
- LIDAR_OUTPUT_DIR=/data/output
- LIDAR_PORT=8973
# Les générations lancées depuis une carte distante utilisent le GPU
- LIDAR_GPU=1
- LIDAR_WORKERS=auto
# Une ligne par worker : BLAS/OpenMP mono-thread, sinon 12 workers × N
# threads écrasent les 14 cœurs (load 68+ observé pendant les runs)
- OMP_NUM_THREADS=1
- OPENBLAS_NUM_THREADS=1
- MKL_NUM_THREADS=1
- NUMEXPR_NUM_THREADS=1
# Protéger l'API si le réseau n'est pas de confiance : même valeur que
# LIDAR_REMOTE_TOKEN sur chaque carte distante (sinon, laisser commenté)
# - LIDAR_API_TOKEN=change-moi
command: python3 -m uvicorn lidar_pipeline.mapserve:app --host 0.0.0.0 --port 8973
restart: unless-stopped
# Traitement ponctuel des dalles input/ (une passe puis arrêt)
process:
build: .
image: lidar-lidar
container_name: lidar-process
init: true
user: "1000:1000"
gpus: all # retirer cette ligne sur une machine sans GPU
volumes:
- ./input:/data/input
- ./output:/data/output
environment:
- TZ=Europe/Paris
command: ["python3", "-m", "lidar_pipeline", "/data/input", "-o", "/data/output", "-r", "0.2", "-g", "all"]
profiles:
- process