Skip to content

Commit

Permalink
OSDOCS#8394: Migrated the Networking topic for the Deploying your App…
Browse files Browse the repository at this point in the history
…lication docs
  • Loading branch information
EricPonvelle committed Apr 30, 2024
1 parent 6409f00 commit c4c7e08
Show file tree
Hide file tree
Showing 4 changed files with 54 additions and 0 deletions.
2 changes: 2 additions & 0 deletions _topic_maps/_topic_map_rosa.yml
Original file line number Diff line number Diff line change
Expand Up @@ -184,6 +184,8 @@ Topics:
File: cloud-experts-deploying-application-prerequisites
- Name: Lab Overview
File: cloud-experts-deploying-application-lab-overview
- Name: Networking
File: cloud-experts-deploying-application-networking
---
Name: Getting started
Dir: rosa_getting_started
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
:_mod-docs-content-type: ASSEMBLY
[id="cloud-experts-deploying-application-networking"]
= Tutorial: Networking
include::_attributes/attributes-openshift-dedicated.adoc[]
:context: cloud-experts-deploying-application-networking

toc::[]

//rosaworkshop.io content metadata
//Brought into ROSA product docs 2023-12-14

This tutorial shows how the OSToy app uses intra-cluster networking to separate functions by using microservices and visualize the scaling of pods.

image::deploying-networking-arch.png[OSToy Diagram]

The diagram shows there are at least 2 separate pods, each with its own service.

One pod functions as the frontend web application with a service and a publicly accessible route. The other pod functions as the backend microservice with a service object so that the frontend pod can communicate with the microservice. This communication occurs across the pods if more than one. Because of these communication limits, this microservice is not accessible from outside this cluster or from other namespaces/projects if these are configured. The sole purpose of this microservice is to serve internal web requests and return a JSON object containing the current hostname, which is the pod's name, and a randomly generated color string. This color string is used to display a box with that color displayed in the tile titled "Intra-cluster Communication".

For more information about the networking limitations, see xref:../../networking/openshift_network_security/network_policy/about-network-policy.adoc#about-network-policy[About network policy].

== Intra-cluster networking

You can view your networking configurations in {cluster-manager-url-pull}.

.Procedure
. In {cluster-manager}, cick *Networking* in the left menu.
. Review the networking configuration. The right tile titled "Hostname Lookup" illustrates how the service name created for a pod can be used to translate into an internal ClusterIP address.
. Enter the name of the microservice we created in the right tile ("Hostname Lookup") following the format of `my-svc.my-namespace.svc.cluster.local` which we created in the service definition of `ostoy-microservice.yaml` which can be seen here:
+
[source,yaml]
----
apiVersion: v1
kind: Service
metadata:
name: ostoy-microservice-svc
labels:
app: ostoy-microservice
spec:
type: ClusterIP
ports:
- port: 8080
targetPort: 8080
protocol: TCP
selector:
app: ostoy-microservice
----
+
In this case we will enter: `ostoy-microservice-svc.ostoy.svc.cluster.local`
. You see an IP address returned. In this example it is `172.30.165.246`. This is the intra-cluster IP address, which is only accessible from within the cluster.
+
image::deploying-networking-dns.png[OSToy DNS]
Binary file added images/deploying-networking-arch.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added images/deploying-networking-dns.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit c4c7e08

Please sign in to comment.