Puppet

Глава 18 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: Puppet
Автор: Luke Kanies
Перевод: А.Панин

18.4. Инфраструктура

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

Плагины

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

Это позволяет значительно усовершенствовать агенты Puppet без изменения основных пакетов Puppet. Данная возможность особенно полезна при использовании специализированных установок Puppet.

Фреймворк Indirector

Вы наверняка уже поняли, что у нас существует традиция некорректного именования классов Puppet и, по мнению множества людей, этот случай заслуживает награды. Indirector является относительно стандартным фреймворком, построенным на основе принципа инверсии управления, со значительными возможностями расширения функций. Системы, созданные на основе принципа инверсии управления, позволяют отделить развертываемые функции от метода управления используемыми функциями. В случае Puppet это обстоятельство позволяет нам работать с множеством плагинов, предоставляющих различные функции, предназначенными для таких целей, как доступ к компилятору по протоколу HTTP или его загрузка в процессе работы, а также осуществлять переключение между ними при помощи небольших изменений конфигурации вместо вмешательства в код. Другими словами, фреймворк Indirector из состава Puppet является реализацией шаблона проектирования "service locator", описанного на странице Wikipedia с названием "Инверсия управления". Все взаимодействия одного класса с другим осуществляются посредством фреймворка Indirector с применением похожего на REST интерфейса (т.е., мы поддерживаем методы find, search, save и destroy), при этом переключение режима работы Puppet с бессерверного на клиент/серверный - в большей степени вопрос конфигурации агента таким образом, чтобы он использовал протокол HTTP в качестве конечной точки для получения каталога вместо конечной точки для доступа к компилятору.

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

Сетевые взаимодействия

Прототип Puppet был разработан летом 2004 года, когда главным вопросом относительно сетевого взаимодействия был вопрос о том, следует ли использовать XMLRPC или SOAP, Мы выбрали XMLRPC и этот протокол работал хорошо, но мы столкнулись с большей частью проблем, известных всем другим его пользователям: он не обуславливал использование стандартных интерфейсов для взаимодействия компонентов и в результате очень быстро приобрел излишнюю сложность. Мы также столкнулись со значительными проблемами в отношении использования памяти, так как кодирование данных для использования протокола XMLRPC подразумевало то, что каждый объект как минимум несколько раз размещался в памяти, что очень скоро привело к значительным затратам памяти при работе с файлами большого объема.

В рамках релиза 0.25 (работа над которым началась в 2008 году) мы начали процесс перевода всех сетевых взаимодействий на использование похожей на REST модели, но мы выбрали значительно более запутанный путь, чем простое изменение метода сетевого взаимодействия. Мы разработали фреймворк Indirector для использования в качестве стандартного фреймворка для межкомпонентного взаимодействия и сделали конечные точки REST одним из возможных вариантов осуществления этого взаимодействия. Реализация полной поддержки REST растянулась на два релиза и мы пока не до конца преобразовали код для использования формата JSON (вместо YAML) во всех операциях сериализации. Мы предприняли переход к использованию JSON по двум основным причинам: во-первых, обработка структур формата YAML средствами языка Ruby происходит очень медленно, при этом обработка структур формата JSON происходит значительно быстрее; во-вторых, большая часть веб-приложений переходит на использование JSON и наблюдается тенденция создания более переносимых реализаций библиотек для работы с форматом JSON в отличие от формата YAML. Конечно же, в случае проекта Puppet первые варианты данных в формате YAML не были переносимы между языками, а также обычно не были переносимы между различными версиями Puppet, так как они в основном создавались в результате сериализациии внутренних объектов Ruby.

В нашем следующем основном релизе Puppet мы наконец окончательно удалим код поддержки протокола XMLRPC.

Далее: Выученные уроки