როგორ განვითარებულ Django აპლიკაციას ის production-ში?

Question

Accepted Answer

Django-ის production-ში განვითარება მოითხოვს სწორი **WSGI/ASGI სერვერის** და **web სერვერის** გამოყენებას, static ფайლების სწორ მიწოდებას, პარამეტრების უსაფრთხოებას და მონაცემთა ბაზის მართვას — ეს მნიშვნელოვნად განსხვავდება ჩაშენებული development სერვერისგან (რომელიც **არ არის** production-სთვის).

## Production stack

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

Dev სერვერი production-სთვის გამოუსადეგარია. სტანდარტული stack: **application სერვერი** (Gunicorn/uWSGI WSGI-სთვის, Uvicorn ASGI/async-სთვის) აკოორდინებს Django-ს მრავალი worker-ის საშუალებით, **web სერვერის** მახლობლად (nginx), რომელიც ამუშავებს შემომავალ კავშირებს, TLS-ს და static ფайლებს.

## Production პარამეტრები (უსაფრთხოების თვალსაზრისით კრიტიკული)

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

## Static ფайლები

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

## მონაცემთა ბაზა და migrацია

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

## ტიპიური განვითარების შემოწმების სია

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

## თანამედროვე განვითარების მიდგომები

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

## რატომ არის ეს მნიშვნელოვანი

Django-ის production-ში სწორი განვითარება აუცილებელი ცოდნაა აპლიკაციების development-დან რეალურ მხარდაჭერაში გადაყვანისთვის, და ეს მოითხოვს მნიშვნელოვან განხილვებს, რომლებიც ფუნდამენტურად განსხვავდება ლოკალური development-ისგან — არასწორი განვითარება იწვევს უსაფრთხოების საფრთხეებს, ცუდ ფუნქციონირებას ან გატეხილ აპლიკაციებს.

**Production stack**-ის გაგება არის საფუძველი: ჩაშენებული development სერვერი (`runserver`) აშკარად არ არის production-სთვის (ის ერთ-ძაფიანია, არასაიმედო და არ შეიძლება გაკმაყოფილდეს დატვირთვა), ამიტომ თქვენ უნდა გაიკოორდინოთ Django სწორი **application სერვერის** მიერ (Gunicorn/uWSGI WSGI-სთვის ან Uvicorn ASGI/async-სთვის) მრავალი worker-ის საშუალებით, რომელიც დაფარული იქნება **web სერვერის** მიერ (nginx), რომელიც ამუშავებს კავშირებს, TLS-ს და static ფაილების მიწოდებას.

მრავალი ასპექტი უსაფრთხოების და სისწორის თვალსაზრისით კრიტიკულია: **production პარამეტრები** (განსაკუთრებით `DEBUG=False`, რომელიც სავალდებულოა, რადგან `DEBUG=True` ღამის მგრიდან ამჟამინდელი ტრეისბეკებს და კონფიგურაციას თავდამსხმელებს, დამატებით `ALLOWED_HOSTS`, საიდუმლო `SECRET_KEY` გარემოდან და HTTPS აუცილებლობა), **static ფაილების მართვა** (აკოორდინება `collectstatic` და ფაილების მიწოდება nginx/CDN/WhiteNoise-ის საშუალებით, რადგან Django თავისთავად არ მიწოდებს მათ production-ში — აკოორდინების ხშირი წარუმატებლობა) და **მონაცემთა ბაზის მართვა** (რეალური მონაცემთა ბაზა, როგორიცაა PostgreSQL, მიგრაციის გამოყენება, მარქაფი).

მიგრაციის სია, თანამედროვე მიდგომები (Docker/კონტეინერები, მართული პლატფორმები, კლაუდ სტორეჯი მედიისთვის, Celery workers ცალკე სერვისებად, ჰორიზონტალური მასშტაბი stateless აპლიკაციის საშუალებით) და ოპერაციული საკითხები (logging, Sentry-ით მონიტორი, სიჯამეს შემოწმება, პროცესის მართვა) იცნობა, ეს აბაზირებს სამუშაო production-ის განვითარებას დაუცველი ან არაიმედო-ს საწინააღმდეგოდ.

რადგან ყველა რეალური Django აპლიკაცია საბოლოო ჯამში უნდა გაიწეროს, და რადგან განვითარების შეცდომები (დატოვება `DEBUG=True`, static ფაილების არასწორი მართვა, საიდუმლოების ღამის მგრიდან, dev სერვერის გამოყენება) იწვევს რეალურ უსაფრთხოების და საიმედობის პრობლემებს, Django-ის სწორი განვითარების გაგება — stack, უსაფრთხოების თვალსაზრისით კრიტიკული პარამეტრები, static/media მართვა და თანამედროვე განვითარების პრაქტიკა — მნიშვნელოვანი, მაღალი კოეფიციენტის ცოდნაა, რომელიც ასახავს უნარს გაიწეროს production-ready აპლიკაციები, ხშირად განხილული და პროფესიონალურად აუცილებელი თემა ნებისმიერი Django დეველოპერისთვის, რომელიც პასუხისმგებელია ლაივ სისტემებზე.