1. Trang chủ
  2. » Luận Văn - Báo Cáo

Construction d’un portail web du catalogue de services et d’applications d’automatisation de l’infrastructure réseau et sécurité = xây dựng cổng thông tin Điện tử về danh mục Ứng dụng và d

108 0 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Construction d’un portail web du catalogue de services et d’applications d’automatisation de l’infrastructure réseau et sécurité
Tác giả Dassoape Noulagnon Segla
Người hướng dẫn Dr. Nguyen Hong Quang, M. Laurent Pison
Trường học Université Nationale Du Vietnam, Hanoï
Chuyên ngành Informatique
Thể loại Mémoire
Năm xuất bản 2021
Thành phố Hanoï
Định dạng
Số trang 108
Dung lượng 3,1 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Cấu trúc

  • 1.1 Introduction (17)
  • 1.2 Institut francophone International (IFI) (17)
    • 1.2.1 Présentation (17)
    • 1.2.2 Organigramme de l’IFI (17)
    • 1.2.3 Les offres de formation (18)
  • 1.3 Carrefour (18)
    • 1.3.1 Présentation (18)
    • 1.3.2 Carrefour en chiffres (18)
    • 1.3.3 Le Service d’affectation et son organigramme (19)
      • 1.3.3.1 Direction Plateforme Services et Opérations (DPSO) (19)
      • 1.3.3.2 Direction des Services Réseaux (DSR) (19)
      • 1.3.3.3 Conception & Ingénierie (C&I) (20)
  • 1.4 Contexte et problématique du projet de stage (20)
  • 1.5 Objectifs du stage (21)
  • 1.6 Conclusion (23)
  • 2.1 Introduction (24)
  • 2.2 Automatisation réseau (24)
  • 2.3 DevOps (25)
  • 2.4 Les outils étudiés (25)
    • 2.4.1 Quelques outils fréquemment utilisés en automatisation (25)
      • 2.4.1.1 Ansible (26)
      • 2.4.1.2 Nornir (26)
      • 2.4.1.3 Nautobot (27)
      • 2.4.1.4 Paramiko (28)
      • 2.4.1.5 Netmiko (28)
      • 2.4.1.6 Napalm (28)
      • 2.4.1.7 Puppet (28)
      • 2.4.1.8 Chef (28)
      • 2.4.1.9 Résumé comparatif des outils d’automatisation (28)
    • 2.4.2 Quelques outils de développement d’API RESTFULL (30)
      • 2.4.2.1 Flask-Restx (30)
      • 2.4.2.2 FastAPI (31)
      • 2.4.2.3 Falcon (31)
      • 2.4.2.4 Résumé comparatif de frameworks API (31)
      • 2.4.2.5 Gunicorn (31)
      • 2.4.2.6 Uvicorn (32)
    • 2.4.3 Quelques outils de conception de moteur de job asynchrones (32)
      • 2.4.3.1 Fonctionnement d’un moteur de job asynchrones : mode point-to-point (32)
      • 2.4.3.2 Redis (33)
      • 2.4.3.3 Redis Sentinel (34)
      • 2.4.3.4 RQ (34)
      • 2.4.3.5 Celery (34)
      • 2.4.3.6 APScheduler (Advanced Python Scheduler) (34)
    • 2.4.4 Quelques outils DevOps (35)
      • 2.4.4.1 Docker (35)
      • 2.4.4.2 Kubernates (36)
      • 2.4.4.3 Helm (37)
      • 2.4.4.4 Jenkins (38)
      • 2.4.4.5 Git et Bitbucket (38)
      • 2.4.4.6 Jfrog (38)
      • 2.4.4.7 Vault (38)
    • 2.4.5 Quelques outils de développement de Fronend (38)
      • 2.4.5.1 Vue.js (39)
      • 2.4.5.2 Bulma CSS (39)
  • 2.5 Conclusion (40)
  • 3.1 Introduction (41)
  • 3.2 Script d’exộcution de commandes : le script ôCommand runnerằ (0)
    • 3.2.1 Formalisme d’entrée/sortie du script (42)
    • 3.2.2 Protocole de connexion aux équipements (43)
    • 3.2.3 Mécanisme de rebond (43)
    • 3.2.4 Rebond et environnement d’exécutions (44)
    • 3.2.5 Authentification (44)
    • 3.2.6 Outils utilisés (44)
  • 3.3 Le backend (45)
    • 3.3.1 Architecture générale de l’application (45)
      • 3.3.1.1 Exécution du script grâce à l’API (46)
      • 3.3.1.2 Récupération du résultat grâce à l’API (47)
      • 3.3.1.3 Intérêt de l’architecture basée sur un moteur de jobs (47)
    • 3.3.2 Redis en temps que base du moteur de jobs asynchrones (47)
      • 3.3.2.1 Fonctionnement (48)
      • 3.3.2.2 Les jobs (48)
      • 3.3.2.3 Quel protocole/bibliothèque pour dialoguer avec Redis (48)
    • 3.3.3 API (49)
      • 3.3.3.1 Choix de Technologies (49)
      • 3.3.3.2 Données en entrée et en sortie (49)
      • 3.3.3.3 Quelques points de terminaison de l’API (49)
      • 3.3.3.4 Fonctionnement de l’API (50)
      • 3.3.3.5 Cas des requêtes avec données (POST) (50)
      • 3.3.3.6 Cas des requêtes (GET) (51)
      • 3.3.3.7 Traitement de la requête validée (51)
      • 3.3.3.8 Architecture sécurisée de l’API (52)
      • 3.3.3.9 Comment servir l’API (52)
      • 3.3.3.10 Quels outils pour développer l’API ? (53)
    • 3.3.4 Le Worker (54)
    • 3.3.5 Base de données (54)
      • 3.3.5.1 Quel système de gestion de base de données ? (54)
      • 3.3.5.2 Accès à la base de données ? (54)
    • 3.3.6 Résumé des bibliothèques de communication (54)
  • 3.4 Intégration au portail : le frontend (55)
  • 3.5 Conclusion (55)
  • 4.1 Introduction (56)
  • 4.2 Le Script Command runner (56)
    • 4.2.1 Fonctionnement de la classe Commande_runner (57)
    • 4.2.2 Arguments (58)
    • 4.2.3 Lancement et résultat (59)
  • 4.3 l’API (59)
    • 4.3.1 Résultat : Interface swagger (59)
    • 4.3.2 Organisation du code (60)
    • 4.3.3 Les points de terminaison (61)
      • 4.3.3.1 Le namespace "job" (61)
      • 4.3.3.2 Le namespace jobs (63)
  • 4.4 Le Worker (63)
    • 4.4.1 La classe CustomWorker (64)
      • 4.4.1.1 Avant lancement du job (64)
      • 4.4.1.2 Après le lancement du job (64)
  • 4.5 Le portail : La page ôCommand Runnerằ (64)
    • 4.5.1 Fonctionnement détaillé (65)
      • 4.5.1.1 Les données de application (65)
      • 4.5.1.2 Localisation des données (66)
      • 4.5.1.3 La View principale : frontend/front/src/views/Comman- (66)
      • 4.5.1.4 Les composants : front/src/components/commandrunner/ (67)
  • 4.6 Le Déploiement (71)
    • 4.6.1 Déploiement en local (71)
      • 4.6.1.1 Qu’est-ce qui est déployé (71)
      • 4.6.1.2 Étapes de déploiement (72)
    • 4.6.2 Déploiement dans le cloud (72)
      • 4.6.2.1 Qu’est-ce qui est déployé (72)
      • 4.6.2.2 Étape du pipeline CI/CD Jenkins (72)
  • 4.7 Évaluations des résultats (73)
  • 4.8 Conclusion (74)
  • A.1 Déploiement de la stack en local (80)
    • A.1.1 Makefile (80)
    • A.1.2 docker-compose.yaml (84)
    • A.1.3 docker-compose.override.yaml (86)
    • A.1.4 docker.ini (88)
    • A.1.5 docker.private.ini (89)
    • A.1.6 L’API Command runner (90)
      • A.1.6.1 Dockerfile (90)
      • A.1.6.2 docker-entrypoint.sh (91)
      • A.1.6.3 whoami.json (92)
      • A.1.6.4 gen_secretfile.sh (94)
  • A.2 Déploiement de la stack dans cloud (k8s) (96)
    • A.2.1 jenkinsfile (96)
    • A.2.2 Chart Helm (103)
      • A.2.2.1 value.ymal (103)
      • A.2.2.2 ingress_api.ymal (104)
      • A.2.2.3 service_api.ymal (104)
      • A.2.2.4 deployment_api.ymal (105)
    • A.2.3 gen_env.sh (106)
      • 1.1 Organigramme IFI (0)
      • 1.2 Exécution des scripts sur serveur de rebond (0)
      • 2.1 Comparatif Outils d’automatisation (0)
      • 2.2 Comparatif Combinaison d’Outils d’automatisation (0)
      • 2.3 Architecture de moteur de job asynchrones (0)
      • 2.4 Architecture de Docker [33] (0)
      • 2.5 Fonctionemennt de Helm [27] (0)
      • 3.1 Connexion à travers un serveur de rebond (0)
      • 3.2 Workflow d’exécution du script Command runner via l’API (0)
      • 3.3 Workflow de récupération de résultat via l’API (0)
      • 3.4 Ajout et retrait de jobs (0)
      • 3.5 API validation de données (0)
      • 3.6 Authentification déléguée au SSO (0)
      • 3.7 API servi par Gunicorn (0)
      • 3.8 Schéma de la base de données (0)
      • 3.9 Librairies pour la communication entre micro-services (0)
      • 4.1 Structure du code du script (0)
      • 4.2 Lancement et résultat du script dans le terminal (0)
      • 4.3 Interface swagger de l’API (0)
      • 4.4 Structure du code de l’API (0)
      • 4.5 Imbrication blueprint et namespaces (0)
      • 4.6 Exemple de données du corps d’une requête POST (0)
      • 4.7 Exemple de Réponse (0)
      • 4.8 Structure du code du Worker (0)
      • 4.9 Page du service command runner (0)
      • 4.10 View principale (0)
      • 4.11 Imbrication des composants à la création job (0)
      • 4.12 Imbrication des composants à l’affichage de résultat (0)
      • 2.1 Comparatif Framework API (0)
      • 3.1 Définition de points de terminaison (0)
      • 4.1 Apports intégration moteur de jobs asynchrones (0)
      • 4.2 Apports migration vers le portail web (0)

Nội dung

Construction d’un portail WEB du catalogue de services et d’applications d’automatisation de l’infrastructure réseau et sécurité = Xây dựng cổng thông tin điện tử về danh mục ứng dụng

Introduction

This internship is part of a Master's degree program in computer science This chapter will provide an overview of the International Francophone Institute (IFI) as an educational institution, as well as Carrefour as the host company for the internship.

Institut francophone International (IFI)

Présentation

The International Francophone Institute (IFI) has been a member of the National University of Vietnam in Hanoi (UNVH) since 2014, focusing exclusively on research and training in new information and communication technologies Established in 1993, IFI plays a crucial role in advancing technological education and innovation.

The "Institut de la Francophonie pour l’Informatique" (IFI) was previously under the supervision of the Agence Universitaire de la Francophonie (AUF) until 2014, when it became part of the National University of Vietnam This transition also marked a change in its name The IFI is located within the National University of Vietnam in Hanoi.

144 Xuan Thuy , Cau Giay, Hanoi.

Organigramme de l’IFI

2 A la date de la rédaction de ce rapport, la direction de l’IFI est occupée par

Dr Ngo Tu Lap La direction est au contrôle des activités de plusieurs entités dont le

1 http://www.ifi.edu.vn/fr/

2 http://www.ifi.edu.vn/fr/about/Organigramme.html conseil scientifique, le département des services La figure1.1montre l’organigramme résumant les connexions entre les entités composantes de l’IFI.

Les offres de formation

The IFI provides Master's level training in four key areas: Computer Science, featuring two specializations in Intelligent Systems and Multimedia (SIM) and Communication Systems and Networks (RSC); Banking, Finance, and Fintech; as well as Information Management.

- communication, spộcialitộ ô Communication Digitale et Editoriale ằ.

Carrefour

Présentation

Carrefour 3 est un groupe franỗais dont les activitộs se situent principalement dans la grande distribution Le siège social du groupe est au 93, Avenue de Paris Massy, 91400France Le groupe est né en 1959 de la volonté de Marcel Fournier, Denis Defforey etJacques Defforey à apporter un renouveau dans l’univers de la grande distribution enFrance Le groupe est actuellement dirigé par Alexemdre Bompard.

Carrefour en chiffres

Commerỗant de rộfộrence alimentaire, Carrefour emploie aujourd’hui plus de 321

383 collaborateurs dans le monde sur plus de 300 métiers différents.

Premiốre chaợne de distribution en Europe et huitiốme dans le monde, Carrefour compte 16 116 magasins sous son enseigne dans plus de 30 pays dont 5469 en France,

6106 en Europe (hors France), 2648 en Amérique latine, 1032 en Asie et 1422 dans d’autres pays.

En 2020, Carrefour réalise un chiffre d’affaire de 78,8 milliards€.

Le Service d’affectation et son organigramme

The internship took place at the Carrefour France headquarters in Massy, within the Design & Engineering teams of the Network Services Department (DSR), which is a subdivision of the Platform Services and Operations Directorate under the Information Systems Department (DSI) The DSI, led by Frederic EICH, comprises various subdivisions.

• Direction Sécurité de l’information France et Groupe

• Direction Plateforme Services et Opérations (DPSO)

1.3.3.1 Direction Plateforme Services et Opérations (DPSO)

The DPSO (Direction Plateforme Services et Opérations) is responsible for managing all hosting infrastructures for Carrefour France's applications, including network infrastructures across the country such as data centers, headquarters, stores, and warehouses Additionally, it oversees international interconnections for various Carrefour group countries, providing users with essential equipment and services that form Carrefour's Digital Workplace, along with support.

1.3.3.2 Direction des Services Réseaux (DSR)

La DSR (Direction des Services Réseaux) est organisée en cinq (5) départements :

• Travaux réseaux et usines de productions : Ce département gère la relation avec les clients internes, les plans budgets et maợtrise des KPI des diffộrents projets

• Conception et ingénierie : réalisation des études techniques, des architectures détaillées, de l’intégration d’équipements et support de niveau 3

• Opérations : activités d’exploitation et de maintien en condition opérationnelles

• Gestion de projet : ce département s’occupe de la gestion de tous les projets d’envergure de la DSR et du suivi des commandes

• Cadrage demandes et évolutions : études de cas et gestion des Appels d’Offres

Le département C&I (Conception et Ingénierie) est organisée en quatre (4) domaines :

• Wan Optimisation et Mesures (WOM) : Ce périmètre couvre la gestion des infra- structures réseaux, la qualité de services et son pilotage.

• LAN/Wifi : a en charge les architectures LAN et Wifi des sièges et magasins.

• Data Center et Sécurité : couvre la gestion des Data Center interconnectés au réseaux de Carrefour et des infrastructures de sécurité réseau.

• Automatisation et Orchestration: ce domaine accompagne les équipes de laDSR pour l’optimisation des services réseaux et sécurité

Contexte et problématique du projet de stage

The automation and orchestration team is relatively new and focuses on developing scripts and software essential for other teams in their respective projects Several projects have already been completed, resulting in scripts (Python and Ansible) that operate within a console environment Figure 1.2 illustrates the environment where these scripts are executed.

FIGURE1.2 – Exécution des scripts sur serveur de rebond

The proxy, referred to as a bounce server throughout this report, serves a critical security function by acting as the sole access point to the secure network.

For simplicity, most scripts are currently executed directly on the bounce server, which somewhat diverts it from its primary function as a connection relay.

Due to the unsatisfactory situation, a decision has been made to create a web platform that will host all scripts Those scripts that require network access will do so through a relay server.

La plate-forme web s’inscrit dans une stratégie sur le long terme et apporte une solution aux problématiques dont :

• L’abandon de l’utilisation des machines de rebond comme environnement d’exécution des scripts Les machines de rebond reprendraient donc leur rôle.

• La migration des applications y compris les scripts dans le cloud.

Common mistakes in configuring the launch environment for scripts can hinder their functionality Since these scripts are primarily developed in Python, they necessitate specific configurations to operate effectively Setting up these configurations can be challenging for teams utilizing the scripts.

• L’utilisation des scripts en mode ligne de commande n’est pas ôuser-frendlyằ. Les principales difficultés pour ce travail sont :

• La compréhension de l’architecture du système d’information de Carrefour ;

• La compréhension des scripts déjà développés au sein l’équipe automatisation ;

• La maợtrise du dộploiement d’application multi-environnent (local,pré-production, production) en pratique au sein de l’équipe.

Objectifs du stage

The internship aims to achieve multiple objectives that collectively contribute to the development of the "Command Runner" service This initiative enhances the product and service catalog offered by the automation team on its web services platform.

C’est la toute première étape du projet Le script doit pouvoir :

• Accepter des données comme : les commandes, des addresses IP.

• Dans un premier temps, faire tourner le script sur un serveur de rebond

• Dans un second temps faire, tourner le script depuis une machine externe et accéder au équipements cibles dans le réseau sécurisé à travers le serveur

• Mettre à disposition les résultats sous forme de fichier text et JSON.

Il s’agira d’un API RESTFULL qui doit permettre d’exploiter le script en tâche de fond Grâce à cette API, avec des requêtes HTTP, le script va pouvoir être lancé.

(ii) Intégration d’un moteur de tâches asynchrones:

Ce moteur est essentiel pour assurer un fonctionnement correct du script.

The execution time of the script can be potentially lengthy, so the role of the asynchronous task engine is to eliminate the blocking nature of executions for an HTTP user session (API request).

3 Portage sur la plateforme web:

Le Frontend est la partie avec laquelle interagiront le plus les utilisateurs Il doit

• Accepter des fichiers en données d’entrée.

• Offrir la possibilité d’exporter les résultats des commandes sous forme de fichier.

As previously mentioned, one of the project's objectives is to eliminate the reliance on executing scripts directly on the bounce machines In alignment with the team's Agile/DevOps development process, all deliverables from the internship, including the script and frontend, must be deployable.

• En local, dans des conteneurs qui tournent sur une machine virtuel (GCP).

Ce déploiement sert essentiellement pour le développement et les tests.

• Dans le cloud, sur le cluster k8s mutualisé de Carrefour Dans le cloud qui doit se faire grâce à un pipeline CI/CD Jenkins (Jekins de Carrefour).

Toutes les étapes du projet doivent être documentes dans deux types de documents :

• Recette d’utilisation : Il s’agit d’un document qui explique aux utilisateurs comment utiliser les produits (scripts).

• Documentation technique : Elles expliquent l’architecture détaillée du code des produits Ces documents sont à destination des développeurs.

Conclusion

In this chapter, we provided an overview of Carrefour and the International Francophone Institute, which serve as the internship host and training organization, respectively We also outlined the key issues that led to the development of the internship project.

Introduction

This chapter will introduce key terms and tools that were explored during the research for the internship objectives These concepts will be briefly discussed, with a focus on connecting them to either the internship environment or the specific project undertaken during the internship.

Automatisation réseau

Network automation involves delegating configuration, monitoring, and management tasks to machines, relieving administrators from lengthy and complex manual processes This technology is increasingly becoming a staple in the networking field, as it effectively addresses the daily challenges faced by network professionals Some of these challenges are not new but continue to persist.

• Les erreurs : Les opérateurs humains sont plus sujets aux erreurs que les machines.

• Le temps: Les machines sont beaucoup plus rapides que les opérateurs humains sur les tâches répétitives On gagne ainsi en temps de résolution des incidents.

• Le cỏt : Une tâche automatisée est généralement beaucoup moins onéreuse pour les entreprises.

These challenges align closely with several reasons discussed in the previous chapter that led to the internship project Connecting to hundreds of network devices to execute a series of commands and subsequently classify the results is a repetitive, tedious task that inevitably takes a long time for a human operator to complete.

The automation of networks addresses contemporary challenges arising from new paradigms and technologies, such as cloud computing and software-defined networking (SDN) These innovations inherently incorporate the concept of network programmability, which serves as their foundational principle.

DevOps

DevOps, a blend of "developers" and "operators," embodies a collaborative culture that aims to automate processes between development teams and operational services This approach enhances the development, testing, and delivery of software, fostering efficiency and innovation in the software lifecycle.

Traditionnellement, les développeurs sont censés créer de la valeur et rendre le produit/service et les opérationnels ont pour objectif de maintenir la stabilité des infrastructures.

The advantages of DevOps culture are significant, enabling faster and higher-quality production deployments DevOps teams deliver more frequently while maintaining the quality and stability of infrastructures A successful DevOps strategy hinges on strong collaboration between operators and developers, fostering improved communication and enhanced team performance.

Les outils étudiés

Quelques outils fréquemment utilisés en automatisation

Automation heavily relies on scripting languages such as Python, Ruby, Perl, and Bash, which can be utilized individually or in combination with other tools Many of these tools serve as frameworks, providing a structured environment for developing automation applications Essential features must be present in any automation tool aiming to function as a framework.

• Gestion des inventaires : La fonction d’identification des machines/applications cibles La gestion des inventaires inclut souvent le filtrage et la gestion des regroupements logiques des machines cibles.

• Gestion du parallélisme des tâches : Cette caractéristique permet de faire faire des tâches en exploitant les capacités multi-processeur des ordinateurs modernes.

Ansible is one of the most popular open-source automation tools available Its versatility allows it to be used in various scenarios beyond just network automation Primarily developed in Python, Ansible can be seen as an automation framework with key features that enhance its functionality.

• Système d’inventaire : Un système d’inventaire basique basé sur des fichiers YAML, mais qui peut-être étendu grâce à des modules.

• Multitâche: Ansible gère les tâches multiples en parallèle.

• Agentless: Cela veut dire qu’à partir de la simple activation de SSH par exemple, Ansible peut-être fonctionnel.

• Pseudo-langage (DSL-Domain Specific Language): Le pseudo-langage d’Ansible est lui-même en YAML.

• Système de Playbook: Les playbooks permettent de décrire l’état souhaitée.

• Idempotence: Ansible n’effectue des changements que lorsque l’état décrit dans les playbooks est diffèrent de l’état opérationnel des machines/applications cibles.

• Modularité : Les opérations faites avec Ansible sont effectuées grâce à des modules (développés en Python, Bash, Perl )

• Soutient: La solution Ansible est soutenu par une forte communauté, mais aussi par des offres commerciales.

Similar to Ansible, Nornir is a versatile tool that provides users with a framework for automation project development Its functionality largely relies on modules, making it a powerful option for automating tasks.

An inventory system serves as a fundamental framework, initially built on files, with the potential for expansion through various modules Available inventory modules include options for Netbox, IP Fabric, and even integration with Ansible inventories, enhancing the system's functionality and adaptability.

• Multitâche: Il gère le parallélisme des tâches.

• Pseudo-langage : Contrairement à Ansible Nornir n’a pas un pseudo-langage. Une application développée avec Nornir doit être en Python.

• Idempotence: Une opération faite avec Nornir n’est pas idempotente.

• Rapidité: En générale l’exécution des mêmes tâches avec Nornir (sous réserve d’une bonne implementation) est souvent plus rapide qu’avec Ansible.

• Modularité : Presque toutes les fonctionnalités de Nornir sont basées sur des module dont une liste est disponible ici [7]

• Soutient: Nornir est un outil libre avec une communauté de soutien.

Nautobot is an open-source automation platform and a reliable source of truth for data regarding network status Launched in 2021 by Network To Code, Nautobot serves as more than just a development framework, with three primary use cases currently established.

Nautobot serves as a flexible source of truth for network infrastructure, featuring foundational data models that capture the state of various components These models encompass a wide range of elements, including IP addresses, devices, racks, circuits, and cables Additionally, users have the capability to create new models and define relationships between them, ensuring maximum flexibility in managing network data.

Nautobot is an extensible data platform designed for automation, featuring a comprehensive set of tools that seamlessly integrate with network automation solutions It offers GraphQL and Git integration, along with REST APIs and webhooks Additionally, Nautobot includes a scalable plugin system that enables users to create custom APIs and user interface elements This plugin system also unifies and aggregates disparate data sources, establishing a single source of truth to streamline data management for network automation.

Nautobot is a powerful platform for network automation applications, enabling users to develop custom apps tailored to their specific needs, whether lightweight or robust By leveraging Nautobot's built-in features such as authentication, permissions, webhooks, GraphQL, and change logging, users can save up to 70% in development time Additionally, Nautobot provides seamless access to pre-existing data, streamlining the application development process.

NB: Le moteur de lancement des applications par Nautobot est basé sur Celery (cf.2.4.3).

L’utilisation de Nautobot pour notre projet peut-être envisagée dans la mesure ou il permet d’intégrer assez facilement les scripts Python.

Paramiko is a Python implementation of the SSH protocol that allows for programmatic management of all SSH aspects It is widely integrated into solutions utilizing SSH, such as Ansible modules and Nornir modules.

[11] Netmiko est une bibliothèque Python qui a pour but de faciliter l’utilisation Paramiko en y rajoutant une interface commune pour gérer toutes sortes d’équipements comme IOS, Junos

NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) is a Python library that offers an abstraction layer for connecting to network devices by providing common APIs.

A titre d’exemple, l’utilisation de la fonction/APIget_bgp_neighborsutilisera Netmiko sur les équipements IOS, Junos-eznc pour les équipements Juniper tournant Junos

Napalm aims to transcend the limitations of vendor-specific devices and operating systems, particularly focusing on Cisco's NX-OS A comprehensive list of supported APIs can be found here [13].

Puppet is a configuration management tool similar to Ansible, designed for automation tasks It operates on a Master-Agent architecture, which makes it unsuitable for our project since we cannot install agents on the devices from which we need information Although Puppet can be used in an agentless mode, particularly for network devices, the list of supported platforms is quite limited.

[39] Chef est plus proche de Puppet que d’Ansible Chef est une technologie de gestion de configuration utilisée pour automatiser le provisionnement des infrastructures.

2.4.1.9 Résumé comparatif des outils d’automatisation

In the following tables, we will outline the advantages and disadvantages of various tools, specifically Nornir, Ansible, Netmiko, and Napalm, as well as certain combinations of these tools This comparison focuses on the tools' data retrieval capabilities in relation to our project objectives We have excluded Chef and Puppet from consideration as they are not utilized by our team, and Paramiko has been deemed too basic for complex tasks.

FIGURE2.2 – Comparatif Combinaison d’Outils d’automatisation

In the following chapter, we will determine which tools to select based on various criteria However, when comparing options of equal value, we will consistently choose the tools that are commonly used within the Automation team.

Quelques outils de développement d’API RESTFULL

Un des objectifs du projet est la conception d’un API RESTFULL.

Flask is arguably the most popular open-source framework for web application development in Python Flask-Restx is an extension of Flask that enhances and formalizes API development, providing a concise method for data validation and endpoint definition In addition to simplifying API development, Flask-Restx offers easy ways to document and expose APIs, supporting OpenAPI and enabling automatic generation of Swagger interfaces This framework aligns perfectly with our objectives.

1 https://en.wikipedia.org/wiki/Swagger_(software)

FastAPI is a Python framework similar to Flask-Restx, designed for developing RESTful APIs While it performs nearly the same functions as Flask-Restx, it is noted for its superior speed.

Unlike FastAPI and Flask-Restx, Falcon lacks features such as data validation, OpenAPI support, and Swagger interface generation However, Falcon focuses on the essentials for building an API with Python, uniquely integrating an application server that supports both WSGI and ASGI protocols.

2.4.2.4 Résumé comparatif de frameworks API

Support OpenAPI Oui Oui Oui

Génération interface Swagger Oui Oui Oui

Validation de données Non (faisable) Oui (simple Pydantic) Oui

Serveur d’application Non ASGI ASGI et WSGI

Rapidité Moins Plus(support Async) (support Async)

Message d’erreur Oui(basique) Oui(avancé) Oui(Basique)

NB: Eu égard de cette comparaison, nous déciderons de quels outils choisir dans le chapitre suivant.

Pour comprendre Gunicorn il faut d’abord se pencher sur le modèle Pre-fork et aussi la spécification WSGI[18].

Python is inherently single-threaded, making it less than ideal for deploying web applications that handle a high volume of requests The pre-fork mechanism addresses this limitation by allowing multiple instances (workers) of the Python interpreter to be launched in advance A master process creates several workers before any requests arrive, ensuring that the master does not handle requests directly This approach eliminates the delay associated with starting and initializing Python interpreters.

WSGI, or Web Server Gateway Interface, addresses the long-standing issue of single-threaded applications by providing a standardized interface between web applications and web servers Over the years, various specifications such as CGI, FastCGI, SCGI, and ASGI have been developed and implemented as middleware to tackle this challenge Additionally, specific modules like mod_python for the Apache server have been created WSGI serves as a convention that defines how Python web frameworks and scripts interact with web servers, ensuring a more efficient and consistent application deployment.

Gunicorn is a web application server that implements the WSGI specification and follows the pre-fork model Its primary function is to pre-fork one or more Python interpreters before incoming requests are received Additionally, Gunicorn manages the translation of Python function calls and the passing of arguments, such as form data, between the web server and Python web applications or frameworks.

Uvicorn is a web application server similar to Gunicorn, but it implements the ASGI specification, which is the successor to WSGI and maintains backward compatibility with it.

Quelques outils de conception de moteur de job asynchrones

There is a wide range of systems for launching asynchronous tasks, often implemented as one or more middleware solutions We have explored some of the most popular options, including APScheduler, Celery, and RQ+Redis.

Même si ces systèmes ont plusieurs modes de fonctionnement, nous allons nous focaliser sur le mode "point-to-point" [21] qui répond à nos besoins.

2.4.3.1 Fonctionnement d’un moteur de job asynchrones : mode point-to-point

In general, job engines can be categorized into producer applications and consumer applications In some instances, a single application may fulfill both roles.

FIGURE2.3 – Architecture de moteur de job asynchrones

In a point-to-point messaging system, the job store typically utilizes a queue data structure to manage jobs as messages sent by producer applications Producers send messages to the queue, while consumers retrieve these messages and send acknowledgments Multiple producer applications can send messages to the same queue, and multiple consumers can fetch messages from it When several consumers are active, each one retrieves only one segment of the message flow, rendering those messages inaccessible to others, which is the essence of the term "point-to-point."

Le fait d’utiliser une structure en file pour stocker les jobs n’est pas une obligation, d’ailleurs certains systèmes utilisent d’autres structures de données.

Juste pour information, un autre mode de fonctionnement est le

"publisher-suscriber" qui permet à plusieurs applications consommatrices de recevoir et de traiter les mêmes messages.

Redis is an in-memory database that stores data structures such as lists and strings It is commonly used as a caching database for applications One of the most recognized use cases for Redis is its role as a job storage solution.

As previously mentioned, Redis alone does not serve as an asynchronous job engine; it merely acts as a storage point for messages sent and received by applications To effectively utilize Redis for asynchronous job processing, it must be combined with libraries that implement communication protocols.

Redis Sentinel is a monitoring solution for Redis instances that manages automatic failover of Redis masters and service discovery to identify the current master within a group of instances Since Sentinel is responsible for reconfiguring instances during failovers and providing configurations to clients connecting to masters or Redis replicas, it is essential for clients to have explicit support for Redis Sentinel.

[43] RQ signifie ôRedis Queueằ Il s’agit d’une librairie Python qui implộmente le mode communication point-to-point (voir plus haut) RQ est conỗu pour ne communiquer qu’avec Redis.

Avec RQ, les applications consommatrices sont appelées des "workers".

The operation of RQ is straightforward A producer wanting to execute a task by a worker submits the task name (a Python function name) along with the parameters to a Redis server database A worker then retrieves the task name and parameters, identifies the corresponding code, and executes the task.

Each task is assigned a unique identification number RQ operates with multiple registers that help track tasks that have started, as well as those that have failed.

Celery is a robust library that offers more features compared to RQ In addition to supporting point-to-point messaging, it also accommodates other protocols such as MQTT, which utilizes the "publisher-subscriber" model.

Celery is primarily designed for Python, but its protocol can be implemented in various programming languages In addition to Python, there are implementations available for Node.js, such as node-celery and node-celery-ts, as well as a client for PHP.

L’interopérabilité des langages peut également être obtenue en exposant un point de terminaison HTTP et en ayant une tâche qui le demande (webhooks).

APScheduler, similar to RQ, allows for the scheduling and execution of jobs at specified times Unlike RQ, which is limited to Redis, APScheduler offers the flexibility to store jobs in various systems, including relational database management systems, Redis servers, and in-memory storage.

Quelques outils DevOps

L’univers DevOps est rempli d’outils très variés Dans cette section nous allons ex- pliquer le fonctionnement de certains de ces outils DevOps dont nous nous servirons.

Docker is a software-platform suite that employs operating system-level virtualization to develop and deliver applications in packages known as containers The software that hosts these containers is referred to as Docker Engine Designed to streamline the creation, deployment, and execution of applications, Docker simplifies the containerization process for developers.

1 Les composants de docker : Le logiciel Docker en tant qu’offre de service comprend trois composants :

The Docker daemon, known as dockerd, is a persistent process that manages Docker containers and their associated objects It listens for requests sent through the Docker Engine API The Docker client, referred to simply as docker, offers a command-line interface that allows users to interact with the Docker daemons effectively.

• Objets: les objets Docker (Docker objects)sont diverses entités utilisées pour assembler une application dans Docker Les principales classes d’objets Docker sont les images, les conteneurs et les services.

— Un conteneur Docker(CONTAINERS) est un environnement normalisé et encapsulé qui exécute des applications Un conteneur est géré à l’aide de l’API Docker ou de la CLI.

— Une image Docker (IMAGES) est un modèle en lecture seule utilisé pour créer des conteneurs Les images sont utilisées pour stocker et expédier des applications.

— Un service Docker (SERVICES) permet de redimensionner les conteneurs sur plusieurs démons Docker Le résultat est appelé un essaim , un ensemble de démons coopérants qui communiquent via l’API Docker.

• Registres : Un registre Docker(Docker registry) est un référentiel des images Docker Les clients Docker se connectent aux registres pour télécharger ("extraire") des images à utiliser ou pour télécharger ("push")

The two main public registries are Docker Hub and Docker Cloud Docker Hub serves as the default registry where Docker searches for images Additionally, Docker registries enable the creation of event-based notifications.

L’architecture de docker présenté à la figure 2.5 présente les différents composants de docker ainsi que la communication entre ces éléments

2 Docker Compose : [34] Docker Compose est un outil permettant de définir et d’exécuter des applications Docker à conteneurs multiples Il utilise des fichiers YAML pour configurer les services de l’application et effectue le processus de création et de démarrage de tous les conteneurs à l’aide d’une seule commande. L’ utilitaire docker-compose CLI permet aux utilisateurs d’exécuter des commandes sur plusieurs conteneurs à la fois, par exemple, la création d’images, la mise à l’échelle de conteneurs, l’exécution de conteneurs arrêtés, etc Les commandes liées à la manipulation d’images, ou les options interactives pour l’utilisateur, ne sont pas pertinentes dans docker compose car elles s’adressent à un conteneur Le fichier docker-compose.yml est utilisé pour définir les services d’une application et inclut diverses options de configuration. Par exemple, l’option build définit des options de configuration telles que le chemin d’accès du fichier Docker, l’ option command permet de remplacer les commandes Docker par défaut, etc.

Toutes les applications de l’équipe automatisation sont déployées dans le cloud grâce une instance Kubernetes sur Google Cloud Platform infogérée.

[45] Kubernetes est un outil d’orchestration de conteneurs open source permettant d’automatiser le déploiement, la mise à l’échelle et la gestion des applications conteneurisées.

Helm is a package manager for Kubernetes that streamlines application deployment through a templating system and dependency management, reducing duplication and maintaining a coherent configuration structure Beyond this, Helm offers features for managing your Charts, allowing for compression and storage in remote directories such as CDN, Git, or local/shared disks Additionally, it includes a system that simplifies updates and rollbacks for your applications.

Quelques concepts sont importants de Helm:

• Un package Kubernetes est appelé Charts dans Helm.

• Un Chart contient un lot d’informations nécessaires pour créer une instance d’application Kubernetes.

• La Config contient les informations dynamiques concernant la configuration d’un Chart

• Une Release est une instance existante sur le cluster, combinée avec une Config spécifique.

During the initialization of Helm, the client installs Tiller on a pod within the cluster Tiller acts as the server that facilitates communication between the Helm client and the Kubernetes API for management purposes.

Jenkins is an open-source continuous integration and continuous deployment (CI/CD) tool developed in Java under the MIT license It utilizes Groovy, a Java-based scripting language, to define deployment actions Whenever there is a code change in an application within the configuration manager, Jenkins can automatically recompile and test the code Additionally, Jenkins comes with several built-in features that can be enhanced through plugins.

Carrefour met à disposition de l’équipe automatisation un déploiement Jenkins sur lequel nous allons construire notre pipeline CI/CD.

Git is the most popular open-source distributed version control protocol in the DevOps realm One of its key features is enabling developers to manage code versions both in local directories and in remote repositories.

Bitbucket est un serveur qui héberge des répertoires distants Git Les codes des applications de l’équipe sont hébergés sur un serveur Bitbucket.

L’un des composants qui a fait le succès de Docker en tant que service c’est la capacitộ à stocker les images sur des serveurs appelộs ôregistriesằ1.

JFrog is best described as an artifact manager, although it offers more than just a Docker registry In this context, we will focus solely on its container image hosting capabilities Carrefour provides the automation team with space on its JFrog platform to host these images.

Vault is an open-source tool developed by HashiCorp designed to secure, store, and tightly control access to tokens, passwords, certificates, and encryption keys It protects sensitive data and secrets through a user interface, command-line interface (CLI), or HTTP API.

Quelques outils de développement de Fronend

Regarding the development of the portal for our application, no new choices will be made since the portal is already built Our mission is to enhance it by integrating the components related to our application In this section, we will briefly discuss the tools used to construct this portal.

[28][29] Vue.js est un framework Frontend Javascript pour créer des interfaces uti- lisateur Vue.js est probablement le plus facile de frameworks Javascript pour frontend web à prendre en main.

Firstly, it is important to understand that VueJS can be integrated incrementally This means that an existing application does not need to be completely rebuilt; instead, a new feature can be quickly added using Vue.js.

Les caractéristiques de Vue.js:

Modularity in Vue.js components allows for a logical segmentation of the application into modules, enhancing code organization and facilitating code reuse.

Vue.js utilizes an HTML-based template syntax that connects the rendered DOM to the underlying Vue.js instance data All Vue.js templates consist of valid HTML code, which can be parsed by browsers and HTML parsers that comply with specifications.

Vue.js features a reactivity system that leverages simple JavaScript objects for optimized rendering Each component tracks its reactive dependencies during rendering, allowing the system to know exactly when to trigger a re-render and which components need to be updated.

• Transitions :Vue.js fournit une variộtộ de faỗons d’appliquer des effets de transition lorsque des éléments sont insérés, mis à jour ou supprimés du DOM. Cela inclut des outils pour :

— Appliquer automatiquement des classes pour les transitions CSS et les ani- mations

— Intégrer des bibliothèques d’animation CSS tierces, telles que Animate.css

— Utilisez JavaScript pour manipuler directement le DOM pendant les hooks de transition

— Intégrer des bibliothèques d’animation JavaScript tierces.

Vue.js est parfaitement compatible a Typescript, vu que le portail est développé en Typtscript et non Jvavascript.

Bulma is an open-source CSS framework that utilizes Flexbox for layout, offering a similar experience to Bootstrap Its extensive built-in features enable faster development times and reduced effort for developers.

Conclusion

All the tools discussed in this chapter have undergone comparative studies to assess their usefulness While some of these tools will not be utilized in our project, they are included here for reference or comparison purposes.

Introduction

The aim of this section is to outline the architectural choices made to achieve the objectives defined at the end of Chapter 1 Each objective will be addressed individually, and a section will provide an overview by organizing all elements of the "command runner" service architecture.

3.2 Script d’exécution de commandes : le script ôCommand runnerằ

The internship project focuses on a script designed for retrieving configurations from Cisco routers (IOS 15.1) that only allow access via SSH.

Les objectifs initiaux ont été étendus pour que le script soit capable de supporter plusieurs types d’équipements (switch, routeurs, firewall ), de plusieurs constructeurs autres que Cisco comme Juniper, Aruba,

Script d’exộcution de commandes : le script ôCommand runnerằ

Formalisme d’entrée/sortie du script

En entrée du script, sous forme d’argument :

• Un fichier CSV contenant la liste des équipements cibles Dans ce fichier chaque ligne décrira un équipement Le fichier devra posséder un en-tête composé de :

— hostname : une adresse IP ou un nom résolvable, celui de l’équipement cible Cette donnée sera obligatoire pour que la ligne soit valide.

— platform: indique la plate-forme cible La valeur par défaut est IOS.

— port: indique le port SSH cible Le port SSH par défaut est 22.

• Un fichier CSV contenant les commandes à exécuter sur les équipements cibles. Chaque ligne représente une commande Ce fichier devra posséder un en-tête avec une seule information :

— command: La commande à exécuter sur les équipements réseau cibles.

• Le nom du fichier ou du répertoire de sortie ó les résultats seront enregistrés.

• Si le rộsultat est dans un fichier texte, ce dernier sera formatộ de faỗon à distinguer les résultats pour chaque équipements :

• Si le résultat est dans un répertoire, des sous-répertoires nommées d’après les hostnames des équipements contiendront les résultats pour chaque commande sous forme de fichiers :

The decision to use the CSV format for the input data files in the script stems from the familiarity of the teams who will utilize it Additionally, CSV is a widely used format that is easily manageable across most tools.

Protocole de connexion aux équipements

Bien que l’accès aux équipements soit restreint au SSH, il est tout à fait envisageable de se servir d’autres protocoles comme NETCONF en sur-couche de SSH.

We chose SSH because it is uncertain whether NETCONF is enabled across the entire Carrefour network Additionally, the script needs to be as generic as possible, allowing it to be used with older equipment that does not support NETCONF.

Mécanisme de rebond

Dans le scénario ó le script est exécuté sur une machine externe, SSH offre un mécanisme de proxy qui est compatible à la majorité des outils que nous avons envisagés d’utiliser.

FIGURE3.1 – Connexion à travers un serveur de rebond

Rebond et environnement d’exécutions

Earlier in this document, we specified that the script must be capable of running on both a bounce server and an external machine To address these two scenarios, two solutions have been considered.

1 Déactiver le rebond après avoir détecté, dans le code du script, l’environnement d’exécution (l’adresse IP du serveur de rebond est identifiable).

2 Désactiver le rebond avec une option à fournir au script.

Disabling the bounce is essential because if the script is run on the bounce server, keeping the bounce active leads to the initial connection being directed to the bounce server itself, which is unnecessary.

The first solution is essential for situations where it is impossible to determine in advance if the execution environment is a bounce server Since there are no use cases outlining this scenario, we opted for the second option, which involves passing an argument to the script to enable or disable the bounce feature.

Authentification

L’authentification finale sur les noeuds réseau cibles va se faire grâce aux noms d’utilisateur et mots de passe Ici encore, deux cas sont à traiter :

1 Quand le script est exécuté sur un serveur de rebond, la connexion par mot de passe est directe.

2 Quand le script est exécuté depuis une machine externe, aucune option SSH [15] ne permet d’utiliser le nom d’utilisateur et mot de passe pour l’authentification lors de la première connexion entre la machine externe et le serveur de rebond.

La seule manière de faire cette première authentification est d’utiliser des clés.

To ensure a seamless initial connection, the public key must be installed on the jump machine It is impractical to require all users of the script to generate and install keys on the jump server The solution to this issue is to configure SSH keys using a designated service account, which will be consistently utilized for the first connection.

Outils utilisés

We opted to use Python because several automation scripts within the team have already been developed in this language Additionally, Python offers faster performance compared to Ansible For libraries, we made specific selections to enhance our development process.

Napalm and Netmiko can be effectively utilized for network management, especially when combined with parallel command execution and inventory management As mentioned in the previous chapter (see 2.4.1), using these tools individually is a viable option for achieving efficient network automation.

• Nornir : Il est possible d’utiliser Nornir pour gérer entre autre le parallélisme des exécutions, mais pas la connexion aux équipements cibles.

We chose to combine the Nornir and Netmiko libraries because Netmiko is easier to use with Nornir compared to Paramiko Additionally, since Napalm would internally utilize Netmiko in our use case, it makes sense to use Netmiko directly to avoid unnecessary software layers.

Le backend

Architecture générale de l’application

We focus on two use cases of the API to illustrate the overall functionality of the application and the role of each component The first use case involves a client request to execute a script, while the second pertains to retrieving the results from a previous execution of the script.

3.3.1.1 Exécution du script grâce à l’API

FIGURE3.2 – Workflow d’exécution du script Command runner via l’API

Dans ce workflow, deux périodes sont à noter pour comprendre l’architecture ainsi que son intérêt.

1 Période 1= Étape 1 à 4: Elle est relativement courte et est synchrone Cela veut dire que l’envoie de la requête et la réponse de l’API contenant l’identifiant du job correspondent au cycle d’une requête POST HTTP classique.

2 Période 2= Étape 5 à 8: Elle est découplée de la période 1 et dépend de la dispo- nibilité d’un Worker.

The scenario illustrated in Figure 3.2 features a single worker, although multiple workers can operate simultaneously on different jobs The API processes range from validating request data to user authorization This scenario depicts a situation where everything functions correctly, including authentication and validation When deployed locally, the reverse proxy is an Nginx container, whereas it operates as a Kubernetes ingress in cloud deployments.

3.3.1.2 Récupération du résultat grâce à l’API

FIGURE3.3 – Workflow de récupération de résultat via l’API

La récupération du résultat depuis la base de données étant relativement courte, l’API communique directement avec la base de données.

3.3.1.3 Intérêt de l’architecture basée sur un moteur de jobs asynchrones

To appreciate the benefits of the job registration and deferred execution mechanism, it is essential to recognize the challenges that would arise in its absence.

Without this mechanism, the client would need to keep the HTTP session open until the script finishes executing, which could take several minutes or even hours Even if a way to maintain the session was found, it would lead to resource wastage, as both the client and server processes managing the session would be idle, waiting for the script to complete.

This blockage led to a quicker saturation of the total number of simultaneous requests that the API can handle, resulting in its unavailability.

Redis en temps que base du moteur de jobs asynchrones

In literature, Redis is the most widely used in-memory data management system for building asynchronous job engines Choosing Redis enables us to evolve our system more easily.

Our goal is to enable the API to post messages (jobs) that a worker can retrieve and execute, as illustrated in the figure below.

FIGURE3.4 – Ajout et retrait de jobs

The principle is to utilize a Redis database as a data bus or queue The API submits jobs into this queue, allowing workers to retrieve and execute them Once a job is selected by a worker, it should no longer be accessible to other workers.

A job primarily consists of the name of a Python function accessible at the Worker level, parameters to be passed to this function, and additional configuration settings, such as the maximum execution duration.

3.3.2.3 Quel protocole/bibliothèque pour dialoguer avec Redis

In Chapter 2, we explored various communication modes for interacting with an asynchronous job engine, identifying point-to-point communication as the most suitable for our objectives Several libraries implement this protocol, and we examined three of them in detail.

We chose RQ for its lightweight design and user-friendly interface, as our engine does not require the additional features offered by Celery While APScheduler is also a viable option, our preference for RQ stems from its prior evaluation within the Automation team.

API

Le rôle de l’API est de permettre d’accéder au script et de rendre transparent tout ce qui se passe en arrière plan.

Il est tout à fait possible d’envisager d’utiliser des technologies autres que REST, mais dans notre cas de figure un API RESTFUL est la solution qui s’est imposée car :

• Elle s’intègre facilement au frontend WEB.

• Le développement de ce type de API est courant au sein de l’équipe Automatisa- tion.

3.3.3.2 Données en entrée et en sortie

We typically handle various types of input and output data, including XML and JSON However, we have opted to focus solely on JSON due to its simplicity in processing and widespread support In essence, when executing a script request, the API receives data such as IP addresses and commands in JSON format and returns a result also in JSON format.

3.3.3.3 Quelques points de terminaison de l’API

Pour pouvoir interagir avec l’API, des requêtes peuvent être envoyées sur les points de terminaison dont voici une liste non exhaustive :

TABLE3.1 – Définition de points de terminaison

Description URL type Donnée entrée

Donnée sortie Codes de sortie

Création de job /job/ POST Oui

/job/{job_id}/ GET Non Oui

/job/{job_id}/ DELETE Non Non

Le job_id est l’identifiant du job et fait partie de la réponse de l’API suite à une requête d’exécution du script.

Upon receiving a request, if it matches the URL of one of the endpoints mentioned above, processing occurs, and a response is generated and sent back to the client.

3.3.3.5 Cas des requêtes avec données (POST)

To ensure that the data sent in a request containing 4.6 JSON complies with expectations, a validation mechanism must be implemented.

FIGURE3.5 – API validation de données

Une fois que la requờte est reỗue sur le point de terminaison POST, les donnộes du corps de la requête sont extraites puis vérifiées (1) La vérification se fait sur :

• Les ports de connexion sont-ils des entiers compris entre 0 et 65535,

C’est seulement après l’étape (1) que les données sont utilisables pour créer (2) un job.

Si la validation ộchoue, l’ộtape (2) n’est pas rộalisộe et l’utilisateur reỗoit un message d’erreur de type "400 : BAD DATA".

Following best practices, some older HTTP clients may ignore data sent in the body of GET requests; therefore, all data must be included in the URLs for the API Data validation for GET requests is unnecessary, as their presence is integral to the request, and any absence or malformed data will result in invalid requests or responses such as "404: NOT FOUND."

3.3.3.7 Traitement de la requête validée

Le traitement de la requête une fois les données validées sont dans l’ordre :

• La vérification de l’autorisation de l’utilisateur.

• Pour une requête POST de création de job, ce dernier est créé puis ajouté dans la base Redis.

For GET requests that retrieve results or the status of a job, the API either queries the database as described in the previous scenario (see Figure 3.3) or accesses the Redis database to obtain information to return to the client.

POST request data, as shown in Figure 4.6, includes authentication information that is concealed within the request body Additionally, all requests are secured with TLS, ensuring systematic encryption for enhanced security.

Authentication and authorization are managed by Carrefour's SSO Each request must include a token for authentication in the header, specified by the attribute "X-API-Authorization," alongside its data in the body This token will be validated by the API through the SSO using OpenID.

FIGURE3.6 – Authentification déléguée au SSO

Au paragraphe (cf 2.4.2.5) du chapitre 2 nous expliquions les solutions aux problốmes que pose l’utilisation d’un langage ôsingle-threadedằ comme Python pour développer des services Web.

La solution que nous retenons pour notre API est d’utiliser les spécifications WSGI

The WSGI specification is currently the most widely used due to its maturity and widespread implementation in various application servers It offers a reliable solution that can easily evolve to ASGI, thanks to ASGI's backward compatibility with WSGI Additionally, the use of WSGI application servers is common within the automation team.

3.3.3.10 Quels outils pour développer l’API ?

1 Le code de l’API : Il existe plusieurs Framework Python qui permettent de construire notre API Le choix s’est basé sur plusieurs critères.

• Est-il déjà utilisé dans l’équipe ?

• Génère-il automatiquement une interface Swagger.

• Intègre-il un mécanisme de validation de données facile à implémenter. Plusieurs framework répondent à la plupart des critères :

Flask répond à tous les critères avec surtout le fait qu’il soit déjà utilisé largement au sein de l’équipe automatisation.

2 Quels outils pour servir l’API?

This topic has been previously discussed, leading us to conclude that the API should be served using an application server that implements the WSGI specification Among the options we explored, Gunicorn and Uvicorn are viable choices, but we prefer Gunicorn for its convenience, as it is already utilized by our automation team for other projects.

Le Worker

In our chosen communication model, a worker acts as a micro-service that executes tasks posted by the API in the job queue on Redis For RQ, the worker is a process that continuously checks the job queue unless it is busy executing another task The code for our script resides within the worker, enabling efficient task management and execution.

Base de données

The command runner service requires the storage of job results categorized by equipment and commands The application's database consists of three tables that are interconnected through one-to-many relationships The database schema is illustrated in the accompanying figure.

FIGURE3.8 – Schéma de la base de données

3.3.5.1 Quel système de gestion de base de données ?

Carrefour utilizes a shared PostgreSQL database management system on Google Cloud Platform (GCP) for all team applications To ensure that the local development environment aligns with the cloud setup, we have opted to use a PostgreSQL container.

3.3.5.2 Accès à la base de données ?

To streamline the management of data retrieved from our database tables, we have opted to use SQLAlchemy This powerful tool allows us to manipulate the entries in our database tables as Python objects, enhancing efficiency and ease of use.

Résumé des bibliothèques de communication

The Command Runner application consists of multiple microservices that communicate directly or through intermediaries The diagram below summarizes the libraries we have selected to facilitate these communications.

FIGURE3.9 – Librairies pour la communication entre micro-services

Intégration au portail : le frontend

The goal is not to build a frontend from scratch, but to enhance the existing frontend developed by the team by adding a single-page application where users can interact with the API and the script in the worker The portal is built using TypeScript, Vue.js framework, and Bulma CSS.

Conclusion

Dans ce chapitre nous avons expliqué globalement les solutions qui seront implé- mentées dans le but de réaliser les objectifs du projet.

Introduction

Des choix ont été faits dans l’optique de mener à bien notre projet A présent, nous allons prộsenter la faỗon dont chaque composant du service command runner a ộtộ implémenté puis déployé.

Le Script Command runner

Fonctionnement de la classe Commande_runner

We have opted to use Nornir and Netmiko for implementing connections to devices and executing our commands This class features a constructor that accepts the following parameters.

1 devices: Une liste de dictionnaires dont les clés sont hostname, port, platform, device_name C’est la liste des équipements sur lesquels les commandes vont être exécutées.

2 commands: Une liste de chaợne de caractốres (les commandes).

3 credentials: C’est un dictionnaire dont les clés sont : username, password Ce sont les paramètres de connexion SSH.

4 logger: (Optionnel) Il s’agit du logger que la classe aurait utilisé pour faire le log- ging des évènements (erreurs par exemple).

Quelques méthodes des objets Comand_runner :

• set_command(commands): Cette méthode initialise la propriété commands avec le paramètre commands.

• set_devices(devices): Elle initialise la propriété devices avec un objet Hosts.

In Nornir, Hosts objects serve as a specialized dictionary that forms the foundational inventory of target devices Each Hosts object must include Host objects, which represent individual equipment within the Nornir framework.

The `set_nornir()` function initializes the `nr` property, which is the Nornir instance used to execute commands Instead of creating a custom Nornir inventory plugin to directly integrate our data (devices and commands) into the Nornir instance, we initialize the Nornir instance with the default "SimpleInventory" plugin and then overwrite the equipment inventory using the `devices` property.

The init_execute() method is designed to execute commands once a Command_runner object is instantiated This method operates by looping through the commands list (the commands property), executing each command in succession.

1 La méthode run de l’instance Nornir (propriété nr) est appelée avec en pa- ramètre la fonction Netmiko (netmiko_send_command) qui doit être utili- sée pour se connecter à chaque équipement de l’inventaire (devices).

2 Le résultat de chaque boucle qui sont des objet “AggregatedResult” (Propre à Nornir) sont stockés dans un tuple (“commande”, "résultats").

NB : La raison pour laquelle nous enregistrons les résultats et les commandes dans des tuples est que l’objet résultat de type

“AggregatedResult” ne permettait pas de connaợtre la commande qui avait été exécutée pour l’obtenir.

3 Les tuples sont ajoutés à une liste.

4 Une fois que la boucle s’est achevée la liste des résultats est passée en paramètre de la méthode generate_results_list() qui formate les résultats sous forme d’une liste de dictionnaire puis la retourne Cette liste est stockée dans la propriété results de l’objet Command_runner.

Arguments

Le fichier Command_runner.py contient l’instruction suivante qui permet de l’uti- liser comme un script dans le terminal :

The processing of arguments, such as converting CSV files into list or dictionary objects in Python, is accomplished through functions found in the h_func/params_parsing.py and h_func/run_prep.py files.

Les arguments suivants peuvent être passés au script, en accord avec nos décisions prises au chapitre précèdent (cf.3.2.1) :

• –devices ou -d : Le chemin vers le fichier csv qui définit la liste des équipements

• –commands ou -c : Le chemin vers le fichier csv de la liste des commandes.

• –outputs-file ou –of : Le nom du fichier qui stockera les résultats.

The ` outputs-directory ` or ` od ` argument specifies the directory where all results will be stored, and this directory must already exist This option can be used as a substitute for ` outputs-file`, and one of these options must be utilized.

• –nb_workers < number of workers > ou -w : Nombre de sous- processus (connexions) simultanés (défaut = 10, max = 20).

• –jumpserver ou -j: Permet l’activation du rebond (cf.3.2.4).

Lancement et résultat

Pour lancer le script : script_command_runner -d \

NB: script_command_runner pointe sur Command_runner.py.

Après lancement les paramètres SSH sont demandés, puis on obtient le résultat après un temps qui dépend du nombre d’équipements et de commandes.

FIGURE4.2 – Lancement et résultat du script dans le terminal

l’API

Résultat : Interface swagger

L’interface ci-dessous est générée à partir de la spécification OpenAPI de l’API.

FIGURE4.3 – Interface swagger de l’API

Cette interface montre deux namespaces :

1 job: Pour les requêtes sur un seul job.

2 jobs: Pour les requêtes sur plusieurs jobs.

Organisation du code

FIGURE4.4 – Structure du code de l’API

Le fichier principal, celui qui est lancé par notre serveur d’application (Gunicorn) est rest_command_runner.py Ce fichier intốgre les deux namespaces ôjobằ et ôjobsằ grâce à un blueprint

There is a hidden namespace called ôhealth that is not visible to users in the interface Its purpose is to define endpoints that provide information about the health status of the backend system.

FIGURE4.5 – Imbrication blueprint et namespaces

A blueprint is a feature provided by the Flask framework that helps modularize API code We have defined two blueprints, each containing its own namespaces Namespaces serve as a way to group endpoints effectively.

Les points de terminaison

The job namespace includes three endpoints To simplify development and maintain consistency in API responses, we have ensured that the structure of the data returned for successful GET and POST requests is identical.

The request corresponds to the execution of the script, and the validation of the request body data is performed using classes defined in the apis/data_validator.py file.

FIGURE4.6 – Exemple de données du corps d’une requête POST

La figure 4.6 montre un exemple du corps d’une requête POST Ce corps contient donc toutes les données nécessaires pour créer un job.

The API responds to a POST request at this endpoint with data that includes the created job identifier (job_id) along with some metadata The 'commands_results' data field is an empty list for a new job.

La figure 4.7 montre un exemple de données retournées en cas de réponse positive (code 201).

Pour récupérer le résultat d’un job le paramètre (job_id) doit être ajouté à l’URL.

[host] /job/a18b4bb9-5dcb-455a-a523-7740e7550980/?data=all

NB: Quand le paramốtre ôdataằ vaut ôallằ l’API retourne les commandes et leurs résultats, sinon seules les méta-données sont retournées.

Pour supprimer un job et ses résultats.

Ce namespace n’a qu’un seul point de terminaison Ce dernier permet de récupérer une liste contenant les données de tous les jobs créés par l’utilisateur.

Le Worker

La classe CustomWorker

Cette classe représente le code du worker Nous y définissons quand le worker lance le job, mais aussi les traitements avant et après la fin du job.

Once a worker retrieves a job, we create an entry in the jobs table of the database containing the job information This ensures that we have a record of the job in the database as early as possible, facilitating potential GET requests to check the status of the jobs.

4.4.1.2 Après le lancement du job

Once the results are available, the entry in the jobs table in the database is updated, followed by the creation of entries in the oper_host_results and oper_command_results tables to store the results.

Le portail : La page ôCommand Runnerằ

Fonctionnement détaillé

Most data objects handled within the application are instantiated from classes defined in the file front/src/store/models/dataModels.ts The classes outlined in this file include the following:

• SshCredentialsUP: Les objets de cette classe représentent les paramètres SSH pour se connecter aux équipements.

• Command : Les objets de cette classe sont ộquivalents à des chaợnes de caractères représentants des commandes.

• Commands: Une liste d’objet Command Un objet de cette classe possède une mộthode ôaddFromCSV(data : string)ằ qui permet d’ajouter des objets command à partir du contenu de fichier CSV (cf.3.2.1).

• Devices: Une liste d’objet Device Un objet de cette classe possède une méthode ôaddFromCSV(data : string)ằ qui permet d’ajouter des objets Device à partir du contenu de fichier CSV.

A Job represents all the data from a POST request necessary to execute a script It includes properties such as SshCredentialsUP, Commands, Devices, and a unique name for identification.

• Jobs: Une liste d’objets Jobs.

• Result : Représente un résultat retourné par l’API pour une requête POST sur le point de terminaison /job/ ou une requête GET sur le point de terminaison /job//.

The ResultList is a collection of Result objects, featuring a method called refreshJobsStatusAll(authToken: string) that updates the contained Result objects until their status is stable, indicating that the job has either completed successfully or failed.

Les composants, en plus de leurs données propres ( par exemple, pour activer/désactiver un checkbox ) utilisent les données (Jobs, Results ) Toutes ces données sont centralisées grâce au moduleVuex.

The front/src/store directory contains the initialization of Vuex (index.ts) and the data store The CommandRunnerMod class in the front/src/store/modules/commandrunner.ts file defines the elements of the store, including data, mutations, and getters.

4.5.1.3 La View principale : frontend/front/src/views/Commandrunner.vue

The main view serves as the central component for all user interactions, organizing the remaining page space using Bulma CSS tiles.

Cette view incorporera d’autres composants fils EditJob, ThumbnailJob, GetJobNa- meSshCred dont certains sont affichés en fonction des actions de l’utilisateur.

• L’espace Jaune : C’est l’endroit ó les composants ThumbnailJob sont ajoutés. Les composants ThumbnailJob sont ajoutés à cette espace dans deux cas de figures :

1 A la création du composant (view) principal.

2 Quand un nouveau job est exécuté.

• L’espace Bleu ou Cyan : Contient un bouton ôcreateằ pour crộer un job.

• L’espace Gris : En fonction de l’action de l’utilisateur, cet espace peut accueillir les composants EditJob ou Display

4.5.1.4 Les composants : front/src/components/commandrunner/

1 Action de création de job:

Quand l’utilisateur clique sur le bouton ôcreateằ, les composants suivants sont ajoutés à la zone grise.

FIGURE4.11 – Imbrication des composants à la création job

— GetJobNameSshCred: Permet de récupérer les paramètres SSH et le nom du job.

— GetDevice: Permet de récupérer les informations (hostname, port ) d’un équipement.

— GetCommand: Permet de récupérer une commande.

— GetCsv: Permet d’importer un fichier CSV.

2 Action d’affichage du résultat d’un job:

Quand l’utilisateur clique sur le nom du job dans l’espace jaune (sur un compo- sant ThumbnailJob), les composants suivants sont ajoutés à la zone grise.

FIGURE4.12 – Imbrication des composants à l’affichage de résultat

— DisplayJobResult : Regroupe les composants qui affichent le résultat pour un job.

— DisplayHostResult: Affiche le résultat pour un équipement.

3 Actions de suppression de job, de téléchargement de résultat:

Les composants ThumbnailJob disposent de menus déroulants qui permettent de supprimer les jobs et leurs résultats ou de télécharger ces derniers.

FIGURE4.13 – Menu déroulant : action de suppression et téléchargement de résultat

Le Déploiement

Déploiement de la stack en local

Déploiement de la stack dans cloud (k8s)

Ngày đăng: 24/03/2025, 23:01

TRÍCH ĐOẠN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm