Рефакторинг приложения Linux с помощью службы приложений Azure, диспетчера трафика и базы данных Azure для MySQL

В этой статье показано, как вымышленная компания Contoso выполняет рефакторинг двухуровневого приложения LAMP, перенеся его из локальной среды в Azure, используя Службу приложений Azure с интеграцией с GitHub и Базу данных Azure для MySQL.

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

Бизнес-факторы

Совместными усилиями ИТ-руководство и деловые партнеры определили следующие цели своей деятельности:

  • Адаптация к расширению бизнеса. Компания Contoso растет и переходит на новые рынки. Требуются дополнительные агенты обслуживания клиентов.
  • Масштабирование. Решение должно создаваться таким образом, чтобы компания Contoso имела возможность добавлять дополнительные агенты обслуживания пользователей по мере расширения бизнеса.
  • Повышение устойчивости. Предыдущие проблемы с системой повлияли только на внутренних пользователей. В новой бизнес-модели эти проблемы будут влиять на внешних пользователей, и компании Contoso потребуется, чтобы приложение работало постоянно.

Цели миграции

Для определения наилучшего способа миграции команда Contoso по работе в облаке определила цели миграции.

  • Приложения должны масштабироваться за пределы текущих локальных ресурсов и производительности. Компания Contoso переносит приложение, чтобы воспользоваться преимуществом масштабирования по требованию в Azure.
  • Им необходимо переместить базу кода приложения в конвейер непрерывной поставки. Так как изменения приложения передаются в GitHub, компании Contoso необходимо, чтобы эти изменения развертывались без задействования персонала.
  • Приложение должно быть устойчивым к возможным расширению и отработке отказа. Компании Contoso необходимо развернуть приложение в двух регионах Azure и настроить его таким образом, чтобы оно масштабировалось автоматически.
  • Компании необходимо свести к минимуму задачи администрирования баз данных после переноса приложения в облако.

Архитектура решения

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

Текущая архитектура

  • Приложение размещено на двух виртуальных машинах (OSTICKETWEB и OSTICKETMYSQL).
  • Виртуальные машины расположены на узле VMware ESXi contosohost1.contoso.com (версии 6.5).
  • Среда VMware находится под управлением сервера vCenter Server 6.5 (vcenter.contoso.com), запущенного на виртуальной машине.
  • Компания Contoso использует локальный центр обработки данных (contoso-datacenter) с локальным контроллером домена (contosodc1).

Схема текущей архитектуры.

Предлагаемая архитектура

Ниже приведена предлагаемая архитектура.

  • Приложение веб-уровня на OSTICKETWEB будет перенесено путем создания веб-приложения Службы приложений Azure в двух регионах Azure. Команда Contoso реализует службу приложений Azure для Linux с использованием контейнера Docker PHP 7.0.
  • Код приложения будет перемещен на портал GitHub, а веб-приложение Службы приложений Azure будет настроено для непрерывной поставки с помощью GitHub.
  • Служба приложений Azure будет развернуты как в основном (East US 2), так и в дополнительном регионе (Central US).
  • Диспетчер трафика Azure будет настроен для обслуживания двух веб-приложений Azure в обоих регионах.
  • Диспетчер трафика будет настроен в режиме приоритета для принудительного перенаправления трафика через регион East US 2.
  • Если сервер приложений Azure в East US 2 переходит в автономный режим, пользователи могут использовать версию приложения после отработки отказа в регионе Central US.
  • База данных приложения будет перенесена в службу Базы данных Azure для MySQL с помощью Azure Database Migration Service. Будет создана локальная резервная копия локальной базы данных. Затем будет выполнено ее восстановление в Базу данных Azure для MySQL.
  • База данных будет находиться в основном регионе (East US 2) в подсети базы данных (PROD-DB-EUS2) рабочей сети (VNET-PROD-EUS2).
  • Так как миграция выполняется для рабочей нагрузки в рабочей среде, ресурсы Azure для приложения будут находиться в рабочей группе ресурсов ContosoRG.
  • Ресурс диспетчера трафика будет развертываться в группе ресурсов инфраструктуры компании Contoso ContosoInfraRG.
  • После завершения миграции локальные виртуальные машины в центре обработки данных Contoso будут выведены из эксплуатации.

Схема архитектуры сценария.

Процесс миграции

Порядок миграции в Contoso выглядит следующим образом.

  1. В качестве первого шага администраторы Contoso настраивают инфраструктуру Azure, включая подготовку Службы приложений Azure, настройку диспетчера трафика и подготовку экземпляра Базы данных Azure для MySQL.
  2. После подготовки инфраструктуры Azure они переносят базу данных с помощью Azure Database Migration Service.
  3. После запуска базы данных в Azure администраторы загружают частный репозиторий GitHub для Службы приложений Azure с непрерывной поставкой и загружают его с помощью приложения osTicket.
  4. Затем с портала Azure они загружают приложение из GitHub в контейнер Docker под управлением Службы приложений Azure.
  5. Компания настроила параметры DNS и автоматическое масштабирование приложения.

Схема процесса миграции Contoso.

Службы Azure

Служба Описание Стоимость
служба приложений Azure; Служба работает и масштабирует приложения, используя Azure PaaS для веб-сайтов. Ценовая политика основывается на размере необходимых экземпляров и компонентов. Подробнее.
Azure Traffic Manager Подсистема балансировки нагрузки, использующая службу доменных имен (DNS) для перенаправления пользователей в Azure или на внешние веб-сайты и службы. Ценообразование основано на количестве получаемых запросов DNS и отслеживаемых конечных точек. Подробнее.
Azure Database Migration Service Azure Database Migration Service обеспечивает надежную миграцию из нескольких источников баз данных на платформы данных Azure с минимальным временем простоя. Дополнительные сведения о поддерживаемых регионах см. на странице цен на Database Migration Service.
База данных Azure для MySQL База данных расположена на ядре базы данных MySQL с открытым исходным кодом. Она предоставляет разработанную сообществом, полностью управляемую и готовую к использованию на предприятии базу данных MySQL для разработки и развертывания приложений. Ценообразование основано на вычислении, хранении и резервном копировании. Подробнее.

Предварительные требования

Для выполнения этого сценария компания Contoso должна отвечать приведенным ниже предварительным требованиям.

Требования Сведения
Подписка Azure. Специалисты Contoso создали подписки ранее в этой серии статей. Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure.

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

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

Шаги выполнения сценария

Вот план компании Contoso по выполнению миграции.

  • Шаг 1. Подготовка Службы приложений Azure. Администраторы Contoso подготовят веб-приложения в основном и дополнительном регионах.
  • Шаг 2. Настройка диспетчера трафика. Они настраивают диспетчер трафика перед веб-приложениями с целью маршрутизации и балансировки нагрузки трафика.
  • Шаг 3. Подготовка Базы данных Azure для MySQL. Они подготавливают в Azure экземпляр Базы данных MySQL для Azure.
  • Шаг 4. Миграция базы данных. Они переносят базу данных с помощью Azure Database Migration Service.
  • Шаг 5. Настройка GitHub. Специалисты компании настраивают локальный репозиторий GitHub для веб-сайтов и кода приложения.
  • Шаг 6. Настройка веб-приложений. Они настраивают веб-приложения с помощью веб-сайтов osTicket.

Шаг 1. Подготовка Службы приложений Azure

Администраторы Contoso подготавливают два веб-приложения (по одному в каждом регионе) с помощью Службы приложений Azure.

  1. Они создают ресурс веб-приложения (osticket-eus2) в основном регионе (East US 2) через Azure Marketplace.

  2. Компания добавляет ресурс в рабочую группу ресурсов ContosoRG.

    Снимок экрана: область веб-приложения для создания веб-приложения в Linux.

  3. Специалисты компании создают план службы приложений APP-SVP-EUS2 в основном регионе, применяя стандартный размер.

    Снимок экрана: панель

  4. Специалисты компании выбирают операционную систему Linux со стеком времени выполнения PHP 7.0, который представляет собой контейнер Docker.

    Снимок экрана: область веб-приложения с выбранной ОС Linux, расположением

  5. Специалисты компании создают второе веб-приложение (osticket-cus) и план службы приложений Azure для региона Центральная часть США.

    Снимок экрана: панель веб-приложения с выбранной ОС Linux, расположением в центральной части США и PHP 7.0.

Требуется дополнительная помощь?

Шаг 2. Настройка диспетчера трафика

Администраторы Contoso настраивают диспетчер трафика для направления входящих веб-запросов в веб-приложения веб-уровня osTicket.

  1. В Azure Marketplace они создают ресурс Диспетчера трафика osticket.trafficmanager.net. Они применяют приоритетную маршрутизацию, чтобы регион Восточная часть США 2 был основным сайтом. Специалисты компании размещают ресурс в группе ресурсов инфраструктуры (ContosoInfraRG). Обратите внимание на то, что диспетчер трафика является глобальным и не привязан к определенному месту.

    Снимок экрана: панель

  2. Специалисты компании настраивают диспетчер трафика с конечными точками. Они добавляют веб-приложение в регионе "Восточная часть США 2" в качестве основного сайта (osticket-eus2) и веб-приложение в регионе "Центральная часть США" в качестве дополнительного сайта (osticket-cus).

    Снимок экрана: панель

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

    Снимок экрана: панель

Требуется дополнительная помощь?

Шаг 3. Подготовка Базы данных Azure для MySQL

Администраторы компании Contoso подготавливают экземпляр базы данных MySQL в основном регионе "Восточная часть США 2".

  1. Специалисты компании создают Базу данных Azure для ресурса MySQL на портале Azure.

    Снимок экрана: ссылка на База данных Azure для MySQL в портал Azure.

  2. Они добавляют имя contosoosticket для базы данных Azure. Саму базу данных они добавляют в рабочую группу ресурсов ContosoRG и указывают для нее учетные данные.

  3. В локальной среде используется база данных MySQL 5.7, поэтому для обеспечения совместимости выбрана именно эта версия. Для размера они выбирают значение по умолчанию, соответствующее требованиям компании для базы данных.

    Снимок экрана: панель Сервера MySQL с выбранной версией 5.7.

  4. В разделе Варианты резервирования для архивации специалисты выбирают Геоизбыточное. Этот вариант позволяет восстановить базу данных в дополнительном регионе ("Центральная часть США") в случае сбоя. Данный параметр можно настроить только при подготовке базы данных.

    Снимок экрана: область параметров избыточности резервного копирования с выбранным параметром Geo-Redundant.

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

  6. Они добавляют IP-адрес клиента локальной рабочей станции в начальный и конечный IP-адреса. Это позволяет веб-приложениям получать доступ к базе данных MySQL, а также к ее клиенту, который выполняет перенос.

    Снимок экрана: панель

Шаг 4. Миграция базы данных

Переместить базу данных MySQL можно одним из следующих способов. При использовании любого из вариантов администраторы Contoso должны создать для целевого объекта экземпляр базы данных Azure для MySQL. После создания экземпляра они могут выполнить миграцию базы данных одним из двух способов.

  • Шаг 4a. Azure Database Migration Service
  • Шаг 4b. Резервное копирование и восстановление MySQL Workbench

Шаг 4a. Перенос базы данных с помощью Azure Database Migration Service

Администраторы Contoso переносят базу данных, используя Azure Database Migration Service и следуя пошаговому руководству по миграции. Они могут выполнять миграции по сети, автономные и гибридные (доступные в виде предварительной версии) миграции с помощью MySQL 5.6 или 5.7.

Примечание

MySQL 8.0 поддерживается в базе данных Azure для MySQL, однако средство Database Migration Service еще не поддерживает эту версию.

Коротко говоря, специалисты Contoso выполняют следующие действия.

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

    • Версия исходного сервера базы данных MySQL должна соответствовать версии, которую поддерживает База данных Azure для MySQL. База данных Azure для MySQL поддерживает MySQL Community Edition, подсистему хранения InnoDB и миграцию между исходным и целевым серверами с одинаковой версией.

    • Они включают ведение двоичного журнала в my.ini (Windows) или my.cnf (Unix). Невозможность включить ведение двоичного журнала приведет к следующей ошибке в мастере миграции:

      Error in binary logging. Variable binlog_row_image has value 'minimal'. Please change it to 'full'.

      Дополнительные сведения см. в статье о параметрах и переменных ведения двоичного журнала в документации по MySQL.

    • Пользователь должен иметь роль ReplicationAdmin.

    • Перенести схемы базы данных без внешних ключей и триггеров.

  • Они создают виртуальную частную сеть, которая подключается к локальной сети через ExpressRoute или VPN-подключение.

  • Они создают экземпляр Azure Database Migration Service с номером SKU категории "Премиум", подключенным к виртуальной сети.

  • Они обеспечивают доступ Azure Database Migration Service к удаленному серверу MySQL через виртуальную сеть. Это позволяет убедиться, что все входящие порты разрешены из Azure в MySQL на уровне виртуальной сети, сети VPN и компьютера, на котором размещается MySQL.

  • Они запускают средство Database Migration Service, а затем выполняют следующие действия.

    1. Создание проекта миграции на основе номера SKU категории "Премиум".

      Снимок экрана: панель

      Снимок экрана: область нового проекта миграции MySQL.

    2. добавление источника (локальной базы данных);

      Снимок экрана: панель

    3. выбор целевого объекта;

      Снимок экрана: панель сведений о целевом объекте мастера миграции.

    4. Выберите базы данных для миграции.

      Снимок экрана: панель

    5. настройка расширенных параметров;

      Снимок экрана: панель параметров миграции мастера миграции.

    6. Запуск репликации и устранение всех ошибок.

      Снимок экрана: область сведений о сервере.

    7. выполнение окончательной прямой миграции.

      Снимок экрана: область сведений о osTicket.

      Снимок экрана: панель завершения прямой переключения.

      Снимок экрана: таблица состояния действий миграции.

    8. Возобновление использования внешних ключей и триггеров.

    9. Изменение приложений для использования новой базы данных.

      Снимок экрана: таблица действий миграции.

Шаг 4b. Перенос базы данных (MySQL Workbench).

  1. Специалисты компании Contoso проверяют предварительные условия и загружают MySQL Workbench.

  2. Специалисты компании устанавливают MySQL Workbench для Windows в соответствии с инструкциями по установке. Компьютер, на котором они устанавливают MySQL Workbench, должен быть доступен для виртуальной машины osticketmysql и Azure через Интернет.

  3. Они создают в среде MySQL Workbench подключение MySQL к osticketmysql.

    Снимок экрана: область сведений о подключении MySQL Workbench.

  4. Они экспортируют базу данных в виде osticket в автономный файл.

    Снимок экрана: область экспорта данных MySQL Workbench.

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

    Область Установка нового подключения для MySQL Workbench.

  6. Теперь специалисты компании могут импортировать (восстановить) базу данных в экземпляре Azure MySQL из автономного файла. Для экземпляра создается новая схема (osticket).

    Снимок экрана: область импорта данных MySQL Workbench.

  7. После восстановления данных администраторы могут выполнять к ним запросы с помощью MySQL Workbench. Данные отображаются на портале Azure.

    Снимок экрана: портал Azure с восстановленными данными.

    Снимок экрана: колонка баз данных MySQL со стрелкой, указывающей на базу данных osTicket.

  8. Администраторы обновляют сведения о базе данных в веб-приложениях. В экземпляре MySQL специалисты открывают Строки подключения.

    Снимок экрана: ссылка на строки подключения в экземпляре MySQL.

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

    Снимок экрана: параметры веб-приложения в экземпляре MySQL.

  10. Специалисты компании открывают новый файл в Блокноте, вставляют строку в него и изменяют его в соответствии с базой данных osTicket, экземпляром MySQL и параметрами учетных данных.

    Снимок экрана: строка подключения, вставленная в файл Блокнота.

  11. Специалисты компании могут проверить имя сервера и имя для входа в области Обзор в экземпляре MySQL на портале Azure.

    Снимок экрана: панель группы ресурсов с именем сервера и именем учетной записи администратора сервера.

Шаг 5. Настройка GitHub

Администраторы Contoso создают частный репозиторий GitHub и настраивают подключение к базе данных osTicket в Базе данных Azure для MySQL. Затем они загружают веб-приложение в Службу приложений Azure.

  1. Специалисты используют общедоступный репозиторий GitHub программного обеспечения osTicket и создают ветвь для учетной записи Contoso GitHub.

    Снимок экрана: страница репозитория GitHub с выделенной кнопкой

  2. После создания вилки репозитория специалисты переходят в папку include и выбирают файл ost-config.php.

    Снимок экрана: PHP-файл в GitHub.

  3. Специалисты компании изменяют этот файл, когда он открывается в браузере.

    Снимок экрана: значок редактирования файла (карандаша) в GitHub.

  4. В текстовом редакторе специалисты обновляют сведения о базе данных, в частности DBHOST и DBUSER.

    Снимок экрана: область редактирования файлов в GitHub.

  5. Они применяют изменения.

    Снимок экрана: кнопка

  6. Для каждого веб-приложения (osticket-eus2 и osticket-cus) на портале Azure специалисты выбирают Параметры приложения на левой панели, а затем изменяют параметры.

    Снимок экрана: ссылка на параметры приложения в портал Azure.

  7. Специалисты вводят строку подключения с именем osticket и копируют строку из блокнота в область значения. Они выбирают MySQL в раскрывающемся списке рядом со строкой и сохраняют параметры.

    Снимок экрана: панель

Шаг 6. Настройка веб-приложений

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

  1. В основном веб-приложении (osticket-eus2) они открывают раздел Вариант развертывания и устанавливают источник GitHub.

    Снимок экрана: панель параметров развертывания с выбранным GitHub в качестве источника.

  2. Специалисты компании выбирают варианты развертывания.

    Снимок экрана: сведения о параметре на панели параметров развертывания.

  3. После настройки параметров конфигурация имеет состояние ожидания на портале Azure.

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

  4. После обновления конфигурации веб-приложение osTicket загружается из GitHub в контейнер Docker под управлением Службы приложений Azure, а сайт отображается как активный.

    Снимок экрана: область параметров развертывания.

  5. Затем специалисты повторяют описанные выше действия для дополнительного веб-приложения (osticket-cus).

  6. После настройки сайт становится доступным через профиль диспетчера трафика. DNS-имя — новое расположение приложения osTicket. Подробнее.

    Снимок экрана: панель профиля диспетчера трафика с DNS-именем.

  7. Компании Contoso необходимо DNS-имя, которое легко запомнить. На панели Запись нового ресурса они создают псевдоним, CNAME и полное доменное имя osticket.contoso.com, которое указывает на имя Диспетчера трафика в DNS на контроллерах домена.

    Снимок экрана: панель

  8. Специалисты настраивают веб-приложения osticket-eus2 и osticket-cus, чтобы разрешить пользовательские имена узлов.

    Снимок экрана: панель

Настройка автомасштабирования

Наконец, администраторы Contoso настраивают для приложения автоматическое масштабирование. Автомасштабирование гарантирует, что количество экземпляров приложения будет соответствовать потребностям бизнеса.

  1. В службе приложений APP-SVP-EUS2 специалисты открывают раздел единицы масштабирования.

  2. Они настраивают новый параметр автомасштабирования с одним правилом, увеличивающим количество экземпляров на один, когда процент использования ЦП для текущего экземпляра превышает 70 % в течение 10 минут.

    Снимок экрана: страница параметров автомасштабирования для первого региона.

  3. Они настраивают тот же параметр в APP-SVP-CUS, чтобы убедиться, что применяется такое же поведение, если приложение выполняет отработку отказа в дополнительный регион. Единственная разница состоит в том, что они ограничивают количество экземпляров по умолчанию до 1, так как это необходимо только для отработки отказа.

    Снимок экрана: страница параметров автомасштабирования для второго региона.

Очистка после миграции

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

Для очистки после миграции специалисты компании Contoso выполняют следующие действия.

  • Удаляют виртуальную машину VMware из перечня в vCenter.
  • Удаление локальных виртуальных машин из локальных заданий резервного копирования.
  • Обновляют внутренние документы и указывают в них новые расположения и IP-адреса.
  • Проверяют все ресурсы, взаимодействующие с локальными виртуальными машинами, и обновляют все соответствующие параметры или документы согласно новой конфигурации.
  • Они повторно настраивают мониторинг для указания на URL-адрес osticket.trafficmanager.net с целью отслеживания работоспособности приложения.

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

Теперь, когда приложение работает, компании Contoso необходимо подготовить его к эксплуатации и защитить новую инфраструктуру.

Безопасность

Специалисты по безопасности компании Contoso проверяют приложение, чтобы выявить любые проблемы безопасности. Они определяют, что обмен данными между приложением osTicket и экземпляром базы данных MySQL не настроен для использования протокола SSL. Они делают все это, чтобы предотвратить взлом трафика базы данных. Подробнее.

Резервные копии

  • Веб-приложения osTicket не содержат данные о состоянии, и поэтому для них не нужно создавать резервные копии.
  • Команде Contoso нет необходимости настраивать резервное копирование для базы данных. В службе "База данных Azure для MySQL" для сервера автоматически создаются резервные копии. Команда решила использовать для базы данных геоизбыточное хранилище, поэтому она отказоустойчива и готова к внедрению в рабочую среду. Резервные копии можно использовать для восстановления сервера до точки во времени. Подробнее.

Лицензирование и оптимизация затрат