Wdróż Python na Nodion

Wdróż Python krok po kroku

1. Dodaj jeden plik zależności do repozytorium Nodion wybiera instalator według pierwszego znalezionego pliku: poetry.lock (Poetry), Pipfile.lock (Pipenv), requirements.txt (pip), a na końcu sam pyproject.toml, instalowany przez pip install . (lub przez Poetry, jeśli ma sekcję [tool.poetry]). Plik uv.lock jest ignorowany, a Pipfile bez pliku lock nie instaluje niczego.
2. Przypnij wersję Pythona Nodion odczytuje .python-version, potem runtime.txt, a potem requires-python w pyproject.toml; jeśli nie ma żadnego z nich, dostajesz 3.13. Zakres taki jak requires-python = ">=3.10" wskazuje najnowsze opublikowane wydanie, obecnie 3.15, więc przypnij wersję, na której testujesz. .python-version

   3.13

3. Poznaj domyślne polecenie startowe Nodion sprawdza Twoje zależności w tej kolejności: Django (z manage.py) uruchamia przez Gunicorn, FastAPI lub Starlette przez Uvicorn, a Flask przez Gunicorn. Serwer nie jest dodawany automatycznie, więc wpisz go do zależności. Bez frameworka Nodion uruchamia python app.py lub python main.py, a ten skrypt musi nasłuchiwać na 0.0.0.0 i na porcie PORT ustawionym przez Nodion.
4. Wszystko inne uruchamiaj przez Procfile Linia web: zastępuje polecenie domyślne. Bez Django, FastAPI, Flask, app.py i main.py plik Procfile musi definiować proces, web: lub worker:; w przeciwnym razie build kończy się błędem wskazującym brakujący element. Linia release: uruchamia się raz na każdy build, przed startem nowej wersji: to miejsce na migracje. Procfile

   web: gunicorn myapp.wsgi --bind 0.0.0.0:$PORT
   release: alembic upgrade head

5. Utwórz aplikację i zrób push Utwórz aplikację ze swojego repozytorium GitHub, GitLab, Bitbucket lub Gitea w regionie EU Central. Zmienne, które odczytuje Twój build, potrzebują w zakładce Environment zaznaczonej opcji Build; wszystkie inne, a także podłączone bazy danych, takie jak DATABASE_URL, istnieją dopiero podczas działania aplikacji. Od tej chwili każdy push buduje nowy release.

Warto wiedzieć

• Workery i inne typy procesówSama linia worker: niczego nie uruchamia: w zakładce Processes dodaj proces o tej samej nazwie, bez portu. Zostaw obok jawną linię web:, bo bez niej domyślnym poleceniem staje się pierwszy wpis w Procfile inny niż release:. Aplikacja złożona tylko z workerów, na przykład bot, ustawia zamiast tego web na 0 instancji.
• Wykrywanie uwzględnia też pliki lockNodion szuka Django, FastAPI i Flask w requirements.txt, Pipfile, pyproject.toml, poetry.lock i Pipfile.lock. Pliki lock zawierają też zależności pośrednie, więc biblioteka, która instaluje FastAPI jako zależność, na przykład Gradio, może włączyć domyślne polecenie dla FastAPI. Linia web: rozstrzyga sprawę.
• Projekty uvPlik lock narzędzia uv nie jest odczytywany. Wyeksportuj przypięte wersje do requirements.txt, na przykład przez uv export --no-emit-project -o requirements.txt, i dodaj ten plik do repozytorium; w przeciwnym razie Nodion instaluje z pyproject.toml bez pliku lock.

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ć

• Dlaczego zbudowaliśmy własne buildpacki na Ubuntu 26.04 Nasze buildpacki są zgodne ze specyfikacją Cloud Native Buildpacks, ale stack, buildpacki językowe i wersje runtime'ów są nasze. Wyjaśniamy dlaczego.
• Cloud Native Buildpacks: czym są i jak działają Buildpacki zamieniają Twój kod źródłowy w obraz kontenera bez Dockerfile. Czym są i jak działają.

Python na Nodion: pytania i odpowiedzi