Авторы: Александр Кислицкий, Евгения Шумахер, Вячеслав Струк, Илья Стечкин

Итак, вы просили рассказать о том, как делать плагины для Fuel. С радостью выполняем эту просьбу. Но говорить про “сферический плагин в вакууме” сложно и неинтересно. Поэтому мы решили взять для примера NFS-плагин и рассказать, как он создавался и тестировался.

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

В этой серии статей мы не претендуем на полноту инструкции — по формату материала мы не можем конкурировать с Fuel Plugin SDK. Но у данного текста есть несколько существенных преимуществ. Во-первых, он на русском языке. Во-вторых, он подробно описывает историю создания конкретного плагина, то есть у вас есть возможность вместе с разработчиком, Александром Кислицким, пройти весь путь от начала до конца. И, наконец, в третьих, если что-то окажется неясным, вы всегда можете задать нам вопросы в комментах и мы постараемся дать исчерпывающие ответы. Итак, доброй охоты!

Есть и несколько недостатков. Главная проблема в том, что эта серия статей основана на опыте создания плагина для Fuel версии 6.0. А актуальной версией сейчас является 6.1. Однако совсем скоро 6.1 устареет, ее сменит 7.0. Другими словами, Fuel Pluggable framework — это живой организм, который растет и улучшается, и у которого есть определенные ограничения. Они меняются от версии к версие. Так что в тот момент, когда вы будете читать этот текст, он уже слегка устареет. Но ссылки, которые даны в статье, позволят читателям актуализировать материалы самостоятельно.

Какие бывают плагины для Fuel?

В большинстве случаев вы будет использовать плагины для того, чтобы расширить функционал таких элементов OpenStack как:

1. Compute
2. Network
3. Storage
4. Operations (logging, monitoring, security)

С помощью плагинов можно создавать, например, альтернативные бэкенды для этих компонентов, или решать задачи по мониторингу облака: LMA Collector устанавливается на такие ноды, как controller, compute и storage nodes. Этот модуль собирает логи, метрики и уведомления от различных сервисов экосистемы OpenStack и пересылает эту информацию на такие внешние бэкенды баз данных как ElasticSearch и InfluxDB. Или Zabbix — плагин. Этот плагин устанавливает Zabbix, одно из самых популярных решений для мониторинга уровня предприятия, созданных на основе открытого кода. Полный список актуальных плагинов вы можете найти здесь. Обращаем ваше внимание, что корректно они работают для Fuel 6.1. Мониторинг облака вообще модная тема. И мы постараемся вернуться к ней в следующих статьях.

Обратите внимание: каждый плагин, который вы создаете, следует хранить в отдельном репозитории. Мы рекомендуем использовать для этой цели StackForge (это инструмент, принятый среди разработчиков OpenStack. Подробнее о нем можно почитать здесь — текст на английском). Очень удобно иметь под руками все необходимое: и код, и спеки, и документацию… Хотя в нашем тестовом примере спеки и доков нет, мы все равно настоятельно рекомендуем их добавлять. Вот в плагине для Calico все сделано как надо. Другие разработчики скажут вам спасибо, поскольку смогут использовать Gerrit workflow для последовательной интеграции (CI) кода, обновлять плагин в соответствии с требованиями последующих релизов Mirantis OpenStack.

Структура плагина

Создаваемый плагин имеет следующий вид:

fuel_plugin_name/
├── deployment_scripts
│ └── deploy.sh
├── environment_config.yaml
├── metadata.yaml
├── pre_build_hook
├── repositories
│ ├── centos
│ └── ubuntu
└── tasks.yaml

Этот шаблон можно сгенерировать автоматически с помощью Fuel plugin builder. Руками эти файлы создавать нет нужды.

YAML — это простой язык для описания данных. Указанный формат позволяет ввести следующую информацию:

— tasks.yaml — данная переменная описывает когда, где и как нужно запустить скрипт
— metadata.yaml — устанавливает имя, версию и связи (см. пример metadata для fuel 6.1 тут) для вашего плагина
— environment_config.yaml — задает параметры, специфические для данного плагина, которые пользователь может устанавливать во вкладке “Настройки” инфтерфейса Fuel
— deployment_scripts — директория, в которую вы можете добавлять ваши bash-скрипты или puppet-манифесты.
— repositories — позволяет добавлять пакеты Ubuntu или CentOS, необходимые для работы плагина.

Какие таски поддерживает Fuel?

Fuel поддерживает таски “shell” и “puppet”, позволяет исполнять специфические shell-команды и Puppet-манифесты. Вот пример shell-таски:

# This task will be applied on controller nodes,
# here you can also specify several roles, for example
# ['cinder', 'compute'] will be applied only on
# cinder and compute nodes
— role: ['controller']
stage: post_deployment
type: shell
parameters:
cmd: ./deploy.sh
timeout: 42
# Task is applied for all roles
— role: '*'
stage: pre_deployment
type: shell
parameters:
cmd: echo all > /tmp/plugin.all
timeout: 42

В данном примере первая таска выполняет deploy.sh script.
./deploy.sh будет исполнен после развертывания так, как сформулировано в соответствующем описании.
Вторая таска создает /tmp/plugin.all file, с текстом 'all', то есть запускает команду «echo all > /tmp/plugin.all».

Исполнение заданий с помощью Puppet позволяет вам применять собственные Puppet-манифесты к OpenStack нодам, такие как:

1. Добавьте файл site.pp в deployment_scripts/puppet/manifests/ directory. puppet_manifest описывает путь к директории для манифеста, имеющего отношение к deployment_scripts
2. Вставьте все необходимые модули в deployment_scripts/puppet/modules директорию — puppet_modules определяют путь к директории для модулей, имеющих отношение к **deployment_scripts

Пример:

# Deployment will be applied on controllers only
— role: ['controller']
stage: post_deployment
type: puppet
parameters:
puppet_manifest: puppet/manifests/site.pp
puppet_modules: puppet/modules
timeout: 360

Fuel не использует Puppet Master. Вместо этого Fuel task executor копирует манифест из Fuel Master node и запускает команду 'puppet apply' на каждой выбранной ноде. Мы рекомендуем использовать Puppet tasks в ваших плагинах вместо того, чтобы запускать Puppet в shell tasks. Тех, кому интересна внутренняя архитектура Fuel, отправляем читать Fuel development documentation, так как эта информация выходит за рамки данной темы.

Тип создаваемого плагина не имеет принципиального значения — это не влияет на процесс разработки, он не изменится. После установки Fuel элементы плагина будут отображаться во вкладке “Настройки” (Settings).
К сожалению, текущая версия Fuel не позволяет гарантировать отображение полной информации о плагине. Сейчас информация о плагинах не отображается в Fuel Wizard, но отображается в Fuel Settings, поэтому бывает не очень удобно работать с точки зрения UX. Мы об этом знаем и работаем над тем, чтобы сделать процесс более комфортным. Сейчас если каких-то инструментов не хватает, можно воспользоваться CLI, который тоже не слишком дружествен к пользователям, но для админов, которые используют Fuel — то, что надо.
Еще раз напомним, что все детали, касающиеся форматирования задач вы можете получить в Fuel Plugin SDK. А мы переходим от общих вопросов непосредственно к процедуре создания плагина.

Продолжение следует…

Как сделать fuel-плагин (на примере NFS). Часть 1