Introduction générale

Introduction générale
Dans le monde de l'informatique, tout évolue à vitesse grand V. Les
applications existantes doivent constamment être adaptées, à un rythme
toujours plus élevé. Et force est de constater que bien souvent des
complications apparaissent en outre souvent entre les développeurs et les
équipes opérationnelles. L’approche DevOps aide à pallier à ces
problèmes. Mais quelles différences entre les équipes de développement
et opérationnelles ? Qu'est-ce que le DevOps ? Quelles sont ses origines,
ses principes ? Et à quel point est-il utile pour votre entreprise ? Tels sont
les points qui feront l'objet de cet article.

Dans le cadre de la concurrence mondiale, et la grande compétitivité, les entreprises

sont appelées à améliorer la qualité de leurs produits et services, elles doivent adopter une
politique qui tient compte de l’évolution économique et technologique actuelle, afin de faire
face efficacement aux impératifs du marché et des réglementations et aussi aux besoins des
clients.
Matious Digital se place parmi les premières entreprises aux maroc qui vont emerger
vers la culture DEVOPS , cette position reste un point fort pour l’entreprise de développer
ses activités. Dans ce contexte, Matious Digital dédie d’utiliser les nouveaux technologie du
culture DEVOPS .

Notre projet sera dans le but de : « pouvoir

créer des image docker qui
nous permettre de faciliter et sécuriser les déploiements en
kuberneties » .
Vu la situation de confinement et le stage à distance nous n’avons pas pu aboutir à
réaliser la totalité du travail. Donc nous étions limités à exploiter toutes les fonctionnalités .

1
Introduction générale

Le rapport se devise en 5 chapitres :

 Chapitre 1 : Présentation  de l’entreprise Matious digital dans laquelle nous avons
effectué ce projet avec une description des problématiques, de l’objectif et de la
démarche de réalisation du projet.
 Chapitre 2 : la conteneurisation avec docker et la manipulation des micro services
avec docker compose .
 Chapitre 3 : L4integration continue en utilisant JENKINS .
 Chapitre 4 : le deploiment en kuberneties .
 Chapitre 5 : conclusion et ouverture vers autres technologies .

2
Introduction générale

Chapitre 1 :
Contexte de projet
Introduction générale

1.1 Introduction
Ce chapitre sera une présentation générale pour décrire le fonctionnement de
l'entreprise qui nous accueillait pour passer le stage de fin d’année ainsi le contexte général
de ce dernier.

Dans ce cadre, nous avons réalisé une recherche qui nous a apporté une foule d’informations
venant s’ajouter à la présentation globale suivante.

1.2 Présentation de l’organisme d’accueil

1.2.1 La société Matious
Matious est une agence digitale spécialisée dans
l‘accompagnement stratégique, la transformation digitale et
marketing pour des entreprises en Europe et en Amérique du Nord.
TABLEAU 1 : FICHE SIGNALÉTIQUE DE LA SOCIÉTÉ MATIOUS

Nom Matious
Date de création 2016
Fondateurs Mati MOUNI, Youssef BOUSSAFA
Directeur général Mati MOUNI
Siège social Mohammedia, Maroc
Domaine d’activité Marketing & Advertising
Statut légal S.a.r.l.
Effectif De 10 à 20 salariés

1.2.2 Activité de l’organisme d’accueil

Matious offre plusieurs services à ses clients parmi eux :

 Stratégie et conseil :
- Stratégies de Branding et de communication BTOC ou BTOB. 
- Stratégie et mise en place d’écosystèmes digitaux.
Introduction générale

- Accompagnement conseil permanent et optimisation des performances.

 Développement des solutions : site web, bloc & e-commerce, application mobile…
 Web Marketing: mettre en œuvre des stratégies élaborées pour booster la visibilité des
marques sur internet et développer un trafic qualifié à fort potentiel de transformation.
 Ad-tech consulting: élaborer des stratégies, mettre en place et gérer leurs activités de
publicité numérique.
 Audit, conseil et accompagnement en monétisation de site web : offrir aux éditeurs un
accompagnement complet pour optimiser leurs revenus.
- Examiner la structure de code source pour améliorer la performance du site.
- Evaluer la visibilité publicitaire afin d’assurer une totale liquidation de l’inventaire au
prix le plus élevé.
- Offrir une solution Anti-Fraude visant à protéger le site internet contre tout type de
trafic frauduleux.

1.3 Le concept devops

D'un point de vue strict il n'existe pas de définition standard et accepté de tous. Aussi
avons-nous une dizaine de définitions visant à expliquer le mouvement. Toutefois
Nous pouvons mentionner la définition de Wikipédia qui définit DevOps comme
étant "un mouvement visant à l'alignement de l'ensemble des équipes du système
d'information sur un objectif commun, à commencer par les équipes de dev ou dev
engineers chargés de faire évoluer le système d'information et les ops ou ops
engineers responsables des infrastructures (exploitants, administrateurs système,
réseau, bases de données,...)".
Bien qu'étant brève cette définition donne un très bon aperçu de la nature du
concept : une collaboration étroite entre les équipes de dev et celle des Ops.

Avant de rentrer plus en profondeur dans le monde du DevOps rappelons d'abord le

rôle de chaque participant :

Le rôle des Devs : Par Devs, on désigne toute personne impliquée dans la
conception, le développement et les tests d'un logiciel avant qu’il n’entre entre
production : les développeurs, les gestionnaires de produits, les testeurs, les
Product Owners et les QAs.
Introduction générale

Rôle opérationnel : Il s’agit de toute personne intervenant dans

l’exploitation et la maintenance de la production : les ingénieurs systèmes, les
DBAs, les ingénieurs réseaux, le personnel de sécurité, etc.
Les Développeurs (Dev) sont donc chargés de produire de l’innovation et délivrer
les nouvelles fonctionnalités aux utilisateurs dans les meilleurs délais. Les
Ingénieurs d’opérations (Ops) sont chargés de s’assurer que les utilisateurs ont
accès à un système stable, rapide et réactif.
Bien que le but ultime de Dev et Ops soit de rendre l’utilisateur satisfait des
systèmes qu’ils fournissent, leurs visions sur la façon d'y arriver restaient
diamétralement opposées. 

DevOps visent par ses pratiques à mettre fin à cette bataille entre Dev et Ops
– pour parvenir à l’équilibre entre l’innovation et la stabilité. Dev et Ops
doivent comprendre les bénéfices des paradigmes DevOps. Ils sont appelés à
changer juste assez pour commencer à travailler ensemble et à trouver le bon
équilibre entre Dev et Ops dont leur organisation a besoin, et de s’améliorer
à partir de là.

Comme mentionné plus haut Devops provient du rapprochement des trois premières

lettres du mot anglais development(développement) et
Introduction générale

de ops pour operations (exploitation), deux fonctions de la gestion des systèmes

informatiques qui ont souvent des objectifs contradictoires. Le mot fut inventé par
l'ingénieur de développement Patrick Debois qui l'utilisa pour la première fois
durant les premiers devopsdays à Gand en Belgique, en Octobre 2009.
En réalité le mouvement DevOps a commencé à naître un an plus tôt,
lorsque les équipes opérationnelles et de développement ont exprimé ce
qu'elles considéraient comme étant un souci de dysfonctionnement majeur
dans le secteur.
Elles ont relevé des inconvenients dans le modèle de développement traditionnel,
qui inclut une séparation organisationnelle et fonctionnelle entre les équipes de
programmation, de déploiement et de support.
Les développeurs et les experts de l'IT/des opérations avaient des objectifs précis
mais souvent opposés, leur propre leadership, des indicateurs clés de performance
différents au moyen desquels ils étaient évalués. Et pour compliquer encore les
choses, bien souvent, ils travaillaient à des étages voire dans des bâtiments séparés.
Résultat : les équipes étaient cloisonnées, elles ne se préoccupaient que de leur
propre rendement, faisaient des heures supplémentaires, bâclaient les livraisons, ce
qui conduit dans la plupart des cas à l'insatisfaction des clients.
Pour pallier à ce problème pour le moins pénalisant, les deux communautés se sont
donc réunies pour échanger et chercher des approches de solutions. Des journées
furent donc organisées avec à leurs têtes des experts du métier tels que Patrick
Dubois, Gene Kim ou encore John Willis.

Les principes de DevOps

 DevOps se résume en une activité continue regroupant 5 grandes

phases :
 Un développement constant
 Des tests constants
 Une intégration constante
Introduction générale

 Une mise en œuvre constante

 Une surveillance constante

Dans le cycle de vie de DevOps, on passe de la phase de projet à la phase de

surveillance, et à chaque fois un nouveau cycle redémarre dès que le précédent est
terminé. La partie en bleu sur le schema correspond à la phase de développement,
tandis que la portion en jaune orangé correspond à la partie opérationnelle, mais en
raison de leur interaction constante, les deux parties finissent par se confondre.
Pour la DevOps Agile Skills Association, (DASA) Six principes de base régissent
le développement d’une stratégie DevOps :
Travaillez selon une approche orientée sur le client, avec de courtes
périodes de retours donnés par de véritables clients et utilisateurs
finaux.
Évitez le modèle en cascade où chaque département travaille séparément,
sans avoir au préalable vue d’ensemble, et préférez une entreprise où
chacun partage un état d’esprit technique pour créer un produit qui
fonctionne comme il se doit.
Organisez vos équipes de façon verticale, de façon à ce qu’elles puissent
être responsables « from concept to grave».
Optez pour des profils polyvalents, qui travaillent en équipes autonomes, au
sein desquelles ils peuvent se développer sur le plan personnel.
Apportez constamment des améliorations sur le plan de la rapidité, des
coûts et du produit/service même.
Automatisez tout ce qui peut être automatisé, y compris l’infrastructure.

L’acronyme CALM désigne le referentiel (framework) conceptuel pour l'intégration

d'équipes, de fonctions et de systèmes DevOps au sein d'une organisation. 
Ce framework aide les responsables à évaluer ou à préparer leurs organisations à
implémentation de la DevOps. 
L'acronyme est attribué à Jez Humble co-fondateur de The Devops Handbook.
Introduction générale

Il se définit par :
Culture
Automation
Lean
Measurement
Sharing

–  Culture : il s'agit de développer la culture de la responsabilité partagée.

Ce terme est utilisé pour désigner la collaboration. Toutes les personnes
dans l'entreprise doivent être focalisées sur un objectif commun et
s'entraider pour l'atteinte de cet objectif.
– Automation : Tous les membres de l'équipe sont appelés à chercher des
moyens d'automatiser autant que possible les tâches et à s'orienter vers
une livraison continue.
Cela permet d'éliminer les tâches manuelles inutiles par la répétition.
– Lean : Une autre des sources d'inspiration de la culture DevOps. Elle
appelle à rationnaliser les opérations et à l'élimination les activités qui
n'apportent que peu de valeur à l'organisation, pour travailler plus
rapidement. En d'autres termes, être plus agile. 
– Measurement : Il s'agit de la mise en place d'outils et technologies
métriques afin de pouvoir mesurer les rendements d'un système ou d'un
produit . Car pour améliorer quelque chose il faut d'abord pouvoir la
mesurer .
– Sharing : Toutes les parties doivent être alignées sur les même objectifs
comme mentionné plus haut. Cela passe donc par la communication. Le
partage est donc essentiel pour améliorer la communication entre le
devs et les ops.

Liens entre DevOps et Agilité

 Devops s'appuie sur la méthodologie Scrum en intégrant

l'ensemble des principes agiles : Daily Scrum Meeting, Product
backlog, Sprints, Product Owner, Scrum Master,
Rétrospectives des Sprints.
Il met aussi en place les principes du lean management pour
permettre la simplification des tâches pour les développeurs et
les administrateurs.
En les simplifiant et les adaptant au mieux au contexte
entreprenarial , Devops met en place les processus de gestion
de services informatiques comme ITIL.
Introduction générale

Aslak Hellesøy, auteur du logiciel Cucumber dans son discours

d'ouverture à l'Agile Grenoble, le 17 novembre 2010, a
présenté devOps comme une des quatre nouvelles tendances
de l'agilité .

CONCLUSION
DevOps est une approche relativement nouvelle qui comporte un grand nombre
d'avantages et qui innove sans cesse. il est possible de la mettre en place dans
toutes les entreprises quelque soit le secteur d'activité. Néanmoins il faudra d'abord
passer par une phase préalable d'analyse et d'audit afin de voir si son
implémentation impactera significativement le rendement d'une entreprise.

1.4 Présentation de projet

Dans son sens le plus large, DevOps désigne une philosophie ou une approche culturelle qui
favorise une meilleure communication entre les deux équipes, à mesure qu'un nombre
croissant d'éléments de leur fonctionnement deviennent programmables.
C’est dans ce cadre que s’inscrit notre projet pour construire une chaîne d’intégration et de
́ploiement continue d’une manière automatise ́e, cette chaîne gère les changements depuis le
code source jusqu’a` la livraison

l’application salis-stable est une application développer par node JS en back end et Vue JS en
front end et mongo db en gestion de base de donnée .
On vas créer une image docker pour cette application puis on vas automatiser l’intégration
en liant mon compte GitHub avec la Repository docker a fin d’automatiser la création
d’image d’une manière continue .
A la fin on vas déployer l’image dans un cluster de Kuberneties .

1.3.1 Problématique de projet

Traditionnellement, un rythme de déploiement standard sur une application classique est
d’une à deux versions majeures par an. Pour chaque version majeure, on regroupe un
ensemble de nouvelles fonctionnalités, ce qui donne délai de 6 à 12 mois entre deux
nouveautés. Entretemps, on se contente de corriger les bugs, de sortir des versions mineures.
C’est terriblement long, surtout à l’ère d’internet. L’objectif est d’assurer la cohérence des
évolutions, regrouper les tests, sécuriser la production et limiter les migrations pour les
clients, mais cela pénalise les délais.
Introduction générale

Ce délai s’explique par le fait que c’est un processus séquentiel, impliquant différentes
équipes et qu’à chaque étape, il faut synchroniser les acteurs, faire des demandes, les
planifier, tout cela générant des délais.

Le déploiement continu prend le contrepied et permet d’permet d’accélérer ce rythme en :

 découpant les versions en un plus grand nombre de livraisons de moindre taille et

moins complexes à tester,
 automatisant au maximum les étapes de tests et passages en production d’une nouvelle
version afin de réduire les cycles,
 permettant un déploiement très régulier des nouveautés.

1.3.2 Objectif du projet

L’objectifs du projet est de pouvoir créer des image docker qui nous permettre de faciliter et
sécuriser les déploiements tout en rendant nos application scalable . pour cela, il faut bien
fonctionner en mode DevOps et respecter un certain nombre de bonnes pratiques. 
Ces images docker vont nous simplifier le déploiement de nos applications.
1.3.3 Tâche à réalisée
Notre Tache se divise en trois mission :

1. La conteneurisation de l’application avec docker .

2. L’automatisation avec Jenkins .
3. Le déploiement avec kuberneties .

1.3.1 Planification du projet

Had la partie a souha ma3erefetech kifach nedir liha o la blach / ?

Figure 1 : Diagramme de Gantt

Introduction générale

1.5 Conclusion
Afin de se situer dans le contexte du projet, nous avons introduit l’organisme d’accueil
pour définir le cadre général de ses activités, après nous avons décortiqué les finalités du
projet en présentant l’objectif final, et les outils qui nous a permis d’aboutir à cet objectif.

Le chapitre suivant discutera sur la définition de la technologie BIM, ses types, ses
avantages sur l’entreprise ainsi la focalisation sur le BIM GEM et son rôle dans l’exploitation
et la maintenance.
Introduction générale

Chapitre 2 :
Conteneurisation avec docker
Introduction générale

2.1 Introduction
Ce chapitre introduit le concept de conteneurisation on passe par une définition
générale de cette technologie, ses différents outils. Et on se termine par la creation de l’image
de l’application .

2.2 La conteneurisation
2.2.1 Définition de la conteneurisation

La conteneurisation, à ne pas confondre avec la virtualisation est une méthode

permettant d’exécuter une application dans un environnement virtuel dans une
seule zone appelée Conteneur. Seul l’environnement d’exécution est virtualise
dans un conteneur (systèmes de fichiers, réseau, processeur, mémoire vive, …).
L’application exécuter dans cet environnement virtuel stocke tous les fichiers,
bibliothèque et librairies dans le conteneur.
Ensuite notre conteneur se connecte au noyau (kernel) d’un système
d’exploitation. Il n’est donc pas nécessaire comme pour les machines virtuelle,
d’installer un nouveau système d’exploitation. Ici le noyau gèrent les
ressources de l’ordinateur et permet au différents composants matériels et
logiciels de communiquer entre eux. La conteneurisation rend donc le
déplacement d’application virtuelle plus simple entre des systèmes
d’exploitation identiques et demande moins de ressources de mémoire, de
RAM, de CPU, etc.
Introduction générale

2.2.2 Difference entre la conteneurisation et la virtualisation

Bien sur la conteneurisation à de nombreux avantages par rapport à la virtualisation mais on
ne peut pas affirmer que cette technologie est 100% parfaite, elle a aussi sont lots
d’inconvénients.
Ces deux schémas si dessus, d’un environnement de virtualisation à gauche et d’un
environnement de conteneurisation à droite permettent de bien identifier les
différences entre ces deux technologies. Tout d’abord, les conteneurs partagent un
seul et unique système d’exploitation, de ce fait, l’échange de données entre les
conteneurs est plus simple et plus rapides que pour les VM. De plus comme
chaque conteneur de contient pas de système d’exploitation propre à lui, les
conteneurs sont donc réduits et prennent moins de place et moins de ressource
Serveur (environ 10 fois plus petit qu’un VM). Le temps de création et de
suppression d’un conteneur est par la même occasion réduit.
Les conteneurs facilitent l’évolution technique, par exemple si dans un
environnement de VM, l’on souhaite faire évoluer les OS de plusieurs VM, il faut
le faire manuellement sur chaque Machines. Ce problème n’est pas présent pour la
conteneurisation car toute l’infrastructure repose sur un seul Système
d’exploitation.
Mais la conteneurisation peut avoir quelques inconvénients, comme tous les
conteneurs ne repose que sur un seul système d’exploitation, la diversification des
systèmes d’exploitation n’est pas possibles avec la conteneurisation, « où est plus
compliquée à mettre en place ». Les conteneurs sont isolées pour assurer la
sécurité et empêcher les malwares de ce transmettre entre les conteneurs, mais il
est évident que les machines virtuelles seront toujours plus isolées que les
conteneurs. Même si les conteneurs ont un grand nombre d’avantages, leur
apparition ne sonne pas la fin de la virtualisation. Aujourd’hui, les machines
virtuelles sont intégrées dans de nombreuses entreprises comportant des réseaux de
grande taille. Pour utiliser entièrement la technologie de conteneurisation, ces
entreprises devrait remanier tous leur système informatique ce qui est impensable.
Mais de nouvelles entreprises ont vu le potentiel de la conteneurisation et on donc
créer leur système informatique en fonction.
Introduction générale

2.2.3 les outils de conteneurisation

LXC « Linux Containers »

Le noyau de linux à la possibilité de créer des conteneurs. Les conteneurs Linux
ont une isolation des systèmes de fichier, des identifiant réseau et utilisateur. Et
également une isolation des ressources (processeur, mémoire, etc).
Ce système de virtualisation est vraiment la base de la conteneurisation .

Docker
Docker est la solution de conteneurisation la plus utilisée aujourd’hui. Il utilise
une Interface de programmation « Libcontainer » pour démarrer, gérer et arrêter
des conteneurs. Il est basée sur le fonctionnement de LXC et y ajoute des capitée
de niveau supérieur. La gestion des versions permet de comprendre certains
problèmes, il est possible de revenir à une version antérieure. De plus, les
conteneurs peuvent servir d’images à un autre, donc le partage de conteneurs en
public est possible. Ce service en ligne est appelée Docker Hub, il contient des
images de conteneurs, ce qui permet aux utilisateurs de faire des échanges. Cela
rend l’installation d’un conteneur extrêmement facile (aussi simple qu’un
téléchargement sur internet).
Docker permet donc de facilitée l’installation d’application dans des conteneurs
et la mise à jour, mais c’est le noyau linux qui s’occupe de la création de
conteneurs.
Docker est disponible sur linux comme sur Windows.
Introduction générale

Une standardisation de conteneurisation ?

L’initiative d’une standardisation « l’Open Container Project »

rassemble un grand nombre d’entreprise telle que Docker, CoreOS,
Google, Microsoft, VMware, Intel, IBM, Cisco, Red Hat et bien
d’autres. Avec la domination du marché de la conteneurisation par
Docker, ce modèle est rapidement devenu un standard, mais ces
entreprises souhaitent aujourd’hui établir un standard ouvert et
formel. Docker proposera son code source comme base mais cette
standardisation reviendra à la Linux Fondation. Le but est que cette
technologie ne soit pas attribuée à une seule entreprise mais que
n’importe qui puissent y accéder. Malgré que ce ne soient pas la
première tentative de standardisation, l’Open Container Project à
l’avantage d’obtenir l’appui précieux de Docker et d’un
impressionnant nombre d’acteurs

2.2.4 Docker
Introduction générale

Il s’agit d’une plateforme logicielle open source permettant de créer, de

déployer et de gérer des containers d’applications virtualisées sur
un système d’exploitation. Les services ou fonctions de l’application et
ses différentes bibliothèques, fichiers de configuration, dépendances et
autres composants sont regroupés au sein du container. Chaque
container exécuté partage les services du système  d’exploitation.

Docker permet de créer des environnements (appelées

containers) de manière à isoler des applications. Jusque là, je suis
resté très pragmatique…Docker repose sur le kernelLinux et sur
une fonctionnalité : les containers, que vous connaissez peut-être
déjà sous le doux nom de LXC. L'idée est de lancer du code (ou
d'exécuter une tâche, si vous préférez) dans un environnement
isolé. Je m'arrêterai ici pour ce qui est des détails des containers
Linux, pour plutôt me concentrer sur les fonctionnalités mises en
avant par Docker.Enfin, un troisième composant est
requis, cgroups qui va avoir pour objectif de gérer les ressources
(utilisation de la RAM, CPU entre autres).

Isoler de l’environnement

Oui… et non ! Docker et les containers Linux ne se comportent pas de

la même manière qu'une VM. Une machine virtuelle isole tout un
système (son OS), et dispose de ses propres ressources.
Dans le cas de  Docker, le kernel va partager les
ressources du système hôte et interagir avec
le(s) container(s). Techniquement, Docker n'est pas une
VM, pas le moins du monde, mais en terme
d'utilisation, Docker peut-être apparenté à une VM.
Lancer un environnement, et isoler les composants de ce
container avec les composants de mon hôte, voilà ce
que Docker sait faire ! Il le fait d'ailleurs très bien, et reste
une alternative bien plus performante que les VMs (à
utilisation équivalente).
Introduction générale

La plateforme Docker

La plateforme Docker présente de nombreux avantages.

Elle permet de composer, de créer, de déployer et
d’échelonner rapidement des containers sur les hôtes
Docker. Elle offre aussi un haut degré de portabilité, ce
qui permet aux utilisateurs de s’enregistrer et de partager
des containers sur une large variété d’hôtes au sein
d’environnements publics et privés.
Par rapport aux machines virtuelles, Docker présente
également plusieurs avantages. Elle permet
de développer des applications de façon plus
efficiente, en utilisant moins de ressources, et de
déployer ces applications plus rapidement.
Introduction générale

Cependant, elle présente aussi plusieurs inconvénients. Il

peut être difficile de gérer de façon efficiente un grand
nombre de containers simultanément. De plus, la
sécurité être un problème. Les containers sont isolés,
mais partagent le même système d’exploitation. De fait,
une attaque ou une faille de sécurité sur l’OS peut
compromettre tous les containers. Pour minimiser ce
risque, certaines entreprises exécutent leurs containers au
sein d’une machine virtuelle.
MAJ : Docker a rencontré une faille de sécurité qui a
touché près de 5 % des utilisateurs. Près de 190 000
d’entre eux ont vu les données de leurs containers
exposées après un accès non autoris à base de données
Hub. L’organisation a demandé aux entreprises et aux
personnes concernées de changer leur mot de passe.

Les alternatives
Docker n’est pas la seule plateforme de container sur le marché,
mais elle demeure la plus utilisée. Son principal concurrent est
CoreOS rkt. Cet outil profite du support de SELinux, ce qui le
sécurise. Parmi les autres plateformes majeures, on compte
Canonical LXD, ou encore Virtuozzo OpenVZ, la plus ancienne
plateforme de container.
On peut aussi évoquer l’écosystème d’outils qui
fonctionnent avec la plateforme pour des tâches telles
que le clustering ou la gestion de containers. On peut
citer comme exemple Kubernetes, l’outil de Container
Orchestration open source créé par Google.
Introduction générale

2.2.5 premiere mission

1.Introduction :

Conteneuriser une application fait référence au processus

d'adaptation d'une application et de ses composants afin de
pouvoir l'exécuter dans des environnements légers
appelés conteneurs. Ces environnements sont isolés et
remplaçables et peuvent être exploités pour développer, tester
et déployer des apps en production.

Dans ce guide, nous utiliserons Docker Compose pour

conteneuriser l’application pour le développement. L’application
fonctionnant sur trois conteneurs de service distincts :

 Un service app fonctionnant sous Sails js;

 Un service vue fonctionnant sous Vue js
 Un service db fonctionnant sous Mongo DB ;
 Un service nginx qui utilise le service Vue pour analyser le
code js avant de servir l'application à l'utilisateur final.

Nous verrons également comment utiliser les

commandes docker-compose exec pour
exécuter Composer et Artisan sur le conteneur de l’app

A. Conditions préalables :
 Accès à une machine locale Ubuntu 18.04 ou à un serveur de
développement en tant qu'utilisateur non root avec des privilèges sudo...
(ou installé docker CLI sur mac ou windows )
 Docker installé sur votre serveur,.
 Docker Compose installé sur votre serveur.

B. Obtenez l'application de démonstration

Introduction générale

Pour commencer, nous irons chercher l'application de démonstration dans notre répertoire
GitHub privée.

et on vas créer en premier lieu créer les image docker de chaque serveur séparément :
a.Back end :

 
Introduction générale

b.Frontend

La couche de base de données :

On vas utilisé l’image fournit en docker hub du Mongo :Latest .

L’orchestration avec docker compose :

o Docker Compose est un outil qui permet de décrire
(dans un fichier YAML) et gérer (en ligne de
commande) plusieurs conteneurs comme un
ensemble de services inter-connectés.
Introduction générale

Nous allons à la fin utiliser les commandes docker-compose pour

construire l'image de l'application et exécuter les services que nous avons
spécifiés dans notre configuration.
Introduction générale

2.3 Conclusion
Jghejdkkl ;slx..
Introduction générale

Chapitre 3 :
Automatisation avec Jenkins

3.1 Introduction
Notre projet de fin d’étude sera basé sur la gestion, la maintenance et l’exploitation
d’un bâtiment dans un processus BIM et sa relation avec TwinOps. C’est pour cela on va
expliquer dans ce chapitre les différentes notions de GEM et les outils exploitables.

3.2 Les fondamenteaux de l’integration continue

L'Intégration Continue, dans sa forme la plus simple, se compose d'un outil qui surveille les
modifications de code dans votre gestionnaire de configuration. Dès qu'un changement est détecté, cet
Introduction générale

outil va automatiquement compiler et tester votre application. Si la moindre erreur arrive alors l'outil
va immédiatement avertir les développeurs afin qu'ils puissent tout de suite corriger le problème.
Mais l'Intégration Continue est bien plus que cela. L'Intégration Continue peut aussi suivre la santé de
votre projet en surveillant la qualité du code et les métriques de couverture et ainsi aider à maintenir la
dette technique à un niveau bas et à abaisser les coûts de maintenance. Rendre visible publiquement
les métriques de qualité de code encourage les développeurs à être fiers de la qualité de leur code et à
essayer de toujours l'améliorer. Combinée à une suite de tests d'acceptance automatisés, l'IC peut aussi
se transformer en outil de communication en affichant une image claire de l'état des développements
en cours. Et elle peut simplifier et accélerer la livraison en vous aidant à automatiser le processus de
déploiement, vous permettant de déployer la dernière version de votre application soit
automatiquement soit d'un simple clic.
Dans le fond, l'Intégration Continue c'est réduire les risques en fournissant des retours rapides. En
premier lieu, de par sa conception, elle permet d'identifier et de corriger les problèmes d'intégration et
les regressions plus rapidement ce qui permet de livrer plus facilement et avec moins de bogues. En
donnant une meilleure visibilité sur l'état du projet à tous les membres de l'équipe, techniques comme
non-techniques, l'Intégration Continue facilite la communication au sein de l'équipe et encourage la
collaboration pour résoudre les problèmes ainsi que l'amélioration du processus. Et, en automatisant le
processus de déploiement, l'Intégration Continue vous permet de mettre votre logiciel dans les mains
des testeurs et des utilisateurs finaux plus rapidement, avec plus de fiabilité et avec moins d'efforts.
Ce concept de déploiement automatisé est important. En effet, si vous poussez ce concept de
déploiement automatisé à sa conclusion logique, vous pourriez mettre en production tout build qui
passerait sans encombre les tests automatisés nécessaires. Cette pratique de déployer en production
tous les builds ayant réussi est appelée communément Déploiement  Continu.
Cependant, une approche pure du Déploiement Continu n'est pas toujours souhaitable. Par exemple,
de nombreux utilisateurs n'apprécieraient pas d'avoir une nouvelle version disponible plusieurs fois
par semaine et préféreraient un cycle de livraison plus prévisible (et transparent). Des considérations
commerciales et marketing peuvent aussi entrer en compte pour déterminer quand une nouvelle
version doit être déployée.
La notion de Livraison Continue est très proche de cette idée de Déploiement Continu en prenant en
compte ces considérations. Lors d'une Livraison Continue tout build qui a réussi à passer les tests
automatisés pertinents et les contrôles qualité peut virtuellement être déployé en production au moyen
d'un processus lancé par un simple clic, et ainsi se retrouver dans les mains de l'utilisateur final en
quelques minutes. Cependant, ce processus n'est pas automatique : c'est au métier, plutôt qu'à
l'Informatique de décider quel est le moment opportun pour livrer les dernières modifications.
Ainsi les techniques d'Intégration Continue, et plus particulièrement le Déploiement Continu et la
Livraison Continue, permettent d'apporter la valeur à l'utilisateur final plus rapidement. Combien de
temps faut-il à votre équipe pour mettre une petite modification du code en production ? Dans ce
temps quelle est la part des problèmes qui auraient pu être corrigés plus tôt si vous aviez su quelles
modifications faisait Joe au bout du couloir ? Quelle part est prise par le pénible travail des équipes de
la qualité pour tester manuellement ? Combien d'étapes manuelles, dont les secrets ne sont connus que
de quelques initiés seulement, sont nécessaires à un déploiement ? L'Intégration Continue n'est pas la
solution miracle, elle permet de rationaliser certains de ces problèmes.
Mais l'Intégration Continue est tout autant une mentalité que des outils. Pour tirer un maximum de
profit de l'IC, une équipe doit adopter un comportement IC. Par exemple, vos projets doivent avoir un
build fiable, reproductible et automatisé, sans intervention humaine. La correction des builds en erreur
devrait être une priorité absolue, et ne devrait pas être oubliée dans un coin. Le processus de
déploiement devrait être automatisé, sans étape manuelle. Et puisque la confiance que vous mettez
Introduction générale

dans votre serveur d'intégration dépend en grande partie de la qualité de vos tests, l'équipe doit mettre
l'accent sur la qualité des tests et des pratiques associées.

3.3 Jenkins

3.3.1 Introduction

Jenkins, qui s'appelait à l'origine Hudson, est un outil d'Intégration Continue open source

écrit en Java. Bénéficiant d'une part de marché dominante, Jenkins est utilisé par des
équipes de toutes tailles, pour des projets dans des langages et des technologies variés,
incluant .NET, Ruby, Groovy, Grails, PHP et d'autres, ainsi que Java bien sûr. Qu'est ce
qui est à l'origine du succès de Jenkins ? Pourquoi utiliser Jenkins pour votre
infrastructure d'IC ?

Tout d'abord, Jenkins est facile à utiliser. L'interface utilisateur est simple, intuitive et
visuellement agréable, et Jenkins dans son ensemble a une très petite courbe
d'apprentissage. Comme nous le verrons dans le chapitre suivant, vous pouvez démarrer
avec jenkins en quelques minutes.

Cependant jenkins n'a pas sacrifié puissance ou extensibilité : il est aussi extrêmement
flexible et s'adapte facilement à vos moindres désirs. Des centaines d'extensions open
source sont disponibles, et de nouvelles aparaissent toutes les semaines. Ces extensions
couvrent tout : les outils de gestion de configuration, les outils de build, les métriques de
qualité de code, les annonceurs de build, l'intégration avec des systèmes externes, la
personalisation de l'interface utilisateur, des jeux et bien d'autres fonctionnalités encore.
Les installer est simple et rapide.

Enfin, mais ce n'est pas négligeable, une bonne part de la popularité de Jenkins vient de
la taille et du dynamisme de sa communauté. La communauté Jenkins est immense,
dynamique, réactive et c'est un groupe accueillant, avec ses champions passionnés, ses
listes de diffusion actives, ses canaux IRC et son blog et son compte twitter très bruyants.
Le rythme de développement est très intense, avec des livraisons hebdomadaires
comportant les dernières évolutions, corrections et mises à jour des extensions.

Cependant, Jenkins répond tout aussi bien aux attentes des utilisateurs qui ne souhaitent
pas mettre à jour toutes les semaines. Pour ceux qui veulent un rythme moins trépidant, il
existe une version Long-term Support, ou LTS. Il s'agit d'un ensemble de versions qui
sont à la traine par rapport à la toute dernière en termes de nouveautés mais qui apportent
plus de stabilité et moins de changements. Les versions LTS sortent environ tous les trois
mois, les correctifs importants y sont intégrés. Ce concept est identique
aux versions Ubuntu LTS .

3.3.2 historique
Introduction générale

De Hudson à Jenkins — Un rapide historique

Jenkins est le produit d'un développeur visionnaire, Kohsuke Kawaguchi, qui a commencé ce

projet comme un loisir sous le nom d'Hudson à la fin de l'année 2004 alors qu'il travaillait
chez Sun. Comme Hudson évoluait au cours des années, il était de plus en plus utilisé par les
équipes de Sun pour leurs propres projets. Début 2008, Sun reconnaissait la qualité et la
valeur de cet outil et demandait à Kohsuke de travailler à plein temps sur Hudson,
commençant ainsi à fournir des services professionnels et du support sur Hudson. En 2010,
Hudson était dévenu la principale solution d'Intégration Continue avec une part de marché
d'environ 70%.

En 2009, Oracle racheta Sun. Vers la fin 2010, des tensions apparurent entre la communauté
de développeurs d'Hudson et d'Oracle, dont la source était les problèmes de l'infrastructure
Java.net, aggravées par la politique d'Oracle au sujet de la marque Hudson. Ces tensions
révélaient de profonds désaccords sur la gestion du projet par Oracle. En effet, Oracle voulait
orienter le projet vers un processus de développement plus controlé, avec des livraisons moins
fréquentes, alors que le coeur des développeurs d'Hudson, mené par Kohsuke, preferait
continuer à fonctionner selon le modèle communautaire ouvert, flexible et rapide qui avait si
bien fonctionné pour Hudson par le passé.

En Janvier 2011, la communauté des développeurs Hudson vota pour renommer le projet en
Jenkins. Par la suite ils migrèrent le code originel d'Hudson vers un nouveau projet Github et
y poursuivirent leur travail. La grande majorité des développeurs du coeur et des plugins leva
le camp et suivit Kohsuke Kawaguchi et les autres principaux contributeurs dans le camp de
Jenkins, où le gros de l'activité de développement peut être observée aujourd'hui.

Après ce fork, la majorité des utilisateurs suivit la communauté des développeurs Jenkins et
passa à Jenkins. Au moment où ces lignes sont écrites, les sondages montrent qu'environ 75%
des utilisateurs d'Hudson sont passés à Jenkins, 13 % utilisent encore Hudson et 12% utilisent
Jenkins et Hudson ou sont en cours de migration vers Jenkins.

Cependant, Oracle et Sonatype (la compagnie derière Maven et Nexus) ont poursuivi leur
travail à partir du code d'Hudson (qui est maintenant lui aussi hébergé chez GitHub
à https://github.com/hudson), mais selon un axe différent. En effet, les développeurs de
Sonatype se sont concentrés sur des modifications dans l'architecture, notamment sur
l'intégration avec Maven, sur le framework d'injection de dépendances, et sur l'architecture
des plugins.

1.6. Mettre en place l'Intégration Continue au sein de votre

organisation
.

.
Introduction générale