XFLAG(TM)スタジオの開発の裏側を公開！engineer meet up(http://mixi.connpass.com/event/25593/) での発表資料です

1. Terraform始めました
@w1mvy
XFLAG™スタジオ

2. 自己紹介
2

3. 自己紹介
• 新卒4年目
• XFLAGスタジオサーバエンジニア
• テラフォーマーズではミッシェルさん推し
• 最近結婚しました
3

4. 4

5. Terraform
5

6. Terraform触ってる人ー？
6

7. 手を挙げた人数によっては
この後やり辛い
7

8. 改めて
8

9. Terraform始めました
9

10. Terraformとは
10

11. Terraformとは
• コードでのインフラリソースの定義、管理
• dry-run機能による、変更内容の確認
• コマンド適用による、人的ミスを減少
• AWS, GCP, DigitalOcean, Heroku, Azure に対
応
11

12. サンプル
12

13. sample.tf
provider "aws" {
access_key = “access_key”
secret_key = “secret_key”
region = “ap-northeast-1“
}
resource "aws_instance" "sample" {
ami = "ami-a31f27cd"
instance_type = "t1.micro"
tags {
Name = "sample"
}
}
13

14. terraform plan
+ aws_instance.sample
ami: "" => "ami-a31f27cd"
availability_zone: "" => "<computed>"
ebs_block_device.#: "" => "<computed>"
ephemeral_block_device.#: "" => "<computed>"
instance_type: "" => "t2.micro"
key_name: "" => "<computed>"
placement_group: "" => "<computed>"
private_dns: "" => "<computed>"
private_ip: "" => "<computed>"
public_dns: "" => "<computed>"
public_ip: "" => "<computed>"
root_block_device.#: "" => "<computed>"
security_groups.#: "" => "<computed>"
source_dest_check: "" => "1"
subnet_id: "" => "<computed>"
tags.#: "" => "1"
tags.Name: "" => "sample"
tenancy: "" => "<computed>"
vpc_security_group_ids.#: "" => "<computed>"
Plan: 1 to add, 0 to change, 0 to destroy.
14

15. terraform apply
aws_instance.sample: Creating...
ami: "" => "ami-a31f27cd"
availability_zone: "" => "<computed>"
ebs_block_device.#: "" => "<computed>"
ephemeral_block_device.#: "" => "<computed>"
instance_type: "" => "t2.micro"
key_name: "" => "<computed>"
placement_group: "" => "<computed>"
private_dns: "" => "<computed>"
private_ip: "" => "<computed>"
public_dns: "" => "<computed>"
public_ip: "" => "<computed>"
root_block_device.#: "" => "<computed>"
security_groups.#: "" => "<computed>"
source_dest_check: "" => "1"
subnet_id: "" => "<computed>"
tags.#: "" => "1"
tags.Name: "" => "sample"
tenancy: "" => "<computed>"
vpc_security_group_ids.#: "" => "<computed>"
aws_instance.sample: Creation complete
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
15

16. terraform.tfstate
{
"version": 1,
"serial": 1,
"modules": [
{
"path": [
"root"
],
"outputs": {},
"resources": {
"aws_instance.sample": {
"type": "aws_instance",
"primary": {
"id": "i-69e4cecc",
"attributes": {
"ami": "ami-a31f27cd",
"availability_zone": "ap-northeast-1a",
….略…..
"private_ip": "172.31.21.24",
"tags.Name": "sample"
},
"meta": {
"schema_version": "1"
}
}
}
}
}
]
}
16

17. terraform plan -destroy
• f
Refreshing Terraform state prior to plan...
aws_instance.sample: Refreshing state... (ID: i-69e4cecc)
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed.
Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.
- aws_instance.sample
Plan: 0 to add, 0 to change, 1 to destroy.
17

18. terraform destroy
Do you really want to destroy?
Terraform will delete all your managed infrastructure.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value: yes
aws_instance.sample: Refreshing state... (ID: i-69e4cecc)
aws_instance.sample: Destroying...
aws_instance.sample: Destruction complete
Apply complete! Resources: 0 added, 0 changed, 1 destroyed.
18

19. 簡単！
19

20. Terraform導入にいたる経緯
20

21. AWS Management Console
• 愚直にポチポチする
• ただポチポチする
21

22. 社内ツール
• aws-cliのラッパー
• yamlファイルを元にec2 instanceを生成する
• Route53などはやはりManagementConsole
22

23. 不便…
• Route53などセンシティブな箇所は二人体制
で確認しながら作業
• 履歴が残らないため、不要なリソースの判断
が難しい
• ManagementConsoleでの操作ミスを無くし
たい
23

24. そんなところに新規PJ
24

25. そうだTerraformだ
25

26. Terraformに決めた理由
• 先程の不便点を解決できる
• AWS以外も扱える
• プロダクト自体の活発さ
26

27. 構成&フロー
27

28. 差分
28

29. 差分
PullRequest
hook
29

30. 差分
state file
30
PullRequest
hook

31. 差分
plan
state file
31
PullRequest
hook

32. 差分
plan
PullRequest
merge hook
state file
32
PullRequest
hook

33. 差分
plan
state file
state file
33
PullRequest
hook
PullRequest
merge hook

34. 差分
plan
state file
state file
34
PullRequest
hook
PullRequest
merge hook

35. 差分
plan
state file
state file
35
PullRequest
hook
PullRequest
merge hook

36. 差分
plan
state file
state file
36
PullRequest
hook
PullRequest
merge hook

37. リポジトリ構成
37

38. 1.プロダクト用リポジトリ
38

39. プロダクト用リポジトリ
• 環境毎のtfファイル(production.tf, staging.tf…)
• 各環境のリソースなどの定義
• main.tf
• 各環境で跨いで利用するリソース(Jenkinsなど)の定義など
• variables.tf
• key, secret, ami定義
39

40. 2.モジュール用リポジトリ
40

41. Terraform module
41

42. Terraform module
• 再利用可能なコンポーネントの定義
• 例 )
• redis用に6379 port を許可する sg定義
• 80 portを受け入れるelb定義
• github.com/terraform-community-modules
42

43. sampleモジュール作成
.
└── sample
└── main.tf
#main.tf
provider "aws" {
region = “ap-northeast-1“
}
resource "aws_instance" "sample" {
ami = "ami-a31f27cd"
instance_type = "t1.micro"
tags {
Name = "sample"
}
}
43

44. sampleモジュール利用
module "sample" {
source = "./sample"
}
# もちろんgithub上のモジュール指定も可能
module "sg_web" {
source = "github.com/terraform-community-modules/
tf_aws_sg//sg_web"
}
44

45. terraform plan
+ module.sample
1 resource(s)
Plan: 1 to add, 0 to change, 0 to destroy.
45

46. terraform plan -module-depth=1
+ module.sample.aws_instance.sample
ami: "" => "ami-a31f27cd"
availability_zone: "" => "<computed>"
ebs_block_device.#: "" => "<computed>"
ephemeral_block_device.#: "" => "<computed>"
instance_type: "" => "t1.micro"
key_name: "" => "<computed>"
placement_group: "" => "<computed>"
private_dns: "" => "<computed>"
private_ip: "" => "<computed>"
public_dns: "" => "<computed>"
public_ip: "" => "<computed>"
root_block_device.#: "" => "<computed>"
security_groups.#: "" => "<computed>"
source_dest_check: "" => "1"
subnet_id: "" => "<computed>"
tags.#: "" => "1"
tags.Name: "" => "sample"
tenancy: "" => "<computed>"
vpc_security_group_ids.#: "" => "<computed>"
Plan: 1 to add, 0 to change, 0 to destroy.
46

47. モジュール用リポジトリ
• sg
• 社内httpアクセス用, github hook用 など
• elb
• http用, https用 など
• これらをプロダクト用リポジトリにて利用
47

48. ハマった箇所
48

49. planコマンドの結果
• planは通るけどapplyが失敗する
• 例: 同じ名前のsecurity groupを複数定義
• 実際には同じ名前のsgは定義できないためapply
時に失敗する
• => プロバイダ側の細かい箇所は見てくれない
49

50. stateファイルの管理
• 手元でテストを行っており、それで作成され
たstateファイルをremote pushしてしまった
• 開発環境作り直し
• 開発環境だけで済んだ
• -> 実行はCIに任せる
50

51. moduleの更新
• module側を更新する度に、module利用箇所
が全て影響を受ける
• この環境だけ先に適用したい
• -> moduleを利用する際には “ref” を指定する
51

52. terraformのリソース名変更
• リソース名変更 = 破棄/作成
• 一度作成したリソース名の変更が難しい
• tfstateファイルを直接書き換えれば対処可能
resource “TYPE” “NAME” {
any_parameters
}
52

53. 増えるamiの定義
• 作りなおす度に増えるami定義
• 古いのも使ってるし消せない
variable base_ami {
description = "EC2 instance base AMI"
default = "ami-1"
}
variable base_ami_2 {
description = "EC2 instance base AMI, created 2015-11-05"
default = "ami-2"
}
variable base_ami_3 {
description = "EC2 instance base AMI, created 2015-12-07"
default = "ami-3"
}
…. 53

54. 増えるamiの定義
• 現状。まだマシ、という程度
variable base_amis {
description = "EC2 instance base AMIs"
default = {
version_1 = "ami-version1"
version_2 = "ami-version2"
version_3 = "ami-version3"
version_4 = “ami-version4"
…
}
}
54

55. Terraformを導入して
よかったところ
55

56. Terraformを導入して
• コードで記述できることによって、
PullRequest&Reviewのレールに乗れる
• PullRequestによって、そのリソースの用途が
把握できる
• 環境一式のリソース作成が簡単
56

57. 最後に
57

58. 皆様
探り探りテラフォーミング
していきましょう！！
58