Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWS Codeシリーズ Terraformパイプライン 勉強会/ハンズオン
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
hiyanger
March 31, 2024
Technology
360
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
AWS Codeシリーズ Terraformパイプライン 勉強会/ハンズオン
2024/3/12 自社内にて実施
hiyanger
March 31, 2024
More Decks by hiyanger
See All by hiyanger
SREに優しいTerraform構成 modulesとstateの組み方
hiyanger
2
230
Terraform やるなら公式スタイルガイドを読もう 〜重要項目 10選〜
hiyanger
14
4.1k
(Amazon Bedrock 基礎)生成 AI の活用に導くシステム構築の基本とセキュリティの実装
hiyanger
4
150
CIer に在籍した 3年間 でやったこと
hiyanger
2
400
これからクラウドエンジニアになるために本当に必要なスキル 5選
hiyanger
1
810
クラウド食堂とは?
hiyanger
0
470
Amazon ECS とマイクロサービスから考えるシステム構成
hiyanger
2
1.5k
全身全霊で取り組んだ 2024 Qiita アドベントカレンダー
hiyanger
0
130
Terraform で作る Amazon ECS の CI/CD パイプライン
hiyanger
1
520
Other Decks in Technology
See All in Technology
AI ネイティブな組織に Gemini Enterprise Agent Platform がなぜ必要なのか
asei
1
150
オートロックマンションなのに、各部屋は施錠なし!? 攻撃者が組織内ネットワークで大暴れする理由 / The Front Door Is Locked, but the Rooms Are Wide Open: Why Attackers Move Freely Inside Enterprise Networks
nttcom
0
980
エンタープライズデータへ安全につなぐ Production-ready なエージェント設計 ― AI × MCP リファレンスアーキテクチャ ― #AIDevDay
cdataj
1
460
データと地図で読む 大井町の「かわるもの、かわらないもの」
yoshiyama_hana
0
900
QAタスクをスキル化したいときに考えること
aomoriringo
0
150
システム監視入門
grimoh
5
790
Amazon Bedrock Managed Knowledge BaseDive Deep
ren8k
0
330
AIは実装を速くする。では、私たちは何を今作るべきか?-立場を越えてリリースに向き合ったチーム開発の実践 / 20260801 Hiromi Nakaya and Naoki Takahashi
shift_evolve
PRO
3
250
ウォーターフォール開発案件のPMとしてAI活用を模索している話
hatahata021
3
260
ここは地獄!つらい朝会を体験することで、チームとしてのより良い振る舞いに気づくワークショップ / The stand-up meeting from hell in the game industry
scrummasudar
0
540
Data Hubグループ 紹介資料
sansan33
PRO
0
3.1k
現場で使える AWS DevOps Agent 活用ノウハウ - Release Management 機能の検証結果を添えて / AWS DevOps Agent Release Management and Know-How
kinunori
5
850
Featured
See All Featured
Tell your own story through comics
letsgokoyo
1
1k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
940
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
550
Paper Plane (Part 1)
katiecoart
PRO
1
10k
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
370
30 Presentation Tips
portentint
PRO
1
360
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
67
56k
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
430
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
1.1k
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.9k
Documentation Writing (for coders)
carmenintech
77
5.4k
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
350
Transcript
CONFIDENTIAL AWS Codeシリーズ Terraformパイプライン 勉強会/ハンズオン アイレット株式会社
CONFIDENTIAL 予定 2 ① Terraform 基礎 ② 構成とか ③ ハンズオン
CONFIDENTIAL 3 1.Terraform基礎
CONFIDENTIAL Terraform 基礎 4 AWSリソースは一般的にAWSコンソールからぽちぽちしてデプロイするか、 AWS CLIを使って端末コンソールからデプロイしますが、Terraformは デプロイ情報をコード化し、まとめてAWSリソースをデプロイできるようになります。 インフラのコード化はIaCと呼ばれTerraformはその中の代表的なツールです。 コード化することのメリットとしては以下があげられます。
・GUI特有の操作ミスがなくなる ・リソースの複製、復元が容易 ・Git利用で変更管理が可能
CONFIDENTIAL 利用はとっても簡単で、 ざっくり下記の4点で可能です。 ①Terraformインストール ②AWSとの接続設定 ③コード記述 ④Terraformコマンドの実行 Terraform 基礎 利用方法
5
CONFIDENTIAL 6 2.パイプライン構成
CONFIDENTIAL パイプラインとは 7 コードを変更すればビルド、デプロイまで自動で流れてくれるシステムのことです。 CICDパイプラインと呼ばれたりもします。
CONFIDENTIAL パイプラインの構成 Terraform 8 CodeCommitでコードを編集すれば、CodePipeline→CodeBuildがTerraformを動作させる仕組みです。 CodeCommitはdevelopとmainという2つのブランチにわかれており、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につながると かリソースレベルの動作確認は 基本不要。