{"id":33504,"date":"2019-10-31T21:52:58","date_gmt":"2019-10-31T18:52:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom\/"},"modified":"2019-10-31T21:52:58","modified_gmt":"2019-10-31T18:52:58","slug":"rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom","title":{"rendered":"Guide du d\u00e9butant : cr\u00e9ation de cha\u00eenes DevOps avec des outils open source","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Guide
\nCr\u00e9er la premi\u00e8re cha\u00eene DevOps en cinq \u00e9tapes pour les d\u00e9butants.<\/em><\/p>\n

<\/p>\n

DevOps est devenu une panac\u00e9e pour des processus de d\u00e9veloppement trop lents, disjoints et autres probl\u00e8mes. Mais des connaissances minimales en DevOps sont n\u00e9cessaires. Nous allons aborder des notions telles que la cha\u00eene DevOps et comment la cr\u00e9er en cinq \u00e9tapes. Ce n'est pas un guide complet, mais simplement une \u00ab base \u00bb qui peut \u00eatre \u00e9tendue. Commen\u00e7ons par l'histoire.<\/p>\n

<\/p>\n

Ma rencontre avec DevOps<\/h3>\n

<\/p>\n

Autrefois, je travaillais avec les clouds chez Citi Group et je d\u00e9veloppais une application web IaaS pour g\u00e9rer l'infrastructure cloud de Citi, mais j'\u00e9tais toujours curieux de savoir comment optimiser la cha\u00eene de d\u00e9veloppement et am\u00e9liorer la culture parmi les d\u00e9veloppeurs. Greg Lavender, notre directeur technique pour l'architecture cloud et l'infrastructure, m'a recommand\u00e9 un livre Projet \u00abPh\u00e9nix\u00bb<\/a><\/noindex>. Il explique tr\u00e8s bien les principes de DevOps, tout en se lisant comme un roman.<\/p>\n

<\/a><\/noindex><\/p>\n

Le tableau au dos montre \u00e0 quelle fr\u00e9quence les entreprises sortent de nouvelles versions :<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Comment Amazon, Google et Netflix arrivent-ils \u00e0 d\u00e9ployer autant ? C'est simple : ils ont compris comment cr\u00e9er une cha\u00eene DevOps presque parfaite.<\/p>\n

<\/p>\n

Chez Citi, ce n'\u00e9tait pas du tout le cas, jusqu'\u00e0 ce que nous passions \u00e0 DevOps. \u00c0 l'\u00e9poque, mon \u00e9quipe avait diff\u00e9rents environnements, mais la livraison sur le serveur de d\u00e9veloppement se faisait manuellement. 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. Quand nous essayions de livrer en m\u00eame temps, le serveur \u00ab tombait \u00bb, et nous devions chaque fois \u00ab douloureusement \u00bb nous entendre. De plus, nous avions une couverture de code insuffisante avec des tests, un processus de livraison manuel laborieux et aucune possibilit\u00e9 de suivre la livraison de code en fonction d'une t\u00e2che ou d'une demande client.<\/p>\n

<\/p>\n

Il \u00e9tait clair qu'il fallait agir rapidement, et j'ai trouv\u00e9 un coll\u00e8gue partageant les m\u00eames id\u00e9es. Nous avons d\u00e9cid\u00e9 de cr\u00e9er ensemble la premi\u00e8re cha\u00eene DevOps : il a configur\u00e9 une machine virtuelle et un serveur d'applications Tomcat, tandis que je me suis occup\u00e9 de Jenkins, de l'int\u00e9gration avec Atlassian Jira et BitBucket, ainsi que de la couverture de code par des tests. Le projet a \u00e9t\u00e9 un succ\u00e8s : nous avons enti\u00e8rement automatis\u00e9 la cha\u00eene de d\u00e9veloppement, obtenu presque 100 % de disponibilit\u00e9 pour le serveur de d\u00e9veloppement, pu suivre et am\u00e9liorer la couverture de code par des tests, et la branche Git pouvait \u00eatre li\u00e9e \u00e0 la livraison et \u00e0 la t\u00e2che Jira. Et presque tous les outils que nous avons utilis\u00e9s pour b\u00e2tir la cha\u00eene DevOps \u00e9taient open source.<\/p>\n

<\/p>\n

En r\u00e9alit\u00e9, la cha\u00eene \u00e9tait simplifi\u00e9e, car nous n\u2019avons m\u00eame pas utilis\u00e9 de configurations avanc\u00e9es avec Jenkins ou Ansible. Mais nous avons r\u00e9ussi. Cela peut \u00eatre le r\u00e9sultat du principe Pareto<\/a><\/noindex> (ou r\u00e8gle 80\/20).<\/p>\n

<\/p>\n

Br\u00e8ve description de la cha\u00eene DevOps et CI\/CD<\/h3>\n

<\/p>\n

DevOps a diff\u00e9rentes d\u00e9finitions. Comme Agile, DevOps comprend diff\u00e9rentes disciplines. Mais la plupart s'accorderaient sur la d\u00e9finition suivante : DevOps est une m\u00e9thode, ou un cycle de vie, du d\u00e9veloppement logiciel dont le principe fondamental est de cr\u00e9er une culture o\u00f9 les d\u00e9veloppeurs et les autres employ\u00e9s sont 'sur la m\u00eame longueur d'onde', o\u00f9 le travail manuel est automatis\u00e9, chacun s'occupant de ce qu'il fait le mieux, ce qui augmente la fr\u00e9quence des livraisons, am\u00e9liore la productivit\u00e9 et accro\u00eet la flexibilit\u00e9.<\/p>\n

<\/p>\n

Et bien que les seuls outils ne soient pas suffisants pour cr\u00e9er un environnement DevOps, ils sont indispensables. Le plus important d'entre eux est l'int\u00e9gration continue et la livraison continue (CI\/CD). Dans la cha\u00eene, chaque environnement comporte diff\u00e9rentes \u00e9tapes (par exemple, DEV (d\u00e9veloppement), INT (int\u00e9gration), TST (test), QA (assurance qualit\u00e9), UAT (tests d'acceptation par les utilisateurs), STG (pr\u00e9paration), PROD (utilisation)), les t\u00e2ches manuelles sont automatis\u00e9es, les d\u00e9veloppeurs peuvent produire un code de qualit\u00e9, le livrer et peuvent facilement se r\u00e9organiser.<\/p>\n

<\/p>\n

Cet article d\u00e9crit comment cr\u00e9er une cha\u00eene DevOps en cinq \u00e9tapes, comme indiqu\u00e9 dans l'image ci-dessous, \u00e0 l'aide d'outils open source.<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Passons aux choses s\u00e9rieuses.<\/p>\n

<\/p>\n

\u00c9tape 1 : Plateforme CI\/CD<\/h3>\n

<\/p>\n

Tout d'abord, vous avez besoin d'un outil CI\/CD. Jenkins est un outil CI\/CD open source \u00e9crit en Java sous licence MIT, qui a lanc\u00e9 la popularisation du mouvement DevOps et qui est devenu de facto la norme pour CI\/CD.<\/p>\n

<\/p>\n

Qu'est-ce que Jenkins ? Imaginez que vous ayez une t\u00e9l\u00e9commande magique pour divers services et outils. L'outil CI\/CD, comme Jenkins, est inutile par lui-m\u00eame, mais avec diff\u00e9rents outils et services, il devient omnipotent.<\/p>\n

<\/p>\n

Outre Jenkins, il existe de nombreux autres outils open source, choisissez n'importe lequel. <\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Voici \u00e0 quoi ressemble le processus DevOps avec un outil CI\/CD<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Vous avez un outil CI\/CD sur localhost, mais vous n'avez pas encore grand-chose \u00e0 faire. Passons \u00e0 l'\u00e9tape suivante.<\/p>\n

<\/p>\n

\u00c9tape 2 : gestion des versions<\/h3>\n

<\/p>\n

La meilleure (et sans doute la plus simple) fa\u00e7on de v\u00e9rifier la magie de l'outil CI\/CD est de l'int\u00e9grer avec un outil de gestion de versions (source control management, SCM). Pourquoi la gestion de versions est-elle n\u00e9cessaire ? Supposons que vous d\u00e9veloppiez une application. Vous la programmez en Java, Python, C++, Go, Ruby, JavaScript ou dans n'importe quel autre langage myriad. Ce que vous \u00e9crivez s'appelle du code source. Au d\u00e9but, surtout si vous travaillez seul, vous pouvez tout conserver dans un r\u00e9pertoire local. Mais lorsque le projet devient plus important et que d'autres personnes se joignent, vous avez besoin d'un moyen de partager les modifications de code tout en \u00e9vitant les conflits lors des fusions. De plus, vous devez pouvoir r\u00e9cup\u00e9rer les versions ant\u00e9rieures sans avoir \u00e0 utiliser des sauvegardes ni \u00e0 recourir \u00e0 une m\u00e9thode de copier-coller pour les fichiers de code.<\/p>\n

<\/p>\n

C'est l\u00e0 qu'intervient le SCM. Le SCM stocke le code dans des d\u00e9p\u00f4ts, g\u00e8re ses versions et le coordonne entre les d\u00e9veloppeurs.<\/p>\n

<\/p>\n

Il existe de nombreux outils SCM, mais le standard de facto est sans conteste Git. Je vous conseille de l'utiliser, bien qu'il existe d'autres options.<\/p>\n

<\/p>\n

\"Guide<\/p>\n

<\/p>\n

Voici \u00e0 quoi ressemble le pipeline DevOps apr\u00e8s l'ajout de SCM.<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

L'outil CI\/CD peut automatiser le t\u00e9l\u00e9chargement et la mise en ligne du code source ainsi que la collaboration en \u00e9quipe. Pas mal ? Mais comment transformer cela en une application fonctionnelle, ch\u00e9rie par des milliards d'utilisateurs ?<\/p>\n

<\/p>\n

\u00c9tape 3 : outil d'automatisation de la construction<\/h3>\n

<\/p>\n

Tout se d\u00e9roule comme pr\u00e9vu. Vous pouvez t\u00e9l\u00e9charger le code et enregistrer les modifications dans le syst\u00e8me de gestion de versions, ainsi qu'inviter des amis \u00e0 travailler avec vous. Mais vous n'avez pas encore d'application. Pour que ce soit une application web, elle doit \u00eatre compil\u00e9e et empaquet\u00e9e pour la livraison ou ex\u00e9cut\u00e9e en tant que fichier ex\u00e9cutable. (Un langage de programmation interpr\u00e9t\u00e9, comme JavaScript ou PHP, n'a pas besoin d'\u00eatre compil\u00e9.)<\/p>\n

<\/p>\n

Utilisez un outil d'automatisation de la construction. Quel que soit l'outil que vous choisissiez, il compilera le code dans le format n\u00e9cessaire et automatisera le nettoyage, la compilation, les tests et la livraison. Les outils de construction varient selon le langage, mais les options open source suivantes sont g\u00e9n\u00e9ralement utilis\u00e9es.<\/p>\n

<\/p>\n

\"Guide<\/p>\n

<\/p>\n

Excellent ! Maintenant, ins\u00e9rons les fichiers de configuration de l'outil d'automatisation de la construction dans le syst\u00e8me de gestion de versions afin que l'outil CI\/CD puisse les rassembler.<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Tout semble en ordre. Mais o\u00f9 d\u00e9ployer tout cela maintenant ?<\/p>\n

<\/p>\n

\u00c9tape 4 : serveur d'applications web<\/h3>\n

<\/p>\n

Donc, vous avez un fichier empaquet\u00e9 qui peut \u00eatre ex\u00e9cut\u00e9 ou d\u00e9ploy\u00e9. Pour que l'application soit r\u00e9ellement utile, elle doit avoir un service ou une interface, mais vous devez la placer quelque part.<\/p>\n

<\/p>\n

Une application web peut \u00eatre d\u00e9ploy\u00e9e sur un serveur d'applications web. Le serveur d'applications fournit un environnement o\u00f9 la logique du logiciel du package peut \u00eatre ex\u00e9cut\u00e9e, o\u00f9 l'interface peut \u00eatre rendue et o\u00f9 des services web peuvent \u00eatre ouverts via un socket. Vous avez besoin d'un serveur HTTP et de plusieurs autres environnements (comme une machine virtuelle, par exemple) pour installer le serveur d'applications. Pour l'instant, imaginons que vous g\u00e9rez tout cela en cours de route (bien que je parle des conteneurs ci-dessous).<\/p>\n

<\/p>\n

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

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Nous avons d\u00e9j\u00e0 presque une cha\u00eene DevOps fonctionnelle. Bon travail !<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

En principe, vous pouvez vous arr\u00eater ici, vous pourrez vous d\u00e9brouiller tout seul \u00e0 partir de l\u00e0, mais il vaut la peine de parler encore de la qualit\u00e9 du code.<\/p>\n

<\/p>\n

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

<\/p>\n

Les tests n\u00e9cessitent beaucoup de temps et d'efforts, mais il est pr\u00e9f\u00e9rable de d\u00e9tecter les erreurs imm\u00e9diatement et d'am\u00e9liorer le code pour ravir les utilisateurs finaux. Pour cela, de nombreux outils open source existent, qui non seulement testeront le code, mais vous conseilleront \u00e9galement sur la mani\u00e8re de l'am\u00e9liorer. La plupart des outils CI\/CD peuvent se connecter \u00e0 ces outils et automatiser le processus.<\/p>\n

<\/p>\n

Les tests sont divis\u00e9s en deux parties : les frameworks de test pour \u00e9crire et ex\u00e9cuter des tests, et les outils fournissant des conseils pour am\u00e9liorer la qualit\u00e9 du code.<\/p>\n

<\/p>\n

Frameworks de test<\/h3>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Outils de conseils sur la qualit\u00e9<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

La plupart de ces outils et frameworks sont \u00e9crits pour Java, Python, et JavaScript, car C++ et C# sont propri\u00e9taires (bien que GCC ait un code source ouvert).<\/p>\n

<\/p>\n

Nous avons appliqu\u00e9 des outils de couverture de test, et maintenant le pipeline DevOps devrait ressembler \u00e0 celui de l'image au d\u00e9but du guide.<\/p>\n

<\/p>\n

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

<\/p>\n

Conteneurs<\/h3>\n

<\/p>\n

Comme je l'ai d\u00e9j\u00e0 dit, un serveur d'applications peut \u00eatre d\u00e9ploy\u00e9 sur une machine virtuelle ou un serveur, mais les conteneurs sont plus populaires.<\/p>\n

<\/p>\n

Qu'est-ce que les conteneurs<\/a><\/noindex>? \u0412\u043a\u0440\u0430\u0442\u0446\u0435, \u0432 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0448\u0438\u043d\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0447\u0430\u0449\u0435 \u0432\u0441\u0435\u0433\u043e \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0435 \u043c\u0435\u0441\u0442\u0430, \u0447\u0435\u043c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435, \u0430 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0443 \u043e\u0431\u044b\u0447\u043d\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a \u0438 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438. \u0412 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0441\u043b\u0443\u0447\u0430\u044f\u0445 \u0431\u0435\u0437 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u043d\u0435 \u043e\u0431\u043e\u0439\u0442\u0438\u0441\u044c, \u043d\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440 \u0432\u043c\u0435\u0449\u0430\u0435\u0442 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0432\u043c\u0435\u0441\u0442\u0435 \u0441 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u043c \u0431\u0435\u0437 \u043b\u0438\u0448\u043d\u0438\u0445 \u0437\u0430\u0442\u0440\u0430\u0442.<\/p>\n

<\/p>\n

Pour les conteneurs, Docker et Kubernetes sont g\u00e9n\u00e9ralement utilis\u00e9s, bien qu'il existe d'autres options.<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Lisez des articles sur Docker et Kubernetes sur Opensource.com<\/a><\/noindex>:<\/p>\n

<\/p>\n