HelmOps

HelmOps est une manière simplifiée de créer des bundles en pointant directement vers un dépôt Helm ou un registre OCI, sans avoir besoin de configurer un dépôt git.

Résumé

Lorsqu’une ressource GitRepo est créée, SUSE® Rancher Prime Continuous Delivery surveille un dépôt git, créant un ou plusieurs bundles à partir des chemins spécifiés dans le GitRepo, suivant une approche GitOps, ou pilotée par git, pour le déploiement continu. Cela nécessite qu’un dépôt git soit disponible, contenant éventuellement fleet.yaml ou d’autres fichiers de configuration.

HelmOps, en revanche, s’appuie sur un registre Helm comme source de vérité, tout comme GitOps utilise un dépôt git. L’utilisation de HelmOps se fait en créant une ressource HelmOp, avec des options similaires à celles disponibles dans une ressource GitRepo et/ou dans un fichier fleet.yaml pour cibler des bundles vers des clusters, configurer des valeurs de chart, etc.

HelmOps est le concept. Une ressource HelmOp est une ressource Kubernetes personnalisée gérée par SUSE® Rancher Prime Continuous Delivery.

Le contrôleur Fleet HelmOps créera des bundles légers, pointant vers des charts Helm référencés, sans les télécharger. Cependant, il résoudra les versions de chart pour s’assurer que la même version, et la plus récente, d’un chart est déployée sur tous les clusters en aval ciblés. Cela s’applique aux cas suivants :

Lorsque les contraintes sont invalides ou qu’aucune version correspondante ne peut être trouvée, SUSE® Rancher Prime Continuous Delivery affiche un message d’erreur descriptif.

Lors de l’utilisation de cette fonctionnalité, les charts Helm sont téléchargés depuis les clusters en aval, qui doivent donc avoir accès aux registres Helm.

Création d’une ressource HelmOp

Une ressource HelmOp peut être créée comme suit pour commencer à déployer des charts Helm directement :

apiVersion: fleet.cattle.io/v1alpha1
kind: HelmOp
metadata:
name: my-awesome-helmop
namespace: "fleet-local"
spec:
helm:
releaseName: my-fantastic-chart
repo: [https://foo.bar/baz](https://foo.bar/baz)
chart: fantastic-chart
version: ''
namespace: that-amazing-namespace
helmSecretName: my-top-secret-helm-access
insecureSkipTLSVerify: false

Pour les charts privés, cela nécessite qu’un secret d’accès Helm (référencé par le champ helmSecretName) soit créé dans le même espace de noms que la ressource HelmOp. Le contrôleur Fleet HelmOps s’occupe de copier ce secret vers les clusters en aval ciblés, permettant à l’agent Fleet d’accéder au registre.

Cas d’utilisation pris en charge

Avec 3 champs disponibles pour référencer un chart Helm, clarifions quelques règles. Selon la documentation d’installation de Helm documentation, il existe 6 façons d’exprimer un chart à installer. 3 d’entre elles utilisent soit des alias du dépôt, soit le système de fichiers local, qui ne sont pas disponibles dans le contexte HelmOps de Fleet. Cela nous laisse avec 3 options :

URL absolue

Référencer un chart Helm par URL absolue est aussi simple que de fournir une URL vers un fichier .tgz dans le champ chart. Les options Helm ressembleraient à :

helm:
chart: [https://example.com/charts/my-chart-1.2.3.tgz](https://example.com/charts/my-chart-1.2.3.tgz)
# can be omitted

repo: ''
version: ''

Si un dépôt non vide ou une version non vide est spécifiée dans ce cas, une erreur apparaîtra dans le statut HelmOp et aucun bundle ne sera créé, annulant le déploiement.

Référence de chart et URL de dépôt

Un chart Helm peut également être référencé par son nom de dépôt et de chart, avec une version optionnelle, qui peut être une version statique ou une contrainte de version.

Dans ce cas, le polling peut avoir du sens, car référencer le chart en utilisant un dépôt permet à SUSE® Rancher Prime Continuous Delivery de vérifier l'index.yaml du dépôt pour les versions disponibles correspondant au champ version.

Exemple :

helm:
repo: [https://foo.bar/baz](https://foo.bar/baz)
chart: fantastic-chart
version: '1.2.3'

Dans ce cas, seul le champ version peut être vide. Si l’un des champs chart ou repo est vide, SUSE® Rancher Prime Continuous Delivery définit une erreur dans le statut HelmOp et aucun bundle ne sera créé.

Registre OCI

Helm prend en charge les registres OCI, qui peuvent être référencés dans SUSE® Rancher Prime Continuous Delivery en utilisant le champ repo.

Dans ce cas, les options Helm seraient similaires à ceci :

helm:
repo: oci://foo.bar/baz
version: '1.2.3' # optional

Lorsqu’une URL OCI est fournie dans le champ repo, un champ chart non vide entraînera une erreur dans le statut HelmOps, et aucun bundle ne sera créé.

Dans ce cas, SUSE® Rancher Prime Continuous Delivery téléchargera des artefacts OCI. Cela signifie que :

  • Le champ version représente le tag d’un artefact OCI, qui peut être différent de la version réelle du chart stockée dans l’artefact OCI.

  • SUSE® Rancher Prime Continuous Delivery peut vérifier les balises OCI disponibles correspondant à la fois au dépôt fourni et à la contrainte de version sur une base régulière, configurée via l’intervalle de sondage.

  • Un artefact OCI peut contenir plusieurs charts Helm. Ce cas d’utilisation n’a été validé qu’avec des artefacts OCI contenant un seul chart Helm.

Interrogation

SUSE® Rancher Prime Continuous Delivery peut interroger le registre Helm référencé, vérifiant périodiquement si de nouvelles versions sont disponibles. Bien sûr, cela n’a de sens que si le champ version contient une contrainte de version, qui peut se résoudre à plusieurs versions.

Comment l’activer

Le sondage implique un champ pollingInterval, similaire à ce qui existe pour GitOps. Cependant, dans le cas de HelmOps, l’intervalle de sondage par défaut est de 0 secondes, ce qui signifie que le sondage sera désactivé.

Les conditions suivantes doivent être remplies sur une ressource HelmOp pour que SUSE® Rancher Prime Continuous Delivery puisse activer le sondage dessus :

  • Le champ pollingInterval est défini sur une durée non nulle (par exemple 10s, 1m, etc.)

  • Le champ version est défini sur une contrainte de version sémantique valide (par exemple 2.x.x, < 1.0), pas une version statique (par exemple 1.2.3)

Fonction

Lorsque le sondage est activé, SUSE® Rancher Prime Continuous Delivery effectue les actions suivantes à l’intervalle configuré :

  • vérifiant le registre Helm référencé pour la dernière version correspondant à la contrainte de version configurée dans le champ version

  • si une nouvelle version est trouvée, définissant cette version sur le Bundle créé à partir de l’objet HelmOp, de sorte que la nouvelle version du chart sera installée sur tous les clusters ciblés.

  • mettant à jour le statut de la ressource HelmOp :

    • définissant sa condition Polled :

      • avec true si le sondage a réussi

      • avec false avec une erreur si un échec s’est produit

    • mettant à jour le champ Last Polling Time à l’heure de début de la dernière tentative de sondage, même si elle a échoué.

Utilisation de dépôts Helm privés

Cela fonctionne de la même manière que pour gitOps, en référencant un secret d’accès Helm à travers le champ helmSecretName.

Pour plus d’informations, référez-vous à Private Helm repo.

La partie sur l’utilisation de credentials séparés pour chaque chemin n’est pas pertinente, car contrairement à un GitRepo, une ressource HelmOp ne fait référence qu’à un seul chart Helm.

Mises à jour de statut

La création d’une ressource HelmOp entraîne la création d’un bundle, si les options Helm sont valides et qu’une version de chart peut être trouvée.

Le statut de ce bundle évoluera au fil du temps, à mesure que des déploiements de bundle seront créés à partir de celui-ci, pour chaque cluster cible, et que les statuts de ces déploiements de bundle évolueront et seront propagés au bundle.

SUSE® Rancher Prime Continuous Delivery propage les mises à jour du statut du bundle au statut de la ressource HelmOp elle-même. Ces ressources sont les suivantes :

  • Un statut d’affichage avec un résumé, des comptes de clusters attendus et prêts

  • Conditions fournissant plus d’informations sur l’état de la ressource, qu’elle soit valide et que ses déploiements soient prêts

  • Comptes de ressources par statut

Référez-vous à Status fields pour plus de détails sur les comptes de ressources et les conditions.