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 の代わりにサービス プリンシパルを使用するようにアプリケーションを構成することもできます。