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 …