Как мы силами команды РСХБ построили свое облако
Привет, %Username%! Меня зовут Михаил Слотин, я главный архитектор в РСХБ-Интех (технологическая дочка Россельхозбанка) и один из создателей Частного Облака (ЧО) РСХБ. Сегодня расскажу вам, как мы работали над ЧО, почему потребовалось создавать новое решение вместо покупки готового и как мы сделали больше, чем планировали. Особо полезна, на мой взгляд, статья будет архитекторам и ИТ-менеджерам. Надеюсь, она поможет определиться, начать свою разработку или нет.
В РСХБ-Интех я пришел конкретно на проект по созданию ЧО в конце декабря 2021 года и сразу же приступил к поискам существующих на российском рынке альтернатив, потому как импортозамещение уже громко звучало из всех уст.
Были интересные решения, в большей части базирующиеся на базе OpenStack. Некоторые пошли дальше простого переклеивания шильдика и банального перевода на русский. Но все равно имеющихся тогда продуктов было недостаточно для решения задачи и перехода на другую платформу, в том числе виртуализации. Транзит на неподходящую платформу кроме затрат на лицензии грозил еще и затратами на оборудование.
Изыскания проводились вместе с моим коллегой, работающим в проекте по VDI. Он подсказал, что слышал, что Джет ведет проект с другим заказчиком по ManageIQ, после чего я решил познакомиться с прекрасными людьми из этой компании. Серега (@haisenberg), привет!
Заканчивая наши поиски (которые, по большому счету, были однотипными, в основном ванильный OpenStack) и параллельно создавая стенд для ManageIQ, за 3 месяца мы сделали MVP на 3 базовые услуги с интеграцией только с AD. Еще через 4 месяца мы скрестили ЧО со всеми необходимыми системами и запустились в продакшен, попутно подняв IPAM, которого в компании не было. И в последние 2 месяца до выхода в продакшн к нам пришла прекрасная разработчица Аня (@Nicky-DT), и мы сделали первую версию портала самообслуживания. Аня, к нашему сожалению, уже покинула компанию. Но она внесла большой вклад и не оценить это невозможно. На ее место пришел новый сильный сотрудник, и он очень нас радует.
Эти 7 месяцев были очень насыщенными, и мысли, что работа в Банке сродни «пенсии», растаяли. Не то чтобы я этого искал, но не думал, что будет настолько динамично. Куча интервью, куча документации, ТЗ на 60 страниц только в части услуг, огромное количество проработки всех сценариев использования с коллегами, согласование с ИБ наших инсталляций и автоматизация-автоматизация-автоматизация. Все ради удобства пользователей — разработчиков и тестировщиков продуктов для РСХБ и дочерних организаций. Тут еще хочется поблагодарить наших первых клиентов команду App.Farm (банковская среда РСХБ, следующая концепции PaaS. Здесь происходят процессы тестирования и доработки решений перед выпуском в продакшен) и, в частности, Костю (@Quadexx). Они мотивируют нас на дальнейшую разработку. Многих ещё хотелось бы поблагодарить, но всех не перечислить. Надеюсь, никто не обидится, но, если вы это читаете — спасибо!
Было-стало
Еще чуть-чуть душноты и перейдем к технике.
На слайде выше опущен процесс предоставления доступа к созданному серверу, но не специально. Процесс предоставления доступов происходит в системе электронного документооборота и занимает примерно неделю. В случае с ЧО через 33 минуты после нажатия на кнопку «Создать» пользователь получает полностью сконфигурированный по стандартам банка сервер с доступами, готовый к работе.
Архитектура и потоки
Две идентичные инсталляции: одна под разработку и тестирование, а вторая продуктивная. Для разработки и тестирования нам выделены 2 кластера на платформах виртуализации VMware и HostVM (oVirt-based решение).
На схеме ниже представлена первая инсталляция со всеми интеграциями, нарисованная на скорую руку. Наша система была заведена как низко-критичная и пока у нас не реализована балансировка на всех уровнях, но задел под это частично заложен и на всех слоях.
Аутентификация пользователей происходит в двух доменах и реализована посредством SSSD. У нас была попытка скрестить ManageIQ с Keycloak, но из-за нехватки времени ушли на классическую схему с AD. Хотя мы планируем продолжить наши изысканиям.
А вот как выглядит процесс создание сервера. Ранее я уже писал, что сервер настраивается по стандартам банка, это происходит двумя системами, встроенным в ManageIQ: Ansible в случае, если это Windows, и AWX если Linux. У нас много планов по оптимизации этого процесса, но мало рук.
Портал
В какой-то момент мы с коллегой Дмитрием (@bel1k0v) поняли, что порталы ManageIQ не отвечают нашим внутренним требованиям, и Дмитрий перешел на разработку внутреннего портала. Для этого был взят Laravel в качестве серверного фреймворка и Vue.js для клиента, что позволило в короткий срок получить MVP. Также для разработки использовались: Docker, Nginx + PHP-FPM, Redis, Postgre Pro, Astra Linux.
Портал является единой точкой входа для клиентов пользовательского интерфейса и, мы уже почти приготовили полноценный API для IaC, описав API в Swagger. На портале реализован механизм статусов виртуальных машин, обработка заявок и обновление данных в фоне, журнал действий пользователя и интеграция с IPAM. В будущем планируется расширение функциональности портала, с увеличением количества доступных сервисов.
Здесь уже будут скрины второй версии пользовательского интерфейса. Как я уже писал, первая версия писалась за 2 месяца. За очень простым интерфейсом скрыта куча логики и валидаций. В ManageIQ помимо квот хранится куча meta-атрибутов на разных уровнях, часть на уровне tenant (tenant и его мета-атрибуты — это Ресурсный пул, далее РП), часть на уровне VM.
Мы отслеживаем статусы в процессе создания, удаления, выключения и перезагрузок. Сравниваем занесенный в мета-атрибуты сервера IP с фактическим значением из VMTools (по факту вся эта информация хранится в ManageIQ).
Создание виртуальной машины
У нас реализована настройка над РП в части нэйминга, он может быть стандартным или кастомным. Стандартный нейминг складывается из мета-атрибутов РП, а кастомный — свободный. В поле имени сервера происходит валидация на существование имен в IPAM (Netbox), для нас это source of truth (источник истины).
Сетей может быть несколько для одного РП поэтому мы даем ее выбирать. Как и свободные IP адреса, они также загружаются из IPAM. Выбор ОС это по факту выбор шаблона, которые автоматом появляются, когда в ManageIQ заносится новый.
С CPU и RAM думаю понятно, и пояснений не требуется. Кроме того, мы валидируем максимальные возможные значения этих параметров для РП в части квот, и существует верхнеуровневый лимит, как требование от команды виртуализации.
Последним пунктом выбирается домен в который будет включен сервер как Windows, так и Linux. На стенде разработки у нас сейчас имплементируется добавление дисков на этапе создания сервера. В ближайшее время готовим запуск новой услуги — создание сервера с настроенной БД (конечно же Postgres Pro).
Изменение виртуальной машины
На форме также есть валидация в зависимости от доступной квоты. Так как для данной машины включен Hot-add (изменение параметров «на горячую»), портал знает, какой лимит есть на системе виртуализации для изменения параметра по RAM.
Другие интерфейсы
У нас реализована ролевая модель, и помимо интерфейса Администраторов РП (скрины выше) есть Администраторы Квот, где они могут создают РП и управляют квотами существующих. Также мы реализовали отображение верхнеуровневой квоты, в зависимости от количества и конфигураций гипервизоров и валидируем создание РП в части количества ресурсов выделенных для ЧО.
В интерфейсе Администраторов ИБ доступен просмотр действий пользователей, в том числе IP-адреса, с которых пользователи к нам пришли. К сожалению, недельные поиски в ManageIQ нам не помогли, и Дмитрий создал свой функционал, но уже на нашем портале.
API
Мы валидируем значения не только на фронте, но теперь и на бэке. За последние несколько недель переработали основные функции, упростив взаимодействие с API.
Проблемы с которыми столкнулись
Первая и основная проблема — это нехватка людей в команде разработки и эксплуатации. Но этот момент, надеюсь, в скором времени решится.
Вторая, это то, что когда мы приходим к коллегам и предлагаем им перенести рабочие процессы в облако, то порой сталкиваемся с непониманием и сопротивлением. Коллеги не верят, что это будет удобно. Приходится проводить презентации и только после этого у людей загораются глаза. Надеюсь эта статья и то, что мы опубликуем ее расширенную версию с ответами на частые вопросы, сильно поможет нам.
Что мы получили в итоге
Подводя итоги, я расскажу, что нам удалось получить и до каких выводов мы дошли в процессе разработки.
Своя разработка дешевле, чем лицензии и поддержка от вендора, но только при условии, что аналогов с такой гибкостью и функционалом нет. В своем продукте можно имплементировать, что угодно, что мы активно и делаем. У нас четкий Roadmap, базирующийся на наиболее частых операциях пользователей, и шаг за шагом мы автоматизируем наиболее востребованные операции.
Пресловутый T2M.
Наши «клиенты» (внутренние сотрудники банка из различных подразделений) теперь не ждут серверы с доступами по 2 недели, изменение конфигурации происходит за минуты, а не дни, так же как перезагрузки не часы, а секунды.
Если остались вопросы и вы еще не побежали разрабатывать свое облако — с удовольствием ответим. ;)
