ビルダーとイメージの自動化

Red Hat Quay 3.15

ビルダーとイメージの自動化

Red Hat OpenShift Documentation Team

法律上の通知

概要

ビルダーと、イメージビルドの自動化におけるそのロールを理解します。

はじめに
リンクのコピー

このガイドでは、ベアメタルマシンと仮想マシンの両方で 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
├── .git
├── Dockerfile
├── file
└── subdir
    └── Dockerfile

Copy to Clipboard

Toggle word wrap

上記の 展開されたビルドアーカイブ は、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]
<quayregistry-name>-quay-builder-<namespace>.<domain-name>:443
# ...

Copy to Clipboard

Toggle word wrap

以下に例を示します。

# ...
[alt_names]
example-registry-quay-builder-quay-enterprise.apps.cluster-new.gcp.quaydev.org:443
# ...

# ...
[alt_names]
example-registry-quay-builder-quay-enterprise.apps.cluster-new.gcp.quaydev.org:443
# ...

Copy to Clipboard

Toggle word wrap

第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
```
```
$ oc new-project bare-metal-builder
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、bare-metal-builder namespace に新しい ServiceAccount を作成します。
```
oc create sa -n bare-metal-builder quay-builder
```
```
$ oc create sa -n bare-metal-builder quay-builder
```
Copy to Clipboard Toggle word wrap

次のコマンドを入力して、ユーザーに bare-metal-builder namespace 内での edit ロールを付与します。

oc policy add-role-to-user -n bare-metal-builder edit system:serviceaccount:bare-metal-builder:quay-builder

$ oc policy add-role-to-user -n bare-metal-builder edit system:serviceaccount:bare-metal-builder:quay-builder

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、bare-metal-builder namespace の quay-builder サービスアカウントに関連付けられたトークンを取得します。このトークンは、OpenShift Container Platform クラスターの API サーバーの認証と対話に使用されます。
1. OpenShift Container Platform クラスターのバージョンが 4.11 以上の場合は、次のコマンドを入力します。
  oc create token quay-builder -n bare-metal-builder --duration 24h
  Copy to Clipboard Toggle word wrap
2. OpenShift Container Platform クラスターがバージョン 4.11 より前 (たとえばバージョン 4.10) の場合は、次のコマンドを入力します。
  $ oc sa get-token -n bare-metal-builder quay-builder
  Copy to Clipboard Toggle word wrap
OpenShift Container Platform クラスターの API サーバーの URL を特定します。これは、OpenShift Container Platform Web コンソールで確認できます。
ビルドジョブ をスケジュールするときに使用するワーカーノードラベルを識別します。ビルド Pod はベアメタルワーカーノード上で実行する必要があるため、これらは通常、特定のラベルで識別されます。
どのノードラベルを使用すべきかは、クラスター管理者に確認してください。
Red Hat Quay の追加証明書に追加するには、Kube API Server の認証局 (CA) を取得します。
1. OpenShift Container Platform バージョン 4.15 以降では、次のコマンドを入力して、CA を含むシークレットの名前を取得します。
  $ oc extract cm/kube-root-ca.crt -n openshift-apiserver
  Copy to Clipboard Toggle word wrap
  $ mv ca.crt build_cluster.crt
  Copy to Clipboard Toggle word wrap
2. 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
  Copy to Clipboard Toggle word wrap
3. OpenShift Container Platform Web コンソールで、シークレットから ca.crt キーの値を取得します。値は "-----BEGIN CERTIFICATE-----"` で始まります。
4. 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

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

Copy to Clipboard

Toggle word wrap

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 
BUILD_MANAGER:
- ephemeral
- ALLOWED_WORKER_COUNT: 10
  ORCHESTRATOR_PREFIX: buildman/production/
    ORCHESTRATOR:
      REDIS_HOST: <sample_redis_hostname> 
      REDIS_PASSWORD: ""
      REDIS_SSL: false
      REDIS_SKIP_KEYSPACE_EVENT_SETUP: false
  EXECUTORS:
  - EXECUTOR: kubernetes
    BUILDER_NAMESPACE: <sample_builder_namespace> 
    K8S_API_SERVER: <sample_k8s_api_server> 
    K8S_API_TLS_CA: <sample_crt_file> 
    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: 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> 
    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: 
    - <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>

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


BUILD_MANAGER:
- ephemeral
- ALLOWED_WORKER_COUNT: 10
  ORCHESTRATOR_PREFIX: buildman/production/
    ORCHESTRATOR:
      REDIS_HOST: <sample_redis_hostname>


      REDIS_PASSWORD: ""
      REDIS_SSL: false
      REDIS_SKIP_KEYSPACE_EVENT_SETUP: false
  EXECUTORS:
  - EXECUTOR: kubernetes
    BUILDER_NAMESPACE: <sample_builder_namespace>


    K8S_API_SERVER: <sample_k8s_api_server>


    K8S_API_TLS_CA: <sample_crt_file>


    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: 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>


    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:


    - <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>

Copy to Clipboard

Toggle word wrap

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}
```
```
$ kubectl get -n <namespace> route <quayregistry-name>-quay-builder -o jsonpath={.status.ingress[0].host}
```
Copy to Clipboard Toggle word wrap
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> 
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
    ...
```
```
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
    ...
```
Copy to Clipboard Toggle word wrap
1
ビルドジョブ が ビルドマネージャー と通信するために使用する、外部からアクセス可能なサーバーホスト名です。デフォルトは SERVER_HOSTNAME と同じです。OpenShift route リソースの場合、これは status.ingress[0].host か、カスタムホスト名を使用している場合は CNAME エントリーのいずれかになります。BUILDMAN_HOSTNAME には、ポート番号を含める必要があります (例: OpenShift Container Platform route の場合は 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
```
```
$ oc new-project virtual-builders
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、ビルド の実行に使用されるプロジェクトに ServiceAccount を作成します。
```
oc create sa -n virtual-builders quay-builder
```
```
$ oc create sa -n virtual-builders quay-builder
```
Copy to Clipboard Toggle word wrap
出力例
```
serviceaccount/quay-builder created
```
```
serviceaccount/quay-builder created
```
Copy to Clipboard Toggle word wrap

作成されたサービスアカウントに編集権限を付与して、ビルド を実行できるようにします。

oc adm policy -n virtual-builders add-role-to-user edit system:serviceaccount:virtual-builders:quay-builder

$ oc adm policy -n virtual-builders add-role-to-user edit system:serviceaccount:virtual-builders:quay-builder

Copy to Clipboard

Toggle word wrap

出力例

clusterrole.rbac.authorization.k8s.io/edit added: "system:serviceaccount:virtual-builders:quay-builder"

clusterrole.rbac.authorization.k8s.io/edit added: "system:serviceaccount:virtual-builders:quay-builder"

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、ビルダー ワーカーに anyuid scc 権限を付与します。これにはクラスター管理者権限が必要です。これは、権限のないビルドまたはルートレスビルドが機能するためには、ビルダー を Podman ユーザーとして実行する必要があるために必要です。
```
oc adm policy -n virtual-builders add-scc-to-user anyuid -z quay-builder
```
```
$ oc adm policy -n virtual-builders add-scc-to-user anyuid -z quay-builder
```
Copy to Clipboard Toggle word wrap
出力例
```
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "quay-builder"
```
```
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "quay-builder"
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、builder サービスアカウントのトークンを取得します。
```
oc create token quay-builder -n virtual-builders
```
```
$ oc create token quay-builder -n virtual-builders
```
Copy to Clipboard Toggle word wrap
注記
トークンの有効期限が切れたら、新しいトークンを要求する必要があります。必要に応じて、カスタムの有効期限を追加することもできます。たとえば、トークンを 2 週間保持するには、--duration 20160m と指定します。
出力例
```
eyJhbGciOiJSUzI1NiIsImtpZCI6IldfQUJkaDVmb3ltTHZ0dGZMYjhIWnYxZTQzN2dJVEJxcDJscldSdEUtYWsifQ...
```
```
eyJhbGciOiJSUzI1NiIsImtpZCI6IldfQUJkaDVmb3ltTHZ0dGZMYjhIWnYxZTQzN2dJVEJxcDJscldSdEUtYWsifQ...
```
Copy to Clipboard Toggle word wrap

次のコマンドを入力して、ビルダー ルートを決定します。

oc get route -n quay-enterprise

$ oc get route -n quay-enterprise

Copy to Clipboard

Toggle word wrap

出力例

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

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

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、.crt エクステンションを持つ自己署名 SSL/TLS 証明書を生成します。
```
oc extract cm/kube-root-ca.crt -n openshift-apiserver
```
```
$ oc extract cm/kube-root-ca.crt -n openshift-apiserver
```
Copy to Clipboard Toggle word wrap
出力例
```
ca.crt
```
```
ca.crt
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、ca.crt ファイルの名前を build-cluster.crt に変更します。
```
mv ca.crt build-cluster.crt
```
```
$ mv ca.crt build-cluster.crt
```
Copy to Clipboard Toggle word wrap

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> 
BUILD_MANAGER:
  - ephemeral
  - ALLOWED_WORKER_COUNT: 1
    ORCHESTRATOR_PREFIX: buildman/production/
    JOB_REGISTRATION_TIMEOUT: 3600 
    ORCHESTRATOR:
      REDIS_HOST: <sample_redis_hostname> 
      REDIS_PASSWORD: ""
      REDIS_SSL: false
      REDIS_SKIP_KEYSPACE_EVENT_SETUP: false
    EXECUTORS:
      - EXECUTOR: kubernetesPodman
        NAME: openshift
        BUILDER_NAMESPACE: <sample_builder_namespace> 
        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> 
        K8S_API_TLS_CA: <sample_crt_file> 
        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: <sample_service_account_name>
        SERVICE_ACCOUNT_TOKEN: <sample_account_token> 
        HTTP_PROXY: <http://10.0.0.1:80>
        HTTPS_PROXY: <http://10.0.0.1:80>
        NO_PROXY: <hostname.example.com>

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>


BUILD_MANAGER:
  - ephemeral
  - ALLOWED_WORKER_COUNT: 1
    ORCHESTRATOR_PREFIX: buildman/production/
    JOB_REGISTRATION_TIMEOUT: 3600


    ORCHESTRATOR:
      REDIS_HOST: <sample_redis_hostname>


      REDIS_PASSWORD: ""
      REDIS_SSL: false
      REDIS_SKIP_KEYSPACE_EVENT_SETUP: false
    EXECUTORS:
      - EXECUTOR: kubernetesPodman
        NAME: openshift
        BUILDER_NAMESPACE: <sample_builder_namespace>


        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>


        K8S_API_TLS_CA: <sample_crt_file>


        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: <sample_service_account_name>
        SERVICE_ACCOUNT_TOKEN: <sample_account_token>


        HTTP_PROXY: <http://10.0.0.1:80>
        HTTPS_PROXY: <http://10.0.0.1:80>
        NO_PROXY: <hostname.example.com>

Copy to Clipboard

Toggle word wrap

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>

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>

Copy to Clipboard

Toggle word wrap

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
      }
  ]

  [
      {
          "AllowedHeaders": [
              "Authorization"
          ],
          "AllowedMethods": [
              "GET"
          ],
          "AllowedOrigins": [
              "*"
          ],
          "ExposeHeaders": [],
          "MaxAgeSeconds": 3000
      },
      {
          "AllowedHeaders": [
              "Content-Type",
              "x-amz-acl",
              "origin"
          ],
          "AllowedMethods": [
              "PUT"
          ],
          "AllowedOrigins": [
              "*"
          ],
          "ExposeHeaders": [],
          "MaxAgeSeconds": 3000
      }
  ]

Copy to Clipboard

Toggle word wrap

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

$ cat gcp_cors.json

Copy to Clipboard

Toggle word wrap

出力例

[
    {
      "origin": ["*"],
      "method": ["GET"],
      "responseHeader": ["Authorization"],
      "maxAgeSeconds": 3600
    },
    {
      "origin": ["*"],
      "method": ["PUT"],
      "responseHeader": [
              "Content-Type",
              "x-goog-acl",
              "origin"],
      "maxAgeSeconds": 3600
    }
]

[
    {
      "origin": ["*"],
      "method": ["GET"],
      "responseHeader": ["Authorization"],
      "maxAgeSeconds": 3600
    },
    {
      "origin": ["*"],
      "method": ["PUT"],
      "responseHeader": [
              "Content-Type",
              "x-goog-acl",
              "origin"],
      "maxAgeSeconds": 3600
    }
]

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、GCP ストレージバケットを更新します。
```
gcloud storage buckets update gs://<bucket_name> --cors-file=./gcp_cors.json
```
```
$ gcloud storage buckets update gs://<bucket_name> --cors-file=./gcp_cors.json
```
Copy to Clipboard Toggle word wrap
出力例
```
Updating
  Completed 1
```
```
Updating
  Completed 1
```
Copy to Clipboard Toggle word wrap

次のコマンドを実行すると、GCP バケットの更新された CORS 設定を表示できます。

gcloud storage buckets describe gs://<bucket_name>  --format="default(cors)"

$ gcloud storage buckets describe gs://<bucket_name>  --format="default(cors)"

Copy to Clipboard

Toggle word wrap

出力例

cors:
- maxAgeSeconds: 3600
  method:
  - GET
  origin:
  - '*'
  responseHeader:
  - Authorization
- maxAgeSeconds: 3600
  method:
  - PUT
  origin:
  - '*'
  responseHeader:
  - Content-Type
  - x-goog-acl
  - origin

cors:
- maxAgeSeconds: 3600
  method:
  - GET
  origin:
  - '*'
  responseHeader:
  - Authorization
- maxAgeSeconds: 3600
  method:
  - PUT
  origin:
  - '*'
  responseHeader:
  - Content-Type
  - x-goog-acl
  - origin

Copy to Clipboard

Toggle word wrap

第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

$ oc get pods -n virtual-builders

Copy to Clipboard

Toggle word wrap

出力例

NAME                                               READY   STATUS    RESTARTS   AGE
f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2   1/1     Running   0          7s

NAME                                               READY   STATUS    RESTARTS   AGE
f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2   1/1     Running   0          7s

Copy to Clipboard

Toggle word wrap

ビルド の完了後、oc get pods -n virtual-builders コマンドはリソースを返しません。
```
oc get pods -n virtual-builders
```
```
$ oc get pods -n virtual-builders
```
Copy to Clipboard Toggle word wrap
出力例
```
No resources found in virtual-builders namespace.
```
```
No resources found in virtual-builders namespace.
```
Copy to Clipboard Toggle word wrap

第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 on OpenShift Container Platform デプロイメントの場合、ベアメタルビルドまたは仮想ビルドのいずれかに対して OpenShift Container Platform 環境を設定している。

手順

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 を選択することで利用できます。

リポジトリーからのタグの表示および変更

Trigger 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
    }
  }
}

{
  "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
    }
  }
}

Copy to Clipboard

Toggle word wrap

これは通常、post-receive Git フックを使用して実現できますが、サーバーのセットアップによって異なります。

6.1.2. ビルドトリガーのタグ命名
リンクのコピー

Red Hat Quay ではカスタムタグを使用できます。

1 つの方法として、ビルドした各イメージにタグとして割り当てる文字列を含める方法があります。または、ビルドトリガーの Configure Tagging セクションで次のタグテンプレートを使用して、各コミットからの情報でイメージにタグ付けすることもできます。

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

$ oc get pods -n virtual-builders

Copy to Clipboard

Toggle word wrap

出力例

NAME                                               READY   STATUS    RESTARTS   AGE
f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2   1/1     Running   0          7s

NAME                                               READY   STATUS    RESTARTS   AGE
f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2   1/1     Running   0          7s

Copy to Clipboard

Toggle word wrap

ビルド の完了後、oc get pods -n virtual-builders コマンドはリソースを返しません。
```
oc get pods -n virtual-builders
```
```
$ oc get pods -n virtual-builders
```
Copy to Clipboard Toggle word wrap
出力例
```
No resources found in virtual-builders namespace.
```
```
No resources found in virtual-builders namespace.
```
Copy to Clipboard Toggle word wrap

第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
      ...

  EXECUTORS:
    - EXECUTOR: ec2
      DEBUG: true
      ...
    - EXECUTOR: kubernetes
      DEBUG: true
      ...

Copy to Clipboard

Toggle word wrap

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
```
```
$ oc port-forward <builder_pod> 9999:2222
```
Copy to Clipboard Toggle word wrap
指定した SSH 鍵とポートを使用して、リモートホストへの SSH 接続を確立します。次に例を示します。
```
ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost
```
```
$ ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、quay-builder サービスログを取得します。
```
systemctl status quay-builder
```
```
$ systemctl status quay-builder
```
Copy to Clipboard Toggle word wrap
```
journalctl -f -u quay-builder
```
```
$ journalctl -f -u quay-builder
```
Copy to Clipboard Toggle word wrap

法律上の通知
リンクのコピー

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

ビルダーとイメージの自動化