此内容没有您所选择的语言版本。
Migrating Apicurio Registry deployments
Migrate from Apicurio Registry version 2.6 to 3.0
Abstract
Chapter 1. Migration from Apicurio Registry 2.6 to 3.x 复制链接链接已复制到粘贴板!
Apicurio Registry 3.x includes a redesigned data model, a reworked REST API, and a refreshed SDK ecosystem compared to the previous Apicurio Registry 2.6 release. This section outlines the major changes between Apicurio Registry 2.6 and version 3.x so that you can plan your upgrade activities.
Because of the breaking changes in 3.x, there is no in-place upgrade. You must stand up a new 3.x deployment, migrate the persisted content, and update your client applications and automation.
When migrating to version 3.x, take the following areas into account:
1.1. Updated data model and governance 复制链接链接已复制到粘贴板!
Apicurio Registry 3.x separates artifact metadata from version metadata and introduces first-class support for empty artifacts. These capabilities let you prepare governance metadata, rules, and branch structures before the first version exists. Additional highlights include:
- Artifact metadata is now managed independently from version metadata.
- Groups and artifacts can define custom labels to improve categorization.
-
Users can create and manage custom branches, and the
latestbranch is implemented as a system managed branch.
1.2. Core v3 REST API 复制链接链接已复制到粘贴板!
The v3 REST API focuses on consistency and discoverability:
- Group management now covers descriptions, owners, labels, and hierarchical rules.
-
New search endpoints at
/search/groupsand/search/versionsexpand discovery. -
Version-focused endpoints streamline content management and require explicit
Content-Typeheaders. -
A
dryRunquery parameter replaces the former/testendpoints. - A dedicated Branch API enables multitrack artifact development.
1.3. Re-engineered Kafka storage variant 复制链接链接已复制到粘贴板!
The KafkaSQL storage implementation is now optimized for stability and maintainability. The new design reduces startup times for large installations.
1.4. Generated SDKs powered by Kiota 复制链接链接已复制到粘贴板!
Apicurio Registry 3.x ships Kiota-generated SDKs that mirror the REST API structure across languages. Updated libraries are available for Java, TypeScript, Python, and Go, providing lightweight, type-safe clients with minimal dependencies and consistent naming.
1.5. Migrating Apicurio Registry data 复制链接链接已复制到粘贴板!
Use the export and import APIs to migrate persisted content from Apicurio Registry 2.6 into a new Apicurio Registry 3.x deployment. The APIs preserve artifact identifiers, metadata, and references so that downstream Kafka payloads remain compatible.
Apicurio Registry 3.x accepts the export archive generated from a 2.6 instance. Capture the archive from your existing deployment, provision the 3.x environment, and import the archive into the new cluster.
Prerequisites
- Running Apicurio Registry instances of the 2.6 server you are exporting from and the 3.x server you are importing into.
-
Administrative credentials that allow access to the
/apis/registry/v2/admin/exportand/apis/registry/v3/admin/importendpoints.
Procedure
Export all data from Apicurio Registry 2.6. The following command downloads
registry-export.zipto your working directory:curl -X GET "http://old-registry.my-company.com/apis/registry/v2/admin/export" \ -o registry-export.zip
curl -X GET "http://old-registry.my-company.com/apis/registry/v2/admin/export" \ -o registry-export.zipCopy to Clipboard Copied! Toggle word wrap Toggle overflow Import the archive into Apicurio Registry 3.x by posting it to the admin import endpoint:
curl -X POST "http://new-registry.my-company.com/apis/registry/v3/admin/import" \ -H "Content-Type: application/zip" \ --data-binary @registry-export.zip
curl -X POST "http://new-registry.my-company.com/apis/registry/v3/admin/import" \ -H "Content-Type: application/zip" \ --data-binary @registry-export.zipCopy to Clipboard Copied! Toggle word wrap Toggle overflow Validate the migrated content. Compare artifact counts between the legacy and new deployments:
curl "http://old-registry.my-company.com/apis/registry/v2/search/artifacts"
curl "http://old-registry.my-company.com/apis/registry/v2/search/artifacts"Copy to Clipboard Copied! Toggle word wrap Toggle overflow curl "http://new-registry.my-company.com/apis/registry/v3/search/artifacts"
curl "http://new-registry.my-company.com/apis/registry/v3/search/artifacts"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Check that global rules were imported successfully:
curl "http://new-registry.my-company.com/apis/registry/v3/admin/rules"
curl "http://new-registry.my-company.com/apis/registry/v3/admin/rules"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.6. Migrating Apicurio Registry client applications 复制链接链接已复制到粘贴板!
Review every application that integrates with Apicurio Registry 2.6 to ensure compatibility with the v3 REST API, SDKs, and client libraries. Update dependency coordinates, reconfigure endpoints, and adjust automation to account for the new data model.
Prerequisites
- Existing Apicurio Registry 2.6 applications that rely on the v2 REST API or legacy client libraries.
- Access to the source code or deployment configuration for each application you must update.
Procedure
Update your client configuration to target the v3 REST API base path:
String registryUrl = "https://new-registry.my-company.com/apis/registry/v3"; RegistryClient client = RegistryClientFactory.create(registryUrl);
String registryUrl = "https://new-registry.my-company.com/apis/registry/v3"; RegistryClient client = RegistryClientFactory.create(registryUrl);Copy to Clipboard Copied! Toggle word wrap Toggle overflow Automation that previously targeted
/apis/registry/v2continues to function, but new functionality is only exposed through the v3 API.Refresh your client dependencies to the latest 3.x SDKs generated with Kiota. For Maven-based Java applications, use the new artifact identifier:
<dependency> <groupId>io.apicurio</groupId> <artifactId>apicurio-registry-java-sdk</artifactId> <version>3.0.0.Final-redhat-00001</version> </dependency><dependency> <groupId>io.apicurio</groupId> <artifactId>apicurio-registry-java-sdk</artifactId> <version>3.0.0.Final-redhat-00001</version> </dependency>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Install the TypeScript, Python, or Go SDKs through the respective package managers (
npm install @apicurio/apicurio-registry-sdk,pip install apicurioregistrysdk, orgo get github.com/apicurio/apicurio-registry/go-sdk).Align your integration code with the reorganized endpoints:
-
Manage artifact metadata at
/groups/{groupId}/artifacts/{artifactId}. -
Retrieve or create content exclusively through
/versionsendpoints. -
Replace calls to
/testendpoints with thedryRunquery parameter. -
Use
/search/groupsand/search/versionswhere you previously enumerated artifacts indirectly.
-
Manage artifact metadata at
- Adopt the branch API if you need parallel development streams. Branches allow you to promote or merge versions without duplicating artifacts.
- If you build Kafka SerDes integrations, verify that serializers and deserializers still reference the correct registry URL and consider enabling group- or artifact-level rules introduced in 3.x to enforce compatibility upstream.
1.7. Updating Apicurio Registry configuration 复制链接链接已复制到粘贴板!
Configuration keys in Apicurio Registry 3.x adopt a unified apicurio. namespace and reorganize authentication, eventing, UI, and storage settings. Review and update your deployment descriptors so that server-side properties match the new naming scheme.
1.7.1. Naming convention changes 复制链接链接已复制到粘贴板!
Most configuration properties now start with the apicurio. prefix. The following examples illustrate common mappings:
| Registry 2.x property | Registry 3.x property |
|---|---|
|
|
|
|
|
|
|
|
|
1.7.2. Authentication and authorization 复制链接链接已复制到粘贴板!
Authentication settings continue to rely on Quarkus OIDC support, but role-based properties moved to the new namespace. Update the property names and review any removed options:
| Registry 2.x property | Registry 3.x property |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1.7.3. Eventing and Kafka storage 复制链接链接已复制到粘贴板!
Kafka-related settings now share the apicurio.kafkasql prefix. Update both event notifications and Kafka storage properties:
| Registry 2.x property | Registry 3.x property |
|---|---|
|
|
|
|
|
|
|
|
|
Registry 3.x example
# Registry 3.x example
apicurio.events.kafka.topic=my-registry-events
apicurio.kafkasql.bootstrap.servers=kafka:9092
apicurio.kafkasql.topic=my-registry-storage
apicurio.kafkasql.topic.auto-create=true
1.8. UI and API configuration 复制链接链接已复制到粘贴板!
The UI configuration is now grouped under apicurio.ui.*, and API diagnostics align with the new hierarchy:
| Registry 2.x property | Registry 3.x property |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
1.8.1. Storage and database configuration 复制链接链接已复制到粘贴板!
Database settings moved out of the Quarkus datasource namespace. Update JDBC configuration and storage selection properties:
| Registry 2.x property | Registry 3.x property |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
1.8.2. Migration checklist 复制链接链接已复制到粘贴板!
-
Inventory all configuration files, including deployment manifests and
application.properties. - Translate properties to their 3.x equivalents using the mappings in this section.
- Start a staging deployment of Apicurio Registry 3.x with the updated configuration and monitor logs for deprecated or unknown keys.
- Validate UI login flows, rule enforcement, and storage connectivity before promoting to production.
1.8.3. Common issues and resolutions 复制链接链接已复制到粘贴板!
-
Authentication failures: confirm that
apicurio.auth.roles.*properties mirror the expected role names and that OIDC redirect URIs use the new property names. -
Missing Kafka settings: verify that all Kafka-related properties use the
apicurio.kafkasqlprefix and that optional settings removed in 3.x are not still present. -
Database connection errors: ensure you migrated JDBC settings out of the
quarkus.datasource.*namespace and updated secrets or ConfigMaps accordingly.
Appendix A. Using your subscription 复制链接链接已复制到粘贴板!
Apicurio Registry is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal.
Accessing your account
- Go to access.redhat.com.
- If you do not already have an account, create one.
- Log in to your account.
Activating a subscription
- Go to access.redhat.com.
- Navigate to My Subscriptions.
- Navigate to Activate a subscription and enter your 16-digit activation number.
Downloading ZIP and TAR files
To access ZIP or TAR files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required.
- Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads.
- Locate the Red Hat Integration entries in the Integration and Automation category.
- Select the desired Apicurio Registry product. The Software Downloads page opens.
- Click the Download link for your component.
Revised on 2025-11-04 11:18:45 UTC