2012年、Andrew MortonはC / R（チェックポイント/復元）をサポートするLinuxカーネルへの最初の変更を受け入れたとき、将来のCRIUプロジェクト（ユーザー空間でのチェックポイントと復元）に悲観的でした。 ユーザーのスペースで実行中のプロセスを保存および復元する機能を実装するというアイデアは夢中になりました。4年後、プロジェクトは生きているだけでなく、ますますそれ自体に興味を持ちました。 CRIUプロジェクトの開始前に、Linux（DMTCP、BLCR、OpenVZ、CKPTなど）にC / Rを実装する試みが行われましたが、CRIUが実行可能なプロジェクトになった一方で、それらはすべてさまざまな理由で失敗する運命にありました。 残念ながら、LinuxのC / Rタスクは簡単になりませんでした。 この記事では、CRIUテストの機能について説明します。
ユニットテストの利点、継続的インテグレーションシステムの使用についての書籍や数百の記事がすでに書かれています。 これらの手法は、経験豊富な開発者全員に知られており、あらゆるソフトウェアプロジェクトの絶対的な基準です。 したがって、ここではこれらの手法を使用する利点については説明しませんが、代わりにCRIUを他のプロジェクトと区別するニュアンスについてのみ説明します。
CRIU開発プロセス自体は、Linuxカーネル開発と変わりません。すべての新しい変更は1つの完全な思考です。 すべてのパッチはcriu @メーリングリストに送られ 、そこでレビューされます。 レビューされたパッチは、プロジェクトのメンテナーによってリポジトリに追加されます。 コードの問題の一部はレビュー段階で明らかになりますが、スクリプトと構成の数のためにそれらをゼロに減らすことはできません。 したがって、劣化を検出するために、新しい変更ごとにテストを実行します。 テストの継続的な実行の保証は、自動作業テストです。
開発の初期段階で、OpenVZでのC / Rのカーネル内実装のテストに成功したZDTM （Zero DownTime Migration）テストスイートの機能テストの使用を開始しました。 現在、このセットの各テストは個別に起動され、3つの段階を経ています。環境の準備、「デモ」、およびシグナル（ステータスをチェックする時間であることをテストに知らせる）の待機、結果の確認。 テストは条件付きで2つのグループに分けられます。 最初のグループは、ある種の一定の環境または状態を準備し、信号を見越して「眠りに落ちる」静的テストです。 2番目のグループは、状態や環境を絶えず変更する動的テストです（たとえば、TCP接続でデータを送信します）。 2012年にCRIUユニットテストシステムが約70の個別のテストプログラムで構成されていた場合、今日ではその数は200に増えています。 しかし、完全なCRIUテストのために実行する必要がある組み合わせの数は本当に恐ろしいです。
主な構成は、ホストで一連のテスト全体を実行することです。各テストプログラムは特定の位置に置かれ、テストプロセスが保存および復元され、同じ位置に残っているかどうかを確認するように求められます。 次に重要な構成は、C / Rが機能するだけでなく、Cの後、メインプロセスが中断しなかったことを確認することです。 したがって、各テストは、最初の部分のみが完了して（回復せずに）バリアントで実行され、ポーズが観察されることを確認する必要があります。 これはテストなしのテストです。 復元されたプロセスは同じ位置にある場合がありますが、繰り返されるC / Rには適していません。 したがって、もう1つの構成が表示されます-C / Rを繰り返します。 次に、スナップショットの構成、名前空間に囲まれたC / R、通常のユーザー権限のC / R、後方互換性チェックのC / R、BTRFSおよびNFSでの正常な回復の検証（これらのFSには独自の「機能」があるため ）があります。 しかし、個々のプロセスのC / Rに加えて、グループC / Rを行うことができます-すべてのプロセスが同じ位置にあり、各プロセスが独自の位置にあるときにプロセスのグループを保存します。
CRIUはいくつかのハードウェアアーキテクチャをサポートしていますが、現在はx86_64、ARM、AArch64、PPC64le、i386が近づいています。 厳しい現実により、カーネルのいくつかのバージョンをテストする必要があります。バニラカーネルの最後の公式リリース、RHEL7カーネル（3.11ベース）、およびlinux-nextブランチです。 テスト期間は短い（2〜10分）が、既存のシナリオと可能な構成の組み合わせの数を考慮すると、印象的な数値が得られる。
すでに書いたように、テストは定期的に使用される場合にのみ役立ちます。 しばらくの間、手動でテストを開始しましたが、ある時点で、ローカルテストには開発者からの時間がかかり、新しい変更ごとにテストを実行するためのシステムをセットアップすることに気付きました。
2つのCIシステムを使用します。TravisCIは 、サポートされているすべてのハードウェアアーキテクチャでコンパイルをチェックするために使用されます。 Travis CIはバージョン3.8よりも低いカーネルを使用しているため、CRIUに必要なパッチのほとんどが不足しているため、Travisはテストの実行に適していないほか、よく知られているJenkins CIを使用します。
結論
- コードカバレッジのアセンブリ、テスト、および測定を自動化する必要があります
- 多くのテストは行われず、有用なコードとテストコードの比率は約1.6（48 KLOC対30 KLOC）であり、努力することが多くあります。
- テストする構成の数が膨大な場合は、優先順位を付けます
- いつものように、CRIUで私たちのところに来てください 。
CRIUプロジェクトは2012年にVirtuozzoのエンジニアによって開始されましたが、後にLinuxでC / Rテクノロジーを作成することに関心を持つ他の企業によってサポートされました。