# Déploiement continu et architecture serveur

## <a name="_Toc77773356"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;"><span style="font: 7.0pt 'Times New Roman';"> </span>I.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Introduction

### <a name="_Toc77773357"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">1.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Ressources utilisés

#### <a name="_Toc77773358"></a>Organisation Github

Afin de gérer au mieux les différents projets que nous avions à réaliser, nous avons créé une organisation sur Github afin de regrouper tous les projets à un seul endroit. L’organisation s'appelle Vécolo Project [https://github.com/vecolo-project](https://github.com/vecolo-project)

#### <a name="_Toc77773359"></a>Serveur VPS

L'intégralité de nos applications et base de données sont hébergées sur un serveur VPS sur lequel pointe le domaine [vecolo.fr](https://vecolo.fr)

Le serveur possède 2 processeurs virtuels cadencés à 2.60 GHz, 2go de RAM, 30go d’espace de stockage en RAID10 ainsi qu’un connexion internet de 100 Mbps.

#### <a name="_Toc77773360"></a>Raspberry PI 4

Nous avons un besoin spécifique qui est que nous devons simuler des station de recharge de vélo un peu partout dans Paris. Pour ce faire nous utilisons une Raspberry PI 4 car celle-ci possède un processeur ARM, c'est ce qui se rapproche le plus du futur composant embarqué sur de vraies stations de recharge.

Elle embarque un processeur ARM 4 cœurs 64bits cadencés à 1.5 GHz, 4go de RAM et 32go d’espace de stockage.

Nous possédons physiquement cette Raspberry et elle est hébergé physiquement chez nous.**<span style="font-size: 14.0pt; mso-bidi-font-size: 11.0pt; line-height: 110%; mso-fareast-font-family: HGMinchoE; mso-fareast-theme-font: major-fareast; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: major-bidi; text-transform: uppercase;"> </span>**

### <a name="_Toc77773361"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">2.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Technologies phares

#### <a name="_Toc77773362"></a>Docker Swarm &amp; Portainer

Docker est un outil qui peut empaqueter une application et ses dépendances dans un conteneur isolé, qui pourra être exécuté sur n'importe quel serveur. Cela est très utile pour déployer et maintenir des applications sur un serveur sans conflits de dépendances.

Portainer est une interface web permettant d’avoir une meilleure gestion de docker sur un serveur, cela permet d’administrer toute nos instances sans avoir à utiliser un terminal.

#### <a name="_Toc77773363"></a>Registre Docker privé

Un registre docker est un espace de stockage où mettons à dispositions les images docker de nos différentes application. Le fait qu’il soit privé signifie qu’il n’est pas accessible publiquement et peut être auto hébergé.

#### <a name="_Toc77773364"></a>MariaDB

MariaDB est un système de gestion de base de données. Il s'agit d'un fork communautaire de MySQL. C’est dans cette base de données que nous stockons toute les données relative à Vécolo, le monitoring des applications et le Schéma BDD de l’application Java Vekanban.

#### <a name="_Toc77773365"></a>Grafana

Grafana est un logiciel libre qui permet la visualisation de données. Il permet de réaliser des tableaux de bords et des graphiques principalement depuis des bases de données temporelles. Il est très souvent utilisé pour faire du monitoring d’applications serveurs.

#### <a name="_Toc77773366"></a>Github Actions

Les actions Github sont des procédures automatiques qui peuvent être lancés lorsque différentes actions sont lancées sur un dépôt Github (push, merge, pull request, …). Elles permettent de lancer différentes actions en relation avec le code (exécution des tests unitaires, compilation de l’application, notifications via webhooks, …) ;

#### <a name="_Toc77773367"></a>Caddy

[Caddy](https://caddyserver.com) est un serveur web écrit en G. Il a été conçu à l’ère du web sécurisé et il fonctionne ainsi par défaut et fourni du https, sauf si c’est demandé explicitement de ne pas le faire.

Il se chargera tout seul d’obtenir un certificat Let’s Encrypt et de le renouveler ensuite sans intervention manuelle. Il se chargera aussi de rediriger toutes les requêtes vers l’adresse en https, là encore sans configuration spécifique.

### <a name="_Toc77773368"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">3.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Architecture Globale

Voici le schéma d'architecture globale de notre projet que nous allons détailler dans ce rapport :

[![Image1.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/Xnaimage1.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/Xnaimage1.png)

<span style="mso-no-proof: yes;"> </span>

## <a name="_Toc77773369"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;"><span style="font: 7.0pt 'Times New Roman';"><span style="mso-spacerun: yes;"> </span></span>II.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Docker, le cœur de notre architecture

Pour ce projet, nous avons vraiment voulu exploiter docker avec ce qu'il pouvait faire de mieux. Nous avons donc passé énormément de temps à apprendre cette technologie et l'implémenter correctement au sein de notre projet.

#### <a name="_Toc77773370"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">1.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Tout est docker

#### <a name="_Toc77773371"></a>Dockerisation de tous les applicatifs

Dans d'autres projets, mise à part l'application client Java, toutes nos applications possède un Dockerfile personnalisé qui permet à celle-ci de se lancer dans un container sans contraintes.

Cela nous permet d'avoir des images clé en main directement instanciable et fonctionnel.

Voici par exemple Dockerfile de notre serveur backend API.

[![Image2.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/3Bgimage2.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/3Bgimage2.png)

<span style="mso-no-proof: yes;"> </span>

Afin que l'image finale soit la plus légère et performante possible, et qu’elle ne possède que l'applicatif, nous possédons dans nos instructions une image intermédiaire qui va simplement se contenter de compiler notre code avant de le faire transiter dans l'image finale qui possédera l'exécutable uniquement.

#### <a name="_Toc77773372"></a>Portainer, l’interface de contrôle

Grâce à Portainer, nous possédons une interface web pour administrer nos images docker ainsi que les containers lancés. Un agent Portainer est présent aussi bien sur le serveur VPS que sur la Raspberry mais c'est le serveur VPS qui héberge l'interface web.

<table border="1" id="bkmrk--3" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>[![Image3.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/JNPimage3.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/JNPimage3.png)</td><td>[![Image4.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/KD2image4.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/KD2image4.png)</td></tr><tr><td>[![Image5.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/ssiimage5.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/ssiimage5.png)</td><td>[![Image6.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/brgimage6.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/brgimage6.png)</td></tr></tbody></table>

### <a name="_Toc77773373"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">2.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Cluster et load balancer

Nous avons décidé d'intégrer à notre projet la problématique de performance de notre application lorsque celle-ci est et soumis à une forte charge. Heureusement, docker nous propose plusieurs solutions pour répondre à cette problématique.

#### <a name="_Toc77773374"></a>Docker Swarm

Docker-Swarm est un outil conçu pour enrichir <span style="mso-fareast-font-family: HGMinchoE; mso-fareast-theme-font: major-fareast;">Docker lui offre</span> un “mode Swarm”. Ce mode donne la possibilité de **créer des clusters de machines** exécutants des **conteneurs Docker**, qui **fonctionnent ensemble** comme une seule machine.

<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-fareast-language: FR;">Docker-Swarm permet entre autres de :</span>

<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; font-family: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-language: FR;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>**<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-fareast-language: FR;">Coordonner les conteneurs</span>**<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-fareast-language: FR;"> et de leur **affecter des tâches** à chacun d’eux. </span>

<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; font-family: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-language: FR;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>**<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-fareast-language: FR;">Gérer et suivre l’état</span>**<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-fareast-language: FR;"> des différents conteneurs dans le cluster, et **redistribuer les tâches** en cas de besoins.</span>

<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; font-family: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-language: FR;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>**<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-fareast-language: FR;">Assurer la scalabilité et flexibilité</span>**<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-fareast-language: FR;"> de l’infrastructure, en augmentant ou diminuant le nombre de clusters mis en services.</span>

<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; font-family: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-language: FR;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>**<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-fareast-language: FR;">Gérer et mettre à jour les applications</span>**<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-fareast-language: FR;"> sur plusieurs conteneurs.</span>

<span style="mso-bidi-font-size: 12.0pt; line-height: 150%; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-fareast-language: FR;">[![Image7.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/E5pimage7.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/E5pimage7.png)</span>

<span style="mso-no-proof: yes;"> </span>

#### <a name="_Toc77773375"></a>Mise en place des services

<span style="mso-fareast-language: FR;">Swarm fonctionne grâce aux services, qui sont des **descriptions de l’état qu’on souhaite garder pour les nœuds du cluster**. Pour fonctionner, un service a besoin d’un conteneur et de commandes à exécuter sur celui-ci. </span>

<span style="mso-fareast-language: FR;">Les services exécutés sur Swarm peuvent avoir plusieurs caractéristiques, telles que : </span>

<span style="font-family: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-language: FR;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>**<span style="mso-fareast-language: FR;">Options des services</span>**<span style="mso-fareast-language: FR;"> : lors de la création du service, on peut **configurer plusieurs paramètres selon les besoins de nos applications** (limites mémoire, le nombre des répliques de l’image à exécuter sur Swarm, etc.).</span>

<span style="font-family: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-language: FR;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>**<span style="mso-fareast-language: FR;">État désiré</span>**<span style="mso-fareast-language: FR;"> : le déploiement du service permet de **définir l’état désiré** sur le Swarm. L’état désiré représente le **comportement normal ou la configuration idéale de l’application sur Swarm**. Par exemple, lorsqu’un problème survient et met à défaut l’état désiré, les “Manager Nodes” interviennent pour corriger le problème en affectant plus de ressources au service.</span>

<span style="mso-fareast-language: FR;">Grâce aux services, nous pouvons créer un répartiteur de charge entre plusieurs instance d’une même application. Celui-ci sera répliqué autant de fois que voulu.</span>

<span style="mso-fareast-language: FR;">Dans le cas de notre application, nous possédons un service sur le backend API qui va faire fonctionner 4 instances de notre application et répartir la charge équitablement sur chaque nœuds. Notre application WEB elle, possède un service avec 2 instances.</span>

<span style="mso-fareast-language: FR;">[![Image8.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/wD8image8.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/wD8image8.png)[![Image9.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/sytimage9.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/sytimage9.png)</span>

### <a name="_Toc77773376"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">3.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Registre docker privé

Les applicatifs étant la propriété de Vécolo, nous ne pouvons pas les héberger publiquement sur docker hub. Il nous faut notre propre registre, le VPS possède donc un registre docker privé avec une authentification. C'est sur ce registre que nous poussons les images de nos applicatifs. Nous avons ainsi un contrôle total sur l’hébergement de nos images Docker.

<span style="mso-no-proof: yes;"> <span style="mso-spacerun: yes;">[![Image10.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/mjJimage10.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/mjJimage10.png)</span> </span>

## <a name="_Toc77773377"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">III.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Déploiement continu

Les étapes de déploiement d'un projet web sont souvent fastidieuses et répétitif. De plus, il faut parfois que cela se fasse rapidement et il n'y a pas toujours quelqu'un de disponible pour le faire.

Nous avons donc fait en sorte que à partir du moment où nous poussons du code sur des branches spécifiques de nos projets, l'application soit automatiquement mise à jour sur le serveur principal sans intervention de notre part.

### <a name="_Toc77773378"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">1.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Builds automatique &amp; Webhooks

Grâce aux actions Github, nous avons pu mettre en place sur nos dépôts de l’application Backend API et Front end Angular des évènements déclenchés lorsque la branche « **dev** » est mis à jour (dernière version fonctionnelle de nos applicatifs). Cet évènement va se charger de construire l’image Docker associé à la dernière version du projet, avant de l’envoyer à notre registre privé.

Une fois cela fait avec succès, un signal est envoyé au service (API ou Angular) présent sur le serveur à l’aide d’un Webhook.**<span style="font-size: 14.0pt; mso-bidi-font-size: 11.0pt; line-height: 110%; mso-fareast-font-family: HGMinchoE; mso-fareast-theme-font: major-fareast; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: major-bidi; text-transform: uppercase;"> </span>**

**<span style="font-size: 14.0pt; mso-bidi-font-size: 11.0pt; line-height: 110%; mso-fareast-font-family: HGMinchoE; mso-fareast-theme-font: major-fareast; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: major-bidi; text-transform: uppercase;">[![Image11.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/2A8image11.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/2A8image11.png)</span>**

### <a name="_Toc77773379"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">2.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Mise à jour des services incrémental

Grâce à la configuration de nos service, celui-ci met à disposition une URL pouvant être appelé depuis un Webhook. Quand celle-ci est requêté, le service sait qu’il doit redémarrer en mettant à jour l’image Docker de ses instances.

Cependant nous ne voulons pas d'interruption de service. C'est pourquoi les instances ne se mettent pas toutes à jour en même temps.

Dans le cadre du back end API (4 instances) les serveurs se mettent à jour 2 par 2. Les 2 derniers serveurs ne se mettent à jour que si les 2 premiers ont réussi à se lancer correctement et continue de tourner depuis au moins 10 secondes.

Pour l'application Angular qui ne contient que 2 instances le service va les mettre à jour une par une

En cas d'échec, le service va retenter plusieurs fois de lancer les instances jusqu’à un maximum de 10 fois. Si au bout de 10 fois le service n'arrive toujours pas à lancer les instances, il effectue un rollback sur les précédentes versions fonctionnelles de l'application. Ainsi, avons en permanence une instance fonctionnelle de lancée.

[![Image12.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/RTBimage12.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/RTBimage12.png)

<span style="mso-no-proof: yes;"> </span>

## <a name="_Toc77773380"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">IV.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Raspberry VS 100 Bornes

### <a name="_Toc77773381"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">1.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Objectif recherché

Notre projet Vemock consiste à simuler le comportement d'une station. Or dans notre application, nous souhaitons avoir bien plus qu'une seule station d'active afin que le comportement soit réaliste. De plus, nous souhaitons simuler ce comportement depuis un appareil ayant des composants matériels prévus pour de l'embarqué. Cela permettra dans le futur une meilleure compatibilité sur de vrais stations.

Le choix de la Raspberry était donc tout indiqué. Il fallait maintenant trouver un moyen correct de faire tourner plusieurs instance de station différente sur cette Raspberry.

### <a name="_Toc77773382"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">2.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Stack de 100 bornes

Docker Compose est un outil qui permet de décrire (dans un fichier YAML) et gérer (en ligne de commande) plusieurs conteneurs. Il est alors possible de démarrer un ensemble de conteneurs en une seule commande. Dans le fichier **docker-compose.yml**, chaque conteneur est décrit avec un ensemble de paramètres qui correspondent aux options disponibles lorsqu'on lance une instance normalement.

La solution d'utiliser docker compose pour monter plusieurs bornes en même temps était donc très intéressante.

Notre docker-compose final permet de lever en une seule commande 100 instances ! elles sont toutes identifiées sur l'API grâce à un token unique et permet donc de simuler le comportement de 100 stations à Paris.**<span style="font-size: 14.0pt; mso-bidi-font-size: 11.0pt; line-height: 110%; mso-fareast-font-family: HGMinchoE; mso-fareast-theme-font: major-fareast; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: major-bidi; text-transform: uppercase;"> </span>**

<table border="1" id="bkmrk--11" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>[![Image13.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/VPPimage13.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/VPPimage13.png)</td><td>[![Image14.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/mEcimage14.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/mEcimage14.png)</td></tr></tbody></table>

### <a name="_Toc77773383"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">3.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Générateur du docker-compose

Pour simuler le comportement de 100 stations, le fichier docker compose **docker-compose.yml** fais plus de 2400 lignes. Bien sûr il serait trop long d'écrire toutes ces lignes à la main…

Nous avons donc mis au point un script python qui permet à partir d'un fichier de configuration JSON beaucoup moins gros de générer notre **docker-compose.yml** final.

Voici un exemple des fichiers de configuration avec seulement 2 stations :<span style="mso-no-proof: yes;"><span style="mso-spacerun: yes;"> </span> </span>

<span style="mso-no-proof: yes;"><span style="mso-spacerun: yes;">[![Image15.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/FSyimage15.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/FSyimage15.png)[![Image16.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/hqpimage16.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/hqpimage16.png)</span></span>

## <a name="_Toc77773384"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;"><span style="font: 7.0pt 'Times New Roman';"> </span>V.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Monitoring

Comme nous pouvons le constater, notre architecture serveurs est assez rempli et beaucoup d'applications différentes. Il est donc compliqué de tout surveiller sans aide.

Nous avons donc mis en place une stack docker compose regroupant Grafana, CAdvisor, Node-Exporter et Prometheus. Afin de pouvoir monitorer tout ce qui se passe sur nos serveurs.**<span style="font-size: 14.0pt; mso-bidi-font-size: 11.0pt; line-height: 110%; mso-fareast-font-family: HGMinchoE; mso-fareast-theme-font: major-fareast; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: major-bidi; text-transform: uppercase;"> </span>**

**<span style="font-size: 14.0pt; mso-bidi-font-size: 11.0pt; line-height: 110%; mso-fareast-font-family: HGMinchoE; mso-fareast-theme-font: major-fareast; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: major-bidi; text-transform: uppercase;">[![Image17.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/6QWimage17.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/6QWimage17.png)</span>**

### <a name="_Toc77773385"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">1.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Grafana &amp; Prometheus

Grafana est un outil open source de monitoring informatique orienté data visualisation. Il est conçu pour générer des tableaux de bord sur la base de métriques et données basées dans le temps.

On peut y connecter différentes bases de données, orientées Time Series (base de données optimisée pour le stockage de données horodatées) pouvant être alimentées grâce à une grande variété d’agents de monitoring. Dans notre cas il s’agira d'une base donnée Prometheus.

### <a name="_Toc77773386"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">2.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Node exporter, les métriques systèmes

Prometheus ne sait pas collecter d'informations tout seul. Il lui faut des agents. Le plus simple et le plus complet pour avoir une vision global de la situation d'une machine (CPU, RAM, Load, traffic, etc.) est le bien nommé Prometheus Node Exporter. Il nous permettra d'avoir les métriques globales de la machine.

### <a name="_Toc77773387"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">3.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Cadvisor, les métriques Docker

Les containers sont aujourd’hui largement utilisés du développement jusqu’en production. Cependant un **docker stats** en SSH ne permet pas de gérer correctement son environnement de production.

Cadvisor est une solution rendue open-source par Google qui permet de fournir les ressources utilisées par des containers docker. Cela nous permettra d'avoir des métriques personnalisées pour chaque instance tournant sur nos serveurs**<span style="font-size: 14.0pt; mso-bidi-font-size: 11.0pt; line-height: 110%; mso-fareast-font-family: HGMinchoE; mso-fareast-theme-font: major-fareast; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: major-bidi; text-transform: uppercase;"> </span>**

### <a name="_Toc77773388"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">4.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Tableaux de bords

Grâce à cette composition, nous possédons 2 tableaux de bord.

<span style="font-family: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Un pour le serveur principal

<span style="font-family: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Un pour la Raspberry

Les 2 tableau de bord sont quasi similaires la différence près que nous surveillons également la température de la machine sur la Raspberry car c'est un composant qui chauffe vite.<span style="mso-no-proof: yes;"> </span>

<span style="mso-no-proof: yes;">[![Image18.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/adYimage18.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/adYimage18.png)[![Image19.png](https://wiki.nospy.fr/uploads/images/gallery/2022-09/scaled-1680-/jiDimage19.png)](https://wiki.nospy.fr/uploads/images/gallery/2022-09/jiDimage19.png)</span>

## <a name="_Toc77773389"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">VI.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Bilan du projet

### <a name="_Toc77773390"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">1.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Problèmes rencontrés

#### <a name="_Toc77773391"></a>Docker Swarm et les services

Nous n'avons pas eu de cours de docker cette année et il a donc fallu partir de 0.

Docker Swarm est un concept que nous avons eu énormément de mal à comprendre et nous n'avons pas tout de suite implémenté des services car nous n'y arrivions tout simplement pas.

C'est plutôt vers la fin du projet que nous sommes enfin parvenus à faire ce que nous voulions avec.

#### <a name="_Toc77773392"></a>Déploiement continue

Nous avons tenté d'abord d'utiliser Jenkins pour le déploiement continu mais nous nous sommes vite retrouvés perdus devant l'immensité de l'outil et le peu d'informations que nous avions à ce sujet.

Ce sont sur les derniers cours de l'année que nous avons pu discuter avec certains de nos professeurs afin de trouver des solutions adéquates pour avoir un développement continu qui tient la route

#### <a name="_Toc77773393"></a>Mockage de 100 stations

Le mockage des 100 stations était un des plus grands défis de ce projet. Il a fallu beaucoup travailler sur l'optimisation du code pour que cela prenne le moins de ressources possible afin de faire tourner 100 instances simultanées sur une Raspberry.

Le premier montage a été long et fastidieux car il fallait créer 100 stations à Paris à des endroits géographiques cohérents est spécifié dans le docker compose la configuration de chacune.**<span style="font-size: 14.0pt; mso-bidi-font-size: 11.0pt; line-height: 110%; mso-fareast-font-family: HGMinchoE; mso-fareast-theme-font: major-fareast; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: major-bidi; text-transform: uppercase;"> </span>**

### <a name="_Toc77773394"></a><span style="mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman';"><span style="mso-list: Ignore;">2.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span>Conclusion

Pour conclure, c'est sans doute la plus grande architecture serveur que nous ayons eu à mettre en place depuis le début de notre scolarité.

Le fait d'intégrer docker dans cela a été une grande nouveauté et nous a permis d'aller beaucoup plus loin que les années précédentes.

Nous sommes très fiers du déploiement continu que nous avons puis mettre en place vers la fin, ainsi que les fameuses stations qui constituent un des gros objectifs du projet.

Enfin, il a été très agréable d'avoir pu monitorer tout ça et surveiller le comportement de nos applications et nos serveurs.

Nous comptons sans doute réutiliser cette architecture pour nos futurs projets