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


Red Hat Quay 3.14

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

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 という 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 にログインしている。

手順

  1. ビルドが実行されるプロジェクト (例: bare-metal-builder) を作成するには、次のコマンドを入力します。

    $ oc new-project bare-metal-builder
  2. 次のコマンドを入力して、bare-metal-builder namespace に新しい ServiceAccount を作成します。

    $ oc create sa -n bare-metal-builder quay-builder
  3. 次のコマンドを入力して、ユーザーに bare-metal-builder namespace 内での edit ロールを付与します。

    $ oc policy add-role-to-user -n bare-metal-builder edit system:serviceaccount:bare-metal-builder:quay-builder
  4. 次のコマンドを入力して、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
    2. OpenShift Container Platform クラスターがバージョン 4.11 より前 (たとえばバージョン 4.10) の場合は、次のコマンドを入力します。

      $ oc sa get-token -n bare-metal-builder quay-builder
  5. OpenShift Container Platform クラスターの API サーバーの URL を特定します。これは、OpenShift Container Platform Web コンソールで確認できます。
  6. ビルドジョブ をスケジュールするときに使用するワーカーノードラベルを識別します。ビルド Pod はベアメタルワーカーノード上で実行する必要があるため、これらは通常、特定のラベルで識別されます。

    どのノードラベルを使用すべきかは、クラスター管理者に確認してください。

  7. Red Hat Quay の追加証明書に追加するには、Kube API Server の認証局 (CA) を取得します。

    1. OpenShift Container Platform バージョン 4.15 以降では、次のコマンドを入力して、CA を含むシークレットの名前を取得します。

      $ oc extract cm/kube-root-ca.crt -n openshift-apiserver
      $ mv ca.crt build_cluster.crt
    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
    3. OpenShift Container Platform Web コンソールで、シークレットから ca.crt キーの値を取得します。値は "-----BEGIN CERTIFICATE-----"` で始まります。
    4. CA を Red Hat Quay にインポートします。このファイルの名前が、手順 9 で使用した K8S_API_TLS_CA フィールドと一致していることを確認します。
  8. 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
  9. OpenShift Container Platform Web コンソールを使用して、Red Hat Quay on OpenShift Container Platform デプロイメントの config.yaml ファイルを更新し、適切な ベアメタルビルド 設定を含めます。

    1. OperatorsInstalled OperatorsRed Hat QuayQuay Registry をクリックします。
    2. レジストリーの名前 (例: example-registry) をクリックします。
    3. Config Bundle Secret の下で、設定バンドルの名前 (例: extra-ca-certificate-config-bundle-secret) をクリックします。
    4. ActionsEdit Secret をクリックします。
    5. 以下の情報を 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
  10. ビルド 機能を有効にするには、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 を使用して、QuayRegistryspec.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 と同じです。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 Objectquay-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 にログインしている。

手順

  1. 次のコマンドを実行して、仮想ビルダーが実行される新しいプロジェクト (virtual-builders など) を作成します。

    $ oc new-project virtual-builders
  2. 次のコマンドを入力して、ビルド の実行に使用されるプロジェクトに ServiceAccount を作成します。

    $ oc create sa -n virtual-builders quay-builder

    出力例

    serviceaccount/quay-builder created

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

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

  4. 次のコマンドを入力して、ビルダー ワーカーに 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"

  5. 次のコマンドを入力して、builder サービスアカウントのトークンを取得します。

    $ oc create token quay-builder -n virtual-builders
    注記

    トークンの有効期限が切れたら、新しいトークンを要求する必要があります。必要に応じて、カスタムの有効期限を追加することもできます。たとえば、トークンを 2 週間保持するには、--duration 20160m と指定します。

    出力例

    eyJhbGciOiJSUzI1NiIsImtpZCI6IldfQUJkaDVmb3ltTHZ0dGZMYjhIWnYxZTQzN2dJVEJxcDJscldSdEUtYWsifQ...

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

    $ 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

  7. 次のコマンドを入力して、.crt エクステンションを持つ自己署名 SSL/TLS 証明書を生成します。

    $ oc extract cm/kube-root-ca.crt -n openshift-apiserver

    出力例

    ca.crt

  8. 次のコマンドを入力して、ca.crt ファイルの名前を build-cluster.crt に変更します。

    $ mv ca.crt build-cluster.crt
  9. OpenShift Container Platform Web コンソールを使用して、Red Hat Quay on OpenShift Container Platform デプロイメントの config.yaml ファイルを更新し、適切な 仮想ビルド 設定を含めます。

    1. OperatorsInstalled OperatorsRed Hat QuayQuay Registry をクリックします。
    2. レジストリーの名前 (例: example-registry) をクリックします。
    3. Config Bundle Secret の下で、設定バンドルの名前 (例: extra-ca-certificate-config-bundle-secret) をクリックします。
    4. ActionsEdit Secret をクリックします。
    5. 以下を参考にして適切な 仮想ビルド 設定を追加します。

      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>

    6. Edit Secret ページで Save をクリックします。
  10. 新しい設定を使用して、OpenShift Container Platform レジストリー上の Red Hat Quay を再起動します。

4.2.1. AWS S3 ストレージバケットの変更

AWS S3 ストレージを使用している場合は、ビルド を開始する前に AWS コンソールでストレージバケットを変更する必要があります。

手順

  1. s3.console.aws.com で AWS コンソールにログインします。
  2. 検索バーで S3 を検索し、S3 をクリックします。
  3. バケットの名前 (myawsbucket など) をクリックします。
  4. Permissions タブをクリックします。
  5. 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 のアップロードは失敗します。

手順

  1. 次のリファレンスを使用して、特定の 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
        }
    ]

  2. 次のコマンドを入力して、GCP ストレージバケットを更新します。

    $ gcloud storage buckets update gs://<bucket_name> --cors-file=./gcp_cors.json

    出力例

    Updating
      Completed 1

  3. 次のコマンドを実行すると、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 ページに移動している。
  • ビルド 機能を使用するように環境を設定している。

手順

  1. Builds ページで、Start New Build をクリックします。
  2. プロンプトが表示されたら、Upload Dockerfile をクリックして、ルートディレクトリーに Dockerfile または Dockerfile を含むアーカイブをアップロードします。
  3. Start Build をクリックします。

    注記
    • 現在、ユーザーは手動でビルドを開始するときに Docker ビルドコンテキストを指定できません。
    • 現在、BitBucket は Red Hat Quay v2 UI ではサポートされていません。
  4. ビルド にリダイレクトされます。ビルドはリアルタイムで確認できます。Dockerfile ビルド が完了してプッシュされるまで待ちます。
  5. オプション: Download Logs をクリックしてログをダウンロードしたり、Copy Logs をクリックしてログをコピーしたりできます。
  6. 戻るボタンをクリックして Repository Builds ページに戻ると、ビルド履歴 を表示できます。

    Build history v2 UI

  7. ビルド のステータスを確認するには、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

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

手順

  1. Red Hat Quay レジストリーにログインします。
  2. ナビゲーションペインで、Repositories をクリックします。
  3. Create Repository をクリックします。
  4. Builds タブをクリックします。
  5. Builds ページで、Create Build Trigger をクリックします。
  6. GithubBitbucketGitlab などの目的のプラットフォームを選択するか、カスタム Git リポジトリーを使用します。この例では、Custom Git Repository Push をクリックします。
  7. カスタム Git リポジトリー名を入力します (例: git@github.com:<username>/<repo>.git)。Next をクリックします。
  8. プロンプトが表示されたら、次のオプションのいずれかまたは両方を選択して、タグ付けオプションを設定します。

    • Tag manifest with the branch or tag name。このオプションを選択すると、ビルドされたマニフェストにブランチの名前または git コミットのタグがタグ付けされます。
    • Add latest tag if on default branch。このオプションを選択すると、リポジトリーのデフォルトブランチでビルドが行われた場合に、ビルドされたマニフェストに latest がタグ付けされます。

      オプションで、カスタムのタグ付けテンプレートを追加できます。ここに入力できるタグテンプレートは複数あります。短い SHA ID、タイムスタンプ、作成者名、コミッター、コミットからのブランチ名をタグとして使用することもできます。詳細は、「ビルドトリガーのタグ命名」を参照してください。

      タグ付けを設定したら、Next をクリックします。

  9. プロンプトが表示されたら、トリガーの呼び出し時にビルドする Dockerfile の場所を選択します。Dockerfile が git リポジトリーのルートにあり、Dockerfile という名前が付けられている場合は、Dockerfile パスとして /Dockerfile を入力します。Next をクリックします。
  10. プロンプトが表示されたら、Docker ビルドのコンテキストを選択します。Dockerfile が Git リポジトリーのルートにある場合は、ビルドコンテキストディレクトリーとして / を入力します。Next をクリックします。
  11. オプション: 任意のロボットアカウントを選択します。これにより、ビルドプロセス中にプライベートのベースイメージをプルできます。プライベートベースイメージが使用されていないことを把握している場合は、この手順を省略できます。
  12. Next をクリックします。検証の警告がないか確認します。必要に応じて、Finish をクリックする前に問題を修正します。
  13. トリガーが正常にアクティベートされたという警告が表示されます。このトリガーを使用するには、以下のアクションが必要になることに注意してください。

    • 以下の公開鍵に git リポジトリーへの読み取りアクセス権を与える必要があります。
    • ビルドをトリガーするには、リポジトリーを POST に設定する必要があります。

      SSH 公開鍵を保存し、Return to <organization_name>/<repository_name> をクリックします。リポジトリーの Builds ページにリダイレクトされます。

  14. Builds ページに、ビルドトリガー が表示されます。以下に例を示します。

    Example Build trigger

    カスタム Git トリガーを作成した後、追加の手順が必要になります。「カスタム Git トリガーのセットアップ」に進みます。

    Github、Gitlab、または Bitbucket の ビルドトリガー をセットアップする場合は、「ビルドの手動トリガー」に進んでください。

6.1.1. カスタム Git トリガーのセットアップ

カスタム Git トリガー を作成した後、次の 2 つの追加手順が必要です。

  1. トリガーの作成時に生成された SSH 公開鍵への読み取りアクセスを付与する必要があります。
  2. ビルドをトリガーする Red Hat Quay のエンドポイントに POST する Webhook をセットアップする必要があります。

これらの手順は、カスタム Git トリガー を使用している場合にのみ必要です。

6.1.1.1. ビルドトリガーの認証情報を取得する

SSH 公開鍵と Webhook エンドポイント URL は、Red Hat Quay UI で利用できます。

前提条件

  • カスタム Git トリガー を作成している。

手順

  1. リポジトリーの Builds ページで、カスタム Git トリガー のメニューケバブをクリックします。
  2. View Credentials をクリックします。
  3. 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
    }
  }
}

これは通常、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. ビルドの手動トリガー

次の手順を使用して、ビルド を手動でトリガーできます。

手順

  1. Builds ページで、Start new build をクリックします。
  2. プロンプトが表示されたら、Invoke Build Trigger を選択します。
  3. Run Trigger Now をクリックして、プロセスを手動で開始します。
  4. ビルドを開始するコミット ID を入力します (例: 1c002dd)。

    ビルドが開始したら、Repository Builds ページで ビルド ID を確認できます。

  5. ビルド のステータスを確認するには、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

  6. ビルド の完了後、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 アプリケーションを作成するには、次の手順を実行します。

手順

  1. GitHub Enterprise にログインします。
  2. ナビゲーションペインで、ユーザー名 → Your organizations を選択します。
  3. ナビゲーションペインで、ApplicationsDeveloper Settings を選択します。
  4. ナビゲーションペインで、OAuth AppsNew OAuth App をクリックします。次のページに移動します:

    Register a new OAuth application

  5. Application name テキストボックスにアプリケーションの名前を入力します。
  6. Homepage URL テキストボックスに、Red Hat Quay URL を入力します。

    注記

    公開されている GitHub を使用する場合、入力するホームページの URL は、ユーザーがアクセスできるものである必要があります。その URL が内部用のままである可能性があります。

  7. Authorization callback URL に、https://<RED_HAT_QUAY_URL>/oauth2/github/callback と入力します。
  8. Register application をクリックして設定を保存します。
  9. 新しいアプリケーションの概要が表示されたら、新しいアプリケーションに対して表示されたクライアント 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 ビルドのトラブルシューティングを行うには、次の手順を実行します。

手順

  1. 次のコマンドを入力して、ローカルマシンと OpenShift Container Platform クラスターまたは Kubernetes クラスターのいずれかで実行されている Pod の間にポート転送トンネルを作成します。

    $ oc port-forward <builder_pod> 9999:2222
  2. 指定した SSH 鍵とポートを使用して、リモートホストへの SSH 接続を確立します。次に例を示します。

    $ ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost
  3. 次のコマンドを入力して、quay-builder サービスログを取得します。

    $ systemctl status quay-builder
    $ journalctl -f -u quay-builder

法律上の通知

Copyright © 2025 Red Hat, Inc.
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.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.