W-16132496-CH2-Networking-Guide-LDS #227

luanamulesoft · 2024-08-21T20:02:09Z

No description provided.

hannanelson · 2024-09-03T20:04:50Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

@@ -0,0 +1,189 @@
+= CloudHub 2.0 Networking Guide


Let's avoid using "guide" in the content.
Maybe "Networking in CloudHub 2.0" or simply "CloudHub 2.0 Networking"

hannanelson · 2024-09-03T20:05:24Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

@@ -0,0 +1,189 @@
+= CloudHub 2.0 Networking Guide
+
+This guide covers cloud deployments using CloudHub 2.0. See xref:runtime-manager::deployment-strategies.adoc[Deployment Options] for information about different deployment scenarios.


The short description should summarize (rather than introduce) the topic.

Remove hard-coded link text?

hannanelson · 2024-09-03T20:09:23Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+
+== Basic Networking Architecture Components
+
+CloudHub 2.0 is MuleSoft's fully managed, containerized integration platform as a service (iPaaS) where you can deploy APIs and integrations as lightweight containers in the cloud so they are maintainable, secure, and scalable. The basic components of CloudHub 2.0 networking architecture are: Load Balancer, Private Spaces, and the Mule replica DNS records.


I sort of expect the next level (H3) to cover these three things.

Is this the only H2-level heading? If so, suggest removing this level because you have a bunch of information in H4s. If you remove this level and put this content in the short description, you can elevate those H4s to H3s.

Do you have an outline (just the headings) of this topic that I can look at?

rithishapadmanabh · 2024-10-01T20:53:40Z

cloudhub-2/modules/ROOT/assets/images/ch2-networking-architecture-diagram.png

We should show where TGW attachments and / VPN sits as well

We also need a diagram for shared spaces.

rithishapadmanabh · 2024-10-01T20:55:56Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+
+=== Upstream HTTPS Traffic
+
+By default, the load balancing service forwards traffic deployed application over HTTP. To use HTTPS:


sentence seems incomplete - traffic "to the" deployed app?

ye that sentence needs to be reworded.
Example:
"forwards traffic to a deployed"
"forwards traffic to deployed applications"

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

rithishapadmanabh · 2024-10-02T18:20:42Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+
+If you use the internal DNS name, traffic remains within the private space network. You can delete or omit the externally exposed endpoint when deploying an application to a private space. In that case, you can use the application's internal endpoint for internal traffic.
+
+If you use the cluster local endpoint, the traffic doesn't leave the cluster. However, the cluster local endpoint isn't highly available. During some cluster operations such as disaster recovery, the endpoint can be unreachable. The cluster local endpoint allows traffic within the same environment only.


What are we referring to when we say 'cluster' here? Can we replace with 'private space' - to avoid exposing details that private space == cluster

rithishapadmanabh · 2024-10-02T18:22:40Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+
+By default, applications can make outbound connections to any destination and ports. You can change this behavior to restrict egress traffic.
+
+You can remove all ingress and egress rules from and to the internet. In this case, the cluster still functions normally because of the following control measures:


Again - should we say 'private space' or 'space' instead of cluster?

xuanshi · 2024-10-02T23:33:25Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+
+The CloudHub 2.0 load balancing service performs a round-robin load distribution across application replicas, which provides horizontal scalability. The load balancing service also provides transparent switchover when an application is upgraded. See xref:ch2-update-apps.adoc[].
+
+Each application deployed to CloudHub 2.0 has both default public and internal DNS records that refer to the load balancer: `<app>.<space-shard>.region.cloudhub.io.` and `<app>.internal-<space-shard>.region.cloudhub.io.`. 


add brackets to region as well? like ...cloudhub.io?

Ye the region should be in brackets like <region>.cloudhub.io.

Do we want to elaborate on what <app> means? According to https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space#app-name-reqs, it is <app-name>-<unique-id>.

ahuynhms · 2024-10-03T05:38:09Z

cloudhub-2/modules/ROOT/assets/images/ch2-networking-architecture-diagram.png

Should app2 in node1 be "app2/replica1" instead of just "app2"? To be consistent with app1/replica1.

For the Client (Customer Network) to Internal NLB, maybe add an image to show it uses Anypoint VPN or Transit Gateway Attachment.

A suggestion: should we have a 2nd more detailed diagram to show where the PS FW comes into the picture and the traffic flow for PS CIDR versus "Local Private Network"? We've had support cases where customer's app to app traffic is failing because they only allowed "PS CIDR" in the PS FW, but didn't allow "Local Private Network".

ahuynhms · 2024-10-03T05:47:31Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+
+Each application deployed to CloudHub 2.0 has both default public and internal DNS records that refer to the load balancer: `<app>.<space-shard>.region.cloudhub.io.` and `<app>.internal-<space-shard>.region.cloudhub.io.`. 
+
+The CloudHub 2.0 load balancing service accepts public traffic on the standard HTTPS port: `443`. You can also choose to accept HTTP traffic on the standard HTTP port: `80`.


I believe this comment is exclusive to Private Space. For Shared Space, customer cannot choose to accept port 80.

Add clarification.

ahuynhms · 2024-10-03T05:50:42Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+
+=== Mule Application Ports
+
+Applications must listen on host `0.0.0.0` and port via the reserved property `${http.port}`. You can dynamically allocate the value of this property, but you can't hard-code it.


What do we mean by You can dynamically allocate the value of this property, but you can't hard-code it.? Can we reword to clarify? What are we allowing the customer to dynamically allocate?

From my understanding, there are 3 options (2 options when using the HTTP Load Balancer).
Option 1: customer can use http.port property.
Option 2: customer can hard code the value 8081 instead of using the property.
Option 3 is not relevant here: can expose TCP port directly, bypassing HTTP Load Balancer.

If customer uses any other port, the request via HTTP Load Balancer will fail.

MuleSof allocates the value of this property, (do not mention hard-coding)

ahuynhms · 2024-10-03T05:54:19Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+By default, the load balancing service forwards traffic deployed application over HTTP. To use HTTPS:
+
+* Enable the *Last-Mile Security* setting in the *Ingress* tab of the xref:ch2-deploy-private-space.adoc#configure-endpoint-path[deployment settings]. 
+* Configure the application to listen on HTTPS by providing a certificate in the xref:ps-config-domains.adoc[TLS context] of your private space.


I think this statement is wrong regarding the hyperlink we have for TLS context. The hyperlink points to the TLS context configuration for external client to Private Space. Whereas this sentence is talking about last-mile security between, which is something customer needs to configure themselves within the mule app.

We'll get rid of the link.

ahuynhms · 2024-10-03T05:55:34Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+
+=== Load Balancer Connections
+
+For each request a client makes through the CloudHub 2.0 load balancer `(<app>.<space-id>.region.cloudhub.io)`, the load balancer maintains two connections: one connection between the client and the load balancer, and another connection between the load balancer and the application. For each connection, the load balancer manages a default idle timeout of 300 seconds that is triggered when no data is sent over either connection. If no data is sent or received during this duration, the load balancer closes both connections.


Here we say <space-id> but previously we said <space-shard>. Lets make them consistent. Also the same deal here with region. Needs to be in brackets.

ahuynhms · 2024-10-03T05:59:02Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+|`*.<space-id>.<region>.cloudhub.io`|Applications running inside a private space.
+|`<space-id>.<region>.cloudhub.io`|Record pointing to the load balancer. Use this record as the target of a custom domain CNAME.
+|`*.internal-<space-id>.<region>.cloudhub.io`|Applications running inside a private space. The IP addresses for this DNS record are accessible only within your xref:ch2-private-space-about.adoc[private spaces]. They cannot be accessed within xref:ch2-shared-space-about.adoc[shared spaces].
+|`internal-<space-id>.<region>.cloudhub.io`|Internal load balancer. Use this record as the target of a custom domain CNAME. The IP addresses for this DNS record are accessible only within your private spaces. They cannot be accessed within shared spaces.


The "Use this record as the target of a custom domain CNAME" comment for the last entry (internal load balancer) is wrong. We currently don't support custom domain CNAME for the internal LB. Is that correct?

We don't support a vanity domain for private endpoints. But we can still put the internal domain as a target, right?

SME confirmed that it is correct as it is now.

Are we planning to have vanity domains for private endpoints released, before we publish this doc?

For the public endpoint scenario:

Customer configures example.com

They create a CNAME for example.com, which points to the public endpoint for purposes of DNS resolution, to get the IP.

When CH2 LB receives the request, it will match the host header example.com against the configured vanity domain (example.com), and it will match.

For the private endpoint scenario:

Let say customer sends request to internal.com

They have CNAME for internal.com, that points to the private endpoint, and DNS resolution works.

But the problem is when CH2 LB receives the request, it will see the host header as internal.com, and it will be unable to match this against any certificate on the CH2 LB, because (currently) we don't support vanity domains for the private endpoint.

Based on my above examples, I don't understand how that statement is valid when we don't support vanity domains for the private endpoint.

ahuynhms · 2024-10-04T00:18:22Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+
+If you use the internal DNS name, traffic remains within the private space network. You can delete or omit the externally exposed endpoint when deploying an application to a private space. In that case, you can use the application's internal endpoint for internal traffic.
+
+If you use the cluster local endpoint, the traffic doesn't leave the cluster. However, the cluster local endpoint isn't highly available. During some cluster operations such as disaster recovery, the endpoint can be unreachable. The cluster local endpoint allows traffic within the same environment only.


"However, the cluster local endpoint isn’t highly available. During some cluster operations such as disaster recovery, the endpoint can be unreachable."

How is this different from using the internal DNS name? Since in this statement we are saying/suggesting that using the internal DNS name is better than using the cluster local endpoint. We will surely get customers asking what are the specific differences so they can make their decision. My personal understanding was using the cluster local endpoint is better (less hops), and customer just lose out on a common log aggregation point (the ingress LB) for audit purposes.

How is using the cluster local endpoint less highly available compared to using the internal DNS name? Isn't using the internal DNS name the same, because the ingress will be forwarding traffic to the cluster local endpoint anyway.

ahuynhms · 2024-10-04T00:21:04Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+* The default public DNS name: `app.sxjsip.aus-s1.cloudhub.io`
+* The default internal DNS name (in private spaces only): `app.internal-sxjsip.aus-s1.cloudhub.io`
+* The custom domain name (if configured): `acme.example.com`
+* The cluster local DNS: `app` or `app.envid.svc.cluster.local`


Should we include the port number here too "app.envid.svc.cluster.local"?
In the other methods we don't need to include the port because it uses the default 80/443. But when using the cluster local DNS, we need to include the port reference in the request (8081).

Change to: app.envid.svc.cluster.local:8081

ahuynhms · 2024-10-04T00:38:35Z

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

+
+You can apply custom certificates to your private space. CloudHub 2.0 parses the CN and SAN list from the certificate and makes those domains available when deploying applications. 
+
+Configure either in the public or the internal DNS record to CNAME. For example: 


I thought we don't support custom domain name for internal endpoint/DNS record (at least not yet?).

SME confirmed it is correct as it is

we don't support private custom domain. but we can still do the CNAME to the internal DNS record, right?

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

Cristian-Venticinque

Approved with some minor suggestions.

Co-authored-by: Cristian-Venticinque <[email protected]>

W-16132496-CH2-Networking-Guide-LDS

eaca88d

luanamulesoft self-assigned this Aug 21, 2024

luanamulesoft requested review from sarathecoubian and a team as code owners August 21, 2024 20:02

luanamulesoft added 4 commits August 29, 2024 14:29

added content

5867588

added topic to nav

610df3d

fixed format

6ddeffe

fixed format2

6dcc079

luanamulesoft requested a review from xuanshi August 30, 2024 14:28

hannanelson reviewed Sep 3, 2024

View reviewed changes

luanamulesoft added 7 commits September 24, 2024 12:02

new changes

0f48411

applied content strategy review

318f0a9

applied content strategy review - nav

c342c4f

applied content strategy review2

974a8b6

fixed format

86ceafd

fixed format2

871414d

review

cc59d66

rithishapadmanabh requested changes Oct 2, 2024

View reviewed changes

xuanshi reviewed Oct 2, 2024

View reviewed changes

ahuynhms reviewed Oct 3, 2024

View reviewed changes

ahuynhms reviewed Oct 4, 2024

View reviewed changes

luanamulesoft and others added 9 commits October 23, 2024 13:31

Update ch2-networking-guide.adoc

f54a64d

Update ch2-networking-guide.adoc

395fa07

Update ch2-networking-guide.adoc

632077b

Update ch2-networking-guide.adoc

5341f1b

Update ch2-networking-guide.adoc

a42186b

Update ch2-networking-guide.adoc

fb2d77b

Update ch2-networking-guide.adoc

5909790

Update ch2-networking-guide.adoc

619125d

applied SME reviews

0a53ad2

luanamulesoft requested a review from kevintroller as a code owner October 30, 2024 16:03

Update ch2-networking-guide.adoc

672230f

Cristian-Venticinque reviewed Nov 11, 2024

View reviewed changes

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc Outdated Show resolved Hide resolved