Чи є Лялечка (або подібне) підходящою технологією для догляду за основними, але критичними змінами маси?
Так, це можна використовувати таким чином. Я використовую це для підтримки зовнішніх клієнтських систем.
Я не хочу, щоб жоден сервер міг бачити будь-яку конфігурацію, якої він не повинен
Якщо ви використовуєте маріонетку, ви не повинні вмикати автоматичний дизайн. Автосигналізація дозволяє хостам автоматично запитувати сертифікат. Ваша конфігурація та дозволи майже напевно будуть прив’язані безпосередньо до CN у сертифікаті. Ви не хочете, щоб випадковий комп'ютер виходив в Інтернет і мав змогу стверджувати, що він насправді є системою з усіма секретними матеріалами високої безпеки.
Якщо ви справді параноїк, ви можете налаштувати параметри файлового сервера ляльок, щоб створити спільні спільні доступу, до яких можуть отримати доступ лише деякі системи. Доступ до сервера файлів базується на сертифікатах.
Я не хочу, щоб Маріонетка вносила будь-які зміни, яких вона не повинна, або повертати будь-які зміни вручну, зроблені на сервері.
Існує кілька різних підходів до дозволу місцевих змін.
Один метод, який я часто використовую, наведений нижче. В основному, якщо ви передаєте список а source, лялечка спробує кожен елемент у списку. Тому я додаю перший елемент у списку, щоб вказати на локальний файл.
file { '/etc/ssh/sshd_config':
ensure => present,
source => ["/etc/ssh/sshd_config_local",
"puppet:///modules/ssh/$ssh_config_file"],
...
}
Іншим варіантом буде використання символьних посилань. Якщо хтось хоче використовувати лялькову версію, вони посилаються на лялькову версію файлу. Якщо вони хочуть підтримувати свою конфігурацію локально, вони не створюють символьне посилання.
file { '/etc/ssh/sshd_config_puppet':
ensure => present,
source => "puppet:///modules/ssh/$ssh_config_file",
...
}
Інша можливість - використовувати augeas для внесення змін на рівні рядків замість зміни цілих файлів. Будьте дуже консервативні щодо того, що ви змінюєте.