Поэтапное преобразование виртуализованных нагрузок в контейнеры OpenShift

Унаследованные приложения, как правило, имеют монолитную архитектуру и запускаются на одной или нескольких виртуальных машинах. Некоторые из таких систем легче поддаются модернизации, поскольку в мире контейнеров для них есть неплохие аналоги (EAP, Spring Boot и т.д.). Однако большие классические приложения на .Net, работающие под IIS на Windows-сервере, модернизировать гораздо сложнее, тем более за одну итерацию. Но благодаря OpenShift Virtualization такие ВМ-нагрузки можно импортировать в OpenShift как есть и затем контейнеризировать их поэтапно.

В OpenShift виртуальные машины являются привилегированными гражданами и имеют ровно те же возможности, что и pod’ы, включая обращение к другим объектам и предоставление доступа к себе через конечные точки служб (service endpoints). Поэтому выполнив первичный перенос ВМ-приложения в OpenShift, его затем можно поэтапно модернизировать, а заодно и расширять функционал.

Стратегия миграции Shift and Modernize

Чтобы показать, как это делается, мы для примера возьмем приложение .Net, работающее под IIS на виртуалке Windows Server, импортируем его в OpenShift Virtualization, а затем поэтапно контейнеризуем все его логические слои. Обратите внимание, что стратегия «shift and modernize» подходит и для других связок «операционная система–связующее ПО».

Этап 1. Импорт ВМ в OpenShift Virtualization

Импорт ВМ в OpenShift возможен несколькими способами. Для виртуальных машин VMware можно использовать встроенный инструментарий миграции, который позволяет подключиться к экземпляру VSphere и напрямую импортировать эти виртуалки в OpenShift Virtualization. Для других платформ виртуализации, включая Hyper-V и Xen, можно использовать virt-v2v, чтобы конвертировать образ ВМ в формат, поддерживаемый OpenShift Virtualization, а затем импортировать этот образ, используя методы описанные здесь (EN).

Виртуальная машина запускается с помощью Yaml-конфигурации, базовый вариант которой можно найти здесь. Этот Yaml-файл содержит определение ВМ, а также объектов service и route, плюс, некоторые функциональные конфигурации для более эффективной работы Windows-ВМ на платформе OpenShift Virtualization.

Нас интересует следующее секция:

        features:           acpi: {}           apic: {}           hyperv:             reenlightenment: {}             ipi: {}             synic: {}             synictimer: {}             spinlocks:               spinlocks: 8191             reset: {}             relaxed: {}             vpindex: {}             runtime: {}             tlbflush: {}             frequencies: {}             vapic: {}             evmcs: {} # do not use evmcs if testing with nested virt

После применения этого yaml, мы получаем доступ к графическому интерфейсу Windows UI через VNC Console, которую нам дает OpenShift Virtualization.

Кроме того, теперь у нас есть доступ к приложению через exposed route.

Этап 2. Контейнеризация UI приложения

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

И поскольку это можно делать поэтапно, мы начнем с веб-интерфейса и после того, как переведем UI-слой на .Net Core, упакуем его в контейнерный образ для OpenShift. Этот новый UI-pod будет потреблять API, которые предоставляются «старым» сайтом, работающем под IIS на виртуальной машине.

Приведенный ниже Dockerfile компилирует ваш код .Net Core и создает runtime-образ. Это также можно сделать через сборки S2I.

# https://hub.docker.com/_/microsoft-dotnet-core FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build WORKDIR /source  # copy csproj and restore as distinct layers COPY ./source . RUN dotnet restore  # copy and publish app and libraries COPY . . RUN dotnet publish -c release -o /app --no-restore  # final stage/image FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 WORKDIR /app COPY --from=build /app . ENTRYPOINT ["dotnet", "ClientListUI.dll"]

Для сборки и отправки этого образа в реестр можно использовать podman. Затем остается только развернуть этот отвечающий за веб-интерфейс pod вместе с виртуальной машиной приложения.

Этап 3. Контейнеризация API

Вслед за UI-слоем мигрируем на .Net Core слой API и развернем его в виде отдельного pod’а. После чего на исходной виртуалке остается только база данных SQL Server. Соответствующим образом поправим сервис ВМ в части описания доступа:

kind: Service apiVersion: v1 metadata:   name: stage3-win2019-db-vm   namespace: stage3   labels:     kubevirt.io: virt-launcher     kubevirt.io/domain: stage3-win2019-iis-vm spec:    ports:     - protocol: TCP       port: 1433       targetPort: 1433   selector:     kubevirt.io: virt-launcher     kubevirt.io/domain: stage3-win2019-iis-vm

Итак, теперь UI-pod нашего приложения вызывает API через service URL нашего API-pod’а, а тот в свою очередь использует service URL нашей виртуальной машины, чтобы делать запросы к базе данных.

Этап 4. Контейнеризация БД

Да, вы правильно поняли: миграция экземпляра MS SQL в контейнер RHEL. Лет пять назад такое и в голову бы никому не пришло, но сегодня это вполне рабочий вариант и подробнее узнать о том, как настроить и запустить MS SQL в контейнере, можно узнать здесь (EN).

После того, SQL-pod будет готов, остается настроить port forwarding, чтобы можно было работать с БД через MS SQL Management Studio или Azure Data Studio:

└──╼ oc get pod | grep sql | grep Running sql2019-1-1-gp29h         1/1     Running     0          39h  └──╼ oc port-forward sql2019-1-1-gp29h 1433:1433 Forwarding from 127.0.0.1:1433 -> 1433 Forwarding from [::1]:1433 -> 1433 Handling connection for 1433

Теперь можно переносить БД из экземпляра MS SQL на Windows-виртуалке в контейнер SQL Server. После чего, необходимо изменить строку подключения для API-pod’а приложения и указать в ней pod, где теперь живет ваш MS SQL.

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

Заключение

Поэтапная миграция ВМ-нагрузки по методу «shift and modernize» позволяет снизить технический долг, минимизировать любого рода регрессии, которые могут возникнуть входе этого процесса, ну и попутно расширить функционал приложения в рамках проводимой при такой миграции доработки кода.