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 »

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

Intent-Based Networking

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 de « Intent-Based Networking »

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 »

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 »

YANG Data Model

YANG Data Model

Dernière modification le 27 septembre 2020

YANG (Yet Another Next Generation) est un langage de modélisation de données pour la configuration du réseau. Il est utilisé pour exprimer la structure des données (pas les données elles-mêmes) et les instances de données peuvent être exprimées en XML, JSON, Protobuf, etc. Elles sont considérées comme valides si elles adhèrent au modèle de données YANG (schéma).

Les fichiers YANG sont appelés des modules, de façon similaire aux modules python (scripts). Nous pourrions faire les analogies suivantes par rapport au langage Python.

YANGPythonDescription
ModuleModuleUn fichier YANG complet
Data TypeData TypesString, Integer, Boolean, … Pour YANG on peut définir son propre type en utilisant typedef
Structures
LeafVariableUne seule variable pouvant contenir une seule valeur
Leaf-listListUne collection de Leaf du même type de données
ListDictionaryUne collection de paires clé / valeur, la clé est la Leaf et la valeur peut être n’importe quel type de données
ContainerClassHiérarchie de haut niveau qui regroupe Leaf, Leaf-list et list, et peut regrouper d’autres conteneurs
Analogies YANG et Python
Continuer la lecture de « YANG Data Model »

Automatisation et Orchestration des réseaux

Automatisation et Orchestration

L’automatisation est un sujet d’actualité dans le monde informatique d’aujourd’hui. Vous pouvez entendre parler de l’automatisation comme d’un moyen d’économiser de l’argent, d’améliorer l’efficacité et de supprimer les erreurs inhérentes.

Souvent, les termes automatisation et orchestration sont utilisés de façon incorrecte, dans une culture DevOps mal définie. Rappelons que DevOps est une nouvelle façon d’approcher la manière dont on conçoit, on exploite et on délivre les services IT. Entrer dans le monde DevOps implique de focaliser sur les objectifs, les personnes, les processus et les outils à mettre en œuvre…

Pour en savoir plus vous pouvez lire la suite de l’article our télécharger le document pdf mis en page.

La Source de Vérité NetBox

NetBox

NetBox est une application Web Open Source conçue pour aider à gérer et documenter les réseaux informatiques. Initialement conçue par l’équipe d’ingénierie réseau de DigitalOcean, NetBox a été développée spécifiquement pour répondre aux besoins des experts réseau et infrastructure. Il englobe les aspects suivants de la gestion de réseau :

  • IP address management (IPAM) – Réseaux et adresses IP, VRFs et VLANs
  • Equipment racks – Organisé par groupe et site
  • Devices – Types de devices et où ils sont installés
  • Connections – Connexions réseau, console et alimentation des devices
  • Virtualization – Machines virtuelles et clusters
  • Data circuits – Circuits de communication longue distance et fournisseurs
  • Secrets – Stockage crypté des informations d’identification sensibles

NetBox est construit sur le framework Django Python et utilise une base de données PostgreSQL. Il fonctionne comme un service WSGI derrière un serveur HTTP.

NetBox Application Stack
Continuer la lecture de « La Source de Vérité NetBox »

Pipeline CI/CD

Pipeline CI-CD

DevOps est une nouvelle façon d’approcher la manière dont on conçoit, on exploite et on délivre les services IT. J’ai eu souvent l’occasion de le dire et de l’écrire, mais réaliser des programmes ne fait pas du programmeur un DevOps et encore moins de la société qui l’emploie une société DevOps.

Entrer dans le monde DevOps implique de focaliser sur les objectifs, les personnes, les processus et les outils à mettre en oeuvre. Cet article se voulant plutôt orienté technique, il focalisera sur des éléments appartenant aux domaines des processus et des outils. Dans les processus DevOps, l’approche CI/CD (Continuous Integration / Continuous Delivery ou Deployment) est fondamentale. Le schéma proposé ci-dessus illustre le pipeline du « Continuous Integration » et met en évidence la différence subtile entre « Continuous Delivery » et « Continuous Deployment » et les deux premières étapes vont être expliquées.

Généralement associé à un gestionnaire de versioning, on utilise un outil d’intégration continue comme Jenkins, CircleCI ou l’intégration continue disponible dans GitLab pour mettre en place le pipeline proposé dans l’illustration de cet article.

Continuer la lecture de « Pipeline CI/CD »