ArgoCD

2.1.1. Utiliser la commande argocd-server

Moi sur Arch je dois juste lancer la commande :

pacman -S argocd

Ensuite, placez vous dans le namespace argocd et lancez la commande argo-server. Vous pouvez maintenant vous connecter sur https://localhost:8080

2.1.2. Mettre en place un port-forward

Solution la plus rapide :

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

2.1.3. Visualisation

Une fois identifié, vous devez avoir ceci :

Si Vault n’est pas opérationnel, c’est que vous ne l’avez pas initialisé ou descellé.

2.2.1. Connexion

Le paquet argocd que nous avons téléchargé pour fournir le programme argocd-server fournit également le programme argocd.

Nous allons donc l’utiliser pour administrer l’outil.

kubens argocd
argocd login localhost:8080 --insecure --username admin --password $(kubectl get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d)

Nous utilisons ici directement le mot de passe stocké dans le secret kubernetes. S’il est effacé il faudra saisir celui-ci.

2.2.2. Création d’une application en ligne de commande

argocd proj create dev
argocd proj add-destination dev https://kubernetes.default.svc apps
argocd proj add-source dev "https://framagit.org/gauthier/*"

Nous pouvons maintenant créer notre application :

argocd app create webapp \
      --project dev \
      --repo https://framagit.org/gauthier/argocd-test1.git \
      --path webapp-vault \
      --dest-server https://kubernetes.default.svc \
      --dest-namespace=apps \
      --sync-policy auto

L’application apparait dans l’interface web et vous pouvez observer le détail du déploiement :

Et si je souhaite supprimer cette application :

argocd app delete webapp

Tout simplement.

3.1.1. Gestion multi-cluster

Nous l’avons vu rapidement lors de la création d’un projet, il est possible de gérer plusieurs cluster kubernetes depuis une seule application ArgoCD. Il faut dans ce cas, juste déployer les CRD pour qu’ArgoCD puisse gérer les applications.

Du coup, nous avons une interface web qui permet d’avoir une vue d’ensemble des applications déployées sur plusieurs clusters. Nous pouvons filtrer l’affichage par namespace, par nom, par cluster ou par métadonnées.

3.1.2. Gestion multi-utilisateurs en cli et web

Dans le tuto nous nous sommes connecté en admin, mais il est possible de créer de nombreux utilisateurs, voir lié ArgoCD à un ldap. Ensuite il est possible d’attribuer des rôles à chaque utilisateur ou groupe d’utilisateurs pour leur restreindre leurs droits sur un cluster, un projet, un dépôt git, un namespace, une application, une action (get, create, update, sync, delete, override), l’accès au log, …​

Actuellement la gestion des droits et des utilisateurs ne peut être fait via l’interface web, il faut alimenter un configmap pour définir ces droits et utilisateurs.

3.1.3. Gestion des mots de passe

Nous pourrions écrire un article complet sur cette problématique et sur la bonne façon de faire. ArgoCD nous laisse le choix des outils de gestion de mots de passe.

3.1.4. Déploiement conditionné à la signature du commit

Il est possible pour chaque projet de spécifier une liste de clés gpg. Ces clés seront utilisées par ArgoCD pour vérifier la validité d’un commit. Si la clé n’est pas dans la liste, le déploiement ne sera pas mis à jour.

3.2.1. Du GitOps mais pas de façon strict

Comme indiqué en introduction, ArgoCD permet d’interagir avec kubernetes sans obligation de passer par un commit dans un dépôt Git. Cela permet une souplesse que ne permet pas FluxCD, mais en contre partie nous perdons en traçabilité. Or la traçabilité permet souvent de trouver plus facilement la raison d’un dysfonctionnement.

3.2.2. Sécurité

ArgoCD a énormément de droits sur le ou les clusters kubernetes, notamment sur les clusters de prod. Ce qui est tout à fait normal, vu les tâches qui lui sont confiées. Personnellement je ne mettrais pas ArgoCD accessible d’internet et pourtant cet outil est régulièrement audité.

3.2.3. Gestion des déploiements

ArgoCD permet de déployer du Helm, Kustomize, Jsonnet ou tout simplement des fichiers Yaml présent dans le répertoire d’un dépôt Git.

Vous avez certainement remarqué, qu’après la mise en place de l’app-of-apps qui m’a permit de gérer ArgoCD dans ArgoCD, j’ai supprimé le secret contenant les informations de déploiement du Chart Helm.

En effet ArgoCD permet de déployer des Charts Helm, mais ces derniers ne sont plus gérer par Helm, et donc la commande helm list ne retournera rien. Il est donc très facile de migrer ses applications préalablement installées avec Helm sous ArgoCD, mais le contraire est moins évident.