Podcast NetDevOps NXOTECH

Podtcast NetDevOps Gilbert MOISIO
Podcast Youtube NetDevOps NXOTECH

Le NetDevOps est une approche transverse agnostique multi-constructeurs, multi-éditeurs et multi-technologies qui permet de centraliser et consolider les paramètres de l’infrastructure, et donne une visibilité complète sur l’ensemble des silos. En cela, elle garantit la sureté de fonctionnement.

La pratique NetDevOps répond au besoin d’exécution et de sécurisation pour accélérer le déploiement et les évolutions de l’infrastructure réseau au même rythme que les systèmes et les applications. 

Elle assure le déploiement des configurations avec rapidité, ainsi que la conformité et la sécurisation par rapport aux objectifs de fonctionnement et de maintien en condition opérationnelle des infrastructures réseaux. La modélisation du réseau est réalisée sur un simulateur, qui permet de valider les modifications avant déploiement, tout en assurant la cohérence de l’ensemble. Elle apporte par ailleurs de la visibilité sur l’ensemble des infrastructures via la télémétrie et le monitoring.

Podcast Spotify NetDevOps NXOTECH

Le mouvement NetDevOps

Mouvement NetDevOps

« NetDevOps est un sujet assez brûlant », déclare Andrew Lerner, vice-président de la recherche pour les réseaux chez Gartner.

« NetDevOps contribue à améliorer l’agilité et est particulièrement précieux pour les organisations mettant en œuvre le concept d’Infrastructure as Code, car le réseau est souvent un goulot d’étranglement », déclare Andrew Lerner. « Les pratiques NetDevOps génèrent des flux de travail et une documentation clairs, ce qui facilite l’audit, la gouvernance et le dépannage. »

Un autre avantage du NetDevOps est qu’il permet une plus grande collaboration entre les différents services informatiques, tout comme DevOps le fait avec le développement et les opérations.

La mutation n’en est qu’à ses début. Gartner estime entre 2 % et 10 %, les organismes qui auraient actuellement implémenté activement la démarche.

Continuer la lecture de « Le mouvement NetDevOps »

Définition du DevSecOps

DevSecOps

On voit apparaître de plus en plus de présentations d’acteurs de la sécurité des infrastructures qui glissent le mot DevSecOps partout en expliquant qu’il s’agit du DevOps appliqué à la sécurité, or ce mot n’a jamais été prévu pour ça.

Même si le marketing américain est friand de l’expression « A nice story doesn’t have to be true » et à moins de considérer que les appliances sécurité ne font pas partie intégrante de l’infrastructure réseau, appliquer les pratiques DevOps à ces solutions revient à faire du NetDevOps.

Selon la définition de Gartner, NetDevOps implique l’application des concepts DevOps CI/CD (Continuous Integration / Continuous Delivery-Deployment) aux activités de mise en réseau.

Le mot DevSecOps n’a rien à voir avec du SecDevOps dans lequel on aurait changé « Sec » de place pour faciliter la prononciation.

N’en déplaise aux conservateurs qui s’accrochent désespérément aux vieilles pratiques, l’approche DevOps s’impose dans tous les domaines et avec elle le « tout logiciel ». Le risque qui a été identifié, c’est que l’approche DevOps soit pratiquée par des personnes qui n’en ont pas toujours la compétence et qui prennent des raccourcis en mettant de côté certains sujets, comme la sécurité dans les implémentations. C’est la raison pour laquelle le mot DevSecOps a été créé : rappeler à tous que la sécurité doit faire partie intégrante de la pratique DevOps avec des bonnes pratiques de développement, mais aussi des tests automatisés à tous les niveaux des différentes implémentations.

Continuer la lecture de « Définition du DevSecOps »

Développer du NetDevOps dans des conteneurs Docker

VM Docker VSCode

Une question m’a été posée : « comment développer des applications NetDevOps directement dans des conteneurs ? ». Si la question peut sembler orienter le débat vers des sujets compliqués, il n’en est rien. Il existe une façon très simple de répondre.

Le contexte de la question doit être précisé. Il s’agissait de conteneurs Docker qui tournaient sur une VM Linux Ubuntu 20.04 distante. Les conteneurs étaient lancés avec de la persistance de stockage sur des volumes externes. C’est une bien meilleure pratique que d’utiliser des points de montage dans des répertoires de la VM (Virtual Machine).

Alors que les points de montages dépendent de la structure du répertoire et du système d’exploitation de la machine hôte, les volumes sont entièrement gérés par Docker. Les volumes présentent plusieurs avantages par rapport aux points de montages :

  • Les volumes sont plus faciles à sauvegarder ou à migrer que les points de montages sur des répertoires.
  • Il est possible de gérer les volumes à l’aide des commandes Docker CLI ou de l’API Docker.
  • Les volumes fonctionnent sur les conteneurs Linux et Windows.
  • Les volumes peuvent être partagés de manière plus sûre entre plusieurs conteneurs.
  • Les drivers de volume permettent de stocker des volumes sur des hôtes distants ou des fournisseurs de cloud, de chiffrer le contenu des volumes ou d’ajouter d’autres fonctionnalités.
  • Les nouveaux volumes peuvent avoir leur contenu pré-rempli par un conteneur.
  • Les volumes sur Docker Desktop ont des performances bien supérieures à celles des points de montages des hôtes Mac et Windows.

De plus, les volumes sont souvent un meilleur choix que les données directement stockées dans le conteneur, car un volume n’augmente pas la taille des conteneurs qui l’utilisent et le contenu du volume existe en dehors du cycle de vie d’un conteneur donné.

Continuer la lecture de « Développer du NetDevOps dans des conteneurs Docker »

Observabilité du réseau (part.3)

Suzieq Architecture

Cet article fait suite à la première partie qui présente la notion d’observabilité et à la deuxième partie qui présente la solution commerciale IP Fabric.

SuzieQ est une application open source proposée par la société Startdust Systems située à Sunnyvale en Californie. L’application collecte, normalise et stocke des données horodatées qui ne sont autrement disponibles qu’en se connectant à chaque équipement. Elle peut s’installer sous la forme d’un conteneur ou d’une VM dans laquelle elle est mise en place en tant que package Python.

Avec SuzieQ, il est possible d’acquérir une compréhension approfondie du réseau, remédier rapidement aux défaillances et identifier de manière proactive les problèmes du réseau avant que leurs effets ne se fassent sentir. Lors de la mise en place du modèle Intent-Based Networking, il est possible de s’assurer que chaque modification du réseau est automatiquement validée après avoir été effectuée.

SuzieQ fonctionne avec plusieurs constructeurs et collecte les données depuis Arista EOS (version 20.0 ou ultérieure), IOS, IOS-XE, IOS-XR et NXOS de Cisco (N7K avec les versions 8.4.4 ou supérieures et N9K avec les versions 9.3.1 ou supérieures), Cumulus Linux , Junos de Juniper (plates-formes QFX, EX, MX et SRX) et les plateformes SONiC. SuzieQ prend également en charge la collecte de données à partir de serveurs Linux. Le poller SuzieQ utilise SSH ou l’API REST d’un équipement pour collecter les données.

Suzieq Constructeurs
Constructeurs supportés
Continuer la lecture de « Observabilité du réseau (part.3) »

Observabilité du réseau (part.2)

IP Fabric Architecture

Cet article fait suite à la première partie et présente une des deux solutions évoquées.

IP Fabric, dont le siège Européen est situé à Prague en République Tchèque, est à la fois une société et un produit commercial soumis à licence. L’application s’installe avec les prérequis minimum suivants :

IP Fabric requirements
Dimensionnement

Les fonctionnalités sont articulées autour de trois grands domaines :

  • Découverte du réseau
    Après la phase de découverte, la plateforme crée un modèle mathématique du réseau à partir des données d’état et de configuration du réseau. Le modèle de réseau créé, appelé snapshot, intègre une logique de commutation, de routage et de sécurité permettant une visualisation avancée et des simulations de trafic réseau, ainsi que des chemins empruntés.
    La fonction de découverte cartographie l’infrastructure réseau de la même manière que le ferait un ingénieur réseau. En commençant par un périphérique de départ, le logiciel suit les relations réseau actives pour découvrir naturellement tous les chemins, périphériques et utilisateurs existants. Avec un algorithme de découverte avancé entièrement automatisé, la plateforme explore le réseau à l’aide de SSH (ou Telnet) et collecte les données opérationnelles et de configuration de tous les appareils. Cette partie du processus ne nécessite pas le protocole SNMP (Simple Network Management Protocol) et ne nécessite aucune modification du pare-feu non plus. Tout ce dont IP Fabric a besoin pour se mettre au travail, ce sont des informations d’identification en lecture seule et un accès à l’infrastructure.
    Le processus de découverte de réseau d’IP Fabric fonctionne sur les périphériques réseau actifs, tels que les commutateurs, les routeurs, les pare-feu, les équilibreurs de charge ou les contrôleurs Wi-Fi. Il collecte également des données sur les serveurs et autres appareils connectés au réseau. Le processus de découverte est évolutif et peut découvrir plus de 3000 appareils par heure.
    Afin d’être le plus agnostique possible, la liste des constructeurs et des configurations pris en charge est en constante évolution.
Continuer la lecture de « Observabilité du réseau (part.2) »

Observabilité du réseau (part.1)

Observabilité du réseau

Dernière modification le 16 avril 2022

Dans la boucle interne de l’Intent-Based Networking, il y a la partie « Intent Fulfillment » qui consiste à partir d’une Source de Vérité unique pour générer des configurations en direction des équipements (directement vers les équipements ou en passant pas une station de management) à l’aide d’un ensemble de programme et la partie « Intent Assurance » qui comprend, entre autre, le « Monitoring ».

Que ce soit dans ou en dehors de la démarche NetDevOps , le chapitre « Monitoring », qui comprend l’observabilité du réseau, est souvent mal compris et mal pris en compte.

Lorsque le sujet de la visibilité du réseau est abordé, la plupart des professionnels pensent à la surveillance du réseau en terme de monitoring traduit par « surveillance ». Les outils de monitoring fournissent une vue centralisée de la santé opérationnelle de l’infrastructure sous-jacente.

Les protocoles et technologies courants de surveillance du réseau incluent entre autre : SNMP (Simple Network Management Protocol), NetFlow, sFlow et syslog. Ils se retrouvent dans des produits aussi divers que Grafana/Prometheus, Zabbix, sFlow-RT, ntopng, Graylog…
La surveillance du réseau nécessite généralement une intervention humaine pour établir le comportement normal du réseau et du trafic. Ensuite, des outils de surveillance identifient et alertent les équipes sur les modifications du comportement attendu. Par exemple, les équipes peuvent utiliser SNMP pour référencer le comportement de débit d’une liaison réseau critique au fil du temps. Une fois que les administrateurs ont déterminé le comportement de base, l’outil de surveillance peut les alerter lorsque le comportement de débit dépasse ce qui est typique.

Continuer la lecture de « Observabilité du réseau (part.1) »

Intent-Based Networking, concepts et définitions

Internet Research Task Force

Dernière modification le 9 janvier 2022

Les bases de la définition de l’IBN (Intent-Based Networking) ont été posées en décembre 2019 dans le groupe de recherche NMRG (Network Management Research Group) de l’IRTF (Internet Research Task Force). Elle a évolué pendant deux ans et à la date d’écriture de cet article, c’est la version 06 du 15/12/2021 qui est active.

Alors que les réseaux qui acceptent les ordres sous forme d’intentions s’appellent « Intent-Based Networks » (IBN), les systèmes qui permettent cette implémentation se nomment « Intent-Based Systems » (IBS). L’intention se définit comme un ensemble d’objectifs opérationnels qu’un réseau doit atteindre et les résultats qu’un réseau est censé fournir, sans préciser comment les atteindre ou les mettre en œuvre. Le terme « Intent » est apparu la première fois en juin 2015 dans le RFC 7575 « Autonomic Networking ».

L’intention applique plusieurs concepts simultanément :

  • Fournir une abstraction des données : les utilisateurs n’ont pas besoin de s’inquiéter de la configuration de bas niveau des équipements.
  • Fournir une abstraction fonctionnelle : les utilisateurs n’ont pas besoin de se préoccuper de la manière d’atteindre une intention donnée. Ce qui est spécifié est le résultat souhaité, avec l’IBS qui détermine automatiquement un plan d’action (par exemple, en utilisant un algorithme ou en appliquant un ensemble de règles dérivées de l’intention) pour savoir comment atteindre le résultat.
Continuer la lecture de « Intent-Based Networking, concepts et définitions »

Le Web 3.0, technologie opérationnelle

Web 3.0

Dernière modification le 9 janvier 2022

A l’origine, le Web 3.0 a été nommé le Web sémantique par l’inventeur du World Wide Web, Tim Berners-Lee. Il visait à devenir un Internet plus autonome, intelligent et ouvert.

On peut ajouter que les données sont interconnectées de manière décentralisée, ce qui constitue un énorme pas en avant par rapport à notre génération actuelle d’Internet Web 2.0, où les données sont principalement stockées dans des référentiels centralisés.

Les utilisateurs et les machines peuvent interagir avec les données. Mais pour que cela se produise, les programmes doivent comprendre les informations à la fois conceptuellement et contextuellement. Dans cette optique, les deux technologies essentielles du Web 3.0 sont le Web sémantique et l’Intelligence Artificielle (IA).

Comme les réseaux Web 3.0 fonctionnent via des protocoles décentralisés – un des fondamentaux de la technologie blockchain et crypto-monnaie – nous voyons une forte convergence entre ces technologies.

Toutes les personnes qui suivent les projets de la blockchain, savent que le Web 3.0 est déjà là au travers de nombreux projets qui couvrent plusieurs domaines actuellement entre les mains des GAFAM. Il en existe beaucoup, mais pour ne prendre que seulement deux d’entre eux, nous avons une illustration de la décentralisation de la fonction Cloud et de la fonction Recherche.

Continuer la lecture de « Le Web 3.0, technologie opérationnelle »