Skip to content

Sănătatea containerelor: verificare reală a bazei și limită de jurnale

Verificarea de sănătate a backend-ului confirmă doar că procesul trăiește, nu și că baza de date răspunde. Docker o folosește ca să decidă starea containerului și ca să lase frontend-ul să pornească, deci magazinul se poate deschide gol în timp ce verificarea spune că totul e în regulă. Separat, niciunul dintre cele două fișiere compose nu limitează jurnalele containerelor, deci nu există rotație scrisă de noi.

Ce am găsit

/api/health nu atinge baza de date

backend/src/routes/health.ts, tot fișierul are 10 linii:

/** GET /api/health — liveness probe used by tooling and the frontend. */
router.get('/', (_req: Request, res: Response) => {
  res.json({ status: 'ok' });
});

Nu atinge Prisma, nu atinge baza. Pe producție: curl -s https://api.hyperice.md/api/health → {"status":"ok"} (200).

Exact acest răspuns decide starea containerului, docker-compose.prod.yml:22-27:

    healthcheck:
      test: ['CMD', 'wget', '-qO-', 'http://localhost:3001/api/health']

iar docker-compose.prod.yml:40-42 leagă pornirea frontend-ului de el:

    depends_on:
      backend:
        condition: service_healthy

Verificarea spune „sunt sănătos" chiar dacă fișierul bazei lipsește, e corupt sau volumul nu s-a montat. Când vom pune și monitorizare externă de disponibilitate, ea va urmări tot acest endpoint și ne va spune că totul e bine în timp ce site-ul nu vinde nimic.

Fixul e sigur în raport cu pornirea: comanda din backend/Dockerfile rulează npx prisma migrate deploy && node dist/index.js, deci baza e migrată înainte ca serverul să răspundă, iar un SELECT 1 în health nu ar bloca un deploy curat.

Jurnalele containerelor nu au limită scrisă de noi

grep -rniE "logrotate|max-size|logging:|log-opts" --include='*.yml' --include='*.conf' .

→ zero rezultate. Nici docker-compose.yml, nici docker-compose.prod.yml nu au bloc logging:.

Volumul scris de backend e mic: în tot backend/src există 5 apeluri console.*, fără middleware de logare a cererilor — practic doar mesajul de pornire. Jurnalul per cerere vine din nginx-ul de frontend; frontend/nginx.conf nu declară access_log, deci merge pe implicitul imaginii, către stdout.

NEVERIFICAT: dacă /etc/docker/daemon.json de pe serverul de producție impune deja max-size și max-file la nivel global. E infrastructură pe care nu se inspectează din repo.

De făcut

  • În backend/src/routes/health.ts, adaugă o interogare ieftină înainte de răspuns (prisma.$queryRawSELECT 1`` sau o numărare de produse), cu try/catch: 200 {status:'ok'} la reușită, 503 `{status:'degraded'}` la eșec. Verificarea Docker rămâne neschimbată.
  • În docker-compose.yml și docker-compose.prod.yml, la fiecare serviciu, adaugă logging: { driver: json-file, options: { max-size: '10m', max-file: '5' } } — maximum 50 MB de jurnal per container, cu rotație automată.

Criteriu de acceptare

  • Cu baza indisponibilă, curl -i http://localhost:3001/api/health întoarce 503, iar docker ps arată containerul de backend ca unhealthy.
  • docker inspect hyperice-backend-prod --format '{{json .HostConfig.LogConfig}}' arată max-size și max-file setate; același lucru pentru containerul de frontend.
Edited by Vitalie