Установка и настройка Puppet + Foreman на Ubuntu 14.04 (пошаговое руководство)

    image Доброго времени суток, жителям Хабра!

    Когда число управляемых серверов достигает нескольких десятков, а то и сотен, приходится искать решение по автоматической настройке и управлению таким парком. Тут на помощь приходит Puppet. Почему Puppet? Puppet кроссплатформенный, имеет богатое сообщество, имеет множество готовых модулей (4800+), имеет Enterprise версии. Все эти плюсы не дают усомнится в мощи данного продукта. Но управлять из консоли таким «комбайном» не так просто. Потому для удобного управления и настройки Puppet был разработан Foreman. Далее установка и настройка этой связки на примере задачи управления SSH-ключами.

    Требования:

    • чистый сервер для puppet-мастер;
    • команды на сервере puppet-мастер выполняются как root;
    • команды на серверах puppet-агент выполняются через sudo.

    Используемое ПО:

    • ОС Ubuntu 14.04.5 LTS;
    • Puppet 3.8.7;
    • Foreman 1.11.4.

    Цели:

    • получить удобный способ автоматизированного управления инфраструктурой сети;
    • получить удобный способ управления ssh-ключами.

    Примечание

    Все скриншоты и кусок конфигурации скрыты спойлерами. Для лучшего понимания, где выполняются команды, перед каждой командой добавил тип сервера (master или agent).

    1. Установка Foreman + Puppet на puppet-мастера


    Добавим репозиторий установщика Foreman/Puppet и установим его в систему:

    master ~ $ apt-get -y install ca-certificates
    master ~ $ cd ~ && wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb
    master ~ $ dpkg -i puppetlabs-release-trusty.deb
    master ~ $ sh -c 'echo "deb http://deb.theforeman.org/ trusty 1.11" > /etc/apt/sources.list.d/foreman.list'
    master ~ $ sh -c 'echo "deb http://deb.theforeman.org/ plugins 1.11" >> /etc/apt/sources.list.d/foreman.list'
    master ~ $ cd ~ && wget -q http://deb.theforeman.org/pubkey.gpg -O- | apt-key add -
    master ~ $ apt-get update && apt-get -y install foreman-installer
    

    Запустим установщик:

    master ~ $ foreman-installer
    

    Результат должен быть похож на следующий:

    Результат установки Foreman


    Ссылка вида puppet.<domain.com> и логином с паролем нам пригодятся дальше.

    Настроим конфигурацию для просмотра в Foreman различий изменений файлов:

    master ~ $ nano /etc/puppet/puppet.conf
    > show_diff = true
    

    Откроем в браузере ссылку, рекомендованную в предыдущем шаге: puppet.<domain.com>
    И введём логин: admin и пароль, который мы видели в консоли после установки.

    Скриншот формы авторизации


    Если авторизация прошла успешно, значит Foreman установлен и работает должным образом. Теперь можно переходить к следующей главе.

    2. Настройка Foreman


    По умолчанию Foreman использует свой SSL-сертификат, сгенерированный Puppet и ваш браузер не будет принимать его. Вы можете добавить корневой сертификат (/var/lib/puppet/ssl/certs/ca.pem) в свой браузер, чтобы исчезли предупреждения небезопасного соединения (для Chromium добавлять сюда: Настройки/SSL/Центры сертификации).

    При первом входе вы увидите страницу Dashboard, где будет показана общая статистика по всем узлам сети. При добавления узлов сети, здесь будет полезная статистическая информация.

    Скриншот панели


    При последующих входах вы будете перенаправляться на страницу списка узлов сети.

    2.1. Смена пароля


    Первым делом необходимо изменить пароль пользователя:

    Сменить пароль


    Пароль по умолчанию и так сложный, но лучше сделать свой.

    2.2. Добавление модуля на примере NTP


    Время должно быть точно установлено на главном сервере puppet-мастер. Для этого необходимо использовать NTP. Если время неверно, puppet-мастер может ошибочно выдавать сертификаты агентов из далекого прошлого или будущего, которые другие узлы будут считать устаревшими.

    Иногда, чтобы иметь возможность управлять модулями Puppet через Foreman, необходимо установить модули, разработчиками которых являются не Puppet-Labs, а разработчики сообщества Puppet. Это вытекает из того факта, что Foreman использует HTTP-запросы Restful API для Puppet, но не во всех модулях определено управление с помощью такого API.

    Установим модуль saz/ntp на puppet master:

    master ~ $ puppet module install saz/ntp

    Примечание

    Модуль saz/ntp прекрасно работает на версии Foreman 1.11. Для других версий Foreman, можно использовать модули с сайта forge.puppetlabs.com по поиску ntp.

    Вы должны увидеть следующее:

    Результат установки saz/ntp


    Сейчас модуль был установлен только для puppet-мастер. Теперь необходимо войти в веб интерфейс и добавить его к Foreman. Перейдите в меню Configure → Classes и нажмите Import from puppet.<domain.com>:

    Configure → Classes


    В результате вы увидите список доступных классов, отметьте нужные и нажмите Update:

    Update


    Для того, чтобы использовать ближние к вам ntp-серверы, перейдем на сайт www.pool.ntp.org. Там в правом блоке выберем нужный нам пул (Африка, Азия и т.д.) и заберём список серверов в буфер обмена.

    Далее идём в настройки класса ntp, кликнув по его названию. Переходим во вкладку Smart Class Parameter и ищем в левом списке вкладку server list:

    server list


    Отмечаем пункт Override и в Default value по примеру предыдущего значения, добавляем сервера из шага выше. Я добавил такое значение:

    ["0.asia.pool.ntp.org","1.asia.pool.ntp.org","2.asia.pool.ntp.org","3.asia.pool.ntp.org"]
    

    Нажимаем Submit внизу страницы, тем самым мы переопределили параметр класса.

    2.3. Добавление модуля accounts и ssh


    На примере предыдущего модуля установим модуль accounts:

    master ~ $ puppet module install camptocamp-accounts
    

    Если установка прошла успешно, то вы увидите следующее:

    Результат установки accounts


    Установим модуль ssh:

    master ~ $ puppet module install saz/ssh
    

    После этого идём в Foreman и импортируем новые классы. Позже, после создания групп узлов сети, мы настроим классы accounts и ssh.

    2.4. Добавление модуля mysql и apache


    Для объяснения последующих названий групп database и web добавим модули apache и mysql. Добавляем модули по примеру предыдущих. Загрузить их можно командами:

    master ~ $ puppet module install puppetlabs-apache
    master ~ $ puppet module install puppetlabs-mysql
    

    3. Добавление узлов сети


    Чтобы добавить узел сети в Puppet, необходимо установить puppet-агент на этот узел. Для установки puppet-агента скачаем и установим репозиторий puppet-labs:

    agent ~ $ cd ~ && wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb
    agent ~ $ sudo dpkg -i puppetlabs-release-trusty.deb
    agent ~ $ sudo apt-get update
    

    Затем установим puppet-агент:

    agent ~ $ sudo apt-get -y install puppet
    

    Чтобы запустить Puppet в роли агента, необходимо закомментировать настройки зоны puppet-мастера. Также добавьте конфигурацию для агента, которая установит адрес нашего puppet-мастера. Приведём файл конфигурации /etc/puppet/puppet.conf в вид:

    puppet.conf
    [main]
    logdir=/var/log/puppet
    vardir=/var/lib/puppet
    ssldir=/var/lib/puppet/ssl
    rundir=/var/run/puppet
    factpath=$vardir/lib/facter
    #templatedir=$confdir/templates
    
    #[master]
    # These are needed when the puppetmaster is run by passenger
    # and can safely be removed if webrick is used.
    #ssl_client_header = SSL_CLIENT_S_DN 
    #ssl_client_verify_header = SSL_CLIENT_VERIFY
    
    [agent]
    server = puppet.domain.com
    # где puppet.domain.com - hostname или IP-адрес вашего master-сервера
    


    Заменим значение переменной START с no на yes, чтобы запустить puppet-агент после перезагрузки ОС. А также запустим puppet-агент:

    agent ~ $ sudo sed -i s/START=no/START=yes/g /etc/default/puppet
    agent ~ $ sudo service puppet start
    

    При небольшой инфраструктуре puppet-агент можно запускать в виде демона. Есть также способ запуска через CRON: docs.puppet.com/puppet/3.6/services_agent_unix.html#running-puppet-agent-as-a-cron-job.

    Примечание

    Puppet-агент по умолчанию ищет домен puppet-мастера в своей зоне, если явно не указан параметр server (в файле puppet.conf). Например: server.domain.com будет искать сервер puppet.domain.com. Потому, если вы ещё идёте по инструкции, то у вас всё должно работать.

    После этого идём на Foreman в Infrastructure → Smart Proxies → Certificates:

    Infrastructure → Smart Proxies → Certificates


    Там должен появится узел сети, на который мы только что установили puppet-агент. Можно использовать фильтр (вверху слева), чтобы увидеть только неподписанные сертификаты. Чтобы подписать, необходимо нажать кнопку Sign:

    Certificates → Sign


    В течение нескольких минут сервер server.<domain.com> (сервер, на котором мы только что установили агент) появится в списке Hosts → All hosts.

    4. Добавление групп узлов сети


    Перейдём в пункт меню Configure → Host Groups. Нажмём New Host Group. Вкладка Host Group должна получится следующей:

    Configure → Host Groups


    Группа root будет корневой. Она будет родителем всех остальных групп. У ней будет полный доступ ко всему. И в неё будут включены основные классы.

    Далее перейдем во вкладку Puppet Classes и добавим необходимые классы нажав на +:

    Puppet Classes


    Нажимаем Submit.

    Добавим по этому же принципу ещё две группы. Только теперь мы выберем в качестве Parent группу root, потому классы accounts, ntp и ssh наследуются и добавлять их повторно не нужно. Добавим только для группы database класс mysql::server, а для группы web класс apache.

    Добавление группы database


    Список всех групп


    5. Добавление узла в группу


    Чтобы включить узел в группу, необходимо перейти в его настройки.

    Настройки узла сети


    После этого в первой вкладке добавляем группу, как на скриншоте ниже:

    Добавление группы к узлу сети


    После этого нажимаем Submit и в течение нескольких минут на узле сети появится mysql. Таким же образом можно присвоить остальным двум серверам группу web:

    Список узлов сети с присвоенными группами


    Вся конфигурация распространяется на puppet-агенты автоматически в течение нетокоротого времени.

    Если не хочется ждать, то можно на клиентах выполнить команду puppet agent --test и увидеть своими глазами, как создаётся конфигурация.

    6. Настройка прав доступа с помощью модуля accounts


    Собственно сейчас можно ещё раз посмотреть на схему, которую мы привели в начале и на основе её создать логику.

    Перейдём в пункт меню Configure → Classes. Нажмём на accounts, чтобы перейти в настройки модуля. Из всех настроек нам будут нужны вкладки accounts, ssh keys, users.

    Примечание
    Вкладка accounts — в ней содержаться хэши «пользователь сервера → названия публичных ключей из вкладки ssh keys». Вкладка ssh keys — в ней содержаться хэши «название ключа → тип и значение». Вкладка users — в ней содержаться пользователи, которых необходимо создать или указать для уже существующих некоторые параметры.

    Откроем последнюю вкладку users и установим её как на скриншоте:

    users


    Этот параметр настраивает домашний каталог пользователя. Здесь мы задействовали Merge overrides и Merge default параметры, которые позволят объединить конфигурацию для конечного узла сети.

    Вкладку ssh keys заполним следующим образом:

    ssh keys


    В поле Default value необходимо вписать все публичные ключи аккаунтов, которые будут использоваться во вкладке accounts. Эти публичные ключи пользователей, которые будут иметь доступ на те или иные сервера. Отступ в два пробела перед параметрами type и public обязателен.

    Пример того, как выглядит один публичный ключ (остальные добавляются друг за другом ниже):

    admin:
      type: ssh-rsa
      public: AAAAB3NzaC1yc2EAAAADAQABAAABAQDXibuyi2MFzERps7mD2J38mhd4phXQlOEZrmui9rDdcYD0XeEnvdRTZPcsMOw6DRT1ERpzbcFehj+G29YxoiXZ541gVjVvsATAqojN3zEkMz5b0AgBNcKDFi9h/qwlK9YDv2trKEcRHQ4kBN332Z6oqdBFerUMys5dvc3RVlE+x2kVmYNmGIlma5twC9w/wRNoD+nUK+3bk+I+Og40f//uFAKFeY4DMoCrdOsHJrPak5nD9vL6a2m/Fe3jfgmpBCcnV3LS2mr+PdRYbtju7nzfu8WT0ugMAUi+dDMRFh3DmfCzXbOi2TPi+mP//L/A19thXffd/QzW7wmAgxlj+km1
    

    Самую верхнюю вкладку accounts заполним следующим образом:

    accounts


    Из этого параметра следует: root имеет доступ везде с аккаунта root (аккаунт root — это элемент из вкладки ssh keys), аккаунт dbadmin имеет root-доступ только к серверам из группы database, а пользователь admin есть только у группы web и аккаунт admin может подключаться только под пользователя admin.

    На вкладке users добавим пользователя admin в группу www-data.

    users


    6.1 Настройка класса ssh


    В классе accounts мы настроили ssh-доступ по ключам. Потому для более полной безопасности необходимо запретить доступ по паролю. Делается это с помощью класса ssh. Переходим в его настройки и открываем вкладку Smart Class Parameter. Далее client options приводим к следующему виду:

    client options


    Вкладку server options приводим к следующему виду:

    server options


    И вкладку storeconfigs enabled заполняем так:

    storeconfigs enabled


    В storeconfigs хранятся все факты о клиентах, поэтому вы можете запросить базу данных и получить списки узлов сети, соответствующие определенным критериям. Для большей безопасности мы это отключили.

    7. Результаты


    В процессе выполнения данного руководства ваша инфраструктура добавленная под управление Puppet станет быстро-конфигурируемой и масштабируемой. А главная цель — управления публичными ssh ключами будет максимально удобной.

    Скриншот списка ключей пользователя admin на одной из машин группы root/web:

    Список ssh-ключей


    Помните, при настройке класса accounts для параметра ssh keys мы включали Merge overrides и Merge default. Это нужно для того, чтобы в конце для определённого узла сети собирался один структурированный файл с ssh-ключами.

    Проверим, действительно ли можно авторизоваться под пользователем “admin” с помощью добавленного ключа:

    Проверка ssh-подключения


    Если у вас также тест прошёл успешно, то инфраструктура готова и можно постепенно подключать остальные ваши сервера к puppet-мастеру и настраивать другие сервисы через Puppet.

    Использованные ресурсы: документация Puppet, документация Foreman.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 26

      +1
      Осталось пара практических вопросов.
      1. Например есть у нас в группе web два аккаунта — developer1 и developer2. И все работает. В какой-то момент developer1 уходит с этого проекта и нам нужно удалить все его ключи со всех серверов. Пупет это сможет?
      2. Частность от первого варианта. developer1 во время работы добавил ключ своего ноутбука, ручками в authorized_keys. Что будет с ними?
        0
        1. Да, это его прямая обязанность. Достаточно в модуле accounts параметр purge ssh keys перевести в true. Но при этом будут так же удалены ключи, добавленные вручную.
        2. Если параметр purge ssh keys = false, что правильнее оставлять по умолчанию, то все ключи добавленные вручную будут пропускаться при обновлении.
          +3
          1. Ни один девопс разработчика на продакшен не пустит.
          2. При увольнении девопса файл с ключами перегенерируется и распространяется на сервера.
          3. За "лезть ручками" в автоматически управляемое окружение надо бить по рукам — есть тестовая среда и стейджинг
          +1
          пупет ужасен
          — стандартная библиотека просто нищая
          — модули, их много, ни одного рабочего
          — миграция с пупет 3 на пупет 4 — это невозможно, проще засетапить по новой
          — внутри руби
          — последовательность исполнения надо указывать явно, есть целыз 3 способа это сделать
          — нет возможности просто выполнить команду, тащите mcollective
          — ресурс уникален, в итоге если каждый хост немного отличается от остальных — это лапша из if
          — очень сложно выполнить на одном хосте код из отдельного бранча
          — все пути прибиты гвоздями, нельзя положить файлик никуда кроме files
          — не понятно куда пихать прослойки profiles/roles, то ли в модули (но это не модули), то ли в манифесты (но к хостам это тоже не относится напрямую), положить в отдельный каталог нельзя, все прибито гвоздями.
          — и еще много чего
            +1
            Согласен. Но это очевидно сейчас, когда есть ансибл. Папет же старенький и тянет за собой кучу легаси. Примером нельзя вызвать дважды функцию с тем же именем, оно должно быть для каждого вызова уникальной… и такого куча.

            Да, действительно стандартная библиотека многого простого не умеет или же это простое нужно делать какими-то костылями. И помню, например, замену строки в файле и как это нелегко делалось…

            Последовательность исполнения — это тот еще ад, особенно когда много кода понаписывали.

            В конфингурациях master-client прекомпиляция почему-то делается на мастере и только на нем и это достаточно быстро приводит к проблемам масштабирования мастера.

            Среди плюсов — это наверное то, что есть Фореман. Ну я не совсем о том, что он очень плох, я о том, что если есть выбор — то лучше попробовать Ансибл.
              +1
              — ресурс уникален, в итоге если каждый хост немного отличается от остальных — это лапша из if

              Для этого в puppet предусмотрены External Node Classifiers (ENC), например hiera (вот, например, статья на эту тему).

                +1
                — стандартная библиотека просто нищая

                Хотелось бы конкретный пример того, что нужно и чего нет в puppetlabs/stdlib?


                — внутри руби

                Наоборот, проблема в том, что нельзя напрямую использовать inline ruby, в отличие от Chef, например


                — последовательность исполнения надо указывать явно

                Да, внутри файла можно было бы добавить зависимость по умолчанию


                — нет возможности просто выполнить команду, тащите mcollective

                Ну это нормально для pull системы конфигурации


                — очень сложно выполнить на одном хосте код из отдельного бранча

                Гм… environments? Работает нормально, была пара багов, но их поправили


                — ресурс уникален, в итоге если каждый хост немного отличается от остальных — это лапша из if

                Ну конечно ресурс с одним именем уникален — было бы странно иметь неоднозначную систему конфигурации


                — не понятно куда пихать прослойки profiles/roles

                Ну так для этого Foreman и создан — там очень гибкая система smart variables — позволяет задавать разные конфигурации в зависимости от множества факторов — имени хоста, домена, группы, региона и т.д.
                Я думаю, что основная проблема в том, что для понимания построения масштабной системы управления конфигурациями на основе Puppet надо обладать серьезными знаниями — отличиями в push/pull системах конфигураций, понятие об external node classifier, compile master, cvs и прочая. Ansible конечно проще для начального освоения.

                  –1
                  — debconf, модули для сетевого железа и еще миллион всего
                  — руби — это ужас, читать чужой код невозможно, писать свой тяжело, в итоге если в модуле банальная бага, ее правка выливается в тонны потраченного времени
                  — если бы у бабушки были яйца…
                  — push система легко превращется в pull, наоборот нет. Зачем делать только pull?
                  — environments решают другую проблему, да даже таскать хост по разным env — это куча телодвижений
                  — это все приводит к боли, добавил роль, а там уже что-то есть и начинается, убрать из роли нельзя, так как у других сломается, оставить как есть тоже. Можно же не выдавать ошибку если ресурс определен дважды, но одинаково?
                  — а без форемана? Его для пупет4 так и не портировали. Как жить?
                    0
                    > а без форемана? Его для пупет4 так и не портировали. Как жить?

                    Та вроде как портировали.

                    Кстати, Ансибл вроде тоже как-то умеет работать с Фореманом. Если это кому-то нужно.
                    –1
                    > нельзя напрямую использовать inline ruby, в отличие от Chef, например

                    а inline_template, или вы не об этом? http://blog.abhijeetr.com/2012/11/execute-ruby-code-from-puppet.html
                      –1

                      Chef позволяет использовать код напрямую, без извращений. Вот пример из документации:


                      if platform?('windows')
                        ruby_block 'copy libmysql.dll into ruby path' do
                          block do
                            require 'fileutils'
                            FileUtils.cp "#{node['mysql']['client']['lib_dir']}\\libmysql.dll",
                              node['mysql']['client']['ruby_dir']
                          end
                          not_if { File.exist?("#{node['mysql']['client']['ruby_dir']}\\libmysql.dll") }
                        end
                      end
                  0
                  И почему 14.04?
                    0
                    Писал статью одновременно с выполнением задачи по работе.
                    Ubuntu 14.04 — «хотелка» заказчика.
                    0
                    Есть работающий фореман-1.10 на дебиан 7, решил обновить до фореман-1.14 и на дебиан 8.
                    Так как рекомендуют обновлять в пределах одной версии (10 -> 11 ->12), то решил не мучаться и поставить с нуля сразу 1.14 версию (руками перенес только группы), используя foreman-install
                    После установки, паппет агенты на хостах автоматом начали региться через фореман-прокси, тк использовался старый сертификат, отрабатывали тоже корректно, но через пару часов апач+мод_пассенджер переставал отвечать по достижении лимита сессий в очереди.
                    Что только не пробовал, увеличивал все лимиты, убирал их совсем, тюнил апач — ничего не помогало, через час passenger (причем последняя версия 5.1.2, где все-все исправили) перестает работать,(паппет агент на амазоновских хостах вообще отваливался по Net::Timeout)
                    На дебиан 7 фореман любой версии работает без проблем с дефолтными настройками, мистика просто.
                      +1

                      Небольшой комментарий по поводу ntp серверов. Для России удобно использовать 0.ru.pool.ntp.org, 1.ru.pool.ntp.org, 2.ru.pool.ntp.org...

                        0
                        А почему не просто ru.pool.ntp.org — они тогда будут не прибиты гвоздями, а динамически выбираться.
                          0

                          Они и так будут динамически выбираться, просто как правило требуется указание более чем одного сервера.

                        +2
                        Статья запоздала года на 4. ;)
                          –1
                          Ну не на 4, но да.
                          +1

                          @tgz, "паппет ужасен", в чистом его виде — согласен. С использованием встроенной hiera, все описание на YAML достаточно просто и элегантно.


                          Из текущего в небольшой конторе:


                          • Puppet 4.9.4 на Debian 8
                          • 2 окружения (environments): corporate & production
                          • > ls -l /etc/puppetlabs/code/environments/corporate/hieradata/nodes/ | wc -l — 60 (и физ. сервера и виртуалки)
                          • в проде хостов по-меньше
                          • общее кол-во модулей — 61
                          • кол-во модулей от 3их разработчиков (т.е. не от Puppetlabs) — 36

                          При использовании hiera, ruby манифест сокращается от 1 до 6 строчек:


                          /etc/puppetlabs/code/environments/corporate/manifests/site.pp
                          (устаревший вариант, но еще работающий)


                          hiera_include('classes')

                          либо


                          include lookup('classes', { 'merge' => 'unique' })

                          или такой, в зависимости от того какое слитие данных необходимо:


                          lookup({ 'name'  => 'classes',
                                   'merge' => {
                                      'strategy'          => 'deep',
                                      'merge_hash_arrays' => true,
                                  },
                          })

                          Иерархия описывается на уровне системного hiera конфига; задатается как угодно; нам хватает вот этого:


                          hierarchy:
                            - name: "Nodes"
                              path: "nodes/%{::trusted.certname}.yaml"
                            - name: "Roles"
                              path: "roles/%{::role}.yaml"
                            - name: "Vurtual"
                              path: "virtual_%{::is_virtual}.yaml"
                            - name: "OS"
                              path: "os_%{::operatingsystem}.yaml"
                            - name: "Environment"
                              path: "env_%{environment}.yaml"
                            - name: "Common Defaults"
                              path: "common.yaml"

                          Последовательность вызова задается в hiera очередностью описания классов, например:


                          ---
                          classes:
                            - apt
                            - sudo
                            - nslcd
                            - package

                          ресурс уникален, в итоге если каждый хост немного отличается от остальных — это лапша из if

                          совсем нет, есть knockout_prefix'ы; есть использование alias'ов и переменных, например:


                          > hieradata/node/devvm01.yaml
                          dev_username: "username"
                          
                          > hieradata/role/dev_vm.yaml
                          sudo::configs:
                            "%{alias('dev_username')}":
                                'content' : "%{alias('dev_username')} ALL=(ALL:ALL) APTGET, APACHECTL....

                          все пути прибиты гвоздями, нельзя положить файлик никуда кроме files

                          смотрите в /etc/puppetlabs/puppet/fileserver.conf и /etc/puppetlabs/puppetserver/conf.d/auth.conf. По сути, Puppet Server — это web сервер, который можно настроить как угодно:


                          # access via puppet:///my_mount_point/
                          [my_mount_point]
                            path /etc/puppetlabs/my_mount_point
                            allow *

                          не понятно куда пихать прослойки profiles/roles

                          окружения (environments), когда недостаточно:


                          > cat /etc/puppetlabs/facter/facts.d/role.json
                          {
                              "role": "dev_vm"
                          }

                          Плюс подобных подролей может быть сколько угодно. В hiera они просто будут как переменные и легко отслеживаются (см выше).


                          push система легко превращется в pull, наоборот нет. Зачем делать только pull

                          хм, нежеланием вешать Puppet Agent на порт, и связанным с этим геммороем в виде дыр, настройкой firewall'а, проброской NAT'а и прочими радостями...


                          К чему я это все, Puppet очень гибкая система, если есть желание с этим разбираться. Зато когда разберешься, то все летает.
                          Другой вопрос, что документация у них оставляет желать лучшего.

                            0
                            Опять же, Папит достаточно актуален. Но попробуйте Ансибл и скажите после этого, что Папитом удобно пользоваться.
                              0
                              Года 1,5 приходилось писать на папете, правда еще 3 версии, задачи и условия были специфические(сначала у нас был свой орекстратор на питоне который запускал агенты на нодах в заданном порядке, потом на другом проекте писал плагин под fuel)- после него на ansible местами плеваться хочется — очень не хватает некоторых функций- вот пример:
                              • Как вы будете переиспользовать handler какой-то роли из другого плейбука, при условии что саму роль исполнять не надо? Если сделать include в handlers -то оно не будет реагировать на notify в версии 2,2(написано в доках)- тут только финт ушами в виде include файла с описанием handler как таски или делать отдельную роль со всеми нужными handler(что, как мне кажется, через пятую точку). По аналогии с папетом- в модуле можно сделать отдельный клас для рестарта и дергать только его(без дублирования описания ресусра)
                              • Как сказать через ansible что вот такой сервис при изменении конфига должен быть перезапущен и должен всегда быть запущен в системе? Тут только отдельный handler на перезапуск и таска на старт(иначе когда кто-то ручками остановит сервис и никаких изменений в конфиге не было- сервис так и не запустится). На папаете это будет один ресурс, который можно «обновлять» из других

                              Вообще такое чувство что ansible все еще сырой, в 2.2 завезли баг в yum модуле- при использовании state=latest — не ообновлялся пакет, который стоит в списке от yum checkupdate первым. Вместо того, чтобы получать список пакетов через rpmconf (как им еще ранее советовали)- опять написали кучу регулярок для парсинга yum checkupdate.
                              Очень двойственное чувство от ansible, если бы не отсуствие выделенного сервера- оно бы «не взлетело».
                                0
                                1. dependencies?
                                2. register и when? state: started? (в пупете тож не за раз всё опишется)
                                Пупет я не люблю больше ансибла :) Но на текущей работе нет salt, зато есть и foreman, и ansible, и puppet :(
                                  0
                                  1) dependencies чего- ролей? Судя по докам при этом выполнится сама роль- чего не нужно (о чем выше написано)
                                  2) Вот тут вообще не понял причем здесь и зачем «register и when? state: started? » даже если рассматривать вариант с таской на запуск и handler на рестарт оно не надо. Почему в папете «не за раз» опишется? ресурс запускающий сервис и рестартующий ровно один, остальные его обновляют(аналог notify).
                                  И эти примеры только-то — на что недавно наступил…
                              0

                              Полностью согласен по всем пунктам, Puppet хорош при грамотной настройке.

                              0
                              не туда ответил

                              Only users with full accounts can post comments. Log in, please.