서비스 레지스트리 사용자 가이드


Red Hat Integration 2023.q2

Service Registry 2.4에서 스키마 및 API 관리

Red Hat Integration Documentation Team

초록

이 가이드에서는 서비스 레지스트리를 소개하고 Service Registry 웹 콘솔, REST API, Maven 플러그인 또는 Java 클라이언트를 사용하여 이벤트 스키마 및 API 설계를 관리하는 방법을 설명합니다. 이 가이드에서는 Java 소비자 및 생산자 애플리케이션에서 Kafka 클라이언트를 직렬화 및 역직렬화하는 방법도 설명합니다. 또한 지원되는 서비스 레지스트리 콘텐츠 유형 및 선택적 규칙 구성에 대해 설명합니다.

머리말

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견에 감사드립니다. 피드백을 제공하려면 문서의 텍스트를 강조 표시하고 주석을 추가합니다.

사전 요구 사항

  • Red Hat 고객 포털에 로그인되어 있습니다.
  • Red Hat 고객 포털에서 문서는 Multi-page HTML 보기 형식으로 되어 있습니다.

절차

피드백을 제공하려면 다음 단계를 수행합니다.

  1. 문서 의 오른쪽 상단에 있는 피드백 버튼을 클릭하여 기존 피드백을 확인합니다.

    참고

    피드백 기능은 Multi-page HTML 형식으로만 활성화됩니다.

  2. 피드백을 제공할 문서의 섹션을 강조 표시합니다.
  3. 강조 표시된 텍스트 근처에 표시되는 피드백 추가 팝업을 클릭합니다.

    페이지 오른쪽의 피드백 섹션에 텍스트 상자가 나타납니다.A text box appears in the feedback section on the right side of the page.

  4. 텍스트 상자에 피드백을 입력하고 Submit 을 클릭합니다.

    문서 문제가 생성되었습니다.

  5. 문제를 보려면 피드백 보기에서 문제 링크를 클릭합니다.

1장. 서비스 레지스트리 소개

이 장에서는 서비스 레지스트리 개념 및 기능을 소개하고 레지스트리에 저장된 지원되는 아티팩트 유형에 대한 세부 정보를 제공합니다.

1.1. Service Registry란 무엇인가?

Service Registry는 이벤트 중심 및 API 아키텍처 전반에서 표준 이벤트 스키마 및 API 설계를 공유하기 위한 데이터 저장소입니다. 서비스 레지스트리를 사용하여 클라이언트 애플리케이션에서 데이터 구조를 분리하고 REST 인터페이스를 사용하여 런타임에 데이터 유형 및 API 설명을 공유 및 관리할 수 있습니다.

클라이언트 애플리케이션은 재배포 없이 런타임 시 서비스 레지스트리로 최신 스키마 업데이트를 동적으로 내보내거나 가져올 수 있습니다. 개발자 팀은 이미 프로덕션에 배포된 서비스에 필요한 기존 스키마에 대해 서비스 레지스트리를 쿼리할 수 있으며 개발 중인 새 서비스에 필요한 새 스키마를 등록할 수 있습니다.

클라이언트 애플리케이션 코드에서 서비스 레지스트리 URL을 지정하여 서비스 레지스트리에 저장된 스키마 및 API 설계를 사용하도록 클라이언트 애플리케이션을 활성화할 수 있습니다. 서비스 레지스트리는 메시지를 직렬화 및 역직렬화하는 데 사용되는 스키마를 저장할 수 있으며, 이러한 메시지를 클라이언트 애플리케이션에서 참조하여 전송 및 수신하는 메시지가 해당 스키마와 호환되도록 할 수 있습니다.

서비스 레지스트리를 사용하여 데이터 구조를 애플리케이션에서 분리하면 전체 메시지 크기를 줄임으로써 비용이 절감되고 조직 전체에서 스키마 및 API 설계를 일관되게 재사용할 수 있습니다. Service Registry에서는 개발자와 관리자가 레지스트리 콘텐츠를 쉽게 관리할 수 있는 웹 콘솔을 제공합니다.

서비스 레지스트리 콘텐츠의 진화를 제어하는 선택적 규칙을 구성할 수 있습니다. 여기에는 업로드된 콘텐츠가 유효한지 또는 다른 버전과 호환되는 규칙이 포함됩니다. 구성된 모든 규칙은 새 버전을 서비스 레지스트리에 업로드하기 전에 전달해야 하므로 유효하지 않거나 호환되지 않는 스키마 또는 API 설계에서 시간이 손상되지 않도록 합니다.

Service Registry는 Apicurio Registry 오픈 소스 커뮤니티 프로젝트를 기반으로 합니다. 자세한 내용은 https://github.com/apicurio/apicurio-registry 에서 참조하십시오.

서비스 레지스트리 기능
  • Apache Avro, JSON Schema, Google Protobuf, AsyncAPI, OpenAPI 등과 같은 표준 이벤트 스키마 및 API 사양에 대한 여러 페이로드 형식.
  • AMQ Streams 또는 PostgreSQL 데이터베이스의 플러그형 서비스 레지스트리 스토리지 옵션입니다.
  • 컨텐츠 검증, 호환성 및 무결성을 위한 규칙으로, 서비스 레지스트리 컨텐츠가 시간이 지남에 따라 진화하는 방식을 관리합니다.
  • 웹 콘솔, REST API, 명령줄, Maven 플러그인 또는 Java 클라이언트를 사용한 서비스 레지스트리 콘텐츠 관리.
  • 외부 시스템용 Kafka Connect와의 통합을 포함하여 전체 Apache Kafka 스키마 레지스트리 지원
  • Kafka 클라이언트 serializers/deserializers(SerDes)는 런타임 시 메시지 유형을 검증합니다.
  • 기존 Confluent 스키마 레지스트리 클라이언트 애플리케이션과의 호환성.
  • 메모리 풋프린트 및 빠른 배포 시간을 위한 클라우드 네이티브 Quarkus Java 런타임입니다.
  • OpenShift에 Operator 기반 서비스 레지스트리 설치.
  • Red Hat Single Sign-On을 사용한 OIDC(OpenID Connect) 인증.

1.2. 서비스 레지스트리의 스키마 및 API 아티팩트

이벤트 스키마 및 API 디자인과 같은 서비스 레지스트리에 저장된 항목은 레지스트리 아티팩트 라고 합니다. 다음은 간단한 공유 가격 애플리케이션의 JSON 형식의 Apache Avro 스키마 아티팩트 예제를 보여줍니다.

Avro 스키마의 예

{
   "type": "record",
   "name": "price",
   "namespace": "com.example",
   "fields": [
       {
           "name": "symbol",
           "type": "string"
       },
       {
           "name": "price",
           "type": "string"
       }
   ]
}

그런 다음 클라이언트 애플리케이션이 서비스 레지스트리에 아티팩트로 스키마 또는 API 설계를 추가하면 클라이언트 메시지가 런타임 시 올바른 데이터 구조를 준수하는지 검증할 수 있습니다.

스키마 및 API 그룹

아티팩트 그룹은 스키마 또는 API 아티팩트의 선택적 이름이 지정된 컬렉션입니다. 각 그룹에는 일반적으로 특정 애플리케이션 또는 조직에 속하는 단일 엔티티에 의해 관리되는 논리적 관련 스키마 또는 API 디자인 세트가 포함되어 있습니다.

스키마 및 API 설계를 추가하여 서비스 레지스트리에서 구성할 때 선택적 아티팩트 그룹을 생성할 수 있습니다. 예를 들어 개발프로덕션 애플리케이션 환경 또는 영업엔지니어링 조직에 맞는 그룹을 생성할 수 있습니다.

스키마 및 API 그룹은 여러 아티팩트 유형을 포함할 수 있습니다. 예를 들어 동일한 그룹에 Protobuf, Avro, JSON Schema, OpenAPI 또는 AsyncAPI 아티팩트가 모두 있을 수 있습니다.

서비스 레지스트리 웹 콘솔, 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

이 예제에서는 my-group 이라는 아티팩트 그룹을 생성하고 공유 변형의 아티팩트 ID가 포함된 Avro 스키마를 추가합니다.

참고

Service Registry 웹 콘솔을 사용할 때 그룹 지정은 선택 사항이며 기본 그룹은 자동으로 생성됩니다. REST API 또는 Maven 플러그인을 사용하는 경우 고유한 그룹을 생성하지 않으려면 API 경로에 기본 그룹을 지정합니다.

추가 리소스

다른 스키마 및 API에 대한 참조

일부 서비스 레지스트리 아티팩트 유형에는 한 아티팩트 파일에서 다른 아티팩트 파일로의 아티팩트 참조가 포함될 수 있습니다. 재사용 가능한 스키마 또는 API 구성 요소를 정의한 다음 여러 위치에서 참조하여 유효성을 높일 수 있습니다. 예를 들어, $ref 문을 사용하여 JSON 스키마 또는 OpenAPI에서 참조를 지정하거나 import 문을 사용하거나 중첩 네임스페이스를 사용하는 Apache Avro에서 Google Protobuf에서 지정할 수 있습니다.

다음 예제에서는 중첩 네임스페이스를 사용하여 Exchange 라는 다른 스키마에 대한 참조를 포함하는 IRQ Key 라는 간단한 Avro 스키마를 보여줍니다.

TRADEKEY 스키마 중첩 Exchange 스키마

{
 "namespace": "com.kubetrade.schema.trade",
 "type": "record",
 "name": "TradeKey",
 "fields": [
   {
     "name": "exchange",
     "type": "com.kubetrade.schema.common.Exchange"
   },
   {
     "name": "key",
     "type": "string"
   }
 ]
}

교환 스키마

{
 "namespace": "com.kubetrade.schema.common",
 "type": "enum",
 "name": "Exchange",
 "symbols" : ["GEMINI"]
}

아티팩트 참조는 서비스 레지스트리에 아티팩트 유형별 참조에서 내부 서비스 레지스트리 참조에 매핑되는 아티팩트 메타데이터의 컬렉션으로 저장됩니다. 서비스 레지스트리의 각 아티팩트 참조는 다음으로 구성됩니다.

  • 그룹 ID
  • 아티팩트 ID
  • 아티팩트 버전
  • 아티팩트 참조 이름

Service Registry core REST API, Maven 플러그인 및 Java serializers/deserializers(SerDes)를 사용하여 아티팩트 참조를 관리할 수 있습니다. 서비스 레지스트리는 아티팩트 콘텐츠와 함께 아티팩트 참조를 저장합니다. 서비스 레지스트리는 또한 모든 아티팩트 참조 컬렉션을 유지 관리하므로 이를 검색하거나 특정 아티팩트에 대한 모든 참조를 나열할 수 있습니다.

지원되는 아티팩트 유형

Service Registry는 현재 다음 아티팩트 유형에 대한 아티팩트 참조만 지원합니다.

  • Avro
  • protobuf
  • JSON Schema

1.3. 서비스 레지스트리 웹 콘솔을 사용하여 콘텐츠 관리

서비스 레지스트리 웹 콘솔을 사용하여 레지스트리에 저장된 스키마 및 API 아티팩트 및 선택적 그룹을 찾아 검색하고 새 스키마 및 API 아티팩트, 그룹 및 버전을 추가할 수 있습니다. 아티팩트는 레이블, 이름, 그룹, 설명별로 검색할 수 있습니다. 아티팩트의 콘텐츠 또는 사용 가능한 버전을 보거나 아티팩트 파일을 로컬로 다운로드할 수 있습니다.

레지스트리 콘텐츠에 대한 선택적 규칙을 전역과 각 스키마 및 API 아티팩트에 대해 구성할 수도 있습니다. 콘텐츠 검증 및 호환성을 위한 선택적 규칙은 새 스키마 및 API 아티팩트 또는 버전이 레지스트리에 업로드될 때 적용됩니다.

자세한 내용은 10장. 서비스 레지스트리 콘텐츠 규칙 참조 에서 참조하십시오.

그림 1.1. 서비스 레지스트리 웹 콘솔

서비스 레지스트리 웹 콘솔

서비스 레지스트리 웹 콘솔은 http://MY_REGISTRY_URL/ui 에서 사용할 수 있습니다.

1.4. 클라이언트용 서비스 레지스트리 REST API

클라이언트 애플리케이션은 코어 레지스트리 API v2를 사용하여 서비스 레지스트리에서 스키마 및 API 아티팩트를 관리할 수 있습니다. 이 API는 다음 기능에 대한 작업을 제공합니다.

admin
.zip 파일에서 서비스 레지스트리 데이터를 내보내거나 가져오고 런타임 시 서비스 레지스트리 인스턴스의 로깅 수준을 관리합니다.
아티팩트
서비스 레지스트리에 저장된 스키마 및 API 아티팩트를 관리합니다. 아티팩트의 라이프사이클 상태( enabled, disabled 또는 deprecated)를 관리할 수도 있습니다.
아티팩트 메타데이터
스키마 또는 API 아티팩트에 대한 세부 정보를 관리합니다. 아티팩트 이름, 설명 또는 레이블과 같은 세부 정보를 편집할 수 있습니다. 아티팩트 그룹 및 아티팩트가 생성되거나 수정된 경우와 같은 세부 정보는 읽기 전용입니다.
아티팩트 규칙
잘못된 콘텐츠 또는 호환되지 않는 콘텐츠가 서비스 레지스트리에 추가되지 않도록 특정 스키마 또는 API 아티팩트의 콘텐츠 진화를 제어하는 규칙을 구성합니다. artifact 규칙은 구성된 모든 글로벌 규칙을 재정의합니다.
아티팩트 버전
스키마 또는 API 아티팩트가 업데이트될 때 생성되는 버전을 관리합니다. 아티팩트 버전의 라이프사이클 상태( enabled, disabled 또는 deprecated)도 관리할 수 있습니다.
글로벌 규칙
잘못된 콘텐츠 또는 호환되지 않는 콘텐츠가 서비스 레지스트리에 추가되지 않도록 모든 스키마 및 API 아티팩트의 콘텐츠 진화를 제어하는 규칙을 구성합니다. 글로벌 규칙은 아티팩트에 자체 특정 아티팩트 규칙이 구성되어 있지 않은 경우에만 적용됩니다.
검색
예를 들어 이름, 그룹, 설명 또는 레이블별로 스키마 및 API 아티팩트 및 버전을 검색하거나 검색합니다.
시스템
서비스 레지스트리 버전 및 서비스 레지스트리 인스턴스의 리소스에 대한 제한을 가져옵니다.
사용자
현재 서비스 레지스트리 사용자를 가져옵니다.
다른 스키마 레지스트리 REST API와의 호환성

서비스 레지스트리는 또한 각 REST API의 구현을 포함하여 다음 스키마 레지스트리와의 호환성을 제공합니다.

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

Confluent 클라이언트 라이브러리를 사용하는 애플리케이션은 서비스 레지스트리를 드롭인 교체로 사용할 수 있습니다. 자세한 내용은 Confluent Schema Registry 교체를 참조하십시오.

추가 리소스

  • Core Registry API v2에 대한 자세한 내용은 Apicurio Registry REST API 설명서를 참조하십시오.
  • Core Registry API v2 및 모든 호환 API에 대한 API 문서의 경우 서비스 레지스트리 인스턴스의 /apis 끝점(예: http://MY-REGISTRY-URL/apis )을 찾습니다.

1.5. 서비스 레지스트리 스토리지 옵션

Service Registry에서는 레지스트리 데이터의 기본 스토리지에 대해 다음 옵션을 제공합니다.

표 1.1. 서비스 레지스트리 데이터 스토리지 옵션
스토리지 옵션설명

PostgreSQL 데이터베이스

PostgreSQL은 프로덕션 환경에서 성능, 안정성, 데이터 관리(백업/복원 등)에 권장되는 데이터 스토리지 옵션입니다.

AMQ Streams

Kafka 스토리지는 데이터베이스 관리 전문 지식을 사용할 수 없거나 Kafka의 스토리지가 특정 요구 사항입니다.

추가 리소스

1.6. 스키마 및 Java 클라이언트 직렬화기/deserializers를 사용하여 Kafka 메시지 검증

Kafka 생산자 애플리케이션은 serializers를 사용하여 특정 이벤트 스키마를 준수하는 메시지를 인코딩할 수 있습니다. 그런 다음 Kafka 소비자 애플리케이션은 deserializers를 사용하여 특정 스키마 ID를 기반으로 올바른 스키마를 사용하여 메시지를 직렬화했는지 검증할 수 있습니다.

그림 1.2. Service Registry 및 Kafka 클라이언트 SerDes 아키텍처

Kafka 클라이언트 SerDes 아키텍처

Service Registry에서는 Kafka 클라이언트 직렬화기/deserializers(SerDes)를 제공하여 런타임 시 다음 메시지 유형을 검증합니다.

  • Apache Avro
  • Google Protobuf
  • JSON Schema

Service Registry Maven 리포지토리 및 소스 코드 배포에는 Kafka 클라이언트 애플리케이션 개발자가 서비스 레지스트리와 통합하는 데 사용할 수 있는 이러한 메시지 유형에 대한 Kafka SerDes 구현이 포함됩니다.

이러한 구현에는 지원되는 각 메시지 유형에 대한 사용자 지정 Java 클래스(예: io.apicurio.registry.serde.avro )가 포함되며 유효성 검사를 위해 런타임 시 서비스 레지스트리에서 스키마를 가져오는 데 사용할 수 있습니다.

1.7. Kafka Connect 변환기를 사용하여 외부 시스템으로 데이터 스트리밍

Apache Kafka Connect와 함께 서비스 레지스트리를 사용하여 Kafka와 외부 시스템 간에 데이터를 스트리밍할 수 있습니다. Kafka Connect를 사용하면 다양한 시스템에 대한 커넥터를 정의하여 Kafka 기반 시스템으로 대량의 데이터를 이동할 수 있습니다.

그림 1.3. 서비스 레지스트리 및 Kafka Connect 아키텍처

레지스트리 및 Kafka Connect 아키텍처

Service Registry에서는 Kafka Connect에 대한 다음 기능을 제공합니다.

  • Kafka Connect 스키마용 스토리지
  • Apache Avro 및 JSON 스키마용 Kafka Connect 컨버터
  • 스키마를 관리하기 위한 코어 레지스트리 API

Avro 및 JSON 스키마 변환기를 사용하여 Kafka Connect 스키마를 Avro 또는 JSON 스키마에 매핑할 수 있습니다. 이러한 스키마는 메시지 키와 값을 컴팩트한 Avro 바이너리 형식 또는 사람이 읽을 수 있는 JSON 형식으로 직렬화할 수 있습니다. 메시지에 스키마 정보만 포함되어 있지 않기 때문에 변환된 JSON도 덜 상세합니다.

서비스 레지스트리는 Kafka 주제에서 사용되는 Avro 및 JSON 스키마를 관리하고 추적할 수 있습니다. 스키마는 서비스 레지스트리에 저장되고 메시지 콘텐츠와 분리되므로 각 메시지에는 작은 스키마 식별자만 포함해야 합니다. Kafka와 같은 I/O 바인딩 시스템의 경우 생산자 및 소비자에게 더 많은 총 처리량을 의미합니다.

Service Registry에서 제공하는 Avro 및 JSON Schema serializers 및 deserializers (SerDes)는 이 사용 사례에서 Kafka 생산자 및 소비자가 사용합니다. 변경 이벤트를 사용하기 위해 작성하는 Kafka 소비자 애플리케이션은 Avro 또는 JSON SerDes를 사용하여 이러한 변경 이벤트를 역직렬화할 수 있습니다. 이러한 SerDes를 Kafka 기반 시스템에 설치하고 Kafka Connect와 함께 사용하거나 Debezium 및 Camel Kafka Connector와 같은 Kafka Connect 기반 시스템과 함께 사용할 수 있습니다.

1.8. 서비스 레지스트리 데모 예

서비스 레지스트리는 다양한 사용 사례 시나리오에서 서비스 레지스트리를 사용하는 방법을 보여주는 오픈 소스 예제 애플리케이션을 제공합니다. 예를 들어 Kafka serializer 및 deserializer (SerDes) Java 클래스에서 사용하는 스키마를 저장하는 것이 포함됩니다. 이러한 클래스는 Kafka 메시지 페이로드를 직렬화, 역직렬화 또는 검증하기 위해 작업을 생성하거나 사용할 수 있도록 서비스 레지스트리에서 스키마를 가져옵니다.

이러한 애플리케이션은 다음 예와 같은 사용 사례를 보여줍니다.

  • Apache Avro Kafka SerDes
  • Apache Avro Maven 플러그인
  • Apache Camel Quarkus 및 Kafka
  • 클라우드 이벤트
  • Confluent Kafka SerDes
  • 사용자 정의 ID 전략
  • Google Protobuf Kafka SerDes
  • JSON Schema Kafka SerDes
  • REST 클라이언트

추가 리소스

1.9. 서비스 레지스트리 사용 가능한 배포

서비스 레지스트리는 다음과 같은 배포 옵션을 제공합니다.

표 1.2. Service Registry Operator 및 이미지
콘텐츠 배포위치릴리스 카테고리

Service Registry Operator

OperatorsOperatorHub아래의 OpenShift 웹 콘솔

정식 출시일 (GA)

Service Registry Operator의 컨테이너 이미지

Red Hat Ecosystem Catalog

정식 출시일 (GA)

AMQ Streams에서 Kafka 스토리지의 컨테이너 이미지

Red Hat Ecosystem Catalog

정식 출시일 (GA)

PostgreSQL의 데이터베이스 스토리지의 컨테이너 이미지

Red Hat Ecosystem Catalog

정식 출시일 (GA)

표 1.3. 서비스 레지스트리 zip 다운로드
콘텐츠 배포위치릴리스 카테고리

설치에 대한 사용자 정의 리소스 정의 예

Red Hat 소프트웨어 다운로드

정식 출시일 (GA)

Service Registry v1에서 v2로의 마이그레이션 툴

Red Hat 소프트웨어 다운로드

정식 출시일 (GA)

Maven 리포지터리

Red Hat 소프트웨어 다운로드

정식 출시일 (GA)

소스 코드

Red Hat 소프트웨어 다운로드

정식 출시일 (GA)

Kafka Connect 변환기

Red Hat 소프트웨어 다운로드

정식 출시일 (GA)

참고

Red Hat Integration 서브스크립션이 있어야 사용 가능한 서비스 레지스트리 배포에 액세스하려면 Red Hat 고객 포털에 로그인해야 합니다.

2장. 서비스 레지스트리 콘텐츠 규칙

이 장에서는 서비스 레지스트리 콘텐츠를 관리하는 데 사용되는 선택적 규칙을 소개하고 사용 가능한 규칙 구성에 대한 세부 정보를 제공합니다.

2.1. 규칙을 사용하여 서비스 레지스트리 콘텐츠 관리

서비스 레지스트리에 추가된 아티팩트 컨텐츠의 진화를 제어하기 위해 선택적 규칙을 구성할 수 있습니다. 구성된 모든 글로벌 규칙 또는 아티팩트별 규칙은 새 아티팩트 버전을 서비스 레지스트리에 업로드하기 전에 전달해야 합니다. 구성된 아티팩트별 규칙은 구성된 글로벌 규칙을 재정의합니다.

이러한 규칙의 목표는 잘못된 콘텐츠가 서비스 레지스트리에 추가되지 않도록 하는 것입니다. 예를 들어 다음과 같은 이유로 콘텐츠가 유효하지 않을 수 있습니다.

  • 지정된 아티팩트 유형의 잘못된 구문(예: AVRO 또는 PROTOBUF )
  • 유효한 구문이지만 의미 체계는 사양을 위반합니다.
  • 호환되지 않는 경우 새 콘텐츠에 현재 아티팩트 버전을 기준으로 변경 사항이 손상되는 경우입니다.
  • 아티팩트 참조 무결성(예: 중복 또는 존재하지 않는 아티팩트 참조 매핑).

Service Registry 웹 콘솔, REST API 명령 또는 Java 클라이언트 애플리케이션을 사용하여 선택적 콘텐츠 규칙을 활성화할 수 있습니다.

2.1.1. 규칙이 적용되는 경우

규칙은 Service Registry에 콘텐츠가 추가된 경우에만 적용됩니다. 여기에는 다음 REST 작업이 포함됩니다.

  • 아티팩트 추가
  • 아티팩트 업데이트
  • 아티팩트 버전 추가

규칙을 위반하는 경우 서비스 레지스트리는 HTTP 오류를 반환합니다. 응답 본문에는 위반된 규칙과 무엇이 잘못되었는지 보여주는 메시지가 포함됩니다.

2.1.2. 규칙 우선순위 순서

아티팩트별 및 글로벌 규칙의 우선순위 순서는 다음과 같습니다.

  • 아티팩트별 규칙을 활성화하고 동등한 글로벌 규칙이 활성화된 경우 아티팩트 규칙은 글로벌 규칙을 재정의합니다.
  • 아티팩트별 규칙을 비활성화하고 동등한 글로벌 규칙이 활성화된 경우 글로벌 규칙이 적용됩니다.
  • 아티팩트별 규칙을 비활성화하고 동등한 글로벌 규칙이 비활성화되면 모든 아티팩트에 대해 규칙이 비활성화됩니다.
  • 아티팩트 수준에서 규칙 값을 NONE 으로 설정하면 활성화된 글로벌 규칙을 덮어씁니다. 이 경우 NONE 의 아티팩트 규칙 값은 이 아티팩트에 대해 우선하지만 활성화된 글로벌 규칙은 아티팩트 수준에서 규칙이 비활성화된 다른 아티팩트에 계속 적용됩니다.

2.1.3. 규칙 작동 방식

각 규칙에는 이름 및 구성 정보가 있습니다. 서비스 레지스트리는 각 아티팩트 및 글로벌 규칙 목록을 유지 관리합니다. 목록의 각 규칙은 규칙 구현에 대한 이름과 구성으로 구성됩니다.

규칙은 현재 아티팩트 버전의 콘텐츠(있는 경우) 및 추가되는 아티팩트의 새 버전과 함께 제공됩니다. 규칙 구현은 아티팩트가 규칙을 전달하는지 여부에 따라 true 또는 false를 반환합니다. 그렇지 않은 경우 서비스 레지스트리는 HTTP 오류 응답에서 이유를 보고합니다. 일부 규칙은 이전 버전의 콘텐츠를 사용하지 않을 수 있습니다. 예를 들어 호환성 규칙은 이전 버전을 사용하지만 구문 또는 의미 체계 유효성 규칙은 그렇지 않습니다.

추가 리소스

자세한 내용은 10장. 서비스 레지스트리 콘텐츠 규칙 참조 에서 참조하십시오.

2.1.4. 콘텐츠 규칙 구성

관리자는 Service Registry 글로벌 규칙 및 아티팩트별 규칙을 구성할 수 있습니다. 개발자는 아티팩트별 규칙만 구성할 수 있습니다.

서비스 레지스트리는 특정 아티팩트에 대해 구성된 규칙을 적용합니다. 해당 수준에서 규칙이 구성되지 않은 경우 서비스 레지스트리는 전역적으로 구성된 규칙을 적용합니다. 글로벌 규칙이 구성되지 않은 경우 규칙이 적용되지 않습니다.

아티팩트 규칙 구성

서비스 레지스트리 웹 콘솔 또는 REST API를 사용하여 아티팩트 규칙을 구성할 수 있습니다. 자세한 내용은 다음을 참조하십시오.

글로벌 규칙 구성

관리자는 여러 가지 방법으로 글로벌 규칙을 구성할 수 있습니다.

  • REST API에서 admin/rules 작업 사용
  • 서비스 레지스트리 웹 콘솔 사용
  • 서비스 레지스트리 애플리케이션 속성을 사용하여 기본 글로벌 규칙 설정

기본 글로벌 규칙 구성

관리자는 글로벌 규칙을 활성화하거나 비활성화하도록 애플리케이션 수준에서 서비스 레지스트리를 구성할 수 있습니다. 다음 애플리케이션 속성 형식을 사용하여 설치 후 구성 없이 설치 시 기본 글로벌 규칙을 구성할 수 있습니다.

registry.rules.global.<ruleName>

현재 다음과 같은 규칙 이름이 지원됩니다.

  • 호환성
  • validity
  • 무결성

애플리케이션 속성의 값은 구성 중인 규칙과 관련된 유효한 구성 옵션이어야 합니다.

참고

이러한 애플리케이션 속성을 Java 시스템 속성으로 구성하거나 Quarkus application.properties 파일에 포함할 수 있습니다. 자세한 내용은 Quarkus 설명서 를 참조하십시오.

3장. 웹 콘솔을 사용하여 서비스 레지스트리 콘텐츠 관리

Service Registry 웹 콘솔을 사용하여 Service Registry에 저장된 스키마 및 API 아티팩트를 관리할 수 있습니다. 여기에는 서비스 레지스트리 콘텐츠 업로드 및 검색, 컨텐츠에 대한 선택적 규칙 구성, 클라이언트 sdk 코드 생성 등이 포함됩니다.

3.1. 서비스 레지스트리 웹 콘솔을 사용하여 아티팩트 보기

서비스 레지스트리 웹 콘솔을 사용하여 서비스 레지스트리에 저장된 스키마 및 API 아티팩트를 검색할 수 있습니다. 이 섹션에서는 서비스 레지스트리 아티팩트, 그룹, 버전 및 아티팩트 규칙을 확인하는 간단한 예를 보여줍니다.

사전 요구 사항

  • 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
  • Service Registry 웹 콘솔에 로그인되어 있습니다.

    http://MY_REGISTRY_URL/ui

  • 웹 콘솔, 명령줄, Maven 플러그인 또는 Java 클라이언트 애플리케이션을 사용하여 아티팩트가 서비스 레지스트리에 추가되었습니다.

절차

  1. Artifacts 탭에서 서비스 레지스트리에 저장된 아티팩트 목록을 찾아보거나 검색 문자열을 입력하여 아티팩트를 찾습니다. 이름, 그룹, 레이블 또는 글로벌 ID와 같은 특정 기준으로 검색할 목록에서 선택할 수 있습니다.

    그림 3.1. Service Registry 웹 콘솔의 아티팩트

    레지스트리 웹 콘솔의 아티팩트
  2. 아티팩트를 클릭하여 다음 세부 정보를 확인합니다.

    • 개요: 아티팩트 이름, 아티팩트 ID, 글로벌 ID, 콘텐츠 ID, 라벨, 속성 등과 같은 아티팩트 버전 메타데이터를 표시합니다. 아티팩트 콘텐츠에 대해 구성할 수 있는 유효성 및 호환성에 대한 규칙도 표시합니다.
    • documentation(OpenAPI 및 AsyncAPI만 해당): 자동으로 생성된 REST API 문서를 표시합니다.
    • Content: 전체 아티팩트 콘텐츠의 읽기 전용 보기를 표시합니다. JSON 콘텐츠의 경우 JSON 또는 YAML 을 클릭하여 기본 형식을 표시할 수 있습니다.
    • references: 이 아티팩트에서 참조하는 모든 아티팩트의 읽기 전용 보기를 표시합니다. 이 아티팩트를 참조하는 아티팩트 보기를 클릭할 수도 있습니다.
  3. 이 아티팩트의 추가 버전이 추가된 경우 페이지 헤더의 버전 목록에서 해당 버전을 선택할 수 있습니다.
  4. 아티팩트 콘텐츠를 로컬 파일(예: my-openapi.json 또는 my-protobuf-schema.proto )에 저장하려면 페이지 끝에 있는 다운로드를 클릭합니다.

3.2. 서비스 레지스트리 웹 콘솔을 사용하여 아티팩트 추가

서비스 레지스트리 웹 콘솔을 사용하여 서비스 레지스트리에 스키마 및 API 아티팩트를 업로드할 수 있습니다. 이 섹션에서는 서비스 레지스트리 아티팩트를 업로드하고 새 아티팩트 버전을 추가하는 간단한 예를 보여줍니다.

사전 요구 사항

  • 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
  • Service Registry 웹 콘솔에 로그인되어 있습니다.

    http://MY_REGISTRY_URL/ui

절차

  1. Artifacts 탭에서 아티팩트 업로드 를 클릭하고 다음 세부 정보를 지정합니다.

    • Group & ID: 기본 빈 설정을 사용하여 아티팩트 ID를 자동으로 생성하고 기본 아티팩트 그룹에 아티팩트를 추가합니다. 또는 선택적 아티팩트 그룹 이름 또는 ID를 입력할 수 있습니다.
    • type : 기본 Auto-Detect 설정을 사용하여 아티팩트 유형을 자동으로 감지하거나 목록에서 아티팩트 유형을 선택합니다(예: Avro Schema 또는 OpenAPI ). 자동으로 감지할 수 없는 Kafka Connect Schema 아티팩트 유형을 수동으로 선택해야 합니다.
    • artifact: 다음 옵션 중 하나를 사용하여 아티팩트 위치를 지정합니다.

      • 파일에서 찾아보기를 클릭하고 파일을 선택하거나 파일을 드래그 앤 드롭합니다. 예를 들면 my-openapi.json 또는 my-schema.proto 입니다. 또는 텍스트 상자에 파일 내용을 입력할 수 있습니다.
      • URL에서: 유효하고 액세스 가능한 URL을 입력하고 Fetch 를 클릭합니다. 예: https://petstore3.swagger.io/api/v3/openapi.json.
  2. 업로드 를 클릭하고 아티팩트 세부 정보를 확인합니다.

    • 개요: 아티팩트 이름, 아티팩트 ID, 글로벌 ID, 콘텐츠 ID, 라벨, 속성 등과 같은 아티팩트 버전 메타데이터를 표시합니다. 아티팩트 콘텐츠에 대해 구성할 수 있는 유효성 및 호환성에 대한 규칙도 표시합니다.
    • documentation(OpenAPI 및 AsyncAPI만 해당): 자동으로 생성된 REST API 문서를 표시합니다.
    • Content: 전체 아티팩트 콘텐츠의 읽기 전용 보기를 표시합니다. JSON 콘텐츠의 경우 JSON 또는 YAML 을 클릭하여 기본 형식을 표시할 수 있습니다.
    • references: 이 아티팩트에서 참조하는 모든 아티팩트의 읽기 전용 보기를 표시합니다. 이 아티팩트를 참조하는 아티팩트 보기를 클릭할 수도 있습니다. Service Registry Maven 플러그인 또는 REST API만 사용하여 아티팩트 참조를 추가할 수 있습니다.

      다음 예제에서는 OpenAPI 아티팩트 예제를 보여줍니다.

      그림 3.2. Service Registry 웹 콘솔의 아티팩트 세부 정보

      레지스트리 웹 콘솔의 아티팩트 세부 정보
  3. Overview 탭에서 연필 편집 아이콘을 클릭하여 이름 또는 설명과 같은 아티팩트 메타데이터를 편집합니다.

    검색을 위해 쉼표로 구분된 레이블 목록을 입력하거나 아티팩트와 관련된 임의의 속성의 키-값 쌍을 추가할 수도 있습니다. 속성을 추가하려면 다음 단계를 수행합니다.

    1. 속성 추가를 클릭합니다.
    2. 키 이름과 값을 입력합니다.
    3. 처음 두 단계를 반복하여 여러 속성을 추가합니다.
    4. 저장을 클릭합니다.
  4. 아티팩트 내용을 로컬 파일에 저장하려면 my-protobuf-schema.proto 또는 my-openapi.json.json 을 클릭하여 페이지 끝에 있는 다운로드를 클릭합니다.
  5. 새 아티팩트 버전을 추가하려면 페이지 헤더에서 새 버전 업로드 를 클릭하고 드래그 앤 드롭을 클릭하거나 찾아보기를 클릭하여 파일을 업로드합니다(예: my-avro-schema.json 또는 my-openapi.json ).
  6. 아티팩트를 삭제하려면 페이지 헤더에서 삭제 를 클릭합니다.

    주의

    아티팩트를 삭제하면 아티팩트 및 해당 버전이 모두 삭제되며 취소할 수 없습니다.

3.3. 서비스 레지스트리 웹 콘솔을 사용하여 콘텐츠 규칙 구성

서비스 레지스트리 웹 콘솔을 사용하여 서비스 레지스트리에 유효하지 않거나 호환되지 않는 콘텐츠가 추가되지 않도록 선택적 규칙을 구성할 수 있습니다. 구성된 모든 아티팩트별 규칙 또는 글로벌 규칙은 새 아티팩트 버전을 서비스 레지스트리에 업로드하기 전에 전달해야 합니다. 구성된 아티팩트별 규칙은 구성된 글로벌 규칙을 재정의합니다. 이 섹션에서는 글로벌 및 아티팩트별 규칙을 구성하는 간단한 예를 보여줍니다.

사전 요구 사항

  • 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
  • Service Registry 웹 콘솔에 로그인되어 있습니다.

    http://MY_REGISTRY_URL/ui

  • 웹 콘솔, 명령줄, Maven 플러그인 또는 Java 클라이언트 애플리케이션을 사용하여 아티팩트가 서비스 레지스트리에 추가되었습니다.
  • 역할 기반 권한 부여가 활성화되면 글로벌 규칙 및 아티팩트별 규칙에 대한 관리자 액세스 또는 아티팩트별 규칙에 대한 개발자 액세스 권한이 있습니다.

절차

  1. Artifacts 탭에서 서비스 레지스트리의 아티팩트 목록을 찾아보거나 검색 문자열을 입력하여 아티팩트를 찾습니다. 아티팩트 이름, 그룹, 레이블 또는 글로벌 ID와 같은 특정 기준으로 검색할 목록에서 선택할 수 있습니다.
  2. 아티팩트를 클릭하여 버전 세부 정보 및 콘텐츠 규칙을 확인합니다.
  3. Artifact-specific 규칙에서 Enable 을 클릭하여 아티팩트 콘텐츠에 대한 유효성, 호환성 또는 무결성 규칙을 구성하고 목록에서 적절한 규칙 구성을 선택합니다. 예를 들어 Validity 규칙 의 경우 Full 을 선택합니다.

    그림 3.3. Service Registry 웹 콘솔에서 아티팩트 콘텐츠 규칙

    레지스트리 웹 콘솔에서 규칙 구성
  4. 글로벌 규칙에 액세스하려면 글로벌 규칙 탭을 클릭합니다. Enable 을 클릭하여 모든 아티팩트 콘텐츠에 대한 글로벌 유효성, 호환성 또는 무결성 규칙을 구성하고 목록에서 적절한 규칙 구성을 선택합니다.
  5. 아티팩트 규칙 또는 글로벌 규칙을 비활성화하려면 규칙 옆에 있는 trash 아이콘을 클릭합니다.

3.4. Service Registry 웹 콘솔을 사용하여 OpenAPI 아티팩트용 클라이언트 SDK 생성

서비스 레지스트리 웹 콘솔을 사용하여 OpenAPI 아티팩트를 위한 클라이언트 소프트웨어 개발 키트(SDK)를 구성, 생성 및 다운로드할 수 있습니다. 그런 다음 생성된 클라이언트 SDK를 사용하여 OpenAPI를 기반으로 특정 플랫폼에 대한 클라이언트 애플리케이션을 빌드할 수 있습니다.

Service Registry는 다음 프로그래밍 언어를 위한 클라이언트 SDK를 생성합니다.

  • C#
  • Go
  • Java
  • PHP
  • Python
  • Ruby
  • Swift
  • TypeScript
참고

OpenAPI 아티팩트용 클라이언트 SDK 생성은 브라우저에서만 실행되며 API를 사용하여 자동화할 수 없습니다. Service Registry에 새 아티팩트 버전이 추가될 때마다 클라이언트 SDK를 다시 생성해야 합니다.

사전 요구 사항

  • 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
  • Service Registry 웹 콘솔에 로그인되어 있습니다.

    http://MY_REGISTRY_URL/ui

  • 웹 콘솔, 명령줄, Maven 플러그인 또는 Java 클라이언트 애플리케이션을 사용하여 OpenAPI 아티팩트가 서비스 레지스트리에 추가되었습니다.

절차

  1. Artifacts 탭에서 Service Registry에 저장된 아티팩트 목록을 찾아보거나 검색 문자열을 입력하여 특정 OpenAPI 아티팩트를 찾습니다. 이름, 그룹, 레이블 또는 글로벌 ID와 같은 기준으로 검색할 목록에서 선택할 수 있습니다.
  2. 목록에서 OpenAPI 아티팩트를 클릭하여 세부 정보를 확인합니다.
  3. 버전 메타데이터 섹션에서 클라이언트 SDK 생성 을 클릭하고 대화 상자에서 다음 설정을 구성합니다.

    • Language: 클라이언트 SDK를 생성할 프로그래밍 언어(예: Java )를 선택합니다.
    • 생성된 클라이언트 클래스 이름: 클라이언트 SDK의 클래스 이름을 입력합니다(예: MyJavaClientSDK).
    • 생성된 클라이언트 패키지 이름: 클라이언트 SDK의 패키지 이름을 입력합니다(예: io.my.example.sdk).
  4. 고급 설정 표시를 클릭하여 포함 또는 제외할 선택적 쉼표로 구분된 경로 패턴 목록을 구성합니다.

    • 경로 패턴 포함: 클라이언트 SDK를 생성할 때 포함할 특정 경로를 입력합니다(예: **/.*, **/my-path/* ). 이 필드가 비어 있으면 모든 경로가 포함됩니다.
    • 경로 패턴 제외: 클라이언트 SDK를 생성할 때 제외할 특정 경로를 입력합니다(예: **/my-other-path/* ). 이 필드가 비어 있으면 경로가 제외되지 않습니다.

      그림 3.4. 서비스 레지스트리 웹 콘솔에서 Java 클라이언트 SDK 생성

      레지스트리 웹 콘솔에서 Java 클라이언트 SDK 생성
  5. 대화 상자에서 설정을 구성한 경우 생성 및 다운로드를 클릭합니다.
  6. 대화 상자에 클라이언트 SDK의 파일 이름(예: my-client-java.zip )을 입력하고 저장을 클릭하여 다운로드합니다.

추가 리소스

3.5. 서비스 레지스트리 웹 콘솔을 사용하여 아티팩트 소유자 변경

관리자 또는 스키마 또는 API 아티팩트의 소유자로서, 서비스 레지스트리 웹 콘솔을 사용하여 아티팩트 소유자를 다른 사용자 계정으로 변경할 수 있습니다.

예를 들어, 이 기능은 소유자 또는 관리자만 아티팩트를 수정할 수 있도록 Settings (설정) 탭의 Service Registry 인스턴스에 대해 Artifact 소유자 전용 권한 부여 옵션이 설정된 경우 유용합니다. 소유자 사용자가 조직을 나가거나 소유자 계정이 삭제된 경우 소유자를 변경해야 할 수 있습니다.

참고

Artifact 소유자 전용 권한 부여 설정과 아티팩트 소유자 필드는 Service Registry 인스턴스가 배포될 때 인증이 활성화된 경우에만 표시됩니다. 자세한 내용은 OpenShift에 서비스 레지스트리 설치 및 배포를 참조하십시오.

사전 요구 사항

  • Service Registry 인스턴스가 배포되고 아티팩트가 생성됩니다.
  • 아티팩트의 현재 소유자 또는 관리자로 서비스 레지스트리 웹 콘솔에 로그인되어 있습니다.

    http://MY_REGISTRY_URL/ui

절차

  1. Artifacts 탭에서 서비스 레지스트리에 저장된 아티팩트 목록을 찾아보거나 검색 문자열을 입력하여 아티팩트를 찾습니다. 이름, 그룹, 레이블 또는 글로벌 ID와 같은 기준으로 검색할 목록에서 선택할 수 있습니다.
  2. 다시 할당할 아티팩트를 클릭합니다.
  3. Version metadata 섹션에서 Owner 필드 옆에 있는 연필 아이콘을 클릭합니다.
  4. 새 소유자 필드에서 계정 이름을 선택하거나 입력합니다.
  5. 소유자 변경을 클릭합니다.

3.6. 웹 콘솔을 사용하여 서비스 레지스트리 인스턴스 설정 구성

관리자는 서비스 레지스트리 웹 콘솔을 사용하여 런타임에 서비스 레지스트리 인스턴스에 대한 동적 설정을 구성할 수 있습니다. 인증, 권한 부여 및 API 호환성과 같은 기능의 구성 옵션을 관리할 수 있습니다.

참고

인증 및 권한 부여 설정은 Service Registry 인스턴스가 배포되었을 때 인증이 이미 활성화된 경우에만 웹 콘솔에 표시됩니다. 자세한 내용은 OpenShift에 서비스 레지스트리 설치 및 배포를 참조하십시오.

사전 요구 사항

  • Service Registry 인스턴스가 이미 배포되어 있습니다.
  • 관리자 액세스 권한이 있는 서비스 레지스트리 웹 콘솔에 로그인되어 있습니다.

    http://MY_REGISTRY_URL/ui

절차

  1. 서비스 레지스트리 웹 콘솔에서 설정 탭을 클릭합니다.
  2. 이 Service Registry 인스턴스에 구성할 설정을 선택합니다.

    표 3.1. 인증 설정
    설정설명

    HTTP 기본 인증

    인증이 이미 활성화된 경우에만 표시됩니다. Service Registry 사용자는 OAuth 외에도 HTTP 기본 인증을 사용하여 인증할 수 있습니다. 기본적으로 선택되지 않습니다.

    표 3.2. 권한 부여 설정
    설정설명

    익명 읽기 액세스

    인증이 이미 선택된 경우에만 표시됩니다. 선택한 경우 서비스 레지스트리는 인증 정보 없이 익명 사용자의 요청에 대한 읽기 전용 액세스 권한을 부여합니다. 이 설정은 이 인스턴스를 사용하여 스키마 또는 API를 외부에 게시하려는 경우에 유용합니다. 기본적으로 선택되지 않습니다.

    아티팩트 소유자 전용 권한 부여

    인증이 이미 활성화된 경우에만 표시됩니다. 선택하면 아티팩트를 생성한 사용자만 해당 아티팩트를 수정할 수 있습니다. 기본적으로 선택되지 않습니다.

    아티팩트 그룹 소유자 전용 권한 부여

    인증이 이미 활성화되어 있고 Artifact 소유자 전용 인증이 선택된 경우에만 표시됩니다. 선택하면 아티팩트 그룹을 생성한 사용자만 해당 아티팩트 그룹에 대한 쓰기 권한이 있습니다(예: 해당 그룹에서 아티팩트를 추가하거나 제거하는 등). 기본적으로 선택되지 않습니다.

    인증된 읽기 액세스

    인증이 이미 활성화된 경우에만 표시됩니다. 선택한 경우 서비스 레지스트리는 사용자 역할에 관계없이 인증된 사용자의 요청에 최소한 읽기 전용 액세스 권한을 부여합니다. 기본적으로 선택되지 않습니다.

    표 3.3. 호환성 설정
    설정설명

    레거시 ID 모드(호환 API)

    선택하면 Confluent Schema Registry compatibility API가 contentId 대신 globalId 를 아티팩트 식별자로 사용합니다. 이 설정은 v1 Core Registry API를 기반으로 레거시 서비스 레지스트리 인스턴스에서 마이그레이션할 때 유용합니다. 기본적으로 선택되지 않습니다.

    표 3.4. 웹 콘솔 설정
    설정설명

    다운로드 링크 만료

    예를 들어 인스턴스에서 아티팩트 데이터를 내보낼 때 보안상의 이유로 만료되기 전에 .zip 다운로드 파일에 생성된 링크가 활성화되는 시간(초)입니다. 기본값은 30초입니다.

    UI 읽기 전용 모드

    선택하면 서비스 레지스트리 웹 콘솔이 읽기 전용으로 설정되어 생성, 읽기, 업데이트 또는 삭제 작업이 방지됩니다. Core Registry API를 사용하여 변경한 내용은 이 설정의 영향을 받지 않습니다. 기본적으로 선택되지 않습니다.

    표 3.5. 추가 속성
    설정설명

    아티팩트 버전 삭제

    선택하는 경우 Core Registry API를 사용하여 이 인스턴스의 아티팩트 버전을 삭제할 수 있습니다. 기본적으로 선택되지 않습니다.

3.7. 서비스 레지스트리 웹 콘솔을 사용하여 데이터 내보내기 및 가져오기

관리자는 서비스 레지스트리 웹 콘솔을 사용하여 하나의 서비스 레지스트리 인스턴스에서 데이터를 내보내고 이 데이터를 다른 서비스 레지스트리 인스턴스로 가져올 수 있습니다. 이 기능을 사용하여 서로 다른 인스턴스 간에 데이터를 쉽게 마이그레이션할 수 있습니다.

다음 예제에서는 하나의 Service Registry 인스턴스에서 다른 인스턴스로 .zip 파일의 기존 데이터를 내보내고 가져오는 방법을 보여줍니다. 서비스 레지스트리 인스턴스에 포함된 모든 아티팩트 데이터는 .zip 파일로 내보냅니다.

참고

다른 서비스 레지스트리 인스턴스에서 내보낸 서비스 레지스트리 데이터만 가져올 수 있습니다.

사전 요구 사항

  • 다음과 같이 서비스 레지스트리 인스턴스가 생성되었습니다.

    • 내보낼 소스 인스턴스에는 하나 이상의 스키마 또는 API 아티팩트가 포함됩니다.
    • 가져온 대상 인스턴스는 고유 ID를 유지하기 위해 비어 있습니다.
  • 관리자 액세스 권한이 있는 서비스 레지스트리 웹 콘솔에 로그인되어 있습니다.

    http://MY_REGISTRY_URL/ui

절차

  1. 소스 서비스 레지스트리 인스턴스의 웹 콘솔에서 Artifacts 탭을 확인합니다.
  2. 아티팩트 업로드 옆에 있는 옵션 아이콘(다시 수직점)을 클릭하고 Download all artifacts (.zip file) 를 선택하여 이 서비스 레지스트리 인스턴스의 데이터를 .zip 다운로드 파일로 내보냅니다.
  3. 대상 서비스 레지스트리 인스턴스의 웹 콘솔에서 Artifacts 탭을 확인합니다.
  4. 아티팩트 업로드 옆에 있는 옵션 아이콘을 클릭하고 여러 아티팩트 업로드 를 선택합니다.
  5. 끌어서 놓거나 이전에 내보낸 .zip 다운로드 파일을 찾습니다.
  6. 업로드 를 클릭하고 데이터를 가져올 때까지 기다립니다.

4장. REST API를 사용하여 서비스 레지스트리 콘텐츠 관리

클라이언트 애플리케이션은 서비스 레지스트리 REST API 작업을 사용하여 서비스 레지스트리의 스키마 및 API 아티팩트를 관리할 수 있습니다(예: 프로덕션에 배포된 CI/CD 파이프라인). Core Registry API v2는 서비스 레지스트리에 저장된 아티팩트, 버전, 메타데이터 및 규칙에 대한 작업을 제공합니다. 자세한 내용은 Apicurio Registry REST API 설명서를 참조하십시오.

이 장에서는 코어 레지스트리 API v2를 사용하여 다음 작업을 수행하는 방법에 대한 예를 설명합니다.

4.1. 서비스 레지스트리 REST API 명령을 사용하여 스키마 및 API 아티팩트 관리

이 섹션에서는 코어 레지스트리 API v2를 사용하여 서비스 레지스트리에서 간단한 스키마 아티팩트를 추가하고 검색하는 간단한 curl 기반 예제를 보여줍니다.

사전 요구 사항

  • 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.

절차

  1. /groups/{group}/artifacts 작업을 사용하여 서비스 레지스트리에 아티팩트를 추가합니다. 다음 예제 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
    • 이 예제에서는 공유 오류의 아티팩트 ID가 있는 Apache Avro 스키마 아티팩트를 추가합니다. 고유한 아티팩트 ID를 지정하지 않으면 서비스 레지스트리가 UUID로 자동으로 생성합니다.
    • MY-REGISTRY-URL 은 서비스 레지스트리가 배포된 호스트 이름입니다. 예: my-cluster-service-registry-myproject.example.com.
    • 이 예제에서는 API 경로에서 my-group 의 그룹 ID를 지정합니다. 고유한 그룹 ID를 지정하지 않으면 API 경로에 ../groups/default 를 지정해야 합니다.
  2. 응답에 아티팩트가 추가되었는지 확인하기 위해 예상 JSON 본문이 포함되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

    {"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}
    • 아티팩트를 추가할 때 버전이 지정되지 않았으므로 기본 버전 1 이 자동으로 생성됩니다.
    • 이는 서비스 레지스트리에 두 번째 아티팩트가 추가되었으므로 글로벌 ID 및 콘텐츠 ID의 값은 2 입니다.
  3. API 경로에서 아티팩트 ID를 사용하여 서비스 레지스트리에서 아티팩트 콘텐츠를 검색합니다. 이 예에서 지정된 ID는 공유 값을 갖습니다.

    $ 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"}]}

추가 리소스

4.2. Service Registry REST API 명령을 사용하여 스키마 및 API 아티팩트 버전 관리

Core Registry API v2를 사용하여 스키마 및 API 아티팩트를 추가할 때 아티팩트 버전을 지정하지 않으면 서비스 레지스트리가 버전을 자동으로 생성합니다. 새 아티팩트를 생성할 때 기본 버전은 1 입니다.

Service Registry에서는 X-Registry-Version HTTP 요청 헤더를 문자열로 사용하여 버전을 지정할 수 있는 사용자 지정 버전 관리도 지원합니다. 사용자 정의 버전 값을 지정하면 아티팩트를 만들거나 업데이트할 때 일반적으로 할당된 기본 버전이 재정의됩니다. 그런 다음 버전이 필요한 REST API 작업을 실행할 때 이 버전 값을 사용할 수 있습니다.

이 섹션에서는 코어 레지스트리 API v2를 사용하여 서비스 레지스트리에서 사용자 정의 Apache Avro 스키마 버전을 추가하고 검색하는 간단한 curl 기반 예제를 보여줍니다. 사용자 지정 버전을 지정하여 아티팩트를 추가하거나 업데이트하거나 아티팩트 버전을 추가할 수 있습니다.

사전 요구 사항

  • 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.

절차

  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
    • 이 예제에서는 my-share- 의 아티팩트 ID와 1.1.1 버전의 Avro 스키마 아티팩트를 추가합니다. 버전을 지정하지 않으면 서비스 레지스트리가 기본 버전 1 을 자동으로 생성합니다.
    • MY-REGISTRY-URL 은 서비스 레지스트리가 배포된 호스트 이름입니다. 예: my-cluster-service-registry-myproject.example.com.
    • 이 예제에서는 API 경로에서 my-group 의 그룹 ID를 지정합니다. 고유한 그룹 ID를 지정하지 않으면 API 경로에 ../groups/default 를 지정해야 합니다.
  2. 응답에 사용자 정의 아티팩트 버전이 추가되었는지 확인하기 위해 예상 JSON 본문이 포함되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

    {"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}
    • 아티팩트를 추가할 때 1.1.1 의 사용자 지정 버전이 지정되었습니다.
    • 이는 레지스트리에 세 번째 아티팩트가 추가되었으므로 글로벌 ID 및 콘텐츠 ID의 값은 3 입니다.
  3. API 경로의 아티팩트 ID 및 버전을 사용하여 레지스트리에서 아티팩트 콘텐츠를 검색합니다. 이 예에서 지정된 ID는 my-share- expensive이며 버전은 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"}]}

추가 리소스

4.3. Service Registry REST API 명령을 사용하여 스키마 및 API 아티팩트 참조 관리

Apache Avro, Protobuf 및 JSON 스키마와 같은 서비스 레지스트리 아티팩트 유형에는 하나의 아티팩트 파일에서 다른 아티팩트로의 아티팩트 참조가 포함될 수 있습니다. 재사용 가능한 스키마 및 API 아티팩트를 정의한 다음 여러 위치에서 해당 스키마를 참조하여 유효성을 높일 수 있습니다.

이 섹션에서는 코어 레지스트리 API v2를 사용하여 서비스 레지스트리의 간단한 Avro 스키마 아티팩트에 대한 아티팩트 참조를 추가하고 검색하는 간단한 curl 기반 예제를 보여줍니다.

이 예제에서는 먼저 Citadel Id라는 스키마 아티팩트를 생성합니다.

pvId 스키마

{
    "namespace":"com.example.common",
    "name":"ItemId",
    "type":"record",
    "fields":[
        {
            "name":"id",
            "type":"int"
        }
    ]
}

그런 다음, 이 예제에서는 중첩된 10.0.0.1 Id 아티팩트에 대한 참조를 포함하는 Citadel이라는 스키마 아티팩트를 생성합니다.

중첩 itemId 스키마가 있는 항목 스키마

{
    "namespace":"com.example.common",
    "name":"Item",
    "type":"record",
    "fields":[
        {
            "name":"itemId",
            "type":"com.example.common.ItemId"
        },
    ]
}

사전 요구 사항

  • 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.

절차

  1. /groups/{group}/artifacts 작업을 사용하여 중첩된 아티팩트 참조를 생성할 item Id 스키마 아티팩트를 추가합니다.

    $ 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"}]}'
    • 이 예제에서는 items Id 의 아티팩트 ID를 사용하여 Avro 스키마 아티팩트를 추가합니다. 고유한 아티팩트 ID를 지정하지 않으면 서비스 레지스트리가 UUID로 자동으로 생성합니다.
    • MY-REGISTRY-URL 은 서비스 레지스트리가 배포된 호스트 이름입니다. 예: my-cluster-service-registry-myproject.example.com.
    • 이 예제에서는 API 경로에서 my-group 의 그룹 ID를 지정합니다. 고유한 그룹 ID를 지정하지 않으면 API 경로에 ../groups/default 를 지정해야 합니다.
  2. 응답에 아티팩트가 추가되었는지 확인하기 위해 예상 JSON 본문이 포함되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

    {"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":[]}
  3. /groups/{group}/artifacts 작업을 사용하여 item Id 스키마에 아티팩트 참조를 포함하는 item 스키마 아티팩트를 추가합니다.

    $ 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"
            }
        ]
    }'
    • 아티팩트 참조의 경우 application/json 콘텐츠 유형을 확장하는 application/create.extended+json 의 사용자 정의 콘텐츠 유형을 지정해야 합니다.
  4. 응답에 아티팩트가 참조로 생성되었는지 확인하기 위해 예상 JSON 본문이 포함되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

    {"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"}] }
  5. 참조를 포함하는 아티팩트의 글로벌 ID를 지정하여 서비스 레지스트리에서 아티팩트 참조를 검색합니다. 이 예에서 지정된 글로벌 ID는 2 입니다.

    $ curl -H "Authorization: Bearer $ACCESS_TOKEN" MY-REGISTRY-URL/apis/registry/v2/ids/globalIds/2/references
  6. 응답에 이 아티팩트 참조에 필요한 JSON 본문이 포함되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

    [{"groupId":"my-group","artifactId":"ItemId","version":"1","name":"com.example.common.ItemId"}]

추가 리소스

4.4. Service Registry REST API 명령을 사용하여 레지스트리 데이터 내보내기 및 가져오기

관리자는 Core Registry API v2를 사용하여 하나의 서비스 레지스트리 인스턴스에서 데이터를 내보내 다른 서비스 레지스트리 인스턴스로 가져올 수 있으므로 서로 다른 인스턴스 간에 데이터를 마이그레이션할 수 있습니다.

이 섹션에서는 Core Registry API v2를 사용하여 하나의 서비스 레지스트리 인스턴스에서 다른 서비스로 .zip 형식으로 기존 데이터를 내보내고 가져오는 간단한 curl 기반 예제를 보여줍니다. 서비스 레지스트리 인스턴스에 포함된 모든 아티팩트 데이터는 .zip 파일로 내보냅니다.

참고

다른 서비스 레지스트리 인스턴스에서 내보낸 서비스 레지스트리 데이터만 가져올 수 있습니다.

사전 요구 사항

  • 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
  • 서비스 레지스트리 인스턴스가 생성되었습니다.

    • 데이터를 내보내려는 소스 인스턴스에는 하나 이상의 스키마 또는 API 아티팩트가 포함됩니다.
    • 고유 ID를 유지하기 위해 데이터를 가져오려는 대상 인스턴스는 비어 있습니다.

절차

  1. 기존 소스 서비스 레지스트리 인스턴스에서 서비스 레지스트리 데이터를 내보냅니다.

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

    MY-REGISTRY-URL 은 소스 서비스 레지스트리가 배포된 호스트 이름입니다. 예: my-cluster-source-registry-myproject.example.com.

  2. 레지스트리 데이터를 대상 서비스 레지스트리 인스턴스로 가져옵니다.

    $ 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

    MY-REGISTRY-URL 은 대상 서비스 레지스트리가 배포된 호스트 이름입니다. 예: my-cluster-target-registry-myproject.example.com.

추가 리소스

5장. Maven 플러그인을 사용하여 서비스 레지스트리 콘텐츠 관리

클라이언트 애플리케이션을 개발할 때 Service Registry Maven 플러그인을 사용하여 서비스 레지스트리에 저장된 스키마 및 API 아티팩트를 관리할 수 있습니다.

사전 요구 사항

  • 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
  • Apache Maven이 사용자 환경에 설치 및 구성되어 있습니다.

5.1. Maven 플러그인을 사용하여 스키마 및 API 아티팩트 추가

Maven 플러그인의 가장 일반적인 사용 사례는 클라이언트 애플리케이션 빌드 중 아티팩트를 추가하는 것입니다. register 실행 목표를 사용하여 이를 수행할 수 있습니다.

사전 요구 사항

  • 클라이언트 애플리케이션에 대한 Maven 프로젝트를 생성했습니다. 자세한 내용은 Apache Maven 설명서 를 참조하십시오.

절차

  1. apicurio-registry-maven-plugin 을 사용하여 아티팩트를 등록하도록 Maven pom.xml 파일을 업데이트합니다. 다음 예제에서는 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
                <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>
    1
    스키마 아티팩트를 서비스 레지스트리에 업로드하는 실행 대상으로 register 를 지정합니다.
    2
    ../apis/registry/v2 끝점을 사용하여 서비스 레지스트리 URL을 지정합니다.
    3
    인증이 필요한 경우 인증 서버 및 클라이언트 자격 증명을 지정할 수 있습니다.
    4
    서비스 레지스트리 아티팩트 그룹 ID를 지정합니다. 고유한 그룹 ID를 사용하지 않으려면 기본 그룹을 지정할 수 있습니다.
    5
    지정된 그룹 ID, 아티팩트 ID 및 위치를 사용하여 여러 아티팩트를 등록할 수 있습니다.
  2. 예를 들어 mvn package 명령을 사용하여 Maven 프로젝트를 빌드합니다.

추가 리소스

5.2. Maven 플러그인을 사용하여 스키마 및 API 아티팩트 다운로드

Maven 플러그인을 사용하여 서비스 레지스트리에서 아티팩트를 다운로드할 수 있습니다. 이는 예를 들어 등록된 스키마에서 코드를 생성할 때 유용합니다.

사전 요구 사항

  • 클라이언트 애플리케이션에 대한 Maven 프로젝트를 생성했습니다. 자세한 내용은 Apache Maven 설명서 를 참조하십시오.

절차

  1. apicurio-registry-maven-plugin 을 사용하여 아티팩트를 다운로드하도록 Maven pom.xml 파일을 업데이트합니다. 다음 예제에서는 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
              <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>
    1
    실행 대상으로 다운로드를 지정합니다.
    2
    ../apis/registry/v2 끝점을 사용하여 서비스 레지스트리 URL을 지정합니다.
    3
    인증이 필요한 경우 인증 서버 및 클라이언트 자격 증명을 지정할 수 있습니다.
    4
    서비스 레지스트리 아티팩트 그룹 ID를 지정합니다. 고유 그룹을 사용하지 않으려면 기본 그룹을 지정할 수 있습니다.
    5
    아티팩트 ID를 사용하여 여러 아티팩트를 지정된 디렉터리에 다운로드할 수 있습니다.
  2. 예를 들어 mvn package 명령을 사용하여 Maven 프로젝트를 빌드합니다.

추가 리소스

5.3. Maven 플러그인을 사용하여 스키마 및 API 아티팩트 테스트

실제로 변경하지 않고 아티팩트를 등록할 수 있는지 확인해야 합니다. 이 기능은 서비스 레지스트리에 규칙이 구성된 경우 유용합니다. 아티팩트 콘텐츠가 구성된 규칙을 위반하는 경우 아티팩트를 테스트하면 오류가 발생합니다.

참고

Maven 플러그인을 사용하여 아티팩트를 테스트할 때 아티팩트가 테스트를 통과하더라도 서비스 레지스트리에 콘텐츠가 추가되지 않습니다.

사전 요구 사항

  • 클라이언트 애플리케이션에 대한 Maven 프로젝트를 생성했습니다. 자세한 내용은 Apache Maven 설명서 를 참조하십시오.

절차

  1. apicurio-registry-maven-plugin 을 사용하여 아티팩트를 테스트하도록 Maven pom.xml 파일을 업데이트합니다. 다음 예제에서는 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
                <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>
    1
    스키마 아티팩트를 테스트하기 위한 실행 목표로 test-update 를 지정합니다.
    2
    ../apis/registry/v2 끝점을 사용하여 서비스 레지스트리 URL을 지정합니다.
    3
    인증이 필요한 경우 인증 서버 및 클라이언트 자격 증명을 지정할 수 있습니다.
    4
    서비스 레지스트리 아티팩트 그룹 ID를 지정합니다. 고유 그룹을 사용하지 않으려면 기본 그룹을 지정할 수 있습니다.
    5
    아티팩트 ID를 사용하여 지정된 디렉터리에서 여러 아티팩트를 테스트할 수 있습니다.
  2. 예를 들어 mvn package 명령을 사용하여 Maven 프로젝트를 빌드합니다.

추가 리소스

5.4. Service Registry Maven 플러그인을 사용하여 수동으로 아티팩트 참조 추가

Apache Avro, Google Protobuf 및 JSON 스키마와 같은 서비스 레지스트리 아티팩트 유형에는 하나의 아티팩트 파일에서 다른 아티팩트로의 아티팩트 참조가 포함될 수 있습니다. 재사용 가능한 스키마 또는 API 아티팩트를 정의한 다음 아티팩트 참조의 여러 위치에서 해당 스키마를 참조하여 유효성을 높일 수 있습니다.

이 섹션에서는 Service Registry Maven 플러그인을 사용하여 서비스 레지스트리에 저장된 간단한 Avro 스키마 아티팩트에 대한 아티팩트 참조를 수동으로 등록하는 간단한 예를 보여줍니다. 이 예에서는 다음 Exchange 스키마 아티팩트가 서비스 레지스트리에 이미 생성된 것으로 가정합니다.

교환 스키마

{
  "namespace": "com.kubetrade.schema.common",
  "type": "enum",
  "name": "Exchange",
  "symbols" : ["GEMINI"]
}

이 예제에서는 중첩된 Exchange 스키마 아티팩트에 대한 참조를 포함하는 skopeo Key 스키마 아티팩트를 생성합니다.

교환 스키마에 대한 중첩된 참조가 있는 tradeKey 스키마

{
  "namespace": "com.kubetrade.schema.trade",
  "type": "record",
  "name": "TradeKey",
  "fields": [
    {
      "name": "exchange",
      "type": "com.kubetrade.schema.common.Exchange"
    },
    {
      "name": "key",
      "type": "string"
    }
  ]
}

사전 요구 사항

  • 클라이언트 애플리케이션에 대한 Maven 프로젝트를 생성했습니다. 자세한 내용은 Apache Maven 설명서 를 참조하십시오.
  • 참조된 교환 스키마 아티팩트는 이미 서비스 레지스트리에 생성됩니다.

절차

  1. apicurio-registry-maven-plugin 을 사용하도록 Maven pom.xml 파일을 업데이트하여 Exchange 스키마에 대한 중첩된 참조가 포함된 skopeo Key 스키마를 등록합니다.

    <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
                    <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>
    1
    서비스 레지스트리에 스키마 아티팩트를 업로드하려면 register 를 실행 목표로 지정합니다.
    2
    ../apis/registry/v2 끝점을 사용하여 서비스 레지스트리 URL을 지정합니다.
    3
    인증이 필요한 경우 인증 서버 및 클라이언트 자격 증명을 지정할 수 있습니다.
    4
    서비스 레지스트리 아티팩트 그룹 ID를 지정합니다. 고유한 그룹 ID를 사용하지 않으려면 기본 그룹을 지정할 수 있습니다.
    5
    그룹 ID, 아티팩트 ID, 버전, 유형 및 위치를 사용하여 서비스 레지스트리 아티팩트 참조를 지정합니다. 이러한 방식으로 여러 아티팩트 참조를 등록할 수 있습니다.
  2. 예를 들어 mvn package 명령을 사용하여 Maven 프로젝트를 빌드합니다.

추가 리소스

5.5. Service Registry Maven 플러그인을 사용하여 자동으로 아티팩트 참조 추가

Apache Avro, Google Protobuf 및 JSON 스키마와 같은 서비스 레지스트리 아티팩트 유형에는 하나의 아티팩트 파일에서 다른 아티팩트로의 아티팩트 참조가 포함될 수 있습니다. 재사용 가능한 스키마 또는 API 아티팩트를 정의한 다음 아티팩트 참조의 여러 위치에서 해당 스키마를 참조하여 유효성을 높일 수 있습니다.

단일 아티팩트를 지정하고 동일한 디렉터리에 있는 아티팩트에 대한 모든 참조를 자동으로 감지하고 해당 참조를 자동으로 등록하도록 Service Registry Maven 플러그인을 구성할 수 있습니다.

이 섹션에서는 Maven 플러그인을 사용하여 Avro 스키마를 등록하고 아티팩트 참조를 간단한 스키마 아티팩트에 자동으로 탐지하고 등록하는 간단한 예를 보여줍니다. 이 예에서는 상위 tradeKey 아티팩트와 중첩된 교환 스키마 아티팩트가 모두 동일한 디렉터리에서 사용 가능한 것으로 가정합니다.

교환 스키마에 대한 중첩된 참조가 있는 tradeKey 스키마

{
  "namespace": "com.kubetrade.schema.trade",
  "type": "record",
  "name": "TradeKey",
  "fields": [
    {
      "name": "exchange",
      "type": "com.kubetrade.schema.common.Exchange"
    },
    {
      "name": "key",
      "type": "string"
    }
  ]
}

교환 스키마

{
  "namespace": "com.kubetrade.schema.common",
  "type": "enum",
  "name": "Exchange",
  "symbols" : ["GEMINI"]
}

사전 요구 사항

  • 클라이언트 애플리케이션에 대한 Maven 프로젝트를 생성했습니다. 자세한 내용은 Apache Maven 설명서 를 참조하십시오.
  • tradeKey 스키마 아티팩트와 중첩된 교환 스키마 아티팩트 파일은 둘 다 동일한 디렉터리에 있습니다.

절차

  1. apicurio-registry-maven-plugin 을 사용하도록 Maven pom.xml 파일을 업데이트하여 Exchange 스키마에 대한 중첩된 참조가 포함된 skopeo Key 스키마를 등록합니다.

    <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
                    <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>
                            <analyzeDirectory>true</analyzeDirectory> 6
                        </artifact>
                    </artifacts>
                </configuration>
            </execution>
        </executions>
    </plugin>
    1
    서비스 레지스트리에 스키마 아티팩트를 업로드하려면 register 를 실행 목표로 지정합니다.
    2
    ../apis/registry/v2 끝점을 사용하여 서비스 레지스트리 URL을 지정합니다.
    3
    인증이 필요한 경우 인증 서버 및 클라이언트 자격 증명을 지정할 수 있습니다.
    4
    참조가 포함된 상위 아티팩트 그룹 ID를 지정합니다. 고유한 그룹 ID를 사용하지 않으려면 기본 그룹을 지정할 수 있습니다.
    5
    상위 아티팩트 파일의 위치를 지정합니다. 참조된 모든 아티팩트도 동일한 디렉터리에 있어야 합니다.
    6
    동일한 디렉터리의 아티팩트에 대한 모든 참조를 자동으로 탐지하고 등록하려면 < analyzeDirectory > 옵션을 true로 설정합니다. 이러한 방식으로 여러 아티팩트 참조를 등록할 수 있습니다.
  2. 예를 들어 mvn package 명령을 사용하여 Maven 프로젝트를 빌드합니다.

추가 리소스

6장. Java 클라이언트를 사용하여 서비스 레지스트리 콘텐츠 관리

Service Registry Java 클라이언트 애플리케이션을 작성하고 이를 사용하여 서비스 레지스트리에 저장된 아티팩트를 관리할 수 있습니다.

6.1. Service Registry Java 클라이언트

Java 클라이언트 애플리케이션을 사용하여 서비스 레지스트리에 저장된 아티팩트를 관리할 수 있습니다. Service Registry Java 클라이언트 클래스를 사용하여 아티팩트를 생성, 읽기, 업데이트 또는 삭제할 수 있습니다. 또한 서비스 레지스트리 Java 클라이언트를 사용하여 글로벌 규칙 관리 또는 서비스 레지스트리 데이터 가져오기 및 내보내기와 같은 관리자 기능을 수행할 수 있습니다.

Apache Maven 프로젝트에 올바른 종속성을 추가하여 Service Registry Java 클라이언트에 액세스할 수 있습니다. 자세한 내용은 6.2절. “서비스 레지스트리 Java 클라이언트 애플리케이션 작성” 에서 참조하십시오.

Service Registry 클라이언트는 필요에 따라 사용자 지정할 수 있는 JDK에서 제공하는 HTTP 클라이언트를 사용하여 구현됩니다. 예를 들어 사용자 정의 헤더를 추가하거나 TLS(Transport Layer Security) 인증에 대한 구성 옵션을 활성화할 수 있습니다. 자세한 내용은 6.3절. “Service Registry Java 클라이언트 구성” 에서 참조하십시오.

6.2. 서비스 레지스트리 Java 클라이언트 애플리케이션 작성

Service Registry Java 클라이언트 클래스를 사용하여 서비스 레지스트리에 저장된 아티팩트를 관리하는 Java 클라이언트 애플리케이션을 작성할 수 있습니다.

사전 요구 사항

  • 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
  • Java 클라이언트 애플리케이션에 대한 Maven 프로젝트를 생성했습니다. 자세한 내용은 Apache Maven 을 참조하십시오.

절차

  1. Maven 프로젝트에 다음 종속성을 추가합니다.

    <dependency>
        <groupId>io.apicurio</groupId>
        <artifactId>apicurio-registry-client</artifactId>
        <version>${apicurio-registry.version}</version>
    </dependency>
  2. 다음과 같이 서비스 레지스트리 클라이언트를 생성합니다.

    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";
           RegistryClient client = RegistryClientFactory.create(registryUrl);
        }
    }
    • https://my-registry.my-domain.com 서비스 레지스트리 URL 예를 지정하면 클라이언트는 /apis/registry/v2 를 자동으로 추가합니다.
    • 서비스 레지스트리 클라이언트를 생성할 때 추가 옵션은 다음 섹션의 Java 클라이언트 구성을 참조하십시오.

클라이언트가 생성되면 클라이언트의 서비스 레지스트리 REST API에서 사용 가능한 모든 작업을 사용할 수 있습니다. 자세한 내용은 Apicurio Registry REST API 설명서를 참조하십시오.

추가 리소스

6.3. Service Registry Java 클라이언트 구성

Service Registry Java 클라이언트에는 클라이언트 팩토리에 따라 다음과 같은 구성 옵션이 포함되어 있습니다.

표 6.1. Service Registry Java 클라이언트 구성 옵션
옵션설명인수

일반 클라이언트

실행 중인 서비스 레지스트리 인스턴스와 상호 작용하는 데 사용되는 기본 REST 클라이언트입니다.

baseUrl

사용자 정의 구성이 있는 클라이언트

사용자가 제공하는 구성을 사용하는 서비스 레지스트리 클라이언트입니다.

BASEURL,Map<String Object> 구성

사용자 정의 구성 및 인증이 있는 클라이언트

사용자 정의 구성이 포함된 맵을 허용하는 서비스 레지스트리 클라이언트입니다. 예를 들어 이 명령은 사용자 지정 헤더를 호출에 추가하는 데 유용합니다. 또한 요청을 인증하기 위해 인증 서버를 제공해야 합니다.

BASEURL, Map<String Object> 구성, Auth 인증

사용자 정의 헤더 구성

사용자 정의 헤더를 구성하려면 configs 맵 키에 apicurio.registry.request.headers 접두사를 추가해야 합니다. 예를 들어, apicurio.registry.request.headers. Authorization 구성 맵 키는 Basic: YWxhZGRpbjpvvcGVuc2VzYW1 로 권한 부여 헤더를 설정합니다.

TLS 구성 옵션

다음 속성을 사용하여 서비스 레지스트리 Java 클라이언트에 대한 TLS(Transport Layer Security) 인증을 구성할 수 있습니다.

  • 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

추가 리소스

7장. Java 클라이언트의 serializers/deserializers를 사용하여 Kafka 메시지 검증

Service Registry는 Java로 작성된 Kafka 생산자 및 소비자 애플리케이션을 위한 클라이언트 직렬화기/deserializers(SerDes)를 제공합니다. Kafka 생산자 애플리케이션은 serializers를 사용하여 특정 이벤트 스키마를 준수하는 메시지를 인코딩합니다. Kafka 소비자 애플리케이션은 deserializers를 사용하여 특정 스키마 ID를 기반으로 올바른 스키마를 사용하여 메시지를 직렬화했는지 확인합니다. 이렇게 하면 스키마가 일관되게 사용되며 런타임에 데이터 오류를 방지할 수 있습니다.

이 장에서는 생산자 및 소비자 클라이언트 애플리케이션에서 Kafka 클라이언트 SerDes를 사용하는 방법을 설명합니다.

사전 요구 사항

7.1. Kafka 클라이언트 애플리케이션 및 서비스 레지스트리

서비스 레지스트리는 클라이언트 애플리케이션 구성에서 스키마 관리를 분리합니다. 클라이언트 코드에서 URL을 지정하여 Java 클라이언트 애플리케이션에서 서비스 레지스트리의 스키마를 사용하도록 설정할 수 있습니다.

서비스 레지스트리에 스키마를 저장하여 클라이언트 애플리케이션에서 참조되는 메시지를 직렬화 및 역직렬화하여 전송 및 수신하는 메시지가 해당 스키마와 호환되는지 확인할 수 있습니다. Kafka 클라이언트 애플리케이션은 런타임 시 서비스 레지스트리에서 스키마를 내보내거나 가져올 수 있습니다.

예를 들어 스키마가 진화하여 서비스 레지스트리에서 규칙을 정의하여 스키마 변경이 유효하고 애플리케이션에서 사용하는 이전 버전이 중단되지 않도록 할 수 있습니다. 서비스 레지스트리는 수정된 스키마를 이전 스키마 버전과 비교하여 호환성을 확인합니다.

서비스 레지스트리 스키마 기술

Service Registry에서는 다음과 같은 스키마 기술에 대한 스키마 레지스트리 지원을 제공합니다.

  • Avro
  • protobuf
  • JSON Schema

이러한 스키마 기술은 Service Registry에서 제공하는 Kafka 클라이언트 serializer/deserializer(SerDes) 서비스를 통해 클라이언트 애플리케이션에서 사용할 수 있습니다. 서비스 레지스트리에서 제공하는 SerDes 클래스의 완성 및 사용은 다를 수 있습니다. 다음 섹션에서는 각 스키마 유형에 대한 세부 정보를 제공합니다.

생산자 스키마 구성

생산자 클라이언트 애플리케이션은 직렬화기를 사용하여 특정 브로커 항목에 보낸 메시지를 올바른 데이터 형식으로 배치합니다.

생산자가 직렬화에 서비스 레지스트리를 사용할 수 있도록 하려면 다음을 수행합니다.

스키마를 등록한 후 Kafka 및 Service Registry를 시작할 때 스키마에 액세스하여 프로듀서에서 Kafka 브로커 주제로 전송된 메시지의 포맷을 지정할 수 있습니다. 또는 구성에 따라 생산자는 처음 사용할 때 스키마를 자동으로 등록할 수 있습니다.

스키마가 이미 존재하는 경우 서비스 레지스트리에 정의된 호환성 규칙을 기반으로 레지스트리 REST API를 사용하여 새 버전을 생성할 수 있습니다. 버전은 스키마가 진화할 때 호환성 검사에 사용됩니다. 그룹 ID, 아티팩트 ID 및 버전은 스키마를 식별하는 고유한 10.0.0.1을 나타냅니다.

소비자 스키마 구성

소비자 클라이언트 애플리케이션은 deserializer를 사용하여 특정 브로커 주제에서 올바른 데이터 형식으로 사용하는 메시지를 가져옵니다.

소비자가 deserialization에 서비스 레지스트리를 사용할 수 있도록 하려면 다음을 수행합니다.

글로벌 ID를 사용하여 스키마 검색

기본적으로 스키마는 사용 중인 메시지에 지정된 전역 ID를 사용하여 deserializer에 의해 서비스 레지스트리에서 검색됩니다. 스키마 글로벌 ID는 생산자 애플리케이션의 구성에 따라 메시지 헤더 또는 메시지 페이로드에 있을 수 있습니다.

메시지 페이로드에서 글로벌 ID를 찾을 때 데이터의 형식은 매직 바이트로 시작되어 소비자에게 신호로 사용되는, 글로벌 ID 및 메시지 데이터를 정상적으로 사용합니다. 예를 들면 다음과 같습니다.

# ...
[MAGIC_BYTE]
[GLOBAL_ID]
[MESSAGE DATA]

그런 다음 Kafka 및 Service Registry를 시작하면 스키마에 액세스하여 Kafka 브로커 주제에서 수신한 메시지를 포맷할 수 있습니다.

콘텐츠 ID를 사용하여 스키마 검색

또는 아티팩트 콘텐츠의 고유 ID인 콘텐츠 ID를 기반으로 서비스 레지스트리에서 스키마를 검색하도록 구성할 수 있습니다. 글로벌 ID는 아티팩트 버전의 고유 ID입니다.

콘텐츠 ID는 버전을 고유하게 식별하는 것이 아니라 버전 콘텐츠만 고유하게 식별합니다. 여러 버전이 정확히 동일한 콘텐츠를 공유하는 경우 해당 버전에는 다른 글로벌 ID가 있지만 동일한 콘텐츠 ID가 있습니다. Confluent Schema Registry는 기본적으로 콘텐츠 ID를 사용합니다.

7.2. 서비스 레지스트리에서 스키마를 검색하는 전략

Kafka 클라이언트 직렬화기에서는 조회 전략을 사용하여 메시지 스키마가 서비스 레지스트리에 등록된 아티팩트 ID 및 글로벌 ID를 결정합니다. 지정된 주제 및 메시지에 대해 ArtifactReferenceResolverStrategy Java 인터페이스의 다양한 구현을 사용하여 레지스트리의 아티팩트에 대한 참조를 반환할 수 있습니다.

각 전략의 클래스는 io.apicurio.registry.serde.strategy 패키지에 있습니다. Avro SerDes에 대한 특정 전략 클래스는 io.apicurio.registry.serde.avro.strategy 패키지에 있습니다. 기본 전략은 TopicIdStrategy 이며, 메시지를 수신하는 Kafka 주제와 이름이 동일한 서비스 레지스트리 아티팩트를 찾습니다.

예제

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

  • topic 매개변수는 메시지를 수신하는 Kafka 항목의 이름입니다.
  • 메시지 키가 직렬화될 때 isKey 매개변수는 true 이고, 메시지 값을 직렬화할 때 false 입니다.
  • schema 매개변수는 직렬화 또는 역직렬화된 메시지의 스키마입니다.
  • 반환된 ArtifactReference 에는 스키마가 등록된 아티팩트 ID가 포함됩니다.

사용하는 조회 전략은 스키마를 저장하는 방법과 위치에 따라 다릅니다. 예를 들어 동일한 Avro 메시지 유형의 Kafka 항목이 다른 경우 레코드 ID 를 사용하는 전략을 사용할 수 있습니다.

아티팩트 해석기 전략

아티팩트 확인자 전략은 Kafka 주제와 메시지 정보를 서비스 레지스트리의 아티팩트에 매핑하는 방법을 제공합니다. 매핑의 일반적인 규칙은 Kafka 메시지 또는 값에 대해 serializer가 사용되는지에 따라 Kafka 주제 이름과 키 또는 값을 결합하는 것입니다.

그러나 Service Registry에서 제공하는 전략을 사용하거나 io.apicurio.registry.serde.strategy.ArtifactReferenceResolverStrategy 를 구현하는 사용자 정의 Java 클래스를 생성하여 매핑에 대한 대체 규칙을 사용할 수 있습니다.

아티팩트에 대한 참조를 반환하는 전략

Service Registry는 ArtifactReferenceResolverStrategy 의 구현을 기반으로 아티팩트에 대한 참조를 반환하는 다음 전략을 제공합니다.

RecordIdStrategy
스키마의 전체 이름을 사용하는 Avro 특정 전략입니다.
TopicRecordIdStrategy
주제 이름과 스키마의 전체 이름을 사용하는 Avro 특정 전략.
TopicIdStrategy
주제 이름 및 또는 접미사를 사용하는 기본 전략입니다.
SimpleTopicIdStrategy
주제 이름만 사용하는 간단한 전략입니다.
DefaultSchemaResolver 인터페이스

기본 스키마 확인자는 아티팩트 확인자 전략에서 제공하는 아티팩트 참조에 등록된 특정 버전의 스키마를 찾아서 식별합니다. 모든 아티팩트 버전에는 해당 아티팩트의 콘텐츠를 검색하는 데 사용할 수 있는 전역적으로 고유한 단일 식별자가 있습니다. 이 글로벌 ID는 모든 Kafka 메시지에 포함되어 역직렬러가 Apicurio Registry에서 스키마를 올바르게 가져올 수 있습니다.

기본 스키마 확인자는 기존 아티팩트 버전을 조회하거나 사용하는 전략에 따라 찾을 수 없는 경우 등록할 수 있습니다. io.apicurio.registry.resolver.SchemaResolver 를 구현하는 사용자 정의 Java 클래스를 생성하여 자체 전략을 제공할 수도 있습니다. 그러나 DefaultSchemaResolver 를 사용하고 대신 구성 속성을 지정하는 것이 좋습니다.

레지스트리 조회 옵션 구성

DefaultSchemaResolver 를 사용하는 경우 애플리케이션 속성을 사용하여 동작을 구성할 수 있습니다. 다음 표에서는 일반적으로 사용되는 몇 가지 예를 보여줍니다.

표 7.1. 서비스 레지스트리 조회 구성 옵션
속성유형설명Default

apicurio.registry.find-latest

boolean

serializer가 해당 그룹 ID 및 아티팩트 ID의 레지스트리에서 최신 아티팩트를 찾는지 여부를 지정합니다.

false

apicurio.registry.use-id

문자열

직렬화기에서 Kafka에 지정된 ID를 쓰고 deserialize자에게 이 ID를 사용하여 스키마를 찾도록 지시합니다.

없음

apicurio.registry.auto-register

boolean

serializer가 레지스트리에 아티팩트를 만들 것인지 여부를 지정합니다. JSON Schema serializer에서 이 기능을 지원하지 않습니다.

false

apicurio.registry.check-period-ms

문자열

전역 ID를 밀리초 단위로 캐시하는 기간을 지정합니다. 구성되지 않은 경우 전역 ID를 매번 가져옵니다.

없음

7.3. 서비스 레지스트리에 스키마 등록

Apache Avro와 같은 적절한 형식으로 스키마를 정의한 후에는 서비스 레지스트리에 스키마를 추가할 수 있습니다.

다음 방법을 사용하여 스키마를 추가할 수 있습니다.

  • 서비스 레지스트리 웹 콘솔
  • 서비스 레지스트리 REST API를 사용하는 curl 명령
  • 서비스 레지스트리와 함께 제공되는 Maven 플러그인
  • 클라이언트 코드에 스키마 구성이 추가됨

클라이언트 애플리케이션은 스키마를 등록하기 전까지 서비스 레지스트리를 사용할 수 없습니다.

서비스 레지스트리 웹 콘솔

Service Registry가 설치되면 ui 끝점에서 웹 콘솔에 연결할 수 있습니다.

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
  1. 간단한 Avro 스키마 아티팩트.
  2. 서비스 레지스트리를 노출하는 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>
  1. 스키마 아티팩트를 레지스트리에 업로드하는 실행 대상으로 register 를 지정합니다.
  2. ../apis/registry/v2 끝점을 사용하여 서비스 레지스트리 URL을 지정합니다.
  3. 서비스 레지스트리 아티팩트 그룹 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();
    }
}
  1. 두 개 이상의 URL 노드에 대해 속성을 등록할 수 있습니다.
  2. 아티팩트 ID에 따라 스키마가 이미 존재하는지 확인합니다.

7.4. Kafka 소비자 클라이언트의 스키마 사용

다음 절차에서는 서비스 레지스트리의 스키마를 사용하도록 Java로 작성된 Kafka 소비자 클라이언트를 구성하는 방법을 설명합니다.

사전 요구 사항

  • Service Registry가 설치됨
  • 스키마가 서비스 레지스트리에 등록됨

절차

  1. 서비스 레지스트리의 URL로 클라이언트를 구성합니다. 예를 들면 다음과 같습니다.

    String registryUrl = "https://registry.example.com/apis/registry/v2";
    Properties props = new Properties();
    props.putIfAbsent(SerdeConfig.REGISTRY_URL, registryUrl);
  2. Service Registry deserializer를 사용하여 클라이언트를 구성합니다. 예를 들면 다음과 같습니다.

    // 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
    • 1. Service Registry에서 제공하는 deserializer입니다.
    • 2. deserialization은 Apache Avro JSON 형식입니다.

7.5. Kafka 생산자 클라이언트에서 스키마 사용

다음 절차에서는 서비스 레지스트리의 스키마를 사용하도록 Java로 작성된 Kafka 생산자 클라이언트를 구성하는 방법을 설명합니다.

사전 요구 사항

  • Service Registry가 설치됨
  • 스키마가 서비스 레지스트리에 등록됨

절차

  1. 서비스 레지스트리의 URL로 클라이언트를 구성합니다. 예를 들면 다음과 같습니다.

    String registryUrl = "https://registry.example.com/apis/registry/v2";
    Properties props = new Properties();
    props.putIfAbsent(SerdeConfig.REGISTRY_URL, registryUrl);
  2. 직렬화자를 사용하여 클라이언트를 구성하고 서비스 레지스트리에서 스키마를 조회하는 전략을 구성합니다. 예를 들면 다음과 같습니다.

    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
    • 1. 서비스 레지스트리에서 제공하는 메시지 키의 serializer입니다.
    • 2. Service Registry에서 제공하는 메시지 값에 대한 serializer입니다.
    • 3. lookup 전략으로 스키마의 글로벌 ID를 찾습니다.

7.6. Kafka Streams 애플리케이션에서 스키마 사용

다음 절차에서는 서비스 레지스트리에서 Apache Avro 스키마를 사용하도록 Java로 작성된 Kafka Streams 클라이언트를 구성하는 방법을 설명합니다.

사전 요구 사항

  • Service Registry가 설치됨
  • 스키마가 서비스 레지스트리에 등록됨

절차

  1. 서비스 레지스트리 URL을 사용하여 Java 클라이언트를 생성하고 구성합니다.

    String registryUrl = "https://registry.example.com/apis/registry/v2";
    
    RegistryService client = RegistryClient.cached(registryUrl);
  2. serializer 및 deserializer를 구성합니다.

    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
    • 1. 서비스 레지스트리에서 제공하는 Avro serializer입니다.
    • 2. 서비스 레지스트리에서 제공하는 Avro deserializer입니다.
    • 3. Avro 형식으로 서비스 레지스트리 URL과 Avro 리더를 구성합니다.
  3. Kafka Streams 클라이언트를 생성합니다.

    KStream<String, LogInput> input = builder.stream(
        INPUT_TOPIC,
        Consumed.with(Serdes.String(), logSerde)
    );

8장. Java 클라이언트에서 Kafka serializers/deserializers 구성

이 장에서는 생산자 및 소비자 Java 클라이언트 애플리케이션에서 Kafka SerDes를 구성하는 방법에 대한 자세한 정보를 제공합니다.

8.1. 클라이언트 애플리케이션의 Service Registry serializer/deserializer 구성

이 섹션에 표시된 예제 상수를 사용하여 클라이언트 애플리케이션에서 특정 클라이언트 serializer/deserializer(SerDe) 서비스 및 스키마 조회 전략을 직접 구성할 수 있습니다. 또는 파일 또는 인스턴스에서 해당 서비스 레지스트리 애플리케이션 속성을 구성할 수 있습니다.

다음 섹션에서는 일반적으로 사용되는 SerDe 상수 및 구성 옵션의 예를 보여줍니다.

SerDe 서비스의 구성
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
  1. 서비스 레지스트리의 필수 URL입니다.
  2. 다른 ID 형식을 지원하고 서비스 레지스트리 SerDe 서비스와 호환되도록 ID 처리를 확장합니다. 예를 들어 기본 ID 형식을 Long 에서 Integer 로 변경하면 Confluent ID 형식이 지원됩니다.
  3. Confluent ID의 처리를 단순화합니다. true 로 설정하면 글로벌 ID 조회에 Integer 가 사용됩니다. ID_HANDLER 옵션과 함께 설정을 사용해서는 안 됩니다.

추가 리소스

SerDe 조회 전략 구성
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
...
  1. 아티팩트 확인자 전략과 Kafka SerDe 및 아티팩트 ID 간 매핑을 구현하는 Java 클래스입니다. 기본값은 주제 ID 전략입니다. 이 클래스는 serializer 클래스에서만 사용됩니다.
  2. 스키마 확인자를 구현하는 Java 클래스입니다. 기본값은 DefaultSchemaResolver 입니다. 이는 serializer 및 deserializer 클래스에서 사용됩니다.

추가 리소스

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
  1. Service Registry Kafka 변환기와 함께 사용하는 데 필요한 직렬화기입니다.
  2. Service Registry Kafka 변환기와 함께 사용하는 데 필요한 역직렬러입니다.

추가 리소스

다양한 스키마 유형의 구성

다양한 스키마 기술에 대한 SerDe 구성 방법에 대한 자세한 내용은 다음을 참조하십시오.

8.2. Service Registry serializer/deserializer 구성 속성

이 섹션에서는 Service Registry Kafka serializers/deserializers(SerDes)의 Java 구성 속성에 대한 참조 정보를 제공합니다.

SchemaResolver 인터페이스

서비스 레지스트리 SerDes는 SchemaResolver 인터페이스를 기반으로 하며 레지스트리에 대한 액세스를 추상화하고 지원되는 모든 형식의 SerDes 클래스에 동일한 조회 논리를 적용합니다.

표 8.1. SchemaResolver 인터페이스의 구성 속성
상수속성설명유형Default

SCHEMA_RESOLVER

apicurio.registry.schema-resolver

serializer 및 deserializers에서 사용합니다. SchemaResolver 를 구현하는 정규화된 Java 클래스 이름입니다.

문자열

io.apicurio.registry.resolver.DefaultSchemaResolver

참고

DefaultSchemaResolver 가 권장되며 대부분의 사용 사례에 유용한 기능을 제공합니다. 일부 고급 사용 사례의 경우 SchemaResolver 의 사용자 지정 구현을 사용할 수 있습니다.

DefaultSchemaResolver 클래스

DefaultSchemaResolver 를 사용하여 다음과 같은 기능을 구성할 수 있습니다.

  • 레지스트리 API에 액세스
  • 레지스트리에서 아티팩트 조회 방법
  • Kafka에 아티팩트 정보를 작성하고 읽는 방법
  • 역직렬러의 대체 옵션
레지스트리 API 액세스 옵션 구성

DefaultSchemaResolver 는 코어 레지스트리 API에 대한 액세스를 구성하기 위해 다음 속성을 제공합니다.

표 8.2. 레지스트리 API에 액세스하기 위한 구성 속성
상수속성설명유형Default

REGISTRY_URL

apicurio.registry.url

serializer 및 deserializers에서 사용합니다. 레지스트리 API에 액세스할 URL입니다.

문자열

없음

AUTH_SERVICE_URL

apicurio.auth.service.url

serializer 및 deserializers에서 사용합니다. 인증 서비스의 URL입니다. OAuth 클라이언트 인증 정보 흐름을 사용하여 보안 레지스트리에 액세스하는 경우 필요합니다.

문자열

없음

AUTH_TOKEN_ENDPOINT

apicurio.auth.service.token.endpoint

serializer 및 deserializers에서 사용합니다. 토큰 끝점의 URL입니다. 보안 레지스트리에 액세스하는 경우 필수 항목이며 AUTH_SERVICE_URL 은 지정되지 않습니다.

문자열

없음

AUTH_REALM

apicurio.auth.realm

serializer 및 deserializers에서 사용합니다. 인증 서비스에 액세스할 영역입니다. OAuth 클라이언트 인증 정보 흐름을 사용하여 보안 레지스트리에 액세스하는 경우 필요합니다.

문자열

없음

AUTH_CLIENT_ID

apicurio.auth.client.id

serializer 및 deserializers에서 사용합니다. 인증 서비스에 액세스하기 위한 클라이언트 ID입니다. OAuth 클라이언트 인증 정보 흐름을 사용하여 보안 레지스트리에 액세스하는 경우 필요합니다.

문자열

없음

AUTH_CLIENT_SECRET

apicurio.auth.client.secret

serializer 및 deserializers에서 사용합니다. 인증 서비스에 액세스하기 위한 클라이언트 시크릿입니다. OAuth 클라이언트 인증 정보 흐름을 사용하여 보안 레지스트리에 액세스하는 경우 필요합니다.

문자열

없음

AUTH_USERNAME

apicurio.auth.username

serializer 및 deserializers에서 사용합니다. 사용자 이름을 사용하여 레지스트리에 액세스합니다. HTTP 기본 인증을 사용하여 보안 레지스트리에 액세스하는 경우 필수 항목입니다.

문자열

없음

AUTH_PASSWORD

apicurio.auth.password

serializer 및 deserializers에서 사용합니다. 레지스트리에 액세스하기 위한 암호입니다. HTTP 기본 인증을 사용하여 보안 레지스트리에 액세스하는 경우 필수 항목입니다.

문자열

없음

레지스트리 조회 옵션 구성

DefaultSchemaResolver 는 다음 속성을 사용하여 서비스 레지스트리에서 아티팩트를 조회하는 방법을 구성합니다.

표 8.3. 레지스트리 아티팩트 조회의 구성 속성
상수속성설명유형Default

ARTIFACT_RESOLVER_STRATEGY

apicurio.registry.artifact-resolver-strategy

serialize자만 사용합니다. ArtifactReferenceResolverStrategy 를 구현하고 각 Kafka 메시지를 ArtifactReference (groupId,artifactId 및 버전)에 매핑하는 정규화된 Java 클래스 이름입니다. 예를 들어 기본 전략에서는 주제 이름을 schema artifactId 로 사용합니다.

문자열

io.apicurio.registry.serde.strategy.TopicIdStrategy

EXPLICIT_ARTIFACT_GROUP_ID

apicurio.registry.artifact.group-id

serialize자만 사용합니다. 아티팩트를 쿼리하거나 생성하는 데 사용되는 groupId 를 설정합니다. ArtifactResolverStrategy 에서 반환된 groupId 를 덮어씁니다.

문자열

없음

EXPLICIT_ARTIFACT_ID

apicurio.registry.artifact.artifact-id

serialize자만 사용합니다. 아티팩트를 쿼리하거나 생성하는 데 사용되는 artifactId 를 설정합니다. ArtifactResolverStrategy 에서 반환된 artifactId 를 덮어씁니다.

문자열

없음

EXPLICIT_ARTIFACT_VERSION

apicurio.registry.artifact.version

serialize자만 사용합니다. 아티팩트를 쿼리하거나 생성하는 데 사용되는 아티팩트 버전을 설정합니다. ArtifactResolverStrategy 에서 반환한 버전을 재정의합니다.

문자열

없음

FIND_LATEST_ARTIFACT

apicurio.registry.find-latest

serialize자만 사용합니다. serializer가 해당 그룹 ID 및 아티팩트 ID의 레지스트리에서 최신 아티팩트를 찾는지 여부를 지정합니다.

boolean

false

AUTO_REGISTER_ARTIFACT

apicurio.registry.auto-register

serialize자만 사용합니다. serializer가 레지스트리에 아티팩트를 만들 것인지 여부를 지정합니다. JSON Schema serializer는 이 기능을 지원하지 않습니다.

부울, 부울 문자열

false

AUTO_REGISTER_ARTIFACT_IF_EXISTS

apicurio.registry.auto-register.if-exists

serialize자만 사용합니다. 아티팩트가 이미 있으므로 아티팩트를 생성하는 충돌이 있을 때 클라이언트의 동작을 구성합니다. 사용 가능한 값은 FAIL,UPDATE, RETURN _OR_UPDATE 입니다.

문자열

RETURN_OR_UPDATE

CHECK_PERIOD_MS

apicurio.registry.check-period-ms

serializer 및 deserializers에서 사용합니다. 자동eviction(밀리초) 전에 아티팩트를 캐시하는 기간을 지정합니다. 0으로 설정하면 매번 아티팩트가 가져옵니다.

java.time.Duration, 음수가 아닌 숫자 또는 정수 문자열

30000

RETRY_BACKOFF_MS

apicurio.registry.retry-backoff-ms

serializer 및 deserializers에서 사용합니다. 레지스트리에서 스키마를 검색할 수 없는 경우 여러 번 재시도할 수 있습니다. 이 구성 옵션은 재시도 시도(밀리초) 간 지연을 제어합니다.

java.time.Duration, 음수가 아닌 숫자 또는 정수 문자열

300

RETRY_COUNT

apicurio.registry.retry-count

serializer 및 deserializers에서 사용합니다. 레지스트리에서 스키마를 검색할 수 없는 경우 여러 번 재시도할 수 있습니다. 이 구성 옵션은 재시도 시도 횟수를 제어합니다.

음수가 아닌 숫자 또는 정수 문자열

3

USE_ID

apicurio.registry.use-id

serializer 및 deserializers에서 사용합니다. 지정된 IdOption 을 아티팩트 식별자로 사용하도록 구성합니다. 옵션은 globalIdcontentId 입니다. 직렬화기에서 Kafka에 지정된 ID를 쓰고 deserialize자에게 이 ID를 사용하여 스키마를 찾도록 지시합니다.

문자열

globalId

Kafka에서 레지스트리 아티팩트 읽기/쓰기 구성

DefaultSchemaResolver 는 다음 속성을 사용하여 아티팩트 정보를 작성하고 Kafka에서 읽는 방법을 구성합니다.

표 8.4. Kafka에서 아티팩트 정보를 읽기/쓰기하기 위한 구성 속성
상수속성설명유형Default

ENABLE_HEADERS

apicurio.registry.headers.enabled

serializer 및 deserializers에서 사용합니다. 는 메시지 페이로드 대신 Kafka 메시지 헤더에 아티팩트 식별자를 읽고 쓰도록 구성합니다.

boolean

true

HEADERS_HANDLER

apicurio.registry.headers.handler

serializer 및 deserializers에서 사용합니다. HeadersHandler 를 구현하고 Kafka 메시지 헤더에서 아티팩트 식별자를 쓰기/읽는 완전한 Java 클래스 이름입니다.

문자열

io.apicurio.registry.serde.headers.DefaultHeadersHandler

ID_HANDLER

apicurio.registry.id-handler

serializer 및 deserializers에서 사용합니다. IdHandler 를 구현하고 메시지 페이로드에서 아티팩트 식별자를 쓰기/읽는 클래스의 정규화된 Java 클래스 이름입니다. apicurio.registry.headers.enabledfalse 로 설정된 경우에만 사용됩니다.

문자열

io.apicurio.registry.serde.DefaultIdHandler

ENABLE_CONFLUENT_ID_HANDLER

apicurio.registry.as-confluent

serializer 및 deserializers에서 사용합니다. IdHandler 의 레거시 Confluent와 호환되는 구현을 가능하게 하는 바로 가기입니다. apicurio.registry.headers.enabledfalse 로 설정된 경우에만 사용됩니다.

boolean

true

역직렬러 장애 옵션 구성

DefaultSchemaResolver 는 다음 속성을 사용하여 모든 역직렬로 대체 공급자를 구성합니다.

표 8.5. 역직렬러 장애 공급자에 대한 구성 속성
상수속성설명유형Default

FALLBACK_ARTIFACT_PROVIDER

apicurio.registry.fallback.provider

역직자만 사용합니다. deserialization에 사용된 아티팩트를 해결하기 위해 FallbackArtifactProvider 의 사용자 지정 구현을 설정합니다. FallbackArtifactProvider 는 조회가 실패하는 경우 레지스트리에서 가져올 대체 아티팩트를 구성합니다.

문자열

io.apicurio.registry.serde.fallback.DefaultFallbackArtifactProvider

DefaultFallbackArtifactProvider 는 다음 속성을 사용하여 deserializer 대체 옵션을 구성합니다.

표 8.6. 역직렬러 장애 옵션에 대한 구성 속성
상수속성설명유형Default

FALLBACK_ARTIFACT_ID

apicurio.registry.fallback.artifact-id

deserialize자만 사용합니다. deserialization에 사용되는 아티팩트를 확인하기 위한 폴백으로 사용되는 artifactId 를 설정합니다.

문자열

없음

FALLBACK_ARTIFACT_GROUP_ID

apicurio.registry.fallback.group-id

deserialize자만 사용합니다. 역직렬화에 사용되는 그룹을 확인하기 위해 폴백으로 사용되는 groupId 를 설정합니다.

문자열

없음

FALLBACK_ARTIFACT_VERSION

apicurio.registry.fallback.version

deserialize자만 사용합니다. deserialization에 사용되는 아티팩트를 해결하기 위한 폴백으로 사용되는 버전을 설정합니다.

문자열

없음

추가 리소스

  • 자세한 내용은 SerdeConfig Java 클래스 를 참조하십시오.
  • 애플리케이션 속성을 Java 시스템 속성으로 구성하거나 Quarkus application.properties 파일에 포함할 수 있습니다. 자세한 내용은 Quarkus 설명서 를 참조하십시오.

8.3. 다른 클라이언트 직렬화기/deserializer 유형을 구성하는 방법

Kafka 클라이언트 애플리케이션에서 스키마를 사용하는 경우 사용 사례에 따라 사용할 특정 스키마 유형을 선택해야 합니다. Service Registry는 Apache Avro, JSON Schema 및 Google Protobuf에 대해 SerDe Java 클래스를 제공합니다. 다음 섹션에서는 각 유형을 사용하도록 Kafka 애플리케이션을 구성하는 방법을 설명합니다.

Kafka를 사용하여 사용자 정의 serializer 및 deserializer 클래스를 구현하고 Service Registry REST Java 클라이언트를 사용하여 서비스 레지스트리 기능을 활용할 수도 있습니다.

serializers/deserializers에 대한 Kafka 애플리케이션 구성

Kafka 애플리케이션에서 서비스 레지스트리에서 제공하는 SerDe 클래스를 사용하려면 올바른 구성 속성을 설정해야 합니다. 다음의 간단한 Avro 예제에서는 Kafka 생산자 애플리케이션에서 serializer를 구성하는 방법과 Kafka 소비자 애플리케이션에서 deserialize자를 구성하는 방법을 보여줍니다.

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;
}

Kafka 소비자의 deserializer 구성 예

// 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;
}

추가 리소스

8.3.1. 서비스 레지스트리를 사용하여 Avro SerDes 구성

이 항목에서는 Apache Avro에 Kafka 클라이언트 직렬화기 및 역직렬러(SerDes) 클래스를 사용하는 방법을 설명합니다.

Service Registry에서는 Avro에 대해 다음과 같은 Kafka 클라이언트 SerDes 클래스를 제공합니다.

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

Avro serializer 구성

다음을 사용하여 Avro serializer 클래스를 구성할 수 있습니다.

  • 서비스 레지스트리 URL
  • 아티팩트 해석기 전략
  • ID 위치
  • ID 인코딩
  • Avro datum 공급자
  • Avro 인코딩

ID 위치

직렬화기에서 스키마의 고유 ID를 Kafka 메시지의 일부로 전달하여 소비자가 deserialization에 올바른 스키마를 사용할 수 있습니다. ID는 메시지 페이로드 또는 메시지 헤더에 있을 수 있습니다. 기본 위치는 메시지 페이로드입니다. 메시지 헤더에 ID를 보내려면 다음 구성 속성을 설정합니다.

props.putIfAbsent(SerdeConfig.ENABLE_HEADERS, "true")

속성 이름은 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를 긴 것으로 나타내지만, 기존의 이유로 또는 다른 레지스트리 또는 SerDe 클래스와의 호환성을 위해 ID를 보낼 때 4바이트를 사용할 수 있습니다.

Avro datum 공급자

Avro는 다양한 datum 작성자와 리더를 제공하여 데이터를 작성하고 읽을 수 있습니다. Service Registry에서는 다음 세 가지 유형을 지원합니다.

  • 일반
  • 특정
  • Reflect

Service Registry AvroDatumProvider 는 기본적으로 DefaultAvroDatumProvider 를 사용하는 유형을 추상화하는 것입니다.

다음 설정 옵션을 설정할 수 있습니다.

  • apicurio.registry.avro-datum-provider: AvroDatumProvider 구현의 정규화된 Java 클래스 이름을 지정합니다(예: io.apicurio.registry.serde.avlectAvroDatumProvider).
  • apicurio.registry.use-specific-avro-reader: DefaultAvroDatumProvider를 사용할 때 특정 유형을 사용하려면 true 로 설정

Avro 인코딩

Avro를 사용하여 데이터를 직렬화할 때 Avro 바이너리 인코딩 형식을 사용하여 데이터가 가능한 한 효율적으로 인코딩되도록 할 수 있습니다. 또한 Avro는 JSON으로 데이터 인코딩을 지원하므로 각 메시지의 페이로드를 더 쉽게 검사할 수 있습니다(예: 로깅 또는 디버깅).

JSON 또는 BINARY 값으로 apicurio.registry.avro.encoding 속성을 구성하여 Avro 인코딩을 설정할 수 있습니다. 기본값은 BINARY 입니다.

Avro deserializer 구성

serializer의 다음 구성 설정과 일치하도록 Avro deserializer 클래스를 구성해야 합니다.

  • 서비스 레지스트리 URL
  • ID 인코딩
  • Avro datum 공급자
  • Avro 인코딩

이러한 구성 옵션은 직렬화기 섹션을 참조하십시오. 속성 이름과 값은 동일합니다.

참고

deserialize자를 구성할 때는 다음 옵션이 필요하지 않습니다.

  • 아티팩트 해석기 전략
  • ID 위치

deserializer 클래스는 메시지에서 이러한 옵션에 대한 값을 결정할 수 있습니다. 직렬화기에서 메시지의 일부로 ID를 전송해야 하므로 전략이 필요하지 않습니다.

ID 위치는 메시지 페이로드의 시작 부분에 있는 매직 바이트를 확인하여 결정됩니다. 해당 바이트가 발견되면 구성된 처리기를 사용하여 메시지 페이로드에서 ID를 읽습니다. 매직 바이트를 찾을 수 없으면 메시지 헤더에서 ID를 읽습니다.

Avro SerDes 및 아티팩트 참조

Avro 메시지 및 중첩 레코드가 포함된 스키마로 작업할 때 중첩 레코드별로 새 아티팩트가 등록됩니다. 예를 들어, 다음 involves Key 스키마에는 중첩된 Exchange 스키마가 포함되어 있습니다.

TRADEKEY 스키마 중첩 Exchange 스키마

{
  "namespace": "com.kubetrade.schema.trade",
  "type": "record",
  "name": "TradeKey",
  "fields": [
    {
      "name": "exchange",
      "type": "com.kubetrade.schema.common.Exchange"
    },
    {
      "name": "key",
      "type": "string"
    }
  ]
}

교환 스키마

{
  "namespace": "com.kubetrade.schema.common",
  "type": "enum",
  "name": "Exchange",
  "symbols" : ["GEMINI"]
}

Avro SerDes와 함께 이러한 스키마를 사용하면 두 개의 아티팩트가 Service Registry에서 생성되며 하나는 tradeKey 스키마용이고 하나는 Exchange 스키마용입니다. tradeKey 스키마를 사용하는 메시지가 직렬화되거나 역직렬화될 때마다 두 스키마가 모두 검색되므로 정의를 다른 파일로 분할할 수 있습니다.

추가 리소스

8.3.2. 서비스 레지스트리를 사용하여 JSON Schema SerDes 구성

이 항목에서는 JSON 스키마에 Kafka 클라이언트 직렬화기 및 역직렬러(SerDes) 클래스를 사용하는 방법을 설명합니다.

서비스 레지스트리는 JSON 스키마에 대해 다음과 같은 Kafka 클라이언트 SerDes 클래스를 제공합니다.

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

Apache Avro와 달리 JSON Schema는 직렬화 기술이 아니며 대신 검증 기술입니다. 따라서 JSON 스키마에 대한 구성 옵션은 매우 다릅니다. 예를 들어, 데이터는 항상 JSON으로 인코딩되므로 인코딩 옵션이 없습니다.

JSON Schema serializer 구성

다음과 같이 JSON Schema serializer 클래스를 구성할 수 있습니다.

  • 서비스 레지스트리 URL
  • 아티팩트 해석기 전략
  • 스키마 검증

비표준 구성 속성은 기본적으로 활성화되어 있는 JSON 스키마 검증입니다. apicurio.registry.serde.validation-enabled"false" 로 설정하여 이를 비활성화할 수 있습니다. 예를 들면 다음과 같습니다.

props.putIfAbsent(SerdeConfig.VALIDATION_ENABLED, Boolean.FALSE)

JSON Schema deserializer 구성

다음과 같이 JSON Schema deserializer 클래스를 구성할 수 있습니다.

  • 서비스 레지스트리 URL
  • 스키마 검증
  • 데이터 역직렬화의 클래스

스키마를 로드할 수 있도록 서비스 레지스트리의 위치를 제공해야 합니다. 다른 구성은 선택 사항입니다.

참고

Deserializer 유효성 검사는 serializer가 Kafka 메시지에서 글로벌 ID를 통과하는 경우에만 작동합니다.이 ID는 serializer에서 유효성 검사를 사용할 수 있는 경우에만 발생합니다.Deserializer validation works only if the serializer passes the global ID in the Kafka message, which will only happen when validation is enabled in the serializer.

JSON Schema SerDes 및 아티팩트 참조

JSON Schema SerDes는 메시지 페이로드에서 스키마를 검색할 수 없으므로 스키마 아티팩트를 미리 등록해야 하며 아티팩트 참조도 적용합니다.

스키마의 콘텐츠에 따라 $ref 값이 URL인 경우 SerDes는 참조된 스키마를 사용하여 해당 URL을 사용하여 확인한 다음 유효성 검사는 일반적으로 작동하고, 기본 스키마에 대해 데이터를 검증하고 중첩 스키마에 대해 중첩된 값을 검증합니다. 서비스 레지스트리의 아티팩트 참조 지원도 구현되었습니다.

예를 들어 다음 growth .json 스키마는 city.json 스키마를 참조합니다.

city.json 스키마에 대한 참조가 포함된 growing.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"
   }
 }
}

city.json schema

{
 "$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
   }
 }
}

이 예에서, 주어진 영주권자는 도시가 있습니다. Service Registry에서 city.json 이라는 이름을 사용하여 도시 아티팩트에 대한 참조가 있는 영주적인 아티팩트가 생성됩니다. SerDes에서, 광주 스키마를 가져올 때, 도시 스키마는 성도 스키마에서 참조되기 때문에 가져옵니다. 데이터를 직렬화/감사할 때 참조 이름은 중첩된 스키마를 확인하는 데 사용되며, 이를 통해 기존 스키마 및 중첩된 도시 스키마에 대한 유효성을 검증할 수 있습니다.

추가 리소스

8.3.3. 서비스 레지스트리를 사용하여 Protobuf SerDes 구성

이 항목에서는 Google Protobuf에 Kafka 클라이언트 직렬화기 및 역직렬러(SerDes) 클래스를 사용하는 방법을 설명합니다.

Service Registry에서는 Protobuf에 대한 다음과 같은 Kafka 클라이언트 SerDes 클래스를 제공합니다.

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

Protobuf serializer 구성

다음과 같이 Protobuf serializer 클래스를 구성할 수 있습니다.

  • 서비스 레지스트리 URL
  • 아티팩트 해석기 전략
  • ID 위치
  • ID 인코딩
  • 스키마 검증

이러한 구성 옵션에 대한 자세한 내용은 다음 섹션을 참조하십시오.

Protobuf deserializer 구성

serializer의 다음 구성 설정과 일치하도록 Protobuf deserializer 클래스를 구성해야 합니다.

  • 서비스 레지스트리 URL
  • ID 인코딩

구성 속성 이름과 값은 serializer의 경우와 동일합니다.

참고

deserialize자를 구성할 때는 다음 옵션이 필요하지 않습니다.

  • 아티팩트 해석기 전략
  • ID 위치

deserializer 클래스는 메시지에서 이러한 옵션에 대한 값을 결정할 수 있습니다. 직렬화기에서 메시지의 일부로 ID를 전송해야 하므로 전략이 필요하지 않습니다.

ID 위치는 메시지 페이로드의 시작 부분에 있는 매직 바이트를 확인하여 결정됩니다. 해당 바이트가 발견되면 구성된 처리기를 사용하여 메시지 페이로드에서 ID를 읽습니다. 매직 바이트를 찾을 수 없으면 메시지 헤더에서 ID를 읽습니다.

참고

Protobuf deserializer는 정확한 Protobuf Message 구현으로 역직렬하지 않고 DynamicMessage 인스턴스입니다. 다른 작업을 수행하는 적절한 API는 없습니다.

protobuf SerDes 및 아티팩트 참조

가져오기 문과 함께 복잡한 Protobuf 메시지를 사용하면 가져온 Protobuf 메시지가 서비스 레지스트리에 별도의 아티팩트로 저장됩니다. 그러면 서비스 레지스트리에서 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;
}

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;
}

이 예에서는 두 개의 Protobuf 아티팩트가 TableInfo 에 저장되고 다른 하나는 Mode 용으로 Service Registry에 저장됩니다. 그러나 Mode 는 TableInfo의 일부이기 때문에 TableInfo 를 가져올 때마다 TableInfo 가 SerDes의 메시지를 검사하도록 할 때마다 ModeTableInfo 에서 참조하는 아티팩트로 반환됩니다.

추가 리소스

9장. 서비스 레지스트리 아티팩트 참조

이 장에서는 Service Registry에 저장된 지원되는 아티팩트 유형, 상태 및 메타데이터에 대한 참조 정보를 제공합니다.

추가 리소스

9.1. 서비스 레지스트리 아티팩트 유형

Service Registry에서 광범위한 스키마 및 API 아티팩트 유형을 저장하고 관리할 수 있습니다.

표 9.1. 서비스 레지스트리 아티팩트 유형
유형설명

ASYNCAPI

AsyncAPI 사양

AVRO

Apache Avro schema

GRAPHQL

GraphQL 스키마

JSON

JSON Schema

KCONNECT

Apache Kafka Connect 스키마

OPENAPI

OpenAPI 사양

PROTOBUF

Google 프로토콜 버퍼 스키마

WSDL

Web Services 정의 언어

XML

확장 가능한 태그 언어

XSD

XML 스키마 정의

9.2. 서비스 레지스트리 아티팩트 상태

서비스 레지스트리의 유효한 아티팩트 상태는 ENABLED,DISABLEDDEPRECATED 입니다.

표 9.2. 서비스 레지스트리 아티팩트 상태
상태설명

ENABLED

기본 상태, 모든 작업을 사용할 수 있습니다.

DISABLED

아티팩트 및 해당 메타데이터는 서비스 레지스트리 웹 콘솔을 사용하여 볼 수 있으며 검색할 수 있지만 클라이언트에서 해당 콘텐츠를 가져올 수 없습니다.

더 이상 사용되지 않음

아티팩트는 완전히 사용할 수 있지만 아티팩트 콘텐츠를 가져올 때마다 헤더가 REST API 응답에 추가됩니다. Service Registry Rest Client는 더 이상 사용되지 않는 콘텐츠가 표시될 때마다 경고를 기록합니다.

9.3. 서비스 레지스트리 아티팩트 메타데이터

아티팩트가 서비스 레지스트리에 추가되면 메타데이터 속성 집합이 아티팩트 콘텐츠와 함께 저장됩니다. 이 메타데이터는 설정할 수 있는 일부 속성과 함께 생성된 읽기 전용 속성 세트로 구성됩니다.

표 9.3. 서비스 레지스트리 읽기 전용 메타데이터
속성유형

contentId

integer

createdBy

string

createdOn

date

globalId

integer

groupId

string

id

string

modifiedBy

string

modifiedOn

date

참고 자료

ArtifactReference 배열

type

ArtifactType

버전

integer

표 9.4. 서비스 레지스트리 편집 가능한 메타데이터
속성유형

description

string

labels

문자열 배열

name

string

속성

map

상태

ArtifactState

아티팩트 메타데이터 업데이트

  • 서비스 레지스트리 REST API를 사용하여 메타데이터 끝점을 사용하여 편집 가능한 속성 집합을 업데이트할 수 있습니다.
  • 상태 전환 API를 사용하여 상태 속성만 편집할 수 있습니다. 예를 들어 아티팩트를 더 이상 사용되지 않거나 비활성화됨으로 표시할 수 있습니다.

10장. 서비스 레지스트리 콘텐츠 규칙 참조

이 장에서는 지원되는 콘텐츠 규칙 유형, 아티팩트 유형에 대한 지원 수준, 아티팩트별 및 글로벌 규칙의 우선순위 순서에 대한 참조 정보를 제공합니다.

추가 리소스

10.1. 서비스 레지스트리 콘텐츠 규칙 유형

VALIDITY,COMPATIBILITYINTEGRITY 규칙 유형을 지정하여 서비스 레지스트리의 콘텐츠 진화를 관리할 수 있습니다. 이러한 규칙 유형은 글로벌 규칙 및 아티팩트별 규칙에 모두 적용됩니다.

표 10.1. 서비스 레지스트리 콘텐츠 규칙 유형
유형설명

유효 기간

서비스 레지스트리에 추가하기 전에 콘텐츠를 검증합니다. 이 규칙에 대해 가능한 구성 값은 다음과 같습니다.

  • FULL: 유효성 검사는 구문과 의미 체계 둘 다입니다.
  • SYNTAX_ONLY: 검증은 구문 전용입니다.
  • NONE: 모든 검증 검사가 비활성화됩니다.

호환성

아티팩트를 업데이트할 때 호환성 수준을 적용합니다(예: 이전 버전과의 호환성을 위해 BACKWARD 선택). 새 아티팩트가 이전에 추가된 아티팩트 버전 또는 클라이언트와 호환되는지 확인합니다. 이 규칙에 대해 가능한 구성 값은 다음과 같습니다.

  • FULL: 새 아티팩트는 가장 최근에 추가된 아티팩트와 전달 및 역호환됩니다.
  • FULL_TRANSITIVE: 새 아티팩트는 이전에 추가된 모든 아티팩트와 앞으로 호환됩니다.
  • BACKWARD: 새 아티팩트를 사용하는 클라이언트는 가장 최근에 추가된 아티팩트를 사용하여 작성된 데이터를 읽을 수 있습니다.
  • BACKWARD_TRANSITIVE: 새 아티팩트를 사용하는 클라이언트는 이전에 추가된 모든 아티팩트를 사용하여 작성된 데이터를 읽을 수 있습니다.
  • FORWARD: 가장 최근에 추가된 아티팩트를 사용하는 클라이언트는 새 아티팩트를 사용하여 작성된 데이터를 읽을 수 있습니다.
  • FORWARD_TRANSITIVE: 이전에 추가된 모든 아티팩트를 사용하는 클라이언트는 새 아티팩트를 사용하여 작성된 데이터를 읽을 수 있습니다.
  • NONE: 이전 버전과 호환성 검사를 모두 사용할 수 없습니다.

무결성

아티팩트를 생성하거나 업데이트할 때 아티팩트 참조 무결성을 강제 적용합니다. 이 규칙을 활성화하고 구성하여 제공된 아티팩트 참조가 올바른지 확인합니다. 이 규칙에 대해 가능한 구성 값은 다음과 같습니다.

  • FULL: 모든 아티팩트 참조 무결성 검사가 활성화됩니다.
  • NO_DUPLICATES: 중복 아티팩트 참조가 있는지 감지합니다.
  • REFS_EXIST: 존재하지 않는 아티팩트에 대한 참조가 있는지 감지합니다.
  • ALL_REFS_MAPPED: 모든 아티팩트 참조가 매핑되었는지 확인합니다.
  • NONE: 모든 아티팩트 참조 무결성 검사가 비활성화됩니다.

10.2. 서비스 레지스트리 콘텐츠 규칙 완성도

Service Registry에서 지원하는 모든 아티팩트 유형에 대해 모든 콘텐츠 규칙이 완전히 구현되는 것은 아닙니다. 다음 표는 각 규칙 및 아티팩트 유형의 현재 완성 수준을 보여줍니다.

표 10.2. 서비스 레지스트리 콘텐츠 규칙 완성 매트릭스
아티팩트 유형유효성 규칙호환성 규칙무결성 규칙

Avro

full

full

full

protobuf

full

full

full

JSON Schema

full

full

매핑 탐지가 지원되지 않음

OpenAPI

full

없음

full

AsyncAPI

구문만 해당

없음

full

GraphQL

구문만 해당

없음

매핑 탐지가 지원되지 않음

Kafka Connect

구문만 해당

없음

매핑 탐지가 지원되지 않음

WSDL

full

없음

매핑 탐지가 지원되지 않음

XML

full

없음

매핑 탐지가 지원되지 않음

XSD

full

없음

매핑 탐지가 지원되지 않음

10.3. 서비스 레지스트리 콘텐츠 규칙 우선순위

아티팩트를 추가하거나 업데이트할 때 서비스 레지스트리는 아티팩트 콘텐츠의 유효성, 호환성 또는 무결성을 확인하는 규칙을 적용합니다. 구성된 아티팩트별 규칙은 다음 표에 표시된 대로 구성된 글로벌 규칙을 재정의합니다.

표 10.3. 서비스 레지스트리 콘텐츠 규칙 우선순위
아티팩트별 규칙글로벌 규칙이 아티팩트에 적용되는 규칙다른 아티팩트에 대해 글로벌 규칙을 사용할 수 있습니까?

enabled

enabled

Artifact-specific

제공됨

disabled

enabled

글로벌

제공됨

disabled

disabled

없음

없음

활성화됨, 없음으로 설정

enabled

없음

제공됨

disabled

활성화됨, 없음으로 설정

없음

없음

부록 A. 서브스크립션 사용

서비스 레지스트리는 소프트웨어 서브스크립션을 통해 제공됩니다. 서브스크립션을 관리하려면 Red Hat 고객 포털에서 계정에 액세스하십시오.

귀하의 계정에 액세스

  1. access.redhat.com 으로 이동합니다.
  2. 아직 계정이 없는 경우 계정을 생성합니다.
  3. 계정에 로그인합니다.

서브스크립션 활성화

  1. access.redhat.com 으로 이동합니다.
  2. 내 서브스크립션으로 이동합니다.
  3. 서브스크립션을 활성화하여 16자리 활성화 번호를 입력합니다.

ZIP 및 TAR 파일 다운로드

ZIP 또는 TAR 파일에 액세스하려면 고객 포털을 사용하여 다운로드를 위한 관련 파일을 찾습니다. RPM 패키지를 사용하는 경우에는 이 단계가 필요하지 않습니다.

  1. 브라우저를 열고 access.redhat.com/downloads 에서 Red Hat 고객 포털 제품 다운로드 페이지에 로그인합니다.
  2. 통합 및 자동화 카테고리에서 Red Hat Integration 항목을 찾습니다.
  3. 원하는 Service Registry 제품을 선택합니다. Software Download 페이지가 열립니다.
  4. 구성 요소에 대한 다운로드 링크를 클릭합니다.

2023-09-19에 최종 업데이트된 문서

법적 공지

Copyright © 2023 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은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.