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

Перемещение приложения-функции в другой регион Azure

  • Статья

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

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

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

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

Эти же ресурсы можно переместить в другую группу ресурсов или подписку, пока они остаются в одном регионе. Дополнительные сведения см. в статье "Перемещение Служба приложений ресурсов в новую группу ресурсов или подписку".

Необходимые компоненты

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

Подготовить

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

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

Имя приложения-функции

Имена приложений-функций должны быть глобально уникальными во всех приложениях Azure. Это означает, что новое приложение-функция не может иметь то же имя и URL-адрес, что и исходный. Это даже верно при использовании пользовательского DNS, так как базовый <APP_NAME>.azurewebsites.net элемент должен быть уникальным. Может потребоваться обновить все клиенты, которые подключаются к конечным точкам HTTP в приложении-функции. Эти клиенты должны использовать новый URL-адрес при выполнении запросов.

Исходный код

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

Учетная запись хранения по умолчанию

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

Сохраненное локальное хранилище

Выполнение функций предназначено для без отслеживания состояния. Однако мы не препятствуем записи данных в локальную файловую систему. Данные, созданные и используемые приложением, можно хранить на виртуальном %HOME%\site диске, но эти данные не должны быть связанными с состоянием. Если в вашем сценарии требуется поддерживать состояние между выполнением функций, рекомендуется вместо этого использовать Устойчивые функции.

Если приложение сохраняет данные в общем пути к хранилищу приложения, убедитесь, что вы планируете управлять этим состоянием во время перемещения ресурсов. Помните, что для приложений плана выделенных (Служба приложений) общий доступ является частью сайта. Для планов потребления и уровня "Премиум" общая папка по умолчанию представляет собой Файлы Azure общий ресурс в учетной записи хранения по умолчанию. Приложения, работающие в Linux, могут использовать явно подключенную общую папку для сохраняемого хранилища.

Подключенные службы

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

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

Настройка

  • Вы можете записать моментальный снимок существующих параметров приложения и строка подключения из портал Azure. Разверните переменные среды параметров, выберите "Дополнительно изменить" в разделе "Параметры> приложения" или "Строки подключений" и сохраните выходные данные JSON, содержащие существующие параметры или подключения. Необходимо повторно создать эти параметры в новом регионе, но сами значения, скорее всего, изменятся в результате последующих изменений региона в подключенных службах.

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

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

Личные домены

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

Виртуальные сети

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

Удостоверения

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

  • Управляемые удостоверения, назначаемые пользователем, также не могут быть перемещены по регионам. Чтобы сохранить назначаемые пользователем управляемые удостоверения в одной группе ресурсов с приложением, необходимо повторно создать их в новом регионе. Дополнительные сведения см. в статье "Перемещение управляемых удостоверений для ресурсов Azure в другой регион".

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

Сертификаты

Служба приложений ресурсы сертификатов можно переместить в новую группу ресурсов или подписку, но не в разных регионах. Сертификаты, которые можно экспортировать, также можно импортировать в приложение или в Key Vault в новом регионе. Этот процесс экспорта и импорта эквивалентен перемещению между регионами.

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

Тип сертификата Доступный для экспорта Комментарии
управляемое Служба приложений No Повторно создайте эти сертификаты в новом регионе.
Управляемый Azure Key Vault Да Эти сертификаты можно экспортировать из Key Vault, а затем импортировать в Key Vault в новом регионе.
Закрытый ключ (самоуправляемый) Да Сертификаты, приобретенные за пределами Azure, можно экспортировать из Служба приложений, а затем импортировать в новое приложение или в Key Vault в новом регионе.
Открытый ключ No Ваше приложение может иметь сертификаты только с открытым ключом и без секрета, который используется для доступа к другим защищенным конечным точкам. Получите необходимые файлы сертификатов открытого ключа и импортируйте их в приложение в новом регионе.

Access keys

Функции используют ключи доступа, чтобы упростить доступ к конечным точкам HTTP в приложении-функции. Эти ключи шифруются в учетной записи хранения по умолчанию. При создании приложения в новом регионе создается новый набор ключей. Необходимо обновить все существующие клиенты, использующие ключи доступа для использования новых ключей в новом регионе. Хотя вы должны использовать новые ключи, можно воссоздать старые ключи в новом приложении. Дополнительные сведения см. в статье "Работа с ключами доступа" в Функции Azure.

Простой

Если минимальное время простоя является обязательным, рассмотрите возможность запуска приложения-функции в обоих регионах, как рекомендуется реализовать архитектуру аварийного восстановления. Определенная архитектура, реализуемая, зависит от типов триггеров в приложении-функции. Дополнительные сведения см. в разделе "Надежность" в Функции Azure.

Устойчивые функции

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

Перемещать

Для повторного создания приложения-функции в новом регионе необходимо сначала воссоздать инфраструктуру Azure плана Служба приложений, экземпляра приложения-функции и связанные ресурсы, такие как виртуальные сети, удостоверения и слоты. Кроме того, необходимо повторно подключиться или повторно создать ресурсы Azure, необходимые приложению. Эти ресурсы могут включать учетную запись служба хранилища Azure по умолчанию и экземпляр Application Insights.

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

Повторное создание инфраструктуры Azure

Существует несколько способов создания приложения-функции и связанных ресурсов в Azure в целевом регионе:

  • Шаблоны развертывания: если вы первоначально развернули приложение-функцию с помощью файлов инфраструктуры как кода (IaC) (Bicep, шаблонов ARM или Terraform), можно обновить эти предыдущие развертывания, чтобы нацелиться на новый регион и использовать их для повторного создания ресурсов в новом регионе. Если у вас больше нет этих файлов развертывания, вы всегда можете скачать шаблон ARM для существующей группы ресурсов из портал Azure.
  • Скрипты Azure CLI/PowerShell. Если вы первоначально развернули приложение-функцию с помощью Azure CLI или скриптов Azure PowerShell, можно обновить эти сценарии, чтобы вместо этого нацелиться на новый регион и снова запустить их. Если у вас больше нет этих скриптов, вы также можете скачать шаблон ARM для существующей группы ресурсов из портал Azure.
  • портал Azure. Если вы создали приложение-функцию на портале изначально или не чувствуете себя комфортно с помощью скриптов или файлов IaC, вы можете просто создать все на портале. Обязательно используйте тот же план размещения, языковую среду выполнения и языковую версию, что и исходное приложение.

Проверка настроенных ресурсов

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

Повторное развертывание исходного кода

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

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

Рекомендации по перемещению

  • Не забудьте проверить конфигурацию и проверить функции в целевом регионе.
  • Если у вас настроен личный домен, переназначите доменное имя.
  • Для приложения-функции, работающего в выделенном плане (Служба приложений), также просмотрите план миграции Служба приложений при совместном использовании плана с одним или несколькими веб-приложениями.

Очистка

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

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