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

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

    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 3
      0
      Спасибо большое за информацию!
      В рунете про cfengine3 ничего нет, а mail.ru'ки не особо делятся инфой (ком.тайна ^^). techforum.mail.ru/report/106 всё что дали.
      Сейчас пытаюсь начать использовать этот замечательный инструмент в связке с aws ec2 (s3 backup) + zabbix!
      alex_www мы случайно не знакомы? ;) если есть возможность стукни в личку.
      Сам любитель fabric… люблю ручками… но сейчас задачи другие up to 10k hosts...puppet & chef вряд ли потянут… и они мне не нравятся.
      Спасибо!
        0
        Алекс, спасибо большое за статью!
        Вопрос — почему CFE3 берет файлик promises.cf из /var/cfengine/masterfiles, при том что этот же файлик есть в /var/cfengine/inputs?
        И как коррелируются эти каталоги между собой?

        Я думал что весь проект достаточно чтобы лежал в inputs — не в masterfiles.
          0
          В клиент-серверной модели управлемые хосты забирают файлы с policy hub директории /var/cfengine/masterfiles себе локально в /var/cfengine/inputs

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое