Aller au contenu principal

chaos-mesh-action : Intégrer le Chaos Engineering dans votre CI

· 7 minutes de lecture
Xiang Wang
Xiang Wang
Committer of Chaos Mesh
Traduction Bêta Non Officielle

Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →

chaos-mesh-action - Intégrer le Chaos Engineering dans votre CI
chaos-mesh-action - Intégrer le Chaos Engineering dans votre CI

Chaos Mesh est une plateforme de tests de chaos cloud-native qui orchestre le chaos dans les environnements Kubernetes. Bien qu'elle soit bien accueillie par la communauté grâce à ses nombreux types d'injection de fautes et son tableau de bord facile à utiliser, son intégration aux tests de bout en bout ou au processus d'intégration continue (CI) était difficile. Par conséquent, les problèmes introduits pendant le développement du système ne pouvaient pas être détectés avant la mise en production.

Dans cet article, je vais partager comment nous utilisons chaos-mesh-action, une action GitHub pour intégrer Chaos Mesh dans le processus CI.

chaos-mesh-action est disponible sur le marché GitHub, et le code source est sur GitHub.

Conception de chaos-mesh-action​

GitHub Actions est une fonctionnalité CI/CD nativement supportée par GitHub, grâce à laquelle nous pouvons facilement créer des workflows de développement logiciel automatisés et personnalisés dans un dépôt GitHub.

Combiné à GitHub Actions, Chaos Mesh peut être plus facilement intégré dans le développement et les tests quotidiens du système, garantissant ainsi que chaque soumission de code sur GitHub est exempte de bugs et ne compromet pas le code existant. La figure suivante montre chaos-mesh-action intégré dans le workflow CI :

Intégration de chaos-mesh-action dans le workflow de CI
Intégration de chaos-mesh-action dans le workflow de CI

Utilisation de chaos-mesh-action dans un workflow GitHub​

chaos-mesh-action fonctionne dans les workflows Github. Un workflow GitHub est un processus automatisé configurable que vous pouvez mettre en place dans votre dépôt pour construire, tester, empaqueter, publier ou déployer n'importe quel projet GitHub. Pour intégrer Chaos Mesh dans votre CI, procédez comme suit :

  1. Concevez un workflow.

  2. Créez un workflow.

  3. Exécutez le workflow.

Concevoir un workflow​

Avant de concevoir un workflow, vous devez considérer les points suivants :

  • Quelles fonctionnalités allons-nous tester dans ce workflow ?

  • Quels types de fautes allons-nous injecter ?

  • Comment vérifier la correction du système ?

À titre d'exemple, concevons un workflow de test simple comprenant les étapes suivantes :

  1. Créez deux Pods dans un cluster Kubernetes.

  2. Effectuez un ping d'un pod depuis l'autre.

  3. Utilisez Chaos Mesh pour injecter un chaos de délai réseau et testez si la commande ping est affectée.

Créer le workflow​

Après avoir conçu le workflow, l'étape suivante consiste à le créer.

  1. Accédez au dépôt GitHub contenant le logiciel que vous souhaitez tester.

  2. Pour commencer à créer un workflow, cliquez sur Actions, puis sur le bouton New workflow :

Création d'un workflow
Création d'un workflow

Un workflow est essentiellement la configuration de jobs qui s'exécutent séquentiellement et automatiquement. Notez que les jobs sont configurés dans un seul fichier. Pour une meilleure illustration, nous avons divisé le script en différents groupes de jobs comme indiqué ci-dessous :

  • Définissez le nom du workflow et les règles de déclenchement.

    Ce job nomme le workflow "Chaos". Lorsque du code est poussé sur la branche master ou qu'une pull request est soumise sur la branche master, ce workflow est déclenché.

    name: Chaos

    on:
      push:
        branches:
          - master
      pull_request:
        branches:
          - master

  • Installez l'environnement lié à l'intégration continue.

    Cette configuration spécifie le système d'exploitation (Ubuntu) et utilise helm/kind-action pour créer un cluster Kind. Elle affiche ensuite les informations relatives au cluster. Enfin, elle récupère le dépôt GitHub pour que le workflow y ait accès.

    jobs:
      build:
        runs-on: ubuntu-latest
        steps:
          - name: Creating kind cluster
            uses: helm/kind-action@v1.0.0-rc.1

          - name: Print cluster information
            run: |
              kubectl config view
              kubectl cluster-info
              kubectl get nodes
              kubectl get pods -n kube-system
              helm version
              kubectl version

          - uses: actions/checkout@v2

  • Déployez l'application.

    Dans notre exemple, ce job déploie une application qui crée deux Pods Kubernetes.

    - name: Deploy an application
         run: |
           kubectl apply -f https://raw.githubusercontent.com/chaos-mesh/apps/master/ping/busybox-statefulset.yaml

  • Injecter du chaos avec chaos-mesh-action.

    - name: Run chaos mesh action
        uses: chaos-mesh/chaos-mesh-action@v0.5
        env:
          CHAOS_MESH_VERSION: v1.0.0
          CFG_BASE64: YXBpVmVyc2lvbjogY2hhb3MtbWVzaC5vcmcvdjFhbHBoYTEKa2luZDogTmV0d29ya0NoYW9zCm1ldGFkYXRhOgogIG5hbWU6IG5ldHdvcmstZGVsYXkKICBuYW1lc3BhY2U6IGJ1c3lib3gKc3BlYzoKICBhY3Rpb246IGRlbGF5ICMgdGhlIHNwZWNpZmljIGNoYW9zIGFjdGlvbiB0byBpbmplY3QKICBtb2RlOiBhbGwKICBzZWxlY3RvcjoKICAgIHBvZHM6CiAgICAgIGJ1c3lib3g6CiAgICAgICAgLSBidXN5Ym94LTAKICBkZWxheToKICAgIGxhdGVuY3k6ICIxMG1zIgogIGR1cmF0aW9uOiAiNXMiCiAgc2NoZWR1bGVyOgogICAgY3JvbjogIkBldmVyeSAxMHMiCiAgZGlyZWN0aW9uOiB0bwogIHRhcmdldDoKICAgIHNlbGVjdG9yOgogICAgICBwb2RzOgogICAgICAgIGJ1c3lib3g6CiAgICAgICAgICAtIGJ1c3lib3gtMQogICAgbW9kZTogYWxsCg==

    Avec chaos-mesh-action, l'installation de Chaos Mesh et l'injection du chaos s'effectuent automatiquement. Il vous suffit de préparer la configuration de chaos souhaitée sous sa représentation Base64. Ici, nous souhaitons injecter un chaos réseau dans les Pods, donc nous utilisons la configuration de chaos originale suivante :

    apiVersion: chaos-mesh.org/v1alpha1
    kind: NetworkChaos
    metadata:
      name: network-delay
      namespace: busybox
    spec:
      action: delay # the specific chaos action to inject
      mode: all
      selector:
        pods:
          busybox:
            - busybox-0
      delay:
        latency: '10ms'
      duration: '5s'
      scheduler:
        cron: '@every 10s'
      direction: to
      target:
        selector:
          pods:
            busybox:
              - busybox-1
        mode: all

    Vous pouvez obtenir la valeur Base64 de ce fichier de configuration avec la commande :

    $ base64 chaos.yaml

  • Vérifier la robustesse du système.

    Dans cette tâche, le workflow exécute un ping entre les Pods et observe les variations de latence réseau.

    - name: Verify
         run: |
           echo "do some verification"
           kubectl exec busybox-0 -it -n busybox -- ping -c 30 busybox-1.busybox.busybox.svc

Exécuter le workflow​

Une fois le workflow configuré, déclenchez-le en soumettant une pull request vers la branche master. À la fin de l'exécution, l'étape de vérification produit des résultats similaires à :

do some verification
Unable to use a TTY - input is not a terminal or the right kind of file
PING busybox-1.busybox.busybox.svc (10.244.0.6): 56 data bytes
64 bytes from 10.244.0.6: seq=0 ttl=63 time=0.069 ms
64 bytes from 10.244.0.6: seq=1 ttl=63 time=10.136 ms
64 bytes from 10.244.0.6: seq=2 ttl=63 time=10.192 ms
64 bytes from 10.244.0.6: seq=3 ttl=63 time=10.129 ms
64 bytes from 10.244.0.6: seq=4 ttl=63 time=10.120 ms
64 bytes from 10.244.0.6: seq=5 ttl=63 time=0.070 ms
64 bytes from 10.244.0.6: seq=6 ttl=63 time=0.073 ms
64 bytes from 10.244.0.6: seq=7 ttl=63 time=0.111 ms
64 bytes from 10.244.0.6: seq=8 ttl=63 time=0.070 ms
64 bytes from 10.244.0.6: seq=9 ttl=63 time=0.077 ms
……

La sortie montre des délais récurrents de 10 millisecondes durant environ 5 secondes chacun. Ce comportement correspond parfaitement à la configuration de chaos injectée via chaos-mesh-action.

État actuel et prochaines étapes​

Actuellement, nous avons appliqué chaos-mesh-action au projet TiDB Operator. Le workflow est injecté avec le chaos de type Pod pour vérifier la fonction de redémarrage des instances spécifiées de l'opérateur. L'objectif est de garantir que tidb-operator fonctionne normalement lorsque les pods de l'opérateur sont supprimés aléatoirement par les fautes injectées. Vous pouvez consulter la page TiDB Operator pour plus de détails.

À l'avenir, nous prévoyons d'appliquer chaos-mesh-action à davantage de tests pour assurer la stabilité de TiDB et des composants associés. Nous vous encourageons à créer votre propre workflow en utilisant chaos-mesh-action.

Si vous découvrez un bug ou pensez qu'il manque quelque chose, n'hésitez pas à ouvrir une issue, créer une pull request (PR) ou nous rejoindre sur le canal #project-chaos-mesh dans l'espace Slack de la CNCF.