Le problème : une image qui fonctionne n'est pas un service qui tourne
Avoir une API qui se construit proprement en image container est les 20 % faciles ; la mettre en production représente les 80 % restants. Traditionnellement, cela signifie louer une VM, installer un runtime, configurer un reverse proxy, obtenir et renouveler des certificats TLS, ouvrir les bons ports, ajouter un gestionnaire de processus pour que l'application redémarre après un crash, câbler la collecte de logs, et monter la garde contre des attaquants qui trouvent la machine quelques heures après sa mise en ligne. Chacune de ces étapes est du travail d'infrastructure indifférencié qui n'a rien à voir avec le vrai travail de votre API, et chacune est un endroit où se tromper subtilement en sécurité ou en fiabilité. Container Apps existe pour réduire toute cette checklist à quelques champs.
Comment cdn.com.tr résout ce problème : des containers managés derrière l'edge
Vous donnez à la plateforme une image, un port et un healthcheck, et elle exécute le container, y route le trafic via l'edge, et le garde en vie. Le TLS est géré par Auto SSL, le point d'entrée public est la route edge plutôt que le container brut, et le WAF filtre le trafic malveillant avant qu'il n'atteigne votre service. La configuration arrive sous forme de variables d'environnement et de secrets injectés à l'exécution, le scaling est un nombre de replicas que vous définissez, et logs et status apparaissent dans le panel. Résultat : la seule chose dont vous êtes responsable est votre image applicative ; les questions de serveur, de proxy, de certificat et de pare-feu sont absorbées par la plateforme.
Healthchecks : le filet de sécurité du déploiement
Le healthcheck est ce qui transforme un déploiement d'un espoir en une opération contrôlée. Quand vous poussez une nouvelle version, la plateforme démarre le container et sonde votre endpoint de santé, et ne route le trafic vers la nouvelle instance qu'une fois que cet endpoint signale être sain. Un build qui plante au démarrage, ne peut pas atteindre sa base de données, ou manque d'un secret requis échoue au contrôle et n'est pas mis en rotation, si bien qu'un mauvais déploiement est intercepté au moment du rollout plutôt que par vos utilisateurs. C'est pourquoi le healthcheck doit vérifier une véritable disponibilité — dépendances joignables, configuration présente — plutôt que de simplement renvoyer 200 inconditionnellement. Un healthcheck pertinent fait la différence entre des redéploiements sûrs et des pannes silencieuses.
Environnement vs secrets : de la configuration sans fuite
Les API ont besoin de configuration — URLs de base de données, clés tierces, feature flags — et la mauvaise façon de la fournir est de l'intégrer dans l'image ou de la commiter dans le dépôt, où elle survit pour toujours dans les couches et l'historique. La plateforme sépare les simples variables d'environnement des secrets : les réglages non sensibles entrent en environnement, tandis que mots de passe, tokens et clés d'API sont stockés comme secrets et injectés à l'exécution par clé, jamais réaffichés ni écrits dans votre build. Cela signifie que la même image peut circuler entre environnements avec des configurations différentes, que vos identifiants restent hors du contrôle de version, et que faire tourner un secret est une action de plateforme plutôt qu'une précipitation de rebuild-et-redéploiement.
Scaling, logs et la boucle opérationnelle
Une fois l'API en ligne, l'exploiter revient à quelques contrôles plutôt qu'à de l'administration serveur. Vous choisissez un plan de ressources et définissez combien de replicas faire tourner, en augmentant pour un lancement ou un pic de trafic et en redescendant ensuite. Les logs s'affichent en flux dans le panel afin de pouvoir tracer une requête, déboguer un 500, ou confirmer qu'un déploiement a bien pris, et le status montre si le service est sain et quand il a redémarré pour la dernière fois. Chaque redéploiement passe par le même verrou de healthcheck, si bien que livrer un nouveau build est une action reproductible et observable — vous poussez l'image, vous regardez le contrôle passer, et vous confirmez dans les logs, sans jamais vous connecter en SSH à quoi que ce soit.
Câbler stockage et données
La plupart des API ont besoin d'un endroit où conserver l'état, et le service se combine proprement avec le reste de la plateforme pour cela. Vous pouvez lier un bucket Object Storage au container sous forme de variables d'environnement afin qu'il lise et écrive directement des médias ou des documents, et vous pouvez connecter une base de données managée ou Redis afin que le service dispose de persistance et de cache sans que vous les exploitiez non plus. Comme ces éléments sont attachés via la plateforme et livrés en configuration injectée, l'API reste une image sans état qui peut être mise à l'échelle et redéployée librement pendant que ses données vivent dans des services managés à ses côtés.
Comment le mettre en place, étape par étape
Pointer vers votre image
Dans le panel, créez une Container App et référencez votre image préconstruite (par exemple myorg/api:1.4) depuis un registre public ou privé. Pour les images privées, ajoutez une fois un identifiant de registre afin que la plateforme puisse la récupérer. Définissez le port sur lequel votre API écoute afin que l'edge sache où envoyer le trafic.
Définir le healthcheck
Donnez à l'application un chemin de healthcheck comme /health ou /ready qui renvoie 200 uniquement quand le service est véritablement capable de servir. C'est ce que la plateforme utilise pour décider si un nouveau déploiement est sain avant qu'il ne reçoive du trafic, alors faites-le vérifier ce qui compte vraiment, comme la connectivité à la base de données.
Définir l'environnement et les secrets
Ajoutez la configuration non sensible en variables d'environnement et les valeurs sensibles — clés d'API, mots de passe de base de données, tokens — en secrets, afin qu'ils soient injectés à l'exécution plutôt qu'intégrés dans l'image ou commités dans votre dépôt. Les valeurs de secrets sont stockées de manière sécurisée et référencées par clé, jamais réaffichées.
Déployer et surveiller le healthcheck
Déclenchez le déploiement depuis le panel ou avec cdnctl. Le container est démarré, le healthcheck est sondé, et le service n'est marqué prêt — et mis en rotation — qu'une fois qu'il passe, afin qu'un build cassé ne prenne pas silencieusement du trafic.
Attacher un domaine avec Auto SSL et WAF
Exposez le service pour obtenir une URL gratuite name.cdn.com.tr avec HTTPS automatique, ou attachez votre propre domaine et laissez Auto SSL émettre le certificat. Activez le WAF afin que l'API se trouve derrière le filtrage edge, et le container d'origine n'est joignable que via cette route edge.
Faire évoluer et observer
Ajustez le plan de ressources et le nombre de replicas pour la charge attendue, et utilisez logs et status pour surveiller les déploiements, les redémarrages et le comportement à l'exécution. Les redéploiements suivent le même chemin conditionné par le healthcheck, si bien que pousser une nouvelle version est une opération de routine, observable.
Exemples de scénarios
Une API JSON est publiée depuis son image derrière un domaine avec Auto SSL et WAF, offrant au frontend un endpoint HTTPS stable et sécurisé sans aucun serveur à maintenir.
Un récepteur de webhook, un processeur d'images ou un service d'authentification tourne isolément avec son propre scaling et ses propres secrets, déployé et redéployé indépendamment de tout le reste.
Une équipe produit monte un container depuis une image taguée pour obtenir une URL HTTPS partageable pour une démo, puis le détruit ou le redéploie à mesure que le build avance.
Questions fréquentes
La plateforme construit-elle mon image, ou dois-je en apporter une ?
Vous apportez une image préconstruite depuis un registre. Container Apps exécute et route l'image que vous fournissez ; si elle est privée, vous ajoutez une fois un identifiant de registre afin que la plateforme puisse la récupérer au déploiement.
Que se passe-t-il si mon nouveau déploiement est cassé ?
Il échoue au healthcheck et n'est pas mis en rotation, si bien que le trafic continue d'aller vers la version fonctionnelle. Un container qui plante au démarrage ou ne peut pas atteindre ses dépendances est intercepté au rollout plutôt que de servir des erreurs à vos utilisateurs.
Comment garder les clés d'API et les mots de passe de base de données hors de mon code ?
Stockez-les comme secrets, qui sont injectés dans le container à l'exécution par clé et jamais intégrés dans l'image ni commités dans votre dépôt. Les réglages non sensibles entrent en simples variables d'environnement, si bien que la même image tourne dans différents environnements avec des configurations différentes.
Mon API peut-elle atteindre une base de données ou un bucket Object Storage ?
Oui. Vous pouvez lier un bucket Object Storage au container sous forme de variables d'environnement et connecter une base de données managée ou Redis, afin que le service dispose de stockage, de persistance et de cache tout en restant une image sans état, redéployable.
Comment gérer un pic de trafic ?
Augmentez le nombre de replicas et, si nécessaire, le plan de ressources de l'application. Comme le trafic entre par l'edge et que les containers se trouvent derrière, vous mettez à l'échelle le nombre d'instances pour correspondre à la charge et redescendez ensuite.
Puis-je déployer depuis la ligne de commande plutôt que le panel ?
Oui. cdnctl pilote les mêmes opérations de container depuis votre terminal — déployer, redéployer, mettre à l'échelle et inspecter — afin que vous puissiez scripter vos déploiements ou les lancer depuis un CI/CD tout en bénéficiant du même comportement conditionné par healthcheck que le panel.