6.3. Service Registry の新機能
Service Registry 2.4 には、次の新機能が含まれています。
Service Registry コアの新機能
- アーティファクト参照の改善
- アーティファクト参照整合性ルール: 新しいアーティファクト固有のルールとグローバルルールを適用して、アーティファクトの作成または更新時にアーティファクト参照の整合性を強制的に確保できるようになりました。すべてのアーティファクトタイプについて、ルールは重複したアーティファクト参照を検出し、存在しないアーティファクトへの参照を防ぎます。アーティファクトタイプのサブセット (Apache Avro、Google Protobuf、OpenAPI、および AsyncAPI) の場合、ルールにより、すべてのアーティファクト参照がマッピングされることが保証されます。
- Maven プラグインでのアーティファクト参照の自動検出: アーティファクトタイプのサブセット (Apache Avro、Google Protobuf、および JSON スキーマ) について、アーティファクト作成時または更新時に、特定のアーティファクトのすべてのアーティファクト参照を Maven プラグインで自動的に識別して設定できるようになりました。
- Web コンソールでのアーティファクト参照の視覚化: 新しい References タブで、アーティファクトバージョンの受信参照と送信参照の両方を表示できるようになりました。REST API は、受信参照と送信参照の両方の取得をサポートするようになりました。以前は、REST API は送信参照のみを取得し、Web コンソールには参照が表示されませんでした。
- アーティファクト参照をコンテンツとして処理: このリリースで、コンテンツハッシュと ID を計算するとき、およびアーティファクトバージョンの互換性をチェックするときに、アーティファクト参照が考慮されるようになりました。同じスキーマコンテンツを異なる参照とともにアップロードすると、新しいアーティファクトバージョンが作成されます。
- クライアント SDK の生成 (OpenAPI)
- このリリースでは、ユーザーが OpenAPI アーティファクトからクライアント SDK を生成できるようにする新しい Web コンソール機能が追加されています。この機能は、Microsoft の Kiota を使用して SDK を生成します。この機能はブラウザー内でのみ実行され、API を使用して自動化できません。詳細は、https://github.com/microsoft/kiota を参照してください。
- アーティファクトのバージョンの削除
- このリリースでは、Web コンソールに新しい REST API 操作と新しい アーティファクトバージョンの削除 設定が追加され、REST API を使用してアーティファクトバージョンを削除できるようになります。以前のリリースでは、アーティファクトのバージョンは不変で、非推奨にしたり無効にしたりすることはできますが、削除できませんでした。ただし、このような意味合いがありますが、アーティファクトのバージョンを削除する必要がある場合があります。たとえば、規制またはポリシー上の理由により、アーティファクトのバージョンを削除する必要がある場合があります。
- Core Registry REST API の改善
- バージョンコメント API: REST API を使用して、アーティファクトバージョンにコメントを追加できるようになりました。コメントの管理は、Web コンソールではまだ利用できません。
-
エクスポート API が Accept ヘッダーで application/json をサポート:
/admin/exportAPI エンドポイントへの呼び出しで、Acceptヘッダーの値としてapplication/jsonを送信できるようになりました。以前のリリースでは、application/json形式の応答を返す唯一の方法は、forBrowserクエリーパラメーターを使用することでした。これで、クエリーパラメーターまたはAcceptヘッダーのいずれかを使用できるようになります。 - グループ管理: アーティファクト作成の一環としてアーティファクトグループを暗黙的に管理するのではなく、必要に応じて、REST API を使用してグループを直接管理できるようになりました。
- Confluent との互換性がある REST API の改善
- Confluent との互換性がある API のサポートを更新: Confluent Schema Registry API のバージョン 7 のサポートを追加しました。Service Registry は、異なるエンドポイントでの v6 と v7 の使用をサポートするようになりました。
-
カスタマイズ可能なサブジェクトの最大数:
registry.ccompat.max-subjects動的設定プロパティーを使用して、ccompatAPI によって返されるサブジェクトの最大数をカスタマイズできるようになりました。
- その他の変更点
-
コンテンツハッシュを使用したシリアライザー/デシリアライザーアーティファクトの解決:
SerDeクラスは、スキーマのコンテンツハッシュを使用してアーティファクトの座標を解決できるようになりました。 - Avro を縮小するための Maven プラグインオプション: Maven プラグインを使用して Avro スキーマを登録する場合に、登録前にコンテンツを縮小できるようになりました。
-
コンテンツハッシュを使用したシリアライザー/デシリアライザーアーティファクトの解決:
- コミュニティーのみ: カスタムアーティファクトタイプ
独自のカスタムアーティファクトタイプを使用して Service Registry を拡張したり、既存のタイプのサポートを削除したりできます。この機能は、Service Registry のコミュニティーバージョンでのみ利用可能であり、サポート対象の機能ではありません。
注記この機能を提供するために、REST API の
ArtifactTypeがenumから単純なstringに変更されました。カスタム統合に REST API クライアントを使用する場合は、新しいクライアントにアップグレードした後にコードの編集が必要になる場合があります。
Service Registry Operator の新機能
- HTTPS の Operator サポート
-
OpenShift クラスター内での HTTPS 接続の設定のサポートが追加されました。証明書と秘密鍵を含むシークレットをそれぞれ
tls.crtとtls.keyという名前で作成し、ApicurioRegistryカスタムリソース定義 (CRD) ファイルのspec.configuration.security.https.secretNameフィールドを設定することでシークレットを参照できます。これにより、Service Registry Operator が、Service Registry のServiceリソースに HTTPS ポートを設定できるようになります。HTTPS が有効な場合は、spec.security.https.disableHttpをtrueに設定することで HTTP 接続を無効にできます。 - 手動で管理される OpenShift リソースのサポート
特定のリソースタイプを無効にして、Service Registry Operator によるそのタイプのリソースの作成または管理を終了し、リソースを手動で設定できるようになりました。手動設定を使用すると、Service Registry Operator が現在サポートしていない機能をより柔軟に使用できます。リソースタイプを無効にすると、その既存のインスタンスは削除されます。リソースタイプを有効にすると、Service Registry Operator は、アプリラベル (例:
app=example-apicurioregistry) を使用してリソースを検索し、その管理を開始しようとします。見つからない場合、Service Registry Operator は新しいインスタンスを作成します。この方法で、次のリソースタイプを無効にすることができます。-
Ingress -
NetworkPolicy -
PodDisruptionBudget
-
- ログレベル設定の改善
-
ApicurioRegistryCRD ファイルのspec.configuration.registryLogLevelフィールドを使用して、Service Registry と Service Registry Operator のログレベルをより簡単に設定できるようになりました。この新しいフィールドは、Apicurio 以外のコンポーネントおよびライブラリーに機能するspec.configuration.logLevelフィールドとは対照的に、Apicurio アプリケーションコンポーネント (Apicurio 以外のコンポーネントおよびライブラリーを除く) のログレベルを設定します。Operator のDeploymentリソースでLOG_LEVEL環境変数を設定することで、Service Registry Operator のログレベルを設定できるようになりました。有効なLOG_LEVEL値は、debug、info、warn、およびerrorです。 - CORS で許可される送信元
サーバーは、Cross-Origin Resource Sharing (CORS) メカニズムを使用して、応答を要求の送信元と共有できるかどうかを制御できます。Service Registry Operator は、
ApicurioRegistryCRD ファイルのspec.deployment.hostフィールドの値に基づいて、CORS_ALLOWED_ORIGINS環境変数を設定するようになりました。この環境変数は、Service Registry によって送信されるAccess-Control-Allow-Originヘッダーを制御します。カスタム
Ingressを使用する場合 (たとえば、HTTPS を設定するため)、spec.deployment.managedResources.disableIngressフィールドをtrueに設定することで Operator 管理のIngressを無効にし、それでもspec.deployment.hostフィールドを適切な値に設定できます。完全にカスタマイズされた CORS ポリシーを設定する場合は、spec.deployment.hostフィールドを空に設定し、変更を適用してから、spec.deployment.envフィールドを使用してCORS_ALLOWED_ORIGINS環境変数を手動で設定します。- Pod テンプレートを使用した Service Registry デプロイメントの設定
ApicurioRegistryCRD ファイルには、テクノロジープレビュー機能としてspec.deployment.podTemplateSpecPreviewフィールドが含まれるようになりました。spec.deployment.podTemplateSpecPreviewフィールドは、OpenShiftDeploymentリソースのspec.templateフィールドと構造 (PodTemplateSpec構造体) が同じです。いくつかの制限がありますが、Service Registry Operator は、このフィールドのデータを、Service Registry のDeploymentリソース内の対応するフィールドに転送します。この機能により、Apicurio Registry Operator で各ユースケースをネイティブにサポートする必要がなくなり、設定の柔軟性が向上します。重要テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat では、実稼働環境での使用を推奨していません。テクノロジープレビュー機能では、最新の製品機能をいち早く提供します。これにより、お客様は開発段階で機能をテストし、フィードバックを提供できます。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Service Registry ユーザーのドキュメントおよび例
ドキュメントライブラリーは、バージョン 2.4 で利用可能な新機能で更新されました。
オープンソースのデモンストレーションアプリケーションも更新されました。