Afin de déployer le robot advisor dont j’ai parlé dans mon article précédent, j’avais besoin de 1. gérer facilement mon infra (serveurs && DB) et 2. éviter de passer des heures à configurer mes outils.
Afin de m’aider à automatiser ces tâches rébarbatives, je me suis décidé à installer les outils proposés par Canonical : MAAS, JuJu et kubernetes. J’avoue être impressionné par la puissance et la courbe d’apprentissage très rapide de ces outils disponibles gratuitement.
L’ensemble de cette installation fera l’objet de trois billets. Dans un premier temps, nous nous intéresserons à la configuration du réseau et des serveurs, le second billet décrira l’installation de MAAS, de juju et de kubernetes. Finalement, le dernier billet portera sur la pipeline de déploiement, avec un outil de gestion des sources, un hub docker et Jenkins pour la création d’un déploiement kubernetes.
Réseau physique
Le schéma ci-dessous présente l’architecture cible. Un modem / routeur connecté à internet. Deux réseaux de classe C : 192.168.0.0/24 et 10.0.0./24. Le premier, connecté à un access point wifi sur lequel se connectent tous les PC / téléphones / TV de la maison. Le second est un réseau dédié aux applications qui peuvent être accessibles (ou pas) depuis internet. Nous nous intéresserons ici à la configuration de ce second réseau, le premier n’ayant aucune différence avec la plupart des accès WIFI domestiques.
Seul élément remarquable, mon routeur le permettant, une route statique a été ajoutée qui permet de forwarder les paquets en provenance du réseau 192.168.0.0/24 à destination du réseau 10.0.0.0/24 vers le routeur
Le réseau 10.0.0.0/24 se compose de trois PC et d’un Raspberry Pi 3 utilisé comme serveur WEB et point d’entrée du réseau HTTP pour le domaine. Le système d’exploitation installé sur tous les éléments du réseau est la version 18.04 d’ubuntu serveur (Bionic Beaver). Le PC qui joue également le rôle de routeur possède deux cartes et permet ainsi d’accéder aux deux réseaux. Il est configuré avec des IP fixes du côté 192.168.0.0/24 et 10.0.0.0/24.
Configuration réseau des serveurs
La configuration du routeur est la suivante :
Nous le verrons plus bas, l’installation de KVM pour la gestion des machines virtuelles passe par la création d’un bridge (br0). J’ai volontairement laissé en commentaire la première version de la configuration du réseau 10.0.0.0/24 pour ceux d’entre vous qui choisiraient de ne pas installer de machines virtuelles sur cet élément.
Afin de faire communiquer les deux réseaux, un peu de configuration supplémentaire est nécessaire. Premièrement, il faut authoriser le système à forwarder les paquets. Cela est fait en éditant le fichier sysctl.conf.
nblotti@homer:~$ sudo cat /etc/sysctl.conf
[sudo] password for nblotti:
#
# /etc/sysctl.conf – Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
## Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1# Uncomment the next line to enable packet forwarding for IPv6
# Enabling this option disables Stateless Address Autoconfiguration
# based on Router Advertisements for this host
net.ipv6.conf.all.forwarding=1
Deuxièmement, le chemin entre les deux cartes réseau doit être défini grâce aux commandes suivantes :
sudo iptable -A FORWARD -i enp2s0f1 -o enx00e04c360061 -j ACCEPT
sudo iptables -A FORWARD -i enp2s0f1 -o enx00e04c360061 -j ACCEPT
Finalement, afin de laisser les pc du réseau 10.0.0.0/24 accéder à internet (nécessaire pour le déploiement d’application avec juju) , un NAT est configuré côté public.
sudo iptables -t nat -A POSTROUTING -o enx00e04c360061 -j MASQUERADE
En dehors des éléments ci-dessus qui ne s’appliquent qu’au routeur, la configuration des deux autres serveurs est assez proche :
Accès aux serveurs
L’accès aux serveurs se fait au travers de SSH. La création d’une clé en local et la copie sur les serveurs se fait aux travers des commandes suivantes :
ssh-keygen // génération d’une clé
ssh-copy-id 10.0.0.3 // copie sur le serveur 1
ssh-copy-id 10.0.0.4 // copie sur le serveur 1
Comme nous le verrons, c’est cette la même clé qui sera utilisée dans la configuration de MAAS.
Gestion des machines virtuelles avec KVM
Le cloud MAAS que nous allons créer ne travaillera qu’avec des machines virtuelles. Au final, les serveurs ne serviront donc que de « fournisseurs » de CPU, de RAM et d’espace de stockage.
En dehors de la configuration réseau et de l’installation du gestionnaire de machine virtuelle, les serveurs ne nécessiteront aucune configuration supplémentaire. De cette manière, on pourra en moins de 20 minutes rajouter un serveur et permettre à nos applications de scaler facilement.
L’installation de KVM se fait avec la commande suivante :
sudo apt-get install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils
Une fois KVM installé, il faut créer un bridge, afin de permettre à nos VM d’être visibles depuis l’extérieur au travers de leur adresse propre, fournie par le DHCP de MAAS. De plus, MAAS fonctionnant avec PXE pour le déploiement des machines, il faut que ce dernier soit accessible.
Sur le serveur concerné, la définition du bridge se fait en créant un fichier avec le contenu suivant :
cat maas.xml
<network>
<name>maas</name>
<forward mode= »bridge »/>
<bridge name= »br0″/>
</network>
Vous remarquerez que le bridge name, br0, fait référence aux bridge créé lors de la configuration du serveur.
La création, le démarrage du bridge et son démarrage au boot se font au travers des commandes suivantes :
virsh net-define maas.xml
virsh net-start maas
virsh net-autostart maas
Les machines virtuelles sont maintenant accessibles sau travers de Virtual Machine Manager :
La création de machines virtuelles ne se fera toutefois pas depuis cette interface, mais depuis MAAS ou Juju, comme nous le verrons dans les billets suivants.
Dernier point en ce qui concerne le monitoring. Nous utiliserons Nagios comme centralisateur d’alertes. Nagios sera déployé grâce à JuJu et son installation décrite dans le billet suivant.
Laisser un commentaire