この前AWS公式のYouTubeチャンネルにて、面白そうなライブ配信がありました
AWSの動画コンテンツといえば、BlackBeltのようなサービス紹介の動画が真っ先に思い浮かぶ方も多いと思います。
自分もその一人ですが、この動画はプロダクトではなく「Infrastructure as Code（IaC）という概念」にフォーカスしたコンテンツです。
Twitterで学びメモを書きましたが、ちゃんと記事として学びをまとめておこうと思います。
また、動画の内容に関連した補足事項を記事の後半にまとめておきました。
↓動画本編はこちら↓
↓資料はこちら↓
IaCをなぜ使うのか
- 純粋にIaCは楽しい、手順書作成は楽しくない
- リリースのたびに手順書更新 or 新規作成するのは、果たして楽しいのか
- IaCのほうがリリースまでのリードタイムが短い
運用する上での教育はどうする？
- そもそも「教育」はIaCじゃなくても必要
- 逆に、手順書ベースの運用なら教育はいらないのか？
- 教育云々の問題の前に、IaCなら読み込めばアーキテクチャの全体像が見える
- 手順書は手順しかない、全体像はわからない。
- 運用を考えてもIaCのほうがメリットがあると思う。
- チャレンジを許容する組織文化が必要
ドキュメント管理どうやってやればいい？
- ツールによって管理方法を変える
- リリースと同時に図も更新する
- 例えば、draw.io のXMLファイルをGitHubで管理、プルリクも同時に挙げる、など
引き継ぎ
- そもそも常日頃から引き継ぎできるようにしよう
- ウォーターフォールでも、アジャイルでも、いつでも引継ぎできる状態にしておくべき
- 組織が開発と運用で分断されてるとIaCの良さを活かすのは難しい
- 開発と運用が分断されているのは果たして正解なの？
- 逆に、手順書なら問題なく引き継ぎできるのか
変わることへの恐怖の克服
- とはいえ、大企業など変わることを怖がる組織ではIaCは難しいのでは。。？
- 対策として挙げられるのは「小さく慎重に始める」
- 例えば、部分的に一連のパイプラインを作ってみる
- ただし、IaCは始め方が重要、始め方を間違えると後戻りできないので注意
- 経験者やAWSのSAさんに頼ってしまうのもあり、外部のリソースもうまく活用しよう
IaCのデメリット
- DBの中は手を出せない
- ロールバック失敗のリスクがある
- ロールバックが発生した場合、スムーズにロールバックできるのか？できなかったらどうする？
- 対策として、イミュータブルな構成にすべき
最後に
- 外部のリソースを有効活用すべし
- 緊急リリースや脆弱性対応を行うと、環境ごとのずれが出てしまうので、デプロイ頻度は細かくすべき
- 手順書を毎回更新するのではなく、汎用的な手順書を使い回す
補足
イミュータブル・インフラストラクチャとは
- イミュータブル（immutable）は「不変」の意味。本番環境に手を加えないインフラストラクチャのことを指す
- 本番環境を変更するときは、新しく別のインフラを構築する
- 問題なければネットワークをパチッと切り替える
- 切り替え後に問題があれば、ネットワークだけを切り替えることで旧環境にすぐ戻せる
- 移行・更改の負担を減らすことができる
- IaCでコード化することで、一元的な管理と自動化が可能になる
draw.ioとは
- ブラウザ上で無料で使える作図ツール
- AWSのアイコンを使って構成図を作成することが可能
- OneDrive、Googleトライブ、Dropbox、GitHubに描画データを保存・共有できる
ほかにこんな記事も書きました
IaCを考える前に、そもそもパブリッククラウドへアクセスする際の認証認可を考えなければなりません
AWSにはIAMというサービスがあり、認証認可の基盤となる縁の下の力持ち的なサービスです
そんな超重要なIAMについて、ロジックからしっかり学べる場所があるんです！
以下の記事で学んできたことをまとめているので、もしご興味があれば合わせて読んでもらえると嬉しいです