Поделиться через

Технологии развертывания в Функции Azure

Вы можете использовать несколько различных технологий для развертывания кода проекта Функции Azure в Azure. В этой статье приводятся общие сведения о доступных методах развертывания и рекомендации для лучшего способа использования в различных сценариях. Он также содержит полный список и основные сведения о базовых технологиях развертывания.

Методы развертывания

Технология развертывания, используемая для публикации кода в приложении-функции в Azure, зависит от конкретных потребностей и точки в цикле разработки. Например, во время разработки и тестирования можно развернуть непосредственно из средства разработки, например Visual Studio Code. Когда приложение работает в рабочей среде, вы, скорее всего, будете постоянно публиковать данные из системы управления версиями или с помощью конвейера автоматической публикации, который может включать проверку и тестирование.

В следующей таблице описаны доступные методы развертывания для проекта кода.

Тип развертывания Методы Оптимален для
На основе инструментов • Azure CLI
• Visual Studio Code публикация
• публикация в Visual Studio
Публикация Core Tools		 Развертывания в процессе разработки и другие импровизированные операции. Развертывание кода по запросу с помощью локальных средств разработки.
Управляемый Службой приложений • Центр развертывания (CI/CD)
• Развертывания контейнеров		 Непрерывное развертывание (CI/CD) из системы управления исходным кодом или из реестра контейнеров. Платформа службы приложений (Kudu) управляет развертываниями.
Внешние конвейеры • Azure Pipelines
• GitHub Actions		 Рабочие конвейеры, включающие проверку, тестирование и другие действия, которые должны выполняться в рамках автоматического развертывания. Пайплайн управляет развертываниями.

Используйте лучшую технологию для конкретного сценария. Многие методы развертывания основаны на zip-развертывании, которое рекомендуется для развертывания.

Доступность технологии развертывания

Метод развертывания также зависит от плана размещения и операционной системы, на которой выполняется ваше приложение функции.

В настоящее время Функции предлагают пять вариантов размещения приложений-функций:

Каждый план имеет разные особенности. Не все технологии развертывания доступны для каждого плана размещения и операционной системы. Эта диаграмма содержит сведения о поддерживаемых технологиях развертывания:

Технология развертывания Потребление Flex Потребление Эластик Премиум Предназначенные Контейнерные приложения
Единое развертывание ✔
Развертывание ZIP-файла ✔ ✔ ✔
URL-адрес внешнего пакета1 ✔ ✔ ✔
Контейнер Docker Только для Linux Только для Linux Только для Linux ✔
Управление исходным кодом только Windows ✔ ✔
Локальный Git1 только Windows ✔ ✔
FTPS1 только Windows ✔ ✔
Редактированиена портале 2 ✔ ✔ ✔

1 Технологии развертывания, требующие ручной синхронизации триггеров , не рекомендуется.
2 Редактирование на портале отключено при развертывании кода в приложении-функции за пределами портала. Дополнительные сведения, включая сведения о поддержке языка для редактирования на портале, см . в разделе "Сведения о поддержке языка".

Основные понятия

Некоторые ключевые понятия важны для понимания работы развертываний в Функции Azure.

Синхронизация триггеров

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

При использовании этих параметров развертывания всегда необходимо синхронизировать триггеры вручную:

Триггеры синхронизации можно синхронизировать вручную одним из следующих способов:

  • Перезапустите функциональное приложение в портале Azure. Хост функций выполняет фоновую синхронизацию триггера после запуска приложения.

  • az rest Используйте команду для отправки HTTP-запроса POST, вызывающего syncfunctiontriggers API, как в следующем примере:

    az rest --method post --url https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME>/syncfunctiontriggers?api-version=2016-08-01

Имейте в виду эти рекомендации для операции триггеров синхронизации:

  • Вы должны вручную перезапустить функциональное приложение каждый раз при развертывании обновленной версии пакета развертывания с использованием того же URL-адреса внешнего пакета.
  • Для приложений, работающих в плане "Потребление" или "Эластичные премиум", необходимо также вручную синхронизировать триггеры в следующих сценариях:
    • При развертывании используется URL-адрес внешнего пакета с развертыванием на основе диспетчера ресурсов с помощью шаблонов ARM или Bicep или файлов Terraform.
    • При обновлении пакета развертывания на месте, используя тот же URL внешнего пакета.
  • При добавлении сетевых ограничений в существующее функциональное приложение необходимо обеспечить подключение к учетной записи хранения узла по умолчанию, установленной в параметре приложения AzureWebJobsStorage. Дополнительные сведения см. в разделе Как использовать безопасную учетную запись хранения с Функции Azure.

Удаленная сборка

Вы можете запросить Функции Azure выполнить удаленную сборку проекта кода во время развертывания. В этих сценариях запросите удаленную сборку вместо локального создания:

  • Вы развертываете приложение в приложении-функции под управлением Linux, разработанном на компьютере Windows. Эта ситуация обычно относится к разработке приложений Python. При сборке пакета развертывания локально на Windows можно получить неправильные библиотеки.
  • Ваш проект имеет зависимости от индекса пользовательских пакетов.
  • Вы хотите уменьшить размер пакета развертывания.

Запрос удаленной сборки зависит от того, работает ли ваше приложение в Azure на Windows или Linux.

Все функциональные приложения, работающие на Windows, имеют небольшое приложение управления, “сайт scm”, предоставляемый Kudu. Этот сайт обрабатывает большую часть логики развертывания и сборки для Функции Azure.

При развертывании приложения в Windows процесс развертывания выполняет команды, относящиеся к языку, например dotnet restore (C#) или npm install (JavaScript).

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

  • Удаленные сборки поддерживаются для функциональных приложений, работающих на Linux в тарифе Consumption. Однако варианты развертывания ограничены для этих приложений, так как у них нет scm сайта Kudu.
  • Приложения-функции, работающие на Linux в плане Premium или в плане Dedicated (App Service) действительно имеют сайт scm (Kudu), но он менее функционален по сравнению с версией для Windows.
  • Удаленные сборки не происходят, когда приложение использует запуск из пакета. Чтобы узнать, как использовать удаленную сборку в этих случаях, см. Zip deploy.
  • У вас могут возникнуть проблемы с удаленной сборкой, когда приложение было создано до того, как эта функция была доступна (1 августа 2019 г.). Для старых приложений создайте новое приложение-функцию или запустите az functionapp update --resource-group <RESOURCE_GROUP_NAME> --name <APP_NAME> для обновления приложения-функции. Для выполнения этой команды может потребоваться две попытки.

Хранилище содержимого приложения

Методы развертывания на основе пакетов хранят пакет в учетной записи хранения, связанной с приложением-функцией, которое определяет параметр AzureWebJobsStorage . Если доступно, приложения тарифных планов «Потребление» и «Эластичный премиум» пытаются использовать общий ресурс данных Файлы Azure из этой учетной записи, но вы также можете хранить пакет в другом месте. Приложения плана потребления Flex используют контейнер хранилища в учетной записи хранения по умолчанию, если для развертывания не настроена другая учетная запись хранения. Для получения дополнительной информации ознакомьтесь с разделом "Где содержимое приложения хранится в каждой технологии развертывания", которые рассматриваются в следующем разделе.

Внимание

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

Защищенные виртуальные сети

Если приложение-функция имеет частные конечные точки и отключен доступ к общедоступной сети, scm сайт развертывания Kudu недоступен для общедоступного доступа. Если учетная запись хранения, используемая приложением-функцией, также защищена за частными конечными точками, технологии, которые должны получать доступ к хранилищу, также блокируются. Из-за этих ограничений, описанных в этой статье, технологии развертывания не могут достичь полностью защищенного функционального приложения извне виртуальной сети.

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

Дополнительные сведения о настройке функции приложения в виртуальной сети можно найти в статье Как настроить функции Azure с виртуальной сетью.

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

Следующие методы развертывания доступны в Функции Azure. Чтобы определить, какие технологии поддерживают каждый план размещения, см. таблицу доступности технологий развертывания .

Одно развертывание

Технология единого развертывания — это единственная технология развертывания, поддерживаемая для приложений в плане потребления Flex. Конечный результат — это готовый пакет .zip, на котором работает приложение-функция.

Как использовать: Развертывайте с использованием функции публикации Visual Studio Code или из командной строки с помощью Функции Azure Core Tools или Azure CLI. Задача Azure DevOps и GitHub Action аналогично используют одно развертывание, когда обнаруживают, что приложение Flex Consumption развёртывается.

При создании приложения Flex Consumption необходимо указать контейнер для хранения объектов blob для развертывания, а также метод аутентификации к нему. По умолчанию используется тот же аккаунт хранения, что и для подключения AzureWebJobsStorage, с использованием строки подключения (строка подключения) в качестве метода аутентификации. Таким образом, параметры развертывания настраиваются во время создания приложения без каких-либо параметров приложения.

Когда его следует использовать: Одно развертывание — это единственная технология развертывания, доступная для приложений-функций, работающих в плане потребления Flex.

Где хранится содержимое приложения: при создании приложения-функции Flex Consumption необходимо указать контейнер хранилища развертывания. В этом контейнере блобов ваши инструменты загружают контент приложения, который вы развернули. Чтобы изменить расположение, перейдите в колонку "Параметры развертывания" на портале Azure или используйте Azure CLI.

Подсказка

Средство диагностики для развертывания Flex Consumption доступно на портале Azure. Откройте приложение Flex Consumption, выберите "Диагностика и решение проблем" и выполните поиск Flex Consumption Deployment. В этом средстве отображаются подробные сведения о развертываниях, включая журнал развертывания, состояние пакета и рекомендации по устранению неполадок.

Развертывание из ZIP-файла

Zip-развертывание — это стандартная и рекомендуемая технология развертывания для приложений-функций в планах Потребление, Эластичный Premium и Служба приложений (выделенные). Конечный результат — это готовый пакет .zip, на котором работает приложение-функция. Он отличается от URL-адреса внешнего пакета в том, что платформа отвечает за удаленное построение и хранение содержимого приложения.

How to use it: Deploy by using your favorite client tool: Visual Studio Code, Visual Studio или из командной строки с помощью Функции Azure Core Tools или Azure CLI. Наша задача Azure Dev Ops и GitHub Action аналогично используют zip-развертывание.

При развертывании из ZIP-файла можно настроить приложение для запуска из пакета. Для выполнения запуска из пакета необходимо установить параметр приложения WEBSITE_RUN_FROM_PACKAGE в значение 1. Рекомендуется использовать развертывание из ZIP-файла. Он обеспечивает более быстрое время загрузки приложений, и это по умолчанию для VS Code, Visual Studio и Azure CLI.

Когда использовать: Zip-развертывание — это стандартная и рекомендуемая технология развертывания для приложений-функций в планах потребления Windows, Windows и Linux Elastic Premium, а также в планах Windows и Linux Служба приложений (Выделенные).

Где хранится содержимое приложения: Содержимое приложения, развернутого из ZIP-файла, по умолчанию хранится в файловой системе, которая может поддерживаться Файлы Azure из учетной записи хранения, указанной при создании приложения-функции. В среде потребления Linux содержимое приложения сохраняется в блобе в учетной записи хранения, указанной с помощью AzureWebJobsStorage параметра приложения, а параметр WEBSITE_RUN_FROM_PACKAGE приложения принимает значение URL-адреса блоба.

URL-адрес внешнего пакета

URL-адрес внешнего пакета — это параметр, если вы хотите вручную управлять выполнением развертываний. Вы несете ответственность за загрузку готового для запуска пакета .zip, содержащего построенное содержимое приложения в хранилище BLOB-объектов и использование этого внешнего URL-адреса в качестве настройки приложения в вашем приложении-функции. При перезапуске приложения он извлекает пакет, подключает его и запускается в режиме запуска из пакета .

Как использовать. Добавьте WEBSITE_RUN_FROM_PACKAGE в параметры приложения. Значение этого параметра должно быть URL-адресом blob, указывающим на расположение конкретного пакета, который нужно запустить в приложении. Можно добавить параметры на портале или с помощью Azure CLI.

Если вы используете Хранилище BLOB-объектов Azure, ваше функциональное приложение может получить доступ к контейнеру либо с помощью подключения на основе управляемых удостоверений, либо с общим доступом с помощью SAS (Shared Access Signature). Выбор параметра влияет на тип URL-адреса, который вы используете в качестве значения для WEBSITE_RUN_FROM_PACKAGE. Управляемое удостоверение рекомендуется для общей безопасности, так как срок действия маркеров SAS истекает и должен поддерживаться вручную.

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

Когда его использовать: URL-адрес внешнего пакета является единственным поддерживаемым методом развертывания для приложений, работающих в плане потребления Linux, если вы не хотите выполнять удаленную сборку . Этот метод также является рекомендуемой технологией развертывания при создания приложения без Файлы Azure. Для масштабируемых приложений, работающих на Linux, следует рассмотреть размещение на тарифном плане Flex Consumption.

Где хранится содержимое приложения: вы несете ответственность за загрузку содержимого вашего приложения в хранилище объектов BLOB. Вы можете использовать любой учетную запись для хранения blob-данных, хотя Хранилище BLOB-объектов Azure рекомендуется.

Контейнер Docker

Вы можете развернуть функциональное приложение, запущенное в контейнере Linux.

How to use it:Create your functions in a Linux container затем, разверните контейнер в плане "Премиум" или "Выделенный" в Функции Azure или другом хосте контейнера. Используйте Функции Azure Core Tools для создания настраиваемого Dockerfile для вашего проекта, чтобы собрать контейнеризированное функциональное приложение. Контейнер можно использовать в следующих развертываниях:

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

Где хранится содержимое приложения: Содержимое приложения хранится в указанном реестре контейнеров в составе образа.

Управление исходным кодом

Вы можете включить непрерывную интеграцию между приложением-функцией и репозиторием исходного кода. При включении системы управления версиями обновление кода в подключенном исходном репозитории активирует развертывание последнего кода из репозитория. Дополнительные сведения см. в непрерывном развертывании для Функции Azure.

Практическое руководство. Самый простой способ настройки публикации из системы управления версиями — из Центра развертывания в области "Функции" портала. Дополнительные сведения см. в разделе Континуальное развертывание Функции Azure.

Когда использовать: Использование системы управления версиями — это лучшая методика для команд, которые совместно работают над функциональными приложениями. Контроль версий — хороший вариант развертывания, который позволяет использовать более сложные конвейеры развертывания. Обычно вы включаете систему управления версиями в промежуточном слоте, который можно переключить в продакшн после проверки обновлений из репозитория. Дополнительные сведения см. в разделе Функции Azure слоты развертывания.

Где хранится содержимое приложения: Система контроля версий хранит содержимое приложения. Файловая система приложения сохраняет локально клонированный и построенный формат содержимого приложения, который может поддерживаться Файлы Azure из учетной записи хранения, указанной при создании приложения-функции.

Локальный репозиторий Git

Используйте локальный Git для отправки кода с локального компьютера в Функции Azure с помощью Git.

How to use it: Следуйте инструкциям в развертывании Local Git для Служба приложений Azure.

Когда его следует использовать: Чтобы снизить вероятность ошибок, не используйте методы развертывания, требующие дополнительного шага синхронизации триггеров вручную. Используйте zip-развертывание по возможности.

Где хранится содержимое приложения: Содержимое приложения хранится в файловой системе, которая может поддерживаться Файлы Azure в учетной записи хранения, указанной при создании функционального приложения.

FTP/S

Вы можете использовать FTP/S для прямого передачи файлов в Функции Azure, но не используйте этот метод развертывания. Если вы не планируете использовать FTP, отключите его. Если вы решили использовать FTP, примените FTPS. Информация о том, как это сделать в портале Azure, см. в статье Enforce FTPS.

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

Когда его следует использовать: Чтобы снизить вероятность ошибок, не используйте методы развертывания, требующие дополнительного шага синхронизации триггеров вручную. Используйте zip-развертывание по возможности.

Где хранится содержимое приложения: Содержимое приложения хранится в файловой системе. Развертывания FTP/FTPS завершаются сбоем, если файловая система вашего приложения поддерживается Файлы Azure в учетной записи хранения узла по умолчанию. FTP/FTPS не работает с Файлы Azure в качестве подключенного хранилища из-за ограничений FTP.

Редактирование на портале

В редакторе на портале вы можете непосредственно изменять файлы, которые находятся в вашем функциональном приложении (по сути, каждый раз развёртывая заново при сохранении изменений).

Как использовать его: Чтобы изменить функции на портале Azure необходимо создать функции на портале. С целью сохранения единого источника достоверного кода, использование любого другого метода развертывания сделает функцию доступной только для чтения и не позволит продолжить редактирование на портале. Чтобы вернуться к состоянию, в котором можно изменить файлы на портале Azure, можно вручную вернуть режим редактирования в Read/Write и удалить все параметры приложения, связанные с развертыванием (например, WEBSITE_RUN_FROM_PACKAGE).

Когда использовать его: Портал — отличный способ начать работу с Функции Azure. Из-за ограничений разработки на портале Azure, следует использовать одно из следующих клиентских средств для более сложной разработки:

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

Поведение развертывания

При развертывании обновлений в коде приложения-функции поведение развертывания зависит от плана размещения:

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

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

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

Слоты развертывания

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

Способ развертывания в слоте зависит от используемого средства развертывания. Например, при использовании основных средств Функции Azure включите параметр --slot, чтобы указать имя определенного слота для команды func azure functionapp publish.

Дополнительные сведения о слотах развертывания см. в документации о слотах развертывания Функции Azure.

Следующие шаги

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

  • Last updated on