バージョン管理パッケージによる構成管理

私たちが管理しているホストの場合、上司はバージョン管理パッケージ（特別な場合はfpmベースのDebianパッケージ）を介した構成管理のビジョンを持っています。これは以下のためのものです：

• ホストの展開が簡単になりました。
• ローカルの変更を簡単に追跡できます。
• ほとんどの場合、機能のバグや設定バグであれば、ソフトウェアのバージョンをバグとして表示できるため、バグの追跡が簡単になります。

別のオプションは、現在使用中のマニュアルに示されている推奨レイアウトを使用したAnsibleによる設定管理です。バージョン指定されたパッケージ（ほぼすべてのWebサービス）をインストールします。このパッケージは独自のパッケージ固有の構成を処理し、Ansibleをシステム全体の構成に委ねます。ホストソフトウェアを更新すると、バージョン番号が増え、スクリプトが再実行されます。私たちは、重要な情報を設定から分離するために、Ansibleの「var_prompts」機能に大きく依存しています。

「バージョンが指定されたパッケージによる構成管理」の場合：

展開用に最小限のサーバー（エージェントなど）を起動し、パッケージマネージャ（私たちの場合はapt）を使用してすべての依存パッケージをインストールする単一の傘パッケージをインストールします。依存パッケージを変更すると、最上位パッケージのバージョンのみが適用されるため、既存の展開をより簡単に更新できます。

構成の場合、すべてのパッケージには構成変更のみを許可する「config」パッケージが付属しています。各パッケージには、ホストのローカル変更を確認するときにパッケージ間の競合を防ぐための独立した構成ファイルがあります。構成を生成するコマンドを実行する代わりに、生成されたファイルがパッケージの一部として含まれていることを確認しますが、プレインストール/インストール後にスクリプトを介してコマンドを実行することもできます。 AFAIK、ほとんどの場合、パッケージはすべて同じ構成ファイルに依存しますが、この場合（システム構成の場合）、ペアの依存関係を持つ別のパッケージがあります。この特定の状況が制御不能に陥るのがわかりますが、常に独立した構成ファイルを保証することで制御できます。最後に、各ホストには独自の構成パッケージがあります。明らかに、これらのファイルはすべてソース管理下にあり、独自のシンプルなテンプレートシステムを起動して、Ansibleロールの柔軟性を確保できます。

このようなホストを構成してデプロイするワークフローに関する情報/分析が見つからないのはなぜですか？既存の構成管理ツールと比較して、このアプローチには根本的な欠陥はありませんか？