Tinc on Zwindler's Reflection

Créer un VPN distribué avec Tinc

Mon, 17 Feb 2020 07:30:00 +0000

Faire un VPN Tinc fullmesh sans monter un gros réseau IPSec

Un des gros problèmes que j’ai rapidement eu à régler lorsque j’ai voulu monter des clusters de serveurs Proxmox VE chez des providers de serveurs physiques, c’est la façon dont est gérée le clustering dans PVE.

Les concepteurs de PVE ne veulent pas que l’on monte des clusters sur Internet et mettent volontairement le plus de bâtons dans les roues pour vous empêcher de le faire. J’exagère à peine.

En version 5.x, PVE se basait sur la version 2 de corosync par multicast (bloqué par tous les providers) et qu’en v6.x, on nous bride en demandant explicitement un sous réseau LAN dédié, autant dire qu’on est pas aidé.

OpenVPN vs Tinc

Une solution que j’ai expérimenté est de monter un serveur OpenVPN sur un des serveurs et de connecter les autres dessus. J’ai d’ailleurs fait un tuto là dessus pour PVE.

Cette approche n’est pas optimale : si on a 2 machines, c’est bon, mais si on en a 3 ou plus, on se retrouve soit avec un SPOF, soit à devoir monter un maillage complexe de couples serveur-client. Au delà de 3, c’est pratiquement ingérable.

Au contraire, Tinc est un logiciel libre (GPLv2) permettant de monter des VPNs multipoints (full mesh routing) entre des machines sur Internet. Tinc est prévu pour notre cas d’usage !

le vrai logo de Tinc (la photo en haut du blog c’est Supercopter, of course)

On sécurise

Comme tout service “ouvert” sur Internet, il est évidemment nécessaire de faire du firewalling pour bloquer le trafic malveillant. Pour information, Tinc utilise le port 655 en TCP et UDP, que vous devrez donc ouvrir dans les deux sens entre l’ensemble de vos serveurs, mais bloquer pour le reste d’Internet.

A noter, ce n’est pas confirmé mais la page principale de Tinc indique qu’il est possible que ce logiciel (tout comme OpenVPN, Wireguard et IPSec) soit vulnérable à la CVE-2019-14899.

On l’installe et on le configure

On va devoir installer le package/binaire sur toutes les machines du VPN. Pas trop de soucis de ce côté, tinc est multiplateforme (Windows aussi) et est packagé dans de nombreuses distrib Linux. Sur les dépôts Debian, tinc est présent sans souci et j’imagine que ça sera le cas pour d’autres distribs aussi.

apt install tinc

Une fois installé, on peut créer notre VPN. Pour déclarer un VPN, il faut ajouter le nom de celui ci dans un fichier de configuration global :

echo "vpnzwindler" >> /etc/tinc/nets.boot

On créé ensuite un répertoire du même nom, contenant lui même un dossier hosts.

mkdir -p /etc/tinc/vpnzwindler/hosts

Dans ces dossiers, on va créer fichier de configuration, /etc/tinc/vpnzwindler/tinc.conf. Ce fichier va nous permettre de décrire le node courant et qui doit se connecter à qui.

Name = node01
AddressFamily = ipv4
Address = 1.1.1.1
Device = /dev/net/tun
Mode = switch
ConnectTo = node02
ConnectTo = node03
ConnectTo = node04
[...]

Dans les informations importantes, Name va être le nom (arbitraire) du node pour tout le VPN, Address représente l’adresse IP publique de votre node, et ConnectTo, la liste des autres Names des autres nodes.

A partir de là, on peut demander à tinc de nous générer des couples clé publique/clé privée pour tous nos serveurs. Sur tous les nodes du VPN, lancer :

echo -e '\n\n' | tincd -n vpnzwindler -K4096

Si tout se passe bien et que tous les fichiers de conf et dossiers ont été créés correctement, tinc devrait créer un couple clé privée/clé publique, puis créer un fichier /etc/tinc/vpnzwindler/hosts/node01 (sur celui dont le Name est node01).

Envoyez (par scp par exemple) l’ensemble des fichiers dans le dossier hosts sur tous les serveurs. Maintenant, tous les VPNs sauront quelle IP publique contacter et avec quel clé authentifier le trafic.

Autre méthode : tinc invite / tinc join

Une feature sympa de tinc, mais seulement en 1.1 (la dernière version), est la possibilité d’ajouter des nodes à un VPN existants via une simple commande tinc invite (voir la doc).

Je ne l’ai pas testée mais a priori tinc créé une URL qui permet d’inviter n’importe qui et de configurer son node avec un tinc join.

The whole URL is around 80 characters long and looks like this: server.example.org:12345/cW1NhLHS-1WPFlcFio8ztYHvewTTKYZp8BjEKg3vbMtDz7w4

Configuration du réseau de l’OS

Maintenant qu’on a tous les prérequis, on peut configurer l’aspect réseau de notre VPN. Ça dépend de votre distribution bien sûr (où dans le cas de PVE, si vous utilisez OpenVSwitch ou pas par exemple). Dans le cas d’une Debian récente, on va gérer tout ça avec ip.

Pour gérer cette partie, Tinc va vous demander de créer 2 scripts. Un tinc-up.sh et un tinc-down.sh, respectivement pour le démarrage et l’extinction de l’interface VPN.

cat /etc/tinc/vpnzwindler/tinc-up
#!/bin/bash
/sbin/ip link set vpnzwindler up
/sbin/ip addr add 10.0.0.1/24 dev vpnzwindler
/sbin/ip route add 10.0.0.0/24 dev vpnzwindler
cat /etc/tinc/vpnzwindler/tinc-down
#!/bin/bash
/sbin/ip link set vpnzwindler down
chmod +x tinc-*

Rien de bien compliqué ici, on demande au binaire ip de créer une interface vpnzwindler. Puis on lui affecte l’IP virtuelle 10.0.0.1 (notre node01). Enfin d’ajouter une route pour que tout le trafic du VPN passe par cette interface.

On le démarre

Dernière étape, on va demander à systemd de nous démarrer le vpn qu’on vient de créer dès le démarrage de la machine.

systemctl daemon-reload
systemctl enable tinc@vpnzwindler
systemctl start tinc@vpnzwindler

Et voilà !!! Vous avez maintenant un VPN multipoint simple et efficace !

root@node01 ~ # ping node02
PING node02 (10.0.0.2) 56(84) bytes of data.
64 bytes from node02 (10.0.0.2): icmp_seq=1 ttl=64 time=17.1 ms

Changement de provider, mon hyperviseur sur un dédié Hetzner

Tue, 19 Nov 2019 07:30:00 +0000

Au revoir OneProvider, bonjour Hetzner

Certains d’entre vous m’ont peut être vu me plaindre de OneProvider et plus particulièrement le support avec qui j’ai eu plusieurs accrochages (Spoiler, j’ai migré vers Hetzner).

Sans rentrer dans les détails (j’ai échangé avec certains d’entre vous sur le sujet), après cette déconvenue, j’ai donc cherché une alternative pour héberger mes machines.

Les prérequis étaient d’avoir :

une machine physique
avec suffisamment de RAM (minimum 8 Go, 16 c’est mieux)
idéalement, une gestion des réseaux virtuels entre machines du provider (type RPN ou vRack)
si possible pas un ATOM en CPU (le souci de l’ATOM, c’est que c’est tellement faiblard que ça pénalise les IO)
si possible du VT-x (je n’en ai pas besoin d’en l’absolu, je vais surtout du LXC, mais ça peut dépanner)
si possible du SSD parce que c’est quand même cool
si possible 2 disques pour avoir du RAID ou que je puisse me faire un équivalent (ZFS/ZRAID)
un prix pas trop élevé (genre pas OVH) car j’ai été mal habitué avec les prix agressifs de OneProvider (oui je sais, je l’ai payé avec le support)

L’état du marché

Chez OneProvider, j’avais tout ça pour environ 20-25 euros / mois, à l’exception du réseaux privé virtuel entre machine.

Autant dire qu’on est très loin du premier prix de chez OVH (>60€/mois TTC). Si on descend en gamme chez OVH, on perd le réseau privé virtuel entre machines (vRack) en passant chez SoYouStart et pourtant on est toujours à plus de 42€ / mois TTC. Toujours 2 fois plus cher que OneProvider :-/.

Il faut descendre encore de gamme et passer chez Kimsufi pour trouver des prix comparables dans mes critères (et toujours pas de réseau privé virtuel), avec de vieux CPU et surtout un réseau bridé au 100 Mbps (ce qui est pénible pour les transferts de gros fichiers, les réplications de VMs et les sauvegardes).

J’avais aussi jeté un œil côté Online.net, qui eux proposent sur certaines machines identiques à celles que j’avais avec EN PLUS le graal, un réseau privé virtuel entre dédiés (RPN).

Ces deux configs me disaient vraiment quelque chose… et pour cause ! OneProvider les revends en marque blanche.

Donc c’est exactement les mêmes machines que celle que j’ai pu avoir dans le passé, mais avec le RPN en plus, et un peu plus cher (beaucoup plus cher même).

Ce qui est dommage ici, c’est que le RPN ne soit pas disponible sur les machines un peu plus petites (mon PRA n’est pas aussi gros, juste de quoi faire tourner le blog en cas de gros crash).

Vient alors Hetzner

Ça fait pas mal de fois que je voyais circuler le nom. Des bloggeurs et d’autres confrères en disaient beaucoup de bien, et j’ai voulu aller voir. La première chose intéressante est que Hetzner, comme OVH et Online, propose bien un service de type réseau privé virtuel entre vos serveurs !

Plus de puissance chez Hetzner !

Par contre, quand j’ai vu les machines… au début je me suis dis que ça allait pas le faire…

Voilà leur machine “bas de gamme” :

Pour à peine plus que le moins cher des SoYouStart (un vieux Xeon E3 v2 4c/4t avec 16Go de RAM et 2 HDD), vous avez un tout nouveau Ryzen 5 6c/12t, 64 Go de RAM et un RAID de 2 SSD NVMe de 512 Go.

Bon clairement on était hors budget mais ils avaient piqué ma curiosité avec leurs config fofolles.

Et je suis donc tombé en fouillant un peu sur leur “server auction”, qui est ni plus ni moins que les serveurs de leurs anciennes gammes qu’ils louent à nouveau. Et là c’était déjà plus proche de mon besoin.

Pour un peu plus de 30€/mois soit 50% plus que mon serveur précédent, mais comparable au prix Online, j’ai un i7-4770, 32 Go de RAM et 2 disques “Entreprise”. Soit beaucoup mieux que la machine chez Online.

Quitte à changer, j’ai donc tenté Hetzner et commandé un serveur.

C’est puissant mais… qu’est ce que c’est moche

Bon, l’UI n’est pas follement attrayante. C’est… spartiate.

Dans le menu “Servers”, vous avez une bête liste de vos serveurs avec le numéro de commande, un hostname (une fois que vous l’aurez setté) et un ID (peu parlant). Bof pratique, surtout au début ou si vous en avez beaucoup.

Et quand on sélectionne un serveur, ce n’est malheureusement guère mieux. Les informations importantes éclatées dans un nombre incalculable de menus.

Bref, côté expérience utilisateur, on repassera. Cependant, tout ce qu’il faut pour bien administrer son serveur est là. On finira par s’y retrouver avec un peu d’habitude…

Installation de l’hyperviseur

Pour installer notre serveur, on peut utiliser l’interface web pour installer un Debian, ou passer par l’image de rescue.

J’ai préféré utiliser la 2ème solution, car elle est immédiatement disponible à la livraison du serveur, avec votre clé SSH.

On arrive sur un login on ne peut plus classique, avec un résumé des caractéristiques de vos serveurs.

Point intéressant, il existe un binaire installimage sur l’OS rescue de Hetzner. Il permet, comme son nom l’indique, d’installer une image.

Comme j’utilise Proxmox VE comme hyperviseur, j’ai donc installé une Debian 10 :

Une fois l’image de base choisie, vous allez arriver à un éditeur de texte. Il va vous permettre de configurer de manière plus fine votre installation. Je trouve cette méthode assez originale. Ça change des interfaces webs pas toujours stables vous demandant la taille de vos partitions pour finalement planter dès que vous demandez un truc non standard.

Ici tout a très bien marché, j’ai configuré le hostname, ainsi qu’un RAID soft et un partitionnement LVM.

Là encore, je suis navré qu’on tombe dans le cliché, mais si ce n’est pas “joli” ni “user friendly”, au moins c’est efficace.

Passer de Debian 10 à Proxmox VE 6

Une fois validé, l’image Debian 10 a été copié extrêmement rapidement (une ou deux minutes). Forcément, c’est une “minimal”. Mais bon c’est quand même agréable d’avoir son serveur “up and running” en moins d’une demie heure entre la commande et la fin de l’installation.

Reste donc à installer PVE 6 sur notre dédié Hetzner. Sans trop de surprise, j’ai réutilisé mon playbook Ansible qui configure de A à Z la Debian pour en faire un Proxmox. Pour ceux qui l’ont loupé, c’est par ici que ça se passe.

J’ai juste eu un petit souci lors de l’installation. La debian étant minimale, je n’avais même pas python d’installé. C’est gênant quand on fait du Ansible !

cat inventory_hetzner.yml
all:
children:
proxmoxve:
hosts:
<fqdn_hyperviser>:
ansible proxmoxve -i inventory_hetzner.yml -u root -m ping
<fqdn_hyperviser> | FAILED! => {
"changed": false,
"module_stderr": "Shared connection to <fqdn_hyperviser> closed.\r\n",
"module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
"msg": "MODULE FAILURE",
"rc": 127
}

Heureusement j’avais déjà eu le souci dans un autre contexte. J’ai donc écris un playbook supplémentaire (dispo sur le Github) pour installer les prérequis manquants.

ansible-playbook -i inventory_hetzner.yml -u root proxmox_python_firstinstall.yml
ansible-playbook -i inventory_hetzner.yml -u root proxmox_prerequisites.yml

Et en quelques minutes, mon Proxmox VE était opérationnel sur Hetzner !

Cluster Proxmox VE, v6 cette fois ci !

Tue, 20 Aug 2019 11:45:00 +0000

Proxmox VE

Et oui, avec la sortie de Proxmox VE 6, je vous avais prévenu : il va y avoir pas mal d’articles là dessus, même si quelques articles sur Kubernetes sont en cours d’écriture aussi ;-).

Fin juillet, j’avais écris un article sur des playbooks Ansible que j’ai écris pour faciliter le déploiement de cluster Proxmox VE. Malheureusement, comme cet article traînait dans mes brouillons, les playbooks ne géraient pas la version 6 (qui venait de sortir) de PVE.

C’est aujourd’hui de l’histoire ancienne puisque, pour tester la v6, j’ai forcément du adapter les playbooks ;-).

Point important, je vais partir du principe que vous n’avez pas la possibilité d’installer Proxmox VE directement avec l’ISO. C’est souvent le cas souvent avec les hébergeurs de serveurs dédiés pas chers (OneProvider par exemple) ou de VMs (OVH, Scaleway, etc).

Car si vous avez la main, le plus simple est bien sûr d’installer l’ISO directement ! Cependant, ce tuto reste utile pour toute la partie mise en VPN et configuration du cluster.

Les prérequis

Dans l’article précédent, pour gagner du temps pour ceux qui veulent juste tester, j’avais mis à disposition un playbook permettant de générer des VMs chez le cloud provider Scaleway (et notamment tirer parti de l’inventaire dynamique proposé par le module développé par Scaleway pour Ansible).

Ici, je met volontairement de côté cette partie qui n’apporterait rien de plus. Si vous voulez voir comment ça fonctionne je vous invite à (re)lire l’article précédent, la procédure est la même.

Le seul prérequis pour ce tutoriel sont donc d’avoir idéalement 3 machines* (ou plus) sous Debian 10 (la raison pour laquelle je n’avais pas pu le faire avec Scaleway qui ne propose pas encore Debian Buster) accessibles en depuis votre station de travail.

*Mais si vous voulez juste installer Proxmox, une seule suffit mais vous n’aurez évidemment pas un cluster. A partir de 2, on peut faire un cluster mais il sera instable dès que vous perdrez une seule des 2 machines (ce qui est dommage) à moins d’ajouter un device pour permettre d’avoir le quorum (ce que nous verrons dans un autre article).

Installer Ansible et récupérer les playbooks

Des fois que n’auriez pas Ansible, installez le (pour git, c’est juste plus simple de cloner le dépôt mais vous pouvez le télécharger autrement si vous ne voulez pas installer git)

apt-get install git ansible
git clone https://github.com/zwindler/ansible-proxmoxve
cd

Ensuite, on créé un fichier d’inventaire pour Ansible (ce qui n’étais pas nécessaire avec Scaleway puisque, je le rappelle, il y a un module d’inventaire dynamique). Ici on se contente juste de lister les serveurs qui nous intéressent.

cat pve_inventory.yml
all:
children:
proxmoxve:
hosts:
proxmox1.myexample.org:
proxmox2.myexample.org:
proxmox3.myexample.org:

Vous ne reconnaissez peut être pas le format de cet inventaire Ansible. En effet, l’inventaire est ici stocké au format YAML et non au format plat. Très peu de gens utilisent ce format (qui existait au début, puis a été retiré pour être de nouveau supporté depuis la 2.4 je crois).

Étant habitué aux inventaires parfois un peu hétéroclites, je préfère largement ce format YAML, qui permet de rajouter de manière beaucoup plus lisibles des variables à des groupes ou mêmes des hôtes directement (sans passer par une arborescence complète avec groups_vars et hosts_vars). De plus, je trouve les dépendances entre groupes plus claires que lorsque nous avions à déclarer les :children du groupe père (mais c’est subjectif).

Notez par contre qu’il faut :

que mes hôtes soient résolvables par DNS (sinon il faut ajouter une variable ansible_host avec l’IP pour chacun)
que vous n’oubliez surtout par le “:” à la fin de chaque hostname, sans quoi vous aurez une erreur de syntaxe.

Lancer le playbook d’installation de Proxmox VE 6

Nous y voilà. Normalement vous pouvez accéder en SSH à l’ensemble de vos machines. Pour installer Proxmox VE 6 sur une debian 10, il faut donc simplement lancer la commande suivante :

ansible-playbook -i pve_inventory.yml proxmox_prerequisites.yml -u root

Normalement, le playbook vous promptera pour répondre à quelques questions basiques (votre domaine, est ce que les machines commencent par test plutôt que proxmox dans le hostname, …) et à l’issue, un reboot sera effectué (pour basculer sur le noyau Linux de PVE et pas celui de debian Buster).

Mise en réseau privé virtuel avec Tinc

Cette étape n’est pas forcément nécessaire. Si vous travaillez sur des machines qui sont dans un même réseau local, il vaut mieux s’en passer.

En revanche, dans le cas où comme moi vous louez des serveurs chez un provider et qu’il ne vous met pas à disposition un moyen de simuler un réseau privé (RPN chez Online, Rack quelque chose chez OVH je crois), il sera préférable de monter un VPN entre les différentes machines du cluster.

Je dis préférable et pas nécessaire, car jusqu’à la version 6 de Proxmox (et Corosync v3), il était nécessaire également de faire passer du multicast entre les machines pour faire fonctionner le cluster. Ce n’est aujourd’hui plus le cas et on peut donc très bien imaginer un cluster Proxmox avec des machines sur des LAN distincts. Cependant, pour activer des fonctionnalités comme Ceph (et probablement d’autre), il est toujours nécessaire d’avoir un LAN.

Pour se faire, j’utilise Tinc plutôt qu’OpenVPN, qui a l’avantage d’être simple à configurer et surtout multipoint (pas de notion de serveur maitre et de clients connectés dessus). Ce n’est pas le cas avec OpenVPN, dont la structure client/serveur complexifie beaucoup l’implémentation si on veut éviter un SPOF (en gros il faut un serveur sur toutes les machines, et que l’ensemble des serveurs soient tous clients les uns des autres, en toile d’araignée). Vous pouvez quand même jeter un oeil sur mes premières tentatives ici, si ça vous intéresse.

Comme j’automatise tout avec Ansible, j’ai donc aussi créé un playbook qui permet d’installer et configurer Tinc sur toutes nos machines et de les mettre en réseau sur un VPN dédié.

ansible-playbook -i pve_inventory.yml tinc_installation.yml -u root

A partir de là, vous avez donc 3 machines Proxmox VE 6, connectés ensembles sur un VPN avec l’adresse 10.10.10.0/24

Le réseau c’est compliqué ?

Un point pas forcément évident avec Proxmox est que la configuration du réseau dépend beaucoup de comment vos machines sont connectées en réseau.

Les différentes configurations conseillées sont détaillées dans un article dédié sur le wiki de Proxmox. J’aurais vraiment aimé connaître cette page lorsque M4vr0x et moi avons fait nos premières expériences avec PVE car nous avons beaucoup tâtonné…

Dans mon cas précis, j’ai des machines hostées par un provider. Je n’ai donc aucunement la main sur le réseau et je ne souhaite pas acheter d’IP supplémentaires.

Dans ce cas là, le plus simple est donc de créer un bridge Linux, qui portera un réseau virtuel interne à chaque serveur et dont le trafic externe sera routé.

L’inconvénient de cette solution est qu’on ne peut pas utiliser l’interface graphique pour faire ces modifications, et aussi qu’en cas d’erreur, vous n’aurez plus accès à votre serveur…

Configuration réseau pour des machines dédiées chez un Provider type OneProvider

Nous voilà donc dans les premières bidouilles manuelles. Connectez vous en SSH à votre (vos) serveurs, et modifier le fichier /etc/network/interfaces.

Je me suis basé sur la section “Masquerading (NAT) with iptables”

Le mien ressemble à ça :

source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto eth0
#real IP address
iface eth0 inet static
address x.x.x.x
netmask 24
gateway x.x x.1
auto vmbr0
iface vmbr0 inet static
address 192.168.0.1
netmask 255.255.255.0
bridge-ports none
bridge-stp off
bridge-fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '192.168.0.0/24' -o eth0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.168.0.0/24' -o eth0 -j MASQUERADE

Le plus important ici pour que tout fonctionne est que vous ne vous trompiez pas sur le nom de l’interface réseau (eth0 dans mon exemple).

Ensuite, une fois que les modifications sont faites, redémarrez le réseau (systemctl restart networking) ou carrément le serveur (c’est ce que Proxmox conseille, même si je ne vois pas bien l’intérêt).

Ici, la configuration est beaucoup plus simple que ce que nous avions imaginé avec M4vr0x dans la série d’articles détaillés sur PVE 5. Et c’est tant mieux car ça suffira amplement à la plupart d’entre vous ;-).

Configuration du cluster Proxmox VE

Ok ! Maintenant tous les prérequis sont en place, on peut donc construire le cluster. Le wizard de la GUI a assez peu évolué depuis la V5 (même s’il y a quelques petites améliorations)

Vous vous connectez sur une des machines
Dans la vue Datacenter, vous sélectionnez Create Cluster, puis vous copiez les informations de connexion pour les autres serveurs.
Sur les autres serveurs, vous rejoignez le cluster en collant les informations des

(Plus de détails dans l’article précédent)

Un cluster Proxmox VE en 5 minutes avec Ansible

Mon, 22 Jul 2019 11:45:34 +0000

Cool on va (encore) déployer du Proxmox VE !!!

Petit tuto aujourd’hui, massivement facilité par l’usage d’Ansible : on va déployer un cluster de machines Proxmox VE via le cloud provider Scaleway.

A noter : Si jamais vous ne voulez pas utiliser Scaleway, les playbooks ont été découpés de manière à ce que la partie d’installation de Proxmox ainsi que l’installation de tinc et la mise en cluster puissent être réalisés à part. Vous pouvez donc tout à faire partir de machines sous Debian 9 via ces playbooks.

Pourquoi Scaleway me direz vous ? Tout simplement parce qu’ils ont, contrairement à d’autres, une très bonne API, qui a permis à un de leurs employés de faire de très bons modules Ansible, notamment un module permettant de gérer l’inventaire dynamique (pas besoin de renseigner un fichier hosts pour Ansible, c’est directement l’API qui nous liste les VMs).

J’ai d’ailleurs utilisé ce provider à plusieurs reprises pour cette raison (voir mon article sur k3s et Ansible ou mon talk à BDX I/O Ami développeur, deviens un ops sans effort avec Ansible).

Proxmox VE 5.4 ? Pourquoi pas 6.0 ?

La deuxième question, tout aussi légitime, repose donc sur “pourquoi diantre monter un cluster Proxmox VE 5.4 alors que tu viens de nous faire un article qui vante les bienfaits de la version 6.0 qui vient de sortir ?”

Et là j’ai deux raisons (une bonne et une mauvaise). La mauvaise, c’est simplement que l’article trainait dans mes brouillons et que je n’ai pas cliqué sur “Poster”… La “bonne” raison, c’est que la version 10 de Debian, qui est la base de Proxmox VE 6, n’est pas encore disponible sur Scaleway, ce qui complique un peu l’installation.

Lorsqu’elle le sera, je ne manquerais pas de faire un petit refresh de l’article ainsi que des playbooks Ansible ;)

Déployer les VMs avec Ansible

Je l’ai dis juste avant, le gros avantage de Scaleway, c’est de pouvoir spawner des VMs à la volées avec Ansible et surtout d’avoir l’inventaire dynamique.

Petite (grosse?) limitation : comme il s’agit de VMs, il ne sera évidemment pas possible de faire tourner des VMs de type KVM/qemu sur ces machines (sauf moyennant un hack de type nesting de VM dans une VM).

Cependant, depuis quelques temps, je n’utilise plus du tout les VMs (je n’ai pas de workload Windows) et j’utilise plutôt des containers LXC.

C’est vraiment plus léger en terme d’empreinte mémoire (je n’ai jamais été embêté côté CPU mais côté RAM, chaque Mo compte) et ça se gère (install, gestion, sauvegarde) de la même façon qu’une VM, contrairement à Docker qui nécessite une gymnastique mentale complémentaire.

Bon, on fait ça comment ?

Maintenant que j’ai posé le décor, on peut commencer le tuto. L’idée va être de :

Créer des VMs
Récupérer leurs informations (IP publique, surtout)
Installer les prérequis de Proxmox VE (puis les rebooter pour passer sur le kernel PVE)
Installer les prérequis et configurer tinc, le VPN qui va nous permettre d’initier le cluster et de laisser passer les trames multicast, nécessaires au clustering

A l’issue de ces étapes, on arrêtera là l’automatisation et on passera sur quelques (rapides) étapes manuelles.

Ok, j’avoue que c’est dommage que tout ne soit pas automatisé. Mais le gros du boulot, c’est vraiment les étapes précédentes. Pour s’en convaincre, vous pouvez lire l’article que j’avais écris pour la version 5.2 (mais avec OpenVPN) ou tout simplement lire le contenu des playbooks.

Prérequis

Et oui, il y a quand même quelques prérequis à ce tuto. Il faudra :

Avoir un compte sur Scaleway
Avoir une clé SSH, avoir la clé publique à la racine du projet, et l’appeler admin.pub
Installer les package pip

pip install jinja2 PyYAML paramiko cryptography packaging

Installer Ansible depuis les sources (>= 2.8)
Installer jq

J’aurai pu faire aussi un playbook pour ça, mais comme c’est très dépendant de votre distribution Linux (ou Windows ahaha), …

You token to me ?

Créez un token sur le site de Scaleway pour les accès distants et le stocker dans un fichier scaleway_token sur votre machine avec Ansible :

export SCW_API_KEY='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'

Puis sourcez le fichier :

source scaleway_token

A partir de maintenant, vous avez le pouvoir tout puissant du cloud au bout de vos doigts (et de votre CB) !

Générer les machines

Là, on tire totalement parti du travail de Rémy Léone sur https://github.com/scaleway/ansible et des modules Ansible pour Scaleway, intégrés au repo officiel.

On va donc utiliser le playbook create_proxmox_vms.yaml pour :

récupérer l’ID d’organisation du compte Scaleway (votre identifiant unique)
récupérer un ID d’une image disque compatible debian Stretch (de la bonne taille)
ajouter si nécessaire la clé SSH de l’admin dans le portail Scaleway, qui sera injectée dans vos VMs à leur création
créer autant de machines que nécessaire

ansible-playbook create_proxmox_vms.yml

Bon, je vous ai pas menti, c’est quand même hyper simple non ?

A noter, actuellement le script traite les demandes de création de machines séquentiellement. Pour 3 VMs, comptez environ 3 minutes.

Cependant, si vous avez un gros besoin, sachez qu’il est possible de modifier le script pour les lancer en parallèle (déjà fait dans mon repo ansible-deploy-azure sur Github) via la fonction async d’Ansible.

Mise en place de l’inventaire dynamique

J’arrête pas de vous en parler depuis tout à l’heure, normalement dans Ansible, maintenant que nos VMs sont créées, pour pouvoir nous y connecter, on devrait créer un fichier texte “inventory” contenant la liste des hôtes et de leur IP (a minima). C’est fastidieux, surtout si vous avez beaucoup de VMs.

Et là, on a juste un fichier inventory.yml, contenant le nom du plugin, la région utilisée (Paris dans mon script) et le tag des machines générées :

plugin: scaleway
regions:
- par1
tags:
- proxmoxve

A partir de là, on peut vérifier le retour de la commande ansible-inventory

ansible-inventory --list -i inventory.yml
{
"_meta": {
"hostvars": {
"x.x.x.x": {
"arch": "x86_64",
"commercial_type": "DEV1-S",
"hostname": "test3",
[...]
"proxmoxve": {
"hosts": [
"x.x.x.x",
"y.y.y.y",
"z.z.z.z"
]
}

Petite hack SSH : comme Ansible se connecte en SSH aux hôtes distants, à la première connexion on va bloquer sur l’acceptation de la fingerprint.

Un moyen de bypasser ça en une ligne de commande est d’utiliser la commande ssh-keyscan et de coller tout ça dans votre known_hosts. On peut le faire avec ce petit oneliner :

ansible-inventory --list -i inventory.yml | jq -r '.proxmoxve.hosts | .[]' | xargs ssh-keyscan >> ~/.ssh/known_hosts

Ce n’est évidemment pas recommandé en production !!! Mais dans le cadre d’un test temporaire, vous me pardonnerez cette liberté.

Ajoutez votre clé SSH dans l’agent, puis vérifiez que vous pouvez vous connecter à tous les serveurs :

eval `ssh-agent`
ssh-add myprivate.key

ansible proxmoxve -i inventory.yml -u root -m ping
x.x.x.x | SUCCESS => {
"changed": false,
"ping": "pong"
}
y.y.y.y | SUCCESS => {
"changed": false,
"ping": "pong"
}
z.z.z.z | SUCCESS => {
"changed": false,
"ping": "pong"
}

Préparation du serveur

Ok ! Maintenant, on a 3 (ou plus) VMs Debian 9. A partir de là, j’ai créé un playbook Ansible qui suit la doc d’installation officielle de Proxmox sur un Debian Stretch.

ansible-playbook -i inventory.yml -u root proxmox_prerequisites.yml

A l’issue de l’installation, il est nécessaire de rebooter les serveurs (manuellement ou via ansible), pour passer sur le kernel de PVE.

Installation et configuration de tinc

C’est piou-piou.

Une fois que vos serveurs sont revenus à la vie, vous avez installé Proxmox. Pas mal hein ?

Cependant, chez Scaleway (et tous les autres providers que je connais), le multicast est coupé entre vos VMs. Et ça c’est la loose car tout notre clustering va passer par des trames multicast.

Pour bypasser ce souci de taille, le plus simple est de passer par un VPN, de créer un réseau privé virtuel entre toutes nos instances, qui lui ne filtrera rien.

Dans les articles précédents, j’avais utilisé OpenVPN (parce que c’est ce que je connais le mieux). Le souci d’OpenVPN c’est qu’il fonctionne sur un base client-serveur. Or, dès qu’on dépasse les 3 serveurs, on se retrouve avec 1 serveur maitre et 2 (ou plus clients), et donc un SPOF…

L’avantage avec tinc, c’est qu’on a pas cette notion de client/serveur. Tous les tincs sont connectés à tous les tincs, dans un genre de gros maillage qui nous évite donc tout SPOF.

L’installation de tinc n’est en soit pas follement complexe (cf le playbook), mais là encore, l’automatiser c’est toujours sympa.

ansible-playbook -i inventory.yml -u root tinc_installation.yml

Etapes additionnelles manuelles

Une fois que vous en êtes là, on arrive dans les tâches non triviales à automatiser.

Actuellement, il n’est pas possible de créer un cluster Proxmox VE sans avoir un mot de passe root. Or, lors de la création des VMs, Scaleway utilise notre clé SSH (ce qui est beaucoup mieux). Nous allons donc devoir nous connecter sur l’ensemble des machines et réinitialiser le mot de passe du compte root.

root@test1:~# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Créer un cluster

Cette partie aurait pu être automatisée. Dans le tutoriel précédent, je le faisais en ligne de commandes, à cause d’une limitation dans le wizard de création de cluster. En effet, dans les précédentes versions de Proxmox, on ne pouvait pas sélectionner sur quelle interface réseau on souhaitait utiliser, et donc mon cluster ne passait pas par le VPN et les trames multicast ne passaient jamais.

Pour autant, maintenant on peut profiter du beau wizard tout neuf et le faire via la GUI :

Se connecter à l’UI de Proxmox avec un des noeuds (le premier, au hasard)
Dans Datacenter (à gauche), sélectionner Cluster puis cliquer sur “Create Cluster”
Donner un nom au cluster, mais surtout, donner comme adresse ring0 l’adresse VPN (10.10.10.1 si on est sur le noeud 1)
Une fois l’opération terminée, cliquer sur “Join Information”, dans le même menu, et copier les informations en cliquant sur “Copy Information”

Joindre le cluster

Se connecter sur l’UI de la 2ème machine
Dans Datacenter, sélectionner Cluster puis cliquer sur “Join Cluster”
Dans le champ “Information”, coller les données récupérée lors de l’étape précédente. Les informations de connexion devraient automatiquement être remplies, SAUF le Corosync ring0, qu’il faut positionner à 10.10.10.2", et le mot de passe root du noeud 1. Cliquer sur “Join”.
Si l’opération réussie, un message doit s’afficher pour dire de recharger la page

Répéter l’opération pour les noeuds suivants (3, voire ++)

Et en attendant la même chose avec la v6, amusez vous bien :)