diff --git a/openshift-openj9/master.adoc b/openshift-openj9/master.adoc index b8e5ae40bc..1956f2849d 100644 --- a/openshift-openj9/master.adoc +++ b/openshift-openj9/master.adoc @@ -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} diff --git a/openshift/master.adoc b/openshift/master.adoc index 2d2e3dd385..c69408cc87 100644 --- a/openshift/master.adoc +++ b/openshift/master.adoc @@ -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} diff --git a/openshift/topics/advanced_concepts.adoc b/openshift/topics/advanced_concepts.adoc index 634e4b6e8c..6dec272775 100644 --- a/openshift/topics/advanced_concepts.adoc +++ b/openshift/topics/advanced_concepts.adoc @@ -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. diff --git a/openshift/topics/get_started.adoc b/openshift/topics/get_started.adoc index 233ffb235b..b4a001854c 100644 --- a/openshift/topics/get_started.adoc +++ b/openshift/topics/get_started.adoc @@ -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: diff --git a/openshift/topics/introduction.adoc b/openshift/topics/introduction.adoc index 8e24979433..3360253e9e 100644 --- a/openshift/topics/introduction.adoc +++ b/openshift/topics/introduction.adoc @@ -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: diff --git a/openshift/topics/reference.adoc b/openshift/topics/reference.adoc index 65caba0542..da2451b183 100644 --- a/openshift/topics/reference.adoc +++ b/openshift/topics/reference.adoc @@ -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 diff --git a/openshift/topics/tutorials.adoc b/openshift/topics/tutorials.adoc index 0011def895..dc38fbc539 100644 --- a/openshift/topics/tutorials.adoc +++ b/openshift/topics/tutorials.adoc @@ -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 `_USERNAME` and `_DATABASE` with the actual database credentials retrieved xref:get-db-credentials[in previous section]. Also use value of `_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 _DATABASE -u _USERNAME -p < /tmp/keycloak-database-update.sql -Enter password: -sh-4.2$ echo $? -0 ----- -+ -[IMPORTANT] -==== -Replace `_USERNAME` and `_DATABASE` with the actual database credentials retrieved xref:get-db-credentials[in previous section]. Also use value of `_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_* ==== diff --git a/topics/templates/document-attributes-product.adoc b/topics/templates/document-attributes-product.adoc index 2e16eda7e4..4848494482 100644 --- a/topics/templates/document-attributes-product.adoc +++ b/topics/templates/document-attributes-product.adoc @@ -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/