როგორ მართავთ პარამეტრებს სხვადსხვა გარემოებში?

Question

Accepted Answer

Django კონფიგურაცია მდებარეობს `settings.py`-ში, მაგრამ რეალური აპლიკაციებმა საჭიროებს **სხვადსხვა პარამეტრებს თითოეული გარემოსთვის** (development, staging, production) და უნდა დაიცვან **საიდუმლოებები კოდის გარეთ**. ამის სწორად მართვა არის ოპერაციული აუცილებლობა და უსაფრთხოების მოთხოვნა.

## ერთი settings.py-ის პრობლემა

```python
# ❌ hardcoded, environment-mixed, and INSECURE settings
DEBUG = True                                    # must be False in production!
SECRET_KEY = "hardcoded-secret-in-code"          # ❌ secret committed to git
DATABASES = {"default": {"PASSWORD": "prod-pw"}} # ❌ production password in code
```

მნიშვნელობების hardcoding ერევს გარემოებს და — კრიტიკულად — ათავსებს საიდუმლოებებს (SECRET_KEY, მონაცემთა ბაზის პაროლები, API გასაღებები) version control-ში, რაც სერიოზული უსაფრთხოების დარღვევაა.

## გამოსავალი 1: კონფიგურაციის წაკითხვა გარემოს ცვლადებიდან

```python
import os
from pathlib import Path

SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]    # from the environment, NOT code
DEBUG = os.environ.get("DJANGO_DEBUG", "False") == "True"
ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "").split(",")
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": os.environ["DB_NAME"],
        "PASSWORD": os.environ["DB_PASSWORD"],   # injected per environment
    }
}
# tools like django-environ / python-decouple make this cleaner (+ .env file support)
```

კონფიგურაციის წაკითხვა (განსაკუთრებით საიდუმლოებების) **გარემოს ცვლადებიდან** ის კოდის გარეთ რჩება — იგივე codebase-იმ ნებისმიერ გარემოში მუშაობს სხვადსხვა injected მნიშვნელობებით (twelve-factor მიდგომა).

## გამოსავალი 2: settings ფაილების გაყოფა გარემოს მიხედვით

```text
settings/
  base.py          # shared settings (apps, middleware, templates)
  development.py   # from base import *; DEBUG=True, local DB, debug toolbar
  production.py    # from base import *; DEBUG=False, security hardening, real DB
  test.py          # test-specific settings
```

```python
# production.py
from .base import *
DEBUG = False
ALLOWED_HOSTS = ["example.com"]
SECURE_SSL_REDIRECT = True            # production-only security settings
# select via: DJANGO_SETTINGS_MODULE=config.settings.production
```

Settings-ის გაყოფა საერთო `base.py`-სა და გარემოს კონკრეტული ფაილებში (რომელიც აირჩევა `DJANGO_SETTINGS_MODULE` გამოყენებით) ს깔ესად ყოფს გარემოსთან დაკავშირებული კონფიგურაციას, ხოლო საერთო პარამეტრებს იზიარებს.

## კრიტიკული production პარამეტრები

```python
DEBUG = False                  # ❗ NEVER True in production — leaks sensitive error info
ALLOWED_HOSTS = ["example.com"] # required when DEBUG=False
SECRET_KEY = os.environ[...]    # strong, secret, from the environment
# + SECURE_SSL_REDIRECT, SESSION_COOKIE_SECURE, HSTS, etc. for hardening
```

```text
✓ NEVER commit secrets — use env vars / a secret manager; gitignore .env
✓ DEBUG=False in production (DEBUG=True leaks tracebacks, settings → security risk)
✓ Commit a .env.example documenting required variables (no real values)
```

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

პარამეტრების მართვა სხვადსხვა გარემოებში არის ოპერაციული აუცილებლობა და კრიტიკული უსაფრთხოების პრაქტიკა ნებისმიერი რეალური Django აპლიკაციისთვის.

აპლიკაციებმა უნდა განსხვავებულად მოიქცნენ გარემოების გასწვრივ — development-ი საჭიროებს `DEBUG=True`-სა და მოსახერხებელ ლოკალურ პარამეტრებს, ხოლო production მოითხოვს `DEBUG=False`-ს, უსაფრთხოების გამკაცრებას, რეალურ მონაცემთა ბაზებს და სათანადო hosts-ებს — და ერთი hardcoded `settings.py` ყველა ამას ვერ გაკმაყოფილებს.

გარკვევით აღმეზობელი, ეს არის **მნიშვნელოვანი უსაფრთხოების საზრუნავი**: საიდუმლოების hardcoding (SECRET_KEY, მონაცემთა ბაზის პაროლები, API გასაღებები) ათავსებს მათ version control-ში, ერთი ყველაზე ხშირი და სერიოზული უსაფრთხოების დარღვევა (ნებისმიერმა, ვისაც აქვს რეპოზიტორიის ხელმისაწვდომობა, ან public რეპოზიტორიაში, აღმოაჩენს თქვენი აპლიკაციისა და მონაცემების გასაღებებს).

ამონახსნების გაგება — კონფიგურაციის და საიდუმლოების წაკითხვა **გარემოს ცვლადებიდან** (მათი კოდის გარეთ დატოვება, twelve-factor მიდგომა, ხშირად django-environ-ის მსგავსი ინსტრუმენტებითა და gitignored `.env` ფაილებით) და **settings-ის გაყოფა** საერთო ბაზისა და გარემოს კონკრეტული ფაილებში — არის აუცილებელი Django-ის უსაფრთხოდ და სწორად development-ის თვის.

**კრიტიკული production პარამეტრების** ცოდნა (განსაკუთრებით რომ `DEBUG` უნდა იყოს `False` production-ში, რადგან `DEBUG=True` გამოაშკარავებს tracebacks, source paths და პარამეტრებს მოწინააღმდეგეებისთვის, პლუს `ALLOWED_HOSTS` და უსაფრთხოების გამკაცრება) არის უპირობო production ცოდნა.

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