使用Ansible从私有Github仓库下载单个文件到远程主机

Question

示例场景：某个服务的配置文件保存在私有Github仓库中的版本控制下。我想编写一个playbook，在远程节点上获取其中一个文件并将其放置到所需的位置。

我可以想到几种解决方案:

1. 在运行ansible的机器上执行checkout（使用local_action），然后使用copy模块。
2. 在远程节点上进行checkout（使用git模块），使用“command: cp src dest creates=dest”将文件复制到所需的位置（也许可以通过处理程序来实现，只有在需要拉取更改时才操作）
3. 在playbook中使用URL模块或“command: wget https://raw.github.com/repo/.../file creates=file”只下载感兴趣的文件。但是，命令模块是否会检查要创建的文件与可能已经存在的文件是否不同，还是仅检查文件是否存在？
4. 在运行ansible的机器上使用wget（使用local_action），然后使用copy模块将其推送到远程节点。

这些方法各有利弊。哪种方案（如果有）可以被认为是良好的实践？什么是最佳通用解决方案？

- pldimitrov

---

解决方案3：一定要确保文件存在。只有在创建时添加create参数到命令中。 - mmv-ru

Answer 1

首先我要说的是，我们选择了第二种方案用于我们的生产环境，我可以保证一件事情 - 它非常有效。现在详细说说：

方案1：

• 简单且稳健- 将会很有效
• 不会将其他配置文件（无关文件）“污染”生产服务器
• 不会导致生产服务器对 GitHub 进行过多的 I/O（可能可以忽略）

方案2：

• 简单且稳健- 将会很有效
• 为了减少污染，我们将配置 repo 克隆到 /tmp 目录，并在剧本结束时删除它

方案3/4：

我猜这些方案将会起作用，但感觉有点奇怪，因为你把你的配置放在源代码控制中，却没有真正使用源代码控制功能。这些方案的优势在于你可以“挑选”想要下载哪些配置文件，而不是克隆整个仓库。这也减少了针对 GitHub 的 I/O，因为随着时间推移，克隆变得越来越沉重。

- Shahar

---

我决定尝试第一种解决方案，我认为它正是我想要的。我认为它的可扩展性更好（至少对于我的用例），因为你只需要在ansible服务器上与github通信一次，而不是每个远程节点每个任务调用都需要通信一次。 - pldimitrov

就可扩展性而言，我认为它取决于您的用例。您更愿意限制 Github 调用还是文件复制？ 采用第一种解决方案，您只需要调用一次 Github，但然后您需要 X 次复制，每个节点需要一次。根据您的连接情况（例如，在 20 个主机上复制 50Mo = 1Go 的数据仅用于控制机器），您的 Ansible Playbook 可能会稍微花费一些时间来处理许多远程节点，而让每个节点联系 Github 将在每个节点上仅使用 50Mo，并且 Github 肯定可以缩放... - Pom12