Déployer un conteneur Docker sur le CDN et le diffuser depuis la périphérie

Ce que signifie « Docker sur le CDN »

Un CDN sous sa forme classique se place devant un site web que vous exploitez déjà : la périphérie met en cache votre origine statique et l'accélère. C'est le mode Pull, et il est parfait quand vous avez déjà un serveur quelque part. Mais si ce que vous avez, c'est une image Docker — une API backend, une application web, un worker — il vous faudrait quand même une machine pour réellement exécuter ce conteneur. C'est exactement le manque que comble la plateforme de conteneurs managés.

Sur cdn.com.tr, vous déployez directement l'image Docker. La plateforme exécute votre conteneur comme une managed container app et le place derrière la périphérie CDN, si bien que la même image qui tourne sur votre ordinateur avec docker run est désormais diffusée sur un vrai domaine avec HTTPS automatique, mise en cache à la périphérie et un WAF devant — sans que vous ayez à provisionner une VM, installer Docker, câbler du TLS ou monter un reverse proxy. Vous apportez une image et un port ; la plateforme se charge de l'exécuter et de la diffuser mondialement. C'est ce qu'on entend par « Docker sur un CDN » ou « docker hosting » façon managée : le conteneur est l'origine, et la périphérie le délivre.

Option A — déployer depuis le panneau (sans CLI)

La voie sans code se déroule entièrement dans le panneau de gestion cdn.com.tr. Sous CDN Hosting / Platforms, choisissez Managed Container et créez une application à partir de votre image. Vous pointez vers une image de registre et un tag (par exemple registry.example.com/acme/app:1.0.0), vous définissez le port sur lequel votre conteneur écoute (disons 8080), et vous ajoutez un chemin de health check pour que la plateforme sache quand le conteneur est réellement prêt (un chemin HTTP comme /health, un check TCP, ou aucun). Ajoutez le domaine personnalisé sur lequel vous voulez le diffuser, et si l'image vit dans un registre privé, attachez les identifiants de registre enregistrés précédemment.

Cliquez ensuite sur Deploy. La plateforme récupère l'image, démarre le conteneur, attend que le health check passe, puis le met en ligne derrière la périphérie. Depuis la vue Operations de l'application, vous pouvez suivre la progression du déploiement, tailer les logs, voir le statut et les révisions, et redémarrer ou revenir en arrière — sans jamais toucher à un terminal. C'est la bonne voie quand vous voulez tout voir visuellement ou que vous déployez un seul conteneur à la main.

Option B — la CLI cdnctl

cdnctl est l'outil en ligne de commande pour opérer cdn.com.tr, et il pilote la même plateforme. Connectez-vous une fois et choisissez votre compte pour que chaque commande sache où travailler : lancez cdnctl login --email you@example.com --password ... (ou cdnctl configure --endpoint https://cdn.com.tr --token <token> si vous utilisez un jeton API), puis cdnctl accounts use <account_uuid>. Avant votre premier déploiement, cdnctl container preflight --account <uuid> vérifie que le compte est prêt.

Créez et déployez le conteneur en deux étapes. D'abord, définissez-le : cdnctl container apps create --account <uuid> --name mobile-backend --image registry.example.com/acme/app --tag 1.0.0 --port 8080 --healthcheck /health --healthcheck-type http --domain api.example.com (ajoutez --registry-credential <uuid> pour une image privée, et --persistent-mount-path /app/data --persistent-storage-gb 5 si elle a besoin d'un volume persistant). Puis expédiez-le : cdnctl container apps deploy --account <uuid> --app <app_uuid>. Pour obtenir une prévisualisation instantanée sans configurer de DNS, cdnctl container apps expose --account <uuid> --app <app_uuid> crée une URL immuable <uid>.cdn.com.tr que vous pouvez appeler tout de suite.

L'exploitation au quotidien se fait aussi entièrement ici : apps logs --tail 100 pour tailer la sortie, apps status et apps wait --status running --timeout 300 pour vérifier que c'est prêt, apps restart, apps scale --replicas 0 pour mettre en pause (ou remonter en charge), apps show pour voir l'application et ses révisions, apps rollback --revision <uuid> pour revenir à une version connue et stable, apps diagnose quand quelque chose ne va pas, et apps update ... --env-json '{"APP_URL":"https://api.example.com"}' pour modifier la configuration. Pour les images privées, créez l'identifiant une fois avec cdnctl container registry-credentials create --account <uuid> --name docker --registry-url https://index.docker.io/v1/ --username <user> --password <token> et référencez-le lors de la création de l'application.

Stacks multi-services, add-ons, jobs et données

Une application réelle est rarement un seul conteneur. Si vous décrivez déjà votre stack avec docker-compose, vous pouvez déployer le tout : cdnctl container compose preview --account <uuid> --file docker-compose.yml montre ce qui sera créé, et cdnctl container compose apply --account <uuid> --file docker-compose.yml --yes déploie la stack multi-services. Votre fichier compose devient des managed container apps sur la plateforme.

Pour les briques dont votre application dépend, liez des add-ons managés plutôt que de les exécuter vous-même : cdnctl container addons enable-redis, enable-postgres, enable-database ou enable-nats provisionnent le service et injectent ses informations de connexion dans votre application sous forme de variables d'environnement (utilisez --env-prefix pour contrôler leurs noms). Le travail en arrière-plan et planifié est couvert par les jobs : cdnctl container jobs create --account <uuid> --app <app_uuid> --name sync --schedule "*/30 * * * *" --method POST --path "/run" enregistre un job de type cron qui appelle votre application selon un planning, et jobs run [--wait] le déclenche à la demande. Et pour amorcer l'état, cdnctl container imports database --file dump.sql.gz charge un dump SQL, tandis que cdnctl container imports files --file data.tar.gz --target-path /app/data décompresse des fichiers dans un volume persistant.

Diffusion depuis la périphérie CDN

L'intérêt d'exécuter votre conteneur ici plutôt que sur une VM nue tient à ce qui se trouve devant lui. Une fois déployée, votre application est accessible sur le domaine personnalisé que vous avez attaché, diffusée depuis la périphérie CDN. Le TLS est automatique — vous obtenez du HTTPS sans certificat à acheter, installer ou renouveler — et les réponses cachables sont mises en cache à la périphérie, près de vos visiteurs, si bien que votre conteneur travaille moins et que les utilisateurs obtiennent des réponses plus rapides. Un WAF se trouve devant pour filtrer le trafic malveillant et absorber les attaques avant qu'elles n'atteignent votre conteneur.

Vous n'avez pas besoin d'un domaine personnalisé pour commencer à tester. cdnctl container apps expose (ou la même action dans le panneau) vous donne une URL immuable <uid>.cdn.com.tr qui diffuse votre conteneur en cours d'exécution immédiatement — idéal pour une prévisualisation, une démo, ou pour connecter un client mobile à un backend avant que le DNS ne soit prêt. Quand vous êtes prêt pour la production, pointez votre vrai domaine vers l'application et elle sera diffusée dessus à la place, avec le même HTTPS automatique et la même protection en périphérie.

Déployer depuis Git — CI/CD et promotions sans interruption

Pour un projet qui vit dans la durée, vous ne voulez généralement pas lancer une commande de déploiement à la main à chaque fois. Connectez un dépôt dans le panneau et les push peuvent auto-déployer : quand vous poussez, la plateforme construit et redéploie automatiquement, si bien qu'expédier un changement se résume à git push. C'est la voie CI/CD pour les conteneurs sur le CDN.

Pour garder la production en sécurité, les déploiements passent par un pipeline staging → production. Un push redéploie d'abord votre environnement Staging, où vous pouvez vérifier la nouvelle version sur une URL de prévisualisation ; quand elle est correcte, un seul Promote manuel bascule instantanément cette build en Production. Comme le promote est une bascule instantanée d'une release déjà construite et déjà chaude, la production change de version sans interruption — pas de reconstruction, pas de cold start pour vos visiteurs. cdnctl s'intègre au même flux depuis un pipeline CI : authentifiez-vous avec un jeton, puis créez/déployez l'application comme étape de build, si bien que votre CI GitHub ou GitLab existante peut aussi piloter les déploiements.

Ce que les gens exécutent comme conteneurs Docker sur le CDN