version: '3.8'
services:
postgres:
image: postgres:15-alpine
container_name: next-postgres
environment:
POSTGRES_USER: dev_user
POSTGRES_PASSWORD: dev_password
POSTGRES_DB: dev_db
ports:
- "5432:5432"
volumes:
- postgres_data:/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
container_name: next-redis
ports:
- "6379:6379"
volumes:
- redis_data:/data
web:
build:
context: .
dockerfile: Dockerfile.dev
container_name: next-web
ports:
- "3000:3000"
environment:
DATABASE_URL: postgres://dev_user:dev_password@postgres:5432/dev_db
REDIS_URL: redis://redis:6379
volumes:
- .:/app
- /app/node_modules
- /app/.next
depends_on:
postgres:
condition: service_healthy
redis:
condition: service_started
volumes:
postgres_data:
redis_data:Să fim sinceri, m-am săturat de ghidurile de onboarding care încep cu „instalează Postgres local, apoi Redis prin Homebrew, iar pe Windows descurcă-te cu WSL”. Docker Compose rezolvă problema asta elegant, dar majoritatea configurațiilor pe care le văd în proiectele clienților sunt făcute destul de prost.
Am lucrat recent la un proiect cu vreo 12 microservicii unde onboarding-ul unui dev nou dura o zi întreagă din cauza conflictelor de versiuni de Node și baze de date. După ce am curățat și Dockerizat mediul de dev local, am redus timpul de onboarding la fix 3 minute – adică timpul în care omul dă docker compose up și își face o cafea.
Astăzi vă arăt un template simplu, curat și optimizat pentru un stack clasic: Next.js, PostgreSQL și Redis.
De ce nu e suficient doar să pui imaginile în compose?
Marea greșeală pe care o văd des este lipsa de coordonare între servicii. Docker pornește containerele în paralel. Dacă aplicația ta Next.js pornește și încearcă să ruleze migrațiile de bază de date înainte ca Postgres să fie complet inițializat (ceea ce durează de obicei 5-10 secunde la prima pornire), aplicația ta va crapa instant.
Simplul depends_on: [postgres] nu ajută aici. El doar îi spune lui Docker să pornească containerul de Postgres, nu să și aștepte ca baza de date să poată accepta conexiuni. De aceea avem nevoie de un healthcheck real pe Postgres și de o condiție inteligentă în Next.js.
Compromisul de performanță pe macOS și Windows
Există un trade-off destul de mare când vine vorba de performanță pe macOS și Windows. Docker pe aceste sisteme rulează într-o mașină virtuală de Linux. Asta înseamnă că disk I/O (scrierea și citirea fișierelor) prin volume partajate (bind mounts) poate fi incredibil de lentă.
Dacă montezi tot folderul proiectului în container, Next.js va scrie fișierele temporare de build direct pe hard-ul tău gazdă prin acest bridge lent. Rezultatul? Hot reload-ul va dura 5 secunde în loc de 200ms.
Soluția este să folosim volume anonime pentru folderul node_modules și .next. Practic, îi spunem lui Docker să țină aceste foldere direct în memoria sa rapidă, nu să le sincronizeze înapoi pe calculatorul nostru. Pierzi posibilitatea de a inspecta ușor node_modules din VS Code-ul local (deși rar ai nevoie de asta direct acolo), dar câștigi o viteză de rulare de 10 ori mai mare.
Câteva detalii fine care îți salvează nervii
- Porturile expuse: Am expus portul
5432și6379pe host. Asta înseamnă că poți folosi în continuare un client GUI local (cum ar fi TablePlus sau DBeaver) ca să te conectezi la baza de date folosindlocalhost:5432. - Alpine Images: Folosesc mereu tag-urile
-alpinepentru imagini în dev. Sunt mult mai mici (sute de MB economisiți la download) și se încarcă mult mai repede în memorie. - Persistența datelor: Volumele numite (
postgres_datașiredis_data) asigură că atunci când oprești containerele, nu îți pierzi datele de test pe care le-ai introdus în baza de date.
Voi cum rulați stack-ul de dev local? Tot pe Docker sau preferați servicii native / cloud?