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
非IaCなAWS環境をCloudFormationでIaC化する
Search
kefi550
October 08, 2023
Programming
2
510
非IaCなAWS環境をCloudFormationでIaC化する
【AWS】AWS10分LT会 - vol.1
https://aws-likers.connpass.com/event/296768/
kefi550
October 08, 2023
Tweet
Share
More Decks by kefi550
See All by kefi550
ECSのコストのケチり方
kefi550
0
200
Amazon Pinpoint使ってますか?Amazon PinpointでGmail送信者ガイドラインに対応した話
kefi550
0
590
CO2濃度を監視して生産性向上💪
kefi550
0
31
Other Decks in Programming
See All in Programming
Compose でデザインと実装の差異を減らすための取り組み
oidy
1
240
ファインディの テックブログ爆誕までの軌跡
starfish719
1
790
chibiccをCILに移植した結果 (NGK2025S版)
kekyo
PRO
0
190
[JAWS-UG横浜 #79] re:Invent 2024 の DB アップデートは Multi-Region!
maroon1st
0
130
EC2からECSへ 念願のコンテナ移行と巨大レガシーPHPアプリケーションの再構築
sumiyae
3
630
Amazon Bedrock Multi Agentsを試してきた
tm2
1
240
ペアーズでの、Langfuseを中心とした評価ドリブンなリリースサイクルのご紹介
fukubaka0825
1
200
知られざるDMMデータエンジニアの生態 〜かつてツチノコと呼ばれし者〜
takaha4k
3
1.1k
ASP. NET CoreにおけるWebAPIの最新情報
tomokusaba
0
220
最近のVS Codeで気になるニュース 2025/01
74th
1
240
サーバーゆる勉強会 DBMS の仕組み編
kj455
1
360
AHC041解説
terryu16
0
550
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
222
9.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Typedesign – Prime Four
hannesfritz
40
2.5k
Why Our Code Smells
bkeepers
PRO
335
57k
A designer walks into a library…
pauljervisheath
205
24k
Faster Mobile Websites
deanohume
305
30k
Designing for humans not robots
tammielis
250
25k
Building Your Own Lightsaber
phodgson
104
6.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.4k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
The Language of Interfaces
destraynor
156
24k
Transcript
非IaCな環境をCloudFormationで IaC化する 2023/10/09 AWS10分LT会 - vol. 1 1 石橋翔太 (@kefi550)
IaCとは https://docs.aws.amazon.com/ja_jp/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html
• AWSリソースがほぼすべて手で作られており、コード化はされていない 課題 • 本番/ステージングで細かい差分が多い...無意味な差分がある... • 作業(手順)漏れなどによるリリース失敗... • AWSリソース等環境の把握、変更レビューがムズい...(自分が入社したときムズかった)
コード管理されず、手作業によるインフラ管理は盆栽になりやすい 課題 ステージング 本番 とりあえず変更... とりあえず変更... なんでこうなってんだっけ?
• パラメータを変えることで、あるテンプレート から環境ごとのリソースを作る 理想の状態 共通テンプレート stagingリソース productionリソース Env=production Env=staging
無意味な本番/ステージングの差分を防止 理想の状態 共通テンプレート stagingリソース productionリソース Env=production Env=staging
• 既存リソースをCFnスタックにimportする ◦ import作業は多少めんどい ◦ 再作成できない系リソースはこっちがいい • 既存リソースと等価なリソースをCFnで作成し、古いリソースを削除するリプレイス ◦ 作るのはラク
◦ 新たに作ったリソースが要件を満たしているかの確認を注意する必要がある • 新規作成系リソースは必ずCloudFormationで作る心構えをする ◦ 既存リソースをコード化するのに比べてラクなので新規作成時にコード化すべき 既存リソースをCloudFormation化していくアプローチ
• former2 をつかって本番/ステージングそれぞ れのリソースのテンプレートを得る • https://github.com/iann0036/former2 既存リソースをCFnスタックにimportする
• 本番/ステージングの同じ役割のリソースをFn::If 等を使って気合で1つのテンプレートにマージ • スタックにimportして、ドリフトが無いことを確認(ドリ フト検出できないリソースもある ) 既存リソースをCFnスタックにimportする
• 本番/ステージングの変な差分 課題 本番DB sg-xxx TCP 5432 allow from sg-zzz
ステージングDB sg-yyy TCP 5432 allow from 0.0.0.0/0
• Fn::Sub や Fn::Ref等を使って共 通テンプレートを整理する 既存リソースをCFnスタックにimportする
一旦既存の状態をそのままスタックにimportしてから細かく変更することで、影響範囲やレビュー 負荷を小さくできる
• 一旦既存の状態のままスタックにimportしてから細かく変更することで、影響範囲やレビュー負荷 を小さくできる • importの段階で多少の気合が必要 ◦ ドリフト検出を使って、テンプレートが正しく現状と合っているかは確認できる
既存リソースをCFnスタックにimportする
• ほぼコード化されていないAWSリソースをCloudFormationでコード化しています • CFn resource importで安全にCFn移行 コード化していまのところ良かったこと • (リソースの作成変更といった)作業漏れが発生しにくい
• マネコンから作るのに比べて、細かいパラメータへの意識 • レビューしやすい • ゴミが残りづらい • オンボーディングに便利(だと思う) おわりに
インフラはコードで管理しよう