Si të vendosni një aplikacion Django në prodhim?

Question

Accepted Answer

Vendosja e Django në prodhim përfshin ekzekutimin e tij pas një **serveri të duhur WSGI/ASGI** dhe **serveri web**, shërbimin e skedarëve statikë në mënyrë të saktë, sigurimin e konfigurimeve, dhe menaxhimin e bazës së të dhënave — shumë ndryshe nga serveri i zhvillimit i ndërtuar në paketë (i cili **nuk është** për prodhim).

## Stakullimi i prodhimit

```text
Client → NGINX (web server) → GUNICORN (WSGI app server) → DJANGO
           │                      (runs your Python app, multiple workers)
           └─ serves static/media files directly (efficient)

❌ NEVER use `python manage.py runserver` in production — it's single-threaded,
   insecure, and not built for load. Use Gunicorn (WSGI) or Uvicorn (ASGI for async).
```

Serveri dev nuk është i përshtatshëm për prodhim. Stakullimi standard: një **server aplikacioni** (Gunicorn/uWSGI për WSGI, Uvicorn për ASGI/async) ekzekuton Django me disa punëtorë, pas një **serveri web** (nginx) i cili përpunon lidhjet ardhëse, TLS, dhe skedarë statikë.

## Cilësimet e prodhimit (siguri-kritike)

```python
DEBUG = False                            # ❗ MUST be False — DEBUG=True leaks sensitive info
ALLOWED_HOSTS = ["example.com"]          # required when DEBUG=False
SECRET_KEY = os.environ["SECRET_KEY"]    # from the environment, NOT committed
SECURE_SSL_REDIRECT = True               # force HTTPS
SESSION_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000
```

## Skedarë statikë

```bash
python manage.py collectstatic           # gather static files into STATIC_ROOT
# then serve them via nginx or a CDN — or use WhiteNoise to serve them from the app
# (Django does NOT serve static files itself in production)
```

## Baza e të dhënave dhe migrimi

```bash
python manage.py migrate                  # apply migrations to the production DB
# use a real database (PostgreSQL), connection pooling, regular backups
```

## Një listë kontrolli tipike për vendosje

```text
1. Set production environment variables (SECRET_KEY, DB credentials, DEBUG=False)
2. Run migrations (manage.py migrate)
3. Collect static files (collectstatic) → serve via nginx/CDN/WhiteNoise
4. Run the app with Gunicorn/Uvicorn (multiple workers, behind nginx)
5. Enable HTTPS (TLS certificates, e.g. Let's Encrypt)
6. Set up logging, error monitoring (Sentry), health checks
7. Add a process manager (systemd/supervisor) or use containers (Docker) + orchestration
8. Run `manage.py check --deploy` to audit security settings
```

## Qasje moderne të vendosjes

```text
✓ Containers (Docker) + orchestration (Kubernetes) or platforms (Heroku, Railway, Render)
✓ Managed databases, separate static/media storage (S3 + CDN)
✓ Background workers (Celery) + a broker (Redis) as separate services
✓ Horizontal scaling: multiple app instances behind a load balancer (keep app STATELESS)
```

## Pse ka rëndësi

Vendosja e Django në prodhim në mënyrë të saktë është njohuri thelbësore për të marrë aplikacionet nga zhvillimi në përdorim real, dhe përfshin konsiderata të rëndësishme që ndryshojnë në mënyrë themelore nga zhvillimi lokal — bërja e gabimeve çon në dobësime të sigurisë, performancë të dobët, ose aplikacione të ndërprera.

Përfshirja e **stakullimit të prodhimit** është themelore: serveri i zhvillimit i ndërtuar (`runserver`) është në mënyrë eksplicite jo për prodhim (është me një fije të vetme, i pasigurt, dhe nuk mund të trajtojë ngarkesën), kështu që duhet të ekzekutoni Django pas një **serveri aplikacioni** të duhur (Gunicorn/uWSGI për WSGI, ose Uvicorn për ASGI/async) me disa punëtorë, të përballuar nga një **server web** (nginx) i cili përpunon lidhjet, TLS, dhe shërbimin e skedarëve statikë.

Një numër aspektesh janë siguri- dhe korrektësi-kritike: **cilësimet e prodhimit** (veçanërisht `DEBUG=False`, i cili është i detyrueshëm pasi `DEBUG=True` rrjedh gjurmime të ndjeshme dhe konfigurimin tek sulmuesit, plus `ALLOWED_HOSTS`, një `SECRET_KEY` i fshehtë nga mjedisi, dhe përforcim HTTPS), **trajtimi i skedarëve statikë** (ekzekutimi i `collectstatic` dhe shërbimi i skedarëve përmes nginx/CDN/WhiteNoise, pasi Django nuk i shërben vetë në prodhim — një dështim i zakonshëm i vendosjes), dhe **menaxhimi i bazës së të dhënave** (një bazë e vërtetë e të dhënave si PostgreSQL, aplikimi i migrimeve, kopje sigurie).

Përnjohurit e listës kontrolli të vendosjes, qasja moderne (Docker/kontejnerë, platforme të menaxhuara, ruajtje në cloud për media, punëtorë Celery si shërbime të veçanta, shkallim horizontal me një aplikacion pa gjendje), dhe shqetësimet operacionale (regjistrim, monitorim me Sentry, kontroll shëndeti, menaxhim procesi) është ajo që ndan një vendosje të prodhimit në punë nga një e brishtë ose e pasigurt.

Sepse çdo aplikacion real Django duhet përfundimisht të vendoset, dhe sepse gabimet e vendosjes (lënie `DEBUG=True`, trajtim të gabuar i skedarëve statikë, ekspozim i sekretet, përdorimi i serverit dev) shkaktojnë probleme reale të sigurisë dhe besueshmërisë, kuptimi se si të vendoset Django në mënyrë të duhur — stakullimi, cilësimet e sigurisë-kritike, trajtimi i skedarëve statikë/mediash, dhe praktika moderne të vendosjes — është njohuri e rëndësishme, me rrezik të lartë e cila pasqyron aftësinë për të dërguar aplikacione të gatshme për prodhim, një temë shpesh-relevante dhe thelbësore profesionalisht për çdo zhvillues Django i përgjegjës për sistemet e drejtpërdrejtë.