Let's say something like this is being returned.
01:44:34,351 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0054: Admin console is not enabled
By default, the admin console listens for HTTP connections on port 9990 and HTTPS connection on port 9993, as can be seen in the standalone.xml or standalone-openshift.xml.
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
In the /opt/eap/standalone/configuration/standalone-openshift.xml in the JBOSS pod on OpenShift, you probably need to update console-enabled to "true". You would use management-http to enable the HTTP management console on port 9990 or management-https to enable the HTTPS management console on port 9993.
<management-interfaces>
<http-interface console-enabled="true">
<http-upgrade enabled="true"/>
<socket-binding http="management-http"/>
</http-interface>
</management-interfaces>
And let's update the deployment YAML to have ports 9990 and 9993. Assuming your deployment has RollingUpdate strategy, updating the deployment YAML should cause the current pod to be terminated and a new pod to be spawned.
spec:
strategy:
type: RollingUpdate
template:
spec:
containers:
image: registry.redhat.io/jboss-eap-7/eap74-openjdk8-openshift-rhel7@sha256:02160a5f66638faa74d44e7332925c3210d986e74bf256dd17d4876715e05ff9
name: eap74-openjdk8-openshift-rhel7
ports:
- containerPort: 8080
protocol: TCP
- containerPort: 8443
protocol: TCP
- containerPort: 8778
protocol: TCP
- containerPort: 9990
protocol: TCP
- containerPort: 9993
protocol: TCP
Or you can restart JBOSS. For example, you can scale the JBOSS deployment down to 0 replicas and then back up to 1 replica to restart the JBOSS pod. Check out my articles FreeKB - JBOSS - Getting Started with JBOSS on OpenShift and FreeKB - OpenShift - Temporarily change the number of pods (replicas) using the oc scale command.
~]$ oc scale deployment eap74-openjdk8-openshift-rhel7 --replicas 0
deployment.apps/eap74-openjdk8-openshift-rhel7 scaled
~]$ oc scale deployment eap74-openjdk8-openshift-rhel7 --replicas 1
deployment.apps/eap74-openjdk8-openshift-rhel7 scaled
The JBOSS logs should show that the management console is now enabled and listening for connections on port 9990 or 9993.
~]$ oc logs eap74-openjdk8-openshift-rhel7-5c899f4665-zwjqp
01:01:39,482 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://0.0.0.0:9993/management
01:01:39,482 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://0.0.0.0:9993
Deploy the hello-openshift pod
If find it makes the most sense to first try to submit a request using the socket (IP address and port) of the pod, because if the request isn't working using the IP address and port of the pod, then likewise the request using the Service or Route will probably also not work either.
Be aware that many pods use /bin/busybox and /bin/busybox does not contain curl. The hello-openshift image contains curl. Check out my article Check out my article FreeKB - OpenShift - Deploy Hello Openshift.
This also will be useful to determine if communication can occur across different projects / namespaces.
~]# oc new-project hello-openshift
~]# oc import-image openshift4/ose-hello-openshift-rhel8:v4.7.0-202205312157.p0.g7706ed4.assembly.stream --from=registry.redhat.io/openshift4/ose-hello-openshift-rhel8:v4.7.0-202205312157.p0.g7706ed4.assembly.stream --confirm
~]# oc new-app registry.example.com/openshift4/ose-hello-openshift-rhel8
~]$ oc exec pod/ose-hello-openshift-rhel8-5959c4fb77-zss6g -- curl --silent localhost:8080
Hello OpenShift!
Or if you are using the OpenShift console, in the left panel select Home > Projects, and select the hello-openshift project / namespace. Then select the hello-openshift pod, select the Terminal tab, and issue command curl localhost:8080 and “Hello OpenShift!” should be returned.
Network Policies
The oc get networkpolicies command can then be see if there are any ingress network policies denying incoming requests in the JBOSS project / namespace.
There is no need to use the oc get egressnetworkpolicies command since this issue is with ingress requests, not egress requests.
~]$ oc get networkpolicies
No resources found in my_project namespace.
Curl from Pod to Pod
The oc get pods command can be used to list the pods in JBOSS project / namespace.
~]$ oc get pods --namespace jboss
NAME READY STATUS RESTARTS AGE
eap74-openjdk8-openshift-rhel7-5c899f4665-qlqbh 1/1 Running 0 12m
And the oc describe command can be used to return the IP address the JBOSS pod is listening for connections on.
~]$ oc describe pod/eap74-openjdk8-openshift-rhel7-5c899f4665-qlqbh --namespace jboss | grep -i ^IP:
IP: 10.128.2.186
And the oc describe command can be used to return the ports the pod is listening for connections on. You'll want to ensure that port 9990 and/or 9993 are listed.
~]$ oc describe pod/eap74-openjdk8-openshift-rhel7-5c899f4665-qlqbh --namespace jboss | grep -i Ports
Ports: 8080/TCP, 8443/TCP, 8778/TCP, 9990/TCP, 9993/TCP
The JBOSS logs should show that the management console is enabled and listening for connections on port 9990 or 9993.
~]$ oc logs eap74-openjdk8-openshift-rhel7-5c899f4665-zwjqp --namespace jboss
01:01:39,482 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://0.0.0.0:9993/management
01:01:39,482 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://0.0.0.0:9993
Assuming there are no ingress network polices in the JBOSS project / namespace, let's use the hello-openshift pod to submit a request to the JBOSS pod using curl in the hello-openshift pod and using the socket (IP address and port) of the JBOSS pod.
In this example I get a response to the GET request. It doesn't really matter what the response is. You just want to see if you get a response. You are looking for response 200 OK or 302 Found. If you get something like Connection Refused or 404 Not Found, something is wrong.
~]$ oc exec pod/ose-hello-openshift-rhel8-5959c4fb77-9tdzw -n hello-openshift -- curl 10.128.2.186:9990 -v
* Rebuilt URL to: 10.128.2.186:9990/
* Trying 10.128.2.186...
* TCP_NODELAY set
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 10.128.2.186 (10.128.2.186) port 9990 (#0)
> GET / HTTP/1.1
> Host: 10.128.2.186:9990
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Connection: keep-alive
< Location: /console/index.html
< Content-Length: 0
< Date: Tue, 22 Oct 2024 01:13:24 GMT
<
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Connection #0 to host 10.128.2.186 left intact
If you get something like "Connection refused", this may mean that the JBOSS pod is unable to respond to your GET request. At this point, you'll need to look into this to determine why the JBOSS pod is unable to respond to your GET request.
~]$ oc exec pod/ose-hello-openshift-rhel8-5959c4fb77-9tdzw -n hello-openshift -- curl 10.128.2.186:9990 -v
* Failed to connect to 10.128.2.186 port 9990: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 10.128.2.186 port 9990: Connection refused
command terminated with exit code 7
Curl from Pod to Service
If you are able to get a response from the JBOSS pod, I would then next see if I can get a response using the Service that forwards requests onto the pod. Let's update the JBOSS Service to forwards requests onto the JBOSS pod on ports 9990 and 9993.
apiVersion: v1
kind: Service
metadata:
annotations:
openshift.io/generated-by: OpenShiftNewApp
creationTimestamp: "2024-08-27T01:19:28Z"
labels:
app: eap74-openjdk8-openshift-rhel7
app.kubernetes.io/component: eap74-openjdk8-openshift-rhel7
app.kubernetes.io/instance: eap74-openjdk8-openshift-rhel7
name: eap74-openjdk8-openshift-rhel7
namespace: jboss
resourceVersion: "337865813"
uid: a807ed0d-4de9-4d8e-90d5-5b6d6df84820
spec:
clusterIP: 172.30.46.75
clusterIPs:
- 172.30.46.75
internalTrafficPolicy: Cluster
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
ports:
- name: http
port: 8080
protocol: TCP
targetPort: 8080
- name: http-console
port: 9990
protocol: TCP
targetPort: 9990
- name: https-console
port: 9993
protocol: TCP
targetPort: 9993
selector:
deployment: eap74-openjdk8-openshift-rhel7
sessionAffinity: None
type: ClusterIP
In this example, since the service has Selector deployment: eap74-openjdk8-openshift-rhel7 the pod must be labeled deployment=eap74-openjdk8-openshift-rhel7.
~]$ oc describe pod/eap74-openjdk8-openshift-rhel7-5c899f4665-qlqbh --namespace jboss | grep -i Labels
Labels: deployment=eap74-openjdk8-openshift-rhel7
Assuming there are no ingress network polices in the JBOSS project / namespace denying traffic, let's use the hello-openshift pod to submit a request to the Service that is forwarding requests onto the JBOSS pod using curl in the hello-openshift pod and using the socket (IP address and port) of the Service.
In this example I get a response to the GET request. This means I am able to connect to the JBOSS pod using the Service. Good - we know the Service is able to forward requests onto the pod and the application in the pod is able to response to GET requests
~]$ oc exec pod/ose-hello-openshift-rhel8-5959c4fb77-9tdzw -n hello-openshift -- curl 172.30.46.75:9990 -v
* Rebuilt URL to: 172.30.46.75:9990/
* Trying 172.30.46.75...
* TCP_NODELAY set
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 172.30.46.75 (172.30.46.75) port 9990 (#0)
> GET / HTTP/1.1
> Host: 172.30.46.75:9990
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Connection: keep-alive
< Location: /console/index.html
< Content-Length: 0
< Date: Tue, 22 Oct 2024 01:19:47 GMT
<
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Connection #0 to host 172.30.46.75 left intact
From Route to Service to Pod
If you are able to get a response from the JBOSS pod using the Service, I would then next see if I can get a response using the Route that forwards requests onto the pod.
The oc get routes command can be used to list the routes in the current selected project / namespace. Notice in this example that there is a route that forwards requests onto the JBOSS pod on port 8080 but there are no routes that forward requests onto the JBOSS pod on port 9990 or 9993.
~]# oc get routes
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
my-route my-jboss-route.apps.openshift.example.com my-service 8080 None
Let's create a route for port 9990 and/or 9993.
The oc expose service command can be used to create an insecured route for the HTTP JBOSS Admin Console on port 9990.
~]$ oc expose service eap74-openjdk8-openshift-rhel7 --name jboss-http-admin-console --port 9990 --labels route-type=default
route.route.openshift.io/jboss-http-admin-console exposed
Or the oc create route command can be used to create a secured HTTPS edge, passthrough or reencrypt route for the HTTPS JBOSS Admin Console on port 9993.
~]$ oc create route edge jboss-https-admin-console --service eap74-openjdk8-openshift-rhel7 --port 9993
route.route.openshift.io/jboss-https-admin-console created
You will want to ensure:
- The route is exposed on one of the OpenShift routers. In this example, the route is "exposed on router default"
- The route is pointing to the JBOSS Service (eap74-openjdk8-openshift-rhel7 in this example)
- The route has Endpoint Port 9990 or 9993
- The route has something like "Endpoints: 10.128.2.186:9990" which means the Route is properly configured to forward requests onto the JBOSS pod with IP address 10.128.2.186 and listening for connections on port 9990 (or 9993).
~]$ oc describe route jboss-http-admin-console
Name: jboss-http-admin-console
Namespace: jboss
Created: 5 days ago
Labels: app=eap74-openjdk8-openshift-rhel7
app.kubernetes.io/component=eap74-openjdk8-openshift-rhel7
app.kubernetes.io/instance=eap74-openjdk8-openshift-rhel7
route-type=default
Requested Host: jboss-http-admin-console.apps.openshift.example.com
exposed on router internal-router (host router-internal-router.apps.openshift.example.com) 5 days ago
Path: <none>
TLS Termination: <none>
Insecure Policy: <none>
Endpoint Port: 9990
Service: eap74-openjdk8-openshift-rhel7
Weight: 100 (100%)
Endpoints: 10.128.2.186:9990
Likewise, this route is similar except that it is an HTTPS secured "edge" route.
~]$ oc describe route jboss-https-admin-console
Name: jboss-https-admin-console
Namespace: jboss
Created: 5 days ago
Labels: app=eap74-openjdk8-openshift-rhel7
app.kubernetes.io/component=eap74-openjdk8-openshift-rhel7
app.kubernetes.io/instance=eap74-openjdk8-openshift-rhel7
route-type=default
Requested Host: jboss-https-admin-console.apps.openshift.example.com
exposed on router internal-router (host router-internal-router.apps.openshift.example.com) 5 days ago
Path: <none>
TLS Termination: edge
Insecure Policy: <none>
Endpoint Port: 9993
Service: eap74-openjdk8-openshift-rhel7
Weight: 100 (100%)
Endpoints: 10.128.2.186:9993
Assuming there are no ingress network polices in the JBOSS project / namespace denying traffic, let's use a web browser such as Microsoft Edge to see if the request using the Route "makes it" to the Pod and returns the Admin Console.
Did you find this article helpful?
If so, consider buying me a coffee over at 