Service Registry ユーザーガイド


Red Hat Integration 2023.q4

Service Registry 2.5 でのスキーマおよび API の管理

Red Hat Integration Documentation Team

概要

このガイドでは、Service Registry を紹介し、Service Registry Web コンソール、REST API、Maven プラグイン、または Java クライアントを使用してイベントスキーマと API 設計を管理する方法を説明します。このガイドでは、Java コンシューマーおよびプロデューサーアプリケーションで Kafka クライアントシリアライザーとデシリアライザーを使用する方法についても説明します。また、サポートされる Service Registry コンテンツタイプおよび任意のルール設定についても説明します。

はじめに

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、用語の置き換えは、今後の複数のリリースにわたって段階的に実施されます。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

Red Hat ドキュメントへのフィードバック

Red Hat ドキュメントに関するご意見やご感想をお寄せください。

改善を提案するには、Jira 課題を作成し、変更案を説明してください。ご要望に迅速に対応できるよう、できるだけ詳細にご記入ください。

前提条件

  • Red Hat カスタマーポータルのアカウントがある。このアカウントを使用すると、Red Hat Jira Software インスタンスにログインできます。
    アカウントをお持ちでない場合は、アカウントを作成するように求められます。

手順

  1. Create issue にアクセスします。
  2. Summary テキストボックスに、問題の簡単な説明を入力します。
  3. Description テキストボックスに、次の情報を入力します。

    • 問題が見つかったページの URL
    • 問題の詳細情報
      他のフィールドの情報はデフォルト値のままにすることができます。
  4. Create をクリックして、Jira 課題をドキュメントチームに送信します。

フィードバックをご提供いただきありがとうございました。

第1章 Service Registry の概要

この章では、Service Registry の概念および機能を紹介し、レジストリーに保存されるサポート対象のアーティファクトタイプの詳細を提供します。

1.1. Service Registry とは

Service Registry は、イベント駆動型および API のアーキテクチャー全体で標準的なイベントスキーマおよび API 設計を共有するためのデータストアです。Service Registry を使用して、クライアントアプリケーションからデータの構造を切り離し、REST インターフェイスを使用して実行時にデータ型と API の記述を共有および管理できます。

クライアントアプリケーションは、再デプロイする必要なく、実行時に Service Registry との間で最新のスキーマ更新を動的にプッシュまたはプルできます。開発者チームは、Service Registry に対して、すでに運用環境にデプロイされているサービスに必要な既存のスキーマをクエリーしたり、開発中の新しいサービスに必要な新しいスキーマを登録したりできます。

クライアントアプリケーションコードで Service Registry の URL を指定することにより、クライアントアプリケーションが Service Registry に保存されているスキーマと API 設計を使用できるようにすることができます。Service Registry は、メッセージのシリアル化と逆シリアル化に使用されるスキーマを保存できます。これらのスキーマはクライアントアプリケーションから参照され、クライアントアプリケーションが送受信するメッセージがそれらのスキーマと互換性があることを確認します。

Service Registry を使用して、アプリケーションからデータ構造を切り離し、メッセージ全体のサイズを減らすことでコストを削減し、組織内のスキーマおよび API 設計の一貫性を高めて効率化します。Service Registry は、開発者および管理者がレジストリーコンテンツの管理を簡単に行えるように Web コンソールを提供します。

オプションのルールを設定して、Service Registry コンテンツの進化を管理できます。これらには、アップロードされたコンテンツが有効であること、または他のバージョンと互換性があることを確認するためのルールが含まれます。新しいバージョンを Service Registry にアップロードする前に、設定されたすべてのルールはパスする必要があります。これにより、無効または互換性のないスキーマまたは API 設計に時間が費やされることはありません。

Service Registry は、Apicurio Registry オープンソースコミュニティープロジェクトに基づいています。詳細は https://github.com/apicurio/apicurio-registry を参照してください。

Service Registry の機能
  • Apache Avro、JSON スキーマ、Google Protobuf、AsyncAPI、OpenAPI などの標準イベントスキーマおよび API 仕様の複数のペイロード形式。
  • AMQ Streams または PostgreSQL データベースのプラグイン可能な Service Registry ストレージオプション。
  • Service Registry のコンテンツが時間の経過とともにどのように進化するかを管理するための、コンテンツの検証、互換性、整合性に関するルール。
  • Web コンソール、REST API、コマンドライン、Maven プラグイン、または Java クライアントを使用した Service Registry コンテンツ管理。
  • 外部システム用の Kafka Connect との統合を含む、完全な Apache Kafka スキーマレジストリーサポート。
  • 実行時にメッセージタイプを検証する Kafka クライアントシリアライザー/デシリアライザー (SerDes)。
  • 既存の Confluent スキーマレジストリークライアントアプリケーションとの互換性。
  • メモリーフットプリントが低く、デプロイメントの時間が高速化されるクラウドネイティブ Quarkus Java ランタイム
  • OpenShift での Service Registry の Operator ベースのインストール。
  • Red Hat Single Sign-On を使用した OpenID Connect (OIDC) 認証

1.2. Service Registry のスキーマと API アーティファクト

イベントスキーマや API 設計などの Service Registry に保存される項目は、レジストリーアーティファクトと呼ばれます。以下は、単純な株価アプリケーションの JSON 形式の Apache Avro スキーマアーティファクトの例を示しています。

Avro スキーマの例

{
   "type": "record",
   "name": "price",
   "namespace": "com.example",
   "fields": [
       {
           "name": "symbol",
           "type": "string"
       },
       {
           "name": "price",
           "type": "string"
       }
   ]
}
Copy to Clipboard Toggle word wrap

スキーマまたは API 設計が Service Registry にアーティファクトとして追加されると、クライアントアプリケーションはそのスキーマまたは API 設計を使用して、実行時にクライアントメッセージが正しいデータ構造に準拠していることを検証できます。

スキーマと API のグループ

アーティファクトグループ は、スキーマまたは API アーティファクトのオプションの名前付きコレクションです。各グループには、論理的に関連したスキーマまたは API 設計のセットが含まれており、通常、特定のアプリケーションまたは組織に属する単一のエンティティーにより管理されます。

スキーマと API 設計を追加するときに、オプションのアーティファクトグループを作成して、Service Registry でそれらを整理できます。たとえば、development および production アプリケーション環境、あるいは sales および engineering 組織に一致するグループを作成できます。

スキーマおよび API グループには複数のアーティファクトタイプを含めることができます。たとえば、Protobuf、Avro、JSON スキーマ、OpenAPI、または AsyncAPI アーティファクトをすべて同じグループに含めることができます。

Service Registry Web コンソール、REST API、コマンドライン、Maven プラグイン、または Java クライアントアプリケーションを使用して、スキーマおよび API アーティファクトとグループを作成できます。次の簡単な例は、Core Registry REST API の使用を示しています。

$ curl -X POST -H "Content-type: application/json; artifactType=AVRO" \
  -H "X-Registry-ArtifactId: share-price" \
  --data '{"type":"record","name":"price","namespace":"com.example", \
   "fields":[{"name":"symbol","type":"string"},{"name":"price","type":"string"}]}' \
  https://my-registry.example.com/apis/registry/v2/groups/my-group/artifacts
Copy to Clipboard Toggle word wrap

この例では、my-group という名前のアーティファクトグループを作成し、アーティファクト ID が share-price の Avro スキーマを追加します。

注記

Service Registry Web コンソールを使用する場合、グループの指定はオプションであり、default グループが自動的に作成されます。REST API または Maven プラグインを使用し、一意のグループを作成したくない場合は API パスで default グループを指定します。

他のスキーマと API への参照

一部の Service Registry アーティファクトタイプには、別のアーティファクトファイルへの アーティファクト参照 を含めることができます。再利用可能なスキーマまたは API コンポーネントを定義し、それらを複数の場所から参照して効率を高めることができます。たとえば、$ref ステートメントを使用して JSON スキーマまたは OpenAPI で参照を指定したり、import ステートメントを使用して Google Protobuf で参照を指定したり、ネストされた名前空間を使用して Apache Avro で参照を指定したりできます。

次の例は、ネストされた名前空間を使用して Exchange という名前の別のスキーマへの参照を含む、TradeKey という名前の単純な Avro スキーマを示しています。

ネストされた Exchange スキーマを持つ TradeKey スキーマ

{
 "namespace": "com.kubetrade.schema.trade",
 "type": "record",
 "name": "TradeKey",
 "fields": [
   {
     "name": "exchange",
     "type": "com.kubetrade.schema.common.Exchange"
   },
   {
     "name": "key",
     "type": "string"
   }
 ]
}
Copy to Clipboard Toggle word wrap

交換スキーマ

{
 "namespace": "com.kubetrade.schema.common",
 "type": "enum",
 "name": "Exchange",
 "symbols" : ["GEMINI"]
}
Copy to Clipboard Toggle word wrap

アーティファクト参照は、アーティファクトタイプ固有の参照から内部 Service Registry 参照にマップされるアーティファクトメタデータのコレクションとして Service Registry に格納されます。Service Registry の各アーティファクト参照は、以下で構成されます。

  • グループ ID
  • アーティファクト ID
  • アーティファクトのバージョン
  • アーティファクト参照名

Service Registry コア REST API、Maven プラグイン、および Java シリアライザー/デシリアライザー (SerDes) を使用して、アーティファクト参照を管理できます。Service Registry は、アーティファクトコンテンツとともにアーティファクト参照を保存します。Service Registry は、すべてのアーティファクトリーファレンスのコレクションも保持しているため、コレクションを検索したり、特定のアーティファクトのすべてのリファレンスを一覧表示したりできます。

サポートされているアーティファクトタイプ

Service Registry は現在、次のアーティファクトタイプのアーティファクトリーファレンスのみをサポートしています。

  • Avro
  • Protobuf
  • JSON スキーマ
  • OpenAPI
  • AsyncAPI

1.3. Service Registry Web コンソールを使用したコンテンツの管理

Service Registry Web コンソールを使用して、レジストリーに保存されているスキーマと API アーティファクトおよびオプションのグループを閲覧および検索し、新しいスキーマと API アーティファクト、グループ、およびバージョンを追加できます。ラベル、名前、グループ、および説明でアーティファクトを検索できます。アーティファクトのコンテンツや利用可能なバージョンを表示するか、アーティファクトファイルをローカルでダウンロードできます。

また、レジストリーコンテンツのオプションのルールを、グローバルに、およびスキーマと API アーティファクトごとに設定することもできます。コンテンツの検証および互換性に関するこれらの任意のルールは、新しいスキーマと API アーティファクトまたはバージョンをレジストリーにアップロードする際に適用されます。

詳細は、10章Service Registry コンテンツルールのリファレンス を参照してください。

図1.1 Service Registry Web コンソール

Service Registry Web コンソールは http://MY_REGISTRY_URL/ui から利用できます。

1.4. クライアント用の Service Registry REST API

クライアントアプリケーションは、Core Registry API v2 を使用して、Service Registry のスキーマと API アーティファクトを管理できます。この API は、次の機能の操作を提供します。

管理者
Service Registry データを .zip ファイルにエクスポートまたはインポートし、実行時に Service Registry インスタンスのログレベルを管理します。
アーティファクト
Service Registry に保存されているスキーマと API アーティファクトを管理します。アーティファクトのライフサイクル状態 (enabled、disabled、または deprecated) を管理することもできます。
アーティファクトのメタデータ
スキーマまたは API アーティファクトに関する詳細を管理します。アーティファクト名、説明、ラベルなどの詳細を編集できます。アーティファクトグループ、アーティファクトが作成または変更された時期などの詳細は読み取り専用です。
アーティファクトルール
特定のスキーマまたは API アーティファクトのコンテンツの進化を管理するルールを設定して、無効または互換性のないコンテンツが Service Registry に追加されないようにします。アーティファクトルールは、設定されたグローバルルールを上書きします。
アーティファクトのバージョン
スキーマまたは API アーティファクトの更新時に作成されるバージョンを管理します。アーティファクトバージョンのライフサイクル状態: enabled、disabled、または deprecated を管理することもできます。
グローバルルール
無効または互換性のないコンテンツが Service Registry に追加されないようにするために、すべてのスキーマおよび API アーティファクトのコンテンツの進化を管理するルールを設定します。グローバルルールは、アーティファクトに独自の特定のアーティファクトルールが設定されていない場合にのみ適用されます。
検索
スキーマと API アーティファクトおよびバージョンを、名前、グループ、説明、ラベルなどで参照または検索します。
システム
Service Registry のバージョン、および Service Registry インスタンスのリソースの制限を取得します。
ユーザー
現在の Service Registry ユーザーを取得します。
他のスキーマレジストリー REST API との互換性

Service Registry は、それぞれの REST API の実装を含めることで、次のスキーマレジストリーとの互換性も提供します。

  • Service Registry Core Registry API v1
  • Confluent Schema Registry API v6
  • Confluent Schema Registry API v7
  • CNCF CloudEvents Schema Registry API v0

Confluent クライアントライブラリーを使用するアプリケーションは Service Registry をドロップイン置換として使用できます。詳細は、Confluent Schema Registry の置換 を参照してください。

1.5. Service Registry ストレージのオプション

Service Registry は、レジストリーデータの基礎となるストレージに対して以下のオプションを提供します。

Expand
表1.1 Service Registry データストレージオプション
ストレージオプション説明

PostgreSQL データベース

PostgreSQL は、実稼働環境でのパフォーマンス、安定性、およびデータ管理 (バックアップ/復元など) に推奨されるデータストレージオプションです。

AMQ Streams

Kafka ストレージは、データベース管理の専門知識が利用できない実稼働環境、または Kafka のストレージが特定の要件である実稼働環境向けに提供されています。

Kafka プロデューサーアプリケーションは、シリアライザーを使用して、特定のイベントスキーマに準拠するメッセージをエンコードできます。Kafka コンシューマーアプリケーションはデシリアライザーを使用して、特定のスキーマ ID に基づいてメッセージが適切なスキーマを使用してシリアライズされたことを検証できます。

図1.2 Service Registry および Kafka クライアント SerDes アーキテクチャー

Service Registry は、実行時に以下のメッセージタイプを検証するために Kafka クライアントシリアライザー/デシリアライザー (SerDes) を提供します。

  • Apache Avro
  • Google Protobuf
  • JSON スキーマ

Service Registry の Maven リポジトリーとソースコードの配布には、これらのメッセージタイプの Kafka SerDes 実装が含まれており、Kafka クライアントアプリケーションの開発者は、これを使用して、Service Registry と統合できます。

これらの実装には、サポートされている各メッセージタイプのカスタム Java クラスが含まれています。たとえば、io.apicurio.registry.serde.avro などです。クライアントアプリケーションは、検証のために実行時に Service Registry からスキーマをプルするために使用できます。

1.7. Kafka Connect コンバーターを使用した外部システムへのデータのストリーミング

Apache Kafka Connect と Service Registry を使用して、Kafka と外部システム間でデータをストリーミングできます。Kafka Connect を使用すると、異なるシステムのコネクターを定義して、大量のデータを Kafka ベースのシステムに出し入れできます。

図1.3 Service Registry および Kafka Connect アーキテクチャー

Service Registry は、Kafka Connect に次の機能を提供します。

  • Kafka Connect スキーマのストレージ
  • Apache Avro および JSON スキーマの Kafka Connect コンバーター
  • スキーマを管理するコアレジストリー API

Avro および JSON スキーマコンバーターを使用して、Kafka Connect スキーマを Avro または JSON スキーマにマッピングすることができます。これらのスキーマは、メッセージのキーと値をコンパクトな Avro バイナリー形式または人間が判読できる JSON 形式にシリアライズすることができます。メッセージにはスキーマ情報が含まれず、スキーマ ID のみが含まれるため、変換された JSON は冗長性が低くなります。

Service Registry は、Kafka トピックで使用される Avro および JSON スキーマを管理および追跡できます。スキーマは Service Registry に保存され、メッセージコンテンツから切り離されるため、各メッセージには小さなスキーマ識別子だけを含める必要があります。Kafka など I/O 律速のシステムの場合、これはプロデューサーおよびコンシューマーのトータルスループットが向上することを意味します。

Service Registry が提供する Avro および JSON スキーマのシリアライザーとデシリアライザー (SerDes) は、このユースケースの Kafka プロデューサーとコンシューマーによって使用されます。変更イベントを消費するために作成する Kafka コンシューマーアプリケーションは、Avro または JSON SerDes を使用して、これらのイベントを逆シリアル化できます。Service Registry SerDes は、Kafka ベースのシステムにインストールし、Kafka Connect や Debezium などの Kafka Connect ベースのシステムと共に使用できます。

1.8. Service Registry デモ例

Service Registry は、異なるユースケースで Service Registry を使用する方法を示すオープンソースサンプルアプリケーションを提供します。たとえば、これらには、Kafka シリアライザーおよびデシリアライザー (SerDes) Java クラスで使用されるスキーマの保存が含まれます。これらのクラスは、Service Registry からスキーマをフェッチして、Kafka メッセージペイロードをシリアル化、逆シリアル化、または検証する操作を生成または使用するときに使用します。

これらのアプリケーションは、次の例のような使用例を示しています。

  • Apache Avro Kafka SerDes
  • Apache Avro Maven プラグイン
  • Apache Camel Quarkus と Kafka
  • CloudEvents
  • Confluent Kafka SerDes
  • Custom ID strategy
  • Debezium を使用したイベント駆動型のアーキテクチャー
  • Google Protobuf Kafka SerDes
  • JSON Schema Kafka SerDes
  • REST クライアント

1.9. Service Registry で利用可能なディストリビューション

Service Registry には、次のディストリビューションオプションがあります。

Expand
表1.2 Service Registry Operator およびイメージ
ディストリビューション場所リリースカテゴリー

Service Registry Operator

OperatorsOperatorHub の OpenShift Web コンソール

一般公開 (GA)

Service Registry Operator のコンテナーイメージ

Red Hat Ecosystem Catalog

一般公開 (GA)

AMQ Streams での Kafka ストレージのコンテナーイメージ

Red Hat Ecosystem Catalog

一般公開 (GA)

PostgreSQL でのデータベースストレージのコンテナーイメージ

Red Hat Ecosystem Catalog

一般公開 (GA)

Expand
表1.3 Service Registry zip ダウンロード
ディストリビューション場所リリースカテゴリー

インストール用のサンプルカスタムリソース定義

Red Hat ソフトウェアのダウンロード

一般公開 (GA)

Service Registry v1 to v2 migration tool

Red Hat ソフトウェアのダウンロード

一般公開 (GA)

Maven リポジトリー

Red Hat ソフトウェアのダウンロード

一般公開 (GA)

Source code

Red Hat ソフトウェアのダウンロード

一般公開 (GA)

Kafka Connect converters

Red Hat ソフトウェアのダウンロード

一般公開 (GA)

注記

利用可能な Service Registry ディストリビューションにアクセスするには、Red Hat Integration のサブスクリプションが必要で、Red Hat カスタマーポータルにログインする必要があります。

第2章 Service Registry のコンテンツルール

この章では、Service Registry のコンテンツを管理するために使用されるオプションのルールを紹介し、利用可能なルール設定の詳細を提供します。

2.1. ルールを使用して、Service Registry コンテンツを管理する

Service Registry に追加されたアーティファクトコンテンツのデプロイメントを管理するために、オプションのルールを設定できます。新しいアーティファクトバージョンを Service Registry にアップロードする前に、設定済みのすべてのグローバルルールまたはアーティファクト固有のルールはパスする必要があります。設定されたアーティファクト固有のルールは、設定されたグローバルルールをオーバーライドします。

これらのルールの目的は、無効なコンテンツが Service レジストリーに追加されないようにすることです。たとえば、次の理由でコンテンツが無効になる可能性があります。

  • 特定のアーティファクトタイプ (AVROPROTOBUF など) の構文が無効
  • 有効な構文で、セマンティクスが仕様に違反している
  • 新しいコンテンツに現在のアーティファクトバージョンに関連する変更の違反が含まれる場合の非互換性
  • アーティファクト参照の整合性 (重複または存在しないアーティファクト参照マッピングなど)

Service Registry Web コンソール、REST API コマンド、または Java クライアントアプリケーションを使用して、任意のコンテンツルールを有効にできます。

2.1.1. ルールの適用時

ルールは、コンテンツが Service Registry に追加された場合のみ、適用されます。これには、以下の REST 操作が含まれます。

  • アーティファクトの追加
  • アーティファクトの更新
  • アーティファクトバージョンの追加

ルールに違反した場合、Service Registry は HTTP エラーを返します。応答本文には、違反したルールと、何が問題だったのかを示すメッセージが含まれます。

2.1.2. ルールの優先順位

アーティファクト固有のルールとグローバルルールの優先順位は次のとおりです。

  • アーティファクト固有のルールを有効にし、同等のグローバルルールが有効になっている場合、アーティファクトルールはグローバルルールをオーバーライドします。
  • アーティファクト固有のルールを無効にし、同等のグローバルルールが有効になっている場合は、グローバルルールが適用されます。
  • アーティファクト固有のルールを無効にし、同等のグローバルルールが無効になっている場合、そのルールはすべてのアーティファクトに対して無効になります。
  • アーティファクトレベルでルール値を NONE に設定すると、有効なグローバルルールがオーバーライドされます。この場合、アーティファクトルール値 NONE がこのアーティファクトでは優先されますが、有効なグローバルルールは、ルールがアーティファクトレベルで無効になっている他のすべてのアーティファクトに引き続き適用されます。

2.1.3. ルールの仕組み

各ルールには、名前と設定情報があります。Service Registry は、各アーティファクトのルールのリストとグローバルルールのリストを維持します。リスト内の各ルールは、ルール実装の名前と設定で構成されます。

アーティファクトの現在のバージョン (存在する場合) および追加されるアーティファクトの新しいバージョンのコンテンツを含むルールが提供されます。ルール実装は、アーティファクトがルールを渡すかどうかに応じて true または false を返します。そうでない場合、Service Registry は HTTP エラー応答で理由を報告します。一部のルールは、コンテンツの以前のバージョンを使用しない場合があります。たとえば、互換性ルールは以前のバージョンを使用しますが、構文またはセマンティック妥当性ルールは使用しません。

2.1.4. コンテンツルールの設定

管理者は、Service Registry のグローバルルールとアーティファクト固有のルールを設定できます。開発者は、アーティファクト固有のルールのみを設定できます。

Service Registry は、特定のアーティファクトに設定したルールを適用します。そのレベルでルールが設定されていない場合、Service Registry はグローバルに設定されたルールを適用します。グローバルルールが設定されていない場合は、ルールが適用されません。

アーティファクトルールの設定

Service Registry Web コンソールまたは REST API を使用してアーティファクトルールを設定できます。詳細は以下を参照してください。

グローバルルールの設定

管理者は、いくつかの方法でグローバルルールを設定できます。

  • REST API で admin/rules 操作を使用する方法
  • Service Registry Web コンソールを使用する方法
  • Service Registry アプリケーションプロパティーを使用してデフォルトのグローバルルールを設定する方法

デフォルトのグローバルルールの設定

開発者は、アプリケーションレベルで Service Registry を設定して、グローバルなルールを有効または無効にすることができます。以下のアプリケーションプロパティー形式を使用して、インストール後の設定を行わずに、インストール時にデフォルトのグローバルルールを設定できます。

registry.rules.global.<ruleName>
Copy to Clipboard Toggle word wrap

現在、以下のルール名がサポートされています。

  • compatibility
  • validity
  • integrity

application プロパティーの値は、設定されたルールに固有の有効な設定オプションである必要があります。

注記

これらのアプリケーションプロパティーは、Java システムプロパティーとして設定することも、Quarkus application.properties ファイルに含めることもできます。詳細は、Quarkus のドキュメント を参照してください。

第3章 Web コンソールを使用した Service Registry コンテンツの管理

Service Registry Web コンソールを使用して、Service Registry に保存されているスキーマおよび API アーティファクトを管理できます。これには、Service Registry コンテンツのアップロードと参照、コンテンツのオプションルールの設定、およびクライアント SDK コードの生成が含まれます。

3.1. Service Registry Web コンソールを使用したアーティファクトの表示

Service Registry Web コンソールを使用して、Service Registry に保存されているスキーマと API アーティファクトを参照できます。このセクションでは、Service Registry アーティファクト、グループ、バージョン、およびアーティファクトルールを表示する簡単な例を紹介します。

前提条件

  • Service Registry が環境にインストールされ、実行している。
  • Service Registry Web コンソールにログインしている。

    http://MY_REGISTRY_URL/ui

  • Web コンソール、コマンドライン、Maven プラグイン、または Java クライアントアプリケーションを使用して、アーティファクトが Service Registry に追加されている。

手順

  1. アーティファクト タブで、Service Registry に保存されているアーティファクトのリストを参照するか、検索文字列を入力してアーティファクトを見つけます。リストから選択して、名前、グループ、ラベル、グローバル ID などの特定の条件で検索できます。

    図3.1 Service Registry Web コンソールでのアーティファクト

  2. アーティファクトをクリックすると、次の詳細が表示されます。

    • Overview: アーティファクト名、アーティファクト ID、グローバル ID、コンテンツ ID、ラベル、プロパティーなどのアーティファクトバージョンメタデータを表示します。また、アーティファクトコンテンツに対して設定できる有効性および互換性のルールも表示されます。
    • Documentation (OpenAPI および AsyncAPI のみ): 自動生成された REST API ドキュメントを表示します。
    • Content: 全アーティファクトコンテンツの読み取り専用ビューを表示します。JSON コンテンツの場合、JSON または YAML をクリックして、好みの形式を表示できます。
    • References: このアーティファクトによって参照されるすべてのアーティファクトの読み取り専用ビューを表示します。View artifacts that reference this artifact クリックすることもできます。
  3. このアーティファクトの追加バージョンが追加されている場合は、ページヘッダーの Version リストから選択できます。
  4. アーティファクトの内容を my-openapi.json または my-protobuf-schema.proto などのローカルファイルに保存するには、ページの最後にある Download をクリックします。

3.2. Service Registry Web コンソールを使用したアーティファクトの追加

Service Registry Web コンソールを使用して、スキーマと API アーティファクトを Service Registry にアップロードできます。このセクションでは、Service Registry アーティファクトをアップロードし、新しいアーティファクトバージョンを追加する簡単な例を示します。

前提条件

  • Service Registry が環境にインストールされ、実行している。
  • Service Registry Web コンソールにログインしている。

    http://MY_REGISTRY_URL/ui

手順

  1. Artifacts タブで Upload artifact をクリックし、次の詳細を指定します。

    • Group & ID: デフォルトの空の設定を使用して、アーティファクト ID を自動的に生成し、アーティファクトを default のアーティファクトグループに追加します。または、オプションのアーティファクトグループ名または ID を入力することもできます。
    • Type: デフォルトの Auto-Detect 設定を使用してアーティファクトタイプを自動的に検出し、リストからアーティファクトタイプを選択します (例: Avro Schema または OpenAPI)。自動検出できない Kafka Connect Schema アーティファクトタイプを手動で選択する必要があります。
    • Artifact: 次のいずれかのオプションを使用して、アーティファクトの場所を指定します。

      • From file: Browse をクリックしてファイルを選択するか、ファイルをドラッグアンドドロップします。たとえば、my-openapi.json または my-schema.proto です。または、テキストボックスにファイルの内容を入力することもできます。
      • From URL: 有効かつアクセス可能な URL を入力し、Fetch をクリックします。例: https://petstore3.swagger.io/api/v3/openapi.json
  2. Upload をクリックし、アーティファクトの詳細を表示します。

    • Overview: アーティファクト名、アーティファクト ID、グローバル ID、コンテンツ ID、ラベル、プロパティーなどのアーティファクトバージョンメタデータを表示します。また、アーティファクトコンテンツに対して設定できる有効性および互換性のルールも表示されます。
    • Documentation (OpenAPI および AsyncAPI のみ): 自動生成された REST API ドキュメントを表示します。
    • Content: 全アーティファクトコンテンツの読み取り専用ビューを表示します。JSON コンテンツの場合、JSON または YAML をクリックして、好みの形式を表示できます。
    • References: このアーティファクトによって参照されるすべてのアーティファクトの読み取り専用ビューを表示します。View artifacts that reference this artifact クリックすることもできます。Service Registry Maven プラグインまたは REST API のみを使用して、アーティファクト参照を追加できます。

      次の例は、OpenAPI アーティファクトの例を示しています。

      図3.2 Service Registry Web コンソールのアーティファクトの詳細

  3. Overview タブで、Edit 鉛筆アイコンをクリックして、名前や説明などのアーティファクトメタデータを編集します。

    オプションで、検索用のラベルのコンマ区切りリストを入力したり、アーティファクトに関連付けられた任意のプロパティーのキーと値のペアを追加したりすることもできます。プロパティーを追加するには、次の手順を実行します。

    1. Add property をクリックします。
    2. キー名と値を入力します。
    3. 複数のプロパティーを追加するには、最初の 2 つの手順を繰り返します。
    4. Save をクリックします。
  4. アーティファクトの内容を my-protobuf-schema.proto または my-openapi.json などのローカルファイルに保存するには、ページの最後にある Download をクリックします。
  5. 新しいアーティファクトバージョンを追加するには、ページヘッダーで Upload new version をクリックし、ドラッグアンドドロップするか Browse をクリックして、my-avro-schema.jsonmy-openapi.json などのファイルをアップロードします。
  6. アーティファクトを削除するには、ページヘッダーの Delete をクリックします。

    警告

    アーティファクトを削除すると、アーティファクトとそのバージョンがすべて削除され、元に戻すことはできません。

3.3. Service Registry Web コンソールを使用したコンテンツルールの設定

Service Registry Web コンソールを使用して、オプションのルールを設定し、無効なコンテンツまたは互換性のないコンテンツが Service Registry に追加されないようにします。新しいアーティファクトバージョンを Service Registry にアップロードする前に、設定済みのすべてのアーティファクト固有のルールまたはグローバルルールはパスする必要があります。設定されたアーティファクト固有のルールは、設定されたグローバルルールをオーバーライドします。このセクションでは、グローバルルールとアーティファクト固有のルールを設定する簡単な例を紹介します。

前提条件

  • Service Registry が環境にインストールされ、実行している。
  • Service Registry Web コンソールにログインしている。

    http://MY_REGISTRY_URL/ui

  • Web コンソール、コマンドライン、Maven プラグイン、または Java クライアントアプリケーションを使用して、アーティファクトが Service Registry に追加されている。
  • ロールベースの認可が有効になっている場合に、グローバルルールとアーティファクト固有のルールに対する管理者アクセス権、またはアーティファクト固有のルールのみに対する開発者アクセス権が付与されている。

手順

  1. Artifacts タブで、Service Registry のアーティファクトのリストを参照するか、検索文字列を入力してアーティファクトを見つけます。リストから選択して、アーティファクト名、グループ、ラベル、またはグローバル ID などの特定の基準で検索できます。
  2. アーティファクトをクリックして、そのバージョンの詳細とコンテンツルールを表示します。
  3. Artifact-specific rules で、Enable をクリックしてアーティファクトコンテンツの有効性、互換性、または整合性ルールを設定し、リストから適切なルール設定を選択します。たとえば、Validity rule では、Full を選択します。

    図3.3 Service Registry Web コンソールのアーティファクトコンテンツルール

  4. グローバルルールにアクセスするには、Global rules タブをクリックします。Enable をクリックして、すべてのアーティファクトコンテンツに対してグローバルな有効性、互換性または整合性のルールを設定し、リストから適切なルール設定を選択します。
  5. アーティファクトルールまたはグローバルルールを無効にするには、ルールの横にあるゴミ箱アイコンをクリックします。

Service Registry Web コンソールを使用して、OpenAPI アーティファクトのクライアントソフトウェア開発キット (SDK) を設定、生成、ダウンロードできます。続いて、生成されたクライアント SDK を使用して、OpenAPI に基づいて特定のプラットフォーム用のクライアントアプリケーションを構築できます。

Service Registry は、次のプログラミング言語用のクライアント SDK を生成します。

  • C#
  • Go
  • Java
  • PHP
  • Python
  • Ruby
  • Swift
  • TypeScript
注記

OpenAPI アーティファクトのクライアント SDK の生成はブラウザー内でのみ実行され、API を使用して自動化することはできません。新しいアーティファクトバージョンが Service Registry に追加されるたびに、クライアント SDK を再生成する必要があります。

前提条件

  • Service Registry が環境にインストールされ、実行している。
  • Service Registry Web コンソールにログインしている。

    http://MY_REGISTRY_URL/ui

  • Web コンソール、コマンドライン、Maven プラグイン、または Java クライアントアプリケーションを使用して、OpenAPI アーティファクトが Service Registry に追加されました。

手順

  1. Artifacts タブで、Service Registry に保存されているアーティファクトのリストを参照するか、検索文字列に入力して特定の OpenAPI アーティファクトを見つけます。リストから選択して、名前、グループ、ラベル、グローバル ID などの条件で検索できます。
  2. リスト内の OpenAPI アーティファクトをクリックして、その詳細を表示します。
  3. Version metadata セクションで、Generate client SDK をクリックし、ダイアログで以下を設定します。

    • Language: クライアント SDK を生成するプログラミング言語 (Java など) を選択します。
    • Generated client class name: クライアント SDK のクラス名 (例: MyJavaClientSDK.) を入力します。
    • Generated client package name: クライアント SDK のパッケージ名 (例: io.my.example.sdk) を入力します。
  4. Show advanced settings をクリックして、包含または除外するパスパターンのオプションのコンマ区切りリストを設定します。

    • Include path patterns: クライアント SDK の生成時に含める特定のパス (例: **/.*, **/my-path/*) を入力します。このフィールドが空の場合、すべてのパスが含まれています。
    • Exclude path patterns: クライアント SDK の生成時に除外する特定のパス (例: **/my-other-path/*) を入力します。このフィールドが空の場合、すべてのパスは除外されません。

      図3.4 Service Registry Web コンソールでの Java クライアント SDK の生成

  5. ダイアログで設定を行ったら、Generate and download をクリックします。
  6. ダイアログにクライアント SDK のファイル名 (例: my-client-java.zip) を入力し、Save をクリックしてダウンロードします。

3.5. Service Registry Web コンソールを使用したアーティファクト所有者の変更

管理者として、またはスキーマまたは API アーティファクトの所有者として、Service Registry Web コンソールを使用して、アーティファクトの所有者を別のユーザーアカウントに変更できます。

たとえば、この機能は、所有者または管理者のみがアーティファクトを変更できるように、Settings タブで Service Registry インスタンスに対して アーティファクトの所有者のみの許可 オプションが設定されている場合に役立ちます。所有者ユーザーが組織を離れた場合、または所有者アカウントが削除された場合は、所有者の変更が必要になる場合があります。

注記

アーティファクトの所有者のみの承認 設定とアーティファクトの 所有者 フィールドは、Service Registry インスタンスのデプロイ時に認証が有効になっている場合に のみ 表示されます。詳細は、Installing and deploying Service Registry on OpenShiftを参照してください。

前提条件

  • Service Registry インスタンスがデプロイされ、アーティファクトが作成されている。
  • アーティファクトの現在の所有者または管理者として Service Registry Web コンソールにログインしている。

    http://MY_REGISTRY_URL/ui

手順

  1. アーティファクト タブで、Service Registry に保存されているアーティファクトのリストを参照するか、検索文字列を入力してアーティファクトを見つけます。リストから選択して、名前、グループ、ラベル、グローバル ID などの条件で検索できます。
  2. 再割り当てするアーティファクトをクリックします。
  3. Version metadata セクションで、Owner フィールドの横にある鉛筆アイコンをクリックします。
  4. New owner フィールドで、アカウント名を選択または入力します。
  5. Change owner をクリックします。

3.6. Web コンソールを使用した Service Registry インスタンス設定の設定

管理者は、Service Registry Web コンソールを使用して、実行時に Service Registry インスタンスの動的設定を指定できます。認証、承認、API 互換性などの機能の設定オプションを管理できます。

注記

Service Registry インスタンスのデプロイ時に認証がすでに有効になっている場合、認証と承認の設定は Web コンソールにのみ表示されます。詳細は、OpenShift での Service Registry のインストールおよびデプロイ を参照してください。

前提条件

  • Service Registry インスタンスがすでにデプロイされている。
  • 管理者アクセスで Service Registry Web コンソールにログインしている。

    http://MY_REGISTRY_URL/ui

手順

  1. Service Registry Web コンソールで、Settings タブをクリックします。
  2. この Service Registry インスタンスに対して設定するオプションを選択します。

    Expand
    表3.1 認証設定
    設定説明

    HTTP Basic 認証

    認証が有効な場合のみ表示されます。選択すると、Service Registry ユーザーは、OAuth に加えて HTTP 基本認証を使用して認証できます。デフォルトでは選択されていません。

    Expand
    表3.2 認可設定
    設定説明

    匿名の読み取りアクセス

    すでに認証が選択されている場合のみ表示されます。選択すると、Service Registry は、認証情報がない匿名ユーザーからの要求に対して、読み取り専用アクセスを許可します。この設定は、このインスタンスを使用してスキーマまたは API を外部に公開する場合に役立ちます。デフォルトでは選択されていません。

    アーティファクトの所有者のみの承認

    認証が有効な場合のみ表示されます。選択すると、アーティファクトを作成したユーザーのみがそのアーティファクトを変更できます。デフォルトでは選択されていません。

    アーティファクトグループの所有者のみの承認

    認証がすでに有効で、Artifact 所有者のみの許可 が選択されている場合にのみ表示されます。選択すると、アーティファクトグループを作成したユーザーのみが、そのアーティファクトグループへの書き込みアクセス権 (そのグループのアーティファクトの追加や削除など) を持ちます。デフォルトでは選択されていません。

    認証された読み取りアクセス

    認証が有効な場合のみ表示されます。選択すると、Service Registry は、ユーザーロールに関係なく、認証されたユーザーからのリクエストに対して、少なくとも読み取り専用アクセスを許可します。デフォルトでは選択されていません。

    Expand
    表3.3 互換性設定
    設定説明

    レガシー ID モード (互換 API)

    選択すると、Confluent Schema Registry 互換性 API は contentId の代わりに globalId をアーティファクト識別子として使用します。この設定は、v1 Core Registry API をベースにする、従来の Service Registry インスタンスから移行する場合に役立ちます。デフォルトでは選択されていません。

    Expand
    表3.4 Web コンソールの設定
    設定説明

    ダウンロードリンクの有効期限

    インスタンスからアーティファクトデータをエクスポートする場合など、セキュリティー上の理由で有効期限が切れる前に、生成された .zip ダウンロードファイルへのリンクがアクティブである秒数。デフォルトは 30 秒です。

    UI 読み取り専用モード

    選択すると、Service Registry Web コンソールが読み取り専用に設定され、作成、読み取り、更新、または削除操作が禁止されます。Core Registry API を使用して行われた変更は、この設定の影響を受けません。デフォルトでは選択されていません。

    Expand
    表3.5 追加のプロパティー
    設定説明

    アーティファクトバージョンの削除

    選択した場合、ユーザーは Core Registry API を使用して、このインスタンスのアーティファクトバージョンを削除できます。デフォルトでは選択されていません。

3.7. Service Registry Web コンソールを使用したデータのエクスポートとインポート

管理者は、Service Registry Web コンソールを使用して、ある Service Registry インスタンスからデータをエクスポートし、このデータを別の Service Registry インスタンスにインポートできます。この機能を使用して、異なるインスタンス間でデータを簡単に移行できます。

次の例は、Service Registry インスタンス間で .zip ファイル内の既存のデータをエクスポートおよびインポートする方法を示しています。Service Registry インスタンスに含まれるすべてのアーティファクトデータは、.zip ファイルにエクスポートされます。

注記

別の Service Registry インスタンスからエクスポートされた Service Registry データのみをインポートできます。

前提条件

  • Service Registry インスタンスは次のように作成されている。

    • エクスポート元のソースインスタンスには、少なくとも 1 つのスキーマまたは API アーティファクトが含まれている
    • インポート先のターゲットインスタンスは、一意の ID を保持するために空である
  • 管理者アクセスで Service Registry Web コンソールにログインしている。

    http://MY_REGISTRY_URL/ui

手順

  1. ソース Service Registry インスタンスの Web コンソールで、Artifacts タブを表示します。
  2. Upload artifact の横にあるオプションアイコン (3 つの縦のドット) をクリックし、Download all artifacts (.zip file) を選択して、この Service Registry インスタンスのデータを .zip ダウンロードファイルにエクスポートします。
  3. ターゲット Service Registry インスタンスの Web コンソールで、Artifacts タブを表示します。
  4. Upload artifact の横にあるオプションアイコンをクリックし、Upload multiple artifacts を選択します。
  5. 以前にエクスポートした .zip ダウンロードファイルをドラッグアンドドロップするか、参照します。
  6. Upload をクリックして、データがインポートされるまで待ちます。

第4章 REST API を使用した Service Registry コンテンツの管理

クライアントアプリケーションは、Service Registry REST API オペレーションを使用して、Service Registry のスキーマと API アーティファクトを管理できます。たとえば、実稼働環境にデプロイされた CI/CD パイプラインで使用できます。Core Registry API v2 は、Service Registry に保存されているアーティファクト、バージョン、メタデータ、およびルールの操作を提供します。詳細は、Apicurio Registry REST API ドキュメント を参照してください。

この章では、Core Registry API v2 を使用して、次のタスクを実行する方法の例を示します。

4.1. Service Registry REST API コマンドを使用したスキーマおよび API アーティファクトの管理

このセクションでは、Core Registry API v2 を使用して、Service Registry で単純なスキーマアーティファクトを追加および取得する簡単な curl ベースの例を示します。

前提条件

  • Service Registry が環境にインストールされ、実行している。

手順

  1. /groups/{group}/artifacts オペレーションを使用して、アーティファクトを Service Registry に追加します。次の curl コマンドの例では、株価アプリケーションの単純なスキーマアーティファクトを追加します。

    $ curl -X POST -H "Content-Type: application/json; artifactType=AVRO" \
      -H "X-Registry-ArtifactId: share-price" \
      -H "Authorization: Bearer $ACCESS_TOKEN" \
      --data '{"type":"record","name":"price","namespace":"com.example", \
       "fields":[{"name":"symbol","type":"string"},{"name":"price","type":"string"}]}' \
      MY-REGISTRY-URL/apis/registry/v2/groups/my-group/artifacts
    Copy to Clipboard Toggle word wrap
    • この例では、アーティファクト ID が share-price の Apache Avro スキーマアーティファクトを追加します。一意のアーティファクト ID を指定しない場合、Service Registry は UUID として自動的に生成します。
    • MY-REGISTRY-URL は、Service Registry がデプロイされているホスト名です。例: my-cluster-service-registry-myproject.example.com
    • この例では、API パスで my-group のグループ ID を指定します。一意のグループ ID を指定しない場合は、API パスで ../groups/default を指定する必要があります。
  2. 応答に、アーティファクトが追加されたことを確認するために、想定される JSON body が含まれていることを確認します。以下に例を示します。

    {"createdBy":"","createdOn":"2021-04-16T09:07:51+0000","modifiedBy":"",
    "modifiedOn":"2021-04-16T09:07:51+0000","id":"share-price","version":"1",
    "type":"AVRO","globalId":2,"state":"ENABLED","groupId":"my-group","contentId":2}
    Copy to Clipboard Toggle word wrap
    • アーティファクトの追加時にバージョンが指定されなかったため、デフォルトのバージョン 1 が自動的に作成されます。
    • これは Service Registry に追加された 2 番目のアーティファクトであるため、グローバル ID とコンテンツ ID の値は 2 です。
  3. API パスのアーティファクト ID を使用して、Service Registry からアーティファクトコンテンツを取得します。この例では、指定された ID は share-price です。

    $ curl -H "Authorization: Bearer $ACCESS_TOKEN" \
     MY-REGISTRY-URL/apis/registry/v2/groups/my-group/artifacts/share-price
     {"type":"record","name":"price","namespace":"com.example",
      "fields":[{"name":"symbol","type":"string"},{"name":"price","type":"string"}]}
    Copy to Clipboard Toggle word wrap

Core Registry API v2 を使用して、スキーマと API アーティファクトを追加する際、アーティファクトバージョンを指定しない場合、Service Registry はバージョンを自動的に生成します。新規アーティファクト作成時のデフォルトのバージョンは 1 です。

Service Registry は、X-Registry-Version HTTP リクエストヘッダーを文字列として使用してバージョンを指定できるカスタムバージョン管理もサポートしています。カスタムバージョン値を指定すると、アーティファクトの作成または更新時に通常割り当てられるデフォルトのバージョンが上書きされます。バージョンを必要とする REST API 操作を実行する場合は、このバージョン値を使用できます。

このセクションでは、Core Registry API v2 を使用して、Service Registry でカスタム Apache Avro スキーマバージョンを追加および取得する簡単な curl ベースの例を示します。カスタムバージョンを指定して、アーティファクトを追加または更新したり、アーティファクトバージョンを追加したりできます。

前提条件

  • Service Registry が環境にインストールされ、実行している。

手順

  1. /groups/{group}/artifacts 操作を使用して、レジストリーにアーティファクトバージョンを追加します。以下の curl コマンドの例は、株価アプリケーションの単純なアーティファクトを追加します。

    $ curl -X POST -H "Content-Type: application/json; artifactType=AVRO" \
      -H "X-Registry-ArtifactId: my-share-price" -H "X-Registry-Version: 1.1.1" \
      -H "Authorization: Bearer $ACCESS_TOKEN" \
      --data '{"type":"record","name":" p","namespace":"com.example", \
       "fields":[{"name":"symbol","type":"string"},{"name":"price","type":"string"}]}' \
       MY-REGISTRY-URL/apis/registry/v2/groups/my-group/artifacts
    Copy to Clipboard Toggle word wrap
    • この例では、アーティファクト ID が my-share-price でバージョンが 1.1.1 の Avro スキーマアーティファクトを追加します。バージョンを指定しないと、Service Registry によってデフォルトのバージョン 1 が自動的に生成されます。
    • MY-REGISTRY-URL は、Service Registry がデプロイされているホスト名です。例: my-cluster-service-registry-myproject.example.com
    • この例では、API パスで my-group のグループ ID を指定します。一意のグループ ID を指定しない場合は、API パスで ../groups/default を指定する必要があります。
  2. 応答に、カスタムアーティファクトバージョンが追加されたことを確認するために、想定される JSON body が含まれていることを確認します。以下に例を示します。

    {"createdBy":"","createdOn":"2021-04-16T10:51:43+0000","modifiedBy":"",
    "modifiedOn":"2021-04-16T10:51:43+0000","id":"my-share-price","version":"1.1.1",
    "type":"AVRO","globalId":3,"state":"ENABLED","groupId":"my-group","contentId":3}
    Copy to Clipboard Toggle word wrap
    • アーティファクトの追加時に、1.1.1 のカスタムバージョンが指定されました。
    • これはレジストリーに追加された 3 つ目のアーティファクトであるため、グローバル ID とコンテンツ ID の値は 3 になります。
  3. API パスでアーティファクト ID とバージョンを使用して、レジストリーからアーティファクトコンテンツを取得します。この例では、指定された ID は my-share-price であり、バージョンは 1.1.1 です。

    $ curl -H "Authorization: Bearer $ACCESS_TOKEN" \
    MY-REGISTRY-URL/apis/registry/v2/groups/my-group/artifacts/my-share-price/versions/1.1.1
    {"type":"record","name":"price","namespace":"com.example",
      "fields":[{"name":"symbol","type":"string"},{"name":"price","type":"string"}]}
    Copy to Clipboard Toggle word wrap

4.3. Service Registry REST API コマンドを使用したスキーマおよび API アーティファクト参照の管理

一部の Service Registry アーティファクトタイプには、別のアーティファクトファイルへの アーティファクト参照 を含めることができます。再利用可能なスキーマまたは API アーティファクトを定義し、アーティファクト参照の複数の場所からそれらを参照することで、効率を高めることができます。

次のアーティファクトタイプはアーティファクト参照をサポートしています。

  • Apache Avro
  • Google Protobuf
  • JSON スキーマ
  • OpenAPI
  • AsyncAPI

このセクションでは、Core Registry API v2 を使用して、Service Registry の単純な Avro スキーマアーティファクトへのアーティファクト参照を追加および取得する簡単な curl ベースの例を示します。

この例では、最初に ItemId という名前のスキーマアーティファクトを作成します。

ItemId スキーマ

{
    "namespace":"com.example.common",
    "name":"ItemId",
    "type":"record",
    "fields":[
        {
            "name":"id",
            "type":"int"
        }
    ]
}
Copy to Clipboard Toggle word wrap

次に、この例では、ネストされた ItemId アーティファクトへの参照を含む、Item という名前のスキーマアーティファクトを作成します。

ネストされた ItemId スキーマを持つアイテムスキーマ

{
    "namespace":"com.example.common",
    "name":"Item",
    "type":"record",
    "fields":[
        {
            "name":"itemId",
            "type":"com.example.common.ItemId"
        },
    ]
}
Copy to Clipboard Toggle word wrap

前提条件

  • Service Registry が環境にインストールされ、実行している。

手順

  1. /groups/{group}/artifacts オペレーションを使用して、ネストされたアーティファクト参照を作成する ItemId スキーマアーティファクトを追加します。

    $ curl -X POST MY-REGISTRY-URL/apis/registry/v2/groups/my-group/artifacts \
       -H "Content-Type: application/json; artifactType=AVRO" \
       -H "X-Registry-ArtifactId: ItemId" \
       -H "Authorization: Bearer $ACCESS_TOKEN" \
       --data '{"namespace": "com.example.common", "type": "record", "name": "ItemId", "fields":[{"name":"id", "type":"int"}]}'
    Copy to Clipboard Toggle word wrap
    • この例では、ItemId のアーティファクト ID を持つ Avro スキーマアーティファクトを追加します。一意のアーティファクト ID を指定しない場合、Service Registry は UUID として自動的に生成します。
    • MY-REGISTRY-URL は、Service Registry がデプロイされているホスト名です。例: my-cluster-service-registry-myproject.example.com
    • この例では、API パスで my-group のグループ ID を指定します。一意のグループ ID を指定しない場合は、API パスで ../groups/default を指定する必要があります。
  2. 応答に、アーティファクトが追加されたことを確認するために、想定される JSON body が含まれていることを確認します。以下に例を示します。

    {"name":"ItemId","createdBy":"","createdOn":"2022-04-14T10:50:09+0000","modifiedBy":"","modifiedOn":"2022-04-14T10:50:09+0000","id":"ItemId","version":"1","type":"AVRO","globalId":1,"state":"ENABLED","groupId":"my-group","contentId":1,"references":[]}
    Copy to Clipboard Toggle word wrap
  3. /groups/{group}/artifacts 操作を使用して、ItemId スキーマへのアーティファクト参照を含む アイテム スキーマアーティファクトを追加します。

    $ curl -X POST MY-REGISTRY-URL/apis/registry/v2/groups/my-group/artifacts \
    -H 'Content-Type: application/create.extended+json' \
    -H "X-Registry-ArtifactId: Item" \
    -H 'X-Registry-ArtifactType: AVRO' \
    -H "Authorization: Bearer $ACCESS_TOKEN" \
    --data-raw '{
        "content": "{\r\n \"namespace\":\"com.example.common\",\r\n  \"name\":\"Item\",\r\n  \"type\":\"record\",\r\n  \"fields\":[\r\n   {\r\n  \"name\":\"itemId\",\r\n   \"type\":\"com.example.common.ItemId\"\r\n        }\r\n    ]\r\n}",
        "references": [
            {
                "groupId": "my-group",
                "artifactId": "ItemId",
                "name": "com.example.common.ItemId",
                "version": "1"
            }
        ]
    }'
    Copy to Clipboard Toggle word wrap
    • アーティファクト参照の場合には、application/json コンテンツタイプを拡張する application/create.extended+json のカスタムコンテンツタイプを指定する必要があります。
  4. アーティファクトが参照を使用して作成されたことを確認するために、予期される JSON body が応答に含まれていることを確認します。以下に例を示します。

    {"name":"Item","createdBy":"","createdOn":"2022-04-14T11:52:15+0000","modifiedBy":"","modifiedOn":"2022-04-14T11:52:15+0000","id":"Item","version":"1","type":"AVRO","globalId":2,"state":"ENABLED","groupId":"my-group","contentId":2, "references":[{"artifactId":"ItemId","groupId":"my-group","name":"ItemId","version":"1"}] }
    Copy to Clipboard Toggle word wrap
  5. 参照を含むアーティファクトのグローバル ID を指定して、Service Registry からアーティファクト参照を取得します。この例では、指定されたグローバル ID は 2 です。

    $ curl -H "Authorization: Bearer $ACCESS_TOKEN" MY-REGISTRY-URL/apis/registry/v2/ids/globalIds/2/references
    Copy to Clipboard Toggle word wrap
  6. 応答に、このアーティファクト参照に必要とされる JSON 本文が含まれていることを確認してください。以下に例を示します。

    [{"groupId":"my-group","artifactId":"ItemId","version":"1","name":"com.example.common.ItemId"}]
    Copy to Clipboard Toggle word wrap

管理者は、Core Registry API v2 を使用して、ある Service Registry インスタンスからデータをエクスポートし、別の Service Registry インスタンスにインポートできるため、異なるインスタンス間でデータを移行できます。

このセクションでは、Core Registry API v2 を使用して、既存のデータを .zip 形式でエクスポートし、ある Service Registry インスタンスから別のインスタンスにインポートする簡単な curl ベースの例を示します。Service Registry インスタンスに含まれるすべてのアーティファクトデータは、.zip ファイルにエクスポートされます。

注記

別の Service Registry インスタンスからエクスポートされた Service Registry データのみをインポートできます。

前提条件

  • Service Registry が環境にインストールされ、実行している。
  • Service Registry インスタンスが作成されている。

    • データのエクスポート元のソースインスタンスには、1 つ以上のスキーマまたは API アーティファクトが含まれています。
    • データをインポートするターゲットインスタンスは、一意の ID を保持するために空。

手順

  1. 既存のソース Service Registry インスタンスから Service Registry データをエクスポートします。

    $ curl MY-REGISTRY-URL/apis/registry/v2/admin/export \
      -H "Authorization: Bearer $ACCESS_TOKEN" \
      --output my-registry-data.zip
    Copy to Clipboard Toggle word wrap

    MY-REGISTRY-URL は、ソース Service Registry がデプロイされているホスト名です。例: my-cluster-source-registry-myproject.example.com

  2. レジストリーデータをターゲット Service Registry インスタンスにインポートします。

    $ curl -X POST "MY-REGISTRY-URL/apis/registry/v2/admin/import" \
      -H "Content-Type: application/zip" -H "Authorization: Bearer $ACCESS_TOKEN" \
      --data-binary @my-registry-data.zip
    Copy to Clipboard Toggle word wrap

    MY-REGISTRY-URL は、ターゲットの Service Registry がデプロイされているホスト名です。例: my-cluster-target-registry-myproject.example.com

第5章 Maven プラグインを使用した Service Registry コンテンツの管理

クライアントアプリケーションを開発する場合、Service Registry Maven プラグインを使用して、Service Registry に保存されているスキーマと API アーティファクトを管理できます。

前提条件

  • Service Registry が環境にインストールされ、実行している。
  • Apache Maven が環境にインストールおよび設定されている。

5.1. Maven プラグインを使用したスキーマおよび API アーティファクトの追加

Maven プラグインの最も一般的な使用例は、クライアントアプリケーションのビルド中に、アーティファクトを追加することです。これは、register 実行目標を使用して実現できます。

前提条件

  • クライアントアプリケーションの Maven プロジェクトを作成している。詳細は、Apache Maven のドキュメント を参照してください。

手順

  1. Maven pom.xml ファイルを更新して、apicurio-registry-maven-plugin を使用してアーティファクトを登録します。以下の例は、Apache Avro および GraphQL スキーマの登録を示しています。

    <plugin>
      <groupId>io.apicurio</groupId>
      <artifactId>apicurio-registry-maven-plugin</artifactId>
      <version>${apicurio.version}</version>
      <executions>
          <execution>
            <phase>generate-sources</phase>
            <goals>
                <goal>register</goal>  
    1
    
            </goals>
            <configuration>
                <registryUrl>MY-REGISTRY-URL/apis/registry/v2</registryUrl> 
    2
    
                <authServerUrl>MY-AUTH-SERVER</authServerUrl>
                <clientId>MY-CLIENT-ID</clientId>
                <clientSecret>MY-CLIENT-SECRET</clientSecret> 
    3
    
                <clientScope>MY-CLIENT-SCOPE</clientScope>
                <artifacts>
                    <artifact>
                        <groupId>TestGroup</groupId> 
    4
    
                        <artifactId>FullNameRecord</artifactId>
                        <file>${project.basedir}/src/main/resources/schemas/record.avsc</file>
                        <ifExists>FAIL</ifExists>
                    </artifact>
                    <artifact>
                        <groupId>TestGroup</groupId>
                        <artifactId>ExampleAPI</artifactId> 
    5
    
                        <type>GRAPHQL</type>
                        <file>${project.basedir}/src/main/resources/apis/example.graphql</file>
                        <ifExists>RETURN_OR_UPDATE</ifExists>
                        <canonicalize>true</canonicalize>
                    </artifact>
                </artifacts>
            </configuration>
        </execution>
      </executions>
     </plugin>
    Copy to Clipboard Toggle word wrap
    1
    register を実行ゴールとして指定し、スキーマアーティファクトを Service Registry にアップロードします。
    2
    ../apis/registry/v2 エンドポイントで Service Registry URL を指定します。
    3
    認証が必要な場合は、認証サーバーおよびクライアントの認証情報を指定できます。
    4
    Service Registry アーティファクトグループ ID を指定します。一意のグループ ID を使用しない場合は、default のグループを指定できます。
    5
    指定したグループ ID、アーティファクト ID、および場所を使用して複数のアーティファクトを登録できます。
  2. たとえば、mvn package コマンドを使用して、Maven プロジェクトをビルドします。

5.2. Maven プラグインを使用したスキーマおよび API アーティファクトのダウンロード

Maven プラグインを使用して Service Registry からアーティファクトをダウンロードできます。これは、たとえば、登録されたスキーマからコードを生成する場合などに便利です。

前提条件

  • クライアントアプリケーションの Maven プロジェクトを作成している。詳細は、Apache Maven のドキュメント を参照してください。

手順

  1. Maven pom.xml ファイルを更新して、apicurio-registry-maven-plugin を使用してアーティファクトをダウンロードします。以下の例は、Apache Avro および GraphQL スキーマのダウンロードを示しています。

    <plugin>
      <groupId>io.apicurio</groupId>
      <artifactId>apicurio-registry-maven-plugin</artifactId>
      <version>${apicurio.version}</version>
      <executions>
        <execution>
          <phase>generate-sources</phase>
          <goals>
            <goal>download</goal> 
    1
    
          </goals>
          <configuration>
              <registryUrl>MY-REGISTRY-URL/apis/registry/v2</registryUrl> 
    2
    
              <authServerUrl>MY-AUTH-SERVER</authServerUrl>
              <clientId>MY-CLIENT-ID</clientId>
              <clientSecret>MY-CLIENT-SECRET</clientSecret> 
    3
    
              <clientScope>MY-CLIENT-SCOPE</clientScope>
              <artifacts>
                  <artifact>
                      <groupId>TestGroup</groupId> 
    4
    
                      <artifactId>FullNameRecord</artifactId> 
    5
    
                      <file>${project.build.directory}/classes/record.avsc</file>
                      <overwrite>true</overwrite>
                  </artifact>
                  <artifact>
                      <groupId>TestGroup</groupId>
                      <artifactId>ExampleAPI</artifactId>
                      <version>1</version>
                      <file>${project.build.directory}/classes/example.graphql</file>
                      <overwrite>true</overwrite>
                  </artifact>
              </artifacts>
          </configuration>
        </execution>
      </executions>
    </plugin>
    Copy to Clipboard Toggle word wrap
    1
    実行目標として download を指定します。
    2
    ../apis/registry/v2 エンドポイントで Service Registry URL を指定します。
    3
    認証が必要な場合は、認証サーバーおよびクライアントの認証情報を指定できます。
    4
    Service Registry アーティファクトグループ ID を指定します。一意のグループを使用しない場合は、default のグループを指定できます。
    5
    アーティファクト ID を使用すると、複数のアーティファクトを指定したディレクトリーにダウンロードできます。
  2. たとえば、mvn package コマンドを使用して、Maven プロジェクトをビルドします。

5.3. Maven プラグインを使用したスキーマおよび API アーティファクトのテスト

実際にアーティファクトを変更せずに、アーティファクトをが登録できることを確認する場合があります。これは、ルールが Service Registry に設定されている場合に役に立ちます。アーティファクトのコンテンツが設定済みのルールのいずれかに違反する場合、アーティファクトのテストに失敗します。

注記

Maven プラグインを使用してアーティファクトをテストする場合には、アーティファクトがテストに合格しても、Service Registry にコンテンツが追加されません。

前提条件

  • クライアントアプリケーションの Maven プロジェクトを作成している。詳細は、Apache Maven のドキュメント を参照してください。

手順

  1. Maven pom.xml ファイルを更新して、apicurio-registry-maven-plugin を使用してアーティファクトをテストします。Apache Avro スキーマのテストの例を以下に示します。

    <plugin>
      <groupId>io.apicurio</groupId>
      <artifactId>apicurio-registry-maven-plugin</artifactId>
      <version>${apicurio.version}</version>
      <executions>
          <execution>
            <phase>generate-sources</phase>
            <goals>
                <goal>test-update</goal>  
    1
    
            </goals>
            <configuration>
                <registryUrl>MY-REGISTRY-URL/apis/registry/v2</registryUrl> 
    2
    
                <authServerUrl>MY-AUTH-SERVER</authServerUrl>
                <clientId>MY-CLIENT-ID</clientId>
                <clientSecret>MY-CLIENT-SECRET</clientSecret> 
    3
    
                <clientScope>MY-CLIENT-SCOPE</clientScope>
                <artifacts>
                    <artifact>
                        <groupId>TestGroup</groupId> 
    4
    
                        <artifactId>FullNameRecord</artifactId>
                        <file>${project.basedir}/src/main/resources/schemas/record.avsc</file> 
    5
    
                    </artifact>
                </artifacts>
            </configuration>
        </execution>
      </executions>
     </plugin>
    Copy to Clipboard Toggle word wrap
    1
    スキーマアーティファクトをテストするための実行目標として test-update を指定します。
    2
    ../apis/registry/v2 エンドポイントで Service Registry URL を指定します。
    3
    認証が必要な場合は、認証サーバーおよびクライアントの認証情報を指定できます。
    4
    Service Registry アーティファクトグループ ID を指定します。一意のグループを使用しない場合は、default のグループを指定できます。
    5
    アーティファクト ID を使用すると、指定のディレクトリーから複数のアーティファクトをテストできます。
  2. たとえば、mvn package コマンドを使用して、Maven プロジェクトをビルドします。

5.4. Service Registry Maven プラグインを使用したアーティファクト参照の手動追加

一部の Service Registry アーティファクトタイプには、別のアーティファクトファイルへの アーティファクト参照 を含めることができます。再利用可能なスキーマまたは API アーティファクトを定義し、アーティファクト参照の複数の場所からそれらを参照することで、効率を高めることができます。

次のアーティファクトタイプはアーティファクト参照をサポートしています。

  • Apache Avro
  • Google Protobuf
  • JSON スキーマ
  • OpenAPI
  • AsyncAPI

このセクションでは、Service Registry Maven プラグインを使用して、Service Registry に保存されている単純な Avro スキーマアーティファクトへのアーティファクト参照を手動で登録する簡単な例を示します。この例では、次の Exchange スキーマアーティファクトが Service Registry にすでに作成されていることを前提としています。

交換スキーマ

{
  "namespace": "com.kubetrade.schema.common",
  "type": "enum",
  "name": "Exchange",
  "symbols" : ["GEMINI"]
}
Copy to Clipboard Toggle word wrap

次に、この例では、ネストされた Exchange スキーマアーティファクトへの参照を含む TradeKey スキーマアーティファクトを作成します。

Exchange スキーマへのネストされた参照を含む TradeKey スキーマ

{
  "namespace": "com.kubetrade.schema.trade",
  "type": "record",
  "name": "TradeKey",
  "fields": [
    {
      "name": "exchange",
      "type": "com.kubetrade.schema.common.Exchange"
    },
    {
      "name": "key",
      "type": "string"
    }
  ]
}
Copy to Clipboard Toggle word wrap

前提条件

  • クライアントアプリケーションの Maven プロジェクトを作成している。詳細は、Apache Maven のドキュメント を参照してください。
  • 参照される Exchange スキーマアーティファクトは、Service Registry にすでに作成されています。

手順

  1. apicurio-registry-maven-plugin を使用して TradeKey スキーマを登録するように Maven pom.xml ファイルを更新します。これには、次のように Exchange スキーマへのネストされた参照が含まれます。

    <plugin>
        <groupId>io.apicurio</groupId>
        <artifactId>apicurio-registry-maven-plugin</artifactId>
        <version>${apicurio-registry.version}</version>
        <executions>
            <execution>
                <phase>generate-sources</phase>
                <goals>
                    <goal>register</goal> 
    1
    
                </goals>
                <configuration>
                    <registryUrl>MY-REGISTRY-URL/apis/registry/v2</registryUrl> 
    2
    
                    <authServerUrl>MY-AUTH-SERVER</authServerUrl>
                    <clientId>MY-CLIENT-ID</clientId>
                    <clientSecret>MY-CLIENT-SECRET</clientSecret> 
    3
    
                    <clientScope>MY-CLIENT-SCOPE</clientScope>
                    <artifacts>
                        <artifact>
                            <groupId>test-group</groupId> 
    4
    
                            <artifactId>TradeKey</artifactId>
                            <version>2.0</version>
                            <type>AVRO</type>
                            <file>
                                ${project.basedir}/src/main/resources/schemas/TradeKey.avsc
                            </file>
                            <ifExists>RETURN_OR_UPDATE</ifExists>
                            <canonicalize>true</canonicalize>
                            <references>
                                <reference> 
    5
    
                                    <name>com.kubetrade.schema.common.Exchange</name>
                                    <groupId>test-group</groupId>
                                    <artifactId>Exchange</artifactId>
                                    <version>2.0</version>
                                    <type>AVRO</type>
                                    <file>
                                        ${project.basedir}/src/main/resources/schemas/Exchange.avsc
                                    </file>
                                    <ifExists>RETURN_OR_UPDATE</ifExists>
                                    <canonicalize>true</canonicalize>
                                </reference>
                            </references>
                        </artifact>
                    </artifacts>
                </configuration>
            </execution>
        </executions>
    </plugin>
    Copy to Clipboard Toggle word wrap
    1
    register を実行ゴールとして指定し、スキーマアーティファクトを Service Registry にアップロードします。
    2
    ../apis/registry/v2 エンドポイントを使用して Service Registry URL を指定します。
    3
    認証が必要な場合は、認証サーバーおよびクライアントの認証情報を指定できます。
    4
    Service Registry アーティファクトグループ ID を指定します。一意のグループ ID を使用しない場合は、default のグループを指定できます。
    5
    グループ ID、アーティファクト ID、バージョン、タイプ、および場所を使用して、Service Registry アーティファクト参照を指定します。この方法で、複数のアーティファクト参照を登録できます。
  2. たとえば、mvn package コマンドを使用して、Maven プロジェクトをビルドします。

5.5. Service Registry Maven プラグインを使用したアーティファクト参照の自動追加

一部の Service Registry アーティファクトタイプには、別のアーティファクトファイルへの アーティファクト参照 を含めることができます。再利用可能なスキーマまたは API アーティファクトを定義し、アーティファクト参照の複数の場所からそれらを参照することで、効率を高めることができます。

次のアーティファクトタイプはアーティファクト参照をサポートしています。

  • Apache Avro
  • Google Protobuf
  • JSON スキーマ
  • OpenAPI
  • AsyncAPI

単一のアーティファクトを指定し、Service Registry Maven プラグインを設定して、同じディレクトリーにあるアーティファクトへのすべての参照を自動的に検出し、これらの参照を自動的に登録できます。これはテクノロジープレビューの機能です。

重要

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

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

このセクションでは、Maven プラグインを使用して Avro スキーマを登録し、単純なスキーマアーティファクトへのアーティファクト参照を自動的に検出して登録する簡単な例を紹介します。この例では、親 TradeKey アーティファクトとネストされた Exchange スキーマアーティファクトの両方が、同じディレクトリーで利用可能であることを前提としています。

Exchange スキーマへのネストされた参照を含む TradeKey スキーマ

{
  "namespace": "com.kubetrade.schema.trade",
  "type": "record",
  "name": "TradeKey",
  "fields": [
    {
      "name": "exchange",
      "type": "com.kubetrade.schema.common.Exchange"
    },
    {
      "name": "key",
      "type": "string"
    }
  ]
}
Copy to Clipboard Toggle word wrap

交換スキーマ

{
  "namespace": "com.kubetrade.schema.common",
  "type": "enum",
  "name": "Exchange",
  "symbols" : ["GEMINI"]
}
Copy to Clipboard Toggle word wrap

前提条件

  • クライアントアプリケーションの Maven プロジェクトを作成している。詳細は、Apache Maven のドキュメント を参照してください。
  • TradeKey スキーマアーティファクトとネストされた Exchange スキーマアーティファクトファイルは両方とも、同じディレクトリーにあります。

手順

  1. apicurio-registry-maven-plugin を使用して TradeKey スキーマを登録するように Maven pom.xml ファイルを更新します。これには、次のように Exchange スキーマへのネストされた参照が含まれます。

    <plugin>
        <groupId>io.apicurio</groupId>
        <artifactId>apicurio-registry-maven-plugin</artifactId>
        <version>${apicurio-registry.version}</version>
        <executions>
            <execution>
                <phase>generate-sources</phase>
                <goals>
                    <goal>register</goal> 
    1
    
                </goals>
                <configuration>
                    <registryUrl>MY-REGISTRY-URL/apis/registry/v2</registryUrl> 
    2
    
                    <authServerUrl>MY-AUTH-SERVER</authServerUrl>
                    <clientId>MY-CLIENT-ID</clientId>
                    <clientSecret>MY-CLIENT-SECRET</clientSecret> 
    3
    
                    <clientScope>MY-CLIENT-SCOPE</clientScope>
                    <artifacts>
                        <artifact>
                            <groupId>test-group</groupId> 
    4
    
                            <artifactId>TradeKey</artifactId>
                            <version>2.0</version>
                            <type>AVRO</type>
                            <file>
                                ${project.basedir}/src/main/resources/schemas/TradeKey.avsc 
    5
    
                            </file>
                            <ifExists>RETURN_OR_UPDATE</ifExists>
                            <canonicalize>true</canonicalize>
                            <autoRefs>true</autoRefs> 
    6
    
                        </artifact>
                    </artifacts>
                </configuration>
            </execution>
        </executions>
    </plugin>
    Copy to Clipboard Toggle word wrap
    1
    register を実行ゴールとして指定し、スキーマアーティファクトを Service Registry にアップロードします。
    2
    ../apis/registry/v2 エンドポイントを使用して Service Registry URL を指定します。
    3
    認証が必要な場合は、認証サーバーおよびクライアントの認証情報を指定できます。
    4
    参照を含む親アーティファクトグループ ID を指定します。一意のグループ ID を使用しない場合は、default のグループを指定できます。
    5
    親アーティファクトファイルの場所を指定します。参照されるアーティファクトはすべて、同じディレクトリーに置く必要があります。
    6
    <autoRefs> オプションを true に設定すると、同じディレクトリー内のアーティファクトへのすべての参照が自動的に検出されて登録されます。この方法で、複数のアーティファクト参照を登録できます。
  2. たとえば、mvn package コマンドを使用して、Maven プロジェクトをビルドします。

第6章 Java クライアントを使用した Service Registry コンテンツの管理

Service Registry Java クライアントアプリケーションを作成し、これを使用して Service Registry に保存されているアーティファクトを管理できます。

6.1. Service Registry Java クライアント

Java クライアントアプリケーションを使用して、Service Registry に保存されたアーティファクトを管理できます。Service Registry Java クライアントクラスを使用して、アーティファクトを作成、読み取り、更新、または削除できます。Service Registry Java クライアントを使用して、グローバルルールの管理や Service Registry データのインポートとエクスポートなどの管理者機能を実行することもできます。

Apache Maven プロジェクトに正しい依存関係を追加することで、Service Registry Java クライアントにアクセスできます。詳細は、「Service Registry Java クライアントアプリケーションの作成」 を参照してください。

Service Registry クライアントは、必要に応じてカスタマイズできる JDK によって提供される HTTP クライアントを使用して、実装されます。たとえば、カスタムヘッダーを追加したり、Transport Layer Security (TLS) 認証の設定オプションを有効にしたりすることができます。詳細は、「Service Registry Java client configuration」 を参照してください。

6.2. Service Registry Java クライアントアプリケーションの作成

Service Registry Java クライアントクラスを使用して、Service Registry に保存されたアーティファクトを管理する Java クライアントアプリケーションを作成できます。

前提条件

  • Service Registry が環境にインストールされ、実行している。
  • Java クライアントアプリケーション用の Maven プロジェクトを作成しました。詳細は、Apache Maven を参照。

手順

  1. 以下の依存関係を Maven プロジェクトに追加します。

    <dependency>
        <groupId>io.apicurio</groupId>
        <artifactId>apicurio-registry-client</artifactId>
        <version>${apicurio-registry.version}</version>
    </dependency>
    Copy to Clipboard Toggle word wrap
  2. 次のように Service Registry クライアントを作成します。

    public class ClientExample {
    
        public static void main(String[] args) throws Exception {
           // Create a registry client
           String registryUrl = "https://my-registry.my-domain.com/apis/registry/v2"; 
    1
    
           RegistryClient client = RegistryClientFactory.create(registryUrl); 
    2
    
        }
    }
    Copy to Clipboard Toggle word wrap
    1
    https://my-registry.my-domain.com の例の Service Registry URL を指定すると、クライアントは自動的に /apis/registry/v2 を追加します。
    2
    Service Registry クライアント作成時の他のオプションは、次のセクションの Java クライアント設定を参照してください。

クライアントが作成されると、クライアントの Service Registry REST API で使用可能なすべての操作を使用できます。詳細は、Apicurio Registry REST API ドキュメント を参照してください。

6.3. Service Registry Java client configuration

Service Registry Java クライアントには、クライアントファクトリーを基にした以下の設定オプションが含まれます。

Expand
表6.1 Service Registry Java クライアント設定オプション
オプション説明引数

プレーンクライアント

実行中の Service Registry インスタンスとやりとりするために使用される基本的な REST クライアント。

baseUrl

カスタム設定のあるクライアント

ユーザーが提供した設定を使用する Service Registry クライアント。

baseUrlMap<String Object> configs

カスタム設定および認証のあるクライアント

カスタム設定を含むマップを受け入れる Service Registry クライアント。たとえば、これは、呼び出しにカスタムヘッダーを追加する場合に便利です。リクエストを認証するための認証サーバーも提供する必要があります。

baseUrl, Map<String Object> configs, Auth auth

カスタムヘッダー設定

カスタムヘッダーを設定するには、configs マップキーに apicurio.registry.request.headers 接頭辞を追加する必要があります。たとえば、Basic の値を持つ apicurio.registry.request.headers.Authorizationconfigs マップキー Basic: YWxhZGRpbjpvcGVuc2VzYW1 は、Authorization ヘッダーに同じ値を設定します。

TLS 設定オプション

以下のプロパティーを使用して、Service Registry Java クライアントの Transport Layer Security (TLS) 認証を設定できます。

  • apicurio.registry.request.ssl.truststore.location
  • apicurio.registry.request.ssl.truststore.password
  • apicurio.registry.request.ssl.truststore.type
  • apicurio.registry.request.ssl.keystore.location
  • apicurio.registry.request.ssl.keystore.password
  • apicurio.registry.request.ssl.keystore.type
  • apicurio.registry.request.ssl.key.password

Service Registry によって、Java で書かれた Kafka プロデューサーおよびコンシューマーアプリケーションのクライアントシリアライザー/デシリアライザー (SerDes) が提供されます。Kafka プロデューサーアプリケーションは、シリアライザーを使用して、特定のイベントスキーマに準拠するメッセージをエンコードします。Kafka コンシューマーアプリケーションはデシリアライザーを使用して、特定のスキーマ ID に基づいてメッセージが適切なスキーマを使用してシリアライズされたことを検証します。これにより、スキーマが一貫して使用されるようにし、実行時にデータエラーが発生しないようにします。

この章では、プロデューサーおよびコンシューマークライアントアプリケーションで Kafka クライアント SerDes を使用する方法を説明します。

前提条件

7.1. Kafka クライアントアプリケーションおよび Service Registry

Service Registry は、クライアントアプリケーション設定からスキーマ管理を分離します。クライアントコードに URL を指定すると、Java クライアントアプリケーションが Service Registry からスキーマを使用できます。

スキーマを Service Registry に保存して、クライアントアプリケーションから参照されるメッセージをシリアライズおよびデシリアライズして、送受信するメッセージがそれらのスキーマと互換性があることを確認できます。Kafka クライアントアプリケーションは、実行時にスキーマを Service Registry からプッシュまたはプルできます。

スキーマは進化するので、Service Registry でルールを定義できます。たとえば、スキーマの変更が有効で、アプリケーションによって使用される以前のバージョンとの互換性を維持するようにします。Service Registry は、変更済みのスキーマと以前のスキーマバージョンを比較することで、互換性をチェックします。

Service Registry スキーマテクノロジー

Service Registry は、以下のようなスキーマテクノロジーのスキーマレジストリーサポートを提供します。

  • Avro
  • Protobuf
  • JSON スキーマ

これらのスキーマテクノロジーは、Service Registry によって提供される Kafka クライアントのシリアライザー/デシリアライザー (SerDes) サービスを介してクライアントアプリケーションで使用できます。Service Registry によって提供される SerDes クラスの成熟度および使用法は異なる場合があります。以降のセクションでは、各スキーマタイプの詳細を提供します。

プロデューサースキーマの設定

プロデューサークライアントアプリケーションは、シリアライザーを使用して、特定のブローカートピックに送信するメッセージを正しいデータ形式にします。

プロデューサーが Service Registry を使用してシリアライズできるようにするには、以下を行います。

スキーマを登録したら、Kafka および Service Registry を開始するときに、スキーマにアクセスして、プロデューサーにより Kafka ブローカートピックに送信されるメッセージをフォーマットできます。または、設定に応じて、プロデューサーは最初の使用時にスキーマを自動的に登録できます。

スキーマがすでに存在する場合、Service Registry に定義される互換性ルールに基づいて、レジストリー REST API を使用して新バージョンのスキーマを作成できます。バージョンは、スキーマの進化にともなう互換性チェックに使用します。グループ ID、アーティファクト ID、およびバージョンは、スキーマを識別する一意のタプルを表します。

コンシューマースキーマの設定

コンシューマークライアントアプリケーションは、デシリアライザーを使用することで、そのアプリケーションが消費するメッセージを特定のブローカートピックから正しいデータ形式にします。

コンシューマーがデシリアライズに Service Registry を使用できるようにするには、以下を実行します。

グローバル ID を使用したスキーマの取得

デフォルトでは、スキーマは、消費されるメッセージに指定されるグローバル ID を使用してデシリアライザーによって Service Registry から取得されます。スキーマグローバル ID は、プロデューサーアプリケーションの設定に応じて、メッセージヘッダーまたはメッセージペイロードに配置できます。

メッセージペイロードでグローバル ID を見つけるとき、データの形式は、コンシューマーへの信号として使用されるマジックバイトで始まり、通常通りグローバル ID とメッセージデータが続きます。以下に例を示します。

# ...
[MAGIC_BYTE]
[GLOBAL_ID]
[MESSAGE DATA]
Copy to Clipboard Toggle word wrap

これで、Kafka および Service Registry を開始するとき、スキーマにアクセスして、Kafka ブローカートピックから受信するメッセージをフォーマットできます。

コンテンツ ID を使用したスキーマの取得

または、アーティファクトコンテンツの一意の ID であるコンテンツ ID に基づいて、Service Registry からスキーマを取得するように設定できます。グローバル ID はアーティファクトバージョンの一意の ID です。

コンテンツ ID はバージョンを一意に識別しませんが、バージョンコンテンツのみを一意に識別します。複数のバージョンがまったく同じコンテンツを共有している場合、グローバル ID は異なりますが、コンテンツ ID は同じです。Confluent Schema Registry はデフォルトでコンテンツ ID を使用します。

7.2. Service Registry でスキーマを検索するストラテジー

Kafka クライアントのシリアライザーは 検索ストラテジー を使用して、メッセージスキーマが Service Registry に登録されるアーティファクト ID およびグローバル ID を決定します。特定のトピックとメッセージについて、ArtifactReferenceResolverStrategy Java インターフェイスのさまざまな実装を使用して、レジストリー内のアーティファクトへの参照を返すことができます。

各ストラテジーのクラスは、io.apicurio.registry.serde.strategy パッケージに含まれています。Avro SerDes の特定のストラテジークラスは、io.apicurio.registry.serde.avro.strategy package に含まれています。デフォルトのストラテジー、TopicIdStrategy は、メッセージを受信する Kafka トピックと同じ名前の Service Registry アーティファクトを検索します。

public ArtifactReference artifactReference(String topic, boolean isKey, T schema) {
        return ArtifactReference.builder()
                .groupId(null)
                .artifactId(String.format("%s-%s", topic, isKey ? "key" : "value"))
                .build();
Copy to Clipboard Toggle word wrap

  • topic パラメーターは、メッセージを受信する Kafka トピックの名前です。
  • isKey パラメーターは、メッセージキーがシリアライズされている場合は true であり、メッセージ値がシリアライズされている場合は false です。
  • schema パラメーターは、シリアライズ/デシリアライズされたメッセージのスキーマです。
  • 返される ArtifactReference には、スキーマが登録されているアーティファクト ID が含まれています。

使用する検索アップストラテジーは、スキーマを保存する方法と場所によって異なります。たとえば、同じ Avro メッセージタイプを持つ Kafka トピックが複数ある場合、レコード ID を使用するストラテジーを使用することがあります。

アーティファクトリーゾルバーストラテジー

アーティファクトリーゾルバーストラテジーは、Kafka トピックおよびメッセージ情報を Service Registry のアーティファクトにマップする方法を提供します。マッピングの共通規則は、Kafka メッセージのキーと値のどちらにシリアライザーを使用するかによって、Kafka トピック名と key または value を結合することです。

ただし、Service Registry によって提供されるストラテジーを使用するか、io.apicurio.registry.serde.strategy.ArtifactReferenceResolverStrategy を実装するカスタム Java クラスを作成することにより、マッピングに代替規則を使用できます。

アーティファクトへの参照を返すストラテジー

Service Registry は、ArtifactReferenceResolverStrategy の実装に基づいてアーティファクトへの参照を返すために、次の戦略を提供します。

RecordIdStrategy
スキーマのフルネームを使用する Avro 固有のストラテジー。
TopicRecordIdStrategy
トピック名およびスキーマのフルネームを使用する Avro 固有のストラテジー。
TopicIdStrategy
トピック名と、key または value 接尾辞を使用するデフォルトストラテジー。
SimpleTopicIdStrategy
トピック名のみを使用する単純なストラテジー。
DefaultSchemaResolver インターフェイス

デフォルトのスキーマリゾルバーは、アーティファクトリーゾルバーストラテジーによって提供されるアーティファクト参照の下に登録されたスキーマの特定バージョンを見つけて識別します。すべてのアーティファクトのすべてのバージョンには、グローバルで一意の識別子が 1 つだけあり、それを使用してそのアーティファクトの内容を取得できます。このグローバル ID はすべての Kafka メッセージに含まれていいるため、デシリアライザーは Apicurio Registry からスキーマを適切に取得できます。

デフォルトのスキーマリゾルバーは、既存のアーティファクトバージョンを検索できます。見つからない場合は、使用するストラテジーに応じて登録できます。io.apicurio.registry.resolver.SchemaResolver を実装するカスタム Java クラスを作成することにより、独自のストラテジーを提供することもできます。ただし、DefaultSchemaResolver を使用して、代わりに設定プロパティーを指定することを推奨します。

レジストリー検索オプションの設定

DefaultSchemaResolver を使用する場合、アプリケーションのプロパティーを使用してその動作を設定できます。次の表は、一般的に使用される例を示しています。

Expand
表7.1 Service Registry 検索設定オプション
プロパティー説明デフォルト

apicurio.registry.find-latest

boolean

シリアライザーが対応するグループ ID およびアーティファクト ID のレジストリー内で最新のアーティファクトの検索を試行するかどうかを指定します。

false

apicurio.registry.use-id

String

指定された ID を Kafka に書き込むようシリアライザーに指示し、この ID を使用してスキーマを見つけるようにデシリアライザーに指示します。

なし

apicurio.registry.auto-register

boolean

シリアライザーがレジストリーでアーティファクトを作成しようとするかどうかを指定します。JSON スキーマシリアライザーはこれをサポートしません。

false

apicurio.registry.check-period-ms

String

グローバル ID をキャッシュする期間をミリ秒単位で指定します。設定されていない場合は、グローバル ID は毎回フェッチされます。

なし

7.3. スキーマの Service Registry への登録

スキーマを Apache Avro などの適切な形式で定義したら、スキーマを Service Registry に追加できます。

以下の方法を使用してスキーマを追加できます。

  • Service Registry Web コンソール
  • Service Registry REST API を使用する curl コマンド
  • Service Registry に付属する Maven プラグイン
  • クライアントコードに加えられたスキーマ設定

スキーマを登録するまでは、クライアントアプリケーションは Service Registry を使用できません。

Service Registry Web コンソール

Service Registry のインストール時に、ui エンドポイントから Web コンソールに接続できます。

http://MY-REGISTRY-URL/ui

コンソールから、スキーマを追加、表示、および設定できます。また、レジストリーに無効なコンテンツが追加されないようにするルールを作成することもできます。

curl コマンドの例
 curl -X POST -H "Content-type: application/json; artifactType=AVRO" \
   -H "X-Registry-ArtifactId: share-price" \ 
1

   --data '{
     "type":"record",
     "name":"price",
     "namespace":"com.example",
     "fields":[{"name":"symbol","type":"string"},
     {"name":"price","type":"string"}]}'
   https://my-cluster-my-registry-my-project.example.com/apis/registry/v2/groups/my-group/artifacts -s 
2
Copy to Clipboard Toggle word wrap
1
シンプルな Avro スキーマアーティファクト。
2
Service Registry を公開する OpenShift ルート名。
Maven プラグインの例
<plugin>
  <groupId>io.apicurio</groupId>
  <artifactId>apicurio-registry-maven-plugin</artifactId>
  <version>${apicurio.version}</version>
  <executions>
      <execution>
        <phase>generate-sources</phase>
        <goals>
            <goal>register</goal>  
1

        </goals>
        <configuration>
            <registryUrl>http://REGISTRY-URL/apis/registry/v2</registryUrl> 
2

            <artifacts>
                <artifact>
                    <groupId>TestGroup</groupId> 
3

                    <artifactId>FullNameRecord</artifactId>
                    <file>${project.basedir}/src/main/resources/schemas/record.avsc</file>
                    <ifExists>FAIL</ifExists>
                </artifact>
                <artifact>
                    <groupId>TestGroup</groupId>
                    <artifactId>ExampleAPI</artifactId> 
4

                    <type>GRAPHQL</type>
                    <file>${project.basedir}/src/main/resources/apis/example.graphql</file>
                    <ifExists>RETURN_OR_UPDATE</ifExists>
                    <canonicalize>true</canonicalize>
                </artifact>
            </artifacts>
        </configuration>
    </execution>
  </executions>
 </plugin>
Copy to Clipboard Toggle word wrap
1
スキーマアーティファクトをレジストリーにアップロードするための実行目標として register を指定します。
2
../apis/registry/v2 エンドポイントで Service Registry URL を指定します。
3
Service Registry アーティファクトグループ ID を指定します。
4
指定したグループ ID、アーティファクト ID、および場所を使用して複数のアーティファクトをアップロードできます。
プロデューサークライアントを使用した設定例
String registryUrl_node1 = PropertiesUtil.property(clientProperties, "registry.url.node1",
    "https://my-cluster-service-registry-myproject.example.com/apis/registry/v2"); 
1

try (RegistryService service = RegistryClient.create(registryUrl_node1)) {
    String artifactId = ApplicationImpl.INPUT_TOPIC + "-value";
    try {
        service.getArtifactMetaData(artifactId); 
2

    } catch (WebApplicationException e) {
        CompletionStage <ArtifactMetaData> csa = service.createArtifact(
            "AVRO",
            artifactId,
            new ByteArrayInputStream(LogInput.SCHEMA$.toString().getBytes())
        );
        csa.toCompletableFuture().get();
    }
}
Copy to Clipboard Toggle word wrap
1
複数の URL ノードに対してプロパティーを登録できます。
2
アーティファクト ID に基づいてスキーマがすでに存在しているかを確認します。

7.4. Kafka コンシューマークライアントからのスキーマの使用

この手順では、Service Registry からのスキーマを使用するように Java で書かれた Kafka コンシューマークライアントを設定する方法を説明します。

前提条件

  • Service Registry がインストールされている必要があります。
  • スキーマが Service Registry に登録されている必要があります。

手順

  1. Service Registry の URL でクライアントを設定します。以下に例を示します。

    String registryUrl = "https://registry.example.com/apis/registry/v2";
    Properties props = new Properties();
    props.putIfAbsent(SerdeConfig.REGISTRY_URL, registryUrl);
    Copy to Clipboard Toggle word wrap
  2. Service Registry デシリアライザーでクライアントを設定します。以下に例を示します。

    // Configure Kafka settings
    props.putIfAbsent(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, SERVERS);
    props.putIfAbsent(ConsumerConfig.GROUP_ID_CONFIG, "Consumer-" + TOPIC_NAME);
    props.putIfAbsent(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");
    props.putIfAbsent(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");
    props.putIfAbsent(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
    // Configure deserializer settings
    props.putIfAbsent(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG,
        AvroKafkaDeserializer.class.getName()); 
    1
    
    props.putIfAbsent(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG,
        AvroKafkaDeserializer.class.getName()); 
    2
    Copy to Clipboard Toggle word wrap
    1
    Service Registry によって提供されるデシリアライザー。
    2
    デシリアライズは Apache Avro JSON 形式です。

7.5. Kafka プロデューサークライアントからのスキーマの使用

この手順では、Service Registry からのスキーマを使用するように Java で書かれた Kafka プロデューサークライアントを設定する方法を説明します。

前提条件

  • Service Registry がインストールされている必要があります。
  • スキーマが Service Registry に登録されている必要があります。

手順

  1. Service Registry の URL でクライアントを設定します。以下に例を示します。

    String registryUrl = "https://registry.example.com/apis/registry/v2";
    Properties props = new Properties();
    props.putIfAbsent(SerdeConfig.REGISTRY_URL, registryUrl);
    Copy to Clipboard Toggle word wrap
  2. クライアントをシリアライザーで設定し、Service Registry でスキーマを検索するようにストラテジーを設定します。以下に例を示します。

    props.put(CommonClientConfigs.BOOTSTRAP_SERVERS_CONFIG, "my-cluster-kafka-bootstrap:9092");
    props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, AvroKafkaSerializer.class.getName()); 
    1
    
    props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, AvroKafkaSerializer.class.getName()); 
    2
    
    props.put(SerdeConfig.FIND_LATEST_ARTIFACT, Boolean.TRUE); 
    3
    Copy to Clipboard Toggle word wrap
    1
    Service Registry により提供されるメッセージキーのシリアライザー。
    2
    Service Registry により提供されるメッセージ値のシリアライザー。
    3
    スキーマのグローバル ID を検索する検索ストラテジー。

7.6. Kafka Streams アプリケーションからのスキーマの使用

この手順では、Service Registry からの Apache Avro スキーマを使用するように Java で書かれた Kafka Streams クライアントを設定する方法を説明します。

前提条件

  • Service Registry がインストールされている必要があります。
  • スキーマが Service Registry に登録されている必要があります。

手順

  1. Service Registry URL を使用して Java クライアントを作成して設定します。

    String registryUrl = "https://registry.example.com/apis/registry/v2";
    
    RegistryService client = RegistryClient.cached(registryUrl);
    Copy to Clipboard Toggle word wrap
  2. シリアライザーおよびデシリアライザーを設定します。

    Serializer<LogInput> serializer = new AvroKafkaSerializer<LogInput>(); 
    1
    
    
    Deserializer<LogInput> deserializer = new AvroKafkaDeserializer <LogInput>(); 
    2
    
    
    Serde<LogInput> logSerde = Serdes.serdeFrom(
        serializer,
        deserializer
    );
    
    Map<String, Object> config = new HashMap<>();
    config.put(SerdeConfig.REGISTRY_URL, registryUrl);
    config.put(AvroKafkaSerdeConfig.USE_SPECIFIC_AVRO_READER, true);
    logSerde.configure(config, false); 
    3
    Copy to Clipboard Toggle word wrap
    1
    Service Registry によって提供される Avro シリアライザー。
    2
    Service Registry によって提供される Avro デシリアライザー。
    3
    Avro 形式でデシリアライズ用の Service Registry URL および Avro リーダーを設定します。
  3. Kafka Streams クライアントを作成します。

    KStream<String, LogInput> input = builder.stream(
        INPUT_TOPIC,
        Consumed.with(Serdes.String(), logSerde)
    );
    Copy to Clipboard Toggle word wrap

第8章 Java クライアントでの Kafka シリアライザー/デシリアライザーの設定

この章では、プロデューサーおよびコンシューマー Java クライアントアプリケーションで Kafka シリアライザー/デシリアライザー (SerDes) を設定する方法について詳説します。

8.1. クライアントアプリケーションの Service Registry シリアライザー/デシリアライザーの設定

このセクションの定数例を使用して、特定のクライアントシリアライザー/デシリアライザー (SerDes) サービスおよびスキーマ検索ストラテジーを直接クライアントアプリケーションに設定できます。または、ファイルまたはインスタンスで対応する Service Registry アプリケーションプロパティーを設定できます。

以下のセクションでは、一般的に使用される SerDes 定数および設定オプションの例を紹介します。

SerDes サービスの設定
public class SerdeConfig {

   public static final String REGISTRY_URL = "apicurio.registry.url"; 
1

   public static final String ID_HANDLER = "apicurio.registry.id-handler"; 
2

   public static final String ENABLE_CONFLUENT_ID_HANDLER = "apicurio.registry.as-confluent"; 
3
Copy to Clipboard Toggle word wrap
  1. Service Registry の必須の URL。
  2. ID 処理を拡張することで、他の ID 形式をサポートし、その形式に Service Registry SerDes サービスとの互換性を持たせます。たとえば、ID 形式を Long から Integer に変更すると Confluent ID 形式がサポートされます。
  3. Confluent ID の処理を簡素化します。true に設定すると、Integer がグローバル ID の検索に使用されます。この設定は、ID_HANDLER オプションと一緒に使用しないでください。
SerDes 検索ストラテジーの設定
public class SerdeConfig {

   public static final String ARTIFACT_RESOLVER_STRATEGY = "apicurio.registry.artifact-resolver-strategy"; 
1

   public static final String SCHEMA_RESOLVER = "apicurio.registry.schema-resolver"; 
2

...
Copy to Clipboard Toggle word wrap
1 1
アーティファクトリーゾルバーストラテジーを実装し、Kafka SerDes とアーティファクト ID の間をマッピングする Java クラス。デフォルトはトピック ID ストラテジーです。これはシリアライザークラスによってのみ使用されます。
2 2
スキーマリゾルバーを実装する Java クラス。デフォルトは DefaultSchemaResolver です。これは、シリアライザーおよびデシリアライザークラスによって使用されます。
Kafka コンバーターの設定
public class SerdeBasedConverter<S, T> extends SchemaResolverConfigurer<S, T> implements Converter, Closeable {

   public static final String REGISTRY_CONVERTER_SERIALIZER_PARAM = "apicurio.registry.converter.serializer"; 
1

   public static final String REGISTRY_CONVERTER_DESERIALIZER_PARAM = "apicurio.registry.converter.deserializer"; 
2
Copy to Clipboard Toggle word wrap
  1. Service Registry Kafka コンバーターと使用するために必要なシリアライザー。
  2. Service Registry Kafka コンバーターと使用するために必要なデシリアライザー。
さまざまなスキーマタイプの設定

さまざまなスキーマ技術に SerDes を設定する方法は、以下を参照してください。

8.2. Service Registry シリアライザー/デシリアライザー設定プロパティー

このセクションでは、Service Registry Kafka シリアライザー/デシリアライザー (SerDes) の Java 設定プロパティーに関する参照情報を提供します。

SchemaResolver インターフェイス

Service Registry SerDes は、レジストリーへのアクセスを抽象化し、サポートされるすべての形式の SerDes クラスに同じ検索ロジックを適用する SchemaResolver インターフェイスをベースとしています。

Expand
表8.1 SchemaResolver インターフェイスの設定プロパティー
Constantプロパティー説明デフォルト

SCHEMA_RESOLVER

apicurio.registry.schema-resolver

シリアライザーおよびデシリアライザーによって使用されます。SchemaResolver を実装する完全修飾 Java クラス名。

String

io.apicurio.registry.resolver.DefaultSchemaResolver

注記

DefaultSchemaResolver が推奨され、ほとんどのユースケースに役立つ機能を提供します。一部の高度なユースケースでは、SchemaResolver のカスタム実装を使用する場合があります。

DefaultSchemaResolver クラス

DefaultSchemaResolver を使用して、次のような機能を設定できます。

  • レジストリー API へのアクセス
  • レジストリーでアーティファクトを検索する方法
  • Kafka との間でアーティファクト情報を読み書きする方法
  • デシリアライザーのフォールバックオプション
レジストリー API アクセスオプションの設定

DefaultSchemaResolver は、コアレジストリー API へのアクセスを設定するために次のプロパティーを提供します。

Expand
表8.2 レジストリー API にアクセスするための設定プロパティー
Constantプロパティー説明デフォルト

REGISTRY_URL

apicurio.registry.url

シリアライザーおよびデシリアライザーによって使用されます。レジストリー API にアクセスするための URL。

String

なし

AUTH_SERVICE_URL

apicurio.auth.service.url

シリアライザーおよびデシリアライザーによって使用されます。認証サービスの URL。OAuth クライアントクレデンシャルフローを使用してセキュアなレジストリーにアクセスする際に必須です。

String

なし

AUTH_TOKEN_ENDPOINT

apicurio.auth.service.token.endpoint

シリアライザーおよびデシリアライザーによって使用されます。トークンエンドポイントの URL。セキュアなレジストリーにアクセスし、AUTH_SERVICE_URL が指定されていない場合に必要です。

String

なし

AUTH_REALM

apicurio.auth.realm

シリアライザーおよびデシリアライザーによって使用されます。認証サービスにアクセスするためのレルム。OAuth クライアントクレデンシャルフローを使用してセキュアなレジストリーにアクセスする際に必須です。

String

なし

AUTH_CLIENT_ID

apicurio.auth.client.id

シリアライザーおよびデシリアライザーによって使用されます。認証サービスにアクセスするためのクライアント ID。OAuth クライアントクレデンシャルフローを使用してセキュアなレジストリーにアクセスする際に必須です。

String

なし

AUTH_CLIENT_SECRET

apicurio.auth.client.secret

シリアライザーおよびデシリアライザーによって使用されます。認証サービスにアクセスするためのクライアントシークレット。OAuth クライアントクレデンシャルフローを使用してセキュアなレジストリーにアクセスする際に必須です。

String

なし

AUTH_USERNAME

apicurio.auth.username

シリアライザーおよびデシリアライザーによって使用されます。レジストリーにアクセスするためのユーザー名HTTP Basic 認証を使用してセキュアなレジストリーにアクセスする際に必須です。

String

なし

AUTH_PASSWORD

apicurio.auth.password

シリアライザーおよびデシリアライザーによって使用されます。レジストリーにアクセスするためのパスワードHTTP Basic 認証を使用してセキュアなレジストリーにアクセスする際に必須です。

String

なし

レジストリー検索オプションの設定

DefaultSchemaResolver は、次のプロパティーを使用して、Service Registry でアーティファクトを検索する方法を設定します。

Expand
表8.3 レジストリーアーティファクト検索の設定プロパティー
Constantプロパティー説明デフォルト

ARTIFACT_RESOLVER_STRATEGY

apicurio.registry.artifact-resolver-strategy

シリアライザーによってのみ使用されます。ArtifactReferenceResolverStrategy を実装し、各 Kafka メッセージを ArtifactReference (groupIdartifactId、および version) にマップする完全修飾 Java クラス名。たとえば、デフォルトのストラテジーはトピック名をスキーマ artifactId として使用します。

String

io.apicurio.registry.serde.strategy.TopicIdStrategy

EXPLICIT_ARTIFACT_GROUP_ID

apicurio.registry.artifact.group-id

シリアライザーによってのみ使用されます。アーティファクトのクエリーまたは作成に使用される groupId を設定します。ArtifactResolverStrategy によって返される groupId をオーバーライドします。

String

なし

EXPLICIT_ARTIFACT_ID

apicurio.registry.artifact.artifact-id

シリアライザーによってのみ使用されます。アーティファクトのクエリーまたは作成に使用される artifactId を設定します。ArtifactResolverStrategy によって返される artifactId をオーバーライドします。

String

なし

EXPLICIT_ARTIFACT_VERSION

apicurio.registry.artifact.version

シリアライザーによってのみ使用されます。アーティファクトの問い合わせまたは作成に使用されるアーティファクトバージョンを設定します。ArtifactResolverStrategy によって返されるバージョンをオーバーライドします。

String

なし

FIND_LATEST_ARTIFACT

apicurio.registry.find-latest

シリアライザーによってのみ使用されます。シリアライザーが対応するグループ ID およびアーティファクト ID のレジストリー内で最新のアーティファクトの検索を試行するかどうかを指定します。

boolean

false

AUTO_REGISTER_ARTIFACT

apicurio.registry.auto-register

シリアライザーによってのみ使用されます。シリアライザーがレジストリーでアーティファクトを作成しようとするかどうかを指定します。JSON スキーマシリアライザーはこの機能をサポートしません。

boolean, boolean String

false

AUTO_REGISTER_ARTIFACT_IF_EXISTS

apicurio.registry.auto-register.if-exists

シリアライザーによってのみ使用されます。アーティファクトがすでに存在するためにアーティファクトの作成で競合が発生した場合のクライアントの動作を設定します。使用可能な値は、FAILUPDATERETURN、または RETURN_OR_UPDATE です。

String

RETURN_OR_UPDATE

CHECK_PERIOD_MS

apicurio.registry.check-period-ms

シリアライザーおよびデシリアライザーによって使用されます。自動エビクションの前にアーティファクトをキャッシュする時間を指定します (ミリ秒)。ゼロに設定すると、アーティファクトが毎回フェッチされます。

java.time.Duration, non-negative Number, or integer String

30000

RETRY_BACKOFF_MS

apicurio.registry.retry-backoff-ms

シリアライザーおよびデシリアライザーによって使用されます。レジストリーからスキーマを取得できない場合は、何度も再試行されることがあります。この設定オプションは、再試行間の遅延 (ミリ秒) を制御します。

java.time.Duration, non-negative Number, or integer String

300

RETRY_COUNT

apicurio.registry.retry-count

シリアライザーおよびデシリアライザーによって使用されます。レジストリーからスキーマを取得できない場合は、何度も再試行されることがあります。この設定オプションは、再試行の回数を制御します。

non-negative Number, or integer String

3

USE_ID

apicurio.registry.use-id

シリアライザーおよびデシリアライザーによって使用されます。指定された IdOption をアーティファクトの識別子として使用するように設定します。オプションは globalIdcontentId です 。指定された ID を Kafka に書き込むようシリアライザーに指示し、この ID を使用してスキーマを見つけるようにデシリアライザーに指示します。

String

globalId

Kafka でレジストリーアーティファクトを読み書きするための設定

DefaultSchemaResolver は、次のプロパティーを使用して、アーティファクト情報の Kafka への書き込みおよび Kafka からの読み取り方法を設定します。

Expand
表8.4 Kafka でアーティファクト情報を読み書きするための設定プロパティー
Constantプロパティー説明デフォルト

ENABLE_HEADERS

apicurio.registry.headers.enabled

シリアライザーおよびデシリアライザーによって使用されます。メッセージペイロードではなく、Kafka メッセージヘッダーに対してアーティファクト識別子を読み書きするように設定します。

boolean

true

HEADERS_HANDLER

apicurio.registry.headers.handler

シリアライザーおよびデシリアライザーによって使用されます。HeadersHandler を実装し、Kafka メッセージヘッダーに対してアーティファクト識別子を読み書きする完全修飾 Java クラス名。

String

io.apicurio.registry.serde.headers.DefaultHeadersHandler

ID_HANDLER

apicurio.registry.id-handler

シリアライザーおよびデシリアライザーによって使用されます。IdHandler を実装し、メッセージペイロードに対してアーティファクト識別子を読み書きするクラスの完全修飾 Java クラス名。apicurio.registry.headers.enabledfalse に設定されている場合にのみ使用されます。

String

io.apicurio.registry.serde.DefaultIdHandler

ENABLE_CONFLUENT_ID_HANDLER

apicurio.registry.as-confluent

シリアライザーおよびデシリアライザーによって使用されます。IdHandler のレガシー Confluent-compatible 実装を有効にするためのショートカット。apicurio.registry.headers.enabledfalse に設定されている場合にのみ使用されます。

boolean

true

デシリアライザーのフォールバックオプションの設定

DefaultSchemaResolver は、次のプロパティーを使用して、すべてのデシリアライザーのフォールバックプロバイダーを設定します。

Expand
表8.5 デシリアライザーのフォールバックプロバイダーの設定プロパティー
Constantプロパティー説明デフォルト

FALLBACK_ARTIFACT_PROVIDER

apicurio.registry.fallback.provider

デシリアライザーによってのみ使用されます。デシリアライズに使用されるアーティファクトを解決するための FallbackArtifactProvider のカスタム実装を設定します。FallbackArtifactProvider は、検索に失敗した場合にレジストリーから取得するフォールバックアーティファクトを設定します。

String

io.apicurio.registry.serde.fallback.DefaultFallbackArtifactProvider

DefaultFallbackArtifactProvider は、次のプロパティーを使用して、デシリアライザーのフォールバックオプションを設定します。

Expand
表8.6 デシリアライザーのフォールバックオプションの設定プロパティー
Constantプロパティー説明デフォルト

FALLBACK_ARTIFACT_ID

apicurio.registry.fallback.artifact-id

デシリアライザーによってのみ使用されます。デシリアライズに使用されるアーティファクトを解決するためのフォールバックとして使用される artifactId を設定します。

String

なし

FALLBACK_ARTIFACT_GROUP_ID

apicurio.registry.fallback.group-id

デシリアライザーによってのみ使用されます。デシリアライズに使用されるグループのフォールバックとして使用される groupId を設定します。

String

なし

FALLBACK_ARTIFACT_VERSION

apicurio.registry.fallback.version

デシリアライザーによってのみ使用されます。デシリアライズに使用されるアーティファクトを解決するために使用されるバージョンを設定します。

String

なし

関連情報

  • 詳細は、SerdeConfig Java クラス を参照してください。
  • アプリケーションプロパティーを Java システムプロパティーとして設定することも、Quarkus application.properties ファイルに含めることもできます。詳細は、Quarkus のドキュメント を参照してください。

8.3. さまざまなクライアントシリアライザー/デシリアライザータイプの設定方法

Kafka クライアントアプリケーションでスキーマを使用する場合は、ユースケースに応じて、使用する特定のスキーマタイプを選択する必要があります。Service Registry は、Apache Avro、JSON スキーマ、および Google Protobuf 用の SerDe Java クラスを提供します。以下のセクションでは、各タイプを使用するように Kafka アプリケーションを設定する方法を説明します。

また、Kafka を使用してカスタムシリアライザーおよびデシリアライザークラスを実装し、Service Registry REST Java クライアントを使用して Service Registry 機能を活用することもできます。

シリアライザー/デシリアライザーの Kafka アプリケーション設定

Kafka アプリケーションで Service Registry によって提供される SerDe クラスを使用するには、正しい設定プロパティーを設定する必要があります。以下の簡単な Avro の例は、Kafka プロデューサーアプリケーションでシリアライザーを設定する方法と、Kafka コンシューマーアプリケーションでデシリアライザーを設定する方法を示しています。

Kafka プロデューサーのシリアライザー設定の例

// Create the Kafka producer
private static Producer<Object, Object> createKafkaProducer() {
    Properties props = new Properties();

    // Configure standard Kafka settings
    props.putIfAbsent(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, SERVERS);
    props.putIfAbsent(ProducerConfig.CLIENT_ID_CONFIG, "Producer-" + TOPIC_NAME);
    props.putIfAbsent(ProducerConfig.ACKS_CONFIG, "all");

    // Use Service Registry-provided Kafka serializer for Avro
    props.putIfAbsent(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
    props.putIfAbsent(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, AvroKafkaSerializer.class.getName());

    // Configure the Service Registry location
    props.putIfAbsent(SerdeConfig.REGISTRY_URL, REGISTRY_URL);

    // Register the schema artifact if not found in the registry.
    props.putIfAbsent(SerdeConfig.AUTO_REGISTER_ARTIFACT, Boolean.TRUE);

    // Create the Kafka producer
    Producer<Object, Object> producer = new KafkaProducer<>(props);
    return producer;
}
Copy to Clipboard Toggle word wrap

Kafka コンシューマーのデシリアライザー設定の例

// Create the Kafka consumer
private static KafkaConsumer<Long, GenericRecord> createKafkaConsumer() {
    Properties props = new Properties();

    // Configure standard Kafka settings
    props.putIfAbsent(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, SERVERS);
    props.putIfAbsent(ConsumerConfig.GROUP_ID_CONFIG, "Consumer-" + TOPIC_NAME);
    props.putIfAbsent(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");
    props.putIfAbsent(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");
    props.putIfAbsent(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");

    // Use Service Registry-provided Kafka deserializer for Avro
    props.putIfAbsent(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
    props.putIfAbsent(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, AvroKafkaDeserializer.class.getName());

    // Configure the Service Registry location
    props.putIfAbsent(SerdeConfig.REGISTRY_URL, REGISTRY_URL);

    // No other configuration needed because the schema globalId the deserializer uses is sent
    // in the payload. The deserializer extracts the globalId and uses it to look up the schema
    // from the registry.

    // Create the Kafka consumer
    KafkaConsumer<Long, GenericRecord> consumer = new KafkaConsumer<>(props);
    return consumer;
}
Copy to Clipboard Toggle word wrap

8.3.1. Service Registry を使用した Avro SerDes の設定

このトピックでは、Apache Avro の Kafka クライアントシリアライザーおよびデシリアライザー (SerDes) クラスを使用する方法を説明します。

Service Registry は、Avro 用に次の Kafka クライアント SerDes クラスを提供します。

  • io.apicurio.registry.serde.avro.AvroKafkaSerializer
  • io.apicurio.registry.serde.avro.AvroKafkaDeserializer

Avro シリアライザーの設定

以下のように Avro シリアライザークラスを設定することができます。

  • Service Registry の URL
  • アーティファクトリーゾルバーストラテジー
  • ID の場所
  • ID エンコーディング
  • Avro datum プロバイダー
  • Avro エンコーディング

ID の場所

シリアライザーは、スキーマの一意の ID を Kafka メッセージの一部として渡し、コンシューマーがデシリアライズに正しいスキーマを使用できるようにします。ID は、メッセージのペイロードまたはメッセージヘッダーに存在できます。デフォルトの場所はメッセージペイロードです。メッセージヘッダーで ID を送信するには、以下の設定プロパティーを設定します。

props.putIfAbsent(SerdeConfig.ENABLE_HEADERS, "true")
Copy to Clipboard Toggle word wrap

プロパティー名は apicurio.registry.headers.enabled です。

ID エンコーディング

Kafka メッセージボディーに渡すときにスキーマ ID をエンコードする方法をカスタマイズできます。apicurio.registry.id-handler 設定プロパティーを、io.apicurio.registry.serde.IdHandler インターフェイスを実装するクラスに設定します。Service Registry は以下の実装を提供します。

  • io.apicurio.registry.serde.DefaultIdHandler:ID を 8 バイト長として格納します
  • io.apicurio.registry.serde.Legacy4ByteIdHandler:ID を 4 バイト整数として格納します

Service Registry はスキーマ ID を long として表しますが、従来の理由、または他のレジストリーまたは SerDe クラスとの互換性のため、ID の送信時に 4 バイトの使用が推奨される場合があります。

Avro datum プロバイダー

Avro は、データを読み書きするためのさまざまなデータライターとリーダーを提供します。Service Registry は、3 つの異なるタイプをサポートします。

  • Generic
  • Specific
  • Reflect

Service Registry AvroDatumProvider は、使用されるタイプの抽象概念であり、DefaultAvroDatumProvider がデフォルトで使用されます。

以下の設定オプションを設定できます。

  • apicurio.registry.avro-datum-provider: AvroDatumProvider 実装の完全修飾 Java クラス名を指定します (例えば、io.apicurio.registry.serde.avro.ReflectAvroDatumProvider)。
  • apicurio.registry.use-specific-avro-reader: DefaultAvroDatumProvider を使用するときに特定のタイプを使用するには、true に設定します

Avro エンコーディング

Avro を使用してデータをシリアライズする場合は、Avro バイナリーエンコーディング形式を使用して、データを可能な限り効率的な形式でエンコードすることができます。Avro は JSON としてデータのエンコードもサポートします。これにより、ロギングやデバッグなどの各メッセージのペイロードの検証が容易になります。

apicurio.registry.avro.encoding プロパティーを JSON または BINARY の値で設定することにより、Avro エンコーディングを設定できます。デフォルトは BINARY です。

Avro デシリアライザーの設定

Avro デシリアライザーの設定を、シリアライザーの設定と一致するように、Avro デシリアライザークラスを設定する必要があります。

  • Service Registry の URL
  • ID エンコーディング
  • Avro datum プロバイダー
  • Avro エンコーディング

これらの設定オプションは、シリアライザーセクションを参照してください。プロパティー名と値は同じです。

注記

デシリアライザーの設定時には、以下のオプションは必要ありません。

  • アーティファクトリーゾルバーストラテジー
  • ID の場所

デシリアライザークラスは、メッセージからこれらのオプションの値を判断できます。シリアライザーはメッセージの一部として ID を送信するため、ストラテジーは必要ありません。

ID の位置は、メッセージペイロードの先頭にあるマジックバイトを確認することで決定されます。そのバイトが見つかると、設定されたハンドラーを使用してメッセージペイロードから ID が読み取られます。マジックバイトが見つからない場合、ID はメッセージヘッダーから読み込まれます。

Avro SerDes とアーティファクトの参照

レコードがネスト化された Avro メッセージとスキーマを使用する場合に、ネストされたレコードごとに新しいアーティファクトが登録されます。たとえば、次の TradeKey スキーマには、ネストされた Exchange スキーマが含まれています。

ネストされた Exchange スキーマを持つ TradeKey スキーマ

{
  "namespace": "com.kubetrade.schema.trade",
  "type": "record",
  "name": "TradeKey",
  "fields": [
    {
      "name": "exchange",
      "type": "com.kubetrade.schema.common.Exchange"
    },
    {
      "name": "key",
      "type": "string"
    }
  ]
}
Copy to Clipboard Toggle word wrap

交換スキーマ

{
  "namespace": "com.kubetrade.schema.common",
  "type": "enum",
  "name": "Exchange",
  "symbols" : ["GEMINI"]
}
Copy to Clipboard Toggle word wrap

これらのスキーマを Avro SerDes で使用すると、Service Registry に、TradeKey スキーマ用と、Exchange スキーマ用の 2 つのアーティファクトが作成されます。TradeKey スキーマを使用するメッセージがシリアライズまたはデシリアライズされるたびに、両方のスキーマが取得されるため、定義を異なるファイルに分割できます。

8.3.2. Service Registry を使用した JSON スキーマ SerDes の設定

このトピックでは、JSON スキーマの Kafka クライアントシリアライザーおよびデシリアライザー (SerDes) クラスを使用する方法を説明します。

Service Registry は、JSON スキーマ用に次の Kafka クライアント SerDes クラスを提供します。

  • io.apicurio.registry.serde.jsonschema.JsonSchemaKafkaSerializer
  • io.apicurio.registry.serde.jsonschema.JsonSchemaKafkaDeserializer

Apache Avro とは異なり、JSON スキーマはシリアライズテクノロジーではなく、検証テクノロジーです。その結果、JSON スキーマの設定オプションは大きく異なります。たとえば、データは常に JSON としてエンコードされるため、エンコーディングオプションはありません。

JSON スキーマシリアライザーの設定

JSON スキーマシリアライザークラスを以下のように設定できます。

  • Service Registry の URL
  • アーティファクトリーゾルバーストラテジー
  • スキーマ検証

唯一の標準以外の設定プロパティーは、デフォルトで有効になっている JSON スキーマバリデーションです。これを無効にするには、apicurio.registry.serde.validation-enabled"false" に設定します。以下に例を示します。

props.putIfAbsent(SerdeConfig.VALIDATION_ENABLED, Boolean.FALSE)
Copy to Clipboard Toggle word wrap

JSON スキーマデシリアライザーの設定

JSON スキーマデシリアライザークラスを以下のように設定できます。

  • Service Registry の URL
  • スキーマ検証
  • データをデシリアライズするためのクラス

スキーマをロードできるように、Service Registry の場所を指定する必要があります。他の設定はオプションです。

注記

デシリアライザーの検証は、シリアライザーが Kafka メッセージでグローバル ID を渡す場合にのみ機能します。これは、シリアライザーで検証が有効になっている場合にのみ発生します。

JSON スキーマの SerDes とアーティファクトの参照

JSON スキーマ SerDes はメッセージペイロードからスキーマを検出できないため、事前にスキーマアーティファクトを登録する必要があり、これはアーティファクト参照にも適用されます。

スキーマの内容に応じて、$ref の値は URL に置き換えます。SerDes はこの URL を使用して参照のスキーマを解決しようとし、主要なスキーマに対するデータの検証、ネスト化されたスキーマに対するネスト化された値の検証など、検証は通常どおりに行われます。Service Registry でアーティファクトを参照するためのサポートも実装されています。

たとえば、次の city.json スキーマは city.json スキーマを参照ししています。

city.json スキーマを参照する citizen.json スキーマ

{
 "$id": "https://example.com/citizen.schema.json",
 "$schema": "http://json-schema.org/draft-07/schema#",
 "title": "Citizen",
 "type": "object",
 "properties": {
   "firstName": {
     "type": "string",
     "description": "The citizen's first name."
   },
   "lastName": {
     "type": "string",
     "description": "The citizen's last name."
   },
   "age": {
     "description": "Age in years which must be equal to or greater than zero.",
     "type": "integer",
     "minimum": 0
   },
   "city": {
     "$ref": "city.json"
   }
 }
}
Copy to Clipboard Toggle word wrap

city.json スキーマ

{
 "$id": "https://example.com/city.schema.json",
 "$schema": "http://json-schema.org/draft-07/schema#",
 "title": "City",
 "type": "object",
 "properties": {
   "name": {
     "type": "string",
     "description": "The city's name."
   },
   "zipCode": {
     "type": "integer",
     "description": "The zip code.",
     "minimum": 0
   }
 }
}
Copy to Clipboard Toggle word wrap

この例では、citizen に city が含まれます。Service Registry では、city アーティファクトへの参照を持つ citizen アーティファクトが、city.json という名前を使用して作成されます。SerDes では、citizen スキーマをフェッチすると、citizen スキーマから参照されるため、city スキーマもフェッチされます。データをシリアライズ/デシリアライズする場合、ネストされたスキーマを解決するために参照名が使用され、citizen スキーマとネストされた city スキーマに対する検証が可能になります。

8.3.3. Service Registry を使用した Protobuf SerDes の設定

このトピックでは、Google Protobuf の Kafka クライアントシリアライザーおよびデシリアライザー (SerDes) クラスを使用する方法を説明します。

Service Registry は、Protobuf 用に次の Kafka クライアント SerDes クラスを提供します。

  • io.apicurio.registry.serde.protobuf.ProtobufKafkaSerializer
  • io.apicurio.registry.serde.protobuf.ProtobufKafkaDeserializer

Protobuf シリアライザーの設定

Protobuf シリアライザークラスを以下のように設定できます。

  • Service Registry の URL
  • アーティファクトリーゾルバーストラテジー
  • ID の場所
  • ID エンコーディング
  • スキーマ検証

これらの設定オプションの詳細は、以下のセクションを参照してください。

Protobuf デシリアライザーの設定

シリアライザーの以下の設定と一致するように、Protobuf デシリアライザークラスを設定する必要があります。

  • Service Registry の URL
  • ID エンコーディング

設定プロパティー名と値はシリアライザーの場合と同じです。

注記

デシリアライザーの設定時には、以下のオプションは必要ありません。

  • アーティファクトリーゾルバーストラテジー
  • ID の場所

デシリアライザークラスは、メッセージからこれらのオプションの値を判断できます。シリアライザーはメッセージの一部として ID を送信するため、ストラテジーは必要ありません。

ID の位置は、メッセージペイロードの先頭にあるマジックバイトを確認することで決定されます。そのバイトが見つかると、設定されたハンドラーを使用してメッセージペイロードから ID が読み取られます。マジックバイトが見つからない場合、ID はメッセージヘッダーから読み込まれます。

注記

Protobuf デシリアライザーは、正確な Protobuf Message 実装へデシリアライズしません。DynamicMessage インスタンスへデシリアライズします。設定しない場合は、適切な API はありません。

Protobuf SerDes とアーティファクト参照

import ステートメントを含む複雑な Protobuf メッセージが使用される場合に、インポートされた Protobuf メッセージは個別のアーティファクトとして Service Registry に保存されます。次に、Service Registry がメインスキーマを取得して Protobuf メッセージをチェックすると、完全なメッセージスキーマをチェックしてシリアル化できるように参照されているスキーマも取得されます。

たとえば、次の table_info.proto スキーマファイルには、インポートされた mode.proto スキーマファイルが含まれています。

インポートされた .mode.proto ファイルを含む table_info.proto ファイル

syntax = "proto3";
package sample;
option java_package = "io.api.sample";
option java_multiple_files = true;

import "sample/mode.proto";

message TableInfo {

 int32 winIndex = 1;
 Mode mode = 2;
 int32 min = 3;
 int32 max = 4;
 string id = 5;
 string dataAdapter = 6;
 string schema = 7;
 string selector = 8;
 string subscription_id = 9;
}
Copy to Clipboard Toggle word wrap

mode.proto ファイル

syntax = "proto3";
package sample;
option java_package = "io.api.sample";
option java_multiple_files = true;

enum Mode {

MODE_UNKNOWN = 0;
RAW = 1;
MERGE = 2;
DISTINCT = 3;
COMMAND = 4;
}
Copy to Clipboard Toggle word wrap

この例では、TableInfo 用と Mode 用の 2 つの Protobuf アーティファクトが Service Registry に格納されます。ただし、ModeTableInfo の一部であるため、SerDes 内のメッセージをチェックするために TableInfo がフェッチされるたびに、ModeTableInfo で参照されるアーティファクトとして返されます。

第9章 Service Registry アーティファクトの参照

この章では、Service Registry に保存されるサポート対象のアーティファクトタイプ、状態、およびメタデータに関する参照情報を提供します。

9.1. Service Registry アーティファクトタイプ

Service Registry では、さまざまなスキーマおよび API アーティファクトタイプを保存して管理できます。

Expand
表9.1 Service Registry アーティファクトタイプ
説明

ASYNCAPI

AsyncAPI 仕様

AVRO

Apache Avro スキーマ

GRAPHQL

GraphQL スキーマ

JSON

JSON スキーマ

KCONNECT

Apache Kafka Connect スキーマ

OPENAPI

OpenAPI 仕様

PROTOBUF

Google プロトコルバッファースキーマ

WSDL

Web Services Definition Language

XML

拡張マークアップ言語

XSD

XML Schema Definition

9.2. Service Registry アーティファクトの状態

Service Registry の有効なアーティファクトの状態は、ENABLEDDISABLED、および DEPRECATED です。

Expand
表9.2 Service Registry アーティファクトの状態
状態説明

ENABLED

基本状態、全ての操作が可能です。

DISABLED

アーティファクトとそのメタデータは、Service Registry Web コンソールを使用して表示および検索できますが、そのコンテンツはどのクライアントでもフェッチできません。

DEPRECATED

アーティファクトは完全に使用可能ですが、アーティファクトのコンテンツがフェッチされるたびに、ヘッダーが REST API 応答に追加されます。Service Registry Rest Client は、非推奨となったコンテンツが見つかったときにも警告をログに記録します。

9.3. Service Registry アーティファクトのメタデータ

アーティファクトが Service Registry に追加されると、メタデータプロパティーのセットがアーティファクトの内容と共に作成され保存されます。このメタデータは、読み取り専用のシステム生成またはユーザー生成のプロパティーと、アーティファクトの作成後に更新できる編集可能なプロパティーで構成されます。

Expand
表9.3 Service Registry システムによって生成されたメタデータ
プロパティー説明

contentId

integer

Service Registry のアーティファクトコンテンツの一意の識別子。アーティファクトバージョンに同一のコンテンツがある場合、同じコンテンツ ID を複数のアーティファクトバージョンで共有できます。たとえば、コンテンツ ID 4 は、コンテンツが同じ複数のアーティファクトバージョンで使用できます。

createdBy

string

アーティファクトを作成したユーザーの名前。

createdOn

date

アーティファクトが作成された日時 (例: 2023-10-11T14:15:28Z)

globalId

integer

Service Registry レジストリー内のアーティファクトバージョンのグローバルに一意な識別子。たとえば、Service Registry で作成された最初のアーティファクトバージョンには、グローバル ID 1 が割り当てられます。

modifiedBy

string

アーティファクトを変更したユーザーの名前。

modifiedOn

date

アーティファクトが変更された日時 (例: 2023-10-11T14:15:28Z)

type

ArtifactType

サポートされているアーティファクトのタイプ (AVROOPENAPIPROTOBUF など)。

Expand
表9.4 Service Registry のユーザー提供またはシステム生成のメタデータ
プロパティー説明

groupId

string

Service Registry 内のアーティファクトグループの一意の識別子 (development または production など)。Service Registry Web コンソールを使用してアーティファクトを作成する時にグループ ID を指定しない場合は、default に設定されます。Apicurio Registry REST API、Java クライアント、または Maven プラグインを使用する場合は、グループ ID を指定する必要があります。

id

string

Service Registry 内のアーティファクトの一意の識別子。アーティファクト ID を指定することも、Service Registry によって生成された UUID (8d168cad-1865-4e6c-bb7e-04e8be005bea など) を使用することもできます。アーティファクトの異なるバージョンは同じアーティファクト ID を使用しますが、グローバル ID は異なります。

references

ArtifactReference の配列

アーティファクトに含まれるアーティファクト参照のオプションのセット。アーティファクトの作成時に指定できます。[{"groupId":"my-group","artifactId":"ItemId","version":"1","name":"com.example.common.ItemId"}] の簡単な例は、単一のアーティファクト参照を示しています。

version

integer

アーティファクトの最新バージョン。生成されたバージョン (例: 3) を使用することも、Service Registry REST API または Maven プラグインを使用してバージョン (例: 2.1.6) を指定することもできます。

Expand
表9.5 Service Registry の編集可能なメタデータ
プロパティー説明

description

string

アーティファクトの意味のあるオプションの説明 (例: This is a simple OpenAPI for testing)。説明を入力することも、すでに提供されている場合は、OpenAPI および AsyncAPI アーティファクトの info セクションから自動的に検出することもできます。

labels

string の配列

アーティファクトのフィルターと検索に使用されるオプションのコンマ区切りのラベルのリスト (例: test,protobuf)。ユーザーによって指定されます。

name

string

人間が判読できるアーティファクトのオプションの名前 (例: My first Avro schema)。説明を入力することも、title フィールドに値がある場合は、OpenAPI および AsyncAPI アーティファクトの info セクションから自動的に検出することもできます。

properties

map

アーティファクトに関連付けられたユーザー定義の名前と値のペアのオプションのリスト。名前と値は文字列である必要があります (例: my-key および my-value)

state

ArtifactState

アーティファクトの最新の状態: ENABLEDDISABLED、または DEPRECATED。デフォルトでは ENABLED に設定されています。

アーティファクトメタデータの更新

  • Service Registry REST API または Web コンソールを使用して、編集可能なメタデータプロパティーのセットを更新できます。
  • state プロパティーを更新できるのは、Service Registry REST API を使用する場合のみです。

第10章 Service Registry コンテンツルールのリファレンス

この章では、サポートされているコンテンツルールタイプ、アーティファクトタイプのサポートレベル、およびアーティファクト固有およびグローバルルールの優先順位に関する参照情報を提供します。

10.1. Service Registry コンテンツルールタイプ

VALIDITYCOMPATIBILITY、および INTEGRITY ルールタイプを指定して、Service Registry でのコンテンツの変化を制御できます。これらのルールタイプは、グローバルルールとアーティファクト固有のルールの両方に適用されます。

Expand
表10.1 Service Registry コンテンツルールタイプ
説明

VALIDITY

コンテンツを Service Registry に追加する前に検証してください。このルールに使用できる設定値は以下のとおりです。

  • FULL: 検証はシンタックスとセマンティックの両方で行われます。
  • SYNTAX_ONLY: 検証は構文のみです。
  • NONE: すべての検証チェックが無効になります。

COMPATIBILITY

アーティファクトを更新するときに互換性レベルを適用します (たとえば、下位互換性を得るには BACKWARD を選択します)。新しいアーティファクトが、以前に追加されたアーティファクトのバージョンまたはクライアントと互換性があることを確認します。このルールに使用できる設定値は以下のとおりです。

  • FULL: 新しいアーティファクトは、最後に追加されたアーティファクトと上位および下位互換性があります。
  • FULL_TRANSITIVE: 新しいアーティファクトは、以前に追加されたすべてのアーティファクトと上位互換性および下位互換性があります。
  • BACKWARD: 新しいアーティファクトを使用するクライアントは、最後に追加されたアーティファクトを使用して書き込まれたデータを読み取りできます。
  • BACKWARD_TRANSITIVE: 新しいアーティファクトを使用しているクライアントは、以前に追加されたすべてのアーティファクトを使用して書き込まれたデータを読み取ることができます。
  • FORWARD: 最後に追加されたアーティファクトを使用するクライアントは、新しいアーティファクトを使用して書き込まれたデータを読み取りできます。
  • FORWARD_TRANSITIVE: 以前に追加されたすべてのアーティファクトを使用しているクライアントは、新しいアーティファクトを使用して書き込まれたデータを読み取ることができます。
  • NONE: 下位互換性および上位互換性チェックはすべて無効になります。

INTEGRITY

アーティファクトを作成または更新するときに、アーティファクト参照の整合性を適用します。このルールを有効にして設定し、提供されたアーティファクト参照が正しいことを確認します。このルールに使用できる設定値は以下のとおりです。

  • FULL: すべてのアーティファクト参照整合性のチェックが有効化されます。
  • NO_DUPLICATES: 重複するアーティファクト参照があるかどうかを検出します。
  • REFS_EXIST: 存在しないアーティファクトへの参照があるかどうかを検出します。
  • ALL_REFS_MAPPED: すべてのアーティファクト参照がマップされていることを確認します。
  • NONE: すべてのアーティファクト参照整合性のチェックが無効化されます。

10.2. Service Registry コンテンツルールの成熟度

すべてのコンテンツルールは、Service Registry でサポートされるすべてのアーティファクトタイプに対して完全に実装されるわけではありません。以下の表は、各ルールおよびアーティファクトタイプの現在の成熟度レベルを示しています。

Expand
表10.2 Service Registry コンテンツルールの成熟度マトリックス
アーティファクトタイプ検証ルール互換性ルール整合性ルール

Avro

完全

完全

完全

Protobuf

完全

完全

完全

JSON スキーマ

完全

完全

マッピング検出はサポートされていません

OpenAPI

完全

なし

完全

AsyncAPI

構文のみ

なし

完全

GraphQL

構文のみ

なし

マッピング検出はサポートされていません

Kafka Connect

構文のみ

なし

マッピング検出はサポートされていません

WSDL

完全

なし

マッピング検出はサポートされていません

XML

完全

なし

マッピング検出はサポートされていません

XSD

完全

なし

マッピング検出はサポートされていません

10.3. Service Registry コンテンツルールの優先順位

アーティファクトを追加または更新すると、Service Registry はルールを適用して、アーティファクトコンテンツの有効性、互換性、または整合性をチェックします。次の表に示すように、設定されたアーティファクト固有のルールは、同等の設定済みグローバルルールをオーバーライドします。

Expand
表10.3 Service Registry コンテンツルールの優先順位
アーティファクト固有のルールグローバルルールこのアーティファクトに適用されるルール他のアーティファクトで利用できるグローバルルール

Enabled

Enabled

アーティファクト固有

はい

無効

Enabled

Global

はい

無効

無効

なし

いいえ

有効、None に設定

Enabled

なし

はい

無効

有効、None に設定

なし

いいえ

付録A サブスクリプションの使用

Service Registry は、ソフトウェアサブスクリプションを通じて提供されます。サブスクリプションを管理するには、Red Hat カスタマーポータルでアカウントにアクセスします。

アカウントへのアクセス

  1. access.redhat.com に移動します。
  2. アカウントがない場合は作成します。
  3. アカウントにログインします。

サブスクリプションのアクティベート

  1. access.redhat.com に移動します。
  2. My Subscriptions に移動します。
  3. Activate a subscription に移動し、16 桁のアクティベーション番号を入力します。

ZIP および TAR ファイルのダウンロード

ZIP または TAR ファイルにアクセスするには、カスタマーポータルを使用して、ダウンロードする関連ファイルを検索します。RPM パッケージを使用している場合、この手順は必要ありません。

  1. ブラウザーを開き、access.redhat.com/downloads で Red Hat カスタマーポータルの Product Downloads ページにログインします。
  2. Integration and Automation カテゴリーで Red Hat Integration エントリーを見つけます。
  3. 必要な Service Registry 製品を選択します。Software Downloads ページが開きます。
  4. コンポーネントの Download リンクをクリックします。

改訂日時: 2024-01-26

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat