Docker: когда нужно размещать контейнер на виртуальной машине?
Контейнеры приложений гарантируют высокую скорость работы и утилизацию ресурсов, но им не хватает той безопасности, которую обеспечивают виртуальные машины. Поэтому сегодня хочется поговорить об использовании Docker внутри ВМ, в частности — OpenSource проекта QEMU/KVM.
Если не погружаться глубоко в специфику различных контейнеров, можно кратко охарактеризовать Docker, как быстрое и динамичное решение, позволяющее моментально запускать миллионы контейнеров с конкретными приложениями. Docker предлагает все необходимое для запуска готовых сборок ПО с сопутствующими компонентами, но при этом многие до сих пор беспокоиться о безопасности таких нагрузок. Проблема заключается в том, что Docker пока что является очень молодым решением, и не все «детские проблемы» решены. А при запуске на одной машине множества Docker-сред злоумышленник чисто технически позволяет получить доступ к ресурсам одного пользователя через взлом другого. Согласитесь, это не хорошо.
Docker внутри QEMU
Внутри Docker изоляция реализована сегодня за счет NameSpaces, но надежность этого подхода все еще вызывает сомнения. Поэтому достаточно распространённой практикой является запуск контейнера внутри виртуальной машины. Как правило выбирается именно QEMU, так как это один из самых популярных проектов виртуализации с открытым исходным кодом. Внутри виртуальной машины QEMU уже запускаются контейнеры одного пользователя. Таким образом, мы находим компромисс между безопасностью и быстродействием, ведь пользователи оказываются надёжно защищены друг от друга, а приложения одного владельца работают достаточно быстро, будучи запущенными в контейнерном окружении.
В погоне за скоростью
Однако со временем, когда контейнеров становится больше, этот компромисс начинает быть проблемой. Поэтому разработчики начинают активно с ней бороться. Так, в сообществе появляются различные технологии, помогающие решить актуальный вопрос — повысить производительность более защищенных сред, работающих с использованием Docker.
Например, ClearLinux представляет собой собственный дистрибутив Intel, который рассчитан не только на работу в рамках экосистемы intel architecture, но также на расширенную поддержку Docker. ClearLinux имеет возможность настройки «слоёв» — отдельных компонентов файловой системы, из которых формируется корневая директория контейнера Docker. Это позволяет значительно повысить эффективность работы с гипервизором. Решение очень перспективное, но основные свои преимущества, конечно, показывает только на оборудовании Intel.
Другой вариант — использование Unikernel. Специально подготовленные образы ОС позволяют уменьшить влияние на производительность присутствия ядра ОС в гостевой ВМ (где уже запускается Docker). Специально облегчённые ядра различных ОС с регламентированным адресным пространством — это проверенные, поддерживаемые и готовые для коммерческого использования решения, оптимизированные для работы с определёнными приложениями. Если под нужное вам приложение, которое вы собираетесь использовать в Docker, уже был создан Unikernel, значит вы сможете использовать изоляцию ВМ c куда большей эффективностью.
Мы в Virtuozzo также продолжаем следить за эволюцией Docker и предлагаем свое решение данной проблемы. Так, гипервизор KVM на базе Virtuozzo не только позволяет использовать облегченные ВМ, но также поддерживает ряд оптимизаций именно для запуска Docker-контейнеров. В дополнение к этому легкие ВМ на OpenVZ и коммерческой Virtuozzo добавляют к возможностям KVM функции резервного копирования и дополнительного мониторинга безопасности, внося свою лепту в защиту экосистемы Docker, запущенной в рамках ВМ.
Поддержка Docker становится необходимой
Хотя сегодня мы говорим о том, что можно обеспечить оптимизацию безопасности Docker за счет использования ВМ или легких ВМ, как промежуточного уровня, то в ближайшем будущем сообщество будет заниматься не только повышением производительность ВМ, как отдельного слоя изоляции, но также возможностью запуска контейнеров Docker непосредственно на базе гипервизора.
В экосистеме Virtuozzo мы вообще рассматриваем Docker, как один из возможных вариантов запуска нагрузок в общей виртуальной среде — наравне с легкими виртуальными машинами и традиционными виртуальными машинами (на базе различных ОС). Сегодня активно ведутся работы по расширению поддержки сервисов о-Docker, таких как hub, compose, kubernetes, flocker, libnetwork, различных средств проверки безопасности и т.д.
Таким образом, за счет собственных усилий команды Docker, наличия различных проектов по оптимизации эффективности промежуточных ВМ для запуска Docker и перспективной поддержки Docker на уровне гипервизора, в скором времени контейнеры приложений Docker смогут заявить о достойном уровне безопасности уже без компромисса со скоростью работы, сохраняя основное преимущество Docker.
Комментарии (6)
zag2art
26 октября 2016 в 09:09
–1↑
↓
Интересно, из каких соображений выбрана первая фотка?26 октября 2016 в 09:48
+1↑
↓
Контейнер на машине. Что тут непонятного.
А по теме статьи — спасибо, погружаюсь в мир Docker и всегда интересно узнать что-то новое в стэке технологических решений. Но все же надеюсь, что когда-нибудь Docker обеспечит vm-подобную защиту контейнеров без этой самой vm.26 октября 2016 в 09:50
+3↑
↓
Я думаю, иллюстрация того, что контейнер на физической машине — не всегда хорошо и полезно.
26 октября 2016 в 09:41
+1↑
↓
Так я не понял — когда нужно размещать, а когда нет?26 октября 2016 в 09:49
0↑
↓
Когда вам понадобится бОльшая секьюрность, чем может предоставить докер с неймспейсами, тогда и берите что-то из перечисленного в сабже.
26 октября 2016 в 09:48
+1↑
↓
Сочетание заголовка и КДПВ очень грамотное.
