{"id":87467,"date":"2020-07-08T13:42:11","date_gmt":"2020-07-08T11:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn"},"modified":"2020-07-08T13:42:11","modified_gmt":"2020-07-08T11:42:11","slug":"rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","title":{"rendered":"Guide pour les d\u00e9butants : cr\u00e9er un pipeline DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Si vous \u00eates novice en DevOps, consultez ce guide pour cr\u00e9er votre premier pipeline en cinq \u00e9tapes.<\/i><\/p>\n

\"Guide<\/p>\n

Le DevOps est devenu la solution standard pour rem\u00e9dier aux processus de d\u00e9veloppement logiciel lents, d\u00e9connect\u00e9s ou non fonctionnels. Le probl\u00e8me, c'est que si vous \u00eates nouveau dans DevOps et ne savez pas par o\u00f9 commencer, vous risquez de manquer de compr\u00e9hension de ces m\u00e9thodes. Cet article s'int\u00e9resse \u00e0 la d\u00e9finition d'un pipeline DevOps et propose un guide pour en cr\u00e9er un en cinq \u00e9tapes. Bien que ce tutoriel ne soit pas exhaustif, il devrait vous fournir une base pour commencer votre parcours et \u00e9largir vos connaissances \u00e0 l'avenir. Commen\u00e7ons par l'histoire.<\/p>\n

Mon voyage dans le DevOps<\/h3>\n

\nJ'ai auparavant travaill\u00e9 au sein de l'\u00e9quipe cloud de Citi Group, d\u00e9veloppant une application web Infrastructure-as-a-Service (IaaS) pour g\u00e9rer l'infrastructure cloud de Citi, mais j'ai toujours \u00e9t\u00e9 int\u00e9ress\u00e9 par la mani\u00e8re de rendre le processus de d\u00e9veloppement plus efficace et d'apporter des changements culturels positifs \u00e0 l'\u00e9quipe de d\u00e9veloppeurs. La r\u00e9ponse, je l'ai trouv\u00e9e dans un livre recommand\u00e9 par Greg Lavender, directeur technique de Citi pour l'architecture cloud et l'infrastructure. Le livre s'intitulait \u00ab The Phoenix Project \u00bbThe Phoenix Project<\/a><\/noindex>, et il explique les principes du DevOps tout en se lisant comme un roman.<\/p>\n

Le tableau au dos du livre montre \u00e0 quelle fr\u00e9quence diff\u00e9rentes entreprises d\u00e9ploient leurs syst\u00e8mes dans un environnement de production :<\/p>\n

Amazon : 23 000 par jour
\nGoogle : 5 500 par jour
\nNetflix : 500 par jour
\nFacebook : Une fois par jour
\nTwitter : 3 fois par semaine
\nEntreprise type : Une fois tous les 9 mois<\/p>\n

Comment est-il possible pour Amazon, Google et Netflix d'atteindre de telles fr\u00e9quences ? Tout simplement parce que ces entreprises ont d\u00e9couvert comment concevoir un pipeline DevOps presque parfait.
\n<\/a><\/noindex>
\nNous \u00e9tions loin de cela jusqu'\u00e0 ce que nous introduisions DevOps chez Citi. \u00c0 cette \u00e9poque, mon \u00e9quipe travaillait avec diff\u00e9rents environnements, mais le d\u00e9ploiement sur le serveur de d\u00e9veloppement \u00e9tait enti\u00e8rement manuel. Tous les d\u00e9veloppeurs n'avaient acc\u00e8s qu'\u00e0 un seul serveur de d\u00e9veloppement bas\u00e9 sur IBM WebSphere Application Server Community Edition. Le probl\u00e8me \u00e9tait que le serveur s'\u00e9teignait d\u00e8s que plusieurs utilisateurs essayaient de d\u00e9ployer simultan\u00e9ment, ce qui obligeait les d\u00e9veloppeurs \u00e0 se communiquer leurs intentions, ce qui \u00e9tait assez p\u00e9nible. De plus, il y avait des probl\u00e8mes de couverture de code \u00e0 bas niveau, des processus manuels de d\u00e9ploiement encombrants et l'absence de possibilit\u00e9 de suivre le d\u00e9ploiement du code li\u00e9 \u00e0 une t\u00e2che ou une histoire utilisateur sp\u00e9cifique.<\/p>\n

J'ai r\u00e9alis\u00e9 qu'il fallait faire quelque chose et j'ai trouv\u00e9 un coll\u00e8gue partageant les m\u00eames id\u00e9es. Nous avons d\u00e9cid\u00e9 de collaborer pour cr\u00e9er un premier pipeline DevOps \u2013 il a install\u00e9 une machine virtuelle et un serveur d'applications Tomcat pendant que je travaillais sur Jenkins, int\u00e9grant Atlassian Jira et BitBucket, et travaillant \u00e9galement sur la couverture de code. Ce projet secondaire a \u00e9t\u00e9 tr\u00e8s r\u00e9ussi : nous avons presque enti\u00e8rement automatis\u00e9 de nombreux processus, atteint presque 100 % de disponibilit\u00e9 de notre serveur de d\u00e9veloppement, assur\u00e9 le suivi et am\u00e9lior\u00e9 la couverture de code, et ajout\u00e9 la possibilit\u00e9 de lier des branches dans Git aux t\u00e2ches dans Jira ou aux d\u00e9ploiements. La plupart des outils que nous avons utilis\u00e9s pour construire notre pipeline DevOps \u00e9taient open source.<\/p>\n

Maintenant, je comprends \u00e0 quel point notre pipeline DevOps \u00e9tait simple : nous n'utilisions pas d'extensions comme Jenkins files ou Ansible. Cependant, ce pipeline simple fonctionnait bien, peut-\u00eatre gr\u00e2ce au principe de Pareto (\u00e9galement connu sous le nom de r\u00e8gle 80\/20).<\/p>\n

Introduction rapide \u00e0 DevOps et au pipeline CI\/CD<\/h3>\n

\nSi vous demandez \u00e0 plusieurs personnes : \u00ab Qu'est-ce que DevOps ? \u00bb, vous obtiendrez probablement plusieurs r\u00e9ponses diff\u00e9rentes. DevOps, tout comme Agile, a \u00e9volu\u00e9 pour englober de nombreuses disciplines diff\u00e9rentes, mais la plupart des gens s'accordent \u00e0 dire certaines choses : DevOps est une pratique de d\u00e9veloppement logiciel ou un cycle de vie de d\u00e9veloppement logiciel (SDLC), dont le principe central est le changement de culture, o\u00f9 d\u00e9veloppeurs et non-d\u00e9veloppeurs coexistent dans un environnement o\u00f9 :<\/p>\n

Les op\u00e9rations qui \u00e9taient auparavant effectu\u00e9es manuellement sont automatis\u00e9es ;
\nChacun fait ce qu'il sait faire le mieux ;
\nLe nombre de d\u00e9ploiements sur une p\u00e9riode donn\u00e9e augmente ; La capacit\u00e9 est accrue ;
\nLa flexibilit\u00e9 du d\u00e9veloppement est am\u00e9lior\u00e9e.<\/p>\n

Bien que poss\u00e9der les bons outils logiciels ne soit pas la seule condition pour cr\u00e9er un environnement DevOps, certains outils sont n\u00e9cessaires. L'outil cl\u00e9 est l'int\u00e9gration continue et le d\u00e9ploiement continu (CI\/CD). Dans ce pipeline, les environnements ont diff\u00e9rentes \u00e9tapes (par exemple, DEV, INT, TST, QA, UAT, STG, PROD), de nombreuses op\u00e9rations sont automatis\u00e9es, et les d\u00e9veloppeurs peuvent \u00e9crire du code de haute qualit\u00e9, atteindre la flexibilit\u00e9 du d\u00e9veloppement et une haute fr\u00e9quence de d\u00e9ploiements.<\/p>\n

Cet article d\u00e9crit une approche en cinq \u00e9tapes pour cr\u00e9er un pipeline DevOps, similaire \u00e0 celui illustr\u00e9 dans le diagramme suivant, en utilisant des outils open source.<\/p>\n

\u00c9tape 1 : M\u00e9thodes CI\/CD<\/h3>\n

\nLa premi\u00e8re chose dont vous avez besoin est un outil pour CI\/CD. Jenkins, un outil open source bas\u00e9 sur Java et distribu\u00e9 sous licence MIT, est le moyen qui a popularis\u00e9 la direction DevOps et est devenu le standard de facto.<\/p>\n

Alors, qu'est-ce que Jenkins ? Consid\u00e9rez-le comme une sorte de t\u00e9l\u00e9commande universelle magique qui peut communiquer avec divers services et outils et les organiser. En soi, un outil CI\/CD comme Jenkins est inutile, mais il devient plus puissant \u00e0 mesure qu'il se connecte \u00e0 diff\u00e9rents outils et services.<\/p>\n

Jenkins n'est qu'un des nombreux outils open source pour CI\/CD que vous pouvez utiliser pour construire un pipeline DevOps.<\/p>\n

Jenkins : Creative Commons et MIT
\nTravis CI : MIT
\nCruiseControl : BSD
\nBuildbot : GPL
\nApache Gump : Apache 2.0
\nCabie : GNU<\/p>\n

Voici \u00e0 quoi ressemblent les processus DevOps avec un outil CI\/CD :<\/p>\n

\"Guide<\/p>\n

Vous avez un outil CI\/CD fonctionnant sur votre localhost, mais pour le moment, vous ne pouvez pas faire grand-chose. Passons \u00e0 l'\u00e9tape suivante de notre voyage dans le monde DevOps.<\/p>\n

\u00c9tape 2 : Gestion des syst\u00e8mes de contr\u00f4le de version<\/h3>\n

\nLa meilleure (et peut-\u00eatre la plus simple) mani\u00e8re de v\u00e9rifier que votre outil CI\/CD peut faire des merveilles est de s'int\u00e9grer \u00e0 un outil de contr\u00f4le de version (SCM). Pourquoi avez-vous besoin d'un contr\u00f4le de version ? Supposons que vous d\u00e9veloppiez une application. Chaque fois que vous cr\u00e9ez une application, vous programmez, et peu importe si vous utilisez Java, Python, C++, Go, Ruby, JavaScript ou l'un des milliards de langages de programmation. Le code que vous \u00e9crivez est appel\u00e9 le code source. Au d\u00e9but, surtout lorsque vous travaillez seul, il est probablement possible de tout placer dans un r\u00e9pertoire local. Mais lorsque le projet devient plus cons\u00e9quent et que vous invitez d'autres personnes \u00e0 collaborer, vous avez besoin d'un moyen d'\u00e9viter les conflits lors d'un \u00e9change efficace des modifications. Vous avez \u00e9galement besoin d'un moyen de restaurer les versions ant\u00e9rieures, car cr\u00e9er des sauvegardes et le copier\/coller dans celles-ci est d\u00e9sormais obsol\u00e8te. Vous (et vos coll\u00e8gues) avez besoin de quelque chose de mieux.<\/p>\n

C'est ici que le syst\u00e8me de contr\u00f4le de version devient pratiquement indispensable. Cet outil sauvegarde votre code dans des d\u00e9p\u00f4ts, g\u00e8re les versions et coordonne le travail des participants au projet.<\/p>\n

Bien qu'il existe de nombreux syst\u00e8mes de contr\u00f4le de version, Git est la r\u00e9f\u00e9rence, et c'est vrai. Je vous recommande vivement d'utiliser Git, m\u00eame s'il existe d'autres options open-source.<\/p>\n

Git : GPLv2 et LGPL v2.1
\nSubversion : Apache 2.0
\nConcurrent Versions System (CVS) : GNU
\nVesta : LGPL
\nMercurial : GNU GPL v2+<\/p>\n

Voici \u00e0 quoi ressemble un pipeline DevOps avec l'ajout de syst\u00e8mes de contr\u00f4le de version.<\/p>\n

\"Guide<\/p>\n

Un outil CI\/CD peut automatiser les processus de v\u00e9rification, d'obtention du code source et de collaboration entre les membres. Pas mal, non ? Mais comment transformer cela en application fonctionnelle pour que des milliards de personnes puissent l'utiliser et l'appr\u00e9cier ?<\/p>\n

\u00c9tape 3 : Cr\u00e9ation de l'outil d'automatisation de construction<\/h3>\n

\nSuper ! Vous pouvez v\u00e9rifier le code et apporter des modifications au syst\u00e8me de contr\u00f4le de version, ainsi qu'inviter vos amis \u00e0 collaborer au d\u00e9veloppement. Mais vous n'avez pas encore cr\u00e9\u00e9 d'application. Pour cr\u00e9er une application web, il faut la compiler et la conditionner dans un format de paquet d\u00e9ployable ou la lancer sous forme de fichier ex\u00e9cutable. (Notez que les langages de programmation interpr\u00e9t\u00e9s, tels que JavaScript ou PHP, n'ont pas besoin d'\u00eatre compil\u00e9s).<\/p>\n

Utilisez un outil d'automatisation de la construction. Peu importe l'outil d'automatisation de la construction que vous choisissez d'utiliser, tous ont le m\u00eame objectif : compiler le code source dans un format souhait\u00e9 et automatiser la t\u00e2che de nettoyage, de compilation, de test et de d\u00e9ploiement dans un environnement sp\u00e9cifique. Les outils de construction varieront en fonction de votre langage de programmation, mais voici quelques options courantes open source.<\/p>\n

Nom
\nLicence
\nLangage de programmation<\/p>\n

Maven
\nApache 2.0
\n Java<\/p>\n

Ant
\nApache 2.0
\nJava<\/p>\n

Gradle
\nApache 2.0
\nJava<\/p>\n

Bazel
\nApache 2.0
\nJava<\/p>\n

Make
\nGNU
\nN\/A<\/p>\n

Grunt
\nMIT
\nJavaScript<\/p>\n

Gulp
\nMIT
\nJavaScript<\/p>\n

Buildr
\nApache
\nRuby<\/p>\n

Rake
\nMIT
\nRuby<\/p>\n

A-A-P
\nGNU
\nPython<\/p>\n

SCons
\nMIT
\nPython<\/p>\n

BitBake
\nGPLv2
\nPython<\/p>\n

Cake
\nMIT
\nC#<\/p>\n

ASDF
\nExpat (MIT)
\nLISP<\/p>\n

Cabal
\n(un syst\u00e8me de distribution de logiciels), les premi\u00e8res sources avaient d\u00e9j\u00e0 le num\u00e9ro de version 4.3. Pendant un certain temps, le serveur DNS \u00e9tait utilis\u00e9 par les membres des laboratoires de l'universit\u00e9. Jusqu'\u00e0 la version 4.8.3, le d\u00e9veloppement de BIND a \u00e9t\u00e9 dirig\u00e9 par des membres du Computer Systems Research Group (CSRG) de l'Universit\u00e9 de Berkeley, mais dans la seconde moiti\u00e9 des ann\u00e9es 1980, le serveur DNS a d\u00e9pass\u00e9 les murs de l'universit\u00e9 \u2014 il a \u00e9t\u00e9 remis \u00e0 Paul Vixie de la soci\u00e9t\u00e9
\nHaskell<\/p>\n

G\u00e9nial ! Vous pouvez placer les fichiers de configuration de l'outil d'automatisation de la construction dans le syst\u00e8me de gestion de version et permettre \u00e0 votre outil CI\/CD de tout rassembler.<\/p>\n

\"Guide<\/p>\n

Tout va bien, n'est-ce pas ? Mais o\u00f9 d\u00e9ployer votre application ?<\/p>\n

\u00c9tape 4 : Serveur pour applications web<\/h3>\n

\nPour l'instant, vous avez un fichier emball\u00e9 qui peut \u00eatre ex\u00e9cutable ou installable. Pour qu'une application soit r\u00e9ellement utile, elle doit fournir un service ou une interface, mais vous avez besoin d'un conteneur pour h\u00e9berger votre application.<\/p>\n

Le serveur pour applications web est justement ce conteneur. Le serveur fournit un environnement dans lequel la logique du paquet d\u00e9ployable peut \u00eatre d\u00e9finie. Il offre \u00e9galement une interface et propose des services web, en ouvrant des sockets vers le monde ext\u00e9rieur. Vous avez besoin d'un serveur HTTP ainsi que d'un environnement (par exemple, une machine virtuelle) pour l'installer. En attendant, supposons que vous apprendrez cela plus tard (bien que je parlerai des conteneurs ci-dessous).<\/p>\n

Il existe plusieurs serveurs d'applications web open source.<\/p>\n

Nom
\nLicence
\nLangage de programmation<\/p>\n

Tomcat
\nApache 2.0
\nJava<\/p>\n

Jetty
\nApache 2.0
\nJava<\/p>\n

WildFly
\nGNU Lesser Public
\nJava<\/p>\n

GlassFish
\nCDDL & GNU Less Public
\nJava<\/p>\n

Django
\n3-Clause BSD
\nPython<\/p>\n

Tornado
\nApache 2.0
\nPython<\/p>\n

Gunicorn
\nMIT
\nPython<\/p>\n

Python
\nMIT
\nPython<\/p>\n

Rails
\nMIT
\nRuby<\/p>\n

Node.js
\nMIT
\nJavascript<\/p>\n

Votre pipeline DevOps est presque pr\u00eat \u00e0 l'emploi. Bon travail !<\/p>\n

\"Guide<\/p>\n

Bien que vous puissiez vous arr\u00eater l\u00e0 et vous occuper de l'int\u00e9gration vous-m\u00eame, la qualit\u00e9 du code est importante pour les d\u00e9veloppeurs d'applications, et il est essentiel de s'en pr\u00e9occuper.<\/p>\n

\u00c9tape 5 : Couverture des tests de code<\/h3>\n

\nLa mise en \u0153uvre des tests peut \u00eatre une exigence fastidieuse, mais les d\u00e9veloppeurs doivent identifier les erreurs dans l'application d\u00e8s le d\u00e9but et am\u00e9liorer la qualit\u00e9 du code pour garantir la satisfaction des utilisateurs finaux. Heureusement, il existe de nombreux outils open source pour tester votre code et fournir des recommandations d'am\u00e9lioration de sa qualit\u00e9. Mieux encore, la plupart des outils CI\/CD peuvent se connecter \u00e0 ces outils et automatiser le processus.<\/p>\n

Les tests de code se composent de deux parties : des frameworks de test qui aident \u00e0 \u00e9crire et \u00e0 ex\u00e9cuter des tests, et des outils de suggestion qui aident \u00e0 am\u00e9liorer la qualit\u00e9 du code.<\/p>\n

Syst\u00e8mes de test de code<\/b><\/p>\n

Nom
\nLicence
\nLangage de programmation<\/p>\n

JUnit
\nLicence publique Eclipse
\nJava<\/p>\n

EasyMock
\nApache
\nJava<\/p>\n

Mockito
\nMIT
\nJava<\/p>\n

PowerMock
\nApache 2.0
\nJava<\/p>\n

Pytest
\n MIT
\nPython<\/p>\n

Hypothesis
\nMozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Syst\u00e8mes de recommandations pour l'am\u00e9lioration du code<\/b><\/p>\n

Nom
\nLicence
\nLangage de programmation<\/p>\n

Cobertura
\nGNU
\nJava<\/p>\n

CodeCover
\nEclipse Public (EPL)
\nJava<\/p>\n

Coverage.py
\n Apache 2.0
\nPython<\/p>\n

Emma
\nLicence publique commune
\nJava<\/p>\n

JaCoCo
\n Licence publique Eclipse
\nJava<\/p>\n

Hypothesis
\n Mozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Jasmine
\nMIT
\nJavaScript<\/p>\n

Karma
\nMIT
\nJavaScript<\/p>\n

Mocha
\n MIT
\nJavaScript<\/p>\n

Jest
\nMIT
\nJavaScript<\/p>\n

Notez que la plupart des outils et frameworks mentionn\u00e9s ci-dessus sont \u00e9crits pour Java, Python et JavaScript, car C++ et C# sont des langages propri\u00e9taires (bien que GCC soit open source).<\/p>\n

Maintenant que vous avez mis en \u0153uvre des outils de couverture des tests de code, votre pipeline DevOps devrait ressembler au diagramme montr\u00e9 au d\u00e9but de ce guide.<\/p>\n

\u00c9tapes suppl\u00e9mentaires<\/h3>\n

\nConteneurs<\/b><\/p>\n

Comme je l'ai d\u00e9j\u00e0 mentionn\u00e9, vous pouvez h\u00e9berger votre serveur sur une machine virtuelle ou un serveur, mais les conteneurs sont une solution populaire.<\/p>\n

Qu'est-ce que les conteneurs ? En r\u00e9sum\u00e9, une machine virtuelle n\u00e9cessite une grande quantit\u00e9 de m\u00e9moire du syst\u00e8me d'exploitation, d\u00e9passant la taille de l'application, tandis qu'un conteneur n'a besoin que de quelques biblioth\u00e8ques et configurations pour ex\u00e9cuter l'application. Il est \u00e9vident que les machines virtuelles ont toujours des cas d'utilisation importants, mais un conteneur est une solution l\u00e9g\u00e8re pour h\u00e9berger une application, y compris un serveur d'applications.<\/p>\n

Bien qu'il existe d'autres options de conteneurs, les plus populaires sont Docker et Kubernetes.<\/p>\n

Docker : Apache 2.0
\nKubernetes : Apache 2.0<\/p>\n

Moyens d'automatisation interm\u00e9diaire<\/b><\/p>\n

Notre pipeline DevOps est principalement ax\u00e9 sur la cr\u00e9ation et le d\u00e9ploiement collaboratifs d'applications, mais il existe de nombreuses autres choses \u00e0 r\u00e9aliser avec des outils DevOps. L'une d'elles est l'utilisation d'outils Infrastructure as Code (IaC), \u00e9galement connus sous le nom de moyens d'automatisation interm\u00e9diaire. Ces outils aident \u00e0 automatiser l'installation, la gestion et d'autres t\u00e2ches pour les logiciels interm\u00e9diaires. Par exemple, un outil d'automatisation peut extraire des applications telles qu'un serveur d'applications, une base de donn\u00e9es et un outil de surveillance, avec les bonnes configurations, et les d\u00e9ployer sur le serveur d'applications.<\/p>\n

Voici quelques outils d'automatisation interm\u00e9diaire open source :<\/p>\n

Ansible : GNU Public
\nSaltStack : Apache 2.0
\nChef : Apache 2.0
\nPuppet : Apache ou GPL<\/p>\n

\"Guide<\/p>\n

D\u00e9couvrez les d\u00e9tails pour acqu\u00e9rir une profession recherch\u00e9e depuis le d\u00e9but ou monter en niveau avec vos comp\u00e9tences et salaire en suivant des cours en ligne payants de SkillFactory :<\/p>\n