Faça deploy de Streamlit na Nodion

Faça deploy de Streamlit passo a passo

1. Adicione o Streamlit e fixe a versão de Python Inclua o streamlit e as suas bibliotecas de dados em requirements.txt. Fixe em .python-version uma versão de Python suportada pelas suas bibliotecas, porque um intervalo escolhe a versão mais recente. requirements.txt

   streamlit
   pandas

2. Arranque o Streamlit a partir de um Procfile Sem esta linha, a Nodion executaria python app.py, que corre o script mas não arranca nenhum servidor. As flags põem o Streamlit a escutar em todas as interfaces e na porta PORT definida pela Nodion, e evitam a pergunta interativa da primeira execução. Procfile

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

3. Guarde os segredos em variáveis de ambiente Não faça commit de .streamlit/secrets.toml. Defina as chaves de API como variáveis secretas no separador Environment e leia-as com os.environ; existem em runtime, que é precisamente quando o Streamlit executa o seu script.
4. Crie a aplicação e faça push Crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea na região EU Central. As aplicações que carregam DataFrames precisam de memória, por isso 1 GB é um ponto de partida razoável. O Streamlit responde 200 em /, pelo que o health check por omissão funciona tal como está.

A ter em conta

• Uma única instância maiorO Streamlit guarda o estado de cada sessão na memória do processo que a serve. Com várias instâncias, um browser que volte a ligar-se pode cair noutra e recomeçar do zero, por isso uma única instância maior é normalmente a escolha mais simples.
• Ficheiros e cachesO st.cache_data e os ficheiros escritos em runtime ficam na instância e desaparecem após o deploy seguinte ou após a substituição diária por uma instância nova. Guarde os dados de que precisa numa base de dados, num bucket ou num volume.

O que a Nodion gere por si

• Deploys sem downtime Faça push para o seu branch e a Nodion cria uma nova release. O tráfego só muda quando as novas instâncias passam no health check; se uma release falhar, a que está em execução mantém-se. Em vez disso, as aplicações com um volume local são reiniciadas, porque o disco pertence a uma única instância.
• Bases de dados junto à aplicação PostgreSQL, pgvector, MySQL, Valkey e ClickHouse geridos, na mesma região. As bases de dados associadas chegam como DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Pré-visualizações por pull request Ative as pré-visualizações e cada pull request do seu repositório passa a ter uma aplicação própria, com URL próprio e bases de dados novas e vazias, criada automática ou manualmente. Os forks e os pull requests de bots são ignorados.
• Workers, cron jobs e escalabilidade Execute workers como processos adicionais da mesma aplicação, agende tarefas no separador Cron e escale cada processo até 16 instâncias.
• Etapa de release Com buildpacks, uma linha release: do Procfile é executada a cada novo build. As aplicações com Dockerfile, bem como os redeploys ou rollbacks para uma imagem anterior, usam um comando de release definido na própria aplicação, que também tem prioridade sobre a linha do Procfile. Nos sites estáticos, a etapa de release é executada numa imagem que contém apenas os ficheiros gerados pelo build.
• Logs e métricas Logs de build, release e runtime, além de métricas de CPU, memória, disco e rede de cada instância, no dashboard.
• Domínios e HTTPS Um hostname atribuído por omissão com HTTPS desde o primeiro deploy; os seus próprios domínios recebem certificados automaticamente.

Para saber mais

• O que é PaaS? A Platform as a Service explicada O que uma PaaS gere, o que fica do seu lado, como se compara a IaaS, SaaS, serverless e Kubernetes e o que verificar antes de escolher.

Streamlit na Nodion: perguntas e respostas