Работа с изолированной инфраструктурой заказчика

Как все началось?

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

Все началось с того, что нам поступил от них запрос: объединить в один сайт существующие веб-площадки компании – основной сайт, который уже устарел, и сайт, отвечающий за множество процессов продаж. Был один нюанс: новая площадка должна была лежать в частной облачной платформе ВСК - Marlin.

Что это такое? 

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

Особенности закрытой среды

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

Некоторые проблемы принес тот факт, что инфраструктура заказчика оказалась закрытого типа, то есть для “высоких” окружений, типа stage или prod, доступ в Интернет сильно ограничен. Также ограничен доступ в Интернет и на агентах сборки docker-образов. Это стало причиной того, что некоторые процессы пришлось пересмотреть и адаптировать.

Задачи и их решение

- Настройка мирроринга. Это было первое, с чем мы столкнулись. По нашему воркфлоу разработка ведется в Azure DevOps (TFS) – платформе для управления версиями приложения и циклами его разработки. Но репозитории с кодом должны храниться в облаке заказчика, поэтому нам нужно было проинтегрировать данные из нашего TFS в GitLab заказчика - хранилище кода. Однако мы столкнулись с последствиями закрытости системы: было невозможно инициировать действий по зеркалированию со стороны TFS. То есть мы не могли переносить изменения в коде в GitLab, так как у нас не было прямого доступа к нему.

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

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

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

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

Выводы

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