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