Контейнеризация монолитных приложений

Может потребоваться создать одно монолитное веб-приложение или службу и развернуть его в виде контейнера. Само приложение может быть не внутренне монолитным, но структурировано как несколько библиотек, компонентов или даже слоев (уровень приложений, уровень домена, уровень доступа к данным и т. д.). Однако внешне это один контейнер — один процесс, одно веб-приложение или одна служба.

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

Рис. 4-1. Пример архитектуры контейнерного монолитного приложения

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

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

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

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

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

С точки зрения инфраструктуры каждый сервер может запускать множество приложений в одном узле и иметь приемлемое соотношение эффективности использования ресурсов, как показано на рис. 4-2.

Рис. 4-2. Монолитный подход: размещение нескольких приложений, каждое приложение, работающее в качестве контейнера

Монолитные приложения в Microsoft Azure можно развертывать с помощью выделенных виртуальных машин для каждого экземпляра. Кроме того, с помощью масштабируемых наборов виртуальных машин Azure можно легко масштабировать виртуальные машины. Служба приложений Azure также может запускать монолитные приложения и легко масштабировать экземпляры без необходимости управлять виртуальными машинами. С 2016 года службы приложений Azure также могут запускать отдельные экземпляры контейнеров Docker, упрощая развертывание.

В качестве среды качества обслуживания или ограниченной рабочей среды можно развернуть несколько виртуальных машин узла Docker и сбалансировать их с помощью балансировщика Azure, как показано на рис. 4-3. Это позволяет управлять масштабированием с помощью грубого подхода, так как все приложение живет в одном контейнере.

Рис. 4-3. Пример масштабирования одного контейнерного приложения на нескольких хостах

Развертывание на различные узлы может осуществляться традиционными методами. Узлы Docker можно управлять с помощью таких команд, как docker run или docker-compose вручную, или с помощью автоматизации, таких как конвейеры непрерывной доставки (CD).

Развертывание монолитного приложения в контейнере

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

Развертывание обновлений в виде образов Docker гораздо быстрее и эффективнее с точки зрения сети. Образы Docker обычно запускаются за секунды, что увеличивает скорость развертывания процесса. Удаление экземпляра образа Docker так же просто, как выполнение команды docker stop, и обычно занимает менее секунды.

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

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

Публикация одноконтейнерного приложения в Службе приложений Azure

Независимо от того, хотите ли вы получить проверку контейнера, развернутого в Azure или когда приложение является просто одноконтейнерным приложением, служба приложений Azure предоставляет отличный способ предоставления масштабируемых одноконтейнерных служб. Использование службы приложений Azure просто. Она обеспечивает отличную интеграцию с Git, чтобы упростить разработку кода, создать его в Visual Studio и развернуть его непосредственно в Azure.

Рис. 4-4. Публикация одноконтейнерного приложения в Службе приложений Azure из Visual Studio 2022

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

Поддержка контейнеров в Visual Studio 2017 и более поздних версиях позволяет включать все, что вы хотите в среде приложения, как показано на рис. 4-4. Так как он выполняется в контейнере, если вы добавляете зависимость в приложение, можно включить зависимость в образ Dockerfile или Docker.

Как показано на рис. 4-4, поток публикации отправляет образ через реестр контейнеров. Это может быть реестр контейнеров Azure (реестр, близкий к развертываниям в Azure и защищенный группами и учетными записями Azure Active Directory), или любой другой реестр Docker, например Docker Hub или локальный реестр.