azure - 地形和更新

Question

能够在单个 Terraform 文件中捕获基础设施具有明显的好处。但是，我不清楚如何处理 - 例如，一旦创建了虚拟机 - 后续的更新是如何处理的。

所以，提供一个具体的场景。假设我们使用 Terraform 设置了一个带有 SQL Server 2014 的 Azure 虚拟机。然后，一个月后，我们决定使用刚刚发布的 SQL Server 2014 的最新服务包更新该虚拟机。

建议我们更新 Terraform 配置文件并重新应用它吗？

Answer 1

我不同意其他两个回复。 Terraform 可以很好地处理基础设施更新。然而，要理解的关键是，Terraform 在很大程度上遵循不可 rebase 础设施范例，这意味着要“更新”资源，您需要删除旧资源并创建一个新资源来替换它。这很像函数式编程，其中变量是不可变的，并且为了“更新”某些内容，您实际上创建了一个新变量。

Terraform 的典型模式是使用它来部署服务器镜像，例如虚拟机 (VM) 镜像(例如 Amazon Machine Image (AMI) )或容器镜像(例如 Docker Image )。当您想要“更新”某些内容时，您可以创建镜像的新版本，将其部署到新服务器上，然后取消部署旧服务器。

以下是其工作原理的示例:

假设您正在构建一个 Ruby on Rails 应用程序。您让应用程序在开发环境中运行，是时候部署到生产环境了。第一步是将应用程序打包为 AMI。您可以使用 Packer 等工具来执行此操作。现在您拥有一个 ID 为 ami-1234 的 AMI。

以下是一个 Terraform 模板，您可以使用它在 AWS 中的服务器(EC2 Instance )上部署此 AMI，并附加一个 Elastic IP Address:

resource "aws_instance" "example" {
  ami = "ami-1234"
  instance_type = "t2.micro"
}

resource "aws_eip" "example" {
  instance = "${aws_instance.example.id}"
}

当您运行 terraform apply 时，Terraform 会部署服务器，并为其附加一个 IP 地址，现在当用户访问该 IP 时，他们将看到您的 Rails 应用程序的 v1。

一段时间后，您更新了 Rails 应用程序并想要部署新版本 v2。为此，您需要构建一个新的 AMI(即再次运行 Packer)以获取 ID 为“ami-5678”的 ami。您相应地更新您的 Terraform 模板:

resource "aws_instance" "example" {
  ami = "ami-5678"
  instance_type = "t2.micro"
}

当您运行 terraform apply 时，Terraform 会取消部署旧服务器(它可以找到它，因为 Terraform records the state of your infrastructure )，使用新 AMI 部署新服务器，现在用户将在该位置看到您的代码的 v2相同的IP。

当然，这里存在一个问题:在 Terraform 取消部署 v1 和部署 v2 之间，您的用户会看到停机时间。要解决这个问题，您可以使用 Terraform 的 create_before_destroy 生命周期设置:

resource "aws_instance" "example" {
  ami = "ami-5678"
  instance_type = "t2.micro"

  lifecycle {
    create_before_destroy = true
  }
}

将create_before_destroy设置为true时，Terraform将首先创建替换服务器，将IP切换到它，然后删除旧服务器。这允许您使用不可变的基础设施进行零停机部署(注意:零停机部署与可以进行健康检查的负载均衡器配合使用比简单的 IP 地址效果更好，特别是如果您的服务器需要很长时间才能启动)。

有关这方面的更多信息，请查看《Terraform: Up & Running》一书。本书的代码示例包括一个使用服务器集群和负载均衡器的零停机部署示例:https://github.com/brikis98/terraform-up-and-running-code