注意 ：这是Navigator指南书内容的早期发布版本，这是DigitalOcean Solutions Engineers提供的产品。 本书的目标是帮助企业客户规划他们的基础架构需求，提供工作实例，并包括技术细微差别和“为什么”，使得某些决策比其他决策更好。
本书和随附的代码将在GitHub存储库中公开提供。 因为这是一个早期版本，该书尚未完成，存储库尚未公开，但请继续关注！
上一节使用Terraform和Ansible来配置资源（Droplet，负载均衡器和浮动IP）并部署您的WordPress应用程序。
Terraform使用main.tf文件创建了这些资源。 目前，该文件中的所有资源都是单独列出的。 您的环境越复杂，您需要的资源就越多，这个文件就会越长越复杂。 这将使您的配置更难以长期管理。
在本补充部分中，我们将讨论使用Terraform模块和单独的基础架构环境简化此配置的一些方法。 在本节中没有要执行的代码和更改，但在构建实际设置时，这些概念很重要。
了解Terraform模块
要使用Terraform自己的模块描述：
Terraform中的模块是Terraform配置的独立包，可作为一个组进行管理。 模块用于在Terraform中创建可重用组件以及基本代码组织。
模块创建可重用基础设施块，可以接受输入并提供输出，就像高级编程语言中的功能一样。 我们可以为类似的基础架构创建接受可选输入参数的模块，并为这些输入参数设置默认值。 这有助于组织和简化配置。 您可以在Terraform的模块文档中了解有关模块的更多信息。
有关完整的示例，请查看main.tf文件。 最后一部分实际上已经在使用Terraform模块：
module "sippin_db" {
source = "github.com/cmndrsp0ck/galera-tf-mod.git?ref=v1.0.6"
...
}
您可以将此部分与文件顶部的wp_node资源块进行wp_node ，该文件具有更多代码行并且更难以遵循。 您将注意到使用远程git存储库调用该模块。 您可以使用本地文件路径，这可以用于一些快速开发和测试，但使用远程git repo可以使您的环境隔离更进一步。 这在运行多个基础架构环境（如登台和生产）时尤其有用。 当使用具有多个基础结构环境的本地文件路径时，您最终可以进行旨在仅影响暂存的更改，但如果您要在prod上运行apply并且正在共享模块文件路径，那么您最终可能会破坏某些内容。 如果您有针对每个环境的专用目录，那么您最终必须维护两个或更多脚本副本，并且恢复到以前的状态将不会那么容易。
使用远程git存储库并指定模块的版本号可以避免此问题。 如前所述，如果出现问题，它还可以更容易地恢复到已知的工作版本，这可以提高您管理事件和中断的能力（我们将在第9章中详细介绍）。
该模块不仅仅创建一个Droplet。 它创建了Droplet标签，Galera集群节点，负载平衡器和浮动IP。 您可以将terraform模块视为打包/或整个服务组件的好方法。 它还意味着您可以向模块添加更多资源，或者您可以创建模块输出，这些输出又可以用作您可能正在开发的其他模块的输入。 当创建新模块有意义时，例如添加新服务或某些您想要解耦的支持功能，您绝对可以在模块中创建输出，并将它们存储为您所在州的一部分。 如果您正在使用远程状态，当您希望在基础结构的不同组件之间共享只读信息或为外部服务提供检索其可能需要的信息的方式时，模块输出可能非常有用。
简而言之，如果您将Terraform计划中的资源部分视为乐高积木，那么您的模块将是预先组装的部分。 这比在任何地方跟踪乐高积木并且可能踩到乐高积木要好得多。 除了帮助防止这种痛苦之外，这些模块还可用于在您的基础架构计划中增加复杂性时通知其他模块的配置。
设置基础结构环境
在大多数专业项目中，您将使用三种不同的环境：开发，登台和生产。
您的开发环境通常是本地的，并为您提供在工作时独立修补和测试的空间。 另一方面，您的临时和生产环境将位于共享或公共空间中，并将使用Terraform等自动化流程进行配置。
从周到和有计划的部署工作流程开始，将在很长一段时间内防止头痛，其中一部分包括将环境彼此隔离。 Terraform的工作区功能使terraform.tfstate文件按环境分开，但对描述资源的terraform文件所做的更改则不然。 因此，虽然此功能可以很好地作为进行微小更改，测试和部署的快速方法，但是当您拥有可能需要彼此隔离服务以及团队的更大部署时，不应该依赖此功能。管理他们。
这是一个示例目录树，描述了如何使用目录设置环境隔离：
.
├── ansible.cfg
├── bin/
├── environments/
│ ├── config/
│ │ └── cloud-config.yaml
│ │
│ ├── dev/
│ ├── prod/
│ │ ├── config -> ../config
│ │ ├── group_vars
│ │ ├── host_vars
│ │ ├── main.tf
│ │ ├── terraform.tfvars
│ │ ├── terraform-inventory -> ../terraform-inventory
│ │ └── variables.tf
│ │
│ ├── staging/
│ │ ├── config -> ../config
│ │ ├── group_vars
│ │ ├── host_vars
│ │ ├── main.tf
│ │ ├── terraform.tfvars
│ │ ├── terraform-inventory -> ../terraform-inventory
│ │ └── variables.tf
│ │
│ └── terraform-inventory
│
├── site.yml
├── wordpress.yml
│
└── roles/
这种布局背后的关键逻辑是将与相似组件相关的文件保持在彼此不同的环境中。
例如，在environments目录中，我们有三个我们想要的环境的子目录： dev ， staging和prod 。 此隔离有助于防止在错误的位置意外运行Ansible或Terraform脚本。 您可以更进一步，使用另一层子目录来保存每个环境基础结构的不同部分的文件。
关于这个主题在网上有很多很棒的文章 ，其中一篇实际上已经变成了由Yevgeniy Brikman撰写的Terraform：Up＆Running一书。
在环境中使用模块版本控制
Terraform模块还可以帮助您进行更改，而不会影响其他环境。 例如，看看这两个模块。
一个用于登台环境（例如， staging/main.tf ）：
module "sippin_db" {
source = "github.com/cmndrsp0ck/galera-tf-mod.git?ref=v1.0.8"
project = "${var.project}"
region = "${var.region}"
keys = "${var.keys}"
private_key_path = "${var.private_key_path}"
ssh_fingerprint = "${var.ssh_fingerprint}"
public_key = "${var.public_key}"
ansible_user = "${var.ansible_user}"
}
一个用于生产环境（例如， prod/main.tf ）：
module "sippin_db" {
source = "github.com/cmndrsp0ck/galera-tf-mod.git?ref=v1.0.6"
project = "${var.project}"
region = "${var.region}"
keys = "${var.keys}"
private_key_path = "${var.private_key_path}"
ssh_fingerprint = "${var.ssh_fingerprint}"
public_key = "${var.public_key}"
ansible_user = "${var.ansible_user}"
}
它们之间的唯一区别是source行末尾的ref键值，它指定要部署的版本。 在分段中，它是v1.0.8 ，在生产中，它是v1.0.6 。 使用版本控制可以在部署到生产之前制作和测试分段中的更改，这些设置可以简化支持该配置的配置。
现在，上一节中的动手设置不使用远程状态。 在第6章中，我们介绍了使用远程状态后端（如Consul），这在团队工作时很关键。 如果没有远程状态后端，您和另一个团队成员可以同时对基础结构执行更改，从而导致状态文件发生冲突，中断或损坏。
下一步是什么？
了解如何通过模块化以及如何隔离环境以实现更安全的开发和部署来简化基础架构代码，我们可以了解如何通过创建模板来提高部署速度。 下一章将介绍如何使用持续开发工具自动化部署工作流，这将有助于您安全，快速地部署新代码。
