Часто задаваемые вопросы об Azure Developer CLI

Существуют различные варианты удаления azd в зависимости от того, как вы изначально установили его. Дополнительные сведения см. на странице установки.

Azure Developer CLI () и Azure CLI (azazd) — это оба средства командной строки, но они помогают выполнять различные задачи.

azd фокусируется на рабочем процессе разработчика высокого уровня. Помимо подготовки и управления ресурсами Azure, azd вы можете смешать облачные компоненты, конфигурацию локальной разработки и автоматизацию конвейеров вместе в полное решение.

Azure CLI — это средство уровня управления для создания и администрирования инфраструктуры Azure, таких как виртуальные машины, виртуальные сети и хранилище. Azure CLI предназначен для детализированных команд для конкретных административных задач.

Azure Developer CLI использует имя среды для задания переменной среды AZURE_ENV_NAME, используемой шаблонами Azure Developer CLI. 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.

В Интерфейсе командной строки azd разработчика Azure команды ссылаются на ENV-файл для конфигурации среды. Такие команды, как azd deploy обновление ENV-файла, например, строка подключения базы данных и конечной точки Azure Key Vault.

Да. Вы можете продолжить разработку локально.

1. Выполните azd init -t <template repo> клонирование проекта шаблона на локальный компьютер.
2. Чтобы извлечь существующий env, созданный с помощью codespaces, выполните команду azd env refresh. Убедитесь, что вы указали то же имя среды, подписку и расположение, что и раньше.

Файл azure.yaml описывает приложения и типы ресурсов Azure, включенных в шаблон.

Функция secretOrRandomPassword извлекает секрет из Azure Key Vault, если указаны параметры имени и секрета хранилища ключей. Если эти параметры не указаны или секрет не удается получить, функция вместо этого вернет случайный созданный пароль.

В следующем примере демонстрируется распространенный вариант secretOrRandomPassword использования файла main.parameters.json . sqlAdminPassword Переменные ${AZURE_KEY_VAULT_NAME} передаются в качестве параметров для имен Key Vault и секрета. Если значение не удается извлечь, создается случайный пароль.

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

Выходные secretOrRandomPassword данные также должны быть сохранены в Key Vault с помощью Bicep для будущих запусков. Получение и повторное использованием одинаковых секретов во время развертывания может предотвратить ошибки или непреднамеренное поведение, которое может возникать при повторном создании новых значений. Чтобы создать Key Vault и сохранить в нем созданный секрет, используйте приведенный ниже код Bicep. Полный пример кода для этих модулей можно просмотреть в репозитории GitHub для разработчиков Azure.

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. Если указанный секрет существует, он извлекается из Key Vault с помощью secretOrRandomPassword функции.
2. Если секрет не существует, создается Key Vault, а случайным образом созданный секрет хранится внутри него.
3. В будущих развертываниях secretOrRandomPassword метод извлекает сохраненный секрет теперь, когда он существует в Key Vault. Хранилище ключей не будет повторно создано, если оно уже существует, но то же значение секрета будет сохранено еще раз для следующего запуска.

Да, но каждое расположение Azure может иметь только одно развертывание. Если вы уже использовали выбранное расположение 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, позволяют настраивать имя ресурса. Для этого можно добавить запись main.parameters.json в папку infra . Например:

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

Эта запись создает новый ресурс с именем my-unique-name вместо случайного значения, например app-web-aj84u2adj при следующей подготовке приложения. Можно вручную удалить старую группу ресурсов с помощью портала Azure или запустить azd down , чтобы удалить все предыдущие развертывания. После удаления ресурсов запустите azd provision , чтобы создать их снова с новым именем.

Это имя должно быть глобально уникальным, в противном случае при попытке создать ресурс будет получена ошибка azd provision ARM.

Команда использует шаблоны Bicep, которые находятся в разделе <your-project-directory-name>/infra подготовки ресурсов Azure.

https://portal.azure.com Перейдите к группе ресурсов и найдите ее.rg-<your-environment-name>

Для подготовки ресурсов Azure используются шаблоны Bicep, которые находятся в разделе <your-project-directory-name>/infra. Если возникли проблемы, мы добавим сообщение об ошибке в выходные данные ИНТЕРФЕЙСА командной строки.

Вы также можете перейти 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. Этот доступ ограничен ролями, назначенными субъекту-службе, что позволяет контролировать доступ к ресурсам и на каком уровне. Дополнительные сведения о проверке подлинности из Azure в GitHub см. в Подключение GitHub и Azure | Документация Майкрософт.

№ Команда azd pipeline config заботится о создании субъекта-службы Azure и выполнении необходимых действий для хранения секретов в репозитории GitHub.

Команда хранит четыре секрета в GitHub: 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 явным --auth-typefederated образом вызывается ошибка.
• Для Terraform:
  • Если --auth-type он не определен, он вернется к clientcredentials предупреждению и приведет к предупреждению.
  • Если --auth-type явно задано значение federated, это приведет к ошибке.

https://github.com/<your-GH-account>/<your-repo>settings/secrets/actionsПерейдите к файлу, а затем обновите AZURE_CREDENTIALS его путем копирования и вставки всего объекта JSON для нового субъекта-службы. Например:

{
  "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субъекта-службы.