Chapter 6. Configuring and managing a Service Registry deployment

6.1. Configuring Service Registry health checks on OpenShift

You can configure optional environment variables for liveness and readiness probes to monitor the health of the Service Registry server on OpenShift:

Liveness probes test if the application can make progress. If the application cannot make progress, OpenShift automatically restarts the failing Pod.
Readiness probes test if the application is ready to process requests. If the application is not ready, it can become overwhelmed by requests, and OpenShift stops sending requests for the time that the probe fails. If other Pods are OK, they continue to receive requests.

Important

The default values of the liveness and readiness environment variables are designed for most cases and should only be changed if required by your environment. Any changes to the defaults depend on your hardware, network, and amount of data stored. These values should be kept as low as possible to avoid unnecessary overhead.

Prerequisites

You must have an OpenShift cluster with cluster administrator access.
You must have already installed Service Registry on OpenShift.
You must have already installed and configured your chosen Service Registry storage in AMQ Streams or PostgreSQL.

Procedure

In the OpenShift Container Platform web console, log in using an account with cluster administrator privileges.
Click Installed Operators > Red Hat Integration - Service Registry.
On the ApicurioRegistry tab, click the Operator custom resource for your deployment, for example, example-apicurioregistry.
In the main overview page, find the Deployment Name section and the corresponding DeploymentConfig name for your Service Registry deployment, for example, example-apicurioregistry.
In the left navigation menu, click Workloads > Deployment Configs, and select your DeploymentConfig name.
Click the Environment tab, and enter your environment variables in the Single values env section, for example:
- NAME: LIVENESS_STATUS_RESET
- VALUE: 350
Click Save at the bottom.
Alternatively, you can perform these steps using the OpenShift oc command. For more details, see the OpenShift CLI documentation.

Additional resources

6.2. Environment variables for Service Registry health checks

This section describes the available environment variables for Service Registry health checks on OpenShift. These include liveness and readiness probes to monitor the health of the Service Registry server on OpenShift. For an example procedure, see Section 6.1, “Configuring Service Registry health checks on OpenShift”.

Important

The following environment variables are provided for reference only. The default values are designed for most cases and should only be changed if required by your environment. Any changes to the defaults depend on your hardware, network, and amount of data stored. These values should be kept as low as possible to avoid unnecessary overhead.

Liveness environment variables

Table 6.1. Environment variables for Service Registry liveness probes
Name	Description	Type	Default
`LIVENESS_ERROR_THRESHOLD`	Number of liveness issues or errors that can occur before the liveness probe fails.	Integer	`1`
`LIVENESS_COUNTER_RESET`	Period in which the threshold number of errors must occur. For example, if this value is 60 and the threshold is 1, the check fails after two errors occur in 1 minute	Seconds	`60`
`LIVENESS_STATUS_RESET`	Number of seconds that must elapse without any more errors for the liveness probe to reset to OK status.	Seconds	`300`
`LIVENESS_ERRORS_IGNORED`	Comma-separated list of ignored liveness exceptions.	String	`io.grpc.StatusRuntimeException,org.apache.kafka.streams.errors.InvalidStateStoreException`

Note

Because OpenShift automatically restarts a Pod that fails a liveness check, the liveness settings, unlike readiness settings, do not directly affect behavior of Service Registry on OpenShift.

Readiness environment variables

Table 6.2. Environment variables for Service Registry readiness probes
Name	Description	Type	Default
`READINESS_ERROR_THRESHOLD`	Number of readiness issues or errors that can occur before the readiness probe fails.	Integer	`1`
`READINESS_COUNTER_RESET`	Period in which the threshold number of errors must occur. For example, if this value is 60 and the threshold is 1, the check fails after two errors occur in 1 minute.	Seconds	`60`
`READINESS_STATUS_RESET`	Number of seconds that must elapse without any more errors for the liveness probe to reset to OK status. In this case, this means how long the Pod stays not ready, until it returns to normal operation.	Seconds	`300`
`READINESS_TIMEOUT`	Readiness tracks the timeout of two operations: How long it takes for storage requests to complete How long it takes for HTTP REST API requests to return a response If these operations take more time than the configured timeout, this is counted as a readiness issue or error. This value controls the timeouts for both operations.	Seconds	`5`

Additional resources

6.3. Managing Service Registry environment variables

Service Registry Operator manages most common Service Registry configuration, but there are some options that you can adjust manually. You can update these by setting an environment variable on the Service Registry Deployment resource. If the specific configuration option is not available in the ApicurioRegistry CR, you can use an environment variable to adjust it.

Procedure

OpenShift web console

Select the Installed Operators tab, and then the Red Hat Integration - Service Registry Operator.
On the Apicurio Registry tab, click the ApicurioRegistry CR for your Service Registry deployment.
On the main overview page, view the managedResources section, which contains the name of the Deployment managed by the Operator to deploy your Service Registry instance.
Find that Deployment in the Workloads > Deployments in the left menu.
Select the Deployment with the correct name, and select the Environment tab.
You can add or modify your environment variable to the Single values (env) section.
Click Save at the bottom.

OpenShift CLI

Select the project where Service Registry is installed.
Run oc get apicurioregistry to get the list of ApicurioRegistry CRs
Run oc describe on the CR representing the Service Registry instance that you want to configure.
View the managedResource in the status section.
Find that Deployment and enter oc edit.
Add or modify the environment variable in the spec.template.spec.containers[0].env section.

6.4. Configuring the Service Registry web console

You can configure the Service Registry web console specifically for your deployment environment or to customize its behavior. This section provides details on how to configure optional environment variables for the Service Registry web console.

Prerequisites

You must have already installed Service Registry.

Configuring the web console deployment environment

When a user navigates their browser to the Service Registry web console, some initial configuration settings are loaded. Two important configuration properties are:

URL for backend Service Registry REST API
URL for frontend Service Registry web console

Typically, Service Registry automatically detects and generates these settings, but there are some deployment environments where this automatic detection can fail. If this happens, you can configure environment variables to explicitly set these URLs for your environment.

Procedure

Configure the following environment variables to override the default URLs:

REGISTRY_UI_CONFIG_APIURL: Set the URL for the backend Service Registry REST API. For example, https://registry.my-domain.com/apis/registry
REGISTRY_UI_CONFIG_UIURL: Set the URL for the frontend Service Registry web console. For example, https://registry.my-domain.com/ui

Configuring the console in read-only mode

You can configure the Service Registry web console in read-only mode as an optional feature. This mode disables all features in the Service Registry web console that allow users to make changes to registered artifacts. For example, this includes the following:

Creating an artifact
Uploading a new version of an artifact
Updating an artifact’s metadata
Deleting an artifact

Procedure

Configure the following environment variable to set the Service Registry web console in read-only mode:

REGISTRY_UI_FEATURES_READONLY: Set to true to enable read-only mode. Defaults to false.

6.5. Configuring Service Registry logging

You can set Service Registry logging configuration at runtime. Service Registry provides a REST endpoint to set the log level for specific loggers for finer grained logging. This section explains how to view and set Service Registry log levels at runtime using the Service Registry /admin REST API.

Prerequisites

Get the URL to access your Service Registry instance, or get your Service Registry route if you have Service Registry deployed on OpenShift. This simple example uses a URL of localhost:8080.

Procedure

Use this curl command to obtain the current log level for the logger io.apicurio.registry.storage:

$ curl -i localhost:8080/apis/registry/v2/admin/loggers/io.apicurio.registry.storage
HTTP/1.1 200 OK
[...]
Content-Type: application/json
{"name":"io.apicurio.registry.storage","level":"INFO"}

Use this curl command to change the log level for the logger io.apicurio.registry.storage to DEBUG:

$ curl -X PUT -i -H "Content-Type: application/json" --data '{"level":"DEBUG"}' localhost:8080/apis/registry/v2/admin/loggers/io.apicurio.registry.storage
HTTP/1.1 200 OK
[...]
Content-Type: application/json
{"name":"io.apicurio.registry.storage","level":"DEBUG"}

Use this curl command to revert the log level for the logger io.apicurio.registry.storage to its default value:

$ curl -X DELETE -i localhost:8080/apis/registry/v2/admin/loggers/io.apicurio.registry.storage
HTTP/1.1 200 OK
[...]
Content-Type: application/json
{"name":"io.apicurio.registry.storage","level":"INFO"}

6.6. Configuring Service Registry event sourcing

You can configure Service Registry to send events when changes are made to the registry. For example, Service Registry can trigger events when schema and API artifacts are created, updated, deleted, and so on. You can configure Service Registry to send events to your applications and to third-party integrations in this way.

There are different protocols available for transporting the events. The currently implemented protocols are HTTP and Apache Kafka. However, regardless of the protocol, the events are sent using the CNCF CloudEvents specification.

All of the event types are defined in io.apicurio.registry.events.dto.RegistryEventType. For example, the event types include:

io.apicurio.registry.artifact-created
io.apicurio.registry.artifact-updated
io.apicurio.registry.artifact-rule-created
io.apicurio.registry.global-rule-created

You can configure cloud events in Service Registry using Java system properties or equivalent environment variables.

Prerequisites

You must have an application that you want to send Service Registry cloud events to. For example, this can be a custom application or a third-party application.

Configuring Service Registry event sourcing using HTTP

The example in this section shows a custom application running at http://my-app-host:8888/events.

Procedure

When using the HTTP protocol, set your Service Registry configuration to send events to a your application as follows:
- registry.events.sink.my-custom-consumer=http://my-app-host:8888/events
If required, you can configure multiple event consumers as follows:
- registry.events.sink.my-custom-consumer=http://my-app-host:8888/events
- registry.events.sink.other-consumer=http://my-consumer.com/events

Configuring Service Registry event sourcing using Apache Kafka

The example in this section shows a Kafka topic named my-registry-events running on my-kafka-host:9092.

Procedure

When using the Kafka protocol, set your Kafka topic as follows:
- registry.events.kafka.topic=my-registry-events
You can set the configuration for the Kafka producer using the KAFKA_BOOTSTRAP_SERVERS environment variable:
- KAFKA_BOOTSTRAP_SERVERS=my-kafka-host:9092
  Alternatively, you can set the properties for the kafka producer using the registry.events.kafka.config prefix, for example: registry.events.kafka.config.bootstrap.servers=my-kafka-host:9092
If required, you can also set the Kafka topic partition to use to produce events:
- registry.events.kafka.topic-partition=1

Additional resources

For more details, see the CNCF CloudEvents specification

此内容没有您所选择的语言版本。

Chapter 6. Configuring and managing a Service Registry deployment

6.1. Configuring Service Registry health checks on OpenShift

6.2. Environment variables for Service Registry health checks

Liveness environment variables

Readiness environment variables

6.3. Managing Service Registry environment variables

6.4. Configuring the Service Registry web console

Configuring the web console deployment environment

Configuring the console in read-only mode

6.5. Configuring Service Registry logging

6.6. Configuring Service Registry event sourcing

Configuring Service Registry event sourcing using HTTP

Configuring Service Registry event sourcing using Apache Kafka

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links