これは、小規模なホスティング会社などのマルチテナント環境に関連しています。
Puppet（または類似の）は、基本的だが重要な質量変更を処理するための適切なテクノロジーですか？例えば：
私の懸念はセキュリティと侵襲性に関するものです：
私はPuppetを本番環境で使用したことがなく、テストラボですぐに試してみただけなので、これを警告する必要があります。そのため、これを間違った方法で考えている可能性があります。
回答:
Ansible（ansible.cc）をお試しください。それはあなたのためかもしれません。クライアントで実行されているエージェントはありません。それは非常に急速に成長しています。
もう1つの非常に優れた代替策は、Salt Stackです。
AnsibleとSaltは理解しやすく、分散シェルのように、必要に応じてコマンドラインツールとして使用できます。
はい、これは確かに可能です。ただし、そうすべきかどうかはあなた次第です。
あなたの質問について：
1）十分公正。トラフィックはSSLベースであるため、証明書の管理は重要です。また、IDに関連してクライアントが提供する「事実」は信頼しないでください。これらはクライアントによって変更される可能性があるためです。クライアントのssl証明書に依存して、サーバーが誰であるかを認証したいとします。hieraのようなものを適切に使用していて、コード内で巨大なホスト名ベースのifブロックを回避する場合は正直に言うと（実際にそうする必要があります）、問題ありません。
2）パッチを当てたままにしておくことを前提にしてください。適切に構成されていれば、puppetmasterがクライアントから攻撃されるための小さなベクトルしかありません。とはいえ、侵害された場合の影響は大きいため、ロックダウンするように注意してください。
3）これは実際にはテストと展開の問題です。あなたが堅実な操り人形のコードを持っているなら、それはあなたのファイルを台無しにしないでしょう。並べ替えるのに少し時間がかかりますが、基本的には（必要なように）長くはありません。
Puppet（または類似の）は、基本的だが重要な質量変更を処理するための適切なテクノロジーですか？
はい、この方法で使用できます。これを使用して、外部クライアントシステムをサポートします。
どのサーバーにも表示してはいけない設定を表示できないようにしたい
パペットを使用している場合は、自動署名を有効にしないでください。自動署名により、ホストは証明書を自動的に要求できます。設定と権限は、ほぼ確実に証明書のCNに直接関連付けられます。ランダムコンピュータがオンラインになり、それらが実際にすべての秘密の高セキュリティ機能を備えたシステムであると主張できるようにしたくない場合。
本当に偏執的である場合は、puppetsファイルサーバー設定を調整して、一部のシステムのみがアクセスできる共有を作成できます。ファイルサーバーへのアクセスは証明書に基づいています。
Puppetにしてはいけない変更を加えたり、サーバーで手動で行った変更を元に戻したりしたくありません。
ローカルでの変更を許可するには、いくつかの異なるアプローチがあります。
私が頻繁に使用する1つの方法は次のとおりです。基本的に、リストをに渡す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を使用して行レベルの変更を行うことです。何を変更するかについては非常に保守的にしてください。
3> Puppetやそのようなツールには、自動的に元に戻す機能はありません。元に戻すには、明示的なコードを記述する必要があります。さらに、puppetの環境機能を調査し、新しいコードがテストされるテストラボ（VMの場合もあります）を用意し、コードレビューを使用できます。
/var/lib/chefデフォルトで変更されたすべてのファイルのバックアップを作成し（機密データなどのバックアップを残さないようにリソースが構成されていない限り）、docフォーマッタを使用すると、ターミナル出力に差分が表示されます。
Puppetにしてはいけない変更を加えたり、サーバーで手動で行った変更を元に戻したりしたくありません。
Puppetsファイルタイプを使用して作成された設定ファイルの場合、これは次の設定で実現できます。
replace => false,
私はそれを使用して、アプリケーションがサーバーに初めてデプロイされるときにいくつかの構成ファイルを生成しますが、その構成ファイルへの編集はPuppetによって上書きされません。
ただし、これは、Puppetがべき等のデプロイスクリプトであるという理念に反します。
できれば、puppetで管理されているファイルとは別に、puppetで管理されていない個別の管理者編集可能ファイルを用意することをお勧めします。
Puppetは、同じ構成の多くのサーバーで最適に動作します。たとえば、会社が提供する共有Webサーバーのすべての構成を記述してから、そのサーバーのN個のインスタンスを作成します。その後、すべてのインスタンスを一度に変更する（たとえば、すべてのApache仮想ホストのAllowOverrideを変更する必要があることがわかった）と、とても簡単になります。また、すべての構成情報を1か所に保存して、バージョン管理することもできます。完璧なケースでは、壊れたホストを捨て、新しいホストに交換し、同じホスト名を設定して必要な証明書に署名することで、ハードウェア障害に対処できます。他のすべては人形によって行うことができます。
しかし、2つのホスト間で構成を共有することがほとんどない場合は、puppetを使用する方が手動で構成するよりも生産性が低くなる可能性があります。また、サーバーの構成の半分をpuppetで管理し、残りの半分を手動で管理することはあまり意味がありません。
まとめ：管理するホストに統一された構造化された構成を作成できる場合、Puppetが最適ですが、各サービス（ホスト、仮想ホスト、データベース）を処理する必要がある場合、Puppetは特別に追加しません多くの価値。