Cet article a été réalisé avec la version 0.3.1 de Kargo.
Introduction#
Je vous avais présenté le mois dernier Flamingo qui combine à la fois Argo CD et Flux CD pour tirer parti de ces deux outils et adopter une approche GitOps.
Néanmoins, le GitOps ou les outils ci-dessus ne définissent pas de moyen pour promouvoir les changements qui ont été apportés d’un environnement de développement à un environnement de qualification ou de production.
En effet, Argo CD et Flux CD se chargent de déployer un ou plusieurs environnements cibles sans aucun lien, ni relation entre eux.
Il est toutefois possible d’adopter un Branching Model pour promouvoir ces changements. Si ce terme ne vous parle pas, je vous recommande de consulter cet article.
Heureusement, une solution est apparue il y a quelques mois, même si cette dernière est encore en phase de développement et donc, pas encore prêt pour être utilisée en production, je vous propose dans cet article un tour d’horizon du potentiel de cet outil.
Kargo, la solution#
Qui n’a jamais rêvé d’appuyer sur un bouton pour porter les modifications d’un environnement à un autre ? L’exemple le plus classique est une nouvelle image de conteneur que l’on teste sur un environnement de développement avant de la déployer sur un environnement de qualification.
C’est exactement ce que permet de faire Kargo, même si ce dernier permet d’aller encore plus loin que la gestion de version des images, il est capable d’appliquer les différences de configurations de vos objets Kubernetes.
De plus, Kargo fait partie de l’Argo Project (la même famille qu’Argo CD) et est un outil 100% open source.
De manière synthétique, Kargo est une plateforme de livraison continue qui permet d’orchestrer le cycle de vie des applications sur Kubernetes d’un environnement à l’autre en s’appuyant sur des outils existants.
Eh oui, Kargo travaille en lien direct avec Argo CD où ce dernier s’occupe de ce qu’il sait faire le mieux : déployer les objets Kubernetes.
Fonctionnalités#
Bien que Kargo soit un outil encore très jeune, il est doté de plusieurs fonctionnalités :
- Promotion de configurations ou d’images conteneurisées d’un environnement à l’autre ;
- Écriture des changements dans Git : Dès qu’un changement est approuvé, Kargo se charge de générer une Pull Request et commit les modifications ;
- Possibilité d’effectuer des retours en arrière en cas d’erreur ;
- Création de tests pour valider le bon fonctionnement d’un environnement notamment avec Argo Rollouts ;
- Le Canary et l’A/B testing peuvent être utilisés pour déployer sur un environnement cible.
Cette liste est sujette à évoluer dans les futures version de Kargo. En effet, l’équipe a pour objectif de faire grandir le produit dans des versions futures jusqu’à atteindre une première version majeure (1.0.0) afin de susciter l’adoption de Kargo dans des environnements de production.
Kargo dispose d’une interface utilisateur qui permet de suivre les changements en un coup d’oeil :
Cette interface permet aussi de visualiser les images ou configurations associées aux environnements définis. Ce qui permet notamment d’avoir un historique et d’auditer l’ensemble des actions au sein de Kargo.
Enfin, la grande barre noire du haut s’appelle la ligne de fret (Freight) comme pour le transport de marchandise. Vous avez compris le rapport avec Kargo maintenant, non ?
Fonctionnement#
C’est le moment de discuter du fonctionnement de Kargo et comment ce dernier opère la gestion des environnements notamment dès lors qu’une nouvelle version d’image est disponible.
Voici le déroulement des opérations dans l’ordre :
- La CI, quelle que soit la plateforme, crée une nouvelle image de conteneur ;
- Cette dernière est déposée dans un registre de conteneurs ;
- En fonction des configurations définies, Kargo vient analyser le dépôt Git contenant les objets Kubernetes (1) et recherche les potentielles nouvelles images (2) associées ;
- En fonction des nouvelles images récupérées, le développeur a le choix de promouvoir ou non ces changements sur le premier environnement configuré, qui sera développement dans ce cas-ci ;
- Une fois la validation du développeur, Kargo pousse les modifications dans Git ;
- Avec l’action précédente, Argo CD se déclenche et détecte une mise à jour des fichiers de l’environnement de développement ;
- Argo CD synchronise les changements sur le cluster Kubernetes ;
- Kargo récupère l’état des objets déployés et permet d’effectuer des tests ;
- Si tout est bon, le développeur a la possibilité d’approuver les changements pour l’environnement suivant.
Du côté de l’installation, Kargo se déploie de préférence avec un chart Helm et il est recommandé de le disposer au plus proche d’Argo CD car il est en interaction directe avec ce dernier.
Vous l’aurez compris, Kargo permet de chaîner un ou plusieurs environnements en fonction de votre cycle de déploiement. Ces environnements sont matérialisés en objet Kubernetes du nom de Stage :
apiVersion: v1
kind: Namespace
metadata:
name: kargo-demo
labels:
kargo.akuity.io/project: "true"
---
apiVersion: kargo.akuity.io/v1alpha1
kind: Warehouse
metadata:
name: docker-registry
namespace: kargo-demo
spec:
subscriptions:
- image:
repoURL: nginx
semverConstraint: ^1.24.0
---
apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
name: dev
namespace: kargo-demo
spec:
subscriptions:
warehouse: docker-registry
promotionMechanisms:
gitRepoUpdates:
- repoURL: ${GITOPS_REPO_URL}
writeBranch: main
kustomize:
images:
- image: nginx
path: overlays/dev
argoCDAppUpdates:
- appName: nginx-dev
appNamespace: argocd
Voici un exemple pour générer un environnement de dev au sein de Kargo. Celui-ci est composé de plusieurs dossiers Kustomize base, overlays/dev, overlays/uat et overlays/prod pour référencer les configurations propres à chaque environnements. À savoir que ce dépôt de code déploie un simple Deployment contenant une image nginx.
Si vous souhaitez reproduire ça chez vous, je vous conseille d’utiliser sur cet exemple qui fournit la démarche à suivre pour tester Kargo.
J’ai fait quelques petites modifications par rapport à la version de base. En effet, plutôt que de créer une branche pour chaque environnement, j’utilise la branche principale avec le paramètre writeBranch: main.
Comme vous pouvez le constater, l’environnement dev écoute sur un objet Warehouse docker-regitry qui récupère les nouvelles images nginx en suivant la contrainte semver associée (^1.24.0). Par ailleurs, le bloc argoCDAppUpdates fait la jonction avec Argo CD qui orchestre le déploiement une fois les changements approuvés.
À noter que la création d’un Namespace avec le label kargo.akuity.io/project: "true" est indispensable pour référencer le projet kargo-demo au sein de l’outil.
Je vous ai présenté le lien entre un registre d’images et un environnement de développement. Évidemment, il est possible d’aller plus loin et d’ajouter des environnements à la suite de cette manière, toujours sous forme de stages.
apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
name: uat
namespace: kargo-demo
spec:
subscriptions:
upstreamStages:
- name: dev
promotionMechanisms:
gitRepoUpdates:
- repoURL: ${GITOPS_REPO_URL}
writeBranch: main
kustomize:
images:
- image: nginx
path: overlays/uat
argoCDAppUpdates:
- appName: nginx-uat
appNamespace: argocd
---
apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
name: prod
namespace: kargo-demo
spec:
subscriptions:
upstreamStages:
- name: uat
promotionMechanisms:
gitRepoUpdates:
- repoURL: ${GITOPS_REPO_URL}
writeBranch: main
kustomize:
images:
- image: nginx
path: overlays/prod
argoCDAppUpdates:
- appName: nginx-prod
appNamespace: argocd
Voici à quoi devrait ressembler votre pipeline Kargo :
Le mécanisme de promotion peut s’effectuer directement depuis l’interface ou en ligne de commande :
Comme dit plus haut, la promotion viendra effectuer un commit directement dans votre dépôt de code et aura comme effet de déclencher le déploiement au sein d’Argo CD :
Il est totalement possible de poursuivre et de mettre à jour les environnements suivants en effectuant les mêmes étapes pour uat et prod.
Pour finir, Kargo permet de travailler avec plusieurs types de sources au sein de l’objet Warehouse, c’est le cas des registres d’images, dépôt de code Git ou encore des registres de charts Helm.
Quelques mots pour conclure#
Plutôt que de bidouiller une chaîne CI/CD à base de diff et de sed pour promovoir vos changements, Kargo apporte avec lui un manque souvent exprimé quand on parle d’outils GitOps : l’orchestration entre environnements.
Encore une fois, Kargo est encore très jeune, mais je trouve personnellement qu’il a un grand potentiel. Quitte à être, plus tard, indispensable avec toute installation d’Argo CD.
N’hésitez pas à suivre les versions et mises à jour de Kargo sur le GitHub.