Zum Hauptinhalt springen

chaos-mesh-action: Chaos Engineering in Ihre CI integrieren

· 6 Minuten Lesezeit
Xiang Wang
Xiang Wang
Committer of Chaos Mesh
Inoffizielle Beta-Übersetzung

Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →

chaos-mesh-action - Chaos Engineering in Ihre CI integrieren
chaos-mesh-action - Chaos Engineering in Ihre CI integrieren

Chaos Mesh ist eine cloud-native Chaos-Testing-Plattform, die Chaos in Kubernetes-Umgebungen orchestriert. Obwohl sie in der Community mit ihren vielfältigen Fehlerinjektionstypen und dem benutzerfreundlichen Dashboard gut angenommen wird, war die Integration in End-to-End-Tests oder Continuous Integration (CI)-Prozesse schwierig. Dadurch konnten Probleme, die während der Systementwicklung entstanden, vor dem Release nicht entdeckt werden.

In diesem Artikel zeige ich Ihnen, wie wir mit der GitHub Action chaos-mesh-action Chaos Mesh in CI-Prozesse integrieren.

chaos-mesh-action ist im GitHub Marketplace verfügbar, und der Quellcode liegt auf GitHub.

Aufbau von chaos-mesh-action​

GitHub Actions ist eine von GitHub nativ unterstützte CI/CD-Funktion, mit der wir automatisierte und angepasste Software-Entwicklungsworkflows im GitHub-Repository erstellen können.

In Kombination mit GitHub Actions lässt sich Chaos Mesh nahtlos in die tägliche Entwicklung und Tests einbinden. Dadurch wird sichergestellt, dass jeder Code-Commit auf GitHub fehlerfrei ist und bestehenden Code nicht beschädigt. Die folgende Abbildung zeigt chaos-mesh-action im CI-Workflow:

Integration von chaos-mesh-action im CI-Workflow
Integration von chaos-mesh-action im CI-Workflow

Verwendung von chaos-mesh-action in GitHub-Workflows​

chaos-mesh-action funktioniert in GitHub-Workflows. Ein GitHub-Workflow ist ein konfigurierbarer, automatisierter Prozess, den Sie in Ihrem Repository einrichten können, um GitHub-Projekte zu bauen, testen, packen, releasen oder bereitzustellen. Gehen Sie wie folgt vor, um Chaos Mesh in Ihre CI zu integrieren:

  1. Workflow entwerfen

  2. Workflow erstellen

  3. Workflow ausführen

Workflow entwerfen​

Bevor Sie einen Workflow entwerfen, sollten Sie folgende Punkte klären:

  • Welche Funktionen wollen wir in diesem Workflow testen?

  • Welche Fehlertypen wollen wir injizieren?

  • Wie überprüfen wir die Systemkorrektheit?

Als Beispiel entwerfen wir einen einfachen Testworkflow mit diesen Schritten:

  1. Erstellen Sie zwei Pods in einem Kubernetes-Cluster.

  2. Pingen Sie einen Pod vom anderen aus an.

  3. Injizieren Sie mit Chaos Mesh Netzwerkverzögerungen und testen Sie, ob der Ping-Befehl beeinträchtigt wird.

Workflow erstellen​

Nachdem Sie den Workflow entworfen haben, erstellen Sie ihn im nächsten Schritt.

  1. Navigieren Sie zum GitHub-Repository mit der zu testenden Software.

  2. Klicken Sie zum Erstellen eines Workflows auf Actions und dann auf die Schaltfläche New workflow:

Workflow erstellen
Workflow erstellen

Ein Workflow ist im Wesentlichen die Konfiguration von Jobs, die sequenziell und automatisch ablaufen. Beachten Sie, dass die Jobs in einer einzigen Datei konfiguriert werden. Zur besseren Veranschaulichung unterteilen wir das Skript in verschiedene Jobgruppen, wie unten gezeigt:

  • Namen des Workflows und Trigger-Regeln festlegen.

    Dieser Job benennt den Workflow "Chaos". Wenn Code in den Master-Branch gepusht oder ein Pull Request an den Master-Branch gestellt wird, wird dieser Workflow ausgelöst.

    name: Chaos

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

  • CI-bezogene Umgebung einrichten.

    Diese Konfiguration legt das Betriebssystem (Ubuntu) fest und verwendet helm/kind-action zum Erstellen eines Kind-Clusters. Anschließend werden relevante Cluster-Informationen ausgegeben. Zuletzt wird das GitHub-Repository für den Workflow-Zugriff ausgecheckt.

    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

  • Anwendung bereitstellen.

    In unserem Beispiel stellt dieser Job eine Anwendung bereit, die zwei Kubernetes-Pods erstellt.

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

  • Chaos mit chaos-mesh-action einspritzen.

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

    Mit chaos-mesh-action erfolgen die Installation von Chaos Mesh und das Einspritzen von Chaos automatisch. Sie müssen lediglich die gewünschte Chaos-Konfiguration vorbereiten und deren Base64-Darstellung angeben. In diesem Beispiel möchten wir Netzwerkverzögerungs-Chaos in die Pods einspritzen, daher verwenden wir folgende Chaos-Konfiguration:

    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

    Den Base64-Wert dieser Konfigurationsdatei erhalten Sie mit folgendem Befehl:

    $ base64 chaos.yaml

  • Systemkorrektheit überprüfen.

    In diesem Job pingt der Workflow einen Pod vom anderen aus und beobachtet die Netzwerkverzögerungsänderungen.

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

Workflow ausführen​

Nach der Konfiguration können wir den Workflow durch einen Pull Request in den Master-Branch auslösen. Nach Abschluss zeigt der Verifizierungsjob Ergebnisse ähnlich diesen:

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
……

Die Ausgabe zeigt regelmäßige 10-Millisekunden-Verzögerungen von jeweils etwa 5 Sekunden Dauer. Dies entspricht der in chaos-mesh-action eingespritzten Chaos-Konfiguration.

Aktueller Status und nächste Schritte​

Derzeit haben wir chaos-mesh-action im TiDB Operator-Projekt eingesetzt. Der Workflow wird mit einem Pod-Chaos versehen, um die Neustart-Funktion spezifizierter Operator-Instanzen zu verifizieren. Ziel ist es sicherzustellen, dass tidb-operator normal funktioniert, wenn die Pods des Operators durch die injizierten Fehler zufällig gelöscht werden. Weitere Details finden Sie auf der TiDB Operator-Seite.

Zukünftig planen wir, chaos-mesh-action für weitere Tests einzusetzen, um die Stabilität von TiDB und verwandten Komponenten sicherzustellen. Sie sind herzlich eingeladen, Ihren eigenen Workflow mit chaos-mesh-action zu erstellen.

Wenn Sie einen Fehler finden oder etwas fehlt, sind Sie herzlich eingeladen, ein Issue zu erstellen, einen Pull Request (PR) zu öffnen oder uns im #project-chaos-mesh-Kanal im CNCF-Slack-Workspace beizutreten.