Перенос приложений

  • 8 мин

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

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

В этом уроке вы изучите обновления, необходимые для подключения к недавно перенесенной базе данных Azure для PostgreSQL.

Создание ролей пользователей вручную

При передаче базы данных PostgreSQL в Базу данных Azure для PostgreSQL с помощью Azure Database Migration Service роли и назначения ролей не копируются. Необходимо вручную создать необходимые роли и учетные записи пользователей для администраторов и пользователей таблиц в целевой базе данных. Для выполнения этих задач используйте служебные программы psql или pgAdmin. Выполните команду CREATE ROLE. Команда GRANT используется для назначения необходимых привилегий роли. Рассмотрим пример.

CREATE ROLE myuseraccount WITH LOGIN NOSUPERUSER CREATEDB PASSWORD 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE mydatabase TO myuseraccount;

Примечание.

Вы также используете команду createuser из командной строки Bash для создания ролей PostgreSQL.

Чтобы просмотреть существующие роли в локальной базе данных, выполните следующую инструкцию SQL:

SELECT rolname
FROM pg_roles;

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

                              List of roles
   Role name   |               Attributes                                   | Member of
---------------+------------------------------------------------------------+-----------
 azureuser     | Superuser, Create DB                                       | {}
 myuseraccount | Create DB                                                  | {}
 postgres      | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

Примечание.

Обратите внимание, что База данных Azure для PostgreSQL добавляет некоторые роли самостоятельно. К этим ролям относятся azure_pg_admin, azure_superuserи пользователь администратора, указанный при создании службы. Вы войдите с помощью учетных записей администратора, но остальные две роли зарезервированы для использования в Azure. Их не следует пытаться использовать.

Перенастройка приложений

Перенастройка приложения для подключения к Базе данных Azure для PostgreSQL — это простой процесс. Однако более важно определить стратегию для приложений миграции.

Рекомендации по перенастройки приложений PostgreSQL

В корпоративной среде может быть много приложений, работающих в одних и том же базах данных PostgreSQL. Может быть большое количество пользователей, работающих с этими приложениями. Вы хотите убедиться, что при переходе из существующей системы в Базу данных Azure для PostgreSQL ваши системы по-прежнему будут работать, пользователи могут продолжать выполнять свои задания, а критически важные для бизнеса операции остаются в эксплуатации. Модуль 1, урок 2, рекомендации по миграции, обсудили многие вопросы в целом. При переносе базы данных PostgreSQL в Azure существуют некоторые особенности.

  • Если вы выполняете автономную миграцию, данные в исходной базе данных PostgreSQL и новые базы данных, запущенные в Azure, могут быстро отличаться, если старая база данных по-прежнему используется. Автономная миграция подходит, если вы полностью переключите систему из эксплуатации в течение короткого времени, а затем переключите все приложения в новую систему, прежде чем запускать снова. Такой подход может оказаться невозможным для критически важной для бизнеса системы. Если вы выполняете миграцию в PostgreSQL на виртуальной машине Azure, настройте репликацию PostgreSQL между локальной системой и запущенной в Azure. Репликация Native PostgreSQL работает только в одном направлении, но сторонние решения доступны, поддерживающие двунаправленную репликацию между серверами PostgreSQL (эти решения не будут работать с Базой данных Azure для PostgreSQL).
  • Если вы выполняете миграцию через Интернет, служба Базы данных Azure для PostgreSQL настраивает репликацию из локальной базы данных в базу данных, запущенную в Azure. После первоначальной передачи данных репликация гарантирует, что все изменения, внесенные в локальную базу данных, копируются в базу данных в Azure, но не наоборот.

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

  • Перенос приложений на основе типа рабочей нагрузки. Приложение, которое обращается к данным только для чтения, может безопасно перемещаться в базу данных, запущенную в Базе данных Azure для PostgreSQL, и увидит все изменения, внесенные приложениями, по-прежнему с помощью локальной базы данных. Вы также можете применить стратегию обратного взаимодействия, если приложения только для чтения не требуют полностью up-toданных даты.
  • Перенос пользователей на основе типа рабочей нагрузки. Эта стратегия аналогична предыдущей, за исключением того, что у вас могут быть пользователи, которые создают только отчеты, а другие изменяют данные. Возможно, у вас есть то же приложение, настроенное для подключения к соответствующей базе данных в соответствии с требованиями пользователей.
  • Перенос приложений на основе используемых наборов данных. Если разные приложения используют разные подмножества данных, вы можете перенести эти приложения независимо друг от друга.

Перенастройка приложения

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

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

изображение со страницей строк подключения для элемента Базы данных Azure для PostgreSQL на портале Azure

Открытие сетевых портов

Как упоминалось на занятии 1 этого модуля, База данных Azure для PostgreSQL — это защищенная служба, которая выполняется за брандмауэром. Клиенты не могут подключаться, если его IP-адрес не распознается службой. Необходимо добавить IP-адреса или диапазоны блоков адресов для клиентов под управлением приложений, которые должны подключаться к базам данных.

Тестирование и проверка приложений

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

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

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

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