用Cfengine自动化基础架构进行系统管理(1)

文章由LinuxBoy分享于2019-03-26 03:03:34热评（71）

用Cfengine自动化基础架构进行系统管理(1)

简介

如今，IT 数据中心必须跨多个操作系统版本提供和维护稳定性、安全性和可伸缩性服务，这类服务可在多种服务器硬件和操作系统上运行。效率很重要，管理员希望能够最小化这些服务的支持，让其成为全自动，就像自动熄灯一样。在这个两个部分系列文章 “用 Cfengine 自动化基础架构管理” 中，我们将探讨一种用于系统管理和 IT 管理的自动框架：Cfengine。

本系列第 1 部分将为您提供一个 Cfengine V3 Community Edition 概述，以及有关如何构建及配置 Cfengine 策略/发布服务器和客户机的信息。第 2 部分则会用示例说明如何使用 Cfengine 完成服务支持所涉及到的诸多日常任务。

本文假设您已经安装了基础的 UNIX® 或 Linux® 操作系统，并且非常熟悉 Cygwin 和 Linux 打包命令。

配置管理和 Cfengine

良好的配置管理可以建立和维护 IT 平台和产品及其环境的性能、功能以及物理属性的一致性。它还可用来决定适当的安全性特性并确保这些特性的正确应用。这是一项复杂的工作，有很多配置管理工具可用。

有些工具，比如 Arusha Project (ARK)，可与 Cfengine 结合使用。其他工具虽然使用的是类似的系统管理概念，但以不同的编程语言编写，比如 Puppet 是用 Ruby 编写、REST 调用的，又比如 Synctool 是用 Python 编写的，再比如 SmartFrog，是基于 Java™ 技术的。而类似 opsi (Open PC Server Integration) 这样的工具则只面向 Windows® 编写。IBM® Systems Director 以及最近收购的 IBM BigFix 也能提供配置管理。

Cfengine 是一种 GNU 开源配置管理框架，用于计算机系统自动化。此框架是轻量的，可针对几乎所有平台构建。它能运行在所有常见平台上，其中包括 AIX、Linux、UNIX、Apple 和 Windows。

IT Infrastructure Library 是在全球应用最为广泛的一种 IT 服务管理方式，它定义了知识管理作为交付服务的关键过程。知识管理确保一个人只要拥有这方面的知识就能够交付并支持业务所需的服务。前提是高效提供服务时，清晰地理解服务带来的价值，并提供所需的相关可用信息。Cfengine V3 关注管理生命周期每个阶段的知识管理。通过使用一个已定义配置，Cfengine 能够确保您拥有恰当的包、配置文件、文件权限，且进程运行在您的环境中。

Cfengine 有两个版本：一个是存在已久的社区版，另一个是商业的企业版。对于商业版，亦有几种形式：Nova、Constellation 和 Galaxy。

生命周期管理

Cfengine 遵循的是系统生命周期管理的 Build-Deploy-Manage-Audit (BDMA) 模式。BDMA 包含系统生命周期的四个阶段：构建、部署、管理和审计。在构建阶段，需要计划策略更改、规划想要的状态承诺(promise)以及构建所建议承诺的模板，这样如果所有机器均能做出并兑现这些承诺，系统便可无缝地运行。

在部署阶段，需要向所有自主客户端(autonomous clients)发布策略，并且每个客户机都要运行一个代理，无需协助即可实现并维护这些策略。

在管理阶段，这个自主代理负责管理该系统，您只需处理不能被自动处理的极少事件。

最后，在审计阶段，对更改进行本地审计和维护。决策结果由 Cfengine 内的设计确保且可自动维护。

Cfengine 不应被视作一种转出(rollout)系统，其中人们试图剔除绝对更改并在出现错误时反转 Cfengine，需发布策略修订序列，然后继续。这些状态更改由各个客户端本地管理且不断修护以便符合策略。

依赖项

Cfengine 需要 OpenSSL 和 BerkeleyDB V3.2 或更高版本。您还可选择为支持 Perl Compatible Regular Expression library (PCRE)、OpenLDAP 和 PostgreSQL 或 MySQL 而构建。有些数据库特性只在商业版本可用。在 Windows 上，Cfengine 需要 Cygwin 环境。而且，像 Subversion (SVN) 这样的版本控制软件可用来控制对配置文件的更改。

术语

承诺 — 定义的动作或规则，以便系统遵循。
包 — 承诺组。
策略 — 定义我们所能管理的实际知识包。
类 — 定义为 "on" 或 "off" 的属性/变量。
策略包含承诺包。
密钥 — 可以是公共或私有的，用来对可以访问服务器进行身份验证，在每个客户机上使用 cf-key 生成，然后再复制到服务器上的密钥仓库。在 IBM ，只使用服务器密钥就足以提供安全性。

准备开始

Cfengine 可运行于任何 UNIX 服务器上，若有 Cygwin 环境，也可运行在 Windows 上。在一个 UNIX 服务器上，先安装 OpenSSL、BerkeleyDB 以及上述讨论的所有附加包。Cfengine 通常从一个分布包(比如 rpm 或 deb)安装，或者，源代码也可下载和编译。

如果计划从源代码构建 Cfengine，还将需要在 UNIX/Linux 服务器上安装额外的工具，比如 gcc、flex 和 bison。在一个 Windows 服务器上，先安装 Cygwin，然后安装 gcc、flex 和 bison 工具来编译并安装代码。

这些基本 Cfengine 文件安装在 Cfengine 工作目录 /var/cfengine 的子目录内。这个工作目录为 Cfengine 自己所用，且在构建时定义。这个路径可视为是一个安全的本地文件系统。配置文件编码后，可将其放置于所有 Cfengine 服务器上的配置分布点内(比如 /var/cfmasterfiles)。这个路径通常置于版本控制目录下。

从源代码构建 Cfengine

从 Cfengine 存储库下载源代码。作为一个非 root 用户登录到此系统并运行如下命令。

tar –zxf cfengine-x.x.x.tar.gz
cd cfengine-x.x.x
./configure --prefix=/var/cfengine
--sbindir=/var/cfengine/bin --localstatedir=/var/cfengine
--with-workdir=/var/cfengine --with-openssl=/usr make

现在转到 root 用户并运行如下命令(二进制文件置于 /var/cfengine/bin 内)。

make install
make installcheck

在 Policy/Distribution Server 上安装 Cfengine

作为 root 用户登录到系统并执行如下命令：

mkdir –p /var/cfengine/masterfiles
cp cfengine-x.x.x/inputs/update.cf to /var/cfengine/masterfiles
cp cfengine-x.x.x/inputs/promises.cf to /var/cfengine/masterfiles

用适当的电子邮件地址更新文件 promises.cf 内的 "mailto" 选项。在 promise.cf 的 "body server control" 部分添加服务器应该接受其连接的网络：

allowconnects => { "192.", "10.", "127.0.0.1" , "::1" };
allowallconnects => { "192.", "10.", "127.0.0.1" , "::1" };
trustkeysfrom => { "192.", "10.", "127.0.0.1" , "::1" };

在所有配置文件内将策略服务器更新为这个新的服务器环境：

cp cfengine-x.x.x/inputs/failsafe.cf to /var/cfengine/masterfiles
cp cfengine-x.x.x/inputs/cfengine_stdlib.cf to /var/cfengine/masterfiles

Cfengine 组件

以下列出的是 Cfengine 安装中需要注意的组件。 (注意：如果您是从一个二进制包安装的 Cfengine，或是在编译安装过程中做过定制，那么这些基础目录有可能不同。)

/var/cfengine/bin — 具有 Cfengine 二进制文件的目录
/var/cfengine/inputs — 具有 Cfengine 配置文件的目录
/var/cfengine/outputs — 具有 Cfengine 运行报告的目录
/var/cfengine/ppkeys — 具有身份验证密钥的目录
/var/cfmasterfiles — 具有策略服务器上的主文件的目录
/var/cfengine/repository — 包含了重要 Cfengine 文件备份以备恢复(name/location 可配置)的目录

二进制文件

/var/cfengine/bin/cf-promises — 检查承诺语法的命令
/var/cfengine/bin/cf-agent — 维护共同做出的承诺及有关系统状态的代理包的命令
/var/cfengine/bin/cf-serverd — 用来将策略或数据文件发布到客户端并就来自 cf-runagent 的请求进行响应的服务器(守护进程)
/var/cfengine/bin/cf-execd — 负责运行 cf-agent 的调度守护进程
/var/cfengine/bin/cf-runagent — 在远端机器上运行 cf-agent 的命令
/var/cfengine/bin/cf-monitord — 负责收集有关系统状态信息的守护进程
/var/cfengine/bin/cf-report — 从 Cfengine 嵌入数据库生成摘要和其他报告的命令
/var/cfengine/bin/cf-know — 从大量承诺(知识建模代理)生成一个 ISO 标准的 Topic Map 的命令
/var/cfengine/bin/cf-key — 在每个主机上运行一次来创建用于安全通信的公共/私有密钥对的密钥生成工具

配置文件

/var/cfengine/inputs/promises.cf — cf-agent 所使用的主要配置文件
/var/cfengine/inputs/library.cf — 包含了可重用代码集的社区库;对于 V3.1.x 发布版，最好使用这个社区库

首次启动 Cfengine Policy Server

在该服务器上运行如下命令：

/var/cfengine/bin/cf-key
mkdir /var/cfmasterfiles/ppkeys
cp /var/cfengine/ppkey/localhost.pub /var/cfmasterfiles/ppkeys/root-.pub
cp /var/cfengine/ppkey/localhost.priv \
/var/cfmasterfiles/ppkeys/root-.priv
cp /var/cfmasterfiles/inputs/update.cf /var/cfengine/inputs/
cp /var/cfmasterfiles/inputs/failsafe.cf /var/cfengine/inputs/
/var/cfengine/bin/cf-agent –bootstrap

Cfengine Policy 服务器现已配置。为了准备 Cfengine 来充当远端客户机，执行如下命令： start cf-server。

在大多数环境内，可以通过配置运行 cf-serverd。其他时候，最好是为服务器配置准备一个独立的配置文件。如果进程意外终止，这可以提供一个位置供外部进程重新启动 cf-serverd。我们还可以用一个 watchdog 脚本来重新启用 cf-serverd。要从命令行运行它：

/var/cfengine/bin/cf-serverd
/var/Cfengine/bin/cf-serverd –f
/var/cfmasterfiles/prod/server/server.cf

客户端的初始设置

通过执行如下命令首次启动 Cfengine 客户端：

/var/cfengine/bin/cf-key
/var/cfengine/bin/cf-agent –K –bootstrap

为您的环境创建一个二进制包

此时，您可能会想要创建 APT 或 RPM 包用来配置您的客户端。其中的一个包包含 Cfengine 二进制文件，而另外一个包则包含了最低限度的 Cfengine 配置文件及服务器公钥来引导 Cfengine，此外，还有 cf-key 以及如上所列的 cf-agent 命令。构建了这两个包后，通过安装这些包来配置 Cfengine 的客户机就显得十分简单了。

我们接下来将会展示如何针对 Red Hat 环境创建二进制包。(要创建一个 Debian 包，请参考 UbuntuForums.org。)不同发布版对创建二进制包有不同的要求。查阅您环境的参考文档，了解如何适当准备此信息。

推荐文章：

用Cfengine自动化基础架构进行系统管理(1)