監訳者まえがき
はじめに
第Ⅰ部　基礎
1章　課題と原則
1.1　なぜInfrastructure as Codeなのか
1.2.I　InfrastructureasCodeとは何か
1.2.1　Infrastructure as Codeの目標
1.3　ダイナミックインフラストラクチャが生み出した課題
1.3.1　サーバースプロール
1.3.2　構成ドリフト
1.3.3　スノーフレークサーバー
1.3.4　脆いインフラストラクチャ
1.3.5　オートメーション恐怖症
1.3.6　システム疲労
1.4 Infrastructure as Codeの原則
1.4.1　簡単に再現できるシステム
1.4.2　使い捨てにできるシステム
1.4.3　統一的なシステム
1.4.4　反復できるプロセス
1.4.5　絶えず変化するデザイン
1.5　プラクティス
1.5.1　定義ファイルの利用
1.5.2　自己記述システムとプロセス
1.5.3　あらゆるものをバージョン管理する
1.5.4　継続的テストシステム、プロセス
1.5.5　一斉変更ではなく小刻みな変更
1.5.6　継続的にサービスを利用可能状態に保つ
1.6　アンチフラジャイル：「堅牢」を越えて
1.6.1　アンチフラジャイルなITシステムの秘密の成分
1.7　まとめ
1.8　このあとの章について
2章　ダイナミックインフラストラクチャプラットフォーム
2.1　ダイナミックインフラストラクチャプラットフォームとは何か
2.2　ダイナミックインフラストラクチャプラットフォームの要件
2.2.1　プログラマブル
2.2.2　オンデマンド
2.2.3　セルフサービス
2.3　プラットフォームから提供されるインフラストラクチャリソース
2.3.1　計算リソース
2.3.2　ストレージリソース
2.3.3　ネットワークリソース
2.4　ダイナミックインフラストラクチャプラットフォームのタイプ
2.4.1　パブリッククラウドのIaaS
2.4.2　コミュニティクラウドのIaaS
2.4.3　プライベートクラウドのIaaS
2.4.4　アンチパターン：手回し式クラウド
2.4.5　ハイブリッド、ミックスクラウド
2.4.6　ベアメタルクラウド
2.5　ダイナミックインフラストラクチャプラットフォームに関する判断のポイント
2.5.1　パブリックかプライベートか
2.5.2　クラウドのポータビリティ
2.6　クラウドと仮想化に対するマシンレベルの共感
2.7　まとめ
3章　インフラストラクチャ定義ツール
3.1.I　Infrastructure as Codeのためのツールの選択
3.1.1　要件：スクリプトで操作できるインターフェイス
3.1.2　要件：コマンドラインツールの無人モード
3.1.3　要件：無人実行のサポート
3.1.4　要件：設定の外在化
3.2　構成定義ファイル
3.2.1　構成定義の再利用可能性
3.3　インフラストラクチャ定義ツールの操作
3.3.1　手続き型スクリプトによるインフラストラクチャのプロビジョニング
3.3.2　インフラストラクチャの宣言的な定義
3.3.3　インフラストラクチャ定義ツールの使い方
3.3.4　サーバーの構成/設定
3.4　構成レジストリ
3.4.1　軽い構成レジストリ
3.4.2　構成レジストリはCMDBか
3.4.3　CMDBの監査、修正のアンチパターン
3.4.4　CMDBに対するInfrastructure as Codeのアプローチ
3.5　まとめ
4章　サーバー構成ツール
4.1　自動化されたサーバー管理の目標
4.2　さまざまなサーバー管理機能に対応するツール
4.2.1　サーバー作成のためのツール
4.2.2　サーバーの構成/設定のためのツール
4.2.3　サーバーテンプレートのパッケージングのためのツール
4.2.4　サーバー上でコマンドを実行するためのツール
4.2.5　中央のレジストリに格納されている構成/設定情報の使い方
4.3　サーバー変更管理のモデル
4.3.1　随時変更
4.3.2　構成/設定の同期
4.3.3　イミュータブルインフラストラクチャ
4.3.4　コンテナ化されたサービス
4.4　コンテナ
4.4.1 Rubyアプリケーション管理がコンテナによってどのように変わるか
4.4.2　コンテナは仮想マシンか
4.4.3　仮想マシンよりもコンテナ
4.4.4　コンテナの実行
4.4.5　コンテナのセキュリティ
4.5　まとめ
5章　主要なインフラストラクチャサービス
5.1　インフラストラクチャサービス、ツールが満たすべき条件
5.1.1　外部定義を使えるツールを選ぶ
5.1.2　インフラストラクチャがダイナミックだという前提で作られたツールを選ぶ
5.1.3　ライセンスがクラウド互換になっている製品を選ぶ
5.1.4　疎結合をサポートする製品を選ぶ
5.2　チーム間でのサービスの共有
5.2.1　サービスインスタンステンプレート
5.3　モニタリング：アラート、計測、ロギング
5.3.1　アラート：何かまずいことが起きたら教えてくれ
5.3.2　指標計測：データの収集と分析
5.3.3　ログの集約と分析
5.4　サービスディスカバリ
5.4.1　サーバーサイドサービスディスカバリのパターン
5.4.2　クライアントサイドサービスディスカバリのパターン
5.5　分散プロセス管理
5.5.1　サーバーロールによるプロセスのオーケストレーション
5.5.2　コンテナによるプロセスのオーケストレーション
5.5.3　短いジョブのスケジューリング
5.5.4　コンテナオーケストレーションツール
5.6　ソフトウェアのデプロイ
5.6.1　デプロイパイプラインソフトウェア
5.6.2　ソフトウェアのパッケージング
5.7　まとめ
第Ⅱ部　パターン
6章　サーバーのプロビジョニングのパターン
6.1　サーバーのプロビジョニング
6.1.1　サーバーのライフサイクル
6.1.2　サーバーには何が含まれるか
6.1.3　サーバーに含まれるものの分類
6.1.4　サーバーロール
6.2　サーバー作成のパターン
6.2.1　アンチパターン：手作りサーバー
6.2.2　プラクティス：サーバー作成オプションをスクリプトでラッピングせよ
6.2.3　アンチパターン：ホットクローンによって作成されたサーバー
6.2.4　パターン：サーバーテンプレート
6.2.5　アンチパターン：スノーフレークファクトリ
6.3　新サーバーのブートストラップのパターン
6.3.1　プッシュブートストラップ
6.3.2　プルブートストラップ
6.3.3　プラクティス：すべての新サーバーインスタンスをスモークテストせよ
6.4　まとめ
7章　サーバーテンプレート管理のパターン
7.1　ストックテンプレート：ほかに管理してくれる人はいないか？
7.2　テンプレートを使ったサーバーのプロビジョニング
7.2.1　作成時のプロビジョニング
7.2.2　テンプレート内でのプロビジョニング
7.2.3　作成時のプロビジョニングとテンプレートによるプロビジョニングのバランスの取り方
7.3　サーバーテンプレートの構築プロセス
7.3.1　複数のプラットフォームのためのテンプレートの作成
7.4　原始イメージ
7.4.1　アンチパターン：ホットクローンによって作成されたサーバーテンプレート
7.4.2　OSインストレーションイメージからのテンプレートの焼き込み
7.4.3　ストックイメージからのテンプレートの焼き込み
7.4.4　ユニカーネルからのテンプレートの構築
7.4.5　ブートをしないサーバーテンプレートのカスタマイズ
7.5　サーバーテンプレートのアップデート
7.5.1　テンプレートの「温め直し」
7.5.2　フレッシュなテンプレートの焼き込み
7.5.3　サーバーテンプレートのバージョン管理
7.6　ロールのためのテンプレートの構築
7.6.1　パターン：階層化テンプレート
7.6.2　テンプレートのためのベーススクリプトの共有
7.7　サーバーテンプレート管理の自動化
7.7.1　焼き込み前のサーバーのカスタマイズ
7.7.2　プラクティス：サーバーテンプレートを自動テストせよ
7.8　まとめ
8章　サーバーのアップデート/変更のパターン
8.1　サーバー変更管理モデル
8.1.1　随時変更
8.1.2　継続的な構成/設定の同期
8.1.3　イミュータブルサーバー
8.1.4　コンテナ化サーバー
8.2　一般的なパターンとプラクティス
8.2.1　プラクティス：サーバーテンプレートを最小化せよ
8.2.2　プラクティス：サーバーテンプレートの変更時にサーバーを交換せよ
8.2.3　パターン：フェニックスサーバー
8.3　継続的デプロイのパターンとプラクティス
8.3.1　パターン：マスターレス構成管理
8.3.2　プラクティス：cronを利用せよ
8.3.3　継続的同期フロー
8.3.4　構成管理の対象外の部分
8.4　イミュータブルサーバーのパターンとプラクティス
8.4.1　アーティファクトとしてのサーバーイメージ
8.4.2　イミュータブルサーバーによる構成管理ツールの単純化
8.4.3　イミュータブルサーバーのフロー
8.4.4　イミュータブルサーバーのブートストラップ時の構成/設定
8.4.5　サーバーアップデートのトランザクション化
8.5　構成定義管理のプラクティス
8.5.1　プラクティス：構成定義を最小限に抑えよ
8.5.2　定義の構造化
8.5.3　プラクティス：優れた設計を生み出すテスト駆動開発（TDD）を使え
8.6　まとめ
9章　インフラストラクチャ定義のパターン
9.1　環境
9.1.1　アンチパターン：手作りのインフラストラクチャ
9.1.2　インフラストラクチャスタックをコードとして定義する
9.1.3　アンチパターン：環境ごとの定義ファイル
9.1.4　パターン：再利用できる定義ファイル
9.1.5　プラクティス：スタック定義をテスト、プロモートせよ
9.1.6　セルフサービス環境
9.2　インフラストラクチャの構造化
9.2.1　アンチパターン：モノリシックスタック
9.2.2　「リフトアンドシフト」によるインフラのマイグレーションを避ける
9.2.3　アプリケーション環境の複数のスタックへの分割
9.2.4　スタック間での構成/設定パラメータの管理
9.2.5　インフラストラクチャ要素の共有
9.2.6　プラクティス：アプリケーションコードとインフラストラクチャコードを統一的に管理せよ
9.2.7　定義の共有に対するアプローチ
9.2.8　プラクティス：変更の範囲に合わせてインフラストラクチャを設計せよ
9.2.9　実例：マイクロサービスのためのインフラストラクチャ設計
9.3　定義ツールの実行
9.4　まとめ
第Ⅲ部　プラクティス
10章　インフラストラクチャのためのソフトウェア工学プラクティス
10.1　システムの品質
10.1.1　品質の低いシステムは変更が難しい
10.1.2　高品質システムは従来よりも簡単かつ安全に変更できる
10.1.3　インフラストラクチャの品質の着目点
10.1.4　高速フィードバック
10.2　インフラストラクチャ管理のためのVCS
10.2　.1 VCSで管理すべきもの
10.3　継続的インテグレーション（CI）
10.4　継続的なブランチのテストは継続的インテグレーションではない
10.4.1　ビルドエラーの原因究明
10.4.2　失敗したテストの無視
10.4.3　インフラストラクチャのためのCI
10.5　継続的デリバリー（CD）
10.5.1　インテグレーション段階の問題点
10.5.2　デプロイパイプラインと変更パイプライン
10.5.3　継続的デリバリーは継続的デプロイではないということ
10.6　コードの品質
10.6.1　クリーンコード
10.6.2　プラクティス：技術的負債をマネジメントせよ
10.7　大きなインフラストラクチャ変更の管理
10.7.1　機能トグル
10.8　まとめ
11章　インフラストラクチャの変更のテスト
11.1　テストに対するアジャイルのアプローチ
11.1.1　高速フィードバックのためのテストの自動化
11.1.2　テストスイートの有機的な構築
11.2　テストスイートの構造化：テストピラミッド
11.2.1　バランスの悪いテストスイートにならないようにするために
11.2.2　プラクティス：できる限り低い水準でテストせよ
11.2.3　プラクティス：必要な階層だけを実装せよ
11.2.4　プラクティス：テストスイートをひんぱんに刈り込め
11.2.5　プラクティス：テストの有効性を継続的に評価せよ
11.3　バランスの取れたテストスイートの実装
11.3.1　低水準テスト
11.3.2　中水準テスト
11.3.3　高水準テスト
11.3.4　運用品質のテスト
11.4　テストコードの管理
11.4.1　プラクティス：テストコードとテスト対象のコードをいっしょに管理せよ
11.4.2　アンチパターン：反射的テスト
11.4.3　テストのためのコンポーネントの切り離しのテクニック
11.4.4　コンポーネントを切り離せるようにするためのリファクタリング
11.4.5　外部依存コンポーネントの管理
11.4.6　テストのセットアップ
11.5　テストのロールとワークフロー
11.5.1　原則：構築したものに対するテストは自分で書け
11.5.2　テストを書く習慣
11.5.3　原則：全員がテストツールを使えるようにせよ
11.5　.4 QAアナリストの価値
11.5.5　テスト駆動開発（TDD）
11.6　まとめ
12章　インフラストラクチャの変更管理パイプライン
12.1　変更管理パイプラインのメリット
12.2　パイプライン設計のガイドライン
12.2.1　ステージ間での統一性を保証せよ
12.2.2　すべての変更にすばやくフィードバックを返せ
12.2.3　マニュアルステージの前に自動ステージを実行せよ
12.2.4　できる限り早く本番環境に近い環境でテストせよ
12.3　パイプラインの基本設計
12.3.1　ローカル開発ステージ
12.3.2　ビルドステージ
12.3.3　構成アーティファクトの公開
12.3.4　自動テストステージ
12.3.5　人間による確認/チェックステージ
12.3.6　本番環境への適用
12.3.7　パイプラインのリズム
12.4　パイプラインを使うためのプラクティス
12.4.1　プラクティス：すべての変更で本番対応の品質を証明せよ
12.4.2　プラクティス：すべての変更をパイプラインの先頭からスタートさせよ
12.4.3　プラクティス：失敗が起きたらラインを止めよ
12.5　より複雑なシステムへのパイプラインのスケールアップ
12.5.1　パターン：ファンインパイプライン
12.5.2　プラクティス：パイプラインを短く保て
12.5.3　プラクティス：パイプラインを分割せよ
12.5.4　インテグレーションモデル
12.6　コンポーネントの間の依存関係を処理するテクニック
12.6.1　パターン：ライブラリ依存
12.6.2　パターン：サービスインスタンスのセルフプロビジョニング
12.6.3　プレリリースライブラリのビルドの提供
12.6.4　コンシューマに対するサービスのテストインスタンスの提供
12.6.5　コンシューマとしてサービスのテストインスタンスを利用する
12.7　コンポーネント間のインターフェイスを管理するためのプラクティス
12.7.1　プラクティス：インターフェイスの下位互換性を確保せよ
12.7.2　プラクティス：リリースとデプロイを切り離せ
12.7.3　プラクティス：バージョン耐性を保証せよ
12.7.4　プラクティス：テストダブルを用意せよ
12.7.5　プラクティス：コントラクトテストでプロバイダをテストせよ
12.7.6　プラクティス：参照コンシューマを使ってテストせよ
12.7.7　プラクティス：プロバイダインターフェイスをスモークテストせよ
12.7.8　プラクティス：コンシューマ主導のコントラクト（CDC）テストを実施せよ
12.8　まとめ
13章　インフラストラクチャチームのワークフロー
13.1　動くものは何でも自動化する
13.1.1　手作業による変更
13.1.2　その場しのぎのオートメーション
13.1.3　自律的なオートメーション
13.1.4　自律的なオートメーションのワークフロー
13.2　ローカルサンドボックスの使い方
13.2.1　ローカル仮想化を使ったサンドボックス
13.2.2　ローカルテストのサンプルワークフロー
13.2.3　仮想化プラットフォームを使ったサンドボックス
13.3　コードベースの構造化のパターン
13.3.1　アンチパターン：ブランチを基礎とするコードベース
13.3.2　パターン：コンポーネントごとのトランク
13.3.3　パターン：単一のトランク
13.4　ワークフローの有効性
13.4.1　変更の加速
13.4.2　コードレビュー
13.4.3　ワークフローにガバナンスを組み込む
13.5　まとめ
14章　継続性とダイナミックインフラストラクチャ
14.1　サービスの継続性
14.1.1　本物の可用性
14.1.2　復旧のためのダイナミックサーバープール
14.1.3　ダイナミックインフラストラクチャを意識したソフトウェア設計
14.1.4　継続性のためのコンパートメント化
14.2　ゼロダウンタイム変更
14.2.1　パターン：ブルー-グリーン交換
14.2.2　パターン：フェニックス交換
14.2.3　プラクティス：交換のスコープを絞り込め
14.2.4　パターン：カナリア交換
14.2.5　ゼロダウンタイム交換のためのトラフィックのルーティング
14.2.6　データをともなうゼロダウンタイム変更
14.3　データの継続性
14.3.1　レプリケートによる冗長なデータの生成
14.3.2　データの再生成
14.3.3　データの永続化の委託
14.3.4　永続ストレージへのバックアップ
14.4　ディザスタリカバリ
14.4.1　継続的ディザスタリカバリ
14.4　.2 DRプラン：災害のためのプランニング
14.4.3　プラクティス：コールドスタンバイではなく再構築せよ
14.4.4　パイプラインによる継続的なモニタリング
14.5　セキュリティ
14.5.1　システムブリーチの自動的な消去
14.5.2　防御としての信頼性の高いアップデート
14.5.3　パッケージの出所
14.5.4　ハードニングの自動化
14.5.5　パイプライン内でのセキュリティチェックの自動化
14.5.6　脆弱性としての変更管理パイプライン
14.5.7　クラウドアカウントによるセキュリティリスクのマネジメント
14.6　まとめ
15章　Infrastructure as Codeのための組織
15.1　発展的なアーキテクチャ
15.1.1　実戦演習
15.1　.2 Trailblazerパイプラインから始める
15.2　効果測定
15.2.1　求める結果について合意を得ることを優先する
15.2.2　チームのために役立つ指標を選択する
15.2.3　リードタイムの監視と改善
15.2.4　カンバンを使った仕事の可視化
15.2.5　レトロスペクティブとポストモーテム
15.3　ユーザーに力を与える組織
15.3.1　職能分割モデルの落とし穴
15.3.2　セルフサービスモデルを採り入れる
15.3.3　完全な責任を引き受ける：構築するのも運用するのも同じチーム
15.3.4　職能横断型チームの組織
15.4　継続的変更管理を通じたガバナンス
15.4.1　信頼できる部品の供給
15.4.2　パイプラインによる運用準備完了の証明
15.4.3　品質に対する責任の共有
15.4.4　自動プロセスのレビューと監査
15.4.5　問題点を検出、是正するための時間の短縮化
15.5　まとめ：決して終わりはない
索引