Kuinka otat Django-sovelluksen käyttöön tuotannossa?

Question

Accepted Answer

Django-sovelluksen käyttöönotto tuotannossa edellyttää sen ajamista asianmukaisen **WSGI/ASGI-palvelimen** ja **web-palvelimen** takana, staattisten tiedostojen oikean palvelun, asetusten turvaamisen ja tietokannan hallinnon — hyvin erilainen prosessi kuin sisäänrakennetun kehityspalvelimen käyttö (joka **ei** ole tuotantoon tarkoitettu).

## Tuotannon pinottava arkkitehtuuri

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

Kehityspalvelin ei sovellu tuotantoon. Vakioarkkitehtuuri: **sovelluspalvelin** (Gunicorn/uWSGI WSGI:lle, Uvicorn ASGI:lle/asynkroniselle) ajaa Djangoa useilla työprosesseilla, **web-palvelimen** (nginx) takana, joka käsittelee saapuvat yhteydet, TLS:n ja staattiset tiedostot.

## Tuotannon asetukset (kriittiset turvallisuuden kannalta)

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

## Staattiset tiedostot

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

## Tietokanta ja migraatiot

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

## Tyypillinen käyttöönottotarkistuslista

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

## Modernit käyttöönottomenetelmät

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

## Miksi tämä on tärkeää

Django-sovelluksen oikea käyttöönotto tuotannossa on olennaista osaamista, kun sovellusten viedään kehityksestä todelliseen käyttöön, ja se edellyttää täysin erilaisia huomioita kuin paikallinen kehitys — väärä toteutus johtaa tietoturvaaukoihin, huonoon suorituskykyyn tai rikkoutuneisiin sovelluksiin.

Tuotannon pinottavan arkkitehtuurin ymmärtäminen on perustava tieto: sisäänrakennettu kehityspalvelin (`runserver`) ei ole eksplisiittisesti tuotantoon (se on yksisäikeinen, epäturvallinen ja ei kestä kuormaa), joten Django-sovellus on ajettava asianmukaisen **sovelluspalvelimen** (Gunicorn/uWSGI WSGI:lle tai Uvicorn ASGI:lle/asynkroniselle) takana useilla työprosesseilla, edessään **web-palvelimen** (nginx) kanssa, joka käsittelee yhteydet, TLS:n ja staattisten tiedostojen palvelun.

Useat seikat ovat turvallisuuden ja oikeellisuuden kannalta kriittisiä: **tuotannon asetukset** (erityisesti `DEBUG=False`, joka on pakollinen, koska `DEBUG=True` paljastaa arkaluontoisia seurantatietoja ja konfiguraatiota hyökkääjille, lisäksi `ALLOWED_HOSTS`, salaisuus `SECRET_KEY` ympäristöstä ja HTTPS-pakottaminen), **staattisten tiedostojen käsittely** (`collectstatic` ajaminen ja tiedostojen palvelu nginx:in/CDN:n/WhiteNoisen kautta, koska Django ei palvele niitä itse tuotannossa — yleinen käyttöönottovika), ja **tietokannan hallinto** (oikea tietokanta kuten PostgreSQL, migraatioiden soveltaminen, varmuuskopiointi).

Käyttöönottotarkistuslistan, modernien menetelmien (Docker/säiliöt, hallitut alustat, pilvivarasto medialle, Celery-työprosessit erillisinä palveluina, horisontaalinen skaalaus tilattomalla sovelluksella) ja operatiivisten huomioiden (loggaus, seuranta Sentrylla, terveystarkistukset, prosessinhallinto) tunteminen on se, mitä erottaa toimivan tuotannon käyttönoton hauraasta tai epäturvallisesta versiosta.

Koska jokainen todellinen Django-sovellus on lopulta otettava käyttöön tuotannossa, ja koska käyttönottovirheet (`DEBUG=True`:n jättäminen, staattisten tiedostojen väärä käsittely, salaisuuksien paljastaminen, kehityspalvelimen käyttö) aiheuttavat todellisia turvallisuus- ja luotettavuusongelmia, Django-sovelluksen asianmukaisen käyttönoton ymmärtäminen — pinottava arkkitehtuuri, turvallisuuden kannalta kriittiset asetukset, staattisten/median tiedostojen käsittely ja modernit käyttöönottokäytännöt — on tärkeää, korkean panoksen osaamista, joka heijastaa kyvykkyyttä toimittaa tuotantoon valmiita sovelluksia. Se on usein relevantti ja ammattimaisesti olennainen aihe kaikille Django-kehittäjille, jotka vastaavat julkisista järjestelmistä.