version: '3.8'
services:
postgres:
image: postgres:16-alpine
container_name: app_postgres
restart: unless-stopped
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: 3s
retries: 5
redis:
image: redis:7-alpine
container_name: app_redis
restart: unless-stopped
ports:
- "6379:6379"
volumes:
- redisdata:/data
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 5s
timeout: 3s
retries: 5
volumes:
pgdata:
redisdata:Dacă te-ai săturat să dai npm run dev și să-ți sară în aer aplicația că ai uitat să pornești Postgres-ul local sau că Redis-ul ascultă pe alt port, configurarea asta e pentru tine. În câteva minute îți ridici tot stack-ul de dev local fără să-ți umpli sistemul de operare cu servicii care rulează degeaba în background.
Am trecut de la stilul vechi, în care fiecare coleg din echipă avea versiunea lui de Postgres instalată prin Homebrew, la un setup unic prin Docker Compose. Diferența e enormă.
De ce merită un setup izolat
Acum ceva timp, la un proiect cu vreo 8k useri activi unde făceam refactoring masiv, am adus doi devi noi în echipă. Fără un mediu standardizat, au pierdut aproape o zi întreagă doar configurând baza de date, extensiile de Postgres și versiunile potrivite de Node. Unul avea Node 18, altul 20, iar Redis-ul local al unuia folosea o parolă veche din alt proiect.
După ce am pus la punct un docker-compose.yml bine structurat, timpul de onboarding pentru orice coleg nou a scăzut la sub 10 minute. Un simplu docker compose up -d și toată lumea lucrează pe exact aceleași versiuni.
Secretele unui config de Compose fără bătăi de cap
Ca să nu transformi mediul de dev într-un consumator inutil de resurse, trebuie să respecți câteva reguli simple:
- Persistența datelor: Baza de date și Redis au nevoie de volume dedicate. Altfel, la fiecare
docker compose downpierzi toate datele de test pe care le-ai introdus cu grijă. - Healthchecks reale: Aplicația ta de Next.js nu trebuie să pornească dacă Postgres încă își inițializează fișierele de sistem. Un healthcheck simplu previne erorile de tip
connection refusedla pornire. - Imagini Alpine: Folosește variante alpine pentru resurse puțin consumate (ex.
postgres:16-alpine). Economisești câțiva gigabiți buni de disc și sute de mega de RAM.
Trade-off-ul sincer: Container complet vs. Model hibrid
Aici e o decizie pe care trebuie să o iei în funcție de laptopul pe care lucrezi:
Dacă bagi și procesul de next dev într-un container Docker și lucrezi pe macOS, mount-ul de fișiere (mai ales directorul node_modules) poate fi sesizabil mai lent la hot reload din cauza căilor de I/O virtualizate, chiar și cu VirtioFS activat.
În schimb, pe Linux, performanța e aproape nativă. Soluția mea preferată pe Mac este modelul hibrid: rulez doar Postgres și Redis în Docker Compose (cu porturile mapate pe host), iar Next.js îl rulez direct pe mașina locală cu npm run dev. Dacă totuși vrei izolare 100% și vrei ca orice coleg să pornească totul cu o singură comandă, poți pune și Next.js în Compose folosind un volum anonim peste node_modules.
Configul din exemplul de mai jos e gândit pentru variantele de servicii de sprijin (Postgres + Redis), fiind cel mai stabil setup de zi cu zi.
Sunt curios: voi ce abordare folosiți la dev local? Rulați absolut totul în Docker (inclusiv app-ul de frontend/backend) sau preferați varianta hibridă cu bazele de date containerizate și aplicația pe host?