Контейнеризация на горизонте: рынок ищет переносимую поставку приложений
Почему боль с окружениями становится системной проблемой и что из доступных подходов помогает её решить.
Есть разговор, который я веду с разными командами уже несколько лет, и он всегда звучит примерно одинаково. "У нас работает на моей машине, но не работает на тестовом сервере". Или: "Мы развернули новую версию, и что-то поменялось в системных библиотеках". Или: "Мы не можем быстро поднять окружение для нового разработчика".
Это не баги. Это системная боль с тем, как приложения упакованы и как они доставляются между средами. И она становится только острее по мере того, как команды растут и усложняются.
В чём проблема с окружениями
Приложение - это не только код. Это конкретная версия языка исполнения, набор системных библиотек, переменные окружения, конфигурационные файлы и зависимости, у которых тоже есть свои зависимости. Когда всё это живёт на "голом" сервере, оно накапливается и конфликтует.
Разработчик ставит одну версию библиотеки, тестовый сервер - другую, а продакшн - третью, потому что его никто не трогал с прошлого года. Результат предсказуем: один и тот же код ведёт себя по-разному в зависимости от того, где он запущен.
Виртуальные машины решают часть проблемы, но ценой накладных расходов. Запустить полноценную ВМ на каждый сервис - дорого и медленно. Для команды из пяти человек это ещё терпимо, для двадцати - уже тормоз.
Что сейчас есть на рынке
Инструментов для изоляции окружений несколько, и они решают задачу с разной степенью полноты.
Для Python-проектов virtualenv давно стал стандартом. Он изолирует зависимости на уровне языка, но не касается системных библиотек и не решает вопрос переносимости между разными ОС.
Vagrant позволяет описать виртуальную машину в файле и воспроизвести её на любом компьютере разработчика. Это уже лучше - окружение становится кодом. Но ВМ остаётся ВМ: тяжёлой, медленной и требующей ресурсов.
В ядре Linux давно есть механизмы namespaces и cgroups, которые позволяют изолировать процессы на уровне ОС без полноценной виртуализации. Это намного легче. Инструменты, которые упакуют эти механизмы в удобный рабочий процесс, уже появляются. Среди разработчиков всё чаще обсуждают LXC - Linux Containers. Идея переносимого, самодостаточного "контейнера" с приложением и его зависимостями носится в воздухе.
Почему это важно для бизнеса, а не только для инженеров
Медленное тестирование и сложное развёртывание - это не абстрактная техническая проблема. Это конкретные деньги и время.
Если новую версию приложения нельзя безопасно откатить - команда боится выкатывать изменения часто. Если поднять тестовое окружение занимает несколько часов - тестирование делается редко. Если новый разработчик неделю разбирается с настройкой локальной среды - это потеря производительности, которую легко посчитать.
Переносимость поставки приложений - это не про удобство разработчиков. Это про скорость и надёжность доставки изменений в продакшн.
Что проверить в своей команде
Несколько вопросов, которые помогают понять, насколько остра эта боль:
- Сколько времени занимает поднять чистое окружение для нового разработчика - от нуля до "можно работать"?
- Как часто деплой в тестинг или продакшн заканчивается проблемами из-за расхождения в окружениях?
- Задокументировано ли где-нибудь, что именно установлено на продакшн-серверах и в каких версиях?
- Можете ли вы воспроизвести продакшн-окружение на новом сервере за разумное время?
- Что происходит, когда один сервер обслуживает несколько приложений с конфликтующими зависимостями?
Если хотя бы на два из этих вопросов нет чёткого ответа - проблема с окружениями уже влияет на скорость команды. Инструменты для её решения становятся доступнее, и стоит следить за тем, что появляется в этой области.