Tanzu Build Service を使用する
Note
Basic、Standard、Enterprise プランは、2025 年 3 月中旬以降非推奨になり、廃止期間は 3 年間です。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の廃止のお知らせ」を参照してください。
Standard 従量課金と専用プランは、2024 年 9 月 30 日以降に非推奨になり、6 か月後に完全にシャットダウンされます。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の Standard 従量課金および専用プランを Azure Container Apps に移行する」を参照してください。
この記事の適用対象: ❎ Basic/Standard ✅ Enterprise
この記事では、Azure Spring Apps Enterprise プランで VMware Tanzu Build Service を使用する方法について説明します。
VMware Tanzu Build Service を使用すると、コンテナーの作成、管理、ガバナンスをエンタープライズ規模で自動化できます。 Tanzu Build Service では、オープンソースの Cloud Native Buildpacks プロジェクトを使用して、アプリケーションのソース コードをコンテナー イメージに変換します。 最新のコンテナー標準に合わせて再現可能なビルドを実行し、イメージを最新の状態に保ちます。
Buildpacks
VMware Tanzu Buildpacks では、アプリケーションに合わせてフレームワークおよびランタイムのサポートを提供します。 Buildpacks では、通常、ご利用のアプリケーションを調べて、どのような依存関係をダウンロードするべきか、バインドされたサービスと通信するためにアプリケーションをどのように構成すればよいかを判断します。
言語ファミリ ビルドパックは、最も一般的な言語ランタイムとアプリ構成を追加設定なしで容易にサポートできる複合ビルドパックです。 これらのビルドパックによって、複数のコンポーネントビルドパックが、順序付けされたグループに結合されます。 グループ化することで、各ビルドパックの要件が満たされます。
ビルダー
ビルダーは Tanzu Build Service リソースです。 ビルダーには、ビルドパックのセットと、ソース コードのビルド プロセスで使用される スタック が含まれています。
ビルド エージェント プール
Enterprise プランの Tanzu Build Service は、ソース コードとアーティファクトの両方からユーザー アプリケーションをコンテナー化するためのエントリ ポイントです。 指定された数のコンカレント ビルド タスクに対応したコンピューティング リソースを予約する専用のビルド エージェント プールがあります。 ビルド エージェント プールによって、実行中のアプリとのリソースの競合が回避されます。
次の表に、使用可能なビルド エージェント プール スケール セットのサイズを示します。
スケール セット | CPU/Gi |
---|---|
S1 | 2 vCPU、4 Gi |
S2 | 3 vCPU、6 Gi |
S3 | 4 vCPU、8 Gi |
S4 | 5 vCPU、10 Gi |
S5 | 6 vCPU、12 Gi |
S6 | 8 vCPU、16 Gi |
S7 | 16 vCPU、32 Gi |
S8 | 32 vCPU、64 Gi |
S9 | 64 vCPU、128 Gi |
Tanzu Build Service では、最大で 1 つのプール サイズのビルド タスクをビルドでき、プール サイズの 2 倍のビルド タスクをキューに入れることができます。 エージェント プールのクォータがビルド タスクに対して不足している場合、このビルドの要求では次のエラーが表示されます: The usage of build results in Building or Queuing status are (cpu: xxx, memory: xxxMi) and the remained quota is insufficient for this build. please retry with smaller size of build resourceRequests, retry after the previous build process completed or increased your build agent pool size
。
ビルド エージェント プールを構成する
Azure portal を使用して Azure Spring Apps Enterprise の新しいサービス インスタンスを作成する場合、[VMware Tanzu の設定] タブを使用すれば、ビルド エージェント プールに割り当てるリソースの数を構成できます。
次の図は、サービス インスタンスを正常にプロビジョニングした後に、Tanzu Build Service エージェント プールに割り当てられたリソースを示しています。 サービス インスタンスの作成後に、ここで構成されたエージェント プールのサイズを更新することもできます。
オンデマンドでのビルド サービス
Azure Springs Apps Enterprise プランのインスタンスの作成時に、ビルド サービスを有効または無効にできます。
ビルドとデプロイの特性
既定では、コンテナー レジストリを使用できるように Tanzu Build Service が有効化されています。 ビルド サービスを無効にすると、カスタム コンテナー イメージのみを使用してアプリケーションをデプロイできます。 次のようなオプションがあります。
ビルド サービスを有効にし、Azure Spring Apps マネージド コンテナー レジストリを使用します。
Azure Spring Apps には、アプリケーションのビルド イメージを格納するためのマネージド Azure Container Registry が用意されています。 ビルドとデプロイは 1 つのコマンドとしてのみ一緒に実行でき、別々に実行することはできます。 同じサービス インスタンスにのみアプリケーションをデプロイするためにビルド コンテナー イメージを使用できます。 このイメージは、他の Azure Spring Apps Enterprise サービス インスタンスからはアクセスできません。
ビルド サービスを有効にし、独自のコンテナー レジストリを使用します。
このシナリオでは、ビルドとデプロイを分離します。 アプリケーションのデプロイとは別に、アプリケーションのソース コードまたはビルド成果物からコンテナー イメージへのビルドを実行できます。 独自のコンテナー レジストリに格納されたコンテナー イメージを、複数の Azure Spring Apps Enterprise サービス インスタンスにデプロイできます。
ビルド サービスを無効にします。
ビルド サービスを無効にすると、Azure Spring Apps Enterprise サービス インスタンスからビルドできるコンテナー イメージのみを使用してアプリケーションをデプロイできます。
ビルド サービス設定を構成する
Azure portal または Azure CLI を使用して、Tanzu Build Service とコンテナー レジストリの設定を構成できます。
Azure Spring Apps サービス インスタンスのプロビジョニング時に Tanzu Build Service を有効にするには、次の手順を使用してください。
Azure Portalを開きます。
[基本] タブで、[価格] セクションの [Enterprise レベル] を選択し、必要な情報を指定します。
[次へ: VMware Tanzu の設定] を選択します。
[VMware Tanzu の設定] タブで、[ビルド サービスを有効にする] を選択します。 [コンテナー レジストリ] の場合、既定の設定は [マネージド Azure Container Registry を使用してビルド イメージを格納する] です。
[コンテナー レジストリ] で [独自のコンテナー レジストリを使用してビルド イメージを格納する] (プレビュー) を選択した場合は、コンテナー レジストリのサーバー、ユーザー名、パスワードを入力してください。
[ビルド サービスを有効にする] を無効にすると、コンテナー レジストリ オプションは提供されませんが、コンテナー イメージを使用してアプリケーションをデプロイできます。
[確認と作成] を選択します。
多言語アプリケーションをデプロイする
Tanzu Build Service を有効または無効にして、Azure Spring Apps Enterprise サービス インスタンスに多言語アプリケーションをデプロイできます。 詳細については、「Azure Spring Apps Enterprise で多言語アプリをデプロイする方法」を参照してください。
APM 統合と CA 証明書を構成する
Tanzu Partner Buildpacks と CA Certificates Buildpack を使用することにより、Azure Spring Apps Enterprise プランでは、アプリケーション パフォーマンス モニター (APM) 統合をサポートするための構成エクスペリエンスを簡素化しています。 この統合には、多言語アプリケーション用の証明機関 (CA) 証明書統合シナリオが含まれます。 詳細については、「APM 統合と CA 証明書を構成する方法」を参照してください。
リアルタイム ビルド ログ
Azure CLI コマンドによってアプリケーションがデプロイされると、ビルド タスクがトリガーされます。 ビルド ログは、CLI コマンドの出力の一部としてリアルタイムでストリーム配信されます。 ビルド ログを使用して問題を診断する方法については、「診断設定でログとメトリックを分析する」を参照してください。
ビルド履歴
Azure Spring Apps Build Service ページの [ビルド] セクションで、すべてのビルド リソースを確認できます。
[ビルド] セクションの表には、次の列が含まれます。
- ビルド名: ビルドの名前。
- プロビジョニングの状態: ビルドのプロビジョニングの状態。 有効値は、
Succeeded
、Failed
、Updating
、およびCreating
です。 プロビジョニング状態のUpdating
とCreating
は、現在のビルドが終了するまでビルドを更新できないことを意味します。 プロビジョニング状態のFailed
は、最新のソース コード ビルドで新しいビルド結果を生成できなかったことを意味します。 - リソース クォータ: ビルドのビルド ポッド内のリソース クォータ。
- ビルダー: ビルドに使用されるビルダー。
- 最新のビルド結果: ビルドの最新のビルド結果イメージ タグ。
- 最新のビルド結果のプロビジョニング状態: ビルドの最新のビルド結果のプロビジョニング状態。 有効値は、
Queuing
、Building
、Succeeded
、およびFailed
です。 - 最新のビルド結果の最終移行時間: ビルドの最新ビルド結果の最終移行時間。
- 最新のビルド結果の最終移行理由: ビルドの最新ビルド結果の最終移行理由。 値は、
CONFIG
、STACK
、およびBUILDPACK
です。CONFIG
は、ビルダーの更新または新しいソース コードのデプロイ操作によってビルド結果が変更されたことを意味します。STACK
は、スタックのアップグレードによってビルド結果が変更されたことを意味します。BUILDPACK
は、ビルドパックのアップグレードによってビルド結果が変更されたことを意味します。 - 最新のビルド結果の最終移行状態: ビルドの最新ビルド結果の最終移行状態。 値は、
True
およびFalse
です。
プロビジョニング状態では、値が Failed
の場合、ソース コードをもう一度デプロイします。 エラーが解決しない場合は、サポート チケットを作成します。
最新のビルド結果のプロビジョニング状態では、値が Failed
の場合、ビルド ログを確認します。 詳細については、「Azure Spring Apps における一般的なビルドの問題のトラブルシューティング」を参照してください。
最新のビルド結果の最終移行状態では、値が Failed
の場合は、最新のビルド結果の最終移行理由列を参照してください。 理由が BUILDPACK
または STACK
の場合は、必要なアクションはありません。 理由が CONFIG
の場合は、ソース コードをもう一度デプロイします。 エラーが解決しない場合は、サポート チケットを作成します。