Node.js aplikāciju kontenerizācija uzņēmumiem

Docker ir standarizējis aplikāciju izvietošanu — 90%+ jaunu uzņēmumu izvietojumu izmanto konteinerus. Node.js konteineri prasa specifiskas prakses, lai sasniegtu ražošanas līmeņa efektivitāti, drošību un uzticamību.

Dockerfile labākās prakses

Daudzpakāpju būvēšana (Multi-stage builds)

Daudzpakāpju būvēšana ir kritiska Node.js konteineru optimizācijai. Principi:

• Pirmā pakāpe (build) — pilns Node.js attēls ar visām build atkarībām (TypeScript compiler, dev dependencies). Kompilē TypeScript, veic bundling
• Otrā pakāpe (production) — minimāls alpine attēls ar TIKAI production atkarībām un kompilētu kodu. Bez devDependencies, bez TypeScript avotfailiem
• Rezultāts — gala attēls var būt 10–20x mazāks nekā vienpakāpes attēls (no ~1.2GB uz ~150MB)

Piemērs struktūrai: Stage 1: FROM node:22-alpine AS builder → COPY → npm ci → npm run build Stage 2: FROM node:22-alpine → COPY --from=builder /app/dist → npm ci --production → CMD

Slāņu optimizācija un kešošana

Docker būvē slāņus secīgi — ja slānis nav mainījies, tas tiek kešots. Optimizācijas stratēģija:

1. package.json un package-lock.json PIRMS pārējā koda — atkarību instalācija kešojas, kamēr tie nemainās
2. COPY . . tikai PĒC npm ci — avotkodam mainoties, atkarības netiek pārinstalētas
3. .dockerignore — izslēdziet node_modules, .git, .env, tests, docs. Samazina build kontekstu un paātrina būvēšanu
4. npm ci (nevis npm install) — precīza reproducibility no lock faila, tīra instalācija

Attēla izmēra samazināšana

• Alpine bāze — node:22-alpine (~50MB vs node:22 ~350MB). Ātrāka lejupielāde, mazāks uzbrukuma laukums
• Distroless (Google) — vēl mazāks, bet bez shell (grūtāk debugot). Ideāls producijā
• Slim variants — node:22-slim kompromiss starp pilno un alpine
• Tīrīšana — npm cache clean --force build pakāpē, noņemiet nevajadzīgos failus

Drošības apsvērumi — konteineru pastiprināšana

Minimāls pamatattēls

Mazāks attēls = mazāks uzbrukuma laukums. Alpine: ~50 CVE vs Full attēls: ~300+ CVE vidēji. Regulāri atjauniniet bāzes attēlu — vismaz reizi nedēļā pārbūvējiet ar jaunāko alpine/node versiju.

Non-root lietotājs

NEKAD nedarbiniet Node.js kā root konteinerā — kompromitēts process iegūst pilnu piekļuvi: RUN addgroup -g 1001 nodejs && adduser -S -u 1001 -G nodejs appuser USER appuser Arī failu atļaujas: COPY --chown=appuser:nodejs

Read-only failu sistēma

Darbiniet konteineru ar --read-only flag. Pierakstāmie direktoriji kā volume: /tmp, /app/logs. Novērš malware failu rakstīšanu konteinerā.

Noslēpumu drošība

NEKAD neiekļaujiet .env, API atslēgas vai sertifikātus Docker attēlā:

• docker history parāda VISAS slāņu komandas (arī ENV un ARG vērtības)
• Risinājumi: Docker Secrets (Swarm), Kubernetes Secrets, runtime vides mainīgie (--env-file), Vault agent sidecar
• BuildKit --mount=type=secret build laikā — noslēpums nav redzams gala attēlā

Attēlu skenēšana

• Trivy — ievainojamību skenēšana CI pipeline (bezmaksas, ātrs)
• Snyk Container — detalizēts CVE ziņojums ar labojumu ieteikumiem
• Docker Scout — integrēts Docker Desktop, policy compliance

.dockerignore — būtisks fails

Izslēdziet no build konteksta: node_modules, .git, .env*, *.md, tests/, coverage/, .nyc_output, .vscode, docker-compose*.yml, Dockerfile Rezultāts: ātrāks build, mazāks konteksts, drošāks (sensitīvi faili nenonāk attēlā pat nejauši).

Orkestrācija — no izstrādes līdz produkcijai

Docker Compose — izstrādes vide

Lokāla multi-servisu vide: app + PostgreSQL + Redis + MinIO. docker-compose.yml definē visus servisus, tīklus, volumes. Visi izstrādātāji saņem identisku vidi ar vienu komandu.

Labas prakses:

• Volumes avotkodam (hot reload izstrādē): ./src:/app/src
• Healthchecks katram servisam: depends_on ar condition: service_healthy
• Vides mainīgie .env failā (tikai izstrādei)
• Tīkla izolācija — frontend un backend atsevišķos tīklos

Kubernetes — produkcijas orkestrācija

Kubernetes risinājumi Node.js kontaineriem:

• Pods — mazākā izvietojamā vienība. Parasti viens konteiners = viens pods
• Deployments — deklaratīva stāvokļa pārvaldība, rolling updates (zero-downtime)
• Services — iekšējā un ārējā trafika maršrutēšana (ClusterIP, LoadBalancer)
• HPA (Horizontal Pod Autoscaler) — automātiska mērogošana pēc CPU/atmiņas/custom metrikām
• Resource limits — CPU un atmiņas limits katram konteineram (novērš resource hogging)
• Liveness un Readiness probes — Kubernetes automātiski restartē vai izņem no load balancera neveselīgus kontainerus

Managed Kubernetes

AWS EKS, GCP GKE, Azure AKS, DigitalOcean DOKS — pārvaldīts control plane, jūs pārvaldāt worker nodes. Mazākām komandām: managed container platforms (Render, Railway, Fly.io) — bez Kubernetes sarežģītības.

Produkcijas optimizācija — Node.js specifika

NODE_ENV=production

Absolūti obligāts. Efekti: Express atspējo verbose error messages, npm ci neinstalē devDependencies, daudzas bibliotēkas optimizē iekšējo cache un izslēdz debug kodu. Var nozīmēt 2–10x veiktspējas uzlabojumu.

Health endpointi

• /health vai /healthz — vienkāršs endpoint, ko pārbauda orchestrator (Kubernetes liveness probe, Docker HEALTHCHECK, load balancer)
• /ready — readiness probe: pārbauda datubāzes savienojumu, Redis pieejamību, ārējo servisu stāvokli. Atgriež 503, ja nav gatavs apkalpot trafiku
• Implementācija: vienkāršs Express route, kas atgriež 200 OK ar statusu JSON

Graceful shutdown

SIGTERM apstrāde — kritiska zero-downtime deployment:

1. Saņem SIGTERM signālu (Kubernetes/Docker sūta pirms konteinera stop)
2. Pārtrauc jaunu pieprasījumu pieņemšanu (server.close())
3. Gaida aktīvo pieprasījumu pabeigšanu (timeout: 30s)
4. Aizver datubāzes savienojumus, Redis, message queues
5. Process exit ar kodu 0

Problēma: Node.js process PID 1 konteinerā neapstrādā SIGTERM. Risinājums: init process (tini vai dumb-init) kā ENTRYPOINT, vai Node.js --init flag.

Atmiņas pārvaldība

• --max-old-space-size iestatiet atbilstoši konteinera atmiņas limitam (parasti 75% no limits)
• Neiegaumējiet konteinera atmiņu kā servera RAM — ja limits ir 512MB, iestatiet --max-old-space-size=384
• Monitorējiet heap lietojumu ar process.memoryUsage()

Monitorings un novērojamība

Konteinera metrikas

• cAdvisor — Google rīks konteinera metrikām (CPU, atmiņa, tīkls, I/O). Integrējas ar Prometheus
• Prometheus + Grafana — standarta monitoringa steks. Node.js: prom-client bibliotēka custom metrikām
• Platforma monitorings — AWS CloudWatch, GCP Cloud Monitoring, Datadog, New Relic

Žurnālēšana (Logging)

• JSON formāts — strukturēti žurnāli (pino, winston JSON transport). Parsējami centralizētos sistēmās
• stdout/stderr — rakstiet žurnālus uz stdout (nevis failos). Docker/Kubernetes novirza uz konfigurēto draiveri
• Centralizēta sistēma — ELK (Elasticsearch + Logstash + Kibana), Loki + Grafana, Datadog Logs
• Correlation ID — unikalāts pieprasījuma ID caur visiem mikrosiervisiem izplatīšanai (distributed tracing)

Alerting

Iestatiet alertus kritiskām situācijām: konteiners restartējas biežāk nekā N reizes / atmiņa pārsniedz 85% / error rate pārsniedz bazsinārksti / latency P99 pārsniedz SLA.