Université LAVAL Faculté des sciences et de génie

Pavillon Adrien-Pouliot Québec,

Canada, G1V 0A6

aide@fsg.ulaval.ca

418 656-2131

Directeur : Pierre-Yves Langlois

Maitre de stage : Sébastien Légaré

Tuteur à l’IUT : Karima Boudaoud

Enseignant-chercheur - Informatique

Gestion des serveurs immuables

Rapport de stage rédigé par Esteban Perez

Promotion 2014 / 2016

Département RÉSEAUX ET TÉLÉCOMMUNICATIONS

2

Remerciements ............................................................................................................3

Présentation de l’entreprise.........................................................................................4

Présentation de la Faculté des Sciences et de Génie ....................................................6

Présentation Equipe informatique de la FSG ................................................................7

Présentation de projet .................................................................................................9

Introduction générale ................................................................................................10

I. Etudes de technologies innovantes (Docker, Gitlab et Sentry) ................................11

1.1 Outils et Organisation du travail .......................................................................11

1.2 Recherches sur Docker ......................................................................................14

1.3 Analyses et recherches sur Gitlab et Sentry ......................................................20

II. Développement et expérimentation locale des technologies .................................25

2.1 Configuration de Gitlab et Sentry avec Docker ..................................................25

2.2 Problèmes rencontrés .......................................................................................34

III. Mise en production et documentation des technologies .......................................37

3.1 Mise en production et intégration ....................................................................37

3.2 Documentation .................................................................................................39

Conclusion Générale ..................................................................................................41

Webographie .............................................................................................................42

Liste des sigles ...........................................................................................................43

Table des illustrations ................................................................................................44

ANNEXE A : Différentes commandes GIT ....................................................................45

ANNEXE B : Docker-compose.yml Gitlab complet .......................................................46

ANNEXE C : Différentes options du Backup automatisé ..............................................47

ANNEXE D : Docker-compose.yml Sentry complet ......................................................48

ANNEXE E : Docker-compose.yml Gitlab pour environnement de production Linux (

Ubuntu server 16.04) .................................................................................................49

ANNEXE F : Docker-compose.yml Gitlab pour environnement de production Linux ....50

ANNEXE G : Docker-compose.yml Gitlab pour environnement de développement

Windows ( Boot2docker) ............................................................................................51

3

Remerciements

Tout d’abord je souhaite remercier toute l’équipe informatique de la Faculté des Sciences

et de Génie de l'Université Laval de m’avoir accueilli, mais plus particulièrement M. Pierre-

Yves LANGLOIS, qui a accepté de me prendre en stage, mais aussi M. Sébastien LEGARE

et M. Frédéric LEBEL (alias SUPER-FRED) qui m’ont pris en charge pour ce stage et qui

m’ont appris beaucoup de notion pendant dix semaines.

Ensuite, je remercie toutes les personnes du Cégep de Lévis-Lauzon dont Mme Melissa

CLERMONT et M. Serge LEVESQUE pour m’avoir accueilli et tout fait pour faciliter mon

installation au Québec.

De plus, Mme Karima BOUDAOUD ma tutrice de stage à l’IUT Réseaux &

Télécommunications qui m’a suivi tout au long du séjour ainsi que M. Nicolas FORTINO

responsable des stages.

Sans oublier toute l’équipe enseignante qui, grâce à leur formation, nous a permis de faire

un stage. Mais aussi Mme Carine GUEUR et Mme Evelyne MOYAL pour l’aide qu’elles

nous ont apporté pour toutes les formalités administratives avant le départ et leur suivi une

fois arrivé au Québec.

4

Présentation de l’entreprise

L’université Laval, située à Québec et fondée en 1852 par François de Montmorency-Laval,

est l’une des plus grandes universités au Canada. Avec un campus qui s’étend sur 1,8km²

et qui possède 64% d’espace verts et boisés.

Quelques chiffres :

L’université avec 17 facultés, compte 500 programmes d’études et plus de 60 000 étudiants

inscrits à la formation régulière créditée ou à des activités de formation continue durant

l'année universitaire 2014-2015

L'effectif étudiant à la session d'automne 2015 :

Plus de 42 500 étudiants

72% à temps complet

24% aux 2e et 3e cycles

Quelque 5 600 étudiants étrangers ou résidents permanents représentant 13% de l'effectif

étudiant total ; aux cycles supérieurs, ces étudiants d'origine étrangère constituent 27% de

l'effectif

Près de 900 résidents en médecine et 360 stagiaires postdoctoraux.

Plus de 230 associations étudiantes.

Quelque 900 étudiants en mobilité hors Québec annuellement, faisant de l'Université Laval

un leader en mobilité étudiante.

9 370 employés à temps plein et partiel :

3 685 professeurs, chargés de cours et autres membres du personnel enseignant et de

recherche

2 910 membres du personnel administratif et de soutien

2 775 étudiants et stagiaires postdoctoraux.

L’Université Laval peut également compter sur près de 600 professeurs associés, 775

professeurs de clinique et plus de 4 380 chargés d’enseignement clinique.

En matière de recherche et création, UL est dans les 6 plus importantes du Canada.

5

Illustration n°2 : Organigramme Université Laval

6

Présentation de la Faculté des Sciences et de Génie

La Faculté des sciences et de génie offre un environnement multidisciplinaire, elle regroupe

les différentes disciplines des sciences pures, des sciences appliquées et du génie.

La FSG se distingue par une structure unique au pays qui réunit sous un même toit un grand nombre de disciplines des sciences et de l'ingénierie. Avec ses 5 500 étudiants, plus de 250

professeurs chercheurs répartis dans 12 départements et une École, son personnel

professionnel, technique et administratif comptant près de 200 personnes, elle est

indéniablement la plus imposante faculté de l'Université Laval.

La Faculté des sciences et de génie contribue à l’avancement des connaissances, forme des

professionnels compétents et vise la réussite des étudiants aux trois cycles d’études. Milieu

disciplinaire, elle encourage tous ses membres à se surpasser pour répondre aux besoins en

constante évolution.

Riche de la qualité de ses membres, la Faculté des sciences et de génie place les étudiants au cœur de ses préoccupations. Elle concrétise sa mission en basant ses actions sur les

valeurs fondamentales suivantes :

L’excellence

La collaboration

La compréhension mutuelle

L’audace et l’innovation

La responsabilité de rendre compte

La cohérence entre les gestes et les paroles

L’ouverture d’esprit

Innovante et reconnue pour sa capacité d’adaptation aux nouvelles réalités, la Faculté des

sciences et de génie conjugue avantageusement ses activités de formation et de recherche

au bénéfice de la société.

7

Présentation Equipe informatique de la FSG

L’équipe informatique dans laquelle j’ai fait mon stage est composé de 9 personnes à temps

plein, stagiaire et auxiliaires, elle se divise en 2 sous équipes :

- L’équipe TACTIC : Regroupement de 3 étudiants encadrés par l’équipe

informatique de la FSG et sont responsables pour les développements pédagogiques

axés sur les Technologies de l'information à la Faculté. Parallèlement à ce mandat,

ils se chargent de développer des solutions Web pour les différents membres de la

communauté FSG et pour des partenaires sur le campus.

- L’équipe informatique de la FSG est divisée en 2 parties :

o Equipe de développement web : Composé de 5 personnes, elle gère les sites

de la FSG, les sites de cours en ligne, intègre et met à jours toutes les

fonctionnalités pour les utilisateurs des sites.

o Equipe de développement infrastructure : Composé de Fréderic LEBEL, mon

encadrant, technicien informatique, il s’occupe de tous les serveurs et de

l’hébergement.

Illustration n°3 : Organisation équipe informatique

8

Illustration n°4 : Salle de travail

Le matériel que nous avons eu à disposition était deux écrans connecté à une même tour, ce

qui permet d’avoir plus de taches ouvertes sur un même ordinateur.

9

Présentation de projet

Pendant dix semaines de stage à l’université Laval, au sein de l’équipe de développement

de la FSG, mon rôle a été de faire des recherches sur de nouvelles technologies tel que

Docker et Gitlab, afin de préparer la migration de Gitorious vers Gitlab.

Ces technologies innovantes, nous devions, à l’aide de mon encadrant, Frédéric LEBEL et

d’un autre stagiaire de l’IUT R&T, Arthur REVIRON, les faire fonctionner et les maitriser

pour, par la suite pouvoir utiliser Gitlab avec Docker.

Dans un premier temps, j’ai été amené à me renseigner sur Docker, grâce à internet et aussi

grâce a différents tests, qui ont permis d’en apprendre plus sur cette technologie. Mais aussi

prendre en main Gitlab, le comparer avec l’ancien service Gitorious.

Par la suite, il a fallu mettre en application ces nouvelles connaissances, mettre en lien

Docker et Gitlab.

Enfin commencer la migration de Gitorious sur la nouvelle instance de Gitlab qui marche sous Docker. Cette étape a été faite avec succès et constitué notre fil conducteur.

Une fois terminé la configuration de Gitlab et la migration, une nouvelle tâche a été de faire

des recherches sur une nouvelle technologie, Sentry et pouvoir la Dockerizer. Cette

technologie servira pour les développeurs et repérer les erreurs.

Toutes mes recherches et applications ont fait l’œuvre d’une documentation pour aider les

prochains utilisateurs. Nous avons commencé à Dockerizer plusieurs services (Gitlab et

Sentry) mais le but est de Dockerizer plein de services dans le futures.

10

Introduction générale

Le nouveau système de conteneur ne cesse de se développer, Docker est un vrai avantage

pour les systèmes de développement, il permet de travailler sur la même image quel que

soit le système et il est beaucoup plus rapide du fait qu’il n’a pas de mémoire alloué, il

utilise celle de l’host.

C’est pour cela que l’équipe de la FSG, a voulu qu’on commence à faire des recherches et

qu’on commence à utiliser Docker, M. LEBEL sous Ubuntu et moi sous Windows. De plus,

en complément des recherches sur Docker, il a fallu faire des recherches sur Gitlab. Gitlab

avait pour but de remplacer Gitorious qui est un ancien système de dépôt de ficher

abandonner et non entretenu, ce qui était donc un problème de sécurité sur le long terme.

Ensuite nous devions faire des recherches et des tests de Sentry, qui est un service

permettant de gérer les erreurs intégrées a des langages de programmation.

Sentry ainsi que Gitlab devaient, tourner sous docker, c’est-à-dire avoir leur propose

configuration sous docker avec un docker-compose.

Les résultats attendu à la fin de ce stage est d’avoir Dockerizé Gitlab, migré Gitorious sur

Gitlab et intégré Gitlab a l’equipe. De plus, Dockerizer Sentry, l’intégrer à l’équipe.

Ces technologies sous docker marquent un nouveau tournant, celle des conteneurs et de plus

les technologies tel que Sentry et Gitlab seront très utilise pour les développeurs.

Ce rapport de stage représente les méthodes utilisé pour arriver au bout d’une tache,

composé de trois grande partie : L’analyse, le Développement et enfin Mise en production.

Comment toutes ces nouvelles technologies peuvent aider et bien s’intégrer dans une

méthode de travail déjà acquise ? C’est ce que nous verrons durant ce rapport.

11

I. Etudes de technologies innovantes (Docker, Gitlab et Sentry)

La première étape de mon stage a consisté en mon intégration dans l’équipe de

développement afin de découvrir les différents outils à leurs environnements, méthodes,

organisation et répartition du travail. Ensuite nous avons fait l’analyse du projet que nous

devions effectuer avec mon encadrant. De plus, je devais faire de nombreuses recherches

sur les technologies innovantes à implémenter au sein de l’équipe. A l’issue, j’avais pour

but d’être capable de connaitre les fonctions et savoir utiliser Docker, Gitlab et Sentry tout

cela dans un temps respectant le planning.

1.1 Outils et Organisation du travail

1.1.1 Les différents outils de travail

A mon arrivé, j’ai dû configurer mon ordinateur sous Windows, qui est le système

d’exploitation utilisé par la majorité de l’équipe et donc pouvoir s’adapter. Mon encadrant

m’a ensuite fait découvrir toutes les plateformes que l’équipe utilise pour pouvoir travailler

et optimiser leur façon de travailler. En effet les équipes de développement utilisent

différents outils. Slack est un outil pour communiquer, cela permet de créer des groupes de

discussion et donc de partager son travail en cours, demander de l’aide rapidement et aussi

être au courant en temps réel de ce qui se passe.

Illustration n°5 : Interface de Slack

12

Ensuite le site de documentation de la FSG permet aux équipes d’avoir un aperçu des projets

et d’obtenir de l’aide sur des sujets déjà traités et ainsi apporter leur propre documentation.

Dans notre cas toute la documentation que nous avons réalisée a été stockée dans un onglet

nommé « Projets/GSC – Gestion des serveurs immuables ». Elle contient tout ce que nous

avons fait.

Illustration n°6 : Site documentation FSG

1.1.2 Organisation du Travail

Le tableau Kanban sur le site de la FSG, il résume toute les tâches à effectuer avec leur

estimation (en journée) et leurs différents états (« A faire », « Analyse », « Prêt révision »,

« En révision », ...). Ce tableau permet la gestion du flux de travail et de limiter le nombre

de tache en cours pour s’assurer de les compléter. Grace à un système de « Drag and Drop »

pour modifier l’état de la tâche, il est facile d’utilisation. Dans notre cas les taches à faire,

ont été rédigées par mon encadrant et l’estimation de la durée de chaque tâche a été décidée

lors de la rétrospective.

13

Illustration n°7 : Illustration du tableau Kanban

La rétrospective est une réunion se faisant une fois toutes les deux semaines (appelé un

« SPRINT »), se divisant en trois parties. Premièrement un résumé de semaine passée avec

des chiffres montrant l’efficacité durant cette semaine. Ensuite sur un tableau divisé en

plusieurs catégories (« Arrêter », « Continuer », « Moins de », « Plus de », « Commencer »)

chaque personne pose des « Post-it » avec ce qu’il a pensé et ce qu’il retient de la semaine

passée. Et enfin, la programmation du SPRINT avec description de chaque tâche par les

personnes concernées et l’estimation du temps, votée à l’unanimité, pour chaque tâche.

Après avoir fait le tour des outils nécessaires tout au long du stage, notre encadrant nous a

expliqué et fais découvrir en quoi consistait notre Projet, la « Gestion des Serveurs

immuables ». Tout d’abord il a été question d’éclaircir la notion de « Serveurs immuables ».

Un serveur Immuable est un serveur qui peux être démolis et reconstruit à volonté. Une fois

déployé, il n’est jamais modifié, simplement remplacée par une nouvelle instance mise

à jour.

Ensuite avoir un aperçu des technologies. Il y a tout d’abord Docker, qui servira dans notre

cas d’empaqueteur pour les autres technologies et qui fera office de serveur immuable.

Ensuite Gitlab, qui est un service web d’hébergement et de gestion de développement qui

remplacera Gitorious, l’actuel service de l’équipe. Enfin Sentry, qui est un service web

permettant de repérer les erreurs en plusieurs langages de programmation, ce qui est une

grande aide pour les développeurs. Gitlab et Sentry devront être « dockerizée » ce que nous

verrons plus tard.

Par la suite mon encadrant m’a dit qu’il faudrait rédiger une documentation sur le site de la

FSG pour décrire toutes les recherches et tous les tests que nous avons effectué.

14

1.2 Recherches sur Docker

1.2.1 Docker

Pendant deux semaines, soit le temps d’un Sprint, nous avons effectué des recherches sur

Docker pour être capable de savoir qu’est-ce que Docker ? Est-il compatible avec la

majorité des systèmes d’exploitations ? Comment l’utiliser ?

Docker est une plate-forme ouverte, compatible avec Windows, Linux et Mac, pour les

développeurs et les administrateurs système pour construire, diriger, et exécuter des

applications, que ce soit sur les ordinateurs, data center VM, ou le cloud. Il permet de

conditionner une application avec toutes ses dépendances dans une unité normalisée appelée

conteneur. Un conteneur comprend tout ce dont il a besoin pour exécuter : code,

bibliothèques système, des outils et d’autres dépendances.

Docker vous permet de diviser une application formée d’un seul bloc dans un grand nombre

de "petites applications" avec une complexité réduite et de les mettre dans des récipients

séparés. De cette façon, de nombreuses équipes peuvent travailler sur leur propre

application, en utilisant la meilleure technologie pour leur tâche (vous n'êtes pas lié à la

même technologie que l'ensemble de l'application), ce qui est notre but final.

En outre, vous pouvez construire votre application dans un conteneur qui fonctionne sur

votre ordinateur ou sur une machine virtuelle, dans le nuage ou partout où vous voulez,

et être assuré que cela fonctionnera de la même manière sur chaque environnement.

En résumé docker est un conteneur avec une image (d’un système d’exploitation) qui

n’utilise pas les ressources de son propre système d’exploitation mais les ressources du

système d’exploitation de la machine hôte, ce qui signifie que cela nécessite beaucoup

moins d’espace disque et ce qui assure un temps d’exécution minime.

Illustration n°8 : Comparaison VM, Docker et Docker + VM

15

1.2.2 Installation de Docker

Dans notre cas nous avons utilisé Docker sous Windows, comme Docker utilise le système

de Linux nous avons dû passer pas une machine virtuelle. Pour commencer avec Docker

nous avons utilisé le « Docker Toolbox » qui permet d’installer les utilitaires nécessaires

pour l’utilisation sous Windows.

« Docker Toolbox » contient :

- Docker-compose qui permet de lier plusieurs conteneurs ensembles (lier plusieurs

applications).

- Kitematic, qui lors de l’ouverture créer une machine virtuel relié à la machine hôte et qui

permet une utilisation de docker et une gestion des conteneurs sans passer par des lignes de

commandes.

- Docker Quickstart qui est une invite de commande communiquant directement avec la

VM.

- Virtulabox qui permet la virtualisation.

Une fois installé, nous avons lancé Kitematic qui s’est occupé de créer une machine virtuelle

dédiée à docker, nommée default, en plus de Kitematic nous avons lancé Docker Quickstart

pour pouvoir exécuter des commandes Docker et pourvoir le prendre en main.

Pour avoir un aperçu des commandes possible avec docker il suffit de taper la « docker »

dans le terminal.

Illustration n°9 : différentes commandes avec Docker

16

1.2.3 Prise en main de Docker

Avant de commencer à utiliser Docker, il faut comprendre le système d’image et de

conteneur.

En effet dans Docker, il y a des images et des conteneurs. Les deux sont étroitement liés,

mais distincts. Une image est à la base d’un conteneur, elle définit toutes les conditions

requises pour exécuter un conteneur Docker. Créé avec la commande build et qui,

lorsqu’elle est lancée avec la command run, devient un conteneur. Pour configurer une

image un fichier Dockerfile est nécessaire, c’est un document texte contenant toutes les

commandes pour assembler une image.

Illustration n°10 : Exemple de Dockerfile

Dans notre cas nous avons utilisé une image déjà créée et stocker sur le docker hub, qui

regroupe toutes les images présentes sur un registre ouvert à tous appartenant à Docker.

Pour ce faire nous nous sommes servis de la commande « docker pull ‘nom de l’image’ ».

Les images « téléchargées » sont stockées localement et peuvent être répertoriées en

exécutant « docker images ».

Illustration n°11 : La commande « docker images »

17

Il faut savoir qu’une image est caractérisée par plusieurs points, son IMAGE ID qui est les

12 premiers caractères du véritable identifiant d’une image, sa taille (SIZE), le TAG qui

définit sa version il suffit de la préciser lors de la création ou lors de la récupération sur le

hub et son REPOSITORY qui est son nom.

Pour lancer une image sous docker, il faut taper la commande suivante « docker run ‘nom

de l’image’ », celle-ci exécutera l’image et créera un conteneur avec les configurations de

l’image. Les conteneurs actifs peuvent être listés avec la commande « docker ps ».

Après avoir vu ce qu’était une image, un conteneur et savoir les utiliser, nous avons étudié

la combinaison de plusieurs conteneurs, ayant pour but une complémentarité d’applications.

Docker-compose est un outil permettant de définir et de faire fonctionner une application

multi-conteneurs.

L’utilisation de docker-compose s’effectue en deux étapes :

1. Définition des services composant l'application dans un fichier docker-compose.yml.

2. Lancement de la commande docker-compose up, afin de lancer l'application.

Le projet que j’ai eu a été de faire fonctionner WordPress associé à une base de donnée avec

docker. Pour se faire il y avait deux solutions :

- Passer par la commande « docker run » en ajoutant un lien pour lier à la base de donnée.

Mais cette méthode ne permettait pas d’utiliser le docker-compose.

- Construire un docker-compose.yml liant directement les images.

Nous avons opté pour la seconde solution pour avoir une première expérience avec le

docker-compose et comparé au « docker run ». Pour utiliser les docker-compose nous avons

créé un fichier docker-compose.yml avec à l’intérieur :

Illustration n° 12 : Docker-compose.yml WordPress et base de donnée

18

Le Docker-compose.yml de WordPress est composé de :

- lignes 1 et 8 / 2 et 9 : Image a utilisé pour faire tourner WordPress et la base de donnée

- lignes 4 et 5 : Avec quelle image lier WordPress, ici db (base de donnée)

- lignes 6 et 7 : Quel port utilisé pour WordPress

- lignes 10 et 11 : Variable d’environnement

Avant de lancer l'application, il est nécessaire de connaitre l'adresse IP de la VM contenant

Docker, « docker-machine IP ‘NOM_MACHINE’ »

Après avoir complété le docker-compose.yml, revenir dans le dossier parent et effectuer un

"docker-compose up", qui va aller chercher les images requises, puis lancera l'application.

Illustration n°13 : Lancement docker-compose

Pour y accéder, aller dans un navigateur et taper dans la barre de recherche l'adresse IP de

la machine virtuel, associé à son numéro de port (ici 8080).

19

Illustration n°14 : WordPress fonctionnel

Après avoir lancé l'application et avoir rentré la bonne adresse, nous avons obtenu la page

web suivante, permettant de commencer l'installation de WordPress.

La prise en main globale avec Docker a fonctionné, il faut maintenant faire des recherches

sur les autres technologies.

20

1.3 Analyses et recherches sur Gitlab et Sentry

1.3.1 Analyse d’une alternative à Gitorious, Gitlab

Après avoir étudié Docker, nous devions rechercher une alternative à Gitorious qui était

utilisé par l’équipe.

Gitorious est un service web, open source de forge basé sur Git, où des copies de dépôts Git

peuvent être téléchargés. C’est un service d’hébergement Git référentiel, qui offre tout le

contrôle de révision distribué et de gestion de code source (SCM), fonctionnalité de Git,

ainsi que l’ajout de ses propres caractéristiques. Contrairement à Git, qui est strictement un

outil de ligne de commande, Gitorious fournit une interface graphique basée sur le Web et

de bureau. Il permet la collaboration avec d’autres personnes sur des projets.

Mais en 2015 Gitorious fut racheté et n’ayant plus de mise à jour et d’entretiens, l’équipe

de développement a décidé de trouver une alternative.

En faisant quelques recherches et avec les conseils de mon encadrant, Gitlab était la

meilleure alternative. En effet, Gitlab contrairement à Github est totalement open source, il

dispose d’une grande communauté qui peut aider pour les problèmes rencontrés liés a

Gitlab. Son interface est très intuitive et similaire à celui de Gitorious ce qui ne dépaysera

pas les développeurs.

Mais Gitlab n’est pas simplement l’égal de Gitorious, il le surpasse. Effectivement, Gitlab

possède de nombreuses fonctionnalités non présentes sur Gitorious, tel que les pull request

qui permette de récupérer un dépôt/projet mais qu’avec autorisation, ce qui inclus plus de

sécurité, de plus il y a un système de code review, possibilité d’intégration en continu et

c’est aussi un service sans cesse mis à jour.

Illustration n°15 : Interface de Gitlab

21

Gitorious et Gitlab s’organisent différemment, il a fallu prendre en compte cela pour faire

la migration que l’on verra plus tard.

Après avoir trouvé l’alternative à Gitorious, il a fallu apprendre l’utilisé et maitriser les

principales fonctionnalités.

Tout d’abord initialisé une clé SSH pour permettre la communication de notre machine avec

Gitlab. Pour générer la clé, nous avons utilisé PuttyGen et introduit la clé générée dans

Gitlab et sauvegardé la clé privée sur notre machine.

Illustration n°16 : Génération de clé SSH

La création de projet, permettant de stocker par le biais de commande Git des documents,

du code ou n’importe quel fichier. Les différentes commandes Git sont disponibles en

ANNEXE A.

22

1.3.2 Sentry, un gestionnaire d’erreur, une aide essentielle pour les développeurs

Sentry est un logiciel (codé en Python) permettant de collecter et de monitorer les erreurs

de vos applications, grâce à des librairies disponibles pour chaque langage de

programmation (Python, Js, PHP, Java…). Pourquoi l’équipe de développement a besoin

de cet outil ? La réponse est simple, lorsque les développeurs mettent en place un service

pour des utilisateurs, la plupart du temps les erreurs sont rapportées par l’utilisateur même,

avec Sentry ils pourront avoir un aperçu avant même que l’utilisateur ne rapporte l’erreur

et cela sera plus précis qu’une simple description simple de l’erreur, il y aura un rapport

complet.

De plus Sentry est totalement open source, il permet de fournir en temps réel des rapports

d'erreurs, de diagnostiquer et résoudre les problèmes rapidement. Sentry contient une API

complète (beaucoup de langages pris en compte), il possède une très bonne répartition des

erreurs avec des organisations, des teams et des projets. Enfin il est facile de constater les

erreurs avec des graphiques et des statistiques détaillés.

Nous avons exploré comment s’organisait Sentry et comment utiliser Sentry avec différents

langages de programmation.

Tout d’abord nous avons regardé comment s’ordonnait Sentry, ce qui est assez similaire a

Gitlab. Nous avons tout d’abord un système d’Organisation qui est une entité encapsulant

les teams et les projets, cela permet de séparer en plusieurs groupes de travail. Il y a la

possibilité de créer une ou plusieurs organisations en mettant « false »

au SENTRY_SINGLE_ORGANIZATION dans sentry.conf.py.default, on peut aussi

ajouter ou enlever des membres d’une Organisation.

Dans les organisations sont présentes des teams qui permet de diviser en plusieurs type de

groupes cette organisation, elles contiennent les projets (Équivalentes aux groupes de

Gitlab).

Et à l’intérieur des teams se situes des projets qui vont permettre de centraliser les erreurs

d'une application à l'intérieur d'une même interface.

Un projet est organisé de la manière suivante :

Dashboard : Avoir une vue d'ensemble de comment se porte le projet

Issues : Observer quelles sont les erreurs, ainsi qu'une barre de recherche pour trouver une

erreur spécifique

Releases : Suivre les différences selon les versions de l'application

Settings : Modifier tout ce qui touche au projet même : Configuration (Nom, Team,

Notifications...), Data et Intégration

En plus de cette disposition il y a aussi une graduation au niveau des utilisateurs

23

Owner : Accès à tous les contrôles dans les organisations

Manager : Accès à tous les contrôles dans les organisations sauf la suppression de celle-ci

Admin : Accès complet à tous les projets et membres mais pas dans les organisations

Member : N'agit que sur les résolutions de problèmes et attributions

Après avoir vu la disposition des utilisateurs et des organisations nous avons observé les

options essentielles de Sentry c’est-à-dire ce qui concerne les erreurs.

Pour commencer à utiliser Sentry avec les différents langages il est nécessaire de créer un

projet, le nommé et l'assigner à l’équipe voulue. Pour ce faire nous avons créé un projet

Test en python

Illustration n°17 : Création du projet

Ensuite nous avons généré des erreurs grâce a un script python relié directement à Sentry

grâce à la clé DSN qui est spécifique à chaque projet.

Illustration n°18 : Script Python

24

Ce script permet de générer un erreur en faisant une division par 0 et en l’envoyant a

Sentry.

Lorsque l'on clique sur une erreur, plusieurs catégories sont disponibles et donnent

différentes informations à propos de l'erreur (onglet Detail) :

Message : informe sur le type d'erreur

Tags : indique sur quelle plateforme est l'erreur

Exception : Localise l'erreur dans le fichier

Paquetage : ce qui est utilisé

Illustration n°19 : Interface d’erreur

Grace aux approches que nous avons réalisées par rapport à sentry, nous avons pu constater

que c’est un service très utile et que cela apporte une grande aide surtout lorsque nous ne

savons pas d’où vient l’erreur.

Cette première étape, en majorité basée sur les recherches, a été très importante pour se

mettre en situation et découvrir ce qui attendait la suite du stage. La découverte de

nouvelles technologies m’a permis d’étoffer mes connaissances et aussi mes capacités

d’adaptation, car il fallait faire des recherches, les assimiler et les appliquer. Une nouvelle

méthode de travail très intéressante.

Dans la suite du stage la recherche était constante, il y avait toujours un besoin de

recherches pour continuer dans le projet, notamment lors des problèmes.

25

II. Développement et expérimentation locale des technologies

La deuxième étape, sans doute celle qui a pris le plus de temps. Elle a duré plus de trois

semaines. Cela consistait, après avoir effectué de nombreuses recherches sur comment

utilisé toutes les technologies, d’exécuter celles-ci avec docker.

Pourquoi « dockerizer » une application ? Comme nous l’avons vu précédemment, docker

est beaucoup moins lourd et plus rapide, et son utilisation permet de multiples options.

Ainsi après avoir fait ces recherches nous devions exécuter Gitlab et Sentry avec docker,

en passant par l’élaboration d’un docker-compose spécifique, faire des sauvegardes de

sécurités, faire de nombreux tests et nous avons été confrontés a de nombreux problèmes.

2.1 Configuration de Gitlab et Sentry avec Docker

2.1.1 Gitlab sous docker

Encore dans ce cas-là des recherches s’imposaient, car nous connaissons les deux

technologies mais il faut savoir les lier.

Grace à des recherches, nous avons trouvé deux solutions pour se faire. Tout d’abord une

image officielle de Gitlab se trouvait se le docker hub mais une autre image a attiré notre

curiosité. La seconde image, « sameersbn/gitlab », est mieux noté et recommandé par un

grand nombre d’utilisateurs. Mon tuteur, ayant fait des recherches, ma lancé sur la piste de

la deuxième image, car elle était plus complète et utilisait l’image officielle avec des ajouts

qui pouvait nous intéresser.

Illustration n°20 : Les deux images disponibles

Pour voir tous les composant de cette version de Gitlab, nous avons été sur le github de

sameersbn.

26

Pour installer Gitlab il a fallu tout d'abord télécharger l'archive contenant les fichiers de

configuration de Gitlab en appuyant sur "Download ZIP" (1).

Pour choisir différentes versions, il y a le menu déroulant (2) et choisir le tag correspondant

à la version voulu.

Illustration n°21 : Github de Sameersbn – Gitlab

Après avoir téléchargé l’archive, nous avons eu besoin de la dézippé. Une fois tout cela fais,

dans le répertoire désarchivé se trouve un docker-compose.yml. Nous sommes allés dans le

terminal et avons exécuté le docker compose.

Illustration n°22 : Exécution de Gitlab sous docker

27

Lorsqu’il est lancé, il suffisait d’inscrire dans la barre de recherche de votre navigateur

l'adresse IP de la VM contenant docker ainsi que le port de l'application (10080 par défaut).

Une fois que Gitlab était fonctionnel avec docker, il fallait être capable de faire une

sauvegarde de sécurité, restaurer cette sauvegarde, pouvoir faire une mise à jour de Gitlab

et être capable de rétrograder d’une version à une version antérieure. Pourquoi faire cela ?

Cela permet une grande sécurité et de réagir face à des problèmes imprévus, comme une

version à jour instable.

Nous avons étudié plusieurs méthodes pour faire des backups de Gitlab.

La première solution que nous avons essayée a été la sauvegarde de chaque volume de

conteneurs ainsi que leurs volumes pour, si jamais, les restaurer à un état stable.

Pour se faire nous avons dû télécharger l’archive de « quadeare/docker_volumes_backup »

sur Github et ensuite dézipper l’archive dans le dossier du docker-compose.yml de Gitlab.

Une fois que cela a été fait, nous avons lancé Gitlab comme précédemment, et listé les

conteneurs car notre méthode utilise l’identification des conteneurs.

Illustration n°23 : Lancement de Gitlab et liste des conteneurs

Après avoir lancé Gitlab, la commande a utilisé été « ./backup-docker.sh ‘Container Id’ »,

donc nous lancerons cette commande pour chaque conteneur.

28

Illustration n° 24 : Création backups de chaque conteneur

Les trois backups se créer dans le répertoire du docker-compose.yml, avec comme nom le

container id et la date le tout au format « .tar.gz ».

Les backups étant créés, il fallait ensuite pouvoir les restaurer, pour exécuter cette étape il

a fallu stopper Gitlab, et ensuite reconstruire chaque conteneur avec les contenus du backup

pour ensuite les relancer.

Illustration n°25 : Restauration et lancement de Gitlab restauré

29

Lorsque Gitlab se relance, il possèdera tous les éléments restaurés.

La création de Backups et la restauration a réussi avec succès, il fallait par la suite pouvoir

mettre à jour l’instance de Gitlab.

Pour mettre à jour Gitlab, rien de compliqué il était juste nécessaire de remplacer dans le

docker-compose.yml a la ligne : « image : sameersbn/gitlab X.X.X », le X.X.X étant le

numéro de la version, par Y.Y.Y le numéro de la nouvelle version.

Lorsque l’on relance Gitlab avec « docker-compose up » la version se met à jour.

Par contre il a fallu aussi rétrograder d’une version a une version antérieure, pour réaliser

ceci, il fallait préalablement avoir des backups des conteneurs. Ensuite, il a suffi de

supprimer la VM, « default », dans VirtualBox, ré-exécuter Kitematic. Pour passer d’une

version a une autre il a fallu faire la même manipulation que la mise à jour mais dans le sens

inverse, c’est-à-dire changer le Y.Y.Y en X.X.X. Une fois fait, nous devions lancer Gitlab

et restaurer les backups pour que la version soit complète avec les dépôts et paramètres que

nous possédions avant.

La deuxième solution se divise en deux parties, une manuelle et une autre automatisé pour

la création de copies de sécurités.

Pour les backups automatisés, il était nécessaire de posséder un docker-compose.yml ainsi

qu’une instance de Gitlab fonctionnelle, d’avoir les volumes qui sont bien mentionnés (pour

l’emplacement des backups) et aussi un bon GITLAB_TIMZONE dans le docker-

compose.yml pour ne pas avoir de problèmes lors du paramétrage de la fréquence des

backups.

La procédure pour effectuer les copies de sécurités était d’ajouter des variables

d’environnement au docker-compose.yml, GITLAB_BACKUP_SCHEDULE permet la

création automatique d’un backup a une fréquence donnée. Il est possible de choisir

l’horaire du backup avec la variable GITLAB_BACKUP_TIME, dans notre cas nous avons

essayé avec l’heure paramétrée à 11h53.

Grace au docker-compose que nous avons configuré, (VOIR ANNEXE B), les backups

s’effectueront chaque jour à 11h53 et se situerons dans la VM a

l’emplacement : « /var/lib/boot2docker/gitlab/gitlab/backups », par défaut ils s’effaceront

automatiquement au bout de sept jours.

30

Illustration n°26 : Localisation du backup crée

Pour plus d’option sur les variables d’environnement concernant les backups automatiques

voir ANNEXE C.

Pour effectuer un backup manuel, il faut avoir une instance Gitlab fonctionnelle et un

docker-compose.yml aussi.

La procédure pour faire le backup, il fallait juste exécuter cette commande :

Illustration n°27 : Commande backup manuel

Cette commande spécifie la position ou doit s’enregistrer le backup, il indique que le backup

doit prendre en compte les liens entre les services.

Enfin la procédure pour effectuer la restauration de ces backups manuels ou automatisés il

suffit de taper la commande :

31

Illustration n°28 : Commande restauration

Cette commande est la commande équivalente à celle pour créer le backup mais précisant

la « restore » et le backup à utiliser pour restaurer.

Après toutes ces opérations, Gitlab est prêt à être intégrer et héberger sur le serveur pour

ensuite envisager la migration.

2.1.2 Sentry sous docker

Pour que Sentry marche sous docker, Arthur et moi avons effectué des recherches, pour que

celui-ci possède aussi sons docker-compose car il est nécessaire d’avoir un système de base

de donné pour conserver les projets, les équipes, les utilisateurs et les erreurs.

Grace au hub de docker et a Github, nous avons trouvé le docker-compose de sentry,

ANNEXE D.

Pour lancer le docker-compose il y a plusieurs étapes :

Générer une Sentry secret key avec la commande :

« docker run --rm sentry generate-secret-key »

Remplacer la secret-key du docker-compose.yml par celle généré

Lancer la commande :

« docker-compose up -d redis postgres sentry »

Initié le setup pour créer un utilisateur root avec la commande et en suivant les indications

du terminal :

« docker exec -it [SENTRY CONTAINER] sentry upgrade »

Lancer le docker-compose :

« docker-compose up –d »

Pour aller à l’intérieur de sentry utiliser la commande :

32

« docker exec -it --user=root [SENTRY CONTAINER] bash »

Sentry est accessible par l’interface Web à l’adresse de la VM et au port indiqué dans le

docker-compose.yml

Après avoir initialisé Sentry et qu’il soit fonctionnel, nous avons eu pour but de réaliser les

backups, pour que ce soit possibles, des nombreuses recherches.

Notre tuteur, nous a indiqué qu’il fallait faire un backup du conteneur Sentry ainsi que celui

de la base donnée car, Sentry gère les paramètres de création de projet et celui des

utilisateurs et la base donnée permet à la sauvegarde des erreurs et des statistiques.

Donc avant de commencer nous avons créé des projets et des erreurs sur le Sentry que nous

avons exécutés.

Ensuite, nous avons créé, grâce à la commande pour pénétrer à l’intérieur du conteneur de

Sentry, le backup.

Illustration n°29 : Création du backup Sentry

Suite à ça, nous avons effectué le backup de la base de donnée grâce à la commande

pg_dump.

Illustration n°30 : Création du backup de la base de donnée Sentry

33

Une fois que les backups ont été créés, nous avons supprimer les conteneurs et relancé grâce

au docker-compose up pour vérifier de la fonctionnalité des backups après restauration.

Tout d’abord nous avons restauré le container de la base de donnée grâce au backups

dump.sql précédemment crée.

Illustration n°31 : Restauration base de la base de donnée

Ensuite vien au tour du conteneur de sentry que l’on restaure grâce au backup présent dans

/var de la VM.

Illustration n°32 : Restauration du conteneur de Sentry

Cette étape ayant restauré toutes les données de Sentry a été un succès.

34

2.2 Problèmes rencontrés

2.2.1 Problèmes liés à Docker

Nous avons effectué des tests sur les registry qui permettent d’avoir nos propres hubs

localement. La semaine pendant laquelle nous nous sommes concentré sur les registry avec

Docker nous avons eu de nombreux problèmes. Les manipulations n’étaient pas

compliquées mais le fait que docker se lance sous machine virtuelle engendrait des

problèmes de localhost, car la VM possède sa propre IP qui n'est pas le local host de la vraie

machine.

La façon de résoudre cela a été de se placer directement sur la VM pour éviter ce problème

d'adresse mais le problème persistait.

Nous avons donc cherché des alternatives au programme utilisé pour faciliter l’utilisation

aux prochaines utilisateurs pour lesquels nous faisons la documentation mais le meilleur est

celui que nous utilisons. Nous avons essayé VAGRANT + DOCKER mais KITEMATIC + DOCKER (celui que

nous utilisons) est plus stable.

Nous avons effectué de nombreux test et comparé les fonctionnalités des différentes

alternatives dont VAGRANT + DOCKER, mais nous avons remarqué avec notre

responsable que KITEMATIC était vraiment plus intuitif et plus complet que les autres

possibilités.

De ce fait nous avons décidé, avec notre tuteur, d’abandonner l’idée des registry sous

Windows.

2.2.2 Problèmes liés à Gitlab sous Docker

Nous avons eu de nombreux problèmes liés à Gitlab. Un des problèmes était le backup qui

nécessitait une sauvegarde.

Lors de la sauvegarde, présente uniquement sur la VM, le backup se créait en .tar, mais

impossible de le restaurer.

J'ai donc décidé de reprendre depuis le début et de m'aider d'un script qui m'a permis de

faire une sauvegarde et une restauration sans problème et fonctionnel.

"backup-docker", voir précédemment.

Ensuite nous avons eu un autre problème lorsque nous stoppions un conteneur, la

persistance des données n’était pas présente.

Nous avons localisé le problème qui était présent dans le docker-compose.yml. En effet les

volumes n’étaient pas bien configurés. Pour ce faire nous avons dû changer la destination

des volumes pour nous adapter à notre VM :

35

AVANT :

/srv/docker/gitlab/redis:/var/lib/redis

/srv/docker/gitlab/gitlab:/home/git/data

/srv/docker/gitlab/postgresql:/var/lib/postgresql

APRES:

/var/lib/boot2docker/redis:/var/lib/redis

/var/lib/boot2docker/gitlab/gitlab:/home/git/data

/var/lib/boot2docker/gitlab/postgresql:/var/lib/postgresql

Ainsi la persistance des données est fonctionnelle.

Enfin, le dernier problème rencontré avec Gitlab a été lors de la sauvegarde des copies de

sécurités automatiques. Effectivement, lorsque l’on indiquait une heure, le backup

s’effectuait à une heure totalement différente.

La solution se trouvait elle aussi dans le docker-compose.yml, elle venait des variables

d’environnements, car il fallait bien précisait de quelle fuseau horaire nous étions d’où le

décalage d’heure dans la sauvegarde automatique.

Nous avons donc modifié le docker-compose.yml :

AVANT :

Environment:

- TZ=Asia/Kolkata

- GITLAB_TIMEZONE=Kolkata

APRES:

Environment:

- TZ=America/New_York

- GITLAB_TIMEZONE= America/New_York

Avec ces parametres, la sauvegarde avait fonctionné et les problèmes avaient été résolus.

36

Cette étape tout aussi riche en recherche, nous a permis de lier les différentes technologies

avec docker et de concrétiser la notion de conteneur. De nombreux tests a permis de les

rendre fonctionnelles.

De plus nous avons été confrontés a de nombreux problèmes que nous avons appris a gérer

et à résoudre. Un seul problème n’a pas pu être résolu mais en général nous avons été

efficaces et avons accomplis les tache en respectant le planning des sprints.

Enfin le fait de prendre en main ces nouvelles technologie en partant de rien nous a forger

sur celles-ci et vas faciliter la mise en production et l’intégration.

37

III. Mise en production et documentation des technologies

Cette dernière phase n’a été que la suite logique des expérimentations en local,

l’achèvement de notre projet. Elle est celle qui a duré le moins de temps car tout le travail

précédent a été utilisé. Grace aux recherches et nos mises en pratiques des technologies

que nous avons faites, nous avons donc pu passer à leur mise en production et leur

intégration au sein de l’équipe de développement.

Lorsque Gitlab a été installé, hébergé, il a fallu effectuer la migration de Gitorious vers

Gitlab, efficacement pour les que les développeurs ne soient pas dérangés.

De plus il a fallu insérer du LDAP pour qu’ils puissent se connecter.

Enfin après l’intégration, nous avons effectué toutes la documentation de tout ce que nous

avons fait durant ce stage, ce qui pourra aider les prochains utilisateurs.

3.1 Mise en production et intégration

3.1.1 Intégration de Gitlab et migration

Pour entamer la mise en production et intégration il a fallu modifier les docker-compose.yml

de Gitlab pour que chaque environnement de production puisse faire tourner la même

image.

Pour se faire nous avons créé trois docker-compose.yml :

Gitlab pour un environnement de production Linux (Ubuntu server 16.04), ANNEXE E

Gitlab pour un environnement de production Linux, ANNEXE F

Gitlab pour un environnement de développement Windows (Boot2docker), ANNEXE G

Ensuite nous avons ajouté des variables d’environnements permettant de paramétrer du

LDAP pour que chaque utilisateur puisse utiliser son identifiant de la FSG pour pouvoir se

connecter à Gitlab.

- LDAP_ENABLED=true

- LDAP_LABEL=LDAP

- LDAP_HOST=ldap.ulaval.ca - LDAP_PORT=***

- LDAP_UID=sAMAccountName

- LDAP_METHOD=plain

-

LDAP_BIND_DN=CN=UN_FSG_wwwauth,OU=fsg,OU=unites,OU=institutionnel,DC=

ulaval,DC=ca

- LDAP_PASS=********

38

- LDAP_TIMEOUT=10

- LDAP_ACTIVE_DIRECTORY=true

- LDAP_ALLOW_USERNAME_OR_EMAIL_LOGIN=false

- LDAP_BASE=OU=IDUL,OU=Comptes,DC=ulaval,DC=ca

- LDAP_BLOCK_AUTO_CREATED_USERS=true

Lorsque que Gitlab était prêt, notre tuteur l’a hébergé sur un serveur avec docker et nous a donné comme mission de migrer les dépôts de Gitorious sur Gitlab.

Tout d’abord nous étions partit sur un script en python permettant de générer les commandes

mais cette méthode « était beaucoup trop longue et ne permettait pas la migration de toutes

les branches de gitorious.

Alors avec notre tuteur nous avons trouvé la solution, cette commande :

« docker exec -it gitlab_gitlab_1 app:rake gitlab:import:repos »

Grace à ça, nous avons pu migrer tous les dépôts de gitorious sous gitlab et cela est

fonctionnelle.

Illustration n°33 et 34 : Gitlab fonctionnel, hébergé sous FSG et avec

tout le contenu de Gitorious.

39

Désormais, Gitlab a remplacé Gitorious et est utilisé par l’équipe.

3.1.2 Intégration de Sentry

Pour sentry, l’intégration s’est faite durant les dernière semaine du stage, cependant avant

de la mettre en intégration, nous avons dû présenter à toute l’équipe ce qu’était Sentry pour

qu’ils en apprennent à son propos et voir comment l’utiliser.

Illustration n°35 : Sentry fonctionnel et hébergé sous FSG

De plus, nous avons eu des taches pour que sentry soit opérationnel lors du déploiement,

nous devions créer une équipe, des projets ainsi que faire l’intégration de sentry sur

différents services, notamment Gitlab.

Pour intégrer Sentry à Gitlab et observer les erreurs de Gitlab, il a fallu configurer à

l’intérieur de Gitlab (interface Web), rentrer la clé DSN du projet Sentry pour lier les deux

services.

Enfin Sentry est fonctionnel et peut être utilisé par l’équipe de développement.

3.2 Documentation

Ce qui retrace tout notre stage, c’est la documentation. En effet, pour toutes les taches une

page ou plusieurs pages de documentation était nécessaire, pour que n’importe quel

informaticien de l’équipe ou nouveau venu puisse utiliser, comprendre et apprendre de nos

travaux par rapport à Docker, Gitlab ou même Sentry.

40

La documentation a été l’étape qui clôturait la tache avant la révision.

Non seulement utile pour les autres personnes mais aussi pour nous trois car tout le monde

ne travaille pas sur les mêmes tâches et donc cela sert de complément et de renforcement

de connaissance.

Illustration n°36 : Exemple de page de documentation

Grace à ce que nous avons vu lors des précédentes parties a été vraiment utile, il a permis

de contrôler et gérer Gitlab et Sentry avec un peu plus de facilité, les objectifs fixés ont été

accomplis.

Gitlab et Sentry ont été intégrés et la migration de Gitorious a Gitlab s’est déroulée avec

succès.

De plus, la documentation que nous avons créée sera très utile pour toute l’équipe et pourra

répondre à de nombreuses questions sur Gitlab, Docker et même Sentry.

41

Conclusion Générale

J'ai fini mon stage en ayant accompli les objectifs fixés : la mise en production de Gitlab et

Sentry, ainsi que la rédaction des documentations appropriées. Ce stage fut une très belle

expérience pour moi. J'ai pu découvrir un métier intéressant à travers une équipe qui m'a accueilli avec bienveillance. A travers ce stage, j'ai pu m'imprégner de la culture

Québécoise, et découvrir de nouvelles méthodes de travail. J'ai aussi pu améliorer mon

niveau d’anglais : en effet, les documentations sur lesquelles j'ai travaillé, notamment celle

de Docker étaient exclusivement en anglais.

Au niveau personnel, ce stage m’a permis de découvrir le monde du travail à l’autre bout

du monde, dans un domaine que j’ai vraiment apprécié.

En générale, le fait d’être à la base d’un projet et de pouvoir le terminé, apprendre des

nouvelles méthodes de travail et découvrir de nouvelles technologie n’est que bénéfique, ce fut une très bonne expérience. En plus du stage, j'ai pu découvrir un pays très intéressant

culturellement, et rencontrer des personnes formidables. Etant logé dans la résidence

internationale de l'université, en compagnie de Camille MARIAULT et Arthur REVIRON.

J'ai donc fait la connaissance de gens culturellement différents, ce qui m'a je pense été

bénéfique.

Il reste encore de nombreuses tâches qui permettrait d'améliorer le travail entrepris par M.

LEBEL, Arthur et moi-même. M. LEBEL a notamment pour objectif de faire passer leur

manager de contenu web, TYPO 3, sous Docker. De plus, l'équipe de développement est toujours à la recherche de nouveaux outils leur permettant de travailler plus efficacement.

Il est donc probable qu'ils aient besoin de stagiaire dans les prochaines années.

42

Webographie

Docker :

- http://blogs.vmware.com/performance/2014/10/docker-containers-performance-vmware-vsphere.html

- https://hub.docker.com/

- https://docs.docker.com/windows/

- http://www.tivix.com/blog/docker-future-or-just-another-buzzword/

- http://12factor.net/fr/concurrency

- https://www.wanadev.fr/23-tuto-docker-comprendre-docker-partie1/

-

http://www.supinfo.com/articles/single/104-qu-est-que-docker-pourquoi-est-il-different-machines-

virtuelles

- https://www.docker.com/products/docker-toolbox

Gitlab :

- https://github.com/sameersbn/docker-gitlab

- https://gitlab.com/

Sentry :

- https://github.com/getsentry/sentry/issues/2698

- https://getsentry.com/welcome/

Université :

- https://aide.fsg.ulaval.ca/documentation/pages/viewpage.action?pageId=12323554

- https://www2.ulaval.ca/fileadmin/ulaval_ca/Documents/Documents_officiels/organigramme-ul-2016-

02-12.pdf

- https://tactic-fsg.slack.com/messages

- http://www2.ulaval.ca/notre-universite/direction-et-gouvernance/facultes-departements-ecoles.html

43

Liste des sigles

FSG : Faculté des Sciences et de Génie

IUT : Institut Universitaire de Technologie

UL : Université Laval

TACTIC : Technologues de l’Apprentissage des Connaissances via les Technologies de l’Information et

des Communications

GSC : Gestion des Serveurs Immuables

VM : Virtual Machine

DB : DataBase

IP : Internet Protocol

SCM : Software Configuration Management

SSH : Secure SHell

TZ : TimeZone

LDAP : Lightweight Directory Access Protocol

44

Table des illustrations

Illustration n°1 : Photo de l’entreprise.................................................................................................1

Illustration n°2 : Organigramme Université Laval.................................................................................5

Illustration n°3 : Organisation équipe informatique .............................................................................7

Illustration n°4 : Salle de travail ...........................................................................................................8

Illustration n°5 : Interface de Slack .................................................................................................... 11

Illustration n°6 : Site documentation FSG .......................................................................................... 12

Illustration n°7 : Illustration du tableau Kanban ................................................................................ 13

Illustration n°8 : Comparaison VM, Docker et Docker + VM ............................................................... 14

Illustration n°9 : différentes commandes avec Docker ....................................................................... 15

Illustration n°10 : Exemple de Dockerfile ........................................................................................... 16

Illustration n°11 : La commande « docker images » ........................................................................... 16

Illustration n°13 : Lancement docker-compose ................................................................................. 18

Illustration n°14 : WordPress fonctionnel .......................................................................................... 19

Illustration n°15 : Interface de Gitlab ................................................................................................ 20

Illustration n°16 : Génération de clé SSH ........................................................................................... 21

Illustration n°17 : Création du projet ................................................................................................. 23

Illustration n°18 : Script Python ......................................................................................................... 23

Illustration n°19 : Interface d’erreur .................................................................................................. 24

Illustration n°20 : Les deux images disponibles .................................................................................. 25

Illustration n°21 : Github de Sameersbn – Gitlab ............................................................................... 26

Illustration n°22 : Exécution de Gitlab sous docker ............................................................................ 26

Illustration n°23 : Lancement de Gitlab et liste des conteneurs ......................................................... 27

Illustration n° 24 : Création backups de chaque conteneur ................................................................ 28

Illustration n°25 : Restauration et lancement de Gitlab restauré ....................................................... 28

Illustration n°26 : Localisation du backup crée .................................................................................. 30

Illustration n°27 : Commande backup manuel ................................................................................... 30

Illustration n°28 : Commande restauration ....................................................................................... 31

Illustration n°29 : Création du backup Sentry .................................................................................... 32

Illustration n°30 : Création du backup de la base de donnée Sentry .................................................. 32

Illustration n°31 : Restauration base de la base de donnée ............................................................... 33

Illustration n°32 : Restauration du conteneur de Sentry .................................................................... 33

Illustration n°33 et 34 : Gitlab fonctionnel, hébergé sous FSGet avec tout le contenu de Gitorious.... 38

Illustration n°35 : Sentry fonctionnel et herbergé sous FSG ............................................................... 39

Illustration n°36 : Exemple de page de documentation ..................................................................... 40

45

ANNEXE A : Différentes commandes GIT

46

ANNEXE B : Docker-compose.yml Gitlab complet

47

ANNEXE C : Différentes options du Backup automatisé

48

ANNEXE D : Docker-compose.yml Sentry complet

49

ANNEXE E : Docker-compose.yml Gitlab pour environnement de

production Linux ( Ubuntu server 16.04)

50

ANNEXE F : Docker-compose.yml Gitlab pour environnement de

production Linux

51

ANNEXE G : Docker-compose.yml Gitlab pour environnement de

développement Windows ( Boot2docker)