Fai il deploy di Rust su Nodion

Deploy di Rust passo dopo passo

1. Metti il server in ascolto su 0.0.0.0:$PORT Nodion imposta PORT per il processo web. Leggila e metti il server in ascolto su 0.0.0.0, non su 127.0.0.1, altrimenti l'health check non raggiunge l'app. Con Actix Web, converti la porta in u16 e passa ("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. Fai il commit di Cargo.lock e tieni [package] in cima Se c'è un Cargo.lock, Nodion compila con --locked, quindi un lock file che non corrisponde a Cargo.toml fa fallire la build. Nodion prende il nome del package dalla prima riga name = di Cargo.toml, quindi tieni la sezione [package] in cima. Cargo.toml

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

3. I binari aggiuntivi diventano tipi di processo Ogni eseguibile in target/release finisce nell'immagine, per esempio uno da src/bin/worker.rs. Il processo web avvia il binario del package; ogni altro binario diventa un tipo di processo con lo stesso nome. Per avviare worker, nella scheda Processes aggiungi un processo con quel nome e senza porta, e lascia vuoto il comando.
4. Crea l'app Nella dashboard crea un'applicazione dal tuo repository GitHub, GitLab, Bitbucket o Gitea, scegli il branch e la regione EU Central. Lascia la strategia di build su Buildpacks; se il repository contiene un Dockerfile, il modulo seleziona invece Dockerfile.
5. Collega PostgreSQL ed esegui le migrazioni Nella scheda Environment collega un database della stessa regione; DATABASE_URL arriva con il deploy successivo, mai durante la build. Con SQLx, esegui cargo sqlx prepare e fai il commit della cartella .sqlx, così le macro query! compilano senza database. Esegui le migrazioni all'avvio con sqlx::migrate!(), oppure crea un binario migrate ed eseguilo come fase di release, una volta per build, prima che parta la nuova versione. Procfile

   release: migrate

Da sapere

• Solo il Rust stabile più recenterust-toolchain.toml e rust-version non selezionano una toolchain più vecchia: ogni build usa il Rust stabile più recente compilato da Nodion. Le toolchain nightly non sono disponibili, quindi i crate che richiedono funzionalità nightly hanno bisogno di un Dockerfile.
• WorkspaceNodion esegue cargo build --release nella base directory senza --workspace. In un workspace virtuale (un Cargo.toml nella root con solo [workspace]) questo compila tutti i membri; con un package nella root compila solo quel package, quindi elenca in workspace.default-members tutti i membri che ti servono. Un workspace virtuale non ha un nome di package, quindi chiama il binario web server, api, web o app.

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

• Perché abbiamo creato i nostri buildpack su Ubuntu 26.04 I nostri buildpack seguono la specifica Cloud Native Buildpacks, ma lo stack, i buildpack dei linguaggi e le versioni dei runtime sono nostri. Ecco perché.
• Cloud Native Buildpacks: cosa sono e come funzionano I buildpack trasformano il tuo codice sorgente in un'immagine container senza Dockerfile. Cosa sono e come funzionano.

Rust su Nodion: domande e risposte