Hébergement Docker : où votre conteneur devrait-il vraiment tourner ?

La vraie question n'est pas le prix

Comparer une facture de VPS avec un abonnement de plateforme, c'est répondre à la mauvaise question. Chaque option peut exécuter votre conteneur ; ce qui diffère, c'est la part d'attention qu'elle continue de vous réclamer après le premier déploiement.

Un conteneur en production a besoin d'un domaine et d'un certificat qui se renouvelle tout seul, d'un moyen de redémarrer en cas de crash, d'un endroit où envoyer les logs, d'une méthode de mise à jour sans interruption, et d'une base de données sauvegardée. Rien de tout cela n'est le travail de Docker. C'est entre les responsables de ces tâches que vous choisissez réellement — et la comparaison honnête met un prix sur vos heures, pas seulement sur le serveur.

Option 1 — un VPS que vous gérez

Louez une machine virtuelle, installez Docker, lancez votre conteneur. C'est la voie la plus directe et elle fonctionne vraiment, avec un accès root complet et aucune abstraction entre vous et la machine.

Ensuite commence le travail permanent : mises à jour de sécurité du système, un reverse proxy devant, des certificats à renouveler, une politique de redémarrage pour la nuit où le conteneur meurt à 4 h du matin, un disque qui se remplit de logs et d'images que personne n'a purgées, et des sauvegardes que vous configurez et — surtout — que vous testez. Un déploiement, c'est votre propre script, et le zéro interruption, c'est quelque chose que vous construisez vous-même.

Choisissez cette voie quand vous voulez le root, quand vous apprenez comment les pièces s'assemblent, ou quand vous exploitez déjà des serveurs et qu'un de plus est marginal. Évitez-la quand votre produit est l'application et non l'infrastructure en dessous.

Option 2 — Kubernetes

Kubernetes résout de vrais problèmes : de nombreux services, des déploiements progressifs, l'auto-réparation, l'autoscaling. Si vous exploitez des dizaines de services au sein d'une équipe, il mérite sa complexité.

En dessous de cette échelle, le rapport s'inverse. Vous maintenez un cluster, ses mises à niveau, son ingress, ses certificats et son YAML pour faire tourner une poignée de conteneurs — et le cluster devient lui-même un système qui exige sa propre expertise. Un Kubernetes managé en enlève une partie, mais pas le poids conceptuel.

Choisissez-le quand votre échelle ou votre équipe l'exigent déjà. Ne le choisissez pas parce que c'est ce qu'utilisent les entreprises sérieuses ; le sérieux consiste à ajuster l'outil à la taille du problème.

Option 3 — une plateforme de conteneurs managée

Ici, vous confiez le conteneur et la plateforme l'exécute : un domaine avec HTTPS automatique, les redémarrages, les logs, un déploiement conditionné par un health check, et du Postgres, du Redis ou du stockage compatible S3 managés, rattachés quand vous en avez besoin.

Sur cdn.com.tr, un déploiement démarre le nouveau conteneur, attend que votre chemin de health check signale qu'il est prêt, puis bascule le trafic et retire l'ancien — ainsi une build cassée ne met jamais le service hors ligne, parce que le trafic reste simplement sur la version qui fonctionne encore. La périphérie CDN se place devant, avec le WAF et la protection DDoS inclus.

Le compromis est réel et mérite d'être dit : pas de root sur l'hôte, pas d'installation de paquets au niveau du système, et l'accès public se fait en HTTP(S) plutôt que sur des ports TCP arbitraires. Si votre application a besoin de quelque chose que la plateforme n'expose pas, un VPS est la réponse honnête.

Trois voies d'entrée, selon ce dont vous disposez

La bonne voie dépend de l'origine de votre image.

Si vous construisez et poussez déjà des images vers un registre, utilisez Container Apps : donnez-lui la référence de l'image et le port, et elle déploie. Rien d'autre ne change dans votre pipeline.

Si vous voulez du push-to-deploy depuis les sources, utilisez GitHub Deploy. Il prend en charge l'étape de build pour vous — votre Dockerfile est construit dans un builder isolé puis poussé vers notre registre privé, aucun compte de registre à vous n'est donc nécessaire. Poussez sur votre branche et la nouvelle version se déploie derrière le health check.

Si votre application regroupe plusieurs services, utilisez Docker Compose Instant Deploy. Les services dotés d'une section build: sont construits à partir de leur Dockerfile ; les services qui référencent une image: publique (bases de données, caches, files d'attente) sont raccordés comme add-ons managés ou comme applications. Les builds multi-étapes, target: et build.args sont pris en compte. Prévisualisez le plan avant que quoi que ce soit ne soit créé, puis appliquez-le.

Prévisualisez ce que deviendrait un fichier compose, puis appliquez-le

# see the plan first — nothing is created
cdnctl container compose preview --account <uuid> --file docker-compose.yml

# apply it when the plan looks right
cdnctl container compose apply --account <uuid> --file docker-compose.yml

Ce qu'il faut vérifier avant de vous engager

Quelle que soit la voie choisie, les questions à poser sont les mêmes. Comment un déploiement se déroule-t-il — une build ratée met-elle le site à terre, ou le trafic reste-t-il sur la dernière version fonctionnelle ? Où vont les logs, et pouvez-vous les lire sans SSH ? Qu'advient-il de vos données : la base est-elle managée et sauvegardée, ou est-ce un conteneur sur un disque dont vous êtes responsable ? Pouvez-vous partir — votre image est-elle portable, ou avez-vous été réécrit dans quelque chose de propriétaire ?

Cette dernière question est celle que l'on saute et que l'on regrette. Une image Docker construite à partir de votre propre Dockerfile est portable par construction : elle s'exécute de la même façon sur un VPS, sur Kubernetes et sur une plateforme managée. La garder ainsi, c'est ce qui rend le choix réversible.