# استکِ محلیِ Docker

`docker-compose.yml` اپ را **به‌همراه** یک استکِ لاگِ متمرکز اجرا می‌کند
(Loki + Grafana Alloy + Grafana).

> این یک تنظیمِ **توسعه/محلی** است، نه دیپلویِ پروداکشن: سرویسِ `django`
> همچنان `runserver` را اجرا می‌کند، نه یک سرورِ WSGI. پروداکشنِ واقعی روی
> `gunicorn` با systemd بالا می‌آید — [`operations.md`](operations.md) را
> ببینید.

```bash
cp .env.example .env      # اختیاری — بدونش از پیش‌فرض‌های dev استفاده می‌کند
docker compose up --build
```

| سرویس | آدرس | توضیح |
|---|---|---|
| اپ Django | `http://localhost:8000` | |
| Grafana | `http://localhost:3000` | دسترسیِ anonymous فقط با نقشِ Viewer، فقط روی خودِ لپ‌تاپ (`127.0.0.1`) |
| Loki | `http://localhost:3100` | ذخیره‌سازیِ لاگ، در معرضِ کاربر نیست |
| Alloy | `http://localhost:12345` | رابطِ دیباگِ اختیاری |

## ترتیبِ بالا آمدن

Compose خودش مدیریتش می‌کند:

1. اول `loki`.
2. `alloy` و `grafana` بعد از آن (`depends_on`).
3. `django` هیچ وابستگی‌ای به استکِ لاگ ندارد — خودش `migrate` و بعد
   `runserver` را اجرا می‌کند و منتظرِ هیچ‌کدام نمی‌ماند.

## اجرای فرمان‌ها داخلِ کانتینر

اگر فقط از Docker استفاده می‌کنید (بدونِ venv محلی)، `python manage.py ...` را
روی سیستمِ خودتان اجرا نکنید — باید داخلِ کانتینرِ `django` اجرا شود:

```bash
docker compose exec django python manage.py createsuperuser
docker compose exec django python manage.py seed_test_data
docker compose exec django python manage.py test
```

`migrate` استثناست: طبقِ بالا خودکار پیش از `runserver` اجرا می‌شود.