book

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

by Kief Morris, 宮下剛輔, 長尾高弘

March 2017

Intermediate to advanced

352 pages

9h 3m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

1.1 なぜInfrastructure as Codeなのか
1.2.1 Infrastructure as Codeの目標
1.3.1 サーバースプロール1.3.2 構成ドリフト1.3.3 スノーフレークサーバー1.3.4 脆いインフラストラクチャ1.3.5 オートメーション恐怖症
1.4 Infrastructure as Codeの原則1.4.1 簡単に再現できるシステム1.4.2 使い捨てにできるシステム1.4.3 統一的なシステム1.4.4 反復できるプロセス1.4.5 絶えず変化するデザイン

1.5.1 定義ファイルの利用1.5.2 自己記述システムとプロセス1.5.3 あらゆるものをバージョン管理する1.5.4 継続的テストシステム、プロセス1.5.5 一斉変更ではなく小刻みな変更1.5.6 継続的にサービスを利用可能状態に保つ
1.6.1 アンチフラジャイルなITシステムの秘密の成分
1.8 このあとの章について
2.1 ダイナミックインフラストラクチャプラットフォームとは何か
2.2.1 プログラマブル2.2.2 オンデマンド
2.3 プラットフォームから提供されるインフラストラクチャリソース2.3.1 計算リソース2.3.2 ストレージリソース2.3.3 ネットワークリソース
2.4.1 パブリッククラウドのIaaS2.4.2 コミュニティクラウドのIaaS2.4.3 プライベートクラウドのIaaS2.4.4 アンチパターン：手回し式クラウド2.4.5 ハイブリッド、ミックスクラウド2.4.6 ベアメタルクラウド
2.5.1 パブリックかプライベートか2.5.2 クラウドのポータビリティ
3.1.1 要件：スクリプトで操作できるインターフェイス3.1.2 要件：コマンドラインツールの無人モード3.1.3 要件：無人実行のサポート3.1.4 要件：設定の外在化
3.3 インフラストラクチャ定義ツールの操作3.3.1 手続き型スクリプトによるインフラストラクチャのプロビジョニング3.3.2 インフラストラクチャの宣言的な定義3.3.3 インフラストラクチャ定義ツールの使い方3.3.4 サーバーの構成/設定
3.4.1 軽い構成レジストリ3.4.2 構成レジストリはCMDBか3.4.3 CMDBの監査、修正のアンチパターン
3.5 まとめ
4.1 自動化されたサーバー管理の目標
4.2.1 サーバー作成のためのツール4.2.2 サーバーの構成/設定のためのツール4.2.3 サーバーテンプレートのパッケージングのためのツール4.2.4 サーバー上でコマンドを実行するためのツール
4.2.5 中央のレジストリに格納されている構成/設定情報の使い方
4.3.1 随時変更4.3.2 構成/設定の同期4.3.3 イミュータブルインフラストラクチャ
4.4 コンテナ (1/2)4.4.1 Rubyアプリケーション管理がコンテナによってどのように変わるか4.4.2 コンテナは仮想マシンか4.4.3 仮想マシンよりもコンテナ
4.4.4 コンテナの実行4.4.5 コンテナのセキュリティ
5.1 インフラストラクチャサービス、ツールが満たすべき条件
5.1.2 インフラストラクチャがダイナミックだという前提で作られたツールを選ぶ5.1.3 ライセンスがクラウド互換になっている製品を選ぶ5.1.4 疎結合をサポートする製品を選ぶ
5.2.1 サービスインスタンステンプレート
5.3.1 アラート：何かまずいことが起きたら教えてくれ5.3.2 指標計測：データの収集と分析
5.4 サービスディスカバリ5.4.1 サーバーサイドサービスディスカバリのパターン5.4.2 クライアントサイドサービスディスカバリのパターン
5.5.1 サーバーロールによるプロセスのオーケストレーション5.5.2 コンテナによるプロセスのオーケストレーション5.5.3 短いジョブのスケジューリング
5.6 ソフトウェアのデプロイ5.6.1 デプロイパイプラインソフトウェア5.6.2 ソフトウェアのパッケージング
6.1.1 サーバーのライフサイクル
6.1.3 サーバーに含まれるものの分類6.1.4 サーバーロール
6.2.1 アンチパターン：手作りサーバー6.2.2 プラクティス：サーバー作成オプションをスクリプトでラッピングせよ6.2.3 アンチパターン：ホットクローンによって作成されたサーバー6.2.4 パターン：サーバーテンプレート
6.3 新サーバーのブートストラップのパターン6.3.1 プッシュブートストラップ6.3.2 プルブートストラップ6.3.3 プラクティス：すべての新サーバーインスタンスをスモークテストせよ
7.1 ストックテンプレート：ほかに管理してくれる人はいないか？
7.2.1 作成時のプロビジョニング7.2.2 テンプレート内でのプロビジョニング7.2.3 作成時のプロビジョニングとテンプレートによるプロビジョニングのバランスの取り方
7.3.1 複数のプラットフォームのためのテンプレートの作成
7.4.1 アンチパターン：ホットクローンによって作成されたサーバーテンプレート7.4.2 OSインストレーションイメージからのテンプレートの焼き込み7.4.3 ストックイメージからのテンプレートの焼き込み7.4.4 ユニカーネルからのテンプレートの構築7.4.5 ブートをしないサーバーテンプレートのカスタマイズ
7.5.1 テンプレートの「温め直し」7.5.2 フレッシュなテンプレートの焼き込み7.5.3 サーバーテンプレートのバージョン管理
7.6.1 パターン：階層化テンプレート7.6.2 テンプレートのためのベーススクリプトの共有
7.7.1 焼き込み前のサーバーのカスタマイズ
7.8 まとめ
8.1.1 随時変更8.1.2 継続的な構成/設定の同期8.1.3 イミュータブルサーバー8.1.4 コンテナ化サーバー
8.2.1 プラクティス：サーバーテンプレートを最小化せよ8.2.2 プラクティス：サーバーテンプレートの変更時にサーバーを交換せよ
8.3 継続的デプロイのパターンとプラクティス (1/2)8.3.1 パターン：マスターレス構成管理8.3.2 プラクティス：cronを利用せよ8.3.3 継続的同期フロー8.3.4 構成管理の対象外の部分
8.4.1 アーティファクトとしてのサーバーイメージ8.4.2 イミュータブルサーバーによる構成管理ツールの単純化8.4.3 イミュータブルサーバーのフロー8.4.4 イミュータブルサーバーのブートストラップ時の構成/設定
8.5 構成定義管理のプラクティス8.5.1 プラクティス：構成定義を最小限に抑えよ8.5.2 定義の構造化
8.6 まとめ
9.1.1 アンチパターン：手作りのインフラストラクチャ9.1.2 インフラストラクチャスタックをコードとして定義する9.1.3 アンチパターン：環境ごとの定義ファイル9.1.4 パターン：再利用できる定義ファイル9.1.5 プラクティス：スタック定義をテスト、プロモートせよ
9.2 インフラストラクチャの構造化 (1/3)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 実例：マイクロサービスのためのインフラストラクチャ設計
10.1.1 品質の低いシステムは変更が難しい10.1.2 高品質システムは従来よりも簡単かつ安全に変更できる10.1.3 インフラストラクチャの品質の着目点10.1.4 高速フィードバック
10.2.1 VCSで管理すべきもの
10.4 継続的なブランチのテストは継続的インテグレーションではない10.4.1 ビルドエラーの原因究明10.4.2 失敗したテストの無視
10.5 継続的デリバリー（CD）10.5.1 インテグレーション段階の問題点10.5.2 デプロイパイプラインと変更パイプライン10.5.3 継続的デリバリーは継続的デプロイではないということ
10.6.1 クリーンコード
10.7 大きなインフラストラクチャ変更の管理10.7.1 機能トグル
11.1.1 高速フィードバックのためのテストの自動化11.1.2 テストスイートの有機的な構築
11.2.1 バランスの悪いテストスイートにならないようにするために11.2.2 プラクティス：できる限り低い水準でテストせよ11.2.3 プラクティス：必要な階層だけを実装せよ11.2.4 プラクティス：テストスイートをひんぱんに刈り込め11.2.5 プラクティス：テストの有効性を継続的に評価せよ
11.3.1 低水準テスト11.3.2 中水準テスト
11.3.3 高水準テスト11.3.4 運用品質のテスト
11.4.1 プラクティス：テストコードとテスト対象のコードをいっしょに管理せよ11.4.2 アンチパターン：反射的テスト11.4.3 テストのためのコンポーネントの切り離しのテクニック11.4.4 コンポーネントを切り離せるようにするためのリファクタリング11.4.5 外部依存コンポーネントの管理
11.4.6 テストのセットアップ
11.5.1 原則：構築したものに対するテストは自分で書け11.5.2 テストを書く習慣11.5.3 原則：全員がテストツールを使えるようにせよ11.5.4 QAアナリストの価値11.5.5 テスト駆動開発（TDD）
12.2 パイプライン設計のガイドライン12.2.1 ステージ間での統一性を保証せよ12.2.2 すべての変更にすばやくフィードバックを返せ12.2.3 マニュアルステージの前に自動ステージを実行せよ12.2.4 できる限り早く本番環境に近い環境でテストせよ
12.3.1 ローカル開発ステージ12.3.2 ビルドステージ12.3.3 構成アーティファクトの公開12.3.4 自動テストステージ12.3.5 人間による確認/チェックステージ
12.3.6 本番環境への適用12.3.7 パイプラインのリズム
12.4.1 プラクティス：すべての変更で本番対応の品質を証明せよ12.4.2 プラクティス: すべての変更をパイプラインの先頭からスタートさせよ
12.5 より複雑なシステムへのパイプラインのスケールアップ (1/2)12.5.1 パターン：ファンインパイプライン
12.5.2 プラクティス：パイプラインを短く保て12.5.3 プラクティス：パイプラインを分割せよ12.5.4 インテグレーションモデル
12.6.1 パターン：ライブラリ依存12.6.2 パターン：サービスインスタンスのセルフプロビジョニング12.6.3 プレリリースライブラリのビルドの提供12.6.4 コンシューマに対するサービスのテストインスタンスの提供12.6.5 コンシューマとしてサービスのテストインスタンスを利用する
12.7.1 プラクティス：インターフェイスの下位互換性を確保せよ12.7.2 プラクティス：リリースとデプロイを切り離せ12.7.3 プラクティス：バージョン耐性を保証せよ12.7.4 プラクティス：テストダブルを用意せよ12.7.5 プラクティス：コントラクトテストでプロバイダをテストせよ12.7.6 プラクティス：参照コンシューマを使ってテストせよ12.7.7 プラクティス：プロバイダインターフェイスをスモークテストせよ
12.8 まとめ
13.1.2 その場しのぎのオートメーション13.1.3 自律的なオートメーション13.1.4 自律的なオートメーションのワークフロー
13.2.1 ローカル仮想化を使ったサンドボックス13.2.2 ローカルテストのサンプルワークフロー
13.3 コードベースの構造化のパターン13.3.1 アンチパターン：ブランチを基礎とするコードベース13.3.2 パターン：コンポーネントごとのトランク13.3.3 パターン：単一のトランク
13.4.1 変更の加速13.4.2 コードレビュー13.4.3 ワークフローにガバナンスを組み込む
14.1.1 本物の可用性14.1.2 復旧のためのダイナミックサーバープール14.1.3 ダイナミックインフラストラクチャを意識したソフトウェア設計
14.2.1 パターン：ブルー-グリーン交換14.2.2 パターン：フェニックス交換14.2.3 プラクティス：交換のスコープを絞り込め14.2.4 パターン：カナリア交換14.2.5 ゼロダウンタイム交換のためのトラフィックのルーティング
14.2.6 データをともなうゼロダウンタイム変更
14.3.1 レプリケートによる冗長なデータの生成14.3.2 データの再生成14.3.3 データの永続化の委託14.3.4 永続ストレージへのバックアップ
14.4.1 継続的ディザスタリカバリ14.4.2 DRプラン：災害のためのプランニング14.4.3 プラクティス：コールドスタンバイではなく再構築せよ14.4.4 パイプラインによる継続的なモニタリング
14.5.1 システムブリーチの自動的な消去14.5.2 防御としての信頼性の高いアップデート14.5.3 パッケージの出所14.5.4 ハードニングの自動化14.5.5 パイプライン内でのセキュリティチェックの自動化14.5.6 脆弱性としての変更管理パイプライン
14.5.7 クラウドアカウントによるセキュリティリスクのマネジメント
15.1.2 Trailblazerパイプラインから始める
15.2.1 求める結果について合意を得ることを優先する15.2.2 チームのために役立つ指標を選択する15.2.3 リードタイムの監視と改善15.2.4 カンバンを使った仕事の可視化
15.2.5 レトロスペクティブとポストモーテム
15.3.1 職能分割モデルの落とし穴15.3.2 セルフサービスモデルを採り入れる15.3.3 完全な責任を引き受ける：構築するのも運用するのも同じチーム15.3.4 職能横断型チームの組織
15.4.1 信頼できる部品の供給15.4.2 パイプラインによる運用準備完了の証明15.4.3 品質に対する責任の共有15.4.4 自動プロセスのレビューと監査
15.5 まとめ：決して終わりはない