В целом (насколько я понимаю) основные системы управления инфраструктурой / конфигурацией (Puppet, Chef, Ansible и SaltStack) основаны на философии, согласно которой ваши серверы являются «скотом», а не «домашними животными», и кажется, что они может противоречить идее о том, что вы когда-либо будете вносить изменения в конфигурацию непосредственно на сервере.
Хотя я работал с Chef, Puppet и Salt, с точки зрения разработчика, работающего с Vagrant, всегда требовалось настроить отдельные блоки для разработки, поэтому мой опыт не помогает ответить на этот вопрос.
Возникает вопрос: поддерживает ли какая-либо из этих систем вариант использования, когда вы вносите изменения непосредственно на сервер и оставляете его там на время, не беспокоясь о том, что локальный демон собирается перезаписать его официальной конфигурацией? Вы должны иметь возможность внести изменения (и в идеале установить временное окно, в течение которого оно будет защищено от перезаписи) без каких-либо значительных изменений (например, рецептов шеф-повара или состояний соли). Вся цель этого варианта использования состоит в том, чтобы не позволить пятиминутному изменению конфигурации увязнуть в корпоративных трениях и сложностях поиска правильного (например) солевого состояния и обеспечения отсутствия побочных эффектов и прохождения выпуска / развертывания цикл и тестирование, чтобы убедиться, что вы ничего не упали в процессе.
Если вам нужен более конкретный пример, предположим, что вы хотите настроить параметры logrotate для ряда журналов, чтобы сбалансировать экономию места на диске и доступ к историческим данным. У вас есть представление о том, сколько данных вы сохраните при любой настройке и сколько данных, по вашему мнению, вам нужно сохранить, но вы не уверены на 100%. Было бы неплохо начать просто с внесения изменений и видеть (1) кто-то жалуется, что им нужно больше исторических данных для некоторой задачи отладки, или (2) вы не экономите столько места на диске, сколько ожидаете, и вам нужно экономить .
Пятиминутное изменение может фактически быть пятиминутное изменение, если ваша система управления конфигурацией позволяет ему быть единым целым, а затем, когда вы уверены, что хотите, чтобы эти изменения были внесены во все ваши ящики, которые выполняют определенную роль, вы можете позволить Chef / Puppet / Salt / Ansible управлять это для тебя.
Примечание: я не спрашиваю о сценарии использования, когда система управления конфигурациями еще нет управление определенным типом файла конфигурации, но случай, когда он уже управление определенным типом файла конфигурации, но вы хотите внести локальные изменения, чтобы они имели приоритет на данной машине, а не перезаписывались.
Поддерживает ли какая-либо из этих систем мой вариант использования? (Без необходимости бороться с системой или делать сальто назад, чтобы заставить ее работать.)
Системы управления конфигурацией поддерживают этот вариант использования, отключая их на целевом хосте на время изменения. Используя в качестве примера chef, вы бы отключили chef-client на узле. Это приведет к тому, что узел будет отображаться как «устаревший» на сервере Chef, но это полезное напоминание о том, что узел не соответствует требованиям и что изменение следует либо откатить, либо откатить.
Для отдельных файлов вы можете использовать chattr + i, и ни один инструмент, который я видел, не знает, как обойти.
Одна дополнительная мысль для шеф-повара - для шаблонов файлов, где файл не существовал до первоначального запуска шеф-повара, вы можете указать шефу: create_if_missing, чтобы он коснулся файла только один раз.
Вы не упомянули PowerShell DSC, но я выделю для этого пару методов, особенно потому, что PowerShell выходит на другие системы, кроме Windows. Некоторые из этих методов могут иметь эквиваленты в других вариантах.
Я могу придумать четыре метода работы с вашим случаем с помощью DSC:
Преимущество следующих вариантов состоит в том, что ваше изменение становится «частью рецепта» и может быть повторно создано.
Независимо от того, используете ли вы выталкивающие или выталкивающие модели DSC, вы можете внести эти изменения для одной или нескольких машин.
Не принимая во внимание на данный момент возможное несоответствие концепции как управления конфигурацией системы из системы CM, так и не делая это в то же время, что комментаторы уже отметили ...
Следует отметить, что для этого варианта использования обычно можно использовать то, что стало условностью с современным серверным программным обеспечением - .d каталоги конфигурации, которые позволяют вставлять дополнительные фрагменты конфигурации в нужные места.
Таким образом, вы можете настроить CM для управления конфигурацией за вас, например, /etc/logrotate.d/local-whatever, в то же время вы все еще можете возиться с конкретной машиной, добавив /etc/logrotate.d/local-aaa-whatever или подобное, что затем заставит программное обеспечение обработать ваши переопределенные настройки.
Очевидно, что если у CM есть рецепты, нацеленные на контроль всего /etc/logrotate.d/ у вас по-прежнему нет другого выхода, кроме как делать что-то в CM.