D'une image à une URL publique, sans faire tourner de serveurs
Mettre un simple container en ligne implique normalement de provisionner un hôte, d'installer un runtime de containers, de câbler un reverse proxy, d'obtenir un certificat et d'ouvrir des ports de pare-feu — beaucoup de travail indifférencié pour une seule API. Container Apps supprime tout cela : vous lui donnez une image et un port, et elle vous rend une URL name.cdn.com.tr en direct, sécurisée en HTTPS. Il n'y a pas d'hôte à patcher, pas de nginx à configurer, et pas de cron certbot à surveiller, car l'edge et le TLS font partie de la plateforme.
Healthchecks et déploiements sans interruption
Un déploiement qui remplace les containers dès que le processus démarre laissera tomber des requêtes pendant que l'application est encore en train de chauffer. La plateforme utilise votre chemin de healthcheck pour décider de l'état de disponibilité : sur un nouveau déploiement, elle démarre le nouveau container, attend que le healthcheck réussisse, bascule le trafic, et ne retire l'ancien container qu'ensuite. Cela signifie qu'une mauvaise image qui ne devient jamais saine ne fait pas tomber le service — la version précédente continue de servir jusqu'à ce que la nouvelle fasse ses preuves.
Environnement et secrets faits correctement
Les applications douze-facteurs lisent leur configuration depuis l'environnement, et les containers ne font pas exception. Les paramètres simples entrent comme variables d'environnement ; tout ce qui est sensible — mots de passe de base de données, clés API tierces, secrets de signature — entre comme un secret stocké chiffré et affiché uniquement par son nom de clé, jamais par sa valeur, une fois enregistré. Lorsque vous liez de l'Object Storage ou une base de données managée, leurs identifiants sont injectés de la même façon, si bien que rien de sensible ne finit intégré dans l'image ou affiché dans un log de build.
Scaling et plans de ressources adaptés à la charge réelle
Vous choisissez un plan de ressources (CPU et mémoire) par application ainsi qu'un nombre de réplicas, de sorte qu'un outil interne à faible trafic et une API publique n'ont pas à partager le même gabarit. Faire tourner plusieurs réplicas apporte aussi de la résilience : si un container redémarre, les autres continuent de servir. Comme les déploiements sont conditionnés par la santé de l'application, scaler ou déployer une nouvelle version ne crée jamais de moment où l'application devient injoignable.
Route edge, Auto SSL et WAF devant votre API
Chaque application containerisée exposée est atteinte via l'edge cdn.com.tr, si bien que les mêmes protections dont bénéficient vos sites web s'appliquent à vos API. Auto SSL fournit et renouvelle le certificat, le WAF filtre le trafic malveillant et de scan avant qu'il n'atteigne votre service, et vous pouvez mettre en cache à l'edge les réponses GET sûres pour soulager le container de la charge de lecture. Votre container d'origine n'est jamais adressé directement par le public — il ne reçoit que le trafic transmis par l'edge.
Panneau ou cdnctl, et ça s'intègre à votre stack
Tout ce que vous pouvez faire dans le panneau — déployer, définir env et secrets, scaler, lire les logs, redémarrer — est également disponible via l'outil en ligne de commande cdnctl, si bien que les opérations sur les containers s'intègrent dans des scripts et de la CI. Container Apps est également la cible de Docker Compose Instant Deploy : un fichier compose multi-services devient plusieurs applications containerisées plus des add-ons managés en un seul apply, ce qui est le moyen le plus rapide de reprendre une stack existante plutôt que de recréer chaque service à la main.
Comment déployer, étape par étape
Créer une application containerisée
Dans le panneau, ouvrez Container Apps et créez une application à partir d'une image préconstruite, par exemple myorg/api:1.4 depuis Docker Hub ou un registre privé. Définissez le port du container sur lequel votre service écoute afin que la plateforme sache où envoyer le trafic.
Ajouter un identifiant de registre privé (si nécessaire)
Si l'image est privée, ajoutez une seule fois un nom d'utilisateur et un access token de registre sous Container Apps → registry credentials, afin que la plateforme puisse la récupérer à chaque déploiement. Les images publiques ignorent complètement cette étape.
Configurer l'environnement, les secrets et le healthcheck
Ajoutez la configuration simple sous forme de variables d'environnement et les valeurs sensibles — clés API, mots de passe de base de données, tokens — sous forme de secrets, stockés chiffrés et jamais réaffichés. Définissez un chemin de healthcheck afin que la plateforme sache quand un nouveau container est réellement prêt à servir, et pas simplement démarré.
Déployer et exposer
Déployez l'application, puis exposez le port web pour obtenir une URL gratuite name.cdn.com.tr avec HTTPS automatique, ou attachez votre propre domaine. Le trafic passe désormais par l'edge cdn.com.tr jusqu'à votre container, avec le SSL terminé à l'edge.
Scaler, surveiller les logs et déployer des mises à jour
Définissez le nombre de réplicas et un plan de ressources adapté à la charge attendue, streamez les logs depuis le panneau pour déboguer, et poussez un nouveau tag d'image pour déclencher un déploiement sans interruption. Vous préférez le terminal ? cdnctl effectue les mêmes opérations de déploiement, de scaling et de logs depuis votre shell.
Exemples de scénarios
Une API Node ou Go est déployée depuis une image, exposée sur un domaine avec Auto SSL, et protégée par le WAF, avec les réponses GET sûres mises en cache à l'edge.
Un seul service tourne avec son propre plan de ressources et ses propres secrets, scalé sur quelques réplicas pour la résilience, sans partager d'hôte avec le reste de la stack.
Une équipe produit monte un environnement jetable à partir d'un tag d'image sur une URL name.cdn.com.tr, puis le démantèle une fois la revue terminée.
Questions fréquentes
Container Apps construit-il mon image à partir d'un Dockerfile ?
Non — il déploie des images préconstruites. Vous construisez et poussez l'image vers un registre (Docker Hub ou un registre privé) et donnez à la plateforme la référence de l'image et le port. Si vous voulez un déploiement au push depuis les sources, associez-le à GitHub Deploy, qui gère l'étape de build, ou utilisez Docker Compose Instant Deploy pour une stack multi-services d'images préconstruites.
Comment fonctionne réellement un déploiement sans interruption ici ?
Sur un nouveau déploiement, la plateforme démarre le nouveau container, attend que votre chemin de healthcheck signale qu'il est prêt, bascule ensuite le trafic vers celui-ci, puis retire l'ancien container. Si le nouveau container ne passe jamais son healthcheck, le trafic reste sur la version précédente, si bien qu'un build cassé ne met pas le service hors ligne.
Mes secrets sont-ils visibles après les avoir enregistrés ?
Non. Les secrets sont stockés chiffrés et affichés uniquement par leur nom de clé une fois enregistrés — les valeurs ne sont jamais réaffichées dans le panneau, dans les logs, ni dans les aperçus. Cela permet de régénérer un secret depuis le panneau sans risquer qu'il fuite dans un enregistrement d'écran, une session support, ou un log de build.
Mon container peut-il accéder à une base de données managée ou à l'Object Storage ?
Oui. Vous liez une base de données managée, Redis, ou un bucket Object Storage à l'application, et les détails de connexion et les access keys sont injectés sous forme de variables d'environnement ou de secrets. Le container les lit depuis son environnement, si bien que les identifiants n'ont jamais à être intégrés dans l'image.
Comment faire tourner plus d'une instance, et pourquoi ?
Définissez le nombre de réplicas sur l'application. Plusieurs réplicas apportent de la résilience — si l'un redémarre ou est en mauvaise santé, les autres continuent de servir — et permettent à l'application d'absorber plus de trafic simultané. Combiné à des déploiements conditionnés par la santé, scaler n'introduit jamais de fenêtre où le service devient injoignable.
Puis-je gérer mes applications containerisées en ligne de commande et en CI ?
Oui. L'outil cdnctl effectue les mêmes opérations de déploiement, scaling, logs, redémarrage et configuration que le panneau, si bien que vous pouvez scripter les opérations sur les containers ou les exécuter depuis un pipeline CI plutôt que de cliquer dans l'interface. C'est aussi ainsi que vous prévisualisez et appliquez un import Docker Compose depuis le terminal.