クラウドへの転送と動作の確認
最終更新日: 2020年7月7日
R8 | R9
本ガイドにおける転送処理とは、ビルドしたドメインアプリケーションを AWS に送信する手順を指します。
ドメイン管理者による転送ボタン押下によって、アプリケーションは AWSが提供する CodeCommit に送られます。CodeCommit とは AWS が運用するプライベートのコード管理サービスで、Gitをベースにしています。ここには CodePipeline という仕組みがあり、あらかじめ定められたルールに沿って（転送されたアプリケーションを含む）実行環境を最終的に Docker コンテナ化し、ECS (Elastic Container Service) 上で運用するようになっています。
AWS管理者は CodePipeline から先の環境を構築し、ドメイン管理者が利用できるようにします。この詳細は「AWS環境の構築」で説明します。
AWS管理者により、各ドメインアプリケーションの転送先としてテスト環境と本番環境の二つが提供されます。両者の違いは次のとおりです。
はじめに、ドメイン管理者はAWS管理者に次のことを伝えます。
AWS管理者は初期設定の作業完了後、ドメイン管理者に次の情報を伝えます。
テスト環境と本番環境を組み合わせた、ドメインの関係は次のようになります。
"運用 > デプロイ" タブを開きます。
ギアアイコンから "新規" を選択し、転送先情報を入力します。
今回は、次の4パターンを AWS 管理者から受領した、とします。
ここまでで、二つのテスト用ドメインアプリケーションを用意した、とします。
このページでは次の手順でアプリケーションを転送します。
W-MSAを有効にしたとき、ビルドはドメイン単位で行います。今回、最初に転送するアプリケーションを app1 とします。app1 を指定してフルビルドを行ってください。
Designerの "運用 > デプロイ" を開きます。
"app1テスト環境" を選択して、転送ボタンを押します。
転送対象のアプリケーションは、直近のフルビルドしたドメインアプリケーションが選択されます。
転送ボタンを押下すると AWS 仮想マシンでのドメインアプリケーションの配置と起動が自動的に行われます。
正常に起動したとき、app1 に関するデータベースの初期化処理も完了しています。
AWS 仮想マシン上での作業は通常20分前後を要します。この作業の進行状況が、ドメイン管理者へメールで届きます。（ドメイン管理者のメールアドレスは、AWS管理者に伝えているもの、とします。）
（または AWS の管理画面で確認することもできます。この方法は AWS 管理画面へのログオンが必要となります。詳細は AWS 管理者にお尋ねください。）
転送処理とは
テスト環境と本番環境
テスト環境
本番環境
仮想マシンのスペック
テスト用の低スペックマシン (*1)
本番用 (*1)
データベース
RDS for MySQL, RDS for PostgreSQL, Aurora MySQL, Aurora PostgreSQL のいずれか
Redis
Amazon ElastiCache
MQ
Amazon MQ
ログ監視
Amazon CloudWatch Logs
ファイルシステム
Amazon EFS
データベースのバックアップ
なし
あり (要・別契約)
ドメインアプリケーション単位のオートスケール
不可
可
設定ファイル
AWS管理者との調整
ドメインID
ドメイン名
転送先ラベル
AWSのカスタムドメイン名
app1
アプリケーション1
app1テスト環境
app1test.wmsa.wagby.com
app1
アプリケーション1
app1本番環境
app1.wmsa.wagby.com
app2
アプリケーション2
app2テスト環境
app2test.wmsa.wagby.com
app2
アプリケーション2
app2本番環境
app2.wmsa.wagby.com
デプロイタブの編集
URL
ラベル
アカウント
パスワード
ドメイン
https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/app1-application-test
app1テスト環境
app1-test-user
*
アプリケーション1
https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/app1-application
app1本番環境
app1-user
*
アプリケーション1
https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/app2-application-test
app2テスト環境
app2-test-user
*
アプリケーション2
https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/app2-application
app2本番環境
app2-user
*
アプリケーション2
最初のアプリケーションの転送
ドメインID
ドメイン名
テスト環境のAWSのカスタムドメイン名 (例)
app1
アプリケーション1
app1test.wmsa.wagby.com
app2
アプリケーション2
app2test.wmsa.wagby.com
app1をビルドする
最初の転送処理
注意
進行状況を把握する
ログオン画面の確認
ブラウザのアドレスバーにカスタムドメイン名を入力し、ログオン画面が表示されることを確認します。(*2)
https://app1test.wmsa.wagby.com/二つ目以降のアプリケーションの転送
ビルド
Designer でドメイン "アプリケーション2" を選択し、フルビルドを行います。
転送
Designerの "運用 > デプロイ" を開きます。"app2テスト環境" を選択して転送ボタンを押します。
ワンポイント
この選択肢は、直近でフルビルドしたアプリケーションだけが転送できます。一度でも差分ビルドを行うと、選択肢は空になります。
ログオン画面の確認
起動が成功したというメールを受信するまで待ちます。 起動後、ブラウザのアドレスバーに URL を入力し、ログオン画面が表示されることを確認します。
https://app2test.wmsa.wagby.com/テーブルの初期化
app1を転送した時は、app1に関するテーブルの初期化が自動的に終了していました。このとき共通ドメイン、システムドメイン、app1ドメインのテーブルが作成されています。
しかしapp2を転送したあとは、テーブルの初期化は行われません。（初期化は最初の一回だけ行われます。）そのため app2ドメインに関するテーブルは、このときはまだ存在していません。
そこで、システム管理者でログオンし、管理処理メニューからインポート画面を開き、app2ドメインのモデルをインポートします。インポートのタイミングで"テーブルを初期化する" チェックを有効にすることで、テーブルの作成も同時に行います。
インポート・エクスポート画面
W-MSAを有効にしたとき、インポート・エクスポート画面が次のように変わります。
- ユーザ定義ドメイン、共通ドメイン、システムドメインを区別してモデル一覧を表示する。
- ユーザ定義ドメイン内で、複数のドメインに属しているモデルは、モデル名の先頭に
*を赤字で表示する。
重要
システムモデル、共通モデル、ならびに app2 の管理対象 以外 のモデルをインポートしないように注意してください。インポートしてしまうと、そのテーブルは初期化されるため、データが消失します。他のドメインアプリケーションに影響が及びます。
app1, app2 の転送とテーブル初期化手順のイメージを示します。
注意
* が付与されているモデルで、app1 では利用しないが app2 で使う共有モデルであれば、ドメイン担当者の判断でテーブルを作成してください。（共有モデルであるため、例えば app2 と app3 では使うものかも知れません。このとき app2 でテーブルを作成した場合は、app3 のインポートエクスポート画面ではこのモデルは選択しない、とします。）つまりテーブルの初期化とはテーブルの作成を伴うものですので、常に一度だけ行われるよう、配慮する必要があります。
ドメインを横断するデータの再設定
次に示すモデルは（ドメインを横断して）異なるドメインに関するデータを含むという性質をもっています。
| モデルID | 説明 |
|---|---|
| jprincipal | プリンシパル（権限） |
| jcategory | プリンシパルのカテゴリ |
| jfcmodel jfcmodel4dm |
アプリケーション全体で定義したモデルIDとモデル名 |
| jfcdomain | ドメインIDとドメイン名 |
| jfcjob | ジョブ |
上記システムテーブルの値を再インポートすることで、他のすべてのドメインアプリケーションが更新された情報 - 権限やモデル - を知ることができるようになっています。(*3)
3つ以上のドメインアプリケーションがある場合
以降、複数のドメインアプリケーションごとに同じ手順（転送、ログオン、テーブルの初期化、ドメインを横断するデータの再設定）を行います。
すべてのドメインアプリケーションの転送が終わったとき、システム全体で必要なテーブルはすべて作成済みであり、かつ、テーブルの初期化は一回だけ行われているものとなります。
共通ドメインとシステムドメインのテーブルを管理するドメイン
最初に作成したドメイン（ここではapp1）が、システムドメインモデルのテーブルと、共通ドメインモデルのテーブルを管理します。
重要
この仕様から、W-MSA運用後、最初に作成したドメインを運用の途中で削除することはできません。
ドメイン情報の更新
運用開始の前に、ドメイン情報 (jfcdomainモデル) を更新する手順を行います。
システム管理者でいずれかのドメインアプリケーションにログオンします。ここでは app1.wmsa.wagby.com とします。
管理処理タブからドメイン情報を開きます。
各ドメインの "URL" に、表2に示すカスタムドメイン名を設定します。
この対応によって、メニューの外部リンクおよびポートレットが動作するようになります。[詳細...]
運用開始の前に
ここまでの作業が完了したら、この時点でデータベースのフルバックアップを取得しておいてください。何らかの理由で初期状態のデータベースに戻す必要が生じた場合の起点とします。
モデルがどのドメインに所属するかを確認する
ビルドしたドメインアプリケーションのメニューから "管理処理 > モデル定義 > 定義モデルの確認" で、どのモデルがどのドメインに所属しているかを確認できます。
ここには異なるドメインアプリケーションのモデルも表示されます。
作成区分を "ユーザー" で絞り込んだ例です。
本番環境へ転送する前に
ここまでの手順を学ぶことで、AWS 環境へドメインアプリケーションを配置し、準備することができました。同じ手順をテスト環境ではなく本番環境に行うことで、運用を開始することができます。しかしこのあとのガイドでドメインアプリケーションの入れ替えならびに運用のノウハウを説明します。今しばらくテスト環境で運用し、ひととおり学んだあとで本番環境で運用するようにしてください。