我们有一台 ubuntu 22 ansible 服务器。我们想在这台服务器上运行 ansible playbook，多个用户将运行 ansible playbook，但我们希望他们以自己的名义运行，因此不需要专门的 ansible 用户。我们可以为此创建一个组 ansible_users。
ansible 剧本存储在 git 中，多个用户可以进行更改，所以我们希望 ansible 服务器上的用户能够通过 git 拉取更新。
仓库应该存储在哪个位置？
我在想也许是/opt或者/usr/local/src或者/usr/src，但我真的不确定哪个更合理。git repo 的最佳位置在哪里，应该可以被多个用户更新/使用。
背景：假设有两个人在 git repo 上处理代码，他们都被允许使用 git repo 中的更改来更新服务器代码（git pull）。
但是其他人被允许阅读/使用 ansible playbooks，但不允许 git pull/更改代码。
目标是拥有一个真实来源，因此不要让所有用户都在他们的主目录中自己检出 repo。
但是如果我将它放在 /tmp 中，repo 将被删除，它也不属于任何人，因此将它放在某人的主目录中也没有意义。
什么目录才有意义？
答案1
由于 git 是一个分布式版本控制，因此您不仅限于只有一个副本用于开发和操作。
例如，Fedora infra 使用 git 并公开了其工作原理，但当然他们使用的是私人副本。并不是要认可他们正在做的任何具体事情，但很明显，应用程序和服务器列表反映了实际工作。
应尽可能减少人员接触服务器，以减少未记录或未经授权的更改的可能性。理想情况下，对运行自动化的管理主机的访问比大多数东西都严格得多，它具有更改内容的管理员访问权限！除了不更改自动化文件外，人们还不应访问特权凭据，也许加载到 ssh-agent 中。
那么如何与团队协作？参考存储库可以与用于操作的副本分开。对于这个事实来源，请使用您已有的任何 git 托管。实现问题跟踪、合并请求、基于角色的访问控制、自动测试等功能。根据所需的工作流程，人们可以从中克隆个人副本，然后将合并请求提交回主分支。这是自动化存在的公共记录。Fedora infra 为此使用 pagure.io 上的公共存储库，如果愿意，可以使用私有 GitLab 之类的东西代替。所有这些的输出是树，它是已批准自动化的事实来源。
然后，操作会获得此树的副本。出于安全和弹性的原因，在单独的管理主机上。git 当然可以获取远程存储库。在此模型下，提交不应在 ops 副本上进行，而应在 dev 副本中向上游进行，并使用脚本进行镜像。如果由于参考副本已关闭而需要对 ops 副本进行提交，这并不是最糟糕的事情，但这需要在某个时候解决。Fedora infra 在用于获取的裸存储库和其他一些存储库之间有多个副本。请调整以适合您使用 git 的方式。
最后，您问的是工作副本应该是什么。我的设计使用 git 托管功能来控制上游访问。人们不需要对 ops 副本进行太多写入，因此写入可能仅限于镜像它的服务用户和一组熟悉 git 的管理员。允许多个人编辑一个工作副本可能会导致问题，git 不会阻止同时更改同一文件的冲突。
至于将树放在哪里，个人管理员或自动化系统是否可以在其主目录中使用个人副本或其他地方并不重要。但无论如何，让我们标准化：它是数据，而不是软件，也不是用户特定的，所以我倾向于使用/srv。事实上，Fedora infra 有 /srv/git/ansible该存储库的其他副本。这些剧本可以作为服务用户（计划任务，在触发器上）或由个人运行。对于个人来说，用于访问控制或日志记录的包装器脚本可能会有所帮助，例如rbac_playbook
机密应单独存储。例如机密系统，其 API 密钥仅加载到运行 playbook 的管理主机中。
总体而言，将开发和运营问题分开是有好处的。在“上游”副本上进行协作开发可以利用软件工具。运营应该在受限制的访问副本上进行，运行自动化工具是一件有特权的事情。
设想一个理想情况，新员工的任务是学习如何按照组织的规范安装应用服务器。他们克隆公共自动化存储库，将其指向个人测试主机，然后实现它。稍后，当他们被允许监督生产自动化时，它的行为方式完全相同。