Share
Embed
Transcript
29 slides
-
agenda • about me • goal • our infrastructure •
our management tools • our terraform apply flow • problem • OSS or Enterprise • sentinel • conclusion -
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 ◦ 仏像制作, 丸太収集, 写経, 寺社仏閣 -
goal • インフラ/構成管理のツール/サービス紹介 • Terraform(Enterprise)が何をするのかを理解する • Terraform OSS verとTerraformEnterpriseの違いを知る •
Enterprise版で利用できる機能の紹介 • まとめ -
our infrastructure • 某ゲームプラットフォームのバックエンド • AWSで構築 • Terraformで管理 ◦ リソース数:
1000+ ◦ HCLコード: 14000行程度 ◦ Planにかかる時間: 20分+ • Code化しているもの・していないもの ◦ していない ▪ EC2インスタンス ▪ DBインスタンス(Aurora, ElastiCache) • applyはせず、planだけ実行、本番とコードの差分が無いかをチェック ▪ Lambda, ApiGateway(Serverlessで管理) ◦ している ▪ 上記以外全て -
our management tools • terraform ◦ AWSリソースの本番適用 (apply) • itamae
/ ansible ◦ 特定のサーバー(EC2)に対してサーバー設定適用 • packer ◦ マシンイメージ(AMI)を作成 • serverless ◦ lambda, api-gateway, route53に対して関数単位で deploy • serverspec ◦ 特定のサーバー(EC2)に対してサーバー設定のテスト • awsspec ◦ AWSのリソースに対してのテスト -
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 -
our terraform apply flow • ブランチによる差異 ◦ master branch =>
plan & apply ◦ master以外 => only plan • backend ◦ S3 backend • Lock ◦ dynamodb • 誰が実行するか ◦ circleci -
problem • stateファイルの管理 (まれによく壊れる) ◦ ローカル ▪ stateファイルのバージョン管理が面倒 (個別にcommitするのは煩雑) ◦
リモート ▪ S3が別途必要 ▪ バージョン管理ができない • apply/planの同時実行時のリソースバッティング(排他処理の仕組みが必要) ◦ dynamodbのテーブルを使って排他処理 (Lock) • ロールバックが(簡単に)できない ◦ 心理的安全性が低い ◦ stateファイル自体が壊れるとサービス復旧までに著しく時間がかかる • Terraformのバージョンアップデートが大変 ◦ バージョンによってtfファイルに差異が発生したら・・・ -
team management • TFEのアカウント構造 ◦ Organization ▪ Team => チーム単位でメンバーをグルーピング
• Members ◦ Account • TFEのワークスペース構造 ◦ Organization ▪ Workspace • Teams => チーム単位でWorkspaceの操作権限を設定 ◦ Permission (Read/Plan/Write/Admin) -
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) -
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 -
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 ... -
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 -
conclusion • TerraformEnterpriseを導入してみました • OSS版では利用できない便利な機能の紹介をしました ◦ Team Management ◦ Remote
Run & State ▪ Terraformの外の仕組みでがんばっていたものを、 Terraformに集約できました(シンプルにな りました) ▪ ロールバックの敷居が下がりました (エンジニアの心理的安全性 ) ◦ Sentinel ▪ Policy As Code でテスト可能な、より「固い」インフラが構築できるようになりました • CI/Deploy(Apply)/権限管理など、属人性の高い作業をTFEに集約できるようにな りました