CFEngine

この文書はCFEngine Core 3.9.1に基づく
Cfengineは最も歴史のある構成管理ソフトウェアである.多くの後発ショー(puppet,saltstack,Chef...)を受けたがしかし、CFEは生き残ることに成功した.他の構成管理ソフトウェアに比べて、CFEの最も明らかなメリットは次のとおりです.

依存が少なく、配置が便利である.現在のバージョンでは、パッケージを1つインストールするだけで、コマンドを1つ実行することで導入を完了できます.

の運行オーバーヘッドが小さく、効率が高いCFEはc/c++で作成し、運行効率は疑いの余地がない.

アーキテクチャの簡単な最も核心的なコンポーネントはcf-agentの1つだけで、その他のコンポーネントは実はすべてオプションです.cf-serverdは、通常、ポリシーファイルのダウンロードを提供するファイルサーバにすぎない.ポリシーファイルの解析はagent側で行う.したがって、CFEのサーバ側は、他の構成管理ソフトウェアに比べて、より多くのagent側を管理することができる.cf-execdもタイマーにすぎない.したがって、rsyncでポリシーファイルを同期し、crondでcf-agentを定期的に実行すると、cf-agentとcf-serverdを完全に起動することはできません.

DSLは特定のプログラミング言語に依存する.

安全外部はcf-agentの実行、およびクラスの定義のみをトリガすることができる.cf-agentでポリシーファイル以外のコマンドを実行できません.

Install
公式文書を参照
ソフトウェアのインストールが完了すると、/var/cfengine/bin/cf-agent --bootstrap を実行して初期化する必要がある.
COMPONENT
cf-execd
周期的にcf-agent実行をトリガする.デフォルト間隔は5分です.
cf-runagent
cf-runagentは、cf-agentの実行(cf-serverdを介して)をリモートで一括トリガすることができる.このプロセスでは、cf-agent実行時のclassを--define-class, -D valueオプションで定義することができる.トリガを必要とするcf-agentは、--select-class, -s valueによりスクリーニングすることができる.実際に使用する場合、これらのメカニズムには2つの側面があります.

テストclassを指定することで、ターゲットマシンに任意のポリシーを適用することができる.

は、バッチ実行ツール、例えばansibleの一部を代替するように、コマンド実行をリモートで一括トリガすることができる.しかし、このようにトリガコマンドは、ポリシーファイルにおいて予め定義されている必要があり、パラメータを伝達することができないため、柔軟性にやや欠けている.

Modules
使い方は二つあります

Set variables and classes based on command output

lines which begin with a ^ are protocol extensions

^context=xyz sets the module context to xyz instead of the default

^meta=a,b,c sets the class and variable tags for any following definitions to a, b, and c

lines which begin with a + are treated as classes to be defined (like -D)

lines which begin with a - are treated as classes to be undefined (like -N)

lines which begin with = are scalar variables to be defined

lines which begin with = and include [] are array variables to be defined

lines which begin with @ are lists.

lines which begin with % are data containers. The value needs to be valid JSON and will be decoded.

usemodule()

Promis
Command
Files
edit_line
edit_lineは、ファイルの内容、特に「行」単位の/簡単なプロファイルを柔軟に制御することができる.しかし、複雑な場合、構造化されたプロファイルは力不足に見える.
もう一つの問題はedit_に基づいてlineはファイルの内容を制御するが、プロファイルの完全な内容を制御することは困難であり、配置が収束しにくい.だからeditは強くお勧めしませんline.
edit template

template_method => "cfengine", native-CFEngine template format, default. v3.3.0

template_method => "mustache". v3.6.0

edit_templateは長年にわたって追加したい機能です.しかし、テンプレートをサポートしていないcfengine 2時代でも実現できないわけではなく、少し面倒なだけです.
edit_xml
テンプレートがあればこれは必要ありませんedit_lineの問題と同様に、配置の完全な内容を制御ことができず、配置が収束しにくい.
Q&A
policy_の決定方法server.
/var/cfengine/policy_server.datにはpolicy_が保存されていますserverのアドレス

default:cfe_autorun_inventory_cmdb.sys#policy_hub 192.168.80.136           source=agent
default:def.policy_servers                {"192.168.80.136"}               source=promise
default:def.sys#policy_hub               192.168.80.136                    source=agent
default:sys.policy_hub                   192.168.80.136                    source=bootstrap

これらの変数の値はpolicy_server.datの内容が決まる.
デフォルトではpolicy fileはどのように更新されますか?
controls/cf_serverd.cf

!windows::
  # last single quote in cfruncommand is left open, so that
  # arguments (like -K and --remote-bundles) are properly appended.
  cfruncommand => "$(def.cf_runagent_shell) -c \'
                       $(sys.cf_agent) -I -D cfruncommand -f $(sys.update_policy_path)  ;
                       $(sys.cf_agent) -I -D cfruncommand";

controls/cf_execd.cf

!windows::
  exec_command => "$(sys.cf_agent) -Dfrom_cfexecd,cf_execd_initiated -f \"$(sys.update_policy_path)\" ; $(sys.cf_agent) -Dfrom_cfexecd,cf_execd_initiated";

cf_からserverd.cfとcf_execd.cfではcfを通過してもserverdかcf_かexecd実行cf_Agentはまずsysを実行する.update_policy_pathのポリシーは、ポリシーファイルを更新する.じゃあupdate_policy_パスは誰ですか?次のコマンドで確認できます.

$ cf-promises --show-vars |grep update.cf

default:sys.update_policy_path           /var/cfengine/inputs/update.cf              source=agent

/var/cfengine/inputs/update.cfは関連ポリシーファイルの大量更新を導入した

body common control
{
      bundlesequence => {
                          "update_def",
                          "u_cfengine_enterprise",
                          @(u_cfengine_enterprise.def),
                          "cfe_internal_dc_workflow",
                          "cfe_internal_bins",
                          "cfe_internal_update_policy",
                          "cfe_internal_update_bins",
                          "cfe_internal_update_processes",
      };

      version => "update.cf $(update_def.current_version)";

      inputs => {
                  @(cfengine_update_controls.update_def_inputs),
                  "cfe_internal/update/update_bins.cf",
                  "cfe_internal/update/cfe_internal_dc_workflow.cf",
                  "cfe_internal/update/cfe_internal_local_git_remote.cf",
                  "cfe_internal/update/cfe_internal_update_from_repository.cf",
                  "cfe_internal/update/update_policy.cf",
                  "cfe_internal/update/update_processes.cf"
      };
}

主な更新ロジックはcfe_に含まれます.internal/update/update_policy.cf中

!am_policy_hub::  # policy hub should not alter inputs/ uneccessary

  "$(inputs_dir)/cf_promises_validated"
  comment => "Check whether a validation stamp is available for a new policy update to reduce the distributed load",
  handle => "cfe_internal_update_policy_check_valid_update",
  copy_from => u_rcp("$(master_location)/cf_promises_validated", @(update_def.policy_servers)),
  action => u_immediate,
  classes => u_if_repaired("validated_updates_ready");

この段落はpolicyをチェックします.servers上のcf_promises_validatedが更新されたかどうか、policy_を決定します.servers上のポリシーファイルに変化があるかどうか.

am_policy_hub|validated_updates_ready::  # policy hub should always put masterfiles in inputs in order to check new policy

  "$(inputs_dir)"
  comment => "Copy policy updates from master source on policy server if a new validation was acquired",
  handle => "cfe_internal_update_policy_files_inputs_dir",
  copy_from => u_rcp("$(master_location)", @(update_def.policy_servers)),
  depth_search => u_recurse("inf"),
  file_select  => u_input_files,
  action => u_immediate;

policy_サーバ上のポリシーファイルが変化すると、ローカルのポリシーファイルが更新される.クライアントとpolicyを見てみましょうサーバ自体の更新ロジックは同じである.

  "validated_updates_ready"
    expression => "cfengine_internal_disable_cf_promises_validated",
    comment => "If cf_promises_validated is disabled, then updates are
                always considered validated.";

cfengine_internal_disable_cf_promises_validatedが設定されている場合、サーバ側のcf_にかかわらずpromises_validatedファイルに変化があるかどうか、validated_updates_readyというクラスはいずれも設定、すなわちクライアントに更新をトリガーする.

  "cfengine_internal_disable_cf_promises_validated"
    expression => "!any",
    comment => "When cf_promises_validated is disabled remote agents will
               always scan all of masterfiles for changes. Disabling this
               is not recomended as it will increase the load on the policy
               server and increases the possibility for remote agents to
               recieve broken policy.";

しかしcontrols/update_def.cfではcfengineが見えますinternal_disable_cf_promises_validatedのデフォルトは設定されていません.つまりデフォルトではcf_を通過する必要があります.promises_validatedファイルの状態で更新か否かを判断する.

body copy_from u_rcp(from,server)
{
      source      => "$(from)";
      compare     => "digest";
      trustkey    => "false";

    !am_policy_hub::

      servers => { "$(server)" };

    cfengine_internal_encrypt_transfers::
      encrypt => "true";

    cfengine_internal_purge_policies::
      purge => "true";

    cfengine_internal_preserve_permissions::
      preserve => "true";
}

copy_from u_rcpの定義では、クライアント更新時にserversプロパティ(policy_server)が入力パラメータに設定されているが、policy_が指定されていないことがわかる.server更新時のservers.実際、copy_fromのデフォルトserversはlocalhost,policy_サーバ更新時はネイティブからファイルを同期するので指定する必要はありません.
Link

Hard and Soft Classes

common attributes