Quel rapport entre le NetDevOps et le Web 3.0

Web 3.0

Ne regarde pas la télévision de si près, c’est mauvais pour les yeux !

Vous aussi vous avez entendu cette phrase à de nombreuses reprises quand vous étiez plus jeunes ? Et pourtant, nous continuons souvent de regarder de trop près ! Vous êtes vous déjà demandé pourquoi on parlait du NetDevOps, de l’Infrastructure as Code et pourquoi on y utilisait autant de technologies issues du système, du développement, de l’Edge Computing, de l’Intelligence Artificielle et de la Blockchain (croyez moi, vous allez le voir arriver).

Je vous propose de prendre beaucoup de hauteur pour regarder le paysage technologique qui se dessine…

Les informations de fuites de données et de censures sont sorties de la presse spécialisée pour atteindre le grand public, avec une forte accentuation depuis deux ans. Est-ce que le Covid a exacerbé le phénomène ? Peut être !

Nous sommes arrivés bien loin de l’idée première d’Internet qui permettait de disposer d’un espace de liberté visant à contourner la censure et outrepasser les frontières. Des algorithmes, de plus en plus pointus, déterminent les contenus que nous consommons. Des géants du numérique se sont imposés. Les GAFAM (Google, Apple, Facebook, Amazon et Microsoft, aussi appelés « Big Five ») qui pèsent à eux seuls une capitalisation boursière d’environ 5.000 milliards de dollars, vendent nos informations personnelles sans qu’aucune récompense ne nous soit directement rétribuée. On essaye de nous faire croire que grâce à l’argent récolté, on nous propose de plus en plus de services gratuits, mais ce n’est qu’une utopie car ces services permettent de nous cerner encore plus pour récolter toujours plus d’informations sur nos comportements.

Continuer la lecture de « Quel rapport entre le NetDevOps et le Web 3.0 »

L’Intelligence Artificielle au service du NetDevOps

Intelligence Artificielle

Je le répète assez souvent : « l’Intelligence Artificielle peut nous rendre des services dans le NetDevOps » pour résoudre des problèmes qui nécessiteraient des algorithmes très longs basés sur des successions de tests. Pour illustrer concrètement ces propos, je vous propose d’étudier un cas simple d’application de l’apprentissage automatique.

Prenons un exemple qui pourrait parfaitement faire partie d’un test de QI. Soit la suite de nombre suivante :

X-1012345
Y-3-11357?

Compléter la dernière valeur de Y manquante…

Pour résoudre ce problème, il va falloir trouver la relation qui relie X et Y et une fois trouvée, l’appliquer à la valeur manquante. Un oeil un peu entrainé va rapidement voir que la relation est Y = 2X – 1

Par soucis de validation, on pourra l’appliquer à chacun des X pour vérifier qu’on a trouvé la relation avec certitude. Une fois validée, la relation sera appliquée à la dernière valeur de X pour trouver Y = 9. Cette relation pourrait s’appliquer à de nouvelles valeurs de X.

Fonction AI
Fonction f(x)=2x-1
Continuer la lecture de « L’Intelligence Artificielle au service du NetDevOps »

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

ACA

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 ACA
Monitoring Grafana / Prometheus en lab
Écosystème NetDevOps ACA
É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

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/.

Rancher Cluster Manager
Rancher Cluster Manager
Rancher Cluster Explorer
Rancher Cluster Explorer

Kubernetes pour le NetDevOps

Kubernetes

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 de « Kubernetes pour le NetDevOps »

Nokia SR Linux

Nokia SR Linux Data Center

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.

Nokia SR Linux
Source Nokia

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é SR Linux
Source Nokia
Continuer la lecture de « Nokia SR Linux »

Un lab économique pour le Network as Code

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 de « Un lab économique pour le Network as Code »

Ansible Collection 1.3.0 pour OmniSwitch AOS

ALE Ansible Collection

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 de « Ansible Collection 1.3.0 pour OmniSwitch AOS »

Documenter du code Python

Documenter 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 de « Documenter du code Python »