Comprovar un servidor Node amb Docker: port, salut i estat

La web funciona a l’editor, però desapareix quan tanques el terminal. Si un procés Node respon les peticions, comprova’l abans de triar allotjament. Aquesta guia revisa senyals concrets: port, rutes, salut, aturada i estat després de reiniciar.

Fem servir Señal, un exemple original MIT, sense dependències externes, comptes, pagaments ni base de dades. La pàgina llegeix la versió i el temps d’activitat del servidor. Copiar els fitxers a un allotjament estàtic no manté aquest procés actiu.

Fixa la versió i arrenca el procés

Instal·la Node 22.23.3, publicat per Node.js, i comprova que node --version retorna v22.23.3. Conserva la llicència MIT i el 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 utilitza el lockfile i falla si no concorda amb package.json. Aquí no hi ha paquets externs. npm start manté el servidor actiu; no genera dist. Obre http://localhost:8080/ i mantén el terminal obert mentre comproves les respostes des d’un altre.

El codi escolta a 0.0.0.0:8080. PORT permet canviar el port, que ha de coincidir amb el configurat al servei. 0.0.0.0 accepta connexions externes al procés: no és una URL per visitar. L’execució nativa pot permetre accés des de la xarxa local.

Reprodueix la imatge sense publicar-la

Amb un motor Docker ja disponible, atura primer el procés natiu per alliberar 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

El Dockerfile fixa Node 22.23.3 Alpine per digest. Node arrenca directament amb un usuari no root. Aquest mapatge de ports publica 8080 només al loopback de l’ordinador. EXPOSE documenta un port, però no el publica. Aquestes ordres locals no configuren domini ni HTTPS.

Per a aquesta restricció a localhost fes servir Docker Engine 28.0.0 o posterior amb la xarxa bridge predeterminada. Docker adverteix que en versions anteriors altres equips del mateix segment L2 poden accedir als ports publicats a localhost. Comprova la versió del servidor amb docker version; no hem provat cap daemon Docker local. Avís oficial.

Comprova comportaments que puguin fallar

Des d’un altre 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 ha de retornar JSON amb status: ok; /status.json inclou version, bootId, uptimeSeconds i requests. La ruta inexistent i la query no declarada han de retornar 404, sense substituir-les per la portada. Obre també /service.css i /signal.svg: una portada funcional no demostra que els seus actius estiguin disponibles.

Senyal	Què cal revisar
Connexió rebutjada	Procés aturat, port diferent o mapatge absent.
Portada 200, CSS 404	Rutes dels actius o context de la imatge.
Salut 200, funció real falla	L’endpoint comprova aquesta demo, no les dependències de la teva aplicació.
Activitat torna a zero	El procés s’ha reiniciat; revisa també `bootId`.

Tres controls de salut diferents

/healthz és una ruta de l’aplicació. El HEALTHCHECK del Dockerfile executa un helper dins del contenidor. Les probes de Kubernetes es configuren a part: readiness controla el trànsit, liveness els reinicis i startup l’arrencada inicial. El Dockerfile no les configura automàticament.

La nostra prova va executar el helper amb èxit. Això no demostra l’estat health d’un daemon Docker ni probes Kubernetes d’un servei publicat.

Aturada i memòria: comprova el límit

docker stop --timeout 10 hostbrid-service-check

L’exemple gestiona SIGTERM: deixa d’acceptar connexions i espera les peticions actives, amb un límit intern de cinc segons. El test de contenidor va verificar sortida 0 i port tancat enviant SIGTERM al servidor fill del verificador. No valida un rollout ni el lliurament del senyal per Kubernetes a Node com a PID1.

Quan torna a arrencar, bootId canvia i el comptador es reinicia. Activitat i peticions viuen en memòria efímera, no en emmagatzematge persistent. Les sondes també compten com a peticions: no són visitants. Per a dades duradores cal dissenyar i provar emmagatzematge, còpies i recuperació separadament.

Què hem provat i què falta per publicar

El 8 d’octubre de 2026 vam construir una imatge OCI i executar 11 comprovacions en un Job temporal: versió, salut, estat, activitat, actius, 404, aturada i reinici de memòria. Es van netejar el Job i les seves referències pròpies d’imatge. No es va crear cap servei d’allotjament ni demostrar HTTPS públic, OAuth de client o desplegament automàtic després d’un push.

Per portar una aplicació amb procés a Hostbrid Projects, revisa un pla amb serveis inclosos i quota lliure, el Dockerfile a l’arrel, el port i les variables. La quota estàtica no autoritza processos permanents. Consulta el preu actual abans de crear recursos; aquest exemple no demostra serveis gratuïts. Domini, HTTPS, probes i persistència necessiten cadascun una verificació amb la teva aplicació.

Si l’aplicació separa el web, l’API i la base de dades en contenidors diferents, consulta la guia per desplegar Docker Compose en un VPS. Explica una pila de diversos serveis; aquesta pàgina se centra a comprovar un únic procés Node.

Quan el procés ja funciona, compara els recorreguts de desplegament a la guia d’allotjament Node.js: Sites, Projects amb Git i un VPS tenen requisits diferents de domini i operació.