Zareian
5492788bf8
The README had grown into a 295-line mixture of onboarding, an ops runbook, a content-authoring workflow, bulk question generation and a Docker log stack. A reader arriving at the repo could not tell in ten seconds what this service is, whether it is live, or where to start, and five of its claims no longer matched the code: - it said to export .env values by hand; settings.py has loaded .env through python-dotenv for a while now - it listed six variables as "everything the app actually reads"; .env.example has carried many more than that for some time - it called DJANGO_SECRET_KEY, DJANGO_ALLOWED_HOSTS and CACHE_URL required in production; all three now have working defaults, and the app boots without them on purpose so a partial .env cannot take the service down - it claimed there is no insecure SECRET_KEY fallback; there is one, under DEBUG - it required Python 3.12 while the project runs on 3.11 (Docker uses 3.12) The README now states what the service is, where it runs, how healthy it is and how to get it running in six commands, then links onward. Procedures moved to docs/operations.md, docs/content-authoring.md, docs/architecture.md and docs/docker.md, which is where someone follows a procedure rather than skims it. Nothing was dropped; the deploy one-liner now includes the separate sudo restart that deploy.sh cannot perform itself, and backup/restore is written down for the first time. Every number in the README was measured rather than quoted: content counts from the live /api/health and content/seed/curriculum.json, 55 endpoints from the generated OpenAPI schema, 481 tests from a full run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
44 lines
2.0 KiB
Markdown
44 lines
2.0 KiB
Markdown
# استکِ محلیِ 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، فقط محیطِ محلی |
|
|
| 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` اجرا می‌شود.
|