Infrastructure as Code 感想 (1章)

June 11, 2017

オライリーの「Infrastructure as Code」を読んで思ったことや自分的メモをまとめておく．太字は自分の感想， 斜字体は本からの引用 ，そのほかは本の要約など．

Infrastructure as Codeの目標

ざっくり言うと「(頻繁な)変化に柔軟に対応できるようになること」ということかなと思った
そのために
- システム変更が日常茶飯事の出来事になること
- 失敗を完全に防ぐという前提は捨てる．失敗しても素早く修正できるようになることを目指す
- 反復的なタスクは自動化すること
- 継続的な改善をすること
会議やドキュメントでソリューションを論ずることなく，実装，テスト，計測を通じてソリューションの効果が証明できるようになること
- Infrastructure as Codeでこれを目指す，というのがピンと来なかった

サーバースプロール，構成ドリフト，スノーフレークサーバーは自分の環境ではほとんどないかな
- いちおうChefを使っている
- ロールごとにVMを作成して役割が混ざらないようにしている
オートメーション恐怖症…これはある
- サーバーに統一性がない→オートメーションにより何かが壊れないかが心配→オートメーションツールの外で変更を加える→… の悪循環
- この循環から抜けるには「自動化された変更」のリリースプロセスの確立とテストの充実が必要になると最近は考えている
  - 「この変更」を「この方法」で適用するのは安全である，と自動的に言えるようになればいい
ペットから家畜へ
- 数年前からよく聞くようになった
- サーバ名にテーマを設け，自分がプロビジョニングした新しいサーバーの名前をじっくり考えていた時代が懐しい．しかし，担当するすべてのサーバーを手作業で調整し，サーバーのご期限をうかがわなけれあならなかった時代は懐しくない
  - おもしろい

一部のサーバーでより大きなディスクが必要になった場合
- すべてのサーバーを同じように拡張する
- xl-file-serverのような新しいロールを追加する
自分だと深く考えずに(ロールを分けずに)そのサーバーだけ拡張してしまいそうだと思った(ディスクサイズだけ変数化しておけばいいじゃん)
- その些細な差異が積み重なって管理システムと人に負荷を与えることになる．気をつけたい

「パーティションの分割」のような些細なタスクであろうとも，手動でやってしまうと差異が生じる可能性がある．
- サイズ，ファイルシステム，そのパラメータ etc.
スクリプトで実行できるシステムはかならずスクリプトにする
- そして，将来同様のタスクをするとになったときにそのスクリプトを使う ←これが難しい．スクリプトを書くだけでなく管理システムに組み込まなければならない
スクリプトにするのが難しい場合は問題を掘り下げて，役に立つテクニックやツールがないか，別の方法がないかを検討する

永続化が必要なデータの定義を広げることが大切．通常はアプリケーションの構成/設定，ログファイルなども保護対象に含める
- サーバーを家畜のように扱うことを前提に，サーバー上のほとんどの情報はいつ失われてもよい状態にしておくということか

Kief Morris, Infrastructure as Code クラウドにおけるサーバ管理の原則とプラクティス, 長尾高弘訳, オライリー・ジャパン, 2017