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を実現する

10章チームでTerraformを使う

この本を読み、サンプルコードに取り組む中で、これまであなたは1人で作業してきたはずです。現実の世界では、あなたはチームの一員として働くことがほとんどで、それには数々の新しい挑戦があります。Terraformやその他のInfrastructure as Code（IaC）ツールを使うようチームを説得する必要があるかもしれません。あなたの書いたTerraformコードを理解し、使用し、変更を加えるために複数の人と並列にやり取りする必要があるかもしれません。また、Terraformが他の技術スタックと調和するようにしたり、会社のワークフローの一部として動くようにする必要もあるかもしれません。

この章では、TerraformとIaCがあなたのチームで使用できるようにするために必要な鍵となるプロセスに迫っていきます。

チームでInfrastructure as Codeを採用する
アプリケーションコードのデプロイワークフロー
インフラコードのデプロイワークフロー
すべてを組み合わせてみよう

それでは、1つ1つのトピックについて見ていきましょう。

サンプルコード

繰り返しになりますが、この本のサンプルコードはすべてGitHub（https://github.com/brikis98/terraform-up-and-running-code）で入手できます。

10.1　チームでInfrastructure as Codeを採用する

あなたのチームがインフラのすべてを手動で管理するのに慣れているなら、IaCへの切り替えには単に新しいツールや技術を導入する以上のことが必要になります。チームの文化やプロセスも変える必要があるのです。文化やプロセスを変えるのは一大事業です。大きな会社ではこれはなおさらです。各チームの文化やプロセスは少しずつ違うので、この変化を起こすためにあらゆる場面で使える汎用的な方法はありません。しかし、多くの状況で有益な、いくつかのヒントはあります。 ...