Azure Developer CLI FAQ

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

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

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

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

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

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

キー コンテナー名とシークレットのパラメーターが指定されている場合、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 の場所にデプロイできるのは 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 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 エラーが発生します。

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

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

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

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

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

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

はい。

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

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

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

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

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

いいえ。 azd pipeline config コマンドは、Azure サービス プリンシパルの作成と、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 を使用すると、ワークフローは有効期間の短いトークンを Azure から直接交換できます。

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

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

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

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

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

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

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

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