Rapport de stage de Masters M2INFORMATIQUE

Migration des briques de bases du SI

Olivier PICARD34002455

M2 Informatique

Encadre par Jephte CLAINDSI de l’Universite de la Reunion

du 13 janvier 2020 au 13 juillet 2020Responsable de stage : Fred Mesnard

1 RemerciementsJe voudrais en premier remercier une personne qui a toujours ete presente pour moi aussi bien dans les

bons moments comme les moins bons. Cette personne qui m’a toujours soutenu et m’a toujours encouragea avancer. Merci maman, merci pour tout ce que tu fais pour moi, merci d’etre la.

Je tiens a remercier toute l’equipe pour son accueil chaleureux et leur constante bonne humeur.

J’aimerais tout particulierement remercier mon tuteur Jepthe CLAIN pour sa disponibilite a mon egard,ses nombreux et judicieux conseils, et aussi de m’avoir donne la possibilite et le temps necessaire a l’ap-prentissage et a l’assimilation de toutes les connaissances acquises durant ce stage.

Je remercie egalement Mamy Haja Rakotobe pour les discussions enrichissantes qui m’ont permis d’avoirune vision differente du monde du travail.

Olivier Picard

Table des matieres

1 Remerciements 1

2 Introduction 5

3 Description du cadre d’accueil 53.1 Description globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Contexte du stage 64.1 Maintenance applicative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.2 Maintenance du systeme d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.2.1 Pannes materielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Sujet de stage 8

6 Qu’est-ce que le DevOps 96.1 Incompatibilites entre developpeurs et operateurs . . . . . . . . . . . . . . . . . . . . . . 96.2 Architectures micro-services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.3 Continuous Integration et Continuous Delivery . . . . . . . . . . . . . . . . . . . . . . . 11

7 MOOC et apprentissage 127.1 Methodologie d’apprentissage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127.2 Description des competences acquises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

7.2.1 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137.2.2 Docker Compose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

8 Mise en pratique de Docker et Docker Compose 14

9 Deploiement manuel sur un hote distant 149.1 Docker Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159.2 Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

9.2.1 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169.3 Objectifs a terme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

10 KeepAlived 1710.1 Fonctionnement theorique et recherches . . . . . . . . . . . . . . . . . . . . . . . . . . . 1710.2 Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2010.3 Demarrage sur une IP fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2110.4 Bind sur une adresse qui n’existe pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

11 Configuration d’un cluster de machines virtuelles 22

12 Domain Name System (DNS) 2412.1 Theorie et raisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2412.2 Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

12.2.1 Configuration sur une IP fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

13 Kubernetes vs Docker Swarm 26

14 Docker Swarm 2714.1 Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

14.1.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2714.1.2 Image locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2814.1.3 Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

14.2 Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2914.2.1 Creation d’un registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3014.2.2 Deploiement des stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

15 Traefik 3215.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3215.2 Pourquoi un reverse proxy? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3215.3 Rapide etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3315.4 Les avantages de Traefik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3415.5 Pourquoi choisir Traefik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3415.6 Difficultes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

16 ProxySQL 3516.1 Fonctionnalites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3516.2 Rapide etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

17 Replication Manager 3617.1 Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3617.2 Sharding Mysql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3617.3 Le choix de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

17.3.1 Pourquoi avoir un cluster de trois machines . . . . . . . . . . . . . . . . . . . . . 3717.3.2 Pourquoi avoir un seul maıtre sur le cluster . . . . . . . . . . . . . . . . . . . . . 37

17.4 Pourquoi utiliser replication manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3917.5 Difficultes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

18 Tests du cluster MariaDB 39

19 Conclusion 41

20 Annexes techniques 4220.1 Annexe A : mise en place de Docker et Docker Compose . . . . . . . . . . . . . . . . . . 42

20.1.1 Annexe B : deploiement manuel sur hote distant - Configuration . . . . . . . . . . 4420.2 Annexe C : configuration d’un DNS avec bind9 . . . . . . . . . . . . . . . . . . . . . . . 4520.3 Annexe D : creation d’un registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

21 Annexe : gestion de projet 47

Rapport de stage M2 Informatique - DSI Universitede la Reunion

Olivier Picard1

1olivier picard@live.fr - 0692 33 42 22

Dans le cadre d’un projet visant a ameliorer la structure existante de la DSI[1], le travail qui m’a ete demande est la

migration des bases du SI. Cette migration concerne en particulier le transfert des bases de donnees MariaDB[2] sur des

serveurs hautes disponibilites pour l’Universite[3] de la Reunion. Le document fait egalement etat des taches realisees

et de mes recherches sur le fonctionnement des outils dans le domaine du reseau, de la DevOps[4] mais aussi sur le

systeme Linux/Debian[5].

As part of a project to improve the existing structure of the DSI, my work is about migration of Information System(SI)

bases. This migration focus precisely on MariaDB database transfert to high availability servers for ’Univeriste de la

Reunion’. This document also describe my tasks achieved and my reseaches. The higlight is put on the network, De-

vOps and also on Linux/Debian.

Mon stage est encadre par mon tuteur Jepthe Clain(jephte.clain@univ-reunion.fr).

Mots-clefs : Reseaux, Docker, Serveurs hautes disponibilites, CAS, Docker Swarm, Traefik

2 Introduction

Ce rapport a pour vocation de presenter le stage de six mois que j’effectue durant ma derniere annee de

Master 2 a l’Universite de la Reunion. j’ai choisi ce stage car il m’a permis de decouvrir des domaines et

outils que je ne connaissais que tres peu, comme la conteneurisation. De plus ce stage m’a offert la pos-

sibilite d’acceder a des services en fonctionnement non interrompus utilises par des milliers d’utilisateurs.

Grace a cela, j’ai pu comprendre les difficultes et les rouages essentiels au bon fonctionnement d’un tel

systeme. Cette experience en milieu professionnel m’a permis de prendre en main de nouveaux outils, et

d’acquerir une methode de travail utile pour la suite de mon parcours.

Ce rapport fait aussi etat des competences theoriques que j’ai pu mettre en pratique, des missions qui

m’ont ete confiees, ainsi que la rigueur acquise au sein de la Direction des Systemes d’Informations (DSI)

de l’Universite de la Reunion.

3 Description du cadre d’accueil

3.1 Description globale

Mon stage se deroule a l’Universite de la Reunion a la DSI, mais plus precisement dans le service

Developpement et Application (SDA). Pour se remettre dans le contexte, l’Universite de la Reunion est

un organisme fonde en 1982 avec la faculte de droit et d’economie. Cette faculte fut la premiere de l’ıle de

la Reunion, suivie ensuite par la faculte de Science et Technologie. Au sein de l’universite de la Reunion,

sur le campus du Moufia se trouve la DSI. Comme le montre l’illustration ci-dessous, la DSI se decompose

en plusieurs services. Cette derniere se decrit comme ayant pour mission ”de proposer et de mettre en

oeuvre la politique du systeme d’informations dans le domaine du traitement informatise ou numerique de

l’information relative a l’enseignement, a la recherche, a la documentation et a la gestion. Son perimetre

d’actions regroupe toutes les composantes et services de l’etablissement.” La DSI joue un role important

au sein de l’universite, notamment en maintenant le bon fonctionnement des infrastructures reseaux et des

applications informatiques. Les services mis en place par la DSI a un impact direct sur l’universite, aussi

bien que sur les etudiants et la majeure partie du personnel, qu’il soit administratif, financier ou autres.

3.2 Environnement de travail

La SDA a pour particularite que la plus grande partie du personnel travaille dans un grand bureau partage

(Open space). En comptant ma presence, nous sommes sept a travailler dans cette salle. L’experience de

travail dans un open space est un peu destabilisante au debut, mais offre des avantages. Parmi ces avantages,

on peut citer la facilite a communiquer. De part la proximite qu’offre l’open space, la communication ver-

bale est le moyen privilegie pour echanger des informations. De ce fait, je peux directement interroger mon

tuteur sans avoir a me deplacer. De meme, les reunions concernant les taches a realiser, et celles en cours

Olivier Picard

FIGURE 1: Organigramme de la DSI

sont grandement facilitees. Il se trouve que les points de blocage sont plus rapidement resolus. Toutefois

la proximite presente aussi quelques inconvenients, tels que les bruits et les deplacements qui diminuent la

productivite. Heureusement que la bonne humeur qui y regne gomme totalement les defauts qu’imposent le

travail en open space.

Dans le contexte particulier du confinement qu’impose le COVID19, J’ai ete autorise a teletravailler. Tra-

vailler a son domicile presente de tres nombreux avantages. Notamment, il est beaucoup plus facile de

s’approprier le projet, et de le considerer comme un projet personnel. Ainsi la motivation et la productivite

sont accrues.

4 Contexte du stage

Mon stage se porte sur le DevOps et s’integre au sein de la volonte de la DSI d’ameliorer la disponibilite

des services proposes. En quelques mots, mon travail vise a rendre certaines applications plus resistantes a

la fois aux pannes et aux fortes affluences.

Maintenir des serveurs qui offrent un acces a l’integralite des membres de l’Universite de la Reunion est

une tache complexe. Les applications proposees doivent etre accessibles 24h/24 et 7j/7. On peut prendre

l’exemple de l’emploi du temps. Il n’est absolument pas envisageable d’arreter ce service, pour la simple rai-

son qu’il est utilise aussi bien pendant et en dehors des heures d’ouverture de l’universite. Il existe d’autres

services comme Moodle qui sont plus sensibles et doivent etre hautement disponibles, afin d’assurer une

fonctionnalite permettant la remise des travaux aux enseignants et l’acces aux cours. Les serveurs sont ainsi

tres sollicites. Par consequent, il est tres difficile de les maintenir en assurant les mises a jour a la fois du

systeme d’exploitation, et de l’ensemble des applications. D’un regard exterieur, il est tres probable qu’on

ne puisse percevoir la difficulte a faire des mises a jour au niveau applicatif. Mais je propose que l’on se

penche un peu plus sur ce sujet.

4.1 Maintenance applicative

Supposons que l’on dispose d’une application programmee en Java et d’un serveur Tomcat. Cette appli-

cation a ete developpee il y a de cela quelques annees. Au fil du temps, des mises a jour majeures ont ete

publiees par Tomcat. En theorie on change de version de Tomcat en se mettant sur la plus recente stable et

supportee pour le long terme. Mais dans les faits, c’est un peu different. Changer de version signifie arreter

tous les services lies au serveur Tomcat. Arreter un service utilise par des milliers d’individus n’est pas

particulierement opportun, ce qui peut eventuellement impacter de nombreux utilisateurs. De plus, selon

la maintenance a effectuer, cela s’avere tres chronophage et necessiterait le redemarrage de l’ensemble des

services, et de nombreuses interventions manuelles qui ont ete definies il y a quelques annees, lors de la

creation du service. Ces manipulations peuvent etre des sources d’erreurs et d’oublis. Mon role durant ce

stage est d’intervenir pour ”conteneuriser” les applications afin de les rendre plus facilement maintenables.

Je reviendrais plus en detail sur ce qu’est la conteneurisation.

4.2 Maintenance du systeme d’exploitation

Cette partie est etroitement liee a celle qui decrit les difficultes de la ”maintenance applicative”. Mais les

consequences d’une maintenance du systeme d’exploitation peut entraıner des problemes de compatibilite

avec les applications existantes. On peut citer l’obligation d’utiliser les dernieres technologies de transmis-

sions securisees. L’utilisation des derniers protocoles de securites permet en effet de mieux proteger les

services, mais sont aussi sources de bugs qui peuvent s’averer difficiles a resoudre. Si de nombreux services

sont dependants d’une version specifique de ce protocole (par exemple TLS), il peut etre delicat de passer a

une version plus recente. Ces operations s’averent etre tres chronophages et peuvent causer des erreurs. Une

maintenance du systeme d’exploitation peut eventuellement affecter un ensemble consequent de services,

et peut meme les rendre inoperants.

4.2.1 Pannes materielles

Lorsque l’on a en charge un ensemble de machines qui doivent fournir un service ininterrompu, le bon

fonctionnement de chacune d’entre elles est primordiale. On n’est jamais a l’abri d’une panne materielle.

Une panne peut survenir a n’importe quel moment, et compromettre l’experience utilisateur. Certaines

ressources comme les base de donnees sont indispensables au bon fonctionnement des autres applications

qui y sont dependantes. Si le ou les serveurs qui gerent les bases de donnees sont en pannes, ce sont de tres

nombreux services qui se retrouvent impactes. Mais heureusement que l’on peut introduire de la redondance

pour pallier a ces problemes, et permettre a l’ensemble du reseau d’etre plus robuste.

Olivier Picard

4.3 Objectifs

Comme on a pu le voir precedemment, mettre des applications ou un systeme a jour est une tache

delicate qui peut compromettre la stabilite du systeme. Les dependances des applications sont difficiles

a faire evoluer, et necessitent souvent quelques modifications du code source de l’application. Pour cela, on

doit prendre en consideration les changements apportes par les nouvelles versions. Les pannes materielles

peuvent devenir problematiques, et mettre en peril une grande partie des services.

Les objectifs vises sont :

— Effectuer des mises a jour plus facilement et par consequent plus regulierement.

— S’assurer que les services restent toujours disponibles pour l’utilisateur.

— Obtenir un reseau robuste en introduisant de la redondance.

— S’adapter aux pics de demandes plus importantes.

5 Sujet de stage

Apres une vue d’ensemble des problemes rencontres et des objectifs de la DSI, j’aborderais mon su-

jet de stage qui se porte sur le DevOps. J’ai pour mission de migrer des services principaux du systeme

d’information vers un cluster haute disponibilite, et d’intervenir dans l’optique d’ameliorer la stabilite et

la maintenance des services fournis par la DSI. Le stage s’etalant sur une periode de six mois, je ne peux

migrer l’ensemble des services. L’objectif principal a ete de me concentrer sur la base de donnees MariaDB.

Cette derniere constitue un besoin grandissant pour la DSI.

Un cluster hautes disponibilites peut etre mis en place par divers moyens. Mais pour repondre aux exi-

gences de la DSI, la methode la plus adequate correspond a la conteneurisation des applications utilisees en

DevOps. Pour donner une definition simple de la conteneurisation : c’est le fait d’isoler chaque application

les unes des autres en les placant dans des boites appelees conteneur (”container” en anglais). Lorsqu’une

application est conteneurisee, ses dependances sont sous controle. Avec une simple modification, on peut

changer de version, reconstruire, tester et deployer notre application, le tout sans interruption de service.

La conteneurisation est la solution ideale qui apporte a la fois de la robustesse et de la flexibilite necessaire

pour repondre aux exigences definies par la DSI.

En outre, l’isolation des applications ne permet pas directement d’obtenir de la redondance sur le reseau.

Dans ce cas, on fait appel a un orchestrateur de conteneurs. Le but d’un orchestrateur est de deployer des

applications conteneurisees sur le reseau en assurant a la fois la redondance, l’augmentation et la reduction

des ressources en cas de fortes ou de faibles affluences.

Meme si la majeur partie des applications peuvent etre conteneurise, certaines actions requierent une

configuration manuelle des services. Ces configurations s’averent tres chronophages lorsqu’un serveur

demarre, et peuvent etre source d’erreurs, au meme titre que les pannes et les maintenances systeme.

En ayant connaissance de ces informations, outre le fait de maıtriser la conteneurisation et de savoir

mettre en place un cluster applicatif, il faut garder a l’esprit que chaque configuration faite manuellement

doit autant que possible etre automatisee grace a un script. Je percois cette exigence, non pas comme des

competences a acquerir pour mener a bien mon stage, mais plutot comme une methode de travail que je

pourrais reutiliser par la suite dans d’autres organismes.

6 Qu’est-ce que le DevOps

J’ai decrit les problemes engendres par la maintenance et les pannes, tout en mentionnant que la conte-

neurisation peut resoudre ces problemes. Toutefois, mettre des applications dans des conteneurs, et laisser

un orchestrateur les gerer demande de connaıtre divers outils. Avant tout, il faut comprendre qu’elle est la

difference entre un deploiement DevOps et un deploiement classique.

Avec l’engouement grandissant pour les technologies liees au cloud, le DevOps est de plus en plus

present. Au travers de la migration des services de la DSI vers des clusters de hautes disponibilites, mon

stage se situe au centre de la culture du DevOps. Durant ces mois, j’ai acquis quelques methodes fondamen-

tales du DevOps que je continuerais par la suite d’approfondir. Meme si je n’ai pas utilise l’ensemble des

procedures citees ci-dessous, il me semble opportun de decrire les plus courantes, ainsi que les avantages

qu’apportent cette philosophie.

Le DevOps est un concept qui a pour objectif d’unir les travaux des developpeurs (dev) a ceux des admi-

nistrateurs systeme et d’infrastructures (ops).

A l’origine dans les grandes infrastructures, on trouve deux equipes isolees les unes des autres. D’un

cote il y a les developpeurs, et de l’autre se trouve l’equipe operation qui est en charge de l’administration

systeme et du deploiement des logiciels. A cause de l’isolation entre ces deux equipes, le deploiement de

logiciel peut prendre plus de temps que necessaire.

6.1 Incompatibilites entre developpeurs et operateurs

Le premier probleme etant l’incompatibilite des dependances des applications. En d’autres termes, l’equipe

des developpeurs ne fournit pas une liste exhaustive des bibliotheques et autres fonctionnalites necessaires

au bon fonctionnement de l’application. L’equipe des operateurs se retrouve donc avec un logiciel qui ne

fonctionne pas, et donc impossible a deployer. Il se peut aussi que les developpeurs et les operateurs ne

possedent pas les memes versions des dependances de l’application, ce qui engendre des incompatibilites

entre les deux equipes.

Olivier Picard

6.2 Architectures micro-services

FIGURE 2: Architecture micro-services

L’utilisation du DevOps entraıne parfois quelques modifications dans l’organisation d’un projet souvent

associe a l’idee de micro-services. Contrairement a la programmation traditionnelle appelee monolithique,

les micro-services decoupent une application en differentes parties appelees services. Un programme mo-

nolithique est un programme complet decoupe en objets ou en fonctions, ce qui forme un seul bloc de codes

interdependants. Chaque fonction ou objet joue un role precis au sein de l’application et ne peut etre separe

les uns des autres. Par opposition, une architecture en micro-services est constituee de petites fonctions

appelees services ou modules qui s’executent en autonomie, et dont la vocation est d’effectuer parfaitement

une seule et unique tache. L’architecture micro-services permet :

— d’obtenir une grande flexibilite du code

— la reutilisation des services au sein de differentes applications

— d’etre facilement deployee sur des clusters hautes disponibilites et d’adapter la replication des ser-

vices selon l’affluence

En revanche l’architecture en micro-services demande une reorganisation complete des structures habi-

tuelles. Chaque service est isole les uns des autres et ne peuvent communiquer que par le reseau qui les

relie. La communication par le reseau etant plus lente que l’appel d’une fonction, par consequent l’ap-

pel aux differents services doit se faire uniquement en cas de necessite. Les services doivent etre le plus

independants possible, afin d’eviter de solliciter un service externe.

6.3 Continuous Integration et Continuous Delivery

FIGURE 3: Continuous Integration et Continuous Delivery (from AWS Website)

Le DevOps presente un avantage majeur qui est la rapidite de deploiement des applications. Notamment

grace au CI (Continuous Integration) /CD (Continuous Delivery). Le CI/CD est un principe fondamental du

DevOps. Il permet de fournir des mises a jour regulieres et fiables aux clients. Un des avantages de mettre

en place le DevOps est qu’on peut faire facilement travailler plusieurs developpeurs sur des fonctionna-

lites differentes d’un meme logiciel. Ce travail en parallele est deja possible depuis de nombreuses annees

par l’utilisation de depots telle que git, cnv ou autres. Cependant,la decomposition d’une infrastructure en

micro-services permet d’aller bien au-dela d’un depot git commun.

La difficulte qu’apporte le travail en parallele, c’est l’integration de toutes les fonctions codees separement

au sein d’un meme logiciel. Ce processus appele le ”merge” est une tache longue et fastidieuse qui requiert

un ou plusieurs jours. Dans certains organismes tels que la DSI de l’Universite de la Reunion, on emploie

un integrateur dont le role est de ”merger” toutes les modifications faites par les developpeurs. L’avantage

que propose le CI est d’integrer automatiquement toutes les modifications, pour former un logiciel complet

et ensuite le construire (build). L’ecriture de tests d’integration et de tests unitaires qui seront executes au-

tomatiquement par la machine est un moyen efficace de verifier si le logiciel a ete correctement assemble,

et que chaque fonction realise correctement leurs missions. Ainsi le role de la CI est d’integrer, tester et de

construire les fonctions afin de creer un logiciel complet.

Une fois l’integration terminee, on peut passer a la partie ”CD (Continuous Deployment)”. Le ”deploiement

continue”, comme son nom l’indique permet de deployer une application mais de maniere automatique.

Avant de realiser un deploiement, il faut s’assurer que la partie integration est terminee et ne contient pas

d’erreur. Pour effectuer un deploiement, il faut que les developpeurs ecrivent au prealable des procedures

specifiques qui permettent au code deploye d’etre mis directement en production. Ainsi la machine suit les

instructions et diffuse l’application dans les referentiels adequats. Du point de vue de l’utilisateur, l’appli-

cation proposee est toujours a jour.

Olivier Picard

Maintenant que j’ai parle des principes fondamentaux du DevOps, je souhaite notifier qu’avant le stage,

je n’avais que tres peu de notions relatives a ce sujet. Par consequent, il fallait que je decouvre et comprenne

les bases. Il me semble donc important que le chapitre suivant soit consacre aux competences que je dois

acquerir, ainsi qu’a la methode d’apprentissage que j’utilise.

7 MOOC et apprentissage

Le sujet du stage demande de posseder des connaissances tres pointues dans de nombreux domaines,

notamment en systeme Linux. Mais la competence la plus importante a acquerir est celle de la conteneu-

risation. Pour des raisons que j’ai deja evoquees, c’est un element tres important qui permet de mettre en

place une fondation solide pour resoudre de nombreux problemes, comme le deploiement automatique.

Comprendre et maıtriser la conteneurisation d’applications est essentielle pour me permettre de mener a

bien mon stage. Pour aller un peu plus loin, cette philosophie et plus globalement le DevOps, sont des tech-

niques que je souhaite personnellement acquerir. Ce qui a ete la principale raison pour laquelle j’ai choisi

ce stage. Ainsi l’autoformation a ete une phase que j’ai beaucoup appreciee au cours de mon stage.

7.1 Methodologie d’apprentissage

Les MOOC constituent d’excellents points d’entree pour etudier une technologie. Mais ils sont bien sou-

vent trop ’scolaires’ avec beaucoup d’informations theoriques et peu de cas concrets. Pour ma part, il est

difficile de memoriser certains details techniques, dont je ne saisis pas l’interet au moment ou je regarde

le MOOC. Toutefois, j’ai suivi un MOOC sur le site web My-MOOC[6] qui explique les rudiments de la

conteneurisation avec l’outil Docker[7] et Docker Compose[8]. Ce MOOC permet de faire ses premiers pas

dans le monde de la DevOps.

La technologie Docker constitue un pilier pour la conteneurisation. Ainsi la maıtrise de cette technologie

est tres importante. J’ai donc regarde de nombreuses videos YouTube, afin d’observer comment Docker est

utilise par d’autres utilisateurs. Celles-ci m’ont permis de voir differents projets, differentes methodes, et

differentes techniques, qui sont propres a chaque Youtuber. L’aspect pratique est tres present, ce qui me per-

met de comprendre tres rapidement les fonctionnalites importantes, ainsi que les differents cas d’utilisation.

Ensuite je me fixe un objectif. En l’occurrence, un projet a realiser. Des le depart, afin de m’entraıner,

mon tuteur m’a confie la realisation d’un projet fictif. Ce projet est un ”raccourcisseur d’URL” (URL shor-

tener). Ce projet m’a aide a guider mon apprentissage et constitue un objectif solide.

Des lors que j’ai un objectif, les forums ainsi que la documentation officielle fournissent des points impor-

tants dans mon cheminement. A cette etape, je suis en mesure de comprendre les commandes principales, et

d’assembler les informations recuperees a partir de diverses sources. Le code repris sur internet est ensuite

legerement modifie pour s’adapter a mes besoins. Ainsi les modifications et les recherches que j’effectue

me permettent de comprendre de mieux en mieux le fonctionnement de Docker, et de combiner toutes les

techniques des autres, afin d’en garder que les meilleures. Cette methode d’apprentissage m’a grandement

aide dans la progression de mes taches durant mon stage.

7.2 Description des competences acquises

Depuis le debut du rapport je parle de conteneurs, de DevOps, et des problemes qu’ils permettent de

resoudre. Mais je n’ai toutefois pas decrit le fonctionnement de ces technologies

7.2.1 Docker

Je ne peux pas parler de conteneurs sans parler de Docker. Docker est un outil qui permet de conteneuriser

une application. Comme je l’ai mentionne plus haut, la conteneurisation est le fait d’isoler une application

de son environnement. Avec Docker il y a deux mots qui sont omnipresents : les conteneurs et les images.

— Une image est une version immuable d’une application. Une image Docker fournit les dependances,

les fichiers de configuration et tout ce qui est necessaire a l’execution de l’application. On peut

construire une image en utilisant un Dockerfile. Si on fait le parallele avec la programmation orientee

objet, une image peut etre comparee a une classe.

— Un conteneur (de l’anglais ’container’) est une instance d’une image. Ainsi, on peut creer autant

d’instances(conteneurs) que l’on souhaite basees sur une meme image. En programmation orientee

objet une image peut etre comparee a un objet.

Il faut aussi mentionner que par defaut une application conteneurisee est une application sans etat dit

”stateless”. En quelques mots une application ’stateless’ est une application qui ne stocke pas des donnees

de maniere persistante. Ainsi a chaque demarrage du conteneur, l’application est initialisee a son etat d’ori-

gine. Pour donner un exemple : il est impossible de faire une base de donnees sur un modele d’applications

’stateless’, puisque le but d’une base de donnees est de sauvegarder les donnees, donc c’est une applica-

tion dite ’stateful’. Toutefois, meme si les applications Docker sont par defaut ’stateless’, il est possible

de les rendre ’stateful’. Pour ceci on leur rajoute un volume. Un volume est un espace disque qu’on attri-

bue au conteneur afin qu’il puisse conserver son etat. L’avantage des applications conteneurisees est qu’ils

contiennent la totalite de leurs dependances avec une version correcte pour le fonctionnement de l’applica-

tion. Cela implique que lorsque l’on transfert une image Docker, l’environnement de travail est deja present

et aucune configuration supplementaire n’est requise. Ensuite, comme les conteneurs sont isoles les uns des

autres, c’est tres simple de changer la version d’une application sans affecter les autres applications.

Ce sont tous ces avantages qui ont permis aux applications conteneurisees d’avoir une rapide adoption

dans la communaute des developpeurs. La conteneurisation donc par consequent Docker possede de nom-

breux autres avantages. Mais dans le cadre de mon stage cette technologie est au centre de toutes reflexions

et represente un point central du projet.

Olivier Picard

7.2.2 Docker Compose

Docker est un excellent outil pour isoler des applications. Mais il est rare qu’une infrastructure se base

sur une seule et unique image. Beaucoup de projets font appel a des bases de donnees et s’appuient sur

des dependances internes au cluster. C’est dans ce cas qu’on utilise Docker Compose. Docker Compose se

base sur un fichier YAML qui decrit les services, les ressources attribuees et bien plus. Par defaut, tous les

services se situent sur un reseau appele ’default’ et peuvent communiquer entre eux. Dans le cadre de mon

stage, j’ai ete amene a utiliser Docker Compose pour presque la totalite de mes taches. D’une part grace a

son format YAML, le fichier docker-compose.yml est tres comprehensible et facilement modifiable. D’autre

part, je trouve que Docker Compose simplifie grandement l’execution et l’arret des conteneurs Docker. Ce

sont pour ces raisons que cette technologie est tres presente dans le rendu de mes taches.

8 Mise en pratique de Docker et Docker Compose

Comme j’ai pu le mentionner, mes premiers pas avec Docker on ete fait grace a l’elaboration d’une ap-

plication web proposee par mon tuteur qui raccourcit les urls (url shortener en anglais). Bien qu’elle ne sera

jamais utilisee en production, ce site web est composee des memes technologies que les services utilises

par la DSI. C’est a dire MariaDB pour la base de donnees, et Apache pour le serveur qui fournira la page

web aux clients

Si l’on l’analyse le probleme, notre application ecrit en PHP s’appuie sur le serveur Apache pour recevoir

les requetes des clients. Mais d’un autre cote, la page web developpee est dependante de MariaDB. Il faut

noter que par defaut les images d’Apache sur DockerHub n’interpretent pas du code PHP. Cette contrainte

complexifie davantage notre tache. Heureusement que le depot DockerHub dispose d’une image PHP basee

sur Apache ayant Debian 10 Buster comme systeme d’exploitation. Maintenant que je dispose d’une image

sur laquelle basee l’application, il ne reste plus qu’a faire le lien avec la base de donnees MariaDB. Pour

cela, il existe plusieurs methodes. Une de ces methodes est beaucoup plus classique, et consiste a ecrire

un simple fichier Dockerfiles qui decrit les instructions pour construire notre image. Comme on doit faire

fonctionner plusieurs services (MariaDB et Apache), la solution la plus adequate et la plus rapide dans ce

contexte est d’utiliser Docker Compose. A ce titre, il faut rediger un fichier dans le language YAML qui

decrit les dependances entre les differents services. (Se referer a l’annexe A pour plus de details techniques)

9 Deploiement manuel sur un hote distant

Ce chapitre introduit un nouveau concept sur lequel j’ai travaille partiellement durant mon stage. Il s’agit

de Docker Machine[9]. Docker Machine est un outil d’aide a la gestion d’un ensemble de machines. Au

cours de ces six mois, mon tuteur m’a initie a l’utilisation de Docker Machine, mais il ne constitue pas un

element essentiel au bon deroulement de mes taches.

FIGURE 4: Recuperation de MariaDB et PHP :Apache depuis Docker Hub, Construction d’une image basee sur leDockerfile qui contient l’application URL Shortener

9.1 Docker Machine

En quelques mots, Docker Machine permet simplement d’acceder a des noeuds ”dockerises” fournis par

des services tels que Amazon, Google ou autres... Comme Docker Machine cree et supprime des machines

virtuelles en seulement quelques secondes, cela peut etre utile pour deployer des services sur un ensemble

de noeuds par exemple.

Plus en details, de la meme maniere que SSH, Docker Machine permet de prendre le controle a distance

des machines sur lesquelles il est installe. Cet outil est etroitement lie aux commandes presentes dans Do-

cker. A savoir, l’affichage des conteneurs en cours d’executions, la liste des images presente sur un noeud,

l’etat ou l’adresse IP des machines. De plus, Docker Machine offre de nombreuses fonctionnalites liees

a la gestion d’hotes distants tels que l’arret et le demarrage a distance d’une machine, mais aussi l’envoi

facilite d’un contenu. Comme mentionne precedemment, Docker Machine facilite grandement la creation

de machine virtuelle ”dockerisee”. Ainsi, le deploiement est rendu beaucoup plus simple.

Toutefois, meme si Docker Machine simplifie l’utilisation de docker sur les hotes distants, une connec-

Olivier Picard

tion ssh classique peut tout aussi bien permettre le deploiement de conteneurs. Une fois connecte via ssh a

l’hote, on peut utiliser les commandes docker habituelles, comme on le fait sur une machine locale.

9.2 Mise en pratique

Pour m’entraıner a l’utilisation de Docker Machine, j’ai reutilise l’application ulshortener developpee

precedemment, afin de le deployer manuellement sur differentes machines

FIGURE 5: Fonctionnement de Docker Machine (image provenant de Docker.com)

9.2.1 Planification

Avant de commencer la configuration, j’ai concu plusieurs machines a l’aide de Docker Machine. Ainsi

l’environnement de travail cree contient deja tous les outils necessaires pour le bon fonctionnement de

docker. Comme je reprends l’application ”urlshortener” qui consiste a raccourcir les url, j’ai donc conserve

la totalite du script creer precedemment, tout en effectuant des modifications sur la facon de le deployer.

On peut choisir differentes methodes pour le deploiement :

— Docker CLI (en ligne de commande et avec des Dockerfile)

— Docker Swarm[10] (pour le deploiement automatique sur un cluster)

— Docker Compose (un fichier de configuration YAML, qui correspond a la meme methode que j’ai

utilise precedemment)

Le plus approprie pour le deploiement sur un ensemble de machines est l’utilisation du Docker Swarm.

Cependant, je ne l’utiliserais pas maintenant, puisque Docker Swarm constitue un deploiement automatique

sur les hotes distants. Or la mission est de deployer manuellement les services. Ainsi la methode manuelle

me permet d’avoir de l’experience des lors ou le deploiement se complexifie, mais surtout ca me permet

d’en apprendre d’avantage sur la communication entre les services, meme lorsqu’ils sont dispatches sur

differentes machines.

Dans ce cas precis, l’utilisation de Docker CLI (la version en ligne de commande de Docker Engine)

parait etre un choix judicieux, mais possede un desavantage majeur. Comme il s’agit d’une succession de

commandes qui s’enchaınent, c’est tres facile de perdre le fil de ses idees. Par exemple, je me suis retrouve

de nombreuses fois a executer des commandes sur la mauvaise machine. Par consequent, j’ai ete oblige de

reecrire des commandes pour stopper les conteneurs en fonctionnement sur le mauvais hote, puis basculer

sur la bonne machine, et ensuite de nouveau deployer le conteneur. Si on execute ces commandes a chaque

fois, ca devient rapidement fastidieux et source d’erreurs. Cependant, il est tout de meme possible de creer

un script bash, pour executer les commandes de maniere automatiques, ce qui limite les erreurs. J’ai pu

constater que les instructions des commandes de docker CLI sont compactes, peu lisibles et difficilement

comprehensibles. C’est pour ces raisons que je n’ai pas utilise Docker CLI pour cette tache.

En revanche, Docker Compose est le choix que j’ai fait. Dans le contexte du deploiement manuel sur plu-

sieurs hotes, Docker Compose n’est pas le meilleur choix, mais c’est celui que je prefere et qui permet d’etre

tres efficace. La raison derriere ce choix est que le fichier de configuration de Docker Compose est ecrit en

YAML. Les instructions sont faciles a lire, simples a comprendre et a apprendre. En utilisant Docker Com-

pose, je peux deployer mes services en utilisant une seule commande ‘docker-compose up --build‘ .

Les erreurs sont ainsi moins frequentes, les modifications ainsi que le deploiement plus rapides

9.3 Objectifs a terme

Meme si cette tache ne permet pas directement de migrer les services de bases de la DSI, en outre elle me

permet de comprendre davantage le fonctionnement des outils lies a Docker. Les exercices de preparation

permettent de resoudre progressivement des cas complexes, et de comprendre exactement quel est le role de

chaque instruction. La mise en pratique me permet de m’affranchir des informations parfois erronees que je

trouve sur internet. L’objectif etant que je sois apte a choisir les solutions les plus appropriees en fonction

des contraintes imposees. Mais surtout la finalite est de comprendre et de pouvoir transmettre les raisons

profondes qui ont permis de faire un choix plutot qu’un autre.

10 KeepAlived

10.1 Fonctionnement theorique et recherches

Keepalived[11] en quelques mots est une application qui permet a un service d’etre davantage dispo-

nible mais aussi plus resistant aux pannes. KeepAlived utilise les protocoles VRRP[12] et ARP[13] pour

determiner les machines en panne et ainsi switcher sur les machines en fonctionnement.

ARP (Address Resolution Protocol) : le protocole ARP est en realite un ensemble de petits paquets qui

sont envoyes a intervalle reguliere sur l’ensemble du reseau. Le but de ARP est de retrouver la machine

Olivier Picard

FIGURE 6: Schema du fonctionnement de KeepAlived montrant le role de l’IP Virtuelle (image provenant du site web’codeproject.com’

(adresse MAC) en charge d’une adresse IP.

VRRP (Virtual Router Redundancy Protocol) : sans entrer dans les details trop techniques du fonc-

tionnement de ce protocole, on peut dire qu’il permet a une machine de prevenir les routeurs alentour du

deplacement de l’adresse IP sur une nouvelle machine.

Keepalived est fourni avec une documentation tres peu explicite sous forme de ”man” unix. Tout juste

quelques exemples sont disponibles pour la configuration de keepalived. C’est tres complexe de definir

les parametres existants et les positions de l’ensemble des fichiers de configuration. Heureusement que de

nombreux tutoriels sont presents sur internet, mais rares sont ceux qui donnent une configuration a la fois

concise et detaillee de keepalived.

Face a ce probleme, ma premiere idee a ete d’utiliser une image docker disponible sur DockerHub[14].

L’avantage d’utiliser une image, c’est qu’elle est deja pre-configuree, et les modifications se font en definissant

des variables d’environnement dans le Dockerfile. De cette maniere, j’evite toutes les configurations et je

dispose d’un KeepAlived fonctionnel dans les plus brefs delais. Avec cette methode je deviens tres produc-

tif, et je prends de l’avance sur mes autres taches. Toutefois, cette methode presente un desavantage majeur.

Il s’agit d’une image Docker non officielle. Cela implique qu’il n’y a pas de garantie d’obtenir un support

par le developpeur. Comme KeepAlived a pour vocation d’etre mis dans un environnement de production

utilise par des milliers de personnes, mon tuteur m’a fortement deconseille de me baser sur des images

Docker non officielles.

Apres de longues recherches sur une maniere simple de configurer KeepAlived, j’ai trouve quelques

articles mais rien de concluant. Alors j’ai eu l’idee de prendre l’image docker non officielle, et de la

deconstruire (faire du reverse engineering). Par consequent, j’ai pu determiner les configurations a utili-

ser, ainsi que l’emplacement des fichiers dans la hierarchie et encore bien plus d’informations necessaires

au developpement. De meme, j’ai pu appliquer ce que j’ai trouve pour disposer d’un KeepAlived fonction-

nel.

Les recherches que j’ai effectuees sur KeepAlived peuvent se resumer a quelques points importants :

— state MASTER — SLAVE : ce parametre permet de definir un hote comme le maıtre. C’est lui qui

repond aux requetes.

— Dans le cas ou plusieurs routeurs sont definis en tant que MASTER (maıtre) , des que la

machine la plus prioritaire est en panne, le routeur un peu moins prioritaire s’autoproclame maıtre

sur le reseau. En revanche, si la machine plus prioritaire est de nouveau fonctionnelle, elle ne

reprend pas son statut de MASTER, elle reste passive.

— Lorsqu’il n’y a qu’un maıtre sur le reseau et que les autres sont definis comme SLAVE (esclave),

alors des que la machine la plus prioritaire est de nouveau operationnelle, elle reprend son statut

de maıtre et les machines les moins prioritaires deviennent a nouveau esclaves. C’est une variation

subtile mais qu’il est necessaire de comprendre.

— interface xxxx : l’interface correspond simplement a l’interface a laquelle l’IP virtuelle sera associee.

— virtual router id xxx : l’identifiant du routeur virtuel est choisi au hasard et permet d’identifier le

routeur sur le reseau. Cet identifiant va de 1 jusqu’a 255. C’est un identifiant qui est distribue entre

tous les routeurs et qui partagent la ou les memes IP virtuelles.

— priority : definie la priorite du routeur. Plus un routeur est prioritaire, plus il est susceptible de de-

venir le maıtre. Le routeur le plus prioritaire s’autoproclame maıtre quand le maıtre actuel ne repond

plus.

— virtual ipaddress {xxx.xxx.xxx.xxx} : cette ou ces adresses IP correspondent aux IPs virtuelles

partagees par les routeurs du meme reseau et du meme ID. La machine maıtre sera donc accessible

par le ou les IPs definies avec ce parametre

Comme KeepAlived est concu pour faire du failover (basculement sur une machine fonctionnelle lorsque

la principale est en panne), c’est un pas de plus vers l’objectif de mon stage. KeepAlived constituera par la

suite l’element indispensable pour la construction des clusters hautes disponibilites.

Olivier Picard

10.2 Mise en pratique

La prochaine etape sera de mettre en pratique avec un cas concret les techniques que j’ai apprises grace a

mes recherches sur KeepAlived. Ma tache pour le moment est de reprendre l’application qui raccourcit les

URLs (url shortener), et d’y ajouter la prise en charge du failover.

FIGURE 7: Fonctionnement de l’application URL Shortener en utilisant KeepAlived

On ne peut pas pour l’instant introduire KeepAlived dans notre cluster, car on ne dispose pas de redon-

dance. Chaque service ne dispose que d’une seule instance sur le reseau. Pour resumer, on possede une

seule base de donnees et un seul serveur Apache qui execute notre application. Notre objectif premier est

d’ajouter de la redondance, et ensuite de creer une relation maıtre/esclave entre les services redondants. Par

souci de simplicite, on duplique seulement notre application et non pas la base de donnees.

Pour ajouter une machine virtuelle et executer une copie du service sur cette nouvelle machine, seulement

quelques lignes suffisent :

docker-machine create --driver virtualbox website2

eval "$(docker-machine env website2)"

docker-compose --file docker-compose-web.yml up -d

Il faut se rappeler qu’on dispose deja de deux machines virtuelles gerees par Docker Machine. La ma-

chine qui gere la base de donnees s’appelle ‘database,‘ et celle qui execute notre application s’appelle

‘website. Ainsi grace aux lignes de commandes ci-dessus, on ajoute la machine ‘website2. On peut verifier

que tout fonctionne correctement en accedant via un navigateur a notre application en utilisant l’adresse IP

de website‘et de l’adresse IP de ‘website2‘.

Maintenant qu’on dispose de deux machines qui executent l’application, on peut utiliser KeepAlived pour

ajouter la relation de master/slave entre ces deux dernieres.

On se connecte en ssh aux machines website‘et website2. Ensuite, on utilise les depots officiels pour

installer KeepAlived. Une fois telecharge et installe, on peut proceder a la configuration de ce dernier en

utilisant les parametres que j’ai decrit dans les recherches que j’ai effectuees. A present, je peux configurer

les machines de la meme facon que ci-dessous :

— state MASTER : defini pour les deux machines. Quand un esclave devient maıtre, il garde son etat

jusqu’a sa ”mort”

— interface eth0 : defini sur les deux machines. Donc KeepAlived s’executera sur l’interface eth0

— Pour la priorite des routeurs virtuels :

— priority 100 : pour ‘website‘la priorite est 100

— priority 150 : pour ‘website2‘ la priorite est 150

— virtual ipaddress {192.168.1.10} : cette adresse IP est partagee par ‘website‘et website2. On pourra

par consequent acceder a notre application avec cette adresse IP.

Avec cette configuration, l’application est maintenant bien disponible en utilisant l’adresse IP virtuelle.

A present, l’application dispose de ce que l’on qualifie d’adresse de service.

Pour simuler une panne, j’eteins une des machines au hasard en essayant d’acceder a l’application de

raccourci d’URL. Tout se deroule comme prevu, et notre service a bien bascule sur la machine la moins

prioritaire. De cette maniere l’application reste disponible, meme si l’une des machines est en panne. Si l’on

souhaite creer encore plus de disponibilites en ajoutant un esclave supplementaire, il suffit juste de suivre la

meme procedure que celle presentee.

10.3 Demarrage sur une IP fixe

En tenant compte du contexte de la DSI, le deploiement tel que decrit ci-dessus ne serait pas adequat.

Quelques particularites sont a prendre en compte. La methode que j’utilise permet aux services d’ecouter sur

l’ensemble des adresses d’un port specifique. En d’autres termes l’application ecoute sur l’IP 0.0.0.0 . Par

exemple si la machine dispose de plusieurs adresses IP, notre service sera accessible sur l’ensemble des IP

de la machine. Mon tuteur m’a explique qu’a la DSI, l’organisation des services oblige le deploiement de ces

derniers sur une adresse IP fixe (definie a l’avance). Ainsi, les services deployes doivent etre accessibles sur

une ou plusieurs IP definies manuellement. Apres beaucoup de recherches dans la documentation officielle

de Docker, j’ai trouve que ce dernier permet nativement de bind (lier) un service sur une adresse IP. La

syntaxe est la meme que celle utilisee pour faire des sockets UNIX docker ps. a savoir adresseIP:port

10.4 Bind sur une adresse qui n’existe pas

Le lien entre KeepAlived et le demarrage d’un service sur une IP fixe represente un probleme majeur qui

n’est pas visible a premiere vue. On dispose de deux machines sur lesquelles sont installees KeepAlived.

Olivier Picard

Ces deux machines qui executent l’application ont un lien master/slave, et se partagent une adresse IP

virtuelle. En d’autres termes, l’IP virtuelle n’est pas disponible sur les deux machines en meme temps, c’est

KeepAlived qui attribue l’IP automatiquement. Cette IP est toujours attribuee a la machine la plus prioritaire

en activite. La question est de savoir comment demarrer notre service sur une IP fixe? Sachant que la

machine esclave ne dispose pas de l’IP virtuelle tant que la machine maıtre fonctionne. Plus simplement, il

faut attendre que la machine la plus prioritaire soit en panne pour que l’IP virtuelle (l’IP fixe) soit definie sur

la machine esclave. Par consequent, lorsque l’on essaie de demarrer le service Docker sur le maıtre, tout ce

passe bien parce qu’il dispose de l’IP virtuelle. Mais en ce qui concerne la machine esclave, le deploiement

echoue. Docker refuse de bind sur une adresse qui n’existe pas. Ce qui fait qu’on ne dispose que d’une seule

machine operationnelle, et tout l’interet d’utiliser KeepAlived est perdu.

Le probleme peut a premiere vue etre une mauvaise configuration de Docker, ou un parametrage man-

quant pour ce dernier. Mais il s’avere que c’est surtout un probleme systeme. Avec Linux (Debian) on

dispose d’un parametre qui permet de modifier ce comportement et d’autoriser a une application d’ecouter

sur une adresse IP qui n’existe pas.

Dans le fichier ‘/etc/sysctl.conf‘on ajoute la ligne suivante

net.ipv4.ip_nonlocal_bind = 1

Maintenant on peut relancer le service sur la machine esclave, et docker reussira a demarrer l’application

avec succes. La raison pour laquelle Linux refuse de bind sur une adresse qui n’existe pas est simple.

Si une adresse IP n’existe pas, l’application qui utilise cette adresse inexistante ne recevra aucun paquet.

Pour eviter d’avoir des applications dont on est sur qu’elles ne recevront pas de trafic, Linux bloque ce

comportement par defaut.

11 Configuration d’un cluster de machines virtuelles

Ma tache principale a ete de me concentrer sur le deploiement manuel des applications. Cela m’a permis

de comprendre plus precisement le fonctionnement de Docker, et surtout d’en savoir davantage de la confi-

guration des services dispatches sur differents serveurs. L’objectif de mon stage est d’apprendre a deployer

des services automatiquement. Ainsi moins d’etapes manuelles sont requises, et les sources d’erreurs sont

par consequent reduites.

Pour l’instant j’utilise des machines creees et automatiquement configurees par Docker Machine, ce qui

accelere ma vitesse de travail. Bien que facile d’utilisation, ces machines ont le desavantage de ne pas dis-

poser de Debian Buster. Par consequent, l’environnement de tests est tres eloigne de celui de production.

De plus, je travaille sur mon ordinateur personnel et j’utilise une machine virtuelle Linux pour concevoir

les services. Ainsi lors de la creation d’environnement avec Docker Machine, ce dernier cree une nouvelle

machine virtuelle. Par deduction, on a une machine virtuelle a l’interieur d’une autre machine virtuelle, ce

qui n’est pas ideal pour les performances.

Par la suite, j’ai ete amene a creer plusieurs VM (Virtual Machines ou en francais Machines Virtuelles)

separees les unes des autres, un peu comme si je disposais de plusieurs serveurs. Toutefois avec cette

methode, il m’a fallu faire face a un nouveau defi, celui de faire communiquer toutes les machines entre

elles. Dans la pratique, il faut installer manuellement Docker, Docker Compose, Docker Machine, Kee-

pAlived, et quelques autres logiciels. Il n’y a pas de reelles differences entre les machines creees par Do-

cker Machine et celles creees manuellement. Toujours dans l’optique de disposer d’un environnement de

developpement le plus proche possible de celui de la production, la mise en place d’un DNS est requis. Ce

qui nous mene au chapitre suivant.

Olivier Picard

12 Domain Name System (DNS)

FIGURE 8: Schema tres simplifie illustrant l’utilite d’un DNS (image provenant de ’kinsta.com’)

12.1 Theorie et raisons

Qu’est-ce qu’un Domain Name System (DNS[15][16])? Le DNS permet de faire correspondre un

nom de domaine a une adresse IP. Par exemple : le nom de domaine google.com‘correspond a l’adresse IP

‘172.217.170.46.

En quoi le DNS est utile pour mon stage? Pour me rapprocher le plus possible de l’environnement de

production, mais aussi parce qu’il est plus facile de memoriser un nom de domaine plutot qu’une adresse

IP. Si le nom est court, il est plus facile et rapide a taper, donc je peux enchaıner les tests plus rapidement.

Comment la creation d’un DNS me rapproche plus de l’environnement de production? Lorsque je

cree un service, si celui-ci est dependant d’un service non dockerise, alors il est necessaire d’y acceder par

une adresse IP. Mais comme je me trouve dans un environnement de developpement, l’adresse IP que je

vais fournir correspondra a l’adresse d’une de mes machines, et non pas a celle de production. Ainsi lors du

deploiement reel en production, il y aura de tres nombreuses modifications a apporter au code, ce qui peut

etre source d’erreurs. L’utilisation d’un DNS est necessaire, car au lieu d’acceder au service non dockerise

par une IP, j’y accede par un nom de domaine. Ce nom de domaine correspond a celui utilise en production,

et masque ainsi l’adresse IP du service. Par exemple : si je dispose d’une machine locale avec le nom de

domaine ‘univ-reunion.fr, les services qui utilisent cette adresse accedent en realite a ma machine locale et

non pas aux services de l’Universite. Maintenant si je bascule mon application en production sans aucune

modification, le nom de domaine univ-reunion.fr‘correspond a une machine de l’universite de la Reunion.

Le meme concept peut etre utilise pour la creation de registry Docker, dont je parlerai plus tard.

La creation de DNS n’est pas nouveau pour moi, puisque dans le cadre de mon cursus scolaire, j’en avais

deja concu un. Ce fut pour moi l’occasion de refaire cette experience, et aussi de valider mes connaissances.

12.2 Mise en pratique

Pour la creation du DNS, j’ai choisi d’utiliser la technologie Bind9. Il faut savoir qu’il en existe une autre

appelee dnsmasq‘ qui est plus legere, qui demande moins de configurations et surtout plus adaptee a un petit

reseau comme le mien. J’ai prefere ne pas utiliser cette derniere, parce que la construction d’un DNS n’est

aucunement l’objectif principal du stage. Par consequent, l’approfondissement de mes connaissances sur

bind9 me paraissait plus judicieux, plutot que de m’aventurer dans des configurations inconnues, et risquer

de perdre du temps sur cet outil. En revanche, il est important de noter que meme si le DNS ne fait pas parti

des objectifs de mon stage, sa creation reste pratique et permet un gain de productivite.

Je dispose de quatre machines en plus de la VM sur lesquelles je concois les applications. Voici une liste

des machines ainsi que leur futur nom de domaine associe a une adresse IP

— dmt1 – nom de domaine : dmt1.vm – IP : 172.16.146.133

— dmt2 – nom de domaine : dmt2.vm – IP : 172.16.146.135

— dmt3 – nom de domaine : dmt3.vm – IP : 172.16.146.136

— reg – nom de domaine : reg.vm – IP : 172.16.146.134

Les machines dmt1, dmt2, dmt3 sont des serveurs virtuels reserves pour les tests. Bien que la machine

reg peut aussi etre utilisee pour les tests, cette machine est reservee a un usage plus specifique telle que

l’accueil du Bind9 (pour le DNS) et du registry de Docker. En ce qui concerne le registry, je le decrirai dans

un autre chapitre

12.2.1 Configuration sur une IP fixe

Par defaut avec VMWare, les machines demarrent avec une IP variable qui leur est automatiquement

attribuee. Il s’agit d’un reseau prive qui regroupe toutes les machines virtuelles entre elles. Le probleme avec

les IPs variables lorsque l’on souhaite faire un DNS est que si l’on configure avec des adresses precises,

le nom de domaine finira par ne plus pointer vers les bonnes adresses. C’est pour cette raison qu’il faut

absolument disposer d’adresses IPs fixes. Toutefois il existe des methodes pour mettre a jour le DNS avec

des adresses generees automatiquement. Mais je ne vais pas m’attarder sur le sujet, puisque ce n’est pas

l’objet du stage.

Pour demarrer une machine Linux/Debian sur une IP fixe, on peut modifier le fichier de configuration

‘/etc/network/interfaces‘. Dans mon cas le reseau correspond a 172.16.146.0/24,le gateway fourni par VM-

Olivier Picard

Ware correspond a l’adresse 172.16.146.2 et le nom de mon interface reseau est ‘ens33. Alors on ajoute les

lignes suivantes au fichier de configuration de la machine ‘dmt1‘

auto ens33

iface ens33 inet static

address 172.16.146.133

netmask 255.255.255.0

gateway 172.16.146.2

Le fichier de configuration reste le meme sur les machines reg, dmt2, dmt3. Seule l’adresse IP va varier

et sera remplacee par l’IP appropriee. Se reporter a l’annexe technique C pour avoir des details sur la confi-

guration du DNS. Une fois le DNS en place, je peux continuer sur l’avancee de mes taches, en particulier

sur le deploiement automatique de services en utilisant Docker Swarm.

13 Kubernetes vs Docker Swarm

Mon stage repose sur l’utilisation de Docker Swarm, et cela implique donc que l’apprentissage de cette

technologie soit prioritaire. D’autant plus que la majeure partie des conteneurs sur les clusters de l’Uni-

versite de la Reunion sont orchestres par Docker Swarm. Comme Swarm ne represente pas le meilleur

orchestrateur, je me suis pose quelques questions sur l’importance reelle de cette technologie pour effec-

tuer mon stage. Mais avant d’approfondir le sujet, il serait necessaire d’apporter quelques informations

supplementaires.

Position sur le marche : developpe a l’origine par Google, ces dernieres annees Kubernetes[17] s’est

impose comme leader dans le monde des orchestrateurs. Il est largement utilise sur les services clouds et

propose par les plus grands fournisseurs cloud du monde tels que Amazon, Google, Microsoft Azure, mais

aussi Digital Ocean et bien d’autres. Face a une si grande popularite, Docker Swarm ne peut qu’occuper

un role d’orchestrateur secondaire. En revanche malgre un retrait certain, Swarm propose des avantages qui

peuvent s’averer utiles pour certains projets.

Comparaison : pour aller droit au but, tout ce que Swarm propose comme fonctionnalites, Kubernetes

le propose aussi. En revanche, l’inverse n’est pas vrai. La majeure difference entre Kubernestes et Swarm,

reside dans le fait que Kubernetes offre beaucoup de parametres, ce qui donne aussi beaucoup plus de

possibilites. On peut citer quelques exemples :

— Repartition de charge : avec Kubernetes on peut faire de la repartition de charge manuellement si on

le souhaite, tandis qu’avec Swarm une repartition de charge automatique est imposee. En outre, la

repartition de charge avec Swarm est un peu plus rapide qu’avec Kubernetes.

— Tableau de bord : par default Kubernetes propose un espace pour surveiller le cluster. Cet espace

appele dashboard fait parti integrante de Kubernetes, tandis qu’avec Swarm cela necessite l’ajout

d’outils supplementaires.

— Prise en main : la prise en main de Kubernetes est tres compliquee en comparaison a celle de Swarm

et c’est l’un des avantages majeurs de ce dernier.

— Demarrage sur une IP statique : avec Swarm il est impossible pour le moment de demarrer un service

sur une IP statique. Tandis que Kubernetes offre par defaut la possibilite qu’un service sur un cluster

soit accessible sur une IP fixe.

Docker Swarm est tres adapte aux projets simples qui ne demandent pas des fonctionnalites tres avancees,

ce qui permet une prise en main simple et rapide. Alors que Kubernetes est plus complexe a prendre en main

et demande plus de rigueur, mais offre un panel plus etendu de fonctions.

Proposition : apres avoir pris connaissance des avantages et des inconvenients des deux orchestrateurs,

on peut a present se demander, pourquoi utiliser Docker Swarm? Est-ce qu’il ne serait pas plus interessant

d’utiliser son concurrent Kubernetes? Apres reflexion, j’ai propose a mon tuteur d’utiliser Kubernetes pour

realiser mes taches, ce qui me semblait etre de mon point de vue plus interessant. Malgre la pertinence de

cette proposition, Kubernetes ne peut etre mis en place dans l’immediat, ce qui demanderait une charge de

travail supplementaire et un remaniement des configurations deja existantes. Pour l’instant cela ne constitue

ni un besoin, ni une priorite pour l’Universite de la Reunion.

14 Docker Swarm

Comme je l’ai mentionne precedemment, Docker Swarm est un outil qui permet l’orchestration des

conteneurs au sein d’un cluster. De ce fait avec un orchestrateur, on peut deployer automatiquement des

conteneurs sur un ensemble de machines appele cluster.

Docker Swarm represente un pas important dans l’accomplissement de mes taches, etant donne que c’est

une piece maıtresse dans la construction de services hautes disponibilites.

Docker Swarm presente de nombreux avantages par rapport au deploiement manuel. On peut citer la rapi-

dite de deploiement, la cohesion facile a maintenir sur l’ensemble du cluster et l’ajustement des ressources

selon les besoins. Cependant la mise en place de Docker Swarm necessite quelques adaptations et quelques

connaissances supplementaires.

14.1 Theorie

14.1.1 Organisation

Avant de commencer, on doit disposer d’un ensemble de machines (cluster) qui sont sur le meme reseau.

Ces machines doivent etre en capacite de communiquer entre elles. Avec Docker Swarm on distingue deux

types de machines :

— Les managers (maıtre)

— Les workers (esclave)

Olivier Picard

FIGURE 9: Schema technique illustrant la relation entre les managers et les workers. (image provenant de ’docker.com’)

Afin de former un cluster, il faut au minimum un noeud manager, mais optionnellement plusieurs peuvent

etre ajoutes au cluster. Meme si plusieurs managers peuvent coexister sur le reseau, ces derniers eliront un

seul et unique leader. Le role du leader est de distribuer les taches sur les clusters en particulier sur les

workers. Autrement dit, le noeud manager leader se charge de l’orchestration, alors que les autres noeuds

managers ont pour role de distribuer les taches aux workers. Par defaut malgre leurs statuts de ’manager’,

ils executent aussi les taches au meme titre que les workers. Neanmoins il est possible d’empecher ce com-

portement, et de les utiliser exclusivement en tant que manager.

14.1.2 Image locale

Lorsqu’on utilise Docker sur une machine locale et qu’on telecharge des images dans le registry‘Docker

Hub‘, ces images sont stockees localement sur l’espace disque de la machine. Ainsi, lorsque l’on deploie

plusieurs services, les conteneurs vont verifier si une image existe localement avant d’aller la telechargee

sur DockerHub. De meme lorsque l’on souhaite construire notre propre image, on utilise Dockerfile. Une

fois construite (build), notre image est stockee sur l’espace disque de la machine, et sera recuperee a chaque

demarrage du conteneur.

14.1.3 Registry

Supposons que l’on deploie nos services sur un ensemble de noeuds. Nos services se basent sur des

images personnalisees que l’on construit a l’aide de Dockerfile et ne sont par consequent pas disponibles

sur ‘Docker Hub‘. Le probleme qui se pose, c’est que les noeuds du cluster ne savent pas ou telecharger les

images que l’on construit nous-memes. Si cette image n’est pas disponible sur ‘Docker Hub‘ ou en local,

il n’y a aucun moyen de les recuperer. Cependant, il existe une solution a ce probleme. L’utilisation d’un

registry. Un registry est un depot ou l’on stocke tous les images. Par exemple : ‘Docker Hub‘ est un registry.

Mais l’avantage d’un registry c’est qu’il peut etre cree partout. Par consequent, le registry personnalise doit

etre disponible pour l’ensemble des noeuds du cluster afin qu’ils accedent aux images .

14.2 Mise en pratique

FIGURE 10: Schema illustrant un cluster orchestre par Swarm, avec un manager, deux workers et un registry hors duswarm mais accessible pour l’ensemble des services du cluster. L’IP de chaque machine est aussi annotee

Mon objectif est de reprendre notre application ”urlshortener” (raccourci d’url) et d’utiliser Docker

Swarm pour deployer automatiquement sur le cluster la base de donnees, ainsi que notre application web

basee sur le serveur web Apache.

Pour concevoir l’application ”urlshortener”, je cree une image personnalisee avec un Dockerfile base

sur l’image php :Apache-buster. Cette image personnalisee me permet de copier mon fichier PHP dans le

conteneur, mais aussi d’installer les packages Debian pour avoir le plugin mysqli de PHP. Comme cette

image est creee par mes soins, elle n’existe que sur ma machine et ne peut etre telechargee sur DockerHub.

Par consequent, un registry est necessaire.

Olivier Picard

Sachant qu’on a deux services (une base de donnees et une application web), je vais donc choisir d’utili-

ser deux machines. On dispose alors d’un noeud manager qui sera en charge d’orchestrer, mais aussi d’un

autre noeud qui sera en charge de l’autre service. On ne peut predire par avance l’attribution des services.

C’est le swarm qui se chargera de les repartir. Toutefois, il est important de noter qu’il existe des parametres

pour deployer un service sur un noeud precis. Je detaillerai cette technique plus tard dans un autre chapitre.

Le cluster sera initialise sur la machine ’reg’, et par consequent ce noeud sera le noeud manager. Pour

initialiser le cluster Docker Swarm, on utilise la commande suivante :

docker swarm init --advertise-addr ADDRESS_IP

l’option ’init --advertise-addr ADDRESS_IP’ n’est pas obligatoire. Par contre si la machine dis-

pose de plusieurs adresses IP, Swarm ne pourra pas choisir entre les differentes IP. Outre le fait d’initialiser

le noeud en tant que manager, le resultat de la console fourni une autre commande permettant a d’autres

machines de rejoindre le cluster en tant que worker. Cette commande est a copier sur les autres machines

afin qu’elles puissent rejoindre la cluster Swarm.

Maintenant que je dispose de notre manager, je vais me charger de la creation du worker. Sur la deuxieme

machine, je colle tout simplement la commande fournie par le manager lors de l’initialisation.

docker swarm join \

--token SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atb \

ADDRESS_IP:PORT

Le cluster dispose a present d’un worker, donc la prochaine etape est de deployer notre application url

shortener sur ce cluster. Le point positif est qu’on dispose deja d’un fichier docker-compose.yml qui decrit

les services qui constituent l’application. (Voir les chapitres precedents pour le detail et la creation de ce

fichier).

Pour realiser ce deploiement il me reste a accomplir deux etapes :

1. La creation d’un registry

2. L’utilisation de docker stack qui pourra etre deploye sur le cluster Swarm.

14.2.1 Creation d’un registry

Comme decrit plus haut, un registry peut etre percu comme un depot ou l’on stocke toutes les images

necessaires aux clusters. En particulier les images qui ne peuvent etre telechargees sur le registry par defaut.

Bien qu’a premiere vue les registry semblent etre tres techniques, ils constituent un element fondamental

dans la mise en place de services hautes disponibilites. Concevoir des services qui s’adaptent aux besoins

et resistent aux pannes, c’est le role principal de Docker Swarm. Mais avant de deployer sur le Swarm, il

faut comprendre ce qu’est un registry? Quel est son fonctionnement? Mais aussi pourquoi les registry sont

essentiels a Docker Swarm? L’aspect technique joue un role important dans la conception, mais aussi dans

la comprehension de la mission dans son ensemble. Il est aise de mettre en place un registry non securise

et disponible uniquement en local. Mais la tache se complexifie lorsque l’on tente de le rendre accessible

depuis l’exterieur.

Registry local : ce type de registry est accessible uniquement en local. Ce qui en d’autres termes si-

gnifient qu’aucune machine ne peut y acceder. L’interet de ce type de registry est assez limite, mais peut

malgre tout etre utilise durant le developpement pour effectuer des tests. Pour deployer un registry local, on

peut utiliser la commande ci-dessous :

docker run -d -p 5000:5000 --name registry registry:2

Registry accessible a distance : ce type de registry est un peu plus complexe a mettre en place, mais

beaucoup plus utile. Bien que j’ai etudie les deux types de registry, je me pencherai plus vers les registry

qui autorisent les connections distantes. Un registry contient une majeure partie des elements du cluster, et

par consequent les donnees qu’il contient est potentiellement sensibles. Pour cette raison, si l’on souhaite

acceder a un registry depuis une autre machine, il faut absolument utiliser le protocole TLS. En resume, ce

protocole permet de chiffrer les donnees qui transitent sur le reseau. Afin que ce protocole puisse securiser

la connection, il faut lui fournir ce que l’on appelle des certificats. Pour ce travail, je vais generer des ”cer-

tificats auto-signes”. En d’autres termes, je cree moi-meme le certificat au lieu de passer par une autorite

de certification. Les certificats auto-signes ne doivent pas etre utilises en production. Je le fais uniquement

dans le cadre de mes tests.

Pour des informations detaillees sur la configuration d’un registry distant avec certificat auto-signe se

reporter a l’annexe D : creation d’un registry

Il faut savoir que l’Universite de la Reunion possede deja son propre registry. Quelques images essen-

tielles au bon fonctionnement de l’organisme y sont stockees. Ainsi durant la phase de production, je ne mets

pas en place cet element. Par contre, je dois etre capable de configurer un registry pour simuler l’environne-

ment de production, et etre a meme de comprendre le fonctionnement general pour pouvoir eventuellement

lire les codes deja existants.

14.2.2 Deploiement des stacks

Meme si la machine de deploiement fait partie du cluster Swarm, un deploiement classique avec Docker

Compose ne permettra pas a l’application d’etre executee dans le Swarm. Il sera juste execute localement.

Pour un deploiement avec Swarm, il faut creer des stacks. Ce sont ces stacks qui vont etre orchestres par

le manager du cluster. Une fois le registry fonctionnel, le deploiement se fait seulement a l’aide de la

commande :

docker stack deploy --compose-file docker-compose.yml $NOM_DU_STACK

Olivier Picard

Maintenant que l’application est disponible sur le cluster et orchestree par docker swarm, je peux introduire

le prochain chapitre sur les ”reverse proxy” qui abordera une methode pour acceder a notre application.

15 Traefik

FIGURE 11: Illustration du reverse proxy Traefik. L’illustration montre la liaison entre internet et l’infrastructure quel’on deploie

Traefik[18] est un reverse proxy concu en France qui concurrence le celebre NGINX[19].

15.1 Definition

Un reverse proxy est un intermediaire qui accueille les requetes des utilisateurs depuis internet, et les

redirige sur le service approprie. Il se situe du cote serveur et peut etre utilise pour divers usages tels que :

— la compression de donnees

— pour verifier qu’un utilisateur est correctement authentifie

— pour faire de la repartition de charge

— pour diriger une requete vers le bon service au sein d’un cluster

15.2 Pourquoi un reverse proxy ?

Lorsque l’on deploie un ensemble de services sur un cluster, on peut rendre chacun d’entre eux acces-

sible depuis l’exterieur en ’bindant’ un conteneur sur un port et une addresse IP. Ainsi on dispose de nom-

breuses IPs et ports differents. En revanche, plus les services sont nombreux, plus ca devient complique

de s’y retrouver. C’est a ce moment qu’intervient le reverse proxy. Il permet de creer et de reunir tous

les services d’un cluster autour d’un nom de domaine. Donc on peut acceder a certains services en utilisant

’http://service.univ-reunion.fr/nom_service’ ou sinon ’http://univ-reunion.fr/nom_service’.

L’acces aux services clusterises de l’Universite de la Reunion est ainsi grandement facilite a la fois pour le

client, mais aussi pour des services d’un autre cluster.

FIGURE 12: Schema representant mon objectif pour la realisation et la composition du cluster. Traefik agit commepoint d’entree du cluster. Il permet de configurer l’acces aux services tels que URL Shortener et MariaDB avec desURLs personnalisables.

15.3 Rapide etat de l’art

Bien evidemment Traefik n’est pas le seul reverse proxy qui existe sur le marche, et ce n’est pas le plus

populaire. Celui qui est le plus utilise est le reverse proxy Nginx qui a vu sa popularite augmenter, en parti-

culier grace a son serveur web bien plus performant que celui de Apache. Il est facile de trouver de la docu-

mentation pour Nginx, car la communaute est bien plus grande autour de ce dernier. Par consequent, malgre

des configurations assez complexes et peu flexibles, il est aise de trouver des solutions aux problemes. Il

existe encore bien d’autres technologies, dont on peut citer notamment HAProxy et Squid. Je ne me suis pas

attarde sur Squid, mais par ailleurs HAProxy au meme titre que NGinx est tres bien documente et dispose

d’une assez large communaute. Toutefois Traefik gagne progressivement en popularite, grace a sa simplicite

Olivier Picard

d’utilisation.

15.4 Les avantages de Traefik

Traefik est concu pour fonctionner avec Docker. D’ailleurs, il est fourni sous la forme d’un conteneur.

Le but de Traefik est de faciliter la configuration d’un reverse proxy en se basant sur les technologies de

cluster les plus connues. On peut citer notamment Docker Swarm, Kubernetes, AWS, Docker... Malgre la

popularite de Nginx, Traefik reduit tellement les configurations, qu’il devient une alternative viable. Traefik

permet de s’affranchir de la majorite des configurations par ses capacites a decouvrir automatiquement son

environnement. Des lors ou l’on utilise un orchestrateur de cluster, Traefik s’avere etre un tres bon choix.

En revanche, Nginx est la technologie la mieux documentee et la plus viable pour les infrastructures avec

des configurations statiques.

15.5 Pourquoi choisir Traefik

A ce stade, Traefik est la technologie qui est retenue pour que je puisse effectuer mon travail. Mais la

raison supplementaire qui m’a pousse a adopter cet outil, c’est que l’Universite de la Reunion dispose deja

de cluster qui utilise Traefik. Donc mon travail viendra s’integrer a une architecture deja existante. Il me

semble important de rappeler que l’une des contraintes de mon stage est de deployer et d’automatiser autant

que possible chacune des taches, afin de minimiser les sources d’erreurs. Comme Traefik a la particularite

de reduire le nombre de configurations, il s’integre donc parfaitement a cette problematique, ce qui n’aurait

pas ete le cas de Nginx.

15.6 Difficultes

J’ai depeint tous les avantages de Traefik, aussi je souhaite mentionner les nombreuses difficultes que

j’ai rencontrees avec cette technologie. Bien qu’une documentation soit fournie, mais dans la plupart des

cas lorsque l’on sort des sentiers battus, cette documentation est loin d’etre suffisante. Seules les informa-

tions les plus essentielles sont presentes. En revanche, si l’on utilise de pair Traefik et Kubernetes, il y a

plus d’informations, et on peut resoudre les problemes plus facilement. Lors de mon stage, mon tuteur m’a

demande d’utiliser la combinaison Traefik + Docker Swarm ce qui est bien moins populaire et donc limite

grandement les articles sur le sujet.

16 ProxySQL

FIGURE 13: Shema provenant de site officiel de ProxySQL, illustrant une configuration de base de donnees Mysqlincluant ProxySQL. Cette illustration montre une configuration avec une base de donnees en ecriture et trois bases dedonnees Mysql en lecture

16.1 Fonctionnalites

Comme son nom l’indique, ProxySQL[20] est un proxy pour les bases de donnees SQL. Mais concretement

ProxySQL est utile pour :

— Le failover (la redirection du trafic vers un noeud sain en cas de panne d’une base de donnees)

— Le sharding (le decoupage d’une grande base de donnees en plusieurs petites bases de donnees)

— Faire office de pare-feu pour les donnees

— Separer les requetes en lecture de ceux en ecriture, et les attribuer aux noeuds du cluster appropries.

J’ai aussi utilise la separation et la redirection des requetes selon leur nature, ce qui m’a permis de les ”load

balancer” intelligemment. Je reviendrai plus tard en detail sur ce point dans le rapport.

16.2 Rapide etat de l’art

Par consequent, ProxySQL est celui que je connais le mieux et dont je m’en suis servi. Concernant ce

domaine, l’Universite de la Reunion dispose deja de services utilisant ProxySQL, c’est une des raisons

Olivier Picard

majeures pour laquelle cette technologie m’a ete utile pour mon travail. Toutefois ProxySQL n’est pas le

seul proxy pour les bases de donnees Mysql sur le marche. Son concurrent le plus connu est HaProxy.

Comme on l’a vu dans le chapitre sur les reverses proxy, HaProxy fait aussi office de reverse proxy. Ha-

Proxy dispose d’une grande communaute, par consequent la resolution de bugs est facilitee. Par ailleurs,

la separation des requetes en lecture de ceux en ecriture demande un peu plus d’efforts a mettre en place

avec HaProxy. Comme ProxySQL s’est impose a moi de par les differentes contraintes, je n’ai pas etudie

davantage HaProxy. Lors de mes recherches sur la separation des requetes en lecture de ceux en ecriture,

j’ai vu beaucoup plus de tutoriels avec HaProxy, qu’avec ProxySQL.

17 Replication Manager

Replication Manager[21] est un outil qui permet de configurer automatiquement un ensemble de base de

donnees. Cet outil permet d’ajouter et de configurer un proxy tel que HaProxy ou ProxySQL. Les confi-

gurations necessaires pour faire fonctionner Replication Manager restent minimales. Juste avec quelques

configurations, je peux creer un cluster de base de donnees avec la relation maıtre-esclave.

17.1 Mission

L’objectif etant de concevoir des clusters hautes disponibilites composes de trois bases de donnees Ma-

riaDB, ainsi qu’un proxy ProxySQL, le tout conteneurisees avec Docker pret a etre deployees avec Swarm.

Une des contraintes est de minimiser les configurations manuelles, afin de diminuer les sources d’erreurs.

Pour ce travail, j’ai ete assiste de mon tuteur puisque cela demande de maıtriser de nombreuses competences

a la fois. Pour effectuer cette tache, j’ai du comprendre et acquerir quelques rouages de l’administration de

base de donnees. A cette occasion, j’ai pour la premiere fois configure manuellement les bases de donnees

avec une relation maıtre-esclave. J’ai aussi donne les droits d’acces en ecriture au maıtre et les droits en

lecture aux esclaves. Ces bases de donnees sont repliquees et communiquent entre elles afin de se partager

les donnees de la base. Repliquer les donnees sur plusieurs bases est une technique qui permet d’effectuer

du load balancing, mais il existe d’autres methodes. Une des methodes s’appelle le sharding, mais son uti-

lisation presente quelques risques.

17.2 Sharding Mysql

Le sharding permet de repartir les donnees sur plusieurs machines pour assurer la mise a l’echelle de

l’architecture. Le concept est relativement simple, sauf que dans les faits, cela implique de nombreux

risques. Plus precisement le sharding Mysql consiste en une partition d’une table Mysql. Chaque parti-

tion est stockee sur des serveurs differents. Le but final du sharding est de faire du load balancing. Sauf

qu’il demande de nombreux changements, notamment sur les schemas, les index. En l’occurrence, je n’ai

pas utilise cette technique pour mon travail, mais je trouve interessant de partager le resultat de mes re-

cherches.

17.3 Le choix de l’architecture

L’architecture du systeme utilise trois machines. A savoir deux esclaves et un maıtre. Pourquoi faut-il

choisir cette configuration? Pour quelle raison utilise-t-on seulement deux machines? Pourquoi avoir un

seul maıtre ? C’est autant de questions que l’on peut se poser.

17.3.1 Pourquoi avoir un cluster de trois machines

Dans l’architecture du cluster, les trois machines permettent de faire du load balancing et du failover.

Si l’on reflechit plus longuement, avec seulement deux machines, il est aussi possible de faire du load ba-

lancing et du failover. Alors a quoi sert la troisieme machine? Je propose qu’on se mette en condition reelle.

Supposons que notre cluster dispose que de deux machines. Notre cluster est fortement sollicite. Par

consequent, le load balancing permet grandement d’alleger le serveur en repartissant la charge de travail

sur les deux serveurs. Imaginons maintenant qu’un de nos serveurs tombe soudainement en panne, il ne

reste donc plus qu’une seule machine. Comme il ne reste qu’un seul serveur, le load balancing n’est plus

fonctionnel, et la totalite du trafic doit etre pris en charge par l’unique noeud du cluster. De ce fait, de nom-

breux ralentissements peuvent se faire ressentir.

Maintenant, imaginons que l’on dispose de trois noeuds sur notre cluster. Si l’un des noeuds est en panne,

il reste deux machines saines sur le cluster. Si la charge de travail est elevee, le load balancing est en place

pour repartir les operations entre les deux noeuds. Ce qui fait qu’avec trois machines et malgre la panne

d’un serveur, les services restent hautement disponibles. Meme si la probabilite que deux machines tombent

en panne en meme temps soit faible, il reste une machine disponible pour s’assurer que le service reste ac-

cessible. En revanche avec deux machines si les deux noeuds sont en panne, les services n’existent plus.

17.3.2 Pourquoi avoir un seul maıtre sur le cluster

On peut remarquer que dans l’architecture des bases de donnees, on retrouve un seul maıtre et deux es-

claves sur le cluster. Or, il est tout a fait possible d’avoir des configurations avec plusieurs bases de donnees

maıtres (master). Comme je l’ai decrit plus haut, il est preferable d’avoir trois machines dans notre cluster

afin d’assurer une haute disponibilite. Mais pourquoi ne pas avoir deux bases de donnees maıtre et un seul

esclave? Afin de repondre a la question on va se plonger dans le contexte reel.

Supposons qu’on dispose d’un cluster avec deux masters (maıtres) et un seul slave (esclave). Avec ce

Olivier Picard

type de configuration, il n’y pas reellement de problemes majeurs si les bases de donnees sont correctement

configurees. Toutefois, cette configuration presente malgre tout un risque qui s’appelle le ”split brain”.

Avant d’aller plus loin, il faut d’abord definir la raison pour laquelle on utilise la relation maıtre esclave.

Il faut savoir que les bases de donnees maıtre ont les pleins pouvoirs sur les donnees. Autrement dit, ils sont

en capacite a la fois d’ecrire, mais aussi de lire les donnees de la base de donnees. Quant aux esclaves, ils

sont plus limites, ils ont seulement le droit de lecture des donnees. Du coup, ils ne peuvent effectuer aucune

modification. Ainsi les requetes qui impliquent la modification des donnees prises sont en charge par le

maıtre et les requetes qui n’impliquent aucune modification sont receptionnees par les esclaves.

Cela depend du service, mais en regle generale il y a toujours plus d’operations en lecture qu’en ecriture.

A mon avis, il semble interessant de mettre plus de serveurs dedies a la lecture qu’a l’ecriture, car on peut

effectuer du load balancing sur les esclaves, et les bases de donnees ne sont pas submergees par le trafic.

Ces explications posent les fondations de notre reflexion sans pour autant repondre a la question : ”Pour-

quoi avoir un seul maıtre sur le cluster ?”. Si nous prolongeons notre mode de reflexion, on peut constater

qu’il est possible de faire du load balancing sur les bases de donnees maıtres. Cette methode aura les memes

resultats que d’avoir deux esclaves. Ce que je n’ai pas mentionne jusqu’a present, c’est que dans une rela-

tion maıtre-esclave, les donnees sont repliquees sur l’ensemble du cluster. Ainsi les esclaves et les maıtres

disposent des memes donnees. Maintenant que l’on dispose de toutes les fondations necessaires, on peut

expliquer le phenomene ”split-brain”.

Dans le contexte ou l’on a deux masters qui sont load balancer, chacun d’entre eux va ecrire les donnees

sur leur propre base de donnees. Ensuite, ils vont les repliquer vers l’autre master. Supposons a present qu’il

y a une erreur de communication entre eux. Cela aura pour consequence que chacun ecrira les donnees de

leur cote sans pouvoir informer l’autre maıtre des modifications effectuees. Ils auront donc des bases de

donnees differentes les unes des autres. Si maintenant la connexion entre eux est retablie, ils vont alors

resynchroniser les donnees. Cependant comme les donnees sont differentes, il ne sera pas possible de fu-

sionner les modifications. Le fait d’avoir chaque base de donnees qui fonctionne separement, plutot qu’en

lien l’une avec l’autre est appele ”split-brain”. Toutefois, il est important de noter qu’il existe des algo-

rithmes qui permettent de fusionner les donnees.

Pour eviter le ”split-brain” et garder une conception simple du cluster. La configuration avec un master et

deux slaves paraıt la plus appropriee, puisque les esclaves ne sont pas autorises a ecrire les donnees. Donc

si la connexion se perd, une simple replication permet d’ajouter les donnees manquantes.

17.4 Pourquoi utiliser replication manager

Maintenant que l’on a vu les raisons qui ont conduit a concevoir une architecture a trois machines,

avec deux masters et un slave, il semble opportun de donner plus de details de Replication Manager. Pour

l’instant, j’ai fait les configurations des bases de donnees manuellement afin de mieux assimiler l’aspect

technique. Le but etant d’utiliser Replication Manager de maniere qu’il configure automatiquement un

cluster de base de donnees. C’est a dire qu’aucune, ou peu d’interventions manuelles soient requises pour

eviter les sources de bugs.

Je dispose de trois machines qui executent MariaDB et qui fonctionnent independamment les unes des

autres. L’interet est de configurer Replication Manager pour qu’il puisse automatiquement prendre connais-

sance de son environnement et configurer a son tour les bases de donnees avec la relation maıtre-esclaves.

17.5 Difficultes

Avec Replication Manager, les difficultes ont ete tres nombreuses. Je dirai que c’est l’outil qui m’a pose

le plus de problemes. Heureusement que pour certaines taches, j’ai pu compter sur l’aide de mon tuteur.

Pour expliquer simplement, Replication Manager est un outil sans documentation. Ou du moins ce qui

fait office de documentation est tres minimale, et liste simplement les fonctionnalites les plus importantes

en les decrivant de facon tres succinctes. J’ai pu constater que les explications qui y sont donnees visent

des utilisateurs qui ont deja des connaissances poussees dans l’administration de base de donnees. Pour

avoir une vision complete du probleme, l’organisme qui a concu Replication Manager ne fournit pas une

documentation complete pour la simple et bonne raison que le support est payant pour l’integrer dans

un systeme existant. Malgre tous ces inconvenients, Replication Manager dispose de nombreux exemples

(fichiers de configuration) qui aident a la comprehension,

18 Tests du cluster MariaDB

Cette etape joue un role majeur avant la mise en production car elle determine la fiabilite du cluster.

Contrairement aux missions precedentes, cette partie se base sur des connaissances que je possedais avant

le stage. Afin d’etre le plus proche possible de ce qui existe deja en production, je me base sur un squelette

fourni par mon tueur.

Ce squelette est constitue des elements principals au fonctionnement de la base de donnees MariaDB.

Plusieurs choix sont disponibles afin de deployer plus ou moins efficacement la base de donnees. On pour-

rait par exemple effectuer un changement dans la topologie, comme avoir deux Masters et un esclave, au

lieu d’un master et deux esclaves. On peut aussi remplacer ProxySQL par HAProxy. Ce ne sont la que

quelques exemples des choix possibles que l’on peut effectuer sur le cluster.

Pour resumer tres brievement, j’ai pour but de guider ces choix. Pour ce faire, je dois mettre en place une

serie de tests afin d’obtenir des resultats concrets pour prendre les bonnes decisions. Chaque element doit

Olivier Picard

etre au maximum automatise. L’interet du programme est de pouvoir mesurer les effets d’une panne sur le

systeme. Le but du cluster etant de ne pas perdre des donnees lors d’un incident dans le systeme. En plus

des fonctionnalites citees plus haut, l’algorithme doit aussi tester les performances du cluster MariaDB en

affichant un rapport avec le nombre d’operations par seconde.

19 Conclusion

Ce stage m’a donne l’opportunite de travailler sur un projet deja en production et utilise par de nombreux

utilisateurs. Grace a cette experience, j’ai acquis de nombreuses methodes de travail qui me seront utiles

pour gagner en productivite, ainsi qu’a l’amelioration de la maintenance des applications. Ces connaissances

m’ont permis de realiser que l’automatisation des deploiements est une etape importante a ne pas negliger, et

qui doit etre integree aussi tot que possible. Avant meme de commencer le developpement d’une application,

j’essaie dorenavant de reflechir a la gestion des erreurs, afin de diagnostiquer au plus tot les pannes et les

comportements anormaux du programme. Bien que cela est illusoire de penser que toutes anomalies soient

detectees, la gestion d’erreurs aide dans quelques cas a detecter precisement la provenance du probleme.

Outre les methodes acquises, ce stage m’a permis de decouvrir le DevOps qui est une pratique de plus en

plus demandee en entreprise, grace a sa philosophie de deploiement continu. Pour le cluster MariaDB haute

disponibilite a deployer, il ne me reste qu’une seule etape. Cette etape concerne la realisation des tests de

montee en charge et de fiabilite qui determineront si la base de donnees est autorisee a entrer en phase de

production.

Olivier Picard

20 Annexes techniques

20.1 Annexe A : mise en place de Docker et Docker Compose

Notre fichier ”docker-compose.yml” se presente de la facon ci-dessous :

version: "3.7"

services:

db:

image: mariadb:latest

volumes:

- database:/var/lib/mysql

urlshort:

image: php:apache-buster

port:

- 8080:80

volume:

- ./index.php:/usr/src/index.php

volumes:

database:

Le fichier ”docker-compose.yml” ci-dessus permet de creer en quelques lignes a la fois la base de donnees

et l’application ”url shortner”. On dispose de deux services,

— Service ”db”

— ”image : mariadb :latest” : recupere l’image la plus recente de mariaDB sur DockerHub grace a

la commande.

— ”volumes” : de part l’utilisation des volumes, on peut conserver de maniere persistante nos

bases de donnees, ainsi que les tables et toutes les donnees qu’elles contiennent. En l’occur-

rence, on conservera dans le volume ”database” les fichiers du conteneur situes dans le repertoire

”/var/lib/mysql”

— Service ”urlshort”

— ”image : php :apache-buster” : ensuite, on definit le service ”urlshort” qui correspond a l’appli-

cation que l’on concoit. Comme mentionne precedemment, on se base sur une image PHP qui

utilise un serveur Apache base sur Debian Buster. Tout comme pour le service ”db”, l’image sera

recuperee sur le DockerHub.

— ”port : - 8080 :80” : par defaut le serveur Apache ecoute sur l’ensemble des adresses, c’est a

dire sur 0.0.0.0 et sur le port 80. En sachant que le serveur Apache se trouve dans un conteneur,

il ecoute donc sur l’adresse 0.0.0.0 et le port 80 a l’interieur du conteneur. Le but ici est de

rendre accessible le port 80 du conteneur vers l’exterieur. C’est dans cette optique que l’on utilise

l’instruction ”port : - 8080 :80”. En d’autres termes, le port 80 du conteneur sera accessible depuis

l’exterieur sur le port 8080.

— ”volumes : ./index.php :/usr/src/index.php” : la particularite de ce service se situe au niveau du

volume. Dans ce contexte, le volume permet de copier notre fichier ”index.php” a l’interieur

de notre conteneur. Dans notre conteneur, on peut donc retrouver le fichier index.php dans le

repertoire /usr/src/ .

— ”Le volume database” : a la fin du fichier, on retrouve le nom du volume utilise par le service urlshort.

On specifie le nom du volume ”database” dans la section volumes a la fin du fichier, de maniere a le

conserver meme lorsque le conteneur est arrete. Si cette etape n’est pas effectuee, alors les donnees

de notre volume ne sont pas conservees.

Olivier Picard

20.1.1 Annexe B : deploiement manuel sur hote distant - Configuration

La conception est assez rudimentaire et reprend tous les elements de la precedente version de ”urlshor-

tener”. Seul le fichier docker-compose.yml est scinde. Ainsi on obtient deux fichiers YAML pour Docker

Compose. Le premier fichier contient le service qui est en charge de la base de donnees et sera execute sur

la machine numero une. Tandis que le second fichier contient la description de notre application web, ainsi

que celle du serveur Apache qui sera executee sur la machine numero deux.On cree deux machines virtuelles a l’aide de Docker Machine

docker-machine create --driver virtualbox database

docker-machine create --driver virtualbox website

On cree notre fichier ‘docker-compose-db.yml‘ qui demarre la base de donnees MariaDB

version: "3.7"

services:

db:

image: mariadb:latest

volumes:

- database:/var/lib/mysql

volumes:

database:

Ensuite, on cree notre fichier ‘docker-compose-web.yml‘qui demarre le serveur Apache et le site web quiraccourcit les URLs. Le site web est constitue d’un simple fichier ‘index.php‘

version: "3.7"

services:

urlshort:

image: php:apache-buster

port:

- 8080:80

volume:

- ./index.php:/usr/src/index.php

Et enfin, j’execute les deux fichiers docker-compose sur les machines appropriees pour demarrer lesserveurs.

eval "$(docker-machine env database)"

docker-compose --file docker-compose-db.yml up -d

eval "$(docker-machine env website)"

docker-compose --file docker-compose-web.yml up -d

Maintenant, notre site web est accessible via l’adresse IP donnee par la commande ci-dessous

docker-machine ip guestbook

20.2 Annexe C : configuration d’un DNS avec bind9

Pour concevoir le DNS, il faut ajouter des fichiers de configuration, notamment un fichier qui decrit les

adresses IP qui correspondent au nom DNS, mais aussi un autre fichier qui decrit les noms de domaine

geres par le DNS. Le DNS ne represente pas une etape primordiale dans l’evolution de mon stage. Par

consequent, seuls les points les plus importants de la creation seront mentionnes.

Je cree un fichier ‘db.docker.univ-reunion.fr.zone‘ qui comporte les entrees suivantes

NS docker.univ-reunion.fr.

@ IN A 172.16.146.134

Par la suite, je cree le fichier ‘db.vm.zone‘qui gere le nom de domaine ‘vm‘. Ce nom de domaine n’a pas

pour vocation d’etre en production, mais juste pour m’eviter de taper les adresses IP :

@ IN NS reg.vm.

reg IN A 172.16.146.134

dmt1 IN A 172.16.146.133

dmt2 IN A 172.16.146.135

dmt3 IN A 172.16.146.136

Maintenant que les fichiers zones sont crees, il reste a definir le fichier ‘named.conf.local‘.

zone "vm" {

type master;

file "/etc/bind/db.vm.zone";

};

zone "docker.univ-reunion.fr" {

type master;

file "/etc/bind/db.docker.univ-reunion.fr.zone";

};

Apres le redemarrage de bind9, on modifie le fichier /etc/resolv.conf en ajoutant ‘nameserver 172.16.146.134‘qui

correspond a l’adresse de la machine ‘reg‘.

Olivier Picard

20.3 Annexe D : creation d’un registry

La premiere etape consiste a creer un certificat. Ce dernier peut etre realise a l’aide de ’openssl’. Les

certificats vont etre crees dans le dossier certs du repertoire local.

cd ~

mkdir ~/certs/

openssl req \

-newkey rsa:4096 -nodes -sha256 -keyout certs/domain.key \

-x509 -days 365 -out certs/domain.crt

La deuxieme etape est de creer notre registry. En suivant la documentation pour mettre nos certificats a

l’interieur du conteneur, on utilise des volumes. On utilise le port 443 qui correspond au port utilise par

TLS par defaut.

docker run -d \

--restart=always \

--name registry \

-v "$(pwd)"/certs:/certs \

-e REGISTRY_HTTP_ADDR=0.0.0.0:443 \

-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \

-e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \

-p 443:443 \

registry:2

Le registry est cree, mais comme j’ai utilise un certificat auto-signe, par defaut aucune machine ne peut

acceder au registry par manque de securite. Donc, sur toutes les machines qui utiliseront ce registry, il faut

ajouter la ligne ci-dessous afin de forcer docker a utiliser ce dernier. ’/etc/docker/daemon.json’

{

"insecure-registries" : ["NOM_DU_DOMAINE.EXTENSION"]

}

21 Annexe : gestion de projet

FIGURE 14: Capture d’ecran de mon organisation avec Trello

Tout au long de mon stage, l’organisation de mes taches a ete une priorite afin d’etre le plus productif

possible, et d’organiser mon temps en consequence. J’utilise Trello[22] qui est pour moi l’outil qui me

convient le mieux. Les raisons qui justifient ce choix sont :

— La conservation de toutes mes taches dans une seule fenetre

— Un visuel attractif

— La possibilite de definir les taches en cours et celles realisees, sans oublier celles a effectuer (TODO)

— La possibilite de grouper mes missions par leur thematique

— La possibilite de definir une date limite pour terminer une tache

Trello n’est pas le seul outil qui permet d’organiser un projet. On peut citer ”GanttProject”[23] qui est un

outil base sur la methode Gant et qui permet de paralleliser au maximum les taches.

Bien que j’ai organise chacune de mes taches et defini une date limite pour leur rendu, il est tres com-

plique de planifier ce que l’on doit faire. Au debut de mon stage, j’ai etudie Docker. Docker est un outil

tres bien documente avec une grande communaute qui l’entoure. Dans ce contexte, j’ai reussi a respecter le

delai que je me suis fixe. En revanche, dans la suite de mon stage, les documentations qui accompagnent

les outils que j’utilise se rarefient de plus en plus. Des lors, le temps que je vais prendre pour comprendre

le fonctionnement de ces logiciels est beaucoup plus long que ce que j’avais initialement prevu.

Apres une utilisation quotidienne des methodes de gestion de projet, je suis mitige sur la necessite et

l’utilite de tels outils pour ma propre organisation. Les outils comme ”Trello”, ”GanttProject” sont avant

Olivier Picard

tout concus pour regrouper et organiser une equipe autour d’un projet. Pour une utilisation individuelle, le

seul avantage que j’y vois est d’utiliser Trello comme ”TODO List”. Lorsque l’on decouvre une technolo-

gie, et qu’on est en phase d’apprentissage sans avoir la maıtrise de ce que l’on fait, il y aura de nombreux

imprevus. Ainsi dans ce contexte, il me semble futile d’essayer de me fixer a moi-meme une contrainte de

temps pour finaliser mes taches. En revanche, lorsque le nombre de taches a realiser est importantes les

TODO listes peuvent s’averer utiles pour ne rien oublier.

Table des figures

1 Organigramme de la DSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Architecture micro-services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Continuous Integration et Continuous Delivery (from AWS Website) . . . . . . . . . . . . 11

4 Recuperation de MariaDB et PHP :Apache depuis Docker Hub, Construction d’une image

basee sur le Dockerfile qui contient l’application URL Shortener . . . . . . . . . . . . . . 15

5 Fonctionnement de Docker Machine (image provenant de Docker.com) . . . . . . . . . . 16

6 Schema du fonctionnement de KeepAlived montrant le role de l’IP Virtuelle (image prove-

nant du site web ’codeproject.com’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7 Fonctionnement de l’application URL Shortener en utilisant KeepAlived . . . . . . . . . . 20

8 Schema tres simplifie illustrant l’utilite d’un DNS (image provenant de ’kinsta.com’) . . . 24

9 Schema technique illustrant la relation entre les managers et les workers. (image provenant

de ’docker.com’) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

10 Schema illustrant un cluster orchestre par Swarm, avec un manager, deux workers et un

registry hors du swarm mais accessible pour l’ensemble des services du cluster. L’IP de

chaque machine est aussi annotee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

11 Illustration du reverse proxy Traefik. L’illustration montre la liaison entre internet et l’in-

frastructure que l’on deploie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

12 Schema representant mon objectif pour la realisation et la composition du cluster. Traefik

agit comme point d’entree du cluster. Il permet de configurer l’acces aux services tels que

URL Shortener et MariaDB avec des URLs personnalisables. . . . . . . . . . . . . . . . 33

13 Shema provenant de site officiel de ProxySQL, illustrant une configuration de base de

donnees Mysql incluant ProxySQL. Cette illustration montre une configuration avec une

base de donnees en ecriture et trois bases de donnees Mysql en lecture . . . . . . . . . . . 35

14 Capture d’ecran de mon organisation avec Trello . . . . . . . . . . . . . . . . . . . . . . 47

Olivier Picard

References

[1] Dsi - https ://dsi.univ-reunion.fr.

[2] Mariadb - https ://mariadb.org.

[3] Universite de la reunion - https ://www.univ-reunion.fr.

[4] Devops - https ://aws.amazon.com/fr/devops/what-is-devops/.

[5] Debian - https ://www.debian.org.

[6] Mymooc - https ://www.my-mooc.com/fr/mooc/.

[7] Docker - https ://www.docker.com.

[8] Docker compose - https ://docs.docker.com/compose/.

[9] Docker machine - https ://docs.docker.com/machine/.

[10] Docker swarm - https ://docs.docker.com/engine/swarm/.

[11] Keepalived - https ://www.keepalived.org.

[12] Protocol vrrp - https ://tools.ietf.org/html/rfc3768.

[13] Protocol arp - https ://tools.ietf.org/html/rfc5494.

[14] Dockerhub - https ://hub.docker.com.

[15] Dns definition - https ://fr.wikipedia.org/wiki/domain name system.

[16] Dns rfc - https ://tools.ietf.org/html/rfc8499.

[17] Kubernetes - https ://kubernetes.io.

[18] Traefik - https ://docs.traefik.io.

[19] Nginx - https ://www.nginx.com.

[20] Proxysql - https ://www.proxysql.com.

[21] Replication manager - https ://signal18.io/products/srm.

[22] Trello - https ://trello.com.

[23] Ganttproject - https ://www.ganttproject.biz.