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/export API エンドポイントへの呼び出しで、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 動的設定プロパティーを使用して、ccompat API によって返されるサブジェクトの最大数をカスタマイズできるようになりました。
その他の変更点
  • コンテンツハッシュを使用したシリアライザー/デシリアライザーアーティファクトの解決: SerDe クラスは、スキーマのコンテンツハッシュを使用してアーティファクトの座標を解決できるようになりました。
  • Avro を縮小するための Maven プラグインオプション: Maven プラグインを使用して Avro スキーマを登録する場合に、登録前にコンテンツを縮小できるようになりました。
コミュニティーのみ: カスタムアーティファクトタイプ

独自のカスタムアーティファクトタイプを使用して Service Registry を拡張したり、既存のタイプのサポートを削除したりできます。この機能は、Service Registry のコミュニティーバージョンでのみ利用可能であり、サポート対象の機能ではありません。

注記

この機能を提供するために、REST API の ArtifactTypeenum から単純な string に変更されました。カスタム統合に REST API クライアントを使用する場合は、新しいクライアントにアップグレードした後にコードの編集が必要になる場合があります。

Service Registry Operator の新機能

HTTPS の Operator サポート
OpenShift クラスター内での HTTPS 接続の設定のサポートが追加されました。証明書と秘密鍵を含むシークレットをそれぞれ tls.crttls.key という名前で作成し、ApicurioRegistry カスタムリソース定義 (CRD) ファイルの spec.configuration.security.https.secretName フィールドを設定することでシークレットを参照できます。これにより、Service Registry Operator が、Service Registry の Service リソースに HTTPS ポートを設定できるようになります。HTTPS が有効な場合は、spec.security.https.disableHttptrue に設定することで HTTP 接続を無効にできます。
手動で管理される OpenShift リソースのサポート

特定のリソースタイプを無効にして、Service Registry Operator によるそのタイプのリソースの作成または管理を終了し、リソースを手動で設定できるようになりました。手動設定を使用すると、Service Registry Operator が現在サポートしていない機能をより柔軟に使用できます。リソースタイプを無効にすると、その既存のインスタンスは削除されます。リソースタイプを有効にすると、Service Registry Operator は、アプリラベル (例: app=example-apicurioregistry) を使用してリソースを検索し、その管理を開始しようとします。見つからない場合、Service Registry Operator は新しいインスタンスを作成します。この方法で、次のリソースタイプを無効にすることができます。

  • Ingress
  • NetworkPolicy
  • PodDisruptionBudget
ログレベル設定の改善
ApicurioRegistry CRD ファイルの spec.configuration.registryLogLevel フィールドを使用して、Service Registry と Service Registry Operator のログレベルをより簡単に設定できるようになりました。この新しいフィールドは、Apicurio 以外のコンポーネントおよびライブラリーに機能する spec.configuration.logLevel フィールドとは対照的に、Apicurio アプリケーションコンポーネント (Apicurio 以外のコンポーネントおよびライブラリーを除く) のログレベルを設定します。Operator の Deployment リソースで LOG_LEVEL 環境変数を設定することで、Service Registry Operator のログレベルを設定できるようになりました。有効な LOG_LEVEL 値は、debuginfowarn、および error です。
CORS で許可される送信元

サーバーは、Cross-Origin Resource Sharing (CORS) メカニズムを使用して、応答を要求の送信元と共有できるかどうかを制御できます。Service Registry Operator は、ApicurioRegistry CRD ファイルの 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 デプロイメントの設定

ApicurioRegistry CRD ファイルには、テクノロジープレビュー機能として spec.deployment.podTemplateSpecPreview フィールドが含まれるようになりました。spec.deployment.podTemplateSpecPreview フィールドは、OpenShift Deployment リソースの spec.template フィールドと構造 (PodTemplateSpec 構造体) が同じです。いくつかの制限がありますが、Service Registry Operator は、このフィールドのデータを、Service Registry の Deployment リソース内の対応するフィールドに転送します。この機能により、Apicurio Registry Operator で各ユースケースをネイティブにサポートする必要がなくなり、設定の柔軟性が向上します。

重要

テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat では、実稼働環境での使用を推奨していません。テクノロジープレビュー機能では、最新の製品機能をいち早く提供します。これにより、お客様は開発段階で機能をテストし、フィードバックを提供できます。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

Service Registry ユーザーのドキュメントおよび例

ドキュメントライブラリーは、バージョン 2.4 で利用可能な新機能で更新されました。

オープンソースのデモンストレーションアプリケーションも更新されました。