version: '3.8'
services:
db:
image: postgres:15-alpine
container_name: nextjs_db
environment:
POSTGRES_USER: ${DB_USER:-postgres}
POSTGRES_PASSWORD: ${DB_PASSWORD:-password}
POSTGRES_DB: ${DB_NAME:-myapp}
ports:
- "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 5s
retries: 5
redis:
image: redis:7-alpine
container_name: nextjs_redis
ports:
- "6379:6379"
app:
build:
context: .
dockerfile: Dockerfile.dev
volumes:
- .:/app
- /app/node_modules
ports:
- "3000:3000"
environment:
DATABASE_URL: postgresql://${DB_USER:-postgres}:${DB_PASSWORD:-password}@db:5432/${DB_NAME:-myapp}
REDIS_URL: redis://redis:6379
depends_on:
db:
condition: service_healthy
redis:
condition: service_started
volumes:
postgres_data:Salutare. Am văzut destul de mulți colegi la început de drum care încă își instalează manual Postgres sau Redis direct pe sistemul de operare, fie că e macOS sau Windows. Nu e greșit neapărat, dar te lovești repede de versiuni diferite între colegi sau, mai rău, de procese care rămân agățate prin background și îți mănâncă RAM-ul degeaba când tu de fapt te joci altceva.
La un proiect de anul trecut, unde aveam vreo 8 microservicii și 3 baze de date diferite, am reușit să reduc timpul de onboarding pentru un dev nou de la o zi întreagă la fix 5 minute. Secretul? Un docker-compose.yaml bine pus la punct. Practic, cu o singură comandă, docker compose up, ai tot stack-ul pregătit, izolat și gata de treabă. Pentru un setup clasic de Next.js, ai nevoie de bază de date (Postgres e standardul de facto acum) și, probabil, un cache sau un queue manager cu Redis.
De ce să te complici cu containere?
Sincer, pe Mac-urile vechi cu Intel era un chin, dar pe generațiile noi M1/M2/M3 sau pe Linux, Docker zboară. Trade-off-ul e clar: consumi ceva mai multe resurse (în special RAM) decât dacă ai rula procesele nativ, dar câștigi liniște mentală. Știi sigur că baza de date e versiunea 15.4, exact ca pe staging, nu ce versiune s-a nimerit să fie în brew sau ce ai instalat acum doi ani pentru alt proiect.
Am pățit de multe ori să am conflicte de porturi sau baze de date corupte pentru că rulasem simultan două versiuni de Postgres pe același port. Cu Docker, fiecare proiect stă în „cutiuța” lui. Dacă ceva se strică, ștergi containerul, ștergi volumul și o iei de la zero în 10 secunde. Plus că poți simula mult mai ușor condiții de rețea sau variabile de mediu specifice.
Configurația curată
Într-un setup de Next.js, cea mai mare problemă e viteza de refresh (HMR). Dacă încerci să rulezi npm run dev în interiorul containerului pe Windows sau Mac, uneori sistemul de fișiere e lent și durează 3-4 secunde până vezi schimbarea în browser. Eu prefer o abordare hibridă: rulez Next.js nativ pe host pentru viteză maximă, dar țin Postgres și Redis în Docker Compose.
Totuși, dacă vrei consistență totală (de exemplu, pentru echipa de QA), poți rula totul în Docker. Important e să folosești volume pentru persistența datelor. Altfel, la fiecare restart de container, pierzi toți userii de test pe care i-ai creat cu sudoare. Am pus mai jos o structură care mie îmi merge brici de câțiva ani.
Un aspect la care mi-am prins urechile la început: conexiunea între servicii. În Docker, containerele vorbesc între ele folosind numele serviciului ca hostname. Deci, în loc de localhost:5432, aplicația ta va căuta db:5432. E o chestie mică, dar care generează 90% din erorile de tip „Connection refused” pe care le văd pe forumuri.
Atenție la detalii
Nu uita de .dockerignore. Dacă trimiți tot folderul node_modules (care are probabil 500MB) către Docker daemon de fiecare dată când faci build, o să pierzi timp prețios. Am optimizat build time-ul cu vreo 30% doar fiind atent la ce fișiere copiez în container.
De asemenea, folosește imagini de tip -alpine unde se poate. Sunt mult mai mici (Redis are vreo 30MB în varianta Alpine, față de 100MB+ cea standard). Mai puțin spațiu ocupat înseamnă descărcare mai rapidă și mai puțin stres pe SSD-ul tău.
Voi cum faceți? Rulați totul în containere sau preferați bazele de date „managed” în cloud (gen Supabase sau Neon) chiar și pentru mediul de development local?