Contact Us 1-800-596-4880
  1. Homepage
  2. Runtime Fabric (1.6)

  3. Enable Inbound Traffic on Anypoint Runtime Fabric

Enable Inbound Traffic on Anypoint Runtime Fabric

Runtime Fabric provides load balancing to manage inbound traffic to Mule applications and API proxies. Network traffic is balanced across multiple replicas of an application, which, by default, are deployed across different worker VMs.

Runtime Fabric can be shared across multiple environments. After installation, configure one or more environments for each Runtime Fabric to enable application deployment. You must associate at least one environment with each Runtime Fabric to be able to deploy Mule applications or API gateways.

Applications deployed to a production environment must be deployed to an instance of Runtime Fabric that is separate from nonproduction applications.

By default, inbound traffic is disabled to prevent consuming unnecessary resources. To allow Mule applications or API gateways to listen on inbound connections, enable inbound traffic.

Step 1: Assign Required Roles and Permissions

Ensure you have the necessary permissions for the Runtime Fabric environment you want to use for applications:

  1. From Anypoint Platform, select Access Management.

    If you do not have access to Access Management, ask your organization admin (system administrator) to provide the "Manage Runtime Fabrics" permission to your user. If you have access, execute the following steps to add the permission:

  2. Select Users.

  3. Locate the row containing your username and then select the blue link in the Username column.

  4. In the Runtime Manager tab, enable the Manage Runtime Fabrics permission for your Runtime Fabric environment.

    It can take up to five minutes for any permissions you add to propagate.

Step 2: Configure Inbound Traffic Using Runtime Manager

  1. Navigate to Runtime Manager and select Runtime Fabric.

  2. Select the name of your Runtime Fabric to open the management page.

  3. In the Associated Environments tab, ensure that your Runtime Fabric is associated with the environments in which applications are to be deployed.

  4. Select Inbound Traffic and toggle Enable inbound traffic to on.

    If you disable the Inbound Traffic tab, changes can take several minutes to complete.

  5. In the Basic Configuration section, verify that Secure Port is set to 443 and that Non Secure Port is set to 80. The nonsecure port redirects to the secure port.

  6. In the Resource Allocation section:

    The inbound load balancer runs on each controller node configured in Runtime Fabric. Refer to Manage Runtime Fabric for detailed information.

    1. Select a mode.

      • Shared Mode is the default setting if no dedicated internal load balancer node is added in Runtime Fabric. In this mode, the internal load balancer runs on all controller nodes with the specified amount of CPU and memory.

      • Dedicated Mode is enabled only if one or more dedicated internal load balancer nodes is available in Runtime Fabric. Because dedicated internal load balancer nodes use all available resources for running the internal load balancer, you cannot specify the amount of CPU cores and memory. If you are setting up a Runtime Fabric with dedicated internal load balancer nodes, include the IP addresses of the dedicated internal load balancer nodes only when configuring the external load balancer.

        The number of replicas for inbound traffic is set to the number of controller nodes for Shared Mode or the number of dedicated internal load balancer nodes for Dedicated Mode. You must include all IP addresses of the controller nodes or the dedicated internal load balancer nodes in your external load balancer or DNS resolution.

        When switching between shared and dedicated modes:

        • All inbound traffic is lost if the shared or dedicated IP addresses are not included in the load balancer or DNS resolution prior to making the change.

        • If you change from Shared Mode to Dedicated Mode, you must include the dedicated internal load balancer node IP addresses in place of the controller node IP addresses in your external load balancer. Temporarily include both controller and dedicated internal load balancer nodes until the switch is completed to properly route inbound requests.

        • If you change from Dedicated Mode to Shared Mode, configure the CPU Cores and Memory fields appropriately for your deployment. The amount of available resources can significantly change between Dedicated Mode, in which all node resources can be consumed, and Shared Mode.

    2. Specify the minimum number of cores to allocate for each controller node for the internal load balancer.

      Note that Runtime Fabric can use up to the maximum number shown if the cores are available. Transport Layer Security (TLS) termination is computationally expensive, so allocate enough CPU to increase throughput and decrease latency. Refer to See the Resource Allocation and Performance on Anypoint Runtime Fabric for more information on CPU allocation and throughput, including how the TLS private key type and size affect these numbers.

    3. Specify the minimum memory to allocate for each controller node for the internal load balancer. Note that Runtime Fabric can use up to the maximum amount shown if it is available.

  7. Configure a TLS context.

    All inbound traffic entering Anypoint Runtime Fabric is encrypted using TLS. When enabling inbound traffic, you must provide a valid TLS certificate. After inbound traffic is enabled, HTTP requests sent to Runtime Fabric receive a 301 response to redirect to HTTPS on port 443.

    You can only change the TLS configuration and policies for Runtime Fabrics that you own. For inherited Runtime Fabric instances, the TLS configuration is read-only.

    You can configure the private key and public certificate for a TLS-enabled server in one of the following ways:

    • Option 1: Upload PEM

      Use this option to upload a public certificate and private key in Privacy-Enhanced Mail (PEM) format and use TLS default values. A PEM file is a Base64-encoded ASCII file with a .cer, .crt, or .pem extension.

      With this option, you cannot change the default values for TLS versions, ciphers, and other TLS configuration options. Refer to Configure a TLS Context for Runtime Fabric Load Balancer for information about TLS default values.

      This is the default option when no TLS context exists for Runtime Fabric.

      1. For Certificate File, specify a public certificate for the inbound traffic server in PEM format. The Domains field lists domains that are selectable for Application url, which is used for routing requests to an application. By default, the first domain listed is used. Other values can be selected via the Applications→Ingress page.

        The certificate must be set with a passphrase and a common name (CN) that specifies the domain for each application deployed to Runtime Fabric.

        • If the CN contains a wildcard, the endpoint for each deployed application takes the form {app-name}.{common-name}.

        • If the CN does not contain a wildcard, the endpoint takes the form {common-name}/{app-name}.

      2. Specify a value for Key File. This is the PEM formatted file that contains the private key for the certificate.

      3. If the Key Passcode field is displayed after uploading a PEM key file, enter the word or phrase that protects the private key.

      4. Optionally, specify a value for CA Path Certificate File (Optional). The CA path contains the intermediary and root certificates that provide the path (chain of trust) from the certificate to the root. When you provide an entry in this field, the path is sent along with the certificate during the TLS handshake.

      5. Select Deploy. The Key Passcode field is blanked out for security reasons. You can still review public certificate details. If you upload a new key file, this field is again enabled.

        The public certificate, private key, and key passcode are saved in the secrets manager.

    • Option 2: Upload JKS

      Use this option to upload a Java Keystore (JKS) file and use TLS default values. With this option, you cannot change the default values for TLS versions, ciphers, and other TLS configuration options. A JKS file is a repository for authorization or public key certificates and does not store secret keys. Refer to Configure a TLS Context for Runtime Fabric Load Balancer for additional information.

      1. Specify a value for Keystore File. At a minimum, the keystore file contains the public certificate and private key, also known as a key pair.

      2. Specify a value for Keystore Passcode, the word or phrase that protects the keystore.

      3. Specify a value for Alias. The alias is used to select a specific key pair.

        This field is enabled after you specify a keystore file and keystore passcode.

      4. In the Choose Alias From Keystore window, select an alias. The following information is displayed:

        • The URL format to be used for your apps, based on the certificate’s CN.

          The certificate must be set with a passphrase and a CN that specifies the domain for each application deployed to Runtime Fabric. The domain is used for routing requests to an application. Other values can be selected via the Applications→Ingress page.

          • If the CN contains a wildcard, the endpoint for each deployed application takes the form {app-name}.{common-name}.

          • If the CN does not contain a wildcard, the endpoint takes the form {common-name}/{app-name}.

        • The expiration date of the secret.

      5. Specify a value for Key Passcode, the word or phrase that protects the private key.

        This field is enabled after you specify an alias.

      6. Verify you have entered values for Keystore File, Keystore Passcode, Alias, and Key Passcode before selecting other options or deploying.

      7. Select Deploy. The Keystore Passcode and Key Passcode fields are blanked out for security reasons.

        • If you select a different Alias value, the Key Passcode field is again enabled.

        • If you upload a new keystore file, the Alias and Keystore Passcode fields are again enabled and the Alias field contents are cleared.

          The JKS file information is saved in the global secrets group for your organization.

    • Option 3: Import from Secrets Manager (for advanced users)

      This option is automatically selected for Runtime Fabrics for which inbound traffic was enabled before the PEM and JKS upload options became available. Refer to Configure a TLS Context for Runtime Fabric Load Balancer for instructions.

      This option imports a TLS context from the secrets manager, and supports advanced configuration such as creating a TLS context, mutual authentication, selecting ciphers, and selecting TLS versions.

      To import a TLS context from the secrets manager, you need additional secrets manager permissions. Refer to Configure a TLS Context for Runtime Fabric Load Balancer for additional information.

      To generate key material for testing purposes and create a TLS context in the secrets manager, follow the instructions provided in Generate a TLS Certificate for Testing later in this topic.

  8. (Optional) Select Security Policies

    A security policy must be defined in Anypoint Security to be displayed as an option in the HTTP Limits, Web Application Firewall (WAF), IP Whitelist, or Denial of Service (DoS) dropdown lists.

    To access a Runtime Fabric instance using more than one DNS, add additional DNS entries in the subject alternative names (SAN) certificate property. If a certificate has multiple DNS entries specified in the SAN property, the available URLs are displayed in the Applications→Ingress page when you deploy an application.

    To define a security policy in Anypoint Security, you must have the Anypoint Security - Edge entitlement for your Anypoint Platform account. If you do not see Security listed in Management Center, contact your customer success manager to enable Anypoint Security for your account.

    Refer to Anypoint Security Policies for Edge for additional information.

  9. (Optional) Select Advanced Options

    The following table describes additional configuration options you might need to set for your environment. In this case, Source IP refers to the client making the request.

    Table 1. Advanced Configuration Options
    Value Description

    Max Connections

    The maximum number of simultaneous connections to allow.

    Default value: 512 connections

    Max Requests per Connection

    The maximum number of requests per connections to allow.
    This value ranges from 1 to 4194304.
    Because this value determines how much reuse a connection allows, consider the amount of CPU required to terminate and reestablish a TLS-encrypted connection when lowering this value.

    Maximum allowed: 1000 requests per connection

    Default value: 1000. This value balances security and performance. Refer to Resource Allocation and Performance on Anypoint Runtime Fabric for additional information.

    Connection Idle Time-out

    The maximum amount of time that allowed for an idle connection.
    This value helps you terminate idle connections and free resources.
    This value should always be higher than your Read Request Time-out.

    Default value: 15 seconds

    Read Request Time-out

    The maximum amount of time spent to read a request before it is terminated.
    This value enables requests with large payloads or slow clients to be terminated to keep resources available.v+ This helps guard against connection pool exhaustion from slow requests or from clients who don’t close connections after a response is sent.

    For example, if a Mule application takes longer than this value to respond, the connection is automatically closed.
    This value should always be lower than the Connection Idle Time-out value previously configured.

    Default value: 10 seconds

    Read Response Time-out

    The maximum amount of time spent to initiate a response before the connection is terminated.
    This value enables requests with large payloads be terminated to keep resources available.

    Default value: 300 seconds

    Write Response Time-out

    The maximum amount of time spent from the end of the request header read to the end of the response write before the request is terminated.

    Default value: 10 seconds

    Max Pipeline Depth

    The maximum number of requests to allow from the same client.
    This value defines how many simultaneous requests a client can send.
    If a client exceeds this number, the exceeding requests are not read until the requests in the queue receive a response.

    Default value: 10 requests per client

    Source IP header name and enable proxy protocol

    Configure the following values based on the applicable scenario:

    1. Runtime Fabric is not deployed behind a load balancer.
      These values should not be configured.

      Source IP header name: Blank
      Enable proxy protocol: Unchecked

    2. Runtime Fabric is deployed behind an AWS load balancer with a proxy protocol configured.
      You must select the enable proxy protocol option.

      Source IP header name: Blank
      Enable proxy protocol: Checked

    3. Runtime Fabric is behind a non-AWS load balancer.
      If Runtime Fabric is deployed behind another type of load balancer, such as F5 or nginx, the source IP address can be provided in an HTTP Header field. In this case, enter the HTTP header name that contains the source IP header.

      HTTP messages not containing this header field will be rejected. Two common HTTP header names that are used for source IP addresses are:

      • Forwarded: An RFC7239 compliant IP header.

      • X-Forwarded-For: Non-standard pre-2014 header containing one or more IPs from a load balancer (For example: “192.16.23.34, 172.16.21.36")

        Source IP header name: Non-blank
        Enable proxy protocol: Unchecked

    Default value: Blank and unchecked.

    If you are using WebSockets:

    • Provide the correct request headers to upgrade the HTTP connection to WebSockets.

    • Configure Mule runtime engine with a WebSockets Listener.

    • Increase the Connection Idle Time-out value to 900 seconds (15 minutes) to ensure consistency with the WebSockets Mule application default value.

  10. (Optional) Configure Internal Load Balancer Logs

    You can define the log levels for the internal load balancer. Runtime Fabric supports the following log levels, listed in descending order of verbosity:

    • FATAL

    • ERROR

    • WARNING

    • INFO

    • VERBOSE

    • DEBUG

    • TRACE

      The more verbose log levels, which include WARNING, INFO, VERBOSE, DEBUG, and TRACE, consume more CPU resources for each request. Consider this when adjusting the log level and allocating resources for the internal load balancer.

      By default, the activity across all IPs addresses behind your endpoint is logged. To help reduce CPU consumption when using more verbose log levels, add IP filters to only log-specific IP addresses. This feature also reduces the quantity of logs when debugging a connection for a specific or limited number of IP addresses.

      1. From Anypoint Platform select Runtime Manager.

      2. Select Runtime Fabric.

      3. Select the Inbound Traffic tab, and then select Logs.

      4. Select Add Filter.

      5. In the IP field, enter a single IP address or subset of addresses using CIDR notation.

      6. Select the log level to apply to this IP filter.

      7. Select OK.

  11. Select Deploy to deploy the internal load balancer.

    The deployment can take up to a minute to complete.

    If there are validation errors, an error message is returned. If the validation is successful, a message in green text is displayed at the bottom-right of the page indicating that the deployment request is accepted. You can view the deployment status at the beginning of the page.

Step 3: Verify that Inbound Traffic is Enabled

To test inbound traffic for deployed applications, you can send a request using the controller IP address along with a host header set to the domain. The host header depends on the structure of the application URL.

  1. Determine which endpoint exposes the application. The Application url field on the Manage application page in Runtime Manager contains this information.

  2. Run the following cURL command for verification:

    curl -Lvk -XGET {application-path-from-runtime-manager} --resolve {hostname}:443:{ip-address-of-controller}

    In the following example, {application-path-from-runtime-manager} is set to https://newapp.example-rtf.dev, and 192.168.64.14 is the IP address of a controller machine in your cluster.

    curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14

Step 4: Configure an External Load Balancer

After you enable inbound traffic, you must configure Runtime Fabric to route incoming traffic to each enabled application for clients to send requests to deployed applications.

You must configure an external load balancer to load balance HTTPS traffic between each controller VM on Runtime Fabric. Controller VMs are virtual machines dedicated to run the components that power Anypoint Runtime Fabric. Each controller VM runs a replica of the internal load balancer and is configured to listen on port 443.

External Load Balancer Requirements

When running multiple controller VMs, you must have an external load balancer outside Runtime Fabric to front each of the controller VMs.

The external load balancer must support TCP load balancing and must be configured with a server pool containing the IP addresses of each controller VM. A health check must also be configured on the external load balancer, listening on port 443.

This configuration of the external load balancer provides the following benefits:

  • Maintains high availability.

  • Protects against failures.

  • Gracefully handles automated failover if a replica of the internal load balancer restarts or is evicted and rescheduled on another controller VM.

To configure an external load balancer:

  1. Review the information described in Advanced Options when adding an external load balancer.

  2. Configure DNS before using the CN obtained from the TLS certificate. DNS is required to send requests to applications or API gateways deployed to Runtime Fabric. Add an "A record" to your DNS provider to map the CN to the IP address of the external load balancer or controller VMs.

Step 5: Deploy Applications

When you are ready to deploy an application, follow the instructions in Deploy a Mule Application to Runtime Fabric.

The Ingress tab allows you to specify whether inbound traffic should be allowed for the application. After you enable inbound traffic, the default behavior is changed to allow for new application deployments. If there are applications deployed to Runtime Fabric before you enable inbound traffic, they do not receive inbound requests until this setting is enabled.

Upgrade Changes

For Runtime Fabric versions 1.5.0 or later, the internal load balancer is upgraded during the Runtime Fabric component upgrade process.

Generate a TLS Certificate for Testing

For testing purposes, you can use the following steps to generate a certificate-key pair:

  1. Run the following command on your machine to generate a certificate-key pair:

    openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365

  2. Type a passphrase for your key.

  3. Complete the requested information. When asked for a common name, supply the domain to be used in your Runtime Fabric.

If you use a wildcard, for example, *.example.com in your common name, your application URLs use the following format: {app-name}.example.com. Otherwise, your application URLs use the format example.com/{app-name}.

TLS Certificate Expiration

Certificates (both self-signed and CA-signed) always have an expiration date. By default, certificates expire one year after they are created.

The following warnings are displayed for certificates that will expire within 30 days to remind you to upload a new certificate-key pair before a certificate expires:

  • On the Runtime Fabrics page, if a TLS certificate will expire within the next 30 days,TLS Expiring is displayed in the Inbound traffic column.

  • On the Runtime Fabrics page, when a TLS certificate has expired, a warning is displayed in the Inbound traffic column for that Runtime Fabric instance.

  • On the Inbound Traffic tab, if a TLS certificate will expire within the next 30 days, a warning is displayed. When a TLS certificate has expired, the expiration date information includes a red warning in the Certificate File field.

See Also