Projet GSB

1 – INTRODUCTION

Cette réalisation a été effectuée durant ma seconde année de BTS SIO (Brevet de Technicien Supérieur Services Informatiques aux Organisations) au lycée Bonaparte de Toulon (83). Nous avons eu pour mission de concevoir, installer et configurer une infrastructure pour le compte d’une entreprise cliente (fictive). Son nom serait GSB (Galaxy Swiss-Bourdin) en résultat de la fusion de deux entreprises : Galaxy, spécialisée dans les maladies virales telles que le SIDA ou l’hépatite et Swiss-Bourdin, une union de trois laboratoires travaillant sur des médicaments conventionnels. 

Durant toute une année scolaire, nous avons été chargés de réaliser l’installation physique et logicielle de l’infrastructure de cette entreprise. Nous devions raisonner comme des techniciens supérieurs et concevoir une infrastructure cohérente et homogène pour répondre au besoin. Nous ne devions pas uniquement répondre à un besoin, mais chercher à raisonner pour concevoir une infrastructure cohérente et homogène. 

Ce projet a été réalisé en équipe et soumis à quatre groupes d’étudiants appelés Pods (groupes en anglais). Ces quatre équipes ont bénéficié chacune d’un serveur d’hypervision, de routeurs et de commutateurs complètement indépendants les uns des autres.

Bien que fictive, l’entreprise GSB était représentée par nos enseignants. Ceux-ci nous ont exprimé leurs besoins en tant que client, tout en restant disponibles pour nous guider et pour répondre à nos questions techniques en s’abstenant cependant de toute action sur le réseau que nous étions en train de concevoir. 

Pour répondre au besoin du client, nous avions à disposition un cahier des charges, rédigé par nos enseignants, dans lequel était consigné un ensemble de besoins. Le suivre nous a permis de valider un ensemble de compétences nécessaires à l’obtention du diplôme de technicien supérieur (BTS SIO). 

Chacun des pods de notre promotion comportait des différences techniques. En plus d’un cahier des charges déjà conséquent, chaque élève avait trois projets personnels techniques à intégrer dans le contexte GSB. Ces trois projets concernaient l’intégration de technologies de notre choix que nous devions intégrer à la solution déjà existante. Dans le cadre de notre BTS, nous avons été évalués sur notre maîtrise des solutions implémentées et sur notre capacité à modifier le réseau. Lors de l’examen, il nous a été demandé d’ajouter des liens réseau, de modifier des configurations serveurs et de répondre à des problématiques techniques ou extra-techniques en implémentant des solutions techniques.

2 – OBJECTIFS

Nos enseignants avaient préparé ce contexte pour nous faire travailler et réfléchir dans une situation professionnelle. Ce projet avait pour objectif de faire croître les compétences techniques et extra-techniques des étudiants de BTS SIO. 

Je vais vous présenter d’abord les objectifs techniques de cette réalisation puis ses objectifs extra-techniques.

2.1 – Les objectifs techniques

Dans cette réalisation, les objectifs techniques ont été nombreux. J’ai réussi à en distinguer deux grands axes : 

• La maîtrise totale d’un système d’exploitation.
• La formation des étudiants à la mise en œuvre d’un cahier des charges dans un contexte professionnel 

Maîtriser un système d’information, c’est comprendre parfaitement son fonctionnement. De sa conception à son amélioration, un technicien supérieur doit maîtriser le réseau, les solutions applicatives et la sécurité de son système d’information. Le technicien doit être en mesure de mettre en œuvre un cahier des charges et donc de répondre aux besoins en proposant une solution adaptée aux limites techniques qui peuvent se présenter ; cela comprend également l’aptitude à délivrer un résultat malgré les contraintes techniques et temporelles. 

2.2 – Les objectifs extra-techniques

Dans cette réalisation, nous avons pu en définir trois : 

• Le relationnel, 
• La veille technologique et juridique 
• La capacité à raisonner. 

Les objectifs relationnels

Dans cette réalisation, ils avaient pour but de nous faire comprendre qu’un projet d’entreprise ne se réalise pas seul. Voici les deux grands axes :

• Communiquer avec tous les acteurs du projet
• Interagir dans notre groupe afin de prendre des décisions collectives pour être en mesure de réaliser des tâches techniques ensemble.

Les objectifs de veille technologique et juridique

Ils avaient pour finalité de permettre à chaque étudiant : 

• D’augmenter ses connaissances
• De développer sa curiosité
• De réfléchir en matière de juridique appliquée à l’informatique. Cela a eu un réel impact sur la réalisation de nos projets personnels dans le contexte GSB.

La capacité à raisonner

L’objectif de ce travail était de nous faire acquérir un ensemble de compétences techniques dans le cadre du déploiement de ce réseau d’entreprise complet. Il visait aussi à nous faire réfléchir sur les méthodologies à aborder, sur la gestion du parc informatique, sur la gestion des ressources, mais aussi sur la communication au sein de nos groupes de travail. L’ensemble de ces objectifs devaient faire de nous des informaticiens aptes à travailler dans les entreprises de demain.

3 – CONTEXTE HUMAIN

Pour réaliser ce projet, nous avons été répartis en groupes de travail appelés « Pods ». Au début du projet GSB, nous avons eu la possibilité de choisir les étudiants avec lesquels nous souhaitions réaliser le projet. Ilan MARRACHE et Dorian RASTELLO ont été mes partenaires dans la réalisation de ce projet. Nous nous sommes vu attribuer par les enseignants un nom de pod : Le Pod 4.

J’ai été désigné responsable du Pod 4 par les membres de mon équipe et ce choix a été validé par nos enseignants. Dès que j’ai reçu ce rôle, j’ai commencé par nous répartir les différentes tâches à réaliser en prenant en considération les niveaux techniques individuels et les niveaux à atteindre. Mes choix ont été également guidés en fonction des préférences techniques de chacun de nous, ainsi un ferait plutôt de la configuration réseau, un autre de la configuration logicielle, pendant que j’installerai une machine virtuelle.

Nos enseignants nous ont expliqué leurs besoins en tant que clients. Ils nous ont cependant guidés durant certaines étapes délicates de ce projet, car ils étaient présents pour répondre à toutes nos questions si nous avions des blocages techniques. 

Ce contexte humain nous a permis de nous épanouir en tant qu’étudiants dans la création d’un réseau d’entreprise complet. 

4 – CONTEXTE TECHNIQUE

Chaque pod devait concevoir un réseau indépendant. La seule ressource partagée par les quatre pods de la classe était la ligne ADSL dédiée aux étudiants de BTS SIO (Systèmes Informatiques aux Organisations). 

Le réseau indépendant mis à disposition pour chaque groupe de travail était composé d’un hyperviseur, d’une baie de brassage, de plusieurs routeurs, de plusieurs switchs et de serveurs physiques.

Dans le cadre de cette réalisation, nous avons été soumis à deux limites techniques. La première était que la réponse au cahier des charges devait être réalisée uniquement sur l’infrastructure dédiée (on-premise dans les salles de notre BTS), ensuite, nous devions obligatoirement utiliser des solutions applicatives gratuites (excepté les licences Windows Serveur). 

En plus du cahier des charges, chaque élève devait faire évoluer l’infrastructure du pod en ajoutant une plus-value. Cela a permis à chacun de pouvoir personnaliser l’infrastructure et donc, d’une certaine manière, de se l’approprier.

5 – ENJEUX ET RISQUES

Le projet GSB du BTS SIO de Toulon avait pour but de nous rendre aptes à travailler dans un contexte d’entreprise. A priori, nous aurions pu penser que le projet étant fictif, celui-ci ne comprenait ni enjeux ni risques, mais nous avons réalisé qu’il en était différemment. 

5.1 – ENJEUX

Ce projet a eu une part très importante dans la réussite de notre diplôme de techniciens supérieurs. Nous avons eu plusieurs examens pratiques et théoriques en rapport direct ou indirect avec le projet GSB, car dès son initialisation, nous avions été informés de l’importance que celui-ci aurait dans la validation de notre BTS. Nous avons eu peu de temps pour déployer l’ensemble de l’infrastructure. Il a fallu que l’on s’organise pour répondre au cahier des charges tout en respectant les délais qui étaient cours. 

5.2 – RISQUES

Dans le cadre du projet GSB, le principal risque concernait les incidents techniques physiques ou logiciels qui auraient pu nous empêcher de présenter l’infrastructure le jour de l’examen. Tout au long de notre avancement dans ce travail, nous avons veillé à procéder régulièrement à la réalisation de sauvegardes des configurations des équipements réseau et des documentations techniques afin de pouvoir si besoin réinstaller les différentes parties de l’infrastructure.

6 – ÉTAPES DU PROJET

6.1 – Organisation

Chaque groupe de travail était composé de trois ou quatre étudiants pour réaliser ce projet et nos enseignants sont restés disponibles pour répondre à des questions techniques, cependant, chacun des groupes devait réaliser le projet dans une autonomie maximale afin de valider l’ensemble des aptitudes techniques et extra-techniques nécessaires à la validation du Brevet de technicien supérieur.

Dès les premières heures de travail sur le contexte GSB, j’ai pu me rendre compte des responsabilités liées à la direction d’un groupe dans le cadre d’un projet aussi important. N’étant pas expérimenté dans la gestion de projet, j’ai employé des méthodologies sommaires de gestion de projet. Dès les premières semaines, j’ai demandé à mes camarades d’inscrire sur papier les détails techniques de chacun des serveurs (virtuels et physiques) et des équipements réseaux (routeurs et commutateurs). J’ai opté pour ces méthodologies simples à cause du manque de vision globale que nous avions sur le système d’information que nous étions en train de concevoir. Nous avions un grand nombre d’équipements à installer physiquement et à configurer. Les détails techniques de chaque composant (serveur ou média d’interconnexion) étaient ainsi connus de tous ceux qui n’avaient pas réalisé eux-mêmes l’installation et la configuration. Ces documents nous ont servi de documentation technique et nous les avons utilisés durant l’ensemble du projet. Nous avons par la suite employé des outils spécialisés comme GLPI (Gestion Libre de Parc Informatique) dans la gestion d’inventaire de parc informatique et d’inventaire des documentations techniques. 

6.2 – IntEractions avec le client

Nos clients (fictifs) étaient représentés par nos enseignants qui nous aidaient à bien comprendre leurs besoins. Nous avions avec eux des rendez-vous pour discuter de l’avancée de notre projet. Ces interactions peuvent être comparées à celles employées dans une démarche agile où l’on garde en permanence un contact avec le client. Par exemple, nous avons eu une réunion pour proposer la structure de l’Active Directory choisi et ainsi constater si nos clients étaient satisfaits ou non de cette proposition. Cela nous a permis de ne pas réaliser d’actions en dehors du vrai besoin client. 

6.3 – Travail réalisé

Appréhension de l’infrastructure existante

Dans un premier temps, nous avons dû nous familiariser avec l’infrastructure réseau de l’école. Il était nécessaire pour nous de la comprendre et de la maîtriser. Le réseau initial était composé de plusieurs routeurs et switchs. Il était également réparti sur plusieurs salles de classe et de travaux pratiques ainsi que dans une salle serveur à laquelle nous avions un libre accès. 

Cette phase d’appréhension n’a pas été initiée dans le cadre du projet GSB. Celle-ci a débuté durant notre première année de BTS. Nous utilisions déjà ce réseau pour réaliser des petits travaux pratiques sur différents sujets comme le routage, les VLAN (réseau local virtuel), le NAT (Network address translation), etc. 

Afin de favoriser au mieux la prise de décisions techniques, nous avions besoin de maîtriser le réseau sur lequel nous intervenions. Cette première étape nous a ainsi permis d’avoir une vue d’ensemble sur le réseau déjà existant. 

Installation physique et logicielle des nouveaux hyperviseurs

Pendant la finalisation de la phase d’appréhension du Système d’Information du lycée, nos enseignants ont réceptionné quatre serveurs rackables Dell EMC 440 Poweredge. Ces serveurs dernière génération étaient destinés aux étudiants du BTS SIO. Ainsi, chaque pods s’est vu attribuer un hyperviseur totalement dédié.

L’ensemble de l’installation (physique et logicielle) de l’hyperviseur nous a été confié dans le cadre du contexte GSB. Pour préparer au mieux cette installation, j’ai réalisé seul une documentation complète sur l’installation logicielle de l’hyperviseur et elle a été utilisée par l’ensemble de notre classe pour que les hyperviseurs soient tous identiques. Cette uniformité était nécessaire pour simplifier la gestion des serveurs lors des années à venir. Un réseau homogène est bien plus évident à comprendre et à mettre à niveau qu’un réseau hétérogène. Cette documentation nous a permis de préparer nos hyperviseurs en y installant Windows Serveur 2019 Datacenter. 

Après avoir réalisé la configuration logicielle préliminaire, nous avons installé les serveurs dans une baie de brassage située dans la salle serveur dédiée à notre filière. Pendant cette phase d’installation physique, nous avons débuté la configuration réseau de nos serveurs. Nous avons pu relier correctement nos serveurs qui avaient désormais accès à deux VLAN différents. Le premier était un VLAN d’administration ; il permettait à nos enseignants de se connecter à notre serveur d’hypervision. Le second était un VLAN de production. Il était nécessaire dans notre utilisation quotidienne.

Installation physique et logicielle des autres serveurs

Le besoin en matière de puissance de calcul étant principalement rempli par notre hyperviseur, quand était-il des autres serveurs qui étaient à notre disposition ? 

Sans compter l’hyperviseur central, nous avions à notre disposition deux serveurs autonomes qui ne comportaient pas réellement de puissance de calcul ; ainsi que trois postes de travail (chacun affecté à un membre du pod) qui pouvaient accueillir quelques machines virtuelles. 

Pour les deux serveurs autonomes, nous avons choisi d’installer comme système d’exploitation Debian 10, qui était la dernière version en date au moment de la réalisation. Le fait que ces deux serveurs soient sous Linux était inscrit sur le cahier des charges. Le premier serveur fut nommé PROXSYLAB, nous l’avons installé et configuré pour qu’il puisse nous permettre d’accéder au réseau GSB depuis partout sur Internet de manière sécurisée. Le second serveur fut nommé REZOLAB, il remplissait le rôle de serveur DNS (Domain Name Service) tertiaire et DHCP (Dynamic Host Configuration Protocol). Un serveur DNS permet de convertir un nom de domaine comme “exemple.com” en une adresse IP (publique ou privée). 

Sur nos trois postes de travail, nous avons installé Windows 10 Professionnel (licences fournies par nos enseignants) et nous avons activé l’hypervision. Comme logiciel d’hypervision, nous avons choisi de rester sur celui natif à Windows, le logiciel Hyper-V. Dans un premier temps, nous n’avons pas réellement eu le besoin de déployer des machines virtuelles sur nos postes de travail. Celles-ci nous permettaient principalement de réaliser des tests, mais aussi de préparer notre examen avec les trois solutions applicatives à ajouter dans le réseau. 

Interconnexion des équipements

Maintenant que nous avions installé nos trois serveurs principaux, il fallait les interconnecter. Pour cela, l’ensemble des serveurs avait chacun deux cartes réseau. La première était celle de production et la seconde servait au monitoring (surveillance) et pouvait également servir en cas de défaillance du réseau de production. 

Pour mettre en réseau ces équipements, nous avions à notre disposition plusieurs routeurs et plusieurs commutateurs qu’il a fallu interconnecter pour former un tout. Nous avons donc brassé nos équipements.

Pour détailler la configuration choisie, nous avons défini des VLAN (Virtual LAN) nous permettant de segmenter les domaines de broadcast. Nous avons configuré les routeurs en adéquation avec le besoin, puis les relais DHCP (Dynamic Host Configuration Protocol) et mis en place des ACL (Access Control List) pour sécuriser le réseau. 

Les ACL ou listes de contrôles d’accès en français, nous permettent de gérer les permissions d’interconnexion entre les différents équipements (routeurs ou commutateurs). Ces listes sont donc très pratiques pour autoriser les flux que nous voulons et interdire le reste. Il est fortement conseillé de documenter le plus possible les ACL mises en place pour les futurs administrateurs qui s’occuperont du réseau. 

Nous avons ainsi configuré nos routeurs, commutateurs et équipements finaux. L’ensemble de ces interconnexions a été réalisé afin de correspondre aux besoins exprimés par le client. 

Création et configuration des différents serveurs virtualisés

• Les serveurs SV-CD1-LAB et SV-CD2-LAB

Les deux premiers serveurs virtuels que nous avons configurés étaient deux serveurs Windows. Nous avons décidé d’installer des serveurs ADDS (Active Directory Domaine Service), DNS (Domain Name System), DHCP (Dynamic Host Configuration Protocol), mais aussi les serveurs liés à la gestion des fichiers sur les deux serveurs Windows pour établir une redondance.

Un serveur Active Directory est un serveur qui concentre l’authentification des utilisateurs et des ordinateurs. Celui-ci est proposé par le système d’exploitation Windows Server 2019. Nous avons choisi d’installer le rôle Windows serveur ADDS. Il existe plusieurs rôles qui permettent de proposer une base de données d’utilisateurs, mais cette solution est la plus répandue et la plus fiable. Nous avons été contraints d’utiliser spécifiquement ce rôle pour correspondre au besoin du client. 

Nous avons configuré ces deux serveurs pour qu’ils puissent fournir un service à haute disponibilité. Si l’un des deux serveurs rencontrait des difficultés, le second pourrait prendre le relais. 

En plus de stocker nos utilisateurs, le serveur Active Directory (AD) nous permettait de mettre en place des GPO (Group Policy Object) qui sont des politiques de sécurité que nous pouvons appliquer à des utilisateurs ou à des ordinateurs. Pour cela, nous avons conçu toute une hiérarchie dans l’annuaire Active Directory pour appliquer certaines règles à certains ordinateurs ou usagers. Par exemple, tous les utilisateurs de l’AD avaient un fond d’écran modifié, mais uniquement les utilisateurs du service informatique avaient droit à l’accès aux terminaux de leurs ordinateurs (CMD ou Powershell).

Les serveurs DNS et DHCP permettent respectivement de traduire un nom de domaine en IP et de délivrer une adresse IP aux cartes réseau du système d’information ne possédant pas d’adresse IP fixe. 

Les services de fichiers et de stockage permettent de créer des partages de fichiers sur le réseau. Ceci est extrêmement pratique dans le cadre d’un contexte d’entreprise, car ça nous permet de créer des profils d’utilisateurs itinérants. Si un utilisateur utilise deux ordinateurs différents, il retrouvera ses dossiers automatiquement. 

De plus, ces possibilités de transfert et de stockage de fichiers sur le réseau facilitent la simplification des échanges de données entre les différents utilisateurs de l’entreprise. Ils sont également très pertinents, car grâce aux GPO (Group Policy Object) précédemment évoqués, nous pouvons ainsi désactiver tous les ports USB des ordinateurs de l’entreprise et ainsi, forcer les utilisateurs à utiliser les partages réseau. C’est aussi une mesure de sécurité pour éviter la perte de données ou la contamination du réseau. 

• Les serveurs INTRALAB ET BDPHARMA

INTRALAB est un serveur Web permettant la gestion des notes de frais des utilisateurs de GSB. Pour installer cette application, nous avons utilisé un serveur LAMP (Linux Apache, MariaDB et PHP). Nous avons, par la suite, téléchargé le site web créé par Monsieur GIL (professeur de développement) qui permet justement la gestion de notes de frais. Pour le bon fonctionnement de ce service, nous avons procédé à une interconnexion entre INTRALAB et BDPHARMA.

BDPHARMA est un serveur de bases de données. Nous avons installé le logiciel Mariadb qui permet le stockage de base de données au format SQL et nous y avons importé la base de données des notes de frais. Nous avons ensuite créé un utilisateur dédié au requêtage de cette base de données que nous avons confié au serveur INTRALAB. 

• Le serveur MESSAGLAB

MESSAGLAB est une machine virtuelle créée dans l’unique but de permettre l’échange de mails entre les employés de GSB. Pour permettre cet échange, nous avons utilisé les serveurs LAMP, Dovecot, Postfix, Postfixadmin et Rainloop. Ce fut la réalisation la plus complexe que j’ai réalisée en tant qu’informaticien, car c’était celle qui comprenait le plus grand nombre de modifications de fichiers de configuration ; mais il fallait également configurer les logiciels précédemment évoqués et les faire communiquer. Nous devions aussi créer une base de données avec plusieurs utilisateurs possédant des droits différents.

Comme je l’ai déjà expliqué, la gestion des mails a été quelque chose de vraiment complexe, car vu que je suivais une documentation en ligne, je n’avais pas une totale maîtrise des configurations effectuées, cependant, nous avons réussi à faire fonctionner ces interconnexions. Les utilisateurs de l’infrastructure étaient désormais en mesure de pouvoir communiquer en interne.

Ce besoin d’une messagerie en interne était un choix très pertinent, car nous pouvons comprendre qu’une entreprise travaillant dans l’industrie pharmaceutique, n’a pas envie que ses projets soient connus par une source tierce. Les mails constituent un ensemble de données très sensibles pour l’entreprise.

• Le serveur SRV-GLPI & SRV-OCS

Les serveurs SRV-GLPI et SRV-OCS sont des machines virtuelles permettant d’assurer la gestion du parc informatique de GSB. Cette gestion se traduit concrètement grâce à la gestion de tickets, à l’inventaire des différents serveurs et à celui des logiciels. Nous avons entrepris d’associer OCS Inventory (Open Computer and Software Inventory) à GLPI (Gestionnaire Libre de Parc Informatique) afin d’optimiser la gestion de parc. Pour ce faire, nous avons installé deux serveurs Web LAMP (Linux, Apache, MySQL, PHP) sur lesquels nous avons ajouté respectivement le logiciel OCS et le logiciel GLPI.

Nous avons ensuite installé des agents OCS sur les solutions applicatives du réseau GSB afin de recenser l’ensemble des logiciels et des systèmes d’exploitation utilisés par l’entreprise.

• Deux postes clients : CLIENT-DEB et CLIENT-WIN

CLIENT-DEB et CLIENT-WIN sont deux machines virtuelles connectées au VLAN des clients de l’infrastructure. Elles reçoivent donc des adresses IP automatiquement. 

Nous avons choisi d’avoir un client Windows et un client Linux pour étendre les possibilités de notre réseau. En effet, dans le cadre d’un système d’information complètement régi sous la franchise Microsoft, il est très fréquent de voir des postes Linux. Ceux-ci sont souvent des stations blanches. Complètement isolées du réseau, elles permettent de formater proprement les clés USB que nous utilisons afin de les affranchir des virus.

• Serveur : FTPLAB

Dans le cadre de l’entreprise fictive GSB, il était impératif pour les employés de disposer d’un répertoire partagé. Sans cette technologie, les employés ne pourraient pas téléverser des dossiers ou des fichiers pharmaceutiques. C’est pourquoi nous avons créé FTPLAB (nommé ainsi pour serveur FTP du laboratoire). Cette machine virtuelle comprend un serveur FTP (File Transfer Protocol) permettant à des clients FTP d’échanger des fichiers.

Sujets personnels

Pour valider l’évaluation finale, chacun d’entre nous devait réaliser trois projets personnels qui devaient améliorer l’infrastructure de GSB. Ce prérequis nous offrait une réelle liberté pour procéder à des changements dans l’infrastructure finale. Cela nous permettait d’accroître notre inventivité.

J’ai choisi les trois sujets suivants : déployer le pare-feu Alcasar, le proxy HaProxy et une solution de surveillance via les logiciels Prometheus et Grafana. J’ai eu la volonté de les mettre en œuvre, car j’avais découvert ces trois technologies lors de ma veille technologique.

Le pare-feu Alcasar permet de filtrer l’activité sur le Web de l’ensemble des utilisateurs de la plateforme GSB. Il permet notamment d’interdire des catégories de site web (streaming, pornographie, violence, réseaux sociaux, etc.). De plus, il nous permet de mettre des restrictions plus diverses comme des plages horaires auxquelles les utilisateurs ont accès à Internet. Passé ces délais, cela ne fonctionnera plus.

J’ai déployé le proxy HaProxy pour accroître la disponibilité du site web interne de GSB (INTRALAB). L’accès au site intranet passait désormais par un proxy qui s’occupait de rediriger les requêtes web vers le bon serveur final (backend). J’ai choisi d’utiliser le mode “round-robin” qui permet d’envoyer les requêtes http sur les deux serveurs, l’un après l’autre. Si je consulte l’url Frontend, le premier serveur va me répondre et si je réitère la requête, le second serveur interviendra. Ce mode de fonctionnement permet de supporter une plus grande volumétrie. J’ai d’ailleurs réalisé une expérience. Si j’utilise un serveur web isolé, je peux lui envoyer 372 763 requêtes avant que le serveur ne soit indisponible. Si je duplique le nombre de serveurs et que je les rends disponibles via un proxy qui fait du round robin, j’obtiens un résultat de 529 522 requêtes. J’ai ainsi pu confirmer que le fait de clusteriser une application la rend plus forte face aux stress tests. En production, cette application sera ainsi plus disponible et engendrera une plus grande satisfaction client. En cas de perte de l’un de deux serveurs, l’application restera disponible, c’est pourquoi j’ai choisi d’implémenter cette solution dans le contexte de GSB.

Enfin, le troisième sujet que j’ai retenu d’implémenter dans GSB, est un monitoring via Prometheus et Grafana. Prometheus est une base de données qui croît en récupérant elle-même des nouvelles données auprès d’agents qui la fournissent. Grafana est un logiciel de visualisation de données. Pour ce projet, j’ai installé sur tous les serveurs Windows des agents d’exportation de métriques systèmes dont le nom est “node-exporter””. Ces agents étaient configurés pour exposer une sorte d’API disponible sur le port 9100 des serveurs sur lesquels ils étaient installés. J’ai ensuite configuré la base de données Prometheus pour qu’elle récupère de manière périodique les données exposées sur le port 9100 des différents serveurs. J’ai enfin utilisé un tableau de bord de monitoring disponible publiquement sur Internet pour visualiser dans Grafana des données de Prometheus. Ce projet m’a permis d’améliorer la visibilité que nous avions sur l’état des différents serveurs Windows et Linux dans l’infrastructure GSB.

GESTION DU PATRIMOINE

En informatique, la gestion d’un patrimoine correspond à l’ensemble des moyens mis en œuvre pour garder le contrôle sur un système d’information. Nous gardons grâce à ce procédé des traces de l’ensemble des équipements d’interconnexions du système, mais également, des équipements finaux. Dans le cadre de ce projet, nous avons procédé de deux manières différentes pour gérer notre patrimoine. Nous avons utilisé une méthode informatisée et une qui ne l’était pas.

• Gestion informatisée

Dans le contexte GSB, nous avons dans un premier temps utilisé le service Google Docs sur lequel nous avons noté toutes les informations importantes sur les serveurs du contexte, cependant nous nous sommes vite rendu compte des limites de ce procédé. Dès l’instant où nous imprimions nos notes, celles-ci étaient difficilement modifiables. Nous étions également limités pour la hiérarchisation des documentations, et par le stockage maximum qu’un compte Google particulier permet.

• Gestion automatisée

Par la suite, nous avons employé un serveur LAMP doté de GLPI couplé avec un serveur OCS. Un serveur GLPI (Gestionnaire Libre de Parc Informatique) permet la gestion (inventaire du matériel et des incidents) d’un parc informatique. Le serveur OCS permet l’inventaire des ordinateurs avec leurs logiciels installés. Ce serveur, couplé avec la puissance de GLPI, permet de collecter des informations très intéressantes pour la gestion du patrimoine. Pour que le serveur OCS récolte bien toutes les données, il a fallu installer sur chaque ordinateur et sur chaque serveur un agent OCS. L’agent OCS va collecter et envoyer tous les logiciels installés sur la machine au serveur OCS durant le démarrage du système d’exploitation. 

Grâce à cette nouvelle gestion du patrimoine, nous avons pu utiliser la puissance de GLPI pour résoudre les difficultés rencontrées en employant une gestion non informatisée. 

7 – FIN DU PROJET ET PERSPECTIVES D’AVENIR

Comme nous l’avons évoqué précédemment, pour valider notre diplôme, nous devions apporter une modification sur l’infrastructure dans le cadre d’un examen individuel.

Cette phase finale du projet fut vraiment intéressante, car nous n’avions pas d’information sur les différentes possibilités de changement à effectuer. C’est durant cette partie de l’examen que nous devions prouver que nous maîtrisions l’infrastructure que nous avions conçue. Ces modifications pouvaient porter sur n’importe quelle partie du Système d’Information que nous avions conçu en équipe, mais également et surtout sur nos projets personnels. 

Dans le cadre de mon examen, j’ai reçu une fiche avec l’ensemble des modifications que je devais apporter à l’infrastructure. Voici une liste des modifications que j’ai dû apporter au serveur proxy Alcasar :

• Interdire un site web donné et la catégorie pornographique 
• Extraire toutes les informations du firewall dans le cadre d’une enquête judiciaire
• Réaliser un script qui effectue la rotation des logs sur le serveur de manière automatisé
• Produire un compte-rendu de l’ensemble des actions que j’ai réalisé sur l’infrastructure ainsi que sur les méthodes que j’ai pu appliquer pour solutionner les blocages rencontrés. Il s’avère que durant la phase d’examen, je n’ai pas pu être en mesure de bannir un site pornographique. En amont, j’avais confirmé le bon fonctionnement de mon proxy en bloquant un site web lambda. Cependant, le jour de l’examen, les sites pornographiques avaient été bloqués au préalable par les serveurs proxy de mes enseignants. Mon serveur n’était pas en mesure de filtrer un trafic déjà filtré. Pour prouver le bon fonctionnement de ma solution applicative, j’ai ainsi bloqué un site web traditionnel en guise d’exemple. 

L’ensemble du réseau physique que nous avions conçu n’avait pas besoin d’être réinitialisé à la fin de notre année scolaire. Les mots de passe de l’infrastructure étant présents dans le cahier des charges, les élèves nous remplaçant ont pu utiliser l’infrastructure que nous avions conçue. Ainsi, ils ont pu accéder aux commutateurs, aux routeurs et à l’hyperviseur. Cependant, ils ont réalisé leur propre infrastructure en supprimant la configuration des équipements et la totalité des machines virtuelles.

8 – CE QUE JE RETIENS

Même si celui-ci ne fut destiné à aucun client réel, le projet GSB m’a apporté plus que n’importe quel autre projet réalisé dans un contexte scolaire ou d’entreprise. J’ai vraiment constaté l’amélioration de mes compétences. Durant cette réalisation, j’ai pu faire de la conduite de projet, du management et exercer pleinement le métier d’administrateur système et réseau. Nous avons pu concevoir un réseau d’entreprise conforme à l’attente de nos clients tout en respectant les courtes dates butoirs imposées. Le projet n’a pas été facile à réaliser. Nous avons dû nous armer de patience dans certains cas face aux problèmes rencontrés en production comme des configurations erronées, des équipements défectueux, ou des erreurs dans l’interconnexion des équipements. Quand je repense à ce projet, je me remémore les nuits entières passées à rédiger des comptes-rendus sans toutefois les avoir vécues comme des contraintes, car nous voyions réellement ce projet nous faire grandir techniquement tout en nous faisant changer notre manière de raisonner et de solutionner les différents problèmes rencontrés. Avec le recul, j’aurais aimé connaître et maîtriser Docker pendant ce projet. Pour réaliser un grand nombre de tests dans ce contexte, j’ai déployé un très grand nombre de machines virtuelles temporaires, car cela permettait de tester une solution applicative pendant une période allant de quelques heures à une ou deux semaines. Docker m’aurait permis d’économiser un très grand nombre d’heures d’installation. 

Je remercie sincèrement l’ensemble des enseignants qui nous ont encadrés durant ce projet, car ils ont réellement fait de nous des techniciens supérieurs.