Contact Us 1-800-596-4880
  1. Homepage
  2. CloudHub 2.0
  3. Deploying Apps to CloudHub 2.0
  4. Deploying Apps to Private Spaces

  5. Configuring Endpoints and Paths for Apps Deployed to a Private Space

Configuring Endpoints and Paths for Apps Deployed to a Private Space

CloudHub 2.0 supports customizing endpoints only for apps deployed to private spaces, not shared spaces.

A private space routes requests from clients to apps deployed to the private space.

When you deploy an app to a private space, CloudHub 2.0 creates two types of endpoints by default:

  • Endpoint: A URL used to reach the app deployed to the public space. In this context, it’s accessible externally and enables clients outside the network to reach the app. You can delete this endpoint to prevent external traffic from reaching the app.

  • Internal endpoint: A URL used to reach the app deployed to the public space, but it’s accessible only within the private network, VPN, or transit gateway (TGW). You can’t modify or delete this type of endpoint.

An example endpoint URL is https://my-app.example.com/. To ensure an app is accessible only within the network, use internal endpoints.

You can customize how requests from clients reach the app by configuring:

  • Multiple custom endpoints

    The administrator specifies the domains that you can use for the endpoints by configuring the TLS context in the private space settings. For information, see Configuring Domains and Certificates (TLS Context) for a Private Space.

  • Different paths for the app and the endpoint URL

    The path is where you want your app to be reachable, for example /api in my-app.example.com/api.

    For information, see HTTP Listener Reference - Mule 4.

  • Different path rewrite configurations for each endpoint URL of an application

    The path rewrite is the base path expected by the HTTP listener in your app, for example, /v1/api

You can also remove the external endpoint to ensure clients outside the private network can’t make requests to the app.

Before You Begin

The administrator must set up the TLS contexts for the private space before you can configure the endpoints and paths for the app.

For information, see Configuring Domains and Certificates (TLS Context) for a Private Space.

Configure Multiple Endpoints

You can enable your app to be reached via multiple endpoints, for example, my-app.example.com and my-old-app.oldname.com.

To ensure that each endpoint name is unique, use the app-name placeholder in the subdomain, or the path if the domain doesn’t include a wildcard.

To configure multiple endpoints:

  1. When deploying an app to a private space, click the Ingress tab.

    See Deploying Apps to Private Spaces.

    If the app is already deployed:

    1. From Anypoint Platform, select Runtime Manager > Applications.

    2. Click the app name.

    3. In the navigation menu, click Settings.

    4. Click the Ingress tab.

  2. Configure the first endpoint:

    1. Select the first domain from the Domain drop-down list, for example *.example.com.

      If the domain includes a wildcard, the Subdomain field becomes available.

    2. Enter the subdomain, or enter the my-app placeholder in the Subdomain field to use the name of the app that you specified in the Application Name field as the subdomain.

      For information, see placeholders.

    3. Enter the path that the client requests, for example /api.

    4. Optionally enter, the path rewrite where the HTTP Listener in the app is listening, for example /v1/api.

    5. Configure the Access:

      • External endpoints are accessible externally, and enable clients outside the network to reach the app.

      • Internal endpoints are only accessible within your private network or via your VPN or Transit Gateway connection.

  3. If you want to configure additional endpoints, click Add Endpoint and repeat steps 2.1 through 2.3.

  4. Depending on the deployment status, choose either:

    • If you’re ready to deploy the application, click Deploy.

    • If this application is deployed, click Apply Changes.

  5. Verify that the app can be reached at each configured endpoint.

Placeholders

The subdomain and path support the following optional lowercase placeholders:

Placeholder Resolves to

app-name

Name of the app that you specified in the Application Name field when you deploy the app

business-group-id

Business group ID associated with the app

environment-id

Environment that you deploy the app to

Configure a Different Path and Path Rewrite for the App and the URL Endpoint

You can configure different paths and path rewrite for the app and the URL endpoint. For example, if the app is listening on my-app.example.com/v1/api and you want the app to be reachable from the internet using my-app.example.com/api.

To configure different paths:

  1. Deploy the app to a private space.

  2. Click the Ingress tab.

  3. In the Path field, enter the path where you want the app to be reachable, for example, /api.

  4. In the Path Rewrite field, enter the base path expected by the HTTP Listener in your app, for example, /v1/api.

  5. Click Apply Changes to create a configuration for your application.

Remove an Endpoint

To remove an endpoint:

  1. From Anypoint Platform, select Runtime Manager > Applications.

  2. Click the app name.

  3. In the navigation menu, click Settings.

  4. Click the Ingress tab.

  5. In the endpoint link row, click X (Delete).

View the Default Internal Endpoint for an App

An internal endpoint is accessible from inside the same private space or through the VPN or transit gateway connection for the private space. You cannot make changes to the path or domain for an internal endpoint.

To view or copy the URL for the internal endpoint:

  1. From Anypoint Platform, select Runtime Manager > Applications.

  2. Click the app name.

  3. In the navigation menu, click Settings.

  4. Click the Ingress tab.

  5. Hover over internal endpoint.

Send Application-to-Application Requests within a Private Space

In a private space, every application replica exposes an endpoint inside the private space. When you enable inbound traffic, that endpoint is exposed externally.

Every application has a DNS record in the private space internal domain. For example, the DNS record for the application helloch2 in the 2abc2ce6-cce6-463b-afaa-a1979e3xxxxx environment is:

helloch2.2abc2ce6-cce6-463b-afaa-a1979e3xxxxx.svc.cluster.local

Because application replicas first search DNS records in the same domain before searching the parent domain, you need only the application name to send a request to another application in the same private space. If both applications are in the same namespace, you need only the application name:

http://helloch2:8081/hello

If required, replace http with https.

You can’t send traffic between applications in different namespaces by using svc.cluster.local endpoints.

Application-to-Application Communication

An application communicates with another application via:

  • 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

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.

During disaster recovery, the cluster local DNS endpoint can fail if an application migrates to a new cluster. This is because traffic routed through the local DNS endpoint doesn’t traverse the ingress load balancer, which is essential for directing traffic to the new cluster. However, using other available endpoints forces traffic to pass through the ingress load balancer. The ingress load balancer detects if a disaster recovery event is happening. It also knows if an application linked to a certain endpoint has moved to a new cluster. It then routes traffic to the new cluster if needed.

During node upgrades and scaling, cluster local DNS endpoints remain reachable as long as you deploy multiple application replicas.

The cluster local endpoint allows traffic within the same environment only.

See Also