Embed Size (px)
Citation preview
実環境に Terraform導入したら驚いたサイバーエージェント 桑野 章弘
自己紹介
自己紹介
• 桑野 章弘
• あだな：銀河
• 渋谷の道玄坂の上の方の緑の会社勤め
• 何やってる人？
自己紹介
• 何やってるの？
• あんなサービスや、こんなサービスのサーバ構築したり、ミドルウェアやデータベース面倒みたり、監視入れたり
• いわゆるインフラエンジニア？
自己紹介
• MongoDBアイドル…
まだ来ません
Terraform
Terraformとは
• Hashicorp社製のプロダクト
Terraformとは
• Hashicorp社製のプロダクト
• サーバ構成をバージョン管理
• サーバ構築のコード化
• 主要なIaaS系のプロバイダ対応
使用例
VPC 構築
•
# VPC for staging resource "aws_vpc" "staging" { cidr_block = “10.0.0.0/24” tags { Name = "staging" } }
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" } }
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は
マネジメントコンソールから
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“ } }
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)}" ] }
実行方法
• 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>"
実行方法
• applyで反映
$ terraform apply （省略）
なしてつかったの？
新規案件時
• 「AWSの構成管理どうする？」「CloudFormation？Ansible？Terraform？」
「新規だしTerraformいっちゃいますかねえ」
「いっちゃうかー」
軽い気持ち (・A・)ｲｸﾅｲ!!
軽い気持ち (・A・)ｲｸﾅｲ!!
一応まじめに決めました:(；ﾞﾟ’ωﾟ'):
選定理由
• クラウド構成の履歴管理をバージョン管理システムベースでできる
• PullRequestベースでの作業分担、プロセス管理
が、魅力的 でした
良かった点
PRベースの構築分担
• 各人がFeatureブランチ切ってそれをDevelop
ブランチでコードレビューしてからApplyっていうのができる
• 複数の人で開発してても誰が何やったか後で追える！( ・∀・)ｲｲ!!
チームでのPRベースの構築例
master
devel
feature
terraform apply
PR
PR
terraform plan&
コードレビュー
厳しい点
tfstate共有問題
• 変更内容はterraform.tfstateに入っていてplan時などはコードの変更内容をつけ合わせている
• 各個人の環境でtfstateの情報は同一になっていないといけない
• Terraform実行はローカル環境でやらない(jenkins等のCIツールや、スクリプト経由で行う)
• tfstateはconsulに保存できるのでそれで共有する
planがあんまり信用出来ない
• terraform planで変更内容確認してterraform
applyで反映でした
• planでエラーでなくてもapplyで実行時にエラー出る時がある
• 辛い、というか恐怖がある
バージョンアップ問題
• ものすごく開発が活発
• でもまだ実装されてない機能も多い
• バージョンアップに細かく追従していかないと辛い
• この2ヶ月くらいで、0.3.7->0.3.8->0.4.0->0.4.1と上げ続けている
• 三途の河感
バージョンアップ問題
• 後、機能がまだ未実装のが結構あってこれがほしいいいいいいんだけどなああああああああああああっていうのが次のバージョンだったりする時も（でもホント開発速い）
• VPC Peering(0.3.8)
• countのsprintf対応(0.4.0)
• optimized iops ssd対応(0.4.0)
バージョンアップ問題
• 後、機能がまだ未実装のが結構あってこれがほしいいいいいいんだけどなああああああああああああっていうのが次のバージョンだったりする時が多い
• VPC Peering(0.3.8)
• countのsprintf対応(0.4.0)
• optimized iops ssd対応(0.4.0)
https://github.com/hashicorp/terraform/
issues/28
まとめ
まとめ
• Terraform結構チームでの構築とか履歴管理に非常にいいと思うんですが、色々つらみも有る
• 追従しつつ頑張っていくつもりですがもしやめてたらごめんなさい:(；ﾞﾟ’ωﾟ'):
つかってる方 情報交換 しましょう
