Upgrade to Pro — share decks privately, control downloads, hide ads and more …

僕と契約して、terraform少女になってよ(仮)

ohr486
December 17, 2018
2k

 僕と契約して、terraform少女になってよ(仮)

ohr486

December 17, 2018
Tweet

Transcript

  1. agenda • about me • goal • our infrastructure •

    our management tools • our terraform apply flow • problem • OSS or Enterprise • sentinel • conclusion
  2. about me • Tsunenori Ohara/おーはら ◦ Twitter: @ohrdev ◦ Github:

    ohr486 • Work ◦ enza事業本部 プラットフォーム開発部 部長 ◦ インフラ/基盤/アーキテクチャ設計 , HCL/SL/Ruby/Elixir/Golang • Community ◦ tokyo.ex, ElixirConfJapan, Erlang&ElisirFest, JEA ◦ meguro.rb, meguro.es • Hobby ◦ 仏像制作, 丸太収集, 写経, 寺社仏閣
  3. our infrastructure • 某ゲームプラットフォームのバックエンド • AWSで構築 • Terraformで管理 ◦ リソース数:

    1000+ ◦ HCLコード: 14000行程度 ◦ Planにかかる時間: 20分+ • Code化しているもの・していないもの ◦ していない ▪ EC2インスタンス ▪ DBインスタンス(Aurora, ElastiCache) • applyはせず、planだけ実行、本番とコードの差分が無いかをチェック ▪ Lambda, ApiGateway(Serverlessで管理) ◦ している ▪ 上記以外全て
  4. our management tools • terraform ◦ AWSリソースの本番適用 (apply) • itamae

    / ansible ◦ 特定のサーバー(EC2)に対してサーバー設定適用 • packer ◦ マシンイメージ(AMI)を作成 • serverless ◦ lambda, api-gateway, route53に対して関数単位で deploy • serverspec ◦ 特定のサーバー(EC2)に対してサーバー設定のテスト • awsspec ◦ AWSのリソースに対してのテスト
  5. AWS resources その他の AWS Resources our management tools EC2 instance

    Amazon Machine Image (ApiGateway) DNS Record Api Gateway Lambda terraform serverless itamae ansible packer serverspec awsspec app deploy
  6. our terraform apply flow • ブランチによる差異 ◦ master branch =>

    plan & apply ◦ master以外 => only plan • backend ◦ S3 backend • Lock ◦ dynamodb • 誰が実行するか ◦ circleci
  7. problem • stateファイルの管理 (まれによく壊れる) ◦ ローカル ▪ stateファイルのバージョン管理が面倒 (個別にcommitするのは煩雑) ◦

    リモート ▪ S3が別途必要 ▪ バージョン管理ができない • apply/planの同時実行時のリソースバッティング(排他処理の仕組みが必要) ◦ dynamodbのテーブルを使って排他処理 (Lock) • ロールバックが(簡単に)できない ◦ 心理的安全性が低い ◦ stateファイル自体が壊れるとサービス復旧までに著しく時間がかかる • Terraformのバージョンアップデートが大変 ◦ バージョンによってtfファイルに差異が発生したら・・・
  8. team management • TFEのアカウント構造 ◦ Organization ▪ Team => チーム単位でメンバーをグルーピング

    • Members ◦ Account • TFEのワークスペース構造 ◦ Organization ▪ Workspace • Teams => チーム単位でWorkspaceの操作権限を設定 ◦ Permission (Read/Plan/Write/Admin)
  9. remote runs & state • Terraformのstateファイル ◦ stateファイルをcloudで管理できる ▪ atlas

    backendで保存される ▪ AWSのS3 backendと異なりバージョン管理可能 • OSS版からEnterprise版へのMigration ◦ https://www.terraform.io/docs/enterprise/migrate/index.html • terraformバージョン ◦ どのterraformバージョンでplan/applyするか指定可能 ◦ 常に最新に保つ設定もある (auto version up)
  10. sentinel • アクセスポリシーを評価するF/W • Sentinel Languageという言語で記述する( Policy as Code )

    ◦ .sentinel という拡張子 • example) ◦ 特定のCIDRブロックからのアクセスを制限する ▪ https://github.com/hashicorp/terraform-guides/blob/master/governance/aws/restrict-aws- cidr-blocks.sentinel ◦ 特定のタグをリソースに必須でつける ▪ https://github.com/hashicorp/terraform-guides/blob/master/governance/aws/enforce-man datory-tags.sentinel ◦ etc
  11. ex) その他、sentinelでできること • Amazon Web Services ◦ Enforce owner allow

    list on aws_ami data source ◦ Enforce mandatory tags on instances ◦ Restrict availability zones ◦ Disallow CIDR blocks ◦ Restrict the type of instance to be provisioned ◦ Require VPCs to be tagged and have DNS hostnames enabled • Microsoft Azure ◦ Restrict VM images ◦ Restrict the type of VM to be provisioned ◦ Enforce limits on an ACS cluster ◦ Enforce limits on an AKS cluster • Google Cloud Platform ◦ Disallow CIDR blocks ◦ Enforce limits on a GKE cluster ◦ Restrict the type of machine to be provisioned • VMware ◦ Require Storage DRS to be enabled ◦ Restrict virtual disk size and type ◦ Restrict VM CPU count and memory ◦ Enforce NFS 4.1 and Kerberos • etc ...
  12. sentinel • 開発/テスト用にCLIシミュレーターが提供される ◦ https://docs.hashicorp.com/sentinel/downloads • CLI ◦ sentinel apply

    ▪ ローカル環境でpolicyを適用 ◦ sentinel doc ▪ importしたplugin情報を表示 ◦ sentinel fmt ▪ .sentinelコードを整形(フォーマッタ) ◦ sentinel test ▪ test policyを実行 ▪ https://docs.hashicorp.com/sentinel/writing/testing
  13. conclusion • TerraformEnterpriseを導入してみました • OSS版では利用できない便利な機能の紹介をしました ◦ Team Management ◦ Remote

    Run & State ▪ Terraformの外の仕組みでがんばっていたものを、 Terraformに集約できました(シンプルにな りました) ▪ ロールバックの敷居が下がりました (エンジニアの心理的安全性 ) ◦ Sentinel ▪ Policy As Code でテスト可能な、より「固い」インフラが構築できるようになりました • CI/Deploy(Apply)/権限管理など、属人性の高い作業をTFEに集約できるようにな りました