эквивалент hiera_include для типов ресурсов

Я использую yumrepo встроенного типа. Я могу получить базовую интеграцию с hiera working

  yumrepo { hiera('yumrepo::name') :
    metadata_expire => hiera('yumrepo::metadata_expire'),
    descr           => hiera('yumrepo::descr'),
    gpgcheck        => hiera('yumrepo::gpgcheck'),
    http_caching    => hiera('yumrepo::http_caching'),
    baseurl         => hiera('yumrepo::baseurl'),
    enabled         => hiera('yumrepo::enabled'),
  }

Если я попытаюсь удалить это определение и вместо этого сделаю hiera_include('classes'), вот что у меня в соответствующем бэкэнде yaml

classes:
 - "yumrepo"

yumrepo::metadata_expire: 0
yumrepo::descr: "custom repository"
yumrepo::gpgcheck: 0
yumrepo::http_caching: none
yumrepo::baseurl: "http://myserver/custom-repo/$basearch"
yumrepo::enabled: 1

Я получаю эту ошибку на агенте

Ошибка 400 на сервере: не удалось найти класс yumrepo

Я думаю, вы не можете уйти от какого-то минимального объявления узла с типами ресурсов и иерархией? Может быть hiera_hash путь?

Я попытался это сделать, но возникла синтаксическая ошибка.

  yumrepo { 'hnav-development':
    hiera_hash('yumrepo')
  }

puppet hiera

Я закончил использовать create_resources. По сути, он предоставляет возможность отображать определенные типы к узлам с hiera, примерно так же hiera_include делает с классами из коробки.

При такой настройке я могу объявить любое количество file типы ресурсов на любом уровне иерархии, плюс вся конфигурация находится в источниках данных hiera.

/etc/hiera.yaml

:hierarchy:
  - defaults
  - "%{environment}"

/var/lib/hiera/defaults.yaml

classes:
  - hiera_file_wrapper
hiera_file:
    hiera-two:
       path: /home/quickshiftin/hiera-two
       ensure: file
       content: 'Hiera two'

/var/lib/hiera/production.yaml

hiera_file:
    hiera-baby:
       path: /home/quickshiftin/hiera-baby
       ensure: file
       content: 'Hiera baby!

модули / hiera_file_wrapper / манифесты / init.pp

class hiera_file_wrapper()
{
    create_resources(file, hiera_hash('hiera_file'))
}

манифесты / site.pp

hiera_include('classes')

поскольку yumrepo это тип ресурса, а не класс, который работать не будет.

Я бы сказал, поместил класс в названный yumrepo_myreponame и пусть он объявит yumrepo ресурс. Для этого вы можете поместить параметры класса в Hiera, если вам нужно, а затем передать их в объявление ресурса.

Например, у меня есть модуль включения EPEL для сервера, который можно поставить в его Hiera classes массив, чтобы включить его. Все его содержание:

class epel_yumrepo {
  yumrepo { "epel":
    descr          => 'Extra Packages for Enterprise Linux 6 - $basearch',
    enabled        => 1,
    gpgcheck       => 1,
    gpgkey         => 'http://download.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-6',
    mirrorlist     => 'https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch',
    failovermethod => "priority",
  }
}

Предположим, у вас есть репозиторий yum с именем hnav, и вам нужно, чтобы у него был другой URL-адрес в зависимости от того, какую версию ОС вы используете, 5 или 6.

Вы настроили свою иерархию в /etc/puppet/hiera.yaml лайк

:hierarchy:
- "%{::operatingsystemmajrelease}"
- common

Таким образом, hiera сначала будет искать файл yaml, названный в честь версии ОС, 5.yaml или 6.yaml. Если он не найдет там значения, он будет искать в common.yaml.

Вы написали параметризованный класс, чтобы hiera могла автоматически указывать URL-адрес.

модули / hnav / manifest.init.pp

class hnav ( $url ) {
  yumrepo { 'hnav':
    enabled => true,
    baseurl => $url
  }
}

Если по какой-то причине вам не нравились параметризованные классы, вы могли бы написать приведенное выше как

class hnav {
  yumrepo { 'hnav':
    enabled => true,
    baseurl => hiera('hnav::url')
  }
}

Затем вы настроили классы, которые вы хотели применить ко всем вашим узлам.

common.yaml

classes:
  - hnav

И вы устанавливаете значения для URL

5.yaml

hnav::url: http://example.com.yum/5/

6.yaml

hnav::url: http://example.com.yum/6/

Это действительно искусственный пример, но, возможно, он поможет вам понять, где используется hiera.

Я создал функциональность hiera_manifest на своей работе. По сути, он позволяет вам вызывать модули, классы, параметры и определенные типы через hiera yaml.

Я просто разместил это на Github, чтобы поделиться: https://github.com/mlbam/hiera_manifest

Это дает небольшие преимущества в том, что параметры также устанавливаются во время вызова модуля, класса или типа.

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