クラウドへの転送と動作の確認最終更新日: 2020年7月7日

転送処理とは

本ガイドにおける転送処理とは、ビルドしたドメインアプリケーションを AWS に送信する手順を指します。

図1 転送イメージ

ドメイン管理者による転送ボタン押下によって、アプリケーションは AWSが提供する CodeCommit に送られます。CodeCommit とは AWS が運用するプライベートのコード管理サービスで、Gitをベースにしています。ここには CodePipeline という仕組みがあり、あらかじめ定められたルールに沿って(転送されたアプリケーションを含む)実行環境を最終的に Docker コンテナ化し、ECS (Elastic Container Service) 上で運用するようになっています。

AWS管理者は、CodePipeline から先の環境を構築し、ドメイン管理者が利用できるようにします。この詳細は「AWS環境の構築」で説明します。

テスト環境と本番環境

AWS管理者により、各ドメインアプリケーションの転送先としてテスト環境と本番環境の二つが提供されます。両者の違いは次のとおりです。

表1. テスト環境と本番環境
テスト環境 本番環境
仮想マシンのスペック テスト用の低スペックマシン (*1) 本番用 (*1)
データベース RDS for MySQL, RDS for PostgreSQL, Aurora MySQL, Aurora PostgreSQL のいずれか
Redis Amazon ElastiCache
MQ Amazon MQ
ログ監視 Amazon CloudWatch Logs
ファイルシステム Amazon EFS
データベースのバックアップ なし あり (要・別契約)
ドメインアプリケーション単位のオートスケール 不可
1. 仮想マシンの具体的な仕様は、AWS 管理者があらかじめ設定した環境に従います。詳細は AWS 管理者に確認してください。

設定ファイル

AWS管理者との調整

はじめに、ドメイン管理者はAWS管理者に次のことを伝えます。

  • 用意するドメインアプリケーションのドメインID。本ガイドでは "app1", "app2" とする。
  • ドメイン管理者のメールアドレス。AWSで行われるアプリケーション入れ替え作業の進捗状況を受信するため。

AWS管理者は初期設定の作業完了後、ドメイン管理者に次の情報を伝えます。

  • カスタムドメイン名。ドメインIDごとに設定されるため、今回は2パターンある。("app1", "app2" 用)
  • CodeCommit のURLと、ログオンするためのユーザアカウントおよびパスワード。ドメインIDごとに、テスト環境用と本番環境用が割り当てられる。今回は 2(ドメインID) x 2(テスト用,本番用) の 4 パターンの組み合わせになる。

テスト環境と本番環境を組み合わせた、ドメインの関係は次のようになります。

ドメイン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
図2 テスト環境と本番環境

デプロイタブの編集

"運用 > デプロイ" タブを開きます。

図3 運用>デプロイタブ

ギアアイコンから "新規" を選択し、転送先情報を入力します。

図4 転送先の作成

今回は、次の4パターンを AWS 管理者から受領した、とします。

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
図5 転送先を設定した例

最初のアプリケーションの転送

ここまでで、二つのテスト用ドメインアプリケーションを用意した、とします。

表2. ドメインとカスタムドメイン名
ドメインID ドメイン名 テスト環境のAWSのカスタムドメイン名 (例)
app1 アプリケーション1 app1test.wmsa.wagby.com
app2 アプリケーション2 app2test.wmsa.wagby.com

このページでは次の手順でアプリケーションを転送します。

  1. app1の初回転送と実行を行う。
  2. app1の動作確認後、app2の初回転送と実行を行う。

app1をビルドする

W-MSAを有効にしたとき、ビルドはドメイン単位で行います。今回、最初に転送するアプリケーションを app1 とします。app1 を指定してフルビルドを行ってください。

最初の転送処理

Designerの "運用 > デプロイ" を開きます。

図7 運用>デプロイタブから転送を行う

"app1テスト環境" を選択して、転送ボタンを押します。

注意

転送対象のアプリケーションは、直近のフルビルドしたドメインアプリケーションが選択されます。

転送ボタンを押下すると AWS 仮想マシンでのドメインアプリケーションの配置と起動が自動的に行われます。 正常に起動したとき、app1 に関するデータベースの初期化処理も完了しています。

進行状況を把握する

AWS 仮想マシン上での作業は通常20分前後を要します。この作業の進行状況が、ドメイン管理者へメールで届きます。(ドメイン管理者のメールアドレスは、AWS管理者に伝えているもの、とします。)

(または AWS の管理画面で確認することもできます。この方法は AWS 管理画面へのログオンが必要となります。詳細は AWS 管理者にお尋ねください。)

ログオン画面の確認

ブラウザのアドレスバーにカスタムドメイン名を入力し、ログオン画面が表示されることを確認します。(*2)

https://app1test.wmsa.wagby.com/
2. 通常はセキュア接続 (https) になります。このカスタムドメイン名は例であり、このまま入力しないよう、ご注意ください。

二つ目以降のアプリケーションの転送

ビルド

Designer でドメイン "アプリケーション2" を選択し、フルビルドを行います。

転送

Designerの "運用 > デプロイ" を開きます。"app2テスト環境" を選択して転送ボタンを押します。

ワンポイント

この選択肢は、直近でフルビルドしたアプリケーションだけが転送できます。一度でも差分ビルドを行うと、選択肢は空になります。

ログオン画面の確認

起動が成功したというメールを受信するまで待ちます。 起動後、ブラウザのアドレスバーに URL を入力し、ログオン画面が表示されることを確認します。

https://app2test.wmsa.wagby.com/
このカスタムドメイン名は例であり、このまま入力しないよう、ご注意ください。

テーブルの初期化

app1を転送した時は、app1に関するテーブルの初期化が自動的に終了していました。このとき共通ドメイン、システムドメイン、app1ドメインのテーブルが作成されています。

しかしapp2を転送したあとは、テーブルの初期化は行われません。(初期化は最初の一回だけ行われます。)そのため app2ドメインに関するテーブルは、このときはまだ存在していません。

そこで、システム管理者でログオンし、管理処理メニューからインポート画面を開き、app2ドメインのモデルをインポートします。インポートのタイミングで"テーブルを初期化する" チェックを有効にすることで、テーブルの作成も同時に行います。

インポート・エクスポート画面

W-MSAを有効にしたとき、インポート・エクスポート画面が次のように変わります。

  • ユーザ定義ドメイン、共通ドメイン、システムドメインを区別してモデル一覧を表示する。
  • ユーザ定義ドメイン内で、複数のドメインに属しているモデルは、モデル名の先頭に*を赤字で表示する。
図8 W-MSA有効時のインポートエクスポート画面

重要

システムモデル、共通モデル、ならびに app2 の管理対象 以外 のモデルをインポートしないように注意してください。インポートしてしまうと、そのテーブルは初期化されるため、データが消失します。他のドメインアプリケーションに影響が及びます。

app1, app2 の転送とテーブル初期化手順のイメージを示します。

図9 W-MSA有効時のインポート処理手順のイメージ

注意

* が付与されているモデルで、app1 では利用しないが app2 で使う共有モデルであれば、ドメイン担当者の判断でテーブルを作成してください。(共有モデルであるため、例えば app2 と app3 では使うものかも知れません。このとき app2 でテーブルを作成した場合は、app3 のインポートエクスポート画面ではこのモデルは選択しない、とします。)つまりテーブルの初期化とはテーブルの作成を伴うものですので、常に一度だけ行われるよう、配慮する必要があります。

ドメインを横断するデータの再設定

次に示すモデルは(ドメインを横断して)異なるドメインに関するデータを含むという性質をもっています。

表3. ドメインを横断したデータを管理するモデル一覧
モデルID 説明
jprincipal プリンシパル(権限)
jcategory プリンシパルのカテゴリ
jfcmodel
jfcmodel4dm
アプリケーション全体で定義したモデルIDとモデル名
jfcdomain ドメインIDとドメイン名
jfcjob ジョブ

上記システムテーブルの値を再インポートすることで、他のすべてのドメインアプリケーションが更新された情報 - 権限やモデル - を知ることができるようになっています。(*3)

3. 例えば、あるドメインアプリケーションで権限が追加された場合、入れ替えによって他のドメインアプリケーションでも追加された権限を認識します。

3つ以上のドメインアプリケーションがある場合

以降、複数のドメインアプリケーションごとに同じ手順(転送、ログオン、テーブルの初期化、ドメインを横断するデータの再設定)を行います。

すべてのドメインアプリケーションの転送が終わったとき、システム全体で必要なテーブルはすべて作成済みであり、かつ、テーブルの初期化は一回だけ行われているものとなります。

共通ドメインとシステムドメインのテーブルを管理するドメイン

最初に作成したドメイン(ここではapp1)が、システムドメインモデルのテーブルと、共通ドメインモデルのテーブルを管理します。

重要

この仕様から、W-MSA運用後、最初に作成したドメインを運用の途中で削除することはできません。

ドメイン情報の更新

運用開始の前に、ドメイン情報 (jfcdomainモデル) を更新する手順を行います。

システム管理者でいずれかのドメインアプリケーションにログオンします。ここでは app1.wmsa.wagby.com とします。

管理処理タブからドメイン情報を開きます。

図10 ドメイン情報

各ドメインの "URL" に、表2に示すカスタムドメイン名を設定します。

図11 URLの設定(1)
図12 URLの設定(2)

この対応によって、メニューの外部リンクおよびポートレットが動作するようになります。[詳細...]

運用開始の前に

ここまでの作業が完了したら、この時点でデータベースのフルバックアップを取得しておいてください。何らかの理由で初期状態のデータベースに戻す必要が生じた場合の起点とします。

モデルがどのドメインに所属するかを確認する

ビルドしたドメインアプリケーションのメニューから "管理処理 > モデル定義 > 定義モデルの確認" で、どのモデルがどのドメインに所属しているかを確認できます。

ここには異なるドメインアプリケーションのモデルも表示されます。

図13 jfcmodelの一覧(1)

作成区分を "ユーザー" で絞り込んだ例です。

図14 jfcmodelの一覧(2)

本番環境へ転送する前に

ここまでの手順を学ぶことで、AWS 環境へドメインアプリケーションを配置し、準備することができました。同じ手順をテスト環境ではなく本番環境に行うことで、運用を開始することができます。しかしこのあとのガイドでドメインアプリケーションの入れ替えならびに運用のノウハウを説明します。今しばらくテスト環境で運用し、ひととおり学んだあとで本番環境で運用するようにしてください。

次ページで、ドメインアプリケーションの入れ替えを説明します。