version: '3.8'
services:
postgres:
image: postgres:15-alpine
environment:
POSTGRES_USER: dev_user
POSTGRES_PASSWORD: dev_password
POSTGRES_DB: dev_db
ports:
- "5432:5432"
volumes:
- pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U dev_user -d dev_db"]
interval: 5s
timeout: 5s
retries: 5
redis:
image: redis:7-alpine
ports:
- "6379:6379"
volumes:
- redisdata:/data
web:
build:
context: .
dockerfile: Dockerfile.dev
ports:
- "3000:3000"
volumes:
- .:/app
- /app/node_modules
environment:
DATABASE_URL: postgres://dev_user:dev_password@postgres:5432/dev_db
REDIS_URL: redis://redis:6379
depends_on:
postgres:
condition: service_healthy
volumes:
pgdata:
redisdata:Salutare! M-am lovit recent de un proiect unde onboarding-ul unui dev nou dura o zi întreagă din cauză că trebuia să-și instaleze manual Postgres, Redis și nu știu ce versiuni de Node. Am zis că e destul. Am scris un docker-compose.yml simplu care rezolvă toată povestea asta în fix 2 minute.
Hai să vedem cum structurăm un setup curat, fără bătăi de cap și mai ales, fără să ne mișcăm în reluare.
De ce facem asta și care-i șmecheria
Docker Compose e genial pentru dev local, dar mulți fac greșeala să bage și codul de Next.js în container cu tot cu node_modules mapat aiurea prin volume. Pe macOS sau Windows, chestia asta rupe performanța din cauza virtualizării sistemului de fișiere. Am pățit asta pe un proiect cu vreo 12 colaboratori: ne plângeam toți că ne mănâncă bateria la laptop în două ore și că hot-reload-ul dura câte 8 secunde.
Soluția? Ținem baza de date și Redis în Docker, iar pentru Next.js facem un mount inteligent. Sau, dacă vrei performanță maximă, rulezi Next.js direct pe host-ul tău și lași doar serviciile de infra în Docker.
Totuși, dacă vrei izolare completă (să fii sigur că toți folosesc aceeași versiune de Node 20), varianta de mai jos e cel mai bun compromis pe care l-am găsit în 10 ani de când mă joc cu containerele.
Configurația care nu dă rateuri
Secretul din fișierul de mai jos stă în două chestii mari și late:
- Healthcheck-ul de pe Postgres: Next.js pornește extrem de repede. Dacă nu punem o condiție de tipul
service_healthy, Next.js va încerca să se conecteze la baza de date înainte ca Postgres să fie gata să accepte conexiuni. Rezultatul? Crash la pornire și nervi vărsați degeaba. - Volumul anonim pentru
node_modules: Observă linia- /app/node_modules. Aceasta îi spune lui Docker să nu suprascrie folderul de dependențe din container cu cel de pe host-ul tău, salvând viteza de scriere/citire.
Trade-off-ul sincer
Configurația asta merge brici pentru a avea un mediu predictibil. Totuși, dacă ai un proiect masiv, cu sute de pagini în Next.js, rularea lui în Docker pe macOS (chiar și cu gRPC FUSE sau VirtioFS active în Docker Desktop) tot va fi cu 15-20% mai lentă la build-ul inițial decât dacă ai rula npm run dev direct pe mașina ta.
Eu personal folosesc abordarea hibridă: pornesc doar Postgres și Redis din Compose, iar Next.js îl rulez nativ. Dar pentru onboarding-ul rapid al colegilor juniori, varianta complet containerizată e aur curat.
Voi cum procedați la proiectele voastre? Dockerizați tot stack-ul în dev sau lăsați aplicația de frontend să ruleze nativ pe host?