Un PRA simple avec Ansible

Suite à un article précédent, j’ai mis en place le PRA (plan de reprise d’activité) que j’envisageais pour mon auto-hébergement, avec Ansible. Même si ça a été un peu plus compliqué que prévu.

Dans ce précédent article, j’expliquais comment j’avais utilisé Ansible pour déployer et sauvegarder mes services, et pour synchroniser les données entre des instances actives et passives. Et j’expliquais que le PRA pourrait simplement consister à mettre une instance passive à l’extérieur (pourvu qu’elle soit accessible en SSH).

C’est effectivement ce que j’ai mis en place, en déplaçant un de mes serveurs chez un autre particulier (derrière une freebox), mais il a fallu quelques petits ajustements.

Architecture actif/passif avec PRA

Accès SSH

Par mesure de sécurité, je n’expose jamais le port 22 (port par défaut de SSH) sur Internet. Ca permet d’échapper à beaucoup de scans de port. Ca tombe bien, les freebox permettent de mapper un port différent dans la configuration du NAT.

J’ai préparé la machine chez moi avant de la déplacer, donc elle était déjà dans mon inventaire Ansible. Il a été facile de conserver son paramétrage Ansible (et même son nom d’hôte) après son déplacement, en définissant simplement les variables ansible_host et ansible_port dans l’inventaire.

Problème : mon role datasync fait un « callback » du serveur à sauvegarder vers le serveur de sauvegardes. Donc il faut exposer le serveur de sauvegardes en SSH à l’extérieur (donc le sécuriser un peu aussi, avec fail2ban, notamment, et en utilisant à nouveau un port non standard).

Known_hosts

Ensuite, il faut compléter le fichier known_hosts, pour que la « host key » soit également associée à l’adresse du serveur via Internet. Syntaxe : [host]:port, [ip]:port.

Dans ma configuration, il faut le faire à la fois sur le serveur Jenkins (dans /var/lib/jenkins/.ssh/known_hosts) et sur le serveur de backup (dans /home/sauvegardes/.ssh/known_hosts).

NB : attention à avoir des IP fixes des 2 côtés. Si une IP change, la vérification de l’hôte par le client SSH va échouer, et il faudra probablement modifier les known_hosts à nouveau. Si l’IP doit vraiment pouvoir changer, on peut a priori demander aux clients SSH de ne pas faire cette vérification, avec le paramètre CheckHostIP à no (qui peut être passé en option de ligne de commande), mais je n’ai pas vérifié.

Module synchronize et port non standard

J’ai eu besoin de configurer le paramètre dest_port du module synchronize pour que le port non standard soit pris en compte :

     dest_port : "{{ ansible_port | default(omit) }}"

C’est bizarre parce que ça devrait marcher tout seul d’après la doc https://docs.ansible.com/ansible/latest/modules/synchronize_module.html (et je l’ai effectivement vu fonctionner correctement sur une autre machine, sans préciser le paramètre dest_port).

Configuration du reverse-proxy

Avec tout ça, j’arrive à tenir à jour les données sur ma machine distante, c’est cool. Mais il reste à préparer le nécessaire pour que les services soient accessibles par Internet. C’est-à-dire à répliquer le reverse-proxy que j’ai dans mon auto-hébergement.

Ce nouveau reverse-proxy peut tout simplement tourner sur la même machine distante. C’est du PRA : tant pis si c’est un mode un peu dégradé en termes de performance et sécurité.

J’ai donc fait un nouveau playbook (qui utilise mon role datasync) pour synchroniser les certificats SSL de Let’s Encrypt. Et j’ai copié la conf Apache des reverse-proxy. Pour ça j’ai dû :

  • spécifier une adresse locale pour certains noms d’hôte dans /etc/hosts
  • remplacer 192.168.* par localhost dans les sites Apache qui font le reverse-proxy
  • activer les modules proxy_http et ssl dans Apache
  • dans ports.conf, écouter uniquement en IPv4 (car la freebox active aussi de l’IPv6, et je ne veux pas que mes services soient accessibles en direct sans passer par le reverse-proxy), en remplaçant Listen 80 et Listen 443 par Listen 0.0.0.0:80 et Listen 0.0.0.0:443. Il y aurait certainement mieux à faire là-dessus, mais je n’ai pas encore travaillé sur l’exposition de mes services en IPv6

Bascule sur le PRA

En cas de problème chez moi (perte d’accès à Internet ou de courant, indispo d’un serveur etc), il n’y a donc qu’à remplacer chez mon registrar l’IP de mon domicile par celle où est mon serveur de PRA (pour le ou les noms DNS qui ne fonctionnent plus à mon domicile).

Evidemment, je n’ai que les données à J-1 (sauf à lancer la synchronisation plus fréquemment qu’une fois par nuit), mais le service peut être rétabli rapidement.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *