|
Gestion des configurations d'un datacenter basée sur Puppet et Foreman( Télécharger le fichier original )par Israel MUKEYA KIONGO Ecole supérieure d'informatique Salama - Administration système et réseaux 2016 |
CHAPITRE 4: IMPLEMENTATION
4.2.1. Installations 4.2.1.1. Serveur sous Ubuntu 14.04.2 LTS Concernant la procédure d'installation de puppet et foreman, nous nous sommes connectés en tant que root sur le terminal, nous avons suivi la procédure d'installation qui avait été donnée dans le chapitre précédent, dès la première commande nous avons eu des messages d'erreurs. TFE_ESIS_AS 2016 67 IMPLEMENTATION Nous avons résolu le problème en faisant la mise à jour de tous les packages locaux du serveur en frappant la commande apt-get update [28, p. 23], ensuite nous nous sommes mis à suivre la procédure d'installation PROC.INST.3.1. Ensuite nous avons exécuté la commande foreman-installer qui a éditer le fichier puppet.conf et imprimer les informations utiles à foreman et puppet, nous avons personnalisé l'exécution de cette commande en y ajoutant le login qui est admin et le mot de passe qui sera utilisé pour la connexion comme représenté sur la figure suivante :
Figure 4.1 test d'installation de puppet et foreman Le résultat de cette commande imprime les informations sur l'URL que nous utiliserons pour nous connecter à l'interface web de foreman, le login et le mot de passe, l'URL du proxy foreman, voici en fait le résultat attendu :
Figure 4.2 résultat du test après exécution de foreman-installer 4.2.1.2. Client sous Ubuntu 14.04.2 LTS L'installation de l'agent puppet sur ce client n'a pas été un succès sur ce dernier vu les erreurs qui ont été générées lors de l'exécution de la commande spécifiée dans la procédure d'installation, du moins l'équivoque a été levée en faisant la mise à jour de la liste de tous les packages locaux de la machine via la commande apt-get update, enfin nous avons suivi la procédure PROC.INST.3.2. 4.2.1.3. Client sous CentOS 6.6 L'installation de l'agent puppet s'est effectué avec succès tout en respectant la procédure d'installation de ce client (PROC.INST.3.3). TFE_ESIS_AS 2016 68 IMPLEMENTATION 4.2.2. Configurations Pour la partie configurations, la conception technique nous a permis de prévoir les configurations nécessaires, dans cette partie présente nous avons pris les configurations prévues déjà à l'avance. 4.2.2.1. Serveur sous Ubuntu 14.04.2 LTS Sur le serveur la procédure de configuration est PROC.CONF.3.1, les tests prévus pour ce dernier ont réussi, les résultats de ces tests se présentent de la manière suivante :
Figure 4.3 résultat du test des paramètres IP du serveur Figure 4.4 résultat du test de vérification de l'hostname du serveur Les différents modules prévus ont été déjà créés, le module mysql et dhcp ont été placés dans l'environnement de production et apache dans l'environnement de développement du gestionnaire des configurations, nous les importerons depuis ce dernier vers le gestionnaire de cycle de vie Foreman. Nous allons tout d'abord lancer le navigateur et ensuite saisir dans la barre d'adresse l'URL de connexion à foreman comme suit :
Figure 4.5 connexion à l'interface web de foreman Apres lancement nous aurons l'interface web de foreman, il nous faudra saisir le login et le mot de passe :
TFE_ESIS_AS 2016 69 IMPLEMENTATION
Figure 4.6 interface d'accueil de foreman Nous allons d'abord créer un proxy intelligent, en suivant cette procédure : onglet Infrastructure > Smart proxies > Nouveau smart proxies et enfin saisir le nom et l'URL du proxy. Figure 4.7 informations du proxy intelligent TFE_ESIS_AS 2016 70 IMPLEMENTATION
Figure 4.8 résultat après création du proxy intelligent Ensuite nous créons un domaine, en allant sur Configurer > Domaines > Nouveau domaine et saisir le nom qui est kanacad et le nom complet kanacad.org.
Figure 4.9 création du domaine kanacad.org
Figure 4.10 importation des classes Après, nous allons sur l'onglet Configurer > Classes, cliquer sur Import depuis kanacad afin d'importer toutes les classes qui constituent les différents modules, ensuite cocher les modules et enfin faire la mise à jour. TFE_ESIS_AS 2016 71 IMPLEMENTATION
Figure 4.11 mise à jour des classes puppet Après avoir fait la mise à jour, nous aurons un tableau reprenant toutes les classes présentes dans les différents environnements de production et de développement (production et development) le tableau se présente de cette manière : 72 IMPLEMENTATION
TFE_ESIS_AS 2016 Figure 4.12 tableau des classes importées depuis puppet TFE_ESIS_AS 2016 73 IMPLEMENTATION 4.2.2.2. Client sous Ubuntu 14.04.2 LTS Les configurations prévues pour ce client (PROC.CONF.3.2) ont été appliquées et aucun problème ne s'est révélé. Le FQDN de ce client est kan-node1.kanacad.org et son adresse IP est 10.137.68.7. Voici donc les résultats des tests effectués sur ce client :
Figure 4.13 résultat du test de configurations des paramètres IP du client kan-node1 Figure 4.14 résultat du test de vérification de l'hostname du client kan-node1 4.2.2.3. Client sous CentOS 6.6 Nous avons appliqué la procédure prévue (PROC.CONF.3.3) pour ce client et le résultat sont les suivant :
Figure 4.15 résultat de test de configuration des paramètres IP du client kan-node2 TFE_ESIS_AS 2016 74 IMPLEMENTATION
Figure 4.16 résultat du test de l'hostname du client kan-node2 4.3. Tests et résultats 4.3.1. Premier objectif 4.3.1.1. Test des connectivités entre clients et serveur Premièrement nous avons testé la connectivité du client kan-node1 avec le serveur en faisant un Ping sur l'adresse IP du serveur, le test a réussi et voici le résultat :
Figure 4.17 résultat du test de connectivité entre le client kan-node1 et le serveur Enfin le test de connectivité entre le deuxième client kan-node2 et le serveur a également réussi, voici le résultat :
Figure 4.18 résultat du test de connectivité entre le client kan-node2 et le serveur 4.3.1.2. Création des certificats Premièrement, nous allons procéder à la création du certificat numérique du client kan-node1.kanacad.org afin de sécuriser les communications entre ce dernier et le serveur de gestion des configurations de notre infrastructure. Il nous faudra saisir la commande puppet agent -test. Le résultat se présente comme suit : TFE_ESIS_AS 2016 75 IMPLEMENTATION
Figure 4.19 création du certificat sur le client kan-node1 Ensuite, nous allons créer le certificat numérique de ce client à l'aide de la commande puppet agent --test. Le résultat de cette dernière donne ceci :
Figure 4.20 création du certificat sur le client kan-node2 4.3.1.3. Signature des certificats Au niveau du serveur, nous nous connectons en tant que root et nous saisissons la commande puppet cert -list pour voir la liste des certificats en attente de signature ainsi que l'empreinte de ce dernier qui est de type SHA256. Voici à quoi ressemble le résultat attendu :
Figure 4.21 liste des certificats en attente de signature sur le serveur Nous avons bien vu le certificat numérique au niveau de puppet, maintenant il faudra signer ce certificat au niveau de foreman en passant par le proxy intelligent Puppet CA, le chemin est le suivant : infrastructure > smart proxy > certificats, voir la liste et cliquer sur signer. TFE_ESIS_AS 2016
76 IMPLEMENTATION
Figure 4.22 procédure de signature des certificats Figure 4.23 signature de certificat du client kan-node1 Figure 4.24 signature de certificat du client kan-node2 4.3.1.4. Affectation des modules aux noeuds A présent, nous allons modifier le noeud kan-node1.kanacad.org afin de lui affecter la classe dhcp et dhcp::service. La modification a réussi et a donné le résultat suivant : TFE_ESIS_AS 2016 77 IMPLEMENTATION Figure 4.25 inclusion des classes dhcp et dhcp :: service Nous allons modifier l'hôte kan-node2.kanacad.org en lui attribuant le module apache qui se trouve dans l'environnement de développement du gestionnaire des configurations Puppet. Le résultat se présente comme suit :
Figure 4.26 inclusion des classes du module Apache 4.3.1.5. Synchronisation des états des configurations des noeuds
Figure 4.27 résultat du test de synchronisation du serveur kan-srvlub-foreman Le serveur n'a pas eu de module qui lui a été assigné, du moins pour qu'il n'ap-paraisse pas en erreur au niveau du tableau de bord, il s'avère nécessaire de le synchroniser aussi, le test a réussi et le résultat se présente comme suit : TFE_ESIS_AS 2016 78 IMPLEMENTATION Pour la synchronisation du deuxième client, nous avons commencé par modifier le fichier init.pp comme indiqué dans la procédure.
Figure 4.28 modification du fichier init.pp du module dhcp Le résultat de la synchronisation du premier client avec son état de configuration a réussi, le package dhcp est présent sur le noeud et tourne sur ce dernier, voici le résultat de ce test :
Figure 4.29 résultat du test de synchronisation du client kan-node1
Figure 4.30 résultat du test de synchronisation du client kan-node2 Le test sur le client kan-node2 n'a pas réussi suite à un problème lié au système de fichier survenu sur ce dernier, voici le résultat émanant de ce test : 79 IMPLEMENTATION 4.3.2. Deuxième objectif 4.3.2.1. Visualisation des hôtes Le test pour la visualisation des noeuds que nous gérons a réussi, à travers l'onglet Hôtes puis tous les hôtes nous savons visualiser tous les noeuds, voici comment se présente le résultat :
Figure 4.31 résultat de test pour la visualisation des noeuds gérés TFE_ESIS_AS 2016 TFE_ESIS_AS 2016 80 IMPLEMENTATION 4.3.2.2. Visualisation du tableau de bord Le résultat pour la visualisation du tableau de bord à travers les onglet spécifiés au niveau des procédures de test a réussi, le résultat est le suivant :
Figure 4.32 résultat du test pour la visualisation du tableau de bord TFE_ESIS_AS 2016 81 IMPLEMENTATION 4.3.2.3. Visualisation des rapports
Figure 4.33 résultat du test de visualisation du rapport global 82 IMPLEMENTATION
Figure 4.34 résultat du test de visualisation du rapport d'un noeud TFE_ESIS_AS 2016 TFE_ESIS_AS 2016 83 IMPLEMENTATION 4.3.2.4. Monitoring d'un noeud Pour voir si le système arrive à offrir un monitoring sur les noeuds gérés nous avons fait un test, ce dernier comme indiqué au niveau des procédures des tests, nous avons navigué dans les onglets spécifiés antérieurement, voici le résultat :
Figure 4.35 résultat du test de monitoring d'un hôte TFE_ESIS_AS 2016 84 IMPLEMENTATION 4.3.2.5. Visualisation des statistiques Nous avons navigué dans les onglets indiqués au niveau des procédures de test pour visualiser les statistiques, le test a réussi et a donné ceci :
Figure 4.36 résultat du test de visualisation des statistiques 85 IMPLEMENTATION 4.3.2.6. Visualisation de l'audit Le test pour la visualisation de l'audit a été un succès, voici comment se présente le résultat de ce test :
Figure 4.37 résultat du test de visualisation de l'audit sur l'ensemble du système TFE_ESIS_AS 2016 86 IMPLEMENTATION Le résultat de l'audit sur un noeud spécifique se présente comme suit :
Figure 4.38 résultat du test de visualisation de l'audit sur un noeud TFE_ESIS_AS 2016 87 IMPLEMENTATION 4.4. Conclusion partielle 4.4.1. Evaluation des besoins 4.4.1.1. Besoins fonctionnels Tableau 4.1 évaluation des besoins fonctionnels
TFE_ESIS_AS 2016 88 IMPLEMENTATION 4.4.1.2. Besoins non fonctionnels Tableau 4.2 évaluation des besoins non fonctionnels
TOTAL 97,77% TFE_ESIS_AS 2016 TFE_ESIS_AS 2016 89 IMPLEMENTATION
0 0 0 0 100 100 100 100 100 100 100 100 66,66666667 Figure 4.39 graphique d'évaluation des besoins fonctionnels
PF-NF-01 PF- NF- 02 95 90 PF- NF- 03 98 PF- NF- 04 99 PF- NF 05 98 PF- NF- 100 100 100 100 06 PF- NF- 07 PF- NF- 08 PF- NF- 09 97,77777778 TOTAL Figure 4.40 graphique d'évaluation des besoins non fonctionnels En bref, nous avons implémenté le système tel que prévu au niveau de la conception technique qui est en fait la matérialisation de toute la conception logique de notre système, seules 66,66% des fonctionnalités ont été implémentées par rapport à l'ensemble des toutes les fonctionnalités ou tous les besoins fonctionnels. TFE_ESIS_AS 2016 |
|
