Назовите любую технологическую компанию, и практически со 100% вероятностью окажется, что она заинтересована в продвижении контейнерных технологий. Google – конечно. IBM – да. Microsoft – разумеется. Вот и VMware не смогла пройти мимо.

Принимая во внимание тот факт, что в портфолио VMware имеется полный набор программного обеспечения для виртуализированных ЦОД, то интерес компании к популярной технологии ожидаем. Раньше системы на базе vSphere работали с контейнерами как с обычными виртуальными машинами, а это затрудняло управление и вело к проблемам с безопасностью.

«Теперь контейнеры станут полноправными элементами vSphere. Можно управлять как традиционными приложениями внутри виртуальных машин, так и приложениями следующего поколения на базе контейнеров. Обе технологии будут работать бок о бок на одной платформе», – говорит Кит Колберт (Kit Colbert), директор по облачным приложениям VMware.

Для поддержки новой технологии инженеры компании доработали виртуальную машину и вынесли часть ее функций на уровень гипервизора. Это позволило добавить поддержку контейнеров, сохранив им привычные качества виртуальной машины. Получается, что VMware представила возможность получить сразу все преимущества Linux-контейнеров и традиционной виртуализации на одной платформе vSphere.

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

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

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

Первая и самая серьезная проблема, которая часто упускается из виду – это безопасность, кто бы что ни говорил. Дэниэл Уолш (Daniel Walsh), инженер по безопасности Red Hat, опубликовал статью «Пустые контейнеры». В ней рассматривается Docker, который в качестве основы использует libcontainers. Libcontainers взаимодействует с пятью пространствами: Process, Network, Mount, Hostname, Shared Memory.

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

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

Вот три совета, которые дает Уолш по этому поводу:

• Удалите привилегии;
• Старайтесь не запускать службы с root-правами;
• Всегда учитывайте, что root-права могут действовать и вне контейнера.

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

«Разделение системы на множество более мелких отдельных частей – это хорошая идея. Но это означает и то, что управлять придется большим числом элементов. Существует тонкая грань между декомпозицией и неконтролируемым разрастанием», – комментирует Роб Хиршфельд, генеральный директор RackN.

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

Большинство людей, которые начинают работу с Docker, используют официальные репозитории Docker, которые, к сожалению, как раз приводят к образу размером с небоскреб, когда он мог быть не больше скворечника. В них слишком много лишнего хлама. Стандартный размер образа Node занимает минимум 643 МБ – это очень много.

Здесь на помощь придут микроконтейнеры, которые содержат только библиотеки операционной системы и другие зависимости, требуемые для запуска приложения, и само приложение. Вы увидите, как приложение, которое занимало 643 МБ, будет занимать 29 МБ, что в 22 раза меньше.



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

На эту тему есть неплохое поясняющее видео:



Так как же создать эти микроконтейнеры? Лучше всего начать со scratch-образа, в котором нет абсолютно ничего. С его помощью вы можете создать самый маленький образ для своего приложения, если вам удастся скомпилировать проект в один бинарный файл без зависимостей, как это позволяет сделать Go. Например, этот образ содержит веб-приложение на Go и весит всего 5 МБ.

Однако не все пишут программы на Go, потому, вероятно, у вас будут несколько зависимостей, и scratch-образ вам не подойдет. Воспользуемся Alpine Linux. Образ Alpine весит всего 5 МБ. Поэтому для нашего простого приложения на Node Docker-файл примет следующий вид:

FROM alpine
RUN apk update && apk upgrade
RUN apk add nodejs

Теперь, чтобы добавить код к образу, нужно прописать еще пару дополнительных строк:

FROM alpine
RUN apk update && apk upgrade
RUN apk add nodejs

WORKDIR /app
ADD . /app
ENTRYPOINT [ "node", "server.js" ]

Код приложения и подробные инструкции можно найти здесь.

Такие образы Docker содержат только необходимые компоненты для работы приложения. Ничего лишнего. Таков мир микроконтейнеров.