Comment je déploie mes vhosts sur Nginx ?

Ecrit le

Un petit post pour visiter l’envers du décor. En effet, si certains ne l’ont pas encore remarqué, j’ai de nombreux (mais pas trop non plus) hôtes virtuels sur Nginx avec un certificat individuel à chaque vhost1.

Le problème

A chaque nouveau vhost, il faut:

  • composer le nouvel hôte virtuel;
  • composer un autre hôte virtuel pour la première génération du certificat;
  • activer le deuxième hôte si le certificat n’existe pas;
  • recharger Nginx;
  • générer le certificat avec certbot;
  • mettre le premier vhost à la place du deuxième;
  • recharger Nginx;
  • Enjoy !

Autant d’étapes un peu longues à faire à la main et facilement automatisables. On peut certes pallier le côté long à faire à la main en ayant des fichiers prêts à l’emploi, des sortes de modèles si on veut. On peut aussi se faire un script de déploiment automagique de vhost avec gestion du certificat ou bien carrément utiliser tout un système existant qui permet de faire de l’autodéploiement.

Avant le système dont je vais parler plus loin, je me prenais moins le chou en terme de génération du certificat:

  • Composer le nouvel hôte virtuel;
  • arrêter Nginx;
  • générer le certitifcat avec certbot en mode standalone;
  • remettre Nginx en marche

C’est moins long et pénible mais nécessite d’arrêter le serveur HTTP pour faire un certificat en plus de ne pas être super facilement renouvelable sans interruption de service.

Ma solution au problème

J’ai entendu parler pas mal de fois de Ansible sur Mastodon ainsi que dans un chat entre amis. Puis je me suis mis à l’utiliser. Vous le pensez bien, j’ai beaucoup aimé la simplicité d’écriture des playbooks. Les playbooks sont des sortes de livres de recettes pour passer d’un point A à un point B. Ansible se débrouillera pour exécuter les commandes nécessaires sur les hôtes afin d’obtenir l’état décrit dans le livre de recettes.

Le premier playbook écrit est une site de tâches successives qui me permet entre autres de:

  • avoir les paquets que je considèrerais de base (git, vim, zsh, etc.) installé sur chaque container;
  • envoyer les fichiers de configuration communs;
  • changer le shell des utilisateurs à zsh;
  • etc.

J’ai éventuellement entendu parler des rôles sur Ansible. Un rôle est, pour rester sur l’analogie des livres de recettes, un bout de recette réutilisable et adaptable aux besoins. Imaginons une recette qui permet de faire un émincé de poulet au curry avec du riz comme accompagnement. Le riz peut être fait sous forme de rôle Ansible puisque la méthode de faire varie peu. La cuisson du poulet aussi varie assez peu en soit et donc pourrait être mis dans un rôle. Le détail de la sauce au curry sera la recette.

Dans le cas de Ansible, c’est à peu près le même principe: tout ce qui peut être fait de façon similaire dans un contexte différent pourrait être regroupé dans un rôle tandis que le reste est dans les playbooks.

Le rôle écrit

Le rôle que j’ai écrit pour automatiser la création de vhosts ainsi que leurs certificats est celui que j’utilise pour mettre sur pied rapidement mes vhosts. Il me convient très bien dans l’état qu’il est même si, j’en suis certain, peut être amélioré d’une manière ou d’une autre.

On ne va pas se mentir, le déploiement de vhosts avec une façon de faire très similaire a été un prétexte pour se créer un rôle qui le fait automagiquement et comme il faut :p

Je songerai encore à la publication de mon rôle histoire que vous puissiez jeter un coup d’œil et où sera l’original et où sera le miroir: l’original sur mon Gitea ou sur Github / autre ?


  1. Virtual Host, hôte virtuel