В прошлой заметке я кратко рассказал о замечательной системе управления конфигурациями cfengine3. Сегодня рассмотрим ее немного подробнее касательно клиент-серверной настройки и более тонкой настройки клиентов в зависимости от предполагаемой функциональности.
Устанавливаем cfengine3 пакет, как и в прошлой замете, как на клиенте так и на сервере политики (policy hub). Рассмотрим следующую клиент-серверную cfengine3 конфигурацию. Положим: policyhub01 198.51.100.10, srv01.local 203.0.113.101. Инициализируем себя как policy hub (198.51.100.10 наш собственный IP). Полиси хаб, как раз и есть то место которое служит централизованным хранилищем наших политик, которые позднее будут скачаны с него клиентами. Почти все системы менеджмента конфигураций используют pull, а не push, тому есть много причин, рассмотрение которых займет не меньше чем объем этой заметки.
root@policyhub01:/tmp# /var/cfengine/bin/cf-agent --bootstrap --policy-server=198.51.100.10
** CFEngine BOOTSTRAP probe initiated
@@@
@@@ CFEngine
@ @@@ @ CFEngine Core 3.4.1
@ @@@ @
@ @@@ @
@ @
@@@
@ @
@ @
@ @
Copyright (C) CFEngine AS 2008-2012
See Licensing at http://cfengine.com/3rdpartylicenses
-> This host is: policyhub01.local
-> Operating System Type is linux
-> Operating System Release is 3.6.10-vs2.3.4.6
-> Architecture = x86_64
-> Internal soft-class is linux
-> No policy failsafe discovered, assume temporary bootstrap vector
-> No previous policy has been cached on this host
-> Assuming the policy distribution point at: 198.51.100.10:/var/cfengine/masterfiles
-> Attempting to initiate promised autonomous services...
** This host recognizes itself as a CFEngine Policy Hub, with policy distribution and knowledge base.
-> The system is now converging. Full initialisation and self-analysis could take up to 30 minutes
R: This host assumes the role of policy distribution host
R: -> Updated local policy from policy server
R: -> Started the server
R: -> Started the scheduler
-> Bootstrap to 198.51.100.10 completed successfully
Теперь переходим к клиенту:
root@srv01:/tmp# /var/cfengine/bin/cf-agent --bootstrap --policy-server=198.51.100.10
-> No policy failsafe discovered, assume temporary bootstrap vector
-> No previous policy has been cached on this host
-> Assuming the policy distribution point at: 198.51.100.10:/var/cfengine/masterfiles
-> Attempting to initiate promised autonomous services...
Challenge response from server 198.51.100.10/198.51.100.10 was incorrect!
!! Authentication dialogue with 198.51.100.10 failed
R: This autonomous node assumes the role of voluntary client
R: !! Failed to pull policy from policy server
R: !! Did not start the scheduler
!! Bootstrapping failed, no input file at /var/cfengine/inputs/promises.cf after bootstrap
Часть вывода удалена.
Не работает! По умолчанию cfengine3 доверяет только хостам из своей /16, а у нас сервер и клиент в разных сетях. Кроме того это слишком широкий диапазон и следует его сразу ограничить в файлах /var/cfengine/inputs/def.cf и /var/cfengine/inputs/controls/cf_serverd.cf.
Исправляем на plicyhub01 файл /var/cfengine/inputs/def.cf
"acl" slist => {
"$(sys.policy_hub)",
"203.0.113.101/32",
},
Можно было бы (и идеологически правильнее ?) сделать обмен ключами иным
способом, не же ли делать 'trust' по IP. Выполняем на srv01 опять: root@srv01:/tmp# /var/cfengine/bin/cf-agent --bootstrap --policy-server=198.51.100.10
** CFEngine BOOTSTRAP probe initiated
@@@
@@@ CFEngine
@ @@@ @ CFEngine Core 3.4.1
@ @@@ @
@ @@@ @
@ @
@@@
@ @
@ @
@ @
Copyright (C) CFEngine AS 2008-2012
See Licensing at http://cfengine.com/3rdpartylicenses
-> This host is: srv01.local
-> Operating System Type is linux
-> Operating System Release is 3.6.10-vs2.3.4.6
-> Architecture = x86_64
-> Internal soft-class is linux
-> An existing policy was cached on this host in /var/cfengine/inputs
-> Assuming the policy distribution point at: 198.51.100.10:/var/cfengine/masterfiles
-> Attempting to initiate promised autonomous services...
R: This autonomous node assumes the role of voluntary client
-> Bootstrap to 198.51.100.10 completed successfully
Успех! Теперь самое время написать несколько политик на стороне policyhub01 и убедится что все работает.
На policyhub01 в /var/cfengine/masterfiles создаем файлы
config_web_srv.cf:
bundle agent config_web_srv {
vars:
"package_list" slist => { "nginx" };
packages:
"${package_list}"
package_policy => "add",
package_method => generic;
processes:
"nginx"
restart_class => "start_nginx";
commands:
"/etc/init.d/nginx restart"
ifvarclass => canonify("start_nginx");
}
и install_base_pkg.cf:
bundle agent install_base_pkg {
vars:
"package_list" slist => { "vim", "mc" };
packages:
"${package_list}"
package_policy => "add",
package_method => generic;
files:
linux::
"/etc/motd"
edit_line => insert_lines("This host is managed by cfengine3!");
}
Важно скопировать эти файлы так же в inputs: root@policyhub01:/var/cfengine/masterfiles# cp config_web_srv.cf install_base_pkg.cf ../inputs/. Теперь настало время сказать кто же из хостов должен выполнить эти полиси. В файле /var/cfengine/masterfiles/promises.cf находим body control inputs и добавляем туда наши файлы:
inputs => {
# Global common bundles
"def.cf",
# Control body for all agents
"controls/cf_agent.cf",
"controls/cf_execd.cf",
"controls/cf_monitord.cf",
"controls/cf_report.cf",
"controls/cf_runagent.cf",
"controls/cf_serverd.cf",
# COPBL/Custom libraries
"libraries/cfengine_stdlib.cf",
# Design Center
# MARKER FOR CF-SKETCH INPUT INSERTION
"cf-sketch-runfile.cf",
# User services from here
"services/init_msg.cf",
# our policies
"config_web_srv.cf",
"install_base_pkg.cf",
};
Далее, в этом же файле создаем наш бандл:
bundle agent config
{
classes:
"web_srv" or => { classmatch("web.*"),
"srv01_local",
"web3_example_com"
};
methods:
web_srv::
"config_web_srv" usebundle => "config_web_srv";
any::
"install_everywhere" usebundle => "install_base_pkg";
reports:
cfengine_3::
"bundle agent config DONE";
}
И добавляем его в bundlesequence:
bundlesequence => {
# Common bundles first for best practice
"def",
# Design Center
"cfsketch_run",
# Agent buddles from here
"main",
# Our ccustomisation
"config",
};
Сохраняем и ждем примерно 5 минут. Проверяем и удостоверяемся, что пакеты из install_base_pkg и config_web_srv установлены. Разберем, что произошло. Клиент, как и положено, скачал себе в inputs файлы из masterfiles нашего полиси хаба. Далее cf-agen на стороне srv01 начинает их обрабатывать, предварительно установив хард классы:
Hard classes = { 203_0_113_101 2_cpus 64_bit Afternoon Day6 GMT_Hr17 Hr17 Hr17_Q2 January Lcycle_0 Min20_25 Min21 PK_MD5_877dfa1640c3c49a2065ce220a3b821f Q2 Sunday Yr2013 agent any cfengine cfengine_3 cfengine_3_4 cfengine_3_4_1 cfengine_in_high community_edition compiled_on_linux_gnu cpu0_normal cpu1_normal cpu_normal debian debian_7 debian_7_0 diskfree_high_normal entropy_misc_in_low entropy_misc_out_low entropy_postgresql_in_low entropy_postgresql_out_low have_aptitude ipv4_203 ipv4_203_0 ipv4_203_0_113 ipv4_203_0_113_101 linux linux_3_6_10_vs2_3_4_6 linux_x86_64 linux_x86_64_3_6_10_vs2_3_4_6 linux_x86_64_3_6_10_vs2_3_4_6__1_SMP_Mon_Dec_17_03_23_11_UTC_2012 local mac_00_25_64_3b_97_cb messages_high_ldt messages_high_normal net_iface_br0 opt_dry_run otherprocs_low rootprocs_high rootprocs_high_ldt srv01 srv01_local syslog_high_ldt syslog_high_normal users_low verbose_mode www_in_low x86_64 }
Список хард классов на данном хосте можно получить запустив cf-agent -v. Выше мы сказали bundlesequence включить наш бандл 'config'. Первым делом мы устанавливаем soft классы в зависимости от имеющихся hard классов. В случае нашего srv01 будет установлен soft класс web_srv, потому что произойдет совпадение по классу доменного имени. Соответственно, когда будет отрабатывать секция methods произойдет сравнение классов и будет вызван нужный bundle. Бандл install_base_pkg отработает для всех хостов, так как hard класс any установлен всегда. Для веб-серверов отработает и install_base_pkg и config_web_srv, который установит пакет nginx и периодически будет удостоверятся что он запущен. Этим как раз и занимается класс nginx типа proccess, который установит soft класс «start_nginx» если такого процесса нет, что соответственно, приведет к выполнению команды "/etc/init.d/nginx restart". Вы можете специально или случайно остановить nginx, но cfengine все равно его запустит через некоторое время!
На этом все, надеюсь эта заметка прояснила в некоторой мере вопрос «solo» и «клиен-сервер» конфигурации. Как всегда, официальный сайт, и в частности, готовые решения всегда придут на помощь!
Автор: alex_www
