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 »

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 »

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 »

Containerlab, topologie de lab sur Docker

Containerlab

Avec le nombre croissant de switchs virtuels conteneurisés, le besoin de les exécuter facilement dans des topologies de simulation augmente. Je l’avais déjà évoqué en présentant le cEOS-lab Arista, les outils d’orchestration de conteneurs tels que docker-compose ne conviennent pas, car ils ne permettent pas de créer facilement des connexions entre les conteneurs pour définir une topologie.

Containerlab fournit une interface IaaC (Infrastructure as a Code) sous forme d’un langage de commande pour l’orchestration et la gestion des simulations réseau basées sur des conteneurs. Il démarre les conteneurs, construit un câblage virtuel entre eux pour créer des topologies et gère le cycle de vie des simulations.

Containerlab se concentre sur les NOS (Network Operating System) conteneurisés qui sont généralement utilisés pour tester les fonctionnalités réseau, tels que :

  • Nokia SR-Linux
  • Arista cEOS
  • Azure SONiC
  • Juniper cRPD
Continuer la lecture de « Containerlab, topologie de lab sur Docker »

Nautobot Inventory dynamique

Nautobot Inventory

Nautobot est une plateforme utilisée en tant que Source de Vérité et d’automatisation réseau extensible et flexible. Que ce soit pour mettre en place une automatisation Python ou Ansible, il est possible et judicieux d’utiliser Nautobot en tant qu’inventory.

Pour programmer en Python, l’utilisation du Framework Nornir est un standard pour l’automatisation réseau. Il existe le plugin nornir-nautobot qui permet de faciliter la connexion à la Source de Vérité et de filtrer les équipements sur lesquels on souhaite travailler.

Continuer la lecture de « Nautobot Inventory dynamique »

Sonde H5 audits sur simulateur

H5 audits EVE-NG

L’utilisation d’un simulateur est un élément incontournable pour une approche NetDevOps. Il est clair que tout constructeur ou fournisseur de logiciel incapable de passer sur un simulateur tel que EVE-NG, pour s’inscrire dans une infrastructure virtualisée, ne peut pas prétendre jouer dans la cours du SDN (Software Defined Network).

Lorsqu’il est question d’analyser le trafic au sein d’une infrastructure simulée, EVE-NG Pro dispose nativement de Wireshark pour effectuer des captures sur les liens inter-équipements. Mon souhait était de pouvoir aller plus loin dans l’analyse avec une sonde virtuelle.

L’avantage d’avoir un constructeur français de sondes, dont la recherche et développement est accessible, est d’avoir réussi à exprimer et défendre ce besoin et d’avoir été entendu. Je remercie Frédéric GUILLOIS (President H5 Audits) et Lionel BARRERE (Chief Technical Officer H5 Audits) de m’avoir écouté et d’avoir mis au point la réponse à ma demande.

Continuer la lecture de « Sonde H5 audits sur simulateur »

GraphQL et Nautobot

GraphQL Nautobot

GraphQL est un langage de requête et un environnement d’exécution côté serveur pour les API (Application Programming Interface) qui s’attache à fournir aux clients les données qui ont été demandées. Utilisé à la place de REST, GraphQL permet aux développeurs de créer des requêtes qui extraient les données de plusieurs sources à l’aide d’une seule requête API. Les requêtes GraphQL renvoient toujours des résultats prévisibles. Alors que les API REST typiques nécessitent un chargement à partir de plusieurs URL, les API GraphQL obtiennent toutes les données dont l’application a besoin en une seule demande. De plus, avec GraphQL, les équipes chargées de la maintenance des API peuvent librement ajouter ou retirer des champs sans perturber les requêtes existantes.

GraphQL a été développé par Facebook, qui a commencé à l’utiliser pour les applications mobiles en 2012. La spécification de GraphQL est devenue Open Source en 2015. Elle est désormais supervisée par la GraphQL Foundation.

Un service GraphQL est créé en définissant des types et des champs sur ces types, puis en fournissant des fonctions pour chaque champ sur chaque type. Par exemple, un service GraphQL qui indique qui est l’utilisateur connecté (me) ainsi que le nom de cet utilisateur peut ressembler à ceci :

type Query {
  me: User
}
 
type User {
  id: ID
  name: String
}

Avec des fonctions pour chaque champ sur chaque type :

function Query_me(request) {
  return request.auth.user;
}
 
function User_name(user) {
  return user.getName();
}
Continuer la lecture de « GraphQL et Nautobot »

Nautobot – Network to Code

Nautobot NTC

La solution communautaire NetBox a été supportée pendant plusieurs années par la société Network to Code qui a finalement décidé de procéder à un fork de manière à créer un nouveau produit appelé Nautobot avec une nouvelle orientation stratégique : proposer une plateforme d’automatisation avec un support de qualité.

Source de vérité flexible
À la base, Nautobot est une source de vérité qui définit l’état qui est prévu pour le réseau (Intent-Based Networking).


Plateforme de données extensible pour l’automatisation de réseau
Nautobot est plus que de la documentation du réseau. Nautobot propose des intégrations et une extensibilité pour véritablement alimenter des solutions d’automatisation de réseau. Nautobot possède des API de plateforme robustes qui incluent des API RESTful (HTTP) traditionnelles, des API GraphQL, des webhooks basés sur les événements et de nombreuses fonctionnalités d’extensibilité pour permettre une plus grande automatisation du réseau. Nautobot utilise également son extensibilité pour agréger des systèmes de données disparates créant une source unique de vérité pour les solutions d’automatisation de réseau.


Plateforme pour les applications d’automatisation de réseau
La plateforme d’applications Nautobot fournit une architecture à partir de laquelle des applications d’automatisation de réseau peuvent être créées. Les applications Nautobot sont des augmentations ou des ajouts flexibles et personnalisés. Grâce à la plateforme d’applications Nautobot, les entreprises peuvent fournir des extensions et des applications d’automatisation de réseau personnalisables 65 à 70% plus rapidement.

Continuer la lecture de « Nautobot – Network to Code »