第4章 RHMAP と他のサービスとの統合
4.1. MBaaS サービスの概要
MBaaS サービスは、複数のプロジェクト内の複数のクラウドアプリケーションが使用できる共有機能を提供するクラウド/Web アプリケーションです。通常のユースケースは以下のとおりです。
- サードパーティー製のサービスにアクセスするために API を提供します。たとえば、複数のプロジェクトに SMS メッセージを送信する要件が含まれるとします。この場合は、SMS メッセージを送信する API を提供するためにサービスを作成し、複数のプロジェクトでそのサービスにアクセスすることができます。
- レガシーカスタマーバックエンドシステムに API を提供します。たとえば、ユーザー認証を実行するレガシーシステムがあるとします。この場合は、プロジェクトで使用する一貫性のある新しい API セットを提供するサービスを作成し、レガシーシステムへのアクセス方法に関するすべての詳細を隠すことができます。
MBaaS サービスは、クライアントアプリで直接使用するよう設計されていません。たとえば、iOS アプリは MBaaS サービスを直接呼び出しません。クライアントアプリは関連するクラウドアプリを呼び出し、クラウドアプリは要求を 1 つ以上の MBaaS サービスに送信します。
MBaaS サービスを使用する利点は以下のとおりです。
- コードの再利用性が向上します。これは、外部サービスへのアクセスが複雑な場合に特に重要です。
- 機密情報を保護します。場合によっては、外部サービスにアクセスするためにユーザークレデンシャルが必要です。サービスを使用することにより、複数のプロジェクト開発者がクレデンシャルを共有する必要がなくなります。
4.2. 認証に対する SAML の使用
4.2.1. 概要
このチュートリアルでは、モバイルアプリケーションで SAML 認証を使用する例を示します。SAML は現在 Red Hat Mobile Application Platform ホスト型 (RHMAP) では認証ポリシーとして利用できませんが、ユーザーの独自のソリューションの土台として使用できるテンプレートが提供されます。
SAML 認証の同じソリューションは、サーバーサイドロジックとクライアントアプリの両方で構成されます。
- SAML サービス —SAML 2.0 認証を実行するために、サービスプロバイダーとして機能し、passport-saml とともに Passport.js を使用するクラウドサービス
- SAML Cloud App — クライアントアプリから SAML サービスへの要求を代理するクライアントアプリ
以下の各プラットフォーム向けのクライアントアプリが提供されます。
4.2.2. SAML の概要
提供されたテンプレートの構造について説明するために、最初に SAML のコンセプトを簡単に説明します。SAML 認証シナリオには以下の 3 つの要素があります。
- プリンシパル — サービスプロバイダーにより提供された保護済みリソースにアクセスしようとするユーザー
- サービスプロバイダー (SP) —プリンシパルにサービスを提供する Web アプリケーション
- ID プロバイダー (IdP) — プリンシパルの ID を検証し、サービスプロバイダーに ID アサーションを提供することが唯一の目的の Web サービス
これらの要素は、複数の前提に基づいて認証の処理で対話します。
- プリンシパルはサービスプロバイダーとパスワードまたは他のシークレットを共有しません。
- ID プロバイダーはプリンシパルとサービスプロバイダーの両方により信頼されています。
- ID プロバイダーは、ID アサーションを多くのサービスプロバイダーに提供して Single Sign-On (SSO) を有効にできます。
4.2.3. テンプレートのセットアップ
最初に、提供されたテンプレートから SAML Service クラウドサービスを作成します。このサービスはソリューションの中心的なコンポーネントであり、サービスプロバイダーとして機能します。この例で提供される実際のサービスでは、エンドポイント /session/valid でユーザーの詳細が表示されています。SAML 認証プロセスをサポートするエンドポイントは他に複数あります。
-
/login— IdP のログイン画面にリダイレクトします。 -
/session/login_host— IdP のログイン画面の URL を返します。 -
/login/callback— IdP が ID アサーションをこのエンドポイントにポストします (ログインの成功または失敗が示されます)。 -
/login/ok— ログイン成功を示すために、クライアントアプリがこの URL にリダイレクトされます。
サービスは IdP として Active Directory Federation Services 2.0 (ADFS) を使用するよう設定されていますが、少しだけ調整して他の任意の SAML 2.0 準拠 IdP を使用するよう設定できます。
4.2.3.1. SAML サービスの作成
- Studio で、Services & APIs に移動し、Provision MBaaS Service/API をクリックします。
- SAML Service テンプレートを見つけ、Choose をクリックし、任意の名前 (たとえば、"SAML Service") を入力して Create をクリックします。
以下のように設定の詳細を入力します。
-
SAML_ISSUER— 現時点では空白のままにします。 -
SAML_CALLBACK_URL—現時点では空白のままにします。 -
SAML_ENTRY_POINT— ADFS エンドポイントに URL を入力します。 -
SAML_AUTHN_CONTEXT—値urn:federation:authentication:windowsを入力します。 -
SAML_CERT— このデモの場合は、空白のままにできます。
-
- Next をクリックし、サービスが作成されるまで待機します。次に、Finish をクリックします。
サービスが作成およびデプロイされたら、SAML_ISSUER と SAML_CALLBACK_URL を設定する必要があります。
-
Service Details ページで Current Host フィールドを確認し、その値をメモします。この値はこの例では
<mbaas-host>と示されます。また、Service ID の値もメモします。 - 左側のメニューで Environment Variables をクリックします。
App Environment Variables セクションで、
SAML_ISSUERとSAML_CALLBACK_URLの両方の変数に以下の値を設定します (<mbaas-host>は手順 1 で見つけた値に置き換えます)。<mbaas-host>/login/callback
4.2.3.2. プロジェクトのセットアップ
最初にプロジェクトを作成します。
- Studio で、Projects に移動し、New Project をクリックします。
- SAML Example Project を選択し、Choose をクリックして、任意の名前 (たとえば、"SAML Example") を入力して Create をクリックします。
- プロジェクトが作成されたら、Finish をクリックします。
次に、以前に作成した SAML サービスをプロジェクトに関連付ける必要があります。
- SAML Example プロジェクトの MBaas Services 列で、+ をクリックして新しいサービスを追加します。
- 以前に作成した SAML サービスを探し、クリックして、画面下部で Associate Services をクリックします。
クラウドアプリには SAML サービスへの参照が必要です。SAML サービスを参照する環境変数を作成します。
- SAML Cloud クラウドアプリに移動し、左側の Environment Variables セクションにアクセスします。
App Environment Variables セクションで Add Variable をクリックし、以下の値を入力して、Create をクリックします。
-
名前:
SAML_SERVICE - 値: 以前にメモした SAML サービスのサービス ID
-
名前:
- Push Environment Variables をクリックして環境変数をランタイム環境に伝播します。
アプリをビルド、デプロイ、およびテストすることができます。
4.2.4. 仕組み
認証プロセス中に起こったことを見ていきます。
Sign In ボタンをクリックすると、クライアントアプリが sso/session/login_host エンドポイントを呼び出し IdP のログイン画面の URL を取得します。この URL はアプリ内ブラウザーで開き、IdP と認証できます。
JavaScript
$('.sign-in-button').on('click', function(e) {
$fh.cloud({
path: 'sso/session/login_host',
method: "POST",
data: {
"token": $fh._getDeviceId()
}
},
function(res) {
console.log('sso host:' + res.sso);
var browser = cordova.InAppBrowser.open(res.sso, '_blank', 'location=yes');
...
Android
JSONObject params = new JSONObject();
params.put(TOKEN, Device.getDeviceId(getApplicationContext()));
FHCloudRequest request = FH.buildCloudRequest(
"sso/session/login_host", "POST", null, params);
request.executeAsync(new FHActCallback() {
@Override
public void success(FHResponse res) {
Log.d(TAG, "FHCloudRequest (login_host) - success");
String ssoStringURL = res.getJson().getString("sso");
Log.d(TAG, "SSO URL = " + ssoStringURL);
SAMLActivity.this.displayWebView(ssoStringURL);
}
...
iOS
NSString* deviceID = [[FHConfig getSharedInstance] uuid];
NSMutableDictionary __params = [NSMutableDictionary dictionary];
params[@"token"] = deviceID;
FHCloudRequest __cloudReq = [FH buildCloudRequest:@"sso/session/login_host" WithMethod:@"POST" AndHeaders:nil AndArgs: params];
// Initiate the SSO call to the cloud
[cloudReq execWithSuccess:^(FHResponse _success) {
NSLog(@"EXEC SUCCESS =%@", success);
NSDictionary_ response = [success parsedResponse];
NSString* urlString = response[@"sso"];
NSURL* loginUrl = [[NSURL alloc] initWithString:urlString];
// Display WebView
FHSAMLViewController *controller = [[FHSAMLViewController alloc] initWithURL:loginUrl];
[[[[UIApplication sharedApplication] keyWindow] rootViewController] presentViewController:controller animated:YES completion:nil];
...
Windows
private async void Button_Click(object sender, RoutedEventArgs e)
{
var response = await FHClient.GetCloudRequest("sso/session/login_host", "POST", null, GetRequestParams()).ExecAsync();
var resData = response.GetResponseAsJObject();
var sso = (string)resData["sso"];
if (!string.IsNullOrEmpty(sso))
{
webView.Visibility = Visibility.Visible;
webView.Navigate(new Uri(sso));
}
}
IdP で必要なクレデンシャルを入力し、ログインフォームを送信したら、IdP は ID アサーションを SAML サービスの /login/callback エンドポイントにポストし直します。
SAML サービスは以下のことを行います。
- 受け取った SAML アサーションをユーザーのトークンに関連付けます (HTTP セッションで渡されます)。
- SAML アサーションからのデータを保持します。
-
ユーザーを
/login/okにリダイレクトします (認証の成功がクライアントアプリに通知されます)。
ユーザーが正常にログインしたら、アプリ内ブラウザーが閉じられ、クライアントアプリはサービスプロバイダーにより提供されたサービスを使用できます (sso/session/valid を呼び出しユーザーの詳細を取得します) 。
JavaScript
$fh.cloud({
path: 'sso/session/valid',
method: "POST",
data: {
"token": $fh._getDeviceId()
}
},
function(details) {
$('.first_name').text(details.first_name);
$('.last_name').text(details.last_name);
$('.email').text(details.email);
$('.expires').text(details.expires);
},
...
Android
JSONObject params = new JSONObject();
params.put(TOKEN, Device.getDeviceId(getApplicationContext()));
FHCloudRequest request = FH.buildCloudRequest(
"sso/session/valid", "POST", null, params);
request.executeAsync(new FHActCallback() {
@Override
public void success(FHResponse res) {
Log.d(TAG, "FHCloudRequest (valid) - success");
User user = new User();
user.setFirstName(res.getJson().getString("first_name"));
user.setLastName(res.getJson().getString("last_name"));
user.setEmail(res.getJson().getString("email"));
user.setExpires(res.getJson().getString("expires"));
Log.d(TAG, user.toString());
SAMLActivity.this.displayUserData(user);
...
iOS
NSString* deviceID = [[FHConfig getSharedInstance] uuid];
NSMutableDictionary __params = [NSMutableDictionary dictionary];
params[@"token"] = deviceID;
FHCloudRequest __cloudReq = [FH buildCloudRequest:@"sso/session/valid" WithMethod:@"POST" AndHeaders:nil AndArgs: params];
// Initiate the SSO call to the cloud
[cloudReq execWithSuccess:^(FHResponse _success) {
NSDictionary_ response = [success parsedResponse];
// Manage next UI view controller
[ self performSegueWithIdentifier: @"showLoggedIn" sender: response];
} AndFailure:^(FHResponse *failed) {
NSLog(@"Request name failure =%@", failed);
}];
Windows
var response = await FHClient.GetCloudRequest("sso/session/valid", "POST", null, GetRequestParams()).ExecAsync();
if (response.Error == null)
{
var data = response.GetResponseAsDictionary();
name.Text = string.Format("{0} {1}", data["first_name"], data["last_name"]);
email.Text = (string) data["email"];
expires.Text = ((DateTime) data["expires"]).ToString();
}
else
{
await new MessageDialog(response.Error.ToString()).ShowAsync();
}
4.3. RedHat OpenShift Online PaaS へのクラウドアプリのステージング
概要
このガイドの目的は Red Hat Mobile Application Platform ホスト型 (RHMAP) で OpenShift Online を MBaaS ターゲットとして使用し、アプリケーションをデプロイする手順を提供することです。
4.3.1. OpenShift Online とは
OpenShift Online は、アプリケーションのプロビジョニング、管理、およびスケーリングを自動化する、Red Hat のパブリッククラウドアプリケーションの開発およびホスティングプラットフォームです。
4.3.1.1. OpenShift Online と RHMAP との統合
OpenShift Online ユーザーは OpenShift Online クレデンシャルを使用して RHMAP にログインし、クラウドアプリとサービスの MBaaS ターゲットとして利用可能な OpenShift Online ギアを使用できます。MBaaS ターゲットは、クラウドアプリとその関連するサービスをデプロイできるコンテナ化されたインフラストラクチャーです。また、1 つまたは複数の MBaaS ターゲットを環境に収集することもできます。ユーザーは複数の環境を作成して (各環境に 1 つまたは複数の MBaaS ターゲットが含まれる状態で)、開発の異なるステージ (たとえば、Dev、UAT、および Production 環境) とプロジェクトライフサイクル管理を有効にできます。
また、MBaaS サービスに関連するプロビジョニング、ロギング、エンドポイントセキュリティーなどのすべての操作は OpenShift Online MBaaS にも適用されます。これらの操作の詳細については、MBaaS Services Product Features page を参照してください。
4.3.1.2. RHMAP による利用可能な OpenShift Online ギアへの影響
RHMAP アプリケーションは、OpenShift Online にデプロイする他のすべてのアプリケーションと同じように扱われます。利用可能なギアの一部またはすべてを使用して RHMAP クラウドと Web アプリケーションをデプロイできますが、利用可能なギアの数によって制限されます。OpenShift Online で実行されているすべてのアプリケーションと同様に、利用可能なギアと機能の数は現在のプランによって異なります。RHMAP で OpenShift Online ギアを使用する方法の詳細については、項「ギア」を参照してください。
4.3.1.3. 制限
RHMAP で OpenShift Online を MBaaS ターゲットとして使用することは現時点では開発者プレビューとして可能であり、本番稼働環境には推奨されません。
4.3.2. スタートガイド
最初に必要なものは OpenShift Online アカウントです。既存のアカウントを使用するか、新しいアカウントを作成することができます。
これは OpenShift Online アカウントを使用して RHMAP にログインする場合のみ可能です。この機能は既存の RHMAP アカウントでは利用できません。
4.3.2.1. 初回ログインおよびセットアップ
OpenShift Online アカウントを取得したら、これらのクレデンシャルを使用して RHMAP にログインできます。OpenShift Online アカウントを使用して初めてログインする場合は、RHMAP によってセットアッププロセスが示されます。それ以降のログインでは、セットアッププロセスなしで RHMAP にアクセスできます。
要求に対応するために、アクセスは招待状によってのみ提供しています。ログインページに提供されたリンクを使用して興味があることを登録すると、スペースが利用可能になり次第招待状メールが送信されます。招待状メールには、アクセスを提供する適切なログインリンク (アクセストークンを含む) が含まれます。ログインするためにログインページに初めてアクセスする場合はこのリンクを使用する必要があります。
セットアッププロセスを開始するには、以下の手順に従ってください。
- RHMAP OpenShift Online ログインページに移動し、Request an Invite をクリックします。
サインアップフォームに適切な詳細情報 (利用可能な場合は プロモーションコードを含む) を入力し、Sign Up をクリックします。
- 招待状メールを受け取ったら、招待状メールに提供されたリンクから RHMAP に移動し、OpenShift Online クレデンシャルを使用してログインします。
- 正常にログインしたら、RHMAP によってドメイン名を作成するよう求められます。希望するドメイン名を入力し、Create をクリックします。
- RHMAP によってドメインが作成され、必要なセットアッププロセスが自動的に開始されます。基本的に RHMAP により承認トークンとパブリックキーが作成され、RHMAP が OpenShift Online ギアと通信し、アプリケーションをユーザーの代わりにデプロイできるようになります。
自動セットアッププロセスが完了したら、RHMAP が OpenShift Online アカウントに接続されます。この時点で OpenShift Online は、クラウドアプリケーションをデプロイしたときに MBaaS ターゲットとして現れます。
OpenShift Online を MBaaS ターゲットとして使用する方法を示すために、テンプレートから新しいサンプルアプリケーションを作成し、クラウド部分を OpenShift Online にデプロイする手順について詳細に説明します。
4.3.2.2. サンプルアプリケーションの作成
新しいアプリケーションを作成するには、以下の手順に従ってください。
- 画面の左上にある Projects をクリックします。
- 画面の左側にある New Project ボタンをクリックします。
- 少なくとも 1 つのクラウドコンポーネントを含むプロジェクト (たとえば、Hello World Project) を選択します。
- プロジェクトの名前を入力し、画面の右側にある Create ボタンをクリックします。
- プロジェクトが作成されたら、画面の下部にある Finish ボタンをクリックします。
- プロジェクトの詳細ページが表示されます。
4.3.2.3. RHMAP を使用した OpenShift Online へのクラウドアプリのデプロイ
クラウドアプリを OpenShift Online にデプロイするには、以下の手順に従ってください。
- クラウドアプリの主要な詳細セクションが表示されていない場合は、そのセクションに移動します。
- OpenShift Online にデプロイするクラウドまたは Web アプリ (クラウドアプリなど) を選択します。
アプリの詳細ページで OpenShift が MBaaS Deploy Targets の隣にリストされていることを確認します。
- 画面の左側にある Deploy をクリックします。
画面の下部にある Deploy Cloud App ボタンをクリックします。
これによりデプロイメントが開始され、ステータスが示されます。
注記初めてのデプロイメントの場合、OpenShift Online へのデプロイにはしばらく (数分) 時間がかかることがあります。それ以降の同じアプリのデプロイメントでは時間が大幅に短縮されます。デプロイメントが開始され、ステータスに従わない場合は、ページから離れることができ、アプリが引き続き環境にデプロイされます。
注記ギアの不足に関連する警告を受け取ることがあります。これは、OpenShift Online アカウントに利用可能なギアが残っていない場合に起こります。OpenShift Online アカウントから他のアプリケーションを削除してギアを解放する必要があることがあります。
- デプロイメントが正常に完了したら、画面の左側にある Details をクリックしてアプリの詳細ページに戻ります。
- アプリがデプロイされたことを確認するには、Current Host の隣りにあるリンクをクリックします。
また、OpenShift Online アカウントにログインして、アプリがそこにデプロイされていることを確認することもできます。
4.3.2.4. fhc を使用した OpenShift Online へのクラウドアプリのデプロイ
本項では、fhc コマンドラインツールを使用します。fhc のインストールおよび使用に関する詳細については、Local Development ドキュメンテーションを参照してください。
fhc を使用してクラウドアプリを OpenShift Online にデプロイするには、以下の手順を実行する必要があります。
- ターゲットを設定し、ログインします。
- OpenShift Online MBaaS ターゲットを確認します。
- デプロイする環境の ID を取得します。
- デプロイするアプリの ID を取得します。
-
stage操作を使用してアプリをデプロイします。
ターゲットを設定し、ログインするには、以下の手順に従ってください。
-
$ fhc target https://{YOUR-DOMAIN}.openshift.feedhenry.com -
$ fhc login
OpenShift Online MBaaS ターゲットを検証するには、以下のコマンドを実行して、現在設定されている MBaaS サービスをリストします。
$ fhc admin mbaas list
この結果、以下のような情報が表示されます。
| ID | URL | サービスキー | ユーザー名 | パスワード | 変更時間 |
|---|---|---|---|---|---|
|
openshift-jsmith-email-com-enJo |
undefined |
undefined |
数秒前 |
デプロイ先の環境の ID を取得するには、以下のコマンドを実行して利用可能な環境をリストします。
$ fhc admin environments list
この結果、以下のような情報が表示されます。
| ID | ラベル | 作成時のデプロイ | 更新時のデプロイ | MBaaS ターゲット | 変更時間 |
|---|---|---|---|---|---|
|
production-openshift-jsmith-email-com-enjo |
Production |
undefined |
undefined |
openshift-jsmith-email-com-enJo |
7 日前 |
|
development-openshift-jsmith-email-com-enjo |
Development |
undefined |
undefined |
openshift-jsmith-email-com-enJo |
7 日前 |
デプロイするアプリの ID を取得するには、アプリが含まれるプロジェクトの ID を最初に取得する必要があります。現在のプロジェクトは以下のコマンドを実行してリストできます。
$ fhc projects
この結果、以下のような情報が表示されます。
| ID | タイトル | アプリの数 | 最終更新日時 |
|---|---|---|---|
|
wp3nlgt2jr5lvymx62tayp5z |
project1 |
2 |
2 時間前 |
|
piilhyeyqpad4nlgyveo6a43 |
project2 |
2 |
1 日前 |
この時点でプロジェクトの ID を使用して apps コマンドでアプリの ID を取得できます。
fhc apps <projID>
たとえば、アプリが project1 に含まれる場合は、以下のコマンドを実行します。
$ fhc apps wp3nlgt2jr5lvymx62tayp5z
この結果、以下のような情報が表示されます。
| ID | タイトル | 説明 | タイプ | Git | ブランチ |
|---|---|---|---|---|---|
|
wp3nlgrxlyzbgvwfjnmulnat |
クラウドアプリ |
cloud_nodejs |
git@example.feedhenry.net:openshift/project1-Cloud-App.git |
master | |
|
wp3nlgudwgejhnzbuj5twsus |
Cordova アプリ |
client_hybrid |
git@example.feedhenry.net:openshift/.git |
最後に、アプリと環境の ID を使用して stage コマンドでアプリを OpenShift Online にデプロイできます。
fhc app stage --app=APP-ID --env=ENV-ID
たとえば、クラウドアプリ を project1 から Development にデプロイする場合は、以下のコマンドを実行します。
fhc app stage --app=wp3nlgrxlyzbgvwfjnmulnat --env=development-openshift-jsmith-example-com-enjo
実行後に、以下のような情報が出力されます。
{
"action": {},
"cacheKey": "CloudAppdevelnat-openshiftdeploy",
"error": "",
"log": [],
"status": "complete"
}4.3.3. どのように連携するか
RHMAP は、OpenShift Online ギアを MBaaS ターゲットとして扱うために、最初に OpenShift Online への接続を確立する必要があります。この接続は OpenShift Online クレデンシャルを使用して RHMAP に初めてログインする場合にセットアップされます。RHMAP はユーザーのクレデンシャルを使用してユーザーの代わりに OpenShift Online にログインし、承認トークンを交換して、RHMAP と OpenShift Online 間の今後の通信を可能にする SSH キーをセットアップします。次に、RHMAP は自動的に OpenShift Online を MBaaS ターゲットとして設定し、プロジェクトで利用できるようにします。
初期設定が完了し、RHMAP プロジェクトで OpenShift MBaaS ターゲットを使用できるようになったら、RHMAP クラウドアプリを OpenShift Online にデプロイできます。これらのアプリは他の OpenShift Online アプリケーションと同様に扱われ、特別な利点として RHMAP に統合されます。たとえば、デプロイメント、アプリケーションロギング、および他の操作は引き続き RHMAP から実行できますが、OpenShift Online で実行されているアプリケーションに SSH 経由で直接接続することもできます。また、アプリケーションが OpenShift Online コンソールから直接デプロイされた場合は、そのアプリケーションの詳細を表示することもできます。
4.3.3.1. ギア
OpenShift Online にデプロイされた RHMAP クラウドアプリは OpenShift Online にデプロイされた他のアプリケーションと同様に扱われるため、利用可能なギアの数に制限されます。ギアの数はプランによって異なることがあります。RHMAP からクラウドアプリをデプロイしようとし、利用可能なギアが不足している場合は、以下のメッセージが表示されます。
この問題を解決するには、アカウントのアップグレードまたは OpenShift Online で実行されている別のアプリケーションの削除を検討してください。
4.3.3.2. 環境
OpenShift Online クレデンシャルを使用して RHMAP にログインすると、Development と Production の 2 つの環境が設定されています。これらの環境は、クラウドアプリケーションの詳細を表示するときに画面の右上にあるメニューを使用して切り替えることができます。
すべての環境でのすべてのクラウドアプリ開発の概要については、画面の上部のプロジェクトの Lifecycle Management セクションをクリックしてください。
各環境の各アプリケーションは独自のギアを受け取ることに注意してください。たとえば、プロジェクトに App1 と App2 の 2 つのクラウドアプリがあり、各アプリケーションに 1 つのギアが必要な場合は、Development と Production で App1 と App2 を実行するために 4 つのギアが必要になります。
この時点で、OpenShift Online で RHMAP を使用する場合は、提供された Development と Production 以外の他の環境を設定することはできません。
4.3.3.3. ロギングおよびデバッグ
OpenShift Online にデプロイされたクラウドアプリのログ参照とトラブルシューティングは、RHMAP または OpenShift Online ツールから実行できます。
OpenShift ツール
OpenShift では、SSH 経由でログインしてアプリケーションをトラブルシューティングする機能が提供されます。クラウドアプリの SSH URL を調べるには以下の手順に従ってください。
- プロジェクトに移動します。
- 希望するクラウドアプリをクリックします。
- 画面の左側にある Details をクリックします。
-
SSH URL は SSH URL フィールドの隣にあります。
SSH URL フィールドは、OpenShift Online にデプロイされたクラウドアプリでのみ利用可能です。SSH を使用した OpenShift への接続の詳細については、OpenShift SSH ヘルプページを参照してください。
SSH と他の OpenShift Online ツールの詳細については、公式ドキュメンテーションを参照してください。
RHMAP ツール
RHMAP からクラウドアプリのログを参照するには、以下の手順に従ってください。
- プロジェクトに移動します。
- 希望するクラウドアプリをクリックします。
- 画面の左側にある Logs をクリックします。
RHMAP でのアプリケーションのデバッグの詳細については、デバッグガイドを参照してください。
4.3.3.4. OpenShift Online にデプロイされたアプリの削除
クラウドアプリは RHMAP 側から削除する必要があります。RHMAP では、OpenShift Online からのクラウドアプリの削除が自動的に実行されます。
RHMAP からクラウドアプリを削除するには、以下の手順に従ってください。
- 希望するプロジェクトに移動します。
- 削除するクラウドアプリを選択します。
- Details セクションで、画面下部にある Delete App をクリックします。
アプリケーションを RHMAP で削除せずに OpenShift Online で削除し、OpenShift Online に再デプロイしようとすると、error: "Error deploying App to OpenShift: Error disabling auto deploy: Application 'XXXXXXXXXXXXXXXXXXXXXXXX' not found. (404)" というメッセージが表示されることがあります。
4.3.3.5. SSH キー
OpenShift Online クレデンシャルを使用して初めて RHMAP にログインすると、RHMAP により OpenShift Online との認証および承認のやり取りが実行され、OpenShift Online アカウントにパブリックキーが追加されます。次に、パブリックキーを使用して SSH 経由で OpenShift Online にクラウドアプリがデプロイされます。OpenShift Online アカウントに関連付けられたすべてのキーは、アカウントの設定ページで参照できます。
RHMAP により生成されたパブリックキーが失効したり、OpenShift Online アカウントから削除されたりした場合は、以下のメッセージが表示されることがあります。
この問題を解決するには、RHMAP からログアウトし、再びログインします。RHMAP により、新しいパブリックキーが作成され、デプロイメントに使用されます。
また、デプロイメントの実行前に、アクセストークンを再生成するよう要求されることもあります。
OpenShift Online クレデンシャルを入力し、Re-Generate Access Tokens をクリックします。
4.3.3.6. ドメイン
ドメインは OpenShift Online アプリケーション URL の一部 (たとえば、myApplication-domain.example.com) であり、多くのアプリケーションは単一のドメインにデプロイできます。ユーザーが定義できるドメインの数は現在のプランによって異なります。ドメインの詳細と管理方法については、OpenShift Online ドキュメンテーションを参照してください。
4.4. Google OAuth を使用した認証ポリシーのセットアップ
4.4.1. Google OAuth アプリ
アプリのユーザーの認証を Google の OAuth サービスに対して実行するには、最初に複数の手順を実行する必要があります。
- 最初に、Google API コンソールを使用して Google でアプリをセットアップする必要があります。アプリの作成時に Web アプリケーションを選択します。詳細は、後で更新されることがあるため、それほど重要ではありません。アプリが作成されたら、Google により提供されたクライアント ID とクライアントシークレットをメモしてください。
- クライアント ID は 00000000000.apps.googleusercontent.com のようになります。
- シークレットは数字および数値のハッシュです。
以下の図では、Google のコンソールでこれらの項目が赤で示されています。
ドメイン管理者権限を持つチームのユーザーとして Studio にログインし、Auth Policies タブをクリックします。次に Create ボタンをクリックして新しいポリシーを作成します。OAuth2 のタイプを選択し、Google によって提供された詳細を入力します。
注記Studio で Auth Policies タブにアクセスするには、ユーザーは Authorization Policy に対して View & Edit が設定されたチームのメンバーである必要があります。
- Auth Policy 作成ページで提供されたコールバック URL をアプリコンソールの Redirect URI 下の Google アプリに追加します。
4.4.2. 承認
承認パネルには 2 つのオプションがあります。
- ユーザーがプラットフォームに存在することを確認します。
- ユーザーが認証されているかどうかを確認します。
これらいずれかのオプションを選択しない場合は、適切な Google アカウントを持つすべてのユーザーがアプリにアクセスすることを許可すると見なされます。
4.4.2.1. ユーザーがプラットフォームに存在することを確認
このオプションでは、ユーザーが適切な Google アカウントを持ち、ユーザーが Google によって返された ID (例: "someuser@gmail.com") でプラットフォームで登録された場合、ユーザーはアプリケーションにアクセスすることが許可されます。
4.4.2.2. ユーザーが認証されているかどうかを確認
このオプションでは、ユーザーが適切な Google アカウントを持ち、Google によって返されたユーザー ID がこの認証ポリシーに関連付けられている場合、ユーザーはこの認証ポリシーに関連付けられたアプリケーションを使用することが許可されます。
4.4.3. 認証ポリシーに対するユーザーの追加/削除
既存のユーザーを認証ポリシーに追加するには、check if user is approved for Auth オプションをクリックします。スワップ選択が、利用可能なユーザーが入力された状態で表示されます。これらいずれかのユーザーをポリシーに追加するには、ユーザーを選択し、承認済み列の方向を向いた矢印を押します。ユーザーを削除するには、承認済み列でユーザーを選択し、利用可能な列の方向を向いた矢印をクリックします。
認証ポリシーの設定が完了したら、"Update Policy" ボタンをクリックします。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.