External-Mirrors/keycloak
2
0
Fork 0
mirror of https://github.com/keycloak/keycloak.git synced 2026-01-10 15:32:05 -03:30
Code Issues Packages Projects Releases Wiki Activity

Edit Operator Guide

Browse Source 
Closes #39543

Signed-off-by: AndyMunro <amunro@redhat.com>
This commit is contained in:
andymunro 2025-05-08 02:45:41 -04:00 committed by GitHub
parent abc448e4d1
commit eb51c03f90
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
4 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/guides/operator/advanced-configuration.adoc
View File

@ -180,7 +180,7 @@ spec:
periodSeconds: 1
----
Note that the usage of a relative HTTP path, or an alternative management port, require changes to the probe configuration.
Note that the usage of a relative HTTP path, or an alternative management port, requires changes to the probe configuration.
=== Disabling required options
@ -345,9 +345,9 @@ This includes `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` and the `/v
=== Admin Bootstrapping
When you create a new instance the Keycloak CR spec.bootstrapAdmin stanza may be used to configure the bootstrap user and/or service account. If you do not specify anything for the spec.bootstrapAdmin, the operator will create a Secret named "metadata.name"-initial-admin with a username temp-admin and a generated password. If you specify a Secret name for bootstrap admin user, then the Secret will need to contain `username` and `password` key value pairs. If you specify a Secret name for bootstrap admin service account, then the Secret will need to contain `client-id` and `client-secret` key value pairs.
When you create a new instance the Keycloak CR spec.bootstrapAdmin stanza may be used to configure the bootstrap user and/or service account. If you do not specify anything for the spec.bootstrapAdmin, the operator will create a Secret named "metadata.name"-initial-admin with a username temp-admin and a generated password. If you specify a Secret name for the bootstrap admin user, then the Secret will need to contain `username` and `password` key value pairs. If you specify a Secret name for bootstrap admin service account, then the Secret will need to contain `client-id` and `client-secret` key value pairs.
If a master realm has already been created for you cluster, then the spec.boostrapAdmin is effectively ignored. If you need to create a recovery admin account, then you'll need to run the CLI command against a Pod directly.
If a master realm has already been created for your cluster, then the spec.boostrapAdmin is effectively ignored. If you need to create a recovery admin account, then you'll need to run the CLI command against a Pod directly.
For more information on how to bootstrap a temporary admin user or service account and recover lost admin access, refer to the <@links.server id="bootstrap-admin-recovery"/> guide.
@ -438,8 +438,8 @@ For a concrete example, let's imagine we have a {project_name} deployment runnin
Users have to access {project_name} to login, so {project_name} must be accessible from the Internet.
To make this example more interesting, let's assume the {project_name} is monitored too.
The monitoring is enabled as described in the OpenShift documentation page:
https://docs.openshift.com/container-platform/4.12/observability/monitoring/enabling-monitoring-for-user-defined-projects.html[enabling Monitoring for user defined projects].
The monitoring is enabled as described in this OpenShift documentation page:
https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/monitoring/configuring-user-workload-monitoring#enabling-monitoring-for-user-defined-projects_preparing-to-configure-the-monitoring-stack-uwm[enabling Monitoring for user defined projects].
Based on those requirements, the Keycloak CR would be like this (most parts are omitted, like DB connection and security):

4
docs/guides/operator/customizing-keycloak.adoc
View File

@ -22,7 +22,7 @@ To avoid this delay, you can provide a custom image with the augmentation built-
With a custom image, you can also specify the Keycloak _build-time_ configurations and extensions during the build of the container.
WARNING: When using optimized custom image, `health-enabled` and `metrics-enabled` options need to be explicitly set in the Containerfile.
WARNING: When using the optimized custom image, `health-enabled` and `metrics-enabled` options need to be explicitly set in the Containerfile.
For instructions on how to build such an image, see <@links.server id="containers"/>.
@ -52,7 +52,7 @@ Use the Keycloak CR for any configuration that requires Operator awareness, name
=== Non-optimized custom image
While it is considered a best practice use a pre-augmented image, if you want to use a non-optimized custom image or build time properties with an augmented image that is still possible. You just need set the `startOptimized` field to `false` as shown in this example:
While it is considered a best practice to use a pre-augmented image, if you want to use a non-optimized custom image or build time properties with an augmented image that is still possible. You just need set the `startOptimized` field to `false` as shown in this example:
[source,yaml]
----

2
docs/guides/operator/installation.adoc
View File

@ -128,7 +128,7 @@ If you do this please be aware:
- CRD revisions from newer Operator versions won't introduce breaking changes except for the eventual removal of fields that have been well deprecated. Thus newer CRDs are generally backward compatible.
- the CRDs installed last will be the ones in use. This applies to OLM installations as well where the Operator version, that is installed as the last, also installs and overrides the CRDs if they exists in the cluster already.
- older CRDs may not be forwards compatible with new fields used by newer operators. When using OLM it will check if your custom resources are compatible with the CRDs being installed, so the usage of new fields can prevent the simultaneous installation of older operator versions.
- fields introduced by newer CRDs will not be supported by older Operators. Older Operator will fail to handle CRs that use such new fields with an error deserializing an unrecognized field.
- fields introduced by newer CRDs will not be supported by older Operators. Older operators will fail to handle CRs that use such new fields with an error deserializing an unrecognized field.
It is therefore recommended in a multiple Operator install scenario that you keep versions aligned as closely as possible to minimize the potential problems with different versions.

2
docs/guides/operator/rolling-updates.adoc
View File

@ -55,7 +55,7 @@ When the image field changes, the Operator scales down the StatefulSet before ap
|On incompatible changes
|The {project_name} Operator detects if a rolling or recreate update is possible.
In the current version, {project_name} performs rolling update if the {project_name} version is the same for the old and the new image.
In the current version, {project_name} performs a rolling update if the {project_name} version is the same for the old and the new image.
Future versions of {project_name} will change that behavior and use additional information from the configuration, the image and the version to determine if a rolling update is possible to reduce downtimes.
|`Explicit`