Как перестать бояться деплоя и полюбить китов. Особенности настроек и опыт контейнеризации

«У меня все работает», — возможно, именно эта фраза стала первопричиной появления контейнеров. На самом деле, все намного сложнее, и повсеместное использование изолированных сред стало ответом на вызовы времени. О том, почему контейнеры так плотно вошли в современный стек, какая от них выгода бизнесу, с какими особенностями приходится считаться разработчикам, и как VK Cloud упрощает управление контейнерами за счет managed-решений — рассмотрим в материале.

Что такое контейнеризация

Предпосылки появления контейнеров можно обнаружить еще в конце 1970-ых, когда заговорили об изолированных средах. Тогда впервые появилась полная изоляция корневых каталогов, но потребности бизнеса лежали в другой плоскости. Даже в виртуализацию (начали использовать в 1964 году) и «цифру» верили не все, поэтому каких-то значимых открытий в этой области не было больше 20 лет.

Дальнего родственника упаковщиков в контейнеры можно разглядеть в FreeBSD Jail. Решение появилось в начале 2000-ых и подразумевало изоляцию приложений в рамках одной ОС. В нулевые появилось сразу несколько технологий виртуализации на уровне операционной системы. Можно вспомнить OpenVZ или Solaris Containers, но к формированию платформы Docker, о которой мы поговорим ниже, они имеют опосредованное отношение.

В 2006 году в Google был разработан механизм изоляции аппаратных ресурсов (например, RAM или CPU), который получил название Process Containers. Спустя два года и под сокращенным названием cgroups — эту функциональность добавили в ядро Linux. Столкнувшись с такой любопытной возможностью управления ресурсами, в комьюнити Linux-систем быстро поняли, что они стоят на пороге открытия технологии, которая определит развитие разработки на десятилетие.

В 2010-ых разработка стала требовать высокого уровня синхронизации между всеми участниками. Часто получалось так, что модули или целые приложения выглядели и разворачивались на разных компьютерах по-разному. Появление Docker в 2013 году решило эту проблему, поскольку контейнеры содержали внутри себя все необходимое для запуска: операционную систему, драйверы, зависимости, библиотеки и настройки. Это значило, что у всей команды могут быть, например, установлены разные версии Python, но это никак не скажется на работе приложения.

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

Возможно, создатели первых контейнерных сред вдохновились контактным зоопарком, когда увидели, что запускать всех животных в один вольер не самая лучшая практика. Животные начинали вести себя непредсказуемо, даже если до объединения были спокойными. Некоторые виды просто не уживались вместе, другие — паразитировали на соседях и отнимали их ресурсы. Если отложить метафору с зоопарком в сторону, окажется, что с приложениями ситуация почти такая же.

В пользу этого говорит и решение-прародитель FreeBSD Jail. Jail (клетка) — здесь вообще не случайное слово. Когда дикие звери или приложения разведены по своим вольерам — с ними на порядок удобнее работать. В каждой такой клетке есть все инструкции, все рекомендации и полностью исключается риск, что «хищники» вырвутся на свободу и съедят все ресурсы соседних виртуальных машин.

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

Основные преимущества контейнеризации для бизнеса

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

Топ-5 ключевых изменений или почему Docker оказался геймченжером

1. Сократился time-to-market продуктов. На имплементацию сервиса, упакованного в контейнер, стал уходить в среднем 1 день работы DevOps-инженера. Раньше на это бы ушла в среднем неделя. Возможно, потребовалось бы подключение команды, чтобы настроить управление сервисом.
2. Простое и быстрое масштабирование. Если нужно запустить 10 новых инстансов, достаточно поднять 10 новых контейнеров. Поднять их вручную несколько сложнее, чем использовать оркестраторы, но до них мы еще доберемся.
3. Автоматизация. Контейнеры можно легко заменять другими аналогичными, поэтому если какой-то вдруг упал, то часто поднять новый проще и быстрее, чем пытаться реанимировать прошлый. Автоматизация касается не только автохилинга, но и ряда других процессов. Например, контейнерные среды помогают реализовать бесконфликтное тестирование, поскольку каждый тест может запускаться в чистой среде, а одной командой: docker-compose up auth-service payment-service notification-service можно поднять целую экосистему. В противном случае, пришлось бы открывать три терминала, в каждом пройти к папке сервиса, проверить зависимости, порты и только затем запустить.
4. Безопасность. Как правило, если злоумышленники получили доступ к контейнеризированному приложению, они не могут видеть процессы других приложений или читать файлы других сервисов. Дополнительную сложность создает архитектурный момент: запущенные контейнеры нельзя изменять, поэтому забросить вредоносное ПО труднее. Нельзя сказать, что само по себе использование контейнеров — уже гарантия безопасности, но при правильной настройке и соблюдении правил конфигурирования, чтобы положить все сервисы контейнеризированного приложения уйдет кратно больше времени.
5. Гибкое управление и полная утилизация ресурсов. Работа с контейнерами делает возможными сценарии, когда все вычислительные ресурсы компании используются без простоев. Виртуализация и упаковка ресурсов в контейнеры помогает приоритизировать при необходимости или равномерно распределить их под актуальные нагрузки, а также быстро пересобирать под изменившуюся ситуацию.

Кажется, что с преимуществами для бизнеса почти все понятно, но остается вопрос: как управлять таким массивом контейнеров? Технологии оркестрации продакшен-сред развивались параллельно Docker, но самый известный продукт — Kubernetes также берет начало в Google. Можно сказать, что Kubernetes появился, чтобы выстраивать docker-контейнеры в правильном порядке или автоматизировать выкатку, но сегодня его функциональность перешагнула Docker и оркестратор научился работать с разными платформами контейнеризации, например, containerd и CRI-O. Это освободило бизнес от туннельного выбора среды выполнения.

Безопасность контейнеров

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

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

Как мы вообще узнаем об уязвимостях? Сейчас любой крупный бизнес работает с большим количеством стороннего кода: какие-то фреймворки, библиотеки из Open Source, которые не всегда проверяются на предмет бэкдоров или закладок в силу разных причин. От большого количества звезд, до неподходящих пайплайнов тестирования.

Мы можем найти уязвимость сами, в результате Bug Bounty или обнаружить ее на горьком опыте в попытках восстановить инфраструктуру. Но пока непоправимого не случилось — мы просто знаем, что где-то в окружении есть скомпрометированный элемент. Мы не знаем только одного: кто еще знает об этой уязвимости? Пользовались ли ей уже раньше и вендор в курсе проблемы или это нечто совершенно новое. Возможно, об этом уже успели рассказать в комьюнити и для злоумышленников это будет красной тряпкой, чтобы проверить, кто не успел поставить патч.

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

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

Как начать переход на контейнеризацию, этапы внедрения

По ходу материала мы мало касались минусов контейнеризации — их не так много, но сейчас подошли к ключевому: высокий порог входа. Чтобы начать использовать контейнеры, недостаточно просто установить Docker или любую другую платформу. Это масштабное архитектурное преобразование, которое требует не только специфических компетенций, но и определенной зрелости процессов во всей компании. Приводим ориентировочный Roadmap перехода на контейнерные среды своими силами.

Шаг 1. Аудит и планирование (1-2 месяца)

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

Шаг 2. Пилот (2-3 месяца)

• Выбираем простое stateless-приложение.
• Контейнеризируем его полностью. Да, сказать проще, чем сделать.
• Настраиваем CI/CD для контейнеров.
• Деплоим в продакшн-среду.
• Ожидаемый результат: ускорение деплоя в 5-10 раз.

Шаг 3. Массовая миграция (6-12 месяцев, время здесь сильно зависит от количества данных и сервисов)

• Переводим оставшиеся приложения.
• Внедряем оркестрацию (Kubernetes/Docker Swarm).
• Настраиваем мониторинг и логирование.
• Ожидаемый результат: время деплоя сокращается на 70%.

Шаг 4. Доработки и оптимизация (3-6 месяцев)

• Настраиваем автоскейлинг.
• Оптимизируем ресурсы.
• Внедряем advanced-практики (service mesh, GitOps).

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

Почему внедрять контейнеры не так больно, когда делаешь это в команде

Контейнеризация как технология обеспечивает стабильную работу бизнес-приложений и позволяет писать код, который работает корректно на любых серверах и с любым типом виртуализации. Звучит отлично, но миграция, развертывание и управление — точки, в которых легко упустить преимущества контейнеризации. Чтобы использовать преимущества контейнеризации в полную силу, можно воспользоваться помощью провайдера. VK Cloud поддерживает один из самых высоконагруженных кластеров Kubernetes и в managed-формате помогает с рядом процессов:

• Помогаем мигрировать приложения.
• Интегрируем новые компоненты.
• Технически поддерживаем и консультируем 24/7.
• Обновляем и обслуживаем платформу.
• Заменяем и восстанавливаем серверы.

Кроме этого, в VK Cloud есть команда Professional Services, которая берет на себя нагрузку и риски миграции на любом этапе разработки: от аудита инфраструктуры до обучения и помощи при развертывании. В силу обозначенных особенностей работы с безопасностью контейнеров — команда практикует подход Lift & Shift. Так мы учитываем уже на уровне архитектуры проблемы безопасности, которые несет в себе контейнеризация и переносим все данные и зависимости с минимальным количеством изменений.

Дальше о подходах и компетенциях команды расскажут их кейсы:

• «Kassa24Бизнес»: как облака обеспечивают масштабируемость и комплаенс эквайринг-сервиса
• «Комус»: как мы в 2,5 раза повысили скорость обработки запросов с помощью облачной Arenadata DB

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