1. Select the Docker Login tab and copy the command.
2. Run the docker login command on each host that pulls from registry.redhat.io.

3. Verify your Docker configuration.

   $ cat ~/.docker/config.json
   ...
   "registry.redhat.io": {
   			"auth": "MTEwMDkx..."
   		}

1. Log in to your OpenShift cluster.

2. Select your working project, for example:

   $ oc project rhdg-helloworld

3. Create a generic pull secret with your Docker configuration.

   $ oc create secret generic ${SECRET_NAME} \
     --from-file=.dockerconfigjson=path/to/.docker/config.json \
     --type=kubernetes.io/dockerconfigjson

4. Link the pull secret to your service account.

   $ oc secrets link default ${SECRET_NAME} --for=pull

5. Mount the secret.

   $ oc secrets link builder ${SECRET_NAME}

Procedure

1. Get service-ca.crt from Data Grid pods.

   $ oc rsync ${pod_name}:/var/run/secrets/kubernetes.io/serviceaccount/..data/service-ca.crt .

2. Pass service-ca.crt when you invoke REST calls.

   curl -X PUT \
     -u ${USERNAME}:${PASSWORD} \
     --cacert service-ca.crt \
     -H 'Content-type: text/plain' \
     -d 'world' \
     https://${HOSTNAME_FOR_HTTPS_ROUTE}/rest/default/hello

1. Set openshift.DNS_PING as the value for the JGROUPS_PING_PROTOCOL environment variable.

   JGROUPS_PING_PROTOCOL=openshift.DNS_PING

2. Specify the name of the ping service for the cluster as the value for the OPENSHIFT_DNS_PING_SERVICE_NAME environment variable.

   OPENSHIFT_DNS_PING_SERVICE_NAME=${PING_SERVICE_NAME}

3. Specify the port number where the ping service is exposed as the value for the OPENSHIFT_DNS_PING_SERVICE_PORT environment variable. The default value is 8888.

   OPENSHIFT_DNS_PING_SERVICE_PORT=${PING_SERVICE_NAME}

4. Define a ping service that exposes the ping port, as in the following example:

   apiVersion: v1
   kind: Service
   spec:
     clusterIP: None
     ports:
       - name: ping
         port: 8888
         protocol: TCP
         targetPort: 8888
     selector: deploymentConfig=datagrid-service
   metadata:
     annotations:
       description: The JGroups ping port for clustering.
       service.alpha.kubernetes.io/tolerate-unready-endpoints: 'true'

   Important

   You should configure clusterIP: None so that the service is headless. Likewise, the ping port must be named and include the service.alpha.kubernetes.io/tolerate-unready-endpoints: 'true' annotation.

1. Set openshift.KUBE_PING as the value for the JGROUPS_PING_PROTOCOL environment variable.

   JGROUPS_PING_PROTOCOL=openshift.KUBE_PING

2. Specify the OpenShift project name as the value for the OPENSHIFT_KUBE_PING_NAMESPACE environment variable. If you do not set this variable, the server behaves like a single-node cluster.

   OPENSHIFT_KUBE_PING_NAMESPACE=${PING_NAMESPACE}

3. Specify a cluster label with the OPENSHIFT_KUBE_PING_LABELS environment variable. If you do not set this variable, pods outside the application but in the same namespace attempt to join.

   OPENSHIFT_KUBE_PING_LABELS=labelKey=labelValue

4. Grant authorization to the service account the pod is running under so that it can access the Kubernetes REST API. For example, grant authorization to datagrid-service-account as follows:

   oc policy add-role-to-user view \
     system:serviceaccount:$(oc project -q):datagrid-service-account \
     -n $(oc project -q)

5. Ensure port 8888 is defined as a ping port on the pod container, as follows:

   ports:
       - containerPort: 8888
         name: ping
         protocol: TCP

1. Create a JGroups keystore (.jceks) that contains credentials to encrypt traffic.

   You can use the Java keytool to generate a JGroups keystore.

2. Deploy the JGroups keystore to OpenShift as a secret.

   1. Log in to your OpenShift cluster.

   2. Create a secret for the JGroups keystore. For example, to create a secret named jgroups-secret from a keystore named jgroups.jceks, do the following:

      $ oc create secret generic jgroups-secret \
        --from-file=jgroups.jceks

   3. Link the secret to the default service account.

      $ oc secrets link default jgroups-secret

   4. Mount the secret to the container.

      $ oc set volumes dc/datagrid \
        --add -t secret \
        --secret-name='jgroups-secret' \
        --mount-path='/keystores/jgroups'

3. Set the value of the JGROUPS_ENCRYPT_PROTOCOL environment variable to SYM_ENCRYPT for each node in the cluster.

4. Configure each node in the cluster to use the JGroups keystore with the following environment variables:

   JGROUPS_ENCRYPT_KEYSTORE

   Specifes the JGroups keystore for encrypting cluster traffic.

   JGROUPS_ENCRYPT_KEYSTORE_DIR

   Specifies the directory where the JGroups keystore resides.

   JGROUPS_ENCRYPT_SECRET

   Matches the OpenShift secret for the keystore.

   JGROUPS_ENCRYPT_NAME

   Matches the username for the keystore.

   JGROUPS_ENCRYPT_PASSWORD

   Matches the keystore password.

5. If required, set a password for nodes to use when joining the cluster with the JGROUPS_CLUSTER_PASSWORD environment variable.

1. Configure authentication with the JGROUPS_CLUSTER_PASSWORD environment variable.
2. Set the value of the JGROUPS_ENCRYPT_PROTOCOL environment variable to ASYM_ENCRYPT for each node in the cluster.

1. Confirm if the Data Grid for OpenShift image is available.

   $ oc get images | grep jboss-datagrid73-openshift

2. If the image is not available, create an image stream and import it.

   $ oc create -f https://raw.githubusercontent.com/jboss-container-images/jboss-datagrid-7-openshift-image/7.3-v1.9/templates/datagrid73-image-stream.json
   
   $ oc import-image jboss-datagrid73-openshift --from='registry.redhat.io/jboss-datagrid-7/datagrid73-openshift:1.9'

1. Create a new binary build using the Data Grid for OpenShift image.

   $ oc new-build jboss-datagrid73-openshift:1.9 --binary=true --name=custom-datagrid

2. Navigate to the s2i directory so you can pass --from-dir=".". You must include the configuration directory so that the S2I process can detect your custom configuration.

   To use the example configuration, do the following:

   $ cd jboss-datagrid-7-openshift-image/docs/examples/s2i/

3. Build the Data Grid for OpenShift image with your custom configuration.

   $ oc start-build custom-datagrid --from-dir="." --follow
   
   Uploading directory "." as binary input for the build ...
   
   ...
   Push successful

4. Check that your image is available.

   $ oc get images | grep custom-datagrid

1. Confirm that the build pod is running.

   $ oc get pods
   
   NAME                      READY     STATUS      RESTARTS   AGE
   custom-datagrid-1-build   0/1       Completed   0          38s

2. Create a Data Grid application with your custom configuration.

   $ oc new-app custom-datagrid \
     -p APPLICATION_USER=${USERNAME} \
     -p APPLICATION_PASSWORD=${PASSWORD}

3. Wait for your custom Data Grid application to start running.

   $ oc get pods -w
   
   NAME                      READY     STATUS         RESTARTS   AGE
   custom-datagrid-1-build   0/1       Completed      0          8m
   custom-datagrid-1-<id>   1/1       Running        0          11s

4. Remotely access the bash shell for your custom Data Grid pod.

   $ oc exec -it ${pod-name} -- /bin/bash

5. View clustered-openshift.xml to verify the configuration, for example:

   $ cat /opt/datagrid/configuration/clustered-openshift.xml

   If clustered-openshift.xml contains your custom configuration then the Data Grid pod is using it. You can optionally use the Data Grid command line interface to verify your configuration, for example:

   $ /opt/datagrid/bin/cli.sh -c

6. End the remote session after you verify your configuration.

   $ exit

1. Wait for your custom Data Grid application to start running.

   $ oc get pods -w
   
   NAME                READY     STATUS    RESTARTS   AGE
   user-config-0   0/1       Running   7          17m

2. Check the container logs.

   $ oc logs ${pod-name} | grep standalone.xml
   
   INFO Running jboss-datagrid-7/datagrid73-openshift image, version 1.9 with user standalone.xml

1. Specify the CUSTOM_INSTALL_DIRECTORIES environment variable in the image template JSON. This variable defines the location where S2I artifacts reside, as in the following example:

   {
       "name": "CUSTOM_INSTALL_DIRECTORIES",
       "value": "extensions/*"
   }

2. Create an install.sh script in that directory. This script installs the modules and drivers for the external datasource in the image.

   The following is an example install.sh script:

   #!/bin/bash
   
   # Import the common functions for
   # installing modules and configuring drivers
   source /usr/local/s2i/install-common.sh
   
   # Directory where this script is located
   injected_dir=$1
   
   # Install the modules for the datasource
   install_modules ${injected_dir}/modules
   
   # Configure the drivers for the datasource
   configure_drivers ${injected_dir}/drivers.properties

3. Include a modules subdirectory that contains a module.xml file and the driver for the datasource. The resulting image uses the module to load classes and define dependencies.

   As an example, you plan to use Derby as an external datasource. You need to obtain a driver such as derby-10.12.1.1.jar and place it in the following directory: modules/org/apache/derby/main/

   In the same directory, you also need to create a module.xml file that defines the driver as a resource and declares dependencies.

   The following is an example module.xml file:

   <?xml version="1.0" encoding="UTF-8"?>
   <module xmlns="urn:jboss:module:1.3" name="org.apache.derby">
    <resources>
      <resource-root path="derby-10.12.1.1.jar"/>
      <resource-root path="derbyclient-10.12.1.1.jar"/>
    </resources>
   
    <dependencies>
      <module name="javax.api"/>
      <module name="javax.transaction.api"/>
    </dependencies>
   </module>

4. Define the driver configuration properties in a drivers.property environment variable file.

   The following is an example drivers.property file:

   #DRIVERS
   DRIVERS=DERBY
   
   DERBY_DRIVER_NAME=derby
   DERBY_DRIVER_MODULE=org.apache.derby
   DERBY_DRIVER_CLASS=org.apache.derby.jdbc.EmbeddedDriver
   DERBY_XA_DATASOURCE_CLASS=org.apache.derby.jdbc.EmbeddedXADataSource

5. After you build and deploy the image, specify environment variables for the datasource.

   The following example shows a datasource definition with the DATASOURCES environment variable:

   # Set a unique prefix for the datasource
   DATASOURCES=ACCOUNTS_DERBY
   # Specify other environment variables using the prefix
   ACCOUNTS_DERBY_DATABASE=accounts
   ACCOUNTS_DERBY_JNDI=java:/accounts-ds
   ACCOUNTS_DERBY_DRIVER=derby
   ACCOUNTS_DERBY_JTA=true
   ACCOUNTS_DERBY_NONXA=false
   ACCOUNTS_DERBY_USERNAME=${USERNAME}
   ACCOUNTS_DERBY_PASSWORD=${PASSWORD}
   ACCOUNTS_DERBY_XA_CONNECTION_PROPERTY_DatabaseName=/opt/eap/standalone/data/databases/derby/accounts
   # _HOST and _PORT are required but not used
   ACCOUNTS_ORACLE_HOST=dummy
   ACCOUNTS_ORACLE_PORT=1527