Контейнеры или виртуальные машины — что лучше выбрать для своей компании?

Вопрос несколько сложнее, чем «куда поместится больше приложений»

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

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

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

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

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

Проблема контейнеров № 1: безопасность

Это самая серьезная проблема, которая, однако, часто упускается из виду. Дэниэл Уолш, инженер по безопасности из Red Hat, опубликовал статью «Пустые контейнеры». Там рассматривается Docker, который использует libcontainers в качестве основы. Libcontainers взаимодействует с пятью пространствами — Process, Network, Mount, Hostname, Shared Memory — при работе с Linux. При этом есть множество важных подсистем ядра Linux вне контейнера.

К ним относятся все устройства, SELinux, Cgroups и вся файловая система внутри /sys. Это значит, что при наличии у пользователя или приложения прав суперпользователя в контейнере операционная система может быть взломана. И это плохо.

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

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

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

Вообще, на смартфоны тоже не стоит ставить что попало, но это уже совсем другая история.

Прочие проблемы контейнеров

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

Роб Хиршфельд, генеральный директор RackN, отметил следующее: «Идея «изолированной коробки» помогает решить часть проблем с нижестоящими системами (вы знаете, что у вас там есть), но никак не с вышестоящими (вы не знаете, от чего зависите)».

Тут я хотел бы добавить, что это не только проблема безопасности, но и проблема обеспечения качества. Можно сказать, что X контейнеров в состоянии поддерживать веб-сервер NGINX, но достаточно ли вам этого? Включен ли в такое решение заодно и обновленный балансировщик TCP? Развернуть приложение в контейнере довольно легко, но если ошибиться с выбором компонентов, то вы просто потратите время впустую.

Хиршфельд также указывает на серьезность проблемы разрастания числа контейнеров. Стоит помнить о том, что «Разделение системы на множество более мелких отдельных частей — хорошая идея. Но это означает и то, что управлять придется ЕЩЕ БОЛЬШИМ числом элементов. Всегда существует некая переломная точка между декомпозицией и неконтролируемым разрастанием».

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

Верно, некоторые технологии контейнеризации вроде Linux Containers (LXC) могут использоваться вместо VM. К примеру, LXC можно использовать для запуска определенных приложений Red Hat Enterprise Linux (RHEL) 6 на экземпляре RHEL 7. Но если говорить в общем, то для запуска одного приложения подходят контейнеры, а для нескольких лучше использовать виртуальные машины.

Непростой выбор

Так что же выбрать — VM или контейнеры? Если требуется запустить несколько копий одного приложения, скажем MySQL, то используйте контейнер. Если нужна большая гибкость при работе нескольких программ — задействуйте виртуальную машину.

Кроме того, контейнеры обычно привязывают к определенной версии операционной системы. Это бывает полезно: нет необходимости беспокоиться о зависимостях, если приложение корректно работает в контейнере. Но взамен вы получаете дополнительные ограничения. С виртуальными машинами не важно, какой гипервизор используется (KVM, Hyper-V, vSphere, Xen), — скорее всего, вы сможете запустить там любую ОС. Нет проблемы запустить в VM специфичное приложение, работающее только на QNX. Но реализовать это с нынешним поколением контейнеров становится не просто.

Итак, подытожим:

• Необходимо запускать максимум приложений на минимальном количестве серверов? В таком случае вы наверняка воспользуетесь контейнерами. Но помните о необходимости дополнительно позаботиться о безопасности.
• Если же нужно выполнять множество приложений и/или поддерживать различные ОС — лучше подойдут виртуальные машины. И если вопрос безопасности для вашей организации стоит на первом месте, то тоже лучше остаться при VM.
• Полагаю, большинство из нас будут использовать контейнеры совместно с виртуальными машинами как в облаках, так и в собственных ЦОД. Ведь открываемые контейнерами возможности экономии на масштабе слишком значительны, чтобы их игнорировать. А у виртуальных машин по-прежнему есть немало достоинств.

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