Managing Apicurio Registry deployment
This chapter explains how to manage your Apicurio Registry deployment:
Managing Apicurio Registry environment variables
Apicurio Registry Operator manages most common Apicurio Registry configuration, but there are some options that you can adjust manually. You can update these by setting an environment variable on the Apicurio Registry DeploymentConfig
resource. If the specific configuration option is not available in the ApicurioRegistry
CR, you can use an environment variable to adjust it.
- OpenShift web console
-
-
Select the Installed Operators tab, and then the Red Hat Integration - Apicurio Registry Operator.
-
On the ApicurioRegistry tab, click the
ApicurioRegistry
CR for your Apicurio Registry deployment. -
On the main overview page, view the Deployment Name section, which contains the name of the
DeploymentConfig
managed by the Operator to deploy your Apicurio Registry instance. -
Find that
DeploymentConfig
in the Workloads > Deployment Configs in the left menu. -
Select the
DeploymentConfig
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 Apicurio Registry is installed.
-
Run
oc get apicurioregistry
to get the list ofApicurioRegistry
CRs -
Run
oc describe
on the CR representing the Apicurio Registry instance that you want to configure. -
View Deployment Name in the status section.
-
Find that
DeploymentConfig
and enteroc edit
. -
Add or modify the environment variable in the
spec.template.spec.containers[0].env
section.
-
Apicurio Registry liveness and readiness environment variables
Apicurio Registry provides readiness and liveness probes for OpenShift to ensure application health. These settings are configured to use reasonable defaults, but if you want to adjust them, this section provides details on the environment variables that you can configure.
OpenShift liveness and readiness errors are explained as follows:
-
Liveness error - the application cannot make progress, OpenShift restarts the failing pod.
-
Readiness error - the application is not ready, for example, it is overwhelmed by requests. OpenShift stops sending requests to the pod for the time the probe fails. If other pods are OK, they still receive requests.
Name | Value type | Description |
---|---|---|
|
Positive integer |
Number of liveness errors that can occur before the liveness probe fails. |
|
Positive integer, seconds |
Period in which the threshold number of errors must occur. For example, if this value is |
|
Positive integer, seconds |
Number of seconds that must elapse without any more errors for the liveness probe to reset to OK status. Because OpenShift restarts the pod that fails the liveness check, this value, unlike readiness, does not actually affect what happens. |
|
Comma-separated list of fully qualified exception class names. |
List of errors that are ignored for liveness checking purposes. |
Name | Value type | Description |
---|---|---|
|
Positive integer |
Number of readiness errors that can occur before the readiness probe fails. |
|
Positive integer, seconds |
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. |
|
Positive integer, seconds |
Number of seconds that must elapse without any more errors for the readiness probe to reset to OK status. In practice, this value means how long the pod remains in an unready state until it returns to normal operation. |
|
positive integer, seconds |
The readiness system tracks the timeout of two operations: how long it takes for a storage request to complete, and how long it takes for an HTTP REST API request to return a response. If the operation takes more time, it is counted as a readiness error. This value controls those timeouts. |
Backing up Apicurio Registry PostgreSQL storage
When using Java Peristence API storage in a PostgreSQL database, you must ensure that the data stored by Apicurio Registry is backed up regularly.
SQL Dump is a simple procedure that works with any PostgreSQL installation. This uses the pg_dump utility to generate a file with SQL commands that you can use to recreate the database in the same state that it was in at the time of the dump.
pg_dump
is a regular PostgreSQL client application, which you can execute from any remote host that has access to the database. Like any other client, the operations that can perform are limited to the user permissions.
-
Use the
pg_dump
command to redirect the output to a file:$ pg_dump dbname > dumpfile
You can specify the database server that
pg_dump
connects to using the-h host
and-p port
options. -
You can reduce large dump files using a compression tool, such as gzip, for example:
$ pg_dump dbname | gzip > filename.gz
For details on client authentication, see the PostgreSQL documentation.
Restoring Apicurio Registry PostgreSQL storage
You can restore SQL Dump files created by pg_dump
using the psql
utility.
-
You must have already backed up your PostgreSQL datbase using
pg_dump
. See Backing up Apicurio Registry PostgreSQL storage. -
All users who own objects or have permissions on objects in the dumped database must already exist.
-
Enter the following command to create the database:
$ createdb -T template0 dbname
-
Enter the following command to restore the SQL dump
$ psql dbname < dumpfile
-
Run ANALYZE on each database so the query optimizer has useful statistics.