IBM Cloud Docs
ビルドの計画

ビルドの計画

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

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

コンテナー・レジストリーに存在するイメージ・ビルドがあり、そのイメージが Intel ベース以外のプロセッサーでビルドされた場合、 Code Engine はコンテナー・イメージを実行できません。 Code Engine は Intel ベースの処理を使用します。 Intel 処理 (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

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

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

Cloud Native Buildpack

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

ランタイムのサンプル・ファイル
のランタイム バージョン サンプル
Go 1.23.8 Go サンプル
Java 21.0.7 Java サンプル
Node.js 20.19.1 Node.js サンプル
PHP 8.1.28 PHP サンプル
Python 3.10.17 Python サンプル
Ruby 3.1.6 Ruby サンプル
.NET コア 9.0.203 (.NET Core SDK), (.NET Core Runtime)
9.0.4
NET コア・サンプル

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

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

ビルドのサイズの決定

Code Engine は、ビルドを smallmediumlargexlarge、および 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 インスタンス内の管理対象名前空間にアップロードされます。 イメージもこの同じ名前空間に保管されます。

コードをビルドし、単一の操作でワークロードを作成するには、以下のトピックを参照してください。

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

ビルドの次のステップ

コード・サンプルがさらに必要ですか? IBM Cloud Code Engine GitHub repoをチェックアウトします。