Наверно. Пытаюсь границы передвинуть что ли. Как раньше делали - работало, но болело

Пока я думаю (стокгольмский синдром), что паппетом всё збс, но мы (я) неправильно всё организовали. Ну это всегда любыми инструментами так наверно

Но вдруг это у нас всё было странно, другие большие конторы делают всё как дока завещала, и им ок?)

А мы такие не в ногу. Нам, видите ли, жмёт там

То есть я начинаю подозревать, что правильно разделять ответственность/сущности - важнее, чем конкретный инструмент. Но звучит как менеджерсий буллшит, а мне кодить)

Не стоит, для клиентских машин, которые не все время  в сети, он не подходит. И я не говорил, что я Ansible не знаю. А с puppet я разберусь, не сразу, но разберусь

Там ты выше задавал вопрос, про организацию кода.
Лучше сразу посмотри паттерн https://puppet.com/docs/pe/2019.8/the_roles_and_profiles_method.html
Изучи hiera
Изучи enc

Если в кратце, есть код  (pp файлы), а есть параметры к нему в yaml (hiera). Классы ты можешь накидывать через тот же hiera.
То есть у тебя будет в site.pp только одна нода - default, в ней делаешь lookup классов из hiera и инклудишь
Что-то типо

node default {
  $lookup_behavior = lookup('classes_lookup_behavior')
  lookup('classes', Array[String], $lookup_behavior).include
}

Потому что задавать конфигурацию через site.pp для каждого хоста ты быстро устанешь

в ansible с группировкой хостов удобней, и это есть из коробки. В puppet тебе придется придумать свое решение.  Можно комбинировать ENC и hiera как угодно.

Обычно крутят на основе ENC (https://puppet.com/docs/puppet/6.17/nodes_external.html)
Там обычный скрипт выполняется,  его вызывает мастер когда агент к нему обращается, и он передает скрипту в качестве параметра имя агента
А он должен вернуть yaml (скрипт пишешь сам).

В этом yaml ты можешь возвращать classes, parameters, environment

Классы  - будут за инклудены, их можно отдавать сразу с параметрами.
environement будет переопределен. То есть на ноде был такой-то, если ENC вернет другой - то будет использован именно он
parameters - просто переменные которые доступны глобално

На основе parameters можно крутить группировку хостов.
Например ты в своем скрипте ENC можешь для хостов ^db.*$ возвращать
parameters:
 group: db

У тебя будет доступна переменная $group для этих хостов. Поэтому ты можешь в hiera.yaml указать например

- name: "groups"
  path: "groups/%{group}.yaml"

Тогда ты можешь создать файл groups/db.yaml - в котором будешь хранить параметры классов для хостов из группы db

У меня свой ямлик, который читается ENC скриптом, и там описаны группы и подобные вещи. То есть по сути это как бы inventory только своими силами. Ты в этом ENC можешь описать любую логику, ограничений нет. Например можно обращаться куда-то в API или в базу данных, если нужные какие-то хитрые штуки.

- name: "groups"
  path: "groups/%{group}.yaml"

ничего не мешает сделать тоже самое на кастомных фактах. Но факты можно подменить на сервере, поэтому не самое безопасное решение + ENC таки гибче, так как это не просто факт, а любая логика в целом + можно централизованно держать конфиг с тем, кому какие переменные назначать.

еще возможно после ansible ты привых, что у тебя доступны переменные всех хостов через hostvars. Тут так не выйдет, с этим все печально. Так как агент выполняется на хосте, и область видимости у него конечно только хост. Самый правильный наверное способ, просто прописать всю конфигурацию статично в hiera. Но возможно захочится магии.

Есть инструменты призванные решать эти проблемы.
Это экспортированые ресурсы и их коллекторы  (https://puppet.com/docs/puppet/6.19/lang_exported.html)

Механизм такой. На одном хосте экспортируешь ресурс например

@@file {'/etc/config'
  content => 'test'
}

А на другом хосте его можно собрать и применить
File <<| titile == '/etc/config'  |>>
То есть вот на этом хосте и будет создан файл /etc/config.

Можно цепляться по тегам

@@file {'/etc/config'
  content => 'test',
  tag => 'tag'
}

File <<| tag == 'tag'  |>>

Можно подменять аттрибуты

File <<| tag == 'tag'  |>> {
  owner => 'www-data',
  group => 'www'-data',
}

не "лучше", а "проще", например вложенных групп нет и подлбия хиеры не хватает часто

помимо этого можно доставть дофига всего из puppetdb. Например

$servers = puppetdb_query("nodes[certname] { facts { name = 'group' and value ~ 'db' } }") - все хосты с фактом group = db
Там на самом деле очень много всего есть: все ресурсы объявленные на хостах, факты, ноды, и т.д. (https://puppet.com/docs/puppetdb/latest/index.html)

На всякий случай: факты текущего хоста тащить из puppetdb не надо - они доступны просто через $facts

наверное да. порог входа как обычно =)

Наверное зря я про магию рассказал. Пока лучше не используй =)

проблема еще в доке на мой взгляд. Очень разрознено все. То есть по сути справочник. Узнал про это, и сам собираешь решение - конструктор. Не хватает рекомендаций, бест практик, примеров. Организация всех этих hiera и enc прост на удобство сильно влияет, было бы круто иметь обобщенное руководство как их сочетать с примерами. А подробности уже можно посмотреть в доке про каждого

Конечно не как в kubernetes. Хочешь посмотреть все поля доступные в конфиге kubeadm - идешь godoc и смотришь структуры данных golang =). Или написано включите фичагейт такой-то. И фиг пойми где его врубать kube-controller-manager или kube-apiserver или kube-scheduler или ваще kubelet.