cfgtool配置管理
cfgtool的Python项目详细描述
一种配置管理工具，它提供了自记录主机 以及一致版本化的配置。
cfgtool做什么？
cfgtool允许应用程序分离其配置文件 从进入这些文件的主机特定值。这些价值观， 称为信念，可以手动部署，也可以公共部署 基础设施或组织工具SaltStack 或者Ansible。
免责声明
而cfgtool在大多数Linux上运行应该没有任何问题 它只在基于debian的linux系统上测试过。
我怎么得到它？
cfgtool可以通过pip安装。它应该作为 安装的每个应用程序的依赖项 由它管理的配置。
pip install cfgtool
它是如何工作的？
安装时（假定具有根权限），cfgtool将创建 以下配置文件和目录。
/etc/cfgtool/cfgtool.conf /etc/cfgtool/module.d/ /etc/cfgtool/belief.d/
module.d为每个已安装的应用程序包含一个文件，使用 cfgtool。此文件包含我们期望的配置文件列表 cfgtool为该应用程序生成。每一个 配置文件应具有相应的.templ文件 与要安装的目录相同。
示例：
/etc/my_application/application.conf /etc/my_application/application.conf.templ
.templ文件是它将使用的模板配置文件 生成实际配置文件的信念。
belief.d包含json文件，其中包含在 正在生成应用程序配置。
我们可以更改module.d和^{tt12}的位置$ 如果愿意的话，cfgtool.conf文件中的目录。
belief_dir = "/my/new/belief/dir/..." module_dir = "/my/new/module/dir/..."
示例
假设我们有一个名为reporter的python应用程序。reporter 是一个程序，它每小时生成一份关于 在其上运行并将其发送到报表服务器的计算机。记者 有两个配置文件：
/etc/reporter/reporter.conf定义我们想要的 包括机器。
temperature=<boolean> system_load=<boolean> disk_space=<boolean> ...
/etc/reporter/report_send_init.sh定义我们想要报告的位置 外带。
exportREPORTER_USER=<string> exportREPORTER_PASS=<string> exportFTP_SERVER=<string> exportREPORT_PREFIX=<string>
这在运行的/etc/cron.hourly/reportercron脚本中使用 每小时生成一个报告并将其上载到ftp服务器。
#! /bin/bash . /etc/reporter/report_send_init.sh filename="${REPORT_PREFIX}_$(date +%Y-%m-%d-%H-%M)" reporter -c /etc/reporter/reporter.conf > /tmp/${filename}.txt ftp -n <<EOF open ${FTP_SERVER} user ${REPORTER_USER} ${REPORTER_PASS} put /tmp/${filename}.txt EOF rm -f /tmp/${filename}.txt
现在假设我们有以下场景；我们必须部署 reportertool在一家创造性地命名为 公司。
公司概况
经过仔细分析，company已经确定 需要仔细监视集群中的每台机器。 他们还有一个名为numbers的集群，它具有最先进的技术 冷却系统有自己的报告，但有频繁的磁盘空间和 需要监视的系统负载问题。
每个集群的计算机定期将其报告发送给 主人。
我们将如何配置所有这些机器？
幸运的是，company非常努力地实现了一些 Orchistration软件上月将配置文件部署到 他们的机器。他们的业务主管希望 尽可能在所有已安装的 应用。让我们尽量减少托管的数量 使用cfgtool的配置！
修改reporter
的配置由于reporter是一个内部工具，我们可以修改它以使用 cfgtool作为依赖项。
业务主管已经同意开始使用cfgtool来简化 所有服务器上的配置。独特的“环境”信念文件 将为每个集群中的每个计算机创建和部署 在/etc/cfgtool/belief.d/env.json下。这将包含以下信念 对于许多使用cfgtool的应用程序可能很有用。
在我们的图中，服务器A的文件是这样的：
{"master":{"domain":"letters.company.com","username":"machine_a","password":"very_secret_password"},"host":{"name":"letters-a","address":"lettersa.company.com"}}
我们的业务主管还部署了reporter特定的 在文件名下的每台计算机上的每个群集的配置 /etc/reporter/belief.d/reporter.json。这就是它的样子 类似于numbers.company.com集群中的计算机。
{"reporter":{"temperature":false,"system_load":true,"disk":true}}
让我们为每个配置文件创建templ文件。在 我们的每个templ文件，都可以在 belief.d/使用${...}语法。cfgtool合并所有 信念文件一起（按字母顺序遍历）成一个大的 字典。
Warning: If a belief is specified twice, the later one (the one in a file whose name is alphabetically greater) will be what ^{tt1}$ uses.
让我们将配置文件更改为templ文件。
/etc/reporter/reporter.conf.templ
temperature=${reporter.temperature}system_load=${reporter.system_load}disk_space=${reporter.disk} ...
/etc/reporter/report_send_init.sh.templ
exportREPORTER_USER=${master.username}exportREPORTER_PASS=${master.password}exportFTP_SERVER=${master.domain}exportREPORT_PREFIX=${host.name}
现在假设reporter的目录结构如下 这个：
├── LICENSE ├── README.md ├── setup.py ├── requirements.txt ├── reporter │ ├── __init__.py │ ├── reporter.py │ ├── ... ├── config │ ├── reporter │ ├── reporter.conf.templ │ ├── report_send_init.sh.templ │ ├── reporter.sh ├── install.sh
我们的新install.sh脚本将如下所示：
#! /bin/sh install -D -g root -o root -m 0644 -p config/reporter /etc/cfgtool/module.d/reporter install -D -g root -o root -m 0644 -p config/reporter.conf.templ /etc/reporter/reporter.conf.templ install -D -g root -o root -m 0644 -p config/report_send_init.sh.templ /etc/reporter/report_send_init.sh.templ install -D -g root -o root -m 0644 -p config/reporter.sh /etc/cron.hourly/reporter
reporter文件包含 reporter应该生成：
/etc/reporter/reporter.conf /etc/reporter/report_send_init.sh
创建real配置文件
此时，我们已经将cfgtool完全集成到reporter， 部署了我们的信念并安装了我们的软件，但是还没有。 可以使用，因为我们的配置文件还不存在。我们还得说 cfgtool生成我们的配置。
要生成配置，我们在终端中运行以下命令：
$ cfgtool write <module> [--force]
我们将<module>替换为要创建的应用程序 的配置文件。--force意味着我们将实际地 写（保持它与非破坏性命令的区别）。
让我们为reporter创建配置文件。这个命令 需要在安装了reporter的每台计算机上运行，并且应该 成为部署过程的一部分。
$ cfgtool write reporter --force
Module: reporter
Generate...
File: /etc/reporter/reporter.conf
File: /reporter/report_send_init.sh
让我们看看机器A上生产的产品：
/etc/reporter/reporter.conf
temperature=truesystem_load=falsedisk_space=false ...
/etc/reporter/report_send_init.sh
exportREPORTER_USER="machine_a"exportREPORTER_PASS="very_secret_password"exportFTP_SERVER="letters.company.com"exportREPORT_PREFIX="letters-a"
哇，每台机器都配置好了，可以像这样报告了！
如果我们的配置改变了呢？
现在可以肯定的是，我们的设置不一定会保留 永远不变。假设在开始使用cfgtool两年后， 新的冷却系统被引入我们的字母群等 增加了机器。我们不再有温度问题了我们需要 监视器，但是系统负载现在是我们需要注意的 原因。
新的reporter信念文件已部署到此群集上。
/etc/reporter/belief.d/reporter.json
{"reporter":{"temperature":false,"system_load":true,"disk":false}}
为了更新配置，我们只需运行cfgtool write 命令，就像我们在初始安装时所做的那样。
$ cfgtool write reporter --force
再一次，我们的配置是最新的！
等等，如果我犯了个错误，想让我的旧配置恢复正常怎么办？
cfgtool要小心，因为它总是留下 不管它在后面覆盖了什么。这是我们在A机上的目录 看起来像再次运行cfgtool write之后。
├── etc │ ├── reporter │ │ ├── reporter.conf.templ │ │ ├── report_send_init.sh.templ │ │ ├── reporter.conf │ │ ├── reporter.conf-backup.2016-01-20_0019.23 │ │ ├── report_send_init.sh │ │ ├── report_send_init.sh-backup.2016-01-20_0019.23 │ │ ├── ...
最终，这可能真的开始堆积后，许多连续的 重新部署：
reporter.conf reporter.conf-backup.2016-01-10_0019.23 reporter.conf-backup.2016-01-11_0112.01 reporter.conf-backup.2016-01-12_1202.26 reporter.conf-backup.2016-01-13_0311.04 reporter.conf-backup.2016-01-14_1049.45 reporter.conf-backup.2016-01-15_0059.15 reporter.conf-backup.2016-01-16_5001.02 reporter.conf-backup.2016-01-17_0019.21 ...
我们可以让cfgtool使用^{tt61}丢弃所有备份$ 命令。
$ cfgtool clean reporter
现在所有的备份都没有了。
reporter.conf ...
嗯，我想不起来我是否已经（重新）生成了配置
我们可以检查我们现有的配置文件是否符合我们的信念（或 即使是运行，也可以通过运行。
$ cfgtool check reporter
Module: reporter
Generate...
File: /etc/reporter/reporter.conf-check
File: /reporter/report_send_init.sh-check
Check...
File: /etc/reporter/reporter.conf-check
File: /reporter/report_send_init.sh-check
如果有任何不一致的地方，检查就不会通过。去掉 检查all已安装应用程序的模块名。
如果我想生成配置以查看它们的外观，但是不立即使用它们呢？
使用sample命令运行cfgtool以生成配置文件 扩展名为.sample。
$ cfgtool sample reporter
Module: reporter
Generate...
File: /etc/reporter/reporter.conf.sample
File: /reporter/report_send_init.sh.sample
如果一切看起来都很好，只要用write运行cfgtool。
等一下，回到这个关于所有信仰被梳理的问题上由cfgtool定义，这不暴露秘密吗？
现在假设我们安装了另一个名为^{tt69}的应用程序$ 它接受我们庞大的客户群上传的文件并将它们放入 亚马逊S3。其中一个信念是aws密钥：
/etc/cfgtool/belief.d/uploader.json
{"uploader":{"aws_secret_key":"..."}}
我们不希望像reporter这样的工具访问这些信息 只要把${uploader.aws_secret_key}放在 配置templ文件。我们该怎么办？
幸运的是，cfgtool足够聪明，能够意识到谁应该知道 什么。只要有一个叫做uploader的顶级信念， cfgtool会意识到它应该只被^{tt69}看到$ 应用程序并隐藏它。
我们可以通过检查暴露在 reporter使用^{tt80}安装uploader后$ cfgtool命令在机器A中。
$ cfgtool belief db_reports Module: db_reports {"master": {"domain": "letters.company.com", "username": "machine_a", "password": "very_secret_password"}, "host": {"name": "letters-a", "address": "lettersa.company.com"}, "reporter": {"temperature": false, "system_load": true, "disk": true}}
uploader的信念尚未公开。你可以放心 你的cfgtool应用程序只知道它们应该做什么 知道了！
接下来是什么？
本页总结了cfgtool的主要功能。学习 有关cfgtool的其他功能的详细信息，请通过查看帮助部分 你的终端。
$ cfgtool -help
欢迎加入QQ群-->： 979659372
