web-dev-qa-db-ja.com

cfengine3出力ディレクトリ

Cf-execdを使用してcfengine3の実行を開始し、デフォルトの間隔である5分ごとにcf-agentの実行をスケジュールしました。

cf-execdは、cf-agent（-informオプションを指定して実行）の出力をキャプチャし、出力を$ WORKDIR/outputsディレクトリに保存し、結果を電子メールで送信します（ただし、前回の実行と異なる場合のみ）。ご想像のとおり、5分ごとの出力ファイルでは、このディレクトリはすぐに多数のファイルでいっぱいになり、ユーザーがこのディレクトリをクリーンアップすることが期待されます。

3日以上経過したこれらの出力ファイルを削除するルールを作成しましたが、これによって発生する問題は、すべての出力が前の出力とは異なるため（新しいファイルは毎回削除されるため）、電子メールは次のようになります。送信されました。そのため、出力ディレクトリの多くのファイルから、受信トレイの多くの電子メールに移動します。

私が本当に望んでいるのは、特定のプロミス、特に出力ディレクトリ内のファイルを削除するプロミスが修復されたときにメッセージを抑制することです。それは本質的にその約束のためだけに-Iオプションを否定するでしょう。あるいは、時間境界を「今」から定点（たとえば毎週水曜日）に変更できれば、少なくとも電子メールの数を1週間に制限することができます。

configuration-managementcfengine
2
aaa90210

質問に対する回答が得られなかったようですので、「今までにないよりも遅くなる」という精神で投稿します。

あなたは尋ねました：

私が本当に望んでいるのは、特定のプロミス、特に出力ディレクトリ内のファイルを削除するプロミスが修復されたときにメッセージを抑制することです。それは本質的にその約束のためだけに-Iオプションを否定するでしょう。

私の知る限り、単一のpromiseの--informスイッチを無効にすることはできません。

あるいは、時間境界を「今」から定点（たとえば毎週水曜日）に変更できれば、少なくとも電子メールの数を1週間に制限することができます。

これは、「ifelapsed」パラメーターを使用して実現できます。これにより、promiseを実行するための最小頻度が得られます。この例を考えてみましょう。

bundle agent garbage_collection {     
    files:
        "$(sys.workdir)/outputs" 
            delete => tidy,
            file_select => days_old("3"),
            depth_search => recurse("inf"),
            action => weekly;
}

body action weekly {
    ifelapsed => 10080; # one week, ie (60*24*7) minutes
}

または、特別なクラスを使用して、水曜日にこの約束を実行することもできます。私はifelapsedアプローチを好みます。これは、平日に依存しません（そのホストが、ある水曜日に実行されていない可能性があるかどうかはわかりません...）。

bundle agent garbage_collection {     
    files:
        Wednesday::
            "$(sys.workdir)/outputs" 
                delete => tidy,
                file_select => days_old("3"),
                depth_search => recurse("inf");
}
3
Jonathan Clarke

「継承された」デプロイメントでは、garbage_collectionバンドルがすでにsite.cfにあることがわかりましたが、どこからも呼び出されませんでした。 promises.cfにバンドルシーケンスを追加する必要があります

これが新しい展開に当てはまるかどうかはわかりません。もしそうなら、あなたはおそらくあなたの約束を更新する必要があります（私は私がする必要があることを知っています）

キャメロン、お役に立てば幸いです

0
Cameron Kerr

実際、私はさらに簡単な答えに到達しました-cf-agentを--informと一緒に実行しないでください。

Cf-engineにそれを行わせ、どのような修復が行われているかを追跡しようとしないでください。主な懸念事項は、システムがどのように到達したかではなく、目的の状態に到達したことです。

これは、システムへのすべての変更を非常に詳細に追跡したい変更管理体制にとっては嫌悪感のように思われるかもしれませんが、正気を保ちながらcf-engineを使用できる唯一の考え方であることがわかりました。

もちろん、あなたの答えは私が提起した質問に対して厳密に正しいものでした。それが私がそれをチェックした理由です。

0
aaa90210