Vérifier un serveur Node avec Docker : port, santé et état

Votre site fonctionne dans l’éditeur, puis disparaît lorsque vous fermez le terminal. Si un processus Node répond aux requêtes, vérifiez-le avant de choisir son hébergement. Cette méthode examine des signaux concrets : port, routes, santé, arrêt et état après redémarrage.

Nous utilisons Señal, un exemple original sous MIT, sans dépendances externes, comptes, paiements ni base de données. Sa page lit la version et la durée d’activité du serveur. Copier les fichiers sur un hébergement statique ne maintient pas ce processus en marche.

Fixer la version et démarrer le processus

Installez Node 22.23.3, publié par Node.js, et vérifiez que node --version renvoie v22.23.3. Conservez la licence MIT et le lockfile.

git clone https://github.com/ocentelles/hostbrid-example-service.git
cd hostbrid-example-service
git checkout dffe40abc37323cb9a84f172f804ed91670e465e
node --version
npm ci
npm run check
npm test
PORT=8080 npm start

npm ci utilise le lockfile et échoue s’il ne correspond pas à package.json. Cet exemple n’a aucun paquet externe. npm start maintient un serveur actif ; il ne génère pas dist. Ouvrez http://localhost:8080/ et gardez le terminal ouvert pendant les vérifications depuis un autre terminal.

Le code écoute sur 0.0.0.0:8080. PORT permet de changer le port, qui doit correspondre à la configuration du service. 0.0.0.0 accepte les connexions extérieures au processus : ce n’est pas une URL à visiter. L’exécution native peut permettre un accès depuis votre réseau local.

Reproduire l’image sans exposition publique

Avec un moteur Docker déjà disponible, arrêtez d’abord le processus natif pour libérer 8080 :

docker build -t hostbrid-service-check:dffe40a .
docker run --rm --name hostbrid-service-check -e PORT=8080 \
  -p 127.0.0.1:8080:8080 hostbrid-service-check:dffe40a

Le Dockerfile fixe Node 22.23.3 Alpine par digest. Node démarre directement avec un utilisateur non root. Ce mappage de ports publie 8080 seulement sur l’interface loopback de l’ordinateur. EXPOSE documente un port sans le publier. Ces commandes locales ne configurent ni domaine ni HTTPS.

Pour cette restriction à localhost, utilisez Docker Engine 28.0.0 ou ultérieur avec le réseau bridge par défaut. Docker avertit que, sur les anciennes versions, d’autres machines du même segment L2 peuvent atteindre les ports publiés sur localhost. Vérifiez la version du serveur avec docker version ; nous n’avons pas testé de daemon Docker local. Avertissement officiel.

Vérifier des comportements qui peuvent échouer

Depuis un autre terminal :

curl -fsS http://127.0.0.1:8080/healthz
curl -fsS http://127.0.0.1:8080/status.json
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/missing
curl -s -o /dev/null -w '%{http_code}\n' 'http://127.0.0.1:8080/healthz?check=1'

/healthz doit renvoyer un JSON avec status: ok ; /status.json contient version, bootId, uptimeSeconds et requests. La route absente et la query non déclarée doivent renvoyer 404, sans remplacer la réponse par l’accueil. Ouvrez aussi /service.css et /signal.svg : un accueil fonctionnel ne prouve pas la disponibilité des fichiers associés.

Trois contrôles de santé distincts

/healthz est une route applicative. Le HEALTHCHECK du Dockerfile exécute un helper dans le conteneur. Les probes Kubernetes se configurent séparément : readiness contrôle le trafic, liveness les redémarrages et startup le démarrage initial. Le Dockerfile ne les configure pas automatiquement.

Notre test a exécuté le helper avec succès. Cela ne prouve ni l’état health d’un daemon Docker ni les probes Kubernetes d’un service publié.

Arrêt et mémoire : vérifier la limite

docker stop --timeout 10 hostbrid-service-check

L’exemple traite SIGTERM en arrêtant les nouvelles connexions et en attendant les requêtes actives, avec une limite interne de cinq secondes. Le test conteneur a vérifié une sortie 0 et la fermeture du port en envoyant SIGTERM au serveur enfant du vérificateur. Il ne valide ni rollout ni signal envoyé par Kubernetes à Node en PID1.

Au redémarrage, bootId change et le compteur repart de zéro. Activité et requêtes résident en mémoire éphémère, sans stockage persistant. Les sondes comptent aussi comme requêtes : ce ne sont pas des visiteurs. Des données durables nécessitent stockage, sauvegardes et restauration conçus et testés séparément.

Preuve obtenue et conditions avant publication

Le 8 octobre 2026, nous avons construit une image OCI et exécuté 11 vérifications dans un Job temporaire : version, santé, état, activité, fichiers, 404, arrêt et remise à zéro de la mémoire. Le Job et ses propres références d’image ont été nettoyés. Aucun service d’hébergement n’a été créé ; HTTPS public, OAuth client et déploiement automatique après push n’ont pas été démontrés.

Pour une application avec processus sur Hostbrid Projects, vérifiez un plan incluant des services et un quota disponible, le Dockerfile à la racine, le port et les variables. Le quota statique n’autorise pas les processus permanents. Consultez le tarif actuel avant de créer des ressources ; cet exemple ne démontre pas de services gratuits. Domaine, HTTPS, probes et persistance doivent chacun être vérifiés avec votre application.

Si votre application sépare le site, l’API et la base de données dans plusieurs conteneurs, consultez le guide de déploiement Docker Compose sur VPS. Il traite d’une pile multi-services ; cette page vérifie un seul processus Node.

Une fois le processus testé, comparez les parcours dans le guide d’hébergement Node.js : Sites, Projects avec Git et un VPS impliquent des exigences différentes pour le domaine et l’exploitation.