Déployer des applications sur GKE grâce à Argo CD

Dans cet article, nous allons voir comment déployer une stack d’application sur un cluster Kubernetes dans GCP à l’aide d’Argo CD.

🤔 Qu’est-ce qu’Argo CD ?

Argo CD est un outil open source qui se déploie sur un cluster Kubernetes.

On peut considérer cet outil comme une tour de contrôle sur l’ensemble de nos créations d’objets Kubernetes. Il va nous permettre de contrôler le déploiement d’une application et son cycle de vie.

Cet outil suit un pattern GitOps, c'est-à-dire qu’il va considérer un répertoire git comme une source de confiance absolue pour définir l’état de l’application désiré.

Cette approche GitOps, permet d’organiser des opérations liées à la modification d’un environnement sur la base d’un (ou plusieurs) repository git, ce qui revient à combiner une source de vérité avec de l’automatisation.

Actuellement, avec Argo CD, nous pouvons appliquer des manifestes Kubernetes à partir des éléments suivants :

• Applications kustomize
• Charts helm
• Répertoire de manifests YAML/JSON
• Fichiers jsonnet
• Applications ksonnet
• Tout outil de gestion de configuration personnalisé, configuré en tant que plug-in de gestion de configuration

Afin de mieux comprendre le fonctionnement d’Argo CD, nous allons tout d’abord l’installer sur un cluster Kubernetes, puis déployer une stack ELK qui de mon point de vue est excellente pour l’intégration en masse de données, l’analyse de celle-ci avec une visualisation en direct.

🚀 Installation d’Argo CD

Dans cette partie, nous allons maintenant installer Argo CD sur un cluster Kubernetes.

Pour cela, nous allons tout d’abord créer un namespace “argocd” et installer les éléments nécessaires dessus :

$ kubectl create namespace argocd
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Une fois l’installation terminée, nous pouvons accéder à l’interface d’Argo CD, en exposant le service par un Ingress ou un Load Balancer. Pour des raisons de simplicité, j’ai choisi ici d'utiliser un Load Balancer (attention il ne faut pas exposer publiquement le Load Balancer publiquement sans protection)  :

$ kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

La modification prend quelques instants à s'appliquer. Une fois terminée, nous accédons à l’interface de notre outil grâce à l’adresse IP externe "35.237.45.81" du service “argocd-server” :

$ kubectl get all -n argocd

Pour nous authentifier sur l’outil, l’utilisateur par défaut est “admin”, quant au mot de passe, il est stocké dans un secret que nous allons récupérer grâce à la commande suivante :

$ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Une fois sur l’interface, je vous invite à modifier votre mot de passe par défaut en vous rendant dans “User Info -> Update password”.

Maintenant, nous allons déployer notre stack ELK grâce à cet outil et voir comment les ressources sont gérées.

👷‍♂️ Mise en place de la stack ELK

J’ai mis en place un repository github contenant le dossier “manifests” que nous allons utiliser.

Afin que la stack ELK se déploie sans souci, nous devons créer une ConfigMap pour le bon fonctionnement de Logstash à partir du dossier manifests :

$ kubectl create configmap logstash-config --from-file=./logstash.conf

Nous pouvons maintenant commencer à créer notre application sur Argo CD.

Tout d’abord, nous devons configurer la connexion à notre répertoire github, pour cela rendez-vous dans “Settings -> Repositories -> Connect repo using SSH” :

Nous allons indiquer ici les informations d’accès au répertoire, nous devons attribuer une clé SSH privée (sans mot de passe) rattachée à notre compte GitHub pour qu’Argo CD puisse accéder au répertoire et récupérer les éléments désirés.

Nous devons obtenir le résultat ci-dessus une fois la connexion établie. Dans les options de la ressource, sélectionner maintenant “Créer une application” et indiquer les informations suivantes :

Ici, nous avons indiqué le nom de notre application, le projet par défaut et la politique de synchronisation.

L’option “Prune ressources”, d’Argo CD va automatiquement supprimer des ressources si elles ne sont plus présentes sur le répertoire git.

L’option “Self heal”, va forcer les ressources de notre cluster à correspondre à celles définies dans git (une suppression automatique des ressources non définies dans git aura alors lieu).

Sur l'image ci-dessus, nous avons indiqué le lieu où est stocké notre projet, la branche du répertoire git que nous utilisons et notre dossier “manifests” contenant la stack ELK que nous allons déployer.

Nous pouvons également spécifier si ce déploiement doit être fait dans un namespace particulier. Dans cet exemple, je reste sur celui par défaut.

On aperçoit sur l’image ci-dessus l’état de nos ressources ainsi que celui de l’application. Argo CD nous permet également de voir l’état de la synchronisation en direct avec le répertoire.

En haut à gauche, on aperçoit la synchronisation du côté de notre cluster Kubernetes, sur la droite, la synchronisation au niveau de git.

Notre application est maintenant déployée mais nous allons la modifier pour voir la réaction d’Argo CD. Dans cet exemple, j’ai édité le fichier “service-kibana.yaml”.
Il s’agissait d’un service de type “NodePort”, qui sera maintenant un service de type “LoadBalancer” pour que l’on puisse accéder publiquement à l’interface de Kibana :

Lors du push de la modification du service, Argo CD détecte tout de suite un changement sur le répertoire git et effectue une comparaison avec les éléments sur le cluster Kubernetes pour voir si des ressources sont modifiées/supprimées.

En attendant quelques instants, on constate que la vérification est terminée avec la récupération du dernier commit de notre répertoire git.

Nous pouvons maintenant accéder à l’interface de Kibana en récupérant l’adresse IP externe “34.138.233.106” du service :

🧐 Conclusion

Dans cet article, nous avons vu comment utiliser l’outil Argo CD pour déployer des applications dans Kubernetes (ici par exemple pour un ELK).

L’approche GitOps, lié à Argo CD va nous apporter des gains importants :

• L’état souhaité est exprimé de manière déclarative
• L’état de l’application est stockée d’une manière qui applique l’immuabilité, la gestion des versions et conserve un historique complet des versions
• Argo CD va automatiquement pull l’état désiré depuis la source github/gitlab
• Suivi des modifications, avec authentification
• Argo CD surveille en permanence l’état du système et essaie d'appliquer l’état désiré (si on ajoute un service manuellement Argo CD va le supprimer automatiquement)
• Facilite la gestion dans le cadre d’équipes larges
• Le repo git peut être considéré comme une source de vérité et peut représenter correctement les divers environnements dont la production

Cependant, pour faciliter la mise en place de cet outil, on peut le résumer de la manière suivante :

• Pour une utilisation simple, il faut privilégiez l’approche push
• Pour en faire la pierre angulaire d’une organisation, il faut privilégier la méthode pull, en fonction de l’organisation de la société. Mais attention à bien former les équipes opérationnelles