Le cas le plus simple de tous

Rien à reconstituer

Les autres technologies de cette série demandent qu’on prépare la machine : version d’interpréteur, bibliothèques, dépendances qui doivent correspondre. Go supprime cette étape. Le programme se compile en un fichier unique, et ce fichier contient tout ce dont il a besoin.

Le déploiement consiste donc à déposer le binaire et à relancer le service. Le retour arrière consiste à remettre le précédent. Il n’y a pas de troisième possibilité, et c’est ce qui rend l’exploitation d’un service Go remarquablement peu bavarde.

Ce qui reste à faire, quand même

Trois choses, et elles ne sont pas propres à Go :

• Un superviseur qui relance le service s’il s’arrête, et remonte l’incident. Un programme s’arrête toujours un jour.
• Un reverse proxy devant, qui porte le certificat SSL et le nom de domaine — et qui permet de basculer d’une version à l’autre sans coupure.
• Les journaux sortis du processus, et les métriques de la machine surveillées comme sur nos autres serveurs.

Plusieurs services sur une machine

C’est la conséquence économique la plus concrète. Là où une application Java demande des centaines de méga-octets de mémoire et une application PHP un serveur web complet, un service Go se contente de quelques dizaines de méga-octets.

Une même machine peut donc en porter plusieurs sans se marcher dessus. Nous exploitons ainsi nos propres outils — redirection HTTP, vérification d’adresses IP en listes noires, détection de botnets, serveurs SMTP entrants et sortants — et le dimensionnement reste modeste au regard de ce qu’ils traitent.

Serveur privé ou conteneur

Le serveur privé convient parfaitement, et c’est souvent le plus économique puisque plusieurs services y cohabitent. Le conteneur apporte moins ici qu’ailleurs — l’image ne résout pas un problème d’environnement, puisqu’il n’y en a pas — mais reste pertinent si vous déployez très souvent ou si le reste de votre pile est déjà conteneurisé.