KEYCLOAK-13364 Remove Mysql templates, add instructions for including custom JDBC driver
This commit is contained in:
Hynek Mlnarik
Hynek Mlnařík
parent
ee167f8f81
commit
0835d23d16
8 changed files with 100 additions and 136 deletions
|
|
@ -8,6 +8,7 @@ include::topics/templates/document-attributes-product.adoc[]
|
|||
:project_templates_version: {openshift_openj9_project_templates_version}
|
||||
:openshift_name: {openshift_openj9_name}
|
||||
:openshift_link: {openshift_openj9_link}
|
||||
:openshift_image: {openshift_openj9_image}
|
||||
:openshift_image_platforms: {openshift_openj9_platforms}
|
||||
:openshift_name_other: {openshift_openjdk_name}
|
||||
:openshift_link_other: {openshift_openjdk_link}
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ include::topics/templates/document-attributes-product.adoc[]
|
|||
:openshift_name: {openshift_openjdk_name}
|
||||
:openshift_link: {openshift_openjdk_link}
|
||||
:openshift_image_platforms: {openshift_openjdk_platforms}
|
||||
:openshift_image: {openshift_openjdk_image}
|
||||
:openshift_name_other: {openshift_openj9_name}
|
||||
:openshift_link_other: {openshift_openj9_link}
|
||||
|
||||
|
|
|
|||
|
|
@ -282,12 +282,76 @@ route "sso" patched
|
|||
----
|
||||
|
||||
[[sso-connecting-to-an-external-database]]
|
||||
==== Connecting to an external database
|
||||
=== Connecting to an external database
|
||||
|
||||
{project_name} can be configured to connect to an external (to OpenShift cluster) database. In order to achieve this, you need to modify the `sso-{database name}` Endpoints object to point to the proper address. The procedure is described in the https://docs.openshift.com/container-platform/latest/networking/configuring-ingress-cluster-traffic/configuring-ingress-cluster-traffic-service-external-ip.html#nw-service-external-ip_configuring-ingress-cluster-traffic-service-external-ip[OpenShift manual].
|
||||
|
||||
Tip: The easiest way to get started is to deploy {project_name} from a template and then modify the Endpoints object. You might also need to update some of the datasource configuration variables in the DeploymentConfig. Once you're done, just roll a new deployment out.
|
||||
|
||||
[[sso-using-custom-jdbc-driver]]
|
||||
=== Using Custom JDBC Driver
|
||||
|
||||
To connect to any database, the JDBC driver for that database must be present and {project_name} configured
|
||||
properly. Currently, the only JDBC driver available in the image is the PostgreSQL JDBC driver. For any other
|
||||
database, you need to extend the {project_name} image with a custom JDBC driver and a CLI script to register
|
||||
it and set up the connection properties. The following steps illustrate how to do that, taking MariaDB driver
|
||||
as an example. Update the example for other database drivers accordingly.
|
||||
|
||||
. Create an empty directory.
|
||||
. Download the JDBC driver binaries into this directory.
|
||||
. Create a new `Dockerfile` file in this directory with the following contents. For other databases, replace `mariadb-java-client-2.5.4.jar` with the filename of the respective driver:
|
||||
+
|
||||
[source,subs="attributes+,macros+,+quotes"]
|
||||
----
|
||||
*FROM* {openshift_image}:latest
|
||||
|
||||
*COPY* sso-extensions.cli /opt/eap/extensions/
|
||||
*COPY* mariadb-java-client-2.5.4.jar /opt/eap/extensions/jdbc-driver.jar
|
||||
----
|
||||
. Create a new `sso-extensions.cli` file in this directory with the following contents. Update the values of the variables in italics according to the deployment needs:
|
||||
+
|
||||
[source,bash,subs="attributes+,macros+,+quotes"]
|
||||
----
|
||||
batch
|
||||
|
||||
set DB_DRIVER_NAME=_mariadb_
|
||||
set DB_USERNAME=_username_
|
||||
set DB_PASSWORD=_password_
|
||||
set DB_DRIVER=_org.mariadb.jdbc.Driver_
|
||||
set DB_XA_DRIVER=_org.mariadb.jdbc.MariaDbDataSource_
|
||||
set DB_JDBC_URL=_jdbc:mariadb://jdbc-host/keycloak_
|
||||
set DB_EAP_MODULE=_org.mariadb_
|
||||
|
||||
set FILE=/opt/eap/extensions/jdbc-driver.jar
|
||||
|
||||
module add --name=$DB_EAP_MODULE --resources=$FILE --dependencies=javax.api,javax.resource.api
|
||||
/subsystem=datasources/jdbc-driver=$DB_DRIVER_NAME:add( \
|
||||
driver-name=$DB_DRIVER_NAME, \
|
||||
driver-module-name=$DB_EAP_MODULE, \
|
||||
driver-class-name=$DB_DRIVER, \
|
||||
driver-xa-datasource-class-name=$DB_XA_DRIVER \
|
||||
)
|
||||
/subsystem=datasources/data-source=KeycloakDS:remove()
|
||||
/subsystem=datasources/data-source=KeycloakDS:add( \
|
||||
jndi-name=java:jboss/datasources/KeycloakDS, \
|
||||
enabled=true, \
|
||||
use-java-context=true, \
|
||||
connection-url=$DB_JDBC_URL, \
|
||||
driver-name=$DB_DRIVER_NAME, \
|
||||
user-name=$DB_USERNAME, \
|
||||
password=$DB_PASSWORD \
|
||||
)
|
||||
|
||||
run-batch
|
||||
----
|
||||
. In this directory, build your image by typing the following command, replacing the `project/name:tag` with arbitrary name. `docker` can be used instead of `podman`.
|
||||
+
|
||||
[source,bash,subs="attributes+,macros+,+quotes"]
|
||||
----
|
||||
podman build -t docker-registry-default/project/name:tag .
|
||||
----
|
||||
. After the build finishes, push your image to the registry used by OpenShift to deploy your image. Refer to the https://docs.openshift.com/container-platform/latest/registry/accessing-the-registry.html#registry-accessing-directly_accessing-the-registry[OpenShift guide] for details.
|
||||
|
||||
[[sso-administrator-setup]]
|
||||
=== Creating the Administrator Account for {project_name} Server
|
||||
|
||||
|
|
@ -317,9 +381,9 @@ When deploying {project_name} application template, the *_SSO_ADMIN_USERNAME_* a
|
|||
====
|
||||
The lifespan of the {project_name} server's administrator account depends upon the storage type used to store the {project_name} server's database:
|
||||
|
||||
* For an in-memory database mode (*_{project_templates_version}-https_* and *_{project_templates_version}-x509-https_* templates) the account exists throughout the lifecycle of the particular {project_name} pod (stored account data is lost upon pod destruction),
|
||||
* For an ephemeral database mode (*_{project_templates_version}-mysql_* and *_{project_templates_version}-postgresql_* templates) the account exists throughout the lifecycle of the database pod (even if the {project_name} pod is destructed, the stored account data is preserved under the assumption that the database pod is still running),
|
||||
* For persistent database mode (*_{project_templates_version}-mysql-persistent_*, *_{project_templates_version}-x509-mysql-persistent_*, *_{project_templates_version}-postgresql-persistent_*, and *_{project_templates_version}-x509-postgresql-persistent_* templates) the account exists throughout the lifecycle of the persistent medium used to hold the database data. This means that the stored account data is preserved even when both the {project_name} and the database pods are destructed.
|
||||
* For an in-memory database mode (*_{project_templates_version}-https_* and *_{project_templates_version}-x509-https_* templates), the account exists throughout the lifecycle of the particular {project_name} pod (stored account data is lost upon pod destruction),
|
||||
* For an ephemeral database mode *_{project_templates_version}-postgresql_* templates), the account exists throughout the lifecycle of the database pod. Even if the {project_name} pod is destructed, the stored account data is preserved under the assumption that the database pod is still running,
|
||||
* For persistent database mode (*_{project_templates_version}-postgresql-persistent_*, and *_{project_templates_version}-x509-postgresql-persistent_* templates), the account exists throughout the lifecycle of the persistent medium used to hold the database data. This means that the stored account data is preserved even when both the {project_name} and the database pods are destructed.
|
||||
|
||||
It is a common practice to deploy an {project_name} application template to get the corresponding OpenShift deployment config for the application, and then reuse that deployment config multiple times (every time a new {project_name} application needs to be instantiated).
|
||||
====
|
||||
|
|
@ -339,7 +403,7 @@ Run the following commands to prepare the previously created deployment config o
|
|||
----
|
||||
$ oc get dc -o name
|
||||
deploymentconfig/sso
|
||||
deploymentconfig/sso-mysql
|
||||
deploymentconfig/sso-postgresql
|
||||
----
|
||||
. Clear the *_SSO_ADMIN_USERNAME_* and *_SSO_ADMIN_PASSWORD_* variables setting.
|
||||
+
|
||||
|
|
@ -361,9 +425,9 @@ Run following commands to create an administrator account for the `master` realm
|
|||
[source,bash,subs="attributes+,macros+"]
|
||||
----
|
||||
$ oc get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
sso-12-pt93n 1/1 Running 0 1m
|
||||
sso-mysql-6-d97pf 1/1 Running 0 2m
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
sso-12-pt93n 1/1 Running 0 1m
|
||||
sso-postgresql-6-d97pf 1/1 Running 0 2m
|
||||
----
|
||||
. Open a remote shell session to the {project_openshift_product_name} container.
|
||||
+
|
||||
|
|
@ -414,11 +478,8 @@ You can change the default behavior of the {project_name} image such as enabling
|
|||
|
||||
This procedure assumes that the {project_openshift_product_name} image has been previously link:https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.3/html-single/red_hat_single_sign-on_for_openshift/index#Example-Deploying-SSO[deployed using one of the following templates:]
|
||||
|
||||
* *_{project_templates_version}-mysql_*
|
||||
* *_{project_templates_version}-mysql-persistent_*
|
||||
* *_{project_templates_version}-postgresql_*
|
||||
* *_{project_templates_version}-postgresql-persistent_*
|
||||
* *_{project_templates_version}-x509-mysql-persistent_*
|
||||
* *_{project_templates_version}-x509-postgresql-persistent_*
|
||||
|
||||
.Procedure
|
||||
|
|
@ -441,7 +502,7 @@ If you use the CLI, use the following commands to enable TechPreview features wh
|
|||
----
|
||||
$ oc get dc -o name
|
||||
deploymentconfig/sso
|
||||
deploymentconfig/sso-mysql
|
||||
deploymentconfig/sso-postgresql
|
||||
|
||||
$ oc scale --replicas=0 dc sso
|
||||
deploymentconfig "sso" scaled
|
||||
|
|
@ -450,7 +511,7 @@ deploymentconfig "sso" scaled
|
|||
+
|
||||
[NOTE]
|
||||
====
|
||||
In the preceding command, ``sso-mysql`` appears because a MySQL template was used to deploy the {project_openshift_product_name} image. However, if a PostgreSQL template was used, the name of the deployment config of the PostgreSQL pod would be ``sso-postgresql``.
|
||||
In the preceding command, ``sso-postgresql`` appears because a PostgreSQL template was used to deploy the {project_openshift_product_name} image.
|
||||
====
|
||||
|
||||
. Edit the deployment config to set the JAVA_OPTS_APPEND variable. For example, to enable TechPreview features, you set the variable as follows:
|
||||
|
|
@ -475,7 +536,7 @@ deploymentconfig "sso" scaled
|
|||
|
||||
=== Deployment Process
|
||||
|
||||
Once deployed, the *_{project_templates_version}-https_* and *_{project_templates_version}-x509-https_* templates create a single pod that contains both the database and the {project_name} servers. The *_{project_templates_version}-mysql_*, *_{project_templates_version}-mysql-persistent_*, *_{project_templates_version}-x509-mysql-persistent_*, *_{project_templates_version}-postgresql_*, *_{project_templates_version}-postgresql-persistent_*, and *_{project_templates_version}-x509-postgresql-persistent_* templates create two pods, one for the database server and one for the {project_name} web server.
|
||||
Once deployed, the *_{project_templates_version}-https_* and *_{project_templates_version}-x509-https_* templates create a single pod that contains both the database and the {project_name} servers. The *_{project_templates_version}-postgresql_*, *_{project_templates_version}-postgresql-persistent_*, and *_{project_templates_version}-x509-postgresql-persistent_* templates create two pods, one for the database server and one for the {project_name} web server.
|
||||
|
||||
After the {project_name} web server pod has started, it can be accessed at its custom configured hostnames, or at the default hostnames:
|
||||
|
||||
|
|
@ -597,10 +658,10 @@ See xref:Example-EAP-Manual[Example Workflow: Manually Configure an Application
|
|||
=== Using {project_name} vault with OpenShift secrets
|
||||
Several fields in the {project_name} administration support obtaining the value
|
||||
of a secret from an external vault, see link:{adminguide_link}#_vault-administration[{adminguide_name}].
|
||||
The following example shows how to set up the files plaintext vault in OpenShift
|
||||
and set it up to be used for obtaining SMTP password.
|
||||
The following example shows how to set up the files plaintext vault in OpenShift
|
||||
and set it up to be used for obtaining an SMTP password.
|
||||
|
||||
. Specify a directory for the vault using the *_SSO_VAULT_DIR_* environment variable.
|
||||
. Specify a directory for the vault using the *_SSO_VAULT_DIR_* environment variable.
|
||||
You can introduce the *_SSO_VAULT_DIR_* environment variable directly in the environment in your deployment configuration. It can also be included in the template by addding the following snippets at the appropriate places in the template:
|
||||
+
|
||||
[source,json,subs="attributes+,macros+"]
|
||||
|
|
@ -649,9 +710,9 @@ For a deployment that is already running:
|
|||
oc set volume dc/sso --add --mount-path=${SSO_VAULT_DIR} --secret-name=rhsso-vault-secrets
|
||||
----
|
||||
|
||||
. After a pod is created you can use a customized string within your {project_name}
|
||||
configuration to refer to the secret. For example, for using `mySMTPPsswd` secret
|
||||
created in this tutorial, you can use `${vault.smtp-password}` within the `master`
|
||||
. After a pod is created you can use a customized string within your {project_name}
|
||||
configuration to refer to the secret. For example, for using `mySMTPPsswd` secret
|
||||
created in this tutorial, you can use `${vault.smtp-password}` within the `master`
|
||||
realm in the configuration of the smtp password and it will be replaced by `mySMTPPsswd` when used.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -34,12 +34,9 @@ $ oc login -u system:admin
|
|||
----
|
||||
$ for resource in {project_templates_version}-image-stream.json \
|
||||
{project_templates_version}-https.json \
|
||||
{project_templates_version}-mysql.json \
|
||||
{project_templates_version}-mysql-persistent.json \
|
||||
{project_templates_version}-postgresql.json \
|
||||
{project_templates_version}-postgresql-persistent.json \
|
||||
{project_templates_version}-x509-https.json \
|
||||
{project_templates_version}-x509-mysql-persistent.json \
|
||||
{project_templates_version}-x509-postgresql-persistent.json
|
||||
do
|
||||
oc replace -n openshift --force -f \
|
||||
|
|
@ -82,12 +79,9 @@ $ oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default
|
|||
----
|
||||
$ oc get templates -n openshift -o name | grep -o '{project_templates_version}.\+'
|
||||
{project_templates_version}-https
|
||||
{project_templates_version}-mysql
|
||||
{project_templates_version}-mysql-persistent
|
||||
{project_templates_version}-postgresql
|
||||
{project_templates_version}-postgresql-persistent
|
||||
{project_templates_version}-x509-https
|
||||
{project_templates_version}-x509-mysql-persistent
|
||||
{project_templates_version}-x509-postgresql-persistent
|
||||
----
|
||||
. Deploy the selected one:
|
||||
|
|
|
|||
|
|
@ -12,16 +12,16 @@ Red Hat offers multiple OpenShift application templates utilizing the {project_o
|
|||
* Templates using HTTPS and JGroups keystores and a truststore for the {project_name} server, all prepared beforehand. These secure the TLS communication using link:https://docs.openshift.com/container-platform/latest/architecture/networking/routes.html#passthrough-termination[passthrough TLS termination]:
|
||||
|
||||
** *_{project_templates_version}-https_*: {project_name} {project_version} backed by internal H2 database on the same pod.
|
||||
** *_{project_templates_version}-mysql_*: {project_name} {project_version} backed by ephemeral MySQL database on a separate pod.
|
||||
** *_{project_templates_version}-mysql-persistent_*: {project_name} {project_version} backed by persistent MySQL database on a separate pod.
|
||||
** *_{project_templates_version}-postgresql_*: {project_name} {project_version} backed by ephemeral PostgreSQL database on a separate pod.
|
||||
** *_{project_templates_version}-postgresql-persistent_*: {project_name} {project_version} backed by persistent PostgreSQL database on a separate pod.
|
||||
|
||||
[NOTE]
|
||||
Templates for using {project_name} with MySQL / MariaDB databases have been removed and are not available since {project_name} version 7.4.
|
||||
|
||||
[[reencrypt-templates]]
|
||||
* Templates using OpenShift's internal link:https://docs.openshift.com/container-platform/latest/dev_guide/secrets.html#service-serving-certificate-secrets[service serving x509 certificate secrets] to automatically create the HTTPS keystore used for serving secure content. The JGroups cluster traffic is authenticated using the `AUTH` protocol and encrypted using the `ASYM_ENCRYPT` protocol. The {project_name} server truststore is also created automatically, containing the */var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt* CA certificate file, which is used to sign the certificate for HTTPS keystore. Moreover, the truststore for the {project_name} server is pre-populated with the all known, trusted CA certificate files found in the Java system path. These templates secure the TLS communication using link:https://docs.openshift.com/container-platform/latest/architecture/networking/routes.html#re-encryption-termination[re-encryption TLS termination]:
|
||||
|
||||
** *_{project_templates_version}-x509-https_*: {project_name} {project_version} with auto-generated HTTPS keystore and {project_name} truststore, backed by internal H2 database. The `ASYM_ENCRYPT` JGroups protocol is used for encryption of cluster traffic.
|
||||
** *_{project_templates_version}-x509-mysql-persistent_*: {project_name} {project_version} with auto-generated HTTPS keystore and {project_name} truststore, backed by persistent MySQL database. The `ASYM_ENCRYPT` JGroups protocol is used for encryption of cluster traffic.
|
||||
** *_{project_templates_version}-x509-postgresql-persistent_*: {project_name} {project_version} with auto-generated HTTPS keystore and {project_name} truststore, backed by persistent PostgreSQL database. The `ASYM_ENCRYPT` JGroups protocol is used for encryption of cluster traffic.
|
||||
|
||||
Other templates that integrate with {project_name} are also available:
|
||||
|
|
|
|||
|
|
@ -367,7 +367,7 @@ for {project_openshift_product_name} can combine the xref:conf_env_vars[aforemen
|
|||
configuration variables] with common OpenShift variables (for example
|
||||
*_APPLICATION_NAME_* or *_SOURCE_REPOSITORY_URL_*), product specific variables
|
||||
(e.g. *_HORNETQ_CLUSTER_PASSWORD_*), or configuration variables typical to
|
||||
database images (e.g. *_MYSQL_FT_MAX_WORD_LEN_*) yet. All of these different
|
||||
database images (e.g. *_POSTGRESQL_MAX_CONNECTIONS_*) yet. All of these different
|
||||
types of configuration variables can be adjusted as desired to achieve the
|
||||
deployed {project_name}-enabled application will align with the intended use case as much
|
||||
as possible. The list of configuration variables, available for each category
|
||||
|
|
@ -477,40 +477,6 @@ if this environment variable is provided.
|
|||
|The password for the truststore and certificate.
|
||||
|===
|
||||
|
||||
==== Template variables specific to *_{project_templates_version}-mysql_*, *_{project_templates_version}-mysql-persistent_*, and *_{project_templates_version}-x509-mysql-persistent_*
|
||||
|
||||
.Configuration Variables Specific To {project_name}-enabled MySQL Applications With Ephemeral Or Persistent Storage
|
||||
[cols="2*", options="header"]
|
||||
|===
|
||||
|Variable
|
||||
|Description
|
||||
|*_DB_USERNAME_*
|
||||
|Database user name.
|
||||
|
||||
|*_DB_PASSWORD_*
|
||||
|Database user password.
|
||||
|
||||
|*_DB_JNDI_*
|
||||
|Database JNDI name used by application to resolve the datasource,
|
||||
e.g. _java:/jboss/datasources/mysql_.
|
||||
|
||||
|*_MYSQL_AIO_*
|
||||
|Controls the _innodb_use_native_aio_ setting value if the native AIO is
|
||||
broken.
|
||||
|
||||
|*_MYSQL_FT_MAX_WORD_LEN_*
|
||||
|The maximum length of the word to be included in a FULLTEXT index.
|
||||
|
||||
|*_MYSQL_FT_MIN_WORD_LEN_*
|
||||
|The minimum length of the word to be included in a FULLTEXT index.
|
||||
|
||||
|*_MYSQL_LOWER_CASE_TABLE_NAMES_*
|
||||
|Sets how the table names are stored and compared.
|
||||
|
||||
|*_MYSQL_MAX_CONNECTIONS_*
|
||||
|The maximum permitted number of simultaneous client connections.
|
||||
|===
|
||||
|
||||
==== Template variables specific to *_{project_templates_version}-postgresql_*, *_{project_templates_version}-postgresql-persistent_*, and *_{project_templates_version}-x509-postgresql-persistent_*
|
||||
|
||||
.Configuration Variables Specific To {project_name}-enabled PostgreSQL Applications With Ephemeral Or Persistent Storage
|
||||
|
|
@ -536,17 +502,6 @@ number of prepared transactions.
|
|||
|Configures how much memory is dedicated to PostgreSQL for caching data.
|
||||
|===
|
||||
|
||||
==== Template variables specific to *_{project_templates_version}-mysql-persistent_*, *_{project_templates_version}-x509-mysql-persistent_*, *_{project_templates_version}-postgresql-persistent_*, and *_{project_templates_version}-x509-postgresql-persistent_*
|
||||
|
||||
.Configuration Variables Specific To {project_name}-enabled MySQL / PostgreSQL Applications With Persistent Storage
|
||||
[cols="2*", options="header"]
|
||||
|===
|
||||
|Variable
|
||||
|Description
|
||||
|*_VOLUME_CAPACITY_*
|
||||
|Size of persistent storage for database volume.
|
||||
|===
|
||||
|
||||
==== Template variables for general *eap64* and *eap71* S2I images
|
||||
|
||||
.Configuration Variables For EAP 6.4 and EAP 7 Applications Built Via S2I
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ By default the database is automatically migrated when you start {project_name}
|
|||
|
||||
[[automatic-db-migration]]
|
||||
==== Automatic Database Migration
|
||||
This process assumes that you are link:{openshift_link}#Example-Deploying-SSO[running] some previous version of the {project_openshift_product_name} image, backed by MySQL or PostgreSQL database (deployed in ephemeral or persistent mode), running on a separate pod.
|
||||
This process assumes that you are link:{openshift_link}#Example-Deploying-SSO[running] some previous version of the {project_openshift_product_name} image, backed by a PostgreSQL database (deployed in ephemeral or persistent mode), running in a separate pod.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
|
|
@ -97,7 +97,7 @@ See link:https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.
|
|||
The database migration process handles the data schema update and performs manipulation of the data, therefore, stop all pods running the previous version of the {project_openshift_product_name} image before dynamic generation of the SQL migration file.
|
||||
====
|
||||
|
||||
This process assumes that you are link:{openshift_link}#Example-Deploying-SSO[running] some previous version of the {project_openshift_product_name} image, backed by MySQL or PostgreSQL database (deployed in ephemeral or persistent mode), running on a separate pod.
|
||||
This process assumes that you are link:{openshift_link}#Example-Deploying-SSO[running] some previous version of the {project_openshift_product_name} image, backed by a PostgreSQL database (deployed in ephemeral or persistent mode), running on a separate pod.
|
||||
|
||||
Perform the following to generate and get the SQL migration file for the database:
|
||||
|
||||
|
|
@ -469,53 +469,6 @@ INSERT 0 1
|
|||
Replace `<PREFIX>_USERNAME` and `<PREFIX>_DATABASE` with the actual database credentials retrieved xref:get-db-credentials[in previous section]. Also use value of `<PREFIX>_PASSWORD` as the password for the database, when prompted.
|
||||
====
|
||||
... Close the shell session to the PostgreSQL pod. Continue with xref:image-change-trigger-update-step[updating image change trigger step].
|
||||
* Run the following commands if running some previous version of the {project_openshift_product_name} image, backed by the MySQL database deployed in ephemeral or persistent mode, running on a separate pod:
|
||||
... Given the pod situation similar to the following:
|
||||
+
|
||||
[source,bash,subs="attributes+,macros+"]
|
||||
----
|
||||
$ oc get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
sso-mysql-1-zvhk3 1/1 Running 0 1h
|
||||
job-to-migrate-db-to-{project_templates_version}-m202t 1/1 Running 0 11m
|
||||
{project_templates_version}-db-migration-image-1-build 0/1 Completed 0 13m
|
||||
----
|
||||
... Copy the generated SQL migration file to the MySQL pod.
|
||||
+
|
||||
[source,bash,subs="attributes+,macros+"]
|
||||
----
|
||||
$ oc rsync --no-perms=true ./db-update/ sso-mysql-1-zvhk3:/tmp
|
||||
sending incremental file list
|
||||
keycloak-database-update.sql
|
||||
|
||||
sent 24,718 bytes received 34 bytes 49,504.00 bytes/sec
|
||||
total size is 24,594 speedup is 0.99
|
||||
----
|
||||
... Start a shell session to the MySQL pod.
|
||||
+
|
||||
[source,bash,subs="attributes+,macros+"]
|
||||
----
|
||||
$ oc rsh sso-mysql-1-zvhk3
|
||||
sh-4.2$
|
||||
----
|
||||
... Use the `mysql` tool to apply database update manually.
|
||||
+
|
||||
[source,bash,subs="attributes+,macros+"]
|
||||
----
|
||||
sh-4.2$ alias mysql="/opt/rh/rh-mysql57/root/bin/mysql"
|
||||
sh-4.2$ mysql --version
|
||||
/opt/rh/rh-mysql57/root/bin/mysql Ver 14.14 Distrib 5.7.16, for Linux (x86_64) using EditLine wrapper
|
||||
sh-4.2$ mysql -D <PREFIX>_DATABASE -u <PREFIX>_USERNAME -p < /tmp/keycloak-database-update.sql
|
||||
Enter password:
|
||||
sh-4.2$ echo $?
|
||||
0
|
||||
----
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
Replace `<PREFIX>_USERNAME` and `<PREFIX>_DATABASE` with the actual database credentials retrieved xref:get-db-credentials[in previous section]. Also use value of `<PREFIX>_PASSWORD` as the password for the database, when prompted.
|
||||
====
|
||||
... Close the shell session to the MySQL pod. Continue with xref:image-change-trigger-update-step[updating image change trigger step].
|
||||
|
||||
[[image-change-trigger-update-step]]
|
||||
[start=12]
|
||||
|
|
@ -544,12 +497,12 @@ deploymentconfig "sso" scaled
|
|||
=== Example Workflow: Migrating The {project_name} Server's Database Across Environments
|
||||
This tutorial focuses on migrating the Red Hat Single Sign-On server database from one environment to another or migrating to a different database. It assumes steps described in xref:Preparing-SSO-Authentication-for-OpenShift-Deployment[Preparing {project_name} Authentication for OpenShift Deployment] section have been performed already.
|
||||
|
||||
==== Deploying the {project_name} MySQL Application Template
|
||||
==== Deploying the {project_name} PostgreSQL Application Template
|
||||
|
||||
. Log in to the OpenShift web console and select the _sso-app-demo_ project space.
|
||||
. Click *Add to project* to list the default image streams and templates.
|
||||
. Use the *Filter by keyword* search bar to limit the list to those that match _sso_. You may need to click *See all* to show the desired application template.
|
||||
. Select *_{project_templates_version}-mysql_* {project_name} application template. When deploying the template ensure to *keep the _SSO_REALM_ variable unset* (default value).
|
||||
. Select *_{project_templates_version}-postgresql_* {project_name} application template. When deploying the template ensure to *keep the _SSO_REALM_ variable unset* (default value).
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
|
|
@ -589,7 +542,7 @@ Upon their creation xref:sso-export-the-database[the database can be exported.]
|
|||
----
|
||||
$ oc get dc -o name
|
||||
deploymentconfig/sso
|
||||
deploymentconfig/sso-mysql
|
||||
deploymentconfig/sso-postgresql
|
||||
|
||||
$ oc scale --replicas=0 dc sso
|
||||
deploymentconfig "sso" scaled
|
||||
|
|
@ -616,9 +569,9 @@ deploymentconfig "sso" scaled
|
|||
[source,bash,subs="attributes+,macros+"]
|
||||
----
|
||||
$ oc get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
sso-4-ejr0k 1/1 Running 0 27m
|
||||
sso-mysql-1-ozzl0 1/1 Running 0 4h
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
sso-4-ejr0k 1/1 Running 0 27m
|
||||
sso-postgresql-1-ozzl0 1/1 Running 0 4h
|
||||
|
||||
$ oc logs sso-4-ejr0k | grep 'Export'
|
||||
09:24:59,503 INFO [org.keycloak.exportimport.singlefile.SingleFileExportProvider] (ServerService Thread Pool -- 57) Exporting model into file /tmp/demorealm-export.json
|
||||
|
|
@ -632,9 +585,9 @@ $ oc logs sso-4-ejr0k | grep 'Export'
|
|||
[source,bash,subs="attributes+,macros+"]
|
||||
----
|
||||
$ oc get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
sso-4-ejr0k 1/1 Running 0 2m
|
||||
sso-mysql-1-ozzl0 1/1 Running 0 4h
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
sso-4-ejr0k 1/1 Running 0 2m
|
||||
sso-postgresql-1-ozzl0 1/1 Running 0 4h
|
||||
|
||||
$ oc rsync sso-4-ejr0k:/tmp/demorealm-export.json .
|
||||
----
|
||||
|
|
@ -812,11 +765,8 @@ The following example uses both link:https://github.com/keycloak/keycloak-quicks
|
|||
====
|
||||
This guide assumes the {project_openshift_product_name} image has been previously link:{openshift_link}#Example-Deploying-SSO[deployed using one of the following templates:]
|
||||
|
||||
* *_{project_templates_version}-mysql_*
|
||||
* *_{project_templates_version}-mysql-persistent_*
|
||||
* *_{project_templates_version}-postgresql_*
|
||||
* *_{project_templates_version}-postgresql-persistent_*
|
||||
* *_{project_templates_version}-x509-mysql-persistent_*
|
||||
* *_{project_templates_version}-x509-postgresql-persistent_*
|
||||
====
|
||||
|
||||
|
|
|
|||
|
|
@ -52,10 +52,12 @@
|
|||
:openshift_openjdk_name: Red Hat Single Sign-On for OpenShift on OpenJDK
|
||||
:openshift_openjdk_link: {project_doc_base_url}/red_hat_single_sign-on_for_openshift/
|
||||
:openshift_openjdk_platforms: x86_64
|
||||
:openshift_openjdk_image: redhat-sso-7/sso74-openshift-rhel8
|
||||
:openshift_openjdk_project_templates_version: sso74
|
||||
:openshift_openj9_name: Red Hat Single Sign-On for OpenShift on OpenJ9
|
||||
:openshift_openj9_link: {project_doc_base_url}/red_hat_single_sign-on_for_openshift_on_openj9/
|
||||
:openshift_openj9_platforms: s390x
|
||||
:openshift_openj9_image: redhat-sso-7/sso74-openj9-openshift-rhel8
|
||||
:openshift_openj9_project_templates_version: sso74-openj9
|
||||
:installguide_name: Server Installation and Configuration Guide
|
||||
:installguide_link: {project_doc_base_url}/server_installation_and_configuration_guide/
|
||||
|
|
|
|||
Loading…
Reference in a new issue