OpenShiftの内部を覗き込み、Originリポジトリの秘密を暴く

OpenShiftを使ったことがある方や、その無償配布版OKDをインストールしたことがある方は、必ずやoriginリポジトリに出会ったことがあるでしょう。OpenShift 3および4.xの初期リリースの時代、ここにプラットフォーム全体のコアが存在していました。開発者たちはKubernetesコードベースの大部分をここにクローンし、その上にコンポーネントを構築していました。

しかし、今日このリポジトリにアクセスしても、以前の構造は見当たりません。おなじみのcontrollerファイルも、ocバイナリのソースコードも存在しません。すべてはどこ去了したのか、そしてRed Hatが9000近いスターを持つプロジェクトを維持しているのはなぜでしょうか？

OpenShiftのソースコードはどこ去了のか

2020年の夏、OpenShift 4.6のリリース前に、開発チームが再編を行いました。モノリシックなアプローチは障害となっていました：アップストリームのKubernetesとの変更の同期を1箇所で行うことと、独自のテストを組み合わせることが複雑になりすぎていたのです。

結果として、コードベースは分割されました：

• Kubernetesフォークとのすべての作業と、ocなどのバイナリ構築はopenshift/ocリポジトリに移動しました。
• openshift/openshift-testsリポジトリは specialized test hub（専門的なテストハブ）へと生まれ変わりました。

現在、Originの主な目的は、openshift-testsバイナリのホーム役を果たし、OpenShiftとKubernetes標準へのクラスター準拠を検証する一連のe2eシナリオを提供することになりました。

openshift-testsでのエンドツーエンドテストの仕組み

このプロジェクトでテストを構築することは、通常のgo testを実行するのとは何も関係がありませんここでは本格的なopenshift-testsバイナリがコンパイルされ、何百もの統合テストとe2eシナリオがバンドルされています。

OpenShiftチームにはe2eテストの記述に関する厳格なルールがあります。2つの異なるテストは、互いの機能を10%以上重複させてはいけません。APIの各バリデーションエラーを丁寧にチェックするなどということは忘れてください。これらのテストの目的は реальный пользовательский путь（実際のユーザージャーニー）を最初から最後までたどること：アプリケーションをデプロイし、ネットワークポリシーが機能することを確認し、ルーティングが正しいことを保証し、メトリクスを収集することです。

プロジェクトルートから1つのコマンドでテストツールをコンパイルできます：

make

生成されたバイナリは、標準のKubernetes適合性テストとRed Hatコンポーネント用の狭いspecific checks（固有のチェック）の両方を実行できます。

アノテーションの代わりに環境セレクター

かつて、特定のクラスター構成で互換性のないテストをスキップするためにエンジニアたちはGoコードに直接アノテーションを付加していました。これはアップグレード時に混乱を引き起こしていました。

最新のOriginブランチでは、アノテーションは排除されました。フィルタリングは現在いわゆる環境セレクター（SuiteSelector）によって制御されています。フレームワークは実行前にターゲットクラスターパラメータ（ネットワークプロバイダータイプやクラウドプラットフォームなど）を確認し、不適切なテストをその場でフィルタリングします。

除外ロジックは2つのレベルに分かれています：

• 標準Kubernetesテストの例外は、kubernetesのexcludeとfocusファイルにあります。
• OpenShift固有のテストのルールは、Originのtest/extendedディレクトリに直接配置されています。

OpenShift用の独自のオペレーターを作成している場合、この構造により、特定のアップストリームテストが自分の環境で実行されない理由を理解しやすくなります。

依存関係の同期とGoチェックサムの落とし穴

openshift-testsはkubernetesのフォークに依存しているため、開発者は постоянно обновлять Go-модули（Goモジュールを常に更新）する必要があります。手動で行うことを避けるために、hack/lib/update-vendor.shスクリプトがプロジェクトに追加されました。

特定のブランチまたはSHAコミットに対してベンダーを更新するには、次のように実行できます：

./hack/update-kube-vendor.sh master

このスクリプトは、マージされていないプルリクエストからの変更も取得できます。そのためには、2番目の引数としてフォークのアドレスを渡します：

./hack/update-kube-vendor.sh my-feature-branch github.com/myname/kubernetes

このスクリプトを扱う際、厄介なエラーに遭遇しやすいです。Goのチェックサムプロキシ（proxy.golang.org）は、コミットが作成したばかりでチェックサムデータベースがまだインデックスを作成する時間がない場合、404 Not Foundを返すことがあります。

このようなエラーです：

go: k8s.io/[email protected] ... 410 Gone
        server response: not found

ここでの解決策はシンプルです—ベンダーの更新中にチェックサムデータベースの検証を強制的に無効にします：

GOSUMDB=off hack/update-kube-vendor.sh master

外部サンプルのクイック実行

テスト以外にも、便利なcontribスクリプトがリポジトリに残っています。これは最新のアプリケーション manifests とクイックスタートをサードパーティのエコシステムリポジトリからダウンロードし、contrib/examplesフォルダーに配置します。

OpenShift用の動作確認済みのDeployment、Route、StatefulSetの例が必要な場合は、contrib/examplesフォルダーを確認する価値があります—検証済みの設定が含まれています。

今日、誰がOriginリポジトリを活かしているのか

単にOpenShiftクラスターを運用しているだけなら、毎日Originのコードを掘り下げる必要はないでしょう。しかし、以下の3つのケースで非常に役立ちます：

• 独自のオペレーターやプラットフォーム拡張を作成しており、CI/CDパイプラインで公式のe2eチェックを実行したい場合。
• OKD開発に貢献している場合、または特定のハードウェア向けのカスタムKubernetesビルドをデバッグしている場合。
• 大規模商用プロジェクトでGoによる分散システムテストアーキテクチャがどのように実装されているかを確認したい場合。

リポジトリはApache 2.0ライセンスの下で公開されており、すべての現行プラットフォームバージョン用のブランチをアクティブなコミュニティがメンテナンスしています。