Контейнеры в enterprise: где заканчивается пилот и начинается платформа
Docker и контейнеризация прошли путь от хайпа к реальным внедрениям. Разбираю, что нужно, чтобы пилот превратился в инфраструктурную платформу.
Docker вышел в 2013 году и примерно год был историей о том, как удобно запускать приложения в изолированных средах на локальном компьютере разработчика. Потом появились оркестраторы - Kubernetes, Mesos, Docker Swarm - и разговор изменился. Контейнеры стали приходить в production в крупных компаниях.
Сейчас, в середине 2016 года, я всё чаще вижу одну и ту же ситуацию: пилот состоялся, команда довольна результатами, но организация не знает, как двигаться дальше. Пилот и платформа - это разные проекты.
Что отличает пилот от платформы
Пилот - это одно приложение или несколько, запущенных в контейнерах силами энтузиастов. Он демонстрирует, что технология работает, и обычно выглядит успехом.
Платформа - это другое. Это инфраструктура, на которой другие команды могут разворачивать свои сервисы, не думая о деталях. Это стандартизированные процессы сборки и деплоя, централизованное логирование и мониторинг, управление секретами, сетевая политика, процедуры обновления и откатов.
Переход от пилота к платформе требует ответов на вопросы, которые в пилоте были проигнорированы: кто за это отвечает, как это мониторится, что происходит при сбое, как это интегрируется с существующими процессами безопасности и соответствия требованиям.
Типичные ловушки перехода
Первая - техническая команда тащит весь груз. В пилоте это нормально: два-три человека энтузиастов делают всё сами. В платформе это не масштабируется. Нужны явные роли, процессы, документация.
Вторая - оркестратор выбран, но не освоен. Kubernetes - мощный инструмент с высоким порогом входа. Компании ставят его в продакшн после поверхностного знакомства и обнаруживают, что при сбоях никто не понимает, что происходит.
Третья - безопасность добавляется постфактум. Контейнеры не являются волшебной изоляцией. Образы нужно сканировать на уязвимости, привилегии контейнеров нужно контролировать, сетевой трафик между контейнерами нужно ограничивать. Всё это проще выстроить с нуля, чем добавить в работающую инфраструктуру.
Четвёртая - stateful-сервисы. Базы данных и другие сервисы с состоянием в контейнерах требуют отдельного подхода к хранению данных, резервному копированию и восстановлению. Это не решённая задача "из коробки".
Что нужно для успешного перехода
Организационно: команда-владелец платформы, с явной ответственностью за её эксплуатацию и развитие. Не "те, кто делали пилот", а официальная роль с ресурсами.
Технически: минимальный набор эксплуатационных стандартов - как собираются образы, как настраивается логирование, как работает мониторинг, как производится деплой и откат. Это скучная документация, без которой платформа превращается в индивидуальное знание нескольких людей.
Процессно: понять, какие приложения переносятся первыми. Лучше начинать с новых сервисов или с тех, у которых нет legacy-зависимостей, а не с попытки "контейнеризировать всё сразу".
Вопросы для оценки готовности
- Есть ли у нас команда, которая будет владеть платформой - а не просто те, кто делали пилот?
- Понимаем ли мы, как восстанавливаться при сбое оркестратора или узла кластера?
- Как наши требования по безопасности и соответствию отображаются на контейнерную инфраструктуру?
- Какие три первых приложения мы переведём на платформу, и почему именно они?
Контейнеры в enterprise - это не вопрос "делать или нет". Вопрос в том, есть ли у вас всё необходимое для того, чтобы пилот стал платформой, а не красивым экспериментом.