Faça deploy de Rust na Nodion

Faça deploy de Rust passo a passo

1. Escute em 0.0.0.0:$PORT A Nodion define PORT para o processo web. Leia essa variável e escute em 0.0.0.0, não em 127.0.0.1, caso contrário o health check não consegue chegar à aplicação. Com o Actix Web, converta a porta para u16 e passe ("0.0.0.0", port) a HttpServer::bind. src/main.rs

   use axum::{routing::get, Router};
   
   #[tokio::main]
   async fn main() {
       let port = std::env::var("PORT").unwrap_or_else(|_| "8080".to_string());
       let app = Router::new().route("/", get(|| async { "ok" }));
       let listener = tokio::net::TcpListener::bind(format!("0.0.0.0:{port}"))
           .await
           .unwrap();
       axum::serve(listener, app).await.unwrap();
   }

2. Faça commit do Cargo.lock e mantenha [package] no início Com um Cargo.lock, a Nodion faz o build com --locked, por isso um lockfile que não corresponda ao Cargo.toml faz falhar o build. A Nodion obtém o nome do pacote da primeira linha name = do Cargo.toml, por isso mantenha a secção [package] no início do ficheiro. Cargo.toml

   [package]
   name = "myapp"
   version = "0.1.0"
   edition = "2024"
   
   [dependencies]
   axum = "0.8"
   tokio = { version = "1", features = ["full"] }

3. Os binários adicionais passam a tipos de processo Todos os executáveis em target/release vão para a imagem, por exemplo um gerado a partir de src/bin/worker.rs. O processo web executa o binário do pacote; cada um dos outros binários passa a ser um tipo de processo com o mesmo nome. Para executar worker, adicione no separador Processes um processo com esse nome e sem porta, e deixe o comando vazio.
4. Crie a aplicação No dashboard, crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea e escolha o branch e a região EU Central. Mantenha a estratégia de build em Buildpacks; se o repositório tiver um Dockerfile, o formulário escolhe Dockerfile em vez disso.
5. Associe o PostgreSQL e execute as migrações No separador Environment, associe uma base de dados da mesma região; DATABASE_URL chega no próximo deploy, nunca durante o build. Com SQLx, execute cargo sqlx prepare e faça commit da pasta .sqlx para que as macros query! compilem sem base de dados. Execute as migrações no arranque com sqlx::migrate!(), ou compile um binário migrate e execute-o como passo de release, uma vez por build, antes de a nova versão arrancar. Procfile

   release: migrate

A ter em conta

• Apenas o Rust estável mais recenterust-toolchain.toml e rust-version não selecionam uma toolchain mais antiga: cada build usa o Rust estável mais recente que a Nodion compilou. As toolchains nightly não estão disponíveis, por isso os crates que precisam de funcionalidades nightly precisam de um Dockerfile.
• WorkspacesA Nodion executa cargo build --release no Base directory sem --workspace. Num workspace virtual (um Cargo.toml na raiz só com [workspace]), isso compila todos os membros; com um pacote na raiz, compila apenas esse pacote, por isso liste em workspace.default-members todos os membros de que precisa. Um workspace virtual não tem nome de pacote, por isso dê ao binário web o nome server, api, web ou app.

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

• Porque criámos os nossos próprios buildpacks no Ubuntu 26.04 Os nossos buildpacks seguem a especificação Cloud Native Buildpacks, mas a stack, os buildpacks de linguagem e as versões de runtime são nossos. Eis porquê.
• Cloud Native Buildpacks: o que são e como funcionam Os buildpacks transformam o seu código-fonte numa imagem de contentor sem Dockerfile. O que são e como funcionam.

Rust na Nodion: perguntas e respostas