еще интересен подход, когда на стороне stronghold/vault делается настройка, чтобы некоторые секреты были доступны только из защищенной ветки, например. тогда даже если разработчик сделает echo переменной, которую достал из vault, ему это не даст уже сделать движок хранения секретов
Unsacrificed, спасибо за аггрегатор. У меня он почему-то выкидывает некоторые маршруты, в итоге файл становитстя сильно меньше, но рутрекер(как пример) не работает. Пользуюсь сейчас github.com/rpv-tomsk/iplist, он работает корректно.
Подобное можно сделать путем указания cookbook_versions в environment + запуск chef-client в режиме dry-run.
Но зачем такое делать, если можно прогнать chef-run в Vagrant?
Да, в FoodCritic есть дефолтные проверки, которые покрывают общие случаи. Но еще с его помощью вы сами можете в коде описать свой опыт, известные вам лучшие практики и внутренние соглашения в компании. Тут я имею ввиду имено опыт в написании chef кукбуков. Нет, вы представьте! Знания, которые вы получили во время n часового дебага кукбука можно описать в коде. Коллеги скажут большое спасибо, если вы сэкономите им время.
TestKitchen. Действительно, не имеет смысла использовать TestKitchen для тестирования кукбуков вида «скопируй файл сюда, установи пакет, перезагрузи сервис». В самом начале статьи описан кейс, когда тестирование актуально.
Вот вам пример из практики.
Представьте, что вы поддерживаете хотя бы 5-10 кукбуков, которые реализуют сложные LWRP. И, допустим, ими пользются разные OPS команды(не дай бог еще в разных компаниях).
А теперь представьте LWRP для развертывания бд. Он должен реализовать установку пакетов, конфигурировать сервис, настраивать репликацию, предоставлять скрипты-хелперы для мониторинга, уметь бекапить бд на различные(облачые и не очень) сервисы. А еще нужно учесть возможность работы под разными платформами и проверять работу с разными мажорными версиями бд. Без тестов каждый коммит будет напоминать русскую рулетку. Добавили поддержку новой версии бд, отвалилась совместимость со старыми версиями. Или сломалась совместимость в новой версии кукбука, от которого наш кукбук зависит. И так далее.
Про выбор фреймворка для тестирования. Использовать Minitest или ServerSpec(RSpec), я считаю, дело вкуса. Не вижу смысла писать тесты на чистом RSpec, тк в ServerSpec уже есть некоторые готовые ресурсы. Конечно, когда выпишете сложный кукбук, вам не хватит готовых ресурсов. Как и не хватит встроенных Chef ресурсов. В ServerSpec легко добавить свои ресурсы, мы пользуемся этим регулярно. Дискуссию про тестирование ServerSpec-ом инфраструктуры поддержать не могу, т.к. такого опыта не имею.
Относительно ChefSpec. Я на практике не сталкивался с ситуациями, когда его использование оправданно. Но не исключаю, что люди найдут/уже нашли такие ситуации.
Когда нужно иметь две версии(mysql/pgsql, nginx итд) мы прибавляем к имени пакета его версию. Например, пакеты с postgresql 9.1 и 9.2 соответственно называются postgresql-9.1 и postgresql-9.2. Способ подходит, если таких пакетов мало.
еще интересен подход, когда на стороне stronghold/vault делается настройка, чтобы некоторые секреты были доступны только из защищенной ветки, например. тогда даже если разработчик сделает echo переменной, которую достал из vault, ему это не даст уже сделать движок хранения секретов
Есть мнение, что это потому что для сборки 3-10 пакетов использовать такую сложную в поддержке систему это оверкил, при наличии fpm, например.
Но зачем такое делать, если можно прогнать chef-run в Vagrant?
Да, в FoodCritic есть дефолтные проверки, которые покрывают общие случаи. Но еще с его помощью вы сами можете в коде описать свой опыт, известные вам лучшие практики и внутренние соглашения в компании. Тут я имею ввиду имено опыт в написании chef кукбуков. Нет, вы представьте! Знания, которые вы получили во время n часового дебага кукбука можно описать в коде. Коллеги скажут большое спасибо, если вы сэкономите им время.
TestKitchen. Действительно, не имеет смысла использовать TestKitchen для тестирования кукбуков вида «скопируй файл сюда, установи пакет, перезагрузи сервис». В самом начале статьи описан кейс, когда тестирование актуально.
Вот вам пример из практики.
Представьте, что вы поддерживаете хотя бы 5-10 кукбуков, которые реализуют сложные LWRP. И, допустим, ими пользются разные OPS команды(не дай бог еще в разных компаниях).
А теперь представьте LWRP для развертывания бд. Он должен реализовать установку пакетов, конфигурировать сервис, настраивать репликацию, предоставлять скрипты-хелперы для мониторинга, уметь бекапить бд на различные(облачые и не очень) сервисы. А еще нужно учесть возможность работы под разными платформами и проверять работу с разными мажорными версиями бд. Без тестов каждый коммит будет напоминать русскую рулетку. Добавили поддержку новой версии бд, отвалилась совместимость со старыми версиями. Или сломалась совместимость в новой версии кукбука, от которого наш кукбук зависит. И так далее.
Про выбор фреймворка для тестирования. Использовать Minitest или ServerSpec(RSpec), я считаю, дело вкуса. Не вижу смысла писать тесты на чистом RSpec, тк в ServerSpec уже есть некоторые готовые ресурсы. Конечно, когда выпишете сложный кукбук, вам не хватит готовых ресурсов. Как и не хватит встроенных Chef ресурсов. В ServerSpec легко добавить свои ресурсы, мы пользуемся этим регулярно. Дискуссию про тестирование ServerSpec-ом инфраструктуры поддержать не могу, т.к. такого опыта не имею.
Относительно ChefSpec. Я на практике не сталкивался с ситуациями, когда его использование оправданно. Но не исключаю, что люди найдут/уже нашли такие ситуации.
Мы такую схему использовали и вполне удачно, интересно, какие проблемы у людей возникают)
Если падает сеть, nfs отваливается. Если у вас на nfs root, то привет.