K3S/GitOps – A (long) way to DevSecOps – Épisode 7

K3S/GitOps – A (long) way to DevSecOps – Épisode 7

Rappel de la saga : A long way to DevSecOps : Épisode 1, Épisode 2, Épisode 3, Épisode 4, Épisode 5, Épisode 6, Épisode 7, Épisode 8.

Dans cette épisode on va mettre en avant un outillage permettant de jouer le rôle de chef d’orchestre dans notre cheminement vers le DevSecOps.

ArgoCD

Qu’est-ce ArgoCD ?

ArgoCD permet tout simplement d’implémenter le pattern GitOps, au sein d’un cluster Kubernetes. ArgoCD permet la gestion des configurations, des applications, des environnements depuis un gestionnaire de version. Puis d’appliquer les changements effectués dans le code directement sur l’infrastructure cible.

Cela permet en plus de gérer plusieurs environnements, et de passer assez simplement d’un environnement d’intégration, de recette fonctionnelle, de pré-production, etc.

Pour simplifier cela permet d’effectuer du « continuous deployment », de manière plus simple en utilisant les avantages de l’orchestration des conteneurs.

Voilà un article intéressant décrivant les outillages similaires.

Installation

Rien de plus simple, la documentation d’installation indique :

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

ArgoCD est stateless et stocke sa configuration dans des objets Kubernetes.

Accès à l’interface d’administration (grâce à Traefik) :

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: argo-middleware
  namespace: argocd
spec:
  headers:
    contentTypeNosniff: true
    browserXssFilter: true
    #HSTS
    forceSTSHeader: true
    stsIncludeSubdomains: true
    stsSeconds: 31536000
    # remove Server and X-Powered-By headers
    customResponseHeaders:
      Server: ''
      X-Powered-By: ''
    # add some sec headers
    featurePolicy: "vibrate 'self'; geolocation 'self'; midi 'self'; notifications 'self'; push 'self'; microphone 'none'; camera 'none'; magnetometer 'none'; gyroscope 'none'; speaker 'none'; vibrate 'self'; fullscreen 'self'"
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: argocd-https
  namespace: argocd
spec:
  entrypoints:
  - websecure
  routes:
  - match: Host(`anywhere.somewhere.com`)
    kind: Rule
    services:
    - name: argocd-server
      port: 80
    middlewares:
    - name: argo-middleware

Création d’une application

Pour le test on part d’une application qui est en version 6.0.1.32, que l’on va passer en version 6.0.2.5 via ArgoCD.

Prérequis

Ces étapes précédentes vont être réutilisées :

Ajout du dépôt git dans ArgoCD :

Paramètres principaux

Création d’un projet depuis l’interface graphique ArgoCD :

Une fois l’application créé et synchronisée :

Mise à jour de la configuration

Depuis ArgoCD

Pour le test on va juste mettre à jour le conteneur dans la dernière version :

Une fois poussé sur le dépôt Gogs (git) et après rafraîchissement :

On voit que l’application actuellement en fonctionnement sur l’infra Kubernetes n’est plus synchronisée avec la source. Il est possible de pousser les changements directement en « production », et même de faire un rollback sur l’ancienne version si jamais il y a des problèmes.

Sur Kubernetes

Une fois la synchronisation lancée…

Création de la nouvelle version du conteneur :

Suppression de l’ancienne version :

État final :

NextCloud

Retour d’OnlyOffice comme prévu dans NextCloud.

Conclusion

Auparavant pour mettre en place une chaîne d’intégration continue cela pouvait être complexe et nécessitait une « glue » qu’il fallait développer. A partir du moment ou l’on veut embrasser l’Infra As Code, les conteneurs, Kubernetes et ArgoCD peuvent nous faciliter le travail. Il est donc possible qu’à chaque commit l’infra adopte automatiquement les changements. Cela nécessite bien entendu des périodes de test et d’intégration mais « Kustomize » nous permet de décliner les environnements assez simplement. De plus ArgoCD supporte les charts Helm. Nous avons donc quasiment tous les outillages nécessaire pour commencer à vivre avec la philosophie GitOps, et nous avons donc atteint un premier objectif dans cette suite d’articles.