地形和更新

Question

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

因此，提供了一个特定的方案。假设使用Terraform我们使用SQL Server 2014设置了一个Azure vm。然后，一个月后，我们决定我们要使用刚刚发布的SQL Server 2014的最新Service Pack更新该vm。

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

Answer 1

我必须不同意其他两个答复。Terraform可以很好地处理基础结构更新。但是，要了解的关键是Terraform在很大程度上遵循不变的基础架构范例，这意味着要“更新”资源，您需要删除旧资源并创建新资源来替换它。这与函数编程非常相似，在函数编程中，变量是不可变的，并且要“更新”某些内容，您实际上要创建一个新变量。

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

这是一个如何工作的示例：

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

这是一个Terraform模板，您可以使用该模板在附加了弹性IP地址的 AWS 上的服务器（EC2实例）上部署此AMI ：

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记录了您的基础架构状态，因此可以找到它），使用新AMI部署新服务器，现在用户将在同一IP上看到您的代码v2。

当然，这里存在一个问题：在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地址更好，尤其是在服务器启动时间较长的情况下）。

有关此的更多信息，请参阅《地形：启动与运行》一书。本书的代码示例包括一个零停机时间部署示例，该部署具有服务器集群和负载均衡器：https : //github.com/brikis98/terraform-up-and-running-code