Just for the curiosity - what is the web server listening on port 8080?

[willesalminen]

In Section 5.2: Guided Exercise: Externalize the Configuration of Application, I noticed that web UI syntax for Router Target port is a bit confusing. What this really mean: 8080 -> 8080 (TCP)?

I know the router interface listen on port 80 default. But for the curiosity, I tried URL http://webconfig-rt-storage-configs.apps.ocp4.example.com:8080 and I was surpised to see there was another apache web instance, but the welcome page wasn't the same than in http://webconfig-rt-storage-configs.apps.ocp4.example.com. And of course lab modifications didn't impact to that site either.

This is not related to lab directly, but what is this server, and why traffic was allowed to it? Or have I done mistake in lab configuration?

Thanks!

[Trevor]

I'm seeing three (3) questions here.  Which query is the
official one????

[willesalminen]

Your are correct. The main question is "What is the web server listening on port 8080 in this lab?".

And secondary question, which may or may not be related to the first question: "Web UI syntax for Router Target port is a bit confusing. What this really mean: 8080 -> 8080 (TCP)?"

[Kent-Kamau]

The target port is the port on the Pod where the application or service is actually listening. When a Service receives traffic, it forwards that traffic to the target port on the Pods it selects. This port is defined in the Pod's container specification. For example, if a container is running a web server on port 8080, the target port would be 8080.

[juicylemon]

All correct, just to clarify. Here we have 3 ports in play:

80 - port of the route (where route controller listens for and accept the traffic). 
8080 - port of the service (this is first of 8080 -> 8080 in target port)
8080 - port of the pod (here we have server running at port 8080)

OG, is asking about "second" server running on the same hostname as the "first" server but on the port 8080. 
As the route resolves and connects to one of the nodes, having something running on port 8080 most likely is something exposed on the node on the port 8080. Traffic here is bypassing route controller and  comes to the one of the pods (most likely the same pod that handles "first" server). 
I recommend making a call and looking into the logs of the pods to verify which one accepted the traffic. 

[mcapileibm]

The server on port 8080 is likely a separate web instance from the main one.
If your lab changes didn’t affect it, it could be:
A default service running on port 8080.
A different pod exposing this port.

80 Route port (entry point for external traffic).
8080 Service port (first 8080 in the UI).
8080 Pod port (where the actual server runs).
Normally, traffic goes through the Route to the Service.
But accessing port 8080 directly may be bypassing the Route and hitting the Node where the pod is running.
To check which pod is responding
oc logs -f <pod_name>

[Psehgaf]

Port 80: This is the route port, where the route controller listens for and accepts incoming traffic.
Port 8080 (Service): The service listens on port 8080, forwarding traffic to the corresponding target port.
Port 8080 (Pod): The application server runs on port 8080 inside one or more pods.
The original question refers to a second server running on the same hostname as the first server, but also on port 8080. Since the route resolves and connects to one of the nodes, any process listening on port 8080 at the node level is likely something directly exposed there. In this case, traffic is bypassing the route controller and reaching one of the pods, most likely the same pod handling the first server.

To diagnose this, I recommend making a request and checking the logs of the pods to determine which one received the traffic.

[willesalminen]

The port syntax is now clear, although the web GUI does not seem very intuitive. I could not find the port field in the Router section. Would the port number be appended to the public hostname if a port other than 80 is required? For example, www.example.com:81?

At the time I conducted the lab, I tried to verify the traffic destination from http://webconfig-rt-storage-configs.apps.ocp4.example.com:8080 but discontinued after some investigation. It is possible that something was running in a different namespace that I did not identify, and it was not within the scope of the lab. The welcome page of the webserver differed significantly from those deployed in the lab.

Thank you for clarifying this for me.

[Asma-Alfayyad]

The web server listening on port 8080 could be an Apache HTTP Server or another web service within the OpenShift cluster. It could also be part of a containerized application you’ve deployed or a service running externally in the OpenShift environment.

1. Router Target Port (8080 -> 8080):
• The syntax 8080 -> 8080 (TCP) in the Router Target Port configuration is referring to traffic redirection from the OpenShift router to your application. It means that the router is forwarding traffic coming to port 8080 (TCP) on the external interface to port 8080 of your application or container. This can sometimes be a bit confusing because OpenShift’s default router typically handles HTTP (port 80) and HTTPS (port 443), but you can configure it to handle other ports, like 8080.
2. Surprise Web Instance on Port 8080:
• When you accessed http://webconfig-rt-storage-configs.apps.ocp4.example.com:8080, you found another Apache web server running. This may be an existing service or part of the OpenShift environment unrelated to your current lab modifications. It’s possible that there’s another Apache instance already running on that route, potentially due to:
• Default OpenShift Services: Some OpenShift-based applications or templates might come pre-configured with an Apache HTTP server.
• External Service: There could be a service running outside of your OpenShift project that is using port 8080 on that domain.
3. Why Was Traffic Allowed to Port 8080?:
• Network Policies: By default, OpenShift may allow traffic to certain ports (like 8080) based on the routing configuration or network policies set up in the cluster. If your router is configured to allow traffic to port 8080, the external Apache instance could be a result of this.
• Ingress or Route Configuration: If you’ve created a route to direct traffic to a particular service in your OpenShift project, that route might also have allowed traffic to port 8080, and the external web server you accessed could be an unintended side effect or service running outside the scope of your current lab setup.

1. The lab configurations typically don’t modify pre-existing services outside your project, so this might be an unintended side effect of OpenShift's routing or an external service running on the same cluster.

By carefully checking your routes, services, and network policies, you should be able to identify why traffic was allowed to that other web instance and make sure your lab configuration is correct.

[Mr_Atoz]

A couple explanations come to mind:

* The Apache instance is configured with some X-Forwarded-Port rule that serves different content if it derived the original request came from port 80 (via the route) vs port 8080 when explicitly defined.

* There is a second namespace with the same hostname defined that is accepting the traffic when 8080 is explicitly defined.  This seems less likely as the router typically has a precedence order when it has multiples of the same name.

The already suggested answers of checking the pods logs is a good palce to start.