Wdróż Django na Nodion

Wdróż Django krok po kroku

1. Dodaj Gunicorn, WhiteNoise i sterownik bazy danych Nodion uruchamia Gunicorn, ale go nie instaluje, więc musi on być w Twoich zależnościach. Gunicorn nie serwuje plików statycznych; to, co zapisze collectstatic, serwuje WhiteNoise. Przypnij wersję Pythona w .python-version, bo zakres taki jak requires-python = ">=3.10" wybiera najnowsze wydanie. requirements.txt

   Django>=5.2
   gunicorn
   whitenoise
   dj-database-url
   psycopg[binary]

2. Odczytuj ustawienia ze środowiska collectstatic działa podczas buildu, w którym istnieją tylko zmienne oznaczone jako Build, więc ustawienia muszą dać się zaimportować bez sekretów potrzebnych dopiero podczas działania aplikacji. Django sprawdza SECRET_KEY dopiero wtedy, gdy jest potrzebny. Dodaj WhiteNoise zaraz po SecurityMiddleware. settings.py

   import os
   import dj_database_url
   
   SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY", "")
   DEBUG = os.environ.get("DJANGO_DEBUG") == "1"
   ALLOWED_HOSTS = os.environ.get("DJANGO_ALLOWED_HOSTS", "").split(",")
   CSRF_TRUSTED_ORIGINS = [f"https://{h}" for h in ALLOWED_HOSTS if h]
   
   DATABASES = {"default": dj_database_url.config(conn_max_age=600)}
   
   STATIC_ROOT = BASE_DIR / "staticfiles"
   # MIDDLEWARE: "whitenoise.middleware.WhiteNoiseMiddleware"
   # right after "django.middleware.security.SecurityMiddleware"

3. Obsłuż health check przed sprawdzeniem hosta Health check Nodion odpytuje każdą instancję pod jej wewnętrznym adresem, którego nie ma w ALLOWED_HOSTS, więc Django odpowiedziałby kodem 400, a release nigdy nie trafiłby na produkcję. Umieść prosty middleware na pierwszym miejscu w MIDDLEWARE i ustaw w ustawieniach aplikacji /healthz jako ścieżkę health checku. health.py

   from django.http import HttpResponse
   
   
   class HealthCheckMiddleware:
       def __init__(self, get_response):
           self.get_response = get_response
   
       def __call__(self, request):
           if request.path == "/healthz":
               return HttpResponse("ok")
           return self.get_response(request)

4. Uruchamiaj migracje przy każdym wdrożeniu Linia release: w pliku Procfile uruchamia się raz na każdy build, po buildzie i przed startem nowej wersji. Jeśli zakończy się błędem, wdrożenie zostanie zatrzymane, a działająca wersja nadal obsługuje ruch. Procfile

   release: python manage.py migrate --noinput

5. Utwórz aplikację i bazę danych Utwórz aplikację ze swojego repozytorium w regionie EU Central, następnie bazę danych PostgreSQL w tym samym regionie i podłącz ją w zakładce Environment: przy następnym wdrożeniu pojawi się jako DATABASE_URL. Ustaw DJANGO_SECRET_KEY jako sekret i DJANGO_ALLOWED_HOSTS na nazwę hosta aplikacji oraz Twoje własne domeny, a potem zrób push.

Warto wiedzieć

• Celery i inne workeryDodaj do pliku Procfile worker: celery -A myproject worker razem z jawną linią web: gunicorn myproject.wsgi --bind 0.0.0.0:$PORT; bez linii web: domyślnym poleceniem staje się pierwszy wpis w Procfile inny niż release:. Następnie w zakładce Processes dodaj proces o nazwie worker bez portu. Valkey w tym samym regionie daje Ci REDIS_URL jako broker.
• ASGIDomyślne polecenie startowe używa WSGI. Dla Channels lub asynchronicznych widoków ustaw własną linię web:, na przykład z workerami Uvicorn, a serwer powiąż z 0.0.0.0:$PORT.
• Pliki z zależnościamirequirements.txt, poetry.lock i Pipfile.lock są instalowane bez zmian. Pipfile bez pliku lock nie instaluje niczego.

Czym Nodion zajmuje się za Ciebie

• Wdrożenia bez przestojów Wypchnij zmiany do swojej gałęzi, a Nodion zbuduje nowy release. Ruch przełącza się, gdy nowe instancje przejdą health check; nieudany release nie wpływa na działającą wersję. Aplikacje z lokalnym wolumenem są natomiast uruchamiane ponownie, bo dysk należy do jednej instancji.
• Bazy danych obok aplikacji Zarządzane PostgreSQL, pgvector, MySQL, Valkey i ClickHouse w tym samym regionie. Podłączone bazy danych trafiają do aplikacji jako DATABASE_URL, REDIS_URL lub CLICKHOUSE_URL.
• Środowiska podglądu dla pull requestów Włącz środowiska podglądu, a każdy pull request z Twojego repozytorium dostanie własną aplikację z własnym adresem URL i nowymi, pustymi bazami danych, tworzoną automatycznie lub ręcznie. Forki i pull requesty od botów są pomijane.
• Workery, zadania cron i skalowanie Uruchamiaj workery jako dodatkowe procesy tej samej aplikacji, planuj zadania w zakładce Cron i skaluj każdy proces do 16 instancji.
• Etap release W przypadku buildpacków linia release: w Procfile uruchamia się przy każdym nowym buildzie. Aplikacje z Dockerfile, a także ponowne wdrożenia i rollbacki do wcześniejszego obrazu, korzystają z polecenia release ustawionego w samej aplikacji, które ma też pierwszeństwo przed linią z Procfile. W przypadku stron statycznych krok release działa w obrazie zawierającym tylko zbudowane pliki.
• Logi i metryki W dashboardzie znajdziesz logi z builda, release'u i działania aplikacji oraz metryki CPU, pamięci, dysku i sieci dla każdej instancji.
• Domeny i HTTPS Domyślna nazwa hosta z HTTPS od pierwszego wdrożenia; Twoje własne domeny automatycznie dostają certyfikaty.

Warto przeczytać

• Alternatywy dla Heroku z hostingiem w UE: porównanie 5 opcji Niemiecka platforma i amerykańskie chmury z regionami w UE, porównane pod względem siedziby, regionów i zarządzanych baz danych.
• Środowiska podglądu: aplikacja dla każdego pull requesta Działająca kopia Twojej aplikacji dla każdego pull requesta: do czego przydają się środowiska podglądu, gdzie robi się trudno i jak obsługuje je Nodion.

Django na Nodion: pytania i odpowiedzi