Infrastructure as Code 談議 2022
- スピーカー
- 進行
- 杉山 祐介氏 (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト)
セッション
- 構成ツール
- サーバー構成ツール:Ansible, Chef, Puppet
- インフラストラクチャ構成ツール:Terraform, CloudFormation
- なぜ IaC ?
- ダイナミックインフラストラクチャの台頭
- プログラムを使ってインフラを管理できるプラットフォーム
- インフラの変更管理を容易にするため
- ダイナミックインフラストラクチャの台頭
- IaC の原則
- 簡単に再現できるシステム:CI/CD
- 使い捨てにできるシステム:CD からデプロイされるサーバ環境
- 統一的なシステム:Git での管理
- 反復できるプロセス:パイプライン
- 絶えず変化するデザイン:開発者の思い
- IaC という言葉の初出は2008年
なぜ IaC を行うのか?
- 手作業と比較して安全で楽しい
- リリースへのリードタイムを短くする
- ビジネスではリードタイムの短縮はとても重要
IaC の教育は?
- IaC だからといって特別な教育が必要なわけではない
- 輪読会など通常の技術のキャッチアップをすればいい
- IaC は依存関係も含めて書かれているので理解しやすい
- 手順書のほうが教育が大変
- 順番が書いているだけなので理解が難しい
- 暗黙的に行われることが多い
- 組織文化が大事
- 失敗するたびに承認プロセスが増えるような文化はダメ
- 小さな失敗を繰り返して改善していくアジャイルな文化がいい
- IaC でドキュメントがいらないというわけではない
- README で残す
- アーキテクチャ図と実際のインフラは DrawIO などで同時に GGit管理する
- 再利用性とバージョン管理ができるのがいい
引き継ぎはどうする?
- いつでも引き継げるようにドキュメント化&コード化
- 日常的に準備しておく
- 複数人やペアプロで対応するのが理想
- 教育もセットでできるといい
- アジャイルでは引き継ぎは発生しない
- 開発の中で常に共有する
- 手順書だからといって引き継ぎできるわけではない
- IaC は DryRun で試すことができる
どうやって IaC に踏み出す?
- 全部 IaC 化を考えず簡単なところから始める
- 簡単な部分を一気通貫で試して広げていく
- 最初に変なのを作るとそれが増産されるので注意する
- 最初にいい素材を入れるために経験者など外部リソースに頼るのもいい
IaC で解決できないツラミは?
- DB の中身をいじるなどできない
- ランタイムのアップデート後のロールバックでのダウングレードなどは失敗しがち
- 破棄して作り直しが簡単
- ブルーグリーンデプロイなどを活用しよう
まとめ
- 数ヶ月に1度のデプロイのほうが危険
- 脆弱性対応などでもっとデプロイ回数が多いハズ
- 毎日デプロイして本番とずらさないのが一番安全!
所感
CloudFormation 大好きなんで、内容的にはすごく同意できるんですが、布教活動が難しいんですよね。
この楽しさを上手に言語化して使える人を増やして引き継いで行きたい。