コンテンツにスキップ

patternモジュールを適用する

本ページでは、Getting Started(本リポジトリ)をどのような順番で実行していくのか、その適用順を記載します。

概要

ここでは、以下の2つの環境を構築します。

各ディレクトリ内には、patternモジュールを適用したTerraform構成ファイルが含まれています。

本ページでは、各ディレクトリ内で行う操作の基本と、各ディレクトリの適用順を説明します。

前提条件

セットアップに記載の手順を実行しており、Terraformを実行するためのユーザーの作成などの作業が完了している必要があります。

また、AWSアカウントやSaaSとの契約などの前提条件を満たしているかも再確認してください。

Terraform実行ユーザーに関するポイント

本リポジトリ内に含まれてるTerraform構成ファイルを適用する際には、ディレクトリに応じてIAMユーザーを切り替える必要があります。

セットアップで、Terraformを実行するためのIAMユーザーを作成しているはずです。

各ディレクトリとユーザーの対応は、以下のようになります。

  • deliveryディレクトリ配下 … Delivery環境用のTerraform実行IAMユーザーを使用
  • runtimes/stagingディレクトリ配下 … Runtime環境用のTerraform実行IAMユーザーを使用

セットアップが完了していても、ディレクトリとIAMユーザーの対応を誤った場合はTerraformの実行に失敗します。
これは、Terraform実行用のIAMロールにスイッチできなくなるからです。ご注意ください。

基本的な操作

各ディレクトリ配下では、以下のコマンドを実行するのが基本になります。
それ以外の操作や注意事項がある場合は、各ディレクトリごとに補足します。

init

初回実行時に、1度行います。各ディレクトリ単位で実行が必要です。

$ terraform init

ℹ️ 利用するProviderやモジュールのバージョンアップ時、追加時などは再度initが必要です。

plan

planを実行することにより、これからどのようなリソースが構築されるか、その実行計画を見ることができます。
また、リソースを構築した後にTerraformの構成ファイルを変更してから使用すると、これから変更する差分を見ることができます。

$ terraform plan

実際にリソースを構築する前に、必ずplanで実行計画を確認しましょう。

plan実行時に変数の入力を求められた場合は、実行のために追加の情報が必要です。
このケースにあたるのは、以下のような情報が該当します。対象のpatternのドキュメントを確認し、適切に値を設定してください。

  • 実際の実行時にしかわからない情報(動的に決まる値など)
  • 秘匿すべき情報

apply

planで確認した内容に沿って、実際のリソースを構築します。
また、リソースを構築した後にTerraformの構成ファイルを変更してから使用すると、変更差分を反映できます。

$ terraform apply

destroy

⚠️ 構築済みのリソースを破棄するコマンドです。

applyで構築したリソースを破棄できます。

$ terraform destroy

リソースが不要になった時や、作り直したい時に使用してください。

構築順

環境は、本セクションに記載の順で構築していきます。

cloneされた本リポジトリ内にある、記載のディレクトリ内に移動して基本的な操作で説明したTerraformのコマンドを実行します。

また、 📗 のアイコンがついたディレクトリは実行や確認にあたり、補足を記載しています。
詳しくは各ディレクトリ内のREADME.mdを参照してください。

各項目は、Terraformの構成ファイルが配置されたディレクトリと、その適用元になったpatternのドキュメントの参照を記載しています。

Delivery環境上にCI/CDパイプラインを構築する

Delivery環境に、CIパイプラインを構築します。



CDパイプラインはRuntime環境で起動しますが、ここではその仕掛けを準備します。

Runtime環境にアプリケーションを動作させるための環境を作成する

Runtime環境上に、アプリケーションを動作させるための環境を揃えます。



データベースやキャッシュ、コンテナ環境やオブジェクトストレージなどを構築します。この時点では、まだアプリケーションはデプロイされません。

Runtime環境にアプリケーションのCDパイプラインを構築する

Runtime環境に、CDパイプラインを構築します。



ここで構築したリソースの情報は、Delivery環境へ連携する必要があります。

Delivery環境にアプリケーションのCDパイプラインを起動する仕組みを構築する

Delivery環境に、CDパイプラインを起動する仕組みを構築します。



ここで行う作業は、構築済みのリソースのアップデートになります。

この後、CIパイプラインを起動させることで、アプリケーションがデプロイ可能となります。 CIパイプラインを起動する方法についてはパイプラインを実行するを参照してください。

CIパイプラインが実行されると、CDパイプラインによってアプリケーションのデプロイが実行されます。 デプロイの進捗はAWS CodePipelineで確認してください。

デプロイが完了したら、ブラウザでアプリケーションにアクセスしてください。 このとき、URLのホスト名はcacheable_frontendインスタンスのrecord_nameで指定した値になります。 (例:https://chat-example.staging.epona-devops.com/

本手順で構築したexample-chatには、ローカルで動かした場合に用意されているテストユーザは存在しません。 したがって、アプリケーションの動作確認にはサインアップが必要になります。 このとき、メールアドレスにはAmazon SESで検証済みのEメールアドレスを使用してください。

Runtime環境のログとメトリクスをSaaSに収集し、インシデント管理の仕組みを構築する

Runtime環境に、Datadogとのインテグレーションとログ転送の仕組みを導入します。
また、インシデント管理のためPagerDutyとのインテグレーションも行います。



DatadogおよびPagerDutyはpatternモジュールの適用だけではなく、Web UIからの操作も必要になります。
これらに関しては、Eponaのモニタリングに関するHow Toドキュメントを参照してください。

Delivery環境にユーザーを作成する

Delivery環境にIAMユーザーを作成します。また、作成したIAMユーザーをRuntime環境へスイッチできる準備をします。



ℹ️ ここで作成するIAMユーザーは、Terraformの実行ユーザーではありません。
ℹ️ 実際にこの環境を運用する、システムのユーザーが使用することを想定したIAMユーザーです。

Runtime環境にロールを作成する

Runtime環境にロールを作成します。これで、Delivery環境上のIAMユーザーからスイッチが可能になります。



Delivery環境の証跡記録とインフラ変更を記録、第三者による不正アクセスを通知する

Delivery環境における、アカウントの証跡やインフラ変更を記録し、ルール違反や第三者による不正アクセスがあった場合は通知できるようにします。



Runtime環境の証跡やインフラ変更を記録、第三者による不正アクセスを通知する

Runtime環境における、アカウントの証跡やインフラ変更を記録し、ルール違反や第三者による不正アクセスがあった場合は通知できるようにします。



ℹ️ rule_violation, threat_detection適用後、これらのログ収集を行う場合はdatadog_log_triggerの再実行が必要です。依存箇所を修正して再実行してください。

Runtime環境に仮想セキュアルームを設置する

Runtime環境に、運用中の本番アクセス用に仮想セキュアルームを設置します。




仮想セキュアルームから構築済みのリソースへアクセスするためには、セキュリティグループを更新する必要があります。 構築済みAWSリソースのセキュリティグループのインバウンドにWorkSpacesのセキュリティグループを設定するようにモジュールを再適用します。

以下のpatternについて、Runtime環境にアプリケーションを動作させるための環境を作成するでコメントアウトしていた*1部分をコメントインして再適用します。

Runtime環境で稼働しているシステムのビジネス指標を可視化する仕組みを構築する

Runtime環境に、ビジネス指標可視化のためのAmazon QuickSightからVPC内のRDSを参照するための仕組みを導入します。

⚠️ VPC内のRDSと、Amazon QuickSightでEnterpriseを選択する必要があります。




QuickSightから構築済みのリソースへアクセスするためには、セキュリティグループを更新する必要があります。 構築済みAWSリソースのセキュリティグループのインバウンドにQuickSight用のセキュリティグループを設定するようにモジュールを再適用します。

以下のpatternについて、Runtime環境にアプリケーションを動作させるための環境を作成するでコメントアウトしていた*2部分をコメントインして再適用します。

また、Amazon QuickSightはpatternモジュールの適用だけではなく、Web UIからの操作も必要になります。
こちらに関しては、QuickSightに関するHow Toドキュメントを参照してください。

Runtime環境にAPIを構築する

Runtime環境に、REST APIアプリケーションを作成・公開します。
必要に応じて実行してください。


applyが完了したら、アプリケーションにアクセスしてください。 このとき、URLのホスト名はapi_gatewayの custom_domains で設定した値になります。
(例:https://api-example.epona-devops.com/staging/)

本手順で構築するアプリケーションは、書籍に関する情報(ID、タイトル、価格など)を登録・確認するような簡易なアプリケーションです。 このアプリケーションには以下のAPIが含まれます。

  • 固定レスポンス
    • URL: https://api-example.epona-devops.com/staging/
    • メソッド: GET
  • 一覧取得
    • URL: https://api-example.epona-devops.com/staging/books/
    • メソッド: GET
  • 1件登録
    • URL: https://api-example.epona-devops.com/staging/books/
    • メソッド: POST
    • Lambdaオーソライザーによる認証あり
  • idを指定して1件取得
    • URL: https://api-example.epona-devops.com/staging/books/{id}
    • メソッド: GET

1件登録のAPIには、Lambdaオーソライザーが設定されています。
ヘッダーのauthorizer_tokenに設定した文字列で認証する簡易なものです。 APIを実行するためにはauthorizer_tokenallowを設定してください。

以下はコマンドのサンプルです。

# 認証成功
$ curl -X POST -H "Content-Type: application/json" -H "authorizer_token: allow" -d '{"id":"101", "title":"book-title101", "price": "4980"}' https://api-example.epona-devops.com/staging/books/
{}

# 認証失敗
$ curl -X POST -H "Content-Type: application/json" -H "authorizer_token: deny" -d '{"id":"101", "title":"book-title101", "price": "4980"}' https://api-example.epona-devops.com/staging/books/
{"Message":"User is not authorized to access this resource with an explicit deny"}

Delivery/Runtime環境にサーバーレスアプリケーションのCI/CDパイプラインを構築する

Delivery/Runtime環境に、CI/CDパイプラインを起動する仕組みを構築します。
必要に応じて実施してください。

Runtime環境にワークフローを構築する

AWS Step Functions により、ワークフローを構築します。
必要に応じて実行してください。


本手順で構築するワークフローは、特定のS3バケットへのファイルアップロードをトリガーとして以下の処理を実行する簡易なワークフローです。

  • S3バケットからCSVファイルを取得する
  • CSVファイルのデータを1行ずつJSONに変換する
  • 変換結果を出力用S3にJSON Linesファイルとして出力する
  • ワークフローが正常終了した場合Microsoft Teams、Slackに通知を送信する
inputのCSV例
id,title,price
101,book1-title,3000
201,book2-title,4800

上記inputを変換後のoutput
{"id":"101","title":"book1-title","price":"3000"}
{"id":"201","title":"book2-title","price":"4800"}

runtimes/staging/lambda_step_functions/get_csvで作成するLambda関数はNode.jsで記述しています。
terraform applyを実行する前に、npmライブラリのインストールが必要です。
runtimes/staging/lambda_step_functions/get_csv/nodenpm installを実行してください。

applyが完了したら、ワークフローを実行してください。
runtimes/staging/lambda_step_functions/get_csvで作成したS3バケットがトリガーになっています。
このS3バケット(バケット名:epona-sfn-input-csv)にファイルをアップロードすることでワークフローが起動します。
テスト用のCSVファイルは step_functions パターンを適用したTerraform構成ファイルと同じディレクトリに配置しています。
以下はaws-cliを使用してトリガーとなるS3バケットへファイルをアップロードするコマンドのサンプルです。

$ aws s3 cp test_data.csv s3://epona-sfn-input-csv

CSVファイルをアップロードすると、作成したワークフローが起動します。ワークフローの状態は、マネジメントコンソールから確認できます。
ワークフローが正常終了すると、変換後のJSON Linesファイルが別のS3バケットに出力されます。 以下はaws-cliを使用してS3バケットから変換後のJSON Linesファイルをダウンロードするコマンドのサンプルです。

$ aws s3 cp s3://epona-sfn-output-json/output_data.jsonl ./

この後は

ここまで実践してきた環境構築、学んできたpatternモジュールを使い、自分たちのサービスを作るための環境を構築してみましょう。
本リポジトリは、その時の参考となるでしょう。


※ このドキュメントはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。

※ このドキュメントに記載されている会社名、製品名は、各社の登録商標または商標です。

© 2021 TIS Inc.