서비스 레지스트리 사용자 가이드
Service Registry 2.4에서 스키마 및 API 관리
초록
머리말
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견에 감사드립니다. 피드백을 제공하려면 문서의 텍스트를 강조 표시하고 주석을 추가합니다.
사전 요구 사항
- Red Hat 고객 포털에 로그인되어 있습니다.
- Red Hat 고객 포털에서 문서는 Multi-page HTML 보기 형식으로 되어 있습니다.
절차
피드백을 제공하려면 다음 단계를 수행합니다.
문서 의 오른쪽 상단에 있는 피드백 버튼을 클릭하여 기존 피드백을 확인합니다.
참고피드백 기능은 Multi-page HTML 형식으로만 활성화됩니다.
- 피드백을 제공할 문서의 섹션을 강조 표시합니다.
강조 표시된 텍스트 근처에 표시되는 피드백 추가 팝업을 클릭합니다.
페이지 오른쪽의 피드백 섹션에 텍스트 상자가 나타납니다.A text box appears in the feedback section on the right side of the page.
텍스트 상자에 피드백을 입력하고 Submit 을 클릭합니다.
문서 문제가 생성되었습니다.
- 문제를 보려면 피드백 보기에서 문제 링크를 클릭합니다.
1장. 서비스 레지스트리 소개
이 장에서는 서비스 레지스트리 개념 및 기능을 소개하고 레지스트리에 저장된 지원되는 아티팩트 유형에 대한 세부 정보를 제공합니다.
- 1.1절. “Service Registry란 무엇인가?”
- 1.2절. “서비스 레지스트리의 스키마 및 API 아티팩트”
- 1.3절. “서비스 레지스트리 웹 콘솔을 사용하여 콘텐츠 관리”
- 1.4절. “클라이언트용 서비스 레지스트리 REST API”
- 1.5절. “서비스 레지스트리 스토리지 옵션”
- 1.6절. “스키마 및 Java 클라이언트 직렬화기/deserializers를 사용하여 Kafka 메시지 검증”
- 1.7절. “Kafka Connect 변환기를 사용하여 외부 시스템으로 데이터 스트리밍”
- 1.8절. “서비스 레지스트리 데모 예”
- 1.9절. “서비스 레지스트리 사용 가능한 배포”
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 경로에 기본
그룹을 지정합니다.
추가 리소스
- 지원되는 아티팩트 유형에 대한 자세한 내용은 9장. 서비스 레지스트리 아티팩트 참조 을 참조하십시오.
- Core Registry API에 대한 자세한 내용은 Apicurio Registry REST 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
추가 리소스
아티팩트 참조 관리에 대한 자세한 내용은 다음을 참조하십시오.
- Java 예제는 참조가 포함된 Apicurio Registry SerDes를 참조하십시오.
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에서는 레지스트리 데이터의 기본 스토리지에 대해 다음 옵션을 제공합니다.
스토리지 옵션 | 설명 |
---|---|
PostgreSQL 데이터베이스 | PostgreSQL은 프로덕션 환경에서 성능, 안정성, 데이터 관리(백업/복원 등)에 권장되는 데이터 스토리지 옵션입니다. |
AMQ Streams | Kafka 스토리지는 데이터베이스 관리 전문 지식을 사용할 수 없거나 Kafka의 스토리지가 특정 요구 사항입니다. |
추가 리소스
- 스토리지 옵션에 대한 자세한 내용은 OpenShift에 서비스 레지스트리 설치 및 배포를 참조하십시오.
1.6. 스키마 및 Java 클라이언트 직렬화기/deserializers를 사용하여 Kafka 메시지 검증
Kafka 생산자 애플리케이션은 serializers를 사용하여 특정 이벤트 스키마를 준수하는 메시지를 인코딩할 수 있습니다. 그런 다음 Kafka 소비자 애플리케이션은 deserializers를 사용하여 특정 스키마 ID를 기반으로 올바른 스키마를 사용하여 메시지를 직렬화했는지 검증할 수 있습니다.
그림 1.2. Service Registry 및 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 아키텍처

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 클라이언트
추가 리소스
- 자세한 내용은 https://github.com/Apicurio/apicurio-registry-examples에서 참조하십시오.
1.9. 서비스 레지스트리 사용 가능한 배포
서비스 레지스트리는 다음과 같은 배포 옵션을 제공합니다.
콘텐츠 배포 | 위치 | 릴리스 카테고리 |
---|---|---|
Service Registry Operator | Operators → OperatorHub아래의 OpenShift 웹 콘솔 | 정식 출시일 (GA) |
Service Registry Operator의 컨테이너 이미지 | 정식 출시일 (GA) | |
AMQ Streams에서 Kafka 스토리지의 컨테이너 이미지 | 정식 출시일 (GA) | |
PostgreSQL의 데이터베이스 스토리지의 컨테이너 이미지 | 정식 출시일 (GA) |
콘텐츠 배포 | 위치 | 릴리스 카테고리 |
---|---|---|
설치에 대한 사용자 정의 리소스 정의 예 | 정식 출시일 (GA) | |
Service Registry v1에서 v2로의 마이그레이션 툴 | 정식 출시일 (GA) | |
Maven 리포지터리 | 정식 출시일 (GA) | |
소스 코드 | 정식 출시일 (GA) | |
Kafka Connect 변환기 | 정식 출시일 (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절. “서비스 레지스트리 웹 콘솔을 사용하여 아티팩트 보기”
- 3.2절. “서비스 레지스트리 웹 콘솔을 사용하여 아티팩트 추가”
- 3.3절. “서비스 레지스트리 웹 콘솔을 사용하여 콘텐츠 규칙 구성”
- 3.4절. “Service Registry 웹 콘솔을 사용하여 OpenAPI 아티팩트용 클라이언트 SDK 생성”
- 3.5절. “서비스 레지스트리 웹 콘솔을 사용하여 아티팩트 소유자 변경”
- 3.6절. “웹 콘솔을 사용하여 서비스 레지스트리 인스턴스 설정 구성”
- 3.7절. “서비스 레지스트리 웹 콘솔을 사용하여 데이터 내보내기 및 가져오기”
3.1. 서비스 레지스트리 웹 콘솔을 사용하여 아티팩트 보기
서비스 레지스트리 웹 콘솔을 사용하여 서비스 레지스트리에 저장된 스키마 및 API 아티팩트를 검색할 수 있습니다. 이 섹션에서는 서비스 레지스트리 아티팩트, 그룹, 버전 및 아티팩트 규칙을 확인하는 간단한 예를 보여줍니다.
사전 요구 사항
- 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
Service Registry 웹 콘솔에 로그인되어 있습니다.
http://MY_REGISTRY_URL/ui
- 웹 콘솔, 명령줄, Maven 플러그인 또는 Java 클라이언트 애플리케이션을 사용하여 아티팩트가 서비스 레지스트리에 추가되었습니다.
절차
Artifacts 탭에서 서비스 레지스트리에 저장된 아티팩트 목록을 찾아보거나 검색 문자열을 입력하여 아티팩트를 찾습니다. 이름, 그룹, 레이블 또는 글로벌 ID와 같은 특정 기준으로 검색할 목록에서 선택할 수 있습니다.
그림 3.1. Service Registry 웹 콘솔의 아티팩트
아티팩트를 클릭하여 다음 세부 정보를 확인합니다.
- 개요: 아티팩트 이름, 아티팩트 ID, 글로벌 ID, 콘텐츠 ID, 라벨, 속성 등과 같은 아티팩트 버전 메타데이터를 표시합니다. 아티팩트 콘텐츠에 대해 구성할 수 있는 유효성 및 호환성에 대한 규칙도 표시합니다.
- documentation(OpenAPI 및 AsyncAPI만 해당): 자동으로 생성된 REST API 문서를 표시합니다.
- Content: 전체 아티팩트 콘텐츠의 읽기 전용 보기를 표시합니다. JSON 콘텐츠의 경우 JSON 또는 YAML 을 클릭하여 기본 형식을 표시할 수 있습니다.
- references: 이 아티팩트에서 참조하는 모든 아티팩트의 읽기 전용 보기를 표시합니다. 이 아티팩트를 참조하는 아티팩트 보기를 클릭할 수도 있습니다.
- 이 아티팩트의 추가 버전이 추가된 경우 페이지 헤더의 버전 목록에서 해당 버전을 선택할 수 있습니다.
-
아티팩트 콘텐츠를 로컬 파일(예:
my-openapi.json
또는my-protobuf-schema.proto
)에 저장하려면 페이지 끝에 있는 다운로드를 클릭합니다.
3.2. 서비스 레지스트리 웹 콘솔을 사용하여 아티팩트 추가
서비스 레지스트리 웹 콘솔을 사용하여 서비스 레지스트리에 스키마 및 API 아티팩트를 업로드할 수 있습니다. 이 섹션에서는 서비스 레지스트리 아티팩트를 업로드하고 새 아티팩트 버전을 추가하는 간단한 예를 보여줍니다.
사전 요구 사항
- 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
Service Registry 웹 콘솔에 로그인되어 있습니다.
http://MY_REGISTRY_URL/ui
절차
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
.
-
파일에서 찾아보기를 클릭하고 파일을 선택하거나 파일을 드래그 앤 드롭합니다. 예를 들면
-
Group & ID: 기본 빈 설정을 사용하여 아티팩트 ID를 자동으로 생성하고
업로드 를 클릭하고 아티팩트 세부 정보를 확인합니다.
- 개요: 아티팩트 이름, 아티팩트 ID, 글로벌 ID, 콘텐츠 ID, 라벨, 속성 등과 같은 아티팩트 버전 메타데이터를 표시합니다. 아티팩트 콘텐츠에 대해 구성할 수 있는 유효성 및 호환성에 대한 규칙도 표시합니다.
- documentation(OpenAPI 및 AsyncAPI만 해당): 자동으로 생성된 REST API 문서를 표시합니다.
- Content: 전체 아티팩트 콘텐츠의 읽기 전용 보기를 표시합니다. JSON 콘텐츠의 경우 JSON 또는 YAML 을 클릭하여 기본 형식을 표시할 수 있습니다.
references: 이 아티팩트에서 참조하는 모든 아티팩트의 읽기 전용 보기를 표시합니다. 이 아티팩트를 참조하는 아티팩트 보기를 클릭할 수도 있습니다. Service Registry Maven 플러그인 또는 REST API만 사용하여 아티팩트 참조를 추가할 수 있습니다.
다음 예제에서는 OpenAPI 아티팩트 예제를 보여줍니다.
그림 3.2. Service Registry 웹 콘솔의 아티팩트 세부 정보
Overview 탭에서 연필 편집 아이콘을 클릭하여 이름 또는 설명과 같은 아티팩트 메타데이터를 편집합니다.
검색을 위해 쉼표로 구분된 레이블 목록을 입력하거나 아티팩트와 관련된 임의의 속성의 키-값 쌍을 추가할 수도 있습니다. 속성을 추가하려면 다음 단계를 수행합니다.
- 속성 추가를 클릭합니다.
- 키 이름과 값을 입력합니다.
- 처음 두 단계를 반복하여 여러 속성을 추가합니다.
- 저장을 클릭합니다.
-
아티팩트 내용을 로컬 파일에 저장하려면
my-protobuf-schema.proto
또는my-openapi.json
.json 을 클릭하여 페이지 끝에 있는 다운로드를 클릭합니다. -
새 아티팩트 버전을 추가하려면 페이지 헤더에서 새 버전 업로드 를 클릭하고 드래그 앤 드롭을 클릭하거나 찾아보기를 클릭하여 파일을 업로드합니다(예:
my-avro-schema.json
또는my-openapi.json
). 아티팩트를 삭제하려면 페이지 헤더에서 삭제 를 클릭합니다.
주의아티팩트를 삭제하면 아티팩트 및 해당 버전이 모두 삭제되며 취소할 수 없습니다.
3.3. 서비스 레지스트리 웹 콘솔을 사용하여 콘텐츠 규칙 구성
서비스 레지스트리 웹 콘솔을 사용하여 서비스 레지스트리에 유효하지 않거나 호환되지 않는 콘텐츠가 추가되지 않도록 선택적 규칙을 구성할 수 있습니다. 구성된 모든 아티팩트별 규칙 또는 글로벌 규칙은 새 아티팩트 버전을 서비스 레지스트리에 업로드하기 전에 전달해야 합니다. 구성된 아티팩트별 규칙은 구성된 글로벌 규칙을 재정의합니다. 이 섹션에서는 글로벌 및 아티팩트별 규칙을 구성하는 간단한 예를 보여줍니다.
사전 요구 사항
- 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
Service Registry 웹 콘솔에 로그인되어 있습니다.
http://MY_REGISTRY_URL/ui
- 웹 콘솔, 명령줄, Maven 플러그인 또는 Java 클라이언트 애플리케이션을 사용하여 아티팩트가 서비스 레지스트리에 추가되었습니다.
- 역할 기반 권한 부여가 활성화되면 글로벌 규칙 및 아티팩트별 규칙에 대한 관리자 액세스 또는 아티팩트별 규칙에 대한 개발자 액세스 권한이 있습니다.
절차
- Artifacts 탭에서 서비스 레지스트리의 아티팩트 목록을 찾아보거나 검색 문자열을 입력하여 아티팩트를 찾습니다. 아티팩트 이름, 그룹, 레이블 또는 글로벌 ID와 같은 특정 기준으로 검색할 목록에서 선택할 수 있습니다.
- 아티팩트를 클릭하여 버전 세부 정보 및 콘텐츠 규칙을 확인합니다.
Artifact-specific 규칙에서 Enable 을 클릭하여 아티팩트 콘텐츠에 대한 유효성, 호환성 또는 무결성 규칙을 구성하고 목록에서 적절한 규칙 구성을 선택합니다. 예를 들어 Validity 규칙 의 경우 Full 을 선택합니다.
그림 3.3. Service Registry 웹 콘솔에서 아티팩트 콘텐츠 규칙
- 글로벌 규칙에 액세스하려면 글로벌 규칙 탭을 클릭합니다. Enable 을 클릭하여 모든 아티팩트 콘텐츠에 대한 글로벌 유효성, 호환성 또는 무결성 규칙을 구성하고 목록에서 적절한 규칙 구성을 선택합니다.
- 아티팩트 규칙 또는 글로벌 규칙을 비활성화하려면 규칙 옆에 있는 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 아티팩트가 서비스 레지스트리에 추가되었습니다.
절차
- Artifacts 탭에서 Service Registry에 저장된 아티팩트 목록을 찾아보거나 검색 문자열을 입력하여 특정 OpenAPI 아티팩트를 찾습니다. 이름, 그룹, 레이블 또는 글로벌 ID와 같은 기준으로 검색할 목록에서 선택할 수 있습니다.
- 목록에서 OpenAPI 아티팩트를 클릭하여 세부 정보를 확인합니다.
버전 메타데이터 섹션에서 클라이언트 SDK 생성 을 클릭하고 대화 상자에서 다음 설정을 구성합니다.
- Language: 클라이언트 SDK를 생성할 프로그래밍 언어(예: Java )를 선택합니다.
-
생성된 클라이언트 클래스 이름: 클라이언트 SDK의 클래스 이름을 입력합니다(예:
MyJavaClientSDK).
-
생성된 클라이언트 패키지 이름: 클라이언트 SDK의 패키지 이름을 입력합니다(예:
io.my.example.sdk
).
고급 설정 표시를 클릭하여 포함 또는 제외할 선택적 쉼표로 구분된 경로 패턴 목록을 구성합니다.
-
경로 패턴 포함: 클라이언트 SDK를 생성할 때 포함할 특정 경로를 입력합니다(예:
**/.*, **/my-path/*
). 이 필드가 비어 있으면 모든 경로가 포함됩니다. 경로 패턴 제외: 클라이언트 SDK를 생성할 때 제외할 특정 경로를 입력합니다(예:
**/my-other-path/*
). 이 필드가 비어 있으면 경로가 제외되지 않습니다.그림 3.4. 서비스 레지스트리 웹 콘솔에서 Java 클라이언트 SDK 생성
-
경로 패턴 포함: 클라이언트 SDK를 생성할 때 포함할 특정 경로를 입력합니다(예:
- 대화 상자에서 설정을 구성한 경우 생성 및 다운로드를 클릭합니다.
-
대화 상자에 클라이언트 SDK의 파일 이름(예:
my-client-java.zip
)을 입력하고 저장을 클릭하여 다운로드합니다.
추가 리소스
- 서비스 레지스트리는 Microsoft의 Kiota를 사용하여 클라이언트 SDK를 생성합니다. 자세한 내용은 GitHub의 Kiota 프로젝트를 참조하십시오.
- 생성된 SDK를 사용하여 클라이언트 애플리케이션을 빌드하는 방법에 대한 예제는 Kiota API 클라이언트 퀵 스타트 를 참조하십시오.
3.5. 서비스 레지스트리 웹 콘솔을 사용하여 아티팩트 소유자 변경
관리자 또는 스키마 또는 API 아티팩트의 소유자로서, 서비스 레지스트리 웹 콘솔을 사용하여 아티팩트 소유자를 다른 사용자 계정으로 변경할 수 있습니다.
예를 들어, 이 기능은 소유자 또는 관리자만 아티팩트를 수정할 수 있도록 Settings (설정) 탭의 Service Registry 인스턴스에 대해 Artifact 소유자 전용 권한 부여 옵션이 설정된 경우 유용합니다. 소유자 사용자가 조직을 나가거나 소유자 계정이 삭제된 경우 소유자를 변경해야 할 수 있습니다.
Artifact 소유자 전용 권한 부여 설정과 아티팩트 소유자 필드는 Service Registry 인스턴스가 배포될 때 인증이 활성화된 경우에만 표시됩니다. 자세한 내용은 OpenShift에 서비스 레지스트리 설치 및 배포를 참조하십시오.
사전 요구 사항
- Service Registry 인스턴스가 배포되고 아티팩트가 생성됩니다.
아티팩트의 현재 소유자 또는 관리자로 서비스 레지스트리 웹 콘솔에 로그인되어 있습니다.
http://MY_REGISTRY_URL/ui
절차
- Artifacts 탭에서 서비스 레지스트리에 저장된 아티팩트 목록을 찾아보거나 검색 문자열을 입력하여 아티팩트를 찾습니다. 이름, 그룹, 레이블 또는 글로벌 ID와 같은 기준으로 검색할 목록에서 선택할 수 있습니다.
- 다시 할당할 아티팩트를 클릭합니다.
- Version metadata 섹션에서 Owner 필드 옆에 있는 연필 아이콘을 클릭합니다.
- 새 소유자 필드에서 계정 이름을 선택하거나 입력합니다.
- 소유자 변경을 클릭합니다.
추가 리소스
3.6. 웹 콘솔을 사용하여 서비스 레지스트리 인스턴스 설정 구성
관리자는 서비스 레지스트리 웹 콘솔을 사용하여 런타임에 서비스 레지스트리 인스턴스에 대한 동적 설정을 구성할 수 있습니다. 인증, 권한 부여 및 API 호환성과 같은 기능의 구성 옵션을 관리할 수 있습니다.
인증 및 권한 부여 설정은 Service Registry 인스턴스가 배포되었을 때 인증이 이미 활성화된 경우에만 웹 콘솔에 표시됩니다. 자세한 내용은 OpenShift에 서비스 레지스트리 설치 및 배포를 참조하십시오.
사전 요구 사항
- Service Registry 인스턴스가 이미 배포되어 있습니다.
관리자 액세스 권한이 있는 서비스 레지스트리 웹 콘솔에 로그인되어 있습니다.
http://MY_REGISTRY_URL/ui
절차
- 서비스 레지스트리 웹 콘솔에서 설정 탭을 클릭합니다.
이 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
절차
- 소스 서비스 레지스트리 인스턴스의 웹 콘솔에서 Artifacts 탭을 확인합니다.
-
아티팩트 업로드 옆에 있는 옵션 아이콘(다시 수직점)을 클릭하고 Download all artifacts (.zip file) 를 선택하여 이 서비스 레지스트리 인스턴스의 데이터를
.zip
다운로드 파일로 내보냅니다. - 대상 서비스 레지스트리 인스턴스의 웹 콘솔에서 Artifacts 탭을 확인합니다.
- 아티팩트 업로드 옆에 있는 옵션 아이콘을 클릭하고 여러 아티팩트 업로드 를 선택합니다.
-
끌어서 놓거나 이전에 내보낸
.zip
다운로드 파일을 찾습니다. - 업로드 를 클릭하고 데이터를 가져올 때까지 기다립니다.
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 기반 예제를 보여줍니다.
사전 요구 사항
- 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
절차
/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
를 지정해야 합니다.
-
이 예제에서는
응답에 아티팩트가 추가되었는지 확인하기 위해 예상 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
입니다.
-
아티팩트를 추가할 때 버전이 지정되지 않았으므로 기본 버전
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 기반 예제를 보여줍니다. 사용자 지정 버전을 지정하여 아티팩트를 추가하거나 업데이트하거나 아티팩트 버전을 추가할 수 있습니다.
사전 요구 사항
- 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
절차
/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
를 지정해야 합니다.
-
이 예제에서는
응답에 사용자 정의 아티팩트 버전이 추가되었는지 확인하기 위해 예상 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
입니다.
-
아티팩트를 추가할 때
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" }, ] }
사전 요구 사항
- 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
절차
/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"}]}'
-
이 예제에서는 items
Id
의 아티팩트 ID를 사용하여 Avro 스키마 아티팩트를 추가합니다. 고유한 아티팩트 ID를 지정하지 않으면 서비스 레지스트리가 UUID로 자동으로 생성합니다. -
MY-REGISTRY-URL
은 서비스 레지스트리가 배포된 호스트 이름입니다. 예:my-cluster-service-registry-myproject.example.com
. -
이 예제에서는 API 경로에서
my-group
의 그룹 ID를 지정합니다. 고유한 그룹 ID를 지정하지 않으면 API 경로에../groups/default
를 지정해야 합니다.
-
이 예제에서는 items
응답에 아티팩트가 추가되었는지 확인하기 위해 예상 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":[]}
/groups/{group}/artifacts
작업을 사용하여 itemId
스키마에 아티팩트 참조를 포함하는 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
의 사용자 정의 콘텐츠 유형을 지정해야 합니다.
-
아티팩트 참조의 경우
응답에 아티팩트가 참조로 생성되었는지 확인하기 위해 예상 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"}] }
참조를 포함하는 아티팩트의 글로벌 ID를 지정하여 서비스 레지스트리에서 아티팩트 참조를 검색합니다. 이 예에서 지정된 글로벌 ID는
2
입니다.$ curl -H "Authorization: Bearer $ACCESS_TOKEN" MY-REGISTRY-URL/apis/registry/v2/ids/globalIds/2/references
응답에 이 아티팩트 참조에 필요한 JSON 본문이 포함되어 있는지 확인합니다. 예를 들면 다음과 같습니다.
[{"groupId":"my-group","artifactId":"ItemId","version":"1","name":"com.example.common.ItemId"}]
추가 리소스
- 자세한 내용은 Apicurio Registry REST API 설명서를 참조하십시오.
- 아티팩트 참조에 대한 자세한 내용은 8장. Java 클라이언트에서 Kafka serializers/deserializers 구성 에서 각 아티팩트 유형을 구성하는 섹션을 참조하십시오.
4.4. Service Registry REST API 명령을 사용하여 레지스트리 데이터 내보내기 및 가져오기
관리자는 Core Registry API v2를 사용하여 하나의 서비스 레지스트리 인스턴스에서 데이터를 내보내 다른 서비스 레지스트리 인스턴스로 가져올 수 있으므로 서로 다른 인스턴스 간에 데이터를 마이그레이션할 수 있습니다.
이 섹션에서는 Core Registry API v2를 사용하여 하나의 서비스 레지스트리 인스턴스에서 다른 서비스로 .zip
형식으로 기존 데이터를 내보내고 가져오는 간단한 curl 기반 예제를 보여줍니다. 서비스 레지스트리 인스턴스에 포함된 모든 아티팩트 데이터는 .zip
파일로 내보냅니다.
다른 서비스 레지스트리 인스턴스에서 내보낸 서비스 레지스트리 데이터만 가져올 수 있습니다.
사전 요구 사항
- 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
서비스 레지스트리 인스턴스가 생성되었습니다.
- 데이터를 내보내려는 소스 인스턴스에는 하나 이상의 스키마 또는 API 아티팩트가 포함됩니다.
- 고유 ID를 유지하기 위해 데이터를 가져오려는 대상 인스턴스는 비어 있습니다.
절차
기존 소스 서비스 레지스트리 인스턴스에서 서비스 레지스트리 데이터를 내보냅니다.
$ 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
.레지스트리 데이터를 대상 서비스 레지스트리 인스턴스로 가져옵니다.
$ 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
.
추가 리소스
-
자세한 내용은 Apicurio Registry REST API 설명서의 관리 끝점을 참조하십시오.
- Service Registry 버전 1.x에서 2.x로 마이그레이션하기 위한 내보내기 툴에 대한 자세한 내용은 1.x 버전에 대한 Apicurio Registry export 유틸리티를 참조하십시오.
5장. Maven 플러그인을 사용하여 서비스 레지스트리 콘텐츠 관리
클라이언트 애플리케이션을 개발할 때 Service Registry Maven 플러그인을 사용하여 서비스 레지스트리에 저장된 스키마 및 API 아티팩트를 관리할 수 있습니다.
사전 요구 사항
- 사용자 환경에 서비스 레지스트리가 설치되어 실행 중입니다.
- Apache Maven이 사용자 환경에 설치 및 구성되어 있습니다.
5.1. Maven 플러그인을 사용하여 스키마 및 API 아티팩트 추가
Maven 플러그인의 가장 일반적인 사용 사례는 클라이언트 애플리케이션 빌드 중 아티팩트를 추가하는 것입니다. register
실행 목표를 사용하여 이를 수행할 수 있습니다.
사전 요구 사항
- 클라이언트 애플리케이션에 대한 Maven 프로젝트를 생성했습니다. 자세한 내용은 Apache Maven 설명서 를 참조하십시오.
절차
apicurio-registry-maven-plugin
을 사용하여 아티팩트를 등록하도록 Mavenpom.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>
-
예를 들어
mvn package
명령을 사용하여 Maven 프로젝트를 빌드합니다.
추가 리소스
- Apache Maven 사용에 대한 자세한 내용은 Apache Maven 설명서를 참조하십시오.
- Service Registry Maven 플러그인을 사용하는 오픈 소스 예제는 Apicurio Registry 데모 예제 를 참조하십시오.
5.2. Maven 플러그인을 사용하여 스키마 및 API 아티팩트 다운로드
Maven 플러그인을 사용하여 서비스 레지스트리에서 아티팩트를 다운로드할 수 있습니다. 이는 예를 들어 등록된 스키마에서 코드를 생성할 때 유용합니다.
사전 요구 사항
- 클라이언트 애플리케이션에 대한 Maven 프로젝트를 생성했습니다. 자세한 내용은 Apache Maven 설명서 를 참조하십시오.
절차
apicurio-registry-maven-plugin
을 사용하여 아티팩트를 다운로드하도록 Mavenpom.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>
-
예를 들어
mvn package
명령을 사용하여 Maven 프로젝트를 빌드합니다.
추가 리소스
- Apache Maven 사용에 대한 자세한 내용은 Apache Maven 설명서를 참조하십시오.
- Service Registry Maven 플러그인을 사용하는 오픈 소스 예제는 Apicurio Registry 데모 예제 를 참조하십시오.
5.3. Maven 플러그인을 사용하여 스키마 및 API 아티팩트 테스트
실제로 변경하지 않고 아티팩트를 등록할 수 있는지 확인해야 합니다. 이 기능은 서비스 레지스트리에 규칙이 구성된 경우 유용합니다. 아티팩트 콘텐츠가 구성된 규칙을 위반하는 경우 아티팩트를 테스트하면 오류가 발생합니다.
Maven 플러그인을 사용하여 아티팩트를 테스트할 때 아티팩트가 테스트를 통과하더라도 서비스 레지스트리에 콘텐츠가 추가되지 않습니다.
사전 요구 사항
- 클라이언트 애플리케이션에 대한 Maven 프로젝트를 생성했습니다. 자세한 내용은 Apache Maven 설명서 를 참조하십시오.
절차
apicurio-registry-maven-plugin
을 사용하여 아티팩트를 테스트하도록 Mavenpom.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>
-
예를 들어
mvn package
명령을 사용하여 Maven 프로젝트를 빌드합니다.
추가 리소스
- Apache Maven 사용에 대한 자세한 내용은 Apache Maven 설명서를 참조하십시오.
- Service Registry Maven 플러그인을 사용하는 오픈 소스 예제는 Apicurio Registry 데모 예제 를 참조하십시오.
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 설명서 를 참조하십시오.
-
참조된
교환
스키마 아티팩트는 이미 서비스 레지스트리에 생성됩니다.
절차
apicurio-registry-maven-plugin
을 사용하도록 Mavenpom.xml
파일을 업데이트하여Exchange
스키마에 대한 중첩된 참조가 포함된 skopeoKey
스키마를 등록합니다.<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, 버전, 유형 및 위치를 사용하여 서비스 레지스트리 아티팩트 참조를 지정합니다. 이러한 방식으로 여러 아티팩트 참조를 등록할 수 있습니다.
-
예를 들어
mvn package
명령을 사용하여 Maven 프로젝트를 빌드합니다.
추가 리소스
- Apache Maven 사용에 대한 자세한 내용은 Apache Maven 설명서를 참조하십시오.
- Service Registry Maven 플러그인을 사용하여 아티팩트 참조를 수동으로 등록하는 오픈 소스 예제는 avro-maven-with-references 데모 예제 를 참조하십시오.
- 아티팩트 참조에 대한 자세한 내용은 8장. Java 클라이언트에서 Kafka serializers/deserializers 구성 에서 각 아티팩트 유형을 구성하는 섹션을 참조하십시오.
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
스키마 아티팩트와 중첩된교환
스키마 아티팩트 파일은 둘 다 동일한 디렉터리에 있습니다.
절차
apicurio-registry-maven-plugin
을 사용하도록 Mavenpom.xml
파일을 업데이트하여Exchange
스키마에 대한 중첩된 참조가 포함된 skopeoKey
스키마를 등록합니다.<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로 설정합니다. 이러한 방식으로 여러 아티팩트 참조를 등록할 수 있습니다.
-
예를 들어
mvn package
명령을 사용하여 Maven 프로젝트를 빌드합니다.
추가 리소스
- Apache Maven 사용에 대한 자세한 내용은 Apache Maven 설명서를 참조하십시오.
- Service Registry Maven 플러그인을 사용하여 여러 아티팩트 참조를 자동으로 등록하는 오픈 소스 예제는 avro-maven-with-references-auto 데모 예를 참조하십시오.
- 아티팩트 참조에 대한 자세한 내용은 8장. Java 클라이언트에서 Kafka serializers/deserializers 구성 에서 각 아티팩트 유형을 구성하는 섹션을 참조하십시오.
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 을 참조하십시오.
절차
Maven 프로젝트에 다음 종속성을 추가합니다.
<dependency> <groupId>io.apicurio</groupId> <artifactId>apicurio-registry-client</artifactId> <version>${apicurio-registry.version}</version> </dependency>
다음과 같이 서비스 레지스트리 클라이언트를 생성합니다.
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 설명서를 참조하십시오.
추가 리소스
- 서비스 레지스트리 클라이언트를 사용하고 사용자 지정하는 방법에 대한 오픈 소스 예제는 Apicurio Registry REST 클라이언트 데모를 참조하십시오.
- 생산자 및 소비자 애플리케이션에서 Service Registry Kafka 클라이언트 serializers/deserializers(SerDes)를 사용하는 방법에 대한 자세한 내용은 7장. Java 클라이언트의 serializers/deserializers를 사용하여 Kafka 메시지 검증 을 참조하십시오.
6.3. Service Registry Java 클라이언트 구성
Service Registry Java 클라이언트에는 클라이언트 팩토리에 따라 다음과 같은 구성 옵션이 포함되어 있습니다.
옵션 | 설명 | 인수 |
---|---|---|
일반 클라이언트 | 실행 중인 서비스 레지스트리 인스턴스와 상호 작용하는 데 사용되는 기본 REST 클라이언트입니다. |
|
사용자 정의 구성이 있는 클라이언트 | 사용자가 제공하는 구성을 사용하는 서비스 레지스트리 클라이언트입니다. |
|
사용자 정의 구성 및 인증이 있는 클라이언트 | 사용자 정의 구성이 포함된 맵을 허용하는 서비스 레지스트리 클라이언트입니다. 예를 들어 이 명령은 사용자 지정 헤더를 호출에 추가하는 데 유용합니다. 또한 요청을 인증하기 위해 인증 서버를 제공해야 합니다. |
|
사용자 정의 헤더 구성
사용자 정의 헤더를 구성하려면 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
추가 리소스
- 서비스 레지스트리 Kafka 클라이언트의 인증을 구성하는 방법에 대한 자세한 내용은 7장. Java 클라이언트의 serializers/deserializers를 사용하여 Kafka 메시지 검증 을 참조하십시오.
7장. Java 클라이언트의 serializers/deserializers를 사용하여 Kafka 메시지 검증
Service Registry는 Java로 작성된 Kafka 생산자 및 소비자 애플리케이션을 위한 클라이언트 직렬화기/deserializers(SerDes)를 제공합니다. Kafka 생산자 애플리케이션은 serializers를 사용하여 특정 이벤트 스키마를 준수하는 메시지를 인코딩합니다. Kafka 소비자 애플리케이션은 deserializers를 사용하여 특정 스키마 ID를 기반으로 올바른 스키마를 사용하여 메시지를 직렬화했는지 확인합니다. 이렇게 하면 스키마가 일관되게 사용되며 런타임에 데이터 오류를 방지할 수 있습니다.
이 장에서는 생산자 및 소비자 클라이언트 애플리케이션에서 Kafka 클라이언트 SerDes를 사용하는 방법을 설명합니다.
사전 요구 사항
- 1장. 서비스 레지스트리 소개 을 읽었습니다.
- 서비스 레지스트리가 설치되어 있습니다.
Kafka 생산자 및 소비자 클라이언트 애플리케이션을 생성했습니다.
Kafka 클라이언트 애플리케이션에 대한 자세한 내용은 OpenShift에서 AMQ 스트림 배포 및 업그레이드 를 참조하십시오.
7.1. Kafka 클라이언트 애플리케이션 및 서비스 레지스트리
서비스 레지스트리는 클라이언트 애플리케이션 구성에서 스키마 관리를 분리합니다. 클라이언트 코드에서 URL을 지정하여 Java 클라이언트 애플리케이션에서 서비스 레지스트리의 스키마를 사용하도록 설정할 수 있습니다.
서비스 레지스트리에 스키마를 저장하여 클라이언트 애플리케이션에서 참조되는 메시지를 직렬화 및 역직렬화하여 전송 및 수신하는 메시지가 해당 스키마와 호환되는지 확인할 수 있습니다. Kafka 클라이언트 애플리케이션은 런타임 시 서비스 레지스트리에서 스키마를 내보내거나 가져올 수 있습니다.
예를 들어 스키마가 진화하여 서비스 레지스트리에서 규칙을 정의하여 스키마 변경이 유효하고 애플리케이션에서 사용하는 이전 버전이 중단되지 않도록 할 수 있습니다. 서비스 레지스트리는 수정된 스키마를 이전 스키마 버전과 비교하여 호환성을 확인합니다.
서비스 레지스트리 스키마 기술
Service Registry에서는 다음과 같은 스키마 기술에 대한 스키마 레지스트리 지원을 제공합니다.
- Avro
- protobuf
- JSON Schema
이러한 스키마 기술은 Service Registry에서 제공하는 Kafka 클라이언트 serializer/deserializer(SerDes) 서비스를 통해 클라이언트 애플리케이션에서 사용할 수 있습니다. 서비스 레지스트리에서 제공하는 SerDes 클래스의 완성 및 사용은 다를 수 있습니다. 다음 섹션에서는 각 스키마 유형에 대한 세부 정보를 제공합니다.
생산자 스키마 구성
생산자 클라이언트 애플리케이션은 직렬화기를 사용하여 특정 브로커 항목에 보낸 메시지를 올바른 데이터 형식으로 배치합니다.
생산자가 직렬화에 서비스 레지스트리를 사용할 수 있도록 하려면 다음을 수행합니다.
- 서비스 레지스트리(아직 존재하지 않는 경우)에 스키마를 정의하고 등록 합니다.
다음을 사용하여 프로듀서 클라이언트 코드를 구성합니다.
- 서비스 레지스트리의 URL
- 메시지와 함께 사용할 Service Registry serializer
- Kafka 메시지를 서비스 레지스트리의 스키마 아티팩트에 매핑하는 전략
- 서비스 레지스트리에서 직렬화에 사용되는 스키마를 검색하거나 등록하는 전략
스키마를 등록한 후 Kafka 및 Service Registry를 시작할 때 스키마에 액세스하여 프로듀서에서 Kafka 브로커 주제로 전송된 메시지의 포맷을 지정할 수 있습니다. 또는 구성에 따라 생산자는 처음 사용할 때 스키마를 자동으로 등록할 수 있습니다.
스키마가 이미 존재하는 경우 서비스 레지스트리에 정의된 호환성 규칙을 기반으로 레지스트리 REST API를 사용하여 새 버전을 생성할 수 있습니다. 버전은 스키마가 진화할 때 호환성 검사에 사용됩니다. 그룹 ID, 아티팩트 ID 및 버전은 스키마를 식별하는 고유한 10.0.0.1을 나타냅니다.
소비자 스키마 구성
소비자 클라이언트 애플리케이션은 deserializer를 사용하여 특정 브로커 주제에서 올바른 데이터 형식으로 사용하는 메시지를 가져옵니다.
소비자가 deserialization에 서비스 레지스트리를 사용할 수 있도록 하려면 다음을 수행합니다.
- 서비스 레지스트리를 사용하여 스키마를 정의하고 등록합니다 (아직 존재하지 않는 경우)
- 서비스 레지스트리의 URL
- 메시지와 함께 사용할 서비스 레지스트리 역직자
- 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
를 사용하는 경우 애플리케이션 속성을 사용하여 동작을 구성할 수 있습니다. 다음 표에서는 일반적으로 사용되는 몇 가지 예를 보여줍니다.
속성 | 유형 | 설명 | Default |
---|---|---|---|
|
| serializer가 해당 그룹 ID 및 아티팩트 ID의 레지스트리에서 최신 아티팩트를 찾는지 여부를 지정합니다. |
|
|
| 직렬화기에서 Kafka에 지정된 ID를 쓰고 deserialize자에게 이 ID를 사용하여 스키마를 찾도록 지시합니다. | 없음 |
|
| serializer가 레지스트리에 아티팩트를 만들 것인지 여부를 지정합니다. JSON Schema serializer에서 이 기능을 지원하지 않습니다. |
|
|
| 전역 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
- 간단한 Avro 스키마 아티팩트.
- 서비스 레지스트리를 노출하는 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>
-
스키마 아티팩트를 레지스트리에 업로드하는 실행 대상으로
register
를 지정합니다. -
../apis/registry/v2
끝점을 사용하여 서비스 레지스트리 URL을 지정합니다. - 서비스 레지스트리 아티팩트 그룹 ID를 지정합니다.
- 지정된 그룹 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(); } }
- 두 개 이상의 URL 노드에 대해 속성을 등록할 수 있습니다.
- 아티팩트 ID에 따라 스키마가 이미 존재하는지 확인합니다.
7.4. Kafka 소비자 클라이언트의 스키마 사용
다음 절차에서는 서비스 레지스트리의 스키마를 사용하도록 Java로 작성된 Kafka 소비자 클라이언트를 구성하는 방법을 설명합니다.
사전 요구 사항
- Service Registry가 설치됨
- 스키마가 서비스 레지스트리에 등록됨
절차
서비스 레지스트리의 URL로 클라이언트를 구성합니다. 예를 들면 다음과 같습니다.
String registryUrl = "https://registry.example.com/apis/registry/v2"; Properties props = new Properties(); props.putIfAbsent(SerdeConfig.REGISTRY_URL, registryUrl);
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가 설치됨
- 스키마가 서비스 레지스트리에 등록됨
절차
서비스 레지스트리의 URL로 클라이언트를 구성합니다. 예를 들면 다음과 같습니다.
String registryUrl = "https://registry.example.com/apis/registry/v2"; Properties props = new Properties(); props.putIfAbsent(SerdeConfig.REGISTRY_URL, registryUrl);
직렬화자를 사용하여 클라이언트를 구성하고 서비스 레지스트리에서 스키마를 조회하는 전략을 구성합니다. 예를 들면 다음과 같습니다.
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가 설치됨
- 스키마가 서비스 레지스트리에 등록됨
절차
서비스 레지스트리 URL을 사용하여 Java 클라이언트를 생성하고 구성합니다.
String registryUrl = "https://registry.example.com/apis/registry/v2"; RegistryService client = RegistryClient.cached(registryUrl);
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 리더를 구성합니다.
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 구성”
- 8.2절. “Service Registry serializer/deserializer 구성 속성”
- 8.3절. “다른 클라이언트 직렬화기/deserializer 유형을 구성하는 방법”
- 8.3.1절. “서비스 레지스트리를 사용하여 Avro SerDes 구성”
- 8.3.2절. “서비스 레지스트리를 사용하여 JSON Schema SerDes 구성”
- 8.3.3절. “서비스 레지스트리를 사용하여 Protobuf 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
- 서비스 레지스트리의 필수 URL입니다.
-
다른 ID 형식을 지원하고 서비스 레지스트리 SerDe 서비스와 호환되도록 ID 처리를 확장합니다. 예를 들어 기본 ID 형식을
Long
에서Integer
로 변경하면 Confluent ID 형식이 지원됩니다. -
Confluent ID의 처리를 단순화합니다.
true
로 설정하면 글로벌 ID 조회에Integer
가 사용됩니다.ID_HANDLER
옵션과 함께 설정을 사용해서는 안 됩니다.
추가 리소스
- 구성 옵션에 대한 자세한 내용은 다음을 참조하십시오. 8.2절. “Service Registry serializer/deserializer 구성 속성”
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 ...
- 아티팩트 확인자 전략과 Kafka SerDe 및 아티팩트 ID 간 매핑을 구현하는 Java 클래스입니다. 기본값은 주제 ID 전략입니다. 이 클래스는 serializer 클래스에서만 사용됩니다.
-
스키마 확인자를 구현하는 Java 클래스입니다. 기본값은
DefaultSchemaResolver
입니다. 이는 serializer 및 deserializer 클래스에서 사용됩니다.
추가 리소스
- 전략 검색에 대한 자세한 내용은 다음을 참조하십시오. 7장. Java 클라이언트의 serializers/deserializers를 사용하여 Kafka 메시지 검증
- 구성 옵션에 대한 자세한 내용은 다음을 참조하십시오. 8.2절. “Service Registry 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
- Service Registry Kafka 변환기와 함께 사용하는 데 필요한 직렬화기입니다.
- Service Registry Kafka 변환기와 함께 사용하는 데 필요한 역직렬러입니다.
추가 리소스
- 자세한 내용은 SerdeBasedConverter Java 클래스를 참조하십시오.
다양한 스키마 유형의 구성
다양한 스키마 기술에 대한 SerDe 구성 방법에 대한 자세한 내용은 다음을 참조하십시오.
8.2. Service Registry serializer/deserializer 구성 속성
이 섹션에서는 Service Registry Kafka serializers/deserializers(SerDes)의 Java 구성 속성에 대한 참조 정보를 제공합니다.
SchemaResolver 인터페이스
서비스 레지스트리 SerDes는 SchemaResolver
인터페이스를 기반으로 하며 레지스트리에 대한 액세스를 추상화하고 지원되는 모든 형식의 SerDes 클래스에 동일한 조회 논리를 적용합니다.
상수 | 속성 | 설명 | 유형 | Default |
---|---|---|---|---|
|
|
serializer 및 deserializers에서 사용합니다. | 문자열 |
|
DefaultSchemaResolver
가 권장되며 대부분의 사용 사례에 유용한 기능을 제공합니다. 일부 고급 사용 사례의 경우 SchemaResolver
의 사용자 지정 구현을 사용할 수 있습니다.
DefaultSchemaResolver 클래스
DefaultSchemaResolver
를 사용하여 다음과 같은 기능을 구성할 수 있습니다.
- 레지스트리 API에 액세스
- 레지스트리에서 아티팩트 조회 방법
- Kafka에 아티팩트 정보를 작성하고 읽는 방법
- 역직렬러의 대체 옵션
레지스트리 API 액세스 옵션 구성
DefaultSchemaResolver
는 코어 레지스트리 API에 대한 액세스를 구성하기 위해 다음 속성을 제공합니다.
상수 | 속성 | 설명 | 유형 | Default |
---|---|---|---|---|
|
| serializer 및 deserializers에서 사용합니다. 레지스트리 API에 액세스할 URL입니다. |
| 없음 |
|
| serializer 및 deserializers에서 사용합니다. 인증 서비스의 URL입니다. OAuth 클라이언트 인증 정보 흐름을 사용하여 보안 레지스트리에 액세스하는 경우 필요합니다. |
| 없음 |
|
|
serializer 및 deserializers에서 사용합니다. 토큰 끝점의 URL입니다. 보안 레지스트리에 액세스하는 경우 필수 항목이며 |
| 없음 |
|
| serializer 및 deserializers에서 사용합니다. 인증 서비스에 액세스할 영역입니다. OAuth 클라이언트 인증 정보 흐름을 사용하여 보안 레지스트리에 액세스하는 경우 필요합니다. |
| 없음 |
|
| serializer 및 deserializers에서 사용합니다. 인증 서비스에 액세스하기 위한 클라이언트 ID입니다. OAuth 클라이언트 인증 정보 흐름을 사용하여 보안 레지스트리에 액세스하는 경우 필요합니다. |
| 없음 |
|
| serializer 및 deserializers에서 사용합니다. 인증 서비스에 액세스하기 위한 클라이언트 시크릿입니다. OAuth 클라이언트 인증 정보 흐름을 사용하여 보안 레지스트리에 액세스하는 경우 필요합니다. |
| 없음 |
|
| serializer 및 deserializers에서 사용합니다. 사용자 이름을 사용하여 레지스트리에 액세스합니다. HTTP 기본 인증을 사용하여 보안 레지스트리에 액세스하는 경우 필수 항목입니다. |
| 없음 |
|
| serializer 및 deserializers에서 사용합니다. 레지스트리에 액세스하기 위한 암호입니다. HTTP 기본 인증을 사용하여 보안 레지스트리에 액세스하는 경우 필수 항목입니다. |
| 없음 |
레지스트리 조회 옵션 구성
DefaultSchemaResolver
는 다음 속성을 사용하여 서비스 레지스트리에서 아티팩트를 조회하는 방법을 구성합니다.
상수 | 속성 | 설명 | 유형 | Default |
---|---|---|---|---|
|
|
serialize자만 사용합니다. |
|
|
|
|
serialize자만 사용합니다. 아티팩트를 쿼리하거나 생성하는 데 사용되는 |
| 없음 |
|
|
serialize자만 사용합니다. 아티팩트를 쿼리하거나 생성하는 데 사용되는 |
| 없음 |
|
|
serialize자만 사용합니다. 아티팩트를 쿼리하거나 생성하는 데 사용되는 아티팩트 버전을 설정합니다. |
| 없음 |
|
| serialize자만 사용합니다. serializer가 해당 그룹 ID 및 아티팩트 ID의 레지스트리에서 최신 아티팩트를 찾는지 여부를 지정합니다. |
|
|
|
| serialize자만 사용합니다. serializer가 레지스트리에 아티팩트를 만들 것인지 여부를 지정합니다. JSON Schema serializer는 이 기능을 지원하지 않습니다. |
|
|
|
|
serialize자만 사용합니다. 아티팩트가 이미 있으므로 아티팩트를 생성하는 충돌이 있을 때 클라이언트의 동작을 구성합니다. 사용 가능한 값은 |
|
|
|
| serializer 및 deserializers에서 사용합니다. 자동eviction(밀리초) 전에 아티팩트를 캐시하는 기간을 지정합니다. 0으로 설정하면 매번 아티팩트가 가져옵니다. |
|
|
|
| serializer 및 deserializers에서 사용합니다. 레지스트리에서 스키마를 검색할 수 없는 경우 여러 번 재시도할 수 있습니다. 이 구성 옵션은 재시도 시도(밀리초) 간 지연을 제어합니다. |
|
|
|
| serializer 및 deserializers에서 사용합니다. 레지스트리에서 스키마를 검색할 수 없는 경우 여러 번 재시도할 수 있습니다. 이 구성 옵션은 재시도 시도 횟수를 제어합니다. |
|
|
|
|
serializer 및 deserializers에서 사용합니다. 지정된 |
|
|
Kafka에서 레지스트리 아티팩트 읽기/쓰기 구성
DefaultSchemaResolver
는 다음 속성을 사용하여 아티팩트 정보를 작성하고 Kafka에서 읽는 방법을 구성합니다.
상수 | 속성 | 설명 | 유형 | Default |
---|---|---|---|---|
|
| serializer 및 deserializers에서 사용합니다. 는 메시지 페이로드 대신 Kafka 메시지 헤더에 아티팩트 식별자를 읽고 쓰도록 구성합니다. |
|
|
|
|
serializer 및 deserializers에서 사용합니다. |
|
|
|
|
serializer 및 deserializers에서 사용합니다. |
|
|
|
|
serializer 및 deserializers에서 사용합니다. |
|
|
역직렬러 장애 옵션 구성
DefaultSchemaResolver
는 다음 속성을 사용하여 모든 역직렬로 대체 공급자를 구성합니다.
상수 | 속성 | 설명 | 유형 | Default |
---|---|---|---|---|
|
|
역직자만 사용합니다. deserialization에 사용된 아티팩트를 해결하기 위해 |
|
|
DefaultFallbackArtifactProvider
는 다음 속성을 사용하여 deserializer 대체 옵션을 구성합니다.
상수 | 속성 | 설명 | 유형 | Default |
---|---|---|---|---|
|
|
deserialize자만 사용합니다. deserialization에 사용되는 아티팩트를 확인하기 위한 폴백으로 사용되는 |
| 없음 |
|
|
deserialize자만 사용합니다. 역직렬화에 사용되는 그룹을 확인하기 위해 폴백으로 사용되는 |
| 없음 |
|
| 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; }
추가 리소스
- 예제 애플리케이션의 경우 간단한 Avro 예제를 참조하십시오.
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
스키마를 사용하는 메시지가 직렬화되거나 역직렬화될 때마다 두 스키마가 모두 검색되므로 정의를 다른 파일로 분할할 수 있습니다.
추가 리소스
- Avro 구성에 대한 자세한 내용은 AvroKafkaSerdeConfig Java 클래스를 참조하십시오.
Java 예제 애플리케이션의 경우 다음을 참조하십시오.
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에서, 광주 스키마를 가져올 때, 도시 스키마는 성도 스키마에서 참조되기 때문에 가져옵니다. 데이터를 직렬화/감사할 때 참조 이름은 중첩된 스키마를 확인하는 데 사용되며, 이를 통해 기존 스키마 및 중첩된 도시 스키마에 대한 유효성을 검증할 수 있습니다.
추가 리소스
- 자세한 내용은 JsonSchemaKafkaDeserializerConfig Java 클래스를 참조하십시오.
Java 예제 애플리케이션의 경우 다음을 참조하십시오.
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의 메시지를 검사하도록 할 때마다 Mode
도 TableInfo
에서 참조하는 아티팩트로 반환됩니다.
추가 리소스
Java 예제 애플리케이션의 경우 다음을 참조하십시오.
9장. 서비스 레지스트리 아티팩트 참조
이 장에서는 Service Registry에 저장된 지원되는 아티팩트 유형, 상태 및 메타데이터에 대한 참조 정보를 제공합니다.
추가 리소스
9.1. 서비스 레지스트리 아티팩트 유형
Service Registry에서 광범위한 스키마 및 API 아티팩트 유형을 저장하고 관리할 수 있습니다.
유형 | 설명 |
---|---|
| AsyncAPI 사양 |
| Apache Avro schema |
| GraphQL 스키마 |
| JSON Schema |
| Apache Kafka Connect 스키마 |
| OpenAPI 사양 |
| Google 프로토콜 버퍼 스키마 |
| Web Services 정의 언어 |
| 확장 가능한 태그 언어 |
| XML 스키마 정의 |
9.2. 서비스 레지스트리 아티팩트 상태
서비스 레지스트리의 유효한 아티팩트 상태는 ENABLED
,DISABLED
및 DEPRECATED
입니다.
상태 | 설명 |
---|---|
| 기본 상태, 모든 작업을 사용할 수 있습니다. |
| 아티팩트 및 해당 메타데이터는 서비스 레지스트리 웹 콘솔을 사용하여 볼 수 있으며 검색할 수 있지만 클라이언트에서 해당 콘텐츠를 가져올 수 없습니다. |
| 아티팩트는 완전히 사용할 수 있지만 아티팩트 콘텐츠를 가져올 때마다 헤더가 REST API 응답에 추가됩니다. Service Registry Rest Client는 더 이상 사용되지 않는 콘텐츠가 표시될 때마다 경고를 기록합니다. |
9.3. 서비스 레지스트리 아티팩트 메타데이터
아티팩트가 서비스 레지스트리에 추가되면 메타데이터 속성 집합이 아티팩트 콘텐츠와 함께 저장됩니다. 이 메타데이터는 설정할 수 있는 일부 속성과 함께 생성된 읽기 전용 속성 세트로 구성됩니다.
속성 | 유형 |
---|---|
| integer |
| string |
| date |
| integer |
| string |
| string |
| string |
| date |
| ArtifactReference 배열 |
| ArtifactType |
| integer |
속성 | 유형 |
---|---|
| string |
| 문자열 배열 |
| string |
| map |
| ArtifactState |
아티팩트 메타데이터 업데이트
- 서비스 레지스트리 REST API를 사용하여 메타데이터 끝점을 사용하여 편집 가능한 속성 집합을 업데이트할 수 있습니다.
-
상태 전환 API를 사용하여
상태
속성만 편집할 수 있습니다. 예를 들어 아티팩트를더 이상 사용되지
않거나비활성화됨으로 표시할 수 있습니다
.
10장. 서비스 레지스트리 콘텐츠 규칙 참조
이 장에서는 지원되는 콘텐츠 규칙 유형, 아티팩트 유형에 대한 지원 수준, 아티팩트별 및 글로벌 규칙의 우선순위 순서에 대한 참조 정보를 제공합니다.
추가 리소스
10.1. 서비스 레지스트리 콘텐츠 규칙 유형
VALIDITY
,COMPATIBILITY
및 INTEGRITY
규칙 유형을 지정하여 서비스 레지스트리의 콘텐츠 진화를 관리할 수 있습니다. 이러한 규칙 유형은 글로벌 규칙 및 아티팩트별 규칙에 모두 적용됩니다.
유형 | 설명 |
---|---|
| 서비스 레지스트리에 추가하기 전에 콘텐츠를 검증합니다. 이 규칙에 대해 가능한 구성 값은 다음과 같습니다.
|
|
아티팩트를 업데이트할 때 호환성 수준을 적용합니다(예: 이전 버전과의 호환성을 위해
|
| 아티팩트를 생성하거나 업데이트할 때 아티팩트 참조 무결성을 강제 적용합니다. 이 규칙을 활성화하고 구성하여 제공된 아티팩트 참조가 올바른지 확인합니다. 이 규칙에 대해 가능한 구성 값은 다음과 같습니다.
|
10.2. 서비스 레지스트리 콘텐츠 규칙 완성도
Service Registry에서 지원하는 모든 아티팩트 유형에 대해 모든 콘텐츠 규칙이 완전히 구현되는 것은 아닙니다. 다음 표는 각 규칙 및 아티팩트 유형의 현재 완성 수준을 보여줍니다.
아티팩트 유형 | 유효성 규칙 | 호환성 규칙 | 무결성 규칙 |
---|---|---|---|
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. 서비스 레지스트리 콘텐츠 규칙 우선순위
아티팩트를 추가하거나 업데이트할 때 서비스 레지스트리는 아티팩트 콘텐츠의 유효성, 호환성 또는 무결성을 확인하는 규칙을 적용합니다. 구성된 아티팩트별 규칙은 다음 표에 표시된 대로 구성된 글로벌 규칙을 재정의합니다.
아티팩트별 규칙 | 글로벌 규칙 | 이 아티팩트에 적용되는 규칙 | 다른 아티팩트에 대해 글로벌 규칙을 사용할 수 있습니까? |
---|---|---|---|
enabled | enabled | Artifact-specific | 제공됨 |
disabled | enabled | 글로벌 | 제공됨 |
disabled | disabled | 없음 | 없음 |
활성화됨, 없음으로 설정 | enabled | 없음 | 제공됨 |
disabled | 활성화됨, 없음으로 설정 | 없음 | 없음 |
부록 A. 서브스크립션 사용
서비스 레지스트리는 소프트웨어 서브스크립션을 통해 제공됩니다. 서브스크립션을 관리하려면 Red Hat 고객 포털에서 계정에 액세스하십시오.
귀하의 계정에 액세스
- access.redhat.com 으로 이동합니다.
- 아직 계정이 없는 경우 계정을 생성합니다.
- 계정에 로그인합니다.
서브스크립션 활성화
- access.redhat.com 으로 이동합니다.
- 내 서브스크립션으로 이동합니다.
- 서브스크립션을 활성화하여 16자리 활성화 번호를 입력합니다.
ZIP 및 TAR 파일 다운로드
ZIP 또는 TAR 파일에 액세스하려면 고객 포털을 사용하여 다운로드를 위한 관련 파일을 찾습니다. RPM 패키지를 사용하는 경우에는 이 단계가 필요하지 않습니다.
- 브라우저를 열고 access.redhat.com/downloads 에서 Red Hat 고객 포털 제품 다운로드 페이지에 로그인합니다.
- 통합 및 자동화 카테고리에서 Red Hat Integration 항목을 찾습니다.
- 원하는 Service Registry 제품을 선택합니다. Software Download 페이지가 열립니다.
- 구성 요소에 대한 다운로드 링크를 클릭합니다.
2023-09-19에 최종 업데이트된 문서