Architecture des conteneurs

Tale tourne en six conteneurs Docker pilotés par Docker Compose, chacun avec une responsabilité unique et un port unique sur le réseau bridge interne. Cette page est le modèle mental de l'opérateur sur ce qui tourne, où, et comment les services se parlent : quels volumes sont partagés, quels ports sont exposés, où la topologie blue-green se replie sur elle-même pendant un déploiement. Ouvre-la quand quelque chose n'atterrit pas là où tu l'attends — un endpoint de métriques injoignable, un port exposé par erreur, une bascule blue-green qui n'a pas drainé proprement.

Les six conteneurs sont stables sur chaque chemin d'installation. Démarrage rapide, déploiement en production et CI montent tous le même ensemble ; seuls les mappages de ports, le mode TLS et les bindings d'hôte diffèrent.

Comment les services se parlent

Le proxy est le seul conteneur qui écoute sur un port public. Tout le reste reste sur le bridge Docker interne ; la plateforme ne touche jamais Postgres directement parce que Convex possède chaque lecture et écriture qui atterrit dans la base. RAG et le crawler parlent à la base pour leurs propres tables par service (schémas tale_knowledge) mais ne lisent ni n'écrivent jamais les tables Convex.

Détails d'image

Sortir Convex de l'image plateforme a fait passer la couche plateforme d'environ 2,58 Go compressés à environ 320 Mo ; le nouveau service convex pèse environ 485 Mo. Le disque image net est similaire, mais la couche plateforme se reconstruit beaucoup plus vite pour les changements purement applicatifs — la plupart des pull requests ne touchent que la SPA ou le serveur Bun, et l'image plateforme est celle que la CI reconstruit à chaque merge.

Mappage de ports

Ports de développement (compose.yml)

Ports de test (compose.test.yml)

Le fichier compose de développement expose les quatre ports backend sur l'hôte (5432, 8001, 8002) pour un accès direct depuis le portable du développeur ; le compose de production généré par tale deploy ne le fait pas — chaque port backend reste sur le bridge interne.

Mappage de volumes

Ne fais jamais tourner docker compose down -v. Le drapeau -v supprime chaque volume nommé, c'est-à-dire la base, chaque fichier téléversé, l'état du crawler et les certificats TLS. Pas de récupération possible.

Arguments de build

Stratégie de build multi-étapes

Chaque service se termine par une étape FROM scratch de squash. Cette étape finale aplatit les couches Docker pour que les suppressions de fichiers dans les étapes de nettoyage précédentes récupèrent de l'espace disque au lieu d'ajouter des couches de masquage ; sans le squash, un rm -rf à l'étape quatre coûterait encore les octets supprimés dans l'image finale.

Platform (5 étapes, après scission)

1. bun-bin — extrait le binaire Bun.
2. workspace-deps — installe chaque dépendance npm, devDependencies incluses.
3. builder — fait tourner vite build pour produire le bundle SPA.
4. pruner — réinstalle les deps de production uniquement, retire les paquets de test et de développement.
5. runner — runtime final sur l'image de base convex-backend (gardée pour le binaire glibc generate_key qui sert à signer les jetons admin Convex). SPA Vite et serveur Bun uniquement — pas de processus backend Convex.

Une étape squash sur FROM scratch puis COPY --from=runner produit l'image livrée. Le conteneur tourne brièvement en root, descend à l'utilisateur app via gosu dans l'entrypoint.

Convex (2 étapes, nouveau en Phase 2)

1. convex-dashboard — FROM ghcr.io/get-convex/convex-dashboard pour copier le build standalone Next.js.
2. runner — FROM ghcr.io/get-convex/convex-backend. Contient le démon local-backend, le tableau de bord, les assets de seed intégrés (agents, workflows, intégrations, fournisseurs, image de marque) et l'entrypoint. Retire LLVM et Clang pour environ 155 Mo d'économies.

Crawler (3 étapes)

1. builder — installe les dépendances Python via uv, télécharge Chromium headless_shell, fait tourner un nettoyage profond (retire le binaire Chrome complet, FFmpeg, pip, __pycache__, les symboles de debug .so, les répertoires de test).
2. runtime — python:3.11-slim propre avec uniquement les bibliothèques système runtime (deps Chromium, tini, curl). Retire LLVM et le jeu d'icônes Adwaita.
3. squash — FROM scratch plus COPY --from=runtime. Préalloue les points de montage de volumes pour /app/data et /app/platform-config.

RAG (3 étapes)

1. builder — installe les deps Python avec build-essential et libpq-dev pour compiler les paquets natifs, puis retire pip et setuptools.
2. runtime — python:3.11-slim propre avec uniquement libpq5 et curl. Préalloue les points de montage de volumes.
3. squash — FROM scratch plus COPY --from=runtime.

DB (3 étapes)

1. cleanup — retire les symboles de debug (environ 888 Mo), les bibliothèques partagées LLVM (environ 127 Mo), les fichiers de l'extension PostGIS, les locales et les docs depuis l'image de base ParadeDB.
2. runtime — FROM scratch plus COPY --from=cleanup. Couche fraîche avec uniquement les fichiers nettoyés.
3. squash — redéclare PGDATA, PATH et les autres variables ENV perdues pendant FROM scratch.

Health checks

Les marqueurs /tmp/<service>-ready sont touchés par l'entrypoint de chaque service après que son travail d'initialisation en une passe se termine — Convex après que le backend est en marche et que le seed intégré atterrit ; la plateforme après que la synchronisation d'environnement et convex deploy réussissent. Le fichier marqueur est ce qui empêche le proxy de router le trafic vers un conteneur qui accepte les connexions mais n'est pas encore prêt à servir.

Test des conteneurs

Tale inclut trois scripts de test de conteneurs qui tournent en CI à chaque pull request et que tu peux faire tourner sur un hôte de développement avant de pousser :

Le guide Contributing Docker couvre chaque script en détail.

Où cela s'insère

L'architecture des conteneurs est le modèle mental de ce qui tourne, où et comment les services se parlent. Ouvre-la quand quelque chose n'atterrit pas là où tu l'attends — un endpoint de métriques injoignable, un port exposé par erreur, une bascule blue-green qui n'a pas drainé proprement. Pour les surfaces d'observabilité par service, Exploitation est la page suivante ; pour les boutons en variable d'environnement, Référence d'environnement est exhaustive.