aws terraform
Serverless development has unlocked a number of patterns that were impractical when dealing with environments that billed by the hour rather than by usage. This post will cover an opinionated pattern of creating a vending machine for serverless environments that can quickly stand up completely isolated environments within the same cloud account.
无服务器开发已经释放了许多模式，这些模式在处理按小时计费而不是按使用计费的环境时是不切实际的。 这篇文章将涵盖为无服务器环境创建自动售货机的一种自以为是的模式，该环境可以快速地在同一云帐户中建立完全隔离的环境。
This post will focus on AWS using Terraform, but in theory, can apply to any major cloud provider or IaC tool.
这篇文章将重点介绍使用Terraform的 AWS ，但从理论上讲，它可以适用于任何主要的云提供商或IaC工具。
为什么无服务器需要隔离的环境 (Why Serverless Needs Isolated Environments)
With traditional bill by hour cloud server solutions, a typical workflow may look like this:
使用传统的按小时计费的云服务器解决方案，典型的工作流程可能如下所示：
Develop Locally-> Test Locally-> Push Code -> Test/Deploy
本地开发->本地测试->推送代码->测试/部署
Serverless solutions, especially those that leverage AWS Lambda, can be difficult for a developer to test locally. It’s not as simple as running the code in your local terminal or deploying a web server to localhost. Serverless code is much more opinionated and oftentimes cannot be run locally. Code needs to be deployed out to the cloud in order to test functionality. Typically, this is done by deploying to a shared development environment within AWS.
对于开发人员而言，无服务器解决方案(尤其是那些利用AWS Lambda的解决方案)可能很难在本地进行测试。 这并不像在本地终端中运行代码或将Web服务器部署到localhost那样简单。 无服务器代码更为自以为是，通常无法在本地运行。 需要将代码部署到云中以测试功能。 通常，这是通过部署到AWS内的共享开发环境来完成的。
In a collaborative team with multiple engineers, a shared environment can quickly get messy. For example, A QE Engineer needs to test a specific version (Version A) of a service in the dev environment. At the same time, a software engineer is developing the latest feature for that same service (Version B). The QE engineer needs version A to be deployed to dev so that they can test it, but the software engineer wants to deploy version B to dev so that he or she can ensure his or her changes will work in AWS. Without proper coordination, the 2 engineers end up stepping on each other’s toes by deploying different versions of the same software to the the same environment.
在具有多个工程师的协作团队中，共享环境很快就会变得混乱。 例如，一名QE工程师需要在开发环境中测试服务的特定版本(版本A)。 同时，软件工程师正在为同一服务(版本B)开发最新功能。 QE工程师需要将版本A部署到开发人员中，以便他们可以对其进行测试，但是软件工程师希望将版本B部署到开发人员中，以便他或她可以确保自己的更改将在AWS中生效。 在没有适当协调的情况下，这两名工程师最终通过将相同软件的不同版本部署到相同环境来互相踩踏。
We can combat this issue by giving each engineer their own AWS account. However, this can be a costly solution and lead to an enormous number of AWS accounts across the business. Most businesses are not set up to handle a large number of cloud accounts. The security overhead alone is enough to make anyone’s head spin. Instead, the goal should be to create isolated environments all within a single AWS account.
我们可以通过为每个工程师提供自己的AWS账户来解决此问题。 但是，这可能是一个昂贵的解决方案，并导致整个企业中有大量AWS账户。 大多数企业未设置为处理大量云帐户。 仅安全性开销就足以使任何人头痛。 相反，目标应该是在一个AWS账户内创建隔离的环境。
为什么自动售货环境不切实际 (Why Vended Environments Were Impractical)
Historically, it’s not been possible to give every engineer a prod-like environment for a few reasons:
从历史上看，由于以下几个原因，不可能为每个工程师提供类似于产品的环境：
- It’s not cost effective (per hour billing, physical server space, etc.) 它的成本效益不高(每小时计费，物理服务器空间等)
- There’s added overhead to building multiple prod-like environments (before infrastructure-as-code (IaC) this could take days with lots of room for error) 建立多个类似于prod的环境会增加开销(在使用基础架构代码(IaC)之前，可能要花几天的时间，并且有很多错误的余地)
- High potential for naming conflicts for serverless environments if deployed to a single account (each Lamba would need a unique name, etc.) 如果将无服务器环境部署到单个帐户，则很有可能发生命名冲突(每个Lamba需要唯一的名称，等等)
Serverless architecture combined with IaC tools like Terraform can easily mitigate these problems.
无服务器架构与IaC工具(例如Terraform)相结合可以轻松缓解这些问题。
计费模式 (Billing Model)
One of the key benefits of a serverless offering is the billing model. Serverless environments bill by request, execution time or storage volume, not by the hour. This enables us to create many environments that only receive a small amount of traffic without getting large hourly charges.
无服务器产品的主要优势之一是计费模型。 无服务器环境按请求，执行时间或存储量计费，而不是按小时计费。 这使我们能够创建许多仅接收少量流量而不会收取大量小时费用的环境。
Pay for value:Pay for consistent throughput or execution duration rather than by server unit.
按价值付费：为获得一致的吞吐量或执行持续时间而付费，而不是按服务器单位付费。
高架 (Overhead)
With the introduction of cloud computing and IaC, the overhead to create any number of isolated prod-like environments has been significantly reduced. Aside from any initial overhead in writing Terraform code and configuring a deployment pipeline, any additional overhead to create extra environments is next to zero. Run your vending machine and within minutes an isolated, properly namespaced environment is at your fingertips.
随着云计算和IaC的引入，创建任意数量的类似prod的环境的开销已大大减少。 除了编写Terraform代码和配置部署管道的任何初始开销外，创建额外环境的任何其他开销都接近于零。 运行您的自动售货机，几分钟之内即可获得一个隔离的，正确命名空间的环境。
Let’s look at how to do exactly that.
让我们看看如何做到这一点。
轻松创建和清理环境 (Ease of Environment Creation and Clean Up)
基础设施法规 (Infrastructure Code)
The first and most important problem to solve is Terraform variable namespacing. We not only need to create a separate Terraform workspace, but to make sure that certain variable names are unique.
要解决的第一个也是最重要的问题是Terraform变量的命名空间。 我们不仅需要创建一个单独的Terraform工作空间，而且还要确保某些变量名称是唯一的。
Let’s take S3 for example. Regardless of workspace, S3 buckets cannot have the same name. Therefore, if an S3 bucket name is in the Terraform, it will need to be properly namespaced to differentiate it from the bucket in the dev environment. We can do this by concatenating a unique identifier onto the S3 bucket name. Using this method, each environment would have its own unique identifier. See the S3 Terraform code below. For more information on Terraform local variables, see here.
让我们以S3为例。 无论工作空间如何，S3存储桶都不能使用相同的名称。 因此，如果S3存储桶名称位于Terraform中，则需要为其命名，以使其与开发环境中的存储桶区分开来。 我们可以通过在S3存储桶名称上串联一个唯一标识符来做到这一点。 使用此方法，每个环境将具有其自己的唯一标识符。 请参阅下面的S3 Terraform代码。 有关Terraform局部变量的更多信息，请参见此处 。
Note: We will be referring to the unique identifier in Terraform as namespace.
注意 ：我们将把Terraform中的唯一标识符称为名称空间 。
We also need to declare namespace as its own variable.
我们还需要声明名称空间作为其自己的变量。
As such, your tfvars file would remain unchanged from a normal implementation of an S3 resource. The namespace would be populated at runtime rather than having a hardcoded value.
这样，您的tfvars文件在S3资源的常规实现中将保持不变。 名称空间将在运行时填充，而不是具有硬编码的值。
Now that we know how to structure our Terraform code to utilize an optional variable for namespacing, let’s look at how to populate that variable.
现在，我们知道了如何构造Terraform代码以利用可选变量进行命名间隔，让我们看看如何填充该变量。
生成命名空间值 (Generating a Namespace Value)
We want the namespacing functionality to be optional so that we can deploy to either a shared environment like dev or prod (without namespacing) or a personalized environment (with namespacing). Therefore, we want an easy way to populate the namespace without having to hardcode a value in the tfvars file.
我们希望命名空间功能是可选的，以便我们可以将其部署到诸如dev或prod的共享环境(不使用命名空间)或个性化环境(使用命名空间)。 因此，我们需要一种简单的方法来填充名称空间，而不必在tfvars文件中对值进行硬编码。
One of the best ways to do this is to have the Terraform workspace name double as the namespace. We can use Terraform’s native workspace interpolation. Below is an example of our local variable declaration with workspace interpolation. You can read more about Terraform Workspaces here.
最好的方法之一是让Terraform工作区名称加倍作为名称空间。 我们可以使用Terraform的本机 工作空间插值。 以下是带有工作空间插值的局部变量声明的示例。 您可以在此处阅读有关Terraform工作区的更多信息。
Even though this is not the only way to populate the namespace, there are a number of benefits to doing it this way:
即使这不是填充名称空间的唯一方法，用这种方法也有很多好处：
Workspace name and namespace are always in sync which allows for greater traceability (what resources belong to which workspace, etc.)
工作空间名称和名称空间始终保持同步，这可以实现更大的可追溯性(哪些资源属于哪个工作空间等)
- Very little human intervention needed; highly automatable 几乎不需要人工干预； 高度自动化
- 100% Terraform native 100％Terraform原生
If a developer wanted to create a separate, isolated environment, a sample workflow would now look something like this:
如果开发人员想要创建一个单独的隔离环境，那么示例工作流现在看起来应该像这样：
Initialize your Terraform project
terraform init初始化 Terraform项目Terraform
terraform initCreate a new workspace
terraform workspace new demo创建一个新的工作空间
terraform workspace new demoApply your Terraform code
terraform apply套用您的Terraform代码
terraform applySince the workspace is no longer
defaultTerraform will append the workspace name tobucket_name由于工作空间不再是
defaultTerraform会将工作空间名称附加到bucket_namebucket_nameis nowmy-bucket-demobucket_name现在是my-bucket-demo
自动贩卖机管道 (Vending Machine Pipeline)
Now that the infrastructure side of things is done, we need to make this into a “push button” solution. That can be as easy as doing the following. Enter your workspace name, hit a button, and a namespaced environment is spun up in minutes. We can do this using any CI/CD tool, but in this specific case we’ll be looking at Jenkins.
现在已经完成了基础架构方面的工作，我们需要将其变成“按钮”解决方案。 这可以像执行以下操作一样容易。 输入您的工作空间名称，单击按钮，然后在几分钟内启动命名空间。 我们可以使用任何CI / CD工具执行此操作，但是在这种特定情况下，我们将研究Jenkins。
Here’s an example of what a Vending Machine pipeline might look like.
这是自动贩卖机管道的外观示例。
A more detailed breakdown of pipeline steps include:
管道步骤的更详细细分包括：
Build & Deploy — Build or compile your serverless code. For example, building and pushing your Lambda bundle to S3, or building and pushing a docker image to ECR
构建和部署 —构建或编译无服务器代码。 例如，将Lambda捆绑包构建并推送到S3，或者将Docker映像构建并推送到ECR
Run Terraform — Apply your Terraform code in the workspace of your choosing. If
TF_WORKSPACEis left as default, deploy to shared environment (dev, qa, prod, etc.)运行Terraform —在您选择的工作区中应用Terraform代码。 如果
TF_WORKSPACE保留默认设置，部署到共享环境(dev，qa，prod等)Run Tests — Optional stage if a QA engineer may need to run tests in a fresh isolated environment. Determined by value of
RUN_TESTS运行测试 —如果QA工程师可能需要在新鲜的隔离环境中运行测试，则为可选阶段。 由
RUN_TESTS的值确定Cleanup — Optional stage determined by value of
DESTROY. If set to true, rather than create a new environment, the pipeline will destroy whichever environment is specified byTF_WORKSPACE清理 —由
DESTROY的值确定的可选阶段。 如果设置为true，则管道将销毁TF_WORKSPACE指定的任何环境，而不是创建新的环境
詹金斯档案 (Jenkinsfile)
The Jenkinsfile describes the job that will be executed by Jenkins in a programmatic fashion. More information can be found here. The file is a collection of calls to Terraform to build and deploy code, create infrastructure, leverage user input to approve the Terraform plans, as well as calls to various testing scripts.
Jenkins文件描述了将由Jenkins以编程方式执行的作业。 在这里可以找到更多信息。 该文件是对Terraform的调用的集合，这些调用用于构建和部署代码，创建基础结构，利用用户输入来批准Terraform计划，以及对各种测试脚本的调用。
Hashicorp provides a guide for running Terraform in automation which can be found here.
Hashicorp提供了在自动化中运行Terraform的指南，可在此处找到。
Below is a sample Jenkinsfile using pseudocode:
以下是使用伪代码的示例Jenkinsfile：
数据静态环境 (Data Static Environments)
What about applications that require some form of sample data to work? Sometimes that data is loaded into the shared environment and engineers don’t want to migrate all that data into every new environment that’s stood up. The solution here is simple: automate!
需要某种形式的示例数据才能工作的应用程序呢？ 有时，这些数据已加载到共享环境中，工程师不希望将所有数据迁移到已建立的每个新环境中。 这里的解决方案很简单：自动化！
If our application has a backend database that requires sample data in order to be useful, we can create a data seed library. For example, we can create a library that when called can automatically load a set of example data into our environment using our application’s own APIs. Seeding the data using our own APIs will provide us sample data and act as a test to ensure proper API functionality.
如果我们的应用程序有一个后端数据库，该数据库需要样本数据才能有用，那么我们可以创建一个数据种子库。 例如，我们可以创建一个库，该库在调用时可以使用应用程序自己的API自动将一组示例数据加载到我们的环境中。 使用我们自己的API播种数据将为我们提供示例数据，并作为确保正确API功能的测试。
From here, we can create a new stage in our environment vending machine pipeline that calls this library immediately after all the infrastructure has been built and deployed. Static data is loaded, then any and all tests can be run against the environment.
从这里，我们可以在环境自动售货机管道中创建一个新阶段，在所有基础架构都已构建和部署后立即调用该库。 加载静态数据后，即可针对环境运行所有测试。
无服务器售卖环境的好处 (Benefits of Serverless Vended Environments)
Utilizing this twofold approach of building optional namespacing capabilities into your Terraform project and automating the deployment via CI/CD tooling, we now have a streamlined, push button way to spin up isolated environments in a matter of minutes.
利用这种双重方法，在您的Terraform项目中构建可选的命名空间功能，并通过CI / CD工具自动进行部署，我们现在有了一种简化的按钮式方法，可以在几分钟内启动隔离的环境。
This will help enable developers in a number of ways:
这将以多种方式帮助开发人员：
- Quickly roll-out any number of environments needed for a smooth workflow 快速部署任何数量的环境，以实现平稳的工作流程
- Easily test code changes before deploying to shared environments 在部署到共享环境之前轻松测试代码更改
- Eliminate having to wait for the right moment to deploy and test code 消除了等待正确的时间来部署和测试代码的麻烦
- Always have a fresh environment to work in (avoid any data contamination or unwanted changes) 始终有一个全新的工作环境(避免任何数据污染或不必要的更改)
- Ensure all parts of application are tested in unison via data seeding (infrastructure, application code, test code, test data, etc.) 确保通过数据种子(基础架构，应用程序代码，测试代码，测试数据等)对应用程序的所有部分进行统一测试。
- Provide push button clean-up of old environments 提供旧环境的按钮清理
Feel free to ask any questions in the comments for specifics on how certain features were implemented!
随意在评论中提出任何问题，以获取有关特定功能实现方式的详细信息！
进一步阅读 (Further Reading)
AWS:
AWS：
Terraform:
地形：
https://www.terraform.io/docs/configuration-0-11/locals.html
https://www.terraform.io/docs/configuration-0-11/locals.html
Jenkins:
詹金斯：
翻译自: https://medium.com/slalom-build/serverless-environment-vending-machines-7302dc170b90
aws terraform
882
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
