Dernière modification le 10 août 2021
Pratiquer le Network as Code, qui se décline en différentes appellations dans la littérature (NetDevOps, NetOps, Infrastructure as Code, Intent Based Networking, …), fait appel à un simulateur réseau pour monter rapidement un environnement sans pour autant posséder tout le matériel nécessaire.
Si le but recherché est d’accéder à un équipement ou deux pour s’entrainer à la pratique du langage de commande (EOS, IOS, NXOS, Junos…), d’une technologie réseau (VXLAN, EVPN/VXLAN, MLAG,…) ou de techniques et technologies d’automatisation (Ansible, Python/Nornir, RESTCONF, NETCONF, gNMI/gRPC, …), il existe de nombreuses solutions qui peuvent s’accommoder de peu de ressources. Mais lorsqu’il s’agit de monter un véritable lab pour reproduire un environnement de simulation complet, on se rend compte qu’il faut rapidement disposer de ressources CPU et RAM importantes. La quantité nécessaire dépasse facilement les ressources disponibles sur une machine de développement ou d’enseignement.
Pourtant il peut s’avérer pratique d’être autonome et de ne dépendre ni d’un serveur additionnel, ni d’une ressource internet, sans pour autant mettre sa machine en surchauffe. Croyez moi, un MacBook Pro qui chauffe pendant la saison d’été c’est très désagréable pour les poignets et plus globalement pour la température ambiante.
Pour monter un environnement de virtualisation sur le MacBook, rien n’est plus rapide et léger que Multipass de Canonical. C’est la méthode recommandée pour créer des machines virtuelles Ubuntu sur Ubuntu. Il est conçu pour les développeurs qui souhaitent un nouvel environnement Ubuntu avec une seule commande et fonctionne sous Linux, Windows et macOS. Multipass utilise la virtualization native de chaque système d’exploitation sur lequel il est installé : Hyper-V sur Windows, HyperKit sur macOS et KVM sur Linux, pour une surcharge minimale et un temps de démarrage le plus rapide possible.
La solution la plus légère, pour faire tourner chaque noeud de l’infrastructure, est de faire appel à Docker. On sait qu’il n’est pas toujours simple de monter une architecture réseau un peu complète sous forme de conteneurs. C’est là que la solution Containerlab entre en jeu pour offrir un outil de déploiement d’infrastructure virtuelle conteneurisée. J’avais déjà évoqué cette solution dans un article au mois de mai 2021.
L’objectif de ce test est de chercher à quantifier une limite de ressource pour une architecture type « Clos Network » en Arista cEOS-lab.
La limite fixée pour la machine virtuelle est de 6 CPUs et 12 Go de RAM avec un disque de 8 Go. Multipass est un outil qui se pilote rapidement par un langage de commande, même si une partie graphique permet de synthétiser la situation.
multipass launch --name containerlab --mem 12G --disk 8G --cpus 6 multipass shell containerlab
La machine Linux Ubuntu 20.04 se gère tout à fait normalement, et une fois les mises à jour et réglages souhaités effectués, il convient d’installer Docker et Containerlab.
sudo apt install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"
sudo apt update
sudo apt install docker-ce
sudo usermod -aG docker ${USER}
su - ${USER}
bash -c "$(curl -sL https://get-clab.srlinux.dev)"
Le lab est constitué de sept switchs cEOS-lab et cinq serveurs Linux Alpine pour effectuer les tests de comportement dans le lab.
Le lancement du lab passe par la réalisation d’un fichier YAML de configuration Containerlab.
name: arista
topology:
kinds:
ceos:
image: ceosimage:4.26.0.1F
linux:
image: alpine:latest
nodes:
spine1:
kind: ceos
spine2:
kind: ceos
leaf1:
kind: ceos
leaf2:
kind: ceos
leaf3:
kind: ceos
leaf4:
kind: ceos
leaf5:
kind: ceos
server1:
kind: linux
server2:
kind: linux
server3:
kind: linux
server4:
kind: linux
server5:
kind: linux
links:
- endpoints: ["spine1:et1", "leaf1:et1"]
- endpoints: ["spine1:et2", "leaf2:et1"]
- endpoints: ["spine1:et3", "leaf3:et1"]
- endpoints: ["spine1:et4", "leaf4:et1"]
- endpoints: ["spine1:et5", "leaf5:et1"]
- endpoints: ["spine2:et1", "leaf1:et2"]
- endpoints: ["spine2:et2", "leaf2:et2"]
- endpoints: ["spine2:et3", "leaf3:et2"]
- endpoints: ["spine2:et4", "leaf4:et2"]
- endpoints: ["spine2:et5", "leaf5:et2"]
- endpoints: ["leaf1:et3", "server1:et1"]
- endpoints: ["leaf2:et3", "server2:et1"]
- endpoints: ["leaf3:et3", "server3:et1"]
- endpoints: ["leaf4:et3", "server4:et1"]
- endpoints: ["leaf5:et3", "server5:et1"]
Pour fonctionner, les images ont été chargées localement. Pour l’image cEOS-lab, c’est un import de l’archive qui est effectué et pour le serveur c’est un pull de l’image Alpine qui est réalisé depuis Docker Hub.
Le lancement du lab s’effectue à l’aide de la commande containerlab deploy -t arista.clab.yaml et moins de 15 secondes plus tard le lab est opérationnel. Il faut plusieurs minutes pour que les coeurs de CPU se calment et stabilisent leur pourcentage d’utilisation.
Containerlab réalise automatiquement un inventory qui est directement utilisable par Ansible.
all:
children:
ceos:
hosts:
clab-arista-leaf1:
ansible_host: 172.20.20.2
clab-arista-leaf2:
ansible_host: 172.20.20.10
clab-arista-leaf3:
ansible_host: 172.20.20.6
clab-arista-leaf4:
ansible_host: 172.20.20.4
clab-arista-leaf5:
ansible_host: 172.20.20.5
clab-arista-spine1:
ansible_host: 172.20.20.13
clab-arista-spine2:
ansible_host: 172.20.20.8
linux:
hosts:
clab-arista-server1:
ansible_host: 172.20.20.3
clab-arista-server2:
ansible_host: 172.20.20.12
clab-arista-server3:
ansible_host: 172.20.20.7
clab-arista-server4:
ansible_host: 172.20.20.9
clab-arista-server5:
ansible_host: 172.20.20.11
Tout est prêt pour pouvoir travailler de façon totalement autonome directement depuis la machine de développement. Il est certain que plus on voudra utiliser les fonctionnalités avancées de Containerlab et plus il faudra des ressources sur la machine Linux.
En baissant les ressources de la VM à 4 CPUs et 8 Go de RAM avec un disque de 6 Go, il est possible de déployer une architecture « Clos Network » réduite à cinq switchs et trois serveurs.
Pour avoir testé des mêmes configurations sur la plateforme hardware utilisée pour mes appliances EVE-NG avec une installation Ubuntu 20.04 bare metal et Containerlab, on peut repousser les limites beaucoup plus loin qu’avec un simulateur basé sur des VMs.