Liveness and readiness probes tell Kubernetes whether a pod is running and ready to do some work. An enterprise application can probe the status of an application via HTTP. If no HTTP endpoint is exposed, Kubernetes can also probe by executing commands.
WildFly ships with the useful
jboss-cli.sh. This CLI retrieves information about the server and deployment states as follows:
$> ./jboss-cli.sh --connect --commands="ls" [...] process-type=Server product-name=WildFly Full product-version=11.0.0.Final [...] server-state=running suspend-state=RUNNING uuid=c52658a9-ca39-4548-9879-162cd6e14d93
We can combine a shell command to check for running servers:
./jboss-cli.sh --connect --commands=ls | grep "server-state=running"
A similar command gives us the deployed applications:
$> ./jboss-cli.sh --connect --commands="ls deployment" hello.war
We compose a shell command again to check whether our application has been deployed successfully:
./jboss-cli.sh --connect --commands="ls deployment" | grep "hello.war"
Now let’s insert these commands into the YAML descriptor:
... containers: - name: hello-joker image: docker.example.com/hello:1 imagePullPolicy: IfNotPresent livenessProbe: exec: command: - /bin/sh - -c - /opt/jboss/wildfly/bin/jboss-cli.sh --connect --commands=ls | grep 'server-state=running' readinessProbe: exec: command: - /bin/sh - -c - /opt/jboss/wildfly/bin/jboss-cli.sh --connect --commands='ls deployment' | grep 'hello.war' ...
If your application emits status or “ping” resources, the easier way is to probe the pod via HTTP as shown in this post.
Happy application probing!