كيف تنشر تطبيق FastAPI إلى الإنتاج؟

Question

Accepted Answer

FastAPI هو تطبيق **ASGI**، لذا فإن نشره في الإنتاج يستخدم خادم ASGI — عادة **Uvicorn** (غالباً يدار بواسطة **Gunicorn** لعدة عمليات)، خلف وكيل عكسي مثل nginx. التكويت (Docker) هو النهج الحديث الشائع.

## مكدس خادم الإنتاج

```bash
# ❌ the dev server (with --reload) is NOT for production
uvicorn main:app --reload

# ✅ production: Gunicorn managing multiple Uvicorn workers (uses all CPU cores)
gunicorn main:app -w 4 -k uvicorn.workers.UvicornWorker --bind 0.0.0.0:8000
# -w 4 → 4 worker processes (rule of thumb: ~2 × CPU cores)
```

```text
Client → NGINX (reverse proxy: TLS, static files, load balancing)
           → GUNICORN (process manager) → UVICORN workers (run the ASGI app)
Multiple workers let FastAPI use multiple CPU cores (each worker = one process).
```

## تكويت التطبيق (شائع)

```dockerfile
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["gunicorn", "main:app", "-w", "4", "-k", "uvicorn.workers.UvicornWorker", "--bind", "0.0.0.0:8000"]
```

حاوية تحزم التطبيق وتبعياته لنشر متسق عبر البيئات (ثم تشغيل على Kubernetes أو ECS أو PaaS مثل Railway/Render/Fly).

## قائمة التحقق من الإنتاج

```text
1. Config & secrets via environment variables (not in code); validate at startup
2. Multiple workers (Gunicorn + Uvicorn workers) for CPU utilization
3. HTTPS/TLS (at nginx or the platform/load balancer)
4. A real database (PostgreSQL) + connection pooling; run migrations (Alembic)
5. CORS configured to an allowlist (not "*") for browser clients
6. Logging + error monitoring (Sentry) + health-check endpoint
7. A separate worker service (Celery/ARQ) + broker (Redis) for background jobs
8. Horizontal scaling: multiple instances behind a load balancer — keep app STATELESS
   (sessions/state in Redis, not process memory)
```

## غير المتزامن والحالة العديمة

```text
✓ Each worker runs its own event loop → workers give parallelism, async gives concurrency
✓ Keep the app STATELESS so you can run many instances behind a load balancer
```

## لماذا يهم

نشر FastAPI بشكل صحيح ضروري لنقل التطبيقات إلى الإنتاج، وينطوي على اعتبارات مهمة خاصة بطبيعة **ASGI** تختلف عن إعداد التطوير.

فهم مكدس خادم الإنتاج أساسي: خادم التطوير (`uvicorn --reload`) ليس للإنتاج، لذا تشغل التطبيق عبر خادم ASGI — **عمليات Uvicorn يدارها Gunicorn** لعدة عمليات (استخدام جميع أنوية المعالج، حيث تشغل كل عملية حلقة الأحداث الخاصة بها)، عادة خلف nginx للـ TLS وموازنة التحميل. **التكويت (Docker)** هو النهج الحديث الشائع لنشر متسق وقابل للنقل.

بعد إعداد الخادم، تغطي قائمة التحقق من الإنتاج المخاوف الحرجة المتعلقة بالأمان والموثوقية: الإعدادات والأسرار عبر متغيرات البيئة (لا تكون في الكود)، HTTPS، قاعدة بيانات حقيقية مع الترحيل وتجميع الاتصالات، CORS السليم، والتسجيل والمراقبة، وخدمات عمل منفصلة للمهام الخلفية، و — للتوسع — تشغيل **عدة نوى عديمة الحالة** خلف موازن تحميل (الحفاظ على الحالة في Redis، وليس ذاكرة العملية).

معرفة كيفية نشر FastAPI مع مكدس ASGI الخادم الصحيح والتكويت وعدة العمليات وتصليب الإنتاج معرفة مهمة على مستوى الأعلى، لأن كل تطبيق FastAPI حقيقي يجب نشره بشكل صحيح ليكون فعالاً وآمناً وقابلاً للتوسع — مما يجعل هذا موضوعاً متكرراً بشكل متكرر وضروري مهنياً لشحن واجهات برمجية إنتاجية.