Streamlit auf Nodion deployen

Streamlit Schritt für Schritt deployen

1. Streamlit hinzufügen und Python pinnen Trag streamlit und deine Daten-Bibliotheken in die requirements.txt ein. Pinne in .python-version eine Python-Version, die deine Bibliotheken unterstützen, denn ein Bereich nimmt das neueste Release. requirements.txt

   streamlit
   pandas

2. Streamlit per Procfile starten Ohne diese Zeile würde Nodion python app.py starten; das führt das Skript aus, startet aber keinen Server. Die Flags binden Streamlit an alle Interfaces und den PORT, den Nodion setzt, und überspringen die interaktive Abfrage beim ersten Start. Procfile

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

3. Secrets in Environment-Variablen ablegen Committe keine .streamlit/secrets.toml. Setz API-Keys auf dem Tab Environment als Secret und lies sie mit os.environ; sie gibt es zur Laufzeit, und genau dann führt Streamlit dein Skript aus.
4. App anlegen und pushen Lege eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository in der Region EU Central an. Apps, die DataFrames laden, brauchen Speicher, 1 GB ist ein vernünftiger Start. Streamlit beantwortet / mit 200, der Standard-Health-Check funktioniert also ohne Änderung.

Gut zu wissen

• Lieber eine größere InstanzStreamlit hält den Zustand jeder Session im Speicher des Prozesses, der sie bedient. Mit mehreren Instanzen kann ein Browser nach einem Reconnect auf einer anderen landen und von vorn beginnen; eine größere Instanz ist meist die einfachere Wahl.
• Dateien und Cachesst.cache_data und zur Laufzeit geschriebene Dateien liegen auf der Instanz und sind nach dem nächsten Deploy oder dem täglichen Austausch gegen eine frische Instanz weg. Daten, die du brauchst, gehören in eine Datenbank, einen Bucket oder ein Volume.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Was ist PaaS? Platform as a Service erklärt Was eine PaaS übernimmt, was bei dir bleibt, der Vergleich zu IaaS, SaaS, Serverless und Kubernetes, und was du prüfst, bevor du eine wählst.

Streamlit auf Nodion: Fragen und Antworten