В большой компании часто очень тяжело согласовывать выделение ресурсов под рабочие задачи. Весь Agile с хрустом разбивается о стену трёхнедельного согласования с ИБ новой инфраструктуры. Поэтому к нам часто приходят запросы на перевод инфраструктуры на контейнеры, чтобы выкатывать изменения не раз в три месяца, а когда нужно бизнесу. Просят при этом настроить/внедрить Kubernetes как самый популярный инструмент оркестрации, хотя, как показывает практика, из 10 проектов он нужен максимум в трёх. А по факту стоит или использовать не Kubernetes, а OpenShift, или работать с ним не в своей инфраструктуре, а в публичном облаке, например. Я попробую рассказать про реальные бизнес-кейсы, которые мы решали, опишу основные различия между Kubernetes и OpenShift. А ещё о том, как мы согласование ИБ до 30 минут урезали, и все остались живы.

У нас было несколько интересных внедрений, в которых мы разгребали накопившиеся проблемы заказчика. Например, к нам пришла розничная компания, которой надо было выкатывать новые фишки непрерывно. Конкуренция дикая! А у них только инфраструктура под разработку каждый раз готовится от шести до десяти дней, из-за чего возникают простои. Решать вопрос с помощью закупки нового железа для тестирования и разработки — дорого и путь в никуда. В итоге мы перевели ИТ-инфраструктуру на контейнерную виртуализацию. В результате благодаря контейнерам нагрузка сократилась на 40 %, а инфраструктура под новую разработку теперь готовится от одного до четырёх часов. Бонус — экономия, так как все процессы можно было продолжать вести на базе имеющихся мощностей без покупки новых.

Что будем делать с ИБ?

ИБ — очень нужные люди. Они часто немного перегибают палку в своих внутренних требованиях к проектам, но это намного лучше, чем однажды увидеть, что ваш внешний SFTP-сервер обнесли румынские хакеры.

Но с ними есть проблема. Если мы рассматриваем бизнес-процесс как конвейер, то их подразделение часто становится тем самым bottleneck’ом, в который упираются все остальные. Они, с одной стороны, отвечают за все риски, связанные с безопасностью, с другой — просто физически не успевают просматривать вручную код и все детали архитектуры нового продукта.

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

В нашем контексте такими автоматизированными системами становятся правильно организованные процессы CI/CD с анализаторами кода на промежуточных этапах, такие решения, как JFrog Xray для Artifactory, и правильно закрученные гайки Kubernetes/OpenShift, не допускающие небезопасных подходов вроде запуска контейнера от пользователя root. Сейчас мы готовим коробочное решение, которое будет всё это обеспечивать.

Целевая задача — перейти от концепции «не уйдёт в прод, пока не досмотрим» к «если не будет возражений — деплоится автоматом». Нет никакого смысла в автоматизации, если организационные процессы останутся прежними.

В одном из проектов нам удалось сократить время на отказ ИБ до 30 минут. Иными словами, если в течение получаса «безопасник» не отклоняет действие, то оно согласуется автоматом, и изменения раскатываются в продакшен. Сейчас мы пытаемся добиться сроков в 60 минут вообще для всех согласующих в проекте без снижения безопасности.

В чём разница систем управления контейнерами?

Kubernetes и OpenShift — основные решения для оркестрации контейнеров. Разберём основные отличия и преимущества для бизнеса.

Открытость

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

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

Тут выбор зависит от того, что вам больше подходит, — поддержка силами своих специалистов или вендора.

Платформы

Kubernetes работает практически на любой Linux-платформе и большинстве облачных провайдеров.

OpenShift не работает нигде, кроме как на RHEL, Red Hat Atomic, Red Hat CoreOS. Есть community-версия — OKD, но она жёстко привязана к дистрибутивам. Единственное исключение — её можно установить на CentOS. И учтите, что официально Red Hat не гарантирует платной поддержки.

Политики безопасности

OpenShift из коробки имеет более жёсткие настройки безопасности. Это плюс при развёртывании инфраструктуры с нуля, но может быть проблемой из-за несовместимости некоторых образов с политиками. Например, в OpenShift запрещён запуск контейнера от root, что ломает совместимость со старыми образами. С другой стороны, подобный подход в сочетании с удобной интеграцией с AD, удобным логгированием на базе EFK-стека (ElasticSearch, Fluentd, Kibana) даёт нам ту самую безопасность из коробки, которая нужна для разгрузки подразделения ИБ.

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

Шаблоны

OpenShift templates менее гибкие, чем Kubernetes Helm charts. На данный момент из-за более жёстких политик к безопасности продукт Red Hat не может обеспечить такой гибкости, как Helm charts. Тем не менее в OpenShift 4 ситуация выровнялась благодаря интегрированному OperatorHub.

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

Одна условная команда «helm install prometheus-operator» развёртывает довольно сложную систему, которую очень долго деплоить самому. В этом Kubernetes пока лидирует.

Общие выводы

Как и большинство продуктов, Red Hat OpenShift — более коробочное, но архитектурно более жёсткое решение. Он требует менее красноглазого и более опытного персонала для работы. Более удобные сценарии развёртывания, отличная интеграция с CI/CD-решениями, в частности, с Jenkins. OpenShift отлично подходит компаниям, которым проще заплатить за поддержку готового продукта, чем нанимать своих специалистов.

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

Реальные кейсы

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

Кейс: электронная коммерция

Проблема

У заказчика было более 100 активных сервисов под управлением cloud foundation от VMware. И у всего этого парка было несколько разных проблем:

1. 12 требовательных к ресурсам и немаржинальных сервисов крутились на VMware, съедая бюджет: примерно $ 408 000 в год.
2. Три сервиса (портал и два мобильных приложения) начали активно развиваться: за семь месяцев объём необходимых для работы ресурсов увеличился в 4,5 раза и продолжает расти.
3. Несколько сервисов заказчика имеют пики нагрузок, во время которых ресурсов необходимо в шесть-семь раз больше, чем в обычное время. Соответственно для их корректной работы выделено оборудование, которое большую часть времени утилизировано менее чем на 15 %.

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

Наше решение

Первое и самое простое решение: сервисы с пиками перевозим в публичное облако КРОК. С биллингом по потребляемым ресурсам. Тут всё максимально просто и скучно. Переезд с чьего-то VMware на наш KVM — один из самых частых кейсов для инженеров облака.

Так как железо под масштабирование уже было закуплено заказчиком, нам оставалось только посчитать лицензии. Под новые хосты от VMware стоили порядка $ 2 100 000, что не очень устраивало заказчика. Мы предложили перевести часть сервисов на KVM под управлением OpenStack. А чтобы не теряться, объединить CloudForms’ом управление обеими инфраструктурами (и заодно OpenShift’ом).

В итоге заказчик получил второе плечо частного облака на базе OpenStack, чем закрыл вопрос vendorlock’а. Перевезя на новое плечо часть ресурсоёмких сервисов, получилось снизить затраты на лицензии VMware (поддержка 24 x 7 от КРОК оказалась дешевле).

Кейс: розничная торговля

Проблема

При аудите оказалось, что в вопросе выделения инфраструктуры у заказчика творится что-то ужасное. Проектов — больше 250, команд разработки — больше 150, половина — контейнеры на Kubernetes. Ресурсы под каждый новый проект закупаются и остаются закреплёнными за ним без возможности отобрать, даже если они не используются. Биллинга нет вообще, отсутствует единый портал. Огромные затраты на тестовую и предпрод-среды, так как тоже крутятся на VMware.

При этом полностью переходить на новую платформу заказчик не желает и хочет собрать всё под единым порталом управления. Причём «всё» — это не только VMware, но и вдобавок PaaS, контейнеры и единый биллинг.

Наше решение

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

Каталог, в котором пользователь выбирает параметры виртуалки и необходимый контур: DevTest, PreProd, Prod. А дальше CloudForms сам выбирает, где запрашиваемый ресурс развернуть: на VMware или на OpenShift. Над единым биллингом мы пока работаем, так как гибридное решение VMware + OpenShift довольно сложно собрать воедино.

По сути, таким способом мы навели порядок в инфраструктуре, разобрав завалы, которые нагородил заказчик.

Кейс: промышленность

Проблема

Копирование ВМ в различные среды (Test, Dev, Prod, Preprod) занимает больше трёх дней и требует ручного выполнения 15 различных операций, каждая из которых занимает до 30 минут. Более глубокий аудит показал, что ранее на выделение ресурсов под новый проект уходило две недели, а запросов было 10–20 в месяц. Сейчас запросов на выделение ресурсов больше десяти в день, что без автоматизации приводило к коллапсу.

Наше решение

По факту заказчику было необходимо перевести IT-инфраструктуру на сервисную модель, перестроить и автоматизировать процесс внесения изменений в инфраструктуру, создать портал самообслуживания, наполнить его каталогом сервисов и внедрить среду для управления контейнеризированными приложениями. Мы автоматизировали процесс копирования ВМ, но он всё равно занимал много времени: 40–60 минут, это не устраивало заказчика. В итоге мы предложили перейти на контейнеры, что сократило время на копирование до трёх–пяти минут.

Выводы

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

• Код становится чище: линтеры, анализаторы кода, автоматизированное тестирование.
• Код и архитектура становятся безопаснее: инструменты для ИБ с широкими возможностями вплоть до автоматической блокировки деплоя небезопасного кода.
• Сервисы становятся более гибкими и мобильными: циклы разработки теперь предельно короткие и быстро реагируют на изменения.
• Автоматическое масштабирование под нагрузки: ваш ресурс больше не проседает в час пик, упуская продажи и клиентов.
• Простое выделение ресурсов под новые проекты, снижение временных затрат на согласование.
• Зачастую контейнеризация позволяет значительно сократить time-to-market.

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