ビルダーとイメージの自動化
はじめに
このガイドでは、ベアメタルマシンと仮想マシンの両方で Red Hat Quay の ビルド 機能を設定する方法を説明します。
第1章 Red Hat Quay ビルドの概要
Red Hat Quay ビルド (または単に ビルド) は、コンテナーイメージのビルドの自動化を可能にする機能です。ビルド 機能は、ワーカーノードを使用して、Dockerfiles またはその他のビルド仕様からイメージをビルドします。これらのビルドは、GitHub などのリポジトリーからの Webhook を介して手動でトリガーすることも、自動的にトリガーすることもできるため、ユーザーは継続的インテグレーション (CI) と継続的デリバリー (CD) パイプラインをワークフローに統合できます。
ビルド 機能は、OpenShift Container Platform および Kubernetes クラスター上の Red Hat Quay でサポートされています。Operator ベースのデプロイメントと Kubernetes クラスターの場合、ビルド は、ビルドジョブを調整および処理する ビルドマネージャー を使用して作成されます。ビルドは、ベアメタルプラットフォームと 仮想ビルダー を使用した仮想化プラットフォームの両方での Dockerfile のビルドをサポートします。この汎用性により、組織は Red Hat Quay のコンテナーイメージビルド機能を活用しながら、既存のインフラストラクチャーに適応できます。
Red Hat Quay ビルド 機能の主な特徴は次のとおりです。
- コードコミットまたはバージョン管理イベントによってトリガーされる自動ビルド
- Docker および Podman コンテナーイメージのサポート
- ビルド環境とリソースのきめ細かな制御
- スケーラブルなビルドを実現する Kubernetes および OpenShift Container Platform との統合
- ベアメタルおよび仮想化インフラストラクチャーとの互換性
ベアメタルプラットフォーム上のコンテナー内で直接 ビルド を実行すると、仮想マシンを使用する場合と同じ分離は実現されませんが、それでも十分な保護が提供されます。
ビルド は非常に複雑なので、管理者は続行する前に ビルドの自動化 アーキテクチャーガイドを確認することを推奨します。
1.1. コンテナーイメージのビルド
コンテナーイメージをビルドするには、コンテナー化されたアプリケーションのブループリントを作成する必要があります。ブループリントは、アプリケーションのインストール方法と設定方法を定義する他のパブリックリポジトリーのベースイメージに依存します。
Red Hat Quay は、Docker および Podman コンテナーイメージをビルドする機能をサポートしています。この機能は、コンテナーとコンテナーオーケストレーションを利用する開発者や組織に役立ちます。
1.1.1. ビルドコンテキスト
Docker または Podman でイメージをビルドする際には、ビルドコンテキスト となるディレクトリーを指定します。これは手動ビルドとビルドトリガーの両方に当てはまります。これによって作成されるビルドは、ローカルマシンで docker build
または podman build
を実行する場合と変わらないためです。
ビルドコンテキストは常にビルドセットアップの サブディレクトリー で指定され、ディレクトリーが指定されていない場合はビルドソースのルートにフォールバックします。
ビルドがトリガーされると、ビルドワーカーは Git リポジトリーをワーカーマシンにクローンし、ビルドの前にビルドコンテキストに入ります。
.tar
アーカイブをベースにしたビルドでは、ビルドワーカーがアーカイブを抽出し、ビルドコンテキストに入ります。以下に例を示します。
展開されたビルドアーカイブ
example ├── .git ├── Dockerfile ├── file └── subdir └── Dockerfile
上記の 展開されたビルドアーカイブ は、example という Github リポジトリーのディレクトリー構造を持っていると考えてみてください。ビルドトリガーの設定でサブディレクトリーが指定されていない場合、またはビルドを手動で開始する場合、ビルドは example ディレクトリーで行われます。
ビルドトリガーの設定でサブディレクトリー (subdir
など) を指定した場合は、その中の Dockerfile のみがビルドの対象になります。つまり、Dockerfile の ADD
コマンドを使用して file
を追加することは、ビルドコンテキストの外にあるためできません。
Docker Hub とは異なり、Dockerfile は Build コンテキストの一部であるため、.dockerignore
ファイルには表示されません。
第2章 ビルド用の OpenShift Container Platform TLS コンポーネントの設定
QuayRegistry
カスタムリソース定義 (CRD) の tls
コンポーネントを使用すると、SSL/TLS を Red Hat Quay Operator によって管理するか、自己管理するかを制御できます。現状では、tls
コンポーネントが Red Hat Quay Operator によって管理されている場合、Red Hat Quay は ビルド 機能または ビルダー ワーカーをサポートしません。
tls
コンポーネントを unmanaged
に設定する場合は、独自の ssl.cert
ファイルと ssl.key
ファイルを指定する必要があります。さらに、クラスターが ビルダー、またはイメージをビルドするワーカーノードをサポートする場合は、証明書の SAN リストに Quay
ルートと builder
ルート名の両方を追加する必要があります。ただし、代わりにワイルドカードを使用することもできます。
次の手順では、ビルダー ルートを追加する方法を示します。
前提条件
-
tls
コンポーネントをunmanaged
に設定し、カスタム SSL/TLS 証明書を Red Hat Quay Operator にアップロードしている。詳細は、Red Hat Quay の SSL および TLS を参照してください。
手順
SSL/TLS 証明書パラメーターを定義する設定ファイル (
openssl.cnf
など) で、証明書のサブジェクト代替名 (SAN) フィールドに次の情報を追加します。以下に例を示します。# ... [alt_names] <quayregistry-name>-quay-builder-<namespace>.<domain-name>:443 # ...
以下に例を示します。
# ... [alt_names] example-registry-quay-builder-quay-enterprise.apps.cluster-new.gcp.quaydev.org:443 # ...
第3章 Red Hat Quay on OpenShift Container Platform を使用したベアメタルビルド
このセクションの手順では、OpenShift Container Platform 上で Red Hat Quay の ベアメタルビルド 環境を作成する方法を説明します。
3.1. Red Hat Quay on OpenShift Container Platform のベアメタルビルドの設定
Red Hat Quay on OpenShift Container Platform の ベアメタルビルド を設定するには、次の手順に従います。
QuayRegistry
CRD でマネージド route
コンポーネントを使用して Red Hat Quay Operator on OpenShift Container Platform を使用している場合は、「自己管理 ルート を使用した Red Hat Quay on OpenShift Container Platform ビルド 制限」を参照してください。
前提条件
- Red Hat Quay Operator が実行されている状態でプロビジョニングされた OpenShift Container Platform クラスターがある。
-
tls
コンポーネントをunmanaged
に設定し、カスタム SSL/TLS 証明書を Red Hat Quay Operator にアップロードしている。詳細は、Red Hat Quay の SSL および TLS を参照してください。 - クラスター管理者として OpenShift Container Platform にログインしている。
手順
ビルドが実行されるプロジェクト (例:
bare-metal-builder
) を作成するには、次のコマンドを入力します。$ oc new-project bare-metal-builder
次のコマンドを入力して、
bare-metal-builder
namespace に新しいServiceAccount
を作成します。$ oc create sa -n bare-metal-builder quay-builder
次のコマンドを入力して、ユーザーに
bare-metal-builder
namespace 内でのedit
ロールを付与します。$ oc policy add-role-to-user -n bare-metal-builder edit system:serviceaccount:bare-metal-builder:quay-builder
次のコマンドを入力して、
bare-metal-builder
namespace のquay-builder
サービスアカウントに関連付けられたトークンを取得します。このトークンは、OpenShift Container Platform クラスターの API サーバーの認証と対話に使用されます。OpenShift Container Platform クラスターのバージョンが 4.11 以上の場合は、次のコマンドを入力します。
oc create token quay-builder -n bare-metal-builder --duration 24h
OpenShift Container Platform クラスターがバージョン 4.11 より前 (たとえばバージョン 4.10) の場合は、次のコマンドを入力します。
$ oc sa get-token -n bare-metal-builder quay-builder
- OpenShift Container Platform クラスターの API サーバーの URL を特定します。これは、OpenShift Container Platform Web コンソールで確認できます。
ビルドジョブ をスケジュールするときに使用するワーカーノードラベルを識別します。ビルド Pod はベアメタルワーカーノード上で実行する必要があるため、これらは通常、特定のラベルで識別されます。
どのノードラベルを使用すべきかは、クラスター管理者に確認してください。
Red Hat Quay の追加証明書に追加するには、Kube API Server の認証局 (CA) を取得します。
OpenShift Container Platform バージョン 4.15 以降では、次のコマンドを入力して、CA を含むシークレットの名前を取得します。
$ oc extract cm/kube-root-ca.crt -n openshift-apiserver
$ mv ca.crt build_cluster.crt
OpenShift Container Platform バージョン 4.15 より前 (例: 4.14) の場合は、次のコマンドを入力します。
$ oc get sa openshift-apiserver-sa --namespace=openshift-apiserver -o json | jq '.secrets[] | select(.name | contains("openshift-apiserver-sa-token"))'.name
-
OpenShift Container Platform Web コンソールで、シークレットから
ca.crt
キーの値を取得します。値は "-----BEGIN CERTIFICATE-----"` で始まります。 -
CA を Red Hat Quay にインポートします。このファイルの名前が、手順 9 で使用した
K8S_API_TLS_CA
フィールドと一致していることを確認します。
ServiceAccount
に対して次のSecurityContextConstraints
リソースを作成します。apiVersion: security.openshift.io/v1 kind: SecurityContextConstraints metadata: name: quay-builder priority: null readOnlyRootFilesystem: false requiredDropCapabilities: null runAsUser: type: RunAsAny seLinuxContext: type: RunAsAny seccompProfiles: - '*' supplementalGroups: type: RunAsAny volumes: - '*' allowHostDirVolumePlugin: true allowHostIPC: true allowHostNetwork: true allowHostPID: true allowHostPorts: true allowPrivilegeEscalation: true allowPrivilegedContainer: true allowedCapabilities: - '*' allowedUnsafeSysctls: - '*' defaultAddCapabilities: null fsGroup: type: RunAsAny --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: quay-builder-scc namespace: bare-metal-builder rules: - apiGroups: - security.openshift.io resourceNames: - quay-builder resources: - securitycontextconstraints verbs: - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: quay-builder-scc namespace: bare-metal-builder subjects: - kind: ServiceAccount name: quay-builder roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: quay-builder-scc
OpenShift Container Platform Web コンソールを使用して、Red Hat Quay on OpenShift Container Platform デプロイメントの
config.yaml
ファイルを更新し、適切な ベアメタルビルド 設定を含めます。- Operators → Installed Operators → Red Hat Quay → Quay Registry をクリックします。
- レジストリーの名前 (例: example-registry) をクリックします。
- Config Bundle Secret の下で、設定バンドルの名前 (例: extra-ca-certificate-config-bundle-secret) をクリックします。
- Actions → Edit Secret をクリックします。
以下の情報を Red Hat Quay の
config.yaml
ファイルに追加し、各値をお客様のインストールに関連する情報に置き換えます。FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - <superusername> FEATURE_USER_CREATION: false FEATURE_QUOTA_MANAGEMENT: true FEATURE_BUILD_SUPPORT: True BUILDMAN_HOSTNAME: ${BUILDMAN_HOSTNAME}:443 1 BUILD_MANAGER: - ephemeral - ALLOWED_WORKER_COUNT: 10 ORCHESTRATOR_PREFIX: buildman/production/ ORCHESTRATOR: REDIS_HOST: <sample_redis_hostname> 2 REDIS_PASSWORD: "" REDIS_SSL: false REDIS_SKIP_KEYSPACE_EVENT_SETUP: false EXECUTORS: - EXECUTOR: kubernetes BUILDER_NAMESPACE: <sample_builder_namespace> 3 K8S_API_SERVER: <sample_k8s_api_server> 4 K8S_API_TLS_CA: <sample_crt_file> 5 VOLUME_SIZE: 8G KUBERNETES_DISTRIBUTION: openshift CONTAINER_MEMORY_LIMITS: 1G 6 CONTAINER_CPU_LIMITS: 300m 7 CONTAINER_MEMORY_REQUEST: 1G 8 CONTAINER_CPU_REQUEST: 300m 9 NODE_SELECTOR_LABEL_KEY: beta.kubernetes.io/instance-type NODE_SELECTOR_LABEL_VALUE: n1-standard-4 CONTAINER_RUNTIME: podman SERVICE_ACCOUNT_NAME: <sample_service_account_name> SERVICE_ACCOUNT_TOKEN: <sample_account_token> 10 QUAY_USERNAME: <quay_username> QUAY_PASSWORD: <quay_password> WORKER_IMAGE: <registry>/quay-quay-builder WORKER_TAG: <some_tag> BUILDER_VM_CONTAINER_IMAGE: registry.redhat.io/quay/quay-builder-qemu-rhcos-rhel8:v3.9.10-4 SETUP_TIME: 180 MINIMUM_RETRY_THRESHOLD: 0 SSH_AUTHORIZED_KEYS: 11 - <ssh-rsa 12345 someuser@email.com> - <ssh-rsa 67890 someuser2@email.com> HTTP_PROXY: <http://10.0.0.1:80> HTTPS_PROXY: <http://10.0.0.1:80> NO_PROXY: <hostname.example.com>
- 1
- 次のコマンドを実行して取得します:
$ oc get route quayregistry-quay-builder -n ${QUAY_PROJECT} -o jsonpath='{.spec.host}'
- 2
- Redis サービスのホスト名。
- 3
- ベアメタルビルド namespace の名前と一致するように設定します。この例では
bare-metal-builder
を使用しました。 - 4
K8S_API_SERVER
は、$ oc cluster-info
を実行して取得します。- 5
- カスタム CA 証明書を手動で作成して追加する必要があります (例
K8S_API_TLS_CA: /conf/stack/extra_ca_certs/build-cluster.crt
)。 - 6
- 指定しないと、デフォルトは
5120Mi
です。 - 7
- 指定しないと、デフォルトは
1000m
です。 - 8
- 指定しないと、デフォルトは
3968Mi
です。 - 9
- 指定しないと、デフォルトは
500m
です。 - 10
$ oc create sa
の実行時に取得します。- 11
- リモートトラブルシューティングアクセス用に、ビルド環境に公開 SSH キーを追加できるようにします。このキーは、管理者または開発者がデバッグの目的でビルドワーカーに SSH 接続するために使用する秘密鍵に対応している必要があります。このキーは、特定の SSH キーとポートを使用してリモートホストへの SSH 接続を確立することによって取得できます。例:
$ ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost
- ビルド 機能を有効にするには、Red Hat Quay レジストリーを再起動します。
3.1.1. 自己管理 ルート を使用した Red Hat Quay on OpenShift Container Platform ビルド 制限
OpenShift Container Platform 上で Red Hat Quay Operator をマネージド route
コンポーネントとともに使用する場合、次の制限が適用されます。
- 現在、OpenShift Container Platform の ルート は、単一ポートへのトラフィックのみを処理できます。Red Hat Quay ビルドをセットアップするには追加の手順が必要です。
-
Red Hat Quay Operator がインストールされているクラスターで
kubectl
またはoc
CLI ツールが動作するように設定されていること、およびQuayRegistry
が存在することを確認します。QuayRegistry
は、ビルダー が実行されるのと同じベアメタルクラスター上にある必要はありません。 - こちらの手順 に従って、OpenShift クラスター上で HTTP/2 ingress が有効になっていることを確認します。
Red Hat Quay Operator は、既存の
Quay
Pod 内で実行されているビルドマネージャーサーバーに gRPC トラフィックを送信するRoute
リソースを作成します。カスタムホスト名、または<builder-registry.example.com>
などのサブドメインを使用する場合は、作成したRoute
リソースのstatus.ingress[0].host
を参照する DNS プロバイダーで CNAME レコードを作成してください。以下に例を示します。$ kubectl get -n <namespace> route <quayregistry-name>-quay-builder -o jsonpath={.status.ingress[0].host}
OpenShift Container Platform UI または CLI を使用して、
QuayRegistry
のspec.configBundleSecret
によって参照されるSecret
を ビルド クラスター CA 証明書で更新します。キーにextra_ca_cert_build_cluster.cert
という名前を付けます。Red Hat Quay ビルド の設定時に作成した ビルド 設定で参照されている正しい値でconfig.yaml
ファイルのエントリーを更新し、BUILDMAN_HOSTNAME
CONFIGURATION FIELD を追加します。BUILDMAN_HOSTNAME: <build-manager-hostname> 1 BUILD_MANAGER: - ephemeral - ALLOWED_WORKER_COUNT: 1 ORCHESTRATOR_PREFIX: buildman/production/ JOB_REGISTRATION_TIMEOUT: 600 ORCHESTRATOR: REDIS_HOST: <quay_redis_host REDIS_PASSWORD: <quay_redis_password> REDIS_SSL: true REDIS_SKIP_KEYSPACE_EVENT_SETUP: false EXECUTORS: - EXECUTOR: kubernetes BUILDER_NAMESPACE: builder ...
- 1
- ビルドジョブ が ビルドマネージャー と通信するために使用する、外部からアクセス可能なサーバーホスト名です。デフォルトは
SERVER_HOSTNAME
と同じです。OpenShiftroute
リソースの場合、これはstatus.ingress[0].host
か、カスタムホスト名を使用している場合は CNAME エントリーのいずれかになります。BUILDMAN_HOSTNAME
には、ポート番号を含める必要があります (例: OpenShift Container Platformroute
の場合はsomehost:443
)。これは、ビルドマネージャー との通信に使用される gRPC クライアントが、ポートを省略すると推測しないためです。
第4章 Red Hat Quay on OpenShift Container Platform を使用した仮想ビルド
このセクションの手順では、OpenShift Container Platform 上で Red Hat Quay の ベアメタルビルド 環境を作成する方法を説明します。
仮想ビルド は、Red Hat Quay on OpenShift Container Platform を使用して仮想マシン上で実行できます。この方法では、ビルドマネージャー は最初に Job Object
リソースを作成します。次に、Job Object
は quay-builder-image
を使用して Pod を作成します。quay-builder-image
には、quay-builder
バイナリーと Podman サービスが含まれています。作成された Pod は unprivileged
として実行されます。次に、quay-builder
バイナリーは、ステータスを通信し、ビルドマネージャー からビルド情報を取得しながらイメージをビルドします。
4.1. 仮想ビルドの制限
仮想ビルド 機能には次の制限が適用されます。
- 権限のないコンテキストで Red Hat Quay on OpenShift Container Platform を使用して 仮想ビルド を実行すると、以前のビルドストラテジーで動作していた一部のコマンドが失敗する可能性があります。ビルド戦略を変更しようとすると、ビルドのパフォーマンスの問題と信頼性の問題が発生する可能性があります。
- コンテナー内で直接 仮想ビルド を実行しても、仮想マシンを使用する場合と同じ分離は実現されません。ビルド環境を変更した場合も、以前は機能していたビルドが失敗する可能性があります。
4.2. Red Hat Quay on OpenShift Container Platform の仮想ビルドの設定
このセクションの手順では、OpenShift Container Platform 上で Red Hat Quay の 仮想ビルド 環境を作成する方法を説明します。
- Amazon Web Service (AWS) S3 ストレージを使用している場合は、ビルダーを実行する前に、AWS コンソールでストレージバケットを変更する必要があります。必要なパラメーターは、次のセクションの「AWS S3 ストレージバケットの変更」を参照してください。
- Google Cloud Platform (GCP) オブジェクトバケットを使用している場合は、仮想ビルド を有効にするために、クロスオリジンリソース共有 (CORS) を設定する必要があります。
前提条件
- Red Hat Quay Operator が実行されている状態でプロビジョニングされた OpenShift Container Platform クラスターがある。
-
tls
コンポーネントをunmanaged
に設定し、カスタム SSL/TLS 証明書を Red Hat Quay Operator にアップロードしている。詳細は、Red Hat Quay の SSL および TLS を参照してください。 - ビルド用に OpenShift Container Platform TLS コンポーネントを設定している。
- クラスター管理者として OpenShift Container Platform にログインしている。
手順
次のコマンドを実行して、仮想ビルダーが実行される新しいプロジェクト (
virtual-builders
など) を作成します。$ oc new-project virtual-builders
次のコマンドを入力して、ビルド の実行に使用されるプロジェクトに
ServiceAccount
を作成します。$ oc create sa -n virtual-builders quay-builder
出力例
serviceaccount/quay-builder created
作成されたサービスアカウントに編集権限を付与して、ビルド を実行できるようにします。
$ oc adm policy -n virtual-builders add-role-to-user edit system:serviceaccount:virtual-builders:quay-builder
出力例
clusterrole.rbac.authorization.k8s.io/edit added: "system:serviceaccount:virtual-builders:quay-builder"
次のコマンドを入力して、ビルダー ワーカーに
anyuid scc
権限を付与します。これにはクラスター管理者権限が必要です。これは、権限のないビルドまたはルートレスビルドが機能するためには、ビルダー を Podman ユーザーとして実行する必要があるために必要です。$ oc adm policy -n virtual-builders add-scc-to-user anyuid -z quay-builder
出力例
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "quay-builder"
次のコマンドを入力して、builder サービスアカウントのトークンを取得します。
$ oc create token quay-builder -n virtual-builders
注記トークンの有効期限が切れたら、新しいトークンを要求する必要があります。必要に応じて、カスタムの有効期限を追加することもできます。たとえば、トークンを 2 週間保持するには、
--duration 20160m
と指定します。出力例
eyJhbGciOiJSUzI1NiIsImtpZCI6IldfQUJkaDVmb3ltTHZ0dGZMYjhIWnYxZTQzN2dJVEJxcDJscldSdEUtYWsifQ...
次のコマンドを入力して、ビルダー ルートを決定します。
$ oc get route -n quay-enterprise
出力例
NAME: example-registry-quay-builder HOST/PORT: example-registry-quay-builder-quay-enterprise.apps.stevsmit-cluster-new.gcp.quaydev.org PATH: SERVICES: example-registry-quay-app PORT: grpc TERMINATION: passthrough/Redirect WILDCARD: None
次のコマンドを入力して、
.crt
エクステンションを持つ自己署名 SSL/TLS 証明書を生成します。$ oc extract cm/kube-root-ca.crt -n openshift-apiserver
出力例
ca.crt
次のコマンドを入力して、
ca.crt
ファイルの名前をbuild-cluster.crt
に変更します。$ mv ca.crt build-cluster.crt
OpenShift Container Platform Web コンソールを使用して、Red Hat Quay on OpenShift Container Platform デプロイメントの
config.yaml
ファイルを更新し、適切な 仮想ビルド 設定を含めます。- Operators → Installed Operators → Red Hat Quay → Quay Registry をクリックします。
- レジストリーの名前 (例: example-registry) をクリックします。
- Config Bundle Secret の下で、設定バンドルの名前 (例: extra-ca-certificate-config-bundle-secret) をクリックします。
- Actions → Edit Secret をクリックします。
以下を参考にして適切な 仮想ビルド 設定を追加します。
FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - <superusername> FEATURE_USER_CREATION: false FEATURE_QUOTA_MANAGEMENT: true FEATURE_BUILD_SUPPORT: True BUILDMAN_HOSTNAME: <sample_build_route> 1 BUILD_MANAGER: - ephemeral - ALLOWED_WORKER_COUNT: 1 ORCHESTRATOR_PREFIX: buildman/production/ JOB_REGISTRATION_TIMEOUT: 3600 2 ORCHESTRATOR: REDIS_HOST: <sample_redis_hostname> 3 REDIS_PASSWORD: "" REDIS_SSL: false REDIS_SKIP_KEYSPACE_EVENT_SETUP: false EXECUTORS: - EXECUTOR: kubernetesPodman NAME: openshift BUILDER_NAMESPACE: <sample_builder_namespace> 4 SETUP_TIME: 180 MINIMUM_RETRY_THRESHOLD: 0 BUILDER_CONTAINER_IMAGE: quay.io/projectquay/quay-builder:{producty} # Kubernetes resource options K8S_API_SERVER: <sample_k8s_api_server> 5 K8S_API_TLS_CA: <sample_crt_file> 6 VOLUME_SIZE: 8G KUBERNETES_DISTRIBUTION: openshift CONTAINER_MEMORY_LIMITS: 1G 7 CONTAINER_CPU_LIMITS: 300m 8 CONTAINER_MEMORY_REQUEST: 1G 9 CONTAINER_CPU_REQUEST: 300m 10 NODE_SELECTOR_LABEL_KEY: "" NODE_SELECTOR_LABEL_VALUE: "" SERVICE_ACCOUNT_NAME: <sample_service_account_name> SERVICE_ACCOUNT_TOKEN: <sample_account_token> 11 HTTP_PROXY: <http://10.0.0.1:80> HTTPS_PROXY: <http://10.0.0.1:80> NO_PROXY: <hostname.example.com>
- 1
- ビルドルートは、OpenShift Container Platform デプロイメント上の Red Hat Quay の namespace を使用して
$ oc get route -n
を実行することで取得されます。ルートの最後にポートを指定する必要があり、[quayregistry-cr-name]-quay-builder-[ocp-namespace].[ocp-domain-name]:443
の形式を使用する必要があります。 - 2
JOB_REGISTRATION_TIMEOUT
パラメーターの設定が低すぎると、failed to register job to build manager: rpc error: code = Unauthenticated desc = Invalid build token: Signature has expired
エラーが発生する可能性があります。このパラメーターは少なくとも240
に設定する必要があります。- 3
- Redis ホストにパスワードまたは SSL/TLS 証明書がある場合は、それに応じてこのフィールドを更新する必要があります。
- 4
- 仮想ビルド namespace の名前と一致するように設定します。この例では、
virtual-builders
を使用しました。 - 5
K8S_API_SERVER
は、$ oc cluster-info
を実行して取得します。- 6
- カスタム CA 証明書を手動で作成して追加する必要があります (例
K8S_API_TLS_CA: /conf/stack/extra_ca_certs/build-cluster.crt
)。 - 7
- 指定しないと、デフォルトは
5120Mi
です。 - 8
- 仮想ビルド の場合、クラスター内に十分なリソースがあることを確認する必要があります。指定しないと、デフォルトは
1000m
です。 - 9
- 指定しないと、デフォルトは
3968Mi
です。 - 10
- 指定しないと、デフォルトは
500m
です。 - 11
$ oc create sa
の実行時に取得します。
仮想ビルド 設定の例
FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false FEATURE_QUOTA_MANAGEMENT: true FEATURE_BUILD_SUPPORT: True BUILDMAN_HOSTNAME: example-registry-quay-builder-quay-enterprise.apps.docs.quayteam.org:443 BUILD_MANAGER: - ephemeral - ALLOWED_WORKER_COUNT: 1 ORCHESTRATOR_PREFIX: buildman/production/ JOB_REGISTRATION_TIMEOUT: 3600 ORCHESTRATOR: REDIS_HOST: example-registry-quay-redis REDIS_PASSWORD: "" REDIS_SSL: false REDIS_SKIP_KEYSPACE_EVENT_SETUP: false EXECUTORS: - EXECUTOR: kubernetesPodman NAME: openshift BUILDER_NAMESPACE: virtual-builders SETUP_TIME: 180 MINIMUM_RETRY_THRESHOLD: 0 BUILDER_CONTAINER_IMAGE: quay.io/projectquay/quay-builder:{producty} # Kubernetes resource options K8S_API_SERVER: api.docs.quayteam.org:6443 K8S_API_TLS_CA: /conf/stack/extra_ca_certs/build-cluster.crt VOLUME_SIZE: 8G KUBERNETES_DISTRIBUTION: openshift CONTAINER_MEMORY_LIMITS: 1G CONTAINER_CPU_LIMITS: 300m CONTAINER_MEMORY_REQUEST: 1G CONTAINER_CPU_REQUEST: 300m NODE_SELECTOR_LABEL_KEY: "" NODE_SELECTOR_LABEL_VALUE: "" SERVICE_ACCOUNT_NAME: quay-builder SERVICE_ACCOUNT_TOKEN: "eyJhbGciOiJSUzI1NiIsImtpZCI6IldfQUJkaDVmb3ltTHZ0dGZMYjhIWnYxZTQzN2dJVEJxcDJscldSdEUtYWsifQ" HTTP_PROXY: <http://10.0.0.1:80> HTTPS_PROXY: <http://10.0.0.1:80> NO_PROXY: <hostname.example.com>
- Edit Secret ページで Save をクリックします。
- 新しい設定を使用して、OpenShift Container Platform レジストリー上の Red Hat Quay を再起動します。
4.2.1. AWS S3 ストレージバケットの変更
AWS S3 ストレージを使用している場合は、ビルド を開始する前に AWS コンソールでストレージバケットを変更する必要があります。
手順
- s3.console.aws.com で AWS コンソールにログインします。
-
検索バーで
S3
を検索し、S3 をクリックします。 -
バケットの名前 (
myawsbucket
など) をクリックします。 - Permissions タブをクリックします。
Cross-origin resource sharing (CORS) の下に、次のパラメーターを含めます。
[ { "AllowedHeaders": [ "Authorization" ], "AllowedMethods": [ "GET" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [], "MaxAgeSeconds": 3000 }, { "AllowedHeaders": [ "Content-Type", "x-amz-acl", "origin" ], "AllowedMethods": [ "PUT" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [], "MaxAgeSeconds": 3000 } ]
4.2.2. Google Cloud Platform オブジェクトバケットの変更
現在、Google Cloud Platform オブジェクトバケットの変更は、IBM Power および IBM Z ではサポートされていません。
仮想ビルダーの CORS (Cross-Origin Resource Sharing) を設定するには、次の手順を実行します。CORS 設定がないと、ビルド Dockerfile のアップロードは失敗します。
手順
次のリファレンスを使用して、特定の CORS ニーズに合わせた JSON ファイルを作成します。以下に例を示します。
$ cat gcp_cors.json
出力例
[ { "origin": ["*"], "method": ["GET"], "responseHeader": ["Authorization"], "maxAgeSeconds": 3600 }, { "origin": ["*"], "method": ["PUT"], "responseHeader": [ "Content-Type", "x-goog-acl", "origin"], "maxAgeSeconds": 3600 } ]
次のコマンドを入力して、GCP ストレージバケットを更新します。
$ gcloud storage buckets update gs://<bucket_name> --cors-file=./gcp_cors.json
出力例
Updating Completed 1
次のコマンドを実行すると、GCP バケットの更新された CORS 設定を表示できます。
$ gcloud storage buckets describe gs://<bucket_name> --format="default(cors)"
出力例
cors: - maxAgeSeconds: 3600 method: - GET origin: - '*' responseHeader: - Authorization - maxAgeSeconds: 3600 method: - PUT origin: - '*' responseHeader: - Content-Type - x-goog-acl - origin
第5章 新しいビルドの開始
デプロイメントを設定して Red Hat Quay ビルド 機能を有効にした後、ビルドトリガー を呼び出すか、Dockerfile をアップロードして新しいビルドを開始できます。
Dockerfile をアップロードして新しい ビルド を開始するには、次の手順に従います。ビルドトリガー の作成は、「ビルドトリガー」を参照してください。
前提条件
- リポジトリーの Builds ページに移動している。
- ビルド 機能を使用するように環境を設定している。
手順
- Builds ページで、Start New Build をクリックします。
- プロンプトが表示されたら、Upload Dockerfile をクリックして、ルートディレクトリーに Dockerfile または Dockerfile を含むアーカイブをアップロードします。
Start Build をクリックします。
注記- 現在、ユーザーは手動でビルドを開始するときに Docker ビルドコンテキストを指定できません。
- 現在、BitBucket は Red Hat Quay v2 UI ではサポートされていません。
- ビルド にリダイレクトされます。ビルドはリアルタイムで確認できます。Dockerfile ビルド が完了してプッシュされるまで待ちます。
- オプション: Download Logs をクリックしてログをダウンロードしたり、Copy Logs をクリックしてログをコピーしたりできます。
戻るボタンをクリックして Repository Builds ページに戻ると、ビルド履歴 を表示できます。
ビルド のステータスを確認するには、Build History ページでコミットをクリックするか、次のコマンドを実行します。
$ oc get pods -n virtual-builders
出力例
NAME READY STATUS RESTARTS AGE f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2 1/1 Running 0 7s
ビルド の完了後、
oc get pods -n virtual-builders
コマンドはリソースを返しません。$ oc get pods -n virtual-builders
出力例
No resources found in virtual-builders namespace.
第6章 ビルドトリガー
ビルドトリガー は、ソースコードの変更、依存関係の更新、Webhook 呼び出しの作成 など、特定の条件が満たされたときにコンテナーイメージのビルドを開始する自動化されたメカニズムです。これらのトリガーは、イメージビルドプロセスの自動化に役立ち、手動介入なしにコンテナーイメージを常に最新の状態にします。
次のセクションでは、ビルドトリガーの作成、タグの命名規則、ソースコントロールがトリガーするビルドのスキップ方法、ビルド の開始、または ビルド の手動トリガーに関連するコンテンツを説明します。
6.1. ビルドトリガーの作成
次の手順では、カスタム Git トリガー をセットアップします。カスタム Git トリガーは、任意の Git サーバーが ビルドトリガー として機能するための一般的な方法です。カスタム Git トリガーは SSH 鍵と Webhook エンドポイントのみに依存します。カスタム Git トリガーの作成は、他のトリガーの作成と似ていますが、次の点が違います。
これらの手順をレプリケートして、Github、Gitlab、または Bitbucket を使用して ビルドトリガー を作成できますが、config.yaml
ファイルでこれらのサービスの認証情報を設定する必要があります。
- Github を使用して ビルドトリガー を作成する場合は、OAuth アプリケーションを作成し、Red Hat Quay で使用する Github を設定する必要があります。詳細は、「OAuth アプリケーション Github の作成」を参照してください。
前提条件
手順
- Red Hat Quay レジストリーにログインします。
- ナビゲーションペインで、Repositories をクリックします。
- Create Repository をクリックします。
- Builds タブをクリックします。
- Builds ページで、Create Build Trigger をクリックします。
- Github、Bitbucket、Gitlab などの目的のプラットフォームを選択するか、カスタム Git リポジトリーを使用します。この例では、Custom Git Repository Push をクリックします。
-
カスタム Git リポジトリー名を入力します (例:
git@github.com:<username>/<repo>.git
)。Next をクリックします。 プロンプトが表示されたら、次のオプションのいずれかまたは両方を選択して、タグ付けオプションを設定します。
- Tag manifest with the branch or tag name。このオプションを選択すると、ビルドされたマニフェストにブランチの名前または git コミットのタグがタグ付けされます。
Add
latest
tag if on default branch。このオプションを選択すると、リポジトリーのデフォルトブランチでビルドが行われた場合に、ビルドされたマニフェストに latest がタグ付けされます。オプションで、カスタムのタグ付けテンプレートを追加できます。ここに入力できるタグテンプレートは複数あります。短い SHA ID、タイムスタンプ、作成者名、コミッター、コミットからのブランチ名をタグとして使用することもできます。詳細は、「ビルドトリガーのタグ命名」を参照してください。
タグ付けを設定したら、Next をクリックします。
- プロンプトが表示されたら、トリガーの呼び出し時にビルドする Dockerfile の場所を選択します。Dockerfile が git リポジトリーのルートにあり、Dockerfile という名前が付けられている場合は、Dockerfile パスとして /Dockerfile を入力します。Next をクリックします。
-
プロンプトが表示されたら、Docker ビルドのコンテキストを選択します。Dockerfile が Git リポジトリーのルートにある場合は、ビルドコンテキストディレクトリーとして
/
を入力します。Next をクリックします。 - オプション: 任意のロボットアカウントを選択します。これにより、ビルドプロセス中にプライベートのベースイメージをプルできます。プライベートベースイメージが使用されていないことを把握している場合は、この手順を省略できます。
- Next をクリックします。検証の警告がないか確認します。必要に応じて、Finish をクリックする前に問題を修正します。
トリガーが正常にアクティベートされたという警告が表示されます。このトリガーを使用するには、以下のアクションが必要になることに注意してください。
- 以下の公開鍵に git リポジトリーへの読み取りアクセス権を与える必要があります。
ビルドをトリガーするには、リポジトリーを
POST
に設定する必要があります。SSH 公開鍵を保存し、Return to <organization_name>/<repository_name> をクリックします。リポジトリーの Builds ページにリダイレクトされます。
Builds ページに、ビルドトリガー が表示されます。以下に例を示します。
カスタム Git トリガーを作成した後、追加の手順が必要になります。「カスタム Git トリガーのセットアップ」に進みます。
Github、Gitlab、または Bitbucket の ビルドトリガー をセットアップする場合は、「ビルドの手動トリガー」に進んでください。
6.1.1. カスタム Git トリガーのセットアップ
カスタム Git トリガー を作成した後、次の 2 つの追加手順が必要です。
- トリガーの作成時に生成された SSH 公開鍵への読み取りアクセスを付与する必要があります。
- ビルドをトリガーする Red Hat Quay のエンドポイントに POST する Webhook をセットアップする必要があります。
これらの手順は、カスタム Git トリガー を使用している場合にのみ必要です。
6.1.1.1. ビルドトリガーの認証情報を取得する
SSH 公開鍵と Webhook エンドポイント URL は、Red Hat Quay UI で利用できます。
前提条件
- カスタム Git トリガー を作成している。
手順
- リポジトリーの Builds ページで、カスタム Git トリガー のメニューケバブをクリックします。
- View Credentials をクリックします。
- SSH 公開鍵と Webhook エンドポイント URL を保存します。
鍵と URL は、Settings または 歯車 アイコンから View Credentials を選択することで利用できます。
リポジトリーからのタグの表示および変更
6.1.1.1.1. SSH 公開鍵へのアクセス
Git サーバーの設定に応じて、カスタム Git トリガー用に生成する SSH 公開鍵をインストールする方法はさまざまです。
たとえば、Getting Git on a Server のドキュメントでは、リポジトリーの管理と SSH 経由のアクセス制御に重点を置いて、Linux ベースのマシンに Git サーバーをセットアップする方法を説明しています。この手順では、$HOME/.ssh/authorize_keys
フォルダーにキーを追加するための小さなサーバーがセットアップされ、ビルダー がリポジトリーのクローンを作成するためのアクセスが提供されます。
公式にサポートされていない Git リポジトリー管理ソフトウェアの場合、通常、Deploy Keys というラベルが付いたキーを入力する場所があります。
6.1.1.1.2. Webhook
ビルドを自動的にトリガーするには、次の形式を使用して .json
ペイロードを Webhook URL に POST
する必要があります。
このリクエストが有効であるためには、application/json
を含む Content-Type
ヘッダーが必要です。
Webhook の例
{ "commit": "1c002dd", // required "ref": "refs/heads/master", // required "default_branch": "master", // required "commit_info": { // optional "url": "gitsoftware.com/repository/commits/1234567", // required "message": "initial commit", // required "date": "timestamp", // required "author": { // optional "username": "user", // required "avatar_url": "gravatar.com/user.png", // required "url": "gitsoftware.com/users/user" // required }, "committer": { // optional "username": "user", // required "avatar_url": "gravatar.com/user.png", // required "url": "gitsoftware.com/users/user" // required } } }
これは通常、post-receive
Git フック を使用して実現できますが、サーバーのセットアップによって異なります。
6.1.2. ビルドトリガーのタグ命名
Red Hat Quay ではカスタムタグを使用できます。
1 つの方法として、ビルドした各イメージにタグとして割り当てる文字列を含める方法があります。または、ビルドトリガーの Configure Tagging セクションで次のタグテンプレートを使用して、各コミットからの情報でイメージにタグ付けすることもできます。
- ${commit}: 発行されたコミットの完全な SHA
- ${parsed_ref.branch}: ブランチ情報 (利用可能な場合)
- ${parsed_ref.tag}: タグ情報 (利用可能な場合)
- ${parsed_ref.remote}: リモート名
- ${commit_info.date}: コミットが発行された日付
- ${commit_info.author.username}: コミットの作成者のユーザー名
- ${commit_info.short_sha}: コミット SHA の最初の 7 文字
- ${committer.properties.username}: コミッターのユーザー名
以上がすべてではありませんが、これらはタグ付けに最も役立つタグテンプレートです。完全なタグテンプレートスキーマは、こちらのページ を参照してください。
詳細は、Set up custom tag templates in build triggers for Red Hat Quay and Quay.io を参照してください。
6.1.3. ソースコントロールをトリガーとしたビルドのスキップ
ビルドシステムがコミットを無視するように指定するには、コミットメッセージの任意の場所に [skip build]
または [build skip]
というテキストを追加します。
6.2. ビルドの手動トリガー
次の手順を使用して、ビルド を手動でトリガーできます。
手順
- Builds ページで、Start new build をクリックします。
- プロンプトが表示されたら、Invoke Build Trigger を選択します。
- Run Trigger Now をクリックして、プロセスを手動で開始します。
ビルドを開始するコミット ID を入力します (例:
1c002dd
)。ビルドが開始したら、Repository Builds ページで ビルド ID を確認できます。
ビルド のステータスを確認するには、Build History ページでコミットをクリックするか、次のコマンドを実行します。
$ oc get pods -n virtual-builders
出力例
NAME READY STATUS RESTARTS AGE f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2 1/1 Running 0 7s
ビルド の完了後、
oc get pods -n virtual-builders
コマンドはリソースを返しません。$ oc get pods -n virtual-builders
出力例
No resources found in virtual-builders namespace.
第7章 GitHub での OAuth アプリケーションの作成
次のセクションでは、OAuth アプリケーションを作成して Red Hat Quay が GitHub と統合することを許可する方法を説明します。これにより、Red Hat Quay はユーザーに代わって GitHub リポジトリーにアクセスできるようになります。
GitHub との OAuth 統合は主に、自動ビルドなどの機能を許可にするために使用されます。Red Hat Quay を有効にすると、コミットやプルリクエストなどの変更について特定の GitHub リポジトリーを監視し、それらの変更が行われたときにコンテナーイメージビルドをトリガーできます。
7.1. GitHub アプリケーションの新規作成
Github で OAuth アプリケーションを作成するには、次の手順を実行します。
手順
- GitHub Enterprise にログインします。
- ナビゲーションペインで、ユーザー名 → Your organizations を選択します。
- ナビゲーションペインで、Applications → Developer Settings を選択します。
ナビゲーションペインで、OAuth Apps → New OAuth App をクリックします。次のページに移動します:
- Application name テキストボックスにアプリケーションの名前を入力します。
Homepage URL テキストボックスに、Red Hat Quay URL を入力します。
注記公開されている GitHub を使用する場合、入力するホームページの URL は、ユーザーがアクセスできるものである必要があります。その URL が内部用のままである可能性があります。
- Authorization callback URL に、https://<RED_HAT_QUAY_URL>/oauth2/github/callback と入力します。
- Register application をクリックして設定を保存します。
- 新しいアプリケーションの概要が表示されたら、新しいアプリケーションに対して表示されたクライアント ID とクライアントシークレットを記録します。
第8章 ビルドのトラブルシューティング
ビルドマネージャー が起動した ビルダー インスタンスは、一時的なものです。これは、タイムアウトまたは失敗時に Red Hat Quay によってシャットダウンされるか、コントロールプレーン (EC2/K8s) によってガベージコレクションされることを意味します。ビルド ログを取得するには、ビルド の実行中に取得する必要があります。
8.1. DEBUG 設定フラグ
ビルダー インスタンスが完了または失敗後にクリーンアップされないようにするには、DEBUG
フラグを true
に設定します。以下に例を示します。
EXECUTORS: - EXECUTOR: ec2 DEBUG: true ... - EXECUTOR: kubernetes DEBUG: true ...
true
に設定すると、デバッグ機能により、quay-builder
サービスが完了または失敗した後の ビルドノード のシャットダウンを阻止します。また、ビルドマネージャー が EC2 インスタンスを終了したり、Kubernetes ジョブを削除したりして、インスタンスをクリーンアップすることも阻止します。これにより、ビルダーノード の問題をデバッグできます。
デバッグは実稼働サイクルでは設定しないでください。設定しても、ライフタイムサービスが残ります。そのため、たとえばインスタンスが約 2 時間後にシャットダウンします。これが発生すると、EC2 インスタンスが終了し、Kubernetes ジョブが完了します。
デバッグを有効にすると、終了していないインスタンスとジョブも実行中のワーカーの総数にカウントされるため、ALLOWED_WORKER_COUNT
にも影響します。その結果、ALLOWED_WORKER_COUNT
に達した場合は、新しい ビルド をスケジュールできるように、既存の ビルダーワーカー を手動で削除する必要があります。
8.2. OpenShift Container Platform および Kubernetes ビルドのトラブルシューティング
OpenShift Container Platform Kubernetes ビルドのトラブルシューティングを行うには、次の手順を実行します。
手順
次のコマンドを入力して、ローカルマシンと OpenShift Container Platform クラスターまたは Kubernetes クラスターのいずれかで実行されている Pod の間にポート転送トンネルを作成します。
$ oc port-forward <builder_pod> 9999:2222
指定した SSH 鍵とポートを使用して、リモートホストへの SSH 接続を確立します。次に例を示します。
$ ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost
次のコマンドを入力して、
quay-builder
サービスログを取得します。$ systemctl status quay-builder
$ journalctl -f -u quay-builder