Статьи

Кукольный: Руководство для начинающих (часть 4) ~ Где мои данные?

части «Руководства по концепции Puppet ~ Beginner», которые нужно прочитать до ~ 
Part # 1 : введение в puppet,  Part # 2 : введение в модули и  Part # 3 : модули и многое другое.


Концептуальное руководство для начинающих кукольных  (часть  4 )

Где мои данные?

Когда я запустил свой Puppet-ry, в примерах, которые я использовал, все данные конфигурации были спрятаны в коде манифестов DSL, люди пытались использовать наследование для передачи данных. Затем я увидел шаблон проектирования в марионеточных манифестах, не учитывающий отдельный манифест параметров для переменных конфигурации. Затем пришел поиск внешних данных через файлы CSV в качестве функции Puppet. Затем с улучшениями в кукольный и другие модули пришли вместе больше.

Ниже приведено несколько полезных способов использования отдельных источников данных в ваших манифестах.

Здесь мы увидим стили использования данных для Puppet Manifests, Extlookup CSV, Hiera, Plug-in Facts и PuppetDB.

params-манифест :

Это очень простой способ отделения данных от кода функциональности и предпочтительный способ для будущих типов данных с возрастающим набором значений. Это будет держать его отдельно от кода с момента запуска. Как только требование достигнет уровня, позволяющего изменить значение по отношению к предполагаемому в зависимости от среды / домена / fqdn / operatingsystem /, его можно извлечь любыми предпочтительными способами, указанными ниже и просто просмотренными здесь. Это позволит избежать изменения основного (вспомогательного) кода модуля.
[Gist-Set Externalize в Params Manifest: [a href = «https://gist.github.com/3683955» style = «text-художественное оформление: нет; цвет: rgb (136, 136, 136); семейство шрифтов: Грузия, Утопия, «Палатино Линотип», Палатино, с засечками, размер шрифта: 15px, высота строки: 21px, цвет фона: rgb (255, 249, 238); «] https://gist.github.com/ 3683955]

Допустим, вы предоставляете подмодуль httpd :: git для модуля httpd, размещая сгенерированный шаблонный файл конфигурации, используя данные, помещенные в параметрах …


« `

Файл: httpd / manifest / git.pp

включает подмодуль params для доступа к данным

# $ MODULEPATH / httpd / manifest / git.pp
  
класс httpd :: git {
  включить httpd :: params
 
  $ is_cgi = $ httpd :: params :: is_cgi
  $ path = $ httpd :: params :: path
  $ url = $ httpd :: params :: url
 
  файл {
    "$ {HTTPD :: PARAMS :: conf_path} /git.conf":
      обеспечить => «настоящее»,
      content => template ('httpd / mynode.conf.erb'),
  }
}

Файл: httpd / templates / mynode.conf.erb

# $ MODULEPATH / httpd / templates / mynode.conf.erb
 
Псевдоним <% = url%> <% = путь%>
 
<Directory <% = путь% >>
  <% if is_cgi%>
  Опции + ExecCGI
  AddHandler cgi-скрипт .cgi
  DirectoryIndex gitweb.cgi
  <% end%>
</ Directory>

Файл: httpd / manifest / params.pp на
самом деле это просто еще один субмодуль, предназначенный только для обработки данных

# $ MODULEPATH / httpd / manifest / params.pp
 
класс httpd :: params {
 
  $ conf_path = '/etc/httpd/conf.d/'
  $ is_cgi = true
  $ path = '/ var / www / git'
  $ url = '/ mygit'
}

Используйте это: run_puppet.sh

Puppet apply --modulepath = $ MODULEPATH -e "включить httpd :: git"

« `
_

extlookup-csv :

Если вы считаете, что ваши данные будут соответствовать формату (ключ, значение) CSV, извлекаемому из файлов данных, необходимо сообщить куклу, где нужно найти местоположение для файлов CSV, и получить значение, назначенное ему в этом файле. ,
Имена, данные этим CSV-файлам, будут иметь значение для Puppet при поиске значений из всех существующих CSV-файлов. Puppet должен быть задан порядок иерархии для этих имен файлов, чтобы искать ключ, и порядок может включать имена переменных.

Например, скажем, у вас есть CSV по имени HOSTNAME, ENVIRONMENT и общий файл с иерархией, указанной в соответствующем порядке. Затем Puppet сначала ищет запрашиваемый ключ в CSV от HOSTNAME, если не найден, ищет в именованном файле ENVIRONMENT и, не найдя его, переходит к поиску общего файла. Если он не находит ключ ни в одном из этих файлов, он возвращает значение по умолчанию, если оно указано в методе extlookup (key, default_value), подобном этому. Если значение по умолчанию также отсутствует, Puppet вызовет исключение, если значение не будет возвращено.

[Gist-Set Externalize в иерархические CSV-файлы:  https://gist.github.com/3684010  ]

Это тот же пример, что и для параметров с разновидностью ExtData. Здесь вы увидите «common.csv» файл внешних данных, предоставляющий набор значений по умолчанию. Тогда есть также  файл ‘env_testnode.csv’,  переопределяющий единственное требуемое измененное значение. Теперь, как и в файле «site.pp»  , приоритет файла  «env _% {environment}»  выше, чем  «common»«httpd :: git»  будет искать все значения сначала из  «env_testnode.csv»,  а если нет нашел там бы перейти к  ‘common.csv’ . Следовательно, в конечном итоге будет переопределено значение ‘httpd_git_url’  из  ‘env_testnode.csv’

# $ MANIFESTPATH ​​/ extdatadir / common.csv 
 
httpd_conf_dir, / и т.д. / HTTPD / conf.d
httpd_is_cgi, правда,
httpd_git_path, / вар / WWW / мерзавец
httpd_git_url, / mygit
# $ MANIFESTPATH ​​/ extdatadir / env_testnode.csv 
 
httpd_git_url, / testgit
# $ MODULEPATH / httpd / manifest / git.pp 
 
класс httpd :: git {
 
  $ conf_dir = extlookup ('httpd_conf_dir')
  $ is_cgi = extlookup ('httpd_is_cgi')
  $ path = extlookup ('httpd_git_path')
  $ url = extlookup ('httpd_git_url')
 
 
  файл {
    "$ {} Conf_dir /git.conf":
      обеспечить => «настоящее»,
      content => template ('httpd / mynode.conf.erb'),
  }
}
# $ MODULEPATH / httpd / templates / mynode.conf.erb 
 
Псевдоним <% = url%> <% = путь%>
 
<Directory <% = путь% >>
  <% if is_cgi === 'true'%> #, потому что из CSV любое (логическое) значение будет читаться как строка
  Опции + ExecCGI
  AddHandler cgi-скрипт .cgi
  DirectoryIndex gitweb.cgi
  <% end%>
</ Directory>
Puppet apply --environment = testnode --modulepath = $ MODULEPATH --manifestdir = $ MANIFESTPATH ​​$ MANIFESTPATH ​​/ site.pp
# $ MANIFESTPATH ​​/ site.pp
 
$ extlookup_datadir = "$ {settings :: manifestdir} / extdatadir"
$ extlookup_precedence = ["% {fqdn}", "env _% {environment}", "domain _% {domain}", "common"]
 
включить httpd :: git

« `

 Используемый здесь метод extlookup () доступен как  функция парсера Puppet , вы можете прочитать больше в  части # 5 пользовательских плагинов Puppet  о том, как создавать свои собственные функции
_


Hiera — это подключаемое иерархическое хранилище данных для Puppet. Он был начат для обеспечения лучшей поддержки внешнего хранения данных, чем функция Ext-lookup, с форматами данных, отличными от CSV.

В этом заключается сущность ENC для извлечения данных без необходимости их записи.

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

Это позволяет Puppet извлекать данные из различных внешних источников данных, используя разные бэкэнды (например, локальные файлы, redis, протокол http), к которым при необходимости можно добавить.

Бэкэнд «http», в свою очередь, обеспечивает поддержку хранилища данных из любого сервиса (couchdb,
riak , web-app или около того) для предоставления данных.


Файл »
hiera.yaml » из Gist ниже является примером конфигурации hiera, который нужно поместить в каталог конфигурации puppet. Основные моменты этой конфигурации: «: backends:», источник базы данных и «:ierarchy:». Можно одновременно использовать несколько бэкэндов, порядок их перечисления обозначает порядок поиска. Иерархия настраивает порядок поиска данных по областям.

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

Здесь мы видим конфигурацию для использования локальных файлов «yaml», «json». Поиск данных с сервера Redis (
он настроит наборы данных для использования redis для текущего примера ) с аутентификацией на месте. И искать данные с любого »
http«Сервис с иерархией в качестве„: контуры:“. Значение

Вы можете даже использовать 
GPG защищенные данные в качестве внутреннего интерфейса ., Но это немного неаккуратно для использования

. Размещение» .yaml «и» .json»от Gist на предполагаемом месте провайдера

запуск »
use_hiera.sh » заставит вас показать магию из этого примера на hiera.

: движки:
    - http
    - Redis
    - Ямл
    - JSON
 
: HTTP:
  : host: testnode.testenv.abk
  : порт: 5984
  : вывод: JSON
  : fail: изящный
  : путь:
    - /config/%ndom::hostname‹.json
    - /config/%ndom::fqdncasts.json
    - /config/%ndom::environment‹.json
    - /config/%ndom::operatingsystem rout.json
    - /config/common.json
 
: Redis:
    : пароль: my_redis_password
 
: YAML:
    : datadir: '/ etc / puppet / hieradata / yaml'
 
: JSON:
    : datadir: '/ etc / puppet / hieradata / json'
 
: Иерархия:
    -% {:: имя хоста}
    -% {:: fqdn}
    - %{::Окружающая среда}
    - %{::Операционная система}
    - обычный
 
: logger: console
{
  "message": "Лучше использовать PuppetDB.",
  "this_file": "/etc/puppet/hieradata/json/common.json"
}

---
public_data: "# создано в CentOS"
this_file: "/etc/puppet/hieradata/yaml/CentOS.yaml"

---
public_file: "/ tmp / note"
public_data: "# создано на любом узле"
this_file: "/etc/puppet/hieradata/yaml/common.yaml"

---

sed -i 's / ^ requirepass \ s * \ S * // g' /etc/redis.conf
 
REDIS_PASSWORD = 'my_redis_password'
echo "requirepass $ REDIS_PASSWORD" >> /etc/redis.conf
 
/ sbin / service redis перезапустить
 
redis-cli -a $ REDIS_PASSWORD << 'EOF'
  установить общий: secret_file /etc/local.keys
  Производство набора: секретный файл /etc/global.keys
  КЛЮЧИ *
EOF

---

{
  "secret_data": "все секретные ключи",
  "this_file": "http: //testnode.testenv.abk/config/mynode.json"
}

---

драгоценный камень установить иера иера-http иера-кукольный иера-редис
 
cat> site.pp << EOF
\ $ public_file = hiera ('public_file', '/ tmp / abc')
 
файл{
  \ $ Public_file:
    content => hiera ('public_data', 'a2z'),
    обеспечить => настоящее время,
}
 
\ $ secret_file = hiera ('secret_file', '/ tmp / cba')
 
файл{
  \ $ Secret_file:
    content => hiera ('secret_data', 'z2a'),
    обеспечить => настоящее время,
}
 
\ $ msg = hiera ('message', '')
извещение (\ $ сбщ)
EOF
 
кукольный применяется --environment = testnode site.pp

« `

[Gist-Set с использованием Hiera с настройкой Masterless Puppet: 
https://gist.github.com/abhishekkr/6133012  ]

_

плагин-факты :


Каждая система имеет свой собственный набор информационных факторов (
http://projects.puppetlabs.com/projects/facter ), по умолчанию предоставляемый марионеткам. Puppet также позволяет разработчикам DevOps устанавливать собственный модуль для использования в модулях.

Сила этих вычисляемых Facters заключается в том, что они могут использовать всю мощь ruby ​​для использования локальных / удаленных простых / зашифрованных данных через REST / Database / API / любой доступный канал.

Для этого требуются возможности пользовательских подключаемых модулей Puppet (
http://docs.puppetlabs.com/guides/custom_facts.html ). Файл ruby, выполняющий это, будет помещаться в ‘MODULE / lib / puppet / facter’ и загружаться в действии ‘pluginsync = true’.

Способ установить Facter в таком коде Ruby просто …


my_value = ‘весь код ruby ​​для его проверки’

Facter.add (mykey) do

  setcode do

    my_value

  end

end


….. весь остальной код должен вычислять значение для установки или даже набор ключей.

[Gist-Set Externalize Data, получающий как Facter: 
https://gist.github.com/3684968  ]

Тот же пример httpd :: git, обновленный для использования Custom Facter в качестве 

« `
# $ MODULEPATH / httpd / manifest / git.pp 
 
класс httpd :: git {
 
  файл {
    "$ {:: conf_dir} /git.conf":
      обеспечить => «настоящее»,
      content => template ('httpd / mynode.conf.erb'),
  }
}
# $ MODULEPATH / httpd / templates / mynode.conf.erb
 
Псевдоним <% = git_url%> <% = git_path%>
 
<Directory <% = git_path% >>
<% if is_cgi === 'true'%> #, потому что в фактах любое (логическое) значение сохраняется как строка
  Опции + ExecCGI
  AddHandler cgi-скрипт .cgi
  DirectoryIndex gitweb.cgi
  <% end%>
</ Directory>
Puppet apply --modulepath = $ MODULEPATH -e "включить httpd :: git"

« `

Существует также другой способ предоставления Facter в Puppet Catalog, который может быть сделан путем предоставления переменной Environment с заглавным именем Facter, предварительно фиксированным с помощью ‘FACTER_’, и значением, которое он должен иметь.

Для Например 
,
FACTER_MYKEY = $ my_value кукольных применить —modulepath = $ ModulePath -e «включает в себя HTTPd :: мерзавца»

_

puppetdb :


Это прекрасное дополнение к набору компонентов Puppet. Что-то, чего не хватало надолго и, возможно, то, из-за чего я отложил этот пост на пол года.

Он обеспечивает питание «storeconfig» без Master, обеспечивает поддержку доверенных БД для нужд данных, связанных с инфраструктурой, и, таким образом, лучше всего подходит для всех.

Чтобы настроить ‘puppetdb’ на узле, следуйте 
PuppetLabs с хорошей документацией .


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

Поместите файл 2 ‘.conf’ и 1 ‘.yaml’ в каталог конфигурации Puppet.

Сценарий 
оболочки  подготовит узел со службой PuppetDB к сценарию использования марионетки без хозяина.
 Параметр

Puppet config для storeconfig, равный ‘puppetdb’, позволяет сохранить в нем экспортированные ресурсы. Конфигурация «отчеты» подтолкнет марионетку применить отчеты к базе данных.

Конфигурация PuppetDB  позволяет Puppet знать хост и порт для подключения к базе данных.

Установка фактов в 
файле rout.yaml  позволяет использовать PuppetDB в режиме без хозяина.

« `

[главный]
  storeconfigs = true
  storeconfigs_backend = puppetdb
  отчеты = магазин, puppetdb
  pluginsync = true
[главный]
  сервер = $ FQDN
  порт = 8081
подать заявление:
  факты:
    конечная остановка: facter
    кеш: facter
# скачать puppetdb и зависимые модули puppet
модуль кукол установить puppetlabs / puppetdb
 
# установить puppetdb и postgresql по умолчанию
кукольный применить -e "class {'puppetdb':}"
puppet apply -e "package {'puppetdb-terminus':}"
 
# резервное копирование ssl dirs, если они существуют
if [-d / etc / puppet / ssl]; затем
  mv / etc / puppet / ssl /etc/puppet/ssl.bak
фи
if [-d / etc / puppetdb / ssl]; затем
  mv / etc / puppetdb / ssl /etc/puppetdb/ssl.bak
фи
 
# Исправление использования CA как masterless
FQDN = `facter fqdn`
кукольный сертификат генерирует $ FQDN
puppetdb-ssl-setup -f
 
# добавление полного доменного имени в IP-отображение хоста в PuppetDB и всех используемых узлов
IPADDRESS = `Ipaddress фастера`
echo "$ IPADDRESS $ FQDN" >> / etc / hosts
 
# / sbin / service или любая другая служебная команда, которую вы используете
/ sbin / service puppetdb restart

« `

[Gist-Set с использованием PuppetDB с настройкой Puppet без мастера: 
https://gist.github.com/abhishekkr/6114760  ]


Теперь запустите что-нибудь, скажем, как …

puppet apply -e ‘package {«vim»:}’,

и прекрасно, что ‘
export resources ‘ будет работать как шарм, используя PuppetDB.

Сопровождаемый puppet.conf будет создавать отчеты и в PuppetDB.


_

На  эту же тему есть 
хорошая статья от 
PuppetLabs