地形和更新 [英] Terraform and Updates

问题描述

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

Being able to capture infrastructure in a single Terraform file has obvious benefits. However, I am not clear in my mind how - once, for example, a virtual machine has been created - subsequent updates are handled.

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

So, to provide a specific scenario. Suppose that using Terraform we set up an Azure vm with SQL Server 2014. Then, after a month we decide that we should like to update that vm with the latest service pack for SQL Server 2014 that has just been released.

我们是否建议更新 Terraform 配置文件并重新应用它?

Is the recommended practice that we update the Terraform configuration file and re-apply it?

推荐答案

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

I have to disagree with the other two responses. Terraform can handle infrastructure updates just fine. The key thing to understand, however, is that Terraform largely follows an immutable infrastructure paradigm, which means that to "update" a resource, you delete the old resource and create a new one to replace it. This is much like functional programming, where variables are immutable, and to "update" something, you actually create a new variable.

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

The typical pattern with Terraform is to use it to deploy a server image, such as an Virtual Machine (VM) Image (e.g. an Amazon Machine Image (AMI)) or a Container Image (e.g. a Docker Image). When you want to "update" something, you create a new version of your image, deploy that onto a new server, and undeploy the old server.

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

Here's an example of how that works:

假设您正在构建一个 Ruby on Rails 应用程序.你让应用程序在 dev 中运行，是时候部署到 prod 了.第一步是将应用程序打包为 AMI.您可以使用 Packer 之类的工具来执行此操作.现在您有一个 AMI，其 id 为 ami-1234.

Imagine that you're building a Ruby on Rails app. You get the app working in dev and it's time to deploy to prod. The first step is to package the app as an AMI. You could do this using a tool like Packer. Now you have an AMI with id ami-1234.

这是一个 Terraform 模板，可用于在服务器上部署此 AMI(EC2 实例) 在 AWS 中使用 弹性 IP 地址 附在上面:

Here is a Terraform template you could use to deploy this AMI on a server (an EC2 Instance) in AWS with an Elastic IP Address attached to it:

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.

When you run terraform apply, Terraform deploys the server, attaches an IP address to it, and now when users visit that IP, they will see v1 of your Rails app.

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

Some time later, you update your Rails app and want to deploy the new version, v2. To do that, you build a new AMI (i.e. you run Packer again) to get an ami with ID "ami-5678". You update your Terraform templates accordingly:

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

当您运行 terraform apply 时，Terraform 会取消部署旧服务器(它可以找到它，因为 Terraform 记录您的基础架构状态)，使用新 AMI 部署新服务器，现在用户将在同一 IP 上看到您的代码的 v2.

When you run terraform apply, Terraform undeploys the old server (which it can find because Terraform records the state of your infrastructure), deploys a new server with the new AMI, and now users will see v2 of your code at that same IP.

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

Of course, there is one problem here: in between the time when Terraform undeploys v1 and when it deploys v2, your users would see downtime. To work around that, you could use Terraform's create_before_destroy lifecycle setting:

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

  lifecycle {
    create_before_destroy = true
  }
}

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

With create_before_destroy set to true, Terraform will create the replacement server first, switch the IP to it, and then remove the old server. This allows you to do zero-downtime deployment with immutable infrastructure (note: zero-downtime deployment works better with a load balancer that can do health checks than a simple IP address, especially if your server takes a long time to boot).

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

For more information on this, check out the book Terraform: Up & Running. The code samples for the book include an example of a zero-downtime deployment with a cluster of servers and a load balancer: https://github.com/brikis98/terraform-up-and-running-code

这篇关于地形和更新的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！