version: '3.8'
services:
postgres:
image: postgres:15-alpine
container_name: nextjs-postgres
environment:
POSTGRES_USER: myuser
POSTGRES_PASSWORD: mypassword
POSTGRES_DB: mydb
ports:
- "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data
restart: always
redis:
image: redis:7-alpine
container_name: nextjs-redis
ports:
- "6379:6379"
volumes:
- redis_data:/data
restart: always
volumes:
postgres_data:
redis_data:Să fim sinceri, nimănui nu-i place să piardă două ore configurând manual Postgres și Redis pe un laptop nou. Am pățit-o acum vreo 5 ani la un proiect cu vreo 10 developeri unde fiecare avea altă versiune de Node și Postgres instalată local; a fost un coșmar logistic până am pus la punct un docker-compose.yml simplu.
Astăzi îți arăt cum să ridici o bază de date și un Redis în mai puțin de 2 minute, fără să-ți umpli sistemul de procese inutile care rulează în background și îți omoară bateria.
Trade-off-ul: Totul în Docker sau abordare hibridă?
Marea greșeală pe care o văd des e încercarea de a înghesui și aplicația Next.js într-un container în timpul dezvoltării locale.
Da, sună bine teoretic să ai izolare completă. Practic, pe macOS sau Windows, file sharing-ul în Docker este incredibil de lent din cauza modului în care este virtualizat sistemul de fișiere. Dacă ai un proiect Next.js mărișor, timpul de fast-refresh/hot-reload crește simțitor. Am făcut un test la un proiect cu peste 100 de pagini: rulat direct pe mașina gazdă, build-ul local dura 12 secunde; în Docker, trecea de 25 de secunde. Am economisit cam 50% din timp rulând Next.js nativ și lăsând doar serviciile grele în containere.
De aceea, recomand abordarea hibridă pentru dev local:
- Postgres și Redis rulează în Docker Compose (sunt izolate, ușor de șters și recreat în caz de corupere a datelor).
- Next.js rulează local (
npm run dev) și se conectează direct la porturile expuse de containere.
Configurația de start pentru docker-compose.yml
Mai jos ai o configurație curată, gata de utilizat. Folosim imagini oficiale bazate pe Alpine Linux pentru că sunt extrem de ușoare (imaginea de Redis are sub 30MB, iar cea de Postgres în jur de 150MB, spre deosebire de versiunile standard care sar de 300MB-400MB).
De asemenea, am definit volume persistente. Dacă nu le pui, te vei trezi că după fiecare restart de container pierzi toate datele de test pe care le-ai creat cu migală. Am pățit asta o singură dată și mi-a fost de ajuns ca să nu mai uit niciodată de secțiunea de volumes.
Cum te conectezi din Next.js
În rădăcina proiectului tău Next.js, creează sau modifică fișierul .env.local. Deoarece rulăm Next.js pe mașina gazdă, ne vom conecta direct la localhost pe porturile pe care le-am mapat în fișierul YAML:
DATABASE_URL="postgresql://myuser:mypassword@localhost:5432/mydb?schema=public"
REDIS_URL="redis://localhost:6379"
Dacă folosești un ORM modern precum Prisma sau Drizzle, rularea migrărilor va funcționa instant deoarece portul 5432 este mapat direct pe mașina ta. Când vrei să cureți totul și să o iei de la capăt cu o bază de date curată, rulezi un simplu docker compose down -v (flag-ul -v șterge și volumele locale) și ai rezolvat problema.
Tu ce workflow preferi pentru dev local? Rulezi totul direct în containere, inclusiv Node.js, sau folosești și tu abordarea asta hibridă?