update.conf
内部の構文エラーを元に戻すことができるように、cfagent.conf
ファイルを更新するために使用されます。cfagent.conf
多くのドキュメントでは、ファイルを更新することは推奨されていませんupdate.conf
。しかし、update.conf
定期的な更新が必要な場合、それを行うためのベストプラクティスは何ですか?
提案をありがとう:-)
update.conf
内部の構文エラーを元に戻すことができるように、cfagent.conf
ファイルを更新するために使用されます。cfagent.conf
多くのドキュメントでは、ファイルを更新することは推奨されていませんupdate.conf
。しかし、update.conf
定期的な更新が必要な場合、それを行うためのベストプラクティスは何ですか?
提案をありがとう:-)
ソフトウェア開発ごとに順次設計プロセスを実行することをお勧めします。update.confの変更もこのグループに含まれます。DEVで変更を加えてから、実際にテストしてからUATを要求し、最後にPRODに移行する必要があります。
多くの人がバージョン管理をポリシーに統合しています。すべてのホストがポリシーを直接チェックアウトします。必要に応じて、それも検討することをお勧めします。
私の場合、update.confの内容はあまり変更していません(年に1回だと思います)。ポリシーのアップグレードのためだけにコードをフリーズします。変更する必要がある場合は、DEVで変更し、問題がまったくないことを確認します。ご覧のとおり、タイプミスや人為的エラーが発生した場合、すべてのホストが完全に停止し、ポリシーを自動的に更新できない可能性があります。
私は今、ダブルフェイルセーフを実装することを考えています。1つのフェイルセーフは、cf-execdによって定期的に実行されるポリシーを更新することであり、もう1つは、フェイルセーフが失敗した場合にのみフェイルセーフをレスキューするためのものです。
yegle が直面しているのと同じ種類の問題かどうかはわかりませんが、CFEngine でデーモンを実行/管理していて、デーモンが必要とするパラメーターを変更する必要がある場合には、update.conf を変更する必要もありました。次回のアップデートで再開予定。
ただし、update.cf は (理論的には) 「決して」変更されるべきではないことに同意します。変更が発生している場合は、それらを分離する必要があります。CFEngine 3 では、 cf_promises_validated 最適化を使用できます。
私の最初の質問は、なぜ update.conf を頻繁に変更する必要があるのですか? 更新に関する潜在的な問題を回避できるように、大部分が不変であることを正確に意図しています。頻繁に更新する必要がある部分がある場合、その部分を別のファイルに分割する必要がありますか?