Как контейнеризовать устаревшее приложение

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

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

1. Определите системы-кандидаты

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

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

2. Компонентизируйте систему

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

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

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

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

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

3. Подготовьте компоненты

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

Постоянного хранения

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

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

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

Управление конфигурацией

Многие устаревшие приложения настраиваются с использованием статических файлов конфигурации. Они могут быть в специальном формате, таком как XML, JSON или INI, или закодированы с использованием языка программирования системы.

Контейнеры обычно настраиваются внешними переменными среды. Переменные определяются при создании контейнеров с использованием таких механизмов, как флаг Docker -e с docker run. Они внедряются в среду работающего контейнера.

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

Ссылки между сервисами

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

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

4. Напишите свои файлы Docker

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

Файлы Docker начинаются с соответствующего базового образа, на который ссылается оператор FROM. Обычно это операционная система (ubuntu:20.04, alpine:3) или предварительно созданная среда языка программирования (php:8, <узел:16). Вы можете выбрать образ, который лучше всего соответствует существующей среде вашего приложения. Запуск с пустой файловой системы возможен, но обычно не требуется, если только вам не требуется чрезвычайно детальный контроль.

Дополнительный контент накладывается на базовое изображение с помощью таких инструкций, как COPY и RUN. Они позволяют копировать файлы с вашего хоста и запускать команды во временной файловой системе сборки. После того, как вы написали свой Dockerfile, вы можете собрать его с помощью команды docker build -t my-image:latest ..

5. Настройте оркестровку

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

Для этой цели в более крупных производственных установках обычно используется Kubernetes. Это специальная система оркестрации, которая добавляет свои собственные концепции более высокого уровня для создания реплицированных контейнерных развертываний. Небольшие системы и среды разработки часто хорошо обслуживаются Docker Compose, инструментом, который использует более простые файлы YAML для запуска «стека» из нескольких контейнеров:

version: "3"

app:
  image: my-web-app:latest
  ports:
    - 80:80
database:
  image: mysql:8.0
  ports:
    - 3306:3306

docker-compose up -d