自動テスト可能なインフラストラクチャの実装および運用を行うための Terraform プロジェクトのサンプルで、クラウドサービスはGoogle Cloudを使用しています。
なお現時点でこのインフラプロジェクトはプロトタイプ版であるため、コード利用の際は処理内容などを精査した上で利用してください。
このリポジトリ内で使用される環境変数は、それぞれ以下のような意味となっています。
| 変数名 | 説明 |
|---|---|
| SERVICE | インフラ構築対象のサービス名あるいはプロダクト名で 23 文字以内必須。 このプロジェクトでは infra-testing-google-sample(実際には存在しないサービス)としている。 |
| ENV | サービスの開発/運用が行われる環境の名前。 詳細は下記 環境参照。 |
| PROJECT(_ID) | 各環境に紐づく Google Cloud プロジェクトの名前。 このインフラプロジェクトでは $SERVICE-$ENVのルールで命名していて、prod 環境の場合はinfra-testing-google-sample-prodとなる 。なお Google Cloud のプロジェクト名は 30 文字であるためこのプロジェクト名は実際には使用できない。 |
infra-testing-google-sample サービスで使用する環境は、prod、stg、test、sbx-eの 4 種類を想定しています。
各環境の詳細は以下のようになります。
| 環境 | CIDR | 説明 |
|---|---|---|
| prod | 10.1.0.0/16 | infra-testing-google-sample サービスの本番環境。 |
| stg | 10.2.0.0/16 | infra-testing-google-sample サービスの staging 環境。 |
| test | 10.3.0.0/16 | infra-testing-google-sample サービスの CI 専用テスト実行環境。 |
| sbx-e | 10.4.0.0/16 | infra-testing-google-sample サービスの個人開発用(sandbox)環境。 所有者を識別するためのサフィックスを sbx の後に付与する。 例として開発者が erueru-tech の場合、sbx-e となる。 |
現時点でこのリポジトリのコードは、あくまでコードサンプルの公開のみを目的としていて、実際に動作させることは想定していません。
それでも個人環境で動作検証を行いたい場合は、scripts/README.mdの手順を参考に Google Cloud プロジェクトのセットアップを完了させてください。
(※)以下で説明されているコマンドを実行すると課金が発生する点にご注意ください。
以降の説明で実行するすべてのスクリプトは以下の環境変数を必要としているため、あらかじめ定義します。
(あくまで説明を簡単にするためで、実際の開発では意図しない環境にコマンドが実行される可能性があるため、推奨されません)
export TF_VAR_service=infra-testing-google-sample
export TF_VAR_env=sbx-e手動テストを行うための環境を構築するために、まず初めに environments ディレクトリ内にある sandbox 環境用の tier1 ディレクトリ内に定義されているモジュールやリソースを作成します。
tier1 には Google Cloud のサービス API の有効化の設定や、VPC などのネットワーク設定といった基本的に destroy を行わないようにしたいモジュールやリソースを定義していて、以下のコマンドでプロビジョニングを行います。
$ cd /path/to/infra-testing-google-sample/terraform/environments/sbx/tier1
$ ./apply.sh
...
# applyを実行するか確認されるので'yes'を入力以上で API の有効化と VPC などのネットワークリソースの作成が完了します。
次に tier2 ディレクトリ内に定義されているリソースを作成します。
tier2 には test 環境や sandbox 環境でコストの面から常時稼働させたくない、かつ destroy を行なっても問題ないモジュールやリソースを定義しています。
リソースの作成は以下のコマンドで行います。
$ cd ../tier2
$ ./apply.sh手動テストが完了して、リソースが不要になった場合は以下のコマンドで破棄を行います。
$ ./destroy.sh
...
# destroyを実行するか確認されるので'yes'を入力Terraform モジュールに対して自動テストを行う場合は、modules ディレクトリ配下の各モジュールのディレクトリ内で test.sh を実行します。
例として、network モジュールに対するテスト実行は以下のコマンドで行います。
$ cd /path/to/infra-testing-google-sample/terraform/modules/network
$ ./test.shtest.sh ではテストが完了するとリソースが自動的に削除されてしまうため、GCP コンソールなどからモジュールの作成状態を確認するなど手動でテストしたい場合は apply_destroy.sh を使用します。
$ ./apply_destroy.sh applyテストが完了したら、以下のコマンドでモジュールのリソースをクリーンアップします。
$ ./apply_destroy.sh destroyこのプロジェクトの開発では以下のツールを利用しています。
- tfenv v3.0.0
- TFLint 0.54.0
- pre-commit v4.0.1
- OPA v1.0.0
- Regal v0.29.2
- Conftest v0.56.0
- Trivy v0.51.1
- jq jq 1.7.1
- yq v4.44.6
各ツールのインストール手順は公式ドキュメントを参照してください。
このプロジェクトではセマンティックバージョンを採用しています。
基本的には機能を追加するたびにマイナーバージョンを更新して、のちにバグや訂正項目が見つかった場合にはパッチバージョンを更新します。
なお、メジャーバージョンはこのプロジェクトのコンセプトが現実のサービスに対して適用可能であることを確認できた場合に更新されます。
(まずあり得ないとは思うものの、)現時点では設計方針が大幅に変更され続ける可能性なども踏まえて、申し訳ありませんがコントリビューションは現在受け付けておりません。
それとは別に、もし何か重大なバグや設計上の問題などを発見した方は Issue などを作成していただければ幸いです。
(返答に時間がかかる点についてはご容赦ください)
このリポジトリのライセンスは MIT であるため、改変、再配布、商用利用等は基本的に自由となります。
このリポジトリ内のあらゆるソースコードの利用によって不利益を被った場合におきましても、その不利益に関して一切の責任を負いかねます。
設計に関する詳細はブログなどで公開していますので、興味のある方はそちらを確認してください。