Étiquette : système

Le mot système fait référence ici à tout ce qui à un rapport avec un système d’exploitation et un ordinateur.

Publié le

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 »
Publié le

Docker Compose plugin

Docker Compose plugin

Docker est un utilitaire pour packager et exécuter des conteneurs. Il aide à créer des conteneurs standard qui incluent tous les composants nécessaires pour qu’ils fonctionnent de manière isolée, y compris le code, les dépendances et les bibliothèques. Docker est techniquement plus un outil de gestion de conteneur qu’un format de conteneur.

Les développeurs interagissent généralement avec Docker via une interface de ligne de commande (CLI) pour communiquer avec le client Docker afin d’exécuter des commandes. Celles-ci sont traduites en commandes d’API vers le démon Docker dockerd, qui dirige le système pour créer l’environnement. Un registre Docker stocke des images Docker, qui sont des modèles exécutables. Ainsi, les conteneurs Docker sont essentiellement des instances de ces images.

Docker a été initialement développé en 2013 et a initié le mouvement moderne des conteneurs. Le format d’image Docker a été proposé en tant que standard ouvert et est maintenant appelé Open Container Initiative (OCI). Lorsque les gens discutent des conteneurs Docker, ils se réfèrent généralement à Docker, l’outil de conditionnement de conteneurs. Cela ne doit pas être confondu avec Docker Inc., la société.

Depuis quelques années Kubernetes est devenu la préférence pour de nombreuses grandes entreprises pour la gestion des conteneurs. Souvent abrégé en K8s, il a d’abord été développé en tant qu’outil interne appelé Borg chez Google et est devenu open source en 2014. Parmi les batailles d’orchestrateurs de conteneurs, Kubernetes est sorti victorieux en tant que plate-forme leader, battant Apache Mesos, Docker Swarm et Nomad. K8s est un projet de la Cloud Native Computing Foundation (CNCF) depuis 2018.

Continuer la lecture de « Docker Compose plugin »
Publié le

Batfish, outil Open Source d’analyse de configuration réseau

Batfish

L’écosystème NetDevOps propose de nombreux outils pouvant être positionnés aux différentes étapes de la boucle interne de l’Intent-Based Networking. Dans une approche NetDevOps, Batfish permet de contrôler des configurations avant leur déploiement.

Batfish détecte les erreurs et garantit l’exactitude des configurations de réseau prévisionnelles ou actuellement utilisées. Il permet une évolution sûre et rapide du réseau, sans crainte de pannes ou de failles de sécurité.

Batfish a été initialement développé par des chercheurs de Microsoft Research, UCLA et USC. Beaucoup d’autres y ont contribué depuis. Il est actuellement maintenu par Intentionet, qui propose également Batfish Enterprise, un service qui étend et améliore les capacités de base de Batfish.

Batfish est un service qui tourne sous la forme d’un conteneur Docker. Batfish est conçu pour analyser une série de snapshots d’un réseau. Il faut voir le réseau comme un regroupement logique d’appareils, que ce soit tous les appareils du réseau ou un sous-ensemble. Un snapshot est un état du réseau à un instant donné. Un réseau peut contenir de nombreux snapshots, pour permettre de comprendre son évolution.

Continuer la lecture de « Batfish, outil Open Source d’analyse de configuration réseau »
Publié le

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) »
Publié le

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) »
Publié le

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 »
Publié le

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 »
Publié le

Administrer Kubernetes avec Rancher

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

Kubernetes Rancher Cluster Manager
Rancher Cluster Manager
Kubernetes Rancher Cluster Explorer
Rancher Cluster Explorer
Publié le

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 »