services:
postgres:
image: postgres:16-alpine
container_name: app_postgres
restart: unless-stopped
environment:
POSTGRES_USER: devuser
POSTGRES_PASSWORD: devpass
POSTGRES_DB: app_dev
ports:
- "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U devuser -d app_dev"]
interval: 5s
timeout: 5s
retries: 5
redis:
image: redis:7-alpine
container_name: app_redis
restart: unless-stopped
command: redis-server --maxmemory 128mb --maxmemory-policy allkeys-lru
ports:
- "6379:6379"
volumes:
- redis_data:/data
volumes:
postgres_data:
redis_data:Am văzut prea mulți colegi care pierd jumătate de zi instalând Postgres și Redis direct pe sistem, ca apoi la primul update de OS să se rupă socket-urile sau dependențele. Cu Docker Compose scapi complet de problema asta. Totuși, trucul e să știi exact ce merită containerizat și ce lași afară pe mașina de dezvoltare.
Marea greșeală: Next.js băgat cu forța în container
La un proiect de acum doi ani am insistat să rulăm absolut totul în Docker pe macOS, inclusiv serverul de Node. Rezultatul? Hot reload-ul pentru o simplă modificare de CSS dura între 4 și 6 secunde din cauza layer-ului lent de I/O pe bind mounts între Mac și VM-ul de Linux. A fost o decizie proastă.
Regula mea de aur acum este simplă: infrastructura de suport (baza de date, cache-ul, eventual un server de mail fals gen Mailpit) merge în containere prin Compose. Aplicația de Next.js rulează nativ pe host cu npm run dev sau pnpm dev. Ai viteza maximă a compilatorului Turbopack sau Webpack, iar serviciile dependente stau cuminți în containere izolate.
Configurația minimă care chiar funcționează
În fișierul compose.yaml (sau clasicul docker-compose.yml), ai nevoie doar de două servicii bine configurate, cu named volumes pentru persistență și porturi mapate corect pe localhost.
Am adăugat și un healthcheck pentru Postgres. De ce? Dacă ai scripturi de seed sau migrații Prisma/Drizzle rulate la pornire prin vreun Makefile, nu vrei ca ele să încerce conectarea înainte ca serverul de Postgres să accepte socket-uri TCP. M-am prins de treaba asta după zeci de crash-uri de tipul connection refused în scripturile de CI și dev.
Pentru Redis, am pus o limită de memorie direct în comandă (--maxmemory 128mb). Dacă uiți chei fără TTL în timpul testelor locale, nu vrei ca Redis să-ți înghită 4 GB de RAM pe nevăzute.
Conectarea din Next.js și mici trade-off-uri
În fișierul tău .env.local din proiectul Next.js, conexiunile devin banale:
DATABASE_URL="postgresql://devuser:devpass@localhost:5432/app_dev?schema=public"
REDIS_URL="redis://localhost:6379"
Trade-off-ul evident: nu ai paritate 100% cu producția. În staging sau prod probabil rulezi totul într-un cluster de Kubernetes sau pe un VPS cu container gata build-uit. Dar pentru bucla rapidă de feedback din dev (unde salvezi un fișier de 300 de ori pe zi), sacrificul ăsta e perfect justificat.
Un alt pont util: nu uita să adaugi folderele de volume locale în .gitignore dacă mapezi directoare în loc de named volumes. Folosirea named volumes (postgres_data, redis_data) te scapă de probleme legate de permisiuni între userul din container și userul tău de sistem pe Linux.
Când vrei să cureți complet starea aplicației și să reiei totul de la zero, dai un simplu docker compose down -v și ai șters și datele persistente. Fără uninstall de servicii locale, fără procese orfane care țin portul 5432 ocupat.
Voi cum lucrați de obicei? Țineți și runtime-ul de frontend/backend în container pe mașina locală sau doar serviciile externe?