Deploy Rust op Nodion

Rust stap voor stap deployen

1. Luister op 0.0.0.0:$PORT Nodion stelt PORT in voor het webproces. Lees die uit en bind aan 0.0.0.0, niet aan 127.0.0.1, anders kan de health check de app niet bereiken. Parse met Actix Web de poort als u16 en geef ("0.0.0.0", port) door aan 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. Commit Cargo.lock en houd [package] bovenaan Met een Cargo.lock bouwt Nodion met --locked, dus een lockbestand dat niet overeenkomt met Cargo.toml laat de build mislukken. Nodion haalt de naam van het package uit de eerste name =-regel in Cargo.toml, dus houd de sectie [package] bovenaan. Cargo.toml

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

3. Extra binaries worden procestypen Elk uitvoerbaar bestand in target/release gaat mee in de image, bijvoorbeeld een uit src/bin/worker.rs. Het webproces start de binary van het package; elke andere binary wordt een procestype met dezelfde naam. Om worker te draaien, voeg je op het tabblad Processes een proces met die naam zonder poort toe en laat je het commando leeg.
4. Maak de app aan Maak in het dashboard een applicatie aan vanuit je GitHub-, GitLab-, Bitbucket- of Gitea-repository en kies de branch en de regio EU Central. Laat de buildstrategie op Buildpacks staan; staat er een Dockerfile in de repository, dan kiest het formulier in plaats daarvan Dockerfile.
5. Koppel PostgreSQL en draai migraties Koppel op het tabblad Environment een database uit dezelfde regio; DATABASE_URL komt binnen bij de volgende deployment, nooit tijdens de build. Met SQLx draai je cargo sqlx prepare en commit je de map .sqlx, zodat de query!-macro's zonder database compileren. Draai migraties bij het opstarten met sqlx::migrate!(), of bouw een migrate-binary en draai die als releasestap, één keer per build voordat de nieuwe versie start. Procfile

   release: migrate

Goed om te weten

• Alleen de nieuwste stabiele Rust-versierust-toolchain.toml en rust-version kiezen geen oudere toolchain: elke build gebruikt de nieuwste stabiele Rust die Nodion heeft gebouwd. Nightly-toolchains zijn niet beschikbaar, dus crates die nightly-features nodig hebben, hebben een Dockerfile nodig.
• WorkspacesNodion draait cargo build --release in de Base directory zonder --workspace. In een virtuele workspace (een Cargo.toml in de root met alleen [workspace]) bouwt dat alle members; met een package in de root bouwt het alleen dat package, dus zet elke member die je nodig hebt in workspace.default-members. Een virtuele workspace heeft geen packagenaam, dus noem de webbinary server, api, web of app.

Wat Nodion voor je regelt

• Deploys zonder downtime Push naar je branch en Nodion bouwt een nieuwe release. Het verkeer schakelt over zodra de nieuwe instanties hun health check doorstaan; een mislukte release laat de draaiende versie staan. Apps met een lokaal volume herstarten in plaats daarvan, omdat de schijf bij één instantie hoort.
• Databases naast de app Managed PostgreSQL, pgvector, MySQL, Valkey en ClickHouse in dezelfde regio. Gekoppelde databases komen binnen als DATABASE_URL, REDIS_URL of CLICKHOUSE_URL.
• Previews per pull request Zet previews aan en pull requests uit je repository krijgen een eigen app met een eigen URL en nieuwe, lege databases, automatisch of handmatig aangemaakt. Forks en pull requests van bots worden overgeslagen.
• Workers, cronjobs en schalen Draai workers als extra processen van dezelfde app, plan jobs op het tabblad Cron en schaal elk proces naar maximaal 16 instanties.
• Releasestap Met buildpacks draait een release:-regel in het Procfile bij elke nieuwe build. Dockerfile-apps, en redeploys of rollbacks naar een eerdere image, gebruiken een releasecommando dat op de app zelf is ingesteld en dat ook voorrang heeft op de Procfile-regel. Bij statische sites draait een releasestap in een image die alleen de gebouwde bestanden bevat.
• Logs en metrics Build-, release- en runtimelogs plus metrics voor CPU, geheugen, schijf en netwerk van elke instantie in het dashboard.
• Domeinen en HTTPS Een standaardhostnaam met HTTPS vanaf de eerste deploy; je eigen domeinen krijgen automatisch certificaten.

Verder lezen

• Waarom we onze eigen buildpacks op Ubuntu 26.04 bouwden Onze buildpacks volgen de specificatie van Cloud Native Buildpacks, maar de stack, de taalbuildpacks en de runtimeversies zijn van ons. Dit is waarom.
• Cloud Native Buildpacks uitgelegd Buildpacks maken van je broncode een containerimage zonder Dockerfile. Wat ze zijn en hoe ze werken.

Rust op Nodion: vragen en antwoorden