Это определенно относится к коду Puppet, у вас есть классы Puppet для инкапсуляции функциональности и модули, которые группируют классы для повторного использования и перераспределения. Модули могут быть повторно использованы из репозиториев git или из Puppet Forge , веб-архива tarballed модулей таким же образом, что и репозитории rpm или maven. Модули в forge определяются поставщиком, именем и версией модуля, во многом как Maid groupid, artifactid и version, и поставщик имеет полный контроль над модулями, которые могут быть опубликованы под его именем, с более открытым подходом, как любой может Загрузите что-нибудь сами через веб-сайт Forge, просто зарегистрируйтесь и начните загружать их.

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

Есть несколько вариантов на самом деле

• Git субмодули . Это версия для бедного человека, в которой вы добавляете репозитории git других модулей в качестве подмодулей git и используете команды init и update git submodule, чтобы оставаться в курсе
• Кукольный модуль инструмента . Позволяет устанавливать модули из кузницы Puppet в зависимости от имени поставщика / имени и версии модуля. Он загрузит и распакует модуль в указанный каталог
• Библиотекарь-марионетка . Это является продолжением рубина Bundler модели для установки драгоценных камней, имея файл , который определяет вашу зависимость, Gemfile в случае Bundler, Puppetfile в случае библиотекарь и .lock файл с устраненными зависимостями.

Модель разрешения отличается от моделей yum, apt-get или maven, которые разрешают зависимости при каждом запуске на клиенте, полагаясь на то, что клиенты последовательно делают это на версиях и машинах. В модели компоновщика или библиотекаря разрешение происходит только один раз и сохраняется в файле блокировки, который используется клиентами до тех пор, пока не будут изменены зависимости.

Декларация зависимостей

Библиотекарь Puppetfile позволяет определять зависимости модулей из нескольких источников.

Кукольный Кузница

Используя провайдера forge и имя модуля, а также, при необходимости, версию, он вызывает инструмент puppet module для извлечения архива и его извлечения в разработанном каталоге.

mod "maestrodev/maven", "1.0.0"

Гит

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

mod "maven",
  :git => "https://github.com/maestrodev/puppet-maven.git",
  :ref => 'v1.0.0'

Путь к папкам

Полезно в основном для тестирования или при переходе к модели полной зависимости, локальные пути могут использоваться как модули

mod 'mymodule', :path => './private/mymodule'

Улучшения и проблемы

Библиотекарь предлагает несколько улучшений по сравнению с модулем кукольного модуля. Помимо возможности загружать модули из разных источников, библиотекарь блокирует версии используемых модулей, что необходимо для последовательного воспроизведения результатов. Допустим, вы определяете зависимость от модуля maestrodev / maven > 1.0.0. Если вы запустите его сейчас, библиотекарь заблокирует версию до 1.0.0. Если версия 1.1.0 будет выпущена позже, ваши зависимости останутся прежними. Если вы попытаетесь запустить инструмент модуля Puppet с

puppet module install maestrodev-maven

Вы бы закончили с 1.0.0 сейчас и более новой версией позже.

Есть некоторые проблемы, и мы их решаем (и исправляем!). У нас есть ветвь исходного проекта, в которой мы продолжаем обновлять ветку maestrodev, пока наши запросы на получение не попадают в исходное хранилище . К сожалению, некоторые из патчей сидели там слишком долго, и мы пошли дальше и создали драгоценный камень библиотекарь-кукольный-маэстродев, который вы можете использовать вместо оригинального.

Некоторые из проблем, которые вы, вероятно, обнаружите, — это несоответствие между соглашениями о версиях Puppet Module и версиями Gem. Библиотекарь использует механизм разрешения бандлеровского гемфайла, который не принимает некоторые версии, такие как версии, включающие тире 1.0-rc1, или тип зависимостей модуля puppet 1.x, который наш библиотекарь адекватно преобразует в ~> 1.0 вместо сбоя. Ознакомьтесь с политиками версий rubygems для более подробной информации.

В следующей статье я расскажу о том, как использовать библиотекаря в сочетании с помощником спецификаций puppetlabs, чтобы сделать тестирование ваших кукол намного проще и последовательнее, и я расскажу об этой теме в своем следующем докладе о непрерывной доставке в ApacheCon Portland в феврале, плюс вы найди меня в следующий понедельник, 28-го на встрече DevOps в Лос-Анджелесе и на DevOps Days LA 22 февраля в рамках конференции SCALE.