Déployer un service Go : le build qui n'a pas besoin de runtime

Un build Go produit un seul binaire lié statiquement, sans rien à résoudre à l’exécution — aucune version d’interpréteur à épingler, aucun gem ou paquet à récupérer sur le serveur qui est sur le point de faire tourner l’application. C’est une chose véritablement différente à construire par rapport à la plupart des applications en langage interprété, et ça se traduit par moins d’endroits où un déploiement peut mal se passer : une fois que le binaire compile, il tourne, point final.

Ce qui est détecté

• Go lui-même est détecté depuis go.mod — y compris un module qui vit dans un sous-dossier (server/go.mod à côté d’un répertoire frontend/), trouvé et construit depuis le bon endroit automatiquement.
• Un import de pilote de base de données connu — github.com/jackc/pgx, github.com/lib/pq, github.com/go-sql-driver/mysql, github.com/redis/go-redis — provisionne la base de données correspondante et injecte DATABASE_URL ou REDIS_URL, sans addon à ajouter à la main d’abord.
• Le build passe par Railpack par défaut, ou votre propre Dockerfile si le dépôt en a un.

railyard create my-app https://github.com/me/my-app --port 8080

ou la même URL depuis le tableau de bord une fois GitHub connecté. La seule exigence qui mérite d’être dite clairement : le binaire doit écouter sur $PORT, et sur toutes les interfaces, pas seulement localhost.

Les workers, puisque Go n’a pas de convention de framework à détecter

Contrairement à Rails ou Django, Go n’a pas une bibliothèque de file de tâches dominante à chercher — il n’y a rien à offrir automatiquement comme worker. Ce n’est pas un problème, parce que c’est une ligne dans les deux cas :

web:    ./server
worker: ./server -mode=worker

Les deux lignes font tourner exactement le même binaire construit; main() lit un indicateur ou une variable d’environnement pour décider quelle boucle faire tourner réellement. Un seul build, plusieurs types de processus, chacun mis à l’échelle indépendamment :

railyard scale my-app worker=2

Pour tout ce qui tourne sur un horaire plutôt qu’en continu, Cron fait tourner le binaire avec un indicateur différent à l’heure planifiée et garde un historique d’exécution — un modèle plus propre qu’une boucle for { time.Sleep(...) } intégrée dans le processus worker.

Config et secrets

Tout ce qui est lu avec os.Getenv est une variable d’environnement simple sous Variables, ou réglée avec railyard env:set my-app KEY=VALUE — jamais compilée dans le binaire, donc exactement le même artefact de build tourne sans changement de staging jusqu’à la production. Pas de recompilation par environnement, ce qui est le point : une différence de config entre staging et prod devrait être une variable, jamais un build différent.

Construire sa propre image, quand on le veut

railyard deploy my-app --local construit avec votre propre Docker et pousse une seule image directement, au lieu d’utiliser le constructeur partagé de l’équipe — utile quand un build a besoin de quelque chose de spécifique à votre chaîne d’outils locale que le chemin de build standard n’a pas besoin de connaître.

Référence complète : Documentation Go, Workers et tâches planifiées.