Azure Developer CLI FAQ

最初にインストールした方法に応じて、azd をアンインストールするためのさまざまなオプションがあります。 詳細については、のインストール ページ を参照してください。

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

azd は、高度な開発者ワークフローに重点を置いています。 azd は、Azure リソースのプロビジョニングと管理とは別に、クラウド コンポーネント、ローカル開発構成、パイプライン自動化を完全なソリューションにまとめるのに役立ちます。

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)"
  } 

secretOrRandomPassword の出力も、今後の実行のために Bicep を使用して 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 エラーが発生します。

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

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

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

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

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

もうすぐです。 この機能は、今後のリリースで予定されています。

はい。

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

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

プロジェクトを配置する場合は、コマンドでサービス名を指定するか (azd deploy api)、またはデプロイするサービスのみを含むサブフォルダーに移動して、特定のサービスをデプロイすることができます。 その場合、他のすべてのサービスが - Skippedとして表示されます。

サービスをスキップしない場合は、必ずルート フォルダーからコマンドを実行するか、コマンドに --all フラグを追加してください。

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

もうすぐです。 この機能は、今後のリリースで予定されています。

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 から直接交換できます。

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

• Azure DevOps の場合、federated として --auth-type を明示的に呼び出すと、エラーが発生します。
• 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に移動し、ワークフロー実行のログ ファイルを参照します。

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