Wdróż Go na Nodion

Wdróż Go krok po kroku

1. Nasłuchuj na porcie PORT Nodion ustawia zmienną PORT dla procesu web; nasłuchuj na tym porcie na wszystkich interfejsach. r.Run() z Gin bez adresu już używa PORT. W Echo, Fiber lub Chi przekaż ":" + port samodzielnie. main.go

   package main
   
   import (
   	"log"
   	"net/http"
   	"os"
   )
   
   func main() {
   	port := os.Getenv("PORT")
   	if port == "" {
   		port = "8080"
   	}
   	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
   		w.Write([]byte("ok"))
   	})
   	log.Fatal(http.ListenAndServe(":"+port, nil))
   }

2. Jeden plik binarny na katalog cmd/ Bez katalogu cmd/ Nodion buduje katalog główny modułu do jednego pliku binarnego. Jeśli są katalogi cmd/<name> z plikami Go, każdy z nich staje się osobnym plikiem binarnym, a pakiet z katalogu głównego nie jest wtedy budowany. Proces web uruchamia jedyny plik binarny; jeśli jest ich kilka, ten o nazwie server, api, web lub app, a gdy takiego nie ma, pierwszy z nich. Każdy inny plik binarny staje się typem procesu o tej samej nazwie.

   cmd/server/main.go
   cmd/worker/main.go
   cmd/migrate/main.go

3. Sprawdź ustawienia buildu Pliki binarne są budowane z CGO_ENABLED=0 i -ldflags "-s -w". Jeśli zależność wymaga cgo, jak mattn/go-sqlite3, ustaw w zakładce Environment CGO_ENABLED=1 z zaznaczoną opcją Build. Zmienna GOFLAGS_LDFLAGS z opcją Build zastępuje ldflags, więc jeśli chcesz zachować -s -w, dodaj je tam.
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, a sterowniki PostgreSQL, takie jak pgx, przyjmują ten URL bez zmian. W czasie działania Twoje pliki binarne są w PATH, więc plik binarny cmd/migrate może działać jako krok release, raz na build, zanim wystartuje nowa wersja. Procfile

   release: migrate

Warto wiedzieć

• Workery bez ProcfilePlik binarny z cmd/worker staje się typem procesu worker. W zakładce Processes dodaj proces o nazwie worker bez portu i zostaw jego polecenie puste; uruchomi on ten plik binarny. Plikowi binarnemu procesu web nadaj nazwę server, api, web lub app, aby proces web nie wybrał innego.
• Zawsze najnowsze GoLinia go w go.mod i plik .go-version nie wybierają starszego toolchainu: każdy build używa najnowszego wydania Go, które udostępnia Nodion. Uruchamiaj swoje CI również na najnowszym Go.

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.
• Dockerfile vs buildpacki: co wybrać dla aplikacji? Oba podejścia zamieniają Twój kod w obraz kontenera. Różni je to, kto pisze kroki builda, a od tego zależą kontrola, utrzymanie i aktualizacje bezpieczeństwa.

Go na Nodion: pytania i odpowiedzi