当我们从Ansible的试用转向生产时，我对更多关于最佳实践的问题有了更多的疑问。我们使用Ansible来安装yum或其他repo中没有的产品和补丁。它们以高达600MB的zip文件形式到达，我们将它们作为zip文件推送到服务器并在那里解压缩。一切正常。我们历史上将这些拉链存储在项目的文件/产品和文件/补丁目录中。
我们现在将项目迁移到Git（Bitbucket）。很多人会说你不应该把二进制文件存储在Git中。在尝试时，我们提交和推送较大文件的成功有限（我们得到超时）。如果我们只是将它们存储在项目目录中的服务器上，则必须非常小心，不要在项目中启用“更新时删除”设置，因为它会在项目更新时吹掉大量的产品和补丁库。感觉有点不稳定。
有了这样的理解，其他人如何使用Ansible存储大文件并分发它们？它们是存储在项目外部还是使用完全限定的路径引用？你有没有为Ansible可以从中获取这些大文件的其他形式的repo？任何指导都将不胜感激。
答案 0 :(得分：1)
首先，你真的，真的不想在Git中存储二进制文件。它会让您轻松克隆回购（包括开发和部署）并导航项目，这绝对是一场噩梦。
如果您有一些必须使用Ansible部署的大型二进制文件，那么该二进制文件属于某种形式的二进制文件或工件库。在我们的例子中，我们使用Aptly来存储apt repos的快照，并使用Artifactory存储一般二进制文件（通常是zip文件，但偶尔也会使用WAR文件和许多其他东西）。
在Aptly的情况下，我们只是简单地指出它好像是一个正常的apt repo，在Artifactory的情况下，我们使用Ansible的get_url模块从中央Artifactory服务器下载二进制文件。
答案 1 :(得分：1)
是的，有一些原因建议不要在Git中存储大文件，包括每个开发人员必须将这些文件的每个副本一直保留在结帐中。您可以找到各种方法来缓解此问题with a simple web search。
就Ansible而言，这不应该有太大变化。如果您使用的解决方案在您运行Ansible的计算机上保留源文件，则可以像以前一样继续复制它们。
或者，许多人将这些文件存储在单独的文件存储中（例如，S3或本地文件服务器），并使Ansible规则引用远程URL以从服务器下载这些文件。这样您就不必在本地计算机上下载它们，主要的带宽使用是在服务器和文件服务器之间，而不是服务器和本地计算机（可能没有调整到这一点）。 HTTP（S）传输文件的效率也比SSH高得多。
对于任何这些外部系统，当您签出期望旧版本的Ansible代码版本时，您将需要确保旧版本的软件包仍然可用。一些git解决方案会自动处理，但您也可以通过在文件路径中包含版本号或校验和来自行完成。