Aller au contenu

ArgoCD ()

GitOps est un ensemble de pratiques qui permet de gérer la mise en production d'application ou la gestion d'infrastructure via un système de contrôle de version (VCS en anglais, Version Control System), le plus utilisé étant git.

L'application de ce paradigme présente les avantages suivants :

  • L'état de l'application ou d'une infrastructure est constamment défini dans le repository Git ;
  • En cas d'erreur, les retours en arrière (rollback en anglais) sont simples, grâce à la gestion en version de git ;
  • Tout le déploiement est géré par l'outillage, la surface d'attaque étant plus petite, moins d'erreurs humaines sont possibles.

GitOps est donc le nom générique de cette méthodologie pour mettre en oeuvre ces pratiques. Il faut alors utiliser un outil GitOps.

Au sein du SNUM/MSP/DAM, c'est ArgoCD qui a été sélectionné. Il est l'un des outils GitOps les plus aboutit et il est soutenu par la Cloud Native Foundation.

Comment fonctionne ArgoCD

ArgoCD a un fonctionnement simple et commun à une grande partie des outils GitOps.

ArgoCD va gérer des Applications : une application est un groupement de ressources Kubernetes (un ensemble de manifestes YAML ou un Modèle HEAT), défini par un manifeste.

Une application est alors vue comme une Custom Resource Definition (CRD), ajoutée par ArgoCD lors de son déploiement (exemple plus bas).

Afin de s'authentifier au repository git où se trouve le manifeste, ArgoCD utilise les secrets Kubernetes, dans lesquels auront été définis les URL des repository git, ainsi que leurs méthodes d'authentification.

Exemple de configuration d'une application pour ArgoCD

Une fois ArgoCD actif, créer une application est très simple, il suffit de décrire une instance de cette dernière via son CRD (fichier YAML) :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook

Le CRD de l'application prend en compte un large panel d'éléments comme, par exemple, quelle branche de développement dans le repository git viser, où l'application doit être déployée dans le cluster, etc.

Il est aussi possible de décorréler l'application du repository git.

Pour configurer un repository (avec ou sans méthode d'authentification), il faut créer un secret avec le label argocd.argoproj.io/secret-type: repository :

apiVersion: v1
kind: Secret
metadata:
  name: private-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  url: https://github.com/argoproj/private-repo
  password: my-password
  username: my-username

Une fois le repository créé, il est possible de décrire une application liée à ce dernier.

Une application ArgoCD peut aussi être une instance d'un chart Helm comme ci-dessous où une instance d'un Runner GitLab (l'application donc) est déployée :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: gitlab-runner-dam
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io 
spec:
  destination:
    namespace: gitlab-runner-dam
    server: https://kubernetes.default.svc
  project: default
  source:
    chart: gitlab-runner
    helm:
      values: |-
        affinity: {}
        checkInterval: 30
        concurrent: 10
        hostAliases: []
        imagePullPolicy: IfNotPresent
        metrics:
          enabled: true
        rbac:
          clusterWideAccess: false
          create: true
          podSecurityPolicy:
            enabled: false
            resourceNames:
            - gitlab-runner
    repoURL: https://charts.gitlab.io
    targetRevision: HEAD
    targetRevision: 0.33.1
  syncPolicy: #Define how the project will sync with the upstream source
    syncOptions: #Here it is not autmated
      - CreateNamespace=true 
      - PruneLast=true

Il est aussi possible de créer ces ressources en ligne de commandes ArgoCD (pour les barbus :fontawesome-solid-grin:{ .green }).

Description des configurations

Cf. https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/

Comment est utilisé ArgoCD ?

Pour configurer et maintenir à jour l'état des clusters Kubernetes maintenus par le SNUM/MSP/DAM autour de GitLab est le principal usage d'ArgoCD.

Les applications proposées aux usagers des clusters (Les Runner GitLab par exemple) et les applications d'administration du cluster (la stack de supervision) sont déployées par ArgoCD.

L'approche App of Apps (littéralement "une Application d'Applications") est mise en place.

App of Apps

https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/

Une application racine (root repository) est déployée à l'initialisation du cluster, cette dernière va contenir d'autres applications qui seront déployée par la suite via ArgoCD.

Avec cette approche, des centaines d'applications peuvent être déployées, tout en ayant un seul point d'entrée !

Afin de s'authentifier à tous les repository git, un modèle d'authentification est mis en place : un jeton (token) est généré en lecture seule sur un dossier GitLab, jeton qui donne droit sur tous les repository de ce dossier

dossier == groupe ?

De ce fait, chaque repository créé dans ce dossier peut être lu par ArgoCD.

Voici une Description du workflow :

Processus de déploiement avec ArgoCD

  • (1) ArgoCD récupère les ressources d'authentification ainsi que l'application racine ;
  • (2) ArgoCD se connecte au repository git racine et va déployer les applications présente dans ce dernier, il n'y a aucune limite sur le nombre d'applications ;
  • (3) ArgoCD va créer les applications définies dans le repository racine ;
  • (4) Les ressources définies par les application sont déployées et maintenues dans le cluster.

Il est important de noter qu'ArgoCD va maintenir à jour les application en permanence (surveillance en continue sur les manifestes).

Manifeste ArgoCD

Ci-dessous un exemple de manifeste ArgoCD utilisé par l'équipe GitLab pour mettre en place la logique définie précédemment.

L'authentification aux repository git se fait par la création d'un secret avec le label argocd.argoproj.io/secret-type: repo-creds :

apiVersion: v1
stringData:
  url: https://gitlab-forge.din.developpement-durable.gouv.fr/snum/gitops-repo/
  password: sample_passwd
  username: sample_username
kind: Secret
metadata:
  labels:
    argocd.argoproj.io/secret-type: repo-creds
  name: snum-gitlab-runner-repo-cred
  namespace: argocd
type: Opaque

l'URL du dossier contenant tous les repository GitOps est défini dans ce secret, ainsi ArgoCD utilisera ces authentifications pour chaque sous-repository correspondant à ce chemin et n'ayant pas de méthode d'authentification définie (surchargeant la méthode indiquée dans le secret).

Par exemple, le repository racine ci-dessous utilisera la méthode précédente :

apiVersion: v1
stringData:
  type: git
    url:https://gitlabforge.din.developpementdurable.gouv.fr/snum/gitops-repo/root-app
kind: Secret
metadata:
  labels:
    argocd.argoproj.io/secret-type: repository
  name: gitlab-cluster-root-app
  namespace: argocd
type: Opaque

Ensuite, l'application racine est créée :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: gitlab-cluster-root-app
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    namespace: default
    server: https://kubernetes.default.svc
  project: default
  source:
    path: .
    repoURL: https://gitlabforge.din.developpementdurable.gouv.fr/snum/gitops-repo/root-app
    targetRevision: HEAD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

Ces trois éléments sont déployés lors de la création d'ArgoCD par un rôle Ansible.

Lequel ?

ArgoCD prendra seul le relai ensuite en déployant automatiquement les applications définies dans le repository racine.

Comment est déployé ArgoCD ?

Via le rôle Ansible présent ici !

ArgoCD, peut être déployé dans un cluster Kubernetes via des manifestes Yaml ou un chart Helm.

Pour l'équipe GitLab, le déploiement se fait via un manifeste YAML.

Une seule instance est déployée. En effet, ArgoCD n'a aucune donnée critique en local, elle possède simplement un cache dans lequel une copie des repository est conservée.

Si ArgoCD venait à tomber, une nouvelle copie serait effectuée, sans arrêt majeur (le temps que le pod soit reconstruit par K8S).

Les manifestes utilisés pour la configuration initiale sont aussi déployé via ce rôle Ansible.