rapport de stage de masters m2...
Post on 17-Aug-2021
7 Views
Preview:
TRANSCRIPT
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.
top related