Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Terraform始めました

8.009 visualizaciones

Publicado el

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

Publicado en: Ingeniería
  • Sé el primero en comentar

Terraform始めました

  1. 1. Terraform始めました @w1mvy XFLAG™スタジオ
  2. 2. 自己紹介 2
  3. 3. 自己紹介 • 新卒4年目 • XFLAGスタジオサーバエンジニア • テラフォーマーズではミッシェルさん推し • 最近結婚しました 3
  4. 4. 4
  5. 5. Terraform 5
  6. 6. Terraform触ってる人ー? 6
  7. 7. 手を挙げた人数によっては この後やり辛い 7
  8. 8. 改めて 8
  9. 9. Terraform始めました 9
  10. 10. Terraformとは 10
  11. 11. Terraformとは • コードでのインフラリソースの定義、管理 • dry-run機能による、変更内容の確認 • コマンド適用による、人的ミスを減少 • AWS, GCP, DigitalOcean, Heroku, Azure に対 応 11
  12. 12. サンプル 12
  13. 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. 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. 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. 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. 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. 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. 簡単! 19
  20. 20. Terraform導入にいたる経緯 20
  21. 21. AWS Management Console • 愚直にポチポチする • ただポチポチする 21
  22. 22. 社内ツール • aws-cliのラッパー • yamlファイルを元にec2 instanceを生成する • Route53などはやはりManagementConsole 22
  23. 23. 不便… • Route53などセンシティブな箇所は二人体制 で確認しながら作業 • 履歴が残らないため、不要なリソースの判断 が難しい • ManagementConsoleでの操作ミスを無くし たい 23
  24. 24. そんなところに新規PJ 24
  25. 25. そうだTerraformだ 25
  26. 26. Terraformに決めた理由 • 先程の不便点を解決できる • AWS以外も扱える • プロダクト自体の活発さ 26
  27. 27. 構成&フロー 27
  28. 28. 差分 28
  29. 29. 差分 PullRequest hook 29
  30. 30. 差分 state file 30 PullRequest hook
  31. 31. 差分 plan state file 31 PullRequest hook
  32. 32. 差分 plan PullRequest merge hook state file 32 PullRequest hook
  33. 33. 差分 plan state file state file 33 PullRequest hook PullRequest merge hook
  34. 34. 差分 plan state file state file 34 PullRequest hook PullRequest merge hook
  35. 35. 差分 plan state file state file 35 PullRequest hook PullRequest merge hook
  36. 36. 差分 plan state file state file 36 PullRequest hook PullRequest merge hook
  37. 37. リポジトリ構成 37
  38. 38. 1.プロダクト用リポジトリ 38
  39. 39. プロダクト用リポジトリ • 環境毎のtfファイル(production.tf, staging.tf…) • 各環境のリソースなどの定義 • main.tf • 各環境で跨いで利用するリソース(Jenkinsなど)の定義など • variables.tf • key, secret, ami定義 39
  40. 40. 2.モジュール用リポジトリ 40
  41. 41. Terraform module 41
  42. 42. Terraform module • 再利用可能なコンポーネントの定義 • 例 ) • redis用に6379 port を許可する sg定義 • 80 portを受け入れるelb定義 • github.com/terraform-community-modules 42
  43. 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. 44. sampleモジュール利用 module "sample" { source = "./sample" } # もちろんgithub上のモジュール指定も可能 module "sg_web" { source = "github.com/terraform-community-modules/ tf_aws_sg//sg_web" } 44
  45. 45. terraform plan + module.sample 1 resource(s) Plan: 1 to add, 0 to change, 0 to destroy. 45
  46. 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. 47. モジュール用リポジトリ • sg • 社内httpアクセス用, github hook用 など • elb • http用, https用 など • これらをプロダクト用リポジトリにて利用 47
  48. 48. ハマった箇所 48
  49. 49. planコマンドの結果 • planは通るけどapplyが失敗する • 例: 同じ名前のsecurity groupを複数定義 • 実際には同じ名前のsgは定義できないためapply 時に失敗する • => プロバイダ側の細かい箇所は見てくれない 49
  50. 50. stateファイルの管理 • 手元でテストを行っており、それで作成され たstateファイルをremote pushしてしまった • 開発環境作り直し • 開発環境だけで済んだ • -> 実行はCIに任せる 50
  51. 51. moduleの更新 • module側を更新する度に、module利用箇所 が全て影響を受ける • この環境だけ先に適用したい • -> moduleを利用する際には “ref” を指定する 51
  52. 52. terraformのリソース名変更 • リソース名変更 = 破棄/作成 • 一度作成したリソース名の変更が難しい • tfstateファイルを直接書き換えれば対処可能 resource “TYPE” “NAME” { any_parameters } 52
  53. 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. 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. 55. Terraformを導入して よかったところ 55
  56. 56. Terraformを導入して • コードで記述できることによって、 PullRequest&Reviewのレールに乗れる • PullRequestによって、そのリソースの用途が 把握できる • 環境一式のリソース作成が簡単 56
  57. 57. 最後に 57
  58. 58. 皆様 探り探りテラフォーミング していきましょう!! 58

×