Разработчик ПО для контейнерной виртуализации
103,18
рейтинг
26 октября 2016 в 08:05

Администрирование → Docker: когда нужно размещать контейнер на виртуальной машине?

image

Контейнеры приложений гарантируют высокую скорость работы и утилизацию ресурсов, но им не хватает той безопасности, которую обеспечивают виртуальные машины. Поэтому сегодня хочется поговорить об использовании 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 непосредственно на базе гипервизора.

image

В экосистеме Virtuozzo мы вообще рассматриваем Docker, как один из возможных вариантов запуска нагрузок в общей виртуальной среде – наравне с легкими виртуальными машинами и традиционными виртуальными машинами (на базе различных ОС). Сегодня активно ведутся работы по расширению поддержки сервисов о-Docker, таких как hub, compose, kubernetes, flocker, libnetwork, различных средств проверки безопасности и т.д.

Таким образом, за счет собственных усилий команды Docker, наличия различных проектов по оптимизации эффективности промежуточных ВМ для запуска Docker и перспективной поддержки Docker на уровне гипервизора, в скором времени контейнеры приложений Docker смогут заявить о достойном уровне безопасности уже без компромисса со скоростью работы, сохраняя основное преимущество Docker.
Автор: @Gummio_7
Virtuozzo
рейтинг 103,18
Разработчик ПО для контейнерной виртуализации

Комментарии (15)

  • 0
    Интересно, из каких соображений выбрана первая фотка?
    • +4
      Контейнер на машине. Что тут непонятного.
      А по теме статьи — спасибо, погружаюсь в мир Docker и всегда интересно узнать что-то новое в стэке технологических решений. Но все же надеюсь, что когда-нибудь Docker обеспечит vm-подобную защиту контейнеров без этой самой vm.
    • +7
      Я думаю, иллюстрация того, что контейнер на физической машине — не всегда хорошо и полезно.
  • +1
    Так я не понял — когда нужно размещать а когда нет?
    • 0
      Когда вам понадобится бОльшая секьюрность, чем может предоставить докер с неймспейсами, тогда и берите что-то из перечисленного в сабже.
  • +3
    Сочетание заголовка и КДПВ очень грамотное.
  • 0
    А при запуске на одной машине множества Docker-сред злоумышленник чисто технически позволяет получить доступ к ресурсам одного пользователя через взлом другого.

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

    • 0
      Все верно, но при этом запуск внутри ВМ используется сегодня, как дополнительный уровень изоляции. Применять его или нет — дело выбора и конкретной ситуации.
  • +1
    Все знают фразу «краткость — сестра таланта»

    Но не все помнят ее продолжение «и теща гонорара».

    Написали по делу, но будто бы отписку, а не пост. Просим, просим, вам же есть что рассказать!
    • 0
      Так задавайте вопросы — в какую сторону тему развивать. :) Мы и напишем. :)
  • 0
    Когда вы пишите что «Как правило выбирается именно QEMU», вы подразумеваете что гипервизор хоста не поддерживает vmx?

    «Внутри Docker изоляция реализована сегодня за счет NameSpaces, но надежность этого подхода все еще вызывает сомнения.»
    — Расскажите пожалуйста, которые аспекты docker'a вызывают соменения? Какие именно есть риски?
    • 0
      Нет, имеется в виду KVM+Qemu (да, не совсем точно выразились) — то есть именно KVM, а не какой-то другой гипервизор (например XEN).

      Далее, слабое место — это общее ядро — если из одного контейнера удаётся «сломать» его, то ломаются все контейнеры. Кроме того, ядро большое, сделать его безопасным ВСЁ невозможно, получается, что либо мы предоставляем контейнеру пользоваться лишь небольшим набором функций (а остальные запрещаем), либо даём ему всё, но учитываем риск получить «дырку» в безопасности.
  • 0
    Если я правильно понял вопрос, то об этом как раз прошлый пост — https://habrahabr.ru/company/virtuozzo/blog/309730/
  • 0
    Внутри виртуальной машины QEMU уже запускаются контейнеры одного пользователя.
    Не совсем понятна фраза, из реальной жизни есть много проектов с кучей фронтендов, бекендов, бекенды тоже разные есть, типо аля микросервисы, базы данных, и т. д. И где концептуально правильней использовать виртуализацию, а где контейнеры, по какому признаку группировать контейнеры по ВМ?
    • 0
      Если я правильно понял вопрос, то об этом как раз прошлый пост — https://habrahabr.ru/company/virtuozzo/blog/309730/

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Администрирование