Appliance v3.0

Appliance v3.0

L’objectif de cette nouvelle appliance n’est pas de remplacer l’Appliance Automation v2.0, ni l’Appliance EVE-NG v2.0. C’est une autre approche dont l’objectif est de concentrer de la puissance dans une plateforme miniature qui permet d’offrir la quasi-totalité des fonctionnalités des deux autres plateformes réunies. De même, le coût de cette plateforme est approximativement équivalente aux deux autres réunies.

Le premier étage sert à offrir des services de connexion réseau indépendamment des possibilités de l’infrastructure d’accueil.

Premier Etage Appliance v3.0
Continuer la lecture de « Appliance v3.0 »

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.

Network Operating System SONIC

SONIC

Dernière modification le 25 avril 2020

La désagrégation entamée par le mouvement du SDN (Software-Defined Networking) a, tout logiquement, entraîné la banalisation de la couche « Infrastructure Layer » ou « Data Plane ». Des fabricants de commutateurs ODM (Original Design Manufacturers) proposent des matériels appelés « Bare-metal » par analogie à des serveurs que l’on a pour habitude d’acheter sans aucun système d’exploitation installé. En tant que ODM on peut citer, par exemple, Dell, Mellanox, Facebook, Supermicro, mais surtout, Edgecore Networks, Quanta Cloud Technology ou Netberg. Les plus grand DataCenters comme Facebook ont été moteurs pour explorer cette voie qui leur laissait présager des économies d’échelle. Facebook a poussé le mouvement « Open Compute Project » pour proposer de couvrir différents aspects d’un DataCenter avec des matériels banalisés et des projets Open Source. Mais il ne faut surtout pas croire que l’approche consistant à fabriquer ses propres commutateurs n’est réservée qu’aux plus grands acteurs.

Dans ce domaine, il y a souvent une confusion entre « Bare-metal », « White box » et « Brite box » (BRanded whITEBOX). L’idée générale reste de ne plus accepter des systèmes propriétaires sur des matériels propriétaires. Les commutateurs « Bare-metal » sont livrés, comme des serveurs, avec un matériel et un firmware prêts à recevoir le « Network Operating System » de son choix. Le firmware qui s’est imposé s’appelle ONIE (Open Network Install Environment) et les « Network Operating Systems » les plus répandus sont OpenSwitch et ONL (Open Network Linux) dans le monde de l’Open Source et Pica8, ainsi que Cumulus Networks pour ce qui est de l’offre commerciale. Le concept de « White box » consiste, pour un acteur hors des fabricants traditionnels de matériel réseau, de prendre des commutateurs « Bare-metal » et d’intégrer un « Network Operating Systems » de leur choix ou même de leur fabrication.

Continuer la lecture de « Network Operating System SONIC »

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 »

Network Source of Truth (NSoT)

Network Source of Truth

Dernière modification le 12 février 2020

L’automatisation réseau et plus généralement l’approche NetDevOps nécessite une source de vérité pour stocker les informations de référence. L’automatisation du réseau doit connaître l’infrastructure sur laquelle elle agit. Cette connaissance nécessite des données complètes sur la configuration et l’état de ce réseau.

Une étude menée par EMA (Enterprise Management Associates), « Enterprise Network Automation for 2020 and Beyond », a révélé que 98% des initiatives d’automatisation de réseau d’entreprise ont une certaine conscience de l’intérêt d’une source de vérité réseau, et 41% des entreprises considèrent leur source de vérité comme indispensable à l’automatisation. Cette recherche, basée sur une enquête auprès de 250 professionnels de l’informatique directement impliqués dans une initiative formelle d’automatisation de réseau, a révélé que les entreprises qui réussissent avec l’automatisation de réseau sont plus susceptibles de considérer la source de vérité comme essentielle.

Pour l’avoir moi-même observé, si aucune source de vérité n’est explicitement définie et respectée, il y aura toujours quelqu’un pour faire une modification en dehors du processus d’automatisation. Le jour où une reconstruction est lancée par automatisation, il manquera un élément dans la configuration…

Continuer la lecture de « Network Source of Truth (NSoT) »

DevOps

Approche DevOps

DevOps est un processus de développement, de livraison et d’exploitation logicielle. Il existe de nombreuses définitions de DevOps dans des ouvrages et sur Internet qui sont imprécises et parfois déroutantes.
Une autre variante trompeuse, est de se limiter à voir DevOps comme une intersection du travail et des personnes dans une organisation informatique, entre les développeurs de logiciels, les testeurs de logiciels et les personnes responsables de la production.

La meilleure approche pour le définir, est de voir DevOps comme du développement itératif de logiciel en mode Agile avec des cadres d’amélioration continue des processus tels que Scrum, Lean, ITIL, …
Pour autant, il ne faut pas considérer que DevOps est un sur-ensemble amélioré et combiné de ces méthodologies et techniques.
La façon simple de s’en convaincre est qu’aucune de ces méthodologies et cadres, hormis Agile et Scrum, n’ont été introduits pour résoudre spécifiquement les problèmes de l’industrie du logiciel.
De nombreuses pratiques et principes DevOps ont été dérivés des sept principes du mouvement Lean après avoir été adaptés, expérimentés, validés et affinés pour le développement, la livraison et l’exploitation de logiciels.

Continuer la lecture de « DevOps »

Python WSGI ou ASGI

Python WSGI ASGI

Contrairement à JavaScript ou Go, Python n’est pas un langage dont l’exécution asynchrone a été intégrée dès le départ. Pendant longtemps, l’exécution simultanée en Python ne pouvait être réalisée qu’en utilisant le multithreading ou le multiprocessing, ou en ayant recours à des bibliothèques spécialisées telles que eventlet, gevent ou Twisted.

Mais tout a changé quand asyncio a été ajouté à la bibliothèque standard pour prendre en charge du multitâche coopératif. Plus tard, la syntaxe async/await a été ajoutée dans Python 3.5. Grâce à cela, nous avions des coroutines natives indépendantes de l’implémentation sous-jacente, ce qui a ouvert la ruée vers l’asynchrone en Python.

ASGI (Asynchronous Server Gateway Interface) est une sorte de successeur de WSGI ( Web Server Gateway Interface), destiné à fournir une interface normalisée entre les serveurs Web compatibles async , les frameworks et les applications Python.
Là où WSGI fournissait une norme pour les applications Python synchrones, ASGI en fournit une pour les applications asynchrones et synchrones, avec une implémentation apportant une compatibilité descendante avec WSGI et de nombreux serveurs et frameworks d’application.

Continuer la lecture de « Python WSGI ou ASGI »

Méthode ScrumBan

ScrumBan

Scrum est un framework, ou cadre de travail, qui inclut la notion d’itérations courtes (sprints) pour réaliser un produit morceau par morceau. Ces itérations sont rythmées par des réunions appelées « cérémonies », comme les daily scrum qui sont des réunions quotidiennes que je conserve en ScrumBan, les revues de sprint qui se produisent à la fin d’une itération ou encore les rétrospectives pour améliorer la façon de travailler de l’équipe.

Dans la méthodologie Scrum, trois rôles sont proposés et je les conserve en ScrumBan : le Product owner (PO), le Scrum master (SM) et l’équipe de réalisation (Team). Le PO est identifié en tant que détenteur du besoin. Dans le domaine des infrastructures, il est fréquent de proposer que ce rôle appartienne au client. Le SM est le garant de la méthodologie, mais il est aussi celui qui va débloquer les situations. Il facilite et provoque les événements Scrum lorsqu’il le faut (daily meeting, revues de sprint, planification…). Enfin, l’équipe de réalisation est là pour implémenter le produit selon les User Stories présentes dans le backlog de sprint.

Continuer la lecture de « Méthode ScrumBan »

Projet vs Produit

Projet vs Produit

Dans le modèle Waterfall, le cycle de développement et de livraison d’un système suit une liste d’étapes en ordre séquentiel. Cette façon de faire à l’avantage de fournir un plan projet définit dès le départ, ce qui résulte la plupart du temps en une gestion budgétaire précise. Chaque composante du système est développée séquentiellement, et menée à terme avant qu’une autre fonctionnalité ne soit programmée. C’est un modèle qui a été systématiquement utilisé, mais qui présente plusieurs lacunes importantes, dont il conviendrait de s’affranchir lorsque le contexte client le permet.

En général, l’analyse des besoins du client se fait conjointement avec lui, sur une période qui pourra varier considérablement et s’étendre parfois jusqu’à plusieurs semaines, voire plusieurs mois. Or, ce modèle Waterfall ne tient pas compte de la variable temps. Une fonctionnalité mise en place, testée puis livrée dans le système, arrivera à destination plusieurs semaines ou mois après qu’elle ait été définie et pensée, pour répondre à un besoin au moment où l’analyse a été faite. Cependant, la réalité du client peut changer rapidement. Ce modèle d’implémentation ne tient pas compte des besoins changeants du client, de sa réalité d’affaire qui est en mouvement au fil du temps, et des technologies émergentes. Le résultat est que la fonctionnalité est bien livrée selon les spécifications initialement documentées, mais ne correspond plus nécessairement aux besoins réels du client.

Continuer la lecture de « Projet vs Produit »