Project1
Terraform
ec2.tf
rds.tf
…
variables.tf
scripts\<some script files>
templetes\<some tfl files as templates>
Ansible
Playbooks<some playbook yml files>
playbook1.yml
playbook2.yml
……
ansible_hosts
vars\<some variable files used by vars_file>
files\<files to be copied to remote hosts>
templates\<jinja2 templated files>
roles\<some roles such as webserver, dbserver, etc.>
注意，我尚未使用以下链接来布局Ansible代码：
https://leucos.github.io/ansible-files-layout
http://docs.ansible.com/ansible/latest/playbooks_best_practices.html
例如我没有将
vars/，templates/和files/放置到单个角色文件夹中，因为我的大多数角色都没有var和模板。此外，我想在一个文件中而不是多个角色中管理vars，templates，files，所以我将vars/，templates/和files/从roles/中移出了。对于我的下一个项目，我可以构建一个Infrastructure-使用CloudFormation / Terraform和Ansible / Chef的代码项目。接下来，我可能会在Jenkins，代码管道等上进行工作。 br />
或者我应该以这种方式基于工具来组织我的DevOps项目：但是那我们如何重用代码呢？例如，如果project1和project2使用相似的terraform代码和一些可笑的角色，该怎么办。我想将project1的代码重用到project2？
还是可以参考网上的任何典型示例？
#1 楼
存储库的布局在许多方面取决于要在其中开发自动化的环境。例如，如果您要作为产品团队的一部分来构建产品的基础架构，则将基础架构与产品-即将基础结构与软件源代码保存在相同的存储库中。 。那么拥有单个common-infrastructure存储库可能更有意义。其中一些将与您所使用的工具相关联，例如Terraform会带您沿路为所有环境建立一个单一存储库以支持terraform.tfstate构造。可重用性
您完全正确地将可重用性和代码共享称为一个问题，您将要早日而不是迟后遇到。这是软件开发中的一项重要原则，称为“请勿重复您的内容”（简称DRY）。大多数所有DevOps工具都允许您以无需复制/粘贴代码的方式对代码进行模块化：
Terraform模块
Ansible Roles
厨师图书馆
Jenkins插件
概念一致性
我建议您不要使用太多工具，请尝试对单个工具进行标准化，而不要更改用于每个项目，通常您会看到整个组织使用的工具集：
Jenkins，Terraform和Ansible
TeamCity，Octopus部署和所需状态配置
这样可以更轻松地在项目之间共享代码，记录到目前为止所做的工作并将代码移交给其他或将来的开发人员。
评论
谈到共享代码，使用git子模块有意义吗？这样就可以对其进行版本控制，并且不同的项目可以使用不同的版本，同时又易于升级。基本上是穷人VCS。
–莫里茨
18年1月9日在21:05
@Moritz您必须对子模块有所注意，并在整个团队的完全同意下将它们合并到您的工作流中，否则，它会陷入混乱。请参见有效使用子模块。
–Richard Slater
18年1月10日10:00
同意使用子模块要求团队相当熟悉Git。由于Git被当作SVN对待，所以在开始时出现了一些问题
–莫里茨
18年1月10日在12:32
谢谢理查德。目前，根据您的建议，我的基础架构即代码将根据项目进行分离。我已经在我的项目中扮演过一个角色。关于代码可重用性，未来的项目将如何利用我的项目中的角色1？我应该将目录project1的角色从project1移到顶层目录，以便project2也可以使用它吗？ ansible put角色目录中的所有教程。所以我不知道角色是如何重用的。
–user389955
18年1月10日在17:59
@ user389955我通常遵循开放源代码模型，可以将多个项目之间共享的所有内容提取到共享项目中。
–Richard Slater
18年1月11日，9：47