一种选择是使用托管的CI工具（例如Travis-CI或Gitlab）运行它们CI，但是，从安全角度来看，这是错误的，因为获得了我的Travis / GitLab帐户访问权限的人将可以访问我的所有服务器。需求？我的GitLab CI建议是否存在严重的安全问题，或者它是公认的解决方案？
#1 楼
解决方案是自动设置控制机器，即VM。您可以使用，例如，Vagrant，Terraform或类似工具（在本示例中，我将坚持使用Vagrant，这与原理有关）。通过这种方法，VM完全由文本文件（“ Vagrantfile”）定义，并且可以轻松，可重复地创建和重新创建。 Vagrantfile生成一个基础映像，例如某些特定的Linux发行版；网络等；只需提供所有必需的shell命令即可设置VM（即安装Ansible）。在此特定示例中，这可能就足够了。如果您需要更复杂的VM，则可以进行某种递归操作，并使用Ansible（或其替代方案之一）配置VM本身。和其他配置一样即，将其提交到SCM并保持最新状态。您还可以将Ansible安装在Docker映像中，或者将您选择的云提供商作为容器化提供的内容安装在其中。
#2 楼
如果您打算采用“基础架构即代码”的方式，则需要将该代码存储在存储库中。将基础架构定义存储在VCS（GitLab）中与在GitLab中存储代码几乎具有相同的安全隐患。只需确保您不以纯文本形式存储敏感数据或凭据，或者如果可以帮助则完全不存储。在Ansible的情况下，通常意味着使用Ansible Vault加密敏感文件。但这绝不是唯一的方法。对于部署，您可以使用ansible-pull，它可以在要设置的计算机上运行：
ansible-pull -U <repository> [options] [<playbook.yml>] 它将从指定的存储库获取Ansible配置到本地主机，然后执行您告诉它的剧本。
这应该满足您的要求，但这也意味着机器执行
ansible-pull将有权访问该存储库中的所有内容。对于您的环境而言，这是否足够安全取决于您。您可以将Ansible配置拆分为多个存储库，使用不同的分支，在初次拉出后撤消对计算机的访问等。通常，对存储库中的敏感数据进行加密（在磁盘上加密）您使用SSH或HTTPS（运行中的加密），并注意谁可以访问存储库，甚至可以间接访问（访问/用户管理），并且在建立一个相当安全的环境方面已经走了很长一段路。 >
是否使用CI部署Ansible是否足够安全，这值得商bat。有人可能会争辩说，获得（写入）Travis / GitLab帐户的人（使您保留Ansible剧本的人）已经可以访问您的基础架构，因为他们可以更改这些剧本，这只是时间问题。另一方面，存储在存储库中的代码只占基础架构代码的一半。 YMMV。
评论
也许您还可以提及terraform
– 030
19年1月27日在13:17
@ rubberband876是的，我这样做并在aws上运行我的控制机
– jdog
19年1月28日在4:48
@ rubberband876：当然，您可以使用Ansible设置您的Ansible控制机器。我以为您首先要解决设置机器以运行Ansible的问题。如果您使用Ansible设置Ansible，则还需要使用Ansible设置Ansible-Ansible-runner来运行Ansible来设置您的实际机器... :-)人们使用Vagrant / Terraform作为设置的第一步不需要“事先”设置的东西（那些虚拟机显得“凭空”，没有任何要求，完全独立于主机）。
– AnoE
19年1月28日在12:51
@ rubberband876：是的，这是正确的。
– AnoE
19年1月28日在21:26
@ rubberband876：关键在于-如果您不信任您的云/平台提供商，那么您就很不走运了，尤其是在“推送式”可部署的环境中。但是，最好为此提出一个新问题，因为我没有在Gitlab CI中使用Ansible，所以不知道是否有一个很好的选择来处理这些秘密，以防止他人窃取您的Gitlab帐户。
– AnoE
19年1月28日在23:12