Deploy Go op Nodion

Go stap voor stap deployen

1. Luister op PORT Nodion stelt PORT in voor het webproces; luister daarop op alle interfaces. r.Run() van Gin zonder adres gebruikt PORT al. Met Echo, Fiber of Chi geef je ":" + port zelf mee. 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. Eén binary per map in cmd/ Zonder map cmd/ bouwt Nodion de root van de module tot één binary. Elke cmd/<name> met Go-bestanden wordt in plaats daarvan een eigen binary, en het package in de root wordt dan niet gebouwd. Het webproces start de enige binary, anders die met de naam server, api, web of app, anders de eerste; elke andere binary wordt een procestype met dezelfde naam.

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

3. Controleer de buildinstellingen Binaries worden gebouwd met CGO_ENABLED=0 en -ldflags "-s -w". Heeft een dependency cgo nodig, zoals mattn/go-sqlite3, stel dan op het tabblad Environment CGO_ENABLED=1 in met de vlag Build. Een Build-variabele GOFLAGS_LDFLAGS vervangt de ldflags, dus neem daar -s -w in op als je die wilt houden.
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, en PostgreSQL-drivers zoals pgx accepteren die URL ongewijzigd. Je binaries staan tijdens runtime in het PATH, dus een cmd/migrate-binary kan als releasestap draaien, één keer per build voordat de nieuwe versie start. Procfile

   release: migrate

Goed om te weten

• Workers zonder ProcfileEen binary uit cmd/worker wordt het procestype worker. Voeg op het tabblad Processes een proces met de naam worker zonder poort toe en laat het commando leeg; het start die binary. Noem de webbinary server, api, web of app, zodat het webproces geen andere kiest.
• Altijd de nieuwste Go-versieDe go-regel in go.mod en een .go-version-bestand kiezen geen oudere toolchain: elke build gebruikt de nieuwste Go-release die Nodion heeft gebouwd. Laat je CI ook tegen de nieuwste Go draaien.

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.
• Dockerfile vs buildpacks: welke moet je gebruiken? Allebei maken ze van je code een containerimage. Het verschil is wie de buildstappen schrijft, en dat bepaalt controle, onderhoud en beveiligingsupdates.

Go op Nodion: vragen en antwoorden