TFE_ESIS_AS 2016
CHAPITRE 3: CONCEPTION TECHNIQUE
3.1. Introduction
La conception générale nous a permis de
ressortir l'architecture générale de notre système, la
conception détaillée logique quant à elle, nous a permis
de détailler chacun des modules composant l'architecture
générale de notre système. La solution ainsi conçue
(globalement et en détail) peut être alors réalisée
dans les technologies disponibles.
3.1.1. Niveau d'abstraction
A ce stade, nous avons déjà franchi la
conception générale et la conception détaillée
logique, nous sommes arrivés au plus bas niveau d'abstraction de notre
conception.
Figure 3.1 niveau d'abstraction de la conception
technique
3.2. Choix technologiques 3.2.1. Critères de
choix
Les choix des différentes solutions technologiques ne
seront pas faits de façon arbitraire, nous allons faire recours à
la première partie de notre travail et plus précisément au
niveau des spécifications des besoins non fonctionnels, ces
dernières vont constituer nos critères de choix pour
différentes solutions technologiques, chaque critère vaut 5
points, ce qui fera un total de 45 points vu leur nombre qui est de 9. Les
solutions qui seront retenues seront celles qui auront les plus grandes cotes
sur 45.
TFE_ESIS_AS 2016
40
CONCEPTION TECHNIQUE
Voici donc nos critères de choix :
Critère 1 (C1) :
Utilisabilité, nous voyons la capacité pour un utilisateur
d'exécu-ter une tâche dans un temps donné après une
formation d'une durée déterminée ;
Critère 2 () : Stabilité, nous voyons par
là un système qui, une fois écarté de sa position
d'équilibre, il tend à y revenir ;
Critère 3 (C3) : Performance,
représente la capacité du système à avoir un temps
d'attente moindre (moins de 10 secondes) ;
Critère 4 (C4) : Disponibilité,
représente la capacité du système à tourner avec un
temps d'arrêt très réduit ;
Critère 5 (C5) :
Sécurité, nous voyons un système dont l'accès est
personnalisé et les connexions sécurisées ;
Critère 6 (C6) : Portabilité,
c'est la capacité d'un système d'être utilisable avec
plusieurs systèmes d'exploitation (plateformes) ;
Critère 7 (C7) : Simplicité de
mise en place, exprime la qualité du système d'être facile
à implémenter ;
Critère 8 (C8) : Fiabilité,
nous voyons par là un système critique, un système dont la
probabilité d'avoir des défaillances pendant le temps de
fonctionnement est moindre ;
Critère 9 (C9) : coût, nous
voyons une solution efficace pouvant être implémentée avec
un budget minimum.
Pour le choix de certaines solutions technologiques, nous ne
nous baserons pas que sur les neuf critères de choix mais plutôt
sur quelques critères qui seront déterminant et dans certains cas
nous donnerons juste les raisons qui nous ont motivé à choisir
une technologie par rapport à une autre.
3.2.2. Choix du gestionnaire des
configurations
Pour le choix du gestionnaire des configurations, plusieurs
solutions existent à l'heure actuelle, néanmoins nous avons
retenu quatre solutions technologiques, à savoir Chef, System Center
Configuration Manager (SCCM), Cfengine et Puppet.
Tableau 3.1 cotations des gestionnaires des
configurations
Critères
|
C1
|
|
C3
|
C4
|
C5
|
C6
|
C7
|
C8
|
C9
|
Total
|
Chef
|
3
|
3,5
|
4
|
3,5
|
3
|
3
|
2
|
3,5
|
4
|
29,5
|
SCCM
|
3
|
3,5
|
4
|
3,5
|
3
|
3
|
2
|
3,5
|
2
|
27,5
|
Cfengine
|
3
|
3,5
|
4
|
3,5
|
3
|
3
|
2
|
3,5
|
4
|
29,5
|
Puppet
|
4
|
3,5
|
4
|
3,5
|
3
|
3
|
2,5
|
3,5
|
4
|
31
|
|
Voici la représentation de ce tableau sous forme des
graphiques et courbes afin de permettre une très bonne vision :
TFE_ESIS_AS 2016
41
CONCEPTION TECHNIQUE
4,5
4 3,5 3 2,5 2 1,5 1 0,5 0
|
|
|
|
Figure 3.2 diagramme en bâtons
Chef SCCM Cfengine Puppet
Figure 3.3 diagramme en courbes
La solution technologique pour la gestion des configurations
retenue est donc Puppet qui l'emporte sur les autres avec un total de 31 points
sur 45 et elle intègre en elle un module de signature de certificat.
3.2.2.1. Présentation de Puppet
Puppet est un logiciel open source comportant les outils
nécessaires à la configuration des systèmes informatiques.
Il s'appuie sur un langage de programmation « Ruby » et est sous
licence GPL v2. Il a été principalement développé
par Luke KANIES et son entreprise Puppet Labs.
« KANIES a développé puppet grâce
à son expérience dans les systèmes Unix et les
systèmes d'administration depuis 1997. Non satisfait des outils de
configuration existants, il
TFE_ESIS_AS 2016
42
CONCEPTION TECHNIQUE
a commencé à travailler avec des outils de
développement en 2001, et a fondé Puppet Labs en 2005, une
entreprise de développement open source basée sur les outils
d'auto-matisation. Peu de temps après, Puppet Labs sort son nouveau
produit phare : Puppet. Il peut être utilisé pour gérer la
configuration d'application sous Unix et OSX, ainsi que Linux et Windows
». Cf. [16, p. 11]
Admin
Client
Echange de catalogue
SSH
HTTPS
Puppet Master
Demande de certificat
Echange de catalogue
Attribution de certificat
Tableau de
bord
Client
Echange de catalogue
Client
Figure 3.4 principe d'utilisation de puppet Son
modèle est basé sur trois piliers :
? Le déploiement ;
? Un langage de configuration et une couche d'abstraction ; ? Sa
couche transactionnelle.
3.2.2.2. Fonctions principales de Puppet
Etant un outil de déploiement et de gestion
automatisée de configurations et des systèmes informatiques. Il
repose sur un modèle client/serveur : un serveur central sert de
dépôt des configurations, les systèmes clients (noeuds) se
mettent à jour de manière manuelle ou automatique.
Avec Puppet, l'administrateur n'écrit pas un ensemble
d'opérations à exécuter sur les différents noeuds
sous la forme d'un script, l'administrateur décrit l'état final
de la machine dans un manifest, ce qui l'affranchit de la connaissance des
commandes propres à chaque système d'exploitation pour arriver
à cet état. Le client puppet peut être
exécuté plusieurs fois, les changements seront
opérés seulement si l'état de la machine ne correspond pas
à celui désiré.
TFE_ESIS_AS 2016
43
CONCEPTION TECHNIQUE
Configuration
language
Transaction Layer
Abstraction Layer
Ressources
Figure 3.5 fonctions principales de puppet
Puppet utilise son propre langage de déclaration pour
définir les points de configuration qui sont écrits dans une
« ressource », ce qui le distingue d'autres outils de gestion des
configurations. Ce langage permet de déclarer si un package doit
être installé ou si un service doit être lancé par
exemple.
La plupart des outils de gestion des configurations (script
shell ou pearl par exemple) sont procéduraux. Ils décrivent
comment les choses doivent être faites plutôt que de se focaliser
sur l'état final attendu. Les utilisateurs de puppet ont juste besoin de
déclarer l'état final voulu de ses hôtes : les packages
à installer, les services à exécuter, etc. Avec puppet,
l'administrateur n'attache pas d'importance sur comment ces actions vont
être faites.
Le moteur de puppet est sa couche transactionnelle, une
transaction puppet : ? Interprète et compile la configuration ;
? Communique la configuration compilée à l'agent ;
? Applique la configuration sur l'agent ;
? Rapporte le résultat de cette application au Master.
La première étape de puppet est celle
d'analyser la configuration et de calculer comment l'appliquer sur l'agent.
Pour cela, puppet crée un graphique représentant toutes les
ressources, ainsi que leurs relations entre elles et chaque agent. Puis il
applique chaque ressource sur un hôte. Ce qui est en fait une des
caractéristiques les plus puissantes de puppet.
Deuxièmement, puppet se sert des ressources et les
compile dans un catalogue pour chaque agent. Le catalogue est envoyé
à l'hôte et appliqué par l'agent puppet. Les
résultats de cette application sont renvoyés au Master sous forme
de rapport.
La couche transactionnelle permet aux configurations
d'être créées et appliquées indéfiniment sur
un hôte. Ceci est appelé « idempotent », cela signifie
que des multiples applications de la même opération donneront le
même résultat. Une configuration de puppet peut être
exécutée plusieurs fois sur un hôte en toute
sécurité avec le même résultat, assurant ainsi
à la configuration de rester compatible.
3.2.2.3. Manifests
Pour que Puppet fonctionne, nous devons lui dire quoi faire.
Ceci se fait grâce aux manifests.
TFE_ESIS_AS 2016
44
CONCEPTION TECHNIQUE
Les programmes de Puppet sont appelés « manifests
», et ils utilisent l'extension de fichier .pp. Le coeur du langage Puppet
est la déclaration des ressources, qui représente l'état
désiré d'une ressource.
Les manifests peuvent également utiliser des
instructions conditionnelles, un groupe des ressources dans des collections,
générer du texte avec des fonctions, référencer du
code dans d'autres manifests, et tant d'autres choses, mais tout revient en
dernière analyse à faire en sorte que les bonnes ressources
soient gérées de la bonne manière.
Avant d'être appliqués, les manifests sont
compilés dans le catalogue, qui est un graphe acyclique dirigé
qui ne présente que les ressources et l'ordre dans lequel elles doivent
être synchronisées. Toute la logique conditionnelle, la recherche
de données, l'in-terprétation de variables, et le regroupement de
ressources calculent l'écart lors de la compilation.
Parmi les manifests deux sont importants. Lorsque le client
consultera le Puppet Master, l'agent lira les fichiers dans un certain ordre
:
· Le fichier
/etc/puppet/environnement/nom-environnement/nom-du-mo-dule/manifests/site.pp
qui dit à Puppet où et quelle configuration charger
pour les clients. C'est également dans ce fichier que nous ferons la
déclaration des ressources, on spécifiera également
d'importer les « noeuds » ;
· Le fichier
/etc/puppet/nom-environnement/nom-du-module/mani-fest/node.pp
est lu lors de l'import. Dans ce fichier, nous renseignons les
FQDN des clients ainsi que les modules qui leurs sont associés.
3.2.2.4. Ressources
Une ressource est un élément que Puppet sait
configurer [19, p. 53] :
· File (contenu, permissions, propriétaire) ;
· Package (présence ou absence) ;
· Service (activation/désactivation,
démarrage/arrêt) ;
· Cron, group, host, user, etc.
Dans Puppet chaque ressource est identifiée par un
nom, elle est composée d'un certain nombre d'attributs qui ont chacun
une valeur.[20, p. 21]
3.2.2.5. Modules
Un module est une collection des manifests, ressources,
fichiers, templates, classes et définitions. Un simple module contiendra
tout ce qui est requis pour configurer une application particulière.
Chaque module a besoin d'une structure de répertoire spécifique
et d'un fichier appelé « init.pp ».
Cette structure autorise Puppet à charger automatiquement les modules.
Pour accomplir ce chargement automatique Puppet vérifie une série
de répertoires appelée le chemin du module (en anglais module
path). Ce chemin est configuré avec l'option de configuration du module
path dans la section [main] de « pup-pet.conf
».
TFE_ESIS_AS 2016
45
CONCEPTION TECHNIQUE
Par défaut, Puppet recherche les modules dans
/etc/puppet/modules et
/var/lib/puppet/modules. Si nécessaire on peut
rajouter d'autres chemins.
Un module est défini de la façon suivante :
1.
/etc/puppet/environnement/nom-environnement/nom-du-module/mani-fests/
:
· Le répertoire manifests contiendra le fichier
init.pp et tout autre configuration;
· Le fichier init.pp est le coeur du module et chaque
module doit en avoir un ;
· Dans le fichier init.pp nous retrouvons des classes
qui seront instanciées lors de l'appel d'un agent. Dans ces classes on
retrouve les configurations de référence.
2.
/etc/puppet/environnement/nom-environnement/nom-du-module/files/
:
Le répertoire files contiendra tous les fichiers que l'on
souhaite utiliser comme une partie du module, par exemple des fichiers à
uploader.
3.
/etc/puppet/environnement/nom-environnement/nom-du-module/tem-plates/
:
Le répertoire « templates » contiendra tous les
templates que le module pourrait utiliser.
3.2.3. Choix du gestionnaire de cycle de
vie
Le choix du gestionnaire de cycle de vie a été
porté sur Foreman « le contre maitre », il est
gratuit, open source, facile à mettre en place, bénéficie
d'une grande communauté et une grande documentation, il s'intègre
bien avec la majorité des gestionnaires des configurations.
Foreman offre les avantages ci-après [21]:
· Installation simple et automatique, il crée les
fichiers de configuration d'Apache, VHosts et tous les fichiers
nécessaires à son exécution ;
· Il peut être utilisé pour configurer les
noeuds, attribuer des classes et définir les paramètres des
classes ;
· Donne des rôles sur la base de données ;
· Offre une section des rapports avec des graphiques
montrant des détails comme les distributions de système
d'exploitation, pourcentage, les mémoires et architectures.
3.2.3.1. Présentation de Foreman
Foreman est un outil Open Source de gestion du cycle de vie des
serveurs physiques ou virtuels. De l'installation à la mise à
jour en continu, tout en passant par la configuration initiale de la machine,
Foreman s'occupe du cycle de vie de la machine. Foreman peut traiter les
rapports venant d'une, ou plusieurs, instances Puppet. Il peut
TFE_ESIS_AS 2016
46
CONCEPTION TECHNIQUE
fonctionner sur la plupart des systèmes d'exploitation
d'aujourd'hui. Cela, que ce soit avec une infrastructure sur site ou dans le
Cloud, privé ou public.
3.2.3.2. Fonctionnement
Foreman utilise un système des proxys intelligents
pour lancer ses actions sur les différents hôtes, il envoie ses
requêtes aux proxys intelligents exécutant les différentes
actions telles que l'allocation d'adresse, la gestion des appels puppet, etc.
Il nourrit une base de données et produit des rapports avec les
informations données par puppet et le tout est pilotable via une
interface web.
Admin
Puppet Master
Attribution de certificat
Echange de catalogue
Echange de catalogue
Client
Client
SSH
Foreman
communication
Demande de certificat
HTTPS
Echange de catalogue
Client
Figure 3.6 fonctionnement de Foreman avec Puppet
3.2.4. Architecture niveau physique
Après avoir effectué les différents
choix, nous avons retenu comme solutions technologiques à mettre en
place dans notre système : Puppet comme outil de gestion des
configurations, Foreman sera notre gestionnaire de cycle de vie qui contient en
son sein une base de données PostgreSQL, des proxy intelligents (TFTP,
DHCP, DNS).
Voici ce qu'est l'architecture du système avec les
différentes solutions technologies citées ci-haut :
TFE_ESIS_AS 2016
47
CONCEPTION TECHNIQUE
Serveur DHCP
Serveur TFTP
PostgreSQL
Serveur DNS
Puppet CA
Puppet
Foreman
Figure 3.7 architecture générale du
système au niveau physique
3.3. Procédures et planification
3.3.1. Procédures
d'installation
Plan sommaire :
· Procédure d'installation de puppet et foreman sur
le serveur ;
· Test d'installation de puppet et foreman sur le serveur
;
· Procédure d'installation de l'agent puppet sur le
client sous Ubuntu 14.04.2 LTS ;
· Procédure d'installation de l'agent puppet sur
le client sous CentOS 6.6. 3.3.1.1. Serveur sous Ubuntu 14.04.2 LTS
(PROC.INST.3.1)
a. Installation
Installer Puppet master et Foreman sur le serveur via les
commandes suivantes en mode root :
· Ouvrir le terminal ;
· Saisir la commande sudo su pour
se connecter en tant que root ;
· Saisir le mot de passe root et valider en appuyant sur la
touche enter ;
· Saisir successivement les commandes ci-après
pour installer les packages de puppet et foreman [22] :
apt-get -y install ca-certificates
wget
https://apt.puppetlabs.com/puppetlabs-release-trusty.deb
dpkg -i puppetlabs-release-trusty.deb
echo" deb http://deb.theforeman.org/ trusty
1.10"> /etc/apt/sources.list.d/foreman.list
TFE_ESIS_AS 2016
48
CONCEPTION TECHNIQUE
echo "deb http://deb.theforeman.org/ plugins
1.10">> /etc/apt/sources.list.d/foreman.list
wget -q
http://deb.theforeman.org/pubkey.gpg
-O- | apt-key add - apt-get update && apt-get -y install
foreman-installer foreman-installer
b. Test
· L'exécution de la dernière commande
(foreman-installer) nous servira de test, dans notre cas nous allons
personnaliser l'exécution de cette commande en définissant le
login et le mot de passe de connexion à Foreman de cette manière
:
foreman-installer
-foreman-admin-password=Id2303
Le résultat de cette commande devra être
l'impression des informations concernant l'URL38 pour accéder
à l'interface web de Foreman qui sera
https://kan-srvlub-foreman.kanacad.org,
le login qui sera admin et le mot de passe
Id2303, l'URL et le port du proxy intelligent qui
sera
https://kan-srvlub-foreman.kanacad.org:8443
et enfin le port par lequel fonctionne le puppetmaster qui est
8140.
3.3.1.2. Client Ubuntu 14.04.2 LTS
(PROC.INST.3.2)
Au niveau de ce client, la procédure sera la suivante
:
· Ouvrir le terminal ;
· Se connecter en tant que root en faisant sudo
su ;
· Saisir le mot de passe root puis valider ;
· Enfin télécharger le package de l'agent
puppet à partir du dépôt d'Ubuntu en passant par la
commande apt-get install puppet.
3.3.1.3. Client sous CentOS 6.6
(PROC.INST.3.3)
Sous CentOS la procédure n'est pas trop différente
de celle d'Ubuntu, elle se passe de cette façon :
· Ouvrir le terminal ;
· Saisir la commande su pour
passer en mode root ;
· Saisir le mot de passe du root et valider ;
· Saisir la commande rpm -ivh
http://yum.puppetlabs.com/puppetlabs-re-lease-el-6.noarch.rpm
suivi de la commande yum install puppet
afin d'installer le package de l'agent puppet. [23]
38 Uniform Resource Locator, en français
localisateur uniforme de ressource, désigne une chaîne de
caractères utilisée pour une adresser les ressources du World
Wide Web.
TFE_ESIS_AS 2016
49
CONCEPTION TECHNIQUE
3.3.2. Procédures de
configuration
Il est question ici de montrer les configurations que
prendront notre serveur et nos clients, mis à part cela, nous allons
montrer les différentes configurations des modules qui seront
déployés dans nos environnements.
Plan sommaire :
· Fixer les adresses IP en statique sur les serveurs et
même les clients ;
· Editer les fichiers hosts du serveur et des clients ;
· Tester les configurations ;
· Editer les fichiers hostname du serveur ainsi que des
clients ;
· Editer les fichiers puppet.conf sur le serveur et sur les
clients ;
· Créer les arborescences des modules qui seront
déployés sur le serveur (mysql, dhcp et apache), cette
arborescence sera fonction de l'environne-ment dans lequel il sera (production
ou développement) ;
· Créer les fichiers init.pp, install.pp,
config.pp, service.pp, node.pp et site.pp de chaque module ;
· Editer les fichiers fichiers init.pp, install.pp,
config.pp, service.pp, node.pp et site.pp de chaque module en fonction des
spécification de ce dernier ;
· Créer le domaine ;
· Créer le proxy intelligent ;
· Importer toutes les classes des différents
modules au niveau du gestionnaire de cycle de vie foreman ;
· Assigner les modules aux noeuds concernés.
3.3.2.1. Configuration du serveur sous Ubuntu 14.04.2 LTS
(PROC.CONF.3.1)
Son adresse IP sera fixée en éditant le fichier
interfaces dans le répertoire /etc/net-work et
se présentera de la façon suivante :
Figure 3.8 fixation de l'adresse IP du serveur
Le fichier hosts sera édité en
faisant nano /etc/hosts et aura comme informations,
l'adresse IP du serveur suivi du FQDN du serveur et enfin le nom du serveur.
Sur les autres lignes nous mettrons les adresses IP ainsi que les FQDN de tous
les noeuds que nous devrons gérer dans notre infrastructure [22]. Ce
fichier se présentera comme suit :
TFE_ESIS_AS 2016
50
CONCEPTION TECHNIQUE
Figure 3.9 configuration du fichier hosts du
serveur
Le fichier hostname quant à lui sera
édité en faisant nano /etc/hostname,
c'est dans ce fichier que nous renseignerons le FQDN du serveur [22].
Figure 3.10 configuration du fichier hostname du
serveur
Enfin nous éditerons le fichier puppet.conf se trouvant
dans puppet, à l'aide de l'éditeur nano, nous ferons
nano /etc/puppet/puppet.conf , nous mettrons la ligne
show_diff à la valeur
true, cela devra ressembler à ceci :
Figure 3.11 configuration du fichier puppet.conf du
serveur
Nous allons créer un domaine à partir de
l'interface web du gestionnaire de cycle de vie, il faudra d'abord se connecter
puis aller sur l'onglet : Infrastructure > Domaines > Nouveau
domaine puis saisir le nom kanacad et le nom complet
kanacad.org puis valider.
TFE_ESIS_AS 2016
51
CONCEPTION TECHNIQUE
Figure 3.12 création du domaine
Enfin nous créerons le proxy intelligent, il faudra
être connecté sur l'interface web du gestionnaire de cycle de vie,
aller sur l'onglet Infrastructure > Smart proxies > Nouveau
smart proxy puis saisir le nom du proxy intelligent (kanacad) et
son URL et port (
https://kan-srvlub-foreman.kanacad.org:8443).
Figure 3.13 création du proxy intelligent
3.3.2.2. Configuration du client sous Ubuntu 14.04.2 LTS
(PROC.CONF.3.2)
Dans le fichier interfaces nous renseignerons les
configurations IP via la commande nano
/etc/network/interfaces, cela se présente comme suit :
Figure 3.14 fixation de l'adresse IP du client
Ubuntu
Dans son fichier hosts via la commande nano
/etc/hosts, nous renseignerons l'adresse IP du serveur, son FQDN,
son nom et aussi l'adresse IP du client, son FQDN et son nom comme le montre la
figure suivante :
TFE_ESIS_AS 2016
52
CONCEPTION TECHNIQUE
Figure 3.15 configuration du fichier hosts du client
Ubuntu
Dans le fichier hostname, nous renseignerons le FQDN du client
comme suit :
Figure 3.16 configuration du fichier hostname du client
Ubuntu
Moyennant la commande nano
/etc/puppet/puppet.conf, nous éditerons le fichier de
configuration de notre client puppet en spécifiant le FQDN du serveur
maître de la façon suivante :
Figure 3.17 configuration du fichier puppet.conf du client
Ubuntu
3.3.2.3. Configuration du client sous CentOS 6.6
(PROC.CONF.3.3)
Fixer son adresse IP en éditant le fichier ifcfg de
l'interface eth0 moyennant la commande nano
/etc/sysconfig/network-scripts/ifcgf-eth0, ce qui donnera le
résultat suivant :
TFE_ESIS_AS 2016
53
CONCEPTION TECHNIQUE
Figure 3.18 fixation de l'adresse IP du client
CentOS
Editer le fichier hosts, pour y insérer l'adresse IP du
serveur et de notre client ainsi que leurs FQDN, cela se fait via la
commande nano /etc/hosts et se présente comme
suit :
Figure 3.19 configuration du fichier hosts du client
CentOS
Spécifier le FQDN du client en éditant son fichier
network en faisant nano /etc/sysconfig/network, le
fichier se présentera comme suit :
Figure 3.20 configuration du fichier network du client
CentOS
Enfin nous nous mettrons à configurer son fichier
puppet.conf afin de spécifier le FQDN de notre serveur en faisant
nano /etc/puppet/puppet.conf, ce fichier devra
ressembler à ceci :
TFE_ESIS_AS 2016
54
CONCEPTION TECHNIQUE
Figure 3.21 configuration du fichier puppet.conf du client
CentOS 3.3.2.4. Tests des configurations des paramètres IP
Nous allons dans un premier temps tester les configurations
des paramètres IP du serveur, du premier client et du deuxième
moyennant la commande ifconfig, le résultat de
ce test devra être l'affichage des paramètres IP tels que
l'adresse IP de l'hôte concerné, le masque ainsi que l'adresse de
broadcast du réseau.
Deuxièmement, nous allons vérifier que les
hostname de tous les noeuds correspondent bien à ce qui a
été décrit dans leurs configurations, ce test se fera en
faisant Ping $(hostname -f). Le résultat devra
être par exemple pour le client
kan-node1.kanacad.org :
Figure 3.22 résultat attendu après test de
l'hostname
3.3.2.5. Module MySQL
Nous allons premièrement créer une arborescence
pour notre module, ce dernier aura trois répertoires à savoir :
files, templates
et manifests. La commande pour créer cette
arborescence est : mkdir -p
/etc/puppet/environnement/production/mo-dules/mysql/{files, templates,
manifests}, ensuite nous créerons le fichier
init.pp avec la commande : touch
/etc/puppet/environnement/production/modules/mysql/mani-fests/init.pp.[17,
p. 19]
TFE_ESIS_AS 2016
55
CONCEPTION TECHNIQUE
Une fois l'arborescence créée nous nous mettrons
à éditer le fichier init.pp en important les autres fichier de
configuration à savoir install.pp, config.pp et service.pp et ensuite
créer une classe mysql et y ajouté les classes incluses comme
suit :
Figure 3.23 configuration du fichier init.pp du module
MySQL
Le fichier init.pp contiendra une seule classe appelée
mysql. A cela, on y ajoutera trois fichiers install.pp, config.pp et service.pp
contenant respectivement les classes mysql::install,
mysql::config et
mysql::service. La classe mysql demande au
puppetmas-ter d'exécuter les classes incluses.
Les trois fichiers devront se trouver dans le même
répertoire que le fichier init.pp. Le premier fichier (install.pp)
s'assurera que les paquets MySQL-server, MySQL-client et Phpmyadmin sont bien
installés.
Figure 3.24 configurations du fichier install.pp du module
MySQL
Il nous permettra aussi de créer un utilisateur MySQL et
un groupe MySQL auquel on donne les droits administrateurs sur MySQL.
Le second fichier, config.pp, utilisera la class
mysql::config. Cette dernière sera une classe de type « ressource
fichier ». Elle permettra de copier un fichier de configuration de MySQL
prédéfinie.
TFE_ESIS_AS 2016
56
CONCEPTION TECHNIQUE
Figure 3.25 configuration du fichier config.pp du module
MySQL
Le troisième fichier importé, service.pp servira
à vérifier si le service récemment installé
fonctionne ou est démarré.
Figure 3.26 configuration du fichier service.pp du module
MySQL
Dans le fichier site.pp qui nous permettra d'importer le noeud
concerné, nous aurons à l'éditer de cette façon
:
Figure 3.27 configuration du fichier site.pp du module
MySQL
Figure 3.28 configuration du fichier node.pp du module
MySQL
Dans le fichier node.pp nous spécifierons le noeud
concerné ainsi que le module qui lui sera associé, ce fichier
sera édité de la manière suivante :
TFE_ESIS_AS 2016
57
CONCEPTION TECHNIQUE
3.3.2.6. Module DHCP [24, p. 41]
Pour le module DHCP, la procédure sera la même
à la seule différence qu'ici le nom du module à saisir
lors de la création de l'arborescence sera dhcp et le nom de la classe
sera dhcp.
Pour le fichier init.pp, nous aurons à importer les
modules install.pp, config.pp et service.pp et la classe se présentera
comme suit :
Figure 3.29 configurations du fichier init.pp du module
DHCP
Le fichier install.pp de ce module, devra s'assurer que le
paquet soit installé, sa configuration se présentera donc de
cette manière :
Figure 3.30 configuration du fichier install.pp du module
DHCP
Figure 3.31 configuration du fichier config.pp du module
DHCP
La configuration du fichier config.pp de ce module se
présentera de la manière suivante :
TFE_ESIS_AS 2016
58
CONCEPTION TECHNIQUE
Le fichier service.pp du module DHCP s'assurera que le paquet
installé tourne, il aura la configuration suivante
Figure 3.32 configuration du fichier service du module
DHCP
Le fichier site.pp qui spécifie d'importer le fichier
node.pp qui détient le FQDN du noeud concerné par cette
configuration sera configuré de cette manière :
Figure 3.33 configuration du fichier node.pp du module
DHCP
Enfin, le fichier node.pp spécifie le FQDN du noeud qui
devra avoir les configurations décrites ci-haut, cela donnera comme
résultat ceci :
Figure 3.34 configuration du fichier node.pp du module
DHCP
3.3.2.7. Module Apache [24, p. 39]
La différence avec les deux modules
précédents se situe au niveau de l'environ-nement, les deux
premiers seront déployés dans l'environnement de production, par
contre celui-ci sera déployé dans l'environnement de
développement.
Le principe reste le même, créer l'arborescence
en faisant mkdir -p
/etc/puppet/environ-nement/developpement/modules/apache/{files, templates,
manifests}, ensuite dans le répertoire manifest
créer les fichiers init.pp, node.pp install.pp et enfin service.pp en
faisant
/etc/puppet/environnement/developpement/modules/apache/manifests
init.pp node.pp install.pp service.pp.
Le fichier se présentera de cette manière :
TFE_ESIS_AS 2016
59
CONCEPTION TECHNIQUE
Figure 3.35 configuration du fichier init.pp du module
Apache
Le fichier install qui nous permettra d'installer le package sur
le noeud concerné sera configuré de la façon suivante :
Figure 3.36 configuration du fichier install.pp du module
Apache
Le fichier service.pp nous permettra de vérifier si le
service apache tourne sur le noeud, il adoptera cette configuration [25, p.
28]:
Figure 3.37 configuration du fichier service.pp du module
Apache Le fichier node.pp se présentera de cette façon :
Figure 3.38 configuration du fichier site.pp du module
Apache
Enfin, le fichier node.pp sera édité et contiendra
le FQDN du noeud qui aura les configurations montrées dans les lignes
d'en haut aura cette présentation :
TFE_ESIS_AS 2016
60
CONCEPTION TECHNIQUE
Figure 3.39 configuration du fichier nodee.pp du module
Apache
Après avoir effectué toutes les configurations,
nous allons importer toutes les classes des différents modules sur notre
gestionnaire de cycle de vie, la procédure sera la suivante : aller sur
l'onglet Configurer > Classes > cliquer sur importer depuis
kanacad > cocher le module trouvés dans les
différents environnements > Faire la mise à
jour. [26, p. 49]
Figure 3.40 importation des classes puppet
3.3.3. Procédure des tests
3.3.3.1. Objectifs des tests
1. Déterminer que le système arrive à
déployer les configurations prévues pour les noeuds ;
2. Déterminer que le système arrive à
faire le monitoring, à avoir une vue globale, générer des
rapports, audits et statistiques concernant les différents noeuds.
3.3.3.2. Tests
1. Test du premier objectif a. Etapes du test
? Tester la connectivité entre tous les noeuds et le
serveur à l'aide de l'utilitaire Ping, il faudra pinger l'adresse IP du
serveur (Ping 10.137.68.23).
Le résultat attendu devra ressembler à ceci :
TFE_ESIS_AS 2016
61
CONCEPTION TECHNIQUE
Figure 3.41 résultat du test de connectivité
avec le serveur
· Créer les certificats numériques des
clients à l'aide de la commande puppet agent
-test, le résultat attendu devra être la
création d'un certificat SSL avec une empreinte de type SHA256
;
· Signer les certificats des clients au niveau du proxy
intelligent Puppet CA en allant dans l'onglet Configurer > Smart
proxies > certificats [26, p. 47];
· Modifier le fichier init.pp du module dhcp en mettant
en commentaire l'importation du fichier config.pp puis enlever la classe
incluse de ce dernier dans la classe principale dhcp. Affecter la classe
dhcp et dhcp :: service au
noeud
kan-node1.kanacad.org en
allant sur l'onglet Hôtes > tous les hôtes
> cliquer sur le nom du client (
kan-node1.kanacad.org)
> Modifier > Classes puppet puis affecter la classe
dhcp et dhcp::service, afin
de voir si le système arrive à déployer le service dhcp et
se rassurer que ce dernier est en service sur le noeud ;
· Affecter le module du client
kan-node2.kanacad.org, nous
procéderons en allant sur l'onglet Hôtes > tous les
hôtes > cliquer sur le nom du client (
kan-node2.kanacad.org)
> Modifier > Classes puppet puis affecter les
classes du module [23, p. 19] ;
· Synchroniser le serveur puis les noeuds qu'il
gère avec leurs états de configuration décrits sur
lui-même en faisant puppet agent -test sur les
noeuds à manager, le résultat devra être l'application des
configurations définies et le temps que l'agent puppet a pris pour
exécuter le catalogue du client sur lequel il est installé [27,
p. 32].
2. Test du deuxième objectif a. Etapes du test
· Aller sur l'onglet Hôtes > Tous
les hôtes, voir si tous les noeuds sont visibles. Le
résultat devra être un tableau reprenant le nom des hôtes,
le logo et la version du système d'exploitation, l'environnement, le
modèle, le groupe d'hôtes ainsi que le dernier rapport de chacun
de ses hôtes ;
· Aller sur l'onglet Surveiller > Tableau
de bord, voir si le système arrive à avoir les
statuts de configuration des hôtes et le diagramme de la configuration
des hôtes. Le résultat devra être le nombre d'hôte qui
ont effectué des changements sans erreurs, les hôtes en erreur,
les bons rapports dans les derniers 35 minutes, hôte en
TFE_ESIS_AS 2016
62
CONCEPTION TECHNIQUE
attente de changements, hôte
désynchronisés, hôte sans aucun rapport, hôte dont
les alertes sont désactivées ;
? Aller sur l'onglet Surveiller > Rapports
puis Hôtes > Tous les hôtes >
cliquer sur le nom d'un hôte >
Rapport, voir si le système arrive à
générer des rapports sur chaque hôte et même
l'ensemble du système. Le résultat devra être un tableau
reprenant le nom des hôtes ainsi que son rapport, pour chaque hôte
le résultat sera un tableau reprenant le nom de l'hôte sur lequel
nous visualisons le rapport ainsi que les indications sur l'application des
configurations ;
? Aller sur l'onglet Hôtes > Tous les
hôtes > cliquer sur le nom de l'un des
hôtes, voir si le système arrive à faire le monitoring
des noeuds gérés, le résultat sera un tableau reprenant
les informations sur le noeud concerné (statut du noeud, état de
configuration, nom de l'hôte, adresse IP, adresse MAC, architecture du
processeur, le nom du domaine, le nom du système d'exploitation ainsi
que l'environnement puppet dans lequel le noeud travail) ainsi que des
graphiques en rapport avec l'application des configurations [26, p. 11];
? Aller sur l'onglet Surveiller >
Statistiques, voir si le système génère des
statistiques. Le résultat devra être des diagrammes en camembert
décrivant en pourcentage les statistiques sur la mémoire, la
répartition des classes, la répartition des systèmes
d'exploitation, la répartition des environnements et l'architecture des
processeurs ;
? Aller sur l'onglet Surveiller >
Audits, voir si le système arrive à
générer un audit sur l'ensemble. Puis aller sur l'onglet
Hôtes > tous les hôtes >
cliquer sur le nom d'un noeud >
Audits. Le résultat devra être la
liste des actions apportées à l'ensemble du système et
l'autre sur un noeud spécifique.
3.3.4. Plan d'implémentation
La planification est l'action de planifier,
c'est-à-dire d'organiser dans le temps une succession d'actions ou
d'évènements afin de réaliser un objectif particulier,
dans notre cas, nous planifions l'implémentation.
Après avoir eu les procédures d'installation,
les procédures des configurations des différents modules ainsi
que celles de test, nous avons déjà réuni les informations
nécessaires pour entamer la phase d'implémentation. Sur ce
l'implémentation se passera comme suit :
? Créer les machines virtuelles en chargeant les
images systèmes dans VMware, une de type Ubuntu 14.04.2 LTS pour le
serveur, une autre du même type pour un client et enfin une image CentOS
6.6 pour le dernier client ;
TFE_ESIS_AS 2016
63
CONCEPTION TECHNIQUE
· Répliquer la connexion de la machine physique sur
les machines virtuelles ;
· Configurer les paramètres du serveur et de deux
clients (fichiers hosts et hostname) ;
· Installer puppet et foreman sur le serveur en suivant la
procédure d'installation et tester si elle a réussi ;
· Installer les agents puppet sur les clients en suivant
leurs procédures d'installation ;
· Configurer le serveur et les noeuds ;
· Tester les configurations des noeuds et serveur ;
· Editer le fichier puppet.conf du serveur ;
· Editer les fichiers puppet.conf des clients ;
· Créer l'arborescence des modules mysql, dhcp et
apache et les différents fichiers (init.pp, install.pp, config.pp,
service.pp, node.pp et site.pp ) nécessaires aux différents
modules sur le serveur ;
· Editer les fichiers init.pp, install.pp, config.pp,
service.pp, node.pp et site.pp de chaque module ;
· Se connecter à l'interface web de foreman et
créer un domaine ;
· Créer un nouveau proxy intelligent regorgeant le
TFTP, Puppet et Puppet CA ;
· Importer toutes les classes des différents modules
de puppet vers foreman ;
· Tester les communications entre les clients et le serveur
;
· Créer les certificats numériques des
clients des hôtes ;
· Signer les certificats à partir du proxy
intelligent dans foreman ;
· Modifier les hôtes en leur attribuant les classes
des modules qui leurs sont concernées ;
· Synchroniser le serveur puis les clients avec leurs
états des configurations définis sur le serveur ;
· Vérifier que les hôtes sont visibles ;
· Vérifie que le tableau de bord du système
est visible ;
· Vérifier que le système
génère les rapports sur l'ensemble du système et sur
chacun des noeuds ;
· Vérifier que le système fait le monitoring
des noeuds ;
· Vérifier que le système
génère les statistiques.
· Vérifier que le système
génère l'audit sur l'ensemble du système et sur chacun des
noeuds.
Toutes les étapes citées ci-haut ont une
durée de temps bien définie dans l'espace et dans le temps,
voilà pourquoi il s'est avéré important de faire un
diagramme de GANTT
TFE_ESIS_AS 2016
64
CONCEPTION TECHNIQUE
retraçant toutes les tâches qui seront
effectuées dans l'implémentation de telle sorte que rien ne soit
oublié.
65
CONCEPTION TECHNIQUE
Figure 3.42 extrait du diagramme de GANTT pour la
planification de l'implémentation
TFE_ESIS_AS 2016
TFE_ESIS_AS 2016
66
CONCEPTION TECHNIQUE
3.4. Conclusion Partielle
Sur la phase des spécifications des besoins et celle
de conception (logique et physique), nous avons suivi un processus de
développement dans lequel chaque cause qui intervenait dans le
système produisait un effet dans ce dernier, rien n'a été
mis au hasard. Dans ce chapitre nous avons planifié ce que nous ferons
durant la prochaine phase. Les résultats de ce chapitre sont les
procédures d'installation, les procédures de configuration du
serveur, des clients ainsi que leurs tests, les procédures des tests
globaux du système et enfin le plan d'implémentation de notre
système.
Dans la phase suivante de notre travail, nous n'allons plus
perdre du temps en réfléchissant sur la façon d'installer
le système, ni même la façon de le configurer ou tester,
tous ces aspects ont déjà été traités dans
l'abstraction.
| 
