Déployez Rust sur Nodion

Déployez Rust étape par étape

1. Écoutez sur 0.0.0.0:$PORT Nodion définit la variable PORT pour le processus web. Lisez-la et écoutez sur 0.0.0.0, pas sur 127.0.0.1, sinon le health check ne peut pas joindre l'app. Avec Actix Web, convertissez le port en u16 et passez ("0.0.0.0", port) à 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. Commitez Cargo.lock et gardez [package] en tête Si un Cargo.lock est présent, Nodion compile avec --locked : un lockfile qui ne correspond pas à Cargo.toml fait donc échouer le build. Nodion lit le nom du package sur la première ligne name = de Cargo.toml : gardez donc la section [package] en tête du fichier. Cargo.toml

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

3. Les binaires supplémentaires deviennent des types de processus Chaque exécutable de target/release est livré dans l'image, par exemple celui issu de src/bin/worker.rs. Le processus web lance le binaire du package ; chaque autre binaire devient un type de processus du même nom. Pour lancer worker, ajoutez dans l'onglet Processes un processus de ce nom, sans port, et laissez sa commande vide.
4. Créez l'app Dans le dashboard, créez une application depuis votre dépôt GitHub, GitLab, Bitbucket ou Gitea, puis choisissez la branche et la région EU Central. Laissez la stratégie de build sur Buildpacks ; si le dépôt contient un Dockerfile, le formulaire choisit Dockerfile à la place.
5. Rattachez PostgreSQL et lancez les migrations Rattachez une base de données de la même région dans l'onglet Environment ; DATABASE_URL arrive au prochain déploiement, jamais pendant le build. Avec SQLx, exécutez cargo sqlx prepare et commitez le dossier .sqlx pour que les macros query! compilent sans base de données. Lancez les migrations au démarrage avec sqlx::migrate!(), ou compilez un binaire migrate et exécutez-le comme étape de release, une fois par build, avant le démarrage de la nouvelle version. Procfile

   release: migrate

Bon à savoir

• Uniquement le Rust stable le plus récentrust-toolchain.toml et rust-version ne sélectionnent pas une chaîne d'outils plus ancienne : chaque build utilise la version stable de Rust la plus récente préparée par Nodion. Les chaînes d'outils nightly ne sont pas disponibles, donc les crates qui ont besoin de fonctionnalités nightly demandent un Dockerfile.
• WorkspacesNodion exécute cargo build --release dans le répertoire indiqué dans le champ Base directory, sans --workspace. Dans un workspace virtuel (un Cargo.toml racine avec uniquement [workspace]), cela compile tous les membres ; avec un package racine, seul ce package est compilé, donc listez dans workspace.default-members tous les membres dont vous avez besoin. Un workspace virtuel n'a pas de nom de package : nommez donc le binaire web server, api, web ou app.

Ce que Nodion gère pour vous

• Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
• Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
• Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
• Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
• Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
• Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Pour aller plus loin

• Pourquoi nous avons créé nos buildpacks sur Ubuntu 26.04 Nos buildpacks suivent la spécification Cloud Native Buildpacks, mais la stack, les buildpacks de langage et les versions de runtime sont les nôtres. Voici pourquoi.
• Les Cloud Native Buildpacks expliqués Les buildpacks transforment votre code source en image de conteneur sans Dockerfile. Ce qu'ils sont et comment ils fonctionnent.

Rust sur Nodion : questions et réponses