Первый опыт в качестве шеф-повара, или управление конфигурацией

    Введение


    Автоматизированное управление конфигурацией ваших компьютеров — необходимо для любой компании с большим парком компьютеров.

    Сейчас среди администраторов очень популярен Puppet, но, по моему мнению, продукты с самописным DSL (предметно-ориентированным языком программирования) — ограниченны по своей природе.

    Chef использует DSL, основанный на Ruby, что придаёт ему изящество и неограниченную расширяемость.

    Update: spanasik поправил меня, Puppet также имеет в дополнение к внешнему DSL ещё и внутренний DSL, основанный на Ruby.

    Архитектура


    Это приложение состоит из серверной (chef server) и клиентской (chef-client) части. Кроме того, есть клиент, работающий без поддержки со стороны сервера (chef-solo). Сервер отвечает за сбор и предоставление информации об узлах (компьютерах, работающих под управлением Chef), и требуемых действиях.

    С точки зрения администратора, мы просто добавляем новые узлы в Chef (выполнив стандартный скрипт на новом узле), и с помощью перетаскивания нужных ролей и рецептов настраиваем узел. Остальное в стандартном сценарии происходит автоматически и без вашего участия.

    Узлы


    Компьютеры, зарегистрированные в Chef, называются узлами. Мы всегда можем просмотреть и изменить список примененных рецептов,
    узнать различные характеристики узла (ip, fqdn, количество процессоров, множество иных параметров, ваши атрибуты), как добавленные вами, так и собранные самим chef (с помощью ohai).

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

    Например,
    template "/etc/my-software.conf" do
      source "my-software.conf.erb"
      variables :trackers => search(:node, "recipe:tracker")
      notifies :restart, resources(:service => "my-software"), :delayed
    end
    


    Поваренные книги (cookbooks)


    Для управления парком машин используется набор поваренных книг, многие из которых уже написаны (Opscode, 37 Signals, Engine Yard), а какие-то мы можем написать и сами (для своих приложений).

    Поваренные книги состоят из метаданных (определяют зависимости между книгами, и так далее), рецептов (действий на целевом узле), определений ресурсов (сервисы и прочая), библиотек функций (просто код, который вы можете написать на Ruby), шаблонов (файлы, генерируемые на узле с помощью шаблонизатора embedded ruby), файлов (которые копируются в неизменном виде) и атрибутов (данные в формате JSON, ассоциируемые с узлом).

    Кстати, важно знать, что такие базовые ресурсы, как шаблон, файл/каталог/линк (копируемый удалённо или создаваемый на месте, команда интерпретатора, пакет для вашей ОС (rpm, deb etc.), сервис init.d, пользователь Unix, репозиторий VCS, и многое другое, — уже есть в базовой поставке Chef.

    Если же чего-то не хватает, это всегда можно либо найти, либо написать самому.

    Примеры



    Runit

    Установка вашего продукта, как сервиса runit, можно выполнить, например, так:

    include_recipe "runit" # It setups runit.
    
    package "tar" do
      version "1.16.1-1"
      action :install
    end
    
    gem "rails" do
      version "2.3.5"
    end
    
    git "our-code" do
      destination "/opt/our-code"
      repository "git://our-code.local/our-code.git"
      reference "HEAD"
      action :export
    end
    
    runit_service "our-service" do
      restart_on(:deploy => "our-code")
    end
    


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

    Так же легко можно настроить скрипты God или Monit.
    Поделиться публикацией

    Комментарии 17

    • НЛО прилетело и опубликовало эту надпись здесь
        +2
        С себя смеетесь, что до сих пор не прикрутили автоматизацию сего процесса?
        0
        У меня была идея создания подобного ПО.

        Приятно думать, что теперь не придется делать свой велосипед )
          +1
          Есть ~20 машин под Debian Squeeze. Сейчас все настройки управляются Puppet. Это меня устраивает. Но Puppet не решает задачу синхронного обновления всех машин. То есть, хотелось бы в 1 шаг узнать, как отличается набор ПО на всех машинах и в 1 шаг обновить / доустановить нужное / удалить лишнее. Есть такой инструмент?
            0
            Очень легко, можно создать рецепт, который смотрит список всех узлов, смотрит список установленных рецептов на них, и недостающие на данной машине рецепты добавляет к ней, и затем инициирует второй проход конвергенции.
              0
              Для автоматического применений обновлений либо chef-client выполняется в режиме демона, либо по крону, либо ставится opscode-agent, который позволяет удалённо выполнять команды chef-client через простой API.
              +1
              Если же нужно согласовывать не набор рецептов, а набор пакетов, то и это несложно, хотя это и неправильный путь. Лучше всегда работать рецептами и ролями.

              Например, в случае Debian можно поступить так:

              Создать рецепт, который добавляет атрибут installed-packages к узлу путём выполнения dpkg -l. Возможно. такой рецепт уже есть.

              И затем создать рецепт, который доставляет пакеты исходя из общего списка пакетов для всех узлов.
              +2
              > Chef использует DSL, основанный на Ruby

              Puppet тоже, как ни странно :-)
              Поэтому про самописный DSL в Puppet лучше уберите.
                0
                Поправил в статье. Громадное спасибо!
                  0
                  Вам спасибо!
                0
                Что насчет Viper-a в єтой категории? Сам пакет -солянка из дургих. (dhcp-server-ldap+netinstall+preseed+openldap+puppet) Все настройки в лдап-е.
                Кто то сием чудом пользовался?
                  0
                  интересно! нашел инструкцию. www.debian-administration.org/article/Automatic_host_installation_using_Viper
                  буду пробовать
                    0
                    Меня смущает его узкопрофильность: парк должен быть строго Debian.

                    А по жизни обычно великое разнообразие :)
                      0
                      Вы не правы, не только дебиан. Все будет зависить от правильно исползования preseed конфигурации (kickstart или другой аналогии что кормиться для автоинстала) и дальнейшего использования папета (а он не дебиан ориентрированный).
                      Хотя с другой стороны для того же редхата есть утилита spacewalk , и держать разнообразный зоопарк — как по мне — тоже не правильно.

                      В данный момент в вайпере проблемка с лдапом… ну кикак у меня не выходит пока что полностью его подружить с новой архитектурой slapd.conf.
                      Вайпер не болие чем солянка пекетов, автосконфигурированная под debian-like системы. А что вы будете ставить на скелет ldap-а — зависит от вас.
                    0
                    Chef — моя основная тулза как у Deployment Engineer, но, несмотря на то, что люблю его нежно не могу не упомянуть об объективных недостатках.

                    1) Готовые cookbooks бывают странного качества. Очень многие ориентированы на Debian, и под RH-like их вообще не проверяли. То есть править приходится много
                    2) Сам чеф молод, и ошибки часто встречаются. Например он очень любит класть собственный CouchDB
                    3) Некоторые вещи реализованы странно — например проверка классов до выполнения рецепта. Создает проблемы, если хочется DSL расширить.
                    4) Документация хороша, но очень поверхностна. Очень часто приходится смотреть в исходники.
                    5) И наверное главное — нет альтернативы web-интерфейсу для менеджмента. Да, я в курсе про knife, но это сторонний сервис и в будущем, видимо, платный

                    Особое отличие от Puppet — это как раз поиск, его в кукле нет и реализовать очень сложно. Вообще opscode изначально занимались именно консультациями по puppet, но, устав с ним бороться, написали свой «велосипед».

                    Кстати, вас не интересует создание русскоязычного ресурса про Chef?
                      0
                      1) согласен, иногда приходится переделывать рецепты.
                      2) Пока не встречался с падениями базы, а вот индекс рушится часто (ferret). Делаю sudo rm /srv/chef/search_index/* в таком случае. Поправят в 0.8, переходом на другой поисковый движок.
                      3) Никаких проблем не было в связи с этим. Если помнить порядок загрузки и компиляции, то, как мне думается, можно очень легко и красиво расширить язык, используя файлы определений.
                      4) Плюс один. Недокументированы такие гадости, как, например, отсутствие нотификаций при выполнении блока кода.
                      5) JSON-интерфейс есть, просто никому пока не пришло в голову написать свою админку. Надо посмотреть, какой они её сделают в Chef 0.8.

                      Пока не уверен, что нужен такой ресурс. Я использую Chef пока немного поверхностно. Тупо решаю свои задачи, не более того.
                        0
                        3) Там помимо определений есть еще и libraries. И вот с ними возникают проблемы, например:
                        в foo/libraries/foo.rb

                        require «bar»
                        class Chef
                        class Resource
                        class Foo < Chef::Resource

                        end
                        end

                        Так вот если этого bar не будет, то естественно, работать не будет. Но не будет работать также, если в рецепте перед вызовом Foo сказать gem_package «bar». То есть Chef просто при загрузке классов упадет :(

                        5) Ну как раз knife это в ту сторону, просто реализовано через сервис самого opscode

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

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