Magnum против Murano: контейнерная стратегия OpenStack

27.06.2016
Последние 18 месяцев продемонстрировали, что контейнерные разработки останутся с нами надолго. А почему бы и нет? Контейнеры маленькие, портативные, нетребовательны к ресурсам и быстро запускаются… что в них может не нравиться?

Отчасти причины популярности контейнеров объяснимы соображениями практического толка, и это справедливо как для уже реализованных проектов, так и для новых. Например, природа контейнеров позволяет перемещать их от стадии разработки к стадии тестирования и продуктиву, не вводя новые переменные. В противном случае это бы негативно отразилось на их надёжности.

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

 С учетом вышесказанного неудивительно, что существовавшие уже многие годы контейнеры стали стремительно завоевывать мир после того, как Docker сделала их использование намного удобнее. Однако, несмотря на фурор, который произвело появление технологий Docker в различных отраслях, контейнеры не не только не являются заменой виртуальным машинам, но и в некоторых окружениях зависят от них. Всё потому, что контейнер – не полноценная «форма жизни». Он представляет собой сконфигурированное окружение с приложениями, процессами и зачастую даже собственной операционной системой, но у него нет своего ядра. Более того, контейнер должен быть где-то запущен, и в большинстве случаев местом его запуска становится виртуальная машина. Говоря же «виртуальная машина», большинство специалистов сегодня имеет в виду OpenStack.

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

Сначала появился nova-docker – как попытка создать драйвер Docker гипервизора для Nova, вычислительного сервиса OpenStack. Но контейнеры – не виртуальные машины, они не взаимозаменяемы. Поняв, что Nova API плохо подходит для контейнерной архитектуры, сообщество двинулось в другом направлении.

Когда Google выпустил систему управления контейнерами Kubernetes, основанную на их внутреннем оркестраторе Borg, произошло следующее. Команда Murano, работающая над одноимённым каталогом приложений OpenStack, приняла вызов и добавила контейнеры в OpenStack, создав приложение Kubernetes для Murano. Оно дало разработчикам возможность создавать кластер Kubernetes в их облаке OpenStack с помощью панели управления Murano. Что, в свою очередь, немало упростило процесс: разработчики смогли пользоваться Kubernetes на OpenStack и, что ещё важнее, создавать на основе Kubernetes/Docker приложения, которые легко устанавливаются конечными пользователями.

 Тем временем контейнерная лихорадка распространялась как пожар, и сообщество OpenStack решило, что настало время сделать контейнеры «полноправными членами» OpenStack наряду с виртуальными машинами и bare metall серверами. Для того, чтобы встроить контейнеры в OpenStack, был создан контейнерный сервис OpenStack Magnum, объединивший возможности обеих платформ. Он позволяет пользователям создавать «нишу», в которую имплементируются контейнеры. Такие ниши могут оркестрироваться через Kubernetes, Docker Swarm или Mesos, что разработчики могут гибко варьировать.

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

 Но если вы разрабатываете контейнерные приложения на OpenStack, какой путь стоит выбрать? Murano? Magnum? Что-то еще?

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

 Использование инструмента управления конфигурациями: например, Puppet или Ansible
Наиболее очевидным способом работы с контейнерами в OpenStack является использование инструмента управления конфигурациями. Примеры таких инструментов - Puppet или Ansible. Они применяются, чтобы запрашивать и конфигурировать ресурсы, на которых будут запущены ваши контейнерные приложения. В этом случае указанные инструменты задействованы главным образом для настройки виртуальных машин, а также групп безопасности, сетей, Kubernetes или другого оркестратора на этих машинах, настройки вашего приложения и так далее.

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

 Однако из основного преимущества данного метода проистекает и его главный недостаток: вся ответственность за принятие решений остаётся на вас. Это значит, что развертывание конечного приложения - это не то, что вы с лёгкостью можете поручить конечным пользователям. Более того, с такой задачей не справится и рядовой разработчик, потому что это работа для dev/ops, требующая глубокого знания всего происходящего в облаке.

 Конечно, для некоторых организаций это не обязательно является препятствием. Но описанный метод лучше всего подходит тем из них, которые всё ещё делают всё «по старинке»: когда сначала ИТ служба развёртывает приложение, а затем создаёт для пользователей точки входа в него (в противовес самообслуживанию пользователей).

 Использование сервиса Magnum для развертывания контейнерного окружения
На порядок проще с точки зрения менеджмента – модель развертывания с помощью сервиса OpenStack Magnum. В отличие от Puppet или другого подобного инструмента, Magnum делает использование контейнеров в OpenStack проще, так что вам не придётся настраивать всё самим.
Вместо этого вы можете использовать Magnum API, чтобы создавать нишу, в которую устанавливаются контейнеры. Magnum взаимодействует с системой оркестрации контейнера для создания окружения и управления им, так что вам не придётся волноваться о таких аспектах проекта, как создание ВМ, управление сетями и так далее. В настоящее время Magnum предоставляет возможность использовать Kubernetes, Docker Swarm или Mesos в качестве оркестраторов после настройки приложения.

 Использование Magnum требует меньшего контроля со стороны администратора, но всё же он необходим, чтобы решить, сколько и каких ниш должно быть создано под контейнеры и так далее. Поскольку OpenStack сам отвечает за развёртывание, этот сервис намного удобнее, чем первый вариант. Но в данном случае он всё ещё является инструментом для dev/ops, а не для конечных пользователей, несмотря на появляющийся UI.

 Рассматриваемая модель наилучшим образом подходит разработчикам, которые создают контейнерные приложения, не нуждающиеся в установке конечными пользователями. А также тем, кому необходимы функции, которых в Murano ещё нет. К ним относятся балансировщик нагрузки Kubernetes, который предоставляет услуги внешним сетям, и TLS сертификаты, обеспечивающие безопасность взаимодействия между сервером и клиентами, а также сервисы Magnum и Kubernetes, работающие в нишах.

 Использование каталога приложений Murano для развертывания контейнерного окружения
Выбирая этот путь, нужно понимать, что сам по себе Murano не является контейнерным окружением. Это каталог приложений, который содержит Kubernetes для развёртывания контейнеров.
Преимущество его использования, однако, состоит в том, что как у разработчика у вас не только не будет необходимости управлять Kubernetes (хотя вы можете это делать), но и появится возможность создавать приложения на базе Kubernetes, которые могут быть легко установлены пользователем. На самом деле пользователи могут даже не подозревать, что приложение работает на базе контейнеров. Им достаточно знать, что они обратились к приложению и оно оказалось доступно. Murano берёт на себя всё внутреннее резервирование для них, основываясь на тех предпочтениях, которые были установлены посредством удобного и понятного пользовательского интерфейса.
Murano – оптимальный выбор для разработчиков, создающих приложения для других пользователей, которые будут работать в режиме самообслуживания.

 Что мы имеем?
В настоящий момент команды обоих проектов работают над совместным выпуском приложения Magnum для Murano. Оно позволит разработчикам сочетать простоту и удобство Murano и обширный инструментарий Magnum, включая доступ к оркестраторам посредством Kubernetes. 

Статья переведена специалистами "Сервионики", оригинал находится здесь, прокомментировать публикацию вы можете на страницах Сервионики и i-Oblako в Facebook.

Назад к разделу "Публикации"