Pull to refresh

Cfengine3 — немного о policy hub

Reading time 6 min
Views 5.3K
В прошлой заметке я кратко рассказал о замечательной системе управления конфигурациями 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» и «клиен-сервер» конфигурации. Как всегда, официальный сайт, и в частности, готовые решения всегда придут на помощь!

Tags:
Hubs:
+4
Comments 3
Comments Comments 3

Articles