Déployez Go sur Nodion

Déployez Go étape par étape

1. Écoutez sur PORT Nodion définit la variable PORT pour le processus web ; écoutez sur ce port, sur toutes les interfaces. r.Run() de Gin sans adresse utilise déjà PORT. Avec Echo, Fiber ou Chi, passez vous-même ":" + 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 binaire par dossier cmd/ Sans dossier cmd/, Nodion compile la racine du module en un seul binaire. Sinon, chaque cmd/<name> contenant des fichiers Go devient son propre binaire, et le package racine n'est alors pas compilé. Le processus web lance le binaire unique, sinon celui nommé server, api, web ou app, sinon le premier ; chaque autre binaire devient un type de processus du même nom.

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

3. Vérifiez les réglages de build Les binaires sont compilés avec CGO_ENABLED=0 et -ldflags "-s -w". Si une dépendance a besoin de cgo, comme mattn/go-sqlite3, définissez CGO_ENABLED=1 dans l'onglet Environment en cochant Build. Une variable Build GOFLAGS_LDFLAGS remplace les ldflags : incluez-y -s -w si vous voulez les conserver.
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, et les pilotes PostgreSQL comme pgx l'acceptent telle quelle. Au runtime, vos binaires sont dans le PATH : un binaire cmd/migrate peut donc tourner comme étape de release, une fois par build, avant le démarrage de la nouvelle version. Procfile

   release: migrate

Bon à savoir

• Workers sans ProcfileUn binaire issu de cmd/worker devient le type de processus worker. Ajoutez un processus nommé worker sans port dans l'onglet Processes et laissez sa commande vide : il lance ce binaire. Nommez le binaire web server, api, web ou app pour que le processus web n'en choisisse pas un autre.
• Toujours le Go le plus récentLa ligne go de go.mod et un fichier .go-version ne sélectionnent pas une chaîne d'outils plus ancienne : chaque build utilise la version de Go la plus récente préparée par Nodion. Faites aussi tourner votre CI avec le Go le plus récent.

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.
• Dockerfile vs buildpacks : lequel choisir ? Les deux transforment votre code en image de conteneur. La différence, c'est qui écrit les étapes du build, et cela détermine le contrôle, la maintenance et les mises à jour de sécurité.

Go sur Nodion : questions et réponses