{"id":83787,"date":"2020-06-03T07:42:26","date_gmt":"2020-06-03T05:42:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2"},"modified":"2020-06-03T07:42:26","modified_gmt":"2020-06-03T05:42:26","slug":"devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","title":{"rendered":"DEVOXX UK. Kubernetes en production : d\u00e9ploiement Blue\/Green, mise \u00e0 l'\u00e9chelle automatique et automatisation du d\u00e9ploiement. Partie 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kubernetes est un excellent outil pour d\u00e9ployer des conteneurs Docker dans un environnement de production en cluster. Cependant, certaines t\u00e2ches ne peuvent pas \u00eatre r\u00e9solues par Kubernetes. Lors d'un d\u00e9ploiement fr\u00e9quent en environnement de production, nous avons besoin d'un d\u00e9ploiement Blue\/Green enti\u00e8rement automatis\u00e9 pour \u00e9viter les temps d'arr\u00eat, ce qui n\u00e9cessite \u00e9galement de traiter les requ\u00eates HTTP externes et d'effectuer le d\u00e9chargement SSL. Cela n\u00e9cessite une int\u00e9gration avec un r\u00e9partiteur de charge comme ha-proxy. Une autre t\u00e2che consiste \u00e0 effectuer un dimensionnement semi-automatique du cluster Kubernetes lorsqu'il fonctionne dans un environnement cloud, par exemple, r\u00e9duire partiellement la taille du cluster la nuit.<\/p>\n

Bien que Kubernetes ne poss\u00e8de pas ces fonctionnalit\u00e9s \u00ab pr\u00eates \u00e0 l'emploi \u00bb, il fournit une API que vous pouvez utiliser pour r\u00e9soudre de telles t\u00e2ches. Les outils pour le d\u00e9ploiement Blue\/Green automatis\u00e9 et le dimensionnement du cluster Kubernetes ont \u00e9t\u00e9 d\u00e9velopp\u00e9s dans le cadre du projet Cloud RTI, qui a \u00e9t\u00e9 cr\u00e9\u00e9 sur la base d'open-source.<\/p>\n

Cet article, qui d\u00e9chiffre une vid\u00e9o, explique comment configurer Kubernetes avec d'autres composants open-source pour cr\u00e9er un environnement pr\u00eat \u00e0 la production, qui, sans temps d'arr\u00eat en production, prend en compte le code des modifications git commit.<\/p>\n

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

DEVOXX UK. Kubernetes en production : d\u00e9ploiement Blue\/Green, autoscaling et automatisation des d\u00e9ploiements. Partie 1<\/a><\/noindex><\/p>\n

Donc, une fois que vous avez acc\u00e8s \u00e0 vos applications depuis le monde ext\u00e9rieur, vous pouvez passer \u00e0 la configuration compl\u00e8te de l'automatisation, c'est-\u00e0-dire l'amener \u00e0 un stade o\u00f9 vous pouvez effectuer un git commit et vous assurer que ce git commit se termine en production. Naturellement, lors de la mise en \u0153uvre de ces \u00e9tapes, lors du d\u00e9ploiement, nous ne voulons pas subir de temps d'arr\u00eat. Ainsi, toute automatisation dans Kubernetes commence par l'API. <\/p>\n

\"DEVOXX
\n
\nKubernetes n'est pas un outil que l'on peut utiliser de mani\u00e8re productive \u00ab pr\u00eat \u00e0 l'emploi \u00bb. Bien s\u00fbr, vous pouvez le faire, utiliser kubectl, etc., mais l'API est tout de m\u00eame la fonctionnalit\u00e9 la plus int\u00e9ressante et utile de cette plateforme. En utilisant l'API comme un ensemble de fonctions, vous pouvez acc\u00e9der pratiquement \u00e0 tout ce que vous souhaitez faire dans Kubernetes. kubectl lui-m\u00eame utilise \u00e9galement l'API REST. <\/p>\n

C'est un REST, donc vous pouvez utiliser n'importe quel langage et outil pour travailler avec cette API, mais les biblioth\u00e8ques utilisateur faciliteront consid\u00e9rablement votre vie. Mon \u00e9quipe a \u00e9crit 2 de ces biblioth\u00e8ques : une pour Java \/ OSGi et une pour Go. La deuxi\u00e8me est moins souvent utilis\u00e9e, mais de toute fa\u00e7on, ces outils utiles sont \u00e0 votre disposition. Ce sont en partie des projets open-source sous licence. Il existe de nombreuses biblioth\u00e8ques de ce type pour diff\u00e9rents langages, vous pouvez donc choisir celles qui vous conviennent le mieux. <\/p>\n

\"DEVOXX
\n
\nDonc, avant de commencer l'automatisation du d\u00e9ploiement, il est essentiel de s'assurer que ce processus ne souffrira d'aucun temps d'arr\u00eat. Par exemple, notre \u00e9quipe effectue des d\u00e9ploiements en production au milieu de la journ\u00e9e, lorsque les utilisateurs utilisent intens\u00e9ment les applications, il est donc tr\u00e8s important d'\u00e9viter les retards dans ce processus. Pour \u00e9viter les temps d'arr\u00eat, nous utilisons 2 m\u00e9thodes : le d\u00e9ploiement blue\/green ou la mise \u00e0 jour continue. Dans le dernier cas, si vous avez 5 r\u00e9pliques de l'application en marche, elles sont mises \u00e0 jour successivement. Cette m\u00e9thode fonctionne tr\u00e8s bien, mais elle n'est pas adapt\u00e9e si diff\u00e9rentes versions de l'application sont en cours d'ex\u00e9cution pendant le d\u00e9ploiement. Dans ce cas, vous pouvez mettre \u00e0 jour l'interface utilisateur pendant que le backend continue de fonctionner avec l'ancienne version, ce qui perturbera l'application. Ainsi, du point de vue de la programmation, travailler dans de telles conditions est assez difficile. <\/p>\n

C'est l'une des raisons pour lesquelles nous pr\u00e9f\u00e9rons utiliser le d\u00e9ploiement blue\/green pour automatiser le d\u00e9ploiement de nos applications. Avec cette m\u00e9thode, vous devez vous assurer qu'\u00e0 un moment donn\u00e9, une seule version de l'application est active. <\/p>\n

Le m\u00e9canisme de d\u00e9ploiement blue\/green fonctionne comme suit. Nous recevons le trafic pour nos applications via ha-proxy, qui le dirige vers les r\u00e9pliques de l'application de la m\u00eame version. <\/p>\n

Lors d'un nouveau d\u00e9ploiement, nous utilisons Deployer, auquel de nouveaux composants sont fournis, et il effectue le d\u00e9ploiement de la nouvelle version. Le d\u00e9ploiement d'une nouvelle version de l'application signifie qu'un nouvel ensemble de r\u00e9pliques est 'mis en place', apr\u00e8s quoi ces r\u00e9pliques de la nouvelle version sont lanc\u00e9es dans un pod s\u00e9par\u00e9 et nouveau. Cependant, ha-proxy n'en sait rien et ne dirige pour l'instant aucune charge de travail vers elles.<\/p>\n

Il est donc primordial d'effectuer d'abord un contr\u00f4le de la fonctionnalit\u00e9 des nouvelles versions par le biais d'un health checking, afin de s'assurer que les r\u00e9pliques sont pr\u00eates \u00e0 prendre en charge la charge.<\/p>\n

\"DEVOXX
\n
\nTous les composants de d\u00e9ploiement doivent prendre en charge une forme quelconque de health check. Cela peut \u00eatre une simple v\u00e9rification HTTP par appel, o\u00f9 vous obtenez un code avec un statut 200, ou un contr\u00f4le plus profond, o\u00f9 vous v\u00e9rifiez la connexion des r\u00e9pliques \u00e0 la base de donn\u00e9es et \u00e0 d'autres services, la robustesse des connexions dans l'environnement dynamique, et si tout est lanc\u00e9 et fonctionne correctement. Ce processus peut \u00eatre assez complexe. <\/p>\n

\"DEVOXX
\n
\nUne fois que le syst\u00e8me a v\u00e9rifi\u00e9 le bon fonctionnement de toutes les r\u00e9pliques mises \u00e0 jour, Deployer mettra \u00e0 jour la configuration et transmettra le bon confd, qui reconfigurera ha-proxy. <\/p>\n

\"DEVOXX
\n
\nCe n'est qu'apr\u00e8s cela que le trafic sera dirig\u00e9 vers le pod avec les r\u00e9pliques de la nouvelle version, et le pod ancien dispara\u00eetra. <\/p>\n

\"DEVOXX
\n
\nCe m\u00e9canisme n'est pas une sp\u00e9cificit\u00e9 de Kubernetes. Le concept de d\u00e9ploiement Blue\/Green existe depuis assez longtemps et a toujours utilis\u00e9 un \u00e9quilibreur de charge. Au d\u00e9part, vous dirigez tout le trafic vers l'ancienne version de l'application, puis, apr\u00e8s la mise \u00e0 jour, vous le transf\u00e9rez enti\u00e8rement vers la nouvelle version. Ce principe est utilis\u00e9 non seulement dans Kubernetes.<\/p>\n

Je vais maintenant vous pr\u00e9senter un nouveau composant de d\u00e9ploiement \u2013 Deployer, qui effectue des v\u00e9rifications de fonctionnalit\u00e9, reconfigure le proxy, etc. C'est un concept qui ne concerne pas le monde ext\u00e9rieur et existe \u00e0 l'int\u00e9rieur de Kubernetes. Je vais montrer comment cr\u00e9er votre propre concept Deployer en utilisant des outils open-source. <\/p>\n

Ainsi, la premi\u00e8re chose que fait Deployer est de cr\u00e9er un contr\u00f4leur de r\u00e9plication RC, en utilisant l'API Kubernetes. Cette API cr\u00e9e des pods et des services pour un d\u00e9ploiement ult\u00e9rieur, c'est-\u00e0-dire qu'elle cr\u00e9e un tout nouveau cluster pour nos applications. Une fois que le RC s'assure que les r\u00e9pliques ont d\u00e9marr\u00e9, il effectuera un contr\u00f4le de leur \u00e9tat de sant\u00e9. Pour cela, Deployer utilise la commande GET \/health. Cela lance les composants de v\u00e9rification appropri\u00e9s et v\u00e9rifie tous les \u00e9l\u00e9ments qui garantissent le bon fonctionnement du cluster. <\/p>\n

\"DEVOXX
\n
\nApr\u00e8s que tous les pods aient signal\u00e9 leur \u00ab sant\u00e9 \u00bb, Deployer cr\u00e9e un nouvel \u00e9l\u00e9ment de configuration : le stockage distribu\u00e9 etcd, qui est utilis\u00e9 \u00e0 l'int\u00e9rieur de Kubernetes, notamment pour stocker la configuration de l'\u00e9quilibreur de charge. Nous enregistrons les donn\u00e9es dans etcd, et un petit outil, confd, surveille etcd \u00e0 la recherche de nouvelles donn\u00e9es. <\/p>\n

S'il d\u00e9tecte des modifications de la configuration initiale, il g\u00e9n\u00e8re un nouveau fichier de param\u00e8tres et le transmet \u00e0 ha-proxy. Dans ce cas, ha-proxy se red\u00e9marre sans perdre aucune connexion et dirige la charge vers les nouveaux services qui assurent le fonctionnement de la nouvelle version de nos applications. <\/p>\n

\"DEVOXX
\n
\nComme vous pouvez le voir, malgr\u00e9 la multitude de composants, il n'y a rien de compliqu\u00e9 ici. Vous devez simplement porter plus d'attention \u00e0 l'API et \u00e0 etcd. Je tiens \u00e0 vous parler d'un d\u00e9ployeur open-source que nous utilisons nous-m\u00eames : Amdatu Kubernetes Deployer.<\/p>\n

\"DEVOXX
\n
\nC'est un outil d'orchestration de d\u00e9ploiements Kubernetes, dot\u00e9 des fonctionnalit\u00e9s suivantes : <\/p>\n