История изменений

Спорно. Это говорит лишь о том, что человек не умеет правильно использовать системы централизованного управления, распределяя изменения только на нужный scope узлов сети.

Имеется ввиду не отказ от централизованного администрирования, а подбор других инструментов. Другой пример на тему: написание сборщика мусора для C++ решается выкидыванием С++.

Если ты администриуешь сеть сервером/ВМ, система централизованного управления должна быть установлена на всех. Аксиома.

Это безусловно так.

Если на отдельном узле разработчики занимаются неожиданными вещами или идёт тестирование, то там лишь нужно вмешиваться по минимуму. Может быть, даже вообще отключить все правила. Но не удалять агента puppet/cfengine/chef/hpsa и т.д.

Ну это понятно. Как разрабатывать это личное дело каждого. Вопрос в том, как потом переносить результаты в production.

Рабочий подход: написать класс, в параметры которого вынесено то, что отличает стенд от боевого применения (адреса сервисов, shared buffers для postgres и т.д). При разворачивание в манифест ноды цепляется этот класс с нужными параметрами. Если нужно что-то поменять: правится модуль, разворачивается на стенд, тестируется, переносится в production. Сами манифесты нодов меняются редко.

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

Или склонировать кусочик своей. Ну не верю я, что на puppet можно писать универсальные модули.

Спорно. Это говорит лишь о том, что человек не умеет правильно использовать системы централизованного управления, распределяя изменения только на нужный scope узлов сети.

Имеется ввиду не отказ от централизованного администрирования, а подбор других инструментов. Другой пример на тему: написание сборщика мусора для C++ решается выкидыванием С++.

Если ты администриуешь сеть сервером/ВМ, система централизованного управления должна быть установлена на всех. Аксиома.

Это безусловно так.

Если на отдельном узле разработчики занимаются неожиданными вещами или идёт тестирование, то там лишь нужно вмешиваться по минимуму. Может быть, даже вообще отключить все правила. Но не удалять агента puppet/cfengine/chef/hpsa и т.д.

Ну это понятно. Как разрабатывать это личное дело каждого. Вопрос в том, как потом переносить результаты в production.

Рабочий подход: написать класс, в параметры которого вынесено то, что отличает стенд от боевого применения (адреса сервисов, shared buffers для postgres и т.д). При разворачивание в манифест ноды цепляется этот класс с нужными параметрами. Если нужно что-то поменять: правиться модуль, разворачивается на стенд, тестируется, переносится в production. Сами манифесты нодов меняются редко.

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

Или склонировать кусочик своей. Ну не верю я, что на puppet можно писать универсальные модули.