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:

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.
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 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

  1. In the OpenShift Container Platform web console, log in using an account with cluster administrator privileges.
  2. Click Installed Operators > Red Hat Integration - Service Registry.
  3. On the ApicurioRegistry tab, click the Operator custom resource for your deployment, for example, example-apicurioregistry.
  4. In the main overview page, find the Deployment Name section and the corresponding DeploymentConfig name for your Service Registry deployment, for example, example-apicurioregistry.
  5. In the left navigation menu, click Workloads > Deployment Configs, and select your DeploymentConfig name.
  6. Click the Environment tab, and enter your environment variables in the Single values env section, for example:

    • NAME: LIVENESS_STATUS_RESET
    • VALUE: 350
  7. 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”.

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 8.1. Environment variables for Service Registry liveness probes

NameDescriptionTypeDefault

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 8.2. Environment variables for Service Registry readiness probes

NameDescriptionTypeDefault

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

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.

Warning

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

  1. 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
  2. Create a new secret to hold the keystore and keystore password.

    1. In the left navigation menu of the OpenShift web console, click Workloads > Secrets > Create Key/Value Secret.
    2. Use the following values:

      • Name: registry-keystore
      • Key 1: keystore.jks
      • Value 1: registry-keystore.jks (uploaded file)
      • Key 2: password
      • Value 2: password

        Note

        If 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 using cat registry-keystore.jks | base64 -w0 > data.txt and edit the Secret resource as yaml to manually add the encoded file.

  3. Edit the DeploymentConfig resource of the Service Registry instance. You can find the correct name in a status field of the Service Registry Operator.

    1. Add the keystore secret as a volume:

      template:
        spec:
          volumes:
          - name: registry-keystore-secret-volume
            secret:
            secretName: registry-keystore
    2. Add a volume mount:

      volumeMounts:
        - name: registry-keystore-secret-volume
          mountPath: /etc/registry-keystore
          readOnly: true
    3. Add JAVA_OPTIONS and KEYSTORE_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)
      Note

      Order is important when using string interpolation.

    4. Enable the HTTPS port:

      ports:
        - containerPort: 8080
          protocol: TCP
        - containerPort: 8443
          protocol: TCP
  4. 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
  5. Verify that the connection is working:

    1. 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
    2. Find the cluster IP of the Service Registry pod from the Service resource (see the Location column in the web console).
    3. 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

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
    Note

    Make 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