Construire et maintenir les images Tale

Construis une image lorsque tu changes les dépendances d’un conteneur, son démarrage ou le code applicatif qu’il contient. Il te faut les sources préparées selon Environnement de développement, un daemon Docker actif et l’accès aux registres d’images et de paquets utilisés par le Dockerfile.

Une construction réussie prouve que l’image peut être assemblée. Lance-la dans un environnement de développement séparé et teste le comportement modifié avant de la déployer.

Identifier les images

Les Dockerfiles utilisent la racine du dépôt comme contexte de construction. Consulte chacun pour les versions de base et arguments exacts. Le tableau précise le rôle des images.

Le stockage objet et le service auxiliaire d’ingestion vidéo utilisent directement des images amont, sans Dockerfile Tale. Les images d’exécution de sandbox et de BuildKit sont lancées à la demande. Construire les seuls services déclarés dans Compose ne les construit pas automatiquement.

Construire en local

Pour construire le proxy isolément, lance cette commande à la racine du dépôt :

docker build -f services/proxy/Dockerfile -t tale-proxy:docs-review .

Le tag local docs-review distingue le résultat d’une version publiée. Attends que la construction réussisse avant de tester l’image ou de la préparer pour sa distribution.

Pour un service disposant d’une définition build: dans le fichier Compose du dépôt :

docker compose build platform

Sans nom de service, docker compose build sélectionne tous les services dotés d’une définition de construction. La durée dépend du cache, du réseau, de la plateforme cible et de l’image. Une image de navigateur ou d’application n’a pas les mêmes besoins que le proxy.

Le fichier Compose du dépôt utilise PULL_POLICY=build par défaut. Les fichiers de production générés récupèrent normalement les images publiées. Fichiers Compose décrit le lancement de développement prévu, qui prépare aussi les services et images supplémentaires.

Choisir où intervenir

Commence par le changement le plus limité qui répond au besoin :

Les points d’entrée, contrôles d’état et chemins internes font partie du contrat d’implémentation. Un fork doit maintenir et tester leurs modifications au fil des versions. Une modification de configuration seule peut ne pas nécessiter d’image ; voir Exploiter Compose soi-même.

Publier dans ton registre

Après les tests, choisis ton espace de noms et un tag immuable. Cet exemple publie uniquement l’image du proxy construite plus haut, pas toutes les images d’un déploiement. L’authentification au registre et le droit d’y publier sont nécessaires.

export REGISTRY=registry.internal.example.com/tale
export IMAGE_TAG=reviewed-build-1
docker tag tale-proxy:docs-review "$REGISTRY/tale-proxy:$IMAGE_TAG"
docker push "$REGISTRY/tale-proxy:$IMAGE_TAG"

Note l’empreinte, le commit source et la plateforme de construction. Distribue toutes les images nécessaires à la destination, dont celles des sandboxes et les dépendances amont. Un environnement hors ligne doit aussi prévoir paquets, téléchargements de navigateurs et accès aux modèles. Transférer une seule image ne rend pas le système autonome.

La CLI lit l’espace de noms des images Tale dans GHCR_REGISTRY. La version sélectionnée détermine toujours le tag. Publie donc les noms et tags attendus par le déploiement. Pour fixer séparément les images et commits source, consulte la référence des déploiements gérés.

Suivre les évolutions amont

Versionne tes changements et examine les évolutions amont avant de reconstruire. Conserve les versions ou empreintes des images de base avec le compte rendu de construction. Mets ces références à jour délibérément : reconstruire avec une référence inchangée ne récupère pas automatiquement une nouvelle version.

Avant le déploiement, vérifie rôle de démarrage, contrôles d’état, routes publiques et fonctionnalité modifiée. Pour une sandbox, teste une nouvelle session et ses appels réseau. Propose les correctifs d’intérêt général au projet amont lorsque possible pour réduire le code propre à ton fork.

Diagnostiquer un échec

L’architecture des conteneurs explique les dépendances ; Mises à jour couvre le déploiement et la restauration.