第5章 ビルドワーカーを使用した Dockerfile の自動ビルド

Red Hat Quay は、OpenShift または Kubernetes でワーカーノードのセットを使用した Dockerfile のビルドをサポートします。GitHub Webhook などのビルドトリガーは、新規コードがコミットされる際にリポジトリーの新規バージョンを自動的にビルドするように設定できます。本書では、Red Hat Quay インストールでビルドを有効にし、1 つ以上の OpenShift/K8s クラスターを設定して Red Hat Quay からのビルドを受け入れる方法について説明します。Red Hat Quay 3.4 では、基礎となる Build Manager が Python 2 から Python 3 への移行の一環として完全に再作成されました。その結果、ビルダーイメージは、Red Hat Quay 3.3 以前のバージョンで継続的に実行された Kubernetes ジョブに対し、ベアメタルノードとして動的に作成されるようになりました。これにより、Red Hat Quay によるビルドの管理方法が大幅に単純化化され、同じメカニズムの quay.io を使用して数千ものコンテナーイメージビルドを日次で処理できるようになりました。現時点で静的 (Red Hat Quay 3.3 の「Enterprise」ビルダー) を実行しているお客様は、Kubernetes ベースのビルドメカニズムに移行する必要があります。

5.1. アーキテクチャーの概要

Red Hat Quay ビルドシステムはスケーラビリティーを確保できるように設計されています(これは quay.io ですべてのビルドをホストするために使用されます)。Red Hat Quay の Build Manager コンポーネントは、ビルド要求を追跡し、Build Executor(OpenShift/K8s クラスター)が各要求を実行できるようにするオーケストレーション層を提供します。各ビルドは、イメージのビルドプロセスを完全に分離し、そのプロセスを組み込むために小規模な仮想マシンを起動する Kubernetes ジョブによって処理されます。これにより、コンテナービルドが相互に影響を与えたり、基礎となるビルドシステムに影響を与えたりしなくなります。インフラストラクチャーに障害が発生した場合でもビルドを実行できるように、複数の Executor を設定できます。Red Hat Quay は、1 つの Executor に問題があることを検知すると、ビルドを別の Executor に自動的に送信します。

注記

Red Hat Quay のアップストリームバージョンは、AWS/EC2 ベースの Executor の設定方法を提供します。この設定は、Red Hat Quay のお客様向けにはサポートされていません。

5.1.1. ビルドマネージャー

ビルドマネージャーは、スケジュールされたビルドのライフサイクルに対応します。ビルドキュー、ビルドフェーズの更新、およびジョブのステータスの実行を必要とする操作は、ビルドマネージャーによって処理されます。

5.1.2. ビルドワーカーのコントロールプレーン

ビルドジョブは個別のワーカーノードで実行され、別のコントロールプレーン (Executor) でスケジュールされます。現時点で、Red Hat Quay は AWS および Kubernetes でのジョブの実行をサポートしています。ビルドは quay.io/quay/quay-builder を使用して実行されます。AWS では、ビルドは EC2 インスタンスにスケジュールされます。k8s では、ビルドはジョブリソースとしてスケジュールされます。

5.1.3. オーケストレーター

オーケストレーターは、現在実行中のビルドジョブの状態を保存し、ビルドマネージャーが消費するイベントを公開します (例: 期限満了のイベント)。現時点で、サポートされているオーケストレーターのバックエンドは Redis です。