Fai il deploy di Go su Nodion

Deploy di Go passo dopo passo

1. Ascolta su PORT Nodion imposta PORT per il processo web; il tuo server deve ascoltare su quella porta, su tutte le interfacce. r.Run() di Gin senza indirizzo usa già PORT. Con Echo, Fiber o Chi passa tu ":" + port. 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. Un binario per ogni cartella cmd/ Senza una cartella cmd/, Nodion compila la root del modulo in un unico binario. Se invece ci sono cartelle cmd/<name> con file Go, ognuna diventa un binario a sé e il package nella root non viene compilato. Il processo web avvia l'unico binario, altrimenti quello chiamato server, api, web o app, altrimenti il primo; ogni altro binario diventa un tipo di processo con lo stesso nome.

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

3. Controlla le impostazioni di build I binari vengono compilati con CGO_ENABLED=0 e -ldflags "-s -w". Se una dipendenza richiede cgo, come mattn/go-sqlite3, imposta CGO_ENABLED=1 con il flag Build nella scheda Environment. Una variabile Build GOFLAGS_LDFLAGS sostituisce gli ldflags, quindi includi lì -s -w se vuoi mantenerli.
4. Crea l'app Nella dashboard crea un'applicazione dal tuo repository GitHub, GitLab, Bitbucket o Gitea, scegli il branch e la regione EU Central. Lascia la strategia di build su Buildpacks; se il repository contiene un Dockerfile, il modulo seleziona invece Dockerfile.
5. Collega PostgreSQL ed esegui le migrazioni Nella scheda Environment collega un database della stessa regione; DATABASE_URL arriva con il deploy successivo e i driver PostgreSQL come pgx lo accettano così com'è. A runtime i tuoi binari sono nel PATH, quindi un binario cmd/migrate può girare come fase di release, una volta per build, prima che parta la nuova versione. Procfile

   release: migrate

Da sapere

• Worker senza ProcfileUn binario da cmd/worker diventa il tipo di processo worker. Nella scheda Processes aggiungi un processo chiamato worker senza porta e lascia vuoto il comando: avvierà quel binario. Chiama il binario web server, api, web o app, così il processo web non ne sceglie un altro.
• Sempre il Go più recenteLa riga go in go.mod e un file .go-version non selezionano una toolchain più vecchia: ogni build usa la release di Go più recente compilata da Nodion. Esegui anche la tua CI con il Go più recente.

Cosa gestisce Nodion per te

• Deploy senza downtime Fai push sul tuo branch e Nodion crea una nuova release. Il traffico passa alle nuove istanze solo quando superano l'health check; una release fallita lascia attiva quella in esecuzione. Le app con un volume locale invece si riavviano, perché il disco appartiene a una sola istanza.
• Database accanto all'app PostgreSQL, pgvector, MySQL, Valkey e ClickHouse gestiti, nella stessa regione. I database collegati arrivano come DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Anteprime per ogni pull request Attiva le anteprime: ogni pull request del tuo repository riceve un'app dedicata, con un proprio URL e database nuovi e vuoti, creata automaticamente o manualmente. Le pull request dai fork e quelle dei bot vengono ignorate.
• Worker, cron job e scalabilità Esegui i worker come processi aggiuntivi della stessa app, pianifica i job nella scheda Cron e scala ogni processo fino a 16 istanze.
• Fase di release Con i buildpack, la riga release: del Procfile viene eseguita a ogni nuova build. Le app con Dockerfile, così come i redeploy e i rollback a un'immagine precedente, usano un comando di release impostato sull'app stessa, che ha anche la precedenza sulla riga del Procfile. Nei siti statici, la fase di release gira in un'immagine che contiene solo i file generati dalla build.
• Log e metriche Nella dashboard trovi log di build, release e runtime, oltre alle metriche di CPU, memoria, disco e rete per ogni istanza.
• Domini e HTTPS Un hostname predefinito con HTTPS dal primo deploy; i tuoi domini ricevono i certificati in automatico.

Per approfondire

• Perché abbiamo creato i nostri buildpack su Ubuntu 26.04 I nostri buildpack seguono la specifica Cloud Native Buildpacks, ma lo stack, i buildpack dei linguaggi e le versioni dei runtime sono nostri. Ecco perché.
• Dockerfile vs buildpack: quale dovresti usare? Entrambi trasformano il tuo codice in un'immagine container. Cambia chi scrive i passaggi della build, e questo determina controllo, manutenzione e aggiornamenti di sicurezza.

Go su Nodion: domande e risposte