カオス・メッシュ・アクション

当初は2020年9月18日にwww.chaos-mesh.orgに掲載された.

Chaos Meshは、Kubernetes環境でカオスを組織化する雲ネイティブのカオステストプラットホームです.それが豊かな断層注入タイプと使いやすいダッシュボードでコミュニティでよく受け取られている間、エンドツーエンドテストまたは連続積分(CI)プロセスでカオスメッシュを使うのは、難しいです.その結果、システム開発中に導入された問題は、リリース前には発見できませんでした.
この記事では、カオスメッシュアクションを使用する方法を共有します.
カオスメッシュアクションはGitHub marketで入手でき、ソースコードはGitHubです.

カオスメッシュ作用の設計

GitHub ActionはGitHubによってネイティブにサポートされているCI/CD機能で、GATHUBリポジトリ内で自動化されカスタマイズされたソフトウェア開発ワークフローを容易に構築できます.
Githubのアクションと組み合わせることで、カオスメッシュは、より簡単にシステムの日常的な開発とテストに統合することができます、このようにgithubの各コード提出はバグフリーであり、既存のコードを破損しないことを保証します.次の図は、CIワークフローに統合されたカオスメッシュアクションを示します.

Githubワークフローにおけるカオスメッシュ動作の使用

chaos-mesh-action githubワークフローで動作します.Githubワークフローは、ビルド、テスト、パッケージ、リリース、または任意のGiThubプロジェクトを展開するには、リポジトリに設定することができます設定可能な自動化されたプロセスです.カオスメッシュをCIで統合するには、次の手順を実行します.

ワークフローをデザインします.

ワークフローを作成します.

ワークフローを実行します.

ワークフローをデザインする

ワークフローをデザインする前に、次の問題を考慮する必要があります.

このワークフローでどのような機能をテストしますか?

どんなタイプの欠陥が注入されますか?

システムの正しさをどうやって検証するか?

例として、次の手順を含む簡単なテストワークフローを設計します.

Kubernetesクラスタの2つのポッドを作成します.

他の1つのpodをpingします.

カオスメッシュを使用してネットワーク遅延カオスを注入し、pingコマンドが影響を受けるかどうかをテストします.

ワークフローを作成する

ワークフローをデザインした後、次のステップを作成します.

あなたがテストしたいソフトウェアを含むGithubリポジトリに移動します.

ワークフローを作成し、アクションをクリックし、「新規ワークフロー」ボタンをクリックします

ワークフローは本質的にジョブの構成です.ジョブは単一のファイルで構成されることに注意してください.より良い説明のために、以下のようにスクリプトを別のジョブグループに分割します.

ワークフロー名とトリガー規則を設定します.
このジョブはワークフロー“カオス”と名付けます.コードがマスターブランチにプッシュされるか、プルリクエストがマスターブランチに提出されると、このワークフローが引き起こされます.

    name: Chaos

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

CI関連の環境をインストールします.
この構成はオペレーティングシステム(Ubuntu)を指定します、そして、それは一種のクラスタをつくるためにhelm/kind-actionを使用します.そしてクラスタに関する関連情報を出力する.最後に、ワークフローのGithubリポジトリをチェックして、アクセスします.

    jobs:
     build:
       runs-on: ubuntu-latest
       steps:

       - name: Creating kind cluster
         uses: helm/[email protected]

       - 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

アプリケーションを配備します.
この例では、このジョブは2つのKubernetesポッドを作成するアプリケーションを配備します.

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

カオスメッシュアクションでカオスを注入します.

    - name: Run chaos mesh action
        uses: chaos-mesh/chaos-mesh-action@xiang/refine_script
        env:
          CFG_BASE64: YXBpVmVyc2lvbjogY2hhb3MtbWVzaC5vcmcvdjFhbHBoYTEKa2luZDogTmV0d29ya0NoYW9zCm1ldGFkYXRhOgogIG5hbWU6IG5ldHdvcmstZGVsYXkKICBuYW1lc3BhY2U6IGJ1c3lib3gKc3BlYzoKICBhY3Rpb246IGRlbGF5ICMgdGhlIHNwZWNpZmljIGNoYW9zIGFjdGlvbiB0byBpbmplY3QKICBtb2RlOiBhbGwKICBzZWxlY3RvcjoKICAgIHBvZHM6CiAgICAgIGJ1c3lib3g6CiAgICAgICAgLSBidXN5Ym94LTAKICBkZWxheToKICAgIGxhdGVuY3k6ICIxMG1zIgogIGR1cmF0aW9uOiAiNXMiCiAgc2NoZWR1bGVyOgogICAgY3JvbjogIkBldmVyeSAxMHMiCiAgZGlyZWN0aW9uOiB0bwogIHRhcmdldDoKICAgIHNlbGVjdG9yOgogICAgICBwb2RzOgogICAgICAgIGJ1c3lib3g6CiAgICAgICAgICAtIGJ1c3lib3gtMQogICAgbW9kZTogYWxsCg==

カオスメッシュアクションでは、カオスメッシュのインストールとカオスの注入が自動的に完了します.単にBase 64表現を得るために使用するカオス構成を準備する必要があります.ここでは、ポッドにネットワーク遅延カオスを注入したいので、オリジナルのカオス構成を次のように使用します.

    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

上記のカオス構成ファイルのbase 64値を次のコマンドを使用して取得できます.

    $ base64 chaos.yaml

システムの正当性を検証する.
この仕事では、ワークフローは片方のポッドをもう一方からpingして、ネットワーク遅れの変化を観察します.

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

ワークフローを実行する

ワークフローが構成されているので、マスターブランチにプル要求を送信することによってトリガーを行うことができます.ワークフローが完了すると、検証ジョブは次のようになります結果を出力します.

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

出力は10ミリ秒遅れのレギュラーシリーズを示します.これはカオスメッシュ作用に注入したカオス配位と一致した.

現状と次のステップ

現在、我々はカオスメッシュ作用をTiDB Operatorプロジェクトに適用した.ワークフローはPODカオスで注入され、演算子の指定されたインスタンスの再起動機能を検証します.目的は、オペレータのPODが注入された故障によってランダムに削除されるとき、TiDB演算子が正常に働くことを確実にすることです.詳細はTiDB Operator pageを見ることができます.
今後,tidbや関連成分の安定性を確保するために,カオスメッシュ作用を適用した.あなた自身のワークフローを作成するには、カオスメッシュアクションを使用しています.
あなたがバグを見つけるか、何かがなくなっていると思うならば、問題をファイルして、プル・リクエスト(PR)を開けてください、さもなければ、#project-chaos-meshスラック・ワークスペースでCNCFチャンネルで我々に加わってください.