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

1章なぜTerraformを使うのか

ソフトウェアは、コードがあなたのコンピュータ上で動けば完成ではありません。テストが通った時に完成でもありません。ましてやコードレビューで「Ship it」（リリースしてよし）と誰かに言われたから完成というわけでもありません。ソフトウェアは、ユーザに届ける（deliver）までは完成とは言えません。

ソフトウェアデリバリとは、コードを本番サーバ上で動かしたり、障害やトラフィックのスパイクに対してコードが弾力性を持つ状態にしたり、コードを攻撃者から守ったりすることを含み、顧客がコードを利用可能にするあらゆる作業のことを言います。Terraformの詳しい内容に飛び込む前に、ソフトウェアデリバリの全体像のどこにTerraformが合うのか、1歩引いて見てみる価値があります。

この章では、以下の内容を詳しく見ていきます。

DevOpsとは何か
Infrastructure as Codeとは何か
Infrastructure as Codeの利点
Terraformの仕組み
他のInfrastructure as CodeのツールとTerraformの比較

1.1　DevOpsとは何か

もしあなたがそれほど遠くない過去にソフトウェアの会社を作ろうとしたなら、あなたは多くのハードウェアも管理する必要がありました。つまり、キャビネットやラックを準備し、その上にサーバを置き、ケーブルを接続し、空調設備を取り付け、冗長化電源システムを作るといったことです。そのため、いわゆる開発者（Dev）と呼ばれるソフトウェアを書くことに専念するチームと、それとは別のいわゆる運用者（Ops）と呼ばれるハードウェアを管理するチームをそれぞれ作るのは理にかなっていました。 ...