Контейнеризация в enterprise: взгляд практика

Шкала зрелости использования контейнеров

Стадия 1: зарождение интереса

Контейнеры только появляются в компании. С ними имеют дело разработчики, а ИТ-эксплуатация понимает, что нужно развивать новые компетенции, поскольку уже скоро потребуется принимать системы и отвечать за SLA. При этом у эксплуатации отсутствует нужная экспертиза и нет понимания того, с какой стороны подступиться к проблеме. То есть появилась потребность, но что и как делать — не ясно.

Пример: телеком-оператор

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

Решение

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

Стадия 2: осознанная потребность

ИТ-эксплуатация принимает системы у разработчиков. Либо последние не в состоянии обеспечить нужный SLA, либо служба эксплуатации сама хочет изучить технологию, чтобы накопить важные в будущем компетенции. В большинстве случаев разработанные решения основаны на продуктах Open Source. То есть это сложный конструктор, правила работы которого знают буквально несколько человек в компании. При этом многие нефункциональные требования к ПО, такие как HA/DR (высокая доступность/катастрофоустойчивость), не проанализированы и не выполняются, а для ИБ вся эта конструкция существует в слепой зоне.

Пример: розничный банк

У нашего клиента работала контейнерная платформа на Open Source, в которой были развернуты тестовые системы. Решили передать ее на поддержку в эксплуатацию, а приложения начать выводить в продуктив. И тут выяснилось, что заказчик не знает, как обеспечить правильный SLA, защищать свое приложение, какое хранилище использовать и как делать бэкап. Служба ИБ, в свою очередь, не понимала, как встроиться в процесс DevOps.

Решение 

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

Стадия 3: продуктивная эксплуатация

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

Оговорюсь: этот этап проходят не все. Некоторые компании могут нормально жить на Open Source, но, как правило, в этом случае систему обслуживают несколько десятков человек, которые в совокупности могут стоить значительных денег (сотни тысяч долларов и больше). 

Пример: телеком-оператор

Оператор из большой тройки достаточно активно использовал контейнерные технологии и строил их на основе решений с открытым кодом. Однако в обширной ИТ-инфраструктуре с жесткими SLA их поддержка обходилась довольно дорого.

Решение 

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

Стадия 4: развиваем платформу

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

Пример: розничный банк

В банке уже был внедрен Red Hat OpenShift и выстроена разработка кода в контейнерах, но не были реализованы меры по обеспечению ИБ в контейнерном окружении. 

Решение

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

Гайд «5 вопросов к контейнерам»

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

Open Source vs Enterprise

Один из самых распространенных вопросов, которые встают на пути внедрения контейнерных сред в компании: стоит ли обращаться к чистым Open Source или взять вендорский продукт? 

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

У вендорских решений есть три основных преимущества. Первое: они предоставляют уже скомпонованную, интегрированную и отлаженную экосистему для работы контейнерной платформы из коробки. Этот конструктор уже собрали за вас. Второе: вендор обеспечивает поддержку с понятными SLA, в случае каких-либо проблем вы не окажетесь один на один с community. Третье: вендор предоставляет понятный roadmap развития и жизни платформы, что позволяет заниматься долгосрочным планированием и исключает ситуацию, когда тот или иной компонент Open Source перестает поддерживаться сообществом (в данной среде это не редкость). 

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

Инфраструктура

Вероятно, в среднесрочной перспективе продукты на базе Kubernetes начнут замещать решения для классической серверной виртуализации. Пока большая часть инсталляций Kubernetes реализована поверх слоя гипервизора, в виде виртуальных машин. Но уже сейчас распространение получают решения класса Kubernetes over bare metal, в рамках которых Kubernetes не только играет роль среды для запуска приложений поверх «виртуалок», но и полностью закрывает слой между железом и прикладным софтом. 

Пример такого решения — платформа Red Hat OpenShift Container Platform. Она существует и в более привычном варианте (поверх виртуальных машин), и как bare metal. Такой подход, с одной стороны, позволяет сократить количество технологических слоев решения и совокупную стоимость владения системой. С другой стороны, его определенные аспекты все еще требуют проработки (например, тот же слой подключения внешнего хранилища к кластеру с использованием гипервизора реализовать проще, чем без него). 

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

По мере увеличения объема микросервисов в общей доле приложений в компаниях, особенно в продуктивных контурах, все больше внимания будет уделяться вопросам создания инфраструктуры контейнерных платформ. Под этим термином мы понимаем не только сам кластер Kubernetes (это лишь вершина айсберга), но и набор сопутствующих компонентов, без которых функционирование и эксплуатация кластера невозможны или не имеют смысла. Это системы мониторинга (как самого кластера, так и работающих в нем сервисов), логгирования, трассировки, внешнего хранения и резервирования данных, интеграции с внешними источниками и приемниками данных, интеграции с CI/CD-системами. Компаниям необходимо научиться собирать из огромного количества существующих компонентов работоспособный механизм для стабильной работы платформы. Для этого нужны либо сильная внутренняя экспертиза, либо надежный партнер.

Здесь можно отметить решения для внешнего хранения данных — Persistent Storage. Несмотря на то что изначально Kubernetes не был предназначен для запуска stateful-нагрузок, в последнее время такой сценарий встречается все чаще. Видимо, удобства использования контейнерных технологий превышают возможные минусы. Традиционные методы подключения внешних дисковых массивов здесь не подходят, требуется дополнительный технологический слой управления дисковыми емкостями — некий провайдер для кластера, который позволит контейнерам работать с внешними томами в динамическом режиме. 

Одни производители традиционных дисковых массивов дополняют и адаптируют функционал своих решений до состояния Kubernetes-aware, другие изначально разрабатывают решения под Kubernetes, обычно на базе подхода Software Defined Storage. Среди последних — Pure Storage с решением Portworx, которое, на наш взгляд, с технологической точки зрения является одним из лидеров рынка. Всего же подобных решений более 60, при этом одна часть из них не развивается, другая функционально непригодна для продуктива при серьезных нагрузках.

Дополнительно ситуацию усложняет тесная взаимосвязь решений для внешнего хранения данных с технологиями резервирования кластеров между разными площадками. Эти два аспекта необходимо продумывать совместно на ранних этапах разработки целевой архитектуры. К сожалению, большая часть решений Open Source пока не обладает таким функционалом, поэтому при наличии подобной потребности выбор часто делается в сторону вендорских продуктов. В них эти вопросы уже проработаны из-за специфики enterprise-рынка. Мы рассчитываем на то, что в ближайшей перспективе решения Open Source будут подтягиваться до стабильного и функционального уровня, пригодного для продуктивных нагрузок, и что экосистема в целом будет выходить на достаточный уровень зрелости технологий.

Централизованное управление

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

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

В сегменте приватных инфраструктур такие средства пока представлены недостаточно широко, но предложения уже есть. Кроме того, с учетом большого количества сред и еще большего количества изменений, происходящих с микросервисными приложениями, становится актуален вопрос автоматизации управления. Здесь упор нужно делать на GitOps. При таком подходе основной задачей ИТ-служб и отделов разработки является грамотное описание целевого состояния системы, а соответствующий инструментарий отвечает за отслеживание текущего состояния и его приведение к целевому в автоматическом режиме. 

Вся идеология Kubernetes, строящаяся на декларативном описании требуемого состояния ресурсов, хорошо ложится на такой подход и способствует его внедрению. Таким образом, средства автоматизации и подходы Infrastructure as Code становятся еще более актуальными по мере роста количества кластеров, увеличения числа сервисов и продуктовых команд. В это направление обязательно нужно инвестировать время и ресурсы.

Вопросы безопасности

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

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