構成管理システムは、サーバー上で直接行われた構成変更を明示的にサポートしていますか？
一般に（私が見る限り）主要なインフラストラクチャ/構成管理システム（Puppet、Chef、Ansible、SaltStack）は、サーバーは「ペット」ではなく「牛」であるという哲学に基づいており、サーバーに対して直接構成を変更するという考えに反する可能性があります。
私はChef、Puppet、Saltと協力してきましたが、開発者がVagrantと協力して個々のボックスを開発用にセットアップするという観点から常に取り組んできたため、私の経験はこの質問に答えるのに役立ちません。
問題は、これらのシステムのいずれかが、サーバーに直接変更を加え、ローカルデーモンが公式の構成で上書きすることを心配せずに、しばらくの間サーバーをそのままにしておくユースケースをサポートしていますか？シェフのレシピやソルトの状態に大きな変更を加えることなく、変更を加えることができるはずです（理想的には、上書きから保護される時間枠を設定できます）。このユースケースの全体的な目的は、企業の摩擦や、適切な（たとえば）塩の状態を見つけて副作用がないことを確認し、リリース/展開を行うことの複雑さによって、5分間の構成変更が滞らないようにすることです。サイクルとテストを行って、プロセスで何も失敗していないことを確認します。
より具体的な例が必要な場合は、ログローテーション設定を多数のログに合わせて調整し、ドライブスペースの節約と履歴データへのアクセスのバランスをとるとします。特定の設定で保存するデータの量と、保持する必要があると思われるデータの量はわかっていますが、100％確実ではありません。変更を加えるだけで始めて、（1）デバッグタスクのためにより多くの履歴データが必要であると誰かが不満を言っている、または（2）期待したほど多くのドライブ容量を節約しておらず、節約する必要があるのを見るのは素晴らしいことです。 。
5分間の変更は、実際にはbe 5分間の変更である可能性があります。これは、構成マンガシステムで1つにすることが許可されている場合です。その後、すべてのボックスでこれらの変更が必要であると確信できたら、特定の役割については、Chef/Puppet/Salt/Ansibleに管理させることができます。
注：構成管理システムがまだ特定のタイプの構成ファイルを管理しているユースケースについては質問していませんが、すでに管理している場合特定の種類の構成ファイルですが、ローカルで変更を加え、その特定のマシンで優先され、上書きされないようにする必要があります。
これらのシステムのいずれかが私のユースケースをサポートしていますか？ （システムと戦ったり、システムを機能させるためにバックフリップを実行したりする必要はありません。）
構成管理システムは、変更の期間中、ターゲットホストでそれらを無効にすることにより、このユースケースをサポートします。例としてchefを使用すると、ノードでchef-clientを無効にします。これにより、Chefサーバーでノードが「古い」と表示されますが、ノードが準拠していないため、変更をロールフォワードまたはロールバックする必要があることを思い出してください。
個々のファイルに対して、chattr + iを実行できます。これは、バイパスする方法を知っているツールはありません。
Chefに関するもう1つの考え-元のchefの実行前にファイルが存在しなかったファイルテンプレートの場合、ファイルに一度だけ触れるように、chefに：create_if_missingを指示できます。
PowerShell DSCについては言及していませんが、特にPowerShellがWindows以外のシステムに導入されるため、そのためのいくつかの方法を紹介します。これらの方法のいくつかは、他のオプションに同等のものがあるかもしれません。
DSCでケースを処理する4つの方法を考えることができます。
- どのリソースでもテストされていないものを変更しても、それが捕まることがないだけです。これは他のレシピベースの選択にも当てはまると思います。
- LCMを[適用および監視]に設定してから、必要な方法で変更を加えます。システムがまだ準拠しているかどうかをテストできますが、修正は試みられません。
次の選択肢には、変更を「レシピの一部」にして再作成できるという利点があります。
- 「追加」設定は最初は公開されていませんが、後で追加できる部分構成の明示的なセットアップを使用してシステムを展開します。これは、「一時的に」設定する予定の設定が、別の構成の設定と競合していないことを前提としています。これにより、構成を完全に再生成しなくても、「レシピの一部」として変更を加えることができます。
- 変更を組み込んだまったく新しい構成を公開し、構成を開始します。前のオプションと同様に、構成はidempotently適用されます（以前に設定されたものに影響を与えることなく、新しい変更のみが行われます。）
DSCプッシュモデルとプルモデルのどちらを使用するかに関係なく、これらの変更は単一のマシンまたは複数のマシンに対して行うことができます。
現時点では、CMシステムからシステムの構成を管理するという概念と、not同時にそれを行わないという概念の考えられる不一致を無視します。すでに述べています...
このユースケースでは、通常、現代のサーバーソフトウェアで慣例となっているものを利用することが可能であることに注意してください。.d構成ディレクトリにより、適切な場所に追加の構成スニペットを挿入できます。
そうすれば、CMに設定を管理させることができる場合があります。 /etc/logrotate.d/local-whateverと同時に、/etc/logrotate.d/local-aaa-whateverなどを追加することで特定のマシンをいじることができます。これにより、ソフトウェアがオーバーライドされた設定を処理します。
明らかに、CMに/etc/logrotate.d/全体を制御することを目的としたレシピがある場合でも、CM内で何かを行う以外に頼ることはできません。