AWS環境の構築 [1] 準備編最終更新日: 2020年7月7日

準備すること

本ガイドは AWS 運用担当者向けに整備した内容となっています。ドメインアプリケーションの運用担当者が Designer から転送処理を行うに、本ガイドの設定を AWS 側に行っておいてください。

ドメイン管理者から入手する情報

AWS管理者は、本ガイドに示す手順を行うにあたって、次の情報をドメイン管理者から入手してください。

  • 用意するドメインアプリケーションのドメインID。例 "app1", "app2"。
  • ドメイン管理者のメールアドレス。

AWS管理者が決めること

作業開始の前に、次の内容を決めておきます。

  • マイクロサービスを運用するドメイン名。例 "wagby.com"。
  • このマイクロサービスに割り当てるサブドメイン名。例 "wmsa"。
  • 各ドメインアプリケーションに割り当てるホスト名を含めたURL。AWSのカスタムドメイン名となる。通常は "ドメインID.マイクロサービスに割り当てたサブドメイン名.組織のドメイン名" となる。これを DNS に登録する。例 "app1.wmsa.wagby.com", "app2.wmsa.wagby.com"。
  • ドメイン管理者に提供する CodeCommit のユーザ名とパスワード。ドメインアプリケーションの数 x 2 (テスト環境,本番環境) が必要。

Code Pipelineについて

AWS管理者は、Designerが提供する「ドメインアプリケーションの転送処理」の実体部分を構築します。図1における Code Pipeline の準備ならびに Elastic Container Service (ECS) の準備が含まれます。

図1 転送イメージ
  • (ドメイン管理者が行う)転送処理により、ビルドされたドメインアプリケーションが CodeCommit へ保存されます。これをトリガーにして CodeBuild と CodeDeploy が行われます。これらを連携させる仕組みを Code Pipeline と呼びます。
  • デプロイは Docker を使います。本ガイド中の「コンテナ」とは Docker コンテナを指します。
  • ビルドしたドメインアプリケーションはコンテナ単位でデプロイします。デプロイ先は ECS です。
  • ドメインアプリケーションの入れ替えはコンテナを順次、更新する Rolling Update 方式です。
  • データベーススキーマの維持管理のために、Wagby が提供するスキーママイグレーション機能を使います。
  • オートスケールの設定と同様、ロードバランサ (LB; Load Balancer) を使います。セキュア通信 (https) の対応は LB が行います。なおロードバランサでは Sticky Session を有効にしません。

2. 利用するサービス一覧

W-MSAでは次のサービスを利用します。

サービス名説明
S3 CloudFormationを含む、各種設定ファイルを保存する。運用時のバックアップ先としても用いる。対象はデータベース、EFS、ログファイル。
Code Pipeline Code Commit,Code Build,Code Deploy を含む。
ECS ビルドされたドメインアプリケーションを含めたDockerコンテナを実行するサービス。
Fargate ECSとともに利用する。コンテナの管理を担うサービス。
VPC 仮想ネットワーク。
ELB ロードバランサ。セキュア通信 (https) の対応を含む。
データベース RDS for MySQL, RDS for PostgreSQL, Aurora MySQL, Aurora PostgreSQL のいずれか
ElastiCache AWSが提供するRedisサービス。
MQ AWSが提供するActive MQサービス。
CloudWatch Events Code Pipeline でパイプラインの状態の変更を検出し、ドメイン管理者へ通知する。
CloudWatch Logs ログファイル (system.log) を一元管理する。
EFS 共有ファイルシステム。

オプション

次のサービスはオプションです。AWS以外のサービスを利用してもかまいません。本ドキュメントでは利用しています。

サービス名説明
Route 53 DNS。カスタムドメイン名を登録する。

AWS CLI のインストール

はじめに Amazon Web Service (AWS) の環境をコマンドラインで操作するための Command Line Interface (CLI) ツールのダウンロードとインストールを行います。(すでにこの対応は行っているという場合、読み飛ばしてください。)具体的には、こちらのURLに記載した手順に従ってください。

インストール後、バージョン番号が適切に表示されるかどうかを確認します。(バージョン番号は適切に読み替えてください。)

C:\Wagby-8.5.0>aws --version
aws-cli/1.16.72 Python/3.6.0 Windows/10 botocore/1.12.62

アクセスキーの設定

管理者の Access Key と Secret Access Key を登録します。(これらの値は AWS の管理画面で確認してください。)

C:\Wagby-8.5.0>aws configure --profile admin

Access Key と Secret Access Key を入力します。ここではリージョン(region)および出力フォーマット(output format)はそれぞれ "ap-northeast-1" と "json" とします。"ap-northeast-1"はアジアパシフィック (東京)となります。

AWS Access Key ID [None]: XXXX
AWS Secret Access Key [None]: XXXX
Default region name [None]: ap-northeast-1
Default output format [None]: json

ホストゾーンの作成

ここではRoute53で、サブドメイン wmsa.wagby.com を管理するホストゾーンを作成する方法を説明します。(その次の章で、サーバ証明書の作成へ続きます。)

すでに AWS のアカウントは作成しており、契約済みの状態として説明します。AWSのマネジメントコンソールから "Route53" のサービスを選択します。

図2 Route53サービスを選択する

Route53はDNS管理のためのサービスです。

図3 Route53トップページ

最初にホストゾーンを用意します。

図4 ホストゾーンの作成

今回は、すでに自社で用意済みの wagby.com というドメインに対するサブドメインとして wmsa.wagby.com を用意した例を示します。実際にはお客様がお持ちのドメインに対する、今回のアプリケーション用のサブドメインを用意してください。

"ホストゾーンの作成" をクリックし、ドメイン名に用意したドメイン名(今回の例では wmsa.wagby.com)を指定します。コメントには適切な説明の文書を指定してください。タイプはパブリックホストゾーンのままにしてください。最後に作成ボタンをクリックします。

図5 ドメイン名を指定する

ホストゾーンが作成され、NSフィールドにRoute53のネームサーバが出力されます。

図6 レコードセットの作成(1)

これをメインドメイン(今回の例ではwagby.com)のネームサーバに登録してください。登録したサブドメインが正しく動作しているかを確認するために、レコードセットを作成します。"レコードセットの作成"をクリックし、名前等を入力して、作成をクリックします。

図7 AWSのDNS一覧

図8,9の例では、名前をwww、タイプをCNAME、値をwww.wagby.comとすることで、www.wmsa.wagby.comの名前を引くと、www.wagby.comのIPアドレスを返すようにしています。

図8 レコードセットの作成(2)
図9 レコードセットの作成(3)

テスト

Windows 10 をお使いの場合、nslookupコマンドでDNSへの登録が成功したかどうかを確認することができます。

> nslookup www.wmsa.wagby.com.
サーバー: ...
Address: ...

ワイルドカードサーバ証明書の作成

AWS が提供する Certificate Manager にて、"*.wmsa.wagby.com" のワイルドカードサーバ証明書を作成します。これによってセキュア(https)通信を実現します。

Route53レコードセットの準備

"wmsa.wagby.com" および "*.wmsa.wagby.com"のサーバ証明書を許可するために、DNSにCAAフィールドを追加します。 レコードセットの作成をクリックし、図10のように名前を未指定、タイプをCAA、値に 0 issue "amazon.com"としてください。"wmsa.wagby.com"の証明書を"amazon.com"にて発行することを許可することとなります。 同様に図11のように名前を"*"、タイプをCAA、値に 0 issuewild "amazon.com"としてください。"*.wmsa.wagby.com"のワイルドカードサーバ証明書を"amazon.com"にて発行することを許可することとなります。

図10 レコードセットの追加(1)
図11 レコードセットの追加(2)
図12 レコードセットの追加(3)

Certificate Manager の操作

"Certificate Manager" を選びます。

図13 ワイルドカードサーバ証明書の作成(1)

"証明書のプロビジョニング" を選びます。

図14 ワイルドカードサーバ証明書の作成(2)

ドメイン名を指定し、パブリック証明書のリクエストを行います。

図15 ワイルドカードサーバ証明書の作成(3)

用意した "*.wmsa.wagby.com" を選択します。

図16 ワイルドカードサーバ証明書の作成(4)

"wmsa.wagby.com" も追加します。

図17 ワイルドカードサーバ証明書の作成(5)

検証方法を指定します。ここでは "DNSの検証" を用いるとします。

図18 ワイルドカードサーバ証明書の作成(6)

タグを追加することもできます。ここでは未入力とします。

図19 ワイルドカードサーバ証明書の作成(7)

入力内容を確認し、間違いなければリクエストします。

図20 ワイルドカードサーバ証明書の作成(8)

ドメイン内の右三角のアイコンをクリックすると、DNSによる検証のためにDNSに追加するレコードの情報が表示されます。今回は対応するドメイン(wmsa.wagby.com)をRoute53で管理しているため、"Route 53でのレコードの作成" ボタンが表示されます。このボタンをクリックすると、DNSでの検証のためのレコードが追加されます。

図21 ワイルドカードサーバ証明書の作成(9)

申請中の二つのドメイン "*.wmsa.wagby.com" と "wmsa.wagby.com" を Route53 に用意します。

図22 ワイルドカードサーバ証明書の作成(10)

作成を行います。

図23 ワイルドカードサーバ証明書の作成(11)

成功すると次のような画面になります。検証にしばらく時間がかかります。

図24 ワイルドカードサーバ証明書の作成(12)

しばらくしてCertificate Managerにて証明書を確認します。検証が完了し、発行に成功すると図25のように発行済みと表示されます。

図25 ワイルドカードサーバ証明書の作成(13)

確認

作成後、サーバ証明書のARNをコマンドラインツールで確認します。 ここで作成したサーバ証明書は後程ロードバランサを作成するときに、サーバ証明書のARNを指定することで、ロードバランサが使用します。 ワイルドカードサーバ証明書となっているため、ホスト名が異なっていても(app1, app2)、ドメイン名が同じ(wmsa.wagby.com)であれば同じサーバ証明書を使うことができます。

> aws --profile admin acm list-certificates
{
  "CertificateSummaryList": [
    {
      "CertificateArn": "arn:aws:acm:ap-northeast-1:000000000000:certificate/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
      "DomainName": "*.wmsa.wagby.com"
    } 
  ]
}

設定ファイルのダウンロードと編集

CodePipelineを実行するときに使う各種ファイルを S3 バケットに保存します。(以下、準備中)