version: '3.8'
services:
postgres:
image: postgres:15-alpine
container_name: nextjs_postgres
environment:
POSTGRES_USER: ${DB_USER:-postgres}
POSTGRES_PASSWORD: ${DB_PASSWORD:-postgres_pass}
POSTGRES_DB: ${DB_NAME:-app_db}
ports:
- "5432:5432"
volumes:
- pgdata:/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"
volumes:
- redisdata:/data
web:
build:
context: .
dockerfile: Dockerfile.dev
container_name: nextjs_web
ports:
- "3000:3000"
volumes:
- .:/app
- /app/node_modules
environment:
DATABASE_URL: postgresql://${DB_USER:-postgres}:${DB_PASSWORD:-postgres_pass}@postgres:5432/${DB_NAME:-app_db}
REDIS_URL: redis://redis:6379
depends_on:
postgres:
condition: service_healthy
redis:
condition: service_started
volumes:
pgdata:
redisdata:Dacă te-ai săturat ca noul tău coleg să piardă o zi întreagă configurându-și PostgreSQL și Redis local, ai nevoie de un Docker Compose curat. În postarea asta îți arăt cum am structurat un setup rapid pentru Next.js, baze de date și cache, fără bătăi de cap cu porturile blocate. O să vezi exact configurația pe care o folosesc acum la un proiect activ cu vreo 15k utilizatori lunari.
De ce facem asta și unde ne lovim cu capul de sus
Am trecut prin faza în care rulam totul nativ pe macOS. "La mine merge" era la ordinea zilei până când versiunea de Postgres de pe brew a unui coleg a decis să nu fie compatibilă cu o migrare de Prisma. Docker rezolvă asta, dar vine cu un cost.
Dacă pui Next.js direct în Docker în mod development cu volume mapate, pe macOS sau Windows o să simți o mică întârziere la hot-reload. Sistemul de fișiere virtualizat e mai lent. Trade-off-ul e simplu: pierzi 200-300ms la salvarea unui fișier, dar câștigi un mediu identic cu cel de producție și zero configurări de mână. Pentru mine, la proiectul actual, a redus timpul de onboarding pentru un dev nou de la 4 ore la exact 5 minute (cât durează un docker compose up).
Secretul unui setup curat
Majoritatea de pe net folosesc depends_on simplu. E o capcană. depends_on doar se asigură că containerul de Postgres a pornit ca proces, nu că serviciul din interiorul lui e gata să primească conexiuni. Next.js-ul tău va încerca să ruleze migrările sau să se conecteze la DB și va crăpa instant pentru că Postgres încă își inițializează folderele interne.
Soluția este să folosim un healthcheck real pe Postgres și să setăm condiția de pornire pentru Next.js ca service_healthy.
Un alt truc pe care mulți îl uită este cel cu node_modules. Dacă montezi tot folderul curent în container (.:/app), riști să suprascrii node_modules din container cu cele de pe mașina gazdă. Dacă rulezi pe Mac cu chip M1 și containerul e Linux, binarul de Prisma sau alte pachete native compilate vor crăpa. Soluția? Adăugăm un volum anonim pentru /app/node_modules. Docker va păstra folderul de node_modules generat în interiorul imaginii, ignorând ce ai tu local.
Variabilele de mediu fără bătăi de cap
Nu hardcoda parolele în fișierul compose. Pune valori default rezonabile direct în YAML folosind sintaxa ${VARIABLE:-default_value}. Docker Compose va citi automat fișierul .env din rădăcină dacă există, dar dacă nu există, configurarea locală tot va funcționa datorită valorilor de fallback.
Cum procedați voi la proiectele voastre? Rulați Next.js nativ pe mașină și doar bazele de date în Docker, sau băgați absolut tot stack-ul în containere?