先週LTした時の資料です

1. 実環境に
Terraform導入したら
驚いた
サイバーエージェント 桑野 章弘

2. 自己紹介

3. 自己紹介
• 桑野 章弘
• あだな：銀河
• 渋谷の道玄坂の上の方の緑の会社勤め
• 何やってる人？

4. 自己紹介
• 何やってるの？
• あんなサービスや、こんなサービスのサーバ
構築したり、ミドルウェアやデータベース面
倒みたり、監視入れたり
• いわゆるインフラエンジニア？

5. 自己紹介
• MongoDBアイドル…

6. まだ来ません

7. Terraform

8. Terraformとは
• Hashicorp社製のプロダクト

9. Terraformとは
• Hashicorp社製のプロダクト
• サーバ構成をバージョン管理
• サーバ構築のコード化
• 主要なIaaS系のプロバイダ対応

10. 使用例

11. VPC 構築
•
# VPC for staging
resource "aws_vpc" "staging" {
cidr_block = 10.0.0.0/24
tags {
Name = "staging"
}
}

12. VPC 構築
• # Public subnets for staging
!
resource "aws_subnet" "staging_public" {
vpc_id = "${aws_vpc.staging.id}"
cidr_block = 10.0.0.0/25
availability_zone = "${var.aws.availability_zone}"
map_public_ip_on_launch = "1"
tags {
Name = "staging_public"
}
}

13. VPC Peering
# VPC Peering
resource "aws_vpc_peering_connection"
"staging_vpc_peering" {
peer_owner_id = "${var.peer_owner_id}"
peer_vpc_id = "${aws_vpc.staging.id}"
vpc_id = ${aws_vpc.other_vpc.id}"
}
ただし
Activateは
マネジメントコンソー
ルから

14. EC2 instance作成
• resource "aws_instance" staging-redis" {
count = 1
ami = "${var.amis.centos}"
instance_type = "t2.micro"
key_name = "${var.aws.key_name}"
subnet_id = "${aws_subnet.staging_private.id}"
security_groups = [
"${aws_security_group.sg_staging_default.id}",
"${aws_security_group.sg_staging_redis-slave.id}"
]
tags {
Name = "staging-redis-${count.index}"
Service = terraform-test
}
}

15. Route53 レコード作成
•
resource "aws_route53_record" "staging-redis-private" {
zone_id = ${var.route53_zones.example.com}"
name = staging-redis$
{count.index}.in.dev.example.com"
count = "1"
type = "A"
ttl = "300"
records = [ "${element(aws_instance.staging-
redis.*.private_ip, count.index)}" ]
}

16. 実行方法
• plan で変更内容の確認
$ terraform plan --refresh=false
（省略）
!
+ aws_instance.stg-redis.1
ami: "" => "ami-88564a89"
availability_zone: "" => "<computed>"
ebs_block_device.#: "" => "<computed>"
ephemeral_block_device.#: "" => "<computed>"
instance_type: "" => "t2.micro"
key_name: "" => "entm-dev"
private_dns: "" => "<computed>"
private_ip: "" => "<computed>"
public_dns: "" => "<computed>"
public_ip: "" => "<computed>"
root_block_device.#: "" => "<computed>"
security_groups.#: "" => "2"
security_groups.3873480020: "" => "sg-22362c15"
security_groups.3945627619: "" => "sg-22312345"
subnet_id: "" => "subnet-1234c80e"
tags.#: "" => "2"
tags.Name: "" => "staging-redis-1"
tags.Service: "" => "staging"
tenancy: "" => "<computed>"

17. 実行方法
• applyで反映
$ terraform apply
（省略）

18. なしてつかっ
たの？

19. 新規案件時
• 「AWSの構成管理どうする？」
「CloudFormation？Ansible？Terraform？」
「新規だしTerraformいっちゃいますかねえ」
「いっちゃうかー」

20. 軽い気持ち
(・A・)ｲｸﾅｲ!!

21. 軽い気持ち
(・A・)ｲｸﾅｲ!!
一応まじめに決めま
した:(；ﾞﾟ ωﾟ'):

22. 選定理由
• クラウド構成の履歴管理をバージョン管理シ
ステムベースでできる
• PullRequestベースでの作業分担、プロセス管
理

23. が、魅力的
でした

24. 良かった点

25. PRベースの構築分担
• 各人がFeatureブランチ切ってそれをDevelop
ブランチでコードレビューしてからApplyって
いうのができる
• 複数の人で開発してても誰が何やったか後で
追える！( ・ ・)ｲｲ!!

26. チームでのPRベースの構築例
master
devel
feature
terraform
apply
PR
PR
terraform plan
&
コードレビュー

27. 厳しい点

28. tfstate共有問題
• 変更内容はterraform.tfstateに入っていてplan時などはコード
の変更内容をつけ合わせている
• 各個人の環境でtfstateの情報は同一になっていないといけな
い
• Terraform実行はローカル環境でやらない(jenkins等のCIツー
ルや、スクリプト経由で行う)
• tfstateはconsulに保存できるのでそれで共有する

29. planがあんまり信用出来ない
• terraform planで変更内容確認してterraform
applyで反映でした
• planでエラーでなくてもapplyで実行時にエ
ラー出る時がある
• 辛い、というか恐怖がある

30. バージョンアップ問題
• ものすごく開発が活発
• でもまだ実装されてない機能も多い
• バージョンアップに細かく追従していかないと辛い
• この2ヶ月くらいで、0.3.7->0.3.8->0.4.0->0.4.1と上
げ続けている
• 三途の河感

31. バージョンアップ問題
• 後、機能がまだ未実装のが結構あってこれがほしいいい
いいいんだけどなああああああああああああっていうの
が次のバージョンだったりする時も（でもホント開発速
い）
• VPC Peering(0.3.8)
• countのsprintf対応(0.4.0)
• optimized iops ssd対応(0.4.0)

32. バージョンアップ問題
• 後、機能がまだ未実装のが結構あってこれがほしい
いいいいいんだけどなああああああああああああっ
ていうのが次のバージョンだったりする時が多い
• VPC Peering(0.3.8)
• countのsprintf対応(0.4.0)
• optimized iops ssd対応(0.4.0)
https://github.com/
hashicorp/terraform/
issues/28

33. まとめ

34. まとめ
• Terraform結構チームでの構築とか履歴管理に
非常にいいと思うんですが、色々つらみも有
る
• 追従しつつ頑張っていくつもりですがもしや
めてたらごめんなさい:(；ﾞﾟ’ωﾟ'):

35. つかってる方
情報交換
しましょう