This assumes you have already deployed JBOSS on OpenShift. If not, check out my article FreeKB - OpenShift - Getting Started with JBOSS on OpenShift.
By default, the logging.properties file in the JBOSS pod will have the following.
~]$ oc exec pod/eap74-openjdk8-openshift-rhel7-8d49d6bd7-j6blz -- cat /opt/eap/standalone/configuration/logging.properties
loggers=sun.rmi,org.jboss.as.config,io.jaegertracing.Configuration,com.arjuna
logger.level=INFO
logger.handlers=CONSOLE
logger.sun.rmi.level=WARN
logger.sun.rmi.useParentHandlers=true
logger.org.jboss.as.config.level=DEBUG
logger.org.jboss.as.config.useParentHandlers=true
logger.io.jaegertracing.Configuration.level=WARN
logger.io.jaegertracing.Configuration.useParentHandlers=true
logger.com.arjuna.level=WARN
logger.com.arjuna.useParentHandlers=true
handler.CONSOLE=org.jboss.logmanager.handlers.ConsoleHandler
handler.CONSOLE.level=ALL
handler.CONSOLE.formatter=COLOR-PATTERN
handler.CONSOLE.properties=autoFlush,target,enabled
handler.CONSOLE.autoFlush=true
handler.CONSOLE.target=SYSTEM_OUT
handler.CONSOLE.enabled=true
formatters=OPENSHIFT
formatter.COLOR-PATTERN=org.jboss.logmanager.formatters.PatternFormatter
formatter.COLOR-PATTERN.properties=pattern
formatter.COLOR-PATTERN.pattern=%K{level}%d{HH\:mm\:ss,SSS} %-5p [%c] (%t) %s%e%n
formatter.OPENSHIFT=org.jboss.logmanager.formatters.JsonFormatter
formatter.OPENSHIFT.properties=keyOverrides,exceptionOutputType,metaData,prettyPrint,printDetails,recordDelimiter
formatter.OPENSHIFT.constructorProperties=keyOverrides
formatter.OPENSHIFT.keyOverrides=timestamp\=@timestamp
formatter.OPENSHIFT.exceptionOutputType=FORMATTED
formatter.OPENSHIFT.metaData=@version\=1
formatter.OPENSHIFT.prettyPrint=false
formatter.OPENSHIFT.printDetails=false
formatter.OPENSHIFT.recordDelimiter=\n
If you want to make a permanent change to this file, let's start by creating a Persistent Volume Claim. I had to go with a Persistent Volume Claim instead of a Config Map because a Config Map gets mounted in the container read only but a Persistent Volume Claim can be mounted with write access, and the JBOSS container needs to be able to write to files in the /opt/eap/standalone/configuration directory. Check out these articles for my notes on how to create a Persistent Volume and Persistent Volume Claim.
For example, I created a Persistent Volume Claim named my-persistent-volume-claim that had Access Mode RWX (Read Write Many).
~]$ oc get pvc --output wide
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE VOLUMEMODE
my-persistent-volume-claim Bound pvc-2db07c57-e282-48e7-bfb1-4cbd7245c25e 1Gi RWX file-storage 3m29s Filesystem
You'll want to ensure that the JBOSS deployment/pod is running with a Security Context Constraint that allows Persistent Volumes to be mounted in the container. By default, if a pod is not associated with a specific Service Account that has been bound to a certain Security Context Constraint, the pod should have the restricted Security Context Constraint, which can be seen using the oc describe pod command.
~]$ oc describe pod my-app-kf7hf
Annotations: openshift.io/scc: restricted
The oc get securitycontextconstraints command can be used to see that the restricted Security Context Constraint has persistentVolumeClaim for VOLUMES. In other words, the pod is running with a Security Context Constraint that allows Persistent Volumes to be mounted in the container. If the pod is running with a Security Context Constraint that does not have persistentVolumeClaim for VOLUMES, check out my article FreeKB - OpenShift - Run a deployment with a Service Account and Security Context Constraint.
~]$ oc get securitycontextconstraints restricted
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES
restricted false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
Then I updated the JBOSS deployment to mount the Persistent Volume Claim to /var/data in the container. Check out my article FreeKB - OpenShift - Mount a Persistent Volume in a container for more details on how to mount a Persistent Volume Claim in a container. Here is a snippet of the deployment YAML with my-persistent-volume-claim mount to the /var/data directory in the JBOSS container.
apiVersion: apps/v1
kind: Deployment
metadata:
name: eap74-openjdk8-openshift-rhel7
spec:
template:
spec:
containers:
- name: eap74-openjdk8-openshift-rhel7
volumeMounts:
- mountPath: /var/data
name: my-volume
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: my-persistent-volume-claim
Then in the container I copied all of the files in the /opt/eap/standalone/configuration directory to the /var/data directory.
oc exec pod/eap74-openjdk8-openshift-rhel7-5c5486c667-lmzdm -- cp -R /opt/eap/standalone/configuration /var/data
Then I edited the deployment once again, replacing /var/data with /opt/eap/standalone/configuration so that the container has the files in my-persistent-volume-claim mounted to the /opt/eap/standalone/configuration directory in the container.
apiVersion: apps/v1
kind: Deployment
metadata:
name: eap74-openjdk8-openshift-rhel7
spec:
template:
spec:
containers:
- name: eap74-openjdk8-openshift-rhel7
volumeMounts:
- mountPath: /opt/eap/standalone/configuration
name: my-volume
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: my-persistent-volume-claim
At this point, I just want to make sure that the pod is Running and returning the JBOSS welcome page. So far, so good.
~]$ oc get pods
NAME READY STATUS RESTARTS AGE
eap74-openjdk8-openshift-rhel7-f68b66fc8-jfxww 1/1 Running 0 10m
Let's make some change to the /opt/eap/standalone/configuration/logging.properties file, such as changing logger.level=INFO to logger.level=DEBUG. The oc exec command can be used to create an interactive shell in the pod.
The cool thing here is that since the files in the /opt/eap/standalone/configuration directory are being mounted in the container via my-persistent-volume-claim, any change made to the files in the /opt/eap/standalone/configuration directory will be persistent, meaning the change will still be there if a new JBOSS pod gets spun up.
oc exec -it pod/eap74-openjdk8-openshift-rhel7-f68b66fc8-jfxww -- /bin/bash
The oc exec command can be used to verify that the logging.properties file in the pod contains whatever change you made to the file, such as having logger.level=DEBUG in this example.
~]$ oc exec pod/eap74-openjdk8-openshift-rhel7-8d49d6bd7-j6blz -- cat /opt/eap/standalone/configuration/logging.properties
loggers=sun.rmi,org.jboss.as.config,io.jaegertracing.Configuration,com.arjuna
logger.level=DEBUG
logger.handlers=CONSOLE
logger.sun.rmi.level=WARN
logger.sun.rmi.useParentHandlers=true
logger.org.jboss.as.config.level=DEBUG
logger.org.jboss.as.config.useParentHandlers=true
logger.io.jaegertracing.Configuration.level=WARN
logger.io.jaegertracing.Configuration.useParentHandlers=true
logger.com.arjuna.level=WARN
logger.com.arjuna.useParentHandlers=true
handler.CONSOLE=org.jboss.logmanager.handlers.ConsoleHandler
handler.CONSOLE.level=ALL
handler.CONSOLE.formatter=COLOR-PATTERN
handler.CONSOLE.properties=autoFlush,target,enabled
handler.CONSOLE.autoFlush=true
handler.CONSOLE.target=SYSTEM_OUT
handler.CONSOLE.enabled=true
formatters=OPENSHIFT
formatter.COLOR-PATTERN=org.jboss.logmanager.formatters.PatternFormatter
formatter.COLOR-PATTERN.properties=pattern
formatter.COLOR-PATTERN.pattern=%K{level}%d{HH\:mm\:ss,SSS} %-5p [%c] (%t) %s%e%n
formatter.OPENSHIFT=org.jboss.logmanager.formatters.JsonFormatter
formatter.OPENSHIFT.properties=keyOverrides,exceptionOutputType,metaData,prettyPrint,printDetails,recordDelimiter
formatter.OPENSHIFT.constructorProperties=keyOverrides
formatter.OPENSHIFT.keyOverrides=timestamp\=@timestamp
formatter.OPENSHIFT.exceptionOutputType=FORMATTED
formatter.OPENSHIFT.metaData=@version\=1
formatter.OPENSHIFT.prettyPrint=false
formatter.OPENSHIFT.printDetails=false
formatter.OPENSHIFT.recordDelimiter=\n
Did you find this article helpful?
If so, consider buying me a coffee over at 