book

詳解 Terraform 第3版 ―Infrastructure as Codeを実現する

by Yevgeniy Brikman, 松浦隼人

November 2023

Intermediate to advanced

472 pages

7h 12m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

　　　　バージョンについて
　　1.1　DevOpsとは何か　　1.2　Infrastructure as Codeとは何か　　　1.2.1　アドホックなスクリプト　　　1.2.2　設定管理ツール　　　1.2.3　サーバテンプレーティングツール　　　1.2.4　オーケストレーションツール　　　1.2.5　プロビジョニングツール　　1.3　Infrastructure as Codeの利点とは　　1.4　Terraformはどう動くのか　　1.5　Terraformと他のIaCツールとはどう違うのか　　　1.5.1　設定管理ツールか、プロビジョニングツールか　　　1.5.2　ミュータブルなインフラか、イミュータブルなインフラか　　　1.5.3　手続き型言語か、宣言型言語か　　　1.5.4　汎用言語かドメイン特化言語か　　　1.5.5　マスタか、マスタレスか　　　1.5.6　エージェントか、エージェントレスか　　　1.5.7　有償か、無償か　　　1.5.8　大きなコミュニティか、小さなコミュニティか　　　1.5.9　成熟か、最先端か　　　1.5.10　複数のツールの組み合わせ　　　　1.5.10.1　プロビジョニングと設定管理の組み合わせ　　　　1.5.10.2　プロビジョニングとサーバテンプレーティングの組み合わせ　　　　1.5.10.3　プロビジョニング、サーバテンプレーティング、オーケストレーションの組み合わせ　　1.6　まとめ
　　2.1　AWSアカウントのセットアップ　　2.2　Terraformのインストール　　2.3　サーバ1台のデプロイ　　2.4　Webサーバ1台のデプロイ　　2.5　設定変更可能なWebサーバのデプロイ　　2.6　Webサーバのクラスタのデプロイ　　2.7　ロードバランサのデプロイ　　2.8　後片付け　　2.9　まとめ
　　3.1　Terraformステートとは　　3.2　ステートファイルの共有ストレージ　　3.3　Terraformバックエンドの制限　　3.4　ステートファイルの分離　　　3.4.1　ワークスペースによる分離　　　3.4.2　ファイルレイアウトによる分離　　3.5　terraform_remote_stateデータソース　　3.6　まとめ
　　4.1　モジュールの基本　　4.2　モジュールの入力　　4.3　モジュールのローカルな値　　4.4　モジュールの出力　　4.5　モジュールの注意点　　　4.5.1　ファイルパス　　　4.5.2　インラインブロック　　　　ネットワークの分離　　4.6　モジュールのバージョン管理　　4.7　まとめ
　　5.1　ループ　　　5.1.1　countパラメータによるループ　　　5.1.2　for_each式によるループ　　　　タグに関するルールを強制する　　　5.1.3　for式によるループ　　　5.1.4　forの文字列ディレクティブを使ったループ　　5.2　条件分岐　　　5.2.1　countパラメータを使った条件分岐　　　　5.2.1.1　countパラメータを使ったif文　　　　5.2.1.2　countパラメータを使ったif-else文　　　5.2.2　for_eachとforを使った条件分岐　　　5.2.3　if文字列ディレクティブを使った条件分岐　　5.3　ゼロダウンタイムデプロイ　　5.4　Terraformのつまずきポイント　　　5.4.1　countとfor_eachの制限事項　　　5.4.2　ゼロダウンタイムデプロイの制限事項　　　5.4.3　有効なプランも失敗することがある　　　5.4.4　リファクタリングは難しい　　5.5　まとめ

　　6.1　シークレット管理の基本　　6.2　シークレット管理ツール　　　6.2.1　保存するシークレットの種類　　　6.2.2　シークレットの保存方法　　　6.2.3　シークレットにアクセスするインタフェイス　　　6.2.4　シークレット管理ツールの比較　　6.3　シークレット管理ツールとTerraform　　　6.3.1　プロバイダ　　　　6.3.1.1　人のユーザ　　　　6.3.1.2　マシンユーザ　　　　　CIサーバとしてのCircleCI（シークレットを保存）　　　　　JenkinsをCIサーバとして動かすEC2インスタンス（IAMロールを使用）　　　　　CIサーバとしてのGitHub Actions（OIDC使用）　　　6.3.2　リソースとデータソース　　　　6.3.2.1　環境変数　　　　6.3.2.2　暗号化されたファイル　　　　6.3.2.3　シークレットストア　　　6.3.3　ステートファイルとプランファイル　　　　6.3.3.1　ステートファイル　　　　6.3.3.2　プランファイル　　6.4　まとめ
　　7.1　1つのプロバイダを使う　　　7.1.1　プロバイダとは何か　　　7.1.2　プロバイダをどのようにインストールするのか　　　7.1.3　プロバイダをどのように使うのか　　7.2　同じプロバイダのコピーを複数使う　　　7.2.1　複数のAWSリージョンを使う　　　7.2.2　複数のAWSアカウントを使う　　　1つのメールアドレスで複数のエイリアスを使う方法　　　7.2.3　複数のプロバイダを使えるモジュールを作る　　7.3　異なる複数のプロバイダを使う　　　7.3.1　Docker短期集中コース　　　7.3.2　Kubernetes短期集中コース　　　7.3.3　Elastic Kubernetes Service（EKS）を使ったAWSへのDockerコンテナのデプロイ　　7.4　まとめ
　　8.1　本番レベルのインフラを構築するのに時間がかかる理由　　8.2　本番レベルのインフラのチェックリスト　　8.3　本番レベルのインフラモジュール　　　8.3.1　小さなモジュール　　　8.3.2　組み合わせ可能なモジュール　　　8.3.3　テスト可能なモジュール　　　　8.3.3.1　バリデーション　　　　8.3.3.2　事前条件と事後条件　　　　8.3.3.3　バリデーション、事前条件、事後条件の使い時　　　8.3.4　バージョン管理されたモジュール　　　8.3.5　Terraformモジュールの先へ　　　　8.3.5.1　プロビジョナ　　　　プロビジョナとユーザーデータ　　　　8.3.5.2　null_resourceとプロビジョナ　　　　8.3.5.3　外部データソース　　8.4　まとめ
　　9.1　手動テスト　　　9.1.1　手動テストの基礎　　　9.1.2　テスト後の後片付け　　9.2　自動テスト　　　9.2.1　ユニットテスト　　　　9.2.1.1　Terraformコードのユニットテスト　　　　9.2.1.2　依存性の注入　　　　9.2.1.3　テストを並列に実行する　　　9.2.2　統合テスト　　　　9.2.2.1　テストステージ　　　　9.2.2.2　リトライ　　　9.2.3　E2Eテスト　　　9.2.4　その他のテスト手法　　　　9.2.4.1　静的解析　　　　9.2.4.2　プランを使ったテスト　　　　9.2.4.3　サーバテスト　　9.3　まとめ
　　10.1　チームでInfrastructure as Codeを採用する　　　10.1.1　上司を説得する　　　10.1.2　少しずつ進める　　　10.1.3　学ぶ時間をチームに与える　　10.2　アプリケーションコードのデプロイワークフロー　　　10.2.1　バージョン管理する　　　10.2.2　コードをローカルで実行する　　　10.2.3　コードに変更を加える　　　10.2.4　変更に対するレビューを依頼する　　　10.2.5　自動テストを実行する　　　10.2.6　マージしてリリースする　　　10.2.7　デプロイする　　　　10.2.7.1　デプロイのツール　　　　10.2.7.2　デプロイ戦略　　　　10.2.7.3　デプロイサーバ　　　　10.2.7.4　環境間の昇格　　10.3　インフラコードのデプロイワークフロー　　　10.3.1　バージョン管理する　　　　10.3.1.1　liveリポジトリとmodulesリポジトリ　　　　10.3.1.2　Terraformの黄金則　　　　10.3.1.3　ブランチによるトラブル　　　10.3.2　コードをローカルで実行する　　　10.3.3　コードに変更を加える　　　10.3.4　変更に対するレビューを依頼する　　　　10.3.4.1　ドキュメント　　　　10.3.4.2　自動テスト　　　　10.3.4.3　ファイルレイアウト　　　　10.3.4.4　スタイルガイド　　　10.3.5　自動テストを実行する　　　10.3.6　マージしてリリースする　　　10.3.7　デプロイする　　　　10.3.7.1　デプロイのツール　　　　10.3.7.2　デプロイ戦略　　　　10.3.7.3　デプロイサーバ　　　　10.3.7.4　環境間の昇格　　10.4　すべてを組み合わせよう　　10.5　まとめ
　　A.1　書籍　　A.2　ブログ　　A.3　講演　　A.4　ニュースレター　　A.5　オンラインフォーラム

Content preview from 詳解 Terraform 第3版 ―Infrastructure as Codeを実現する

8章本番レベルのTerraformコード

本番レベルのインフラを構築するのは、難しく、緊張が多く、時間がかかります。本番レベルのインフラとは、あなたの会社の運命を任せられる種類のインフラであるという意味です。トラフィックが増えても落ちないインフラ、障害があってもデータが消えないインフラ、ハッカーが侵入しようとしてもデータ漏洩を許さないインフラ、にあなたは運命を任せます。もしその賭けが外れたなら、あなたの会社は倒産してしまうかもしれません。この章における本番レベルのインフラとは、そういうことです。

私はたくさんの企業と働く機会に恵まれましたが、これらすべての経験を元に考えた、次の本番レベルのインフラプロジェクトがどのくらいの期間を要するかの大まかな目安は次のとおりです。

AWS Relational Database Service（RDS）を使ったMySQLのような、サードパーティの完全にマネージドなサービスをデプロイする場合、本番環境でサービスが使用できるようにするまで1週間から2週間。
ローカルに一切データを保存しない（全データをRDSに保存するなど）Node.jsのクラスタなどステートレスな分散アプリケーションをAWS Auto Scalingグループ（ASG）上で動かすなら、およそ2倍、つまり2週間から4週間。
ASG上で動作しローカルディスクにデータを保存するElasticsearchクラスタのようなステートフルな分散アプリケーションを自前で動かすなら、1桁違う時間、つまり本番環境で使用できるようにするまでおよそ2か月から4か月。
アプリケーション、データストア、ロードバランサ、監視、アラート、セキュリティなどすべてのアーキテクチャを構築するなら、さらに1桁あるいは2桁違う時間、つまり6か月から36か月。小さな会社なら通常6か月に近い期間、大企業なら通常数年。 ...