CONFIDENTIAL AWS Codeシリーズ Terraformパイプライン 勉強会/ハンズオン アイレット株式会社

CONFIDENTIAL 予定 2 ① Terraform 基礎 ② 構成とか ③ ハンズオン

CONFIDENTIAL 3 １.Terraform基礎

CONFIDENTIAL Terraform 基礎 4 AWSリソースは一般的にAWSコンソールからぽちぽちしてデプロイするか、 AWS CLIを使って端末コンソールからデプロイしますが、Terraformは デプロイ情報をコード化し、まとめてAWSリソースをデプロイできるようになります。 インフラのコード化はIaCと呼ばれTerraformはその中の代表的なツールです。 コード化することのメリットとしては以下があげられます。 ・GUI特有の操作ミスがなくなる ・リソースの複製、復元が容易 ・Git利用で変更管理が可能

CONFIDENTIAL 利用はとっても簡単で、 ざっくり下記の４点で可能です。 ①Terraformインストール ②AWSとの接続設定 ③コード記述 ④Terraformコマンドの実行 Terraform 基礎 利用方法 5

CONFIDENTIAL 6 2.パイプライン構成

CONFIDENTIAL パイプラインとは 7 コードを変更すればビルド、デプロイまで自動で流れてくれるシステムのことです。 CICDパイプラインと呼ばれたりもします。

CONFIDENTIAL パイプラインの構成 Terraform 8 CodeCommitでコードを編集すれば、CodePipeline→CodeBuildがTerraformを動作させる仕組みです。 CodeCommitはdevelopとmainという２つのブランチにわかれており、developを編集すれば開発、mainを編集すれば商用で Terraformが動作します。 今回使うのは developのみ！

CONFIDENTIAL Git運用 ブランチの使い方 9 下記の流れで各ブランチを更新します。 ① feature/機能名 ブランチ作成/プッシュ ② develop（検証）プルリクエスト/マージ ③ main（商用）プルリクエスト/マージ

CONFIDENTIAL Git運用 コード記述のルール 10 ここからは少し具体的なお話です。前述の通りパイプラインの運用にGit（CodeCommit）の運用が必要です。 コードは可読性からくる保守性の向上のため、一定の記述の統一性をもたせています。 そのため、コードは同系統のリソース記述を参考に記述するようにしてください。下記にポイントを記載します。 ・コメント ・Terraformリソース名 ・AWSリソース名 ・環境変数の利用 ・ポリシーの外だし （同系統のポリシーが 　つくられる場合）

CONFIDENTIAL Git運用 コミットメッセージの書き方 11 featureブランチへのpush時にコミットメッセージ （どこのなにを更新したか）を求められます。 コミット履歴が一目でわかるよう、 下記の規則にのっとって記述してください。 ・prefix fix：バグ修正 add：新規（ファイル）機能追加 update：機能修正（バグではない） remove：削除（ファイル） ・記述例 [add] CICD [add] CodeBuild [fix]CodeBuild ReadOnelyAccess

CONFIDENTIAL Git運用 .gitignore 12 Gitでpushさせないファイルが記述されています。もし今 後該当するファイルが追加された場合は、ここに記述を追 加してください。 主にzipやterraform providerのファイルが対象になって います。 大容量のファイルを追加してしまうと、git cloneに時間 がかかってしまったりするのでそこも注意です。

CONFIDENTIAL ディレクトリ構成 13 modules →common（環境共通リソース） →network.tf（VPC、サブネット） 　ec2.tf 　s3.tf bucketpolicy（バケポリjson格納用） dev →main.tf 　provider.tf（AWSのprofile名をここに記述） backend.tf（terraformのリソース管理ファイル.tfstateの格納先などを記述） variable.tf terraform.tfvars prd 今回は使わない（一応mainにマージするとBグループアカウントにあるパイプラインが動く） .gitignore（git push除外ファイル） ※各環境配下 buildspec_apply.yml（codebuild用ファイル） buildspec.plan.yml（codebuild用ファイル）

CONFIDENTIAL Terraform ハンズオン 14 1.端末plan用 terraform1.5.7インストール https://qiita.com/kamatama_41/items/ba59a070d8389aab7694 　VSCodeに拡張もいれる「HashiCorp Terraform」 2.CodeCommit→cicd-tf→developブランチからfeatureブランチを作成 feature/XXX 3.IAMからcodecommit認証情報をダウンロードしてVSCodeでgit clone→作成したfeatureブランチに切り替え 4.ローカルからのplan用にAWSクレデンシャルをstg/provider.tfへ記述（push時にはコメントアウトする） 5.Terraformコード作成 https://registry.terraform.io/providers/hashicorp/aws/5.24.0/docs/resources/codecommit_repository 　※リソース名の頭には「dev」をつけましょう 「${env}」という記述でstg/terraform.tfvarsから取得できます。 　（環境固有の変数が設定可能。環境共通変数はlocal変数で記述できる。変数の動きは重要なので余裕あれば適当に使ってみるとよいかも 　　アカウント番号とか差し替えが起こりやすいものがでてきたら変数使ってみてください。コンフリクトしたらうまく調整。） 　① VPC/サブネット作成 https://registry.terraform.io/providers/hashicorp/aws/5.24.0/docs/resources/default_vpc 　できそうなら ② ①へEC2作成 https://registry.terraform.io/providers/hashicorp/aws/5.24.0/docs/resources/instance 　できそうなら ③ S3へ①からフローログ設定（バケポリDeleteBucket禁止だけ記述。外出しで記述すること/環境名は変数で記述 P10） 　https://registry.terraform.io/providers/hashicorp/aws/5.24.0/docs/data-sources/s3_bucket 6.端末からのterraform init/terraform planでデプロイ確認 7.VSCodeでステージング→コミット→git push 8.CodeCommitからdevelopへプルリクエスト→マージ（実施時に声をかけること） 9.Codepipelineにてterraform planを確認できたら手動でApproval（承認）する 10.terraform applyが正常に流れれば完了（最後にローカルからterraform destroyしとく） planの確認は自端末から、 実際のapplyはパイプラインから流します！ （パイプラインを流すのは手間なので、planは さくっとterraformコマンドを流せる時端末も使う） ここまでみんな一緒にやる ここからはVPCだけで9までの流れみせて、 そのあとは各自やってもらう 各リソースはデプロイさえできれ ばOK。なので、EC2につながると かリソースレベルの動作確認は 基本不要。