ビルドの計画

IBM Cloud® Code Engine でイメージのビルドを始める前に、ビルドに使用できるさまざまなオプションについて理解しておいてください。

ビルド (イメージ・ビルド) は、ソース・コードからコンテナー・イメージを作成するために使用できるメカニズムです。 Code Engineは、Dockerfile および Cloud Native Buildpacks からのビルドをサポートしています。

コンテナ・レジストリに存在するイメージ・ビルドが、インテル・ベースでないプロセッサーでビルドされている場合、 Code Engine、コンテナ・イメージを実行することはできません。 Code Engine はインテル・ベースの処理を使用します。 インテルプロセッシング（ x86 プロセッサー）を使用している場合は、独自のイメージを構築することができます。 また、 Code Engine にビルド・プロセスを任せることもできる。

Code Engine では、カスタム・リソース定義 (CRD) 方式が提供されています。 詳細については、 ソースから画像へのCRDメソッドを 参照してください。

ソース・ロケーションの準備

Code Engine にソース・コードへのアクセス権限を付与するには、Git リポジトリーで、またはローカル・ワークステーション上のアクセス可能な場所で、ソース・コードを使用可能にする必要があります。

Gitリポジトリー
Git リポジトリにコードを保存します。 GitHub または GitLab. コードは、リポジトリーの最上位に配置することも、サブディレクトリーに配置することもできます。 ソース・リポジトリーがパブリックでない場合は、 Code Engine にアクセスを追加する必要があります。
ローカル・ワークステーション
ローカル・ワークステーションにコードを保管します。 ローカル・ディレクトリーからコードをプルするビルドを実行依頼すると、ソース・コードがアーカイブ・ファイルにパックされ、IBM Cloud Container Registryインスタンスにアップロードされます。 ソース・イメージは、ビルド・イメージと同じ名前空間に作成されます。 ローカル・ビルドのターゲットにできるのは IBM Cloud Container Registry のみであることに注意してください。 .gitignore ファイルと同様に動作する .ceignore ファイルを使用して、ソース・コード内の特定のファイル・パターンを無視することを選択できます。 例えば、node.js アプリケーションの.ceignoreファイルのエントリーには、node_modulesおよび.npmが含まれる場合があります。 無視するファイルパターンのサンプルについては、 GitHub.gitignore リポジトリを参照してください。

ビルド方式の選択

Code Engineは、以下のいずれかの戦略を使用してコンテナー・イメージをビルドできます。

Dockerfile

ツールを使用する Dockerfile ビルド BuildKit ツールを使用します。 この方式を使用するには、Dockerfile をソース・リポジトリーに追加します。 この Dockerfile に、ソース・リポジトリーにあるコンテナー・イメージをビルドするために必要なステップを記述します。 例えば、ソースの静的ファイルを、Web サービスでホストするコンテナーにコピーするステップなどを Dockerfile に含めることができます。 選択した言語で作成されたソース・コードをコンパイルし、生成されたバイナリーをコンテナー・イメージに追加することもできます。 Dockerfile ビルドについて詳しくは、 Code Engine 用 Dockerfile の記述を参照してください。

Code Engine のアプリやジョブで使用するために Docker Hub から画像を取り込む場合は、無料プラン（未認証）ユーザーの Docker 料金制限にご注意ください。 429 エラーはプル速度の制限に達したことを示しているので、このエラーを受け取った場合はプルの限度になっている可能性があります。 料金の上限を引き上げるには、 アカウント Docker Pro または Team サブスクリプションにアップグレードしてください。

Cloud Native Buildpacks

クラウドネイティブビルドパックは、 Paketoを使ってソースリポジトリを検査し、あなたのコードがどのランタイム環境に基づいているか、そしてあなたのソースからコンテナイメージがどのようにビルドされるかを検出します。 ビルドパックでは、ソース・リポジトリーのディレクトリー構造が推定されます。 ソース・リポジトリーを正しく構造化する方法について詳しくは、使用するランタイム用に提供されているサンプルを参照してください。

ランタイムのサンプル・ファイル
のランタイム バージョン サンプル
Go 1.24.12 サンプルに行く。
Java 21.0.10 Java サンプル.
Node.js 24.14.0 Node.js サンプル.
PHP 8.1.28 PHPのサンプル。
Python 3.11.14 Python サンプル.
Ruby 3.1.7 Ruby サンプル.
.NET Core 9.0.311 (.NET Core SDK),
9.0.13 (.NET Core Runtime)		 .NET Core サンプル.

Cloud Native Buildpacks を使用して作成された画像は、 Jan, 1st 1980 の中立タイムスタンプを画像作成のタイムスタンプとして使用しなくなりました。 入力ソースのタイムスタンプがイメージの作成タイムスタンプとして使用されます。例えば、ビルドに使用されたコミットの Git。

Paketoビルドパックの特定のランタイムのバージョンは、ビルドパックの更新バージョンが様々な IBM Cloud 地域にロールアウトされるたびに、短期間地域間で異なる場合があります。

ビルドのサイズの決定

Code Engine は、ビルドを small、 medium、 large、 xlarge、 xxlarge のサイズに分類する。 ビルドのサイズによって、CPU コア、メモリー、およびディスク・スペースがビルドに割り当てられる方法が決まります。 ビルドのサイズが小さいほどコストは低くなりますが、使用する CPU コアの数が少ないため、通常は低速になります。 また、ビルドのメモリーとディスクの所要量によっては、サイズが小さいとビルドが失敗する場合もあります。

ビルド・サイズの値。
サイズ Dockerfile ビルドパック
small
  • CPU 0.5
  • メモリー 2 GB
  • ディスク 2 GB
  • CPU 0.5
  • メモリー 2 GB
  • ディスク 2 GB
medium
  • CPU 1
  • メモリー 4 GB
  • ディスク 4 GB
  • CPU 1
  • メモリー 4 GB
  • ディスク 4 GB
large
  • CPU 2
  • メモリー 8 GB
  • ディスク 8 GB
  • CPU 2
  • メモリー 8 GB
  • ディスク 8 GB
xlarge
  • CPU 4
  • メモリー 16 GB
  • ディスク 16 GB
  • CPU 4
  • メモリー 16 GB
  • ディスク 16 GB
xxlarge
  • CPU 12
  • メモリ 48 GB
  • ディスク 48 GB
  • CPU 12
  • メモリ 48 GB
  • ディスク 48 GB

選択すべきサイズかわからない場合は、small または medium から始めることを検討してください。 メモリー不足またはディスク・スペース不足でビルドが失敗したり、処理が遅かったりしたら、より大きいサイズに切り替えてください。

コンテナー・イメージ・レジストリーの選択

Code Engine は、Git リポジトリーまたはローカル・ディレクトリーからソース・コードをプルしてビルドし、イメージをコンテナー・イメージ・レジストリーにプッシュ (アップロード) します。

パブリックまたはプライベートのソースのリポジトリーおよびコンテナー・イメージのレジストリーを使用できます。 また、ビルド出力にレジストリの詳細をレジストリ・シークレットで指定することもできますし、 Code Engine、ソースからあなたのためにイメージをビルドし、 自動アクセスで IBM Cloud Container Registry、イメージを保存することもできます。

構築方法を選択する

以下のビルド・オプションでは、 Code Engine が Git リポジトリまたはローカル・ディレクトリからソース・コードをプルし、コンテナ・イメージをビルドし、コンテナ・イメージをレジストリにプッシュ（アップロード）する。 公開または非公開の リポジトリや レジストリを 選択できます。 レジストリが非公開である場合、 ユーザー提供のアクセス権を持つビルド出力用に、レジストリの詳細をレジストリ・シークレットで指定する。 または、 Code Engine、 自動アクセスで IBM Cloud Container Registry に画像を保存するアクセスを作成することもできます。

ビルド構成を作成する

このシナリオでは、 Code Engine、ビルド用のコンフィギュレーションを作成する。

ビルド・コンフィギュレーションを作成してもイメージは作成されず、代わりにイメージをビルドするためのコンフィギュレーションが作成されます。 ビルドを実行すれば、コンフィギュレーションからイメージを作成できる。 ビルドを実行するまでは、ビルド構成が検証されることも、イメージを作成するために使用されることもありません。 ビルド構成を使用すると、特定のイメージの複数のビルドを後で作成することができます。これはソース・リポジトリーに変更が適用された場合などに便利です。

詳細は以下のトピックを参照。

ビルド・コンフィギュレーションを作成したら、 それを実行 することができる。

スタンドアロンビルドコマンドでコンテナイメージを作成する

単一の Code Engine CLI コマンドを使用してコンテナー・イメージをビルドし、再使用可能なビルド構成を作成せずにコンテナー・イメージを作成する方法については、スタンドアロン・ビルド・コマンド (CLI) を使用したコンテナー・イメージのビルドを参照してください。

コードを構築し、ワークロードを作成する

ローカルのソースコードからワークロードを作成する場合、ソースコードはアーカイブファイルにまとめられ、 アカウント IBM Cloud Container Registry インスタンス内のマネージドネームスペースにアップロードされます。 画像もこの同じ名前空間に保存される。

コードを構築し、1回の操作でワークロードを作成するには、以下のトピックを参照のこと。

Gitリポジトリー
ローカル・ファイル

ビルドの次のステップ

コード・サンプルがさらに必要ですか? Samples for IBM Cloud Code Engine GitHub repoをチェックしてください。