{"id":34735,"date":"2019-10-31T22:00:06","date_gmt":"2019-10-31T19:00:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/znakomstvo-s-helm-3\/"},"modified":"2019-10-31T22:00:06","modified_gmt":"2019-10-31T19:00:06","slug":"znakomstvo-s-helm-3","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/znakomstvo-s-helm-3","title":{"rendered":"Introduction \u00e0 Helm 3.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introduction \u00e0 Helm 3.\" src=\"\/wp-content\/uploads\/2019\/05\/6de0e2887ddcc802f1dd71c902325401.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Note de traduction.<\/b>Le 16 mai de cette ann\u00e9e \u2014 une date marquante dans le d\u00e9veloppement du gestionnaire de paquets pour Kubernetes \u2014 Helm. Ce jour-l\u00e0, la premi\u00e8re version alpha de la future version majeure du projet \u2014 3.0 \u2014 a \u00e9t\u00e9 pr\u00e9sent\u00e9e. Sa sortie apportera \u00e0 Helm des changements significatifs et tr\u00e8s attendus, sur lesquels beaucoup dans la communaut\u00e9 Kubernetes fondent de grands espoirs. Nous nous incluons parmi ceux-l\u00e0, car nous utilisons activement Helm pour d\u00e9ployer des applications : nous l'avons int\u00e9gr\u00e9 dans notre outil de mise en \u0153uvre CI\/CD. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">werf<\/a><\/noindex> et au fil du temps, nous contribuons modestement \u00e0 l'\u00e9volution du projet en amont. Cette traduction regroupe 7 notes du blog officiel de Helm, qui sont li\u00e9es \u00e0 la premi\u00e8re version alpha de Helm 3 et racontent l'histoire du projet ainsi que les principales caract\u00e9ristiques de Helm 3. Leur auteur est Matt \u00ab bacongobbler \u00bb Fisher, employ\u00e9 chez Microsoft et l'un des principaux mainteneurs de Helm.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Le 15 octobre 2015, le projet aujourd'hui connu sous le nom de Helm est n\u00e9. \u00c0 peine un an apr\u00e8s sa cr\u00e9ation, la communaut\u00e9 Helm a rejoint Kubernetes, tout en travaillant activement sur Helm 2. En juin 2018, Helm <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cncf.io\/blog\/2018\/06\/01\/cncf-to-host-helm\/\">est devenu un projet de la CNCF<\/a><\/noindex> en tant que projet en incubation. Remontons le temps jusqu'\u00e0 aujourd'hui \u2014 et voil\u00e0 que la premi\u00e8re version alpha du nouveau Helm 3 approche. <i>(cette version <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">a d\u00e9j\u00e0 eu lieu<\/a><\/noindex> mi-mai \u2014 note de la traduction.)<\/i>.<\/p>\n<p>Dans cet article, je vais raconter comment tout a commenc\u00e9, comment nous en sommes arriv\u00e9s \u00e0 ce stade actuel, pr\u00e9senter quelques caract\u00e9ristiques uniques disponibles dans la premi\u00e8re version alpha de Helm 3, et expliquer comment nous pr\u00e9voyons d'\u00e9voluer \u00e0 l'avenir.<\/p>\n<p>R\u00e9sum\u00e9 :<\/p>\n<ul>\n<li>l'histoire de la cr\u00e9ation de Helm;<\/li>\n<li>un doux adieu \u00e0 Tiller;<\/li>\n<li>les d\u00e9p\u00f4ts de charts;<\/li>\n<li>la gestion des versions;<\/li>\n<li>les changements dans les d\u00e9pendances des charts;<\/li>\n<li>les charts de biblioth\u00e8que;<\/li>\n<li>que faire ensuite ?<\/li>\n<\/ul>\n<p><\/p>\n<h2>L'histoire de la cr\u00e9ation de Helm<\/h2>\n<p><\/p>\n<h3>Naissance<\/h3>\n<p>\nHelm 1 a commenc\u00e9 comme un projet Open Source, cr\u00e9\u00e9 par la soci\u00e9t\u00e9 Deis. Nous \u00e9tions une petite startup, <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.microsoft.com\/blog\/2017\/04\/10\/microsoft-acquire-deis-help-companies-innovate-containers\/\">absorb\u00e9e<\/a><\/noindex> par Microsoft au printemps 2017. Notre autre projet Open Source, \u00e9galement appel\u00e9 Deis, avait un outil <code>deisctl<\/code>, qui \u00e9tait utilis\u00e9 (entre autres) pour installer et exploiter la plateforme Deis dans un <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/coreos\/fleet\">cluster Fleet.<\/a><\/noindex>\u00c0 l'\u00e9poque, Fleet \u00e9tait l'une des premi\u00e8res plateformes d'orchestration de conteneurs.<\/p>\n<p>Au milieu de 2015, nous avons d\u00e9cid\u00e9 de changer de cap et de migrer Deis (\u00e0 l'\u00e9poque renomm\u00e9 Deis Workflow) de Fleet vers Kubernetes. L'un des premiers outils \u00e0 \u00eatre repens\u00e9 \u00e9tait l'installateur. <code>deisctl<\/code>Nous l'avons utilis\u00e9 pour installer et g\u00e9rer Deis Workflow dans un cluster Fleet.<\/p>\n<p>Helm 1 a \u00e9t\u00e9 cr\u00e9\u00e9 \u00e0 l'image de gestionnaires de paquets bien connus comme Homebrew, apt et yum. Sa principale t\u00e2che consistait \u00e0 simplifier des t\u00e2ches telles que le conditionnement et l'installation d'applications dans Kubernetes. Helm a \u00e9t\u00e9 officiellement pr\u00e9sent\u00e9 en 2015 lors de la conf\u00e9rence KubeCon \u00e0 San Francisco.<\/p>\n<p>Notre premi\u00e8re tentative avec Helm a fonctionn\u00e9, mais elle n'a pas \u00e9t\u00e9 sans limitations s\u00e9rieuses. Il prenait un ensemble de manifestes Kubernetes, enrichis par des g\u00e9n\u00e9rateurs, comme blocs YAML d'entr\u00e9e. <i>(front-matter)<\/i>*, et t\u00e9l\u00e9chargeait les r\u00e9sultats dans Kubernetes.<\/p>\n<p><i>* <b>Note de traduction.<\/b>: Depuis la premi\u00e8re version de Helm, la syntaxe YAML a \u00e9t\u00e9 choisie pour d\u00e9crire les ressources Kubernetes, et lors de la r\u00e9daction des configurations, des mod\u00e8les Jinja et des scripts Python \u00e9taient pris en charge. Nous avons \u00e9crit plus en d\u00e9tail \u00e0 ce sujet et sur la conception de la premi\u00e8re version de Helm dans le chapitre \u00ab Br\u00e8ve histoire de Helm \u00bb <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">de ce mat\u00e9riau.<\/a><\/noindex>.<\/i><\/p>\n<p>Par exemple, pour remplacer un champ dans un fichier YAML, il fallait ajouter la construction suivante au manifeste :<\/p>\n<pre><code class=\"plaintext\">#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my\/pod.yaml<\/code><\/pre>\n<p>\nC'est g\u00e9nial qu'il existe aujourd'hui des g\u00e9n\u00e9rateurs de mod\u00e8les, n'est-ce pas ?<\/p>\n<p>Pour de nombreuses raisons, ce premier installateur Kubernetes n\u00e9cessitait une liste de fichiers manifeste rigoureusement d\u00e9finie et ex\u00e9cutait seulement une petite s\u00e9quence d'\u00e9v\u00e9nements fixes. Son utilisation \u00e9tait si difficile que l'\u00e9quipe R&amp;D de Deis Workflow a eu du mal lorsqu'elle a tent\u00e9 de porter son produit sur cette plateforme - cependant, les graines de l'id\u00e9e avaient d\u00e9j\u00e0 \u00e9t\u00e9 sem\u00e9es. Notre premi\u00e8re tentative a \u00e9t\u00e9 une excellente occasion d'apprentissage : nous avons r\u00e9alis\u00e9 que nous \u00e9tions r\u00e9ellement passionn\u00e9s par la cr\u00e9ation d'outils pragmatiques, r\u00e9solvant les probl\u00e8mes quotidiens de nos utilisateurs.<\/p>\n<p>S'appuyant sur l'exp\u00e9rience des erreurs pass\u00e9es, nous avons commenc\u00e9 \u00e0 d\u00e9velopper Helm 2.<\/p>\n<h3>Cr\u00e9ation de Helm 2<\/h3>\n<p>\n\u00c0 la fin de 2015, l'\u00e9quipe de Google nous a contact\u00e9s. Ils travaillaient sur un outil similaire pour Kubernetes. Le Deployment Manager pour Kubernetes \u00e9tait un port d'un outil existant utilis\u00e9 pour Google Cloud Platform. \u00ab Ne voulons-nous pas, a-t-on demand\u00e9, passer quelques jours \u00e0 discuter des similarit\u00e9s et des diff\u00e9rences ? \u00bb<\/p>\n<p>En janvier 2016, les \u00e9quipes de Helm et du Deployment Manager se sont rencontr\u00e9es \u00e0 Seattle pour \u00e9changer des id\u00e9es. Les n\u00e9gociations ont abouti \u00e0 un plan ambitieux : fusionner les deux projets pour cr\u00e9er Helm 2. Aux c\u00f4t\u00e9s de Deis et Google, des membres de l'\u00e9quipe de d\u00e9veloppement ont rejoint <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/skippbox\">SkippBox<\/a><\/noindex> <i>(qui fait maintenant partie de Bitnami - note du traducteur)<\/i>, et nous avons commenc\u00e9 \u00e0 travailler sur Helm 2.<\/p>\n<p>Nous voulions maintenir la simplicit\u00e9 d'utilisation de Helm, tout en ajoutant ce qui suit :<\/p>\n<ul>\n<li> des mod\u00e8les de charts pour la personnalisation ;<\/li>\n<li> la gestion intra-cluster pour les \u00e9quipes ;<\/li>\n<li> un r\u00e9f\u00e9rentiel de charts de premier ordre ;<\/li>\n<li> un format de packages stable avec une possibilit\u00e9 de signature ;<\/li>\n<li> un engagement ferme envers le versionnage s\u00e9mantique et le maintien de la compatibilit\u00e9 r\u00e9troactive entre les versions.<\/li>\n<\/ul>\n<p>\nPour atteindre ces objectifs, un deuxi\u00e8me \u00e9l\u00e9ment a \u00e9t\u00e9 ajout\u00e9 \u00e0 l'\u00e9cosyst\u00e8me Helm. Ce composant intra-cluster a \u00e9t\u00e9 appel\u00e9 Tiller et \u00e9tait responsable de l'installation et de la gestion des charts Helm.<\/p>\n<p>Depuis la sortie de Helm 2 en 2016, Kubernetes a connu plusieurs innovations majeures. Un acc\u00e8s bas\u00e9 sur les r\u00f4les (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/422801\/\">RBAC<\/a><\/noindex>), qui a finalement remplac\u00e9 le contr\u00f4le d'acc\u00e8s bas\u00e9 sur les attributs (ABAC). De nouveaux types de ressources ont \u00e9t\u00e9 introduits (les Deployments \u00e9taient encore en version b\u00eata \u00e0 l'\u00e9poque). Les d\u00e9finitions de ressources personnalis\u00e9es ont \u00e9t\u00e9 invent\u00e9es (elles \u00e9taient initialement appel\u00e9es Third Party Resources ou TPRs). Et surtout, un ensemble de meilleures pratiques est apparu.<\/p>\n<p>Dans le contexte de tous ces changements, Helm a continu\u00e9 \u00e0 servir fid\u00e8lement les utilisateurs de Kubernetes. Apr\u00e8s trois ans et de nombreux ajouts, il est devenu clair qu'il \u00e9tait temps d'apporter des modifications significatives \u00e0 la base de code pour que Helm puisse continuer \u00e0 r\u00e9pondre aux besoins croissants d'un \u00e9cosyst\u00e8me en \u00e9volution.<\/p>\n<h2>Un doux adieu \u00e0 Tiller<\/h2>\n<p>\nLors du d\u00e9veloppement de Helm 2, nous avons introduit Tiller comme partie de notre int\u00e9gration avec le Deployment Manager de Google. Tiller a jou\u00e9 un r\u00f4le cl\u00e9 pour les \u00e9quipes travaillant au sein d'un m\u00eame cluster : il permettait aux diff\u00e9rents experts en infrastructure d'interagir avec le m\u00eame ensemble de versions.<\/p>\n<p>Alors que le contr\u00f4le d'acc\u00e8s bas\u00e9 sur les r\u00f4les (RBAC) \u00e9tait activ\u00e9 par d\u00e9faut dans Kubernetes 1.6, travailler avec Tiller en production devenait plus compliqu\u00e9. En raison du grand nombre de politiques de s\u00e9curit\u00e9 possibles, notre position \u00e9tait de proposer par d\u00e9faut une configuration permissive. Cela permettait aux novices d'exp\u00e9rimenter avec Helm et Kubernetes sans avoir besoin de se plonger d'abord dans les r\u00e9glages de s\u00e9curit\u00e9. Malheureusement, cette configuration permissive pouvait donner \u00e0 l'utilisateur un \u00e9ventail de permissions trop large, dont il n'avait pas besoin. Les ing\u00e9nieurs DevOps et SRE devaient apprendre des \u00e9tapes op\u00e9rationnelles suppl\u00e9mentaires pour installer Tiller dans un cluster multi-locataire.<\/p>\n<p>En apprenant comment les membres de la communaut\u00e9 utilisent Helm dans des situations sp\u00e9cifiques, nous avons r\u00e9alis\u00e9 que le syst\u00e8me de gestion des versions de Tiller n'avait pas besoin de s'appuyer sur un composant intra-cluster pour maintenir des \u00e9tats ou agir comme un hub central pour les informations sur les versions. Au lieu de cela, nous pourrions simplement obtenir des informations \u00e0 partir de l'API server de Kubernetes, g\u00e9n\u00e9rer le chart c\u00f4t\u00e9 client et conserver un enregistrement de l'installation dans Kubernetes.<\/p>\n<p>La fonction principale de Tiller pouvait \u00eatre r\u00e9alis\u00e9e sans lui, donc l'une de nos premi\u00e8res d\u00e9cisions concernant Helm 3 a \u00e9t\u00e9 de se d\u00e9barrasser compl\u00e8tement de Tiller.<\/p>\n<p>Avec le d\u00e9part de Tiller, le mod\u00e8le de s\u00e9curit\u00e9 de Helm a \u00e9t\u00e9 radicalement simplifi\u00e9. Helm 3 prend d\u00e9sormais en charge toutes les m\u00e9thodes modernes de s\u00e9curit\u00e9, d'identification et d'autorisation du Kubernetes actuel. Les permissions de Helm sont d\u00e9finies \u00e0 l'aide de <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/organize-cluster-access-kubeconfig\/\">fichier kubeconfig<\/a><\/noindex>. Les administrateurs de cluster peuvent restreindre les droits des utilisateurs avec un degr\u00e9 de d\u00e9tail variable. Les versions sont toujours conserv\u00e9es dans le cluster, et le reste de la fonctionnalit\u00e9 de Helm est pr\u00e9serv\u00e9.<\/p>\n<h2>D\u00e9p\u00f4ts de charts<\/h2>\n<p>\n\u00c0 un niveau \u00e9lev\u00e9, un d\u00e9p\u00f4t de charts est un endroit o\u00f9 l'on peut stocker et partager des charts. Le client Helm empaquete et envoie des charts au d\u00e9p\u00f4t. En termes simples, un d\u00e9p\u00f4t de charts est un serveur HTTP primitif avec un fichier index.yaml et quelques charts empaquet\u00e9s.<\/p>\n<p>Bien qu'il y ait certains avantages \u00e0 ce que l'API du d\u00e9p\u00f4t de charts r\u00e9ponde aux exigences de base du stockage, elle pr\u00e9sente aussi plusieurs inconv\u00e9nients :<\/p>\n<ul>\n<li> Les d\u00e9p\u00f4ts de charts sont mal compatibles avec la plupart des impl\u00e9mentations de s\u00e9curit\u00e9 n\u00e9cessaires dans un environnement de production. La disponibilit\u00e9 d'une API standard pour l'authentification et l'autorisation est cruciale dans les sc\u00e9narios de production.<\/li>\n<li> Les outils de Helm pour suivre l'origine des charts, utilis\u00e9s pour la signature, la v\u00e9rification de l'int\u00e9grit\u00e9 et l'origine des charts, font partie int\u00e9grante du processus de publication d'un chart.<\/li>\n<li> Dans des sc\u00e9narios multi-utilisateurs, le m\u00eame chart peut \u00eatre charg\u00e9 par un autre utilisateur, doublant ainsi l'espace n\u00e9cessaire pour stocker le m\u00eame contenu. Pour r\u00e9soudre ce probl\u00e8me, des d\u00e9p\u00f4ts plus intelligents ont \u00e9t\u00e9 d\u00e9velopp\u00e9s, mais ils ne font pas partie de la sp\u00e9cification formelle.<\/li>\n<li> L'utilisation d'un unique fichier d'index pour rechercher, stocker des m\u00e9tadonn\u00e9es et obtenir des charts a compliqu\u00e9 le d\u00e9veloppement d'impl\u00e9mentations multi-utilisateurs s\u00e9curis\u00e9es.<\/li>\n<\/ul>\n<p>\nProjet <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/docker\/distribution\">Docker Distribution<\/a><\/noindex> aussi connu sous le nom de Docker Registry v2, est le successeur de Docker Registry et constitue en r\u00e9alit\u00e9 un ensemble d'outils pour empaqueter, envoyer, stocker et livrer des images Docker. De nombreux grands services cloud proposent des produits bas\u00e9s sur Distribution. Gr\u00e2ce \u00e0 cette attention accrue, le projet Distribution a b\u00e9n\u00e9fici\u00e9 de nombreuses am\u00e9liorations au fil des ans, des meilleures pratiques en mati\u00e8re de s\u00e9curit\u00e9 et de tests en conditions r\u00e9elles, en le transformant en l'un des h\u00e9ros m\u00e9connus les plus r\u00e9ussis du monde de l'Open Source.<\/p>\n<p>Mais saviez-vous que le projet Distribution a \u00e9t\u00e9 con\u00e7u pour distribuer toute forme de contenu, pas seulement des images de conteneurs?<\/p>\n<p>Gr\u00e2ce aux efforts de <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opencontainers.org\/\">Open Container Initiative<\/a><\/noindex> ou OCI, les charts Helm peuvent \u00eatre h\u00e9berg\u00e9s sur n'importe quelle instance de Distribution. Bien que ce processus soit encore exp\u00e9rimental. Le travail sur le support des connexions et d'autres fonctions n\u00e9cessaires \u00e0 un Helm 3 pleinement fonctionnel n'est pas encore termin\u00e9, mais nous sommes tr\u00e8s enthousiastes \u00e0 l'id\u00e9e d'apprendre des d\u00e9couvertes faites par les \u00e9quipes OCI et Distribution au fil des ans. Gr\u00e2ce \u00e0 leur mentorat et \u00e0 leurs conseils, nous d\u00e9couvrons ce qu'implique l'exploitation d'un service hautement disponible \u00e0 grande \u00e9chelle.<\/p>\n<p>Une description plus d\u00e9taill\u00e9e de certains changements \u00e0 venir dans les d\u00e9p\u00f4ts de charts Helm est disponible. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.bacongobbler.com\/post\/2019-01-25-distributing-with-distribution\/\">via le lien<\/a><\/noindex>.<\/p>\n<h2>Gestion des versions<\/h2>\n<p>\nDans Helm 3, l'\u00e9tat de l'application est suivi \u00e0 l'int\u00e9rieur du cluster par une paire d'objets :<\/p>\n<ul>\n<li> l'objet release \u2014 repr\u00e9sente une instance de l'application;<\/li>\n<li> le secret de version de release \u2014 repr\u00e9sente l'\u00e9tat souhait\u00e9 de l'application \u00e0 un moment donn\u00e9 (par exemple, la sortie d'une nouvelle version).<\/li>\n<\/ul>\n<p>\nde system-nspawn <code>helm install<\/code> cr\u00e9e un objet release et un secret de version de release. L'appel <code>helm upgrade<\/code> n\u00e9cessite un objet release (qu'il peut modifier) et cr\u00e9e un nouveau secret de version de release contenant de nouvelles valeurs et un manifeste pr\u00e9par\u00e9.<\/p>\n<p>L'objet de release contient des informations sur le release, o\u00f9 le release est une installation sp\u00e9cifique d'un chart nomm\u00e9 et de valeurs. Cet objet d\u00e9crit les m\u00e9tadonn\u00e9es de haut niveau concernant le release. L'objet de release est conserv\u00e9 tout au long du cycle de vie de l'application et est le propri\u00e9taire de tous les secrets de version de release, ainsi que de tous les objets cr\u00e9\u00e9s directement par le chart Helm.<\/p>\n<p>Le secret de version de release lie la release \u00e0 une s\u00e9rie de r\u00e9visions (installation, mises \u00e0 jour, retours en arri\u00e8re, suppression).<\/p>\n<p>Dans Helm 2, les r\u00e9visions \u00e9taient exclusivement s\u00e9quentielles. L'appel <code>helm install<\/code> il a cr\u00e9\u00e9 v1, la mise \u00e0 jour suivante (upgrade) \u00e9tant v2, et ainsi de suite. Le release et le secret de version de release ont \u00e9t\u00e9 fusionn\u00e9s en un seul objet, connu sous le nom de r\u00e9vision. Les r\u00e9visions \u00e9taient stock\u00e9es dans le m\u00eame espace de noms que Tiller, ce qui signifiait que chaque release \u00e9tait \u00ab global \u00bb en termes d'espace de noms ; par cons\u00e9quent, un seul exemplaire du nom pouvait \u00eatre utilis\u00e9.<\/p>\n<p>Dans Helm 3, chaque release est li\u00e9e \u00e0 un ou plusieurs secrets de version de release. L'objet de release d\u00e9crit toujours le release actuel, d\u00e9ploy\u00e9 dans Kubernetes. Chaque secret de version de release d\u00e9crit une seule version de ce release. Une mise \u00e0 jour (upgrade), par exemple, cr\u00e9era un nouveau secret de version de release et changera ensuite l'objet de release pour qu'il pointe vers cette nouvelle version. En cas de retour en arri\u00e8re (rollback), les secrets de version de release pr\u00e9c\u00e9dents peuvent \u00eatre utilis\u00e9s pour restaurer le release \u00e0 son \u00e9tat pr\u00e9c\u00e9dent.<\/p>\n<p>Apr\u00e8s l'abandon de Tiller, Helm 3 stocke les donn\u00e9es du release dans l'espace de noms unique li\u00e9 au release. Ce changement permet d'installer un chart avec le m\u00eame nom de release dans un autre espace de noms, et les donn\u00e9es sont conserv\u00e9es entre les mises \u00e0 jour \/ red\u00e9marrages du cluster dans etcd. Par exemple, vous pouvez installer WordPress dans l'espace de noms \u00ab foo \u00bb, puis dans l'espace de noms \u00ab bar \u00bb, et les deux releases peuvent s'appeler \u00ab wordpress \u00bb.<\/p>\n<h2>Changements dans les d\u00e9pendances des charts<\/h2>\n<p>\nCharts, empaquet\u00e9s (\u00e0 l'aide de <code>helm package<\/code>) pour une utilisation avec Helm 2, il peut \u00eatre install\u00e9 avec Helm 3, cependant, le processus de d\u00e9veloppement des charts a \u00e9t\u00e9 compl\u00e8tement r\u00e9vis\u00e9, donc certaines modifications doivent \u00eatre apport\u00e9es pour continuer le d\u00e9veloppement des charts avec Helm 3. En particulier, le syst\u00e8me de gestion des d\u00e9pendances des charts a chang\u00e9.<\/p>\n<p>Le syst\u00e8me de gestion des d\u00e9pendances des charts est pass\u00e9 de <code>requirements.yaml<\/code> et <code>requirements.lock<\/code> sur <code>Chart.yaml<\/code> et <code>Chart.lock<\/code>. Cela signifie que les charts ayant utilis\u00e9 la commande <code>helm dependency<\/code>, n\u00e9cessitent une certaine configuration pour fonctionner dans Helm 3.<\/p>\n<p>Prenons un exemple. Ajoutons une d\u00e9pendance \u00e0 un chart dans Helm 2 et voyons ce qui change lors de la migration vers Helm 3.<\/p>\n<p>Dans Helm 2 <code>requirements.yaml<\/code> il apparaissait comme suit :<\/p>\n<pre><code class=\"plaintext\">dependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https:\/\/kubernetes-charts.storage.googleapis.com\/\n  condition: mariadb.enabled\n  tags:\n    - database<\/code><\/pre>\n<p>\nDans Helm 3, la m\u00eame d\u00e9pendance sera refl\u00e9t\u00e9e dans votre <code>Chart.yaml<\/code>:<\/p>\n<pre><code class=\"plaintext\">dependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https:\/\/kubernetes-charts.storage.googleapis.com\/\n  condition: mariadb.enabled\n  tags:\n    - database<\/code><\/pre>\n<p>\nLes charts continuent d'\u00eatre t\u00e9l\u00e9charg\u00e9s et plac\u00e9s dans le r\u00e9pertoire <code>charts\/<\/code>, donc les sous-charts <i>(subcharts)<\/i>, situ\u00e9s dans le r\u00e9pertoire <code>charts\/<\/code>, continueront de fonctionner sans modifications.<\/p>\n<h2>Pr\u00e9sentation des Library Charts<\/h2>\n<p>\nHelm 3 prend en charge une classe de charts appel\u00e9e charts-libraries <i>(library chart)<\/i>. Ce chart est utilis\u00e9 par d'autres charts, mais ne cr\u00e9e lui-m\u00eame aucun artefact de release. Les mod\u00e8les des charts de biblioth\u00e8que peuvent uniquement d\u00e9clarer des \u00e9l\u00e9ments. <code>define<\/code>. Tout autre contenu est simplement ignor\u00e9. Cela permet aux utilisateurs de r\u00e9utiliser et d'\u00e9changer des morceaux de code qui peuvent \u00eatre utilis\u00e9s dans de nombreux charts, \u00e9vitant ainsi la duplication et respectant le principe de <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Don%27t_repeat_yourself\">DRY<\/a><\/noindex>.<\/p>\n<p>Les Library charts sont d\u00e9clar\u00e9s dans la section <code>d\u00e9pendances<\/code> dans le fichier <code>Chart.yaml<\/code>. L'installation et la gestion de ceux-ci ne diff\u00e8rent pas des autres charts.<\/p>\n<pre><code class=\"plaintext\">dependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io<\/code><\/pre>\n<p>\nNous attendons avec impatience les cas d'utilisation que ce composant ouvrira aux d\u00e9veloppeurs de charts, ainsi que les meilleures pratiques qui pourraient \u00e9merger gr\u00e2ce aux library charts.<\/p>\n<h2>Et apr\u00e8s ?<\/h2>\n<p>\nHelm 3.0.0-alpha.1 est la base sur laquelle nous commen\u00e7ons \u00e0 cr\u00e9er une nouvelle version de Helm. Dans cet article, j'ai d\u00e9crit certaines fonctionnalit\u00e9s int\u00e9ressantes de Helm 3. Beaucoup d'entre elles sont encore \u00e0 un stade pr\u00e9coce de d\u00e9veloppement et c'est normal ; l'id\u00e9e d'une version alpha est de tester l'id\u00e9e, de recueillir des retours des premiers utilisateurs et de valider nos hypoth\u00e8ses.<\/p>\n<p>D\u00e8s que la version alpha sera publi\u00e9e <i>(rappelons que cela <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">est d\u00e9j\u00e0 arriv\u00e9<\/a><\/noindex> \u2014 n.d.t.)<\/i>, nous commencerons \u00e0 accepter les patches pour Helm 3 de la part de la communaut\u00e9. Il est n\u00e9cessaire de cr\u00e9er une base solide qui permettra de d\u00e9velopper et d\u2019accepter de nouvelles fonctionnalit\u00e9s, et les utilisateurs pourront s\u2019impliquer dans le processus en ouvrant des tickets et en soumettant des corrections.<\/p>\n<p>Dans cet article, j'ai essay\u00e9 de mettre en lumi\u00e8re certaines am\u00e9liorations majeures qui appara\u00eetront dans Helm 3, cependant, cette liste ne peut en aucun cas \u00eatre consid\u00e9r\u00e9e comme exhaustive. Le plan \u00e0 grande \u00e9chelle pour Helm 3 inclut des nouveaut\u00e9s telles que des strat\u00e9gies de mise \u00e0 jour am\u00e9lior\u00e9es, une int\u00e9gration plus profonde avec les registres OCI et l'utilisation de sch\u00e9mas JSON pour valider les valeurs des charts. Nous pr\u00e9voyons \u00e9galement de nettoyer la base de code et de mettre \u00e0 jour les parties qui sont rest\u00e9es sans attention ces trois derni\u00e8res ann\u00e9es.<\/p>\n<p>Si vous pensez que nous avons omis quelque chose, nous serions ravis d'entendre vos id\u00e9es !<\/p>\n<p>Rejoignez la discussion dans nos <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.slack.com\/\">canaux Slack<\/a><\/noindex>:<\/p>\n<ul>\n<li> <code>#helm-users<\/code> pour poser des questions et simplement discuter avec la communaut\u00e9;<\/li>\n<li> <code>#helm-dev<\/code> pour discuter des pull requests, du code et des bugs.<\/li>\n<\/ul>\n<p>\nVous pouvez \u00e9galement \u00e9changer lors de nos appels hebdomadaires publics de d\u00e9veloppeurs, tous les jeudis \u00e0 19h30 MSK. Les r\u00e9unions sont d\u00e9di\u00e9es \u00e0 la discussion des t\u00e2ches sur lesquelles travaillent les d\u00e9veloppeurs cl\u00e9s et la communaut\u00e9, ainsi qu\u2019aux sujets \u00e0 aborder pour la semaine. Tout le monde est bienvenu pour se joindre et participer \u00e0 la r\u00e9union. Le lien est disponible dans le canal Slack <code>#helm-dev<\/code>.<\/p>\n<h2>P.S. de l'auteur<\/h2>\n<p>\nLisez aussi dans notre blog :<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">Le gestionnaire de paquets pour Kubernetes \u2014 Helm : pass\u00e9, pr\u00e9sent, futur<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438814\/\">Un regard lucide sur Helm 2 : \u00ab Tel quel\u2026 \u00bb<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/420437\/\">Une introduction pratique au gestionnaire de paquets pour Kubernetes \u2014 Helm<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/441964\/\">Conseils &amp; astuces Kubernetes : traduction des ressources fonctionnant dans le cluster sous la gestion de Helm 2<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/336170\/\">Pratique avec dapp. Partie 2. D\u00e9ploiement d'images Docker dans Kubernetes avec Helm<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/453734\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: 16 \u043c\u0430\u044f \u044d\u0442\u043e\u0433\u043e \u0433\u043e\u0434\u0430 \u2014 \u0437\u043d\u0430\u0447\u0438\u043c\u0430\u044f \u0432\u0435\u0445\u0430 \u0432 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0430 \u043f\u0430\u043a\u0435\u0442\u043e\u0432 \u0434\u043b\u044f Kubernetes \u2014 Helm. \u0412 \u044d\u0442\u043e\u0442 \u0434\u0435\u043d\u044c \u0431\u044b\u043b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d \u043f\u0435\u0440\u0432\u044b\u0439 \u0430\u043b\u044c\u0444\u0430-\u0440\u0435\u043b\u0438\u0437 \u0431\u0443\u0434\u0443\u0449\u0435\u0439 \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u2014 3.0. \u0415\u0451 \u0432\u044b\u0445\u043e\u0434 \u043f\u0440\u0438\u043d\u0435\u0441\u0451\u0442 \u0432 Helm \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0435 \u0438 \u0434\u043e\u043b\u0433\u043e\u0436\u0434\u0430\u043d\u043d\u044b\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043d\u043e\u0433\u0438\u0435 \u0432 Kubernetes-\u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0435 \u0432\u043e\u0437\u043b\u0430\u0433\u0430\u044e\u0442 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u043d\u0430\u0434\u0435\u0436\u0434\u044b. \u041a \u0442\u0430\u043a\u043e\u0432\u044b\u043c \u043e\u0442\u043d\u043e\u0441\u0438\u043c\u0441\u044f \u0438 \u043c\u044b \u0441\u0430\u043c\u0438, \u043f\u043e\u0441\u043a\u043e\u043b\u044c\u043a\u0443 \u0430\u043a\u0442\u0438\u0432\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26173,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34735","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 Helm 3 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:00:06+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:06+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Introduction \u00e0 Helm 3 | ProHoster","description":"Ex.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/znakomstvo-s-helm-3","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 Helm 3 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/znakomstvo-s-helm-3","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:00:06+00:00","article:modified_time":"2019-10-31T19:00:06+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34735","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 20:26:53","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 23:08:04","updated":"2026-01-21 20:26:53","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/34735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=34735"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/34735\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/26173"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=34735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=34735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=34735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}