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
….. весь остальной код должен вычислять значение для установки или даже набор ключей.
Тот же пример 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 …