新米SRE的Terraform之旅─踏出的第一步

eyecatch_2107TerraformForSREBeginner-or8.png

※这篇文章是Tech Inside Drecom上发表的一篇名为”用于新人SRE的Terraform~第一步~”的文章的Qiita版本。


你好!很高兴认识你。
我是Doricon的SRE部门的sasa。我是一名新社会人。在Doricon,我们使用名为Terraform的工具来管理AWS的资源。
Terraform是一种可以通过代码描述基础架构配置的工具,对于通过DevOps进行开发的效率提升非常有帮助。
本文将介绍使用Terraform在AWS上进行基础架构设计的要点,以及具体的使用方法,并附带示例代码来进行说明。

目录

    • 対象読者&記事の目的

 

    • Terraformとは?

 

    • Terraformの機能: Workspaceとは?

環境を分ける意義

Workspaceの活用方法

common
system
$env
そのほかの環境を分ける方法

ドリコム式Workspaceのメリット

デメリット

設計のポイント
TerraformのCI
Workspace実用サンプル
最後に

目标读者和文章的目的

    • AWSを感覚で触ったことがある人

 

    • Terraformを試しに触ったことがあるけど、まだちゃんとは使ってない人

 

    Terraformと聞いて「火星・ゴキブリ」のキーワードしか思い浮かばない人

不关系的,但我希望称呼使用Terraform的人为Terraformer。
阅读完这篇文章后,你会变成这样。

    • Workspaceの使い方が分かる

 

    • Terraformでworkspaceを使ったAWSリソースの管理ができる

 

    IaC(Infrastructure as Code)による効率的なインフラ運用が実践できる

Terraform是什么?

1-terraform.png

改善后,Terraform是由HashiCorp开发的自动化基础架构建设工具。通过在代码中进行资源更改,可以减少在管理界面上的手动操作,解放您从操作错误和繁琐的界面点击中。当然,Terraform几乎支持所有著名的云服务,包括AWS、GCP和Azure。

可利用的服务列表

另外,Terraform v1.0于2021年6月8日发布。未来将能够实现更稳定的运营。

Terraform的功能:工作区是什么?

您可以将多个基础设施环境分割为工作区进行管理。
工作区的特点是,多个工作区共享一份源代码。
有关详细信息,请参阅后面的设计要点说明,
使用工作区可以轻松构建新环境。

分割环境的重要性

通过创建像生产环境和预备环境等不同的环境,即使在非生产环境中修改资源,也不会对生产环境产生影响(非常重要)。因此,我们工程师可以放心地进行工作,并成为向商业方面提供说服材料的依据。

2-workspace.png

工作空间的使用方法

在ドリコム中,我们通常使用至少三个工作空间。
它们是common、system和$env。
如果需要的话,可以扩展$env,并增加production、staging、dev1等环境。
当要构建新的环境时,只需创建一个工作空间,非常简单。

$ terraform workspace new dev1      # workspace「dev1」を作成 
$ terraform workspace select dev1   # 現在のworkspaceを「dev1」に切り替え

整体上看起来就像下图所示的感觉。因为有很多不同的东西,所以在这里只需要浏览一下就可以了。
我们将从基础资源common开始创建。

3-workspace.png

通常的

在common中,主要是将全局区域的资源汇集到一个工作空间中,作为首次执行的内容。
例如:ACM、IAM、S3(lambda bucket)。

4-common.png

系统

系统是按地区进行资源划分,并在$env中汇集共享资源的工作空间。
它是在common之后执行的。
例如:S3(日志)、ECR、CloudWatch、Lambda(用于监控)。

5-system.png

环境

$env是一个聚集了应用程序所使用的资源的工作区。
例如:VPC、ALB、ECS、AutoScaling、RDS、ElastiCache

6-env.png

将其他环境予以区分的方法

除了工作区之外,还有一种分隔环境的方法是使用模块(将资源模板化的功能),为每个环境的目录准备模块,并复制调用模块的代码以进行调整。

Dorikomu式Workspace的好处

通过分割工作空间,可以在共享代码的同时生成独立的环境(tfstate文件)。

通过使用Workspace,您可以轻松地通过编辑简单的命令和配置文件来创建用于应用程序的AWS环境,包括生产、暂存和开发1、开发2等。

另外,通过区分通用、系统和生产环境,可以缩短每次应用执行的时间,并将影响风险分散。

此外,通过将环境进行分离,可以更好地创建资源,也能避免在IAM资源创建后立即创建资源的失败。在Drecom中,我们需要创建多个环境来进行开发,包括生产环境、分段环境、负载测试环境、开发环境1、开发环境2等,因此我们采用了这种可以在每个环境中共享代码而无需复制文件的方法。

7-drecom.png

缺點

如果有优点,当然也会有缺点。
使用本次Workspace的方法是通过使用count来对资源进行环境分割,这会导致整体视野不清晰。
此外,为了传递相关资源的值给不同的工作区,还需要编写output,这可能会使得代码变得杂乱无章。

设计的重点

您只需编辑variables.tf文件即可进行基本设置。
此外,通过编辑*_variables.tf文件,您还可以切换资源的启用和禁用,使系统可以超出基本设置。

8-con.png

我们使用count参数来控制根据不同环境创建资源的方式。让我们看个例子。

以下是应用程序运行器的IAM角色资源的代码示例。
根据三元运算符,如count = local.on_common ? 1 : 0,如果为True,则设置为1(ON),如果为False,则设置为0(OFF)。
请注意,local.on_common是在variables.tf文件中定义的。

terraform-onboarding/variables.tf

resource "aws_iam_role" "apprunner" {
     count = local.on_common ? 1 : 0 # リソースの作成制御
     name = format("%s-%s", local.service_name, "apprunner")
     assume_role_policy = <<EOF
 {
   "Version": "2012-10-17",
   "Statement": [
     {
       "Action": "sts:AssumeRole",
       "Principal": {
         "Service": [
           "build.apprunner.amazonaws.com",
           "tasks.apprunner.amazonaws.com"
         ]
       },
       "Effect": "Allow",
       "Sid": ""
     }
   ]
 }
 EOF
 }

在variables.tf文件中,变量的编写如下所示。

terraform-onboarding/variables.tf

locals {
   env        = terraform.workspace
   on_common  = local.env == "common" ? true : false
   on_system  = local.env == "system" ? true : false
   on_service = local.env != "common" && local.env != "system" ? true : false
 }

如果只想针对特定的 $env 进行特殊处理,则需要添加 on_$env。
例如:当只想创建生产环境的部署管道时。

terraform-onboarding/variables.tf

locals {
   env        = terraform.workspace
   on_common  = local.env == "common" ? true : false
   on_system  = local.env == "system" ? true : false
   on_service = local.env != "common" && local.env != "system" ? true : false
   on_production = local.env == "production" ? true : false # 必要に応じて追加していく
 }

土地形态的持续改进。

(Note: This translation assumes “Terraform” refers to the software, and “CI” refers to continuous improvement.)

在ドリコム中,只需将代码push到GitLab的master以外的分支,GitLab Runner就会在其上执行$ terraform plan,并在合并到master分支后执行$ terraform apply。
通过apply所做的tfstate文件更改会自动更新到master分支上。

这次的示例代码中没有涉及Gitlab CI,但是配置如下图所示。

9-ci.png

现在只需要操作图中的蓝线部分(①、③、⑤),非常方便。

    1. 在本地分支上预先创建一个名为common的分支并切换到该分支,然后使用$terraform plan检查是否有错误,之后进行git push。

 

    1. 一旦推送到gitlab,docker将在gitlab runner上启动,并执行$terraform init、$terraform get、$terraform plan,并将结果通知到公司内部的聊天应用程序。

 

    1. 一旦gitlab的计划作业成功,将向master分支提交合并请求。

 

    1. 一旦合并到master分支,将在gitlab runner上执行$terraform init、$terraform get、$terraform apply,并将结果通知到聊天应用程序。

 

    1. 此外,执行apply会更新tfstate文件,因此将更改内容应用到master分支。

 

    1. 拉取更新后的master分支到本地,并继续下一个循环。

 

    如果在过程中发生错误,则拉取后修复代码,再次进行push并提交合并请求。

工作空间实用样本

那么,我们来看一下这次准备的Workspace使用例子的样本。

土壤建模入门示例代码

在这个示例中,我们将使用Lambda和App Runner服务来构建一个简单的hello world系统。

以下是AWS的结构示意图。为了方便新手SRE员工,我们尽可能地简化了内容,并且可以使用最新的AWS功能(App Runner在2021年5月发布)。如果您拥有AWS帐户,请务必在您的环境中进行尝试!

10-sample.png

README中提供了执行步骤。

由于详细的步骤在README中,所以在这里只介绍体验的流程。

1. 建立共通资源
2. 建立系统资源
3. 使用curl进行Lambda的操作验证
4. 建立生产环境资源
5. 在浏览器中验证App runner的操作
6. 清理各个环境

最后的清理别忘了!如果觉得”以后再做吧”的话可能会吃亏。(痛感自戒)

最后

(complexity of translation depends on the context and purpose)

到目前为止,我们已经介绍了在Dorikom中使用Terraform的方法。
在Terraform中,有多种环境分隔的方法,每种方法都有其优点和缺点。关于环境分隔的方法,可以参考这篇Future技术博客。
关于Terraform的最佳实践,我们应该如何定义呢?

无论采用哪种方法,都有各自的优劣。但正如提到的在Dorikomu式工作空间中的优点,只需一次应用就能节省时间,而且只需通过创建新的工作空间和编辑配置文件就能轻松添加环境,这两点使得工作空间的优势显著。

还有,我们准备了一个使用Terraform在AWS上进行环境构建的示例代码,可以让您亲身体验。但是,对于那些希望使用更多AWS资源进行学习的人来说,我推荐一本名为《实践Terraform》的书籍。我们将把《实践Terraform》重新出版为商业书籍《Pragmatic Terraform on AWS》。

希望能为新手SRE、初次引入Terraform的人、在Terraform运营方面感到困惑的人以及对IaC有兴趣的人提供参考。

那么,再见


德良公司的最新信息将通过Facebook和Twitter传递,请大家关注我们!

    • Twitter: @DRECOM_TECH

Facebook: tech.inside.drecom


请点击此处查找Drecom Tech Inside的其他文章!

广告
将在 10 秒后关闭
bannerAds