Тестируем Chef cookbook

  • Tutorial


Концепция infrastructure as code позволяет нам применять к инфраструктуре решения из мира разработки. Отдельные компоненты инфраструктуры в проектах часто повторяются. При интеграции таких компонентов наиболее удобный вариант – общие кукбуки. Код кукбуков постоянно меняется, фиксятся баги, появляется новый функционал. С помощью тестирования мы отслеживаем регрессии, контролируем обратную совместимость и внедряем новые фичи быстрее.
В этой статье мы познакомимся с инструментами для тестирования, напишем простой кукбук и тест к нему.



Что тестируем


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

  1. Ruby Style Guide. В Ruby мире нет style guide от разработчиков языка, но есть style guide от сообщества. Так как код кукбуков пишется на ruby, хорошо следовать практикам, которые уже есть в сообществе;
  2. Cookbook linter. За время существования chef накопилось большое количество паттернов и анти-паттернов, их необходимо учитывать при написании кукбука;
  3. Интеграционное тестирование. После внесения изменений необходимо проверить работоспособность кукбуков, пограничные условия и интеграцию с другими кукбуками.

Ruby Style Guide


Для проверки ruby на соответствие style guide используется утилита Rubocop.
Утилита ставится командой gem install rubocop, проверить код можно командой 'rubocop .', большинство ошибок можно исправить автоматически, для этого надо воспользоваться опцией -a.
Если нужно для некоторых файлов отключить некоторые проверки, то надо создать файл .rubocop.yml и указать в нем исключения.

Пример. Для всех поддиректорий в директории test отключаем проверку на длину метода для файла spec_helper.rb:
MethodLength:
  Exclude:
    - 'test/**/spec_helper.rb'

Cookbook linter


Стиль кукбуков и выявление известных ошибок осуществляется с помощью утилиты Foodcritic. Утилита ставится командой gem install foodcritic, запускается командой foodcritic <путь до кукбука>
Пример работы:
foodcritic .
FC017: LWRP does not notify when updated: ./providers/default.rb:32

В случае, если Foodcritic нашел какие-то проблемы, на сайте проекта http://acrmp.github.io/foodcritic/ есть инструкции по их исправлению.

Интеграционное тестирование


Для интеграционного тестирования компания Chef выпустила утилиту Test Kitchen, http://kitchen.ci. Эта утилита подготавливает среду для тестирования и запускает ваши тесты. В простом случае Test Kitchen запускает виртуальную машину, в ней запускает chef-client и после прохождения chef-run запускает тесты.
Виртуальные машины запускаются через Vagrant. В качестве гипервизора можно использовать всё, что поддерживает Vagrant. Помимо использования виртуальных машин Test Kitchen умеет работать с публичными и приватными облаками.
Тесты можно писать с помощью различных фрейморков. Из коробки поддерживаются Bats, shUnit2, RSpec и Serverspec. Язык тестов Bash(Bats, shUnit2) или Ruby( RSpec, Serverspec). Одновременно один и тот же кукбук можно тестировать под разными операционными системами и с разными наборами тестов.

Тестирование с помощью Test Kitchen


Для того, чтобы писать тесты и вообще работать с chef кукбуками в современном мире используется Chef Development Kit. ChefDK устанавливает собственную инсталляцию языка ruby и всех гемов, которы нужны для работы chef. Таким образом инсталяция chef не будет зависеть от вашего системного руби, это позволит избежать множества проблем с кросс-зависимостями gem-ов и и тд.
В поставку ChefDK входит сам chef и большинство нужных гемов. Если какого-то гема не хватает, то его можно установить командой:
chef gem install <имя гема>.
Скачать ChefDK под вашу платформу можно тут: https://downloads.chef.io/chef-dk/

Тестируемый кукбук


Для обучения тестированию напишем простой кукбук deploy-user который будет создавать пользователя deployer и домашнюю директорию /home/deployer. В реальной жизни для создания пользователей можно(и нужно) пользоваться уже готовыми кукбукам сообщества.
Для генерации скелета кукбука воспользуемся командой: chef generate cookbook deploy-user. На выходе получим директорию deploy-user с кукбуком.
чем генерировать скелет?
Исторически пустой кукбук можно было создать командой
knife cookbook create <name>
– Эта команда создает кукбук в директории, которая прописана в настройках knife, не создает скелет тестов, не создает chefignore файл, не создает git репозиторий, зато создает много лишних директорий под все сущности chef. Хотя, в 2010-ом году и это было очень круто =)
berks cookbook <name>
– создает скелет при помощи утилиты berkshelf(это как bundler в ruby мире)
chef generate cookbook <name>
– создает скелет при помощи утилиты chef из ChefDK.
berks cookbook и chef generate делают примерно одно и тоже. Разница в мелочах, которые мы не будем рассматривать в рамках этой статьи. В любом случае вы всегда можете добавить/удалить что вам нужно.
В конечном итоге можно написать несложный Thor/Rack таск, который учтет все ваши пожелания.

Создадим директорию attributes и файл default.rb в ней. В файле default.rb определим переменные с именем пользователя и его shell.
attributes/default.rb:
default['deploy-user']['username'] = 'deployer'
default['deploy-user']['shell'] = '/bin/bash'

В файле recipes/default.rb вызовем стандартный ресурс user и передадим ему наши параметры
recipes/default.rb:
user node['deploy-user']['username'] do
  shell node['deploy-user']['shell']
  supports manage_home: true
end

Для нашего примера такого простого кукбука будет вполне достаточно.

kitchen.yml


Вся конфигурация Test Kitchen описывается одним файлом .kitchen.yml. Этот файл у нас уже есть, он был сгенерирован утилитой chef.
Давайте пройдемся по содержимому .kitchen.yml.
Конфиг разделен на секции, каждая секция отвечает за разные аспекты процесса тестирования.

Дефолтный .kitchen.yml:
---
driver:
  name: vagrant

provisioner:
  name: chef_zero

platforms:
  - name: ubuntu-12.04
  - name: centos-6.5

suites:
  - name: default
    run_list:
      - recipe[deploy-user::default]
    attributes:


В секции driver описываются параметры драйвера работы с виртуальными машинами. В простом случае мы используем Vagrant.

В секции provisioner мы указываем кто будет исполнять код тестируемого кукбука. В случае с Chef есть два варианта, chef-solo и chef-zero. В современном мире использовать chef-solo без особой необходимости не требуется. Также можно указать некоторые дополнительные опции, например, какую версию Chef ставить. Если ваш кукбук не работает с Chef 12, то можно явно указать версию require_chef_omnibus: 11.18.6.

Секция platforms описывает на каких ОС будет тестироваться наш кукбук. Например, добавить Ubuntu 14.04 можно так: ' — name: ubuntu-14.04'.

ВАЖНО для каждого драйвера и платформы существуют свои vagrant box-ы по умолчанию. Если вам нужно поменять настройки по умолчанию, то драйверу надо передать соответствующую команду.

Пример: гипервизор Parallels Desktop и custom box.
platforms:
  - name: ubuntu-14.04
    driver:
      provider: parallels
      box: express42/ubuntu-14.04

При такой записи(company/image) образ берется с сервиса https://atlas.hashicorp.com, вы можете указать просто url box-а через опцию box_url.

Наконец, секция suites описывает набор рецептов, который необходимо выполнить перед запуском тестов. У нас один suite с именем default. В нем описан run-list с одним рецептом deploy-user::default. Это тот рецепт, в котом мы описывали создание пользователя.

Работа с Test Kitchen


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

Посмотреть список машин и их состояние можно командой kitchen list. Заметьте, у нас описан только один suite, поэтому будут созданы только две машины: default-ubuntu-1404 и default-centos-70. Если бы мы описали еще один suite, то количество машин бы удвоилось. Конечное количество машин равно: количество suites умножить на количество platforms

Командой kitchen converge мы запустим создание виртуальных машин и запуск всех suites для всех платформ. Запустить один suite на одной платформе можно так: kitchen converge default-ubuntu-1404. Чтобы удалить все машины и вернуть всё как было существует команда kitchen destroy.
как выключить виртуальную машину
Забавный факт, средствами Test Kitchen нельзя выключить машины не удаляя их. На Github об этом есть эпичная сага в нескольких действиях issue https://github.com/test-kitchen/test-kitchen/issues/350

После выполнения kitchen converge мы получим запущенные виртуальные машины с выполненным рецептом default.rb из нашего кукбука deploy-user.

Если в коде кукбука есть ошибки, chef-run прервется и будет показано место в коде, которое вызвало ошибку. Считаем, что chef-run прошел успешно =). Далее давайте проверим, действительно-ли suite отработал правильно и сделал, что мы от него ждали. С помощью команды kitchen login default-ubuntu-1404 войдем на одну из машин.

Выполним команду getent passwd deployer:
deployer:x:1001:1001::/home/deployer:/bin/bash

И правда, пользователь deployer создан, используется верная home директория и используется нужным нам shell.

Теперь проверим, что для пользователя создана home директория и у нее верный владелец, группа и права доступа: ls -lah /home/deployer/.
drwxr-xr-x 2 deployer deployer 4096 Mar 15 23:12 .
drwxr-xr-x 4 root     root     4096 Mar 15 23:12 ..
-rw-r--r-- 1 deployer deployer  220 Apr  8  2014 .bash_logout
-rw-r--r-- 1 deployer deployer 3637 Apr  8  2014 .bashrc
-rw-r--r-- 1 deployer deployer  675 Apr  8  2014 .profile

Действительно, домашняя директория существует и имеет верного владельца, группу и права доступа.

Ура, теперь вы умеете тестировать кукбуки!

Шутка =)

Тестирование


Для запуска тестов есть две команды kitchen verify и kitchen test.

kitchen verify ставит фреймворк для тестирования внутрь vm и запускает ваши тесты. Вы можете править ваши тесты и повторно запустить verify.

kitchen test запускает полный цикл тестирования. В первую очередь выполняется kitchen destroy, если до этого машина была создана, затем выполняются suites, прогоняются тесты и в конце иногда выполняется destroy. По умолчанию destroy производится, если тесты прошли успешно. Такое поведение можно переопределить через опции команды kitchen test.

В наши дни кукбуки принято тестировать фреймворком Serverspec, http://serverspec.org. Serverspec это расширение RSpec, которое предоставляет удобные примитивы для тестирования серверов. С выходом serverspec люди перестали писать тесты на чистом RSpec(как и на bash).

Если сейчас запустить kitchen verify, то мы увидим, что за нас написали пустой тест:

       deploy-user::default
         does something (PENDING: Replace this with meaningful tests)

       Pending: (Failures listed here are expected and do not affect your suite's status)

         1) deploy-user::default does something
            # Replace this with meaningful tests
            # /tmp/busser/suites/serverspec/default_spec.rb:8


       Finished in 0.00185 seconds (files took 0.3851 seconds to load)
       1 example, 0 failures, 1 pending

       Finished verifying <default-ubuntu-1404> (0m36.87s).


Откроем файл test/integration/default/serverspec/default_spec.rb и напишем тест на наш кукбук:
require 'spec_helper'

describe 'deploy-user::default' do

  describe user('deployer') do
    it { should exist }
    it { should have_home_directory '/home/deployer' }
    it { should have_login_shell '/bin/bash' }
  end

  describe file('/home/deployer') do
    it { should be_directory }
    it { should be_mode 755 }
    it { should be_owned_by 'deployer' }
    it { should be_grouped_into 'deployer' }
  end

end


В коде описаны действия, которые мы делали на машине вручную.
Пользователь deployer должен существовать, иметь home директорию /home/deployer, и иметь shell /bin/bash.
/home/deployer должно быть директорией, иметь права доступа 755, владельца deployer и группу deployer.

В случае если мы нигде не ошиблись, то результат kitchen verify будет таким:
deploy-user::default
         User "deployer"
           should exist
           should have home directory "/home/deployer"
           should have login shell "/bin/bash"
         File "/home/deployer"
           should be directory
           should be mode 755
           should be owned by "deployer"
           should be grouped into "deployer"

       Finished in 0.10972 seconds (files took 0.306 seconds to load)
       7 examples, 0 failures

       Finished verifying <default-ubuntu-1404> (0m1.92s).


Ура, теперь вы умеете тестировать кукбуки!

Бонус. Unit тестирование


В мире Сhef также существует unit тестирование. Для него используется инструмент chefspec, http://sethvargo.github.io/chefspec/. Основное отличие от тестирования через Test Kitchen заключается в том, что создания виртуальных машин и запуска chef-run не происходит. Вместо этого проверяется вызов ресурса с нужными параметрами. Это может быть полезно, когда какие-то ресурсы нельзя протестировать обычным способом. Например, если выполнение ресурса зависит от внешней системы или требует специфического оборудования. Ну и такие тесты можно прогонять в любой CI системе. Из минусов стоит отметить, что таким способом сложно тестировать LWRP.

Пример такого теста можно посмотреть ниже.

spec/unit/recipes/default_spec.rb
require 'spec_helper'

describe 'deploy-user::default' do

    let(:chef_run) do
      runner = ChefSpec::ServerRunner.new
      runner.converge(described_recipe)
    end

    it 'converges successfully' do
      chef_run # This should not raise an error
    end

    it 'creates a user deployer with home "/home/deployer" and shell "/bin/bash"' do
      expect(chef_run).to create_user('deployer').with(
        home: '/home/deployer',
        shell: '/bin/bash')
    end

end


Если в файл spec/spec_helper.rb дописать строчку at_exit { ChefSpec::Coverage.report! }, то после окончания тестов будет выводиться процент покрытия.

Запустить эти тесты можно командой chef exec rspec -c
..

Finished in 0.51553 seconds (files took 3.34 seconds to load)
2 examples, 0 failures

ChefSpec Coverage report generated...

  Total Resources:   1
  Touched Resources: 1
  Touch Coverage:    100.0%

You are awesome and so is your test coverage! Have a fantastic day!

Полезная документация


Поделиться публикацией

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

    +2
    Много и по делу, спасибо. Отличный материал для изучение в ближайшее время, очень кстати.
      0
      Спасибо. В скором времени будут еще две статьи уже для «продолжающих».
      0
      На самом деле немного неполная статья. Хорошая, видно что человек разбирался и смотрел много чего, но на практике всегда есть много ложек дегтя и получается что тестирование если и нужно использовать, то для очень ограниченного числа кукбуков.
      foodcritic при всей его няшности и скорости содержит всего 45 правил. Еще 2-3 правила можно найти в сторонних рецептах для него.
      serverspec та же история — всего ничего проверок, который *и так* должны присутствовать в нормальном кукбуке, потому что идемпотентность, все дела. Если ресурс после старта сервиса не проверяет что сервис стартанул успешно — отдал 0 exit status, то это проблема кукбука, а большинство ресурсов сервис спека вообще какая-то адовая фигня типа
      describe package('httpd') do
        it { should be_installed }
      end
      

      Это вообще ни о чем, если использовать совместно с шефом. Пару кейсов может и покроет, например что-то типа когда сервис стартует, отдает хороший статус и потом ложится, но это уже задача мониторинга и не факт что запущенный сразу после рецепта серверспек отлично отработает. на сервисе, который падает через 20 секунд после старта. Поидее это должны решить интеграционные тесты.

      Поехали дальше: testkitchen в принципе очень хорош собой, хорошая идея, поддержка chef-zero, но нет никакой возможности заюзать какой-то провиженер кроме шефа. Отлично подходит чтобы тестить общие кукбуки типа nginx, mysql или haproxy, но всякие продуктовые штуки, которые не деплоятся шефом ( а шефом деплоить продукт на сервера ОЧЕНЬ неудобно ) им тестить нельзя. Соответственно для большинства пользователей, которые не пишут свои кукбуки для широкого потребления — почти бесполезен.

      ну и ChefSpec — вообще полный угар и содомия, как и почти все поделки sethvargo, типа chef sugar. Почти полностью бесполезная и левая вещь в себе, учитывая идеологию chef. Сложные штуки не покрывает, не понимает разницу между стадией компиляции и стадией выполнения и в целом является просто переписанным другим DSLем кукбуком. Потому что Unit тестирование вполне годится для ruby программ, в которой можно переписать функцию, но всегда проверять что она так же как и работала работает на вход и выход, но не годится для chef, в котором большинство ресурсов которые стоит использовать — идемпотенты и вообще идеология шефа состоит в том что ты пишешь что-то вроде «тут должен быть запущен nginx», а шеф уже сам все делает и проверяет что nginx запущен.

      То есть в каких то случаях тестирование кукбука очень удобно, но в большинстве случав с которыми пришлось столкнуться мне это чепуха не о чем, даже при разработке кукбука и всегда более мение хватает vagrant + какой-то minitest или rspec.
        0
        Сложную логику как-то тестировать, наверное, неплохо бы.

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

        А в чем проблемы с chef-sugar?
          0
          ServerSpec действительно неплох, если не тестировать им кукбуки)

          Chef sugar — хорошая задумка, но 1) он полупустой 2) внятных кейсов использования два с половиной
          Могу в принципе описать почему я так считаю, если вас интересует мое мнение.

          Сложную логику действительно надо тестировать отдельно, но даже всякие враперы или самописные штуки не удобно тестировать описанными выше инструментами.
          Например, насколько я знаю основные кейсы использования шефа — написание своих кастомных кукбуков типа «скопируй файл сюда, помести темплейт сюда, установи то, то и то», написание своих кукбуков с ресурсами и разнообразные врапперы.

          В первом случае мы используем ресурсы с гарантированной проверкой на стороне шефа. Если файл не может скопироваться или темплейт не создается или не создается каталог — с ошибкой выпадет шеф. Точно так же будет если не установится программа.

          Во втором случае, если мы пишем ресурсы — мы должны сами обеспечить такое поведение. В последнее время в моде разнообразные LWRP и подключение библиотек, там тестирование проходит уже как тестирование руби кода. Возможно тут пригодится интеграционное тестирование с test kitchen, но опять же — ОЧЕНЬ много нюансов.

          Врапперы тоже почти невозможно тестировать указанным выше способом по причинам описанным в первом пункте. Ну то есть тестировать можно, но смысла в этом немного, потому что шеф позиционируется как инструмент в логикой «тут должен быть nginx», а не «установи nginx».
            0
            Я из chef sugar использую только compile_time, на самом деле :-)

            Проблемы могут быть, если например, конфиг кривой и сервис не поднялся, и при этом инитскрипт кривой — эти случаи и имеет смысл тестировать серверспеком.

            Только сейчас заметил, в шеф теперь подобного рода тестирование встроено, можно запускать серверспеки в конце применения кукбуков, или например верифицировать конфиги прямо в ресурсе: docs.chef.io/release_notes.html
              0
              Отвечу сразу на два комментария.

              Да, в FoodCritic есть дефолтные проверки, которые покрывают общие случаи. Но еще с его помощью вы сами можете в коде описать свой опыт, известные вам лучшие практики и внутренние соглашения в компании. Тут я имею ввиду имено опыт в написании chef кукбуков. Нет, вы представьте! Знания, которые вы получили во время n часового дебага кукбука можно описать в коде. Коллеги скажут большое спасибо, если вы сэкономите им время.

              TestKitchen. Действительно, не имеет смысла использовать TestKitchen для тестирования кукбуков вида «скопируй файл сюда, установи пакет, перезагрузи сервис». В самом начале статьи описан кейс, когда тестирование актуально.
              Вот вам пример из практики.
              Представьте, что вы поддерживаете хотя бы 5-10 кукбуков, которые реализуют сложные LWRP. И, допустим, ими пользются разные OPS команды(не дай бог еще в разных компаниях).
              А теперь представьте LWRP для развертывания бд. Он должен реализовать установку пакетов, конфигурировать сервис, настраивать репликацию, предоставлять скрипты-хелперы для мониторинга, уметь бекапить бд на различные(облачые и не очень) сервисы. А еще нужно учесть возможность работы под разными платформами и проверять работу с разными мажорными версиями бд. Без тестов каждый коммит будет напоминать русскую рулетку. Добавили поддержку новой версии бд, отвалилась совместимость со старыми версиями. Или сломалась совместимость в новой версии кукбука, от которого наш кукбук зависит. И так далее.

              Про выбор фреймворка для тестирования. Использовать Minitest или ServerSpec(RSpec), я считаю, дело вкуса. Не вижу смысла писать тесты на чистом RSpec, тк в ServerSpec уже есть некоторые готовые ресурсы. Конечно, когда выпишете сложный кукбук, вам не хватит готовых ресурсов. Как и не хватит встроенных Chef ресурсов. В ServerSpec легко добавить свои ресурсы, мы пользуемся этим регулярно. Дискуссию про тестирование ServerSpec-ом инфраструктуры поддержать не могу, т.к. такого опыта не имею.

              Относительно ChefSpec. Я на практике не сталкивался с ситуациями, когда его использование оправданно. Но не исключаю, что люди найдут/уже нашли такие ситуации.
                0
                Про фудкритик вы очень красиво написали, я надеюсь вы заопенсорсили свои правила? С удовольствием бы на них посмотрел и посчитал бы количество :) Я не спорю, звучит просто отлично, но из rubocop на самом деле больше пользы.

                По TestKitchen вы тоже все правильно ответили, есть кейсы когда это может быть удобным: я их упомянул («тестить общие кукбуки типа nginx, mysql или haproxy»), а вы — развернули в отдельный ответ. Действительно, такие штуки удобно тестить при помощи TestKitchen, но если мы хотим покрыть еще больше разных кейсов, в том числе и CI всего этого, то тогда лучше писать про jenkins, packer и так далее. Потому что в кейсе testkithen + разные операционные системы и вообще AWS, DO, xen, docker packer очень хорошо смотрится. Убедительнее.

                Я тоже считаю что выбор между minitest и rspec дело вкуса. Я говорил что для теста большинства кукбуков это неудобно, да и в многих других случаях тестирование кукбука сразу после прогонки не покрывает все кейсы и может быть избыточным. То есть я изначально сказал что ваша статья немного неполная.
          0
          я тут немножко с другим вопросом, но все же:
          как можно делать в puppet'e — в конфиге сервера указывается что для environment «development» директория такая-то (там лежит незакомичченое в мастер добро).
          Идем на конечную ноду, выполняем команду вида
          puppetd --test --verbose --environment development --noop
          

          где noop = dry-run, т.е. ничего не делать
          вывод такой:
          root@kappa1:~# puppetd --test --verbose --environment development --noop
          notice: Ignoring --listen on onetime run
          info: Caching catalog for kappa1.xxxx.ru
          info: Applying configuration version '1426878058'
          notice: /Stage[main]/Smartmontools/File[/etc/smartd.conf]/content:
          --- /etc/smartd.conf    2015-03-20 22:02:18.000000000 +0300
          +++ /tmp/puppet-file20150320-733013-woiq4a-0    2015-03-20 22:02:28.000000000 +0300
          @@ -1,4 +1,3 @@
          -#inserted by hand for example
           # this is puppet generated file, don't mess with it, gonna be overwritten
          
           # /etc/smartd.conf
          
          notice: /Stage[main]/Smartmontools/File[/etc/smartd.conf]/content: current_value {md5}3efca6dd8a344981e69d2dec4aada487, should be {md5}30829791beb5e133009eeadfbaf5142c (noop)
          
          

          смотрим на ошибки в синтаксисе/рецепте/кукбуке (типа поменялось то что не должно было и т.п.), комиттим, раскатывается уже дальше из мастера

          как-то можно схожей простоты достичь в шефе?
            0
            Подобное можно сделать путем указания cookbook_versions в environment + запуск chef-client в режиме dry-run.
            Но зачем такое делать, если можно прогнать chef-run в Vagrant?
              0
              Если вы поддерживаете сложный LWRP — такое делать незачем, но если вы пишете кукбук для компании и\или ваш уровень не высок и\или в кукбуке есть зависимости от датабегов и поиска нод и\или вы хотите протестить что-то на qa с живим продуктом готовыми тестами продукта — смысл есть. Тут или-или: или вы прогоняете кукбук в вагранте, доабвляете его в шеф сервер, выставляете окружение прода и так далее (что тоже не всегда прокатывает) и смотрите на результат (тут бывают проблемы с небыстрым добавлением новоподнятых нод и их атрибутов в индекс шефа), или держите отдельное окружение типа stage и пините кукбуки.

              Я попробую немного дополнить ваш комментарий: мы сейчас в некоторых случаях используем vagrant + docker контейнеры (для быстрого поднятия) и тестим простые случаи или сложную логику в них. Для того чтобы затестить что-то интеграционное у нас есть отдельное окружение на котором мы можем прогонять новые кукбуки перед тем как выливать их в прод. А процес выливания происходит так:
              1) поднимаем версию кукбука
              2) пиним ее в этом окружении
              3) если все ок — пиним ее в прод

              Тут стоит учесть, что в любом окружение выбирается максимально высокая версия кукбука если она не запиненая, поэтому все нужные кукбуки должны быть запинены в окружениях. Один из самых удобный инструментов для того чтобы пинить кукбуки — knife spork. Таким образом, если нам надо изменить конфиг для nginx мы совершаем такие действия:

              knife spork omni nginx-grammarly # поднимает версию кукбука, заливает его в шеф и пинит в qa кукбуке
              # тут идет прогон тестов qa команды
              knife spork promote prod nginx-grammarly # пинит кукбук в прод
              


              Окружение может меняться в зависимости от потребностей и вместо qa можно использовать stage, тогда команда omni должна получить дополнительный флаг -e stage
              Ну и в принципе все :)
            +1
            Мне кажется для новичка статья будет неподъемная, а для продолжающих полезнее не сама статья, а мнения из комментов.
            Может устроить хабра версию foodfightshow?

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

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