Cas d’étude d’une architecture de containérisation et de la haute

disponibilité des services

Après l’analyse de l’état actuel de l’entreprise DESALLE, vous contactez pour

réaliser une infrastructure de conteunérisation et de haute disponibilité. Votre travail consiste
à mettre sur pied une infrastructure plus adéquate en vue d’assurer la communication interne
et le travail collaboratif au sein de l’entreprise enfin customisé la solution selon les besoins
de l’entreprise. Le cahier de charges ci-dessous présente les besoins et les contraintes de
l’entreprise.

1. CAHIER DE CHARGES
1.1. Contexte
Le Groupe DELASALLE est un ensemble de deux entreprises et d’une association
exerçant dans le domaine de l’informatique. Notre stage a été effectué dans l’entreprise
DELASALLE. Dans cette dernière, nous avons réalisé une étude sur le fonctionnement
interne de l’entreprise ainsi que sur son système informatique. Nous avons à cet effet soulevé
un certain nombre de points faibles.
Il s’agit notamment de l’absence d’une plateforme favorisant la communication interne de
l’entreprise, l’utilisation des applications grand public pour effectuer des réunions en audio
et vidéoconférence, la rédaction et l’envoi des rapports journaliers et Dashboards de façon
fastidieuse, l’absence d’une source centralisée pour le stockage des données. De plus, nous
avons constaté l’absence d’une source d’alimentation redondance qui entrainait
l’indisponibilité du système informatique en cas de coupure d’énergie électrique. Enfin, le
fait qu’en en cas de déplacement l’employer ne puisse pas avoir accès aux services et
informations de l’entreprise constitue un réel frein au télétravail. Il nous a donc été confié la
tâche de mettre sur pied une plateforme hautement disponible avec un minimum de
ressources informatiques qui sera en mesure de pallier à ces différentes préoccupations.

3.1.2. Problématique
Au regard des multiples limites que peut présenter la communication au sein d’une
entreprise, le stockage des données, l’accès distant aux services et données de l’entreprise et
la gestion des rapports journaliers, nous nous posons des questions suivantes :

• Comment assurer une bonne communication, le travail collaboratif et le

télétravail entre les employés d’une entreprise via des moyens numériques en
 minimisant les ressources informatiques tout en assurant la haute disponibilité des
services ?
• Comment centraliser les données d’une entreprise ?
Afin de répondre à cette problématique, nous nous sommes fixés un certain nombre
d’objectifs bien précis qui orienteront notre travail.

1.3. Objectifs
L’objectif principal de notre travail est de mettre en place une plateforme hautement
disponible et sécurisée en vue de faciliter la communication interne, le travail collaboratif et
le télétravail entre les employés de DESALLE. De cet objectif principal, découle plusieurs
objectifs secondaires. On peut citer :

• La centralisation des données et de l’authentification de des utilisateurs l’entreprise ;

• L’unification de l’accès aux outils de communication interne (messagerie instantanée,
messagerie électronique, audio et vidéoconférence, partage et synchronisation des fichiers)
;
• Mettre en place des outils de travail collaboratif pour faciliter la gestion de projet ;
• Gestion des rapports journaliers ;
• Mise en place des services de messagerie instantanée, vidéoconférence, de partage et de
synchronisation de fichiers ;
• Economiser les ressources informatiques ;
• Assurer la haute disponibilité des services ;
• Assurer l’accès aux services d’entreprise indépendamment de la localisation
géographique ;
• Gestion des droits sur les fichiers ;
• Assurer la portabilité des services et des données.

Les atteintes de ces objectifs sont gouvernées par un certain nombre de contraintes.

1.4. Contraintes
Pour la réalisation de ce travail, la contrainte majeure a été au niveau des ressources
informatiques très limitées de l’entreprise. En effet, la structure ne disposait que d’un PC qui
fera office de serveur pour la mise en place de notre architecture. De plus le respect des dates
d’échéance pour chaque lot de travail car nous ne disposions pas d’assez de temps compte
tenue de la période de stage relativement courte.
Comme tout projet, la mise en place de notre plateforme nécessite un ensemble de ressources
humaines, matérielles et logicielles à savoir :

1.5. Outils

3.1.5.1. Ressources logicielles

Les ressources logicielles dont nous avons besoin et leur rôle sont présentées dans le
tableau suivant :

Tableau 3. 1: Ressources logicielles pour la réalisation du projet

Ressources logiciels Rôles
Un hyperviseur à barre de métal C’est un logiciel qui permet de créer et d'exécuter des
VMware EXSI machines virtuelles. Dans notre cas, il nous permettra
de créer et d’exécuter sur notre unique serveur les
machines virtuelles qui feront office de nœuds du
cluster.

Le système d’exploitation CENTOS C’est le système d’exploitation par-dessus lequel on

7 installera docker. Il sera installé sur toutes les
machines constituant les nœuds du cluster.
Les images dockers relatives à notre Ce sont elles qui nous fournissent les applications
solution nécessaires l’implémentation de notre solution dans
un environnement de conteneurisation.
Un nom de domaine C’est la chaîne de caractères que les utilisateurs
entrent dans la barre de recherche du navigateur afin
d’avoir accès aux services. Elle correspond à une
adresse IP bien précise.
Adresse IP publique C’est l’adresse IP qui permet de rendre les services
informatiques accessibles de l’extérieur.
Connexion internet Elle permettra te télécharger les images docker.

1.5.2. Ressources matérielles

Comme ressource matérielle, nous pouvons citer entre autres :

 Tableau 3. 2: Ressources logicielles pour la réalisation du projet
Ressources Rôles
matérielles

Un serveur C’est lui qui offrira les services d’intranet aux utilisateurs.
Un routeur Il permet la communication entre le réseau local et Internet.
Un switch Il permet d’interconnecter les ordinateurs, serveurs ou tout autre
équipement physique appartenant à un même réseau physique.

Des câbles réseau Il assure la connexion entre les équipements réseau de l’entreprise.
Un onduleur Il permet, en cas de coupure d'électricité, de prendre le relais avec
ses batteries et alimenter vos appareils en électricité.

Un Groupe Il permet de fournir une source d’électricité de secours pour les

diverses activités requérant de l’électricité, en l’absence d’une
électrogène
alimentation classique au secteur.

Des ordinateurs Ce sont les utilisateurs de notre plateforme

2. Choix des différentes solutions

En ce qui concerne les solutions Cloud et d’intranet, notre choix s’est porté sur Nextcloud.
Ceci est dû au fait qu’il soit totalement gratuit, sécurisé avec de multiples fonctionnalités qui
répond parfaitement aux attentes de notre projet en termes de coûts. De plus, les fonctionnalités
de Nextcloud répondent mieux aux exigences de notre projet à savoir : une plateforme de travail
collaboratif, de communications unifiées, de gestion et de stockage de fichiers, de gestion des
documents avec l’intégration des tableurs, des outils de coédition de document ainsi que les
logiciels de présentation. Enfin, pour des fonctionnalités moindres, Owncloud exige un pack
entreprise payant. En ce qui concerne l’environnement de haute disponibilité et de
conteneurisation, nous avons opté pour docker Swarm au détriment de Kubernetes pour
plusieurs raisons. Tout d’abord, Docker Swarm se révèle plus simple à utiliser que Kubernetes
dû au fait qu’il soit directement intégré au moteur de docker. Ce qui facilite son installation et
sa configuration Ensuite, docker Swarm possède un répartiteur de charge intégré permettant de
distribuer les requêtes aux différents nœuds du cluster. Or avec Kubernetes, l’installation d’un
répartiteur de charge externe est nécessaire afin d’assurer cette fonction. Enfin, il est adapté
aux petites charges de travail. Le choix de la solution ainsi fait, nous allons passer à la
conception de l’architecture qui devra abriter cette solution.
 3. Architecture de la solution et plan d’adressage du cluster de haute
disponibilité
La figure suivante présente l’architecture de notre solution.

Figure 3. 1: Architecture de la solution

A l’architecture existant, nous avons ajouté un serveur physique qui abritera les
différents services de l’entreprise, un groupe électrogène et un onduleur dans le but d’assurer
la continuité du fonctionnement du système informatique en cas de coupure d’énergie
électrique. La figure suivante présente la disposition logicielle interne de notre serveur.
 Figure 3. 2 : Structure logicielle interne du serveur

L’hyperviseur VMware permet de créer les machines virtuelles du cluster de haute

disponibilité. Ce cluster est constitué de trois machines virtuelles dont le plan d’adressage est
présenté par tableau suivant :

Tableau 3. 4: Plan d’adressage du cluster de haute disponibilité

Machine virtuelle Adresse IP Masque de sous réseau

Master 192.168.8.104 255.255.2550

Worker1 192.168.8.103 255.255.255.0

Worker2 192.168.8.105 255.255.255.0

De plus tous les nœuds ou machines virtuelles du cluster ont les caractéristiques suivantes :
 Tableau 3. 5: Caractéristiques des nœuds du cluster
Caractéristiques Valeurs

RAM 4GO pour le nœud master

2GO pour chaque nœud worker
Disque dur 300GO

CPU 3

Système d’exploitation Centos 7

Les conteneurs qui exécutent sur ces différents nœuds contiennent les images docker
de notre solution. Il est donc important de présenter ces images que nous avons choisies en
spécifiant leurs rôles et fichier de configuration.

4. Présentation des images docker nécessaires

La mise en place de notre solution dans un environnement de conteneurisation exige
le téléchargement de plusieurs images docker. Afin de mieux nous édifier sur le rôle de
chacune d’elles, nous avons conçu le tableau suivant :

Tableau 3. 6: Présentation des images docker nécessaires à la réalisation du projet.

Images docker rôle Volumes persistants

Nextcloud Plateforme d’intranet et /var/www/html : dossier de mises à jour du service

de cloud privé nextcloud
/var/www/html/custom_apps : contient les applications
installées sur la plateforme
/var/www/html/config : fichiers de configuration de
Nextcloud.
/var/www/html/data : les données réelles de votre
Nextcloud.
/var/www/html/themes/<YOUR_CUSTOM_THEME>
: thème/image de marque pour la customisation de
l’interface graphique de Nextcloud. [24]
mariadb MariaDB Server est /var/lib/mysql : contient les données du serveur de base de
une base de données données. [25]
relationnelle open
source hautement
performante, dérivée de
MySQL. Il assure le
stockage des données.
 letsencryptnginx- Conteneur LetsEncrypt - etc/nginx/certs:rw : stockes les certificats et clés
est utilisé comme privés
serveur proxy. Il gère la
création,
proxycompanion le renouvellement et - /etc/nginx/vhost.d:rw : contient les fichiers de
l’utilisation des configuration des hôtes virtuelles (techniques permettant
certificats d’héberger plusieurs noms de domaine sur un même
LetsEnccrypt pour les serveur dédié).
conteneurs Docker - /usr/share/nginx/html:rw : contient les fichiers de
proxy challenges http-01 [23].
jwilder nginx- Proxy inverse Nginx - /etc/nginx/conf.d : contient le fichier de
proxy automatisé pour les configuration par défaut du serveur nginx
conteneurs Docker. - /etc/nginx/vhost.d:rw : contient les fichiers de
Nginx est le serveur configuration des hôtes virtuelles (techniques permettant
Web permettant de d’heberger plusieurs noms de domaine sur un même serveur
fournir une interface dédié).
Web à l’utilisateur. - /usr/share/nginx/html:rw : contient les fichiers de
challenges http-01.
- /etc/nginx/certs:ro : stocke les certificats et clés
privés [22].

Les images dockers ainsi présentées, nous allons passer à la conception proprement
dites de notre solution qui consiste à exécuter les conteneurs grâce aux images docker situées
ci-dessus via la rédaction d’un fichier YAML.

5. Rédaction des scripts du docker compose

C’est le squelette de notre solution car il contient toutes les images docker de notre
solution, la configuration des volumes persistants, du réseau utilisé par les conteneurs et les
variables d’environnement nécessaires au fonctionnement de ces images. Pour le faire, nous
utiliserons l’outil docker-compose de docker qui permet de définir et d’exécuter les
applications docker multiconteneurs. Nous écrirons un fichier YAML pour la configuration
de nos différents services.

version: '3.7' # version du docker-compose

services: # section de déclaration des services
proxy:
image: jwilder/nginx-proxy:alpine # nom de l’image
labels:
- "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true"
container_name: nextcloud-proxy# nom du conteneur proxy networks:
- nextcloud # réseau utilisé par le service proxy ports: # déclaration et mappage des
ports
 - 80:80 # port utilisé pour http - 443:443# port utilisé pour https volumes: #
déclaration et mappage des volumes utilisés par l’image proxy - nginx:/etc/nginx/conf.d
- vhost:/etc/nginx/vhost.d:rw
- html:/usr/share/nginx/html:rw
- certificats:/etc/nginx/certs:ro
- /etc/localtime:/etc/localtime:ro
- /var/run/docker.sock:/tmp/docker.sock:ro
deploy: # paramètres de déploiement du service sur le cluster
swarm mode: replicated replicas: 3 # nombre de
réplicas du service sur le cluster restart_policy: # politique
de redémarrage du service
condition: on-failure # condition de redémarrage du service en cas d’échec
letsencrypt:
image: jrcs/letsencrypt-nginx-proxy-
companion container_name: nextcloud-
letsencrypt depends_on: - proxy
networks: - nextcloud volumes:
- certificats:/etc/nginx/certs:rw
- vhost:/etc/nginx/vhost.d:rw
- html:/usr/share/nginx/html:rw
- /etc/localtime:/etc/localtime:ro
- /var/run/docker.sock:/var/run/docker.sock:ro deploy: mode: replicated
replicas: 3 restart_policy: condition: on-failure db:
image: mariadb
container_name: nextcloud-
mariadb networks:
- nextcloud volumes:
- db:/var/lib/mysql
- /etc/localtime:/etc/localtime:ro
environment: #déclaration des variables d’environnemt
- MYSQL_ROOT_PASSWORD=toor # mot de passe administrateur de la base de
données
- MYSQL_PASSWORD=mysql # mot de passe de la base de données
- MYSQL_DATABASE=nextcloud # nom de la base de données
- MYSQL_USER=nextcloud # nom d’’utilisateur de la base de données
deploy:
mode: replicated
replicas: 3
restart_policy:
condition: on-failure
app: image:
nextcloud:latest
container_name: nextcloud-
app networks: -
nextcloud depends_on:
- letsencrypt
- proxy
 - db volumes: - nextcloud:/var/www/html
- config:/var/www/html/config
- custom_apps:/var/www/html/custom_apps
- data:/var/www/html/data
- themes:/var/www/html/themes - /etc/localtime:/etc/localtime:ro environment:
- VIRTUAL_HOST=nextcloud.madia.local
- LETSENCRYPT_HOST=nextcloud.madia.local -
LETSENCRYPT_EMAIL=keoupaule@gmail.com deploy: mode: replicated
replicas: 3 restart_policy: condition: on-failure volumes: #
déclaration des volumes persistants nextcloud:
external: true # spécification du type de volume « externe
» db:
external: true
nginx:
external:
true
vhost:
external:
true
certificats:
external: true
html:
external:
true
config:
external:
true
custom_app
s:
external:
true data:
external:
true
themes:
external:
true network
-nextcloud
driver : bridge

Ce script décrit les commandes à exécuter pour mettre en marche les différents
services nécessaires au fonctionnement de notre plateforme. Le premier est le service « proxy
». Il utilise l'image de jwilder/nginx-proxy. L’option « Labels » est utilisé pour spécifier que
le conteneur Let's Encrypt sera utilisé afin de générer les certificats pour le conteneur proxy.
La section « Volumes » est utilisée par le conteneur pour configurer l'hôte virtuel Nginx et
accéder aux certificats générés par le conteneur compagnon Let's Encrypt. Ensuite, on a le
service let’sEnscrypt qui assure la génération automatique des certificats SSL. Il utilise
exactement les mêmes volumes le conteneur proxy afin qu’il génère les certificats dans /etc
/nginx/certs. Ces certificats seront utilisés par le service proxy afin de sécuriser les échanges
d’informations entre le serveur Web et le client http.
Le service db est le suivant. Il utilise l’image Mariadb. Mariadb est le moteur de bases de
données qui va nous permettre de sauvegarder les métadonnées et données des utilisateurs.
Elle dispose de plusieurs variables d’environnement : le nom de la base de données, le nom
d’utilisateur et le mot de passe que le service Nextcloud utilisera pour utiliser les informations
de la base de données. Enfin, nous avons défini le service Nextcloud. Pour qu’il fonctionne
correctement, nous l’avons lié à la base de données MariaDB et définit le volume Nextcloud.
Ce volume permet d’éviter une perte de données occasionnée par le redémarrage du
conteneur. Nous avons mappé le port 80 du serveur sur le port 80 du conteneur, mettant ainsi
sur pied une permettant aux hôtes de se connecter au service via le port 80.