Я всегда работал там, где раньше запускали Puppet через определенные промежутки времени. Таким образом, распространение изменений было простым и оперативным. В новой команде они недовольны тем, что регулярно запускают агента Chef. Они используют его только для начальной загрузки ОС, а затем ее уничтожения. Я не понимаю, зачем кому-то использовать инструмент управления конфигурацией, такой как Chef, без необходимости регулярно его запускать. Независимо от того, что мы делаем, начальную загрузку можно выполнить с помощью базовых сценариев оболочки - установите программное обеспечение xyz, скопируйте файл конфигурации, перезапустите службу.
Они говорят, что слишком опасно запускать его через регулярные промежутки времени в производственной среде, поскольку они не уверены, идемпотентен ли код.
Мои запросы:
Есть такие инструменты, как Terraform, которые на самом деле ориентированы на эту часть процесса. Я также использую ansible для некоторых специальных задач, которые не нужно часто запускать повторно.
Тем не менее, как правило, рекомендуется запускать управление конфигурацией хотя бы раз в час. Предоставление или удаление доступа часто происходит через эти механизмы, и задержка обновлений может вызвать проблемы с соответствием или удобством использования. В одном большом магазине мы разделили марионетку на две, чтобы можно было приостановить работу конкретного приложения, не нарушая «теневую марионетку», которая обрабатывала обновления контроля доступа, и «не могла» быть отключена.
Если вы напишете плохие рецепты, вы можете очень быстро уничтожить всю продукцию. Наличие некоторого процесса, в котором роли передаются в QA и проверяются перед переходом к постановке и повторно проверяются перед переходом к производству. Chef имеет встроенные механизмы тестирования. Аналогичные методы можно использовать и с другими.
Я бы сначала сосредоточился на проблемах, которые скрываются под ковром. Если вы не запускаете свои рецепты часто, вы не заметите, когда они перестают работать из-за изменений в ОС или ваших приложениях.
Затем я бы упомянул, что изменения могут быть внесены везде довольно быстро, когда это необходимо. Интервал между запусками шеф-повара должен быть максимальным временем, в течение которого вы готовы ждать, пока изменение распространится в вашей среде.
В основном. Если это сработает для них достаточно хорошо, они могут не видеть необходимости что-либо менять. Возможно, вам потребуется создать демонстрацию, чтобы показать ценность и сделать ее реальной для людей. Или вам может потребоваться подождать, пока ваша организация созреет до такой степени, что сможет справиться с тем, что вы преподаете.
Главное, что вы, кажется, не учитываете, - это возможное влияние на производительность. Если приложение действительно чувствительно к тому, что работает в фоновом режиме, вы можете увидеть более низкую пропускную способность или большую задержку во время работы Chef. В этом случае вам нужно изменить рецепты или дать им работать только в непиковые часы.
Еще я видел, как происходит истощение памяти. Приложение постепенно поглощает память, пока шеф-повар не перестанет работать. Надеюсь, у вас есть мониторинг уровня памяти и того, работает ли шеф-повар, чтобы уловить подобные вещи.
Помимо производительности и памяти, я бы посоветовал прочитать такую книгу, как Отпустить это многое объясняет о том, как создавать надежные производственные системы.