Chapter 8. Configuring and managing Service Registry deployment
This chapter explains how to configure and manage optional settings for your Service Registry deployment on OpenShift:
- Section 8.1, “Configuring Service Registry health checks on OpenShift”
- Section 8.2, “Environment variables for Service Registry health checks”
- Section 8.3, “Configuring an HTTPS connection to Service Registry from inside the OpenShift cluster”
- Section 8.4, “Configuring an HTTPS connection to Service Registry from outside the OpenShift cluster”
8.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.
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 with your preferred storage option. See Chapter 4, Installing Service Registry on OpenShift.
- You must have already installed and configured your chosen Service Registry storage in AMQ Streams, embedded Infinispan, 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
-
NAME:
Click Save at the bottom.
Alternatively, you can perform these steps using the OpenShift
oc
command. For more details, see the OpenShift CLI documentation.
8.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 8.1, “Configuring Service Registry health checks on OpenShift”.
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
Name | Description | Type | Default |
---|---|---|---|
| Number of liveness issues or errors that can occur before the liveness probe fails. | Integer |
|
| 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 |
|
| Number of seconds that must elapse without any more errors for the liveness probe to reset to OK status. | Seconds |
|
| Comma-separated list of ignored liveness exceptions. | String |
|
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
Name | Description | Type | Default |
---|---|---|---|
| Number of readiness issues or errors that can occur before the readiness probe fails. | Integer |
|
| 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 |
|
| 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 |
|
| Readiness tracks the timeout of two operations:
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 |
|
8.3. Configuring an HTTPS connection to Service Registry from inside the OpenShift cluster
The following procedure shows how to configure Service Registry deployment to expose a port for HTTPS connections from inside the OpenShift cluster.
This kind of connection is not directly available outside of the cluster. Routing is based on hostname, which is encoded in the case of an HTTPS connection. Therefore, edge termination or other configuration is still needed. See Section 8.4, “Configuring an HTTPS connection to Service Registry from outside the OpenShift cluster”.
Prerequisites
- You must have already installed the Service Registry Operator.
Procedure
Generate a
keystore
with a self-signed certificate. You can skip this step if you are using your own certificates.keytool -genkey -trustcacerts -keyalg RSA -keystore registry-keystore.jks -storepass password
Create a new secret to hold the keystore and keystore password.
- In the left navigation menu of the OpenShift web console, click Workloads > Secrets > Create Key/Value Secret.
Use the following values:
-
Name:
registry-keystore
-
Key 1:
keystore.jks
-
Value 1: registry-keystore.jks (uploaded file)
-
Key 2:
password
Value 2: password
NoteIf you encounter a
java.io.IOException: Invalid keystore format
, the upload of the binary file did not work properly. As an alternative, encode the file as a base64 string usingcat registry-keystore.jks | base64 -w0 > data.txt
and edit the Secret resource as yaml to manually add the encoded file.
-
Name:
Edit the DeploymentConfig resource of the Service Registry instance. You can find the correct name in a status field of the Service Registry Operator.
Add the keystore secret as a volume:
template: spec: volumes: - name: registry-keystore-secret-volume secret: secretName: registry-keystore
Add a volume mount:
volumeMounts: - name: registry-keystore-secret-volume mountPath: /etc/registry-keystore readOnly: true
Add
JAVA_OPTIONS
andKEYSTORE_PASSWORD
environment variables:- name: KEYSTORE_PASSWORD valueFrom: secretKeyRef: name: registry-keystore key: password - name: JAVA_OPTIONS value: >- -Dquarkus.http.ssl.certificate.key-store-file=/etc/registry-keystore/keystore.jks -Dquarkus.http.ssl.certificate.key-store-file-type=jks -Dquarkus.http.ssl.certificate.key-store-password=$(KEYSTORE_PASSWORD)
NoteOrder is important when using string interpolation.
Enable the HTTPS port:
ports: - containerPort: 8080 protocol: TCP - containerPort: 8443 protocol: TCP
Edit the Service resource of the Service Registry instance. You can find the correct name in a status field of the Service Registry Operator.
ports: - name: http protocol: TCP port: 8080 targetPort: 8080 - name: https protocol: TCP port: 8443 targetPort: 8443
Verify that the connection is working:
Connect into a pod on the cluster using SSH (you can use the Service Registry pod):
oc rsh -n default example-apicurioregistry-deployment-vx28s-4-lmtqb
- Find the cluster IP of the Service Registry pod from the Service resource (see the Location column in the web console).
Afterwards, execute a test request (we are using self-signed certificate, so an insecure flag is required):
curl -k https://172.30.209.198:8443/health [...]
8.4. Configuring an HTTPS connection to Service Registry from outside the OpenShift cluster
The following procedure shows how to configure Service Registry deployment to expose an HTTPS edge-terminated route for connections from outside the OpenShift cluster.
Prerequisites
- You must have already installed the Service Registry Operator.
- Read the OpenShift documentation for creating secured routes.
Procedure
Add a second Route in addition to the HTTP route created by the Service Registry Operator. See the following example:
kind: Route apiVersion: route.openshift.io/v1 metadata: [...] labels: app: example-apicurioregistry [...] spec: host: example-apicurioregistry-default.apps.example.com to: kind: Service name: example-apicurioregistry-service-9whd7 weight: 100 port: targetPort: 8080 tls: termination: edge insecureEdgeTerminationPolicy: Redirect wildcardPolicy: None
NoteMake sure the
insecureEdgeTerminationPolicy: Redirect
configuration property is set.If you do not specify a certificate, OpenShift will use a default. You can alternatively generate a custom self-signed certificate using the following commands:
openssl genrsa 2048 > host.key && openssl req -new -x509 -nodes -sha256 -days 365 -key host.key -out host.cert
And then create a route using the OpenShift CLI:
oc create route edge \ --service=example-apicurioregistry-service-9whd7 \ --cert=host.cert --key=host.key \ --hostname=example-apicurioregistry-default.apps.example.com \ --insecure-policy=Redirect \ -n default