Version : Suivant

Intégrer Chaos Mesh à GitHub Actions

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 →

Ce document explique comment intégrer Chaos Mesh pour personnaliser l'intégration continue (CI) à l'aide de chaos-mesh-action. Cela vous permet d'identifier les problèmes introduits lors du développement système avant les mises en production.

chaos-mesh-action est une action GitHub publiée sur le GitHub Marketplace. Son code source est également disponible sur GitHub.

Conception de chaos-mesh-action

GitHub Action est la fonctionnalité d'intégration continue (CI) et de déploiement continu (CD) intégrée à GitHub. Avec GitHub Action, vous pouvez automatiser et personnaliser vos flux de travail de développement logiciel directement dans votre dépôt.

Grâce à GitHub Action, Chaos Mesh s'intègre facilement dans vos développements et tests quotidiens, garantissant que tout code soumis sur GitHub passe les tests sans affecter la logique existante. L'image ci-dessous montre chaos-mesh-action intégré dans un flux CI :

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

Utiliser chaos-mesh-action dans un workflow GitHub

chaos-mesh-action fonctionne avec les workflows GitHub. Un workflow GitHub est un processus automatisé configurable. Vous pouvez configurer des workflows dans votre dépôt pour construire, tester, empaqueter, publier ou déployer des projets. Pour intégrer Chaos Mesh dans votre CI, suivez ce processus :

Étape 1 : Concevoir le workflow
Étape 2 : Créer le workflow
Étape 3 : Exécuter le workflow

Étape 1 : Concevoir le workflow

Avant de concevoir un workflow, prenez en compte ces questions :

Quelles fonctionnalités souhaitez-vous tester dans ce workflow ?
Quel type de panne sera injecté ?
Comment vérifier la robustesse du système ?

Par exemple, concevons un workflow de test simple incluant ces étapes :

Créer deux Pods dans le cluster Kubernetes
Envoyer une requête ping d'un Pod à l'autre
Utiliser Chaos Mesh pour injecter une panne de latence réseau et vérifier l'impact sur la commande ping

Étape 2 : Créer le workflow

Une fois le workflow conçu, suivez ces étapes pour le créer :

Accédez au dépôt GitHub du logiciel à tester
Créez un workflow en cliquant sur Actions puis New workflow

Un workflow est essentiellement une configuration automatisée de tâches séquentielles. Le job suivant est configuré dans un seul fichier. Pour plus de clarté, le script est divisé en groupes fonctionnels :

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

Nommez le workflow "Chaos". Il se déclenche lors d'un commit ou d'une pull request sur la branche master :
```
name: Chaos

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

Configurer l'environnement lié à l'intégration continue.

Cette configuration spécifie le système d'exploitation (Ubuntu) et crée un cluster Kind via helm/kind-action. Elle affiche ensuite les informations du cluster. Enfin, elle récupère le dépôt GitHub auquel le workflow doit accéder.

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éployer une application.

Dans l'exemple suivant, cette tâche déploie une application créant deux Pods Kubernetes.

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

Injecter des fautes avec Chaos Mesh.

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

Grâce à chaos-mesh-action, Chaos Mesh s'installe et injecte automatiquement les fautes. Vous devez simplement préparer la configuration de l'expérience de chaos sous forme de valeur encodée en base64. Pour injecter une latence réseau sur un Pod, utilisez cet exemple de configuration :

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

Obtenez la valeur encodée en base64 du fichier de configuration de l'expérience de chaos avec cette commande :

base64 chaos.yaml

Vérifier la fiabilité du système.

Dans ce job, le workflow envoie des requêtes ping d'un Pod à un autre et observe la 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

Étape 3 : Exécuter le workflow

Une fois le workflow créé, vous pouvez le déclencher en créant une pull request vers la branche master. Une fois le workflow terminé, le résultat de la vérification du job ressemble à celui ci-dessous :

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
bytes from 10.244.0.6: seq=0 ttl=63 time=0.069 ms
bytes from 10.244.0.6: seq=1 ttl=63 time=10.136 ms
bytes from 10.244.0.6: seq=2 ttl=63 time=10.192 ms
bytes from 10.244.0.6: seq=3 ttl=63 time=10.129 ms
bytes from 10.244.0.6: seq=4 ttl=63 time=10.120 ms
bytes from 10.244.0.6: seq=5 ttl=63 time=0.070 ms
bytes from 10.244.0.6: seq=6 ttl=63 time=0.073 ms
bytes from 10.244.0.6: seq=7 ttl=63 time=0.111 ms
bytes from 10.244.0.6: seq=8 ttl=63 time=0.070 ms
bytes from 10.244.0.6: seq=9 ttl=63 time=0.077 ms
……

Le résultat montre une série de délais de 10 millisecondes, chaque délai durant 5 secondes (soit 5 fois). Cela correspond à la configuration des expériences de chaos injectées avec chaos-mesh-action.

Prochaines étapes

Actuellement, chaos-mesh-action est utilisé dans TiDB Operator. En injectant des fautes de Pod dans le workflow, vous pouvez vérifier le redémarrage des instances de l'Operator. Cela permet de s'assurer que TiDB Operator fonctionne correctement lorsqu'un Pod de l'operator TiDB est supprimé aléatoirement par la faute injectée. Pour plus de détails, consultez la page de workflow de TiDB Operator.

À l'avenir, chaos-mesh-action sera utilisé dans davantage de tests TiDB pour garantir la stabilité de TiDB et de ses composants. Vous êtes invités à utiliser chaos-mesh-action pour créer votre propre workflow.

Si vous rencontrez un problème avec chaos-mesh-action, ou si vous constatez qu'une information manque, n'hésitez pas à créer un problème GitHub ou une pull request (PR) dans le dépôt Chaos Mesh. Vous pouvez également rejoindre notre canal Slack #project-chaos-mesh dans l'espace de travail CNCF.

Conception de chaos-mesh-action​

Utiliser chaos-mesh-action dans un workflow GitHub​

Étape 1 : Concevoir le workflow​

Étape 2 : Créer le workflow​

Étape 3 : Exécuter le workflow​

Prochaines étapes​