GitLab en tant que registre Helm Chart avec GitLab CI

Graphique Helm Kubernetes

Les graphiques sont le format d’emballage utilisé par Helm. Un graphique est un groupe de fichiers qui répertorie plusieurs ressources Kubernetes liées les unes aux autres. Un graphique peut être utilisé pour déployer un module simple, quelque chose de simple ou une architecture d’application Web complète, y compris des serveurs HTTP, des bases de données, des caches et d’autres composants divers.

Conditions préalables

Compréhension de Kubernetes et de la configuration de Kubernetes sur votre machine.
Compréhension de base de Helm et installé sur votre machine.
Compte GitLab.

Configurer GitLab en tant que registre Helm Chart

Création d’un graphique Helm

Dans cet article, un graphique Helm sera créé, envoyé au projet GitLab, empaqueté et mis à disposition sur le registre de packages GitLab, que nous pourrons utiliser ultérieurement pour l’installer sur nos clusters Kubernetes.

Tout d’abord, créons un projet sur GitLab, où vous stockerez les modèles du graphique.

Maintenant, créons un graphique localement. Pour créer le graphique Helm, exécutez la commande suivante :

Note: Assurez-vous d’avoir déjà installé Helm sur votre machine ou installez-le.

Cette commande créera un répertoire de graphique avec certains fichiers et répertoires généraux communs qui seront utilisés dans un graphique. Par exemple, notre graphique de démonstration a la structure de projet suivante sous le nom de répertoire demo-chart/:

.
├── charts
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── serviceaccount.yaml
│   ├── service.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

3 directories, 10 files

Poussons maintenant vers le helm-chart-demo dépôt du projet sur GitLab :

$ cd demo-chart
$ git init --initial-branch=main
$ git remote add origin git@gitlab.com:<username>/helm-chart-demo.git

Ici, vous pouvez utiliser l’URL HTTPS si vous n’avez pas encore configuré SSH. Maintenant, validez et transférez les modifications :

$ git add .
$ git commit -m "demo-chart first commit"

[main (root-commit) 506893a] demo-chart first commit
 11 files changed, 405 insertions(+)
 create mode 100644 .helmignore
 create mode 100644 Chart.yaml
 create mode 100644 templates/NOTES.txt
 create mode 100644 templates/_helpers.tpl
 create mode 100644 templates/deployment.yaml
 create mode 100644 templates/hpa.yaml
 create mode 100644 templates/ingress.yaml
 create mode 100644 templates/service.yaml
 create mode 100644 templates/serviceaccount.yaml
 create mode 100644 templates/tests/test-connection.yaml
 create mode 100644 values.yaml

$ git push origin main

Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
Delta compression using up to 8 threads
Compressing objects: 100% (14/14), done.
Writing objects: 100% (15/15), 5.47 KiB | 1.82 MiB/s, done.
Total 15 (delta 0), reused 0 (delta 0), pack-reused 0
To gitlab.com:sbmagar/helm-chart-demo.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

Maintenant, créez ce référentiel que nous venons de pousser en tant que graphique Helm afin que nous puissions le stocker dans le registre de packages GitLab.

Pour ce faire, vous pouvez utiliser le terminal de commande local ou le CI GitLab fourni par GitLab. Il est recommandé d’utiliser GitLab CI pour empaqueter et pousser vos Helm Charts au lieu de la ligne de commande de votre ordinateur.

Créons le pipeline CI GitLab :

Création du pipeline CI GitLab

Tout d’abord, activez le « Paquets” bouton de Paramètres > Général > Visibilité, fonctionnalités du projet, autorisations :

Vous pouvez configurer la configuration GitLab CI à partir de CI/CD > Éditeur > Configurer le pipeline (ou vous pouvez créer manuellement .gitlab-ci.yml fichier et configurez-vous localement, puis poussez-le vers le référentiel.):

Maintenant, remplacez le contenu du .gitlab-ci.yml fichier avec les éléments suivants :

stages:
  - helm-chart-publish

helm-package-publish:
  stage: helm-chart-publish
  image:
    name: alpine/helm:3.10.1
    entrypoint: [""]
  tags: 
    - kubernetes
  variables:
    CHART: demo-chart
  before_script:
    - apk add git
    - helm plugin install --version=v0.10.3 <https://github.com/chartmuseum/helm-push.git>
    - >
      helm repo add ${CHART}
      --username ${CI_REGISTRY_USER}
      --password ${CI_REGISTRY_PASSWORD}
      ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/helm/stable
  script:
    - helm package ${CHART}
    - helm cm-push ${CHART}*.tgz ${CHART}
  only:
    refs:
      - main
    changes:
      - demo-chart/**/*

Ici, comprenons-le un par un:

stages:
  - helm-chart-publish

C’est un nom de scène appelé helm-chart-publishqui sera utilisé dans le helm-package-publish emploi:

helm-package-publish:
  stage: helm-chart-publish
  image:
    name: alpine/helm:3.10.1
    entrypoint: [""]
  tags: 
    - kubernetes
  variables:
    CHART: demo-chart

En cela, un travail helm-package-publish est défini avec une image de conteneur et des variables requises pour notre projet de démonstration. La variable est juste pour simplifier notre code, car elle sera utilisée plusieurs fois. Et le tags le mot clé est pour les gitlab-runners. Dans mon cas, j’utilise un gitlab-runner auto-hébergé avec le nom de la balise kubernetes.

Note: Vous devez utiliser d’autres balises en fonction de votre configuration gitlab-runner :

before_script:
  - apk add git
  - helm plugin install --version=v0.10.3 <https://github.com/chartmuseum/helm-push.git>
  - >
    helm repo add ${CHART}
    --username ${CI_REGISTRY_USER}
    --password ${CI_REGISTRY_PASSWORD}
    ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/helm/stable

Ici, dans ce before_script section, nous installons certaines dépendances comme git (qui sera à l’intérieur de notre image de conteneur) et helm-push plugin par chartmuseaum. Également helm repo add commande qui ajoutera le référentiel Helm dans le shell de notre gitlab-runner afin que nous puissions l’authentifier à partir du runner.

Le CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_API_V4_URLet CI_PROJECT_ID les variables sont des variables prédéfinies spécifiques au CI/CD de GitLab :

CI_REGISTRY_USER: Il s’agit du nom d’utilisateur pour pousser les conteneurs/graphiques vers le registre de conteneurs/paquets GitLab du projet. Uniquement disponible si le registre de conteneurs/packages est activé pour le projet.
CI_REGISTRY_PASSWORD: Il s’agit du mot de passe pour pousser les conteneurs/helm-charts vers le registre de conteneurs/paquets GitLab du projet. Uniquement disponible si le registre de conteneurs/packages est activé pour le projet.
CI_API_V4_URL: L’URL racine de l’API GitLab v4.
CI_PROJECT_ID: L’ID du projet en cours. Cet ID est unique pour tous les projets de l’instance GitLab.

Vous pouvez vérifier ici les variables prédéfinies pour GitLab CI/CD.

script:
  - helm package ${CHART}
  - helm cm-push ${CHART}*.tgz ${CHART}

Dans ce script , nous allons créer un package Helm et le pousser vers le registre de packages GitLab. Le helm package La commande regroupe un graphique dans un fichier d’archive de graphique versionné, et la helm cm-push command charge un graphique dans un registre :

only:
  refs:
    - main
  changes:
    - demo-chart/**/*

Enfin, la tâche GitLab est déclenchée. Si un commit est fait pour le main branche, l’emploi sera créé en raison de la only.refs mot-clé. Quand le only.changes est utilisé, une tâche est créée et lancée chaque fois que des fichiers du répertoire demo-chart sont modifiés.

Exécution du pipeline CI

Nous avons créé notre fichier de configuration de pipeline CI. Maintenant, il est temps d’exécuter notre pipeline. Pour déclencher cela, apportons quelques modifications à n’importe quel fichier de notre répertoire demo-chart. Pour cela changeons de version dans le Chart.yaml déposer:

Validez les modifications et accédez à « IC/CD« , pour voir l’état du travail :

Et enfin, vérifiez le package Helm dans le registre GitLab à partir de Packages et registres > Registre de packages:

Conclusion

Dans cet article, vous avez appris à créer une charte Helm et à la stocker dans le registre GitLab en tant que référentiel de chartes Helm. En d’autres termes, vous avez appris à utiliser GitLab comme registre de chartes Helm, afin de pouvoir stocker, partager et utiliser des chartes Helm.

Joyeux Helming !