Chef за 21 день. Часть первая. Введение

  • Tutorial
Привет, Хабраюзеры! На улице противная погода, ангина не дает покоя моему воспаленному горлу, почему бы не написать статью? Это моя первая проба пера на Хабре, поэтому не судите строго. Название ее навеяно огромным количеством книг, имеющих схожее название. В этой статье я постараюсь описать путь воина-автоматизатора для юных падованов, коим в некоторой мере являюсь сам. Речь пойдет о подходе, который при определенном старании, поможет в краткие сроки познакомиться с таким инструментом кроссплатформенной автоматизации, как CHEF. А также, при сильном старании – овладеть ним в достаточной мере для первых серьезных опытов. Эта статья – некий “guiding way” для людей, мало знакомых с процессом автоматизации.


Шаг 1. Знакомство с CHEF



Что представляет собой Chef? Это инструментарий для автоматизированного управления конфигурацией ваших компьютеров («узлов» в терминологии Chef). Узлы общаются с сервером, который содержит в себе описания действий, которые должны быть выполнены узлом. Данные действия описываются в cookbook-е, основными частями которого являются рецепты (набор действий для узла), атрибуты (данные узла, описанные в формате json) и шаблоны (embedded ruby-файлы, генерируемые на узле).

Шаг 2. Подготовка среды



Ну что ж, какая учеба без боевых действий? Что понадобится? Минимальный набор (достаточный для большинства случаев) – это 2 виртуальных машины с поддержкой сети. На одну из них устанавливается сервер (open source Chef). Другая будет клиентом. Выбор ОС произвольный – чем изощреннее Ваш выбор, тем с большим количеством особенностей (в простонародье – костылей) Вы встретитесь. На данный момент, мой скромный опыт показывается, что самым надежным вариантом является Deb-подобные дистрибутивы.

Другим вариантом является использование ресурса preview.opscode.com – готового Chef-сервера, на котором Вы можете зарегистрировать себя и завести организацию с уникальным именем, в которую в дальнейшем будете добавлять Ваши узлы и cookbook-и. После заведения аккаунта и создания организации – Вы сможете загрузить так называемый «start kit» — готовую конфигурацию для chef-администратора, содержащая сертификаты и конфигурационные файлы. Этот kit позволит Вам управлять сервером с Вашего ПК.

Шаг 3. Добавление узлов



Среда готова, можно добавлять наши первые узлы. Тут есть два базовых пути – можно использовать web-интерфейс сервера, либо можно использовать консоль chef-администратора. Использовать web-интерфейс это не наши методы, поэтому мы будем использовать консоль. Инструментарий, который поможет нам в этом процессе – это knife. Он позволяет создавать cookbook-и, добавлять узлы, управлять списками выполнения для каждого узла и имеет множество других возможностей. Процесс добавления узла в данном случае носит название bootstrap, который по сути является установкой и первичным запуском chef-клиента на узел. Также в этом процессе можно передать параметры первого запуска для создаваемого узла в виде json-атрибутов. Для проведения данной операции необходимо иметь доступ к учетной записи администратора и указать параметры оного. После успешного прохождения данного процесса – узел появляется в списке доступных на узле. Данный список можно просмотреть через web-интерфейс либо использую knife node директиву в консоли.

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

Шаг 4. Что же мы автоматизируем?



Вы спросите – вот эти все мучения по добавлению узлов никак не похожи на автоматизацию, ведь все приходится делать руками. Да, Вы правы, однако есть одно «но». Я не все Вам рассказываю, мой юный падован. На самом деле, этот процесс также может быть автоматизирован. Сделаем маленькое лирическое отступление.

Когда у нас есть парк компьютеров, и мы проводим первичную установку ОС на них, мы также можем установить туда и наши сервера и клиенты. Тем самым первый шаг по установке ПО будет осуществлен. Это означает, что наши chef-сервера и клиенты уже запущены и ожидают указаний (как сделать так, чтоб они постоянно работали как демоны или сервисы – вопрос другой статьи). Также, наш прекрасный инструментарии knife позволяет нам осуществлять поиск по параметрам (атрибутам) клиентов. Это может быть использовано для того, чтобы провести какие-то первичные действия с клиентом (например, установить тот или иной пакет). Сами же атрибуты, если Вы помните, назначаются при установке клиента при помощи файла формата json. Атрибуты, на самом деле, представляют себе метку, состоящую из названия и значения (да-да, все предельно просто, как и во всей автоматизации, ха-ха). В итоге мы получаем узлы, которые идентифицируются данными метками, например: узел1 («метка1» = «значение1»). Когда сервер производит поиск по узлам, мы можем задать ему цель его поиска – атрибут, и значение, которому должен он соответствовать. Если быть предельно детальным, то можно это осуществить при помощи knife exec и nodes.find, но об этом Вы можете прочитать отдельно (ссылки на полезные материалы будут в конце статьи). Так вот, процесс поиска даст нам список узлов, соответствующих критерию, и с этим списком мы можем делать что угодно – скормить его серверу, который даст узлам команду на установку чего-либо согласно рецептам, сохранить его и т.п.
После всех этих нехитрых манипуляций – мы должны получить архитектуру, в которой будет сервер и необходимое количество узлов, зарегистрированных на нем, и общающихся с ним в периодическом характере (надо заметить, что на узле это необходимо реализовать доступными средствами, такими как cron или Windows Services). Вернемся к нашей задаче – автоматизации процесса конфигурации узлов.

Chef – настолько могучий, что позволяет множество манипуляций с Вашими узлами. Я даже не уверен, знаю ли я до конца все его возможности, почти уверен – что нет. Со всеми возможностями можно ознакомиться на официальном сайте Chef, в разделе Docs, но даже там описано не все.
Надо установить десяток пакетов и зависимостей? Не проблема! Перезапустить сервисы? Не проблема! Сгенерировать файл по шаблону? Вообще не вопрос! Запустить команды в консоли? Не вопрос!

Все это регламентируется cookbook-ами и рецептами в них. Собственно создание и использование оных – и есть мастерство джедая-автоматизатора. А для достижения мастерства – я настоятельно советую Вам ознакомиться с Ruby и проникнуться концепцией самого Chef. После нескольких недель – Вы полюбите его, а он будет любить Вас и радовать, только иногда пугая костылями и багами.
По моему скромному мнению, на эту часть уйдет 2 дня. Конечно, все зависит от Вашего упорства – так что вперед и с песнями (с).

Ну, и как обещано, полезные ссылки прилагаются далее.
Официальные документы и мануалы — docs.opscode.com
Установка Chef-сервера (Enterprise) — docs.opscode.com/install_server_oec.html
Установка Chef-сервера (Open source) — docs.opscode.com/install_server.html
Установка Chef-клиента — docs.opscode.com/install_workstation.html
Инструмент knife — docs.opscode.com/knife.html
Полезная картинка с опциями knife — docs.opscode.com/_images/qr_knife_web.png
Базовая информация по cookbook-ам — docs.opscode.com/essentials_cookbooks.html
Детальная информация находится тут — docs.opscode.com/chef_overview.html.

P.S. Ангина берет свое, поэтому на сим прощаюсь с Вами до второй части нашей статьи, которая будет посвящена основам «куховарения». Я открыт к критике, советам и вопросам. Спасибо за внимание!
EPAM
139,45
Компания для карьерного и профессионального роста
Поделиться публикацией

Похожие публикации

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

    +2
    а сильно ли отличается по сложности исполнение обращений к OpenStack api из шел скрипта от использования Chef? Т.е. с точки зрения администратора при использовании шефа надо знать как работает и то и другое если я правильно понимаю, вопрос не проще ли администратору разобраться только в облачном апи и запускать свои обращения каким-нибудь дженкинсом допустим?
      +3
      На самом деле, каждому свое. Chef — автоматизация процесса конфигурации. Это же не просто инструмент для запуска скриптов. Он умеет гораздо больше. Также как и основное назначение Jenkins — совсем не заменяет Chef. То, что он умеет ранить external job — это хорошо. Уместно ли в упомянутом случае это делать? Возможно Вы достигнете цели. Вопрос будет ли это оптимизированная автоматизация?
        +2
        Разрешите уточнить, «ранить» — это запускать или что-то другое?
          +2
          Так точно. Запускать. Привычный сленг пробивается, прошу прощения :)
      +5
      Такой ад шеф, для не извращенцев советую Ansible.
        +2
        Подскажите, чем он лучше? Я смотрю многие вот рекомендуют. Я, например, опасаюсь того, что мне будет не найти под него какой-нибудь готовый рецепт установщика например Oracle XE, или jdk ораклового, или там даже redis'а, который не проприетарен, как те что я выше перечислил. Плюс меня смущает, что там еще один язык, yaml.
          +2
          Yaml не язык, а разметка. К тому же, даже в шефе зачастую бывает выгоднее написать свой рецепт установки, что равносильно play-list у энсибла,.
          +4
          Ansible и Salt имеет смысл использовать когда сходятся два условия
          — лютая, бешеная любовь к python и одновременная ненависть к ruby
          — задача простая и относительно линейная

          Оба весьма декларативны и фактически в форме ML описывают конечное состояние системы. Вопросы начинаются когда конечное состояние зависит от внешних факторов или других систем
            +3
            Ну как раз в ansible можно достаточно безболезненно сделать зависимость состояния системы от процесса выполнения скрипта. Например нам надо загрузить на бекенды новую дату на балансерах поправить статику и только после этого рестартнуть бекенды. Как это сделать в шефе?
            Но, с другой стороны, в ansible пока нет ничего аналогичного chefspec или testkitchen — те инструменты, которые появились в шефе спустя кучу времени. И как то тестировать ansible, кроме как тестируя дату в вагранте шелскриптами — сложно и зачастую неоправдано.
              +3
              Возможно я что то не так понимаю, но, зачем ansible нужен chefspec и тот же testkitchen если play-файл ansible и есть тот тест который вы пишите для chef.

              Вот пример задач описаные используя yaml для ansible:

              — name: Ensure APT cache is up to date
              apt: update_cache=yes cache_valid_time=3600

              — name: Ensure sudo group rights are absent
              lineinfile: dest=/etc/sudoers regexp="^%sudo" state=absent

              — name: Ensure deploy user exists
              user: name=deploy shell=/bin/bash

              Они и есть тесты, а запуск ansible удовлетворяет их. Конечно тут уже все упирается в корректности модулей.
                +2
                Если задачи такого уровня — все ок и для шефа. Но там где есть удобоваримые проверки типа «слушает ли сервер такой-то порт», «что отдает сервер на такой-то запрос», «создались ли такие-то файлы после выполнения такого-то скрипта» в энсибле надо использовать сторонние тулы или как-то извращаться с башскриптами и втроенным регистрированием — есть такая возможность register.
                А что делать если у нас несколько ОС? Делать отдельные роли под каждую ос? Или проверять в плейбуках? И те задачи, которые в шефе решаются просто, в темплейтах энсибла могут выглядеть вот так:

                {% if ansible_distribution_version|truncate(1, True, "")|int== 6%}
                  {% set release = "squeeze"%}
                {% elif ansible_distribution_version|truncate(1, True, "")|int== 7%}
                  {% set release = "wheezy"%}
                {% endif %}
                

                То есть чем сложнее задача, тем замороченнее становится конфигурить энсибл. И на каком-то этапе шеф становится намного проще и логичнее того, что вы нагородите в энсибле. Но, повторюсь, это только для более-мение сложных задач.
                Вы не думайте, я вроде очень неплохо знаком с энсиблом и у него достаточно слабых сторон. Если не нужен сверхгибкий инструмент он подходит и подходит просто замечательно. Может через пару лет он догонит и перегонит шеф. Но пока они занимают разные ниши.
                  +2
                  Ну в целом вы правы, и на сколько я пока понял в ansible действительно легче писать отдельные роли под разные ос. Но опять же зависит от задачи, ansible во многом полагается на плагины которые по их мнению и должны решать эти задачи. Вот например модуль service, hostname у каждого есть разные стратегий в зависимости от OS.

                  Я не пробую сказать что ansible лучше или гибче всех, а то что на нем быстрее и легче можно настроить разумное количество серверов, и можно освоить за ночь.
                    +2
                    >>на нем быстрее и легче можно настроить разумное количество серверов, и можно освоить за ночь.

                    Так и есть.

                    >>ansible во многом полагается на плагины которые по их мнению и должны решать эти задачи.

                    Поэтому ждем аналога установщика для разных ОС. Но даже когда он будет, делать зависимости шаблонов от ОС надо будет руками.

                    Каждой задаче свой инструмент. И, если вы не помните, это вы говорили что шеф для извращенцев.
            +2
            А как с ansible общаться по api и не платить 10 000 баксов в год за мизерные 100 серверов?
            +2
            Большое спасибо, жду с нетерпением продолжения.
            Ответите на извечный вопрос — почему chief, а не puppet?..
              +2
              И не salt?
                +1
                А это дело личное. Например, язык манифестов/рецептов. Мне удобно было использовать Ruby. Хорошее комьюнити Chef — предостаточно готовых кукбуков, вокруг которых можно писать свои wrapper-ы. Да и просто сравнил свой небольшой опыт использования Puppet vs Chef. Chef оказался более удобным. Вышла совокупность впечатлений.
                  +2
                  Просто на слуху (во всяком случае у меня в окружении) Chef vs puppet. Вот выше порекомендовали интересный Ansible…
                    +3
                    Никогда не понимал таких холиварных сравнений. Умеешь делать автоматизацию на Puppet — делай. Умеешь на Chef — делай. Удобно? Ну и ок. Не умеет Puppet что-то — переползай на Chef или выдумывай костыль. Все предельно просто — кому нужны сравнения. Это же не спорт, это IT технологии.
                  +3
                  У них есть очень критическая разница в подходе к идемпотентности.
                  Когда обе системы применяют конфигурацию к серверу то шеф выполняет каждый шаг конфигурации последовательно, а паппет от балды или все сразу.
                  Вся ругань возникает из за порядка выполнения действий на сервере. Для шефа достаточно написать их в желаемом порядке а для паппета приходится городоить зависимости.

                  С точки зрения теории паппет прав, с точки зрения жизненного опыта шеф сильно удобнее.
                    +2
                    Честно, я начинал знакомится с Puppet и на этом все закончилось — я не смог упорядочить директивы. Потом я только понял, что там есть зависимости — но было поздно, были написаны первые рецепты Чефа.
                  +2
                  Ух ты. Шеф за 21 день! А путешествия во времени будут?

                  Теперь серьезно. Холивары на тему как готовить Шеф сейчас очень горячая тема — вот например. Грубо говоря ответа на вопрос «как правильно готовить Шеф» нету пока даже в Opscode, но к их чести, надо сказать, что они приложили большие усилия за последний год что бы собрать обобщить опыт своих клиентов и составть какой то Best Practice.

                  Я про все это говорю ибо перечитал и поучаствовал в куче подобных холиваров по долгу службы и мне кажется одна вещь обязательная для таких топиков здесь упущена — а именно опыт и инфраструктура автора. Это не из вредности, но советы людей могут быть очень противоречивыми из-за разницы окружений в которых они работают. Хорошо про это сказал Phil Dibowitz в самом начале своего выступления.
                    +2
                    С Шефом все может быть :)
                    А если серьезно — полностью согласен по поводу инфраструктуры.
                    Сделано это намеренно — дабы статьи не приобретали узконаправленный характер по компании, в которой все сделано на UNIX или Windows или Linux.
                    Поэтому я трезво отношусь к спорам, мне, как начинающему, очень интересно услышать другие идеи, но комментарии — чем «хуже/лучше» не несут идей, это просто спор.
                    В дальнейших частях будет изложен глобальный подход. Отдельным рядом пойдут статьи про решение кастомных задач, с которыми приходится встречаться.

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

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