Gilbert MOISIO – Page 3 – Gilbert MOÏSIO

3 octobre 2021

Automatisation Juniper – Aéroport Nice Côte d’Azur

L’aéroport Nice Côte d’Azur est le deuxième aéroport de France avec 14.5 millions de passagers par an et un réseau de plus de 120 destinations, en majorité à l’international.

EVPN (Ethernet VPN)-VXLAN (Virtual Extensible LAN)
Underlay eBGP
Overlay iBGP
Centrally Routed Bridging (CBR) Overlay
30 switchs Juniper QFX
10 VRFs
250 VLANs
480 ports
4000+ machines connectées

Grafana Aéroports de la Côte d'Azur — Monitoring Grafana / Prometheus en lab

Écosystème NetDevOps Aéroports de la Côte d'Azur — Écosystème NetDevOps ACA

Écosystème NetDevOps Aéroport Nice Côte d’Azur :

EVE-NG Pro
GitLab
Docker Swarm
GlusterFS
Juniper
Ansible
Python
Junos PyEZ
Robot Framework
Grafana
Prometheus
SNMP Exporter
Blackbox Exporter
gNMIc

26 août 202127 août 2021

Écosystème Nautobot

Fidèle à sa stratégie, Nautobot ne cesse d’enrichir son écosystème. C’est le bon moment pour faire un point sur la situation en vue de la rentrée prochaine.

Continuer la lecture

8 août 202110 août 2021

Administrer Kubernetes avec Rancher

Dernière modification le 10 août 2021

Vous déployez des clusters Kubernetes partout – sur site, dans le cloud et à la périphérie. Rancher unifie ces clusters pour assurer des opérations cohérentes, une gestion de la charge de travail et une sécurité de niveau entreprise…

Rancher est un projet Open Source avec un support disponible pour les entreprises. Pour ceux qui souhaiteraient le tester, voici une procédure simplifiée sur la base d’un serveur Ubuntu 20.04 à jour et disposant d’au moins 2 vCPUs, 4 Go de RAM et 20 Go de disque.

Installer Kubernetes K3s

sudo apt install curl
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--write-kubeconfig-mode 644" sh -

Installer Helm

wget https://get.helm.sh/helm-v3.6.3-linux-amd64.tar.gz
tar -zxvf helm-v3.6.3-linux-amd64.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/helm

Installer Rancher

mkdir .kube
kubectl config view --raw > ~/.kube/config
chmod 600 ~/.kube/config
kubectl create namespace cattle-system
kubectl create namespace cert-manager
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.4.3/cert-manager.crds.yaml
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v1.4.3
kubectl get pods --namespace cert-manager
helm install rancher rancher-latest/rancher --namespace cattle-system --set hostname=k3s-rancher.homelab.int
kubectl -n cattle-system rollout status deploy/rancher
kubectl -n cattle-system get deploy rancher

Il reste à faire pointer l’URL k3s-rancher.homelab.int vers l’adresse IP de la machine grâce au fichier /etc/hosts du poste de travail, puis naviguer vers https://k3s-rancher.homelab.int/.

Kubernetes Rancher Cluster Manager — Rancher Cluster Manager

Kubernetes Rancher Cluster Explorer — Rancher Cluster Explorer

4 août 202110 août 2021

Kubernetes pour le NetDevOps

Dernière modification le 10 août 2021

Lorsqu’il s’agit d’installer un environnement système et applicatif pour le NetDevOps, la question qui consiste à choisir entre Docker et Kubernetes ne pose plus vraiment de dilemne.

Pendant un certain temps, la réponse la plus adaptée était qu’ils étaient complémentaires, mais ce n’est plus le cas. Depuis début 2021, Kubernetes ne supporte plus Docker en tant qu’environnement d’exécution de conteneur.

Kubernetes fonctionne avec tous les environnements d’exécution de conteneur qui implémentent une norme connue sous le nom de CRI (Container Runtime Interface). Il s’agit essentiellement d’un moyen standard de communication entre Kubernetes et l’environnement d’exécution du conteneur, et tout environnement d’exécution prenant en charge cette norme fonctionne automatiquement avec Kubernetes.

Docker n’implémente pas l’interface d’exécution de conteneur (CRI). Dans le passé, il n’y avait pas autant d’options pour les environnements d’exécution de conteneurs, et Kubernetes avait implémenté le Shim Docker, une couche supplémentaire servant d’interface entre Kubernetes et Docker. Maintenant, cependant, il existe de nombreux runtimes disponibles qui implémentent le CRI, et il n’est plus logique que Kubernetes maintienne un support spécial pour Docker.

Pour vraiment comprendre pourquoi il est logique que Kubernetes se détache de Docker, il faut comprendre que Docker n’est pas vraiment un environnement d’exécution de conteneur. C’est en fait une collection d’outils qui se trouve au-dessus d’un environnement d’exécution de conteneur appelé containerd. Docker n’exécute pas directement les conteneurs. Il crée simplement une interface plus accessible et plus riche en fonctionnalités en plus d’un environnement d’exécution de conteneur sous-jacent séparé. Lorsqu’il est utilisé comme environnement d’exécution de conteneur pour Kubernetes, Docker n’est qu’un intermédiaire entre Kubernetes et containerd. Or, Kubernetes peut utiliser containerd directement comme environnement d’exécution de conteneur, ce qui signifie que Docker n’est plus nécessaire dans ce rôle d’intermédiaire.

Continuer la lecture

2 août 20212 août 2021

Nokia SR Linux

SR Linux est un NOS (Network Operating System) qui exploite la pile de protocoles de routage de Nokia SR OS, tout en utilisant également Linux comme système d’exploitation sous-jacent, permettant aux administrateurs d’utiliser des outils de débogage et de configuration qu’ils connaissent bien, même s’ils n’ont aucune expérience avec SR OS.
Les fonctions de routage sur SR Linux s’exécutent comme des applications modulaires et légères, configurables via des API externes. Ces applications utilisent gRPC et des API pour communiquer entre elles et avec des systèmes externes via TCP. Les applications fournies par Nokia peuvent être complétées par des applications développées par des tiers, qui se connectent au framework SR Linux. Les fonctions « Application-based » permettent des mises à jour modulaires et une isolation facile des pannes.

SR Linux utilise largement les modèles de données structurées. Chaque application a un modèle YANG qui pilote sa configuration et son état. SR Linux expose les modèles YANG aux API de gestion prises en charge. Par exemple, l’arborescence de commandes dans le CLI est dérivée des modèles SR Linux YANG chargés dans le système, et un client gNMI peut utiliser des RPC définis pour configurer une application en fonction de son modèle YANG. Lorsqu’une configuration est validée, le serveur de gestion SR Linux valide les modèles YANG et les traduit en « protocol buffers » pour la base de données IDB (Impart DataBase).

Modularité Nokia SR Linux — Source Nokia

Continuer la lecture

25 juillet 202110 août 2021

Un lab économique pour le Network as Code

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.

Continuer la lecture

18 juillet 202118 juillet 2021

Ansible Collection 1.3.0 pour OmniSwitch AOS

La collection est disponible dans la Galaxy Ansible et attend vos tests et propositions d’améliorations, le dépôt officiel des modules étant dans le GitHub public. La licence utilisée permet toutes les améliorations des Network Modules et Filtres sur la branche main, mais n’autorise pas la redistributions des forks, afin d’éviter la perte d’énergie (licence Attribution-NonCommercial-NoDerivatives 4.0 International / CC BY-NC-ND 4.0).

Modules

gmoisio.ale.ale_aos_ping : Vérifie la connectivité en SSH à un équipement.
gmoisio.ale.ale_aos_command : Exécute une liste de commandes sur un équipement. Il est possible de chercher une chaîne de caractères dans le résultat de chaque commande en passant un dictionnaire dans la liste. Dès qu’une chaine de caractère n’est pas trouvée, l’exécution des commandes s’arrête.
gmoisio.ale.ale_aos_config : Exécute un ensemble de commandes, généralement pour effectuer une configuration. L’ensemble des commandes peut être transmis sous la forme d’une liste ou sous la forme d’un fichier texte pouvant être généré via un template Jinja2.
gmoisio.ale.ale_aos_facts : Module expérimental permettant de récupérer des informations (vlans, interfaces et serveurs ntp) sous la forme d’un dictionnaire de listes pour effectuer des boucles.

Filtres

gmoisio.ale.validate : Ce filtre permet de valider des variables en les confrontant à un schéma YAML. La génération d’un template Jinja2 s’arrête en affichant les causes d’erreurs si les variables ne sont pas conformes au schéma. Le filtre peut être utilisé dans un playbook pour seulement valider la Source de Vérité.

Continuer la lecture

14 juillet 202115 juillet 2021

Documenter du code Python

Lorsqu’il s’agit de documenter des développements, il existe plusieurs méthodes. Soyons direct, l’approche qui consiste à réaliser un document n’a aucune pérennité. Dès les premières phases de refactoring ou d’amélioration, la documentation ne sera pas mise à jour.

L’approche qui consiste à utiliser un Wiki est déjà plus souple et permet à plusieurs développeurs de collaborer sur la construction documentaire. Cependant, idéalement, il convient de limiter les changements d’environnements qu’un développeur peut être amené à faire pour mener à bien sa mission. Il y a deux environnements dans lequel le développeur évolue depuis son IDE (Integrated Development Environment).

Il y a tout d’abord le répertoire qui contient l’ensemble de l’arborescence du produit et qui se traduit sur le serveur de versioning par une branche dans un repository. Le format le plus utilisé est le markdown qui permet de créer des fichiers documentaires un peu agrémentés de mises en pages, sachant que par convention, un serveur de versioning affiche automatiquement le fichier README.md du répertoire visité.

Le deuxième environnement est le code lui-même, dans lequel il est naturel pour le développeur, d’intégrer au moins des commentaires qui lui permettront de retrouver la logique utilisée lorsqu’il se replongera, plus tard, dans le code. Comme défini dans PEP 8 (Style Guide for Python Code), les commentaires peuvent être de type « Block Comments » ou « Inline Comments ».

Continuer la lecture

27 juin 202127 juin 2021

Ansible Collection 1.2.2 pour OmniSwitch AOS

La collection est disponible dans la Galaxy Ansible et attend vos tests et propositions d’améliorations, le dépôt officiel des modules étant dans le GitHub public. La licence utilisée permet toutes les améliorations des Network Modules sur la branche main, mais n’autorise pas la redistributions des forks, afin d’éviter la perte d’énergie (licence Attribution-NonCommercial-NoDerivatives 4.0 International / CC BY-NC-ND 4.0).

gmoisio.ale.ale_aos_ping : Vérifie la connectivité en SSH à un équipement.
gmoisio.ale.ale_aos_command : Exécute une liste de commandes sur un équipement. Il est possible de chercher une chaîne de caractères dans le résultat de chaque commande en passant un dictionnaire dans la liste. Dès qu’une chaine de caractère n’est pas trouvée, l’exécution des commandes s’arrête.
gmoisio.ale.ale_aos_config : Exécute un ensemble de commandes, généralement pour effectuer une configuration. L’ensemble des commandes peut être transmis sous la forme d’une liste ou sous la forme d’un fichier texte pouvant être généré via un template Jinja2.
gmoisio.ale.ale_aos_facts : Module expérimental permettant de récupérer des informations (vlans, interfaces et serveurs ntp) sous la forme d’un dictionnaire de listes pour effectuer des boucles.

Pour exécuter le module gmoisio.ale.ale_aos_command sous sa nouvelle forme, il convient de se conformer aux syntaxes suivantes :

---
- name: This is a test for ale_aos_command module
  hosts: ale
  connection: local
  gather_facts: no
  tasks:
    - name: Test ale_aos_command Python module
      gmoisio.ale.ale_aos_command: 
        host: "{{ ansible_host }}"
        username: "{{ login }}"
        password: "{{ password }}"
        commands:
          - show running-directory
          - show vlan

Continuer la lecture

14 juin 202117 juin 2021

Intent-Based Networking

Dernière modification le 17 juin 2021

Vous vous souvenez des étapes de l’implémentation DevOps pour les infrastructures réseaux déjà présentées dans cet article. Bien que tout ceci puisse vous faire penser à du marketing ou même à du buzzword, il s’agit bien de réalités terrains qui sont concrètement mises en oeuvre avec des étapes intermédiaires supplémentaires.

Etapes Automatisation — Source Juniper Networks

Si nous remontons dans l’histoire, le scripting n’est pas un phénomène nouveau. Dès le début de ma carrière, j’utilisai déjà le scripting pour automatiser les déploiements. Il s’agissait de programmes écrits en perl (1987) ou en Visual Basic (1991) finalement associé avec SecureCRT (1995) dont l’objectif était d’envoyer des commandes CLI sur les équipements et d’analyser les réponses (méthode appelée Screen Scraping). Ce qui a changé avec le temps, c’est le fait d’utiliser des protocoles de communication optimisés (NETCONF, RESTCONF ou gNMI) et des formats de données adaptés (XML, JSON ou protobuf), pour parler de « Human-driven Automation ».

Bien que de nombreuses idées fondamentales des approches DevOps, comme les pratiques Lean, le mode Agile ou le cycle Plan-Do-Check-Act de la roue de Deming, ont été popularisés dans les années 1990, le terme DevOps que nous connaissons est né en 2009. Après avoir été appliqué aux développement, puis au système, le DevOps a finalement été appliqué au réseau. Le mouvement NetDevOps avait pour objectif de supprimer le goulot d’étranglement que représentait le réseau dans les cycles rapides d’adaptation imposés par les applications et les infrastructures de serveurs en mouvements permanents pour suivre les besoins métiers et marchés. Le NetDevOps propose l’idée de considérer l’infrastructure réseau en tant que IaC (Infrastructure as Code) ou plus spécifiquement NaC (Network as Code), avec tous les principes techniques, technologiques, méthodologiques, organisationnels et humains sous-jacents. Le NetDevOps a apporté un tournant dans les nouveaux profils de compétences nécessaires à son application concrète.

Continuer la lecture