В этой статье я дам обзор того, где вы можете найти интеграцию с Docker в экосистеме Cloud Foundry. Мы посмотрим на Декера, Стакато и Диего.
палубное судно
На прошлой неделе мне посчастливилось дойти до встречи в лондонской группе пользователей PaaS . Там я встретил Колина Хамфриса из CloudCredo и увидел, как он демонстрирует Decker .
Decker — это прототип, созданный Колином для использования Docker в качестве бэкэнда для Cloud Foundry. Decker реализует API-интерфейс DEA, поэтому он является компонентом Cloud Foundry. Это похоже на то, как были реализованы другие сторонние DEA, такие как Iron Foundry .
Протокол HTTP API плюс шина сообщений Cloud Foundry позволяет любому пользователю написать подключаемый модуль для подготовки и запуска экземпляров приложения. Это также означает, что вы можете запускать приложения на платформах, отличных от Linux, таких как Windows, и при этом использовать Cloud Foundry в Linux — лишь в том случае, если сторонний DEA общается с остальной частью системы, используя протокол Cloud Foundry DEA. Это то, что Колин сделал с Декером.
Когда вы хотите развернуть приложение в Docker, вы указываете --stack deckerсвоей cf pushкомандой. Decker DEA объявляет, что поддерживает этот стек, поэтому Cloud Controller будет направлять туда экземпляры приложений.
В настоящее время Decker работает с Dockerfiles , а не со встроенными образами Docker. Dockerfile — это отдельный файл, в котором перечислены все команды, которые запускаются для создания образа Docker.
Когда cf pushзапускается, Dockerfile загружается в Cloud Controller. Облачный контроллер выбирает Dea DEA Колина для развертывания в соответствии с --stack deckerуказанным.
Как признает Колин, процесс создания прототипа Decker на данный момент немного обманывает и на самом деле мало что делает для подготовки. В настоящее время Декер просто сохранит файл Docker в дроплете и оставит сборку образа Docker до времени выполнения. При каждом развернутом экземпляре капли Decker извлекает файл Docker из капли, создает образ Docker, а затем запускает построенный образ Docker в качестве нового контейнера.
Очевидно, что создание новых образов Docker во время выполнения неэффективно и может привести к появлению « снежинок », если какая-либо из зависимостей изменится или произойдет что-то необычное во время сборки образа Docker. Как упоминал Колин, это MVP (минимальный жизнеспособный продукт), и это будет рассмотрено в будущих итерациях.
В настоящее время безопасность связана с тем, чтобы пользователи Cloud Foundry могли развернуть любой образ Docker по своему выбору. Когда вам разрешено создавать свои собственные образы, довольно просто разрешить пользователю этого контейнера запускаться от имени пользователя root. Пространство имен пользователя cgroups основывается на идентификаторе пользователя хост-системы. Пользователи внутри контейнера получат уникальный идентификатор, который не существует вне контейнера. К сожалению, пользователь root имеет идентификатор 0 как внутри, так и снаружи контейнера, поэтому он является одним и тем же пользователем как внутри, так и снаружи контейнера. Если пользователь становится пользователем root внутри контейнера, он может вырваться из контейнера и получить доступ к хост-системе.
Stackato
В декабре прошлого года ActiveState выпустил Stackato 3.0, в котором мы заменили нашу собственную реализацию LXC на Docker. У нас был многолетний опыт работы с LXC и cgroups, и мы проанализировали реализацию с открытым исходным кодом dotCloud под названием Docker. Нам понравилось то, как они это реализовали, и мы увидели очевидный потенциал Докера в будущем PaaS, но также знали, какую линию нам нужно провести вокруг нашей интеграции. Докер был молодым, не рекомендованным к производству, но основы обеспечения контейнеров LXC были прочными.
Поэтому в Stackato 3.0 интеграция с Docker была минимальной. Мы заменили уникальный шаблон LXC Stackato одним базовым образом Docker. Предоставленные контейнеры не имели доступа sudo (по умолчанию), и разработчик приложения не мог указать, как образ Docker был построен с точки зрения функциональности Docker. Что касается Stackato, то fence (менеджер контейнеров LXC в Stackato) по-прежнему просто поставлял базовые контейнеры LXC. Разница заключалась в том , что LXC резервах теперь было десять тысяч глазных яблок на нем и ActiveState заложила основу для Stackato быть корпоративным классом Docker PaaS , когда Docker достигает зрелость.
Оформление приложений в Stackato 3.0, аналогично Cloud Foundry v2, стало ориентированным на buildpack. Для конечного пользователя это может быть не совсем очевидно, поскольку теперь у нас есть встроенные «устаревшие пакеты сборки», которые копируют поведение резидентной поддержки Stackato 2.10 (и ранее) для сред выполнения и сред.
Когда демон управления контейнерами Stackato, fence, предоставляет контейнер LXC через базовый образ Docker, контейнер LXC используется для построения стека с использованием пакетов сборки и промежуточных хуков . Затем капли извлекаются из контейнера LXC таким же образом, как это было в Stackato до 3.0.
Администратор Stackato может изменить базовый образ Docker, который использует забор, с помощью нескольких команд kato.
$ kato config get fence docker/image stackato/stack/alsek $ kato config set fence docker/image exampleco/newimg exampleco/newimg - See more at: http://www.activestate.com/blog/2014/04/docker-and-cloud-foundry#sthash.UPNuyBcy.dpuf
Мы все еще не прошли «полностью Docker» по уважительным причинам. Мы все еще не можем позволить пользователям развертывать образы Docker, где они могут получить root-доступ к контейнеру, а затем и к хост-системе. Это было решено на уровне LXC / cgroups, и когда мы говорим, я уверен, что кто-то работает над реализацией Docker, но она пока недоступна. Мы также поддерживаем Ubuntu LTS и поддерживаемые ядра, так что мы ждем выравнивания всех звезд.
Диего
Diego — это новый компонент Cloud Foundry, цель которого — перестроить способ управления подготовкой и развертыванием. Это существенно заменяет DEA чем-то, что должно быть более расширяемым в различных средах выполнения.
Долгое время Cloud Foundry использовала Warden для управления контейнерами. Подобно Docker или первоначальной реализации LXC в Stackato, Warden основан на LXC и cgroups. С Диего Страж становится Садом.
Так, где Докер вписывается в Диего?
Интеграция минимальна, и вы не найдете Docker в развернутом кластере Cloud Foundry. В настоящее время Docker используется только для создания шаблона LXC, который затем использует Garden. Docker — это просто инструмент времени сборки для выпуска Cloud Foundry.
Хотя, возможно, что Диего мог бы предоставить дополнительный сервер Docker.
Диего состоит из 3 компонентов — Stager, металлургического завода и исполнителя. Сначала Stager, работающий в Linux, настраивает задание на плавку. Завод, работающий на целевой платформе, создает каплю приложения. В этом случае задача исполнителя, который также выполняется на целевой платформе, состоит в том, чтобы запускать дроплет как работающее приложение.
Smelter и Executor, работающие на целевой платформе, предоставляют способ поддержки любого бэкэнда, будь то Linux, Windows или другой. Серверная часть Linux предоставляется компанией Garden (ранее Warden). Должна быть возможность иметь другой, хотя и избыточный, бэкэнд Linux, такой как Docker.
Вывод
Существует огромный потенциал для сотрудничества Docker и Cloud Foundry. Интеграция была доказана с 3 различными проектами. Декер, Стаккато и Диего каждый по-разному подходят к точкам интеграции. Очевидно, что интеграция Диего в настоящее время живет за пределами встроенного выпуска Cloud Foundry, но существует дополнительный потенциал для обеспечения интеграции с Docker через Smelter и Executor.
Колин Хамфрис на прошлой неделе заинтересовался лондонской группой пользователей PaaS. Он сказал, что считает, что текущая модель PaaS должна быть разделена, чтобы у нас был еще один уровень. Этот слой он называет CaaS, или Контейнеры как услуга. Эта идея мотивирует Декера.
Насколько тесно должен быть интегрирован PaaS с его реализацией контейнеризации? Должны ли пользователи Cloud Foundry легко подключать и отключать различные диспетчеры контейнеров, например, отключать Warden для Docker? Что мы теряем из-за накладных расходов на их разделение? Что мы получаем?