Wdróż Rust na Nodion

Wdróż Rust krok po kroku

1. Nasłuchuj na 0.0.0.0:$PORT Nodion ustawia zmienną PORT dla procesu web. Odczytaj ją i nasłuchuj na 0.0.0.0, a nie na 127.0.0.1, bo inaczej health check nie dotrze do aplikacji. W Actix Web sparsuj port jako u16 i przekaż ("0.0.0.0", port) do 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. Dodaj Cargo.lock do repozytorium i trzymaj [package] na początku Jeśli w repozytorium jest Cargo.lock, Nodion buduje z --locked, więc plik lock niezgodny z Cargo.toml kończy build błędem. Nazwę pakietu Nodion bierze z pierwszej linii name = w Cargo.toml, więc trzymaj sekcję [package] na początku pliku. Cargo.toml

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

3. Dodatkowe pliki binarne stają się typami procesów Każdy plik wykonywalny z target/release trafia do obrazu, na przykład ten z src/bin/worker.rs. Proces web uruchamia plik binarny pakietu; każdy inny plik binarny staje się typem procesu o tej samej nazwie. Aby uruchomić worker, dodaj w zakładce Processes proces o tej nazwie bez portu i zostaw jego polecenie puste.
4. Utwórz aplikację W dashboardzie utwórz aplikację ze swojego repozytorium GitHub, GitLab, Bitbucket lub Gitea, wybierz branch i region EU Central. Pozostaw strategię buildu Buildpacks; jeśli w repozytorium jest Dockerfile, formularz wybiera zamiast niej Dockerfile.
5. Podłącz PostgreSQL i uruchom migracje W zakładce Environment podłącz bazę danych z tego samego regionu; DATABASE_URL pojawi się przy następnym wdrożeniu, nigdy podczas buildu. Z SQLx uruchom cargo sqlx prepare i dodaj do repozytorium katalog .sqlx, aby makra query! kompilowały się bez bazy danych. Uruchamiaj migracje przy starcie przez sqlx::migrate!() albo zbuduj plik binarny migrate i uruchamiaj go jako krok release, raz na build, zanim wystartuje nowa wersja. Procfile

   release: migrate

Warto wiedzieć

• Tylko najnowszy stabilny Rustrust-toolchain.toml i rust-version nie wybierają starszego toolchainu: każdy build używa najnowszej stabilnej wersji Rust dostarczonej przez Nodion. Toolchainy nightly nie są dostępne, więc crate'y wymagające funkcji nightly potrzebują Dockerfile.
• Workspace w CargoNodion uruchamia cargo build --release w katalogu Base directory bez --workspace. W wirtualnym workspace (główny Cargo.toml zawierający tylko [workspace]) buduje to wszystkie elementy (members); przy pakiecie w katalogu głównym buduje tylko ten pakiet, więc wpisz wszystkie potrzebne elementy do workspace.default-members. Wirtualny workspace nie ma nazwy pakietu, więc plikowi binarnemu procesu web nadaj nazwę server, api, web lub app.

Czym Nodion zajmuje się za Ciebie

• Wdrożenia bez przestojów Wypchnij zmiany do swojej gałęzi, a Nodion zbuduje nowy release. Ruch przełącza się, gdy nowe instancje przejdą health check; nieudany release nie wpływa na działającą wersję. Aplikacje z lokalnym wolumenem są natomiast uruchamiane ponownie, bo dysk należy do jednej instancji.
• Bazy danych obok aplikacji Zarządzane PostgreSQL, pgvector, MySQL, Valkey i ClickHouse w tym samym regionie. Podłączone bazy danych trafiają do aplikacji jako DATABASE_URL, REDIS_URL lub CLICKHOUSE_URL.
• Środowiska podglądu dla pull requestów Włącz środowiska podglądu, a każdy pull request z Twojego repozytorium dostanie własną aplikację z własnym adresem URL i nowymi, pustymi bazami danych, tworzoną automatycznie lub ręcznie. Forki i pull requesty od botów są pomijane.
• Workery, zadania cron i skalowanie Uruchamiaj workery jako dodatkowe procesy tej samej aplikacji, planuj zadania w zakładce Cron i skaluj każdy proces do 16 instancji.
• Etap release W przypadku buildpacków linia release: w Procfile uruchamia się przy każdym nowym buildzie. Aplikacje z Dockerfile, a także ponowne wdrożenia i rollbacki do wcześniejszego obrazu, korzystają z polecenia release ustawionego w samej aplikacji, które ma też pierwszeństwo przed linią z Procfile. W przypadku stron statycznych krok release działa w obrazie zawierającym tylko zbudowane pliki.
• Logi i metryki W dashboardzie znajdziesz logi z builda, release'u i działania aplikacji oraz metryki CPU, pamięci, dysku i sieci dla każdej instancji.
• Domeny i HTTPS Domyślna nazwa hosta z HTTPS od pierwszego wdrożenia; Twoje własne domeny automatycznie dostają certyfikaty.

Warto przeczytać

• Dlaczego zbudowaliśmy własne buildpacki na Ubuntu 26.04 Nasze buildpacki są zgodne ze specyfikacją Cloud Native Buildpacks, ale stack, buildpacki językowe i wersje runtime'ów są nasze. Wyjaśniamy dlaczego.
• Cloud Native Buildpacks: czym są i jak działają Buildpacki zamieniają Twój kod źródłowy w obraz kontenera bez Dockerfile. Czym są i jak działają.

Rust na Nodion: pytania i odpowiedzi