Open6
2025/2/25 Infrastructure as Code 談義 ~ これってやりすぎ?やらなすぎ ? ~ AWS Developer Live Show
Q1. IaCを書き始めるタイミングは?
- 判断するタイミングやシチュエーションはいろいろある
- やらなすぎ
- アプリ完成後、運用フェーズでIaC化
- すでに出来上がったものをIaC化は大変、環境を壊してしまうリスクもある
- アプリ完成後、運用フェーズでIaC化
- ちょうどいい
- IaCは開発段階から始めるのがいいか
- 生成AI前提なら初手IaC
- 同じ構成を作らないならIaCは不要か?
- 簡単なものならIaCにしないというケースもある。
- パラメータチェックや、環境レビューにIaCはメリットあるのでセキュリティ面でチェックしたいならIaCはよい
- やりすぎ
- 新しいAWSサービス
- IaC対応が遅いものは、まずはマネジメントコンソールで検証後にIaC化
- いつでも最初からIaC
- 最終的にIaC化はマスト。検証など一時的なものなら手作業でもいい。
- 本番で使う予定であるなら最初からIaC
- IaCの利用度によっては手元にノウハウがあって、ベースとして使えるなら検証でも使うのはあり。
- 新しいAWSサービス
Q2. IaCは運用のどこまでをカバーすべき?
- やらなすぎ
- 最初だけIaC、ドリフト当たり前
- IaCの管理メリットがないので、スタック管理から除外してしまうとか。
- 最初だけIaC、ドリフト当たり前
- ちょうどいい
- DBを入れるかいれないか
- DBの数などにもよる
- 限界までIaC
- 意見いろいろ
- ライフサイクルが長いものはIaC管理から外す
- PRでレビューしたらCI/CDで反映されるので楽
- DBを入れるかいれないか
- やりすぎ
- 手動操作は絶対に許さない
- ”絶対”は厳しい。緊急時はOKなど
- 手動操作は絶対に許さない
Q3. IaCでどのくらいドキュメント書く?
- やらなすぎ
- デプロイコマンドだけ
- ちょうどいい
- やりすぎ