GitOps sur un laptop avec K3D et ArgoCD

TL;DR

Qui a dit que pratiquer GitOps nécessite toujours des outils complexes et une infrastructure coûteuse, même pour des scénarios simples ? Dans cet article, nous allons montrer comment mettre en place (et faire fonctionner) un environnement GitOps avec K3D et Argo CD pour du développement local.

Faire fonctionner une application selon l’approche GitOps sur un ordinateur local peut être utile dans plusieurs scénarios :

• Provisionner des clusters Kubernetes dans votre organisation n’est pas chose aisée (autorisations, délais, etc.)
• Votre organisation est encore en chemin vers Kubernetes mais n’est pas encore prête. En attendant, les développeurs et testeurs ont besoin de travailler sur des environnements Kubernetes.

Et si nous pouvions disposer d’un moyen peu coûteux et sans tracas pour obtenir un environnement Kubernetes complet, suffisamment proche de la préproduction et de la production ?

Un setup GitOps local minimal

k3d, tel que décrit sur son site :

K3D est un wrapper léger permettant de faire tourner* k3s (la distribution Kubernetes minimaliste de Rancher Lab) dans docker. k3d permet de créer très facilement des clusters k3s mono ou multi-nœuds dans Docker, par exemple pour du développement local sur Kubernetes.

C’est une solution économique pour les développeurs qui souhaitent provisionner localement des clusters Kubernetes légers. Enfin, avec ArgoCD qui synchronise les ressources du cluster avec nos manifestes hébergés dans git, nous obtenons un workflow GitOps de premier ordre, sans coût, et sans grand compromis !

Voici un aperçu graphique du setup que nous allons mettre en place dans cet article. Nous limiterons notre périmètre aux branches de fonctionnalités (feature branches) : idéalement, vos autres branches (préproduction, branche de release, master) sont déjà couvertes par les pipelines CI/CD sur des clusters dédiés. Notre approche est l’approche pull, puisque les changements sont détectés et pilotés depuis l’intérieur du cluster (les identifiants du cluster ne sont pas exposés vers l’extérieur).

Notre cluster local aura deux namespaces :

• argocd : pour l’application ArgoCD et la configuration additionnelle de notre setup
• dev : pour notre application elle-même

ArgoCD maintiendra en synchronisation les manifestes Kubernetes de notre application, hébergés sur une branche d’un dépôt GitHub, et le namespace dev local dédié.

Mettre en place un cluster local avec K3D

Nous avons déjà présenté k3d et k3s dans un article précédent. Depuis, k3d a été considérablement réécrit et ne cesse de s’améliorer, mais certaines commandes ne sont plus compatibles avec les versions précédentes. Pour cet article, nous allons utiliser la version v3.0.0 qui vient tout juste de sortir, en suivant les instructions d’installation. Notre environnement local est un Ubuntu 20.04.

1
2

$ sudo wget https://github.com/rancher/k3d/releases/download/v3.0.0/k3d-linux-amd64 -O /usr/local/bin/k3d
$ sudo chmod +x /usr/local/bin/k3d

Nous vérifions que l’installation est correcte en lançant la commande k3d version :

1
2
3

$ k3d version
k3d version v3.0.0
k3s version v1.18.6-k3s1 (default)

Nous pouvons installer les scripts d’auto-complétion (qui sont vraiment utiles) avec la commande k3d completion et en l’ajoutant à vos ressources de shell. Par exemple pour linux avec bash :

1
2

$ echo "source <(k3d completion bash)" >> ~/.bashrc
$ source ~/.bashrc

Mettons en place notre cluster avec 2 nœuds worker (–agents dans la commande k3d) et exposons le load balancer HTTP sur l’hôte au port 8080 (afin de pouvoir interagir avec notre application)

1

$ k3d cluster create my-cluster --api-port 6443 -p 8080:80@loadbalancer --agents 2

Par défaut, créer un nouveau cluster va :

• mettre à jour votre fichier kubeconfig avec le nouveau context, cluster et les détails de l’utilisateur (option –update-default-kubeconfig)
• en faire le contexte par défaut (option –switch-context)

Vous pouvez donc directement utiliser la commande kubectl :

1

$ kubectl cluster-info

Installation d’ArgoCD

Argo CD est un outil de livraison continue déclaratif pour Kubernetes, basé sur l’approche GitOps.

Les définitions d’applications, les configurations et les environnements devraient être déclaratifs et versionnés. Le déploiement des applications et la gestion de leur cycle de vie devraient être automatisés, auditables et faciles à comprendre.

Téléchargeons le yaml d’installation d’ArgoCD 1.6.2 :

1

$ wget https://github.com/argoproj/argo-cd/raw/v1.6.2/manifests/install.yaml

Nous voulons qu’ArgoCD soit disponible sur /argocd, il faut donc modifier le chemin racine de l’application avec l’option –rootpath dans la commande du conteneur argocd server (juste après les lignes –staticassets /shared/app) et ajouter également l’option –insecure :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

...
    spec:
      containers:
      - command:
        - argocd-server
        - --staticassets
        - /shared/app
        # Add insecure and argocd as rootpath
        - --insecure
        - --rootpath
        - /argocd
        image: argoproj/argocd:v1.6.2
        imagePullPolicy: Always
...

Une fois cela fait, créons le namespace argocd et installons ArgoCD avec le script modifié

1
2

$ kubectl create namespace argocd
$ kubectl apply -f install.yaml -n argocd

Créons un Ingress pour rediriger /argocd vers le service principal argocd :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

$ cat > ingress.yaml << EOF
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: argocd-ingress
  labels:
    app: argocd
  annotations:
    ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - http:
      paths:
      - path: /argocd
        backend:
          serviceName: argocd-server
          servicePort: 80
EOF

$ kubectl apply -f ingress.yaml -n argocd

Ouvrons un navigateur sur http://localhost:8080/argocd. Notez que l’installation peut prendre un peu de temps pour se terminer.

Par défaut, ArgoCD utilise le nom du pod du serveur comme mot de passe par défaut pour l’utilisateur admin, nous allons donc le remplacer par mysupersecretpassword (nous avons utilisé https://bcrypt-generator.com/ pour générer la version hachée en blowfish de “mysupersecretpassword” ci-dessous)

1
2
3
4
5

kubectl -n argocd patch secret argocd-secret\
  -p '{"stringData":  {
    "admin.password": "$2y$12$Kg4H0rLL/RVrWUVhj6ykeO3Ei/YqbGaqp.jAtzzUSJdYWT6LUh/n6",
    "admin.passwordMtime": "'$(date +%FT%T%Z)'"
  }}'

Utilisons maintenant les identifiants admin et mysupersecretpassword comme mot de passe, et nous devrions obtenir une instance ArgoCD vide et prête à l’emploi !

Vous pouvez explorer un peu l’interface, mais comme nous voulons automatiser la majeure partie de notre setup, il vaut mieux ne rien configurer manuellement.

Notre application d’exemple

Nous allons utiliser ici un dépôt public sur GitHub comme exemple, mais ArgoCD est agnostique quant à l’hébergement des manifestes de l’application, tant qu’ils respectent le protocole git.

Notre application d’exemple est un Deployment d’un serveur web nginx avec du contenu (une ConfigMap stockant le site web et montée comme un volume), un Service et un Ingress pour la rendre accessible sur /app :

L’application d’exemple est hébergée publiquement sur github : https://github.com/sokube/argocd-rocks

• website-cm.yaml : un simple site html stocké sous forme de ConfigMap
• website-deployment.yaml : notez la ConfigMap montée comme un volume sous le chemin par défaut du contenu html du site nginx
• website-svc.yaml : un simple service ClusterIP pour notre Ingress
• website-ingress.yaml : notez ici les annotations avec une ligne spécifique pour que traefik réécrive les urls des requêtes /app en /

Puisqu’ArgoCD synchronise le contenu d’un namespace avec les manifestes situés sous un chemin dans un dépôt git, nous devons au préalable créer un namespace dédié (dev) :

1

$ kubectl create namespace dev

Nous voulons que notre travail au sein d’ArgoCD soit hébergé dans un projet dédié nommé argocdrocks-project. Nous appliquons volontairement quelques restrictions à ce projet, qui s’appliqueront à toutes les applications situées dans ce projet : autoriser uniquement les déploiements dans le cluster, dans le namespace dev, et uniquement pour les dépôts github de Sokube.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

$ cat > project.yaml << EOF
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: argocdrocks-project
  labels:
    app: argocdrocks
spec:
  # Project description
  description: Our ArgoCD Project to deploy our app locally
  # Allow manifests to deploy only from Sokube git repositories
  sourceRepos:
  - "https://github.com/sokube/*"
  # Only permit to deploy applications in the same cluster
  destinations:
  - namespace: dev
    server: https://kubernetes.default.svc
  # Enables namespace orphaned resource monitoring.
  orphanedResources:
    warn: false
EOF

$ kubectl apply -f project.yaml -n argocd

Ensuite, nous allons créer une Application ArgoCD qui synchronisera nos manifestes Kubernetes hébergés dans le dossier app sur la branche de fonctionnalité featurebranch_1 de notre dépôt github, avec les ressources associées dans le namespace dev de notre cluster local :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

$ cat > application.yaml << EOF
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  labels:
    app: argocdrocks
  name: argocdrocks-app
spec:
  project: argocdrocks-project
  source:
    repoURL: https://github.com/sokube/argocd-rocks.git
    targetRevision: featurebranch_1
    path: app
    directory:
      recurse: true
  destination:
    server: https://kubernetes.default.svc
    namespace: dev
  syncPolicy:
    automated:
      prune: false
      selfHeal: true
EOF

Arrêtons-nous un instant sur la section syncPolicy de la définition de l’Application ArgoCD :

• la synchronisation automatisée relance les tentatives échouées 5 fois, avec les délais suivants entre chaque tentative : 5s, 10s, 20s, 40s, 80s. Le nombre de tentatives, les délais et les facteurs de multiplication sont configurables dans une section retry additionnelle (non illustrée ici).
• prune précise si les ressources doivent être supprimées (pruned) pendant la synchronisation automatique (false par défaut).
• selfHeal précise si une synchronisation (partielle) doit être effectuée si les ressources du cluster Kubernetes cible sont modifiées alors qu’aucun changement git n’a été détecté (par exemple, la suppression manuelle d’un deployment)

1

$ kubectl apply -f application.yaml -n argocd

La synchronisation est immédiate, et nos différentes ressources sont créées dans notre namespace dev :

Et notre application se trouve bien sur /app à l’adresse localhost:8080 :

Tout changement ultérieur dans notre branche de fonctionnalité sera détecté par ArgoCD (qui interroge régulièrement le dépôt git) et appliqué dans notre cluster. Modifions website-cm.yaml dans notre branche feature_branch1 :

1
2
3
4

...
          <h1>ArgoCD Rocks Really!</h1>
          <p>Version 2</p>
...

Nous commitons, poussons, et observons ArgoCD détecter les changements et les appliquer. Ici, la mise à jour de la ConfigMap ne déclenche pas de redéploiement, mais comme la ConfigMap est montée comme un volume, le changement est pris en compte par le kubelet de Kubernetes après environ une minute.

Conclusion

À travers cet article rapide, nous avons pu démontrer et expérimenter l’usage d’ArgoCD en utilisant Git comme source de vérité pour le déploiement des applications. Combiné à la distribution légère K3D de RancherLabs, l’ensemble peut facilement tourner sur un ordinateur portable à des fins d’expérimentation.

Dans un scénario réel, ArgoCD ferait partie d’un pipeline CI/CD d’entreprise sécurisé pour déployer des charges de travail sur des clusters Kubernetes de production.

Les opérateurs GitOps tels qu’ArgoCD ou FluxCD aident indéniablement à mettre en œuvre des scénarios d’Operations by Pull-Requests. Les deux projets, respectivement en phase d’incubation et de sandbox au sein de la CNCF, ont d’ailleurs décidé d’unir leurs forces pour apporter à la communauté Kubernetes une expérience GitOps unifiée, et peut-être bientôt standardisée…

Pour aller plus loin, découvrez notre formation ArgoCD et GitOps et notre consulting DevOps.