IaCジャーニーの紹介

Transcript

1. IaCジャーニーマップの紹介
 2023年12月15日
 クラスメソッド AWS事業本部 佐藤 雅樹
 1
2. resource “my_profile” “this” { name = “佐藤雅樹” company = “クラスメソッド株式会社” department = “ソリューションアーキテクト” Interest = [ “CI/CD”, “IaC” ] } 2 自己紹介 2
3. 3 本セッションの対象聴講者、ゴール • 対象者
 ◦ IaCの導入を検討している方
 ◦ IaCをすでに適用していて、課題に向き合っている方
 • ゴール
 ◦ 組織のIaC利用の成熟度を上げるために、必要なステップがわ かる

4. 4 IaCジャーニーマップとは クラスメソッド作成の「IaCを導入させるためのステージ分けさ れた、ロードマップ」
5. 5 ペルソナ • Webシステムを運営している事業会社
 ◦ システムはAWS上で稼働
 • インフラチームは3名
 ◦ IaCの経験者は無し、プログラミング経験も無し
 • インフラの設定変更は手動で行なっている

6. 6 課題 • インフラ規模は拡大していて、以下のような課題がある
 ◦ インフラ構築や変更のリードタイムが長い
 ◦ 手動変更によって作業ミスが発生してしまった

7. 7 IaCジャーニーマップ ここからスタート
8. 8 Stage.2 IaC導入 ToDo • ツール選定(IaCツール、VCS)
 • 実行環境の整備(ローカル/リモート)
 • 既存リソースのImport
 • 各種フローの整備
 • ツールのチーム内への普及
 • ...etc
 
 ※太字部分を解説

9. 9 Stage.2 IaC導入 ツール選定 • IaCツール: Terraform
 ◦ ツールの学習コストを抑えたい
 ◦ AWS以外にも将来的に、別クラウドやSaaSも管理したい
 • VCS: GitLab
 ◦ アプリケーションチームがGitLabを使っていた

10. 10 Stage.2 IaC導入 実行環境 • ローカル
 ◦ リモート環境用のサーバーを維持したくない
 ◦ tfenvでTerraformバージョンを合わせる運用とする
 ◦ ローカルにAWS認証情報が必要だが、一旦許容する

11. 11 Stage.2 IaC導入 構成図
12. 12 Stage.2 IaC導入 振り返り ✅ 解決できたこと
 ◦ IaCコードを再利用することで、リードタイム短縮
 ◦ コード化したことで、変更履歴がGitで確認できるように
 ◦ レビューがしやすくなり、作業ミス減少・品質向上
 ❌ 課題
 ◦ ローカルのAWS認証情報を使って、承認(レビュー)なしで、イン フラを変更できてしまう
 ◦ コマンドの手動実行ミス
 

13. 13 Stage.3 デプロイパイプライン ToDo • デプロイパイプラインツールの選定
 • デプロイフローの整備
 • デプロイ方法の切り替え
 • ...etc
 
 ※太字部分を解説
 
 
 

14. 14 Stage.3 デプロイパイプライン ツール選定
15. 15 Terraform Cloud
16. Pros - Terraformのデプロイに最適化されている - 少ない工数でデプロイパイプラインを構築可能 - ツール用のインフラの構築・運用が不要 - Stateファイルの管理機能等、その他機能も充実 - HashiCorp社のサポートを受けれる Cons - デフォルト設定では、VCS上でPlan等の実行結果が見れな い - その他の方法より料金が高い Terraform Cloud 16
17. 17 CIツール(Github Actions, GitLab CI/CD)
18. 18 Pros - アプリケーションのデプロイとツールを統一できる - ツール用のインフラの構築・運用が不要(SaaS製品の場合) Cons - パイプライン処理の作り込みが必要 - (Terraform CloudやAtlantisと比較して) - 環境の数が増えるとデプロイ設定用のファイルが増えて管 理が大変 CIツール(Github Actions, GitLab CI/CD)
19. 19 Stage.3 デプロイパイプライン ツール選定
 • Terraform Cloud
 ◦ パイプラインの構築・維持コストを最小化したい
 ◦ HashiCorp社のサポートを受けたい
 
 

20. 20 Stage.3 デプロイパイプライン

21. 21 Stage.3 デプロイパイプライン ✅ 解決できたこと
 ◦ 手動コマンド実行によるミスを防止
 ◦ ローカルのAWS認証情報を廃止、デプロイツール上で一元管 理
 

22. 22 しばらく経ち IaC運用が軌道に乗ってきた
23. 23 IaCの利用規模拡大 規模が大きくなり、以下の課題が発生
 ❌ 課題
 ◦ コードレビューの負荷が高く、リリースサイクルが遅くなってい る
 ▪ 以下のようなインフラコードのPR(MR)が上がってくる
 - 自社のガイドラインに違反している
 - セキュアな設定になっていない
 ◦ 手動運用時より障害は減ったが、もっと減らしたい

24. Stage.4 スキャン・テスト・ビルド 24 • 自動テストを導入する
 ◦ 静的解析
 ◦ プランテスト
 ◦ ユニットテスト
 ◦ 統合テスト
 ◦ E2Eテスト
 • ...etc
 
 ※太字部分を解説
 
 

25. 25 静的解析 terraform validate tflint Snyk IaC 説明 Terraformの組み込 みコマンド リンターツール セキュリティスキャ ンツール チェック対象 文法 プロバイダー (AWS,GCP,Azure) の特定の制約やエ ラー 例) AMIやインスタ ンスタイプの検証 作成されるリソース のセキュリティ 例) S3バケットが暗 号化されてない Terraformコードを解析する(実際のコード実行は無し)
 
 
 

26. • TerraformのPlan結果を解析する
 • 静的解析との比較
 ◦ Pros
 - Planを実行するため、より踏み込んだ解析が可能
 ◦ Cons
 - プロバイダ(AWS,Azure, Google Cloud)の認証情報が必要
 • ポリシーの例
 ◦ 「ManagedBy = terraform」タグがついていないリソースのデプ ロイ禁止
 ◦ 金曜日にデプロイすることを禁止
 
 
 26 プランテスト
27. 27 プランテスト Open Policy Agent (OPA) HashiCorp Sentinel Snyk IaC (内部でOPA利用) 対象 Terraform,Kubern etes,Envoy等 HashiCorp製品 (Terraform,Vault,N omad,Consul) Terraform,CloudF ormation,Kubernet es等 言語 Rego Sentinel Rego
28. 選定したツール 28 • 静的解析: terraform validate,tflint, Snyk IaC
 ◦ 役割が異なるため、全て組み込む
 • プランテスト: Snyk IaC,OPA
 ◦ Terraform Cloudがサポートしているため組み込み易い
 ◦ KubernetesやEnvoyにも対象を広げていきたい
 ◦ Terraform Cloudでカスタムルールを使う場合、OPAの方が使 い回ししやすい
 
 
 

29. 29 Stage.4 スキャン・テスト・ビルド

30. 30 Stage.4 スキャン・テスト・ビルド ✅ 解決できたこと
 ◦ レビュー負荷が軽減、リリースサイクル向上
 ◦ 早期にミスを検出できるようになり、障害のリスク軽減

31. 31 Stage.5 発展的なIaC活用 • インフラセルフサービス化
 ◦ No-Code Provisioning(Terraform Cloud)
 • AWSアカウント払い出し&ベースライン設定
 ◦ AFT、CfCT

32. 32 まとめ IaC運用の成熟度向上に、IaCジャーニーマップを
 是非お役立てください

33. 33 関連URL Terraform Cloud - https://developer.hashicorp.com/terraform/cloud-docs Snyk - https://snyk.io/jp/product/infrastructure-as-code-security/ Terraformのデプロイパイプラインに使用できるツールをまとめてみた - https://dev.classmethod.jp/articles/terraform-deploy-pipeline-tool/ Snyk IaCでTerraformコードのセキュリティ解析をしてみた - https://dev.classmethod.jp/articles/snyk-infrastructure-as-code-security-overvie w/ Terraform CloudのOPA Policy適用のチュートリアルをやってみた - https://dev.classmethod.jp/articles/terraform-cloud-opa-policy-tutorial/