コンテナーのビルドとデプロイのワークフローを選択する

Azure Developer CLI (azd) では、複数のAzure ホスティング サービスにわたってコンテナー イメージをビルド、発行、デプロイできます。 コンテナー ワークフローは、ホスティング ターゲットとビルドの場所と発行方法を組み合わせたものです。 最適な組み合わせは、アプリケーション、チームが利用できるツール、環境間でのイメージの昇格方法によって異なります。

この記事を使用して、これらの選択肢をニーズに合わせます。 次の決定事項を比較します。

  • コンテナーをホストしている Azure サービス。
  • azdイメージをローカルにビルドするか、Azure Container Registry (ACR) でリモートでビルドするか、既存のイメージを使用します。
  • azdがイメージを一緒に発行してデプロイするか、別の手順としてデプロイするか。

この記事では、次の汎用ホスティング サービスを比較します。

まず、ホスティング ターゲットとイメージ ビルド オプションを比較します。 これらの選択肢を理解したら、「 コンテナーデプロイ ワークフローの比較」セクションで候補となるワークフローを特定します。

コンテナー ホスティング ターゲットを比較する

azure.yamlの host プロパティは、azdがコンテナーをデプロイするAzure サービスを識別します。 イメージのビルド場所とは別にホストを選択します。

ホスト値 Azure ホスティング先 コンテナー ワークフロー 考慮事項
containerapp Azure Container Apps と Container Apps ジョブ プロジェクトと Dockerfile からビルドするか、事前構築済みのイメージをデプロイします。 サービス レベルの環境変数と Container Apps 固有のデプロイ戦略をサポートします。 Container Apps ジョブには同じホスト値を使用します。
appservice Azure App Service 上のコンテナー向け Linux Web アプリ プロジェクトと Dockerfile からビルドするか、事前構築済みのイメージをデプロイします。 インフラストラクチャでは、Linux コンテナー対応サイトをプロビジョニングし、ACR へのマネージド ID アクセスを構成する必要があります。 azd deploy は、イメージ参照のみを更新します。
aks Azure Kubernetes Service イメージをビルドし、Kubernetes マニフェスト、Helm チャート、または Kustomize 構成をデプロイします。 最も多くの制御を提供しますが、クラスターと Kubernetes の構成を管理する必要があります。 azdで Helm または Kustomize を使用するには、アルファ機能フラグを有効にする必要があります。

ai.endpointホストとazure.ai.agent ホストでは、特殊なMicrosoft Foundry シナリオ向けの Docker 構成もサポートされています。 これらのワークロードについては、Microsoft Foundry オンライン エンドポイントへのデプロイおよびMicrosoft Foundry エージェント拡張機能を参照してください。

イメージ のビルド オプションを比較する

サービス定義は、 azd イメージをビルドするか、既存のイメージで開始するかを決定します。

ビルド オプション 必要な構成 ビルドの実行場所 ローカル コンテナー エンジン 最も適しているデータ
ローカル ビルド project と、必要に応じて docker 開発環境または CI ランナー 必須 Docker または Podman を既に提供している高速な開発イテレーションとビルド環境。
ACR リモート ビルド project と docker.remoteBuild: true Azure Container Registry リモート ビルドの失敗後に azd がフォールバックしない限り不要です ローカル コンテナー エンジンを使用しない一貫したクラウド ビルドと環境。 ドキュメントに記載されているリモート ビルド ワークフローは、Azure Container Appsを対象とします。
によって管理される既存のイメージ azd image ソースからのビルドなし イメージのライフサイクル操作を行う際に必要になる場合があります ローカルまたはレジストリに既に存在し、 azd がプル、タグ付け、プッシュできるイメージ。
リモート イメージパススルー image と docker.imagePassthrough: true ビルドなし 必須ではない ホスティング リソースがそのまま使用する完全修飾されたリモート イメージ。

オプションごとの構成に関する記事を読むときは、次の概念上の違いに留意してください。

  • 事前構築済みイメージでは、projectではなく image プロパティが使用され、azdは引き続きプル、タグ付け、プッシュを実行できます。
  • ACR リモート ビルドは、リモート ビルドが失敗し、サポートされているコンテナー エンジンが使用可能な場合に、ローカルの Docker または Podman ビルドにフォールバックします。
  • イメージパススルーには、レジストリを含む完全修飾リモート イメージ参照が必要であり、remoteBuildと組み合わせることはできません。また、azdはイメージを管理しないため、azd publish --from-packageまたはazd publish --toオプションはサポートされません。

各オプションの完全な構成については、「Azure Container Registryを使用したリモート ビルドのサポート、サードパーティのコンテナー レジストリの使用、Azure Developer CLI を使用した App Service コンテナーのデプロイ、およびdocker スキーマ」を参照してください。

コンテナーデプロイワークフローを比較する

「コンテナー ホスティング ターゲットの比較」のホスティング ターゲット と「イメージのビルドの 比較オプション」のビルド オプションを比較した後、次の表を使用して、ニーズに最も可能性の高いワークフローを特定します。

次が必要な場合: 次から開始 なぜでしょうか
コンテナー化されたアプリケーションをサーバーレス プラットフォームにデプロイする ローカル ビルドを使用したAzure Container Apps このワークフローは、Dockerfile ベースのプロジェクトを 1 つの開発ワークフローでビルドしてデプロイします。
Docker または Podman をローカルにインストールせずにビルドする ACR リモート ビルドを使用したAzure Container Apps ACR はプロジェクトからイメージをビルドし、Azureで Dockerfile をビルドします。
別のビルド システムによって生成されるイメージをデプロイする ビルド済みイメージを使用した Azure Container Apps または App Service image プロパティは、ビルドするソース コードではなく、既存のイメージを識別します。
リモート イメージをプル、タグ付け、プッシュせずに再利用する イメージ パススルー対応の Azure Container Apps azd は、完全修飾イメージ参照をホスティング リソースに直接渡します。
従来の Web アプリケーションを Linux コンテナーとしてホストする Azure App Service 上の Web App for Containers App Service は、コンテナー対応のサイト構成をインフラストラクチャが制御する一方で、統合された Web ホスティング プラットフォームを提供します。
Kubernetes マニフェストとクラスター構成を制御する Azure Kubernetes Service (AKS) azd では、イメージをビルドして発行し、Kubernetes マニフェスト、Helm チャート、または Kustomize 構成をデプロイできます。
1 回ビルドし、環境を通じて同じイメージを昇格させる azd publish、その後に azd deploy --from-package 発行とデプロイは別々であるため、各環境は同じイメージを受け取ります。

各行は、 コンテナーホスティングターゲットの比較 からのホスティングの選択肢と、イメージの ビルドオプションの比較 から開始点へのビルドの選択肢を組み合わせたものになります。 azure.yamlで選択内容を設定し、Bicep または Terraform ファイルで対応するホスティング リソースとレジストリ リソースをプロビジョニングできるようにします。

最小限のサービス定義では、 host、ビルド ソース、および Dockerfile が設定されます。

services:
  api:
    project: ./src/api
    language: docker
    host: containerapp
    docker:
      path: ./Dockerfile

この定義を別のホストに適応するには、 host 値を変更し、ホストごとの構成コントラクトに従います。

発行コマンドとデプロイ コマンドを比較する

ホストとビルドのオプションを選択した後、イメージの発行とデプロイを組み合わせるか、別にするかを選択します。

命令 画像の操作 Azure リソース アクション 次の場合に使用します。
azd up ビルドしてプッシュ プロビジョニングとデプロイ 完全な環境を作成または更新し、1 つのワークフローでアプリケーションをデプロイする必要があります。
azd deploy ビルドしてプッシュ デプロイ インフラストラクチャは既に存在し、アプリケーションの変更をデプロイする必要があります。
azd publish ビルドとプッシュ なし レジストリ成果物をデプロイせずに作成する場合。 azd publish では、Container Apps と AKS サービスがサポートされています。
azd publish --from-package <image> 既存のローカル イメージをプッシュする なし 別のプロセスでイメージがビルドされていて、それを azd で公開したい場合。
azd deploy --from-package <image> なし デプロイ 再構築せずに特定のイメージをデプロイする場合。

たとえば、バージョン管理されたイメージを発行し、同じイメージを別の環境にデプロイします。

azd publish api --to myregistry.azurecr.io/my-api:v1.0.0
azd env select production
azd deploy api --from-package myregistry.azurecr.io/my-api:v1.0.0

このワークフローでは、環境ごとにイメージをリビルドするときに発生する可能性のある違いを防ぐことができます。 完全なプロモーション ワークフローについては、Azure Developer CLI の発行ワークフローを参照してください。

関連するコンテンツ

  • 最終更新: