azd publish コマンドを使用すると、すぐに Azure リソースにデプロイすることなく、コンテナー イメージをビルドして Azure Container Registry や Docker Hub などのコンテナー レジストリにプッシュできます。
ビルドとプッシュの手順をデプロイ ステップから分離することで、"ビルド 1 回、すべての場所にデプロイする" パターンなど、より高度なデプロイ ワークフローを実装できます。 この方法は、 Azure Container Apps または AzureKubernetes Service (AKS) を対象とするコンテナー化されたアプリケーションに役立ちます。
azd publishを使用する理由
標準の azd ワークフローでは、 azd deploy コマンドは次の 3 つのアクションを順番に実行します。
- ビルド: アプリケーション コードをコンテナー イメージにビルドします。
- プッシュ: そのイメージをレジストリにプッシュします。
- デプロイ: Azure ホスティング サービス (Container Apps など) を更新して、新しいイメージを実行します。
内部ループ開発には便利ですが、このアプローチでは、すべてのデプロイに新しいビルドが必要であることを前提としています。 運用シナリオでは、多くの場合、次のことが必要になります。
- 1 回ビルドし、すべての場所にデプロイします。1 つの成果物 (イメージ) をビルドし、開発環境でテストした後、再構築せずに 、まったく同じ成果物 を運用環境に昇格させます。
- 成果物の一元化: 1 つの共有 Azure Container Registry (ACR) を使用して、すべての環境のイメージを格納します。
- セキュリティの向上: 検証済みおよびテスト済みのイメージのみが運用環境にデプロイされるようにします。
azd publish では、手順 1 と 2 (ビルドとプッシュ) のみを処理することで、これらのシナリオを実現できます。 その後、特定のフラグを持つ azd deploy を使用して、事前公開されたイメージを使用して手順 3 (デプロイ) を処理できます。
主な機能
- 独立したパブリッシング: デプロイメントをトリガーせずにレジストリにイメージを発行します。
-
カスタム ターゲット:
--toフラグを使用して、イメージをプッシュする場所 ([registry/]repository[:tag]) を正確に指定し、既定の名前付け規則をオーバーライドします。 - サード パーティレジストリのサポート: Azure Container Registry に加えて、外部レジストリ (Docker Hub など) にプッシュします。
-
フックサポート:カスタムオートメーションの
prepublishとpostpublishフックをサポートします。 - サービスのターゲット設定: 現在、 Azure Container Apps と AKS でホストされているサービスをサポートしています。
Usage
azure.yamlで定義されている特定のサービスのイメージをビルドして発行するには:
azd publish <service-name>
すべてのサービスをビルドして発行するには:
azd publish --all
パラメーター
| Flag | Description |
|---|---|
--all |
azure.yamlで定義されているすべてのサービスを発行します。 |
--from-package <image> |
ソースからビルドするのではなく、既存のローカル イメージまたはパッケージを使用します。 |
--to <image-ref> |
ターゲット イメージ参照 (たとえば、 <your-registry>.azurecr.io/my-app:v1) を指定します。
azure.yamlの既定の名前付けをオーバーライドします。 |
例示
特定のサービスをカスタム タグに発行します。
azd publish api-service --to <your-registry>.azurecr.io/api-service:v1.0.0
ローカル イメージをリモート レジストリに発行します。
イメージを既にローカルにビルドしている場合 (例: local-api:dev)、 azdを使用してタグ付けしてプッシュできます。
azd publish api-service --from-package local-api:dev --to <your-registry>.azurecr.io/api-service:v1.0.0
シナリオ: 1 回ビルドし、あらゆる場所にデプロイする
一般的な運用ワークフローでは、イメージを 1 回ビルドし、Dev -> Test -> Prod などの複数の環境で昇格させます。 azd publish と azd deployの組み合わせを使用してこれを実現します。
イメージを発行します。
コードをビルドし、共有レジストリにプッシュします。
azd publish api-service --to <your-registry>.azurecr.io/my-app:v1.0.0開発にデプロイする:
特定のイメージ バージョンを開発環境にデプロイします。
--from-packageフラグは、ビルド/プッシュ手順をスキップし、サービス構成を更新するようにazd deployに指示します。azd env select dev azd deploy api-service --from-package <your-registry>.azurecr.io/my-app:v1.0.0運用環境への昇格:
Dev でテストした後、 運用環境に同じ イメージ参照をデプロイします。
azd env select prod azd deploy api-service --from-package <your-registry>.azurecr.io/my-app:v1.0.0
他のコマンドとの比較
| Command | 実行されたアクション | 最適な対象者 |
|---|---|---|
azd publish |
ビルド -> プッシュ | CI/CD パイプライン、成果物の作成、"ビルド 1 回" のワークフロー。 |
azd publish --from-package |
プッシュのみ | は、事前に構築された成果物を環境にプッシュします。 |
azd deploy |
ビルド -> プッシュ -> デプロイ | 標準開発イテレーション (内部ループ)。 |
azd deploy --from-package |
デプロイのみ | 事前構築済み/事前発行済みの成果物を環境にデプロイする。 |
azd up |
プロビジョニング -> ビルド -> プッシュ -> デプロイ | 作業の開始、新しい環境のゼロからの初期化。 |
注
azd upの既定の動作は変更されません。 すべてのエンドツーエンドのプロセスを引き続き指揮します。 ただし、必要に応じて、azure.yamlを使用するようにazd publishでワークフローをカスタマイズできます。
azure.yaml の構成
azure.yamlでサービスの既定の Docker 設定を構成します。
azd publish コマンドは、--toなどのフラグによってオーバーライドされない限り、これらの設定を考慮します。
name: my-app
services:
api:
project: ./src/api
host: containerapp
docker:
registry: 'docker.io/myusername' # Default registry
image: 'my-api' # Default image name
tag: 'latest' # Default tag
この構成では、 azd publish api を実行すると、 docker.io/myusername/my-api:latestにプッシュされます。