Comment déployer Docker sans gérer un serveur

docker build fonctionne. docker run -p 3000:3000 myapp fonctionne sur votre ordinateur. Ce qui n’existe pas encore, c’est tout ce qui se trouve entre « ce conteneur tourne » et « c’est un service en production » : un proxy inverse devant lui, un certificat qui se renouvelle de lui-même, un processus qui redémarre après un crash, un serveur dont le système d’exploitation est corrigé, et quelqu’un ou quelque chose qui surveille si c’est vraiment en ligne. Rien de tout ça n’est spécifique à votre application. Tout ça est spécifique au fait de faire tourner un serveur, ce qui est la partie que beaucoup de gens avec un Dockerfile qui fonctionne préféreraient ne pas apprendre à partir de zéro.

Ce guide s’adresse à cette situation : vous avez un Dockerfile, il construit, et vous voulez que ça tourne en production sans devenir la personne qui maintient une machine Linux. Il couvre ce que « gérer un serveur » implique vraiment, la version manuelle de le faire soi-même (en bref, ce n’est pas le but), puis le chemin qui l’élimine.

Ce que « gérer un serveur » veut vraiment dire

Chacun de ces points est un petit problème bien compris en soi. Ensemble, pour un seul conteneur, ça représente une quantité de travail continu disproportionnée :

• Les mises à jour du système. Les correctifs de sécurité pour l’installation Ubuntu ou Debian elle-même, indépendamment de tout ce qu’il y a dans votre Dockerfile, doivent être appliqués selon un certain rythme, et certains nécessitent un redémarrage pour prendre effet.
• Installer et maintenir Docker. Le moteur Docker sur l’hôte est un logiciel à part entière avec son propre chemin de mise à jour, séparé de n’importe quelle image que vous faites tourner par-dessus.
• Un proxy inverse. Quelque chose doit terminer le HTTPS et rediriger les requêtes vers le port de votre conteneur ; c’est une configuration nginx ou Caddy, écrite et gardée synchronisée avec votre application à la main.
• Le renouvellement du certificat. Les certificats Let’s Encrypt expirent tous les 90 jours. Quelque chose doit demander le premier, prouver la propriété du domaine, et le renouveler avant qu’il n’expire, indéfiniment, sans que personne n’ait à s’en souvenir.
• La surveillance. Savoir que le conteneur sert réellement du trafic, pas juste que docker ps le montre en cours d’exécution, demande quelque chose qui vérifie depuis l’extérieur de la machine.
• La politique de redémarrage et les règles de pare-feu. Un crash doit ramener le processus sans qu’un humain se connecte en SSH, et la machine ne doit avoir ouverts vers Internet que les ports qu’elle sert réellement.

Rien de tout ça n’est difficile isolément. C’est le genre de travail qui est invisible jusqu’à la semaine où il ne l’est plus : un certificat expire en silence, une CVE non corrigée reste ouverte pendant des mois, ou un crash à 2 h du matin reste simplement planté.

La version manuelle, en bref

Sur un VPS Ubuntu 24.04, c’est Docker plus Caddy comme proxy inverse :

curl -fsSL https://get.docker.com | sh

Un Caddyfile devant le conteneur :

myapp.example.com {
	reverse_proxy localhost:3000
}

docker run -d --name myapp --restart unless-stopped -p 3000:3000 --env-file .env myapp:latest
caddy run --config Caddyfile

Caddy demande et renouvelle automatiquement son propre certificat Let’s Encrypt une fois que le DNS pointe vers le serveur et que les ports 80/443 sont accessibles, ce qui couvre le renouvellement du certificat. --restart unless-stopped couvre la partie récupération après crash. Ce qui reste, et que cette version courte ne règle pas, c’est tout ce qui dans la liste ci-dessus n’est pas le conteneur lui-même : les correctifs système selon un calendrier, les mises à jour de Docker lui-même, les règles ufw gardées synchronisées avec ce qui tourne réellement, et quelque chose d’externe qui vérifie que le site est vraiment accessible, rien de tout ça ne vient du simple fait de faire tourner Caddy et Docker correctement.

Le chemin qui s’occupe du reste

Pointez Railyard vers le même dépôt, ou vers une image déjà existante. La détection de build de Railyard choisit un Dockerfile automatiquement quand le dépôt en a un qui construit vraiment l’application ; une image de développement qui attend seulement un montage lié est ignorée plutôt que déployée ; voir les méthodes de build. Pour une image déjà dans un registre plutôt que dans un dépôt, image://ghcr.io/you/myapp:latest comme source fonctionne de la même façon, et le port que votre Dockerfile EXPOSE est lu directement depuis le registre, sans configuration manuelle de port ; voir déployer une image Docker.

Ce que cette seule étape remplace vraiment, face à la liste manuelle ci-dessus :

• Le proxy inverse et le certificat TLS ne sont pas quelque chose que vous écrivez. Chaque application reçoit immédiatement https://<name>.<server-ip>.sslip.io avec un certificat ; pointer votre propre domaine ajoute un enregistrement DNS et une vérification de propriété (un enregistrement TXT que Railyard vérifie avant d’émettre quoi que ce soit, pour que personne ne puisse pointer un domaine qu’il ne contrôle pas vers votre application), et le certificat à partir de là est automatique. Voir domaines et HTTPS.
• Les mises à jour du système apparaissent sur la page du serveur lui-même, avec un compte des mises à jour en attente et combien sont spécifiquement de sécurité ; les mises à jour de sécurité nocturnes s’appliquent sans intervention, et rien ne redémarre la machine sans que vous ne le choisissiez. Voir maintenance du serveur.
• La politique de redémarrage n’est pas un drapeau qu’il faut penser à ajouter. C’est juste la façon dont tourne le conteneur de chaque application.
• Les déploiements eux-mêmes ne causent pas d’interruption : une nouvelle image est récupérée ou construite, la commande de release (si vous en avez défini une) s’exécute, et le trafic ne bascule vers elle qu’une fois que le nouveau conteneur répond vraiment, la même forme sans interruption que l’image ait changé ou que le code ait changé.
• Une image basée sur un registre qui se met à jour toute seule peut se redéployer automatiquement : activez Deploy when the tag changes dans Settings → Source, et Railyard vérifie le registre toutes les cinq minutes (ou instantanément, via un webhook que vous ajoutez au registre) et redéploie quand le digest bouge, donc un docker push d’un nouveau latest devient tout le processus de mise en production. Voir déployer une image Docker.

Une chose qui mérite d’être précisée : Railyard n’est pas une plateforme de conteneurs serverless qui possède le matériel à votre place. Vous ajoutez quand même un serveur, soit un que Railyard crée sur votre compte DigitalOcean, Hetzner, Vultr, AWS ou OVH, soit n’importe quelle machine Ubuntu 22.04/24.04 à laquelle vous avez déjà accès en SSH, et c’est votre fournisseur cloud qui vous facture directement pour la machine elle-même. Voir ajouter un serveur. Ce qui disparaît, c’est tout ce qui se trouve par-dessus le fait de posséder cette machine : installer Docker dessus, écrire et maintenir la configuration du proxy inverse, demander et renouveler les certificats, et corriger le système à la main.

Variables et secrets

Quoi que votre conteneur lise depuis son environnement, définissez-le sous l’onglet Variables de l’application ; les valeurs sont chiffrées et appliquées au prochain déploiement. Si votre image a besoin d’un identifiant qui doit vraiment être un fichier plutôt qu’une variable (un JSON de compte de service, un certificat client), Variables → File secrets le monte en lecture seule dans le conteneur et expose son chemin comme variable d’environnement, pour que GOOGLE_APPLICATION_CREDENTIALS=${RAILYARD_SECRET_FILE_GCP_KEY_JSON} se résolve sans copie manuelle de fichier vers le serveur. Voir variables et secrets.

Dépannage

Le déploiement réussit mais l’application n’apparaît jamais sur le domaine. Vérifiez le statut du domaine dans l’onglet Domains de l’application : unverified veut dire que l’enregistrement TXT de propriété n’est pas encore trouvé (propagation DNS, ou faute de frappe dans l’enregistrement), misconfigured veut dire que l’émission du certificat a échoué et la carte explique pourquoi, et unrouted veut dire que le domaine a été vérifié mais que l’application n’a pas redéployé depuis, ce qu’un redéploiement corrige.

Un Dockerfile qui fonctionne en local échoue à la construction. L’écart le plus courant entre un build local et un build Railyard est une image qui suppose un répertoire source monté par lien plutôt que de COPY-er l’application dans l’image ; c’est exactement ce schéma que la détection de build de Railyard traite comme une image de développement et ignore. Confirmez que le Dockerfile construit une image autonome avec docker build . et sans drapeau -v avant d’aller plus loin dans le dépannage.

La construction manque de mémoire. Les grosses constructions sont ajustées automatiquement sur un serveur de build temporaire et plus grand quand le fournisseur le permet, donc c’est rare, mais quand ça arrive, la page de déploiement le dit directement et suggère la prochaine étape plutôt que d’échouer en silence.

FAQ

Dois-je quand même connaître Docker ? Oui, dans le sens où vous écrivez toujours le Dockerfile ; ce que ça élimine, c’est tout ce qui vient après une image qui fonctionne, pas l’image elle-même. Si votre Dockerfile construit et tourne déjà en local, cette partie du travail est faite.

Est-ce la même chose qu’une plateforme de conteneurs serverless comme Cloud Run ? Non. Ces plateformes font tourner votre conteneur sur une infrastructure qu’elles possèdent et vous facturent par requête ou par seconde de calcul. Railyard le fait tourner sur un serveur que vous ajoutez à votre propre compte cloud (ou une machine que vous avez déjà), facturé par votre fournisseur, et automatise ce qu’implique le fait de gérer un serveur par-dessus cette machine.

Et si mon image a besoin de plus d’un port, comme un point de terminaison de métriques à côté de l’application principale ? Settings → General → More public ports accepte des paires nom:port supplémentaires, chacune recevant sa propre adresse HTTPS et son propre certificat de la même façon que l’adresse principale ; voir réseautage.

Mon conteneur doit-il tourner en root ? Non, et c’est mieux s’il ne le fait pas ; c’est une propriété de votre propre Dockerfile, pas quelque chose que Railyard exige dans un sens ou dans l’autre. Un réglage Hardened isolation, distinct et optionnel, sous Settings → General, restreint davantage ce qu’un conteneur peut atteindre sur un serveur partagé avec d’autres applications, à tester avec une image qui ne suppose pas root.

Que se passe-t-il exactement à chaque déploiement, étape par étape ? L’image est récupérée ou construite, toute commande de release que vous avez définie s’exécute contre elle, et ce n’est qu’une fois que le nouveau conteneur répond que le trafic bascule vers lui ; l’ancien conteneur reste actif jusqu’à ce que ce transfert réussisse, pour qu’un mauvais déploiement n’emporte pas la version précédente qui fonctionnait.

Le Dockerfile n’a jamais été la partie difficile. Tout ce qui vient après, le fait que la machine sur laquelle il tourne reste corrigée, que le certificat reste valide, et que le processus revienne après un crash, voilà ce que « gérer un serveur » veut dire en pratique, et c’est aussi la partie qui n’a rien à voir avec ce que fait réellement votre conteneur.