Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

Builds について

builds for Red Hat OpenShift 1.6

Builds の紹介

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、Builds の機能を概説します。リリースノートとサポートを受ける方法の詳細も含まれています。

第1章 Builds の概要
リンクのコピー

Builds は、Shipwright プロジェクト に基づく拡張可能なビルドフレームワークで、OpenShift Container Platform クラスター上でコンテナーイメージを構築するために使用できます。Source-to-Image (S2I) や Buildah などのイメージビルドツールを使用して、ソースコードおよび Dockerfile からコンテナーイメージをビルドできます。OpenShift Container Platform namespace で、ビルドリソースの作成と適用、ビルド実行のログの表示、ビルドの管理を行うことができます。

Builds には以下の機能が含まれます。

  • ソースコードと Dockerfile からコンテナーイメージを構築するための標準 Kubernetes ネイティブ API
  • Source-to-Image (S2I) および Buildah ビルドストラテジーのサポート
  • 独自のカスタムビルドストラテジーによる拡張性
  • ローカルディレクトリー内のソースコードからのビルドの実行
  • Shipwright CLI によるログの作成と表示、およびクラスター上におけるビルドの管理
  • OpenShift Container Platform Web コンソールの Developer パースペクティブと統合されたユーザーエクスペリエンス

Builds は以下のカスタムリソース (CR) で構成します。

  • Build
  • BuildStrategy および ClusterBuildStrategy
  • BuildRun

1.1. Build リソース
リンクのコピー

Build リソースは、アプリケーションのソースコードと、アプリケーションイメージをプッシュする場所を定義します。次の例は、Git ソース、ビルドストラテジー、出力イメージで構成される単純なビルドを示しています。 

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
spec:
  source:
    git:
      url: https://github.com/username/taxi
  strategy:
    name: buildah
    kind: ClusterBuildStrategy
  output:
    image: registry.mycompany.com/my-org/taxi-app:latest
Copy to Clipboard Toggle word wrap

また、Build リソースを拡張してイメージをプライベートレジストリーにプッシュしたり、Dockerfile ファイルを使用したりすることもできます。

1.2. BuildStrategy および ClusterBuildStrategy リソース
リンクのコピー

BuildStrategy および ClusterBuildStrategy リソースは、アプリケーションをアセンブルする一連のステップを定義します。namespace では BuildStrategy リソースを使用でき、クラスターでは ClusterBuildStrategy リソースを使用できます。

BuildStrategy または ClusterBuildStrategy リソースの仕様は、steps オブジェクトで構成されます。以下の例は、buildah クラスタービルドストラテジーの仕様を示しています。 

apiVersion: shipwright.io/v1beta1
kind: ClusterBuildStrategy
metadata:
  name: buildah
spec:
  steps:
    - name: build-and-push
      image: quay.io/containers/buildah:v1.31.0
      workingDir: $(params.shp-source-root)
      command:
        - /bin/bash
       # ...
# ...
Copy to Clipboard Toggle word wrap

1.3. BuildRun リソース
リンクのコピー

BuildRun リソースは、クラスタージョブや Tekton タスク実行と同様に、クラスターのビルドを呼び出します。BuildRun リソースはクラスター上のワークロードを表し、その結果 Pod が実行します。BuildRun は、ビルドで実行中のインスタンスです。クラスター上で特定のパラメーターを使用して実行するビルドをインスタンス化します。

BuildRun リソースを使用すると、以下の要素を定義できます。

  • ビルドのステータスを監視する一意の BuildRun 名
  • ビルド中に使用する、参照される Build インスタンス
  • ビルドの全シークレットをホストするサービスアカウント

各 BuildRun リソースは、namespace 内で利用できます。

1.4. ビルドコントローラー
リンクのコピー

ビルドコントローラーは、Build リソースの更新を監視し、以下のタスクを実行します。

  • 参照される Strategy オブジェクトが Build リソースに存在するかどうかを検証します。
  • Build CR で指定されたパラメーターが参照されたビルドストラテジーに存在するかどうかを検証します。また、パラメーター名が予約された名前と競合するかどうかも検証します。
  • コンテナーレジストリーの出力シークレットが Build リソースに存在するかどうかを検証します。
  • 参照される spec.source.git.url エンドポイント URL が Build リソースに存在するかどうかを検証します。

build run controller は、Build または TaskRun リソースの更新を監視し、以下のタスクを実行します。

  • 既存の TaskRun リソースを検索し、その親 BuildRun リソースのステータスを更新します。
  • 指定したサービスアカウントを取得し、Build リソースの出力シークレットと共に設定します。
  • TaskRun リソースが存在しない場合は、コントローラーが新しい Tekton TaskRun リソースを生成し、TaskRun リソースへの参照を設定します。
  • TaskRun リソースの後続の更新では、コントローラーが親の BuildRun リソースを更新します。

1.4.1. ビルドの検証
リンクのコピー

BuildRun リソースのトリガーを回避して、依存関係や設定が正しくない、または欠落していることが原因で失敗しないように、ビルドコントローラーがこのような内容を事前に検証します。すべての検証が成功すると、Succeeded という名前の status.reason フィールドが表示されます。ただし、検証が失敗した場合は、status.reason フィールドと status.message フィールドをチェックして根本原因を理解する必要があります。

Expand
表1.1 ビルドコントローラーによるビルドの検証
status.reason フィールド説明

BuildStrategyNotFound

namespace レベルで参照されているストラテジーは存在しません。

ClusterBuildStrategyNotFound

クラスターレベルで参照されているストラテジーは存在しません。

SetOwnerReferenceFailed

Build リソースと BuildRun リソース間の所有者参照の設定に失敗しました。このステータスは、ビルドで spec.retention.atBuildDeletion フィールドを true に設定するとトリガーされます。

SpecSourceSecretRefNotFound

Git への認証に使用されるシークレットは存在しません。

SpecOutputSecretRefNotFound

コンテナーレジストリーに対する認証に使用されるシークレットが存在しません。

SpecBuilderSecretRefNotFound

コンテナーレジストリーに対する認証に使用されるシークレットが存在しません。

MultipleSecretRefNotFound

認証に使用されるシークレットが複数欠落しています。

RestrictedParametersInUse

1 つまたは複数の定義済み params が予約済みパラメーターと競合しています。

UndefinedParameter

パラメーターは参照されたストラテジーでは定義されません。これらのパラメーターは、ストラテジーの spec.parameters 仕様で定義する必要があります。

RemoteRepositoryUnreachable

定義された spec.source.git.url 仕様が見つかりませんでした。この検証は、HTTP および HTTPS プロトコルに対してのみ行われます。

BuildNameInvalid

metadata.name フィールドのビルド名が無効です。ビルド名には有効なラベル値を使用する必要があります。

SpecEnvNameCanNotBeBlank

ユーザー指定の環境変数の名前が空白であることを示します。

SpecEnvValueCanNotBeBlank

ユーザー指定の環境変数の値が空白であることを示します。

第2章 ビルドストラテジー
リンクのコピー

OpenShift Container Platform クラスターでは、厳選されたビルドストラテジーまたはクラスタービルドストラテジーのセットを使用できます。これらのストラテジーは、Builds for Red Hat OpenShift Operator によって自動的にインストールされ、使用可能になります。このストラテジーの自動インストールにより、ビルドをすぐに開始できます。

ビルドは、以下のクラスタービルドストラテジーをサポートします。

  • buildah: すべてのプラットフォームでサポートされています。
  • source-to-image: Linux/amd64 プラットフォームでサポートされています。
  • buildpacks: すべてのプラットフォームでサポートされています。
  • buildpacks-extender: すべてのプラットフォームでサポートされています。

2.1. Buildah
リンクのコピー

buildah クラスターのビルドストラテジーは、Dockerfile を使用してコンテナーイメージをビルドし、それをターゲットレジストリーにプッシュします。Build CR の spec.paramValues フィールドに Dockerfile を指定する必要があります。

Builds for Red Hat OpenShift Operator は buildah ストラテジーをクラスターレベルでインストールするため、クラスター内の異なる名前空間間で buildah ストラテジーを共有できます。

buildah ストラテジーに対して次のパラメーターを設定できます。

Expand
表2.1 buildah の設定パラメーター
名前型説明デフォルト

build-args

array

ビルド中に使用される Dockerfile で必要な引数のキーと値のペア

[]

registries-block

array

ブロックする必要があるレジストリーのリスト

[]

registries-insecure

array

セキュアでないレジストリーとその完全修飾ドメイン名 (FQDN) のリスト

[]

registries-search

array

短縮名のイメージを検索するためのレジストリーのリスト

["registry.redhat.io", "quay.io"]

dockerfile

string

ビルド中に使用される Dockerfile のパス

"Dockerfile"

storage-driver

string

buildah によって使用されるストレージドライバー (overlay や vfs など)

"vfs"

target

string

ビルドするターゲットステージを設定します。

""

注記

詳細は、ビルドストラテジーの設定 を参照してください。

2.2. Source-to-Image
リンクのコピー

このビルドストラテジーは、source-to-image および buildah で構成されます。このストラテジーを使用して、コンテナーファイルを生成し、ビルダーイメージでアプリケーションをビルドする準備を行うことができます。Build CR の spec.paramValues フィールドにビルダーイメージを指定する必要があります。

Builds for Red Hat OpenShift Operator は source-to-image ストラテジーをクラスターレベルでインストールするため、クラスター内の異なる namespace 間で source-to-image ストラテジーを共有できます。

source-to-image ストラテジーに対して次のパラメーターを設定できます。

Expand
表2.2 source-to-image の設定パラメーター
名前型説明デフォルト

registries-block

array

ブロックする必要があるレジストリーのリスト

[]

registries-insecure

array

セキュアでないレジストリーとその FQDN のリスト

[]

registries-search

array

短縮名のイメージを検索するためのレジストリーのリスト

["registry.redhat.io", "quay.io"]

builder-image

string

ビルド中に使用されるビルダーイメージの場所

NA

storage-driver

string

オーバーレイや vfs など、source-to-image で使用されるストレージドライバー

"vfs"

2.3. Buildpacks
リンクのコピー

buildpacks クラスタービルドストラテジーは、Dockerfile を必要とせずに、Cloud Native Buildpacks (CNB) を使用してソースコードからコンテナーイメージをビルドしてプッシュします。設定の詳細は、Build リソースのパラメーターにより提供されます。

buildpacks-extender クラスタービルドストラテジーは、buildpacks ストラテジーによって提供されるすべての機能に加えて、CNB のイメージ拡張機能をサポートしています。buildpacks-extender を使用すると、ビルダーを変更したり、Dockerfile を使用してイメージを実行したりできます。これは、システム依存関係をインストールしたり、標準の Buildpacks では処理できないセキュリティー設定を適用したりするのに役立ちます。Dockerfile は拡張をサポートしている Buildpack によって提供されます。extender を使用するには、Build リソースで cnb-extender-kind パラメーターを設定します。

注記

buildpacks クラスタービルドストラテジーは、Quarkus および Go ベースのアプリケーションをサポートしています。一方、buildpacks-extender クラスタービルドストラテジーは、Node.js および Python ベースのアプリケーションをサポートしています。

buildpacks ストラテジーには次のパラメーターを設定できます。

Expand
表2.3 buildpacks の設定パラメーター
名前型説明デフォルト

cnb-platform-api

string

サポートされているプラットフォーム API バージョン

"0.12"

cnb-builder-image

string

buildpacks を含むビルダーイメージ

""

cnb-lifecycle-image

string

ライフサイクルフェーズの実行中に使用するイメージ

"buildpacksio/lifecycle:0.20.8"

cnb-log-level

string

ロギングレベル

"debug"

run-image

string

使用する実行イメージへの参照

""

cache-image

string

永続的なアプリケーションキャッシュイメージの名前

""

source-subpath

string

ビルドするソースが配置されているソース入力内のサブパス

""

env-vars

array

ビルド時に設定する環境変数

[]

platform-dir

string

プラットフォームディレクトリーの名前

"empty-dir"

user-id

string

ビルダーイメージユーザーのユーザー ID

"1001"

group-id

string

ビルダーイメージユーザーのグループ ID

"1001"

user-home

string

ユーザーのホームディレクトリーへの絶対パス

"/tekton/home"

cache-pvc-name

string

キャッシュの永続ボリューム要求の名前

"ws-pvc"

cnb-extender-kind

string

拡張するイメージの種類 (build または run) "build"

""

cnb-extended-dir-exporter

string

拡張されるレイヤーのディレクトリー。エクスポーターに -extended フラグとして渡されます。

"/layers/extended"

Legal Notice
リンクのコピー

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

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

Theme

© 2025 Red Hat