Перемещение Статические веб-приложения Azure в другой регион

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

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

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

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

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

• Убедитесь, что Статические веб-приложения Azure доступен в целевом регионе.

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

• Узнайте, применяются ли ограничения Политика Azure региона к вашей организации.

• Если используется встроенная поддержка API, предоставляемая Функции Azure:

  • Определите доступность Функции Azure в целевом регионе.
  • Определите, используются ли ключи API функций. Например, вы используете Key Vault или развертываете их в составе файлов конфигурации приложения?
  • Определите модель развертывания для поддержки API в целевом регионе: предоставление собственных функций. Общие сведения о различиях между двумя моделями.

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

• Определите допустимое время простоя для перемещения.

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

  • Функции Azure.
  • Виртуальная сеть Azure
  • Azure Front Door
  • Группа безопасности сети
  • Служба Приватный канал Azure
  • Azure Key Vault
  • Учетная запись хранения Azure
  • Шлюз приложений Azure

Простой

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

• Холодный резервный режим: данные рабочей нагрузки регулярно резервируются на основе его требований. В случае аварии рабочая нагрузка повторно развертывается в новом регионе Azure, а данные восстанавливаются.
• Теплый режим ожидания: рабочая нагрузка развертывается в регионе непрерывности бизнес-процессов и аварийном восстановлении (BCDR), а данные реплицируются асинхронно или синхронно. В случае аварии развертывание в регионе аварийного восстановления (АВАРИЙНОго восстановления) масштабируется и выходит.
• Несколько регионов: рабочая нагрузка развертывается в обоих регионах , а данные реплицируются синхронно. Оба региона имеют записываемую копию данных. Реализация может быть активной или пассивной или активной или активной.

Подготовить

Развертывания с частными конечными точками

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

• Обновите имя узла для конечной точки подключения.
• Обновите имя узла в частной зоне DNS или пользовательском DNS-сервере (применимо только к Приватный канал).

Дополнительные сведения см. в разделе "Настройка частной конечной точки" в Статические веб-приложения Azure.

Все остальные развертывания

Для всех других типов развертывания обязательно выполните следующие действия.

• Если применимо, получите новые ключи API функций из Функции Azure в новом регионе.

• Если функция Azure имеет зависимость от базы данных, убедитесь, что она обновлена DATABASE_CONNECTION_STRING . Эта база данных может не находиться в области региональной миграции.

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

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

Экспорт шаблона

Чтобы экспортировать шаблон Resource Manager, содержащий параметры, описывающие статическое веб-приложение:

1. Войдите на портал Azure.

2. Перейдите в статическое веб-приложение.

3. В меню слева в разделе Автоматизация выберите Экспорт шаблона.

   Для создания шаблона может потребоваться некоторое время.

4. Выберите Скачать.

5. Найдите скачанный .zip файл и откройте его в папку вашего выбора.

   Этот файл содержит .json файлы, включающие шаблон и скрипты для развертывания шаблона.

6. Внесите необходимые изменения в шаблон, например обновление расположения с помощью целевого региона.

Перемещать

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

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

2. Если вы предоставили существующую Функции Azure для статического веб-приложения, выполните процедуру перемещения для Функции Azure.

3. Повторно разверните статическое веб-приложение с помощью шаблона, экспортированного и настроенного в предыдущем разделе.

   Внимание

   Если вы не используете личный домен, URL-адрес приложения изменяется в целевом регионе. В этом сценарии убедитесь, что пользователи знают об изменении URL-адреса.

4. Если вы используете интегрированный API, создайте новый интегрированный API, поддерживаемый Функции Azure.

5. Перенастройьте репозиторий (GitHub или Azure DevOps), чтобы развернуть его в недавно развернутом статическом веб-приложении в целевом регионе. Инициируйте развертывание приложения с помощью действий GitHub или Azure Pipelines.

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