エンドツーエンドテストの実行

cert-manager には、実際の Kubernetes クラスターに対して機能を検証する広範なエンドツーエンド（e2e）テストスイートがあります。

完全なエンドツーエンドテストスイートを完了するには長い時間がかかる可能性があり、cert-manager プロジェクトに対するすべてのプルリクエストに対して実行されます。

cert-manager コードベース、またはエンドツーエンドテスト自体に大きな変更を加えた場合を除き、ローカルでテストを実行する必要はないでしょう。ただし、テストを実行したい場合は、このドキュメントでその方法を説明します。

要件

エンドツーエンドテストに特別な要件はありません。すべての依存関係は、makeビルドシステムを通じて自動的にプロビジョニングできます。

エンドツーエンドテストの設定

クラスターの作成

Makeを使用してkindクラスターを作成できます。

# Create a cluster using whatever K8s version is default, named "kind"
make e2e-setup-kind

# Create a cluster using K8s 1.23 named "keith"
make K8S_VERSION=1.23 KIND_CLUSTER_NAME=keith e2e-setup-kind

重要：kindクラスターは、エンドツーエンドテストで特定の機能を有効にするために、特定のサービスCIDR範囲を使用してセットアップされます。このCIDR範囲は現在構成できません。

完了すると、クラスターは、期待どおりにkubectl経由で利用可能になります。

テスト依存関係のインストール

エンドツーエンドテストに必要なさまざまな依存関係があり、これらはすべてMake経由でインストールすることもできます。

make e2e-setup

テストクラスターでこれらの依存関係の1つだけを更新または再インストールする必要がある場合は、時間を節約するために、名前付きコンポーネントを明示的にインストールできます。

この最も一般的なユースケースは、cert-manager自体を再インストールすることです。たとえば、ローカルで変更を行い、その変更をクラスターでテストしたい場合です。

# Most important: reinstall cert-manager, including rebuilding changed containers locally
make e2e-setup-certmanager

# An example of reinstalling something else; reinstall bind
make e2e-setup-bind

# More generally, see make/e2e-setup.mk for different targets!

エンドツーエンドテストの実行

セットアップと同様に、テストの実行はmakeを通じて利用できます。実際、make e2eを直接実行するだけで、手動で何もセットアップする必要がありません。

# Set up a cluster using the defaults if one's not already present, and then run the end-to-end tests
make e2e

# Set up a K8s 1.23 cluster and then run tests
make K8S_VERSION=1.23 e2e

# Run tests exactly as they're run in CI; usually not needed
make e2e-ci

すべてのテストを実行したくない場合は、Ginkgoドキュメントで説明されているように、GINKGO_FOCUS構文を使用して特定のテストに焦点を当てることができます。

make GINKGO_FOCUS=".*my test description" e2e

クラスターIPの詳細

前述のように、エンドツーエンドテストでは、特定のコンポーネントが特定の方法で、さらには特定のIPアドレスでデプロイされることが期待されます。

例として、以下のクラスターコンポーネントは特定のIPでデプロイされます。

これらのコンポーネントを正しくセットアップしないと、ACME HTTP01（およびその他の）エンドツーエンドテストが失敗する可能性があります。

エンドツーエンドテストの構造

エンドツーエンドテストは、主に2つの部分で構成されています。イシュー固有のテストと適合性スイートです。

どちらの部分も、内部でテストを実行するためにGinkgoを使用します。

適合性スイート

RBAC

このスイートは、cert-managerにクラスター上で付与されたすべてのRBAC権限をテストして、正しく動作できるかどうかを確認します。

証明書

このスイートは、すべての発行者に対して証明書機能をテストします。

フィーチャーセット

一部の発行者は、たとえばEd25519証明書の発行や、X.509 SAN拡張機能へのメールアドレスの追加など、特定の機能をサポートしていません。

各テストでは、s.checkFeatures(feature)を使用して使用される機能を指定します。これは、発行者のUnsupportedFeaturesリストに対してチェックされます。発行者でサポートされていない機能を使用するテストは、その発行者に対してスキップされます。

クラウドプロバイダーテスト

cert-managerのマスターブランチは、さまざまなクラウドプロバイダーに対してテストすることもできます。現在、EKSのテストが存在し、2日に1回定期的なジョブとして実行されます。

クラウドプロバイダーテストの拡張

クラウドプロバイダーでe2eテストを実行するために使用されるインフラストラクチャは、cert-manager/test-infraリポジトリにあります。Terraformを使用してインフラストラクチャを作成することで、より多くのクラウドプロバイダーを追加できます。

それとは別に、Jetstack testingリポジトリリポジトリにあるそれぞれのprowジョブを編集することで、既存のインフラストラクチャのテストをカスタマイズできます。cert-managerのバージョンやクラウドプロバイダーのバージョンなどの値はTerraformの変数として存在するため、たとえば、EKS prowジョブの場合、terraform applyをprowジョブで使用するときに、それらの値を変更できます。テストされているcert-managerのバージョンは変更できます。

terraform apply -var="cert_manager_version=v1.3.3" -auto-approve

特定のインフラストラクチャで使用できるすべての構成可能な変数のリストを表示するには、そのクラウドプロバイダーのインフラストラクチャのvariables.tfファイルを参照してください。

クラウドプロバイダーテストでは、cert-managerのmasterブランチにあるe2eテストを、事前に定義されたcert-managerのバージョン（prowジョブで変更可能）で実行することに注意してください。現在、PRのコードはテストされませんが、そのリクエストを追跡するissueがあります。