Upload
phungthien
View
214
Download
0
Embed Size (px)
Citation preview
Université LAVAL Faculté des sciences et de génie
Pavillon Adrien-Pouliot Québec,
Canada, G1V 0A6
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)