Pull to refresh

Comments 12

Много и по делу, спасибо. Отличный материал для изучение в ближайшее время, очень кстати.
Спасибо. В скором времени будут еще две статьи уже для «продолжающих».
На самом деле немного неполная статья. Хорошая, видно что человек разбирался и смотрел много чего, но на практике всегда есть много ложек дегтя и получается что тестирование если и нужно использовать, то для очень ограниченного числа кукбуков.
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.
Сложную логику как-то тестировать, наверное, неплохо бы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я тоже считаю что выбор между minitest и rspec дело вкуса. Я говорил что для теста большинства кукбуков это неудобно, да и в многих других случаях тестирование кукбука сразу после прогонки не покрывает все кейсы и может быть избыточным. То есть я изначально сказал что ваша статья немного неполная.
я тут немножко с другим вопросом, но все же:
как можно делать в 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)


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

как-то можно схожей простоты достичь в шефе?
Подобное можно сделать путем указания cookbook_versions в environment + запуск chef-client в режиме dry-run.
Но зачем такое делать, если можно прогнать chef-run в Vagrant?
Если вы поддерживаете сложный 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
Ну и в принципе все :)
Мне кажется для новичка статья будет неподъемная, а для продолжающих полезнее не сама статья, а мнения из комментов.
Может устроить хабра версию foodfightshow?
Only those users with full accounts are able to leave comments. Log in, please.