À qui s'adresse cette fonctionnalité ?
Équipes qui décrivent déjà leur pile dans un fichier docker-compose et veulent la faire tourner derrière la périphérie sans la reconstruire service par service.
Comment ça fonctionne ?
Les services avec une image préconstruite deviennent des apps conteneurs ; les services Redis, MySQL/MariaDB, Postgres et NATS sont convertis en add-ons managés et rattachés aux apps qui en dépendent. Ports, environnement, volumes, réplicas, healthchecks et ordre depends_on sont mappés automatiquement.
Aperçu avant l'application
L'aperçu analyse le fichier côté serveur et renvoie le plan : apps à créer, mappings d'add-ons, clés d'environnement vs secrets, avertissements, services non pris en charge, et si cela tient dans votre quota. Rien n'est créé avant l'application, et les valeurs des secrets ne sont jamais renvoyées — seulement les noms de clés.
Sécurisé par défaut
Le déploiement est tout-ou-rien dans une seule transaction : si un nom d'app existe déjà ou si une étape échoue, rien n'est créé. Les clés de type secret comme les mots de passe, tokens et clés API sont stockées comme secrets plutôt qu'en variables d'environnement en clair.
Comment déployer, étape par étape
Préparer votre fichier compose
Assurez-vous que chaque service utilise une image préconstruite (par exemple image: myorg/web:1.2). Les services qui n'ont qu'une étape build: ne sont pas encore pris en charge, poussez-les d'abord vers un registre. Les services Redis, MySQL/MariaDB, Postgres et NATS n'ont pas besoin d'image — ils sont automatiquement transformés en add-ons managés.
Identifiants de registre (images privées)
Si une image est privée, ouvrez Container Apps → identifiants de registre une fois et ajoutez votre nom d'utilisateur de registre et votre token d'accès, afin que la plateforme puisse récupérer l'image au déploiement. Passez cette étape si toutes vos images sont publiques.
Importer le fichier
Dans le panel, ouvrez Container Apps → « Import From Docker Compose », puis téléversez ou collez votre docker-compose.yml. Rien n'est créé à ce stade — l'import se contente de lire le fichier.
Prévisualiser le plan
Le fichier est analysé côté serveur et vous obtenez le plan complet avant que quoi que ce soit ne se produise : quelles apps conteneurs seront créées, quels services deviennent des add-ons managés, quelles clés sont stockées en environnement ou en secrets, les avertissements ou services non pris en charge éventuels, et si cela tient dans votre quota.
Appliquer
Confirmez pour appliquer. Dans une transaction unique tout-ou-rien, les apps et add-ons sont créés et connectés entre eux — ports, environnement, volumes, réplicas, healthchecks et ordre depends_on sont mappés pour vous. Si une étape échoue, rien n'est créé.
Exposer et gérer
Exposez le service web pour obtenir une URL gratuite name.cdn.com.tr avec HTTPS automatique, ou attachez votre propre domaine. Depuis là, gérez logs, environnement, scaling et redémarrages dans le panel. Vous préférez le terminal ? « cdnctl container compose preview » puis « … apply » font la même chose en deux commandes.
Exemples de scénarios
Migrer un projet compose multi-services vers des apps et add-ons managés.
Monter un environnement de revue ou de démo à partir du même fichier compose.
Utiliser un seul fichier compose comme source de vérité sur tous les projets.
Questions fréquentes
Construit-il des images à partir du code source ?
Non. Chaque service d'app a besoin d'une image préconstruite. Les services qui ne définissent qu'une étape build sont listés comme non pris en charge dans l'aperçu, pour que vous puissiez d'abord pousser une image.
Que se passe-t-il pour ma base de données ou mon service Redis ?
Redis, MySQL/MariaDB, Postgres et NATS sont convertis en add-ons managés et rattachés aux apps qui en dépendent, au lieu de s'exécuter comme des conteneurs bruts.
Y a-t-il une limite ?
Un import unique gère jusqu'à 20 services. Lancez d'abord l'aperçu pour voir le plan complet et vérifier qu'il tient dans votre quota de compte.