Fai il deploy di Streamlit su Nodion

Deploy di Streamlit passo dopo passo

1. Aggiungi Streamlit e fissa la versione di Python Elenca streamlit e le tue librerie per i dati in requirements.txt. Fissa in .python-version una versione di Python supportata dalle tue librerie, perché un intervallo seleziona la release più recente. requirements.txt

   streamlit
   pandas

2. Avvia Streamlit da un Procfile Senza questa riga Nodion eseguirebbe python app.py, che lancia lo script ma non avvia alcun server. I flag mettono Streamlit in ascolto su tutte le interfacce e sulla porta PORT impostata da Nodion, e saltano la richiesta interattiva del primo avvio. Procfile

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

3. Conserva i dati riservati nelle variabili d'ambiente Non fare il commit di .streamlit/secrets.toml. Imposta le chiavi API come variabili segrete nella scheda Environment e leggile con os.environ; esistono a runtime, cioè proprio quando Streamlit esegue il tuo script.
4. Crea l'app e fai push Crea un'applicazione dal tuo repository GitHub, GitLab, Bitbucket o Gitea nella regione EU Central. Le app che caricano DataFrame hanno bisogno di memoria, quindi 1 GB è un buon punto di partenza. Streamlit risponde a / con 200, quindi l'health check predefinito funziona così com'è.

Da sapere

• Una sola istanza più grandeStreamlit tiene lo stato di ogni sessione nella memoria del processo che la serve. Con più istanze, un browser che si riconnette può finire su un'altra istanza e ricominciare da capo, quindi una sola istanza più grande è di solito la scelta più semplice.
• File e cachest.cache_data e i file scritti a runtime restano sull'istanza e spariscono dopo il deploy successivo o dopo la sostituzione giornaliera con un'istanza nuova. Tieni i dati che ti servono in un database, in un bucket o in un volume.

Cosa gestisce Nodion per te

• Deploy senza downtime Fai push sul tuo branch e Nodion crea una nuova release. Il traffico passa alle nuove istanze solo quando superano l'health check; una release fallita lascia attiva quella in esecuzione. Le app con un volume locale invece si riavviano, perché il disco appartiene a una sola istanza.
• Database accanto all'app PostgreSQL, pgvector, MySQL, Valkey e ClickHouse gestiti, nella stessa regione. I database collegati arrivano come DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Anteprime per ogni pull request Attiva le anteprime: ogni pull request del tuo repository riceve un'app dedicata, con un proprio URL e database nuovi e vuoti, creata automaticamente o manualmente. Le pull request dai fork e quelle dei bot vengono ignorate.
• Worker, cron job e scalabilità Esegui i worker come processi aggiuntivi della stessa app, pianifica i job nella scheda Cron e scala ogni processo fino a 16 istanze.
• Fase di release Con i buildpack, la riga release: del Procfile viene eseguita a ogni nuova build. Le app con Dockerfile, così come i redeploy e i rollback a un'immagine precedente, usano un comando di release impostato sull'app stessa, che ha anche la precedenza sulla riga del Procfile. Nei siti statici, la fase di release gira in un'immagine che contiene solo i file generati dalla build.
• Log e metriche Nella dashboard trovi log di build, release e runtime, oltre alle metriche di CPU, memoria, disco e rete per ogni istanza.
• Domini e HTTPS Un hostname predefinito con HTTPS dal primo deploy; i tuoi domini ricevono i certificati in automatico.

Per approfondire

• Cos'è il PaaS? Platform as a Service spiegato Cosa fa un PaaS al posto tuo, cosa resta a te, come si confronta con IaaS, SaaS, serverless e Kubernetes e cosa controllare prima di sceglierne uno.

Streamlit su Nodion: domande e risposte