Bagaimanakah anda men-deploy aplikasi Django ke pengeluaran?

Question

Accepted Answer

Men-deploy Django ke pengeluaran melibatkan menjalankannya di belakang **pelayan WSGI/ASGI** dan **pelayan web** yang sesuai, menyajikan fail statik dengan betul, mengamankan tetapan, dan menguruskan pangkalan data — agak berbeza daripada pelayan pembangunan terbina dalam (yang **bukan** untuk pengeluaran).

## Stack pengeluaran

```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).
```

Pelayan pembangunan tidak sesuai untuk pengeluaran. Stack standard: **pelayan aplikasi** (Gunicorn/uWSGI untuk WSGI, Uvicorn untuk ASGI/async) menjalankan Django dengan berbilang worker, di belakang **pelayan web** (nginx) yang mengendalikan sambungan masuk, TLS, dan fail statik.

## Tetapan pengeluaran (kritikal-keselamatan)

```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
```

## Fail 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)
```

## Pangkalan data dan migrasi

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

## Senarai semak deployment biasa

```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
```

## Pendekatan deployment moden

```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)
```

## Mengapa ia penting

Men-deploy Django ke pengeluaran dengan betul ialah pengetahuan penting untuk membawa aplikasi daripada pembangunan ke penggunaan dunia sebenar, dan ia melibatkan pertimbangan penting yang berbeza secara mendasar daripada pembangunan tempatan — melakukannya secara salah membawa kepada kelemahan keselamatan, prestasi lemah, atau aplikasi rosak.

Memahami **stack pengeluaran** adalah asas: pelayan pembangunan terbina dalam (`runserver`) secara eksplisit bukan untuk pengeluaran (ia single-threaded, tidak selamat, dan tidak boleh mengendalikan beban), jadi anda mesti menjalankan Django di belakang **pelayan aplikasi** yang sesuai (Gunicorn/uWSGI untuk WSGI, atau Uvicorn untuk ASGI/async) dengan berbilang worker, di hadapannya **pelayan web** (nginx) yang mengendalikan sambungan, TLS, dan penyajian fail statik.

Beberapa aspek adalah kritikal-keselamatan dan kritikal-ketepatan: **tetapan pengeluaran** (terutamanya `DEBUG=False`, yang wajib kerana `DEBUG=True` membocorkan traceback dan konfigurasi sensitif kepada penyerang, ditambah `ALLOWED_HOSTS`, `SECRET_KEY` rahsia daripada persekitaran, dan penguatkuasaan HTTPS), **pengendalian fail statik** (menjalankan `collectstatic` dan menyajikan fail melalui nginx/CDN/WhiteNoise, kerana Django tidak menyajikannya sendiri dalam pengeluaran — kegagalan deployment yang biasa), dan **pengurusan pangkalan data** (pangkalan data sebenar seperti PostgreSQL, melaksanakan migrasi, sandaran).

Mengetahui senarai semak deployment, pendekatan moden (Docker/kontena, platform terurus, storan awan untuk media, worker Celery sebagai perkhidmatan berasingan, penskalaan mendatar dengan aplikasi stateless), dan kebimbangan operasi (logging, pemantauan dengan Sentry, health check, pengurusan proses) ialah apa yang membezakan deployment pengeluaran yang berfungsi daripada yang rapuh atau tidak selamat.

Kerana setiap aplikasi Django sebenar akhirnya mesti di-deploy, dan kerana kesilapan deployment (membiarkan `DEBUG=True`, salah mengendalikan fail statik, mendedahkan rahsia, menggunakan pelayan pembangunan) menyebabkan masalah keselamatan dan kebolehpercayaan sebenar, memahami cara men-deploy Django dengan betul — stack, tetapan kritikal-keselamatan, pengendalian static/media, dan amalan deployment moden — ialah pengetahuan penting yang berisiko tinggi yang mencerminkan keupayaan untuk menghantar aplikasi yang sedia-pengeluaran, satu topik yang kerap relevan dan penting secara profesional untuk mana-mana pembangun Django yang bertanggungjawab terhadap sistem langsung.