アドオンの仕組み

この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。

最終更新日 2024年02月06日(火)

Heroku のユーザーは、アドオンのプロビジョニングを行うためにマーケットプレイス​または Heroku CLI​ を使用します。Heroku からユーザーのサービスにリクエストが送信され、アプリ用に新しいプライベートリソースが作成されます。

このリソースはユーザーのサービスを表し、クライアントアプリケーションはこのリソースとやり取りを行います。

リソースを表す URI は環境設定​としてアプリで使用できます。アプリはサービスに応じてライブラリ、プラグイン、または HTTP 経由でプライベートリソースを使用します。

アドオンの概要

プロビジョニング

ユーザーによるアドオンの追加

プロビジョニング手順 1

プロビジョニングプロセスは、Heroku ユーザーがアドオンカタログでアドオンを見つけて Add​ (追加) をクリックすると開始されます。代わりにコマンドラインツールを使用することもできます。

$ heroku addons:create addon-name

Heroku によるサービスプロビジョニングのリクエスト

プロビジョニング手順 2

プロビジョニングされるリソースの構成は、使用しているサービスのタイプに応じて異なります。

ほぼすべてのケースにおいて、ユーザーアカウントをプロビジョニングする必要があります。ただし、データベースアドオンのパートナーはアプリがすぐに使用開始できるデータベースを即座に作成することもできますが、例外レポートサービスによって、ユーザー資格情報のほかに API キーが発行される場合があります。

リソース URL のリターン

プロビジョニング手順 3

リソースが作成されると、サービスによって、アプリがプライベートリソースへのアクセスに使用できる正確な場所と資格情報とともに URL が返されます。

たとえば、Amazon RDS のようなデータベースパートナーは以下を返す可能性があります。

MYSQL_URL=mysql://user:pass@mysqlhost.net/database

New Relic のような一般的なパートナーは以下を返す可能性があります。

NEW_RELIC_URL=http://newrelic.com/accounts/[apitoken]

Heroku によるアプリの再構築

プロビジョニング手順 4

Heroku は返された URL を環境設定​としてアプリに追加し、slug を再構築してすべての dyno​ を再起動します。これで、クラウドサービスによってプロビジョニングされたリソースをユーザーのアプリが消費できるようになります。

消費

消費手順 1

エンドユーザーが Web ブラウザからアプリに対してリクエストを行うと、アプリがリソースを消費する必要がある場合があります。または、アプリ内の Worker dyno が、バックグラウンドジョブ実行の一環でリソースを消費する必要がある場合があります。

たとえば、あるページが “SELECT * FROM table” などのクエリを送信してデータベースリソースを消費する、または POST /exceptions などの呼び出しによって Web サービスを消費する必要があることがあります。

アプリによるリソース URL へのアクセス

消費手順 2

アプリは、プロビジョニング時に環境設定としてアプリに保存された URL を使用して、リモートリソースにアクセスします。

MySQL、MongoDB、Memcache などのデータストアリソースには独自のプロトコルがあり、リソースへのアクセスには ActiveRecord、MongoMapper、MemcacheClient などのクライアントライブラリが使用されます。これらのリソースの URL は、mysql://、mongo://、memcache:// など、プロトコル名が冒頭に付きます。

Exceptional、New Relic などの Web サービスリソースでは HTTP をプロトコルとして使用するため、URL は https:// で始まります。

リソースの応答

消費手順 3

クラウドサービス内で起動されたリソースは、資格情報が有効であるとみなされ、リクエストを処理できます。

これが読み取りリクエスト (SQL の SELECT、HTTP の GET など) である場合、アプリに戻るための情報が検索されます。これが書き込みリクエスト (SQL の INSERT、HTTP の POST など) である場合、リソースに対する情報が保存され、確認が返されます。

応答を取得すると、アプリはこれを使用してエンドユーザー向けのページを構築 (Web リクエストを処理する dyno からのリクエストを消費する場合) したり、バックグラウンドジョブの処理を継続 (Worker dyno からのリクエストを消費する場合) したりできます。

環境設定およびアドオンセキュリティの更新

アドオンパートナーは、アドオン統合を通じて、提供された資格情報をいつでも更新できます。これは、資格情報の回転が必要な場合や、パートナー側で URL を変更する場合に行われます。そのため、アドオンから提供されている環境設定は上書きしないことをお勧めします。

アドオンは、アドオン自体がアプリに設定した環境設定の読み取りのみ行うことができ、ゼロ、1 つ、または複数の環境設定を設定できます。ユーザーが手動でアプリに設定した環境設定や、その他のアドオンによって設定された環境設定を読み取ることはできません。

シングルサインオン

Heroku Dashboard

SSO 手順 1

マニフェストを Heroku に提供すると、アドオンを Heroku のマーケットプレイスやダッシュボードに統合できるようにアドオンをシステムに対して記述したことになります。ダッシュボードは、ユーザーがアプリに関連付けられているリソースを管理する場所です。

Heroku ユーザーは、Heroku Dashboard​ にログインして、自身のアプリに関する情報を表示できます。

アドオンの選択

SSO 手順 2

アプリをクリックすると、アプリについての詳細ページに移動し、インストールされているすべてのアドオンがここに表示されます。ユーザーは一覧でアドオンを見つけてクリックします。

アドオンプロパティへのリダイレクト

Heroku では、リソースの ID、現在時刻、ソルト (Heroku およびユーザーのサービスの両方が認識している共有秘密鍵) を使用してシングルサインオントークンが生成されます。

これにより、以下のようなリクエストが生成されます。

POST https://yourcloudservice.net/sso/login
id=123&token=4af1e20905361a570&timestamp=1267592469&user@example.com

アドオンパートナーのサイトはこのリクエストを受信し、トークンが一致すること、タイムスタンプが最新であることを確認します。サイトはユーザーのブラウザに Cookie を設定してこれらが認証済みであることを示し、その後リソースの管理パネルにリダイレクトすることができます。

SSO を介したユーザーのログイン

SSO URL を使用して、サイトにユーザーをすばやくログインさせることができます。リンクはメールや Campfire の通知に添付でき、ユーザーがそのリンクをクリックすると、直接アドオンダッシュボードに移動します。

SSO URL は以下の形式に従います。

https://api.heroku.com/myapps/<heroku_id>/addons/<addon_name>

次に例を示します。

https://api.heroku.com/myapps/app123@heroku.com/addons/cloudcounter

追加情報は GET パラメータとして補足できます。追加のキーと値が残りのユーザーデータとともに SSO POST 経由で送信され、以下のように、ダッシュボード内でユーザーの関連する状態やコンテキストを設定することができます。

https://api.heroku.com/myapps/app123@heroku.com/addons/cloudcounter?issue_no=42