Comment déployer un conteneur Docker dans le cloud ?

On arrive au moment que cette série prépare depuis le début. Vous savez construire une image Docker, vous savez la pousser sur un registry, vous savez même le faire automatiquement depuis GitHub Actions.

Et dans la fiche précédente, on a vu qu’un service managé de conteneurs occupait une place bien à lui : vous livrez une image, le fournisseur s’occupe de la machine qui la fait tourner.

Il reste donc une seule chose à faire, et c’est celle dont on n’a jamais parlé : faire tourner cette image quelque part.

Cette fiche déroule le chemin complet. Elle reste volontairement indépendante du fournisseur : les noms changent d’un service à l’autre, les six étapes, non.

---

Le point de départ : une image, pas un dépôt

Une précision qui évite beaucoup de confusion. Un service managé de conteneurs ne va pas chercher votre code source. Il va chercher une image, déjà construite, déjà rangée sur un registry.

Ça change deux choses par rapport à un hébergement classique :

• la construction se fait ailleurs, typiquement dans votre CI. Le cloud ne compile rien, il exécute ;
• ce que vous déployez est exactement ce que vous avez testé, à la version près, puisque c’est le même artefact qui passe de la CI au registry puis au service.

Un mot sur l’étiquette, tant qu’on y est. Évitez latest en production. Elle ne dit pas ce qui tourne, elle rend les retours arrière pénibles et elle transforme chaque redémarrage en surprise. Une étiquette de version — un numéro, ou le hachage du commit — coûte une ligne dans votre workflow et vous fait gagner des soirées entières.

---

Étape 1 : Publier l’image sur un registry

Le registry doit être joignable depuis le service cloud. Deux options, et le choix est plus structurant qu’il n’en a l’air.

Le registry du fournisseur — celui intégré à la plateforme où vous déployez. C’est le chemin le plus court : l’authentification est souvent implicite, le transfert reste interne, et il ne vous est donc pas facturé en sortie de données.

Un registry externe, celui de votre forge par exemple. Plus pratique si vous déployez chez plusieurs fournisseurs, mais chaque récupération d’image traverse Internet, avec l’authentification et la latence que ça suppose.

Si vous avez déjà mis en place le workflow de la fiche sur le déploiement d’images depuis GitHub Actions, vous êtes déjà à cette étape sans rien changer : il ne reste qu’à donner la main au cloud sur ce registry.

---

Étape 2 : Autoriser le service à lire l’image

C’est l’étape qu’on oublie, et c’est de loin la cause numéro un des premiers déploiements qui échouent. Le service doit avoir le droit de lire votre image. Un dépôt privé sans autorisation, ça donne un conteneur qui ne démarre jamais et un message d’erreur qui parle de pull access denied.

Trois principes qui vous éviteront d’y revenir :

• un compte de service dédié, jamais vos identifiants personnels. Le jour où vous partez en vacances ou changez de mot de passe, la production ne doit pas s’arrêter avec vous ;
• en lecture seule. Le service qui exécute n’a aucune raison de pouvoir pousser une image ;
• rangé dans le gestionnaire de secrets du fournisseur, pas dans une variable d’environnement en clair.

Ces réflexes sont exactement ceux de la fiche sur la gestion des secrets dans GitHub Actions, appliqués de l’autre côté de la chaîne.

---

Étape 3 : Créer le service à partir de l’image

C’est le cœur de l’affaire, et c’est étonnamment court. Vous donnez au fournisseur l’adresse complète de l’image, les ressources allouées et le port exposé.

Sur les ressources, un ordre de grandeur utile : partez petit. Une application web classique démarre très bien avec un demi-processeur virtuel et 512 Mo de mémoire. Vous augmenterez au vu des mesures, ce qui est infiniment plus fiable que d’estimer à l’avance — et ça évite de payer pendant six mois une machine dimensionnée pour un trafic qui n’est jamais venu.

Sur le port, une règle simple et deux erreurs classiques. La règle : l’application doit écouter sur l’interface 0.0.0.0, pas sur 127.0.0.1. Un service qui n’écoute que sur la boucle locale est injoignable depuis l’extérieur du conteneur, et c’est le genre de détail qui ne se voit pas en local.

Les deux erreurs :

• déclarer un port différent de celui sur lequel l’application écoute vraiment. Le EXPOSE du Dockerfile est documentaire, il n’ouvre rien : ce qui compte, c’est ce que dit votre code ;
• coder le port en dur. Beaucoup de services managés imposent leur propre port par une variable d’environnement. Lire cette variable avec une valeur de repli est une habitude qui rend votre image portable partout.

---

Étape 4 : Déclarer les variables d’environnement

En local, votre fichier .env remplit ce rôle et vous n’y pensez plus. Dans le cloud, il n’existe pas — et c’est très bien, il n’a jamais eu vocation à être déployé.

Reprenez-le ligne par ligne et rangez chaque valeur dans l’une des deux catégories :

• la configuration ordinaire — niveau de journalisation, nom de l’environnement, adresse d’un service tiers. Elle va dans les variables d’environnement du service, elle est lisible dans la console, ce n’est pas un problème ;
• les secrets — mots de passe de base, clés d’API, jetons. Ils vont dans le gestionnaire de secrets du fournisseur, qui les injecte au démarrage sans jamais les afficher.

Deux points de vigilance pendant qu’on y est. Une variable oubliée ne se voit souvent qu’au premier appel, pas au démarrage : l’application se lance tranquillement et casse à la première requête qui touche la base. Et changer une variable impose de redéployer : le conteneur lit son environnement au démarrage, il ne le relit jamais ensuite.

---

Étape 5 : Brancher un healthcheck

Sans healthcheck, le service sait seulement que votre processus est lancé. Ce n’est pas la même chose que prêt à répondre, et cette nuance coûte cher au moment précis où on la découvre : pendant un déploiement.

Exposez une route dédiée — /health fait très bien l’affaire — qui répond un code 200 quand l’application est réellement opérationnelle. Trois qualités pour une bonne route de santé :

• rapide, quelques millisecondes, parce qu’elle sera appelée sans arrêt ;
• honnête : si l’application ne sait pas fonctionner sans sa base, la route doit vérifier que la base répond ;
• silencieuse dans les journaux, sous peine de noyer tout le reste.

Ce que vous y gagnez concrètement : le fournisseur n’envoie du trafic sur une nouvelle version qu’une fois qu’elle a répondu vert, et il redémarre tout seul un conteneur qui part en vrille. C’est la différence entre un déploiement sans coupure et une minute d’erreurs 502 à chaque mise en production.

---

Étape 6 : Vérifier, puis borner la mise à l’échelle

Le premier démarrage se lit dans les journaux, et il faut vraiment prendre les deux minutes nécessaires. C’est là que se voient la variable manquante, le port mal déclaré et le droit de lecture oublié.

Une fois que ça tourne, il reste un réglage à ne pas remettre à plus tard : les bornes de la mise à l’échelle.

Le nombre minimum d’instances arbitre entre coût et réactivité. À zéro, vous ne payez rien quand personne ne vient, mais le premier visiteur attend le démarrage à froid — quelques secondes, parfois plus. C’est parfait pour un environnement de test, discutable pour une page vue par des clients.

Le nombre maximum, lui, est votre garde-fou de facture. Sans plafond, une montée de trafic — un article qui marche, un robot un peu vif, une boucle dans votre propre code — se traduit directement en euros. Mettez un plafond dès le premier déploiement, même large. C’est le même réflexe que l’alerte de budget dont on parlait dans la fiche sur le cloud public.

---

Astuce bonus : Service managé ou orchestrateur ?

La question tombe toujours à ce moment-là : et Kubernetes dans tout ça ? Ou Docker Swarm, dont on a déjà parlé ?

La différence tient en une phrase. Un service managé fait tourner vos conteneurs, un orchestrateur vous donne les outils pour les faire tourner vous-même. Dans le premier cas, la couche de pilotage appartient au fournisseur et ne vous demande rien. Dans le second, elle est à vous : à configurer, à mettre à jour, à dépanner.

L’orchestrateur devient intéressant quand vous avez beaucoup de services qui se parlent, des besoins de placement fins, ou l’intention de rester portable entre plusieurs fournisseurs. En dessous d’une dizaine de services, il apporte surtout de la complexité.

Mon conseil, et il vaut pour toute cette série : commencez par le service managé. Votre image ne change pas, votre Dockerfile non plus — donc le jour où l’orchestrateur devient justifié, la migration porte sur l’exploitation, pas sur votre application. C’est très exactement ce que le conteneur vous a fait gagner.

---

Et voilà, votre image tourne ! Pour résumer en une phrase : déployer un conteneur dans le cloud, c’est publier une image, donner au service le droit de la lire, lui décrire son port et ses variables, puis lui apprendre à savoir si elle va bien.

Cette fiche ferme la boucle ouverte il y a plusieurs mois avec Docker. Elle reste volontairement sans fournisseur, alors la suivante déroule exactement ces six étapes en ligne de commande, chez Scaleway. De quoi voir à quoi ressemble chacune une fois qu’elle porte un nom.

Après quoi on quittera la technique pour les deux questions qu’on se pose juste avant de signer : est-ce que le cloud coûte vraiment moins cher et ce que veut dire « souverain ». Restez dans le coin 😉.

D’ici là, je vous invite :

• à relire la fiche sur IaaS, PaaS et SaaS pour situer ce service managé dans la pile ;
• à (re)commencer le cours sur les GitHub Actions si la partie construction de l’image est encore manuelle chez vous.

Ressources

• Best practices for building containers (Google Cloud)
• Amazon ECS, la documentation d’AWS
• La référence du Dockerfile (Docker)
• Le glossaire Cloud Native de la CNCF, en français