Обзор систем контейнеризации Docker и Singularity в рамках кластеров суперкомпьютеров

В данной статье разбираются некоторые аспекты механизма контейнеризации в рамках высокопроизводительных кластеров и производится общий обзор технологии виртуализации, а так же двух технологий контейнеризации — Docker и Singularity.

Ключевые слова: Docker, контейнеризация, кластеры, облачные вычисления, виртуализация.

На сегодняшний день суперкомпьютером (HPC) является один или несколько объединенных кластером под управлением ОС Linux. Такие системы вытеснили в девяностых годах мэйнфреймы и традиционные суперкомпьютеры.

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

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

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

Большинство используемых в настоящее время сред контейнеризации, таких как Docker, Singularity или LXC, основаны на ядре Linux. Основное преимущество контейнеризации по сравнению с полной виртуализацией заключается в значительно меньшем времени простоя или неработоспособности бизнес-процессов во время проведения работ по развертыванию новых контейнеров на работающем узле. Последнее особенно важно для масштабирования крупных коммерческих веб-сервисов.

Следует упомянуть, что процесс развертывания новых экземпляров контейнеров в Docker и Singularity довольно схож, и, к тому же, созданные экземпляры обладают обратной совместимостью.

Рассмотрим архитектуры, согласно которым работают технологии виртуализации и контейнеризации. Обе архитектуры приведены на рисунке 1.

Видно, что на схеме слева (виртуализация) гипервизор координирует гостевую ОС с каждым из наборов библиотек для запуска соответствующих приложений и является некой прослойкой между аппаратной частью и ОС. В свою очередь, технология контейнеризации использует иной процесс — основная ОС (обычно Linux) использует аппаратные мощности машины, а механизм контейнера координирует среды, включая библиотеки для каждого приложения, работающего в отдельных контейнерах [1].

Рис. 1. Архитектура виртуализации и контейнеризации [1]

Стоит упомянуть, что контейнеры создаются на основании образа, структура которого определяется конфигурационным файлом. В нем пользователь определяет выполняемые команды, структуру и многие другие нюансы того или иного контейнера. Файлы конфигурации обычно начинаются с определения базового образа — некоего используемого дистрибутива Linux. Затем, в процессе сборки можно загрузить, настроить и скомпилировать дополнительные источники. И Docker, и Singularity предлагают сервис, в котором можно хранить и выгружать образы контейнеров. Вызов команды «run» запускает новый контейнер. Несколько экземпляров контейнеров могут быть созданы на основании одного и того же образа. Как правило, контейнер будет работать до тех пор, пока не будут завершены все операции, определенные в образе, либо же до тех пор, пока пользователь не использует команду «down». Контейнеры также могут работать в интерактивном режиме, например, с оболочкой на консоли. Команда «exec» позволяет выполнять операции в запущенном контейнере.

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

Из интересных особенностей архитектуры можно отметить тот факт, что Docker использует функции ядра Linux «cgroups» для управления ресурсами и «пространства имен» для изоляции запущенных внутри контейнеров процессов. Конфигурационные файлы для сборки образов называются Dockerfiles. Большинство таких конфигурационных файлов начинаются с указания так называемого «базового образа», который, как следует из названия, включает основные библиотеки и бинарные файлы определенной версии дистрибутива Linux. Такие «официальные» базовые образы публикуются соответствующими организациями, такими как «Canonical» (Ubuntu) или «Debian», через общедоступный реестр Docker Hub [2].

Если рассматривать архитектуру Docker на уровне операционной системы, то можно отметить, что основой Docker является служебный демон с названием dockerd. Основная цель данного демона — управление контейнерами. Доступ к данному демону можно получить через REST API посредством клиента Docker, используя интерфейс командной строки. Часто упоминаемая и важная деталь демона Docker заключается в том, что он работает только при наличии привилегий суперпользователя.

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

Помимо этого, для Docker существуют некоторые приложения — надстройки, которые позволяют эффективнее управлять контейнерами и предлагают пользователям дополнительные возможности. Например, программа Kubernetes, которая является разработкой Google — на данный момент является стандартом в сфере оркестрации и управления контейнерами Docker.

В отличие от Docker, Singularity изначально разрабатывалась под архитектуру высокопроизводительных кластеров, и основной целью данного приложения было повышение портируемости — то есть возможности переноса приложений, разработанных в ходе научных исследований, с одной платформы на другую

Архитектура Singularity такова, что обычные пользователи могут безопасно запускать свои контейнеры в кластерной системе суперкомпьютера без возможности и необходимости повышения пользовательских привилегий до уровня суперпользователя. Внутри, Singularity использует более простой подход, который не требует наличия демона, в отличие от Docker. Образы выполняются с правами пользователя, используя функциональность UNIX SUID. Singularity использует функцию «пространства имен» ядра Linux для изоляции процессов. Однако Singularity не использует функции ядра «cgroups» или какие-либо другие методы и способы управления ресурсами. Как упоминалось ранее, Singularity позволяет использовать образы Docker как непосредственно для выполнения, так и в качестве базового образа в инструкциях по сборке Singularity. Как и в случае с Docker Hub, для Singularity существует свой собственный общедоступный реестр образов.

Литература:

1. Контейнеризация для высокопроизводительных кластеров — электронный ресурс. URL — http://www.diva-portal.org/smash/get/diva2:1277794/FULLTEXT01.pdf
2. Docker и Singularity в рамках задач обработки данных — электронный ресурс. URL — https://pythonspeed.com/articles/containers-filesystem-data-processing/
3. Введение в контейнеризацию в рамках высокопроизводительных кластеров — электронный ресурс. URL — https://centers.hpc.mil/users/singularity.html