DevOpsで最も難しい問題の1つは、自分の調査を積極的にブロックする問題です。チャンピオンシップタイトルを争う中で、2番目に悪い問題は断続的に発生する問題です。この記事は、Podmanのアップストリームの継続的インテグレーション/継続的デプロイ（CI / CD）システムが両方に同時に遭遇したときの冒険物語です。
最悪の状況
昔々、Podmanのテスト自動化はその「ビッグボーイ」パンツよりも成長し始めました。これは、事実上すべてのCI/CDシステムがコンテナベースであった数年前に発生しました。コンテナ（およびポッド）管理（およびデバッグ）ツールであるPodmanは、コンテナ内で完全に実行することはできません。おそらくもっと悪いことに、コモディティ自動化サービスの大部分はUbuntuしかサポートしていませんでした。 Podmanは仮想マシン（VM）で実行する必要があったため、これはすぐに完全な非スターターになりました。また、RedHatのアップストリームディストリビューションであるFedoraを含む複数のディストリビューションに対して実行する必要がありました。
クラウドアクセス用のcloud-sdk+SSH（および/またはAnsible）セットアップの下に移植されたCI / CDワークフローの経験があるため、複雑さが増すと常に問題が発生するようです。それからある日、私はCirrus-CIに出くわしました。 Cirrus-CIは、多数のクラウドプロバイダーを使用して、コンテナーとVMを調整できるGit中心の自動化ツールです。これにより、Podmanチームは、オーケストレーションとは独立してクラウドサービスの料金を支払い、管理することができます。 Cirrus-CIがオーケストレーションのみを管理することで、VMとログデータを完全に制御できます。
全体的なワークフローは次のようになります：
- 開発者は、提案されたコード変更をPodmanのGitリポジトリにアップストリームで送信します。
- Circrus-CIは、構成ファイルを認識して読み取り、クラウド内の必要なVMを起動します。
- ネイティブクラウドメタデータサービスは、スクリプトの実行とCirrus-CIへのログバックを管理します。
- Circrus-CIはVMを停止し、開発者に合格/不合格のフィードバックを提供します。
- 変更が加えられ、コードが受け入れられるまでこのサイクルが繰り返されます。
何年もの間、このワークフローはほぼ完璧に機能しており、ほとんどの問題はテストとスクリプトに集中しており、Podmanチームが簡単に管理できる障害です。まれに、Cirrus-CI、インターネット、および/またはクラウドプロバイダー内の問題により、VMが孤立（削除に失敗）することがあります。それ以外の点では、Cirrus Labsのサポートスタッフは素晴らしく、非常に親しみやすく、トップクラスの応答性と説明責任を備えています。
次に、2020年10月のある日、新しく更新されたVMイメージのセット（つまり、新しいVMインスタンスごとにコピーされたディスクイメージ）をローテーションした後、一見ランダムなジョブが失敗し始めました。スクリプト出力の初期調査では、情報は提供されませんでした。文字通り、すべての出力が突然停止し、他の障害と比較して識別可能なパターンはありません。予想どおり、Cirrus-CIはVMを熱心にクリーンアップし、結果として生じる障害を開発者に提示して把握します。多くの場合、失敗したジョブを再実行すると、問題なく成功します。
この状況は問題なく数週間続きました。クラウド、GitHub、またはCirrusのインフラストラクチャの停止に対応しています。何百もの成功した仕事のうち、この問題はややまれで、おそらく1日に数回の失敗でした。障害の発見は困難であり、ジョブを永続的に再実行することは長期的な回避策にはなり得ませんでした。私のチームからの定期的なインシデントレポート以外に、障害の高レベルのパターンを識別することはできませんでした。新しいVMイメージには大きなメリットがあるため、ロールバックのコストも高くなります。
このようなほぼすべてのシステム上の問題では、動作パターンを見つけることがトラブルシューティングを成功させるための重要な要素です。信頼できる仕事の成功は望ましい状態であるため、少なくともいくつかの概念またはヒントを持っていることは難しい要件でした。残念ながら、この場合、パターンを観察する能力は、ランダムな失敗と非常に望ましい機能である、実際のお金を浪費する使用されていないクラウドVMのクリーンアップによって非常に制限されていました。
単純な繰り返しの手動テスト実行では、問題はまったく再現されませんでした。また、より多くのCPUおよびメモリリソースをスローしても、動作に影響はありませんでした。障害に関連する追加のデータを収集するために、オプションについて熟考し、ブレインストーミングすることに何日も費やしました。最後に、VMのクリーンアップを選択的に中断する方法が必要であることに気付きましたが、テストの実行が完了しなかった場合に限ります。
[あなたも好きかもしれません：sysadminからDevOpsへ]
言い換えると、テストの成功（合格/不合格だけでなく）をクリーンアップの実行を許可することと何らかの形で関連付ける必要がありました。そのとき、クラウドのWebUIをざっと見ていたときに見た小さなチェックボックス削除保護を思い出しました。 。このフラグが設定されている場合、Cirrus-CIはVMの削除がブロックされているため大声で文句を言いますが、それ以外の場合は、問題が発生しません。
VM自体が独自の削除保護フラグを設定および設定解除できるように、ワークフローをインストルメント化する必要がありました。このようなもの：
- VMはそれ自体で削除保護を有効にします。
- テストを実行します。
- VMは独自の削除保護を無効にします。
- Circrus-CIは、VMをクリーンアップするか、クリーンアップに失敗して、悪臭を放ちます。
このようにして、テストが完了すると、Cirrus-CIは通常どおりVMを正常に削除します。ただし、問題が発生した場合、テストは完了せず、Cirrus-CIは（まだ）有効な削除保護に遭遇します。幸い、このワークフローは、VMにインストールできるクラウド管理ユーティリティプログラムの簡単なコマンドラインオプションを使用して完全に実現できました。
このワークフローインストルメンテーションを使用すると、テストマトリックスを繰り返しトリガーし、孤立したVMが表示されるのを待つだけで済みました。問題がほぼ瞬時に再現されたので、運命はその日私に微笑んでいました。ただし、さらに数回実行したため、検査する孤立したVMが数個以上あります。
予期せぬことに、これは状況がさらに興味深いものになったときです。孤立したVMにSSHで接続できませんでした。実際、彼らは私たちのクラウドの内側または外側からのpingにさえ応答しませんでした。 1つのVMでハードリセットを実行し、起動したらシステムログを確認しました。何もなかった。ジップ。灘。私たちがすでに知っていること以外に、手がかりの1つのイオタはありません。テストは、システムの他の部分とともに、実行を停止し、停止しました。
すでに幸運な日だったので、それをプッシュすることにし、再びクラウドのWebUIをいじくり回しました。最終的に、私は別の信じられないほど便利な小さな設定を見つけました：シリアルコンソール出力ログ 。これは基本的に、カーネルに直接つながる低レベルの直接通信回線でした。完全なシステムハングが発生するほど恐ろしいことが起こった場合、カーネルは仮想シリアルポートから絶叫しているはずです。ビンゴ、ヤーツェー、ハザ！
[ 1203.905090] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 1203.912275] #PF: supervisor read access in kernel mode
[ 1203.917588] #PF: error_code(0x0000) - not-present page
[ 1203.922881] PGD 8000000124e2d067 P4D 8000000124e2d067 PUD 138d5e067 PMD 0
[ 1203.929939] Oops: 0000 [#1] SMP PTI
...blah...blah...blah
[ 1204.052766] Call Trace:
[ 1204.055440] bfq_idle_extract+0x52/0xb0
[ 1204.059468] bfq_put_idle_entity+0x12/0x60
[ 1204.063722] bfq_bfqq_served+0xb0/0x190
[ 1204.067718] bfq_dispatch_request+0x2c2/0x1070 なんで、こんにちは、旧友！本当にラッキーな一日でした！
これは、私が1年前に見たカーネルパニックであり、上流のカーネルエンジニアリングで何ヶ月も精力的に修正に取り組んできました。これは、効率を改善し、貴重な0と1がディスクに書き込まれることを保証するカーネルのストレージサブシステムのバグでした。この場合、ストレージが破損するのではなく、カーネルが白旗を掲げ、トラック内のすべての機能を停止しました。
これまでほぼ同じ問題に取り組んだことがありますが、私はすでに1行の回避策を認識していました。私のチームを何ヶ月にもわたるデバッグに引きずり込む必要はありませんでした。再発を報告し、問題に100％対処できることを知って、自信を持って回避策を展開することができます。
echo mq-deadline > /sys/block/sda/queue/scheduler さて、私はあなたが所有するすべてのLinuxシステムでそのコマンドを意地悪に実行することをお勧めしません。この特定のケースでは、過去の経験から、バッファリングアルゴリズム（I / Oエレベーターとも呼ばれます）を交換することが完全に安全であることがわかりました。 Podmanの開発者は、テスト結果の変化に気付くことさえありません。
[コンテナを使い始めますか？この無料コースをチェックしてください。コンテナ化されたアプリケーションのデプロイ：技術的な概要。 ]
まとめ
あなたやあなたの愛する人が自分自身のカーネルパニックに遭遇した場合は、このトピックに関するこの最近の記事を参照することをお勧めします。それ以外の場合、主なポイントは次のとおりです。ブラインドのトラブルシューティングを行う場合、原因と難読化の側面を解決することが絶対に不可欠です。 2つ目は、データを処理して問題の再現性を高めることです。前者の支援なしに後者を行うのは非常に困難です。