问题 1：假设您使用 Terraform 创建了一个 EC2 实例，创建完成后，您从状态文件中删除了该条目，那么运行 Terraform Apply 命令时会发生什么？
由于我们已从该状态文件中删除了该条目，因此 Terraform 将不再管理该资源，因此在下次执行 Apply 命令时，它将创建一个新的资源。
问题 2：Terraform 中的状态文件是什么？
状态文件是 Terraform 用来跟踪其部署的所有基础设施的文件。
问题 3：存储 Terraform 状态文件的最佳方式是什么？
存储状态文件的最佳方式是将其保存在远程后端，例如 S3 或 GitLab 管理的 Terraform State，这样当多个用户处理同一代码资源时，就不会发生重复。
问题 4：什么是 Terraform 状态锁定？
每当我们在处理任何 Terraform 代码并执行 Terraform 的规划、应用或销毁操作时，Terraform 都会锁定状态文件，以防止破坏性操作。
问题 5：什么是 Terraform 后端？
后端定义了 Terraform 存储其状态数据文件的位置。Terraform 使用持久化状态数据来跟踪其管理的资源。
问题 6：Terraform 中的插件是什么？
插件负责将 HCL 代码转换为 API 调用，并将请求发送到相应的提供商（AWS、GCP）。
问题 7：什么是空资源？
正如名称中所示，前缀为 null，这意味着该资源不存在于您的云基础设施中。
Terraform null_resource 可用于以下场景 -
- 运行 Shell 命令
- 您可以将其与本地配置器和远程配置器一起使用
- 它还可以与 Terraform 模块、Terraform 计数、Terraform 数据源和本地变量一起使用
- 它甚至可以用于输出块
问题 8：配置器有哪些类型？
远程执行：使用 Terraform 在远程服务器上运行命令
本地执行：使用 Terraform 在本地系统上运行命令
问题 9：Terraform 模块有什么用？
- 我们可以一次性创建 Terraform 模块，并在需要时重复使用它们。
- 为了使代码标准化
- 为了减少代码重复
- 模块可以进行版本控制。
问题 10：如果我使用 Terraform 创建了 EC2 和 VPC，但不幸 tfstate 文件被删除了，可以恢复吗？（该文件仅位于本地机器上，而不在 S3 或 Dynamo 数据库中）
您可以使用 Terraform import 命令导入 Terraform 创建的资源，然后它会进入状态文件。
问题 11：如果我们创建了不同的模块，例如 VPC、EC2、安全组、访问密钥和子网，那么 Terraform 如何确定应该首先部署哪个资源？
Terraform 会根据代码中的资源引用自动计算出依赖关系图。它理解资源之间的关系，并利用这些信息来确定创建或修改资源的顺序。
您可以使用depends_on关键字定义显式依赖关系。
问题12：如何在不更改逻辑的情况下删除/销毁特定资源？
- 使用taint和destroy命令
- 我们需要使用terraform taint RESOURCE_TYPE.RESOURCE_NAME命令对该资源进行污染。
- 污染资源后，您可以运行“destroy”命令，使用terraform destroy -target=RESOURCE_TYPE.RESOURCE_NAME命令删除受污染的资源。
问题13：如何在Terraform中重命名资源而不删除它？
我们可以使用terraform mv命令重命名资源而不删除它。
问题14：假设您使用Terraform创建了一个EC2实例，并且有人在您下次运行Terraform plan时对其进行了手动更改，会发生什么？
Terraform 状态将不匹配，Terraform 会将 EC2 实例修改为所需状态，即我们在 .tf 文件中定义的状态。
问题 15：Terraform 中的局部变量和变量有什么区别？
变量在 Variables.tf 文件中定义，或者使用可以覆盖的 Variables 关键字，但局部变量不能被覆盖。
因此，如果您想限制此时对变量的覆盖，则需要使用局部变量。
问题 16：解释 Terraform 的“本地”和“远程”后端配置之间的区别。
Terraform 状态文件是一个文件，用于存储 Terraform 所配置基础设施的当前状态。该状态文件可以本地存储或远程存储。本地状态文件存储在运行 Terraform 的计算机上。远程状态文件存储在远程服务器上。
a. 本地后端：本地后端将状态文件存储在运行 Terraform 的计算机的本地磁盘上。它是默认后端，无需任何额外配置。此后端适用于由单个开发人员管理基础设施的个人或小型项目。
b. 远程后端：远程后端将状态文件远程存储，通常存储在一个共享且可访问的位置。远程后端具有多种优势，包括：协作、一致性、可扩展性和安全性。
要配置远程后端，您需要指定后端类型（例如 S3、Azure 存储）、必要的凭据或访问详细信息以及其他可选设置。此配置通常存储在单独的文件中（例如 backend.tf），或作为 Terraform 命令的命令行参数提供。
总体而言，虽然本地后端适用于小型或个人项目，但在使用 Terraform 进行更大规模开发时，远程后端对于团队协作、可扩展性、一致性和增强的安全性至关重要。
问题 17：Terraform 的“target”参数是什么？它有何用途？
Terraform 中的“target”参数允许您指定单个资源或模块作为操作的目标。当您希望仅将更改应用于特定资源而不影响整个基础架构时，此功能尤其有用。例如：
terraform apply -target="aws_security_group.my_sg"
通过使用资源地址（例如本例中的安全组）指定“target”参数，Terraform 将仅将更改应用于该特定资源，从而最大限度地减少对其他资源的影响。
当您想要在大型基础设施部署中进行有针对性的更新或排查特定资源的故障时，这会非常有用。
问题 18：terraform_remote_state 数据源的用途是什么？如何使用？
Terraform 中的 terraform_remote_state 数据源支持从单独的 Terraform 状态文件共享和检索输出。它促进了不同 Terraform 配置或处理相关基础设施的团队之间的沟通。这提高了可重用性、一致性，并简化了不同 Terraform 项目之间的协作。
要使用 terraform_remote_state，您需要为远程状态定义后端配置并指定所需的输出。以下是如何在 Terraform 中使用 `terraform_remote_state` 的示例：
data "terraform_remote_state" "networking" {backend = "s3"config = {bucket = "example-bucket"key = "networking.tfstate"region = "us-west-2"
}
}
resource "aws_instance" "example" {
// 使用远程状态输出作为资源配置的输入subnet_id = data.terraform_remote_state.networking.outputs.subnet_id
// …
}
这里我们定义了一个引用名为“networking”的 terraform_remote_state 数据源的数据块。后端配置指定了 S3 存储桶、状态文件键和 AWS 区域。然后，我们可以在配置 aws_instance 等资源时访问远程状态的输出，例如 subnet_id。
问题 19：解释“不可变基础设施”的概念以及 Terraform 如何支持它。
不可变基础设施是一种架构方法，其中基础设施组件（例如服务器或容器）被视为不可变的，并且在初始部署后永远不会被修改。任何更新或更改都不是直接更改正在运行的实例，而是通过部署具有所需配置的新实例并替换旧实例来进行。
Terraform 通过多种方式支持不可变基础设施的概念：
a. 声明式基础设施即代码：Terraform 允许您使用声明式语言将基础设施定义为代码。使用 Terraform 代码，您可以指定基础设施的期望状态，而不是描述实现该状态的步骤。这种方法与不可变基础设施的理念非常契合，即定义所需配置并部署新实例以匹配该配置。
b. 基础设施版本控制：Terraform 与 Git 等版本控制系统集成，允许您跟踪和管理基础设施代码随时间的变化。此版本控制功能使您能够回滚到先前的基础设施状态或跟踪部署历史记录。
c.不可变资源管理：使用 Terraform，您可以使用资源提供程序为各种云平台配置和管理基础设施资源。Terraform 将资源视为不可变实体，可以创建、更新或销毁，但不能直接修改。
问题20: 您拥有不同的环境，并且希望在所有环境（例如开发、测试、生产等）中部署基础架构。该如何实现？
每个应用程序在部署到生产环境之前都会经历不同的环境。为了保持一致性，拥有相似的环境始终是最佳实践。复制错误并轻松修复它们非常容易。如果我们手动操作，则很难在每个环境中复制相同的基础架构。Terraform 可以轻松在多云环境中创建基础架构。
Terraform — 在多环境中创建基础架构的 4种方法
1) 使用文件夹
3) 工作区
4) 模块
5) Terragrunt
问题21 如何限制提供程序版本？
要按照建议限制提供程序版本，请在 Terraform 块中添加一个 required_providers 块：
terraform {required_providers {aws = "~> 1.0"}
}
问题22. 配置提供程序版本的方法有多少种？
1. 使用 Terraform 块下的 required_providers 块
terraform {required_providers {aws = "~> 1.0"}
}
2. 也可以使用提供程序块中的版本参数指定提供程序版本约束
provider {version= "1.0"
}
问题23. 如何配置多个提供程序实例？
别名
您可以选择为同一个提供程序定义多个配置，并根据每个资源或每个模块选择使用哪个配置。
问题24. 为什么需要多个提供程序实例？
一些示例场景：
a.一个云平台的多个区域
b. 针对多个 Docker 主机
c. 多个 Consul 主机等
问题25. 如何定义多个提供程序配置？
要为给定提供程序包含多个配置，请包含具有相同提供程序名称的多个提供程序块，但将 alias 元参数设置为每个附加配置使用的别名。
# 默认提供程序配置
provider "aws" {region = "us-east-1"
}
# 西海岸区域的附加提供程序配置
provider "aws" {alias = "west"region = "us-west-2"
}
问题26. 如何选择备用提供程序？
默认情况下，资源使用从资源类型名称的第一个单词推断出的默认提供程序配置。例如，除非另有说明，否则 aws_instance 类型的资源将使用默认（未使用别名的）aws 提供程序配置。
resource "aws_instance" "foo" {provider = aws.west
# ...问题27. 什么是提供程序插件缓存？
默认情况下，terraform init 会将插件下载到工作目录的子目录中，以便每个工作目录都是独立的。因此，如果您有多个使用同一提供程序的配置，则每个配置都会下载其插件的单独副本。鉴于提供程序插件可能非常大（大约数百兆字节），这种默认行为对于那些网络连接速度较慢或流量计费的用户来说可能不方便。因此，Terraform 可以选择使用本地目录作为共享插件缓存，这样每个不同的插件二进制文件只需下载一次。
问题28. 使用插件缓存时，缓存目录最终会变得越来越大，包含不同的版本。谁负责清理它？
用户
一旦插件被放入插件缓存中，Terraform 就永远不会自行删除它。随着时间的推移，随着插件的升级，缓存目录可能会变得很大，包含多个未使用的版本，这些版本必须手动删除。
问题29. 如果不同的团队使用相同的配置，如何确保文件格式一致？
terraform fmt此命令会自动更新当前目录中的配置，以提高可读性和一致性。
