アドオンを共有可能にする
この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。
最終更新日 2024年02月06日(火)
Table of Contents
このガイドでは、既存の Heroku アドオンを「共有可能」にするプロセスを手順に沿って説明します。
ステージングアドオン
ステージング環境と、一般公開されている Heroku アドオンとは異なる対応する Heroku アドオンがある場合は、これらの変更をそこで広範囲にわたってテストしてからメインの製品にプロモートすることを強くお勧めします。
複数アプリアタッチメントのサポート
アドオンをアプリ間で共有可能にするには、マニフェスト内の requires 配列に attachable フラグを追加します。この機能にそれ以上の変更は必要ありません。
アプリあたり複数のインストールのサポート
アドオンサービスを同じアプリケーションに複数回インストールできるようにするには、次のようにします。
- マニフェスト内の
requires 配列にmany_per_app フラグを追加します。 - プロビジョニングリクエストの
heroku_id フィールドの一意性制約はすべて削除するようにしてください。 - 必要に応じて、Heroku 側の一意性には新しいプロビジョニング時の
uuid フィールドを使用します。- このフィールドは、新しいランタイムへのフラグが付けられたアドオンに対して、またはフラグが付けられているユーザーまたはアプリケーションからのプロビジョニングに対してのみ存在します。
- アプリごとに一意ではなく (つまり、
app123@heroku.com のようなheroku_id の派生ではなく)、インストールごとに一意の独自のプロビジョニングレスポンスid を返します。 - 必要に応じて、アプリ情報 API から
uuid フィールドをオプションでバックフィルします。 このフィールドは、移行とロールアウトが完了するまで、一部のインストールでは null である可能性があります。
many_per_app フラグが有効になっている場合、ユーザーは、環境変数へのプレフィックスとして使用されている “アタッチメント名” を上書きできます。
FOO_BAR_A と FOO_BAR_B を設定する foo-bar という名前のアドオンの場合は、これを文字列の先頭からアドオンサービス slug の正規化されたバリアントを取り除くのではなく、A と B を設定する操作として処理します。(将来の統合バージョンでは、サービスプレフィックスは必要なくなるが、現在は下位互換性のために必要です)
- A と B の前に、そのアプリケーションの観点からアタッチメント名が付加されます。
BALLOON という名前のアタッチメントの場合は、これによりBALLOON_A とBALLOON_B の変数が公開されます。 - アタッチメント名は、次のヒューリスティックで選択されます。
- ユーザーが指定した名前 (
WORKER など。競合する場合はエラー) - パートナーによって推奨される名前 (
REDIS など。競合する場合は次) - 正規化されたアドオンサービス slug (
REDISGREEN など。競合する場合は次) - 正規化されたアドオンサービス slug + ランダムな色 (
REDISGREEN_CYAN など。競合する場合は、新しいランダムな色を選択する。色のプールがなくなった場合はエラー)
- ユーザーが指定した名前 (
- カスタム名は将来、
many_per_app が有効になっていなくても許可される可能性があります。 - 推奨されたアタッチメント名を指定するには、プロビジョニングレスポンスで
recommended_prefix という名前のルートレベルのキーを返します。パートナーのフィードバックに基づいて、この推奨がマニフェストに移される可能性があります。
テストする内容
アドオンのすべての側面を実行して、上記の変更が機能に悪影響を与えていないことを確認してください。また、Heroku の統合に固有の次の動作がアドオンに適用される場合は、これらもテストします。
- 同じアプリの複数回のプロビジョニング (many-per-app をサポートすることを選択した場合)
- 1 つのインストールの同じアプリへの複数のアタッチメント
- 1 つのアプリへの複数のインストールのコンテキスト、および複数のアプリへのアタッチメントでの SSO
- カスタムのアタッチメント名前付け
- 環境設定の更新と、それがアタッチされたすべてのアプリケーションに伝播されることの確認
- プランのアップグレードとダウングレード