Docker: контейнеризация старых приложений

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

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

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

Контейнеризация или упаковка старого приложения в контейнер может также добавить столь необходимую в настоящее время скорость и гибкость для такого приложения.

Если вы решили упаковать ваше унаследованное приложение, существуют два основных подхода, которые можно использовать: «чистый» и"грязный". Давайте сначала обсудим чистую стратегию, прежде чем поговорить о грязном подходе.

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

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

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

• Разбиение приложения по функциям или модулям. Если в вашем приложении уже четко определенны наборы функций или явно выделены определенные модули, например, «работа с корзиной покупателя», вы можете использовать их в качестве основы для рефакторинга. Каждый микросервис может состоять из отдельной функций или их тесно связанных групп (или модулей).
• Разбиение приложения по ресурсам. Каждый микросервис может быть определен на основе конкретного ресурса, за который он ответственен в конечном приложении, например, микросервис доступа к базе данных, микросервис, занимающийся передачей сообщений между отдельными приложениями, микросервис, взаимодействующий с периферийными устройствами. и т.д.
• Разбиение приложения по границам существующих компонентов. Этот путь может быть полезен, когда в архитектуре унаследованного приложения существуют определенные компоненты с явными границами между собой, а данные между этими компонентами перемещаются по ограниченному количеству каналов.

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

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

«Грязный» подход к упаковке устаревшего приложения состоит в основном в том, чтобы взять это приложение целиком и поместить его в контейнер. Приложение, упакованное таким образом может использовать лишь некоторые функции контейнеров (т.к. сетевые и системные ресурсы). Однако, без полного редизайна ваше приложение не будет являться микросервисным.

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

Само собой, какой именно способ упаковки устаревших приложениями использовать («чистый» или «грязный»), не всегда может быть очевидно. Иногда легче реорганизовывать приложение частично, т.е. постепенно перемещать некоторые функции из приложения в отдельные микросервисы, держа основное приложение в отдельном контейнере. Когда контейнеризация происходит именно таким образом, промежуточный результат точно не будет элегантным с точки зрения стандартов контейнеризации или микросервисной архитектуры, но тем не менее позволит вам существенно оптимизировать во времени затраты на рефакторинг вашего приложения.

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

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

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