Развертывание полного стека с помощью Интерфейса командной строки разработчика Azure

Приложения с полным стеком, которые объединяют интерфейсные и внутренние службы, являются общим шаблоном современной веб-разработки. Интерфейс командной строки разработчика Azure (azd) поддерживает развертывание приложений полного стека, где интерфейсная и серверная часть размещаются в виде отдельных служб. В этой статье объясняется, как развертывать полностековые приложения с использованием azd, и выделяются стратегии и преимущества для эффективного развертывания.

Что такое развертывание с полным стеком?

Развертывание полного стека с использованием azd обычно включает в себя:

• Интерфейсная служба: пользовательское веб-приложение, часто созданное с помощью таких платформ, как React, Angular, Vue или Blazor. Интерфейс может размещаться как статический сайт или как контейнерное приложение.
• Серверная служба: уровень API или службы, который обрабатывает бизнес-логику, доступ к данным и интеграции. Серверная часть обычно размещается в контейнерах или как бессерверные функции.
• Общие ресурсы: базы данных, учетные записи хранения, хранилища ключей и другие ресурсы Azure, которые могут использовать обе службы.

С помощью azdможно определить обе службы в одном azure.yaml файле и подготовить их вместе с помощью инфраструктуры в качестве кода (Bicep или Terraform).

Жизненный цикл интерфейса командной строки разработчика Azure

Интерфейс командной строки разработчика Azure следует структурированным рабочим процессам с различными событиями жизненного цикла:

1. Пакет. Создание исходного кода приложения и подготовка артефактов для развертывания.
2. Обеспечение. Создание или обновление ресурсов инфраструктуры Azure с помощью Bicep или Terraform.
3. Развертывание. Разверните упакованный код приложения в подготовленной инфраструктуре.

Команда azd up выполняет все три этапа последовательно. Вы также можете запускать каждый этап независимо с помощью azd package, azd provisionа azd deploy также для более детального управления. Понимание этого жизненного цикла важно для управления зависимостями между службами, особенно в развертываниях приложений с полным стеком, где важны время и порядок.

Дополнительные сведения о настройке azd жизненного цикла и рабочего процесса см. в разделе "Обзор рабочего процесса azd up".

Рекомендации по проектированию инфраструктуры

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

Дополнительные сведения о размещении приложений в Azure.

Понимание взаимозависимости между интерфейсными и внутренними приложениями

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

Интерфейс должен иметь внутренний URL-адрес: интерфейсное приложение обычно должно знать URL-адрес конечной точки API серверной части во время сборки или во время выполнения. Однако серверная служба не имеет URL-адреса, пока она не будет развернута в Azure.

Для настройки политик CORS может быть необходим URL-адрес фронтенда. Службе серверной части может понадобиться URL-адрес фронтенда для настройки политик CORS, но фронтенд не имеет URL-адреса, пока он не будет развернут.

Зависимости общих ресурсов: обе службы могут зависеть от общих ресурсов, таких как базы данных, хранилища ключей или учетные записи хранения. Эти ресурсы необходимо подготовить, прежде чем можно настроить их для использования любой из служб.

Конфигурация для конкретной среды: для разных сред (разработки, промежуточного хранения, рабочей среды) требуются разные URL-адреса и конфигурации конечных точек, но эти значения не известны до завершения подготовки.

Общие сведения о стратегиях конфигурации

Интерфейс командной строки разработчика Azure обрабатывает эти взаимозависимости с помощью двух подходов:

• Настройка во время развертывания: разрешение зависимостей во время подготовки и развертывания
• Конфигурация среды выполнения: отложить конфигурацию зависимостей до момента запуска приложения

Эти подходы представляют собой решения по проектированию, которые вы принимаете при создании приложения. Вы можете использовать одну стратегию исключительно или объединить в зависимости от архитектуры и требований.

Настройка времени развертывания

Конфигурация во время развертывания означает, что подключения и конфигурации службы определяются и блокируются во время azd provision и azd deploy этапов. Используя этот подход, вы настраиваете службы с определенными URL-адресами конечных точек, строками подключения и другими сведениями о зависимостях перед запуском. Эта конфигурация становится частью среды развернутой службы как переменные среды, так и в файлах конфигурации, упакованных с развертыванием.

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

Выходные переменные: Bicep и Terraform могут выводить значения, такие как URL-адреса и строки подключения, после развертывания. Эти выходные данные становятся доступными в виде переменных среды на этапе развертывания, поэтому перед началом развертывания можно настроить службы с правильными конечными точками.

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

Шаблон вставки/обновления контейнера: проверенные Azure модули (AVM) предоставляют контейнерные шаблоны приложений, такие как container-app-upsert, которые беспрепятственно работают с двухфазным рабочим процессом azd. Во время подготовки создаются инфраструктура и начальный контейнер. Во время развертывания azd обновляет образ контейнера, добавляя актуализированные переменные среды, включающие значения, созданные в процессе предоставления, такие как строки подключения к базе данных или URL-адреса службы. Этот шаблон устраняет проблему с курицей и яйцом, позволяя инфраструктуре существовать сначала, а затем обновлять конфигурацию контейнера со всеми необходимыми сведениями о зависимости.

Пример рабочего процесса для интерфейса React с серверной частью API контейнера:

1. Запуск azd up, который выполняет пакет, подготовку и развертывание этапов последовательно.
2. Во время развертывания Bicep создает инфраструктуру контейнерных приложений Azure с использованием модулей AVM container-app-upsert и выводит back-end URL-адрес API.
3. Во время развертывания azd автоматически обновляет оба контейнера с правильными переменными среды, включая URL-адрес API для внешнего интерфейса.
4. Обе службы начинаются с правильной конфигурации. Будущие запуски azd up или azd deploy обновляют контейнеры с любыми новыми значениями конфигурации.

Конфигурация среды выполнения

Конфигурация среды выполнения позволяет приложениям загружать конфигурацию при запуске приложения, а не во время развертывания. Этот подход обеспечивает гибкость для обновления конечных точек службы, строк подключения и политик без повторного развертывания приложения.

Источники конфигурации: приложения могут загружать конфигурацию среды выполнения из двух основных источников:

• Локальные файлы конфигурации: разверните файл конфигурации, например config.jsonвместе с приложением. Приложение загружает этот файл при запуске, чтобы получить URL-адреса текущей конечной точки, параметры проверки подлинности и другие значения конфигурации. Этот подход хорошо подходит для клиентских платформ, таких как React, Angular, Vue и Blazor WebAssembly, которые могут получить конфигурацию при запуске приложения в браузере.

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

Преимущества. При любом подходе изменения конфигурации становятся доступными немедленно без повторного развертывания. Обновите файл конфигурации с помощью конвейера развертывания или измените значения в службе "Конфигурация приложений Azure " на портале Azure. При перезапуске или обновлении конфигурации приложение получает новые значения. Этот шаблон особенно полезен для:

• Фронтенд-приложения, которые должны обнаруживать URL-адреса API бэкенда, эндпоинты аутентификации и расположения микросервисов.
• Бэкенд-сервисы, которые должны обновлять политики CORS по мере изменения URL-адресов фронтенда
• Службы, которым требуется другая конфигурация в средах разработки, промежуточной и рабочей среды

Пример рабочего процесса для внешнего интерфейса React, который обнаруживает внутренний API:

1. Запустите azd up для подготовки инфраструктуры и развертывания обеих служб.
2. После выполнения развертывания хук создает config.json файл, содержащий URL-адрес серверной части, и отправляет его в расположение хранилища фронтенда.
3. Приложение React получает config.json при запуске, чтобы обнаружить конечную точку API.
4. Чтобы обновить конечную точку позже, измените config.json без повторного развертывания внешнего интерфейса.

Этот подход не подходит для статически созданных сайтов, где все содержимое предварительно отрисовывается во время сборки.

Планирование рабочего процесса развертывания

При разработке развертывания с полным стеком следует учитывать следующие факторы:

1. Определение зависимостей. Сопоставление служб, которым требуются сведения из других служб. Для однонаправленных зависимостей (таких как API в зависимости от базы данных), платформа подготовки (Bicep или Terraform) автоматически обрабатывает упорядочение. Для циклических зависимостей (таких как интерфейсные и внутренние службы, которые оба нуждаются в URL-адресах друг друга при запуске), необходимо разработать координацию с помощью стратегий конфигурации времени развертывания или среды выполнения.
2. Подготовка перед развертыванием. Убедитесь, что все инфраструктуры существуют перед развертыванием кода приложения.
3. Используйте переменные среды: передача конфигурации между инфраструктурой и уровнями приложений с помощью переменных среды azd.
4. Проектирование для нескольких сред. Планирование разных конфигураций в разных средах разработки, промежуточной и рабочей среды.
5. Рассмотрим порядок развертывания. Для некоторых сценариев может потребоваться развертывание служб в определенной последовательности.

Команда azd up обрабатывает большинство сценариев развертывания, автоматически выполняя подготовку, а затем развертывание в одном рабочем процессе. Для стандартных отдельных приложений этот подход хорошо работает и требует минимальной конфигурации.

Для более сложных развертываний, таких как полный стек с циклическими зависимостями:

• Настройка порядка обслуживания. В azure.yaml файле определите службы в том порядке, в который они будут развернуты. По умолчанию azd выполняется параллельное развертывание служб, однако при необходимости можно использовать хуки для обеспечения последовательного развертывания.

• Настройка шагов рабочего процесса: Переопределите рабочий процесс по умолчанию azd up, определив пользовательское workflows свойство в azure.yaml файле. Например, можно изменить поведение по умолчанию для запуска подготовки перед созданием исходного кода приложения:

  name: todo-nodejs-mongo
  metadata:
    template: todo-nodejs-mongo@0.0.1-beta
  workflows:
    up: 
      steps:
        - azd: provision
        - azd: package
        - azd: deploy
  

  Этот шаблон полезен, если процесс сборки нуждается в значениях конфигурации, которые доступны только после завершения подготовки.

• Отдельная подготовка и развертывание: вместо использования azd up, запускайте azd provision и azd deploy отдельно как команды. Это разделение полезно, если необходимо проверить конфигурацию инфраструктуры перед развертыванием кода приложения или при устранении неполадок с развертыванием. Вы можете развернуть инфраструктуру один раз, а затем разворачивать и разворачивать повторно код приложения несколько раз без повторного развертывания инфраструктуры.

• Настройка с помощью хуков: Добавьте в ваш файл хуки до и после azure.yaml для выполнения пользовательской логики между этапами подготовки и развертывания. Используйте хуки для заполнения файлов конфигурации, проверки состояния среды или координации сложных процессов развертывания.

Лучшие практики

При создании полностековых приложений с azd следуйте следующим рекомендациям.

1. Раннее сопоставление зависимостей: определите, какие службы нуждаются в информации из других служб на этапе разработки. Различайте однонаправленные зависимости, которые Bicep или Terraform обрабатывают автоматически, и циклические зависимости, требующие стратегий конфигурации на этапе развертывания или во время выполнения.
2. Выберите правильную стратегию конфигурации: используйте конфигурацию во время развертывания, если службам требуется блокировка конфигурации во время развертывания. Используйте конфигурацию среды выполнения, если требуется гибкость для обновления конфигурации без повторного развертывания. Объединяйте обе стратегии при необходимости.
3. Используйте проверенные модули Azure (AVM): используйте модули Bicep, проверенные Azure , например container-app-upsert для приложений контейнеров. Эти шаблоны легко работают с azdдвухфазным рабочим процессом для разрешения циклических зависимостей.
4. При необходимости настройте рабочие процессы: для простых развертываний используйте azd up параметры по умолчанию. Для сложных сценариев с циклическими зависимостями настройте workflows свойство в azure.yaml файле для контроля порядка упаковки, подготовки и развертывания.
5. Использование конфигурации среды выполнения. Для обеспечения максимальной гибкости в разных средах используйте конфигурацию приложений Azure или локальные файлы конфигурации для управления конечными точками и параметрами службы, которые можно обновить без повторного развертывания.
6. Тестирование в разных средах. Убедитесь, что стратегия настройки работает правильно в разных средах разработки, промежуточной и рабочей среды, где URL-адреса и конфигурации службы отличаются.

Дальнейшие шаги

• Развертывание в приложениях контейнеров Azure с помощью интерфейса командной строки разработчика Azure
• Шаблоны развертывания с полным стеком
• Общие сведения о шаблонах ИНТЕРФЕЙСА командной строки разработчика Azure
• Изучение рабочего процесса azd up