■

 「infrastructure as a code」を読む。

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

概要

もう５年位前の出版にはなるけど、現在もインフラ設計知識や考え方を学ぶには良い本。Terraform、Packer、Vagrant、Jenkins、chef、Ansibleなど具体的なツール名や若干のコードも出てくるけど、それは概念を説明するための手段で、あくまでも考え方を学ぶための本、と考えて読んだ方が良い。結構内容的に重複してる部分が多いので、時間ない人は「課題と原則」章だけでも学びはあると思う。後は、「プラクティス」項目を拾い読みするだけでも、こういう考え方で設計すべし！というのが学べるのでそれもあり。後は、訳者のスライドも有用。

speakerdeck.com

本書に出る頻出単語

この辺覚えておくだけでも、インフラ界隈の会話の共通言語として使えそう。

・サーバースプロール
→個々に手修正が入り、一律で設定管理しきれないサーバー群。仮想化とかクラウド　　の技術によりサーバがハードに縛られなくなり、乱立してしまう結果起こる。
・構成ドリフト
→構成や設定のずれ。
・スノーフレークサーバ
→雪のひとかけらだけ、他のサーバ群と設定が違うサーバ。本番でうまく稼働してた　　りすると再現できず、オートメーション恐怖症を引き起こす。
・オートメーション恐怖症
→インフラをコードで一律自動化するのが怖い状態。スノーフレークサーバがたくさ　　んあると、「何かしら違うけどどこか違うか分からない」状態であり自動化すると絶対何かトラブりそうな予感がする感じ。

自動化とセキュリティ
プッシュベースの構成・設定は、どうしても接続用のポートを開いておく必要があり、攻撃者にとっても標的となるためセキュリティとトレードオフになる。一応プルで構成・設定もできるが、その場合はエージェントをインストールしておき、cronとかで定期実行する必要あり。こっちの方がセキュリティ的には安全。

学びになったプラクティス

• コンテナは強化版のRPM。疏結合で軽い。
• サーバのプロビジョニングを最適化するためのキャッシングを意識する。
• 毎回編集しなければいけないようなスクリプトを書いてはいけない。
• ホットクローンを使ってはいけない。結果が予想できないし。
• サーバ作成時はブートストラップで設定し最新にして、自動テストまで行う。
• サーバ作成時か、テンプレートのプロビジョニングに盛りこむかバランスを考えて設計すべし。
• スタック定義をテスト、プロモートせよ。テストの信頼性が下がってしまう。
• アプリコードとインフラコードを統一的に管理すべし。一緒にテスト出来るから。
• DevOopsにならないように気をつけよ。自動構成の仕組みは逆に自動破壊ももたらす。

• VCSで管理すべきでないものは以下の通り。

  　ソフトウェアアーティファクト
  　アプリのデータやログファイル
  　パスワードなどの機密情報

インフラのテストコードはかくあるべし

• テストスイートは構造化し、構文チェック、静的コード解析、ユニットテストみたいな低い水準のテストは出来るだけ低い水準でテストすべし。
• 必要な階層のみ実施し、不要テストを刈り込むべし。反射テストという構成定義を言い直してるだけのテストは不要。
• テストコードとテスト対象も一緒に管理すべし。
• テストダブル、モックなどを活用して効率的にテストすべし。
• 全ての変更をパイプラインの先頭からスタートさせよ。途中で失敗したテストに応じて変更した環境は、最初からテストしなおせ。
• テンプレートは階層化して管理すべし。
• ローカルテストを行ってからテストすべし。

実際にインフラを何かしら変更する場合はこうすべし、という手順

ここまで作りこめたら理想。

1. VCSからチェックアウトする。
2. ローカルVMで設定変更し、中でテストする。
3. 変更分の自動テストを書く。
4. 変更分のAnsibleのプレイブックを変更する。
5. 変更をローカルVMに適用してテストに問題ないことを確認する。
6. １．でチェックアウトしてから他の人の変更分をマージするため、再度アップデート。
7. ローカルVMを一度破棄して再構築してテストし、マージ後も問題ないことを確認する。
8. VCSをコミットする。
9. 自動ステージのパイプラインが通過することを確認。
10. 本番環境に変更が反映されてることを確認する。