Azure Developer CLI FAQ

この記事では、Azure Developer CLI についてよく寄せられる質問に回答します。

全般

Azure Developer CLI をアンインストールする操作方法とは?

azd をインストールした方法によって、アンインストールの方法も異なります。 詳細については、インストールに関するページをご覧ください。

Azure Developer CLI と Azure CLI の違いは何ですか?

Azure Developer CLI (azd) と Azure CLI (az) はどちらもコマンドライン ツールですが、さまざまなタスクを実行するのに役立ちます。

azd は、高レベルの開発者ワークフローに重点を置いています。 Azure リソースのプロビジョニング/管理とは別に、azd はクラウド コンポーネント、ローカル開発構成、パイプライン自動化をつなぎ合わせて、一式揃ったソリューションにするのに役立ちます。

Azure CLI は、仮想マシン、仮想ネットワーク、ストレージなどの Azure インフラストラクチャを作成および管理するためのコントロール プレーン ツールです。 Azure CLI は、特定の管理タスクのための詳細なコマンドを中心に設計されています。

環境名とは?

Azure Developer CLI は、環境名を使用して、Azure Developer CLI テンプレートで使用される AZURE_ENV_NAME 環境変数を設定します。 AZURE_ENV_NAME は、Azure リソース グループ名の接頭辞としても使用されます。 各環境には独自の構成セットがあるため、Azure Developer CLI はすべての構成ファイルを環境ディレクトリに保存します。

├── .Azure                          [This directory displays after you run add init or azd up]
│   ├── <your environment1>         [A directory to store all environment-related configurations]
│   │   ├── .env                    [Contains environment variables]
│   │   └── main.parameters.json    [A parameter file]
│   └── <your environment2>         [A directory to store all environment-related configurations]
│   │   ├── .env                    [Contains environment variables]
│   │   └── main.parameters.json    [A parameter file]
│   └──config.json 

複数の環境を設定できますか?

はい。 さまざまな環境 ( 開発、テスト、運用など ) を設定できます。 azd env を使用してこれらの環境を管理できます。

環境構成 (.env) ファイルはどこに保存されていますか?

.env ファイルのパスは <your-project-directory-name>\.azure\<your-environment-name>\.env です。

env ファイルはどのように使用されますか?

Azure Developer CLI では、azd コマンドは環境構成の .env ファイルを参照します。 azd deploy などのコマンドも、db 接続文字列や Azure Key Vault のエンドポイントなどで .env ファイルを更新します。

Codespaces で 'azd up' を実行しました。 ローカル開発環境で作業を続行できますか?

はい。 開発作業はローカルで続行できます。

  1. azd init -t <template repo> を実行して、テンプレート プロジェクトをローカル コンピューターに複製します。
  2. Codespaces を使用して作成された既存の env をプルダウンするには、azd env refresh を実行します。 以前と同じ環境名、サブスクリプション、場所を指定してください。

azure.yaml ファイルはどのように使用されますか?

azure.yaml ファイルには、テンプレートに含まれる Azure リソースのアプリと種類が記述されています。

'secretOrRandomPassword' 関数はどのように動作しますか?

キー コンテナー名とシークレットのパラメーターが指定されている場合、secretOrRandomPassword 関数は Azure Key Vault からシークレットを取得します。 これらのパラメーターが指定されていない場合、またはシークレットを取得できない場合、関数は代わりにランダムに生成されたパスワードを返して代わりに使用します。

次の例は、main.parameters.json ファイル内の secretOrRandomPassword の一般的な使用例を示しています。 ${AZURE_KEY_VAULT_NAME} 変数と sqlAdminPassword 変数は、Key Vault とシークレットの名前のパラメーターとして渡されます。 値を取得できない場合は、代わりにランダムなパスワードが生成されます。

  "sqlAdminPassword": {
    "value": "$(secretOrRandomPassword ${AZURE_KEY_VAULT_NAME} sqlAdminPassword)"
  } 

また、今後の実行に備えて、Bicep を使用した secretOrRandomPassword の出力も Key Vault に保存しておくとよいでしょう。 複数デプロイ間で同じシークレットを取得して再利用すると、新しい値を繰り返し生成するときに発生する可能性のあるエラーや意図しない動作を防ぐことができます。 Key Vault を作成し、生成されたシークレットをその中に格納するには、次の Bicep コードを使用します。 これらのモジュールの完全なサンプル コードは、Azure Developer CLI GitHub リポジトリで確認できます。

module keyVault './core/security/keyvault.bicep' = {
  name: 'keyvault'
  scope: resourceGroup
  params: {
    name: '${take(prefix, 17)}-vault'
    location: location
    tags: tags
    principalId: principalId
  }
}

module keyVaultSecrets './core/security/keyvault-secret.bicep' = {
  name: 'keyvault-secret-sqlAdminPassword'
  scope: resourceGroup
  params: {
    keyVaultName: keyVault.outputs.name
    name: 'sqlAdminPassword'
    secretValue: sqlAdminPassword
  }
}]

この Bicep セットアップにより、シークレットを管理するための次のワークフローが有効になります。

  1. 指定したシークレットが存在する場合は、secretOrRandomPassword 関数を使用して Key Vault から取得されます。
  2. シークレットが存在しない場合は、Key Vault が作成され、ランダムに生成されたシークレットが内部に格納されます。
  3. 今後のデプロイでは、secretOrRandomPassword メソッドが Key Vault 内に存在するようになった格納済みシークレットを取得します。 Key Vault が既に存在する場合は、Key Vault は再作成されませんが、次回の実行のために同じシークレット値が再び格納されます。

Azure 無料サブスクリプションを使用できますか?

はい。ただし、各 Azure の場所にデプロイできるのは 1 つだけです。 選択した Azure の場所を既に使用している場合は、デプロイ エラーが表示されます。

InvalidTemplateDeployment: The template deployment '<env_name>' isn't valid according to the validation procedure. The tracking ID is '<tracking_id>'. See inner errors for details.

別の Azure の場所を選択して問題を解決できます。

Azure App Service でホストされているアプリで、"前方に人をだますサイトがあります" という警告が表示される場合、どのように修正できますか?

これは、リソースに名前を付ける方法が原因で発生する可能性があります。

"Azure Dev" で作成されたテンプレートを使用すると、リソースの名前を構成できます。 これを行うには、エントリを infra フォルダー内の main.parameters.json に追加できます。 次に例を示します。

  "webServiceName": {
  "value": "my-unique-name"
}

このエントリでは、次回アプリケーションをプロビジョニングするときに、ランダム化された値 ("app-web-aj84u2adj" など) ではなく、"my-unique-name" という名前の新しいリソースが作成されます。 Azure Portal を使用して古いリソース グループを手動で削除するか、azd down を実行して以前のすべてのデプロイを削除できます。 リソースを削除した後、azd provision を実行して新しい名前でもう一度作成します。

この名前はグローバルに一意である必要があります。そうしないと、リソース作成時に azd provision 中に ARM エラーが発生します。

コマンド: azd provision

コマンドは、プロビジョニングするリソースをどのように認識しますか?

このコマンドは、<your-project-directory-name>/infra の下にある Bicep テンプレートを使用して、Azure リソースをプロビジョニングします。

Azure でプロビジョニングされているリソースはどこで確認できますか?

https://portal.azure.com に移動し、リソース グループ (rg-<your-environment-name>) を探します。

Azure エラーの詳細についての操作方法とは?

<your-project-directory-name>/infra の下にある Bicep テンプレートを使用して、Azure リソースをプロビジョニングしています。 問題がある場合は、CLI 出力にエラー メッセージを含めます。

https://portal.azure.com に移動し、リソース グループ (rg-<your-environment-name>) を探すこともできます。 いずれかのデプロイが失敗した場合は、エラー リンクを選んで詳しい情報を入手してください。

その他のリソースについては、「Azure デプロイに関する一般的なエラーのトラブルシューティング - Azure Resource Manager」 をご覧ください。

'azd provision' のログファイルはありますか?

間もなく公開予定。 この機能は、将来のリリースで予定されています。

コマンド: azd deploy

このコマンドを再実行できますか?

はい。

azd は私のコードのデプロイ先となる Azure リソースをどのように見つけますか?

デプロイ中、まず azdazd-env-name でタグ付けされ、かつ環境の名前と一致する値を持つグループを探して、アプリケーションを構成するすべてのリソース グループを検出します。 次に、これらの各リソース グループ内のすべてのリソースを列挙します。その際には、azd-service-name でタグ付けされ、かつ azure.yaml のサービスの名前に一致する値を持つリソースを探します。

リソースにタグを使用することをお勧めしますが、resourceName プロパティを azure.yaml で使用して明示的なリソース名を指定することもできます。 その場合、上記のロジックは実行されません。

コマンド: azd up

'azd up' を再実行できますか?

はい。 増分デプロイ モード を使用します。

`azd up` のログ ファイルの操作方法とは?

間もなく公開予定。 この機能は、将来のリリースで予定されています。

コマンド: azd pipeline

Azure サービス プリンシパルとは

Azure サービス プリンシパルは、アプリ、ホステッド サービス、および Azure リソースにアクセスするための自動化ツールで使用するために作成される ID です。 このアクセスは、サービスプリンシパルに割り当てられているロールによって制限されます。これにより、どのリソースにどのレベルでアクセスできるかを制御することができます。 Azure から GitHub への認証の詳細については、「GitHub と Azure を接続する | Microsoft Docs」 をご覧ください。

'azd pipeline config' を実行する前に、Azure サービス プリンシパルを作成する必要がありますか?

いいえ。 azd pipeline config コマンドは、Azure サービス プリンシパルの作成と、GitHub リポジトリにシークレットを保存するために必要なステップを実行します。

GitHub に保存されているすべてのシークレットは何ですか?

このコマンドは、GitHub に 4 つのシークレット (AZURE_CREDENTIALS、AZURE_ENV_NAME、AZURE_LOCATION、AZURE_SUBSCRIPTION_ID) を保存します。 https://github.com/<your-GH-account>/<your-repo>/secrets/actions に移動して、各シークレットの値をオーバーライドできます。

OpenID Connect (OIDC) とは何ですか。サポートされていますか?

OpenID Connect を使用すると、ワークフローは有効期間の短いトークンを Azure から直接交換できます。

GitHub Actions と Azure Pipeline (フェデレーション として設定) の既定として、OIDC がサポートされていますが、Azure DevOps または Terraform ではサポートされていません。

  • Azure DevOps の場合、--auth-typefederated として明示的に呼び出すと、エラーが発生します。
  • Terraform の場合:
    • --auth-type が定義されていない場合は、clientcredentials にフォールバックされ、警告が発生します。
    • --auth-typefederated に明示的に設定されると、エラーが発生します。

GitHub Actions に保存されている Azure サービス プリンシパルをリセットする操作方法とは?

https://github.com/<your-GH-account>/<your-repo>settings/secrets/actions に移動し、新しいサービス プリンシパルの JSON オブジェクト全体をコピーして貼り付けて AZURE_CREDENTIALS を更新します。 次に例を示します。

{
  "clientId": "<GUID>",
  "clientSecret": "<GUID>",
  "subscriptionId": "<GUID>",
  "tenantId": "<GUID>",
  (...)
}

GitHub Actions ファイルはどこに保存されますか?

GitHub Actions ファイルのパスは <your-project-directory-name>\.github\workflows\azure-dev.yml です。

azure-dev.yml ファイルで、ビルド ステップのコードだけをデプロイできますか?

はい。 run: azd up --no-promptrun: azd deploy --no-promptに置き換えます。

’azd pipeline config’ を実行したときにトリガーした GitHub Actions ジョブのログはどこで確認できますか?

https://github.com/<your-GH-account>/<your-repo>/actions に移動し、ワークフロー実行で「ログ ファイル」をご覧ください。

コンテナー アプリケーションのローカルでのビルド

ビルド中のコンテナー アプリをローカルで実行できないのはなぜですか?

コンテナー アプリケーションをローカルでビルドする場合は、azd auth login をコンテナー内で実行して、アプリケーションが AzureDeveloperCliCredential と連携できるようにする必要があります。 あるいは、AzureDeveloperCliCredential の代わりにサービス プリンシパルを使用するようにアプリケーションを構成することもできます。