From 4559c1760d1caf2cd9a1d9c07ba25026dd7f372f Mon Sep 17 00:00:00 2001 From: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Thu, 1 Aug 2024 16:47:12 +0200 Subject: [PATCH 01/15] Translate Best Pratices un french Signed-off-by: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- .../fr/docs/chart_best_practices/_index.md | 12 + .../docs/chart_best_practices/conventions.md | 42 ++++ .../custom_resource_definitions.md | 38 ++++ .../docs/chart_best_practices/dependencies.md | 62 ++++++ .../fr/docs/chart_best_practices/labels.md | 36 +++ content/fr/docs/chart_best_practices/pods.md | 68 ++++++ content/fr/docs/chart_best_practices/rbac.md | 74 ++++++ .../fr/docs/chart_best_practices/templates.md | 210 ++++++++++++++++++ .../fr/docs/chart_best_practices/values.md | 136 ++++++++++++ 9 files changed, 678 insertions(+) create mode 100644 content/fr/docs/chart_best_practices/_index.md create mode 100644 content/fr/docs/chart_best_practices/conventions.md create mode 100644 content/fr/docs/chart_best_practices/custom_resource_definitions.md create mode 100644 content/fr/docs/chart_best_practices/dependencies.md create mode 100644 content/fr/docs/chart_best_practices/labels.md create mode 100644 content/fr/docs/chart_best_practices/pods.md create mode 100644 content/fr/docs/chart_best_practices/rbac.md create mode 100644 content/fr/docs/chart_best_practices/templates.md create mode 100644 content/fr/docs/chart_best_practices/values.md diff --git a/content/fr/docs/chart_best_practices/_index.md b/content/fr/docs/chart_best_practices/_index.md new file mode 100644 index 000000000..0bbf53e9c --- /dev/null +++ b/content/fr/docs/chart_best_practices/_index.md @@ -0,0 +1,12 @@ +--- +title: "Bonnes Pratiques" +sidebar: true +weight: 4 +--- + +# Le guide des Bonnes Pratiques + +Ce guide couvre les bonnes pratiques considérées par l'équipe de Helm, pour créer des charts. Il se concentre sur la manière dont les charts doivent structurés. + + +Nous nous concentrons principalement sur les meilleures pratiques pour les charts qui peuvent être déployés publiquement. Nous savons que de nombreux charts sont destinés à un usage interne uniquement et les auteurs des ces charts peuvent estimer que leurs intérêts internes priment sur nos suggestions ici. diff --git a/content/fr/docs/chart_best_practices/conventions.md b/content/fr/docs/chart_best_practices/conventions.md new file mode 100644 index 000000000..0c0707e34 --- /dev/null +++ b/content/fr/docs/chart_best_practices/conventions.md @@ -0,0 +1,42 @@ +--- +title: "Conventions Générales" +description: "Conventions générales pour les charts." +weight: 1 +--- + +Cette partie du Guide des Bonnes Pratiques présente les conventions générales + +## Nommages des Charts + +Les noms de charts doivent être constitués de lettres minuscules et de chiffres. Les mots _peuvent_ être séparés par des tirets (-) : + +Exemples : + +``` +drupal +nginx-lego +aws-cluster-autoscaler +``` + +Ni les majuscules ni les traits de soulignement ne peuvent être utilisés dans les noms de charts. Les points ne doivent pas être utilisés dans les noms de charts. + +## Numérotation de Version + +Dans la mesure du possible, Helm utilise [SemVer 2](https://semver.org) pour représenter les numéros de version. (Notez que les tags des images Docker ne suivent pas nécessairement SemVer et et sont donc considérées comme une malheureuse exception à la règle.) + +Quand les versions SemVer sont stockées dans les labels Kubernetes, nous remplaçons conventionnellement le caractère `+` par un `_` car les labels n'autorisent pas le signe `+` comme valeur. + +## Formatage YAML + +Les fichiers YAML doivent être indentés en utilisant _deux espaces_ (et non avec des tabulations). + +## Utilisation des mots Helm et Chart + +Il existe plusieurs conventions pour utiliser les mots _Helm_ et _helm_. + +- _Helm_ fait référence au projet dans son ensemble +- `helm` fait référence à la commande côté client +- Le terme `chart` n'a pas besoin d'être majuscule, car ce n'est pas un nom propre +- Cependant, `Chart.yaml` doit être en majuscule car le nom du fichier est sensible à la casse + +En cas de doute, utilisez _Helm_ (avec un 'H' majuscule). diff --git a/content/fr/docs/chart_best_practices/custom_resource_definitions.md b/content/fr/docs/chart_best_practices/custom_resource_definitions.md new file mode 100644 index 000000000..c0b5c8349 --- /dev/null +++ b/content/fr/docs/chart_best_practices/custom_resource_definitions.md @@ -0,0 +1,38 @@ +--- +title: "Définition de Ressource Personalisée" +description: "Comment gérer la création et l'utilisation de CRDs." +weight: 7 +--- + +Cette section du Guide des Bonnes Pratiques traite de la création et de l'utilisation d'objets de Définition de Ressource Personnalisée. + +Lorsque vous travaillez avec des Définitions de Ressource Personnalisées (_Custom Resource Definitions, CRDs_), il est important de distinguer deux types différents : + +- Il existe une déclaration de CRD. Il s'agit d'un fichier YAML qui a le genre `CustomResourceDefinition` +- Ensuite, il y a des ressources qui _utilisent_ le CRD. Supposons qu'une CRD définisse `foo.example.com/v1`. Toutes ressource ayant `ApiVersion : example.com/v1` et `kind: foo` est une ressource qui utilise la CRD. + +## Installer une déclaration CRD avant d'utiliser la ressource + +Helm est optimisé pour charger le plus de ressources possible dans Kubernetes aussi rapidement que possible. Par conception, Kubernetes peut prendre un ensemble complet de manifests et les mettre tous en ligne (c'est ce qu'on appelle la boucle de reconciliation). + +Mais il y a une différence avec les CRDs. + +Pour une CRD, la déclaration doit être enregistrée avant que des ressources de ce(s) type(s) puissent être utilisées. Ce processus d'enregistrement prend parfois quelques secondes. + +### Méthode 1 : Laisse `Helm` le faire pour toi + +Avec l'arrivée de Helm 3, nous avons supprimé les anciens hooks `crd-install` au profit d'une méthodologie plus simple. Il existe maintenant un répertoire spécial appelé `crds` que vous pouvez créer dans votre chart pour y placer vos CRDs. Ces CRDs ne sont pas templatisées, mais seront installées par défaut lors de l'exécution de la commande `helm install` pour le chart. Si la CRD existe déjà, elle sera ignorée avec un avertissement. Si vous souhaitez passer l'étape d'installation des CRDs, vous pouvez utiliser l'option `--skip-crds`. + +#### Quelques mises en garde (et explications) + +Il n'y a pas de support pour la mise à niveau ou la suppression des CRDs avec Helm pour le moment. Il s'agit d'une décision explicite prise après de nombreuses discussions au sein de la communauté en raison du risque de perte de données non intentionnelle. De plus, il n'y a pas encore de consensus au sein de la communauté sur la manière de gérer les CRDs et leur cycle de vie. À mesure que cela évoluera, Helm ajoutera un support pour ces cas d'utilisation. + +L'option `--dry-run` des commandes `helm install` et `helm upgrade` n'est pas actuellement supportée pour les CRDs. L'objectif de l'option "Dry Run" est de valider que le résultat du chart fonctionnera réellement s'il est envoyé au serveur. Mais les CRDs sont une modification du comportement du serveur. Helm ne peut pas installer le CRD lors d'un dry run, donc le client de découverte ne connaîtra pas cette Ressource Personnalisée (CR), et la validation échouera. Vous pouvez alternativement déplacer les CRDs dans leur propre chart ou utiliser `helm template` à la place. + +Un autre point important à considérer dans la discussion autour du support des CRDs est la manière dont le rendu des templates est géré. Un des inconvénients majeurs de la méthode `crd-install` utilisée dans Helm 2 était l'incapacité de valider correctement les charts en raison de la disponibilité changeante des API (une CRD ajoute en fait une autre API disponible à votre cluster Kubernetes). Si un chart installait une CRD, `helm` n'avait plus un ensemble valide de versions d'API sur lequel se baser. C'est également la raison pour laquelle le support du templating a été supprimé pour les CRDs. Avec la nouvelle méthode d'installation des CRDs via le répertoire `crds`, nous veillons maintenant à ce que `helm` dispose d'informations complètement valides sur l'état actuel du cluster. + +### Méthode 2 : Charts séparés + +Une autre façon de procéder est de placer la définition du CRD dans un chart, puis de mettre les ressources qui utilisent cette CRD dans _un autre_ chart. + +Avec cette méthode, chaque chart doit être installé séparément. Cependant, ce workflow peut être plus utile pour les opérateurs de cluster qui ont un accès admin à un cluster. diff --git a/content/fr/docs/chart_best_practices/dependencies.md b/content/fr/docs/chart_best_practices/dependencies.md new file mode 100644 index 000000000..b77e43857 --- /dev/null +++ b/content/fr/docs/chart_best_practices/dependencies.md @@ -0,0 +1,62 @@ +--- +title: "Dépendances" +description: "Couvre les meilleures pratiques pour les dépendances des Charts." +weight: 4 +--- + +Cette section du guide couvre les bonne pratiques pour les `dependencies` déclarées dans `Chart.yaml`. + +## Versions + +Dans la mesure du possible, utilisez des plages de versions au lieu d’épingler une version exacte. La valeur par défaut suggérée consiste à utiliser une correspondance de version au niveau du correctif : + +```yaml +version: ~1.2.3 +``` + +Cela correspondra à la version `1.2.3`et tous les correctifs de cette version. Autrement dit, `~1.2.3` est équivalent à `>= 1.2.3, < 1.3.0` + +Pour la syntaxe complète de correspondance de version, veuillez consulter la [documentation semver](https://github.com/Masterminds/semver#checking-version-constraints). + +### Versions préliminaires + +Les contraintes de version ci-dessus ne correspondront pas aux versions préliminaires. Par exemple, `version: ~1.2.3` correspondra à `version: ~1.2.4` mais pas à `version: ~1.2.3-1`. Ce qui suit permet de faire correspondre à la fois les versions préliminaires et les niveaux de correctifs : + +```yaml +version: ~1.2.3-0 +``` + +### URL de dépots + +Dans la mesure du possible, utilisez des URLs de dépots en `https://`, suivie des URLs en `http://`. + +Si le dépôt a été ajouté au fichier d'index des dépôts, le nom du dépôt peut être utilisé comme un alias de l'URL. Utilisez `alias:` ou `@` suivi des noms de dépôt. + +Les URLs de type `file://...` sont considérées comme un "cas spécial" pour les charts qui sont assemblés par un pipeline de déploiement fixe. + +Lorsque vous utilisez des [plugins de téléchargement](), le schéma de l'URL sera spécifique au plugin. Notez qu'un utilisateur du chart devra avoir un plugin prenant en charge le schéma installé pour mettre à jour ou construire la dépendance. + +Helm ne peut pas effectuer d'opérations de gestion des dépendances sur la dépendance lorsque le champ `repository` est laissé vide. Dans ce cas, Helm supposera que la dépendance se trouve dans un sous-répertoire du dossier `charts`, avec un nom identique à la propriété `name` de la dépendance. + +## Conditions et Tags + +Les conditions ou les tags doivent être ajoutés à toutes les dépendances qui _sont optionnelles_. + +La forme préférée pour une condition est : + +```yaml +condition: somechart.enabled +``` + +Où `somechart` est le nom d'un chart de la dépendance. + +Lorsque plusieurs sous-charts (dépendances) fournissent ensemble une fonctionnalité optionnelle ou interchangeable, ces charts devraient partager les mêmes tags. + +Par exemple, si à la fois `nginx` et `memcached` fournissent ensemble des optimisations de performance pour l'application principale du chart, et qu'ils doivent tous deux être présents lorsque cette fonctionnalité est activée, alors ils devraient tous les deux avoir une section de tags comme ceci : + +```yaml +tags: + - webaccelerator +``` + +Cela permet à un utilisateur d'activer ou de désactiver cette fonctionnalité avec un seul tag. diff --git a/content/fr/docs/chart_best_practices/labels.md b/content/fr/docs/chart_best_practices/labels.md new file mode 100644 index 000000000..42a5d4c72 --- /dev/null +++ b/content/fr/docs/chart_best_practices/labels.md @@ -0,0 +1,36 @@ +--- +title: "Labels et Annotations" +description: "Couvre les bonnes pratiques pour l'utilisation des labels et des annotations dans votre Chart." +weight: 5 +--- + +Cette partie du Guide des Bonnes Pratiques discute des meilleures pratiques pour l'utilisation des labels et des annotations dans votre chart. + +## Est-ce un Label ou une Annotation ? + +Un élément de métadonnées doit être un label dans les conditions suivantes : + +- Il est utilisé par Kubernetes pour identifier cette ressource. +- Il est utile de l'exposer aux opérateurs pour interroger le système. + +Par exemple, nous suggérons d'utiliser `helm.sh/chart: NAME-VERSION` comme label afin que les opérateurs puissent facilement trouver toutes les instances d'un chart particulier à utiliser. + +Si un élément de métadonnées n'est pas utilisé pour les requêtes, il doit être défini comme une annotation à la place. + +Les hooks de Helm sont toujours des annotations. + +## Labels standards + +Le tableau suivant définit les labels couramment utilisés dans les charts Helm. Helm ne requiert jamais la présence d'un label particulier. Les labels marqués REC sont recommandés et _devraient_ être placés sur un chart pour une cohérence globale. Ceux marqués OPT sont optionnels. Ils sont idiomatiques ou couramment utilisés, mais ne sont pas souvent indispensables à des fins opérationnelles. + +Nom | Statut | Description +----- | ------ | ---------- +`app.kubernetes.io/name` | REC | Ce label doit correspondre au nom de l'application, reflétant l'ensemble de l'application. Habituellement, `{{ template "name" . }}` est utilisé pour cela. Ce label est utilisé par de nombreux manifests Kubernetes et n'est pas spécifique à Helm. +`helm.sh/chart` | REC | Ce label doit contenir le nom du chart et la version : `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. +`app.kubernetes.io/managed-by` | REC | Ce label doit toujours être défini sur `{{ .Release.Service }}`. Il permet de trouver tous les éléments gérés par Helm. +`app.kubernetes.io/instance` | REC | Ce label doit correspondre à `{{ .Release.Name }}`. Il aide à différencier les différentes instances de la même application. +`app.kubernetes.io/version` | OPT | La version de l'application, qui peut être définie sur `{{ .Chart.AppVersion }}`. +`app.kubernetes.io/component` | OPT | Ce label est couramment utilisé pour marquer les différents rôles que peuvent jouer les éléments d'une application. Par exemple, `app.kubernetes.io/component: frontend`. +`app.kubernetes.io/part-of` | OPT | Utilisé lorsque plusieurs charts ou éléments logiciels sont utilisés ensemble pour créer une application. Par exemple, un logiciel applicatif et une base de données pour produire un site web. Ce label peut être défini pour l'application principale soutenue. + +Vous pouvez trouver plus d'informations sur les labels Kubernetes, les prefix en `app.kubernetes.io`, dans la [documentation Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). diff --git a/content/fr/docs/chart_best_practices/pods.md b/content/fr/docs/chart_best_practices/pods.md new file mode 100644 index 000000000..5e228747a --- /dev/null +++ b/content/fr/docs/chart_best_practices/pods.md @@ -0,0 +1,68 @@ +--- +title: "Pods et PodTemplates" +description: "Formatage des parties Pod et PodTemplate dans les manifests de Chart." +weight: 6 +--- + +Cette partie du Guide des Bonnes Pratiques discute du formatage des sections Pod et PodTemplate dans les manifests de chart. + +La liste (non-exhaustive) des ressources suivantes, utilise des PodTemplates : + +- Deployment +- ReplicationController +- ReplicaSet +- DaemonSet +- StatefulSet + +## Images + +Une image de conteneur devrait utiliser un tag fixe ou le SHA de l'image. Elle ne devrait pas utiliser les tags `latest`, `head`, `canary`, ou d'autres tags conçus pour être "flottants". + + +Les images _peuvent_ être définies dans le fichier `values.yaml` pour faciliter le remplacement des images. + +```yaml +image: {{ .Values.redisImage | quote }} +``` + +Une image et un tag _peuvent_ être définie dans le fichier `values.yaml` séparé en deux champs distincts : + +```yaml +image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" +``` + +## ImagePullPolicy + +`helm create` définit par défaut la `imagePullPolicy` sur `IfNotPresent` en faisant ce qui suit dans votre `deployment.yaml` : + +```yaml +imagePullPolicy: {{ .Values.image.pullPolicy }} +``` + +Et dans le fichier `values.yaml` : + +```yaml +image: + pullPolicy: IfNotPresent +``` + +De même, Kubernetes définit par défaut la `imagePullPolicy` sur `IfNotPresent` si elle n'est pas du tout définie. Si vous souhaitez une valeur autre que `IfNotPresent`, il vous suffit de mettre à jour la valeur dans `values.yaml` selon vos besoins. + + +## Les PodTemplates devraient déclarer des sélecteurs + +Toutes les sections PodTemplate devraient spécifier un sélecteur. Par exemple : + +```yaml +selector: + matchLabels: + app.kubernetes.io/name: MyName +template: + metadata: + labels: + app.kubernetes.io/name: MyName +``` + +C'est une bonne pratique car cela établit clairement la relation entre le set et le pod. + +Mais c'est encore plus important pour des ensembles comme les Deployments. Sans cela, l'_ensemble_ des labels est utilisé pour sélectionner les pods correspondants, et cela peut échouer si vous utilisez des labels qui changent, comme la version ou la date de publication. diff --git a/content/fr/docs/chart_best_practices/rbac.md b/content/fr/docs/chart_best_practices/rbac.md new file mode 100644 index 000000000..9e3c5fc57 --- /dev/null +++ b/content/fr/docs/chart_best_practices/rbac.md @@ -0,0 +1,74 @@ +--- +title: "Role-Based Access Control" +description: "Création et formatage des ressources RBAC dans les manifests de Chart." +weight: 8 +--- + +Cette partie du Guide des Bonnes Pratiques discute de la création et du formatage des ressources RBAC dans les manifests de chart. + +Les ressources RBAC sont : + +- ServiceAccount (namespacé) +- Role (namespacé) +- ClusterRole +- RoleBinding (namespacé) +- ClusterRoleBinding + +## Configuration YAML + +RBAC and ServiceAccount configuration should happen under separate keys. They +are separate things. Splitting these two concepts out in the YAML disambiguates +them and makes this clearer. + +```yaml +rbac: + # Précise si les ressources RBAC doivent être créées + create: true + +serviceAccount: + # Précise si un ServiceAccount doit être créé + create: true + # Le nom du ServiceAccount à utiliser + # Si ce n'est pas défini et que la création est activée, un nom est généré en utilisant le nom complet du modèle. + name: +``` + +Cette structure peut être étendue pour des charts plus complexes qui nécessitent plusieurs ServiceAccounts. + +```yaml +someComponent: + serviceAccount: + create: true + name: +anotherComponent: + serviceAccount: + create: true + name: +``` + +## Les ressources RBAC devraient être créées par défaut + +`rbac.create` devrait être une valeur booléenne contrôlant la création des ressources RBAC. La valeur par défaut devrait être `true`. Les utilisateurs qui souhaitent gérer les contrôles d'accès RBAC eux-mêmes peuvent définir cette valeur sur `false` (voir ci-dessous dans ce cas). + +## Utilisation des ressources RBAC + +`serviceAccount.name` doit être défini sur le nom du ServiceAccount à utiliser par les ressources contrôlées par les accès créées par le chart. Si `serviceAccount.create` est vrai, alors un ServiceAccount avec ce nom doit être créé. Si le nom n'est pas défini, un nom est généré en utilisant le modèle `fullname`. Si `serviceAccount.create` est faux, le ServiceAccount ne doit pas être créé, mais il doit néanmoins être associé aux mêmes ressources afin que les ressources RBAC créées manuellement qui le référencent fonctionnent correctement. Si `serviceAccount.create` est faux et que le nom n'est pas spécifié, le ServiceAccount par défaut est utilisé. + +Le modèle d'aide suivant devrait être utilisé pour le ServiceAccount : + +```yaml +{{/* +Create the name of the service account to use +*/}} +{{- define "mychart.serviceAccountName" -}} +{{- if .Values.serviceAccount.create -}} + {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} +{{- else -}} + {{ default "default" .Values.serviceAccount.name }} +{{- end -}} +{{- end -}} +``` + +À l'heure actuelle, Helm ne dispose pas de mécanisme permettant d'extraire les RBAC nécessaire pour l'installation, la mise à jour et la désinstallation des charts. Ce qui est contraignant, si l'opérateur exécutant ces commandes Helm, n'a pas les droits admin sur le cluster Kubernetes ou des droits inférieurs à ceux présents dans les charts, cela peut faire remonté des erreurs. Pour ce faire, vous devrez lister manuellement tous les rôles présent dans les ressources RBAC des charts, en plus des rôles de `create`, `list`, `read`, `update`, ... obligatoire pour manipuler vos ressources. Ensuite attribuez ces rôles à l'opérateur pour qu'il puisse disposer au minimum de droit équivalent ou supérieur à ceux du chart. + +Note : Certain chart trouvable sur l'ArtifactHub n'ont pas été conçus pour être déployé avec des droits restreints (mais avec tous les droits `*`). Il se peut que vous devrez les modifier. diff --git a/content/fr/docs/chart_best_practices/templates.md b/content/fr/docs/chart_best_practices/templates.md new file mode 100644 index 000000000..6db7a9693 --- /dev/null +++ b/content/fr/docs/chart_best_practices/templates.md @@ -0,0 +1,210 @@ +--- +title: "Templates" +description: "Point plus précis sur les bonnes pratiques concernant les templates" +weight: 3 +--- + +Cette partie du Guide des Bonnes Pratiques se concentre sur les Templates. + +## Structure de `templates/` + +Le répertoire `templates/` devrait être structuré comme suit : + +- Les fichiers de template devraient avoir l'extension `.yaml` s'ils produisent une sortie en YAML. L'extension `.tpl` peut être utilisée pour les fichiers de template qui ne produisent aucun contenu formaté. +- Les noms de fichiers de template devraient utiliser la notation avec des tirets (`my-example-configmap.yaml`), et non le camelcase. +- Chaque définition de ressource devrait être dans son propre fichier de template. +- Les noms de fichiers de template devraient refléter le type de ressource dans le nom. Par exemple, `foo-pod.yaml`, `bar-svc.yaml`. + +## Noms des templates définis + +Les templates définis (templates créés à l'intérieur d'une directive `{{ define }}`) sont accessibles globalement. Cela signifie qu'un chart et tous ses sous-charts auront accès à tous les templates créés avec `{{ define }}`. + +Pour cette raison, _tous les noms de templates définis devraient être nommés de manière à inclure un espace de nom. + +Correct : + +```yaml +{{- define "nginx.fullname" }} +{{/* ... */}} +{{ end -}} +``` + +Incorrect : + +```yaml +{{- define "fullname" -}} +{{/* ... */}} +{{ end -}} +``` +Il est fortement recommandé de créer de nouveaux charts via la commande `helm create`, car les noms de templates y sont automatiquement définis conformément à cette bonne pratique. + +## Formatage de Templates + +Les templates doivent être indentés en utilisant _deux espaces_ (jamais de tabulations). + +Les directives de template doivent avoir un espace après les accolades d'ouverture et avant les accolades de fermeture : + +Correct : +``` +{{ .foo }} +{{ print "foo" }} +{{- print "bar" -}} +``` + +Incorrect : +``` +{{.foo}} +{{print "foo"}} +{{-print "bar"-}} +``` + +Les templates devraient supprimer les espaces blancs lorsque cela est possible : + +```yaml +foo: + {{- range .Values.items }} + {{ . }} + {{ end -}} +``` + +Les blocs (tels que les structures de contrôle) peuvent être indentés pour indiquer le flux du code du template. + +``` +{{ if $foo -}} + {{- with .Bar }}Hello{{ end -}} +{{- end -}} +``` + +Cependant, étant donné que YAML est un langage orienté sur les espaces blancs, il n'est souvent pas possible pour l'indentation du code de suivre cette convention. + +## Les espaces dans les templates générés + +Il est préférable de minimiser la quantité d'espaces blancs dans les templates générés. En particulier, de nombreuses lignes vides ne devraient pas apparaître les unes à côté des autres. Cependant, quelques lignes vides occasionnelles (notamment entre les sections logiques) sont acceptables. + +Le mieux : + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: example + labels: + first: first + second: second +``` + +Cela est OK : + +```yaml +apiVersion: batch/v1 +kind: Job + +metadata: + name: example + + labels: + first: first + second: second + +``` + +Mais cela devrait être a éviter : + +```yaml +apiVersion: batch/v1 +kind: Job + +metadata: + name: example + + + + + + labels: + first: first + + second: second + +``` + +## Commentaires (Commentaires YAML vs. Commentaires de Template) + +Tant YAML que les Templates Helm disposent de marqueurs de commentaire. + +Commentaires en YAML +```yaml +# Ceci est un commentaire +type: sprocket +``` + +Commentaires des les Template : +```yaml +{{- /* +c'est un commentaire +*/}} +type: frobnitz +``` + +Les commentaires dans les templates devraient être utilisés pour documenter les fonctionnalités d'un template, comme l'explication d'un template défini : + +```yaml +{{- /* +mychart.shortname fournit une version tronquée à 6 caractères du nom de la release. +*/}} +{{ define "mychart.shortname" -}} +{{ .Release.Name | trunc 6 }} +{{- end -}} + +``` + +À l'intérieur des templates, les commentaires YAML peuvent être utilisés lorsqu'il est utile que les utilisateurs de Helm puissent (éventuellement) voir les commentaires lors du débogage. + +```yaml +# Cela peut poser des problèmes si la valeur est supérieure à 100 Gi +memory: {{ .Values.maxMem | quote }} +``` + +Le commentaire ci-dessus est visible lorsque l'utilisateur exécute `helm install --debug`, tandis que les commentaires spécifiés dans les sections `{{- /* */}}` ne le sont pas. + +Attention à ne pas ajouter de commentaires YAML `#` dans les sections de template contenant des valeurs Helm qui peuvent être requises par certaines fonctions de template. + +Par exemple, si la fonction `required` est introduite dans l'exemple ci-dessus et que `maxMem` n'est pas définie, un commentaire YAML `#` introduira une erreur de rendu. + +Correct : `helm template` ne rend pas ce bloc. +```yaml +{{- /* +# Cela peut poser des problèmes si la valeur est supérieure à 100 Gi +memory: {{ required "maxMem must be set" .Values.maxMem | quote }} +*/ -}} +``` + +Incorrect : `helm template` retourne `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` +```yaml +# Cela peut poser des problèmes si la valeur est supérieure à 100 Gi +# memory: {{ required .Values.maxMem "maxMem must be set" | quote }} +``` + +Consultez [Débogage des Templates](../chart_template_guide/debugging.md) pour un autre exemple de ce comportement, montrant comment les commentaires YAML restent intacts. + +## Utilisation du JSON dans les Templates et la sortie des Templates + +YAML est un sur-ensemble de JSON. Dans certains cas, l'utilisation de la syntaxe JSON peut être plus lisible que d'autres représentations YAML. + +Par exemple, ce YAML est plus proche de la méthode normale YAML d'expression des listes : + +```yaml +arguments: + - "--dirname" + - "/foo" +``` + +Mais il est plus facile à lire lorsqu'il est compressé en style liste JSON : + +```yaml +arguments: ["--dirname", "/foo"] +``` + +Utiliser JSON pour améliorer la lisibilité est une bonne pratique. Cependant, la syntaxe JSON ne devrait pas être utilisée pour représenter des constructions plus complexes. + +Lorsqu'il s'agit de JSON pur intégré dans du YAML (comme la configuration des conteneurs d'initialisation), il est bien sûr approprié d'utiliser le format JSON. diff --git a/content/fr/docs/chart_best_practices/values.md b/content/fr/docs/chart_best_practices/values.md new file mode 100644 index 000000000..a7e887934 --- /dev/null +++ b/content/fr/docs/chart_best_practices/values.md @@ -0,0 +1,136 @@ +--- +title: "Values" +description: "Focussur la manière dont vous devez structurer et utiliser vos valeurs." +weight: 2 +--- + +Cette partie du guide des bonnes pratiques traite de l'utilisation des valeurs. Nous y fournissons des recommandations sur la manière dont vous devriez structurer et utiliser vos valeurs, en mettant l'accent sur la conception du fichier `values.yaml` d'un chart. + +## Conventions de nommage + +Les noms de variables devraient commencer par une lettre minuscule, et les mots devraient être séparés par camelcase : + +Correct : + +```yaml +chicken: true +chickenNoodleSoup: true +``` + +Incorrect : + +```yaml +Chicken: true # Les majuscules au début peuvent entrer en conflit avec les noms réservés intégrés. +chicken-noodle-soup: true # N'utilisez pas de tirets dans les noms. +``` + +Notez que toutes les variables intégrées de Helm commencent par une lettre majuscule pour les distinguer facilement des valeurs définies par l'utilisateur : `.Release.Name`, `.Capabilities.KubeVersion`. + +## Valeurs plates ou imbriquées + +YAML est un format flexible, et les valeurs peuvent être profondément imbriquées ou aplaties. + +Imbriquée : + +```yaml +server: + name: nginx + port: 80 +``` + +Plate : + +```yaml +serverName: nginx +serverPort: 80 +``` + +Dans la plupart des cas, il est préférable de privilégier les valeurs plates plutôt qu'imbriquées. La raison en est que cela est plus simple pour les développeurs de templates et les utilisateurs. + + +Pour une sécurité optimale, une valeur imbriquée doit être vérifiée à chaque niveau : + +``` +{{ if .Values.server }} + {{ default "none" .Values.server.name }} +{{ end }} +``` + +Pour chaque niveau d'imbrication, une vérification d'existence doit être effectuée. En revanche, pour une configuration plate, ces vérifications peuvent être omises, ce qui rend le template plus facile à lire et à utiliser. + +``` +{{ default "none" .Values.serverName }} +``` + +Lorsque plusieurs variables liées sont présentes et qu'au moins l'une d'elles est obligatoire, des valeurs imbriquées peuvent être utilisées pour améliorer la lisibilité. + +## Clarifiez les types + +Les règles de coercition des types en YAML sont parfois contre-intuitives. Par exemple, `foo: false` n'est pas la même chose que `foo: "false"`. De grands entiers comme `foo: 12345678` peuvent être convertis en notation scientifique dans certains cas. + +La manière la plus simple d'éviter les erreurs de conversion de types est d'être explicite pour les chaînes de caractères, et implicite pour tout le reste. En d'autres termes, _entourez toutes les chaînes de caractères de guillemets_. + +Souvent, pour éviter les problèmes de conversion d'entiers, il est avantageux de stocker vos entiers sous forme de chaînes de caractères également, et d'utiliser `{{ int $value }}` dans le template pour convertir une chaîne en entier. + +Dans la plupart des cas, les tags de type explicites sont respectés, donc `foo: !!string 1234` devrait traiter `1234` comme une chaîne. _Cependant_, le parseur YAML consomme les tags, donc les données de type sont perdues après un premier parsing. + +## Considérez comment les utilisateurs vont utiliser vos valeurs + +Il y a trois sources potentielles de valeurs : + +- Le fichier `values.yaml` d'un chart +- Un fichier de valeurs fourni par `helm install -f` ou `helm upgrade -f` +- Les valeurs passées avec l'option `--set` ou `--set-string` lors de l'exécution de `helm install` ou `helm upgrade` + +Lorsque vous concevez la structure de vos valeurs, gardez à l'esprit que les utilisateurs de votre chart peuvent vouloir les remplacer via l'option `-f` ou avec l'option `--set`. + +Comme `--set` est plus limité en termes d'expressivité, la première règle pour rédiger votre fichier `values.yaml` est _de faciliter le remplacement via `--set`_. + +Pour cette raison, il est souvent préférable de structurer votre fichier de valeurs en utilisant des cartes (maps). + +Difficile à utiliser avec `--set` : + +```yaml +servers: + - name: foo + port: 80 + - name: bar + port: 81 +``` + +Ce qui précède ne peut pas être exprimé avec `--set` dans Helm `<=2.4`. Dans Helm 2.5, l'accès au port de foo est `--set servers[0].port=80`. Non seulement il est plus difficile pour l'utilisateur de le comprendre, mais cela est également sujet à des erreurs si, à un moment ultérieur, l'ordre des `servers` est modifié. + +Facile à utiliser : + +```yaml +servers: + foo: + port: 80 + bar: + port: 81 +``` + +L'accès au port de foo est beaucoup plus évident : `--set servers.foo.port=80`. + +## Fichier `values.yaml` + +Chaque propriété définie dans `values.yaml` doit être documentée. La chaîne de documentation doit commencer par le nom de la propriété qu'elle décrit, puis fournir au moins une phrase de description. + +Incorrect : + +```yaml +# le nom d'hôte pour le serveur web +serverHost: example +serverPort: 9191 +``` + +Correct : + +```yaml +# serverHost est le nom d'hôte pour le serveur web +serverHost: example +# serverPort est le port d'écoute HTTP pour le serveur web +serverPort: 9191 +``` + +Commencer chaque commentaire par le nom du paramètre qu'il documente facilite la recherche de la documentation avec des outils comme `grep`, et permettra aux outils de documentation de corréler de manière fiable les chaînes de documentation avec les paramètres qu'ils décrivent. From 226010d143544bccc13701ac03f54d554fbb7693 Mon Sep 17 00:00:00 2001 From: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Thu, 22 Aug 2024 16:32:23 +0200 Subject: [PATCH 02/15] Translate part 'How-to' in french Signed-off-by: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- .../fr/docs/howto/chart_releaser_action.md | 81 ++++++ .../howto/chart_repository_sync_example.md | 84 +++++++ .../fr/docs/howto/charts_tips_and_tricks.md | 232 ++++++++++++++++++ 3 files changed, 397 insertions(+) create mode 100644 content/fr/docs/howto/chart_releaser_action.md create mode 100644 content/fr/docs/howto/chart_repository_sync_example.md create mode 100644 content/fr/docs/howto/charts_tips_and_tricks.md diff --git a/content/fr/docs/howto/chart_releaser_action.md b/content/fr/docs/howto/chart_releaser_action.md new file mode 100644 index 000000000..b853515ec --- /dev/null +++ b/content/fr/docs/howto/chart_releaser_action.md @@ -0,0 +1,81 @@ +--- +title: "Action Chart Releaser pour automatiser les charts via GitHub pages" +description: "Décrit comment utiliser l'action Chart Releaser pour automatiser la publication de charts via GitHub pages." +weight: 3 +--- + +Ce guide décrit comment utiliser l'[Action Chart Releaser](https://github.com/marketplace/actions/helm-chart-releaser) pour automatiser la publication de charts via GitHub. L'Action Chart Releaser est un workflow GitHub Action qui transforme un projet GitHub en un dépôt de charts Helm auto-hébergé, en utilisant l'outil CLI [helm/chart-releaser](https://github.com/helm/chart-releaser). + +## Modifications du dépôt + +Créez un dépôt Git dans votre organisation GitHub. Vous pouvez nommer le dépôt `helm-charts`, bien que d'autres noms soient également acceptables. Les sources de tous les charts peuvent être placées sous la branche `main`. Les charts doivent être placés sous le dossier `/charts` à la racine de l'arborescence des répertoires. + +Il doit y avoir une autre branche nommée `gh-pages` pour publier les charts. Les modifications apportées à cette branche seront automatiquement créées par l'Action Chart Releaser décrite ici. Cependant, vous pouvez créer cette branche `gh-pages` et ajouter un fichier `README.md`, qui sera visible par les utilisateurs visitant la page. + +Vous pouvez ajouter des instructions dans le `README.md` pour l'installation des charts comme ceci. +(remplacez ``, ``, et ``): + +``` +## Utilisation + +[Helm](https://helm.sh) doit être installé pour utiliser les charts. +Référez-vous à la [documentation Helm](https://helm.sh/docs) pour commencer. + +Une fois Helm à correctement été configuré, ajoutez le dépôt comme suit : + + helm repo add https://.github.io/helm-charts + +Si vous avez déjà ajouté ce dépôt précédemment, exécutez la commande `helm repo update` pour recevoir les dernières versions des packages. Vous pouvez également exécuter la commande `helm search repo ` pour consulter les charts. + +Pour installer le chart : + + helm install my- / + +Pour désinstaller le chart : + + helm delete my- +``` + +Les charts seront publiés sur un site web avec une URL comme celle-ci : + + https://.github.io/helm-charts + +## Workflow GitHub Actions + +Créez un fichier de workflow GitHub Actions dans la branche `main` à l'emplacement `.github/workflows/release.yml` + +``` +name: Release Charts + +on: + push: + branches: + - main + +jobs: + release: + permissions: + contents: write + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + with: + fetch-depth: 0 + + - name: Configure Git + run: | + git config user.name "$GITHUB_ACTOR" + git config user.email "$GITHUB_ACTOR@users.noreply.github.com" + + - name: Run chart-releaser + uses: helm/chart-releaser-action@v1.6.0 + env: + CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" +``` + +La configuration ci-dessus utilise [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) pour transformer votre projet GitHub en un dépôt de charts Helm auto-hébergé. Cela se fait - à chaque push vers `main` - en vérifiant chaque chart dans votre projet, et chaque fois qu'il y a une nouvelle version de chart, elle crée une release GitHub correspondante nommée selon la version du chart, ajoute les artefacts de chart Helm à la release, et crée ou met à jour un fichier `index.yaml` avec les métadonnées sur ces releases, qui est ensuite hébergé sur GitHub Pages. + +Le numéro de version de l'Action Chart Releaser utilisé dans l'exemple ci-dessus est `v1.6.0`. Vous pouvez le changer pour la [dernière version disponible](https://github.com/helm/chart-releaser-action/releases). + +Remarque : L'Action Chart Releaser est presque toujours utilisée en tandem avec l'[Action Helm Testing](https://github.com/marketplace/actions/helm-chart-testing) et l'[Action Kind](https://github.com/marketplace/actions/kind-cluster). diff --git a/content/fr/docs/howto/chart_repository_sync_example.md b/content/fr/docs/howto/chart_repository_sync_example.md new file mode 100644 index 000000000..b9dcf027c --- /dev/null +++ b/content/fr/docs/howto/chart_repository_sync_example.md @@ -0,0 +1,84 @@ +--- +title: "Syncroniser votre dépôt de charts" +description: "Décrit comment synchroniser vos dépôts de charts locaux et distants." +weight: 2 +--- + +*Remarque : Cet exemple concerne spécifiquement un bucket Google Cloud Storage (GCS) qui sert de dépôt de charts.* + +## Prérequis +* Installer l'outil [gsutil](https://cloud.google.com/storage/docs/gsutil). *Nous nous appuyons fortement sur la fonctionnalité gsutil rsync* +* Assurez-vous d'avoir accès au binaire Helm +* _Optionnel : Nous vous recommandons de définir l'[object + versioning](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) + sur votre bucket GCS au cas où vous supprimeriez accidentellement quelque chose._ + +## Mise en place d'un dépôt de charts local +Créez un dépôt local, comme nous l'avons fait dans [le guide du dépôt de charts]({{< ref "/fr/docs/topics/chart_repository.md" >}}), et placez-y vos charts packagés. + +Pour exemple : +```console +$ mkdir fantastic-charts +$ mv alpine-0.1.0.tgz fantastic-charts/ +``` + +## Générer un index.yaml à jour +Utilisez Helm pour générer un fichier `index.yaml` à jour en passant le chemin du répertoire et l'URL du dépôt distant à la commande `helm repo index` comme ceci : + +```console +$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com +``` +Cela va générer un fichier index.yaml actualisé et le placer dans le dossier `fantastic-charts/`. + +## Synchroniser votre dépôt local et distant +Téléversez le contenu du dossier local, dans votre bucket GCS en exécutant `scripts/sync-repo.sh` et en passant le nom du dossier local et le nom du bucket GCS. + +Pour exemple : +```console +$ pwd +/Users/me/code/go/src/helm.sh/helm +$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts +Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts +Verifying Prerequisites.... +Thumbs up! Looks like you have gsutil. Let's continue. +Building synchronization state... +Starting synchronization +Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz +Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml +Are you sure you would like to continue with these changes?? [y/N]} y +Building synchronization state... +Starting synchronization +Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... +Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B +Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... +Uploading gs://fantastic-charts/index.yaml: 347 B/347 B +Congratulations your remote chart repository now matches the contents of fantastic-charts/ +``` + +## Mettre à jour votre dépôt de chart +Vous voudrez garder une copie locale du contenu de votre dépôt de charts ou utiliser `gsutil rsync` pour copier le contenu de votre dépôt de charts distant vers un répertoire local. + +Pour exemple : +```console +$ gsutil rsync -d -n gs://bucket-name local-dir/ # l'argument -n fait un essai à blanc +Building synchronization state... +Starting synchronization +Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz +Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml + +$ gsutil rsync -d gs://bucket-name local-dir/ # effectue les actions de copie +Building synchronization state... +Starting synchronization +Copying gs://bucket-name/alpine-0.1.0.tgz... +Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B +Copying gs://bucket-name/index.yaml... +Downloading file://local-dir/index.yaml: 346 B/346 B +``` + +Liens utiles : +* Documentation sur [gsutil + rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) +* [Guide du dépôt de chart]({{< ref "/docs/topics/chart_repository.md" >}}) +* Documentation sur [object versioning and concurrency + control](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) + sur Google Cloud Storage diff --git a/content/fr/docs/howto/charts_tips_and_tricks.md b/content/fr/docs/howto/charts_tips_and_tricks.md new file mode 100644 index 000000000..485126c99 --- /dev/null +++ b/content/fr/docs/howto/charts_tips_and_tricks.md @@ -0,0 +1,232 @@ +--- +title: "Trucs et astuces pour le développement de charts" +description: "Couvre certains des trucs et astuces que les développeurs de charts Helm ont appris en construisant des charts de qualité pour la production." +weight: 1 +--- + +Couvre certains des trucs et astuces que les développeurs de charts Helm ont appris en construisant des charts de qualité pour la production. + +## Connaitre les Fonctions de Template + +Helm utilise les [templates Go](https://godoc.org/text/template) pour le templating de vos fichiers de ressources. Bien que Go propose plusieurs fonctions intégrées, nous en avons ajouté beaucoup d'autres. + +Tout d'abord, nous avons ajouté toutes les fonctions de la [bibliothèque Sprig](https://masterminds.github.io/sprig/), à l'exception de `env` et `expandenv`, pour des raisons de sécurité. + +Nous avons également ajouté deux fonctions de template spéciales : `include` et `required`. La fonction `include` vous permet d'incorporer un autre template, puis de passer les résultats à d'autres fonctions de template. + +Par exemple, cet extrait de template inclut un template appelé `mytpl`, puis met le résultat en minuscules et l'entoure de guillemets doubles : + +```yaml +value: {{ include "mytpl" . | lower | quote }} +``` + +La fonction `required` vous permet de déclarer qu'une entrée de valeurs particulière est obligatoire pour le rendu du template. Si la valeur est vide, le rendu du template échouera et affichera un message d'erreur soumis par l'utilisateur. + +L'exemple suivant de la fonction `required` qui déclare que l'entrée pour `.Values.who` est obligatoire et affichera un message d'erreur si cette entrée est manquante : + +```yaml +value: {{ required "La valeur .Values.who est requise !" .Values.who }} +``` + +## Citez les chaînes de caractères, pas les entiers + +Lorsque vous travaillez avec des données de type chaîne de caractères, il est toujours plus sûr de citer (`".."`) les chaînes de caractères plutôt que de les laisser sous forme de mots nus : + +```yaml +name: {{ .Values.MyName | quote }} +``` + +Mais lorsqu'il s'agit de travailler avec des entiers, _ne citez pas les valeurs._ Cela peut, dans de nombreux cas, provoquer des erreurs d'analyse au sein de Kubernetes. + +```yaml +port: {{ .Values.Port }} +``` + +Cette remarque ne s'applique pas aux valeurs des variables d'environnement qui sont attendues sous forme de chaînes de caractères, même si elles représentent des entiers : + +```yaml +env: + - name: HOST + value: "http://host" + - name: PORT + value: "1234" +``` + +## Utilisation de la fonction 'include' + +Go fournit un moyen d'inclure un modèle dans un autre en utilisant une directive intégrée `template`. Cependant, la fonction intégrée ne peut pas être utilisée dans les pipelines de modèles Go. + +Pour rendre possible l'inclusion d'un modèle, puis effectuer une opération sur la sortie de ce modèle, Helm dispose d'une fonction spéciale `include` : + +``` +{{ include "toYaml" $value | indent 2 }} +``` + +L'exemple ci-dessus, inclut un modèle appelé `toYaml`, lui passe `$value`, puis transmet la sortie de ce modèle à la fonction `indent`. + +Étant donné que YAML accorde de l'importance aux niveaux d'indentation et aux espaces, c'est une excellente manière d'inclure des extraits de code tout en gérant l'indentation dans un contexte pertinent. + +## Utilisation de la fonction 'required' + +Go fournit un moyen de définir des options de modèle pour contrôler le comportement lorsqu'un mapping est indexée avec une clé qui n'est pas présente dans le mapping. Cela se règle généralement avec `template.Options("missingkey=option")`, où `option` peut être `default`, `zero`, ou `error`. Tandis que le paramètre `error` arrête l'exécution en cas d'erreur, cela s'appliquerait à chaque clé manquante dans le mapping. Il peut y avoir des situations où un développeur de chart souhaite imposer ce comportement pour certaines valeurs dans le fichier `values.yaml`. + +La fonction `required` permet aux développeurs de déclarer une entrée de valeur comme obligatoire pour le rendu du modèle. Si l'entrée est vide dans `values.yaml`, le modèle ne sera pas rendu et renverra un message d'erreur fourni par le développeur. + +Pour exemple : + +``` +{{ required "Une valeur pour foo est obligatoire !" .Values.foo }} +``` + +L'exemple ci-dessus, rendra le modèle lorsque `.Values.foo` est défini, mais échouera à rendre le modèle et se terminera lorsque `.Values.foo` est indéfini. + +## Utilisation de la fonction 'tpl' + +La fonction `tpl` permet aux développeurs d'évaluer des chaînes de caractères comme des modèles à l'intérieur d'un modèle. Cela est utile pour passer une chaîne de modèle comme valeur à un chart ou pour rendre des fichiers de configuration externes. Syntaxe : `{{ tpl TEMPLATE_STRING VALUES }}` + +Exemples : + +```yaml +# values +template: "{{ .Values.name }}" +name: "Benjamin" + +# template +{{ tpl .Values.template . }} + +# output +Benjamin +``` + +Rendu d'un fichier de configuration externe : + +```yaml +# external configuration file conf/app.conf +firstName={{ .Values.firstName }} +lastName={{ .Values.lastName }} + +# values +firstName: Peter +lastName: Parker + +# template +{{ tpl (.Files.Get "conf/app.conf") . }} + +# output +firstName=Peter +lastName=Parker +``` + +## Création de Secrets de récupération d'images +Les secrets de récupération d'image (Image Pull Secrets) sont essentiellement une combinaison de _registry_, _username_, et _password_. Vous pourriez en avoir besoin dans une application que vous déployez, mais leur création nécessite d'exécuter `base64` plusieurs fois. Nous pouvons écrire un modèle d'assistance pour composer le fichier de configuration Docker à utiliser comme charge utile du Secret. Voici un exemple : + +Tout d'abord, supposons que les informations d'identification sont définies dans le fichier `values.yaml` comme suit : +```yaml +imageCredentials: + registry: quay.io + username: someone + password: sillyness + email: someone@host.com +``` + +Nous définissons ensuite notre modèle d'assistance comme suit : +``` +{{- define "imagePullSecret" }} +{{- with .Values.imageCredentials }} +{{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":\"%s\",\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username .password .email (printf "%s:%s" .username .password | b64enc) | b64enc }} +{{- end }} +{{- end }} +``` + +Enfin, nous utilisons le modèle d'assistance dans un modèle plus large pour créer le manifeste du Secret : +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: myregistrykey +type: kubernetes.io/dockerconfigjson +data: + .dockerconfigjson: {{ template "imagePullSecret" . }} +``` + +## Déploiements automatiques + +Souvent, les ConfigMaps ou Secrets sont injectés comme fichiers de configuration dans les conteneurs, ou il y a d'autres modifications de dépendances externes qui nécessitent un roulage des pods. Selon l'application, un redémarrage peut être nécessaire si ces éléments sont mis à jour avec un `helm upgrade` ultérieur. Cependant, si la spec de déploiement elle-même n'a pas changée, l'application continue de fonctionner avec l'ancienne configuration, entraînant un déploiement incohérent. + +La fonction `sha256sum` peut être utilisée pour garantir que la section des annotations d'un déploiement est mise à jour si un autre fichier change : + +```yaml +kind: Deployment +spec: + template: + metadata: + annotations: + checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} +[...] +``` + +REMARQUE : Si vous ajoutez cela à un chart librairie vous ne pourrez pas accéder à votre fichier dans `$.Template.BasePath`. Vous pouvez plutôt référencer votre définition avec `{{ include ("mylibchart.configmap") . | sha256sum }}`. + +Dans le cas où vous souhaitez toujours effectuer un roulage de votre déploiement, vous pouvez utiliser une étape d'annotation similaire à celle mentionnée ci-dessus, mais en la remplaçant par une chaîne aléatoire pour qu'elle change toujours et entraîne le roulage du déploiement : + +```yaml +kind: Deployment +spec: + template: + metadata: + annotations: + rollme: {{ randAlphaNum 5 | quote }} +[...] +``` + +Chaque appel de la fonction de modèle générera une chaîne aléatoire unique. Cela signifie que si vous devez synchroniser les chaînes aléatoires utilisées par plusieurs ressources, toutes les ressources pertinentes devront être dans le même fichier de modèle. + +Ces deux méthodes permettent à votre Déploiement de tirer parti de la logique de stratégie de mise à jour intégrée pour éviter les temps d'arrêt. + +REMARQUE : Par le passé, nous recommandions l'utilisation de l'argument `--recreate-pods` comme autre option. Cet argument a été marqué comme obsolète dans Helm 3 au profit de la méthode plus déclarative mentionnée ci-dessus. + +## Indiquez à Helm de ne pas désinstaller une ressource + +Parfois, certaines ressources ne doivent pas être désinstallées lorsque Helm exécute un `helm uninstall`. Les développeurs de chart peuvent ajouter une annotation à leurs ressources pour éviter leurs désinstallations. + +```yaml +kind: Secret +metadata: + annotations: + helm.sh/resource-policy: keep +[...] +``` + +L'annotation `helm.sh/resource-policy: keep` indique à Helm de ne pas supprimer cette ressource lorsqu'une opération Helm (comme `helm uninstall`, `helm upgrade` ou `helm rollback`) entraînerait sa suppression. _Cependant_, cette ressource devient orpheline. Helm ne la gérera plus de quelque manière que ce soit. Cela peut entraîner des problèmes si vous utilisez `helm install --replace` sur une release qui a déjà été désinstallée, mais qui a conservé des ressources. + +## Utilisation des "Partiels" et des Inclusion de Modèles + +Parfois, vous souhaitez créer des parties réutilisables dans votre chart, qu'il s'agisse de blocs ou de modèles partiels. Il est souvent plus propre de les garder dans leurs propres fichiers. + +Dans le répertoire `templates/`, tout fichier commençant par un underscore (`_`) n'est pas censé produire un fichier manifeste Kubernetes. Par conséquent, par convention, les modèles d'assistance et les partiels sont placés dans un fichier `_helpers.tpl`. + +## Charts complexes avec de nombreuses dépendances + +Beaucoup de charts sur le [Artifact Hub](https://artifacthub.io/packages/search?kind=0) de la CNCF sont des "blocs de construction" pour créer des applications plus avancées. Mais les charts peuvent aussi être utilisés pour créer des instances d'applications à grande échelle. Dans ces cas, un chart "parapluie" unique peut avoir plusieurs sous-charts, chacun fonctionnant comme une partie de l'ensemble. + +La meilleure pratique actuelle pour composer une application complexe à partir de parties distinctes est de créer un chart "parapluie" de niveau supérieur qui expose les configurations globales, puis d'utiliser le sous-répertoire `charts/` pour intégrer chacun des composants.* + +## YAML est un sur-ensemble de JSON + +Selon la spécification YAML, YAML est un sur-ensemble de JSON. Cela signifie que toute structure JSON valide devrait également être valide en YAML. + +Cela présente un avantage : il arrive que les développeurs de modèles trouvent plus facile d'exprimer une structure de données avec une syntaxe semblable à JSON plutôt que de gérer la sensibilité aux espaces de YAML. + +En tant que bonne pratique, les modèles doivent suivre une syntaxe semblable à YAML _à moins que_ la syntaxe JSON ne réduise considérablement le risque de problème de formatage. + +## Soyez vigilant avec la génération de valeurs aléatoires + +Il existe des fonctions dans Helm qui vous permettent de générer des données aléatoires, des clés cryptographiques, etc. Ces fonctions sont utiles. Cependant, soyez conscient qu'au cours des mises à jour, les modèles sont réexécutés. Lorsque l'exécution d'un modèle génère des données différentes de celles de l'exécution précédente, cela déclenchera une mise à jour de cette ressource. + +## Installer ou mettre à jour une release avec une seule commande + +Helm offre un moyen d'effectuer une installation ou une mise à jour en une seule commande. Utilisez `helm upgrade` avec l'option `--install`. Cela amène Helm à vérifier si la release est déjà installée. Si ce n'est pas le cas, il effectuera une installation. Si elle l'est, la release existante sera mise à jour. + +```console +$ helm upgrade --install --values +``` From 8ca367cd296f10136a063a0725dfb0e1646a6bb4 Mon Sep 17 00:00:00 2001 From: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Fri, 23 Aug 2024 13:18:28 +0200 Subject: [PATCH 03/15] Translate part 'faq' in french Signed-off-by: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- content/fr/docs/faq/_index.md | 16 ++ content/fr/docs/faq/changes_since_helm2.md | 278 +++++++++++++++++++++ content/fr/docs/faq/installing.md | 27 ++ content/fr/docs/faq/troubleshooting.md | 134 ++++++++++ content/fr/docs/faq/uninstalling.md | 22 ++ 5 files changed, 477 insertions(+) create mode 100644 content/fr/docs/faq/_index.md create mode 100644 content/fr/docs/faq/changes_since_helm2.md create mode 100644 content/fr/docs/faq/installing.md create mode 100644 content/fr/docs/faq/troubleshooting.md create mode 100644 content/fr/docs/faq/uninstalling.md diff --git a/content/fr/docs/faq/_index.md b/content/fr/docs/faq/_index.md new file mode 100644 index 000000000..4397fe2b8 --- /dev/null +++ b/content/fr/docs/faq/_index.md @@ -0,0 +1,16 @@ +--- +title: "Foire Aux Questions" +weight: 8 +aliases: [ + "/fr/docs/topics/faq/", + "/fr/docs/faq/" +] +--- + +# Foire Aux Questions + +> Cette section fournit de l'aide pour les questions les plus courantes. + +**Nous serions ravis de votre aide** pour améliorer ce document. Pour ajouter, corriger ou supprimer des informations, [signalez un problème](https://github.com/helm/helm-www/issues) ou envoyez-nous une pull request. + + diff --git a/content/fr/docs/faq/changes_since_helm2.md b/content/fr/docs/faq/changes_since_helm2.md new file mode 100644 index 000000000..505d00fb8 --- /dev/null +++ b/content/fr/docs/faq/changes_since_helm2.md @@ -0,0 +1,278 @@ +--- +title: "Changements depuis Helm 2" +weight: 1 +--- + +## Changements depuis Helm 2 + +Voici la liste exhaustive de tous les principaux changements introduits dans Helm 3. + +### Suppression de Tiller + +Pendant le cycle de développement de Helm 2, nous avons introduit Tiller. Tiller jouait un rôle important pour les équipes travaillant sur un cluster partagé - il permettait à plusieurs opérateurs différents d'interagir avec le même ensemble de releases. + +Avec le contrôle d'accès basé sur les rôles (RBAC) activé par défaut dans Kubernetes 1.6, la sécurisation de Tiller pour une utilisation en production est devenue plus difficile à gérer. En raison du grand nombre de politiques de sécurité possibles, notre position était de fournir une configuration par défaut permissive. Cela permettait aux utilisateurs novices de commencer à expérimenter avec Helm et Kubernetes sans avoir à plonger immédiatement dans les contrôles de sécurité. Malheureusement, cette configuration permissive pouvait accorder à un utilisateur un large éventail de permissions qu'il n'était pas censé avoir. Les équipes DevOps et SRE devaient apprendre des étapes opérationnelles supplémentaires lors de l'installation de Tiller dans un cluster multi-tenant. + +Après avoir entendu comment les membres de la communauté utilisaient Helm dans certains scénarios, nous avons constaté que le système de gestion des releases de Tiller n'avait pas besoin de s'appuyer sur un opérateur interne au cluster pour maintenir l'état ou agir comme un centre central pour les informations sur les releases de Helm. Au lieu de cela, nous pouvions simplement récupérer les informations depuis l'API serveur Kubernetes, rendre les Charts côté client et stocker un enregistrement de l'installation dans Kubernetes. + +L'objectif principal de Tiller pouvait être accompli sans Tiller, donc l'une des premières décisions que nous avons prises concernant Helm 3 a été de supprimer complètement Tiller. + +Avec la disparition de Tiller, le modèle de sécurité de Helm est radicalement simplifié. Helm 3 prend désormais en charge toutes les fonctionnalités modernes de sécurité, d'identité et d'autorisation de Kubernetes. Les permissions de Helm sont évaluées à l'aide de votre [fichier kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Les administrateurs de cluster peuvent restreindre les permissions des utilisateurs avec la granularité qu'ils jugent appropriée. Les releases sont toujours enregistrées dans le cluster, et le reste des fonctionnalités de Helm demeure. + +### Amélioration de la stratégie de mise à niveau : 3 voies pour la stratégie de fusion + +Helm 2 utilisait un patch de fusion stratégique à deux voies. Lors d'une mise à niveau, il comparait le manifeste du chart le plus récent avec celui du chart proposé (celui fourni lors de `helm upgrade`). Il comparait les différences entre ces deux charts pour déterminer les modifications à appliquer aux ressources dans Kubernetes. Si des modifications étaient apportées au cluster en dehors de Helm (comme lors d'un `kubectl edit`), ces changements n'étaient pas pris en compte. Cela entraînait des difficultés pour revenir à un état antérieur : puisque Helm considérait uniquement le manifeste du dernier chart appliqué comme l'état actuel, si l'état du chart n'avait pas changé, l'état en direct restait inchangé. + +Dans Helm 3, nous utilisons désormais un patch de fusion stratégique à trois voies. Helm prend en compte l'ancien manifeste, son état en direct, et le nouveau manifeste lors de la génération d'un patch. + +#### Exemples + +Voyons quelques exemples courants de l'impact de ce changement. + +##### Revenir en arrière lorsque l'état en direct a changé + +Votre équipe vient de déployer son application en production sur Kubernetes en utilisant Helm. Le chart contient un objet Deployment où le nombre de réplicas est défini sur trois : + +```console +$ helm install myapp ./myapp +``` + +Un nouveau développeur rejoint l'équipe. Le premier jour, en observant le cluster de production, un horrible accident de café renversé sur le clavier se produit et il utilise la commande `kubectl scale` pour réduire le déploiement de production de trois réplicas à zéro. + +```console +$ kubectl scale --replicas=0 deployment/myapp +``` + +Un autre développeur de votre équipe remarque que le site de production est hors service et décide de revenir à l'état précédent de la release : + +```console +$ helm rollback myapp +``` + +Que se passe-t-il ? + +Dans Helm 2, cela générerait un patch en comparant le manifeste ancien avec le nouveau manifeste. Étant donné qu'il s'agit d'un rollback, le manifeste est le même. Helm déterminerait qu'il n'y a rien à changer puisque le manifeste ancien et le nouveau sont identiques. Le nombre de réplicas resterait donc à zéro. La panique s'ensuit. + +Dans Helm 3, le patch est généré en utilisant le manifeste ancien, l'état actuel et le nouveau manifeste. Helm reconnaît que l'état ancien était à trois, l'état actuel est à zéro, et le nouveau manifeste souhaite le ramener à trois. Ainsi, Helm génère un patch pour rétablir l'état à trois. + +##### Mise à jour où l'état actuel a changé + +De nombreux maillages de services et autres applications basées sur des contrôleurs injectent des données dans les objets Kubernetes. Cela peut être quelque chose comme un sidecar, des labels ou d'autres informations. Auparavant, si vous aviez le manifeste donné rendu à partir d'un Chart : + +```yaml +containers: +- name: server + image: nginx:2.0.0 +``` + +Et que son état actuel à été modifié par une autre application pour : + +```yaml +containers: +- name: server + image: nginx:2.0.0 +- name: my-injected-sidecar + image: my-cool-mesh:1.0.0 +``` + +Maintenant, vous souhaitez mettre à jour le tag de l'image `nginx` à `2.1.0`. Vous procédez donc à une mise à jour avec un chart contenant le manifeste suivant : + +```yaml +containers: +- name: server + image: nginx:2.1.0 +``` + +Que se passe-t-il ? + +Dans Helm 2, Helm génère un patch de l'objet `containers` entre le manifeste ancien et le nouveau manifeste. L'état actuel du cluster n'est pas pris en compte lors de la génération du patch. + +L'état actuel du cluster est modifié pour ressembler à ce qui suit : + +```yaml +containers: +- name: server + image: nginx:2.1.0 +``` + +Le sidecar du pod a été supprimé de l'état actuel. Encore plus de panique s'ensuit. + +Dans Helm 3, Helm génère un patch de l'objet `containers` en utilisant le manifeste ancien, l'état actuel et le nouveau manifeste. Il remarque que le nouveau manifeste change le tag de l'image à `2.1.0`, mais que l'état actuel contient un conteneur sidecar. + +L'état actuel du cluster est modifié pour ressembler à ce qui suit : + +```yaml +containers: +- name: server + image: nginx:2.1.0 +- name: my-injected-sidecar + image: my-cool-mesh:1.0.0 +``` + +### Les noms de release sont désormais limités à l'espace de noms (Namespace) + +Avec la suppression de Tiller, les informations sur chaque release devaient être stockées ailleurs. Dans Helm 2, cela était conservé dans le même espace de noms que Tiller. En pratique, cela signifiait qu'une fois qu'un nom était utilisé par une release, aucune autre release ne pouvait utiliser ce même nom, même si elle était déployée dans un espace de noms différent. + +Dans Helm 3, les informations sur une release particulière sont désormais stockées dans le même espace de noms que la release elle-même. Cela signifie que les utilisateurs peuvent maintenant `helm install wordpress stable/wordpress` dans deux espaces de noms distincts, et chacune peut être consultée avec `helm list` en changeant le contexte de l'espace de noms actuel (par exemple, `helm list --namespace foo`). + +Avec ce meilleur alignement aux espaces de noms natifs du cluster, la commande `helm list` ne liste plus toutes les releases par défaut. Au lieu de cela, elle ne liste que les releases dans l'espace de noms de votre contexte Kubernetes actuel (c'est-à-dire l'espace de noms affiché lorsque vous exécutez `kubectl config view --minify`). Cela signifie également que vous devez fournir l'option `--all-namespaces` à `helm list` pour obtenir un comportement similaire à celui de Helm 2. + +### Secret comme pilote de stockage par défaut + +Dans Helm 3, les Secrets sont désormais utilisés comme [pilote de stockage par défaut](/docs/topics/advanced/#storage-backends). Helm 2 utilisait des ConfigMaps par défaut pour stocker les informations de release. Dans Helm 2.7.0, un nouveau backend de stockage utilisant des Secrets pour conserver les informations de release a été implémenté, et il est désormais le pilote de stockage par défaut à partir de Helm 3. + +Le passage aux Secrets par défaut dans Helm 3 permet une sécurité accrue pour protéger les charts en conjonction avec la fonctionnalité de chiffrement des Secrets dans Kubernetes. + +[Le chiffrement des secrets at-rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) est devenu disponible en tant que fonctionnalité alpha dans Kubernetes 1.7 et est devenu stable à partir de Kubernetes 1.13. Cela permet aux utilisateurs de chiffrer les métadonnées des releases Helm at-rest et constitue donc un bon point de départ qui peut être étendu ultérieurement vers l'utilisation de solutions telles que Vault. + +### Changements dans le chemin d'importation Go + +Dans Helm 3, Helm a modifié le chemin d'importation Go de `k8s.io/helm` à `helm.sh/helm/v3`. Si vous prévoyez de mettre à niveau vers les bibliothèques clientes Go de Helm 3, assurez-vous de modifier vos chemins d'importation. + +### Capacités + +L'objet intégré `.Capabilities`, disponible durant la phase de rendu, a été simplifié. + +[Built-in Objects](/docs/chart_template_guide/builtin_objects/) + +### Validation des valeurs de Chart avec JSONSchema + +Un schéma JSON peut désormais être imposé sur les valeurs de chart. Cela garantit que les valeurs fournies par l'utilisateur respectent le schéma défini par le mainteneur du chart, offrant ainsi de meilleurs rapports d'erreurs lorsque l'utilisateur fournit un ensemble incorrect de valeurs pour un chart. + +La validation a lieu lorsque l'une des commandes suivantes est invoquée : + +* `helm install` +* `helm upgrade` +* `helm template` +* `helm lint` + +Consultez la documentation sur les [fichiers de schéma](fr/docs/topics/charts#schema-files) pour plus d'informations. + +### Remplacement de `requirements.yaml` en `Chart.yaml` + +Le système de gestion des dépendances des charts est passé de `requirements.yaml` et `requirements.lock` à `Chart.yaml` et `Chart.lock`. Nous recommandons que les nouveaux charts destinés à Helm 3 utilisent le nouveau format. Cependant, Helm 3 comprend toujours la version 1 de l'API des charts (`v1`) et chargera les fichiers `requirements.yaml` existants. + +Dans Helm 2, voici à quoi ressemblait un `requirements.yaml` : + +```yaml +dependencies: +- name: mariadb + version: 5.x.x + repository: https://charts.helm.sh/stable + condition: mariadb.enabled + tags: + - database +``` + +Dans Helm 3, la dépendance est exprimée de la même manière, mais maintenant dans votre `Chart.yaml` : + +```yaml +dependencies: +- name: mariadb + version: 5.x.x + repository: https://charts.helm.sh/stable + condition: mariadb.enabled + tags: + - database +``` + +Les charts sont toujours téléchargés et placés dans le répertoire `charts/`, donc les sous-chart inclus dans le répertoire `charts/` continueront à fonctionner sans modification. + +### Le nom (ou le `--generate-name`) est désormais requis lors de l'installation + +Dans Helm 2, si aucun nom n'était fourni, un nom généré automatiquement était attribué. En production, cela s'est révélé plus gênant qu'utile. Dans Helm 3, Helm renverra une erreur si aucun nom n'est fourni avec `helm install`. + +Pour ceux qui souhaitent toujours qu'un nom soit généré automatiquement, vous pouvez utiliser l'option `--generate-name` pour en créer un pour vous. + +### Publication de Charts dans les registres OCI + +Il s'agit d'une fonctionnalité expérimentale introduite dans Helm 3. Pour l'utiliser, définissez la variable d'environnement `HELM_EXPERIMENTAL_OCI=1`. + +À un niveau élevé, un dépôt de Charts est un emplacement où les Charts peuvent être stockés et partagés. Le client Helm empaquette et expédie les Charts Helm vers un dépôt de Charts. En termes simples, un dépôt de Charts est un serveur HTTP basique qui héberge un fichier `index.yaml` et quelques charts empaquetés. + +Bien qu'il y ait plusieurs avantages à ce que l'API des dépôts de Charts réponde aux exigences de stockage les plus élémentaires, quelques inconvénients ont commencé à apparaître : + +- Les dépôts de Charts ont beaucoup de mal à abstraire la plupart des implémentations de sécurité nécessaires dans un environnement de production. Avoir une API standard pour l'authentification et l'autorisation est très important dans les scénarios de production. +- Les outils de provenance des Charts de Helm, utilisés pour signer et vérifier l'intégrité et l'origine d'un chart, sont un élément facultatif du processus de publication des Charts. +- Dans les scénarios multi-tenant, le même Chart peut être téléchargé par un autre tenant, ce qui double le coût de stockage pour le même contenu. Des dépôts de charts plus intelligents ont été conçus pour gérer cela, mais ce n'est pas partie de la spécification formelle. +- L'utilisation d'un seul fichier d'index pour la recherche, les informations de métadonnées et la récupération des Charts a rendu difficile ou maladroit la conception autour de cela dans les implémentations sécurisées multi-tenant. + +Le projet Distribution de Docker (également connu sous le nom de Docker Registry v2) est le successeur du projet Docker Registry. De nombreux grands fournisseurs de cloud proposent une offre basée sur le projet Distribution, et avec autant de fournisseurs offrant le même produit, le projet Distribution a bénéficié de nombreuses années de renforcement, de meilleures pratiques en matière de sécurité et de tests en conditions réelles. + +Veuillez consulter `helm help chart` et `helm help registry` pour plus d'informations sur la manière d'empaqueter un chart et de le publier dans un registre Docker. + +Pour plus d'information, consultez [cette page](/fr/docs/topics/registries/). + +### Suppression de `helm serve` + +`helm serve` exécutait un dépôt de Charts local sur votre machine à des fins de développement. Cependant, il n'a pas beaucoup été utilisé en tant qu'outil de développement et avait de nombreux problèmes de conception. En fin de compte, nous avons décidé de le supprimer et de le séparer en tant que plugin. + +Pour une expérience similaire à `helm serve`, consultez l'option de stockage sur le système de fichiers local dans [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) et le [plugin servecm](https://github.com/jdolitsky/helm-servecm). + + +### Support des charts librairie + +Helm 3 prend en charge une catégorie de charts appelée « chart librairie». Il s'agit d'un chart partagé par d'autres charts, mais qui ne crée aucun artefact de release propre. Les templates d'un chart de bibliothèque ne peuvent déclarer que des éléments `define`. Le contenu non `define` à portée globale est simplement ignoré. Cela permet aux utilisateurs de réutiliser et de partager des extraits de code pouvant être utilisés dans de nombreux charts, évitant ainsi la redondance et maintenant les charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). + +Les charts librairie sont déclarés dans la directive des dépendances dans `Chart.yaml`, et sont installés et gérés comme tout autre chart. + +```yaml +dependencies: + - name: mylib + version: 1.x.x + repository: quay.io +``` + +Nous sommes très enthousiastes de voir les cas d'utilisation que cette fonctionnalité ouvre pour les développeurs de charts, ainsi que les meilleures pratiques qui émergeront de l'utilisation des charts de bibliothèque. + +### Mise à jour de l'apiVersion dans Charts.yaml + +Avec l'introduction du support des charts de bibliothèque et la consolidation de `requirements.yaml` dans `Chart.yaml`, les clients qui comprenaient le format de package de Helm 2 ne comprendront pas ces nouvelles fonctionnalités. Nous avons donc augmenté la version de l'API dans `Chart.yaml` de `v1` à `v2`. + +`helm create` crée désormais des charts en utilisant ce nouveau format, donc la version de l'API par défaut a également été augmentée. + +Les clients souhaitant prendre en charge les deux versions des charts Helm doivent inspecter le champ `apiVersion` dans `Chart.yaml` pour comprendre comment analyser le format du package. + +### Support des répertoires de base XDG + +[La spécification des répertoires de base XDG](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) est une norme portable définissant où les fichiers de configuration, les données et les fichiers cache doivent être stockés sur le système de fichiers. + +Dans Helm 2, Helm stockait toutes ces informations dans `~/.helm` (affectueusement connu sous le nom de `helm home`), ce qui pouvait être modifié en définissant la variable d'environnement `$HELM_HOME` ou en utilisant l'option globale `--home`. + +Dans Helm 3, Helm respecte désormais les variables d'environnement suivantes conformément à la spécification des répertoires de base XDG : + +- `$XDG_CACHE_HOME` +- `$XDG_CONFIG_HOME` +- `$XDG_DATA_HOME` + +Les plugins Helm reçoivent toujours `$HELM_HOME` comme un alias de `$XDG_DATA_HOME` pour assurer la compatibilité avec les plugins qui utilisent `$HELM_HOME` comme un environnement temporaire. + +Plusieurs nouvelles variables d'environnement sont également passées dans l'environnement du plugin pour s'adapter à ce changement : + +- `$HELM_PATH_CACHE` pour l'emplacement du cache +- `$HELM_PATH_CONFIG` pour l'emplacement de la configuration +- `$HELM_PATH_DATA` pour l'emplacement des données + +Les plugins Helm cherchant à prendre en charge Helm 3 devraient envisager d'utiliser ces nouvelles variables d'environnement à la place. + +### Renommage des commandes CLI + +Afin de mieux s'aligner avec la terminologie utilisée par d'autres gestionnaires de packages, `helm delete` a été renommé en `helm uninstall`. La commande `helm delete` est toujours conservée comme un alias de `helm uninstall`, donc les deux formes peuvent être utilisées. + +Dans Helm 2, pour purger le registre des releases, il fallait fournir l'option `--purge`. Cette fonctionnalité est maintenant activée par défaut. Pour conserver le comportement précédent, utilisez `helm uninstall --keep-history`. + +De plus, plusieurs autres commandes ont été renommées pour s'adapter aux mêmes conventions : + +- `helm inspect` -> `helm show` +- `helm fetch` -> `helm pull` + +Ces commandes ont également conservé leurs anciens verbes en tant qu'alias, vous pouvez donc continuer à les utiliser sous l'une ou l'autre forme. + +### Création automatique de namespaces + +Lors de la création d'une release dans un espace de noms qui n'existe pas, Helm 2 créait l'espace de noms. Helm 3 suit le comportement des autres outils Kubernetes et renvoie une erreur si l'espace de noms n'existe pas. Helm 3 créera l'espace de noms si vous spécifiez explicitement l'option `--create-namespace`. + +### Qu'est devenu `.Chart.ApiVersion` ? + +Helm suit la convention typique du CamelCasing, qui consiste à mettre en majuscule un acronyme. Nous avons appliqué cette règle ailleurs dans le code, par exemple avec `.Capabilities.APIVersions.Has`. Dans Helm v3, nous avons corrigé `.Chart.ApiVersion` pour suivre ce modèle, en le renommant en `.Chart.APIVersion`. + diff --git a/content/fr/docs/faq/installing.md b/content/fr/docs/faq/installing.md new file mode 100644 index 000000000..db2ee3560 --- /dev/null +++ b/content/fr/docs/faq/installing.md @@ -0,0 +1,27 @@ +--- +title: "Installation" +weight: 2 +--- + +## Installation + +### Pourquoi n'y a-t-il pas de packages natifs de Helm pour Fedora et d'autres distributions Linux ? + +Le projet Helm ne maintient pas de packages pour les systèmes d'exploitation et les environnements. La communauté Helm peut fournir des packages natifs et, si le projet Helm en est informé, ils seront listés. C'est ainsi que la formule Homebrew a été créée et répertoriée. Si vous êtes intéressé par la maintenance d'un package, nous serions ravis de vous accueillir. + +### Pourquoi fournissez-vous un script `curl ...|bash` ? + +Il y a un script dans notre dépôt (`scripts/get-helm-3`) qui peut être exécuté en tant que script `curl ..|bash`. Les transferts sont tous protégés par HTTPS, et le script effectue une certaine vérification des packages qu'il récupère. Cependant, le script présente tous les dangers habituels de tout script shell. + +Nous le fournissons parce qu'il est utile, mais nous suggérons aux utilisateurs de lire attentivement le script avant de l'exécuter. Ce que nous aimerions vraiment, cependant, ce sont des versions de Helm mieux packagées. + +### Comment puis-je placer les fichiers du client Helm à un autre endroit que les emplacements par défaut ? + +Helm utilise la structure XDG pour stocker les fichiers. Il existe des variables d'environnement que vous pouvez utiliser pour remplacer ces emplacements : + +- `$XDG_CACHE_HOME` : définir un emplacement alternatif pour stocker les fichiers en cache. +- `$XDG_CONFIG_HOME` : définir un emplacement alternatif pour stocker la configuration de Helm. +- `$XDG_DATA_HOME` : définir un emplacement alternatif pour stocker les données de Helm. + +Notez que si vous avez des dépôts existants, vous devrez les ajouter à nouveau avec `helm repo add...`. + diff --git a/content/fr/docs/faq/troubleshooting.md b/content/fr/docs/faq/troubleshooting.md new file mode 100644 index 000000000..202db0f79 --- /dev/null +++ b/content/fr/docs/faq/troubleshooting.md @@ -0,0 +1,134 @@ +--- +title: "Dépannage" +weight: 4 +--- + +## Dépannage + +### Je reçois un avertissement concernant "Impossible d'obtenir une mise à jour depuis le dépôt de charts 'stable'" + +Exécutez `helm repo list`. S'il indique que votre dépôt `stable` pointe vers une URL `storage.googleapis.com`, vous devrez mettre à jour ce dépôt. Le 13 novembre 2020, le dépôt Helm Charts [est devenu obsolète](https://github.com/helm/charts#deprecation-timeline) après une période de dépréciation d'un an. Un archive est disponible à l'adresse `https://charts.helm.sh/stable`, mais elle ne recevra plus de mises à jour. + +Vous pouvez exécutez la commande suivante pour réparer votre dépôt : + +```console +$ helm repo add stable https://charts.helm.sh/stable --force-update +``` + +Il en va de même pour le dépôt `incubator`, qui dispose d'une archive disponible à l'adresse [https://charts.helm.sh/incubator](https://charts.helm.sh/incubator). Vous pouvez exécuter la commande suivante pour le réparer : + +```console +$ helm repo add incubator https://charts.helm.sh/incubator --force-update +``` + +### Je reçois l'avertissement suivant : 'WARNING: "kubernetes-charts.storage.googleapis.com" est obsolète pour "stable" et sera supprimé le 13 novembre 2020.' + +L'ancien dépôt de charts Helm de Google a été remplacé par un nouveau dépôt de charts Helm. + +Exécutez la commande suivante pour résoudre ce problème de façon permanente : + +```console +$ helm repo add stable https://charts.helm.sh/stable --force-update +``` + +Si vous avez une erreur similaire pour `incubator`, utilisez cette commande : + +```console +$ helm repo add incubator https://charts.helm.sh/incubator --force-update +``` + +### Lorsque j'ajoute un dépôt Helm, j'obtiens l'erreur 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available' + +Les dépôts de charts Helm ne sont plus supportés après [une période de dépréciation d'un an](https://github.com/helm/charts#deprecation-timeline). Les archives de ces dépôts sont disponibles à `https://charts.helm.sh/stable` et `https://charts.helm.sh/incubator`, mais elles ne recevront plus de mises à jour. La commande `helm repo add` ne vous permettra pas d'ajouter les anciennes URL à moins que vous ne spécifiiez `--use-deprecated-repos`. + +### Sur GKE (Google Kubernetes Engine), je reçois l'erreur "No SSH tunnels currently open" + +``` +Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? +``` + +Une autre variation de ce message est : + + +``` +Unable to connect to the server: x509: certificate signed by unknown authority +``` + +Le problème est que votre fichier de configuration Kubernetes local doit contenir les bons identifiants. + +Lorsque vous créez un cluster sur GKE, il vous fournit des identifiants, y compris des certificats SSL et des autorités de certification. Ceux-ci doivent être stockés dans un fichier de configuration Kubernetes (par défaut : `~/.kube/config`) afin que `kubectl` et `helm` puissent y accéder. + +### Après la migration vers Helm 3, `helm list` n'affiche que certains (ou aucun) de mes releases + +Il est probable que vous ayez omis le fait que Helm 3 utilise désormais les namespaces du cluster pour délimiter les releases. Cela signifie que pour toutes les commandes faisant référence à une release, vous devez soit : + +* vous fier au namespace actuel dans le contexte Kubernetes actif (comme décrit par la commande `kubectl config view --minify`), +* spécifier le namespace correct en utilisant l'argument `--namespace`/`-n`, ou +* pour la commande `helm list`, spécifier l'argument `--all-namespaces`/`-A`. + +Cela s'applique à `helm ls`, `helm uninstall`, et à toutes les autres commandes `helm` faisant référence à une release. + + +### Sur macOS, on accède au fichier /etc/.mdns_debug. Pourquoi? + +Nous sommes conscients d'un cas sur macOS où Helm essaiera d'accéder à un fichier nommé `/etc/.mdns_debug`. Si le fichier existe, Helm garde le fichier ouvert pendant son exécution. + +Cela est causé par la bibliothèque MDNS de macOS. Elle tente de charger ce fichier pour lire les paramètres de débogage (s'ils sont activés). Le fichier ne devrait probablement pas rester ouvert, et ce problème a été signalé à Apple. Cependant, c'est macOS, et non Helm, qui est à l'origine de ce comportement. + +Si vous ne souhaitez pas que Helm charge ce fichier, vous pouvez éventuellement compiler Helm en tant que bibliothèque statique qui n'utilise pas la pile réseau de l'hôte. Cela augmentera la taille du binaire de Helm, mais empêchera l'ouverture du fichier. + +Ce problème avait initialement été signalé comme un problème de sécurité potentiel. Mais il a depuis été déterminé qu'il n'y a pas de défaut ou de vulnérabilité causé par ce comportement. + +### La commande `helm repo add` échoue alors qu'elle fonctionnait auparavant + +Dans Helm 3.3.1 et les versions antérieures, la commande `helm repo add ` ne produisait aucun résultat si vous tentiez d'ajouter un dépôt déjà existant. L'argument `--no-update` générait une erreur si le dépôt était déjà enregistré. + +Dans Helm 3.3.2 et les versions ultérieures, une tentative d'ajout d'un dépôt existant générera une erreur : + +`Error: repository name (reponame) already exists, please specify a different name` + +Le comportement par défaut a maintenant été inversé. Le flag `--no-update` est désormais ignoré, tandis que si vous souhaitez remplacer (écraser) un dépôt existant, vous pouvez utiliser `--force-update`. + +Cela est dû à un changement important pour un correctif de sécurité, comme expliqué dans les [notes de version de Helm 3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2). + +### Activation de la journalisation du client Kubernetes + +L'affichage des messages de journalisation pour le débogage du client Kubernetes peut être activé en utilisant l'argument [klog](https://pkg.go.dev/k8s.io/klog). L'utilisation de l'argument `-v` pour définir le niveau de verbosité sera suffisant dans la plupart des cas. + +Par exemple : + +``` +helm list -v 6 +``` + +### Les installations de Tiller ont cessé de fonctionner et l'accès est refusé + +Les releases de Helm étaient auparavant disponibles à partir de . Comme expliqué dans ["Annonçant get.helm.sh"](https://helm.sh/blog/get-helm-sh/), l'emplacement officiel a changé en juin 2019. [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) rend toutes les anciennes images de Tiller disponibles. + +Si vous essayez de télécharger des versions plus anciennes de Helm depuis le bucket de stockage que vous utilisiez auparavant, vous constaterez peut-être qu'elles sont manquantes : + +``` + + AccessDenied + Access denied. +
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
+ +``` + +L'[emplacement historique des image de Tiller](https://gcr.io/kubernetes-helm/tiller) a commencé à supprimer les images en août 2021. Nous avons rendu ces images disponibles à l'emplacement [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller). Par exemple, pour télécharger la version v2.17.0, remplacez : + +`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` + +avec : + +`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` + +Pour initialiser avec Helm v2.17.0 : + +`helm init —upgrade` + +Ou si une version différente est nécessaire, utilisez l'argument `--tiller-image` pour remplacer l'emplacement par défaut et installer une version spécifique de Helm v2 : + +`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` + +**Note :** Les mainteneurs de Helm recommandent de migrer vers une version actuellement supportée de Helm. Helm v2.17.0 était la dernière version de Helm v2 ; Helm v2 est non supporté depuis novembre 2020, comme détaillé dans [Helm 2 et le projet Charts sont maintenant obsolètes](https://helm.sh/blog/helm-2-becomes-unsupported/). De nombreuses CVE ont été signalées contre Helm depuis lors, et ces vulnérabilités sont corrigées dans Helm v3 mais ne seront jamais corrigées dans Helm v2. Consultez la [liste actuelle des avis de sécurité publiés sur Helm](https://github.com/helm/helm/security/advisories?state=published) et élaborez un plan pour [migrer vers Helm v3](https://helm.sh/docs/topics/v2_v3_migration/#helm) dès aujourd'hui. diff --git a/content/fr/docs/faq/uninstalling.md b/content/fr/docs/faq/uninstalling.md new file mode 100644 index 000000000..b937cc7f8 --- /dev/null +++ b/content/fr/docs/faq/uninstalling.md @@ -0,0 +1,22 @@ +--- +title: "Désinstallation" +weight: 3 +--- + +## Désinstallation + +### Je souhaite supprimer Helm. Où sont tous ses fichiers ? + +En plus du binaire `helm`, Helm stocke certains fichiers aux emplacements suivants : + +- `$XDG_CACHE_HOME` +- `$XDG_CONFIG_HOME` +- `$XDG_DATA_HOME` + +Le tableau suivant fournis la liste des emplacements par défaut pour chacun des ces dossiers, par système d'exploitation : + +| Système d'Exploitation | Emplacement du Cache | Emplacement de la Configuration | Emplacement des Données | +|------------------------|--------------------------|---------------------------------|-------------------------| +| Linux | `$HOME/.cache/helm ` | `$HOME/.config/helm ` | `$HOME/.local/share/helm` | +| macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm ` | +| Windows | `%TEMP%\helm ` | `%APPDATA%\helm ` | `%APPDATA%\helm` | From 82293cbd45db4892a8dbf833a90f1da3fcd09f6f Mon Sep 17 00:00:00 2001 From: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Fri, 23 Aug 2024 16:36:41 +0200 Subject: [PATCH 04/15] Translate part 'community' in french. Todo: update release_checklist summary Signed-off-by: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- content/fr/docs/community/developers.md | 109 +++++ content/fr/docs/community/history.md | 20 + content/fr/docs/community/localization.md | 110 +++++ content/fr/docs/community/related.md | 78 ++++ .../fr/docs/community/release_checklist.md | 380 ++++++++++++++++++ 5 files changed, 697 insertions(+) create mode 100644 content/fr/docs/community/developers.md create mode 100644 content/fr/docs/community/history.md create mode 100644 content/fr/docs/community/localization.md create mode 100644 content/fr/docs/community/related.md create mode 100644 content/fr/docs/community/release_checklist.md diff --git a/content/fr/docs/community/developers.md b/content/fr/docs/community/developers.md new file mode 100644 index 000000000..7f79e894d --- /dev/null +++ b/content/fr/docs/community/developers.md @@ -0,0 +1,109 @@ +--- +title: "Guide du Développeur" +description: "Insctructions pour configurer votre environement de développement pour Helm" +weight: 1 +--- + +Ce guide explique comment configurer votre environnement pour le développement sur Helm. + +## Prérequis + +- La dernière version de Go +- Un cluster Kubernetes avec kubectl (optionnel) +- Git + +## Construire Helm + +Nous utiliserons Make pour compiler nos programmes. La manière la plus simple de commencer est la suivantes : + +```console +$ make +``` + +Si nécessaire, cela installera d'abord les dépendances et validera la configuration. Ensuite, cela compilera `helm` et le placera dans `bin/helm`. + +Pour exécuter Helm localement, vous pouvez exécuter `bin/helm`. + +- Helm est connu pour fonctionner sur macOS et la plupart des distributions Linux, y compris Alpine. + +## Lancer des Tests + +Pour exécuter tous les tests, lancez `make test`. Comme prérequis, vous devez avoir [golangci-lint](https://golangci-lint.run) installé. + +## Directives de Contribution + +Nous accueillons volontiers les contributions. Ce projet a établi certaines directives afin de garantir que (a) la qualité du code reste élevée, (b) le projet reste cohérent, et (c) les contributions respectent les exigences légales en matière de logiciel open source. Notre intention n'est pas de surcharger les contributeurs, mais de construire un code open source élégant et de haute qualité afin que nos utilisateurs en bénéficient. + +Assurez-vous d'avoir lu et compris le guide principal de CONTRIBUTION : + + + +### Structure du Code + +Le code du projet Helm est organisé comme suit : + +- Les programmes individuels se trouvent dans `cmd/`. Le code à l'intérieur de `cmd/` n'est pas conçu pour être réutilisé en tant que bibliothèque. +- Les bibliothèques partagées sont stockées dans `pkg/`. +- Le répertoire `scripts/` contient plusieurs scripts utilitaires. La plupart d'entre eux sont utilisés par le pipeline CI/CD. + +La gestion des dépendances Go est en évolution, et il est probable qu'elle change au cours du cycle de vie de Helm. Nous encourageons les développeurs à _ne pas_ essayer de gérer les dépendances manuellement. Au lieu de cela, nous suggérons de vous fier au `Makefile` du projet pour le faire à votre place. Avec Helm 3, il est recommandé d'utiliser la version 1.13 de Go ou ultérieure. + +### Écriture de la Documentation + +Depuis Helm 3, la documentation a été déplacée dans son propre dépôt. Lors de l'ajout de nouvelles fonctionnalités, veuillez rédiger la documentation correspondante et la soumettre au dépôt [helm-www](https://github.com/helm/helm-www). + +Une exception : [La sortie CLI de Helm (en anglais)](https://helm.sh/docs/helm/) est générée à partir du binaire `helm` lui-même. Voir [Mise à jour de la documentation de référence CLI de Helm](https://github.com/helm/helm-www#updating-the-helm-cli-reference-docs) pour les instructions sur la génération de cette sortie. Lorsqu'elle est traduite, la sortie CLI n'est pas générée et peut être trouvée dans `/content//docs/helm`. + +### Conventions Git + +Nous utilisons Git pour notre système de contrôle de version. La branche `main` est le lieu des candidats actuels au développement. Les versions sont marquées avec des tags. + +Nous acceptons les modifications du code via des Pull Requests (PRs) sur GitHub. Un flux de travail pour cela est le suivant : + +1. **Forkez** le dépôt `github.com/helm/helm` dans votre compte GitHub. +2. **Clonez** le dépôt forké dans le répertoire de votre choix avec `git clone`. +3. Créez une nouvelle branche de travail (`git checkout -b feat/my-feature`) et effectuez vos modifications sur cette branche. +4. Lorsque vous êtes prêt pour la révision, **poussez** votre branche sur GitHub, puis **ouvrez** une nouvelle pull request avec nous. + +Pour les messages de commit Git, nous suivons les [Semantic Commit Messages](https://karma-runner.github.io/0.13/dev/git-commit-msg.html) : + +``` +fix(helm): add --foo flag to 'helm install' + +When 'helm install --foo bar' is run, this will print "foo" in the +output regardless of the outcome of the installation. + +Closes #1234 +``` + +Types communs de commit : + +- fix : Corriger un bug ou une erreur +- feat : Ajouter une nouvelle fonctionnalité +- docs : Modifier la documentation +- test : Améliorer les tests +- ref : Refactoriser le code existant + +Scope communs : + +- `helm` : La CLI Helm +- `pkg/lint` : Le package lint. Suivez une convention similaire pour tout autre package +- `*` : Deux scopes ou plus + +Voir plus : + +- Les [Directives Deis](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md) ont été l'inspiration pour cette section. +- [Karma Runner](https://karma-runner.github.io/0.13/dev/git-commit-msg.html), qui définisse l'idée des messages de commit sémantiques. + +### Conventions Go + +Nous suivons de très près les standards de style de codage Go. En général, l'exécution de `go fmt` rendra votre code élégant pour vous. + +Nous suivons également les conventions recommandées par `go lint` et `gometalinter`. Exécutez `make test-style` pour vérifier la conformité du style. + +Voir plus : + +- Le guide Effective Go [introduit la mise en forme](https://golang.org/doc/effective_go.html#formatting). +- Le Wiki de Go contient un excellent article sur la [mise en forme](https://github.com/golang/go/wiki/CodeReviewComments). + +Si vous exécutez la cible `make test`, non seulement les tests unitaires seront exécutés, mais les tests de style le seront également. Si la cible `make test` échoue, même pour des raisons de style, votre PR ne sera pas considérée comme prête à être fusionnée. diff --git a/content/fr/docs/community/history.md b/content/fr/docs/community/history.md new file mode 100644 index 000000000..89ed27b53 --- /dev/null +++ b/content/fr/docs/community/history.md @@ -0,0 +1,20 @@ +--- +title: "L'histoire du Projet" +description: "Fournit un aperçu général de l'historique du projet." +weight: 4 +--- + +Helm est un [projet de la CNCF](https://www.cncf.io/projects/), qui a été [récompensé](https://helm.sh/blog/celebrating-helms-cncf-graduation/). + + +Helm a commencé sous ce qui est maintenant connu sous le nom de [Helm Classic](https://github.com/helm/helm-classic), un projet Deis lancé en 2015 et présenté lors de la première KubeCon. + +En janvier 2016, le projet a fusionné avec un outil GCS appelé Kubernetes Deployment Manager, et le projet a été transféré sous [Kubernetes](https://kubernetes.io). À la suite de la fusion des bases de code, Helm 2.0 a été publié plus tard dans l'année. La caractéristique clé du Deployment Manager qui a survécu dans Helm 2 était le composant côté serveur, renommé de DM en Tiller pour la version finale de Helm 2.0. + +Helm a été promu de sous-projet Kubernetes à projet CNCF à part entière en juin 2018. Helm a constitué un organe de gouvernance de niveau supérieur et plusieurs projets ont été intégrés au projet Helm, notamment Monocular, le Helm Chart Repo, Chart Museum, et plus tard le Helm Hub.. + +Lorsque le cycle de développement de Helm 3 a commencé, Tiller a été supprimé, rapprochant Helm de sa vision originale d'outil client. Cependant, Helm 3 continue de suivre les releases à l'intérieur du cluster Kubernetes, ce qui permet aux équipes de collaborer sur un ensemble commun de releases Helm. Helm 3 a été publié en novembre 2019. + +Helm a obtenu le statut de [projet gradué de la CNCF en avril 2020](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/). + +Le [Artifact Hub](https://artifacthub.io) de la CNCF remplace le [Helm Hub](https://hub.helm.sh) en octobre 2020. diff --git a/content/fr/docs/community/localization.md b/content/fr/docs/community/localization.md new file mode 100644 index 000000000..5a5e4490b --- /dev/null +++ b/content/fr/docs/community/localization.md @@ -0,0 +1,110 @@ +--- +title: "Traduction de la documentation Helm" +description: "Instructions pour traduire la documentation de Helm" +weight: 5 +--- + +Ce guide explique comment traduire la documentation de Helm. + +## Commencer + +Les contributions pour les traductions suivent le même processus que les contributions pour la documentation. Les traductions sont fournies via des [pull requests](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) au dépôt git [helm-www](https://github.com/helm/helm-www), et les pull requests sont examinées par l'équipe qui gère le site web. + +### Code de la langue à 2 lettres + +La documentation est organisée selon la norme [ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php) pour les codes de langue. Par exemple, le code à deux lettres pour le coréen est `ko`. + +Dans le contenu et la configuration, vous trouverez le code de langue utilisé. Voici 3 exemples : + +- Dans le répertoire `content`, les codes de langue sont utilisés comme sous-répertoires et le contenu localisé pour chaque langue se trouve dans ces répertoires. Principalement dans le sous-répertoire `docs` de chaque répertoire de code de langue. +- Le répertoire `i18n` contient un fichier de configuration pour chaque langue avec les phrases utilisées sur le site Web. Les fichiers sont nommés selon le modèle `[LANG].toml`, où `[LANG]` est le code de langue à deux lettres. +- Dans le fichier `config.toml` au niveau supérieur, il y a une configuration pour la navigation et d'autres détails organisés par code de langue. + +L'anglais, avec un code de langue `en`, est la langue par défaut et la source des traductions. + +### Fork, Branche, Changement, Pull Request + +Pour contribuer aux traductions, commencez par [créer un fork](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) du [dépôt helm-www](https://github.com/helm/helm-www) sur GitHub. Vous commencerez par valider les modifications dans votre fork. + +Par défaut, votre fork sera configuré pour travailler sur la branche par défaut, connue sous le nom de `main`. Veuillez utiliser des branches pour développer vos modifications et créer des pull requests. Si vous n'êtes pas familier avec les branches, vous pouvez [lire à leur sujet dans la documentation GitHub](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-branches). + +Une fois que vous avez créé une branche, apportez les modifications nécessaires pour ajouter des traductions et localiser le contenu dans la langue souhaitée. + +Remarque : Helm utilise un [Certificate of Origin pour les Développeurs](https://developercertificate.org/). Tous les commits doivent être signés. Lorsque vous effectuez un commit, vous pouvez utiliser le drapeau `-s` ou `--signoff` pour signer le commit avec votre nom et votre adresse e-mail configurés dans Git. Plus de détails sont disponibles dans le fichier [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md#sign-your-work). + +Lorsque vous êtes prêt, créez une [pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) pour soumettre la traduction au dépôt `helm-www`. + +Une fois qu'une pull request a été créée, l'un des mainteneurs l'examinera. Les détails sur ce processus se trouvent dans le fichier [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md). + +## Traduction du contenu + +La localisation de tout le contenu de Helm est une tâche importante. Il est tout à fait acceptable de commencer par une petite partie. Les traductions peuvent être étendues au fil du temps. + +### Commencer avec une nouvelle langue + +Lorsque vous commencez à travailler sur une nouvelle langue, un minimum est nécessaire. Cela inclut : + +- Ajouter un répertoire `content/[LANG]/docs` contenant un fichier `_index.md`. C'est la page de destination principale de la documentation. +- Créer un fichier `[LANG].toml` dans le répertoire `i18n`. Vous pouvez initialement copier le fichier `en.toml` comme point de départ. +- Ajouter une section pour la langue dans le fichier `config.toml` pour exposer la nouvelle langue. Une section de langue existante peut servir de point de départ. + +### Traduction + +Le contenu traduit doit être situé dans le répertoire `content/[LANG]/docs`. Il doit avoir la même URL que la source en anglais. Par exemple, pour traduire l'introduction en coréen, il peut être utile de copier la source en anglais comme suit : + +```sh +mkdir -p content/ko/docs/intro +cp content/en/docs/intro/install.md content/ko/docs/intro/install.md +``` + +Le contenu du nouveau fichier peut ensuite être traduit dans l'autre langue. + +Ne pas ajouter une copie non traduite d'un fichier en anglais dans `content/[LANG]/`. Une fois qu'une langue existe sur le site, les pages non traduites seront automatiquement redirigées vers la version anglaise. La traduction prend du temps, et il est important de toujours traduire la version la plus récente de la documentation, et non un fork obsolète. + +Assurez-vous de supprimer toutes les lignes `aliases` de la section d'en-tête. Une ligne comme `aliases: ["/docs/using_helm/"]` n'a pas sa place dans les traductions. Ce sont des redirections pour d'anciens liens qui n'existent pas pour les nouvelles pages. + +Notez que les outils de traduction peuvent aider dans le processus. Cela inclut les traductions générées automatiquement. Les traductions automatiques doivent être révisées ou corrigées par un locuteur natif à la langue traduite pour vérifier la grammaire et le sens avant leur publication. + + +## Naviguer entre les langues + +![Screen Shot 2020-05-11 at 11 24 22 +AM](https://user-images.githubusercontent.com/686194/81597103-035de600-937a-11ea-9834-cd9dcef4e914.png) + +Le fichier de configuration global du site, [`config.toml`](https://github.com/helm/helm-www/blob/main/config.toml#L83L89), est l'endroit où la navigation entre les langues est configurée. + +Pour ajouter une nouvelle langue, ajoutez un nouvel ensemble de paramètres en utilisant le [code de langue à deux lettres](./localization/#two-letter-language-code) défini ci-dessus. Exemple : + +``` +# Korean +[languages.ko] +title = "Helm" +description = "Helm - The Kubernetes Package Manager." +contentDir = "content/ko" +languageName = "한국어 Korean" +weight = 1 +``` + +## Résolution des Liens Internes + +Le contenu traduit peut parfois inclure des liens vers des pages qui n'existent que dans une autre langue. Cela entraînera des [erreurs de construction du site](https://app.netlify.com/sites/helm-merge/deploys). Exemple : + +``` +12:45:31 PM: htmltest started at 12:45:30 on app +12:45:31 PM: ======================================================================== +12:45:31 PM: ko/docs/chart_template_guide/accessing_files/index.html +12:45:31 PM: hash does not exist --- ko/docs/chart_template_guide/accessing_files/index.html --> #basic-example +12:45:31 PM: ✘✘✘ failed in 197.566561ms +12:45:31 PM: 1 error in 212 documents +``` + +Pour résoudre ce problème, vous devez vérifier votre contenu pour les liens internes. + +* Les liens d'ancrage doivent refléter la valeur `id` traduite. +* Les liens vers les pages internes doivent être corrigés. + +Pour les pages internes qui n'existent pas _(ou qui n'ont pas encore été traduites)_, le site ne sera pas généré tant qu'une correction n'aura pas été apportée. En tant que solution de repli, l'URL peut pointer vers une autre langue où ce contenu _existe_ comme suit : + +`< relref path="/docs/topics/library_charts.md" lang="en" >` + +Voir les [documents Hugo sur les références croisées entre langues](https://gohugo.io/content-management/cross-references/#link-to-another-language-version) pour plus d'informations. diff --git a/content/fr/docs/community/related.md b/content/fr/docs/community/related.md new file mode 100644 index 000000000..3b7dff099 --- /dev/null +++ b/content/fr/docs/community/related.md @@ -0,0 +1,78 @@ +--- +title: "Projets et documentation associés" +description: "Outils tiers, plugins et documentation fournis par la communauté !" +weight: 3 +--- + +La communauté Helm a produit de nombreux outils supplémentaires, plugins et de la documentation sur Helm. Nous aimons entendre parler de ces projets. + +Si vous avez quelque chose à ajouter à cette liste, n'hésitez pas à ouvrir une [issue](https://github.com/helm/helm-www/issues) ou une [pull request](https://github.com/helm/helm-www/pulls). + +## Plugins Helm + +- [helm-adopt](https://github.com/HamzaZo/helm-adopt) - Un plugin Helm v3 pour adopter des ressources k8s existantes dans un nouveau Chart Helm généré. +- [helm-chartsnap](https://github.com/jlandowner/helm-chartsnap) - Plugin de tests instantanés pour les Charts Helm. +- [Helm Diff](https://github.com/databus23/helm-diff) - Aperçu de `helm upgrade` sous forme de diff coloré +- [Helm Dt](https://github.com/vmware-labs/distribution-tooling-for-helm) - Plugin qui aide à distribuer les Charts Helm à travers les registres OCI et dans les environnements déconnecté +- [Helm Dashboard](https://github.com/komodorio/helm-dashboard) - Interface graphique pour Helm, permettant de visualiser les releases et les dépôts, ainsi que les différences de manifests. +- [helm-gcs](https://github.com/hayorov/helm-gcs) - Plugin pour gérer les dépôts sur Google Cloud Storage +- [helm-git](https://github.com/aslafy-z/helm-git) - Installer des charts et récupérer des fichiers de valeurs depuis vos dépôts Git +- [helm-k8comp](https://github.com/cststack/k8comp) - Plugin pour créer des Helm Charts à partir de hiera en utilisant k8comp +- [helm-mapkubeapis](https://github.com/helm/helm-mapkubeapis) - Mettre à jour les métadonnées des releases Helm pour remplacer les API Kubernetes obsolètes ou supprimées +- [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) - Plugin pour surveiller une release et effectuer un rollback basé sur une requête Prometheus/ElasticSearch +- [helm-release-plugin](https://github.com/JovianX/helm-release-plugin) - Plugin pour la gestion des releases : mettre à jour les valeurs des releases, extraire (et recréer) les Helm Charts à partir des releases déployées, et définir le TTL des releases Helm. +- [helm-s3](https://github.com/hypnoglow/helm-s3) -Plugin Helm permettant d'utiliser AWS S3 comme [dépôt] privé de charts +- [helm-schema-gen](https://github.com/karuppiah7890/helm-schema-gen) - Plugin Helm qui génère un schéma YAML des valeurs pour vos Charts Helm 3 +- [helm-secrets](https://github.com/jkroepke/helm-secrets) - Plugin pour gérer et stocker les secrets en toute sécurité (basé sur [sops](https://github.com/mozilla/sops)) +- [helm-sigstore](https://github.com/sigstore/helm-sigstore) - + Plugin pour Helm intégrant l'écosystème [sigstore](https://sigstore.dev/). Recherchez, téléchargez et vérifiez les Helm charts signés. +- [helm-tanka](https://github.com/Duologic/helm-tanka) - Plugin Helm pour rendre du Tanka/Jsonnet à l'intérieur des Charts Helm. +- [hc-unit](https://github.com/xchapter7x/hcunit) - Plugin pour tester les charts localement à l'aide d'OPA (Open Policy Agent) et Rego +- [helm-unittest](https://github.com/quintush/helm-unittest) - Plugin pour tester les charts localement avec YAML +- [helm-val](https://github.com/HamzaZo/helm-val) - Plugin pour récupérer les valeurs d'une release précédente. +- [helm-external-val](https://github.com/kuuji/helm-external-val) - Plugin qui récupère les valeurs Helm depuis des sources externes (ConfigMaps, Secrets, etc.). +- [helm-images](https://github.com/nikhilsbhat/helm-images) - Plugin Helm pour récupérer toutes les images possibles depuis le chart avant le déploiement ou depuis une release déployée. +- [helm-drift](https://github.com/nikhilsbhat/helm-drift) - Plugin Helm qui identifie la configuration ayant divergé du Helm chart. + +Nous encourageons également les auteurs sur GitHub à utiliser le tag [helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories) sur leurs dépôts de plugins. + +## Outils additionnels + +Outils superposés à Helm. + +Voici la traduction des outils et plugins mentionnés : + +- [Armada](https://airshipit.readthedocs.io/projects/armada/en/latest/) - Gère les releases préfixées à travers divers namespaces Kubernetes et supprime les jobs terminés pour des déploiements complexes. +- [avionix](https://github.com/zbrookle/avionix) - Interface Python pour générer des Helm charts et des fichiers Kubernetes YAML, permettant l'héritage et moins de duplication de code. +- [Botkube](https://botkube.io) - Exécute des commandes Helm directement depuis Slack, Discord, Microsoft Teams et Mattermost. +- [Captain](https://github.com/alauda/captain) - Un contrôleur Helm3 utilisant HelmRequest et Release CRD. +- [Chartify](https://github.com/appscode/chartify) - Génère des Helm charts à partir de ressources Kubernetes existantes. +- [ChartMuseum](https://github.com/helm/chartmuseum) - Dépôt de Helm Charts avec support pour Amazon S3 et Google Cloud Storage. +- [chart-registry](https://github.com/hangyan/chart-registry) - Héberge des Helm Charts sur OCI Registry. +- [Codefresh](https://codefresh.io) - Plateforme CI/CD et de gestion native Kubernetes avec des tableaux de bord UI pour gérer les Helm charts et les releases. +- [Flux](https://fluxcd.io/docs/components/helm/) - Livraison continue et progressive de Git à Kubernetes. +- [Helmfile](https://github.com/helmfile/helmfile) - Helmfile est un spécification déclarative pour déployer des Helm charts. +- [Helmper](https://github.com/ChristofferNissen/helmper) - Helmper vous aide à importer des Helm Charts - y compris tous les artefacts OCI (images), dans vos propres OCI registries. Helmper facilite également le scan de sécurité et le patch des images OCI. Helmper utilise Helm, Oras, Trivy, Copacetic et Buildkitd. +- [Helmsman](https://github.com/Praqma/helmsman) - Helmsman est un outil de type helm-charts-as-code qui permet d’installer, mettre à jour, protéger, déplacer et supprimer des releases à partir de fichiers d'état désiré versionnés (décrits dans un format TOML simple). +- [HULL](https://github.com/vidispine/hull) - Cette bibliothèque chart fournit une interface prête à l'emploi pour spécifier tous les objets Kubernetes directement dans le `values.yaml`. Elle élimine la nécessité d'écrire des templates pour vos charts et propose de nombreuses fonctionnalités supplémentaires pour simplifier la création et l'utilisation des Helm charts. +- [Konveyor Move2Kube](https://konveyor.io/move2kube/) - Génère des Helm charts pour vos projets existants. +- [Landscaper](https://github.com/Eneco/landscaper/) - "Landscaper prend un ensemble de références de Helm Chart avec des valeurs (un état désiré) et le réalise dans un cluster Kubernetes." +- [Monocular](https://github.com/helm/monocular) - Interface Web pour les dépôts de Helm Charts. +- [Monokle](https://monokle.io) - Outil de bureau pour créer, déboguer et déployer des ressources Kubernetes et des Helm Charts. +- [Orkestra](https://azure.github.io/orkestra/) - Une plateforme cloud-native d'orchestration des releases et de gestion du cycle de vie (LCM) pour un groupe de releases Helm et leurs sous-charts associés. +- [Tanka](https://tanka.dev/helm) - Grafana Tanka configure les ressources Kubernetes via Jsonnet avec la capacité de consommer des Helm Charts. +- [Terraform Helm Provider](https://github.com/hashicorp/terraform-provider-helm) - Le provider Helm pour HashiCorp Terraform permet la gestion du cycle de vie des Helm Charts avec une syntaxe déclarative d'infrastructure-as-code. Le provider Helm est souvent associé à d'autres providers Terraform, comme le provider Kubernetes, pour créer un flux de travail commun à travers tous les services d'infrastructure. +- [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) - Plugin VIM pour Kubernetes et Helm. + +## Helm Included + +Plateformes, distributions et services qui incluent le support de Helm. + +- [Kubernetic](https://kubernetic.com/) - Client bureau pour Kubernetes +- [Jenkins X](https://jenkins-x.io/) - CI/CD automatisé open source pour Kubernetes qui utilise Helm pour [promouvoir](https://jenkins-x.io/docs/getting-started/promotion/) des applications à travers les environnements via GitOps + +## Divers + +Collection d'éléments utiles pour les auteurs de Charts et les utilisateurs de Helm. + +- [Await](https://github.com/saltside/await) - Image Docker pour "attendre" différentes conditions, particulièrement utile pour les conteneurs d'initialisation. [Plus d'infos](https://blog.slashdeploy.com/2017/02/16/introducing-await/) diff --git a/content/fr/docs/community/release_checklist.md b/content/fr/docs/community/release_checklist.md new file mode 100644 index 000000000..d249c6d86 --- /dev/null +++ b/content/fr/docs/community/release_checklist.md @@ -0,0 +1,380 @@ +--- +title: "Liste de vérification pour les releases" +description: "Liste de vérification pour les mainteneurs lors de la publication de leur prochaine release Helm" +weight: 2 +--- + +# Guide du Mainteneur pour les Releases Helm + +Il est temps de publier une nouvelle version de Helm ! En tant que mainteneur de Helm responsable de la publication, vous êtes la personne la mieux placée pour [mettre à jour cette liste de vérification de publication](https://github.com/helm/helm-www/blob/main/content/en/docs/community/release_checklist.md) si votre expérience diffère de ce qui est documenté ici. + +Toutes les versions seront sous la forme vX.Y.Z où X est le numéro de version majeure, Y est le numéro de version mineure et Z est le numéro de correctif. Ce projet suit strictement [le versionnage sémantique](https://semver.org/), donc suivre cette étape est crucial. + +Helm annonce à l'avance la date de sa prochaine version mineure. Tous les efforts doivent être faits pour respecter la date annoncée. De plus, au moment de commencer le processus de publication, la date de la prochaine version doit avoir été sélectionnée car elle sera utilisée dans le processus de publication. + +Ces instructions couvriront la configuration initiale suivie du processus de publication pour trois types de versions différents : + +* **Versions majeures** - publiées moins fréquemment - ont des changements incompatibles +* **Versions mineures** - publiées tous les 3 à 4 mois - sans changements incompatibles +* **Versions de correction** - publiées mensuellement - ne nécessitent pas toutes les étapes de ce guide + +[Configuration Initiale](#configuration-initiale) + +1. [Créer une branche de release](#1-créer-une-branche-de-release) +2. [Major/Minor releases: Change the Version Number in Git](#2-majorminor-releases-change-the-version-number-in-git) +3. [Major/Minor releases: Commit and Push the Release Branch](#3-majorminor-releases-commit-and-push-the-release-branch) +4. [Major/Minor releases: Create a Release Candidate](#4-majorminor-releases-create-a-release-candidate) +5. [Major/Minor releases: Iterate on Successive Release Candidates](#5-majorminor-releases-iterate-on-successive-release-candidates) +6. [Finalize the Release](#6-finalize-the-release) +7. [Write the Release Notes](#7-write-the-release-notes) +8. [PGP Sign the downloads](#8-pgp-sign-the-downloads) +9. [Publish Release](#9-publish-release) +10. [Update Docs](#10-update-docs) +11. [Tell the Community](#11-tell-the-community) + +## Configuration Initiale + +### Configurer le dépôt distant Git + +Il est important de noter que ce document suppose que le dépôt distant Git dans votre référentiel correspondant à est nommé "upstream". Si ce n'est pas le cas (par exemple, si vous avez choisi de le nommer "origin" ou quelque chose de similaire), assurez-vous d'ajuster les extraits listés en fonction de votre environnement local. Si vous n'êtes pas sûr du nom de votre dépôt distant "upstream", utilisez une commande comme `git remote -v` pour le découvrir. + +Si vous n'avez pas de dépôt distant [upstream](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork), vous pouvez en ajouter un en utilisant une commande comme : + +```shell +git remote add upstream git@github.com:helm/helm.git +``` + +### Configurer les variables d'environnement + +Dans cet documentation, nous allons également faire référence à quelques variables d'environnement que vous pourriez vouloir définir pour plus de commodité. Pour les versions majeures/minor, utilisez les variables suivantes : + +```shell +export RELEASE_NAME=vX.Y.0 +export RELEASE_BRANCH_NAME="release-X.Y" +export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.1" +``` + +Si vous créez une version de correctif, utilisez les variables suivantes à la place : + +```shell +export PREVIOUS_PATCH_RELEASE=vX.Y.Z +export RELEASE_NAME=vX.Y.Z+1 +export RELEASE_BRANCH_NAME="release-X.Y" +``` + +### Configurer la clé de signature + +Nous allons également ajouter des mesures de sécurité et de vérification au processus de publication en hachant les binaires et en fournissant des fichiers de signature. Nous effectuons cela en utilisant [GitHub et GPG](https://help.github.com/en/articles/about-commit-signature-verification). Si vous n'avez pas encore configuré GPG, vous pouvez suivre ces étapes : + +1. [Installer GPG](https://gnupg.org/index.html) +2. [Générer une clé GPG](https://help.github.com/en/articles/generating-a-new-gpg-key) +3. [Ajouter la clé à votre compte GitHub](https://help.github.com/en/articles/adding-a-new-gpg-key-to-your-github-account) +4. [Ajouter la clé de signature à Git](https://help.github.com/en/articles/telling-git-about-your-signing-key) + +Une fois que vous avez une clé de signature, vous devez l'ajouter au fichier KEYS à la racine du dépôt. Les instructions pour l'ajouter au fichier KEYS sont présentes dans le fichier lui-même. Si vous ne l'avez pas encore fait, vous devez ajouter votre clé publique au réseau de serveurs de clés. Si vous utilisez GnuPG, vous pouvez suivre les [instructions fournies par Debian](https://debian-administration.org/article/451/Submitting_your_GPG_key_to_a_keyserver). + +## 1. Créer une branche de release + +### Version Majeures/Mineur + +Les versions majeures sont destinées à l'ajout de nouvelles fonctionnalités et aux changements de comportement *qui cassent la compatibilité ascendante*. Les versions mineures concernent l'ajout de nouvelles fonctionnalités qui ne cassent pas la compatibilité ascendante. Pour créer une version majeure ou mineure, commencez par créer une branche `release-X.Y` à partir de `main`. + +```shell +git fetch upstream +git checkout upstream/main +git checkout -b $RELEASE_BRANCH_NAME +``` + +Cette nouvelle branche servira de base pour la version, sur laquelle nous allons itérer par la suite. + +Vérifiez qu'un [milestone helm/helm](https://github.com/helm/helm/milestones) pour la version existe sur GitHub (en le créant si nécessaire). Assurez-vous que les PRs et les issues pour cette version sont inclus dans ce milestone. + +Pour les versions majeures et mineures, passez à l'étape 2 : [Versions majeures/minor : Changer le numéro de version dans Git](#2-majorminor-releases-change-the-version-number-in-git). + +### Versions de correction + +Les versions de correction sont quelques corrections critiques sélectionnées pour les versions existantes. +Commencez par créer une branche `release-X.Y` : + +```shell +git fetch upstream +git checkout -b $RELEASE_BRANCH_NAME upstream/$RELEASE_BRANCH_NAME +``` + +À partir de là, nous pouvons sélectionner les commits que nous souhaitons inclure dans la version de correction : + +```shell +# get the commits ids we want to cherry-pick +git log --oneline +# cherry-pick the commits starting from the oldest one, without including merge commits +git cherry-pick -x +``` + +Après que les commits aient été sélectionnés, la branche de version doit être poussée. + +```shell +git push upstream $RELEASE_BRANCH_NAME +``` + +Pousser la branche déclenchera l'exécution des tests. Assurez-vous qu'ils passent avant de créer le tag. Ce nouveau tag servira de base pour la version de correction. + +La création d'un [jalon Helm/helm](https://github.com/helm/helm/milestones) est facultative pour les versions de correction. + +Assurez-vous de vérifier [helm sur CircleCI](https://circleci.com/gh/helm/helm) pour voir si la version a réussi les tests CI avant de continuer. Les versions de correction peuvent sauter les étapes 2 à 5 et passer directement à l'étape 6 pour [Finaliser la version](#6-finalize-the-release). + +## 2. Versions majeures/mineures : Modifier le numéro de version dans Git + +Lors d'une version majeure ou mineure, assurez-vous de mettre à jour `internal/version/version.go` avec le nouveau numéro de version. + +```shell +$ git diff internal/version/version.go +diff --git a/internal/version/version.go b/internal/version/version.go +index 712aae64..c1ed191e 100644 +--- a/internal/version/version.go ++++ b/internal/version/version.go +@@ -30,7 +30,7 @@ var ( + // Increment major number for new feature additions and behavioral changes. + // Increment minor number for bug fixes and performance enhancements. + // Increment patch number for critical fixes to existing releases. +- version = "v3.3" ++ version = "v3.4" + + // metadata is extra build time data + metadata = "" +``` + +En plus de mettre à jour la version dans le fichier `version.go`, vous devrez également mettre à jour les tests correspondants utilisant ce numéro de version. + +* `cmd/helm/testdata/output/version.txt` +* `cmd/helm/testdata/output/version-client.txt` +* `cmd/helm/testdata/output/version-client-shorthand.txt` +* `cmd/helm/testdata/output/version-short.txt` +* `cmd/helm/testdata/output/version-template.txt` +* `pkg/chartutil/capabilities_test.go` + +```shell +git add . +git commit -m "bump version to $RELEASE_NAME" +``` + +Cela mettra à jour uniquement la branche `$RELEASE_BRANCH_NAME`. Vous devrez également intégrer ce changement dans la branche principale pour la création de la prochaine version, comme dans [cet exemple de 3.2 à 3.3](https://github.com/helm/helm/pull/8411/files), et l'ajouter au jalon pour la prochaine version. + +```shell +# get the last commit id i.e. commit to bump the version +git log --format="%H" -n 1 + +# create new branch off main +git checkout main +git checkout -b bump-version- + +# cherry pick the commit using id from first command +git cherry-pick -x + +# commit the change +git push origin bump-version- +``` + +## 3. Versions majeures/mineures : Commiter et pousser la branche de version + +Pour que les autres puissent commencer les tests, nous pouvons maintenant pousser la branche de version en amont et démarrer le processus de test. + +```shell +git push upstream $RELEASE_BRANCH_NAME +``` + +Assurez-vous de vérifier [helm sur CircleCI](https://circleci.com/gh/helm/helm) pour voir si la version a réussi les tests CI avant de continuer. + +Si possible, demandez à d'autres personnes de faire une révision par les pairs de la branche avant de poursuivre, afin de garantir que toutes les modifications nécessaires ont été apportées et que tous les commits pour la version sont présents. + +## 4. Version majeures/mineures : Créer une version candidate + +Maintenant que la branche de version est prête, il est temps de commencer à créer et à itérer sur les candidats à la version. + +```shell +git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}" +git push upstream $RELEASE_CANDIDATE_NAME +``` + +CircleCI créera automatiquement une image de version taguée et un binaire client pour les tests. + +Pour les testeurs, le processus pour commencer les tests après que CircleCI ait terminé la construction des artefacts comprend les étapes suivantes pour récupérer le client : + +linux/amd64, utilisez /bin/bash: + +```shell +wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-linux-amd64.tar.gz +``` + +darwin/amd64, utilisez Terminal.app: + +```shell +wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-darwin-amd64.tar.gz +``` + +windows/amd64, utilisez PowerShell: + +```shell +PS C:\> Invoke-WebRequest -Uri "https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-windows-amd64.tar.gz" -OutFile "helm-$ReleaseCandidateName-windows-amd64.tar.gz" +``` + +Ensuite, décompressez et déplacez le binaire dans un répertoire de votre `$PATH`, ou déplacez-le quelque part et ajoutez-le à votre `$PATH` (par exemple, `/usr/local/bin/helm` pour Linux/macOS, `C:\Program Files\helm\helm.exe` pour Windows). + +## 5. Versions majeures/mineures : Itérer sur les candidats à la version successifs + +Passez plusieurs jours à investir du temps et des ressources pour essayer de casser Helm de toutes les manières possibles, en documentant toutes les découvertes pertinentes pour la version. Ce temps doit être consacré aux tests et à la recherche de manières dont la version pourrait avoir causé des problèmes avec diverses fonctionnalités ou environnements de mise à niveau, et non au codage. Pendant cette période, la version est en gel de code, et toute modification supplémentaire du code sera repoussée à la prochaine version. + +Pendant cette phase, la branche `$RELEASE_BRANCH_NAME` continuera d'évoluer à mesure que vous produirez de nouveaux candidats à la version. La fréquence des nouveaux candidats dépend du responsable de la version : utilisez votre meilleur jugement en tenant compte de la gravité des problèmes signalés, de la disponibilité des testeurs et de la date limite de la version. En général, il vaut mieux laisser une version dépasser la date limite que de publier une version défectueuse. + +Chaque fois que vous souhaiterez produire un nouveau candidat à la version, vous commencerez par ajouter des commits à la branche en les sélectionnant depuis la branche principale : + +```shell +git cherry-pick -x +``` + +Vous devrez également pousser la branche sur GitHub et vous assurer qu'elle passe les tests CI. + +Ensuite, taguez-la et informez les utilisateurs du nouveau candidat à la version : + +```shell +export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.2" +git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}" +git push upstream $RELEASE_CANDIDATE_NAME +``` + +Une fois poussée sur GitHub, vérifiez que la branche avec ce tag se construit correctement dans CI. + +À partir de là, répétez simplement ce processus en testant en continu jusqu'à ce que vous soyez satisfait du candidat à la version. Pour un candidat à la version, nous ne rédigeons pas les notes complètes, mais vous pouvez esquisser quelques [notes de version](#7-write-the-release-notes). + +## 6. Finaliser la version + +Lorsque vous êtes enfin satisfait de la qualité d'un candidat à la version, vous pouvez passer à la création de la version finale. Vérifiez une dernière fois pour vous assurer que tout est en ordre, puis poussez enfin le tag de version. + +```shell +git checkout $RELEASE_BRANCH_NAME +git tag --sign --annotate "${RELEASE_NAME}" --message "Helm release ${RELEASE_NAME}" +git push upstream $RELEASE_NAME +``` + +Vérifiez que la version a réussi dans [CircleCI](https://circleci.com/gh/helm/helm). Si ce n'est pas le cas, vous devrez corriger la version et la pousser à nouveau. + +Comme le job CI prendra un certain temps à s'exécuter, vous pouvez passer à la rédaction des notes de version pendant que vous attendez sa conclusion. + +## 7. Rédiger les notes de version + +Nous générerons automatiquement un changelog basé sur les commits effectués pendant un cycle de version, mais il est généralement plus bénéfique pour l'utilisateur final que les notes de version soient rédigées par un être humain, une équipe marketing ou un chien. + +Si vous publiez une version majeure ou mineure, il suffit généralement de lister les fonctionnalités notables visibles par l'utilisateur. Pour les versions de correction, faites de même, mais indiquez les symptômes et les personnes concernées. + +Les notes de version doivent inclure le numéro de version et la date prévue de la prochaine version. + +Un exemple de note de version pour une version mineure serait le suivant : + +```markdown +## vX.Y.Z + +Helm vX.Y.Z is a feature release. This release, we focused on . Users are encouraged to upgrade for the best experience. + +The community keeps growing, and we'd love to see you there! + +- Join the discussion in [Kubernetes Slack](https://kubernetes.slack.com): + - `#helm-users` for questions and just to hang out + - `#helm-dev` for discussing PRs, code, and bugs +- Hang out at the Public Developer Call: Thursday, 9:30 Pacific via [Zoom](https://zoom.us/j/696660622) +- Test, debug, and contribute charts: [Artifact Hub helm charts](https://artifacthub.io/packages/search?kind=0) + +## Notable Changes + +- Kubernetes 1.16 is now supported including new manifest apiVersions +- Sprig was upgraded to 2.22 + +## Installation and Upgrading + +Download Helm X.Y. The common platform binaries are here: + +- [MacOS amd64](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz.sha256sum) / CHECKSUM_VAL) +- [Linux amd64](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz.sha256sum) / CHECKSUM_VAL) +- [Linux arm](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz.sha256) / CHECKSUM_VAL) +- [Linux arm64](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz.sha256sum) / CHECKSUM_VAL) +- [Linux i386](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz.sha256) / CHECKSUM_VAL) +- [Linux ppc64le](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz.sha256sum) / CHECKSUM_VAL) +- [Linux s390x](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz.sha256sum) / CHECKSUM_VAL) +- [Windows amd64](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip) ([checksum](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip.sha256sum) / CHECKSUM_VAL) + +The [Quickstart Guide](https://docs.helm.sh/using_helm/#quickstart-guide) will get you going from there. For **upgrade instructions** or detailed installation notes, check the [install guide](https://docs.helm.sh/using_helm/#installing-helm). You can also use a [script to install](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3) on any system with `bash`. + +## What's Next + +- vX.Y.Z+1 will contain only bug fixes and is planned for . +- vX.Y+1.0 is the next feature release and is planned for . This release will focus on ... + +## Changelog + +- chore(*): bump version to v2.7.0 08c1144f5eb3e3b636d9775617287cc26e53dba4 (Adam Reese) +- fix circle not building tags f4f932fabd197f7e6d608c8672b33a483b4b76fa (Matthew Fisher) +``` + +Un ensemble partiellement complété de notes de version, y compris le changelog, peut être créé en exécutant la commande suivante : + +```shell +export VERSION="$RELEASE_NAME" +export PREVIOUS_RELEASE=vX.Y.Z +make clean +make fetch-dist +make release-notes +``` + +Cela créera un bon ensemble de notes de version de base auquel vous devrez simplement ajouter les sections **Changements notables** et **À venir**. + +N'hésitez pas à personnaliser les notes de version ; il est agréable pour les gens de penser que nous ne sommes pas tous des robots. + +Vous devez également vérifier que les URLs et les sommes de contrôle sont correctes dans les notes de version générées automatiquement. + +Une fois terminé, allez sur GitHub dans [helm/helm releases](https://github.com/helm/helm/releases) et éditez les notes de version pour la version taguée avec les notes rédigées ici. +Pour la branche cible, définissez-la sur `$RELEASE_BRANCH_NAME`. + +Il est maintenant utile de demander à d'autres personnes de jeter un œil aux notes de version avant la publication de la version. Envoyez une demande de révision à [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG). C'est toujours bénéfique car il est facile de passer à côté de quelque chose. + +## 8. Signer les téléchargements avec PGP + +Bien que les sommes de contrôle fournissent une signature confirmant que le contenu des téléchargements est bien celui attendu, les packages signés offrent une traçabilité sur l'origine du package. + +Pour ce faire, exécutez les commandes `make` suivantes : + +```shell +export VERSION="$RELEASE_NAME" +make clean # if not already run +make fetch-dist # if not already run +make sign +``` + +Cela générera des fichiers de signature en ASCII armé pour chacun des fichiers poussés par CI. + +Tous les fichiers de signature (`*.asc`) doivent être téléchargés sur la version GitHub (joindre les binaires). + +## 9. Publication d'une version + +C'est le moment d'officialiser cette version ! + +Après avoir sauvegardé les notes de version sur GitHub, complété la construction CI et ajouté les fichiers de signature à la version, vous pouvez cliquer sur "Publier" pour publier la version. Cela la répertorie comme "latest" et affiche cette version sur la page d'accueil du dépôt [helm/helm](https://github.com/helm/helm). + +## 10. Mettre à jour la documentation + +La section des docs du site [Helm](https://helm.sh/docs) liste les versions de Helm pour la documentation. Les versions majeures, mineures et de correction doivent être mises à jour sur le site. La date de la prochaine version mineure est également publiée sur le site et doit être mise à jour. + +Pour ce faire, créez une demande de tirage (pull request) contre le dépôt [helm-www](https://github.com/helm/helm-www). Dans le fichier `config.toml`, trouvez la section `params.versions` appropriée et mettez à jour la version de Helm, comme dans cet exemple de [mise à jour de la version actuelle](https://github.com/helm/helm-www/pull/676/files). Dans le même fichier `config.toml`, mettez également à jour la section `params.nextversion`. + +Fermez le [jalon helm/helm](https://github.com/helm/helm/milestones) pour la version, si applicable. + +Mettez à jour le [version skew](https://github.com/helm/helm-www/blob/main/content/en/docs/topics/version_skew.md) pour les versions majeures et mineures. + +Mettez à jour le calendrier des versions [ici](https://helm.sh/calendar/release) : +* Créez une entrée pour la prochaine version mineure avec un rappel pour ce jour à 17h GMT. +* Créez une entrée pour le RC1 de la prochaine version mineure le lundi de la semaine précédant la version prévue, avec un rappel pour ce jour à 17h GMT. + +## 11. Informer la communauté + +Félicitations ! Vous avez terminé. Allez vous servir une $BOISSON_DE_VOTRE_CHOIX. Vous l'avez bien mérité. + +Après avoir savouré une bonne $BOISSON_DE_VOTRE_CHOIX, annoncez la nouvelle version sur Slack et sur Twitter avec un lien vers la [version sur GitHub](https://github.com/helm/helm/releases). + +Optionnellement, rédigez un article de blog sur la nouvelle version et mettez en avant certaines des nouvelles fonctionnalités ! From 1e3904f7a17ffcbe4904fe888a2b61b51269dc12 Mon Sep 17 00:00:00 2001 From: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Fri, 23 Aug 2024 19:01:14 +0200 Subject: [PATCH 05/15] Update release_checklist summary & remove alias and wrong internal link Signed-off-by: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- .../fr/docs/community/release_checklist.md | 20 +++++++++---------- content/fr/docs/faq/_index.md | 4 ---- .../howto/chart_repository_sync_example.md | 4 ++-- 3 files changed, 12 insertions(+), 16 deletions(-) diff --git a/content/fr/docs/community/release_checklist.md b/content/fr/docs/community/release_checklist.md index d249c6d86..e372564a4 100644 --- a/content/fr/docs/community/release_checklist.md +++ b/content/fr/docs/community/release_checklist.md @@ -21,16 +21,16 @@ Ces instructions couvriront la configuration initiale suivie du processus de pub [Configuration Initiale](#configuration-initiale) 1. [Créer une branche de release](#1-créer-une-branche-de-release) -2. [Major/Minor releases: Change the Version Number in Git](#2-majorminor-releases-change-the-version-number-in-git) -3. [Major/Minor releases: Commit and Push the Release Branch](#3-majorminor-releases-commit-and-push-the-release-branch) -4. [Major/Minor releases: Create a Release Candidate](#4-majorminor-releases-create-a-release-candidate) -5. [Major/Minor releases: Iterate on Successive Release Candidates](#5-majorminor-releases-iterate-on-successive-release-candidates) -6. [Finalize the Release](#6-finalize-the-release) -7. [Write the Release Notes](#7-write-the-release-notes) -8. [PGP Sign the downloads](#8-pgp-sign-the-downloads) -9. [Publish Release](#9-publish-release) -10. [Update Docs](#10-update-docs) -11. [Tell the Community](#11-tell-the-community) +2. [Versions majeures/mineures : Modifier le numéro de version dans Git](#2-versions-majeuresmineures--modifier-le-numéro-de-version-dans-git) +3. [Versions majeures/mineures : Commiter et pousser la branche de version](#3-versions-majeuresmineures--commiter-et-pousser-la-branche-de-version) +4. [Version majeures/mineures : Créer une version candidate](#4-version-majeuresmineures--créer-une-version-candidate) +5. [Versions majeures/mineures : Itérer sur les candidats à la version successifs](#5-versions-majeuresmineures--itérer-sur-les-candidats-à-la-version-successifs) +6. [Finaliser la version](#6-finaliser-la-version) +7. [Rédiger les notes de version](#7-rédiger-les-notes-de-version) +8. [Signer les téléchargements avec PGP](#8-signer-les-téléchargements-avec-pgp) +9. [Publication d'une version](#9-publication-dune-version) +10. [Mettre à jour la documentation](#10-mettre-à-jour-la-documentation) +11. [Informer la communauté](#11-informer-la-communauté) ## Configuration Initiale diff --git a/content/fr/docs/faq/_index.md b/content/fr/docs/faq/_index.md index 4397fe2b8..d0ed4470c 100644 --- a/content/fr/docs/faq/_index.md +++ b/content/fr/docs/faq/_index.md @@ -1,10 +1,6 @@ --- title: "Foire Aux Questions" weight: 8 -aliases: [ - "/fr/docs/topics/faq/", - "/fr/docs/faq/" -] --- # Foire Aux Questions diff --git a/content/fr/docs/howto/chart_repository_sync_example.md b/content/fr/docs/howto/chart_repository_sync_example.md index b9dcf027c..db1eda869 100644 --- a/content/fr/docs/howto/chart_repository_sync_example.md +++ b/content/fr/docs/howto/chart_repository_sync_example.md @@ -14,7 +14,7 @@ weight: 2 sur votre bucket GCS au cas où vous supprimeriez accidentellement quelque chose._ ## Mise en place d'un dépôt de charts local -Créez un dépôt local, comme nous l'avons fait dans [le guide du dépôt de charts]({{< ref "/fr/docs/topics/chart_repository.md" >}}), et placez-y vos charts packagés. +Créez un dépôt local, comme nous l'avons fait dans [le guide du dépôt de charts](), et placez-y vos charts packagés. Pour exemple : ```console @@ -78,7 +78,7 @@ Downloading file://local-dir/index.yaml: 346 B/346 Liens utiles : * Documentation sur [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) -* [Guide du dépôt de chart]({{< ref "/docs/topics/chart_repository.md" >}}) +* [Guide du dépôt de chart]() * Documentation sur [object versioning and concurrency control](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) sur Google Cloud Storage From 7a1dc405284e069b01d9c29bd978a16653ec80aa Mon Sep 17 00:00:00 2001 From: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Sat, 21 Sep 2024 17:13:20 +0200 Subject: [PATCH 06/15] Translate topics in french Signed-off-by: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- content/fr/docs/topics/advanced.md | 150 +++ content/fr/docs/topics/architecture.md | 54 ++ content/fr/docs/topics/chart_repository.md | 232 +++++ content/fr/docs/topics/chart_tests.md | 86 ++ content/fr/docs/topics/charts.md | 873 ++++++++++++++++++ content/fr/docs/topics/charts_hooks.md | 155 ++++ content/fr/docs/topics/kubernetes_apis.md | 93 ++ content/fr/docs/topics/kubernetes_distros.md | 76 ++ content/fr/docs/topics/library_charts.md | 348 +++++++ .../topics/permissions_sql_storage_backend.md | 43 + content/fr/docs/topics/plugins.md | 285 ++++++ content/fr/docs/topics/provenance.md | 225 +++++ content/fr/docs/topics/rbac.md | 148 +++ content/fr/docs/topics/registries.md | 235 +++++ content/fr/docs/topics/release_policy.md | 43 + content/fr/docs/topics/v2_v3_migration.md | 78 ++ content/fr/docs/topics/version_skew.md | 61 ++ 17 files changed, 3185 insertions(+) create mode 100644 content/fr/docs/topics/advanced.md create mode 100644 content/fr/docs/topics/architecture.md create mode 100644 content/fr/docs/topics/chart_repository.md create mode 100644 content/fr/docs/topics/chart_tests.md create mode 100644 content/fr/docs/topics/charts.md create mode 100644 content/fr/docs/topics/charts_hooks.md create mode 100644 content/fr/docs/topics/kubernetes_apis.md create mode 100644 content/fr/docs/topics/kubernetes_distros.md create mode 100644 content/fr/docs/topics/library_charts.md create mode 100644 content/fr/docs/topics/permissions_sql_storage_backend.md create mode 100644 content/fr/docs/topics/plugins.md create mode 100644 content/fr/docs/topics/provenance.md create mode 100644 content/fr/docs/topics/rbac.md create mode 100644 content/fr/docs/topics/registries.md create mode 100644 content/fr/docs/topics/release_policy.md create mode 100644 content/fr/docs/topics/v2_v3_migration.md create mode 100644 content/fr/docs/topics/version_skew.md diff --git a/content/fr/docs/topics/advanced.md b/content/fr/docs/topics/advanced.md new file mode 100644 index 000000000..b9ee79243 --- /dev/null +++ b/content/fr/docs/topics/advanced.md @@ -0,0 +1,150 @@ +--- +title: "Techniques avancées de Helm" +description: "Explique diverses fonctionnalités avancées pour les utilisateurs expérimentés de Helm" +weight: 9 +--- + +Cette section explique diverses fonctionnalités et techniques avancées pour l'utilisation de Helm. Les informations de cette section sont destinées aux « power users » de Helm qui souhaitent effectuer des personnalisations et manipulations avancées de leurs charts et releases. Chacune de ces fonctionnalités avancées comporte ses propres compromis et mises en garde, il est donc nécessaire de les utiliser avec précaution et une connaissance approfondie de Helm. En d'autres termes, souvenez-vous du [principe de Peter Parker](https://fr.wikipedia.org/wiki/Un_grand_pouvoir_implique_de_grandes_responsabilit%C3%A9s). + +## Post Rendering +Le post rendering donne aux installateurs de charts la possibilité de manipuler, configurer et/ou valider manuellement les manifestes rendus avant qu'ils ne soient installés par Helm. Cela permet aux utilisateurs ayant des besoins de configuration avancés d'utiliser des outils comme [`kustomize`](https://kustomize.io) pour appliquer des modifications de configuration sans avoir à forker un chart public ou à demander aux mainteneurs de chart de spécifier chaque option de configuration pour un logiciel. Il existe également des cas d'utilisation pour l'injection d'outils communs et de side-cars dans des environnements d'entreprise, ou pour l'analyse des manifestes avant le déploiement. + +### Prérequis +- Helm 3.1+ + +### Utilisation +Un post-renderer peut être n'importe quel exécutable qui accepte des manifestes Kubernetes rendus sur STDIN et renvoie des manifestes Kubernetes valides sur STDOUT. Il doit retourner un code de sortie non nul en cas d'échec. Il s'agit de la seule "API" entre les deux composants. Cela offre une grande flexibilité dans ce que vous pouvez faire avec votre processus de post-rendering. + +Un post-renderer peut être utilisé avec les commandes `install`, `upgrade` et `template`. Pour utiliser un post-renderer, il suffit d'ajouter l'option `--post-renderer` suivie du chemin vers l'exécutable du renderer que vous souhaitez utiliser : + +```shell +$ helm install mychart stable/wordpress --post-renderer ./path/to/executable +``` + +Si le chemin ne contient aucun séparateur, il effectuera une recherche dans $PATH, sinon il résoudra tout chemin relatif en un chemin entièrement qualifié. + +Si vous souhaitez utiliser plusieurs post-renderers, appelez-les tous dans un script ou ensemble dans l'outil binaire que vous avez créé. En bash, cela serait aussi simple que `renderer1 | renderer2 | renderer3`. + +Vous pouvez voir un exemple d'utilisation de `kustomize` comme post-renderer [ici](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render). + +### Précautions +Lors de l'utilisation de post-renderers, il y a plusieurs points importants à garder à l'esprit. Le plus crucial est que, lorsque vous utilisez un post-renderer, toutes les personnes modifiant cette release **DOIVENT** utiliser le même renderer afin d'avoir des builds reproductibles. Cette fonctionnalité est intentionnellement conçue pour permettre à tout utilisateur de changer de renderer ou de cesser d'utiliser un renderer, mais cela doit être fait de manière délibérée pour éviter les modifications accidentelles ou la perte de données. + +Une autre note importante concerne la sécurité. Si vous utilisez un post-renderer, vous devez vous assurer qu'il provient d'une source fiable (comme c'est le cas pour tout autre exécutable arbitraire). L'utilisation de renderers non fiables ou non vérifiés n'est PAS recommandée, car ils ont un accès complet aux templates rendus, qui contiennent souvent des données secrètes. + +### Post-renderers personnalisés +L'étape de post-rendering offre encore plus de flexibilité lorsqu'elle est utilisée dans le Go SDK. Tout post-renderer doit simplement implémenter l'interface Go suivante : + +```go +type PostRenderer interface { + //Run attend un seul buffer rempli de manifestes rendus par Helm. Il + // attend que les résultats modifiés soient retournés dans un buffer séparé ou + // une erreur s'il y a un problème ou un échec pendant l'exécution de l'étape de post-rendering. + Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) +} +``` + +Pour plus d'informations sur l'utilisation du Go SDK, consultez la [section Go SDK](#go-sdk). + +## Go SDK +Helm 3 a introduit un Go SDK entièrement restructuré pour offrir une meilleure expérience lors de la création de logiciels et d'outils utilisant Helm. La documentation complète est disponible sur [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3), mais un court aperçu de certains des packages les plus courants ainsi qu'un exemple simple suivent ci-dessous. + +### Vue d'ensemble des packages +Voici une liste des packages les plus couramment utilisés avec une explication simple pour chacun : + +- `pkg/action` : Contient le « client » principal pour effectuer des actions Helm. Il s'agit du même package utilisé en interne par la CLI. Si vous devez simplement exécuter des commandes Helm de base depuis un autre programme Go, ce package est fait pour vous. +- `pkg/{chart,chartutil}` : Méthodes et outils utilisés pour charger et manipuler des charts. +- `pkg/cli` et ses sous-packages : Contient tous les gestionnaires des variables d'environnement Helm standard, et ses sous-packages gèrent la sortie et les fichiers de valeurs. +- `pkg/release` : Définit l'objet `Release` et ses statuts. + +Évidemment, il existe de nombreux autres packages en plus de ceux-ci, alors consultez la documentation pour plus d'informations ! + +### Exemple simple +Voici un exemple simple de réalisation d'un `helm list` en utilisant le Go SDK : + +```go +package main + +import ( + "log" + "os" + + "helm.sh/helm/v3/pkg/action" + "helm.sh/helm/v3/pkg/cli" +) + +func main() { + settings := cli.New() + + actionConfig := new(action.Configuration) + // // Vous pouvez passer une chaîne vide au lieu de settings.Namespace() pour lister tous les namespaces + + if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { + log.Printf("%+v", err) + os.Exit(1) + } + + client := action.NewList(actionConfig) + // Liste uniquement les déploiements + client.Deployed = true + results, err := client.Run() + if err != nil { + log.Printf("%+v", err) + os.Exit(1) + } + + for _, rel := range results { + log.Printf("%+v", rel) + } +} + +``` + +## Stockage des backends + +Helm 3 a modifié le stockage par défaut des informations de release en utilisant des Secrets dans le namespace de la release. Helm 2 stockait par défaut les informations de release sous forme de ConfigMaps dans le namespace de l'instance de Tiller. Les sous-sections suivantes montrent comment configurer différents backends. Cette configuration est basée sur la variable d'environnement `HELM_DRIVER`. Elle peut être définie sur l'une des valeurs suivantes : `[configmap, secret, sql]`. + +### Backend de stockage ConfigMap + +Pour activer le backend de stockage ConfigMap, vous devez définir la variable d'environnement `HELM_DRIVER` sur `configmap`. + +Vous pouvez la définir dans un shell comme suit : + +```shell +export HELM_DRIVER=configmap +``` + +Si vous souhaitez passer du backend par défaut au backend ConfigMap, vous devrez effectuer la migration vous-même. Vous pouvez récupérer les informations de release avec la commande suivante : + +```shell +kubectl get secret --all-namespaces -l "owner=helm" +``` + +**REMARQUES POUR LA PRODUCTION** : Les informations de release incluent le contenu des charts et des fichiers de valeurs, et peuvent donc contenir des données sensibles (comme des mots de passe, des clés privées et d'autres identifiants) qui doivent être protégées contre tout accès non autorisé. Lors de la gestion de l'autorisation Kubernetes, par exemple avec [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), il est possible de donner un accès plus large aux ressources ConfigMap, tout en restreignant l'accès aux ressources Secret. Par exemple, le rôle [orienté utilisateur par défaut](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) "view" accorde l'accès à la plupart des ressources, mais pas aux Secrets. De plus, les données des secrets peuvent être configurées pour un [stockage chiffré](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Veuillez en tenir compte si vous décidez de passer au backend ConfigMap, car cela pourrait exposer les données sensibles de votre application. + +### Backend de stockage SQL + +Il existe un backend de stockage SQL en ***bêta*** qui stocke les informations de release dans une base de données SQL. + +L'utilisation d'un tel backend de stockage est particulièrement utile si vos informations de release pèsent plus de 1 Mo (dans ce cas, elles ne peuvent pas être stockées dans ConfigMaps/Secrets en raison des limites internes du store de clés-valeurs etcd sous-jacent de Kubernetes). + +Pour activer le backend SQL, vous devrez déployer une base de données SQL et définir la variable d'environnement `HELM_DRIVER` sur `sql`. Les détails de la base de données sont configurés avec la variable d'environnement `HELM_DRIVER_SQL_CONNECTION_STRING`. + +Vous pouvez la définir dans un shell comme suit : + +```shell +export HELM_DRIVER=sql +export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme +``` + +> Note : Uniquement PostgreSQL est actuellement supporté. + +**REMARQUES POUR LA PRODUCTION** : Il est recommandé de : +- Préparer votre base de données pour la production. Pour PostgreSQL, consultez la documentation sur l'[administration du serveur](https://www.postgresql.org/docs/12/admin.html) pour plus de détails. +- Activer la [gestion des permissions](/docs/permissions_sql_storage_backend/) pour refléter les RBAC Kubernetes pour les informations de release. + +Si vous souhaitez passer du backend par défaut au backend SQL, vous devrez effectuer la migration vous-même. Vous pouvez récupérer les informations de release avec la commande suivante : + +```shell +kubectl get secret --all-namespaces -l "owner=helm" +``` diff --git a/content/fr/docs/topics/architecture.md b/content/fr/docs/topics/architecture.md new file mode 100644 index 000000000..ba0742d24 --- /dev/null +++ b/content/fr/docs/topics/architecture.md @@ -0,0 +1,54 @@ +--- +title: "Architecture de Helm" +description: "Décrit l'architecture de Helm à un niveau élevé" +weight: 8 +--- + +# Architecture de Helm + +Ce document décrit l'architecture de Helm à un niveau élevé. + +## L'objectif de Helm + +Helm est un outil pour gérer les packages Kubernetes appelés _charts_. Helm peut faire ce qui suit : + +- Créer de nouveaux charts à partir de zéro +- Emballer les charts dans des archives de chart (.tgz) +- Interagir avec les dépôts de charts où les charts sont stockés +- Installer et désinstaller des charts dans un cluster Kubernetes existant +- Gérer le cycle de vie des releases de charts qui ont été installées avec Helm + +Pour Helm, il y a trois concepts importants : + +1. Le _chart_ est un ensemble d'informations nécessaires pour créer une instance d'une application Kubernetes. +2. La _config_ contient des informations de configuration qui peuvent être fusionnées dans un chart emballé pour créer un objet déployable. +3. Une _release_ est une instance en cours d'exécution d'un _chart_, combinée avec une configuration spécifique. + +## Composants + +Helm est un exécutable qui est implémenté en deux parties distinctes : + +**Le Client Helm** est un client en ligne de commande pour les utilisateurs finaux. Le client est responsable des éléments suivants : + +- Développement local de charts +- Gestion des dépôts +- Gestion des releases +- Interface avec la bibliothèque Helm + - Envoi des charts à installer + - Demande de mise à jour ou de désinstallation des releases existantes + +**La Bibliothèque Helm** fournit la logique pour exécuter toutes les opérations Helm. Elle interagit avec le serveur API Kubernetes et offre les capacités suivantes : + +- Combinaison d'un chart et d'une configuration pour créer une release +- Installation de charts dans Kubernetes et fourniture de l'objet de release correspondant +- Mise à jour et désinstallation de charts en interagissant avec Kubernetes + +La bibliothèque Helm autonome encapsule la logique Helm afin qu'elle puisse être utilisée par différents clients. + +## Implémentation + +Le client Helm et la bibliothèque sont écrits en langage de programmation Go. + +La bibliothèque utilise la bibliothèque cliente Kubernetes pour communiquer avec Kubernetes. Actuellement, cette bibliothèque utilise REST+JSON. Elle stocke les informations dans des Secrets situés à l'intérieur de Kubernetes. Elle n'a pas besoin de sa propre base de données. + +Les fichiers de configuration sont, lorsque cela est possible, écrits en YAML. diff --git a/content/fr/docs/topics/chart_repository.md b/content/fr/docs/topics/chart_repository.md new file mode 100644 index 000000000..ffb8deb1f --- /dev/null +++ b/content/fr/docs/topics/chart_repository.md @@ -0,0 +1,232 @@ +--- +title: "Guide des dépôts de charts" +description: "Comment créer et travailler avec des dépôts de charts Helm" +weight: 6 +--- + +Cette section explique comment créer et travailler avec des dépôts de charts Helm. À un niveau élevé, un dépôt de charts est un emplacement où les charts emballés peuvent être stockés et partagés. + +Le dépôt de charts Helm communautaire distribué est situé sur [Artifact Hub](https://artifacthub.io/packages/search?kind=0) et accueille la participation. Cependant, Helm permet également de créer et de gérer votre propre dépôt de charts. Ce guide explique comment procéder. + +## Prérequis + +* Consultez le guide [Quickstart]({{< ref "quickstart.md" >}}) +* Lisez le document [Charts]({{}}) + +## Créer un dépôt de charts + +Un _dépôt de charts_ est un serveur HTTP qui contient un fichier `index.yaml` et éventuellement des charts emballés. Lorsque vous êtes prêt à partager vos charts, la méthode recommandée est de les télécharger sur un dépôt de charts. + +Depuis Helm 2.2.0, l'authentification SSL côté client pour un dépôt est prise en charge. D'autres protocoles d'authentification peuvent être disponibles sous forme de plugins. + +Parce qu'un dépôt de charts peut être n'importe quel serveur HTTP capable de servir des fichiers YAML et tar et de répondre aux requêtes GET, vous avez de nombreuses options pour héberger votre propre dépôt de charts. Par exemple, vous pouvez utiliser un bucket Google Cloud Storage (GCS), un bucket Amazon S3, GitHub Pages, ou même créer votre propre serveur web. + +### La structure du dépôt de charts + +Un dépôt de charts se compose de charts emballés et d'un fichier spécial appelé `index.yaml`, qui contient un index de tous les charts dans le dépôt. Souvent, les charts décrits par `index.yaml` sont également hébergés sur le même serveur, tout comme les [fichiers de provenance]({{}}). + +Par exemple, la structure du dépôt `https://example.com/charts` pourrait ressembler à ceci : + +``` +charts/ + | + |- index.yaml + | + |- alpine-0.1.2.tgz + | + |- alpine-0.1.2.tgz.prov +``` + +Dans ce cas, le fichier index contiendrait des informations sur un chart, le chart Alpine, et fournirait l'URL de téléchargement `https://example.com/charts/alpine-0.1.2.tgz` pour ce chart. + +Il n'est pas nécessaire qu'un package de chart soit situé sur le même serveur que le fichier `index.yaml`. Cependant, cela est souvent le plus simple. + +### Le fichier index + +Le fichier d'index est un fichier YAML appelé `index.yaml`. Il contient des métadonnées sur le package, y compris le contenu du fichier `Chart.yaml` d'un chart. Un dépôt de charts valide doit avoir un fichier d'index. Le fichier d'index contient des informations sur chaque chart dans le dépôt de charts. La commande `helm repo index` générera un fichier d'index basé sur un répertoire local donné contenant des charts emballés. + +Voici un exemple de fichier d'index : + +```yaml +apiVersion: v1 +entries: + alpine: + - created: 2016-10-06T16:23:20.499814565-06:00 + description: Deploy a basic Alpine Linux pod + digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd + home: https://helm.sh/helm + name: alpine + sources: + - https://github.com/helm/helm + urls: + - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz + version: 0.2.0 + - created: 2016-10-06T16:23:20.499543808-06:00 + description: Deploy a basic Alpine Linux pod + digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 + home: https://helm.sh/helm + name: alpine + sources: + - https://github.com/helm/helm + urls: + - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz + version: 0.1.0 + nginx: + - created: 2016-10-06T16:23:20.499543808-06:00 + description: Create a basic nginx HTTP server + digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff + home: https://helm.sh/helm + name: nginx + sources: + - https://github.com/helm/charts + urls: + - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz + version: 1.1.0 +generated: 2016-10-06T16:23:20.499029981-06:00 +``` + +## Hébergement des dépôts de charts + +Cette section présente plusieurs façons de servir un dépôt de charts. + +### Google Cloud Storage + +La première étape est de **créer votre bucket GCS**. Nous l'appellerons `fantastic-charts`. + +![Create a GCS Bucket](https://helm.sh/img/create-a-bucket.png) + +Ensuite, rendez votre bucket public en **modifiant les autorisations du bucket**. + +![Edit Permissions](https://helm.sh/img/edit-permissions.png) + +Ajoutez cette ligne pour **rendre votre bucket public** : + +![Make Bucket Public](https://helm.sh/img/make-bucket-public.png) + +Félicitations, vous avez maintenant un bucket GCS vide prêt à servir des charts ! + +Vous pouvez télécharger votre dépôt de charts en utilisant l'outil en ligne de commande Google Cloud Storage, ou via l'interface web GCS. Un bucket GCS public peut être accédé via HTTPS à cette adresse : `https://bucket-name.storage.googleapis.com/`. + +### Cloudsmith + +Vous pouvez également configurer des dépôts de charts en utilisant Cloudsmith. Pour en savoir plus sur les dépôts de charts avec Cloudsmith, consultez [ce lien](https://help.cloudsmith.io/docs/helm-chart-repository). + +### JFrog Artifactory + +De la même manière, vous pouvez également configurer des dépôts de charts en utilisant JFrog Artifactory. Pour en savoir plus sur les dépôts de charts avec JFrog Artifactory, consultez [ce lien](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories). + +### Exemple de GitHub Pages + +De manière similaire, vous pouvez créer des dépôts de charts en utilisant GitHub Pages. + +GitHub permet de servir des pages web statiques de deux manières différentes : + +- En configurant un projet pour servir le contenu de son répertoire `docs/` +- En configurant un projet pour servir une branche particulière + +Nous allons adopter la seconde approche, bien que la première soit tout aussi simple. + +La première étape sera de **créer votre branche gh-pages**. Vous pouvez le faire localement comme suit : +```console +$ git checkout -b gh-pages +``` + +Ou via un navigateur web en utilisant le bouton **Branch** sur votre dépôt GitHub : + +![Create GitHub Pages branch](https://helm.sh/img/create-a-gh-page-button.png) + +Next, you'll want to make sure your **gh-pages branch** is set as GitHub Pages, +click on your repo **Settings** and scroll down to **GitHub pages** section and +set as per below: + +![Create GitHub Pages branch](https://helm.sh/img/set-a-gh-page.png) + +Par défaut, la **Source** est généralement définie sur **gh-pages branch**. Si ce n'est pas le cas par défaut, sélectionnez-la. + +Vous pouvez utiliser un **domaine personnalisé** si vous le souhaitez. + +Assurez-vous également que **Enforce HTTPS** est coché, afin que le **HTTPS** soit utilisé lorsque les charts sont servis. + +Dans ce type de configuration, vous pouvez utiliser votre branche par défaut pour stocker le code de vos charts, et la **branche gh-pages** comme dépôt de charts, par exemple : `https://USERNAME.github.io/REPONAME`. Le dépôt de démonstration [TS Charts](https://github.com/technosophos/tscharts) est accessible à `https://technosophos.github.io/tscharts/`. + +Si vous avez décidé d'utiliser GitHub Pages pour héberger le dépôt de charts, consultez l'[Action Chart Releaser]({{< ref "/docs/howto/chart_releaser_action.md" >}}). L'Action Chart Releaser est un workflow GitHub Action qui transforme un projet GitHub en un dépôt Helm chart auto-hébergé, en utilisant l'outil en ligne de commande [helm/chart-releaser](https://github.com/helm/chart-releaser). + +### Serveurs Web ordinaires + +Pour configurer un serveur web ordinaire pour servir des charts Helm, vous devez simplement faire ce qui suit : + +- Placez votre index et vos charts dans un répertoire que le serveur peut servir +- Assurez-vous que le fichier `index.yaml` est accessible sans exigence d'authentification +- Assurez-vous que les fichiers `yaml` sont servis avec le type de contenu correct (`text/yaml` ou `text/x-yaml`) + +Par exemple, si vous souhaitez servir vos charts depuis `$WEBROOT/charts`, assurez-vous qu'il y a un répertoire `charts/` dans votre racine web, et placez le fichier d'index et les charts à l'intérieur de ce dossier. + +### Serveur de dépôt ChartMuseum + +ChartMuseum est un serveur de dépôt de charts Helm open-source écrit en Go (Golang), avec support pour des backends de stockage en cloud, incluant [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/), et [etcd](https://etcd.io/). + +Vous pouvez également utiliser le serveur [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) pour héberger un dépôt de charts à partir d'un système de fichiers local. + +### GitLab Package Registry + +Avec GitLab, vous pouvez publier des charts Helm dans le registre de packages de votre projet. Pour en savoir plus sur la configuration d'un dépôt de packages Helm avec GitLab, consultez [ce lien](https://docs.gitlab.com/ee/user/packages/helm_repository/). + +## Gestion des dépôts de charts + +Maintenant que vous avez un dépôt de charts, la dernière partie de ce guide explique comment maintenir les charts dans ce dépôt. + + +### Stocker des charts dans votre dépôt de charts + +Maintenant que vous avez un dépôt de charts, téléchargeons un chart et un fichier d'index dans le dépôt. Les charts dans un dépôt de charts doivent être empaquetés (`helm package chart-name/`) et correctement versionnés (en suivant les directives de [SemVer 2](https://semver.org/)). + +Ces prochaines étapes composent un exemple de workflow, mais vous êtes libre d'utiliser le workflow de votre choix pour stocker et mettre à jour les charts dans votre dépôt de charts. + +Une fois que vous avez un chart empaqueté prêt, créez un nouveau répertoire et déplacez votre chart empaqueté dans ce répertoire. + +```console +$ helm package docs/examples/alpine/ +$ mkdir fantastic-charts +$ mv alpine-0.1.0.tgz fantastic-charts/ +$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com +``` + +La dernière commande prend le chemin du répertoire local que vous venez de créer et l'URL de votre dépôt de charts distant, puis compose un fichier `index.yaml` à l'intérieur du répertoire spécifié. + +Vous pouvez maintenant télécharger le chart et le fichier d'index vers votre dépôt de charts en utilisant un outil de synchronisation ou manuellement. Si vous utilisez Google Cloud Storage, consultez cet [exemple de workflow]({{< ref "/docs/howto/chart_repository_sync_example.md" >}}) utilisant le client `gsutil`. Pour GitHub, vous pouvez simplement placer les charts dans la branche de destination appropriée. + +### Ajouter de nouveaux charts à un dépôt existant + +Chaque fois que vous souhaitez ajouter un nouveau chart à votre dépôt, vous devez régénérer l'index. La commande `helm repo index` reconstruira complètement le fichier `index.yaml` à partir de zéro, en incluant uniquement les charts qu'elle trouve localement. + +Cependant, vous pouvez utiliser l'option `--merge` pour ajouter progressivement de nouveaux charts à un fichier `index.yaml` existant (ce qui est une excellente option lorsque vous travaillez avec un dépôt distant comme GCS). Exécutez `helm repo index --help` pour en savoir plus. + +Assurez-vous de télécharger à la fois le fichier `index.yaml` révisé et le chart. Et si vous avez généré un fichier de provenance, téléchargez-le également. + +### Partager vos charts avec vos amis + +Lorsque vous êtes prêt à partager vos charts, informez simplement les autres de l'URL de votre dépôt. + +À partir de là, ils ajouteront le dépôt à leur client Helm via la commande `helm repo add [NOM] [URL]` avec le nom de leur choix pour faire référence au dépôt. + +```console +$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com +$ helm repo list +fantastic-charts https://fantastic-charts.storage.googleapis.com +``` + +Si les charts sont protégés par une authentification HTTP basique, vous pouvez également fournir le nom d'utilisateur et le mot de passe ici : + +```console +$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password +$ helm repo list +fantastic-charts https://fantastic-charts.storage.googleapis.com +``` + +**Remarque :** Un dépôt ne sera pas ajouté s'il ne contient pas un fichier `index.yaml` valide. + +**Remarque :** Si votre dépôt Helm utilise par exemple un certificat auto-signé, vous pouvez utiliser `helm repo add --insecure-skip-tls-verify ...` pour ignorer la vérification de l'autorité de certification (CA). + +Après cela, vos utilisateurs pourront rechercher parmi vos charts. Après avoir mis à jour le dépôt, ils pourront utiliser la commande `helm repo update` pour obtenir les dernières informations sur les charts. + +*En interne, les commandes `helm repo add` et `helm repo update` récupèrent le fichier `index.yaml` et les stockent dans le répertoire `$XDG_CACHE_HOME/helm/repository/cache/`. C'est là que la fonction `helm search` trouve les informations sur les charts.* diff --git a/content/fr/docs/topics/chart_tests.md b/content/fr/docs/topics/chart_tests.md new file mode 100644 index 000000000..fcf500cf6 --- /dev/null +++ b/content/fr/docs/topics/chart_tests.md @@ -0,0 +1,86 @@ +--- +title: "Tests de Chart" +description: "Décrit comment exécuter et tester vos charts" +weight: 3 +--- + +Un chart contient un certain nombre de ressources et de composants Kubernetes qui fonctionnent ensemble. En tant qu'auteur de chart, vous pouvez vouloir écrire des tests pour valider que votre chart fonctionne comme prévu lors de son installation. Ces tests aident également l'utilisateur du chart à comprendre ce que votre chart est censé faire. + +Un **test** dans un chart Helm se trouve dans le répertoire `templates/` et est une définition de job qui spécifie un conteneur avec une commande à exécuter. Le conteneur doit se terminer avec succès (exit 0) pour que le test soit considéré comme réussi. La définition du job doit contenir l'annotation du hook de test Helm : `helm.sh/hook: test`. + +Notez que jusqu'à Helm v3, la définition du job devait contenir l'une de ces annotations de hook de test : `helm.sh/hook: test-success` ou `helm.sh/hook: test-failure`. L'annotation `helm.sh/hook: test-success` est toujours acceptée comme alternative rétrocompatible à `helm.sh/hook: test`. + +Exemple de tests : + +- Valider que votre configuration du fichier values.yaml a été correctement injectée. + - Assurez-vous que votre nom d'utilisateur et mot de passe fonctionnent correctement. + - Vérifiez qu'un nom d'utilisateur ou mot de passe incorrect ne fonctionne pas. +- Vérifier que vos services sont actifs et assurent correctement l'équilibrage de charge. +- etc. + +Vous pouvez exécuter les tests prédéfinis dans Helm sur une release en utilisant la commande `helm test `. Pour l'utilisateur d'un chart, c'est un excellent moyen de vérifier que la release de son chart (ou application) fonctionne comme prévu. + +## Exemple de test + +La commande [helm create](/docs/helm/helm_create) créera automatiquement un certain nombre de dossiers et de fichiers. Pour essayer la fonctionnalité de test Helm, commencez par créer un chart Helm de démonstration. + +```console +$ helm create demo +``` + +Vous pourrez maintenant voir la structure suivante dans votre chart Helm de démonstration. + +``` +demo/ + Chart.yaml + values.yaml + charts/ + templates/ + templates/tests/test-connection.yaml +``` + +Dans `demo/templates/tests/test-connection.yaml`, vous trouverez un test que vous pouvez essayer. Vous pouvez voir la définition du pod de test Helm ici : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: "{{ include "demo.fullname" . }}-test-connection" + labels: + {{- include "demo.labels" . | nindent 4 }} + annotations: + "helm.sh/hook": test +spec: + containers: + - name: wget + image: busybox + command: ['wget'] + args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] + restartPolicy: Never + +``` + +## Étapes pour exécuter une suite de tests sur une release + +Tout d'abord, installez le chart sur votre cluster pour créer une release. Vous devrez peut-être attendre que tous les pods deviennent actifs ; si vous testez immédiatement après cette installation, il est probable que vous rencontriez un échec transitoire, et vous devrez refaire le test. + +```console +$ helm install demo demo --namespace default +$ helm test demo +NAME: demo +LAST DEPLOYED: Mon Feb 14 20:03:16 2022 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +TEST SUITE: demo-test-connection +Last Started: Mon Feb 14 20:35:19 2022 +Last Completed: Mon Feb 14 20:35:23 2022 +Phase: Succeeded +[...] +``` + +## Notes + +- Vous pouvez définir autant de tests que vous le souhaitez dans un seul fichier yaml ou les répartir dans plusieurs fichiers yaml dans le répertoire `templates/`. +- Vous êtes libre de regrouper votre suite de tests sous un répertoire `tests/`, comme `/templates/tests/`, pour une meilleure isolation. +- Un test est un [hook Helm](/docs/charts_hooks/), donc des annotations telles que `helm.sh/hook-weight` et `helm.sh/hook-delete-policy` peuvent être utilisées avec les ressources de test. diff --git a/content/fr/docs/topics/charts.md b/content/fr/docs/topics/charts.md new file mode 100644 index 000000000..be015e2a0 --- /dev/null +++ b/content/fr/docs/topics/charts.md @@ -0,0 +1,873 @@ +--- +title: "Charts" +description: "Explique le format des charts et fournit des conseils de base pour créer des charts avec Helm." +weight: 1 +--- + +Helm utilise un format de packaging appelé _charts_. Un chart est une collection de fichiers qui décrivent un ensemble de ressources Kubernetes liées. Un seul chart peut être utilisé pour déployer quelque chose de simple, comme un pod memcached, ou quelque chose de complexe, comme une pile d'application web complète avec serveurs HTTP, bases de données, caches, etc. + +Les charts sont créés sous forme de fichiers organisés dans un arbre de répertoires particulier. Ils peuvent être emballés dans des archives versionnées pour être déployés. + +Si vous souhaitez télécharger et consulter les fichiers d'un chart publié sans l'installer, vous pouvez le faire avec la commande `helm pull chartrepo/chartname`. + +Ce document explique le format des charts et fournit des conseils de base pour créer des charts avec Helm. + +## La structure des fichiers d'un chart + +Un chart est organisé comme une collection de fichiers dans un répertoire. Le nom du répertoire est le nom du chart (sans les informations de version). Ainsi, un chart décrivant WordPress serait stocké dans un répertoire `wordpress/`. + +À l'intérieur de ce répertoire, Helm s'attend à une structure qui correspond à ceci : + +```text +wordpress/ + Chart.yaml # Un fichier YAML qui contient les informations sur le charts + LICENSE # OPTIONNEL : Un fichier en texte brut contenant la licence du chart + README.md # OPTIONNEL : Un fichier README lisible par l'homme + values.yaml # Les valeurs de configuration par défaut pour ce chart + values.schema.json # OPTIONNEL : Un schéma JSON pour imposer une structure au fichier values.yaml + charts/ # Un répertoire contenant les charts dont ce chart dépend. + crds/ # Custom Resource Definitions + templates/ # Un répertoire de templates qui, combinés avec les valeurs, généreront des fichiers manifest Kubernetes valides. + templates/NOTES.txt # OPTIONNEL : Un fichier en texte brut contenant de courtes notes d'utilisation +``` + +Helm réserve l'utilisation des répertoires `charts/`, `crds/` et `templates/`, ainsi que des noms de fichiers listés. Les autres fichiers seront laissés tels quels. + +## Le fichier Chart.yaml + +Le fichier `Chart.yaml` est requis pour un chart. Il contient les champs suivants : + +```yaml +apiVersion: La version API du chart (requis) +name: Le nom du chart (requis) +version: Une version SemVer 2 (requis) +kubeVersion: Une plage de versions Kubernetes compatibles en SemVer (optionnel) +description: Une description en une phrase de ce projet (optionnel) +type: Le type du chart (optionnel) +keywords: + - Une liste de mots-clés concernant ce projet (optionnel) +home: L'URL de la page d'accueil de ce projet (optionnel) +sources: + - Une liste d'URLs vers le code source de ce projet (optionnel) +dependencies: # Une liste des dépendances du chart (optionnel) + - name: Le nom du chart (nginx) + version: La version du chart ("1.2.3") + repository: (optionnel) L'URL du dépôt ("https://example.com/charts") ou un alias ("@repo-name") + condition: (optionnel) Un chemin YAML qui résout en booléen, utilisé pour activer/désactiver des charts (ex. : subchart1.enabled) + tags: # (optionnel) + - Les tags peuvent être utilisés pour grouper les charts pour les activer/désactiver ensemble + import-values: # (optionnel) + - ImportValues contient le mappage des valeurs source vers la clé parente à importer. Chaque élément peut être une chaîne ou une paire d'éléments enfants/parents. + alias: (optionnel) Alias à utiliser pour le chart. Utile lorsque vous devez ajouter le même chart plusieurs fois +maintainers: # (optionnel) + - name: Le nom du mainteneur (requis pour chaque mainteneur) + email: L'email du mainteneur (optionnel pour chaque mainteneur) + url: Une URL pour le mainteneur (optionnel pour chaque mainteneur) +icon: Une URL vers une image SVG ou PNG à utiliser comme icône (optionnel) +appVersion: La version de l'application que ce chart contient (optionnel). N'a pas besoin d'être en SemVer. Les guillemets sont recommandés. +deprecated: Indique si ce chart est obsolète (optionnel, booléen) +annotations: + example: Une liste d'annotations avec des clés par nom (optionnel). +``` + +Depuis [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), les champs supplémentaires ne sont pas autorisés. L'approche recommandée est d'ajouter des métadonnées personnalisées dans `annotations`. + +### Charts et versionnage + +Chaque chart doit avoir un numéro de version. Une version doit suivre le standard [SemVer 2](https://semver.org/spec/v2.0.0.html). Contrairement à Helm Classic, Helm v2 et les versions ultérieures utilisent les numéros de version comme marqueurs de release. Les packages dans les dépôts sont identifiés par leur nom ainsi que leur version. + +Par exemple, un chart `nginx` dont le champ de version est défini sur `version: 1.2.3` sera nommé : + +```text +nginx-1.2.3.tgz +``` + +Des noms SemVer 2 plus complexes sont également pris en charge, tels que `version: 1.2.3-alpha.1+ef365`. Cependant, les noms non conformes à SemVer sont explicitement interdits par le système. + +**REMARQUE :** Alors que Helm Classic et Deployment Manager étaient très orientés GitHub pour les charts, Helm v2 et les versions ultérieures ne dépendent ni de GitHub ni de Git. Par conséquent, il n'utilise pas du tout les SHAs Git pour le versionnage. + +Le champ `version` à l'intérieur du fichier `Chart.yaml` est utilisé par de nombreux outils Helm, y compris la CLI. Lors de la génération d'un package, la commande `helm package` utilise la version trouvée dans le `Chart.yaml` comme jeton dans le nom du package. Le système suppose que le numéro de version dans le nom du package du chart correspond au numéro de version dans le `Chart.yaml`. Le non-respect de cette hypothèse entraînera une erreur. + +### Le champ `apiVersion` + +Le champ `apiVersion` doit être `v2` pour les charts Helm qui nécessitent au moins Helm 3. Les charts compatibles avec les versions précédentes de Helm ont un `apiVersion` défini sur `v1` et sont toujours installables par Helm 3. + +Changements de `v1` à `v2` : + +- Un champ `dependencies` définissant les dépendances du chart, qui étaient situées dans un fichier `requirements.yaml` séparé pour les charts `v1` (voir [Dépendances des Charts](#chart-dependencies)). +- Le champ `type`, discriminant les charts d'application et les charts de bibliothèque (voir [Types de Charts](#chart-types)). + +### Le champ `appVersion` + +Notez que le champ `appVersion` n'est pas lié au champ `version`. Il sert à spécifier la version de l'application. Par exemple, le chart `drupal` peut avoir un `appVersion: "8.2.1"`, ce qui indique que la version de Drupal incluse dans le chart (par défaut) est `8.2.1`. Ce champ est informatif et n'a aucun impact sur les calculs de version du chart. Il est fortement recommandé d'encapsuler la version entre guillemets. Cela force le parseur YAML à traiter le numéro de version comme une chaîne. Le fait de laisser la version sans guillemets peut entraîner des problèmes de parsing dans certains cas. Par exemple, YAML interprète `1.0` comme une valeur flottante, et un SHA de commit git comme `1234e10` comme une notation scientifique. + +Depuis Helm v3.5.0, `helm create` entoure le champ `appVersion` par défaut de guillemets. + +### Le champ `kubeVersion` + +Le champ optionnel `kubeVersion` peut définir des contraintes semver sur les versions Kubernetes prises en charge. Helm validera les contraintes de version lors de l'installation du chart et échouera si le cluster utilise une version de Kubernetes non supportée. + +Les contraintes de version peuvent comprendre des comparaisons AND séparées par des espaces, telles que +``` +>= 1.13.0 < 1.15.0 +``` +qui peuvent elles-mêmes être combinées avec l'opérateur OR `||`, comme dans l'exemple suivant +``` +>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 +``` +Dans cet exemple, la version `1.14.0` est exclue, ce qui peut être pertinent si un bug dans certaines versions est connu pour empêcher le bon fonctionnement du chart. + +Outre les contraintes de version utilisant les opérateurs `=`, `!=`, `>`, `<`, `>=`, `<=`, les notations abrégées suivantes sont prises en charge : + +* Plages par tiret pour les intervalles fermés, où `1.1 - 2.3.4` est équivalent à `>= 1.1 <= 2.3.4`. +* Caractères génériques `x`, `X` et `*`, où `1.2.x` est équivalent à `>= 1.2.0 < 1.3.0`. +* Plages avec tilde (changements de version de correctif autorisés), où `~1.2.3` est équivalent à `>= 1.2.3 < 1.3.0`. +* Plages avec caret (changements de version mineure autorisés), où `^1.2.3` est équivalent à `>= 1.2.3 < 2.0.0`. + +Pour une explication détaillée des contraintes semver prises en charge, consultez [Masterminds/semver](https://github.com/Masterminds/semver). + +### Dépréciation des Charts + +Lors de la gestion des charts dans un dépôt de charts, il est parfois nécessaire de déprécier un chart. Le champ optionnel `deprecated` dans `Chart.yaml` peut être utilisé pour marquer un chart comme déprécié. Si la **dernière** version d'un chart dans le dépôt est marquée comme dépréciée, alors le chart dans son ensemble est considéré comme déprécié. Le nom du chart peut être réutilisé ultérieurement en publiant une version plus récente qui n'est pas marquée comme dépréciée. Le flux de travail pour la dépréciation des charts est le suivant : + +1. Mettez à jour le `Chart.yaml` du chart pour marquer le chart comme déprécié, en augmentant la version. +2. Publiez la nouvelle version du chart dans le dépôt de charts. +3. Supprimez le chart du dépôt source (par exemple, git). + +### Types de Charts + +Le champ `type` définit le type de chart. Il y a deux types : `application` et `library`. `application` est le type par défaut et c'est le chart standard qui peut être entièrement utilisé. Le [chart de bibliothèque]({{}}) fournit des utilitaires ou des fonctions pour le constructeur de charts. Un chart de bibliothèque diffère d'un chart d'application car il n'est pas installable et ne contient généralement aucun objet de ressource. + +**Remarque :** Un chart d'application peut être utilisé comme un chart de bibliothèque. Cela est possible en définissant le type sur `library`. Le chart sera alors rendu comme un chart de bibliothèque où toutes les utilitaires et fonctions peuvent être utilisées. Tous les objets de ressource du chart ne seront pas rendus. + +## Licence, README et NOTES de Chart + +Les charts peuvent également contenir des fichiers qui décrivent l'installation, la configuration, l'utilisation et la licence d'un chart. + +Un fichier LICENSE est un fichier texte brut contenant la [licence](https://en.wikipedia.org/wiki/Software_license) du chart. Le chart peut contenir une licence car il peut avoir une logique de programmation dans les templates et ne serait donc pas uniquement une configuration. Il peut également y avoir des licences séparées pour l'application installée par le chart, si nécessaire. + +Un README pour un chart devrait être formaté en Markdown (README.md) et devrait généralement contenir : + +- Une description de l'application ou du service fourni par le chart +- Les prérequis ou les exigences pour exécuter le chart +- Descriptions des options dans `values.yaml` et des valeurs par défaut +- Toute autre information pertinente pour l'installation ou la configuration du chart + +Lorsque les hubs et autres interfaces utilisateur affichent des détails sur un chart, ces détails sont tirés du contenu du fichier `README.md`. + +Le chart peut également contenir un fichier `templates/NOTES.txt` en texte brut qui sera imprimé après l'installation et lors de la consultation du statut d'une release. Ce fichier est évalué comme un [template](#templates-and-values) et peut être utilisé pour afficher des notes d'utilisation, des étapes suivantes ou toute autre information pertinente pour une release du chart. Par exemple, des instructions pourraient être fournies pour se connecter à une base de données ou accéder à une interface web. Étant donné que ce fichier est imprimé sur STDOUT lors de l'exécution de `helm install` ou `helm status`, il est recommandé de garder le contenu bref et de renvoyer au README pour plus de détails. + +## Dépendances des Charts + +Dans Helm, un chart peut dépendre d'un certain nombre d'autres charts. Ces dépendances peuvent être liées dynamiquement à l'aide du champ `dependencies` dans `Chart.yaml` ou ajoutées manuellement dans le répertoire `charts/` et gérées manuellement. + +### Gestion des dépendances avec le champ `dependencies` + +Les charts requis par le chart actuel sont définis sous forme de liste dans le champ `dependencies`. + +```yaml +dependencies: + - name: apache + version: 1.2.3 + repository: https://example.com/charts + - name: mysql + version: 3.2.1 + repository: https://another.example.com/charts +``` + +- Le champ `name` correspond au nom du chart souhaité. +- Le champ `version` correspond à la version du chart souhaitée. +- Le champ `repository` correspond à l'URL complète du dépôt de charts. Notez que vous devez également utiliser `helm repo add` pour ajouter ce dépôt localement. +- Vous pouvez utiliser le nom du dépôt à la place de l'URL. + +```console +$ helm repo add fantastic-charts https://charts.helm.sh/incubator +``` + +```yaml +dependencies: + - name: awesomeness + version: 1.0.0 + repository: "@fantastic-charts" +``` + +Une fois que vous avez défini les dépendances, vous pouvez exécuter `helm dependency update` et cela utilisera votre fichier de dépendances pour télécharger tous les charts spécifiés dans votre répertoire `charts/`. + +```console +$ helm dep up foochart +Hang tight while we grab the latest from your chart repositories... +...Successfully got an update from the "local" chart repository +...Successfully got an update from the "stable" chart repository +...Successfully got an update from the "example" chart repository +...Successfully got an update from the "another" chart repository +Update Complete. Happy Helming! +Saving 2 charts +Downloading apache from repo https://example.com/charts +Downloading mysql from repo https://another.example.com/charts +``` + +Lorsque `helm dependency update` récupère des charts, il les stocke sous forme d'archives de charts dans le répertoire `charts/`. Ainsi, pour l'exemple ci-dessus, on s'attendrait à voir les fichiers suivants dans le répertoire `charts/` : + +```text +charts/ + apache-1.2.3.tgz + mysql-3.2.1.tgz +``` + +#### Champ Alias dans les dépendances + +En plus des autres champs mentionnés ci-dessus, chaque entrée de dépendance peut contenir le champ optionnel `alias`. + +Ajouter un alias pour un chart de dépendance permettrait de placer un chart dans les dépendances en utilisant l'alias comme nom de la nouvelle dépendance. + +On peut utiliser `alias` dans les cas où il est nécessaire d'accéder à un chart sous un ou plusieurs autres noms. + +```yaml +# chartparent/Chart.yaml + +dependencies: + - name: subchart + repository: http://localhost:10191 + version: 0.1.0 + alias: new-subchart-1 + - name: subchart + repository: http://localhost:10191 + version: 0.1.0 + alias: new-subchart-2 + - name: subchart + repository: http://localhost:10191 + version: 0.1.0 +``` + +Dans l'exemple ci-dessus, nous obtiendrons 3 dépendances au total pour `parentchart` : + +```text +subchart +new-subchart-1 +new-subchart-2 +``` + +La méthode manuelle pour y parvenir consiste à copier/coller le même chart plusieurs fois dans le répertoire `charts/` avec des noms différents. + +#### Champs Tags et Condition dans les dépendances + +En plus des autres champs mentionnés ci-dessus, chaque entrée de dépendance peut contenir les champs optionnels `tags` et `condition`. + +Tous les charts sont chargés par défaut. Si les champs `tags` ou `condition` sont présents, ils seront évalués et utilisés pour contrôler le chargement des charts auxquels ils sont appliqués. + +Condition - Le champ `condition` contient un ou plusieurs chemins YAML (séparés par des virgules). Si ce chemin existe dans les valeurs du chart parent et se résout en une valeur booléenne, le chart sera activé ou désactivé en fonction de cette valeur booléenne. Seul le premier chemin valide trouvé dans la liste est évalué, et si aucun chemin n'existe, le condition n'a aucun effet. + +Tags - Le champ `tags` est une liste YAML d'étiquettes à associer à ce chart. Dans les valeurs du chart parent, tous les charts avec des tags peuvent être activés ou désactivés en spécifiant le tag et une valeur booléenne. + +```yaml +# chartparent/Chart.yaml + +dependencies: + - name: subchart1 + repository: http://localhost:10191 + version: 0.1.0 + condition: subchart1.enabled,global.subchart1.enabled + tags: + - front-end + - subchart1 + - name: subchart2 + repository: http://localhost:10191 + version: 0.1.0 + condition: subchart2.enabled,global.subchart2.enabled + tags: + - back-end + - subchart2 +``` + +```yaml +# chartparent/values.yaml + +subchart1: + enabled: true +tags: + front-end: false + back-end: true +``` + +Dans l'exemple ci-dessus, tous les charts avec le tag `front-end` seraient désactivés, mais comme le chemin `subchart1.enabled` évalue à `true` dans les valeurs du parent, la condition annulera le tag `front-end` et `subchart1` sera activé. + +Étant donné que `subchart2` est étiqueté avec `back-end` et que ce tag évalue à `true`, `subchart2` sera activé. Notez également que bien que `subchart2` ait une condition spécifiée, il n'y a pas de chemin et de valeur correspondants dans les valeurs du parent, donc cette condition n'a aucun effet. + +##### Utilisation de la CLI avec les Tags et Conditions + +Le paramètre `--set` peut être utilisé comme d'habitude pour modifier les valeurs des tags et des conditions. + +```console +helm install --set tags.front-end=true --set subchart2.enabled=false +``` + +##### Résolution des Tags et des Conditions + +- **Les conditions (lorsqu'elles sont définies dans les valeurs) remplacent toujours les tags.** Le premier chemin de condition existant est pris en compte, et les suivants pour ce chart sont ignorés. +- Les tags sont évalués comme suit : "si l'un des tags du chart est vrai, alors activez le chart". +- Les valeurs des tags et des conditions doivent être définies dans les valeurs du chart parent. +- La clé `tags:` dans les valeurs doit être une clé de niveau supérieur. Les tables `tags:` globales et imbriquées ne sont pas actuellement prises en charge. + +#### Importation des Valeurs Enfants via les Dépendances + +Dans certains cas, il est souhaitable de permettre aux valeurs d'un chart enfant de se propager au chart parent et d'être partagées comme valeurs par défaut communes. Un avantage supplémentaire de l'utilisation du format `exports` est qu'il permettra aux outils futurs d'examiner les valeurs modifiables par l'utilisateur. + +Les clés contenant les valeurs à importer peuvent être spécifiées dans les dépendances du chart parent dans le champ `import-values` en utilisant une liste YAML. Chaque élément de la liste est une clé qui est importée depuis le champ `exports` du chart enfant. + +Pour importer des valeurs non contenues dans la clé `exports`, utilisez le format [child-parent](#using-the-child-parent-format). Des exemples des deux formats sont décrits ci-dessous. + +##### Utilisation du format `exports` + +Si le fichier `values.yaml` d'un chart enfant contient un champ `exports` à la racine, son contenu peut être importé directement dans les valeurs du parent en spécifiant les clés à importer comme dans l'exemple ci-dessous : + +```yaml +# fichier `Chart.yaml` du parent + +dependencies: + - name: subchart + repository: http://localhost:10191 + version: 0.1.0 + import-values: + - data +``` + +```yaml +# fichier `values.yaml` de l'enfant + +exports: + data: + myint: 99 +``` + +Puisque nous spécifions la clé `data` dans notre liste d'importation, Helm cherche dans le champ `exports` du chart enfant la clé `data` et importe son contenu. + +Les valeurs finales du parent contiendraient notre champ exporté : + +```yaml +# valeurs du parent + +myint: 99 +``` + +Veuillez noter que la clé `data` du parent n'est pas contenue dans les valeurs finales du parent. Si vous devez spécifier la clé du parent, utilisez le format `child-parent`. + +##### Utilisation du format enfant-parent + +Pour accéder aux valeurs qui ne sont pas contenues dans la clé `exports` des valeurs du chart enfant, vous devrez spécifier la clé source des valeurs à importer (`child`) et le chemin de destination dans les valeurs du chart parent (`parent`). + +Le champ `import-values` dans l'exemple ci-dessous indique à Helm de prendre toutes les valeurs trouvées au chemin `child:` et de les copier dans les valeurs du parent au chemin spécifié dans `parent:`. + +```yaml +# fichier Chart.yaml du parent + +dependencies: + - name: subchart1 + repository: http://localhost:10191 + version: 0.1.0 + ... + import-values: + - child: default.data + parent: myimports +``` + +Dans l'exemple ci-dessus, les valeurs trouvées à `default.data` dans les valeurs du `subchart1` seront importées sous la clé `myimports` dans les valeurs du chart parent comme détaillé ci-dessous : + +```yaml +# fichier values.yaml du parent + +myimports: + myint: 0 + mybool: false + mystring: "helm rocks!" +``` + +```yaml +# fichier values.yaml du souschart1 + +default: + data: + myint: 999 + mybool: true +``` + +Les valeurs résultantes du chart parent seraient : + +```yaml +# valeurs finales du parent + +myimports: + myint: 999 + mybool: true + mystring: "helm rocks!" +``` + +Les valeurs finales du parent contiennent désormais les champs `myint` et `mybool` importés du `souschart1`. + +### Gestion des dépendances manuellement via le répertoire charts/ + +Si un contrôle plus précis sur les dépendances est souhaité, ces dépendances peuvent être exprimées explicitement en copiant les charts de dépendance dans le répertoire `charts/`. + +Une dépendance doit être un répertoire de chart décompressé, mais son nom ne peut pas commencer par `_` ou `.`. De tels fichiers sont ignorés par le chargeur de charts. + +Par exemple, si le chart WordPress dépend du chart Apache, le chart Apache (de la version correcte) est fourni dans le répertoire `charts/` du chart WordPress : + +```yaml +wordpress: + Chart.yaml + # ... + charts/ + apache/ + Chart.yaml + # ... + mysql/ + Chart.yaml + # ... +``` + +L'exemple ci-dessus montre comment le chart WordPress exprime sa dépendance vis-à-vis d'Apache et de MySQL en incluant ces charts dans son répertoire `charts/`. + +**CONSEIL :** _Pour ajouter une dépendance dans votre répertoire `charts/`, utilisez la commande `helm pull`._ + +### Aspects opérationnels de l'utilisation des dépendances + +Les sections ci-dessus expliquent comment spécifier les dépendances des charts, mais comment cela affecte-t-il l'installation des charts avec `helm install` et `helm upgrade` ? + +Supposons qu'un chart nommé "A" crée les objets Kubernetes suivants : + +- namespace "A-Namespace" +- statefulset "A-StatefulSet" +- service "A-Service" + +De plus, A dépend du chart B qui crée les objets suivants : + +- namespace "B-Namespace" +- replicaset "B-ReplicaSet" +- service "B-Service" + +Après l'installation ou la mise à jour du chart A, une seule release Helm est créée ou modifiée. Cette release créera ou mettra à jour tous les objets Kubernetes ci-dessus dans l'ordre suivant : + +- A-Namespace +- B-Namespace +- A-Service +- B-Service +- B-ReplicaSet +- A-StatefulSet + +Cela est dû au fait que lorsque Helm installe ou met à jour des charts, les objets Kubernetes provenant des charts et de toutes ses dépendances sont : + +- agrégés en un seul ensemble ; +- triés par type puis par nom ; +- et enfin créés/mis à jour dans cet ordre. + +Ainsi, une seule release est créée avec tous les objets pour le chart et ses dépendances. + +L'ordre d'installation des types Kubernetes est défini par l'énumération `InstallOrder` dans le fichier `kind_sorter.go` (voir [le fichier source de Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). + +## Modèles et Valeurs + +Les modèles de Helm Chart sont écrits dans le [langage de modèles Go](https://golang.org/pkg/text/template/), avec l'ajout d'environ 50 fonctions de modèle supplémentaires [provenant de la bibliothèque Sprig](https://github.com/Masterminds/sprig) et quelques autres [fonctions spécialisées]({{< ref "/docs/howto/charts_tips_and_tricks.md" >}}). + +Tous les fichiers de modèles sont stockés dans le dossier `templates/` d'un chart. Lorsque Helm rend les charts, il passe chaque fichier de ce répertoire par le moteur de modèles. + +Les valeurs pour les modèles sont fournies de deux manières : + +- Les développeurs de charts peuvent fournir un fichier appelé `values.yaml` à l'intérieur d'un chart. Ce fichier peut contenir des valeurs par défaut. +- Les utilisateurs de charts peuvent fournir un fichier YAML contenant des valeurs. Cela peut être fourni en ligne de commande avec `helm install`. + +Lorsque l'utilisateur fournit des valeurs personnalisées, celles-ci remplaceront les valeurs du fichier `values.yaml` du chart. + +### Fichiers de modèles + +Les fichiers de modèles suivent les conventions standard pour l'écriture de modèles Go (voir [la documentation du package text/template Go](https://golang.org/pkg/text/template/) pour plus de détails). Un exemple de fichier de modèle pourrait ressembler à ceci : + +```yaml +apiVersion: v1 +kind: ReplicationController +metadata: + name: deis-database + namespace: deis + labels: + app.kubernetes.io/managed-by: deis +spec: + replicas: 1 + selector: + app.kubernetes.io/name: deis-database + template: + metadata: + labels: + app.kubernetes.io/name: deis-database + spec: + serviceAccount: deis-database + containers: + - name: deis-database + image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} + imagePullPolicy: {{ .Values.pullPolicy }} + ports: + - containerPort: 5432 + env: + - name: DATABASE_STORAGE + value: {{ default "minio" .Values.storage }} +``` + +L'exemple ci-dessus, basé librement sur [https://github.com/deis/charts](https://github.com/deis/charts), est un modèle pour un contrôleur de réplication Kubernetes. Il peut utiliser les quatre valeurs de modèle suivantes (généralement définies dans un fichier `values.yaml`) : + +- `imageRegistry` : Le registre source pour l'image Docker. +- `dockerTag` : Le tag pour l'image Docker. +- `pullPolicy` : La politique de récupération de Kubernetes. +- `storage` : Le backend de stockage, dont la valeur par défaut est `"minio"` + +Toutes ces valeurs sont définies par l'auteur du modèle. Helm ne nécessite ni ne dicte de paramètres. + +Pour voir de nombreux charts fonctionnels, consultez le [CNCF Artifact Hub](https://artifacthub.io/packages/search?kind=0). + +### Valeurs prédéfinies + +Les valeurs fournies via un fichier `values.yaml` (ou via l'option `--set`) sont accessibles depuis l'objet `.Values` dans un modèle. Mais il y a d'autres données prédéfinies auxquelles vous pouvez accéder dans vos modèles. + +Les valeurs suivantes sont prédéfinies, disponibles dans chaque modèle et ne peuvent pas être remplacées. Comme pour toutes les valeurs, les noms sont _sensibles à la casse_. + +- `Release.Name` : Le nom de la release (et non du chart). +- `Release.Namespace` : Le namespace dans lequel le chart a été déployé. +- `Release.Service` : Le service qui a réalisé la release. +- `Release.IsUpgrade` : Cela est défini sur `true` si l'opération actuelle est une mise à niveau ou un retour en arrière. +- `Release.IsInstall` : Cela est défini sur `true` si l'opération actuelle est une installation. +- `Chart` : Le contenu du fichier `Chart.yaml`. Ainsi, la version du chart est obtenable avec `Chart.Version` et les mainteneurs sont dans `Chart.Maintainers`. +- `Files` : Un objet de type map contenant tous les fichiers non spéciaux dans le chart. Cela ne vous donnera pas accès aux modèles, mais vous permettra d'accéder à des fichiers supplémentaires présents (sauf s'ils sont exclus via `.helmignore`). Les fichiers peuvent être accédés en utilisant `{{ index .Files "file.name" }}` ou la fonction `{{.Files.Get name }}`. Vous pouvez également accéder au contenu du fichier en tant que `[]byte` en utilisant `{{ .Files.GetBytes }}` +- `Capabilities` : Un objet de type map contenant des informations sur les versions de Kubernetes (`{{ .Capabilities.KubeVersion }}`) et les versions API Kubernetes prises en charge (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) + +**REMARQUE :** Tout champ inconnu dans `Chart.yaml` sera ignoré. Ils ne seront pas accessibles à l'intérieur de l'objet `Chart`. Ainsi, `Chart.yaml` ne peut pas être utilisé pour passer des données structurées arbitraires dans le modèle. En revanche, le fichier de valeurs peut être utilisé à cette fin. + +### Fichiers de valeurs + +En considérant le modèle de la section précédente, un fichier `values.yaml` qui fournit les valeurs nécessaires pourrait ressembler à ceci : + +```yaml +imageRegistry: "quay.io/deis" +dockerTag: "latest" +pullPolicy: "Always" +storage: "s3" +``` + +Un fichier de valeurs est formaté en YAML. Un chart peut inclure un fichier `values.yaml` par défaut. La commande d'installation de Helm permet à un utilisateur de remplacer les valeurs en fournissant des valeurs YAML supplémentaires : + +```console +$ helm install --generate-name --values=myvals.yaml wordpress +``` + +Lorsque les valeurs sont passées de cette manière, elles seront fusionnées avec le fichier de valeurs par défaut. Par exemple, considérez un fichier `myvals.yaml` qui ressemble à ceci : + +```yaml +storage: "gcs" +``` + +Lorsque cela est fusionné avec le fichier `values.yaml` dans le chart, le contenu généré résultant sera : + +```yaml +imageRegistry: "quay.io/deis" +dockerTag: "latest" +pullPolicy: "Always" +storage: "gcs" +``` + +Notez que seul le dernier champ a été remplacé. + +**REMARQUE :** Le fichier de valeurs par défaut inclus à l'intérieur d'un chart _doit_ être nommé `values.yaml`. Mais les fichiers spécifiés en ligne de commande peuvent avoir n'importe quel nom. + +**REMARQUE :** Si l'option `--set` est utilisée avec `helm install` ou `helm upgrade`, ces valeurs sont simplement converties en YAML côté client. + +**REMARQUE :** Si des entrées requises dans le fichier de valeurs existent, elles peuvent être déclarées comme requises dans le modèle de chart en utilisant la fonction ['required']({{}}) + +Chacune de ces valeurs est ensuite accessible à l'intérieur des modèles en utilisant l'objet `.Values` : + +```yaml +apiVersion: v1 +kind: ReplicationController +metadata: + name: deis-database + namespace: deis + labels: + app.kubernetes.io/managed-by: deis +spec: + replicas: 1 + selector: + app.kubernetes.io/name: deis-database + template: + metadata: + labels: + app.kubernetes.io/name: deis-database + spec: + serviceAccount: deis-database + containers: + - name: deis-database + image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} + imagePullPolicy: {{ .Values.pullPolicy }} + ports: + - containerPort: 5432 + env: + - name: DATABASE_STORAGE + value: {{ default "minio" .Values.storage }} +``` + +### Portée, Dépendances et Valeurs + +Les fichiers de valeurs peuvent déclarer des valeurs pour le chart de niveau supérieur, ainsi que pour tous les charts inclus dans le répertoire `charts/` de ce chart. Autrement dit, un fichier de valeurs peut fournir des valeurs au chart ainsi qu'à ses dépendances. Par exemple, le chart WordPress de démonstration ci-dessus a à la fois `mysql` et `apache` comme dépendances. Le fichier de valeurs pourrait fournir des valeurs à tous ces composants : + +```yaml +title: "Mon Site Wordpress" # Envoyé au modèle WordPress + +mysql: + max_connections: 100 # Envoyé à MySQL + password: "secret" + +apache: + port: 8080 # Passé à Apache +``` + +Les charts de niveau supérieur ont accès à toutes les variables définies en dessous. Ainsi, le chart WordPress peut accéder au mot de passe MySQL via `.Values.mysql.password`. En revanche, les charts de niveau inférieur ne peuvent pas accéder aux éléments des charts parents, donc MySQL ne pourra pas accéder à la propriété `title`. De même, il ne pourra pas accéder à `apache.port`. + +Les valeurs sont nommées par espace de noms, mais les espaces de noms sont réduits. Ainsi, pour le chart WordPress, il peut accéder au champ du mot de passe MySQL en tant que `.Values.mysql.password`. Mais pour le chart MySQL, la portée des valeurs a été réduite et le préfixe de l'espace de noms supprimé, donc il verra le champ du mot de passe simplement comme `.Values.password`. + +#### Valeurs globales + +Depuis la version 2.0.0-Alpha.2, Helm prend en charge une valeur spéciale appelée "global". Considérons cette version modifiée de l'exemple précédent : + +```yaml +title: "Mon Site Wordpress" # Envoyé au modèle WordPress + +global: + app: MyWordPress + +mysql: + max_connections: 100 # Envoyé à MySQL + password: "secret" + +apache: + port: 8080 # Passé à Apache +``` + +L'exemple ci-dessus ajoute une section `global` avec la valeur `app: MyWordPress`. Cette valeur est disponible pour _tous_ les charts sous la forme `.Values.global.app`. + +Par exemple, les modèles `mysql` peuvent accéder à `app` en utilisant `{{ .Values.global.app }}`, tout comme le chart `apache`. Effectivement, le fichier de valeurs ci-dessus est régénéré comme ceci : + +```yaml +title: "Mon Site Wordpress" # Envoyé au modèle WordPress + +global: + app: MyWordPress + +mysql: + global: + app: MyWordPress + max_connections: 100 # Envoyé à MySQL + password: "secret" + +apache: + global: + app: MyWordPress + port: 8080 # Passé à Apache +``` + +Cela permet de partager une variable de niveau supérieur avec tous les sous-charts, ce qui est utile pour des éléments tels que la définition de propriétés `metadata` comme les labels. + +Si un sous-chart déclare une variable globale, cette variable sera transmise _vers le bas_ (aux sous-charts du sous-chart), mais pas _vers le haut_ au chart parent. Il n'existe aucun moyen pour un sous-chart d'influencer les valeurs du chart parent. + +De plus, les variables globales des charts parents prennent le pas sur les variables globales des sous-charts. + +### Fichiers de Schéma + +Parfois, un mainteneur de chart peut vouloir définir une structure pour ses valeurs. Cela peut être fait en définissant un schéma dans le fichier `values.schema.json`. Un schéma est représenté sous la forme d'un [Schéma JSON](https://json-schema.org/). Il pourrait ressembler à ceci : + +```json +{ + "$schema": "https://json-schema.org/draft-07/schema#", + "properties": { + "image": { + "description": "Container Image", + "properties": { + "repo": { + "type": "string" + }, + "tag": { + "type": "string" + } + }, + "type": "object" + }, + "name": { + "description": "Service name", + "type": "string" + }, + "port": { + "description": "Port", + "minimum": 0, + "type": "integer" + }, + "protocol": { + "type": "string" + } + }, + "required": [ + "protocol", + "port" + ], + "title": "Values", + "type": "object" +} +``` + +Ce schéma sera appliqué aux valeurs pour les valider. La validation se produit lorsque l'une des commandes suivantes est invoquée : + +- `helm install` +- `helm upgrade` +- `helm lint` +- `helm template` + +Un exemple de fichier `values.yaml` qui respecte les exigences de ce schéma pourrait ressembler à ceci : + +```yaml +name: frontend +protocol: https +port: 443 +``` + +Notez que le schéma est appliqué à l'objet final `.Values`, et non seulement au fichier `values.yaml`. Cela signifie que le fichier `yaml` suivant est valide, à condition que le chart soit installé avec l'option `--set` appropriée, comme indiqué ci-dessous. + +```yaml +name: frontend +protocol: https +``` + +```console +helm install --set port=443 +``` + +De plus, l'objet final `.Values` est vérifié par rapport à *tous* les schémas des sous-charts. Cela signifie que les restrictions d'un sous-chart ne peuvent pas être contournées par un chart parent. Cela fonctionne également dans l'autre sens : si un sous-chart a une exigence qui n'est pas respectée dans son fichier `values.yaml`, le chart parent *doit* satisfaire à ces restrictions pour être valide. + +### Références + +En ce qui concerne l'écriture de modèles, de valeurs et de fichiers de schéma, il existe plusieurs références standard qui peuvent vous aider. + +- [Templates Go](https://godoc.org/text/template) +- [Fonctions supplémentaires pour les modèles](https://godoc.org/github.com/Masterminds/sprig) +- [Le format YAML](https://yaml.org/spec/) +- [Schéma JSON](https://json-schema.org/) + +## Définitions de Ressources Personnalisées (CRDs) + +Kubernetes fournit un mécanisme pour déclarer de nouveaux types d'objets Kubernetes. En utilisant les CustomResourceDefinitions (CRD), les développeurs Kubernetes peuvent déclarer des types de ressources personnalisées. + +Dans Helm 3, les CRD (Custom Resource Definitions) sont considérés comme un type spécial d'objet. Ils sont installés avant le reste du chart et sont soumis à certaines limitations. + +Les fichiers YAML des CRD doivent être placés dans le répertoire `crds/` à l'intérieur d'un chart. Plusieurs CRD (séparées par des marqueurs de début et de fin YAML) peuvent être placées dans le même fichier. Helm tentera de charger _tous_ les fichiers du répertoire CRD dans Kubernetes. + +Les fichiers de CRD _ne peuvent pas être modélisés_. Ils doivent être de simple documents YAML. + +Lorsque Helm installe un nouveau chart, il télécharge les CRD, fait une pause jusqu'à ce que les CRD soient disponibles via le serveur API, puis démarre le moteur de modèles, rend le reste du chart et le télécharge dans Kubernetes. En raison de cet ordre, les informations sur les CRD sont disponibles dans l'objet `.Capabilities` des modèles Helm, et les modèles Helm peuvent créer de nouvelles instances d'objets déclarés dans les CRD. + +Par exemple, si votre chart avait une CRD pour `CronTab` dans le répertoire `crds/`, vous pouvez créer des instances du type `CronTab` dans le répertoire `templates/` : + +```text +crontabs/ + Chart.yaml + crds/ + crontab.yaml + templates/ + mycrontab.yaml +``` + +Le fichier `crontab.yaml` doit contenir la CRD sans directives de modèle : + +```yaml +kind: CustomResourceDefinition +metadata: + name: crontabs.stable.example.com +spec: + group: stable.example.com + versions: + - name: v1 + served: true + storage: true + scope: Namespaced + names: + plural: crontabs + singular: crontab + kind: CronTab +``` + +Ensuite, le modèle `mycrontab.yaml` peut créer un nouveau `CronTab` (en utilisant des modèles comme d'habitude) : + +```yaml +apiVersion: stable.example.com +kind: CronTab +metadata: + name: {{ .Values.name }} +spec: + # ... +``` + +Helm s'assurera que le type `CronTab` a été installé et est disponible depuis le serveur API Kubernetes avant de procéder à l'installation des éléments dans `templates/`. + +### Limitations sur les CRDs + +Contrairement à la plupart des objets dans Kubernetes, les CRD sont installées globalement. Pour cette raison, Helm adopte une approche très prudente dans la gestion des CRD. Les CRD sont soumises aux limitations suivantes : + +- Les CRD ne sont jamais réinstallées. Si Helm détermine que les CRD dans le répertoire `crds/` sont déjà présentes (indépendamment de la version), Helm ne tentera pas de les installer ou de les mettre à niveau. +- Les CRD ne sont jamais installées lors d'une mise à niveau ou d'un retour en arrière. Helm ne créera des CRD que lors des opérations d'installation. +- Les CRD ne sont jamais supprimées. La suppression d'une CRD supprime automatiquement tout le contenu de la CRD dans tous les namespaces du cluster. Par conséquent, Helm ne supprimera pas les CRD. + +Les opérateurs qui souhaitent mettre à niveau ou supprimer des CRD sont encouragés à le faire manuellement et avec une grande prudence. + +## Utiliser Helm pour gérer les Charts + +L'outil `helm` dispose de plusieurs commandes pour travailler avec les charts. + +Il peut créer un nouveau chart pour vous : + +```console +$ helm create mychart +Created mychart/ +``` + +Une fois que vous avez modifié un chart, `helm` peut l'emballer dans une archive de chart pour vous : + +```console +$ helm package mychart +Archived mychart-0.1.-.tgz +``` + +Vous pouvez également utiliser `helm` pour vous aider à trouver des problèmes avec le formatage ou les informations de votre chart : + +```console +$ helm lint mychart +No issues found +``` + +## Dépôts de Charts + +Un _dépôt de charts_ est un serveur HTTP qui héberge un ou plusieurs charts emballés. Bien que `helm` puisse être utilisé pour gérer des répertoires de charts locaux, le mécanisme préféré pour partager des charts est un dépôt de charts. + +Tout serveur HTTP capable de servir des fichiers YAML et des fichiers tar, et de répondre aux requêtes GET, peut être utilisé comme serveur de dépôt. L'équipe Helm a testé certains serveurs, y compris Google Cloud Storage avec le mode site Web activé, et S3 avec le mode site Web activé. + +Un dépôt est principalement caractérisé par la présence d'un fichier spécial appelé `index.yaml`, qui contient une liste de tous les packages fournis par le dépôt, ainsi que des métadonnées permettant de récupérer et de vérifier ces packages. + +Côté client, les dépôts sont gérés avec les commandes `helm repo`. Cependant, Helm ne fournit pas d'outils pour télécharger des charts sur des serveurs de dépôt distants. En effet, cela imposerait des exigences substantielles au serveur de dépôt, augmentant ainsi la difficulté de mise en place d'un dépôt. + +## Packs de démarrage de Charts + +La commande `helm create` prend une option `--starter` facultative qui vous permet de spécifier un "chart de démarrage". De plus, l'option de démarrage a un alias court `-p`. + +Exemple d'utilisation : + +```console +helm create my-chart --starter starter-name +helm create my-chart -p starter-name +helm create my-chart -p /absolute/path/to/starter-name +``` + +Les starters sont simplement des charts réguliers, mais situés dans `$XDG_DATA_HOME/helm/starters`. En tant que développeur de charts, vous pouvez créer des charts spécifiquement conçus pour être utilisés comme starters. Ces charts doivent être conçus en tenant compte des considérations suivantes : + +- Le fichier `Chart.yaml` sera écrasé par le générateur. +- Les utilisateurs s'attendront à modifier le contenu d'un tel chart, donc la documentation doit indiquer comment les utilisateurs peuvent le faire. +- Toutes les occurrences de `` seront remplacées par le nom du chart spécifié afin que les charts de démarrage puissent être utilisés comme modèles, à l'exception de certains fichiers de variables. Par exemple, si vous utilisez des fichiers personnalisés dans le répertoire `vars` ou certains fichiers `README.md`, `` ne sera PAS remplacé à l'intérieur de ceux-ci. De plus, la description du chart n'est pas héritée. + +Actuellement, la seule façon d'ajouter un chart à `$XDG_DATA_HOME/helm/starters` est de le copier manuellement à cet emplacement. Dans la documentation de votre chart, vous pourriez vouloir expliquer ce processus. diff --git a/content/fr/docs/topics/charts_hooks.md b/content/fr/docs/topics/charts_hooks.md new file mode 100644 index 000000000..ae467842f --- /dev/null +++ b/content/fr/docs/topics/charts_hooks.md @@ -0,0 +1,155 @@ +--- +title: "Les Hooks de Chart" +description: "Décrit comment travailler avec les hooks de chart" +weight: 2 +--- + +Helm fournit un mécanisme de _hook_ permettant aux développeurs de charts d'intervenir à certains moments du cycle de vie d'une release. Par exemple, vous pouvez utiliser des hooks pour : + +- Charger un ConfigMap ou un Secret lors de l'installation avant que d'autres charts ne soient chargés. +- Exécuter un Job pour sauvegarder une base de données avant d'installer un nouveau chart, puis exécuter un deuxième job après la mise à niveau afin de restaurer les données. +- Exécuter un Job avant de supprimer une release pour retirer un service de manière ordonnée avant de le supprimer. + +Les hooks fonctionnent comme des templates réguliers, mais ils ont des annotations spéciales qui font que Helm les utilise différemment. Dans cette section, nous couvrons le modèle d'utilisation de base des hooks. + +## Les Hooks disponibles + +Les hooks suivants sont définis : + +| Valeur de l'annotation | Description | +| ---------------------- | -------------------------------------------------------------------------------------------------------------------- | +| `pre-install` | S'exécute après le rendu des templates, mais avant que les ressources ne soient créées dans Kubernetes | +| `post-install` | S'exécute après que toutes les ressources aient été chargées dans Kubernetes | +| `pre-delete` | S'exécute lors d'une demande de suppression avant que les ressources ne soient supprimées de Kubernetes | +| `post-delete` | S'exécute lors d'une demande de suppression après que toutes les ressources de la release aient été supprimées | +| `pre-upgrade` | S'exécute lors d'une demande de mise à niveau après le rendu des templates, mais avant la mise à jour des ressources | +| `post-upgrade` | S'exécute après la mise à jour de toutes les ressources | +| `pre-rollback` | S'exécute lors d'une demande de restauration après le rendu des templates, mais avant la restauration des ressources | +| `post-rollback` | S'exécute après que toutes les ressources aient été modifiées lors d'une restauration | +| `test` | S'exécute lorsque la sous-commande de test Helm est invoquée ([voir la documentation des tests](/docs/chart_tests/)) | + +_Remarquez que le hook `crd-install` a été supprimé au profit du répertoire `crds/` dans Helm 3._ + +## Les hooks et le cycle de vie d'une release + +Les hooks vous permettent, en tant que développeur de chart, d'effectuer des opérations à des points stratégiques du cycle de vie d'une release. Par exemple, considérons le cycle de vie d'une `helm install`. Par défaut, le cycle de vie ressemble à ceci : + +1. L'utilisateur exécute `helm install foo` +2. L'API d'installation de la bibliothèque Helm est appelée +3. Après une vérification, la bibliothèque rend les templates de `foo` +4. La bibliothèque charge les ressources résultantes dans Kubernetes +5. La bibliothèque retourne l'objet de la release (et d'autres données) au client +6. Le client se termine + +Helm définit deux hooks pour le cycle de vie de `install` : `pre-install` et `post-install`. Si le développeur du chart `foo` implémente les deux hooks, le cycle de vie est modifié comme suit : + +1. L'utilisateur exécute `helm install foo` +2. L'API d'installation de la bibliothèque Helm est appelée +3. Les CRD dans le répertoire `crds/` sont installées +4. Après vérification, la bibliothèque rend les templates de `foo` +5. La bibliothèque se prépare à exécuter les hooks `pre-install` (chargement des ressources de hook dans Kubernetes) +6. La bibliothèque trie les hooks par poids (attribuant un poids de 0 par défaut), par type de ressource et enfin par nom en ordre croissant +7. La bibliothèque charge ensuite le hook avec le poids le plus bas en premier (de négatif à positif) +8. La bibliothèque attend que le hook soit "prêt" (à l'exception des CRD) +9. La bibliothèque charge les ressources résultantes dans Kubernetes. Notez que si le drapeau `--wait` est défini, la bibliothèque attendra que toutes les ressources soient dans un état prêt et ne exécutera pas le hook `post-install` tant qu'elles ne sont pas prêtes. +10. La bibliothèque exécute le hook `post-install` (chargement des ressources de hook) +11. La bibliothèque attend que le hook soit "prêt" +12. La bibliothèque retourne l'objet de la release (et d'autres données) au client +13. Le client se termine + +Qu'est-ce que cela signifie d'attendre qu'un hook soit prêt ? Cela dépend du type de ressource déclaré dans le hook. Si la ressource est de type `Job` ou `Pod`, Helm attendra jusqu'à ce qu'elle s'exécute avec succès jusqu'à son terme. Et si le hook échoue, la release échouera. Il s'agit d'une _opération bloquante_, donc le client Helm se mettra en pause pendant que le Job est exécuté. + +Pour tous les autres types, dès que Kubernetes marque la ressource comme chargée (ajoutée ou mise à jour), la ressource est considérée comme "prête". Lorsque plusieurs ressources sont déclarées dans un hook, elles sont exécutées de manière séquentielle. Si elles ont des poids de hook (voir ci-dessous), elles sont exécutées dans l'ordre des poids. + +À partir de Helm 3.2.0, les ressources de hook ayant le même poids sont installées dans le même ordre que les ressources non-hook normales. Sinon, l'ordre n'est pas garanti. (Dans Helm 2.3.0 et versions ultérieures, elles étaient triées par ordre alphabétique. Ce comportement n'est pas considéré comme contraignant et pourrait changer à l'avenir.) Il est considéré comme une bonne pratique d'ajouter un poids de hook et de le définir à 0 si le poids n'est pas important. + +### Les ressources de hook ne sont pas gérées avec les releases correspondantes + +Les ressources créées par un hook ne sont actuellement pas suivies ni gérées dans le cadre de la release. Une fois que Helm vérifie que le hook a atteint son état prêt, il laissera la ressource de hook telle quelle. La collecte des ressources de hook lors de la suppression de la release correspondante pourrait être ajoutée à Helm 3 à l'avenir, donc toute ressource de hook qui ne doit jamais être supprimée doit être annotée avec `helm.sh/resource-policy: keep`. + +En pratique, cela signifie que si vous créez des ressources dans un hook, vous ne pouvez pas compter sur `helm uninstall` pour supprimer les ressources. Pour détruire ces ressources, vous devez soit [ajouter une annotation personnalisée `helm.sh/hook-delete-policy`](#hook-deletion-policies) au fichier template du hook, soit [définir le champ de durée de vie (TTL) d'une ressource Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). + +## Écrire un Hook + +Les hooks sont simplement des fichiers de manifeste Kubernetes avec des annotations spéciales dans la section `metadata`. Étant donné qu'ils sont des fichiers de template, vous pouvez utiliser toutes les fonctionnalités de template normales, y compris la lecture de `.Values`, `.Release`, et `.Template`. + +Par exemple, ce template, stocké dans `templates/post-install-job.yaml`, déclare un job à exécuter lors du `post-install` : + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: "{{ .Release.Name }}" + labels: + app.kubernetes.io/managed-by: {{ .Release.Service | quote }} + app.kubernetes.io/instance: {{ .Release.Name | quote }} + app.kubernetes.io/version: {{ .Chart.AppVersion }} + helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" + annotations: + # C'est ce qui définit cette ressource comme un hook. Sans cette ligne, le + # job est considéré comme faisant partie de la release. + "helm.sh/hook": post-install + "helm.sh/hook-weight": "-5" + "helm.sh/hook-delete-policy": hook-succeeded +spec: + template: + metadata: + name: "{{ .Release.Name }}" + labels: + app.kubernetes.io/managed-by: {{ .Release.Service | quote }} + app.kubernetes.io/instance: {{ .Release.Name | quote }} + helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" + spec: + restartPolicy: Never + containers: + - name: post-install-job + image: "alpine:3.3" + command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] + +``` + +Ce qui rend ce template un hook est l'annotation : + +```yaml +annotations: + "helm.sh/hook": post-install +``` + +Une ressource peut implémenter plusieurs hooks : + +```yaml +annotations: + "helm.sh/hook": post-install,post-upgrade +``` + +De même, il n'y a pas de limite au nombre de ressources différentes qui peuvent implémenter un hook donné. Par exemple, on pourrait déclarer à la fois un secret et une config map comme un hook `pre-install`. + +Lorsque les sous-charts déclarent des hooks, ceux-ci sont également évalués. Il n'est pas possible pour un chart de niveau supérieur de désactiver les hooks déclarés par les sous-charts. + +Il est possible de définir un poids pour un hook, ce qui aidera à établir un ordre d'exécution déterministe. Les poids sont définis à l'aide de l'annotation suivante : + +```yaml +annotations: + "helm.sh/hook-weight": "5" +``` + +Les poids des hooks peuvent être des nombres positifs ou négatifs mais doivent être représentés sous forme de chaînes de caractères. Lorsque Helm commence le cycle d'exécution des hooks d'un type particulier, il triera ces hooks par ordre croissant. + +### Politiques de suppression des hooks + +Il est possible de définir des politiques qui déterminent quand supprimer les ressources de hook correspondantes. Les politiques de suppression des hooks sont définies à l'aide de l'annotation suivante : + +```yaml +annotations: + "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded +``` + +Vous pouvez choisir une ou plusieurs valeurs d'annotation définies : + +| Valeur d'annotation | Description | +| ----------------------- | ----------------------------------------------------------------------- | +| `before-hook-creation` | Supprimer la ressource précédente avant qu'un nouveau hook ne soit lancé (par défaut) | +| `hook-succeeded` | Supprimer la ressource après l'exécution réussie du hook | +| `hook-failed` | Supprimer la ressource si le hook a échoué pendant l'exécution | + +Si aucune politique de suppression de hook n'est spécifiée, le comportement `before-hook-creation` s'applique par défaut.. diff --git a/content/fr/docs/topics/kubernetes_apis.md b/content/fr/docs/topics/kubernetes_apis.md new file mode 100644 index 000000000..8a78e80b6 --- /dev/null +++ b/content/fr/docs/topics/kubernetes_apis.md @@ -0,0 +1,93 @@ +--- +title: "APIs Kubernetes obsolètes" +description: "Explique les APIs Kubernetes obsolètes dans Helm" +--- + +Kubernetes est un système piloté par des API, et ces dernières évoluent au fil du temps pour refléter la compréhension en constante évolution du domaine des problèmes. Cette pratique est courante dans les systèmes et leurs API. Un élément important de l'évolution des API est d'avoir une bonne politique et un processus de dépréciation pour informer les utilisateurs des changements apportés aux API. En d'autres termes, les consommateurs de votre API doivent être informés à l'avance de la version dans laquelle une API sera supprimée ou modifiée. Cela élimine l'effet de surprise et les modifications disruptives pour les utilisateurs. + +La [politique de dépréciation de Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) documente comment Kubernetes gère les modifications de ses versions d'API. Cette politique précise le délai pendant lequel les versions d'API seront prises en charge après une annonce de dépréciation. Il est donc important de rester attentif aux annonces de dépréciation et de savoir quand les versions d'API seront supprimées, afin de minimiser l'impact. + +Voici un exemple d'annonce [pour la suppression des versions d'API obsolètes dans Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/), qui a été publiée quelques mois avant la sortie. Ces versions d'API avaient déjà été annoncées comme dépréciées auparavant. Cela montre qu'il existe une bonne politique en place pour informer les utilisateurs du support des versions d'API. + +Les templates Helm spécifient un [groupe d'API Kubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) lors de la définition d'un objet Kubernetes, de manière similaire à un fichier manifeste Kubernetes. Il est indiqué dans le champ `apiVersion` du template et identifie la version de l'API de l'objet Kubernetes. Cela signifie que les utilisateurs de Helm et les mainteneurs de chart doivent être conscients des versions d'API Kubernetes qui ont été dépréciées et de la version de Kubernetes dans laquelle elles seront supprimées. + +## Mainteneurs de chart + +Vous devez auditer vos charts en vérifiant les versions d'API Kubernetes qui sont dépréciées ou supprimées dans une version de Kubernetes. Les versions d'API qui ne sont plus prises en charge ou qui sont sur le point de l'être doivent être mises à jour vers une version prise en charge, et une nouvelle version du chart doit être publiée. La version de l'API est définie par les champs `kind` et `apiVersion`. Par exemple, voici une version de l'API de l'objet `Deployment` supprimée dans Kubernetes 1.16 : + +```yaml +apiVersion: apps/v1beta1 +kind: Deployment +``` + +## Utilisateurs de Helm + +Vous devez auditer les charts que vous utilisez (de manière similaire aux [mainteneurs de chart](#mainteneurs-de-chart) et identifier ceux pour lesquels les versions d'API sont dépréciées ou supprimées dans une version de Kubernetes. Pour les charts identifiés, vous devez vérifier la dernière version du chart (qui a des versions d'API prises en charge) ou mettre à jour le chart vous-même. + +De plus, vous devez également auditer les charts déployés (c'est-à-dire les releases Helm) en vérifiant à nouveau les versions d'API dépréciées ou supprimées. Cela peut être fait en obtenant les détails d'une release en utilisant la commande `helm get manifest`. + +Les moyens de mettre à jour une release Helm vers des APIs prises en charge dépendent de vos constations sont les suivants : + +1. Si vous trouvez uniquement des versions d'API dépréciées : + - Effectuez une `helm upgrade` avec une version du chart contenant des versions d'API Kubernetes prises en charge. + - Ajoutez une description lors de la mise à niveau, précisant de ne pas effectuer de rollback vers une version Helm antérieure à cette version actuelle. + +2. Si vous trouvez une ou plusieurs versions d'API qui sont supprimées dans une version de Kubernetes : + - Si vous utilisez une version de Kubernetes où les versions d'API sont encore disponibles (par exemple, vous êtes sur Kubernetes 1.15 et vous avez trouvé que vous utilisez des APIs qui seront supprimées dans Kubernetes 1.16) : + - Suivez la procédure de l'étape 1. + - Sinon (par exemple, vous utilisez déjà une version de Kubernetes où certaines versions d'API signalées par `helm get manifest` ne sont plus disponibles) : + - Vous devez éditer le manifeste de la release stocké dans le cluster pour mettre à jour les versions d'API vers des APIs prises en charge. Voir [Mise à jour des versions d'API d'un manifeste de release](#updating-api-versions-of-a-release-manifest) pour plus de détails. + +> Remarque : Dans tous les cas de mise à jour d'une release Helm avec des APIs prises en charge, vous ne devez jamais faire de rollback de la release vers une version antérieure à la version de la release avec les APIs prises en charge. + +> Recommandation : La meilleure pratique est de mettre à niveau les releases utilisant des versions d'API dépréciées vers des versions d'API prises en charge, avant de mettre à niveau vers un cluster Kubernetes qui supprime ces versions d'API. + +Si vous ne mettez pas à jour une release comme suggéré précédemment, vous rencontrerez une erreur similaire à la suivante lorsque vous tenterez de mettre à niveau une release dans une version de Kubernetes où ses versions d'API sont supprimées : + +``` +Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) +for this kubernetes version and it is therefore unable to build the kubernetes +objects for performing the diff. error from kubernetes: unable to recognize "": +no matches for kind "Deployment" in version "apps/v1beta1" +``` + +Helm échoue dans ce scénario car il tente de créer un patch de différence entre la release actuellement déployée (qui contient les APIs Kubernetes supprimées dans cette version de Kubernetes) et le chart que vous passez avec les versions d'API mises à jour/prises en charge. La raison sous-jacente de l'échec est que lorsque Kubernetes supprime une version d'API, la bibliothèque cliente Go de Kubernetes ne peut plus analyser les objets dépréciés, et Helm échoue donc lorsqu'il appelle la bibliothèque. Malheureusement, Helm ne peut pas récupérer de cette situation et n'est plus en mesure de gérer une telle release. Voir [Mise à jour des versions d'API d'un manifeste de release](#updating-api-versions-of-a-release-manifest) pour plus de détails sur la manière de récupérer de ce scénario. + +## Mise à jour des versions d'API d'un manifeste de release + +Le manifeste est une propriété de l'objet release Helm qui est stockée dans le champ de données d'un Secret (par défaut) ou d'un ConfigMap dans le cluster. Le champ de données contient un objet compressé en gzip qui est encodé en base 64 (il y a un encodage base 64 supplémentaire pour un Secret). Il y a un Secret/ConfigMap par version/révision de release dans l'espace de noms de la release. + +Vous pouvez utiliser le plugin Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) pour mettre à jour une release vers des APIs prises en charge. Consultez le README pour plus de détails. + +Alternativement, vous pouvez suivre ces étapes manuelles pour mettre à jour les versions d'API d'un manifeste de release. En fonction de votre configuration, vous suivrez les étapes pour le backend Secret ou ConfigMap. + +- Get the name of the Secret or Configmap associated with the latest deployed + release: +- Backend Secrets : `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` +- Backend ConfigMap : `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` + +- Obtenez les détails de la release déployée : + - Backend Secrets : `kubectl get secret -n -o yaml > release.yaml` + - Backend ConfigMap : `kubectl get configmap -n -o yaml > release.yaml` + +- Sauvegardez la release au cas où vous auriez besoin de restaurer en cas de problème : + - `cp release.yaml release.bak` + - En cas d'urgence, restaurez : `kubectl apply -f release.bak -n ` + +- Décodez l'objet release : + - Backend Secrets : `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` + - Backend ConfigMap : `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` + +- Modifiez les versions d'API des manifests. Vous pouvez utiliser n'importe quel outil (par exemple, un éditeur) pour effectuer les modifications. Cela se trouve dans le champ `manifest` de votre objet release décodé (`release.data.decoded`). + +- Encodez l'objet release : + - Backend Secrets : `cat release.data.decoded | gzip | base64 | base64` + - Backend ConfigMap : `cat release.data.decoded | gzip | base64` + +- Remplacez la valeur de la propriété `data.release` dans le fichier de release déployé (`release.yaml`) par le nouvel objet release encodé. + +- Appliquez le fichier dans l'espace de noms : `kubectl apply -f release.yaml -n ` + +- Effectuez une `helm upgrade` avec une version du chart contenant des versions d'API Kubernetes prises en charge. + +- Ajoutez une description lors de la mise à niveau, précisant de ne pas effectuer de rollback vers une version Helm antérieure à cette version actuelle. diff --git a/content/fr/docs/topics/kubernetes_distros.md b/content/fr/docs/topics/kubernetes_distros.md new file mode 100644 index 000000000..79185e00d --- /dev/null +++ b/content/fr/docs/topics/kubernetes_distros.md @@ -0,0 +1,76 @@ +--- +title: "Guide de distribution Kubernetes" +description: "Contient des informations sur l'utilisation de Helm dans des environnements Kubernetes spécifiques." +weight: 10 +--- + +Helm devrait fonctionner avec toute [version conforme de Kubernetes](https://github.com/cncf/k8s-conformance) (qu'elle soit [certifiée](https://www.cncf.io/certification/software-conformance/) ou non). + +Ce document contient des informations sur l'utilisation de Helm dans des environnements Kubernetes spécifiques. Veuillez contribuer avec plus de détails sur les différentes distributions (triées par ordre alphabétique) si souhaité. + + +## AKS + +Helm fonctionne avec [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). + +## DC/OS + +Helm a été testé et fonctionne sur la plateforme Kubernetes Mesospheres DC/OS 1.11, sans nécessiter de configuration supplémentaire. + +## EKS + +Helm fonctionne avec Amazon Elastic Kubernetes Service (Amazon EKS) : [Utilisation de Helm avec Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). + +## GKE + +La plateforme Kubernetes hébergée GKE de Google est connue pour fonctionner avec Helm et ne nécessite aucune configuration supplémentaire. + +## `scripts/local-cluster` et Hyperkube + +Hyperkube configuré via `scripts/local-cluster.sh` est connu pour fonctionner avec Helm. Pour une installation brute de Hyperkube, vous pourriez avoir besoin d'effectuer quelques configurations manuelles. + +## IKS + +Helm fonctionne avec [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). + +## KIND (Kubernetes IN Docker) + +Helm est régulièrement testé sur [KIND](https://github.com/kubernetes-sigs/kind). + +## KubeOne + +Helm fonctionne dans les clusters configurés par KubeOne sans réserve. + +## Kubermatic + +Helm fonctionne dans les clusters utilisateurs créés par Kubermatic sans réserve. Étant donné que le cluster de seed peut être configuré de différentes manières, le support de Helm dépend de leur configuration. + +## MicroK8s + +Helm peut être activé dans [MicroK8s](https://microk8s.io) en utilisant la commande : +`microk8s.enable helm3` + +## Minikube + +Helm est testé et fonctionne avec [Minikube](https://github.com/kubernetes/minikube). Il ne nécessite aucune configuration supplémentaire. + +## Openshift + +Helm fonctionne simplement sur OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (version >= 3.6) ou OpenShift Origin (version >= 3.6). Pour en savoir plus, lisez [cet article de blog](https://blog.openshift.com/getting-started-helm-openshift/). + +## Platform9 + +Helm est préinstallé avec [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). Platform9 offre l'accès à tous les charts Helm officiels via l'interface App Catalog et la CLI Kubernetes native. Des dépôts supplémentaires peuvent être ajoutés manuellement. Pour plus de détails, consultez [cet article sur le catalogue d'applications Platform9](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). + +## Ubuntu avec `kubeadm` + +Kubernetes bootstrappé avec `kubeadm` est connu pour fonctionner sur les distributions Linux suivantes : + +- Ubuntu 16.04 +- Fedora release 25 + +Certaines versions de Helm (v2.0.0-beta2) nécessitent que vous exécutiez `export KUBECONFIG=/etc/kubernetes/admin.conf` ou que vous créiez un fichier `~/.kube/config`. + +## VMware Tanzu Kubernetes Grid + +Helm fonctionne sur VMware Tanzu Kubernetes Grid (TKG) sans nécessiter de modifications de configuration. La CLI Tanzu peut gérer l'installation des packages pour [helm-controller](https://fluxcd.io/flux/components/helm/), permettant une gestion déclarative des releases de charts Helm. Pour plus de détails, consultez la documentation de TKG sur les [Packages Gérés par la CLI](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). diff --git a/content/fr/docs/topics/library_charts.md b/content/fr/docs/topics/library_charts.md new file mode 100644 index 000000000..83bd381d4 --- /dev/null +++ b/content/fr/docs/topics/library_charts.md @@ -0,0 +1,348 @@ +--- +title: "Charts de bibliothèque" +description: "Explique les charts de bibliothèque et donne des exemples d'utilisation" +weight: 4 +--- + +Un chart de bibliothèque est un type de [Chart Helm]({{< ref "/docs/topics/charts.md" >}}) qui définit des primitives ou des définitions de chart pouvant être partagées par des templates Helm dans d'autres charts. Cela permet aux utilisateurs de partager des morceaux de code réutilisables dans différents charts, évitant ainsi la répétition et respectant le principe [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). + +Le chart de bibliothèque a été introduit dans Helm 3 pour reconnaître formellement les charts communs ou d'assistance qui étaient utilisés par les mainteneurs de charts depuis Helm 2. En l'incluant comme un type de chart, il permet de : + +- Distinguer explicitement les charts communs des charts d'application +- Empêcher l'installation d'un chart commun +- Ne pas rendre les templates d'un chart commun qui pourraient contenir des artefacts de release +- Permettre aux charts dépendants d'utiliser le contexte de l'importateur + +Un mainteneur de chart peut définir un chart commun comme un chart de bibliothèque et avoir désormais la certitude que Helm le gérera de manière standard et cohérente. Cela signifie également que les définitions d'un chart d'application peuvent être partagées en modifiant simplement le type de chart. + +## Créer un Chart de Bibliothèque Simple + +Comme mentionné précédemment, un chart de bibliothèque est un type de [Chart Helm]({{< ref "/docs/topics/charts.md" >}}). Cela signifie que vous pouvez commencer par créer un chart de base : +```console +$ helm create mylibchart +Creating mylibchart +``` + +Vous devrez d'abord supprimer tous les fichiers dans le répertoire `templates`, car nous allons créer nos propres définitions de templates dans cet exemple. + +```console +$ rm -rf mylibchart/templates/* +``` + +Le fichier `values.yaml` ne sera pas non plus nécessaire. + +```console +$ rm -f mylibchart/values.yaml +``` + +Avant de commencer à créer du code commun, faisons un rapide tour d'horizon de certains concepts pertinents de Helm. Un [template nommé]({{< ref "/docs/chart_template_guide/named_templates.md" >}}) (parfois appelé partiel ou sous-template) est simplement un template défini dans un fichier et auquel on donne un nom. Dans le répertoire `templates/`, tout fichier commençant par un underscore (_) n'est pas censé produire un fichier manifeste Kubernetes. Par convention, les templates d'assistance et les partiels sont donc placés dans des fichiers `_*.tpl` ou `_*.yaml`. + +Dans cet exemple, nous allons coder un ConfigMap commun qui crée une ressource ConfigMap vide. Nous définirons le ConfigMap commun dans le fichier `mylibchart/templates/_configmap.yaml` comme suit : + +```yaml +{{- define "mylibchart.configmap.tpl" -}} +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} +data: {} +{{- end -}} +{{- define "mylibchart.configmap" -}} +{{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} +{{- end -}} +``` + +Le construct ConfigMap est défini dans le template nommé `mylibchart.configmap.tpl`. C'est un ConfigMap simple avec une ressource vide, `data`. Dans ce fichier, il y a un autre template nommé appelé `mylibchart.configmap`. Ce template nommé inclut un autre template nommé, `mylibchart.util.merge`, qui prendra deux templates nommés en arguments : le template appelant `mylibchart.configmap` et `mylibchart.configmap.tpl`. + +La fonction d'assistance `mylibchart.util.merge` est un template nommé dans `mylibchart/templates/_util.yaml`. C'est un utilitaire pratique de [Le Chart d'Assistance Helm Commun]() car il fusionne les deux templates et remplace les parties communes dans les deux : + +```yaml +{{- /* +mylibchart.util.merge fusionnera deux templates YAML et produira le résultat. Il prend un tableau de trois valeurs : +- le contexte principal +- le nom du template des remplacements (destination) +- le nom du template de base (source) +*/}} +{{- define "mylibchart.util.merge" -}} +{{- $top := first . -}} +{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} +{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} +{{- toYaml (merge $overrides $tpl) -}} +{{- end -}} +``` + +C'est important lorsqu'un chart souhaite utiliser du code commun qu'il doit personnaliser avec sa propre configuration. + +Enfin, changeons le type de chart en `library`. Cela nécessite de modifier `mylibchart/Chart.yaml` comme suit : + +```yaml +apiVersion: v2 +name: mylibchart +description: A Helm chart for Kubernetes + +# Un chart peut être soit un chart 'application', soit un chart 'library'. +# +# Les charts d'application sont une collection de templates qui peuvent être empaquetés en archives versionnées +# pour être déployés. +# +# Les charts de bibliothèque fournissent des utilitaires ou des fonctions utiles pour le développeur de charts. Ils sont inclus comme +# une dépendance des charts d'application pour injecter ces utilitaires et fonctions dans le pipeline de rendu. Les charts de bibliothèque ne définissent +# aucun template et ne peuvent donc pas être déployés. +# type: application +type: library + +# C'est la version du chart. Ce numéro de version doit être incrémenté chaque fois que vous apportez des modifications +# au chart et à ses templates, y compris la version de l'application. +version: 0.1.0 + +# C'est le numéro de version de l'application déployée. Ce numéro de version doit être +# incrémenté chaque fois que vous apportez des modifications à l'application et il est recommandé de l'utiliser entre guillemets. +appVersion: "1.16.0" +``` + +Le chart de bibliothèque est maintenant prêt à être partagé et sa définition de ConfigMap peut être réutilisée. + +Avant de continuer, il est utile de vérifier si Helm reconnaît le chart comme un chart de bibliothèque : + +```console +$ helm install mylibchart mylibchart/ +Error: library charts are not installable +``` + +## Utiliser le Chart de Bibliothèque Simple + +Il est temps d'utiliser le chart de bibliothèque. Cela signifie qu'il faut à nouveau créer un chart de base : + +```console +$ helm create mychart +Creating mychart +``` + +Nettoyons à nouveau les fichiers de templates, car nous souhaitons créer uniquement un ConfigMap : + +```console +$ rm -rf mychart/templates/* +``` + +Lorsque nous voulons créer un ConfigMap simple dans un template Helm, il pourrait ressembler à ce qui suit : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} +data: + myvalue: "Hello World" +``` + +Nous allons cependant réutiliser le code commun déjà créé dans `mylibchart`. Le ConfigMap peut être créé dans le fichier `mychart/templates/configmap.yaml` comme suit : + +```yaml +{{- include "mylibchart.configmap" (list . "mychart.configmap") -}} +{{- define "mychart.configmap" -}} +data: + myvalue: "Hello World" +{{- end -}} +``` + +Vous pouvez voir que cela simplifie le travail à réaliser en héritant de la définition commune du ConfigMap, qui ajoute des propriétés standard pour le ConfigMap. Dans notre template, nous ajoutons la configuration, dans ce cas, la clé de données `myvalue` et sa valeur. La configuration remplace la ressource vide du ConfigMap commun. Cela est possible grâce à la fonction d'assistance `mylibchart.util.merge` que nous avons mentionnée dans la section précédente. + +Pour pouvoir utiliser le code commun, nous devons ajouter `mylibchart` comme dépendance. Ajoutez ce qui suit à la fin du fichier `mychart/Chart.yaml` : + +```yaml +# Mon code commun dans mon chart de bibliothèque +dependencies: +- name: mylibchart + version: 0.1.0 + repository: file://../mylibchart +``` + +Cela inclut le chart de bibliothèque comme une dépendance dynamique depuis le système de fichiers, qui se trouve au même niveau que notre chart d'application. Comme nous incluons le chart de bibliothèque comme une dépendance dynamique, nous devons exécuter `helm dependency update`. Cette commande copiera le chart de bibliothèque dans votre répertoire `charts/`. + +```console +$ helm dependency update mychart/ +Hang tight while we grab the latest from your chart repositories... +...Successfully got an update from the "stable" chart repository +Update Complete. ⎈Happy Helming!⎈ +Saving 1 charts +Deleting outdated charts +``` + +Nous sommes maintenant prêts à déployer notre chart. Avant d'installer, il est utile de vérifier d'abord le template rendu. + +```console +$ helm install mydemo mychart/ --debug --dry-run +install.go:159: [debug] Original chart version: "" +install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart + +NAME: mydemo +LAST DEPLOYED: Tue Mar 3 17:48:47 2020 +NAMESPACE: default +STATUS: pending-install +REVISION: 1 +TEST SUITE: None +USER-SUPPLIED VALUES: +{} + +COMPUTED VALUES: +affinity: {} +fullnameOverride: "" +image: + pullPolicy: IfNotPresent + repository: nginx +imagePullSecrets: [] +ingress: + annotations: {} + enabled: false + hosts: + - host: chart-example.local + paths: [] + tls: [] +mylibchart: + global: {} +nameOverride: "" +nodeSelector: {} +podSecurityContext: {} +replicaCount: 1 +resources: {} +securityContext: {} +service: + port: 80 + type: ClusterIP +serviceAccount: + annotations: {} + create: true + name: null +tolerations: [] + +HOOKS: +MANIFEST: +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +data: + myvalue: Hello World +kind: ConfigMap +metadata: + labels: + app: mychart + chart: mychart-0.1.0 + release: mydemo + name: mychart-mydemo +``` + +Cela ressemble au ConfigMap que nous souhaitons, avec l'écrasement des données pour `myvalue: Hello World`. Installons-le : + +```console +$ helm install mydemo mychart/ +NAME: mydemo +LAST DEPLOYED: Tue Mar 3 17:52:40 2020 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +TEST SUITE: None +``` + +Nous pouvons récupérer la version et vérifier que le template réel a été chargé. + +```console +$ helm get manifest mydemo +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +data: + myvalue: Hello World +kind: ConfigMap +metadata: + labels: + app: mychart + chart: mychart-0.1.0 + release: mydemo + name: mychart-mydemo + ``` + +## Avantages des Charts de Bibliothèque +En raison de leur incapacité à agir en tant que charts autonomes, les charts de bibliothèque peuvent tirer parti des fonctionnalités suivantes : + +- L'objet `.Files` fait référence aux chemins de fichiers du chart parent, plutôt qu'au chemin local au chart de bibliothèque. +- L'objet `.Values` est identique à celui du chart parent, contrairement aux [sous-charts]({{< ref "/docs/chart_template_guide/subcharts_and_globals.md" >}}) d'application qui reçoivent la section des valeurs configurées sous leur en-tête dans le parent. + + +## Le Chart d'Assistance Helm Commun + +```markdown +Note : Le dépôt Common Helm Helper Chart sur GitHub n'est plus activement maintenu. Le dépôt a été déprécié et archivé. +``` + +Ce [chart](https://github.com/helm/charts/tree/master/incubator/common) était le modèle original pour les charts communs. Il fournit des utilitaires qui reflètent les meilleures pratiques du développement de charts Kubernetes. Le mieux, c'est qu'il peut être utilisé immédiatement par vous lors du développement de vos charts pour vous fournir du code partagé pratique. + +Voici une méthode rapide pour l'utiliser. Pour plus de détails, consultez le [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). + +Créez à nouveau un chart de base : + +```console +$ helm create demo +Creating demo +``` + +Utilisons le code commun du chart d'assistance. Tout d'abord, modifiez le fichier `demo/templates/deployment.yaml` comme suit : + +```yaml +{{- template "common.deployment" (list . "demo.deployment") -}} +{{- define "demo.deployment" -}} +## Définissez les surcharges pour votre ressource Deployment ici, par exemple +apiVersion: apps/v1 +spec: + replicas: {{ .Values.replicaCount }} + selector: + matchLabels: + {{- include "demo.selectorLabels" . | nindent 6 }} + template: + metadata: + labels: + {{- include "demo.selectorLabels" . | nindent 8 }} + +{{- end -}} +``` + +Et maintenant, le fichier de service, `demo/templates/service.yaml`, comme suit : + +```yaml +{{- template "common.service" (list . "demo.service") -}} +{{- define "demo.service" -}} +## Définissez les surcharges pour votre ressource Deployment ici, par exemple +# metadata: +# labels: +# custom: label +# spec: +# ports: +# - port: 8080 +{{- end -}} +``` + +Ces templates montrent comment l'héritage du code commun du chart d'assistance simplifie votre codage en le réduisant à la configuration ou à la personnalisation des ressources. + +Pour pouvoir utiliser le code commun, nous devons ajouter `common` comme dépendance. Ajoutez ce qui suit à la fin du fichier `demo/Chart.yaml` : + +```yaml +dependencies: +- name: common + version: "^0.0.5" + repository: "https://charts.helm.sh/incubator/" +``` + +Note : Vous devrez ajouter le dépôt `incubator` à la liste des dépôts Helm (`helm repo add`). + +Comme nous incluons le chart comme une dépendance dynamique, nous devons exécuter `helm dependency update`. Cela copiera le chart d'assistance dans votre répertoire `charts/`. + +Étant donné que le chart d'assistance utilise certains éléments de Helm 2, vous devrez ajouter ce qui suit à `demo/values.yaml` pour permettre le chargement de l'image `nginx`, car cela a été mis à jour dans le chart de base Helm 3 : + +```yaml +image: + tag: 1.16.0 +``` + +Vous pouvez vérifier que les templates du chart sont corrects avant de déployer en utilisant les commandes `helm lint` et `helm template`. + +Si tout est en ordre, déployez avec `helm install` ! + diff --git a/content/fr/docs/topics/permissions_sql_storage_backend.md b/content/fr/docs/topics/permissions_sql_storage_backend.md new file mode 100644 index 000000000..9c8ca5f18 --- /dev/null +++ b/content/fr/docs/topics/permissions_sql_storage_backend.md @@ -0,0 +1,43 @@ +--- +title: "Gestion des autorisations pour le backend de stockage SQL" +description: "Découvrez comment configurer les autorisations lors de l'utilisation d'un backend de stockage SQL" +--- + +Ce document a pour objectif de fournir des conseils aux utilisateurs pour la configuration et la gestion des autorisations lors de l'utilisation d'un backend de stockage SQL. + +## Introduction + +Pour gérer les autorisations, Helm s'appuie sur la fonctionnalité RBAC de Kubernetes. Lors de l'utilisation du backend de stockage SQL, les rôles de Kubernetes ne peuvent pas être utilisés pour déterminer si un utilisateur peut accéder à une ressource donnée. Ce document montre comment créer et gérer ces autorisations. + +## Initialisation + +La première fois que l'interface en ligne de commande Helm se connectera à votre base de données, le client s'assurera qu'elle a été initialisée au préalable. Si ce n'est pas le cas, il s'occupera automatiquement de la configuration nécessaire. Cette initialisation nécessite des privilèges d'administrateur sur le schéma public, ou au moins la capacité de : + +* créer une table +* accorder des privilèges sur le schéma public + +Après l'exécution de la migration sur votre base de données, tous les autres rôles peuvent utiliser le client. + +## Accorder des privilèges à un utilisateur non administrateur dans PostgreSQL + +Pour gérer les autorisations, le pilote de backend SQL utilise la fonctionnalité [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Security Level) de PostgreSQL. RLS permet à tous les utilisateurs de lire/écrire dans la même table, sans pouvoir manipuler les mêmes lignes s'ils n'y sont pas explicitement autorisés. Par défaut, tout rôle qui n'a pas reçu les privilèges appropriés renverra toujours une liste vide lors de l'exécution de la commande `helm list` et ne pourra ni récupérer ni modifier une ressource dans le cluster. + +Voyons comment accorder à un rôle donné l'accès à des espaces de noms spécifiques : + +```sql +CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); +``` + +Cette commande accordera les autorisations de lecture et d'écriture pour toutes les ressources répondant à la condition `namespace = 'default'` au rôle `role`. Après avoir créé cette politique, l'utilisateur connecté à la base de données au nom du rôle `role` pourra donc voir toutes les releases se trouvant dans l'espace de noms `default` lors de l'exécution de `helm list`, ainsi que les modifier et les supprimer. + +Les privilèges peuvent être gérés de manière granulaire avec RLS, et il peut être intéressant de restreindre l'accès en fonction des différentes colonnes de la table : +* key +* type +* body +* name +* namespace +* version +* status +* owner +* createdAt +* modifiedAt diff --git a/content/fr/docs/topics/plugins.md b/content/fr/docs/topics/plugins.md new file mode 100644 index 000000000..c3f1aebe9 --- /dev/null +++ b/content/fr/docs/topics/plugins.md @@ -0,0 +1,285 @@ +--- +title: "Le Guide des Plugins Helm" +description: "Présente comment utiliser et créer des plugins pour étendre les fonctionnalités de Helm" +weight: 12 +--- + +Un plugin Helm est un outil qui peut être accédé via l'interface en ligne de commande `helm`, mais qui ne fait pas partie de la base de code intégrée de Helm. + +Les plugins existants peuvent être trouvés dans la section [liée]({{}}) ou en recherchant sur [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). + +Ce guide explique comment utiliser et créer des plugins. + +## Un Aperçu + +Les plugins Helm sont des outils complémentaires qui s'intègrent parfaitement à Helm. Ils offrent un moyen d'étendre les fonctionnalités de base de Helm, sans nécessiter que chaque nouvelle fonctionnalité soit écrite en Go et ajoutée à l'outil principal. + +Les plugins Helm possèdent les caractéristiques suivantes : + +- Ils peuvent être ajoutés et supprimés d'une installation Helm sans impacter l'outil Helm principal. +- Ils peuvent être écrits dans n'importe quel langage de programmation. +- Ils s'intègrent à Helm et apparaissent dans `helm help` et à d'autres endroits. + +Les plugins Helm se trouvent dans `$HELM_PLUGINS`. Vous pouvez trouver la valeur actuelle de cette variable, y compris la valeur par défaut lorsqu'elle n'est pas définie dans l'environnement, en utilisant la commande `helm env`. + +Le modèle de plugin Helm est en partie inspiré du modèle de plugins de Git. À ce titre, vous pourriez parfois entendre que `helm` est appelé la couche _porcelaine_, tandis que les plugins sont le _plomberie_. C'est une manière abrégée de suggérer que Helm fournit l'expérience utilisateur et la logique de traitement de haut niveau, tandis que les plugins se chargent du "travail de détail" pour exécuter une action souhaitée. + +## Installer un Plugin + +Les plugins sont installés en utilisant la commande `$ helm plugin install `. Vous pouvez spécifier un chemin vers un plugin sur votre système de fichiers local ou une URL d'un dépôt VCS distant. La commande `helm plugin install` clone ou copie le plugin au chemin/URL donné dans `$HELM_PLUGINS` + +```console +$ helm plugin install https://github.com/adamreese/helm-env +``` + +Si vous avez une distribution de plugin au format tar, il suffit de décompresser le plugin dans le répertoire `$HELM_PLUGINS`. Vous pouvez également installer des plugins au format tarball directement depuis une URL en exécutant `helm plugin install https://domain/path/to/plugin.tar.gz`. + +## Créer un Plugin + +À bien des égards, un plugin est similaire à un chart. Chaque plugin a un répertoire de niveau supérieur, ainsi qu'un fichier `plugin.yaml`. + +``` +$HELM_PLUGINS/ + |- last/ + | + |- plugin.yaml + |- last.sh + +``` + +Dans l'exemple ci-dessus, le plugin `last` est contenu dans un répertoire nommé `last`. Il comprend deux fichiers : `plugin.yaml` (obligatoire) et un script exécutable, `last.sh` (optionnel). + +Le cœur d'un plugin est un simple fichier YAML nommé `plugin.yaml`. Voici un exemple de YAML pour un plugin qui aide à obtenir le nom de la dernière release : + +```yaml +name: "last" +version: "0.1.0" +usage: "obtenir le nom de la dernière release" +description: "obtenir le nom de la dernière release" +ignoreFlags: false +command: "$HELM_BIN --host $TILLER_HOST list --short --max 1 --date -r" +platformCommand: + - os: linux + arch: i386 + command: "$HELM_BIN list --short --max 1 --date -r" + - os: linux + arch: amd64 + command: "$HELM_BIN list --short --max 1 --date -r" + - os: windows + arch: amd64 + command: "$HELM_BIN list --short --max 1 --date -r" +``` + +Le `name` est le nom du plugin. Lorsque Helm exécute ce plugin, c'est ce nom qu'il utilisera (par exemple, `helm NAME` invoquera ce plugin). + +_Le `name` doit correspondre au nom du répertoire._ Dans notre exemple, cela signifie que le plugin avec `name: last` doit être contenu dans un répertoire nommé `last`. + +Restrictions sur le `name` : + +- `name` ne peut pas dupliquer l'un des commandes de niveau supérieur existantes de `helm`. +- `name` doit être limité aux caractères ASCII a-z, A-Z, 0-9, `_` et `-`. + +`version` est la version SemVer 2 du plugin. `usage` et `description` sont utilisés pour générer le texte d'aide d'une commande. + +Le switch `ignoreFlags` indique à Helm de _ne pas_ passer les options au plugin. Ainsi, si un plugin est appelé avec `helm myplugin --foo` et que `ignoreFlags: true` est défini, alors `--foo` sera silencieusement ignoré. + +Enfin, et surtout, `platformCommand` ou `command` est la commande que ce plugin exécutera lorsqu'il sera appelé. La section `platformCommand` définit les variations spécifiques au système d'exploitation/architecture d'une commande. Les règles suivantes s'appliquent pour décider quelle commande utiliser : + +- Si `platformCommand` est présent, il sera recherché en premier. +- Si à la fois `os` et `arch` correspondent à la plateforme actuelle, la recherche s'arrêtera et la commande sera utilisée. +- Si `os` correspond et qu'il n'y a pas de correspondance plus spécifique pour `arch`, la commande sera utilisée. +- Si aucune correspondance dans `platformCommand` n'est trouvée, la commande par défaut `command` sera utilisée. +- Si aucune correspondance n'est trouvée dans `platformCommand` et qu'aucun `command` n'est présent, Helm quittera avec une erreur. + +Les variables d'environnement sont interpolées avant l'exécution du plugin. Le modèle ci-dessus illustre la manière préférée d'indiquer où se trouve le programme du plugin. + +Il existe plusieurs stratégies pour travailler avec les commandes de plugins : + +- Si un plugin inclut un exécutable, l'exécutable pour un `platformCommand:` ou un `command:` doit être emballé dans le répertoire du plugin. +- La ligne `platformCommand:` ou `command:` aura toutes les variables d'environnement développées avant l'exécution. `$HELM_PLUGIN_DIR` pointera vers le répertoire du plugin. +- La commande elle-même n'est pas exécutée dans un shell. Vous ne pouvez donc pas enchaîner un script shell en une seule ligne. +- Helm injecte beaucoup de configuration dans les variables d'environnement. Consultez l'environnement pour voir quelles informations sont disponibles. +- Helm ne fait aucune restriction sur le langage du plugin. Vous pouvez l'écrire dans le langage de votre choix. +- Les commandes sont responsables de la mise en œuvre du texte d'aide spécifique pour `-h` et `--help`. Helm utilisera `usage` et `description` pour `helm help` et `helm help myplugin`, mais ne gérera pas `helm myplugin --help`. + +## Plugins de Téléchargement +Par défaut, Helm est capable de récupérer des Charts via HTTP/S. À partir de Helm 2.4.0, les plugins peuvent avoir une capacité spéciale pour télécharger des Charts depuis des sources arbitraires. + +Les plugins doivent déclarer cette capacité spéciale dans le fichier `plugin.yaml` (au niveau supérieur) : + +```yaml +downloaders: +- command: "bin/mydownloader" + protocols: + - "myprotocol" + - "myprotocols" +``` + +Si un tel plugin est installé, Helm peut interagir avec le dépôt en utilisant le schéma de protocole spécifié en invoquant la `command`. Le dépôt spécial doit être ajouté de la même manière que les dépôts réguliers : `helm repo add favorite myprotocol://example.com/`. Les règles pour les dépôts spéciaux sont les mêmes que pour les dépôts réguliers : Helm doit être capable de télécharger le fichier `index.yaml` afin de découvrir et de mettre en cache la liste des Charts disponibles. + +La commande définie sera invoquée avec le schéma suivant : `command certFile keyFile caFile full-URL`. Les identifiants SSL proviennent de la définition du dépôt, stockée dans `$HELM_REPOSITORY_CONFIG` (c'est-à-dire, `$HELM_CONFIG_HOME/repositories.yaml`). Un plugin Downloader est censé émettre le contenu brut sur stdout et signaler les erreurs sur stderr. + +La commande de téléchargement prend également en charge les sous-commandes ou arguments, vous permettant de spécifier par exemple `bin/mydownloader subcommand -d` dans le `plugin.yaml`. Cela est utile si vous souhaitez utiliser le même exécutable pour la commande principale du plugin et la commande de téléchargement, mais avec une sous-commande différente pour chacune. + +## Variables d'Environnement + +Lorsque Helm exécute un plugin, il passe l'environnement externe au plugin et injecte également certaines variables d'environnement supplémentaires. + +Les variables comme `KUBECONFIG` sont définies pour le plugin si elles sont définies dans l'environnement externe. + +Les variables suivantes sont garanties d'être définies : + +- `HELM_PLUGINS` : Le chemin vers le répertoire des plugins. +- `HELM_PLUGIN_NAME` : Le nom du plugin, tel qu'invoqué par `helm`. Ainsi, `helm myplug` aura le nom court `myplug`. +- `HELM_PLUGIN_DIR` : Le répertoire contenant le plugin. +- `HELM_BIN` : Le chemin vers la commande `helm` (telle qu'exécutée par l'utilisateur). +- `HELM_DEBUG` : Indique si le flag de débogage a été activé par Helm. +- `HELM_REGISTRY_CONFIG` : L'emplacement de la configuration du registre (si utilisé). Notez que l'utilisation de Helm avec les registres est une fonctionnalité expérimentale. +- `HELM_REPOSITORY_CACHE` : Le chemin vers les fichiers de cache des dépôts. +- `HELM_REPOSITORY_CONFIG` : Le chemin vers le fichier de configuration des dépôts. +- `HELM_NAMESPACE` : L'espace de noms donné à la commande `helm` (généralement en utilisant le flag `-n`). +- `HELM_KUBECONTEXT` : Le nom du contexte de configuration Kubernetes donné à la commande `helm`. + +De plus, si un fichier de configuration Kubernetes a été spécifié explicitement, il sera défini en tant que variable `KUBECONFIG`. + +## Remarque sur l'Analyse des Arguments + +Lors de l'exécution d'un plugin, Helm analysera les arguments globaux pour son propre usage. Aucun de ces arguments n'est transmis au plugin. + +- `--debug` : Si cet argument est spécifié, `$HELM_DEBUG` est défini sur `1`. +- `--registry-config` : Ceci est converti en `$HELM_REGISTRY_CONFIG`. +- `--repository-cache` : Ceci est converti en `$HELM_REPOSITORY_CACHE`. +- `--repository-config` : Ceci est converti en `$HELM_REPOSITORY_CONFIG`. +- `--namespace` et `-n` : Ceci est converti en `$HELM_NAMESPACE`. +- `--kube-context` : Ceci est converti en `$HELM_KUBECONTEXT`. +- `--kubeconfig` : Ceci est converti en `$KUBECONFIG`. + +Les plugins _devraient_ afficher le texte d'aide et ensuite se terminer pour `-h` et `--help`. Dans tous les autres cas, les plugins peuvent utiliser les arguments de manière appropriée. + +## Fournir l'auto-complétion shell + +Depuis Helm 3.2, un plugin peut optionnellement fournir un support pour l'auto-complétion shell dans le cadre du mécanisme d'auto-complétion existant de Helm. + +### Complétion automatique statique + +Si un plugin fournit ses propres arguments et/ou sous-commandes, il peut en informer Helm en ayant un fichier `completion.yaml` situé dans le répertoire racine du plugin. Le fichier `completion.yaml` a la forme suivante : + +```yaml +name: +flags: +- +- +validArgs: +- +- +commands: + name: + flags: + - + - + validArgs: + - + - + commands: + +``` + +Remarques : +1. Toutes les sections sont optionnelles mais doivent être fournies si elles sont applicables. +2. Les arguments ne doivent pas inclure le préfixe `-` ou `--`. +3. Les arguments courts et longs peuvent et doivent être spécifiés. Un argument court n'a pas besoin d'être associé à sa forme longue correspondante, mais les deux formes doivent être listées. +4. Les arguments n'ont pas besoin d'être ordonnés de manière spécifique, mais doivent être listés au bon endroit dans la hiérarchie des sous-commandes du fichier. +5. Les arguments globaux existants de Helm sont déjà pris en charge par le mécanisme d'auto-complétion de Helm, donc les plugins n'ont pas besoin de spécifier les arguments suivants : `--debug`, `--namespace` ou `-n`, `--kube-context`, et `--kubeconfig`, ou tout autre flag global. +6. La liste `validArgs` fournit une liste statique de complétions possibles pour le premier paramètre suivant une sous-commande. Il n'est pas toujours possible de fournir une telle liste à l'avance (voir la section [Complétion Dynamique]() ci-dessous), auquel cas la section `validArgs` peut être omise. + +Le fichier `completion.yaml` est entièrement optionnel. S'il n'est pas fourni, Helm ne proposera tout simplement pas l'auto-complétion shell pour le plugin (à moins que la [Complétion Dynamique]() soit supportée par le plugin). De plus, l'ajout d'un fichier `completion.yaml` est rétrocompatible et n'affectera pas le comportement du plugin avec les versions antérieures de Helm. + +Par exemple, pour le [`plugin fullstatus`](https://github.com/marckhouzam/helm-fullstatus) qui n'a pas de sous-commandes mais accepte les mêmes flags que la commande `helm status`, le fichier `completion.yaml` est : + +```yaml +name: fullstatus +flags: +- o +- output +- revision +``` + +Un exemple plus complexe pour le [`plugin 2to3`](https://github.com/helm/helm-2to3) a un fichier `completion.yaml` comme suit : + +```yaml +name: 2to3 +commands: +- name: cleanup + flags: + - config-cleanup + - dry-run + - l + - label + - release-cleanup + - s + - release-storage + - tiller-cleanup + - t + - tiller-ns + - tiller-out-cluster +- name: convert + flags: + - delete-v2-releases + - dry-run + - l + - label + - s + - release-storage + - release-versions-max + - t + - tiller-ns + - tiller-out-cluster +- name: move + commands: + - name: config + flags: + - dry-run +``` + +### Complétion Dynamique + +Depuis Helm 3.2, les plugins peuvent également fournir leur propre auto-complétion shell dynamique. La complétion shell dynamique concerne la complétion des valeurs de paramètres ou de flags qui ne peuvent pas être définies à l'avance. Par exemple, la complétion des noms des releases Helm actuellement disponibles sur le cluster. + +Pour que le plugin supporte l'auto-complétion dynamique, il doit fournir un fichier **exécutable** appelé `plugin.complete` dans son répertoire racine. Lorsque le script de complétion Helm nécessite des complétions dynamiques pour le plugin, il exécutera le fichier `plugin.complete`, en lui passant la ligne de commande qui doit être complétée. L'exécutable `plugin.complete` devra avoir la logique pour déterminer quels sont les choix de complétion appropriés et les afficher sur la sortie standard pour être consommés par le script de complétion Helm. + +Le fichier `plugin.complete` est entièrement optionnel. S'il n'est pas fourni, Helm ne proposera tout simplement pas de complétion dynamique pour le plugin. De plus, l'ajout d'un fichier `plugin.complete` est rétrocompatible et n'affectera pas le comportement du plugin avec les versions antérieures de Helm. + +La sortie du script `plugin.complete` doit être une liste séparée par des sauts de ligne, par exemple : + +``` +rel1 +rel2 +rel3 +``` + +Lorsque `plugin.complete` est appelé, l'environnement du plugin est configuré de la même manière que lorsqu'on appelle le script principal du plugin. Par conséquent, les variables `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT`, et toutes les autres variables du plugin seront déjà définies, et les flags globaux correspondants seront supprimés. + +Le fichier `plugin.complete` peut être sous n'importe quelle forme exécutable ; il peut s'agir d'un script shell, d'un programme Go, ou de tout autre type de programme que Helm peut exécuter. Le fichier `plugin.complete` ***doit*** avoir des permissions d'exécution pour l'utilisateur. Le fichier `plugin.complete` ***doit*** se terminer avec un code de succès (valeur 0). + +Dans certains cas, la complétion dynamique nécessitera d'obtenir des informations depuis le cluster Kubernetes. Par exemple, le plugin `helm fullstatus` nécessite un nom de release en entrée. Dans le plugin `fullstatus`, pour que son script `plugin.complete` fournisse des complétions pour les noms de release actuels, il peut simplement exécuter `helm list -q` et afficher le résultat. + +S'il est souhaité d'utiliser le même exécutable pour l'exécution du plugin et pour la complétion du plugin, le script `plugin.complete` peut être configuré pour appeler l'exécutable principal du plugin avec un paramètre ou un flag spécial. Lorsque l'exécutable principal du plugin détecte ce paramètre ou flag spécial, il saura qu'il doit exécuter la complétion. Dans notre exemple, `plugin.complete` pourrait être implémenté comme suit : + +```sh +#!/usr/bin/env sh + +# "$@" est la ligne de commande entière qui nécessite une complétion. +# Il est important de mettre en double citation la variable "$@" pour préserver un éventuel dernier paramètre vide. +$HELM_PLUGIN_DIR/status.sh --complete "$@" +``` + +Le vrai script du plugin `fullstatus` (`status.sh`) doit alors rechercher l'argument `--complete` et, s'il est trouvé, afficher les complétions appropriées. + +### Conseils et astuces + +1. Le shell filtrera automatiquement les choix de complétion qui ne correspondent pas à l'entrée de l'utilisateur. Un plugin peut donc retourner toutes les complétions pertinentes sans supprimer celles qui ne correspondent pas à l'entrée de l'utilisateur. Par exemple, si la ligne de commande est `helm fullstatus ngin`, le script `plugin.complete` peut imprimer *tous* les noms de release (de l'espace de noms `default`), pas seulement ceux commençant par `ngin` ; le shell ne conservera que ceux commençant par `ngin`. +2. Pour simplifier le support de la complétion dynamique, surtout si vous avez un plugin complexe, vous pouvez faire en sorte que votre script `plugin.complete` appelle votre script principal de plugin et demande des choix de complétion. Voir la section [Complétion Dynamique]() ci-dessus pour un exemple. +3. Pour déboguer la complétion dynamique et le fichier `plugin.complete`, vous pouvez exécuter ce qui suit pour voir les résultats de complétion : + - `helm __complete `. Par exemple : + - `helm __complete fullstatus --output js`, + - `helm __complete fullstatus -o json ""` diff --git a/content/fr/docs/topics/provenance.md b/content/fr/docs/topics/provenance.md new file mode 100644 index 000000000..e1badd722 --- /dev/null +++ b/content/fr/docs/topics/provenance.md @@ -0,0 +1,225 @@ +--- +title: "Authenticité et Intégrité de Helm" +description: "Décrit comment vérifier l'intégrité et l'origine d'un chart" +weight: 5 +--- + +Helm dispose d'outils d'authenticité qui aident les utilisateurs de charts à vérifier l'intégrité et l'origine d'un package. En utilisant des outils standards de l'industrie basés sur PKI, GnuPG et des gestionnaires de packages reconnus, Helm peut générer et vérifier des fichiers de signature. + +## Aperçu + +L'intégrité est établie en comparant un chart à un enregistrement d'authenticité. Les enregistrements d'authenticité sont stockés dans des _fichiers de provenance_, qui sont enregistrés aux côtés d'un chart empaqueté. Par exemple, si un chart s'appelle `myapp-1.2.3.tgz`, son fichier de provenance sera `myapp-1.2.3.tgz.prov`. + +Les fichiers de provenance sont générés au moment de l'empaquetage (`helm package --sign ...`) et peuvent être vérifiés par plusieurs commandes, notamment `helm install --verify`. + +## Le Flux de Travail + +Cette section décrit un flux de travail possible pour utiliser efficacement les données d'authenticité. + +Prérequis : + +- Une paire de clés PGP valide au format binaire (pas en ASCII armé) +- L'outil en ligne de commande `helm` +- Outils en ligne de commande GnuPG (optionnel) +- Outils en ligne de commande Keybase (optionnel) + +**REMARQUE :** Si votre clé privée PGP est protégée par une phrase de passe, vous serez invité à entrer cette phrase pour toute commande qui prend en charge l'option `--sign`. + +Créer un nouveau chart : + +```console +$ helm create mychart +Creating mychart +``` + +Une fois prêt à empaqueter, ajoutez l'argument `--sign` à `helm package`. Spécifiez également le nom sous lequel la clé de signature est connue et le trousseau de clés contenant la clé privée correspondante : + +```console +$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart +``` + +**Remarque :** La valeur de l'argument `--key` doit être une sous-chaîne de l'`uid` de la clé souhaitée (dans la sortie de `gpg --list-keys`), par exemple le nom ou l'e-mail. **L'empreinte digitale _ne peut pas_ être utilisée.** + +**CONSEIL :** Pour les utilisateurs de GnuPG, votre trousseau de clés secrètes se trouve dans `~/.gnupg/secring.gpg`. Vous pouvez utiliser `gpg --list-secret-keys` pour lister les clés dont vous disposez. + +**Avertissement :** GnuPG v2 stocke votre trousseau de clés secrètes dans un nouveau format `kbx` à l'emplacement par défaut `~/.gnupg/pubring.kbx`. Veuillez utiliser la commande suivante pour convertir votre trousseau de clés au format GPG traditionnel : + +```console +$ gpg --export >~/.gnupg/pubring.gpg +$ gpg --export-secret-keys >~/.gnupg/secring.gpg +``` + +À ce stade, vous devriez voir à la fois `mychart-0.1.0.tgz` et `mychart-0.1.0.tgz.prov`. Les deux fichiers doivent finalement être téléchargés dans le dépôt de charts de votre choix. + +Vous pouvez vérifier un chart en utilisant `helm verify` : + +```console +$ helm verify mychart-0.1.0.tgz +``` + +Une vérification échouée ressemblera à ça : + +```console +$ helm verify topchart-0.1.0.tgz +Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" +``` + +Pour vérifier lors de l'installation, utilisez l'argument `--verify`. + +```console +$ helm install --generate-name --verify mychart-0.1.0.tgz +``` + +Si le trousseau de clés contenant la clé publique associée au chart signé n'est pas à l'emplacement par défaut, vous devrez peut-être indiquer le trousseau de clés avec `--keyring PATH`, comme dans l'exemple de `helm package`. + +Si la vérification échoue, l'installation sera annulée avant même que le chart ne soit rendu. + +### Utilisation des identifiants Keybase.io + +Le service [Keybase.io](https://keybase.io) facilite l'établissement d'une chaîne de confiance pour une identité cryptographique. Les identifiants Keybase peuvent être utilisés pour signer des charts. + +Prérequis : + +- Un compte Keybase.io configuré +- GnuPG installé localement +- L'outil en ligne de commande `keybase` installé localement + +#### Signature des packages + +La première étape est d'importer vos clés Keybase dans votre trousseau de clés GnuPG local : + +```console +$ keybase pgp export -s | gpg --import +``` + +Cela convertira votre clé Keybase au format OpenPGP, puis l'importera localement dans votre fichier `~/.gnupg/secring.gpg`. + +Vous pouvez vérifier en exécutant `gpg --list-secret-keys`. + +```console +$ gpg --list-secret-keys +/Users/mattbutcher/.gnupg/secring.gpg +------------------------------------- +sec 2048R/1FC18762 2016-07-25 +uid technosophos (keybase.io/technosophos) +ssb 2048R/D125E546 2016-07-25 +``` + +Notez que votre clé secrète aura une chaîne d'identifiant : + +``` +technosophos (keybase.io/technosophos) +``` + +C'est le nom complet de votre clé. + +Ensuite, vous pouvez empaqueter et signer un chart avec `helm package`. Assurez-vous d'utiliser au moins une partie de cette chaîne de nom dans `--key`. + +```console +$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart +``` + +En conséquence, la commande `package` devrait produire à la fois un fichier `.tgz` et un fichier `.tgz.prov`. + +#### Vérification des packages + +Vous pouvez également utiliser une technique similaire pour vérifier un chart signé avec la clé Keybase d'une autre personne. Supposons que vous souhaitiez vérifier un package signé par `keybase.io/technosophos`. Pour ce faire, utilisez l'outil `keybase` : + +```console +$ keybase follow technosophos +$ keybase pgp pull +``` + +La première commande ci-dessus suit l'utilisateur `technosophos`. Ensuite, `keybase pgp pull` télécharge les clés OpenPGP de tous les comptes que vous suivez, les plaçant dans votre trousseau de clés GnuPG (`~/.gnupg/pubring.gpg`). + +À ce stade, vous pouvez maintenant utiliser `helm verify` ou toute autre commande avec un argument `--verify` : + +```console +$ helm verify somechart-1.2.3.tgz +``` + +### Raisons pour lesquelles un chart peut ne pas être vérifié + +Voici les raisons courantes d'échec : + +- Le fichier `.prov` est manquant ou corrompu. Cela indique qu'il y a une mauvaise configuration ou que le mainteneur original n'a pas créé de fichier de provenance. +- La clé utilisée pour signer le fichier n'est pas dans votre trousseau de clés. Cela indique que l'entité ayant signé le chart n'est pas quelqu'un que vous avez déjà signalé comme fiable. +- La vérification du fichier `.prov` a échoué. Cela indique qu'il y a un problème soit avec le chart, soit avec les données de provenance. +- Les hashs des fichiers dans le fichier de provenance ne correspondent pas au hash du fichier d'archive. Cela indique que l'archive a été modifiée. + +Si une vérification échoue, il y a des raisons de ne pas faire confiance au package. + +## Le Fichier de Provenance + +Le fichier de provenance contient le fichier YAML d'un chart ainsi que plusieurs éléments d'information pour la vérification. Les fichiers de provenance sont conçus pour être générés automatiquement. + +Les éléments suivants sont ajoutés aux données de provenance : + +* Le fichier de chart (`Chart.yaml`) est inclus pour offrir aux utilisateurs et aux outils une vue facile sur le contenu du chart. +* La signature (SHA256, comme pour Docker) du package de chart (le fichier `.tgz`) est incluse et peut être utilisée pour vérifier l'intégrité du package de chart. +* L'ensemble du corps est signé en utilisant l'algorithme utilisé par OpenPGP (voir [Keybase.io](https://keybase.io) pour une méthode émergente facilitant la signature et la vérification cryptographiques). + +La combinaison de ces éléments donne aux utilisateurs les assurances suivantes : + +* Le package lui-même n'a pas été modifié (checksum du package `.tgz`). +* L'entité ayant publié ce package est connue (via la signature GnuPG/PGP). + +Le format du fichier ressemble à ceci : + +``` +Hash: SHA512 + +apiVersion: v2 +appVersion: "1.16.0" +description: Sample chart +name: mychart +type: application +version: 0.1.0 + +... +files: + mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 +-----BEGIN PGP SIGNATURE----- + +wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd +nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI +mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 +cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi +hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D +qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= +=aHfz +-----END PGP SIGNATURE----- +``` + +Notez que la section YAML contient deux documents (séparés par `...\n`). Le premier document est le contenu de `Chart.yaml`. Le second document est constitué des checksums, une map des noms de fichiers aux résumés SHA-256 du contenu de ces fichiers au moment de l'empaquetage. + +Le bloc de signature est une signature PGP standard, qui offre une [résistance à la falsification](https://www.rossde.com/PGP/pgp_signatures.html). + +## Dépôts de Charts + +Les dépôts de charts servent de collection centralisée de charts Helm. + +Les dépôts de charts doivent permettre de servir les fichiers de provenance via HTTP à l'aide d'une requête spécifique, et doivent les rendre disponibles au même chemin URI que le chart. + +Par exemple, si l'URL de base pour un package est `https://example.com/charts/mychart-1.2.3.tgz`, le fichier de provenance, s'il existe, DOIT être accessible à `https://example.com/charts/mychart-1.2.3.tgz.prov`. + +Du point de vue de l'utilisateur final, la commande `helm install --verify myrepo/mychart-1.2.3` devrait entraîner le téléchargement à la fois du chart et du fichier de provenance, sans configuration ou action supplémentaire de l'utilisateur. + +### Signatures dans les registres basés sur OCI + +Lors de la publication de charts dans un [registre basé sur OCI]({{}}), le [plugin `helm-sigstore`](https://github.com/sigstore/helm-sigstore/) peut être utilisé pour publier les informations de provenance sur [sigstore](https://sigstore.dev/). [Comme décrit dans la documentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), le processus de création de provenance et de signature avec une clé GPG est similaire, mais la commande `helm sigstore upload` peut être utilisée pour publier la provenance sur un registre d'immuabilité transparent. + +## Établir l'Autorité et l'Authenticité + +Lorsqu'on traite des systèmes de chaîne de confiance, il est important de pouvoir établir l'autorité d'un signataire. Autrement dit, le système repose sur le fait que vous faites confiance à la personne qui a signé le chart. Cela signifie, à son tour, que vous devez faire confiance à la clé publique du signataire. + +L'une des décisions de conception de Helm a été que le projet Helm ne s'insérerait pas dans la chaîne de confiance en tant que partie nécessaire. Nous ne voulons pas être "l'autorité de certification" pour tous les signataires de charts. Au lieu de cela, nous privilégions fortement un modèle décentralisé, ce qui est en partie la raison pour laquelle nous avons choisi OpenPGP comme technologie de base. Ainsi, en ce qui concerne l'établissement de l'autorité, nous avons laissé cette étape plus ou moins indéfinie dans Helm 2 (une décision maintenue dans Helm 3). + +Cependant, nous avons quelques indications et recommandations pour ceux qui souhaitent utiliser le système de provenance : + +- La plateforme [Keybase](https://keybase.io) fournit un dépôt public centralisé pour les informations de confiance. + - Vous pouvez utiliser Keybase pour stocker vos clés ou obtenir les clés publiques des autres. + - Keybase dispose également d'une documentation excellente. + - Bien que nous ne l'ayons pas testé, la fonctionnalité de "site web sécurisé" de Keybase pourrait être utilisée pour servir des charts Helm. + - L'idée de base est qu'un "examinateur de charts" officiel signe les charts avec sa clé, et le fichier de provenance résultant est ensuite téléchargé dans le dépôt de charts. + - Il y a eu des travaux sur l'idée qu'une liste de clés de signature valides pourrait être incluse dans le fichier `index.yaml` d'un dépôt. diff --git a/content/fr/docs/topics/rbac.md b/content/fr/docs/topics/rbac.md new file mode 100644 index 000000000..99abbe6f2 --- /dev/null +++ b/content/fr/docs/topics/rbac.md @@ -0,0 +1,148 @@ +--- +title: "Role-based Access Control" +description: "Explique comment Helm interagit avec le contrôle d'accès basé sur les rôles (RBAC) de Kubernetes." +weight: 11 +--- + +Dans Kubernetes, accorder des rôles à un utilisateur ou à un compte de service spécifique à une application est une bonne pratique pour garantir que votre application fonctionne dans le périmètre que vous avez spécifié. Pour en savoir plus sur les autorisations des comptes de service, consultez la [documentation officielle de Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). + +À partir de Kubernetes 1.6, le contrôle d'accès basé sur les rôles (RBAC) est activé par défaut. RBAC vous permet de spécifier quels types d'actions sont autorisés en fonction de l'utilisateur et de son rôle au sein de votre organisation. + +Avec RBAC, vous pouvez : + +- accorder des opérations privilégiées (création de ressources à l'échelle du cluster, comme de nouveaux rôles) aux administrateurs +- limiter la capacité d'un utilisateur à créer des ressources (pods, volumes persistants, déploiements) à des namespaces spécifiques, ou à l'échelle du cluster (quotas de ressources, rôles, définitions de ressources personnalisées) +- limiter la capacité d'un utilisateur à consulter des ressources, soit dans des namespaces spécifiques, soit à l'échelle du cluster. + +Ce guide s'adresse aux administrateurs qui souhaitent restreindre la portée de l'interaction d'un utilisateur avec l'API Kubernetes. + +## Gestion des comptes utilisateurs + +Tous les clusters Kubernetes ont deux catégories d'utilisateurs : les comptes de service (ServiceAccount) gérés par Kubernetes et les utilisateurs normaux. + +Les utilisateurs normaux sont supposés être gérés par un service externe et indépendant, comme un administrateur distribuant des clés privées, un magasin d'utilisateurs tel que Keystone ou Google Accounts, voire un fichier contenant une liste de noms d'utilisateur et de mots de passe. À cet égard, Kubernetes ne dispose pas d'objets représentant des comptes d'utilisateurs normaux. Les utilisateurs normaux ne peuvent pas être ajoutés à un cluster via un appel API. + +En revanche, les comptes de service sont des utilisateurs gérés par l'API Kubernetes. Ils sont liés à des namespaces spécifiques et créés automatiquement par le serveur API ou manuellement via des appels API. Les comptes de service sont associés à un ensemble d'identifiants stockés sous forme de Secrets, qui sont montés dans des pods, permettant ainsi aux processus internes du cluster de communiquer avec l'API Kubernetes. + +Les demandes API sont associées soit à un utilisateur normal, soit à un compte de service, ou sont traitées comme des demandes anonymes. Cela signifie que chaque processus à l'intérieur ou à l'extérieur du cluster, qu'il s'agisse d'un utilisateur humain tapant `kubectl` sur une station de travail, de kubelets sur des nœuds, ou de membres du plan de contrôle, doit s'authentifier lorsqu'il fait des demandes au serveur API, ou être traité comme un utilisateur anonyme. + +## Roles, ClusterRoles, RoleBindings et ClusterRoleBindings + +Dans Kubernetes, les comptes utilisateurs et les comptes de service ne peuvent voir et modifier que les ressources auxquelles ils ont été autorisés. Cet accès est accordé par l'utilisation de Rôles et de RoleBindings. Les Rôles et les RoleBindings sont liés à un namespace particulier, ce qui accorde aux utilisateurs la possibilité de voir et/ou de modifier les ressources dans ce namespace auxquelles le Rôle leur donne accès. + +À l'échelle du cluster, ces objets sont appelés ClusterRoles et ClusterRoleBindings. Accorder à un utilisateur un ClusterRole lui donne accès pour voir et/ou modifier des ressources dans l'ensemble du cluster. Il est également nécessaire pour voir et/ou modifier des ressources à l'échelle du cluster (namespaces, quotas de ressources, nœuds). + +Les ClusterRoles peuvent être liés à un namespace particulier par le biais d'une référence dans un RoleBinding. Les ClusterRoles par défaut `admin`, `edit` et `view` sont souvent utilisés de cette manière. + +Voici quelques ClusterRoles disponibles par défaut dans Kubernetes. Ils sont destinés à être des rôles orientés utilisateur. Ils incluent des rôles super-utilisateur (`cluster-admin`), ainsi que des rôles avec un accès plus granulaire (`admin`, `edit`, `view`). + +| ClusterRole par défaut | ClusterRoleBinding par défaut | Description +|------------------------|-------------------------------|------------- +| `cluster-admin` | Groupe `system:masters` | Permet un accès super-utilisateur pour effectuer toute action sur n'importe quelle ressource. Lorsqu'il est utilisé dans un ClusterRoleBinding, il donne un contrôle total sur chaque ressource du cluster et dans tous les namespaces. Lorsqu'il est utilisé dans un RoleBinding, il donne un contrôle total sur chaque ressource dans le namespace du RoleBinding, y compris le namespace lui-même. +| `admin` | Aucun | Permet un accès administrateur, destiné à être accordé dans un namespace via un RoleBinding. Lorsqu'il est utilisé dans un RoleBinding, il permet un accès en lecture/écriture à la plupart des ressources dans un namespace, y compris la possibilité de créer des rôles et des RoleBindings dans le namespace. Il n'autorise pas l'accès en écriture aux quotas de ressources ou au namespace lui-même. +| `edit` | Aucun | Permet un accès en lecture/écriture à la plupart des objets dans un namespace. Il ne permet pas de voir ou de modifier les rôles ou les RoleBindings. +| `view` | Aucun | Permet un accès en lecture seule pour voir la plupart des objets dans un namespace. Il ne permet pas de voir les rôles ou les RoleBindings. Il ne permet pas de voir les secrets, car ceux-ci sont considérés comme des informations sensibles. + +## Restreindre l'accès d'un compte utilisateur en utilisant RBAC + +Maintenant que nous comprenons les bases du contrôle d'accès basé sur les rôles, discutons de la manière dont un administrateur peut restreindre le périmètre d'accès d'un utilisateur. + +### Exemple : Accorder à un utilisateur un accès en lecture/écriture à un namespace particulier + +Pour restreindre l'accès d'un utilisateur à un namespace particulier, nous pouvons utiliser soit le rôle `edit`, soit le rôle `admin`. Si vos charts créent ou interagissent avec des Roles et des RoleBindings, vous voudrez utiliser le ClusterRole `admin`. + +De plus, vous pouvez également créer un RoleBinding avec un accès `cluster-admin`. Accorder à un utilisateur un accès `cluster-admin` à l'échelle du namespace lui donne un contrôle total sur chaque ressource dans le namespace, y compris le namespace lui-même. + +Pour cet exemple, nous allons créer un utilisateur avec le rôle `edit`. Tout d'abord, créez le namespace : + +```console +$ kubectl create namespace foo +``` + +Maintenant, créez un RoleBinding dans ce namespace, accordant à l'utilisateur le rôle `edit`. + +```console +$ kubectl create rolebinding sam-edit + --clusterrole edit \​ + --user sam \​ + --namespace foo +``` + +### Exemple : Accorder à un utilisateur un accès en lecture/écriture à l'échelle du cluster + +Si un utilisateur souhaite installer un chart qui crée des ressources à l'échelle du cluster (namespaces, rôles, définitions de ressources personnalisées, etc.), il aura besoin d'un accès en écriture à l'échelle du cluster. + +Pour cela, accordez à l'utilisateur un accès `admin` ou `cluster-admin`. + +Accorder un accès `cluster-admin` à un utilisateur lui donne accès à toutes les ressources disponibles dans Kubernetes, y compris l'accès aux nœuds avec `kubectl drain` et d'autres tâches administratives. Il est fortement recommandé de considérer la possibilité de fournir à l'utilisateur un accès `admin` à la place, ou de créer un ClusterRole personnalisé adapté à ses besoins. + +```console +$ kubectl create clusterrolebinding sam-view + --clusterrole view \​ + --user sam + +$ kubectl create clusterrolebinding sam-secret-reader + --clusterrole secret-reader \​ + --user sam +``` + +### Exemple : Accorder à un utilisateur un accès en lecture seule à un namespace particulier + +Vous aurez peut-être remarqué qu'il n'existe pas de ClusterRole pour visualiser les secrets. Le ClusterRole `view` n'accorde pas à un utilisateur un accès en lecture aux Secrets en raison de préoccupations liées à l'escalade des privilèges. Helm stocke les métadonnées des releases sous forme de Secrets par défaut. + +Pour qu'un utilisateur puisse exécuter `helm list`, il doit être en mesure de lire ces secrets. Pour cela, nous allons créer un ClusterRole spécial appelé `secret-reader`. + +Créez le fichier `cluster-role-secret-reader.yaml` et écrivez le contenu suivant dans le fichier : + +```yaml +apiVersion: rbac.authorization.k8s.io/v1​ +kind: ClusterRole​ +metadata:​ + name: secret-reader​ +rules:​ +- apiGroups: [""]​ + resources: ["secrets"]​ + verbs: ["get", "watch", "list"] +``` + +Ensuite, créez le ClusterRole en utilisant la commande suivante : + +```console +$ kubectl create -f clusterrole-secret-reader.yaml​ +``` + +Une fois cela fait, nous pouvons accorder à un utilisateur un accès en lecture à la plupart des ressources, puis lui accorder un accès en lecture aux secrets : + +```console +$ kubectl create namespace foo + +$ kubectl create rolebinding sam-view + --clusterrole view \​ + --user sam \​ + --namespace foo + +$ kubectl create rolebinding sam-secret-reader + --clusterrole secret-reader \​ + --user sam \​ + --namespace foo +``` + +### Exemple : Accorder à un utilisateur un accès en lecture seule à l'échelle du cluster + +Dans certains scénarios, il peut être avantageux d'accorder à un utilisateur un accès à l'échelle du cluster. Par exemple, si un utilisateur souhaite exécuter la commande `helm list --all-namespaces`, l'API exige que l'utilisateur dispose d'un accès en lecture à l'échelle du cluster. + +Pour ce faire, accordez à l'utilisateur à la fois les accès `view` et `secret-reader` comme décrit ci-dessus, mais avec un ClusterRoleBinding. + +```console +$ kubectl create clusterrolebinding sam-view + --clusterrole view \​ + --user sam + +$ kubectl create clusterrolebinding sam-secret-reader + --clusterrole secret-reader \​ + --user sam +``` + +## Réflexions supplémentaires + +Les exemples ci-dessus utilisent les ClusterRoles par défaut fournis avec Kubernetes. Pour un contrôle plus granulaire sur les ressources auxquelles les utilisateurs ont accès, consultez [la documentation de Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) sur la création de vos propres rôles et ClusterRoles personnalisés. diff --git a/content/fr/docs/topics/registries.md b/content/fr/docs/topics/registries.md new file mode 100644 index 000000000..f5f4ced30 --- /dev/null +++ b/content/fr/docs/topics/registries.md @@ -0,0 +1,235 @@ +--- +title: "Utiliser des registres basés sur OCI" +description: "Décrit comment utiliser OCI pour la distribution de Charts" +weight: 7 +--- + +À partir de Helm 3, vous pouvez utiliser des registres de conteneurs avec la prise en charge d'[OCI](https://www.opencontainers.org/) pour stocker et partager des packages de charts. À partir de Helm v3.8.0, la prise en charge d'OCI est activée par défaut. + + +## Prise en charge d'OCI avant la version 3.8.0 + +La prise en charge d'OCI est passée du statut expérimental à la disponibilité générale avec Helm v3.8.0. Dans les versions antérieures de Helm, le support OCI fonctionnait différemment. Si vous utilisiez le support OCI avant Helm v3.8.0, il est important de comprendre ce qui a changé avec les différentes versions de Helm. + +### Activer le support OCI avant la version v3.8.0 + +Avant Helm v3.8.0, le support OCI est *expérimental* et doit être activé. + +Pour activer le support expérimental OCI pour les versions de Helm antérieures à la v3.8.0, définissez `HELM_EXPERIMENTAL_OCI` dans votre environnement. Par exemple : + +```console +export HELM_EXPERIMENTAL_OCI=1 +``` + +### Fonctionnalités dépréciés d'OCI et changements de comportement avec la v3.8.0 + +Avec la sortie de [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0), les fonctionnalités et comportements suivants diffèrent des versions précédentes de Helm : + +- Lors de la définition d'un chart dans les dépendances en tant qu'OCI, la version peut être définie sur une plage comme pour les autres dépendances. +- Les tags SemVer incluant des informations de build peuvent être poussés et utilisés. Les registres OCI ne supportent pas `+` comme caractère de tag. Helm traduit le `+` en `_` lorsqu'il est stocké comme tag. +- La commande `helm registry login` suit désormais la même structure que celle de la CLI Docker pour le stockage des identifiants. Le même emplacement pour la configuration du registre peut être utilisé pour Helm et la CLI Docker. + +### Fonctionnalités dépréciés d'OCI et changements de comportement avec la v3.7.0 + +La sortie de [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) a inclus la mise en œuvre de [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) pour le support OCI. En conséquence, les fonctionnalités et comportements suivants diffèrent des versions précédentes de Helm : + +- La sous-commande `helm chart` a été supprimée. +- Le cache de chart a été supprimé (plus de `helm chart list`, etc.). +- Les références aux registres OCI sont désormais toujours préfixées par `oci://`. +- Le nom de base de la référence au registre doit *toujours* correspondre au nom du chart. +- Le tag de la référence au registre doit *toujours* correspondre à la version sémantique du chart (c'est-à-dire pas de tags `latest`). +- Le type de média de la couche du chart a été changé de `application/tar+gzip` à `application/vnd.cncf.helm.chart.content.v1.tar+gzip`. + + +## Utiliser un registre basé sur OCI + +### Les dépôts Helm dans les registres basés sur OCI + +Un [dépôt Helm]({{< ref "chart_repository.md" >}}) est un moyen de stocker et de distribuer des charts Helm empaquetés. Un registre basé sur OCI peut contenir zéro ou plusieurs dépôts Helm, et chacun de ces dépôts peut contenir zéro ou plusieurs charts Helm empaquetés. + +### Utiliser des registres hébergés + +Il existe plusieurs registres de conteneurs hébergés avec support d'OCI que vous pouvez utiliser pour vos charts Helm. Par exemple : + +- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) +- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) +- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) +- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) +- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) +- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) +- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) + + +Suivez la documentation du fournisseur de registre de conteneurs hébergés pour créer et configurer un registre avec support d'OCI. + +**Remarque :** Vous pouvez exécuter [Docker Registry](https://docs.docker.com/registry/deploying/) ou [`zot`](https://github.com/project-zot/zot), qui sont des registres basés sur OCI, sur votre ordinateur de développement. L'exécution d'un registre basé sur OCI sur votre ordinateur de développement ne doit être utilisée qu'à des fins de test. + +### Utiliser sigstore pour signer des charts basés sur OCI + +Le plugin [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) permet d'utiliser [Sigstore](https://sigstore.dev/) pour signer des charts Helm avec les mêmes outils utilisés pour signer des images de conteneurs. Cela constitue une alternative à la provenance basée sur [GPG]({{< ref "provenance.md" >}}) supportée par les [dépôts de charts classiques]({{< ref "chart_repository.md" >}}). + +Pour plus de détails sur l'utilisation du plugin `helm sigstore`, consultez [la documentation de ce projet](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). + +## Commandes pour travailler avec les registres + +### La sous-commande `registry` + +#### `login` + +Se connecter à un registre (avec saisie manuelle du mot de passe) + +```console +$ helm registry login -u myuser localhost:5000 +Password: +Login succeeded +``` + +#### `logout` + +Se déconnecter d'un registre + +```console +$ helm registry logout localhost:5000 +Logout succeeded +``` + +### La sous-commande `push` + +Télécharger un chart vers un registre basé sur OCI : + +```console +$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts +Pushed: localhost:5000/helm-charts/mychart:0.1.0 +Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 +``` + +La sous-commande `push` ne peut être utilisée qu'avec des fichiers `.tgz` créés au préalable avec `helm package`. + +Lors de l'utilisation de `helm push` pour télécharger un chart vers un registre OCI, la référence doit être préfixée par `oci://` et ne doit pas contenir le nom de base ni le tag. + +Le nom de base de la référence du registre est déduit du nom du chart, et le tag est déduit de la version sémantique du chart. C'est actuellement une exigence stricte. + +Certain registries require the repository and/or namespace (if specified) +to be created beforehand. Otherwise, an error will be produced during the + `helm push` operation. + +Si vous avez créé un [fichier de provenance]({{< ref "provenance.md" >}}) (`.prov`) et qu'il est présent à côté du fichier `.tgz` du chart, il sera automatiquement téléchargé vers le registre lors de l'opération `push`. Cela ajoute une couche supplémentaire sur [le manifeste du chart Helm](#helm-chart-manifest). + +Les utilisateurs du [plugin helm-push](https://github.com/chartmuseum/helm-push) (pour télécharger des charts vers [ChartMuseum]({{}}) peuvent rencontrer des problèmes, car le plugin entre en conflit avec la nouvelle fonction `push` intégrée. Depuis la version v0.10.0, le plugin a été renommé en `cm-push`. + +### Autres sous-commandes + +Le support du protocole `oci://` est également disponible dans diverses autres sous-commandes. Voici la liste complète : + +- `helm pull` +- `helm show ` +- `helm template` +- `helm install` +- `helm upgrade` + +Le nom de base (nom du chart) de la référence du registre *est* inclus pour tout type d'action impliquant le téléchargement de charts (contrairement à `helm push` où il est omis). + +Voici quelques exemples d'utilisation des sous-commandes listées ci-dessus avec des charts basés sur OCI : + +``` +$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 +Pulled: localhost:5000/helm-charts/mychart:0.1.0 +Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff + +$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 +apiVersion: v2 +appVersion: 1.16.0 +description: A Helm chart for Kubernetes +name: mychart +... + +$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 +--- +# Source: mychart/templates/serviceaccount.yaml +apiVersion: v1 +kind: ServiceAccount +... + +$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 +NAME: myrelease +LAST DEPLOYED: Wed Oct 27 15:11:40 2021 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +NOTES: +... + +$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 +Release "myrelease" has been upgraded. Happy Helming! +NAME: myrelease +LAST DEPLOYED: Wed Oct 27 15:12:05 2021 +NAMESPACE: default +STATUS: deployed +REVISION: 2 +NOTES: +... +``` + +## Spécifier des dépendances + +Les dépendances d'un chart peuvent être récupérées depuis un registre en utilisant la sous-commande `dependency update`. + +Le `repository` pour une entrée donnée dans `Chart.yaml` est spécifié comme la référence du registre sans le nom de base : + +``` +dependencies: + - name: mychart + version: "2.7.0" + repository: "oci://localhost:5000/myrepo" +``` +Cela récupérera `oci://localhost:5000/myrepo/mychart:2.7.0` lorsque `dependency update` est exécuté. + +## Manifeste de chart Helm + +Exemple de manifeste de chart Helm tel qu'il est représenté dans un registre (remarquez les champs `mediaType`) : +```json +{ + "schemaVersion": 2, + "config": { + "mediaType": "application/vnd.cncf.helm.config.v1+json", + "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", + "size": 117 + }, + "layers": [ + { + "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", + "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", + "size": 2487 + } + ] +} +``` + +L'exemple suivant contient un [fichier de provenance]({{< ref "provenance.md" >}}) (remarquez la couche supplémentaire) : + +```json +{ + "schemaVersion": 2, + "config": { + "mediaType": "application/vnd.cncf.helm.config.v1+json", + "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", + "size": 117 + }, + "layers": [ + { + "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", + "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", + "size": 2487 + }, + { + "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", + "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", + "size": 643 + } + ] +} +``` + +## Migrer depuis les dépôts de charts + +La migration depuis les [dépôts de charts classiques]({{< ref "chart_repository.md" >}}) (dépôts basés sur index.yaml) est aussi simple que d'utiliser `helm pull`, puis d'utiliser `helm push` pour télécharger les fichiers `.tgz` résultants vers un registre. diff --git a/content/fr/docs/topics/release_policy.md b/content/fr/docs/topics/release_policy.md new file mode 100644 index 000000000..2e599b164 --- /dev/null +++ b/content/fr/docs/topics/release_policy.md @@ -0,0 +1,43 @@ +--- +title: "Politique de planification des versions" +description: "Décrit la politique de planification des versions de Helm" +--- + +Pour le bénéfice de ses utilisateurs, Helm définit et annonce les dates de publication à l'avance. Ce document décrit la politique régissant le calendrier des versions de Helm. + +## Calendrier des sorties + +Un calendrier public montrant les prochaines versions de Helm peut être consulté [ici](https://helm.sh/calendar/release). + +## Versionnage sémantique + +Les versions de Helm sont exprimées sous la forme `x.y.z`, où `x` est la version majeure, `y` est la version mineure et `z` est la version de correction, conformément à la terminologie du [Versionnage Sémantique](https://semver.org/spec/v2.0.0.html). + +## Versions de correction + +Les versions de correction fournissent aux utilisateurs des corrections de bogues et des correctifs de sécurité. Elles ne contiennent pas de nouvelles fonctionnalités. + +Une nouvelle version de correction relative à la dernière version mineure/majeure sera normalement publiée une fois par mois, le deuxième mercredi de chaque mois. + +Une version de correction pour résoudre un problème de régression ou de sécurité de haute priorité peut être publiée dès que nécessaire. + +Une version de correction sera annulée pour l'une des raisons suivantes : +- s'il n'y a pas de nouveau contenu depuis la version précédente +- si la date de la version de correction tombe dans la semaine précédant le premier candidat à la publication (RC1) d'une version mineure à venir +- si la date de la version de correction tombe dans les quatre semaines suivant une version mineure + +## Versions mineures + +Les versions mineures contiennent des corrections de sécurité et de bogues ainsi que de nouvelles fonctionnalités. Elles sont compatibles avec les versions précédentes en ce qui concerne l'API et l'utilisation de l'interface en ligne de commande (CLI). + +Pour s'aligner sur les versions de Kubernetes, une version mineure de Helm sera publiée tous les 4 mois (3 versions par an). + +Des versions mineures supplémentaires peuvent être publiées si nécessaire, mais elles n'affecteront pas le calendrier d'une version future annoncée, sauf si la version annoncée est prévue dans moins de 7 jours. + +En même temps qu'une version est publiée, la date de la prochaine version mineure sera annoncée et publiée sur la page principale de Helm. + +## Versions majeures + +Les versions majeures contiennent des changements incompatibles avec les versions précédentes. Ces versions sont rares mais parfois nécessaires pour permettre à Helm de continuer à évoluer dans des directions nouvelles et importantes. + +Les versions majeures peuvent être difficiles à planifier. Dans cette optique, une date de publication finale ne sera choisie et annoncée qu'une fois que la première version bêta de cette version sera disponible. diff --git a/content/fr/docs/topics/v2_v3_migration.md b/content/fr/docs/topics/v2_v3_migration.md new file mode 100644 index 000000000..7446cd078 --- /dev/null +++ b/content/fr/docs/topics/v2_v3_migration.md @@ -0,0 +1,78 @@ +--- +title: "Migration de Helm v2 vers v3" +description: "Apprenez comment migrer Helm v2 vers v3" +weight: 13 +--- + +Ce guide explique comment migrer Helm v2 vers v3. Helm v2 doit être installé et gérer des releases dans un ou plusieurs clusters. + +## Aperçu des changements dans Helm 3 + +La liste complète des changements entre Helm 2 et 3 est documentée dans la [section FAQ](https://v3.helm.sh/docs/faq/#changes-since-helm-2). Voici un résumé de certains de ces changements qu'un utilisateur devrait connaître avant et pendant la migration : + +1. Suppression de Tiller : + - Remplacement de l'architecture client/serveur par une architecture client/bibliothèque (seul le binaire `helm` est utilisé) + - La sécurité est désormais basée sur chaque utilisateur (déléguée à la sécurité de l'utilisateur du cluster Kubernetes) + - Les releases sont désormais stockées en tant que secrets dans le cluster, et les métadonnées de l'objet release ont changé + - Les releases sont conservées dans l'espace de noms de la release, et non plus dans l'espace de noms de Tiller +2. Mise à jour du dépôt de charts : + - `helm search` prend désormais en charge les recherches locales dans le dépôt et permet d'effectuer des requêtes de recherche sur Artifact Hub +3. Version d'api des charts passée à "v2" avec les changements suivants : + - Les dépendances de charts liées dynamiquement ont été déplacées vers `Chart.yaml` (suppression de `requirements.yaml` et remplacement de requirements par dependencies) + - Les charts de bibliothèque (charts d'assistance/communs) peuvent désormais être ajoutés en tant que dépendances de charts liées dynamiquement + - Les charts ont un champ de métadonnées `type` pour définir s'ils sont de type `application` ou `library`. Par défaut, c'est une application, ce qui signifie qu'il est rendu et installable + - Les charts Helm 2 (apiVersion=v1) sont toujours installables +4. Ajout de la spécification des répertoires XDG : + - Le répertoire Helm home est supprimé et remplacé par la spécification des répertoires XDG pour le stockage des fichiers de configuration + - Il n'est plus nécessaire d'initialiser Helm + - Les commandes `helm init` et `helm home` sont supprimées +5. Autres changements : + - L'installation/mise en place de Helm est simplifiée : + - Client Helm uniquement (binaire helm sans Tiller) + - Paradigme "run-as-is" + - Les dépôts `local` ou `stable` ne sont plus configurés par défaut + - Le hook `crd-install` est supprimé et remplacé par le répertoire `crds` dans le chart où tous les CRD définis y seront installés avant le rendu du chart + - L'annotation `test-failure` est supprimée, et `test-success` est dépréciée. Utilisez `test` à la place + - Commandes supprimées/remplacées/ajoutées : + - delete --> uninstall : supprime tout l'historique de la release par défaut (nécessitait auparavant `--purge`) + - fetch --> pull + - home (supprimé) + - init (supprimé) + - install : nécessite un nom de release ou l'argument `--generate-name` + - inspect --> show + - reset (supprimé) + - serve (supprimé) + - template : l'argument `-x`/`--execute` est renommé en `-s`/`--show-only` + - upgrade : ajout de l'argument `--history-max` qui limite le nombre maximum de révisions sauvegardées par release (0 pour aucune limite) + - La bibliothèque Go de Helm 3 a subi de nombreuses modifications et est incompatible avec la bibliothèque de Helm 2 + - Les binaires de release sont désormais hébergés sur `get.helm.sh` + +## Cas d'utilisation de la migration + +Les cas d'utilisation de la migration sont les suivants : + +1. Helm v2 et v3 gérant le même cluster : + - Ce cas d'utilisation est recommandé uniquement si vous envisagez de supprimer progressivement Helm v2 et que vous ne souhaitez pas que v3 gère les releases déployées par v2. Toutes les nouvelles releases doivent être déployées par v3, et les releases existantes déployées par v2 doivent être mises à jour ou supprimées uniquement par v2. + - Helm v2 et v3 peuvent coexister dans le même cluster. Les deux versions peuvent être installées sur le même système ou sur des systèmes séparés. + - Si Helm v3 est installé sur le même système que Helm v2, il est nécessaire d'effectuer une étape supplémentaire pour permettre la coexistence des deux versions jusqu'à la suppression de Helm v2. Il faut renommer ou déplacer le binaire de Helm v3 dans un autre dossier pour éviter les conflits. + - Il n'y a pas d'autres conflits entre les deux versions en raison des distinctions suivantes : + - Le stockage des releases (historique) de v2 et v3 est indépendant. Les changements incluent les ressources Kubernetes pour le stockage et les métadonnées des objets de release contenus dans la ressource. Les releases sont également basées sur l'espace de noms de l'utilisateur, plutôt que d'utiliser l'espace de noms de Tiller (par exemple, dans v2, l'espace de noms par défaut de Tiller est kube-system). v2 utilise des "ConfigMaps" ou "Secrets" dans l'espace de noms de Tiller avec la propriété `TILLER`. v3 utilise des "Secrets" dans l'espace de noms de l'utilisateur avec la propriété `helm`. Les releases sont incrémentielles dans v2 et v3. + - Le seul problème pourrait survenir si des ressources à l'échelle du cluster Kubernetes (par exemple, `clusterroles.rbac`) sont définies dans un chart. Le déploiement avec v3 échouerait dans ce cas même si la ressource est unique dans l'espace de noms, car les ressources se chevaucheraient. + - La configuration de v3 n'utilise plus `$HELM_HOME` et repose désormais sur la spécification des répertoires XDG. Elle est créée à la volée si nécessaire, rendant v3 indépendant de la configuration de v2. Cela ne s'applique que lorsque les deux versions sont installées sur le même système. +2. Migration de Helm v2 vers Helm v3 : + - Ce cas d'utilisation s'applique lorsque vous souhaitez que Helm v3 gère les releases existantes de Helm v2. + - Il est important de noter que le client Helm v2 : + - peut gérer un ou plusieurs clusters Kubernetes + - peut se connecter à une ou plusieurs instances de Tiller dans un cluster + - Cela signifie qu'il faut en être conscient lors de la migration, car les releases sont déployées dans les clusters par Tiller et son espace de noms. Il est donc nécessaire de gérer la migration pour chaque cluster et chaque instance de Tiller gérée par l'instance du client Helm v2. + - Le chemin de migration recommandé pour les données est le suivant : + 1. Sauvegarder les données de v2 + 2. Migrer la configuration de Helm v2 + 3. Migrer les releases de Helm v2 + 4. Une fois que vous êtes sûr que Helm v3 gère toutes les données de Helm v2 (pour tous les clusters et instances de Tiller du client Helm v2) comme prévu, nettoyez les données de Helm v2. + - Le processus de migration est automatisé par le plugin Helm v3 [2to3](https://github.com/helm/helm-2to3). + +## Références + + - Plugin Helm v3 [2to3](https://github.com/helm/helm-2to3) + - Article de blog [posté ici](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) expliquant l'utilisation du plugin `2to3` avec des exemples. diff --git a/content/fr/docs/topics/version_skew.md b/content/fr/docs/topics/version_skew.md new file mode 100644 index 000000000..dda208ecc --- /dev/null +++ b/content/fr/docs/topics/version_skew.md @@ -0,0 +1,61 @@ +--- +title: "Politique de support des versions de Helm" +description: "Décrit la politique de publication des versions de correction de Helm ainsi que l'écart de version maximal supporté entre Helm et Kubernetes" +--- + +Ce document décrit l'écart de version maximal supporté entre Helm et Kubernetes. + +## Versions supportées + +Les versions de Helm sont exprimées sous la forme `x.y.z`, où `x` est la version majeure, `y` est la version mineure et `z` est la version de correction, conformément à la terminologie du [Versionnage Sémantique](https://semver.org/spec/v2.0.0.html). + +Le projet Helm maintient une branche de version pour la dernière version mineure en date. Les correctifs applicables, y compris les correctifs de sécurité, sont sélectionnés et intégrés dans la branche de version, en fonction de la gravité et de la faisabilité. Plus de détails peuvent être trouvés dans la [politique de publication de Helm]({{}}). + +## Écart de version supporté + +Lorsqu'une nouvelle version de Helm est publiée, elle est compilée contre une version mineure particulière de Kubernetes. Par exemple, Helm 3.0.0 interagit avec Kubernetes en utilisant le client Kubernetes 1.16.2, donc elle est compatible avec Kubernetes 1.16. + +À partir de Helm 3, Helm est supposé être compatible avec les versions de Kubernetes allant jusqu'à `n-3` versions par rapport à celle contre laquelle il a été compilé. En raison des changements dans Kubernetes entre les versions mineures, la politique de support de Helm 2 est légèrement plus stricte, en supposant une compatibilité avec les versions `n-1` de Kubernetes. + +Par exemple, si vous utilisez une version de Helm 3 qui a été compilée avec les API client de Kubernetes 1.17, alors il devrait être sûr de l'utiliser avec Kubernetes 1.17, 1.16, 1.15 et 1.14. Si vous utilisez une version de Helm 2 qui a été compilée avec les API client de Kubernetes 1.16, alors il devrait être sûr de l'utiliser avec Kubernetes 1.16 et 1.15. + +Il n'est pas recommandé d'utiliser Helm avec une version de Kubernetes plus récente que celle contre laquelle il a été compilé, car Helm ne fournit aucune garantie de compatibilité ascendante. + +Si vous choisissez d'utiliser Helm avec une version de Kubernetes qu'il ne prend pas en charge, vous le faites à vos propres risques. + +Veuillez consulter le tableau ci-dessous pour déterminer quelle version de Helm est compatible avec votre cluster. + +| Version d'Helm | Versions de Kubernetes supportées | +|----------------|-----------------------------------| +| 3.14.x | 1.29.x - 1.26.x | +| 3.13.x | 1.28.x - 1.25.x | +| 3.12.x | 1.27.x - 1.24.x | +| 3.11.x | 1.26.x - 1.23.x | +| 3.10.x | 1.25.x - 1.22.x | +| 3.9.x | 1.24.x - 1.21.x | +| 3.8.x | 1.23.x - 1.20.x | +| 3.7.x | 1.22.x - 1.19.x | +| 3.6.x | 1.21.x - 1.18.x | +| 3.5.x | 1.20.x - 1.17.x | +| 3.4.x | 1.19.x - 1.16.x | +| 3.3.x | 1.18.x - 1.15.x | +| 3.2.x | 1.18.x - 1.15.x | +| 3.1.x | 1.17.x - 1.14.x | +| 3.0.x | 1.16.x - 1.13.x | +| 2.16.x | 1.16.x - 1.15.x | +| 2.15.x | 1.15.x - 1.14.x | +| 2.14.x | 1.14.x - 1.13.x | +| 2.13.x | 1.13.x - 1.12.x | +| 2.12.x | 1.12.x - 1.11.x | +| 2.11.x | 1.11.x - 1.10.x | +| 2.10.x | 1.10.x - 1.9.x | +| 2.9.x | 1.10.x - 1.9.x | +| 2.8.x | 1.9.x - 1.8.x | +| 2.7.x | 1.8.x - 1.7.x | +| 2.6.x | 1.7.x - 1.6.x | +| 2.5.x | 1.6.x - 1.5.x | +| 2.4.x | 1.6.x - 1.5.x | +| 2.3.x | 1.5.x - 1.4.x | +| 2.2.x | 1.5.x - 1.4.x | +| 2.1.x | 1.5.x - 1.4.x | +| 2.0.x | 1.4.x - 1.3.x | From 77a29f81f9bc09b6edd6cc90510b42643c839bcc Mon Sep 17 00:00:00 2001 From: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Fri, 27 Sep 2024 22:53:17 +0200 Subject: [PATCH 07/15] Translate chart_template_guide in french Signed-off-by: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- .../fr/docs/chart_template_guide/_index.md | 18 + .../chart_template_guide/accessing_files.md | 205 ++ .../chart_template_guide/builtin_objects.md | 46 + .../control_structures.md | 387 +++ .../docs/chart_template_guide/data_types.md | 18 + .../fr/docs/chart_template_guide/debugging.md | 32 + .../chart_template_guide/function_list.md | 2089 +++++++++++++++++ .../functions_and_pipelines.md | 204 ++ .../chart_template_guide/getting_started.md | 216 ++ .../chart_template_guide/helm_ignore_file.md | 58 + .../chart_template_guide/named_templates.md | 287 +++ .../docs/chart_template_guide/notes_files.md | 49 + .../subcharts_and_globals.md | 206 ++ .../docs/chart_template_guide/values_files.md | 158 ++ .../fr/docs/chart_template_guide/variables.md | 132 ++ .../docs/chart_template_guide/wrapping_up.md | 26 + .../chart_template_guide/yaml_techniques.md | 295 +++ 17 files changed, 4426 insertions(+) create mode 100644 content/fr/docs/chart_template_guide/_index.md create mode 100644 content/fr/docs/chart_template_guide/accessing_files.md create mode 100644 content/fr/docs/chart_template_guide/builtin_objects.md create mode 100644 content/fr/docs/chart_template_guide/control_structures.md create mode 100644 content/fr/docs/chart_template_guide/data_types.md create mode 100644 content/fr/docs/chart_template_guide/debugging.md create mode 100644 content/fr/docs/chart_template_guide/function_list.md create mode 100644 content/fr/docs/chart_template_guide/functions_and_pipelines.md create mode 100644 content/fr/docs/chart_template_guide/getting_started.md create mode 100644 content/fr/docs/chart_template_guide/helm_ignore_file.md create mode 100644 content/fr/docs/chart_template_guide/named_templates.md create mode 100644 content/fr/docs/chart_template_guide/notes_files.md create mode 100644 content/fr/docs/chart_template_guide/subcharts_and_globals.md create mode 100644 content/fr/docs/chart_template_guide/values_files.md create mode 100644 content/fr/docs/chart_template_guide/variables.md create mode 100644 content/fr/docs/chart_template_guide/wrapping_up.md create mode 100644 content/fr/docs/chart_template_guide/yaml_techniques.md diff --git a/content/fr/docs/chart_template_guide/_index.md b/content/fr/docs/chart_template_guide/_index.md new file mode 100644 index 000000000..6f3a6f50e --- /dev/null +++ b/content/fr/docs/chart_template_guide/_index.md @@ -0,0 +1,18 @@ +--- +title: "Guide de modèle de chart" +weight: 5 +--- + +# Le Guide du Développeur de Modèles de Chart + +Ce guide propose une introduction aux modèles de chart Helm, en mettant l'accent sur le langage de modèle. + +Les modèles génèrent des fichiers de manifestes, qui sont des descriptions de ressources au format YAML compréhensibles par Kubernetes. Nous examinerons comment les modèles sont structurés, comment ils peuvent être utilisés, comment écrire des modèles Go, et comment déboguer votre travail. + +Ce guide se concentre sur les concepts suivants : + +- Le langage de modèle Helm +- Utilisation des valeurs +- Techniques pour travailler avec les modèles + +Ce guide est axé sur l'apprentissage des détails du langage de modèle Helm. D'autres guides fournissent des informations introductives, des exemples et des bonnes pratiques. diff --git a/content/fr/docs/chart_template_guide/accessing_files.md b/content/fr/docs/chart_template_guide/accessing_files.md new file mode 100644 index 000000000..8515837de --- /dev/null +++ b/content/fr/docs/chart_template_guide/accessing_files.md @@ -0,0 +1,205 @@ +--- +title: "Accès aux fichiers à l'intérieur des modèles" +description: "Comment accéder aux fichiers depuis un modèle" +weight: 10 +--- + +Dans la section précédente, nous avons examiné plusieurs façons de créer et d'accéder à des modèles nommés. Cela facilite l'importation d'un modèle à partir d'un autre modèle. Mais il arrive parfois qu'il soit souhaitable d'importer un _fichier qui n'est pas un modèle_ et d'injecter son contenu sans passer par le moteur de rendu des modèles. + +Helm permet d'accéder aux fichiers via l'objet `.Files`. Avant de commencer avec les exemples de modèles, il y a quelques points à noter concernant son fonctionnement : + +- Il est acceptable d'ajouter des fichiers supplémentaires à votre chart Helm. Ces fichiers seront inclus. Faites cependant attention, car les charts doivent être inférieurs à 1 Mo en raison des limitations de stockage des objets Kubernetes. +- Certains fichiers ne peuvent pas être accédés via l'objet `.Files`, généralement pour des raisons de sécurité : + - Les fichiers dans `templates/` ne peuvent pas être accédés. + - Les fichiers exclus à l'aide de `.helmignore` ne peuvent pas être accédés. + - Les fichiers en dehors d'une application Helm [sous-chart]({{< ref "/docs/chart_template_guide/subcharts_and_globals.md" >}}), y compris ceux du parent, ne peuvent pas être accédés. +- Les charts ne conservent pas les informations de mode UNIX, donc les permissions au niveau des fichiers n'affecteront pas la disponibilité d'un fichier via l'objet `.Files`. + + + + + +- [Exemple de base](#exemple-de-base) +- [Aides pour les chemins](#aides-pour-les-chemins) +- [Modèles Glob](#modèles-glob) +- [Fonctions utilitaires pour ConfigMap et Secrets](#fonctions-utilitaires-pour-configmap-et-secrets) +- [Encoding](#encoding) +- [Lines](#lines) + + + +## Exemple de base + +Avec ces mises en garde en tête, rédigeons un modèle qui lit trois fichiers dans notre ConfigMap. Pour commencer, nous allons ajouter trois fichiers au chart, en plaçant les trois directement dans le répertoire `mychart/`. + +`config1.toml`: + +```toml +message = Hello from config 1 +``` + +`config2.toml`: + +```toml +message = This is config 2 +``` + +`config3.toml`: + +```toml +message = Goodbye from config 3 +``` + +Chacun de ces fichiers est un simple fichier TOML (pensez aux anciens fichiers INI de Windows). Nous connaissons les noms de ces fichiers, nous pouvons donc utiliser une fonction `range` pour les parcourir et injecter leur contenu dans notre ConfigMap. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + {{- $files := .Files }} + {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} + {{ . }}: |- + {{ $files.Get . }} + {{- end }} +``` + +Ce ConfigMap utilise plusieurs des techniques abordées dans les sections précédentes. Par exemple, nous créons une variable `$files` pour contenir une référence à l'objet `.Files`. Nous utilisons également la fonction `tuple` pour créer une liste de fichiers que nous parcourons. Ensuite, nous affichons chaque nom de fichier (`{{ . }}: |-`) suivi du contenu du fichier `{{ $files.Get . }}`. + +L'exécution de ce modèle produira un seul ConfigMap contenant le contenu des trois fichiers : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: quieting-giraf-configmap +data: + config1.toml: |- + message = Hello from config 1 + + config2.toml: |- + message = This is config 2 + + config3.toml: |- + message = Goodbye from config 3 +``` + +## Aides pour les chemins + +Lorsque vous travaillez avec des fichiers, il peut être très utile d'effectuer certaines opérations standard sur les chemins de fichiers eux-mêmes. Pour vous aider, Helm importe de nombreuses fonctions du package [path](https://golang.org/pkg/path/) de Go pour votre utilisation. Elles sont toutes accessibles avec les mêmes noms que dans le package Go, mais avec une première lettre en minuscule. Par exemple, `Base` devient `base`, etc. + +Les fonctions importées sont : +- `base` +- `dir` +- `ext` +- `isAbs` +- `clean` + +## Modèles glob + +À mesure que votre chart grandit, vous pourriez avoir besoin d'organiser davantage vos fichiers. Nous fournissons donc une méthode `Files.Glob(pattern string)` pour aider à extraire certains fichiers avec toute la flexibilité des [modèles glob](https://godoc.org/github.com/gobwas/glob). + +`.Glob` renvoie un type `Files`, vous pouvez donc appeler n'importe quelle méthode `Files` sur l'objet retourné. + +Par exemple, imaginez la structure de répertoire suivante : + +``` +foo/: + foo.txt foo.yaml + +bar/: + bar.go bar.conf baz.yaml +``` + +Vous avez plusieurs options avec les modèles glob : + +```yaml +{{ $currentScope := .}} +{{ range $path, $_ := .Files.Glob "**.yaml" }} + {{- with $currentScope}} + {{ .Files.Get $path }} + {{- end }} +{{ end }} +``` + +Ou + +```yaml +{{ range $path, $_ := .Files.Glob "**.yaml" }} + {{ $.Files.Get $path }} +{{ end }} +``` + +## Fonctions utilitaires pour ConfigMap et Secrets + +(Disponible à partir de Helm 2.0.2) + +Il est très courant de vouloir placer le contenu de fichiers à la fois dans des ConfigMaps et des Secrets, afin de les monter dans vos pods au moment de l'exécution. Pour vous aider, nous fournissons quelques méthodes utilitaires sur le type `Files`. + +Pour une meilleure organisation, il est particulièrement utile d'utiliser ces méthodes en conjonction avec la méthode `Glob`. + +Étant donné la structure de répertoire de l'exemple [Glob](#modèles-glob) ci-dessus : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: conf +data: +{{ (.Files.Glob "foo/*").AsConfig | indent 2 }} +--- +apiVersion: v1 +kind: Secret +metadata: + name: very-secret +type: Opaque +data: +{{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} +``` + +## Encodage + +Vous pouvez importer un fichier et faire en sorte que le modèle l'encode en base64 pour garantir une transmission réussie : + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: {{ .Release.Name }}-secret +type: Opaque +data: + token: |- + {{ .Files.Get "config1.toml" | b64enc }} +``` + +Ce qui précède prendra le même fichier `config1.toml` que nous avons utilisé précédemment et l'encodera : + +```yaml +# Source : mychart/templates/secret.yaml +apiVersion: v1 +kind: Secret +metadata: + name: lucky-turkey-secret +type: Opaque +data: + token: |- + bWVzc2FnZSA9IEhlbGxvIGZyb20gY29uZmlnIDEK +``` + +## Lignes + +Parfois, il est souhaitable d'accéder à chaque ligne d'un fichier dans votre modèle. Nous fournissons une méthode pratique `Lines` pour cela. + +Vous pouvez parcourir `Lines` en utilisant une fonction `range` : + +```yaml +data: + some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} + {{ . }}{{ end }} +``` + +Il n'est pas possible de passer des fichiers externes au chart lors de l'exécution de `helm install`. Donc, si vous demandez aux utilisateurs de fournir des données, celles-ci doivent être chargées en utilisant `helm install -f` ou `helm install --set`. + +Cette discussion conclut notre exploration des outils et techniques pour écrire des modèles Helm. Dans la section suivante, nous verrons comment vous pouvez utiliser un fichier spécial, `templates/NOTES.txt`, pour envoyer des instructions post-installation aux utilisateurs de votre chart. diff --git a/content/fr/docs/chart_template_guide/builtin_objects.md b/content/fr/docs/chart_template_guide/builtin_objects.md new file mode 100644 index 000000000..e63993c91 --- /dev/null +++ b/content/fr/docs/chart_template_guide/builtin_objects.md @@ -0,0 +1,46 @@ +--- +title: "Objets intégrés" +description: "Objets intégrés disponibles pour les templates" +weight: 3 +--- + +Les objets sont transmis à un template par le moteur de templates. Votre code peut également passer des objets d'un endroit à un autre (nous verrons des exemples en étudiant les déclarations `with` et `range`). Il existe même quelques méthodes pour créer de nouveaux objets au sein de vos templates, comme avec la fonction `tuple` que nous aborderons plus tard. + +Les objets peuvent être simples et n’avoir qu’une seule valeur. Ou bien, ils peuvent contenir d’autres objets ou fonctions. Par exemple, l’objet `Release` contient plusieurs sous-objets (comme `Release.Name`), et l’objet `Files` possède plusieurs fonctions. + +Dans la section précédente, nous avons utilisé `{{ .Release.Name }}` pour insérer le nom d'une release dans un template. `Release` est l'un des objets de haut niveau que vous pouvez accéder dans vos templates. + +- `Release` : Cet objet décrit la release elle-même et contient plusieurs objets à l'intérieur : + - `Release.Name` : Le nom de la release. + - `Release.Namespace` : Le namespace dans lequel la release sera déployée (sauf si le manifest en décide autrement). + - `Release.IsUpgrade` : Défini à `true` si l'opération actuelle est une mise à jour ou un rollback. + - `Release.IsInstall` : Défini à `true` si l'opération actuelle est une installation. + - `Release.Revision` : Le numéro de révision pour cette release. Lors d'une installation, ce numéro est à 1 et il s'incrémente à chaque mise à jour ou rollback. + - `Release.Service` : Le service qui rend le template en cours. Avec Helm, c'est toujours `Helm`. +- `Values` : Valeurs passées dans le template depuis le fichier `values.yaml` et les fichiers fournis par l'utilisateur. Par défaut, `Values` est vide. +- `Chart` : Contenu du fichier `Chart.yaml`. Toutes les données de ce fichier sont accessibles ici. Par exemple, `{{ .Chart.Name }}-{{ .Chart.Version }}` affichera `mychart-0.1.0`. + - Les champs disponibles sont listés dans le [Guide des Charts]({{}}). +- `Subcharts` : Donne accès à la portée (.Values, .Charts, .Releases, etc.) des sous-charts du parent. Par exemple, `.Subcharts.mySubChart.myValue` permet d'accéder à `myValue` dans le chart `mySubChart`. +- `Files` : Permet d'accéder à tous les fichiers non-spéciaux d'un chart, mais pas aux templates. + - `Files.Get` permet d'obtenir un fichier par son nom (`.Files.Get config.ini`). + - `Files.GetBytes` retourne le contenu du fichier sous forme de tableau d'octets au lieu d'une chaîne. Utile pour des fichiers comme des images. + - `Files.Glob` retourne une liste de fichiers dont les noms correspondent au pattern glob donné. + - `Files.Lines` lit un fichier ligne par ligne, pratique pour parcourir chaque ligne d'un fichier. + - `Files.AsSecrets` retourne les corps de fichiers sous forme de chaînes encodées en Base64. + - `Files.AsConfig` retourne les corps de fichiers sous forme de map YAML. +- `Capabilities` : Donne des informations sur les capacités du cluster Kubernetes. + - `Capabilities.APIVersions` est un ensemble de versions. + - `Capabilities.APIVersions.Has $version` indique si une version (ex. `batch/v1`) ou une ressource (ex. `apps/v1/Deployment`) est disponible dans le cluster. + - `Capabilities.KubeVersion` et `Capabilities.KubeVersion.Version` affichent la version de Kubernetes. + - `Capabilities.KubeVersion.Major` affiche la version majeure de Kubernetes. + - `Capabilities.KubeVersion.Minor` affiche la version mineure de Kubernetes. + - `Capabilities.HelmVersion` contient les détails de la version de Helm, correspondant à la sortie de `helm version`. + - `Capabilities.HelmVersion.Version` affiche la version actuelle de Helm au format semver. + - `Capabilities.HelmVersion.GitCommit` affiche le SHA1 du commit git de Helm. + - `Capabilities.HelmVersion.GitTreeState` indique l'état de l'arbre git de Helm. + - `Capabilities.HelmVersion.GoVersion` affiche la version du compilateur Go utilisée. +- `Template` : Contient des informations sur le template en cours d'exécution. + - `Template.Name` : Le chemin vers le template actuel (ex. `mychart/templates/mytemplate.yaml`). + - `Template.BasePath` : Le chemin vers le répertoire des templates du chart en cours (ex. `mychart/templates`). + +Les valeurs intégrées commencent toujours par une majuscule, conformément à la convention de nommage de Go. Lorsque vous créez vos propres noms, vous êtes libre d'utiliser une convention qui convient à votre équipe. Certaines équipes, comme celles dont vous verrez les charts sur [Artifact Hub](https://artifacthub.io/packages/search?kind=0), choisissent d'utiliser uniquement des lettres minuscules au début pour distinguer les noms locaux de ceux intégrés. Dans ce guide, nous suivons cette convention. diff --git a/content/fr/docs/chart_template_guide/control_structures.md b/content/fr/docs/chart_template_guide/control_structures.md new file mode 100644 index 000000000..b24bb9dc8 --- /dev/null +++ b/content/fr/docs/chart_template_guide/control_structures.md @@ -0,0 +1,387 @@ +--- +title: "Contrôle de flux" +description: "Un aperçu rapide sur la structure du flux dans les modèles" +weight: 7 +--- + +Les structures de contrôle (appelées « actions » dans le langage des modèles) te permettent, en tant qu'auteur de modèle, de contrôler le flux de génération d'un modèle. Le langage de modèle de Helm propose les structures de contrôle suivantes : + +- `if`/`else` pour créer des blocs conditionnels +- `with` pour spécifier un contexte +- `range`, qui fournit une boucle de type « pour chaque » + +En plus de cela, il fournit quelques actions pour déclarer et utiliser des segments de modèle nommés : + +- `define` déclare un nouveau modèle nommé à l'intérieur de votre modèle +- `template` importe un modèle nommé +- `block` déclare une sorte de zone de modèle remplissable spéciale + +Dans cette section, nous parlerons de `if`, `with` et `range`. Les autres sont abordées dans la section [Modèles nommés]({{}}) plus loin dans ce guide. + +## If/Else + +La première structure de contrôle que nous allons examiner est celle permettant d'inclure conditionnellement des blocs de texte dans un modèle. Il s'agit du bloc `if`/`else` (si/sinon). + +La structure de base pour une conditionnelle ressemble à ceci : + +``` +{{ if PIPELINE }} + # Fais quelque chose +{{ else if OTHER PIPELINE }} + # Fais autre chose +{{ else }} + # Cas par défaut +{{ end }} +``` + +Remarque que nous parlons maintenant de _pipelines_ au lieu de valeurs. La raison en est de préciser que les structures de contrôle peuvent exécuter un pipeline entier, et pas seulement évaluer une valeur. + +Un pipeline est évalué comme _faux_ si la valeur est : + +- un booléen faux +- un zéro numérique +- une chaîne vide +- un `nil` (vide ou nul) +- une collection vide (`map`, `slice`, `tuple`, `dict`, `array`) + +Dans toutes les autres conditions, la condition est vraie. + +Ajoutons une conditionnelle simple à notre ConfigMap. Nous ajouterons un autre paramètre si la boisson est définie sur café : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | default "tea" | quote }} + food: {{ .Values.favorite.food | upper | quote }} + {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} +``` + +Puisque nous avons commenté `drink: coffee` dans notre dernier exemple, la sortie ne devrait pas inclure un flag `mug: "true"`. Mais si nous ajoutons cette ligne dans notre fichier `values.yaml`, la sortie devrait ressembler à ceci : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: eyewitness-elk-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" + mug: "true" +``` + +## Contrôle des espaces + +Tout en examinant les conditionnelles, nous devrions jeter un coup d'œil rapide à la façon dont les espaces sont contrôlés dans les modèles. Prenons l'exemple précédent et formatons-le pour le rendre un peu plus lisible : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | default "tea" | quote }} + food: {{ .Values.favorite.food | upper | quote }} + {{ if eq .Values.favorite.drink "coffee" }} + mug: "true" + {{ end }} +``` + +Au départ, cela semble bien. Mais si nous le passons par le moteur de modèle, nous obtiendrons un mauvais résultat : + +```console +$ helm install --dry-run --debug ./mychart +SERVER: "localhost:44134" +CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart +Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key +``` + +Que s'est-il passé ? Nous avons généré un YAML incorrect en raison des espaces ci-dessus. + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: eyewitness-elk-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" + mug: "true" +``` + +`mug` est mal indenté. Retirons simplement cette ligne de l'indentation et exécutons à nouveau : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | default "tea" | quote }} + food: {{ .Values.favorite.food | upper | quote }} + {{ if eq .Values.favorite.drink "coffee" }} + mug: "true" + {{ end }} +``` + +Lorsque nous envoyons cela, nous obtiendrons un YAML valide, mais qui semble encore un peu étrange : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: telling-chimp-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" + + mug: "true" + +``` + +Remarque que nous avons reçu quelques lignes vides dans notre YAML. Pourquoi ? Lorsque le moteur de modèle s'exécute, il _supprime_ le contenu à l'intérieur de `{{` et `}}`, mais il laisse les espaces restants tels quels. + +YAML attribue une signification aux espaces, donc gérer ces espaces devient assez important. Heureusement, les modèles Helm disposent de quelques outils pour aider. + +Tout d'abord, la syntaxe des accolades des déclarations de modèle peut être modifiée avec des caractères spéciaux pour indiquer au moteur de modèle de supprimer les espaces. `{{- ` (avec le tiret et l'espace ajoutés) indique que les espaces blancs à gauche doivent être supprimés, tandis que ` -}}` signifie que les espaces à droite doivent être consommés. _Faites attention ! Les nouvelles lignes sont des espaces !_ + +> Assurez-vous qu'il y a un espace entre le `-` et le reste de votre directive. +> `{{- 3 }}` signifie "supprimer les espaces à gauche et imprimer 3", tandis que `{{-3 }}` signifie "imprimer -3". + +En utilisant cette syntaxe, nous pouvons modifier notre modèle pour supprimer ces nouvelles lignes : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | default "tea" | quote }} + food: {{ .Values.favorite.food | upper | quote }} + {{- if eq .Values.favorite.drink "coffee" }} + mug: "true" + {{- end }} +``` + +Pour clarifier ce point, ajustons ce qui précède et substituons un `*` pour chaque espace qui sera supprimé selon cette règle. Un `*` à la fin de la ligne indique un caractère de nouvelle ligne qui serait supprimé. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | default "tea" | quote }} + food: {{ .Values.favorite.food | upper | quote }}* +**{{- if eq .Values.favorite.drink "coffee" }} + mug: "true"* +**{{- end }} + +``` + +En gardant cela à l'esprit, nous pouvons exécuter notre modèle à travers Helm et voir le résultat : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: clunky-cat-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" + mug: "true" +``` + +Faites attention aux modificateurs de suppression. Il est facile de faire accidentellement des choses comme ceci : + +```yaml + food: {{ .Values.favorite.food | upper | quote }} + {{- if eq .Values.favorite.drink "coffee" -}} + mug: "true" + {{- end -}} + +``` + +Cela produira `food: "PIZZA"mug: "true"` car il a consommé les nouvelles lignes des deux côtés. + +> Pour les détails sur le contrôle des espaces dans les modèles, consultez la [documentation officielle des modèles Go](https://godoc.org/text/template). + +Enfin, il est parfois plus facile de laisser le système de modèles gérer l'indentation à votre place plutôt que d'essayer de maîtriser l'espacement des directives de modèle. Pour cette raison, il peut parfois être utile d'utiliser la fonction `indent` (`{{ indent 2 "mug:true" }}` par exemple). + +## Modifier le contexte en utilisant `with`. + +La prochaine structure de contrôle à examiner est l'action `with`. Cela contrôle la portée des variables. Rappelons que `.` est une référence à _la portée actuelle_. Ainsi, `.Values` indique au modèle de trouver l'objet `Values` dans la portée actuelle. + +La syntaxe de `with` est similaire à celle d'une simple instruction `if` : + +``` +{{ with PIPELINE }} + # Portée restreinte +{{ end }} +``` + +Les portées peuvent être modifiées. `with` permet de définir la portée actuelle (`.`) sur un objet particulier. Par exemple, nous avons travaillé avec `.Values.favorite`. Réécrivons notre ConfigMap pour modifier la portée `.` afin de pointer vers `.Values.favorite` : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + {{- end }} +``` + +Note que nous avons supprimé la conditionnelle `if` de l'exercice précédent car elle n'est plus nécessaire : le bloc après `with` s'exécute uniquement si la valeur de `PIPELINE` n'est pas vide. + +Remarque que maintenant nous pouvons référencer `.drink` et `.food` sans les qualifier. Cela est dû au fait que l'instruction `with` définit `.` pour pointer vers `.Values.favorite`. Le `.` est réinitialisé à sa portée précédente après `{{ end }}`. + +Mais voici un avertissement ! À l'intérieur de la portée restreinte, vous ne pourrez pas accéder aux autres objets de la portée parente en utilisant `.`. Cela, par exemple, échouera : + +```yaml + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + release: {{ .Release.Name }} + {{- end }} +``` + +Cela produira une erreur car `Release.Name` n'est pas à l'intérieur de la portée restreinte de `.`. Cependant, si nous échangeons les deux dernières lignes, tout fonctionnera comme prévu car la portée est réinitialisée après `{{ end }}`. + +```yaml + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + {{- end }} + release: {{ .Release.Name }} +``` + +Ou, nous pouvons utiliser `$` pour accéder à l'objet `Release.Name` depuis la portée parente. `$` est mappé à la portée racine lorsque l'exécution du modèle commence et il ne change pas pendant l'exécution du modèle. Ce qui suit fonctionnerait également : + +```yaml + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + release: {{ $.Release.Name }} + {{- end }} +``` + +Après avoir examiné `range`, nous allons jeter un œil aux variables de modèle, qui offrent une solution au problème de portée mentionné ci-dessus. + +## Boucler avec l'action `range`. + +De nombreux langages de programmation prennent en charge les boucles à l'aide de boucles `for`, `foreach` ou des mécanismes fonctionnels similaires. Dans le langage des modèles de Helm, la façon d'itérer à travers une collection est d'utiliser l'opérateur `range`. + +Pour commencer, ajoutons une liste de garnitures à pizza dans notre fichier `values.yaml` : + +```yaml +favorite: + drink: coffee + food: pizza +pizzaToppings: + - mushrooms + - cheese + - peppers + - onions +``` + +Nous avons maintenant une liste (appelée `slice` dans les modèles) de `pizzaToppings`. Nous pouvons modifier notre modèle pour imprimer cette liste dans notre ConfigMap : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + {{- end }} + toppings: |- + {{- range .Values.pizzaToppings }} + - {{ . | title | quote }} + {{- end }} + +``` +Nous pouvons utiliser `$` pour accéder à la liste `Values.pizzaToppings` depuis la portée parente. `$` est mappé à la portée racine lorsque l'exécution du modèle commence et il ne change pas pendant l'exécution du modèle. Ce qui suit fonctionnerait également : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + toppings: |- + {{- range $.Values.pizzaToppings }} + - {{ . | title | quote }} + {{- end }} + {{- end }} +``` + +Examinons de plus près la liste `toppings:`. La fonction `range` va "parcourir" (itérer) la liste `pizzaToppings`. Mais maintenant, quelque chose d'intéressant se produit. Tout comme `with` définit la portée de `.`, le fonctionnement de `range` fait de même. À chaque passage dans la boucle, `.` est défini sur la garniture de pizza actuelle. C'est-à-dire qu'à la première itération, `.` est défini sur `mushrooms`. À la deuxième itération, il est défini sur `cheese`, et ainsi de suite. + +Nous pouvons envoyer la valeur de `.` directement dans un pipeline, donc lorsque nous faisons `{{ . | title | quote }}`, cela envoie `.` à `title` (fonction de mise en majuscule) puis à `quote`. Si nous exécutons ce modèle, la sortie sera : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: edgy-dragonfly-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" + toppings: |- + - "Mushrooms" + - "Cheese" + - "Peppers" + - "Onions" +``` + +Dans cet exemple, nous avons fait quelque chose de subtil. La ligne `toppings: |-` déclare une chaîne multi-lignes. Donc, notre liste de garnitures n'est en réalité pas une liste YAML. C'est une grande chaîne de caractères. Pourquoi ferions-nous cela ? Parce que les données dans les `ConfigMaps` `data` sont composées de paires clé/valeur, où la clé et la valeur sont toutes deux des chaînes simples. Pour comprendre pourquoi c'est le cas, consultez la [documentation des ConfigMaps Kubernetes](https://kubernetes.io/docs/concepts/configuration/configmap/). Pour nous, cependant, ce détail n'a pas beaucoup d'importance. + +> Le marqueur `|-` en YAML prend une chaîne multi-lignes. C'est une technique utile pour intégrer de gros blocs de données à l'intérieur de vos manifests, comme illustré ici. + +Parfois, il est utile de pouvoir créer rapidement une liste à l'intérieur de votre modèle, puis d'itérer sur cette liste. Les modèles Helm disposent d'une fonction pour faciliter cela : `tuple`. En informatique, un tuple est une collection de taille fixe ressemblant à une liste, mais avec des types de données arbitraires. Cela décrit en gros la façon dont un `tuple` est utilisé. + +```yaml + sizes: |- + {{- range tuple "small" "medium" "large" }} + - {{ . }} + {{- end }} +``` + +Ce qui précède produira ceci : + +```yaml + sizes: |- + - small + - medium + - large +``` + +En plus des listes et des tuples, `range` peut être utilisé pour itérer sur des collections qui ont une clé et une valeur (comme un `map` ou un `dict`). Nous verrons comment faire cela dans la section suivante lorsque nous introduirons les variables de modèle. diff --git a/content/fr/docs/chart_template_guide/data_types.md b/content/fr/docs/chart_template_guide/data_types.md new file mode 100644 index 000000000..02a6f0878 --- /dev/null +++ b/content/fr/docs/chart_template_guide/data_types.md @@ -0,0 +1,18 @@ +--- +title: "Annexe : Types de données Go et modèles." +description: "Un aperçu rapide sur les variables dans les modèles" +weight: 16 +--- + +Le langage des modèles Helm est implémenté dans le langage de programmation Go, qui est fortement typé. Pour cette raison, les variables dans les modèles sont _typées_. Dans l'ensemble, les variables seront exposées comme l'un des types suivants : + +- string : Une chaîne de texte +- bool : un `true` ou `false` +- int : Une valeur entière (il existe également des variantes signées et non signées de 8, 16, 32 et 64 bits) +- float64 : Une valeur à virgule flottante de 64 bits (il existe également des variétés de 8, 16 et 32 bits) +- un tableau d'octets (`[]byte`), souvent utilisé pour contenir des données (potentiellement) binaires +- struct : un objet avec des propriétés et des méthodes +- un slice (liste indexée) d'un des types précédents +- une map avec des clés de type chaîne (`map[string]interface{}`) où la valeur est l'un des types précédents + +Il existe de nombreux autres types en Go, et il vous faudra parfois convertir entre eux dans vos modèles. La façon la plus simple de déboguer le type d'un objet est de le passer à travers `printf "%t"` dans un modèle, ce qui imprimera le type. Consultez également les fonctions `typeOf` et `kindOf`. diff --git a/content/fr/docs/chart_template_guide/debugging.md b/content/fr/docs/chart_template_guide/debugging.md new file mode 100644 index 000000000..0b2629056 --- /dev/null +++ b/content/fr/docs/chart_template_guide/debugging.md @@ -0,0 +1,32 @@ +--- +title: "Déboguer les modèles." +description: "Résolution des problèmes des charts qui échouent à se déployer" +weight: 13 +--- + +Déboguer les modèles peut être délicat, car les modèles rendus sont envoyés au serveur API Kubernetes, qui peut rejeter les fichiers YAML pour des raisons autres que le formatage. + +Il existe quelques commandes qui peuvent vous aider à déboguer : + +- `helm lint` est votre outil de référence pour vérifier que votre chart suit les meilleures pratiques. +- `helm template --debug` testera le rendu des modèles de chart localement. +- `helm install --dry-run --debug` rendra également votre chart localement sans l'installer, mais vérifiera aussi si des ressources conflictuelles sont déjà en cours d'exécution sur le cluster. En définissant `--dry-run=server`, il exécutera également toute opération `lookup` dans votre chart vers le serveur. +- `helm get manifest` : C'est un bon moyen de voir quels modèles sont installés sur le serveur. + +Lorsque votre YAML échoue à se parser, mais que vous souhaitez voir ce qui est généré, une manière simple de récupérer le YAML est de commenter la section problématique dans le modèle, puis de relancer `helm install --dry-run --debug` : + +```yaml +apiVersion: v2 +# some: problem section +# {{ .Values.foo | quote }} +``` + +Ce qui précède sera rendu et renvoyé avec les commentaires intacts : + +```yaml +apiVersion: v2 +# some: problem section +# "bar" +``` + +Cela fournit un moyen rapide de visualiser le contenu généré sans que les erreurs de parsing YAML ne bloquent. diff --git a/content/fr/docs/chart_template_guide/function_list.md b/content/fr/docs/chart_template_guide/function_list.md new file mode 100644 index 000000000..2ca7be82b --- /dev/null +++ b/content/fr/docs/chart_template_guide/function_list.md @@ -0,0 +1,2089 @@ +--- +title: "Liste des fonctions de modèle" +description: "Une liste des fonctions de modèle disponibles dans Helm" +weight: 6 +--- + +Helm comprend de nombreuses fonctions de modèle que vous pouvez utiliser dans les modèles. Elles sont listées ici et classées par les catégories suivantes : + +* [Cryptographic and Security](#cryptographic-and-security-functions) +* [Date](#date-functions) +* [Dictionaries](#dictionaries-and-dict-functions) +* [Encoding](#encoding-functions) +* [File Path](#file-path-functions) +* [Kubernetes and Chart](#kubernetes-and-chart-functions) +* [Logic and Flow Control](#logic-and-flow-control-functions) +* [Lists](#lists-and-list-functions) +* [Math](#math-functions) +* [Float Math](#float-math-functions) +* [Network](#network-functions) +* [Reflection](#reflection-functions) +* [Regular Expressions](#regular-expressions) +* [Semantic Versions](#semantic-version-functions) +* [String](#string-functions) +* [Type Conversion](#type-conversion-functions) +* [URL](#url-functions) +* [UUID](#uuid-functions) + +## Fonctions de logique et de contrôle de flux. + +Helm comprend de nombreuses fonctions de logique et de contrôle de flux, notamment : [and](#and), +[coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), +[fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), +[not](#not), [or](#or) et [required](#required). + +### and + +Renvoie le booléen ET de deux arguments ou plus (le premier argument vide, ou le dernier argument). + +``` +and .Arg1 .Arg2 +``` + +### or + +Renvoie le booléen OU de deux arguments ou plus (le premier argument non vide, ou le dernier argument). + +``` +or .Arg1 .Arg2 +``` + +### not + +Renvoie la négation booléenne de son argument. + +``` +not .Arg +``` + +### eq + +Renvoie l'égalité booléenne des arguments (par exemple, Arg1 == Arg2). + +``` +eq .Arg1 .Arg2 +``` + +### ne + +Renvoie l'inégalité booléenne des arguments (par exemple, Arg1 != Arg2). + +``` +ne .Arg1 .Arg2 +``` + +### lt + +Renvoie un booléen vrai si le premier argument est inférieur au second. Faux est renvoyé dans le cas contraire (par exemple, Arg1 < Arg2). + +``` +lt .Arg1 .Arg2 +``` + +### le + +Renvoie un booléen vrai si le premier argument est inférieur ou égal au second. Faux est renvoyé dans le cas contraire (par exemple, Arg1 <= Arg2). + +``` +le .Arg1 .Arg2 +``` + +### gt + +Renvoie un booléen vrai si le premier argument est supérieur au second. Faux est renvoyé dans le cas contraire (par exemple, Arg1 > Arg2). + +``` +gt .Arg1 .Arg2 +``` + +### ge + +Renvoie un booléen vrai si le premier argument est supérieur ou égal au second. Faux est renvoyé dans le cas contraire (par exemple, Arg1 >= Arg2). + +``` +ge .Arg1 .Arg2 +``` + +### default + +Pour définir une valeur par défaut simple, utilisez `default` : + +``` +default "foo" .Bar +``` + +Dans ce qui précède, si `.Bar` évalue à une valeur non vide, elle sera utilisée. Mais si elle est vide, `foo` sera renvoyé à la place. + +La définition de "vide" dépend du type : + +- Numérique : 0 +- Chaîne : "" +- Listes : `[]` +- Dictionnaires : `{}` +- Booléen : `false` +- Et toujours `nil` (c'est-à-dire null) + +Pour les structs, il n'existe pas de définition de vide, donc un struct ne renverra jamais la valeur par défaut. + +### required + +Spécifiez les valeurs qui doivent être définies avec `required` : + +``` +required "A valid foo is required!" .Bar +``` + +Si `.Bar` est vide ou non défini (voir [default](#default) sur la façon dont cela est évalué), le modèle ne sera pas rendu et renverra le message d'erreur fourni à la place. + +### empty + +La fonction `empty` renvoie `true` si la valeur donnée est considérée comme vide, et `false` dans le cas contraire. Les valeurs vides sont listées dans la section `default`. + +``` +empty .Foo +``` + +Notez que dans les conditionnels des modèles Go, la vacuité est calculée pour vous. Ainsi, vous n'avez que rarement besoin d'utiliser `if not empty .Foo`. Utilisez plutôt simplement `if .Foo`. + +### fail + +Renvoie inconditionnellement une chaîne vide et une erreur avec le texte spécifié. Ceci est utile dans les scénarios où d'autres conditionnels ont déterminé que le rendu du modèle devrait échouer. + +``` +fail "Please accept the end user license agreement" +``` + +### coalesce + +La fonction `coalesce` prend une liste de valeurs et renvoie la première non vide. + +``` +coalesce 0 1 2 +``` + +Ce qui précède renvoie `1`. + +Cette fonction est utile pour parcourir plusieurs variables ou valeurs : + +``` +coalesce .name .parent.name "Matt" +``` + +Ce qui précède vérifiera d'abord si `.name` est vide. Si ce n'est pas le cas, il renverra cette valeur. Si c'est _vide_, `coalesce` évaluera `.parent.name` pour vérifier sa vacuité. Enfin, si à la fois `.name` et `.parent.name` sont vides, il renverra `Matt`. + +### ternary + +La fonction `ternary` prend deux valeurs et une valeur de test. Si la valeur de test est vraie, la première valeur sera renvoyée. Si la valeur de test est vide, la deuxième valeur sera renvoyée. Cela est similaire à l'opérateur ternaire en C et dans d'autres langages de programmation. + +#### true test value + +``` +ternary "foo" "bar" true +``` + +ou + +``` +true | ternary "foo" "bar" +``` + +Ce qui précède renvoie `"foo"`. + +#### false test value + +``` +ternary "foo" "bar" false +``` + +ou + +``` +false | ternary "foo" "bar" +``` + +Ce qui précède renvoie `"bar"`. + +## Fonction de chaîne de caractères + +Helm comprend les fonctions de chaîne suivantes : [abbrev](#abbrev), +[abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), +[contains](#contains), [hasPrefix](#hasprefix-and-hassuffix), +[hasSuffix](#hasprefix-and-hassuffix), [indent](#indent), [initials](#initials), +[kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), +[nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), +[println](#println), [quote](#quote-and-squote), +[randAlpha](#randalphanum-randalpha-randnumeric-and-randascii), +[randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii), +[randAscii](#randalphanum-randalpha-randnumeric-and-randascii), +[randNumeric](#randalphanum-randalpha-randnumeric-and-randascii), +[repeat](#repeat), [replace](#replace), [shuffle](#shuffle), +[snakecase](#snakecase), [squote](#quote-and-squote), [substr](#substr), +[swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), +[trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), +[untitle](#untitle), [upper](#upper), [wrap](#wrap) et [wrapWith](#wrapwith). + +### print + +Renvoie une chaîne résultant de la combinaison de ses parties. + +``` +print "Matt has " .Dogs " dogs" +``` + +Les types qui ne sont pas des chaînes sont convertis en chaînes lorsque cela est possible. + +Notez que lorsque deux arguments adjacents ne sont pas des chaînes, un espace est ajouté entre eux. + +### println + +Fonctionne de la même manière que [print](#print) mais ajoute une nouvelle ligne à la fin. + +### printf + +Renvoie une chaîne basée sur une chaîne de formatage et les arguments à lui passer dans l'ordre. + +``` +printf "%s has %d dogs." .Name .NumberDogs +``` + +Le placeholder à utiliser dépend du type de l'argument passé. Cela inclut : + +Usage général : + +* `%v` la valeur dans un format par défaut + * lors de l'impression de dictionnaires, le flag plus (%+v) ajoute les noms de champs +* `%%` un signe pourcentage littéral ; ne consomme aucune valeur + +Booléen : + +* `%t` le mot true ou false + +Entier : + +* `%b` base 2 +* `%c` le caractère représenté par le point de code Unicode correspondant +* `%d` base 10 +* `%o` base 8 +* `%O` base 8 avec le préfixe 0o +* `%q` un littéral de caractère entre guillemets simples, échappé en toute sécurité +* `%x` base 16, avec des lettres minuscules pour a-f +* `%X` base 16, avec des lettres majuscules pour A-F +* `%U` format Unicode : U+1234 ; identique à "U+%04X" + +Flottants et nombres complexes : + +* `%b` décimal sans notation scientifique avec exponent à une puissance de deux, par ex. -123456p-78 +* `%e` notation scientifique, par ex. -1.234456e+78 +* `%E` notation scientifique, par ex. -1.234456E+78 +* `%f` point décimal sans exponent, par ex. 123.456 +* `%F` synonyme de %f +* `%g` %e pour de grands exposants, %f sinon. +* `%G` %E pour de grands exposants, %F sinon +* `%x` notation hexadécimale (avec exponent en puissance de deux décimal), par ex. -0x1.23abcp+20 +* `%X` notation hexadécimale en majuscules, par ex. -0X1.23ABCP+20 + +Chaîne et tranche d'octets (traitées de manière équivalente avec ces verbes) : + +* `%s` les octets non interprétés de la chaîne ou de la tranche +* `%q` une chaîne entre guillemets doubles, échappée en toute sécurité +* `%x` base 16, en minuscules, deux caractères par octet +* `%X` base 16, en majuscules, deux caractères par octet + +Tranche : + +* `%p` adresse du 0ème élément en notation hexadécimale, avec le préfixe 0x + +### trim + +La fonction `trim` supprime les espaces des deux côtés d'une chaîne : + +``` +trim " hello " +``` + +Cela donnera `hello` + +### trimAll + +Supprime les caractères donnés du début et de la fin d'une chaîne : + +``` +trimAll "$" "$5.00" +``` + +Ce qui précède renvoie `5.00` (sous forme de chaîne). + +### trimPrefix + +Supprime uniquement le préfixe d'une chaîne : + +``` +trimPrefix "-" "-hello" +``` + +Ce qui précède renvoie `hello`. + +### trimSuffix + +Supprime simplement le suffixe d'une chaîne : + +``` +trimSuffix "-" "hello-" +``` + +Ce qui précède renvoie `hello`. + +### lower + +Convertit toute la chaîne en minuscules : + +``` +lower "HELLO" +``` + +Ce qui précède renvoie `hello`. + +### upper + +Convertit toute la chaîne en majuscules : + +``` +upper "hello" +``` + +Ce qui précède renvoie `HELLO`. + +### title + +Convertit en titre : + +``` +title "hello world" +``` + +L'exemple ci-dessus renverra `Hello World` + +### untitle + +Supprime la casse titre. `untitle "Hello World"` produit `hello world`. + +### repeat + +Répète une chaîne plusieurs fois : + +``` +repeat 3 "hello" +``` + +L'exemple ci-dessus renverra `hellohellohello` + +### substr + +Obtenir une sous-chaîne d'une chaîne. Cela prend trois paramètres : + +- début (int) +- fin (int) +- chaîne (string) + +``` +substr 0 5 "hello world" +``` + +L'exemple ci-dessus renverra `hello` + +### nospace + +Supprime tout les espaces d'une chaîne de caractère + +``` +nospace "hello w o r l d" +``` + +L'exemple ci-dessus renverra `helloworld` + +### trunc + +Tronque une chaîne + +``` +trunc 5 "hello world" +``` + +Ce qui précède produit `hello`. + +``` +trunc -5 "hello world" +``` + +Ce qui précède produit `world`. + +### abbrev + +Tronque une chaîne avec des points de suspension (`...`) : + +Paramètres : + +- longueur maximale +- la chaîne + +``` +abbrev 5 "hello world" +``` + +Ce qui précède renvoie `he...`, car il prend en compte la largeur des points de suspension dans la longueur maximale. + +### abbrevboth + +Abréger des deux côtés : + +``` +abbrevboth 5 10 "1234 5678 9123" +``` + +Ce qui précède produit `...5678...`. + +Cela prend : + +- décalage gauche +- longueur maximale +- la chaîne + +### initials + +Étant donné plusieurs mots, prenez la première lettre de chaque mot et combinez-les. + +``` +initials "First Try" +``` + +Ce qui précède produit `FT` + +### randAlphaNum, randAlpha, randNumeric et randAscii + +Ces quatre fonctions génèrent des chaînes aléatoires sécurisées sur le plan cryptographique (utilisant ```crypto/rand```) avec différents ensembles de caractères de base : + +- `randAlphaNum` utilise `0-9a-zA-Z` +- `randAlpha` utilise `a-zA-Z` +- `randNumeric` utilise `0-9` +- `randAscii` utilise tous les caractères ASCII imprimables + +Chacune d'elles prend un paramètre, la longueur entière de la chaîne. + +``` +randNumeric 3 +``` + +Ce qui précède produira une chaîne aléatoire avec trois chiffres. + +### wrap + +Envelopper le texte à un nombre de colonnes donné : + +``` +wrap 80 $someText +``` + +Ce qui précède enveloppera la chaîne dans `$someText` à 80 colonnes. + +### wrapWith + +`wrapWith` fonctionne comme `wrap`, mais vous permet de spécifier la chaîne avec laquelle envelopper. (`wrap` utilise `\n`) + +``` +wrapWith 5 "\t" "Hello World" +``` + +Ce qui précède produit `Hello World` (où l'espace est un caractère de tabulation ASCII). + +### contains + +Tester pour voir si une chaîne est contenue dans une autre : + +``` +contains "cat" "catch" +``` + +Ce qui précède renvoie `true` car `catch` contient `cat`. + +### hasPrefix et hasSuffix + +Les fonctions `hasPrefix` et `hasSuffix` testent si une chaîne a un préfixe ou un suffixe donné : + +``` +hasPrefix "cat" "catch" +``` + +Ce qui précède renvoie `true` car `catch` a le préfixe `cat`. + +### quote and squote + +Ces fonctions enveloppent une chaîne entre des guillemets doubles (`quote`) ou des guillemets simples (`squote`). + +### cat + +La fonction `cat` concatène plusieurs chaînes en une seule, en les séparant par des espaces : + +``` +cat "hello" "beautiful" "world" +``` + +Ce qui précède produit `hello beautiful world`. + +### indent + +La fonction `indent` indente chaque ligne d'une chaîne donnée à la largeur d'indentation spécifiée. Cela est utile pour aligner des chaînes multi-lignes : + +``` +indent 4 $lots_of_text +``` + +Le résultat ci-dessus indente chaque ligne de texte de 4 caractères d'espace. + +### nindent + +La fonction `nindent` est identique à la fonction `indent`, mais elle ajoute une nouvelle ligne au début de la chaîne. + +``` +nindent 4 $lots_of_text +``` + +Cela ajoutera une nouvelle ligne au début et indenter chaque ligne de texte de 4 espaces. + +### replace + +Effectue un remplacement simple de chaîne. + +Il prend trois arguments : + +- chaîne à remplacer +- chaîne de remplacement +- chaîne source + +``` +"I Am Henry VIII" | replace " " "-" +``` + +Cela produira `I-Am-Henry-VIII`. + +### plural + +Pluraliser une chaîne. + +``` +len $fish | plural "one anchovy" "many anchovies" +``` + +Dans l'exemple ci-dessus, si la longueur de la chaîne est de 1, le premier argument sera imprimé (`une anchois`). Sinon, le deuxième argument sera imprimé (`plusieurs anchois`). + +Les arguments sont : + +- chaîne au singulier +- chaîne au pluriel +- entier de longueur + +REMARQUE : Helm ne prend actuellement pas en charge les langues avec des règles de pluralisation plus complexes. De plus, `0` est considéré comme un pluriel car la langue anglaise le traite ainsi (`zero anchovies`). + +### snakecase + +Convertir une chaîne de `camelCase` en `snake_case`. + +``` +snakecase "FirstName" +``` + +Cela produira `first_name`. + +### camelcase + +Convertir une chaîne de `snake_case` en `CamelCase`. + +``` +camelcase "http_server" +``` + +Cela produira `HttpServer`. + +### kebabcase + +Convertir une chaîne de `camelCase` en `kebab-case`. + +``` +kebabcase "FirstName" +``` + +Cela produira `first-name`. + +### swapcase + +Échanger la casse d'une chaîne en utilisant un algorithme basé sur les mots. + +Algorithme de conversion : + +- Un caractère en majuscule se convertit en minuscule. +- Un caractère en casse de titre se convertit en minuscule. +- Un caractère en minuscule après un espace ou au début se convertit en casse de titre. +- Un autre caractère en minuscule se convertit en majuscule. +- L'espace est défini par `unicode.IsSpace(char)`. + +``` +swapcase "This Is A.Test" +``` + +Cela produira `tHIS iS a.tEST`. + +### shuffle + +Mélanger une chaîne de caractères. + +``` +shuffle "hello" +``` + +Le résultat ci-dessus randomisera les lettres de « hello », produisant peut-être « oelhl ». + +## Fonctions de conversion de type + +Les fonctions de conversion de type suivantes sont fournies par Helm : + +- `atoi` : Convertit une chaîne en entier. +- `float64` : Convertit en `float64`. +- `int` : Convertit en `int` selon la largeur du système. +- `int64` : Convertit en `int64`. +- `toDecimal` : Convertit un octal Unix en `int64`. +- `toString` : Convertit en chaîne. +- `toStrings` : Convertit une liste, un tableau ou un tableau en une liste de chaînes. +- `toJson` (`mustToJson`) : Convertit une liste, un tableau, un dictionnaire ou un objet en JSON. +- `toPrettyJson` (`mustToPrettyJson`) : Convertit une liste, un tableau, un dictionnaire ou un objet en JSON indenté. +- `toRawJson` (`mustToRawJson`) : Convertit une liste, un tableau, un dictionnaire ou un objet en JSON avec les caractères HTML non échappés. +- `fromYaml` : Convertit une chaîne YAML en objet. +- `fromJson` : Convertit une chaîne JSON en objet. +- `fromJsonArray` : Convertit un tableau JSON en liste. +- `toYaml` : Convertit une liste, un tableau, un dictionnaire ou un objet en YAML indenté, peut être utilisé pour copier des morceaux de YAML à partir de n'importe quelle source. Cette fonction est équivalente à la fonction GoLang `yaml.Marshal`, voir la documentation ici : https://pkg.go.dev/gopkg.in/yaml.v2#Marshal. +- `toToml` : Convertit une liste, un tableau, un dictionnaire ou un objet en TOML, peut être utilisé pour copier des morceaux de TOML à partir de n'importe quelle source. +- `fromYamlArray` : Convertit un tableau YAML en liste. + +Seule la fonction `atoi` exige que l'entrée soit d'un type spécifique. Les autres essaieront de convertir n'importe quel type en type de destination. Par exemple, `int64` peut convertir des flottants en entiers, et il peut également convertir des chaînes en entiers. + +### toStrings + +Étant donné une collection de type liste, produisez une tranche de chaînes. + +``` +list 1 2 3 | toStrings +``` + +Ce qui précède convertit `1` en `"1"`, `2` en `"2"`, et ainsi de suite, puis les retourne sous forme de liste. + +### toDecimal + +Étant donné une permission octale UNIX, produit un décimal. + +``` +"0777" | toDecimal +``` + +Le code ci-dessus convertit `0777` en `511` et renvoie la valeur en tant qu'int64. + +### toJson, mustToJson + +La fonction `toJson` encode un élément en une chaîne JSON. Si l'élément ne peut pas être converti en JSON, la fonction renverra une chaîne vide. La fonction `mustToJson` renverra une erreur si l'élément ne peut pas être encodé en JSON. + +``` +toJson .Item +``` + +Cela renvoie la représentation sous forme de chaîne JSON de `.Item`. + +### toPrettyJson, mustToPrettyJson + +La fonction `toPrettyJson` encode un élément en une chaîne JSON joliment formatée (indente). + +``` +toPrettyJson .Item +``` + +Le résultat ci-dessus renvoie une représentation en chaîne JSON indentée de `.Item`. + +### toRawJson, mustToRawJson + +La fonction `toRawJson` encode un élément en une chaîne JSON avec des caractères HTML non échappés. + +``` +toRawJson .Item +``` + +Cela renvoie une représentation de chaîne JSON non échappée de `.Item`. + +### fromYaml + +La fonction `fromYaml` prend une chaîne YAML et renvoie un objet qui peut être utilisé dans des templates. + +`Fichier : yamls/person.yaml` +```yaml +name: Bob +age: 25 +hobbies: + - hiking + - fishing + - cooking +``` + +```yaml +{{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} +greeting: | + Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. + My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. +``` + +### fromJson + +La fonction `fromJson` prend une chaîne JSON et renvoie un objet qui peut être utilisé dans des templates. + +`Fichier : jsons/person.json` +```json +{ + "name": "Bob", + "age": 25, + "hobbies": [ + "hiking", + "fishing", + "cooking" + ] +} +``` + +```yaml +{{- $person := .Files.Get "jsons/person.json" | fromJson }} +greeting: | + Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. + My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. +``` + + +### fromJsonArray + +La fonction `fromJsonArray` prend un tableau JSON et renvoie une liste qui peut être utilisée dans des templates. + +`Fichier : jsons/people.json` +```json +[ + { "name": "Bob","age": 25 }, + { "name": "Ram","age": 16 } +] +``` + +```yaml +{{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} +{{- range $person := $people }} +greeting: | + Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. +{{ end }} +``` + +### fromYamlArray + +La fonction `fromYamlArray` prend un tableau YAML et renvoie une liste qui peut être utilisée dans des templates. + +`Fichier : yamls/people.yml` +```yaml +- name: Bob + age: 25 +- name: Ram + age: 16 +``` + +```yaml +{{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} +{{- range $person := $people }} +greeting: | + Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. +{{ end }} +``` + + +## Expressions régulières + +Helm inclut les fonctions d'expressions régulières suivantes : [regexFind +(mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll +(mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch +(mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll +(mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall), +[regexReplaceAllLiteral +(mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral), +[regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit). + +### regexMatch, mustRegexMatch + +Retourne `true` si la chaîne d'entrée contient une correspondance avec l'expression régulière. + +``` +regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" +``` + +L'exemple ci-dessus produit `true` + +`regexMatch` provoque une panique en cas de problème, tandis que `mustRegexMatch` renvoie une erreur au moteur de template si un problème survient. + +### regexFindAll, mustRegexFindAll + +Retourne un tableau de toutes les correspondances de l'expression régulière dans la chaîne d'entrée. Le dernier paramètre `n` détermine le nombre de sous-chaînes à retourner, où `-1` signifie retourner toutes les correspondances. + +``` +regexFindAll "[2,4,6,8]" "123456789" -1 +``` + +L'exemple ci-dessus produit `[2 4 6 8]`. + +`regexFindAll` provoque une panique s'il y a un problème, tandis que `mustRegexFindAll` renvoie une erreur au moteur de templates s'il y a un problème. + +### regexFind, mustRegexFind + +Renvoie la première correspondance (la plus à gauche) de l'expression régulière dans la chaîne d'entrée. + +``` +regexFind "[a-zA-Z][1-9]" "abcd1234" +``` + +L'exemple ci-dessus produit `d1`. + +`regexFind` panique s'il y a un problème, et `mustRegexFind` renvoie une erreur au moteur de template s'il y a un problème. + +### regexReplaceAll, mustRegexReplaceAll + +Retourne une copie de la chaîne d'entrée, remplaçant les correspondances de l'expression régulière par la chaîne de remplacement. Dans la chaîne de remplacement, les signes `$` sont interprétés comme dans `Expand`, donc par exemple `$1` représente le texte de la première sous-correspondance. + +``` +regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" +``` + +L'exemple ci-dessus produit `-W-xxW-`. + +`regexReplaceAll` provoque une panique s'il y a un problème, tandis que `mustRegexReplaceAll` renvoie une erreur au moteur de template en cas de problème. + +### regexReplaceAllLiteral, mustRegexReplaceAllLiteral + +Renvoie une copie de la chaîne d'entrée, remplaçant les correspondances de l'expression régulière par la chaîne de remplacement. La chaîne de remplacement est substituée directement, sans utiliser Expand. + +``` +regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" +``` + +L'exemple ci-dessus produit `-${1}-${1}-` + +`regexReplaceAllLiteral` provoque une panique en cas de problème, tandis que `mustRegexReplaceAllLiteral` renvoie une erreur au moteur de template s'il y a un problème. + +### regexSplit, mustRegexSplit + +Divise la chaîne d'entrée en sous-chaînes séparées par l'expression et renvoie un tableau des sous-chaînes situées entre ces correspondances d'expression. Le dernier paramètre `n` détermine le nombre de sous-chaînes à renvoyer, où `-1` signifie renvoyer toutes les correspondances. + +``` +regexSplit "z+" "pizza" -1 +``` + +L'exemple ci-dessus produit `[pi a]` + +`regexSplit` provoque une panique en cas de problème et `mustRegexSplit` renvoie une erreur au moteur de template s'il y a un problème. + +## Fonctions cryptographiques et de sécurité + +Helm propose des fonctions cryptographiques avancées, notamment : +[adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), +[decryptAES](#decryptaes), [derivePassword](#derivepassword), +[encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), +[genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), +[htpasswd](#htpasswd), [sha1sum](#sha1sum) et [sha256sum](#sha256sum). + +### sha1sum + +La fonction `sha1sum` reçoit une chaîne de caractères et calcule son empreinte SHA1. + +``` +sha1sum "Hello world!" +``` + +### sha256sum + +La fonction `sha256sum` reçoit une chaîne de caractères et calcule son empreinte SHA256. + +``` +sha256sum "Hello world!" +``` + +L'exemple ci-dessus calcule la somme SHA 256 dans un format "ASCII armored" qui est sûr à imprimer. + +### adler32sum + +La fonction `adler32sum` reçoit une chaîne de caractères et calcule son empreinte Adler-32. + +``` +adler32sum "Hello world!" +``` + +### htpasswd + +La fonction `htpasswd` prend un `nom d'utilisateur` et un `mot de passe`, et génère un hachage `bcrypt` du mot de passe. Le résultat peut être utilisé pour l'authentification de base sur un [serveur HTTP Apache](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic). + +``` +htpasswd "myUser" "myPassword" +``` + +Notez qu'il est dangereux de stocker le mot de passe directement dans le template. + +### derivePassword + +La fonction `derivePassword` peut être utilisée pour dériver un mot de passe spécifique en fonction de certaines contraintes d'un "mot de passe maître" partagé. L'algorithme pour cela est [bien spécifié](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf). + +``` +derivePassword 1 "long" "password" "user" "example.com" +``` + +Notez qu'il est dangereux de stocker le mot de passe directement dans le template. + +### genPrivateKey + +La fonction `genPrivateKey` génère une nouvelle clé privée encodée dans un bloc PEM. + +Elle prend l'une des valeurs suivantes pour son premier paramètre : + +- `ecdsa` : Génère une clé DSA à courbe elliptique (P256) +- `dsa` : Génère une clé DSA (L2048N256) +- `rsa` : Génère une clé RSA 4096 + +### buildCustomCert + +La fonction `buildCustomCert` permet de personnaliser le certificat. + +Elle prend les paramètres suivants sous forme de chaînes de caractères : + +- Un certificat au format PEM encodé en base64 +- Une clé privée au format PEM encodée en base64 + +Elle renvoie un objet certificat avec les attributs suivants : + +- `Cert` : Un certificat encodé en PEM +- `Key` : Une clé privée encodée en PEM + +Exemple : + +``` +$ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" +``` + +Notez que l'objet retourné peut être passé à la fonction `genSignedCert` pour signer un certificat en utilisant cette autorité de certification (CA). + +### genCA + +La fonction `genCA` génère une nouvelle autorité de certification (CA) x509 auto-signée. + +Elle prend les paramètres suivants : + +- Nom commun (cn) du sujet +- Durée de validité du certificat en jours + +Elle retourne un objet avec les attributs suivants : + +- `Cert`: Un certificat encodé en PEM +- `Key`: Une clé privée encodée en PEM + +Exemple : + +``` +$ca := genCA "foo-ca" 365 +``` + +Notez que l'objet retourné peut être passé à la fonction `genSignedCert` pour signer un certificat en utilisant cette autorité de certification. + +### genSelfSignedCert + +La fonction `genSelfSignedCert` génère un nouveau certificat x509 auto-signé. + +Elle prend les paramètres suivants : + +- Nom commun du sujet (cn) +- Liste optionnelle d'adresses IP ; peut être nil +- Liste optionnelle de noms DNS alternatifs ; peut être nil +- Durée de validité du certificat en jours + +Elle retourne un objet avec les attributs suivants : + +- `Cert` : Un certificat encodé en PEM +- `Key` : Une clé privée encodée en PEM + +Exemple : + +``` +$cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 +``` + +### genSignedCert + +La fonction `genSignedCert` génère un nouveau certificat x509 signé par la CA spécifiée. + +Elle prend les paramètres suivants : + +- Nom commun du sujet (cn) +- Liste optionnelle d'adresses IP ; peut être nil +- Liste optionnelle de noms DNS alternatifs ; peut être nil +- Durée de validité du certificat en jours +- CA (voir `genCA`) + +Exemple : + +``` +$ca := genCA "foo-ca" 365 +$cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca +``` + +### encryptAES + +La fonction `encryptAES` chiffre du texte avec AES-256 CBC et retourne une chaîne encodée en base64. + +``` +encryptAES "secretkey" "plaintext" +``` + +### decryptAES + +La fonction `decryptAES` reçoit une chaîne encodée en base64 par l'algorithme AES-256 CBC et retourne le texte décodé. + +``` +"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" +``` + +## Fonctions de date + +Helm inclut les fonctions de date suivantes que vous pouvez utiliser dans les modèles : +[ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify +(mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), +[durationRound](#durationround), [htmlDate](#htmldate), +[htmlDateInZone](#htmldateinzone), [now](#now), [toDate +(mustToDate)](#todate-musttodate) et [unixEpoch](#unixepoch). + +### now + +La date/heure actuelle. Utilisez cela en conjonction avec d'autres fonctions de date. + +### ago + +La fonction `ago` renvoie la durée depuis un moment donné. Maintenant avec une résolution en secondes. + +``` +ago .CreatedAt +``` + +renvoie au format `time.Duration` String(). + +``` +2h34m7s +``` + +### date + +La fonction `date` formate une date. + +Formate la date au format ANNÉE-MOIS-JOUR : + +``` +now | date "2006-01-02" +``` + +Le formatage des dates en Go est [un peu différent](https://pauladamsmith.com/blog/2011/05/go_time.html). + +En résumé, prenez ceci comme date de référence : + +``` +Mon Jan 2 15:04:05 MST 2006 +``` + +Écrivez-le dans le format que vous souhaitez. Ci-dessus, `2006-01-02` est la même date, mais dans le format que nous voulons. + +### dateInZone + +Identique à `date`, mais avec un fuseau horaire. + +``` +dateInZone "2006-01-02" (now) "UTC" +``` + +### duration + +Formate une durée donnée en secondes sous la forme `time.Duration`. + +Cela retourne 1m35s + +``` +duration "95" +``` + +### durationRound + +Arrondit une durée donnée à l'unité la plus significative. Les chaînes et `time.Duration` sont analysées comme une durée, tandis qu'un `time.Time` est calculé comme la durée écoulée depuis. + +Cela retourne 2h + +``` +durationRound "2h10m5s" +``` + +Cela retourne 3mo + +``` +durationRound "2400h10m5s" +``` + +### unixEpoch + +Renvoie le nombre de secondes écoulées depuis l'époque Unix pour un `time.Time`. + +``` +now | unixEpoch +``` + +### dateModify, mustDateModify + +La fonction `dateModify` prend une modification et une date et renvoie l'horodatage. + +Soustraire une heure et trente minutes à l'heure actuelle : + +``` +now | dateModify "-1.5h" +``` + +Si le format de la modification est incorrect, `dateModify` renverra la date sans modification. `mustDateModify` renverra une erreur sinon. + +### htmlDate + +La fonction `htmlDate` formate une date pour l'insertion dans un champ d'entrée de sélecteur de date HTML. + +``` +now | htmlDate +``` + +### htmlDateInZone + +Identique à `htmlDate`, mais avec un fuseau horaire. + +``` +htmlDateInZone (now) "UTC" +``` + +### toDate, mustToDate + +`toDate` convertit une chaîne en date. Le premier argument est le format de la date et le second est la chaîne de date. Si la chaîne ne peut pas être convertie, elle renvoie la valeur nulle. `mustToDate` renverra une erreur si la chaîne ne peut pas être convertie. + +Ceci est utile lorsque vous souhaitez convertir une date sous forme de chaîne dans un autre format (en utilisant un pipe). L'exemple ci-dessous convertit "2017-12-31" en "31/12/2017". + +``` +toDate "2006-01-02" "2017-12-31" | date "02/01/2006" +``` + +## Dictionnaires et fonctions de dictionnaire. + +Helm fournit un type de stockage clé/valeur appelé `dict` (abréviation de "dictionnaire", comme en Python). Un `dict` est un type _non ordonné_. + +La clé d'un dictionnaire **doit être une chaîne de caractères**. Cependant, la valeur peut être de n'importe quel type, même un autre `dict` ou `liste`. + +Contrairement aux `listes`, les `dicts` ne sont pas immuables. Les fonctions `set` et `unset` modifieront le contenu d'un dictionnaire. + +Helm fournit les fonctions suivantes pour prendre en charge le travail avec les dictionnaires : [deepCopy +(mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get), +[hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), +[mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), +[omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset) et [values](#values). + +### dict + +La création de dictionnaires se fait en appelant la fonction `dict` et en lui passant une liste de paires. + +Ce qui suit, crée un dictionnaire avec trois éléments : + +``` +$myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" +``` + +### get + +Étant donné une map et une clé, obtenez la valeur de la carte. + +``` +get $myDict "name1" +``` + +Le résultat ci-dessus renvoie `"value1"`. + +Notez que si la clé n'est pas trouvée, cette opération renverra simplement `""`. Aucune erreur ne sera générée. + +### set + +Utilisez `set` pour ajouter une nouvelle paire clé/valeur à un dictionnaire. + +``` +$_ := set $myDict "name4" "value4" +``` + +Notez que `set` _renvoie le dictionnaire_ (une exigence des fonctions de modèle Go), donc vous devrez peut-être capturer la valeur comme fait ci-dessus avec l'assignation `$_`. + +### unset + +Étant donné une map et une clé, supprimez la clé de la map. + +``` +$_ := unset $myDict "name4" +``` + +Comme avec `set`, cela renvoie le dictionnaire. + +Notez que si la clé n'est pas trouvée, cette opération renverra simplement. Aucune erreur ne sera générée. + +### hasKey + +La fonction `hasKey` renvoie `true` si le dictionnaire donné contient la clé spécifiée. + +``` +hasKey $myDict "name1" +``` + +Si la clé n'est pas trouvée, cela renvoie `false`. + +### pluck + +La fonction `pluck` permet de fournir une clé et plusieurs cartes, et d'obtenir une liste de toutes les correspondances : + +``` +pluck "name1" $myDict $myOtherDict +``` + +Ce qui précède renverra une `liste` contenant toutes les valeurs trouvées (`[value1 otherValue1]`). + +Si la clé n'est _pas trouvée_ dans une map, cette map ne sera pas incluse dans la liste (et la longueur de la liste retournée sera inférieure au nombre de dictionnaires dans l'appel à `pluck`). + +Si la clé est _trouvée_ mais que la valeur est une valeur vide, cette valeur sera insérée. + +Une idiome courant dans les modèles Helm est d'utiliser `pluck... | first` pour obtenir la première clé correspondante d'une collection de dictionnaires. + +### dig + +La fonction `dig` parcourt un ensemble imbriqué de dictionnaires, sélectionnant des clés à partir d'une liste de valeurs. Elle renvoie une valeur par défaut si l'une des clés n'est pas trouvée dans le dictionnaire associé. + +``` +dig "user" "role" "humanName" "guest" $dict +``` + +Donnez un dictionnaire structuré comme ceci : +``` +{ + user: { + role: { + humanName: "curator" + } + } +} +``` + +le résultat serait `"curator"`. Si le dictionnaire manquait même d'un champ `user`, le résultat serait `"guest"`. + +La fonction `dig` peut être très utile dans les cas où vous souhaitez éviter les clauses de garde, surtout puisque la fonction `and` du package de modèles Go ne fait pas de court-circuit. Par exemple, `and a.maybeNil a.maybeNil.iNeedThis` évaluera toujours `a.maybeNil.iNeedThis`, et provoquera un panic si `a` n'a pas de champ `maybeNil`. + +`dig` accepte son argument de dictionnaire en dernier pour prendre en charge le passage en pipeline. Par exemple : +``` +merge a b c | dig "one" "two" "three" "" +``` + +### merge, mustMerge + +Fusionnez deux ou plusieurs dictionnaires en un seul, en donnant la priorité au dictionnaire de destination : + +Donnée : + +``` +dst: + default: default + overwrite: me + key: true + +src: + overwrite: overwritten + key: false +``` + +Fera : + +``` +newdict: + default: default + overwrite: me + key: true +``` +``` +$newdict := merge $dest $source1 $source2 +``` + +C'est une opération de fusion profonde mais pas une opération de copie profonde. Les objets imbriqués qui sont fusionnés sont la même instance dans les deux dictionnaires. Si vous souhaitez une copie profonde ainsi que la fusion, utilisez alors la fonction `deepCopy` en même temps que la fusion. Par exemple : + +``` +deepCopy $source | merge $dest +``` + +`mustMerge` renverra une erreur en cas d'échec de la fusion. + +### mergeOverwrite, mustMergeOverwrite + +Fusionnez deux ou plusieurs dictionnaires en un, en donnant la priorité de **droite à gauche**, écrasant ainsi les valeurs dans le dictionnaire de destination : + +Donnée : + +``` +dst: + default: default + overwrite: me + key: true + +src: + overwrite: overwritten + key: false +``` + +Fera : + +``` +newdict: + default: default + overwrite: overwritten + key: false +``` + +``` +$newdict := mergeOverwrite $dest $source1 $source2 +``` + +C'est une opération de fusion profonde mais pas une opération de copie profonde. Les objets imbriqués qui sont fusionnés sont la même instance dans les deux dictionnaires. Si vous souhaitez une copie profonde ainsi que la fusion, utilisez la fonction `deepCopy` en plus de la fusion. Par exemple : + +``` +deepCopy $source | mergeOverwrite $dest +``` + +`mustMergeOverwrite` renverra une erreur en cas d'échec de la fusion. + +### keys + +La fonction `keys` renverra une `liste` de toutes les clés dans un ou plusieurs types de `dict`. Étant donné qu'un dictionnaire est _non ordonné_, les clés ne seront pas dans un ordre prévisible. Elles peuvent être triées avec `sortAlpha`. + +``` +keys $myDict | sortAlpha +``` + +Lorsque vous fournissez plusieurs dictionnaires, les clés seront concaténées. Utilisez la fonction `uniq` avec `sortAlpha` pour obtenir une liste de clés unique et triée. + +``` +keys $myDict $myOtherDict | uniq | sortAlpha +``` + +### pick + +La fonction `pick` sélectionne uniquement les clés données d'un dictionnaire, créant ainsi un nouveau `dict`. + +``` +$new := pick $myDict "name1" "name2" +``` + +L'exemple ci-dessus retourne : `{name1: value1, name2: value2}` + +### omit + +La fonction `omit` est similaire à `pick`, sauf qu'elle retourne un nouveau `dict` avec toutes les clés qui ne correspondent pas aux clés données. + +``` +$new := omit $myDict "name1" "name3" +``` + +L'exemple ci-dessus retournera : `{name2: value2}` + +### values + +La fonction `values` est similaire à `keys`, sauf qu'elle retourne une nouvelle `list` contenant toutes les valeurs du `dict` source (un seul dictionnaire est pris en charge). + +``` +$vals := values $myDict +``` + +Le résultat ci-dessus retourne `list["value1", "value2", "value 3"]`. Notez que la fonction `values` ne garantit pas l'ordre du résultat ; si cela vous importe, utilisez `sortAlpha`. + +### deepCopy, mustDeepCopy + +Les fonctions `deepCopy` et `mustDeepCopy` prennent une valeur et en font une copie profonde. Cela inclut les dictionnaires et d'autres structures. `deepCopy` provoque un panique en cas de problème, tandis que `mustDeepCopy` renvoie une erreur au système de templates lorsqu'il y a une erreur. + +``` +dict "a" 1 "b" 2 | deepCopy +``` + +### Une note sur le fonctionnement des dictionnaires + +Un `dict` est implémenté en Go comme un `map[string]interface{}`. Les développeurs Go peuvent passer des valeurs de `map[string]interface{}` dans le contexte pour les rendre disponibles aux templates sous forme de `dict`. + +## Fonctions d'encodage + +Helm dispose des fonctions d'encodage et de décodage suivantes : + +- `b64enc`/`b64dec` : Encoder ou décoder avec Base64 +- `b32enc`/`b32dec` : Encoder ou décoder avec Base32 + +## Listes et Fonctions de Liste + +Helm fournit un type `list` simple qui peut contenir des listes séquentielles de données arbitraires. Cela est similaire aux tableaux ou aux slice, mais les listes sont conçues pour être utilisées comme des types de données immuables. + +Créer une liste d'entier : + +``` +$myList := list 1 2 3 4 5 +``` + +Cela créera la liste `[1 2 3 4 5]`. + +Helm fournit les fonctions de liste suivantes : [append +(mustAppend)](#append-mustappend), [compact +(mustCompact)](#compact-mustcompact), [concat](#concat), [first +(mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial +(mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), +[prepend (mustPrepend)](#prepend-mustprepend), [rest +(mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), +[seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq +(mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep) et +[without (mustWithout)](#without-mustwithout). + +### first, mustFirst + +Pour obtenir le premier élément d'une liste, utilisez `first`. + +`first $myList` renvoie `1` + +`first` provoque une panique en cas de problème, tandis que `mustFirst` renvoie une erreur au moteur de template si un problème survient. + +### rest, mustRest + +Pour obtenir la queue de la liste (tout sauf le premier élément), utilisez `rest`. + +`rest $myList` renvoie `[2 3 4 5]` + +`rest` provoque une panique en cas de problème, tandis que `mustRest` renvoie une erreur au moteur de template si un problème survient. + +### last, mustLast + +Pour obtenir le dernier élément d'une liste, utilisez `last` : + +`last $myList` renvoie `5`. Cela revient à inverser une liste et à appeler ensuite `first`. + +### initial, mustInitial + +Cela complète `last` en renvoyant tous les éléments _sauf_ le dernier. `initial $myList` renvoie `[1 2 3 4]`. + +`initial` panique s'il y a un problème, tandis que `mustInitial` renvoie une erreur au moteur de template s'il y a un problème. + +### append, mustAppend + +Ajoutez un nouvel élément à une liste existante, créant ainsi une nouvelle liste. + +``` +$new = append $myList 6 +``` + +Le code ci-dessus affectera à `$new` la valeur `[1 2 3 4 5 6]`. `$myList` resterait inchangé. + +La fonction `append` génère une panique en cas de problème, tandis que `mustAppend` retourne une erreur au moteur de modèles en cas de problème. + +### prepend, mustPrepend + +Ajoute un élément au début d'une liste, en créant une nouvelle liste. + +``` +prepend $myList 0 +``` + +Le résultat ci-dessus produira `[0 1 2 3 4 5]`. `$myList` restera inchangé. + +`prepend` déclenche une panique s'il y a un problème, tandis que `mustPrepend` renvoie une erreur au moteur de templates en cas de problème. + +### concat + +Concaténer un nombre arbitraire de listes en une seule. + +``` +concat $myList ( list 6 7 ) ( list 8 ) +``` + +Cela produira `[1 2 3 4 5 6 7 8]`. `$myList` restera inchangé. + +### reverse, mustReverse + +Produire une nouvelle liste avec les éléments inversés de la liste donnée. + +``` +reverse $myList +``` + +Cela générera la liste `[5 4 3 2 1]`. + +`reverse` provoquera une panique en cas de problème, tandis que `mustReverse` retournera une erreur au moteur de templates s'il y a un problème. + +### uniq, mustUniq + +Générez une liste avec toutes les duplications supprimées. + +``` +list 1 1 1 2 | uniq +``` + +Le résultat ci-dessus produira `[1 2]`. + +`uniq` panique s'il y a un problème, tandis que `mustUniq` renverra une erreur au moteur de modèles s'il y a un problème. + +### without, mustWithout + +La fonction `without` filtre les éléments d'une liste. + +``` +without $myList 3 +``` + +Cela produira `[1 2 4 5]`. + +La fonction `without` peut prendre plusieurs filtres : + +``` +without $myList 1 3 5 +``` + +Cela produira `[2 4]` + +La fonction `without` déclenchera une panique en cas de problème, tandis que `mustWithout` renverra une erreur au moteur de templates en cas de problème. + +### has, mustHas + +Test to see if a list has a particular element. + +``` +has 4 $myList +``` + +L'exemple ci-dessus retournerait `true`, tandis que `has "hello" $myList` retournerait `false`. + +La fonction `has` panique s'il y a un problème, tandis que `mustHas` renverra une erreur au moteur de template en cas de problème. + +### compact, mustCompact + +Accepte une liste et supprime les entrées avec des valeurs vides. + +``` +$list := list 1 "a" "foo" "" +$copy := compact $list +``` + +`compact` renverra une nouvelle liste avec l'élément vide (c'est-à-dire, "") supprimé. + +`compact` panique s'il y a un problème et `mustCompact` renverra une erreur au moteur de template s'il y a un problème. + +### index + +Pour obtenir le n-ième élément d'une liste, utilisez `index list [n]`. Pour indexer des listes multidimensionnelles, utilisez `index list [n] [m] ...` + +- `index $myList 0` renverra `1`. C'est la même chose que `myList[0]`. +- `index $myList 0 1` serait identique à `myList[0][1]`. + +### slice, mustSlice + +Pour obtenir des éléments partiels d'une liste, utilisez `slice list [n] [m]`. Cela équivaut à `list[n:m]`. + +- `slice $myList` renverra `[1 2 3 4 5]`. C'est la même chose que `myList[:]`. +- `slice $myList 3` renverra `[4 5]`. C'est la même chose que `myList[3:]`. +- `slice $myList 1 3` renverra `[2 3]`. C'est la même chose que `myList[1:3]`. +- `slice $myList 0 3` renverra `[1 2 3]`. C'est la même chose que `myList[:3]`. + +`slice` panique s'il y a un problème, tandis que `mustSlice` renverra une erreur au moteur de template s'il y a un problème. + +### until + +La fonction `until` construit une plage d'entiers. + +``` +until 5 +``` + +Cela génère la liste `[0, 1, 2, 3, 4]`. + +Ceci est utile pour itérer avec `range $i, $e := until 5`. + +### untilStep + +Comme `until`, `untilStep` génère une liste d'entiers comptés. Mais il vous permet de définir un point de départ, un point d'arrêt et un pas : + +``` +untilStep 3 6 2 +``` + +Cela produira `[3 5]` en commençant par 3 et en ajoutant 2 jusqu'à ce qu'il soit égal ou supérieur à 6. C'est similaire à la fonction `range` de Python. + +### seq + +Fonctionne comme la commande `seq` de bash. + +* 1 paramètre (fin) - générera tous les entiers entre 1 et `fin`, inclus. +* 2 paramètres (début, fin) - générera tous les entiers entre `début` et `fin`, inclus, en incrémentant ou en décrémentant de 1. +* 3 paramètres (début, pas, fin) - générera tous les entiers entre `début` et `fin`, inclus, en incrémentant ou en décrémentant de `pas`. + +``` +seq 5 => 1 2 3 4 5 +seq -3 => 1 0 -1 -2 -3 +seq 0 2 => 0 1 2 +seq 2 -2 => 2 1 0 -1 -2 +seq 0 2 10 => 0 2 4 6 8 10 +seq 0 -2 -5 => 0 -2 -4 +``` + +## Fonctions Mathématiques + +Toutes les fonctions mathématiques opèrent sur des valeurs `int64`, sauf indication contraire. + +Les fonctions mathématiques suivantes sont disponibles : [add](#add), [add1](#add1), +[ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), +[min](#min), [mod](#mod), [mul](#mul), [round](#round) et [sub](#sub). + +### add + +Additionnez des nombres avec `add`. Accepte deux entrées ou plus. + +``` +add 1 2 3 +``` + +### add1 + +Pour incrémenter de 1, utilisez `add1`. + +### sub + +Pour soustraire, utilisez `sub`. + +### div + +Effectuez une division entière avec `div`. + +### mod + +Effectuez un modulo avec `mod`. + +### mul + +Multipliez avec `mul`. Accepte deux entrées ou plus. + +``` +mul 1 2 3 +``` + +### max + +Retournez le plus grand d'une série d'entiers. + +Cela retournera `3` : + +``` +max 1 2 3 +``` + +### min + +Retournez le plus petit d'une série d'entiers. + +`min 1 2 3` renverra `1`. + +### len + +Retourne la longueur de l'argument sous forme d'entier. + +``` +len .Arg +``` + +## Fonctions mathématiques pour les nombres à virgule flottante. + +Toutes les fonctions mathématiques opèrent sur des valeurs `float64`. + +### addf + +Faites la somme des nombres avec `addf`. + +Cela retournera `5.5` : + +``` +addf 1.5 2 2 +``` + +### add1f + +Pour incrémenter de 1, utilisez `add1f`. + +### subf + +Pour soustraire, utilisez `subf`. + +Ceci est équivalent à `7.5 - 2 - 3` et renverra `2.5`. + +``` +subf 7.5 2 3 +``` + +### divf + +Effectuez une division entière avec `divf`. + +Ceci est équivalent à `10 / 2 / 4` et renverra `1.25`. + +``` +divf 10 2 4 +``` + +### mulf + +Multipliez avec `mulf`. + +Ceci renverra `6`. + +``` +mulf 1.5 2 2 +``` + +### maxf + +Renvoie le plus grand d'une série de nombres à virgule flottante : + +Ceci renverra `3`. + +``` +maxf 1 2.5 3 +``` + +### minf + +Renvoie le plus petit d'une série de nombres à virgule flottante. + +Ceci renverra `1.5`. + +``` +minf 1.5 2 3 +``` + +### floor + +Renvoie la plus grande valeur à virgule flottante inférieure ou égale à la valeur d'entrée. + +`floor 123.9999` renverra `123.0`. + +### ceil + +Renvoie la plus grande valeur à virgule flottante supérieure ou égale à la valeur d'entrée. + +`ceil 123.001` renverra `124.0`. + +### round + +Renvoie une valeur à virgule flottante avec le reste arrondi au nombre donné de chiffres après la virgule décimale. + +`round 123.555555 3` renverra `123.556`. + +## Fonctions Réseaux + +Helm dispose d'une seule fonction réseau, `getHostByName`. + +La fonction `getHostByName` reçoit un nom de domaine et renvoie l'adresse IP. + +`getHostByName "www.google.com"` renverra l'adresse IP correspondante de `www.google.com`. + +## Fonctions de Chemin de Fichier. + +Bien que les fonctions de modèle Helm n'accordent pas l'accès au système de fichiers, elles fournissent des fonctions pour travailler avec des chaînes qui suivent les conventions de chemin de fichier. Cela inclut [base](#base), [clean](#clean), [dir](#dir), [ext](#ext) et [isAbs](#isabs). + +### base + +Retourne le dernier élément d'un chemin. + +``` +base "foo/bar/baz" +``` + +Cela affichera "baz". + +### dir + +Retourne le répertoire, en supprimant la dernière partie du chemin. Ainsi, `dir "foo/bar/baz"` renvoie `foo/bar`. + +### clean + +Nettoie un chemin. + +``` +clean "foo/bar/../baz" +``` + +La phrase ci-dessus résout le `..` et renvoie `foo/baz`. + +### ext + +Retourner l'extension de fichier. + +``` +ext "foo.bar" +``` + +Ce qui précède renverra `.bar`. + +### isAbs + +Pour vérifier si un chemin de fichier est absolu, utilisez `isAbs`. + +## Fonctions de Réflexion + +Helm fournit des outils de réflexion rudimentaires. Ceux-ci aident les développeurs de modèles avancés à comprendre les informations de type Go sous-jacentes pour une valeur particulière. Helm est écrit en Go et utilise un système de types fortement typé. Le système de types s'applique dans les modèles. + +Go possède plusieurs _kinds_ primitifs, comme `string`, `slice`, `int64`, et `bool`. + +Go possède un système de _types_ ouvert qui permet aux développeurs de créer leurs propres types. + +Helm fournit un ensemble de fonctions pour chaque via [fonctions de kind](#kind-functions) et [fonctions de type](#type-functions). Une fonction [deepEqual](#deepequal) est également fournie pour comparer deux valeurs. + +### Fonctions de Kind + +Il existe deux fonctions de kind : `kindOf` retourne le kind (type primitif) d'un objet. + +``` +kindOf "hello" +``` + +La phrase ci-dessus retournerait `string`. Pour des tests simples (comme dans les blocs `if`), la fonction `kindIs` vous permettra de vérifier qu'une valeur est d'un kind particulier : + +``` +kindIs "int" 123 +``` + +La phrase ci-dessus retournerait `true`. + +### Functions de Type + +Les types sont un peu plus difficiles à manipuler, c'est pourquoi il existe trois fonctions différentes : + +- `typeOf` retourne le type sous-jacent d'une valeur : `typeOf $foo` +- `typeIs` fonctionne comme `kindIs`, mais pour les types : `typeIs "*io.Buffer" $myVal` +- `typeIsLike` fonctionne comme `typeIs`, sauf qu'il déréférence également les pointeurs. + +**Remarque :** Aucune de ces fonctions ne peut tester si quelque chose implémente une interface donnée, car cela nécessiterait de compiler l'interface à l'avance. + +### deepEqual + +`deepEqual` retourne true si deux valeurs sont ["profondément égales"](https://golang.org/pkg/reflect/#DeepEqual). + +Fonctionne également pour les types non primitifs (par rapport à la fonction `eq` intégrée). + +``` +deepEqual (list 1 2 3) (list 1 2 3) +``` + +La phrase ci-dessus retournerait `true`. + +## Fonctions de Version Sémantique + +Certains schémas de version sont facilement analysables et comparables. Helm fournit des fonctions pour travailler avec les versions [SemVer 2](http://semver.org). Celles-ci incluent [semver](#semver) et [semverCompare](#semvercompare). Vous trouverez ci-dessous également des détails sur l'utilisation des plages pour les comparaisons. + +### semver + +La fonction `semver` analyse une chaîne de caractères en une version sémantique : + +``` +$version := semver "1.2.3-alpha.1+123" +``` + +_Si l'analyseur échoue, l'exécution du modèle sera arrêtée avec une erreur._ + +À ce stade, `$version` est un pointeur vers un objet `Version` avec les propriétés suivantes : + +- `$version.Major` : Le numéro majeur (`1` ci-dessus) +- `$version.Minor` : Le numéro mineur (`2` ci-dessus) +- `$version.Patch` : Le numéro patch (`3` ci-dessus) +- `$version.Prerelease` : La version préliminaire (`alpha.1` ci-dessus) +- `$version.Metadata` : Les métadonnées de build (`123` ci-dessus) +- `$version.Original` : La version originale en tant que chaîne de caractères + +De plus, vous pouvez comparer une `Version` à une autre version en utilisant la fonction `Compare` : + +``` +semver "1.4.3" | (semver "1.2.3").Compare +``` + +L'exemple ci-dessus retournera `-1`. + +Les valeurs de retour sont : + +- `-1` si la version sémantique donnée est supérieure à la version sémantique dont la méthode `Compare` a été appelée +- `1` si la version dont la fonction `Compare` a été appelée est supérieure +- `0` si ce sont les mêmes versions + +(Notez que dans SemVer, le champ `Metadata` n'est pas comparé lors des opérations de comparaison de versions.) + +### semverCompare + +Une fonction de comparaison plus robuste est fournie sous le nom de `semverCompare`. Cette version prend en charge les plages de versions : + +- `semverCompare "1.2.3" "1.2.3"` vérifie une correspondance exacte. +- `semverCompare "~1.2.0" "1.2.3"` vérifie que les versions majeures et mineures correspondent, et que le numéro de patch de la deuxième version est _supérieur ou égal_ au premier paramètre. + +Les fonctions SemVer utilisent la [bibliothèque semver de Masterminds](https://github.com/Masterminds/semver), créée par les développeurs de Sprig. + +### Comparaisons Simple + +Il y a deux éléments dans les comparaisons. Tout d'abord, une chaîne de comparaison est une liste de comparaisons AND séparées par des espaces ou des virgules. Ensuite, ces comparaisons sont séparées par des `||` (comparaisons OR). Par exemple, `">= 1.2 < 3.0.0 || >= 4.2.3"` recherche une version qui est supérieure ou égale à 1.2 et inférieure à 3.0.0 ou est supérieure ou égale à 4.2.3. + +Les comparaisons de base sont : + +- `=` : égal (alias pour aucun opérateur) +- `!=` : différent de +- `>` : supérieur à +- `<` : inférieur à +- `>=` : supérieur ou égal à +- `<=` : inférieur ou égal à + +### Travailler avec les Versions Préliminaires + +Les préversions, pour ceux qui ne les connaissent pas, sont utilisées pour les versions de logiciels avant les versions stables ou généralement disponibles. Les exemples de préversions incluent les versions de développement, alpha, bêta et candidates à la publication. Une préversion peut être une version telle que `1.2.3-beta.1`, tandis que la version stable serait `1.2.3`. Dans l'ordre de préséance, les préversions précèdent leurs versions associées. Dans cet exemple, `1.2.3-beta.1 < 1.2.3`. + +Selon la spécification de la version sémantique, les préversions peuvent ne pas être compatibles avec l'API de leur version associée. Elle stipule : + +> Une version préliminaire indique que la version est instable et pourrait ne pas +> satisfaire aux exigences de compatibilité prévues telles que désignées par sa version normale associée. + +Les comparaisons SemVer utilisant des contraintes sans un comparateur de préversions ignoreront les préversions. Par exemple, `>=1.2.3` ignorera les préversions lors de l'examen d'une liste de versions, tandis que `>=1.2.3-0` évaluera et trouvera les préversions. + +La raison pour laquelle le `0` est utilisé comme version de préversion dans l'exemple de comparaison est que les préversions ne peuvent contenir que des alphanumériques ASCII et des tirets (avec des séparateurs `.`), selon la spécification. Le tri se fait dans l'ordre de tri ASCII, conformément à la spécification. Le caractère le plus bas est un `0` dans l'ordre de tri ASCII (voir une [table ASCII](http://www.asciitable.com/)). + +Comprendre l'ordre de tri ASCII est important car les lettres majuscules A-Z viennent avant les lettres minuscules a-z. Cela signifie que `>=1.2.3-BETA` retournera `1.2.3-alpha`. Ce que vous pourriez attendre de la sensibilité à la casse ne s'applique pas ici. C'est en raison de l'ordre de tri ASCII qui est ce que spécifie la spécification. + +### Comparaisons de Plages avec Tirets + +Il existe plusieurs méthodes pour gérer les plages, et la première est celle des plages avec tirets. Cela ressemble à : + +- `1.2 - 1.4.5` qui est équivalent à `>= 1.2 <= 1.4.5` +- `2.3.4 - 4.5` qui est équivalent à `>= 2.3.4 <= 4.5` + +### Caractères Génériques dans les Comparaisons + +Les caractères `x`, `X` et `*` peuvent être utilisés comme caractères génériques. Cela fonctionne pour tous les opérateurs de comparaison. Lorsqu'ils sont utilisés avec l'opérateur `=`, ils se replient sur la comparaison au niveau du patch (voir le tilde ci-dessous). Par exemple : + +- `1.2.x` est équivalent à `>= 1.2.0, < 1.3.0` +- `>= 1.2.x` est équivalent à `>= 1.2.0` +- `<= 2.x` est équivalent à `< 3` +- `*` est équivalent à `>= 0.0.0` + +### Comparaisons de Plages avec Tilde (patch) + +L'opérateur de comparaison tilde (`~`) est utilisé pour les plages de niveaux de patch lorsqu'une version mineure est spécifiée et pour les changements de niveaux majeurs lorsque le numéro mineur est absent. Par exemple : + +- `~1.2.3` est équivalent à `>= 1.2.3, < 1.3.0` +- `~1` est équivalent à `>= 1, < 2` +- `~2.3` est équivalent à `>= 2.3, < 2.4` +- `~1.2.x` est équivalent à `>= 1.2.0, < 1.3.0` +- `~1.x` est équivalent à `>= 1, < 2` + +### Comparaisons de Plages avec accent circonflexe (majeur) + +L'opérateur de comparaison accent circonflexe (`^`) est utilisé pour les changements de niveau majeur une fois qu'une version stable (1.0.0) a été publiée. Avant une version 1.0.0, les versions mineures agissent comme le niveau de stabilité de l'API. Cela est utile pour les comparaisons des versions de l'API, car un changement majeur casse la compatibilité de l'API. Par exemple : + +- `^1.2.3` est équivalent à `>= 1.2.3, < 2.0.0` +- `^1.2.x` est équivalent à `>= 1.2.0, < 2.0.0` +- `^2.3` est équivalent à `>= 2.3, < 3` +- `^2.x` est équivalent à `>= 2.0.0, < 3` +- `^0.2.3` est équivalent à `>= 0.2.3, < 0.3.0` +- `^0.2` est équivalent à `>= 0.2.0, < 0.3.0` +- `^0.0.3` est équivalent à `>= 0.0.3, < 0.0.4` +- `^0.0` est équivalent à `>= 0.0.0, < 0.1.0` +- `^0` est équivalent à `>= 0.0.0, < 1.0.0` + +## Fonctions d'URL + +Helm inclut les fonctions [urlParse](#urlparse), [urlJoin](#urljoin) et [urlQuery](#urlquery) vous permettant de travailler avec les parties d'une URL. + +### urlParse + +Analyse une chaîne pour une URL et produit un dictionnaire avec les parties de l'URL. + +``` +urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" +``` + +Ce qui précède renverra un dictionnaire contenant l'objet URL : + +```yaml +scheme: 'http' +host: 'server.com:8080' +path: '/api' +query: 'list=false' +opaque: nil +fragment: 'anchor' +userinfo: 'admin:secret' +``` + +Cela est implémenté en utilisant les packages URL de la bibliothèque standard Go. Pour plus d'informations, consultez https://golang.org/pkg/net/url/#URL + +### urlJoin + +Concatène une map (produite par `urlParse`) pour produire une chaîne URL. + +``` +urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") +``` + +Cela retournera la chaîne suivante : +``` +http://host:80/path?query#fragment +``` + +### urlquery + +Renvoie la version échappée de la valeur passée en argument de manière à ce qu'elle soit adaptée à l'insertion dans la partie query d'une URL. + +``` +$var := urlquery "string for query" +``` + +## Fonctions UUID + +Helm peut générer des UUID v4 (identifiants uniques universels). + +``` +uuidv4 +``` + +L'exemple 'ci-dessus renverra un nouvel UUID de type v4 (généré de manière aléatoire). + +## Kubernetes et Fonctions de Charts + +Helm inclut des fonctions pour travailler avec Kubernetes, y compris +[.Capabilities.APIVersions.Has](#capabilitiesapiversionshas), +[Files](#file-functions) et [lookup](#lookup). + +### lookup + +`lookup` est utilisé pour rechercher des ressources dans un cluster en cours d'exécution. Lorsqu'il est utilisé avec la commande `helm template`, il renvoie toujours une réponse vide. + +Vous pouvez trouver plus de détails dans la [documentation sur la fonction lookup]({{}}). + +### .Capabilities.APIVersions.Has + +Renvoie si une version d'API ou une ressource est disponible dans un cluster. + +``` +.Capabilities.APIVersions.Has "apps/v1" +.Capabilities.APIVersions.Has "apps/v1/Deployment" +``` + +Plus d'informations sont disponibles sur le [built-in objects]({{}}). + +### Fonctions de Fichiers + +Il existe plusieurs fonctions qui vous permettent d'accéder à des fichiers non spéciaux dans un chart. Par exemple, pour accéder aux fichiers de configuration de l'application. Ces fonctions sont documentées dans [Accéder aux fichiers à l'intérieur des modèles]({{}}). + +_Remarque : la documentation pour beaucoup de ces fonctions provient de [Sprig](https://github.com/Masterminds/sprig). Sprig est une bibliothèque de fonctions de modèle disponible pour les applications Go._ diff --git a/content/fr/docs/chart_template_guide/functions_and_pipelines.md b/content/fr/docs/chart_template_guide/functions_and_pipelines.md new file mode 100644 index 000000000..3ebd0c753 --- /dev/null +++ b/content/fr/docs/chart_template_guide/functions_and_pipelines.md @@ -0,0 +1,204 @@ +--- +title: "Fonctions de Modèle et Pipelines." +description: "Utiliser des fonctions dans les modèles" +weight: 5 +--- + +Jusqu'à présent, nous avons vu comment insérer des informations dans un modèle. Mais ces informations sont placées dans le modèle sans modification. Parfois, nous souhaitons transformer les données fournies d'une manière qui les rend plus utilisables pour nous. + +Commençons par une bonne pratique : lorsque nous injectons des chaînes à partir de l'objet `.Values` dans le modèle, nous devrions entourer ces chaînes de guillemets. Nous pouvons le faire en appelant la fonction `quote` dans la directive du modèle : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ quote .Values.favorite.drink }} + food: {{ quote .Values.favorite.food }} +``` + +Les fonctions de modèle suivent la syntaxe `nomDeFonction arg1 arg2...`. Dans l'extrait ci-dessus, `quote .Values.favorite.drink` appelle la fonction `quote` et lui passe un seul argument. + +Helm dispose de plus de 60 fonctions disponibles. Certaines d'entre elles sont définies par le [langage de modèle Go](https://godoc.org/text/template) lui-même. La plupart des autres font partie de la [bibliothèque de modèles Sprig](https://masterminds.github.io/sprig/). Nous en verrons beaucoup au fur et à mesure de notre progression dans les exemples. + +> Bien que nous parlions du "langage de modèle Helm" comme s'il était spécifique à Helm, il s'agit en réalité d'une combinaison du langage de modèle Go, de certaines fonctions supplémentaires et d'une variété d'enveloppes pour exposer certains objets aux modèles. De nombreuses ressources sur les modèles Go peuvent être utiles lors de votre apprentissage des modèles. + +## Pipelines + +L'une des fonctionnalités puissantes du langage de modèle est son concept de _pipelines_. S'inspirant d'un concept UNIX, les pipelines sont un outil pour enchaîner une série de commandes de modèle afin d'exprimer de manière concise une série de transformations. En d'autres termes, les pipelines constituent un moyen efficace d'effectuer plusieurs opérations en séquence. Réécrivons l'exemple ci-dessus en utilisant un pipeline. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | quote }} + food: {{ .Values.favorite.food | quote }} +``` + +Dans cet exemple, au lieu d'appeler `quote ARGUMENT`, nous avons inversé l'ordre. Nous avons "envoyé" l'argument à la fonction en utilisant un pipe (`|`): `.Values.favorite.drink | quote`. Grâce aux pipes, nous pouvons enchaîner plusieurs fonctions ensemble : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | quote }} + food: {{ .Values.favorite.food | upper | quote }} +``` + +> Inverser l'ordre est une pratique courante dans les templates. Vous verrez plus souvent `.val | quote` que `quote .val`. Les deux pratiques sont acceptables. + +Lorsque ce template sera évalué, il produira ceci : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: trendsetting-p-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" +``` + +Notez que notre `pizza` d'origine a maintenant été transformé en `"PIZZA"`. + +Lors du passage des arguments de cette manière, le résultat de la première évaluation (`.Values.favorite.drink`) est envoyé comme le _dernier argument à la fonction_. Nous pouvons modifier l'exemple de boisson pour illustrer cela avec une fonction qui prend deux arguments : `repeat COUNT STRING` : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | repeat 5 | quote }} + food: {{ .Values.favorite.food | upper | quote }} +``` + +La fonction `repeat` va répéter la chaîne donnée le nombre de fois indiqué, donc nous obtiendrons ceci comme sortie : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: melting-porcup-configmap +data: + myvalue: "Hello World" + drink: "coffeecoffeecoffeecoffeecoffee" + food: "PIZZA" +``` + +## Utilisation de la fonction `default` + +Une fonction souvent utilisée dans les modèles est la fonction `default` : `default DEFAULT_VALUE GIVEN_VALUE`. Cette fonction vous permet de spécifier une valeur par défaut à l'intérieur du modèle, au cas où la valeur serait omise. Utilisons-la pour modifier l'exemple de boisson ci-dessus : + +```yaml +drink: {{ .Values.favorite.drink | default "tea" | quote }} +``` + +Si nous exécutons cela normalement, nous obtiendrons notre `coffee` : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: virtuous-mink-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" +``` + +Maintenant, nous allons supprimer le paramètre de boisson préférée de `values.yaml` : + +```yaml +favorite: + #drink: coffee + food: pizza +``` + +Maintenant, relançons la commande `helm install --dry-run --debug fair-worm ./mychart` ce qui produira ce YAML : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: fair-worm-configmap +data: + myvalue: "Hello World" + drink: "tea" + food: "PIZZA" +``` + +Dans un véritable chart, toutes les valeurs par défaut statiques doivent résider dans le fichier `values.yaml` et ne doivent pas être répétées à l'aide de la commande `default` (sinon, elles seraient redondantes). Cependant, la commande `default` est parfaite pour les valeurs calculées, qui ne peuvent pas être déclarées dans `values.yaml`. Par exemple : + +```yaml +drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} +``` + +Dans certains cas, une conditionnelle `if` peut être mieux adaptée que `default`. Nous verrons cela dans la section suivante. + +Les fonctions de template et les pipelines sont un moyen puissant de transformer des informations puis de les insérer dans votre YAML. Mais parfois, il est nécessaire d'ajouter une logique de template qui est un peu plus sophistiquée que simplement insérer une chaîne. Dans la section suivante, nous examinerons les structures de contrôle fournies par le langage de template. + +## Utilisation de la fonction `lookup` + +La fonction `lookup` peut être utilisée pour _chercher_ des ressources dans un cluster en cours d'exécution. La syntaxe de la fonction lookup est `lookup apiVersion, kind, namespace, name -> ressource ou liste de ressources`. + +| paramètre | type | +|------------|--------| +| apiVersion | string | +| kind | string | +| namespace | string | +| name | string | + +À la fois `name` et `namespace` sont optionnels et peuvent être passés comme une chaîne vide (`""`). + +Les combinaisons de paramètres suivantes sont possibles : + +| Commandes | Fonction Lookup | +|----------------------------------------|--------------------------------------------| +| `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | +| `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | +| `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | +| `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | +| `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | + +Lorsque `lookup` renvoie un objet, il renvoie un dictionnaire. Ce dictionnaire peut être navigué davantage pour extraire des valeurs spécifiques. + +L'exemple suivant renverra les annotations présentes pour l'objet `mynamespace` : + +```go +(lookup "v1" "Namespace" "" "mynamespace").metadata.annotations +``` + +Lorsque `lookup` renvoie une liste d'objets, il est possible d'accéder à la liste des objets via le champ `items` : + +```go +{{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} + {{/* fait quelque chose avec chaque service */}} +{{ end }} +``` + +Lorsque aucun objet n'est trouvé, une valeur vide est renvoyée. Cela peut être utilisé pour vérifier l'existence d'un objet. + +La fonction `lookup` utilise la configuration de connexion Kubernetes existante de Helm pour interroger Kubernetes. Si une erreur est renvoyée lors de l'interaction avec l'API (par exemple, en raison d'un manque de permission pour accéder à une ressource), le traitement des modèles de Helm échouera. + +Gardez à l'esprit que Helm n'est pas censé contacter le serveur API Kubernetes pendant une opération `helm template|install|upgrade|delete|rollback --dry-run`. Pour tester `lookup` contre un cluster en cours d'exécution, il est conseillé d'utiliser `helm template|install|upgrade|delete|rollback --dry-run=server` afin de permettre la connexion au cluster. + +## Les opérateurs sont des fonctions + +Pour les modèles, les opérateurs (`eq`, `ne`, `lt`, `gt`, `and`, `or`, etc.) sont tous implémentés en tant que fonctions. Dans les pipelines, les opérations peuvent être regroupées avec des parenthèses (`(` and `)`). + +Nous pouvons maintenant passer des fonctions et des pipelines au contrôle de flux avec des conditions, des boucles et des modificateurs de portée. diff --git a/content/fr/docs/chart_template_guide/getting_started.md b/content/fr/docs/chart_template_guide/getting_started.md new file mode 100644 index 000000000..3d46d5977 --- /dev/null +++ b/content/fr/docs/chart_template_guide/getting_started.md @@ -0,0 +1,216 @@ +--- +title: "Commencer" +weight: 2 +description: "Un guide rapide sur les templates de Chart" +--- + +Dans cette section du guide, nous allons créer un chart puis ajouter un premier template. Le chart que nous créons ici sera utilisé tout au long du reste du guide. + +Pour commencer, jetons un rapide coup d'œil à un chart Helm. + +## Charts + +Comme décrit dans le [Guide des Charts](../../topics/charts), les charts Helm sont structurés de cette manière : + +``` +mychart/ + Chart.yaml + values.yaml + charts/ + templates/ + ... +``` + +Le répertoire `templates/` est destiné aux fichiers de template. Lorsque Helm évalue un chart, il enverra tous les fichiers du répertoire `templates/` au moteur de rendu des templates. Ensuite, il collecte les résultats de ces templates et les transmet à Kubernetes. + +Le fichier `values.yaml` est également important pour les templates. Ce fichier contient les _valeurs par défaut_ pour un chart. Ces valeurs peuvent être remplacées par les utilisateurs lors de `helm install` ou `helm upgrade`. + +Le fichier `Chart.yaml` contient une description du chart. Vous pouvez y accéder depuis un template. + +Le répertoire `charts/` _peut_ contenir d'autres charts (que nous appelons _sous-charts_). Plus tard dans ce guide, nous verrons comment ceux-ci fonctionnent lors du rendu des templates. + +## Chart d'Initiation + +Pour ce guide, nous allons créer un chart simple appelé `mychart`, puis nous allons créer quelques templates à l'intérieur de ce chart. + +```console +$ helm create mychart +Creating mychart +``` + +### Un aperçu rapide de `mychart/templates/` + +Si vous regardez le répertoire `mychart/templates/`, vous remarquerez qu'il y a déjà quelques fichiers présents. + +- `NOTES.txt` : Le "texte d'aide" pour votre chart. Cela sera affiché à vos utilisateurs lorsqu'ils exécutent `helm install`. +- `deployment.yaml` : Un manifeste de base pour créer un [déploiement Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/). +- `service.yaml` : Un manifeste de base pour créer un [service](https://kubernetes.io/docs/concepts/services-networking/service/) pour votre déploiement. +- `_helpers.tpl` : Un endroit pour mettre des helpers de template que vous pouvez réutiliser dans tout le chart. + +Et ce que nous allons faire, c'est... _les supprimer tous !_ Ainsi, nous pourrons travailler à travers notre tutoriel depuis le début. Nous allons en fait créer notre propre `NOTES.txt` et `_helpers.tpl` au fur et à mesure. + +```console +$ rm -rf mychart/templates/* +``` + +Lorsque vous rédigez des charts de qualité production, avoir des versions de base de ces charts peut être très utile. Donc, dans votre rédaction quotidienne de charts, vous ne voudrez probablement pas les supprimer. + +## Premier Modèle + +Le premier template que nous allons créer sera un `ConfigMap`. Dans Kubernetes, un ConfigMap est simplement un objet pour stocker des données de configuration. D'autres objets, comme les pods, peuvent accéder aux données dans un ConfigMap. + +Parce que les ConfigMaps sont des ressources de base, ils constituent un excellent point de départ pour nous. + +Commençons par créer un fichier appelé `mychart/templates/configmap.yaml` : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: mychart-configmap +data: + myvalue: "Hello World" +``` + +**CONSEIL :** Les noms de modèles ne suivent pas un schéma de nommage rigide. Cependant, nous recommandons d'utiliser l'extension `.yaml` pour les fichiers YAML et `.tpl` pour les fichiers d'assistance. + +Le fichier YAML ci-dessus est un ConfigMap minimal, comportant les champs nécessaires. En raison du fait que ce fichier se trouve dans le répertoire `mychart/templates/`, il sera traité par le moteur de template. + +Il est tout à fait acceptable de placer un fichier YAML simple comme celui-ci dans le répertoire `mychart/templates/`. Lorsque Helm lit ce template, il l'enverra simplement à Kubernetes tel quel. + +Avec ce template simple, nous avons maintenant un chart installable. Nous pouvons l'installer de la manière suivante : + +```console +$ helm install full-coral ./mychart +NAME: full-coral +LAST DEPLOYED: Tue Nov 1 17:36:01 2016 +NAMESPACE: default +STATUS: DEPLOYED +REVISION: 1 +TEST SUITE: None +``` + +En utilisant Helm, nous pouvons récupérer la version et voir le template réel qui a été chargé. + +```console +$ helm get manifest full-coral + +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: mychart-configmap +data: + myvalue: "Hello World" +``` + +La commande `helm get manifest` prend un nom de version (`full-coral`) et affiche toutes les ressources Kubernetes qui ont été téléchargées sur le serveur. Chaque fichier commence par `---` pour indiquer le début d'un document YAML, suivi d'une ligne de commentaire générée automatiquement qui nous indique quel fichier de template a généré ce document YAML. + +À partir de là, nous pouvons constater que les données YAML sont exactement ce que nous avons mis dans notre fichier `configmap.yaml`. + +Maintenant, nous pouvons désinstaller notre release : `helm uninstall full-coral`. + +### Ajouter un appel de template simple + +Il est généralement considéré comme une mauvaise pratique de coder en dur le champ `name:` dans une ressource. Les noms doivent être uniques à une release. Ainsi, nous pourrions vouloir générer un champ de nom en insérant le nom de la release. + +**ASTUCE :** Le champ `name:` est limité à 63 caractères en raison des limitations du système DNS. Pour cette raison, les noms de release sont limités à 53 caractères. Kubernetes 1.3 et les versions antérieures limitaient cela à seulement 24 caractères (ce qui signifie des noms de 14 caractères maximum). + +Modifions `configmap.yaml` en conséquence. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" +``` + +Le changement majeur concerne la valeur du champ `name:`, qui est maintenant `{{ .Release.Name }}-configmap`. + +> Une directive de template est encadrée par des blocs `{{` et `}}`. + +La directive de template `{{ .Release.Name }}` injecte le nom de la version dans le template. Les valeurs passées dans un template peuvent être considérées comme des objets _namespacés_, où un point (`.`) sépare chaque élément du namespace. + +Le point précédant `Release` indique que nous commençons par le namespace le plus élevé pour ce scope (nous parlerons du scope un peu plus tard). Ainsi, nous pourrions lire `.Release.Name` comme "partir du namespace supérieur, trouver l'objet `Release`, puis chercher à l'intérieur de celui-ci un objet appelé `Name`". + +L'objet `Release` est l'un des objets intégrés de Helm, et nous le couvrirons plus en profondeur plus tard. Mais pour l'instant, il suffit de dire que cela affichera le nom de la release que la bibliothèque attribue à notre release. + +Maintenant, lorsque nous installons notre ressource, nous verrons immédiatement le résultat de l'utilisation de cette directive de template : + +```console +$ helm install clunky-serval ./mychart +NAME: clunky-serval +LAST DEPLOYED: Tue Nov 1 17:45:37 2016 +NAMESPACE: default +STATUS: DEPLOYED +REVISION: 1 +TEST SUITE: None +``` + +Vous pouvez exécuter `helm get manifest clunky-serval` pour voir l'intégralité du YAML généré. + +Notez que le nom du ConfigMap dans Kubernetes est `clunky-serval-configmap` au lieu de `mychart-configmap` comme auparavant. + +À ce stade, nous avons vu les modèles dans leur forme la plus basique : des fichiers YAML contenant des directives de modèle intégrées dans `{{` et `}}`. Dans la prochaine partie, nous examinerons les modèles de manière plus approfondie. Mais avant de continuer, voici une astuce rapide qui peut rendre la création de modèles plus rapide : lorsque vous souhaitez tester le rendu des modèles sans rien installer, vous pouvez utiliser `helm install --debug --dry-run goodly-guppy ./mychart`. Cela rendra les modèles. Mais au lieu d'installer le graphique, cela vous renverra le modèle rendu afin que vous puissiez voir la sortie : + +```console +$ helm install --debug --dry-run goodly-guppy ./mychart +install.go:149: [debug] Original chart version: "" +install.go:166: [debug] CHART PATH: /Users/ninja/mychart + +NAME: goodly-guppy +LAST DEPLOYED: Thu Dec 26 17:24:13 2019 +NAMESPACE: default +STATUS: pending-install +REVISION: 1 +TEST SUITE: None +USER-SUPPLIED VALUES: +{} + +COMPUTED VALUES: +affinity: {} +fullnameOverride: "" +image: + pullPolicy: IfNotPresent + repository: nginx +imagePullSecrets: [] +ingress: + annotations: {} + enabled: false + hosts: + - host: chart-example.local + paths: [] + tls: [] +nameOverride: "" +nodeSelector: {} +podSecurityContext: {} +replicaCount: 1 +resources: {} +securityContext: {} +service: + port: 80 + type: ClusterIP +serviceAccount: + create: true + name: null +tolerations: [] + +HOOKS: +MANIFEST: +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: goodly-guppy-configmap +data: + myvalue: "Hello World" + +``` + +L'utilisation de `--dry-run` facilitera le test de votre code, mais cela ne garantira pas que Kubernetes acceptera les modèles que vous générez. Il est préférable de ne pas supposer que votre graphique s'installera simplement parce que `--dry-run` fonctionne. + +Dans le [Guide des modèles de graphiques](content/en/docs/chart_template_guide/_index.md), nous prendrons le graphique de base que nous avons défini ici et explorerons en détail le langage de modèle Helm. Nous commencerons par les objets intégrés. diff --git a/content/fr/docs/chart_template_guide/helm_ignore_file.md b/content/fr/docs/chart_template_guide/helm_ignore_file.md new file mode 100644 index 000000000..572c91bc3 --- /dev/null +++ b/content/fr/docs/chart_template_guide/helm_ignore_file.md @@ -0,0 +1,58 @@ +--- +title: "Fichier .helmignore" +description: "Le fichier `.helmignore` est utilisé pour spécifier les fichiers que vous ne souhaitez pas inclure dans votre graphique Helm" +weight: 12 +--- + +Le fichier `.helmignore` est utilisé pour spécifier les fichiers que vous ne souhaitez pas inclure dans votre graphique Helm. + +Si ce fichier existe, la commande `helm package` ignorera tous les fichiers qui correspondent aux motifs spécifiés dans le fichier `.helmignore` lors de l'emballage de votre application. + +Cela peut aider à éviter que des fichiers ou des répertoires inutiles ou sensibles ne soient ajoutés à votre chart Helm. + +Le fichier `.helmignore` prend en charge la correspondance de motifs de type glob Unix, la correspondance de chemins relatifs et la négation (préfixée par !). Seul un motif par ligne est pris en compte. + +Voici un exemple de fichier `.helmignore` : + +Voici la traduction des commentaires du fichier `.helmignore` : + +``` +# Commentaire + +# Correspond à tout fichier ou chemin nommé .helmignore +.helmignore + +# Correspond à tout fichier ou chemin nommé .git +.git + +# Correspond à tout fichier texte +*.txt + +# Correspond uniquement aux répertoires nommés mydir +mydir/ + +# Correspond uniquement aux fichiers texte dans le répertoire de premier niveau +/*.txt + +# Correspond uniquement au fichier foo.txt dans le répertoire de premier niveau +/foo.txt + +# Correspond à tout fichier nommé ab.txt, ac.txt ou ad.txt +a[b-d].txt + +# Correspond à tout fichier sous un sous-répertoire correspondant à temp* +*/temp* + +# Correspond à tout fichier sous n'importe quel sous-répertoire se terminant par temp +*/*/temp* +temp? +``` + +Quelques différences notables par rapport à `.gitignore` : +- La syntaxe `**` n'est pas prise en charge. +- La bibliothèque de correspondance utilise `filepath.Match` de Go, et non `fnmatch(3)`. +- Les espaces à la fin sont toujours ignorés (il n'y a pas de séquence d'échappement prise en charge). +- Il n'y a pas de support pour `\!` en tant que séquence spéciale de début. +- Il ne s'exclut pas par défaut ; vous devez ajouter une entrée explicite pour `.helmignore`. + +**Nous aimerions votre aide** pour améliorer ce document. Pour ajouter, corriger ou supprimer des informations, [signalez un problème](https://github.com/helm/helm-www/issues) ou envoyez-nous une demande de pull request. diff --git a/content/fr/docs/chart_template_guide/named_templates.md b/content/fr/docs/chart_template_guide/named_templates.md new file mode 100644 index 000000000..febcc4963 --- /dev/null +++ b/content/fr/docs/chart_template_guide/named_templates.md @@ -0,0 +1,287 @@ +--- +title: "Templates Nommés" +description: "Comment définir des templates nommés" +weight: 9 +--- + +Il est temps de passer au-delà d'un seul template et de commencer à en créer d'autres. Dans cette section, nous verrons comment définir des _templates nommés_ dans un fichier, puis les utiliser ailleurs. Un _template nommé_ (parfois appelé _partiel_ ou _sous-template_) est simplement un template défini à l'intérieur d'un fichier et auquel on donne un nom. Nous verrons deux façons de les créer et quelques façons différentes de les utiliser. + +Dans la section [Contrôle de flux](content/en/docs/chart_template_guide/control_structures.md), nous avons présenté trois actions pour déclarer et gérer des templates : `define`, `template` et `block`. Dans cette section, nous aborderons ces trois actions, et nous introduirons également une fonction à usage spécial `include` qui fonctionne de manière similaire à l'action `template`. + +Un détail important à garder à l'esprit lors de la nomination des templates : **les noms des templates sont globaux**. Si vous déclarez deux templates avec le même nom, celui qui est chargé en dernier sera celui utilisé. Étant donné que les templates dans les sous-charts sont compilés avec les templates de niveau supérieur, vous devez faire attention à nommer vos templates avec des _noms spécifiques au chart_. + +Une convention de nommage populaire consiste à préfixer chaque template défini par le nom du chart : `{{ define "mychart.labels" }}`. En utilisant le nom spécifique du chart comme préfixe, nous pouvons éviter tout conflit qui pourrait survenir en raison de deux charts différents qui implémentent des templates du même nom. + +Ce comportement s'applique également aux différentes versions d'un chart. Si vous avez le chart `mychart` version `1.0.0` qui définit un template d'une certaine manière, et un `mychart` version `2.0.0` qui modifie le template nommé existant, il utilisera celui qui a été chargé en dernier. Vous pouvez contourner ce problème en ajoutant également une version dans le nom du chart : `{{ define "mychart.v1.labels" }}` et `{{ define "mychart.v2.labels" }}`. + +## Partiels et fichiers `_` + +Jusqu'à présent, nous avons utilisé un fichier, et ce fichier contenait un seul modèle. Mais le langage de modèles de Helm permet de créer des modèles imbriqués nommés, qui peuvent être accessibles par leur nom ailleurs. + +Avant d'entrer dans les détails de l'écriture de ces modèles, il y a une convention de nommage des fichiers qui mérite d'être mentionnée : + +* La plupart des fichiers dans `templates/` sont considérés comme contenant des manifests Kubernetes. +* Le fichier `NOTES.txt` est une exception. +* Cependant, les fichiers dont le nom commence par un underscore (`_`) sont supposés _ne pas_ contenir de manifestes à l'intérieur. Ces fichiers ne sont pas rendus en définitions d'objets Kubernetes, mais sont disponibles partout dans les autres modèles de chartes pour utilisation. + +Ces fichiers sont utilisés pour stocker des partiels et des helpers. En fait, lorsque nous avons d'abord créé `mychart`, nous avons vu un fichier appelé `_helpers.tpl`. Ce fichier est l'emplacement par défaut pour les partiels de modèles. + +## Déclaration et utilisation de modèles avec `define` et `template` + +L'action `define` nous permet de créer un modèle nommé à l'intérieur d'un fichier de modèle. Sa syntaxe est la suivante : + +```yaml +{{- define "MY.NAME" }} + # corps du modèle ici +{{- end }} +``` + +Par exemple, nous pouvons définir un modèle pour encapsuler un bloc de labels Kubernetes : + +```yaml +{{- define "mychart.labels" }} + labels: + generator: helm + date: {{ now | htmlDate }} +{{- end }} +``` + +Maintenant, nous pouvons intégrer ce modèle à notre ConfigMap existant, puis l'inclure avec l'action `template` : + +```yaml +{{- define "mychart.labels" }} + labels: + generator: helm + date: {{ now | htmlDate }} +{{- end }} +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap + {{- template "mychart.labels" }} +data: + myvalue: "Hello World" + {{- range $key, $val := .Values.favorite }} + {{ $key }}: {{ $val | quote }} + {{- end }} +``` + +Lorsque le moteur de modèles lit ce fichier, il conservera la référence à `mychart.labels` jusqu'à ce que `template "mychart.labels"` soit appelé. Ensuite, il rendra ce modèle en ligne. Le résultat ressemblera donc à ceci : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: running-panda-configmap + labels: + generator: helm + date: 2016-11-02 +data: + myvalue: "Hello World" + drink: "coffee" + food: "pizza" +``` + +Remarque : un `define` ne produit pas de sortie à moins qu'il ne soit appelé avec un modèle, comme dans cet exemple. + +Conventionnellement, les charts Helm placent ces modèles à l'intérieur d'un fichier de partials, généralement `_helpers.tpl`. Déplaçons cette fonction là-bas : + +```yaml +{{/* Generate basic labels */}} +{{- define "mychart.labels" }} + labels: + generator: helm + date: {{ now | htmlDate }} +{{- end }} +``` + +Par convention, les fonctions `define` doivent avoir un bloc de documentation simple (`{{/* ... */}}`) décrivant ce qu'elles font. + +Bien que cette définition soit dans `_helpers.tpl`, elle peut toujours être accessible dans `configmap.yaml`. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap + {{- template "mychart.labels" }} +data: + myvalue: "Hello World" + {{- range $key, $val := .Values.favorite }} + {{ $key }}: {{ $val | quote }} + {{- end }} +``` + +Comme mentionné ci-dessus, **les noms de modèles sont globaux**. Par conséquent, si deux modèles sont déclarés avec le même nom, la dernière occurrence sera celle qui sera utilisée. Étant donné que les modèles dans les sous-charts sont compilés avec les modèles de niveau supérieur, il est préférable de nommer vos modèles avec des _noms spécifiques au chart_. Une convention de nommage populaire consiste à préfixer chaque modèle défini avec le nom du chart : `{{ define "mychart.labels" }}`. + +## Définir la portée d'un modèle + +Dans le modèle que nous avons défini ci-dessus, nous n'avons utilisé aucun objet. Nous avons simplement utilisé des fonctions. Modifions notre modèle défini pour inclure le nom du chart et la version du chart : + +```yaml +{{/* Generate basic labels */}} +{{- define "mychart.labels" }} + labels: + generator: helm + date: {{ now | htmlDate }} + chart: {{ .Chart.Name }} + version: {{ .Chart.Version }} +{{- end }} +``` + +Si nous rendons cela, nous obtiendrons une erreur comme celle-ci : + +```console +$ helm install --dry-run moldy-jaguar ./mychart +Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] +``` + +Pour voir ce qui a été rendu, réexécutez avec `--disable-openapi-validation` : `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. Le résultat ne sera pas ce que nous attendons : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: moldy-jaguar-configmap + labels: + generator: helm + date: 2021-03-06 + chart: + version: +``` + +Que s'est-il passé avec le nom et la version ? Ils n'étaient pas dans le scope de notre template défini. Lorsqu'un template nommé (créé avec `define`) est rendu, il recevra le scope passé par l'appel `template`. Dans notre exemple, nous avons inclus le template de cette manière : + +```yaml +{{- template "mychart.labels" }} +``` + +Aucun scope n'a été passé, donc à l'intérieur du template, nous ne pouvons accéder à rien dans `.`. Cela se résout facilement : il suffit de passer un scope au template : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap + {{- template "mychart.labels" . }} +``` + +Notez que nous passons `.` à la fin de l'appel `template`. Nous pourrions tout aussi bien passer `.Values`, `.Values.favorite` ou tout autre scope que nous souhaitons. Mais ce que nous voulons, c'est le scope de niveau supérieur. + +Maintenant, lorsque nous exécutons ce modèle avec `helm install --dry-run --debug plinking-anaco ./mychart`, nous obtenons ceci : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: plinking-anaco-configmap + labels: + generator: helm + date: 2021-03-06 + chart: mychart + version: 0.1.0 +``` + +Maintenant, `{{ .Chart.Name }}` résout à `mychart`, et `{{ .Chart.Version }}` résout à `0.1.0`. + +## La fonction `include` + +Disons que nous avons défini un modèle simple qui ressemble à ceci : + +```yaml +{{- define "mychart.app" -}} +app_name: {{ .Chart.Name }} +app_version: "{{ .Chart.Version }}" +{{- end -}} +``` + +Maintenant, disons que je veux insérer cela à la fois dans la section `labels:` de mon modèle, et aussi dans la section `data:` : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap + labels: + {{ template "mychart.app" . }} +data: + myvalue: "Hello World" + {{- range $key, $val := .Values.favorite }} + {{ $key }}: {{ $val | quote }} + {{- end }} +{{ template "mychart.app" . }} +``` + +Si nous rendons cela, nous obtiendrons une erreur comme celle-ci : + +```console +$ helm install --dry-run measly-whippet ./mychart +Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] +``` + +Pour voir ce qui a été rendu, réexécutez avec `--disable-openapi-validation` : +`helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. La sortie ne sera pas ce que nous attendons : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: measly-whippet-configmap + labels: + app_name: mychart +app_version: "0.1.0" +data: + myvalue: "Hello World" + drink: "coffee" + food: "pizza" +app_name: mychart +app_version: "0.1.0" +``` + +Notez que l'indentation de `app_version` est incorrecte dans les deux endroits. Pourquoi ? Parce que le modèle qui est substitué a le texte aligné à gauche. Comme `template` est une action et non une fonction, il n'y a pas moyen de passer la sortie d'un appel `template` à d'autres fonctions ; les données sont simplement insérées en ligne. + +Pour contourner ce cas, Helm propose une alternative à `template` qui importera le contenu d'un modèle dans le pipeline actuel, où il pourra être transmis à d'autres fonctions dans le pipeline. + +Voici l'exemple ci-dessus, corrigé pour utiliser `indent` afin d'indiquer correctement le modèle `mychart.app` : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap + labels: +{{ include "mychart.app" . | indent 4 }} +data: + myvalue: "Hello World" + {{- range $key, $val := .Values.favorite }} + {{ $key }}: {{ $val | quote }} + {{- end }} +{{ include "mychart.app" . | indent 2 }} +``` + +Maintenant, le YAML produit est correctement indenté pour chaque section : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: edgy-mole-configmap + labels: + app_name: mychart + app_version: "0.1.0" +data: + myvalue: "Hello World" + drink: "coffee" + food: "pizza" + app_name: mychart + app_version: "0.1.0" +``` + +> Il est considéré comme préférable d'utiliser `include` plutôt que `template` dans les modèles Helm afin que le formatage de la sortie puisse être géré plus efficacement pour les documents YAML. + +Parfois, nous souhaitons importer du contenu, mais pas en tant que modèles. C'est-à-dire que nous voulons importer des fichiers tels quels. Nous pouvons y parvenir en accédant aux fichiers via l'objet `.Files` décrit dans la section suivante. diff --git a/content/fr/docs/chart_template_guide/notes_files.md b/content/fr/docs/chart_template_guide/notes_files.md new file mode 100644 index 000000000..f331a2288 --- /dev/null +++ b/content/fr/docs/chart_template_guide/notes_files.md @@ -0,0 +1,49 @@ +--- +title: "Créer un fichier NOTES.txt" +description: "Comment fournir des instructions à vos utilisateurs de Chart" +weight: 10 +--- + +Dans cette section, nous allons examiner l'outil de Helm pour fournir des instructions à vos utilisateurs de Chart. À la fin d'une commande `helm install` ou `helm upgrade`, Helm peut imprimer un bloc d'informations utiles pour les utilisateurs. Ces informations sont hautement personnalisables à l'aide de modèles. + +Pour ajouter des notes d'installation à votre chart, il vous suffit de créer un fichier `templates/NOTES.txt`. Ce fichier est un texte brut, mais il est traité comme un modèle et dispose de toutes les fonctions et objets de modèle habituels disponibles. + +Créons un simple fichier `NOTES.txt` : + +``` +Merci d'avoir installé {{ .Chart.Name }}. + +Votre nom de release est {{ .Release.Name }}. + +Pour en savoir plus sur cette release, essayez : + + $ helm status {{ .Release.Name }} + $ helm get all {{ .Release.Name }} + +``` + +Maintenant, si nous exécutons `helm install rude-cardinal ./mychart`, nous verrons ce message en bas : + +``` +RESOURCES: +==> v1/Secret +NAME TYPE DATA AGE +rude-cardinal-secret Opaque 1 0s + +==> v1/ConfigMap +NAME DATA AGE +rude-cardinal-configmap 3 0s + + +NOTES: +Merci d'avoir installé mychart. + +Votre nom de release est rude-cardinal. + +Pour en savoir plus sur cette release, essayez : + + $ helm status rude-cardinal + $ helm get all rude-cardinal +``` + +Utiliser `NOTES.txt` de cette manière est un excellent moyen de fournir à vos utilisateurs des informations détaillées sur la façon d'utiliser leur chart nouvellement installé. La création d'un fichier `NOTES.txt` est fortement recommandée, bien qu'elle ne soit pas obligatoire. diff --git a/content/fr/docs/chart_template_guide/subcharts_and_globals.md b/content/fr/docs/chart_template_guide/subcharts_and_globals.md new file mode 100644 index 000000000..1bc41d16d --- /dev/null +++ b/content/fr/docs/chart_template_guide/subcharts_and_globals.md @@ -0,0 +1,206 @@ +--- +title: "Sous-charts et Valeurs Globales" +description: "Interaction avec les sous-charts et les valeurs globales" +weight: 11 +--- + +Jusqu'à présent, nous avons travaillé uniquement avec un chart. Cependant, les charts peuvent avoir des dépendances, appelées _sous-charts_, qui possèdent également leurs propres valeurs et modèles. Dans cette section, nous allons créer un sous-chart et examiner les différentes manières d'accéder aux valeurs depuis les modèles. + +Avant de plonger dans le code, il y a quelques détails importants à connaître concernant les sous-charts d'application. + +1. Un sous-chart est considéré comme "autonome", ce qui signifie qu'un sous-chart ne peut jamais dépendre explicitement de son chart parent. +2. Pour cette raison, un sous-chart ne peut pas accéder aux valeurs de son parent. +3. Un chart parent peut remplacer les valeurs des sous-charts. +4. Helm possède un concept de _valeurs globales_ qui peuvent être accessibles par tous les charts. + +> Ces limitations ne s'appliquent pas forcément à [library charts]({{< ref "/docs/topics/library_charts.md" >}}), qui sont conçus pour fournir des fonctionnalités d'assistance standardisées. + +Au fur et à mesure que nous parcourrons les exemples de cette section, beaucoup de ces concepts deviendront plus clairs. + +## Créer un sous-chart + +Pour ces exercices, nous commencerons avec le chart `mychart/` que nous avons créé au début de ce guide, et nous ajouterons un nouveau chart à l'intérieur de celui-ci. + +```console +$ cd mychart/charts +$ helm create mysubchart +Creating mysubchart +$ rm -rf mysubchart/templates/* +``` + +Remarquez que, comme précédemment, nous avons supprimé tous les modèles de base afin de repartir de zéro. Dans ce guide, nous nous concentrons sur le fonctionnement des modèles, et non sur la gestion des dépendances. Cependant, le [Guide des Charts]({{< ref "../topics/charts.md" >}}) contient plus d'informations sur le fonctionnement des sous-charts. + +## Ajouter des valeurs et un modèle au sous-chart + +Ensuite, créons un modèle simple et un fichier de valeurs pour notre chart `mysubchart`. Il devrait déjà y avoir un fichier `values.yaml` dans `mychart/charts/mysubchart`. Nous allons le configurer comme suit : + +```yaml +dessert: cake +``` + +Ensuite, nous allons créer un nouveau modèle de ConfigMap dans `mychart/charts/mysubchart/templates/configmap.yaml` : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-cfgmap2 +data: + dessert: {{ .Values.dessert }} +``` + +Parce que chaque sous-chart est un _chart autonome_, nous pouvons tester `mysubchart` seul : + +```console +$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart +SERVER: "localhost:44134" +CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart +NAME: newbie-elk +TARGET NAMESPACE: default +CHART: mysubchart 0.1.0 +MANIFEST: +--- +# Source: mysubchart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: newbie-elk-cfgmap2 +data: + dessert: cake +``` + +## Remplacer les valeurs d'un chart parent + +Notre chart d'origine, `mychart`, est maintenant le chart _parent_ de `mysubchart`. Cette relation est entièrement basée sur le fait que `mysubchart` se trouve dans `mychart/charts`. + +Puisque `mychart` est un parent, nous pouvons spécifier la configuration dans `mychart` et faire en sorte que cette configuration soit transmise à `mysubchart`. Par exemple, nous pouvons modifier `mychart/values.yaml` comme suit : + +```yaml +favorite: + drink: coffee + food: pizza +pizzaToppings: + - mushrooms + - cheese + - peppers + - onions + +mysubchart: + dessert: ice cream +``` + +Notez les deux dernières lignes. Toutes les directives à l'intérieur de la section `mysubchart` seront envoyées au chart `mysubchart`. Ainsi, si nous exécutons `helm install --generate-name --dry-run --debug mychart`, l'une des choses que nous verrons sera le ConfigMap de `mysubchart` : + +```yaml +# Source: mychart/charts/mysubchart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: unhinged-bee-cfgmap2 +data: + dessert: ice cream +``` + +La valeur au niveau supérieur a maintenant remplacé la valeur du sous-chart. + +Il y a un détail important à noter ici. Nous n'avons pas modifié le modèle de `mychart/charts/mysubchart/templates/configmap.yaml` pour pointer vers `.Values.mysubchart.dessert`. Du point de vue de ce modèle, la valeur se trouve toujours à `.Values.dessert`. À mesure que le moteur de modèle transmet les valeurs, il définit le contexte. Ainsi, pour les modèles de `mysubchart`, seules les valeurs spécifiquement pour `mysubchart` seront disponibles dans `.Values`. + +Parfois, cependant, vous souhaitez que certaines valeurs soient disponibles pour tous les modèles. Cela s'accomplit en utilisant des valeurs globales de chart. + +## Valeurs Globales de Chart + +Les valeurs globales sont des valeurs qui peuvent être accessibles depuis n'importe quel chart ou sous-chart sous le même nom. Les valeurs globales nécessitent une déclaration explicite. Vous ne pouvez pas utiliser un existant non-global comme s'il s'agissait d'un global. + +Le type de données Values a une section réservée appelée `Values.global` où les valeurs globales peuvent être définies. Définissons-en une dans notre fichier `mychart/values.yaml`. + +```yaml +favorite: + drink: coffee + food: pizza +pizzaToppings: + - mushrooms + - cheese + - peppers + - onions + +mysubchart: + dessert: ice cream + +global: + salad: caesar +``` + +En raison du fonctionnement des valeurs globales, tant `mychart/templates/configmap.yaml` que `mysubchart/templates/configmap.yaml` devraient pouvoir accéder à cette valeur sous la forme `{{ .Values.global.salad }}`. + +`mychart/templates/configmap.yaml`: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + salad: {{ .Values.global.salad }} +``` + +`mysubchart/templates/configmap.yaml`: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-cfgmap2 +data: + dessert: {{ .Values.dessert }} + salad: {{ .Values.global.salad }} +``` + +Maintenant, si nous exécutons une installation en mode dry run, nous verrons la même valeur dans les deux sorties : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: silly-snake-configmap +data: + salad: caesar + +--- +# Source: mychart/charts/mysubchart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: silly-snake-cfgmap2 +data: + dessert: ice cream + salad: caesar +``` + +Les valeurs globales sont utiles pour transmettre des informations de cette manière, bien qu'il faille un certain planification pour s'assurer que les bons modèles sont configurés pour utiliser les valeurs globales. + +## Partager des modèles avec des sous-charts + +Les charts parents et les sous-charts peuvent partager des modèles. Tout bloc défini dans un chart est disponible pour les autres charts. + +Par exemple, nous pouvons définir un modèle simple comme ceci : + +```yaml +{{- define "labels" }}from: mychart{{ end }} +``` + +Rappelez-vous comment les étiquettes sur les modèles sont _partagées globalement_. Ainsi, le chart `labels` peut être inclus depuis n'importe quel autre chart. + +Alors que les développeurs de charts ont le choix entre `include` et `template`, un avantage de l'utilisation de `include` est qu'il peut référencer dynamiquement des modèles : + +```yaml +{{ include $mytemplate }} +``` + +Ce qui précède désaffichera `$mytemplate`. La fonction `template`, en revanche, n'acceptera qu'une chaîne littérale. + +## Évitez d'utiliser des blocs + +Le langage de template Go fournit un mot-clé `block` qui permet aux développeurs de fournir une implémentation par défaut qui peut être remplacée ultérieurement. Dans les charts Helm, les blocs ne sont pas le meilleur outil pour le remplacement, car si plusieurs implémentations du même bloc sont fournies, celle qui est sélectionnée est imprévisible. + +La suggestion est d'utiliser plutôt `include`. diff --git a/content/fr/docs/chart_template_guide/values_files.md b/content/fr/docs/chart_template_guide/values_files.md new file mode 100644 index 000000000..84f512ad9 --- /dev/null +++ b/content/fr/docs/chart_template_guide/values_files.md @@ -0,0 +1,158 @@ +--- +title: "Fichiers de Valeurs" +description: "Instructions sur l'utilisation de l'argument --values" +weight: 4 +--- + +Dans la section précédente, nous avons examiné les objets intégrés que les modèles Helm offrent. L'un des objets intégrés est `Values`. Cet objet permet d'accéder aux valeurs passées au chart. Son contenu provient de plusieurs sources : + +- Le fichier `values.yaml` dans le chart +- Si c'est un sous-chart, le fichier `values.yaml` d'un chart parent +- Un fichier de valeurs est passé à `helm install` ou `helm upgrade` avec l'argument `-f` (`helm install -f myvals.yaml ./mychart`) +- Des paramètres individuels sont passés avec `--set` (comme `helm install --set foo=bar ./mychart`) + +La liste ci-dessus est par ordre de spécificité : `values.yaml` est la valeur par défaut, qui peut être remplacée par le `values.yaml` d'un chart parent, qui peut à son tour être remplacé par un fichier de valeurs fourni par l'utilisateur, qui peut à son tour être remplacé par des paramètres `--set`. + +Les fichiers de valeurs sont des fichiers YAML simples. Éditons `mychart/values.yaml` puis modifions notre modèle de ConfigMap. + +En supprimant les valeurs par défaut dans `values.yaml`, nous allons définir juste un paramètre : + +```yaml +favoriteDrink: coffee +``` + +Nous pouvons maintenant l'utiliser à l'intérieur d'un modèle : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favoriteDrink }} +``` + +Remarquez que sur la dernière ligne, nous accédons à `favoriteDrink` en tant qu'attribut de `Values` : `{{ .Values.favoriteDrink }}`. + +Voyons comment cela se rend. + +```console +$ helm install geared-marsupi ./mychart --dry-run --debug +install.go:158: [debug] Original chart version: "" +install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart + +NAME: geared-marsupi +LAST DEPLOYED: Wed Feb 19 23:21:13 2020 +NAMESPACE: default +STATUS: pending-install +REVISION: 1 +TEST SUITE: None +USER-SUPPLIED VALUES: +{} + +COMPUTED VALUES: +favoriteDrink: coffee + +HOOKS: +MANIFEST: +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: geared-marsupi-configmap +data: + myvalue: "Hello World" + drink: coffee +``` + +Puisque `favoriteDrink` est défini dans le fichier `values.yaml` par défaut sur `coffee`, c'est la valeur affichée dans le modèle. Nous pouvons facilement remplacer cela en ajoutant un argument `--set` dans notre appel à `helm install` : + +```console +$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm +install.go:158: [debug] Original chart version: "" +install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart + +NAME: solid-vulture +LAST DEPLOYED: Wed Feb 19 23:25:54 2020 +NAMESPACE: default +STATUS: pending-install +REVISION: 1 +TEST SUITE: None +USER-SUPPLIED VALUES: +favoriteDrink: slurm + +COMPUTED VALUES: +favoriteDrink: slurm + +HOOKS: +MANIFEST: +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: solid-vulture-configmap +data: + myvalue: "Hello World" + drink: slurm +``` + +Puisque `--set` a une priorité plus élevée que le fichier `values.yaml` par défaut, notre modèle génère `drink: slurm`. + +Les fichiers de valeurs peuvent également contenir un contenu plus structuré. Par exemple, nous pourrions créer une section `favorite` dans notre fichier `values.yaml`, puis y ajouter plusieurs clés : + +```yaml +favorite: + drink: coffee + food: pizza +``` + +Maintenant, nous devrions modifier légèrement le modèle : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink }} + food: {{ .Values.favorite.food }} +``` + +Bien que structurer les données de cette manière soit possible, il est recommandé de garder vos arbres de valeurs peu profonds, en favorisant la platitude. Lorsque nous examinerons l'attribution de valeurs aux sous-charts, nous verrons comment les valeurs sont nommées en utilisant une structure arborescente. + +## Supprimer une clé par défaut + +Si vous devez supprimer une clé des valeurs par défaut, vous pouvez remplacer la valeur de la clé par `null`, auquel cas Helm supprimera la clé de la fusion des valeurs remplacées. + +Par exemple, le chart stable de Drupal permet de configurer le probe de vivacité, au cas où vous configureriez une image personnalisée. Voici les valeurs par défaut : +```yaml +livenessProbe: + httpGet: + path: /user/login + port: http + initialDelaySeconds: 120 +``` + +Si vous essayez de remplacer le gestionnaire de livenessProbe par `exec` au lieu de `httpGet` en utilisant `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm va fusionner les clés par défaut et remplacées, ce qui donne le YAML suivant : +```yaml +livenessProbe: + httpGet: + path: /user/login + port: http + exec: + command: + - cat + - docroot/CHANGELOG.txt + initialDelaySeconds: 120 +``` + +Cependant, Kubernetes échouerait alors parce que vous ne pouvez pas déclarer plus d'un gestionnaire de livenessProbe. Pour contourner cela, vous pouvez indiquer à Helm de supprimer le `livenessProbe.httpGet` en le définissant sur null : +```sh +helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null +``` + +À ce stade, nous avons vu plusieurs objets intégrés et les avons utilisés pour injecter des informations dans un modèle. Maintenant, nous allons examiner un autre aspect du moteur de modèles : les fonctions et les pipelines. diff --git a/content/fr/docs/chart_template_guide/variables.md b/content/fr/docs/chart_template_guide/variables.md new file mode 100644 index 000000000..811bfd1d7 --- /dev/null +++ b/content/fr/docs/chart_template_guide/variables.md @@ -0,0 +1,132 @@ +--- +title: "Variables" +description: "Utilisation des variables dans les modèles" +weight: 8 +--- + +Avec les fonctions, pipelines, objets et structures de contrôle à notre disposition, nous pouvons aborder l'une des idées les plus basiques de nombreux langages de programmation : les variables. Dans les modèles, elles sont moins fréquemment utilisées. Cependant, nous verrons comment les utiliser pour simplifier le code et optimiser l'utilisation de `with` et `range`. + +Dans un exemple précédent, nous avons vu que ce code échouera : + +```yaml + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + release: {{ .Release.Name }} + {{- end }} +``` + +`Release.Name` n'est pas dans le scope restreint du bloc `with`. Une façon de contourner les problèmes de portée est d'assigner des objets à des variables qui peuvent être accessibles indépendamment du scope actuel. + +Dans les modèles Helm, une variable est une référence nommée à un autre objet. Elle suit la forme `$name`. Les variables sont assignées avec un opérateur d'affectation spécial : `:=`. Nous pouvons réécrire l'exemple ci-dessus en utilisant une variable pour `Release.Name`. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + {{- $relname := .Release.Name -}} + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + release: {{ $relname }} + {{- end }} +``` + +Remarquez qu'avant de commencer le bloc `with`, nous assignons `$relname := .Release.Name`. Maintenant, à l'intérieur du bloc `with`, la variable `$relname` pointe toujours vers le nom de la release. + +Running that will produce this: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: viable-badger-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" + release: viable-badger +``` + +Les variables sont particulièrement utiles dans les boucles `range`. Elles peuvent être utilisées sur des objets de type liste pour capturer à la fois l'index et la valeur : + +```yaml + toppings: |- + {{- range $index, $topping := .Values.pizzaToppings }} + {{ $index }}: {{ $topping }} + {{- end }} + +``` + +Notez que `range` vient en premier, puis les variables, ensuite l'opérateur d'affectation, et enfin la liste. Cela assignera l'index entier (à partir de zéro) à `$index` et la valeur à `$topping`. L'exécution de ce code produira : + +```yaml + toppings: |- + 0: mushrooms + 1: cheese + 2: peppers + 3: onions +``` + +Pour les structures de données qui ont à la fois une clé et une valeur, nous pouvons utiliser `range` pour obtenir les deux. Par exemple, nous pouvons boucler sur `.Values.favorite` comme ceci : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + {{- range $key, $val := .Values.favorite }} + {{ $key }}: {{ $val | quote }} + {{- end }} +``` + +Pour les structures de données qui ont à la fois une clé et une valeur, nous pouvons utiliser `range` pour obtenir les deux. Par exemple, nous pouvons boucler sur `.Values.favorite` comme ceci : + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: eager-rabbit-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "pizza" +``` + +Les variables ne sont généralement pas "globales". Elles sont limitées au bloc dans lequel elles sont déclarées. Plus tôt, nous avons assigné `$relname` au niveau supérieur du modèle. Cette variable sera accessible dans l'ensemble du modèle. Cependant, dans notre dernier exemple, `$key` et `$val` ne seront accessibles qu'à l'intérieur du bloc `{{ range... }}{{ end }}`. + +Cependant, il existe une variable qui est toujours globale - `$` - cette variable pointera toujours vers le contexte racine. Cela peut être très utile lorsque vous bouclez dans une plage et que vous avez besoin de connaître le nom de la release du chart. + +Un exemple illustrant cela : +```yaml +{{- range .Values.tlsSecrets }} +apiVersion: v1 +kind: Secret +metadata: + name: {{ .name }} + labels: + # De nombreux modèles Helm utiliseraient `.` ci-dessous, mais cela ne fonctionnera pas, + # cependant, `$` fonctionnera ici + app.kubernetes.io/name: {{ template "fullname" $ }} + # Je ne peux pas référencer .Chart.Name, mais je peux faire $.Chart.Name + helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" + app.kubernetes.io/instance: "{{ $.Release.Name }}" + # Valeur de appVersion dans Chart.yaml + app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" + app.kubernetes.io/managed-by: "{{ $.Release.Service }}" +type: kubernetes.io/tls +data: + tls.crt: {{ .certificate }} + tls.key: {{ .key }} +--- +{{- end }} +``` + +Jusqu'à présent, nous avons examiné un seul modèle déclaré dans un seul fichier. Mais l'une des fonctionnalités puissantes du langage de modèle Helm est sa capacité à déclarer plusieurs modèles et à les utiliser ensemble. Nous nous pencherons sur cela dans la prochaine section. diff --git a/content/fr/docs/chart_template_guide/wrapping_up.md b/content/fr/docs/chart_template_guide/wrapping_up.md new file mode 100644 index 000000000..d68a1b38e --- /dev/null +++ b/content/fr/docs/chart_template_guide/wrapping_up.md @@ -0,0 +1,26 @@ +--- +title: "Prochaines étapes" +description: "Conclusion - quelques conseils utiles vers d'autres documents qui vous aideront" +weight: 14 +--- + +Ce guide est destiné à vous, le développeur de charts, pour vous donner une solide compréhension de l'utilisation du langage de modèle de Helm. Le guide se concentre sur les aspects techniques du développement de modèles. + +Mais il y a de nombreuses choses que ce guide n'a pas abordées en ce qui concerne le développement pratique au quotidien des charts. Voici quelques conseils utiles vers d'autres documents qui vous aideront à créer de nouveaux charts : + +- L'[Artifact Hub](https://artifacthub.io/packages/search?kind=0) CNCF est une source indispensable de charts. +- La [Documentation Kubernetes](https://kubernetes.io/docs/home/) fournit des exemples détaillés des différents types de ressources que vous pouvez utiliser, des ConfigMaps et Secrets aux DaemonSets et Deployments. +- Le [Guide des Charts Helm](../../topics/charts/) explique le flux de travail d'utilisation des charts. +- Le [Guide des Hooks de Chart Helm](../../topics/charts_hooks/) explique comment créer des hooks de cycle de vie. +- L'article [Astuces et conseils pour les Charts Helm](../../howto/charts_tips_and_tricks/) fournit des conseils utiles pour écrire des charts. +- La [documentation Sprig](https://github.com/Masterminds/sprig) documente plus de soixante fonctions de modèle. +- La [doc des template Go](https://godoc.org/text/template) explique la syntaxe des modèles en détail. +- L'outil [Schelm](https://github.com/databus23/schelm) est un utilitaire d'aide agréable pour le débogage des charts. + +Parfois, il est plus facile de poser quelques questions et d'obtenir des réponses de développeurs expérimentés. Le meilleur endroit pour le faire est dans les canaux Helm du [Slack Kubernetes](https://kubernetes.slack.com) : + +- [#helm-users](https://kubernetes.slack.com/messages/helm-users) +- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) +- [#charts](https://kubernetes.slack.com/messages/charts) + +Enfin, si vous trouvez des erreurs ou des omissions dans ce document, souhaitez suggérer un nouveau contenu ou aimeriez contribuer, rendez-vous sur le [GitHub du Projet Helm](https://github.com/helm/helm-www). diff --git a/content/fr/docs/chart_template_guide/yaml_techniques.md b/content/fr/docs/chart_template_guide/yaml_techniques.md new file mode 100644 index 000000000..5db437183 --- /dev/null +++ b/content/fr/docs/chart_template_guide/yaml_techniques.md @@ -0,0 +1,295 @@ +--- +title: "Annexe : Techniques YAML" +description: "Un examen plus approfondi de la spécification YAML et de son application à Helm" +weight: 15 +--- + +La plupart de ce guide s'est concentrée sur l'écriture du langage de modèle. Ici, nous allons examiner le format YAML. YAML possède certaines fonctionnalités utiles que nous, en tant qu'auteurs de modèles, pouvons utiliser pour rendre nos modèles moins sujets aux erreurs et plus faciles à lire. + +## Scalaires et Collections + +Selon la [spécification YAML](https://yaml.org/spec/1.2/spec.html), il existe deux types de collections et de nombreux types scalaires. + +Les deux types de collections sont les maps et les séquences : + +```yaml +map: + one: 1 + two: 2 + three: 3 + +sequence: + - one + - two + - three +``` + +Les valeurs scalaires sont des valeurs individuelles (par opposition aux collections). + +### Types Scalaires en YAML + +Dans le dialecte YAML de Helm, le type de données scalaire d'une valeur est déterminé par un ensemble complexe de règles, y compris le schéma Kubernetes pour les définitions de ressources. Mais lors de l'inférence des types, les règles suivantes tendent à être vraies. + +Si un entier ou un flottant est non cité, il est généralement traité comme un type numérique : + +```yaml +count: 1 +size: 2.34 +``` + +Mais s'ils sont cités, ils sont traités comme des chaînes de caractères : + +```yaml +count: "1" # <-- chaîne, pas un entier +size: '2.34' # <-- chaîne, pas un floattant +``` + +Il en va de même pour les booléens : + +```yaml +isGood: true # booléen +answer: "true" # chaîne +``` + +Le mot pour une valeur vide est `null` (et non `nil`). + +Notez que `port: "80"` est un YAML valide et passera à travers à la fois le moteur de modèles et le parseur YAML, mais échouera si Kubernetes s'attend à ce que `port` soit un entier. + +Dans certains cas, vous pouvez forcer une inférence de type particulière en utilisant des tags de nœud YAML : + +```yaml +coffee: "yes, please" +age: !!str 21 +port: !!int "80" +``` + +Dans ce qui précède, `!!str` indique au parseur que `age` est une chaîne, même s'il ressemble à un entier. Et `port` est traité comme un entier, même s'il est cité. + + +## Les Chaînes en YAML + +Une grande partie des données que nous plaçons dans les documents YAML sont des chaînes. YAML a plus d'une manière de représenter une chaîne. Cette section explique les différentes façons et démontre comment les utiliser. + +Il existe trois manières "en ligne" de déclarer une chaîne : + +```yaml +way1: bare words +way2: "double-quoted strings" +way3: 'single-quoted strings' +``` + +Tous les styles en ligne doivent être sur une seule ligne. + +- Les mots non cités ne sont pas entre guillemets et ne sont pas échappés. Pour cette raison, vous devez faire attention aux caractères que vous utilisez. +- Les chaînes entre guillemets doubles peuvent avoir des caractères spécifiques échappés avec `\`. Par exemple, `"\"Bonjour\", a-t-elle dit"`. Vous pouvez échapper les retours à la ligne avec `\n`. +- Les chaînes entre guillemets simples sont des chaînes "littérales" et n'utilisent pas le `\` pour échapper les caractères. La seule séquence d'échappement est `''`, qui est décodée comme un seul `'`. + +En plus des chaînes sur une seule ligne, vous pouvez déclarer des chaînes multilignes : + +```yaml +coffee: | + Latte + Cappuccino + Espresso +``` + +Cela traitera la valeur de `coffee` comme une seule chaîne équivalente à `Latte\nCappuccino\nEspresso\n`. + +Notez que la première ligne après le `|` doit être correctement indentée. Donc, nous pourrions casser l'exemple ci-dessus en procédant ainsi : + +```yaml +coffee: | + Latte + Cappuccino + Espresso + +``` + +Parce que `Latte` est mal indenté, nous obtiendrions une erreur comme ceci : + +``` +Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key +``` + +Dans les modèles, il est parfois plus sûr d'inclure une "première ligne" fictive de contenu dans un document multi-lignes juste pour se protéger contre l'erreur ci-dessus : + +```yaml +coffee: | + # Commented first line + Latte + Cappuccino + Espresso + +``` + +Notez que quelle que soit cette première ligne, elle sera préservée dans la sortie de la chaîne. Ainsi, si vous utilisez cette technique pour injecter le contenu d'un fichier dans un ConfigMap, le commentaire doit être du type attendu par le lecteur de cette entrée. + +### Contrôle des Espaces dans les Chaînes Multi-Lignes + +Dans l'exemple ci-dessus, nous avons utilisé `|` pour indiquer une chaîne multi-lignes. Mais notez que le contenu de notre chaîne était suivi d'un `\n` à la fin. Si nous voulons que le processeur YAML supprime le saut de ligne à la fin, nous pouvons ajouter un `-` après le `|` : + +```yaml +coffee: |- + Latte + Cappuccino + Espresso +``` + +Maintenant, la valeur de `coffee` sera : `Latte\nCappuccino\nEspresso` (sans le saut de ligne final `\n`). + +D'autres fois, nous pourrions vouloir que tous les espaces blancs à la fin soient préservés. Nous pouvons le faire avec la notation `|+` : + +```yaml +coffee: |+ + Latte + Cappuccino + Espresso + + +another: value +``` + +Maintenant, la valeur de `coffee` sera `Latte\nCappuccino\nEspresso\n\n\n`. + +L'indentation à l'intérieur d'un bloc de texte est préservée, ce qui entraîne également la préservation des sauts de ligne. + +```yaml +coffee: |- + Latte + 12 oz + 16 oz + Cappuccino + Espresso +``` + +Dans le cas ci-dessus, `coffee` sera `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. + +### Indentation et Templates + +Lors de l'écriture de templates, vous pourriez vouloir injecter le contenu d'un fichier dans le template. Comme nous l'avons vu dans les chapitres précédents, il existe deux façons de le faire : + +- Utilisez `{{ .Files.Get "NOM_DU_FICHIER" }}` pour obtenir le contenu d'un fichier dans le chart. +- Utilisez `{{ include "TEMPLATE" . }}` pour rendre un template et ensuite placer son contenu dans le chart. + +Lors de l'insertion de fichiers dans du YAML, il est bon de comprendre les règles des chaînes multi-lignes mentionnées ci-dessus. Souvent, la manière la plus simple d'insérer un fichier statique est de faire quelque chose comme ceci : + +```yaml +myfile: | +{{ .Files.Get "myfile.txt" | indent 2 }} +``` + +Notez comment nous effectuons l'indentation ci-dessus : `indent 2` indique au moteur de template d'indiquer chaque ligne de "myfile.txt" avec deux espaces. Remarquez que nous n'indiquons pas cette ligne de template. Si nous le faisions, le contenu du fichier de la première ligne serait indenté deux fois. + +### Chaînes multi-lignes pliées + +Parfois, vous souhaitez représenter une chaîne dans votre YAML avec plusieurs lignes, mais vous voulez qu'elle soit traitée comme une longue ligne lorsqu'elle est interprétée. Cela s'appelle le "pliage". Pour déclarer un bloc plié, utilisez `>` au lieu de `|` : + +```yaml +coffee: > + Latte + Cappuccino + Espresso + + +``` + +La valeur de `coffee` ci-dessus sera `Latte Cappuccino Espresso\n`. Notez que toutes les nouvelles lignes sauf la dernière seront converties en espaces. Vous pouvez combiner les contrôles d'espacement avec le marqueur de texte plié, donc `>-` remplacera ou supprimera toutes les nouvelles lignes. + +Notez qu'avec la syntaxe pliée, l'indentation du texte entraînera la préservation des lignes. + +```yaml +coffee: >- + Latte + 12 oz + 16 oz + Cappuccino + Espresso +``` + +Ce qui précède produira `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Notez que les espaces et les sauts de ligne sont toujours présents. + +## Incorporer Plusieurs Documents dans un Seul Fichier. + +Il est possible d'insérer plus d'un document YAML dans un seul fichier. Cela se fait en préfixant un nouveau document avec `---` et en terminant le document par `...`. + +```yaml + +--- +document: 1 +... +--- +document: 2 +... +``` + +Dans de nombreux cas, il est possible d'omettre soit le `---`, soit le `...`. + +Certains fichiers dans Helm ne peuvent pas contenir plus d'un document. Par exemple, si plusieurs documents sont fournis dans un fichier `values.yaml`, seul le premier sera utilisé. + +Les fichiers de modèle, en revanche, peuvent contenir plus d'un document. Dans ce cas, le fichier (et tous ses documents) est traité comme un seul objet lors du rendu du modèle. Cependant, le YAML résultant est ensuite divisé en plusieurs documents avant d'être transmis à Kubernetes. + +Nous recommandons d'utiliser plusieurs documents par fichier uniquement lorsque cela est absolument nécessaire. Avoir plusieurs documents dans un fichier peut rendre le débogage difficile. + +## YAML est un sur-ensemble de JSON. + +Parce que YAML est un sur-ensemble de JSON, tout document JSON valide _devrait_ être un YAML valide. + +```json +{ + "coffee": "yes, please", + "coffees": [ + "Latte", "Cappuccino", "Espresso" + ] +} +``` + +Ce qui précède est une autre façon de représenter cela : + +```yaml +coffee: yes, please +coffees: +- Latte +- Cappuccino +- Espresso +``` + +Et les deux peuvent être mélangés (avec précaution) : + +```yaml +coffee: "yes, please" +coffees: [ "Latte", "Cappuccino", "Espresso"] +``` + +Ces trois éléments devraient tous être analysés en la même représentation interne. + +Bien que cela signifie que des fichiers tels que `values.yaml` puissent contenir des données JSON, Helm ne considère pas l'extension de fichier `.json` comme un suffixe valide. + +## Ancrages YAML + +La spécification YAML fournit un moyen de stocker une référence à une valeur, puis de faire référence à cette valeur par référence. YAML appelle cela "ancrage" : + +```yaml +coffee: "yes, please" +favorite: &favoriteCoffee "Cappuccino" +coffees: + - Latte + - *favoriteCoffee + - Espresso +``` + +Dans ce qui précède, `&favoriteCoffee` définit une référence à `Cappuccino`. Plus tard, cette référence est utilisée sous la forme `*favoriteCoffee`. Ainsi, `coffees` devient `Latte, Cappuccino, Espresso`. + +Bien qu'il existe quelques cas où les ancrages sont utiles, il y a un aspect qui peut causer des bogues subtils : la première fois que le YAML est consommé, la référence est développée puis rejetée. + +Ainsi, si nous devions décoder puis réencoder l'exemple ci-dessus, le YAML résultant serait : + +```yaml +coffee: yes, please +favorite: Cappuccino +coffees: +- Latte +- Cappuccino +- Espresso +``` + +Parce que Helm et Kubernetes lisent souvent, modifient puis réécrivent des fichiers YAML, les ancrages seront perdus. \ No newline at end of file From 720ddb40d5b35dbd1fba2ccddf895d251a704e4c Mon Sep 17 00:00:00 2001 From: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Fri, 27 Sep 2024 22:56:42 +0200 Subject: [PATCH 08/15] Update content/fr/docs/community/history.md Signed-off-by: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- content/fr/docs/community/history.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/fr/docs/community/history.md b/content/fr/docs/community/history.md index 89ed27b53..435487597 100644 --- a/content/fr/docs/community/history.md +++ b/content/fr/docs/community/history.md @@ -4,7 +4,7 @@ description: "Fournit un aperçu général de l'historique du projet." weight: 4 --- -Helm est un [projet de la CNCF](https://www.cncf.io/projects/), qui a été [récompensé](https://helm.sh/blog/celebrating-helms-cncf-graduation/). +Helm est un [projet récompensé](https://helm.sh/blog/celebrating-helms-cncf-graduation/) par la [CNCF](https://www.cncf.io/projects/). Helm a commencé sous ce qui est maintenant connu sous le nom de [Helm Classic](https://github.com/helm/helm-classic), un projet Deis lancé en 2015 et présenté lors de la première KubeCon. From 9f8f890921872515bef1bf28b0ca34138e5e1ba6 Mon Sep 17 00:00:00 2001 From: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Fri, 27 Sep 2024 23:03:59 +0200 Subject: [PATCH 09/15] Remove additional information not officially present Signed-off-by: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- content/fr/docs/chart_best_practices/rbac.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/content/fr/docs/chart_best_practices/rbac.md b/content/fr/docs/chart_best_practices/rbac.md index 9e3c5fc57..71904f8f7 100644 --- a/content/fr/docs/chart_best_practices/rbac.md +++ b/content/fr/docs/chart_best_practices/rbac.md @@ -58,7 +58,7 @@ Le modèle d'aide suivant devrait être utilisé pour le ServiceAccount : ```yaml {{/* -Create the name of the service account to use +Créer le nom du compte de service à utiliser */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} @@ -68,7 +68,3 @@ Create the name of the service account to use {{- end -}} {{- end -}} ``` - -À l'heure actuelle, Helm ne dispose pas de mécanisme permettant d'extraire les RBAC nécessaire pour l'installation, la mise à jour et la désinstallation des charts. Ce qui est contraignant, si l'opérateur exécutant ces commandes Helm, n'a pas les droits admin sur le cluster Kubernetes ou des droits inférieurs à ceux présents dans les charts, cela peut faire remonté des erreurs. Pour ce faire, vous devrez lister manuellement tous les rôles présent dans les ressources RBAC des charts, en plus des rôles de `create`, `list`, `read`, `update`, ... obligatoire pour manipuler vos ressources. Ensuite attribuez ces rôles à l'opérateur pour qu'il puisse disposer au minimum de droit équivalent ou supérieur à ceux du chart. - -Note : Certain chart trouvable sur l'ArtifactHub n'ont pas été conçus pour être déployé avec des droits restreints (mais avec tous les droits `*`). Il se peut que vous devrez les modifier. From f731901d3f231f533acec19e72efdb0d9d30e8c2 Mon Sep 17 00:00:00 2001 From: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Sat, 28 Sep 2024 01:26:15 +0200 Subject: [PATCH 10/15] Relink links ref Signed-off-by: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- content/fr/docs/_index.md | 2 +- .../docs/chart_best_practices/dependencies.md | 2 +- .../chart_template_guide/accessing_files.md | 4 +- .../chart_template_guide/builtin_objects.md | 5 +- .../control_structures.md | 2 +- .../chart_template_guide/function_list.md | 64 +++++++++---------- .../chart_template_guide/getting_started.md | 2 +- .../chart_template_guide/named_templates.md | 2 +- .../subcharts_and_globals.md | 2 +- content/fr/docs/community/localization.md | 2 +- content/fr/docs/faq/changes_since_helm2.md | 8 +-- content/fr/docs/faq/troubleshooting.md | 2 +- content/fr/docs/helm/helm_init.md | 2 +- .../howto/chart_repository_sync_example.md | 4 +- content/fr/docs/intro/install.md | 4 +- content/fr/docs/intro/quickstart.md | 2 +- content/fr/docs/intro/using_helm.md | 8 +-- content/fr/docs/topics/chart_repository.md | 4 +- content/fr/docs/topics/chart_tests.md | 4 +- content/fr/docs/topics/charts.md | 12 ++-- content/fr/docs/topics/charts_hooks.md | 2 +- content/fr/docs/topics/kubernetes_apis.md | 2 +- content/fr/docs/topics/library_charts.md | 2 +- content/fr/docs/topics/plugins.md | 8 +-- content/fr/docs/topics/provenance.md | 2 +- content/fr/docs/topics/registries.md | 2 +- content/fr/docs/topics/version_skew.md | 2 +- 27 files changed, 79 insertions(+), 78 deletions(-) diff --git a/content/fr/docs/_index.md b/content/fr/docs/_index.md index 31a099e1b..b7b2bdfa9 100644 --- a/content/fr/docs/_index.md +++ b/content/fr/docs/_index.md @@ -5,7 +5,7 @@ description: "Tout ce que vous devez savoir sur l'organisation de la documentati # Bienvenue -Bienvenue dans la documentation de [Helm](https://helm.sh/). Helm est le manageur de paquet pour Kubernetes. Les informations générales détaillées sont disponnibles ici : [CNCF Helm Project Journey report](https://www.cncf.io/cncf-helm-project-journey/). +Bienvenue dans la documentation de [Helm](https://helm.sh/). Helm est le manageur de paquet pour Kubernetes. Les informations générales détaillées sont disponibles ici : [CNCF Helm Project Journey report](https://www.cncf.io/cncf-helm-project-journey/). # Comment la documentation est organisée diff --git a/content/fr/docs/chart_best_practices/dependencies.md b/content/fr/docs/chart_best_practices/dependencies.md index b77e43857..bca05e65c 100644 --- a/content/fr/docs/chart_best_practices/dependencies.md +++ b/content/fr/docs/chart_best_practices/dependencies.md @@ -34,7 +34,7 @@ Si le dépôt a été ajouté au fichier d'index des dépôts, le nom du dépôt Les URLs de type `file://...` sont considérées comme un "cas spécial" pour les charts qui sont assemblés par un pipeline de déploiement fixe. -Lorsque vous utilisez des [plugins de téléchargement](), le schéma de l'URL sera spécifique au plugin. Notez qu'un utilisateur du chart devra avoir un plugin prenant en charge le schéma installé pour mettre à jour ou construire la dépendance. +Lorsque vous utilisez des [plugins de téléchargement]({{< ref "../topics/plugins#plugins-de-téléchargement" >}}), le schéma de l'URL sera spécifique au plugin. Notez qu'un utilisateur du chart devra avoir un plugin prenant en charge le schéma installé pour mettre à jour ou construire la dépendance. Helm ne peut pas effectuer d'opérations de gestion des dépendances sur la dépendance lorsque le champ `repository` est laissé vide. Dans ce cas, Helm supposera que la dépendance se trouve dans un sous-répertoire du dossier `charts`, avec un nom identique à la propriété `name` de la dépendance. diff --git a/content/fr/docs/chart_template_guide/accessing_files.md b/content/fr/docs/chart_template_guide/accessing_files.md index 8515837de..027edacf2 100644 --- a/content/fr/docs/chart_template_guide/accessing_files.md +++ b/content/fr/docs/chart_template_guide/accessing_files.md @@ -23,8 +23,8 @@ Helm permet d'accéder aux fichiers via l'objet `.Files`. Avant de commencer ave - [Aides pour les chemins](#aides-pour-les-chemins) - [Modèles Glob](#modèles-glob) - [Fonctions utilitaires pour ConfigMap et Secrets](#fonctions-utilitaires-pour-configmap-et-secrets) -- [Encoding](#encoding) -- [Lines](#lines) +- [Encodage](#encodage) +- [Lignes](#lignes) diff --git a/content/fr/docs/chart_template_guide/builtin_objects.md b/content/fr/docs/chart_template_guide/builtin_objects.md index e63993c91..3147dab09 100644 --- a/content/fr/docs/chart_template_guide/builtin_objects.md +++ b/content/fr/docs/chart_template_guide/builtin_objects.md @@ -19,9 +19,10 @@ Dans la section précédente, nous avons utilisé `{{ .Release.Name }}` pour ins - `Release.Service` : Le service qui rend le template en cours. Avec Helm, c'est toujours `Helm`. - `Values` : Valeurs passées dans le template depuis le fichier `values.yaml` et les fichiers fournis par l'utilisateur. Par défaut, `Values` est vide. - `Chart` : Contenu du fichier `Chart.yaml`. Toutes les données de ce fichier sont accessibles ici. Par exemple, `{{ .Chart.Name }}-{{ .Chart.Version }}` affichera `mychart-0.1.0`. - - Les champs disponibles sont listés dans le [Guide des Charts]({{}}). + - Les champs disponibles sont listés dans le [Guide des Charts]({{< ref + "/docs/topics/charts.md#le-fichier-chartyaml" >}}). - `Subcharts` : Donne accès à la portée (.Values, .Charts, .Releases, etc.) des sous-charts du parent. Par exemple, `.Subcharts.mySubChart.myValue` permet d'accéder à `myValue` dans le chart `mySubChart`. -- `Files` : Permet d'accéder à tous les fichiers non-spéciaux d'un chart, mais pas aux templates. +- `Files` : Permet d'accéder à tous les fichiers non-spéciaux d'un chart, mais pas aux templates. Consultez la section [Accéder aux fichiers]({{< ref "/docs/chart_template_guide/accessing_files" >}}) pour en savoir plus. - `Files.Get` permet d'obtenir un fichier par son nom (`.Files.Get config.ini`). - `Files.GetBytes` retourne le contenu du fichier sous forme de tableau d'octets au lieu d'une chaîne. Utile pour des fichiers comme des images. - `Files.Glob` retourne une liste de fichiers dont les noms correspondent au pattern glob donné. diff --git a/content/fr/docs/chart_template_guide/control_structures.md b/content/fr/docs/chart_template_guide/control_structures.md index b24bb9dc8..cd96e80bf 100644 --- a/content/fr/docs/chart_template_guide/control_structures.md +++ b/content/fr/docs/chart_template_guide/control_structures.md @@ -16,7 +16,7 @@ En plus de cela, il fournit quelques actions pour déclarer et utiliser des segm - `template` importe un modèle nommé - `block` déclare une sorte de zone de modèle remplissable spéciale -Dans cette section, nous parlerons de `if`, `with` et `range`. Les autres sont abordées dans la section [Modèles nommés]({{}}) plus loin dans ce guide. +Dans cette section, nous parlerons de `if`, `with` et `range`. Les autres sont abordées dans la section [Modèles nommés](named_templates.md) plus loin dans ce guide. ## If/Else diff --git a/content/fr/docs/chart_template_guide/function_list.md b/content/fr/docs/chart_template_guide/function_list.md index 2ca7be82b..f8bcd406f 100644 --- a/content/fr/docs/chart_template_guide/function_list.md +++ b/content/fr/docs/chart_template_guide/function_list.md @@ -6,24 +6,24 @@ weight: 6 Helm comprend de nombreuses fonctions de modèle que vous pouvez utiliser dans les modèles. Elles sont listées ici et classées par les catégories suivantes : -* [Cryptographic and Security](#cryptographic-and-security-functions) -* [Date](#date-functions) -* [Dictionaries](#dictionaries-and-dict-functions) -* [Encoding](#encoding-functions) -* [File Path](#file-path-functions) -* [Kubernetes and Chart](#kubernetes-and-chart-functions) -* [Logic and Flow Control](#logic-and-flow-control-functions) -* [Lists](#lists-and-list-functions) -* [Math](#math-functions) -* [Float Math](#float-math-functions) -* [Network](#network-functions) -* [Reflection](#reflection-functions) -* [Regular Expressions](#regular-expressions) -* [Semantic Versions](#semantic-version-functions) +* [Cryptographiques et Sécurité](#fonctions-cryptographiques-et-de-sécurité) +* [Date](#fonctions-de-date) +* [Dictionnaires](#dictionnaires-et-fonctions-de-dictionnaire) +* [Encodage](#fonctions-dencodage) +* [Chemin de Fichier](#fonctions-de-chemin-de-fichier) +* [Kubernetes et Charts](#kubernetes-et-fonctions-de-charts) +* [Logique et de Contrôle de Flux.](#fonctions-de-logique-et-de-contrôle-de-flux) +* [Listes](#listes-et-fonctions-de-liste) +* [Mathématiques](#fonctions-mathématiques) +* [Flottant en Mathématique](#fonctions-mathématiques-pour-les-nombres-à-virgule-flottante) +* [Réseau](#fonctions-réseau) +* [Réflexion](#fonctions-de-réflexion) +* [Expressions régulières](#expressions-régulières) +* [Version Sémantique](#fonctions-de-version-sémantique) * [String](#string-functions) -* [Type Conversion](#type-conversion-functions) -* [URL](#url-functions) -* [UUID](#uuid-functions) +* [Conversion de Type](#fonctions-de-conversion-de-type) +* [URL](#fonctions-durl) +* [UUID](#fonctions-uuid) ## Fonctions de logique et de contrôle de flux. @@ -207,17 +207,17 @@ Ce qui précède renvoie `"bar"`. Helm comprend les fonctions de chaîne suivantes : [abbrev](#abbrev), [abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), -[contains](#contains), [hasPrefix](#hasprefix-and-hassuffix), -[hasSuffix](#hasprefix-and-hassuffix), [indent](#indent), [initials](#initials), +[contains](#contains), [hasPrefix](#hasprefix-et-hassuffix), +[hasSuffix](#hasprefix-et-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), -[println](#println), [quote](#quote-and-squote), -[randAlpha](#randalphanum-randalpha-randnumeric-and-randascii), -[randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii), -[randAscii](#randalphanum-randalpha-randnumeric-and-randascii), -[randNumeric](#randalphanum-randalpha-randnumeric-and-randascii), +[println](#println), [quote](#quote-et-squote), +[randAlpha](#randalphanum-randalpha-randnumeric-et-randascii), +[randAlphaNum](#randalphanum-randalpha-randnumeric-et-randascii), +[randAscii](#randalphanum-randalpha-randnumeric-et-randascii), +[randNumeric](#randalphanum-randalpha-randnumeric-et-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), -[snakecase](#snakecase), [squote](#quote-and-squote), [substr](#substr), +[snakecase](#snakecase), [squote](#quote-et-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap) et [wrapWith](#wrapwith). @@ -515,7 +515,7 @@ hasPrefix "cat" "catch" Ce qui précède renvoie `true` car `catch` a le préfixe `cat`. -### quote and squote +### quote et squote Ces fonctions enveloppent une chaîne entre des guillemets doubles (`quote`) ou des guillemets simples (`squote`). @@ -1788,7 +1788,7 @@ Renvoie une valeur à virgule flottante avec le reste arrondi au nombre donné d `round 123.555555 3` renverra `123.556`. -## Fonctions Réseaux +## Fonctions Réseau Helm dispose d'une seule fonction réseau, `getHostByName`. @@ -1846,7 +1846,7 @@ Go possède plusieurs _kinds_ primitifs, comme `string`, `slice`, `int64`, et `b Go possède un système de _types_ ouvert qui permet aux développeurs de créer leurs propres types. -Helm fournit un ensemble de fonctions pour chaque via [fonctions de kind](#kind-functions) et [fonctions de type](#type-functions). Une fonction [deepEqual](#deepequal) est également fournie pour comparer deux valeurs. +Helm fournit un ensemble de fonctions pour chaque via [fonctions de kind](#fonctions-de-kind) et [fonctions de type](#functions-de-type). Une fonction [deepEqual](#deepequal) est également fournie pour comparer deux valeurs. ### Fonctions de Kind @@ -2063,13 +2063,13 @@ L'exemple 'ci-dessus renverra un nouvel UUID de type v4 (généré de manière a Helm inclut des fonctions pour travailler avec Kubernetes, y compris [.Capabilities.APIVersions.Has](#capabilitiesapiversionshas), -[Files](#file-functions) et [lookup](#lookup). +[Fichiers](#fonctions-de-fichiers) et [lookup](#lookup). ### lookup `lookup` est utilisé pour rechercher des ressources dans un cluster en cours d'exécution. Lorsqu'il est utilisé avec la commande `helm template`, il renvoie toujours une réponse vide. -Vous pouvez trouver plus de détails dans la [documentation sur la fonction lookup]({{}}). +Vous pouvez trouver plus de détails dans la [documentation sur la fonction lookup](functions_and_pipelines.md/#utilisation-de-la-fonction-lookup). ### .Capabilities.APIVersions.Has @@ -2080,10 +2080,10 @@ Renvoie si une version d'API ou une ressource est disponible dans un cluster. .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` -Plus d'informations sont disponibles sur le [built-in objects]({{}}). +Plus d'informations sont disponibles sur le [built-in objects](builtin_objects.md). ### Fonctions de Fichiers -Il existe plusieurs fonctions qui vous permettent d'accéder à des fichiers non spéciaux dans un chart. Par exemple, pour accéder aux fichiers de configuration de l'application. Ces fonctions sont documentées dans [Accéder aux fichiers à l'intérieur des modèles]({{}}). +Il existe plusieurs fonctions qui vous permettent d'accéder à des fichiers non spéciaux dans un chart. Par exemple, pour accéder aux fichiers de configuration de l'application. Ces fonctions sont documentées dans [Accéder aux fichiers à l'intérieur des modèles](accessing_files.md). _Remarque : la documentation pour beaucoup de ces fonctions provient de [Sprig](https://github.com/Masterminds/sprig). Sprig est une bibliothèque de fonctions de modèle disponible pour les applications Go._ diff --git a/content/fr/docs/chart_template_guide/getting_started.md b/content/fr/docs/chart_template_guide/getting_started.md index 3d46d5977..54ec295de 100644 --- a/content/fr/docs/chart_template_guide/getting_started.md +++ b/content/fr/docs/chart_template_guide/getting_started.md @@ -213,4 +213,4 @@ data: L'utilisation de `--dry-run` facilitera le test de votre code, mais cela ne garantira pas que Kubernetes acceptera les modèles que vous générez. Il est préférable de ne pas supposer que votre graphique s'installera simplement parce que `--dry-run` fonctionne. -Dans le [Guide des modèles de graphiques](content/en/docs/chart_template_guide/_index.md), nous prendrons le graphique de base que nous avons défini ici et explorerons en détail le langage de modèle Helm. Nous commencerons par les objets intégrés. +Dans le [Guide des modèles de graphiques](_index.md), nous prendrons le graphique de base que nous avons défini ici et explorerons en détail le langage de modèle Helm. Nous commencerons par les objets intégrés. diff --git a/content/fr/docs/chart_template_guide/named_templates.md b/content/fr/docs/chart_template_guide/named_templates.md index febcc4963..616b6327c 100644 --- a/content/fr/docs/chart_template_guide/named_templates.md +++ b/content/fr/docs/chart_template_guide/named_templates.md @@ -6,7 +6,7 @@ weight: 9 Il est temps de passer au-delà d'un seul template et de commencer à en créer d'autres. Dans cette section, nous verrons comment définir des _templates nommés_ dans un fichier, puis les utiliser ailleurs. Un _template nommé_ (parfois appelé _partiel_ ou _sous-template_) est simplement un template défini à l'intérieur d'un fichier et auquel on donne un nom. Nous verrons deux façons de les créer et quelques façons différentes de les utiliser. -Dans la section [Contrôle de flux](content/en/docs/chart_template_guide/control_structures.md), nous avons présenté trois actions pour déclarer et gérer des templates : `define`, `template` et `block`. Dans cette section, nous aborderons ces trois actions, et nous introduirons également une fonction à usage spécial `include` qui fonctionne de manière similaire à l'action `template`. +Dans la section [Contrôle de flux]({{< ref "/docs/chart_template_guide/control_structures.md">}}) , nous avons présenté trois actions pour déclarer et gérer des templates : `define`, `template` et `block`. Dans cette section, nous aborderons ces trois actions, et nous introduirons également une fonction à usage spécial `include` qui fonctionne de manière similaire à l'action `template`. Un détail important à garder à l'esprit lors de la nomination des templates : **les noms des templates sont globaux**. Si vous déclarez deux templates avec le même nom, celui qui est chargé en dernier sera celui utilisé. Étant donné que les templates dans les sous-charts sont compilés avec les templates de niveau supérieur, vous devez faire attention à nommer vos templates avec des _noms spécifiques au chart_. diff --git a/content/fr/docs/chart_template_guide/subcharts_and_globals.md b/content/fr/docs/chart_template_guide/subcharts_and_globals.md index 1bc41d16d..7795d9c42 100644 --- a/content/fr/docs/chart_template_guide/subcharts_and_globals.md +++ b/content/fr/docs/chart_template_guide/subcharts_and_globals.md @@ -13,7 +13,7 @@ Avant de plonger dans le code, il y a quelques détails importants à connaître 3. Un chart parent peut remplacer les valeurs des sous-charts. 4. Helm possède un concept de _valeurs globales_ qui peuvent être accessibles par tous les charts. -> Ces limitations ne s'appliquent pas forcément à [library charts]({{< ref "/docs/topics/library_charts.md" >}}), qui sont conçus pour fournir des fonctionnalités d'assistance standardisées. +> Ces limitations ne s'appliquent pas forcément aux [charts librairies]({{< ref "/docs/topics/library_charts.md" >}}), qui sont conçus pour fournir des fonctionnalités d'assistance standardisées. Au fur et à mesure que nous parcourrons les exemples de cette section, beaucoup de ces concepts deviendront plus clairs. diff --git a/content/fr/docs/community/localization.md b/content/fr/docs/community/localization.md index 5a5e4490b..5bff81e9c 100644 --- a/content/fr/docs/community/localization.md +++ b/content/fr/docs/community/localization.md @@ -73,7 +73,7 @@ AM](https://user-images.githubusercontent.com/686194/81597103-035de600-937a-11ea Le fichier de configuration global du site, [`config.toml`](https://github.com/helm/helm-www/blob/main/config.toml#L83L89), est l'endroit où la navigation entre les langues est configurée. -Pour ajouter une nouvelle langue, ajoutez un nouvel ensemble de paramètres en utilisant le [code de langue à deux lettres](./localization/#two-letter-language-code) défini ci-dessus. Exemple : +Pour ajouter une nouvelle langue, ajoutez un nouvel ensemble de paramètres en utilisant le [code de langue à deux lettres](./localization/#code-de-la-langue-à-2-lettres) défini ci-dessus. Exemple : ``` # Korean diff --git a/content/fr/docs/faq/changes_since_helm2.md b/content/fr/docs/faq/changes_since_helm2.md index 505d00fb8..52583ebff 100644 --- a/content/fr/docs/faq/changes_since_helm2.md +++ b/content/fr/docs/faq/changes_since_helm2.md @@ -119,7 +119,7 @@ Avec ce meilleur alignement aux espaces de noms natifs du cluster, la commande ` ### Secret comme pilote de stockage par défaut -Dans Helm 3, les Secrets sont désormais utilisés comme [pilote de stockage par défaut](/docs/topics/advanced/#storage-backends). Helm 2 utilisait des ConfigMaps par défaut pour stocker les informations de release. Dans Helm 2.7.0, un nouveau backend de stockage utilisant des Secrets pour conserver les informations de release a été implémenté, et il est désormais le pilote de stockage par défaut à partir de Helm 3. +Dans Helm 3, les Secrets sont désormais utilisés comme [pilote de stockage par défaut]({{< ref "/docs/topics/advanced.md#stockage-des-backends" >}}). Helm 2 utilisait des ConfigMaps par défaut pour stocker les informations de release. Dans Helm 2.7.0, un nouveau backend de stockage utilisant des Secrets pour conserver les informations de release a été implémenté, et il est désormais le pilote de stockage par défaut à partir de Helm 3. Le passage aux Secrets par défaut dans Helm 3 permet une sécurité accrue pour protéger les charts en conjonction avec la fonctionnalité de chiffrement des Secrets dans Kubernetes. @@ -133,7 +133,7 @@ Dans Helm 3, Helm a modifié le chemin d'importation Go de `k8s.io/helm` à `hel L'objet intégré `.Capabilities`, disponible durant la phase de rendu, a été simplifié. -[Built-in Objects](/docs/chart_template_guide/builtin_objects/) +[Objets intégrés]({{< ref "/docs/chart_template_guide/builtin_objects.md" >}}) ### Validation des valeurs de Chart avec JSONSchema @@ -146,7 +146,7 @@ La validation a lieu lorsque l'une des commandes suivantes est invoquée : * `helm template` * `helm lint` -Consultez la documentation sur les [fichiers de schéma](fr/docs/topics/charts#schema-files) pour plus d'informations. +Consultez la documentation sur les [fichiers de schéma]({{< ref "/docs/topics/charts.md#fichiers-de-schéma" >}}) pour plus d'informations. ### Remplacement de `requirements.yaml` en `Chart.yaml` @@ -201,7 +201,7 @@ Le projet Distribution de Docker (également connu sous le nom de Docker Registr Veuillez consulter `helm help chart` et `helm help registry` pour plus d'informations sur la manière d'empaqueter un chart et de le publier dans un registre Docker. -Pour plus d'information, consultez [cette page](/fr/docs/topics/registries/). +Pour plus d'information, consultez [cette page]({{< ref "/docs/topics/registries.md" >}}). ### Suppression de `helm serve` diff --git a/content/fr/docs/faq/troubleshooting.md b/content/fr/docs/faq/troubleshooting.md index 202db0f79..04ae968e6 100644 --- a/content/fr/docs/faq/troubleshooting.md +++ b/content/fr/docs/faq/troubleshooting.md @@ -131,4 +131,4 @@ Ou si une version différente est nécessaire, utilisez l'argument `--tiller-ima `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` -**Note :** Les mainteneurs de Helm recommandent de migrer vers une version actuellement supportée de Helm. Helm v2.17.0 était la dernière version de Helm v2 ; Helm v2 est non supporté depuis novembre 2020, comme détaillé dans [Helm 2 et le projet Charts sont maintenant obsolètes](https://helm.sh/blog/helm-2-becomes-unsupported/). De nombreuses CVE ont été signalées contre Helm depuis lors, et ces vulnérabilités sont corrigées dans Helm v3 mais ne seront jamais corrigées dans Helm v2. Consultez la [liste actuelle des avis de sécurité publiés sur Helm](https://github.com/helm/helm/security/advisories?state=published) et élaborez un plan pour [migrer vers Helm v3](https://helm.sh/docs/topics/v2_v3_migration/#helm) dès aujourd'hui. +**Note :** Les mainteneurs de Helm recommandent de migrer vers une version actuellement supportée de Helm. Helm v2.17.0 était la dernière version de Helm v2 ; Helm v2 est non supporté depuis novembre 2020, comme détaillé dans [Helm 2 et le projet Charts sont maintenant obsolètes](https://helm.sh/blog/helm-2-becomes-unsupported/). De nombreuses CVE ont été signalées contre Helm depuis lors, et ces vulnérabilités sont corrigées dans Helm v3 mais ne seront jamais corrigées dans Helm v2. Consultez la [liste actuelle des avis de sécurité publiés sur Helm](https://github.com/helm/helm/security/advisories?state=published) et élaborez un plan pour [migrer vers Helm v3]({{< ref "/docs/topics/v2_v3_migration.md" >}}) dès aujourd'hui. diff --git a/content/fr/docs/helm/helm_init.md b/content/fr/docs/helm/helm_init.md index 15478812a..af97ba02c 100644 --- a/content/fr/docs/helm/helm_init.md +++ b/content/fr/docs/helm/helm_init.md @@ -4,6 +4,6 @@ section: deprecated ## helm init -Cette commande n'existe pas dans la version 3 de Helm, référez-vous à [removal of Tiller](https://helm.sh/docs/faq/#removal-of-tiller). Vous n'avez plus besoin d'installer Tiller dans votre cluster pour utiliser Helm. +Cette commande n'existe pas dans la version 3 de Helm, référez-vous à [Suppression de Tiller]({{< ref "/docs/faq/changes_since_helm2.md#suppression-de-tiller" >}}). Vous n'avez plus besoin d'installer Tiller dans votre cluster pour utiliser Helm. Si vous utilisez la version 2 de Helm, allez sur [v2.helm.sh](https://v2.helm.sh/docs/helm/#helm-init) pour consulter la [documentation Helm Init](https://v2.helm.sh/docs/helm/#helm-init). diff --git a/content/fr/docs/howto/chart_repository_sync_example.md b/content/fr/docs/howto/chart_repository_sync_example.md index db1eda869..295ea998c 100644 --- a/content/fr/docs/howto/chart_repository_sync_example.md +++ b/content/fr/docs/howto/chart_repository_sync_example.md @@ -14,7 +14,7 @@ weight: 2 sur votre bucket GCS au cas où vous supprimeriez accidentellement quelque chose._ ## Mise en place d'un dépôt de charts local -Créez un dépôt local, comme nous l'avons fait dans [le guide du dépôt de charts](), et placez-y vos charts packagés. +Créez un dépôt local, comme nous l'avons fait dans [le guide des dépôts de charts]({{< ref "/docs/topics/chart_repository.md" >}}), et placez-y vos charts packagés. Pour exemple : ```console @@ -78,7 +78,7 @@ Downloading file://local-dir/index.yaml: 346 B/346 Liens utiles : * Documentation sur [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) -* [Guide du dépôt de chart]() +* [Guide des dépôts de chart]({{< ref "/docs/topics/chart_repository.md" >}}) * Documentation sur [object versioning and concurrency control](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) sur Google Cloud Storage diff --git a/content/fr/docs/intro/install.md b/content/fr/docs/intro/install.md index 6b4d2a2c1..7e789ec5b 100755 --- a/content/fr/docs/intro/install.md +++ b/content/fr/docs/intro/install.md @@ -20,7 +20,7 @@ et installé. 2. Décompressez l'archive (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`) 3. Trouvez le binaire `helm` dans le répertoire décompréssé, et déplacez le dans la destination voulue (`mv linux-amd64/helm /usr/local/bin/helm`) -A ce stade, vous devriez être cappable de lancer le client et [d'ajouter le dépot stable](https://helm.sh/docs/intro/quickstart/#initialize-a-helm-chart-repository): `helm help`. +A ce stade, vous devriez être cappable de lancer le client et [d'ajouter le dépot stable]({{< ref "docs/intro/quickstart.mc#initialiser-un-dépot-de-charts-helm" >}}): `helm help`. **Remarque:** Les tests automatisés de Helm sont effectués pour Linux AMD64 uniquement pendant les build et release CircleCi. Les tests d'autres systèmes d'exploitation sont sous la responsabilité de la communauté qui demande Helm pour le système d'exploitation en question. @@ -128,4 +128,4 @@ Si nécessaire, Helm récupérera les dépendances et les mettra en cache, il po Dans la plupart des cas, l'installation est aussi simple que de télécharger un binaire `helm` pré-compilé. Ce document couvre des cas supplémentaires pour ceux qui veulent utiliser Helm dans des cas plus sophistiqués. -Une fois que le client Helm est installé avec succès, vous pouvez passer à l'utilisation de Helm pour gérer des Charts [ajouter le dépot stable](https://helm.sh/docs/intro/quickstart/#initialize-a-helm-chart-repository). +Une fois que le client Helm est installé avec succès, vous pouvez passer à l'utilisation de Helm pour gérer des Charts [ajouter le dépot stable]({{< ref "docs/intro/quickstart.mc#initialiser-un-dépot-de-charts-helm" >}}). diff --git a/content/fr/docs/intro/quickstart.md b/content/fr/docs/intro/quickstart.md index 6f4a8224a..4f7a3c6d1 100644 --- a/content/fr/docs/intro/quickstart.md +++ b/content/fr/docs/intro/quickstart.md @@ -19,7 +19,7 @@ Les conditions préalables suivantes sont requises pour une utilisation correcte - Vous devez avoir installé Kubernetes. Pour la dernière release de Helm, nous recommandons la dernière version stable de Kubernetes, qui est dans la plupart des cas la deuxième release mineure la plus récente. - Vous devriez également avoir une copie locale configurée de `kubectl`. -Lisez la [Politique de prise en charge de la version Helm](https://helm.sh/docs/topics/version_skew/) pour connaitre la différence de version maximal pris en charge entre Helm et Kubernetes. +Lisez la [Politique de prise en charge de la version Helm]({{< ref "/docs/topics/version_skew.md" >}}) pour connaitre la différence de version maximal pris en charge entre Helm et Kubernetes. ## Installer Helm diff --git a/content/fr/docs/intro/using_helm.md b/content/fr/docs/intro/using_helm.md index 722503489..78279438c 100755 --- a/content/fr/docs/intro/using_helm.md +++ b/content/fr/docs/intro/using_helm.md @@ -255,7 +255,7 @@ nodeSelector: kubernetes.io/role: master ``` -Les structures de données profondément imbriquées peuvent être difficiles à exprimer en utilisant `--set`. Les concepteurs de charts sont encouragés à utiliser un fichier de valeurs au format YAML : ` values.yaml` lorsqu'il y a beaucoup de valeurs à configurer (en savoir plus sur [les fichiers de valeurs]({{< relref path="/docs/chart_template_guide/values_files/_index.md" lang="en" >}})). +Les structures de données profondément imbriquées peuvent être difficiles à exprimer en utilisant `--set`. Les concepteurs de charts sont encouragés à utiliser un fichier de valeurs au format YAML : ` values.yaml` lorsqu'il y a beaucoup de valeurs à configurer (en savoir plus sur [les fichiers de valeurs]({{< ref "/docs/chart_template_guide/values_files.md" >}}). ### Autres methodes d'installations @@ -369,7 +369,7 @@ Les dépôts peuvent être supprimés avec `helm repo remove`. ## Création de vos propres charts -Le [Guide de développement de charts]({{< relref path="/docs/topics/charts.md" lang="en" >}}) explique comment développer vos propres charts. Mais vous pouvez vous lancer rapidement dans la création de charts avec la commande `helm create`: +Le [Guide de développement de charts]({{< ref "/docs/topics/charts.md" >}}) explique comment développer vos propres charts. Mais vous pouvez vous lancer rapidement dans la création de charts avec la commande `helm create`: ```console $ helm create deis-workflow @@ -395,7 +395,7 @@ $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ``` Les charts packagés peuvent être uploadés dans des dépôts. Jetez un oeil à la -[documentation des dépôts]({{< ref path="/docs/topics/chart_repository.md" lang="en" >}}) de charts Helm pour plus de détails. +[documentation des dépôts]({{< ref "/docs/topics/chart_repository.md" >}}) de charts Helm pour plus de détails. ## Conclusion @@ -403,4 +403,4 @@ Ce chapitre a couvert les utilisations de base du client `helm`, y compris la re Pour plus d'informations sur ces commandes, consultez l'aide intégrée de Helm: `helm help`. -Dans le [chapitre suivant]({{< relref path="/docs/howto/charts_tips_and_tricks/_index.md" lang="en" >}}), nous verrons le processus de développement des charts. +Dans le [chapitre suivant]({{< ref "/docs/howto/charts_tips_and_tricks.md" >}}), nous verrons le processus de développement des charts. diff --git a/content/fr/docs/topics/chart_repository.md b/content/fr/docs/topics/chart_repository.md index ffb8deb1f..eb696a154 100644 --- a/content/fr/docs/topics/chart_repository.md +++ b/content/fr/docs/topics/chart_repository.md @@ -11,7 +11,7 @@ Le dépôt de charts Helm communautaire distribué est situé sur [Artifact Hub] ## Prérequis * Consultez le guide [Quickstart]({{< ref "quickstart.md" >}}) -* Lisez le document [Charts]({{}}) +* Lisez le document [Charts]({{< ref "charts.md" >}}) ## Créer un dépôt de charts @@ -23,7 +23,7 @@ Parce qu'un dépôt de charts peut être n'importe quel serveur HTTP capable de ### La structure du dépôt de charts -Un dépôt de charts se compose de charts emballés et d'un fichier spécial appelé `index.yaml`, qui contient un index de tous les charts dans le dépôt. Souvent, les charts décrits par `index.yaml` sont également hébergés sur le même serveur, tout comme les [fichiers de provenance]({{}}). +Un dépôt de charts se compose de charts emballés et d'un fichier spécial appelé `index.yaml`, qui contient un index de tous les charts dans le dépôt. Souvent, les charts décrits par `index.yaml` sont également hébergés sur le même serveur, tout comme les [fichiers de provenance]({{< ref "provenance.md" >}}). Par exemple, la structure du dépôt `https://example.com/charts` pourrait ressembler à ceci : diff --git a/content/fr/docs/topics/chart_tests.md b/content/fr/docs/topics/chart_tests.md index fcf500cf6..d1ccbfd05 100644 --- a/content/fr/docs/topics/chart_tests.md +++ b/content/fr/docs/topics/chart_tests.md @@ -22,7 +22,7 @@ Vous pouvez exécuter les tests prédéfinis dans Helm sur une release en utilis ## Exemple de test -La commande [helm create](/docs/helm/helm_create) créera automatiquement un certain nombre de dossiers et de fichiers. Pour essayer la fonctionnalité de test Helm, commencez par créer un chart Helm de démonstration. +La commande [helm create]({{< ref "/docs/helm/helm_create.md" >}}) créera automatiquement un certain nombre de dossiers et de fichiers. Pour essayer la fonctionnalité de test Helm, commencez par créer un chart Helm de démonstration. ```console $ helm create demo @@ -83,4 +83,4 @@ Phase: Succeeded - Vous pouvez définir autant de tests que vous le souhaitez dans un seul fichier yaml ou les répartir dans plusieurs fichiers yaml dans le répertoire `templates/`. - Vous êtes libre de regrouper votre suite de tests sous un répertoire `tests/`, comme `/templates/tests/`, pour une meilleure isolation. -- Un test est un [hook Helm](/docs/charts_hooks/), donc des annotations telles que `helm.sh/hook-weight` et `helm.sh/hook-delete-policy` peuvent être utilisées avec les ressources de test. +- Un test est un [hook Helm]({{< ref "/docs/topics/charts_hooks.md" >}}), donc des annotations telles que `helm.sh/hook-weight` et `helm.sh/hook-delete-policy` peuvent être utilisées avec les ressources de test. diff --git a/content/fr/docs/topics/charts.md b/content/fr/docs/topics/charts.md index be015e2a0..d2f38e4dd 100644 --- a/content/fr/docs/topics/charts.md +++ b/content/fr/docs/topics/charts.md @@ -94,8 +94,8 @@ Le champ `apiVersion` doit être `v2` pour les charts Helm qui nécessitent au m Changements de `v1` à `v2` : -- Un champ `dependencies` définissant les dépendances du chart, qui étaient situées dans un fichier `requirements.yaml` séparé pour les charts `v1` (voir [Dépendances des Charts](#chart-dependencies)). -- Le champ `type`, discriminant les charts d'application et les charts de bibliothèque (voir [Types de Charts](#chart-types)). +- Un champ `dependencies` définissant les dépendances du chart, qui étaient situées dans un fichier `requirements.yaml` séparé pour les charts `v1` (voir [Dépendances des Charts](#dépendances-des-charts)). +- Le champ `type`, discriminant les charts d'application et les charts de bibliothèque (voir [Types de Charts](#types-de-charts)). ### Le champ `appVersion` @@ -136,7 +136,7 @@ Lors de la gestion des charts dans un dépôt de charts, il est parfois nécessa ### Types de Charts -Le champ `type` définit le type de chart. Il y a deux types : `application` et `library`. `application` est le type par défaut et c'est le chart standard qui peut être entièrement utilisé. Le [chart de bibliothèque]({{}}) fournit des utilitaires ou des fonctions pour le constructeur de charts. Un chart de bibliothèque diffère d'un chart d'application car il n'est pas installable et ne contient généralement aucun objet de ressource. +Le champ `type` définit le type de chart. Il y a deux types : `application` et `library`. `application` est le type par défaut et c'est le chart standard qui peut être entièrement utilisé. Le [chart de bibliothèque]({{< ref "/docs/topics/library_charts.md" >}}) fournit des utilitaires ou des fonctions pour le constructeur de charts. Un chart de bibliothèque diffère d'un chart d'application car il n'est pas installable et ne contient généralement aucun objet de ressource. **Remarque :** Un chart d'application peut être utilisé comme un chart de bibliothèque. Cela est possible en définissant le type sur `library`. Le chart sera alors rendu comme un chart de bibliothèque où toutes les utilitaires et fonctions peuvent être utilisées. Tous les objets de ressource du chart ne seront pas rendus. @@ -155,7 +155,7 @@ Un README pour un chart devrait être formaté en Markdown (README.md) et devrai Lorsque les hubs et autres interfaces utilisateur affichent des détails sur un chart, ces détails sont tirés du contenu du fichier `README.md`. -Le chart peut également contenir un fichier `templates/NOTES.txt` en texte brut qui sera imprimé après l'installation et lors de la consultation du statut d'une release. Ce fichier est évalué comme un [template](#templates-and-values) et peut être utilisé pour afficher des notes d'utilisation, des étapes suivantes ou toute autre information pertinente pour une release du chart. Par exemple, des instructions pourraient être fournies pour se connecter à une base de données ou accéder à une interface web. Étant donné que ce fichier est imprimé sur STDOUT lors de l'exécution de `helm install` ou `helm status`, il est recommandé de garder le contenu bref et de renvoyer au README pour plus de détails. +Le chart peut également contenir un fichier `templates/NOTES.txt` en texte brut qui sera imprimé après l'installation et lors de la consultation du statut d'une release. Ce fichier est évalué comme un [template](#modèles-et-valeurs) et peut être utilisé pour afficher des notes d'utilisation, des étapes suivantes ou toute autre information pertinente pour une release du chart. Par exemple, des instructions pourraient être fournies pour se connecter à une base de données ou accéder à une interface web. Étant donné que ce fichier est imprimé sur STDOUT lors de l'exécution de `helm install` ou `helm status`, il est recommandé de garder le contenu bref et de renvoyer au README pour plus de détails. ## Dépendances des Charts @@ -314,7 +314,7 @@ Dans certains cas, il est souhaitable de permettre aux valeurs d'un chart enfant Les clés contenant les valeurs à importer peuvent être spécifiées dans les dépendances du chart parent dans le champ `import-values` en utilisant une liste YAML. Chaque élément de la liste est une clé qui est importée depuis le champ `exports` du chart enfant. -Pour importer des valeurs non contenues dans la clé `exports`, utilisez le format [child-parent](#using-the-child-parent-format). Des exemples des deux formats sont décrits ci-dessous. +Pour importer des valeurs non contenues dans la clé `exports`, utilisez le format [child-parent](#utilisation-du-format-enfant-parent). Des exemples des deux formats sont décrits ci-dessous. ##### Utilisation du format `exports` @@ -575,7 +575,7 @@ Notez que seul le dernier champ a été remplacé. **REMARQUE :** Si l'option `--set` est utilisée avec `helm install` ou `helm upgrade`, ces valeurs sont simplement converties en YAML côté client. -**REMARQUE :** Si des entrées requises dans le fichier de valeurs existent, elles peuvent être déclarées comme requises dans le modèle de chart en utilisant la fonction ['required']({{}}) +**REMARQUE :** Si des entrées requises dans le fichier de valeurs existent, elles peuvent être déclarées comme requises dans le modèle de chart en utilisant la fonction ['required']({{< ref "/docs/howto/charts_tips_and_tricks.md#utilisation-de-la-fonction-required" >}}) Chacune de ces valeurs est ensuite accessible à l'intérieur des modèles en utilisant l'objet `.Values` : diff --git a/content/fr/docs/topics/charts_hooks.md b/content/fr/docs/topics/charts_hooks.md index ae467842f..50ea3f019 100644 --- a/content/fr/docs/topics/charts_hooks.md +++ b/content/fr/docs/topics/charts_hooks.md @@ -67,7 +67,7 @@ Pour tous les autres types, dès que Kubernetes marque la ressource comme charg Les ressources créées par un hook ne sont actuellement pas suivies ni gérées dans le cadre de la release. Une fois que Helm vérifie que le hook a atteint son état prêt, il laissera la ressource de hook telle quelle. La collecte des ressources de hook lors de la suppression de la release correspondante pourrait être ajoutée à Helm 3 à l'avenir, donc toute ressource de hook qui ne doit jamais être supprimée doit être annotée avec `helm.sh/resource-policy: keep`. -En pratique, cela signifie que si vous créez des ressources dans un hook, vous ne pouvez pas compter sur `helm uninstall` pour supprimer les ressources. Pour détruire ces ressources, vous devez soit [ajouter une annotation personnalisée `helm.sh/hook-delete-policy`](#hook-deletion-policies) au fichier template du hook, soit [définir le champ de durée de vie (TTL) d'une ressource Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). +En pratique, cela signifie que si vous créez des ressources dans un hook, vous ne pouvez pas compter sur `helm uninstall` pour supprimer les ressources. Pour détruire ces ressources, vous devez soit [ajouter une annotation personnalisée `helm.sh/hook-delete-policy`](#politiques-de-suppression-des-hooks) au fichier template du hook, soit [définir le champ de durée de vie (TTL) d'une ressource Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). ## Écrire un Hook diff --git a/content/fr/docs/topics/kubernetes_apis.md b/content/fr/docs/topics/kubernetes_apis.md index 8a78e80b6..c51e2fd88 100644 --- a/content/fr/docs/topics/kubernetes_apis.md +++ b/content/fr/docs/topics/kubernetes_apis.md @@ -51,7 +51,7 @@ objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` -Helm échoue dans ce scénario car il tente de créer un patch de différence entre la release actuellement déployée (qui contient les APIs Kubernetes supprimées dans cette version de Kubernetes) et le chart que vous passez avec les versions d'API mises à jour/prises en charge. La raison sous-jacente de l'échec est que lorsque Kubernetes supprime une version d'API, la bibliothèque cliente Go de Kubernetes ne peut plus analyser les objets dépréciés, et Helm échoue donc lorsqu'il appelle la bibliothèque. Malheureusement, Helm ne peut pas récupérer de cette situation et n'est plus en mesure de gérer une telle release. Voir [Mise à jour des versions d'API d'un manifeste de release](#updating-api-versions-of-a-release-manifest) pour plus de détails sur la manière de récupérer de ce scénario. +Helm échoue dans ce scénario car il tente de créer un patch de différence entre la release actuellement déployée (qui contient les APIs Kubernetes supprimées dans cette version de Kubernetes) et le chart que vous passez avec les versions d'API mises à jour/prises en charge. La raison sous-jacente de l'échec est que lorsque Kubernetes supprime une version d'API, la bibliothèque cliente Go de Kubernetes ne peut plus analyser les objets dépréciés, et Helm échoue donc lorsqu'il appelle la bibliothèque. Malheureusement, Helm ne peut pas récupérer de cette situation et n'est plus en mesure de gérer une telle release. Voir [Mise à jour des versions d'API d'un manifeste de release](#mise-à-jour-des-versions-dapi-dun-manifeste-de-release) pour plus de détails sur la manière de récupérer de ce scénario. ## Mise à jour des versions d'API d'un manifeste de release diff --git a/content/fr/docs/topics/library_charts.md b/content/fr/docs/topics/library_charts.md index 83bd381d4..5b81ec865 100644 --- a/content/fr/docs/topics/library_charts.md +++ b/content/fr/docs/topics/library_charts.md @@ -54,7 +54,7 @@ data: {} Le construct ConfigMap est défini dans le template nommé `mylibchart.configmap.tpl`. C'est un ConfigMap simple avec une ressource vide, `data`. Dans ce fichier, il y a un autre template nommé appelé `mylibchart.configmap`. Ce template nommé inclut un autre template nommé, `mylibchart.util.merge`, qui prendra deux templates nommés en arguments : le template appelant `mylibchart.configmap` et `mylibchart.configmap.tpl`. -La fonction d'assistance `mylibchart.util.merge` est un template nommé dans `mylibchart/templates/_util.yaml`. C'est un utilitaire pratique de [Le Chart d'Assistance Helm Commun]() car il fusionne les deux templates et remplace les parties communes dans les deux : +La fonction d'assistance `mylibchart.util.merge` est un template nommé dans `mylibchart/templates/_util.yaml`. C'est un utilitaire pratique de [Le Chart d'Assistance Helm Commun](#le-chart-dassistance-helm-commun) car il fusionne les deux templates et remplace les parties communes dans les deux : ```yaml {{- /* diff --git a/content/fr/docs/topics/plugins.md b/content/fr/docs/topics/plugins.md index c3f1aebe9..723b475ac 100644 --- a/content/fr/docs/topics/plugins.md +++ b/content/fr/docs/topics/plugins.md @@ -6,7 +6,7 @@ weight: 12 Un plugin Helm est un outil qui peut être accédé via l'interface en ligne de commande `helm`, mais qui ne fait pas partie de la base de code intégrée de Helm. -Les plugins existants peuvent être trouvés dans la section [liée]({{}}) ou en recherchant sur [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). +Les plugins existants peuvent être trouvés dans la section [liée]({{< ref "/docs/community/related.md#plugins-helm" >}}) ou en recherchant sur [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). Ce guide explique comment utiliser et créer des plugins. @@ -190,9 +190,9 @@ Remarques : 3. Les arguments courts et longs peuvent et doivent être spécifiés. Un argument court n'a pas besoin d'être associé à sa forme longue correspondante, mais les deux formes doivent être listées. 4. Les arguments n'ont pas besoin d'être ordonnés de manière spécifique, mais doivent être listés au bon endroit dans la hiérarchie des sous-commandes du fichier. 5. Les arguments globaux existants de Helm sont déjà pris en charge par le mécanisme d'auto-complétion de Helm, donc les plugins n'ont pas besoin de spécifier les arguments suivants : `--debug`, `--namespace` ou `-n`, `--kube-context`, et `--kubeconfig`, ou tout autre flag global. -6. La liste `validArgs` fournit une liste statique de complétions possibles pour le premier paramètre suivant une sous-commande. Il n'est pas toujours possible de fournir une telle liste à l'avance (voir la section [Complétion Dynamique]() ci-dessous), auquel cas la section `validArgs` peut être omise. +6. La liste `validArgs` fournit une liste statique de complétions possibles pour le premier paramètre suivant une sous-commande. Il n'est pas toujours possible de fournir une telle liste à l'avance (voir la section [Complétion Dynamique](#complétion-dynamique) ci-dessous), auquel cas la section `validArgs` peut être omise. -Le fichier `completion.yaml` est entièrement optionnel. S'il n'est pas fourni, Helm ne proposera tout simplement pas l'auto-complétion shell pour le plugin (à moins que la [Complétion Dynamique]() soit supportée par le plugin). De plus, l'ajout d'un fichier `completion.yaml` est rétrocompatible et n'affectera pas le comportement du plugin avec les versions antérieures de Helm. +Le fichier `completion.yaml` est entièrement optionnel. S'il n'est pas fourni, Helm ne proposera tout simplement pas l'auto-complétion shell pour le plugin (à moins que la [Complétion Dynamique](#complétion-dynamique) soit supportée par le plugin). De plus, l'ajout d'un fichier `completion.yaml` est rétrocompatible et n'affectera pas le comportement du plugin avec les versions antérieures de Helm. Par exemple, pour le [`plugin fullstatus`](https://github.com/marckhouzam/helm-fullstatus) qui n'a pas de sous-commandes mais accepte les mêmes flags que la commande `helm status`, le fichier `completion.yaml` est : @@ -278,7 +278,7 @@ Le vrai script du plugin `fullstatus` (`status.sh`) doit alors rechercher l'argu ### Conseils et astuces 1. Le shell filtrera automatiquement les choix de complétion qui ne correspondent pas à l'entrée de l'utilisateur. Un plugin peut donc retourner toutes les complétions pertinentes sans supprimer celles qui ne correspondent pas à l'entrée de l'utilisateur. Par exemple, si la ligne de commande est `helm fullstatus ngin`, le script `plugin.complete` peut imprimer *tous* les noms de release (de l'espace de noms `default`), pas seulement ceux commençant par `ngin` ; le shell ne conservera que ceux commençant par `ngin`. -2. Pour simplifier le support de la complétion dynamique, surtout si vous avez un plugin complexe, vous pouvez faire en sorte que votre script `plugin.complete` appelle votre script principal de plugin et demande des choix de complétion. Voir la section [Complétion Dynamique]() ci-dessus pour un exemple. +2. Pour simplifier le support de la complétion dynamique, surtout si vous avez un plugin complexe, vous pouvez faire en sorte que votre script `plugin.complete` appelle votre script principal de plugin et demande des choix de complétion. Voir la section [Complétion Dynamique](#complétion-dynamique) ci-dessus pour un exemple. 3. Pour déboguer la complétion dynamique et le fichier `plugin.complete`, vous pouvez exécuter ce qui suit pour voir les résultats de complétion : - `helm __complete `. Par exemple : - `helm __complete fullstatus --output js`, diff --git a/content/fr/docs/topics/provenance.md b/content/fr/docs/topics/provenance.md index e1badd722..42c2175b0 100644 --- a/content/fr/docs/topics/provenance.md +++ b/content/fr/docs/topics/provenance.md @@ -207,7 +207,7 @@ Du point de vue de l'utilisateur final, la commande `helm install --verify myrep ### Signatures dans les registres basés sur OCI -Lors de la publication de charts dans un [registre basé sur OCI]({{}}), le [plugin `helm-sigstore`](https://github.com/sigstore/helm-sigstore/) peut être utilisé pour publier les informations de provenance sur [sigstore](https://sigstore.dev/). [Comme décrit dans la documentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), le processus de création de provenance et de signature avec une clé GPG est similaire, mais la commande `helm sigstore upload` peut être utilisée pour publier la provenance sur un registre d'immuabilité transparent. +Lors de la publication de charts dans un [registre basé sur OCI]({{< ref "/docs/topics/registries.md" >}}), le [plugin `helm-sigstore`](https://github.com/sigstore/helm-sigstore/) peut être utilisé pour publier les informations de provenance sur [sigstore](https://sigstore.dev/). [Comme décrit dans la documentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), le processus de création de provenance et de signature avec une clé GPG est similaire, mais la commande `helm sigstore upload` peut être utilisée pour publier la provenance sur un registre d'immuabilité transparent. ## Établir l'Autorité et l'Authenticité diff --git a/content/fr/docs/topics/registries.md b/content/fr/docs/topics/registries.md index f5f4ced30..9713fcd06 100644 --- a/content/fr/docs/topics/registries.md +++ b/content/fr/docs/topics/registries.md @@ -115,7 +115,7 @@ to be created beforehand. Otherwise, an error will be produced during the Si vous avez créé un [fichier de provenance]({{< ref "provenance.md" >}}) (`.prov`) et qu'il est présent à côté du fichier `.tgz` du chart, il sera automatiquement téléchargé vers le registre lors de l'opération `push`. Cela ajoute une couche supplémentaire sur [le manifeste du chart Helm](#helm-chart-manifest). -Les utilisateurs du [plugin helm-push](https://github.com/chartmuseum/helm-push) (pour télécharger des charts vers [ChartMuseum]({{}}) peuvent rencontrer des problèmes, car le plugin entre en conflit avec la nouvelle fonction `push` intégrée. Depuis la version v0.10.0, le plugin a été renommé en `cm-push`. +Les utilisateurs du [plugin helm-push](https://github.com/chartmuseum/helm-push) (pour télécharger des charts vers [ChartMuseum]({{< ref "/docs/topics/chart_repository.md#serveur-de-dépôt-chartmuseum" >}}) peuvent rencontrer des problèmes, car le plugin entre en conflit avec la nouvelle fonction `push` intégrée. Depuis la version v0.10.0, le plugin a été renommé en `cm-push`. ### Autres sous-commandes diff --git a/content/fr/docs/topics/version_skew.md b/content/fr/docs/topics/version_skew.md index dda208ecc..9637359ed 100644 --- a/content/fr/docs/topics/version_skew.md +++ b/content/fr/docs/topics/version_skew.md @@ -9,7 +9,7 @@ Ce document décrit l'écart de version maximal supporté entre Helm et Kubernet Les versions de Helm sont exprimées sous la forme `x.y.z`, où `x` est la version majeure, `y` est la version mineure et `z` est la version de correction, conformément à la terminologie du [Versionnage Sémantique](https://semver.org/spec/v2.0.0.html). -Le projet Helm maintient une branche de version pour la dernière version mineure en date. Les correctifs applicables, y compris les correctifs de sécurité, sont sélectionnés et intégrés dans la branche de version, en fonction de la gravité et de la faisabilité. Plus de détails peuvent être trouvés dans la [politique de publication de Helm]({{}}). +Le projet Helm maintient une branche de version pour la dernière version mineure en date. Les correctifs applicables, y compris les correctifs de sécurité, sont sélectionnés et intégrés dans la branche de version, en fonction de la gravité et de la faisabilité. Plus de détails peuvent être trouvés dans la [politique de publication de Helm]({{< ref "/docs/topics/release_policy.md" >}}). ## Écart de version supporté From f606ab74313c139bd397602855a14e5de6167643 Mon Sep 17 00:00:00 2001 From: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Sat, 28 Sep 2024 01:38:46 +0200 Subject: [PATCH 11/15] Fixing wrong hash Signed-off-by: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- content/fr/docs/chart_template_guide/function_list.md | 2 +- content/fr/docs/topics/kubernetes_apis.md | 2 +- content/fr/docs/topics/registries.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/fr/docs/chart_template_guide/function_list.md b/content/fr/docs/chart_template_guide/function_list.md index f8bcd406f..5dac3842d 100644 --- a/content/fr/docs/chart_template_guide/function_list.md +++ b/content/fr/docs/chart_template_guide/function_list.md @@ -20,7 +20,7 @@ Helm comprend de nombreuses fonctions de modèle que vous pouvez utiliser dans l * [Réflexion](#fonctions-de-réflexion) * [Expressions régulières](#expressions-régulières) * [Version Sémantique](#fonctions-de-version-sémantique) -* [String](#string-functions) +* [Chaîne de Caractères](#fonction-de-chaîne-de-caractères) * [Conversion de Type](#fonctions-de-conversion-de-type) * [URL](#fonctions-durl) * [UUID](#fonctions-uuid) diff --git a/content/fr/docs/topics/kubernetes_apis.md b/content/fr/docs/topics/kubernetes_apis.md index c51e2fd88..0822eeb13 100644 --- a/content/fr/docs/topics/kubernetes_apis.md +++ b/content/fr/docs/topics/kubernetes_apis.md @@ -36,7 +36,7 @@ Les moyens de mettre à jour une release Helm vers des APIs prises en charge dé - Si vous utilisez une version de Kubernetes où les versions d'API sont encore disponibles (par exemple, vous êtes sur Kubernetes 1.15 et vous avez trouvé que vous utilisez des APIs qui seront supprimées dans Kubernetes 1.16) : - Suivez la procédure de l'étape 1. - Sinon (par exemple, vous utilisez déjà une version de Kubernetes où certaines versions d'API signalées par `helm get manifest` ne sont plus disponibles) : - - Vous devez éditer le manifeste de la release stocké dans le cluster pour mettre à jour les versions d'API vers des APIs prises en charge. Voir [Mise à jour des versions d'API d'un manifeste de release](#updating-api-versions-of-a-release-manifest) pour plus de détails. + - Vous devez éditer le manifeste de la release stocké dans le cluster pour mettre à jour les versions d'API vers des APIs prises en charge. Voir [Mise à jour des versions d'API d'un manifeste de release](#mise-à-jour-des-versions-dapi-dun-manifeste-de-release) pour plus de détails. > Remarque : Dans tous les cas de mise à jour d'une release Helm avec des APIs prises en charge, vous ne devez jamais faire de rollback de la release vers une version antérieure à la version de la release avec les APIs prises en charge. diff --git a/content/fr/docs/topics/registries.md b/content/fr/docs/topics/registries.md index 9713fcd06..53533a598 100644 --- a/content/fr/docs/topics/registries.md +++ b/content/fr/docs/topics/registries.md @@ -113,7 +113,7 @@ Certain registries require the repository and/or namespace (if specified) to be created beforehand. Otherwise, an error will be produced during the `helm push` operation. -Si vous avez créé un [fichier de provenance]({{< ref "provenance.md" >}}) (`.prov`) et qu'il est présent à côté du fichier `.tgz` du chart, il sera automatiquement téléchargé vers le registre lors de l'opération `push`. Cela ajoute une couche supplémentaire sur [le manifeste du chart Helm](#helm-chart-manifest). +Si vous avez créé un [fichier de provenance]({{< ref "provenance.md" >}}) (`.prov`) et qu'il est présent à côté du fichier `.tgz` du chart, il sera automatiquement téléchargé vers le registre lors de l'opération `push`. Cela ajoute une couche supplémentaire sur [le manifeste du chart Helm](#manifeste-de-chart-helm). Les utilisateurs du [plugin helm-push](https://github.com/chartmuseum/helm-push) (pour télécharger des charts vers [ChartMuseum]({{< ref "/docs/topics/chart_repository.md#serveur-de-dépôt-chartmuseum" >}}) peuvent rencontrer des problèmes, car le plugin entre en conflit avec la nouvelle fonction `push` intégrée. Depuis la version v0.10.0, le plugin a été renommé en `cm-push`. From 6c656e4e971df045fe20ec4bcf3ea8975145007d Mon Sep 17 00:00:00 2001 From: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Sat, 28 Sep 2024 01:42:53 +0200 Subject: [PATCH 12/15] Fixing wrong hash Signed-off-by: BenjaminFourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- content/fr/docs/community/release_checklist.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/fr/docs/community/release_checklist.md b/content/fr/docs/community/release_checklist.md index e372564a4..b6bfa7bc2 100644 --- a/content/fr/docs/community/release_checklist.md +++ b/content/fr/docs/community/release_checklist.md @@ -89,7 +89,7 @@ Cette nouvelle branche servira de base pour la version, sur laquelle nous allons Vérifiez qu'un [milestone helm/helm](https://github.com/helm/helm/milestones) pour la version existe sur GitHub (en le créant si nécessaire). Assurez-vous que les PRs et les issues pour cette version sont inclus dans ce milestone. -Pour les versions majeures et mineures, passez à l'étape 2 : [Versions majeures/minor : Changer le numéro de version dans Git](#2-majorminor-releases-change-the-version-number-in-git). +Pour les versions majeures et mineures, passez à l'étape 2 : [Versions majeures/minor : Changer le numéro de version dans Git](#2-versions-majeuresmineures--modifier-le-numéro-de-version-dans-git). ### Versions de correction @@ -120,7 +120,7 @@ Pousser la branche déclenchera l'exécution des tests. Assurez-vous qu'ils pass La création d'un [jalon Helm/helm](https://github.com/helm/helm/milestones) est facultative pour les versions de correction. -Assurez-vous de vérifier [helm sur CircleCI](https://circleci.com/gh/helm/helm) pour voir si la version a réussi les tests CI avant de continuer. Les versions de correction peuvent sauter les étapes 2 à 5 et passer directement à l'étape 6 pour [Finaliser la version](#6-finalize-the-release). +Assurez-vous de vérifier [helm sur CircleCI](https://circleci.com/gh/helm/helm) pour voir si la version a réussi les tests CI avant de continuer. Les versions de correction peuvent sauter les étapes 2 à 5 et passer directement à l'étape 6 pour [Finaliser la version](#6-finaliser-la-version). ## 2. Versions majeures/mineures : Modifier le numéro de version dans Git @@ -243,7 +243,7 @@ git push upstream $RELEASE_CANDIDATE_NAME Une fois poussée sur GitHub, vérifiez que la branche avec ce tag se construit correctement dans CI. -À partir de là, répétez simplement ce processus en testant en continu jusqu'à ce que vous soyez satisfait du candidat à la version. Pour un candidat à la version, nous ne rédigeons pas les notes complètes, mais vous pouvez esquisser quelques [notes de version](#7-write-the-release-notes). +À partir de là, répétez simplement ce processus en testant en continu jusqu'à ce que vous soyez satisfait du candidat à la version. Pour un candidat à la version, nous ne rédigeons pas les notes complètes, mais vous pouvez esquisser quelques [notes de version](#7-rédiger-les-notes-de-version). ## 6. Finaliser la version From 4dd5116290f9d854a505646090d1c842ad1dff46 Mon Sep 17 00:00:00 2001 From: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Mon, 7 Oct 2024 09:38:20 +0200 Subject: [PATCH 13/15] Typing fault Signed-off-by: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- content/fr/docs/intro/install.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/fr/docs/intro/install.md b/content/fr/docs/intro/install.md index 7e789ec5b..911f40a5b 100755 --- a/content/fr/docs/intro/install.md +++ b/content/fr/docs/intro/install.md @@ -128,4 +128,4 @@ Si nécessaire, Helm récupérera les dépendances et les mettra en cache, il po Dans la plupart des cas, l'installation est aussi simple que de télécharger un binaire `helm` pré-compilé. Ce document couvre des cas supplémentaires pour ceux qui veulent utiliser Helm dans des cas plus sophistiqués. -Une fois que le client Helm est installé avec succès, vous pouvez passer à l'utilisation de Helm pour gérer des Charts [ajouter le dépot stable]({{< ref "docs/intro/quickstart.mc#initialiser-un-dépot-de-charts-helm" >}}). +Une fois que le client Helm est installé avec succès, vous pouvez passer à l'utilisation de Helm pour gérer des Charts [ajouter le dépot stable]({{< ref "docs/intro/quickstart.md#initialiser-un-dépot-de-charts-helm" >}}). From be319e31b2d8f0b2f07d66342459d636a57ca07e Mon Sep 17 00:00:00 2001 From: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Sun, 26 Jan 2025 22:08:58 +0100 Subject: [PATCH 14/15] Apply suggestions from code review Co-authored-by: Karen Chu Signed-off-by: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- .../fr/docs/chart_template_guide/accessing_files.md | 1 - .../fr/docs/chart_template_guide/control_structures.md | 2 ++ content/fr/docs/community/release_checklist.md | 10 +++++----- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/content/fr/docs/chart_template_guide/accessing_files.md b/content/fr/docs/chart_template_guide/accessing_files.md index 027edacf2..afdabb988 100644 --- a/content/fr/docs/chart_template_guide/accessing_files.md +++ b/content/fr/docs/chart_template_guide/accessing_files.md @@ -15,7 +15,6 @@ Helm permet d'accéder aux fichiers via l'objet `.Files`. Avant de commencer ave - Les fichiers en dehors d'une application Helm [sous-chart]({{< ref "/docs/chart_template_guide/subcharts_and_globals.md" >}}), y compris ceux du parent, ne peuvent pas être accédés. - Les charts ne conservent pas les informations de mode UNIX, donc les permissions au niveau des fichiers n'affecteront pas la disponibilité d'un fichier via l'objet `.Files`. - diff --git a/content/fr/docs/chart_template_guide/control_structures.md b/content/fr/docs/chart_template_guide/control_structures.md index cd96e80bf..75221bfda 100644 --- a/content/fr/docs/chart_template_guide/control_structures.md +++ b/content/fr/docs/chart_template_guide/control_structures.md @@ -301,6 +301,7 @@ pizzaToppings: - cheese - peppers - onions + - pineapple ``` Nous avons maintenant une liste (appelée `slice` dans les modèles) de `pizzaToppings`. Nous pouvons modifier notre modèle pour imprimer cette liste dans notre ConfigMap : @@ -360,6 +361,7 @@ data: - "Cheese" - "Peppers" - "Onions" + - "Pineapple" ``` Dans cet exemple, nous avons fait quelque chose de subtil. La ligne `toppings: |-` déclare une chaîne multi-lignes. Donc, notre liste de garnitures n'est en réalité pas une liste YAML. C'est une grande chaîne de caractères. Pourquoi ferions-nous cela ? Parce que les données dans les `ConfigMaps` `data` sont composées de paires clé/valeur, où la clé et la valeur sont toutes deux des chaînes simples. Pour comprendre pourquoi c'est le cas, consultez la [documentation des ConfigMaps Kubernetes](https://kubernetes.io/docs/concepts/configuration/configmap/). Pour nous, cependant, ce détail n'a pas beaucoup d'importance. diff --git a/content/fr/docs/community/release_checklist.md b/content/fr/docs/community/release_checklist.md index b6bfa7bc2..eb9307edd 100644 --- a/content/fr/docs/community/release_checklist.md +++ b/content/fr/docs/community/release_checklist.md @@ -120,7 +120,7 @@ Pousser la branche déclenchera l'exécution des tests. Assurez-vous qu'ils pass La création d'un [jalon Helm/helm](https://github.com/helm/helm/milestones) est facultative pour les versions de correction. -Assurez-vous de vérifier [helm sur CircleCI](https://circleci.com/gh/helm/helm) pour voir si la version a réussi les tests CI avant de continuer. Les versions de correction peuvent sauter les étapes 2 à 5 et passer directement à l'étape 6 pour [Finaliser la version](#6-finaliser-la-version). +Assurez-vous de vérifier [GitHub Actions](https://github.com/helm/helm/actions) pour voir si la version a réussi les tests CI avant de continuer. Les versions de correction peuvent sauter les étapes 2 à 5 et passer directement à l'étape 6 pour [Finaliser la version](#6-finaliser-la-version). ## 2. Versions majeures/mineures : Modifier le numéro de version dans Git @@ -182,7 +182,7 @@ Pour que les autres puissent commencer les tests, nous pouvons maintenant pousse git push upstream $RELEASE_BRANCH_NAME ``` -Assurez-vous de vérifier [helm sur CircleCI](https://circleci.com/gh/helm/helm) pour voir si la version a réussi les tests CI avant de continuer. +Assurez-vous de vérifier [GitHub Actions](https://github.com/helm/helm/actions) pour voir si la version a réussi les tests CI avant de continuer. Si possible, demandez à d'autres personnes de faire une révision par les pairs de la branche avant de poursuivre, afin de garantir que toutes les modifications nécessaires ont été apportées et que tous les commits pour la version sont présents. @@ -195,9 +195,9 @@ git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${ git push upstream $RELEASE_CANDIDATE_NAME ``` -CircleCI créera automatiquement une image de version taguée et un binaire client pour les tests. +GitHub Actions créera automatiquement une image de version taguée et un binaire client pour les tests. -Pour les testeurs, le processus pour commencer les tests après que CircleCI ait terminé la construction des artefacts comprend les étapes suivantes pour récupérer le client : +Pour les testeurs, le processus pour commencer les tests après que GitHub Actions ait terminé la construction des artefacts comprend les étapes suivantes pour récupérer le client : linux/amd64, utilisez /bin/bash: @@ -255,7 +255,7 @@ git tag --sign --annotate "${RELEASE_NAME}" --message "Helm release ${RELEASE_NA git push upstream $RELEASE_NAME ``` -Vérifiez que la version a réussi dans [CircleCI](https://circleci.com/gh/helm/helm). Si ce n'est pas le cas, vous devrez corriger la version et la pousser à nouveau. +Vérifiez que la version a réussi dans [GitHub Actions](https://github.com/helm/helm/actions). Si ce n'est pas le cas, vous devrez corriger la version et la pousser à nouveau. Comme le job CI prendra un certain temps à s'exécuter, vous pouvez passer à la rédaction des notes de version pendant que vous attendez sa conclusion. From d0efcca761776d62f28179d3f9af38fb0a15bb36 Mon Sep 17 00:00:00 2001 From: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> Date: Sun, 26 Jan 2025 23:40:11 +0100 Subject: [PATCH 15/15] Changes from request review Signed-off-by: Benjamin Fourmaux <49273769+BenjaminFourmaux@users.noreply.github.com> --- .../chart_template_guide/named_templates.md | 2 +- .../fr/docs/chart_template_guide/variables.md | 2 +- content/fr/docs/community/developers.md | 10 + content/fr/docs/community/related.md | 5 + content/fr/docs/topics/advanced.md | 56 +---- content/fr/docs/topics/chart_repository.md | 2 +- content/fr/docs/topics/plugins.md | 202 ++++++++++++++---- content/fr/docs/topics/version_skew.md | 2 + 8 files changed, 181 insertions(+), 100 deletions(-) diff --git a/content/fr/docs/chart_template_guide/named_templates.md b/content/fr/docs/chart_template_guide/named_templates.md index 616b6327c..e2cdb3043 100644 --- a/content/fr/docs/chart_template_guide/named_templates.md +++ b/content/fr/docs/chart_template_guide/named_templates.md @@ -168,7 +168,7 @@ metadata: {{- template "mychart.labels" . }} ``` -Notez que nous passons `.` à la fin de l'appel `template`. Nous pourrions tout aussi bien passer `.Values`, `.Values.favorite` ou tout autre scope que nous souhaitons. Mais ce que nous voulons, c'est le scope de niveau supérieur. +Notez que nous passons `.` à la fin de l'appel `template`. Nous pourrions tout aussi bien passer `.Values`, `.Values.favorite` ou tout autre scope souhaité. Mais ce que nous voulons ici, c'est le scope de niveau supérieur. Dans le contexte du modèle nommé, `$` fera référence au scope que vous avez passé et non à un scope global. Maintenant, lorsque nous exécutons ce modèle avec `helm install --dry-run --debug plinking-anaco ./mychart`, nous obtenons ceci : diff --git a/content/fr/docs/chart_template_guide/variables.md b/content/fr/docs/chart_template_guide/variables.md index 811bfd1d7..e0c9d7a78 100644 --- a/content/fr/docs/chart_template_guide/variables.md +++ b/content/fr/docs/chart_template_guide/variables.md @@ -86,7 +86,7 @@ data: {{- end }} ``` -Pour les structures de données qui ont à la fois une clé et une valeur, nous pouvons utiliser `range` pour obtenir les deux. Par exemple, nous pouvons boucler sur `.Values.favorite` comme ceci : +Lors de la première itération, `$key` sera à `drink` et `$val` sera à `coffee` et lors de la seconde, `$key` sera à `food` et `$val` sera à `pizza`. L'exécution de ce qui précède générera ceci : ```yaml # Source: mychart/templates/configmap.yaml diff --git a/content/fr/docs/community/developers.md b/content/fr/docs/community/developers.md index 7f79e894d..cc7d893c7 100644 --- a/content/fr/docs/community/developers.md +++ b/content/fr/docs/community/developers.md @@ -30,6 +30,16 @@ Pour exécuter Helm localement, vous pouvez exécuter `bin/helm`. Pour exécuter tous les tests, lancez `make test`. Comme prérequis, vous devez avoir [golangci-lint](https://golangci-lint.run) installé. +## Exécution locale + +Vous pouvez mettre à jour votre variable PATH et ajouter le chemin de votre binaire Helm local. Dans un éditeur, ouvrez votre fichier de configuration de shell. Ajoutez la ligne suivante en veillant à remplacer `` par le répertoire de votre dossier binaire local : + +``` +export PATH=":$PATH" +``` + +Cela vous permettra d'exécuter la version construite localement de Helm depuis votre terminal. + ## Directives de Contribution Nous accueillons volontiers les contributions. Ce projet a établi certaines directives afin de garantir que (a) la qualité du code reste élevée, (b) le projet reste cohérent, et (c) les contributions respectent les exigences légales en matière de logiciel open source. Notre intention n'est pas de surcharger les contributeurs, mais de construire un code open source élégant et de haute qualité afin que nos utilisateurs en bénéficient. diff --git a/content/fr/docs/community/related.md b/content/fr/docs/community/related.md index 3b7dff099..cbce44190 100644 --- a/content/fr/docs/community/related.md +++ b/content/fr/docs/community/related.md @@ -19,6 +19,7 @@ Si vous avez quelque chose à ajouter à cette liste, n'hésitez pas à ouvrir u - [helm-git](https://github.com/aslafy-z/helm-git) - Installer des charts et récupérer des fichiers de valeurs depuis vos dépôts Git - [helm-k8comp](https://github.com/cststack/k8comp) - Plugin pour créer des Helm Charts à partir de hiera en utilisant k8comp - [helm-mapkubeapis](https://github.com/helm/helm-mapkubeapis) - Mettre à jour les métadonnées des releases Helm pour remplacer les API Kubernetes obsolètes ou supprimées +- [helm-migrate-values](https://github.com/OctopusDeployLabs/helm-migrate-values) - Plugin pour migrer les valeurs spécifiées par l'utilisateur entre différentes versions d'un chart Helm afin de gérer les changements de schéma incompatibles dans le fichier `values.yaml` - [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) - Plugin pour surveiller une release et effectuer un rollback basé sur une requête Prometheus/ElasticSearch - [helm-release-plugin](https://github.com/JovianX/helm-release-plugin) - Plugin pour la gestion des releases : mettre à jour les valeurs des releases, extraire (et recréer) les Helm Charts à partir des releases déployées, et définir le TTL des releases Helm. - [helm-s3](https://github.com/hypnoglow/helm-s3) -Plugin Helm permettant d'utiliser AWS S3 comme [dépôt] privé de charts @@ -33,6 +34,7 @@ Si vous avez quelque chose à ajouter à cette liste, n'hésitez pas à ouvrir u - [helm-external-val](https://github.com/kuuji/helm-external-val) - Plugin qui récupère les valeurs Helm depuis des sources externes (ConfigMaps, Secrets, etc.). - [helm-images](https://github.com/nikhilsbhat/helm-images) - Plugin Helm pour récupérer toutes les images possibles depuis le chart avant le déploiement ou depuis une release déployée. - [helm-drift](https://github.com/nikhilsbhat/helm-drift) - Plugin Helm qui identifie la configuration ayant divergé du Helm chart. +- [helm-tui](https://github.com/pidanou/helm-tui) - Une interface légère pour gérer vos ressources Helm sans quitter le terminal Nous encourageons également les auteurs sur GitHub à utiliser le tag [helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories) sur leurs dépôts de plugins. @@ -42,6 +44,7 @@ Outils superposés à Helm. Voici la traduction des outils et plugins mentionnés : +- [Aptakube](https://aptakube.com/) - Interface bureau pour les versions Kubernetes et Helm - [Armada](https://airshipit.readthedocs.io/projects/armada/en/latest/) - Gère les releases préfixées à travers divers namespaces Kubernetes et supprime les jobs terminés pour des déploiements complexes. - [avionix](https://github.com/zbrookle/avionix) - Interface Python pour générer des Helm charts et des fichiers Kubernetes YAML, permettant l'héritage et moins de duplication de code. - [Botkube](https://botkube.io) - Exécute des commandes Helm directement depuis Slack, Discord, Microsoft Teams et Mattermost. @@ -50,11 +53,13 @@ Voici la traduction des outils et plugins mentionnés : - [ChartMuseum](https://github.com/helm/chartmuseum) - Dépôt de Helm Charts avec support pour Amazon S3 et Google Cloud Storage. - [chart-registry](https://github.com/hangyan/chart-registry) - Héberge des Helm Charts sur OCI Registry. - [Codefresh](https://codefresh.io) - Plateforme CI/CD et de gestion native Kubernetes avec des tableaux de bord UI pour gérer les Helm charts et les releases. +- [Cyclops]https://cyclops-ui.com/) - Rendu dynamique d'une interface utilisateur Kubernetes basé sur des charts Helm - [Flux](https://fluxcd.io/docs/components/helm/) - Livraison continue et progressive de Git à Kubernetes. - [Helmfile](https://github.com/helmfile/helmfile) - Helmfile est un spécification déclarative pour déployer des Helm charts. - [Helmper](https://github.com/ChristofferNissen/helmper) - Helmper vous aide à importer des Helm Charts - y compris tous les artefacts OCI (images), dans vos propres OCI registries. Helmper facilite également le scan de sécurité et le patch des images OCI. Helmper utilise Helm, Oras, Trivy, Copacetic et Buildkitd. - [Helmsman](https://github.com/Praqma/helmsman) - Helmsman est un outil de type helm-charts-as-code qui permet d’installer, mettre à jour, protéger, déplacer et supprimer des releases à partir de fichiers d'état désiré versionnés (décrits dans un format TOML simple). - [HULL](https://github.com/vidispine/hull) - Cette bibliothèque chart fournit une interface prête à l'emploi pour spécifier tous les objets Kubernetes directement dans le `values.yaml`. Elle élimine la nécessité d'écrire des templates pour vos charts et propose de nombreuses fonctionnalités supplémentaires pour simplifier la création et l'utilisation des Helm charts. +- [K8Studio](https://k8studio.io/) - Interface utilisateur de bureau pour la gestion des clusters Kubernetes avec un gestionnaire Helm intégré. - [Konveyor Move2Kube](https://konveyor.io/move2kube/) - Génère des Helm charts pour vos projets existants. - [Landscaper](https://github.com/Eneco/landscaper/) - "Landscaper prend un ensemble de références de Helm Chart avec des valeurs (un état désiré) et le réalise dans un cluster Kubernetes." - [Monocular](https://github.com/helm/monocular) - Interface Web pour les dépôts de Helm Charts. diff --git a/content/fr/docs/topics/advanced.md b/content/fr/docs/topics/advanced.md index b9ee79243..90d80cc63 100644 --- a/content/fr/docs/topics/advanced.md +++ b/content/fr/docs/topics/advanced.md @@ -44,61 +44,7 @@ type PostRenderer interface { } ``` -Pour plus d'informations sur l'utilisation du Go SDK, consultez la [section Go SDK](#go-sdk). - -## Go SDK -Helm 3 a introduit un Go SDK entièrement restructuré pour offrir une meilleure expérience lors de la création de logiciels et d'outils utilisant Helm. La documentation complète est disponible sur [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3), mais un court aperçu de certains des packages les plus courants ainsi qu'un exemple simple suivent ci-dessous. - -### Vue d'ensemble des packages -Voici une liste des packages les plus couramment utilisés avec une explication simple pour chacun : - -- `pkg/action` : Contient le « client » principal pour effectuer des actions Helm. Il s'agit du même package utilisé en interne par la CLI. Si vous devez simplement exécuter des commandes Helm de base depuis un autre programme Go, ce package est fait pour vous. -- `pkg/{chart,chartutil}` : Méthodes et outils utilisés pour charger et manipuler des charts. -- `pkg/cli` et ses sous-packages : Contient tous les gestionnaires des variables d'environnement Helm standard, et ses sous-packages gèrent la sortie et les fichiers de valeurs. -- `pkg/release` : Définit l'objet `Release` et ses statuts. - -Évidemment, il existe de nombreux autres packages en plus de ceux-ci, alors consultez la documentation pour plus d'informations ! - -### Exemple simple -Voici un exemple simple de réalisation d'un `helm list` en utilisant le Go SDK : - -```go -package main - -import ( - "log" - "os" - - "helm.sh/helm/v3/pkg/action" - "helm.sh/helm/v3/pkg/cli" -) - -func main() { - settings := cli.New() - - actionConfig := new(action.Configuration) - // // Vous pouvez passer une chaîne vide au lieu de settings.Namespace() pour lister tous les namespaces - - if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { - log.Printf("%+v", err) - os.Exit(1) - } - - client := action.NewList(actionConfig) - // Liste uniquement les déploiements - client.Deployed = true - results, err := client.Run() - if err != nil { - log.Printf("%+v", err) - os.Exit(1) - } - - for _, rel := range results { - log.Printf("%+v", rel) - } -} - -``` +Pour plus d'informations sur l'utilisation du Go SDK, consultez la [section Go SDK](https://helm.sh/docs/sdk/gosdk/). ## Stockage des backends diff --git a/content/fr/docs/topics/chart_repository.md b/content/fr/docs/topics/chart_repository.md index eb696a154..cfdf594d8 100644 --- a/content/fr/docs/topics/chart_repository.md +++ b/content/fr/docs/topics/chart_repository.md @@ -6,7 +6,7 @@ weight: 6 Cette section explique comment créer et travailler avec des dépôts de charts Helm. À un niveau élevé, un dépôt de charts est un emplacement où les charts emballés peuvent être stockés et partagés. -Le dépôt de charts Helm communautaire distribué est situé sur [Artifact Hub](https://artifacthub.io/packages/search?kind=0) et accueille la participation. Cependant, Helm permet également de créer et de gérer votre propre dépôt de charts. Ce guide explique comment procéder. +Le dépôt de charts Helm communautaire distribué est situé sur [Artifact Hub](https://artifacthub.io/packages/search?kind=0) et accueille la participation. Cependant, Helm permet également de créer et de gérer votre propre dépôt de charts. Ce guide explique comment procéder. Si vous envisagez de créer un dépôt de charts, vous pourriez envisager d'utiliser à la place un [registre OCI]({{< ref "../topics/registries" >}}). ## Prérequis diff --git a/content/fr/docs/topics/plugins.md b/content/fr/docs/topics/plugins.md index 723b475ac..529d484f4 100644 --- a/content/fr/docs/topics/plugins.md +++ b/content/fr/docs/topics/plugins.md @@ -26,7 +26,7 @@ Le modèle de plugin Helm est en partie inspiré du modèle de plugins de Git. ## Installer un Plugin -Les plugins sont installés en utilisant la commande `$ helm plugin install `. Vous pouvez spécifier un chemin vers un plugin sur votre système de fichiers local ou une URL d'un dépôt VCS distant. La commande `helm plugin install` clone ou copie le plugin au chemin/URL donné dans `$HELM_PLUGINS` +Les plugins sont installés en utilisant la commande `$ helm plugin install `. Vous pouvez spécifier un chemin vers un plugin sur votre système de fichiers local ou une URL d'un dépôt VCS distant. La commande `helm plugin install` clone ou copie le plugin au chemin/URL donné dans `$HELM_PLUGINS`. Si vous installez à partir d'un système de contrôle de version (VCS), vous pouvez spécifier la version à l'aide de l'argument `--version`. ```console $ helm plugin install https://github.com/adamreese/helm-env @@ -34,73 +34,191 @@ $ helm plugin install https://github.com/adamreese/helm-env Si vous avez une distribution de plugin au format tar, il suffit de décompresser le plugin dans le répertoire `$HELM_PLUGINS`. Vous pouvez également installer des plugins au format tarball directement depuis une URL en exécutant `helm plugin install https://domain/path/to/plugin.tar.gz`. -## Créer un Plugin +## Structure des fichiers du plugin -À bien des égards, un plugin est similaire à un chart. Chaque plugin a un répertoire de niveau supérieur, ainsi qu'un fichier `plugin.yaml`. +À bien des égards, un plugin est similaire à un chart. Chaque plugin possède un répertoire de niveau supérieur contenant un fichier `plugin.yaml`. Des fichiers supplémentaires peuvent être présents, mais seul le fichier `plugin.yaml` est requis. -``` +```console $HELM_PLUGINS/ |- last/ - | |- plugin.yaml - |- last.sh +``` + +## Fichier plugin.yaml +Le fichier `plugin.yaml` est requis pour un plugin. Il contient les champs suivants : + +```yaml +name: Le nom du plugin (REQUIS) +version: Une version SemVer 2 (REQUIS) +usage: Texte d'utilisation sur une seule ligne affiché dans l'aide +description: Description longue affichée dans des endroits comme `helm help` +ignoreFlags: Ignorer les arguments passés depuis Helm +platformCommand: # Configurer la commande à exécuter en fonction de la plateforme. + - os: Correspondance du système d'exploitation, peut être vide ou omis pour correspondre à tous les systèmes d'exploitation + arch: Correspondance de l'architecture, peut être vide ou omis pour correspondre à toutes les architectures + command: Plugin command to execute + args: Commande du plugin à exécuter +command: (DÉPRÉCIÉ) Commande du plugin, utilisez `platformCommand` à la place +platformHooks: # Configurer les hooks du cycle de vie du plugin en fonction de la plateforme +install: # Commandes du cycle de vie d'installation + - os: Correspondance du système d'exploitation, peut être vide ou omis pour correspondre à tous les systèmes d'exploitation + arch: Correspondance de l'architecture, peut être vide ou omis pour correspondre à toutes les architectures + command: Commande d'installation du plugin à exécuter + args: Arguments de la commande d'installation du plugin +update: # Commandes du cycle de vie de mise à jour + - os: Correspondance du système d'exploitation, peut être vide ou omis pour correspondre à tous les systèmes d'exploitation + arch: Correspondance de l'architecture, peut être vide ou omis pour correspondre à toutes les architectures + command: Commande de mise à jour du plugin à exécuter + args: Arguments de la commande de mise à jour du plugin +delete: # Commandes du cycle de vie de suppression + - os: Correspondance du système d'exploitation, peut être vide ou omis pour correspondre à tous les systèmes d'exploitation + arch: Correspondance de l'architecture, peut être vide ou omis pour correspondre à toutes les architectures + command: Commande de suppression du plugin à exécuter + args: Arguments de la commande de suppression du plugin +hooks: # (Déprécié) Hooks du cycle de vie du plugin, utilisez `platformHooks` à la place + install: Commande pour installer le plugin + update: Commande pour mettre à jour le plugin + delete: Commande pour supprimer le plugin +downloaders: # Configurer la capacité de téléchargement + - command: Commande à invoquer + protocols: + - Schéma de protocole pris en charge ``` -Dans l'exemple ci-dessus, le plugin `last` est contenu dans un répertoire nommé `last`. Il comprend deux fichiers : `plugin.yaml` (obligatoire) et un script exécutable, `last.sh` (optionnel). +### Le champ `name` + +Le champ `name` est le nom du plugin. Lorsque Helm exécute ce plugin, c'est ce nom qui sera utilisé (par exemple, `helm NAME` invoquera ce plugin). + +_Le `name` doit correspondre au nom du répertoire._ Dans notre exemple ci-dessus, cela signifie que le plugin avec `name: last` doit être contenu dans un répertoire nommé `last`. + +Restrictions sur `name` : + +- `name` ne peut pas dupliquer l'un des commandes principales existantes de `helm`. +- `name` doit être limité aux caractères ASCII a-z, A-Z, 0-9, `_` et `-`. + +### Le champ `version` + +Le champ `version` est la version SemVer 2 du plugin. `usage` et `description` sont utilisés pour générer le texte d'aide d'une commande. + +### Le champ `ignoreFlags` + +Le commutateur `ignoreFlags` indique à Helm de _ne pas_ passer les arguments au plugin. Ainsi, si un plugin est appelé avec `helm myplugin --foo` et que `ignoreFlags: true`, alors `--foo` sera silencieusement ignoré. + +### Le champ `platformCommand` + +Le champ `platformCommand` configure la commande que le plugin exécutera lorsqu'il est appelé. Vous ne pouvez pas définir à la fois `platformCommand` et `command`, cela entraînera une erreur. Les règles suivantes s'appliquent pour décider quelle commande utiliser : + +- Si `platformCommand` est présent, il sera utilisé. + - Si `os` et `arch` correspondent à la plateforme actuelle, la recherche s'arrête et la commande sera utilisée. + - Si `os` correspond et que `arch` est vide, la commande sera utilisée. + - Si `os` et `arch` sont tous deux vides, la commande sera utilisée. + - S'il n'y a pas de correspondance, Helm quittera avec une erreur. +- Si `platformCommand` n'est pas présent et que l'ancien `command` est présent, celui-ci sera utilisé. + - Si la commande est vide, Helm quittera avec une erreur. + +### Le champ `platformHooks` -Le cœur d'un plugin est un simple fichier YAML nommé `plugin.yaml`. Voici un exemple de YAML pour un plugin qui aide à obtenir le nom de la dernière release : +Le champ `platformHooks` configure les commandes que le plugin exécutera pour les événements du cycle de vie. Vous ne pouvez pas définir à la fois `platformHooks` et `hooks`, cela entraînera une erreur. Les règles suivantes s'appliquent pour décider quelle commande de hook utiliser : + +- Si `platformHooks` est présent, il sera utilisé et les commandes pour l'événement du cycle de vie seront traitées. + - Si `os` et `arch` correspondent à la plateforme actuelle, la recherche s'arrête et la commande sera utilisée. + - Si `os` correspond et que `arch` est vide, la commande sera utilisée. + - Si `os` et `arch` sont tous deux vides, la commande sera utilisée. + - S'il n'y a pas de correspondance, Helm ignorera l'événement. +- Si `platformHooks` n'est pas présent et que l'ancien `hooks` est présent, la commande pour l'événement du cycle de vie sera utilisée. + - Si la commande est vide, Helm ignorera l'événement. + +## Créer un Plugin + +Voici le plugin YAML pour un plugin simple qui permet d'obtenir le nom de la dernière version : ```yaml -name: "last" -version: "0.1.0" -usage: "obtenir le nom de la dernière release" -description: "obtenir le nom de la dernière release" +name: last +version: 0.1.0 +usage: get the last release name +description: get the last release name ignoreFlags: false -command: "$HELM_BIN --host $TILLER_HOST list --short --max 1 --date -r" platformCommand: - - os: linux - arch: i386 - command: "$HELM_BIN list --short --max 1 --date -r" - - os: linux - arch: amd64 - command: "$HELM_BIN list --short --max 1 --date -r" + - command: ${HELM_BIN} + args: + - list + - --short + - --max=1 + - --date + - -r +``` + +Les plugins peuvent nécessiter des scripts et des exécutables supplémentaires. Les scripts peuvent être inclus dans le répertoire du plugin et les exécutables peuvent être téléchargés via un hook. Voici un exemple de plugin : + +```console +$HELM_PLUGINS/ + |- monplugin/ + |- scripts/ + |- install.ps1 + |- install.sh + |- plugin.yaml +``` + +```yaml +name: monplugin +version: 0.1.0 +usage: plugin exemple +description: plugin exemple +ignoreFlags: false +platformCommand: + - command: ${HELM_PLUGIN_DIR}/bin/monplugin - os: windows - arch: amd64 - command: "$HELM_BIN list --short --max 1 --date -r" + command: ${HELM_PLUGIN_DIR}\bin\monplugin.exe +platformHooks: + install: + - command: ${HELM_PLUGIN_DIR}/scripts/install.sh + - os: windows + command: pwsh + args: + - -c + - ${HELM_PLUGIN_DIR}\scripts\install.ps1 + update: + - command: ${HELM_PLUGIN_DIR}/scripts/install.sh + args: + - -u + - os: windows + command: pwsh + args: + - -c + - ${HELM_PLUGIN_DIR}\scripts\install.ps1 + - -Update ``` -Le `name` est le nom du plugin. Lorsque Helm exécute ce plugin, c'est ce nom qu'il utilisera (par exemple, `helm NAME` invoquera ce plugin). +Les variables d'environnement sont interpolées avant l'exécution du plugin. Le modèle ci-dessus illustre la méthode préférée pour indiquer l'emplacement du programme du plugin. -_Le `name` doit correspondre au nom du répertoire._ Dans notre exemple, cela signifie que le plugin avec `name: last` doit être contenu dans un répertoire nommé `last`. +### Commandes du plugin -Restrictions sur le `name` : +Il existe plusieurs stratégies pour travailler avec les commandes de plugin : -- `name` ne peut pas dupliquer l'un des commandes de niveau supérieur existantes de `helm`. -- `name` doit être limité aux caractères ASCII a-z, A-Z, 0-9, `_` et `-`. +- Si un plugin inclut un exécutable, l'exécutable pour un `platformCommand:` ou doit être empaqueté dans le répertoire du plugin ou installé via un hook. +- La ligne `platformCommand:` ou `command:` aura toutes les variables d'environnement étendues avant l'exécution. `$HELM_PLUGIN_DIR` pointera vers le répertoire du plugin. +- La commande elle-même n'est pas exécutée dans un shell. Vous ne pouvez donc pas écrire un script shell sur une seule ligne. +- Helm injecte beaucoup de configurations dans les variables d'environnement. Jetez un œil à l'environnement pour voir quelles informations sont disponibles. +- Helm ne fait aucune restriction sur le langage du plugin. Vous pouvez l'écrire dans le langage de votre choix. +- Les commandes sont responsables de l'implémentation du texte d'aide spécifique pour `-h` et `--help`. Helm utilisera `usage` et `description` pour `helm help` et `helm help monplugin`, mais ne gérera pas `helm monplugin --help`. -`version` est la version SemVer 2 du plugin. `usage` et `description` sont utilisés pour générer le texte d'aide d'une commande. +### Tester un plugin local -Le switch `ignoreFlags` indique à Helm de _ne pas_ passer les options au plugin. Ainsi, si un plugin est appelé avec `helm myplugin --foo` et que `ignoreFlags: true` est défini, alors `--foo` sera silencieusement ignoré. +Tout d'abord, vous devez trouver le chemin de votre `HELM_PLUGINS`. Pour ce faire, exécutez la commande suivante : -Enfin, et surtout, `platformCommand` ou `command` est la commande que ce plugin exécutera lorsqu'il sera appelé. La section `platformCommand` définit les variations spécifiques au système d'exploitation/architecture d'une commande. Les règles suivantes s'appliquent pour décider quelle commande utiliser : +```bash +helm env +``` -- Si `platformCommand` est présent, il sera recherché en premier. -- Si à la fois `os` et `arch` correspondent à la plateforme actuelle, la recherche s'arrêtera et la commande sera utilisée. -- Si `os` correspond et qu'il n'y a pas de correspondance plus spécifique pour `arch`, la commande sera utilisée. -- Si aucune correspondance dans `platformCommand` n'est trouvée, la commande par défaut `command` sera utilisée. -- Si aucune correspondance n'est trouvée dans `platformCommand` et qu'aucun `command` n'est présent, Helm quittera avec une erreur. +Changez votre répertoire actuel pour celui qui est défini dans `HELM_PLUGINS`. -Les variables d'environnement sont interpolées avant l'exécution du plugin. Le modèle ci-dessus illustre la manière préférée d'indiquer où se trouve le programme du plugin. +Maintenant, vous pouvez ajouter un lien symbolique vers le répertoire de sortie de votre plugin. Dans cet exemple, nous l'avons fait pour `mapkubeapis` : -Il existe plusieurs stratégies pour travailler avec les commandes de plugins : +```bash +ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis +``` -- Si un plugin inclut un exécutable, l'exécutable pour un `platformCommand:` ou un `command:` doit être emballé dans le répertoire du plugin. -- La ligne `platformCommand:` ou `command:` aura toutes les variables d'environnement développées avant l'exécution. `$HELM_PLUGIN_DIR` pointera vers le répertoire du plugin. -- La commande elle-même n'est pas exécutée dans un shell. Vous ne pouvez donc pas enchaîner un script shell en une seule ligne. -- Helm injecte beaucoup de configuration dans les variables d'environnement. Consultez l'environnement pour voir quelles informations sont disponibles. -- Helm ne fait aucune restriction sur le langage du plugin. Vous pouvez l'écrire dans le langage de votre choix. -- Les commandes sont responsables de la mise en œuvre du texte d'aide spécifique pour `-h` et `--help`. Helm utilisera `usage` et `description` pour `helm help` et `helm help myplugin`, mais ne gérera pas `helm myplugin --help`. ## Plugins de Téléchargement Par défaut, Helm est capable de récupérer des Charts via HTTP/S. À partir de Helm 2.4.0, les plugins peuvent avoir une capacité spéciale pour télécharger des Charts depuis des sources arbitraires. diff --git a/content/fr/docs/topics/version_skew.md b/content/fr/docs/topics/version_skew.md index 9637359ed..ff24c70c2 100644 --- a/content/fr/docs/topics/version_skew.md +++ b/content/fr/docs/topics/version_skew.md @@ -27,6 +27,8 @@ Veuillez consulter le tableau ci-dessous pour déterminer quelle version de Helm | Version d'Helm | Versions de Kubernetes supportées | |----------------|-----------------------------------| +| 3.16.x | 1.31.x - 1.28.x | +| 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x |