API スキーマの昇格
API スキーマを開発して設定するときに、本番に向けた次の環境に API スキーマを昇格して、その環境の統合スキーマに追加することができます。この場合、スキーマ設定のみが昇格され、基盤となる実際のソース REST API は昇格されません。
昇格により、ある環境で API スキーマを設定した後、後続の環境で同じ設定を繰り返す必要がなくなります。昇格を使用して、スキーマ設定を開発からステージング、ステージングから本番に移動します。
本番までのサイクルで API を昇格するために実行する手順は、各自のニーズによって異なります。たとえば、開発環境で開発して設定した Orders API をステージングに昇格するとします。この場合、次のような昇格シナリオが考えられます。
| 開発の Orders API のバージョン | ステージングの Orders API のバージョン | 昇格アクション | 昇格後のバージョン |
|---|---|---|---|
v3.1.0 |
なし |
Anypoint DataGraph で API スキーマとその設定が昇格される。 ユーザーが URL と認証方法を設定する。 |
v3.1.0 |
v3.1.1 |
v3.1.0 |
Anypoint DataGraph で既存の API スキーマのアセットバージョンが自動的に更新される。 ユーザーが URL と認証方法を設定する。 |
v3.1.1 |
v3.1.0 |
v3.1.0 |
Anypoint DataGraph でアセットバージョンのカスタマイズが更新される。 |
v3.1.0 |
v4.0.0 |
v3.1.0 |
Anypoint DataGraph で両方の API バージョンが対象環境に追加されて共存する。 ユーザーが v4.0.0 の URL と認証方法を設定する。 |
v3.1.0、v4.0.0 |
API を別の環境に昇格する
アクセス権のある任意の環境に API スキーマを昇格できます。
API は Exchange でパブリッシュする必要がありますが、API が Mule アプリケーションでなくても、あるいは Mule Runtime Engine や CloudHub で実行されていなくても、統合スキーマに追加できます。
昇格するスキーマが、対象環境の統合スキーマと競合しないようにします。競合が存在する場合は、API を手動で追加して、API を追加する場合と同じ方法で競合を解決する必要があります。
「寄稿」または「管理」権限が必要です。
|
Anypoint DataGraph から API にアクセスするためにサポートされている認証方法は次の手順に記載されています。それ以外の認証方法 (有効期間の短いトークン方式など) はサポートされていません。詳細は、「サポートされる認証方法」を参照してください。 |
API を昇格する手順は、次のとおりです。
-
[List of API added (追加された API のリスト)] をクリックし、昇格する API を選択します。
-
[Promote API schema (API スキーマを昇格)] をクリックします。
-
[Target environment (対象環境)] リストから、昇格の対象環境を選択します。
-
[Next: Configure URL (次へ: URL を設定)] をクリックします。
-
昇格シナリオに応じて、次の設定オプションのいずれかを選択できます。
-
API が API Manager で管理されているか、Exchange の API のインスタンスを追加した場合は、[Get an existing URL from Anypoint Platform (Anypoint Platform から既存の URL を取得)] を選択します。
-
独自の実装 URL を指定する場合は、[Add a new URL (新しい URL を追加)] を選択するか、[Use the URL in API specification (API 仕様の URL を使用)] をクリックします。
-
-
[Next: Provide Authentication (次へ: 認証を指定)] をクリックします。
-
[Provide authentication (認証の指定)] ページで、API の GET エンドポイントに追加する認証の種類を選択し、照会時に Anypoint DataGraph が API に要求を実行できるようにします。
-
No Auth (認証なし): API が公開の場合に使用します。
-
Basic Auth (基本認証): ユーザー名とパスワードを使用して API に対する認証を行う場合に使用します。
-
Pass-through (パススルー): 認証ヘッダーを渡して API に対する認証を行う場合に使用します。
-
Client ID enforcement via headers (ヘッダー経由のクライアント ID 適用):
client_id および client_secret ヘッダーを渡して API に対する認証を行う場合に使用します。 -
Client ID enforcement via query parameters (クエリパラメーター経由のクライアント ID 適用):
client_id および client_secret クエリパラメーターを渡して API に対する認証を行う場合に使用します。 -
OAuth 2.0 Client Credentials (OAuth 2.0 クライアントログイン情報): OAuth 2.0 の
client_id、client_secret、認証サーバーの値を渡して API に対する認証を行う場合に使用します。 -
Custom (カスタム): カスタムヘッダーパラメーターと値を使用して API に対する認証を行う場合に使用します。
-
-
必要に応じて、キーストアを追加し、API と DataGraph 間の相互認証 (mTLS) を設定します。
対象環境に既存の API を昇格する場合は、対象環境の API に既存のキーストアまたはトラストストアがあるかどうかがチェックされます。対象環境にキーストアまたはトラストストアが存在する場合は、既存のものを維持する、既存のものを削除する、既存のものを削除して新しいものを追加するのいずれかを選択できます。ソース環境のキーストアやトラストストアを対象環境に自動的に送信することはできません。ソース環境のキーストアやトラストストアを対象環境で使用するには、昇格プロセス中に削除して追加し直す必要があります。
[Configure Keystore (キーストアを設定)] を選択して次の情報を指定します。
-
組織の「ルート」認証機関 (CA) によって署名された公開証明書
-
証明書署名要求 (CSR) の生成に使用される非公開キー
-
非公開キーのパスワード
-
-
必要に応じて、トラストストアを追加して統合スキーマから API へのアクセスを許可します。
[Configure Truststore (トラストストアを設定)] を選択して、ルート CA が含まれる証明書バンドルを指定します。
-
[Next: Add to unified schema (次へ: 統合スキーマに追加)] をクリックします。
更新された API を昇格する
API バージョンを更新したら、更新されたバージョンを別の環境に昇格できます。
昇格する API の新しいバージョンを選択すると、対象環境で新しいバージョンに自動的に適用できない現在のバージョンへの編集が DataGraph にリストされます。
DataGraph で自動的に適用できない編集には、プロモーションを完了する前にそれらの編集を手動で適用するオプションがあります。
更新された API スキーマを昇格する前に、API バージョンを更新する必要があります。
-
[List of APIs added (追加された API のリスト)] をクリックし、該当する API を選択します。
-
[API details (API の詳細)] をクリックします。
-
[Promote API schema (API スキーマを昇格)] をクリックします。
-
[Target environment (対象環境)] リストから、昇格の対象環境を選択します。
-
[Next (次へ)] をクリックします。
-
DataGraph で適用できない変更が検出された場合、[Changes Not Applied (適用されない変更)] のリストを確認し、手動で適用します。
-
変更を選択し、[Next (次へ)] をクリックします。
-
必要に応じて API スキーマを編集し、[Apply Changes and Promote (変更を適用して昇格)] をクリックします。
変更を適用したら、追加の変更に対してステップ 5 を繰り返します。
-
-
[Next (次へ)] をクリックして、残りの昇格手順を完了します。