16 января 2024

Кейсы

Как мы работаем с приватной облачной платформой заказчика

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

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

В чем разница между публичным и приватным облаком?

Основное отличие, конечно, в том, что частное облако – это инфраструктура, которая используется в рамках одной компании. А публичное облако – это решение, которое провайдер сдает «в аренду» сразу нескольким клиентам. Каждый из них создает виртуальные сервера и управляет ими. 

И у того, и у другого решения есть свои минусы и плюсы. 

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

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

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

Здесь мы хотим рассмотреть именно процесс работы с приватным облаком на стороне заказчика. Чтобы рассказать об этом подробнее, возьмем для примера облачное решение EPaaS S7. 

Что из себя представляет EPaaS? 

EPaaS (Enterprise Platform as a Service) это корпоративная облачная платформа S7. Она включает в себя полноценную среду для разработки и развертывания с набором сервисов для создания и контроля приложений. Можно сказать, что жизненный цикл приложения за редкими исключениями протекает именно там. 

Цели и задачи 

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

Изначально все приложения были расположены либо на Windows-серверах, либо в привычном для нас кластере Kubernetes. Отсюда вытекала наша первая основная задача – перенос всех приложений в EPaaS. 

Первый шаг переезд 

В 2019 году мы начали работу над переносом приложений. EPaaS была новой платформой как для нас, так и для заказчика, поэтому мы решили делать все постепенно: от более простых модулей до масштабных сервисов. Первыми мы начали перевозить модули S7 VSM. На них мы откатали весь процесс: хранение исходников на нашей стороне, автоматическую синхронизацию в GitLub, сборка на стороне заказчика и автоматическое развертывание.  

Переезд потребовал некоторых изменений в CI/CD, связанных с ограничениями и правилами Openshift. Например, ограничение на запуск контейнеров из-под привилегированного пользователя, правила для именования сервисов, подключение автоматически создаваемых TLS-сертификатов и т. д.  

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

Последующая работа 

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

1) В 2021 году мы провели масштабную работу – наши специалисты инфраструктурного подразделения перевели все продукты на новую версию кластера, где хранятся наши приложения. Это было связано с тем, что старый кластер работал на изрядно устаревшей версии Kubernetes 1.11, из-за чего возникали технические трудности. Плюс нам хотелось использовать свежие возможности новой версии.  

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

2) В декабре 2023 мы перенесли боевую базу данных еще одного продукта Sigma в хранилище в EPaaS. Это было необходимо, так как, во-первых, предыдущее решение не содержало в себе всех необходимых функций, во-вторых, это было одним из важных требований IT. 

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

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

3) Сейчас мы активно занимаемся переездом на новую версию Gitlab, которая интегрирована в EPaaS. В связи с этим возникает много “невидимой работы” - например, изначально на сборочных агентах Gitlab2 не было доступа в интернет, а прокси S7 для репозиториев не работал на нужной скорости и периодически отдавал ошибки на попытки скачать тот или иной пакет. В итоге после нескольких недель тестирования решили включить доступ в интернет. Из задач, которые решаются прямо сейчас - невозможность создать Access Token, нужный для мирроринга наших репозиториев, на срок более года.  

Помимо прочего, мы постоянно проверяем наши сервисы на соответствие best practices: следим, чтобы все пароли хранились в Vault (инструмент для хранения паролей), за правильным неймингом Docker-образов, настройкой мониторингов и т. д. 

Выводы 

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