Retour aux articles

Home >> Blog >> Approche GitOps avec Flamingo, le meilleur des deux mondes

DevOps

Approche GitOps avec Flamingo, le meilleur des deux mondes

30 novembre 2023

Par Romain Boulanger.

Introduction

Dès lors que l’on parle de déploiement dans Kubernetes, il est difficile de ne pas parler de GitOps. En effet, cette pratique a tendance à se standardiser et à devenir l’approche la plus utilisée.

Pour présenter ce concept très rapidement, Git contiendra nos fichiers de déploiement (charts Helm, fichiers Kustomize, fichiers YAML, etc.) et le contenu de ce dépôt de code sera synchronisé grâce à un outil installé au préalable dans le cluster. Vous l’aurez compris, Git deviendra la source de vérité de l’état désiré de nos objets.

Un autre avantage très lié à Git est l’aspect lisibilité où tout est tracé avec des commits au sein du gestionnaire de sources ce qui permet de valider grâce à des Merge Requests ou Pull Requests de nouveaux composants ou des mises à jour.

Enfin, si vous désirez en savoir plus sur le GitOps, n’hésitez pas à consulter ces articles :

Quel outil choisir ?

Si l’on regarde d’un peu plus près, deux outils sont particulièrement utilisés : Argo CD et Flux CD. ils sont d’ailleurs tous les deux référencés par la Cloud Native Computing Foundation (CNCF) au statut Graduated grâce à leur maturité et leur utilisation dans des contextes de production.

Ces deux outils bien que similaires dans leur approche GitOps, ont tout de même quelques différences.

Au niveau de la synchronisation, Argo CD dispose d’un fonctionnement par défaut manuel où il est nécessaire d’avoir une action de l’utilisateur pour déclencher cette action tandis que Flux CD est totalement automatique par défaut.

De manière générale, on utilisera un système de Merge/Pull requests en synchronisant uniquement la branche principale.

Pour la réconciliation en cas de dérive, Argo CD propose certaines options qui sont optionnelles, tandis que Flux CD utilise une boucle de réconciliation totalement automatique sans aucun paramétrage notamment sur du Kustomize.

De manière plus pratique, il est possible de sélectionner les ressources à synchroniser avec Argo CD tandis que Flux CD prendra l’ensemble du contenu du dépôt de code.

Lors d’un retour en arrière, les comportements sont différents, notamment sur des charts Helm. Flux CD grâce à ses contrôleurs peut revenir à une version antérieure d’un chart tandis qu’Argo CD, qui applique le contenu de la commande helm template, utilisera un numéro de commit pour revenir sur une version antérieure.

Dernier point à ne pas négliger : la gestion des permissions. Flux CD utilise la couche native des contrôles d’accès à base de rôles (RBAC) de Kubernetes alors qu’Argo CD intègre un système qui lui est propre, sous forme de ConfigMap avec défnition de groupes, rôles et permissions.

Nous verrons un peu plus tard les atouts principaux des deux outils mais l’idée est de comparer plusieurs points essentiels.

Flamingo, l’union des deux mondes

Pourquoi choisir quand on peut avoir les deux ? C’est ce que propose Flamingo qui est sponsorisé par Weaveworks tout en restant totalement open source.

Flamingo reprend les forces d’Argo CD :

  • Une Interface utilisateur épurée permettant de visualiser les ressources déployées. Cette dernière peut être vue comme une tour de contrôle pour piloter l’ensemble des déploiements ;

  • Les Custom Resource Definitions (CRDs) comme les AppProject, Application et ApplicationSet qui permettent d’isoler et déployer nos ressources avec un large panel de configuration et d’options.

Mais aussi avec la performance du moteur de réconciliation de Flux CD qui se base sur des controlleurs. Que ce soit pour du Helm, du Kustomize mais aussi pourquoi pas du Terraform avec le tf-controller pour déployer de l’infrastructure as Code que ce soit sur de l’AWS, Azure, Google Cloud, ou autres en mode GitOps.

Pour faire simple, Flamingo est un Argo CD modifié sur lequel il est possible de bénéficier du Flux System for Argo (FSA) permettant d’utiliser la boucle de réconciliation de Flux CD plutôt que celle d’Argo CD. Cependant, ce choix est totalement configurable.

Néanmoins, il est tout à faire possible d’utiliser les deux méthodes (Argo CD ou FSA) au sein de la même instance pour des déploiements différents : la compatibilité est entièrement gérée et maintenue.

Pour utiliser le Flux System for Argo, il est nécessaire de configurer deux options de synchronisation dans vos Applications ou ApplicationSet :

syncOptions:
  - AutoCreateFluxResources=true
  - FluxSubsystem=true

Pour terminer cette section, voici un schéma récapitulatif des possibilités offertes par Flamingo :

Il est temps de passer à la découverte de Flamingo !

Installation

Pour installer Flamingo et suivre cette démonstration, vous aurez besoin d’un cluster Kubernetes, des outils en ligne de commande Flux et Flamingo.

À noter que Flamingo peut très bien utiliser une installation existante d’Argo CD comme expliqué dans ce guide.

C’est d’ailleurs ce que je vous recommande pour une installation plus pérenne en utilisant le chart Helm d’Argo CD. Celui-ci devra être surchargé avec les images de Flamingo pour l’ensemble des composants (argocd-server, argocd-repo-server, etc.) car il n’existe pour l’heure aucun chart officiel.

De mon côté, j’utilise un cluster kind avec deux nœuds (controlplane et worker) en utilisant la configuration suivante :

cat > kind-flamingo.yaml <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
EOF
kind create cluster --config kind-flamingo.yaml --name flamingo

Première étape, l’installation de Flux CD au sein du cluster :

flux install

Puis de Flamingo :

flamingo install --version=v2.8.6

Une fois ces deux outils installés, les namespaces argocd et flux-system sont créés :

$ kubectl get ns
NAME                 STATUS   AGE
argocd               Active   90s
default              Active   3m49s
flux-system          Active   2m35s
[...]

Chose intéressante à constater au sein du namespace argocd, les images des composants principaux d’Argo CD sont bien remplacées par celles de Flamingo :

$ kubectl -n argocd get deployments argocd-server argocd-applicationset-controller argocd-notifications-controller argocd-repo-server -o yaml | grep image:
          image: ghcr.io/flux-subsystem-argo/fsa/argocd:v2.8.6-fl.21-main-ff4f071a
          image: ghcr.io/flux-subsystem-argo/fsa/argocd:v2.8.6-fl.21-main-ff4f071a
          image: ghcr.io/flux-subsystem-argo/fsa/argocd:v2.8.6-fl.21-main-ff4f071a
          image: ghcr.io/flux-subsystem-argo/fsa/argocd:v2.8.6-fl.21-main-ff4f071a
          image: ghcr.io/flux-subsystem-argo/fsa/argocd:v2.8.6-fl.21-main-ff4f071a

Il est temps de faire un tour d’horizon de l’interface graphique mais avant, il est nécessaire de récupérer le mot de passe initialisé à l’installation.

Flamingo dispose d’une commande toute préparée pour obtenir le mot de passe associé à l’utilisateur admin :

flamingo show-init-password

Vous pouvez utiliser la commande port-forward pour accéder à l’interface utilisateur sans avoir besoin de configurer un service NodePort ou un Ingress :

kubectl port-forward -n argocd svc/argocd-server 8080:443

On retrouve l’interface d’Argo CD à l’identique à l’exception du logo qui lui a changé.

Déploiement

Une fois l’installation terminée, l’objectif est de tester deux déploiements :

  • Le premier qui utilise les fonctionnalités classiques d’Argo CD à travers une Application qui installe un chart Helm ;
  • Le second, comme le premier mais qui contiendra les deux options citées plus haut à savoir AutoCreateFluxResources=true et FluxSubsystem=true pour bénéficier du Flux System for Argo (FSA).

Pour l’exemple, j’ai choisi d’utiliser le chart Helm Traefik qui est mon Ingress Controller favori ! Pour ce faire, voici mes deux déploiements au format Application :

  • Traefik avec la réconciliation version Argo CD
cat > traefik-without-fsa.yaml <<EOF
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: traefik-without-fsa
  namespace: argocd
spec:
  project: default
  source:
    chart: traefik
    repoURL: https://traefik.github.io/charts
    targetRevision: 25.0.0
    helm:
      releaseName: traefik
      values: |
        service:
          type: NodePort
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
  destination:
    namespace: traefik-without-fsa
    server: 'https://kubernetes.default.svc'
EOF

Rien de bien compliqué, on précise le chart, sa version ainsi que l’url pour le récupérer tout en spécifiant le cluster local pour l’installer. La partie values évite d’utiliser le mode LoadBalancer qui ne pourra pas être déployé nativement avec kind.

Côté syncPolicy, le mode automatique pour la synchronisation a été configurée avec la remédiation (selfHeal) et la suppression des anciennes ressources (prune).

  • Traefik avec la réconciliation version Flux CD
cat > traefik-with-fsa.yaml <<EOF
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: traefik-with-fsa
  namespace: argocd
spec:
  project: default
  source:
    chart: traefik
    repoURL: https://traefik.github.io/charts
    targetRevision: 25.0.0
    helm:
      releaseName: traefik
      values: |
        service:
          type: NodePort
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - AutoCreateFluxResources=true
      - FluxSubsystem=true
  destination:
    namespace: traefik-with-fsa
    server: 'https://kubernetes.default.svc'
EOF

Pas de différence majeure au-delà de nos deux options configurées.

C’est le moment d’appliquer nos deux fichiers au sein du cluster avec la commande kubectl create -f :

kubectl create -f traefik-without-fsa.yaml
kubectl create -f traefik-with-fsa.yaml

En comparant l’Application traefik-without-fsa avec traefik-with-fsa, on remarque que deux objets supplémentaires sont créés : HelmRelease et HelmRepository qui correspondent aux objets manipulés par le controller de Flux CD.

$ kubectl -n traefik-with-fsa get helmrepositories.source.toolkit.fluxcd.io
NAME               URL                                AGE     READY   STATUS
traefik-with-fsa   https://traefik.github.io/charts   4m19s   True    stored artifact: revision 'sha256:fc9276fb5f5dbcbf524bdd84ce67771c128fdfeb598208e3b6445062e4d79d37'
$ kubectl -n traefik-with-fsa get helmreleases.helm.toolkit.fluxcd.io
NAME               AGE     READY   STATUS
traefik-with-fsa   4m37s   True    Release reconciliation succeeded

C’est donc bien la boucle de réconciliation FSA qui a pris en charge les objets Kubernetes lors de la création de la deuxième Application.

En raison de la jeunesse de Flamingo, certains paramétrages ne sont pas encore pris en charge, c’est le cas du champ valuesObject qui ne transmet pas au contrôleur de Flux CD les valeurs surchargées, il convient donc d’utiliser values comme sur l’exemple du dessus.

Enfin, si l’Application traefik-with-fsa est supprimée, les objets manipulés par Flux CD ne sont pas supprimés de manière automatique. Ce comportement est totalement normal pour le moment. En effet, la configuration est traduite en langage Flux CD et c’est ce dernier qui s’occupe du cycle de vie des objets indépendamment du cycle de vie de l’Application.

Le mot de la fin

Flamingo apparaît comme un outil qui permet de faire la liaison entre les deux références du monde GitOps sur Kubernetes.

En profitant des avantages des deux côtés, il permet aux amateurs d’Argo CD de ne pas être déboussolé sans rompre avec les grandes possibilités de déploiement offertes par les objets Application et ApplicationSet.

Pour les connaisseurs de Flux CD qui veulent continuer à bénéficier des controllers personnalisés comme Terraform et de la boucle de réconciliation propre à l’outil, ce sera l’occasion d’avoir une vue centralisée des déploiements effectués sur le cluster.

Attention tout même, Flamingo reste un outil assez jeune qui doit être encore éprouvé pour être utilisé dans des contextes de production.

SoKube peut vous aider !

Consultez les liens suivants liés à cet article de blog et découvrez comment SoKube peut vous aider :

Laisser un commentaire

  Edit this page