Пока патентные войны остаются скрытой угрозой для экосистемы OpenStack, давайте поговорим о технологии, позволяющей разворачивать OpenStack практически в один клик. Название этого проекта многократно встречалось в постах нашего блога, но не было ни одного текста, посвященного именно Fuel. Между тем — именно этот проект существенно упростил процедуру развертывания OpenStack и сделал менее трудоемким процесс дальнейшего управления облаком. Безусловно, можно действовать по старинке. Использование Fuel не является обязательным для работы с OpenStack. Однако мы считаем, что если театр начинается с вешалки, то OpenStack начинается с Fuel. По крайней мере — Mirantis OpenStack (MOS).
Несколько общих слов про Fuel
Fuel — это инструмент развертывания OpenStack и последующего управления облаком. Трудно назвать проект, который давал бы больше информационных поводов. Вот сейчас мы рассказываем вам о том, что Fuel теперь использует Docker-контейнеры, но уже знаем о запуске поддерджки плагинов. И все-таки сперва поговорим о контейнерах. В преддверии первого российского Docker-митапа такой разговор более чем оправдан.
Те из вас, кто уже попробовал OpenStack (мы ведь не просто так рассказываем вам о том, что это такое, но надеемся убедить вас потратить время на эксперименты с технологией, которая два года назад привлекла наше внимание и не отпускает его до сих пор), могли убедиться, что установка вручную — дело трудоемкое, сложное и, главное, чреватое большим количеством ошибок. Fuel — наш ответ проблемам ручного развертывания. Это интуитивно понятный инструмент, оснащенный пользовательским веб-интерфейсом, который, по сути, является панелью управления для развертывания облака в несколько кликов и дальнейшей работы с ним. Важно отметить, что Fuel упрощает масштабное (на сегодняшний день протестировано развертывание на окружение из 100 нод) развертывание, тестирование и поддержку конфигураций OpenStack. Будучи одним из проектов экосистемы OpenStack, проект Fuel не связан с каким-то конкретным брендом (даже с нашим).
Мы еще не один раз вернемся к этой разработке. А сейчас давайте поговорим про Docker.
Docker: экономия сил и времени
Начиная с версии MOS 5.0 компания Mirantis сделала ставку на Docker для того, чтобы реализовать простое и надежное транзакционное обновление Fuel: поднимаем новые контейнеры, проверяем, а если что-то пошло не так, возвращаем старые.Вместе с простотой пришла и скорость. Расскажем о том, как это было.
Ретроспектива
MOS 5.0
Сделанные нами изменения позволили пользователю повторно развернуть Fuel менее чем за 30 секунд без применения скриптов для возврата окружения в исходное состояние. Появилась возможность вносить изменения, оперативно их тестировать и, при необходимости, многократно “откатываться” назад.
Оперативность изменений стала результатом использования «контейнеров», область применения которых, на самом деле, очень широка. Соответствующую среду можно создать на базе лэптопа с Mac OS X или Windows (с использованием boot2docker), на серверах QA под Ubuntu в облаке, а также на виртуальных машинах в реальных дата-центрах на базе Red Hat Enterprise Linux.
Для обновления приложения Fuel в Docker достаточно просто удалить старые контейнеры и запустить новые, сэкономив 1-2 часа, которые вам потребовались бы для повторной сборки Fuel ISO и тестирования сделанных изменений.
MOS 5.1
В Mirantis OpenStack 5.1 мы уменьшили время, требуемое для установки Fuel на мастер-ноду. При виртуализированном развертывании на SSD-диске время загрузки образов сократилось в два раза — с 18 минут до 9 минут, контейнеров — с 9 до 8 минут. При развертывании в лабе (на физических серверах) время загрузки образов в версии 5.1 уменьшилось на 20%.
Была идея использовать временное файловое хранилище (tmpfs) на мастер-ноде для сокращения времени установки, но мы выявили его ненадежность в средах с недостаточным объемом оперативной памяти, что замедляло процесс. В то время, как наша основная задача — выиграть время.
А вот стабильность Fuel в версии 5.1 повысить удалось, благодаря утилите dockerctl, отслеживающей активность настроек для Fuel в процессе обновления Docker, при котором передаются сотни параметров в 13 контейнерах. Утилита dockerctl особенно важна в свете того, что устанавливается большое количество соответствий для приложений, требующих 5-6 параметров из нашего конфигурационного файла (astute.yaml) для каждого контейнера, чтобы развернуть приложение.
Вместо etcd или иных инструментов, требующих применения systemd, мы использовали параметры astute.yaml, оставили локальный файл в формате YAML и выполнили запуск Puppet внутри контейнеров для развертывания приложений на мастер-ноде Fuel. Мы необязательно будем делать это в дальнейшем, но этот способ был более простым и менее разрушительным, чем использование других доступных средств. Как бы то ни было, у локального файла в формате YAML и Puppet было несколько недостатков, например, они способствовали установлению большого количества связей в Docker, что привело к большим затратам дисковых ресурсов для каждого контейнера из-за выполненной установки Puppet и зависимых модулей. Но даже при этом мы используем в работе одни из самых компактных полнофункциональных образов ОС Docker. Размер образа Docker на базе Ubuntu огромен, тогда как размер нашего образа на базе CentOS с установленным Puppet сжат до 39MB.
Status quo:MOS 6.0
Мы устранили ошибки в настройках Fuel и реализовали ротацию логов для высвобождения дискового пространства. Помимо этого, задавая системные требования для 6.0, мы учли проблему с утилитой logrotate, которая по умолчанию сохраняет пять последних архивов (для этого требуется несоразмерное дисковое пространство, при том, что Docker сам нуждается в дисковом пространстве для логов, которые могут заполнить все свободное пространство и обрушить файловую систему). У данной проблемы отсутствует автоматическое решение, поэтому даже с усовершенствованиями хранения логов, сделанными компанией Mirantis, вам все так же нужно будет отслеживать емкость диска, поскольку мы не можем предсказать, какой объем логов вы будете генерировать. Несмотря на то, что logrotate обновляет логи каждый час, она не отслеживает свободное дисковое пространство, а настройка, которая бы позволила увеличить размер папки с логами Docker, отсутствует. В действительности, настройки logrotate ограничивают размер одного log-файла, по достижении которого он архивируется. Поэтому даже с увеличенными параметрами следует выделить 30GB исключительно для логов (при развертывании на 20 нод). Но если включить режим отладки (Debug), ротация больших файлов будет происходить каждые 10 минут, а не каждый час.
К другим нововведениям для Fuel на базе Docker в Mirantis OpenStack 6.0 относится использование CentOS 6.5 в качестве операционной системы для мастер-ноды.
Поскольку в CentOS 6.5 нет демона инициализации systemd, который бы постоянно запускал сервисы, компания Mirantis использует утилиту управления Supervisor для запуска и отслеживания Docker-контейнеров, а также для запуска веб-приложений. “Два в одном”, как любят говорить рекламщики.
Кроме того, мы использум простую схему “try-or-fail” для решения
проблем с остановкой работы Docker-контейнеров, в которых нет унаследованных инструментов по отслеживанию зависимостей. В нашем решении, если Docker-контейнеры пытаются запуститься, а затем останавливаются из-за того, что PostgreSQL или RabbitMQ еще не запущен, Supervisor ждет несколько секунд и пытается снова запустить контейнер, запуск которого не удался, до тех пор, пока все контейнеры не будут запущены. Данный метод намного проще поддерживать, чем сложную последовательность ввода в действие контейнеров на основе приоритетов или
зависимостей. И, несмотря на то, что у dockerctl имеется надлежащая последовательность при запуске всех контейнеров, эта последовательность применяется только при начальном развертывании.
Еще раз обращаем внимание на то, что Fuel — это проект всей экосистемы OpenStack, так что вы можете использовать этот инструмент для развертывания, тестирования и поддержки вашей платформы OpenStack. Хотя, конечно, мы считаем, что проще всего получить его как часть дистрибутива Mirantis OpenStack. Все-таки за свой дистрибутив мы отвечаем и можем гарантировать, что его использование не нанесет ущерба репутации экосистемы в целом.
Первый Docker-ивент в Москве
Поскольку мы сами убедились в том, что Docker — инструмент полезный, хотим поделиться этим знанием. 26 февраля с 18:00 до 21:00 Mirantis участвует в первом митапе по Docker в Москве и приглашает желающих присоединиться. Участие бесплатное. Подробнее о мероприятии можно прочесть на сайте российского сообщества OpenStack, а зарегистрироваться можно здесь. Для желающих принять участие во встрече — регистрация обязательна.
Начнет встречу Фабрицио Соппельса (Fabrizio Soppelsa) — инженер нашей службы поддержки Fuel, автор Linux Journal и просто энтузиаст OpenStack. Он сформулирует краткое описание технологии Docker, расскажет, какие преимущества дает использование этой мощной платформы и что делает ее популярной среди разработчиков.
Дальше Мэтью Мосесон (Matthew Mosesohn) — старший разработчик в Mirantis. Мэтью расскажет про развертывание Docker “Off the Grid”. Кстати, именно на его пост в нашем корпоративном блоге, посвященный переходу Fuel на Docker, мы опирались при подготовке этого материала.
Денис Зайцев, руководитель группы эксплуатации облачной платформы и CDN в Яндексе, расскажет про масштабирование Docker Registry; про запуск Docker приложений в OpenStack-облаке с помощью Murano — Сергей Меликян, старший разработчик в Mirantis.
Завершит митап Андрей Вагин — разработчик в команде Linux Kernel компании Parallels. Его тема: “Libcontainer: объединяя усилия под одной крышей”. Андрей сделает описание планов и текущего статуса этой задачи.
У вас наверняка остались (или появились) вопросы. Ивент — самое правильное место, для того, чтобы их задать. Но если вы по каким-то причинам не попадаете на встречу, то пишите вопросы в комментах — мы постараемся призвать наших экспертов к ответу.
Автор: Mirantis_OpenStack
