Wdróż Streamlit na Nodion

Wdróż Streamlit krok po kroku

1. Dodaj Streamlit i przypnij wersję Pythona Wpisz streamlit i swoje biblioteki do pracy z danymi do requirements.txt. W .python-version przypnij wersję Pythona, którą obsługują Twoje biblioteki, bo zakres wybiera najnowsze wydanie. requirements.txt

   streamlit
   pandas

2. Uruchom Streamlit z pliku Procfile Bez tej linii Nodion uruchomiłby python app.py, co wykonuje skrypt, ale nie startuje serwera. Flagi ustawiają nasłuchiwanie Streamlit na wszystkich interfejsach i na porcie PORT ustawionym przez Nodion oraz pomijają interaktywne pytanie przy pierwszym uruchomieniu. Procfile

   web: streamlit run app.py --server.port $PORT --server.address 0.0.0.0 --server.headless true

3. Trzymaj sekrety w zmiennych środowiskowych Nie dodawaj .streamlit/secrets.toml do repozytorium. Ustaw klucze API jako zmienne oznaczone jako sekret w zakładce Environment i odczytuj je przez os.environ; istnieją podczas działania aplikacji, czyli wtedy, gdy Streamlit wykonuje Twój skrypt.
4. Utwórz aplikację i zrób push Utwórz aplikację ze swojego repozytorium GitHub, GitLab, Bitbucket lub Gitea w regionie EU Central. Aplikacje wczytujące DataFrame potrzebują więcej pamięci, więc 1 GB to rozsądny początek. Streamlit odpowiada na / kodem 200, więc domyślny health check działa bez zmian.

Warto wiedzieć

• Jedna większa instancjaStreamlit trzyma stan każdej sesji w pamięci procesu, który ją obsługuje. Przy kilku instancjach przeglądarka, która połączy się ponownie, może trafić na inną i zacząć od nowa, więc jedna większa instancja to zwykle prostszy wybór.
• Pliki i cachest.cache_data i pliki zapisane podczas działania aplikacji znajdują się na instancji i znikają po następnym wdrożeniu lub codziennej wymianie instancji. Dane, których potrzebujesz, trzymaj w bazie danych, buckecie lub wolumenie.

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ć

• Czym jest PaaS? Wyjaśniamy Platform as a Service Co przejmuje PaaS, co zostaje po Twojej stronie, jak wypada na tle IaaS, SaaS, serverless i Kubernetes oraz co sprawdzić przed wyborem.

Streamlit na Nodion: pytania i odpowiedzi