Есть ли ограничение в отношениях?
У нас есть несколько модулей Puppet, которые зависят друг от друга (или, по крайней мере, зависят от своих пакетов).
Я спрашиваю об этом, потому что теперь, когда я хотел подписаться на некоторые службы для перезапуска, если зависимость обновится.
Проблема:
Error: Failed to apply catalog: Could not find dependency Package[shibbolethsp] for Package[httpd] at /etc/puppetlabs/code/environments/development/modules/apache/manifests/instance.pp:39
Модули:
# Module someco-httpd, init.pp
package['httpd'] {
...
require => Package['openssl','shibbolethsp'] # can find openssl but NOT shibbolethsp
}
# Module someco-openssl, init.pp
package['openssl'] {
...
}
# Module someco-shibbolethsp, init.pp
package['shibbolethsp'] {
...
}
Ресурс Package[shibbolethsp]
присутствует, потому что, если я удалю пакет и снова запущу марионетку, я вижу, что она будет установлена, но если я также хочу настроить Apache (который требует, чтобы Package[shibbolethsp]
функционировал должным образом), Puppet не работает.
Итак, ресурс присутствует, но Puppet не может решить их должным образом, я полагаю? Такое же отношение к Package[openssl]
работает как ожидалось и перезапуск Apache, если openssl обновлен до новой версии ...
Это проблема упорядочивания / многопоточности? Одни отношения работают, другие нет ...
Привет @Jon! Большое спасибо за Ваш ответ! Да, пакет ´shibbolethsp´ находится в нашем репозитории, он также будет установлен, если я удалю наш "перезапуск при обновлении зависимостей - логика" ... Пакет - это наш собственный встроенный RPM в нашем собственном репозитории YUM ... они существуют, они будут установлены, если настроены без отношения "require => bla". вся ошибка возникает во время компиляции каталога ...
В этом случае вам, вероятно, просто нужно сделать пакет shibbolethsp
зависимым от установки конфигурации yum.repos.d
. Я предполагаю, что Puppet просто пытается выполнить их в неправильном порядке и не может найти пакет shib.
Еще одна вещь - необычный синтаксис вашего ресурса. Вместо package['name'] { }
используется идиома package { 'name': }
. Это, вероятно, не имеет значения, но я раньше не видел этого использования и должен был проверить это в документации!
Какая у вас версия puppet
? Моя версия 4.10.12 даже не компилирует объявления стиля package['httpd']
:-) Вылетает с ошибкой о строковых индексах.
@Jon да, вы правы насчет синтаксиса, конечно, это "package {'name':}" Я просто писал быстро и забыл о синтаксисе здесь, но вы можете быть уверены, что я использую правильный синтаксис в своем модуле :). Мы используем Puppet 4.10, который поставляется с Red Hat Satellite 6.3. ваше предположение с репозиторием yum к этому не относится, потому что ВСЕ наши пакеты происходят из одного репо yum (наше собственное репо с нашими собственными встроенными RPM). Для меня с 6 месяцами полной разработки Puppet кажется, что это 100% марионеточная ошибка или недокументированное поведение ...
@Jon Наблюдаемое поведение не наблюдалось бы, если бы пакет shibbolethsp
не находился в доступном репозитории пакетов. Это проблема чисто марионеточного парсера.
@Pali Не могли бы вы поделиться содержимым classes.txt
внутри cachedir
puppet.com/docs/puppet/4.10/…? Это будет для узла, который применяет каталог, который вы описываете выше.
текущее содержимое: настройки puppetdev-d00 module_global_settings java
@Jon см. Мой собственный ответ для решения
The resource
Package[shibbolethsp]
IS present because if I remove the package and run puppet again I can see that it gets installed,
Ваше наблюдение не подтверждает вывод.
Во-первых, вполне возможно, что пакет будет установлен в результате запуска Puppet, даже если в каталоге нет ресурса Package
для него. Фактически, это происходит постоянно. Он управляется зависимостями, выраженными в самих пакетах, где менеджер пакетов (Yum, apt, так далее.) Определяет зависимости пакета, который он устанавливает, и организует их установку. Puppet не понимает этого.
Во-вторых, вполне возможно, что Package[shibbolethsp]
будет объявлен в каталоге для одного узла, но не в каталоге для другого узла. Естественно, если вы удалите shibbolethsp
с узла первого типа, Puppet переустановит его при следующем запуске. Это никоим образом не свидетельствует о том, что пакет объявлен в каталоге другого узла.
but if I also want to configure Apache (which requires
Package[shibbolethsp]
to function properly) Puppet fails.
Это говорит мне, что нет, вы нет объявляете Package[shibbolethsp]
в каталоге затронутого узла, несмотря на ваши возражения об обратном.
So the resource is present but Puppet can't resolve them properly I guess? The same relationship to
Package[openssl]
works as expected and Apache restarts if openssl updated to a new version ...
Я не вижу причин думать, что эти отношения не работают так, как ожидалось должно быть, но я подозреваю, что у вас неверные ожидания.
Во-первых, отношения ресурсов и классов Puppet связаны с зависимостями порядок подачи заявки. Например. File[/etc/foo.conf]
должен быть обновлен до того, как Service[foo]
будет управляться потому что в противном случае служба foo не может быть переведена в правильное состояние. Это в значительной степени, хотя и не полностью, отдельно от функциональной зависимости между управляемыми компонентами.
Во-вторых, я думаю, вы предполагаете, что ваши отношения require
между ресурсами Package
приведут к объявлению требуемых Package
в случае объявления их requirer. Это совершенно неверно. Опять же, отношения ресурсов Puppet связаны с порядком применения. Puppet не может автоматически объявлять ресурсы require
d, потому что он полагается на то, что вы укажете ему, какие свойства у них есть, а также потому, что это может создать серьезный риск дублирования объявлений.
В целом, редко бывает полезно объявлять отношения между ресурсами Package
на уровне Puppet, поскольку функциональные зависимости между пакетами лучше всего обрабатываются на уровне пакета / диспетчера пакетов, и обычно нет никаких других зависимостей добросовестный порядка приложения между парами. пакетов.
Если вы хотите, чтобы shibboleth находился на машинах, на которых установлен Apache, вам необходимо убедиться, что объявлен соответствующий класс. У вас также может быть некоторый порядок рассмотрения приложений на уровне, отличном от пакетов - например, вам может потребоваться убедиться, что Shibboleth установлен, прежде чем вы начнете управлять Apache услуга, и, возможно, вы также захотите перезапустить службу, если когда-либо shibboleth пакет или конфигурация обновлены. Лучше всего это устроить на уровне класса, а не в объявлениях отдельных ресурсов.
Например, класс модуля httpd
для модуля someco-httpd может включать что-то вроде этого:
# Nodes to which this class is applied require class ::shibbolethsp to be applied first
require '::shibbolethsp'
В отличие от метапараметра require
ресурсов, который вызывает оценку именованного класса, shibbolethsp
(предположительно, создает объявление Package[shibbolethsp]
, среди прочего), а также создает отношение порядка приложений, так что класс shibbolethsp
применяется первым. И снова, порядок приложения не предназначен для установления отношения пакет / пакет, а скорее для более общего отношения класса / класса, которое охватывает зависимость httpd
услуга от наличия установленного и настроенного shibboleth.
1. Мы сами собираем пакеты RPM (все). у них нет никакой зависимости ни в одном RPM, который установил бы shibbolethsp, его может установить только Puppet 2. весь ваш ответ бесполезен для меня, потому что вы выражаете мне официальную документацию ... вся проблема, похоже, связана с заказом во время компиляции или что еще ... 3. Все это работает для OpenSSL, но не для Shibboleth SP, поэтому я понятия не имею, что вы хотите мне сказать: /
@Pali, я обобщаю для вас соответствующие части официальной документации, потому что в этом отношении документация - точный. Извините, если это не то, что вы хотели услышать, но это правда. Если вы думаете, что наблюдаете другое поведение, вам следует уменьшить его до минимальный воспроизводимый пример, которое вы можете указать в своем вопросе. Скорее всего, вы сами решите проблему таким образом, но если вы этого не сделаете, мы сможем это сделать.
Я пытаюсь получить минимальный воспроизводимый пример, но что, если проблема возникает только в больших конфигурациях марионеток? все, что я могу вам сказать, это то, что я действительно наблюдаю странное, недокументированное поведение ... Я попытаюсь еще раз получить рабочий "плохой" пример на следующей неделе и дать вам знать о нем ...
Проблема заключается в межмодульных зависимостях. Ресурсы в других модулях находятся в другом пространстве имен, чем текущий модуль. Поэтому, если вы зависите от ресурса из другого модуля, вы должны использовать полный путь, например Other_module::Other_class_or_defined_type['bla']
или используйте require Other_module
в своих init.pp
, чтобы обеспечить правильный заказ!
ПРИМЕЧАНИЕ: в site.pp
вы должны определять ресурсы в их правильном порядке!
Вы уверены, что
shibbolethsp
находится в ваших репозиториях пакетов? Shibboleth не является типичным пакетом, поэтому вам придется либо загрузить и установить его вручную, либо добавить содержащий его репозиторий. Кроме того, быстрый Google не показывает пакет под названиемshibbolethsp
. Вы уверены, что это неshibboleth
илиshibboleth-sp
?