# mulesoft Runtime Fabric - Full Documentation --- product: Runtime Fabric version: 2.6 --- # Allocating Resource for Application Deployment on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying a Mule application to Anypoint Runtime Fabric, determine the correct number of resources to allocate. Determining resource allocation is also important when configuring the internal load balancers on Anypoint Runtime Fabrics. When a Mule application is deployed to Runtime Fabric, the application is deployed with its own Mule runtime engine (Mule). The number of replicas, or instances of that application and runtime, are also specified. The resources available for each replica are determined by the values you set when deploying an application. The following performance information is based on clusters with controller nodes using custom Intel Xeon E5-2676 v3 Haswell processors. The processors run at a base clock rate of 2.4 GHz and can go as high as 3.0 GHz with Intel Turbo Boost. The load generator was hosted on a separate cluster in the same region. You can allocate the following resources when deploying an application: - vCPU cores - `Reserved vCPU` The amount of vCPU guaranteed to the application and reserved for its use. - `vCPU Limit` The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node. - Memory Review [MuleSoft licensing requirements](https://docs.mulesoft.com/runtime-fabric/2.6/limitations-self#license-compliance) for applications deployed on Runtime Fabric instances. ## vCPU Allocation When the `Reserved vCPU` and `vCPU Limit` are equal, the CPU on the worker node is allocated in a guaranteed model. The container always has the specified amount of CPU available. The vCPU is reserved for each replica of the application and is guaranteed regardless of what else is running on Runtime Fabric. Guaranteed CPU allocation allows applications to perform consistently by ensuring there is no CPU contention between other applications. It guarantees performance in all cases. When the value of `vCPU Limit` is set higher than the value of `Reserved vCPU`, the application can burst up to the either the vCPU limit value or the amount of unreserved vCPU on the worker node, whichever is less. When estimating the CPU and memory required for worker nodes, Anypoint Monitoring agent requires at least 0.05 vCPU cores and 50 Mi of memory for Anypoint Monitoring. This container is used to stream application metrics to the control plane and cannot be disabled. ## CPU Bursting When using CPU bursting, you must consider the following factors: - Minimum reserved vCPU: 0.02 vCPU. - Minimum vCPU limit: 0.07 vCPU. Resource intensive applications might require additional CPU capacity. If an application deployment fails using the minimum vCPU limit, increase the vCPU limit and redeploy the application. - The CPU limit is upper-bounded by the CPU cores provided on the worker nodes. - The maximum recommended utilization per CPU core is 20 - 25 simple applications and API gateways. More complex applications with higher usage may need more capacity. - Runtime Fabric runs a small number of services on worker nodes. These services consume between 0.3 and 0.5 vCPU, depending on whether log forwarding is enabled for Anypoint Monitoring. - Each application replica must reserve 50m CPU and 150Mi memory for the container that runs Anypoint Monitoring. This container streams application metrics to the control plane and cannot be disabled. - Applications compete for the unallocated CPU remaining on their worker node. As more applications are deployed on a worker node, less unallocated CPU is available to share with other applications and can result in poor performance. The following strategies can be considered for minimizing CPU contention with your applications: - Deploy nightly batch applications with other applications that have peak load during the day. - Deploy multiple replicas of an application so that they are distributed across worker nodes to maximize the surface area for unallocated CPU. Regardless of what approach is chosen, make sure you run tests to validate performance. ## Memory Allocation The minimum values for the amount of memory allocated to each replica of a Mule application or API gateway are the following: - 0.7 GiB memory for Mule 4 - 0.5 GiB memory for Mule 3 When Anypoint Monitoring is enabled, 50MB memory is reserved for running the Anypoint Monitoring sidecar containers, which can burst up to 70MB for each application deployed when processing metrics data. ## Calculating Memory Allocation on CloudHub and Runtime Fabric Anypoint Platform allocates native and heap memory for a deployed application. Heap memory is the portion of the total memory that is made available to the Mule runtime and the application. Heap memory is used for tasks like handling payload. Anypoint Platform allocates native memory for deployed applications through the JVM, taking into account the standard practices of Java memory management. Both CloudHub and Anypoint Runtime Fabric allocate both types of memory. However, they differ in how the memory allocation of each memory type is calculated. - Runtime Fabric lists the total memory available for an application. The available heap memory is approximately half of the total memory allocated to an application. - CloudHub describes minimum memory requirements in terms of the heap memory available to an application. ## Application Startup Times The startup time for a Mule application is correlated to the total number of vCPU cores the application has access to. The following lists approximate startup times for a simple Mule proxy application performing processing on a payload:
vCPU CoresApproximate Startup Time

1.00

Less than 1 minute

0.50

Under 2 minutes

0.10

6 to 8 minutes

0.07

10 to 14 minutes

## Application Performance The resources allocated to your Mule application determine the application’s performance. The following table lists approximate values for throughput based on the total number of vCPU cores allocated for a single Mule application performing simple processing on a 10-KB payload:
vCPU CoresConcurrent ConnectionsAvg Response Time (ms)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78

> [!NOTE] Run performance and load testing on your Mule applications to determine the number of > resources to allocate. ## CPU Requirements for Keys and Certificates Ensure that you allocate enough CPU resources to support a minmum of 10 PEM/P12 or 8 JKS/JCEKS certificates. The number of recommended cores are:
CoresPEM/P12JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8

## Key Types RSA keys are the most common type of keys. RSA keys of 2K length offer the best compromise between security and performance. > [!NOTE] RSA keys larger than 2K protect against brute force cracking and are appropriate for > certificates that have expirations of many years. However, whenever key length is doubled, for > example, from 2k to 4k, performance is reduced by a factor greater than 6. ECDSA keys are also supported. In most cases, ECDSA doubles the performance of a 2K RSA key. Supported curves are: - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (also known as prime256v1 (P-256)) ## See Also - [Deploy a Mule Application to a Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-runtime-fabric) - [View Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.6/view-health) --- product: Runtime Fabric version: 2.7 --- # Allocating Resource for Application Deployment on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying a Mule application to Anypoint Runtime Fabric, determine the correct number of resources to allocate. Determining resource allocation is also important when configuring the internal load balancers on Anypoint Runtime Fabrics. When a Mule application is deployed to Runtime Fabric, the application is deployed with its own Mule runtime engine (Mule). The number of replicas, or instances of that application and runtime, are also specified. The resources available for each replica are determined by the values you set when deploying an application. The following performance information is based on clusters with controller nodes using custom Intel Xeon E5-2676 v3 Haswell processors. The processors run at a base clock rate of 2.4 GHz and can go as high as 3.0 GHz with Intel Turbo Boost. The load generator was hosted on a separate cluster in the same region. You can allocate the following resources when deploying an application: - vCPU cores - `Reserved vCPU` The amount of vCPU guaranteed to the application and reserved for its use. - `vCPU Limit` The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node. - Memory Review [MuleSoft licensing requirements](https://docs.mulesoft.com/runtime-fabric/2.7/limitations-self#license-compliance) for applications deployed on Runtime Fabric instances. ## vCPU Allocation When the `Reserved vCPU` and `vCPU Limit` are equal, the CPU on the worker node is allocated in a guaranteed model. The container always has the specified amount of CPU available. The vCPU is reserved for each replica of the application and is guaranteed regardless of what else is running on Runtime Fabric. Guaranteed CPU allocation allows applications to perform consistently by ensuring there is no CPU contention between other applications. It guarantees performance in all cases. When the value of `vCPU Limit` is set higher than the value of `Reserved vCPU`, the application can burst up to the either the vCPU limit value or the amount of unreserved vCPU on the worker node, whichever is less. When estimating the CPU and memory required for worker nodes, Anypoint Monitoring agent requires at least 0.05 vCPU cores and 50 Mi of memory for Anypoint Monitoring. This container is used to stream application metrics to the control plane and cannot be disabled. ## CPU Bursting When using CPU bursting, you must consider the following factors: - Minimum reserved vCPU: 0.02 vCPU. - Minimum vCPU limit: 0.07 vCPU. Resource intensive applications might require additional CPU capacity. If an application deployment fails using the minimum vCPU limit, increase the vCPU limit and redeploy the application. - The CPU limit is upper-bounded by the CPU cores provided on the worker nodes. - The maximum recommended utilization per CPU core is 20 - 25 simple applications and API gateways. More complex applications with higher usage may need more capacity. - Runtime Fabric runs a small number of services on worker nodes. These services consume between 0.3 and 0.5 vCPU, depending on whether log forwarding is enabled for Anypoint Monitoring. - Each application replica must reserve 50m CPU and 150Mi memory for the container that runs Anypoint Monitoring. This container streams application metrics to the control plane and cannot be disabled. - Applications compete for the unallocated CPU remaining on their worker node. As more applications are deployed on a worker node, less unallocated CPU is available to share with other applications and can result in poor performance. The following strategies can be considered for minimizing CPU contention with your applications: - Deploy nightly batch applications with other applications that have peak load during the day. - Deploy multiple replicas of an application so that they are distributed across worker nodes to maximize the surface area for unallocated CPU. Regardless of what approach is chosen, make sure you run tests to validate performance. ## Memory Allocation The minimum values for the amount of memory allocated to each replica of a Mule application or API gateway are the following: - 0.7 GiB memory for Mule 4 - 0.5 GiB memory for Mule 3 When Anypoint Monitoring is enabled, 50MB memory is reserved for running the Anypoint Monitoring sidecar containers, which can burst up to 70MB for each application deployed when processing metrics data. ## Calculating Memory Allocation on CloudHub and Runtime Fabric Anypoint Platform allocates native and heap memory for a deployed application. Heap memory is the portion of the total memory that is made available to the Mule runtime and the application. Heap memory is used for tasks like handling payload. Anypoint Platform allocates native memory for deployed applications through the JVM, taking into account the standard practices of Java memory management. Both CloudHub and Anypoint Runtime Fabric allocate both types of memory. However, they differ in how the memory allocation of each memory type is calculated. - Runtime Fabric lists the total memory available for an application. The available heap memory is approximately half of the total memory allocated to an application. - CloudHub describes minimum memory requirements in terms of the heap memory available to an application. ## Application Startup Times The startup time for a Mule application is correlated to the total number of vCPU cores the application has access to. The following lists approximate startup times for a simple Mule proxy application performing processing on a payload:
vCPU CoresApproximate Startup Time

1.00

Less than 1 minute

0.50

Under 2 minutes

0.10

6 to 8 minutes

0.07

10 to 14 minutes

## Application Performance The resources allocated to your Mule application determine the application’s performance. The following table lists approximate values for throughput based on the total number of vCPU cores allocated for a single Mule application performing simple processing on a 10-KB payload:
vCPU CoresConcurrent ConnectionsAvg Response Time (ms)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78

> [!NOTE] Run performance and load testing on your Mule applications to determine the number of > resources to allocate. ## CPU Requirements for Keys and Certificates Ensure that you allocate enough CPU resources to support a minmum of 10 PEM/P12 or 8 JKS/JCEKS certificates. The number of recommended cores are:
CoresPEM/P12JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8

## Key Types RSA keys are the most common type of keys. RSA keys of 2K length offer the best compromise between security and performance. > [!NOTE] RSA keys larger than 2K protect against brute force cracking and are appropriate for > certificates that have expirations of many years. However, whenever key length is doubled, for > example, from 2k to 4k, performance is reduced by a factor greater than 6. ECDSA keys are also supported. In most cases, ECDSA doubles the performance of a 2K RSA key. Supported curves are: - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (also known as prime256v1 (P-256)) ## See Also - [Deploy a Mule Application to a Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-runtime-fabric) - [View Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.7/view-health) --- product: Runtime Fabric version: 2.10 --- # Allocating Resources for Application Deployment on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying a Mule application to Anypoint Runtime Fabric, determine the correct number of resources to allocate. Determining resource allocation is also important when configuring the internal load balancers on Anypoint Runtime Fabrics. When a Mule application is deployed to Runtime Fabric, the application is deployed with its own Mule runtime engine (Mule). The number of replicas, or instances of that application and runtime, are also specified. The resources available for each replica are determined by the values you set when deploying an application. The following performance information is based on clusters with controller nodes using custom Intel Xeon E5-2676 v3 Haswell processors. The processors run at a base clock rate of 2.4 GHz and can go as high as 3.0 GHz with Intel Turbo Boost. The load generator was hosted on a separate cluster in the same region. You can allocate the following resources when deploying an application: - vCPU cores - `Reserved vCPU` The amount of vCPU guaranteed to the application and reserved for its use. - `vCPU Limit` The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node. - Memory Review [MuleSoft licensing requirements](https://docs.mulesoft.com/runtime-fabric/2.10/limitations-self#license-compliance) for applications deployed on Runtime Fabric instances. ## vCPU Allocation When the `Reserved vCPU` and `vCPU Limit` are equal, the CPU on the worker node is allocated in a guaranteed model. The container always has the specified amount of CPU available. The vCPU is reserved for each replica of the application and is guaranteed regardless of what else is running on Runtime Fabric. Guaranteed CPU allocation allows applications to perform consistently by ensuring there is no CPU contention between other applications. It guarantees performance in all cases. When the value of `vCPU Limit` is set higher than the value of `Reserved vCPU`, the application can burst up to the either the vCPU limit value or the amount of unreserved vCPU on the worker node, whichever is less. When estimating the CPU and memory required for worker nodes, Anypoint Monitoring agent requires at least 0.05 vCPU cores and 50 Mi of memory for Anypoint Monitoring. This container is used to stream application metrics to the control plane and cannot be disabled. ## CPU Bursting When using CPU bursting, you must consider the following factors: - Minimum reserved vCPU: 0.02 vCPU. - Minimum vCPU limit: 0.07 vCPU. Resource intensive applications might require additional CPU capacity. If an application deployment fails using the minimum vCPU limit, increase the vCPU limit and redeploy the application. - The CPU limit is upper-bounded by the CPU cores provided on the worker nodes. - The maximum recommended utilization per CPU core is 20 - 25 simple applications and API gateways. More complex applications with higher usage may need more capacity. - Runtime Fabric runs a small number of services on worker nodes. These services consume between 0.3 and 0.5 vCPU, depending on whether log forwarding is enabled for Anypoint Monitoring. - Each application replica must reserve 50m CPU and 150Mi memory for the container that runs Anypoint Monitoring. This container streams application metrics to the control plane and cannot be disabled. - Applications compete for the unallocated CPU remaining on their worker node. As more applications are deployed on a worker node, less unallocated CPU is available to share with other applications and can result in poor performance. The following strategies can be considered for minimizing CPU contention with your applications: - Deploy nightly batch applications with other applications that have peak load during the day. - Deploy multiple replicas of an application so that they are distributed across worker nodes to maximize the surface area for unallocated CPU. Regardless of what approach is chosen, make sure you run tests to validate performance. ## Memory Allocation The minimum values for the amount of memory allocated to each replica of a Mule application or API gateway is: - 0.7 GiB memory for Mule 4 When Anypoint Monitoring is enabled, 50MB memory is reserved for running the Anypoint Monitoring sidecar containers, which can burst up to 70MB for each application deployed when processing metrics data. ## Calculating Memory Allocation on CloudHub and Runtime Fabric Anypoint Platform allocates native and heap memory for a deployed application. Heap memory is the portion of the total memory that is made available to the Mule runtime and the application. Heap memory is used for tasks like handling payload. Anypoint Platform allocates native memory for deployed applications through the JVM, taking into account the standard practices of Java memory management. Both CloudHub and Anypoint Runtime Fabric allocate both types of memory. However, they differ in how the memory allocation of each memory type is calculated. - Runtime Fabric lists the total memory available for an application. The available heap memory is approximately half of the total memory allocated to an application. - CloudHub describes minimum memory requirements in terms of the heap memory available to an application. ## Application Startup Times The startup time for a Mule application is correlated to the total number of vCPU cores the application has access to. The following lists approximate startup times for a simple Mule proxy application performing processing on a payload:
vCPU CoresApproximate Startup Time

1.00

Less than 1 minute

0.50

Under 2 minutes

0.10

6 to 8 minutes

0.07

10 to 14 minutes

## Application Performance The resources allocated to your Mule application determine the application’s performance. The following table lists approximate values for throughput based on the total number of vCPU cores allocated for a single Mule application performing simple processing on a 10-KB payload:
vCPU CoresConcurrent ConnectionsAvg Response Time (ms)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78

> [!NOTE] Run performance and load testing on your Mule applications to determine the number of > resources to allocate. ## CPU Requirements for Keys and Certificates Ensure that you allocate enough CPU resources to support a minmum of 10 PEM/P12 or 8 JKS/JCEKS certificates. The number of recommended cores are:
CoresPEM/P12JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8

## Key Types RSA keys are the most common type of keys. RSA keys of 2K length offer the best compromise between security and performance. > [!NOTE] RSA keys larger than 2K protect against brute force cracking and are appropriate for > certificates that have expirations of many years. However, whenever key length is doubled, for > example, from 2k to 4k, performance is reduced by a factor greater than 6. ECDSA keys are also supported. In most cases, ECDSA doubles the performance of a 2K RSA key. Supported curves are: - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (also known as prime256v1 (P-256)) ## See Also - [Deploy a Mule Application to a Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-runtime-fabric) - [View Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.10/view-health) --- product: Runtime Fabric version: 2.11 --- # Allocating Resources for Application Deployment on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying a Mule application to Anypoint Runtime Fabric, determine the correct number of resources to allocate. Determining resource allocation is also important when configuring the internal load balancers on Anypoint Runtime Fabrics. When a Mule application is deployed to Runtime Fabric, the application is deployed with its own Mule runtime engine (Mule). The number of replicas, or instances of that application and runtime, are also specified. The resources available for each replica are determined by the values you set when deploying an application. The following performance information is based on clusters with controller nodes using custom Intel Xeon E5-2676 v3 Haswell processors. The processors run at a base clock rate of 2.4 GHz and can go as high as 3.0 GHz with Intel Turbo Boost. The load generator was hosted on a separate cluster in the same region. You can allocate these resources when deploying an application: - vCPU cores - `Reserved vCPU` The amount of vCPU guaranteed to the application and reserved for its use. - `vCPU Limit` The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node. - Memory Review [MuleSoft licensing requirements](https://docs.mulesoft.com/runtime-fabric/2.11/limitations-self#license-compliance) for applications deployed on Runtime Fabric instances. ## vCPU Allocation When the `Reserved vCPU` and `vCPU Limit` are equal, the CPU on the worker node is allocated in a guaranteed model. The container always has the specified amount of CPU available. The vCPU is reserved for each replica of the application and is guaranteed regardless of what else is running on Runtime Fabric. Guaranteed CPU allocation allows applications to perform consistently by ensuring there is no CPU contention between other applications. It guarantees performance in all cases. When the value of `vCPU Limit` is set higher than the value of `Reserved vCPU`, the application can burst up to the either the vCPU limit value or the amount of unreserved vCPU on the worker node, whichever is less. When estimating the CPU and memory required for worker nodes, Anypoint Monitoring agent requires at least 0.05 vCPU cores and 50 Mi of memory for Anypoint Monitoring. This container is used to stream application metrics to the control plane and cannot be disabled. ## CPU Bursting When using CPU bursting, you must consider these factors: - Minimum reserved vCPU: 0.02 vCPU. - Minimum vCPU limit: 0.07 vCPU. Resource intensive applications might require additional CPU capacity. If an application deployment fails using the minimum vCPU limit, increase the vCPU limit and redeploy the application. - The CPU limit is upper-bounded by the CPU cores provided on the worker nodes. - The maximum recommended utilization per CPU core is 20 - 25 simple applications and API gateways. More complex applications with higher usage may need more capacity. - Runtime Fabric runs a small number of services on worker nodes. These services consume between 0.3 and 0.5 vCPU, depending on whether log forwarding is enabled for Anypoint Monitoring. - Each application replica must reserve 50m CPU and 150Mi memory for the container that runs Anypoint Monitoring. This container streams application metrics to the control plane and cannot be disabled. - Applications compete for the unallocated CPU remaining on their worker node. As more applications are deployed on a worker node, less unallocated CPU is available to share with other applications and can result in poor performance. The following strategies can be considered for minimizing CPU contention with your applications: - Deploy nightly batch applications with other applications that have peak load during the day. - Deploy multiple replicas of an application so that they are distributed across worker nodes to maximize the surface area for unallocated CPU. Regardless of what approach is chosen, make sure you run tests to validate performance. ## Memory Allocation The minimum values for the amount of memory allocated to each replica of a Mule application or API gateway is: - 0.7 GiB memory for Mule 4 When Anypoint Monitoring is enabled, 50MB memory is reserved for running the Anypoint Monitoring sidecar containers, which can burst up to 70MB for each application deployed when processing metrics data. ## Calculating Memory Allocation on CloudHub and Runtime Fabric Anypoint Platform allocates native and heap memory for a deployed application. Heap memory is the portion of the total memory that is made available to the Mule runtime and the application. Heap memory is used for tasks like handling payload. Anypoint Platform allocates native memory for deployed applications through the JVM, taking into account the standard practices of Java memory management. Both CloudHub and Anypoint Runtime Fabric allocate both types of memory. However, they differ in how the memory allocation of each memory type is calculated. - Runtime Fabric lists the total memory available for an application. The available heap memory is approximately half of the total memory allocated to an application. - CloudHub describes minimum memory requirements in terms of the heap memory available to an application. ## Application Startup Times The startup time for a Mule application is correlated to the total number of vCPU cores the application has access to. The following lists approximate startup times for a simple Mule proxy application performing processing on a payload:
vCPU CoresApproximate Startup Time

1.00

Less than 1 minute

0.50

Under 2 minutes

0.10

6 to 8 minutes

0.07

10 to 14 minutes

## Application Performance The resources allocated to your Mule application determine the application’s performance. The following table lists approximate values for throughput based on the total number of vCPU cores allocated for a single Mule application performing simple processing on a 10-KB payload:
vCPU CoresConcurrent ConnectionsAvg Response Time (ms)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78

> [!NOTE] Run performance and load testing on your Mule applications to determine the number of > resources to allocate. ## CPU Requirements for Keys and Certificates Ensure that you allocate enough CPU resources to support a minmum of 10 PEM/P12 or 8 JKS/JCEKS certificates. The number of recommended cores are:
CoresPEM/P12JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8

## Key Types RSA keys are the most common type of keys. RSA keys of 2K length offer the best compromise between security and performance. > [!NOTE] RSA keys larger than 2K protect against brute force cracking and are appropriate for > certificates that have expirations of many years. However, whenever key length is doubled, for > example, from 2k to 4k, performance is reduced by a factor greater than 6. ECDSA keys are also supported. In most cases, ECDSA doubles the performance of a 2K RSA key. Supported curves are: - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (also known as prime256v1 (P-256)) ## See Also - [Deploy a Mule Application to a Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-runtime-fabric) - [View Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.11/view-health) --- product: Runtime Fabric version: 2.8 --- # Allocating Resources for Application Deployment on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying a Mule application to Anypoint Runtime Fabric, determine the correct number of resources to allocate. Determining resource allocation is also important when configuring the internal load balancers on Anypoint Runtime Fabrics. When a Mule application is deployed to Runtime Fabric, the application is deployed with its own Mule runtime engine (Mule). The number of replicas, or instances of that application and runtime, are also specified. The resources available for each replica are determined by the values you set when deploying an application. The following performance information is based on clusters with controller nodes using custom Intel Xeon E5-2676 v3 Haswell processors. The processors run at a base clock rate of 2.4 GHz and can go as high as 3.0 GHz with Intel Turbo Boost. The load generator was hosted on a separate cluster in the same region. You can allocate the following resources when deploying an application: - vCPU cores - `Reserved vCPU` The amount of vCPU guaranteed to the application and reserved for its use. - `vCPU Limit` The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node. - Memory Review [MuleSoft licensing requirements](https://docs.mulesoft.com/runtime-fabric/2.8/limitations-self#license-compliance) for applications deployed on Runtime Fabric instances. ## vCPU Allocation When the `Reserved vCPU` and `vCPU Limit` are equal, the CPU on the worker node is allocated in a guaranteed model. The container always has the specified amount of CPU available. The vCPU is reserved for each replica of the application and is guaranteed regardless of what else is running on Runtime Fabric. Guaranteed CPU allocation allows applications to perform consistently by ensuring there is no CPU contention between other applications. It guarantees performance in all cases. When the value of `vCPU Limit` is set higher than the value of `Reserved vCPU`, the application can burst up to the either the vCPU limit value or the amount of unreserved vCPU on the worker node, whichever is less. When estimating the CPU and memory required for worker nodes, Anypoint Monitoring agent requires at least 0.05 vCPU cores and 50 Mi of memory for Anypoint Monitoring. This container is used to stream application metrics to the control plane and cannot be disabled. ## CPU Bursting When using CPU bursting, you must consider the following factors: - Minimum reserved vCPU: 0.02 vCPU. - Minimum vCPU limit: 0.07 vCPU. Resource intensive applications might require additional CPU capacity. If an application deployment fails using the minimum vCPU limit, increase the vCPU limit and redeploy the application. - The CPU limit is upper-bounded by the CPU cores provided on the worker nodes. - The maximum recommended utilization per CPU core is 20 - 25 simple applications and API gateways. More complex applications with higher usage may need more capacity. - Runtime Fabric runs a small number of services on worker nodes. These services consume between 0.3 and 0.5 vCPU, depending on whether log forwarding is enabled for Anypoint Monitoring. - Each application replica must reserve 50m CPU and 150Mi memory for the container that runs Anypoint Monitoring. This container streams application metrics to the control plane and cannot be disabled. - Applications compete for the unallocated CPU remaining on their worker node. As more applications are deployed on a worker node, less unallocated CPU is available to share with other applications and can result in poor performance. The following strategies can be considered for minimizing CPU contention with your applications: - Deploy nightly batch applications with other applications that have peak load during the day. - Deploy multiple replicas of an application so that they are distributed across worker nodes to maximize the surface area for unallocated CPU. Regardless of what approach is chosen, make sure you run tests to validate performance. ## Memory Allocation The minimum values for the amount of memory allocated to each replica of a Mule application or API gateway are the following: - 0.7 GiB memory for Mule 4 - 0.5 GiB memory for Mule 3 When Anypoint Monitoring is enabled, 50MB memory is reserved for running the Anypoint Monitoring sidecar containers, which can burst up to 70MB for each application deployed when processing metrics data. ## Calculating Memory Allocation on CloudHub and Runtime Fabric Anypoint Platform allocates native and heap memory for a deployed application. Heap memory is the portion of the total memory that is made available to the Mule runtime and the application. Heap memory is used for tasks like handling payload. Anypoint Platform allocates native memory for deployed applications through the JVM, taking into account the standard practices of Java memory management. Both CloudHub and Anypoint Runtime Fabric allocate both types of memory. However, they differ in how the memory allocation of each memory type is calculated. - Runtime Fabric lists the total memory available for an application. The available heap memory is approximately half of the total memory allocated to an application. - CloudHub describes minimum memory requirements in terms of the heap memory available to an application. ## Application Startup Times The startup time for a Mule application is correlated to the total number of vCPU cores the application has access to. The following lists approximate startup times for a simple Mule proxy application performing processing on a payload:
vCPU CoresApproximate Startup Time

1.00

Less than 1 minute

0.50

Under 2 minutes

0.10

6 to 8 minutes

0.07

10 to 14 minutes

## Application Performance The resources allocated to your Mule application determine the application’s performance. The following table lists approximate values for throughput based on the total number of vCPU cores allocated for a single Mule application performing simple processing on a 10-KB payload:
vCPU CoresConcurrent ConnectionsAvg Response Time (ms)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78

> [!NOTE] Run performance and load testing on your Mule applications to determine the number of > resources to allocate. ## CPU Requirements for Keys and Certificates Ensure that you allocate enough CPU resources to support a minimum of 10 PEM/P12 or 8 JKS/JCEKS certificates. The number of recommended cores are:
CoresPEM/P12JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8

## Key Types RSA keys are the most common type of keys. RSA keys of 2K length offer the best compromise between security and performance. > [!NOTE] RSA keys larger than 2K protect against brute force cracking and are appropriate for > certificates that have expirations of many years. However, whenever key length is doubled, for > example, from 2k to 4k, performance is reduced by a factor greater than 6. ECDSA keys are also supported. In most cases, ECDSA doubles the performance of a 2K RSA key. Supported curves are: - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (also known as prime256v1 (P-256)) ## See Also - [Deploy a Mule Application to a Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-runtime-fabric) - [View Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.8/view-health) --- product: Runtime Fabric version: 2.9 --- # Allocating Resources for Application Deployment on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying a Mule application to Anypoint Runtime Fabric, determine the correct number of resources to allocate. Determining resource allocation is also important when configuring the internal load balancers on Anypoint Runtime Fabrics. When a Mule application is deployed to Runtime Fabric, the application is deployed with its own Mule runtime engine (Mule). The number of replicas, or instances of that application and runtime, are also specified. The resources available for each replica are determined by the values you set when deploying an application. The following performance information is based on clusters with controller nodes using custom Intel Xeon E5-2676 v3 Haswell processors. The processors run at a base clock rate of 2.4 GHz and can go as high as 3.0 GHz with Intel Turbo Boost. The load generator was hosted on a separate cluster in the same region. You can allocate the following resources when deploying an application: - vCPU cores - `Reserved vCPU` The amount of vCPU guaranteed to the application and reserved for its use. - `vCPU Limit` The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node. - Memory Review [MuleSoft licensing requirements](https://docs.mulesoft.com/runtime-fabric/2.9/limitations-self#license-compliance) for applications deployed on Runtime Fabric instances. ## vCPU Allocation When the `Reserved vCPU` and `vCPU Limit` are equal, the CPU on the worker node is allocated in a guaranteed model. The container always has the specified amount of CPU available. The vCPU is reserved for each replica of the application and is guaranteed regardless of what else is running on Runtime Fabric. Guaranteed CPU allocation allows applications to perform consistently by ensuring there is no CPU contention between other applications. It guarantees performance in all cases. When the value of `vCPU Limit` is set higher than the value of `Reserved vCPU`, the application can burst up to the either the vCPU limit value or the amount of unreserved vCPU on the worker node, whichever is less. When estimating the CPU and memory required for worker nodes, Anypoint Monitoring agent requires at least 0.05 vCPU cores and 50 Mi of memory for Anypoint Monitoring. This container is used to stream application metrics to the control plane and cannot be disabled. ## CPU Bursting When using CPU bursting, you must consider the following factors: - Minimum reserved vCPU: 0.02 vCPU. - Minimum vCPU limit: 0.07 vCPU. Resource intensive applications might require additional CPU capacity. If an application deployment fails using the minimum vCPU limit, increase the vCPU limit and redeploy the application. - The CPU limit is upper-bounded by the CPU cores provided on the worker nodes. - The maximum recommended utilization per CPU core is 20 - 25 simple applications and API gateways. More complex applications with higher usage may need more capacity. - Runtime Fabric runs a small number of services on worker nodes. These services consume between 0.3 and 0.5 vCPU, depending on whether log forwarding is enabled for Anypoint Monitoring. - Each application replica must reserve 50m CPU and 150Mi memory for the container that runs Anypoint Monitoring. This container streams application metrics to the control plane and cannot be disabled. - Applications compete for the unallocated CPU remaining on their worker node. As more applications are deployed on a worker node, less unallocated CPU is available to share with other applications and can result in poor performance. The following strategies can be considered for minimizing CPU contention with your applications: - Deploy nightly batch applications with other applications that have peak load during the day. - Deploy multiple replicas of an application so that they are distributed across worker nodes to maximize the surface area for unallocated CPU. Regardless of what approach is chosen, make sure you run tests to validate performance. ## Memory Allocation The minimum values for the amount of memory allocated to each replica of a Mule application or API gateway is: - 0.7 GiB memory for Mule 4 When Anypoint Monitoring is enabled, 50MB memory is reserved for running the Anypoint Monitoring sidecar containers, which can burst up to 70MB for each application deployed when processing metrics data. ## Calculating Memory Allocation on CloudHub and Runtime Fabric Anypoint Platform allocates native and heap memory for a deployed application. Heap memory is the portion of the total memory that is made available to the Mule runtime and the application. Heap memory is used for tasks like handling payload. Anypoint Platform allocates native memory for deployed applications through the JVM, taking into account the standard practices of Java memory management. Both CloudHub and Anypoint Runtime Fabric allocate both types of memory. However, they differ in how the memory allocation of each memory type is calculated. - Runtime Fabric lists the total memory available for an application. The available heap memory is approximately half of the total memory allocated to an application. - CloudHub describes minimum memory requirements in terms of the heap memory available to an application. ## Application Startup Times The startup time for a Mule application is correlated to the total number of vCPU cores the application has access to. The following lists approximate startup times for a simple Mule proxy application performing processing on a payload:
vCPU CoresApproximate Startup Time

1.00

Less than 1 minute

0.50

Under 2 minutes

0.10

6 to 8 minutes

0.07

10 to 14 minutes

## Application Performance The resources allocated to your Mule application determine the application’s performance. The following table lists approximate values for throughput based on the total number of vCPU cores allocated for a single Mule application performing simple processing on a 10-KB payload:
vCPU CoresConcurrent ConnectionsAvg Response Time (ms)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78

> [!NOTE] Run performance and load testing on your Mule applications to determine the number of > resources to allocate. ## CPU Requirements for Keys and Certificates Ensure that you allocate enough CPU resources to support a minmum of 10 PEM/P12 or 8 JKS/JCEKS certificates. The number of recommended cores are:
CoresPEM/P12JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8

## Key Types RSA keys are the most common type of keys. RSA keys of 2K length offer the best compromise between security and performance. > [!NOTE] RSA keys larger than 2K protect against brute force cracking and are appropriate for > certificates that have expirations of many years. However, whenever key length is doubled, for > example, from 2k to 4k, performance is reduced by a factor greater than 6. ECDSA keys are also supported. In most cases, ECDSA doubles the performance of a 2K RSA key. Supported curves are: - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (also known as prime256v1 (P-256)) ## See Also - [Deploy a Mule Application to a Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-runtime-fabric) - [View Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.9/view-health) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Allocating Resources for Application Deployment on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying a Mule application to Anypoint Runtime Fabric, determine the correct number of resources to allocate. Determining resource allocation is also important when configuring the internal load balancers on Anypoint Runtime Fabrics. When a Mule application is deployed to Runtime Fabric, the application is deployed with its own Mule runtime engine (Mule). The number of replicas, or instances of that application and runtime, are also specified. The resources available for each replica are determined by the values you set when deploying an application. The following performance information is based on clusters with controller nodes using custom Intel Xeon E5-2676 v3 Haswell processors. The processors run at a base clock rate of 2.4 GHz and can go as high as 3.0 GHz with Intel Turbo Boost. The load generator was hosted on a separate cluster in the same region. You can allocate the following resources when deploying an application: - vCPU cores - `Reserved vCPU` The amount of vCPU guaranteed to the application and reserved for its use. - `vCPU Limit` The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node. - Memory Review [MuleSoft licensing requirements](https://docs.mulesoft.com/runtime-fabric/latest/limitations-self#license-compliance) for applications deployed on Runtime Fabric instances. ## vCPU Allocation When the `Reserved vCPU` and `vCPU Limit` are equal, the CPU on the worker node is allocated in a guaranteed model. The container always has the specified amount of CPU available. The vCPU is reserved for each replica of the application and is guaranteed regardless of what else is running on Runtime Fabric. Guaranteed CPU allocation allows applications to perform consistently by ensuring there is no CPU contention between other applications. It guarantees performance in all cases. When the value of `vCPU Limit` is set higher than the value of `Reserved vCPU`, the application can burst up to the either the vCPU limit value or the amount of unreserved vCPU on the worker node, whichever is less. When estimating the CPU and memory required for worker nodes, each application replica includes an Anypoint Monitoring sidecar container that streams application metrics to the control plane. The resource allocation for this container varies depending on enabled features such as Anypoint Monitoring logging and tracing. As a baseline, plan for at least 0.05 vCPU cores and 50 Mi of memory per replica, though actual usage can be higher when additional monitoring features are enabled. ## CPU Bursting When using CPU bursting, you must consider the following factors: - Minimum reserved vCPU: 0.02 vCPU. - Minimum vCPU limit: 0.07 vCPU. Resource intensive applications might require additional CPU capacity. If an application deployment fails using the minimum vCPU limit, increase the vCPU limit and redeploy the application. - The CPU limit is upper-bounded by the CPU cores provided on the worker nodes. - The maximum recommended utilization per CPU core is 20 - 25 simple applications and API gateways. More complex applications with higher usage may need more capacity. - Runtime Fabric runs a small number of services on worker nodes. These services consume between 0.3 and 0.5 vCPU, depending on whether log forwarding is enabled for Anypoint Monitoring. - Each application replica includes an Anypoint Monitoring sidecar container that streams application metrics to the control plane and can’t be disabled. The CPU and memory reserved for this container vary depending on the monitoring features enabled for the application (such as tracing). As a baseline, plan for at least 50m CPU and 50Mi memory per replica, though actual values can be higher. - Applications compete for the unallocated CPU remaining on their worker node. As more applications are deployed on a worker node, less unallocated CPU is available to share with other applications and can result in poor performance. The following strategies can be considered for minimizing CPU contention with your applications: - Deploy nightly batch applications with other applications that have peak load during the day. - Deploy multiple replicas of an application so that they are distributed across worker nodes to maximize the surface area for unallocated CPU. Regardless of what approach is chosen, make sure you run tests to validate performance. ## Memory Allocation The minimum values for the amount of memory allocated to each replica of a Mule application or API gateway is: - 0.7 GiB memory for Mule 4 When Anypoint Monitoring is enabled, memory is reserved for the Anypoint Monitoring sidecar container on each application replica. The actual memory allocation varies depending on enabled monitoring features such as tracing. Plan for a baseline of at least 50Mi per replica, with higher allocations when additional features are active. ## Calculating Memory Allocation on CloudHub and Runtime Fabric Anypoint Platform allocates native and heap memory for a deployed application. Heap memory is the portion of the total memory that is made available to the Mule runtime and the application. Heap memory is used for tasks like handling payload. Anypoint Platform allocates native memory for deployed applications through the JVM, taking into account the standard practices of Java memory management. Both CloudHub and Anypoint Runtime Fabric allocate both types of memory. However, they differ in how the memory allocation of each memory type is calculated. - Runtime Fabric lists the total memory available for an application. The available heap memory is approximately half of the total memory allocated to an application. - CloudHub describes minimum memory requirements in terms of the heap memory available to an application. ## Application Startup Times The startup time for a Mule application is correlated to the total number of vCPU cores the application has access to. The following lists approximate startup times for a simple Mule proxy application performing processing on a payload:
vCPU CoresApproximate Startup Time

1.00

Less than 1 minute

0.50

Under 2 minutes

0.10

6 to 8 minutes

0.07

10 to 14 minutes

## Application Performance The resources allocated to your Mule application determine the application’s performance. The following table lists approximate values for throughput based on the total number of vCPU cores allocated for a single Mule application performing simple processing on a 10-KB payload:
vCPU CoresConcurrent ConnectionsAvg Response Time (ms)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78

> [!NOTE] Run performance and load testing on your Mule applications to determine the number of > resources to allocate. ## CPU Requirements for Keys and Certificates Ensure that you allocate enough CPU resources to support a minmum of 10 PEM/P12 or 8 JKS/JCEKS certificates. The number of recommended cores are:
CoresPEM/P12JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8

## Key Types RSA keys are the most common type of keys. RSA keys of 2K length offer the best compromise between security and performance. > [!NOTE] RSA keys larger than 2K protect against brute force cracking and are appropriate for > certificates that have expirations of many years. However, whenever key length is doubled, for > example, from 2k to 4k, performance is reduced by a factor greater than 6. ECDSA keys are also supported. In most cases, ECDSA doubles the performance of a 2K RSA key. Supported curves are: - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (also known as prime256v1 (P-256)) ## See Also - [Deploy a Mule Application to a Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) - [View Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/latest/view-health) --- product: Runtime Fabric version: 2.10 --- # Anypoint Runtime Fabric Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API proxies to a Kubernetes cluster that you create, configure, and manage. Watch the Anypoint Runtime Fabric Product Spotlight video to see a quick overview of Runtime Fabric. ![](https://play.vidyard.com/x7B1DALud3noKWbWL9Xwrp.jpg) If you work in public clouds and have some level of expertise in managing a Kubernetes cluster, Runtime Fabric supports: - [Amazon Elastics Kubernetes Service (EKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Google Kubernetes Engine (GKE)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Microsoft Azure Kubernetes Service (AKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat OpenShift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - [Alibaba Cloud Container Service for Kubernetes (ACK)](https://www.google.com/url?q=https://www.alibabacloud.com/product/kubernetes&sa=D&source=docs&ust=1695253295782775&usg=AOvVaw1HvpOJ2m_H7JOIZzcIbyym) If you prefer to standardize your own bare-metal solutions using public K8s distributions, depending on your affinity to public clouds and in-house Kubernetes expertise, the following offerings can enable both On-Prem and public cloud bare-metal solutions: - [Amazon EKS Anywhere (EKS-A)](https://aws.amazon.com/eks/eks-anywhere/) - [Rancher Kubernetes Engine (RKE2)](https://docs.rke2.io/) - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - [VMware Tanzu Kubernetes Grid](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere-supervisor/8-0/using-tkg-service-with-vsphere-supervisor.html) Some capabilities of Anypoint Runtime Fabric include: - Isolation between applications by running a separate Mule runtime server per application. - Ability to run multiple versions of Mule runtime server on the same set of resources. - Scaling applications across multiple replicas. - Automated application fail-over. - Application management with Anypoint Runtime Manager. The Anypoint control plane features, Anypoint CLI, and the Mule Maven Plugin are available universally across all partners. At runtime plane, only Helm based Runtime Fabric management and features are supported for VMWare Tanzu, Alibaba ACK, and Rancher. The feature supportability matrix across platforms is as follows:
Support of following use-casesAWS EKS and AWS EKS-AIBM Openshift OfferingsAKS & GKEVMWare Tanzu, Alibaba ACK, Rancher

Access and use of Anypoint Control Plane including Runtime Manager, Access Management, Anypoint Monitoring, etc.

Yes

Yes

Yes

Yes

Automation toolings such as the Mule Maven Plugin, Runtime Fabric APIs, and Anypoint CLI.

Yes

Yes

Yes

Yes

Runtime Fabric functionality support for compatible K8s versions.

Yes

Yes

Yes

Yes

Security updates for Runtime Fabric core software and Mule runtime engine images.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via helm.

Yes

Yes

Yes

Yes

Customization of application workloads using CRDs via helm.

Yes

Yes

Yes

Yes

Log4j support for App Monitoring

Yes

Yes

Yes

Yes

Troubleshooting through rtfctl report command.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via operator.

-

Yes

-

-

Managed lifecycle of Runtime Fabric software via control plane.

Yes

-

Yes

-

Setup secure properties using rtfctl.

Yes

-

Yes

-

Lifecycle management of Runtime Fabric software via rtfctl.

Yes

-

Yes

-

Full Backup/Restore via rtfctl.

Yes

-

Yes

-

Reference implementations (templates) - performance tuning, CRD configurations K8s best practices, recommended cluster sizing, and network configuration.

Yes

-

-

-

## Anypoint Runtime Fabric as a Shared Responsibility The successful operation of Anypoint Runtime Fabric is a shared responsibility. It is critical to understand which areas you provide and manage and which areas MuleSoft provides. The following image illustrates different MuleSoft and customer responsibilities for Anypoint Runtime Fabric instances: ![Anypoint Runtime Fabric shared responsibilities diagram](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-shared-responsibility.png) ### MuleSoft Provided MuleSoft provides the Runtime Fabric agent, Mule runtime engine (Mule), and other dependencies used to deploy Mule applications. The Runtime Fabric agent deploys and manages Mule applications by generating and updating Kubernetes resources such as deployments, pods, Replicasets, and ingress resources. #### Runtime Fabric Core Services Anypoint Runtime Fabric and its underlying components run as Kubernetes deployment objects in EKS, AKS, GKE, or RedHat OpenShift environments. You manage the objects via Anypoint Platform. Linux-based operating systems are required for all nodes that run Runtime Fabric components in Kubernetes clusters. - The Runtime Fabric Agent The Runtime Fabric agent is deployed as a pod in the cluster and communicates with the control plane via an mTLS outbound connection established at startup. The agent is event-driven. When an application state change generates a Kubernetes event, the agent sends metadata describing the current state of the application to the control plane. Kubernetes events include application pod starts, updates, or restarts. The agent also listens for incoming requests from the control plane. When the agent receives a message from the control plane, the agent makes changes to the Kubernetes resources specified in the message. Such changes include creating a new application, updating an existing application, or deleting an application. - Mule cluster IP service Provides an API that Mule applications use to discover their peers inside the cluster. - Resource cache Provides a cluster-local cache of application dependencies. These services are isolated within the core Runtime Fabric installation namespace and replicas. These services do not multiply as applications or nodes increase. For more details, review the [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture#security-diagram) diagram. #### Application Services Runtime Fabric installs the following application services only when they are configured by users: - Persistence Gateway: Provides a persistent ObjectStore v2 interface to Mule applications (Replication configured by user) ### Customer Managed Customers are responsible for provisioning, configuring, and managing the Kubernetes cluster used for Runtime Fabric. Additional configuration used to set up or enable capabilities on the Kubernetes cluster, such as those listed below, are also the customer’s responsibility to manage: - Ingress controller and [Customizations to Ingress resources](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration) - External load balancing - Log forwarding - Monitoring - Network ports, NAT gateways, and proxies - Host runtime and networking - Provisioning and management of the Kubernetes environment. This requires assistance from the following teams in your organization: - IT team to provision and manage the infrastructure - Network team to specify allowed ports and configure proxy settings - Security team to verify compliance and obtain security certificates ## How Application Deployments Work in Anypoint Runtime Fabric When you deploy an application in Anypoint Runtime Fabric on, the following occurs: 1. You use Runtime Manager to trigger the application deployment. 2. The Runtime Fabric agent in the target cluster receives a request to deploy the application. 3. Runtime Fabric assigns the application to an existing namespace or creates a new namespace if necessary. 4. Runtime Fabric generates the appropriate Kubernetes resources, including a deployment, ConfigMap, secrets, services, and ingress. 5. If the Kubernetes deployment resource includes an init container, it fetches dependencies from the Runtime Fabric resource cache. 6. If the resource cache doesn’t contain required dependencies, Runtime Fabric fetches them from the control plane and adds them to the resource cache. ![Application deployment workflow for Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-app-deployment.png) To retrieve deployable artifacts, application pods in the worker namespace must communicate with the resource cache in the Runtime Fabric agent namespace. ### Assigning Namespaces in Anypoint Runtime Fabric Each application is deployed into a Kubernetes namespace based on the application’s environment. 1. Runtime Fabric searches for a namespace with the label `rtf.mulesoft.com/envId=`. 2. If Runtime Fabric can’t find that label, it searches for a namespace with the name ``. 3. If Runtime Fabric can’t find that namespace, it creates a new namespace called ``. ![Application namespace assignment flowchart](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-namespace-flow.png) ### Monitoring Application Deployments The Runtime Fabric agent monitors Kubernetes Deployments labelled with `rtf.mulesoft.com/id`. When Kubernetes updates the state of the deployment, the agent sends that update to the control plane. See [Logs](https://docs.mulesoft.com/runtime-fabric/2.10/limitations-self#logs) and [Monitoring](https://docs.mulesoft.com/runtime-fabric/2.10/limitations-self#monitoring) for additional information. ## Feature Support List for Runtime Fabric The following table lists supported and non-supported features.
FeatureStatus

Support for deploying Mules and API Gateways

Supported

Kubernetes and Docker

Not included.

Provide your instances of Kubernetes and Docker via Amazon EKS, AKS or GKE clusters.

Installing on any Linux distribution

Supported

Node auto-scaling

Supported using AWS, Azure, Google Cloud, or RedHat OpenShift functionality

External log forwarding

You can set up Log4j to forward logs to external systems.

Internal load balancer

You must provide an internal load balancer (Ingress Controller)

Anypoint Security Edge

Not supported

Anypoint Security Tokenization

Not supported

Ops Center

Not Included
You can enable monitoring and alerting in AWS, Azure, Google Cloud, or RedHat OpenShift

## Anypoint Runtime Fabric and Standalone Mule Runtimes (Hybrid Deployments) Hybrid deployments of Mule applications require you to install a version of the Mule runtime on a server and deploy one or more applications on the server. Each application shares the Mule runtime server and the resources allocated to it. Other resources such as certificates or database connections may also be shared using domains. Anypoint Runtime Fabric provisions resources differently. Each Mule application and API gateway runs within its own Mule runtime and in its own container. The resources available to the container are specified when deploying a Mule application or API proxy. This enables Mule applications to horizontally scale across nodes without relying on other dependencies. It also ensures that different applications do not compete with each other for resources on the same node. --- product: Runtime Fabric version: 2.11 --- # Anypoint Runtime Fabric Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API proxies to a Kubernetes cluster that you create, configure, and manage. Runtime Fabric isolates applications by running a separate Mule runtime server per application and supports automated fail-over and horizontal scaling across multiple replicas. You can use Runtime Fabric with managed Kubernetes services like EKS, AKS, and GKE, or with self-managed distributions like Red Hat OpenShift and Rancher. Watch the Anypoint Runtime Fabric Product Spotlight video to see a quick overview of Runtime Fabric. ![](https://play.vidyard.com/x7B1DALud3noKWbWL9Xwrp.jpg) If you work in public clouds and have some level of expertise in managing a Kubernetes cluster, Runtime Fabric supports: - [Amazon Elastics Kubernetes Service (EKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Google Kubernetes Engine (GKE)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Microsoft Azure Kubernetes Service (AKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat OpenShift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - [Alibaba Cloud Container Service for Kubernetes (ACK)](https://www.google.com/url?q=https://www.alibabacloud.com/product/kubernetes&sa=D&source=docs&ust=1695253295782775&usg=AOvVaw1HvpOJ2m_H7JOIZzcIbyym) If you prefer to standardize your own bare-metal solutions using public K8s distributions, depending on your affinity to public clouds and in-house Kubernetes expertise, these offerings can enable both On-Prem and public cloud bare-metal solutions: - [Amazon EKS Anywhere (EKS-A)](https://aws.amazon.com/eks/eks-anywhere/) - [Rancher Kubernetes Engine (RKE2)](https://docs.rke2.io/) - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - [VMware Tanzu Kubernetes Grid](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere-supervisor/8-0/using-tkg-service-with-vsphere-supervisor.html) Some capabilities of Anypoint Runtime Fabric include: - Isolation between applications by running a separate Mule runtime server per application. - Ability to run multiple versions of Mule runtime server on the same set of resources. - Scaling applications across multiple replicas. - Automated application fail-over. - Application management with Anypoint Runtime Manager. The Anypoint control plane features, Anypoint CLI, and the Mule Maven Plugin are available universally across all partners. At runtime plane, only Helm based Runtime Fabric management and features are supported for VMWare Tanzu, Alibaba ACK, and Rancher. The feature supportability matrix across platforms is as follows:
Support of following use-casesAWS EKS and AWS EKS-AIBM Openshift OfferingsAKS & GKEVMWare Tanzu, Alibaba ACK, Rancher

Access and use of Anypoint Control Plane including Runtime Manager, Access Management, Anypoint Monitoring, etc.

Yes

Yes

Yes

Yes

Automation toolings such as the Mule Maven Plugin, Runtime Fabric APIs, and Anypoint CLI.

Yes

Yes

Yes

Yes

Runtime Fabric functionality support for compatible K8s versions.

Yes

Yes

Yes

Yes

Security updates for Runtime Fabric core software and Mule runtime engine images.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via helm.

Yes

Yes

Yes

Yes

Customization of application workloads using CRDs via helm.

Yes

Yes

Yes

Yes

Log4j support for App Monitoring

Yes

Yes

Yes

Yes

Troubleshooting through rtfctl report command.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via operator.

-

Yes

-

-

Managed lifecycle of Runtime Fabric software via control plane.

Yes

-

Yes

-

Setup secure properties using rtfctl.

Yes

-

Yes

-

Lifecycle management of Runtime Fabric software via rtfctl.

Yes

-

Yes

-

Full Backup/Restore via rtfctl.

Yes

-

Yes

-

Reference implementations (templates) - performance tuning, CRD configurations K8s best practices, recommended cluster sizing, and network configuration.

Yes

-

-

-

## Anypoint Runtime Fabric as a Shared Responsibility The successful operation of Anypoint Runtime Fabric is a shared responsibility. It is critical to understand which areas you provide and manage and which areas MuleSoft provides. The following image illustrates different MuleSoft and customer responsibilities for Anypoint Runtime Fabric instances: ![Anypoint Runtime Fabric shared responsibilities diagram](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-shared-responsibility.png) ### MuleSoft Provided MuleSoft provides the Runtime Fabric agent, Mule runtime engine (Mule), and other dependencies used to deploy Mule applications. The Runtime Fabric agent deploys and manages Mule applications by generating and updating Kubernetes resources such as deployments, pods, Replicasets, and ingress resources. #### Runtime Fabric Core Services Anypoint Runtime Fabric and its underlying components run as Kubernetes deployment objects in EKS, AKS, GKE, or RedHat OpenShift environments. You manage the objects via Anypoint Platform. Linux-based operating systems are required for all nodes that run Runtime Fabric components in Kubernetes clusters. - The Runtime Fabric Agent The Runtime Fabric agent is deployed as a pod in the cluster and communicates with the control plane via an mTLS outbound connection established at startup. The agent is event-driven. When an application state change generates a Kubernetes event, the agent sends metadata describing the current state of the application to the control plane. Kubernetes events include application pod starts, updates, or restarts. The agent also listens for incoming requests from the control plane. When the agent receives a message from the control plane, the agent makes changes to the Kubernetes resources specified in the message. Such changes include creating a new application, updating an existing application, or deleting an application. - Mule cluster IP service Provides an API that Mule applications use to discover their peers inside the cluster. - Resource cache Provides a cluster-local cache of application dependencies. These services are isolated within the core Runtime Fabric installation namespace and replicas. These services do not multiply as applications or nodes increase. For more details, review the [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture#security-diagram) diagram. #### Application Services Runtime Fabric installs these application services only when they are configured by users: - Persistence Gateway: Provides a persistent ObjectStore v2 interface to Mule applications (Replication configured by user) ### Customer Managed Customers are responsible for provisioning, configuring, and managing the Kubernetes cluster used for Runtime Fabric. Additional configuration used to set up or enable capabilities on the Kubernetes cluster, such as those listed below, are also the customer’s responsibility to manage: - Ingress controller and [Customizations to Ingress resources](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration) - External load balancing - Log forwarding - Monitoring - Network ports, NAT gateways, and proxies - Host runtime and networking - Provisioning and management of the Kubernetes environment. This requires assistance from these teams in your organization: - IT team to provision and manage the infrastructure - Network team to specify allowed ports and configure proxy settings - Security team to verify compliance and obtain security certificates ## How Application Deployments Work in Anypoint Runtime Fabric When you deploy an application in Anypoint Runtime Fabric on, this occurs: 1. You use Runtime Manager to trigger the application deployment. 2. The Runtime Fabric agent in the target cluster receives a request to deploy the application. 3. Runtime Fabric assigns the application to an existing namespace or creates a new namespace if necessary. 4. Runtime Fabric generates the appropriate Kubernetes resources, including a deployment, ConfigMap, secrets, services, and ingress. 5. If the Kubernetes deployment resource includes an init container, it fetches dependencies from the Runtime Fabric resource cache. 6. If the resource cache doesn’t contain required dependencies, Runtime Fabric fetches them from the control plane and adds them to the resource cache. ![Application deployment workflow for Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-app-deployment.png) To retrieve deployable artifacts, application pods in the worker namespace must communicate with the resource cache in the Runtime Fabric agent namespace. ### Assigning Namespaces in Anypoint Runtime Fabric Each application is deployed into a Kubernetes namespace based on the application’s environment. 1. Runtime Fabric searches for a namespace with the label `rtf.mulesoft.com/envId=`. 2. If Runtime Fabric can’t find that label, it searches for a namespace with the name ``. 3. If Runtime Fabric can’t find that namespace, it creates a new namespace called ``. ![Application namespace assignment flowchart](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-namespace-flow.png) ### Monitoring Application Deployments The Runtime Fabric agent monitors Kubernetes Deployments labelled with `rtf.mulesoft.com/id`. When Kubernetes updates the state of the deployment, the agent sends that update to the control plane. See [Logs](https://docs.mulesoft.com/runtime-fabric/2.11/limitations-self#logs) and [Monitoring](https://docs.mulesoft.com/runtime-fabric/2.11/limitations-self#monitoring) for additional information. ## Feature Support List for Runtime Fabric The following table lists supported and non-supported features.
FeatureStatus

Support for deploying Mules and API Gateways

Supported

Kubernetes and Docker

Not included.

Provide your instances of Kubernetes and Docker via Amazon EKS, AKS or GKE clusters.

Installing on any Linux distribution

Supported

Node auto-scaling

Supported using AWS, Azure, Google Cloud, or RedHat OpenShift functionality

External log forwarding

You can set up Log4j to forward logs to external systems.

Internal load balancer

You must provide an internal load balancer (Ingress Controller)

Anypoint Security Edge

Not supported

Anypoint Security Tokenization

Not supported

Ops Center

Not Included
You can enable monitoring and alerting in AWS, Azure, Google Cloud, or RedHat OpenShift

## Anypoint Runtime Fabric and Standalone Mule Runtimes (Hybrid Deployments) Hybrid deployments of Mule applications require you to install a version of the Mule runtime on a server and deploy one or more applications on the server. Each application shares the Mule runtime server and the resources allocated to it. Other resources such as certificates or database connections may also be shared using domains. Anypoint Runtime Fabric provisions resources differently. Each Mule application and API gateway runs within its own Mule runtime and in its own container. The resources available to the container are specified when deploying a Mule application or API proxy. This enables Mule applications to horizontally scale across nodes without relying on other dependencies. It also ensures that different applications do not compete with each other for resources on the same node. --- product: Runtime Fabric version: 2.5 --- # Anypoint Runtime Fabric Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API proxies to a Kubernetes cluster that you create, configure, and manage. If you work in public clouds and have some level of expertise in managing a Kubernetes cluster, Runtime Fabric supports: - [Amazon Elastics Kubernetes Service (EKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Google Kubernetes Engine (GKE)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Microsoft Azure Kubernetes Service (AKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - [Alibaba Cloud Container Service for Kubernetes (ACK)](https://www.google.com/url?q=https://www.alibabacloud.com/product/kubernetes&sa=D&source=docs&ust=1695253295782775&usg=AOvVaw1HvpOJ2m_H7JOIZzcIbyym) If you prefer to standardize your own bare-metal solutions using public K8s distributions, depending on your affinity to public clouds and in-house Kubernetes expertise, the following offerings can enable both On-Prem and public cloud bare-metal solutions: - [Amazon EKS Anywhere (EKS-A)](https://aws.amazon.com/eks/eks-anywhere/) - [Rancher Kubernetes Engine (RKE)](https://rke.docs.rancher.com/) - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - [VMware Tanzu Kubernetes Grid](https://www.vmware.com/products/app-platform/tanzu-kubernetes-grid) Some capabilities of Anypoint Runtime Fabric include: - Isolation between applications by running a separate Mule runtime server per application. - Ability to run multiple versions of Mule runtime server on the same set of resources. - Scaling applications across multiple replicas. - Automated application fail-over. - Application management with Anypoint Runtime Manager. The Anypoint control plane features, Anypoint CLI, and the Mule Maven Plugin are available universally across all partners. At runtime plane, only Helm based Runtime Fabric management and features are supported for VMWare Tanzu, Alibaba ACK, and Rancher. The feature supportability matrix across platforms is as follows:
Support of following use-casesAWS EKS and AWS EKS-AIBM Openshift OfferingsAKS & GKEVMWare Tanzu, Alibaba ACK, Rancher

Access and use of Anypoint Control Plane including Runtime Manager, Access Management, Anypoint Monitoring, etc.

Yes

Yes

Yes

Yes

Automation toolings such as the Mule Maven Plugin, Runtime Fabric APIs, and Anypoint CLI.

Yes

Yes

Yes

Yes

Runtime Fabric functionality support for compatible K8s versions.

Yes

Yes

Yes

Yes

Security updates for Runtime Fabric core software and Mule runtime engine images.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via helm.

Yes

Yes

Yes

Yes

Customization of application workloads using CRDs via helm.

Yes

Yes

Yes

Yes

Log4j support for App Monitoring

Yes

Yes

Yes

Yes

Troubleshooting through rtfctl report command.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via operator.

-

Yes

-

-

Enable FIPS mode for security.

Yes

-

Yes

-

Managed lifecycle of Runtime Fabric software via control plane.

Yes

-

Yes

-

Setup secure properties using rtfctl.

Yes

-

Yes

-

Lifecycle management of Runtime Fabric software via rtfctl.

Yes

-

Yes

-

Full Backup/Restore via rtfctl.

Yes

-

Yes

-

Reference implementations (templates) - performance tuning, CRD configurations K8s best practices, recommended cluster sizing, and network configuration.

Yes

-

-

-

## Anypoint Runtime Fabric as a Shared Responsibility The successful operation of Anypoint Runtime Fabric is a shared responsibility. It is critical to understand which areas you provide and manage and which areas MuleSoft provides. The following image illustrates different MuleSoft and customer responsibilities for Anypoint Runtime Fabric instances: ![Anypoint Runtime Fabric shared responsibilities diagram](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-shared-responsibility.png) ### MuleSoft Provided MuleSoft provides the Runtime Fabric agent, Mule runtime engine (Mule), and other dependencies used to deploy Mule applications. The Runtime Fabric agent deploys and manages Mule applications by generating and updating Kubernetes resources such as deployments, pods, Replicasets, and ingress resources. #### Runtime Fabric Core Services Anypoint Runtime Fabric and its underlying components run as Kubernetes deployment objects in EKS, AKS, GKE, or RedHat OpenShift environments. You manage the objects via Anypoint Platform. Linux-based operating systems are required for all nodes that run Runtime Fabric components in Kubernetes clusters. - The Runtime Fabric Agent The Runtime Fabric agent is deployed as a pod in the cluster and communicates with the control plane via an mTLS outbound connection established at startup. The agent is event-driven. When an application state change generates a Kubernetes event, the agent sends metadata describing the current state of the application to the control plane. Kubernetes events include application pod starts, updates, or restarts. The agent also listens for incoming requests from the control plane. When the agent receives a message from the control plane, the agent makes changes to the Kubernetes resources specified in the message. Such changes include creating a new application, updating an existing application, or deleting an application. - Mule cluster IP service Provides an API that Mule applications use to discover their peers inside the cluster. - Resource cache Provides a cluster-local cache of application dependencies. These services are isolated within the core Runtime Fabric installation namespace and replicas. These services do not multiply as applications or nodes increase. #### Application Services Runtime Fabric installs the following application services only when they are configured by users: - Persistence Gateway: Provides a persistent ObjectStore v2 interface to Mule applications (Replication configured by user) - Anypoint Monitoring sidecar: For monitoring and logging (One sidecar deployed per application replica) ### Customer Managed Customers are responsible for provisioning, configuring, and managing the Kubernetes cluster used for Runtime Fabric. Additional configuration used to set up or enable capabilities on the Kubernetes cluster, such as those listed below, are also the customer’s responsibility to manage: - Ingress controller and [Customizations to Ingress resources](https://docs.mulesoft.com/runtime-fabric/2.5/custom-ingress-configuration) - External load balancing - Log forwarding - Monitoring - Network ports, NAT gateways, and proxies - Host runtime and networking - Provisioning and management of the Kubernetes environment. This requires assistance from the following teams in your organization: - IT team to provision and manage the infrastructure - Network team to specify allowed ports and configure proxy settings - Security team to verify compliance and obtain security certificates ## How Application Deployments Work in Anypoint Runtime Fabric When you deploy an application in Anypoint Runtime Fabric on, the following occurs: 1. You use Runtime Manager to trigger the application deployment. 2. The Runtime Fabric agent in the target cluster receives a request to deploy the application. 3. Runtime Fabric assigns the application to an existing namespace or creates a new namespace if necessary. 4. Runtime Fabric generates the appropriate Kubernetes resources, including a deployment, ConfigMap, secrets, services, and ingress. 5. If the Kubernetes deployment resource includes an init container, it fetches dependencies from the Runtime Fabric resource cache. 6. If the resource cache doesn’t contain required dependencies, Runtime Fabric fetches them from the control plane and adds them to the resource cache. ![Application deployment workflow for Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-app-deployment.png) ### Assigning Namespaces in Anypoint Runtime Fabric Each application is deployed into a Kubernetes namespace based on the application’s environment. 1. Runtime Fabric searches for a namespace with the label `rtf.mulesoft.com/envId=`. 2. If Runtime Fabric can’t find that label, it searches for a namespace with the name ``. 3. If Runtime Fabric can’t find that namespace, it creates a new namespace called ``. ![Application namespace assignment flowchart](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-namespace-flow.png) ### Monitoring Application Deployments The Runtime Fabric agent monitors Kubernetes Deployments labelled with `rtf.mulesoft.com/id`. When Kubernetes updates the state of the deployment, the agent sends that update to the control plane. See [Logs](https://docs.mulesoft.com/runtime-fabric/2.5/limitations-self#logs) and [Monitoring](https://docs.mulesoft.com/runtime-fabric/2.5/limitations-self#monitoring) for additional information. ## Feature Support List for Runtime Fabric The following table lists supported and non-supported features.
FeatureStatus

Support for deploying Mules and API Gateways

Supported

Kubernetes and Docker

Not included.

Provide your instances of Kubernetes and Docker via Amazon EKS, AKS or GKE clusters.

Installing on any Linux distribution

Supported

Node auto-scaling

Supported using AWS, Azure, Google Cloud, or RedHat OpenShift functionality

External log forwarding

You can set up Log4j to forward logs to external systems.

Internal load balancer

You must provide an internal load balancer (Ingress Controller)

Anypoint Security Edge

Not supported

Anypoint Security Tokenization

Not supported

Ops Center

Not Included
You can enable monitoring and alerting in AWS, Azure, Google Cloud, or RedHat OpenShift

## Anypoint Runtime Fabric and Standalone Mule Runtimes (Hybrid Deployments) Hybrid deployments of Mule applications require you to install a version of the Mule runtime on a server and deploy one or more applications on the server. Each application shares the Mule runtime server and the resources allocated to it. Other resources such as certificates or database connections may also be shared using domains. Anypoint Runtime Fabric provisions resources differently. Each Mule application and API gateway runs within its own Mule runtime and in its own container. The resources available to the container are specified when deploying a Mule application or API proxy. This enables Mule applications to horizontally scale across nodes without relying on other dependencies. It also ensures that different applications do not compete with each other for resources on the same node. --- product: Runtime Fabric version: 2.6 --- # Anypoint Runtime Fabric Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API proxies to a Kubernetes cluster that you create, configure, and manage. If you work in public clouds and have some level of expertise in managing a Kubernetes cluster, Runtime Fabric supports: - [Amazon Elastics Kubernetes Service (EKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Google Kubernetes Engine (GKE)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Microsoft Azure Kubernetes Service (AKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - [Alibaba Cloud Container Service for Kubernetes (ACK)](https://www.google.com/url?q=https://www.alibabacloud.com/product/kubernetes&sa=D&source=docs&ust=1695253295782775&usg=AOvVaw1HvpOJ2m_H7JOIZzcIbyym) If you prefer to standardize your own bare-metal solutions using public K8s distributions, depending on your affinity to public clouds and in-house Kubernetes expertise, the following offerings can enable both On-Prem and public cloud bare-metal solutions: - [Amazon EKS Anywhere (EKS-A)](https://aws.amazon.com/eks/eks-anywhere/) - [Rancher Kubernetes Engine (RKE)](https://rke.docs.rancher.com/) - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - [VMware Tanzu Kubernetes Grid](https://www.vmware.com/products/app-platform/tanzu-kubernetes-grid) Some capabilities of Anypoint Runtime Fabric include: - Isolation between applications by running a separate Mule runtime server per application. - Ability to run multiple versions of Mule runtime server on the same set of resources. - Scaling applications across multiple replicas. - Automated application fail-over. - Application management with Anypoint Runtime Manager. The Anypoint control plane features, Anypoint CLI, and the Mule Maven Plugin are available universally across all partners. At runtime plane, only Helm based Runtime Fabric management and features are supported for VMWare Tanzu, Alibaba ACK, and Rancher. The feature supportability matrix across platforms is as follows:
Support of following use-casesAWS EKS and AWS EKS-AIBM Openshift OfferingsAKS & GKEVMWare Tanzu, Alibaba ACK, Rancher

Access and use of Anypoint Control Plane including Runtime Manager, Access Management, Anypoint Monitoring, etc.

Yes

Yes

Yes

Yes

Automation toolings such as the Mule Maven Plugin, Runtime Fabric APIs, and Anypoint CLI.

Yes

Yes

Yes

Yes

Runtime Fabric functionality support for compatible K8s versions.

Yes

Yes

Yes

Yes

Security updates for Runtime Fabric core software and Mule runtime engine images.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via helm.

Yes

Yes

Yes

Yes

Customization of application workloads using CRDs via helm.

Yes

Yes

Yes

Yes

Log4j support for App Monitoring

Yes

Yes

Yes

Yes

Troubleshooting through rtfctl report command.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via operator.

-

Yes

-

-

Enable FIPS mode for security.

Yes

-

Yes

-

Managed lifecycle of Runtime Fabric software via control plane.

Yes

-

Yes

-

Setup secure properties using rtfctl.

Yes

-

Yes

-

Lifecycle management of Runtime Fabric software via rtfctl.

Yes

-

Yes

-

Full Backup/Restore via rtfctl.

Yes

-

Yes

-

Reference implementations (templates) - performance tuning, CRD configurations K8s best practices, recommended cluster sizing, and network configuration.

Yes

-

-

-

## Anypoint Runtime Fabric as a Shared Responsibility The successful operation of Anypoint Runtime Fabric is a shared responsibility. It is critical to understand which areas you provide and manage and which areas MuleSoft provides. The following image illustrates different MuleSoft and customer responsibilities for Anypoint Runtime Fabric instances: ![Anypoint Runtime Fabric shared responsibilities diagram](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-shared-responsibility.png) ### MuleSoft Provided MuleSoft provides the Runtime Fabric agent, Mule runtime engine (Mule), and other dependencies used to deploy Mule applications. The Runtime Fabric agent deploys and manages Mule applications by generating and updating Kubernetes resources such as deployments, pods, Replicasets, and ingress resources. #### Runtime Fabric Core Services Anypoint Runtime Fabric and its underlying components run as Kubernetes deployment objects in EKS, AKS, GKE, or RedHat OpenShift environments. You manage the objects via Anypoint Platform. Linux-based operating systems are required for all nodes that run Runtime Fabric components in Kubernetes clusters. - The Runtime Fabric Agent The Runtime Fabric agent is deployed as a pod in the cluster and communicates with the control plane via an mTLS outbound connection established at startup. The agent is event-driven. When an application state change generates a Kubernetes event, the agent sends metadata describing the current state of the application to the control plane. Kubernetes events include application pod starts, updates, or restarts. The agent also listens for incoming requests from the control plane. When the agent receives a message from the control plane, the agent makes changes to the Kubernetes resources specified in the message. Such changes include creating a new application, updating an existing application, or deleting an application. - Mule cluster IP service Provides an API that Mule applications use to discover their peers inside the cluster. - Resource cache Provides a cluster-local cache of application dependencies. These services are isolated within the core Runtime Fabric installation namespace and replicas. These services do not multiply as applications or nodes increase. #### Application Services Runtime Fabric installs the following application services only when they are configured by users: - Persistence Gateway: Provides a persistent ObjectStore v2 interface to Mule applications (Replication configured by user) - Anypoint Monitoring sidecar: For monitoring and logging (One sidecar deployed per application replica) ### Customer Managed Customers are responsible for provisioning, configuring, and managing the Kubernetes cluster used for Runtime Fabric. Additional configuration used to set up or enable capabilities on the Kubernetes cluster, such as those listed below, are also the customer’s responsibility to manage: - Ingress controller and [Customizations to Ingress resources](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration) - External load balancing - Log forwarding - Monitoring - Network ports, NAT gateways, and proxies - Host runtime and networking - Provisioning and management of the Kubernetes environment. This requires assistance from the following teams in your organization: - IT team to provision and manage the infrastructure - Network team to specify allowed ports and configure proxy settings - Security team to verify compliance and obtain security certificates ## How Application Deployments Work in Anypoint Runtime Fabric When you deploy an application in Anypoint Runtime Fabric on, the following occurs: 1. You use Runtime Manager to trigger the application deployment. 2. The Runtime Fabric agent in the target cluster receives a request to deploy the application. 3. Runtime Fabric assigns the application to an existing namespace or creates a new namespace if necessary. 4. Runtime Fabric generates the appropriate Kubernetes resources, including a deployment, ConfigMap, secrets, services, and ingress. 5. If the Kubernetes deployment resource includes an init container, it fetches dependencies from the Runtime Fabric resource cache. 6. If the resource cache doesn’t contain required dependencies, Runtime Fabric fetches them from the control plane and adds them to the resource cache. ![Application deployment workflow for Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-app-deployment.png) ### Assigning Namespaces in Anypoint Runtime Fabric Each application is deployed into a Kubernetes namespace based on the application’s environment. 1. Runtime Fabric searches for a namespace with the label `rtf.mulesoft.com/envId=`. 2. If Runtime Fabric can’t find that label, it searches for a namespace with the name ``. 3. If Runtime Fabric can’t find that namespace, it creates a new namespace called ``. ![Application namespace assignment flowchart](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-namespace-flow.png) ### Monitoring Application Deployments The Runtime Fabric agent monitors Kubernetes Deployments labelled with `rtf.mulesoft.com/id`. When Kubernetes updates the state of the deployment, the agent sends that update to the control plane. See [Logs](https://docs.mulesoft.com/runtime-fabric/2.6/limitations-self#logs) and [Monitoring](https://docs.mulesoft.com/runtime-fabric/2.6/limitations-self#monitoring) for additional information. ## Feature Support List for Runtime Fabric The following table lists supported and non-supported features.
FeatureStatus

Support for deploying Mules and API Gateways

Supported

Kubernetes and Docker

Not included.

Provide your instances of Kubernetes and Docker via Amazon EKS, AKS or GKE clusters.

Installing on any Linux distribution

Supported

Node auto-scaling

Supported using AWS, Azure, Google Cloud, or RedHat OpenShift functionality

External log forwarding

You can set up Log4j to forward logs to external systems.

Internal load balancer

You must provide an internal load balancer (Ingress Controller)

Anypoint Security Edge

Not supported

Anypoint Security Tokenization

Not supported

Ops Center

Not Included
You can enable monitoring and alerting in AWS, Azure, Google Cloud, or RedHat OpenShift

## Anypoint Runtime Fabric and Standalone Mule Runtimes (Hybrid Deployments) Hybrid deployments of Mule applications require you to install a version of the Mule runtime on a server and deploy one or more applications on the server. Each application shares the Mule runtime server and the resources allocated to it. Other resources such as certificates or database connections may also be shared using domains. Anypoint Runtime Fabric provisions resources differently. Each Mule application and API gateway runs within its own Mule runtime and in its own container. The resources available to the container are specified when deploying a Mule application or API proxy. This enables Mule applications to horizontally scale across nodes without relying on other dependencies. It also ensures that different applications do not compete with each other for resources on the same node. --- product: Runtime Fabric version: 2.7 --- # Anypoint Runtime Fabric Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API proxies to a Kubernetes cluster that you create, configure, and manage. If you work in public clouds and have some level of expertise in managing a Kubernetes cluster, Runtime Fabric supports: - [Amazon Elastics Kubernetes Service (EKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Google Kubernetes Engine (GKE)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Microsoft Azure Kubernetes Service (AKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - [Alibaba Cloud Container Service for Kubernetes (ACK)](https://www.google.com/url?q=https://www.alibabacloud.com/product/kubernetes&sa=D&source=docs&ust=1695253295782775&usg=AOvVaw1HvpOJ2m_H7JOIZzcIbyym) If you prefer to standardize your own bare-metal solutions using public K8s distributions, depending on your affinity to public clouds and in-house Kubernetes expertise, the following offerings can enable both On-Prem and public cloud bare-metal solutions: - [Amazon EKS Anywhere (EKS-A)](https://aws.amazon.com/eks/eks-anywhere/) - [Rancher Kubernetes Engine (RKE2)](https://docs.rke2.io/) - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - [VMware Tanzu Kubernetes Grid](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere-supervisor/8-0/using-tkg-service-with-vsphere-supervisor.html) Some capabilities of Anypoint Runtime Fabric include: - Isolation between applications by running a separate Mule runtime server per application. - Ability to run multiple versions of Mule runtime server on the same set of resources. - Scaling applications across multiple replicas. - Automated application fail-over. - Application management with Anypoint Runtime Manager. The Anypoint control plane features, Anypoint CLI, and the Mule Maven Plugin are available universally across all partners. At runtime plane, only Helm based Runtime Fabric management and features are supported for VMWare Tanzu, Alibaba ACK, and Rancher. The feature supportability matrix across platforms is as follows:
Support of following use-casesAWS EKS and AWS EKS-AIBM Openshift OfferingsAKS & GKEVMWare Tanzu, Alibaba ACK, Rancher

Access and use of Anypoint Control Plane including Runtime Manager, Access Management, Anypoint Monitoring, etc.

Yes

Yes

Yes

Yes

Automation toolings such as the Mule Maven Plugin, Runtime Fabric APIs, and Anypoint CLI.

Yes

Yes

Yes

Yes

Runtime Fabric functionality support for compatible K8s versions.

Yes

Yes

Yes

Yes

Security updates for Runtime Fabric core software and Mule runtime engine images.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via helm.

Yes

Yes

Yes

Yes

Customization of application workloads using CRDs via helm.

Yes

Yes

Yes

Yes

Log4j support for App Monitoring

Yes

Yes

Yes

Yes

Troubleshooting through rtfctl report command.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via operator.

-

Yes

-

-

Managed lifecycle of Runtime Fabric software via control plane.

Yes

-

Yes

-

Setup secure properties using rtfctl.

Yes

-

Yes

-

Lifecycle management of Runtime Fabric software via rtfctl.

Yes

-

Yes

-

Full Backup/Restore via rtfctl.

Yes

-

Yes

-

Reference implementations (templates) - performance tuning, CRD configurations K8s best practices, recommended cluster sizing, and network configuration.

Yes

-

-

-

## Anypoint Runtime Fabric as a Shared Responsibility The successful operation of Anypoint Runtime Fabric is a shared responsibility. It is critical to understand which areas you provide and manage and which areas MuleSoft provides. The following image illustrates different MuleSoft and customer responsibilities for Anypoint Runtime Fabric instances: ![Anypoint Runtime Fabric shared responsibilities diagram](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-shared-responsibility.png) ### MuleSoft Provided MuleSoft provides the Runtime Fabric agent, Mule runtime engine (Mule), and other dependencies used to deploy Mule applications. The Runtime Fabric agent deploys and manages Mule applications by generating and updating Kubernetes resources such as deployments, pods, Replicasets, and ingress resources. #### Runtime Fabric Core Services Anypoint Runtime Fabric and its underlying components run as Kubernetes deployment objects in EKS, AKS, GKE, or RedHat OpenShift environments. You manage the objects via Anypoint Platform. Linux-based operating systems are required for all nodes that run Runtime Fabric components in Kubernetes clusters. - The Runtime Fabric Agent The Runtime Fabric agent is deployed as a pod in the cluster and communicates with the control plane via an mTLS outbound connection established at startup. The agent is event-driven. When an application state change generates a Kubernetes event, the agent sends metadata describing the current state of the application to the control plane. Kubernetes events include application pod starts, updates, or restarts. The agent also listens for incoming requests from the control plane. When the agent receives a message from the control plane, the agent makes changes to the Kubernetes resources specified in the message. Such changes include creating a new application, updating an existing application, or deleting an application. - Mule cluster IP service Provides an API that Mule applications use to discover their peers inside the cluster. - Resource cache Provides a cluster-local cache of application dependencies. These services are isolated within the core Runtime Fabric installation namespace and replicas. These services do not multiply as applications or nodes increase. #### Application Services Runtime Fabric installs the following application services only when they are configured by users: - Persistence Gateway: Provides a persistent ObjectStore v2 interface to Mule applications (Replication configured by user) - Anypoint Monitoring sidecar: For monitoring and logging (One sidecar deployed per application replica) ### Customer Managed Customers are responsible for provisioning, configuring, and managing the Kubernetes cluster used for Runtime Fabric. Additional configuration used to set up or enable capabilities on the Kubernetes cluster, such as those listed below, are also the customer’s responsibility to manage: - Ingress controller and [Customizations to Ingress resources](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration) - External load balancing - Log forwarding - Monitoring - Network ports, NAT gateways, and proxies - Host runtime and networking - Provisioning and management of the Kubernetes environment. This requires assistance from the following teams in your organization: - IT team to provision and manage the infrastructure - Network team to specify allowed ports and configure proxy settings - Security team to verify compliance and obtain security certificates ## How Application Deployments Work in Anypoint Runtime Fabric When you deploy an application in Anypoint Runtime Fabric on, the following occurs: 1. You use Runtime Manager to trigger the application deployment. 2. The Runtime Fabric agent in the target cluster receives a request to deploy the application. 3. Runtime Fabric assigns the application to an existing namespace or creates a new namespace if necessary. 4. Runtime Fabric generates the appropriate Kubernetes resources, including a deployment, ConfigMap, secrets, services, and ingress. 5. If the Kubernetes deployment resource includes an init container, it fetches dependencies from the Runtime Fabric resource cache. 6. If the resource cache doesn’t contain required dependencies, Runtime Fabric fetches them from the control plane and adds them to the resource cache. ![Application deployment workflow for Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-app-deployment.png) ### Assigning Namespaces in Anypoint Runtime Fabric Each application is deployed into a Kubernetes namespace based on the application’s environment. 1. Runtime Fabric searches for a namespace with the label `rtf.mulesoft.com/envId=`. 2. If Runtime Fabric can’t find that label, it searches for a namespace with the name ``. 3. If Runtime Fabric can’t find that namespace, it creates a new namespace called ``. ![Application namespace assignment flowchart](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-namespace-flow.png) ### Monitoring Application Deployments The Runtime Fabric agent monitors Kubernetes Deployments labelled with `rtf.mulesoft.com/id`. When Kubernetes updates the state of the deployment, the agent sends that update to the control plane. See [Logs](https://docs.mulesoft.com/runtime-fabric/2.7/limitations-self#logs) and [Monitoring](https://docs.mulesoft.com/runtime-fabric/2.7/limitations-self#monitoring) for additional information. ## Feature Support List for Runtime Fabric The following table lists supported and non-supported features.
FeatureStatus

Support for deploying Mules and API Gateways

Supported

Kubernetes and Docker

Not included.

Provide your instances of Kubernetes and Docker via Amazon EKS, AKS or GKE clusters.

Installing on any Linux distribution

Supported

Node auto-scaling

Supported using AWS, Azure, Google Cloud, or RedHat OpenShift functionality

External log forwarding

You can set up Log4j to forward logs to external systems.

Internal load balancer

You must provide an internal load balancer (Ingress Controller)

Anypoint Security Edge

Not supported

Anypoint Security Tokenization

Not supported

Ops Center

Not Included
You can enable monitoring and alerting in AWS, Azure, Google Cloud, or RedHat OpenShift

## Anypoint Runtime Fabric and Standalone Mule Runtimes (Hybrid Deployments) Hybrid deployments of Mule applications require you to install a version of the Mule runtime on a server and deploy one or more applications on the server. Each application shares the Mule runtime server and the resources allocated to it. Other resources such as certificates or database connections may also be shared using domains. Anypoint Runtime Fabric provisions resources differently. Each Mule application and API gateway runs within its own Mule runtime and in its own container. The resources available to the container are specified when deploying a Mule application or API proxy. This enables Mule applications to horizontally scale across nodes without relying on other dependencies. It also ensures that different applications do not compete with each other for resources on the same node. --- product: Runtime Fabric version: 2.8 --- # Anypoint Runtime Fabric Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API proxies to a Kubernetes cluster that you create, configure, and manage. If you work in public clouds and have some level of expertise in managing a Kubernetes cluster, Runtime Fabric supports: - [Amazon Elastics Kubernetes Service (EKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Google Kubernetes Engine (GKE)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Microsoft Azure Kubernetes Service (AKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat OpenShift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - [Alibaba Cloud Container Service for Kubernetes (ACK)](https://www.google.com/url?q=https://www.alibabacloud.com/product/kubernetes&sa=D&source=docs&ust=1695253295782775&usg=AOvVaw1HvpOJ2m_H7JOIZzcIbyym) If you prefer to standardize your own bare-metal solutions using public K8s distributions, depending on your affinity to public clouds and in-house Kubernetes expertise, the following offerings can enable both On-Prem and public cloud bare-metal solutions: - [Amazon EKS Anywhere (EKS-A)](https://aws.amazon.com/eks/eks-anywhere/) - [Rancher Kubernetes Engine (RKE2)](https://docs.rke2.io/) - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - [VMware Tanzu Kubernetes Grid](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere-supervisor/8-0/using-tkg-service-with-vsphere-supervisor.html) Some capabilities of Anypoint Runtime Fabric include: - Isolation between applications by running a separate Mule runtime server per application. - Ability to run multiple versions of Mule runtime server on the same set of resources. - Scaling applications across multiple replicas. - Automated application fail-over. - Application management with Anypoint Runtime Manager. The Anypoint control plane features, Anypoint CLI, and the Mule Maven Plugin are available universally across all partners. At runtime plane, only Helm based Runtime Fabric management and features are supported for VMWare Tanzu, Alibaba ACK, and Rancher. The feature supportability matrix across platforms is as follows:
Support of following use-casesAWS EKS and AWS EKS-AIBM Openshift OfferingsAKS & GKEVMWare Tanzu, Alibaba ACK, Rancher

Access and use of Anypoint Control Plane including Runtime Manager, Access Management, Anypoint Monitoring, etc.

Yes

Yes

Yes

Yes

Automation toolings such as the Mule Maven Plugin, Runtime Fabric APIs, and Anypoint CLI.

Yes

Yes

Yes

Yes

Runtime Fabric functionality support for compatible K8s versions.

Yes

Yes

Yes

Yes

Security updates for Runtime Fabric core software and Mule runtime engine images.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via helm.

Yes

Yes

Yes

Yes

Customization of application workloads using CRDs via helm.

Yes

Yes

Yes

Yes

Log4j support for App Monitoring

Yes

Yes

Yes

Yes

Troubleshooting through rtfctl report command.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via operator.

-

Yes

-

-

Managed lifecycle of Runtime Fabric software via control plane.

Yes

-

Yes

-

Setup secure properties using rtfctl.

Yes

-

Yes

-

Lifecycle management of Runtime Fabric software via rtfctl.

Yes

-

Yes

-

Full Backup/Restore via rtfctl.

Yes

-

Yes

-

Reference implementations (templates) - performance tuning, CRD configurations K8s best practices, recommended cluster sizing, and network configuration.

Yes

-

-

-

## Anypoint Runtime Fabric as a Shared Responsibility The successful operation of Anypoint Runtime Fabric is a shared responsibility. It is critical to understand which areas you provide and manage and which areas MuleSoft provides. The following image illustrates different MuleSoft and customer responsibilities for Anypoint Runtime Fabric instances: ![Anypoint Runtime Fabric shared responsibilities diagram](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-shared-responsibility.png) ### MuleSoft Provided MuleSoft provides the Runtime Fabric agent, Mule runtime engine (Mule), and other dependencies used to deploy Mule applications. The Runtime Fabric agent deploys and manages Mule applications by generating and updating Kubernetes resources such as deployments, pods, Replicasets, and ingress resources. #### Runtime Fabric Core Services Anypoint Runtime Fabric and its underlying components run as Kubernetes deployment objects in EKS, AKS, GKE, or RedHat OpenShift environments. You manage the objects via Anypoint Platform. Linux-based operating systems are required for all nodes that run Runtime Fabric components in Kubernetes clusters. - The Runtime Fabric Agent The Runtime Fabric agent is deployed as a pod in the cluster and communicates with the control plane via an mTLS outbound connection established at startup. The agent is event-driven. When an application state change generates a Kubernetes event, the agent sends metadata describing the current state of the application to the control plane. Kubernetes events include application pod starts, updates, or restarts. The agent also listens for incoming requests from the control plane. When the agent receives a message from the control plane, the agent makes changes to the Kubernetes resources specified in the message. Such changes include creating a new application, updating an existing application, or deleting an application. - Mule cluster IP service Provides an API that Mule applications use to discover their peers inside the cluster. - Resource cache Provides a cluster-local cache of application dependencies. These services are isolated within the core Runtime Fabric installation namespace and replicas. These services do not multiply as applications or nodes increase. For more details, review the [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture#security-diagram) diagram. #### Application Services Runtime Fabric installs the following application services only when they are configured by users: - Persistence Gateway: Provides a persistent ObjectStore v2 interface to Mule applications (Replication configured by user) - Anypoint Monitoring sidecar: For monitoring and logging (One sidecar deployed per application replica) ### Customer Managed Customers are responsible for provisioning, configuring, and managing the Kubernetes cluster used for Runtime Fabric. Additional configuration used to set up or enable capabilities on the Kubernetes cluster, such as those listed below, are also the customer’s responsibility to manage: - Ingress controller and [Customizations to Ingress resources](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration) - External load balancing - Log forwarding - Monitoring - Network ports, NAT gateways, and proxies - Host runtime and networking - Provisioning and management of the Kubernetes environment. This requires assistance from the following teams in your organization: - IT team to provision and manage the infrastructure - Network team to specify allowed ports and configure proxy settings - Security team to verify compliance and obtain security certificates ## How Application Deployments Work in Anypoint Runtime Fabric When you deploy an application in Anypoint Runtime Fabric on, the following occurs: 1. You use Runtime Manager to trigger the application deployment. 2. The Runtime Fabric agent in the target cluster receives a request to deploy the application. 3. Runtime Fabric assigns the application to an existing namespace or creates a new namespace if necessary. 4. Runtime Fabric generates the appropriate Kubernetes resources, including a deployment, ConfigMap, secrets, services, and ingress. 5. If the Kubernetes deployment resource includes an init container, it fetches dependencies from the Runtime Fabric resource cache. 6. If the resource cache doesn’t contain required dependencies, Runtime Fabric fetches them from the control plane and adds them to the resource cache. ![Application deployment workflow for Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-app-deployment.png) ### Assigning Namespaces in Anypoint Runtime Fabric Each application is deployed into a Kubernetes namespace based on the application’s environment. 1. Runtime Fabric searches for a namespace with the label `rtf.mulesoft.com/envId=`. 2. If Runtime Fabric can’t find that label, it searches for a namespace with the name ``. 3. If Runtime Fabric can’t find that namespace, it creates a new namespace called ``. ![Application namespace assignment flowchart](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-namespace-flow.png) ### Monitoring Application Deployments The Runtime Fabric agent monitors Kubernetes Deployments labelled with `rtf.mulesoft.com/id`. When Kubernetes updates the state of the deployment, the agent sends that update to the control plane. See [Logs](https://docs.mulesoft.com/runtime-fabric/2.8/limitations-self#logs) and [Monitoring](https://docs.mulesoft.com/runtime-fabric/2.8/limitations-self#monitoring) for additional information. ## Feature Support List for Runtime Fabric The following table lists supported and non-supported features.
FeatureStatus

Support for deploying Mules and API Gateways

Supported

Kubernetes and Docker

Not included.

Provide your instances of Kubernetes and Docker via Amazon EKS, AKS or GKE clusters.

Installing on any Linux distribution

Supported

Node auto-scaling

Supported using AWS, Azure, Google Cloud, or RedHat OpenShift functionality

External log forwarding

You can set up Log4j to forward logs to external systems.

Internal load balancer

You must provide an internal load balancer (Ingress Controller)

Anypoint Security Edge

Not supported

Anypoint Security Tokenization

Not supported

Ops Center

Not Included
You can enable monitoring and alerting in AWS, Azure, Google Cloud, or RedHat OpenShift

## Anypoint Runtime Fabric and Standalone Mule Runtimes (Hybrid Deployments) Hybrid deployments of Mule applications require you to install a version of the Mule runtime on a server and deploy one or more applications on the server. Each application shares the Mule runtime server and the resources allocated to it. Other resources such as certificates or database connections may also be shared using domains. Anypoint Runtime Fabric provisions resources differently. Each Mule application and API gateway runs within its own Mule runtime and in its own container. The resources available to the container are specified when deploying a Mule application or API proxy. This enables Mule applications to horizontally scale across nodes without relying on other dependencies. It also ensures that different applications do not compete with each other for resources on the same node. --- product: Runtime Fabric version: 2.9 --- # Anypoint Runtime Fabric Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API proxies to a Kubernetes cluster that you create, configure, and manage. If you work in public clouds and have some level of expertise in managing a Kubernetes cluster, Runtime Fabric supports: - [Amazon Elastics Kubernetes Service (EKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Google Kubernetes Engine (GKE)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Microsoft Azure Kubernetes Service (AKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat OpenShift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - [Alibaba Cloud Container Service for Kubernetes (ACK)](https://www.google.com/url?q=https://www.alibabacloud.com/product/kubernetes&sa=D&source=docs&ust=1695253295782775&usg=AOvVaw1HvpOJ2m_H7JOIZzcIbyym) If you prefer to standardize your own bare-metal solutions using public K8s distributions, depending on your affinity to public clouds and in-house Kubernetes expertise, the following offerings can enable both On-Prem and public cloud bare-metal solutions: - [Amazon EKS Anywhere (EKS-A)](https://aws.amazon.com/eks/eks-anywhere/) - [Rancher Kubernetes Engine (RKE2)](https://docs.rke2.io/) - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - [VMware Tanzu Kubernetes Grid](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere-supervisor/8-0/using-tkg-service-with-vsphere-supervisor.html) Some capabilities of Anypoint Runtime Fabric include: - Isolation between applications by running a separate Mule runtime server per application. - Ability to run multiple versions of Mule runtime server on the same set of resources. - Scaling applications across multiple replicas. - Automated application fail-over. - Application management with Anypoint Runtime Manager. The Anypoint control plane features, Anypoint CLI, and the Mule Maven Plugin are available universally across all partners. At runtime plane, only Helm based Runtime Fabric management and features are supported for VMWare Tanzu, Alibaba ACK, and Rancher. The feature supportability matrix across platforms is as follows:
Support of following use-casesAWS EKS and AWS EKS-AIBM Openshift OfferingsAKS & GKEVMWare Tanzu, Alibaba ACK, Rancher

Access and use of Anypoint Control Plane including Runtime Manager, Access Management, Anypoint Monitoring, etc.

Yes

Yes

Yes

Yes

Automation toolings such as the Mule Maven Plugin, Runtime Fabric APIs, and Anypoint CLI.

Yes

Yes

Yes

Yes

Runtime Fabric functionality support for compatible K8s versions.

Yes

Yes

Yes

Yes

Security updates for Runtime Fabric core software and Mule runtime engine images.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via helm.

Yes

Yes

Yes

Yes

Customization of application workloads using CRDs via helm.

Yes

Yes

Yes

Yes

Log4j support for App Monitoring

Yes

Yes

Yes

Yes

Troubleshooting through rtfctl report command.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via operator.

-

Yes

-

-

Managed lifecycle of Runtime Fabric software via control plane.

Yes

-

Yes

-

Setup secure properties using rtfctl.

Yes

-

Yes

-

Lifecycle management of Runtime Fabric software via rtfctl.

Yes

-

Yes

-

Full Backup/Restore via rtfctl.

Yes

-

Yes

-

Reference implementations (templates) - performance tuning, CRD configurations K8s best practices, recommended cluster sizing, and network configuration.

Yes

-

-

-

## Anypoint Runtime Fabric as a Shared Responsibility The successful operation of Anypoint Runtime Fabric is a shared responsibility. It is critical to understand which areas you provide and manage and which areas MuleSoft provides. The following image illustrates different MuleSoft and customer responsibilities for Anypoint Runtime Fabric instances: ![Anypoint Runtime Fabric shared responsibilities diagram](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-shared-responsibility.png) ### MuleSoft Provided MuleSoft provides the Runtime Fabric agent, Mule runtime engine (Mule), and other dependencies used to deploy Mule applications. The Runtime Fabric agent deploys and manages Mule applications by generating and updating Kubernetes resources such as deployments, pods, Replicasets, and ingress resources. #### Runtime Fabric Core Services Anypoint Runtime Fabric and its underlying components run as Kubernetes deployment objects in EKS, AKS, GKE, or RedHat OpenShift environments. You manage the objects via Anypoint Platform. Linux-based operating systems are required for all nodes that run Runtime Fabric components in Kubernetes clusters. - The Runtime Fabric Agent The Runtime Fabric agent is deployed as a pod in the cluster and communicates with the control plane via an mTLS outbound connection established at startup. The agent is event-driven. When an application state change generates a Kubernetes event, the agent sends metadata describing the current state of the application to the control plane. Kubernetes events include application pod starts, updates, or restarts. The agent also listens for incoming requests from the control plane. When the agent receives a message from the control plane, the agent makes changes to the Kubernetes resources specified in the message. Such changes include creating a new application, updating an existing application, or deleting an application. - Mule cluster IP service Provides an API that Mule applications use to discover their peers inside the cluster. - Resource cache Provides a cluster-local cache of application dependencies. These services are isolated within the core Runtime Fabric installation namespace and replicas. These services do not multiply as applications or nodes increase. For more details, review the [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture#security-diagram) diagram. #### Application Services Runtime Fabric installs the following application services only when they are configured by users: - Persistence Gateway: Provides a persistent ObjectStore v2 interface to Mule applications (Replication configured by user) ### Customer Managed Customers are responsible for provisioning, configuring, and managing the Kubernetes cluster used for Runtime Fabric. Additional configuration used to set up or enable capabilities on the Kubernetes cluster, such as those listed below, are also the customer’s responsibility to manage: - Ingress controller and [Customizations to Ingress resources](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration) - External load balancing - Log forwarding - Monitoring - Network ports, NAT gateways, and proxies - Host runtime and networking - Provisioning and management of the Kubernetes environment. This requires assistance from the following teams in your organization: - IT team to provision and manage the infrastructure - Network team to specify allowed ports and configure proxy settings - Security team to verify compliance and obtain security certificates ## How Application Deployments Work in Anypoint Runtime Fabric When you deploy an application in Anypoint Runtime Fabric on, the following occurs: 1. You use Runtime Manager to trigger the application deployment. 2. The Runtime Fabric agent in the target cluster receives a request to deploy the application. 3. Runtime Fabric assigns the application to an existing namespace or creates a new namespace if necessary. 4. Runtime Fabric generates the appropriate Kubernetes resources, including a deployment, ConfigMap, secrets, services, and ingress. 5. If the Kubernetes deployment resource includes an init container, it fetches dependencies from the Runtime Fabric resource cache. 6. If the resource cache doesn’t contain required dependencies, Runtime Fabric fetches them from the control plane and adds them to the resource cache. ![Application deployment workflow for Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-app-deployment.png) To retrieve deployable artifacts, application pods in the worker namespace must communicate with the resource cache in the Runtime Fabric agent namespace. ### Assigning Namespaces in Anypoint Runtime Fabric Each application is deployed into a Kubernetes namespace based on the application’s environment. 1. Runtime Fabric searches for a namespace with the label `rtf.mulesoft.com/envId=`. 2. If Runtime Fabric can’t find that label, it searches for a namespace with the name ``. 3. If Runtime Fabric can’t find that namespace, it creates a new namespace called ``. ![Application namespace assignment flowchart](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-namespace-flow.png) ### Monitoring Application Deployments The Runtime Fabric agent monitors Kubernetes Deployments labelled with `rtf.mulesoft.com/id`. When Kubernetes updates the state of the deployment, the agent sends that update to the control plane. See [Logs](https://docs.mulesoft.com/runtime-fabric/2.9/limitations-self#logs) and [Monitoring](https://docs.mulesoft.com/runtime-fabric/2.9/limitations-self#monitoring) for additional information. ## Feature Support List for Runtime Fabric The following table lists supported and non-supported features.
FeatureStatus

Support for deploying Mules and API Gateways

Supported

Kubernetes and Docker

Not included.

Provide your instances of Kubernetes and Docker via Amazon EKS, AKS or GKE clusters.

Installing on any Linux distribution

Supported

Node auto-scaling

Supported using AWS, Azure, Google Cloud, or RedHat OpenShift functionality

External log forwarding

You can set up Log4j to forward logs to external systems.

Internal load balancer

You must provide an internal load balancer (Ingress Controller)

Anypoint Security Edge

Not supported

Anypoint Security Tokenization

Not supported

Ops Center

Not Included
You can enable monitoring and alerting in AWS, Azure, Google Cloud, or RedHat OpenShift

## Anypoint Runtime Fabric and Standalone Mule Runtimes (Hybrid Deployments) Hybrid deployments of Mule applications require you to install a version of the Mule runtime on a server and deploy one or more applications on the server. Each application shares the Mule runtime server and the resources allocated to it. Other resources such as certificates or database connections may also be shared using domains. Anypoint Runtime Fabric provisions resources differently. Each Mule application and API gateway runs within its own Mule runtime and in its own container. The resources available to the container are specified when deploying a Mule application or API proxy. This enables Mule applications to horizontally scale across nodes without relying on other dependencies. It also ensures that different applications do not compete with each other for resources on the same node. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Anypoint Runtime Fabric Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API proxies to a Kubernetes cluster that you create, configure, and manage. Runtime Fabric isolates applications by running a separate Mule runtime server per application and supports automated fail-over and horizontal scaling across multiple replicas. You can use Runtime Fabric with managed Kubernetes services like EKS, AKS, GKE, and OKE, or with self-managed distributions like Red Hat OpenShift and Rancher. Watch the Anypoint Runtime Fabric Product Spotlight video to see a quick overview of Runtime Fabric. ![](https://play.vidyard.com/x7B1DALud3noKWbWL9Xwrp.jpg) If you work in public clouds and have some level of expertise in managing a Kubernetes cluster, Runtime Fabric supports: - [Amazon Elastics Kubernetes Service (EKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Google Kubernetes Engine (GKE)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Microsoft Azure Kubernetes Service (AKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Oracle Kubernetes Engine (OKE)](https://www.oracle.com/cloud/cloud-native/kubernetes-engine/) - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat OpenShift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - [Alibaba Cloud Container Service for Kubernetes (ACK)](https://www.google.com/url?q=https://www.alibabacloud.com/product/kubernetes&sa=D&source=docs&ust=1695253295782775&usg=AOvVaw1HvpOJ2m_H7JOIZzcIbyym) If you prefer to standardize your own bare-metal solutions using public K8s distributions, depending on your affinity to public clouds and in-house Kubernetes expertise, the following offerings can enable both On-Prem and public cloud bare-metal solutions: - [Amazon EKS Anywhere (EKS-A)](https://aws.amazon.com/eks/eks-anywhere/) - [Rancher Kubernetes Engine (RKE2)](https://docs.rke2.io/) - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - [VMware Tanzu Kubernetes Grid](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere-supervisor/8-0/using-tkg-service-with-vsphere-supervisor.html) Some capabilities of Anypoint Runtime Fabric include: - Isolation between applications by running a separate Mule runtime server per application. - Ability to run multiple versions of Mule runtime server on the same set of resources. - Scaling applications across multiple replicas. - Automated application fail-over. - Application management with Anypoint Runtime Manager. The Anypoint control plane features, Anypoint CLI, and the Mule Maven Plugin are available universally across all partners. At runtime plane, only Helm based Runtime Fabric management and features are supported for VMWare Tanzu, Alibaba ACK, and Rancher. The feature supportability matrix across platforms is as follows:
Support of following use-casesAWS EKS and AWS EKS-AIBM Openshift OfferingsAKS, GKE & OKEVMWare Tanzu, Alibaba ACK, Rancher

Access and use of Anypoint Control Plane including Runtime Manager, Access Management, Anypoint Monitoring, etc.

Yes

Yes

Yes

Yes

Automation toolings such as the Mule Maven Plugin, Runtime Fabric APIs, and Anypoint CLI.

Yes

Yes

Yes

Yes

Runtime Fabric functionality support for compatible K8s versions.

Yes

Yes

Yes

Yes

Security updates for Runtime Fabric core software and Mule runtime engine images.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via helm.

Yes

Yes

Yes

Yes

Customization of application workloads using CRDs via helm.

Yes

Yes

Yes

Yes

Log4j support for App Monitoring

Yes

Yes

Yes

Yes

Troubleshooting through rtfctl report command.

Yes

Yes

Yes

Yes

Lifecycle management of Runtime Fabric software via operator.

-

Yes

-

-

Managed lifecycle of Runtime Fabric software via control plane.

Yes

-

Yes

-

Setup secure properties using rtfctl.

Yes

-

Yes

-

Lifecycle management of Runtime Fabric software via rtfctl.

Yes

-

Yes

-

Full Backup/Restore via rtfctl.

Yes

-

Yes

-

Reference implementations (templates) - performance tuning, CRD configurations K8s best practices, recommended cluster sizing, and network configuration.

Yes

-

-

-

## Anypoint Runtime Fabric as a Shared Responsibility The successful operation of Anypoint Runtime Fabric is a shared responsibility. It is critical to understand which areas you provide and manage and which areas MuleSoft provides. The following image illustrates different MuleSoft and customer responsibilities for Anypoint Runtime Fabric instances: ![Anypoint Runtime Fabric shared responsibilities diagram](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-shared-responsibility.png) ### MuleSoft Provided MuleSoft provides the Runtime Fabric agent, Mule runtime engine (Mule), and other dependencies used to deploy Mule applications. The Runtime Fabric agent deploys and manages Mule applications by generating and updating Kubernetes resources such as deployments, pods, Replicasets, and ingress resources. #### Runtime Fabric Core Services Anypoint Runtime Fabric and its underlying components run as Kubernetes deployment objects in EKS, AKS, GKE, OKE, or RedHat OpenShift environments. You manage the objects via Anypoint Platform. Linux-based operating systems are required for all nodes that run Runtime Fabric components in Kubernetes clusters. - The Runtime Fabric Agent The Runtime Fabric agent is deployed as a pod in the cluster and communicates with the control plane via an mTLS outbound connection established at startup. The agent is event-driven. When an application state change generates a Kubernetes event, the agent sends metadata describing the current state of the application to the control plane. Kubernetes events include application pod starts, updates, or restarts. The agent also listens for incoming requests from the control plane. When the agent receives a message from the control plane, the agent makes changes to the Kubernetes resources specified in the message. Such changes include creating a new application, updating an existing application, or deleting an application. - Mule cluster IP service Provides an API that Mule applications use to discover their peers inside the cluster. - Resource cache Provides a cluster-local cache of application dependencies. These services are isolated within the core Runtime Fabric installation namespace and replicas. These services do not multiply as applications or nodes increase. For more details, review the [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture#security-diagram) diagram. #### Application Services Runtime Fabric installs the following application services only when they are configured by users: - Persistence Gateway: Provides a persistent ObjectStore v2 interface to Mule applications (Replication configured by user) ### Customer Managed Customers are responsible for provisioning, configuring, and managing the Kubernetes cluster used for Runtime Fabric. Additional configuration used to set up or enable capabilities on the Kubernetes cluster, such as those listed below, are also the customer’s responsibility to manage: - Ingress controller and [Customizations to Ingress resources](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration) - External load balancing - Log forwarding - Monitoring - Network ports, NAT gateways, and proxies - Host runtime and networking - Provisioning and management of the Kubernetes environment. This requires assistance from the following teams in your organization: - IT team to provision and manage the infrastructure - Network team to specify allowed ports and configure proxy settings - Security team to verify compliance and obtain security certificates ## How Application Deployments Work in Anypoint Runtime Fabric When you deploy an application in Anypoint Runtime Fabric on, the following occurs: 1. You use Runtime Manager to trigger the application deployment. 2. The Runtime Fabric agent in the target cluster receives a request to deploy the application. 3. Runtime Fabric assigns the application to an existing namespace or creates a new namespace if necessary. 4. Runtime Fabric generates the appropriate Kubernetes resources, including a deployment, ConfigMap, secrets, services, and ingress. 5. If the Kubernetes deployment resource includes an init container, it fetches dependencies from the Runtime Fabric resource cache. 6. If the resource cache doesn’t contain required dependencies, Runtime Fabric fetches them from the control plane and adds them to the resource cache. ![Application deployment workflow for Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-app-deployment.png) To retrieve deployable artifacts, application pods in the worker namespace must communicate with the resource cache in the Runtime Fabric agent namespace. ### Assigning Namespaces in Anypoint Runtime Fabric Each application is deployed into a Kubernetes namespace based on the application’s environment. 1. Runtime Fabric searches for a namespace with the label `rtf.mulesoft.com/envId=`. 2. If Runtime Fabric can’t find that label, it searches for a namespace with the name ``. 3. If Runtime Fabric can’t find that namespace, it creates a new namespace called ``. ![Application namespace assignment flowchart](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-namespace-flow.png) ### Monitoring Application Deployments The Runtime Fabric agent monitors Kubernetes Deployments labelled with `rtf.mulesoft.com/id`. When Kubernetes updates the state of the deployment, the agent sends that update to the control plane. See [Logs](https://docs.mulesoft.com/runtime-fabric/latest/limitations-self#logs) and [Monitoring](https://docs.mulesoft.com/runtime-fabric/latest/limitations-self#monitoring) for additional information. ## Feature Support List for Runtime Fabric The following table lists supported and non-supported features.
FeatureStatus

Support for deploying Mules and API Gateways

Supported

Kubernetes and Docker

Not included.

Provide your instances of Kubernetes and Docker via Amazon EKS, AKS, GKE, or OKE clusters.

Installing on any Linux distribution

Supported

Node auto-scaling

Supported using AWS, Azure, Google Cloud, or RedHat OpenShift functionality

External log forwarding

You can set up Log4j to forward logs to external systems.

Internal load balancer

You must provide an internal load balancer (Ingress Controller)

Anypoint Security Edge

Not supported

Anypoint Security Tokenization

Not supported

Ops Center

Not Included
You can enable monitoring and alerting in AWS, Azure, Google Cloud, or RedHat OpenShift

## Anypoint Runtime Fabric and Standalone Mule Runtimes (Hybrid Deployments) Hybrid deployments of Mule applications require you to install a version of the Mule runtime on a server and deploy one or more applications on the server. Each application shares the Mule runtime server and the resources allocated to it. Other resources such as certificates or database connections may also be shared using domains. Anypoint Runtime Fabric provisions resources differently. Each Mule application and API gateway runs within its own Mule runtime and in its own container. The resources available to the container are specified when deploying a Mule application or API proxy. This enables Mule applications to horizontally scale across nodes without relying on other dependencies. It also ensures that different applications do not compete with each other for resources on the same node. --- product: Runtime Fabric version: 2.10 --- # Anypoint Runtime Fabric Security Architecture > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere and ensures that you own and control the source and destination of your data. MuleSoft’s architecture model enables a Runtime Fabric to be installed anywhere and managed centrally from Anypoint Platform’s cloud-based Anypoint Management Center, which includes Anypoint Runtime Manager, Anypoint API Manager, Anypoint Monitoring and Access Management. Under this model, all of your data flows are controlled at the location of your Runtime Fabric installation with limited metadata and metrics stored in Anypoint Management Center. This metadata assists you with managing, monitoring, and troubleshooting Runtime Fabrics, integration runtimes, and APIs. This model is powered by components that run within the Runtime Fabric cluster, referred to as the Runtime Fabric agent. The Runtime Fabric agent establishes the connection to Anypoint Management Center. It also acts as the conduit between the internal components that power Runtime Fabric (such as Kubernetes) and Anypoint Management Center. ## Runtime Fabric Security Architecture The following diagram illustrates the architecture of Runtime Fabric running on a customer’s Kubernetes cluster, highlighting the communication between various Runtime Fabric core components and the interaction with the MuleSoft Anypoint control plane. All of the outbound communications are secured by mTLS. ![rtf security architecture diagram](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-security-architecture-diagram.png) ## Runtime Fabric Data Flow Review the following diagram that shows the Runtime Fabric data flow: ![Diagram of Runtime Fabric Data flow](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-security-data-flow.png) ### Activation Flow The following list the steps in the activation flow process: 1. As an authorized customer, you obtain a Runtime Fabric activation token from the Runtime Fabric Manager running on the Anypoint control plane. 2. This activation token is then presented back to Runtime Fabric Manager during creation of the Runtime Fabric. 3. Runtime Fabric Manager responds with a TLS certificate, CA chain, and read-only credentials to the Runtime Fabric container registry. 4. Runtime Fabric agent stores the certificate and CA chain in a Kubernetes Secret. 5. Runtime Fabric agent stores the read-only Docker registry credentials in a Kubernetes Secret. 6. Runtime Fabric agent uses the TLS certificate and CA chain to establish a mutual TLS (mTLS) connection to Anypoint Management Center to communicate with Anypoint Runtime Manager. 7. The container registry credentials are used to pull Mule runtime images from the Runtime Fabric container registry. ### Management Flow The following list the steps in the management flow process: 1. The mTLS tunnel protects all metadata between Anypoint Management Center and your Runtime Fabric. Runtime Fabric agent initiates and control the tunnel. 2. Application deployment messages contain metadata that describes the application and its dependencies, along with links to Anypoint Management Center Configuration Resolver to fetch the Mule app bundle and configuration from. The Configuration Resolver communication is also protected with the same mTLS credentials. 3. You can use Anypoint Runtime Manager to manage and monitor applications in the Runtime Fabric cluster: ![Runtime Manager UI with application status running](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-security-runtime-manager.png) - Management capabilities: start, stop, update Mule apps - Monitoring capabilities: monitor CPU, memory, and Mule application metrics ![Anypoint Monitoring UI with monitoring views and metrics of an application](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-security-anypoint-monitoring.png) 4. You can use the Anypoint Analytics service to get insight into how your APIs are being used and how they are performing. The service sends this metric data directly to the Analytics API over a one-way TLS connection, see [Mule API Analytics](https://docs.mulesoft.com/api-manager/latest/analytics-landing-page). These metrics consist of data specific to requests: ![Anypoint Platform UI showing requests by date for an API](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-security-anypoint-platform.png) 5. Runtime Fabric agent, Mule apps, and API gateway are separate processes. If the Runtime Fabric agent stops working or it loses connectivity with Anypoint Management Center, Mule apps and API gateways continue to operate. 6. Mule apps and API gateways work as defined in your Mule flows, and no customer data traverse to Anypoint Management Center. Your dataflow is specific to the application that was built and deployed to the runtime. ### mTLS Certificate Renewal Flow The following list the mTLS certificate renewal flow process: 1. When the mTLS certificate is close to its expiration date, the Runtime Fabric agent requests a renewed certificate from Anypoint Management Center via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new TLS certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Runtime Fabric agent restarts and re-establishes the mTLS tunnel with the new certificate. ### Anypoint Monitoring Certificate Renewal Flow The following list the Monitoring certificate renewal flow process: 1. When the Anypoint Monitoring certificate is close to its expiration date, Runtime Fabric agent requests a renewed certificate from Anypoint Management Center, via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Anypoint Monitoring containers re-establish the connection with the new certificate. ### MuleSoft Image Management The following list the image management process: - Vulnerability scanning and Sonar quality gates during build process. - All newer image pulls are triggered by customer only. - MuleSoft remediates container images and applies available patches according to the normal remediation cadence. - Critical vulnerabilities within 30 days - High vulnerabilities within 90 days - Medium vulnerabilities within 180 days - Low vulnerabilities within 360 days ### Container Privilege Management The following list the container privilege management process: 1. None of the containers need to run as root in Runtime Fabric. 2. Extremely pared down utilities inside the containers. 3. No Kubernetes service account attached to any application containers. The Runtime Fabric agent and Mule cluster IP service interact with Kubernetes control plane. To perform any action, these components need all permissions on all resources in the cluster. ## Metadata Types Stored in The Cloud The following metadata types are stored in the cloud: - Runtime Fabric Information about a Runtime Fabric cluster. Specifically: - Name - Region - Cluster version - Runtime Fabric agent version - Associated environments - Nodes, CPU, memory capacity, Kubernetes version, docker version, Kubernetes health warnings - Mule apps The flow architecture that you create using Anypoint Studio. This flow architecture is metadata about your APIs, and you upload it to Runtime Manager. Mule apps are then deployed to the specified Runtime Fabric. - Monitoring metrics (optional) Metrics about the basic runtime status that are collected on a poll configured on the runtime. Specifically: - CPU Usage - Past Hour, Current Time - Memory Usage - Past Hour, Current Time - Memory Total - Past Hour, Current Time - Message Count - Past Hour, Current Time - Response Time - Past Hour, Current Time - Error Count - Past Hour, Current Time - Analytics metrics (optional) You can enable analytics metrics to get insight into how your APIs are used and how they perform. You can configure these metrics and store the results for a maximum of 90 days. You can capture these metrics: - API name - API version - Application - Browser - City - Client IP - Continent - Country - Hardware platform - OS family - OS major Version - OS minor Version - OS version - Postal code - Resource path - Status code - Timezone - User agent type - User agent version - Verb - Violated policy name - Advanced capabilities You can use advanced capabilities in this model to send payload information to the cloud. These are not turned on by default and require advanced configuration to turn on and use. An example of this capability is [Runtime Manager Insight](https://docs.mulesoft.com/runtime-manager/insight) [https://docs.mulesoft.com/runtime-manager/insight](https://docs.mulesoft.com/runtime-manager/insight). --- product: Runtime Fabric version: 2.11 --- # Anypoint Runtime Fabric Security Architecture > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere and ensures that you own and control the source and destination of your data. MuleSoft’s architecture model enables a Runtime Fabric to be installed anywhere and managed centrally from Anypoint Platform’s cloud-based Anypoint Management Center, which includes Anypoint Runtime Manager, Anypoint API Manager, Anypoint Monitoring and Access Management. Under this model, all of your data flows are controlled at the location of your Runtime Fabric installation with limited metadata and metrics stored in Anypoint Management Center. This metadata assists you with managing, monitoring, and troubleshooting Runtime Fabrics, integration runtimes, and APIs. This model is powered by components that run within the Runtime Fabric cluster, referred to as the Runtime Fabric agent. The Runtime Fabric agent establishes the connection to Anypoint Management Center. It also acts as the conduit between the internal components that power Runtime Fabric (such as Kubernetes) and Anypoint Management Center. ## Runtime Fabric Security Architecture The following diagram illustrates the architecture of Runtime Fabric running on a customer’s Kubernetes cluster, highlighting the communication between various Runtime Fabric core components and the interaction with the MuleSoft Anypoint control plane. All of the outbound communications are secured by mTLS. ![rtf security architecture diagram](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-security-architecture-diagram.png) ## Runtime Fabric Data Flow Review this diagram that shows the Runtime Fabric data flow: ![Diagram of Runtime Fabric Data flow](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-security-data-flow.png) ### Activation Flow The following list the steps in the activation flow process: 1. As an authorized customer, you obtain a Runtime Fabric activation token from the Runtime Fabric Manager running on the Anypoint control plane. 2. This activation token is then presented back to Runtime Fabric Manager during creation of the Runtime Fabric. 3. Runtime Fabric Manager responds with a TLS certificate, CA chain, and read-only credentials to the Runtime Fabric container registry. 4. Runtime Fabric agent stores the certificate and CA chain in a Kubernetes Secret. 5. Runtime Fabric agent stores the read-only Docker registry credentials in a Kubernetes Secret. 6. Runtime Fabric agent uses the TLS certificate and CA chain to establish a mutual TLS (mTLS) connection to Anypoint Management Center to communicate with Anypoint Runtime Manager. 7. The container registry credentials are used to pull Mule runtime images from the Runtime Fabric container registry. ### Management Flow The following list the steps in the management flow process: 1. The mTLS tunnel protects all metadata between Anypoint Management Center and your Runtime Fabric. Runtime Fabric agent initiates and control the tunnel. 2. Application deployment messages contain metadata that describes the application and its dependencies, along with links to Anypoint Management Center Configuration Resolver to fetch the Mule app bundle and configuration from. The Configuration Resolver communication is also protected with the same mTLS credentials. 3. You can use Anypoint Runtime Manager to manage and monitor applications in the Runtime Fabric cluster: ![Runtime Manager UI with application status running](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-security-runtime-manager.png) - Management capabilities: start, stop, update Mule apps - Monitoring capabilities: monitor CPU, memory, and Mule application metrics ![Anypoint Monitoring UI with monitoring views and metrics of an application](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-security-anypoint-monitoring.png) 4. You can use the Anypoint Analytics service to get insight into how your APIs are being used and how they are performing. The service sends this metric data directly to the Analytics API over a one-way TLS connection, see [Mule API Analytics](https://docs.mulesoft.com/api-manager/latest/analytics-landing-page). These metrics consist of data specific to requests: ![Anypoint Platform UI showing requests by date for an API](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-security-anypoint-platform.png) 5. Runtime Fabric agent, Mule apps, and API gateway are separate processes. If the Runtime Fabric agent stops working or it loses connectivity with Anypoint Management Center, Mule apps and API gateways continue to operate. 6. Mule apps and API gateways work as defined in your Mule flows, and no customer data traverse to Anypoint Management Center. Your dataflow is specific to the application that was built and deployed to the runtime. ### mTLS Certificate Renewal Flow The following list the mTLS certificate renewal flow process: 1. When the mTLS certificate is close to its expiration date, the Runtime Fabric agent requests a renewed certificate from Anypoint Management Center via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new TLS certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Runtime Fabric agent restarts and re-establishes the mTLS tunnel with the new certificate. ### Anypoint Monitoring Certificate Renewal Flow The following list the Monitoring certificate renewal flow process: 1. When the Anypoint Monitoring certificate is close to its expiration date, Runtime Fabric agent requests a renewed certificate from Anypoint Management Center, via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Anypoint Monitoring containers re-establish the connection with the new certificate. ### MuleSoft Image Management The following list the image management process: - Vulnerability scanning and Sonar quality gates during build process. - All newer image pulls are triggered by customer only. - MuleSoft remediates container images and applies available patches according to the normal remediation cadence. - Critical vulnerabilities within 30 days - High vulnerabilities within 90 days - Medium vulnerabilities within 180 days - Low vulnerabilities within 360 days ### Container Privilege Management The following list the container privilege management process: 1. None of the containers need to run as root in Runtime Fabric. 2. Extremely pared down utilities inside the containers. 3. No Kubernetes service account attached to any application containers. The Runtime Fabric agent and Mule cluster IP service interact with Kubernetes control plane. To perform any action, these components need all permissions on all resources in the cluster. ## Metadata Types Stored in The Cloud The following metadata types are stored in the cloud: - Runtime Fabric Information about a Runtime Fabric cluster. Specifically: - Name - Region - Cluster version - Runtime Fabric agent version - Associated environments - Nodes, CPU, memory capacity, Kubernetes version, docker version, Kubernetes health warnings - Mule apps The flow architecture that you create using Anypoint Studio. This flow architecture is metadata about your APIs, and you upload it to Runtime Manager. Mule apps are then deployed to the specified Runtime Fabric. - Monitoring metrics (optional) Metrics about the basic runtime status that are collected on a poll configured on the runtime. Specifically: - CPU Usage - Past Hour, Current Time - Memory Usage - Past Hour, Current Time - Memory Total - Past Hour, Current Time - Message Count - Past Hour, Current Time - Response Time - Past Hour, Current Time - Error Count - Past Hour, Current Time - Analytics metrics (optional) You can enable analytics metrics to get insight into how your APIs are used and how they perform. You can configure these metrics and store the results for a maximum of 90 days. You can capture these metrics: - API name - API version - Application - Browser - City - Client IP - Continent - Country - Hardware platform - OS family - OS major Version - OS minor Version - OS version - Postal code - Resource path - Status code - Timezone - User agent type - User agent version - Verb - Violated policy name - Advanced capabilities You can use advanced capabilities in this model to send payload information to the cloud. These are not turned on by default and require advanced configuration to turn on and use. An example of this capability is [Runtime Manager Insight](https://docs.mulesoft.com/runtime-manager/insight) [https://docs.mulesoft.com/runtime-manager/insight](https://docs.mulesoft.com/runtime-manager/insight). --- product: Runtime Fabric version: 2.5 --- # Anypoint Runtime Fabric Security Architecture > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere and ensures that you own and control the source and destination of your data. MuleSoft’s architecture model enables a Runtime Fabric to be installed anywhere and managed centrally from Anypoint Platform’s cloud-based Anypoint Management Center, which includes Anypoint Runtime Manager, Anypoint API Manager, Anypoint Monitoring and Access Management. Under this model, all of your data flows are controlled at the location of your Runtime Fabric installation with limited metadata and metrics stored in Anypoint Management Center. This metadata assists you with managing, monitoring, and troubleshooting Runtime Fabrics, integration runtimes, and APIs. This model is powered by components that run within the Runtime Fabric cluster, referred to as the Runtime Fabric agent. The Runtime Fabric agent establishes the connection to Anypoint Management Center. It also acts as the conduit between the internal components that power Runtime Fabric (such as Kubernetes) and Anypoint Management Center. ## Runtime Fabric Data Flow Review the following diagram that shows the Runtime Fabric data flow: ![Diagram of Runtime Fabric Data flow](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-security-data-flow.png) ### Activation Flow The following list the steps in the activation flow process: 1. As an authorized customer, you obtain a Runtime Fabric activation token from the Runtime Fabric Manager running on the Anypoint control plane. 2. This activation token is then presented back to Runtime Fabric Manager during creation of the Runtime Fabric. 3. Runtime Fabric Manager responds with a TLS certificate, CA chain, and read-only credentials to the Runtime Fabric container registry. 4. Runtime Fabric agent stores the certificate and CA chain in a Kubernetes Secret. 5. Runtime Fabric agent stores the read-only Docker registry credentials in a Kubernetes Secret. 6. Runtime Fabric agent uses the TLS certificate and CA chain to establish a mutual TLS (mTLS) connection to Anypoint Management Center to communicate with Anypoint Runtime Manager. 7. The container registry credentials are used to pull Mule runtime images from the Runtime Fabric container registry. ### Management Flow The following list the steps in the management flow process: 1. The mTLS tunnel protects all metadata between Anypoint Management Center and your Runtime Fabric. Runtime Fabric agent initiates and control the tunnel. 2. Application deployment messages contain metadata that describes the application and its dependencies, along with links to Anypoint Management Center Configuration Resolver to fetch the Mule app bundle and configuration from. The Configuration Resolver communication is also protected with the same mTLS credentials. 3. You can use Anypoint Runtime Manager to manage and monitor applications in the Runtime Fabric cluster: ![Runtime Manager UI with application status running](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-security-runtime-manager.png) - Management capabilities: start, stop, update Mule apps - Monitoring capabilities: monitor CPU, memory, and Mule application metrics ![Anypoint Monitoring UI with monitoring views and metrics of an application](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-security-anypoint-monitoring.png) 4. You can use the Anypoint Analytics service to get insight into how your APIs are being used and how they are performing. The service sends this metric data directly to the Analytics API over a one-way TLS connection, see [Mule API Analytics](https://docs.mulesoft.com/api-manager/latest/analytics-landing-page). These metrics consist of data specific to requests: ![Anypoint Platform UI showing requests by date for an API](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-security-anypoint-platform.png) 5. Runtime Fabric agent, Mule apps, and API gateway are separate processes. If the Runtime Fabric agent stops working or it loses connectivity with Anypoint Management Center, Mule apps and API gateways continue to operate. 6. Mule apps and API gateways work as defined in your Mule flows, and no customer data traverse to Anypoint Management Center. Your dataflow is specific to the application that was built and deployed to the runtime. ### mTLS Certificate Renewal Flow The following list the mTLS certificate renewal flow process: 1. When the mTLS certificate is close to its expiration date, the Runtime Fabric agent requests a renewed certificate from Anypoint Management Center via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new TLS certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Runtime Fabric agent restarts and re-establishes the mTLS tunnel with the new certificate. ### Anypoint Monitoring Certificate Renewal Flow The following list the Monitoring certificate renewal flow process: 1. When the Anypoint Monitoring certificate is close to its expiration date, Runtime Fabric agent requests a renewed certificate from Anypoint Management Center, via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Anypoint Monitoring containers re-establish the connection with the new certificate. ### MuleSoft Image Management The following list the image management process: - Vulnerability scanning and Sonar quality gates during build process. - All newer image pulls are triggered by customer only. - MuleSoft remediates container images and applies available patches according to the normal remediation cadence. - Critical vulnerabilities within 30 days - High vulnerabilities within 90 days - Medium vulnerabilities within 180 days - Low vulnerabilities within 360 days ### Container Privilege Management The following list the container privilege management process: 1. None of the containers need to run as root in Runtime Fabric. 2. Extremely pared down utilities inside the containers. 3. No Kubernetes service account attached to any application containers. The Runtime Fabric agent and Mule cluster IP service interact with Kubernetes control plane. To perform any action, these components need all permissions on all resources in the cluster. ## Metadata Types Stored in The Cloud The following metadata types are stored in the cloud: - Runtime Fabric Information about a Runtime Fabric cluster. Specifically: - Name - Region - Cluster version - Runtime Fabric agent version - Associated environments - Nodes, CPU, memory capacity, Kubernetes version, docker version, Kubernetes health warnings - Mule apps The flow architecture that you create using Anypoint Studio. This flow architecture is metadata about your APIs, and you upload it to Runtime Manager. Mule apps are then deployed to the specified Runtime Fabric. - Monitoring metrics (optional) Metrics about the basic runtime status that are collected on a poll configured on the runtime. Specifically: - CPU Usage - Past Hour, Current Time - Memory Usage - Past Hour, Current Time - Memory Total - Past Hour, Current Time - Message Count - Past Hour, Current Time - Response Time - Past Hour, Current Time - Error Count - Past Hour, Current Time - Analytics metrics (optional) You can enable analytics metrics to get insight into how your APIs are used and how they perform. You can configure these metrics and store the results for a maximum of 90 days. You can capture these metrics: - API name - API version - Application - Browser - City - Client IP - Continent - Country - Hardware platform - OS family - OS major Version - OS minor Version - OS version - Postal code - Resource path - Status code - Timezone - User agent type - User agent version - Verb - Violated policy name - Advanced capabilities You can use advanced capabilities in this model to send payload information to the cloud. These are not turned on by default and require advanced configuration to turn on and use. An example of this capability is [Runtime Manager Insight](https://docs.mulesoft.com/runtime-manager/insight) [https://docs.mulesoft.com/runtime-manager/insight](https://docs.mulesoft.com/runtime-manager/insight). --- product: Runtime Fabric version: 2.6 --- # Anypoint Runtime Fabric Security Architecture > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere and ensures that you own and control the source and destination of your data. MuleSoft’s architecture model enables a Runtime Fabric to be installed anywhere and managed centrally from Anypoint Platform’s cloud-based Anypoint Management Center, which includes Anypoint Runtime Manager, Anypoint API Manager, Anypoint Monitoring and Access Management. Under this model, all of your data flows are controlled at the location of your Runtime Fabric installation with limited metadata and metrics stored in Anypoint Management Center. This metadata assists you with managing, monitoring, and troubleshooting Runtime Fabrics, integration runtimes, and APIs. This model is powered by components that run within the Runtime Fabric cluster, referred to as the Runtime Fabric agent. The Runtime Fabric agent establishes the connection to Anypoint Management Center. It also acts as the conduit between the internal components that power Runtime Fabric (such as Kubernetes) and Anypoint Management Center. ## Runtime Fabric Data Flow Review the following diagram that shows the Runtime Fabric data flow: ![Diagram of Runtime Fabric Data flow](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-security-data-flow.png) ### Activation Flow The following list the steps in the activation flow process: 1. As an authorized customer, you obtain a Runtime Fabric activation token from the Runtime Fabric Manager running on the Anypoint control plane. 2. This activation token is then presented back to Runtime Fabric Manager during creation of the Runtime Fabric. 3. Runtime Fabric Manager responds with a TLS certificate, CA chain, and read-only credentials to the Runtime Fabric container registry. 4. Runtime Fabric agent stores the certificate and CA chain in a Kubernetes Secret. 5. Runtime Fabric agent stores the read-only Docker registry credentials in a Kubernetes Secret. 6. Runtime Fabric agent uses the TLS certificate and CA chain to establish a mutual TLS (mTLS) connection to Anypoint Management Center to communicate with Anypoint Runtime Manager. 7. The container registry credentials are used to pull Mule runtime images from the Runtime Fabric container registry. ### Management Flow The following list the steps in the management flow process: 1. The mTLS tunnel protects all metadata between Anypoint Management Center and your Runtime Fabric. Runtime Fabric agent initiates and control the tunnel. 2. Application deployment messages contain metadata that describes the application and its dependencies, along with links to Anypoint Management Center Configuration Resolver to fetch the Mule app bundle and configuration from. The Configuration Resolver communication is also protected with the same mTLS credentials. 3. You can use Anypoint Runtime Manager to manage and monitor applications in the Runtime Fabric cluster: ![Runtime Manager UI with application status running](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-security-runtime-manager.png) - Management capabilities: start, stop, update Mule apps - Monitoring capabilities: monitor CPU, memory, and Mule application metrics ![Anypoint Monitoring UI with monitoring views and metrics of an application](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-security-anypoint-monitoring.png) 4. You can use the Anypoint Analytics service to get insight into how your APIs are being used and how they are performing. The service sends this metric data directly to the Analytics API over a one-way TLS connection, see [Mule API Analytics](https://docs.mulesoft.com/api-manager/latest/analytics-landing-page). These metrics consist of data specific to requests: ![Anypoint Platform UI showing requests by date for an API](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-security-anypoint-platform.png) 5. Runtime Fabric agent, Mule apps, and API gateway are separate processes. If the Runtime Fabric agent stops working or it loses connectivity with Anypoint Management Center, Mule apps and API gateways continue to operate. 6. Mule apps and API gateways work as defined in your Mule flows, and no customer data traverse to Anypoint Management Center. Your dataflow is specific to the application that was built and deployed to the runtime. ### mTLS Certificate Renewal Flow The following list the mTLS certificate renewal flow process: 1. When the mTLS certificate is close to its expiration date, the Runtime Fabric agent requests a renewed certificate from Anypoint Management Center via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new TLS certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Runtime Fabric agent restarts and re-establishes the mTLS tunnel with the new certificate. ### Anypoint Monitoring Certificate Renewal Flow The following list the Monitoring certificate renewal flow process: 1. When the Anypoint Monitoring certificate is close to its expiration date, Runtime Fabric agent requests a renewed certificate from Anypoint Management Center, via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Anypoint Monitoring containers re-establish the connection with the new certificate. ### MuleSoft Image Management The following list the image management process: - Vulnerability scanning and Sonar quality gates during build process. - All newer image pulls are triggered by customer only. - MuleSoft remediates container images and applies available patches according to the normal remediation cadence. - Critical vulnerabilities within 30 days - High vulnerabilities within 90 days - Medium vulnerabilities within 180 days - Low vulnerabilities within 360 days ### Container Privilege Management The following list the container privilege management process: 1. None of the containers need to run as root in Runtime Fabric. 2. Extremely pared down utilities inside the containers. 3. No Kubernetes service account attached to any application containers. The Runtime Fabric agent and Mule cluster IP service interact with Kubernetes control plane. To perform any action, these components need all permissions on all resources in the cluster. ## Metadata Types Stored in The Cloud The following metadata types are stored in the cloud: - Runtime Fabric Information about a Runtime Fabric cluster. Specifically: - Name - Region - Cluster version - Runtime Fabric agent version - Associated environments - Nodes, CPU, memory capacity, Kubernetes version, docker version, Kubernetes health warnings - Mule apps The flow architecture that you create using Anypoint Studio. This flow architecture is metadata about your APIs, and you upload it to Runtime Manager. Mule apps are then deployed to the specified Runtime Fabric. - Monitoring metrics (optional) Metrics about the basic runtime status that are collected on a poll configured on the runtime. Specifically: - CPU Usage - Past Hour, Current Time - Memory Usage - Past Hour, Current Time - Memory Total - Past Hour, Current Time - Message Count - Past Hour, Current Time - Response Time - Past Hour, Current Time - Error Count - Past Hour, Current Time - Analytics metrics (optional) You can enable analytics metrics to get insight into how your APIs are used and how they perform. You can configure these metrics and store the results for a maximum of 90 days. You can capture these metrics: - API name - API version - Application - Browser - City - Client IP - Continent - Country - Hardware platform - OS family - OS major Version - OS minor Version - OS version - Postal code - Resource path - Status code - Timezone - User agent type - User agent version - Verb - Violated policy name - Advanced capabilities You can use advanced capabilities in this model to send payload information to the cloud. These are not turned on by default and require advanced configuration to turn on and use. An example of this capability is [Runtime Manager Insight](https://docs.mulesoft.com/runtime-manager/insight) [https://docs.mulesoft.com/runtime-manager/insight](https://docs.mulesoft.com/runtime-manager/insight). --- product: Runtime Fabric version: 2.7 --- # Anypoint Runtime Fabric Security Architecture > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere and ensures that you own and control the source and destination of your data. MuleSoft’s architecture model enables a Runtime Fabric to be installed anywhere and managed centrally from Anypoint Platform’s cloud-based Anypoint Management Center, which includes Anypoint Runtime Manager, Anypoint API Manager, Anypoint Monitoring and Access Management. Under this model, all of your data flows are controlled at the location of your Runtime Fabric installation with limited metadata and metrics stored in Anypoint Management Center. This metadata assists you with managing, monitoring, and troubleshooting Runtime Fabrics, integration runtimes, and APIs. This model is powered by components that run within the Runtime Fabric cluster, referred to as the Runtime Fabric agent. The Runtime Fabric agent establishes the connection to Anypoint Management Center. It also acts as the conduit between the internal components that power Runtime Fabric (such as Kubernetes) and Anypoint Management Center. ## Runtime Fabric Data Flow Review the following diagram that shows the Runtime Fabric data flow: ![Diagram of Runtime Fabric Data flow](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-security-data-flow.png) ### Activation Flow The following list the steps in the activation flow process: 1. As an authorized customer, you obtain a Runtime Fabric activation token from the Runtime Fabric Manager running on the Anypoint control plane. 2. This activation token is then presented back to Runtime Fabric Manager during creation of the Runtime Fabric. 3. Runtime Fabric Manager responds with a TLS certificate, CA chain, and read-only credentials to the Runtime Fabric container registry. 4. Runtime Fabric agent stores the certificate and CA chain in a Kubernetes Secret. 5. Runtime Fabric agent stores the read-only Docker registry credentials in a Kubernetes Secret. 6. Runtime Fabric agent uses the TLS certificate and CA chain to establish a mutual TLS (mTLS) connection to Anypoint Management Center to communicate with Anypoint Runtime Manager. 7. The container registry credentials are used to pull Mule runtime images from the Runtime Fabric container registry. ### Management Flow The following list the steps in the management flow process: 1. The mTLS tunnel protects all metadata between Anypoint Management Center and your Runtime Fabric. Runtime Fabric agent initiates and control the tunnel. 2. Application deployment messages contain metadata that describes the application and its dependencies, along with links to Anypoint Management Center Configuration Resolver to fetch the Mule app bundle and configuration from. The Configuration Resolver communication is also protected with the same mTLS credentials. 3. You can use Anypoint Runtime Manager to manage and monitor applications in the Runtime Fabric cluster: ![Runtime Manager UI with application status running](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-security-runtime-manager.png) - Management capabilities: start, stop, update Mule apps - Monitoring capabilities: monitor CPU, memory, and Mule application metrics ![Anypoint Monitoring UI with monitoring views and metrics of an application](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-security-anypoint-monitoring.png) 4. You can use the Anypoint Analytics service to get insight into how your APIs are being used and how they are performing. The service sends this metric data directly to the Analytics API over a one-way TLS connection, see [Mule API Analytics](https://docs.mulesoft.com/api-manager/latest/analytics-landing-page). These metrics consist of data specific to requests: ![Anypoint Platform UI showing requests by date for an API](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-security-anypoint-platform.png) 5. Runtime Fabric agent, Mule apps, and API gateway are separate processes. If the Runtime Fabric agent stops working or it loses connectivity with Anypoint Management Center, Mule apps and API gateways continue to operate. 6. Mule apps and API gateways work as defined in your Mule flows, and no customer data traverse to Anypoint Management Center. Your dataflow is specific to the application that was built and deployed to the runtime. ### mTLS Certificate Renewal Flow The following list the mTLS certificate renewal flow process: 1. When the mTLS certificate is close to its expiration date, the Runtime Fabric agent requests a renewed certificate from Anypoint Management Center via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new TLS certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Runtime Fabric agent restarts and re-establishes the mTLS tunnel with the new certificate. ### Anypoint Monitoring Certificate Renewal Flow The following list the Monitoring certificate renewal flow process: 1. When the Anypoint Monitoring certificate is close to its expiration date, Runtime Fabric agent requests a renewed certificate from Anypoint Management Center, via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Anypoint Monitoring containers re-establish the connection with the new certificate. ### MuleSoft Image Management The following list the image management process: - Vulnerability scanning and Sonar quality gates during build process. - All newer image pulls are triggered by customer only. - MuleSoft remediates container images and applies available patches according to the normal remediation cadence. - Critical vulnerabilities within 30 days - High vulnerabilities within 90 days - Medium vulnerabilities within 180 days - Low vulnerabilities within 360 days ### Container Privilege Management The following list the container privilege management process: 1. None of the containers need to run as root in Runtime Fabric. 2. Extremely pared down utilities inside the containers. 3. No Kubernetes service account attached to any application containers. The Runtime Fabric agent and Mule cluster IP service interact with Kubernetes control plane. To perform any action, these components need all permissions on all resources in the cluster. ## Metadata Types Stored in The Cloud The following metadata types are stored in the cloud: - Runtime Fabric Information about a Runtime Fabric cluster. Specifically: - Name - Region - Cluster version - Runtime Fabric agent version - Associated environments - Nodes, CPU, memory capacity, Kubernetes version, docker version, Kubernetes health warnings - Mule apps The flow architecture that you create using Anypoint Studio. This flow architecture is metadata about your APIs, and you upload it to Runtime Manager. Mule apps are then deployed to the specified Runtime Fabric. - Monitoring metrics (optional) Metrics about the basic runtime status that are collected on a poll configured on the runtime. Specifically: - CPU Usage - Past Hour, Current Time - Memory Usage - Past Hour, Current Time - Memory Total - Past Hour, Current Time - Message Count - Past Hour, Current Time - Response Time - Past Hour, Current Time - Error Count - Past Hour, Current Time - Analytics metrics (optional) You can enable analytics metrics to get insight into how your APIs are used and how they perform. You can configure these metrics and store the results for a maximum of 90 days. You can capture these metrics: - API name - API version - Application - Browser - City - Client IP - Continent - Country - Hardware platform - OS family - OS major Version - OS minor Version - OS version - Postal code - Resource path - Status code - Timezone - User agent type - User agent version - Verb - Violated policy name - Advanced capabilities You can use advanced capabilities in this model to send payload information to the cloud. These are not turned on by default and require advanced configuration to turn on and use. An example of this capability is [Runtime Manager Insight](https://docs.mulesoft.com/runtime-manager/insight) [https://docs.mulesoft.com/runtime-manager/insight](https://docs.mulesoft.com/runtime-manager/insight). --- product: Runtime Fabric version: 2.8 --- # Anypoint Runtime Fabric Security Architecture > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere and ensures that you own and control the source and destination of your data. MuleSoft’s architecture model enables a Runtime Fabric to be installed anywhere and managed centrally from Anypoint Platform’s cloud-based Anypoint Management Center, which includes Anypoint Runtime Manager, Anypoint API Manager, Anypoint Monitoring and Access Management. Under this model, all of your data flows are controlled at the location of your Runtime Fabric installation with limited metadata and metrics stored in Anypoint Management Center. This metadata assists you with managing, monitoring, and troubleshooting Runtime Fabrics, integration runtimes, and APIs. This model is powered by components that run within the Runtime Fabric cluster, referred to as the Runtime Fabric agent. The Runtime Fabric agent establishes the connection to Anypoint Management Center. It also acts as the conduit between the internal components that power Runtime Fabric (such as Kubernetes) and Anypoint Management Center. ## Runtime Fabric Security Architecture The following diagram illustrates the architecture of Runtime Fabric running on a customer’s Kubernetes cluster, highlighting the communication between various Runtime Fabric core components and the interaction with the MuleSoft Anypoint control plane. All of the outbound communications are secured by mTLS. ![rtf security architecture diagram](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-security-architecture-diagram.png) ## Runtime Fabric Data Flow Review the following diagram that shows the Runtime Fabric data flow: ![Diagram of Runtime Fabric Data flow](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-security-data-flow.png) ### Activation Flow The following list the steps in the activation flow process: 1. As an authorized customer, you obtain a Runtime Fabric activation token from the Runtime Fabric Manager running on the Anypoint control plane. 2. This activation token is then presented back to Runtime Fabric Manager during creation of the Runtime Fabric. 3. Runtime Fabric Manager responds with a TLS certificate, CA chain, and read-only credentials to the Runtime Fabric container registry. 4. Runtime Fabric agent stores the certificate and CA chain in a Kubernetes Secret. 5. Runtime Fabric agent stores the read-only Docker registry credentials in a Kubernetes Secret. 6. Runtime Fabric agent uses the TLS certificate and CA chain to establish a mutual TLS (mTLS) connection to Anypoint Management Center to communicate with Anypoint Runtime Manager. 7. The container registry credentials are used to pull Mule runtime images from the Runtime Fabric container registry. ### Management Flow The following list the steps in the management flow process: 1. The mTLS tunnel protects all metadata between Anypoint Management Center and your Runtime Fabric. Runtime Fabric agent initiates and control the tunnel. 2. Application deployment messages contain metadata that describes the application and its dependencies, along with links to Anypoint Management Center Configuration Resolver to fetch the Mule app bundle and configuration from. The Configuration Resolver communication is also protected with the same mTLS credentials. 3. You can use Anypoint Runtime Manager to manage and monitor applications in the Runtime Fabric cluster: ![Runtime Manager UI with application status running](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-security-runtime-manager.png) - Management capabilities: start, stop, update Mule apps - Monitoring capabilities: monitor CPU, memory, and Mule application metrics ![Anypoint Monitoring UI with monitoring views and metrics of an application](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-security-anypoint-monitoring.png) 4. You can use the Anypoint Analytics service to get insight into how your APIs are being used and how they are performing. The service sends this metric data directly to the Analytics API over a one-way TLS connection, see [Mule API Analytics](https://docs.mulesoft.com/api-manager/latest/analytics-landing-page). These metrics consist of data specific to requests: ![Anypoint Platform UI showing requests by date for an API](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-security-anypoint-platform.png) 5. Runtime Fabric agent, Mule apps, and API gateway are separate processes. If the Runtime Fabric agent stops working or it loses connectivity with Anypoint Management Center, Mule apps and API gateways continue to operate. 6. Mule apps and API gateways work as defined in your Mule flows, and no customer data traverse to Anypoint Management Center. Your dataflow is specific to the application that was built and deployed to the runtime. ### mTLS Certificate Renewal Flow The following list the mTLS certificate renewal flow process: 1. When the mTLS certificate is close to its expiration date, the Runtime Fabric agent requests a renewed certificate from Anypoint Management Center via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new TLS certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Runtime Fabric agent restarts and re-establishes the mTLS tunnel with the new certificate. ### Anypoint Monitoring Certificate Renewal Flow The following list the Monitoring certificate renewal flow process: 1. When the Anypoint Monitoring certificate is close to its expiration date, Runtime Fabric agent requests a renewed certificate from Anypoint Management Center, via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Anypoint Monitoring containers re-establish the connection with the new certificate. ### MuleSoft Image Management The following list the image management process: - Vulnerability scanning and Sonar quality gates during build process. - All newer image pulls are triggered by customer only. - MuleSoft remediates container images and applies available patches according to the normal remediation cadence. - Critical vulnerabilities within 30 days - High vulnerabilities within 90 days - Medium vulnerabilities within 180 days - Low vulnerabilities within 360 days ### Container Privilege Management The following list the container privilege management process: 1. None of the containers need to run as root in Runtime Fabric. 2. Extremely pared down utilities inside the containers. 3. No Kubernetes service account attached to any application containers. The Runtime Fabric agent and Mule cluster IP service interact with Kubernetes control plane. To perform any action, these components need all permissions on all resources in the cluster. ## Metadata Types Stored in The Cloud The following metadata types are stored in the cloud: - Runtime Fabric Information about a Runtime Fabric cluster. Specifically: - Name - Region - Cluster version - Runtime Fabric agent version - Associated environments - Nodes, CPU, memory capacity, Kubernetes version, docker version, Kubernetes health warnings - Mule apps The flow architecture that you create using Anypoint Studio. This flow architecture is metadata about your APIs, and you upload it to Runtime Manager. Mule apps are then deployed to the specified Runtime Fabric. - Monitoring metrics (optional) Metrics about the basic runtime status that are collected on a poll configured on the runtime. Specifically: - CPU Usage - Past Hour, Current Time - Memory Usage - Past Hour, Current Time - Memory Total - Past Hour, Current Time - Message Count - Past Hour, Current Time - Response Time - Past Hour, Current Time - Error Count - Past Hour, Current Time - Analytics metrics (optional) You can enable analytics metrics to get insight into how your APIs are used and how they perform. You can configure these metrics and store the results for a maximum of 90 days. You can capture these metrics: - API name - API version - Application - Browser - City - Client IP - Continent - Country - Hardware platform - OS family - OS major Version - OS minor Version - OS version - Postal code - Resource path - Status code - Timezone - User agent type - User agent version - Verb - Violated policy name - Advanced capabilities You can use advanced capabilities in this model to send payload information to the cloud. These are not turned on by default and require advanced configuration to turn on and use. An example of this capability is [Runtime Manager Insight](https://docs.mulesoft.com/runtime-manager/insight) [https://docs.mulesoft.com/runtime-manager/insight](https://docs.mulesoft.com/runtime-manager/insight). --- product: Runtime Fabric version: 2.9 --- # Anypoint Runtime Fabric Security Architecture > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere and ensures that you own and control the source and destination of your data. MuleSoft’s architecture model enables a Runtime Fabric to be installed anywhere and managed centrally from Anypoint Platform’s cloud-based Anypoint Management Center, which includes Anypoint Runtime Manager, Anypoint API Manager, Anypoint Monitoring and Access Management. Under this model, all of your data flows are controlled at the location of your Runtime Fabric installation with limited metadata and metrics stored in Anypoint Management Center. This metadata assists you with managing, monitoring, and troubleshooting Runtime Fabrics, integration runtimes, and APIs. This model is powered by components that run within the Runtime Fabric cluster, referred to as the Runtime Fabric agent. The Runtime Fabric agent establishes the connection to Anypoint Management Center. It also acts as the conduit between the internal components that power Runtime Fabric (such as Kubernetes) and Anypoint Management Center. ## Runtime Fabric Security Architecture The following diagram illustrates the architecture of Runtime Fabric running on a customer’s Kubernetes cluster, highlighting the communication between various Runtime Fabric core components and the interaction with the MuleSoft Anypoint control plane. All of the outbound communications are secured by mTLS. ![rtf security architecture diagram](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-security-architecture-diagram.png) ## Runtime Fabric Data Flow Review the following diagram that shows the Runtime Fabric data flow: ![Diagram of Runtime Fabric Data flow](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-security-data-flow.png) ### Activation Flow The following list the steps in the activation flow process: 1. As an authorized customer, you obtain a Runtime Fabric activation token from the Runtime Fabric Manager running on the Anypoint control plane. 2. This activation token is then presented back to Runtime Fabric Manager during creation of the Runtime Fabric. 3. Runtime Fabric Manager responds with a TLS certificate, CA chain, and read-only credentials to the Runtime Fabric container registry. 4. Runtime Fabric agent stores the certificate and CA chain in a Kubernetes Secret. 5. Runtime Fabric agent stores the read-only Docker registry credentials in a Kubernetes Secret. 6. Runtime Fabric agent uses the TLS certificate and CA chain to establish a mutual TLS (mTLS) connection to Anypoint Management Center to communicate with Anypoint Runtime Manager. 7. The container registry credentials are used to pull Mule runtime images from the Runtime Fabric container registry. ### Management Flow The following list the steps in the management flow process: 1. The mTLS tunnel protects all metadata between Anypoint Management Center and your Runtime Fabric. Runtime Fabric agent initiates and control the tunnel. 2. Application deployment messages contain metadata that describes the application and its dependencies, along with links to Anypoint Management Center Configuration Resolver to fetch the Mule app bundle and configuration from. The Configuration Resolver communication is also protected with the same mTLS credentials. 3. You can use Anypoint Runtime Manager to manage and monitor applications in the Runtime Fabric cluster: ![Runtime Manager UI with application status running](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-security-runtime-manager.png) - Management capabilities: start, stop, update Mule apps - Monitoring capabilities: monitor CPU, memory, and Mule application metrics ![Anypoint Monitoring UI with monitoring views and metrics of an application](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-security-anypoint-monitoring.png) 4. You can use the Anypoint Analytics service to get insight into how your APIs are being used and how they are performing. The service sends this metric data directly to the Analytics API over a one-way TLS connection, see [Mule API Analytics](https://docs.mulesoft.com/api-manager/latest/analytics-landing-page). These metrics consist of data specific to requests: ![Anypoint Platform UI showing requests by date for an API](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-security-anypoint-platform.png) 5. Runtime Fabric agent, Mule apps, and API gateway are separate processes. If the Runtime Fabric agent stops working or it loses connectivity with Anypoint Management Center, Mule apps and API gateways continue to operate. 6. Mule apps and API gateways work as defined in your Mule flows, and no customer data traverse to Anypoint Management Center. Your dataflow is specific to the application that was built and deployed to the runtime. ### mTLS Certificate Renewal Flow The following list the mTLS certificate renewal flow process: 1. When the mTLS certificate is close to its expiration date, the Runtime Fabric agent requests a renewed certificate from Anypoint Management Center via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new TLS certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Runtime Fabric agent restarts and re-establishes the mTLS tunnel with the new certificate. ### Anypoint Monitoring Certificate Renewal Flow The following list the Monitoring certificate renewal flow process: 1. When the Anypoint Monitoring certificate is close to its expiration date, Runtime Fabric agent requests a renewed certificate from Anypoint Management Center, via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Anypoint Monitoring containers re-establish the connection with the new certificate. ### MuleSoft Image Management The following list the image management process: - Vulnerability scanning and Sonar quality gates during build process. - All newer image pulls are triggered by customer only. - MuleSoft remediates container images and applies available patches according to the normal remediation cadence. - Critical vulnerabilities within 30 days - High vulnerabilities within 90 days - Medium vulnerabilities within 180 days - Low vulnerabilities within 360 days ### Container Privilege Management The following list the container privilege management process: 1. None of the containers need to run as root in Runtime Fabric. 2. Extremely pared down utilities inside the containers. 3. No Kubernetes service account attached to any application containers. The Runtime Fabric agent and Mule cluster IP service interact with Kubernetes control plane. To perform any action, these components need all permissions on all resources in the cluster. ## Metadata Types Stored in The Cloud The following metadata types are stored in the cloud: - Runtime Fabric Information about a Runtime Fabric cluster. Specifically: - Name - Region - Cluster version - Runtime Fabric agent version - Associated environments - Nodes, CPU, memory capacity, Kubernetes version, docker version, Kubernetes health warnings - Mule apps The flow architecture that you create using Anypoint Studio. This flow architecture is metadata about your APIs, and you upload it to Runtime Manager. Mule apps are then deployed to the specified Runtime Fabric. - Monitoring metrics (optional) Metrics about the basic runtime status that are collected on a poll configured on the runtime. Specifically: - CPU Usage - Past Hour, Current Time - Memory Usage - Past Hour, Current Time - Memory Total - Past Hour, Current Time - Message Count - Past Hour, Current Time - Response Time - Past Hour, Current Time - Error Count - Past Hour, Current Time - Analytics metrics (optional) You can enable analytics metrics to get insight into how your APIs are used and how they perform. You can configure these metrics and store the results for a maximum of 90 days. You can capture these metrics: - API name - API version - Application - Browser - City - Client IP - Continent - Country - Hardware platform - OS family - OS major Version - OS minor Version - OS version - Postal code - Resource path - Status code - Timezone - User agent type - User agent version - Verb - Violated policy name - Advanced capabilities You can use advanced capabilities in this model to send payload information to the cloud. These are not turned on by default and require advanced configuration to turn on and use. An example of this capability is [Runtime Manager Insight](https://docs.mulesoft.com/runtime-manager/insight) [https://docs.mulesoft.com/runtime-manager/insight](https://docs.mulesoft.com/runtime-manager/insight). --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Anypoint Runtime Fabric Security Architecture > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere and ensures that you own and control the source and destination of your data. MuleSoft’s architecture model enables a Runtime Fabric to be installed anywhere and managed centrally from Anypoint Platform’s cloud-based Anypoint Management Center, which includes Anypoint Runtime Manager, Anypoint API Manager, Anypoint Monitoring and Access Management. Under this model, all of your data flows are controlled at the location of your Runtime Fabric installation with limited metadata and metrics stored in Anypoint Management Center. This metadata assists you with managing, monitoring, and troubleshooting Runtime Fabrics, integration runtimes, and APIs. This model is powered by components that run within the Runtime Fabric cluster, referred to as the Runtime Fabric agent. The Runtime Fabric agent establishes the connection to Anypoint Management Center. It also acts as the conduit between the internal components that power Runtime Fabric (such as Kubernetes) and Anypoint Management Center. ## Runtime Fabric Security Architecture The following diagram illustrates the architecture of Runtime Fabric running on a customer’s Kubernetes cluster, highlighting the communication between various Runtime Fabric core components and the interaction with the MuleSoft Anypoint control plane. All of the outbound communications are secured by mTLS. ![rtf security architecture diagram](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-security-architecture-diagram.png) ## Runtime Fabric Data Flow Review the following diagram that shows the Runtime Fabric data flow: ![Diagram of Runtime Fabric Data flow](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-security-data-flow.png) ### Activation Flow The following list the steps in the activation flow process: 1. As an authorized customer, you obtain a Runtime Fabric activation token from the Runtime Fabric Manager running on the Anypoint control plane. 2. This activation token is then presented back to Runtime Fabric Manager during creation of the Runtime Fabric. 3. Runtime Fabric Manager responds with a TLS certificate, CA chain, and read-only credentials to the Runtime Fabric container registry. 4. Runtime Fabric agent stores the certificate and CA chain in a Kubernetes Secret. 5. Runtime Fabric agent stores the read-only Docker registry credentials in a Kubernetes Secret. 6. Runtime Fabric agent uses the TLS certificate and CA chain to establish a mutual TLS (mTLS) connection to Anypoint Management Center to communicate with Anypoint Runtime Manager. 7. The container registry credentials are used to pull Mule runtime images from the Runtime Fabric container registry. ### Management Flow The following list the steps in the management flow process: 1. The mTLS tunnel protects all metadata between Anypoint Management Center and your Runtime Fabric. Runtime Fabric agent initiates and control the tunnel. 2. Application deployment messages contain metadata that describes the application and its dependencies, along with links to Anypoint Management Center Configuration Resolver to fetch the Mule app bundle and configuration from. The Configuration Resolver communication is also protected with the same mTLS credentials. 3. You can use Anypoint Runtime Manager to manage and monitor applications in the Runtime Fabric cluster: ![Runtime Manager UI with application status running](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-security-runtime-manager.png) - Management capabilities: start, stop, update Mule apps - Monitoring capabilities: monitor CPU, memory, and Mule application metrics ![Anypoint Monitoring UI with monitoring views and metrics of an application](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-security-anypoint-monitoring.png) 4. You can use the Anypoint Analytics service to get insight into how your APIs are being used and how they are performing. The service sends this metric data directly to the Analytics API over a one-way TLS connection, see [Mule API Analytics](https://docs.mulesoft.com/api-manager/latest/analytics-landing-page). These metrics consist of data specific to requests: ![Anypoint Platform UI showing requests by date for an API](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-security-anypoint-platform.png) 5. Runtime Fabric agent, Mule apps, and API gateway are separate processes. If the Runtime Fabric agent stops working or it loses connectivity with Anypoint Management Center, Mule apps and API gateways continue to operate. 6. Mule apps and API gateways work as defined in your Mule flows, and no customer data traverse to Anypoint Management Center. Your dataflow is specific to the application that was built and deployed to the runtime. ### mTLS Certificate Renewal Flow The following list the mTLS certificate renewal flow process: 1. When the mTLS certificate is close to its expiration date, the Runtime Fabric agent requests a renewed certificate from Anypoint Management Center via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new TLS certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Runtime Fabric agent restarts and re-establishes the mTLS tunnel with the new certificate. ### Anypoint Monitoring Certificate Renewal Flow The following list the Monitoring certificate renewal flow process: 1. When the Anypoint Monitoring certificate is close to its expiration date, Runtime Fabric agent requests a renewed certificate from Anypoint Management Center, via the existing mTLS tunnel. 2. Anypoint Management Center responds with a new certificate. 3. Runtime Fabric agent overwrites the existing certificate with the new certificate. 4. Anypoint Monitoring containers re-establish the connection with the new certificate. ### MuleSoft Image Management The following list the image management process: - Vulnerability scanning and Sonar quality gates during build process. - All newer image pulls are triggered by customer only. - MuleSoft remediates container images and applies available patches according to the normal remediation cadence. - Critical vulnerabilities within 30 days - High vulnerabilities within 90 days - Medium vulnerabilities within 180 days - Low vulnerabilities within 360 days ### Container Privilege Management The following list the container privilege management process: 1. None of the containers need to run as root in Runtime Fabric. 2. Extremely pared down utilities inside the containers. 3. No Kubernetes service account attached to any application containers. The Runtime Fabric agent and Mule cluster IP service interact with Kubernetes control plane. To perform any action, these components need all permissions on all resources in the cluster. ## Metadata Types Stored in The Cloud The following metadata types are stored in the cloud: - Runtime Fabric Information about a Runtime Fabric cluster. Specifically: - Name - Region - Cluster version - Runtime Fabric agent version - Associated environments - Nodes, CPU, memory capacity, Kubernetes version, docker version, Kubernetes health warnings - Mule apps The flow architecture that you create using Anypoint Studio. This flow architecture is metadata about your APIs, and you upload it to Runtime Manager. Mule apps are then deployed to the specified Runtime Fabric. - Monitoring metrics (optional) Metrics about the basic runtime status that are collected on a poll configured on the runtime. Specifically: - CPU Usage - Past Hour, Current Time - Memory Usage - Past Hour, Current Time - Memory Total - Past Hour, Current Time - Message Count - Past Hour, Current Time - Response Time - Past Hour, Current Time - Error Count - Past Hour, Current Time - Analytics metrics (optional) You can enable analytics metrics to get insight into how your APIs are used and how they perform. You can configure these metrics and store the results for a maximum of 90 days. You can capture these metrics: - API name - API version - Application - Browser - City - Client IP - Continent - Country - Hardware platform - OS family - OS major Version - OS minor Version - OS version - Postal code - Resource path - Status code - Timezone - User agent type - User agent version - Verb - Violated policy name - Advanced capabilities You can use advanced capabilities in this model to send payload information to the cloud. These are not turned on by default and require advanced configuration to turn on and use. An example of this capability is [Runtime Manager Insight](https://docs.mulesoft.com/runtime-manager/insight) [https://docs.mulesoft.com/runtime-manager/insight](https://docs.mulesoft.com/runtime-manager/insight). --- product: Runtime Fabric version: 2.10 --- # Associating Business Groups and Environments to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying applications or API gateways to Anypoint Runtime Fabric, you must associate a Runtime Fabric with one or more Anypoint Platform environments. When deploying a Mule application, you cannot select a Runtime Fabric as a deployment target until you have performed this step in the environment where you want to deploy. > [!NOTE] Runtime Fabric appliance does not support this feature. ## Associate Business Groups You can share Runtime Fabric with an organization’s business groups. This allows other business groups to deploy applications to a single Runtime Fabric. To use this feature, the business groups must fall under the scope of the organization the Runtime Fabric is registered to. To associate a Runtime Fabric across business groups: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** tab on the left sidebar. 3. Select the Runtime Fabric to manage. 4. On the **Environments** tab, click **Add business group**. 5. Select the business groups from the drop-down list: - **This business group and its children** This option allows you to select either all environments, all sandbox environment or all production environments for the selected business group and all its children. - **Selected business groups** Enter the business group name in the **Add business group** field and select it from the list. This option allows you to select specific environments for root organizations as well as it’s children. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Business Groups dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-associate-business-groups.png) ## Associate Environments To associate an environment to a Runtime Fabric: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** section on the left sidebar. 3. Select the Runtime Fabric based on the name used during installation. 4. Click the **Environments** tab. 5. Select the environments from the drop-down list: - **All Environment** Associates the Runtime Fabric with all sandbox and production environments in the business group and all its children, or in specific child business organizations. - **All Sandbox Environments** Associates the Runtime Fabric with only sandbox environments in the business group and all its children, or in specific child business organizations. - **All Production Environments** Associates the Runtime Fabric with only production environments in the business group and all its children, or in specific child business organizations. - **Select Environments Manually** Allows you to associate the Runtime Fabric with specific environments in specific child business groups. - Check the **Sandbox** or **Production** box to bulk select all sandbox or production environments in specific child business organizations. - Check the box for each specific subenvironment to individually select the desired environments in specific child business organizations. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Environments dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-associate-environments.png) ### Production Environments When selecting a production environment, a dialog is displayed that verifies Runtime Fabric has been configured to operate in a production setting. This includes proper hardware configuration, log forwarding, alerting, and possible failure modes. If your Runtime Fabric is running with an unsupported configuration or does not meet the requirements for a production environment, one of the following messages is displayed: - `This Runtime Fabric is not supported for any workloads. Learn more.` - `This Runtime Fabric is suitable for non-production workloads only. Learn more.` Refer to [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-index) for additional information. Proper configuration must be complete before operating and deploying production applications on Runtime Fabric. --- product: Runtime Fabric version: 2.11 --- # Associating Business Groups and Environments to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying applications or API gateways to Anypoint Runtime Fabric, you must associate a Runtime Fabric with one or more Anypoint Platform environments. When deploying a Mule application, you cannot select a Runtime Fabric as a deployment target until you have performed this step in the environment where you want to deploy. > [!NOTE] Runtime Fabric appliance does not support this feature. ## Associate Business Groups You can share Runtime Fabric with an organization’s business groups. This allows other business groups to deploy applications to a single Runtime Fabric. To use this feature, the business groups must fall under the scope of the organization the Runtime Fabric is registered to. To associate a Runtime Fabric across business groups: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** tab on the left sidebar. 3. Select the Runtime Fabric to manage. 4. On the **Environments** tab, click **Add business group**. 5. Select the business groups from the drop-down list: - **This business group and its children** This option allows you to select either all environments, all sandbox environment or all production environments for the selected business group and all its children. - **Selected business groups** Enter the business group name in the **Add business group** field and select it from the list. This option allows you to select specific environments for root organizations as well as it’s children. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Business Groups dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-associate-business-groups.png) ## Associate Environments To associate an environment to a Runtime Fabric: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** section on the left sidebar. 3. Select the Runtime Fabric based on the name used during installation. 4. Click the **Environments** tab. 5. Select the environments from the drop-down list: - **All Environment** Associates the Runtime Fabric with all sandbox and production environments in the business group and all its children, or in specific child business organizations. - **All Sandbox Environments** Associates the Runtime Fabric with only sandbox environments in the business group and all its children, or in specific child business organizations. - **All Production Environments** Associates the Runtime Fabric with only production environments in the business group and all its children, or in specific child business organizations. - **Select Environments Manually** Allows you to associate the Runtime Fabric with specific environments in specific child business groups. - Check the **Sandbox** or **Production** box to bulk select all sandbox or production environments in specific child business organizations. - Check the box for each specific subenvironment to individually select the desired environments in specific child business organizations. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Environments dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-associate-environments.png) ### Production Environments When selecting a production environment, a dialog is displayed that verifies Runtime Fabric has been configured to operate in a production setting. This includes proper hardware configuration, log forwarding, alerting, and possible failure modes. If your Runtime Fabric is running with an unsupported configuration or does not meet the requirements for a production environment, one of these messages is displayed: - `This Runtime Fabric is not supported for any workloads. Learn more.` - `This Runtime Fabric is suitable for non-production workloads only. Learn more.` Refer to [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-index) for additional information. Proper configuration must be complete before operating and deploying production applications on Runtime Fabric. --- product: Runtime Fabric version: 2.5 --- # Associating Business Groups and Environments to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying applications or API gateways to Anypoint Runtime Fabric, you must associate a Runtime Fabric with one or more Anypoint Platform environments. When deploying a Mule application, you cannot select a Runtime Fabric as a deployment target until you have performed this step in the environment where you want to deploy. > [!NOTE] Runtime Fabric appliance does not support this feature. ## Associate Business Groups You can share Runtime Fabric with an organization’s business groups. This allows other business groups to deploy applications to a single Runtime Fabric. To use this feature, the business groups must fall under the scope of the organization the Runtime Fabric is registered to. To associate a Runtime Fabric across business groups: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** tab on the left sidebar. 3. Select the Runtime Fabric to manage. 4. On the **Environments** tab, click **Add business group**. 5. Select the business groups from the drop-down list: - **This business group and its children** This option allows you to select either all environments, all sandbox environment or all production environments for the selected business group and all its children. - **Selected business groups** Enter the business group name in the **Add business group** field and select it from the list. This option allows you to select specific environments for root organizations as well as it’s children. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Business Groups dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-associate-business-groups.png) ## Associate Environments To associate an environment to a Runtime Fabric: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** section on the left sidebar. 3. Select the Runtime Fabric based on the name used during installation. 4. Click the **Environments** tab. 5. Select the environments from the drop-down list: - **All Environment** Associates the Runtime Fabric with all sandbox and production environments in the business group and all its children, or in specific child business organizations. - **All Sandbox Environments** Associates the Runtime Fabric with only sandbox environments in the business group and all its children, or in specific child business organizations. - **All Production Environments** Associates the Runtime Fabric with only production environments in the business group and all its children, or in specific child business organizations. - **Select Environments Manually** Allows you to associate the Runtime Fabric with specific environments in specific child business groups. - Check the **Sandbox** or **Production** box to bulk select all sandbox or production environments in specific child business organizations. - Check the box for each specific subenvironment to individually select the desired environments in specific child business organizations. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Environments dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-associate-environments.png) ### Production Environments When selecting a production environment, a dialog is displayed that verifies Runtime Fabric has been configured to operate in a production setting. This includes proper hardware configuration, log forwarding, alerting, and possible failure modes. If your Runtime Fabric is running with an unsupported configuration or does not meet the requirements for a production environment, one of the following messages is displayed: - `This Runtime Fabric is not supported for any workloads. Learn more.` - `This Runtime Fabric is suitable for non-production workloads only. Learn more.` Refer to [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/install-index) for additional information. Proper configuration must be complete before operating and deploying production applications on Runtime Fabric. --- product: Runtime Fabric version: 2.6 --- # Associating Business Groups and Environments to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying applications or API gateways to Anypoint Runtime Fabric, you must associate a Runtime Fabric with one or more Anypoint Platform environments. When deploying a Mule application, you cannot select a Runtime Fabric as a deployment target until you have performed this step in the environment where you want to deploy. > [!NOTE] Runtime Fabric appliance does not support this feature. ## Associate Business Groups You can share Runtime Fabric with an organization’s business groups. This allows other business groups to deploy applications to a single Runtime Fabric. To use this feature, the business groups must fall under the scope of the organization the Runtime Fabric is registered to. To associate a Runtime Fabric across business groups: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** tab on the left sidebar. 3. Select the Runtime Fabric to manage. 4. On the **Environments** tab, click **Add business group**. 5. Select the business groups from the drop-down list: - **This business group and its children** This option allows you to select either all environments, all sandbox environment or all production environments for the selected business group and all its children. - **Selected business groups** Enter the business group name in the **Add business group** field and select it from the list. This option allows you to select specific environments for root organizations as well as it’s children. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Business Groups dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-associate-business-groups.png) ## Associate Environments To associate an environment to a Runtime Fabric: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** section on the left sidebar. 3. Select the Runtime Fabric based on the name used during installation. 4. Click the **Environments** tab. 5. Select the environments from the drop-down list: - **All Environment** Associates the Runtime Fabric with all sandbox and production environments in the business group and all its children, or in specific child business organizations. - **All Sandbox Environments** Associates the Runtime Fabric with only sandbox environments in the business group and all its children, or in specific child business organizations. - **All Production Environments** Associates the Runtime Fabric with only production environments in the business group and all its children, or in specific child business organizations. - **Select Environments Manually** Allows you to associate the Runtime Fabric with specific environments in specific child business groups. - Check the **Sandbox** or **Production** box to bulk select all sandbox or production environments in specific child business organizations. - Check the box for each specific subenvironment to individually select the desired environments in specific child business organizations. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Environments dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-associate-environments.png) ### Production Environments When selecting a production environment, a dialog is displayed that verifies Runtime Fabric has been configured to operate in a production setting. This includes proper hardware configuration, log forwarding, alerting, and possible failure modes. If your Runtime Fabric is running with an unsupported configuration or does not meet the requirements for a production environment, one of the following messages is displayed: - `This Runtime Fabric is not supported for any workloads. Learn more.` - `This Runtime Fabric is suitable for non-production workloads only. Learn more.` Refer to [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-index) for additional information. Proper configuration must be complete before operating and deploying production applications on Runtime Fabric. --- product: Runtime Fabric version: 2.7 --- # Associating Business Groups and Environments to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying applications or API gateways to Anypoint Runtime Fabric, you must associate a Runtime Fabric with one or more Anypoint Platform environments. When deploying a Mule application, you cannot select a Runtime Fabric as a deployment target until you have performed this step in the environment where you want to deploy. > [!NOTE] Runtime Fabric appliance does not support this feature. ## Associate Business Groups You can share Runtime Fabric with an organization’s business groups. This allows other business groups to deploy applications to a single Runtime Fabric. To use this feature, the business groups must fall under the scope of the organization the Runtime Fabric is registered to. To associate a Runtime Fabric across business groups: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** tab on the left sidebar. 3. Select the Runtime Fabric to manage. 4. On the **Environments** tab, click **Add business group**. 5. Select the business groups from the drop-down list: - **This business group and its children** This option allows you to select either all environments, all sandbox environment or all production environments for the selected business group and all its children. - **Selected business groups** Enter the business group name in the **Add business group** field and select it from the list. This option allows you to select specific environments for root organizations as well as it’s children. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Business Groups dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-associate-business-groups.png) ## Associate Environments To associate an environment to a Runtime Fabric: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** section on the left sidebar. 3. Select the Runtime Fabric based on the name used during installation. 4. Click the **Environments** tab. 5. Select the environments from the drop-down list: - **All Environment** Associates the Runtime Fabric with all sandbox and production environments in the business group and all its children, or in specific child business organizations. - **All Sandbox Environments** Associates the Runtime Fabric with only sandbox environments in the business group and all its children, or in specific child business organizations. - **All Production Environments** Associates the Runtime Fabric with only production environments in the business group and all its children, or in specific child business organizations. - **Select Environments Manually** Allows you to associate the Runtime Fabric with specific environments in specific child business groups. - Check the **Sandbox** or **Production** box to bulk select all sandbox or production environments in specific child business organizations. - Check the box for each specific subenvironment to individually select the desired environments in specific child business organizations. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Environments dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-associate-environments.png) ### Production Environments When selecting a production environment, a dialog is displayed that verifies Runtime Fabric has been configured to operate in a production setting. This includes proper hardware configuration, log forwarding, alerting, and possible failure modes. If your Runtime Fabric is running with an unsupported configuration or does not meet the requirements for a production environment, one of the following messages is displayed: - `This Runtime Fabric is not supported for any workloads. Learn more.` - `This Runtime Fabric is suitable for non-production workloads only. Learn more.` Refer to [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-index) for additional information. Proper configuration must be complete before operating and deploying production applications on Runtime Fabric. --- product: Runtime Fabric version: 2.8 --- # Associating Business Groups and Environments to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying applications or API gateways to Anypoint Runtime Fabric, you must associate a Runtime Fabric with one or more Anypoint Platform environments. When deploying a Mule application, you cannot select a Runtime Fabric as a deployment target until you have performed this step in the environment where you want to deploy. > [!NOTE] Runtime Fabric appliance does not support this feature. ## Associate Business Groups You can share Runtime Fabric with an organization’s business groups. This allows other business groups to deploy applications to a single Runtime Fabric. To use this feature, the business groups must fall under the scope of the organization the Runtime Fabric is registered to. To associate a Runtime Fabric across business groups: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** tab on the left sidebar. 3. Select the Runtime Fabric to manage. 4. On the **Environments** tab, click **Add business group**. 5. Select the business groups from the drop-down list: - **This business group and its children** This option allows you to select either all environments, all sandbox environment or all production environments for the selected business group and all its children. - **Selected business groups** Enter the business group name in the **Add business group** field and select it from the list. This option allows you to select specific environments for root organizations as well as it’s children. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Business Groups dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-associate-business-groups.png) ## Associate Environments To associate an environment to a Runtime Fabric: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** section on the left sidebar. 3. Select the Runtime Fabric based on the name used during installation. 4. Click the **Environments** tab. 5. Select the environments from the drop-down list: - **All Environment** Associates the Runtime Fabric with all sandbox and production environments in the business group and all its children, or in specific child business organizations. - **All Sandbox Environments** Associates the Runtime Fabric with only sandbox environments in the business group and all its children, or in specific child business organizations. - **All Production Environments** Associates the Runtime Fabric with only production environments in the business group and all its children, or in specific child business organizations. - **Select Environments Manually** Allows you to associate the Runtime Fabric with specific environments in specific child business groups. - Check the **Sandbox** or **Production** box to bulk select all sandbox or production environments in specific child business organizations. - Check the box for each specific subenvironment to individually select the desired environments in specific child business organizations. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Environments dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-associate-environments.png) ### Production Environments When selecting a production environment, a dialog is displayed that verifies Runtime Fabric has been configured to operate in a production setting. This includes proper hardware configuration, log forwarding, alerting, and possible failure modes. If your Runtime Fabric is running with an unsupported configuration or does not meet the requirements for a production environment, one of the following messages is displayed: - `This Runtime Fabric is not supported for any workloads. Learn more.` - `This Runtime Fabric is suitable for non-production workloads only. Learn more.` Refer to [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-index) for additional information. Proper configuration must be complete before operating and deploying production applications on Runtime Fabric. --- product: Runtime Fabric version: 2.9 --- # Associating Business Groups and Environments to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying applications or API gateways to Anypoint Runtime Fabric, you must associate a Runtime Fabric with one or more Anypoint Platform environments. When deploying a Mule application, you cannot select a Runtime Fabric as a deployment target until you have performed this step in the environment where you want to deploy. > [!NOTE] Runtime Fabric appliance does not support this feature. ## Associate Business Groups You can share Runtime Fabric with an organization’s business groups. This allows other business groups to deploy applications to a single Runtime Fabric. To use this feature, the business groups must fall under the scope of the organization the Runtime Fabric is registered to. To associate a Runtime Fabric across business groups: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** tab on the left sidebar. 3. Select the Runtime Fabric to manage. 4. On the **Environments** tab, click **Add business group**. 5. Select the business groups from the drop-down list: - **This business group and its children** This option allows you to select either all environments, all sandbox environment or all production environments for the selected business group and all its children. - **Selected business groups** Enter the business group name in the **Add business group** field and select it from the list. This option allows you to select specific environments for root organizations as well as it’s children. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Business Groups dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-associate-business-groups.png) ## Associate Environments To associate an environment to a Runtime Fabric: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** section on the left sidebar. 3. Select the Runtime Fabric based on the name used during installation. 4. Click the **Environments** tab. 5. Select the environments from the drop-down list: - **All Environment** Associates the Runtime Fabric with all sandbox and production environments in the business group and all its children, or in specific child business organizations. - **All Sandbox Environments** Associates the Runtime Fabric with only sandbox environments in the business group and all its children, or in specific child business organizations. - **All Production Environments** Associates the Runtime Fabric with only production environments in the business group and all its children, or in specific child business organizations. - **Select Environments Manually** Allows you to associate the Runtime Fabric with specific environments in specific child business groups. - Check the **Sandbox** or **Production** box to bulk select all sandbox or production environments in specific child business organizations. - Check the box for each specific subenvironment to individually select the desired environments in specific child business organizations. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Environments dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-associate-environments.png) ### Production Environments When selecting a production environment, a dialog is displayed that verifies Runtime Fabric has been configured to operate in a production setting. This includes proper hardware configuration, log forwarding, alerting, and possible failure modes. If your Runtime Fabric is running with an unsupported configuration or does not meet the requirements for a production environment, one of the following messages is displayed: - `This Runtime Fabric is not supported for any workloads. Learn more.` - `This Runtime Fabric is suitable for non-production workloads only. Learn more.` Refer to [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-index) for additional information. Proper configuration must be complete before operating and deploying production applications on Runtime Fabric. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Associating Business Groups and Environments to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying applications or API gateways to Anypoint Runtime Fabric, you must associate a Runtime Fabric with one or more Anypoint Platform environments. When deploying a Mule application, you cannot select a Runtime Fabric as a deployment target until you have performed this step in the environment where you want to deploy. > [!NOTE] Runtime Fabric appliance does not support this feature. ## Associate Business Groups You can share Runtime Fabric with an organization’s business groups. This allows other business groups to deploy applications to a single Runtime Fabric. To use this feature, the business groups must fall under the scope of the organization the Runtime Fabric is registered to. To associate a Runtime Fabric across business groups: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** tab on the left sidebar. 3. Select the Runtime Fabric to manage. 4. On the **Environments** tab, click **Add business group**. 5. Select the business groups from the drop-down list: - **This business group and its children** This option allows you to select either all environments, all sandbox environment or all production environments for the selected business group and all its children. - **Selected business groups** Enter the business group name in the **Add business group** field and select it from the list. This option allows you to select specific environments for root organizations as well as it’s children. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Business Groups dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-associate-business-groups.png) ## Associate Environments To associate an environment to a Runtime Fabric: 1. From Anypoint Platform, select **Runtime Manager**. 2. Select the **Runtime Fabric** section on the left sidebar. 3. Select the Runtime Fabric based on the name used during installation. 4. Click the **Environments** tab. 5. Select the environments from the drop-down list: - **All Environment** Associates the Runtime Fabric with all sandbox and production environments in the business group and all its children, or in specific child business organizations. - **All Sandbox Environments** Associates the Runtime Fabric with only sandbox environments in the business group and all its children, or in specific child business organizations. - **All Production Environments** Associates the Runtime Fabric with only production environments in the business group and all its children, or in specific child business organizations. - **Select Environments Manually** Allows you to associate the Runtime Fabric with specific environments in specific child business groups. - Check the **Sandbox** or **Production** box to bulk select all sandbox or production environments in specific child business organizations. - Check the box for each specific subenvironment to individually select the desired environments in specific child business organizations. 6. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Runtime Manager UI showing Environments dropdown menu with options to select](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-associate-environments.png) ### Production Environments When selecting a production environment, a dialog is displayed that verifies Runtime Fabric has been configured to operate in a production setting. This includes proper hardware configuration, log forwarding, alerting, and possible failure modes. If your Runtime Fabric is running with an unsupported configuration or does not meet the requirements for a production environment, one of the following messages is displayed: - `This Runtime Fabric is not supported for any workloads. Learn more.` - `This Runtime Fabric is suitable for non-production workloads only. Learn more.` Refer to [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-index) for additional information. Proper configuration must be complete before operating and deploying production applications on Runtime Fabric. --- product: Runtime Fabric version: 2.10 --- # Backing Up and Restoring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the following procedures to back up and restore Runtime Fabric services and the required state necessary for all deployed applications and their configurations. Data about the state of Runtime Fabric is distributed across the Kubernetes cluster. To preserve applications in the event of system failure, confirm that Runtime Fabric is automatically backed up. When scheduling backups, follow best practices by configuring hourly backups. Store your backup on external storage outside the Runtime Fabric cluster. Starting with `rtfctl` version 1.0.70, if you use an rtf-agent version higher than 2.6.52, the `rtfctl` backup bundle does not contain the Mule app deployments. The deployments are synched from the Runtime Manager UI at the time of restoration. ## When to Use the Back Up and Restore Process Common scenarios for using the backup and restore process include: - Performing a major infrastructure upgrade, such as migrating nodes in a Runtime Fabric cluster to a new version of an operating system. - Migrating your Runtime Fabric cluster from on-premises to the cloud or migrating from one cloud provider to another. - Performing a failover to a standby cluster. > [!WARNING] Do not use the backup and restore process to create concurrent running instances of > Runtime Fabric. In other words, do not back up Runtime Fabric A, use that back up to create a new > Runtime Fabric B while Runtime Fabric A is still active, and attempt to run them concurrently. > This creates application deployment issues. ## What Gets Backed Up The Runtime Fabric backup process affects only the Runtime Fabric cluster. The backup process does not back up data from the control plane. For regular Kubernetes clusters, the following is backed up: - Runtime Fabric cluster details, such as controller and worker node configurations - Cluster-level secure properties - All data in the Runtime Fabric and application namespace, such as data about deployments, services and service accounts, secrets, ingress resources, role bindings, cluster role configurations, and ConfigMap settings - The current `rtfctl` version - The current Runtime Fabric agent version - Application details including: - Application configurations for pods, replicasets, application metadata, and templates - Application properties configured in Runtime Manager - Data from other Mulesoft configurations, including: - Object Store - Edge - Anypoint Monitoring and external logforwarders For OpenShift clusters, the following is backed up: - Custom Resources - Application namespaces and for each one: - Secrets - Service Account - ConfigMap - Services - CronJobs - DaemonSets - Deployments - Ingress - Role - Role Bindings - Ingress from Runtime Fabric namespace ## What Does Not Get Backed Up - Data about application state - Data from Ops Center - Data from the control plane ### Changes Made After Performing a Backup Are Not Restored Any changes you make after you perform a backup will not be present if you restore the cluster from that backup. For example, if you perform a backup, delete an application, and then restore from that backup, the application you deleted will be recreated in the cluster, but it will be marked as deleted in Runtime Manager. As a result the application’s status will show as **applying** in Runtime Manager. Runtime Fabric does not restore the following control plane changes if you make them after you take a backup: - Created apps - Delete apps - Updated app configurations - Agent upgrades You need to manually resolve such inconsistencies by reapplying the changes you made after performing the backup, as these changes can’t be reapplied from the control plane. ## Create a Backup Before creating a backup: - Verify that Runtime Fabric is installed and running successfully. - Verify that `rtfctl` command-line tool is upgraded to version 0.3.102 or later. Verify the version by running `rtfctl version` on any Runtime Fabric node. - Confirm that the `rtfctl` binary is present in the current directory and `kubectl` is present in the user `$PATH`. Additionally, confirm that you’ve set the Kubernetes (`kubectl`) context to the intended backup cluster. > [!WARNING] Creating a backup per node, such as via a VM snapshot, is not supported. To create a backup, run the following command: ```copy ./rtfctl backup ``` This command creates a backup of the current system state in ``, which can be any path in the file system that you have write access to, such as: `/opt/anypoint/runtimefabric/backup.tar.gz`. ## Perform a Restore > [!IMPORTANT] Before you restore a cluster, review the following information: > > - You must perform the restore on the same Runtime Fabric cluster that is listed in Runtime > Manager (the same cluster in the control plane). > > - Configuration changes you make to deployed applications and management services after a back up > are not restored. > > - Application monitoring metrics are not restored. > > - When restoring on an existing Runtime Fabric cluster, use the same version of the `rftctl` > command-line utility that you used to create the backup. Runtime Fabric provides two target options when restoring a cluster from a backup: - Use an existing Runtime Fabric cluster. - Create a new Kubernetes cluster with the same configuration as the backed-up cluster. This includes the same number of servers, disks, etc. To restore a cluster on Runtime Fabric, create a cluster **without** running the `rtfctl` install command. After you create the cluster, complete the restore process. 1. Choose a target option for restoring a cluster. 2. Ensure you have installed `rftctl` in the cluster. 3. Copy the backup file you previously created, and make sure it is available to `rtfctl`. 4. Confirm your Kubernetes (kubectl) context is set to the backed-up cluster, and scale down all Runtime Fabric components on the original backed-up cluster: ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. Restore the cluster from the backup: ./rtfctl restore This process may require several minutes to complete. For Runtime Fabric, confirm the `rtfctl` binary is present in the current directory and the Kubernetes (kubectl) context is set to the cluster you are restoring to. ## Create a Backup and Restore for OpenShift Clusters In the following example, you have a Runtime Fabric with a set of Mule applications and configurations deployed on cluster (named `cluster-1`) inside an OpenShift cluster. To create a backup and perform a restore, follow these steps: 1. Run the backup command: ```copy ./rtfctl backup -n ``` > [!NOTE] MuleSoft performs the back up based on the detected cluster you have. Though, you can > also manually specify the type of back up to perform using the flag `--backup-type` string. > The flag options are `auto`, `openshift`, and `full`. With the default `auto` flag option, > MuleSoft automatically detects the infrastructure cluster provider to perform the back up. 2. Shutdown `cluster-1`. 3. Delete all Mule application deployments by running the following command: ```copy kubectl delete ns ``` Do not remove applications from the Runtime Manager UI. 4. Remove the Runtime Fabric installation. 5. Remove the Runtime Fabric operator from the OpenShift cluster (optional). 6. Send a `curl` command to the management plane API endpoint to regenerate the activation ID. The Runtime Fabric shows as ready for activation. You can install and activate Runtime Fabric again on a new OpenShift cluster. ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. Install the Runtime Fabric operator on `cluster-2` using the regenerated activation data ID. The installation must be on the same Runtime Fabric namespace. All labels on the backup point to that installation. 8. Run the restore command to pick the set of resources and restore them in the cluster: ```copy ./rtfctl restore -n ``` 9. Check the status of your Runtime Fabric deployments. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.11 --- # Backing Up and Restoring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these procedures to back up and restore Runtime Fabric services and the required state necessary for all deployed applications and their configurations. Data about the state of Runtime Fabric is distributed across the Kubernetes cluster. To preserve applications in the event of system failure, confirm that Runtime Fabric is automatically backed up. When scheduling backups, follow best practices by configuring hourly backups. Store your backup on external storage outside the Runtime Fabric cluster. Starting with `rtfctl` version 1.0.70, if you use an rtf-agent version higher than 2.6.52, the `rtfctl` backup bundle does not contain the Mule app deployments. The deployments are synched from the Runtime Manager UI at the time of restoration. ## When to Use the Back Up and Restore Process Common scenarios for using the backup and restore process include: - Performing a major infrastructure upgrade, such as migrating nodes in a Runtime Fabric cluster to a new version of an operating system. - Migrating your Runtime Fabric cluster from on-premises to the cloud or migrating from one cloud provider to another. - Performing a failover to a standby cluster. > [!WARNING] Do not use the backup and restore process to create concurrent running instances of > Runtime Fabric. In other words, do not back up Runtime Fabric A, use that back up to create a new > Runtime Fabric B while Runtime Fabric A is still active, and attempt to run them concurrently. > This creates application deployment issues. ## What Gets Backed Up The Runtime Fabric backup process affects only the Runtime Fabric cluster. The backup process does not back up data from the control plane. For regular Kubernetes clusters, this is backed up: - Runtime Fabric cluster details, such as controller and worker node configurations - Cluster-level secure properties - All data in the Runtime Fabric and application namespace, such as data about deployments, services and service accounts, secrets, ingress resources, role bindings, cluster role configurations, and ConfigMap settings - The current `rtfctl` version - The current Runtime Fabric agent version - Application details including: - Application configurations for pods, replicasets, application metadata, and templates - Application properties configured in Runtime Manager - Data from other Mulesoft configurations, including: - Object Store - Edge - Anypoint Monitoring and external logforwarders For OpenShift clusters, this is backed up: - Custom Resources - Application namespaces and for each one: - Secrets - Service Account - ConfigMap - Services - CronJobs - DaemonSets - Deployments - Ingress - Role - Role Bindings - Ingress from Runtime Fabric namespace ## What Does Not Get Backed Up - Data about application state - Data from Ops Center - Data from the control plane ### Changes Made After Performing a Backup Are Not Restored Any changes you make after you perform a backup will not be present if you restore the cluster from that backup. For example, if you perform a backup, delete an application, and then restore from that backup, the application you deleted will be recreated in the cluster, but it will be marked as deleted in Runtime Manager. As a result the application’s status will show as **applying** in Runtime Manager. Runtime Fabric does not restore these control plane changes if you make them after you take a backup: - Created apps - Delete apps - Updated app configurations - Agent upgrades You need to manually resolve such inconsistencies by reapplying the changes you made after performing the backup, as these changes can’t be reapplied from the control plane. ## Create a Backup Before creating a backup: - Verify that Runtime Fabric is installed and running successfully. - Verify that `rtfctl` command-line tool is upgraded to version 0.3.102 or later. Verify the version by running `rtfctl version` on any Runtime Fabric node. - Confirm that the `rtfctl` binary is present in the current directory and `kubectl` is present in the user `$PATH`. Additionally, confirm that you’ve set the Kubernetes (`kubectl`) context to the intended backup cluster. > [!WARNING] Creating a backup per node, such as via a VM snapshot, is not supported. To create a backup, run this command: ```copy ./rtfctl backup ``` This command creates a backup of the current system state in ``, which can be any path in the file system that you have write access to, such as: `/opt/anypoint/runtimefabric/backup.tar.gz`. ## Perform a Restore > [!IMPORTANT] Before you restore a cluster, review this information: > > - You must perform the restore on the same Runtime Fabric cluster that is listed in Runtime > Manager (the same cluster in the control plane). > > - Configuration changes you make to deployed applications and management services after a back up > are not restored. > > - Application monitoring metrics are not restored. > > - When restoring on an existing Runtime Fabric cluster, use the same version of the `rftctl` > command-line utility that you used to create the backup. Runtime Fabric provides two target options when restoring a cluster from a backup: - Use an existing Runtime Fabric cluster. - Create a new Kubernetes cluster with the same configuration as the backed-up cluster. This includes the same number of servers, disks, etc. To restore a cluster on Runtime Fabric, create a cluster **without** running the `rtfctl` install command. After you create the cluster, complete the restore process. 1. Choose a target option for restoring a cluster. 2. Ensure you have installed `rftctl` in the cluster. 3. Copy the backup file you previously created, and make sure it is available to `rtfctl`. 4. Confirm your Kubernetes (kubectl) context is set to the backed-up cluster, and scale down all Runtime Fabric components on the original backed-up cluster: ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. Restore the cluster from the backup: ./rtfctl restore This process may require several minutes to complete. For Runtime Fabric, confirm the `rtfctl` binary is present in the current directory and the Kubernetes (kubectl) context is set to the cluster you are restoring to. ## Create a Backup and Restore for OpenShift Clusters In this example, you have a Runtime Fabric with a set of Mule applications and configurations deployed on cluster (named `cluster-1`) inside an OpenShift cluster. To create a backup and perform a restore, follow these steps: 1. Run the backup command: ```copy ./rtfctl backup -n ``` > [!NOTE] MuleSoft performs the back up based on the detected cluster you have. Though, you can > also manually specify the type of back up to perform using the flag `--backup-type` string. > The flag options are `auto`, `openshift`, and `full`. With the default `auto` flag option, > MuleSoft automatically detects the infrastructure cluster provider to perform the back up. 2. Shutdown `cluster-1`. 3. Delete all Mule application deployments by running this command: ```copy kubectl delete ns ``` Do not remove applications from the Runtime Manager UI. 4. Remove the Runtime Fabric installation. 5. Remove the Runtime Fabric operator from the OpenShift cluster (optional). 6. Send a `curl` command to the management plane API endpoint to regenerate the activation ID. The Runtime Fabric shows as ready for activation. You can install and activate Runtime Fabric again on a new OpenShift cluster. ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. Install the Runtime Fabric operator on `cluster-2` using the regenerated activation data ID. The installation must be on the same Runtime Fabric namespace. All labels on the backup point to that installation. 8. Run the restore command to pick the set of resources and restore them in the cluster: ```copy ./rtfctl restore -n ``` 9. Check the status of your Runtime Fabric deployments. \[\[backup-restore-rtfctl\] ## Commands for Backing Up and Restoring a Runtime Fabric with RTFCTL Use these commands to back up and restore a Runtime Fabric.
CommandDescription

Performs a back up of the local Runtime Fabric state

Restores local Runtime Fabric state from a backup

### `backup` Performs a back up of the local Runtime Fabric state. rtfctl backup .tar.gz --namespace ### `restore` Restores the local Runtime Fabric state from a backup rtfctl restore .tar.gz --namespace Restore only the core Runtime Fabric software components without triggering application synchronization from the control plane. rtfctl restore .tar.gz --namespace --core-software-only ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.5 --- # Backing Up and Restoring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the following procedures to back up and restore Runtime Fabric services and the required state necessary for all deployed applications and their configurations. Data about the state of Runtime Fabric is distributed across the Kubernetes cluster. To preserve applications in the event of system failure, confirm that Runtime Fabric is automatically backed up. When scheduling backups, follow best practices by configuring hourly backups. Store your backup on external storage outside the Runtime Fabric cluster. ## When to Use the Back Up and Restore Process Common scenarios for using the backup and restore process include: - Performing a major infrastructure upgrade, such as migrating nodes in a Runtime Fabric cluster to a new version of an operating system. - Migrating your Runtime Fabric cluster from on-premises to the cloud or migrating from one cloud provider to another. - Performing a failover to a standby cluster. > [!WARNING] Do not use the backup and restore process to create concurrent running instances of > Runtime Fabric. In other words, do not back up Runtime Fabric A, use that back up to create a new > Runtime Fabric B while Runtime Fabric A is still active, and attempt to run them concurrently. > This creates application deployment issues. ## What Gets Backed Up The Runtime Fabric backup process affects only the Runtime Fabric cluster. The backup process does not back up data from the control plane. For regular Kubernetes clusters, the following is backed up: - Runtime Fabric cluster details, such as controller and worker node configurations - Cluster-level secure properties - All data in the Runtime Fabric and application namespace, such as data about deployments, services and service accounts, secrets, ingress resources, role bindings, cluster role configurations, and ConfigMap settings - The current `rtfctl` version - The current Runtime Fabric agent version - Application details including: - Application configurations for pods, replicasets, application metadata, and templates - Application properties configured in Runtime Manager - Data from other Mulesoft configurations, including: - Object Store - Edge - Anypoint Monitoring and external logforwarders For OpenShift clusters, the following is backed up: - Custom Resources - Application namespaces and for each one: - Secrets - Service Account - ConfigMap - Services - CronJobs - DaemonSets - Deployments - Ingress - Role - Role Bindings - Ingress from Runtime Fabric namespace ## What Does Not Get Backed Up - Data about application state - Data from Ops Center - Data from the control plane ### Changes Made After Performing a Backup Are Not Restored Any changes you make after you perform a backup will not be present if you restore the cluster from that backup. For example, if you perform a backup, delete an application, and then restore from that backup, the application you deleted will be recreated in the cluster, but it will be marked as deleted in Runtime Manager. As a result the application’s status will show as **applying** in Runtime Manager. Runtime Fabric does not restore the following control plane changes if you make them after you take a backup: - Created apps - Delete apps - Updated app configurations - Agent upgrades You need to manually resolve such inconsistencies by reapplying the changes you made after performing the backup, as these changes can’t be reapplied from the control plane. ## Create a Backup Before creating a backup: - Verify that Runtime Fabric is installed and running successfully. - Verify that `rtfctl` command-line tool is upgraded to version 0.3.102 or later. Verify the version by running `rtfctl version` on any Runtime Fabric node. - Confirm that the `rtfctl` binary is present in the current directory and `kubectl` is present in the user `$PATH`. Additionally, confirm that you’ve set the Kubernetes (`kubectl`) context to the intended backup cluster. > [!WARNING] Creating a backup per node, such as via a VM snapshot, is not supported. To create a backup, run the following command: ```copy ./rtfctl backup ``` This command creates a backup of the current system state in ``, which can be any path in the file system that you have write access to, such as: `/opt/anypoint/runtimefabric/backup.tar.gz`. ## Perform a Restore > [!IMPORTANT] Before you restore a cluster, review the following information: > > - You must perform the restore on the same Runtime Fabric cluster that is listed in Runtime > Manager (the same cluster in the control plane). > > - Configuration changes you make to deployed applications and management services after a back up > are not restored. > > - Application monitoring metrics are not restored. > > - When restoring on an existing Runtime Fabric cluster, use the same version of the `rftctl` > command-line utility that you used to create the backup. Runtime Fabric provides two target options when restoring a cluster from a backup: - Use an existing Runtime Fabric cluster. - Create a new Kubernetes cluster with the same configuration as the backed-up cluster. This includes the same number of servers, disks, etc. To restore a cluster on Runtime Fabric, create a cluster **without** running the `rtfctl` install command. After you create the cluster, complete the restore process. 1. Choose a target option for restoring a cluster. 2. Ensure you have installed `rftctl` in the cluster. 3. Copy the backup file you previously created, and make sure it is available to `rtfctl`. 4. Confirm your Kubernetes (kubectl) context is set to the backed-up cluster, and scale down all Runtime Fabric components on the original backed-up cluster: ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. Restore the cluster from the backup: ./rtfctl restore This process may require several minutes to complete. For Runtime Fabric, confirm the `rtfctl` binary is present in the current directory and the Kubernetes (kubectl) context is set to the cluster you are restoring to. ## Create a Backup and Restore for OpenShift Clusters In the following example, you have a Runtime Fabric with a set of Mule applications and configurations deployed on cluster (named `cluster-1`) inside an OpenShift cluster. To create a backup and perform a restore, follow these steps: 1. Run the backup command: ```copy ./rtfctl backup -n ``` > [!NOTE] MuleSoft performs the back up based on the detected cluster you have. Though, you can > also manually specify the type of back up to perform using the flag `--backup-type` string. > The flag options are `auto`, `openshift`, and `full`. With the default `auto` flag option, > MuleSoft automatically detects the infrastructure cluster provider to perform the back up. 2. Shutdown `cluster-1`. 3. Delete all Mule application deployments by running the following command: ```copy kubectl delete ns ``` Do not remove applications from the Runtime Manager UI. 4. Remove the Runtime Fabric installation. 5. Remove the Runtime Fabric operator from the OpenShift cluster (optional). 6. Send a `curl` command to the management plane API endpoint to regenerate the activation ID. The Runtime Fabric shows as ready for activation. You can install and activate Runtime Fabric again on a new OpenShift cluster. ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. Install the Runtime Fabric operator on `cluster-2` using the regenerated activation data ID. The installation must be on the same Runtime Fabric namespace. All labels on the backup point to that installation. 8. Run the restore command to pick the set of resources and restore them in the cluster: ```copy ./rtfctl restore -n ``` 9. Check the status of your Runtime Fabric deployments. --- product: Runtime Fabric version: 2.6 --- # Backing Up and Restoring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the following procedures to back up and restore Runtime Fabric services and the required state necessary for all deployed applications and their configurations. Data about the state of Runtime Fabric is distributed across the Kubernetes cluster. To preserve applications in the event of system failure, confirm that Runtime Fabric is automatically backed up. When scheduling backups, follow best practices by configuring hourly backups. Store your backup on external storage outside the Runtime Fabric cluster. Starting with `rtfctl` version 1.0.70, if you use an rtf-agent version higher than 2.6.52, the `rtfctl` backup bundle does not contain the Mule app deployments. The deployments are synced from the Runtime Manager UI at the time of restoration. ## When to Use the Back Up and Restore Process Common scenarios for using the backup and restore process include: - Performing a major infrastructure upgrade, such as migrating nodes in a Runtime Fabric cluster to a new version of an operating system. - Migrating your Runtime Fabric cluster from on-premises to the cloud or migrating from one cloud provider to another. - Performing a failover to a standby cluster. > [!WARNING] Do not use the backup and restore process to create concurrent running instances of > Runtime Fabric. In other words, do not back up Runtime Fabric A, use that back up to create a new > Runtime Fabric B while Runtime Fabric A is still active, and attempt to run them concurrently. > This creates application deployment issues. ## What Gets Backed Up The Runtime Fabric backup process affects only the Runtime Fabric cluster. The backup process does not back up data from the control plane. For regular Kubernetes clusters, the following is backed up: - Runtime Fabric cluster details, such as controller and worker node configurations - Cluster-level secure properties - All data in the Runtime Fabric and application namespace, such as data about deployments, services and service accounts, secrets, ingress resources, role bindings, cluster role configurations, and ConfigMap settings - The current `rtfctl` version - The current Runtime Fabric agent version - Application details including: - Application configurations for pods, replicasets, application metadata, and templates - Application properties configured in Runtime Manager - Data from other Mulesoft configurations, including: - Object Store - Edge - Anypoint Monitoring and external logforwarders For OpenShift clusters, the following is backed up: - Custom Resources - Application namespaces and for each one: - Secrets - Service Account - ConfigMap - Services - CronJobs - DaemonSets - Deployments - Ingress - Role - Role Bindings - Ingress from Runtime Fabric namespace ## What Does Not Get Backed Up - Data about application state - Data from Ops Center - Data from the control plane ### Changes Made After Performing a Backup Are Not Restored All changes performed on the control plane side don’t need a new backup to be taken into account because those are taken from the platform at the time of restoration. Any changes done on the cluster side aren’t part of the restoration and must be reapplied. These changes include: - RTFCTL managed secure properties - Ingress resources on Runtime Fabric namespace - ConfigMap settings ## Create a Backup Before creating a backup: - Verify that Runtime Fabric is installed and running successfully. - Verify that `rtfctl` command-line tool is upgraded to version 0.3.102 or later. Verify the version by running `rtfctl version` on any Runtime Fabric node. - Confirm that the `rtfctl` binary is present in the current directory and `kubectl` is present in the user `$PATH`. Additionally, confirm that you’ve set the Kubernetes (`kubectl`) context to the intended backup cluster. > [!WARNING] Creating a backup per node, such as via a VM snapshot, is not supported. To create a backup, run the following command: ```copy ./rtfctl backup ``` This command creates a backup of the current system state in ``, which can be any path in the file system that you have write access to, such as: `/opt/anypoint/runtimefabric/backup.tar.gz`. ## Perform a Restore > [!IMPORTANT] Before you restore a cluster, review the following information: > > - You must perform the restore on the same Runtime Fabric cluster that is listed in Runtime > Manager (the same cluster in the control plane). > > - Configuration changes you make to deployed applications and management services after a back up > are not restored. > > - Application monitoring metrics are not restored. > > - When restoring on an existing Runtime Fabric cluster, use the same version of the `rftctl` > command-line utility that you used to create the backup. Runtime Fabric provides two target options when restoring a cluster from a backup: - Use an existing Runtime Fabric cluster. - Create a new Kubernetes cluster with the same configuration as the backed-up cluster. This includes the same number of servers, disks, etc. To restore a cluster on Runtime Fabric, create a cluster **without** running the `rtfctl` install command. After you create the cluster, complete the restore process. 1. Choose a target option for restoring a cluster. 2. Ensure you have installed `rftctl` in the cluster. 3. Copy the backup file you previously created, and make sure it is available to `rtfctl`. 4. Confirm your Kubernetes (kubectl) context is set to the backed-up cluster, and scale down all Runtime Fabric components on the original backed-up cluster: ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. Restore the cluster from the backup: ./rtfctl restore This process may require several minutes to complete. For Runtime Fabric, confirm the `rtfctl` binary is present in the current directory and the Kubernetes (kubectl) context is set to the cluster you are restoring to. ## Create a Backup and Restore for OpenShift Clusters In the following example, you have a Runtime Fabric with a set of Mule applications and configurations deployed on cluster (named `cluster-1`) inside an OpenShift cluster. To create a backup and perform a restore, follow these steps: 1. Run the backup command: ```copy ./rtfctl backup -n ``` > [!NOTE] MuleSoft performs the back up based on the detected cluster you have. Though, you can > also manually specify the type of back up to perform using the flag `--backup-type` string. > The flag options are `auto`, `openshift`, and `full`. With the default `auto` flag option, > MuleSoft automatically detects the infrastructure cluster provider to perform the back up. 2. Shutdown `cluster-1`. 3. Delete all Mule application deployments by running the following command: ```copy kubectl delete ns ``` Do not remove applications from the Runtime Manager UI. 4. Remove the Runtime Fabric installation. 5. Remove the Runtime Fabric operator from the OpenShift cluster (optional). 6. Send a `curl` command to the management plane API endpoint to regenerate the activation ID. The Runtime Fabric shows as ready for activation. You can install and activate Runtime Fabric again on a new OpenShift cluster. ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. Install the Runtime Fabric operator on `cluster-2` using the regenerated activation data ID. The installation must be on the same Runtime Fabric namespace. All labels on the backup point to that installation. 8. Run the restore command to pick the set of resources and restore them in the cluster: ```copy ./rtfctl restore -n ``` 9. Check the status of your Runtime Fabric deployments. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.7 --- # Backing Up and Restoring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the following procedures to back up and restore Runtime Fabric services and the required state necessary for all deployed applications and their configurations. Data about the state of Runtime Fabric is distributed across the Kubernetes cluster. To preserve applications in the event of system failure, confirm that Runtime Fabric is automatically backed up. When scheduling backups, follow best practices by configuring hourly backups. Store your backup on external storage outside the Runtime Fabric cluster. Starting with `rtfctl` version 1.0.70, if you use an rtf-agent version higher than 2.6.52, the `rtfctl` backup bundle does not contain the Mule app deployments. The deployments are synced from the Runtime Manager UI at the time of restoration. ## When to Use the Back Up and Restore Process Common scenarios for using the backup and restore process include: - Performing a major infrastructure upgrade, such as migrating nodes in a Runtime Fabric cluster to a new version of an operating system. - Migrating your Runtime Fabric cluster from on-premises to the cloud or migrating from one cloud provider to another. - Performing a failover to a standby cluster. > [!WARNING] Do not use the backup and restore process to create concurrent running instances of > Runtime Fabric. In other words, do not back up Runtime Fabric A, use that back up to create a new > Runtime Fabric B while Runtime Fabric A is still active, and attempt to run them concurrently. > This creates application deployment issues. ## What Gets Backed Up The Runtime Fabric backup process affects only the Runtime Fabric cluster. The backup process does not back up data from the control plane. For regular Kubernetes clusters, the following is backed up: - Runtime Fabric cluster details, such as controller and worker node configurations - Cluster-level secure properties - All data in the Runtime Fabric and application namespace, such as data about deployments, services and service accounts, secrets, ingress resources, role bindings, cluster role configurations, and ConfigMap settings - The current `rtfctl` version - The current Runtime Fabric agent version - Application details including: - Application configurations for pods, replicasets, application metadata, and templates - Application properties configured in Runtime Manager - Data from other Mulesoft configurations, including: - Object Store - Edge - Anypoint Monitoring and external logforwarders For OpenShift clusters, the following is backed up: - Custom Resources - Application namespaces and for each one: - Secrets - Service Account - ConfigMap - Services - CronJobs - DaemonSets - Deployments - Ingress - Role - Role Bindings - Ingress from Runtime Fabric namespace ## What Does Not Get Backed Up - Data about application state - Data from Ops Center - Data from the control plane ### Changes Made After Performing a Backup Are Not Restored All changes performed on the control plane side don’t need a new backup to be taken into account because those are taken from the platform at the time of restoration. Any changes done on the cluster side aren’t part of the restoration and must be reapplied. These changes include: - Agent upgrades - RTFCTL managed secure properties - Ingress resources on Runtime Fabric namespace - ConfigMap settings ## Create a Backup Before creating a backup: - Verify that Runtime Fabric is installed and running successfully. - Verify that `rtfctl` command-line tool is upgraded to version 0.3.102 or later. Verify the version by running `rtfctl version` on any Runtime Fabric node. - Confirm that the `rtfctl` binary is present in the current directory and `kubectl` is present in the user `$PATH`. Additionally, confirm that you’ve set the Kubernetes (`kubectl`) context to the intended backup cluster. > [!WARNING] Creating a backup per node, such as via a VM snapshot, is not supported. To create a backup, run the following command: ```copy ./rtfctl backup ``` This command creates a backup of the current system state in ``, which can be any path in the file system that you have write access to, such as: `/opt/anypoint/runtimefabric/backup.tar.gz`. ## Perform a Restore > [!IMPORTANT] Before you restore a cluster, review the following information: > > - You must perform the restore on the same Runtime Fabric cluster that is listed in Runtime > Manager (the same cluster in the control plane). > > - Configuration changes you make to deployed applications and management services after a back up > are not restored. > > - Application monitoring metrics are not restored. > > - When restoring on an existing Runtime Fabric cluster, use the same version of the `rftctl` > command-line utility that you used to create the backup. Runtime Fabric provides two target options when restoring a cluster from a backup: - Use an existing Runtime Fabric cluster. - Create a new Kubernetes cluster with the same configuration as the backed-up cluster. This includes the same number of servers, disks, etc. To restore a cluster on Runtime Fabric, create a cluster **without** running the `rtfctl` install command. After you create the cluster, complete the restore process. 1. Choose a target option for restoring a cluster. 2. Ensure you have installed `rftctl` in the cluster. 3. Copy the backup file you previously created, and make sure it is available to `rtfctl`. 4. Confirm your Kubernetes (kubectl) context is set to the backed-up cluster, and scale down all Runtime Fabric components on the original backed-up cluster: ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. Restore the cluster from the backup: ./rtfctl restore This process may require several minutes to complete. For Runtime Fabric, confirm the `rtfctl` binary is present in the current directory and the Kubernetes (kubectl) context is set to the cluster you are restoring to. ## Create a Backup and Restore for OpenShift Clusters In the following example, you have a Runtime Fabric with a set of Mule applications and configurations deployed on cluster (named `cluster-1`) inside an OpenShift cluster. To create a backup and perform a restore, follow these steps: 1. Run the backup command: ```copy ./rtfctl backup -n ``` > [!NOTE] MuleSoft performs the back up based on the detected cluster you have. Though, you can > also manually specify the type of back up to perform using the flag `--backup-type` string. > The flag options are `auto`, `openshift`, and `full`. With the default `auto` flag option, > MuleSoft automatically detects the infrastructure cluster provider to perform the back up. 2. Shutdown `cluster-1`. 3. Delete all Mule application deployments by running the following command: ```copy kubectl delete ns ``` Do not remove applications from the Runtime Manager UI. 4. Remove the Runtime Fabric installation. 5. Remove the Runtime Fabric operator from the OpenShift cluster (optional). 6. Send a `curl` command to the management plane API endpoint to regenerate the activation ID. The Runtime Fabric shows as ready for activation. You can install and activate Runtime Fabric again on a new OpenShift cluster. ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. Install the Runtime Fabric operator on `cluster-2` using the regenerated activation data ID. The installation must be on the same Runtime Fabric namespace. All labels on the backup point to that installation. 8. Run the restore command to pick the set of resources and restore them in the cluster: ```copy ./rtfctl restore -n ``` 9. Check the status of your Runtime Fabric deployments. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.8 --- # Backing Up and Restoring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the following procedures to back up and restore Runtime Fabric services and the required state necessary for all deployed applications and their configurations. Data about the state of Runtime Fabric is distributed across the Kubernetes cluster. To preserve applications in the event of system failure, confirm that Runtime Fabric is automatically backed up. When scheduling backups, follow best practices by configuring hourly backups. Store your backup on external storage outside the Runtime Fabric cluster. Starting with `rtfctl` version 1.0.70, if you use an rtf-agent version higher than 2.6.52, the `rtfctl` backup bundle does not contain the Mule app deployments. The deployments are synced from the Runtime Manager UI at the time of restoration. ## When to Use the Back Up and Restore Process Common scenarios for using the backup and restore process include: - Performing a major infrastructure upgrade, such as migrating nodes in a Runtime Fabric cluster to a new version of an operating system. - Migrating your Runtime Fabric cluster from on-premises to the cloud or migrating from one cloud provider to another. - Performing a failover to a standby cluster. > [!WARNING] Do not use the backup and restore process to create concurrent running instances of > Runtime Fabric. In other words, do not back up Runtime Fabric A, use that back up to create a new > Runtime Fabric B while Runtime Fabric A is still active, and attempt to run them concurrently. > This creates application deployment issues. ## What Gets Backed Up The Runtime Fabric backup process affects only the Runtime Fabric cluster. The backup process does not back up data from the control plane. For regular Kubernetes clusters, the following is backed up: - Runtime Fabric cluster details, such as controller and worker node configurations - Cluster-level secure properties - All data in the Runtime Fabric and application namespace, such as data about deployments, services and service accounts, secrets, ingress resources, role bindings, cluster role configurations, and ConfigMap settings - The current `rtfctl` version - The current Runtime Fabric agent version - Application details including: - Application configurations for pods, replicasets, application metadata, and templates - Application properties configured in Runtime Manager - Data from other Mulesoft configurations, including: - Object Store - Edge - Anypoint Monitoring and external logforwarders For OpenShift clusters, the following is backed up: - Custom Resources - Application namespaces and for each one: - Secrets - Service Account - ConfigMap - Services - CronJobs - DaemonSets - Deployments - Ingress - Role - Role Bindings - Ingress from Runtime Fabric namespace ## What Does Not Get Backed Up - Data about application state - Data from Ops Center - Data from the control plane ### Changes Made After Performing a Backup Are Not Restored All changes performed on the control plane side don’t need a new backup to be taken into account because those are taken from the platform at the time of restoration. Any changes done on the cluster side aren’t part of the restoration and must be reapplied. These changes include: - RTFCTL managed secure properties - Ingress resources on Runtime Fabric namespace - ConfigMap settings ## Create a Backup Before creating a backup: - Verify that Runtime Fabric is installed and running successfully. - Verify that `rtfctl` command-line tool is upgraded to version 0.3.102 or later. Verify the version by running `rtfctl version` on any Runtime Fabric node. - Confirm that the `rtfctl` binary is present in the current directory and `kubectl` is present in the user `$PATH`. Additionally, confirm that you’ve set the Kubernetes (`kubectl`) context to the intended backup cluster. > [!WARNING] Creating a backup per node, such as via a VM snapshot, is not supported. To create a backup, run the following command: ```copy ./rtfctl backup ``` This command creates a backup of the current system state in ``, which can be any path in the file system that you have write access to, such as: `/opt/anypoint/runtimefabric/backup.tar.gz`. ## Perform a Restore > [!IMPORTANT] Before you restore a cluster, review the following information: > > - You must perform the restore on the same Runtime Fabric cluster that is listed in Runtime > Manager (the same cluster in the control plane). > > - Configuration changes you make to deployed applications and management services after a back up > are not restored. > > - Application monitoring metrics are not restored. > > - When restoring on an existing Runtime Fabric cluster, use the same version of the `rftctl` > command-line utility that you used to create the backup. Runtime Fabric provides two target options when restoring a cluster from a backup: - Use an existing Runtime Fabric cluster. - Create a new Kubernetes cluster with the same configuration as the backed-up cluster. This includes the same number of servers, disks, etc. To restore a cluster on Runtime Fabric, create a cluster **without** running the `rtfctl` install command. After you create the cluster, complete the restore process. 1. Choose a target option for restoring a cluster. 2. Ensure you have installed `rftctl` in the cluster. 3. Copy the backup file you previously created, and make sure it is available to `rtfctl`. 4. Confirm your Kubernetes (kubectl) context is set to the backed-up cluster, and scale down all Runtime Fabric components on the original backed-up cluster: ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. Restore the cluster from the backup: ./rtfctl restore This process may require several minutes to complete. For Runtime Fabric, confirm the `rtfctl` binary is present in the current directory and the Kubernetes (kubectl) context is set to the cluster you are restoring to. ## Create a Backup and Restore for OpenShift Clusters In the following example, you have a Runtime Fabric with a set of Mule applications and configurations deployed on cluster (named `cluster-1`) inside an OpenShift cluster. To create a backup and perform a restore, follow these steps: 1. Run the backup command: ```copy ./rtfctl backup -n ``` > [!NOTE] MuleSoft performs the back up based on the detected cluster you have. Though, you can > also manually specify the type of back up to perform using the flag `--backup-type` string. > The flag options are `auto`, `openshift`, and `full`. With the default `auto` flag option, > MuleSoft automatically detects the infrastructure cluster provider to perform the back up. 2. Shutdown `cluster-1`. 3. Delete all Mule application deployments by running the following command: ```copy kubectl delete ns ``` Do not remove applications from the Runtime Manager UI. 4. Remove the Runtime Fabric installation. 5. Remove the Runtime Fabric operator from the OpenShift cluster (optional). 6. Send a `curl` command to the management plane API endpoint to regenerate the activation ID. The Runtime Fabric shows as ready for activation. You can install and activate Runtime Fabric again on a new OpenShift cluster. ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. Install the Runtime Fabric operator on `cluster-2` using the regenerated activation data ID. The installation must be on the same Runtime Fabric namespace. All labels on the backup point to that installation. 8. Run the restore command to pick the set of resources and restore them in the cluster: ```copy ./rtfctl restore -n ``` 9. Check the status of your Runtime Fabric deployments. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.9 --- # Backing Up and Restoring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the following procedures to back up and restore Runtime Fabric services and the required state necessary for all deployed applications and their configurations. Data about the state of Runtime Fabric is distributed across the Kubernetes cluster. To preserve applications in the event of system failure, confirm that Runtime Fabric is automatically backed up. When scheduling backups, follow best practices by configuring hourly backups. Store your backup on external storage outside the Runtime Fabric cluster. Starting with `rtfctl` version 1.0.70, if you use an rtf-agent version higher than 2.6.52, the `rtfctl` backup bundle does not contain the Mule app deployments. The deployments are synched from the Runtime Manager UI at the time of restoration. ## When to Use the Back Up and Restore Process Common scenarios for using the backup and restore process include: - Performing a major infrastructure upgrade, such as migrating nodes in a Runtime Fabric cluster to a new version of an operating system. - Migrating your Runtime Fabric cluster from on-premises to the cloud or migrating from one cloud provider to another. - Performing a failover to a standby cluster. > [!WARNING] Do not use the backup and restore process to create concurrent running instances of > Runtime Fabric. In other words, do not back up Runtime Fabric A, use that back up to create a new > Runtime Fabric B while Runtime Fabric A is still active, and attempt to run them concurrently. > This creates application deployment issues. ## What Gets Backed Up The Runtime Fabric backup process affects only the Runtime Fabric cluster. The backup process does not back up data from the control plane. For regular Kubernetes clusters, the following is backed up: - Runtime Fabric cluster details, such as controller and worker node configurations - Cluster-level secure properties - All data in the Runtime Fabric and application namespace, such as data about deployments, services and service accounts, secrets, ingress resources, role bindings, cluster role configurations, and ConfigMap settings - The current `rtfctl` version - The current Runtime Fabric agent version - Application details including: - Application configurations for pods, replicasets, application metadata, and templates - Application properties configured in Runtime Manager - Data from other Mulesoft configurations, including: - Object Store - Edge - Anypoint Monitoring and external logforwarders For OpenShift clusters, the following is backed up: - Custom Resources - Application namespaces and for each one: - Secrets - Service Account - ConfigMap - Services - CronJobs - DaemonSets - Deployments - Ingress - Role - Role Bindings - Ingress from Runtime Fabric namespace ## What Does Not Get Backed Up - Data about application state - Data from Ops Center - Data from the control plane ### Changes Made After Performing a Backup Are Not Restored Any changes you make after you perform a backup will not be present if you restore the cluster from that backup. For example, if you perform a backup, delete an application, and then restore from that backup, the application you deleted will be recreated in the cluster, but it will be marked as deleted in Runtime Manager. As a result the application’s status will show as **applying** in Runtime Manager. Runtime Fabric does not restore the following control plane changes if you make them after you take a backup: - Created apps - Delete apps - Updated app configurations - Agent upgrades You need to manually resolve such inconsistencies by reapplying the changes you made after performing the backup, as these changes can’t be reapplied from the control plane. ## Create a Backup Before creating a backup: - Verify that Runtime Fabric is installed and running successfully. - Verify that `rtfctl` command-line tool is upgraded to version 0.3.102 or later. Verify the version by running `rtfctl version` on any Runtime Fabric node. - Confirm that the `rtfctl` binary is present in the current directory and `kubectl` is present in the user `$PATH`. Additionally, confirm that you’ve set the Kubernetes (`kubectl`) context to the intended backup cluster. > [!WARNING] Creating a backup per node, such as via a VM snapshot, is not supported. To create a backup, run the following command: ```copy ./rtfctl backup ``` This command creates a backup of the current system state in ``, which can be any path in the file system that you have write access to, such as: `/opt/anypoint/runtimefabric/backup.tar.gz`. ## Perform a Restore > [!IMPORTANT] Before you restore a cluster, review the following information: > > - You must perform the restore on the same Runtime Fabric cluster that is listed in Runtime > Manager (the same cluster in the control plane). > > - Configuration changes you make to deployed applications and management services after a back up > are not restored. > > - Application monitoring metrics are not restored. > > - When restoring on an existing Runtime Fabric cluster, use the same version of the `rftctl` > command-line utility that you used to create the backup. Runtime Fabric provides two target options when restoring a cluster from a backup: - Use an existing Runtime Fabric cluster. - Create a new Kubernetes cluster with the same configuration as the backed-up cluster. This includes the same number of servers, disks, etc. To restore a cluster on Runtime Fabric, create a cluster **without** running the `rtfctl` install command. After you create the cluster, complete the restore process. 1. Choose a target option for restoring a cluster. 2. Ensure you have installed `rftctl` in the cluster. 3. Copy the backup file you previously created, and make sure it is available to `rtfctl`. 4. Confirm your Kubernetes (kubectl) context is set to the backed-up cluster, and scale down all Runtime Fabric components on the original backed-up cluster: ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. Restore the cluster from the backup: ./rtfctl restore This process may require several minutes to complete. For Runtime Fabric, confirm the `rtfctl` binary is present in the current directory and the Kubernetes (kubectl) context is set to the cluster you are restoring to. ## Create a Backup and Restore for OpenShift Clusters In the following example, you have a Runtime Fabric with a set of Mule applications and configurations deployed on cluster (named `cluster-1`) inside an OpenShift cluster. To create a backup and perform a restore, follow these steps: 1. Run the backup command: ```copy ./rtfctl backup -n ``` > [!NOTE] MuleSoft performs the back up based on the detected cluster you have. Though, you can > also manually specify the type of back up to perform using the flag `--backup-type` string. > The flag options are `auto`, `openshift`, and `full`. With the default `auto` flag option, > MuleSoft automatically detects the infrastructure cluster provider to perform the back up. 2. Shutdown `cluster-1`. 3. Delete all Mule application deployments by running the following command: ```copy kubectl delete ns ``` Do not remove applications from the Runtime Manager UI. 4. Remove the Runtime Fabric installation. 5. Remove the Runtime Fabric operator from the OpenShift cluster (optional). 6. Send a `curl` command to the management plane API endpoint to regenerate the activation ID. The Runtime Fabric shows as ready for activation. You can install and activate Runtime Fabric again on a new OpenShift cluster. ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. Install the Runtime Fabric operator on `cluster-2` using the regenerated activation data ID. The installation must be on the same Runtime Fabric namespace. All labels on the backup point to that installation. 8. Run the restore command to pick the set of resources and restore them in the cluster: ```copy ./rtfctl restore -n ``` 9. Check the status of your Runtime Fabric deployments. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/hardening-runtime-fabric) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Backing Up and Restoring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the following procedures to back up and restore Runtime Fabric services and the required state necessary for all deployed applications and their configurations. Data about the state of Runtime Fabric is distributed across the Kubernetes cluster. To preserve applications in the event of system failure, confirm that Runtime Fabric is automatically backed up. When scheduling backups, follow best practices by configuring hourly backups. Store your backup on external storage outside the Runtime Fabric cluster. Starting with `rtfctl` version 1.0.70, if you use an rtf-agent version higher than 2.6.52, the `rtfctl` backup bundle does not contain the Mule app deployments. The deployments are synched from the Runtime Manager UI at the time of restoration. ## When to Use the Back Up and Restore Process Common scenarios for using the backup and restore process include: - Performing a major infrastructure upgrade, such as migrating nodes in a Runtime Fabric cluster to a new version of an operating system. - Migrating your Runtime Fabric cluster from on-premises to the cloud or migrating from one cloud provider to another. - Performing a failover to a standby cluster. > [!WARNING] Do not use the backup and restore process to create concurrent running instances of > Runtime Fabric. In other words, do not back up Runtime Fabric A, use that back up to create a new > Runtime Fabric B while Runtime Fabric A is still active, and attempt to run them concurrently. > This creates application deployment issues. ## What Gets Backed Up The Runtime Fabric backup process affects only the Runtime Fabric cluster. The backup process does not back up data from the control plane. For regular Kubernetes clusters, the following is backed up: - Runtime Fabric cluster details, such as controller and worker node configurations - Cluster-level secure properties - All data in the Runtime Fabric and application namespace, such as data about deployments, services and service accounts, secrets, ingress resources, role bindings, cluster role configurations, and ConfigMap settings - The current `rtfctl` version - The current Runtime Fabric agent version - Application details including: - Application configurations for pods, replicasets, application metadata, and templates - Application properties configured in Runtime Manager - Data from other Mulesoft configurations, including: - Object Store - Edge - Anypoint Monitoring and external logforwarders For OpenShift clusters, the following is backed up: - Custom Resources - Application namespaces and for each one: - Secrets - Service Account - ConfigMap - Services - CronJobs - DaemonSets - Deployments - Ingress - Role - Role Bindings - Ingress from Runtime Fabric namespace ## What Does Not Get Backed Up - Data about application state - Data from Ops Center - Data from the control plane ### Changes Made After Performing a Backup Are Not Restored Any changes you make after you perform a backup will not be present if you restore the cluster from that backup. For example, if you perform a backup, delete an application, and then restore from that backup, the application you deleted will be recreated in the cluster, but it will be marked as deleted in Runtime Manager. As a result the application’s status will show as **applying** in Runtime Manager. Runtime Fabric does not restore the following control plane changes if you make them after you take a backup: - Created apps - Delete apps - Updated app configurations - Agent upgrades You need to manually resolve such inconsistencies by reapplying the changes you made after performing the backup, as these changes can’t be reapplied from the control plane. ## Create a Backup Before creating a backup: - Verify that Runtime Fabric is installed and running successfully. - Verify that `rtfctl` command-line tool is upgraded to version 0.3.102 or later. Verify the version by running `rtfctl version` on any Runtime Fabric node. - Confirm that the `rtfctl` binary is present in the current directory and `kubectl` is present in the user `$PATH`. Additionally, confirm that you’ve set the Kubernetes (`kubectl`) context to the intended backup cluster. > [!WARNING] Creating a backup per node, such as via a VM snapshot, is not supported. To create a backup, run the following command: ```copy ./rtfctl backup ``` This command creates a backup of the current system state in ``, which can be any path in the file system that you have write access to, such as: `/opt/anypoint/runtimefabric/backup.tar.gz`. ## Perform a Restore > [!IMPORTANT] Before you restore a cluster, review the following information: > > - You must perform the restore on the same Runtime Fabric cluster that is listed in Runtime > Manager (the same cluster in the control plane). > > - Configuration changes you make to deployed applications and management services after a back up > are not restored. > > - Application monitoring metrics are not restored. > > - When restoring on an existing Runtime Fabric cluster, use the same version of the `rftctl` > command-line utility that you used to create the backup. Runtime Fabric provides two target options when restoring a cluster from a backup: - Use an existing Runtime Fabric cluster. - Create a new Kubernetes cluster with the same configuration as the backed-up cluster. This includes the same number of servers, disks, etc. To restore a cluster on Runtime Fabric, create a cluster **without** running the `rtfctl` install command. After you create the cluster, complete the restore process. 1. Choose a target option for restoring a cluster. 2. Ensure you have installed `rftctl` in the cluster. 3. Copy the backup file you previously created, and make sure it is available to `rtfctl`. 4. Confirm your Kubernetes (kubectl) context is set to the backed-up cluster, and scale down all Runtime Fabric components on the original backed-up cluster: ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. Restore the cluster from the backup: ./rtfctl restore This process may require several minutes to complete. For Runtime Fabric, confirm the `rtfctl` binary is present in the current directory and the Kubernetes (kubectl) context is set to the cluster you are restoring to. ## Create a Backup and Restore for OpenShift Clusters In the following example, you have a Runtime Fabric with a set of Mule applications and configurations deployed on cluster (named `cluster-1`) inside an OpenShift cluster. To create a backup and perform a restore, follow these steps: 1. Run the backup command: ```copy ./rtfctl backup -n ``` > [!NOTE] MuleSoft performs the back up based on the detected cluster you have. Though, you can > also manually specify the type of back up to perform using the flag `--backup-type` string. > The flag options are `auto`, `openshift`, and `full`. With the default `auto` flag option, > MuleSoft automatically detects the infrastructure cluster provider to perform the back up. 2. Shutdown `cluster-1`. 3. Delete all Mule application deployments by running the following command: ```copy kubectl delete ns ``` Do not remove applications from the Runtime Manager UI. 4. Remove the Runtime Fabric installation. 5. Remove the Runtime Fabric operator from the OpenShift cluster (optional). 6. Send a `curl` command to the management plane API endpoint to regenerate the activation ID. The Runtime Fabric shows as ready for activation. You can install and activate Runtime Fabric again on a new OpenShift cluster. ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. Install the Runtime Fabric operator on `cluster-2` using the regenerated activation data ID. The installation must be on the same Runtime Fabric namespace. All labels on the backup point to that installation. 8. Run the restore command to pick the set of resources and restore them in the cluster: ```copy ./rtfctl restore -n ``` 9. Check the status of your Runtime Fabric deployments. \[\[backup-restore-rtfctl\] ## Commands for Backing Up and Restoring a Runtime Fabric with RTFCTL Use these commands to back up and restore a Runtime Fabric.
CommandDescription

Performs a back up of the local Runtime Fabric state

Restores local Runtime Fabric state from a backup

### `backup` Performs a back up of the local Runtime Fabric state. rtfctl backup .tar.gz --namespace ### `restore` Restores the local Runtime Fabric state from a backup rtfctl restore .tar.gz --namespace Restore only the core Runtime Fabric software components without triggering application synchronization from the control plane. rtfctl restore .tar.gz --namespace --core-software-only ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.10 --- # Cluster Configurations > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To use the complete value of Runtime Fabric, refer to your respective Kubernetes (K8s) provider’s configuration specification. To get started, use the following recommended configurations to set up your cluster.
Type of configurationEKS-AEKSApplianceMuleSoft requirements

Infrastructure

Vsphere/Bare Metal

AWS

Pre-provisioned hosts

-

Ingress

Emissary, Nginx-ingress or any other available ingress options.

Nginx ingress

Nginx ingress

Customer-managed component config

Load balancer

MetalLB

ELB

-

Customer-managed component config

Monitoring

Grafana/Prometheus

CloudWatch

Grafana/Prometheus

Check Requirements and Limitations of Runtime Fabric

Local cluster registry

Harbor or any other compliant implementation

ECR

Docker registry running inside the cluster

Cluster size limits

Kubernetes imposed limits on the cluster size.

1000 managed nodes

21 total (5 control plane nodes + 16 worker nodes

-

CK8s distro

EKS-D

EKS-D

Custom distro (planet)

Check Requirements and Limitations of Runtime Fabric

Cluster mgmt tool

eksctl or eksctl-anywhere

eksctl

Custom utility (rtfctl)

Check Requirements and Limitations of Runtime Fabric

--- product: Runtime Fabric version: 2.11 --- # Cluster Configurations > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To use the complete value of Runtime Fabric, refer to your respective Kubernetes (K8s) provider’s configuration specification. To get started, use these recommended configurations to set up your cluster.
Type of configurationEKS-AEKSApplianceMuleSoft requirements

Infrastructure

Vsphere/Bare Metal

AWS

Pre-provisioned hosts

-

Ingress

Emissary, Nginx-ingress or any other available ingress options.

Nginx ingress

Nginx ingress

Customer-managed component config

Load balancer

MetalLB

ELB

-

Customer-managed component config

Monitoring

Grafana/Prometheus

CloudWatch

Grafana/Prometheus

Check Requirements and Limitations of Runtime Fabric

Local cluster registry

Harbor or any other compliant implementation

ECR

Docker registry running inside the cluster

Cluster size limits

Kubernetes imposed limits on the cluster size.

1000 managed nodes

21 total (5 control plane nodes + 16 worker nodes

-

CK8s distro

EKS-D

EKS-D

Custom distro (planet)

Check Requirements and Limitations of Runtime Fabric

Cluster mgmt tool

eksctl or eksctl-anywhere

eksctl

Custom utility (rtfctl)

Check Requirements and Limitations of Runtime Fabric

--- product: Runtime Fabric version: 2.5 --- # Cluster Configurations > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To use the complete value of Runtime Fabric, refer to your respective Kubernetes (K8s) provider’s configuration specification. To get started, use the following recommended configurations to set up your cluster.
Type of configurationEKS-AEKSApplianceMuleSoft requirements

Infrastructure

Vsphere/Bare Metal

AWS

Pre-provisioned hosts

-

Ingress

Emissary, Nginx-ingress or any other available ingress options.

Nginx ingress

Nginx ingress

Customer-managed component config

Load balancer

MetalLB

ELB

-

Customer-managed component config

Monitoring

Grafana/Prometheus

CloudWatch

Grafana/Prometheus

Check Requirements and Limitations of Runtime Fabric

Local cluster registry

Harbor or any other compliant implementation

ECR

Docker registry running inside the cluster

Cluster size limits

Kubernetes imposed limits on the cluster size.

1000 managed nodes

21 total (5 control plane nodes + 16 worker nodes

-

CK8s distro

EKS-D

EKS-D

Custom distro (planet)

Check Requirements and Limitations of Runtime Fabric

Cluster mgmt tool

eksctl or eksctl-anywhere

eksctl

Custom utility (rtfctl)

Check Requirements and Limitations of Runtime Fabric

--- product: Runtime Fabric version: 2.6 --- # Cluster Configurations > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To use the complete value of Runtime Fabric, refer to your respective Kubernetes (K8s) provider’s configuration specification. To get started, use the following recommended configurations to set up your cluster.
Type of configurationEKS-AEKSApplianceMuleSoft requirements

Infrastructure

Vsphere/Bare Metal

AWS

Pre-provisioned hosts

-

Ingress

Emissary, Nginx-ingress or any other available ingress options.

Nginx ingress

Nginx ingress

Customer-managed component config

Load balancer

MetalLB

ELB

-

Customer-managed component config

Monitoring

Grafana/Prometheus

CloudWatch

Grafana/Prometheus

Check Requirements and Limitations of Runtime Fabric

Local cluster registry

Harbor or any other compliant implementation

ECR

Docker registry running inside the cluster

Cluster size limits

Kubernetes imposed limits on the cluster size.

1000 managed nodes

21 total (5 control plane nodes + 16 worker nodes

-

CK8s distro

EKS-D

EKS-D

Custom distro (planet)

Check Requirements and Limitations of Runtime Fabric

Cluster mgmt tool

eksctl or eksctl-anywhere

eksctl

Custom utility (rtfctl)

Check Requirements and Limitations of Runtime Fabric

--- product: Runtime Fabric version: 2.7 --- # Cluster Configurations > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To use the complete value of Runtime Fabric, refer to your respective Kubernetes (K8s) provider’s configuration specification. To get started, use the following recommended configurations to set up your cluster.
Type of configurationEKS-AEKSApplianceMuleSoft requirements

Infrastructure

Vsphere/Bare Metal

AWS

Pre-provisioned hosts

-

Ingress

Emissary, Nginx-ingress or any other available ingress options.

Nginx ingress

Nginx ingress

Customer-managed component config

Load balancer

MetalLB

ELB

-

Customer-managed component config

Monitoring

Grafana/Prometheus

CloudWatch

Grafana/Prometheus

Check Requirements and Limitations of Runtime Fabric

Local cluster registry

Harbor or any other compliant implementation

ECR

Docker registry running inside the cluster

Cluster size limits

Kubernetes imposed limits on the cluster size.

1000 managed nodes

21 total (5 control plane nodes + 16 worker nodes

-

CK8s distro

EKS-D

EKS-D

Custom distro (planet)

Check Requirements and Limitations of Runtime Fabric

Cluster mgmt tool

eksctl or eksctl-anywhere

eksctl

Custom utility (rtfctl)

Check Requirements and Limitations of Runtime Fabric

--- product: Runtime Fabric version: 2.8 --- # Cluster Configurations > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To use the complete value of Runtime Fabric, refer to your respective Kubernetes (K8s) provider’s configuration specification. To get started, use the following recommended configurations to set up your cluster.
Type of configurationEKS-AEKSApplianceMuleSoft requirements

Infrastructure

Vsphere/Bare Metal

AWS

Pre-provisioned hosts

-

Ingress

Emissary, Nginx-ingress or any other available ingress options.

Nginx ingress

Nginx ingress

Customer-managed component config

Load balancer

MetalLB

ELB

-

Customer-managed component config

Monitoring

Grafana/Prometheus

CloudWatch

Grafana/Prometheus

Check Requirements and Limitations of Runtime Fabric

Local cluster registry

Harbor or any other compliant implementation

ECR

Docker registry running inside the cluster

Cluster size limits

Kubernetes imposed limits on the cluster size.

1000 managed nodes

21 total (5 control plane nodes + 16 worker nodes

-

CK8s distro

EKS-D

EKS-D

Custom distro (planet)

Check Requirements and Limitations of Runtime Fabric

Cluster mgmt tool

eksctl or eksctl-anywhere

eksctl

Custom utility (rtfctl)

Check Requirements and Limitations of Runtime Fabric

--- product: Runtime Fabric version: 2.9 --- # Cluster Configurations > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To use the complete value of Runtime Fabric, refer to your respective Kubernetes (K8s) provider’s configuration specification. To get started, use the following recommended configurations to set up your cluster.
Type of configurationEKS-AEKSApplianceMuleSoft requirements

Infrastructure

Vsphere/Bare Metal

AWS

Pre-provisioned hosts

-

Ingress

Emissary, Nginx-ingress or any other available ingress options.

Nginx ingress

Nginx ingress

Customer-managed component config

Load balancer

MetalLB

ELB

-

Customer-managed component config

Monitoring

Grafana/Prometheus

CloudWatch

Grafana/Prometheus

Check Requirements and Limitations of Runtime Fabric

Local cluster registry

Harbor or any other compliant implementation

ECR

Docker registry running inside the cluster

Cluster size limits

Kubernetes imposed limits on the cluster size.

1000 managed nodes

21 total (5 control plane nodes + 16 worker nodes

-

CK8s distro

EKS-D

EKS-D

Custom distro (planet)

Check Requirements and Limitations of Runtime Fabric

Cluster mgmt tool

eksctl or eksctl-anywhere

eksctl

Custom utility (rtfctl)

Check Requirements and Limitations of Runtime Fabric

--- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configure a Local Registry for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt By default, Runtime Fabric pulls the Docker images it needs for installation, management, and application deployments from the MuleSoft-managed registry. If your security policies require that all images come from a registry you control, you can configure Runtime Fabric to use a local registry instead. ## Requirements and Considerations You can configure a local registry across all Runtime Fabric supported platform vendors to store Mule Docker images and Runtime Fabric software images. > [!IMPORTANT] You cannot use a local registry for installation or management of the Runtime Fabric > operator on OpenShift. ### Supported Configurations - You can use [Runtime Fabric command line utility (`rtfctl`)](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) version 0.3.150 or later. `rtfctl` installs Runtime Fabric agent to the latest version by default. - You can use Helm to install Runtime Fabric and configure your local registry. - You can use a local registry only if you create a new Runtime Fabric instance of version 1.12.0 or later. Once configured, you can upgrade to later versions without reinstalling Runtime Fabric. To add a local registry to an existing Runtime Fabric instance, ensure the installation is Helm-based (see [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/migrate-helm)) and follow the steps in this page. > [!IMPORTANT] Local registry configuration is a one-way change. After you configure Runtime Fabric > to use a local registry, you cannot reconfigure it to use the `rtf-runtime-registry` endpoint. To > revert, you must install a new Runtime Fabric instance using the standard installation procedure. ### Synchronization and Authentication You must keep your local registry synchronized with the images Runtime Fabric requires: - [Synchronize Runtime Fabric Core Software Images](#synch-rtf) — synchronize automatically or manually before installation and upgrades. - [Synchronize Mule Runtime Images](#synch-runtime) — synchronize manually for each runtime version you deploy. - Third-party dependencies required by your applications — MuleSoft does not provide tooling for this. Push all required images to your local registry before starting deployments. If your local registry requires authentication, pull secret propagation across namespaces is your responsibility. Alternatively, Runtime Fabric can synchronize your pull secret automatically if you apply this label to the secret: labels: rtf.mulesoft.com/synchronized: "true" Ensure that the [corresponding credentials are configured as a Kubernetes secret in the `rtf` namespace](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials). You need the name of this secret when you install Runtime Fabric. ## Synchronize Images to Your Local Registry Before you can install or configure Runtime Fabric with a local registry, you must synchronize the required images. These sections cover Runtime Fabric core software images and Mule runtime images separately, as they use different sources and synchronization methods. ### Synchronize Runtime Fabric Core Software Images To install Runtime Fabric, you must first synchronize the core software images to your local registry. You can perform the synchronization by either running a script automatically or executing commands manually. - Synchronize Automatically - Synchronize Manually To synchronize the dependencies images automatically, run a bash script that uses the `docker`, `curl`, and `jq` tools. > [!NOTE] Automated registry synchronization is available from Runtime Fabric version 2.6.0 onwards. > Previous dependencies cannot be retrieved using this script. Ensure that your [Access Management permission for Runtime Manager](https://docs.mulesoft.com/access-management/permissions-by-product#runtime-manager) is set to **Read Runtime Fabric**, which enables you to query Runtime Fabrics in your organization. 1. In your Unix shell, run this script, replacing `agent-version`, `authorization-token`, `mulesoft-docker-server`, and any other parameter value where appropriate: For non-OpenShift environments: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("generic")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull //$i docker tag //$i /mulesoft/$i docker push /mulesoft/$i done ``` For OpenShift environments: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("openshift")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull //$i docker tag //$i /mulesoft/$i docker push /mulesoft/$i done ```
Table 1. Script Parameters
ParametersDescription

platform-url

Anypoint Platform URL, such as https://anypoint.mulesoft.com, or https://eu1.anypoint.mulesoft.com.

agent-version

Runtime Fabric agent release version required for the synchronization.

authorization-token

Authorization token required for using connected apps to perform the synchronization. When you use this token, a link redirects to the connected apps page.

mulesoft-docker-server

MuleSoft Docker server required for the synchronization.

  • US Cloud: rtf-runtime-registry.kprod.msap.io

  • EU Cloud: rtf-runtime-registry.kprod-eu.msap.io

  • Canada Cloud: rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net

  • Japan Cloud: rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net

  • India Cloud: rtf-runtime-registry-mulesoft-cp.sfdc-y37hzm.svc.sfdcfc.net

  • Australia Cloud: rtf-runtime-registry-mulesoft-cp.sfdc-vwfla6.svc.sfdcfc.net

  • United Kingdom Cloud: rtf-runtime-registry-mulesoft-cp.sfdc-5pakla.svc.sfdcfc.net

image-path

Image namespace path on the registry.

  • US Cloud and EU Cloud: mulesoft

  • Canada Cloud, Japan Cloud, India Cloud, Australia Cloud, and United Kingdom Cloud: sfci/mulesoft/ms-docker-image

> [!NOTE] For Canada Cloud, Japan Cloud, India Cloud, Australia Cloud, and United Kingdom Cloud, > images in the SFCI registry use an `ms-` prefix in the artifact name (for example, `ms-rtf-agent` > instead of `rtf-agent`). The automated script does not account for this prefix difference, so you > must manually prepend `ms-` to each artifact name when pulling from the SFCI registry for these > regions. To synchronize the dependencies images manually, follow these steps: > [!NOTE] Repeat the pull/tag/push pattern shown below for each dependency image listed in the > [Runtime Fabric release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) > for your version, not just `rtf-agent`. 1. Log in to your private container registry and run this command, replacing `docker-server` where appropriate: For the US Cloud: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the EU Cloud: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the Canada Cloud: ```copy # docker pull rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-rtf-agent:v1.12.0 # docker tag rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the Japan Cloud: ```copy # docker pull rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-rtf-agent:v1.12.0 # docker tag rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the India Cloud: ```copy # docker pull rtf-runtime-registry-mulesoft-cp.sfdc-y37hzm.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-rtf-agent:v1.12.0 # docker tag rtf-runtime-registry-mulesoft-cp.sfdc-y37hzm.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the Australia Cloud: ```copy # docker pull rtf-runtime-registry-mulesoft-cp.sfdc-vwfla6.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-rtf-agent:v1.12.0 # docker tag rtf-runtime-registry-mulesoft-cp.sfdc-vwfla6.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the United Kingdom Cloud: ```copy # docker pull rtf-runtime-registry-mulesoft-cp.sfdc-5pakla.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-rtf-agent:v1.12.0 # docker tag rtf-runtime-registry-mulesoft-cp.sfdc-5pakla.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` ### Synchronize Mule Runtime Images To synchronize the Mule runtime versions you plan to use for application deployments, refer to the [Mule runtime patch updates for Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) for the image names and tags. The source registry depends on your control plane:
Control PlaneImage Location Format

US Cloud

rtf-runtime-registry.kprod.msap.io/mulesoft/<image>:<tag>

EU Cloud

rtf-runtime-registry.kprod-eu.msap.io/mulesoft/<image>:<tag>

Canada Cloud

rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net/v2/sfci/mulesoft/ms-docker-image/<image>:<tag>

Japan Cloud

rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net/v2/sfci/mulesoft/ms-docker-image/<image>:<tag>

India Cloud

rtf-runtime-registry-mulesoft-cp.sfdc-y37hzm.svc.sfdcfc.net/v2/sfci/mulesoft/ms-docker-image/<image>:<tag>

Australia Cloud

rtf-runtime-registry-mulesoft-cp.sfdc-vwfla6.svc.sfdcfc.net/v2/sfci/mulesoft/ms-docker-image/<image>:<tag>

United Kingdom Cloud

rtf-runtime-registry-mulesoft-cp.sfdc-5pakla.svc.sfdcfc.net/v2/sfci/mulesoft/ms-docker-image/<image>:<tag>

> [!NOTE] For Canada Cloud, Japan Cloud, India Cloud, Australia Cloud, and United Kingdom Cloud > deployments on OpenShift, download these images from the SFCI registry: > > - Mule runtime: `/sfci/mulesoft/ms-docker-image/ms-poseidon-runtime-:` > > - Anypoint Monitoring sidecar: > `/sfci/mulesoft/ms-docker-image/ms-dias-anypoint-monitoring-sidecar-ubi:` There is no automated tooling for Mule runtime images. For each runtime version you deploy, manually pull the image from the MuleSoft source registry, retag it for your local registry, and push it, using the same `docker pull`/`docker tag`/`docker push` pattern shown for the core software images. Log in to both the MuleSoft source registry and your private container registry, then run these commands for your control plane, replacing `` and `` with the values from the [Mule runtime release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) and `` with your local registry server. These examples synchronize a single Mule runtime image; repeat the pattern for each runtime version you deploy. For the US Cloud: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/: # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/: /mulesoft/: # docker push /mulesoft/: ``` For the EU Cloud: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/: # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/: /mulesoft/: # docker push /mulesoft/: ``` For the Canada Cloud: ```copy # docker pull rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-: # docker tag rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-: /mulesoft/: # docker push /mulesoft/: ``` For the Japan Cloud: ```copy # docker pull rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-: # docker tag rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-: /mulesoft/: # docker push /mulesoft/: ``` For the India Cloud: ```copy # docker pull rtf-runtime-registry-mulesoft-cp.sfdc-y37hzm.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-: # docker tag rtf-runtime-registry-mulesoft-cp.sfdc-y37hzm.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-: /mulesoft/: # docker push /mulesoft/: ``` For the Australia Cloud: ```copy # docker pull rtf-runtime-registry-mulesoft-cp.sfdc-vwfla6.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-: # docker tag rtf-runtime-registry-mulesoft-cp.sfdc-vwfla6.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-: /mulesoft/: # docker push /mulesoft/: ``` For the United Kingdom Cloud: ```copy # docker pull rtf-runtime-registry-mulesoft-cp.sfdc-5pakla.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-: # docker tag rtf-runtime-registry-mulesoft-cp.sfdc-5pakla.svc.sfdcfc.net/sfci/mulesoft/ms-docker-image/ms-: /mulesoft/: # docker push /mulesoft/: ``` > [!NOTE] For Canada Cloud, Japan Cloud, India Cloud, Australia Cloud, and United Kingdom Cloud, the > source image in the SFCI registry uses an `ms-` prefix in the artifact name (for example, > `ms-`). When you retag the image for your local registry, drop the `ms-` prefix so that > Runtime Fabric can pull it using the expected name. ## Configure Your Local Registry for Runtime Fabric To configure a local registry, you must gather and add the necessary credentials to synchronize the registries. ### Before You Begin Ensure that you’ve completed these steps before proceeding: 1. Set up, configure, and test your private Docker image registry. 2. [Synchronize](#synchronize-images-to-your-local-registry) all required Docker images to your local registry. See the [Runtime Fabric release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the dependency versions specific to your Runtime Fabric version. To install Runtime Fabric with your local registry, select your installation method: - RTFCTL - Helm - OpenShift 1. [Download and install the `rtfctl` command line utility](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed#step-3-download-the-rtfctl-utility) version 0.3.150 or higher. 2. Obtain `rtf-runtime-registry` credentials: ```copy # rtfctl get registry-credentials ``` This command sets `RTF_IMAGE_REGISTRY_ENDPOINT`, `RTF_IMAGE_REGISTRY_USER`, and `RTF_IMAGE_REGISTRY_PASSWORD` in the current shell environment. 3. Run these commands to verify that the Docker login to the `rtf-runtime-registry` succeeds: ```copy # eval $(rtfctl get registry-credentials ) # docker login $RTF_IMAGE_REGISTRY_ENDPOINT --username $RTF_IMAGE_REGISTRY_USER --password $RTF_IMAGE_REGISTRY_PASSWORD ``` You should see a message that the login was successful. 4. [Synchronize your container images](#synch-rtf) to your local registry. 5. Repeat step 4 for all other dependency images (such as `resourceFetcher` and `clusterOps`) based on the versions published in the Runtime Fabric release notes. 6. If you use authentication to access your registry, create the required secret in the rtf namespace: ```copy # kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf ``` 7. Finalize the Runtime Fabric installation, and configure it to pull from your local registry: ```copy # rtfctl install ‘’ --image-pull-registry ``` Alternatively, if you use authentication to access your registry, use this command: ```copy # rtfctl install ‘’ --image-pull-registry --image-pull-secret ``` This command ensures that Runtime Fabric creates the necessary overrides for the local registry URL and `image-pull-secret` values so Runtime Fabric continues to pull images from the local registry even after an upgrade. 8. If you use authentication to access your registry, after you complete the installation, you must recreate the pull secret in the RTF namespace and in any other namespaces where you will deploy applications. 9. Refer to the [installation instructions](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed) for further steps, such as inserting the Mule license key. The `rtfctl uninstall` command deletes any pull secret you specify during installation. When using `rtfctl` to perform a backup and restore procedure, the backups point to your local registry URL and pull secret. 1. [Synchronize your container images](#synch-rtf) to your local registry. 2. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/latest/install-helm#create-a-runtime-fabric-using-runtime-manager). 3. In Runtime Manager, select the **Helm** path, and follow the on-screen instructions. 4. Obtain your private `docker-server`, `docker-username`, and `docker-password`. 5. Follow the **Helm** path instructions in Runtime Manager to create a secret with your docker server name, username, and password by running this command in your Unix shell: ```copy kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 6. Follow the **Helm** path instructions to download the `values.yml` file so that you can modify its values. For the private registry configuration, update `rtfRegistry` with your local docker server, and update the `pullSecretName` parameter. 7. Continue with the **Helm** path instructions and install Runtime Fabric in your Kubernetes cluster. 8. [Synchronize your container images](#synch-rtf) to your local registry. 9. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/latest/install-helm#create-a-runtime-fabric-using-runtime-manager). 10. In Runtime Manager, follow the on-screen instructions. 11. Obtain your private `docker-server`, `docker-username`, and `docker-password`. 12. Follow the instructions in Runtime Manager to create a secret with your docker server name, username, and password by running this command in your Unix shell: ```copy oc create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 13. In the OpenShift form view, set the rtfRegistry values to configure the local registry. ![OpenShift form view to add values for rtfRegistry](/mulesoft/current/en-us/runtime-fabric/latest/_images/ocp-local-registry.png) 14. Continue with the OpenShift installation. ## See Also - [Configure values.yml Reference](https://docs.mulesoft.com/runtime-fabric/latest/install-helm#values-yml-reference) --- product: Runtime Fabric version: 2.10 --- # Configuring Authorized Namespaces in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Authorized namespaces enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. By limiting permissions in your cluster, you can allow Runtime Fabric to access resources only within namespaces assigned to Runtime Fabric. With authorized namespaces, you have control of the creation of the following Runtime Fabric resources: - Namespaces - RoleBindings - ServiceAccounts ## How Authorized Namespaces Work At install time, you provide a configuration file that consists of your namespaces, ServiceAccounts, ClusterRoles/Roles, and RoleBindings. Runtime Fabric installs the Runtime Fabric agent (rtf-agent) in the Runtime Fabric namespace, and it has access to any additional namespaces that you provide in the authorized namespace list. ### Example The following is an example of a Runtime Fabric agent ClusterRole that allows the agent to control all cron jobs across all namespaces in a cluster. ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rtf:agent rules: - apiGroups: - batch resources: - cronjobs verbs: - create - delete - deletecollection - get - list - patch - update - watch ``` Runtime Fabric creates the required RoleBinding objects which use the ClusterRole rtf:agent to allow corresponding ServiceAccount to perform various actions (verbs) on cron jobs in two namespaces. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` ## Configure Authorized Namespaces You configure authorized namespaces when you install Runtime Fabric. Refer to the appropriate installation instructions: - [Installing Runtime Fabric on EKS, AKS, and GKE Using Helm](https://docs.mulesoft.com/runtime-fabric/2.10/install-helm) - [Install Runtime Fabric on Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.10/install-openshift) ## Add New Namespaces If you update the authorized-namespaces ConfigMap with a new namespace, you must restart the Runtime Fabric agent deployment using the following command: `kubectl rollout restart deployment/agent` --- product: Runtime Fabric version: 2.11 --- # Configuring Authorized Namespaces in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Authorized namespaces enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. By limiting permissions in your cluster, you can allow Runtime Fabric to access resources only within namespaces assigned to Runtime Fabric. With authorized namespaces, you have control of the creation of these Runtime Fabric resources: - Namespaces - RoleBindings - ServiceAccounts ## How Authorized Namespaces Work At install time, you provide a configuration file that consists of your namespaces, ServiceAccounts, ClusterRoles/Roles, and RoleBindings. Runtime Fabric installs the Runtime Fabric agent (rtf-agent) in the Runtime Fabric namespace, and it has access to any additional namespaces that you provide in the authorized namespace list. ### Example The following is an example of a Runtime Fabric agent ClusterRole that allows the agent to control all cron jobs across all namespaces in a cluster. ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rtf:agent rules: - apiGroups: - batch resources: - cronjobs verbs: - create - delete - deletecollection - get - list - patch - update - watch ``` Runtime Fabric creates the required RoleBinding objects which use the ClusterRole rtf:agent to allow corresponding ServiceAccount to perform various actions (verbs) on cron jobs in two namespaces. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default ``` To use clustered apps in authorized namespaces mode, this RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` ## Configure Authorized Namespaces You configure authorized namespaces when you install Runtime Fabric. Refer to the appropriate installation instructions: - [Installing Runtime Fabric on EKS, AKS, and GKE Using Helm](https://docs.mulesoft.com/runtime-fabric/2.11/install-helm) - [Install Runtime Fabric on Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.11/install-openshift) ## Add New Namespaces If you update the authorized-namespaces ConfigMap with a new namespace, you must restart the Runtime Fabric agent deployment using this command: `kubectl rollout restart deployment/agent` --- product: Runtime Fabric version: 2.5 --- # Configuring Authorized Namespaces in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Authorized namespaces enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. By limiting permissions in your cluster, you can allow Runtime Fabric to access resources only within namespaces assigned to Runtime Fabric. With authorized namespaces, you have control of the creation of the following Runtime Fabric resources: - Namespaces - RoleBindings - ServiceAccounts ## How Authorized Namespaces Work At install time, you provide a configuration file that consists of your namespaces, ServiceAccounts, ClusterRoles/Roles, and RoleBindings. Runtime Fabric installs the Runtime Fabric agent (rtf-agent) in the Runtime Fabric namespace, and it has access to any additional namespaces that you provide in the authorized namespace list. ### Example The following is an example of a Runtime Fabric agent ClusterRole that allows the agent to control all cron jobs across all namespaces in a cluster. ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rtf:agent rules: - apiGroups: - batch resources: - cronjobs verbs: - create - delete - deletecollection - get - list - patch - update - watch ``` Runtime Fabric creates the required RoleBinding objects which use the ClusterRole rtf:agent to allow corresponding ServiceAccount to perform various actions (verbs) on cron jobs in two namespaces. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` ## Configure Authorized Namespaces You configure authorized namespaces when you install Runtime Fabric. Refer to the appropriate installation instructions: - [Installing Runtime Fabric on EKS, AKS, and GKE Using Helm](https://docs.mulesoft.com/runtime-fabric/2.5/install-helm) - [Install Runtime Fabric on Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.5/install-openshift) --- product: Runtime Fabric version: 2.6 --- # Configuring Authorized Namespaces in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Authorized namespaces enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. By limiting permissions in your cluster, you can allow Runtime Fabric to access resources only within namespaces assigned to Runtime Fabric. With authorized namespaces, you have control of the creation of the following Runtime Fabric resources: - Namespaces - RoleBindings - ServiceAccounts ## How Authorized Namespaces Work At install time, you provide a configuration file that consists of your namespaces, ServiceAccounts, ClusterRoles/Roles, and RoleBindings. Runtime Fabric installs the Runtime Fabric agent (rtf-agent) in the Runtime Fabric namespace, and it has access to any additional namespaces that you provide in the authorized namespace list. ### Example The following is an example of a Runtime Fabric agent ClusterRole that allows the agent to control all cron jobs across all namespaces in a cluster. ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rtf:agent rules: - apiGroups: - batch resources: - cronjobs verbs: - create - delete - deletecollection - get - list - patch - update - watch ``` Runtime Fabric creates the required RoleBinding objects which use the ClusterRole rtf:agent to allow corresponding ServiceAccount to perform various actions (verbs) on cron jobs in two namespaces. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service- apiGroup: rbac.authorization.k8s.io ``` ## Configure Authorized Namespaces You configure authorized namespaces when you install Runtime Fabric. Refer to the appropriate installation instructions: - [Installing Runtime Fabric on EKS, AKS, and GKE Using Helm](https://docs.mulesoft.com/runtime-fabric/2.6/install-helm) - [Install Runtime Fabric on Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.6/install-openshift) ## Add New Namespaces If you update the authorized-namespaces ConfigMap with a new namespace, you must restart the Runtime Fabric agent deployment using the following command: `kubectl rollout restart deployment/agent` --- product: Runtime Fabric version: 2.7 --- # Configuring Authorized Namespaces in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Authorized namespaces enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. By limiting permissions in your cluster, you can allow Runtime Fabric to access resources only within namespaces assigned to Runtime Fabric. With authorized namespaces, you have control of the creation of the following Runtime Fabric resources: - Namespaces - RoleBindings - ServiceAccounts ## How Authorized Namespaces Work At install time, you provide a configuration file that consists of your namespaces, ServiceAccounts, ClusterRoles/Roles, and RoleBindings. Runtime Fabric installs the Runtime Fabric agent (rtf-agent) in the Runtime Fabric namespace, and it has access to any additional namespaces that you provide in the authorized namespace list. ### Example The following is an example of a Runtime Fabric agent ClusterRole that allows the agent to control all cron jobs across all namespaces in a cluster. ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rtf:agent rules: - apiGroups: - batch resources: - cronjobs verbs: - create - delete - deletecollection - get - list - patch - update - watch ``` Runtime Fabric creates the required RoleBinding objects which use the ClusterRole rtf:agent to allow corresponding ServiceAccount to perform various actions (verbs) on cron jobs in two namespaces. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service- apiGroup: rbac.authorization.k8s.io ``` ## Configure Authorized Namespaces You configure authorized namespaces when you install Runtime Fabric. Refer to the appropriate installation instructions: - [Installing Runtime Fabric on EKS, AKS, and GKE Using Helm](https://docs.mulesoft.com/runtime-fabric/2.7/install-helm) - [Install Runtime Fabric on Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.7/install-openshift) ## Add New Namespaces If you update the authorized-namespaces ConfigMap with a new namespace, you must restart the Runtime Fabric agent deployment using the following command: `kubectl rollout restart deployment/agent` --- product: Runtime Fabric version: 2.8 --- # Configuring Authorized Namespaces in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Authorized namespaces enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. By limiting permissions in your cluster, you can allow Runtime Fabric to access resources only within namespaces assigned to Runtime Fabric. With authorized namespaces, you have control of the creation of the following Runtime Fabric resources: - Namespaces - RoleBindings - ServiceAccounts ## How Authorized Namespaces Work At install time, you provide a configuration file that consists of your namespaces, ServiceAccounts, ClusterRoles/Roles, and RoleBindings. Runtime Fabric installs the Runtime Fabric agent (rtf-agent) in the Runtime Fabric namespace, and it has access to any additional namespaces that you provide in the authorized namespace list. ### Example The following is an example of a Runtime Fabric agent ClusterRole that allows the agent to control all cron jobs across all namespaces in a cluster. ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rtf:agent rules: - apiGroups: - batch resources: - cronjobs verbs: - create - delete - deletecollection - get - list - patch - update - watch ``` Runtime Fabric creates the required RoleBinding objects which use the ClusterRole rtf:agent to allow corresponding ServiceAccount to perform various actions (verbs) on cron jobs in two namespaces. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service- apiGroup: rbac.authorization.k8s.io ``` ## Configure Authorized Namespaces You configure authorized namespaces when you install Runtime Fabric. Refer to the appropriate installation instructions: - [Installing Runtime Fabric on EKS, AKS, and GKE Using Helm](https://docs.mulesoft.com/runtime-fabric/2.8/install-helm) - [Install Runtime Fabric on Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.8/install-openshift) ## Add New Namespaces If you update the authorized-namespaces ConfigMap with a new namespace, you must restart the Runtime Fabric agent deployment using the following command: `kubectl rollout restart deployment/agent` --- product: Runtime Fabric version: 2.9 --- # Configuring Authorized Namespaces in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Authorized namespaces enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. By limiting permissions in your cluster, you can allow Runtime Fabric to access resources only within namespaces assigned to Runtime Fabric. With authorized namespaces, you have control of the creation of the following Runtime Fabric resources: - Namespaces - RoleBindings - ServiceAccounts ## How Authorized Namespaces Work At install time, you provide a configuration file that consists of your namespaces, ServiceAccounts, ClusterRoles/Roles, and RoleBindings. Runtime Fabric installs the Runtime Fabric agent (rtf-agent) in the Runtime Fabric namespace, and it has access to any additional namespaces that you provide in the authorized namespace list. ### Example The following is an example of a Runtime Fabric agent ClusterRole that allows the agent to control all cron jobs across all namespaces in a cluster. ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rtf:agent rules: - apiGroups: - batch resources: - cronjobs verbs: - create - delete - deletecollection - get - list - patch - update - watch ``` Runtime Fabric creates the required RoleBinding objects which use the ClusterRole rtf:agent to allow corresponding ServiceAccount to perform various actions (verbs) on cron jobs in two namespaces. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` ## Configure Authorized Namespaces You configure authorized namespaces when you install Runtime Fabric. Refer to the appropriate installation instructions: - [Installing Runtime Fabric on EKS, AKS, and GKE Using Helm](https://docs.mulesoft.com/runtime-fabric/2.9/install-helm) - [Install Runtime Fabric on Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.9/install-openshift) ## Add New Namespaces If you update the authorized-namespaces ConfigMap with a new namespace, you must restart the Runtime Fabric agent deployment using the following command: `kubectl rollout restart deployment/agent` --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Authorized Namespaces in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Authorized namespaces enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. By limiting permissions in your cluster, you can allow Runtime Fabric to access resources only within namespaces assigned to Runtime Fabric. With authorized namespaces, you have control of the creation of the following Runtime Fabric resources: - Namespaces - RoleBindings - ServiceAccounts ## How Authorized Namespaces Work At install time, you provide a configuration file that consists of your namespaces, ServiceAccounts, ClusterRoles/Roles, and RoleBindings. Runtime Fabric installs the Runtime Fabric agent (rtf-agent) in the Runtime Fabric namespace, and it has access to any additional namespaces that you provide in the authorized namespace list. ### Example The following is an example of a Runtime Fabric agent ClusterRole that allows the agent to control all cron jobs across all namespaces in a cluster. ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rtf:agent rules: - apiGroups: - batch resources: - cronjobs verbs: - create - delete - deletecollection - get - list - patch - update - watch ``` Runtime Fabric creates the required RoleBinding objects which use the ClusterRole rtf:agent to allow corresponding ServiceAccount to perform various actions (verbs) on cron jobs in two namespaces. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` ## Configure Authorized Namespaces You configure authorized namespaces when you install Runtime Fabric. Refer to the appropriate installation instructions: - [Installing Runtime Fabric on EKS, AKS, GKE, and OKE Using Helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) - [Install Runtime Fabric on Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/latest/install-openshift) ## Add New Namespaces If you update the authorized-namespaces ConfigMap with a new namespace, you must restart the Runtime Fabric agent deployment using the following command: `kubectl rollout restart deployment/agent` --- product: Runtime Fabric version: 2.10 --- # Configuring Horizontal Pod Autoscaling (HPA) for Runtime Fabric Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric instances support horizontal scaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. Mulesoft supports configuring Mule apps to be responsive to the CPU usage on Kubernetes (K8s) runtime side. You can enable CPU based horizontal autoscaling per application on the Runtime Manager application deployment page, which will result in automatic scale up or scale down of the deployment replicas as needed. In Kubernetes, a Horizontal Pod Autoscaler (HPA) automatically updates a workload resource, with the aim of automatically scaling the workload to match demand. Horizontal scaling means that the response to increased load is to deploy more pods. > [!NOTE] HPA is supported only on Runtime Fabric agent version 2.6.22 and higher. This feature applies only to select customers who are opted into the new pricing and packaging model. For more details, see [Anypoint Platform Pricing](https://docs.mulesoft.com/general/pricing) ## Before You Begin To configure autoscaling, the cluster administrator must enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. Refer to your managed vendors documentation on how to install or enable metrics API servers. ## Recommendations for Cluster Autoscaling The following recommendations are for your infrastructure team to configure cluster autoscaling ### Configure Node Groups Configure one node group per availability zone, with a minimum of one node in the node group. This ensures that Kubernetes has information about all the availability zones in the cluster and avoids an issue where zone topology unschedulable pod fails to scale-out topologySpread predicate check. Make sure that nodes from all the node groups have the exact same labels except for the common labels and specific cloud provider labels that are different across nodes or availability zones by default. Custom labels (which are not common labels and specific cloud provider labels) and are different across nodes need to be excluded from cluster autoscaler when evaluating similar node groups. For reference on managed EKS labels such as: eks.amazonaws.com/nodegroup failure-domain.beta.kubernetes.io/region failure-domain.beta.kubernetes.io/zone kubernetes.io/hostname topology.kubernetes.io/region topology.kubernetes.io/zone ### Configure Cluster Autoscaler Flags Start the cluster autoscaler with flag `--balance-similar-node-groups=true` and exclude the custom labels previously mentioned in the node groups section with the flag `--balancing-ignore-label`. These flags ensure that the cluster autoscaler balances the number of nodes across availability zones. For reference on managed EKS cluster, the following node labels are different across node groups: k8s.amazonaws.com/eniConfigCustom vpc.amazonaws.com/eniConfig Therefore, the cluster autoscaler starts with: \- --balancing-ignore-label=k8s.amazonaws.com/eniConfigCustom - --balancing-ignore-label=vpc.amazonaws.com/eniConfig These configuration recommendations serve as a guideline. However, the actual configuration of the cluster autoscaler (CA) depends on the cloud or infrastructure provider (vendor) you use and the relevant topology considerations. You must configure the CA appropriately. ### Configure Overprovisioning Nodes Configure at least one overprovisioning node per availability zone. Each overprovisioning nodes holds a resource that can accommodate three Mule app nodes, which improves the performance when new nodes are needed. > [!NOTE] Refer to your managed vendor documentation for cluster autoscaling best practices and > over-provisioning configuration details. ### Configure Topology Spread Constraints Your Mule app deployments which are enabled with autoscaling, are required to customize the kubernetes resources for the topology spread constraints in pod spec by updating the **whenUnsatisfiable** field with `DoNotSchedule`. This configuration ensures that autoscaling replicas are evenly spread across zones for high availability. topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" rtf.mulesoft.com/generation: "{{ .Values.resourceContentHash }}" Using `whenUnsatisfiable: DoNotSchedule` guarantees that pods are evenly spread across availability zones. To modify this setting, use the K8S templates CRD to adjust your deployments using HPA to `whenUnsatisfiable: DoNotSchedule`. You can also use dedicated namespaces (environments) to separate the autoscaling workloads from the classic ones. If you don’t make this change, you use `whenUnsatisfiable: ScheduleAnyway`. For further details on the configuration, refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.10/customize-kubernetes-crd) documentation. > [!WARNING] Customizing topology spread with `whenUnsatisfiable: DoNotSchedule`, without the > recommended configurations for node groups per availability zone, cluster autoscaler, and > overprovisionining, can lead to K8s failing to schedule the replicas with `Pending state` error. ### Understand CPU-based Autoscaling Policy MuleSoft owns and applies the [autoscaling](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) policy for your Mule application deployments. The following example shows the CPU-based HPA policy used for Mule apps deployed on Runtime Fabric instances. Note that you can choose `minReplicas` and `maxReplicas` values from the Runtime Manager user interface. apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app namespace: app-namespace spec: behavior: scaleDown: policies: - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 1800 scaleUp: policies: - periodSeconds: 180 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 0 maxReplicas: metrics: - resource: name: cpu target: averageUtilization: 70 type: Utilization type: Resource minReplicas: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app Some points to consider: Scale up can occur at most every 180 seconds. Each period, up to 100% of the currently running replicas may be added until the maximum configured replicas is reached. For scaling up there is no stabilization window. When the metrics indicate that the target should be scaled up, the target is scaled up immediately. Scale down can occur at most every 15 seconds. Each Period, up to 100% of the currently running replicas may be removed which means the scaling target can be scaled down to the minimum allowed replicas. The number of replicas removed is based on the aggregated calculations over the past 1800 seconds of the stabilization window. Min replicas - The minimum number of replicas that would be guaranteed to run at any given point of time. - Scale down policy would never remove replicas below this number. Max replicas - The maximum number of replicas that are capped, beyond which no more replicas can be added for scale up. For details, see [limitations-self.adoc#limitations](https://docs.mulesoft.com/runtime-fabric/2.10/limitations-self#limitations). - Scale up policy would never add replicas above this number. Enabling HPA can result in customers incurring additional flow usage when your application scales horizontally. To avoid overages from unpredicted scaling, configure the maximum configured replicas judiciously to stay within purchased flow limits. Track your incurred flow usage through [usage reports](https://docs.mulesoft.com/general/usage-reports). HPA uses CPU utilization at average of 70% HPA bases on [resource requests](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/#how-does-a-horizontalpodautoscaler-work). When target utilization value is set, the controller calculates the utilization value as a percentage of the equivalent resource request on the containers in each pod. If pod average use is greater than 70% in a period (periods for scale-up are set as 180 seconds), HPA scales up. Refer to the Kubernetes documentation for additional details. ## Performance Considerations and Limitations For a successful horizontal autoscaling of your Mule apps, review the following performance considerations: - In Runtime Fabric, the policy in use was benchmarked for Mule apps with CPU Reserved: 0.45vCpu and Limit: 0.55vCpu, which corresponds to these settings: resources: limits: cpu: 550m requests: cpu: 450m - Mule apps that scale based on CPU usage are a good fit with CPU based HPA. For example: - HTTP/HTTPS apps with async requests - Reverse proxies - Low latency + high throughput apps - Dataweave transformations - APIKit Routing - API Gateways with policies - Non-reentrant apps that do not have built in parallel processing such as batch jobs, scheduler apps without re-entrancy and duplicate scheduling across apps and low throughput, high latency apps with large requests may not be a good fit with CPU based HPA. - Scale up and scale down performance can vary based on the replica size and the application type. - The policy is optimized for replica sizes with <850m. Larger replica sizes might take longer to scale. HPA is recommended only for smaller CPU applications with average usage of 0.2vCPU. ### Limitations There are some limitations to consider: - CPU is the only resource for horizontal autoscaling. ## Configure Horizontal Pod Autoscaling To configure horizontal autoscaling for Mule apps deployed to Runtime Fabric, follow these steps: 1. Enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. 2. From Anypoint Platform, select **Runtime Manager** > **Applications**. 3. Click **Deploy application**. 4. In the **Runtime** tab, check the **Enable Autoscaling** box. 5. Set the minimum and maximum **Replica Count** limits. 6. Click **Deploy Application**. ![Runtime Manager UI with Enable Autoscaling field selected](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-autoscaling.png) ## Autoscaling Status and Logs When an autoscaling event occurs and your Mule app with horizontal autoscaling scales up, you can check the **Scaling** status in the Runtime Manager UI by clicking **View status** in your application’s details window: ![Runtime Manager UI with Mule app and Scaling status](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-hpa-rtm.png) You can also track when autoscaling events occurred through **Audit logs** in Access Management. Each time an application deployment scaled, there is an audit log published under the product **Runtime Manager**, by the **Anypoint Staff** user. The log has **Action** set to `Scaling` with the **Object** as the application ID. ![Runtime Manager UI with Audit logs and Scaling status](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-hpa-rtm-2.png) The following is an example log payload: ```console {"properties":{"organizationId":"my-orgID-abc","environmentId":"my-envID-xyz","response":{"message":{"message":"Application id:my-appID-123 scaled DOWN from 3 to 2 replicas.","logLevel":"INFO","context":{"logger":"Runtime Manager"},"timestamp":1700234556678}},"deploymentId":"my-appID-123","initialRequest":"/organizations/my-orgID-abc/environments/my-envID-xyz/deployments/my-appID-123/specs/my-specID-456"},"subaction":"Scaling"} ``` Additionally, you can track the scaled up replicas startup and the number of replicas of your Mule apps by running the following `kubectl` command in your terminal: ```console kubectl get events | grep HorizontalPodAutoscaler ``` Use the `kubectl get events` command in Kubernetes to retrieve events that occurred within the cluster. The command provides information about various activities and changes happening in the cluster, such as pod creations, deletions, and other important events. The `grep` command filters the output of `kubectl get events` for lines that contain the string `HorizontalPodAutoscaler`. The following example shows the command output that includes events related to a `HorizontalPodAutoscaler` with information about successful rescaling operations triggered by the HPA: ```console # kubectl get events | grep HorizontalPodAutoscaler 5m20s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target 5m5s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target 4m50s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 10; reason: ``` --- product: Runtime Fabric version: 2.11 --- # Configuring Horizontal Pod Autoscaling (HPA) for Runtime Fabric Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric instances support horizontal scaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. Mulesoft supports configuring Mule apps to be responsive to the CPU usage on Kubernetes (K8s) runtime side. You can enable CPU based horizontal autoscaling per application on the Runtime Manager application deployment page, which will result in automatic scale up or scale down of the deployment replicas as needed. In Kubernetes, a Horizontal Pod Autoscaler (HPA) automatically updates a workload resource, with the aim of automatically scaling the workload to match demand. Horizontal scaling means that the response to increased load is to deploy more pods. > [!NOTE] HPA is supported only on Runtime Fabric agent version 2.6.22 and higher. This feature applies only to select customers who are opted into the new pricing and packaging model. For more details, see [Anypoint Platform Pricing](https://docs.mulesoft.com/general/pricing) ## Before You Begin To configure autoscaling, the cluster administrator must enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. Refer to your managed vendors documentation on how to install or enable metrics API servers. ## Recommendations for Cluster Autoscaling The following recommendations are for your infrastructure team to configure cluster autoscaling ### Configure Node Groups Configure one node group per availability zone, with a minimum of one node in the node group. This ensures that Kubernetes has information about all the availability zones in the cluster and avoids an issue where zone topology unschedulable pod fails to scale-out topologySpread predicate check. Make sure that nodes from all the node groups have the exact same labels except for the common labels and specific cloud provider labels that are different across nodes or availability zones by default. Custom labels (which are not common labels and specific cloud provider labels) and are different across nodes need to be excluded from cluster autoscaler when evaluating similar node groups. For reference on managed EKS labels such as: eks.amazonaws.com/nodegroup failure-domain.beta.kubernetes.io/region failure-domain.beta.kubernetes.io/zone kubernetes.io/hostname topology.kubernetes.io/region topology.kubernetes.io/zone ### Configure Cluster Autoscaler Flags Start the cluster autoscaler with flag `--balance-similar-node-groups=true` and exclude the custom labels previously mentioned in the node groups section with the flag `--balancing-ignore-label`. These flags ensure that the cluster autoscaler balances the number of nodes across availability zones. For reference on managed EKS cluster, these node labels are different across node groups: k8s.amazonaws.com/eniConfigCustom vpc.amazonaws.com/eniConfig Therefore, the cluster autoscaler starts with: \- --balancing-ignore-label=k8s.amazonaws.com/eniConfigCustom - --balancing-ignore-label=vpc.amazonaws.com/eniConfig These configuration recommendations serve as a guideline. However, the actual configuration of the cluster autoscaler (CA) depends on the cloud or infrastructure provider (vendor) you use and the relevant topology considerations. You must configure the CA appropriately. ### Configure Overprovisioning Nodes Configure at least one overprovisioning node per availability zone. Each overprovisioning nodes holds a resource that can accommodate three Mule app nodes, which improves the performance when new nodes are needed. > [!NOTE] Refer to your managed vendor documentation for cluster autoscaling best practices and > over-provisioning configuration details. ### Configure Topology Spread Constraints Your Mule app deployments which are enabled with autoscaling, are required to customize the kubernetes resources for the topology spread constraints in pod spec by updating the **whenUnsatisfiable** field with `DoNotSchedule`. This configuration ensures that autoscaling replicas are evenly spread across zones for high availability. topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" rtf.mulesoft.com/generation: "{{ .Values.resourceContentHash }}" Using `whenUnsatisfiable: DoNotSchedule` guarantees that pods are evenly spread across availability zones. To modify this setting, use the K8S templates CRD to adjust your deployments using HPA to `whenUnsatisfiable: DoNotSchedule`. You can also use dedicated namespaces (environments) to separate the autoscaling workloads from the classic ones. If you don’t make this change, you use `whenUnsatisfiable: ScheduleAnyway`. For further details on the configuration, refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.11/customize-kubernetes-crd) documentation. > [!WARNING] Customizing topology spread with `whenUnsatisfiable: DoNotSchedule`, without the > recommended configurations for node groups per availability zone, cluster autoscaler, and > overprovisionining, can lead to K8s failing to schedule the replicas with `Pending state` error. ### Understand CPU-based Autoscaling Policy MuleSoft owns and applies the [autoscaling](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) policy for your Mule application deployments. The following example shows the CPU-based HPA policy used for Mule apps deployed on Runtime Fabric instances. Note that you can choose `minReplicas` and `maxReplicas` values from the Runtime Manager user interface. apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app namespace: app-namespace spec: behavior: scaleDown: policies: - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 1800 scaleUp: policies: - periodSeconds: 180 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 0 maxReplicas: metrics: - resource: name: cpu target: averageUtilization: 70 type: Utilization type: Resource minReplicas: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app Some points to consider: Scale up can occur at most every 180 seconds. Each period, up to 100% of the currently running replicas may be added until the maximum configured replicas is reached. For scaling up there is no stabilization window. When the metrics indicate that the target should be scaled up, the target is scaled up immediately. Scale down can occur at most every 15 seconds. Each Period, up to 100% of the currently running replicas may be removed which means the scaling target can be scaled down to the minimum allowed replicas. The number of replicas removed is based on the aggregated calculations over the past 1800 seconds of the stabilization window. Min replicas - The minimum number of replicas that would be guaranteed to run at any given point of time. - Scale down policy would never remove replicas below this number. Max replicas - The maximum number of replicas that are capped, beyond which no more replicas can be added for scale up. For details, see [limitations-self.adoc#limitations](https://docs.mulesoft.com/runtime-fabric/2.11/limitations-self#limitations). - Scale up policy would never add replicas above this number. Enabling HPA can result in customers incurring additional flow usage when your application scales horizontally. To avoid overages from unpredicted scaling, configure the maximum configured replicas judiciously to stay within purchased flow limits. Track your incurred flow usage through [usage reports](https://docs.mulesoft.com/general/usage-reports). HPA uses CPU utilization at average of 70% HPA bases on [resource requests](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/#how-does-a-horizontalpodautoscaler-work). When target utilization value is set, the controller calculates the utilization value as a percentage of the equivalent resource request on the containers in each pod. If pod average use is greater than 70% in a period (periods for scale-up are set as 180 seconds), HPA scales up. Refer to the Kubernetes documentation for additional details. ## Performance Considerations and Limitations For a successful horizontal autoscaling of your Mule apps, review these performance considerations: - In Runtime Fabric, the policy in use was benchmarked for Mule apps with CPU Reserved: 0.45vCpu and Limit: 0.55vCpu, which corresponds to these settings: resources: limits: cpu: 550m requests: cpu: 450m - Mule apps that scale based on CPU usage are a good fit with CPU based HPA. For example: - HTTP/HTTPS apps with async requests - Reverse proxies - Low latency + high throughput apps - Dataweave transformations - APIKit Routing - API Gateways with policies - Non-reentrant apps that do not have built in parallel processing such as batch jobs, scheduler apps without re-entrancy and duplicate scheduling across apps and low throughput, high latency apps with large requests may not be a good fit with CPU based HPA. - Scale up and scale down performance can vary based on the replica size and the application type. - The policy is optimized for replica sizes with <850m. Larger replica sizes might take longer to scale. HPA is recommended only for smaller CPU applications with average usage of 0.2vCPU. ### Limitations There are some limitations to consider: - CPU is the only resource for horizontal autoscaling. ## Configure Horizontal Pod Autoscaling To configure horizontal autoscaling for Mule apps deployed to Runtime Fabric, follow these steps: 1. Enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. 2. From Anypoint Platform, select **Runtime Manager** > **Applications**. 3. Click **Deploy application**. 4. In the **Runtime** tab, check the **Enable Autoscaling** box. 5. Set the minimum and maximum **Replica Count** limits. 6. Click **Deploy Application**. ![Runtime Manager UI with Enable Autoscaling field selected](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-autoscaling.png) ## Autoscaling Status and Logs When an autoscaling event occurs and your Mule app with horizontal autoscaling scales up, you can check the **Scaling** status in the Runtime Manager UI by clicking **View status** in your application’s details window: ![Runtime Manager UI with Mule app and Scaling status](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-hpa-rtm.png) You can also track when autoscaling events occurred through **Audit logs** in Access Management. Each time an application deployment scaled, there is an audit log published under the product **Runtime Manager**, by the **Anypoint Staff** user. The log has **Action** set to `Scaling` with the **Object** as the application ID. ![Runtime Manager UI with Audit logs and Scaling status](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-hpa-rtm-2.png) The following is an example log payload: ```console {"properties":{"organizationId":"my-orgID-abc","environmentId":"my-envID-xyz","response":{"message":{"message":"Application id:my-appID-123 scaled DOWN from 3 to 2 replicas.","logLevel":"INFO","context":{"logger":"Runtime Manager"},"timestamp":1700234556678}},"deploymentId":"my-appID-123","initialRequest":"/organizations/my-orgID-abc/environments/my-envID-xyz/deployments/my-appID-123/specs/my-specID-456"},"subaction":"Scaling"} ``` Additionally, you can track the scaled up replicas startup and the number of replicas of your Mule apps by running this `kubectl` command in your terminal: ```console kubectl get events | grep HorizontalPodAutoscaler ``` Use the `kubectl get events` command in Kubernetes to retrieve events that occurred within the cluster. The command provides information about various activities and changes happening in the cluster, such as pod creations, deletions, and other important events. The `grep` command filters the output of `kubectl get events` for lines that contain the string `HorizontalPodAutoscaler`. The following example shows the command output that includes events related to a `HorizontalPodAutoscaler` with information about successful rescaling operations triggered by the HPA: ```console # kubectl get events | grep HorizontalPodAutoscaler 5m20s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target 5m5s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target 4m50s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 10; reason: ``` --- product: Runtime Fabric version: 2.6 --- # Configuring Horizontal Pod Autoscaling (HPA) for Runtime Fabric Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric instances support horizontal scaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. Mulesoft supports configuring Mule apps to be responsive to the CPU usage on Kubernetes (K8s) runtime side. You can enable CPU based horizontal autoscaling per application on the Runtime Manager application deployment page, which will result in automatic scale up or scale down of the deployment replicas as needed. In Kubernetes, a Horizontal Pod Autoscaler (HPA) automatically updates a workload resource, with the aim of automatically scaling the workload to match demand. Horizontal scaling means that the response to increased load is to deploy more pods. > [!NOTE] HPA is supported only on Runtime Fabric agent version 2.6.22 and higher. This feature applies only to select customers who are opted into the new pricing and packaging model. For more details, see [Anypoint Platform Pricing](https://docs.mulesoft.com/general/pricing) ## Before You Begin To configure autoscaling, the cluster administrator must enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. Refer to your managed vendors documentation on how to install or enable metrics API servers. ## Recommendations for Cluster Autoscaling The following recommendations are for your infrastructure team to configure cluster autoscaling ### Configure Node Groups Configure one node group per availability zone, with a minimum of one node in the node group. This ensures that Kubernetes has information about all the availability zones in the cluster and avoids an issue where zone topology unschedulable pod fails to scale-out topologySpread predicate check. Make sure that nodes from all the node groups have the exact same labels except for the common labels and specific cloud provider labels that are different across nodes or availability zones by default. Custom labels (which are not common labels and specific cloud provider labels) and are different across nodes need to be excluded from cluster autoscaler when evaluating similar node groups. For reference on managed EKS labels such as: eks.amazonaws.com/nodegroup failure-domain.beta.kubernetes.io/region failure-domain.beta.kubernetes.io/zone kubernetes.io/hostname topology.kubernetes.io/region topology.kubernetes.io/zone ### Configure Cluster Autoscaler Flags Start the cluster autoscaler with flag `--balance-similar-node-groups=true` and exclude the custom labels previously mentioned in the node groups section with the flag `--balancing-ignore-label`. These flags ensure that the cluster autoscaler balances the number of nodes across availability zones. For reference on managed EKS cluster, the following node labels are different across node groups: k8s.amazonaws.com/eniConfigCustom vpc.amazonaws.com/eniConfig Therefore, the cluster autoscaler starts with: \- --balancing-ignore-label=k8s.amazonaws.com/eniConfigCustom - --balancing-ignore-label=vpc.amazonaws.com/eniConfig These configuration recommendations serve as a guideline. However, the actual configuration of the cluster autoscaler (CA) depends on the cloud or infrastructure provider (vendor) you use and the relevant topology considerations. You must configure the CA appropriately. ### Configure Overprovisioning Nodes Configure at least one overprovisioning node per availability zone. Each overprovisioning nodes holds a resource that can accommodate three Mule app nodes, which improves the performance when new nodes are needed. > [!NOTE] Refer to your managed vendor documentation for cluster autoscaling best practices and > over-provisioning configuration details. ### Configure Topology Spread Constraints Your Mule app deployments which are enabled with autoscaling, are required to customize the kubernetes resources for the topology spread constraints in pod spec by updating the **whenUnsatisfiable** field with `DoNotSchedule`. This configuration ensures that autoscaling replicas are evenly spread across zones for high availability. topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" Using `whenUnsatisfiable: DoNotSchedule` guarantees that pods are evenly spread across availability zones. To modify this setting, use the K8S templates CRD to adjust your deployments using HPA to `whenUnsatisfiable: DoNotSchedule`. You can also use dedicated namespaces (environments) to separate the autoscaling workloads from the classic ones. If you don’t make this change, you use `whenUnsatisfiable: ScheduleAnyway`. For further details on the configuration, refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.6/customize-kubernetes-crd) documentation. > [!WARNING] Customizing topology spread with `whenUnsatisfiable: DoNotSchedule`, without the > recommended configurations for node groups per availability zone, cluster autoscaler, and > overprovisionining, can lead to K8s failing to schedule the replicas with `Pending state` error. ### Understand CPU-based Autoscaling Policy MuleSoft owns and applies the [autoscaling](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) policy for your Mule application deployments. The following example shows the CPU-based HPA policy used for Mule apps deployed on Runtime Fabric instances. Note that you can choose `minReplicas` and `maxReplicas` values from the Runtime Manager user interface. apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app namespace: app-namespace spec: behavior: scaleDown: policies: - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 1800 scaleUp: policies: - periodSeconds: 180 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 0 maxReplicas: metrics: - resource: name: cpu target: averageUtilization: 70 type: Utilization type: Resource minReplicas: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app Some points to consider: Scale up can occur at most every 180 seconds. Each period, up to 100% of the currently running replicas may be added until the maximum configured replicas is reached. For scaling up there is no stabilization window. When the metrics indicate that the target should be scaled up, the target is scaled up immediately. Scale down can occur at most every 15 seconds. Each Period, up to 100% of the currently running replicas may be removed which means the scaling target can be scaled down to the minimum allowed replicas. The number of replicas removed is based on the aggregated calculations over the past 1800 seconds of the stabilization window. Min replicas - The minimum number of replicas that would be guaranteed to run at any given point of time. - Scale down policy would never remove replicas below this number. Max replicas - The maximum number of replicas that are capped, beyond which no more replicas can be added for scale up. - Scale up policy would never add replicas above this number. Enabling HPA can result in customers incurring additional flow usage when your application scales horizontally. To avoid overages from unpredicted scaling, configure the maximum configured replicas judiciously to stay within purchased flow limits. Track your incurred flow usage through [usage reports](https://docs.mulesoft.com/general/usage-reports). HPA uses CPU utilization at average of 70% HPA bases on [resource requests](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/#how-does-a-horizontalpodautoscaler-work). When target utilization value is set, the controller calculates the utilization value as a percentage of the equivalent resource request on the containers in each pod. If pod average use is greater than 70% in a period (periods for scale-up are set as 180 seconds), HPA scales up. Refer to the Kubernetes documentation for additional details. ## Performance Considerations and Limitations For a successful horizontal autoscaling of your Mule apps, review the following performance considerations: - In Runtime Fabric, the policy in use was benchmarked for Mule apps with CPU Reserved: 0.45vCpu and Limit: 0.55vCpu, which corresponds to these settings: resources: limits: cpu: 550m requests: cpu: 450m - Mule apps that scale based on CPU usage are a good fit with CPU based HPA. For example: - HTTP/HTTPS apps with async requests - Reverse proxies - Low latency + high throughput apps - Dataweave transformations - APIKit Routing - API Gateways with policies - Non-reentrant apps that do not have built in parallel processing such as batch jobs, scheduler apps without re-entrancy and duplicate scheduling across apps and low throughput, high latency apps with large requests may not be a good fit with CPU based HPA. - Scale up and scale down performance can vary based on the replica size and the application type. - The policy is optimized for replica sizes with <850m. Larger replica sizes might take longer to scale. HPA is recommended only for smaller CPU applications with average usage of 0.2vCPU. ### Limitations There are some limitations to consider: - CPU is the only resource for horizontal autoscaling. ## Configure Horizontal Pod Autoscaling To configure horizontal autoscaling for Mule apps deployed to Runtime Fabric, follow these steps: 1. Enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. 2. From Anypoint Platform, select **Runtime Manager** > **Applications**. 3. Click **Deploy application**. 4. In the **Runtime** tab, check the **Enable Autoscaling** box. 5. Set the minimum and maximum **Replica Count** limits. 6. Click **Deploy Application**. ![Runtime Manager UI with Enable Autoscaling field selected](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-autoscaling.png) ## Autoscaling Status and Logs When an autoscaling event occurs and your Mule app with horizontal autoscaling scales up, you can check the **Scaling** status in the Runtime Manager UI by clicking **View status** in your application’s details window: ![Runtime Manager UI with Mule app and Scaling status](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-hpa-rtm.png) You can also track when autoscaling events occurred through **Audit logs** in Access Management. Each time an application deployment scaled, there is an audit log published under the product **Runtime Manager**, by the **Anypoint Staff** user. The log has **Action** set to `Scaling` with the **Object** as the application ID. ![Runtime Manager UI with Audit logs and Scaling status](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-hpa-rtm-2.png) The following is an example log payload: ```console {"properties":{"organizationId":"my-orgID-abc","environmentId":"my-envID-xyz","response":{"message":{"message":"Application id:my-appID-123 scaled DOWN from 3 to 2 replicas.","logLevel":"INFO","context":{"logger":"Runtime Manager"},"timestamp":1700234556678}},"deploymentId":"my-appID-123","initialRequest":"/organizations/my-orgID-abc/environments/my-envID-xyz/deployments/my-appID-123/specs/my-specID-456"},"subaction":"Scaling"} ``` Additionally, you can track the scaled up replicas startup and the number of replicas of your Mule apps by running the following `kubectl` command in your terminal: ```console kubectl get events | grep HorizontalPodAutoscaler ``` Use the `kubectl get events` command in Kubernetes to retrieve events that occurred within the cluster. The command provides information about various activities and changes happening in the cluster, such as pod creations, deletions, and other important events. The `grep` command filters the output of `kubectl get events` for lines that contain the string `HorizontalPodAutoscaler`. The following example shows the command output that includes events related to a `HorizontalPodAutoscaler` with information about successful rescaling operations triggered by the HPA: ```console # kubectl get events | grep HorizontalPodAutoscaler 5m20s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target 5m5s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target 4m50s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 10; reason: ``` --- product: Runtime Fabric version: 2.7 --- # Configuring Horizontal Pod Autoscaling (HPA) for Runtime Fabric Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric instances support horizontal scaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. Mulesoft supports configuring Mule apps to be responsive to the CPU usage on Kubernetes (K8s) runtime side. You can enable CPU based horizontal autoscaling per application on the Runtime Manager application deployment page, which will result in automatic scale up or scale down of the deployment replicas as needed. In Kubernetes, a Horizontal Pod Autoscaler (HPA) automatically updates a workload resource, with the aim of automatically scaling the workload to match demand. Horizontal scaling means that the response to increased load is to deploy more pods. > [!NOTE] HPA is supported only on Runtime Fabric agent version 2.6.22 and higher. This feature applies only to select customers who are opted into the new pricing and packaging model. For more details, see [Anypoint Platform Pricing](https://docs.mulesoft.com/general/pricing) ## Before You Begin To configure autoscaling, the cluster administrator must enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. Refer to your managed vendors documentation on how to install or enable metrics API servers. ## Recommendations for Cluster Autoscaling The following recommendations are for your infrastructure team to configure cluster autoscaling ### Configure Node Groups Configure one node group per availability zone, with a minimum of one node in the node group. This ensures that Kubernetes has information about all the availability zones in the cluster and avoids an issue where zone topology unschedulable pod fails to scale-out topologySpread predicate check. Make sure that nodes from all the node groups have the exact same labels except for the common labels and specific cloud provider labels that are different across nodes or availability zones by default. Custom labels (which are not common labels and specific cloud provider labels) and are different across nodes need to be excluded from cluster autoscaler when evaluating similar node groups. For reference on managed EKS labels such as: eks.amazonaws.com/nodegroup failure-domain.beta.kubernetes.io/region failure-domain.beta.kubernetes.io/zone kubernetes.io/hostname topology.kubernetes.io/region topology.kubernetes.io/zone ### Configure Cluster Autoscaler Flags Start the cluster autoscaler with flag `--balance-similar-node-groups=true` and exclude the custom labels previously mentioned in the node groups section with the flag `--balancing-ignore-label`. These flags ensure that the cluster autoscaler balances the number of nodes across availability zones. For reference on managed EKS cluster, the following node labels are different across node groups: k8s.amazonaws.com/eniConfigCustom vpc.amazonaws.com/eniConfig Therefore, the cluster autoscaler starts with: \- --balancing-ignore-label=k8s.amazonaws.com/eniConfigCustom - --balancing-ignore-label=vpc.amazonaws.com/eniConfig These configuration recommendations serve as a guideline. However, the actual configuration of the cluster autoscaler (CA) depends on the cloud or infrastructure provider (vendor) you use and the relevant topology considerations. You must configure the CA appropriately. ### Configure Overprovisioning Nodes Configure at least one overprovisioning node per availability zone. Each overprovisioning nodes holds a resource that can accommodate three Mule app nodes, which improves the performance when new nodes are needed. > [!NOTE] Refer to your managed vendor documentation for cluster autoscaling best practices and > over-provisioning configuration details. ### Configure Topology Spread Constraints Your Mule app deployments which are enabled with autoscaling, are required to customize the kubernetes resources for the topology spread constraints in pod spec by updating the **whenUnsatisfiable** field with `DoNotSchedule`. This configuration ensures that autoscaling replicas are evenly spread across zones for high availability. topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" Using `whenUnsatisfiable: DoNotSchedule` guarantees that pods are evenly spread across availability zones. To modify this setting, use the K8S templates CRD to adjust your deployments using HPA to `whenUnsatisfiable: DoNotSchedule`. You can also use dedicated namespaces (environments) to separate the autoscaling workloads from the classic ones. If you don’t make this change, you use `whenUnsatisfiable: ScheduleAnyway`. For further details on the configuration, refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.7/customize-kubernetes-crd) documentation. > [!WARNING] Customizing topology spread with `whenUnsatisfiable: DoNotSchedule`, without the > recommended configurations for node groups per availability zone, cluster autoscaler, and > overprovisionining, can lead to K8s failing to schedule the replicas with `Pending state` error. ### Understand CPU-based Autoscaling Policy MuleSoft owns and applies the [autoscaling](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) policy for your Mule application deployments. The following example shows the CPU-based HPA policy used for Mule apps deployed on Runtime Fabric instances. Note that you can choose `minReplicas` and `maxReplicas` values from the Runtime Manager user interface. apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app namespace: app-namespace spec: behavior: scaleDown: policies: - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 1800 scaleUp: policies: - periodSeconds: 180 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 0 maxReplicas: metrics: - resource: name: cpu target: averageUtilization: 70 type: Utilization type: Resource minReplicas: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app Some points to consider: Scale up can occur at most every 180 seconds. Each period, up to 100% of the currently running replicas may be added until the maximum configured replicas is reached. For scaling up there is no stabilization window. When the metrics indicate that the target should be scaled up, the target is scaled up immediately. Scale down can occur at most every 15 seconds. Each Period, up to 100% of the currently running replicas may be removed which means the scaling target can be scaled down to the minimum allowed replicas. The number of replicas removed is based on the aggregated calculations over the past 1800 seconds of the stabilization window. Min replicas - The minimum number of replicas that would be guaranteed to run at any given point of time. - Scale down policy would never remove replicas below this number. Max replicas - The maximum number of replicas that are capped, beyond which no more replicas can be added for scale up. - Scale up policy would never add replicas above this number. Enabling HPA can result in customers incurring additional flow usage when your application scales horizontally. To avoid overages from unpredicted scaling, configure the maximum configured replicas judiciously to stay within purchased flow limits. Track your incurred flow usage through [usage reports](https://docs.mulesoft.com/general/usage-reports). HPA uses CPU utilization at average of 70% HPA bases on [resource requests](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/#how-does-a-horizontalpodautoscaler-work). When target utilization value is set, the controller calculates the utilization value as a percentage of the equivalent resource request on the containers in each pod. If pod average use is greater than 70% in a period (periods for scale-up are set as 180 seconds), HPA scales up. Refer to the Kubernetes documentation for additional details. ## Performance Considerations and Limitations For a successful horizontal autoscaling of your Mule apps, review the following performance considerations: - In Runtime Fabric, the policy in use was benchmarked for Mule apps with CPU Reserved: 0.45vCpu and Limit: 0.55vCpu, which corresponds to these settings: resources: limits: cpu: 550m requests: cpu: 450m - Mule apps that scale based on CPU usage are a good fit with CPU based HPA. For example: - HTTP/HTTPS apps with async requests - Reverse proxies - Low latency + high throughput apps - Dataweave transformations - APIKit Routing - API Gateways with policies - Non-reentrant apps that do not have built in parallel processing such as batch jobs, scheduler apps without re-entrancy and duplicate scheduling across apps and low throughput, high latency apps with large requests may not be a good fit with CPU based HPA. - Scale up and scale down performance can vary based on the replica size and the application type. - The policy is optimized for replica sizes with <850m. Larger replica sizes might take longer to scale. HPA is recommended only for smaller CPU applications with average usage of 0.2vCPU. ### Limitations There are some limitations to consider: - CPU is the only resource for horizontal autoscaling. ## Configure Horizontal Pod Autoscaling To configure horizontal autoscaling for Mule apps deployed to Runtime Fabric, follow these steps: 1. Enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. 2. From Anypoint Platform, select **Runtime Manager** > **Applications**. 3. Click **Deploy application**. 4. In the **Runtime** tab, check the **Enable Autoscaling** box. 5. Set the minimum and maximum **Replica Count** limits. 6. Click **Deploy Application**. ![Runtime Manager UI with Enable Autoscaling field selected](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-autoscaling.png) ## Autoscaling Status and Logs When an autoscaling event occurs and your Mule app with horizontal autoscaling scales up, you can check the **Scaling** status in the Runtime Manager UI by clicking **View status** in your application’s details window: ![Runtime Manager UI with Mule app and Scaling status](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-hpa-rtm.png) You can also track when autoscaling events occurred through **Audit logs** in Access Management. Each time an application deployment scaled, there is an audit log published under the product **Runtime Manager**, by the **Anypoint Staff** user. The log has **Action** set to `Scaling` with the **Object** as the application ID. ![Runtime Manager UI with Audit logs and Scaling status](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-hpa-rtm-2.png) The following is an example log payload: ```console {"properties":{"organizationId":"my-orgID-abc","environmentId":"my-envID-xyz","response":{"message":{"message":"Application id:my-appID-123 scaled DOWN from 3 to 2 replicas.","logLevel":"INFO","context":{"logger":"Runtime Manager"},"timestamp":1700234556678}},"deploymentId":"my-appID-123","initialRequest":"/organizations/my-orgID-abc/environments/my-envID-xyz/deployments/my-appID-123/specs/my-specID-456"},"subaction":"Scaling"} ``` Additionally, you can track the scaled up replicas startup and the number of replicas of your Mule apps by running the following `kubectl` command in your terminal: ```console kubectl get events | grep HorizontalPodAutoscaler ``` Use the `kubectl get events` command in Kubernetes to retrieve events that occurred within the cluster. The command provides information about various activities and changes happening in the cluster, such as pod creations, deletions, and other important events. The `grep` command filters the output of `kubectl get events` for lines that contain the string `HorizontalPodAutoscaler`. The following example shows the command output that includes events related to a `HorizontalPodAutoscaler` with information about successful rescaling operations triggered by the HPA: ```console # kubectl get events | grep HorizontalPodAutoscaler 5m20s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target 5m5s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target 4m50s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 10; reason: ``` --- product: Runtime Fabric version: 2.8 --- # Configuring Horizontal Pod Autoscaling (HPA) for Runtime Fabric Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric instances support horizontal scaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. Mulesoft supports configuring Mule apps to be responsive to the CPU usage on Kubernetes (K8s) runtime side. You can enable CPU based horizontal autoscaling per application on the Runtime Manager application deployment page, which will result in automatic scale up or scale down of the deployment replicas as needed. In Kubernetes, a Horizontal Pod Autoscaler (HPA) automatically updates a workload resource, with the aim of automatically scaling the workload to match demand. Horizontal scaling means that the response to increased load is to deploy more pods. > [!NOTE] HPA is supported only on Runtime Fabric agent version 2.6.22 and higher. This feature applies only to select customers who are opted into the new pricing and packaging model. For more details, see [Anypoint Platform Pricing](https://docs.mulesoft.com/general/pricing) ## Before You Begin To configure autoscaling, the cluster administrator must enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. Refer to your managed vendors documentation on how to install or enable metrics API servers. ## Recommendations for Cluster Autoscaling The following recommendations are for your infrastructure team to configure cluster autoscaling ### Configure Node Groups Configure one node group per availability zone, with a minimum of one node in the node group. This ensures that Kubernetes has information about all the availability zones in the cluster and avoids an issue where zone topology unschedulable pod fails to scale-out topologySpread predicate check. Make sure that nodes from all the node groups have the exact same labels except for the common labels and specific cloud provider labels that are different across nodes or availability zones by default. Custom labels (which are not common labels and specific cloud provider labels) and are different across nodes need to be excluded from cluster autoscaler when evaluating similar node groups. For reference on managed EKS labels such as: eks.amazonaws.com/nodegroup failure-domain.beta.kubernetes.io/region failure-domain.beta.kubernetes.io/zone kubernetes.io/hostname topology.kubernetes.io/region topology.kubernetes.io/zone ### Configure Cluster Autoscaler Flags Start the cluster autoscaler with flag `--balance-similar-node-groups=true` and exclude the custom labels previously mentioned in the node groups section with the flag `--balancing-ignore-label`. These flags ensure that the cluster autoscaler balances the number of nodes across availability zones. For reference on managed EKS cluster, the following node labels are different across node groups: k8s.amazonaws.com/eniConfigCustom vpc.amazonaws.com/eniConfig Therefore, the cluster autoscaler starts with: \- --balancing-ignore-label=k8s.amazonaws.com/eniConfigCustom - --balancing-ignore-label=vpc.amazonaws.com/eniConfig These configuration recommendations serve as a guideline. However, the actual configuration of the cluster autoscaler (CA) depends on the cloud or infrastructure provider (vendor) you use and the relevant topology considerations. You must configure the CA appropriately. ### Configure Overprovisioning Nodes Configure at least one overprovisioning node per availability zone. Each overprovisioning nodes holds a resource that can accommodate three Mule app nodes, which improves the performance when new nodes are needed. > [!NOTE] Refer to your managed vendor documentation for cluster autoscaling best practices and > over-provisioning configuration details. ### Configure Topology Spread Constraints Your Mule app deployments which are enabled with autoscaling, are required to customize the kubernetes resources for the topology spread constraints in pod spec by updating the **whenUnsatisfiable** field with `DoNotSchedule`. This configuration ensures that autoscaling replicas are evenly spread across zones for high availability. topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" Using `whenUnsatisfiable: DoNotSchedule` guarantees that pods are evenly spread across availability zones. To modify this setting, use the K8S templates CRD to adjust your deployments using HPA to `whenUnsatisfiable: DoNotSchedule`. You can also use dedicated namespaces (environments) to separate the autoscaling workloads from the classic ones. If you don’t make this change, you use `whenUnsatisfiable: ScheduleAnyway`. For further details on the configuration, refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.8/customize-kubernetes-crd) documentation. > [!WARNING] Customizing topology spread with `whenUnsatisfiable: DoNotSchedule`, without the > recommended configurations for node groups per availability zone, cluster autoscaler, and > overprovisionining, can lead to K8s failing to schedule the replicas with `Pending state` error. ### Understand CPU-based Autoscaling Policy MuleSoft owns and applies the [autoscaling](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) policy for your Mule application deployments. The following example shows the CPU-based HPA policy used for Mule apps deployed on Runtime Fabric instances. Note that you can choose `minReplicas` and `maxReplicas` values from the Runtime Manager user interface. apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app namespace: app-namespace spec: behavior: scaleDown: policies: - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 1800 scaleUp: policies: - periodSeconds: 180 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 0 maxReplicas: metrics: - resource: name: cpu target: averageUtilization: 70 type: Utilization type: Resource minReplicas: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app Some points to consider: Scale up can occur at most every 180 seconds. Each period, up to 100% of the currently running replicas may be added until the maximum configured replicas is reached. For scaling up there is no stabilization window. When the metrics indicate that the target should be scaled up, the target is scaled up immediately. Scale down can occur at most every 15 seconds. Each Period, up to 100% of the currently running replicas may be removed which means the scaling target can be scaled down to the minimum allowed replicas. The number of replicas removed is based on the aggregated calculations over the past 1800 seconds of the stabilization window. Min replicas - The minimum number of replicas that would be guaranteed to run at any given point of time. - Scale down policy would never remove replicas below this number. Max replicas - The maximum number of replicas that are capped, beyond which no more replicas can be added for scale up. For details, see [limitations-self.adoc#limitations](https://docs.mulesoft.com/runtime-fabric/2.8/limitations-self#limitations). - Scale up policy would never add replicas above this number. Enabling HPA can result in customers incurring additional flow usage when your application scales horizontally. To avoid overages from unpredicted scaling, configure the maximum configured replicas judiciously to stay within purchased flow limits. Track your incurred flow usage through [usage reports](https://docs.mulesoft.com/general/usage-reports). HPA uses CPU utilization at average of 70% HPA bases on [resource requests](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/#how-does-a-horizontalpodautoscaler-work). When target utilization value is set, the controller calculates the utilization value as a percentage of the equivalent resource request on the containers in each pod. If pod average use is greater than 70% in a period (periods for scale-up are set as 180 seconds), HPA scales up. Refer to the Kubernetes documentation for additional details. ## Performance Considerations and Limitations For a successful horizontal autoscaling of your Mule apps, review the following performance considerations: - In Runtime Fabric, the policy in use was benchmarked for Mule apps with CPU Reserved: 0.45vCpu and Limit: 0.55vCpu, which corresponds to these settings: resources: limits: cpu: 550m requests: cpu: 450m - Mule apps that scale based on CPU usage are a good fit with CPU based HPA. For example: - HTTP/HTTPS apps with async requests - Reverse proxies - Low latency + high throughput apps - Dataweave transformations - APIKit Routing - API Gateways with policies - Non-reentrant apps that do not have built in parallel processing such as batch jobs, scheduler apps without re-entrancy and duplicate scheduling across apps and low throughput, high latency apps with large requests may not be a good fit with CPU based HPA. - Scale up and scale down performance can vary based on the replica size and the application type. - The policy is optimized for replica sizes with <850m. Larger replica sizes might take longer to scale. HPA is recommended only for smaller CPU applications with average usage of 0.2vCPU. ### Limitations There are some limitations to consider: - CPU is the only resource for horizontal autoscaling. ## Configure Horizontal Pod Autoscaling To configure horizontal autoscaling for Mule apps deployed to Runtime Fabric, follow these steps: 1. Enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. 2. From Anypoint Platform, select **Runtime Manager** > **Applications**. 3. Click **Deploy application**. 4. In the **Runtime** tab, check the **Enable Autoscaling** box. 5. Set the minimum and maximum **Replica Count** limits. 6. Click **Deploy Application**. ![Runtime Manager UI with Enable Autoscaling field selected](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-autoscaling.png) ## Autoscaling Status and Logs When an autoscaling event occurs and your Mule app with horizontal autoscaling scales up, you can check the **Scaling** status in the Runtime Manager UI by clicking **View status** in your application’s details window: ![Runtime Manager UI with Mule app and Scaling status](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-hpa-rtm.png) You can also track when autoscaling events occurred through **Audit logs** in Access Management. Each time an application deployment scaled, there is an audit log published under the product **Runtime Manager**, by the **Anypoint Staff** user. The log has **Action** set to `Scaling` with the **Object** as the application ID. ![Runtime Manager UI with Audit logs and Scaling status](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-hpa-rtm-2.png) The following is an example log payload: ```console {"properties":{"organizationId":"my-orgID-abc","environmentId":"my-envID-xyz","response":{"message":{"message":"Application id:my-appID-123 scaled DOWN from 3 to 2 replicas.","logLevel":"INFO","context":{"logger":"Runtime Manager"},"timestamp":1700234556678}},"deploymentId":"my-appID-123","initialRequest":"/organizations/my-orgID-abc/environments/my-envID-xyz/deployments/my-appID-123/specs/my-specID-456"},"subaction":"Scaling"} ``` Additionally, you can track the scaled up replicas startup and the number of replicas of your Mule apps by running the following `kubectl` command in your terminal: ```console kubectl get events | grep HorizontalPodAutoscaler ``` Use the `kubectl get events` command in Kubernetes to retrieve events that occurred within the cluster. The command provides information about various activities and changes happening in the cluster, such as pod creations, deletions, and other important events. The `grep` command filters the output of `kubectl get events` for lines that contain the string `HorizontalPodAutoscaler`. The following example shows the command output that includes events related to a `HorizontalPodAutoscaler` with information about successful rescaling operations triggered by the HPA: ```console # kubectl get events | grep HorizontalPodAutoscaler 5m20s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target 5m5s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target 4m50s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 10; reason: ``` --- product: Runtime Fabric version: 2.9 --- # Configuring Horizontal Pod Autoscaling (HPA) for Runtime Fabric Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric instances support horizontal scaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. Mulesoft supports configuring Mule apps to be responsive to the CPU usage on Kubernetes (K8s) runtime side. You can enable CPU based horizontal autoscaling per application on the Runtime Manager application deployment page, which will result in automatic scale up or scale down of the deployment replicas as needed. In Kubernetes, a Horizontal Pod Autoscaler (HPA) automatically updates a workload resource, with the aim of automatically scaling the workload to match demand. Horizontal scaling means that the response to increased load is to deploy more pods. > [!NOTE] HPA is supported only on Runtime Fabric agent version 2.6.22 and higher. This feature applies only to select customers who are opted into the new pricing and packaging model. For more details, see [Anypoint Platform Pricing](https://docs.mulesoft.com/general/pricing) ## Before You Begin To configure autoscaling, the cluster administrator must enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. Refer to your managed vendors documentation on how to install or enable metrics API servers. ## Recommendations for Cluster Autoscaling The following recommendations are for your infrastructure team to configure cluster autoscaling ### Configure Node Groups Configure one node group per availability zone, with a minimum of one node in the node group. This ensures that Kubernetes has information about all the availability zones in the cluster and avoids an issue where zone topology unschedulable pod fails to scale-out topologySpread predicate check. Make sure that nodes from all the node groups have the exact same labels except for the common labels and specific cloud provider labels that are different across nodes or availability zones by default. Custom labels (which are not common labels and specific cloud provider labels) and are different across nodes need to be excluded from cluster autoscaler when evaluating similar node groups. For reference on managed EKS labels such as: eks.amazonaws.com/nodegroup failure-domain.beta.kubernetes.io/region failure-domain.beta.kubernetes.io/zone kubernetes.io/hostname topology.kubernetes.io/region topology.kubernetes.io/zone ### Configure Cluster Autoscaler Flags Start the cluster autoscaler with flag `--balance-similar-node-groups=true` and exclude the custom labels previously mentioned in the node groups section with the flag `--balancing-ignore-label`. These flags ensure that the cluster autoscaler balances the number of nodes across availability zones. For reference on managed EKS cluster, the following node labels are different across node groups: k8s.amazonaws.com/eniConfigCustom vpc.amazonaws.com/eniConfig Therefore, the cluster autoscaler starts with: \- --balancing-ignore-label=k8s.amazonaws.com/eniConfigCustom - --balancing-ignore-label=vpc.amazonaws.com/eniConfig These configuration recommendations serve as a guideline. However, the actual configuration of the cluster autoscaler (CA) depends on the cloud or infrastructure provider (vendor) you use and the relevant topology considerations. You must configure the CA appropriately. ### Configure Overprovisioning Nodes Configure at least one overprovisioning node per availability zone. Each overprovisioning nodes holds a resource that can accommodate three Mule app nodes, which improves the performance when new nodes are needed. > [!NOTE] Refer to your managed vendor documentation for cluster autoscaling best practices and > over-provisioning configuration details. ### Configure Topology Spread Constraints Your Mule app deployments which are enabled with autoscaling, are required to customize the kubernetes resources for the topology spread constraints in pod spec by updating the **whenUnsatisfiable** field with `DoNotSchedule`. This configuration ensures that autoscaling replicas are evenly spread across zones for high availability. topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" rtf.mulesoft.com/generation: "{{ .Values.resourceContentHash }}" Using `whenUnsatisfiable: DoNotSchedule` guarantees that pods are evenly spread across availability zones. To modify this setting, use the K8S templates CRD to adjust your deployments using HPA to `whenUnsatisfiable: DoNotSchedule`. You can also use dedicated namespaces (environments) to separate the autoscaling workloads from the classic ones. If you don’t make this change, you use `whenUnsatisfiable: ScheduleAnyway`. For further details on the configuration, refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.9/customize-kubernetes-crd) documentation. > [!WARNING] Customizing topology spread with `whenUnsatisfiable: DoNotSchedule`, without the > recommended configurations for node groups per availability zone, cluster autoscaler, and > overprovisionining, can lead to K8s failing to schedule the replicas with `Pending state` error. ### Understand CPU-based Autoscaling Policy MuleSoft owns and applies the [autoscaling](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) policy for your Mule application deployments. The following example shows the CPU-based HPA policy used for Mule apps deployed on Runtime Fabric instances. Note that you can choose `minReplicas` and `maxReplicas` values from the Runtime Manager user interface. apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app namespace: app-namespace spec: behavior: scaleDown: policies: - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 1800 scaleUp: policies: - periodSeconds: 180 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 0 maxReplicas: metrics: - resource: name: cpu target: averageUtilization: 70 type: Utilization type: Resource minReplicas: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app Some points to consider: Scale up can occur at most every 180 seconds. Each period, up to 100% of the currently running replicas may be added until the maximum configured replicas is reached. For scaling up there is no stabilization window. When the metrics indicate that the target should be scaled up, the target is scaled up immediately. Scale down can occur at most every 15 seconds. Each Period, up to 100% of the currently running replicas may be removed which means the scaling target can be scaled down to the minimum allowed replicas. The number of replicas removed is based on the aggregated calculations over the past 1800 seconds of the stabilization window. Min replicas - The minimum number of replicas that would be guaranteed to run at any given point of time. - Scale down policy would never remove replicas below this number. Max replicas - The maximum number of replicas that are capped, beyond which no more replicas can be added for scale up. For details, see [limitations-self.adoc#limitations](https://docs.mulesoft.com/runtime-fabric/2.9/limitations-self#limitations). - Scale up policy would never add replicas above this number. Enabling HPA can result in customers incurring additional flow usage when your application scales horizontally. To avoid overages from unpredicted scaling, configure the maximum configured replicas judiciously to stay within purchased flow limits. Track your incurred flow usage through [usage reports](https://docs.mulesoft.com/general/usage-reports). HPA uses CPU utilization at average of 70% HPA bases on [resource requests](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/#how-does-a-horizontalpodautoscaler-work). When target utilization value is set, the controller calculates the utilization value as a percentage of the equivalent resource request on the containers in each pod. If pod average use is greater than 70% in a period (periods for scale-up are set as 180 seconds), HPA scales up. Refer to the Kubernetes documentation for additional details. ## Performance Considerations and Limitations For a successful horizontal autoscaling of your Mule apps, review the following performance considerations: - In Runtime Fabric, the policy in use was benchmarked for Mule apps with CPU Reserved: 0.45vCpu and Limit: 0.55vCpu, which corresponds to these settings: resources: limits: cpu: 550m requests: cpu: 450m - Mule apps that scale based on CPU usage are a good fit with CPU based HPA. For example: - HTTP/HTTPS apps with async requests - Reverse proxies - Low latency + high throughput apps - Dataweave transformations - APIKit Routing - API Gateways with policies - Non-reentrant apps that do not have built in parallel processing such as batch jobs, scheduler apps without re-entrancy and duplicate scheduling across apps and low throughput, high latency apps with large requests may not be a good fit with CPU based HPA. - Scale up and scale down performance can vary based on the replica size and the application type. - The policy is optimized for replica sizes with <850m. Larger replica sizes might take longer to scale. HPA is recommended only for smaller CPU applications with average usage of 0.2vCPU. ### Limitations There are some limitations to consider: - CPU is the only resource for horizontal autoscaling. ## Configure Horizontal Pod Autoscaling To configure horizontal autoscaling for Mule apps deployed to Runtime Fabric, follow these steps: 1. Enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. 2. From Anypoint Platform, select **Runtime Manager** > **Applications**. 3. Click **Deploy application**. 4. In the **Runtime** tab, check the **Enable Autoscaling** box. 5. Set the minimum and maximum **Replica Count** limits. 6. Click **Deploy Application**. ![Runtime Manager UI with Enable Autoscaling field selected](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-autoscaling.png) ## Autoscaling Status and Logs When an autoscaling event occurs and your Mule app with horizontal autoscaling scales up, you can check the **Scaling** status in the Runtime Manager UI by clicking **View status** in your application’s details window: ![Runtime Manager UI with Mule app and Scaling status](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-hpa-rtm.png) You can also track when autoscaling events occurred through **Audit logs** in Access Management. Each time an application deployment scaled, there is an audit log published under the product **Runtime Manager**, by the **Anypoint Staff** user. The log has **Action** set to `Scaling` with the **Object** as the application ID. ![Runtime Manager UI with Audit logs and Scaling status](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-hpa-rtm-2.png) The following is an example log payload: ```console {"properties":{"organizationId":"my-orgID-abc","environmentId":"my-envID-xyz","response":{"message":{"message":"Application id:my-appID-123 scaled DOWN from 3 to 2 replicas.","logLevel":"INFO","context":{"logger":"Runtime Manager"},"timestamp":1700234556678}},"deploymentId":"my-appID-123","initialRequest":"/organizations/my-orgID-abc/environments/my-envID-xyz/deployments/my-appID-123/specs/my-specID-456"},"subaction":"Scaling"} ``` Additionally, you can track the scaled up replicas startup and the number of replicas of your Mule apps by running the following `kubectl` command in your terminal: ```console kubectl get events | grep HorizontalPodAutoscaler ``` Use the `kubectl get events` command in Kubernetes to retrieve events that occurred within the cluster. The command provides information about various activities and changes happening in the cluster, such as pod creations, deletions, and other important events. The `grep` command filters the output of `kubectl get events` for lines that contain the string `HorizontalPodAutoscaler`. The following example shows the command output that includes events related to a `HorizontalPodAutoscaler` with information about successful rescaling operations triggered by the HPA: ```console # kubectl get events | grep HorizontalPodAutoscaler 5m20s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target 5m5s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target 4m50s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 10; reason: ``` --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Horizontal Pod Autoscaling (HPA) for Runtime Fabric Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric instances support horizontal scaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. Mulesoft supports configuring Mule apps to be responsive to the CPU usage on Kubernetes (K8s) runtime side. You can enable CPU based horizontal autoscaling per application on the Runtime Manager application deployment page, which will result in automatic scale up or scale down of the deployment replicas as needed. In Kubernetes, a Horizontal Pod Autoscaler (HPA) automatically updates a workload resource, with the aim of automatically scaling the workload to match demand. Horizontal scaling means that the response to increased load is to deploy more pods. > [!NOTE] HPA is supported only on Runtime Fabric agent version 2.6.22 and higher. This feature applies only to select customers who are opted into the new pricing and packaging model. For more details, see [Anypoint Platform Pricing](https://docs.mulesoft.com/general/pricing) ## Before You Begin To configure autoscaling, the cluster administrator must enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. Refer to your managed vendors documentation on how to install or enable metrics API servers. ## Recommendations for Cluster Autoscaling These recommendations are for your infrastructure team to configure cluster autoscaling ### Configure Node Groups Configure one node group per availability zone, with a minimum of one node in the node group. This ensures that Kubernetes has information about all the availability zones in the cluster and avoids an issue where zone topology unschedulable pod fails to scale-out topologySpread predicate check. Make sure that nodes from all the node groups have the exact same labels except for the common labels and specific cloud provider labels that are different across nodes or availability zones by default. Custom labels (which are not common labels and specific cloud provider labels) and are different across nodes need to be excluded from cluster autoscaler when evaluating similar node groups. For reference on managed EKS labels such as: eks.amazonaws.com/nodegroup failure-domain.beta.kubernetes.io/region failure-domain.beta.kubernetes.io/zone kubernetes.io/hostname topology.kubernetes.io/region topology.kubernetes.io/zone ### Configure Cluster Autoscaler Flags Start the cluster autoscaler with flag `--balance-similar-node-groups=true` and exclude the custom labels previously mentioned in the node groups section with the flag `--balancing-ignore-label`. These flags ensure that the cluster autoscaler balances the number of nodes across availability zones. For reference on managed EKS cluster, these node labels are different across node groups: k8s.amazonaws.com/eniConfigCustom vpc.amazonaws.com/eniConfig Therefore, the cluster autoscaler starts with: \- --balancing-ignore-label=k8s.amazonaws.com/eniConfigCustom - --balancing-ignore-label=vpc.amazonaws.com/eniConfig These configuration recommendations serve as a guideline. However, the actual configuration of the cluster autoscaler (CA) depends on the cloud or infrastructure provider (vendor) you use and the relevant topology considerations. You must configure the CA appropriately. ### Configure Overprovisioning Nodes Configure at least one overprovisioning node per availability zone. Each overprovisioning nodes holds a resource that can accommodate three Mule app nodes, which improves the performance when new nodes are needed. > [!NOTE] Refer to your managed vendor documentation for cluster autoscaling best practices and > over-provisioning configuration details. ### Configure Topology Spread Constraints Your Mule app deployments which are enabled with autoscaling, are required to customize the kubernetes resources for the topology spread constraints in pod spec by updating the **whenUnsatisfiable** field with `DoNotSchedule`. This configuration ensures that autoscaling replicas are evenly spread across zones for high availability. topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" rtf.mulesoft.com/generation: "{{ .Values.resourceContentHash }}" Using `whenUnsatisfiable: DoNotSchedule` guarantees that pods are evenly spread across availability zones. To modify this setting, use the K8S templates CRD to adjust your deployments using HPA to `whenUnsatisfiable: DoNotSchedule`. You can also use dedicated namespaces (environments) to separate the autoscaling workloads from the classic ones. If you don’t make this change, you use `whenUnsatisfiable: ScheduleAnyway`. For further details on the configuration, refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd) documentation. > [!WARNING] Customizing topology spread with `whenUnsatisfiable: DoNotSchedule`, without the > recommended configurations for node groups per availability zone, cluster autoscaler, and > overprovisionining, can lead to K8s failing to schedule the replicas with `Pending state` error. ### Understand CPU-based Autoscaling Policy MuleSoft owns and applies the [autoscaling](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) policy for your Mule application deployments. This example shows the CPU-based HPA policy used for Mule apps deployed on Runtime Fabric instances. Note that you can choose `minReplicas` and `maxReplicas` values from the Runtime Manager user interface. Runtime Fabric deploys your Mule apps with Helm. The `HorizontalPodAutoscaler` resource therefore includes the Helm ownership label and annotations shown in this example. These values allow Helm to recognize and manage the resource as part of the application release. If you manually create or modify the HPA, you must keep these labels and annotations, where `` is the name of your application and `` is the environment namespace ID: apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app namespace: app-namespace labels: app.kubernetes.io/managed-by: Helm annotations: meta.helm.sh/release-name: meta.helm.sh/release-namespace: spec: behavior: scaleDown: policies: - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 1800 scaleUp: policies: - periodSeconds: 180 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 0 maxReplicas: metrics: - resource: name: cpu target: averageUtilization: 70 type: Utilization type: Resource minReplicas: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app Some points to consider: Scale up can occur at most every 180 seconds. Each period, up to 100% of the currently running replicas may be added until the maximum configured replicas is reached. For scaling up there is no stabilization window. When the metrics indicate that the target should be scaled up, the target is scaled up immediately. Scale down can occur at most every 15 seconds. Each Period, up to 100% of the currently running replicas may be removed which means the scaling target can be scaled down to the minimum allowed replicas. The number of replicas removed is based on the aggregated calculations over the past 1800 seconds of the stabilization window. Min replicas - The minimum number of replicas that would be guaranteed to run at any given point of time. - Scale down policy would never remove replicas below this number. Max replicas - The maximum number of replicas that are capped, beyond which no more replicas can be added for scale up. For details, see [limitations-self.adoc#limitations](https://docs.mulesoft.com/runtime-fabric/latest/limitations-self#limitations). - Scale up policy would never add replicas above this number. Enabling HPA can result in customers incurring additional flow usage when your application scales horizontally. To avoid overages from unpredicted scaling, configure the maximum configured replicas judiciously to stay within purchased flow limits. Track your incurred flow usage through [usage reports](https://docs.mulesoft.com/general/usage-reports). HPA uses CPU utilization at average of 70% HPA bases on [resource requests](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/#how-does-a-horizontalpodautoscaler-work). When target utilization value is set, the controller calculates the utilization value as a percentage of the equivalent resource request on the containers in each pod. If pod average use is greater than 70% in a period (periods for scale-up are set as 180 seconds), HPA scales up. Refer to the Kubernetes documentation for additional details. ## Performance Considerations and Limitations For a successful horizontal autoscaling of your Mule apps, review these performance considerations: - In Runtime Fabric, the policy in use was benchmarked for Mule apps with CPU Reserved: 0.45vCpu and Limit: 0.55vCpu, which corresponds to these settings: resources: limits: cpu: 550m requests: cpu: 450m - Mule apps that scale based on CPU usage are a good fit with CPU based HPA. For example: - HTTP/HTTPS apps with async requests - Reverse proxies - Low latency + high throughput apps - Dataweave transformations - APIKit Routing - API Gateways with policies - Non-reentrant apps that don’t have built in parallel processing such as batch jobs, scheduler apps without re-entrancy and duplicate scheduling across apps and low throughput, high latency apps with large requests may not be a good fit with CPU based HPA. - Scale up and scale down performance can vary based on the replica size and the application type. - The policy is optimized for replica sizes with <850m. Larger replica sizes might take longer to scale. HPA is recommended only for smaller CPU applications with average usage of 0.2vCPU. ### Limitations There are some limitations to consider: - CPU is the only resource for horizontal autoscaling. ## Configure Horizontal Pod Autoscaling To configure horizontal autoscaling for Mule apps deployed to Runtime Fabric, follow these steps: 1. Enable the [support for metrics APIs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) on your managed K8s API server. 2. From Anypoint Platform, select **Runtime Manager** > **Applications**. 3. Click **Deploy application**. 4. In the **Runtime** tab, check the **Enable Autoscaling** box. 5. Set the minimum and maximum **Replica Count** limits. 6. Click **Deploy Application**. ![Runtime Manager UI with Enable Autoscaling field selected](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-autoscaling.png) ## Autoscaling Status and Logs When an autoscaling event occurs and your Mule app with horizontal autoscaling scales up, you can check the **Scaling** status in the Runtime Manager UI by clicking **View status** in your application’s details window: ![Runtime Manager UI with Mule app and Scaling status](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-hpa-rtm.png) You can also track when autoscaling events occurred through **Audit logs** in Access Management. Each time an application deployment scaled, there is an audit log published under the product **Runtime Manager**, by the **Anypoint Staff** user. The log has **Action** set to `Scaling` with the **Object** as the application ID. ![Runtime Manager UI with Audit logs and Scaling status](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-hpa-rtm-2.png) This is an example log payload: ```console {"properties":{"organizationId":"my-orgID-abc","environmentId":"my-envID-xyz","response":{"message":{"message":"Application id:my-appID-123 scaled DOWN from 3 to 2 replicas.","logLevel":"INFO","context":{"logger":"Runtime Manager"},"timestamp":1700234556678}},"deploymentId":"my-appID-123","initialRequest":"/organizations/my-orgID-abc/environments/my-envID-xyz/deployments/my-appID-123/specs/my-specID-456"},"subaction":"Scaling"} ``` Additionally, you can track the scaled up replicas startup and the number of replicas of your Mule apps by running this `kubectl` command in your terminal: ```console kubectl get events | grep HorizontalPodAutoscaler ``` Use the `kubectl get events` command in Kubernetes to retrieve events that occurred within the cluster. The command provides information about various activities and changes happening in the cluster, such as pod creations, deletions, and other important events. The `grep` command filters the output of `kubectl get events` for lines that contain the string `HorizontalPodAutoscaler`. This example shows the command output that includes events related to a `HorizontalPodAutoscaler` with information about successful rescaling operations triggered by the HPA: ```console # kubectl get events | grep HorizontalPodAutoscaler 5m20s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target 5m5s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target 4m50s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 10; reason: ``` ## Troubleshooting ### Deployment Fails with `invalid ownership metadata` Error When you deploy a Mule app with autoscaling enabled, the deployment can fail and the app shows a **Not running** status in Runtime Manager with an error similar to this: ```text 1 or more replicas in unexpected state: [Runtime Fabric] UNKNOWN: running helm install: failed to upgrade: failed to upgrade chart runtime-fabric-public/rtf-mule-chart:: Unable to continue with update: HorizontalPodAutoscaler "" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to ""; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "" ``` This error occurs when a `HorizontalPodAutoscaler` (or another Kubernetes resource, such as a `Service` or `ServiceAccount`) with the same name already exists in the namespace but is not owned by Helm because it is missing the required Helm ownership label and annotations. Helm refuses to take ownership of a resource it did not create, so the deployment fails. This commonly happens when: - An HPA was created manually or by a tool other than Runtime Fabric. - A previous deployment left orphaned resources on the cluster after the application was removed from Runtime Manager, leaving Runtime Manager and the cluster out of sync. To resolve the error, use one of these options: - Add the Helm ownership metadata to the existing resource. Patch the resource so that Helm can adopt it, where `` is the application name and `` is the environment namespace ID: ```console kubectl label horizontalpodautoscaler -n \ app.kubernetes.io/managed-by=Helm --overwrite kubectl annotate horizontalpodautoscaler -n \ meta.helm.sh/release-name= \ meta.helm.sh/release-namespace= --overwrite ``` - Delete the conflicting resource. If the resource is left over from a previous deployment, delete it so that Runtime Fabric can recreate it during the next deployment. Verify that the resource is not in use before deleting it: ```console kubectl delete horizontalpodautoscaler -n ``` > [!NOTE] If the error references a different resource type, such as `Service` or > `ServiceAccount`, apply the same option to that resource. When the cluster is out of sync, more > than one orphaned resource might be missing the Helm ownership metadata. After you resolve the conflict, redeploy the application from Runtime Manager. --- product: Runtime Fabric version: 2.10 --- # Configuring Ingress Endpoints for Mule App Deployment > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure ingress endpoints for a Mule app deployment, complete these tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule app. ## Before You Begin Before configuring ingress in Runtime Fabric, set up an ingress controller. For a list of ingress controllers, refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/). ## Create an Ingress Resource Template and Apply it in the Cluster Use one of the [example templates](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration#kubernetes-ingress) to create an ingress resource. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ## Configure Ingress for a Mule App You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. ## See Also - [Configure Ingress in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/configure-ingress) --- product: Runtime Fabric version: 2.11 --- # Configuring Ingress Endpoints for Mule App Deployment > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure ingress endpoints for a Mule app deployment, complete these tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule app. ## Before You Begin Before configuring ingress in Runtime Fabric, set up an ingress controller. For a list of ingress controllers, refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/). ## Create an Ingress Resource Template and Apply it in the Cluster Use one of the [example templates](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration#kubernetes-ingress) to create an ingress resource. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ## Configure Ingress for a Mule App You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. ## See Also - [Configure Ingress in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/configure-ingress) --- product: Runtime Fabric version: 2.9 --- # Configuring Ingress Endpoints for Mule App Deployment > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure ingress endpoints for a Mule app deployment, complete these tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule app. ## Before You Begin Before configuring ingress in Runtime Fabric, set up an ingress controller. For a list of ingress controllers, refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/). ## Create an Ingress Resource Template and Apply it in the Cluster Use one of the [example templates](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration#kubernetes-ingress) to create an ingress resource. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ## Configure Ingress for a Mule App You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. ## See Also - [Configure Ingress in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/configure-ingress) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Ingress Endpoints for Mule App Deployment > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure ingress endpoints for a Mule app deployment, complete these tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule app. ## Before You Begin Before configuring ingress in Runtime Fabric, set up an ingress controller. For a list of ingress controllers, refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/). ## Create an Ingress Resource Template and Apply it in the Cluster Use one of the [example templates](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration#kubernetes-ingress) to create an ingress resource. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ## Configure Ingress for a Mule App You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. ## See Also - [Configure Ingress in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/configure-ingress) --- product: Runtime Fabric version: 2.5 --- # Configuring Ingress for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] This content refers to configuring ingress on Runtime Fabric for versions 1.10 and > later. Refer to the documentation for versions 1.8 or 1.9 for previous ingress configuration > instructions. Anypoint Runtime Fabric enables you to specify custom Ingress configurations using an ingress resource template. In a template, similar to a [Kubernetes ingress spec](https://kubernetes.io/docs/concepts/services-networking/ingress/), you can specify annotations, ingress class name, and HTTP and HTTPS rules. If you do not apply an ingress resource template for an application, you can’t add ingress endpoints when you deploy it. > [!IMPORTANT] The ingress controller included with Google Kubernetes Engine (GKE) provisions a > separate HTTP load balancer per application by default. > > AWS Application Load Balancers have similar behavior unless you use the `group.name` annotation. > Refer to > [Application load balancing on Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) > for details. ## Benefits of Custom Ingress Resource Templates Using custom ingress resource templates in Runtime Fabric enables you to take advantage of native Kubernetes ingress configuration functionality, including support for: - Multiple ingress configurations per application - Multiple ingress controllers within the same Runtime Fabric instance - TLS and HTTPS configuration - Custom URL naming - URL parameter placeholders ## How Ingress Resources Templates Work in Runtime Fabric The following diagram provides an overview of how to use ingress resource templates in Runtime Fabric: ![Diagram shows the ingress template workflow in Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.5/_images/ingress-diagram.png) 1. An IT admin configures an ingress controller. 2. An IT admin creates or modifies an ingress resource template using the necessary parameters. Various ingress controllers operate differently. Review your ingress controller documentation and adjust your annotations accordingly. 3. An IT admin applies the template using `kubectl apply` commands. 4. From the applied template, Runtime Fabric creates placeholder URI domains and propagates the ingress configuration in Anypoint Runtime Manager as a template for all application deployments. 5. A Mule application developer uses Runtime Manager to configure an application for deployment by selecting an available host, an optional subdomain, and a path combination, as specified in the ingress template. 6. Runtime Fabric receives the application deployment request and uses the ingress configurations from the template to create a corresponding ingress object in the cluster. ## Example Ingress Resource Templates The following examples illustrate how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress-resource template. Use the API version appropriate to your Kubernetes version: - Kubernetes v1.19 or later: - networking.k8s.io/v1 - networking.k8s.io/v1beta1 For Kubernetes v1.22 and later, the `extensions/v1beta1` and `networking.k8s.io/v1beta1` API versions of Ingress are not available. - Kubernetes v1.18 and earlier: - only networking.k8s.io/v1beta1 ### networking.k8s.io/v1 > [!NOTE] This template is a simplified version of the configuration. The final configuration of the > template can vary depending on the controller and ingress routing rules you use. Review the > documentation for your ingress controller carefully. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, for example, rtf-nginx.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example, nginx or haproxy.

3TLS is optional.

If you add the TLS section with a secretName attribute, you must ensure that you also create the referred TLS secret in the rtf namespace.

4The app-name placeholder parameter is replaced with the actual app name when you deploy the application. It helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6The path parameter value is replaced by the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a path-based routing ingress template, consult your ingress controller documentation and configure it accordingly. For an example using Nginx, see [Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes](https://help.salesforce.com/s/articleView?id=001116839&type=1). ### networking.k8s.io/v1beta1 ```yaml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - path: / (6) pathType: backend: (7) serviceName: service-name servicePort: 80 ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, for example, rtf-nginx.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example, nginx or haproxy.

3TLS is optional.

If you add the TLS section with a secretName attribute, you must ensure that you also create the referred TLS secret in the rtf namespace.

4The app-name placeholder parameter is replaced with the actual app name when you deploy the application. It helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6The path parameter value is replaced by the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a path-based routing ingress template, consult your ingress controller documentation and configure it accordingly. For an example using Nginx, see [Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes](https://help.salesforce.com/s/articleView?id=001116839&type=1). ### Template Placeholders The following placeholders are optional. If you use a placeholder, replace it in the appropriate location in the template. Placeholders must be lowercase.
Name of PlaceholderLocationExample Value

business-group-id

path, host, annotation, labels

labels:
  business:
  business-group-id

environment-id

path, host, annotation, labels

labels:
  environment:
  environment-id

unique-id

path, annotation, labels

path: /app-name-unique-id.com
Use the `unique-id` placeholder to create a unique application URL. This is useful if you want to deploy two applications with same name from different business groups. For example, if you use `app-name-unique-id.com` in the `path` section of the ingress template, the resulting endpoint will be similar to `app-name-7jkbic.com`. > [!NOTE] The `unique-id` placeholder is available in Runtime Fabric version 1.12.28 and later. ## Using TLS in the Ingress Template To use TLS in the ingress template, you must create a TLS secret. See the [Kubernetes TLS documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) for details. You can use the `rtf.mulesoft.com/synchronized=true` label to configure Runtime Fabric to synchronize any TLS secret updates to all application namespaces, for example: ```none apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: labels: rtf.mulesoft.com/synchronized=true data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` Applying this label to your secret enables your ingress controller to immediately apply the updated TLS material into application namespaces. If you don’t add this label, you must manually update the secret in each namespace. > [!NOTE] You can use the synchronization mechanism to replicate any secret from the Runtime Fabric > agent namespace into the application namespace upon deployment. ## Modify an Existing Ingress Template You can modify existing ingress templates even if they were already used for application deployments. Note that already created ingress objects based on this template are not updated if you modify the template. To update existing ingresses with the template changes, you have to perform a redeployment of the Mule application. For example, if you update the base domain which requires to change the endpoint for the ingress template, you must remove the old endpoint and add the new one as part of the application redeployment. ## Configure Ingress for a Mule Application Deployment in Runtime Fabric To configure ingress, complete the following tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule application. ### Before You Begin Before configuring ingress in Runtime Fabric, you must set up an ingress controller. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) for a list of ingress controllers. ### Create an Ingress Resource Template and Apply it in the Cluster Use one of the [example templates](#example-ingress-resource-templates) to create an ingress resource. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### Configure Ingress for a Mule Application You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. ## Existing Ingress Configurations Translated Post-Upgrade When upgrading to Runtime Fabric version 1.10, the upgrade process automatically translates any existing ingress ConfigMaps to the ingress resource template format, including annotations, path, namespace, and host parameters. Review the following table to determine if any action is required after upgrading.
Runtime Fabric Pre-upgradeRuntime Fabric UpgradedAction RequiredTLS Support

No domains configured and no ingress-ConfigMap applied

No template is generated automatically after the upgrade

Create a template. See Create an Ingress Resource Template and Apply it in the Cluster.

-

No domains configured, but a valid ingress-ConfigMap applied

Generated template will contain * for hosts and will contain the path and annotations from the previous ingress-ConfigMap

Edit the host field in the generated template to provide a valid host/domain for deploying applications in Runtime Manager

No TLS section added by default

Valid domains configured, but no ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include /app-name in the path for each template

No immediate action is required unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

Valid domains configured and a valid ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include all the paths and annotations from the previous ingress-ConfigMap

No immediate action required, unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

## Troubleshooting Ingress Issues If you encounter errors when attempting to use ingress for Runtime Fabric, troubleshoot them as follows. ### Mule App Deployed But Cannot Access Its Endpoint Scenario: You successfully deploy a Mule application in Runtime Manager, but you cannot access the application’s endpoint. To troubleshoot this issue: 1. Verify that the application is listening on port 8081: ```copy kubectl port-forward -n [NAMESPACE] svc/ 8081:8081 ``` 2. Verify that the application is running and responding to HTTP requests: ```copy curl -v \http://127.0.0.1:8081/ ``` This helps determine if the API access issue is on the Mule app itself. 3. Validate that an ingress resource exists for that application service: ```copy kubectl get ingress -n [NAMESPACE] ``` 4. Validate that the service was created: ```copy kubectl get svc -n [NAMESPACE] ``` If not, check the Runtime Fabric agent logs: - ```copy kubectl logs -n rtf [AGENT_POD_NAME] -f ``` If the service and ingress object look healthy, see additional troubleshooting tasks. ### Ingress Resource Created in Cluster But Cannot Access Its Endpoint Scenario: Runtime Fabric successfully creates an ingress resource in the cluster but you cannot access the application’s endpoint due to a 404 error. To troubleshoot this issue: 1. Verify the ingress and service resources: ```copy kubectl get ingress -n kubectl get svc -n ``` The results should be similar to: \# kubectl get ingress -n NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s # kubectl get svc -n NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. Check the ingress resource for your app to ensure that the HTTP path in the resource, annotations, and host are correctly rendered: ```copy kubectl get ing -n -oyaml ``` The results should be similar to: ```yaml # kubectl get ing -n -oyaml apiVersion: extensions/v1beta1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. Check the application pod logs to ensure that you’ve configured the correct listening port: ```copy kubectl logs -f -n -c app ``` The results should be similar to: \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. In the logs, verify that the listener port matches the service port discovered in Step 1. 5. If the port is correct, check the application logs to verify that the application is receiving requests from the ingress controller. ### Ingress Resource Not Recognized by AWS Application Load Balancer Scenario: When using an AWS ALB, you can’t access an application’s endpoint, even though you successfully deployed the application and endpoint. If you’re using AWS Load Balancer Controller for ingress, you must specify the `kubernetes.io/ingress.class: rtf-alb` annotation in the template, _not_ `ingressClassName: rtf-alb`. AWS Load Balancer Controller requires the `ingress.class` annotation to discover and create L7 load balancers for deployed ingress resources for those annotations. --- product: Runtime Fabric version: 2.6 --- # Configuring Ingress for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] This content refers to configuring ingress on Runtime Fabric for versions 1.10 and > later. Refer to the documentation for versions 1.8 or 1.9 for previous ingress configuration > instructions. Anypoint Runtime Fabric enables you to specify custom Ingress configurations using an ingress resource template. In a template, similar to a [Kubernetes ingress spec](https://kubernetes.io/docs/concepts/services-networking/ingress/), you can specify annotations, ingress class name, and HTTP and HTTPS rules. If you do not apply an ingress resource template for an application, you can’t add ingress endpoints when you deploy it. > [!IMPORTANT] The ingress controller included with Google Kubernetes Engine (GKE) provisions a > separate HTTP load balancer per application by default. > > AWS Application Load Balancers have similar behavior unless you use the `group.name` annotation. > Refer to > [Application load balancing on Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) > for details. ## Benefits of Custom Ingress Resource Templates Using custom ingress resource templates in Runtime Fabric enables you to take advantage of native Kubernetes ingress configuration functionality, including support for: - Multiple ingress configurations per application - Multiple ingress controllers within the same Runtime Fabric instance - TLS and HTTPS configuration - Custom URL naming - URL parameter placeholders ## How Ingress Resources Templates Work in Runtime Fabric The following diagram provides an overview of how to use ingress resource templates in Runtime Fabric: ![Diagram shows the ingress template workflow in Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.6/_images/ingress-diagram.png) 1. An IT admin configures an ingress controller. 2. An IT admin creates or modifies an ingress resource template using the necessary parameters. Various ingress controllers operate differently. Review your ingress controller documentation and adjust your annotations accordingly. 3. An IT admin applies the template using `kubectl apply` commands. 4. From the applied template, Runtime Fabric creates placeholder URI domains and propagates the ingress configuration in Anypoint Runtime Manager as a template for all application deployments. 5. A Mule application developer uses Runtime Manager to configure an application for deployment by selecting an available host, an optional subdomain, and a path combination, as specified in the ingress template. 6. Runtime Fabric receives the application deployment request and uses the ingress configurations from the template to create a corresponding ingress object in the cluster. ## Example Ingress Resource Templates The following examples illustrate how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress-resource template. Use the API version appropriate to your Kubernetes version: - Kubernetes v1.19 or later: - networking.k8s.io/v1 - networking.k8s.io/v1beta1 For Kubernetes v1.22 and later, the `extensions/v1beta1` and `networking.k8s.io/v1beta1` API versions of Ingress are not available. - Kubernetes v1.18 and earlier: - only networking.k8s.io/v1beta1 ### networking.k8s.io/v1 > [!NOTE] This template is a simplified version of the configuration. The final configuration of the > template can vary depending on the controller and ingress routing rules you use. Review the > documentation for your ingress controller carefully. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, for example, rtf-nginx.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example, nginx or haproxy.

3TLS is optional.

If you add the TLS section with a secretName attribute, you must ensure that you also create the referred TLS secret in the rtf namespace.

4The app-name placeholder parameter is replaced with the actual app name when you deploy the application. It helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6The path parameter value is replaced by the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a path-based routing ingress template, consult your ingress controller documentation and configure it accordingly. For an example using Nginx, see [Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes](https://help.salesforce.com/s/articleView?id=001116839&type=1). ### networking.k8s.io/v1beta1 ```yaml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - path: / (6) pathType: backend: (7) serviceName: service-name servicePort: 80 ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, for example, rtf-nginx.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example, nginx or haproxy.

3TLS is optional.

If you add the TLS section with a secretName attribute, you must ensure that you also create the referred TLS secret in the rtf namespace.

4The app-name placeholder parameter is replaced with the actual app name when you deploy the application. It helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6The path parameter value is replaced by the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a path-based routing ingress template, consult your ingress controller documentation and configure it accordingly. For an example using Nginx, see [Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes](https://help.salesforce.com/s/articleView?id=001116839&type=1). ### Template Placeholders The following placeholders are optional. If you use a placeholder, replace it in the appropriate location in the template. Placeholders must be lowercase.
Name of PlaceholderLocationExample Value

business-group-id

path, host, annotation, labels

labels:
  business:
  business-group-id

environment-id

path, host, annotation, labels

labels:
  environment:
  environment-id

unique-id

path, annotation, labels

path: /app-name-unique-id.com
Use the `unique-id` placeholder to create a unique application URL. This is useful if you want to deploy two applications with same name from different business groups. For example, if you use `app-name-unique-id.com` in the `path` section of the ingress template, the resulting endpoint will be similar to `app-name-7jkbic.com`. > [!NOTE] The `unique-id` placeholder is available in Runtime Fabric version 1.12.28 and later. ## Using TLS in the Ingress Template To use TLS in the ingress template, you must create a TLS secret. See the [Kubernetes TLS documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) for details. You can use the `rtf.mulesoft.com/synchronized=true` label to configure Runtime Fabric to synchronize any TLS secret updates to all application namespaces, for example: ```none apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: labels: rtf.mulesoft.com/synchronized=true data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` Applying this label to your secret enables your ingress controller to immediately apply the updated TLS material into application namespaces. If you don’t add this label, you must manually update the secret in each namespace. > [!NOTE] You can use the synchronization mechanism to replicate any secret from the Runtime Fabric > agent namespace into the application namespace upon deployment. ## Modify an Existing Ingress Template You can modify existing ingress templates even if they were already used for application deployments. Note that already created ingress objects based on this template are not updated if you modify the template. To update existing ingresses with the template changes, you have to perform a redeployment of the Mule application. For example, if you update the base domain which requires to change the endpoint for the ingress template, you must remove the old endpoint and add the new one as part of the application redeployment. Other changes take effect once the `ServiceResourceWatcher`, a component of the Runtime Fabric agent, processes the existing services after detecting changes in the ingress template. Therefore, restart the Runtime Fabric agent immediately after any changes to the ingress template to ensure all services are reconciled. ## Configure Ingress for a Mule Application Deployment in Runtime Fabric To configure ingress, complete the following tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule application. ### Before You Begin Before configuring ingress in Runtime Fabric, you must set up an ingress controller. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) for a list of ingress controllers. ### Create an Ingress Resource Template and Apply it in the Cluster Use one of the [example templates](#example-ingress-resource-templates) to create an ingress resource. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### Configure Ingress for a Mule Application You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. ## Existing Ingress Configurations Translated Post-Upgrade When upgrading to Runtime Fabric version 1.10, the upgrade process automatically translates any existing ingress ConfigMaps to the ingress resource template format, including annotations, path, namespace, and host parameters. Review the following table to determine if any action is required after upgrading.
Runtime Fabric Pre-upgradeRuntime Fabric UpgradedAction RequiredTLS Support

No domains configured and no ingress-ConfigMap applied

No template is generated automatically after the upgrade

Create a template. See Create an Ingress Resource Template and Apply it in the Cluster.

-

No domains configured, but a valid ingress-ConfigMap applied

Generated template will contain * for hosts and will contain the path and annotations from the previous ingress-ConfigMap

Edit the host field in the generated template to provide a valid host/domain for deploying applications in Runtime Manager

No TLS section added by default

Valid domains configured, but no ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include /app-name in the path for each template

No immediate action is required unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

Valid domains configured and a valid ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include all the paths and annotations from the previous ingress-ConfigMap

No immediate action required, unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

## Troubleshooting Ingress Issues If you encounter errors when attempting to use ingress for Runtime Fabric, troubleshoot them as follows. ### Mule App Deployed But Cannot Access Its Endpoint Scenario: You successfully deploy a Mule application in Runtime Manager, but you cannot access the application’s endpoint. To troubleshoot this issue: 1. Verify that the application is listening on port 8081: ```copy kubectl port-forward -n [NAMESPACE] svc/ 8081:8081 ``` 2. Verify that the application is running and responding to HTTP requests: ```copy curl -v \http://127.0.0.1:8081/ ``` This helps determine if the API access issue is on the Mule app itself. 3. Validate that an ingress resource exists for that application service: ```copy kubectl get ingress -n [NAMESPACE] ``` 4. Validate that the service was created: ```copy kubectl get svc -n [NAMESPACE] ``` If not, check the Runtime Fabric agent logs: - ```copy kubectl logs -n rtf [AGENT_POD_NAME] -f ``` If the service and ingress object look healthy, see additional troubleshooting tasks. ### Ingress Resource Created in Cluster But Cannot Access Its Endpoint Scenario: Runtime Fabric successfully creates an ingress resource in the cluster but you cannot access the application’s endpoint due to a 404 error. To troubleshoot this issue: 1. Verify the ingress and service resources: ```copy kubectl get ingress -n kubectl get svc -n ``` The results should be similar to: \# kubectl get ingress -n NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s # kubectl get svc -n NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. Check the ingress resource for your app to ensure that the HTTP path in the resource, annotations, and host are correctly rendered: ```copy kubectl get ing -n -oyaml ``` The results should be similar to: ```yaml # kubectl get ing -n -oyaml apiVersion: extensions/v1beta1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. Check the application pod logs to ensure that you’ve configured the correct listening port: ```copy kubectl logs -f -n -c app ``` The results should be similar to: \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. In the logs, verify that the listener port matches the service port discovered in Step 1. 5. If the port is correct, check the application logs to verify that the application is receiving requests from the ingress controller. ### Ingress Resource Not Recognized by AWS Application Load Balancer Scenario: When using an AWS ALB, you can’t access an application’s endpoint, even though you successfully deployed the application and endpoint. If you’re using AWS Load Balancer Controller for ingress, you must specify the `kubernetes.io/ingress.class: rtf-alb` annotation in the template, _not_ `ingressClassName: rtf-alb`. AWS Load Balancer Controller requires the `ingress.class` annotation to discover and create L7 load balancers for deployed ingress resources for those annotations. --- product: Runtime Fabric version: 2.7 --- # Configuring Ingress for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] This content refers to configuring ingress on Runtime Fabric for versions 1.10 and > later. Refer to the documentation for versions 1.8 or 1.9 for previous ingress configuration > instructions. Anypoint Runtime Fabric enables you to specify custom Ingress configurations using an ingress resource template. In a template, similar to a [Kubernetes ingress spec](https://kubernetes.io/docs/concepts/services-networking/ingress/), you can specify annotations, ingress class name, and HTTP and HTTPS rules. If you do not apply an ingress resource template for an application, you can’t add ingress endpoints when you deploy it. > [!IMPORTANT] The ingress controller included with Google Kubernetes Engine (GKE) provisions a > separate HTTP load balancer per application by default. > > AWS Application Load Balancers have similar behavior unless you use the `group.name` annotation. > Refer to > [Application load balancing on Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) > for details. ## Benefits of Custom Ingress Resource Templates Using custom ingress resource templates in Runtime Fabric enables you to take advantage of native Kubernetes ingress configuration functionality, including support for: - Multiple ingress configurations per application - Multiple ingress controllers within the same Runtime Fabric instance - TLS and HTTPS configuration - Custom URL naming - URL parameter placeholders ## How Ingress Resources Templates Work in Runtime Fabric The following diagram provides an overview of how to use ingress resource templates in Runtime Fabric: ![Diagram shows the ingress template workflow in Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.7/_images/ingress-diagram.png) 1. An IT admin configures an ingress controller. 2. An IT admin creates or modifies an ingress resource template using the necessary parameters. Various ingress controllers operate differently. Review your ingress controller documentation and adjust your annotations accordingly. 3. An IT admin applies the template using `kubectl apply` commands. 4. From the applied template, Runtime Fabric creates placeholder URI domains and propagates the ingress configuration in Anypoint Runtime Manager as a template for all application deployments. 5. A Mule application developer uses Runtime Manager to configure an application for deployment by selecting an available host, an optional subdomain, and a path combination, as specified in the ingress template. 6. Runtime Fabric receives the application deployment request and uses the ingress configurations from the template to create a corresponding ingress object in the cluster. ## Example Ingress Resource Templates The following examples illustrate how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress-resource template. Use the API version appropriate to your Kubernetes version: - Kubernetes v1.19 or later: - networking.k8s.io/v1 - networking.k8s.io/v1beta1 For Kubernetes v1.22 and later, the `extensions/v1beta1` and `networking.k8s.io/v1beta1` API versions of Ingress are not available. - Kubernetes v1.18 and earlier: - only networking.k8s.io/v1beta1 ### networking.k8s.io/v1 > [!NOTE] This template is a simplified version of the configuration. The final configuration of the > template can vary depending on the controller and ingress routing rules you use. Review the > documentation for your ingress controller carefully. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, for example, rtf-nginx.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example, nginx or haproxy.

3TLS is optional.

If you add the TLS section with a secretName attribute, you must ensure that you also create the referred TLS secret in the rtf namespace.

4The app-name placeholder parameter is replaced with the actual app name when you deploy the application. It helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6The path parameter value is replaced by the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a path-based routing ingress template, consult your ingress controller documentation and configure it accordingly. For an example using Nginx, see [Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes](https://help.salesforce.com/s/articleView?id=001116839&type=1). ### networking.k8s.io/v1beta1 ```yaml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - path: / (6) pathType: backend: (7) serviceName: service-name servicePort: 80 ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, for example, rtf-nginx.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example, nginx or haproxy.

3TLS is optional.

If you add the TLS section with a secretName attribute, you must ensure that you also create the referred TLS secret in the rtf namespace.

4The app-name placeholder parameter is replaced with the actual app name when you deploy the application. It helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6The path parameter value is replaced by the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a path-based routing ingress template, consult your ingress controller documentation and configure it accordingly. For an example using Nginx, see [Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes](https://help.salesforce.com/s/articleView?id=001116839&type=1). ### Template Placeholders The following placeholders are optional. If you use a placeholder, replace it in the appropriate location in the template. Placeholders must be lowercase.
Name of PlaceholderLocationExample Value

business-group-id

path, host, annotation, labels

labels:
  business:
  business-group-id

environment-id

path, host, annotation, labels

labels:
  environment:
  environment-id

unique-id

path, annotation, labels

path: /app-name-unique-id.com
Use the `unique-id` placeholder to create a unique application URL. This is useful if you want to deploy two applications with same name from different business groups. For example, if you use `app-name-unique-id.com` in the `path` section of the ingress template, the resulting endpoint will be similar to `app-name-7jkbic.com`. > [!NOTE] The `unique-id` placeholder is available in Runtime Fabric version 1.12.28 and later. ## Using TLS in the Ingress Template To use TLS in the ingress template, you must create a TLS secret. See the [Kubernetes TLS documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) for details. You can use the `rtf.mulesoft.com/synchronized: "true"` label to configure Runtime Fabric to synchronize any TLS secret updates to all application namespaces, for example: ```none apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: labels: rtf.mulesoft.com/synchronized: "true" data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` Applying this label to your secret enables your ingress controller to immediately apply the updated TLS material into application namespaces. If you don’t add this label, you must manually update the secret in each namespace. > [!NOTE] You can use the synchronization mechanism to replicate any secret from the Runtime Fabric > agent namespace into the application namespace upon deployment. ## Modify an Existing Ingress Template You can modify existing ingress templates even if they were already used for application deployments. Note that already created ingress objects based on this template are not updated if you modify the template. To update existing ingresses with the template changes, you have to perform a redeployment of the Mule application. For example, if you update the base domain which requires to change the endpoint for the ingress template, you must remove the old endpoint and add the new one as part of the application redeployment. ## Configure Ingress for a Mule Application Deployment in Runtime Fabric To configure ingress, complete the following tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule application. ### Before You Begin Before configuring ingress in Runtime Fabric, you must set up an ingress controller. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) for a list of ingress controllers. ### Create an Ingress Resource Template and Apply it in the Cluster Use one of the [example templates](#example-ingress-resource-templates) to create an ingress resource. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### Configure Ingress for a Mule Application You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. ## Existing Ingress Configurations Translated Post-Upgrade When upgrading to Runtime Fabric version 1.10, the upgrade process automatically translates any existing ingress ConfigMaps to the ingress resource template format, including annotations, path, namespace, and host parameters. Review the following table to determine if any action is required after upgrading.
Runtime Fabric Pre-upgradeRuntime Fabric UpgradedAction RequiredTLS Support

No domains configured and no ingress-ConfigMap applied

No template is generated automatically after the upgrade

Create a template. See Create an Ingress Resource Template and Apply it in the Cluster.

-

No domains configured, but a valid ingress-ConfigMap applied

Generated template will contain * for hosts and will contain the path and annotations from the previous ingress-ConfigMap

Edit the host field in the generated template to provide a valid host/domain for deploying applications in Runtime Manager

No TLS section added by default

Valid domains configured, but no ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include /app-name in the path for each template

No immediate action is required unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

Valid domains configured and a valid ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include all the paths and annotations from the previous ingress-ConfigMap

No immediate action required, unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

## Troubleshooting Ingress Issues If you encounter errors when attempting to use ingress for Runtime Fabric, troubleshoot them as follows. ### Mule App Deployed But Cannot Access Its Endpoint Scenario: You successfully deploy a Mule application in Runtime Manager, but you cannot access the application’s endpoint. To troubleshoot this issue: 1. Verify that the application is listening on port 8081: ```copy kubectl port-forward -n [NAMESPACE] svc/ 8081:8081 ``` 2. Verify that the application is running and responding to HTTP requests: ```copy curl -v \http://127.0.0.1:8081/ ``` This helps determine if the API access issue is on the Mule app itself. 3. Validate that an ingress resource exists for that application service: ```copy kubectl get ingress -n [NAMESPACE] ``` 4. Validate that the service was created: ```copy kubectl get svc -n [NAMESPACE] ``` If not, check the Runtime Fabric agent logs: - ```copy kubectl logs -n rtf [AGENT_POD_NAME] -f ``` If the service and ingress object look healthy, see additional troubleshooting tasks. ### Ingress Resource Created in Cluster But Cannot Access Its Endpoint Scenario: Runtime Fabric successfully creates an ingress resource in the cluster but you cannot access the application’s endpoint due to a 404 error. To troubleshoot this issue: 1. Verify the ingress and service resources: ```copy kubectl get ingress -n kubectl get svc -n ``` The results should be similar to: \# kubectl get ingress -n NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s # kubectl get svc -n NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. Check the ingress resource for your app to ensure that the HTTP path in the resource, annotations, and host are correctly rendered: ```copy kubectl get ing -n -oyaml ``` The results should be similar to: ```yaml # kubectl get ing -n -oyaml apiVersion: extensions/v1beta1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. Check the application pod logs to ensure that you’ve configured the correct listening port: ```copy kubectl logs -f -n -c app ``` The results should be similar to: \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. In the logs, verify that the listener port matches the service port discovered in Step 1. 5. If the port is correct, check the application logs to verify that the application is receiving requests from the ingress controller. ### Ingress Resource Not Recognized by AWS Application Load Balancer Scenario: When using an AWS ALB, you can’t access an application’s endpoint, even though you successfully deployed the application and endpoint. If you’re using AWS Load Balancer Controller for ingress, you must specify the `kubernetes.io/ingress.class: rtf-alb` annotation in the template, _not_ `ingressClassName: rtf-alb`. AWS Load Balancer Controller requires the `ingress.class` annotation to discover and create L7 load balancers for deployed ingress resources for those annotations. --- product: Runtime Fabric version: 2.8 --- # Configuring Ingress for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] This content refers to configuring ingress on Runtime Fabric for versions 1.10 and > later. Refer to the documentation for versions 1.8 or 1.9 for previous ingress configuration > instructions. Anypoint Runtime Fabric enables you to specify custom Ingress configurations using an ingress resource template. In a template, similar to a [Kubernetes ingress spec](https://kubernetes.io/docs/concepts/services-networking/ingress/), you can specify annotations, ingress class name, and HTTP and HTTPS rules. If you do not apply an ingress resource template for an application, you can’t add ingress endpoints when you deploy it. > [!IMPORTANT] The ingress controller included with Google Kubernetes Engine (GKE) provisions a > separate HTTP load balancer per application by default. > > AWS Application Load Balancers have similar behavior unless you use the `group.name` annotation. > Refer to > [Application load balancing on Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) > for details. ## Benefits of Custom Ingress Resource Templates Using custom ingress resource templates in Runtime Fabric enables you to take advantage of native Kubernetes ingress configuration functionality, including support for: - Multiple ingress configurations per application - Multiple ingress controllers within the same Runtime Fabric instance - TLS and HTTPS configuration - Custom URL naming - URL parameter placeholders ## How Ingress Resources Templates Work in Runtime Fabric The following diagram provides an overview of how to use ingress resource templates in Runtime Fabric: ![Diagram shows the ingress template workflow in Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.8/_images/ingress-diagram.png) 1. An IT admin configures an ingress controller. 2. An IT admin creates or modifies an ingress resource template using the necessary parameters. Various ingress controllers operate differently. Review your ingress controller documentation and adjust your annotations accordingly. 3. An IT admin applies the template using `kubectl apply` commands. 4. From the applied template, Runtime Fabric creates placeholder URI domains and propagates the ingress configuration in Anypoint Runtime Manager as a template for all application deployments. 5. A Mule application developer uses Runtime Manager to configure an application for deployment by selecting an available host, an optional subdomain, and a path combination, as specified in the ingress template. 6. Runtime Fabric receives the application deployment request and uses the ingress configurations from the template to create a corresponding ingress object in the cluster. ## Example Ingress Resource Templates The following examples illustrate how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress-resource template. Use the API version appropriate to your Kubernetes version: - Kubernetes v1.19 or later: - networking.k8s.io/v1 - networking.k8s.io/v1beta1 For Kubernetes v1.22 and later, the `extensions/v1beta1` and `networking.k8s.io/v1beta1` API versions of Ingress are not available. ### networking.k8s.io/v1 > [!NOTE] This template is a simplified version of the configuration. The final configuration of the > template can vary depending on the controller and ingress routing rules you use. Review the > documentation for your ingress controller carefully. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, for example, rtf-nginx.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example, nginx or haproxy.

3TLS is optional.

If you add the TLS section with a secretName attribute, you must ensure that you also create the referred TLS secret in the rtf namespace.

4The app-name placeholder parameter is replaced with the actual app name when you deploy the application. It helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6The path parameter is updated with the value specified in the Path field when configuring path-based routing for an ingress in your Mule app. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-path-based-routing namespace: rtf labels: spec: ingressClassName: rtf-nginx tls: - hosts: - test.example.com secretName: example-tls rules: - host: test.example.com http: paths: - pathType: Prefix path: /hello backend: service: name: service-name port: name: service-port ``` The resulting Mule app ingress from this template has the `path` parameter replaced with the values you configured on the Mule app deployment. In this example of the Mule app `myapp`, the routing is configured with the paths `/foo` and `/bar`: ```yaml # For the endpoint https://test.example.com/foo apiVersion: networking.k8s.io/v1 kind: Ingress … … spec: ingressClassName: nginx rules: - host: test.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: /foo pathType: Prefix tls: - hosts: test.example.com secretName: example-tls ``` ```yaml # For the endpoint https://test.example.com/bar apiVersion: networking.k8s.io/v1 kind: Ingress … … spec: ingressClassName: nginx rules: - host: test.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: /bar pathType: Prefix tls: - hosts: test.example.com secretName: example-tls ``` ![Runtime Manager UI with ingress configuration window](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-ingress.png) > [!NOTE] Refer to the documentation of your ingress controller and configure the path-based routing > ingress template accordingly. ### Template Placeholders The following placeholders are optional. If you use a placeholder, replace it in the appropriate location in the template. Placeholders must be lowercase.
Name of PlaceholderLocationExample Value

business-group-id

path, host, annotation, labels

labels:
  business:
  business-group-id

environment-id

path, host, annotation, labels

labels:
  environment:
  environment-id

unique-id

path, annotation, labels

path: /app-name-unique-id.com
Use the `unique-id` placeholder to create a unique application URL. This is useful if you want to deploy two applications with same name from different business groups. For example, if you use `app-name-unique-id.com` in the `path` section of the ingress template, the resulting endpoint will be similar to `app-name-7jkbic.com`. > [!NOTE] The `unique-id` placeholder is available in Runtime Fabric version 1.12.28 and later. ## Using TLS in the Ingress Template To use TLS in the ingress template, you must create a TLS secret. See the [Kubernetes TLS documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) for details. You can use the `rtf.mulesoft.com/synchronized: "true"` label to configure Runtime Fabric to synchronize any TLS secret updates to all application namespaces, for example: ```none apiVersion: v1 kind: Secret metadata: name: example-tls namespace: labels: rtf.mulesoft.com/synchronized: "true" data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` Applying this label to your secret enables your ingress controller to immediately apply the updated TLS material into application namespaces. If you don’t add this label, you must manually update the secret in each namespace. > [!NOTE] You can use the synchronization mechanism to replicate any secret from the Runtime Fabric > agent namespace into the application namespace upon deployment. ## Modify an Existing Ingress Template You can modify existing ingress templates even if they were already used for application deployments. Note that already created ingress objects based on this template are not updated if you modify the template. To update existing ingresses with the template changes, you have to perform a redeployment of the Mule application. For example, if you update the base domain which requires to change the endpoint for the ingress template, you must remove the old endpoint and add the new one as part of the application redeployment. ## Configure Ingress for a Mule Application Deployment in Runtime Fabric To configure ingress, complete the following tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule application. ### Before You Begin Before configuring ingress in Runtime Fabric, you must set up an ingress controller. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) for a list of ingress controllers. ### Create an Ingress Resource Template and Apply it in the Cluster Use one of the [example templates](#example-ingress-resource-templates) to create an ingress resource. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### Configure Ingress for a Mule Application You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. ## Existing Ingress Configurations Translated Post-Upgrade When upgrading to Runtime Fabric version 1.10, the upgrade process automatically translates any existing ingress ConfigMaps to the ingress resource template format, including annotations, path, namespace, and host parameters. Review the following table to determine if any action is required after upgrading.
Runtime Fabric Pre-upgradeRuntime Fabric UpgradedAction RequiredTLS Support

No domains configured and no ingress-ConfigMap applied

No template is generated automatically after the upgrade

Create a template. See Create an Ingress Resource Template and Apply it in the Cluster.

-

No domains configured, but a valid ingress-ConfigMap applied

Generated template will contain * for hosts and will contain the path and annotations from the previous ingress-ConfigMap

Edit the host field in the generated template to provide a valid host/domain for deploying applications in Runtime Manager

No TLS section added by default

Valid domains configured, but no ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include /app-name in the path for each template

No immediate action is required unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

Valid domains configured and a valid ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include all the paths and annotations from the previous ingress-ConfigMap

No immediate action required, unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

## Troubleshooting Ingress Issues If you encounter errors when attempting to use ingress for Runtime Fabric, troubleshoot them as follows. ### Mule App Deployed But Cannot Access Its Endpoint Scenario: You successfully deploy a Mule application in Runtime Manager, but you cannot access the application’s endpoint. To troubleshoot this issue: 1. Verify that the application is listening on port 8081: ```copy kubectl port-forward -n [NAMESPACE] svc/ 8081:8081 ``` 2. Verify that the application is running and responding to HTTP requests: ```copy curl -v \http://127.0.0.1:8081/ ``` This helps determine if the API access issue is on the Mule app itself. 3. Validate that an ingress resource exists for that application service: ```copy kubectl get ingress -n [NAMESPACE] ``` 4. Validate that the service was created: ```copy kubectl get svc -n [NAMESPACE] ``` If not, check the Runtime Fabric agent logs: - ```copy kubectl logs -n rtf [AGENT_POD_NAME] -f ``` If the service and ingress object look healthy, see additional troubleshooting tasks. ### Ingress Resource Created in Cluster But Cannot Access Its Endpoint Scenario: Runtime Fabric successfully creates an ingress resource in the cluster but you cannot access the application’s endpoint due to a 404 error. To troubleshoot this issue: 1. Verify the ingress and service resources: ```copy kubectl get ingress -n kubectl get svc -n ``` The results should be similar to: \# kubectl get ingress -n NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s # kubectl get svc -n NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. Check the ingress resource for your app to ensure that the HTTP path in the resource, annotations, and host are correctly rendered: ```copy kubectl get ing -n -oyaml ``` The results should be similar to: ```yaml # kubectl get ing -n -oyaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. Check the application pod logs to ensure that you’ve configured the correct listening port: ```copy kubectl logs -f -n -c app ``` The results should be similar to: \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. In the logs, verify that the listener port matches the service port discovered in Step 1. 5. If the port is correct, check the application logs to verify that the application is receiving requests from the ingress controller. ### Ingress Resource Not Recognized by AWS Application Load Balancer Scenario: When using an AWS ALB, you can’t access an application’s endpoint, even though you successfully deployed the application and endpoint. If you’re using AWS Load Balancer Controller for ingress, you must specify the `kubernetes.io/ingress.class: rtf-alb` annotation in the template, _not_ `ingressClassName: rtf-alb`. AWS Load Balancer Controller requires the `ingress.class` annotation to discover and create L7 load balancers for deployed ingress resources for those annotations. --- product: Runtime Fabric version: 2.10 --- # Configuring Ingress in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure ingress in Runtime Fabric, review these topics: - [Configuring Ingress Resource Template in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration) - [Configuring Ingress with HTTP Route Template Custom Resource In Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/configure-ingress-http-resource) - [Configuring Ingress Endpoints for Mule App Deployment](https://docs.mulesoft.com/runtime-fabric/2.10/configure-ingress-endpoints) --- product: Runtime Fabric version: 2.11 --- # Configuring Ingress in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure ingress in Runtime Fabric, review these topics: - [Configuring Ingress Resource Template in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration) - [Configuring Ingress with HTTP Route Template Custom Resource In Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/configure-ingress-http-resource) - [Configuring Ingress Endpoints for Mule App Deployment](https://docs.mulesoft.com/runtime-fabric/2.11/configure-ingress-endpoints) --- product: Runtime Fabric version: 2.9 --- # Configuring Ingress in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure ingress in Runtime Fabric, review these topics: - [Configuring Ingress Resource Template in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration) - [Configuring Ingress with HTTP Route Template Custom Resource In Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/configure-ingress-http-resource) - [Configuring Ingress Endpoints for Mule App Deployment](https://docs.mulesoft.com/runtime-fabric/2.9/configure-ingress-endpoints) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Ingress in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure ingress in Runtime Fabric, review these topics: - [Configuring Ingress Resource Template in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration) - [Configuring Ingress with HTTP Route Template Custom Resource In Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/configure-ingress-http-resource) - [Configuring Ingress Endpoints for Mule App Deployment](https://docs.mulesoft.com/runtime-fabric/latest/configure-ingress-endpoints) --- product: Runtime Fabric version: 2.10 --- # Configuring Ingress Resource Template in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] This content refers to configuring ingress on Runtime Fabric for versions 1.10 and > later. Refer to the documentation for versions 1.8 or 1.9 for previous ingress configuration > instructions. Anypoint Runtime Fabric enables you to specify custom Ingress configurations using an ingress resource template. In a template, similar to a [Kubernetes ingress spec](https://kubernetes.io/docs/concepts/services-networking/ingress/), you can specify annotations, ingress class name, and HTTP and HTTPS rules. If you do not apply an ingress resource template for an application, you can’t add ingress endpoints when you deploy it. > [!IMPORTANT] The ingress controller included with Google Kubernetes Engine (GKE) provisions a > separate HTTP load balancer per application by default. > > AWS Application Load Balancers have similar behavior unless you use the `group.name` annotation. > Refer to > [Application load balancing on Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) > for details. ## Benefits of Custom Ingress Resource Templates Using custom ingress resource templates in Runtime Fabric enables you to take advantage of native Kubernetes ingress configuration functionality, including support for: - Multiple ingress configurations per application - Multiple ingress controllers within the same Runtime Fabric instance - TLS and HTTPS configuration - Custom URL naming - URL parameter placeholders ## How Ingress Resources Templates Work in Runtime Fabric The following diagram provides an overview of how to use ingress resource templates in Runtime Fabric: ![Diagram shows the ingress template workflow in Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.10/_images/ingress-diagram.png) 1. An IT admin configures an ingress controller. 2. An IT admin creates or modifies an ingress resource template using the necessary parameters. Various ingress controllers operate differently. Review your ingress controller documentation and adjust your annotations accordingly. 3. An IT admin applies the template using `kubectl apply` commands. 4. From the applied template, Runtime Fabric creates placeholder URI domains and propagates the ingress configuration in Anypoint Runtime Manager as a template for all application deployments. 5. A Mule application developer uses Runtime Manager to configure an application for deployment by selecting an available host, an optional subdomain, and a path combination, as specified in the ingress template. 6. Runtime Fabric receives the application deployment request and uses the ingress configurations from the template to create a corresponding ingress object in the cluster. ## Example Ingress Resource Templates The following examples illustrate how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress-resource template. ### networking.k8s.io/v1 > [!NOTE] This template is a simplified version of the configuration. The final configuration of the > template can vary depending on the controller and ingress routing rules you use. Review the > documentation for your ingress controller carefully. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, for example, rtf-nginx.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example, nginx or haproxy.

kubernetes.io/ingress.class is deprecated by K8s > 1.18, for details refer to Improvements to the Ingress API in Kubernetes 1.18
3TLS is optional.

If you add the TLS section with a secretName attribute, you must ensure that you also create the referred TLS secret in the rtf namespace.

4The app-name placeholder parameter is replaced with the actual app name when you deploy the application. It helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6The path parameter value is replaced by the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a path-based routing ingress template, consult your ingress controller documentation and configure it accordingly. For an example using Nginx, see [Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes](https://help.salesforce.com/s/articleView?id=001116839&type=1). ### Template Placeholders The following placeholders are optional. If you use a placeholder, replace it in the appropriate location in the template. Placeholders must be lowercase.
Name of PlaceholderLocationExample Value

business-group-id

path, host, annotation, labels

labels:
  business:
  business-group-id

environment-id

path, host, annotation, labels

labels:
  environment:
  environment-id

unique-id

path, annotation, labels

path: /app-name-unique-id.com
Use the `unique-id` placeholder to create a unique application URL. This is useful if you want to deploy two applications with same name from different business groups. For example, if you use `app-name-unique-id.com` in the `path` section of the ingress template, the resulting endpoint will be similar to `app-name-7jkbic.com`. > [!NOTE] The `unique-id` placeholder is available in Runtime Fabric version 1.12.28 and later. ## Using TLS in the Ingress Template To use TLS in the ingress template, you must create a TLS secret. See the [Kubernetes TLS documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) for details. You can use the `rtf.mulesoft.com/synchronized: "true"` label to configure Runtime Fabric to synchronize any TLS secret updates to all application namespaces, for example: ```none apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: labels: rtf.mulesoft.com/synchronized: "true" data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` Applying this label to your secret enables your ingress controller to immediately apply the updated TLS material into application namespaces. If you don’t add this label, you must manually update the secret in each namespace. > [!NOTE] You can use the synchronization mechanism to replicate any secret from the Runtime Fabric > agent namespace into the application namespace upon deployment. ## Modify an Existing Ingress Template You can modify existing ingress templates even if they were already used for application deployments. Note that already created ingress objects based on this template are not updated if you modify the template. To update existing ingresses with the template changes, you have to perform a redeployment of the Mule application. For example, if you update the base domain which requires to change the endpoint for the ingress template, you must remove the old endpoint and add the new one as part of the application redeployment. ## Existing Ingress Configurations Translated Post-Upgrade When upgrading to Runtime Fabric version 1.10, the upgrade process automatically translates any existing ingress ConfigMaps to the ingress resource template format, including annotations, path, namespace, and host parameters. Review the following table to determine if any action is required after upgrading.
Runtime Fabric Pre-upgradeRuntime Fabric UpgradedAction RequiredTLS Support

No domains configured and no ingress-ConfigMap applied

No template is generated automatically after the upgrade

Create a template. See Create an Ingress Resource Template and Apply it in the Cluster.

-

No domains configured, but a valid ingress-ConfigMap applied

Generated template will contain * for hosts and will contain the path and annotations from the previous ingress-ConfigMap

Edit the host field in the generated template to provide a valid host/domain for deploying applications in Runtime Manager

No TLS section added by default

Valid domains configured, but no ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include /app-name in the path for each template

No immediate action is required unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

Valid domains configured and a valid ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include all the paths and annotations from the previous ingress-ConfigMap

No immediate action required, unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

## Troubleshooting Ingress Issues If you encounter errors when attempting to use ingress for Runtime Fabric, troubleshoot them as follows. ### Mule App Deployed But Cannot Access Its Endpoint Scenario: You successfully deploy a Mule application in Runtime Manager, but you cannot access the application’s endpoint. To troubleshoot this issue: 1. Verify that the application is listening on port 8081: ```copy kubectl port-forward -n [NAMESPACE] svc/ 8081:8081 ``` 2. Verify that the application is running and responding to HTTP requests: ```copy curl -v \http://127.0.0.1:8081/ ``` This helps determine if the API access issue is on the Mule app itself. 3. Validate that an ingress resource exists for that application service: ```copy kubectl get ingress -n [NAMESPACE] ``` 4. Validate that the service was created: ```copy kubectl get svc -n [NAMESPACE] ``` If not, check the Runtime Fabric agent logs: ```copy kubectl logs -n rtf [AGENT_POD_NAME] -f ``` If the service and ingress object look healthy, see additional troubleshooting tasks. ### Ingress Resource Created in Cluster But Cannot Access Its Endpoint Scenario: Runtime Fabric successfully creates an ingress resource in the cluster but you cannot access the application’s endpoint due to a 404 error. To troubleshoot this issue: 1. Verify the ingress and service resources: ```copy kubectl get ingress -n kubectl get svc -n ``` The results should be similar to: \# kubectl get ingress -n NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s # kubectl get svc -n NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. Check the ingress resource for your app to ensure that the HTTP path in the resource, annotations, and host are correctly rendered: ```copy kubectl get ing -n -oyaml ``` The results should be similar to: ```yaml # kubectl get ing -n -oyaml apiVersion: extensions/v1beta1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. Check the application pod logs to ensure that you’ve configured the correct listening port: ```copy kubectl logs -f -n -c app ``` The results should be similar to: \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. In the logs, verify that the listener port matches the service port discovered in Step 1. 5. If the port is correct, check the application logs to verify that the application is receiving requests from the ingress controller. ### Ingress Resource Not Recognized by AWS Application Load Balancer Scenario: When using an AWS ALB, you can’t access an application’s endpoint, even though you successfully deployed the application and endpoint. If you’re using AWS Load Balancer Controller for ingress, you must specify the `spec.ingressClassName: rtf-alb` in the template. AWS Load Balancer Controller requires the `spec.ingressClassName` to discover and create L7 load balancers for deployed ingress resources for those annotations. --- product: Runtime Fabric version: 2.11 --- # Configuring Ingress Resource Template in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] This content refers to configuring ingress on Runtime Fabric for versions 1.10 and > later. Refer to the documentation for versions 1.8 or 1.9 for previous ingress configuration > instructions. Anypoint Runtime Fabric enables you to specify custom Ingress configurations using an ingress resource template. In a template, similar to a [Kubernetes ingress spec](https://kubernetes.io/docs/concepts/services-networking/ingress/), you can specify annotations, ingress class name, and HTTP and HTTPS rules. If you do not apply an ingress resource template for an application, you can’t add ingress endpoints when you deploy it. > [!IMPORTANT] The ingress controller included with Google Kubernetes Engine (GKE) provisions a > separate HTTP load balancer per application by default. > > AWS Application Load Balancers have similar behavior unless you use the `group.name` annotation. > Refer to > [Application load balancing on Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) > for details. ## Benefits of Custom Ingress Resource Templates Using custom ingress resource templates in Runtime Fabric enables you to take advantage of native Kubernetes ingress configuration functionality, including support for: - Multiple ingress configurations per application - Multiple ingress controllers within the same Runtime Fabric instance - TLS and HTTPS configuration - Custom URL naming - URL parameter placeholders ## How Ingress Resources Templates Work in Runtime Fabric This diagram provides an overview of how to use ingress resource templates in Runtime Fabric: ![Diagram shows the ingress template workflow in Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.11/_images/ingress-diagram.png) 1. An IT admin configures an ingress controller. 2. An IT admin creates or modifies an ingress resource template using the necessary parameters. Various ingress controllers operate differently. Review your ingress controller documentation and adjust your annotations accordingly. 3. An IT admin applies the template using `kubectl apply` commands. 4. From the applied template, Runtime Fabric creates placeholder URI domains and propagates the ingress configuration in Anypoint Runtime Manager as a template for all application deployments. 5. A Mule application developer uses Runtime Manager to configure an application for deployment by selecting an available host, an optional subdomain, and a path combination, as specified in the ingress template. 6. Runtime Fabric receives the application deployment request and uses the ingress configurations from the template to create a corresponding ingress object in the cluster. ## Example Ingress Resource Templates These examples illustrate how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress-resource template. ### networking.k8s.io/v1 > [!NOTE] This template is a simplified version of the configuration. The final configuration of the > template can vary depending on the controller and ingress routing rules you use. Review the > documentation for your ingress controller carefully. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` Note this about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, for example, rtf-nginx.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example, nginx or haproxy.

kubernetes.io/ingress.class is deprecated by K8s > 1.18, for details refer to Improvements to the Ingress API in Kubernetes 1.18
3TLS is optional.

If you add the TLS section with a secretName attribute, you must ensure that you also create the referred TLS secret in the rtf namespace.

4The app-name placeholder parameter is replaced with the actual app name when you deploy the application. It helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6The path parameter value is replaced by the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a path-based routing ingress template, consult your ingress controller documentation and configure it accordingly. For an example using Nginx, see [Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes](https://help.salesforce.com/s/articleView?id=001116839&type=1). ### Template Placeholders These placeholders are optional. If you use a placeholder, replace it in the appropriate location in the template. Placeholders must be lowercase.
Name of PlaceholderLocationExample Value

business-group-id

path, host, annotation, labels

labels:
  business:
  business-group-id

environment-id

path, host, annotation, labels

labels:
  environment:
  environment-id

unique-id

path, annotation, labels

path: /app-name-unique-id.com
Use the `unique-id` placeholder to create a unique application URL. This is useful if you want to deploy two applications with same name from different business groups. For example, if you use `app-name-unique-id.com` in the `path` section of the ingress template, the resulting endpoint will be similar to `app-name-7jkbic.com`. > [!NOTE] The `unique-id` placeholder is available in Runtime Fabric version 1.12.28 and later. ## Using TLS in the Ingress Template To use TLS in the ingress template, you must create a TLS secret. See the [Kubernetes TLS documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) for details. You can use the `rtf.mulesoft.com/synchronized: "true"` label to configure Runtime Fabric to synchronize any TLS secret updates to all application namespaces, for example: ```none apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: labels: rtf.mulesoft.com/synchronized: "true" data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` Applying this label to your secret enables your ingress controller to immediately apply the updated TLS material into application namespaces. If you don’t add this label, you must manually update the secret in each namespace. > [!NOTE] You can use the synchronization mechanism to replicate any secret from the Runtime Fabric > agent namespace into the application namespace upon deployment. ## Modify an Existing Ingress Template You can modify existing ingress templates even if they were already used for application deployments. Note that already created ingress objects based on this template are not updated if you modify the template. To update existing ingresses with the template changes, you have to perform a redeployment of the Mule application. For example, if you update the base domain which requires to change the endpoint for the ingress template, you must remove the old endpoint and add the new one as part of the application redeployment. ## Existing Ingress Configurations Translated Post-Upgrade When upgrading to Runtime Fabric version 1.10, the upgrade process automatically translates any existing ingress ConfigMaps to the ingress resource template format, including annotations, path, namespace, and host parameters. Review this table to determine if any action is required after upgrading.
Runtime Fabric Pre-upgradeRuntime Fabric UpgradedAction RequiredTLS Support

No domains configured and no ingress-ConfigMap applied

No template is generated automatically after the upgrade

Create a template. See Create an Ingress Resource Template and Apply it in the Cluster.

-

No domains configured, but a valid ingress-ConfigMap applied

Generated template will contain * for hosts and will contain the path and annotations from the previous ingress-ConfigMap

Edit the host field in the generated template to provide a valid host/domain for deploying applications in Runtime Manager

No TLS section added by default

Valid domains configured, but no ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include /app-name in the path for each template

No immediate action is required unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

Valid domains configured and a valid ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include all the paths and annotations from the previous ingress-ConfigMap

No immediate action required, unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

## Troubleshooting Ingress Issues If you encounter errors when attempting to use ingress for Runtime Fabric, troubleshoot them as follows. ### Mule App Deployed But Cannot Access Its Endpoint Scenario: You successfully deploy a Mule application in Runtime Manager, but you cannot access the application’s endpoint. To troubleshoot this issue: 1. Verify that the application is listening on port 8081: ```copy kubectl port-forward -n [NAMESPACE] svc/ 8081:8081 ``` 2. Verify that the application is running and responding to HTTP requests: ```copy curl -v \http://127.0.0.1:8081/ ``` This helps determine if the API access issue is on the Mule app itself. 3. Validate that an ingress resource exists for that application service: ```copy kubectl get ingress -n [NAMESPACE] ``` 4. Validate that the service was created: ```copy kubectl get svc -n [NAMESPACE] ``` If not, check the Runtime Fabric agent logs: ```copy kubectl logs -n rtf [AGENT_POD_NAME] -f ``` If the service and ingress object look healthy, see additional troubleshooting tasks. ### Ingress Resource Created in Cluster But Cannot Access Its Endpoint Scenario: Runtime Fabric successfully creates an ingress resource in the cluster but you cannot access the application’s endpoint due to a 404 error. To troubleshoot this issue: 1. Verify the ingress and service resources: ```copy kubectl get ingress -n kubectl get svc -n ``` The results should be similar to: \# kubectl get ingress -n NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s # kubectl get svc -n NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. Check the ingress resource for your app to ensure that the HTTP path in the resource, annotations, and host are correctly rendered: ```copy kubectl get ing -n -oyaml ``` The results should be similar to: ```yaml # kubectl get ing -n -oyaml apiVersion: extensions/v1beta1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. Check the application pod logs to ensure that you’ve configured the correct listening port: ```copy kubectl logs -f -n -c app ``` The results should be similar to: \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. In the logs, verify that the listener port matches the service port discovered in Step 1. 5. If the port is correct, check the application logs to verify that the application is receiving requests from the ingress controller. ### Ingress Resource Not Recognized by AWS Application Load Balancer Scenario: When using an AWS ALB, you can’t access an application’s endpoint, even though you successfully deployed the application and endpoint. If you’re using AWS Load Balancer Controller for ingress, you must specify the `spec.ingressClassName: rtf-alb` in the template. AWS Load Balancer Controller requires the `spec.ingressClassName` to discover and create L7 load balancers for deployed ingress resources for those annotations. --- product: Runtime Fabric version: 2.9 --- # Configuring Ingress Resource Template in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] This content refers to configuring ingress on Runtime Fabric for versions 1.10 and > later. Refer to the documentation for versions 1.8 or 1.9 for previous ingress configuration > instructions. Anypoint Runtime Fabric enables you to specify custom Ingress configurations using an ingress resource template. In a template, similar to a [Kubernetes ingress spec](https://kubernetes.io/docs/concepts/services-networking/ingress/), you can specify annotations, ingress class name, and HTTP and HTTPS rules. If you do not apply an ingress resource template for an application, you can’t add ingress endpoints when you deploy it. > [!IMPORTANT] The ingress controller included with Google Kubernetes Engine (GKE) provisions a > separate HTTP load balancer per application by default. > > AWS Application Load Balancers have similar behavior unless you use the `group.name` annotation. > Refer to > [Application load balancing on Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) > for details. ## Benefits of Custom Ingress Resource Templates Using custom ingress resource templates in Runtime Fabric enables you to take advantage of native Kubernetes ingress configuration functionality, including support for: - Multiple ingress configurations per application - Multiple ingress controllers within the same Runtime Fabric instance - TLS and HTTPS configuration - Custom URL naming - URL parameter placeholders ## How Ingress Resources Templates Work in Runtime Fabric The following diagram provides an overview of how to use ingress resource templates in Runtime Fabric: ![Diagram shows the ingress template workflow in Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/2.9/_images/ingress-diagram.png) 1. An IT admin configures an ingress controller. 2. An IT admin creates or modifies an ingress resource template using the necessary parameters. Various ingress controllers operate differently. Review your ingress controller documentation and adjust your annotations accordingly. 3. An IT admin applies the template using `kubectl apply` commands. 4. From the applied template, Runtime Fabric creates placeholder URI domains and propagates the ingress configuration in Anypoint Runtime Manager as a template for all application deployments. 5. A Mule application developer uses Runtime Manager to configure an application for deployment by selecting an available host, an optional subdomain, and a path combination, as specified in the ingress template. 6. Runtime Fabric receives the application deployment request and uses the ingress configurations from the template to create a corresponding ingress object in the cluster. ## Example Ingress Resource Templates The following examples illustrate how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress-resource template. ### networking.k8s.io/v1 > [!NOTE] This template is a simplified version of the configuration. The final configuration of the > template can vary depending on the controller and ingress routing rules you use. Review the > documentation for your ingress controller carefully. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, for example, rtf-nginx.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example, nginx or haproxy.

kubernetes.io/ingress.class is deprecated by K8s > 1.18, for details refer to Improvements to the Ingress API in Kubernetes 1.18
3TLS is optional.

If you add the TLS section with a secretName attribute, you must ensure that you also create the referred TLS secret in the rtf namespace.

4The app-name placeholder parameter is replaced with the actual app name when you deploy the application. It helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6The path parameter value is replaced by the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a path-based routing ingress template, consult your ingress controller documentation and configure it accordingly. ### Template Placeholders The following placeholders are optional. If you use a placeholder, replace it in the appropriate location in the template. Placeholders must be lowercase.
Name of PlaceholderLocationExample Value

business-group-id

path, host, annotation, labels

labels:
  business:
  business-group-id

environment-id

path, host, annotation, labels

labels:
  environment:
  environment-id

unique-id

path, annotation, labels

path: /app-name-unique-id.com
Use the `unique-id` placeholder to create a unique application URL. This is useful if you want to deploy two applications with same name from different business groups. For example, if you use `app-name-unique-id.com` in the `path` section of the ingress template, the resulting endpoint will be similar to `app-name-7jkbic.com`. > [!NOTE] The `unique-id` placeholder is available in Runtime Fabric version 1.12.28 and later. ## Using TLS in the Ingress Template To use TLS in the ingress template, you must create a TLS secret. See the [Kubernetes TLS documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) for details. You can use the `rtf.mulesoft.com/synchronized: "true"` label to configure Runtime Fabric to synchronize any TLS secret updates to all application namespaces, for example: ```none apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: labels: rtf.mulesoft.com/synchronized: "true" data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` Applying this label to your secret enables your ingress controller to immediately apply the updated TLS material into application namespaces. If you don’t add this label, you must manually update the secret in each namespace. > [!NOTE] You can use the synchronization mechanism to replicate any secret from the Runtime Fabric > agent namespace into the application namespace upon deployment. ## Modify an Existing Ingress Template You can modify existing ingress templates even if they were already used for application deployments. Note that already created ingress objects based on this template are not updated if you modify the template. To update existing ingresses with the template changes, you have to perform a redeployment of the Mule application. For example, if you update the base domain which requires to change the endpoint for the ingress template, you must remove the old endpoint and add the new one as part of the application redeployment. ## Existing Ingress Configurations Translated Post-Upgrade When upgrading to Runtime Fabric version 1.10, the upgrade process automatically translates any existing ingress ConfigMaps to the ingress resource template format, including annotations, path, namespace, and host parameters. Review the following table to determine if any action is required after upgrading.
Runtime Fabric Pre-upgradeRuntime Fabric UpgradedAction RequiredTLS Support

No domains configured and no ingress-ConfigMap applied

No template is generated automatically after the upgrade

Create a template. See Create an Ingress Resource Template and Apply it in the Cluster.

-

No domains configured, but a valid ingress-ConfigMap applied

Generated template will contain * for hosts and will contain the path and annotations from the previous ingress-ConfigMap

Edit the host field in the generated template to provide a valid host/domain for deploying applications in Runtime Manager

No TLS section added by default

Valid domains configured, but no ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include /app-name in the path for each template

No immediate action is required unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

Valid domains configured and a valid ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include all the paths and annotations from the previous ingress-ConfigMap

No immediate action required, unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

## Troubleshooting Ingress Issues If you encounter errors when attempting to use ingress for Runtime Fabric, troubleshoot them as follows. ### Mule App Deployed But Cannot Access Its Endpoint Scenario: You successfully deploy a Mule application in Runtime Manager, but you cannot access the application’s endpoint. To troubleshoot this issue: 1. Verify that the application is listening on port 8081: ```copy kubectl port-forward -n [NAMESPACE] svc/ 8081:8081 ``` 2. Verify that the application is running and responding to HTTP requests: ```copy curl -v \http://127.0.0.1:8081/ ``` This helps determine if the API access issue is on the Mule app itself. 3. Validate that an ingress resource exists for that application service: ```copy kubectl get ingress -n [NAMESPACE] ``` 4. Validate that the service was created: ```copy kubectl get svc -n [NAMESPACE] ``` If not, check the Runtime Fabric agent logs: ```copy kubectl logs -n rtf [AGENT_POD_NAME] -f ``` If the service and ingress object look healthy, see additional troubleshooting tasks. ### Ingress Resource Created in Cluster But Cannot Access Its Endpoint Scenario: Runtime Fabric successfully creates an ingress resource in the cluster but you cannot access the application’s endpoint due to a 404 error. To troubleshoot this issue: 1. Verify the ingress and service resources: ```copy kubectl get ingress -n kubectl get svc -n ``` The results should be similar to: \# kubectl get ingress -n NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s # kubectl get svc -n NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. Check the ingress resource for your app to ensure that the HTTP path in the resource, annotations, and host are correctly rendered: ```copy kubectl get ing -n -oyaml ``` The results should be similar to: ```yaml # kubectl get ing -n -oyaml apiVersion: extensions/v1beta1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. Check the application pod logs to ensure that you’ve configured the correct listening port: ```copy kubectl logs -f -n -c app ``` The results should be similar to: \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. In the logs, verify that the listener port matches the service port discovered in Step 1. 5. If the port is correct, check the application logs to verify that the application is receiving requests from the ingress controller. ### Ingress Resource Not Recognized by AWS Application Load Balancer Scenario: When using an AWS ALB, you can’t access an application’s endpoint, even though you successfully deployed the application and endpoint. If you’re using AWS Load Balancer Controller for ingress, you must specify the `spec.ingressClassName: rtf-alb` in the template. AWS Load Balancer Controller requires the `spec.ingressClassName` to discover and create L7 load balancers for deployed ingress resources for those annotations. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Ingress Resource Template in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] This content refers to configuring ingress on Runtime Fabric for versions 1.10 and > later. Refer to the documentation for versions 1.8 or 1.9 for previous ingress configuration > instructions. Anypoint Runtime Fabric enables you to specify custom Ingress configurations using an ingress resource template. In a template, similar to a [Kubernetes ingress spec](https://kubernetes.io/docs/concepts/services-networking/ingress/), you can specify annotations, ingress class name, and HTTP and HTTPS rules. If you do not apply an ingress resource template for an application, you can’t add ingress endpoints when you deploy it. > [!IMPORTANT] The ingress controller included with Google Kubernetes Engine (GKE) provisions a > separate HTTP load balancer per application by default. > > AWS Application Load Balancers have similar behavior unless you use the `group.name` annotation. > Refer to > [Application load balancing on Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) > for details. ## Benefits of Custom Ingress Resource Templates Using custom ingress resource templates in Runtime Fabric enables you to take advantage of native Kubernetes ingress configuration functionality, including support for: - Multiple ingress configurations per application - Multiple ingress controllers within the same Runtime Fabric instance - TLS and HTTPS configuration - Custom URL naming - URL parameter placeholders ## How Ingress Resources Templates Work in Runtime Fabric The following diagram provides an overview of how to use ingress resource templates in Runtime Fabric: ![Diagram shows the ingress template workflow in Runtime Fabric](/mulesoft/current/en-us/runtime-fabric/latest/_images/ingress-diagram.png) 1. An IT admin configures an ingress controller. 2. An IT admin creates or modifies an ingress resource template using the necessary parameters. Various ingress controllers operate differently. Review your ingress controller documentation and adjust your annotations accordingly. 3. An IT admin applies the template using `kubectl apply` commands. 4. From the applied template, Runtime Fabric creates placeholder URI domains and propagates the ingress configuration in Anypoint Runtime Manager as a template for all application deployments. 5. A Mule application developer uses Runtime Manager to configure an application for deployment by selecting an available host, an optional subdomain, and a path combination, as specified in the ingress template. 6. Runtime Fabric receives the application deployment request and uses the ingress configurations from the template to create a corresponding ingress object in the cluster. ## Example Ingress Resource Templates The following examples illustrate how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress-resource template. ### networking.k8s.io/v1 > [!NOTE] This template is a simplified version of the configuration. The final configuration of the > template can vary depending on the controller and ingress routing rules you use. Review the > documentation for your ingress controller carefully. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, for example, rtf-nginx.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example, nginx or haproxy.

kubernetes.io/ingress.class is deprecated by K8s > 1.18, for details refer to Improvements to the Ingress API in Kubernetes 1.18
3TLS is optional.

If you add the TLS section with a secretName attribute, you must ensure that you also create the referred TLS secret in the rtf namespace.

4The app-name placeholder parameter is replaced with the actual app name when you deploy the application. It helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6The path parameter value is replaced by the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a path-based routing ingress template, consult your ingress controller documentation and configure it accordingly. For an example using Nginx, see [Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes](https://help.salesforce.com/s/articleView?id=001116839&type=1). ### Template Placeholders The following placeholders are optional. If you use a placeholder, replace it in the appropriate location in the template. Placeholders must be lowercase.
Name of PlaceholderLocationExample Value

business-group-id

path, host, annotation, labels

labels:
  business:
  business-group-id

environment-id

path, host, annotation, labels

labels:
  environment:
  environment-id

unique-id

path, annotation, labels

path: /app-name-unique-id.com
Use the `unique-id` placeholder to create a unique application URL. This is useful if you want to deploy two applications with same name from different business groups. For example, if you use `app-name-unique-id.com` in the `path` section of the ingress template, the resulting endpoint will be similar to `app-name-7jkbic.com`. > [!NOTE] The `unique-id` placeholder is available in Runtime Fabric version 1.12.28 and later. ## Using TLS in the Ingress Template To use TLS in the ingress template, you must create a TLS secret. See the [Kubernetes TLS documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) for details. You can use the `rtf.mulesoft.com/synchronized: "true"` label to configure Runtime Fabric to synchronize any TLS secret updates to all application namespaces, for example: ```none apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: labels: rtf.mulesoft.com/synchronized: "true" data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` Applying this label to your secret enables your ingress controller to immediately apply the updated TLS material into application namespaces. If you don’t add this label, you must manually update the secret in each namespace. > [!NOTE] You can use the synchronization mechanism to replicate any secret from the Runtime Fabric > agent namespace into the application namespace upon deployment. ## Modify an Existing Ingress Template You can modify existing ingress templates even if they were already used for application deployments. Note that already created ingress objects based on this template are not updated if you modify the template. To update existing ingresses with the template changes, you have to perform a redeployment of the Mule application. For example, if you update the base domain which requires to change the endpoint for the ingress template, you must remove the old endpoint and add the new one as part of the application redeployment. ## Existing Ingress Configurations Translated Post-Upgrade When upgrading to Runtime Fabric version 1.10, the upgrade process automatically translates any existing ingress ConfigMaps to the ingress resource template format, including annotations, path, namespace, and host parameters. Review the following table to determine if any action is required after upgrading.
Runtime Fabric Pre-upgradeRuntime Fabric UpgradedAction RequiredTLS Support

No domains configured and no ingress-ConfigMap applied

No template is generated automatically after the upgrade

Create a template. See Create an Ingress Resource Template and Apply it in the Cluster.

-

No domains configured, but a valid ingress-ConfigMap applied

Generated template will contain * for hosts and will contain the path and annotations from the previous ingress-ConfigMap

Edit the host field in the generated template to provide a valid host/domain for deploying applications in Runtime Manager

No TLS section added by default

Valid domains configured, but no ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include /app-name in the path for each template

No immediate action is required unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

Valid domains configured and a valid ingress-ConfigMap applied

Generated templates will contain one host per domain per template and will include all the paths and annotations from the previous ingress-ConfigMap

No immediate action required, unless the domains use https://; in this case, configure a TLS secret in the template corresponding to the HTTPS domain

For domains that have https://, the template corresponding to that domain will have a TLS section without a secret attribute

## Troubleshooting Ingress Issues If you encounter errors when attempting to use ingress for Runtime Fabric, troubleshoot them as follows. ### Mule App Deployed But Cannot Access Its Endpoint Scenario: You successfully deploy a Mule application in Runtime Manager, but you cannot access the application’s endpoint. To troubleshoot this issue: 1. Verify that the application is listening on port 8081: ```copy kubectl port-forward -n [NAMESPACE] svc/ 8081:8081 ``` 2. Verify that the application is running and responding to HTTP requests: ```copy curl -v \http://127.0.0.1:8081/ ``` This helps determine if the API access issue is on the Mule app itself. 3. Validate that an ingress resource exists for that application service: ```copy kubectl get ingress -n [NAMESPACE] ``` 4. Validate that the service was created: ```copy kubectl get svc -n [NAMESPACE] ``` If not, check the Runtime Fabric agent logs: ```copy kubectl logs -n rtf [AGENT_POD_NAME] -f ``` If the service and ingress object look healthy, see additional troubleshooting tasks. ### Ingress Resource Created in Cluster But Cannot Access Its Endpoint Scenario: Runtime Fabric successfully creates an ingress resource in the cluster but you cannot access the application’s endpoint due to a 404 error. To troubleshoot this issue: 1. Verify the ingress and service resources: ```copy kubectl get ingress -n kubectl get svc -n ``` The results should be similar to: \# kubectl get ingress -n NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s # kubectl get svc -n NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. Check the ingress resource for your app to ensure that the HTTP path in the resource, annotations, and host are correctly rendered: ```copy kubectl get ing -n -oyaml ``` The results should be similar to: ```yaml # kubectl get ing -n -oyaml apiVersion: extensions/v1beta1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. Check the application pod logs to ensure that you’ve configured the correct listening port: ```copy kubectl logs -f -n -c app ``` The results should be similar to: \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. In the logs, verify that the listener port matches the service port discovered in Step 1. 5. If the port is correct, check the application logs to verify that the application is receiving requests from the ingress controller. ### Ingress Resource Not Recognized by AWS Application Load Balancer Scenario: When using an AWS ALB, you can’t access an application’s endpoint, even though you successfully deployed the application and endpoint. If you’re using AWS Load Balancer Controller for ingress, you must specify the `spec.ingressClassName: rtf-alb` in the template. AWS Load Balancer Controller requires the `spec.ingressClassName` to discover and create L7 load balancers for deployed ingress resources for those annotations. --- product: Runtime Fabric version: 2.10 --- # Configuring Ingress with HTTP Route-Template Custom Resource in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Configure ingress support for Mule apps on the Anypoint Runtime Fabric platform using the HTTP route-template custom resource. ## Benefits of Ingress Configuration with the HTTP Route-Template Custom Resource Current ingress support for Mule apps on the Runtime Fabric platform is confined to [Kubernetes ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) resources, which restricts usage to cloud vendor-native HTTP routing solutions, such as OpenShift Routes on OpenShift clusters, Istio, or Kubernetes Gateway API. To address this limitation, Runtime Fabric supports a custom resource `httproutetemplates.rtf.mulesoft.com` template. Use the HTTP route-template custom resource in Runtime Fabric to define and implement custom routing configurations. With this approach, you can take advantage of compatibility with a range of ingress controllers and cloud-native routing mechanisms, including support for: - Subdomain based routing - Path based routing - Header based routing - Rate limiting ## HTTP Route-Template Custom-Resource Placeholders Runtime Fabric provides placeholder properties that cluster administrators can use in their HTTP route-template custom resource. Placeholder properties are replaced with real values during application deployment. The following property placeholders are available:
PropertyDescription

{{ .ResourceName }}

Runtime Fabric generated unique routing resource name

{{ .ApplicationName }}

Application deployment name

{{ .Namespace }}

Namespace of the Mule app deployment

{{ .Service.Name }}

Backend service name of the application deployment

{{ .Service.PortName }}

Backend service port name of the application deployment

{{ .Service.Port }}

Backend service port number of the application deployment

{{ .Host }}

Host value from the public endpoint of application deployment

{{ .Path }}

Path value from the public endpoint of application deployment

{{ .OrganizationID }}

Organization ID of the application deployment

{{ .EnvironmentID }}

Environment ID of the application deployment

{{ .UniqueId }}

Unique ID placeholder to create a unique application URL

Use the `{ .ResourceName }` placeholder to ensure the uniqueness of the name of the HTTP routing resource being created, especially if the deployment has multiple endpoints. It is recommended to use this placeholder; otherwise, you need to manually ensure the resource name uniqueness. Kubernetes enforces that the names of resources must be unique within a namespace, but not across namespaces.For more details, refer to [Namespaces Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/#when-to-use-multiple-namespaces). For example: resources: - | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: {{ .ResourceName }} The resulting HTTP routing (ingress in the previous example) resource name for the `myapp` deployment will be `myapp-2048497571` Use the `{{ .ApplicationName }}` placeholder to replace with the actual name of application deployment. For example: resources: - | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: labels: app-name: {{ .ApplicationName }} Use the `{{ .UniqueID }}` placeholder to create a unique application URL. This is useful if you want to deploy two applications with same name from different business groups. For example, if you use `/api/{{ .UniqueID }}.com` in the path section of the ingress template, the resulting endpoint will be similar to `/api/7jkbic.com`. > [!NOTE] The placeholders are currently scoped to the `resources` section of the > `httproutetemplates.rtf.mulesoft.com` only. Usage of these placeholders on the baseEndpoints and > Anypoint Runtime Manager UI will be supported in future releases. ## How the HTTP Route-Template Custom Resource Works in Runtime Fabric This diagram provides an overview of how to configure ingress using an HTTP route-template custom resource in Runtime Fabric: ![HTTP route-template diagram overview](/mulesoft/current/en-us/runtime-fabric/2.10/_images/ingress-http-diagram.png) The `httproutetemplates` resource applies only to new Mule app deployments created after the template resource is set up. Existing deployments are unaffected. After applying an httproutetemplate, it is applied for all subsequent application deployments. The `httproutetemplates` resource enables you to configure routes like these: - `baseEndpoints` Endpoints associated with the routing resources defined in the template. These endpoints are synchronized by Runtime Fabric with the Anypoint control plane. Application developers select one or more endpoints during deployment and optionally customize the path and subdomain when applicable. Specify the `http` or `https` protocol for your endpoints. - `resources` A list of strings, each declaring a Kubernetes routing resource. To get the CRD of key elements available to configure for the template, retrieve the Kubernetes specification by running this command: kubectl get crd httproutetemplates.rtf.mulesoft.com -o yaml ## HTTP Route-Template Examples Review these HTTP route-templates examples for Kubernetes ingress, OpenShift routes, and Kubernetes Gateway API (HTTPRoute). ### Example for Kubernetes Ingress This example shows an HTTP route-template resource for Kubernetes ingress: apiVersion: rtf.mulesoft.com/v1 kind: HTTPRouteTemplate metadata: name: example-template-ingress namespace: rtf spec: baseEndpoints: #(1) - https://\*.example.com - https://example.com resources: #(2) - | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: {{ .ResourceName }} namespace: {{ .Namespace }} labels: annotations: spec: ingressClassName: nginx tls: - hosts: - {{ .Host }} secretName: testsecret-tls rules: - host: {{ .Host }} #(3) http: paths: - pathType: Prefix path: {{ .Path }} #(4) backend: service: name: {{ .Service.Name }} port: name: {{ .Service.PortName }} 1. Hosts or domains used for mapping the public endpoints configured on the Mule app deployment. 2. One or more Kubernetes routing resources, such as an Ingress resource. 3. Host or domain from the Mule app’s public URL. 4. Path from the Mule app’s public URL. > [!NOTE] For Runtime fabric software entire `resources` is a list of strings and gets consumed as > is. So you dont have to configure any special prefix like `rtf-` for IngressClassName On the Anypoint Runtime Manager UI page, application developers see the following Base Endpoints to configure their app deployment. ![Ingress configuration window in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-ingress-rtm.png) Finally, when this application is deployed to the Runtime Fabric target, each endpoint will result in the creation of an ingress resource. In this example, the ingress resource generated corresponds to the `myapp.example.com` host endpoint: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: meta.helm.sh/release-name: myapp meta.helm.sh/release-namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c creationTimestamp: "2025-01-10T17:08:41Z" generation: 1 labels: app.kubernetes.io/managed-by: Helm name: myapp-1699085749 namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c resourceVersion: "45959978" uid: ee20766e-0d6e-4d19-8770-08250458d659 spec: ingressClassName: nginx rules: - host: myapp.example.com http: paths: - backend: service: name: myapp port: name: http path: / pathType: Prefix tls: - hosts: - myapp.example.com secretName: testsecret-tls In this example, the ingress resource generated corresponds to the `example.com` host endpoint: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: meta.helm.sh/release-name: myapp meta.helm.sh/release-namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c creationTimestamp: "2025-01-10T17:08:41Z" generation: 1 labels: app.kubernetes.io/managed-by: Helm name: myapp-860107349 namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c resourceVersion: "45959979" uid: e51d488b-9cf5-4c03-8adf-f0ea50366e31 spec: ingressClassName: nginx rules: - host: example.com http: paths: - backend: service: name: myapp port: name: http path: / pathType: Prefix tls: - hosts: - example.com secretName: testsecret-tls ### Example for OpenShift Routes This example shows an HTTP route-template resource for OpenShift routes: apiVersion: rtf.mulesoft.com/v1 kind: HTTPRouteTemplate metadata: name: example-template-openshiftroute namespace: rtf spec: baseEndpoints: - https://example.com/ resources: - | apiVersion: route.openshift.io/v1 kind: Routes metadata: name: {{ .ResourceName }} namespace: {{ .Namespace }} spec: host: {{ .Host }} path: {{ .Path }} to: kind: Service name: {{ .Service.Name }} tls: termination: edge key: |- -----BEGIN PRIVATE KEY----- \[...\] -----END PRIVATE KEY----- certificate: |- -----BEGIN CERTIFICATE----- \[...\] -----END CERTIFICATE----- caCertificate: |- -----BEGIN CERTIFICATE----- \[...\] -----END CERTIFICATE----- ### Example for Kubernetes Gateway API This example shows an HTTP route-template resource for Kubernetes Gateway API (HTTPRoute): apiVersion: rtf.mulesoft.com/v1 kind: HTTPRouteTemplate metadata: name: example-template-gateway namespace: rtf spec: baseEndpoints: - https://example.com resources: - | apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: {{ .ResourceName }} namespace: {{ .Namespace }} spec: parentRefs: - kind: Gateway name: cluster-gateway hostnames: - {{ .Host }} rules: - matches: - path: type: PathPrefix value: {{ .Path }} backendRefs: - name: {{ .Service.Name }} port: {{ .Service.Port }} > [!NOTE] You are responsible for the configuration of the Kubernetes Gateway resources and allowing > HTTPRoutes from the route’s namespace to be attached. ## Use TLS in the HTTP Route-Template Custom Resource To use TLS in the routing resources in an HTTP route template, you may need to create a TLS secret in the Runtime Fabric namespace. For details, refer to the [Kubernetes TLS](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) documentation. To configure the Runtime Fabric to manage the secrets lifecycle (create, update, and delete) across all application namespace, use the `rtf.mulesoft.com/synchronized: "true"` label on the TLS secret. For example: apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: rtf labels: rtf.mulesoft.com/synchronized: "true" data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls Using this label is highly recommended for secrets management. If you don’t add this label, you must manually update the secret in each namespace. ## Modify an Existing HTTP Route-Template CRD You can modify existing `httproutetemplates` templates at any time. Note that previously created HTTP routing resources based on this template aren’t updated automatically. To update existing HTTP routing resources after changing the template, perform a redeployment of the Mule app from the Anypoint control plane. For example, if you update the base domain, which requires changing the endpoint for the ingress template, remove the old endpoint and add the new one as part of the application redeployment. ## Create Role and RoleBindings If the ingress resource is not the standard ingress type, create a Role or RoleBinding to give the Runtime Fabric agent service account the necessary privileges to create an ingress resource. This example shows the creation of Role and RoleBinding. For OpenShift routes and other similar configurations, create Roles and RoleBindings that are tailored to your specific needs. You can either create these in all application namespaces or use ClusterRole and ClusterRoleBindings, depending on your preferences and any restrictions you have in place. Role example: apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: rtf-manage-routes namespace: rules: - apiGroups: - route.openshift.io resources: - routes - routes/custom-host verbs: - '\*' RoleBinding example: apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: manage-routes namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: rtf-manage-routes subjects: - kind: ServiceAccount name: rtf-agent namespace: ## Frequently Asked Questions **Does Runtime Fabric support the existing ingress templates?** Yes, Runtime Fabric supports both old and new templates. However, it is recommended to use the new HTTP Route templates to configure the ingress for your Mule application deployments. **What happens if there is a BaseEndpoint or URL collision between two HTTP Route CRs?** If there are ingress templates and HTTPRoute templates with the same baseEndpoints, the new HttpRoute CR always takes precedence, and the old ingress serves as a fallback. **What are some placeholder usage guidelines?** Placeholders are not mandatory, but use them to make the HTTP Route template more generic. Placeholders are specific to the templates. This means that placeholders used in ingress templates cannot be used in route templates. For example, the `app-name` placeholder: - In an ingress template the placeholder is replaced by the application name. - In a route template the placeholder is treated as a string `app-name`. ## See Also - [Configuring Ingress in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/configure-ingress) --- product: Runtime Fabric version: 2.11 --- # Configuring Ingress with HTTP Route-Template Custom Resource in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Configure ingress support for Mule apps on the Anypoint Runtime Fabric platform using the HTTP route-template custom resource. ## Benefits of Ingress Configuration with the HTTP Route-Template Custom Resource Current ingress support for Mule apps on the Runtime Fabric platform is confined to [Kubernetes ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) resources, which restricts usage to cloud vendor-native HTTP routing solutions, such as OpenShift Routes on OpenShift clusters, Istio, or Kubernetes Gateway API. To address this limitation, Runtime Fabric supports a custom resource `httproutetemplates.rtf.mulesoft.com` template. Use the HTTP route-template custom resource in Runtime Fabric to define and implement custom routing configurations. With this approach, you can take advantage of compatibility with a range of ingress controllers and cloud-native routing mechanisms, including support for: - Subdomain based routing - Path based routing - Header based routing - Rate limiting ## HTTP Route-Template Custom-Resource Placeholders Runtime Fabric provides placeholder properties that cluster administrators can use in their HTTP route-template custom resource. Placeholder properties are replaced with real values during application deployment. The following property placeholders are available:
PropertyDescription

{{ .ResourceName }}

Runtime Fabric generated unique routing resource name

{{ .ApplicationName }}

Application deployment name

{{ .Namespace }}

Namespace of the Mule app deployment

{{ .Service.Name }}

Backend service name of the application deployment

{{ .Service.PortName }}

Backend service port name of the application deployment

{{ .Service.Port }}

Backend service port number of the application deployment

{{ .Host }}

Host value from the public endpoint of application deployment

{{ .Path }}

Path value from the public endpoint of application deployment

{{ .OrganizationID }}

Organization ID of the application deployment

{{ .EnvironmentID }}

Environment ID of the application deployment

{{ .UniqueId }}

Unique ID placeholder to create a unique application URL

Use the `{ .ResourceName }` placeholder to ensure the uniqueness of the name of the HTTP routing resource being created, especially if the deployment has multiple endpoints. It is recommended to use this placeholder; otherwise, you need to manually ensure the resource name uniqueness. Kubernetes enforces that the names of resources must be unique within a namespace, but not across namespaces.For more details, refer to [Namespaces Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/#when-to-use-multiple-namespaces). For example: resources: - | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: {{ .ResourceName }} The resulting HTTP routing (ingress in the previous example) resource name for the `myapp` deployment will be `myapp-2048497571` Use the `{{ .ApplicationName }}` placeholder to replace with the actual name of application deployment. For example: resources: - | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: labels: app-name: {{ .ApplicationName }} Use the `{{ .UniqueID }}` placeholder to create a unique application URL. This is useful if you want to deploy two applications with same name from different business groups. For example, if you use `/api/{{ .UniqueID }}.com` in the path section of the ingress template, the resulting endpoint will be similar to `/api/7jkbic.com`. > [!NOTE] The placeholders are currently scoped to the `resources` section of the > `httproutetemplates.rtf.mulesoft.com` only. Usage of these placeholders on the baseEndpoints and > Anypoint Runtime Manager UI will be supported in future releases. ## How the HTTP Route-Template Custom Resource Works in Runtime Fabric This diagram provides an overview of how to configure ingress using an HTTP route-template custom resource in Runtime Fabric: ![HTTP route-template diagram overview](/mulesoft/current/en-us/runtime-fabric/2.11/_images/ingress-http-diagram.png) The `httproutetemplates` resource applies only to new Mule app deployments created after the template resource is set up. Existing deployments are unaffected. After applying an httproutetemplate, it is applied for all subsequent application deployments. The `httproutetemplates` resource enables you to configure routes like these: - `baseEndpoints` Endpoints associated with the routing resources defined in the template. These endpoints are synchronized by Runtime Fabric with the Anypoint control plane. Application developers select one or more endpoints during deployment and optionally customize the path and subdomain when applicable. - `resources` A list of strings, each declaring a Kubernetes routing resource. To get the CRD of key elements available to configure for the template, retrieve the Kubernetes specification by running this command: kubectl get crd httproutetemplates.rtf.mulesoft.com -o yaml ## HTTP Route-Template Examples Review these HTTP route-templates examples for Kubernetes ingress, OpenShift routes, and Kubernetes Gateway API (HTTPRoute). ### Example for Kubernetes Ingress This example shows an HTTP route-template resource for Kubernetes ingress: apiVersion: rtf.mulesoft.com/v1 kind: HTTPRouteTemplate metadata: name: example-template-ingress namespace: rtf spec: baseEndpoints: #(1) - https://\*.example.com - https://example.com resources: #(2) - | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: {{ .ResourceName }} namespace: {{ .Namespace }} labels: annotations: spec: ingressClassName: nginx tls: - hosts: - {{ .Host }} secretName: testsecret-tls rules: - host: {{ .Host }} #(3) http: paths: - pathType: Prefix path: {{ .Path }} #(4) backend: service: name: {{ .Service.Name }} port: name: {{ .Service.PortName }} 1. Hosts or domains used for mapping the public endpoints configured on the Mule app deployment. 2. One or more Kubernetes routing resources, such as an Ingress resource. 3. Host or domain from the Mule app’s public URL. 4. Path from the Mule app’s public URL. > [!NOTE] For Runtime fabric software entire `resources` is a list of strings and gets consumed as > is. So you dont have to configure any special prefix like `rtf-` for IngressClassName On the Anypoint Runtime Manager UI page, application developers see these Base Endpoints to configure their app deployment. ![Ingress configuration window in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-ingress-rtm.png) Finally, when this application is deployed to the Runtime Fabric target, each endpoint will result in the creation of an ingress resource. In this example, the ingress resource generated corresponds to the `myapp.example.com` host endpoint: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: meta.helm.sh/release-name: myapp meta.helm.sh/release-namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c creationTimestamp: "2025-01-10T17:08:41Z" generation: 1 labels: app.kubernetes.io/managed-by: Helm name: myapp-1699085749 namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c resourceVersion: "45959978" uid: ee20766e-0d6e-4d19-8770-08250458d659 spec: ingressClassName: nginx rules: - host: myapp.example.com http: paths: - backend: service: name: myapp port: name: http path: / pathType: Prefix tls: - hosts: - myapp.example.com secretName: testsecret-tls In this example, the ingress resource generated corresponds to the `example.com` host endpoint: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: meta.helm.sh/release-name: myapp meta.helm.sh/release-namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c creationTimestamp: "2025-01-10T17:08:41Z" generation: 1 labels: app.kubernetes.io/managed-by: Helm name: myapp-860107349 namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c resourceVersion: "45959979" uid: e51d488b-9cf5-4c03-8adf-f0ea50366e31 spec: ingressClassName: nginx rules: - host: example.com http: paths: - backend: service: name: myapp port: name: http path: / pathType: Prefix tls: - hosts: - example.com secretName: testsecret-tls ### Example for OpenShift Routes This example shows an HTTP route-template resource for OpenShift routes: apiVersion: rtf.mulesoft.com/v1 kind: HTTPRouteTemplate metadata: name: example-template-openshiftroute namespace: rtf spec: baseEndpoints: - https://example.com/ resources: - | apiVersion: route.openshift.io/v1 kind: Routes metadata: name: {{ .ResourceName }} namespace: {{ .Namespace }} spec: host: {{ .Host }} path: {{ .Path }} to: kind: Service name: {{ .Service.Name }} tls: termination: edge key: |- -----BEGIN PRIVATE KEY----- \[...\] -----END PRIVATE KEY----- certificate: |- -----BEGIN CERTIFICATE----- \[...\] -----END CERTIFICATE----- caCertificate: |- -----BEGIN CERTIFICATE----- \[...\] -----END CERTIFICATE----- ### Example for Kubernetes Gateway API This example shows an HTTP route-template resource for Kubernetes Gateway API (HTTPRoute): apiVersion: rtf.mulesoft.com/v1 kind: HTTPRouteTemplate metadata: name: example-template-gateway namespace: rtf spec: baseEndpoints: - https://example.com resources: - | apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: {{ .ResourceName }} namespace: {{ .Namespace }} spec: parentRefs: - kind: Gateway name: cluster-gateway hostnames: - {{ .Host }} rules: - matches: - path: type: PathPrefix value: {{ .Path }} backendRefs: - name: {{ .Service.Name }} port: {{ .Service.Port }} > [!NOTE] You are responsible for the configuration of the Kubernetes Gateway resources and allowing > HTTPRoutes from the route’s namespace to be attached. ## Use TLS in the HTTP Route-Template Custom Resource To use TLS in the routing resources in an HTTP route template, you may need to create a TLS secret in the Runtime Fabric namespace. For details, refer to the [Kubernetes TLS](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) documentation. To configure the Runtime Fabric to manage the secrets lifecycle (create, update, and delete) across all application namespace, use the `rtf.mulesoft.com/synchronized: "true"` label on the TLS secret. For example: apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: rtf labels: rtf.mulesoft.com/synchronized: "true" data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls Using this label is highly recommended for secrets management. If you don’t add this label, you must manually update the secret in each namespace. ## Modify an Existing HTTP Route-Template CRD You can modify existing `httproutetemplates` templates at any time. Note that previously created HTTP routing resources based on this template aren’t updated automatically. To update existing HTTP routing resources after changing the template, perform a redeployment of the Mule app from the Anypoint control plane. For example, if you update the base domain, which requires changing the endpoint for the ingress template, remove the old endpoint and add the new one as part of the application redeployment. ## Create Role and RoleBindings If the ingress resource is not the standard ingress type, create a Role or RoleBinding to give the Runtime Fabric agent service account the necessary privileges to create an ingress resource. This example shows the creation of Role and RoleBinding. For OpenShift routes and other similar configurations, create Roles and RoleBindings that are tailored to your specific needs. You can either create these in all application namespaces or use ClusterRole and ClusterRoleBindings, depending on your preferences and any restrictions you have in place. Role example: apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: rtf-manage-routes namespace: rules: - apiGroups: - route.openshift.io resources: - routes - routes/custom-host verbs: - '\*' RoleBinding example: apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: manage-routes namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: rtf-manage-routes subjects: - kind: ServiceAccount name: rtf-agent namespace: ## Frequently Asked Questions **Does Runtime Fabric support the existing ingress templates?** Yes, Runtime Fabric supports both old and new templates. However, it is recommended to use the new HTTP Route templates to configure the ingress for your Mule application deployments. **What happens if there is a BaseEndpoint or URL collision between two HTTP Route CRs?** If there are ingress templates and HTTPRoute templates with the same baseEndpoints, the new HttpRoute CR always takes precedence, and the old ingress serves as a fallback. **What are some placeholder usage guidelines?** Placeholders are not mandatory, but use them to make the HTTP Route template more generic. Placeholders are specific to the templates. This means that placeholders used in ingress templates cannot be used in route templates. For example, the `app-name` placeholder: - In an ingress template the placeholder is replaced by the application name. - In a route template the placeholder is treated as a string `app-name`. ## See Also - [Configuring Ingress in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/configure-ingress) --- product: Runtime Fabric version: 2.9 --- # Configuring Ingress with HTTP Route-Template Custom Resource in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Configure ingress support for Mule apps on the Anypoint Runtime Fabric platform using the HTTP route-template custom resource. ## Benefits of Ingress Configuration with the HTTP Route-Template Custom Resource Current ingress support for Mule apps on the Runtime Fabric platform is confined to [Kubernetes ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) resources, which restricts usage to cloud vendor-native HTTP routing solutions, such as OpenShift Routes on OpenShift clusters, Istio, or Kubernetes Gateway API. To address this limitation, Runtime Fabric supports a custom resource `httproutetemplates.rtf.mulesoft.com` template. Use the HTTP route-template custom resource in Runtime Fabric to define and implement custom routing configurations. With this approach, you can take advantage of compatibility with a range of ingress controllers and cloud-native routing mechanisms, including support for: - Subdomain based routing - Path based routing - Header based routing - Rate limiting ## HTTP Route-Template Custom-Resource Placeholders Runtime Fabric provides placeholder properties that cluster administrators can use in their HTTP route-template custom resource. Placeholder properties are replaced with real values during application deployment. The following property placeholders are available:
PropertyDescription

{{ .ResourceName }}

Runtime Fabric generated unique routing resource name

{{ .ApplicationName }}

Application deployment name

{{ .Namespace }}

Namespace of the Mule app deployment

{{ .Service.Name }}

Backend service name of the application deployment

{{ .Service.PortName }}

Backend service port name of the application deployment

{{ .Service.Port }}

Backend service port number of the application deployment

{{ .Host }}

Host value from the public endpoint of application deployment

{{ .Path }}

Path value from the public endpoint of application deployment

{{ .OrganizationID }}

Organization ID of the application deployment

{{ .EnvironmentID }}

Environment ID of the application deployment

{{ .UniqueId }}

Unique ID placeholder to create a unique application URL

Use the `{ .ResourceName }` placeholder to ensure the uniqueness of the name of the HTTP routing resource being created, especially if the deployment has multiple endpoints. It is recommended to use this placeholder; otherwise, you need to manually ensure the resource name uniqueness. Kubernetes enforces that the names of resources must be unique within a namespace, but not across namespaces.For more details, refer to [Namespaces Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/#when-to-use-multiple-namespaces). For example: resources: - | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: {{ .ResourceName }} The resulting HTTP routing (ingress in the previous example) resource name for the `myapp` deployment will be `myapp-2048497571` Use the `{{ .ApplicationName }}` placeholder to replace with the actual name of application deployment. For example: resources: - | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: labels: app-name: {{ .ApplicationName }} Use the `{{ .UniqueID }}` placeholder to create a unique application URL. This is useful if you want to deploy two applications with same name from different business groups. For example, if you use `/api/{{ .UniqueID }}.com` in the path section of the ingress template, the resulting endpoint will be similar to `/api/7jkbic.com`. > [!NOTE] The placeholders are currently scoped to the `resources` section of the > `httproutetemplates.rtf.mulesoft.com` only. Usage of these placeholders on the baseEndpoints and > Anypoint Runtime Manager UI will be supported in future releases. ## How the HTTP Route-Template Custom Resource Works in Runtime Fabric This diagram provides an overview of how to configure ingress using an HTTP route-template custom resource in Runtime Fabric: ![HTTP route-template diagram overview](/mulesoft/current/en-us/runtime-fabric/2.9/_images/ingress-http-diagram.png) The `httproutetemplates` resource applies only to new Mule app deployments created after the template resource is set up. Existing deployments are unaffected. After applying an httproutetemplate, it is applied for all subsequent application deployments. The `httproutetemplates` resource enables you to configure routes like these: - `baseEndpoints` Endpoints associated with the routing resources defined in the template. These endpoints are synchronized by Runtime Fabric with the Anypoint control plane. Application developers select one or more endpoints during deployment and optionally customize the path and subdomain when applicable. Specify the `http` or `https` protocol for your endpoints. - `resources` A list of strings, each declaring a Kubernetes routing resource. To get the CRD of key elements available to configure for the template, retrieve the Kubernetes specification by running this command: kubectl get crd httproutetemplates.rtf.mulesoft.com -o yaml ## HTTP Route-Template Examples Review these HTTP route-templates examples for Kubernetes ingress, OpenShift routes, and Kubernetes Gateway API (HTTPRoute). ### Example for Kubernetes Ingress This example shows an HTTP route-template resource for Kubernetes ingress: apiVersion: rtf.mulesoft.com/v1 kind: HTTPRouteTemplate metadata: name: example-template-ingress namespace: rtf spec: baseEndpoints: #(1) - https://\*.example.com - https://example.com resources: #(2) - | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: {{ .ResourceName }} namespace: {{ .Namespace }} labels: annotations: spec: ingressClassName: nginx tls: - hosts: - {{ .Host }} secretName: testsecret-tls rules: - host: {{ .Host }} #(3) http: paths: - pathType: Prefix path: {{ .Path }} #(4) backend: service: name: {{ .Service.Name }} port: name: {{ .Service.PortName }} 1. Hosts or domains used for mapping the public endpoints configured on the Mule app deployment. 2. One or more Kubernetes routing resources, such as an Ingress resource. 3. Host or domain from the Mule app’s public URL. 4. Path from the Mule app’s public URL. > [!NOTE] For Runtime fabric software entire `resources` is a list of strings and gets consumed as > is. So you dont have to configure any special prefix like `rtf-` for IngressClassName On the Anypoint Runtime Manager UI page, application developers see the following Base Endpoints to configure their app deployment. ![Ingress configuration window in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-ingress-rtm.png) Finally, when this application is deployed to the Runtime Fabric target, each endpoint will result in the creation of an ingress resource. In this example, the ingress resource generated corresponds to the `myapp.example.com` host endpoint: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: meta.helm.sh/release-name: myapp meta.helm.sh/release-namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c creationTimestamp: "2025-01-10T17:08:41Z" generation: 1 labels: app.kubernetes.io/managed-by: Helm name: myapp-1699085749 namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c resourceVersion: "45959978" uid: ee20766e-0d6e-4d19-8770-08250458d659 spec: ingressClassName: nginx rules: - host: myapp.example.com http: paths: - backend: service: name: myapp port: name: http path: / pathType: Prefix tls: - hosts: - myapp.example.com secretName: testsecret-tls In this example, the ingress resource generated corresponds to the `example.com` host endpoint: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: meta.helm.sh/release-name: myapp meta.helm.sh/release-namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c creationTimestamp: "2025-01-10T17:08:41Z" generation: 1 labels: app.kubernetes.io/managed-by: Helm name: myapp-860107349 namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c resourceVersion: "45959979" uid: e51d488b-9cf5-4c03-8adf-f0ea50366e31 spec: ingressClassName: nginx rules: - host: example.com http: paths: - backend: service: name: myapp port: name: http path: / pathType: Prefix tls: - hosts: - example.com secretName: testsecret-tls ### Example for OpenShift Routes This example shows an HTTP route-template resource for OpenShift routes: apiVersion: rtf.mulesoft.com/v1 kind: HTTPRouteTemplate metadata: name: example-template-openshiftroute namespace: rtf spec: baseEndpoints: - https://example.com/ resources: - | apiVersion: route.openshift.io/v1 kind: Routes metadata: name: {{ .ResourceName }} namespace: {{ .Namespace }} spec: host: {{ .Host }} path: {{ .Path }} to: kind: Service name: {{ .Service.Name }} tls: termination: edge key: |- -----BEGIN PRIVATE KEY----- \[...\] -----END PRIVATE KEY----- certificate: |- -----BEGIN CERTIFICATE----- \[...\] -----END CERTIFICATE----- caCertificate: |- -----BEGIN CERTIFICATE----- \[...\] -----END CERTIFICATE----- ### Example for Kubernetes Gateway API This example shows an HTTP route-template resource for Kubernetes Gateway API (HTTPRoute): apiVersion: rtf.mulesoft.com/v1 kind: HTTPRouteTemplate metadata: name: example-template-gateway namespace: rtf spec: baseEndpoints: - https://example.com resources: - | apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: {{ .ResourceName }} namespace: {{ .Namespace }} spec: parentRefs: - kind: Gateway name: cluster-gateway hostnames: - {{ .Host }} rules: - matches: - path: type: PathPrefix value: {{ .Path }} backendRefs: - name: {{ .Service.Name }} port: {{ .Service.Port }} > [!NOTE] You are responsible for the configuration of the Kubernetes Gateway resources and allowing > HTTPRoutes from the route’s namespace to be attached. ## Use TLS in the HTTP Route-Template Custom Resource To use TLS in the routing resources in an HTTP route template, you may need to create a TLS secret in the Runtime Fabric namespace. For details, refer to the [Kubernetes TLS](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) documentation. To configure the Runtime Fabric to manage the secrets lifecycle (create, update, and delete) across all application namespace, use the `rtf.mulesoft.com/synchronized: "true"` label on the TLS secret. For example: apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: rtf labels: rtf.mulesoft.com/synchronized: "true" data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls Using this label is highly recommended for secrets management. If you don’t add this label, you must manually update the secret in each namespace. ## Modify an Existing HTTP Route-Template CRD You can modify existing `httproutetemplates` templates at any time. Note that previously created HTTP routing resources based on this template aren’t updated automatically. To update existing HTTP routing resources after changing the template, perform a redeployment of the Mule app from the Anypoint control plane. For example, if you update the base domain, which requires changing the endpoint for the ingress template, remove the old endpoint and add the new one as part of the application redeployment. ## Create Role and RoleBindings If the ingress resource is not the standard ingress type, create a Role or RoleBinding to give the Runtime Fabric agent service account the necessary privileges to create an ingress resource. This example shows the creation of Role and RoleBinding. For OpenShift routes and other similar configurations, create Roles and RoleBindings that are tailored to your specific needs. You can either create these in all application namespaces or use ClusterRole and ClusterRoleBindings, depending on your preferences and any restrictions you have in place. Role example: apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: rtf-manage-routes namespace: rules: - apiGroups: - route.openshift.io resources: - routes - routes/custom-host verbs: - '\*' RoleBinding example: apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: manage-routes namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: rtf-manage-routes subjects: - kind: ServiceAccount name: rtf-agent namespace: ## Frequently Asked Questions **Does Runtime Fabric support the existing ingress templates?** Yes, Runtime Fabric supports both old and new templates. However, it is recommended to use the new HTTP Route templates to configure the ingress for your Mule application deployments. **What happens if there is a BaseEndpoint or URL collision between two HTTP Route CRs?** If there are ingress templates and HTTPRoute templates with the same baseEndpoints, the new HttpRoute CR always takes precedence, and the old ingress serves as a fallback. **What are some placeholder usage guidelines?** Placeholders are not mandatory, but use them to make the HTTP Route template more generic. Placeholders are specific to the templates. This means that placeholders used in ingress templates cannot be used in route templates. For example, the `app-name` placeholder: - In an ingress template the placeholder is replaced by the application name. - In a route template the placeholder is treated as a string `app-name`. ## See Also - [Configuring Ingress in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/configure-ingress) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Ingress with HTTP Route-Template Custom Resource in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Configure ingress support for Mule apps on the Anypoint Runtime Fabric platform using the HTTP route-template custom resource. ## Benefits of Ingress Configuration with the HTTP Route-Template Custom Resource Current ingress support for Mule apps on the Runtime Fabric platform is confined to [Kubernetes ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) resources, which restricts usage to cloud vendor-native HTTP routing solutions, such as OpenShift Routes on OpenShift clusters, Istio, or Kubernetes Gateway API. To address this limitation, Runtime Fabric supports a custom resource `httproutetemplates.rtf.mulesoft.com` template. Use the HTTP route-template custom resource in Runtime Fabric to define and implement custom routing configurations. With this approach, you can take advantage of compatibility with a range of ingress controllers and cloud-native routing mechanisms, including support for: - Subdomain based routing - Path based routing - Header based routing - Rate limiting ## HTTP Route-Template Custom-Resource Placeholders Runtime Fabric provides placeholder properties for HTTP route templates. Placeholders use Handlebars-style syntax, such as `{{ .ApplicationName }}`. Cluster administrators use them in the HTTP route-template custom resource (`httproutetemplates.rtf.mulesoft.com`). Application developers can enter the same placeholders in the Anypoint Runtime Manager UI when configuring public endpoints for a Mule application deployment (for example in host or path fields). Placeholder properties are replaced with deployment-specific values when the application deploys. The following property placeholders are available:
PropertyDescription

{{ .ResourceName }}

Runtime Fabric generated unique routing resource name

{{ .ApplicationName }}

Application deployment name

{{ .Namespace }}

Namespace of the Mule app deployment

{{ .Service.Name }}

Backend service name of the application deployment

{{ .Service.PortName }}

Backend service port name of the application deployment

{{ .Service.Port }}

Backend service port number of the application deployment

{{ .Host }}

Host value from the public endpoint of application deployment

{{ .Path }}

Path value from the public endpoint of application deployment

{{ .OrganizationID }}

Organization ID of the application deployment

{{ .EnvironmentID }}

Environment ID of the application deployment

{{ .UniqueID }}

Unique ID placeholder to create a unique application URL

Use the `{{ .ResourceName }}` placeholder to ensure the uniqueness of the name of the HTTP routing resource being created, especially if the deployment has multiple endpoints. It is recommended to use this placeholder; otherwise, you need to manually ensure the resource name uniqueness. Kubernetes enforces that the names of resources must be unique within a namespace, but not across namespaces. For more details, refer to [Namespaces Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/#when-to-use-multiple-namespaces). For example: resources: - | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: {{ .ResourceName }} The resulting HTTP routing (ingress in the previous example) resource name for the `myapp` deployment will be `myapp-2048497571` Use the `{{ .ApplicationName }}` placeholder to replace with the actual name of application deployment. For example: resources: - | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: labels: app-name: {{ .ApplicationName }} Use the `{{ .UniqueID }}` placeholder to create a unique application URL. This is useful if you want to deploy two applications with same name from different business groups. For example, if you use `/api/{{ .UniqueID }}.com` in the path section of the ingress template, the resulting endpoint will be similar to `/api/7jkbic.com`. > [!NOTE] In the HTTP route-template custom resource, use placeholders in the `resources` section; > Runtime Fabric substitutes values there when it generates Kubernetes routing resources (ingress, > routes, gateway HTTPRoute, and similar). The Anypoint Runtime Manager UI resolves the same supported placeholders when you configure public endpoints, so values you enter in the UI are consistent with the template at deployment time. Supported placeholders in the UI replace older, unofficial patterns. For example, to inject the application name dynamically, use `{{ .ApplicationName }}` instead of legacy ingress-style strings such as `app-name`. > [!IMPORTANT] For HTTP route templates, the Runtime Manager UI no longer treats legacy strings like > `app-name` as placeholders. If you redeploy an application that still uses the old syntax in a > host or path, that string is left as literal text. For example, for an application named `test-app`, configuring: `[https://test-app.testrtf.com/app-name](https://test-app.testrtf.com/app-name)` Previously produced: `[https://test-app.testrtf.com/test-app](https://test-app.testrtf.com/test-app)` With the current behavior, the same input produces: `[https://test-app.testrtf.com/app-name](https://test-app.testrtf.com/app-name)` To get the application name in the URL, use `[https://test-app.testrtf.com/{{](https://test-app.testrtf.com/{{) .ApplicationName }}` (or the appropriate segment for your template). ## How the HTTP Route-Template Custom Resource Works in Runtime Fabric This diagram provides an overview of how to configure ingress using an HTTP route-template custom resource in Runtime Fabric: ![HTTP route-template diagram overview](/mulesoft/current/en-us/runtime-fabric/latest/_images/ingress-http-diagram.png) The `httproutetemplates` resource applies only to new Mule app deployments created after the template resource is set up. Existing deployments are unaffected. After applying an httproutetemplate, it is applied for all subsequent application deployments. The `httproutetemplates` resource enables you to configure routes like these: - `baseEndpoints` Endpoints associated with the routing resources defined in the template. These endpoints are synchronized by Runtime Fabric with the Anypoint control plane. Application developers select one or more endpoints during deployment and optionally customize the path and subdomain when applicable. - `resources` A list of strings, each declaring a Kubernetes routing resource. To get the CRD of key elements available to configure for the template, retrieve the Kubernetes specification by running this command: kubectl get crd httproutetemplates.rtf.mulesoft.com -o yaml ## HTTP Route-Template Examples Review these HTTP route-templates examples for Kubernetes ingress, OpenShift routes, and Kubernetes Gateway API (HTTPRoute). ### Example for Kubernetes Ingress This example shows an HTTP route-template resource for Kubernetes ingress: apiVersion: rtf.mulesoft.com/v1 kind: HTTPRouteTemplate metadata: name: example-template-ingress namespace: rtf spec: baseEndpoints: #(1) - https://\*.example.com - https://example.com resources: #(2) - | apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: {{ .ResourceName }} namespace: {{ .Namespace }} labels: annotations: spec: ingressClassName: nginx tls: - hosts: - {{ .Host }} secretName: testsecret-tls rules: - host: {{ .Host }} #(3) http: paths: - pathType: Prefix path: {{ .Path }} #(4) backend: service: name: {{ .Service.Name }} port: name: {{ .Service.PortName }} 1. Hosts or domains used for mapping the public endpoints configured on the Mule app deployment. 2. One or more Kubernetes routing resources, such as an Ingress resource. 3. Host or domain from the Mule app’s public URL. 4. Path from the Mule app’s public URL. > [!NOTE] For Runtime fabric software entire `resources` is a list of strings and gets consumed as > is. So you dont have to configure any special prefix like `rtf-` for IngressClassName On the Anypoint Runtime Manager UI page, application developers see the following Base Endpoints to configure their app deployment. ![Ingress configuration window in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-ingress-rtm.png) Finally, when this application is deployed to the Runtime Fabric target, each endpoint will result in the creation of an ingress resource. In this example, the ingress resource generated corresponds to the `myapp.example.com` host endpoint: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: meta.helm.sh/release-name: myapp meta.helm.sh/release-namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c creationTimestamp: "2025-01-10T17:08:41Z" generation: 1 labels: app.kubernetes.io/managed-by: Helm name: myapp-1699085749 namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c resourceVersion: "45959978" uid: ee20766e-0d6e-4d19-8770-08250458d659 spec: ingressClassName: nginx rules: - host: myapp.example.com http: paths: - backend: service: name: myapp port: name: http path: / pathType: Prefix tls: - hosts: - myapp.example.com secretName: testsecret-tls In this example, the ingress resource generated corresponds to the `example.com` host endpoint: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: meta.helm.sh/release-name: myapp meta.helm.sh/release-namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c creationTimestamp: "2025-01-10T17:08:41Z" generation: 1 labels: app.kubernetes.io/managed-by: Helm name: myapp-860107349 namespace: c07871d0-bfa6-4998-ac9f-a45fdc944a9c resourceVersion: "45959979" uid: e51d488b-9cf5-4c03-8adf-f0ea50366e31 spec: ingressClassName: nginx rules: - host: example.com http: paths: - backend: service: name: myapp port: name: http path: / pathType: Prefix tls: - hosts: - example.com secretName: testsecret-tls ### Example for OpenShift Routes This example shows an HTTP route-template resource for OpenShift routes: apiVersion: rtf.mulesoft.com/v1 kind: HTTPRouteTemplate metadata: name: example-template-openshiftroute namespace: rtf spec: baseEndpoints: - https://example.com/ resources: - | apiVersion: route.openshift.io/v1 kind: Routes metadata: name: {{ .ResourceName }} namespace: {{ .Namespace }} spec: host: {{ .Host }} path: {{ .Path }} to: kind: Service name: {{ .Service.Name }} tls: termination: edge key: |- -----BEGIN PRIVATE KEY----- \[...\] -----END PRIVATE KEY----- certificate: |- -----BEGIN CERTIFICATE----- \[...\] -----END CERTIFICATE----- caCertificate: |- -----BEGIN CERTIFICATE----- \[...\] -----END CERTIFICATE----- ### Example for Kubernetes Gateway API This example shows an HTTP route-template resource for Kubernetes Gateway API (HTTPRoute): apiVersion: rtf.mulesoft.com/v1 kind: HTTPRouteTemplate metadata: name: example-template-gateway namespace: rtf spec: baseEndpoints: - https://example.com resources: - | apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: {{ .ResourceName }} namespace: {{ .Namespace }} spec: parentRefs: - kind: Gateway name: cluster-gateway hostnames: - {{ .Host }} rules: - matches: - path: type: PathPrefix value: {{ .Path }} backendRefs: - name: {{ .Service.Name }} port: {{ .Service.Port }} > [!NOTE] You are responsible for the configuration of the Kubernetes Gateway resources and allowing > HTTPRoutes from the route’s namespace to be attached. ## Use TLS in the HTTP Route-Template Custom Resource To use TLS in the routing resources in an HTTP route template, you may need to create a TLS secret in the Runtime Fabric namespace. For details, refer to the [Kubernetes TLS](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) documentation. To configure the Runtime Fabric to manage the secrets lifecycle (create, update, and delete) across all application namespace, use the `rtf.mulesoft.com/synchronized: "true"` label on the TLS secret. For example: apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: rtf labels: rtf.mulesoft.com/synchronized: "true" data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls Using this label is highly recommended for secrets management. If you don’t add this label, you must manually update the secret in each namespace. ## Modify an Existing HTTP Route-Template CRD You can modify existing `httproutetemplates` templates at any time. Note that previously created HTTP routing resources based on this template aren’t updated automatically. To update existing HTTP routing resources after changing the template, perform a redeployment of the Mule app from the Anypoint control plane. For example, if you update the base domain, which requires changing the endpoint for the ingress template, remove the old endpoint and add the new one as part of the application redeployment. ## Create Role and RoleBindings If the ingress resource is not the standard ingress type, create a Role or RoleBinding to give the Runtime Fabric agent service account the necessary privileges to create an ingress resource. This example shows the creation of Role and RoleBinding. For OpenShift routes and other similar configurations, create Roles and RoleBindings that are tailored to your specific needs. You can either create these in all application namespaces or use ClusterRole and ClusterRoleBindings, depending on your preferences and any restrictions you have in place. Role example: apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: rtf-manage-routes namespace: rules: - apiGroups: - route.openshift.io resources: - routes - routes/custom-host verbs: - '\*' RoleBinding example: apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: manage-routes namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: rtf-manage-routes subjects: - kind: ServiceAccount name: rtf-agent namespace: ## Frequently Asked Questions **Does Runtime Fabric support the existing ingress templates?** Yes, Runtime Fabric supports both old and new templates. However, it is recommended to use the new HTTP Route templates to configure the ingress for your Mule application deployments. **What happens if there is a BaseEndpoint or URL collision between two HTTP Route CRs?** If there are ingress templates and HTTPRoute templates with the same baseEndpoints, the new HttpRoute CR always takes precedence, and the old ingress serves as a fallback. **What are some placeholder usage guidelines?** Placeholders are not mandatory, but use them to make the HTTP Route template more generic. Ingress templates and HTTP route templates use different placeholder conventions. For example, the legacy ingress-style string `app-name` is still replaced by the application name in ingress templates. For HTTP route templates, use Handlebars-style placeholders such as `{{ .ApplicationName }}` in the custom resource and in Runtime Manager; the UI does not replace bare `app-name` strings for HTTP route templates. ## See Also - [Configuring Ingress in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/configure-ingress) --- product: Runtime Fabric version: 2.10 --- # Configuring Kubernetes for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Kubernetes for Anypoint Runtime Fabric, review the following topics: - [Kubernetes (K8s) Best Practices for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/rtf-k8s-practices) Review scalability benchmarks and cluster configurations best practices. - [Kubernetes Hardening Guide](https://docs.mulesoft.com/runtime-fabric/2.10/kubernetes-hardening-guide) Review security opportunities associated with setting up and securing a Kubernetes cluster based on the Kubernetes Hardening Guide. - [Customizing Mule Apps Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.10/customize-kubernetes-crd) Customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. - [Runtime Fabric Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.10/rtf-kubernetes-permissions) Configure Kubernetes permissions for Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.11 --- # Configuring Kubernetes for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Kubernetes for Anypoint Runtime Fabric, review these topics: - [Kubernetes (K8s) Best Practices for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/rtf-k8s-practices) Review scalability benchmarks and cluster configurations best practices. - [Kubernetes Hardening Guide](https://docs.mulesoft.com/runtime-fabric/2.11/kubernetes-hardening-guide) Review security opportunities associated with setting up and securing a Kubernetes cluster based on the Kubernetes Hardening Guide. - [Customizing Mule Apps Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.11/customize-kubernetes-crd) Customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. - [Runtime Fabric Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.11/rtf-kubernetes-permissions) Configure Kubernetes permissions for Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.6 --- # Configuring Kubernetes for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Kubernetes for Anypoint Runtime Fabric, review the following topics: - [Kubernetes (K8s) Best Practices for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/rtf-k8s-practices) Review scalability benchmarks and cluster configurations best practices. - [Kubernetes Hardening Guide](https://docs.mulesoft.com/runtime-fabric/2.6/kubernetes-hardening-guide) Review security opportunities associated with setting up and securing a Kubernetes cluster based on the Kubernetes Hardening Guide. - [Customizing Mule Apps Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.6/customize-kubernetes-crd) Customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. - [Runtime Fabric Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.6/rtf-kubernetes-permissions) Configure Kubernetes permissions for Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.7 --- # Configuring Kubernetes for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Kubernetes for Anypoint Runtime Fabric, review the following topics: - [Kubernetes (K8s) Best Practices for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/rtf-k8s-practices) Review scalability benchmarks and cluster configurations best practices. - [Kubernetes Hardening Guide](https://docs.mulesoft.com/runtime-fabric/2.7/kubernetes-hardening-guide) Review security opportunities associated with setting up and securing a Kubernetes cluster based on the Kubernetes Hardening Guide. - [Customizing Mule Apps Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.7/customize-kubernetes-crd) Customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. - [Runtime Fabric Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.7/rtf-kubernetes-permissions) Configure Kubernetes permissions for Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.8 --- # Configuring Kubernetes for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Kubernetes for Anypoint Runtime Fabric, review the following topics: - [Kubernetes (K8s) Best Practices for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/rtf-k8s-practices) Review scalability benchmarks and cluster configurations best practices. - [Kubernetes Hardening Guide](https://docs.mulesoft.com/runtime-fabric/2.8/kubernetes-hardening-guide) Review security opportunities associated with setting up and securing a Kubernetes cluster based on the Kubernetes Hardening Guide. - [Customizing Mule Apps Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.8/customize-kubernetes-crd) Customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. - [Runtime Fabric Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.8/rtf-kubernetes-permissions) Configure Kubernetes permissions for Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.9 --- # Configuring Kubernetes for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Kubernetes for Anypoint Runtime Fabric, review the following topics: - [Kubernetes (K8s) Best Practices for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/rtf-k8s-practices) Review scalability benchmarks and cluster configurations best practices. - [Kubernetes Hardening Guide](https://docs.mulesoft.com/runtime-fabric/2.9/kubernetes-hardening-guide) Review security opportunities associated with setting up and securing a Kubernetes cluster based on the Kubernetes Hardening Guide. - [Customizing Mule Apps Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.9/customize-kubernetes-crd) Customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. - [Runtime Fabric Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.9/rtf-kubernetes-permissions) Configure Kubernetes permissions for Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/hardening-runtime-fabric) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Kubernetes for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Kubernetes for Anypoint Runtime Fabric, review the following topics: - [Kubernetes (K8s) Best Practices for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/rtf-k8s-practices) Review scalability benchmarks and cluster configurations best practices. - [Kubernetes Hardening Guide](https://docs.mulesoft.com/runtime-fabric/latest/kubernetes-hardening-guide) Review security opportunities associated with setting up and securing a Kubernetes cluster based on the Kubernetes Hardening Guide. - [Customizing Mule Apps Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd) Customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. - [Runtime Fabric Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/latest/rtf-kubernetes-permissions) Configure Kubernetes permissions for Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.10 --- # Configuring Persistence Gateway with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides Persistence Gateway, which enables Mule applications deployed to a Mule runtime instance to store and share data across application replicas and restarts. > [!NOTE] You can also use the Mule Maven plugin version 3.5.4 or later to enable persistent object > stores for Runtime Fabric deployments. ## Using Persistence Gateway in a Mule Application After Persistence Gateway is configured in Anypoint Runtime Fabric, it is available for Mule applications deployed to Mule runtime engine, version 4.2.1 or later. When configured, users can select **Use Persistent Object Storage** when deploying an application using Runtime Manager. See [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-runtime-fabric) for more information. Mule applications use the Object Store v2 REST API via the Object Store Connector to connect to Persistence Gateway. This enables you to deploy to both Anypoint Runtime Fabric and CloudHub without having to modify your Mule application. > [!NOTE] After deleting an application, persistent data may not be deleted immediately. Runtime > Fabric cleans persistence data every 60 minutes. ## Persistent Gateway Limits The following table lists the limits on the data stored by Persistence Gateway:
LimitDescription

Maximum TTL.

The amount of time data is stored in Persistence Gateway, value is set to 30 days.

## Before You Begin Before enabling Persistence Gateway, ensure that you have: - Created a PostgreSQL database to serve as the data source for data stored by Persistence Gateway. This database must be compatible with a [supported version of PostgreSQL](https://www.postgresql.org/support/versioning/) that does not reserve the `partition` keyword. - Granted the PostgreSQL user CREATE, INSERT, SELECT, UPDATE, and DELETE privileges. > [!NOTE] Only plain text connections to the database are supported. ## Configure Persistence Gateway During configuration, Persistence Gateway creates the required database schema. Afterwards, when an application deployed to Runtime Fabric is configured to use persistent object storage, the Persistence Gateway writes the necessary rows to the database. To configure Persistence Gateway, you must create a Kubernetes custom resource that allows the cluster to connect to your persistence data store. 1. Create a Kubernetes secret: kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename' > [!IMPORTANT] > > - Do not change `--from-literal=persistence-gateway-creds`. You can replace `` > with any value you want to use for the secret. > > - Do not use the "@" character in the database username. > > - If your PostgresSQL user account password contains special characters, make sure to encode > your connection URL before pushing it as Kubernetes secret. 2. Create a custom resource for your data store: 1. Copy the custom resource template from [Kubernetes Custom Resource Template](#k8-custom-resource-template) to a file called `custom-resource.yaml`. 2. Ensure the value of `secretRef: name` matches the `name` field defined in your Kubernetes secret file. 3. Modify other fields of the custom resource template as required for your environment. 4. Run `kubectl apply -f custom-resource.yaml`. 3. Check the logs of the Persistence Gateway pod to ensure it can communicate with the database: ```copy kubectl get pods -n rtf ``` Look for pods with the name prefix `persistence-gateway` ```copy kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -n rtf ``` The output of this command should be similar to the following: 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## Persistence Gateway with Authorized Namespaces If you use [authorized namespace](https://docs.mulesoft.com/runtime-fabric/2.10/install-helm#optional-configure-authorized-namespaces) and want to use persistence gateway, edit the RoleBinding by adding a new `rtf-persistence-gateway` subject: ```copy subjects: - kind: ServiceAccount name: rtf-persistence-gateway namespace: ``` ## Kubernetes Custom Resource Template Use the example template below to create a Kubernetes custom resource. This custom resource enables the Kubernetes cluster to connect to your data store. ```yaml apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi ``` Modify the following fields based on your environment:
FieldDescriptionDefault Value

kind

The type of custom resource. The only supported value is PersistenceGateway.

PersistenceGateway

metadata.name

The internal identifier for this custom resource. The value for this field should be default.

default

metadata.namespace

The namespace where the secret is applied. The supported value is rtf.

rtf

spec.objectStore.backendDriver

The driver used by the data store. Only postgresql is supported.

postgresql

spec.objectStore.maxBackendConnectionPool

The maximum number of simultaneous open connections to the data store.

20

spec.objectStore.replicas

The number of replicas of Persistence Gateway.

2

spec.objectStore.resources.limits.cpu

The CPU resource limits for the Persistence Gateway pods.

250m

spec.objectStore.resources.limits.memory

The memory resource limits for the Persistence Gateway pods.

150Mi

spec.objectStore.resources.requests.cpu

The CPU resource requests for the Persistence Gateway pods.

200m

spec.objectStore.resources.requests.memory

The memory resource requests for the Persistence Gateway pods.

75Mi

spec.objectStore.secretRef.name

The name of the Persistence Gateway credentials defined in the Kubernetes secret file.

persistence-gateway-creds

> [!NOTE] The default CPU, memory, and limit values are based on a small number of deployed Mule > applications. Modify these values based on the requirements of your environment. ## Persistence Gateway Application Data Persistence Gateway stores application data using the following two tables: ```copy CREATE TABLE IF NOT EXISTS stores ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, org_id VARCHAR(255) NOT NULL, env_id VARCHAR(255) NOT NULL, default_ttl_seconds int NOT NULL, is_fixed_ttl bool NOT NULL, CONSTRAINT UK_stores UNIQUE (name, org_id, env_id) ); CREATE TABLE IF NOT EXISTS items ( store_id INT NOT NULL REFERENCES stores(id), key VARCHAR(255) NOT NULL, partition VARCHAR(255) NOT NULL, value_type VARCHAR(10) NOT NULL, number_value integer, string_value text, binary_value bytea, last_updated timestamp, is_fixed_ttl bool NOT NULL, ttl timestamp NOT NULL, CONSTRAINT UK_items UNIQUE (key, store_id, partition) ); CREATE INDEX IF NOT EXISTS IDX_items_ttl ON items(ttl) ; ``` To migrate the persistent data from one cluster to another, backup these two tables entirely from the source cluster and recreate them on the target one database. Do not to have applications deployed during this process on both clusters to prevent unexpected results. If you’re using a version of the Runtime Fabric agent higher than 2.6.22, the `id` parameter in the `CREATE TABLE IF NOT EXISTS items` statement no longer applies. For previous versions of the Runtime Fabric agent 2.6.22, the `id` parameter is available in the items table. ## See Also - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-runtime-fabric) - [Deploy Applications to Runtime Fabric Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) --- product: Runtime Fabric version: 2.11 --- # Configuring Persistence Gateway with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides Persistence Gateway, which enables Mule applications deployed to a Mule runtime instance to store and share data across application replicas and restarts. > [!NOTE] You can also use the Mule Maven plugin version 3.5.4 or later to enable persistent object > stores for Runtime Fabric deployments. ## Using Persistence Gateway in a Mule Application After Persistence Gateway is configured in Anypoint Runtime Fabric, it is available for Mule applications deployed to Mule runtime engine, version 4.2.1 or later. When configured, users can select **Use Persistent Object Storage** when deploying an application using Runtime Manager. See [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-runtime-fabric) for more information. Mule applications use the Object Store v2 REST API via the Object Store Connector to connect to Persistence Gateway. This enables you to deploy to both Anypoint Runtime Fabric and CloudHub without having to modify your Mule application. > [!NOTE] After deleting an application, persistent data may not be deleted immediately. Runtime > Fabric cleans persistence data every 60 minutes. ## Persistent Gateway Limits The following table lists the limits on the data stored by Persistence Gateway:
LimitDescription

Maximum TTL.

The amount of time data is stored in Persistence Gateway, value is set to 30 days.

## Before You Begin Before enabling Persistence Gateway, ensure that you have: - Created a PostgreSQL database to serve as the data source for data stored by Persistence Gateway. This database must be compatible with a [supported version of PostgreSQL](https://www.postgresql.org/support/versioning/) that does not reserve the `partition` keyword. - Granted the PostgreSQL user CREATE, INSERT, SELECT, UPDATE, and DELETE privileges. > [!NOTE] Only plain text connections to the database are supported. ## Configure Persistence Gateway During configuration, Persistence Gateway creates the required database schema. Afterwards, when an application deployed to Runtime Fabric is configured to use persistent object storage, the Persistence Gateway writes the necessary rows to the database. To configure Persistence Gateway, you must create a Kubernetes custom resource that allows the cluster to connect to your persistence data store. 1. Create a Kubernetes secret: kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename' > [!IMPORTANT] > > - Do not change `--from-literal=persistence-gateway-creds`. You can replace `` > with any value you want to use for the secret. > > - Do not use the "@" character in the database username. > > - If your PostgresSQL user account password contains special characters, make sure to encode > your connection URL before pushing it as Kubernetes secret. 2. Create a custom resource for your data store: 1. Copy the custom resource template from [Kubernetes Custom Resource Template](#k8-custom-resource-template) to a file called `custom-resource.yaml`. 2. Ensure the value of `secretRef: name` matches the `name` field defined in your Kubernetes secret file. 3. Modify other fields of the custom resource template as required for your environment. 4. Run `kubectl apply -f custom-resource.yaml`. 3. Check the logs of the Persistence Gateway pod to ensure it can communicate with the database: ```copy kubectl get pods -n rtf ``` Look for pods with the name prefix `persistence-gateway` ```copy kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -n rtf ``` The output of this command should be similar to this: 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## Persistence Gateway with Authorized Namespaces If you use [authorized namespace](https://docs.mulesoft.com/runtime-fabric/2.11/install-helm#optional-configure-authorized-namespaces) and want to use persistence gateway, edit the RoleBinding by adding a new `rtf-persistence-gateway` subject: ```copy subjects: - kind: ServiceAccount name: rtf-persistence-gateway namespace: ``` ## Kubernetes Custom Resource Template Use the example template below to create a Kubernetes custom resource. This custom resource enables the Kubernetes cluster to connect to your data store. ```yaml apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway ``` Modify these fields based on your environment:
FieldDescriptionDefault Value

kind

The type of custom resource. The only supported value is PersistenceGateway.

PersistenceGateway

metadata.name

The internal identifier for this custom resource. The value for this field should be default.

default

metadata.namespace

The namespace where the secret is applied. The supported value is rtf.

rtf

spec.objectStore.backendDriver

The driver used by the data store. Only postgresql is supported.

postgresql

spec.objectStore.maxBackendConnectionPool

The maximum number of simultaneous open connections to the data store.

20

spec.objectStore.replicas

The number of replicas of Persistence Gateway.

2

spec.objectStore.resources.limits.cpu

The CPU resource limits for the Persistence Gateway pods.

250m

spec.objectStore.resources.limits.memory

The memory resource limits for the Persistence Gateway pods.

150Mi

spec.objectStore.resources.requests.cpu

The CPU resource requests for the Persistence Gateway pods.

200m

spec.objectStore.resources.requests.memory

The memory resource requests for the Persistence Gateway pods.

75Mi

spec.objectStore.secretRef.name

The name of the Persistence Gateway credentials defined in the Kubernetes secret file.

persistence-gateway-creds

spec.objectStore.topologySpreadConstraints.maxSkew

Describes the degree to which pods may be unevenly distributed.

1

spec.objectStore.topologySpreadConstraints.topologyKey

Key that understands which criteria to use to distribute pods.

topology.kubernetes.io/zone

spec.objectStore.topologySpreadConstraints.whenUnsatisfiable

Indicates how to deal with a pod if it doesn’t satisfy the spread constraint.

ScheduleAnyway

> [!NOTE] The default CPU, memory, and limit values are based on a small number of deployed Mule > applications. Modify these values based on the requirements of your environment. ## Persistence Gateway Application Data Persistence Gateway stores application data using these two tables: ```copy CREATE TABLE IF NOT EXISTS stores ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, org_id VARCHAR(255) NOT NULL, env_id VARCHAR(255) NOT NULL, default_ttl_seconds int NOT NULL, is_fixed_ttl bool NOT NULL, CONSTRAINT UK_stores UNIQUE (name, org_id, env_id) ); CREATE TABLE IF NOT EXISTS items ( store_id INT NOT NULL REFERENCES stores(id), key VARCHAR(255) NOT NULL, partition VARCHAR(255) NOT NULL, value_type VARCHAR(10) NOT NULL, number_value integer, string_value text, binary_value bytea, last_updated timestamp, is_fixed_ttl bool NOT NULL, ttl timestamp NOT NULL, CONSTRAINT UK_items UNIQUE (key, store_id, partition) ); CREATE INDEX IF NOT EXISTS IDX_items_ttl ON items(ttl) ; ``` To migrate the persistent data from one cluster to another, backup these two tables entirely from the source cluster and recreate them on the target one database. Do not to have applications deployed during this process on both clusters to prevent unexpected results. If you’re using a version of the Runtime Fabric agent higher than 2.6.22, the `id` parameter in the `CREATE TABLE IF NOT EXISTS items` statement no longer applies. For previous versions of the Runtime Fabric agent 2.6.22, the `id` parameter is available in the items table. ## See Also - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-runtime-fabric) - [Deploy Applications to Runtime Fabric Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) --- product: Runtime Fabric version: 2.6 --- # Configuring Persistence Gateway with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides Persistence Gateway, which enables Mule applications deployed to a Mule runtime instance to store and share data across application replicas and restarts. > [!NOTE] You can also use the Mule Maven plugin version 3.5.4 or later to enable persistent object > stores for Runtime Fabric deployments. ## Using Persistence Gateway in a Mule Application After Persistence Gateway is configured in Anypoint Runtime Fabric, it is available for Mule applications deployed to Mule runtime engine, version 4.2.1 or later. When configured, users can select **Use Persistent Object Storage** when deploying an application using Runtime Manager. See [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-runtime-fabric) for more information. Mule applications use the Object Store v2 REST API via the Object Store Connector to connect to Persistence Gateway. This enables you to deploy to both Anypoint Runtime Fabric and CloudHub without having to modify your Mule application. > [!NOTE] After deleting an application, persistent data may not be deleted immediately. Runtime > Fabric cleans persistence data every 60 minutes. ## Persistent Gateway Limits The following table lists the limits on the data stored by Persistence Gateway:
LimitDescription

Maximum TTL.

The amount of time data is stored in Persistence Gateway, value is set to 30 days.

## Before You Begin Before enabling Persistence Gateway, ensure that you have: - Created a PostgreSQL database to serve as the data source for data stored by Persistence Gateway. This database must be compatible with a [supported version of PostgreSQL](https://www.postgresql.org/support/versioning/) that does not reserve the `partition` keyword. - Granted the PostgreSQL user CREATE, INSERT, SELECT, UPDATE, and DELETE privileges. > [!NOTE] Only plain text connections to the database are supported. ## Configure Persistence Gateway During configuration, Persistence Gateway creates the required database schema. Afterwards, when an application deployed to Runtime Fabric is configured to use persistent object storage, the Persistence Gateway writes the necessary rows to the database. To configure Persistence Gateway, you must create a Kubernetes custom resource that allows the cluster to connect to your persistence data store. 1. Create a Kubernetes secret: kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename' > [!IMPORTANT] > > - Do not change `--from-literal=persistence-gateway-creds`. You can replace `` > with any value you want to use for the secret. > > - Do not use the "@" character in the database username. > > - If your PostgresSQL user account password contains special characters, make sure to encode > your connection URL before pushing it as Kubernetes secret. 2. Create a custom resource for your data store: 1. Copy the custom resource template from [Kubernetes Custom Resource Template](#k8-custom-resource-template) to a file called `custom-resource.yaml`. 2. Ensure the value of `secretRef: name` matches the `name` field defined in your Kubernetes secret file. 3. Modify other fields of the custom resource template as required for your environment. 4. Run `kubectl apply -f custom-resource.yaml`. 3. Check the logs of the Persistence Gateway pod to ensure it can communicate with the database: ```copy kubectl get pods -n rtf ``` Look for pods with the name prefix `persistence-gateway` ```copy kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -n rtf ``` The output of this command should be similar to the following: 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## Persistence Gateway with Authorized Namespaces If you use [authorized namespace](https://docs.mulesoft.com/runtime-fabric/2.6/install-helm#optional-configure-authorized-namespaces) and want to use persistence gateway, edit the RoleBinding by adding a new `rtf-persistence-gateway` subject: ```copy subjects: - kind: ServiceAccount name: rtf-persistence-gateway namespace: ``` ## Kubernetes Custom Resource Template Use the example template below to create a Kubernetes custom resource. This custom resource enables the Kubernetes cluster to connect to your data store. ```yaml apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi ``` Modify the following fields based on your environment:
FieldDescriptionDefault Value

kind

The type of custom resource. The only supported value is PersistenceGateway.

PersistenceGateway

metadata.name

The internal identifier for this custom resource. The value for this field should be default.

default

metadata.namespace

The namespace where the secret is applied. The supported value is rtf.

rtf

spec.objectStore.backendDriver

The driver used by the data store. Only postgresql is supported.

postgresql

spec.objectStore.maxBackendConnectionPool

The maximum number of simultaneous open connections to the data store.

20

spec.objectStore.replicas

The number of replicas of Persistence Gateway.

2

spec.objectStore.resources.limits.cpu

The CPU resource limits for the Persistence Gateway pods.

250m

spec.objectStore.resources.limits.memory

The memory resource limits for the Persistence Gateway pods.

150Mi

spec.objectStore.resources.requests.cpu

The CPU resource requests for the Persistence Gateway pods.

200m

spec.objectStore.resources.requests.memory

The memory resource requests for the Persistence Gateway pods.

75Mi

spec.objectStore.secretRef.name

The name of the Persistence Gateway credentials defined in the Kubernetes secret file.

persistence-gateway-creds

> [!NOTE] The default CPU, memory, and limit values are based on a small number of deployed Mule > applications. Modify these values based on the requirements of your environment. ## Persistence Gateway Application Data Persistence Gateway stores application data using the following two tables: ```copy CREATE TABLE IF NOT EXISTS stores ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, org_id VARCHAR(255) NOT NULL, env_id VARCHAR(255) NOT NULL, default_ttl_seconds int NOT NULL, is_fixed_ttl bool NOT NULL, CONSTRAINT UK_stores UNIQUE (name, org_id, env_id) ); CREATE TABLE IF NOT EXISTS items ( id SERIAL PRIMARY KEY, store_id INT NOT NULL REFERENCES stores(id), key VARCHAR(255) NOT NULL, partition VARCHAR(255) NOT NULL, value_type VARCHAR(10) NOT NULL, number_value integer, string_value text, binary_value bytea, last_updated timestamp, is_fixed_ttl bool NOT NULL, ttl timestamp NOT NULL, CONSTRAINT UK_items UNIQUE (key, store_id, partition) ); CREATE INDEX IF NOT EXISTS IDX_items_ttl ON items(ttl) ; ``` To migrate the persistent data from one cluster to another, backup these two tables entirely from the source cluster and recreate them on the target one database. Do not to have applications deployed during this process on both clusters to prevent unexpected results. ## See Also - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-runtime-fabric) - [Deploy Applications to Runtime Fabric Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) --- product: Runtime Fabric version: 2.7 --- # Configuring Persistence Gateway with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides Persistence Gateway, which enables Mule applications deployed to a Mule runtime instance to store and share data across application replicas and restarts. > [!NOTE] You can also use the Mule Maven plugin version 3.5.4 or later to enable persistent object > stores for Runtime Fabric deployments. ## Using Persistence Gateway in a Mule Application After Persistence Gateway is configured in Anypoint Runtime Fabric, it is available for Mule applications deployed to Mule runtime engine, version 4.2.1 or later. When configured, users can select **Use Persistent Object Storage** when deploying an application using Runtime Manager. See [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-runtime-fabric) for more information. Mule applications use the Object Store v2 REST API via the Object Store Connector to connect to Persistence Gateway. This enables you to deploy to both Anypoint Runtime Fabric and CloudHub without having to modify your Mule application. > [!NOTE] After deleting an application, persistent data may not be deleted immediately. Runtime > Fabric cleans persistence data every 60 minutes. ## Persistent Gateway Limits The following table lists the limits on the data stored by Persistence Gateway:
LimitDescription

Maximum TTL.

The amount of time data is stored in Persistence Gateway, value is set to 30 days.

## Before You Begin Before enabling Persistence Gateway, ensure that you have: - Created a PostgreSQL database to serve as the data source for data stored by Persistence Gateway. This database must be compatible with a [supported version of PostgreSQL](https://www.postgresql.org/support/versioning/) that does not reserve the `partition` keyword. - Granted the PostgreSQL user CREATE, INSERT, SELECT, UPDATE, and DELETE privileges. > [!NOTE] Only plain text connections to the database are supported. ## Configure Persistence Gateway During configuration, Persistence Gateway creates the required database schema. Afterwards, when an application deployed to Runtime Fabric is configured to use persistent object storage, the Persistence Gateway writes the necessary rows to the database. To configure Persistence Gateway, you must create a Kubernetes custom resource that allows the cluster to connect to your persistence data store. 1. Create a Kubernetes secret: kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename' > [!IMPORTANT] > > - Do not change `--from-literal=persistence-gateway-creds`. You can replace `` > with any value you want to use for the secret. > > - Do not use the "@" character in the database username. > > - If your PostgresSQL user account password contains special characters, make sure to encode > your connection URL before pushing it as Kubernetes secret. 2. Create a custom resource for your data store: 1. Copy the custom resource template from [Kubernetes Custom Resource Template](#k8-custom-resource-template) to a file called `custom-resource.yaml`. 2. Ensure the value of `secretRef: name` matches the `name` field defined in your Kubernetes secret file. 3. Modify other fields of the custom resource template as required for your environment. 4. Run `kubectl apply -f custom-resource.yaml`. 3. Check the logs of the Persistence Gateway pod to ensure it can communicate with the database: ```copy kubectl get pods -n rtf ``` Look for pods with the name prefix `persistence-gateway` ```copy kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -n rtf ``` The output of this command should be similar to the following: 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## Persistence Gateway with Authorized Namespaces If you use [authorized namespace](https://docs.mulesoft.com/runtime-fabric/2.7/install-helm#optional-configure-authorized-namespaces) and want to use persistence gateway, edit the RoleBinding by adding a new `rtf-persistence-gateway` subject: ```copy subjects: - kind: ServiceAccount name: rtf-persistence-gateway namespace: ``` ## Kubernetes Custom Resource Template Use the example template below to create a Kubernetes custom resource. This custom resource enables the Kubernetes cluster to connect to your data store. ```yaml apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi ``` Modify the following fields based on your environment:
FieldDescriptionDefault Value

kind

The type of custom resource. The only supported value is PersistenceGateway.

PersistenceGateway

metadata.name

The internal identifier for this custom resource. The value for this field should be default.

default

metadata.namespace

The namespace where the secret is applied. The supported value is rtf.

rtf

spec.objectStore.backendDriver

The driver used by the data store. Only postgresql is supported.

postgresql

spec.objectStore.maxBackendConnectionPool

The maximum number of simultaneous open connections to the data store.

20

spec.objectStore.replicas

The number of replicas of Persistence Gateway.

2

spec.objectStore.resources.limits.cpu

The CPU resource limits for the Persistence Gateway pods.

250m

spec.objectStore.resources.limits.memory

The memory resource limits for the Persistence Gateway pods.

150Mi

spec.objectStore.resources.requests.cpu

The CPU resource requests for the Persistence Gateway pods.

200m

spec.objectStore.resources.requests.memory

The memory resource requests for the Persistence Gateway pods.

75Mi

spec.objectStore.secretRef.name

The name of the Persistence Gateway credentials defined in the Kubernetes secret file.

persistence-gateway-creds

> [!NOTE] The default CPU, memory, and limit values are based on a small number of deployed Mule > applications. Modify these values based on the requirements of your environment. ## Persistence Gateway Application Data Persistence Gateway stores application data using the following two tables: ```copy CREATE TABLE IF NOT EXISTS stores ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, org_id VARCHAR(255) NOT NULL, env_id VARCHAR(255) NOT NULL, default_ttl_seconds int NOT NULL, is_fixed_ttl bool NOT NULL, CONSTRAINT UK_stores UNIQUE (name, org_id, env_id) ); CREATE TABLE IF NOT EXISTS items ( id SERIAL PRIMARY KEY, store_id INT NOT NULL REFERENCES stores(id), key VARCHAR(255) NOT NULL, partition VARCHAR(255) NOT NULL, value_type VARCHAR(10) NOT NULL, number_value integer, string_value text, binary_value bytea, last_updated timestamp, is_fixed_ttl bool NOT NULL, ttl timestamp NOT NULL, CONSTRAINT UK_items UNIQUE (key, store_id, partition) ); CREATE INDEX IF NOT EXISTS IDX_items_ttl ON items(ttl) ; ``` To migrate the persistent data from one cluster to another, backup these two tables entirely from the source cluster and recreate them on the target one database. Do not to have applications deployed during this process on both clusters to prevent unexpected results. ## See Also - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-runtime-fabric) - [Deploy Applications to Runtime Fabric Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) --- product: Runtime Fabric version: 2.8 --- # Configuring Persistence Gateway with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides Persistence Gateway, which enables Mule applications deployed to a Mule runtime instance to store and share data across application replicas and restarts. > [!NOTE] You can also use the Mule Maven plugin version 3.5.4 or later to enable persistent object > stores for Runtime Fabric deployments. ## Using Persistence Gateway in a Mule Application After Persistence Gateway is configured in Anypoint Runtime Fabric, it is available for Mule applications deployed to Mule runtime engine, version 4.2.1 or later. When configured, users can select **Use Persistent Object Storage** when deploying an application using Runtime Manager. See [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-runtime-fabric) for more information. Mule applications use the Object Store v2 REST API via the Object Store Connector to connect to Persistence Gateway. This enables you to deploy to both Anypoint Runtime Fabric and CloudHub without having to modify your Mule application. > [!NOTE] After deleting an application, persistent data may not be deleted immediately. Runtime > Fabric cleans persistence data every 60 minutes. ## Persistent Gateway Limits The following table lists the limits on the data stored by Persistence Gateway:
LimitDescription

Maximum TTL.

The amount of time data is stored in Persistence Gateway, value is set to 30 days.

## Before You Begin Before enabling Persistence Gateway, ensure that you have: - Created a PostgreSQL database to serve as the data source for data stored by Persistence Gateway. This database must be compatible with a [supported version of PostgreSQL](https://www.postgresql.org/support/versioning/) that does not reserve the `partition` keyword. - Granted the PostgreSQL user CREATE, INSERT, SELECT, UPDATE, and DELETE privileges. > [!NOTE] Only plain text connections to the database are supported. ## Configure Persistence Gateway During configuration, Persistence Gateway creates the required database schema. Afterwards, when an application deployed to Runtime Fabric is configured to use persistent object storage, the Persistence Gateway writes the necessary rows to the database. To configure Persistence Gateway, you must create a Kubernetes custom resource that allows the cluster to connect to your persistence data store. 1. Create a Kubernetes secret: kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename' > [!IMPORTANT] > > - Do not change `--from-literal=persistence-gateway-creds`. You can replace `` > with any value you want to use for the secret. > > - Do not use the "@" character in the database username. > > - If your PostgresSQL user account password contains special characters, make sure to encode > your connection URL before pushing it as Kubernetes secret. 2. Create a custom resource for your data store: 1. Copy the custom resource template from [Kubernetes Custom Resource Template](#k8-custom-resource-template) to a file called `custom-resource.yaml`. 2. Ensure the value of `secretRef: name` matches the `name` field defined in your Kubernetes secret file. 3. Modify other fields of the custom resource template as required for your environment. 4. Run `kubectl apply -f custom-resource.yaml`. 3. Check the logs of the Persistence Gateway pod to ensure it can communicate with the database: ```copy kubectl get pods -n rtf ``` Look for pods with the name prefix `persistence-gateway` ```copy kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -n rtf ``` The output of this command should be similar to the following: 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## Persistence Gateway with Authorized Namespaces If you use [authorized namespace](https://docs.mulesoft.com/runtime-fabric/2.8/install-helm#optional-configure-authorized-namespaces) and want to use persistence gateway, edit the RoleBinding by adding a new `rtf-persistence-gateway` subject: ```copy subjects: - kind: ServiceAccount name: rtf-persistence-gateway namespace: ``` ## Kubernetes Custom Resource Template Use the example template below to create a Kubernetes custom resource. This custom resource enables the Kubernetes cluster to connect to your data store. ```yaml apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi ``` Modify the following fields based on your environment:
FieldDescriptionDefault Value

kind

The type of custom resource. The only supported value is PersistenceGateway.

PersistenceGateway

metadata.name

The internal identifier for this custom resource. The value for this field should be default.

default

metadata.namespace

The namespace where the secret is applied. The supported value is rtf.

rtf

spec.objectStore.backendDriver

The driver used by the data store. Only postgresql is supported.

postgresql

spec.objectStore.maxBackendConnectionPool

The maximum number of simultaneous open connections to the data store.

20

spec.objectStore.replicas

The number of replicas of Persistence Gateway.

2

spec.objectStore.resources.limits.cpu

The CPU resource limits for the Persistence Gateway pods.

250m

spec.objectStore.resources.limits.memory

The memory resource limits for the Persistence Gateway pods.

150Mi

spec.objectStore.resources.requests.cpu

The CPU resource requests for the Persistence Gateway pods.

200m

spec.objectStore.resources.requests.memory

The memory resource requests for the Persistence Gateway pods.

75Mi

spec.objectStore.secretRef.name

The name of the Persistence Gateway credentials defined in the Kubernetes secret file.

persistence-gateway-creds

> [!NOTE] The default CPU, memory, and limit values are based on a small number of deployed Mule > applications. Modify these values based on the requirements of your environment. ## Persistence Gateway Application Data Persistence Gateway stores application data using the following two tables: ```copy CREATE TABLE IF NOT EXISTS stores ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, org_id VARCHAR(255) NOT NULL, env_id VARCHAR(255) NOT NULL, default_ttl_seconds int NOT NULL, is_fixed_ttl bool NOT NULL, CONSTRAINT UK_stores UNIQUE (name, org_id, env_id) ); CREATE TABLE IF NOT EXISTS items ( id SERIAL PRIMARY KEY, store_id INT NOT NULL REFERENCES stores(id), key VARCHAR(255) NOT NULL, partition VARCHAR(255) NOT NULL, value_type VARCHAR(10) NOT NULL, number_value integer, string_value text, binary_value bytea, last_updated timestamp, is_fixed_ttl bool NOT NULL, ttl timestamp NOT NULL, CONSTRAINT UK_items UNIQUE (key, store_id, partition) ); CREATE INDEX IF NOT EXISTS IDX_items_ttl ON items(ttl) ; ``` To migrate the persistent data from one cluster to another, backup these two tables entirely from the source cluster and recreate them on the target one database. Do not to have applications deployed during this process on both clusters to prevent unexpected results. ## See Also - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-runtime-fabric) - [Deploy Applications to Runtime Fabric Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) --- product: Runtime Fabric version: 2.9 --- # Configuring Persistence Gateway with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides Persistence Gateway, which enables Mule applications deployed to a Mule runtime instance to store and share data across application replicas and restarts. > [!NOTE] You can also use the Mule Maven plugin version 3.5.4 or later to enable persistent object > stores for Runtime Fabric deployments. ## Using Persistence Gateway in a Mule Application After Persistence Gateway is configured in Anypoint Runtime Fabric, it is available for Mule applications deployed to Mule runtime engine, version 4.2.1 or later. When configured, users can select **Use Persistent Object Storage** when deploying an application using Runtime Manager. See [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-runtime-fabric) for more information. Mule applications use the Object Store v2 REST API via the Object Store Connector to connect to Persistence Gateway. This enables you to deploy to both Anypoint Runtime Fabric and CloudHub without having to modify your Mule application. > [!NOTE] After deleting an application, persistent data may not be deleted immediately. Runtime > Fabric cleans persistence data every 60 minutes. ## Persistent Gateway Limits The following table lists the limits on the data stored by Persistence Gateway:
LimitDescription

Maximum TTL.

The amount of time data is stored in Persistence Gateway, value is set to 30 days.

## Before You Begin Before enabling Persistence Gateway, ensure that you have: - Created a PostgreSQL database to serve as the data source for data stored by Persistence Gateway. This database must be compatible with a [supported version of PostgreSQL](https://www.postgresql.org/support/versioning/) that does not reserve the `partition` keyword. - Granted the PostgreSQL user CREATE, INSERT, SELECT, UPDATE, and DELETE privileges. > [!NOTE] Only plain text connections to the database are supported. ## Configure Persistence Gateway During configuration, Persistence Gateway creates the required database schema. Afterwards, when an application deployed to Runtime Fabric is configured to use persistent object storage, the Persistence Gateway writes the necessary rows to the database. To configure Persistence Gateway, you must create a Kubernetes custom resource that allows the cluster to connect to your persistence data store. 1. Create a Kubernetes secret: kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename' > [!IMPORTANT] > > - Do not change `--from-literal=persistence-gateway-creds`. You can replace `` > with any value you want to use for the secret. > > - Do not use the "@" character in the database username. > > - If your PostgresSQL user account password contains special characters, make sure to encode > your connection URL before pushing it as Kubernetes secret. 2. Create a custom resource for your data store: 1. Copy the custom resource template from [Kubernetes Custom Resource Template](#k8-custom-resource-template) to a file called `custom-resource.yaml`. 2. Ensure the value of `secretRef: name` matches the `name` field defined in your Kubernetes secret file. 3. Modify other fields of the custom resource template as required for your environment. 4. Run `kubectl apply -f custom-resource.yaml`. 3. Check the logs of the Persistence Gateway pod to ensure it can communicate with the database: ```copy kubectl get pods -n rtf ``` Look for pods with the name prefix `persistence-gateway` ```copy kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -n rtf ``` The output of this command should be similar to the following: 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## Persistence Gateway with Authorized Namespaces If you use [authorized namespace](https://docs.mulesoft.com/runtime-fabric/2.9/install-helm#optional-configure-authorized-namespaces) and want to use persistence gateway, edit the RoleBinding by adding a new `rtf-persistence-gateway` subject: ```copy subjects: - kind: ServiceAccount name: rtf-persistence-gateway namespace: ``` ## Kubernetes Custom Resource Template Use the example template below to create a Kubernetes custom resource. This custom resource enables the Kubernetes cluster to connect to your data store. ```yaml apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi ``` Modify the following fields based on your environment:
FieldDescriptionDefault Value

kind

The type of custom resource. The only supported value is PersistenceGateway.

PersistenceGateway

metadata.name

The internal identifier for this custom resource. The value for this field should be default.

default

metadata.namespace

The namespace where the secret is applied. The supported value is rtf.

rtf

spec.objectStore.backendDriver

The driver used by the data store. Only postgresql is supported.

postgresql

spec.objectStore.maxBackendConnectionPool

The maximum number of simultaneous open connections to the data store.

20

spec.objectStore.replicas

The number of replicas of Persistence Gateway.

2

spec.objectStore.resources.limits.cpu

The CPU resource limits for the Persistence Gateway pods.

250m

spec.objectStore.resources.limits.memory

The memory resource limits for the Persistence Gateway pods.

150Mi

spec.objectStore.resources.requests.cpu

The CPU resource requests for the Persistence Gateway pods.

200m

spec.objectStore.resources.requests.memory

The memory resource requests for the Persistence Gateway pods.

75Mi

spec.objectStore.secretRef.name

The name of the Persistence Gateway credentials defined in the Kubernetes secret file.

persistence-gateway-creds

> [!NOTE] The default CPU, memory, and limit values are based on a small number of deployed Mule > applications. Modify these values based on the requirements of your environment. ## Persistence Gateway Application Data Persistence Gateway stores application data using the following two tables: ```copy CREATE TABLE IF NOT EXISTS stores ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, org_id VARCHAR(255) NOT NULL, env_id VARCHAR(255) NOT NULL, default_ttl_seconds int NOT NULL, is_fixed_ttl bool NOT NULL, CONSTRAINT UK_stores UNIQUE (name, org_id, env_id) ); CREATE TABLE IF NOT EXISTS items ( store_id INT NOT NULL REFERENCES stores(id), key VARCHAR(255) NOT NULL, partition VARCHAR(255) NOT NULL, value_type VARCHAR(10) NOT NULL, number_value integer, string_value text, binary_value bytea, last_updated timestamp, is_fixed_ttl bool NOT NULL, ttl timestamp NOT NULL, CONSTRAINT UK_items UNIQUE (key, store_id, partition) ); CREATE INDEX IF NOT EXISTS IDX_items_ttl ON items(ttl) ; ``` To migrate the persistent data from one cluster to another, backup these two tables entirely from the source cluster and recreate them on the target one database. Do not to have applications deployed during this process on both clusters to prevent unexpected results. If you’re using a version of the Runtime Fabric agent higher than 2.6.22, the `id` parameter in the `CREATE TABLE IF NOT EXISTS items` statement no longer applies. For previous versions of the Runtime Fabric agent 2.6.22, the `id` parameter is available in the items table. ## See Also - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-runtime-fabric) - [Deploy Applications to Runtime Fabric Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Persistence Gateway with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides Persistence Gateway, which enables Mule applications deployed to a Mule runtime instance to store and share data across application replicas and restarts. > [!NOTE] You can also use the Mule Maven plugin version 3.5.4 or later to enable persistent object > stores for Runtime Fabric deployments. ## Using Persistence Gateway in a Mule Application After Persistence Gateway is configured in Anypoint Runtime Fabric, it is available for Mule applications deployed to Mule runtime engine, version 4.2.1 or later. When configured, users can select **Use Persistent Object Storage** when deploying an application using Runtime Manager. See [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) for more information. Mule applications use the Object Store v2 REST API via the Object Store Connector to connect to Persistence Gateway. This enables you to deploy to both Anypoint Runtime Fabric and CloudHub without having to modify your Mule application. > [!NOTE] After deleting an application, persistent data may not be deleted immediately. Runtime > Fabric cleans persistence data every 60 minutes. ## Persistent Gateway Limits The following table lists the limits on the data stored by Persistence Gateway:
LimitDescription

Maximum TTL.

The amount of time data is stored in Persistence Gateway, value is set to 30 days.

## Before You Begin Before enabling Persistence Gateway, ensure that you have: - Created a PostgreSQL database to serve as the data source for data stored by Persistence Gateway. This database must be compatible with a [supported version of PostgreSQL](https://www.postgresql.org/support/versioning/) that does not reserve the `partition` keyword. - Granted the PostgreSQL user CREATE, INSERT, SELECT, UPDATE, and DELETE privileges. > [!NOTE] Only plain text connections to the database are supported. ## Configure Persistence Gateway During configuration, Persistence Gateway creates the required database schema. Afterwards, when an application deployed to Runtime Fabric is configured to use persistent object storage, the Persistence Gateway writes the necessary rows to the database. To configure Persistence Gateway, you must create a Kubernetes custom resource that allows the cluster to connect to your persistence data store. 1. Create a Kubernetes secret: kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename' > [!IMPORTANT] > > - Do not change `--from-literal=persistence-gateway-creds`. You can replace `` > with any value you want to use for the secret. > > - Do not use the "@" character in the database username. > > - If your PostgresSQL user account password contains special characters, make sure to encode > your connection URL before pushing it as Kubernetes secret. 2. Create a custom resource for your data store: 1. Copy the custom resource template from [Kubernetes Custom Resource Template](#k8-custom-resource-template) to a file called `custom-resource.yaml`. 2. Ensure the value of `secretRef: name` matches the `name` field defined in your Kubernetes secret file. 3. Modify other fields of the custom resource template as required for your environment. 4. Run `kubectl apply -f custom-resource.yaml`. 3. Check the logs of the Persistence Gateway pod to ensure it can communicate with the database: ```copy kubectl get pods -n rtf ``` Look for pods with the name prefix `persistence-gateway` ```copy kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -n rtf ``` The output of this command should be similar to the following: 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## Persistence Gateway with Authorized Namespaces If you use [authorized namespace](https://docs.mulesoft.com/runtime-fabric/latest/install-helm#optional-configure-authorized-namespaces) and want to use persistence gateway, edit the RoleBinding by adding a new `rtf-persistence-gateway` subject: ```copy subjects: - kind: ServiceAccount name: rtf-persistence-gateway namespace: ``` ## Kubernetes Custom Resource Template Use the example template below to create a Kubernetes custom resource. This custom resource enables the Kubernetes cluster to connect to your data store. ```yaml apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway ``` Modify the following fields based on your environment:
FieldDescriptionDefault Value

kind

The type of custom resource. The only supported value is PersistenceGateway.

PersistenceGateway

metadata.name

The internal identifier for this custom resource. The value for this field should be default.

default

metadata.namespace

The namespace where the secret is applied. The supported value is rtf.

rtf

spec.objectStore.backendDriver

The driver used by the data store. Only postgresql is supported.

postgresql

spec.objectStore.maxBackendConnectionPool

The maximum number of simultaneous open connections to the data store.

20

spec.objectStore.replicas

The number of replicas of Persistence Gateway.

2

spec.objectStore.resources.limits.cpu

The CPU resource limits for the Persistence Gateway pods.

250m

spec.objectStore.resources.limits.memory

The memory resource limits for the Persistence Gateway pods.

150Mi

spec.objectStore.resources.requests.cpu

The CPU resource requests for the Persistence Gateway pods.

200m

spec.objectStore.resources.requests.memory

The memory resource requests for the Persistence Gateway pods.

75Mi

spec.objectStore.secretRef.name

The name of the Persistence Gateway credentials defined in the Kubernetes secret file.

persistence-gateway-creds

spec.objectStore.topologySpreadConstraints.maxSkew

Describes the degree to which pods may be unevenly distributed.

1

spec.objectStore.topologySpreadConstraints.topologyKey

Key that understands which criteria to use to distribute pods.

topology.kubernetes.io/zone

spec.objectStore.topologySpreadConstraints.whenUnsatisfiable

Indicates how to deal with a pod if it doesn’t satisfy the spread constraint.

ScheduleAnyway

> [!NOTE] The default CPU, memory, and limit values are based on a small number of deployed Mule > applications. Modify these values based on the requirements of your environment. ## Persistence Gateway Application Data Persistence Gateway stores application data using the following two tables: ```copy CREATE TABLE IF NOT EXISTS stores ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, org_id VARCHAR(255) NOT NULL, env_id VARCHAR(255) NOT NULL, default_ttl_seconds int NOT NULL, is_fixed_ttl bool NOT NULL, CONSTRAINT UK_stores UNIQUE (name, org_id, env_id) ); CREATE TABLE IF NOT EXISTS items ( store_id INT NOT NULL REFERENCES stores(id), key VARCHAR(255) NOT NULL, partition VARCHAR(255) NOT NULL, value_type VARCHAR(10) NOT NULL, number_value integer, string_value text, binary_value bytea, last_updated timestamp, is_fixed_ttl bool NOT NULL, ttl timestamp NOT NULL, CONSTRAINT UK_items UNIQUE (key, store_id, partition) ); CREATE INDEX IF NOT EXISTS IDX_items_ttl ON items(ttl) ; ``` To migrate the persistent data from one cluster to another, backup these two tables entirely from the source cluster and recreate them on the target one database. Do not to have applications deployed during this process on both clusters to prevent unexpected results. If you’re using a version of the Runtime Fabric agent higher than 2.6.22, the `id` parameter in the `CREATE TABLE IF NOT EXISTS items` statement no longer applies. For previous versions of the Runtime Fabric agent 2.6.22, the `id` parameter is available in the items table. ## See Also - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) - [Deploy Applications to Runtime Fabric Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) --- product: Runtime Fabric version: 2.10 --- # Configuring Proxies on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric uses two types of proxies when running and hosting applications: - System proxies: include proxies that enable connectivity among Kubernetes cluster services, including the Docker daemon and other internal components. When using Runtime Fabric you are responsible for configuring and managing system proxies. - Application proxies: include proxies that enable connectivity to applications running on Runtime Fabric. You can configure the proxy settings used by Runtime Fabric outbound connections to the internet. This includes both HTTP proxies for connecting to the Anypoint Platform control plane and SOCKS5 proxies for sending metrics and logs to Anypoint Monitoring. You can also configure proxies for applications. ## Install rtfctl The `rtfctl` command line tool is required to manage proxy settings on Runtime Fabric. Follow the steps to [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl) before configuring proxy settings. > [!NOTE] You can apply proxy settings during installation of Runtime Fabric if you install using > Helm. For more information, refer to the > [Installing Runtime Fabric Using Helm documentation](https://docs.mulesoft.com/runtime-fabric/2.10/install-helm). ## Configure an Anypoint Monitoring Proxy Anypoint Monitoring requires a proxy for communication. The type of proxy you need to configure depends on your Runtime Fabric version.
Table 1. Anypoint Monitoring Proxy Configuration
Runtime Fabric VersionRequired Proxy TypeConfiguration Details

2.6.22 and Later

HTTP Proxy

For detailed steps, refer to Configure an HTTP Proxy for Services in Runtime Fabric.

Earlier than 2.6.22 and Legacy Deployments

SOCKS5 Proxy

For detailed steps, refer to Configure a SOCKS5 Proxy for Runtime Fabric.

## Configure a SOCKS5 Proxy for Runtime Fabric Make sure your SOCKS5 proxy connect to Anypoint Monitoring over TCP at these endpoints, depending on your control plane: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` 1. Log in to a node where `rtfctl` is installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" ``` - ****: the username needed to authenticate to the SOCKS5 proxy. - ****: the password needed to authenticate to the SOCKS5 proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.2>**: The IP address or hostname used to access the SOCKS5 proxy. - **<8080>**: The host port on the host where the SOCKS5 proxy is listening for requests. 1. To verify the change was successful, run the following command to output the current value of the monitoring proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy ``` The output should match the value expected. 2. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl#validate) documentation. ## Configure an HTTP Proxy for Services in Runtime Fabric You can configure HTTP proxies so that outbound components can communicate with the control plane. You must restart the `rtf-agent` pod and any Mule app that requires a proxy. Although no downtime occurs if you are running multiple replicas, you should perform HTTP proxy updates during a maintenance window. - Apply the proxy values to the services running within Runtime Fabric. - If you are using Runtime Fabric installer 1.0.x, run the script on each node of your Runtime Fabric to update the cluster. 1. Log in to a node where `rtfctl` has been installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" ``` - ****: the username needed to authenticate to the HTTP proxy. - ****: the password needed to authenticate to the HTTP proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.1>**: Specifies the IP address or hostname to access the HTTP proxy. - **<8080>**: Specifies the port on the host where the HTTP proxy is listening for requests. - **<1.1.1.1:8888,2.2.2.2:9999>**: Specifies the `RTF_NO_PROXY` hosts and ports, delimited by commas. - (Optional) `--confirm`: Skips manual acknowledgement of the change. If not specified, the `rtfctl apply proxy` command prompts you to confirm the change before continuing. 1. To verify the change was successful, run the following command to output the current value of the HTTP proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get http-proxy ``` The output should match the value expected. 2. To remove the proxy values, run: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ``` 3. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl#validate) documentation. ### About the HTTP\_PROXY Environment Variable After applying a proxy for services in Runtime Fabric, you could see a warning similar to: Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric generates a warning to let you know that you have not set the `HTTP_PROXY` environment variable or that the variable does not match the value used for Runtime Fabric services. The settings do not have to match, but Runtime Fabric generates the warning so you’re aware services could be impacted. Many Linux tools use the `HTTP_PROXY` environment variable to provide their proxy settings. If your environment requires a proxy for Internet access, you likely need to set the `HTTP_PROXY` environment variable for commands that require Internet access. This could affect other tools that also use HTTP or HTTPS operations but do not require Internet access, such as `kubectl`. You can use the `NO_PROXY` environment variable to establish connections that should not be proxied. Refer to the documentation for your Linux tools for more information on which environment variables affect its proxy behavior. ### About the NO\_PROXY Environment Variable By default, `NO_PROXY` is set to `0.0.0.0/0` and `.local`. These settings ensure that the proxy does not route any IPV4 destination addresses. ## Configure a Proxy for the API Manager Agent You can use a proxy to establish communication for Mule applications that you manage with API Manager. This proxy configuration must be set on each Mule application, even if you are using the same configuration for all applications. Note this setting is independent from the application-level proxy that applications use to communicate with other external endpoints. To configure a proxy for the API Manager Agent, add the following properties to the application: anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## Configure a Proxy for a Mule Application Applications deployed in Runtime Fabric inherit proxy settings from the Runtime Fabric cluster. You can also configure a proxy for each application. You can set up a proxy on each connector (such as an HTTP requestor) or set up a proxy with application properties as shown in the following example. Setting up a proxy with application properties is less work if you have a large number of connectors in an application. http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true --- product: Runtime Fabric version: 2.11 --- # Configuring Proxies on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric uses two types of proxies when running and hosting applications: - System proxies: include proxies that enable connectivity among Kubernetes cluster services, including the Docker daemon and other internal components. When using Runtime Fabric you are responsible for configuring and managing system proxies. - Application proxies: include proxies that enable connectivity to applications running on Runtime Fabric. You can configure the proxy settings used by Runtime Fabric outbound connections to the internet. This includes both HTTP proxies for connecting to the Anypoint Platform control plane and SOCKS5 proxies for sending metrics and logs to Anypoint Monitoring. You can also configure proxies for applications. ## Install rtfctl The `rtfctl` command line tool is required to manage proxy settings on Runtime Fabric. Follow the steps to [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl) before configuring proxy settings. > [!NOTE] You can apply proxy settings during installation of Runtime Fabric if you install using > Helm. For more information, refer to the > [Installing Runtime Fabric Using Helm documentation](https://docs.mulesoft.com/runtime-fabric/2.11/install-helm). ## Configure an Anypoint Monitoring Proxy For Runtime Fabric deployments on version 2.6.22 and later, Anypoint Monitoring uses an HTTP proxy. Refer to [Configure an HTTP Proxy for Services in Runtime Fabric](#configure-http) for details. For Runtime Fabric versions earlier than 2.6.22 and for legacy deployments, Anypoint Monitoring requires a SOCKS5 proxy. Use these steps for the configuration: The SOCKS5 proxy must connect to Anypoint Monitoring over TCP at these endpoints: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` 1. Log in to a node where `rtfctl` is installed. 2. Run this command, replacing the placeholder values with this: ```copy /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" ``` - ****: the username needed to authenticate to the SOCKS5 proxy. - ****: the password needed to authenticate to the SOCKS5 proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.2>**: The IP address or hostname used to access the SOCKS5 proxy. - **<8080>**: The host port on the host where the SOCKS5 proxy is listening for requests. 1. To verify the change was successful, run this command to output the current value of the monitoring proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy ``` The output should match the value expected. 2. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl#validate) documentation. ## Configure an HTTP Proxy for Services in Runtime Fabric You can configure HTTP proxies so that outbound components can communicate with the control plane. You must restart the `rtf-agent` pod and any Mule app that requires a proxy. Although no downtime occurs if you are running multiple replicas, you should perform HTTP proxy updates during a maintenance window. - Apply the proxy values to the services running within Runtime Fabric. - If you are using Runtime Fabric installer 1.0.x, run the script on each node of your Runtime Fabric to update the cluster. 1. Log in to a node where `rtfctl` has been installed. 2. Run this command, replacing the placeholder values with this: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" ``` - ****: the username needed to authenticate to the HTTP proxy. - ****: the password needed to authenticate to the HTTP proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.1>**: Specifies the IP address or hostname to access the HTTP proxy. - **<8080>**: Specifies the port on the host where the HTTP proxy is listening for requests. - **<1.1.1.1:8888,2.2.2.2:9999>**: Specifies the `RTF_NO_PROXY` hosts and ports, delimited by commas. - (Optional) `--confirm`: Skips manual acknowledgement of the change. If not specified, the `rtfctl apply proxy` command prompts you to confirm the change before continuing. 1. To verify the change was successful, run this command to output the current value of the HTTP proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get http-proxy ``` The output should match the value expected. 2. To remove the proxy values, run: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ``` 3. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl#validate) documentation. ### About the HTTP\_PROXY Environment Variable After applying a proxy for services in Runtime Fabric, you could see a warning similar to: Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric generates a warning to let you know that you have not set the `HTTP_PROXY` environment variable or that the variable does not match the value used for Runtime Fabric services. The settings do not have to match, but Runtime Fabric generates the warning so you’re aware services could be impacted. Many Linux tools use the `HTTP_PROXY` environment variable to provide their proxy settings. If your environment requires a proxy for Internet access, you likely need to set the `HTTP_PROXY` environment variable for commands that require Internet access. This could affect other tools that also use HTTP or HTTPS operations but do not require Internet access, such as `kubectl`. You can use the `NO_PROXY` environment variable to establish connections that should not be proxied. Refer to the documentation for your Linux tools for more information on which environment variables affect its proxy behavior. ### About the NO\_PROXY Environment Variable By default, `NO_PROXY` is set to `0.0.0.0/0` and `.local`. These settings ensure that the proxy does not route any IPV4 destination addresses. ## Configure a Proxy for the API Manager Agent You can use a proxy to establish communication for Mule applications that you manage with API Manager. This proxy configuration must be set on each Mule application, even if you are using the same configuration for all applications. Note this setting is independent from the application-level proxy that applications use to communicate with other external endpoints. To configure a proxy for the API Manager Agent, add these properties to the application: anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## Configure a Proxy for a Mule Application Applications deployed in Runtime Fabric inherit proxy settings from the Runtime Fabric cluster. You can also configure a proxy for each application. You can set up a proxy on each connector (such as an HTTP requestor) or set up a proxy with application properties as shown in this example. Setting up a proxy with application properties is less work if you have a large number of connectors in an application. http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true --- product: Runtime Fabric version: 2.6 --- # Configuring Proxies on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric uses two types of proxies when running and hosting applications: - System proxies: include proxies that enable connectivity among Kubernetes cluster services, including the Docker daemon and other internal components. When using Runtime Fabric you are responsible for configuring and managing system proxies. - Application proxies: include proxies that enable connectivity to applications running on Runtime Fabric. You can configure the proxy settings used by Runtime Fabric outbound connections to the internet. This includes both HTTP proxies for connecting to the Anypoint Platform control plane and SOCKS5 proxies for sending metrics and logs to Anypoint Monitoring. You can also configure proxies for applications. ## Install rtfctl The `rtfctl` command line tool is required to manage proxy settings on Runtime Fabric. Follow the steps to [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl) before configuring proxy settings. > [!NOTE] You can apply proxy settings during installation of Runtime Fabric if you install using > Helm. For more information, refer to the > [Installing Runtime Fabric Using Helm documentation](https://docs.mulesoft.com/runtime-fabric/2.6/install-helm). ## Configure an Anypoint Monitoring Proxy Anypoint Monitoring requires a proxy for communication. The type of proxy you need to configure depends on your Runtime Fabric version.
Table 1. Anypoint Monitoring Proxy Configuration
Runtime Fabric VersionRequired Proxy TypeConfiguration Details

2.6.22 and Later

HTTP Proxy

For detailed steps, refer to Configure an HTTP Proxy for Services in Runtime Fabric.

Earlier than 2.6.22 and Legacy Deployments

SOCKS5 Proxy

For detailed steps, refer to Configure a SOCKS5 Proxy for Runtime Fabric.

## Configure a SOCKS5 Proxy for Runtime Fabric - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` 1. Log in to a node where `rtfctl` is installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" ``` - ****: the username needed to authenticate to the SOCKS5 proxy. - ****: the password needed to authenticate to the SOCKS5 proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.2>**: The IP address or hostname used to access the SOCKS5 proxy. - **<8080>**: The host port on the host where the SOCKS5 proxy is listening for requests. 1. To verify the change was successful, run the following command to output the current value of the monitoring proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy ``` The output should match the value expected. 2. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl#validate) documentation. ## Configure an HTTP Proxy for Services in Runtime Fabric You can configure HTTP proxies so that outbound components can communicate with the control plane. > [!NOTE] Starting Runtime Fabric version 2.6.22, the following HTTP proxy is needed for Anypoint > Monitoring sidecar or agents as well. SOCK5 proxy is not required for Mule apps deployed on > Runtime Fabrics with version 2.6.22 onwards Updating an HTTP proxy causes each machine in the cluster to restart all pods running on it. Although no downtime occurs if you are running multiple replicas, you should perform HTTP proxy updates during a maintenance window. - Apply the proxy values to the services running within Runtime Fabric. - If you are using Runtime Fabric installer 1.0.x, run the script on each node of your Runtime Fabric to update the cluster. 1. Log in to a node where `rtfctl` has been installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" ``` - ****: the username needed to authenticate to the HTTP proxy. - ****: the password needed to authenticate to the HTTP proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.1>**: Specifies the IP address or hostname to access the HTTP proxy. - **<8080>**: Specifies the port on the host where the HTTP proxy is listening for requests. - **<1.1.1.1:8888,2.2.2.2:9999>**: Specifies the `RTF_NO_PROXY` hosts and ports, delimited by commas. - (Optional) `--confirm`: Skips manual acknowledgement of the change. If not specified, the `rtfctl apply proxy` command prompts you to confirm the change before continuing. 1. To verify the change was successful, run the following command to output the current value of the HTTP proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get http-proxy ``` The output should match the value expected. 2. To remove the proxy values, run: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ``` 3. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl#validate) documentation. ### About the HTTP\_PROXY Environment Variable After applying a proxy for services in Runtime Fabric, you could see a warning similar to: Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric generates a warning to let you know that you have not set the `HTTP_PROXY` environment variable or that the variable does not match the value used for Runtime Fabric services. The settings do not have to match, but Runtime Fabric generates the warning so you’re aware services could be impacted. Many Linux tools use the `HTTP_PROXY` environment variable to provide their proxy settings. If your environment requires a proxy for Internet access, you likely need to set the `HTTP_PROXY` environment variable for commands that require Internet access. This could affect other tools that also use HTTP or HTTPS operations but do not require Internet access, such as `kubectl`. You can use the `NO_PROXY` environment variable to establish connections that should not be proxied. Refer to the documentation for your Linux tools for more information on which environment variables affect its proxy behavior. ### About the NO\_PROXY Environment Variable By default, `NO_PROXY` is set to `0.0.0.0/0` and `.local`. These settings ensure that the proxy does not route any IPV4 destination addresses. ## Configure a Proxy for the API Manager Agent You can use a proxy to establish communication for Mule applications that you manage with API Manager. This proxy configuration must be set on each Mule application, even if you are using the same configuration for all applications. Note this setting is independent from the application-level proxy that applications use to communicate with other external endpoints. To configure a proxy for the API Manager Agent, add the following properties to the application: anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## Configure a Proxy for a Mule Application Applications deployed in Runtime Fabric inherit proxy settings from the Runtime Fabric cluster. You can also configure a proxy for each application. You can set up a proxy on each connector (such as an HTTP requestor) or set up a proxy with application properties as shown in the following example. Setting up a proxy with application properties is less work if you have a large number of connectors in an application. http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true --- product: Runtime Fabric version: 2.7 --- # Configuring Proxies on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric uses two types of proxies when running and hosting applications: - System proxies: include proxies that enable connectivity among Kubernetes cluster services, including the Docker daemon and other internal components. When using Runtime Fabric you are responsible for configuring and managing system proxies. - Application proxies: include proxies that enable connectivity to applications running on Runtime Fabric. You can configure the proxy settings used by Runtime Fabric outbound connections to the internet. This includes both HTTP proxies for connecting to the Anypoint Platform control plane and SOCKS5 proxies for sending metrics and logs to Anypoint Monitoring. You can also configure proxies for applications. ## Install rtfctl The `rtfctl` command line tool is required to manage proxy settings on Runtime Fabric. Follow the steps to [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl) before configuring proxy settings. > [!NOTE] You can apply proxy settings during installation of Runtime Fabric if you install using > Helm. For more information, refer to the > [Installing Runtime Fabric Using Helm documentation](https://docs.mulesoft.com/runtime-fabric/2.7/install-helm). ## Configure an Anypoint Monitoring Proxy Anypoint Monitoring requires a proxy for communication. The type of proxy you need to configure depends on your Runtime Fabric version.
Table 1. Anypoint Monitoring Proxy Configuration
Runtime Fabric VersionRequired Proxy TypeConfiguration Details

2.6.22 and Later

HTTP Proxy

For detailed steps, refer to Configure an HTTP Proxy for Services in Runtime Fabric.

Earlier than 2.6.22 and Legacy Deployments

SOCKS5 Proxy

For detailed steps, refer to Configure a SOCKS5 Proxy for Runtime Fabric.

## Configure a SOCKS5 Proxy for Runtime Fabric Make sure your SOCKS5 proxy connects to Anypoint Monitoring over TCP at these endpoints, depending on your control plane: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` 1. Log in to a node where `rtfctl` is installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" ``` - ****: the username needed to authenticate to the SOCKS5 proxy. - ****: the password needed to authenticate to the SOCKS5 proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.2>**: The IP address or hostname used to access the SOCKS5 proxy. - **<8080>**: The host port on the host where the SOCKS5 proxy is listening for requests. 1. To verify the change was successful, run the following command to output the current value of the monitoring proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy ``` The output should match the value expected. 2. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl#validate) documentation. ## Configure an HTTP Proxy for Services in Runtime Fabric You can configure HTTP proxies so that outbound components can communicate with the control plane. Updating an HTTP proxy causes each machine in the cluster to restart all pods running on it. Although no downtime occurs if you are running multiple replicas, you should perform HTTP proxy updates during a maintenance window. - Apply the proxy values to the services running within Runtime Fabric. - If you are using Runtime Fabric installer 1.0.x, run the script on each node of your Runtime Fabric to update the cluster. 1. Log in to a node where `rtfctl` has been installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" ``` - ****: the username needed to authenticate to the HTTP proxy. - ****: the password needed to authenticate to the HTTP proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.1>**: Specifies the IP address or hostname to access the HTTP proxy. - **<8080>**: Specifies the port on the host where the HTTP proxy is listening for requests. - **<1.1.1.1:8888,2.2.2.2:9999>**: Specifies the `RTF_NO_PROXY` hosts and ports, delimited by commas. - (Optional) `--confirm`: Skips manual acknowledgement of the change. If not specified, the `rtfctl apply proxy` command prompts you to confirm the change before continuing. 1. To verify the change was successful, run the following command to output the current value of the HTTP proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get http-proxy ``` The output should match the value expected. 2. To remove the proxy values, run: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ``` 3. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl#validate) documentation. ### About the HTTP\_PROXY Environment Variable After applying a proxy for services in Runtime Fabric, you could see a warning similar to: Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric generates a warning to let you know that you have not set the `HTTP_PROXY` environment variable or that the variable does not match the value used for Runtime Fabric services. The settings do not have to match, but Runtime Fabric generates the warning so you’re aware services could be impacted. Many Linux tools use the `HTTP_PROXY` environment variable to provide their proxy settings. If your environment requires a proxy for Internet access, you likely need to set the `HTTP_PROXY` environment variable for commands that require Internet access. This could affect other tools that also use HTTP or HTTPS operations but do not require Internet access, such as `kubectl`. You can use the `NO_PROXY` environment variable to establish connections that should not be proxied. Refer to the documentation for your Linux tools for more information on which environment variables affect its proxy behavior. ### About the NO\_PROXY Environment Variable By default, `NO_PROXY` is set to `0.0.0.0/0` and `.local`. These settings ensure that the proxy does not route any IPV4 destination addresses. ## Configure a Proxy for the API Manager Agent You can use a proxy to establish communication for Mule applications that you manage with API Manager. This proxy configuration must be set on each Mule application, even if you are using the same configuration for all applications. Note this setting is independent from the application-level proxy that applications use to communicate with other external endpoints. To configure a proxy for the API Manager Agent, add the following properties to the application: anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## Configure a Proxy for a Mule Application Applications deployed in Runtime Fabric inherit proxy settings from the Runtime Fabric cluster. You can also configure a proxy for each application. You can set up a proxy on each connector (such as an HTTP requestor) or set up a proxy with application properties as shown in the following example. Setting up a proxy with application properties is less work if you have a large number of connectors in an application. http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true --- product: Runtime Fabric version: 2.8 --- # Configuring Proxies on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric uses two types of proxies when running and hosting applications: - System proxies: include proxies that enable connectivity among Kubernetes cluster services, including the Docker daemon and other internal components. When using Runtime Fabric you are responsible for configuring and managing system proxies. - Application proxies: include proxies that enable connectivity to applications running on Runtime Fabric. You can configure the proxy settings used by Runtime Fabric outbound connections to the internet. This includes both HTTP proxies for connecting to the Anypoint Platform control plane and SOCKS5 proxies for sending metrics and logs to Anypoint Monitoring. You can also configure proxies for applications. ## Install rtfctl The `rtfctl` command line tool is required to manage proxy settings on Runtime Fabric. Follow the steps to [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) before configuring proxy settings. > [!NOTE] You can apply proxy settings during installation of Runtime Fabric if you install using > Helm. For more information, refer to the > [Installing Runtime Fabric Using Helm documentation](https://docs.mulesoft.com/runtime-fabric/2.8/install-helm). ## Configure an Anypoint Monitoring Proxy Anypoint Monitoring requires a proxy for communication. The type of proxy you need to configure depends on your Runtime Fabric version.
Table 1. Anypoint Monitoring Proxy Configuration
Runtime Fabric VersionRequired Proxy TypeConfiguration Details

2.6.22 and Later

HTTP Proxy

For detailed steps, refer to Configure an HTTP Proxy for Services in Runtime Fabric.

Earlier than 2.6.22 and Legacy Deployments

SOCKS5 Proxy

For detailed steps, refer to Configure a SOCKS5 Proxy for Runtime Fabric.

## Configure a SOCKS5 Proxy for Runtime Fabric Make sure your SOCKS5 proxy connects to Anypoint Monitoring over TCP at these endpoints, depending on your control plane: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` 1. Log in to a node where `rtfctl` is installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" ``` - ****: the username needed to authenticate to the SOCKS5 proxy. - ****: the password needed to authenticate to the SOCKS5 proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.2>**: The IP address or hostname used to access the SOCKS5 proxy. - **<8080>**: The host port on the host where the SOCKS5 proxy is listening for requests. 1. To verify the change was successful, run the following command to output the current value of the monitoring proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy ``` The output should match the value expected. 2. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl#validate) documentation. ## Configure an HTTP Proxy for Services in Runtime Fabric You can configure HTTP proxies so that outbound components can communicate with the control plane. You must restart the `rtf-agent` pod and any Mule app that requires a proxy. Although no downtime occurs if you are running multiple replicas, you should perform HTTP proxy updates during a maintenance window. - Apply the proxy values to the services running within Runtime Fabric. - If you are using Runtime Fabric installer 1.0.x, run the script on each node of your Runtime Fabric to update the cluster. 1. Log in to a node where `rtfctl` has been installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" ``` - ****: the username needed to authenticate to the HTTP proxy. - ****: the password needed to authenticate to the HTTP proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.1>**: Specifies the IP address or hostname to access the HTTP proxy. - **<8080>**: Specifies the port on the host where the HTTP proxy is listening for requests. - **<1.1.1.1:8888,2.2.2.2:9999>**: Specifies the `RTF_NO_PROXY` hosts and ports, delimited by commas. - (Optional) `--confirm`: Skips manual acknowledgement of the change. If not specified, the `rtfctl apply proxy` command prompts you to confirm the change before continuing. 1. To verify the change was successful, run the following command to output the current value of the HTTP proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get http-proxy ``` The output should match the value expected. 2. To remove the proxy values, run: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ``` 3. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl#validate) documentation. ### About the HTTP\_PROXY Environment Variable After applying a proxy for services in Runtime Fabric, you could see a warning similar to: Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric generates a warning to let you know that you have not set the `HTTP_PROXY` environment variable or that the variable does not match the value used for Runtime Fabric services. The settings do not have to match, but Runtime Fabric generates the warning so you’re aware services could be impacted. Many Linux tools use the `HTTP_PROXY` environment variable to provide their proxy settings. If your environment requires a proxy for Internet access, you likely need to set the `HTTP_PROXY` environment variable for commands that require Internet access. This could affect other tools that also use HTTP or HTTPS operations but do not require Internet access, such as `kubectl`. You can use the `NO_PROXY` environment variable to establish connections that should not be proxied. Refer to the documentation for your Linux tools for more information on which environment variables affect its proxy behavior. ### About the NO\_PROXY Environment Variable By default, `NO_PROXY` is set to `0.0.0.0/0` and `.local`. These settings ensure that the proxy does not route any IPV4 destination addresses. ## Configure a Proxy for the API Manager Agent You can use a proxy to establish communication for Mule applications that you manage with API Manager. This proxy configuration must be set on each Mule application, even if you are using the same configuration for all applications. Note this setting is independent from the application-level proxy that applications use to communicate with other external endpoints. To configure a proxy for the API Manager Agent, add the following properties to the application: anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## Configure a Proxy for a Mule Application Applications deployed in Runtime Fabric inherit proxy settings from the Runtime Fabric cluster. You can also configure a proxy for each application. You can set up a proxy on each connector (such as an HTTP requestor) or set up a proxy with application properties as shown in the following example. Setting up a proxy with application properties is less work if you have a large number of connectors in an application. http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true --- product: Runtime Fabric version: 2.9 --- # Configuring Proxies on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric uses two types of proxies when running and hosting applications: - System proxies: include proxies that enable connectivity among Kubernetes cluster services, including the Docker daemon and other internal components. When using Runtime Fabric you are responsible for configuring and managing system proxies. - Application proxies: include proxies that enable connectivity to applications running on Runtime Fabric. You can configure the proxy settings used by Runtime Fabric outbound connections to the internet. This includes both HTTP proxies for connecting to the Anypoint Platform control plane and SOCKS5 proxies for sending metrics and logs to Anypoint Monitoring. You can also configure proxies for applications. ## Install rtfctl The `rtfctl` command line tool is required to manage proxy settings on Runtime Fabric. Follow the steps to [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl) before configuring proxy settings. > [!NOTE] You can apply proxy settings during installation of Runtime Fabric if you install using > Helm. For more information, refer to the > [Installing Runtime Fabric Using Helm documentation](https://docs.mulesoft.com/runtime-fabric/2.9/install-helm). ## Configure an Anypoint Monitoring Proxy Anypoint Monitoring requires a proxy for communication. The type of proxy you need to configure depends on your Runtime Fabric version.
Table 1. Anypoint Monitoring Proxy Configuration
Runtime Fabric VersionRequired Proxy TypeConfiguration Details

2.6.22 and Later

HTTP Proxy

For detailed steps, refer to Configure an HTTP Proxy for Services in Runtime Fabric.

Earlier than 2.6.22 and Legacy Deployments

SOCKS5 Proxy

For detailed steps, refer to Configure a SOCKS5 Proxy for Runtime Fabric.

## Configure a SOCKS5 Proxy for Runtime Fabric Make sure your SOCKS5 proxy connects to Anypoint Monitoring over TCP at these endpoints, depending on your control plane: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` 1. Log in to a node where `rtfctl` is installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" ``` - ****: the username needed to authenticate to the SOCKS5 proxy. - ****: the password needed to authenticate to the SOCKS5 proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.2>**: The IP address or hostname used to access the SOCKS5 proxy. - **<8080>**: The host port on the host where the SOCKS5 proxy is listening for requests. 1. To verify the change was successful, run the following command to output the current value of the monitoring proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy ``` The output should match the value expected. 2. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl#validate) documentation. ## Configure an HTTP Proxy for Services in Runtime Fabric You can configure HTTP proxies so that outbound components can communicate with the control plane. You must restart the `rtf-agent` pod and any Mule app that requires a proxy. Although no downtime occurs if you are running multiple replicas, you should perform HTTP proxy updates during a maintenance window. - Apply the proxy values to the services running within Runtime Fabric. - If you are using Runtime Fabric installer 1.0.x, run the script on each node of your Runtime Fabric to update the cluster. 1. Log in to a node where `rtfctl` has been installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" ``` - ****: the username needed to authenticate to the HTTP proxy. - ****: the password needed to authenticate to the HTTP proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.1>**: Specifies the IP address or hostname to access the HTTP proxy. - **<8080>**: Specifies the port on the host where the HTTP proxy is listening for requests. - **<1.1.1.1:8888,2.2.2.2:9999>**: Specifies the `RTF_NO_PROXY` hosts and ports, delimited by commas. - (Optional) `--confirm`: Skips manual acknowledgement of the change. If not specified, the `rtfctl apply proxy` command prompts you to confirm the change before continuing. 1. To verify the change was successful, run the following command to output the current value of the HTTP proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get http-proxy ``` The output should match the value expected. 2. To remove the proxy values, run: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ``` 3. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl#validate) documentation. ### About the HTTP\_PROXY Environment Variable After applying a proxy for services in Runtime Fabric, you could see a warning similar to: Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric generates a warning to let you know that you have not set the `HTTP_PROXY` environment variable or that the variable does not match the value used for Runtime Fabric services. The settings do not have to match, but Runtime Fabric generates the warning so you’re aware services could be impacted. Many Linux tools use the `HTTP_PROXY` environment variable to provide their proxy settings. If your environment requires a proxy for Internet access, you likely need to set the `HTTP_PROXY` environment variable for commands that require Internet access. This could affect other tools that also use HTTP or HTTPS operations but do not require Internet access, such as `kubectl`. You can use the `NO_PROXY` environment variable to establish connections that should not be proxied. Refer to the documentation for your Linux tools for more information on which environment variables affect its proxy behavior. ### About the NO\_PROXY Environment Variable By default, `NO_PROXY` is set to `0.0.0.0/0` and `.local`. These settings ensure that the proxy does not route any IPV4 destination addresses. ## Configure a Proxy for the API Manager Agent You can use a proxy to establish communication for Mule applications that you manage with API Manager. This proxy configuration must be set on each Mule application, even if you are using the same configuration for all applications. Note this setting is independent from the application-level proxy that applications use to communicate with other external endpoints. To configure a proxy for the API Manager Agent, add the following properties to the application: anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## Configure a Proxy for a Mule Application Applications deployed in Runtime Fabric inherit proxy settings from the Runtime Fabric cluster. You can also configure a proxy for each application. You can set up a proxy on each connector (such as an HTTP requestor) or set up a proxy with application properties as shown in the following example. Setting up a proxy with application properties is less work if you have a large number of connectors in an application. http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Proxies on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric uses two types of proxies when running and hosting applications: - System proxies: include proxies that enable connectivity among Kubernetes cluster services, including the Docker daemon and other internal components. When using Runtime Fabric you are responsible for configuring and managing system proxies. - Application proxies: include proxies that enable connectivity to applications running on Runtime Fabric. You can configure the proxy settings used by Runtime Fabric outbound connections to the internet. This includes both HTTP proxies for connecting to the Anypoint Platform control plane and SOCKS5 proxies for sending metrics and logs to Anypoint Monitoring. You can also configure proxies for applications. ## Install rtfctl The `rtfctl` command line tool is required to manage proxy settings on Runtime Fabric. Follow the steps to [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) before configuring proxy settings. > [!NOTE] You can apply proxy settings during installation of Runtime Fabric if you install using > Helm. For more information, refer to the > [Installing Runtime Fabric Using Helm documentation](https://docs.mulesoft.com/runtime-fabric/latest/install-helm). ## Configure an Anypoint Monitoring Proxy For Runtime Fabric deployments on version 2.6.22 and later, Anypoint Monitoring uses an HTTP proxy. Refer to [Configure an HTTP Proxy for Services in Runtime Fabric](#configure-http) for details. For Runtime Fabric versions earlier than 2.6.22 and for legacy deployments, Anypoint Monitoring requires a SOCKS5 proxy. Use these steps for the configuration: The SOCKS5 proxy must connect to Anypoint Monitoring over TCP at the following endpoints: - US Cloud: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU Cloud: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` - Canada Cloud: `ingest.ca1.platform.mulesoft.com` - Japan Cloud: `ingest.jp1.platform.mulesoft.com` - India Cloud: `ingest.in1.platform.mulesoft.com` - Australia Cloud: `ingest.au1.platform.mulesoft.com` - United Kingdom Cloud: `ingest.gb1.platform.mulesoft.com` 1. Log in to a node where `rtfctl` is installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" ``` - ****: the username needed to authenticate to the SOCKS5 proxy. - ****: the password needed to authenticate to the SOCKS5 proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.2>**: The IP address or hostname used to access the SOCKS5 proxy. - **<8080>**: The host port on the host where the SOCKS5 proxy is listening for requests. 1. To verify the change was successful, run the following command to output the current value of the monitoring proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy ``` The output should match the value expected. 2. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#validate) documentation. ## Configure an HTTP Proxy for Services in Runtime Fabric You can configure HTTP proxies so that outbound components can communicate with the control plane. You must restart the `rtf-agent` pod and any Mule app that requires a proxy. Although no downtime occurs if you are running multiple replicas, you should perform HTTP proxy updates during a maintenance window. - Apply the proxy values to the services running within Runtime Fabric. - If you are using Runtime Fabric installer 1.0.x, run the script on each node of your Runtime Fabric to update the cluster. 1. Log in to a node where `rtfctl` has been installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" ``` - ****: the username needed to authenticate to the HTTP proxy. - ****: the password needed to authenticate to the HTTP proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.1>**: Specifies the IP address or hostname to access the HTTP proxy. - **<8080>**: Specifies the port on the host where the HTTP proxy is listening for requests. - **<1.1.1.1:8888,2.2.2.2:9999>**: Specifies the `RTF_NO_PROXY` hosts and ports, delimited by commas. - (Optional) `--confirm`: Skips manual acknowledgement of the change. If not specified, the `rtfctl apply proxy` command prompts you to confirm the change before continuing. 1. To verify the change was successful, run the following command to output the current value of the HTTP proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get http-proxy ``` The output should match the value expected. 2. To remove the proxy values, run: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ``` 3. After setting up the proxy, validate the setup by running the `rtfctl validate` command. See [rtfctl Validate](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#validate) documentation. ### About the HTTP\_PROXY Environment Variable After applying a proxy for services in Runtime Fabric, you could see a warning similar to: Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric generates a warning to let you know that you have not set the `HTTP_PROXY` environment variable or that the variable does not match the value used for Runtime Fabric services. The settings do not have to match, but Runtime Fabric generates the warning so you’re aware services could be impacted. Many Linux tools use the `HTTP_PROXY` environment variable to provide their proxy settings. If your environment requires a proxy for Internet access, you likely need to set the `HTTP_PROXY` environment variable for commands that require Internet access. This could affect other tools that also use HTTP or HTTPS operations but do not require Internet access, such as `kubectl`. You can use the `NO_PROXY` environment variable to establish connections that should not be proxied. Refer to the documentation for your Linux tools for more information on which environment variables affect its proxy behavior. ### About the NO\_PROXY Environment Variable By default, `NO_PROXY` is set to `0.0.0.0/0` and `.local`. These settings ensure that the proxy does not route any IPV4 destination addresses. ## Configure a Proxy for the API Manager Agent You can use a proxy to establish communication for Mule applications that you manage with API Manager. This proxy configuration must be set on each Mule application, even if you are using the same configuration for all applications. Note this setting is independent from the application-level proxy that applications use to communicate with other external endpoints. To configure a proxy for the API Manager Agent, add the following properties to the application: anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## Configure a Proxy for a Mule Application Applications deployed in Runtime Fabric inherit proxy settings from the Runtime Fabric cluster. You can also configure a proxy for each application. You can set up a proxy on each connector (such as an HTTP requestor) or set up a proxy with application properties as shown in this example. Setting up a proxy with application properties is less work if you have a large number of connectors in an application. > [!NOTE] These application properties apply only when the Mule HTTP service uses the Grizzly > implementation. Mule runtime 4.11 and later uses Netty by default. To use this JVM-level proxy > configuration, add the application property `mule.http.service.implementation` with the value > `GRIZZLY` in Runtime Manager. Don’t set it as a `-D` JVM argument. http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true --- product: Runtime Fabric version: 2.10 --- # Configuring Red Hat OpenShift Routes in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric enables you to configure Red Hat OpenShift Routes to create ingress endpoints for your Mule applications. ## Before You Begin Configuration of routes in Runtime Fabric follows closely to ingress resource configuration. Before you create routes, review the following: - [How Ingress Resources Templates Work in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration#how-ingress-resources-templates-work-in-runtime-fabric) - [Example Ingress Resource Templates](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration#example-ingress-resource-templates) - [Creating a route through an Ingress object](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). ## Example Ingress Resource Template for A Red Hat OpenShift Route The following example illustrates how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress resource template for the networking.k8s.io/v1 API. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf #(1) labels: spec: ingressClassName: rtf-openshift #(2) tls: #(3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com #(4) http: paths: #(5) - pathType: Prefix path: / #(6) backend: #(7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, and must be set to rtf-openshift.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example,openshift.

3TLS is optional. If specified in the template, Runtime Fabric creates a route with edge termination by default unless you set the route.openshift.io/termination: annotation.
4Runtime Fabric replaces the app-name placeholder parameter with the actual app name when you deploy the application. This helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6Runtime Fabric replaces the path parameter value with the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a list of optional placeholder values, see [Template Placeholders](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration#template-placeholders). ## Configure A Route in Runtime Fabric To configure a route, complete the following tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule application. ### Create an Ingress Resource Template and Apply it in the Cluster Use the [example template](#example-ingress-resource-template-for-a-red-hat-openshift-route) to create an ingress resource for a route. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### Configure Ingress for a Mule Application You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. After you deploy the application, Runtime Manager creates a route to serve traffic to the application as per the template specified. ## Configure Passthrough TLS Termination You can configure the ingress resource template to include passthrough TLS termination. For more information on configuring routes with passthrough TLS termination, refer to the [Red Hat OpenShift documentation](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). Follow these steps to create an ingress resource template: 1. In the template, add the following annotation: route.openshift.io/termination: passthrough 2. In the template, set the following parameter values: - `path: ''` (an empty string) - `pathType: ImplementationSpecific` 3. In Runtime Manager, when configuring ingress for a Mule app, in the **Path** field include a `/`. The application endpoint will show HTTPS for passthrough TLS termination. ## Configure Reencrypt Termination You can configure the ingress resource template to include reencrypt termination by adding the `route.openshift.io/termination: reencrypt` annotation to the template. Follow these steps to configure reencrypt termination: 1. Create a secret object to hold the destination CA certificate, which can be a self-signed certificate, or chain. The following mule-app.cert file contains a PEM-encoded certificate (chain or self-signed certificate) of the leaf certificate used in target Mule app’s keystore. kubectl -nrtf create secret generic ah-destination-tls \\ --from-file=tls.crt=mule-app.cert 2. Add a label to the secret to propagate it into the Mule app’s namespace. kubectl -n rtf label secret ah-destination-tls "rtf.mulesoft.com/synchronized=true"" 3. Create or delete and re-create the ingress template in Runtime Fabric namespace with the additional `route.openshift.io/destination-ca-certificate-secret:` annotation. \> cat ingress-reencrypt.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: "ah-destination-tls" name: rtf-ingress namespace: rtf labels: spec: ingressClassName: rtf-openshift tls: - hosts: - app-name.andrew.com secretName: ah-tls rules: - host: app-name.andrew.com http: paths: - path: / pathType: Prefix backend: service: name: service-name port: name: service-port 4. In Runtime Manager > Application settings, select the ingress endpoint. If the previous ingress endpoint exists with the same name, remove it, apply changes, then select the new ingress endoint and apply changes again. 5. Check and confirm that the ingress, secret, and routes exist in the Mule app’s namespace. Requests should now be successful. kubectl -n get ingress kubectl -n get routes kubectl -n get secret For example: \> kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ah-app-1-rtf-ingress ah-app-1.andrew.com router-default.apps.ah-rtf-rosa-1.9esk.p1.openshiftapps.com 80, 443 7m30s > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get route NAME HOST/PORT PATH SERVICES PORT > TERMINATION WILDCARD ah-app-1-rtf-ingress-6vhpq ah-app-1.andrew.com / ah-app-1 http > reencrypt/Redirect None > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get secret | grep -i tls ah-destination-tls Opaque > 1 52m ah-tls kubernetes.io/tls 2 131m --- product: Runtime Fabric version: 2.11 --- # Configuring Red Hat OpenShift Routes in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric enables you to configure Red Hat OpenShift Routes to create ingress endpoints for your Mule applications. ## Before You Begin Configuration of routes in Runtime Fabric follows closely to ingress resource configuration. Before you create routes, review this: - [How Ingress Resources Templates Work in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration#how-ingress-resources-templates-work-in-runtime-fabric) - [Example Ingress Resource Templates](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration#example-ingress-resource-templates) - [Creating a route through an Ingress object](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). ## Example Ingress Resource Template for A Red Hat OpenShift Route The following example illustrates how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress resource template for the networking.k8s.io/v1 API. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf #(1) labels: spec: ingressClassName: rtf-openshift #(2) tls: #(3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com #(4) http: paths: #(5) - pathType: Prefix path: / #(6) backend: #(7) service: name: service-name port: name: service-port ``` Note this about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, and must be set to rtf-openshift.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example,openshift.

3TLS is optional. If specified in the template, Runtime Fabric creates a route with edge termination by default unless you set the route.openshift.io/termination: annotation.
4Runtime Fabric replaces the app-name placeholder parameter with the actual app name when you deploy the application. This helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6Runtime Fabric replaces the path parameter value with the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a list of optional placeholder values, see [Template Placeholders](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration#template-placeholders). ## Configure A Route in Runtime Fabric To configure a route, complete these tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule application. ### Create an Ingress Resource Template and Apply it in the Cluster Use the [example template](#example-ingress-resource-template-for-a-red-hat-openshift-route) to create an ingress resource for a route. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### Configure Ingress for a Mule Application You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. After you deploy the application, Runtime Manager creates a route to serve traffic to the application as per the template specified. ## Configure Passthrough TLS Termination You can configure the ingress resource template to include passthrough TLS termination. For more information on configuring routes with passthrough TLS termination, refer to the [Red Hat OpenShift documentation](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). Follow these steps to create an ingress resource template: 1. In the template, add this annotation: route.openshift.io/termination: passthrough 2. In the template, set these parameter values: - `path: ''` (an empty string) - `pathType: ImplementationSpecific` 3. In Runtime Manager, when configuring ingress for a Mule app, in the **Path** field include a `/`. The application endpoint will show HTTPS for passthrough TLS termination. ## Configure Reencrypt Termination You can configure the ingress resource template to include reencrypt termination by adding the `route.openshift.io/termination: reencrypt` annotation to the template. Follow these steps to configure reencrypt termination: 1. Create a secret object to hold the destination CA certificate, which can be a self-signed certificate, or chain. The following mule-app.cert file contains a PEM-encoded certificate (chain or self-signed certificate) of the leaf certificate used in target Mule app’s keystore. kubectl -nrtf create secret generic ah-destination-tls \\ --from-file=tls.crt=mule-app.cert 2. Add a label to the secret to propagate it into the Mule app’s namespace. kubectl -n rtf label secret ah-destination-tls "rtf.mulesoft.com/synchronized=true"" 3. Create or delete and re-create the ingress template in Runtime Fabric namespace with the additional `route.openshift.io/destination-ca-certificate-secret:` annotation. \> cat ingress-reencrypt.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: "ah-destination-tls" name: rtf-ingress namespace: rtf labels: spec: ingressClassName: rtf-openshift tls: - hosts: - app-name.andrew.com secretName: ah-tls rules: - host: app-name.andrew.com http: paths: - path: / pathType: Prefix backend: service: name: service-name port: name: service-port 4. In Runtime Manager > Application settings, select the ingress endpoint. If the previous ingress endpoint exists with the same name, remove it, apply changes, then select the new ingress endoint and apply changes again. 5. Check and confirm that the ingress, secret, and routes exist in the Mule app’s namespace. Requests should now be successful. kubectl -n get ingress kubectl -n get routes kubectl -n get secret For example: \> kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ah-app-1-rtf-ingress ah-app-1.andrew.com router-default.apps.ah-rtf-rosa-1.9esk.p1.openshiftapps.com 80, 443 7m30s > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get route NAME HOST/PORT PATH SERVICES PORT > TERMINATION WILDCARD ah-app-1-rtf-ingress-6vhpq ah-app-1.andrew.com / ah-app-1 http > reencrypt/Redirect None > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get secret | grep -i tls ah-destination-tls Opaque > 1 52m ah-tls kubernetes.io/tls 2 131m --- product: Runtime Fabric version: 2.5 --- # Configuring Red Hat OpenShift Routes in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric enables you to configure Red Hat OpenShift Routes to create ingress endpoints for your Mule applications. ## Before You Begin Configuration of routes in Runtime Fabric follows closely to ingress resource configuration. Before you create routes, review the following: - [How Ingress Resources Templates Work in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/custom-ingress-configuration#how-ingress-resources-templates-work-in-runtime-fabric) - [Example Ingress Resource Templates](https://docs.mulesoft.com/runtime-fabric/2.5/custom-ingress-configuration#example-ingress-resource-templates) - [Creating a route through an Ingress object](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). ## Example Ingress Resource Template for A Red Hat OpenShift Route The following example illustrates how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress resource template for the networking.k8s.io/v1 API. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf #(1) labels: spec: ingressClassName: rtf-openshift #(2) tls: #(3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com #(4) http: paths: #(5) - pathType: Prefix path: / #(6) backend: #(7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, and must be set to rtf-openshift.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example,openshift.

3TLS is optional. If specified in the template, Runtime Fabric creates a route with edge termination by default unless you set the route.openshift.io/termination: annotation.
4Runtime Fabric replaces the app-name placeholder parameter with the actual app name when you deploy the application. This helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6Runtime Fabric replaces the path parameter value with the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a list of optional placeholder values, see [Template Placeholders](https://docs.mulesoft.com/runtime-fabric/2.5/custom-ingress-configuration#template-placeholders). ## Configure A Route in Runtime Fabric To configure a route, complete the following tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule application. ### Create an Ingress Resource Template and Apply it in the Cluster Use the [example template](#example-ingress-resource-template-for-a-red-hat-openshift-route) to create an ingress resource for a route. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### Configure Ingress for a Mule Application You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. After you deploy the application, Runtime Manager creates a route to serve traffic to the application as per the template specified. ## Configure Passthrough TLS Termination You can configure the ingress resource template to include passthrough TLS termination. For more information on configuring routes with passthrough TLS termination, refer to the [Red Hat OpenShift documentation](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). Follow these steps to create an ingress resource template: 1. In the template, add the following annotation: route.openshift.io/termination: passthrough 2. In the template, set the following parameter values: - `path: ''` (an empty string) - `pathType: ImplementationSpecific` 3. In Runtime Manager, when configuring ingress for a Mule app, in the **Path** field include a `/`. The application endpoint will show HTTPS for passthrough TLS termination. ## Configure Reencrypt Termination You can configure the ingress resource template to include reencrypt termination by adding the `route.openshift.io/termination: reencrypt` annotation to the template. Follow these steps to configure reencrypt termination: 1. Create a secret object to hold the destination CA certificate, which can be a self-signed certificate, or chain. The following mule-app.cert file contains a PEM-encoded certificate (chain or self-signed certificate) of the leaf certificate used in target Mule app’s keystore. kubectl -nrtf create secret generic ah-destination-tls \\ --from-file=tls.crt=mule-app.cert 2. Add a label to the secret to propagate it into the Mule app’s namespace. kubectl -n rtf label secret ah-destination-tls "rtf.mulesoft.com/synchronized=true"" 3. Create or delete and re-create the ingress template in Runtime Fabric namespace with the additional `route.openshift.io/destination-ca-certificate-secret:` annotation. \> cat ingress-reencrypt.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: "ah-destination-tls" name: rtf-ingress namespace: rtf labels: spec: ingressClassName: rtf-openshift tls: - hosts: - app-name.andrew.com secretName: ah-tls rules: - host: app-name.andrew.com http: paths: - path: / pathType: Prefix backend: service: name: service-name port: name: service-port 4. In Runtime Manager > Application settings, select the ingress endpoint. If the previous ingress endpoint exists with the same name, remove it, apply changes, then select the new ingress endoint and apply changes again. 5. Check and confirm that the ingress, secret, and routes exist in the Mule app’s namespace. Requests should now be successful. kubectl -n get ingress kubectl -n get routes kubectl -n get secret For example: \> kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ah-app-1-rtf-ingress ah-app-1.andrew.com router-default.apps.ah-rtf-rosa-1.9esk.p1.openshiftapps.com 80, 443 7m30s > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get route NAME HOST/PORT PATH SERVICES PORT > TERMINATION WILDCARD ah-app-1-rtf-ingress-6vhpq ah-app-1.andrew.com / ah-app-1 http > reencrypt/Redirect None > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get secret | grep -i tls ah-destination-tls Opaque > 1 52m ah-tls kubernetes.io/tls 2 131m --- product: Runtime Fabric version: 2.6 --- # Configuring Red Hat OpenShift Routes in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric enables you to configure Red Hat OpenShift Routes to create ingress endpoints for your Mule applications. ## Before You Begin Configuration of routes in Runtime Fabric follows closely to ingress resource configuration. Before you create routes, review the following: - [How Ingress Resources Templates Work in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration#how-ingress-resources-templates-work-in-runtime-fabric) - [Example Ingress Resource Templates](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration#example-ingress-resource-templates) - [Creating a route through an Ingress object](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). ## Example Ingress Resource Template for A Red Hat OpenShift Route The following example illustrates how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress resource template for the networking.k8s.io/v1 API. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf #(1) labels: spec: ingressClassName: rtf-openshift #(2) tls: #(3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com #(4) http: paths: #(5) - pathType: Prefix path: / #(6) backend: #(7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, and must be set to rtf-openshift.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example,openshift.

3TLS is optional. If specified in the template, Runtime Fabric creates a route with edge termination by default unless you set the route.openshift.io/termination: annotation.
4Runtime Fabric replaces the app-name placeholder parameter with the actual app name when you deploy the application. This helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6Runtime Fabric replaces the path parameter value with the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a list of optional placeholder values, see [Template Placeholders](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration#template-placeholders). ## Configure A Route in Runtime Fabric To configure a route, complete the following tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule application. ### Create an Ingress Resource Template and Apply it in the Cluster Use the [example template](#example-ingress-resource-template-for-a-red-hat-openshift-route) to create an ingress resource for a route. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### Configure Ingress for a Mule Application You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. After you deploy the application, Runtime Manager creates a route to serve traffic to the application as per the template specified. ## Configure Passthrough TLS Termination You can configure the ingress resource template to include passthrough TLS termination. For more information on configuring routes with passthrough TLS termination, refer to the [Red Hat OpenShift documentation](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). Follow these steps to create an ingress resource template: 1. In the template, add the following annotation: route.openshift.io/termination: passthrough 2. In the template, set the following parameter values: - `path: ''` (an empty string) - `pathType: ImplementationSpecific` 3. In Runtime Manager, when configuring ingress for a Mule app, in the **Path** field include a `/`. The application endpoint will show HTTPS for passthrough TLS termination. ## Configure Reencrypt Termination You can configure the ingress resource template to include reencrypt termination by adding the `route.openshift.io/termination: reencrypt` annotation to the template. Follow these steps to configure reencrypt termination: 1. Create a secret object to hold the destination CA certificate, which can be a self-signed certificate, or chain. The following mule-app.cert file contains a PEM-encoded certificate (chain or self-signed certificate) of the leaf certificate used in target Mule app’s keystore. kubectl -nrtf create secret generic ah-destination-tls \\ --from-file=tls.crt=mule-app.cert 2. Add a label to the secret to propagate it into the Mule app’s namespace. kubectl -n rtf label secret ah-destination-tls "rtf.mulesoft.com/synchronized=true"" 3. Create or delete and re-create the ingress template in Runtime Fabric namespace with the additional `route.openshift.io/destination-ca-certificate-secret:` annotation. \> cat ingress-reencrypt.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: "ah-destination-tls" name: rtf-ingress namespace: rtf labels: spec: ingressClassName: rtf-openshift tls: - hosts: - app-name.andrew.com secretName: ah-tls rules: - host: app-name.andrew.com http: paths: - path: / pathType: Prefix backend: service: name: service-name port: name: service-port 4. In Runtime Manager > Application settings, select the ingress endpoint. If the previous ingress endpoint exists with the same name, remove it, apply changes, then select the new ingress endoint and apply changes again. 5. Check and confirm that the ingress, secret, and routes exist in the Mule app’s namespace. Requests should now be successful. kubectl -n get ingress kubectl -n get routes kubectl -n get secret For example: \> kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ah-app-1-rtf-ingress ah-app-1.andrew.com router-default.apps.ah-rtf-rosa-1.9esk.p1.openshiftapps.com 80, 443 7m30s > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get route NAME HOST/PORT PATH SERVICES PORT > TERMINATION WILDCARD ah-app-1-rtf-ingress-6vhpq ah-app-1.andrew.com / ah-app-1 http > reencrypt/Redirect None > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get secret | grep -i tls ah-destination-tls Opaque > 1 52m ah-tls kubernetes.io/tls 2 131m --- product: Runtime Fabric version: 2.7 --- # Configuring Red Hat OpenShift Routes in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric enables you to configure Red Hat OpenShift Routes to create ingress endpoints for your Mule applications. ## Before You Begin Configuration of routes in Runtime Fabric follows closely to ingress resource configuration. Before you create routes, review the following: - [How Ingress Resources Templates Work in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration#how-ingress-resources-templates-work-in-runtime-fabric) - [Example Ingress Resource Templates](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration#example-ingress-resource-templates) - [Creating a route through an Ingress object](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). ## Example Ingress Resource Template for A Red Hat OpenShift Route The following example illustrates how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress resource template for the networking.k8s.io/v1 API. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf #(1) labels: spec: ingressClassName: rtf-openshift #(2) tls: #(3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com #(4) http: paths: #(5) - pathType: Prefix path: / #(6) backend: #(7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, and must be set to rtf-openshift.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example,openshift.

3TLS is optional. If specified in the template, Runtime Fabric creates a route with edge termination by default unless you set the route.openshift.io/termination: annotation.
4Runtime Fabric replaces the app-name placeholder parameter with the actual app name when you deploy the application. This helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6Runtime Fabric replaces the path parameter value with the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a list of optional placeholder values, see [Template Placeholders](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration#template-placeholders). ## Configure A Route in Runtime Fabric To configure a route, complete the following tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule application. ### Create an Ingress Resource Template and Apply it in the Cluster Use the [example template](#example-ingress-resource-template-for-a-red-hat-openshift-route) to create an ingress resource for a route. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### Configure Ingress for a Mule Application You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. After you deploy the application, Runtime Manager creates a route to serve traffic to the application as per the template specified. ## Configure Passthrough TLS Termination You can configure the ingress resource template to include passthrough TLS termination. For more information on configuring routes with passthrough TLS termination, refer to the [Red Hat OpenShift documentation](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). Follow these steps to create an ingress resource template: 1. In the template, add the following annotation: route.openshift.io/termination: passthrough 2. In the template, set the following parameter values: - `path: ''` (an empty string) - `pathType: ImplementationSpecific` 3. In Runtime Manager, when configuring ingress for a Mule app, in the **Path** field include a `/`. The application endpoint will show HTTPS for passthrough TLS termination. ## Configure Reencrypt Termination You can configure the ingress resource template to include reencrypt termination by adding the `route.openshift.io/termination: reencrypt` annotation to the template. Follow these steps to configure reencrypt termination: 1. Create a secret object to hold the destination CA certificate, which can be a self-signed certificate, or chain. The following mule-app.cert file contains a PEM-encoded certificate (chain or self-signed certificate) of the leaf certificate used in target Mule app’s keystore. kubectl -nrtf create secret generic ah-destination-tls \\ --from-file=tls.crt=mule-app.cert 2. Add a label to the secret to propagate it into the Mule app’s namespace. kubectl -n rtf label secret ah-destination-tls "rtf.mulesoft.com/synchronized=true"" 3. Create or delete and re-create the ingress template in Runtime Fabric namespace with the additional `route.openshift.io/destination-ca-certificate-secret:` annotation. \> cat ingress-reencrypt.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: "ah-destination-tls" name: rtf-ingress namespace: rtf labels: spec: ingressClassName: rtf-openshift tls: - hosts: - app-name.andrew.com secretName: ah-tls rules: - host: app-name.andrew.com http: paths: - path: / pathType: Prefix backend: service: name: service-name port: name: service-port 4. In Runtime Manager > Application settings, select the ingress endpoint. If the previous ingress endpoint exists with the same name, remove it, apply changes, then select the new ingress endoint and apply changes again. 5. Check and confirm that the ingress, secret, and routes exist in the Mule app’s namespace. Requests should now be successful. kubectl -n get ingress kubectl -n get routes kubectl -n get secret For example: \> kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ah-app-1-rtf-ingress ah-app-1.andrew.com router-default.apps.ah-rtf-rosa-1.9esk.p1.openshiftapps.com 80, 443 7m30s > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get route NAME HOST/PORT PATH SERVICES PORT > TERMINATION WILDCARD ah-app-1-rtf-ingress-6vhpq ah-app-1.andrew.com / ah-app-1 http > reencrypt/Redirect None > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get secret | grep -i tls ah-destination-tls Opaque > 1 52m ah-tls kubernetes.io/tls 2 131m --- product: Runtime Fabric version: 2.8 --- # Configuring Red Hat OpenShift Routes in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric enables you to configure Red Hat OpenShift Routes to create ingress endpoints for your Mule applications. ## Before You Begin Configuration of routes in Runtime Fabric follows closely to ingress resource configuration. Before you create routes, review the following: - [How Ingress Resources Templates Work in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration#how-ingress-resources-templates-work-in-runtime-fabric) - [Example Ingress Resource Templates](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration#example-ingress-resource-templates) - [Creating a route through an Ingress object](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). ## Example Ingress Resource Template for A Red Hat OpenShift Route The following example illustrates how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress resource template for the networking.k8s.io/v1 API. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf #(1) labels: spec: ingressClassName: rtf-openshift #(2) tls: #(3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com #(4) http: paths: #(5) - pathType: Prefix path: / #(6) backend: #(7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, and must be set to rtf-openshift.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example,openshift.

3TLS is optional. If specified in the template, Runtime Fabric creates a route with edge termination by default unless you set the route.openshift.io/termination: annotation.
4Runtime Fabric replaces the app-name placeholder parameter with the actual app name when you deploy the application. This helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6Runtime Fabric replaces the path parameter value with the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a list of optional placeholder values, see [Template Placeholders](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration#template-placeholders). ## Configure A Route in Runtime Fabric To configure a route, complete the following tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule application. ### Create an Ingress Resource Template and Apply it in the Cluster Use the [example template](#example-ingress-resource-template-for-a-red-hat-openshift-route) to create an ingress resource for a route. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### Configure Ingress for a Mule Application You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. After you deploy the application, Runtime Manager creates a route to serve traffic to the application as per the template specified. ## Configure Passthrough TLS Termination You can configure the ingress resource template to include passthrough TLS termination. For more information on configuring routes with passthrough TLS termination, refer to the [Red Hat OpenShift documentation](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). Follow these steps to create an ingress resource template: 1. In the template, add the following annotation: route.openshift.io/termination: passthrough 2. In the template, set the following parameter values: - `path: ''` (an empty string) - `pathType: ImplementationSpecific` 3. In Runtime Manager, when configuring ingress for a Mule app, in the **Path** field include a `/`. The application endpoint will show HTTPS for passthrough TLS termination. ## Configure Reencrypt Termination You can configure the ingress resource template to include reencrypt termination by adding the `route.openshift.io/termination: reencrypt` annotation to the template. Follow these steps to configure reencrypt termination: 1. Create a secret object to hold the destination CA certificate, which can be a self-signed certificate, or chain. The following mule-app.cert file contains a PEM-encoded certificate (chain or self-signed certificate) of the leaf certificate used in target Mule app’s keystore. kubectl -nrtf create secret generic ah-destination-tls \\ --from-file=tls.crt=mule-app.cert 2. Add a label to the secret to propagate it into the Mule app’s namespace. kubectl -n rtf label secret ah-destination-tls "rtf.mulesoft.com/synchronized=true"" 3. Create or delete and re-create the ingress template in Runtime Fabric namespace with the additional `route.openshift.io/destination-ca-certificate-secret:` annotation. \> cat ingress-reencrypt.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: "ah-destination-tls" name: rtf-ingress namespace: rtf labels: spec: ingressClassName: rtf-openshift tls: - hosts: - app-name.andrew.com secretName: ah-tls rules: - host: app-name.andrew.com http: paths: - path: / pathType: Prefix backend: service: name: service-name port: name: service-port 4. In Runtime Manager > Application settings, select the ingress endpoint. If the previous ingress endpoint exists with the same name, remove it, apply changes, then select the new ingress endoint and apply changes again. 5. Check and confirm that the ingress, secret, and routes exist in the Mule app’s namespace. Requests should now be successful. kubectl -n get ingress kubectl -n get routes kubectl -n get secret For example: \> kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ah-app-1-rtf-ingress ah-app-1.andrew.com router-default.apps.ah-rtf-rosa-1.9esk.p1.openshiftapps.com 80, 443 7m30s > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get route NAME HOST/PORT PATH SERVICES PORT > TERMINATION WILDCARD ah-app-1-rtf-ingress-6vhpq ah-app-1.andrew.com / ah-app-1 http > reencrypt/Redirect None > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get secret | grep -i tls ah-destination-tls Opaque > 1 52m ah-tls kubernetes.io/tls 2 131m --- product: Runtime Fabric version: 2.9 --- # Configuring Red Hat OpenShift Routes in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric enables you to configure Red Hat OpenShift Routes to create ingress endpoints for your Mule applications. ## Before You Begin Configuration of routes in Runtime Fabric follows closely to ingress resource configuration. Before you create routes, review the following: - [How Ingress Resources Templates Work in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration#how-ingress-resources-templates-work-in-runtime-fabric) - [Example Ingress Resource Templates](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration#example-ingress-resource-templates) - [Creating a route through an Ingress object](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). ## Example Ingress Resource Template for A Red Hat OpenShift Route The following example illustrates how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress resource template for the networking.k8s.io/v1 API. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf #(1) labels: spec: ingressClassName: rtf-openshift #(2) tls: #(3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com #(4) http: paths: #(5) - pathType: Prefix path: / #(6) backend: #(7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, and must be set to rtf-openshift.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example,openshift.

3TLS is optional. If specified in the template, Runtime Fabric creates a route with edge termination by default unless you set the route.openshift.io/termination: annotation.
4Runtime Fabric replaces the app-name placeholder parameter with the actual app name when you deploy the application. This helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6Runtime Fabric replaces the path parameter value with the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a list of optional placeholder values, see [Template Placeholders](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration#template-placeholders). ## Configure A Route in Runtime Fabric To configure a route, complete the following tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule application. ### Create an Ingress Resource Template and Apply it in the Cluster Use the [example template](#example-ingress-resource-template-for-a-red-hat-openshift-route) to create an ingress resource for a route. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### Configure Ingress for a Mule Application You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. After you deploy the application, Runtime Manager creates a route to serve traffic to the application as per the template specified. ## Configure Passthrough TLS Termination You can configure the ingress resource template to include passthrough TLS termination. For more information on configuring routes with passthrough TLS termination, refer to the [Red Hat OpenShift documentation](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). Follow these steps to create an ingress resource template: 1. In the template, add the following annotation: route.openshift.io/termination: passthrough 2. In the template, set the following parameter values: - `path: ''` (an empty string) - `pathType: ImplementationSpecific` 3. In Runtime Manager, when configuring ingress for a Mule app, in the **Path** field include a `/`. The application endpoint will show HTTPS for passthrough TLS termination. ## Configure Reencrypt Termination You can configure the ingress resource template to include reencrypt termination by adding the `route.openshift.io/termination: reencrypt` annotation to the template. Follow these steps to configure reencrypt termination: 1. Create a secret object to hold the destination CA certificate, which can be a self-signed certificate, or chain. The following mule-app.cert file contains a PEM-encoded certificate (chain or self-signed certificate) of the leaf certificate used in target Mule app’s keystore. kubectl -nrtf create secret generic ah-destination-tls \\ --from-file=tls.crt=mule-app.cert 2. Add a label to the secret to propagate it into the Mule app’s namespace. kubectl -n rtf label secret ah-destination-tls "rtf.mulesoft.com/synchronized=true"" 3. Create or delete and re-create the ingress template in Runtime Fabric namespace with the additional `route.openshift.io/destination-ca-certificate-secret:` annotation. \> cat ingress-reencrypt.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: "ah-destination-tls" name: rtf-ingress namespace: rtf labels: spec: ingressClassName: rtf-openshift tls: - hosts: - app-name.andrew.com secretName: ah-tls rules: - host: app-name.andrew.com http: paths: - path: / pathType: Prefix backend: service: name: service-name port: name: service-port 4. In Runtime Manager > Application settings, select the ingress endpoint. If the previous ingress endpoint exists with the same name, remove it, apply changes, then select the new ingress endoint and apply changes again. 5. Check and confirm that the ingress, secret, and routes exist in the Mule app’s namespace. Requests should now be successful. kubectl -n get ingress kubectl -n get routes kubectl -n get secret For example: \> kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ah-app-1-rtf-ingress ah-app-1.andrew.com router-default.apps.ah-rtf-rosa-1.9esk.p1.openshiftapps.com 80, 443 7m30s > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get route NAME HOST/PORT PATH SERVICES PORT > TERMINATION WILDCARD ah-app-1-rtf-ingress-6vhpq ah-app-1.andrew.com / ah-app-1 http > reencrypt/Redirect None > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get secret | grep -i tls ah-destination-tls Opaque > 1 52m ah-tls kubernetes.io/tls 2 131m --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Red Hat OpenShift Routes in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric enables you to configure Red Hat OpenShift Routes to create ingress endpoints for your Mule applications. ## Before You Begin Configuration of routes in Runtime Fabric follows closely to ingress resource configuration. Before you create routes, review the following: - [How Ingress Resources Templates Work in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration#how-ingress-resources-templates-work-in-runtime-fabric) - [Example Ingress Resource Templates](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration#example-ingress-resource-templates) - [Creating a route through an Ingress object](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). ## Example Ingress Resource Template for A Red Hat OpenShift Route The following example illustrates how to modify a Kubernetes ingress spec to create a Runtime Fabric ingress resource template for the networking.k8s.io/v1 API. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf #(1) labels: spec: ingressClassName: rtf-openshift #(2) tls: #(3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com #(4) http: paths: #(5) - pathType: Prefix path: / #(6) backend: #(7) service: name: service-name port: name: service-port ``` Note the following about this example:
1The template must be placed in the rtf namespace.
2ingressClassName must be prefixed with rtf-, and must be set to rtf-openshift.

Runtime Fabric uses the rtf- prefix to recognize the object as a template. Templates with rtf- prefix in the spec.ingressClassName field or in the kubernetes.io/ingress.class annotation are consumed by the Runtime Fabric agent only and not by the actual ingress controller. Ingress controllers discover only those resources with a spec.ingressClassName value that use the vendor-specific name, for example,openshift.

3TLS is optional. If specified in the template, Runtime Fabric creates a route with edge termination by default unless you set the route.openshift.io/termination: annotation.
4Runtime Fabric replaces the app-name placeholder parameter with the actual app name when you deploy the application. This helps to ensure that each endpoint name is unique if there is not a wildcard in the subdomain.
5A template can include multiple paths for a host, but Runtime Manager displays only the first path rule for the host.
6Runtime Fabric replaces the path parameter value with the value you add in the Path field when you configure ingress for a Mule application. Note that path is not a placeholder.
7These placeholder values are required for Kubernetes validation, but the actual values are not used by Runtime Fabric.
For a list of optional placeholder values, see [Template Placeholders](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration#template-placeholders). ## Configure A Route in Runtime Fabric To configure a route, complete the following tasks: 1. Create an ingress resource template and apply it in the cluster. 2. Configure ingress for a Mule application. ### Create an Ingress Resource Template and Apply it in the Cluster Use the [example template](#example-ingress-resource-template-for-a-red-hat-openshift-route) to create an ingress resource for a route. 1. Copy the example template into a new file and modify it according to the notes. 2. Include a `.yaml` extension in the file name. 3. To apply an ingress template, run: ```copy kubectl apply -f ``` If there is an issue in the template, Kubernetes `api-server` returns an error and the command fails. After you apply a template successfully, you can view it with: ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### Configure Ingress for a Mule Application You configure ingress for an application when you deploy it to Runtime Fabric using Runtime Manager. Available hosts and paths for an application come from the ingress resource template configured by the Runtime Fabric administrator. You can also use this procedure to deploy a test application to validate your ingress resource template. > [!NOTE] The following provides an overview of how to configure ingress for an application. Refer > to [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) for complete deployment > instructions. If you are using the Mule Maven plugin to deploy applications to Runtime Fabric, the > deployment settings parameter `publicUrl` in the block `http` can accept a comma-delimited string > of multiple endpoints. For more information, see > [deploymentSettings Parameters Reference](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference). 1. Navigate to Runtime Manager and follow the documentation to deploy an application to Runtime Fabric. 2. Select **Ingress**. 3. From the **Host** drop-down list, select a host for the application. 4. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 5. In the **Path** field, add a URL path to the application’s endpoint: ![The host and path fields are populated for the endpoint](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-ingress-endpoint.png) 6. To preview the endpoint, click the generated preview link. 7. To add additional endpoints, click **\+ Add Endpoint**. 8. When ready, click **Deploy application**. After you deploy the application, Runtime Manager creates a route to serve traffic to the application as per the template specified. ## Configure Passthrough TLS Termination You can configure the ingress resource template to include passthrough TLS termination. For more information on configuring routes with passthrough TLS termination, refer to the [Red Hat OpenShift documentation](https://docs.openshift.com/en/container-platform/4.10/networking/routes/route-configuration.html). Follow these steps to create an ingress resource template: 1. In the template, add the following annotation: route.openshift.io/termination: passthrough 2. In the template, set the following parameter values: - `path: ''` (an empty string) - `pathType: ImplementationSpecific` 3. In Runtime Manager, when configuring ingress for a Mule app, in the **Path** field include a `/`. The application endpoint will show HTTPS for passthrough TLS termination. ## Configure Reencrypt Termination You can configure the ingress resource template to include reencrypt termination by adding the `route.openshift.io/termination: reencrypt` annotation to the template. Follow these steps to configure reencrypt termination: 1. Create a secret object to hold the destination CA certificate, which can be a self-signed certificate, or chain. The following mule-app.cert file contains a PEM-encoded certificate (chain or self-signed certificate) of the leaf certificate used in target Mule app’s keystore. kubectl -nrtf create secret generic ah-destination-tls \\ --from-file=tls.crt=mule-app.cert 2. Add a label to the secret to propagate it into the Mule app’s namespace. kubectl -n rtf label secret ah-destination-tls "rtf.mulesoft.com/synchronized=true"" 3. Create or delete and re-create the ingress template in Runtime Fabric namespace with the additional `route.openshift.io/destination-ca-certificate-secret:` annotation. \> cat ingress-reencrypt.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: "ah-destination-tls" name: rtf-ingress namespace: rtf labels: spec: ingressClassName: rtf-openshift tls: - hosts: - app-name.andrew.com secretName: ah-tls rules: - host: app-name.andrew.com http: paths: - path: / pathType: Prefix backend: service: name: service-name port: name: service-port 4. In Runtime Manager > Application settings, select the ingress endpoint. If the previous ingress endpoint exists with the same name, remove it, apply changes, then select the new ingress endoint and apply changes again. 5. Check and confirm that the ingress, secret, and routes exist in the Mule app’s namespace. Requests should now be successful. kubectl -n get ingress kubectl -n get routes kubectl -n get secret For example: \> kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ah-app-1-rtf-ingress ah-app-1.andrew.com router-default.apps.ah-rtf-rosa-1.9esk.p1.openshiftapps.com 80, 443 7m30s > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get route NAME HOST/PORT PATH SERVICES PORT > TERMINATION WILDCARD ah-app-1-rtf-ingress-6vhpq ah-app-1.andrew.com / ah-app-1 http > reencrypt/Redirect None > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get secret | grep -i tls ah-destination-tls Opaque > 1 52m ah-tls kubernetes.io/tls 2 131m --- product: Runtime Fabric version: 2.10 --- # Configuring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Anypoint Runtime Fabric, review the following topics: - [Associating Business Groups and Environments](https://docs.mulesoft.com/runtime-fabric/2.10/associate-environments) Associate a Runtime Fabric with one or more Anypoint Platform environments before deploying a Mule app or API proxy. - [Configuring Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl#configure-rtfctl) Use `rtfctl apply`, `update`, and `wait` commands to configure Runtime Fabric. - [Configuring Ingress](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration) Customize ingress configurations using an ingress resource template. - [Configuring Red Hat OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.10/configure-openshift-routes) Configure Red Hat OpenShift Routes to create ingress endpoints for your Mule apps. - [Configuring Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.10/persistence-gateway) Use Persistence Gateway, which enables Mule apps deployed to a Mule runtime instance to store and share data across application replicas and restarts. - [Configuring Proxies](https://docs.mulesoft.com/runtime-fabric/2.10/manage-proxy-self) Configure proxies when running and hosting Mule apps deployed to Runtime Fabric. - [Configuring Horizontal Pod Autoscaling (HPA)](https://docs.mulesoft.com/runtime-fabric/2.10/configure-horizontal-autoscaling) Configure horizontal autoscaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. --- product: Runtime Fabric version: 2.11 --- # Configuring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Anypoint Runtime Fabric, review these topics: - [Associating Business Groups and Environments](https://docs.mulesoft.com/runtime-fabric/2.11/associate-environments) Associate a Runtime Fabric with one or more Anypoint Platform environments before deploying a Mule app or API proxy. - [Configuring Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl#configure-rtfctl) Use `rtfctl apply`, `update`, and `wait` commands to configure Runtime Fabric. - [Configuring Ingress](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration) Customize ingress configurations using an ingress resource template. - [Configuring Red Hat OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.11/configure-openshift-routes) Configure Red Hat OpenShift Routes to create ingress endpoints for your Mule apps. - [Configuring Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.11/persistence-gateway) Use Persistence Gateway, which enables Mule apps deployed to a Mule runtime instance to store and share data across application replicas and restarts. - [Configuring Proxies](https://docs.mulesoft.com/runtime-fabric/2.11/manage-proxy-self) Configure proxies when running and hosting Mule apps deployed to Runtime Fabric. - [Configuring Horizontal Pod Autoscaling (HPA)](https://docs.mulesoft.com/runtime-fabric/2.11/configure-horizontal-autoscaling) Configure horizontal autoscaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. --- product: Runtime Fabric version: 2.6 --- # Configuring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Anypoint Runtime Fabric, review the following topics: - [Associating Business Groups and Environments](https://docs.mulesoft.com/runtime-fabric/2.6/associate-environments) Associate a Runtime Fabric with one or more Anypoint Platform environments before deploying a Mule app or API proxy. - [Configuring Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl#configure-rtfctl) Use `rtfctl apply`, `update`, and `wait` commands to configure Runtime Fabric. - [Configuring Ingress](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration) Customize ingress configurations using an ingress resource template. - [Configuring Red Hat OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.6/configure-openshift-routes) Configure Red Hat OpenShift Routes to create ingress endpoints for your Mule apps. - [Configuring Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.6/persistence-gateway) Use Persistence Gateway, which enables Mule apps deployed to a Mule runtime instance to store and share data across application replicas and restarts. - [Configuring Proxies](https://docs.mulesoft.com/runtime-fabric/2.6/manage-proxy-self) Configure proxies when running and hosting Mule apps deployed to Runtime Fabric. - [Configuring Horizontal Pod Autoscaling (HPA)](https://docs.mulesoft.com/runtime-fabric/2.6/configure-horizontal-autoscaling) Configure horizontal autoscaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. --- product: Runtime Fabric version: 2.7 --- # Configuring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Anypoint Runtime Fabric, review the following topics: - [Associating Business Groups and Environments](https://docs.mulesoft.com/runtime-fabric/2.7/associate-environments) Associate a Runtime Fabric with one or more Anypoint Platform environments before deploying a Mule app or API proxy. - [Configuring Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl#configure-rtfctl) Use `rtfctl apply`, `update`, and `wait` commands to configure Runtime Fabric. - [Configuring Ingress](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration) Customize ingress configurations using an ingress resource template. - [Configuring Red Hat OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.7/configure-openshift-routes) Configure Red Hat OpenShift Routes to create ingress endpoints for your Mule apps. - [Configuring Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.7/persistence-gateway) Use Persistence Gateway, which enables Mule apps deployed to a Mule runtime instance to store and share data across application replicas and restarts. - [Configuring Proxies](https://docs.mulesoft.com/runtime-fabric/2.7/manage-proxy-self) Configure proxies when running and hosting Mule apps deployed to Runtime Fabric. - [Configuring Horizontal Pod Autoscaling (HPA)](https://docs.mulesoft.com/runtime-fabric/2.7/configure-horizontal-autoscaling) Configure horizontal autoscaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. --- product: Runtime Fabric version: 2.8 --- # Configuring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Anypoint Runtime Fabric, review the following topics: - [Associating Business Groups and Environments](https://docs.mulesoft.com/runtime-fabric/2.8/associate-environments) Associate a Runtime Fabric with one or more Anypoint Platform environments before deploying a Mule app or API proxy. - [Configuring Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl#configure-rtfctl) Use `rtfctl apply`, `update`, and `wait` commands to configure Runtime Fabric. - [Configuring Ingress](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration) Customize ingress configurations using an ingress resource template. - [Configuring Red Hat OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.8/configure-openshift-routes) Configure Red Hat OpenShift Routes to create ingress endpoints for your Mule apps. - [Configuring Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.8/persistence-gateway) Use Persistence Gateway, which enables Mule apps deployed to a Mule runtime instance to store and share data across application replicas and restarts. - [Configuring Proxies](https://docs.mulesoft.com/runtime-fabric/2.8/manage-proxy-self) Configure proxies when running and hosting Mule apps deployed to Runtime Fabric. - [Configuring Horizontal Pod Autoscaling (HPA)](https://docs.mulesoft.com/runtime-fabric/2.8/configure-horizontal-autoscaling) Configure horizontal autoscaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. --- product: Runtime Fabric version: 2.9 --- # Configuring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Anypoint Runtime Fabric, review the following topics: - [Associating Business Groups and Environments](https://docs.mulesoft.com/runtime-fabric/2.9/associate-environments) Associate a Runtime Fabric with one or more Anypoint Platform environments before deploying a Mule app or API proxy. - [Configuring Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl#configure-rtfctl) Use `rtfctl apply`, `update`, and `wait` commands to configure Runtime Fabric. - [Configuring Ingress](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration) Customize ingress configurations using an ingress resource template. - [Configuring Red Hat OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.9/configure-openshift-routes) Configure Red Hat OpenShift Routes to create ingress endpoints for your Mule apps. - [Configuring Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.9/persistence-gateway) Use Persistence Gateway, which enables Mule apps deployed to a Mule runtime instance to store and share data across application replicas and restarts. - [Configuring Proxies](https://docs.mulesoft.com/runtime-fabric/2.9/manage-proxy-self) Configure proxies when running and hosting Mule apps deployed to Runtime Fabric. - [Configuring Horizontal Pod Autoscaling (HPA)](https://docs.mulesoft.com/runtime-fabric/2.9/configure-horizontal-autoscaling) Configure horizontal autoscaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure Anypoint Runtime Fabric, review the following topics: - [Associating Business Groups and Environments](https://docs.mulesoft.com/runtime-fabric/latest/associate-environments) Associate a Runtime Fabric with one or more Anypoint Platform environments before deploying a Mule app or API proxy. - [Configuring Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#configure-rtfctl) Use `rtfctl apply`, `update`, and `wait` commands to configure Runtime Fabric. - [Configuring Ingress](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration) Customize ingress configurations using an ingress resource template. - [Configuring Red Hat OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/latest/configure-openshift-routes) Configure Red Hat OpenShift Routes to create ingress endpoints for your Mule apps. - [Configuring Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway) Use Persistence Gateway, which enables Mule apps deployed to a Mule runtime instance to store and share data across application replicas and restarts. - [Configuring Proxies](https://docs.mulesoft.com/runtime-fabric/latest/manage-proxy-self) Configure proxies when running and hosting Mule apps deployed to Runtime Fabric. - [Configuring Horizontal Pod Autoscaling (HPA)](https://docs.mulesoft.com/runtime-fabric/latest/configure-horizontal-autoscaling) Configure horizontal autoscaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal. --- product: Runtime Fabric version: 2.10 --- # Configuring Runtime Fabric with RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to configure Runtime Fabric. ## Commands for Configuring Applications on Runtime Fabric
CommandDescription

Applies changes to a Runtime Fabric configuration

Updates rtfctl

Waits for Runtime Fabric components to become ready

Renews an expired client certificate using a pre-downloaded package

### `apply` Applies changes to a Runtime Fabric configuration. > [!NOTE] You can use the `rtfctl apply system-configuration` command to update OpenShift > system-configuration values. Other rtfctl apply commands are not effective for OpenShift. For any > other updates, modify the values in the OpenShift console. - Applies an HTTP proxy configuration rtfctl apply http-proxy http://: --namespace - Applies an HTTP proxy configuration with hostnames bypassing the proxy rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - Applies an HTTP proxy configuration with authentication rtfctl apply http-proxy http://:@: --namespace - Clears an HTTP proxy configuration rtfctl apply http-proxy "" --no-proxy "" --namespace - Applies a secure property rtfctl apply secure-property --key --value --app-namespace --namespace - Applies a system configuration on a host node rtfctl apply system-configuration - Applies a system configuration on a host node without downloading the latest scripts rtfctl apply system-configuration --skip-download - Applies a Mule license rtfctl apply mule-license --namespace If Runtime Fabric is installed via Helm, you must update the `mule-license` property in the Helm values. - Applies a monitoring proxy rtfctl apply monitoring-proxy http://: --namespace - Clears a monitoring proxy configuration rtfctl apply monitoring-proxy "" --namespace ### `update` Updates `rtfctl`. - Updates from the US control plane rtfctl update - Updates `rtfctl` from the EU control plane rtfctl update --host eu1.anypoint.mulesoft.com ### `wait` Waits for Runtime Fabric components to become ready - Specifies the number of seconds to wait rtfctl wait --namespace - Specifies the number of seconds to pass before timing out the wait (Default is 600 seconds) rtfctl wait --timeout --namespace ### `renew` Renews an expired client certificate using a pre-downloaded package rtfctl renew-expired-client-cert ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl) --- product: Runtime Fabric version: 2.11 --- # Configuring Runtime Fabric with RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to configure Runtime Fabric.
CommandDescription

Applies changes to a Runtime Fabric configuration

Updates rtfctl

Waits for Runtime Fabric components to become ready

Renews an expired client certificate using a pre-downloaded package

## `apply` Applies changes to a Runtime Fabric configuration. > [!NOTE] You can use the `rtfctl apply system-configuration` command to update OpenShift > system-configuration values. Other rtfctl apply commands are not effective for OpenShift. For any > other updates, modify the values in the OpenShift console. - Applies an HTTP proxy configuration rtfctl apply http-proxy http://: --namespace - Applies an HTTP proxy configuration with hostnames bypassing the proxy rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - Applies an HTTP proxy configuration with authentication rtfctl apply http-proxy http://:@: --namespace - Clears an HTTP proxy configuration rtfctl apply http-proxy "" --no-proxy "" --namespace - Applies a secure property rtfctl apply secure-property --key --value --app-namespace --namespace - Applies a system configuration on a host node rtfctl apply system-configuration - Applies a system configuration on a host node without downloading the latest scripts rtfctl apply system-configuration --skip-download - Applies a Mule license rtfctl apply mule-license --namespace If Runtime Fabric is installed via Helm, you must update the `mule-license` property in the Helm values. - Applies a monitoring proxy rtfctl apply monitoring-proxy http://: --namespace - Clears a monitoring proxy configuration rtfctl apply monitoring-proxy "" --namespace ## `update` Updates `rtfctl`. - Updates from the US control plane rtfctl update - Updates `rtfctl` from the EU control plane rtfctl update --host eu1.anypoint.mulesoft.com ## `wait` Waits for Runtime Fabric components to become ready - Specifies the number of seconds to wait rtfctl wait --namespace - Specifies the number of seconds to pass before timing out the wait (Default is 600 seconds) rtfctl wait --timeout --namespace ## `renew` Renews an expired client certificate using a pre-downloaded package rtfctl renew-expired-client-cert ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl) --- product: Runtime Fabric version: 2.9 --- # Configuring Runtime Fabric with RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to configure Runtime Fabric. ## Commands for Configuring Runtime Fabric
CommandDescription

Applies changes to a Runtime Fabric configuration

Updates rtfctl

Waits for Runtime Fabric components to become ready

Renews an expired client certificate using a pre-downloaded package

### apply Applies changes to a Runtime Fabric configuration. > [!NOTE] You can use the `rtfctl apply system-configuration` command to update OpenShift > system-configuration values. Other rtfctl apply commands are not effective for OpenShift. For any > other updates, modify the values in the OpenShift console. - Applies an HTTP proxy configuration rtfctl apply http-proxy http://: --namespace - Applies an HTTP proxy configuration with hostnames bypassing the proxy rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - Applies an HTTP proxy configuration with authentication rtfctl apply http-proxy http://:@: --namespace - Clears an HTTP proxy configuration rtfctl apply http-proxy "" --no-proxy "" --namespace - Applies a secure property rtfctl apply secure-property --key --value --app-namespace --namespace - Applies a system configuration on a host node rtfctl apply system-configuration - Applies a system configuration on a host node without downloading the latest scripts rtfctl apply system-configuration --skip-download - Applies a Mule license rtfctl apply mule-license --namespace If Runtime Fabric is installed via Helm, you must update the `mule-license` property in the Helm values. - Applies a monitoring proxy rtfctl apply monitoring-proxy http://: --namespace - Clears a monitoring proxy configuration rtfctl apply monitoring-proxy "" --namespace ### update Updates `rtfctl`. - Updates from the US control plane rtfctl update - Updates `rtfctl` from the EU control plane rtfctl update --host eu1.anypoint.mulesoft.com ### wait Waits for Runtime Fabric components to become ready - Specifies the number of seconds to wait rtfctl wait --namespace - Specifies the number of seconds to pass before timing out the wait (Default is 600 seconds) rtfctl wait --timeout --namespace ### renew Renews an expired client certificate using a pre-downloaded package rtfctl renew-expired-client-cert ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Runtime Fabric with RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to configure Runtime Fabric.
CommandDescription

Applies changes to a Runtime Fabric configuration

Updates rtfctl

Waits for Runtime Fabric components to become ready

Renews an expired client certificate using a pre-downloaded package

## `apply` Applies changes to a Runtime Fabric configuration. > [!NOTE] You can use the `rtfctl apply system-configuration` command to update OpenShift > system-configuration values. Other rtfctl apply commands are not effective for OpenShift. For any > other updates, modify the values in the OpenShift console. - Applies an HTTP proxy configuration rtfctl apply http-proxy http://: --namespace - Applies an HTTP proxy configuration with hostnames bypassing the proxy rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - Applies an HTTP proxy configuration with authentication rtfctl apply http-proxy http://:@: --namespace - Clears an HTTP proxy configuration rtfctl apply http-proxy "" --no-proxy "" --namespace - Applies a secure property rtfctl apply secure-property --key --value --app-namespace --namespace - Applies a system configuration on a host node rtfctl apply system-configuration - Applies a system configuration on a host node without downloading the latest scripts rtfctl apply system-configuration --skip-download - Applies a Mule license rtfctl apply mule-license --namespace If Runtime Fabric is installed via Helm, you must update the `mule-license` property in the Helm values. - Applies a monitoring proxy rtfctl apply monitoring-proxy http://: --namespace - Clears a monitoring proxy configuration rtfctl apply monitoring-proxy "" --namespace ## `update` Updates `rtfctl`. - Updates `rtfctl` from the US Cloud rtfctl update - Updates `rtfctl` from the EU Cloud rtfctl update --host eu1.anypoint.mulesoft.com - Updates `rtfctl` from the Canada Cloud rtfctl update --host ca1.platform.mulesoft.com - Updates `rtfctl` from the Japan Cloud rtfctl update --host jp1.platform.mulesoft.com - Updates `rtfctl` from the India Cloud rtfctl update --host in1.platform.mulesoft.com - Updates `rtfctl` from the Australia Cloud rtfctl update --host au1.platform.mulesoft.com - Updates `rtfctl` from the United Kingdom Cloud rtfctl update --host gb1.platform.mulesoft.com ## `wait` Waits for Runtime Fabric components to become ready - Specifies the number of seconds to wait rtfctl wait --namespace - Specifies the number of seconds to pass before timing out the wait (Default is 600 seconds) rtfctl wait --timeout --namespace ## `renew` Renews an expired client certificate using a pre-downloaded package rtfctl renew-expired-client-cert ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl) --- product: Runtime Fabric version: 2.10 --- # Configuring Your Network to Support Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] Network configuration must be performed by an IT administrator. Before installing or using Runtime Fabric, ensure that the following ports and hostnames are configured correctly. Note that all internal communication within the cluster (between pods and services) needs to be allowed. ## Port Configuration To install or run Runtime Fabric, ensure that you have configured the following ports on your Kubernetes installation. For protocol-aware firewalls, consider allowing the following port traffic to use AMQP (Advanced Message Queuing Protocol) over Websockets. > [!NOTE] The following table does not include ports and hostnames from Anypoint Platform that you > may also need to allow. Refer to > [the Anypoint Mule Gateway documentation](https://docs.mulesoft.com/mule-gateway/mule-gateway-hostnames) for a list of > additional ports and hostnames.
PortLayer 4 ProtocolLayer 7 ProtocolSourceDestinationDescription

443

TCP

HTTPS

API consumers

All nodes

Allow inbound API requests to ingress controllers

443

TCP

AMQP over WebSockets

All nodes

Internet

Anypoint Platform management services

443

TCP

HTTPS

All nodes

Internet

API Manager policy updates, API Analytics Ingestion, and Resource retrieval (application files, container images).

443 (v1.8.50, or later)

TCP

Lumberjack

All nodes

Internet

Anypoint Monitoring, Anypoint Visualizer

## Port Used by the Persistence Gateway The Persistent Gateway requires a Postgres-compliant database to store persistent data across Mule application replicas. Ensure that your Kubernetes cluster has access to this database and port. See [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.10/persistence-gateway). ## Hostname Endpoint Configuration To function correctly, Runtime Fabric requires the following hostname endpoint configurations. Give access to these endpoints in your infrastructure to avoid any installation or deployment issues.
PortProtocolHostnamesDescription

443

AMQP over WebSockets

  • US control plane: transport-layer.prod.cloudhub.io

  • EU control plane: transport-layer.prod-eu.msap.io

Runtime Fabric message broker for interaction with the control plane.

443 (v1.8.50 and later)

TCP (Lumberjack)

  • US control plane:
    dias-ingestor-router.us-east-1.prod.cloudhub.io
    us1.ingest.mulesoft.com

  • EU control plane:
    dias-ingestor-router.eu-central-1.prod-eu.msap.io
    eu1.ingest.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric.

5044 (legacy)

TCP (Lumberjack)

  • US control plane: dias-ingestor-nginx.prod.cloudhub.io

  • EU control plane: dias-ingestor-nginx.prod-eu.msap.io

Anypoint Monitoring agent for Runtime Fabric.

As of Runtime Fabric version 1.8.50, this port is not strictly required. It will be deprecated in the future.

443

HTTPS

anypoint.mulesoft.com

Anypoint Platform for pulling assets.

443

HTTPS

  • US control plane: worker-cloud-helm-prod.s3.amazonaws.com

  • EU control plane: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com, worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric version repository. The Runtime Fabric installation uses software from this repository during installation and upgrades.

443

HTTPS

  • US control plane: exchange2-asset-manager-kprod.s3.amazonaws.com

  • EU control plane: exchange2-asset-manager-kprod-eu.s3.amazonaws.com, exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

Anypoint Exchange for application assets.

443

HTTPS

  • US control plane: exchange-files.anypoint.mulesoft.com

  • EU control plane: exchange-files.eu1.anypoint.mulesoft.com

Anypoint Exchange for application files.

443

HTTPS

  • US control plane: rtf-runtime-registry.kprod.msap.io

  • EU control plane: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com, prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

  • EU control plane: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com, prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker image delivery.

443

HTTPS

  • US control plane: runtime-fabric.s3.amazonaws.com

  • EU control plane: runtime-fabric-eu.s3.amazonaws.com

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: configuration-resolver.prod.cloudhub.io

  • EU control plane: configuration-resolver.prod-eu.msap.io

Anypoint Configuration Resolver.

## Verify Outbound Connectivity Every Anypoint Runtime Fabric cluster requires connectivity with Anypoint control plane, and any interference with connectivity can limit functionality, resulting in application deployment failures or degraded status in Anypoint Runtime Manager. You can use `rtfctl` to verify that Runtime Fabric has the required outbound connectivity. On each node, follow the instructions in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl) to install `rtfctl`. To verify the required outbound connectivity, run the following command on all controller and worker nodes in the cluster: ./rtfctl test outbound-network Sample output: \[root@rtf-controller-1 runtimefabric\]# ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ If you have outbound connectivity issues that prevent Runtime Fabric from reaching any of the required Anypoint control plane services, work with your network team to verify that you have added the required port IPs and hostnames to the allowlist as described in the port configuration section. ## Certificate Configuration To allow different endpoints to use mutual TLS authentication to establish a connection, you must configure SSL passthrough to allow the following certificates:
Control PlaneCertificates

US control plane

transport-layer.prod.cloudhub.io
configuration-resolver.prod.cloudhub.io
us1.ingest.mulesoft.com

EU control plane

transport-layer.prod-eu.msap.io
configuration-resolver.prod-eu.msap.io

--- product: Runtime Fabric version: 2.11 --- # Configuring Your Network to Support Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] Network configuration must be performed by an IT administrator. Before installing or using Runtime Fabric, ensure that these ports and hostnames are configured correctly. Note that all internal communication within the cluster (between pods and services) needs to be allowed. ## Port Configuration To install or run Runtime Fabric, ensure that you have configured these ports on your Kubernetes installation. For protocol-aware firewalls, consider allowing this port traffic to use AMQP (Advanced Message Queuing Protocol) over Websockets. > [!NOTE] The following table does not include ports and hostnames from Anypoint Platform that you > may also need to allow. Refer to > [the Anypoint Mule Gateway documentation](https://docs.mulesoft.com/mule-gateway/mule-gateway-hostnames) for a list of > additional ports and hostnames.
PortLayer 4 ProtocolLayer 7 ProtocolSourceDestinationDescription

443

TCP

HTTPS

API consumers

All nodes

Allow inbound API requests to ingress controllers

443

TCP

AMQP over WebSockets

All nodes

Internet

Anypoint Platform management services

443

TCP

HTTPS

All nodes

Internet

API Manager policy updates, API Analytics Ingestion, and Resource retrieval (application files, container images).

443 (v1.8.50, or later)

TCP

Lumberjack

All nodes

Internet

Anypoint Monitoring, Anypoint Visualizer

## Port Used by the Persistence Gateway The Persistent Gateway requires a Postgres-compliant database to store persistent data across Mule application replicas. Ensure that your Kubernetes cluster has access to this database and port. See [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.11/persistence-gateway). ## Hostname Endpoint Configuration To function correctly, Runtime Fabric requires these hostname endpoint configurations. Give access to these endpoints in your infrastructure to avoid any installation or deployment issues.
PortProtocolHostnamesDescription

443

AMQP over WebSockets

  • US control plane: transport-layer.prod.cloudhub.io

  • EU control plane: transport-layer.prod-eu.msap.io

Runtime Fabric message broker for interaction with the control plane.

443 (v1.8.50 and later)

TCP (Lumberjack)

  • US control plane:
    dias-ingestor-router.us-east-1.prod.cloudhub.io
    us1.ingest.mulesoft.com

  • EU control plane:
    dias-ingestor-router.eu-central-1.prod-eu.msap.io
    eu1.ingest.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric.

5044 (legacy)

TCP (Lumberjack)

  • US control plane: dias-ingestor-nginx.prod.cloudhub.io

  • EU control plane: dias-ingestor-nginx.prod-eu.msap.io

Anypoint Monitoring agent for Runtime Fabric.

As of Runtime Fabric version 1.8.50, this port is not strictly required. It will be deprecated in the future.

443

HTTPS

anypoint.mulesoft.com

Anypoint Platform for pulling assets.

443

HTTPS

  • US control plane: worker-cloud-helm-prod.s3.amazonaws.com

  • EU control plane: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com, worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric version repository. The Runtime Fabric installation uses software from this repository during installation and upgrades.

443

HTTPS

  • US control plane: exchange2-asset-manager-kprod.s3.amazonaws.com

  • EU control plane: exchange2-asset-manager-kprod-eu.s3.amazonaws.com, exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

Anypoint Exchange for application assets.

443

HTTPS

  • US control plane: exchange-files.anypoint.mulesoft.com

  • EU control plane: exchange-files.eu1.anypoint.mulesoft.com

Anypoint Exchange for application files.

443

HTTPS

  • US control plane: rtf-runtime-registry.kprod.msap.io

  • EU control plane: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com, prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

  • EU control plane: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com, prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker image delivery.

443

HTTPS

  • US control plane: runtime-fabric.s3.amazonaws.com

  • EU control plane: runtime-fabric-eu.s3.amazonaws.com

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: configuration-resolver.prod.cloudhub.io

  • EU control plane: configuration-resolver.prod-eu.msap.io

Anypoint Configuration Resolver.

## Verify Outbound Connectivity Every Anypoint Runtime Fabric cluster requires connectivity with Anypoint control plane, and any interference with connectivity can limit functionality, resulting in application deployment failures or degraded status in Anypoint Runtime Manager. You can use `rtfctl` to verify that Runtime Fabric has the required outbound connectivity. On each node, follow the instructions in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl) to install `rtfctl`. To verify the required outbound connectivity, run this command on all controller and worker nodes in the cluster: ./rtfctl test outbound-network Sample output: \[root@rtf-controller-1 runtimefabric\]# ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ If you have outbound connectivity issues that prevent Runtime Fabric from reaching any of the required Anypoint control plane services, work with your network team to verify that you have added the required port IPs and hostnames to the allowlist as described in the port configuration section. ## Certificate Configuration To allow different endpoints to use mutual TLS authentication to establish a connection, you must configure SSL passthrough to allow these certificates:
Control PlaneCertificates

US control plane

transport-layer.prod.cloudhub.io
configuration-resolver.prod.cloudhub.io
us1.ingest.mulesoft.com

EU control plane

transport-layer.prod-eu.msap.io
configuration-resolver.prod-eu.msap.io

--- product: Runtime Fabric version: 2.5 --- # Configuring Your Network to Support Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] Network configuration must be performed by an IT administrator. Before installing or using Runtime Fabric, ensure that the following ports and hostnames are configured correctly. ## Port Configuration To install or run Runtime Fabric, ensure that you have configured the following ports on your Kubernetes installation. For protocol-aware firewalls, consider allowing the following port traffic to use AMQP (Advanced Message Queuing Protocol) over Websockets. > [!NOTE] The following table does not include ports and hostnames from Anypoint Platform that you > may also need to allow. Refer to > [the Anypoint Mule Gateway documentation](https://docs.mulesoft.com/mule-gateway/mule-gateway-hostnames) for a list of > additional ports and hostnames.
PortLayer 4 ProtocolLayer 5 ProtocolSourceDestinationDescription

443

TCP

HTTPS

API consumers

All nodes

Allow inbound API requests to ingress controllers

443

TCP

AMQP over WebSockets

All nodes

Internet

Anypoint Platform management services

443

TCP

HTTPS

All nodes

Internet

API Manager policy updates, API Analytics Ingestion, and Resource retrieval (application files, container images).

443 (v1.8.50, or later)

TCP

Lumberjack

All nodes

Internet

Anypoint Monitoring, Anypoint Visualizer

## Port Used by the Persistence Gateway The Persistent Gateway requires a Postgres-compliant database to store persistent data across Mule application replicas. Ensure that your Kubernetes cluster has access to this database and port. See [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.5/persistence-gateway). ## Hostname Configuration To function correctly, Runtime Fabric requires the following hostname configurations:
PortProtocolHostnamesDescription

443

AMQP over WebSockets

  • US control plane: transport-layer.prod.cloudhub.io

  • EU control plane: transport-layer.prod-eu.msap.io

Runtime Fabric message broker for interaction with the control plane.

443 (v1.8.50 and later)

TCP (Lumberjack)

  • US control plane: dias-ingestor-router.us-east-1.prod.cloudhub.io

  • EU control plane: dias-ingestor-nginx.prod-eu.msap.io

  • EU control plane: dias-ingestor-router.eu-central-1.prod-eu.msap.io

Anypoint Monitoring agent for Runtime Fabric.

5044 (legacy)

TCP (Lumberjack)

  • US control plane: dias-ingestor-nginx.prod.cloudhub.io

  • EU control plane: dias-ingestor-nginx.prod-eu.msap.io

Anypoint Monitoring agent for Runtime Fabric.

As of Runtime Fabric version 1.8.50, this port is not strictly required. It will be deprecated in the future.

443

HTTPS

anypoint.mulesoft.com

Anypoint Platform for pulling assets.

443

HTTPS

  • US control plane: worker-cloud-helm-prod.s3.amazonaws.com

  • EU control plane: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com, worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric version repository. The Runtime Fabric installation uses software from this repository during installation and upgrades.

443

HTTPS

  • US control plane: exchange2-asset-manager-kprod.s3.amazonaws.com

  • EU control plane: exchange2-asset-manager-kprod-eu.s3.amazonaws.com, exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

Anypoint Exchange for application assets.

443

HTTPS

  • US control plane: exchange-files.anypoint.mulesoft.com

  • EU control plane: exchange-files.eu1.anypoint.mulesoft.com

Anypoint Exchange for application files.

443

HTTPS

  • US control plane: rtf-runtime-registry.kprod.msap.io

  • EU control plane: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com, prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

  • EU control plane: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com, prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker image delivery.

443

HTTPS

  • US control plane: runtime-fabric.s3.amazonaws.com

  • EU control plane: runtime-fabric-eu.s3.amazonaws.com

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: configuration-resolver.prod.cloudhub.io

  • EU control plane: configuration-resolver.prod-eu.msap.io

Anypoint Configuration Resolver.

## Verify Outbound Connectivity Every Anypoint Runtime Fabric cluster requires connectivity with Anypoint control plane, and any interference with connectivity can limit functionality, resulting in application deployment failures or degraded status in Anypoint Runtime Manager. You can use `rtfctl` to verify that Runtime Fabric has the required outbound connectivity. On each node, follow the instructions in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.5/install-rtfctl) to install `rtfctl`. To verify the required outbound connectivity, run the following command on all controller and worker nodes in the cluster: ./rtfctl test outbound-network Sample output: \[root@rtf-controller-1 runtimefabric\]# ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ If you have outbound connectivity issues that prevent Runtime Fabric from reaching any of the required Anypoint control plane services, work with your network team to verify that you have added the required port IPs and hostnames to the allowlist as described in the port configuration section. ## Certificate Configuration To allow different endpoints to use mutual TLS authentication to establish a connection, you must configure SSL passthrough to allow the following certificates:
Control PlaneCertificates

US control plane

transport-layer.prod.cloudhub.io
configuration-resolver.prod.cloudhub.io

EU control plane

transport-layer.prod-eu.msap.io
configuration-resolver.prod-eu.msap.io

--- product: Runtime Fabric version: 2.6 --- # Configuring Your Network to Support Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] Network configuration must be performed by an IT administrator. Before installing or using Runtime Fabric, ensure that the following ports and hostnames are configured correctly. ## Port Configuration To install or run Runtime Fabric, ensure that you have configured the following ports on your Kubernetes installation. For protocol-aware firewalls, consider allowing the following port traffic to use AMQP (Advanced Message Queuing Protocol) over Websockets. > [!NOTE] The following table does not include ports and hostnames from Anypoint Platform that you > may also need to allow. Refer to > [the Anypoint Mule Gateway documentation](https://docs.mulesoft.com/mule-gateway/mule-gateway-hostnames) for a list of > additional ports and hostnames.
PortLayer 4 ProtocolLayer 5 ProtocolSourceDestinationDescription

443

TCP

HTTPS

API consumers

All nodes

Allow inbound API requests to ingress controllers

443

TCP

AMQP over WebSockets

All nodes

Internet

Anypoint Platform management services

443

TCP

HTTPS

All nodes

Internet

API Manager policy updates, API Analytics Ingestion, and Resource retrieval (application files, container images).

443 (v1.8.50, or later)

TCP

Lumberjack

All nodes

Internet

Anypoint Monitoring, Anypoint Visualizer

## Port Used by the Persistence Gateway The Persistent Gateway requires a Postgres-compliant database to store persistent data across Mule application replicas. Ensure that your Kubernetes cluster has access to this database and port. See [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.6/persistence-gateway). ## Hostname Configuration To function correctly, Runtime Fabric requires the following hostname configurations:
PortProtocolHostnamesDescription

443

AMQP over WebSockets

  • US control plane: transport-layer.prod.cloudhub.io

  • EU control plane: transport-layer.prod-eu.msap.io

Runtime Fabric message broker for interaction with the control plane.

443 (v1.8.50 and later)

TCP (Lumberjack)

  • US control plane:
    dias-ingestor-router.us-east-1.prod.cloudhub.io
    us1.ingest.mulesoft.com

  • EU control plane:
    dias-ingestor-router.eu-central-1.prod-eu.msap.io
    eu1.ingest.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric.

5044 (legacy)

TCP (Lumberjack)

  • US control plane: dias-ingestor-nginx.prod.cloudhub.io

  • EU control plane: dias-ingestor-nginx.prod-eu.msap.io

Anypoint Monitoring agent for Runtime Fabric.

As of Runtime Fabric version 1.8.50, this port is not strictly required. It will be deprecated in the future.

443

HTTPS

anypoint.mulesoft.com

Anypoint Platform for pulling assets.

443

HTTPS

  • US control plane: worker-cloud-helm-prod.s3.amazonaws.com

  • EU control plane: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com, worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric version repository. The Runtime Fabric installation uses software from this repository during installation and upgrades.

443

HTTPS

  • US control plane: exchange2-asset-manager-kprod.s3.amazonaws.com

  • EU control plane: exchange2-asset-manager-kprod-eu.s3.amazonaws.com, exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

Anypoint Exchange for application assets.

443

HTTPS

  • US control plane: exchange-files.anypoint.mulesoft.com

  • EU control plane: exchange-files.eu1.anypoint.mulesoft.com

Anypoint Exchange for application files.

443

HTTPS

  • US control plane: rtf-runtime-registry.kprod.msap.io

  • EU control plane: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com, prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

  • EU control plane: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com, prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker image delivery.

443

HTTPS

  • US control plane: runtime-fabric.s3.amazonaws.com

  • EU control plane: runtime-fabric-eu.s3.amazonaws.com

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: configuration-resolver.prod.cloudhub.io

  • EU control plane: configuration-resolver.prod-eu.msap.io

Anypoint Configuration Resolver.

## Verify Outbound Connectivity Every Anypoint Runtime Fabric cluster requires connectivity with Anypoint control plane, and any interference with connectivity can limit functionality, resulting in application deployment failures or degraded status in Anypoint Runtime Manager. You can use `rtfctl` to verify that Runtime Fabric has the required outbound connectivity. On each node, follow the instructions in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl) to install `rtfctl`. To verify the required outbound connectivity, run the following command on all controller and worker nodes in the cluster: ./rtfctl test outbound-network Sample output: \[root@rtf-controller-1 runtimefabric\]# ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ If you have outbound connectivity issues that prevent Runtime Fabric from reaching any of the required Anypoint control plane services, work with your network team to verify that you have added the required port IPs and hostnames to the allowlist as described in the port configuration section. ## Certificate Configuration To allow different endpoints to use mutual TLS authentication to establish a connection, you must configure SSL passthrough to allow the following certificates:
Control PlaneCertificates

US control plane

transport-layer.prod.cloudhub.io
configuration-resolver.prod.cloudhub.io

EU control plane

transport-layer.prod-eu.msap.io
configuration-resolver.prod-eu.msap.io

--- product: Runtime Fabric version: 2.7 --- # Configuring Your Network to Support Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] Network configuration must be performed by an IT administrator. Before installing or using Runtime Fabric, ensure that the following ports and hostnames are configured correctly. ## Port Configuration To install or run Runtime Fabric, ensure that you have configured the following ports on your Kubernetes installation. For protocol-aware firewalls, consider allowing the following port traffic to use AMQP (Advanced Message Queuing Protocol) over Websockets. > [!NOTE] The following table does not include ports and hostnames from Anypoint Platform that you > may also need to allow. Refer to > [the Anypoint Mule Gateway documentation](https://docs.mulesoft.com/mule-gateway/mule-gateway-hostnames) for a list of > additional ports and hostnames.
PortLayer 4 ProtocolLayer 5 ProtocolSourceDestinationDescription

443

TCP

HTTPS

API consumers

All nodes

Allow inbound API requests to ingress controllers

443

TCP

AMQP over WebSockets

All nodes

Internet

Anypoint Platform management services

443

TCP

HTTPS

All nodes

Internet

API Manager policy updates, API Analytics Ingestion, and Resource retrieval (application files, container images).

443 (v1.8.50, or later)

TCP

Lumberjack

All nodes

Internet

Anypoint Monitoring, Anypoint Visualizer

## Port Used by the Persistence Gateway The Persistent Gateway requires a Postgres-compliant database to store persistent data across Mule application replicas. Ensure that your Kubernetes cluster has access to this database and port. See [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.7/persistence-gateway). ## Hostname Configuration To function correctly, Runtime Fabric requires the following hostname configurations:
PortProtocolHostnamesDescription

443

AMQP over WebSockets

  • US control plane: transport-layer.prod.cloudhub.io

  • EU control plane: transport-layer.prod-eu.msap.io

Runtime Fabric message broker for interaction with the control plane.

443 (v1.8.50 and later)

TCP (Lumberjack)

  • US control plane:
    dias-ingestor-router.us-east-1.prod.cloudhub.io
    us1.ingest.mulesoft.com

  • EU control plane:
    dias-ingestor-router.eu-central-1.prod-eu.msap.io
    eu1.ingest.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric.

5044 (legacy)

TCP (Lumberjack)

  • US control plane: dias-ingestor-nginx.prod.cloudhub.io

  • EU control plane: dias-ingestor-nginx.prod-eu.msap.io

Anypoint Monitoring agent for Runtime Fabric.

As of Runtime Fabric version 1.8.50, this port is not strictly required. It will be deprecated in the future.

443

HTTPS

anypoint.mulesoft.com

Anypoint Platform for pulling assets.

443

HTTPS

  • US control plane: worker-cloud-helm-prod.s3.amazonaws.com

  • EU control plane: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com, worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric version repository. The Runtime Fabric installation uses software from this repository during installation and upgrades.

443

HTTPS

  • US control plane: exchange2-asset-manager-kprod.s3.amazonaws.com

  • EU control plane: exchange2-asset-manager-kprod-eu.s3.amazonaws.com, exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

Anypoint Exchange for application assets.

443

HTTPS

  • US control plane: exchange-files.anypoint.mulesoft.com

  • EU control plane: exchange-files.eu1.anypoint.mulesoft.com

Anypoint Exchange for application files.

443

HTTPS

  • US control plane: rtf-runtime-registry.kprod.msap.io

  • EU control plane: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com, prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

  • EU control plane: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com, prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker image delivery.

443

HTTPS

  • US control plane: runtime-fabric.s3.amazonaws.com

  • EU control plane: runtime-fabric-eu.s3.amazonaws.com

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: configuration-resolver.prod.cloudhub.io

  • EU control plane: configuration-resolver.prod-eu.msap.io

Anypoint Configuration Resolver.

## Verify Outbound Connectivity Every Anypoint Runtime Fabric cluster requires connectivity with Anypoint control plane, and any interference with connectivity can limit functionality, resulting in application deployment failures or degraded status in Anypoint Runtime Manager. You can use `rtfctl` to verify that Runtime Fabric has the required outbound connectivity. On each node, follow the instructions in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl) to install `rtfctl`. To verify the required outbound connectivity, run the following command on all controller and worker nodes in the cluster: ./rtfctl test outbound-network Sample output: \[root@rtf-controller-1 runtimefabric\]# ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ If you have outbound connectivity issues that prevent Runtime Fabric from reaching any of the required Anypoint control plane services, work with your network team to verify that you have added the required port IPs and hostnames to the allowlist as described in the port configuration section. ## Certificate Configuration To allow different endpoints to use mutual TLS authentication to establish a connection, you must configure SSL passthrough to allow the following certificates:
Control PlaneCertificates

US control plane

transport-layer.prod.cloudhub.io
configuration-resolver.prod.cloudhub.io

EU control plane

transport-layer.prod-eu.msap.io
configuration-resolver.prod-eu.msap.io

--- product: Runtime Fabric version: 2.8 --- # Configuring Your Network to Support Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] Network configuration must be performed by an IT administrator. Before installing or using Runtime Fabric, ensure that the following ports and hostnames are configured correctly. Note that all internal communication within the cluster (between pods and services) needs to be allowed. ## Port Configuration To install or run Runtime Fabric, ensure that you have configured the following ports on your Kubernetes installation. For protocol-aware firewalls, consider allowing the following port traffic to use AMQP (Advanced Message Queuing Protocol) over Websockets. > [!NOTE] The following table does not include ports and hostnames from Anypoint Platform that you > may also need to allow. Refer to > [the Anypoint Mule Gateway documentation](https://docs.mulesoft.com/mule-gateway/mule-gateway-hostnames) for a list of > additional ports and hostnames.
PortLayer 4 ProtocolLayer 7 ProtocolSourceDestinationDescription

443

TCP

HTTPS

API consumers

All nodes

Allow inbound API requests to ingress controllers

443

TCP

AMQP over WebSockets

All nodes

Internet

Anypoint Platform management services

443

TCP

HTTPS

All nodes

Internet

API Manager policy updates, API Analytics Ingestion, and Resource retrieval (application files, container images).

443 (v1.8.50, or later)

TCP

Lumberjack

All nodes

Internet

Anypoint Monitoring, Anypoint Visualizer

## Port Used by the Persistence Gateway The Persistent Gateway requires a Postgres-compliant database to store persistent data across Mule application replicas. Ensure that your Kubernetes cluster has access to this database and port. See [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.8/persistence-gateway). ## Hostname Endpoint Configuration To function correctly, Runtime Fabric requires the following hostname endpoint configurations. Give access to these endpoints in your infrastructure to avoid any installation or deployment issues.
PortProtocolHostnamesDescription

443

AMQP over WebSockets

  • US control plane: transport-layer.prod.cloudhub.io

  • EU control plane: transport-layer.prod-eu.msap.io

Runtime Fabric message broker for interaction with the control plane.

443 (v1.8.50 and later)

TCP (Lumberjack)

  • US control plane:
    dias-ingestor-router.us-east-1.prod.cloudhub.io
    us1.ingest.mulesoft.com

  • EU control plane:
    dias-ingestor-router.eu-central-1.prod-eu.msap.io
    eu1.ingest.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric.

5044 (legacy)

TCP (Lumberjack)

  • US control plane: dias-ingestor-nginx.prod.cloudhub.io

  • EU control plane: dias-ingestor-nginx.prod-eu.msap.io

Anypoint Monitoring agent for Runtime Fabric.

As of Runtime Fabric version 1.8.50, this port is not strictly required. It will be deprecated in the future.

443

HTTPS

anypoint.mulesoft.com

Anypoint Platform for pulling assets.

443

HTTPS

  • US control plane: worker-cloud-helm-prod.s3.amazonaws.com

  • EU control plane: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com, worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric version repository. The Runtime Fabric installation uses software from this repository during installation and upgrades.

443

HTTPS

  • US control plane: exchange2-asset-manager-kprod.s3.amazonaws.com

  • EU control plane: exchange2-asset-manager-kprod-eu.s3.amazonaws.com, exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

Anypoint Exchange for application assets.

443

HTTPS

  • US control plane: exchange-files.anypoint.mulesoft.com

  • EU control plane: exchange-files.eu1.anypoint.mulesoft.com

Anypoint Exchange for application files.

443

HTTPS

  • US control plane: rtf-runtime-registry.kprod.msap.io

  • EU control plane: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com, prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

  • EU control plane: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com, prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker image delivery.

443

HTTPS

  • US control plane: runtime-fabric.s3.amazonaws.com

  • EU control plane: runtime-fabric-eu.s3.amazonaws.com

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: configuration-resolver.prod.cloudhub.io

  • EU control plane: configuration-resolver.prod-eu.msap.io

Anypoint Configuration Resolver.

## Verify Outbound Connectivity Every Anypoint Runtime Fabric cluster requires connectivity with Anypoint control plane, and any interference with connectivity can limit functionality, resulting in application deployment failures or degraded status in Anypoint Runtime Manager. You can use `rtfctl` to verify that Runtime Fabric has the required outbound connectivity. On each node, follow the instructions in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) to install `rtfctl`. To verify the required outbound connectivity, run the following command on all controller and worker nodes in the cluster: ./rtfctl test outbound-network Sample output: \[root@rtf-controller-1 runtimefabric\]# ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ If you have outbound connectivity issues that prevent Runtime Fabric from reaching any of the required Anypoint control plane services, work with your network team to verify that you have added the required port IPs and hostnames to the allowlist as described in the port configuration section. ## Certificate Configuration To allow different endpoints to use mutual TLS authentication to establish a connection, you must configure SSL passthrough to allow the following certificates:
Control PlaneCertificates

US control plane

transport-layer.prod.cloudhub.io
configuration-resolver.prod.cloudhub.io
us1.ingest.mulesoft.com

EU control plane

transport-layer.prod-eu.msap.io
configuration-resolver.prod-eu.msap.io

--- product: Runtime Fabric version: 2.9 --- # Configuring Your Network to Support Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] Network configuration must be performed by an IT administrator. Before installing or using Runtime Fabric, ensure that the following ports and hostnames are configured correctly. Note that all internal communication within the cluster (between pods and services) needs to be allowed. ## Port Configuration To install or run Runtime Fabric, ensure that you have configured the following ports on your Kubernetes installation. For protocol-aware firewalls, consider allowing the following port traffic to use AMQP (Advanced Message Queuing Protocol) over Websockets. > [!NOTE] The following table does not include ports and hostnames from Anypoint Platform that you > may also need to allow. Refer to > [the Anypoint Mule Gateway documentation](https://docs.mulesoft.com/mule-gateway/mule-gateway-hostnames) for a list of > additional ports and hostnames.
PortLayer 4 ProtocolLayer 7 ProtocolSourceDestinationDescription

443

TCP

HTTPS

API consumers

All nodes

Allow inbound API requests to ingress controllers

443

TCP

AMQP over WebSockets

All nodes

Internet

Anypoint Platform management services

443

TCP

HTTPS

All nodes

Internet

API Manager policy updates, API Analytics Ingestion, and Resource retrieval (application files, container images).

443 (v1.8.50, or later)

TCP

Lumberjack

All nodes

Internet

Anypoint Monitoring, Anypoint Visualizer

## Port Used by the Persistence Gateway The Persistent Gateway requires a Postgres-compliant database to store persistent data across Mule application replicas. Ensure that your Kubernetes cluster has access to this database and port. See [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.9/persistence-gateway). ## Hostname Endpoint Configuration To function correctly, Runtime Fabric requires the following hostname endpoint configurations. Give access to these endpoints in your infrastructure to avoid any installation or deployment issues.
PortProtocolHostnamesDescription

443

AMQP over WebSockets

  • US control plane: transport-layer.prod.cloudhub.io

  • EU control plane: transport-layer.prod-eu.msap.io

Runtime Fabric message broker for interaction with the control plane.

443 (v1.8.50 and later)

TCP (Lumberjack)

  • US control plane:
    dias-ingestor-router.us-east-1.prod.cloudhub.io
    us1.ingest.mulesoft.com

  • EU control plane:
    dias-ingestor-router.eu-central-1.prod-eu.msap.io
    eu1.ingest.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric.

5044 (legacy)

TCP (Lumberjack)

  • US control plane: dias-ingestor-nginx.prod.cloudhub.io

  • EU control plane: dias-ingestor-nginx.prod-eu.msap.io

Anypoint Monitoring agent for Runtime Fabric.

As of Runtime Fabric version 1.8.50, this port is not strictly required. It will be deprecated in the future.

443

HTTPS

anypoint.mulesoft.com

Anypoint Platform for pulling assets.

443

HTTPS

  • US control plane: worker-cloud-helm-prod.s3.amazonaws.com

  • EU control plane: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com, worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric version repository. The Runtime Fabric installation uses software from this repository during installation and upgrades.

443

HTTPS

  • US control plane: exchange2-asset-manager-kprod.s3.amazonaws.com

  • EU control plane: exchange2-asset-manager-kprod-eu.s3.amazonaws.com, exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

Anypoint Exchange for application assets.

443

HTTPS

  • US control plane: exchange-files.anypoint.mulesoft.com

  • EU control plane: exchange-files.eu1.anypoint.mulesoft.com

Anypoint Exchange for application files.

443

HTTPS

  • US control plane: rtf-runtime-registry.kprod.msap.io

  • EU control plane: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com, prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

  • EU control plane: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com, prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker image delivery.

443

HTTPS

  • US control plane: runtime-fabric.s3.amazonaws.com

  • EU control plane: runtime-fabric-eu.s3.amazonaws.com

Runtime Fabric Docker repository.

443

HTTPS

  • US control plane: configuration-resolver.prod.cloudhub.io

  • EU control plane: configuration-resolver.prod-eu.msap.io

Anypoint Configuration Resolver.

## Verify Outbound Connectivity Every Anypoint Runtime Fabric cluster requires connectivity with Anypoint control plane, and any interference with connectivity can limit functionality, resulting in application deployment failures or degraded status in Anypoint Runtime Manager. You can use `rtfctl` to verify that Runtime Fabric has the required outbound connectivity. On each node, follow the instructions in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl) to install `rtfctl`. To verify the required outbound connectivity, run the following command on all controller and worker nodes in the cluster: ./rtfctl test outbound-network Sample output: \[root@rtf-controller-1 runtimefabric\]# ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ If you have outbound connectivity issues that prevent Runtime Fabric from reaching any of the required Anypoint control plane services, work with your network team to verify that you have added the required port IPs and hostnames to the allowlist as described in the port configuration section. ## Certificate Configuration To allow different endpoints to use mutual TLS authentication to establish a connection, you must configure SSL passthrough to allow the following certificates:
Control PlaneCertificates

US control plane

transport-layer.prod.cloudhub.io
configuration-resolver.prod.cloudhub.io
us1.ingest.mulesoft.com

EU control plane

transport-layer.prod-eu.msap.io
configuration-resolver.prod-eu.msap.io

--- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Configuring Your Network to Support Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] Network configuration must be performed by an IT administrator. Before installing or using Runtime Fabric, ensure that the following ports and hostnames are configured correctly. Note that all internal communication within the cluster (between pods and services) needs to be allowed. ## Port Configuration To install or run Runtime Fabric, ensure that you have configured the following ports on your Kubernetes installation. For protocol-aware firewalls, consider allowing the following port traffic to use AMQP (Advanced Message Queuing Protocol) over Websockets. > [!NOTE] The following table does not include ports and hostnames from Anypoint Platform that you > may also need to allow. Refer to > [the Anypoint Mule Gateway documentation](https://docs.mulesoft.com/mule-gateway/mule-gateway-hostnames) for a list of > additional ports and hostnames.
PortLayer 4 ProtocolLayer 7 ProtocolSourceDestinationDescription

443

TCP

HTTPS

API consumers

All nodes

Allow inbound API requests to ingress controllers

443

TCP

AMQP over WebSockets

All nodes

Internet

Anypoint Platform management services

443

TCP

HTTPS

All nodes

Internet

API Manager policy updates, API Analytics Ingestion, and Resource retrieval (application files, container images).

443 (v1.8.50, or later)

TCP

HTTPS

All nodes

Internet

Anypoint Monitoring, Anypoint Visualizer

## Port Used by the Persistence Gateway The Persistent Gateway requires a Postgres-compliant database to store persistent data across Mule application replicas. Ensure that your Kubernetes cluster has access to this database and port. See [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway). ## Hostname Endpoint Configuration To function correctly, Runtime Fabric requires the following hostname endpoint configurations. Give access to these endpoints in your infrastructure to avoid any installation or deployment issues. ### US Cloud This table lists the required hostname endpoint configurations for the US Cloud.
PortProtocolHostnamesDescription

443

AMQP over WebSockets

transport-layer.prod.cloudhub.io

Runtime Fabric message broker for interaction with the control plane.

443 (v2.6.22 and later)

HTTPS

us1.ingest.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric.

443 (pre-2.6.22, legacy)

TCP (Lumberjack)

dias-ingestor-router.us-east-1.prod.cloudhub.io

Anypoint Monitoring agent for Runtime Fabric.

Required only for Runtime Fabric versions earlier than 2.6.22. After upgrading to Runtime Fabric 2.6.22 or later and redeploying all applications, this endpoint is no longer used.

5044 (legacy)

TCP (Lumberjack)

dias-ingestor-nginx.prod.cloudhub.io

Anypoint Monitoring agent for Runtime Fabric.

Starting with Runtime Fabric version 1.8.50, this port is not required. It will be deprecated in the future.

443

HTTPS

anypoint.mulesoft.com

Anypoint Platform for pulling assets.

443

HTTPS

worker-cloud-helm-prod.s3.amazonaws.com

Runtime Fabric version repository. The Runtime Fabric installation uses software from this repository during installation and upgrades.

443

HTTPS

exchange2-asset-manager-kprod.s3.amazonaws.com

Anypoint Exchange for application assets.

443

HTTPS

exchange-files.anypoint.mulesoft.com

Anypoint Exchange for application files.

443

HTTPS

rtf-runtime-registry.kprod.msap.io

Runtime Fabric Docker repository.

443

HTTPS

prod-us-east-1-starport-layer-bucket.s3.amazonaws.com, prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

Runtime Fabric Docker image delivery.

443

HTTPS

esvc-us-east-1-sfcd-ms-fabric.s3.amazonaws.com

Runtime Fabric agent and installer downloads. Download endpoints redirect clients to this bucket.

443

HTTPS

runtime-fabric.s3.amazonaws.com

Older Runtime Fabric agent versions, and installer and rtfctl artifacts.

443

HTTPS

configuration-resolver.prod.cloudhub.io

Anypoint Configuration Resolver.

### EU Cloud This table lists the required hostname endpoint configurations for the EU Cloud.
PortProtocolHostnamesDescription

443

AMQP over WebSockets

transport-layer.prod-eu.msap.io

Runtime Fabric message broker for interaction with the control plane.

443 (v2.6.22 and later)

HTTPS

eu1.ingest.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric.

443 (pre-2.6.22, legacy)

TCP (Lumberjack)

dias-ingestor-router.eu-central-1.prod-eu.msap.io

Anypoint Monitoring agent for Runtime Fabric.

Required only for Runtime Fabric versions earlier than 2.6.22. After upgrading to Runtime Fabric 2.6.22 or later and redeploying all applications, this endpoint is no longer used.

5044 (legacy)

TCP (Lumberjack)

dias-ingestor-nginx.prod-eu.msap.io

Anypoint Monitoring agent for Runtime Fabric.

Starting with Runtime Fabric version 1.8.50, this port is not required. It will be deprecated in the future.

443

HTTPS

eu1.anypoint.mulesoft.com

Anypoint Platform for pulling assets.

443

HTTPS

worker-cloud-helm-prod-eu-rt.s3.amazonaws.com, worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric version repository. The Runtime Fabric installation uses software from this repository during installation and upgrades.

443

HTTPS

exchange2-asset-manager-kprod-eu.s3.amazonaws.com, exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

Anypoint Exchange for application assets.

443

HTTPS

exchange-files.eu1.anypoint.mulesoft.com

Anypoint Exchange for application files.

443

HTTPS

rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker repository.

443

HTTPS

prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com, prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker image delivery.

443

HTTPS

esvc-eu-central-1-sfcd-ms-fabric.s3.eu-central-1.amazonaws.com

Runtime Fabric agent and installer downloads. Download endpoints redirect clients to this bucket.

443

HTTPS

runtime-fabric-eu.s3.amazonaws.com, runtime-fabric-eu.s3.eu-central-1.amazonaws.com

Older Runtime Fabric agent versions, and installer and rtfctl artifacts.

443

HTTPS

configuration-resolver.prod-eu.msap.io

Anypoint Configuration Resolver.

### Canada Cloud This table lists the required hostname endpoint configurations for the Canada Cloud.
PortProtocolHostnamesDescription

11443

WSS

arm-mcm2-service-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net

Runtime Fabric message broker for interaction with the control plane.

443

HTTPS

ca1.platform.mulesoft.com

Anypoint Platform for agent bootstrapping and certificate renewal.

8443

HTTPS

runtime-manager.ca1.platform.mulesoft.com

Configuration Resolver, Exchange asset download, and Runtime Manager services. In the Canada control plane, these services are consolidated behind a single endpoint.

8443

HTTPS

ingest.ca1.platform.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric (logs, metrics, and traces ingestion via OTEL).

443

HTTPS

rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net

Runtime Fabric Docker and Helm chart repository. All container images (Mule runtime, monitoring sidecars, and Runtime Fabric agent) are pulled from this registry.

443

HTTPS

esvc-ca-central-1-sfcd-ms-fabric.s3.ca-central-1.amazonaws.com

Runtime Fabric agent and installer downloads. Download endpoints redirect clients to this bucket.

443

HTTPS

esvc-us-east-2-mulesoft.s3.us-east-2.amazonaws.com

Older Runtime Fabric agent versions, and installer and rtfctl artifacts.

443

HTTPS

prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

Runtime Fabric Docker image delivery.

### Japan Cloud This table lists the required hostname endpoint configurations for the Japan Cloud.
PortProtocolHostnamesDescription

11443

WSS

arm-mcm2-service-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net

Runtime Fabric message broker for interaction with the control plane.

443

HTTPS

jp1.platform.mulesoft.com

Anypoint Platform for agent bootstrapping and certificate renewal.

8443

HTTPS

runtime-manager.jp1.platform.mulesoft.com

Configuration Resolver, Exchange asset download, and Runtime Manager services. In the Japan Cloud, these services are consolidated behind a single endpoint.

8443

HTTPS

ingest.jp1.platform.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric (logs, metrics, and traces ingestion via OTEL).

443

HTTPS

rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net

Runtime Fabric Docker and Helm chart repository. All container images (Mule runtime, monitoring sidecars, and Runtime Fabric agent) are pulled from this registry.

443

HTTPS

esvc-ap-northeast-1-sfcd-ms-fabric.s3.ap-northeast-1.amazonaws.com

Runtime Fabric agent and installer downloads. Download endpoints redirect clients to this bucket.

443

HTTPS

esvc-us-east-2-mulesoft.s3.us-east-2.amazonaws.com

Older Runtime Fabric agent versions, and installer and rtfctl artifacts.

443

HTTPS

prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

Runtime Fabric Docker image delivery.

### India Cloud This table lists the required hostname endpoint configurations for the India Cloud.
PortProtocolHostnamesDescription

8443

WSS

runtime-manager.in1.platform.mulesoft.com

Runtime Fabric message broker for interaction with the control plane (path: /v1/connect).

443

HTTPS

in1.platform.mulesoft.com

Anypoint Platform for agent bootstrapping and certificate renewal.

8443

HTTPS

runtime-manager.in1.platform.mulesoft.com

Configuration Resolver, Exchange asset download, and Runtime Manager services. In the India Cloud, these services are consolidated behind a single endpoint (path: /resolver).

8443

HTTPS

ingest.in1.platform.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric (logs, metrics, and traces ingestion via OTEL).

443

HTTPS

rtf-runtime-registry-mulesoft-cp.sfdc-y37hzm.svc.sfdcfc.net

Runtime Fabric Docker and Helm chart repository. All container images (Mule runtime, monitoring sidecars, and Runtime Fabric agent) are pulled from this registry.

443

HTTPS

esvc-ap-south-1-sfcd-ms-fabric.s3.ap-south-1.amazonaws.com

Runtime Fabric agent and installer downloads. Download endpoints redirect clients to this bucket.

443

HTTPS

esvc-us-east-2-mulesoft.s3.us-east-2.amazonaws.com

Older Runtime Fabric agent versions, and installer and rtfctl artifacts.

443

HTTPS

prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

Runtime Fabric Docker image delivery.

### Australia Cloud This table lists the required hostname endpoint configurations for the Australia Cloud.
PortProtocolHostnamesDescription

8443

WSS

runtime-manager.au1.platform.mulesoft.com

Runtime Fabric message broker for interaction with the control plane (path: /v1/connect).

443

HTTPS

au1.platform.mulesoft.com

Anypoint Platform for agent bootstrapping and certificate renewal.

8443

HTTPS

runtime-manager.au1.platform.mulesoft.com

Configuration Resolver, Exchange asset download, and Runtime Manager services. In the Australia Cloud, these services are consolidated behind a single endpoint (path: /resolver).

8443

HTTPS

ingest.au1.platform.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric (logs, metrics, and traces ingestion via OTEL).

443

HTTPS

rtf-runtime-registry-mulesoft-cp.sfdc-vwfla6.svc.sfdcfc.net

Runtime Fabric Docker and Helm chart repository. All container images (Mule runtime, monitoring sidecars, and Runtime Fabric agent) are pulled from this registry.

443

HTTPS

esvc-ap-southeast-2-sfcd-ms-fabric.s3.ap-southeast-2.amazonaws.com

Runtime Fabric agent and installer downloads. Download endpoints redirect clients to this bucket.

443

HTTPS

esvc-us-east-2-mulesoft.s3.us-east-2.amazonaws.com

Older Runtime Fabric agent versions, and installer and rtfctl artifacts.

443

HTTPS

prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

Runtime Fabric Docker image delivery.

### United Kingdom Cloud This table lists the required hostname endpoint configurations for the United Kingdom Cloud.
PortProtocolHostnamesDescription

8443

WSS

runtime-manager.gb1.platform.mulesoft.com

Runtime Fabric message broker for interaction with the control plane (path: /v1/connect).

443

HTTPS

gb1.platform.mulesoft.com

Anypoint Platform for agent bootstrapping and certificate renewal.

8443

HTTPS

runtime-manager.gb1.platform.mulesoft.com

Configuration Resolver, Exchange asset download, and Runtime Manager services. In the United Kingdom Cloud, these services are consolidated behind a single endpoint (path: /resolver).

8443

HTTPS

ingest.gb1.platform.mulesoft.com

Anypoint Monitoring agent for Runtime Fabric (logs, metrics, and traces ingestion via OTEL).

443

HTTPS

rtf-runtime-registry-mulesoft-cp.sfdc-5pakla.svc.sfdcfc.net

Runtime Fabric Docker and Helm chart repository. All container images (Mule runtime, monitoring sidecars, and Runtime Fabric agent) are pulled from this registry.

443

HTTPS

esvc-eu-west-2-sfcd-ms-fabric.s3.eu-west-2.amazonaws.com

Runtime Fabric agent and installer downloads. Download endpoints redirect clients to this bucket.

443

HTTPS

esvc-us-east-2-mulesoft.s3.us-east-2.amazonaws.com

Older Runtime Fabric agent versions, and installer and rtfctl artifacts.

443

HTTPS

prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com

Runtime Fabric Docker image delivery.

## Verify Outbound Connectivity Every Anypoint Runtime Fabric cluster requires connectivity with Anypoint control plane, and any interference with connectivity can limit functionality, resulting in application deployment failures or degraded status in Anypoint Runtime Manager. You can use `rtfctl` to verify that Runtime Fabric has the required outbound connectivity. On each node, follow the instructions in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) to install `rtfctl`. To verify the required outbound connectivity, run the following command on all controller and worker nodes in the cluster: ./rtfctl test outbound-network Sample output: \[root@rtf-controller-1 runtimefabric\]# ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ If you have outbound connectivity issues that prevent Runtime Fabric from reaching any of the required Anypoint control plane services, work with your network team to verify that you have added the required port IPs and hostnames to the allowlist as described in the port configuration section. ## Certificate Configuration To allow different endpoints to use mutual TLS authentication to establish a connection, you must configure SSL passthrough to allow the following certificates:
CloudHostnamePortProtocolPurpose

US Cloud

transport-layer.prod.cloudhub.io

443

AMQP over WebSockets

Message broker (mTLS)

US Cloud

configuration-resolver.prod.cloudhub.io

443

HTTPS

Configuration Resolver

US Cloud

us1.ingest.mulesoft.com

443

TCP (Lumberjack)

Anypoint Monitoring ingest

EU Cloud

transport-layer.prod-eu.msap.io

443

AMQP over WebSockets

Message broker (mTLS)

EU Cloud

configuration-resolver.prod-eu.msap.io

443

HTTPS

Configuration Resolver

Canada Cloud

arm-mcm2-service-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net

11443

WSS

Message broker (mTLS)

Canada Cloud

runtime-manager.ca1.platform.mulesoft.com

8443

HTTPS

Configuration Resolver and Runtime Manager services (consolidated endpoint)

Canada Cloud

ingest.ca1.platform.mulesoft.com

8443

HTTPS

Anypoint Monitoring ingest (OTEL)

Japan Cloud

arm-mcm2-service-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net

11443

WSS

Message broker (mTLS)

Japan Cloud

runtime-manager.jp1.platform.mulesoft.com

8443

HTTPS

Configuration Resolver and Runtime Manager services (consolidated endpoint)

Japan Cloud

ingest.jp1.platform.mulesoft.com

8443

HTTPS

Anypoint Monitoring ingest (OTEL)

India Cloud

runtime-manager.in1.platform.mulesoft.com

8443

WSS

Message broker (mTLS, path: /v1/connect)

India Cloud

runtime-manager.in1.platform.mulesoft.com

8443

HTTPS

Configuration Resolver and Runtime Manager services (consolidated endpoint, path: /resolver)

India Cloud

ingest.in1.platform.mulesoft.com

8443

HTTPS

Anypoint Monitoring ingest (OTEL)

Australia Cloud

runtime-manager.au1.platform.mulesoft.com

8443

WSS

Message broker (mTLS, path: /v1/connect)

Australia Cloud

runtime-manager.au1.platform.mulesoft.com

8443

HTTPS

Configuration Resolver and Runtime Manager services (consolidated endpoint, path: /resolver)

Australia Cloud

ingest.au1.platform.mulesoft.com

8443

HTTPS

Anypoint Monitoring ingest (OTEL)

United Kingdom Cloud

runtime-manager.gb1.platform.mulesoft.com

8443

WSS

Message broker (mTLS, path: /v1/connect)

United Kingdom Cloud

runtime-manager.gb1.platform.mulesoft.com

8443

HTTPS

Configuration Resolver and Runtime Manager services (consolidated endpoint, path: /resolver)

United Kingdom Cloud

ingest.gb1.platform.mulesoft.com

8443

HTTPS

Anypoint Monitoring ingest (OTEL)

--- product: Runtime Fabric version: 2.10 --- # Creating Namespaces for Application Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric version 1.12 or later enables you to create your own namespaces for application deployments. When you deploy an application into an Anypoint Platform environment, Runtime Fabric creates a new default namespace using the identifier of the environment. However, if you can create or modify a namespace with the appropriate Kubernetes labels, Runtime Fabric deploys applications into that namespace instead of into the default namespace. ## Create A Namespace 1. As a user with permissions to create a namespace, log in to a Kubernetes workstation. 2. Run the following commands: ```copy kubectl create ns kubectl label ns rtf.mulesoft.com/agentNamespace= rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= rtf.mulesoft.com/org= ``` - Replace `` with the name of your namespace. - Replace `` with the name of the namespace containing the RTF agent. - Replace `` with the correct ID for your environment. - Replace `` with the correct ID for your Business Group. After you run these commands, any application deployed into an Anypoint Platform environment identified by `` and `` is created inside the `` namespace by the RTF agent running in the ``. Before you deploy any applications into the new namespace, delete any autogenerated namespaces and any applications in them that use the same environment ID as the new namespace. Do not use the to deploy your Mule app. ## Troubleshooting Custom Namespaces If you encounter errors when attempting to create namespaces for Runtime Fabric, troubleshoot them as follows. ### More Than One Namespace Uses the Same Environment ID Imagine that you created more than one namespace using the same environment ID, as shown in the following example: ```copy $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc ``` In such cases, Runtime Fabric fails the deployment and creates an error message in Runtime Manager. Before you delete a namespace, ensure that you have not deployed any production applications into that namespace. --- product: Runtime Fabric version: 2.11 --- # Creating Namespaces for Application Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric version 1.12 or later enables you to create your own namespaces for application deployments. When you deploy an application into an Anypoint Platform environment, Runtime Fabric creates a new default namespace using the identifier of the environment. However, if you can create or modify a namespace with the appropriate Kubernetes labels, Runtime Fabric deploys applications into that namespace instead of into the default namespace. ## Create A Namespace 1. As a user with permissions to create a namespace, log in to a Kubernetes workstation. 2. Run these commands: ```copy kubectl create ns kubectl label ns rtf.mulesoft.com/agentNamespace= rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= rtf.mulesoft.com/org= ``` - Replace `` with the name of your namespace. - Replace `` with the name of the namespace containing the RTF agent. - Replace `` with the correct ID for your environment. - Replace `` with the correct ID for your Business Group. After you run these commands, any application deployed into an Anypoint Platform environment identified by `` and `` is created inside the `` namespace by the RTF agent running in the ``. Before you deploy any applications into the new namespace, delete any autogenerated namespaces and any applications in them that use the same environment ID as the new namespace. Do not use the to deploy your Mule app. ## Troubleshooting Custom Namespaces If you encounter errors when attempting to create namespaces for Runtime Fabric, troubleshoot them as follows. ### More Than One Namespace Uses the Same Environment ID Imagine that you created more than one namespace using the same environment ID, as shown in this example: ```copy $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc ``` In such cases, Runtime Fabric fails the deployment and creates an error message in Runtime Manager. Before you delete a namespace, ensure that you have not deployed any production applications into that namespace. --- product: Runtime Fabric version: 2.5 --- # Creating Namespaces for Application Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric version 1.12 or later enables you to create your own namespaces for application deployments. When you deploy an application into an Anypoint Platform environment, Runtime Fabric creates a new default namespace using the identifier of the environment. However, if you can create or modify a namespace with the appropriate Kubernetes labels, Runtime Fabric deploys applications into that namespace instead of into the default namespace. ## Create A Namespace 1. As a user with permissions to create a namespace, log in to a Kubernetes workstation. 2. Run the following commands: ```copy kubectl create ns kubectl label ns rtf.mulesoft.com/agentNamespace= rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= rtf.mulesoft.com/org= ``` - Replace `` with the name of your namespace. - Replace `` with the name of the namespace containing the RTF agent. - Replace `` with the correct ID for your environment. - Replace `` with the correct ID for your Business Group. After you run these commands, any application deployed into an Anypoint Platform environment identified by `` and `` is created inside the `` namespace by the RTF agent running in the ``. Before you deploy any applications into the new namespace, delete any autogenerated namespaces and any applications in them that use the same environment ID as the new namespace. Do not use the to deploy your Mule app. ## Troubleshooting Custom Namespaces If you encounter errors when attempting to create namespaces for Runtime Fabric, troubleshoot them as follows. ### More Than One Namespace Uses the Same Environment ID Imagine that you created more than one namespace using the same environment ID, as shown in the following example: ```copy $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc ``` In such cases, Runtime Fabric fails the deployment and creates an error message in Runtime Manager. Before you delete a namespace, ensure that you have not deployed any production applications into that namespace. --- product: Runtime Fabric version: 2.6 --- # Creating Namespaces for Application Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric version 1.12 or later enables you to create your own namespaces for application deployments. When you deploy an application into an Anypoint Platform environment, Runtime Fabric creates a new default namespace using the identifier of the environment. However, if you can create or modify a namespace with the appropriate Kubernetes labels, Runtime Fabric deploys applications into that namespace instead of into the default namespace. ## Create A Namespace 1. As a user with permissions to create a namespace, log in to a Kubernetes workstation. 2. Run the following commands: ```copy kubectl create ns kubectl label ns rtf.mulesoft.com/agentNamespace= rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= rtf.mulesoft.com/org= ``` - Replace `` with the name of your namespace. - Replace `` with the name of the namespace containing the RTF agent. - Replace `` with the correct ID for your environment. - Replace `` with the correct ID for your Business Group. After you run these commands, any application deployed into an Anypoint Platform environment identified by `` and `` is created inside the `` namespace by the RTF agent running in the ``. Before you deploy any applications into the new namespace, delete any autogenerated namespaces and any applications in them that use the same environment ID as the new namespace. Do not use the to deploy your Mule app. ## Troubleshooting Custom Namespaces If you encounter errors when attempting to create namespaces for Runtime Fabric, troubleshoot them as follows. ### More Than One Namespace Uses the Same Environment ID Imagine that you created more than one namespace using the same environment ID, as shown in the following example: ```copy $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc ``` In such cases, Runtime Fabric fails the deployment and creates an error message in Runtime Manager. Before you delete a namespace, ensure that you have not deployed any production applications into that namespace. --- product: Runtime Fabric version: 2.7 --- # Creating Namespaces for Application Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric version 1.12 or later enables you to create your own namespaces for application deployments. When you deploy an application into an Anypoint Platform environment, Runtime Fabric creates a new default namespace using the identifier of the environment. However, if you can create or modify a namespace with the appropriate Kubernetes labels, Runtime Fabric deploys applications into that namespace instead of into the default namespace. ## Create A Namespace 1. As a user with permissions to create a namespace, log in to a Kubernetes workstation. 2. Run the following commands: ```copy kubectl create ns kubectl label ns rtf.mulesoft.com/agentNamespace= rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= rtf.mulesoft.com/org= ``` - Replace `` with the name of your namespace. - Replace `` with the name of the namespace containing the RTF agent. - Replace `` with the correct ID for your environment. - Replace `` with the correct ID for your Business Group. After you run these commands, any application deployed into an Anypoint Platform environment identified by `` and `` is created inside the `` namespace by the RTF agent running in the ``. Before you deploy any applications into the new namespace, delete any autogenerated namespaces and any applications in them that use the same environment ID as the new namespace. Do not use the to deploy your Mule app. ## Troubleshooting Custom Namespaces If you encounter errors when attempting to create namespaces for Runtime Fabric, troubleshoot them as follows. ### More Than One Namespace Uses the Same Environment ID Imagine that you created more than one namespace using the same environment ID, as shown in the following example: ```copy $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc ``` In such cases, Runtime Fabric fails the deployment and creates an error message in Runtime Manager. Before you delete a namespace, ensure that you have not deployed any production applications into that namespace. --- product: Runtime Fabric version: 2.8 --- # Creating Namespaces for Application Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric version 1.12 or later enables you to create your own namespaces for application deployments. When you deploy an application into an Anypoint Platform environment, Runtime Fabric creates a new default namespace using the identifier of the environment. However, if you can create or modify a namespace with the appropriate Kubernetes labels, Runtime Fabric deploys applications into that namespace instead of into the default namespace. ## Create A Namespace 1. As a user with permissions to create a namespace, log in to a Kubernetes workstation. 2. Run the following commands: ```copy kubectl create ns kubectl label ns rtf.mulesoft.com/agentNamespace= rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= rtf.mulesoft.com/org= ``` - Replace `` with the name of your namespace. - Replace `` with the name of the namespace containing the RTF agent. - Replace `` with the correct ID for your environment. - Replace `` with the correct ID for your Business Group. After you run these commands, any application deployed into an Anypoint Platform environment identified by `` and `` is created inside the `` namespace by the RTF agent running in the ``. Before you deploy any applications into the new namespace, delete any autogenerated namespaces and any applications in them that use the same environment ID as the new namespace. Do not use the to deploy your Mule app. ## Troubleshooting Custom Namespaces If you encounter errors when attempting to create namespaces for Runtime Fabric, troubleshoot them as follows. ### More Than One Namespace Uses the Same Environment ID Imagine that you created more than one namespace using the same environment ID, as shown in the following example: ```copy $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc ``` In such cases, Runtime Fabric fails the deployment and creates an error message in Runtime Manager. Before you delete a namespace, ensure that you have not deployed any production applications into that namespace. --- product: Runtime Fabric version: 2.9 --- # Creating Namespaces for Application Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric version 1.12 or later enables you to create your own namespaces for application deployments. When you deploy an application into an Anypoint Platform environment, Runtime Fabric creates a new default namespace using the identifier of the environment. However, if you can create or modify a namespace with the appropriate Kubernetes labels, Runtime Fabric deploys applications into that namespace instead of into the default namespace. ## Create A Namespace 1. As a user with permissions to create a namespace, log in to a Kubernetes workstation. 2. Run the following commands: ```copy kubectl create ns kubectl label ns rtf.mulesoft.com/agentNamespace= rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= rtf.mulesoft.com/org= ``` - Replace `` with the name of your namespace. - Replace `` with the name of the namespace containing the RTF agent. - Replace `` with the correct ID for your environment. - Replace `` with the correct ID for your Business Group. After you run these commands, any application deployed into an Anypoint Platform environment identified by `` and `` is created inside the `` namespace by the RTF agent running in the ``. Before you deploy any applications into the new namespace, delete any autogenerated namespaces and any applications in them that use the same environment ID as the new namespace. Do not use the to deploy your Mule app. ## Troubleshooting Custom Namespaces If you encounter errors when attempting to create namespaces for Runtime Fabric, troubleshoot them as follows. ### More Than One Namespace Uses the Same Environment ID Imagine that you created more than one namespace using the same environment ID, as shown in the following example: ```copy $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc ``` In such cases, Runtime Fabric fails the deployment and creates an error message in Runtime Manager. Before you delete a namespace, ensure that you have not deployed any production applications into that namespace. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Creating Namespaces for Application Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric version 1.12 or later enables you to create your own namespaces for application deployments. When you deploy an application into an Anypoint Platform environment, Runtime Fabric creates a new default namespace using the identifier of the environment. However, if you can create or modify a namespace with the appropriate Kubernetes labels, Runtime Fabric deploys applications into that namespace instead of into the default namespace. ## Create A Namespace 1. As a user with permissions to create a namespace, log in to a Kubernetes workstation. 2. Run the following commands: ```copy kubectl create ns kubectl label ns rtf.mulesoft.com/agentNamespace= rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= rtf.mulesoft.com/org= ``` - Replace `` with the name of your namespace. - Replace `` with the name of the namespace containing the RTF agent. - Replace `` with the correct ID for your environment. - Replace `` with the correct ID for your Business Group. After you run these commands, any application deployed into an Anypoint Platform environment identified by `` and `` is created inside the `` namespace by the RTF agent running in the ``. Before you deploy any applications into the new namespace, delete any autogenerated namespaces and any applications in them that use the same environment ID as the new namespace. Do not use the to deploy your Mule app. ## Troubleshooting Custom Namespaces If you encounter errors when attempting to create namespaces for Runtime Fabric, troubleshoot them as follows. ### More Than One Namespace Uses the Same Environment ID Imagine that you created more than one namespace using the same environment ID, as shown in the following example: ```copy $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc ``` In such cases, Runtime Fabric fails the deployment and creates an error message in Runtime Manager. Before you delete a namespace, ensure that you have not deployed any production applications into that namespace. --- product: Runtime Fabric version: 2.5 --- # Customize Mule App Kubernetes Resources > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. Name the `kubernetestemplate` resource as `mule-application`. You can define the template in two different namespaces: - Apps namespace The template is applied to all Mule apps deployed to the given namespace. - Runtime Fabric agent namespace The template is applied to all Mule apps managed by the given Runtime Fabric agent. The `kubernetestemplate` resource applies only to new Mule app deployments after the resource creation. It does not affect existing deployments. If you redeploy a Mule app after creating or updating the `kubernetestemplate`, the template is applied. The `kubernetestemplate` resource enables you to configure the following elements of your apps pods, deployments, and services objects: - Pod - [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [Node selectors](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [Ephemeral storage limit](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [Topology spread constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) For the security context pod, the key to use is `containerSecurityContext`. - Deployment - Annotations - Labels - Service - Annotations - Labels Configuration elements already defined by Runtime Fabric take precedence over the ones you define in the template. To get the CRD of key elements that you can configure for the template, you can get the Kubernetes specification by running the following command: ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## Examples Configuring `labels` at `pod`, `deploy`, and `service` objects: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` Configuring the runtime default `seccompProfile` for `containerSecurityContext` under the `pod` object: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` Another example with all the keys that you can configure: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4gb nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: {{ .Values.id }} ``` Key elements that can not be overwritten using the CRD: - Deployment - labels - environment - organization - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - Pods - annotations - fluentbit.io/exclude - mulesoft.com/resources - labels - app - environment - am-org-id - root-org-id - organization - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - Resources - ephemeral-storage (if is not set in env.resources or cluster flavor is rtfc) - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity - podAntiAffinity - Service - labels - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization --- product: Runtime Fabric version: 2.10 --- # Customizing Mule App Kubernetes Resources > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. Name the `kubernetestemplate` resource as `mule-application`. You can define the template in two different namespaces: - Apps namespace The template is applied to all Mule apps deployed to the given namespace. - Runtime Fabric agent namespace The template is applied to all Mule apps managed by the given Runtime Fabric agent. The `kubernetestemplate` resource applies only to new Mule app deployments after the resource creation. It does not affect existing deployments. If you redeploy a Mule app after creating or updating the `kubernetestemplate`, the template is applied. The `kubernetestemplate` resource enables you to configure the following elements of your apps pods, deployments, and services objects: - Pod - [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [Node selectors](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [Ephemeral storage limit](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [Topology spread constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) - [Service Account Token](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting/) Note that customization of environment variables is not supported: - [Environment Variables](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) The env supported only keywords are for [enable console logging](#enable-console-logging) and [disable service account](#disable-service-account). For the security context pod, the key to use is `containerSecurityContext`. - Deployment - Annotations - Labels - Service - Annotations - Labels Configuration elements already defined by Runtime Fabric take precedence over the ones you define in the template. To get the CRD of key elements that you can configure for the template, you can get the Kubernetes specification by running the following command: ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## Examples Configuring `labels` at `pod`, `deploy`, and `service` objects: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` Configuring the runtime default `seccompProfile` for `containerSecurityContext` under the `pod` object: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` Another example with all the keys that you can configure: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: env: ENABLE_CONSOLE_LOG: "true" automountServiceAccountToken: true containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4Gi nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" rtf.mulesoft.com/generation: "{{ .Values.resourceContentHash }}" ``` Key elements that can not be overwritten using the CRD: - Deployment - labels - environment - organization - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - Pods - annotations - fluentbit.io/exclude - mulesoft.com/resources - labels - app - environment - am-org-id - root-org-id - organization - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - Resources - ephemeral-storage (if is not set in env.resources or cluster flavor is rtfc) - ServiceAccountToken - automountServiceAccountToken - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity - nodeAffinity: rtf.mulesoft.com/non-worker - podAntiAffinity - Service - labels - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization ## Enable Console Logging By default, console logging is disabled if it’s detected that your Mule app logs at least one other source. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. To enable console log using the Kubernetes template, set the `ENABLE_CONSOLE_LOG` variable in the `env` section: ```copy pod: env: ENABLE_CONSOLE_LOG: "true" ``` > [!NOTE] For clusters that forward logs using `stdout`, there is potential impact on log forwarding > functionality. Work with your Kubernetes team to adjust log forwarding configurations accordingly > and ensure continuous log monitoring and collection. If you use a side car container for Anypoint Monitoring (with AMLogFwdingAppender), console logging is also disabled. ## Disable Per Application Service Account By default, a [service account](https://kubernetes.io/docs/concepts/security/service-accounts/) is created for every Mule application deployment. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. If disabled, the Mule application deployment uses the [default service account](https://kubernetes.io/docs/concepts/security/service-accounts/#default-service-accounts). To disable the creation of the service account per Mule application using the Kubernetes template, set the `DISABLE_PER_APP_SA` variable in the `env` section: ```copy pod: env: DISABLE_PER_APP_SA: "true" ``` --- product: Runtime Fabric version: 2.11 --- # Customizing Mule App Kubernetes Resources > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. Name the `kubernetestemplate` resource as `mule-application`. You can define the template in two different namespaces: - Apps namespace The template is applied to all Mule apps deployed to the given namespace. - Runtime Fabric agent namespace The template is applied to all Mule apps managed by the given Runtime Fabric agent. The `kubernetestemplate` resource applies only to new Mule app deployments after the resource creation. It does not affect existing deployments. If you redeploy a Mule app after creating or updating the `kubernetestemplate`, the template is applied. The `kubernetestemplate` resource enables you to configure these elements of your apps pods, deployments, and services objects: - Pod - [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [Node selectors](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [Ephemeral storage limit](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [Topology spread constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) - [Service Account Token](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting/) Note that customization of environment variables is not supported: - [Environment Variables](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) The env supported only keywords are for [enable console logging](#enable-console-logging) and [disable service account](#disable-service-account). For the security context pod, the key to use is `containerSecurityContext`. - Deployment - Annotations - Labels - Service - Annotations - Labels Configuration elements already defined by Runtime Fabric take precedence over the ones you define in the template. To get the CRD of key elements that you can configure for the template, you can get the Kubernetes specification by running this command: ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## Examples Configuring `labels` at `pod`, `deploy`, and `service` objects: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` Configuring the runtime default `seccompProfile` for `containerSecurityContext` under the `pod` object: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` Another example with all the keys that you can configure: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: env: ENABLE_CONSOLE_LOG: "true" automountServiceAccountToken: true containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4Gi nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" rtf.mulesoft.com/generation: "{{ .Values.resourceContentHash }}" ``` Key elements that can not be overwritten using the CRD: - Deployment - labels - environment - organization - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - Pods - annotations - fluentbit.io/exclude - mulesoft.com/resources - labels - app - environment - am-org-id - root-org-id - organization - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - Resources - ephemeral-storage (if is not set in env.resources or cluster flavor is rtfc) - ServiceAccountToken - automountServiceAccountToken - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity - podAntiAffinity - Service - labels - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization ## Enable Console Logging By default, console logging is disabled if it’s detected that your Mule app logs at least one other source. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. To enable console log using the Kubernetes template, set the `ENABLE_CONSOLE_LOG` variable in the `env` section: ```copy pod: env: ENABLE_CONSOLE_LOG: "true" ``` > [!NOTE] For clusters that forward logs using `stdout`, there is potential impact on log forwarding > functionality. Work with your Kubernetes team to adjust log forwarding configurations accordingly > and ensure continuous log monitoring and collection. If you use a side car container for Anypoint Monitoring (with AMLogFwdingAppender), console logging is also disabled. ## Disable Per Application Service Account By default, a [service account](https://kubernetes.io/docs/concepts/security/service-accounts/) is created for every Mule application deployment. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. If disabled, the Mule application deployment uses the [default service account](https://kubernetes.io/docs/concepts/security/service-accounts/#default-service-accounts). To disable the creation of the service account per Mule application using the Kubernetes template, set the `DISABLE_PER_APP_SA` variable in the `env` section: ```copy pod: env: DISABLE_PER_APP_SA: "true" ``` --- product: Runtime Fabric version: 2.6 --- # Customizing Mule App Kubernetes Resources > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. Name the `kubernetestemplate` resource as `mule-application`. You can define the template in two different namespaces: - Apps namespace The template is applied to all Mule apps deployed to the given namespace. - Runtime Fabric agent namespace The template is applied to all Mule apps managed by the given Runtime Fabric agent. The `kubernetestemplate` resource applies only to new Mule app deployments after the resource creation. It does not affect existing deployments. If you redeploy a Mule app after creating or updating the `kubernetestemplate`, the template is applied. The `kubernetestemplate` resource enables you to configure the following elements of your apps pods, deployments, and services objects: - Pod - [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [Node selectors](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [Ephemeral storage limit](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [Topology spread constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) - [Service Account Token](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting/) - [Environment Variables](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) For the security context pod, the key to use is `containerSecurityContext`. - Deployment - Annotations - Labels - Service - Annotations - Labels Configuration elements already defined by Runtime Fabric take precedence over the ones you define in the template. To get the CRD of key elements that you can configure for the template, you can get the Kubernetes specification by running the following command: ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## Examples Configuring `labels` at `pod`, `deploy`, and `service` objects: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` Configuring the runtime default `seccompProfile` for `containerSecurityContext` under the `pod` object: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` Another example with all the keys that you can configure: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: env: ENABLE_CONSOLE_LOG: "true" automountServiceAccountToken: true containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4gb nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" ``` Key elements that can not be overwritten using the CRD: - Deployment - labels - environment - organization - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - Pods - annotations - fluentbit.io/exclude - mulesoft.com/resources - labels - app - environment - am-org-id - root-org-id - organization - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - Resources - ephemeral-storage (if is not set in env.resources or cluster flavor is rtfc) - ServiceAccountToken - automountServiceAccountToken - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity - podAntiAffinity - Service - labels - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization ## Enable Console Logging By default, console logging is disabled if it’s detected that your Mule app logs at least one other source. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. To enable console log using the Kubernetes template, set the `ENABLE_CONSOLE_LOG` variable in the `env` section: ```copy pod: env: ENABLE_CONSOLE_LOG: "true" ``` > [!NOTE] For clusters that forward logs using `stdout`, there is potential impact on log forwarding > functionality. Work with your Kubernetes team to adjust log forwarding configurations accordingly > and ensure continuous log monitoring and collection. --- product: Runtime Fabric version: 2.7 --- # Customizing Mule App Kubernetes Resources > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. Name the `kubernetestemplate` resource as `mule-application`. You can define the template in two different namespaces: - Apps namespace The template is applied to all Mule apps deployed to the given namespace. - Runtime Fabric agent namespace The template is applied to all Mule apps managed by the given Runtime Fabric agent. The `kubernetestemplate` resource applies only to new Mule app deployments after the resource creation. It does not affect existing deployments. If you redeploy a Mule app after creating or updating the `kubernetestemplate`, the template is applied. The `kubernetestemplate` resource enables you to configure the following elements of your apps pods, deployments, and services objects: - Pod - [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [Node selectors](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [Ephemeral storage limit](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [Topology spread constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) - [Service Account Token](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting/) Note that customization of environment variables is not supported: - [Environment Variables](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) The env supported only keywords are for [enable console logging](#enable-console-logging) and [disable service account](#disable-service-account). For the security context pod, the key to use is `containerSecurityContext`. - Deployment - Annotations - Labels - Service - Annotations - Labels Configuration elements already defined by Runtime Fabric take precedence over the ones you define in the template. To get the CRD of key elements that you can configure for the template, you can get the Kubernetes specification by running the following command: ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## Examples Configuring `labels` at `pod`, `deploy`, and `service` objects: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` Configuring the runtime default `seccompProfile` for `containerSecurityContext` under the `pod` object: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` Another example with all the keys that you can configure: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: env: ENABLE_CONSOLE_LOG: "true" automountServiceAccountToken: true containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4Gi nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" ``` Key elements that can not be overwritten using the CRD: - Deployment - labels - environment - organization - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - Pods - annotations - fluentbit.io/exclude - mulesoft.com/resources - labels - app - environment - am-org-id - root-org-id - organization - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - Resources - ephemeral-storage (if is not set in env.resources or cluster flavor is rtfc) - ServiceAccountToken - automountServiceAccountToken - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity - podAntiAffinity - Service - labels - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization ## Enable Console Logging By default, console logging is disabled if it’s detected that your Mule app logs at least one other source. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. To enable console log using the Kubernetes template, set the `ENABLE_CONSOLE_LOG` variable in the `env` section: ```copy pod: env: ENABLE_CONSOLE_LOG: "true" ``` > [!NOTE] For clusters that forward logs using `stdout`, there is potential impact on log forwarding > functionality. Work with your Kubernetes team to adjust log forwarding configurations accordingly > and ensure continuous log monitoring and collection. If you use a side car container for Anypoint Monitoring (with AMLogFwdingAppender), console logging is also disabled. ## Disable Per Application Service Account By default, a [service account](https://kubernetes.io/docs/concepts/security/service-accounts/) is created for every Mule application deployment. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. If disabled, the Mule application deployment uses the [default service account](https://kubernetes.io/docs/concepts/security/service-accounts/#default-service-accounts). To disable the creation of the service account per Mule application using the Kubernetes template, set the `DISABLE_PER_APP_SA` variable in the `env` section: ```copy pod: env: DISABLE_PER_APP_SA: "true" ``` --- product: Runtime Fabric version: 2.8 --- # Customizing Mule App Kubernetes Resources > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. Name the `kubernetestemplate` resource as `mule-application`. You can define the template in two different namespaces: - Apps namespace The template is applied to all Mule apps deployed to the given namespace. - Runtime Fabric agent namespace The template is applied to all Mule apps managed by the given Runtime Fabric agent. The `kubernetestemplate` resource applies only to new Mule app deployments after the resource creation. It does not affect existing deployments. If you redeploy a Mule app after creating or updating the `kubernetestemplate`, the template is applied. The `kubernetestemplate` resource enables you to configure the following elements of your apps pods, deployments, and services objects: - Pod - [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [Node selectors](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [Ephemeral storage limit](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [Topology spread constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) - [Service Account Token](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting/) Note that customization of environment variables is not supported: - [Environment Variables](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) The env supported only keywords are for [enable console logging](#enable-console-logging) and [disable service account](#disable-service-account). For the security context pod, the key to use is `containerSecurityContext`. - Deployment - Annotations - Labels - Service - Annotations - Labels Configuration elements already defined by Runtime Fabric take precedence over the ones you define in the template. To get the CRD of key elements that you can configure for the template, you can get the Kubernetes specification by running the following command: ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## Examples Configuring `labels` at `pod`, `deploy`, and `service` objects: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` Configuring the runtime default `seccompProfile` for `containerSecurityContext` under the `pod` object: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` Another example with all the keys that you can configure: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: env: ENABLE_CONSOLE_LOG: "true" automountServiceAccountToken: true containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4Gi nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" ``` Key elements that can not be overwritten using the CRD: - Deployment - labels - environment - organization - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - Pods - annotations - fluentbit.io/exclude - mulesoft.com/resources - labels - app - environment - am-org-id - root-org-id - organization - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - Resources - ephemeral-storage (if is not set in env.resources or cluster flavor is rtfc) - ServiceAccountToken - automountServiceAccountToken - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity - podAntiAffinity - Service - labels - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization ## Enable Console Logging By default, console logging is disabled if it’s detected that your Mule app logs at least one other source. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. To enable console log using the Kubernetes template, set the `ENABLE_CONSOLE_LOG` variable in the `env` section: ```copy pod: env: ENABLE_CONSOLE_LOG: "true" ``` > [!NOTE] For clusters that forward logs using `stdout`, there is potential impact on log forwarding > functionality. Work with your Kubernetes team to adjust log forwarding configurations accordingly > and ensure continuous log monitoring and collection. If you use a side car container for Anypoint Monitoring (with AMLogFwdingAppender), console logging is also disabled. ## Disable Per Application Service Account By default, a [service account](https://kubernetes.io/docs/concepts/security/service-accounts/) is created for every Mule application deployment. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. If disabled, the Mule application deployment uses the [default service account](https://kubernetes.io/docs/concepts/security/service-accounts/#default-service-accounts). To disable the creation of the service account per Mule application using the Kubernetes template, set the `DISABLE_PER_APP_SA` variable in the `env` section: ```copy pod: env: DISABLE_PER_APP_SA: "true" ``` --- product: Runtime Fabric version: 2.9 --- # Customizing Mule App Kubernetes Resources > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. Name the `kubernetestemplate` resource as `mule-application`. You can define the template in two different namespaces: - Apps namespace The template is applied to all Mule apps deployed to the given namespace. - Runtime Fabric agent namespace The template is applied to all Mule apps managed by the given Runtime Fabric agent. The `kubernetestemplate` resource applies only to new Mule app deployments after the resource creation. It does not affect existing deployments. If you redeploy a Mule app after creating or updating the `kubernetestemplate`, the template is applied. The `kubernetestemplate` resource enables you to configure the following elements of your apps pods, deployments, and services objects: - Pod - [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [Node selectors](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [Ephemeral storage limit](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [Topology spread constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) - [Service Account Token](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting/) Note that customization of environment variables is not supported: - [Environment Variables](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) The env supported only keywords are for [enable console logging](#enable-console-logging) and [disable service account](#disable-service-account). For the security context pod, the key to use is `containerSecurityContext`. - Deployment - Annotations - Labels - Service - Annotations - Labels Configuration elements already defined by Runtime Fabric take precedence over the ones you define in the template. To get the CRD of key elements that you can configure for the template, you can get the Kubernetes specification by running the following command: ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## Examples Configuring `labels` at `pod`, `deploy`, and `service` objects: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` Configuring the runtime default `seccompProfile` for `containerSecurityContext` under the `pod` object: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` Another example with all the keys that you can configure: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: env: ENABLE_CONSOLE_LOG: "true" automountServiceAccountToken: true containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4Gi nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" rtf.mulesoft.com/generation: "{{ .Values.resourceContentHash }}" ``` Key elements that can not be overwritten using the CRD: - Deployment - labels - environment - organization - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - Pods - annotations - fluentbit.io/exclude - mulesoft.com/resources - labels - app - environment - am-org-id - root-org-id - organization - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - Resources - ephemeral-storage (if is not set in env.resources or cluster flavor is rtfc) - ServiceAccountToken - automountServiceAccountToken - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity - podAntiAffinity - Service - labels - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization ## Enable Console Logging By default, console logging is disabled if it’s detected that your Mule app logs at least one other source. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. To enable console log using the Kubernetes template, set the `ENABLE_CONSOLE_LOG` variable in the `env` section: ```copy pod: env: ENABLE_CONSOLE_LOG: "true" ``` > [!NOTE] For clusters that forward logs using `stdout`, there is potential impact on log forwarding > functionality. Work with your Kubernetes team to adjust log forwarding configurations accordingly > and ensure continuous log monitoring and collection. If you use a side car container for Anypoint Monitoring (with AMLogFwdingAppender), console logging is also disabled. ## Disable Per Application Service Account By default, a [service account](https://kubernetes.io/docs/concepts/security/service-accounts/) is created for every Mule application deployment. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. If disabled, the Mule application deployment uses the [default service account](https://kubernetes.io/docs/concepts/security/service-accounts/#default-service-accounts). To disable the creation of the service account per Mule application using the Kubernetes template, set the `DISABLE_PER_APP_SA` variable in the `env` section: ```copy pod: env: DISABLE_PER_APP_SA: "true" ``` --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Customizing Mule App Kubernetes Resources > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. Name the `kubernetestemplate` resource as `mule-application`. You can define the template in two different namespaces: - Apps namespace The template is applied to all Mule apps deployed to the given namespace. - Runtime Fabric agent namespace The template is applied to all Mule apps managed by the given Runtime Fabric agent. The `kubernetestemplate` resource applies only to new Mule app deployments after the resource creation. It does not affect existing deployments. If you redeploy a Mule app after creating or updating the `kubernetestemplate`, the template is applied. The `kubernetestemplate` resource enables you to configure the following elements of your apps pods, deployments, and services objects: - Pod - [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [Node selectors](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [Ephemeral storage limit](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [Topology spread constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) - [Service Account Token](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting/) Note that customization of environment variables is not supported: - [Environment Variables](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) The env supported only keywords are for [enable console logging](#enable-console-logging) and [disable service account](#disable-service-account). For the security context pod, the key to use is `containerSecurityContext`. - Deployment - Annotations - Labels - Service - Annotations - Labels Configuration elements already defined by Runtime Fabric take precedence over the ones you define in the template. To get the CRD of key elements that you can configure for the template, you can get the Kubernetes specification by running the following command: ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## Examples Configuring `labels` at `pod`, `deploy`, and `service` objects: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` Configuring the runtime default `seccompProfile` for `containerSecurityContext` under the `pod` object: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` Another example with all the keys that you can configure: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: env: ENABLE_CONSOLE_LOG: "true" automountServiceAccountToken: true containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4Gi nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" rtf.mulesoft.com/generation: "{{ .Values.resourceContentHash }}" ``` Key elements that can not be overwritten using the CRD: - Deployment - labels - environment - organization - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - Pods - annotations - fluentbit.io/exclude - mulesoft.com/resources - labels - app - environment - am-org-id - root-org-id - organization - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - Resources - ephemeral-storage (if is not set in env.resources or cluster flavor is rtfc) - ServiceAccountToken - automountServiceAccountToken - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity - podAntiAffinity - Service - labels - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization ## Enable Console Logging By default, console logging is disabled if it’s detected that your Mule app logs at least one other source. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. To enable console log using the Kubernetes template, set the `ENABLE_CONSOLE_LOG` variable in the `env` section: ```copy pod: env: ENABLE_CONSOLE_LOG: "true" ``` > [!NOTE] For clusters that forward logs using `stdout`, there is potential impact on log forwarding > functionality. Work with your Kubernetes team to adjust log forwarding configurations accordingly > and ensure continuous log monitoring and collection. If you use a side car container for Anypoint Monitoring (with AMLogFwdingAppender), console logging is also disabled. ## Disable Per Application Service Account By default, a [service account](https://kubernetes.io/docs/concepts/security/service-accounts/) is created for every Mule application deployment. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. If disabled, the Mule application deployment uses the [default service account](https://kubernetes.io/docs/concepts/security/service-accounts/#default-service-accounts). To disable the creation of the service account per Mule application using the Kubernetes template, set the `DISABLE_PER_APP_SA` variable in the `env` section: ```copy pod: env: DISABLE_PER_APP_SA: "true" ``` ## Enable Readiness Probe on HTTP GET To enable the native K8s HTTP GET probe for readiness on Mule applications using the Kubernetes template, set the `ENABLE_READINESS_PROBE_ON_HTTP_GET` variable in the `env` section: ```copy pod: env: ENABLE_READINESS_PROBE_ON_HTTP_GET: "true" ``` This setting defaults to `false`. When you enable it on Runtime Fabric 3.0.1 or later, use Mule runtime engine patches from November 7, 2025 and later for your applications. For compatible patch versions, see the [November 7, 2025](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#november-7-2025) section of the Runtime Fabric runtimes release notes. Applications on older patches may fail to become ready or restart correctly when this feature is enabled. To enable the HTTP GET readiness probe for applications running on Mule runtime engine patches older than November 7, 2025, either upgrade those applications to a compatible patch or keep the feature disabled until you can upgrade. ## See Also - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/configure-kubernetes) --- product: Runtime Fabric version: 2.5 --- # Deploy and Manage Apps in Runtime Fabric Using the CLI > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these Anypoint Platform CLI commands for deploying and managing applications in Runtime Fabric. The CLI supports both the interactive shell and standard CLI modes. Runtime Fabric currently supports only Anypoint CLI version 3.x. Before you get started, review [Anypoint CLI prerequisites, installation, and authentication instructions](https://docs.mulesoft.com/anypoint-cli/3.x/). > [!NOTE] Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term > Support (LTS). The Mule runtime versioning schema for the new release channels is: > > _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, > nothing for LTS\]_ > > Some examples of these values are: `4.5.0:1e` for Edge, and `4.6.0:1` for LTS.
CommandDescription

Deletes an application

Deploys an application to a specified target using an Exchange application and runs the specified runtime version

Describes an application

Describes an application in a raw JSON response

Downloads logs of an application from a specification to a specified directory

Lists all applications in an organization

Modifies a deployed application

Starts a stopped application

Stops running an application

Tails an application’s logs from a specification

## runtime-mgr application delete \> runtime-mgr application delete \[options\] Deletes the running application specified in ``. To get this ID, run the `runtime-mgr application list` command. > [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction, > it does not ask for confirmation. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application deploy \> runtime-mgr application deploy \[options\] Deploys the application specified in `` to the deployment target specified using the following options:
ValueDescriptionExample

ArtifactId

Artifact ID of the application retrieved from Exchange.

mule-test-plugin

deploymentTargetID

ID of the deployment target.
You can get this ID directly from Runtime Manager.

app.runetime

name

Name of the application to deploy.

testCloudhub2app

runtimeVersion

Runtime version of the deployment target.

1.0.1

Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default:.disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID

org.mule.test

javaVersion

Set the name of the JAVA version to be used for the selected Mule version. Supported values are 8 and 17. If you do not specify a value, Runtime Fabric imposes the default value. The default JAVA version for Mule 4.6 and earlier versions is '8'. If you don’t specify a Mule version, the default Mule version for the selected JAVA version is used. If the JAVA version you select is not available for the specified Mule version, you get an error.

8

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

memory

The amount of memory allocated to each replica of a Mule application or API gateway.

0.7

objectStoreV2

Enables Object Store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example:/status?limit=10

releaseChannel

Set the name of the release channel to be used for the selected Mule version. Supported values are NONE, EDGE, and LTS. If you do not specify a value, Runtime Fabric imposes the default value. The default release channel is EDGE. If you don’t specify a Mule version, the default Mule version for the selected release channel is used. If the selected release channel doesn’t exist, you get an error.

EDGE

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

reservedCPU

The amount of vCPU guaranteed to the application and reserved for its use.

0.02

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: one tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

vCPULimit

The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node.

3.9

## runtime-mgr application describe \> runtime-mgr application describe \[options\] Displays information about the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] Displays a raw JSON response from the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] Downloads logs for the application specified in `` from the specification specified in `` to the selected directory. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application list \> runtime-mgr application list \[options\] Lists all applications in your organization. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application modify \> runtime-mgr application modify \[options\] Updates the settings of an existing application specified in ``. To get the ``, run the `runtime-mgr application list` command. Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

ArtifactId

ID of the application retrieved from Exchange.

mule-maven-plugin

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default: disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID.

org.mule.testgroup

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

objectStoreV2

Enables object store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000.

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example: /status?limit=10

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

runtimeVersion

Runtime version of the deployment target.

1.0.1

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: 1 tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

## runtime-mgr application start \> runtime-mgr application start \[options\] Starts running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application stop \> runtime-mgr application stop \[options\] Stops running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] Tails application logs for the application specificied in `` from the specification specified in ``. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default option `--help`. ## runtime-mgr rtf list \> runtime-mgr rtf list \[options\] This command lists available Runtime Fabric instances. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output`. For information about managing your Runtime Fabric instances using the command line, see [Supported rtfctl Commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands). --- product: Runtime Fabric version: 2.5 --- # Deploy Mule Applications to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You deploy Mule applications to Mule runtime servers on Anypoint Runtime Fabric. Applications deployed to a production environment must be deployed to an instance of Runtime Fabric that is separate from non-production applications. After deploying an application you can test the inbound traffic for deployed applications. ## Deploy a Mule Application to Runtime Fabric The full deployment process includes these steps: 1. Select the application and deployment target 2. Configure the deployment target 3. Configure a public endpoint for the application 4. Set up replication 5. (Optional) Enable TLSv1 and TLSv1.1 6. Configure application properties 7. Deploy the application Watch the following video to see how to deploy a Mule application to Runtime Fabric using Runtime Manager: ![](https://play.vidyard.com/CoePGwoZgbY8AZWQxGZQKA.jpg) ### Prerequisites Before deploying an application to Anypoint Runtime Fabric, perform the following: - Review the [Anypoint Platform Roles and Permissions](https://docs.mulesoft.com/runtime-fabric/2.5/#anypoint-platform-roles-and-permissions) necessary for deploying applications to Runtime Fabric. - Ensure that Runtime Fabric is associated with an environment. Refer to [Associating Business Groups and Environments to Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/associate-environments) - Determine the resource allocation requirements for your application. Refer to [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-resource-allocation-self-managed) for more information. - To deploy an application to a specific domain (endpoint), ensure that you have set up domains (endpoints) in your environment. Refer to [Configure Ingress For Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/custom-ingress-configuration). - If you’re using Runtime Fabric on Red Hat OpenShift, follow the steps in [Prepare for Deploying Mule Apps to Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.5/install-openshift#prepare-for-deploying-mule-apps-to-red-hat-openshift) to enable app deployment. ### Select the Application and Deployment Target 1. Sign into [Anypoint Platform](https://anypoint.mulesoft.com). 2. Navigate to **Runtime Manager**, and select **Applications**. 3. Click **Deploy application**. 4. Provide a name for your application in the **Application Name** field. The name can contain only lowercase alphanumeric characters, hyphens, and underscores. 5. Click **Choose File** to select the application to deploy, and then select one of the following options: - **Import file from Exchange**: Select a Mule application stored in Anypoint Exchange. - **Upload file**: Select a Mule application file from your filesystem. 6. From the **Deployment Target** drop-down list, select the name of your Runtime Fabric. 7. Select the Mule runtime engine version from the **Runtime Version** drop-down list. ![Runtime Manager UI with Mule Edge release dropdown window](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-rtm-mule-cadence.png) The **Deployment Target**, **Ingress**, **Properties**, **Logs**, and **JVM** tabs are displayed. Use these tabs to enter additional configuration information for your application. To learn more about Mule runtime versions supported by Runtime Fabric, refer to [Anypoint Runtime Fabric Patch Update Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). You can deploy Mule apps with Mule runtime engine versions that are within the standard support or extended support life. Specify the versions through the API or in the Runtime Manager UI. With a Mule runtime engine version in EOL (end of life) support, you can redeploy and restart Mule apps but can not deploy new Mule apps. ### Configure a Public Endpoint for the Application Use the following steps to configure a public endpoint for an application deployed to Runtime Fabric. Available domains and paths for an application come from the ingress resource template configured by your Runtime Fabric administrator. Refer to [Use Custom Ingress Resource Templates in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/custom-ingress-configuration) for more information. > [!NOTE] If you do not select a domain, the application is deployed to an empty domain. 1. Select **Ingress**. 2. From the **Host** drop-down list, select a host for the application. 3. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 4. In the **Path** field, add a URL path to the application’s endpoint: ![A host and path are set for the application’s endpoint](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-ingress-endpoint.png) 5. To preview the endpoint, click the generated preview link. 6. To add additional endpoints, click **\+ Add Endpoint**. ### Set Up Replication and Storage After you configure an application’s endpoints, set up replication to configure the number of application instances to deploy. A minimum of two replicas is required for high availability. You set up object to storage to enable data persistence across Mule application replicas and restarts. This option is only available on Mule runtime engine version 4.2.1 or later. If this option is unavailable, contact your IT administrator. Refer to [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.5/persistence-gateway) for more information. 1. Select the **Deployment Target** tab. This tab displays the name and type of the deployment target previously selected. 2. Select the number of replicas, or instances, of the application to deploy. 3. To enable Mule clustering across each replica of the application, enable **Run in Runtime Clustering Mode**. 4. To enforce the deployment of replicas across different nodes, select **Enforce deploying replicas across nodes**. > [!WARNING] If there is an insufficient number of worker nodes or resources available on the > worker nodes needed to deploy each replica, some replicas in the deployment remain in > **Pending** status. The deployment status will transition to **Running** after all replicas > are deployed on different worker nodes. 5. To enable data persistence, select **Use Persistent Object Storage**. 6. Specify the number of **Cores** and amount of **Memory** to allocate to each replica of the application by adjusting the sliders to the appropriate values. If needed, review [determine resource allocation](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-resource-allocation-self-managed) for applications deployed to Runtime Fabric. ### (Optional) Enable TLS v1 and TLS v1.1 Starting with the [August 3, 2021 patch releases](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021), Mule runtime disables TLS v1 and TLS v1.1 by default for all runtime versions. When you deploy an application to Runtime Fabric, you can enable TLS v1 or TLS v1.1 using JVM args. 1. Click the **JVM** tab. 2. In the **Java Virtual Machine arguments** field, add one of the following arguments: - Enable TLSv1.0 and TLSv1.1: `-Drtf.allow.TLSv1.0+` - Enable TLSv1.1: `-Drtf.allow.TLSv1.1` ### Configure Application Properties > [!NOTE] For instructions on protecting application property values, see > [Protect Application Property Values in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/protect-app-properties) Use Runtime Manager to configure any application property values, such as specifying the environment or setting passwords and usernames. Runtime Fabric resolves the property at runtime without exposing the sensitive information. 1. Click the **Properties** tab. 2. Click **Table view**. 3. In the **New Key** field, add a property to protect. 4. In the **New Value** field, add a value. 5. Add additional properties as needed. ### Configure Logging and Log Levels Anypoint Monitoring provides access to log data for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. 1. Click the **Logging** tab. 2. Select the **Enable application logs** option. 3. Select the log level from the drop-down list: - **INFO**: Informative messages - **DEBUG**: Debugging messages - **WARNING**: Warning messages - **ERROR**: Error messages, such as when an exception occurs - **FATAL**: Fatal messages for when an application fails 4. Optionally, set the log level for specific a Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key. 5. Click **Apply Changes**. ### Deploy the Application Now you’re ready to deploy the application. 1. To deploy the application, click **Deploy Application**. If the **Deploy Application** button is disabled, ensure that you have uploaded a valid Mule application file. Also ensure that the Mule runtime engine version you selected is the same as the version used by your application. _Result_: Runtime Manager displays a status message confirming the application deployment. After the deployment starts, you’ll be directed to the applications list page where you can view the deployment status. For newly deployed applications, the status initially displays as **Starting**. The status updates to **Started** if the application is successful. Monitor the application status to ensure that it starts successfully. ## Verify Inbound Traffic for Deployed Applications 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: ```copy 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](https://newapp.example-rtf.dev)`, and `192.168.64.14` is the IP address of a controller machine in your cluster. ```copy curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## Configure Continuous Deployment To set up a workflow for on-premises application deployment on Runtime Fabric, refer to [Workflow for On-Premises Runtime Fabric](https://docs.mulesoft.com/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc). ## Common Issues When deploying applications, you may encounter the following issues: - If your application remains in the **Starting** status for several minutes, this may be due to specifying a lower amount of resources. It’s common for applications to take several minutes to start up when selecting 0.3 cores or lower. - If the application encounters an error during startup, the deployment will stop and the status updates to **Failed**. An error message preview is displayed when clicking on the application and viewing the right sidebar. To view the entire message, click on the **Manage Application** button. - An error message indicating `insufficient resources` is returned when Runtime Fabric doesn’t have the CPU cores or memory available for the deployment. When selecting multiple replicas, it’s important to know that the cores and memory specified applies to _each_ replica. - If a re-deployment to an existing running application fails, the previous application remains running and active. This behavior enables zero-downtime application re-deployments. Runtime Manager will report the details and status of the failed deployment to help resolve the failure. ## See Also - [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-resource-allocation-self-managed) - [Deploy a Mule Application to CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [Deploy a Mule Application to a Hybrid Environment](https://docs.mulesoft.com/runtime-manager/deploying-to-your-own-servers) --- product: Runtime Fabric version: 2.5 --- # Deploying and Managing Applications to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API Proxies to a Mule runtime engine that is managed on Runtime Fabric. ## Supported Mule Runtime Server Versions See [Anypoint Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) for information on supported versions of Mule runtime server. ## Prerequisites Before you deploy a Mule application or API proxy to Runtime Fabric: - Install and configure a Runtime Fabric. - Ensure that you understand how resources are allocated as described in [Resource Allocation on Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-resource-allocation-self-managed). - Publish your Mule application or API proxy to Exchange. > [!NOTE] Before you deploy Mule applications and API proxies to Runtime Fabric, you must first > publish them to Exchange. When you deploy Mule applications and API proxies from Runtime > Manager, they are published to Exchange automatically. ## Deploy Using Runtime Manager You can use Runtime Manager to manually deploy Mule applications and API proxies. See [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-to-runtime-fabric). You can also use the Anypoint Platform CLI to deploy Mule applications. See [Deploying and Managing Apps in Runtime Fabric Using the CLI](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-to-rtf-cli). ## Deploy Using Maven Runtime Fabric supports Maven for managing and deploying a Mule application or API proxy. To deploy Mule applications and API proxies using Maven, see [Deploying Applications to Runtime Fabric using Maven](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-maven-4.x). ## Deployment Considerations ### Eventual consistency Runtime Fabric is a self healing, eventually consistent platform. When building a CI pipeline for Runtime Fabric deployment, you must take eventual consistency into consideration. After triggering a deployment, the application status should become `RUNNING`. If the application status never indicates `RUNNING`, the replicas contain a `state` and `reason` to indicate why the application is not `RUNNING`. ### Application Deployment When an application is deployed, the following events occur: - The expected state of your application is stored, including application bundle and number of replicas. - The application replica status shows as `PENDING`. - When adequate compute and memory resources are available, each replica is attached to a node. - If not already present, a Docker image corresponding to the Mule Runtime version is downloaded. - The replica status shows as `STARTING`. - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. ### Application Failure If an application fails, for example, due to running of out memory, the following events occur: - The replica status shows as `TERMINATED`. - Runtime Fabric immediately attempts to restart the replica. - The replica status shows as `RECOVERING`. - If the replica is able to restart: - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. - If the replica is initially unable to restart, for example, it relies on a network resource which temporarily unavailable, the following events occur: - The replica status shows as `PENDING`, with a message indicating "CrashLoopBackoff". Runtime Fabric attempts to restart the replica, using exponential backoff to avoid an excessive number of restart attempts. - The replica status alternates between `RECOVERING` and `PENDING` until the issue preventing a successful restart is resolved. - The replica loads the application. - After a successful restart, the replica shows as `STARTED` and is able to perform work. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Deploying and Managing Mule Applications Using Anypoint Controller for Kubernetes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Controller is a Kubernetes operator that enables you to deploy and manage Mule applications on Runtime Fabric using Kubernetes tools and Custom Resources (CR). With Anypoint Controller, you can: - Define application configurations declaratively in versioned manifest files and let the controller automatically reconcile them with Anypoint Platform and your cluster. - Use standard Kubernetes tools and practices to deploy Mule applications as Kubernetes Custom Resources, including `kubectl`, Helm, Terraform Kubernetes Provider, and GitOps workflows. - Leverage Kubernetes features such as external secret managers, volume mounts, and RBAC policies to meet enterprise security requirements. This guide shows you how to: - Install and configure Anypoint Controller in your Runtime Fabric cluster. - Deploy Mule applications using declarative Mule application Custom Resources (CRs). - Monitor application status using Kubernetes-native status conditions. - Update, delete, and manage application lifecycles with standard Kubernetes commands. - Integrate with CI/CD and GitOps tools like ArgoCD, FluxCD, and Terraform Kubernetes provider. - Configure Kubernetes-specific settings including volumes, secrets, and node affinity. - Troubleshoot common deployment and configuration issues. ## Scope and Limitations Anypoint Controller works with these deployment targets, runtime versions, and installation methods: - Runtime Fabric Mule application deployments - Mule runtime engine (Mule) versions 4.6 and higher. Note: Support is only available in patch versions released on or after [November 7, 2025](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#november-7-2025). Any patch version released prior to this date does not support Anypoint Controller. - Helm-based Runtime Fabric 3.0.1 installation or upgrade Anypoint Controller has these limitations and does not support: - CloudHub 2.0 Mule application deployments - Scheduler-based Mule applications - Omni Gateway deployments - `rtfctl`\-based Runtime Fabric installation or upgrade > [!IMPORTANT] Anypoint Runtime Fabric Command-Line Tool (rtfctl) supports the backup and restore of > the Mule Application Custom Resource Definition (CRD). However, Mule application CRs are not > supported for backup and restore using Anypoint Controller. > > You must plan your recovery strategy using your source control repository as the single source of > truth for all application configurations. After a Runtime Fabric cluster restore, you must > re-apply your Mule Application CRs from your repository. ## Before You Begin Anypoint Controller is designed for Kubernetes administrators with cluster access and proficiency in Kubernetes tools such as `kubectl`, Helm, and Custom Resources. Before you begin, review these prerequisites and environment setup requirements. ### Installation Prerequisites To use Anypoint Controller, you must either: - Have an existing Runtime Fabric installation using Helm. - [Install Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) or [upgrade Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-helm) using Helm. ### Management Limitations Understanding the management model is critical before deploying and managing applications with Anypoint Controller: - Applications created via Anypoint Controller can only be managed through the Custom Resource itself. - To manage existing applications using Anypoint Controller, you must redeploy them as a Kubernetes Custom Resource. - All configuration changes must be applied by updating the Custom Resource definition in your deployment tool and applying it to the cluster. - Stop and Restart functionality is not supported for applications managed by Anypoint Controller. - The Anypoint Platform Runtime Manager UI displays these applications in read-only mode. - Attempts to modify or delete these applications via Anypoint Platform APIs result in an error. ## Install and Configure Anypoint Controller To set up Anypoint Controller, complete these steps: 1. [Configure Anypoint Controller in Helm Chart](#configure-anypoint-controller-in-helm-chart) 2. [Define Mule Application CR](#define-muleapplication-custom-resource) 3. [Configure Volumes and Volume Mounts](#configure-volumes-and-volume-mounts) 4. [Create a Connected App](#create-an-anypoint-connected-app) 5. [Configure Anypoint Credentials](#configure-anypoint-credentials) ### Configure Anypoint Controller in Helm Chart To enable Anypoint Controller, configure these Helm chart settings: - `global.crds.install = true` Installs the MuleApplication Custom Resource Definition (CRD) in the cluster. The CRD is cluster-scoped and accessible by all Runtime Fabric instances in the cluster. - `agent.rtfd.anypointController.enabled = true` Enables the Anypoint Controller feature for the specific Runtime Fabric instance. You can configure these settings independently based on your deployment scenario: - Single Runtime Fabric instance: Set both `global.crds.install = true` and `agent.rtfd.anypointController.enabled = true`. - Multiple Runtime Fabric instances in the same cluster: - First instance: Set `global.crds.install = true` to install the CRD. Optionally, set `agent.rtfd.anypointController.enabled = true` if this instance manages applications. - Additional instances: Set only `agent.rtfd.anypointController.enabled = true`. The CRD installed by the first instance is accessible to all instances. For more information, see [Install Multiple Instances of Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-multiple-instances). For New Runtime Fabric Installations (Single Instance) 1. In your `values.yaml` file, add this configuration: ```yaml global: crds: install: true agent: rtfd: anypointController: enabled: true ``` 2. Install the Runtime Fabric agent: ```bash helm install runtime-fabric /rtf-agent \ -f values.yaml \ -n ``` For Multiple Runtime Fabric Instances First Runtime Fabric instance (installs the CRD): ```yaml global: crds: install: true agent: rtfd: anypointController: enabled: true # Optional: enable if this instance manages applications ``` Additional Runtime Fabric instances (use existing CRD): ```yaml global: crds: install: false # CRD already installed by first instance agent: rtfd: anypointController: enabled: true # Enable controller feature for this instance ``` For Upgrading Existing Runtime Fabric Installations 1. Update your `values.yaml` file with the appropriate configuration: ```yaml global: crds: install: true # Set to false if CRD is already installed agent: rtfd: anypointController: enabled: true ``` 2. Upgrade the Runtime Fabric agent: ```bash helm upgrade runtime-fabric /rtf-agent \ -f values.yaml \ -n ``` ### Define Mule Application CR Use the Custom Resource Definition (CRD) to define and manage Mule application configurations similar to any Kubernetes resources through Kubernetes APIs. Anypoint Controller watches the Mule application CR state and matches it against the desired configured state. Define your Mule application as a Custom Resource using your preferred deployment tool (such as YAML manifests with `kubectl`, Terraform, Helm charts, or GitOps tools). The Custom Resource specifies deployment configurations such as CPU and memory resources, replica count, runtime version, application artifact details, properties, volume mounts for secrets and configuration files, and Kubernetes-specific settings. After you apply this file to your Kubernetes cluster, for example by using `kubectl apply -f .yaml`, Anypoint Controller deploys the application based on the specifications. For a complete reference of all available MuleApplicationCR fields and configuration options, see [Understanding Custom Resource Definitions](#understanding-custom-resource-definitions). #### Basic MuleApplication Structure YAML File ```yaml apiVersion: rtf.mulesoft.com/v1 kind: MuleApplication metadata: name: my-hello-world-app namespace: my-apps spec: target: my-rtf-target businessGroup: MyOrg environment: Production runtimeVersion: "4.8.0:2e-java8" application: group: my-org artifactId: hello-world version: "1.0.0" packaging: jar replicas: 2 resources: requests: cpu: 500m memory: 1Gi ``` ### Configure Volumes and Volume Mounts Use the `volumes` and `volumeMounts` fields to mount standard Kubernetes volume types into your Mule application containers, including sensitive data (credentials, API keys, certificates), configuration files, and persistent storage: - `volumes` Defines the storage volumes available to the application, such as Kubernetes Secrets, ConfigMaps, persistent volumes, or external secret stores. - `volumeMounts` Specifies where to mount the volumes inside the application container and makes the data accessible at the specified file path. When you specify `volumes` and `volumeMounts` in the Mule application CR: 1. The controller includes these specifications in the Deployment resource. 2. Kubernetes mounts the volumes into the Mule application container at the specified paths. 3. Your Mule application can access the files at runtime. > [!NOTE] Volumes specified in the Mule application CR are mounted to the main Mule application > container, not to sidecar containers. Example: Mount Secrets from Kubernetes Secrets Use Kubernetes native Secrets to store secret data on the Kubernetes cluster and mount them into your Mule application. 1. Create a Secret in your Kubernetes cluster: ```bash kubectl create secret generic my-database-secret \ --from-literal=db.username=admin \ --from-literal=db.password=secret123 \ -n my-apps ``` 2. Mount it in your Mule application CR: ```yaml spec: volumes: - name: database-secret secret: secretName: my-database-secret volumeMounts: - name: database-secret mountPath: /mnt/secrets readOnly: true ``` The secret files are now accessible at: - `/mnt/secrets/db.username` - `/mnt/secrets/db.password` Example: Mount a TLS Keystore from a Secret 1. Create a Secret containing your keystore: ```bash kubectl create secret generic java-keystore \ --from-file=keystore.jks=./path/to/keystore.jks \ --from-literal=keystore.password=changeit \ -n my-apps ``` 2. Mount it in your Mule application CR: ```yaml spec: volumes: - name: tls-keystore secret: secretName: java-keystore volumeMounts: - name: tls-keystore mountPath: /var/tls readOnly: true jvmArgs: - "-Djavax.net.ssl.keyStore=/var/tls/keystore.jks" - "-Djavax.net.ssl.keyStorePassword=changeit" ``` Your application can now access: - `/var/tls/keystore.jks` - `/var/tls/keystore.password` Example: Mount Configuration Files from a ConfigMap 1. Create a ConfigMap with configuration files: ```bash kubectl create configmap app-configs \ --from-file=log4j2.xml \ --from-file=truststore.jks \ -n my-apps ``` 2. Mount the files in your Mule application CR: ```yaml spec: volumes: - name: app-configs configMap: name: app-configs volumeMounts: - name: app-configs mountPath: /opt/mule/conf readOnly: true ``` Example: Use External Secret Manager (AWS Secrets Manager) To integrate with AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault, use the Secrets Store CSI Driver. > [!NOTE] You must install the Secrets Store CSI Driver in your cluster. Refer to your Secrets > Manager’s documentation for installation instructions. 1. Create a SecretProviderClass: ```yaml apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: aws-database-secrets namespace: my-apps spec: provider: aws parameters: objects: | - objectName: "production/database/credentials" objectType: "secretsmanager" jmesPath: - path: username objectAlias: db_username - path: password objectAlias: db_password ``` 2. Reference in Mule application CR: ```yaml spec: volumes: - name: aws-secrets csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: aws-database-secrets volumeMounts: - name: aws-secrets mountPath: /mnt/secrets/aws readOnly: true ``` 3. Access Secrets: The secrets are available at: - `/mnt/secrets/aws/db_username` - `/mnt/secrets/aws/db_password` 4. Reference them in your Mule configuration: ```xml ``` Example: Use Azure Key Vault To integrate with Azure Key Vault, configure a SecretProviderClass and reference it in your Mule application CR. ```yaml apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: azure-key-vault-secrets namespace: my-apps spec: provider: azure parameters: usePodIdentity: "false" useVMManagedIdentity: "true" userAssignedIdentityID: "" keyvaultName: "my-keyvault" objects: | array: - | objectName: database-password objectType: secret objectVersion: "" tenantId: "" --- apiVersion: rtf.mulesoft.com/v1 kind: MuleApplication metadata: name: my-app spec: # ... other fields ... volumes: - name: azure-secrets csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: azure-key-vault-secrets volumeMounts: - name: azure-secrets mountPath: /mnt/secrets/azure readOnly: true ``` Example: Mount a Persistent Volume To mount a persistent volume for storing data that must survive pod restarts, use a PersistentVolumeClaim. ```yaml spec: volumes: - name: app-data persistentVolumeClaim: claimName: mule-app-pvc volumeMounts: - name: app-data mountPath: /mnt/data ``` Your application can read and write files to `/mnt/data`, and the data persists across pod restarts. Example: Mount an Empty Directory (Temporary Storage) To provide temporary storage that is created when a pod starts and deleted when it stops, use an emptyDir volume. ```yaml spec: volumes: - name: temp-storage emptyDir: sizeLimit: 1Gi volumeMounts: - name: temp-storage mountPath: /tmp/processing ``` ### Create a Connected App Anypoint Controller requires a Connected App to authenticate with Anypoint Platform APIs. The Connected App acts on its own behalf using client credentials. 1. Log in to Anypoint Platform. 2. Navigate to **Access Management** > **Connected Apps**. 3. Click **Create app**. 4. Select **App acts on its own behalf (client credentials)**. 5. Enter a name for your Connected App, such as `anypoint-controller`. 6. Under **Scopes**, grant these permissions:
CategoryPermissionDescription

Exchange

Exchange Viewer

View and download application artifacts from Exchange

OpenID

Profile

Access basic profile information

Runtime Manager

Create Applications

Create new application deployments

Runtime Manager

Delete Applications

Delete existing application deployments

Runtime Manager

Read Runtime Fabrics

View Runtime Fabric target information

7. Click **Save**. 8. Copy the **Client ID** and **Client Secret**. You need these values in the next step. ### Configure Anypoint Credentials Create a Kubernetes Secret `anypoint-credentials` containing the Connected App credentials in the namespace where Runtime Fabric is installed. ```bash kubectl create secret generic anypoint-credentials \ --from-literal=ANYPOINT_CLIENT_ID= \ --from-literal=ANYPOINT_CLIENT_SECRET= \ -n ``` Replace these: - ``: The Client ID from your Connected App - ``: The Client Secret from your Connected App - ``: The namespace where Runtime Fabric is installed (for example, `rtf`) Anypoint Controller monitors this secret and automatically reloads credentials when updated, enabling credential rotation without controller restarts. #### Rotate Credentials To rotate Connected App credentials: 1. Create a new Connected App in Anypoint Platform. 2. Update the secret: ```bash kubectl create secret generic anypoint-credentials \ --from-literal=ANYPOINT_CLIENT_ID= \ --from-literal=ANYPOINT_CLIENT_SECRET= \ -n \ --dry-run=client -o yaml | kubectl apply -f - ``` 3. The controller automatically detects the change and reloads credentials. ## Deploy Mule Applications After installing and configuring Anypoint Controller, you can deploy Mule applications by creating Mule application CRs. The controller automatically synchronizes these resources with Anypoint Platform and deploys them to your Runtime Fabric cluster. For detailed information about CRD fields and Kubernetes permissions, see: - [Understanding Custom Resource Definitions](#understanding-custom-resource-definitions) - [Understanding Runtime Fabric Agent Kubernetes Permissions](#understanding-runtime-fabric-agent-kubernetes-permissions). ### Create Your First Application Follow these steps to deploy a Mule application using Anypoint Controller. #### Prerequisites - Anypoint Controller installed and configured - Connected App credentials configured - Mule application artifact published to Anypoint Exchange - Target Runtime Fabric name from Runtime Manager - Business group and environment names Complete these steps to create your first application: 1. [Create the Application Manifest](#create-the-application-manifest) 2. [Apply the Manifest](#apply-the-manifest) 3. [Verify the Deployment](#verify-the-deployment) #### Create the Application Manifest Create a file named `hello-world-app.yaml`: ```yaml apiVersion: rtf.mulesoft.com/v1 kind: MuleApplication metadata: name: hello-world-app namespace: my-apps spec: # Required: Anypoint Platform Configuration (Immutable) target: my-rtf-target businessGroup: MyOrg/Engineering environment: Production # Required: Runtime Configuration runtimeVersion: "4.8.0:2e-java8" # Required: Application Artifact application: group: my-org artifactId: hello-world version: "1.0.0" packaging: jar # Deployment Configuration replicas: 2 resources: requests: cpu: 500m memory: 1Gi limits: cpu: 1000m memory: 2Gi ``` This example shows the minimum required fields. For a complete list of all available configuration fields, see [Understanding Custom Resource Definitions](#understanding-custom-resource-definitions). #### Apply the Manifest 1. Create the namespace and label it with the Runtime Fabric namespace: ```bash kubectl create namespace my-apps kubectl label namespace my-apps rtf.mulesoft.com/agentNamespace= ``` Replace `` with the namespace where your Runtime Fabric is installed (for example, `rtf`). > [!IMPORTANT] The `rtf.mulesoft.com/agentNamespace` label tells the Runtime Fabric agent which > Mule application CRs to manage. Only one Runtime Fabric instance can manage applications in a > given namespace. 2. Apply the application manifest: ```bash kubectl apply -f hello-world-app.yaml ``` 3. Verify the Custom Resource was created: ```bash kubectl get muleapplication hello-world-app -n my-apps ``` When you apply the Mule application CR, Anypoint Controller perform these actions: 1. Detects the new MuleApplication resource. 2. Validates the configuration. 3. Adds a label to the namespace for synchronization tracking (`rtf.mulesoft.com/role: workers`). 4. Creates the application in Anypoint Platform. 5. Deploys the application to the specified Runtime Fabric target. 6. Continuously monitors and reconciles the desired state. #### Verify the Deployment 1. Check the application status: ```bash kubectl get muleapplication hello-world-app -n my-apps ``` Example output: ```console NAME APPLICATION FILE DESIRED READY ANYPOINT ID ANYPOINT VERSION hello-world-app hello-world 2 2 abc123def v456 ``` 2. View detailed status: ```bash kubectl describe muleapplication hello-world-app -n my-apps ``` 3. Check the application in Runtime Manager: Log in to Anypoint Platform and navigate to Runtime Manager. Your application appears in the applications list in read-only mode, with all management actions (buttons) grayed out. ### Deployment Examples Explore different deployment patterns and configurations for common use cases. Deploy with Properties To deploy an application with configuration properties, use the `properties` field: ```yaml apiVersion: rtf.mulesoft.com/v1 kind: MuleApplication metadata: name: api-gateway namespace: my-apps spec: target: production-rtf businessGroup: MyOrg environment: Production runtimeVersion: "4.8.0:2e-java8" application: group: my-org artifactId: api-gateway version: "2.1.0" packaging: jar replicas: 3 # Application properties properties: - name: http.port value: "8081" - name: api.base.url value: "https://api.example.com" - name: api.key value: "prod-key-12345" secure: true # Encrypt this property - name: max.connections value: "100" resources: requests: cpu: 1000m memory: 2Gi limits: cpu: 2000m memory: 4Gi ``` Apply the manifest: ```bash kubectl apply -f api-gateway.yaml ``` Deploy with External Properties To reference properties from Kubernetes Secrets or ConfigMaps, use the `propertiesFrom` field: 1. Create a Secret with credentials: ```bash kubectl create secret generic database-credentials \ --from-literal=db.username=admin \ --from-literal=db.password=secretPass123 \ --from-literal=db.host=database.example.com \ -n my-apps ``` 2. Create a ConfigMap with configuration: ```bash kubectl create configmap app-config \ --from-literal=api.timeout=30000 \ --from-literal=api.retry.count=3 \ -n my-apps ``` 3. Reference them in your application: ```yaml apiVersion: rtf.mulesoft.com/v1 kind: MuleApplication metadata: name: order-service namespace: my-apps spec: target: production-rtf businessGroup: MyOrg environment: Production runtimeVersion: "4.8.0:2e-java8" application: group: my-org artifactId: order-service version: "1.5.0" packaging: jar replicas: 2 # Mount properties from external sources propertiesFrom: - secretRef: name: database-credentials - configMapRef: name: app-config resources: requests: cpu: 500m memory: 1Gi limits: cpu: 1000m memory: 2Gi ``` 4. Apply the manifest: ```bash kubectl apply -f order-service.yaml ``` Deploy with Autoscaling To enable horizontal pod autoscaling based on CPU utilization: ```yaml apiVersion: rtf.mulesoft.com/v1 kind: MuleApplication metadata: name: high-traffic-api namespace: my-apps spec: target: production-rtf businessGroup: MyOrg environment: Production runtimeVersion: "4.8.0:2e-java8" application: group: my-org artifactId: high-traffic-api version: "3.0.0" packaging: jar # Configure autoscaling autoscaling: enabled: true minReplicas: 2 maxReplicas: 10 resources: requests: cpu: 500m memory: 1Gi limits: cpu: 1000m memory: 2Gi ``` The controller creates a HorizontalPodAutoscaler resource that automatically adjusts the replica count based on CPU utilization. Deploy a Clustered Application To deploy a clustered application with persistent object store: ```yaml apiVersion: rtf.mulesoft.com/v1 kind: MuleApplication metadata: name: workflow-engine namespace: my-apps spec: target: production-rtf businessGroup: MyOrg environment: Production runtimeVersion: "4.8.0:2e-java8" application: group: my-org artifactId: workflow-engine version: "2.0.0" packaging: jar replicas: 3 # Enable clustering and persistence clustered: true persistentObjectStore: true enforceDeployingReplicasAcrossNodes: true resources: requests: cpu: 1000m memory: 2Gi limits: cpu: 2000m memory: 4Gi ``` Common Deployment Scenarios Customize your Mule application deployments for specific use cases. **Deploy to a Specific Namespace** You can deploy applications to any Kubernetes namespace. Create the namespace and label it with the Runtime Fabric namespace: ```bash kubectl create namespace production-apps kubectl label namespace production-apps rtf.mulesoft.com/agentNamespace= kubectl apply -f my-app.yaml -n production-apps ``` The controller watches namespaces that are labeled with `rtf.mulesoft.com/agentNamespace: `, where `` is the namespace where the Runtime Fabric core software is installed. The agent running in that namespace manages Mule application CRs in the labeled application namespace. For more information about namespace permissions and flexibility, see [Understanding Runtime Fabric Agent Kubernetes Permissions](#understanding-runtime-fabric-agent-kubernetes-permissions). **Deploy with Custom Logging** Configure package-level logging for troubleshooting: ```yaml spec: scopeLoggingConfigurations: - scope: com.mulesoft logLevel: DEBUG - scope: org.mule.extension.http logLevel: INFO - scope: root logLevel: INFO ``` **Deploy with JVM Arguments** Specify custom JVM arguments for memory tuning or SSL configuration: ```yaml spec: jvmArgs: - "-Xmx2048m" - "-Xms1024m" - "-Djavax.net.ssl.keyStore=/var/tls/keystore.jks" ``` **Deploy with Node Affinity** Control which nodes run your application: ```yaml spec: pod: nodeSelector: environment: production disktype: ssd tolerations: - key: "dedicated" operator: "Equal" value: "mule-apps" effect: "NoSchedule" ``` For more Kubernetes customization options including affinity rules, topology spread constraints, and security context, see [Understanding Custom Resource Definitions](#understanding-custom-resource-definitions). ## Monitor Mule Applications Anypoint Controller reports application state through standard Kubernetes status conditions. These conditions provide real-time feedback on the application’s deployment and operational status. ### View Application Status Check the status of a Mule application: ```bash kubectl get muleapplication hello-world-app -n my-apps ``` Output: ```console NAME APPLICATION FILE DESIRED READY ANYPOINT ID ANYPOINT VERSION hello-world-app hello-world 2 2 abc123def v456 ``` View detailed status: ```bash kubectl get muleapplication hello-world-app -n my-apps -o yaml ``` Or use `describe`: ```bash kubectl describe muleapplication hello-world-app -n my-apps ``` ### Status Conditions The controller reports these status conditions. To report these conditions as ArgoCD resource health, see [Configure MuleApplication Health in ArgoCD](#configure-muleapplication-health-in-argocd). Status Condition: Applied The `Applied` condition indicates whether the desired configuration was successfully synchronized with Anypoint Platform. **Status: True (Success)** ```yaml status: conditions: - type: Applied status: "True" reason: APISuccessResponse lastTransitionTime: "2024-01-15T10:30:00Z" ``` The controller successfully created or updated the application in Anypoint Platform. The application configuration matches the desired state defined in the CR. **Status: False (Failure)** ```yaml status: conditions: - type: Applied status: "False" reason: APIErrorResponse message: "409 Conflict - Application name 'hello-world-app' already exists" lastTransitionTime: "2024-01-15T10:30:00Z" ``` The controller could not apply the configuration to Anypoint Platform. The `message` field contains the error details. Common Failure Reasons: - Application name already exists (either not created via Anypoint Controller, or created via Anypoint Controller with the same name) - Invalid Runtime Fabric target name - Invalid business group or environment name - Insufficient vCore entitlement - Invalid runtime version - Exchange artifact not found - Connected App lacks required permissions - Network connectivity issues to Anypoint Platform Status Condition: Available The `Available` condition indicates whether the application has at least one available replica and serving traffic. **Status: True (Available)** ```yaml status: readyReplicas: 2 conditions: - type: Available status: "True" reason: HaveReadyReplicas message: "Application is ready to serve traffic" lastTransitionTime: "2024-01-15T10:32:00Z" ``` Has at least one available replica and is serving traffic. **Status: False (Not Available)** ```yaml status: readyReplicas: 0 conditions: - type: Available status: "False" reason: HaveReadyReplicas message: "Application is not ready to serve traffic" lastTransitionTime: "2024-01-15T10:32:00Z" ``` The application doesn’t have ready replicas. Check pod status and logs to diagnose the issue. Status Condition: Progressing The `Progressing` condition indicates whether a deployment rollout is currently underway. This tracks the process of updating pods to match the desired specification. **Status: True (Rolling Out)** ```yaml status: conditions: - type: Progressing status: "True" reason: RollingOut message: "Rolling out: 1/2 replicas updated" lastTransitionTime: "2024-01-15T10:35:00Z" ``` A rollout is in progress. This status is `True` when: - New replicas are being created - Old replicas are being terminated - Replicas are waiting to become ready **Status: False (Idle)** ```yaml status: conditions: - type: Progressing status: "False" reason: RolloutComplete message: "All replicas updated and ready" lastTransitionTime: "2024-01-15T10:36:00Z" ``` The deployment has finished. All replicas are updated to the latest version and are ready. Status Condition: Degraded The `Degraded` condition indicates whether the application pods are failing to start or stabilize. This is critical for identifying issues like `CrashLoopBackOff`, `ImagePullBackOff`, or readiness probe failures. **Status: True (Failing)** ```yaml status: conditions: - type: Degraded status: "True" reason: PodFailure message: "Pod hello-world-app-86dcf987-xyz: CrashLoopBackOff: Back-off restarting failed container" lastTransitionTime: "2024-01-15T10:40:00Z" ``` The application is in a degraded state. One or more pods in the newest ReplicaSet are failing. If a new version is failing but the old version is still serving traffic, the message will indicate this: New version rollout blocked: Pod : . Service remains available on previous version. **Status: Missing (Healthy)** If the `Degraded` condition is not present in the status list, the application is healthy (or at least not reporting specific pod failures). Status Condition: DesiredSpecAppliedOnCluster The `DesiredSpecAppliedOnCluster` condition indicates whether the currently deployed application version in the cluster matches the desired specification version in Anypoint Platform. **Status: True (Synchronized)** ```yaml status: anypointVersion: v789 conditions: - type: DesiredSpecAppliedOnCluster status: "True" reason: DesiredSpecAppliedOnCluster lastTransitionTime: "2024-01-15T10:33:00Z" ``` The running application version matches the desired version. Deployment is complete and synchronized. **Status: False (Out of Sync)** ```yaml status: conditions: - type: DesiredSpecAppliedOnCluster status: "False" reason: DesiredSpecAppliedOnCluster lastTransitionTime: "2024-01-15T10:33:00Z" ``` The cluster is still deploying the updated version, or the deployment is in progress. Additional Status Fields The MuleApplication status includes additional fields that provide operational information about the application. **Anypoint Platform Identifiers** Use `anypointUri` to quickly navigate to the application in Runtime Manager. ```yaml status: anypointId: abc123def456 # Application ID in Anypoint Platform anypointUri: https://anypoint.mulesoft.com/... # Direct link to app anypointVersion: v789 # Deployed spec version targetId: target-123 # Runtime Fabric target ID businessGroupId: bg-456 # Business group ID environmentId: env-789 # Environment ID ``` **Replica Status** The number of replicas that are running and ready to serve traffic. ```yaml status: readyReplicas: 2 ``` **Retry Information** Indicates whether a failed operation is retrievable. ```yaml status: retryable: true ``` **Reconciliation Metadata** Used internally by the controller for change detection and reconciliation. ```yaml status: lastPublishedHash: "a1b2c3d4..." # Hash of last published spec lastPublishedAt: "2024-01-15T10:30:00Z" # Last publish timestamp ``` ## Manage Mule Applications Anypoint Controller enables you to manage the complete lifecycle of your Mule applications using standard Kubernetes commands and GitOps workflows. ### Reconciliation Behavior Anypoint Controller continuously reconciles the desired state: - Synchronizes the application state every 30 seconds. - Compares the CR spec hash with the last published hash to detect changes. - When changes are detected, updates Anypoint Platform automatically. - Retries failed operations with exponential backoff. - Refreshes the state every 10 minutes, even when no changes occur. Manage your application lifecycle: - [Update a Mule Application](#update-a-mule-application) - [Delete a Mule Application](#delete-a-mule-application) ### Update a Mule Application 1. Modify your Mule application YAML file: ```yaml spec: replicas: 5 # Changed from 2 to 5 ``` 2. Apply the change: ```bash kubectl apply -f hello-world-app.yaml ``` 3. Monitor the update: ```bash kubectl get muleapplication hello-world-app -n my-apps -w ``` The controller detects the change and initiates the update automatically. > [!NOTE] Some fields like `target`, `businessGroup`, and `environment` are immutable and can’t be > changed after creation. For a complete list of mutable and immutable fields, see > [Understanding Custom Resource Definitions](#understanding-custom-resource-definitions). ### Delete a MuleApplication To delete an application managed by Anypoint Controller, delete the Mule application CR: ```bash kubectl delete muleapplication -n ``` Example: ```bash kubectl delete muleapplication hello-world-app -n my-apps ``` The controller automatically: 1. Deletes the application from Anypoint Platform. 2. Removes all Kubernetes resources (Deployment, Service, ConfigMaps, and Secrets). 3. Removes the finalizer from the CR. 4. Allows Kubernetes to delete the CR. > [!IMPORTANT] Deletion is permanent. Make sure your version control repository contains the > application configuration in case you need to redeploy it later. ## Integrate with CI/CD and GitOps Tools Anypoint Controller works seamlessly with GitOps and Infrastructure-as-Code tools. ### GitOps Workflow 1. Store MuleApplication manifests in a version control repository. 2. Define branch strategies (for example, `dev`, `staging`, `production`). 3. Use pull requests or merge requests for configuration changes. 4. Automate deployment with GitOps tools. Integrate Anypoint Controller with these tools: - [ArgoCD Integration](#argocd-integration) - [Configure MuleApplication Health in ArgoCD](#configure-muleapplication-health-in-argocd) - [FluxCD Integration](#fluxcd-integration) - [Terraform Integration](#terraform-integration) ### ArgoCD Integration 1. Store your manifests in version control: ```console my-mule-apps/ ├── production/ │ ├── hello-world-app.yaml │ └── order-processing-app.yaml └── staging/ ├── hello-world-app.yaml └── order-processing-app.yaml ``` 2. Create an ArgoCD Application: ```yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: mule-apps-production namespace: argocd spec: project: default source: repoURL: https://github.com/myorg/mule-deployments targetRevision: main path: production destination: server: https://kubernetes.default.svc namespace: mule-apps syncPolicy: automated: prune: true # Delete resources removed from version control selfHeal: true # Revert manual changes syncOptions: - CreateNamespace=true ``` ArgoCD continuously monitors the version control repository and automatically deploys changes. ### Configure MuleApplication Health in ArgoCD ArgoCD sync status and resource health are independent. A `MuleApplication` can be `Synced` when its Kubernetes resource matches the manifest in Git, even when Anypoint Controller can’t apply the requested configuration or the application rollout fails. ArgoCD doesn’t interpret `MuleApplication.status.conditions` automatically. To report Anypoint Controller results as ArgoCD resource health, add this custom health check to the ArgoCD instance that manages your `MuleApplication` resources. Follow the [ArgoCD custom health check documentation](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/) and use the configuration method for your ArgoCD installation. Use this resource-customization key: ```console resource.customizations.health.rtf.mulesoft.com_MuleApplication ``` This key follows the ArgoCD naming convention `resource.customizations.health._`. The API version isn’t included, and the `MuleApplication` kind is case-sensitive. Add this configuration: ```yaml data: resource.customizations.health.rtf.mulesoft.com_MuleApplication: | local hs = {} if obj.metadata ~= nil and obj.metadata.deletionTimestamp ~= nil then hs.status = "Progressing" hs.message = "Deletion is waiting for Anypoint Controller cleanup" return hs end if obj.status == nil or obj.status.conditions == nil then hs.status = "Progressing" hs.message = "Waiting for Anypoint Controller to report status" return hs end local applied = nil local available = nil local progressing = nil local degraded = nil local desiredSpecApplied = nil for _, condition in ipairs(obj.status.conditions) do if condition.type == "Applied" then applied = condition elseif condition.type == "Available" then available = condition elseif condition.type == "Progressing" then progressing = condition elseif condition.type == "Degraded" then degraded = condition elseif condition.type == "DesiredSpecAppliedOnCluster" then desiredSpecApplied = condition end end -- A desired configuration that failed to apply is terminally unhealthy -- even if an older version still has ready replicas. if applied ~= nil and applied.status == "False" then hs.status = "Degraded" hs.message = applied.message or applied.reason or "Desired configuration was not applied" return hs end if degraded ~= nil and degraded.status == "True" then hs.status = "Degraded" hs.message = degraded.message or degraded.reason or "MuleApplication workload is degraded" return hs end -- The controller can report a terminal Deployment timeout without adding -- Degraded=True when it cannot derive a pod-level failure. if progressing ~= nil and progressing.status == "False" and progressing.reason == "ProgressDeadlineExceeded" then hs.status = "Degraded" hs.message = progressing.message or "MuleApplication deployment exceeded its progress deadline" return hs end if progressing ~= nil and progressing.status == "True" then hs.status = "Progressing" hs.message = progressing.message or progressing.reason or "MuleApplication rollout is progressing" return hs end if desiredSpecApplied ~= nil and desiredSpecApplied.status == "False" then hs.status = "Progressing" hs.message = desiredSpecApplied.message or desiredSpecApplied.reason or "Waiting for the desired specification to reach the cluster" return hs end if applied ~= nil and applied.status == "True" and available ~= nil and available.status == "True" then hs.status = "Healthy" hs.message = available.message or applied.message or "MuleApplication is applied and available" return hs end hs.status = "Progressing" if progressing ~= nil and progressing.message ~= nil then hs.message = progressing.message elseif progressing ~= nil and progressing.reason ~= nil then hs.message = progressing.reason elseif applied ~= nil and applied.message ~= nil then hs.message = applied.message elseif available ~= nil and available.message ~= nil then hs.message = available.message else hs.message = "Waiting for the current MuleApplication generation to become applied and available" end return hs ``` This custom health check maps these `MuleApplication` conditions:
MuleApplication StateArgoCD HealthDescription

The resource has a deletion timestamp

Progressing

Anypoint Controller cleanup is in progress.

Status or conditions aren’t present

Progressing

Anypoint Controller hasn’t reported status.

Applied=False

Degraded

Anypoint Controller couldn’t apply the requested configuration. ArgoCD displays the controller message when available.

Degraded=True

Degraded

Anypoint Controller found a workload failure, such as a pod startup failure.

Progressing=False with reason ProgressDeadlineExceeded

Degraded

The Kubernetes Deployment exceeded its progress deadline. This condition can occur without Degraded=True. For example, an admission failure can prevent creation of a pod that Anypoint Controller can inspect.

Progressing=True

Progressing

A rollout is active.

DesiredSpecAppliedOnCluster=False

Progressing

The desired application version hasn’t reached the cluster.

Applied=True and Available=True

Healthy

The configuration was accepted and at least one replica is available.

Any unknown or incomplete combination

Progressing

This health check uses a conservative fallback and displays the controller message or reason when available.

> [!NOTE] This customization changes only how ArgoCD interprets resource health. It doesn’t change > ArgoCD sync status, modify the `MuleApplication`, or resolve the underlying deployment failure. An > application whose manifest was applied successfully can be `Synced` and `Degraded` at the same > time. `Applied=True` together with `Available=False` isn’t sufficient to classify an application as failed. This combination occurs while an application is starting. `Progressing=False` isn’t always a failure. Anypoint Controller also sets it with reasons such as `RolloutComplete`, `NoReplicas`, and `DeploymentNotFound`. This custom health check maps only the terminal `ProgressDeadlineExceeded` reason to `Degraded`. This customization applies to every ArgoCD-managed `MuleApplication` in that ArgoCD instance. If this resource-customization key is already configured, don’t replace it until you review the existing script. ArgoCD uses one health script for each API group and kind. This script doesn’t require `resource.customizations.useOpenLibs`. ### FluxCD Integration 1. Create a GitRepository resource: ```yaml apiVersion: source.toolkit.fluxcd.io/v1 kind: GitRepository metadata: name: mule-apps namespace: flux-system spec: interval: 1m url: https://github.com/myorg/mule-deployments ref: branch: main ``` 2. Create a Kustomization resource: ```yaml apiVersion: kustomize.toolkit.fluxcd.io/v1 kind: Kustomization metadata: name: mule-apps-production namespace: flux-system spec: interval: 10m sourceRef: kind: GitRepository name: mule-apps path: ./production prune: true targetNamespace: mule-apps ``` FluxCD automatically reconciles the cluster state with the version control. ### Terraform Integration Use Terraform to manage MuleApplication resources as infrastructure as code. 1. Create a Terraform configuration file: ```hcl resource "kubernetes_manifest" "hello_world_app" { manifest = { apiVersion = "rtf.mulesoft.com/v1" kind = "MuleApplication" metadata = { name = "hello-world-app" namespace = "mule-apps" } spec = { target = "production-rtf" businessGroup = "MyOrg/Engineering" environment = "Production" runtimeVersion = "4.8.0:2e-java8" application = { group = "my-org" artifactId = "hello-world" version = var.app_version packaging = "jar" } replicas = var.replica_count resources = { requests = { cpu = "500m" memory = "1Gi" } limits = { cpu = "1000m" memory = "2Gi" } } } } } ``` 2. Apply the Terraform configuration: ```bash terraform init terraform plan terraform apply ``` Terraform manages the MuleApplication lifecycle and tracks state changes in your infrastructure. ## Understanding Runtime Fabric Agent Kubernetes Permissions The Runtime Fabric agent requires specific Kubernetes permissions to manage Mule application CRs: - Namespace Label Requirement To enable the Runtime Fabric agent to manage Mule application CRs in a namespace, you must label the namespace with `rtf.mulesoft.com/agentNamespace=`. Only one Runtime Fabric instance can manage applications in a given namespace. - Namespace Flexibility You can create Mule application CRs in any Kubernetes namespace, as long as the namespace is labeled with `rtf.mulesoft.com/agentNamespace: `. A controller running in a given Runtime Fabric agent pod only watches for Mule application CRs in namespaces that have this matching label. - Resource Creation The controller creates application resources (Deployments, Services, ConfigMaps, Secrets) in the same namespace as the Mule application CR. - Label Management The controller adds labels to resources for tracking, ownership, and reconciliation purposes. ## Understanding Custom Resource Definitions The MuleApplication Custom Resource Definition (CRD) defines the schema for Mule application deployments. When you enable Anypoint Controller, Helm installs this CRD in your cluster. ### View the CRD This command verifies that the Mule application CRD is installed in your cluster. ```bash kubectl get crd muleapplications.rtf.mulesoft.com ``` ### Describe the CRD Schema This command shows all available fields and their descriptions. ```bash kubectl explain muleapplication.spec ``` ### Basic MuleApplication Example Create a file named `hello-world-app.yaml`: ```yaml apiVersion: rtf.mulesoft.com/v1 kind: MuleApplication metadata: name: hello-world-app namespace: my-apps spec: # Required: Anypoint Platform Configuration (Immutable) target: my-rtf-target businessGroup: MyOrg/Engineering environment: Production # Required: Runtime Configuration runtimeVersion: "4.8.0:2e-java8" # Required: Application Artifact application: group: my-org artifactId: hello-world version: "1.0.0" packaging: jar # Deployment Configuration replicas: 2 resources: requests: cpu: 500m memory: 1Gi limits: cpu: 1000m memory: 2Gi ``` Apply the Custom Resource: ```bash kubectl apply -f hello-world-app.yaml ``` Anypoint Controller detects the new resource and: 1. Creates the application in Anypoint Platform. 2. Deploys the application to the specified Runtime Fabric target. 3. Continuously monitors and reconciles the desired state. ### MuleApplication Field Reference For a comprehensive reference of all Mule application deployment fields and configuration options, see [Mule Application Deployment Fields](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric#rtf-deploy-reference). ### Advanced Field Configurations Required Fields (Immutable After Creation) These fields are required and can’t be changed after the application is created: - `target` (string): The name of the Runtime Fabric target as shown in Runtime Manager. ```yaml spec: target: production-rtf ``` - `businessGroup` (string): The hierarchical path of the Anypoint business group. Use forward slashes to separate parent and child groups. ```yaml spec: businessGroup: Acme/Finance/MyGroup ``` If your business group is the root organization, use only the organization name: ```yaml spec: businessGroup: Acme ``` - `environment` (string): The name of the Anypoint environment (not the environment ID). ```yaml spec: environment: Production ``` Required: Runtime Version The `runtimeVersion` (string) specifies the Mule runtime version to use. Must be version 4.6 or above. ```yaml spec: runtimeVersion: "4.8.0:2e-java8" ``` Required: Application Artifact The `application` field specifies the artifact to deploy from Anypoint Exchange, using Maven coordinate conventions: ```yaml spec: application: group: my-business-group # Business group that owns the artifact artifactId: order-processing # Artifact name version: "1.0.5" # Artifact version packaging: jar # Artifact format (typically "jar") ``` Deployment Configuration **Replicas** The `replicas` field specifies the number of application instances: ```yaml spec: replicas: 3 ``` - Default: `1` - Maximum: `16` replicas per application **Resource Allocation** The `resources` field defines CPU and memory resources per replica: ```yaml spec: resources: requests: cpu: 500m # Minimum CPU (millicores) memory: 1Gi # Minimum memory limits: cpu: 2000m # Maximum CPU memory: 2Gi # Maximum memory ``` **Update Strategy** The `updateStrategy` field controls how updates are rolled out: ```yaml spec: updateStrategy: rolling # or "recreate" ``` - `rolling` (default): Updates replicas incrementally, maintaining availability - `recreate`: Terminates all replicas before creating new ones **Horizontal Pod Autoscaling** The `autoscaling` field configures CPU-based autoscaling: ```yaml spec: autoscaling: enabled: true minReplicas: 2 maxReplicas: 10 ``` When autoscaling is enabled, the controller creates a HorizontalPodAutoscaler resource that automatically adjusts replica count based on CPU utilization. **Clustering and Persistence** Configure Mule clustering for high availability and enable persistent object store for stateful applications. ```yaml spec: clustered: true # Enable Mule clustering persistentObjectStore: true # Enable persistent object store ``` **Replica Distribution** When enabled, Kubernetes ensures replicas are distributed across different nodes for high availability. ```yaml spec: enforceDeployingReplicasAcrossNodes: true ``` Application Properties Define properties directly in the Custom Resource: ```yaml spec: properties: - name: http.port value: "8081" - name: api.key value: "my-api-key-123" secure: true # Encrypt this property - name: max.connections value: "100" ``` Set `secure: true` for sensitive values that should be encrypted in Anypoint Platform. JVM Configuration Specify custom JVM arguments: ```yaml spec: jvmArgs: - "-Xmx2048m" - "-Xms1024m" - "-Djavax.net.ssl.keyStore=/var/tls/keystore.jks" - "-Djavax.net.ssl.keyStorePassword=changeit" ``` Logging Configuration Configure package-level logging: ```yaml spec: scopeLoggingConfigurations: - scope: com.mulesoft logLevel: DEBUG - scope: org.mule.extension.http logLevel: INFO - scope: org.springframework logLevel: WARN - scope: root logLevel: INFO ``` Valid log levels: `DEBUG`, `INFO`, `WARN`, `ERROR`, `FATAL` Monitoring and Tracing Control Anypoint Monitoring log forwarding and enable OpenTelemetry tracing for application observability. ```yaml spec: disableAmLogForwarding: false # Keep Anypoint Monitoring log forwarding enabled tracingEnabled: true # Enable OpenTelemetry tracing (requires Mule 4.6+) ``` Kubernetes Customization Customize pod, service, and deployment metadata: ```yaml spec: pod: metadata: labels: team: engineering cost-center: "12345" app-version: "1.0.0" annotations: prometheus.io/scrape: "true" prometheus.io/port: "8081" # Node placement nodeSelector: environment: production disktype: ssd # Tolerations for tainted nodes tolerations: - key: "dedicated" operator: "Equal" value: "mule-apps" effect: "NoSchedule" # Affinity rules affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/arch operator: In values: - amd64 podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app: hello-world-app topologyKey: kubernetes.io/hostname # Topology spread constraints topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: hello-world-app # Security context containerSecurityContext: seccompProfile: type: RuntimeDefault runAsNonRoot: true # Service account automountServiceAccountToken: true # Environment variables (only specific keys are supported) env: ENABLE_CONSOLE_LOG: "true" ENABLE_READINESS_PROBE_ON_HTTP_GET: "true" # Ephemeral storage ephemeralStorageLimit: 4Gi service: metadata: labels: monitoring: enabled annotations: service.beta.kubernetes.io/aws-load-balancer-type: "nlb" deployment: metadata: labels: deployment-version: "v1" annotations: fluxcd.io/automated: "true" ``` > [!IMPORTANT] The `pod.env` field uses `map[string]string` format (for example, > `ENABLE_CONSOLE_LOG: "true"`), not a list of `name`/`value` pairs. As with the > [KubernetesTemplate](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd) CR, it supports only the keys listed in this list. > Any other key (for example, `MY_CUSTOM_VAR`) is ignored. > > - `ENABLE_CONSOLE_LOG`: Enables console logging for the application container. Emitted as a > container environment variable. For more information, see > [Enable Console Logging](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd#enable-console-logging). > > - `ENABLE_READINESS_PROBE_ON_HTTP_GET`: Enables the native Kubernetes HTTP GET probe for > readiness. Requires Mule runtime engine patches from November 7, 2025 or later; older patches > might fail to become ready. Emitted as a container environment variable. For more information, > see [Enable Readiness Probe on HTTP GET](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd#enable-readiness-probe). > > - `DISABLE_PER_APP_SA`: Disables the per-application service account, so the Mule application uses > the default namespace service account. Controls deployment-level behavior. For more information, > see [Disable Per Application Service Account](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd#disable-service-account). > > To pass custom configuration values to your Mule application, use the `properties` or > `propertiesFrom` fields instead. For more information, see > [Mounting Properties from External Sources](#mounting-properties-from-external-sources). ### Mounting Properties from External Sources The `propertiesFrom` field in the Mule application CR `spec` enables you to inject application properties from Kubernetes Secrets and ConfigMaps without hardcoding them in the Custom Resource. ```yaml spec: propertiesFrom: - secretRef: name: my-secret - configMapRef: name: my-config ``` When you reference a Secret or ConfigMap in `propertiesFrom`, the controller: 1. Creates `volume` and `volumeMount` configurations automatically. 2. Mounts the files to `/etc/mule/properties/` in the Mule application container. 3. The Mule agent scans this directory recursively and loads properties before starting the application. #### Supported Property Formats The Mule agent supports two property file formats: - Java Properties Files (`.properties` extension): - Files ending with `.properties` are parsed as standard Java properties files - Each line follows the `key=value` format - File-as-Property (any other file): - The filename becomes the property name - The file content becomes the property value - Useful for single-value secrets Properties are loaded alphabetically by source name. Later properties override earlier ones with the same name. Example: Mount Properties from a Secret 1. Create a Secret: ```bash kubectl create secret generic database-credentials \ --from-literal=db.username=admin \ --from-literal=db.password=secretPass123 \ --from-literal=db.host=database.example.com \ -n my-apps ``` 2. Reference it in your MuleApplication: ```yaml spec: propertiesFrom: - secretRef: name: database-credentials ``` 3. Access properties in your Mule application: ```xml ``` Example: Mount Properties from a ConfigMap 1. Create a ConfigMap: ```bash kubectl create configmap app-config \ --from-literal=api.timeout=30000 \ --from-literal=api.retry.count=3 \ --from-literal=api.base.url=https://api.example.com \ -n my-apps ``` 2. Reference it in your MuleApplication: ```yaml spec: propertiesFrom: - configMapRef: name: app-config ``` Example: Mount a Java Properties File 1. Create a properties file: ```properties # application.properties http.port=8081 http.host=0.0.0.0 api.key=prod-key-12345 max.retry.attempts=5 timeout.seconds=30 ``` 2. Create a ConfigMap from the file: ```bash kubectl create configmap app-properties \ --from-file=application.properties \ -n my-apps ``` 3. Reference it in your MuleApplication: ```yaml spec: propertiesFrom: - configMapRef: name: app-properties ``` All properties from the file are loaded and available as `${http.port}`, `${api.key}`, etc. Example: Combine Multiple Property Sources To combine properties from multiple Secrets and ConfigMaps, list them in the order they should be loaded, where later sources override earlier ones if property names conflict. ```yaml spec: propertiesFrom: - secretRef: name: database-credentials # Loaded first - configMapRef: name: app-config # Loaded second (overrides conflicts) - secretRef: name: api-keys # Loaded third (overrides conflicts) ``` Example: Optional Property Sources Make a property source optional (doesn’t fail if not found): ```yaml spec: propertiesFrom: - configMapRef: name: optional-config optional: true # Don't fail if this ConfigMap doesn't exist ``` ### Template Restrictions When using Anypoint Controller, certain Runtime Fabric templates are not supported.
TemplateSupport StatusAlternative

KubernetesTemplate

Not supported

Define all Kubernetes-specific configurations directly in the Mule application CR fields (spec.pod, spec.service, spec.deployment)

HttpRouteTemplate

Not supported

Manage HTTP routing and ingress configurations separately using standard Kubernetes Ingress resources or your cluster’s ingress controller

Ingress Template

Not supported

Manage ingress configurations separately using standard Kubernetes Ingress resources or your cluster’s ingress controller

Templates were designed for imperative application management through Runtime Manager. With Anypoint Controller’s declarative GitOps approach, all configuration must be explicitly defined in the Custom Resource to maintain: - A single source of truth in version control - Complete visibility of application configuration - Reproducible deployments across environments #### Migrating from Templates If you currently use KubernetesTemplate for configuration, migrate those settings to the Mule application CR fields:
Template FieldMule application CR Field

Pod labels

spec.pod.metadata.labels

Pod annotations

spec.pod.metadata.annotations

Node selectors

spec.pod.nodeSelector

Tolerations

spec.pod.tolerations

Affinity rules

spec.pod.affinity

Topology spread

spec.pod.topologySpreadConstraints

Service annotations

spec.service.metadata.annotations

Deployment labels

spec.deployment.metadata.labels

#### Configuring Application URLs and Ingress For application URLs and ingress, you can define Kubernetes native Ingress resources in your cluster for Mule applications created with Anypoint Controller. Use standard Kubernetes Ingress controllers and resources to manage HTTP routing and external access to your applications, rather than Runtime Fabric ingress templates. For more information about configuring ingress for Runtime Fabric, see [Configure Ingress](https://docs.mulesoft.com/runtime-fabric/latest/configure-ingress). ## Troubleshooting Use these techniques to diagnose and resolve common issues with Anypoint Controller and Mule application deployments. ### Check Controller Logs Anypoint Controller is a feature enabled in the existing `rtfd` container. View the logs to troubleshoot deployment issues: ```bash kubectl logs -l app=rtf-agent -n -c rtfd --tail=100 ``` Follow logs in real-time: ```bash kubectl logs -l app=rtf-agent -n -c rtfd -f ``` Enable Debug Logs: By default, the log level is set to `info`, which does not emit detailed information for diagnosis. To enable debug logs for more detailed troubleshooting, add these environment variables to the `app-config` ConfigMap and restart the agent deployment: ```yaml LOG_LEVEL: DEBUG LOGGING_LEVEL_ROOT: debug ``` ### Common Issues Application Not Reconciling The `Applied` condition remains `False` or changes aren’t reflected. To resolve this issue: 1. Verify the namespace has the correct label: ```bash kubectl get namespace --show-labels ``` The namespace should have `rtf.mulesoft.com/agentNamespace=`. Add the label if missing: ```bash kubectl label namespace rtf.mulesoft.com/agentNamespace= ``` 2. Check the Connected App credentials: ```bash kubectl get secret anypoint-credentials -n -o yaml ``` 3. Verify the Connected App has required permissions in Anypoint Platform. 4. Check [Check Controller Logs](#check-controller-logs) for errors. Application Deployment Fails The `Applied` condition is `True`, but `Available` is `False`. Common causes: - Invalid runtime version - Artifact not found in Exchange - Insufficient resources (CPU/memory) - Image pull errors To resolve this issue: 1. Check pod status: ```bash kubectl get pods -n -l rtf.mulesoft.com/app= ``` 2. View pod logs: ```bash kubectl logs -n ``` 3. Check pod events: ```bash kubectl describe pod -n ``` Invalid Configuration `kubectl apply` fails with validation errors. To resolve this issue: 1. Validate the YAML syntax: ```bash kubectl apply -f app.yaml --dry-run=server ``` 2. Check immutable field violations (target, businessGroup, and environment can’t be changed after creation). 3. Verify required fields are present. Anypoint Platform API Errors The `Applied` condition shows `APIErrorResponse`. To resolve this issue: 1. Read the error message in the status condition. Common errors: - `409 Conflict`: Application name already exists (created outside Anypoint Controller) - `404 Not Found`: Invalid target, business group, or environment name - `403 Forbidden`: Connected App lacks permissions - `400 Bad Request`: Invalid configuration (for example, runtime version) 2. Verify the configuration matches your Anypoint Platform setup. ## See Also - [Deploy Applications to Runtime Fabric Using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) - [Install Runtime Fabric Using Helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) - [Monitor Applications](https://docs.mulesoft.com/runtime-fabric/latest/manage-monitor-applications) - [Customize Kubernetes Resources Using CRDs](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd) - [Configure Horizontal Pod Autoscaling](https://docs.mulesoft.com/runtime-fabric/latest/configure-horizontal-autoscaling) - [Harden Mule Applications](https://docs.mulesoft.com/runtime-fabric/latest/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.10 --- # Deploying API Proxies to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy API proxies to a Mule runtime. ## Before you Begin To deploy API proxies to a Mule runtime, you must have the following permissions on your account: - Manage APIs Configuration permission - Deploy API Proxies permission You must ensure that you are using API Gateway version 3.8.7, 3.9.1, or 4.1.2. If you are deploying your API to a Mule 4 environment and want to enable the proxy to support HTTPS requests, first refer to [build HTTPS API proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy). By default, the resources allocated to the proxy app are: - CPU: 0.2 vCores - Memory: 1.024 GB You can update resource allocation settings on the application’s **Settings** page in Runtime Manager. ## Deploy an API Proxy Use API Manager to deploy proxies to Runtime Fabric. You can enable proxies to support inbound and outbound requests over HTTP or HTTPS. If you need your proxy to support HTTPS, see [Build HTTPS API Proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) in the API Manager documentation for additional requirements before getting started. 1. From Anypoint Platform, select **API Manager** > **Manage API** > **Manage API From Exchange**. 2. In **API Name**, search for the name of the asset saved in Exchange. The **Asset type**, **API version**, and **Asset version** fields for the API are auto-populated from Exchange. 3. For **Managing type**, select **Endpoint with proxy**. 4. For **Proxy deployment target**, select Runtime Fabric. 5. Select the Mule version. 6. For **Implementation URI**, specify the base URL path to access the proxy. 7. Optionally, specify a **Path**. 8. If you want to enable SSL for inbound traffic: 1. Select **HTTPS** for the **Scheme**. You should now see the **TLS Context for Inbound Traffic** field enabled. 2. Select **Add TLS Context**. 3. Select the secret group where you hosted your TLS context from the **Secret group** drop-down. 4. Select your TLS context for your HTTPS API Proxy from the **TLS Context** drop-down. 9. Enter the **Port** number for your API proxy. 10. Select your **Client Provider**. 11. Click **Advanced Options**. 12. In **Proxy Version**, select **latest**. This value ensures that your API proxy uses the latest released proxy version. 13. Click **Add TLS Context** for **TLS Context for Outbound traffic**. 1. Select the secret group where you hosted your TLS Context from the **Secret Group** drop-down list. 2. Select your TLS Context for your HTTPS API Proxy from the **TLS Context** drop-down. 14. Click **Save**. Your configuration information is saved and API Manager displays the **Deployment Configuration** section. 15. In the **Deployment Configuration** section, configure the following: 1. Select the **Runtime Fabric target**. 2. Select the **Runtime version**. 3. Enter the name of the proxy application. API Manager deploys the API proxy to Runtime Fabric. While deploying, a deployment status dialog appears that indicates: 1. **Deploying proxy**. 2. **Starting application**. 3. **Deploy successful**. After deployment, you can manage the deployed API proxy from Runtime Manager. ## Enable an HTTPS Proxy Using Anypoint Studio You can enable the proxy to support HTTPs requests using Anypoint Studio. 1. Download the API gateway and deploy from API Manager using the instructions in [Downloading an API Proxy](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). 2. Open the gateway in Anypoint Studio and insert a keystore (SSL cert) using the instructions in [Use Anypoint Studio to Configure TLS](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls). 3. Export and deploy the gateway using Runtime Manager according to the instructions in [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric). 4. Enable last-mile security on the application using the instructions in [How to enable last-mile security in Runtime Fabric (RTF)](https://help.salesforce.com/s/articleView?id=001117051&type=1). ## Related Resources - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.11 --- # Deploying API Proxies to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy API proxies to a Mule runtime. ## Before you Begin To deploy API proxies to a Mule runtime, you must have these permissions on your account: - Manage APIs Configuration permission - Deploy API Proxies permission You must ensure that you are using API Gateway version 3.8.7, 3.9.1, or 4.1.2. If you are deploying your API to a Mule 4 environment and want to enable the proxy to support HTTPS requests, first refer to [build HTTPS API proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy). By default, the resources allocated to the proxy app are: - CPU: 0.2 vCores - Memory: 1.024 GB You can update resource allocation settings on the application’s **Settings** page in Runtime Manager. ## Deploy an API Proxy Use API Manager to deploy proxies to Runtime Fabric. You can enable proxies to support inbound and outbound requests over HTTP or HTTPS. If you need your proxy to support HTTPS, see [Build HTTPS API Proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) in the API Manager documentation for additional requirements before getting started. 1. From Anypoint Platform, select **API Manager** > **Manage API** > **Manage API From Exchange**. 2. In **API Name**, search for the name of the asset saved in Exchange. The **Asset type**, **API version**, and **Asset version** fields for the API are auto-populated from Exchange. 3. For **Managing type**, select **Endpoint with proxy**. 4. For **Proxy deployment target**, select Runtime Fabric. 5. Select the Mule version. 6. For **Implementation URI**, specify the base URL path to access the proxy. 7. Optionally, specify a **Path**. 8. If you want to enable SSL for inbound traffic: 1. Select **HTTPS** for the **Scheme**. You should now see the **TLS Context for Inbound Traffic** field enabled. 2. Select **Add TLS Context**. 3. Select the secret group where you hosted your TLS context from the **Secret group** drop-down. 4. Select your TLS context for your HTTPS API Proxy from the **TLS Context** drop-down. 9. Enter the **Port** number for your API proxy. 10. Select your **Client Provider**. 11. Click **Advanced Options**. 12. In **Proxy Version**, select **latest**. This value ensures that your API proxy uses the latest released proxy version. 13. Click **Add TLS Context** for **TLS Context for Outbound traffic**. 1. Select the secret group where you hosted your TLS Context from the **Secret Group** drop-down list. 2. Select your TLS Context for your HTTPS API Proxy from the **TLS Context** drop-down. 14. Click **Save**. Your configuration information is saved and API Manager displays the **Deployment Configuration** section. 15. In the **Deployment Configuration** section, configure this: 1. Select the **Runtime Fabric target**. 2. Select the **Runtime version**. 3. Enter the name of the proxy application. API Manager deploys the API proxy to Runtime Fabric. While deploying, a deployment status dialog appears that indicates: 1. **Deploying proxy**. 2. **Starting application**. 3. **Deploy successful**. After deployment, you can manage the deployed API proxy from Runtime Manager. ## Enable an HTTPS Proxy Using Anypoint Studio You can enable the proxy to support HTTPs requests using Anypoint Studio. 1. Download the API gateway and deploy from API Manager using the instructions in [Downloading an API Proxy](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). 2. Open the gateway in Anypoint Studio and insert a keystore (SSL cert) using the instructions in [Use Anypoint Studio to Configure TLS](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls). 3. Export and deploy the gateway using Runtime Manager according to the instructions in [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric). 4. Enable last-mile security on the application using the instructions in [How to enable last-mile security in Runtime Fabric (RTF)](https://help.salesforce.com/s/articleView?id=001117051&type=1). ## Related Resources - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.5 --- # Deploying API Proxies to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric enables you to deploy API proxies to a Mule runtime. ## Before you Begin To deploy API proxies to a Mule runtime, you must have the following permissions on your account: - Manage APIs Configuration permission - Deploy API Proxies permission You must ensure that you are using API Gateway version 3.8.7, 3.9.1, or 4.1.2. If you are deploying your API to a Mule 4 environment and want to enable the proxy to support HTTPS requests, first refer to [build HTTPS API proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy). By default, the resources allocated to the proxy app are: - CPU: 0.2 vCores - Memory: 1.024 GB You can update resource allocation settings on the application’s **Settings** page in Runtime Manager. ## Deploy an API Proxy Use API Manager to deploy proxies to Runtime Fabric. You can enable proxies to support inbound and outbound requests over HTTP or HTTPS. If you need your proxy to support HTTPS, see [Build HTTPS API Proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) in the API Manager documentation for additional requirements before getting started. 1. From Anypoint Platform, select **API Manager** > **Manage API** > **Manage API From Exchange**. 2. In **API Name**, search for the name of the asset saved in Exchange. The **Asset type**, **API version**, and **Asset version** fields for the API are auto-populated from Exchange. 3. For **Managing type**, select **Endpoint with proxy**. 4. For **Proxy deployment target**, select Runtime Fabric. 5. Select the Mule version. 6. For **Implementation URI**, specify the base URL path to access the proxy. 7. Optionally, specify a **Path**. 8. If you want to enable SSL for inbound traffic: 1. Select **HTTPS** for the **Scheme**. You should now see the **TLS Context for Inbound Traffic** field enabled. 2. Select **Add TLS Context**. 3. Select the secret group where you hosted your TLS context from the **Secret group** drop-down. 4. Select your TLS context for your HTTPS API Proxy from the **TLS Context** drop-down. 9. Enter the **Port** number for your API proxy. 10. Select your **Client Provider**. 11. Click **Advanced Options**. 12. In **Proxy Version**, select **latest**. This value ensures that your API proxy uses the latest released proxy version. 13. Click **Add TLS Context** for **TLS Context for Outbound traffic**. 1. Select the secret group where you hosted your TLS Context from the **Secret Group** drop-down list. 2. Select your TLS Context for your HTTPS API Proxy from the **TLS Context** drop-down. 14. Click **Save**. Your configuration information is saved and API Manager displays the **Deployment Configuration** section. 15. In the **Deployment Configuration** section, configure the following: 1. Select the **Runtime Fabric target**. 2. Select the **Runtime version**. 3. Enter the name of the proxy application. API Manager deploys the API proxy to Runtime Fabric. While deploying, a deployment status dialog appears that indicates: 1. **Deploying proxy**. 2. **Starting application**. 3. **Deploy successful**. After deployment, you can manage the deployed API proxy from Runtime Manager. ## Enable an HTTPS Proxy Using Anypoint Studio You can enable the proxy to support HTTPs requests using Anypoint Studio. 1. Download the API gateway and deploy from API Manager using the instructions in [Downloading an API Proxy](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). 2. Open the gateway in Anypoint Studio and insert a keystore (SSL cert) using the instructions in [Use Anypoint Studio to Configure TLS](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls). 3. Export and deploy the gateway using Runtime Manager according to the instructions in [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric). 4. Enable last-mile security on the application using the instructions in [How to enable last-mile security in Runtime Fabric (RTF)](https://help.salesforce.com/s/articleView?id=001117051&type=1). ## Related Resources - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.6 --- # Deploying API Proxies to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy API proxies to a Mule runtime. ## Before you Begin To deploy API proxies to a Mule runtime, you must have the following permissions on your account: - Manage APIs Configuration permission - Deploy API Proxies permission You must ensure that you are using API Gateway version 3.8.7, 3.9.1, or 4.1.2. If you are deploying your API to a Mule 4 environment and want to enable the proxy to support HTTPS requests, first refer to [build HTTPS API proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy). By default, the resources allocated to the proxy app are: - CPU: 0.2 vCores - Memory: 1.024 GB You can update resource allocation settings on the application’s **Settings** page in Runtime Manager. ## Deploy an API Proxy Use API Manager to deploy proxies to Runtime Fabric. You can enable proxies to support inbound and outbound requests over HTTP or HTTPS. If you need your proxy to support HTTPS, see [Build HTTPS API Proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) in the API Manager documentation for additional requirements before getting started. 1. From Anypoint Platform, select **API Manager** > **Manage API** > **Manage API From Exchange**. 2. In **API Name**, search for the name of the asset saved in Exchange. The **Asset type**, **API version**, and **Asset version** fields for the API are auto-populated from Exchange. 3. For **Managing type**, select **Endpoint with proxy**. 4. For **Proxy deployment target**, select Runtime Fabric. 5. Select the Mule version. 6. For **Implementation URI**, specify the base URL path to access the proxy. 7. Optionally, specify a **Path**. 8. If you want to enable SSL for inbound traffic: 1. Select **HTTPS** for the **Scheme**. You should now see the **TLS Context for Inbound Traffic** field enabled. 2. Select **Add TLS Context**. 3. Select the secret group where you hosted your TLS context from the **Secret group** drop-down. 4. Select your TLS context for your HTTPS API Proxy from the **TLS Context** drop-down. 9. Enter the **Port** number for your API proxy. 10. Select your **Client Provider**. 11. Click **Advanced Options**. 12. In **Proxy Version**, select **latest**. This value ensures that your API proxy uses the latest released proxy version. 13. Click **Add TLS Context** for **TLS Context for Outbound traffic**. 1. Select the secret group where you hosted your TLS Context from the **Secret Group** drop-down list. 2. Select your TLS Context for your HTTPS API Proxy from the **TLS Context** drop-down. 14. Click **Save**. Your configuration information is saved and API Manager displays the **Deployment Configuration** section. 15. In the **Deployment Configuration** section, configure the following: 1. Select the **Runtime Fabric target**. 2. Select the **Runtime version**. 3. Enter the name of the proxy application. API Manager deploys the API proxy to Runtime Fabric. While deploying, a deployment status dialog appears that indicates: 1. **Deploying proxy**. 2. **Starting application**. 3. **Deploy successful**. After deployment, you can manage the deployed API proxy from Runtime Manager. ## Enable an HTTPS Proxy Using Anypoint Studio You can enable the proxy to support HTTPs requests using Anypoint Studio. 1. Download the API gateway and deploy from API Manager using the instructions in [Downloading an API Proxy](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). 2. Open the gateway in Anypoint Studio and insert a keystore (SSL cert) using the instructions in [Use Anypoint Studio to Configure TLS](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls). 3. Export and deploy the gateway using Runtime Manager according to the instructions in [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric). 4. Enable last-mile security on the application using the instructions in [How to enable last-mile security in Runtime Fabric (RTF)](https://help.salesforce.com/s/articleView?id=001117051&type=1). ## Related Resources - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.7 --- # Deploying API Proxies to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy API proxies to a Mule runtime. ## Before you Begin To deploy API proxies to a Mule runtime, you must have the following permissions on your account: - Manage APIs Configuration permission - Deploy API Proxies permission You must ensure that you are using API Gateway version 3.8.7, 3.9.1, or 4.1.2. If you are deploying your API to a Mule 4 environment and want to enable the proxy to support HTTPS requests, first refer to [build HTTPS API proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy). By default, the resources allocated to the proxy app are: - CPU: 0.2 vCores - Memory: 1.024 GB You can update resource allocation settings on the application’s **Settings** page in Runtime Manager. ## Deploy an API Proxy Use API Manager to deploy proxies to Runtime Fabric. You can enable proxies to support inbound and outbound requests over HTTP or HTTPS. If you need your proxy to support HTTPS, see [Build HTTPS API Proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) in the API Manager documentation for additional requirements before getting started. 1. From Anypoint Platform, select **API Manager** > **Manage API** > **Manage API From Exchange**. 2. In **API Name**, search for the name of the asset saved in Exchange. The **Asset type**, **API version**, and **Asset version** fields for the API are auto-populated from Exchange. 3. For **Managing type**, select **Endpoint with proxy**. 4. For **Proxy deployment target**, select Runtime Fabric. 5. Select the Mule version. 6. For **Implementation URI**, specify the base URL path to access the proxy. 7. Optionally, specify a **Path**. 8. If you want to enable SSL for inbound traffic: 1. Select **HTTPS** for the **Scheme**. You should now see the **TLS Context for Inbound Traffic** field enabled. 2. Select **Add TLS Context**. 3. Select the secret group where you hosted your TLS context from the **Secret group** drop-down. 4. Select your TLS context for your HTTPS API Proxy from the **TLS Context** drop-down. 9. Enter the **Port** number for your API proxy. 10. Select your **Client Provider**. 11. Click **Advanced Options**. 12. In **Proxy Version**, select **latest**. This value ensures that your API proxy uses the latest released proxy version. 13. Click **Add TLS Context** for **TLS Context for Outbound traffic**. 1. Select the secret group where you hosted your TLS Context from the **Secret Group** drop-down list. 2. Select your TLS Context for your HTTPS API Proxy from the **TLS Context** drop-down. 14. Click **Save**. Your configuration information is saved and API Manager displays the **Deployment Configuration** section. 15. In the **Deployment Configuration** section, configure the following: 1. Select the **Runtime Fabric target**. 2. Select the **Runtime version**. 3. Enter the name of the proxy application. API Manager deploys the API proxy to Runtime Fabric. While deploying, a deployment status dialog appears that indicates: 1. **Deploying proxy**. 2. **Starting application**. 3. **Deploy successful**. After deployment, you can manage the deployed API proxy from Runtime Manager. ## Enable an HTTPS Proxy Using Anypoint Studio You can enable the proxy to support HTTPs requests using Anypoint Studio. 1. Download the API gateway and deploy from API Manager using the instructions in [Downloading an API Proxy](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). 2. Open the gateway in Anypoint Studio and insert a keystore (SSL cert) using the instructions in [Use Anypoint Studio to Configure TLS](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls). 3. Export and deploy the gateway using Runtime Manager according to the instructions in [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric). 4. Enable last-mile security on the application using the instructions in [How to enable last-mile security in Runtime Fabric (RTF)](https://help.salesforce.com/s/articleView?id=001117051&type=1). ## Related Resources - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.8 --- # Deploying API Proxies to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy API proxies to a Mule runtime. ## Before you Begin To deploy API proxies to a Mule runtime, you must have the following permissions on your account: - Manage APIs Configuration permission - Deploy API Proxies permission You must ensure that you are using API Gateway version 3.8.7, 3.9.1, or 4.1.2. If you are deploying your API to a Mule 4 environment and want to enable the proxy to support HTTPS requests, first refer to [build HTTPS API proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy). By default, the resources allocated to the proxy app are: - CPU: 0.2 vCores - Memory: 1.024 GB You can update resource allocation settings on the application’s **Settings** page in Runtime Manager. ## Deploy an API Proxy Use API Manager to deploy proxies to Runtime Fabric. You can enable proxies to support inbound and outbound requests over HTTP or HTTPS. If you need your proxy to support HTTPS, see [Build HTTPS API Proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) in the API Manager documentation for additional requirements before getting started. 1. From Anypoint Platform, select **API Manager** > **Manage API** > **Manage API From Exchange**. 2. In **API Name**, search for the name of the asset saved in Exchange. The **Asset type**, **API version**, and **Asset version** fields for the API are auto-populated from Exchange. 3. For **Managing type**, select **Endpoint with proxy**. 4. For **Proxy deployment target**, select Runtime Fabric. 5. Select the Mule version. 6. For **Implementation URI**, specify the base URL path to access the proxy. 7. Optionally, specify a **Path**. 8. If you want to enable SSL for inbound traffic: 1. Select **HTTPS** for the **Scheme**. You should now see the **TLS Context for Inbound Traffic** field enabled. 2. Select **Add TLS Context**. 3. Select the secret group where you hosted your TLS context from the **Secret group** drop-down. 4. Select your TLS context for your HTTPS API Proxy from the **TLS Context** drop-down. 9. Enter the **Port** number for your API proxy. 10. Select your **Client Provider**. 11. Click **Advanced Options**. 12. In **Proxy Version**, select **latest**. This value ensures that your API proxy uses the latest released proxy version. 13. Click **Add TLS Context** for **TLS Context for Outbound traffic**. 1. Select the secret group where you hosted your TLS Context from the **Secret Group** drop-down list. 2. Select your TLS Context for your HTTPS API Proxy from the **TLS Context** drop-down. 14. Click **Save**. Your configuration information is saved and API Manager displays the **Deployment Configuration** section. 15. In the **Deployment Configuration** section, configure the following: 1. Select the **Runtime Fabric target**. 2. Select the **Runtime version**. 3. Enter the name of the proxy application. API Manager deploys the API proxy to Runtime Fabric. While deploying, a deployment status dialog appears that indicates: 1. **Deploying proxy**. 2. **Starting application**. 3. **Deploy successful**. After deployment, you can manage the deployed API proxy from Runtime Manager. ## Enable an HTTPS Proxy Using Anypoint Studio You can enable the proxy to support HTTPs requests using Anypoint Studio. 1. Download the API gateway and deploy from API Manager using the instructions in [Downloading an API Proxy](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). 2. Open the gateway in Anypoint Studio and insert a keystore (SSL cert) using the instructions in [Use Anypoint Studio to Configure TLS](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls). 3. Export and deploy the gateway using Runtime Manager according to the instructions in [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric). 4. Enable last-mile security on the application using the instructions in [How to enable last-mile security in Runtime Fabric (RTF)](https://help.salesforce.com/s/articleView?id=001117051&type=1). ## Related Resources - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.9 --- # Deploying API Proxies to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy API proxies to a Mule runtime. ## Before you Begin To deploy API proxies to a Mule runtime, you must have the following permissions on your account: - Manage APIs Configuration permission - Deploy API Proxies permission You must ensure that you are using API Gateway version 3.8.7, 3.9.1, or 4.1.2. If you are deploying your API to a Mule 4 environment and want to enable the proxy to support HTTPS requests, first refer to [build HTTPS API proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy). By default, the resources allocated to the proxy app are: - CPU: 0.2 vCores - Memory: 1.024 GB You can update resource allocation settings on the application’s **Settings** page in Runtime Manager. ## Deploy an API Proxy Use API Manager to deploy proxies to Runtime Fabric. You can enable proxies to support inbound and outbound requests over HTTP or HTTPS. If you need your proxy to support HTTPS, see [Build HTTPS API Proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) in the API Manager documentation for additional requirements before getting started. 1. From Anypoint Platform, select **API Manager** > **Manage API** > **Manage API From Exchange**. 2. In **API Name**, search for the name of the asset saved in Exchange. The **Asset type**, **API version**, and **Asset version** fields for the API are auto-populated from Exchange. 3. For **Managing type**, select **Endpoint with proxy**. 4. For **Proxy deployment target**, select Runtime Fabric. 5. Select the Mule version. 6. For **Implementation URI**, specify the base URL path to access the proxy. 7. Optionally, specify a **Path**. 8. If you want to enable SSL for inbound traffic: 1. Select **HTTPS** for the **Scheme**. You should now see the **TLS Context for Inbound Traffic** field enabled. 2. Select **Add TLS Context**. 3. Select the secret group where you hosted your TLS context from the **Secret group** drop-down. 4. Select your TLS context for your HTTPS API Proxy from the **TLS Context** drop-down. 9. Enter the **Port** number for your API proxy. 10. Select your **Client Provider**. 11. Click **Advanced Options**. 12. In **Proxy Version**, select **latest**. This value ensures that your API proxy uses the latest released proxy version. 13. Click **Add TLS Context** for **TLS Context for Outbound traffic**. 1. Select the secret group where you hosted your TLS Context from the **Secret Group** drop-down list. 2. Select your TLS Context for your HTTPS API Proxy from the **TLS Context** drop-down. 14. Click **Save**. Your configuration information is saved and API Manager displays the **Deployment Configuration** section. 15. In the **Deployment Configuration** section, configure the following: 1. Select the **Runtime Fabric target**. 2. Select the **Runtime version**. 3. Enter the name of the proxy application. API Manager deploys the API proxy to Runtime Fabric. While deploying, a deployment status dialog appears that indicates: 1. **Deploying proxy**. 2. **Starting application**. 3. **Deploy successful**. After deployment, you can manage the deployed API proxy from Runtime Manager. ## Enable an HTTPS Proxy Using Anypoint Studio You can enable the proxy to support HTTPs requests using Anypoint Studio. 1. Download the API gateway and deploy from API Manager using the instructions in [Downloading an API Proxy](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). 2. Open the gateway in Anypoint Studio and insert a keystore (SSL cert) using the instructions in [Use Anypoint Studio to Configure TLS](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls). 3. Export and deploy the gateway using Runtime Manager according to the instructions in [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric). 4. Enable last-mile security on the application using the instructions in [How to enable last-mile security in Runtime Fabric (RTF)](https://help.salesforce.com/s/articleView?id=001117051&type=1). ## Related Resources - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Deploying API Proxies to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy API proxies to a Mule runtime. ## Before you Begin To deploy API proxies to a Mule runtime, you must have the following permissions on your account: - Manage APIs Configuration permission - Deploy API Proxies permission You must ensure that you are using API Gateway version 3.8.7, 3.9.1, or 4.1.2. If you are deploying your API to a Mule 4 environment and want to enable the proxy to support HTTPS requests, first refer to [build HTTPS API proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy). By default, the resources allocated to the proxy app are: - CPU: 0.2 vCores - Memory: 1.024 GB You can update resource allocation settings on the application’s **Settings** page in Runtime Manager. ## Deploy an API Proxy Use API Manager to deploy proxies to Runtime Fabric. You can enable proxies to support inbound and outbound requests over HTTP or HTTPS. If you need your proxy to support HTTPS, see [Build HTTPS API Proxies](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) in the API Manager documentation for additional requirements before getting started. 1. From Anypoint Platform, select **API Manager** > **Manage API** > **Manage API From Exchange**. 2. In **API Name**, search for the name of the asset saved in Exchange. The **Asset type**, **API version**, and **Asset version** fields for the API are auto-populated from Exchange. 3. For **Managing type**, select **Endpoint with proxy**. 4. For **Proxy deployment target**, select Runtime Fabric. 5. Select the Mule version. 6. For **Implementation URI**, specify the base URL path to access the proxy. 7. Optionally, specify a **Path**. 8. If you want to enable SSL for inbound traffic: 1. Select **HTTPS** for the **Scheme**. You should now see the **TLS Context for Inbound Traffic** field enabled. 2. Select **Add TLS Context**. 3. Select the secret group where you hosted your TLS context from the **Secret group** drop-down. 4. Select your TLS context for your HTTPS API Proxy from the **TLS Context** drop-down. 9. Enter the **Port** number for your API proxy. 10. Select your **Client Provider**. 11. Click **Advanced Options**. 12. In **Proxy Version**, select **latest**. This value ensures that your API proxy uses the latest released proxy version. 13. Click **Add TLS Context** for **TLS Context for Outbound traffic**. 1. Select the secret group where you hosted your TLS Context from the **Secret Group** drop-down list. 2. Select your TLS Context for your HTTPS API Proxy from the **TLS Context** drop-down. 14. Click **Save**. Your configuration information is saved and API Manager displays the **Deployment Configuration** section. 15. In the **Deployment Configuration** section, configure the following: 1. Select the **Runtime Fabric target**. 2. Select the **Runtime version**. 3. Enter the name of the proxy application. API Manager deploys the API proxy to Runtime Fabric. While deploying, a deployment status dialog appears that indicates: 1. **Deploying proxy**. 2. **Starting application**. 3. **Deploy successful**. After deployment, you can manage the deployed API proxy from Runtime Manager. ## Enable an HTTPS Proxy Using Anypoint Studio You can enable the proxy to support HTTPs requests using Anypoint Studio. 1. Download the API gateway and deploy from API Manager using the instructions in [Downloading an API Proxy](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). 2. Open the gateway in Anypoint Studio and insert a keystore (SSL cert) using the instructions in [Use Anypoint Studio to Configure TLS](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls). 3. Export and deploy the gateway using Runtime Manager according to the instructions in [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric). 4. Enable last-mile security on the application using the instructions in [How to enable last-mile security in Runtime Fabric (RTF)](https://help.salesforce.com/s/articleView?id=001117051&type=1). ## Related Resources - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.5 --- # Deploying Applications to Runtime Fabric using Maven > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric supports using Mule Maven Plugin 3.x to manage and deploy Mule applications. The information in this topic is specific to deploying a Mule application to Mule runtime engine 4.x. ## Prerequisites - Ensure that the Mule Maven Plugin is added to your project See [Add the Mule Maven Plugin to a Mule Project](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp) for instructions. - You understand and have available the number of resources required to deploy to Runtime Fabric See [Resource Allocation on Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) for more information. - The application is already published in Exchange See [Publish and Deploy Exchange Assets Using Maven](https://docs.mulesoft.com/exchange/to-publish-assets-maven). The Mule Maven Facade API (v3) is added as a repository in the distribution management section of your project’s POM file. For example: Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION\_ID/maven default If you publish assets using Exchange API, use Exchange API v2, otherwise schedulers aren’t displayed. ## Add the Mule Maven Plugin to a Mule Project To add the Mule Maven plugin, you need to add its maven dependency to the project: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` From this repository: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` This enables the Mule Maven plugin in your project. > [!IMPORTANT] If `true` is not present, the plugin does not work. ## Configure the Runtime Fabric Deployment Strategy Inside the `plugin` element, add a configuration for your Runtime Fabric deployment, replacing the following placeholder values with your Runtime Fabric information: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## Deploy to Runtime Fabric From the command line in your project’s folder, package the application and execute the deploy goal: ```bash mvn clean deploy -DmuleDeploy ``` ### Exchange Snapshot Assets You can also deploy Exchange snapshot assets into Runtime Fabric. By using `SNAPSHOT` version assets in Anypoint Exchange during the development and testing phase, you can avoid incrementing your application’s version number for small changes. After your `SNAPSHOT` version application has been overwritten in Anypoint Exchange, you can redeploy your `SNAPSHOT` version application to Runtime Fabric via the Mule Maven plugin to deploy the latest changes. To learn more about publishing snapshot assets to Anypoint Exchange, see [Asset Lifecycle State](https://docs.mulesoft.com/exchange/to-publish-assets-maven#asset-lifecycle-state). > [!NOTE] Each time you update your application’s snapshot, redeploy the application to refresh it > with the latest snapshot binaries. > > Because snapshot assets can change after deployment, avoid deploying them into your production > environment. ## Redeploy to Runtime Fabric To redeploy the application, run the same command as you did to deploy. Runtime Fabric rewrites the application you had deployed. ## Authentication Methods When you deploy applications using Mule Maven plugin, you can use different methods to provide your credentials to authenticate against the deployment platform. Depending on the authentication method you use, the parameters to set in the deployment configuration differ:
Authentication MethodDescriptionConfiguration Parameters

Username and password

Use a Runtime Fabric username and password to authenticate.

  • username

  • password

Server

Use credentials stored in a Maven server, configured inside the Maven settings.xml file.

  • server

Authorization Token

Use an authorization token to access the platform.
See Identity Management for a list of supported single sign-on (SSO) types.

  • authToken

Connected Apps

Use a Connected App to perform the authentication programmatically by communicating with Anypoint Platform.
Note that the Connected App credentials must have the Design Center Developer access scope.
See Connected Apps for Developers for instructions about creating Connected Apps.

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType

For a detailed description of the configuration parameters, see the [Runtime Fabric Deployment Parameters Reference](#rtf-deploy-reference). ## Runtime Fabric Deployment Parameters Reference
ParameterDescriptionRequired

runtimeFabricDeployment

Top-Level Element

Yes

uri

Your Anypoint Platform URI.
If not set, defaults to https://anypoint.mulesoft.com.

No

muleVersion

The Mule runtime engine version to run in your Runtime Fabric instance.
Ensure that this value is equal to or higher than the earliest required Mule version of your application. By default, the latest available Mule version is selected.
Example values: 4.6.0 selects the last build where it defaults to Edge channel and Java 8. If you want to choose a different LTS or Edge selection or Java version, specify the full Mule version name as in 4.6.0:1e-java17.
When using Mule Maven plugin versions 3.8.0 and 4.0.0 for deployments, the muleVersion property doesn’t allow you to specify releaseChannel and javaVersion. To specify these properties, upgrade the plugin to version 4.1.1 or later.

No

releaseChannel

Set the name of the release channel used to select the Mule image. Supported values are NONE, EDGE, and LTS. By default, the value is set to EDGE. If the selected release channel doesn’t exist, an error occurs.

No

javaVersion

Set the Java version used in the deploy. Supported values are 8 and 17. By default, the value is set to 8. If the selected Java version doesn’t exist, an error occurs.

No

username

Your Anypoint Platform username

Only when using Anypoint Platform credentials to login.

password

Your Anypoint Platform password

Only when using Anypoint Platform credentials to login.

applicationName

The application name displayed in Runtime Manager after the app deploys.

Yes

target

The Runtime Fabric target name where to deploy the app.

Yes

provider

Provider MC (MuleSoft Control Plane) indicates that the deployment is managed through Anypoint Runtime Manager. Set to MC for Runtime Fabric.

Yes

environment

Target Anypoint Platform environment.
This value must match an environment configured in your Anypoint Platform account, as shown here:

<environment>Sandbox</environment>

Yes

replicas

Specifies the number of replicas, or instances, of the Mule application to deploy. The maximum number of replicas per application is 16.

Only when autoscaling is set to false.

businessGroup

The Business group path of the deployment
Specify the full hierarchical path from the parent organization to the target Business group, for example:

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

This value is omitted if businessGroupId is set. If businessGroup and businessGroupId are not set, the value defaults to the main business group of the user.

No

businessGroupId

The Business group ID of the deployment
Instead of specifying the Business group path, you can specify the Business group ID to deploy your application. If businessGroupId and businessGroup are not set, the value defaults to the main business group of the user.
The Business group ID is a mandatory parameter when you have access only to a specific Business group but not to the parent organization.
This parameter is available in plugin version 3.2.7 and later.

No

deploymentTimeout

The allowed elapsed time, in milliseconds, between the start of the deployment process and the confirmation that the artifact has been deployed

The default value is 600000.

No

server

Maven server with Anypoint Platform credentials
This is only needed if you want to use your credentials stored in your Maven settings.xml file. This is not the Mule server name.

No

properties

Top-Level element
If you need to set properties for the Mule application you are deploying, you can use the <properties> top-level element:

<properties>
  <key>value</key>
</properties>

For example:

<properties>
  <http.port>8081</http.port>
</properties>

No

propertiesFile

Top-level element
Specifies a file that contains properties for the Mule application being deployed. Use this parameter as an alternative to defining properties inline with <properties>. The file must use the Java properties format, with one key=value pair per line.

No

secureProperties

Top-Level element
Use the secureProperties top-level element to set properties for the Mule application and instruct Runtime Fabric to encrypt the values before storing them:

<secureProperties>
  <key>value</key>
</secureProperties>

For example:

<secureProperties>
  <http.port>8081</http.port>
</secureProperties>

No

skip

When set to true, skips the plugin deployment goal.
Its default value is false.

No

skipDeploymentVerification

When set to true, skips the status verification of your deployed app.
Its default value is false.

No

authToken

Specifies the authorization token to access the platform. You can use this authentication method instead of setting username and password.
See Identity Management for a list of supported single sign-on (SSO) types.

Only when using an Authorization token to login.

connectedAppClientId

Specifies the Connected App clientID value.

Only when using Connected Apps credentials to login.

connectedAppClientSecret

Specifies the Connected App secret key.

Only when using Connected Apps credentials to login.

connectedAppGrantType

Specifies the only supported connection type: client_credentials.

Only when using Connected Apps credentials to login.

deploymentSettings

Any of the parameters documented in deploymentSettings Reference

No

### deploymentSettings Parameters Reference
ParameterDescription

enforceDeployingReplicasAcrossNodes

Enforces the deployment of replicas across different nodes. The default value is false.

Configuration example:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy

Accepted valuesDescription

rolling

Maintains availability by updating replicas incrementally. Requires one additional replica’s worth of resources to succeed.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is one less than the total number of nodes.

recreate

Terminates replicas before re-deployment. Re-deployment is quicker than rolling and doesn’t require additional resources.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is equal to the number of nodes.

The default value is rolling.

Configuration example:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

Enables clustering across two or more replicas of the application. The default value is false.

Configuration example:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

resources

cpu

reserved

Specifies the number of cores to allocate for each application replica. The default value is 0.5 vCores.

limit

Specifies the number of max cores to allocate for each replica of the application.
If a reserved configuration is present, ensure that this value is equal or higher.

memory

reserved

Specifies the amount of memory to allocate for each application replica. The default value is 700 MB.

limit

Specifies the maximum memory allocated per application replica. If a reserved configuration is present, ensure that this value is equal or higher.

Configuration example:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound

publicUrl

URL of the deployed application.

Configuration example using wildcard URL:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

Configuration example for path-based routing:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://www.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

Configures the Mule application to use a persistent object store. By default, it is set to false.

jvm

args

Specifies JVM arguments to pass to Runtime Fabric when deploying the application. Use spaces to separate each argument.

Configuration example:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

Not applicable for Runtime Fabric BYOK. By default, it is set to false

disableAmLogForwarding

Disables the application-level log forwarding to Anypoint Monitoring. By default, it is set to false.

autoscaling

Provides CPU based horizontal autoscaling configuration for deployment and redeployment operations. If autoscaling is disabled and the fields minReplicas and maxReplicas are provided, they must match the value of the target.replicas field. See Enable Trace Data Collection. Configuration example:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>
## Encrypt Credentials To use encrypted credentials when deploying, you need to set up your Maven master encrypted password and your `settings-security.xml` file. 1. Create a master password for your Maven configuration. mvn --encrypt-master-password Maven returns your master password encrypted: {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. Create a `settings-security.xml` file in your ~/.m2 repository and add your encrypted master password: ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Encrypt your Anypoint platform password: mvn --encrypt-password Maven returns your Anypoint platform password encrypted: {HTWFGH5BG9QmvJ1B=} 4. Add your encrypted Anypoint Platform password to your `settings.xml` file in the section: ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. In your configuration deployment, reference the credentials injecting the server ID configured in your `settings.xml` file: ```xml ... ... ... my.anypoint.credentials ... ... ... ``` > [!NOTE] Make sure that the username and password are not set in the deployment configuration, > or they will overwrite the defined server ID. ## See Also - [Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) --- product: Runtime Fabric version: 2.10 --- # Deploying Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API Proxies to a Mule runtime engine that is managed on Runtime Fabric. ## Supported Mule Runtime Server Versions See [Anypoint Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) for information on supported versions of Mule runtime server. ## Before You Begin Deploying Mule Apps Before you deploy a Mule app or API proxy to Runtime Fabric: - Install and configure a Runtime Fabric. - Ensure that you understand how resources are allocated as described in [Allocating resources for Application Deployment](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-resource-allocation-self-managed). - Publish your Mule app or API proxy to Exchange. > [!NOTE] Before you deploy Mule apps and API proxies to Runtime Fabric, you must first publish > them to Exchange. When you deploy Mule apps and API proxies from Runtime Manager, they are > published to Exchange automatically. ## Deployment Options Use one of the following options to deploy Mule apps to Runtime Fabric: - [Deploying a Mule App Using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-runtime-fabric) Use Runtime Manager to manually deploy Mule apps and API proxies. - [Deploying Mule Apps to Runtime Fabric using Maven](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-maven-4.x) Use Maven for managing and deploying a Mule application or API proxy. - [Deploying and Managing Apps in Runtime Fabric Using the CLI](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-rtf-cli) Use the Anypoint Platform CLI to deploy Mule applications ## Deployment Considerations ### Eventual consistency Runtime Fabric is a self healing, eventually consistent platform. When building a CI pipeline for Runtime Fabric deployment, you must take eventual consistency into consideration. After triggering a deployment, the application status should become `RUNNING`. If the application status never indicates `RUNNING`, the replicas contain a `state` and `reason` to indicate why the application is not `RUNNING`. ### Application Deployment When an application is deployed, the following events occur: - The expected state of your application is stored, including application bundle and number of replicas. - The application replica status shows as `PENDING`. - When adequate compute and memory resources are available, each replica is attached to a node. - If not already present, a Docker image corresponding to the Mule Runtime version is downloaded. - The replica status shows as `STARTING`. - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. ### Application Failure If an application fails, for example, due to running of out memory, the following events occur: - The replica status shows as `TERMINATED`. - Runtime Fabric immediately attempts to restart the replica. - The replica status shows as `RECOVERING`. - If the replica is able to restart: - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. - If the replica is initially unable to restart, for example, it relies on a network resource which temporarily unavailable, the following events occur: - The replica status shows as `PENDING`, with a message indicating "CrashLoopBackoff". Runtime Fabric attempts to restart the replica, using exponential backoff to avoid an excessive number of restart attempts. - The replica status alternates between `RECOVERING` and `PENDING` until the issue preventing a successful restart is resolved. - The replica loads the application. - After a successful restart, the replica shows as `STARTED` and is able to perform work. ## See Also - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/managing-apps-deployed-runtime-fabric) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.11 --- # Deploying Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API Proxies to a Mule runtime engine that is managed on Runtime Fabric. ## Supported Mule Runtime Server Versions See [Anypoint Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) for information on supported versions of Mule runtime server. ## Before You Begin Deploying Mule Apps Before you deploy a Mule app or API proxy to Runtime Fabric: - Install and configure a Runtime Fabric. - Ensure that you understand how resources are allocated as described in [Allocating resources for Application Deployment](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-resource-allocation-self-managed). - Publish your Mule app or API proxy to Exchange. > [!NOTE] Before you deploy Mule apps and API proxies to Runtime Fabric, you must first publish > them to Exchange. When you deploy Mule apps and API proxies from Runtime Manager, they are > published to Exchange automatically. ## Deployment Options Use one of these options to deploy Mule apps to Runtime Fabric: - [Deploying a Mule App Using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-runtime-fabric) Use Runtime Manager to manually deploy Mule apps and API proxies. - [Deploying a Mule App to Runtime Fabric using Maven (Mule 4)](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-maven-4.x) Use Maven for managing and deploying a Mule application or API proxy. - [Deploying and Managing Apps in Runtime Fabric Using the CLI](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-rtf-cli) Use the Anypoint Platform CLI to deploy Mule applications ## Deployment Considerations ### Eventual consistency Runtime Fabric is a self healing, eventually consistent platform. When building a CI pipeline for Runtime Fabric deployment, you must take eventual consistency into consideration. After triggering a deployment, the application status should become `RUNNING`. If the application status never indicates `RUNNING`, the replicas contain a `state` and `reason` to indicate why the application is not `RUNNING`. ### Application Deployment When an application is deployed, these events occur: - The expected state of your application is stored, including application bundle and number of replicas. - The application replica status shows as `PENDING`. - When adequate compute and memory resources are available, each replica is attached to a node. - If not already present, a Docker image corresponding to the Mule Runtime version is downloaded. - The replica status shows as `STARTING`. - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. ### Application Failure If an application fails, for example, due to running of out memory, these events occur: - The replica status shows as `TERMINATED`. - Runtime Fabric immediately attempts to restart the replica. - The replica status shows as `RECOVERING`. - If the replica is able to restart: - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. - If the replica is initially unable to restart, for example, it relies on a network resource which temporarily unavailable, these events occur: - The replica status shows as `PENDING`, with a message indicating "CrashLoopBackoff". Runtime Fabric attempts to restart the replica, using exponential backoff to avoid an excessive number of restart attempts. - The replica status alternates between `RECOVERING` and `PENDING` until the issue preventing a successful restart is resolved. - The replica loads the application. - After a successful restart, the replica shows as `STARTED` and is able to perform work. ## See Also - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/managing-apps-deployed-runtime-fabric) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.6 --- # Deploying Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API Proxies to a Mule runtime engine that is managed on Runtime Fabric. ## Supported Mule Runtime Server Versions See [Anypoint Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) for information on supported versions of Mule runtime server. ## Before You Begin Deploying Mule Apps Before you deploy a Mule app or API proxy to Runtime Fabric: - Install and configure a Runtime Fabric. - Ensure that you understand how resources are allocated as described in [Allocating resources for Application Deployment](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-resource-allocation-self-managed). - Publish your Mule app or API proxy to Exchange. > [!NOTE] Before you deploy Mule apps and API proxies to Runtime Fabric, you must first publish > them to Exchange. When you deploy Mule apps and API proxies from Runtime Manager, they are > published to Exchange automatically. ## Deployment Options Use one of the following options to deploy Mule apps to Runtime Fabric: - [Deploying a Mule App Using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-runtime-fabric) Use Runtime Manager to manually deploy Mule apps and API proxies. - [Deploying Mule Apps to Runtime Fabric using Maven](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-maven-4.x) Use Maven for managing and deploying a Mule application or API proxy. - [Deploying and Managing Apps in Runtime Fabric Using the CLI](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-rtf-cli) Use the Anypoint Platform CLI to deploy Mule applications ## Deployment Considerations ### Eventual consistency Runtime Fabric is a self healing, eventually consistent platform. When building a CI pipeline for Runtime Fabric deployment, you must take eventual consistency into consideration. After triggering a deployment, the application status should become `RUNNING`. If the application status never indicates `RUNNING`, the replicas contain a `state` and `reason` to indicate why the application is not `RUNNING`. ### Application Deployment When an application is deployed, the following events occur: - The expected state of your application is stored, including application bundle and number of replicas. - The application replica status shows as `PENDING`. - When adequate compute and memory resources are available, each replica is attached to a node. - If not already present, a Docker image corresponding to the Mule Runtime version is downloaded. - The replica status shows as `STARTING`. - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. ### Application Failure If an application fails, for example, due to running of out memory, the following events occur: - The replica status shows as `TERMINATED`. - Runtime Fabric immediately attempts to restart the replica. - The replica status shows as `RECOVERING`. - If the replica is able to restart: - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. - If the replica is initially unable to restart, for example, it relies on a network resource which temporarily unavailable, the following events occur: - The replica status shows as `PENDING`, with a message indicating "CrashLoopBackoff". Runtime Fabric attempts to restart the replica, using exponential backoff to avoid an excessive number of restart attempts. - The replica status alternates between `RECOVERING` and `PENDING` until the issue preventing a successful restart is resolved. - The replica loads the application. - After a successful restart, the replica shows as `STARTED` and is able to perform work. ## See Also - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/managing-apps-deployed-runtime-fabric) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.7 --- # Deploying Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API Proxies to a Mule runtime engine that is managed on Runtime Fabric. ## Supported Mule Runtime Server Versions See [Anypoint Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) for information on supported versions of Mule runtime server. ## Before You Begin Deploying Mule Apps Before you deploy a Mule app or API proxy to Runtime Fabric: - Install and configure a Runtime Fabric. - Ensure that you understand how resources are allocated as described in [Allocating resources for Application Deployment](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-resource-allocation-self-managed). - Publish your Mule app or API proxy to Exchange. > [!NOTE] Before you deploy Mule apps and API proxies to Runtime Fabric, you must first publish > them to Exchange. When you deploy Mule apps and API proxies from Runtime Manager, they are > published to Exchange automatically. ## Deployment Options Use one of the following options to deploy Mule apps to Runtime Fabric: - [Deploying a Mule App Using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-runtime-fabric) Use Runtime Manager to manually deploy Mule apps and API proxies. - [Deploying Mule Apps to Runtime Fabric using Maven](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-maven-4.x) Use Maven for managing and deploying a Mule application or API proxy. - [Deploying and Managing Apps in Runtime Fabric Using the CLI](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-rtf-cli) Use the Anypoint Platform CLI to deploy Mule applications ## Deployment Considerations ### Eventual consistency Runtime Fabric is a self healing, eventually consistent platform. When building a CI pipeline for Runtime Fabric deployment, you must take eventual consistency into consideration. After triggering a deployment, the application status should become `RUNNING`. If the application status never indicates `RUNNING`, the replicas contain a `state` and `reason` to indicate why the application is not `RUNNING`. ### Application Deployment When an application is deployed, the following events occur: - The expected state of your application is stored, including application bundle and number of replicas. - The application replica status shows as `PENDING`. - When adequate compute and memory resources are available, each replica is attached to a node. - If not already present, a Docker image corresponding to the Mule Runtime version is downloaded. - The replica status shows as `STARTING`. - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. ### Application Failure If an application fails, for example, due to running of out memory, the following events occur: - The replica status shows as `TERMINATED`. - Runtime Fabric immediately attempts to restart the replica. - The replica status shows as `RECOVERING`. - If the replica is able to restart: - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. - If the replica is initially unable to restart, for example, it relies on a network resource which temporarily unavailable, the following events occur: - The replica status shows as `PENDING`, with a message indicating "CrashLoopBackoff". Runtime Fabric attempts to restart the replica, using exponential backoff to avoid an excessive number of restart attempts. - The replica status alternates between `RECOVERING` and `PENDING` until the issue preventing a successful restart is resolved. - The replica loads the application. - After a successful restart, the replica shows as `STARTED` and is able to perform work. ## See Also - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/managing-apps-deployed-runtime-fabric) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.8 --- # Deploying Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API Proxies to a Mule runtime engine that is managed on Runtime Fabric. ## Supported Mule Runtime Server Versions See [Anypoint Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) for information on supported versions of Mule runtime server. ## Before You Begin Deploying Mule Apps Before you deploy a Mule app or API proxy to Runtime Fabric: - Install and configure a Runtime Fabric. - Ensure that you understand how resources are allocated as described in [Allocating resources for Application Deployment](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-resource-allocation-self-managed). - Publish your Mule app or API proxy to Exchange. > [!NOTE] Before you deploy Mule apps and API proxies to Runtime Fabric, you must first publish > them to Exchange. When you deploy Mule apps and API proxies from Runtime Manager, they are > published to Exchange automatically. ## Deployment Options Use one of the following options to deploy Mule apps to Runtime Fabric: - [Deploying a Mule App Using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-runtime-fabric) Use Runtime Manager to manually deploy Mule apps and API proxies. - [Deploying Mule Apps to Runtime Fabric using Maven](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-maven-4.x) Use Maven for managing and deploying a Mule application or API proxy. - [Deploying and Managing Apps in Runtime Fabric Using the CLI](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-rtf-cli) Use the Anypoint Platform CLI to deploy Mule applications ## Deployment Considerations ### Eventual consistency Runtime Fabric is a self healing, eventually consistent platform. When building a CI pipeline for Runtime Fabric deployment, you must take eventual consistency into consideration. After triggering a deployment, the application status should become `RUNNING`. If the application status never indicates `RUNNING`, the replicas contain a `state` and `reason` to indicate why the application is not `RUNNING`. ### Application Deployment When an application is deployed, the following events occur: - The expected state of your application is stored, including application bundle and number of replicas. - The application replica status shows as `PENDING`. - When adequate compute and memory resources are available, each replica is attached to a node. - If not already present, a Docker image corresponding to the Mule Runtime version is downloaded. - The replica status shows as `STARTING`. - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. ### Application Failure If an application fails, for example, due to running of out memory, the following events occur: - The replica status shows as `TERMINATED`. - Runtime Fabric immediately attempts to restart the replica. - The replica status shows as `RECOVERING`. - If the replica is able to restart: - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. - If the replica is initially unable to restart, for example, it relies on a network resource which temporarily unavailable, the following events occur: - The replica status shows as `PENDING`, with a message indicating "CrashLoopBackoff". Runtime Fabric attempts to restart the replica, using exponential backoff to avoid an excessive number of restart attempts. - The replica status alternates between `RECOVERING` and `PENDING` until the issue preventing a successful restart is resolved. - The replica loads the application. - After a successful restart, the replica shows as `STARTED` and is able to perform work. ## See Also - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/managing-apps-deployed-runtime-fabric) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.9 --- # Deploying Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API Proxies to a Mule runtime engine that is managed on Runtime Fabric. ## Supported Mule Runtime Server Versions See [Anypoint Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) for information on supported versions of Mule runtime server. ## Before You Begin Deploying Mule Apps Before you deploy a Mule app or API proxy to Runtime Fabric: - Install and configure a Runtime Fabric. - Ensure that you understand how resources are allocated as described in [Allocating resources for Application Deployment](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-resource-allocation-self-managed). - Publish your Mule app or API proxy to Exchange. > [!NOTE] Before you deploy Mule apps and API proxies to Runtime Fabric, you must first publish > them to Exchange. When you deploy Mule apps and API proxies from Runtime Manager, they are > published to Exchange automatically. ## Deployment Options Use one of the following options to deploy Mule apps to Runtime Fabric: - [Deploying a Mule App Using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-runtime-fabric) Use Runtime Manager to manually deploy Mule apps and API proxies. - [Deploying a Mule App to Runtime Fabric using Maven (Mule 4)](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-maven-4.x) Use Maven for managing and deploying a Mule application or API proxy. - [Deploying and Managing Apps in Runtime Fabric Using the CLI](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-rtf-cli) Use the Anypoint Platform CLI to deploy Mule applications ## Deployment Considerations ### Eventual consistency Runtime Fabric is a self healing, eventually consistent platform. When building a CI pipeline for Runtime Fabric deployment, you must take eventual consistency into consideration. After triggering a deployment, the application status should become `RUNNING`. If the application status never indicates `RUNNING`, the replicas contain a `state` and `reason` to indicate why the application is not `RUNNING`. ### Application Deployment When an application is deployed, the following events occur: - The expected state of your application is stored, including application bundle and number of replicas. - The application replica status shows as `PENDING`. - When adequate compute and memory resources are available, each replica is attached to a node. - If not already present, a Docker image corresponding to the Mule Runtime version is downloaded. - The replica status shows as `STARTING`. - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. ### Application Failure If an application fails, for example, due to running of out memory, the following events occur: - The replica status shows as `TERMINATED`. - Runtime Fabric immediately attempts to restart the replica. - The replica status shows as `RECOVERING`. - If the replica is able to restart: - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. - If the replica is initially unable to restart, for example, it relies on a network resource which temporarily unavailable, the following events occur: - The replica status shows as `PENDING`, with a message indicating "CrashLoopBackoff". Runtime Fabric attempts to restart the replica, using exponential backoff to avoid an excessive number of restart attempts. - The replica status alternates between `RECOVERING` and `PENDING` until the issue preventing a successful restart is resolved. - The replica loads the application. - After a successful restart, the replica shows as `STARTED` and is able to perform work. ## See Also - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/managing-apps-deployed-runtime-fabric) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Deploying Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to deploy Mule applications and API Proxies to a Mule runtime engine that is managed on Runtime Fabric. ## Supported Mule Runtime Server Versions See [Anypoint Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) for information on supported versions of Mule runtime server. ## Before You Begin Deploying Mule Apps Before you deploy a Mule app or API proxy to Runtime Fabric: - Install and configure a Runtime Fabric. - Ensure that you understand how resources are allocated as described in [Allocating resources for Application Deployment](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed). - Publish your Mule app or API proxy to Exchange. > [!NOTE] Before you deploy Mule apps and API proxies to Runtime Fabric, you must first publish > them to Exchange. When you deploy Mule apps and API proxies from Runtime Manager, they are > published to Exchange automatically. ## Deployment Options Use one of the following options to deploy Mule apps to Runtime Fabric: - [Deploying a Mule App Using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) Use Runtime Manager to manually deploy Mule apps and API proxies. - [Deploying a Mule App to Runtime Fabric using Maven (Mule 4)](https://docs.mulesoft.com/runtime-fabric/latest/deploy-maven-4.x) Use Maven for managing and deploying a Mule application or API proxy. - [Deploying and Managing Apps in Runtime Fabric Using the CLI](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-rtf-cli) Use the Anypoint Platform CLI to deploy Mule applications ## Deployment Considerations ### Eventual consistency Runtime Fabric is a self healing, eventually consistent platform. When building a CI pipeline for Runtime Fabric deployment, you must take eventual consistency into consideration. After triggering a deployment, the application status should become `RUNNING`. If the application status never indicates `RUNNING`, the replicas contain a `state` and `reason` to indicate why the application is not `RUNNING`. ### Application Deployment When an application is deployed, the following events occur: - The expected state of your application is stored, including application bundle and number of replicas. - The application replica status shows as `PENDING`. - When adequate compute and memory resources are available, each replica is attached to a node. - If not already present, a Docker image corresponding to the Mule Runtime version is downloaded. - The replica status shows as `STARTING`. - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. ### Exchange Asset Caching When you deploy a Mule application, the runtime environment caches the application artifact using a key derived from its Maven coordinates: `groupId`, `artifactId`, and `version`. This cache improves deployment performance by avoiding redundant downloads from Exchange. However, if you delete an Exchange asset and re-publish it under the same version (for example, `1.0.0`), the cache has no visibility into whether the underlying artifact content has changed. As a result, deployments continue to use the previously cached artifact until that cache entry is evicted. > [!IMPORTANT] Re-publishing an Exchange asset under the same `groupId:artifactId:version` > coordinates doesn’t update cached artifacts on existing deployment targets. Deployments on those > targets continue to use the previously cached version. To ensure that updated application artifacts are deployed correctly, use one of these approaches: - Increment the version number Even a patch-level version bump (for example, from `1.0.0` to `1.0.1`) produces a distinct cache key, ensuring the runtime fetches and caches the new artifact from Exchange. - Use the `-SNAPSHOT` qualifier Appending `-SNAPSHOT` to the version (for example, `1.0.0-SNAPSHOT`) signals that the artifact is mutable. The resource cache treats `SNAPSHOT` versions as non-cacheable and fetches directly from Exchange on every deployment. This approach is recommended during active development iterations. ### Application Failure If an application fails, for example, due to running of out memory, the following events occur: - The replica status shows as `TERMINATED`. - Runtime Fabric immediately attempts to restart the replica. - The replica status shows as `RECOVERING`. - If the replica is able to restart: - The replica finishes loading the application. - The replica status shows as `STARTED` and is able to perform work. - If the replica is initially unable to restart, for example, it relies on a network resource which temporarily unavailable, the following events occur: - The replica status shows as `PENDING`, with a message indicating "CrashLoopBackoff". Runtime Fabric attempts to restart the replica, using exponential backoff to avoid an excessive number of restart attempts. - The replica status alternates between `RECOVERING` and `PENDING` until the issue preventing a successful restart is resolved. - The replica loads the application. - After a successful restart, the replica shows as `STARTED` and is able to perform work. ## See Also - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/managing-apps-deployed-runtime-fabric) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.10 --- # Deploying Mule Apps to Runtime Fabric Using Anypoint CLI > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these Anypoint Platform CLI commands for deploying and managing applications in Runtime Fabric. The CLI supports both the interactive shell and standard CLI modes. Runtime Fabric currently supports only Anypoint CLI version 3.x. Before you get started, review [Anypoint CLI prerequisites, installation, and authentication instructions](https://docs.mulesoft.com/anypoint-cli/3.x/). > [!NOTE] Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term > Support (LTS). The Mule runtime versioning schema for the new release channels is: > > _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, > nothing for LTS\]_ > > Some examples of these values are: `4.5.0:1e` for Edge, and `4.6.0:1` for LTS.
CommandDescription

Deletes an application

Deploys an application to a specified target using an Exchange application and runs the specified runtime version

Describes an application

Describes an application in a raw JSON response

Downloads logs of an application from a specification to a specified directory

Lists all applications in an organization

Modifies a deployed application

Starts a stopped application

Stops running an application

Tails an application’s logs from a specification

## runtime-mgr application delete \> runtime-mgr application delete \[options\] Deletes the running application specified in ``. To get this ID, run the `runtime-mgr application list` command. > [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction, > it does not ask for confirmation. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application deploy \> runtime-mgr application deploy \[options\] Deploys the application specified in `` to the deployment target specified using the following options:
ValueDescriptionExample

ArtifactId

Artifact ID of the application retrieved from Exchange.

mule-test-plugin

deploymentTargetID

ID of the deployment target.
You can get this ID directly from Runtime Manager.

app.runetime

name

Name of the application to deploy.

testCloudhub2app

runtimeVersion

Runtime version of the deployment target.

1.0.1

Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default:.disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID

org.mule.test

javaVersion

Set the name of the JAVA version to be used for the selected Mule version. Supported values are 8 and 17. If you do not specify a value, Runtime Fabric imposes the default value. The default JAVA version for Mule 4.6 and earlier versions is '8'. If you don’t specify a Mule version, the default Mule version for the selected JAVA version is used. If the JAVA version you select is not available for the specified Mule version, you get an error.

8

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

memory

The amount of memory allocated to each replica of a Mule application or API gateway.

0.7

objectStoreV2

Enables Object Store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example:/status?limit=10

releaseChannel

Set the name of the release channel to be used for the selected Mule version. Supported values are NONE, EDGE, and LTS. If you do not specify a value, Runtime Fabric imposes the default value. The default release channel is EDGE. If you don’t specify a Mule version, the default Mule version for the selected release channel is used. If the selected release channel doesn’t exist, you get an error.

EDGE

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

reservedCPU

The amount of vCPU guaranteed to the application and reserved for its use.

0.02

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: one tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

vCPULimit

The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node.

3.9

## runtime-mgr application describe \> runtime-mgr application describe \[options\] Displays information about the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] Displays a raw JSON response from the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] Downloads logs for the application specified in `` from the specification specified in `` to the selected directory. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application list \> runtime-mgr application list \[options\] Lists all applications in your organization. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application modify \> runtime-mgr application modify \[options\] Updates the settings of an existing application specified in ``. To get the ``, run the `runtime-mgr application list` command. Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

ArtifactId

ID of the application retrieved from Exchange.

mule-maven-plugin

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default: disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID.

org.mule.testgroup

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

objectStoreV2

Enables object store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000.

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example: /status?limit=10

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

runtimeVersion

Runtime version of the deployment target.

1.0.1

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: 1 tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

## runtime-mgr application start \> runtime-mgr application start \[options\] Starts running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application stop \> runtime-mgr application stop \[options\] Stops running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] Tails application logs for the application specificied in `` from the specification specified in ``. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default option `--help`. ## runtime-mgr rtf list \> runtime-mgr rtf list \[options\] This command lists available Runtime Fabric instances. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output`. For information about managing your Runtime Fabric instances using the command line, see [Supported rtfctl Commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands). --- product: Runtime Fabric version: 2.11 --- # Deploying Mule Apps to Runtime Fabric Using Anypoint CLI > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these Anypoint Platform CLI commands for deploying and managing applications in Runtime Fabric. The CLI supports both the interactive shell and standard CLI modes. Runtime Fabric currently supports only Anypoint CLI version 3.x. Before you get started, review [Anypoint CLI prerequisites, installation, and authentication instructions](https://docs.mulesoft.com/anypoint-cli/3.x/). > [!NOTE] Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term > Support (LTS). The Mule runtime versioning schema for the new release channels is: > > _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, > nothing for LTS\]_ > > Some examples of these values are: `4.5.0:1e` for Edge, and `4.6.0:1` for LTS.
CommandDescription

Deletes an application

Deploys an application to a specified target using an Exchange application and runs the specified runtime version

Describes an application

Describes an application in a raw JSON response

Downloads logs of an application from a specification to a specified directory

Lists all applications in an organization

Modifies a deployed application

Starts a stopped application

Stops running an application

Tails an application’s logs from a specification

## runtime-mgr application delete \> runtime-mgr application delete \[options\] Deletes the running application specified in ``. To get this ID, run the `runtime-mgr application list` command. > [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction, > it does not ask for confirmation. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application deploy \> runtime-mgr application deploy \[options\] Deploys the application specified in `` to the deployment target specified using the following options:
ValueDescriptionExample

ArtifactId

Artifact ID of the application retrieved from Exchange.

mule-test-plugin

deploymentTargetID

ID of the deployment target.
You can get this ID directly from Runtime Manager.

app.runetime

name

Name of the application to deploy.

testCloudhub2app

runtimeVersion

Runtime version of the deployment target.

1.0.1

Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default:.disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID

org.mule.test

javaVersion

Set the name of the JAVA version to be used for the selected Mule version. Supported values are 8 and 17. If you do not specify a value, Runtime Fabric imposes the default value. The default JAVA version for Mule 4.6 and earlier versions is '8'. If you don’t specify a Mule version, the default Mule version for the selected JAVA version is used. If the JAVA version you select is not available for the specified Mule version, you get an error.

8

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

memory

The amount of memory allocated to each replica of a Mule application or API gateway.

0.7

objectStoreV2

Enables Object Store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example:/status?limit=10

releaseChannel

Set the name of the release channel to be used for the selected Mule version. Supported values are NONE, EDGE, and LTS. If you do not specify a value, Runtime Fabric imposes the default value. The default release channel is EDGE. If you don’t specify a Mule version, the default Mule version for the selected release channel is used. If the selected release channel doesn’t exist, you get an error.

EDGE

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

reservedCPU

The amount of vCPU guaranteed to the application and reserved for its use.

0.02

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: one tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

vCPULimit

The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node.

3.9

## runtime-mgr application describe \> runtime-mgr application describe \[options\] Displays information about the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] Displays a raw JSON response from the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] Downloads logs for the application specified in `` from the specification specified in `` to the selected directory. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application list \> runtime-mgr application list \[options\] Lists all applications in your organization. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application modify \> runtime-mgr application modify \[options\] Updates the settings of an existing application specified in ``. To get the ``, run the `runtime-mgr application list` command. Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

ArtifactId

ID of the application retrieved from Exchange.

mule-maven-plugin

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default: disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID.

org.mule.testgroup

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

objectStoreV2

Enables object store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000.

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example: /status?limit=10

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

runtimeVersion

Runtime version of the deployment target.

1.0.1

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: 1 tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

## runtime-mgr application start \> runtime-mgr application start \[options\] Starts running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application stop \> runtime-mgr application stop \[options\] Stops running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] Tails application logs for the application specificied in `` from the specification specified in ``. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default option `--help`. ## runtime-mgr rtf list \> runtime-mgr rtf list \[options\] This command lists available Runtime Fabric instances. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output`. For information about managing your Runtime Fabric instances using the command line, see [Supported rtfctl Commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands). --- product: Runtime Fabric version: 2.6 --- # Deploying Mule Apps to Runtime Fabric Using Anypoint CLI > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these Anypoint Platform CLI commands for deploying and managing applications in Runtime Fabric. The CLI supports both the interactive shell and standard CLI modes. Runtime Fabric currently supports only Anypoint CLI version 3.x. Before you get started, review [Anypoint CLI prerequisites, installation, and authentication instructions](https://docs.mulesoft.com/anypoint-cli/3.x/). > [!NOTE] Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term > Support (LTS). The Mule runtime versioning schema for the new release channels is: > > _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, > nothing for LTS\]_ > > Some examples of these values are: `4.5.0:1e` for Edge, and `4.6.0:1` for LTS.
CommandDescription

Deletes an application

Deploys an application to a specified target using an Exchange application and runs the specified runtime version

Describes an application

Describes an application in a raw JSON response

Downloads logs of an application from a specification to a specified directory

Lists all applications in an organization

Modifies a deployed application

Starts a stopped application

Stops running an application

Tails an application’s logs from a specification

## runtime-mgr application delete \> runtime-mgr application delete \[options\] Deletes the running application specified in ``. To get this ID, run the `runtime-mgr application list` command. > [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction, > it does not ask for confirmation. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application deploy \> runtime-mgr application deploy \[options\] Deploys the application specified in `` to the deployment target specified using the following options:
ValueDescriptionExample

ArtifactId

Artifact ID of the application retrieved from Exchange.

mule-test-plugin

deploymentTargetID

ID of the deployment target.
You can get this ID directly from Runtime Manager.

app.runetime

name

Name of the application to deploy.

testCloudhub2app

runtimeVersion

Runtime version of the deployment target.

1.0.1

Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default:.disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID

org.mule.test

javaVersion

Set the name of the JAVA version to be used for the selected Mule version. Supported values are 8 and 17. If you do not specify a value, Runtime Fabric imposes the default value. The default JAVA version for Mule 4.6 and earlier versions is '8'. If you don’t specify a Mule version, the default Mule version for the selected JAVA version is used. If the JAVA version you select is not available for the specified Mule version, you get an error.

8

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

memory

The amount of memory allocated to each replica of a Mule application or API gateway.

0.7

objectStoreV2

Enables Object Store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example:/status?limit=10

releaseChannel

Set the name of the release channel to be used for the selected Mule version. Supported values are NONE, EDGE, and LTS. If you do not specify a value, Runtime Fabric imposes the default value. The default release channel is EDGE. If you don’t specify a Mule version, the default Mule version for the selected release channel is used. If the selected release channel doesn’t exist, you get an error.

EDGE

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

reservedCPU

The amount of vCPU guaranteed to the application and reserved for its use.

0.02

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: one tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

vCPULimit

The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node.

3.9

## runtime-mgr application describe \> runtime-mgr application describe \[options\] Displays information about the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] Displays a raw JSON response from the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] Downloads logs for the application specified in `` from the specification specified in `` to the selected directory. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application list \> runtime-mgr application list \[options\] Lists all applications in your organization. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application modify \> runtime-mgr application modify \[options\] Updates the settings of an existing application specified in ``. To get the ``, run the `runtime-mgr application list` command. Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

ArtifactId

ID of the application retrieved from Exchange.

mule-maven-plugin

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default: disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID.

org.mule.testgroup

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

objectStoreV2

Enables object store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000.

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example: /status?limit=10

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

runtimeVersion

Runtime version of the deployment target.

1.0.1

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: 1 tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

## runtime-mgr application start \> runtime-mgr application start \[options\] Starts running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application stop \> runtime-mgr application stop \[options\] Stops running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] Tails application logs for the application specificied in `` from the specification specified in ``. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default option `--help`. ## runtime-mgr rtf list \> runtime-mgr rtf list \[options\] This command lists available Runtime Fabric instances. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output`. For information about managing your Runtime Fabric instances using the command line, see [Supported rtfctl Commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands). --- product: Runtime Fabric version: 2.7 --- # Deploying Mule Apps to Runtime Fabric Using Anypoint CLI > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these Anypoint Platform CLI commands for deploying and managing applications in Runtime Fabric. The CLI supports both the interactive shell and standard CLI modes. Runtime Fabric currently supports only Anypoint CLI version 3.x. Before you get started, review [Anypoint CLI prerequisites, installation, and authentication instructions](https://docs.mulesoft.com/anypoint-cli/3.x/). > [!NOTE] Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term > Support (LTS). The Mule runtime versioning schema for the new release channels is: > > _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, > nothing for LTS\]_ > > Some examples of these values are: `4.5.0:1e` for Edge, and `4.6.0:1` for LTS.
CommandDescription

Deletes an application

Deploys an application to a specified target using an Exchange application and runs the specified runtime version

Describes an application

Describes an application in a raw JSON response

Downloads logs of an application from a specification to a specified directory

Lists all applications in an organization

Modifies a deployed application

Starts a stopped application

Stops running an application

Tails an application’s logs from a specification

## runtime-mgr application delete \> runtime-mgr application delete \[options\] Deletes the running application specified in ``. To get this ID, run the `runtime-mgr application list` command. > [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction, > it does not ask for confirmation. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application deploy \> runtime-mgr application deploy \[options\] Deploys the application specified in `` to the deployment target specified using the following options:
ValueDescriptionExample

ArtifactId

Artifact ID of the application retrieved from Exchange.

mule-test-plugin

deploymentTargetID

ID of the deployment target.
You can get this ID directly from Runtime Manager.

app.runetime

name

Name of the application to deploy.

testCloudhub2app

runtimeVersion

Runtime version of the deployment target.

1.0.1

Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default:.disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID

org.mule.test

javaVersion

Set the name of the JAVA version to be used for the selected Mule version. Supported values are 8 and 17. If you do not specify a value, Runtime Fabric imposes the default value. The default JAVA version for Mule 4.6 and earlier versions is '8'. If you don’t specify a Mule version, the default Mule version for the selected JAVA version is used. If the JAVA version you select is not available for the specified Mule version, you get an error.

8

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

memory

The amount of memory allocated to each replica of a Mule application or API gateway.

0.7

objectStoreV2

Enables Object Store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example:/status?limit=10

releaseChannel

Set the name of the release channel to be used for the selected Mule version. Supported values are NONE, EDGE, and LTS. If you do not specify a value, Runtime Fabric imposes the default value. The default release channel is EDGE. If you don’t specify a Mule version, the default Mule version for the selected release channel is used. If the selected release channel doesn’t exist, you get an error.

EDGE

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

reservedCPU

The amount of vCPU guaranteed to the application and reserved for its use.

0.02

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: one tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

vCPULimit

The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node.

3.9

## runtime-mgr application describe \> runtime-mgr application describe \[options\] Displays information about the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] Displays a raw JSON response from the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] Downloads logs for the application specified in `` from the specification specified in `` to the selected directory. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application list \> runtime-mgr application list \[options\] Lists all applications in your organization. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application modify \> runtime-mgr application modify \[options\] Updates the settings of an existing application specified in ``. To get the ``, run the `runtime-mgr application list` command. Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

ArtifactId

ID of the application retrieved from Exchange.

mule-maven-plugin

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default: disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID.

org.mule.testgroup

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

objectStoreV2

Enables object store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000.

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example: /status?limit=10

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

runtimeVersion

Runtime version of the deployment target.

1.0.1

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: 1 tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

## runtime-mgr application start \> runtime-mgr application start \[options\] Starts running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application stop \> runtime-mgr application stop \[options\] Stops running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] Tails application logs for the application specificied in `` from the specification specified in ``. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default option `--help`. ## runtime-mgr rtf list \> runtime-mgr rtf list \[options\] This command lists available Runtime Fabric instances. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output`. For information about managing your Runtime Fabric instances using the command line, see [Supported rtfctl Commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands). --- product: Runtime Fabric version: 2.8 --- # Deploying Mule Apps to Runtime Fabric Using Anypoint CLI > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these Anypoint Platform CLI commands for deploying and managing applications in Runtime Fabric. The CLI supports both the interactive shell and standard CLI modes. Runtime Fabric currently supports only Anypoint CLI version 3.x. Before you get started, review [Anypoint CLI prerequisites, installation, and authentication instructions](https://docs.mulesoft.com/anypoint-cli/3.x/). > [!NOTE] Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term > Support (LTS). The Mule runtime versioning schema for the new release channels is: > > _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, > nothing for LTS\]_ > > Some examples of these values are: `4.5.0:1e` for Edge, and `4.6.0:1` for LTS.
CommandDescription

Deletes an application

Deploys an application to a specified target using an Exchange application and runs the specified runtime version

Describes an application

Describes an application in a raw JSON response

Downloads logs of an application from a specification to a specified directory

Lists all applications in an organization

Modifies a deployed application

Starts a stopped application

Stops running an application

Tails an application’s logs from a specification

## runtime-mgr application delete \> runtime-mgr application delete \[options\] Deletes the running application specified in ``. To get this ID, run the `runtime-mgr application list` command. > [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction, > it does not ask for confirmation. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application deploy \> runtime-mgr application deploy \[options\] Deploys the application specified in `` to the deployment target specified using the following options:
ValueDescriptionExample

ArtifactId

Artifact ID of the application retrieved from Exchange.

mule-test-plugin

deploymentTargetID

ID of the deployment target.
You can get this ID directly from Runtime Manager.

app.runetime

name

Name of the application to deploy.

testCloudhub2app

runtimeVersion

Runtime version of the deployment target.

1.0.1

Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default:.disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID

org.mule.test

javaVersion

Set the name of the JAVA version to be used for the selected Mule version. Supported values are 8 and 17. If you do not specify a value, Runtime Fabric imposes the default value. The default JAVA version for Mule 4.6 and earlier versions is '8'. If you don’t specify a Mule version, the default Mule version for the selected JAVA version is used. If the JAVA version you select is not available for the specified Mule version, you get an error.

8

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

memory

The amount of memory allocated to each replica of a Mule application or API gateway.

0.7

objectStoreV2

Enables Object Store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example:/status?limit=10

releaseChannel

Set the name of the release channel to be used for the selected Mule version. Supported values are NONE, EDGE, and LTS. If you do not specify a value, Runtime Fabric imposes the default value. The default release channel is EDGE. If you don’t specify a Mule version, the default Mule version for the selected release channel is used. If the selected release channel doesn’t exist, you get an error.

EDGE

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

reservedCPU

The amount of vCPU guaranteed to the application and reserved for its use.

0.02

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: one tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

vCPULimit

The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node.

3.9

## runtime-mgr application describe \> runtime-mgr application describe \[options\] Displays information about the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] Displays a raw JSON response from the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] Downloads logs for the application specified in `` from the specification specified in `` to the selected directory. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application list \> runtime-mgr application list \[options\] Lists all applications in your organization. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application modify \> runtime-mgr application modify \[options\] Updates the settings of an existing application specified in ``. To get the ``, run the `runtime-mgr application list` command. Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

ArtifactId

ID of the application retrieved from Exchange.

mule-maven-plugin

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default: disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID.

org.mule.testgroup

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

objectStoreV2

Enables object store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000.

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example: /status?limit=10

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

runtimeVersion

Runtime version of the deployment target.

1.0.1

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: 1 tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

## runtime-mgr application start \> runtime-mgr application start \[options\] Starts running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application stop \> runtime-mgr application stop \[options\] Stops running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] Tails application logs for the application specificied in `` from the specification specified in ``. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default option `--help`. ## runtime-mgr rtf list \> runtime-mgr rtf list \[options\] This command lists available Runtime Fabric instances. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output`. For information about managing your Runtime Fabric instances using the command line, see [Supported rtfctl Commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands). --- product: Runtime Fabric version: 2.9 --- # Deploying Mule Apps to Runtime Fabric Using Anypoint CLI > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these Anypoint Platform CLI commands for deploying and managing applications in Runtime Fabric. The CLI supports both the interactive shell and standard CLI modes. Runtime Fabric currently supports only Anypoint CLI version 3.x. Before you get started, review [Anypoint CLI prerequisites, installation, and authentication instructions](https://docs.mulesoft.com/anypoint-cli/3.x/). > [!NOTE] Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term > Support (LTS). The Mule runtime versioning schema for the new release channels is: > > _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, > nothing for LTS\]_ > > Some examples of these values are: `4.5.0:1e` for Edge, and `4.6.0:1` for LTS.
CommandDescription

Deletes an application

Deploys an application to a specified target using an Exchange application and runs the specified runtime version

Describes an application

Describes an application in a raw JSON response

Downloads logs of an application from a specification to a specified directory

Lists all applications in an organization

Modifies a deployed application

Starts a stopped application

Stops running an application

Tails an application’s logs from a specification

## runtime-mgr application delete \> runtime-mgr application delete \[options\] Deletes the running application specified in ``. To get this ID, run the `runtime-mgr application list` command. > [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction, > it does not ask for confirmation. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application deploy \> runtime-mgr application deploy \[options\] Deploys the application specified in `` to the deployment target specified using the following options:
ValueDescriptionExample

ArtifactId

Artifact ID of the application retrieved from Exchange.

mule-test-plugin

deploymentTargetID

ID of the deployment target.
You can get this ID directly from Runtime Manager.

app.runetime

name

Name of the application to deploy.

testCloudhub2app

runtimeVersion

Runtime version of the deployment target.

1.0.1

Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default:.disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID

org.mule.test

javaVersion

Set the name of the JAVA version to be used for the selected Mule version. Supported values are 8 and 17. If you do not specify a value, Runtime Fabric imposes the default value. The default JAVA version for Mule 4.6 and earlier versions is '8'. If you don’t specify a Mule version, the default Mule version for the selected JAVA version is used. If the JAVA version you select is not available for the specified Mule version, you get an error.

8

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

memory

The amount of memory allocated to each replica of a Mule application or API gateway.

0.7

objectStoreV2

Enables Object Store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example:/status?limit=10

releaseChannel

Set the name of the release channel to be used for the selected Mule version. Supported values are NONE, EDGE, and LTS. If you do not specify a value, Runtime Fabric imposes the default value. The default release channel is EDGE. If you don’t specify a Mule version, the default Mule version for the selected release channel is used. If the selected release channel doesn’t exist, you get an error.

EDGE

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

reservedCPU

The amount of vCPU guaranteed to the application and reserved for its use.

0.02

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: one tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

vCPULimit

The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node.

3.9

## runtime-mgr application describe \> runtime-mgr application describe \[options\] Displays information about the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] Displays a raw JSON response from the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] Downloads logs for the application specified in `` from the specification specified in `` to the selected directory. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application list \> runtime-mgr application list \[options\] Lists all applications in your organization. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application modify \> runtime-mgr application modify \[options\] Updates the settings of an existing application specified in ``. To get the ``, run the `runtime-mgr application list` command. Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

ArtifactId

ID of the application retrieved from Exchange.

mule-maven-plugin

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default: disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID.

org.mule.testgroup

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

objectStoreV2

Enables object store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000.

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example: /status?limit=10

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

runtimeVersion

Runtime version of the deployment target.

1.0.1

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: 1 tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

## runtime-mgr application start \> runtime-mgr application start \[options\] Starts running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application stop \> runtime-mgr application stop \[options\] Stops running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] Tails application logs for the application specificied in `` from the specification specified in ``. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default option `--help`. ## runtime-mgr rtf list \> runtime-mgr rtf list \[options\] This command lists available Runtime Fabric instances. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output`. For information about managing your Runtime Fabric instances using the command line, see [Supported rtfctl Commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands). --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Deploying Mule Apps to Runtime Fabric Using Anypoint CLI > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these Anypoint Platform CLI commands for deploying and managing applications in Runtime Fabric. The CLI supports both the interactive shell and standard CLI modes. Runtime Fabric currently supports only Anypoint CLI version 3.x. Before you get started, review [Anypoint CLI prerequisites, installation, and authentication instructions](https://docs.mulesoft.com/anypoint-cli/3.x/). > [!NOTE] Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term > Support (LTS). The Mule runtime versioning schema for the new release channels is: > > _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, > nothing for LTS\]_ > > Some examples of these values are: `4.5.0:1e` for Edge, and `4.6.0:1` for LTS.
CommandDescription

Deletes an application

Deploys an application to a specified target using an Exchange application and runs the specified runtime version

Describes an application

Describes an application in a raw JSON response

Downloads logs of an application from a specification to a specified directory

Lists all applications in an organization

Modifies a deployed application

Starts a stopped application

Stops running an application

Tails an application’s logs from a specification

## runtime-mgr application delete \> runtime-mgr application delete \[options\] Deletes the running application specified in ``. To get this ID, run the `runtime-mgr application list` command. > [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction, > it does not ask for confirmation. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application deploy \> runtime-mgr application deploy \[options\] Deploys the application specified in `` to the deployment target specified using the following options:
ValueDescriptionExample

ArtifactId

Artifact ID of the application retrieved from Exchange.

mule-test-plugin

deploymentTargetID

ID of the deployment target.
You can get this ID directly from Runtime Manager.

app.runetime

name

Name of the application to deploy.

testCloudhub2app

runtimeVersion

Runtime version of the deployment target.

1.0.1

Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default:.disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID

org.mule.test

javaVersion

Set the name of the JAVA version to be used for the selected Mule version. Supported values are 8 and 17. If you do not specify a value, Runtime Fabric imposes the default value. The default JAVA version for Mule 4.6 and earlier versions is '8'. If you don’t specify a Mule version, the default Mule version for the selected JAVA version is used. If the JAVA version you select is not available for the specified Mule version, you get an error.

8

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

memory

The amount of memory allocated to each replica of a Mule application or API gateway.

0.7

objectStoreV2

Enables Object Store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example:/status?limit=10

releaseChannel

Set the name of the release channel to be used for the selected Mule version. Supported values are NONE, EDGE, and LTS. If you do not specify a value, Runtime Fabric imposes the default value. The default release channel is EDGE. If you don’t specify a Mule version, the default Mule version for the selected release channel is used. If the selected release channel doesn’t exist, you get an error.

EDGE

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

reservedCPU

The amount of vCPU guaranteed to the application and reserved for its use.

0.02

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: one tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

vCPULimit

The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node.

3.9

## runtime-mgr application describe \> runtime-mgr application describe \[options\] Displays information about the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] Displays a raw JSON response from the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] Downloads logs for the application specified in `` from the specification specified in `` to the selected directory. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application list \> runtime-mgr application list \[options\] Lists all applications in your organization. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output` ## runtime-mgr application modify \> runtime-mgr application modify \[options\] Updates the settings of an existing application specified in ``. To get the ``, run the `runtime-mgr application list` command. Besides the default `--help`, `-f`/`--fields` and `-o`/`--output` options, this command also takes these options:
ValueDescriptionExample

ArtifactId

ID of the application retrieved from Exchange.

mule-maven-plugin

assetVersion

Version of the Exchange application to use.
Default: latest application version

2.0.4

clustered

Enables clustered nodes, which requires at least two replicas.
Default: disabled
Supported values: true, false

false

disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled
Supported values: true, false

true

forwardSslSession

Enables SSL session forwarding.
Default: disabled
Values: true, false

false

groupID

Group ID of the asset to deploy.
Default: selected organization ID.

org.mule.testgroup

lastMileSecurity

Enables Last Mile Security.
Default: disabled
Supported values: true, false

true

objectStoreV2

Enables object store v2.
Default: disabled
Supported values: true, false

true

pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

/http://localhost:3000.

property

Sets a property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--property "gcp.privateKey:dGVzdA\=\="

propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

/Users/mule/Documents/properties.txt

publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

my-superapp-example: /status?limit=10

replicas

Number of replicas. Must be above 0.
Default: 1

2

replicaSize

Size of replicas in Vcores.
Default: 0.1

0.5

runtimeVersion

Runtime version of the deployment target.

1.0.1

scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: 1 tupple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

/Users/mule/Documents/cert.txt

secureProperty

Sets a secure property.
Format: name:value. Can be specified multiple times.
Enclose the property in quotes and escape the : and = characters.

--secureProperty "gcp.privateKey:dGVzdA\=\="

updateStrategy

Updates the strategy used.
Default: rolling

recreate

## runtime-mgr application start \> runtime-mgr application start \[options\] Starts running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application stop \> runtime-mgr application stop \[options\] Stops running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts only the default option `--help`. ## runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] Tails application logs for the application specificied in `` from the specification specified in ``. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts only the default option `--help`. ## runtime-mgr rtf list \> runtime-mgr rtf list \[options\] This command lists available Runtime Fabric instances. This command accepts only the default options: `--help`, `-f`/`--fields` and `-o`/`--output`. For information about managing your Runtime Fabric instances using the command line, see [Supported rtfctl Commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands). --- product: Runtime Fabric version: 2.10 --- # Deploying Mule Apps to Runtime Fabric using Maven > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric supports using Mule Maven Plugin 3.x to manage and deploy Mule applications. The information in this topic is specific to deploying a Mule application to Mule runtime engine 4.x. ## Prerequisites - Ensure that the Mule Maven Plugin is added to your project See [Add the Mule Maven Plugin to a Mule Project](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp) for instructions. - You understand and have available the number of resources required to deploy to Runtime Fabric See [Resource Allocation on Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) for more information. - The application is already published in Exchange See [Publish and Deploy Exchange Assets Using Maven](https://docs.mulesoft.com/exchange/to-publish-assets-maven). The Mule Maven Facade API (v3) is added as a repository in the distribution management section of your project’s POM file. For example: Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION\_ID/maven default If you publish assets using Exchange API, use Exchange API v2, otherwise schedulers aren’t displayed. ## Add the Mule Maven Plugin to a Mule Project To add the Mule Maven plugin, you need to add its maven dependency to the project: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` From this repository: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` This enables the Mule Maven plugin in your project. > [!IMPORTANT] If `true` is not present, the plugin does not work. ## Configure the Runtime Fabric Deployment Strategy Inside the `plugin` element, add a configuration for your Runtime Fabric deployment, replacing the following placeholder values with your Runtime Fabric information: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## Deploy to Runtime Fabric From the command line in your project’s folder, package the application and execute the deploy goal: ```bash mvn clean deploy -DmuleDeploy ``` ### Exchange Snapshot Assets You can also deploy Exchange snapshot assets into Runtime Fabric. By using `SNAPSHOT` version assets in Anypoint Exchange during the development and testing phase, you can avoid incrementing your application’s version number for small changes. After your `SNAPSHOT` version application has been overwritten in Anypoint Exchange, you can redeploy your `SNAPSHOT` version application to Runtime Fabric via the Mule Maven plugin to deploy the latest changes. To learn more about publishing snapshot assets to Anypoint Exchange, see [Asset Lifecycle State](https://docs.mulesoft.com/exchange/to-publish-assets-maven#asset-lifecycle-state). > [!NOTE] Each time you update your application’s snapshot, redeploy the application to refresh it > with the latest snapshot binaries. > > Because snapshot assets can change after deployment, avoid deploying them into your production > environment. ## Redeploy to Runtime Fabric To redeploy the application, run the same command as you did to deploy. Runtime Fabric rewrites the application you had deployed. ## Authentication Methods When you deploy applications using Mule Maven plugin, you can use different methods to provide your credentials to authenticate against the deployment platform. Depending on the authentication method you use, the parameters to set in the deployment configuration differ:
Authentication MethodDescriptionConfiguration Parameters

Username and password

Use a Runtime Fabric username and password to authenticate.

  • username

  • password

Server

Use credentials stored in a Maven server, configured inside the Maven settings.xml file.

  • server

Authorization Token

Use an authorization token to access the platform.
See Identity Management for a list of supported single sign-on (SSO) types.

  • authToken

Connected Apps

Use a Connected App to perform the authentication programmatically by communicating with Anypoint Platform.
Note that the Connected App credentials must have the Design Center Developer access scope.
See Connected Apps for Developers for instructions about creating Connected Apps.

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType

For a detailed description of the configuration parameters, see the [Runtime Fabric Deployment Parameters Reference](#rtf-deploy-reference). ## Runtime Fabric Deployment Parameters Reference
ParameterDescriptionRequired

runtimeFabricDeployment

Top-Level Element

Yes

uri

Your Anypoint Platform URI.
If not set, defaults to https://anypoint.mulesoft.com.

No

muleVersion

The Mule runtime engine version to run in your Runtime Fabric instance.
Ensure that this value is equal to or higher than the earliest required Mule version of your application. By default, the latest available Mule version is selected.
Example values: 4.6.0 selects the last build where it defaults to Edge channel and Java 8. If you want to choose a different LTS or Edge selection or Java version, specify the full Mule version name as in 4.6.0:1e-java17.
When using Mule Maven plugin versions 3.8.0 and 4.0.0 for deployments, the muleVersion property doesn’t allow you to specify releaseChannel and javaVersion. To specify these properties, upgrade the plugin to version 4.1.1 or later.

No

releaseChannel

Set the name of the release channel used to select the Mule image. Supported values are NONE, EDGE, and LTS. By default, the value is set to EDGE. If the selected release channel doesn’t exist, an error occurs.

No

javaVersion

Set the Java version used in the deploy. Supported values are 8 and 17. By default, the value is set to 8. If the selected Java version doesn’t exist, an error occurs.

No

username

Your Anypoint Platform username

Only when using Anypoint Platform credentials to login.

password

Your Anypoint Platform password

Only when using Anypoint Platform credentials to login.

applicationName

The application name displayed in Runtime Manager after the app deploys.

Yes

target

The Runtime Fabric target name where to deploy the app.

Yes

provider

Provider MC (MuleSoft Control Plane) indicates that the deployment is managed through Anypoint Runtime Manager. Set to MC for Runtime Fabric.

Yes

environment

Target Anypoint Platform environment.
This value must match an environment configured in your Anypoint Platform account, as shown here:

<environment>Sandbox</environment>

Yes

replicas

Specifies the number of replicas, or instances, of the Mule application to deploy. The maximum number of replicas per application is 16.

Only when autoscaling is set to false.

businessGroup

The Business group path of the deployment
Specify the full hierarchical path from the parent organization to the target Business group, for example:

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

This value is omitted if businessGroupId is set. If businessGroup and businessGroupId are not set, the value defaults to the main business group of the user.

No

businessGroupId

The Business group ID of the deployment
Instead of specifying the Business group path, you can specify the Business group ID to deploy your application. If businessGroupId and businessGroup are not set, the value defaults to the main business group of the user.
The Business group ID is a mandatory parameter when you have access only to a specific Business group but not to the parent organization.
This parameter is available in plugin version 3.2.7 and later.

No

deploymentTimeout

The allowed elapsed time, in milliseconds, between the start of the deployment process and the confirmation that the artifact has been deployed

The default value is 600000.

No

server

Maven server with Anypoint Platform credentials
This is only needed if you want to use your credentials stored in your Maven settings.xml file. This is not the Mule server name.

No

properties

Top-Level element
If you need to set properties for the Mule application you are deploying, you can use the <properties> top-level element:

<properties>
  <key>value</key>
</properties>

For example:

<properties>
  <http.port>8081</http.port>
</properties>

No

propertiesFile

Top-level element
Specifies a file that contains properties for the Mule application being deployed. Use this parameter as an alternative to defining properties inline with <properties>. The file must use the Java properties format, with one key=value pair per line.

No

secureProperties

Top-Level element
Use the secureProperties top-level element to set properties for the Mule application and instruct Runtime Fabric to encrypt the values before storing them:

<secureProperties>
  <key>value</key>
</secureProperties>

For example:

<secureProperties>
  <http.port>8081</http.port>
</secureProperties>

No

skip

When set to true, skips the plugin deployment goal.
Its default value is false.

No

skipDeploymentVerification

When set to true, skips the status verification of your deployed app.
Its default value is false.

No

authToken

Specifies the authorization token to access the platform. You can use this authentication method instead of setting username and password.
See Identity Management for a list of supported single sign-on (SSO) types.

Only when using an Authorization token to login.

connectedAppClientId

Specifies the Connected App clientID value.

Only when using Connected Apps credentials to login.

connectedAppClientSecret

Specifies the Connected App secret key.

Only when using Connected Apps credentials to login.

connectedAppGrantType

Specifies the only supported connection type: client_credentials.

Only when using Connected Apps credentials to login.

deploymentSettings

Any of the parameters documented in deploymentSettings Reference

No

### deploymentSettings Parameters Reference
ParameterDescription

enforceDeployingReplicasAcrossNodes

Enforces the deployment of replicas across different nodes. The default value is false.

Configuration example:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy

Accepted valuesDescription

rolling

Maintains availability by updating replicas incrementally. Requires one additional replica’s worth of resources to succeed.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is one less than the total number of nodes.

recreate

Terminates replicas before re-deployment. Re-deployment is quicker than rolling and doesn’t require additional resources.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is equal to the number of nodes.

The default value is rolling.

Configuration example:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

Enables clustering across two or more replicas of the application. The default value is false.

Configuration example:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

resources

cpu

reserved

Specifies the number of cores to allocate for each application replica. The default value is 0.5 vCores.

limit

Specifies the number of max cores to allocate for each replica of the application.
If a reserved configuration is present, ensure that this value is equal or higher.

memory

reserved

Specifies the amount of memory to allocate for each application replica. The default value is 700 MB.

limit

Specifies the maximum memory allocated per application replica. If a reserved configuration is present, ensure that this value is equal or higher.

Configuration example:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound

publicUrl

URL of the deployed application.

Configuration example using wildcard URL:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

Configuration example for path-based routing:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://www.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

Configures the Mule application to use a persistent object store. By default, it is set to false.

jvm

args

Specifies JVM arguments to pass to Runtime Fabric when deploying the application. Use spaces to separate each argument.

Configuration example:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

Not applicable for Runtime Fabric BYOK. By default, it is set to false

disableAmLogForwarding

Disables the application-level log forwarding to Anypoint Monitoring. By default, it is set to false.

autoscaling

Provides CPU based horizontal autoscaling configuration for deployment and redeployment operations. If autoscaling is disabled and the fields minReplicas and maxReplicas are provided, they must match the value of the target.replicas field. See Enable Trace Data Collection. Configuration example:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>
## Encrypt Credentials To use encrypted credentials when deploying, you need to set up your Maven master encrypted password and your `settings-security.xml` file. 1. Create a master password for your Maven configuration. mvn --encrypt-master-password Maven returns your master password encrypted: {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. Create a `settings-security.xml` file in your ~/.m2 repository and add your encrypted master password: ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Encrypt your Anypoint platform password: mvn --encrypt-password Maven returns your Anypoint platform password encrypted: {HTWFGH5BG9QmvJ1B=} 4. Add your encrypted Anypoint Platform password to your `settings.xml` file in the section: ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. In your configuration deployment, reference the credentials injecting the server ID configured in your `settings.xml` file: ```xml ... ... ... my.anypoint.credentials ... ... ... ``` > [!NOTE] Make sure that the username and password are not set in the deployment configuration, > or they will overwrite the defined server ID. ## See Also - [Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) --- product: Runtime Fabric version: 2.6 --- # Deploying Mule Apps to Runtime Fabric using Maven > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric supports using Mule Maven Plugin 3.x to manage and deploy Mule applications. The information in this topic is specific to deploying a Mule application to Mule runtime engine 4.x. ## Prerequisites - Ensure that the Mule Maven Plugin is added to your project See [Add the Mule Maven Plugin to a Mule Project](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp) for instructions. - You understand and have available the number of resources required to deploy to Runtime Fabric See [Resource Allocation on Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) for more information. - The application is already published in Exchange See [Publish and Deploy Exchange Assets Using Maven](https://docs.mulesoft.com/exchange/to-publish-assets-maven). The Mule Maven Facade API (v3) is added as a repository in the distribution management section of your project’s POM file. For example: Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION\_ID/maven default If you publish assets using Exchange API, use Exchange API v2, otherwise schedulers aren’t displayed. ## Add the Mule Maven Plugin to a Mule Project To add the Mule Maven plugin, you need to add its maven dependency to the project: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` From this repository: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` This enables the Mule Maven plugin in your project. > [!IMPORTANT] If `true` is not present, the plugin does not work. ## Configure the Runtime Fabric Deployment Strategy Inside the `plugin` element, add a configuration for your Runtime Fabric deployment, replacing the following placeholder values with your Runtime Fabric information: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## Deploy to Runtime Fabric From the command line in your project’s folder, package the application and execute the deploy goal: ```bash mvn clean deploy -DmuleDeploy ``` ### Exchange Snapshot Assets You can also deploy Exchange snapshot assets into Runtime Fabric. By using `SNAPSHOT` version assets in Anypoint Exchange during the development and testing phase, you can avoid incrementing your application’s version number for small changes. After your `SNAPSHOT` version application has been overwritten in Anypoint Exchange, you can redeploy your `SNAPSHOT` version application to Runtime Fabric via the Mule Maven plugin to deploy the latest changes. To learn more about publishing snapshot assets to Anypoint Exchange, see [Asset Lifecycle State](https://docs.mulesoft.com/exchange/to-publish-assets-maven#asset-lifecycle-state). > [!NOTE] Each time you update your application’s snapshot, redeploy the application to refresh it > with the latest snapshot binaries. > > Because snapshot assets can change after deployment, avoid deploying them into your production > environment. ## Redeploy to Runtime Fabric To redeploy the application, run the same command as you did to deploy. Runtime Fabric rewrites the application you had deployed. ## Authentication Methods When you deploy applications using Mule Maven plugin, you can use different methods to provide your credentials to authenticate against the deployment platform. Depending on the authentication method you use, the parameters to set in the deployment configuration differ:
Authentication MethodDescriptionConfiguration Parameters

Username and password

Use a Runtime Fabric username and password to authenticate.

  • username

  • password

Server

Use credentials stored in a Maven server, configured inside the Maven settings.xml file.

  • server

Authorization Token

Use an authorization token to access the platform.
See Identity Management for a list of supported single sign-on (SSO) types.

  • authToken

Connected Apps

Use a Connected App to perform the authentication programmatically by communicating with Anypoint Platform.
Note that the Connected App credentials must have the Design Center Developer access scope.
See Connected Apps for Developers for instructions about creating Connected Apps.

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType

For a detailed description of the configuration parameters, see the [Runtime Fabric Deployment Parameters Reference](#rtf-deploy-reference). ## Runtime Fabric Deployment Parameters Reference
ParameterDescriptionRequired

runtimeFabricDeployment

Top-Level Element

Yes

uri

Your Anypoint Platform URI.
If not set, defaults to https://anypoint.mulesoft.com.

No

muleVersion

The Mule runtime engine version to run in your Runtime Fabric instance.
Ensure that this value is equal to or higher than the earliest required Mule version of your application. By default, the latest available Mule version is selected.
Example values: 4.6.0 selects the last build where it defaults to Edge channel and Java 8. If you want to choose a different LTS or Edge selection or Java version, specify the full Mule version name as in 4.6.0:1e-java17.
When using Mule Maven plugin versions 3.8.0 and 4.0.0 for deployments, the muleVersion property doesn’t allow you to specify releaseChannel and javaVersion. To specify these properties, upgrade the plugin to version 4.1.1 or later.

No

releaseChannel

Set the name of the release channel used to select the Mule image. Supported values are NONE, EDGE, and LTS. By default, the value is set to EDGE. If the selected release channel doesn’t exist, an error occurs.

No

javaVersion

Set the Java version used in the deploy. Supported values are 8 and 17. By default, the value is set to 8. If the selected Java version doesn’t exist, an error occurs.

No

username

Your Anypoint Platform username

Only when using Anypoint Platform credentials to login.

password

Your Anypoint Platform password

Only when using Anypoint Platform credentials to login.

applicationName

The application name displayed in Runtime Manager after the app deploys.

Yes

target

The Runtime Fabric target name where to deploy the app.

Yes

provider

Provider MC (MuleSoft Control Plane) indicates that the deployment is managed through Anypoint Runtime Manager. Set to MC for Runtime Fabric.

Yes

environment

Target Anypoint Platform environment.
This value must match an environment configured in your Anypoint Platform account, as shown here:

<environment>Sandbox</environment>

Yes

replicas

Specifies the number of replicas, or instances, of the Mule application to deploy. The maximum number of replicas per application is 16.

Only when autoscaling is set to false.

businessGroup

The Business group path of the deployment
Specify the full hierarchical path from the parent organization to the target Business group, for example:

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

This value is omitted if businessGroupId is set. If businessGroup and businessGroupId are not set, the value defaults to the main business group of the user.

No

businessGroupId

The Business group ID of the deployment
Instead of specifying the Business group path, you can specify the Business group ID to deploy your application. If businessGroupId and businessGroup are not set, the value defaults to the main business group of the user.
The Business group ID is a mandatory parameter when you have access only to a specific Business group but not to the parent organization.
This parameter is available in plugin version 3.2.7 and later.

No

deploymentTimeout

The allowed elapsed time, in milliseconds, between the start of the deployment process and the confirmation that the artifact has been deployed

The default value is 600000.

No

server

Maven server with Anypoint Platform credentials
This is only needed if you want to use your credentials stored in your Maven settings.xml file. This is not the Mule server name.

No

properties

Top-Level element
If you need to set properties for the Mule application you are deploying, you can use the <properties> top-level element:

<properties>
  <key>value</key>
</properties>

For example:

<properties>
  <http.port>8081</http.port>
</properties>

No

propertiesFile

Top-level element
Specifies a file that contains properties for the Mule application being deployed. Use this parameter as an alternative to defining properties inline with <properties>. The file must use the Java properties format, with one key=value pair per line.

No

secureProperties

Top-Level element
Use the secureProperties top-level element to set properties for the Mule application and instruct Runtime Fabric to encrypt the values before storing them:

<secureProperties>
  <key>value</key>
</secureProperties>

For example:

<secureProperties>
  <http.port>8081</http.port>
</secureProperties>

No

skip

When set to true, skips the plugin deployment goal.
Its default value is false.

No

skipDeploymentVerification

When set to true, skips the status verification of your deployed app.
Its default value is false.

No

authToken

Specifies the authorization token to access the platform. You can use this authentication method instead of setting username and password.
See Identity Management for a list of supported single sign-on (SSO) types.

Only when using an Authorization token to login.

connectedAppClientId

Specifies the Connected App clientID value.

Only when using Connected Apps credentials to login.

connectedAppClientSecret

Specifies the Connected App secret key.

Only when using Connected Apps credentials to login.

connectedAppGrantType

Specifies the only supported connection type: client_credentials.

Only when using Connected Apps credentials to login.

deploymentSettings

Any of the parameters documented in deploymentSettings Reference

No

### deploymentSettings Parameters Reference
ParameterDescription

enforceDeployingReplicasAcrossNodes

Enforces the deployment of replicas across different nodes. The default value is false.

Configuration example:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy

Accepted valuesDescription

rolling

Maintains availability by updating replicas incrementally. Requires one additional replica’s worth of resources to succeed.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is one less than the total number of nodes.

recreate

Terminates replicas before re-deployment. Re-deployment is quicker than rolling and doesn’t require additional resources.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is equal to the number of nodes.

The default value is rolling.

Configuration example:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

Enables clustering across two or more replicas of the application. The default value is false.

Configuration example:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

resources

cpu

reserved

Specifies the number of cores to allocate for each application replica. The default value is 0.5 vCores.

limit

Specifies the number of max cores to allocate for each replica of the application.
If a reserved configuration is present, ensure that this value is equal or higher.

memory

reserved

Specifies the amount of memory to allocate for each application replica. The default value is 700 MB.

limit

Specifies the maximum memory allocated per application replica. If a reserved configuration is present, ensure that this value is equal or higher.

Configuration example:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound

publicUrl

URL of the deployed application.

Configuration example using wildcard URL:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

Configuration example for path-based routing:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://www.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

Configures the Mule application to use a persistent object store. By default, it is set to false.

jvm

args

Specifies JVM arguments to pass to Runtime Fabric when deploying the application. Use spaces to separate each argument.

Configuration example:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

Not applicable for Runtime Fabric BYOK. By default, it is set to false

disableAmLogForwarding

Disables the application-level log forwarding to Anypoint Monitoring. By default, it is set to false.

autoscaling

Provides CPU based horizontal autoscaling configuration for deployment and redeployment operations. If autoscaling is disabled and the fields minReplicas and maxReplicas are provided, they must match the value of the target.replicas field. See Enable Trace Data Collection. Configuration example:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>
## Encrypt Credentials To use encrypted credentials when deploying, you need to set up your Maven master encrypted password and your `settings-security.xml` file. 1. Create a master password for your Maven configuration. mvn --encrypt-master-password Maven returns your master password encrypted: {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. Create a `settings-security.xml` file in your ~/.m2 repository and add your encrypted master password: ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Encrypt your Anypoint platform password: mvn --encrypt-password Maven returns your Anypoint platform password encrypted: {HTWFGH5BG9QmvJ1B=} 4. Add your encrypted Anypoint Platform password to your `settings.xml` file in the section: ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. In your configuration deployment, reference the credentials injecting the server ID configured in your `settings.xml` file: ```xml ... ... ... my.anypoint.credentials ... ... ... ``` > [!NOTE] Make sure that the username and password are not set in the deployment configuration, > or they will overwrite the defined server ID. ## See Also - [Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) --- product: Runtime Fabric version: 2.7 --- # Deploying Mule Apps to Runtime Fabric using Maven > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric supports using Mule Maven Plugin 3.x to manage and deploy Mule applications. The information in this topic is specific to deploying a Mule application to Mule runtime engine 4.x. ## Prerequisites - Ensure that the Mule Maven Plugin is added to your project See [Add the Mule Maven Plugin to a Mule Project](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp) for instructions. - You understand and have available the number of resources required to deploy to Runtime Fabric See [Resource Allocation on Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) for more information. - The application is already published in Exchange See [Publish and Deploy Exchange Assets Using Maven](https://docs.mulesoft.com/exchange/to-publish-assets-maven). The Mule Maven Facade API (v3) is added as a repository in the distribution management section of your project’s POM file. For example: Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION\_ID/maven default If you publish assets using Exchange API, use Exchange API v2, otherwise schedulers aren’t displayed. ## Add the Mule Maven Plugin to a Mule Project To add the Mule Maven plugin, you need to add its maven dependency to the project: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` From this repository: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` This enables the Mule Maven plugin in your project. > [!IMPORTANT] If `true` is not present, the plugin does not work. ## Configure the Runtime Fabric Deployment Strategy Inside the `plugin` element, add a configuration for your Runtime Fabric deployment, replacing the following placeholder values with your Runtime Fabric information: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## Deploy to Runtime Fabric From the command line in your project’s folder, package the application and execute the deploy goal: ```bash mvn clean deploy -DmuleDeploy ``` ### Exchange Snapshot Assets You can also deploy Exchange snapshot assets into Runtime Fabric. By using `SNAPSHOT` version assets in Anypoint Exchange during the development and testing phase, you can avoid incrementing your application’s version number for small changes. After your `SNAPSHOT` version application has been overwritten in Anypoint Exchange, you can redeploy your `SNAPSHOT` version application to Runtime Fabric via the Mule Maven plugin to deploy the latest changes. To learn more about publishing snapshot assets to Anypoint Exchange, see [Asset Lifecycle State](https://docs.mulesoft.com/exchange/to-publish-assets-maven#asset-lifecycle-state). > [!NOTE] Each time you update your application’s snapshot, redeploy the application to refresh it > with the latest snapshot binaries. > > Because snapshot assets can change after deployment, avoid deploying them into your production > environment. ## Redeploy to Runtime Fabric To redeploy the application, run the same command as you did to deploy. Runtime Fabric rewrites the application you had deployed. ## Authentication Methods When you deploy applications using Mule Maven plugin, you can use different methods to provide your credentials to authenticate against the deployment platform. Depending on the authentication method you use, the parameters to set in the deployment configuration differ:
Authentication MethodDescriptionConfiguration Parameters

Username and password

Use a Runtime Fabric username and password to authenticate.

  • username

  • password

Server

Use credentials stored in a Maven server, configured inside the Maven settings.xml file.

  • server

Authorization Token

Use an authorization token to access the platform.
See Identity Management for a list of supported single sign-on (SSO) types.

  • authToken

Connected Apps

Use a Connected App to perform the authentication programmatically by communicating with Anypoint Platform.
Note that the Connected App credentials must have the Design Center Developer access scope.
See Connected Apps for Developers for instructions about creating Connected Apps.

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType

For a detailed description of the configuration parameters, see the [Runtime Fabric Deployment Parameters Reference](#rtf-deploy-reference). ## Runtime Fabric Deployment Parameters Reference
ParameterDescriptionRequired

runtimeFabricDeployment

Top-Level Element

Yes

uri

Your Anypoint Platform URI.
If not set, defaults to https://anypoint.mulesoft.com.

No

muleVersion

The Mule runtime engine version to run in your Runtime Fabric instance.
Ensure that this value is equal to or higher than the earliest required Mule version of your application. By default, the latest available Mule version is selected.
Example values: 4.6.0 selects the last build where it defaults to Edge channel and Java 8. If you want to choose a different LTS or Edge selection or Java version, specify the full Mule version name as in 4.6.0:1e-java17.
When using Mule Maven plugin versions 3.8.0 and 4.0.0 for deployments, the muleVersion property doesn’t allow you to specify releaseChannel and javaVersion. To specify these properties, upgrade the plugin to version 4.1.1 or later.

No

releaseChannel

Set the name of the release channel used to select the Mule image. Supported values are NONE, EDGE, and LTS. By default, the value is set to EDGE. If the selected release channel doesn’t exist, an error occurs.

No

javaVersion

Set the Java version used in the deploy. Supported values are 8 and 17. By default, the value is set to 8. If the selected Java version doesn’t exist, an error occurs.

No

username

Your Anypoint Platform username

Only when using Anypoint Platform credentials to login.

password

Your Anypoint Platform password

Only when using Anypoint Platform credentials to login.

applicationName

The application name displayed in Runtime Manager after the app deploys.

Yes

target

The Runtime Fabric target name where to deploy the app.

Yes

provider

Provider MC (MuleSoft Control Plane) indicates that the deployment is managed through Anypoint Runtime Manager. Set to MC for Runtime Fabric.

Yes

environment

Target Anypoint Platform environment.
This value must match an environment configured in your Anypoint Platform account, as shown here:

<environment>Sandbox</environment>

Yes

replicas

Specifies the number of replicas, or instances, of the Mule application to deploy. The maximum number of replicas per application is 16.

Only when autoscaling is set to false.

businessGroup

The Business group path of the deployment
Specify the full hierarchical path from the parent organization to the target Business group, for example:

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

This value is omitted if businessGroupId is set. If businessGroup and businessGroupId are not set, the value defaults to the main business group of the user.

No

businessGroupId

The Business group ID of the deployment
Instead of specifying the Business group path, you can specify the Business group ID to deploy your application. If businessGroupId and businessGroup are not set, the value defaults to the main business group of the user.
The Business group ID is a mandatory parameter when you have access only to a specific Business group but not to the parent organization.
This parameter is available in plugin version 3.2.7 and later.

No

deploymentTimeout

The allowed elapsed time, in milliseconds, between the start of the deployment process and the confirmation that the artifact has been deployed

The default value is 600000.

No

server

Maven server with Anypoint Platform credentials
This is only needed if you want to use your credentials stored in your Maven settings.xml file. This is not the Mule server name.

No

properties

Top-Level element
If you need to set properties for the Mule application you are deploying, you can use the <properties> top-level element:

<properties>
  <key>value</key>
</properties>

For example:

<properties>
  <http.port>8081</http.port>
</properties>

No

propertiesFile

Top-level element
Specifies a file that contains properties for the Mule application being deployed. Use this parameter as an alternative to defining properties inline with <properties>. The file must use the Java properties format, with one key=value pair per line.

No

secureProperties

Top-Level element
Use the secureProperties top-level element to set properties for the Mule application and instruct Runtime Fabric to encrypt the values before storing them:

<secureProperties>
  <key>value</key>
</secureProperties>

For example:

<secureProperties>
  <http.port>8081</http.port>
</secureProperties>

No

skip

When set to true, skips the plugin deployment goal.
Its default value is false.

No

skipDeploymentVerification

When set to true, skips the status verification of your deployed app.
Its default value is false.

No

authToken

Specifies the authorization token to access the platform. You can use this authentication method instead of setting username and password.
See Identity Management for a list of supported single sign-on (SSO) types.

Only when using an Authorization token to login.

connectedAppClientId

Specifies the Connected App clientID value.

Only when using Connected Apps credentials to login.

connectedAppClientSecret

Specifies the Connected App secret key.

Only when using Connected Apps credentials to login.

connectedAppGrantType

Specifies the only supported connection type: client_credentials.

Only when using Connected Apps credentials to login.

deploymentSettings

Any of the parameters documented in deploymentSettings Reference

No

### deploymentSettings Parameters Reference
ParameterDescription

enforceDeployingReplicasAcrossNodes

Enforces the deployment of replicas across different nodes. The default value is false.

Configuration example:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy

Accepted valuesDescription

rolling

Maintains availability by updating replicas incrementally. Requires one additional replica’s worth of resources to succeed.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is one less than the total number of nodes.

recreate

Terminates replicas before re-deployment. Re-deployment is quicker than rolling and doesn’t require additional resources.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is equal to the number of nodes.

The default value is rolling.

Configuration example:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

Enables clustering across two or more replicas of the application. The default value is false.

Configuration example:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

resources

cpu

reserved

Specifies the number of cores to allocate for each application replica. The default value is 0.5 vCores.

limit

Specifies the number of max cores to allocate for each replica of the application.
If a reserved configuration is present, ensure that this value is equal or higher.

memory

reserved

Specifies the amount of memory to allocate for each application replica. The default value is 700 MB.

limit

Specifies the maximum memory allocated per application replica. If a reserved configuration is present, ensure that this value is equal or higher.

Configuration example:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound

publicUrl

URL of the deployed application.

Configuration example using wildcard URL:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

Configuration example for path-based routing:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://www.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

Configures the Mule application to use a persistent object store. By default, it is set to false.

jvm

args

Specifies JVM arguments to pass to Runtime Fabric when deploying the application. Use spaces to separate each argument.

Configuration example:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

Not applicable for Runtime Fabric BYOK. By default, it is set to false

disableAmLogForwarding

Disables the application-level log forwarding to Anypoint Monitoring. By default, it is set to false.

autoscaling

Provides CPU based horizontal autoscaling configuration for deployment and redeployment operations. If autoscaling is disabled and the fields minReplicas and maxReplicas are provided, they must match the value of the target.replicas field. See Enable Trace Data Collection. Configuration example:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>
## Encrypt Credentials To use encrypted credentials when deploying, you need to set up your Maven master encrypted password and your `settings-security.xml` file. 1. Create a master password for your Maven configuration. mvn --encrypt-master-password Maven returns your master password encrypted: {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. Create a `settings-security.xml` file in your ~/.m2 repository and add your encrypted master password: ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Encrypt your Anypoint platform password: mvn --encrypt-password Maven returns your Anypoint platform password encrypted: {HTWFGH5BG9QmvJ1B=} 4. Add your encrypted Anypoint Platform password to your `settings.xml` file in the section: ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. In your configuration deployment, reference the credentials injecting the server ID configured in your `settings.xml` file: ```xml ... ... ... my.anypoint.credentials ... ... ... ``` > [!NOTE] Make sure that the username and password are not set in the deployment configuration, > or they will overwrite the defined server ID. ## See Also - [Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) --- product: Runtime Fabric version: 2.8 --- # Deploying Mule Apps to Runtime Fabric using Maven > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric supports using Mule Maven Plugin 3.x to manage and deploy Mule applications. The information in this topic is specific to deploying a Mule application to Mule runtime engine 4.x. ## Prerequisites - Ensure that the Mule Maven Plugin is added to your project See [Add the Mule Maven Plugin to a Mule Project](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp) for instructions. - You understand and have available the number of resources required to deploy to Runtime Fabric See [Resource Allocation on Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) for more information. - The application is already published in Exchange See [Publish and Deploy Exchange Assets Using Maven](https://docs.mulesoft.com/exchange/to-publish-assets-maven). The Mule Maven Facade API (v3) is added as a repository in the distribution management section of your project’s POM file. For example: Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION\_ID/maven default If you publish assets using Exchange API, use Exchange API v2, otherwise schedulers aren’t displayed. ## Add the Mule Maven Plugin to a Mule Project To add the Mule Maven plugin, you need to add its maven dependency to the project: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` From this repository: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` This enables the Mule Maven plugin in your project. > [!IMPORTANT] If `true` is not present, the plugin does not work. ## Configure the Runtime Fabric Deployment Strategy Inside the `plugin` element, add a configuration for your Runtime Fabric deployment, replacing the following placeholder values with your Runtime Fabric information: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## Deploy to Runtime Fabric From the command line in your project’s folder, package the application and execute the deploy goal: ```bash mvn clean deploy -DmuleDeploy ``` ### Exchange Snapshot Assets You can also deploy Exchange snapshot assets into Runtime Fabric. By using `SNAPSHOT` version assets in Anypoint Exchange during the development and testing phase, you can avoid incrementing your application’s version number for small changes. After your `SNAPSHOT` version application has been overwritten in Anypoint Exchange, you can redeploy your `SNAPSHOT` version application to Runtime Fabric via the Mule Maven plugin to deploy the latest changes. To learn more about publishing snapshot assets to Anypoint Exchange, see [Asset Lifecycle State](https://docs.mulesoft.com/exchange/to-publish-assets-maven#asset-lifecycle-state). > [!NOTE] Each time you update your application’s snapshot, redeploy the application to refresh it > with the latest snapshot binaries. > > Because snapshot assets can change after deployment, avoid deploying them into your production > environment. ## Redeploy to Runtime Fabric To redeploy the application, run the same command as you did to deploy. Runtime Fabric rewrites the application you had deployed. ## Authentication Methods When you deploy applications using Mule Maven plugin, you can use different methods to provide your credentials to authenticate against the deployment platform. Depending on the authentication method you use, the parameters to set in the deployment configuration differ:
Authentication MethodDescriptionConfiguration Parameters

Username and password

Use a Runtime Fabric username and password to authenticate.

  • username

  • password

Server

Use credentials stored in a Maven server, configured inside the Maven settings.xml file.

  • server

Authorization Token

Use an authorization token to access the platform.
See Identity Management for a list of supported single sign-on (SSO) types.

  • authToken

Connected Apps

Use a Connected App to perform the authentication programmatically by communicating with Anypoint Platform.
Note that the Connected App credentials must have the Design Center Developer access scope.
See Connected Apps for Developers for instructions about creating Connected Apps.

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType

For a detailed description of the configuration parameters, see the [Runtime Fabric Deployment Parameters Reference](#rtf-deploy-reference). ## Runtime Fabric Deployment Parameters Reference
ParameterDescriptionRequired

runtimeFabricDeployment

Top-Level Element

Yes

uri

Your Anypoint Platform URI.
If not set, defaults to https://anypoint.mulesoft.com.

No

muleVersion

The Mule runtime engine version to run in your Runtime Fabric instance.
Ensure that this value is equal to or higher than the earliest required Mule version of your application. By default, the latest available Mule version is selected.
Example values: 4.6.0 selects the last build where it defaults to Edge channel and Java 8. If you want to choose a different LTS or Edge selection or Java version, specify the full Mule version name as in 4.6.0:1e-java17.
When using Mule Maven plugin versions 3.8.0 and 4.0.0 for deployments, the muleVersion property doesn’t allow you to specify releaseChannel and javaVersion. To specify these properties, upgrade the plugin to version 4.1.1 or later.

No

releaseChannel

Set the name of the release channel used to select the Mule image. Supported values are NONE, EDGE, and LTS. By default, the value is set to EDGE. If the selected release channel doesn’t exist, an error occurs.

No

javaVersion

Set the Java version used in the deploy. Supported values are 8 and 17. By default, the value is set to 8. If the selected Java version doesn’t exist, an error occurs.

No

username

Your Anypoint Platform username

Only when using Anypoint Platform credentials to login.

password

Your Anypoint Platform password

Only when using Anypoint Platform credentials to login.

applicationName

The application name displayed in Runtime Manager after the app deploys.

Yes

target

The Runtime Fabric target name where to deploy the app.

Yes

provider

Provider MC (MuleSoft Control Plane) indicates that the deployment is managed through Anypoint Runtime Manager. Set to MC for Runtime Fabric.

Yes

environment

Target Anypoint Platform environment.
This value must match an environment configured in your Anypoint Platform account, as shown here:

<environment>Sandbox</environment>

Yes

replicas

Specifies the number of replicas, or instances, of the Mule application to deploy. The maximum number of replicas per application is 16.

Only when autoscaling is set to false.

businessGroup

The Business group path of the deployment
Specify the full hierarchical path from the parent organization to the target Business group, for example:

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

This value is omitted if businessGroupId is set. If businessGroup and businessGroupId are not set, the value defaults to the main business group of the user.

No

businessGroupId

The Business group ID of the deployment
Instead of specifying the Business group path, you can specify the Business group ID to deploy your application. If businessGroupId and businessGroup are not set, the value defaults to the main business group of the user.
The Business group ID is a mandatory parameter when you have access only to a specific Business group but not to the parent organization.
This parameter is available in plugin version 3.2.7 and later.

No

deploymentTimeout

The allowed elapsed time, in milliseconds, between the start of the deployment process and the confirmation that the artifact has been deployed

The default value is 600000.

No

server

Maven server with Anypoint Platform credentials
This is only needed if you want to use your credentials stored in your Maven settings.xml file. This is not the Mule server name.

No

properties

Top-Level element
If you need to set properties for the Mule application you are deploying, you can use the <properties> top-level element:

<properties>
  <key>value</key>
</properties>

For example:

<properties>
  <http.port>8081</http.port>
</properties>

No

propertiesFile

Top-level element
Specifies a file that contains properties for the Mule application being deployed. Use this parameter as an alternative to defining properties inline with <properties>. The file must use the Java properties format, with one key=value pair per line.

No

secureProperties

Top-Level element
Use the secureProperties top-level element to set properties for the Mule application and instruct Runtime Fabric to encrypt the values before storing them:

<secureProperties>
  <key>value</key>
</secureProperties>

For example:

<secureProperties>
  <http.port>8081</http.port>
</secureProperties>

No

skip

When set to true, skips the plugin deployment goal.
Its default value is false.

No

skipDeploymentVerification

When set to true, skips the status verification of your deployed app.
Its default value is false.

No

authToken

Specifies the authorization token to access the platform. You can use this authentication method instead of setting username and password.
See Identity Management for a list of supported single sign-on (SSO) types.

Only when using an Authorization token to login.

connectedAppClientId

Specifies the Connected App clientID value.

Only when using Connected Apps credentials to login.

connectedAppClientSecret

Specifies the Connected App secret key.

Only when using Connected Apps credentials to login.

connectedAppGrantType

Specifies the only supported connection type: client_credentials.

Only when using Connected Apps credentials to login.

deploymentSettings

Any of the parameters documented in deploymentSettings Reference

No

### deploymentSettings Parameters Reference
ParameterDescription

enforceDeployingReplicasAcrossNodes

Enforces the deployment of replicas across different nodes. The default value is false.

Configuration example:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy

Accepted valuesDescription

rolling

Maintains availability by updating replicas incrementally. Requires one additional replica’s worth of resources to succeed.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is one less than the total number of nodes.

recreate

Terminates replicas before re-deployment. Re-deployment is quicker than rolling and doesn’t require additional resources.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is equal to the number of nodes.

The default value is rolling.

Configuration example:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

Enables clustering across two or more replicas of the application. The default value is false.

Configuration example:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

resources

cpu

reserved

Specifies the number of cores to allocate for each application replica. The default value is 0.5 vCores.

limit

Specifies the number of max cores to allocate for each replica of the application.
If a reserved configuration is present, ensure that this value is equal or higher.

memory

reserved

Specifies the amount of memory to allocate for each application replica. The default value is 700 MB.

limit

Specifies the maximum memory allocated per application replica. If a reserved configuration is present, ensure that this value is equal or higher.

Configuration example:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound

publicUrl

URL of the deployed application.

Configuration example using wildcard URL:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

Configuration example for path-based routing:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://www.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

Configures the Mule application to use a persistent object store. By default, it is set to false.

jvm

args

Specifies JVM arguments to pass to Runtime Fabric when deploying the application. Use spaces to separate each argument.

Configuration example:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

Not applicable for Runtime Fabric BYOK. By default, it is set to false

disableAmLogForwarding

Disables the application-level log forwarding to Anypoint Monitoring. By default, it is set to false.

autoscaling

Provides CPU based horizontal autoscaling configuration for deployment and redeployment operations. If autoscaling is disabled and the fields minReplicas and maxReplicas are provided, they must match the value of the target.replicas field. See Enable Trace Data Collection. Configuration example:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>
## Encrypt Credentials To use encrypted credentials when deploying, you need to set up your Maven master encrypted password and your `settings-security.xml` file. 1. Create a master password for your Maven configuration. mvn --encrypt-master-password Maven returns your master password encrypted: {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. Create a `settings-security.xml` file in your ~/.m2 repository and add your encrypted master password: ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Encrypt your Anypoint platform password: mvn --encrypt-password Maven returns your Anypoint platform password encrypted: {HTWFGH5BG9QmvJ1B=} 4. Add your encrypted Anypoint Platform password to your `settings.xml` file in the section: ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. In your configuration deployment, reference the credentials injecting the server ID configured in your `settings.xml` file: ```xml ... ... ... my.anypoint.credentials ... ... ... ``` > [!NOTE] Make sure that the username and password are not set in the deployment configuration, > or they will overwrite the defined server ID. ## See Also - [Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) --- product: Runtime Fabric version: 2.11 --- # Deploying Mule Apps to Runtime Fabric using Maven (Mule 4) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric supports using Mule Maven Plugin 3.x to manage and deploy Mule applications. The information in this topic is specific to deploying a Mule application to Mule runtime engine 4.x. ## Prerequisites - Ensure that the Mule Maven Plugin is added to your project See [Add the Mule Maven Plugin to a Mule Project](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp) for instructions. - You understand and have available the number of resources required to deploy to Runtime Fabric See [Resource Allocation on Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) for more information. - The application is already published in Exchange See [Publish and Deploy Exchange Assets Using Maven](https://docs.mulesoft.com/exchange/to-publish-assets-maven). The Mule Maven Facade API (v3) is added as a repository in the distribution management section of your project’s POM file. For example: Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION\_ID/maven default If you publish assets using Exchange API, use Exchange API v2, otherwise schedulers aren’t displayed. ## Add the Mule Maven Plugin to a Mule Project To add the Mule Maven plugin, you need to add its maven dependency to the project: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` From this repository: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` This enables the Mule Maven plugin in your project. > [!IMPORTANT] If `true` is not present, the plugin does not work. ## Configure the Runtime Fabric Deployment Strategy Inside the `plugin` element, add a configuration for your Runtime Fabric deployment, replacing the following placeholder values with your Runtime Fabric information: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## Deploy to Runtime Fabric From the command line in your project’s folder, package the application and execute the deploy goal: ```bash mvn clean deploy -DmuleDeploy ``` ### Exchange Snapshot Assets You can also deploy Exchange snapshot assets into Runtime Fabric. By using `SNAPSHOT` version assets in Anypoint Exchange during the development and testing phase, you can avoid incrementing your application’s version number for small changes. After your `SNAPSHOT` version application has been overwritten in Anypoint Exchange, you can redeploy your `SNAPSHOT` version application to Runtime Fabric via the Mule Maven plugin to deploy the latest changes. To learn more about publishing snapshot assets to Anypoint Exchange, see [Asset Lifecycle State](https://docs.mulesoft.com/exchange/to-publish-assets-maven#asset-lifecycle-state). > [!NOTE] Each time you update your application’s snapshot, redeploy the application to refresh it > with the latest snapshot binaries. > > Because snapshot assets can change after deployment, avoid deploying them into your production > environment. ## Redeploy to Runtime Fabric To redeploy the application, run the same command as you did to deploy. Runtime Fabric rewrites the application you had deployed. ## Authentication Methods When you deploy applications using Mule Maven plugin, you can use different methods to provide your credentials to authenticate against the deployment platform. Depending on the authentication method you use, the parameters to set in the deployment configuration differ:
Authentication MethodDescriptionConfiguration Parameters

Username and password

Use a Runtime Fabric username and password to authenticate.

  • username

  • password

Server

Use credentials stored in a Maven server, configured inside the Maven settings.xml file.

  • server

Authorization Token

Use an authorization token to access the platform.
See Identity Management for a list of supported single sign-on (SSO) types.

  • authToken

Connected Apps

Use a Connected App to perform the authentication programmatically by communicating with Anypoint Platform.
Note that the Connected App credentials must have the Design Center Developer access scope.
See Connected Apps for Developers for instructions about creating Connected Apps.

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType

For a detailed description of the configuration parameters, see the [Runtime Fabric Deployment Parameters Reference](#rtf-deploy-reference). ## Runtime Fabric Deployment Parameters Reference
ParameterDescriptionRequired

runtimeFabricDeployment

Top-Level Element

Yes

uri

Your Anypoint Platform URI.
If not set, defaults to https://anypoint.mulesoft.com.

No

muleVersion

The Mule runtime engine version to run in your Runtime Fabric instance.
Ensure that this value is equal to or higher than the earliest required Mule version of your application. By default, the latest available Mule version is selected.
Example values: 4.6.0 selects the last build where it defaults to Edge channel and Java 8. If you want to choose a different LTS or Edge selection or Java version, specify the full Mule version name as in 4.6.0:1e-java17.
When using Mule Maven plugin versions 3.8.0 and 4.0.0 for deployments, the muleVersion property doesn’t allow you to specify releaseChannel and javaVersion. To specify these properties, upgrade the plugin to version 4.1.1 or later.

No

releaseChannel

Set the name of the release channel used to select the Mule image. Supported values are NONE, EDGE, and LTS. By default, the value is set to EDGE. If the selected release channel doesn’t exist, an error occurs.

No

javaVersion

Set the Java version used in the deploy. Supported values are 8 and 17. By default, the value is set to 8. If the selected Java version doesn’t exist, an error occurs.

No

username

Your Anypoint Platform username

Only when using Anypoint Platform credentials to login.

password

Your Anypoint Platform password

Only when using Anypoint Platform credentials to login.

applicationName

The application name displayed in Runtime Manager after the app deploys.

Yes

target

The Runtime Fabric target name where to deploy the app.

Yes

provider

Provider MC (MuleSoft Control Plane) indicates that the deployment is managed through Anypoint Runtime Manager. Set to MC for Runtime Fabric.

Yes

environment

Target Anypoint Platform environment.
This value must match an environment configured in your Anypoint Platform account, as shown here:

<environment>Sandbox</environment>

Yes

replicas

Specifies the number of replicas, or instances, of the Mule application to deploy. The maximum number of replicas per application is 16.

Only when autoscaling is set to false.

businessGroup

The Business group path of the deployment
Specify the full hierarchical path from the parent organization to the target Business group, for example:

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

This value is omitted if businessGroupId is set. If businessGroup and businessGroupId are not set, the value defaults to the main business group of the user.

No

businessGroupId

The Business group ID of the deployment
Instead of specifying the Business group path, you can specify the Business group ID to deploy your application. If businessGroupId and businessGroup are not set, the value defaults to the main business group of the user.
The Business group ID is a mandatory parameter when you have access only to a specific Business group but not to the parent organization.
This parameter is available in plugin version 3.2.7 and later.

No

deploymentTimeout

The allowed elapsed time, in milliseconds, between the start of the deployment process and the confirmation that the artifact has been deployed

The default value is 600000.

No

server

Maven server with Anypoint Platform credentials
This is only needed if you want to use your credentials stored in your Maven settings.xml file. This is not the Mule server name.

No

properties

Top-Level element
If you need to set properties for the Mule application you are deploying, you can use the <properties> top-level element:

<properties>
  <key>value</key>
</properties>

For example:

<properties>
  <http.port>8081</http.port>
</properties>

No

propertiesFile

Top-level element
Specifies a file that contains properties for the Mule application being deployed. Use this parameter as an alternative to defining properties inline with <properties>. The file must use the Java properties format, with one key=value pair per line.

No

secureProperties

Top-Level element
Use the secureProperties top-level element to set properties for the Mule application and instruct Runtime Fabric to encrypt the values before storing them:

<secureProperties>
  <key>value</key>
</secureProperties>

For example:

<secureProperties>
  <http.port>8081</http.port>
</secureProperties>

No

skip

When set to true, skips the plugin deployment goal.
Its default value is false.

No

skipDeploymentVerification

When set to true, skips the status verification of your deployed app.
Its default value is false.

No

authToken

Specifies the authorization token to access the platform. You can use this authentication method instead of setting username and password.
See Identity Management for a list of supported single sign-on (SSO) types.

Only when using an Authorization token to login.

connectedAppClientId

Specifies the Connected App clientID value.

Only when using Connected Apps credentials to login.

connectedAppClientSecret

Specifies the Connected App secret key.

Only when using Connected Apps credentials to login.

connectedAppGrantType

Specifies the only supported connection type: client_credentials.

Only when using Connected Apps credentials to login.

deploymentSettings

Any of the parameters documented in deploymentSettings Reference

No

### deploymentSettings Parameters Reference
ParameterDescription

enforceDeployingReplicasAcrossNodes

Enforces the deployment of replicas across different nodes. The default value is false.

Configuration example:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy

Accepted valuesDescription

rolling

Maintains availability by updating replicas incrementally. Requires one additional replica’s worth of resources to succeed.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is one less than the total number of nodes.

recreate

Terminates replicas before re-deployment. Re-deployment is quicker than rolling and doesn’t require additional resources.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is equal to the number of nodes.

The default value is rolling.

Configuration example:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

Enables clustering across two or more replicas of the application. The default value is false.

Configuration example:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

resources

cpu

reserved

Specifies the number of cores to allocate for each application replica. The default value is 0.5 vCores.

limit

Specifies the number of max cores to allocate for each replica of the application.
If a reserved configuration is present, ensure that this value is equal or higher.

memory

reserved

Specifies the amount of memory to allocate for each application replica. The default value is 700 MB.

limit

Specifies the maximum memory allocated per application replica. If a reserved configuration is present, ensure that this value is equal or higher.

Configuration example:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound

publicUrl

URL of the deployed application.

Configuration example using wildcard URL:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

Configuration example for path-based routing:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://www.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

Configures the Mule application to use a persistent object store. By default, it is set to false.

jvm

args

Specifies JVM arguments to pass to Runtime Fabric when deploying the application. Use spaces to separate each argument.

Configuration example:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

Not applicable for Runtime Fabric BYOK. By default, it is set to false

disableAmLogForwarding

Disables the application-level log forwarding to Anypoint Monitoring. By default, it is set to false.

autoscaling

Provides CPU based horizontal autoscaling configuration for deployment and redeployment operations. If autoscaling is disabled and the fields minReplicas and maxReplicas are provided, they must match the value of the target.replicas field. See Enable Trace Data Collection. Configuration example:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>
## Encrypt Credentials To use encrypted credentials when deploying, you need to set up your Maven master encrypted password and your `settings-security.xml` file. 1. Create a master password for your Maven configuration. mvn --encrypt-master-password Maven returns your master password encrypted: {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. Create a `settings-security.xml` file in your ~/.m2 repository and add your encrypted master password: ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Encrypt your Anypoint platform password: mvn --encrypt-password Maven returns your Anypoint platform password encrypted: {HTWFGH5BG9QmvJ1B=} 4. Add your encrypted Anypoint Platform password to your `settings.xml` file in the section: ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. In your configuration deployment, reference the credentials injecting the server ID configured in your `settings.xml` file: ```xml ... ... ... my.anypoint.credentials ... ... ... ``` > [!NOTE] Make sure that the username and password are not set in the deployment configuration, > or they will overwrite the defined server ID. ## See Also - [Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) --- product: Runtime Fabric version: 2.9 --- # Deploying Mule Apps to Runtime Fabric using Maven (Mule 4) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric supports using Mule Maven Plugin 3.x to manage and deploy Mule applications. The information in this topic is specific to deploying a Mule application to Mule runtime engine 4.x. ## Prerequisites - Ensure that the Mule Maven Plugin is added to your project See [Add the Mule Maven Plugin to a Mule Project](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp) for instructions. - You understand and have available the number of resources required to deploy to Runtime Fabric See [Resource Allocation on Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) for more information. - The application is already published in Exchange See [Publish and Deploy Exchange Assets Using Maven](https://docs.mulesoft.com/exchange/to-publish-assets-maven). The Mule Maven Facade API (v3) is added as a repository in the distribution management section of your project’s POM file. For example: Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION\_ID/maven default If you publish assets using Exchange API, use Exchange API v2, otherwise schedulers aren’t displayed. ## Add the Mule Maven Plugin to a Mule Project To add the Mule Maven plugin, you need to add its maven dependency to the project: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` From this repository: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` This enables the Mule Maven plugin in your project. > [!IMPORTANT] If `true` is not present, the plugin does not work. ## Configure the Runtime Fabric Deployment Strategy Inside the `plugin` element, add a configuration for your Runtime Fabric deployment, replacing the following placeholder values with your Runtime Fabric information: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## Deploy to Runtime Fabric From the command line in your project’s folder, package the application and execute the deploy goal: ```bash mvn clean deploy -DmuleDeploy ``` ### Exchange Snapshot Assets You can also deploy Exchange snapshot assets into Runtime Fabric. By using `SNAPSHOT` version assets in Anypoint Exchange during the development and testing phase, you can avoid incrementing your application’s version number for small changes. After your `SNAPSHOT` version application has been overwritten in Anypoint Exchange, you can redeploy your `SNAPSHOT` version application to Runtime Fabric via the Mule Maven plugin to deploy the latest changes. To learn more about publishing snapshot assets to Anypoint Exchange, see [Asset Lifecycle State](https://docs.mulesoft.com/exchange/to-publish-assets-maven#asset-lifecycle-state). > [!NOTE] Each time you update your application’s snapshot, redeploy the application to refresh it > with the latest snapshot binaries. > > Because snapshot assets can change after deployment, avoid deploying them into your production > environment. ## Redeploy to Runtime Fabric To redeploy the application, run the same command as you did to deploy. Runtime Fabric rewrites the application you had deployed. ## Authentication Methods When you deploy applications using Mule Maven plugin, you can use different methods to provide your credentials to authenticate against the deployment platform. Depending on the authentication method you use, the parameters to set in the deployment configuration differ:
Authentication MethodDescriptionConfiguration Parameters

Username and password

Use a Runtime Fabric username and password to authenticate.

  • username

  • password

Server

Use credentials stored in a Maven server, configured inside the Maven settings.xml file.

  • server

Authorization Token

Use an authorization token to access the platform.
See Identity Management for a list of supported single sign-on (SSO) types.

  • authToken

Connected Apps

Use a Connected App to perform the authentication programmatically by communicating with Anypoint Platform.
Note that the Connected App credentials must have the Design Center Developer access scope.
See Connected Apps for Developers for instructions about creating Connected Apps.

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType

For a detailed description of the configuration parameters, see the [Runtime Fabric Deployment Parameters Reference](#rtf-deploy-reference). ## Runtime Fabric Deployment Parameters Reference
ParameterDescriptionRequired

runtimeFabricDeployment

Top-Level Element

Yes

uri

Your Anypoint Platform URI.
If not set, defaults to https://anypoint.mulesoft.com.

No

muleVersion

The Mule runtime engine version to run in your Runtime Fabric instance.
Ensure that this value is equal to or higher than the earliest required Mule version of your application. By default, the latest available Mule version is selected.
Example values: 4.6.0 selects the last build where it defaults to Edge channel and Java 8. If you want to choose a different LTS or Edge selection or Java version, specify the full Mule version name as in 4.6.0:1e-java17.
When using Mule Maven plugin versions 3.8.0 and 4.0.0 for deployments, the muleVersion property doesn’t allow you to specify releaseChannel and javaVersion. To specify these properties, upgrade the plugin to version 4.1.1 or later.

No

releaseChannel

Set the name of the release channel used to select the Mule image. Supported values are NONE, EDGE, and LTS. By default, the value is set to EDGE. If the selected release channel doesn’t exist, an error occurs.

No

javaVersion

Set the Java version used in the deploy. Supported values are 8 and 17. By default, the value is set to 8. If the selected Java version doesn’t exist, an error occurs.

No

username

Your Anypoint Platform username

Only when using Anypoint Platform credentials to login.

password

Your Anypoint Platform password

Only when using Anypoint Platform credentials to login.

applicationName

The application name displayed in Runtime Manager after the app deploys.

Yes

target

The Runtime Fabric target name where to deploy the app.

Yes

provider

Provider MC (MuleSoft Control Plane) indicates that the deployment is managed through Anypoint Runtime Manager. Set to MC for Runtime Fabric.

Yes

environment

Target Anypoint Platform environment.
This value must match an environment configured in your Anypoint Platform account, as shown here:

<environment>Sandbox</environment>

Yes

replicas

Specifies the number of replicas, or instances, of the Mule application to deploy. The maximum number of replicas per application is 16.

Only when autoscaling is set to false.

businessGroup

The Business group path of the deployment
Specify the full hierarchical path from the parent organization to the target Business group, for example:

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

This value is omitted if businessGroupId is set. If businessGroup and businessGroupId are not set, the value defaults to the main business group of the user.

No

businessGroupId

The Business group ID of the deployment
Instead of specifying the Business group path, you can specify the Business group ID to deploy your application. If businessGroupId and businessGroup are not set, the value defaults to the main business group of the user.
The Business group ID is a mandatory parameter when you have access only to a specific Business group but not to the parent organization.
This parameter is available in plugin version 3.2.7 and later.

No

deploymentTimeout

The allowed elapsed time, in milliseconds, between the start of the deployment process and the confirmation that the artifact has been deployed

The default value is 600000.

No

server

Maven server with Anypoint Platform credentials
This is only needed if you want to use your credentials stored in your Maven settings.xml file. This is not the Mule server name.

No

properties

Top-Level element
If you need to set properties for the Mule application you are deploying, you can use the <properties> top-level element:

<properties>
  <key>value</key>
</properties>

For example:

<properties>
  <http.port>8081</http.port>
</properties>

No

propertiesFile

Top-level element
Specifies a file that contains properties for the Mule application being deployed. Use this parameter as an alternative to defining properties inline with <properties>. The file must use the Java properties format, with one key=value pair per line.

No

secureProperties

Top-Level element
Use the secureProperties top-level element to set properties for the Mule application and instruct Runtime Fabric to encrypt the values before storing them:

<secureProperties>
  <key>value</key>
</secureProperties>

For example:

<secureProperties>
  <http.port>8081</http.port>
</secureProperties>

No

skip

When set to true, skips the plugin deployment goal.
Its default value is false.

No

skipDeploymentVerification

When set to true, skips the status verification of your deployed app.
Its default value is false.

No

authToken

Specifies the authorization token to access the platform. You can use this authentication method instead of setting username and password.
See Identity Management for a list of supported single sign-on (SSO) types.

Only when using an Authorization token to login.

connectedAppClientId

Specifies the Connected App clientID value.

Only when using Connected Apps credentials to login.

connectedAppClientSecret

Specifies the Connected App secret key.

Only when using Connected Apps credentials to login.

connectedAppGrantType

Specifies the only supported connection type: client_credentials.

Only when using Connected Apps credentials to login.

deploymentSettings

Any of the parameters documented in deploymentSettings Reference

No

### deploymentSettings Parameters Reference
ParameterDescription

enforceDeployingReplicasAcrossNodes

Enforces the deployment of replicas across different nodes. The default value is false.

Configuration example:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy

Accepted valuesDescription

rolling

Maintains availability by updating replicas incrementally. Requires one additional replica’s worth of resources to succeed.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is one less than the total number of nodes.

recreate

Terminates replicas before re-deployment. Re-deployment is quicker than rolling and doesn’t require additional resources.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is equal to the number of nodes.

The default value is rolling.

Configuration example:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

Enables clustering across two or more replicas of the application. The default value is false.

Configuration example:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

resources

cpu

reserved

Specifies the number of cores to allocate for each application replica. The default value is 0.5 vCores.

limit

Specifies the number of max cores to allocate for each replica of the application.
If a reserved configuration is present, ensure that this value is equal or higher.

memory

reserved

Specifies the amount of memory to allocate for each application replica. The default value is 700 MB.

limit

Specifies the maximum memory allocated per application replica. If a reserved configuration is present, ensure that this value is equal or higher.

Configuration example:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound

publicUrl

URL of the deployed application.

Configuration example using wildcard URL:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

Configuration example for path-based routing:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://www.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

Configures the Mule application to use a persistent object store. By default, it is set to false.

jvm

args

Specifies JVM arguments to pass to Runtime Fabric when deploying the application. Use spaces to separate each argument.

Configuration example:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

Not applicable for Runtime Fabric BYOK. By default, it is set to false

disableAmLogForwarding

Disables the application-level log forwarding to Anypoint Monitoring. By default, it is set to false.

autoscaling

Provides CPU based horizontal autoscaling configuration for deployment and redeployment operations. If autoscaling is disabled and the fields minReplicas and maxReplicas are provided, they must match the value of the target.replicas field. See Enable Trace Data Collection. Configuration example:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>
## Encrypt Credentials To use encrypted credentials when deploying, you need to set up your Maven master encrypted password and your `settings-security.xml` file. 1. Create a master password for your Maven configuration. mvn --encrypt-master-password Maven returns your master password encrypted: {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. Create a `settings-security.xml` file in your ~/.m2 repository and add your encrypted master password: ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Encrypt your Anypoint platform password: mvn --encrypt-password Maven returns your Anypoint platform password encrypted: {HTWFGH5BG9QmvJ1B=} 4. Add your encrypted Anypoint Platform password to your `settings.xml` file in the section: ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. In your configuration deployment, reference the credentials injecting the server ID configured in your `settings.xml` file: ```xml ... ... ... my.anypoint.credentials ... ... ... ``` > [!NOTE] Make sure that the username and password are not set in the deployment configuration, > or they will overwrite the defined server ID. ## See Also - [Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Deploying Mule Apps to Runtime Fabric using Maven (Mule 4) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric supports using Mule Maven Plugin 3.x to manage and deploy Mule applications. The information in this topic is specific to deploying a Mule application to Mule runtime engine 4.x. ## Prerequisites - Ensure that the Mule Maven Plugin is added to your project See [Add the Mule Maven Plugin to a Mule Project](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp) for instructions. - You understand and have available the number of resources required to deploy to Runtime Fabric See [Resource Allocation on Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) for more information. - The application is already published in Exchange See [Publish and Deploy Exchange Assets Using Maven](https://docs.mulesoft.com/exchange/to-publish-assets-maven). The Mule Maven Facade API (v3) is added as a repository in the distribution management section of your project’s POM file. For example: Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION\_ID/maven default If you publish assets using Exchange API, use Exchange API v2, otherwise schedulers aren’t displayed. ## Add the Mule Maven Plugin to a Mule Project To add the Mule Maven plugin, you need to add its maven dependency to the project: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` From this repository: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` This enables the Mule Maven plugin in your project. > [!IMPORTANT] If `true` is not present, the plugin does not work. ## Configure the Runtime Fabric Deployment Strategy Inside the `plugin` element, add a configuration for your Runtime Fabric deployment, replacing the following placeholder values with your Runtime Fabric information: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## Deploy to Runtime Fabric From the command line in your project’s folder, package the application and execute the deploy goal: ```bash mvn clean deploy -DmuleDeploy ``` ### Exchange Snapshot Assets You can also deploy Exchange snapshot assets into Runtime Fabric. By using `SNAPSHOT` version assets in Anypoint Exchange during the development and testing phase, you can avoid incrementing your application’s version number for small changes. After your `SNAPSHOT` version application has been overwritten in Anypoint Exchange, you can redeploy your `SNAPSHOT` version application to Runtime Fabric via the Mule Maven plugin to deploy the latest changes. To learn more about publishing snapshot assets to Anypoint Exchange, see [Asset Lifecycle State](https://docs.mulesoft.com/exchange/to-publish-assets-maven#asset-lifecycle-state). > [!NOTE] Each time you update your application’s snapshot, redeploy the application to refresh it > with the latest snapshot binaries. > > Because snapshot assets can change after deployment, avoid deploying them into your production > environment. ## Redeploy to Runtime Fabric To redeploy the application, run the same command as you did to deploy. Runtime Fabric rewrites the application you had deployed. ## Authentication Methods When you deploy applications using Mule Maven plugin, you can use different methods to provide your credentials to authenticate against the deployment platform. Depending on the authentication method you use, the parameters to set in the deployment configuration differ:
Authentication MethodDescriptionConfiguration Parameters

Username and password

Use a Runtime Fabric username and password to authenticate.

  • username

  • password

Server

Use credentials stored in a Maven server, configured inside the Maven settings.xml file.

  • server

Authorization Token

Use an authorization token to access the platform.
See Identity Management for a list of supported single sign-on (SSO) types.

  • authToken

Connected Apps

Use a Connected App to perform the authentication programmatically by communicating with Anypoint Platform.
Note that the Connected App credentials must have the Design Center Developer access scope.
See Connected Apps for Developers for instructions about creating Connected Apps.

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType

For a detailed description of the configuration parameters, see the [Runtime Fabric Deployment Parameters Reference](#rtf-deploy-reference). ## Runtime Fabric Deployment Parameters Reference
ParameterDescriptionRequired

runtimeFabricDeployment

Top-Level Element

Yes

uri

Your Anypoint Platform URI.
If not set, defaults to https://anypoint.mulesoft.com.

No

muleVersion

The Mule runtime engine version to run in your Runtime Fabric instance.
Ensure that this value is equal to or higher than the earliest required Mule version of your application. By default, the latest available Mule version is selected.
Example values: 4.6.0 selects the last build where it defaults to Edge channel and Java 8. If you want to choose a different LTS or Edge selection or Java version, specify the full Mule version name as in 4.6.0:1e-java17.
When using Mule Maven plugin versions 3.8.0 and 4.0.0 for deployments, the muleVersion property doesn’t allow you to specify releaseChannel and javaVersion. To specify these properties, upgrade the plugin to version 4.1.1 or later.

No

releaseChannel

Set the name of the release channel used to select the Mule image. Supported values are NONE, EDGE, and LTS. By default, the value is set to EDGE. If the selected release channel doesn’t exist, an error occurs.

No

javaVersion

Set the Java version used in the deploy. Supported values are 8 and 17. By default, the value is set to 8. If the selected Java version doesn’t exist, an error occurs.

No

username

Your Anypoint Platform username

Only when using Anypoint Platform credentials to login.

password

Your Anypoint Platform password

Only when using Anypoint Platform credentials to login.

applicationName

The application name displayed in Runtime Manager after the app deploys.

Yes

target

The Runtime Fabric target name where to deploy the app.

Yes

provider

Provider MC (MuleSoft Control Plane) indicates that the deployment is managed through Anypoint Runtime Manager. Set to MC for Runtime Fabric.

Yes

environment

Target Anypoint Platform environment.
This value must match an environment configured in your Anypoint Platform account, as shown here:

<environment>Sandbox</environment>

Yes

replicas

Specifies the number of replicas, or instances, of the Mule application to deploy. The maximum number of replicas per application is 16.

Only when autoscaling is set to false.

businessGroup

The Business group path of the deployment
Specify the full hierarchical path from the parent organization to the target Business group, for example:

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

This value is omitted if businessGroupId is set. If businessGroup and businessGroupId are not set, the value defaults to the main business group of the user.

No

businessGroupId

The Business group ID of the deployment
Instead of specifying the Business group path, you can specify the Business group ID to deploy your application. If businessGroupId and businessGroup are not set, the value defaults to the main business group of the user.
The Business group ID is a mandatory parameter when you have access only to a specific Business group but not to the parent organization.
This parameter is available in plugin version 3.2.7 and later.

No

deploymentTimeout

The allowed elapsed time, in milliseconds, between the start of the deployment process and the confirmation that the artifact has been deployed

The default value is 600000.

No

server

Maven server with Anypoint Platform credentials
This is only needed if you want to use your credentials stored in your Maven settings.xml file. This is not the Mule server name.

No

properties

Top-Level element
If you need to set properties for the Mule application you are deploying, you can use the <properties> top-level element:

<properties>
  <key>value</key>
</properties>

For example:

<properties>
  <http.port>8081</http.port>
</properties>

No

propertiesFile

Top-level element
Specifies a file that contains properties for the Mule application being deployed. Use this parameter as an alternative to defining properties inline with <properties>. The file must use the Java properties format, with one key=value pair per line.

No

secureProperties

Top-Level element
Use the secureProperties top-level element to set properties for the Mule application and instruct Runtime Fabric to encrypt the values before storing them:

<secureProperties>
  <key>value</key>
</secureProperties>

For example:

<secureProperties>
  <http.port>8081</http.port>
</secureProperties>

No

skip

When set to true, skips the plugin deployment goal.
Its default value is false.

No

skipDeploymentVerification

When set to true, skips the status verification of your deployed app.
Its default value is false.

No

authToken

Specifies the authorization token to access the platform. You can use this authentication method instead of setting username and password.
See Identity Management for a list of supported single sign-on (SSO) types.

Only when using an Authorization token to login.

connectedAppClientId

Specifies the Connected App clientID value.

Only when using Connected Apps credentials to login.

connectedAppClientSecret

Specifies the Connected App secret key.

Only when using Connected Apps credentials to login.

connectedAppGrantType

Specifies the only supported connection type: client_credentials.

Only when using Connected Apps credentials to login.

deploymentSettings

Any of the parameters documented in deploymentSettings Reference

No

### deploymentSettings Parameters Reference
ParameterDescription

enforceDeployingReplicasAcrossNodes

Enforces the deployment of replicas across different nodes. The default value is false.

Configuration example:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy

Accepted valuesDescription

rolling

Maintains availability by updating replicas incrementally. Requires one additional replica’s worth of resources to succeed.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is one less than the total number of nodes.

recreate

Terminates replicas before re-deployment. Re-deployment is quicker than rolling and doesn’t require additional resources.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is equal to the number of nodes.

The default value is rolling.

Configuration example:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

Enables clustering across two or more replicas of the application. The default value is false.

Configuration example:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

resources

cpu

reserved

Specifies the number of cores to allocate for each application replica. The default value is 0.5 vCores.

limit

Specifies the number of max cores to allocate for each replica of the application.
If a reserved configuration is present, ensure that this value is equal or higher.

memory

reserved

Specifies the amount of memory to allocate for each application replica. The default value is 700 MB.

limit

Specifies the maximum memory allocated per application replica. If a reserved configuration is present, ensure that this value is equal or higher.

Configuration example:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound

publicUrl

URL of the deployed application.

Configuration example using wildcard URL:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

Configuration example for path-based routing:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://www.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

Configures the Mule application to use a persistent object store. By default, it is set to false.

jvm

args

Specifies JVM arguments to pass to Runtime Fabric when deploying the application. Use spaces to separate each argument.

Configuration example:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

Not applicable for Runtime Fabric BYOK. By default, it is set to false

disableAmLogForwarding

Disables the application-level log forwarding to Anypoint Monitoring. By default, it is set to false.

autoscaling

Provides CPU based horizontal autoscaling configuration for deployment and redeployment operations. If autoscaling is disabled and the fields minReplicas and maxReplicas are provided, they must match the value of the target.replicas field. See Enable Trace Data Collection. Configuration example:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>
## Encrypt Credentials To use encrypted credentials when deploying, you need to set up your Maven master encrypted password and your `settings-security.xml` file. 1. Create a master password for your Maven configuration. mvn --encrypt-master-password Maven returns your master password encrypted: {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. Create a `settings-security.xml` file in your ~/.m2 repository and add your encrypted master password: ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Encrypt your Anypoint platform password: mvn --encrypt-password Maven returns your Anypoint platform password encrypted: {HTWFGH5BG9QmvJ1B=} 4. Add your encrypted Anypoint Platform password to your `settings.xml` file in the section: ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. In your configuration deployment, reference the credentials injecting the server ID configured in your `settings.xml` file: ```xml ... ... ... my.anypoint.credentials ... ... ... ``` > [!NOTE] Make sure that the username and password are not set in the deployment configuration, > or they will overwrite the defined server ID. ## See Also - [Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) --- product: Runtime Fabric version: 2.10 --- # Deploying Mule Apps to Runtime Fabric Using Runtime Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You deploy Mule applications to Mule runtime servers on Anypoint Runtime Fabric. Applications deployed to a production environment must be deployed to an instance of Runtime Fabric that is separate from non-production applications. After deploying an application you can test the inbound traffic for deployed applications. > [!NOTE] Runtime Manager doesn’t support deploying an application to CloudHub 2.0 or Runtime Fabric > if the asset was previously [soft-deleted](https://docs.mulesoft.com/exchange/to-delete-asset) in Exchange. ## Deploy a Mule Application to Runtime Fabric The full deployment process includes these steps: 1. Select the application and deployment target 2. Configure the deployment target 3. Configure a public endpoint for the application 4. Set up replication 5. (Optional) Enable TLSv1 and TLSv1.1 6. Configure application properties 7. Deploy the application Watch the following video to see how to deploy a Mule application to Runtime Fabric using Runtime Manager: ![](https://play.vidyard.com/CoePGwoZgbY8AZWQxGZQKA.jpg) ### Prerequisites Before deploying an application to Anypoint Runtime Fabric, perform the following: - Review the [Anypoint Platform Roles and Permissions](https://docs.mulesoft.com/runtime-fabric/2.10/#anypoint-platform-roles-and-permissions) necessary for deploying applications to Runtime Fabric. - Ensure that Runtime Fabric is associated with an environment. Refer to [Associating Business Groups and Environments to Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/associate-environments) - Determine the resource allocation requirements for your application. Refer to [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-resource-allocation-self-managed) for more information. - To deploy an application to a specific domain (endpoint), ensure that you have set up domains (endpoints) in your environment. Refer to [Configure Ingress For Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration). - If you’re using Runtime Fabric on Red Hat OpenShift, follow the steps in [Prepare for Deploying Mule Apps to Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.10/install-openshift#prepare-for-deploying-mule-apps-to-red-hat-openshift) to enable app deployment. ### Select the Application and Deployment Target 1. Sign into [Anypoint Platform](https://anypoint.mulesoft.com). 2. Navigate to **Runtime Manager**, and select **Applications**. 3. Click **Deploy application**. 4. Provide a name for your application in the **Application Name** field. The name can contain only lowercase alphanumeric characters, hyphens, and underscores. 5. Click **Choose File** to select the application to deploy, and then select one of the following options: - **Import file from Exchange**: Select a Mule application stored in Anypoint Exchange. - **Upload file**: Select a Mule application file from your filesystem. 6. From the **Deployment Target** drop-down list, select the name of your Runtime Fabric. 7. Select the Mule runtime engine version from the **Runtime Version** drop-down list. ![Runtime Manager UI with Mule Edge release dropdown window](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-rtm-mule-cadence.png) The **Deployment Target**, **Ingress**, **Properties**, **Logs**, and **JVM** tabs are displayed. Use these tabs to enter additional configuration information for your application. To learn more about Mule runtime versions supported by Runtime Fabric, refer to [Anypoint Runtime Fabric Patch Update Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). You can deploy Mule apps with Mule runtime engine versions that are within the standard support or extended support life. Specify the versions through the API or in the Runtime Manager UI. With a Mule runtime engine version in EOL (end of life) support, you can redeploy and restart Mule apps but can not deploy new Mule apps. ### Configure a Public Endpoint for the Application Use the following steps to configure a public endpoint for an application deployed to Runtime Fabric. Available domains and paths for an application come from the ingress resource template configured by your Runtime Fabric administrator. Refer to [Use Custom Ingress Resource Templates in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration) for more information. > [!NOTE] If you do not select a domain, the application is deployed to an empty domain. 1. Select **Ingress**. 2. From the **Host** drop-down list, select a host for the application. 3. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 4. In the **Path** field, add a URL path to the application’s endpoint: ![A host and path are set for the application’s endpoint](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-ingress-endpoint.png) 5. To preview the endpoint, click the generated preview link. 6. To add additional endpoints, click **\+ Add Endpoint**. ### Set Up Replication and Storage After you configure an application’s endpoints, set up replication to configure the number of application instances to deploy. A minimum of two replicas is required for high availability. You set up object to storage to enable data persistence across Mule application replicas and restarts. This option is only available on Mule runtime engine version 4.2.1 or later. If this option is unavailable, contact your IT administrator. Refer to [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.10/persistence-gateway) for more information. 1. Select the **Deployment Target** tab. This tab displays the name and type of the deployment target previously selected. 2. Select the number of replicas, or instances, of the application to deploy. 3. To enable Mule clustering across each replica of the application, enable **Run in Runtime Clustering Mode**. 4. To enforce the deployment of replicas across different nodes, select **Enforce deploying replicas across nodes**. > [!WARNING] If there is an insufficient number of worker nodes or resources available on the > worker nodes needed to deploy each replica, some replicas in the deployment remain in > **Pending** status. The deployment status transitions to **Running** after all replicas are > deployed on different worker nodes. 5. To enable data persistence, select **Use Persistent Object Storage**. 6. Specify the number of **Cores** and amount of **Memory** to allocate to each replica of the application by adjusting the sliders to the appropriate values. If needed, review [determine resource allocation](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-resource-allocation-self-managed) for applications deployed to Runtime Fabric. ### (Optional) Enable TLS v1 and TLS v1.1 Starting with the [August 3, 2021 patch releases](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021), Mule runtime disables TLS v1 and TLS v1.1 by default for all runtime versions. When you deploy an application to Runtime Fabric, you can enable TLS v1 or TLS v1.1 using JVM args. 1. Click the **JVM** tab. 2. In the **Java Virtual Machine arguments** field, add one of the following arguments: - Enable TLSv1.0 and TLSv1.1: `-Drtf.allow.TLSv1.0+` - Enable TLSv1.1: `-Drtf.allow.TLSv1.1` ### Configure Application Properties > [!NOTE] For instructions on protecting application property values, see > [Protect Application Property Values in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/protect-app-properties) Use Runtime Manager to configure any application property values, such as specifying the environment or setting passwords and usernames. Runtime Fabric resolves the property at runtime without exposing the sensitive information. 1. Click the **Properties** tab. 2. Click **Table view**. 3. In the **New Key** field, add a property to protect. 4. In the **New Value** field, add a value. 5. Add additional properties as needed. ### Configure Logging and Log Levels Anypoint Monitoring provides access to log data for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. 1. Click the **Logging** tab. 2. Select the **Enable application logs** option. 3. Select the log level from the drop-down list: - **INFO**: Informative messages - **DEBUG**: Debugging messages - **WARNING**: Warning messages - **ERROR**: Error messages, such as when an exception occurs - **FATAL**: Fatal messages for when an application fails 4. Optionally, set the log level for specific a Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key. 5. Click **Apply Changes**. ### Deploy the Application Now you’re ready to deploy the application. 1. To deploy the application, click **Deploy Application**. If the **Deploy Application** button is disabled, ensure that you have uploaded a valid Mule application file. Also ensure that the Mule runtime engine version you selected is the same as the version used by your application. _Result_: Runtime Manager displays a status message confirming the application deployment. After the deployment starts, you’ll be directed to the applications list page where you can view the deployment status. For newly deployed applications, the status initially displays as **Starting**. The status updates to **Started** if the application is successful. Monitor the application status to ensure that it starts successfully. ## Verify Inbound Traffic for Deployed Applications 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: ```copy 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](https://newapp.example-rtf.dev)`, and `192.168.64.14` is the IP address of a controller machine in your cluster. ```copy curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## Configure Continuous Deployment To set up a workflow for on-premises application deployment on Runtime Fabric, refer to [Workflow for On-Premises Runtime Fabric](https://docs.mulesoft.com/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc). ## Common Issues When deploying applications, you may encounter the following issues: - If your application remains in the **Starting** status for several minutes, this may be due to specifying a lower amount of resources. It’s common for applications to take several minutes to start up when selecting 0.3 cores or lower. - If the application encounters an error during startup, the deployment stops and the status updates to **Failed**. An error message preview is displayed when clicking on the application and viewing the right sidebar. To view the entire message, click on the **Manage Application** button. - An error message indicating `insufficient resources` is returned when Runtime Fabric doesn’t have the CPU cores or memory available for the deployment. When selecting multiple replicas, it’s important to know that the cores and memory specified applies to _each_ replica. - If a re-deployment to an existing running application fails, the previous application remains running and active. This behavior enables zero-downtime application re-deployments. Runtime Manager reports the details and status of the failed deployment to help resolve the failure. ## See Also - [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-resource-allocation-self-managed) - [Deploy a Mule Application to CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [Deploy a Mule Application to a Hybrid Environment](https://docs.mulesoft.com/runtime-manager/deploying-to-your-own-servers) --- product: Runtime Fabric version: 2.11 --- # Deploying Mule Apps to Runtime Fabric Using Runtime Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You deploy Mule applications to Mule runtime servers on Anypoint Runtime Fabric. Applications deployed to a production environment must be deployed to an instance of Runtime Fabric that is separate from non-production applications. After deploying an application you can test the inbound traffic for deployed applications. > [!NOTE] Runtime Manager doesn’t support deploying an application to CloudHub 2.0 or Runtime Fabric > if the asset was previously [soft-deleted](https://docs.mulesoft.com/exchange/to-delete-asset) in Exchange. ## Deploy a Mule Application to Runtime Fabric The full deployment process includes these steps: 1. Select the application and deployment target 2. Configure the deployment target 3. Configure a public endpoint for the application 4. Set up replication 5. (Optional) Enable TLSv1 and TLSv1.1 6. Configure application properties 7. Deploy the application Watch this video to see how to deploy a Mule application to Runtime Fabric using Runtime Manager: ![](https://play.vidyard.com/CoePGwoZgbY8AZWQxGZQKA.jpg) ### Prerequisites Before deploying an application to Anypoint Runtime Fabric, perform this: - Review the [Anypoint Platform Roles and Permissions](https://docs.mulesoft.com/runtime-fabric/2.11/#anypoint-platform-roles-and-permissions) necessary for deploying applications to Runtime Fabric. - Ensure that Runtime Fabric is associated with an environment. Refer to [Associating Business Groups and Environments to Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/associate-environments) - Determine the resource allocation requirements for your application. Refer to [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-resource-allocation-self-managed) for more information. - To deploy an application to a specific domain (endpoint), ensure that you have set up domains (endpoints) in your environment. Refer to [Configure Ingress For Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration). - If you’re using Runtime Fabric on Red Hat OpenShift, follow the steps in [Prepare for Deploying Mule Apps to Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.11/install-openshift#prepare-for-deploying-mule-apps-to-red-hat-openshift) to enable app deployment. ### Select the Application and Deployment Target 1. Sign into [Anypoint Platform](https://anypoint.mulesoft.com). 2. Navigate to **Runtime Manager**, and select **Applications**. 3. Click **Deploy application**. 4. Provide a name for your application in the **Application Name** field. The name can contain only lowercase alphanumeric characters, hyphens, and underscores. 5. Click **Choose File** to select the application to deploy, and then select one of these options: - **Import file from Exchange**: Select a Mule application stored in Anypoint Exchange. - **Upload file**: Select a Mule application file from your filesystem. 6. From the **Deployment Target** drop-down list, select the name of your Runtime Fabric. 7. Select the Mule runtime engine version from the **Runtime Version** drop-down list. ![Runtime Manager UI with Mule Edge release dropdown window](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-rtm-mule-cadence.png) The **Deployment Target**, **Ingress**, **Properties**, **Logs**, and **JVM** tabs are displayed. Use these tabs to enter additional configuration information for your application. To learn more about Mule runtime versions supported by Runtime Fabric, refer to [Anypoint Runtime Fabric Patch Update Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). You can deploy Mule apps with Mule runtime engine versions that are within the standard support or extended support life. Specify the versions through the API or in the Runtime Manager UI. With a Mule runtime engine version in EOL (end of life) support, you can redeploy and restart Mule apps but can not deploy new Mule apps. ### Configure a Public Endpoint for the Application Use these steps to configure a public endpoint for an application deployed to Runtime Fabric. Available domains and paths for an application come from the ingress resource template configured by your Runtime Fabric administrator. Refer to [Use Custom Ingress Resource Templates in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration) for more information. > [!NOTE] If you do not select a domain, the application is deployed to an empty domain. 1. Select **Ingress**. 2. From the **Host** drop-down list, select a host for the application. 3. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 4. In the **Path** field, add a URL path to the application’s endpoint: ![A host and path are set for the application’s endpoint](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-ingress-endpoint.png) 5. To preview the endpoint, click the generated preview link. 6. To add additional endpoints, click **\+ Add Endpoint**. ### Set Up Replication and Storage After you configure an application’s endpoints, set up replication to configure the number of application instances to deploy. A minimum of two replicas is required for high availability. You set up object to storage to enable data persistence across Mule application replicas and restarts. This option is only available on Mule runtime engine version 4.2.1 or later. If this option is unavailable, contact your IT administrator. Refer to [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.11/persistence-gateway) for more information. 1. Select the **Deployment Target** tab. This tab displays the name and type of the deployment target previously selected. 2. Select the number of replicas, or instances, of the application to deploy. 3. To enable Mule clustering across each replica of the application, enable **Run in Runtime Clustering Mode**. 4. To enforce the deployment of replicas across different nodes, select **Enforce deploying replicas across nodes**. > [!WARNING] If there is an insufficient number of worker nodes or resources available on the > worker nodes needed to deploy each replica, some replicas in the deployment remain in > **Pending** status. The deployment status transitions to **Running** after all replicas are > deployed on different worker nodes. 5. To enable data persistence, select **Use Persistent Object Storage**. 6. Specify the number of **Cores** and amount of **Memory** to allocate to each replica of the application by adjusting the sliders to the appropriate values. If needed, review [determine resource allocation](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-resource-allocation-self-managed) for applications deployed to Runtime Fabric. ### (Optional) Enable TLS v1 and TLS v1.1 Starting with the [August 3, 2021 patch releases](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021), Mule runtime disables TLS v1 and TLS v1.1 by default for all runtime versions. When you deploy an application to Runtime Fabric, you can enable TLS v1 or TLS v1.1 using JVM args. 1. Click the **JVM** tab. 2. In the **Java Virtual Machine arguments** field, add one of these arguments: - Enable TLSv1.0 and TLSv1.1: `-Drtf.allow.TLSv1.0+` - Enable TLSv1.1: `-Drtf.allow.TLSv1.1` ### Configure Application Properties > [!NOTE] For instructions on protecting application property values, see > [Protect Application Property Values in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/protect-app-properties) Use Runtime Manager to configure any application property values, such as specifying the environment or setting passwords and usernames. Runtime Fabric resolves the property at runtime without exposing the sensitive information. 1. Click the **Properties** tab. 2. Click **Table view**. 3. In the **New Key** field, add a property to protect. 4. In the **New Value** field, add a value. 5. Add additional properties as needed. ### Configure Logging and Log Levels Anypoint Monitoring provides access to log data for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. 1. Click the **Logging** tab. 2. Select the **Enable application logs** option. 3. Select the log level from the drop-down list: - **INFO**: Informative messages - **DEBUG**: Debugging messages - **WARNING**: Warning messages - **ERROR**: Error messages, such as when an exception occurs - **FATAL**: Fatal messages for when an application fails 4. Optionally, set the log level for specific a Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key. 5. Click **Apply Changes**. ### Deploy the Application Now you’re ready to deploy the application. 1. To deploy the application, click **Deploy Application**. If the **Deploy Application** button is disabled, ensure that you have uploaded a valid Mule application file. Also ensure that the Mule runtime engine version you selected is the same as the version used by your application. _Result_: Runtime Manager displays a status message confirming the application deployment. After the deployment starts, you’ll be directed to the applications list page where you can view the deployment status. For newly deployed applications, the status initially displays as **Starting**. The status updates to **Started** if the application is successful. Monitor the application status to ensure that it starts successfully. ## Verify Inbound Traffic for Deployed Applications 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 this cURL command for verification: ```copy curl -Lvk -XGET {application-path-from-runtime-manager} --resolve {hostname}:443:{ip-address-of-controller} ``` In this example, `{application-path-from-runtime-manager}` is set to `[https://newapp.example-rtf.dev](https://newapp.example-rtf.dev)`, and `192.168.64.14` is the IP address of a controller machine in your cluster. ```copy curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## Configure Continuous Deployment To set up a workflow for on-premises application deployment on Runtime Fabric, refer to [Workflow for On-Premises Runtime Fabric](https://docs.mulesoft.com/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc). ## Common Issues When deploying applications, you may encounter these issues: - If your application remains in the **Starting** status for several minutes, this may be due to specifying a lower amount of resources. It’s common for applications to take several minutes to start up when selecting 0.3 cores or lower. - If the application encounters an error during startup, the deployment stops and the status updates to **Failed**. An error message preview is displayed when clicking on the application and viewing the right sidebar. To view the entire message, click on the **Manage Application** button. - An error message indicating `insufficient resources` is returned when Runtime Fabric doesn’t have the CPU cores or memory available for the deployment. When selecting multiple replicas, it’s important to know that the cores and memory specified applies to _each_ replica. - If a re-deployment to an existing running application fails, the previous application remains running and active. This behavior enables zero-downtime application re-deployments. Runtime Manager reports the details and status of the failed deployment to help resolve the failure. ## See Also - [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-resource-allocation-self-managed) - [Deploy a Mule Application to CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [Deploy a Mule Application to a Hybrid Environment](https://docs.mulesoft.com/runtime-manager/deploying-to-your-own-servers) --- product: Runtime Fabric version: 2.6 --- # Deploying Mule Apps to Runtime Fabric Using Runtime Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You deploy Mule applications to Mule runtime servers on Anypoint Runtime Fabric. Applications deployed to a production environment must be deployed to an instance of Runtime Fabric that is separate from non-production applications. After deploying an application you can test the inbound traffic for deployed applications. ## Deploy a Mule Application to Runtime Fabric The full deployment process includes these steps: 1. Select the application and deployment target 2. Configure the deployment target 3. Configure a public endpoint for the application 4. Set up replication 5. (Optional) Enable TLSv1 and TLSv1.1 6. Configure application properties 7. Deploy the application Watch the following video to see how to deploy a Mule application to Runtime Fabric using Runtime Manager: ![](https://play.vidyard.com/CoePGwoZgbY8AZWQxGZQKA.jpg) ### Prerequisites Before deploying an application to Anypoint Runtime Fabric, perform the following: - Review the [Anypoint Platform Roles and Permissions](https://docs.mulesoft.com/runtime-fabric/2.6/#anypoint-platform-roles-and-permissions) necessary for deploying applications to Runtime Fabric. - Ensure that Runtime Fabric is associated with an environment. Refer to [Associating Business Groups and Environments to Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/associate-environments) - Determine the resource allocation requirements for your application. Refer to [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-resource-allocation-self-managed) for more information. - To deploy an application to a specific domain (endpoint), ensure that you have set up domains (endpoints) in your environment. Refer to [Configure Ingress For Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration). - If you’re using Runtime Fabric on Red Hat OpenShift, follow the steps in [Prepare for Deploying Mule Apps to Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.6/install-openshift#prepare-for-deploying-mule-apps-to-red-hat-openshift) to enable app deployment. ### Select the Application and Deployment Target 1. Sign into [Anypoint Platform](https://anypoint.mulesoft.com). 2. Navigate to **Runtime Manager**, and select **Applications**. 3. Click **Deploy application**. 4. Provide a name for your application in the **Application Name** field. The name can contain only lowercase alphanumeric characters, hyphens, and underscores. 5. Click **Choose File** to select the application to deploy, and then select one of the following options: - **Import file from Exchange**: Select a Mule application stored in Anypoint Exchange. - **Upload file**: Select a Mule application file from your filesystem. 6. From the **Deployment Target** drop-down list, select the name of your Runtime Fabric. 7. Select the Mule runtime engine version from the **Runtime Version** drop-down list. ![Runtime Manager UI with Mule Edge release dropdown window](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-rtm-mule-cadence.png) The **Deployment Target**, **Ingress**, **Properties**, **Logs**, and **JVM** tabs are displayed. Use these tabs to enter additional configuration information for your application. To learn more about Mule runtime versions supported by Runtime Fabric, refer to [Anypoint Runtime Fabric Patch Update Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). You can deploy Mule apps with Mule runtime engine versions that are within the standard support or extended support life. Specify the versions through the API or in the Runtime Manager UI. With a Mule runtime engine version in EOL (end of life) support, you can redeploy and restart Mule apps but can not deploy new Mule apps. ### Configure a Public Endpoint for the Application Use the following steps to configure a public endpoint for an application deployed to Runtime Fabric. Available domains and paths for an application come from the ingress resource template configured by your Runtime Fabric administrator. Refer to [Use Custom Ingress Resource Templates in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration) for more information. > [!NOTE] If you do not select a domain, the application is deployed to an empty domain. 1. Select **Ingress**. 2. From the **Host** drop-down list, select a host for the application. 3. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 4. In the **Path** field, add a URL path to the application’s endpoint: ![A host and path are set for the application’s endpoint](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-ingress-endpoint.png) 5. To preview the endpoint, click the generated preview link. 6. To add additional endpoints, click **\+ Add Endpoint**. ### Set Up Replication and Storage After you configure an application’s endpoints, set up replication to configure the number of application instances to deploy. A minimum of two replicas is required for high availability. You set up object to storage to enable data persistence across Mule application replicas and restarts. This option is only available on Mule runtime engine version 4.2.1 or later. If this option is unavailable, contact your IT administrator. Refer to [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.6/persistence-gateway) for more information. 1. Select the **Deployment Target** tab. This tab displays the name and type of the deployment target previously selected. 2. Select the number of replicas, or instances, of the application to deploy. 3. To enable Mule clustering across each replica of the application, enable **Run in Runtime Clustering Mode**. 4. To enforce the deployment of replicas across different nodes, select **Enforce deploying replicas across nodes**. > [!WARNING] If there is an insufficient number of worker nodes or resources available on the > worker nodes needed to deploy each replica, some replicas in the deployment remain in > **Pending** status. The deployment status transitions to **Running** after all replicas are > deployed on different worker nodes. 5. To enable data persistence, select **Use Persistent Object Storage**. 6. Specify the number of **Cores** and amount of **Memory** to allocate to each replica of the application by adjusting the sliders to the appropriate values. If needed, review [determine resource allocation](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-resource-allocation-self-managed) for applications deployed to Runtime Fabric. ### (Optional) Enable TLS v1 and TLS v1.1 Starting with the [August 3, 2021 patch releases](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021), Mule runtime disables TLS v1 and TLS v1.1 by default for all runtime versions. When you deploy an application to Runtime Fabric, you can enable TLS v1 or TLS v1.1 using JVM args. 1. Click the **JVM** tab. 2. In the **Java Virtual Machine arguments** field, add one of the following arguments: - Enable TLSv1.0 and TLSv1.1: `-Drtf.allow.TLSv1.0+` - Enable TLSv1.1: `-Drtf.allow.TLSv1.1` ### Configure Application Properties > [!NOTE] For instructions on protecting application property values, see > [Protect Application Property Values in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/protect-app-properties) Use Runtime Manager to configure any application property values, such as specifying the environment or setting passwords and usernames. Runtime Fabric resolves the property at runtime without exposing the sensitive information. 1. Click the **Properties** tab. 2. Click **Table view**. 3. In the **New Key** field, add a property to protect. 4. In the **New Value** field, add a value. 5. Add additional properties as needed. ### Configure Logging and Log Levels Anypoint Monitoring provides access to log data for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. 1. Click the **Logging** tab. 2. Select the **Enable application logs** option. 3. Select the log level from the drop-down list: - **INFO**: Informative messages - **DEBUG**: Debugging messages - **WARNING**: Warning messages - **ERROR**: Error messages, such as when an exception occurs - **FATAL**: Fatal messages for when an application fails 4. Optionally, set the log level for specific a Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key. 5. Click **Apply Changes**. ### Deploy the Application Now you’re ready to deploy the application. 1. To deploy the application, click **Deploy Application**. If the **Deploy Application** button is disabled, ensure that you have uploaded a valid Mule application file. Also ensure that the Mule runtime engine version you selected is the same as the version used by your application. _Result_: Runtime Manager displays a status message confirming the application deployment. After the deployment starts, you’ll be directed to the applications list page where you can view the deployment status. For newly deployed applications, the status initially displays as **Starting**. The status updates to **Started** if the application is successful. Monitor the application status to ensure that it starts successfully. ## Verify Inbound Traffic for Deployed Applications 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: ```copy 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](https://newapp.example-rtf.dev)`, and `192.168.64.14` is the IP address of a controller machine in your cluster. ```copy curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## Configure Continuous Deployment To set up a workflow for on-premises application deployment on Runtime Fabric, refer to [Workflow for On-Premises Runtime Fabric](https://docs.mulesoft.com/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc). ## Common Issues When deploying applications, you may encounter the following issues: - If your application remains in the **Starting** status for several minutes, this may be due to specifying a lower amount of resources. It’s common for applications to take several minutes to start up when selecting 0.3 cores or lower. - If the application encounters an error during startup, the deployment stops and the status updates to **Failed**. An error message preview is displayed when clicking on the application and viewing the right sidebar. To view the entire message, click on the **Manage Application** button. - An error message indicating `insufficient resources` is returned when Runtime Fabric doesn’t have the CPU cores or memory available for the deployment. When selecting multiple replicas, it’s important to know that the cores and memory specified applies to _each_ replica. - If a re-deployment to an existing running application fails, the previous application remains running and active. This behavior enables zero-downtime application re-deployments. Runtime Manager reports the details and status of the failed deployment to help resolve the failure. ## See Also - [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-resource-allocation-self-managed) - [Deploy a Mule Application to CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [Deploy a Mule Application to a Hybrid Environment](https://docs.mulesoft.com/runtime-manager/deploying-to-your-own-servers) --- product: Runtime Fabric version: 2.7 --- # Deploying Mule Apps to Runtime Fabric Using Runtime Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You deploy Mule applications to Mule runtime servers on Anypoint Runtime Fabric. Applications deployed to a production environment must be deployed to an instance of Runtime Fabric that is separate from non-production applications. After deploying an application you can test the inbound traffic for deployed applications. ## Deploy a Mule Application to Runtime Fabric The full deployment process includes these steps: 1. Select the application and deployment target 2. Configure the deployment target 3. Configure a public endpoint for the application 4. Set up replication 5. (Optional) Enable TLSv1 and TLSv1.1 6. Configure application properties 7. Deploy the application Watch the following video to see how to deploy a Mule application to Runtime Fabric using Runtime Manager: ![](https://play.vidyard.com/CoePGwoZgbY8AZWQxGZQKA.jpg) ### Prerequisites Before deploying an application to Anypoint Runtime Fabric, perform the following: - Review the [Anypoint Platform Roles and Permissions](https://docs.mulesoft.com/runtime-fabric/2.7/#anypoint-platform-roles-and-permissions) necessary for deploying applications to Runtime Fabric. - Ensure that Runtime Fabric is associated with an environment. Refer to [Associating Business Groups and Environments to Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/associate-environments) - Determine the resource allocation requirements for your application. Refer to [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-resource-allocation-self-managed) for more information. - To deploy an application to a specific domain (endpoint), ensure that you have set up domains (endpoints) in your environment. Refer to [Configure Ingress For Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration). - If you’re using Runtime Fabric on Red Hat OpenShift, follow the steps in [Prepare for Deploying Mule Apps to Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.7/install-openshift#prepare-for-deploying-mule-apps-to-red-hat-openshift) to enable app deployment. ### Select the Application and Deployment Target 1. Sign into [Anypoint Platform](https://anypoint.mulesoft.com). 2. Navigate to **Runtime Manager**, and select **Applications**. 3. Click **Deploy application**. 4. Provide a name for your application in the **Application Name** field. The name can contain only lowercase alphanumeric characters, hyphens, and underscores. 5. Click **Choose File** to select the application to deploy, and then select one of the following options: - **Import file from Exchange**: Select a Mule application stored in Anypoint Exchange. - **Upload file**: Select a Mule application file from your filesystem. 6. From the **Deployment Target** drop-down list, select the name of your Runtime Fabric. 7. Select the Mule runtime engine version from the **Runtime Version** drop-down list. ![Runtime Manager UI with Mule Edge release dropdown window](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-rtm-mule-cadence.png) The **Deployment Target**, **Ingress**, **Properties**, **Logs**, and **JVM** tabs are displayed. Use these tabs to enter additional configuration information for your application. To learn more about Mule runtime versions supported by Runtime Fabric, refer to [Anypoint Runtime Fabric Patch Update Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). You can deploy Mule apps with Mule runtime engine versions that are within the standard support or extended support life. Specify the versions through the API or in the Runtime Manager UI. With a Mule runtime engine version in EOL (end of life) support, you can redeploy and restart Mule apps but can not deploy new Mule apps. ### Configure a Public Endpoint for the Application Use the following steps to configure a public endpoint for an application deployed to Runtime Fabric. Available domains and paths for an application come from the ingress resource template configured by your Runtime Fabric administrator. Refer to [Use Custom Ingress Resource Templates in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration) for more information. > [!NOTE] If you do not select a domain, the application is deployed to an empty domain. 1. Select **Ingress**. 2. From the **Host** drop-down list, select a host for the application. 3. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 4. In the **Path** field, add a URL path to the application’s endpoint: ![A host and path are set for the application’s endpoint](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-ingress-endpoint.png) 5. To preview the endpoint, click the generated preview link. 6. To add additional endpoints, click **\+ Add Endpoint**. ### Set Up Replication and Storage After you configure an application’s endpoints, set up replication to configure the number of application instances to deploy. A minimum of two replicas is required for high availability. You set up object to storage to enable data persistence across Mule application replicas and restarts. This option is only available on Mule runtime engine version 4.2.1 or later. If this option is unavailable, contact your IT administrator. Refer to [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.7/persistence-gateway) for more information. 1. Select the **Deployment Target** tab. This tab displays the name and type of the deployment target previously selected. 2. Select the number of replicas, or instances, of the application to deploy. 3. To enable Mule clustering across each replica of the application, enable **Run in Runtime Clustering Mode**. 4. To enforce the deployment of replicas across different nodes, select **Enforce deploying replicas across nodes**. > [!WARNING] If there is an insufficient number of worker nodes or resources available on the > worker nodes needed to deploy each replica, some replicas in the deployment remain in > **Pending** status. The deployment status transitions to **Running** after all replicas are > deployed on different worker nodes. 5. To enable data persistence, select **Use Persistent Object Storage**. 6. Specify the number of **Cores** and amount of **Memory** to allocate to each replica of the application by adjusting the sliders to the appropriate values. If needed, review [determine resource allocation](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-resource-allocation-self-managed) for applications deployed to Runtime Fabric. ### (Optional) Enable TLS v1 and TLS v1.1 Starting with the [August 3, 2021 patch releases](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021), Mule runtime disables TLS v1 and TLS v1.1 by default for all runtime versions. When you deploy an application to Runtime Fabric, you can enable TLS v1 or TLS v1.1 using JVM args. 1. Click the **JVM** tab. 2. In the **Java Virtual Machine arguments** field, add one of the following arguments: - Enable TLSv1.0 and TLSv1.1: `-Drtf.allow.TLSv1.0+` - Enable TLSv1.1: `-Drtf.allow.TLSv1.1` ### Configure Application Properties > [!NOTE] For instructions on protecting application property values, see > [Protect Application Property Values in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/protect-app-properties) Use Runtime Manager to configure any application property values, such as specifying the environment or setting passwords and usernames. Runtime Fabric resolves the property at runtime without exposing the sensitive information. 1. Click the **Properties** tab. 2. Click **Table view**. 3. In the **New Key** field, add a property to protect. 4. In the **New Value** field, add a value. 5. Add additional properties as needed. ### Configure Logging and Log Levels Anypoint Monitoring provides access to log data for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. 1. Click the **Logging** tab. 2. Select the **Enable application logs** option. 3. Select the log level from the drop-down list: - **INFO**: Informative messages - **DEBUG**: Debugging messages - **WARNING**: Warning messages - **ERROR**: Error messages, such as when an exception occurs - **FATAL**: Fatal messages for when an application fails 4. Optionally, set the log level for specific a Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key. 5. Click **Apply Changes**. ### Deploy the Application Now you’re ready to deploy the application. 1. To deploy the application, click **Deploy Application**. If the **Deploy Application** button is disabled, ensure that you have uploaded a valid Mule application file. Also ensure that the Mule runtime engine version you selected is the same as the version used by your application. _Result_: Runtime Manager displays a status message confirming the application deployment. After the deployment starts, you’ll be directed to the applications list page where you can view the deployment status. For newly deployed applications, the status initially displays as **Starting**. The status updates to **Started** if the application is successful. Monitor the application status to ensure that it starts successfully. ## Verify Inbound Traffic for Deployed Applications 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: ```copy 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](https://newapp.example-rtf.dev)`, and `192.168.64.14` is the IP address of a controller machine in your cluster. ```copy curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## Configure Continuous Deployment To set up a workflow for on-premises application deployment on Runtime Fabric, refer to [Workflow for On-Premises Runtime Fabric](https://docs.mulesoft.com/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc). ## Common Issues When deploying applications, you may encounter the following issues: - If your application remains in the **Starting** status for several minutes, this may be due to specifying a lower amount of resources. It’s common for applications to take several minutes to start up when selecting 0.3 cores or lower. - If the application encounters an error during startup, the deployment stops and the status updates to **Failed**. An error message preview is displayed when clicking on the application and viewing the right sidebar. To view the entire message, click on the **Manage Application** button. - An error message indicating `insufficient resources` is returned when Runtime Fabric doesn’t have the CPU cores or memory available for the deployment. When selecting multiple replicas, it’s important to know that the cores and memory specified applies to _each_ replica. - If a re-deployment to an existing running application fails, the previous application remains running and active. This behavior enables zero-downtime application re-deployments. Runtime Manager reports the details and status of the failed deployment to help resolve the failure. ## See Also - [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-resource-allocation-self-managed) - [Deploy a Mule Application to CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [Deploy a Mule Application to a Hybrid Environment](https://docs.mulesoft.com/runtime-manager/deploying-to-your-own-servers) --- product: Runtime Fabric version: 2.8 --- # Deploying Mule Apps to Runtime Fabric Using Runtime Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You deploy Mule applications to Mule runtime servers on Anypoint Runtime Fabric. Applications deployed to a production environment must be deployed to an instance of Runtime Fabric that is separate from non-production applications. After deploying an application you can test the inbound traffic for deployed applications. > [!NOTE] Runtime Manager doesn’t support deploying an application to CloudHub 2.0 or Runtime Fabric > if the asset was previously [soft-deleted](https://docs.mulesoft.com/exchange/to-delete-asset) in Exchange. ## Deploy a Mule Application to Runtime Fabric The full deployment process includes these steps: 1. Select the application and deployment target 2. Configure the deployment target 3. Configure a public endpoint for the application 4. Set up replication 5. (Optional) Enable TLSv1 and TLSv1.1 6. Configure application properties 7. Deploy the application Watch the following video to see how to deploy a Mule application to Runtime Fabric using Runtime Manager: ![](https://play.vidyard.com/CoePGwoZgbY8AZWQxGZQKA.jpg) ### Prerequisites Before deploying an application to Anypoint Runtime Fabric, perform the following: - Review the [Anypoint Platform Roles and Permissions](https://docs.mulesoft.com/runtime-fabric/2.8/#anypoint-platform-roles-and-permissions) necessary for deploying applications to Runtime Fabric. - Ensure that Runtime Fabric is associated with an environment. Refer to [Associating Business Groups and Environments to Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/associate-environments) - Determine the resource allocation requirements for your application. Refer to [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-resource-allocation-self-managed) for more information. - To deploy an application to a specific domain (endpoint), ensure that you have set up domains (endpoints) in your environment. Refer to [Configure Ingress For Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration). - If you’re using Runtime Fabric on Red Hat OpenShift, follow the steps in [Prepare for Deploying Mule Apps to Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.8/install-openshift#prepare-for-deploying-mule-apps-to-red-hat-openshift) to enable app deployment. ### Select the Application and Deployment Target 1. Sign into [Anypoint Platform](https://anypoint.mulesoft.com). 2. Navigate to **Runtime Manager**, and select **Applications**. 3. Click **Deploy application**. 4. Provide a name for your application in the **Application Name** field. The name can contain only lowercase alphanumeric characters, hyphens, and underscores. 5. Click **Choose File** to select the application to deploy, and then select one of the following options: - **Import file from Exchange**: Select a Mule application stored in Anypoint Exchange. - **Upload file**: Select a Mule application file from your filesystem. 6. From the **Deployment Target** drop-down list, select the name of your Runtime Fabric. 7. Select the Mule runtime engine version from the **Runtime Version** drop-down list. ![Runtime Manager UI with Mule Edge release dropdown window](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-rtm-mule-cadence.png) The **Deployment Target**, **Ingress**, **Properties**, **Logs**, and **JVM** tabs are displayed. Use these tabs to enter additional configuration information for your application. To learn more about Mule runtime versions supported by Runtime Fabric, refer to [Anypoint Runtime Fabric Patch Update Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). You can deploy Mule apps with Mule runtime engine versions that are within the standard support or extended support life. Specify the versions through the API or in the Runtime Manager UI. With a Mule runtime engine version in EOL (end of life) support, you can redeploy and restart Mule apps but can not deploy new Mule apps. ### Configure a Public Endpoint for the Application Use the following steps to configure a public endpoint for an application deployed to Runtime Fabric. Available domains and paths for an application come from the ingress resource template configured by your Runtime Fabric administrator. Refer to [Use Custom Ingress Resource Templates in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration) for more information. > [!NOTE] If you do not select a domain, the application is deployed to an empty domain. 1. Select **Ingress**. 2. From the **Host** drop-down list, select a host for the application. 3. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 4. In the **Path** field, add a URL path to the application’s endpoint: ![A host and path are set for the application’s endpoint](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-ingress-endpoint.png) 5. To preview the endpoint, click the generated preview link. 6. To add additional endpoints, click **\+ Add Endpoint**. ### Set Up Replication and Storage After you configure an application’s endpoints, set up replication to configure the number of application instances to deploy. A minimum of two replicas is required for high availability. You set up object to storage to enable data persistence across Mule application replicas and restarts. This option is only available on Mule runtime engine version 4.2.1 or later. If this option is unavailable, contact your IT administrator. Refer to [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.8/persistence-gateway) for more information. 1. Select the **Deployment Target** tab. This tab displays the name and type of the deployment target previously selected. 2. Select the number of replicas, or instances, of the application to deploy. 3. To enable Mule clustering across each replica of the application, enable **Run in Runtime Clustering Mode**. 4. To enforce the deployment of replicas across different nodes, select **Enforce deploying replicas across nodes**. > [!WARNING] If there is an insufficient number of worker nodes or resources available on the > worker nodes needed to deploy each replica, some replicas in the deployment remain in > **Pending** status. The deployment status transitions to **Running** after all replicas are > deployed on different worker nodes. 5. To enable data persistence, select **Use Persistent Object Storage**. 6. Specify the number of **Cores** and amount of **Memory** to allocate to each replica of the application by adjusting the sliders to the appropriate values. If needed, review [determine resource allocation](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-resource-allocation-self-managed) for applications deployed to Runtime Fabric. ### (Optional) Enable TLS v1 and TLS v1.1 Starting with the [August 3, 2021 patch releases](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021), Mule runtime disables TLS v1 and TLS v1.1 by default for all runtime versions. When you deploy an application to Runtime Fabric, you can enable TLS v1 or TLS v1.1 using JVM args. 1. Click the **JVM** tab. 2. In the **Java Virtual Machine arguments** field, add one of the following arguments: - Enable TLSv1.0 and TLSv1.1: `-Drtf.allow.TLSv1.0+` - Enable TLSv1.1: `-Drtf.allow.TLSv1.1` ### Configure Application Properties > [!NOTE] For instructions on protecting application property values, see > [Protect Application Property Values in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/protect-app-properties) Use Runtime Manager to configure any application property values, such as specifying the environment or setting passwords and usernames. Runtime Fabric resolves the property at runtime without exposing the sensitive information. 1. Click the **Properties** tab. 2. Click **Table view**. 3. In the **New Key** field, add a property to protect. 4. In the **New Value** field, add a value. 5. Add additional properties as needed. ### Configure Logging and Log Levels Anypoint Monitoring provides access to log data for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. 1. Click the **Logging** tab. 2. Select the **Enable application logs** option. 3. Select the log level from the drop-down list: - **INFO**: Informative messages - **DEBUG**: Debugging messages - **WARNING**: Warning messages - **ERROR**: Error messages, such as when an exception occurs - **FATAL**: Fatal messages for when an application fails 4. Optionally, set the log level for specific a Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key. 5. Click **Apply Changes**. ### Deploy the Application Now you’re ready to deploy the application. 1. To deploy the application, click **Deploy Application**. If the **Deploy Application** button is disabled, ensure that you have uploaded a valid Mule application file. Also ensure that the Mule runtime engine version you selected is the same as the version used by your application. _Result_: Runtime Manager displays a status message confirming the application deployment. After the deployment starts, you’ll be directed to the applications list page where you can view the deployment status. For newly deployed applications, the status initially displays as **Starting**. The status updates to **Started** if the application is successful. Monitor the application status to ensure that it starts successfully. ## Verify Inbound Traffic for Deployed Applications 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: ```copy 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](https://newapp.example-rtf.dev)`, and `192.168.64.14` is the IP address of a controller machine in your cluster. ```copy curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## Configure Continuous Deployment To set up a workflow for on-premises application deployment on Runtime Fabric, refer to [Workflow for On-Premises Runtime Fabric](https://docs.mulesoft.com/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc). ## Common Issues When deploying applications, you may encounter the following issues: - If your application remains in the **Starting** status for several minutes, this may be due to specifying a lower amount of resources. It’s common for applications to take several minutes to start up when selecting 0.3 cores or lower. - If the application encounters an error during startup, the deployment stops and the status updates to **Failed**. An error message preview is displayed when clicking on the application and viewing the right sidebar. To view the entire message, click on the **Manage Application** button. - An error message indicating `insufficient resources` is returned when Runtime Fabric doesn’t have the CPU cores or memory available for the deployment. When selecting multiple replicas, it’s important to know that the cores and memory specified applies to _each_ replica. - If a re-deployment to an existing running application fails, the previous application remains running and active. This behavior enables zero-downtime application re-deployments. Runtime Manager reports the details and status of the failed deployment to help resolve the failure. ## See Also - [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-resource-allocation-self-managed) - [Deploy a Mule Application to CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [Deploy a Mule Application to a Hybrid Environment](https://docs.mulesoft.com/runtime-manager/deploying-to-your-own-servers) --- product: Runtime Fabric version: 2.9 --- # Deploying Mule Apps to Runtime Fabric Using Runtime Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You deploy Mule applications to Mule runtime servers on Anypoint Runtime Fabric. Applications deployed to a production environment must be deployed to an instance of Runtime Fabric that is separate from non-production applications. After deploying an application you can test the inbound traffic for deployed applications. > [!NOTE] Runtime Manager doesn’t support deploying an application to CloudHub 2.0 or Runtime Fabric > if the asset was previously [soft-deleted](https://docs.mulesoft.com/exchange/to-delete-asset) in Exchange. ## Deploy a Mule Application to Runtime Fabric The full deployment process includes these steps: 1. Select the application and deployment target 2. Configure the deployment target 3. Configure a public endpoint for the application 4. Set up replication 5. (Optional) Enable TLSv1 and TLSv1.1 6. Configure application properties 7. Deploy the application Watch the following video to see how to deploy a Mule application to Runtime Fabric using Runtime Manager: ![](https://play.vidyard.com/CoePGwoZgbY8AZWQxGZQKA.jpg) ### Prerequisites Before deploying an application to Anypoint Runtime Fabric, perform the following: - Review the [Anypoint Platform Roles and Permissions](https://docs.mulesoft.com/runtime-fabric/2.9/#anypoint-platform-roles-and-permissions) necessary for deploying applications to Runtime Fabric. - Ensure that Runtime Fabric is associated with an environment. Refer to [Associating Business Groups and Environments to Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/associate-environments) - Determine the resource allocation requirements for your application. Refer to [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-resource-allocation-self-managed) for more information. - To deploy an application to a specific domain (endpoint), ensure that you have set up domains (endpoints) in your environment. Refer to [Configure Ingress For Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration). - If you’re using Runtime Fabric on Red Hat OpenShift, follow the steps in [Prepare for Deploying Mule Apps to Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/2.9/install-openshift#prepare-for-deploying-mule-apps-to-red-hat-openshift) to enable app deployment. ### Select the Application and Deployment Target 1. Sign into [Anypoint Platform](https://anypoint.mulesoft.com). 2. Navigate to **Runtime Manager**, and select **Applications**. 3. Click **Deploy application**. 4. Provide a name for your application in the **Application Name** field. The name can contain only lowercase alphanumeric characters, hyphens, and underscores. 5. Click **Choose File** to select the application to deploy, and then select one of the following options: - **Import file from Exchange**: Select a Mule application stored in Anypoint Exchange. - **Upload file**: Select a Mule application file from your filesystem. 6. From the **Deployment Target** drop-down list, select the name of your Runtime Fabric. 7. Select the Mule runtime engine version from the **Runtime Version** drop-down list. ![Runtime Manager UI with Mule Edge release dropdown window](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-rtm-mule-cadence.png) The **Deployment Target**, **Ingress**, **Properties**, **Logs**, and **JVM** tabs are displayed. Use these tabs to enter additional configuration information for your application. To learn more about Mule runtime versions supported by Runtime Fabric, refer to [Anypoint Runtime Fabric Patch Update Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). You can deploy Mule apps with Mule runtime engine versions that are within the standard support or extended support life. Specify the versions through the API or in the Runtime Manager UI. With a Mule runtime engine version in EOL (end of life) support, you can redeploy and restart Mule apps but can not deploy new Mule apps. ### Configure a Public Endpoint for the Application Use the following steps to configure a public endpoint for an application deployed to Runtime Fabric. Available domains and paths for an application come from the ingress resource template configured by your Runtime Fabric administrator. Refer to [Use Custom Ingress Resource Templates in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration) for more information. > [!NOTE] If you do not select a domain, the application is deployed to an empty domain. 1. Select **Ingress**. 2. From the **Host** drop-down list, select a host for the application. 3. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 4. In the **Path** field, add a URL path to the application’s endpoint: ![A host and path are set for the application’s endpoint](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-ingress-endpoint.png) 5. To preview the endpoint, click the generated preview link. 6. To add additional endpoints, click **\+ Add Endpoint**. ### Set Up Replication and Storage After you configure an application’s endpoints, set up replication to configure the number of application instances to deploy. A minimum of two replicas is required for high availability. You set up object to storage to enable data persistence across Mule application replicas and restarts. This option is only available on Mule runtime engine version 4.2.1 or later. If this option is unavailable, contact your IT administrator. Refer to [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/2.9/persistence-gateway) for more information. 1. Select the **Deployment Target** tab. This tab displays the name and type of the deployment target previously selected. 2. Select the number of replicas, or instances, of the application to deploy. 3. To enable Mule clustering across each replica of the application, enable **Run in Runtime Clustering Mode**. 4. To enforce the deployment of replicas across different nodes, select **Enforce deploying replicas across nodes**. > [!WARNING] If there is an insufficient number of worker nodes or resources available on the > worker nodes needed to deploy each replica, some replicas in the deployment remain in > **Pending** status. The deployment status transitions to **Running** after all replicas are > deployed on different worker nodes. 5. To enable data persistence, select **Use Persistent Object Storage**. 6. Specify the number of **Cores** and amount of **Memory** to allocate to each replica of the application by adjusting the sliders to the appropriate values. If needed, review [determine resource allocation](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-resource-allocation-self-managed) for applications deployed to Runtime Fabric. ### (Optional) Enable TLS v1 and TLS v1.1 Starting with the [August 3, 2021 patch releases](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021), Mule runtime disables TLS v1 and TLS v1.1 by default for all runtime versions. When you deploy an application to Runtime Fabric, you can enable TLS v1 or TLS v1.1 using JVM args. 1. Click the **JVM** tab. 2. In the **Java Virtual Machine arguments** field, add one of the following arguments: - Enable TLSv1.0 and TLSv1.1: `-Drtf.allow.TLSv1.0+` - Enable TLSv1.1: `-Drtf.allow.TLSv1.1` ### Configure Application Properties > [!NOTE] For instructions on protecting application property values, see > [Protect Application Property Values in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/protect-app-properties) Use Runtime Manager to configure any application property values, such as specifying the environment or setting passwords and usernames. Runtime Fabric resolves the property at runtime without exposing the sensitive information. 1. Click the **Properties** tab. 2. Click **Table view**. 3. In the **New Key** field, add a property to protect. 4. In the **New Value** field, add a value. 5. Add additional properties as needed. ### Configure Logging and Log Levels Anypoint Monitoring provides access to log data for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. 1. Click the **Logging** tab. 2. Select the **Enable application logs** option. 3. Select the log level from the drop-down list: - **INFO**: Informative messages - **DEBUG**: Debugging messages - **WARNING**: Warning messages - **ERROR**: Error messages, such as when an exception occurs - **FATAL**: Fatal messages for when an application fails 4. Optionally, set the log level for specific a Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key. 5. Click **Apply Changes**. ### Deploy the Application Now you’re ready to deploy the application. 1. To deploy the application, click **Deploy Application**. If the **Deploy Application** button is disabled, ensure that you have uploaded a valid Mule application file. Also ensure that the Mule runtime engine version you selected is the same as the version used by your application. _Result_: Runtime Manager displays a status message confirming the application deployment. After the deployment starts, you’ll be directed to the applications list page where you can view the deployment status. For newly deployed applications, the status initially displays as **Starting**. The status updates to **Started** if the application is successful. Monitor the application status to ensure that it starts successfully. ## Verify Inbound Traffic for Deployed Applications 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: ```copy 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](https://newapp.example-rtf.dev)`, and `192.168.64.14` is the IP address of a controller machine in your cluster. ```copy curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## Configure Continuous Deployment To set up a workflow for on-premises application deployment on Runtime Fabric, refer to [Workflow for On-Premises Runtime Fabric](https://docs.mulesoft.com/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc). ## Common Issues When deploying applications, you may encounter the following issues: - If your application remains in the **Starting** status for several minutes, this may be due to specifying a lower amount of resources. It’s common for applications to take several minutes to start up when selecting 0.3 cores or lower. - If the application encounters an error during startup, the deployment stops and the status updates to **Failed**. An error message preview is displayed when clicking on the application and viewing the right sidebar. To view the entire message, click on the **Manage Application** button. - An error message indicating `insufficient resources` is returned when Runtime Fabric doesn’t have the CPU cores or memory available for the deployment. When selecting multiple replicas, it’s important to know that the cores and memory specified applies to _each_ replica. - If a re-deployment to an existing running application fails, the previous application remains running and active. This behavior enables zero-downtime application re-deployments. Runtime Manager reports the details and status of the failed deployment to help resolve the failure. ## See Also - [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-resource-allocation-self-managed) - [Deploy a Mule Application to CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [Deploy a Mule Application to a Hybrid Environment](https://docs.mulesoft.com/runtime-manager/deploying-to-your-own-servers) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Deploying Mule Apps to Runtime Fabric Using Runtime Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You deploy Mule applications to Mule runtime servers on Anypoint Runtime Fabric. Applications deployed to a production environment must be deployed to an instance of Runtime Fabric that is separate from non-production applications. After deploying an application you can test the inbound traffic for deployed applications. > [!NOTE] Runtime Manager doesn’t support deploying an application to CloudHub 2.0 or Runtime Fabric > if the asset was previously [soft-deleted](https://docs.mulesoft.com/exchange/to-delete-asset) in Exchange. ## Deploy a Mule Application to Runtime Fabric The full deployment process includes these steps: 1. Select the application and deployment target 2. Configure the deployment target 3. Configure a public endpoint for the application 4. Set up replication 5. (Optional) Enable TLSv1 and TLSv1.1 6. Configure application properties 7. Deploy the application Watch the following video to see how to deploy a Mule application to Runtime Fabric using Runtime Manager: ![](https://play.vidyard.com/CoePGwoZgbY8AZWQxGZQKA.jpg) ### Prerequisites Before deploying an application to Anypoint Runtime Fabric, perform the following: - Review the [Anypoint Platform Roles and Permissions](https://docs.mulesoft.com/runtime-fabric/latest/#anypoint-platform-roles-and-permissions) necessary for deploying applications to Runtime Fabric. - Ensure that Runtime Fabric is associated with an environment. Refer to [Associating Business Groups and Environments to Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/associate-environments) - Determine the resource allocation requirements for your application. Refer to [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) for more information. - To deploy an application to a specific domain (endpoint), ensure that you have set up domains (endpoints) in your environment. Refer to [Configure Ingress For Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration). - If you’re using Runtime Fabric on Red Hat OpenShift, follow the steps in [Prepare for Deploying Mule Apps to Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/latest/install-openshift#prepare-for-deploying-mule-apps-to-red-hat-openshift) to enable app deployment. ### Select the Application and Deployment Target 1. Sign into [Anypoint Platform](https://anypoint.mulesoft.com). 2. Navigate to **Runtime Manager**, and select **Applications**. 3. Click **Deploy application**. 4. Provide a name for your application in the **Application Name** field. The name can contain only lowercase alphanumeric characters, hyphens, and underscores. 5. Click **Choose File** to select the application to deploy, and then select one of the following options: - **Import file from Exchange**: Select a Mule application stored in Anypoint Exchange. - **Upload file**: Select a Mule application file from your filesystem. 6. From the **Deployment Target** drop-down list, select the name of your Runtime Fabric. 7. Select the Mule runtime engine version from the **Runtime Version** drop-down list. ![Runtime Manager UI with Mule Edge release dropdown window](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-rtm-mule-cadence.png) The **Deployment Target**, **Ingress**, **Properties**, **Logs**, and **JVM** tabs are displayed. Use these tabs to enter additional configuration information for your application. To learn more about Mule runtime versions supported by Runtime Fabric, refer to [Anypoint Runtime Fabric Patch Update Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). You can deploy Mule apps with Mule runtime engine versions that are within the standard support or extended support life. Specify the versions through the API or in the Runtime Manager UI. With a Mule runtime engine version in EOL (end of life) support, you can redeploy and restart Mule apps but can not deploy new Mule apps. ### Configure a Public Endpoint for the Application Use the following steps to configure a public endpoint for an application deployed to Runtime Fabric. Available domains and paths for an application come from the ingress resource template configured by your Runtime Fabric administrator. Refer to [Use Custom Ingress Resource Templates in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration) for more information. > [!NOTE] If you do not select a domain, the application is deployed to an empty domain. 1. Select **Ingress**. 2. From the **Host** drop-down list, select a host for the application. 3. If the hostname uses a wildcard, add a subdomain in the **Subdomain** field. The **Subdomain** field is only available if the hostname uses a wildcard. 4. In the **Path** field, add a URL path to the application’s endpoint: ![A host and path are set for the application’s endpoint](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-ingress-endpoint.png) 5. To preview the endpoint, click the generated preview link. 6. To add additional endpoints, click **\+ Add Endpoint**. ### Set Up Replication and Storage After you configure an application’s endpoints, set up replication to configure the number of application instances to deploy. A minimum of two replicas is required for high availability. You set up object to storage to enable data persistence across Mule application replicas and restarts. This option is only available on Mule runtime engine version 4.2.1 or later. If this option is unavailable, contact your IT administrator. Refer to [Persistence Gateway](https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway) for more information. 1. Select the **Deployment Target** tab. This tab displays the name and type of the deployment target previously selected. 2. Select the number of replicas, or instances, of the application to deploy. 3. To enable Mule clustering across each replica of the application, enable **Run in Runtime Clustering Mode**. 4. To enforce the deployment of replicas across different nodes, select **Enforce deploying replicas across nodes**. > [!WARNING] If there is an insufficient number of worker nodes or resources available on the > worker nodes needed to deploy each replica, some replicas in the deployment remain in > **Pending** status. The deployment status transitions to **Running** after all replicas are > deployed on different worker nodes. 5. To enable data persistence, select **Use Persistent Object Storage**. 6. Specify the number of **Cores** and amount of **Memory** to allocate to each replica of the application by adjusting the sliders to the appropriate values. If needed, review [determine resource allocation](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) for applications deployed to Runtime Fabric. ### (Optional) Enable TLS v1 and TLS v1.1 Starting with the [August 3, 2021 patch releases](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021), Mule runtime disables TLS v1 and TLS v1.1 by default for all runtime versions. When you deploy an application to Runtime Fabric, you can enable TLS v1 or TLS v1.1 using JVM args. 1. Click the **JVM** tab. 2. In the **Java Virtual Machine arguments** field, add one of the following arguments: - Enable TLSv1.0 and TLSv1.1: `-Drtf.allow.TLSv1.0+` - Enable TLSv1.1: `-Drtf.allow.TLSv1.1` ### Configure Application Properties > [!NOTE] For instructions on protecting application property values, see > [Protect Application Property Values in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/protect-app-properties) Use Runtime Manager to configure any application property values, such as specifying the environment or setting passwords and usernames. Runtime Fabric resolves the property at runtime without exposing the sensitive information. 1. Click the **Properties** tab. 2. Click **Table view**. 3. In the **New Key** field, add a property to protect. 4. In the **New Value** field, add a value. 5. Add additional properties as needed. ### Configure Logging and Log Levels Anypoint Monitoring provides access to log data for applications deployed to Runtime Fabric. To access logs, you need an [Anypoint Platform Integration Advanced](https://www.mulesoft.com/anypoint-pricing) subscription. For log forwarding configuration details, see [Enable and Configure Log Forwarding](https://docs.mulesoft.com/runtime-fabric/latest/use-anypoint-monitoring#logs). > [!NOTE] Runtime Manager provides two ways to configure application log levels: the **Logging** tab > (recommended) and the **Properties** tab (legacy). Both methods work, but they write to different > configuration paths in the application YAML file. Use the **Logging** tab unless you need > TRACE-level logging, which is only available through the **Properties** tab. Choose one method and > apply it consistently — mixing both methods for the same application can produce unexpected > results. 1. Click the **Logging** tab. 2. Select the **Enable application logs** option. 3. Select the log level from the drop-down list: - **INFO**: Informative messages - **DEBUG**: Debugging messages - **WARNING**: Warning messages - **ERROR**: Error messages, such as when an exception occurs - **FATAL**: Fatal messages for when an application fails 4. Optionally, set the log level for a specific Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key. 5. Click **Apply Changes**. ### Deploy the Application Now you’re ready to deploy the application. 1. To deploy the application, click **Deploy Application**. If the **Deploy Application** button is disabled, ensure that you have uploaded a valid Mule application file. Also ensure that the Mule runtime engine version you selected is the same as the version used by your application. _Result_: Runtime Manager displays a status message confirming the application deployment. After the deployment starts, you’ll be directed to the applications list page where you can view the deployment status. For newly deployed applications, the status initially displays as **Starting**. The status updates to **Started** if the application is successful. Monitor the application status to ensure that it starts successfully. > [!NOTE] The runtime environment caches application artifacts based on their Maven coordinates > (`groupId:artifactId:version`). If you re-publish an Exchange asset under the same version, the > cached artifact is served instead of the updated one. Always increment the version number when > artifact content changes, or use the `-SNAPSHOT` qualifier for mutable artifacts during > development. For details, see [Exchange Asset Caching](https://docs.mulesoft.com/runtime-fabric/latest/deploy-index#_exchange_asset_caching). ## Verify Inbound Traffic for Deployed Applications 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: ```copy 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](https://newapp.example-rtf.dev)`, and `192.168.64.14` is the IP address of a controller machine in your cluster. ```copy curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## Configure Continuous Deployment To set up a workflow for on-premises application deployment on Runtime Fabric, refer to [Workflow for On-Premises Runtime Fabric](https://docs.mulesoft.com/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc). ## Common Issues When deploying applications, you may encounter the following issues: - If your application remains in the **Starting** status for several minutes, this may be due to specifying a lower amount of resources. It’s common for applications to take several minutes to start up when selecting 0.3 cores or lower. - If the application encounters an error during startup, the deployment stops and the status updates to **Failed**. An error message preview is displayed when clicking on the application and viewing the right sidebar. To view the entire message, click on the **Manage Application** button. - An error message indicating `insufficient resources` is returned when Runtime Fabric doesn’t have the CPU cores or memory available for the deployment. When selecting multiple replicas, it’s important to know that the cores and memory specified applies to _each_ replica. - If a re-deployment to an existing running application fails, the previous application remains running and active. This behavior enables zero-downtime application re-deployments. Runtime Manager reports the details and status of the failed deployment to help resolve the failure. ## See Also - [Determine Application Resource Allocation on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) - [Deploy a Mule Application to CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [Deploy a Mule Application to a Hybrid Environment](https://docs.mulesoft.com/runtime-manager/deploying-to-your-own-servers) --- product: Runtime Fabric version: 2.10 --- # Deployment Status Messages for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Manager shows deployment status messages when you deploy a Mule app for the first time or when you make changes to an existing Mule app deployed to Runtime Fabric: - [Application Deployment Status State](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#application_deploy_states) These statuses are related to the general application deployment, such as Deleted, Applying, Applied, Failed, or Unknown messages. - [Replica Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#replica_status_states) These statuses appear when you apply new, or changed, configurations to a deployed Mule app. - [Warning Messages Status States](#warning-status) These statuses appear when you receive a warning message while a deployment is in progress. - [App Namespaces Status States](#app-namespaces-status-states) These statuses appear when there are issues with app namespaces during deployment. ## Warning Messages Status States When you deploy a Mule app or make a change to an existing Mule app deployed to Runtime Fabric, Runtime Manager waits a minute and then begins to actively check the reported status of its replicas. If the status is other than STARTED or STOPPED, a warning message shows. A warning message does not necessarily mean there is something wrong with your Mule app or cluster. Understanding the meaning of these messages is important, as some warnings are only temporary while others can be permanent failures. Warning messages appear with the following legend: `1 or more replicas in unexpected state:` followed by the specific description. For example: `1 or more replicas in unexpected state: [Kubernetes] Container "any point-monitoring" - PodInitializing` > [!NOTE] If a warning message persists and the related issue does not resolve automatically, work > with your IT department and developer team to check the deployment and pod status for > troubleshooting. ## Permanent versus Temporary Warning Messages Permanent warning messages usually require your action to fix the related issue. Instead, temporary warning messages disappear after some time. Check warning messages with your Kubernetes admin if they don’t disappear in a reasonable time. For example, if a node stops working, some pods might be pending temporarily. Your Kubernetes admin may need to restart that node manually, or the machine might take a long time to reboot. A Mule app deployment may return a CrashLoopBackOff warning because the Mule app fails to start due to an external dependency being down, such as a database or JMS server. The warning may fix itself when the service comes up. Though, if there is something wrong with the deployment artifact, then the warning message will be permanent. ## Warning Messages Description The following table shows a non-exhaustive list of different types of warning messages. For a complete reference, refer to the Kubernetes documentation.
Warning StatusTypeDescriptionExample

PodInitializing

Usually temporary

There is a pod initialization delay, not all containers in your Mule app pods are ready and it is usually a matter of time until the pods initialize. If there is a real problem with your deployment, this warning transitions into another state.

Link

CrashLoopBackOff

Usually permanent

There is a problem with your Mule app image and the app is crashing.

Link

Unschedulable

Usually temporary

There are no nodes available to run the requested replicas. Reasons might include:

* Nodes being down for maintenance.
* Nodes without enough resources available to assign for your deployment.
* The Enforce deploying replicas across nodes option in the Deployments Target tab of Runtime Manager is enabled but there are not enough different nodes available for the number of replicas desired.

Link

For more information on Pod Status, refer to the [Kubernetes official documentation](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime). Reach your Kubernetes administrator to inquire about whether a state should be considered critical or not and request advice on how to troubleshoot if required. ## Warning Messages Examples ### PodInitializing Example In the following example, the warning message shows because the pod is ready but is waiting to initialize: ![PodInitializing warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-deployment-example-1.png) ### CrashLoopBackOff Example In the following example, the warning message shows that there is a problem with your Mule app image because a corrupt artifact was uploaded and caused the Mule app to crash during the deployment. ![CrashLoopBackOff warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text ➜ ~ kubectl get deployments,pods --namespace 788a26d2-a837-4336-aa7b-1f367cf70d7d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 20m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-78b7ffd454-h5x5n 1/2 CrashLoopBackOff 8 (2m57s ago) 20m ``` ### Unschedulable Example In the following example, the warning message shows that 3 nodes were unschedulable because they were not available: ![Unschedulable warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 170m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-58dd54d9f-xt569 0/2 Pending 0 4s pod/omg-s1-now-6c5c5d987c-fbmbl 0/2 Pending 0 50m ``` ## App Namespaces Status States The following table lists statuses that show when there are issues with the app and authorized namespaces. They are prefixed with `[Runtime Fabric]`.
Status and descriptionType

There is an existing namespace <app_namespace> for your current environment <env_id>, please create a custom namespace with required labels to proceed with this deployment. For more information on creating custom namespaces, refer to documentation.

Permanent

Failed to select a namespace. Multiple namespaces <namespaces name> found with the same rtf.mulesoft.com/envId=<env_id> and rtf.mulesoft.com/agentNamespace=<agent_namespace> annotation. A single namespace can be annotated with the given environment id / RTF namespace pair.

Permanent

No application namespace corresponding to environment '%s' found. Please make sure to update the ConfigMap with the correct application namespace. For more information on configuring authorized namespaces, refer to documentation.

Permanent

An application namespace<app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with rtf.mulesoft.com/agentNamespace=<agent_namespace>.

Permanent

An application namespace <app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with proper rtf.mulesoft.com/envId (but was empty).

Permanent

Failed to select a namespace. Multiple namespaces found with the same rtf.mulesoft.com/envId=<env_id> annotation. A single namespace can be annotated with any given environment id.

Permanent

## See Also - [Reviewing Application Versioning on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Runtime Manager Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#status_states) --- product: Runtime Fabric version: 2.11 --- # Deployment Status Messages for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Manager shows deployment status messages when you deploy a Mule app for the first time or when you make changes to an existing Mule app deployed to Runtime Fabric: - [Application Deployment Status State](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#application_deploy_states) These statuses are related to the general application deployment, such as Deleted, Applying, Applied, Failed, or Unknown messages. - [Replica Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#replica_status_states) These statuses appear when you apply new, or changed, configurations to a deployed Mule app. - [Warning Messages Status States](#warning-status) These statuses appear when you receive a warning message while a deployment is in progress. - [App Namespaces Status States](#app-namespaces-status-states) These statuses appear when there are issues with app namespaces during deployment. ## Warning Messages Status States When you deploy a Mule app or make a change to an existing Mule app deployed to Runtime Fabric, Runtime Manager waits a minute and then begins to actively check the reported status of its replicas. If the status is other than STARTED or STOPPED, a warning message shows. A warning message does not necessarily mean there is something wrong with your Mule app or cluster. Understanding the meaning of these messages is important, as some warnings are only temporary while others can be permanent failures. Warning messages appear with this legend: `1 or more replicas in unexpected state:` followed by the specific description. For example: `1 or more replicas in unexpected state: [Kubernetes] Container "any point-monitoring" - PodInitializing` > [!NOTE] If a warning message persists and the related issue does not resolve automatically, work > with your IT department and developer team to check the deployment and pod status for > troubleshooting. ## Permanent versus Temporary Warning Messages Permanent warning messages usually require your action to fix the related issue. Instead, temporary warning messages disappear after some time. Check warning messages with your Kubernetes admin if they don’t disappear in a reasonable time. For example, if a node stops working, some pods might be pending temporarily. Your Kubernetes admin may need to restart that node manually, or the machine might take a long time to reboot. A Mule app deployment may return a CrashLoopBackOff warning because the Mule app fails to start due to an external dependency being down, such as a database or JMS server. The warning may fix itself when the service comes up. Though, if there is something wrong with the deployment artifact, then the warning message will be permanent. ## Warning Messages Description This table shows a non-exhaustive list of different types of warning messages. For a complete reference, refer to the Kubernetes documentation.
Warning StatusTypeDescriptionExample

PodInitializing

Usually temporary

There is a pod initialization delay, not all containers in your Mule app pods are ready and it is usually a matter of time until the pods initialize. If there is a real problem with your deployment, this warning transitions into another state.

Link

CrashLoopBackOff

Usually permanent

There is a problem with your Mule app image and the app is crashing.

Link

Unschedulable

Usually temporary

There are no nodes available to run the requested replicas. Reasons might include:

* Nodes being down for maintenance.
* Nodes without enough resources available to assign for your deployment.
* The Enforce deploying replicas across nodes option in the Deployments Target tab of Runtime Manager is enabled but there are not enough different nodes available for the number of replicas desired.

Link

For more information on Pod Status, refer to the [Kubernetes official documentation](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime). Reach your Kubernetes administrator to inquire about whether a state should be considered critical or not and request advice on how to troubleshoot if required. ## Warning Messages Examples ### PodInitializing Example In this example, the warning message shows because the pod is ready but is waiting to initialize: ![PodInitializing warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-deployment-example-1.png) ### CrashLoopBackOff Example In this example, the warning message shows that there is a problem with your Mule app image because a corrupt artifact was uploaded and caused the Mule app to crash during the deployment. ![CrashLoopBackOff warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run this command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text ➜ ~ kubectl get deployments,pods --namespace 788a26d2-a837-4336-aa7b-1f367cf70d7d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 20m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-78b7ffd454-h5x5n 1/2 CrashLoopBackOff 8 (2m57s ago) 20m ``` ### Unschedulable Example In this example, the warning message shows that 3 nodes were unschedulable because they were not available: ![Unschedulable warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run this command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 170m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-58dd54d9f-xt569 0/2 Pending 0 4s pod/omg-s1-now-6c5c5d987c-fbmbl 0/2 Pending 0 50m ``` ## App Namespaces Status States The following table lists statuses that show when there are issues with the app and authorized namespaces. They are prefixed with `[Runtime Fabric]`.
Status and descriptionType

There is an existing namespace <app_namespace> for your current environment <env_id>, please create a custom namespace with required labels to proceed with this deployment. For more information on creating custom namespaces, refer to documentation.

Permanent

Failed to select a namespace. Multiple namespaces <namespaces name> found with the same rtf.mulesoft.com/envId=<env_id> and rtf.mulesoft.com/agentNamespace=<agent_namespace> annotation. A single namespace can be annotated with the given environment id / RTF namespace pair.

Permanent

No application namespace corresponding to environment '%s' found. Please make sure to update the ConfigMap with the correct application namespace. For more information on configuring authorized namespaces, refer to documentation.

Permanent

An application namespace<app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with rtf.mulesoft.com/agentNamespace=<agent_namespace>.

Permanent

An application namespace <app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with proper rtf.mulesoft.com/envId (but was empty).

Permanent

Failed to select a namespace. Multiple namespaces found with the same rtf.mulesoft.com/envId=<env_id> annotation. A single namespace can be annotated with any given environment id.

Permanent

## See Also - [Reviewing Application Versioning on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Runtime Manager Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#status_states) --- product: Runtime Fabric version: 2.5 --- # Deployment Status Messages for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Manager shows deployment status messages when you deploy a Mule app for the first time or when you make changes to an existing Mule app deployed to Runtime Fabric: - [Application Deployment Status State](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#application_deploy_states) These statuses are related to the general application deployment, such as Deleted, Applying, Applied, Failed, or Unknown messages. - [Replica Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#replica_status_states) These statuses appear when you apply new, or changed, configurations to a deployed Mule app. - [Warning Messages Status States](#warning-status) These statuses appear when you receive a warning message while a deployment is in progress. - [App Namespaces Status States](#app-namespaces-status-states) These statuses appear when there are issues with app namespaces during deployment. ## Warning Messages Status States When you deploy a Mule app or make a change to an existing Mule app deployed to Runtime Fabric, Runtime Manager waits a minute and then begins to actively check the reported status of its replicas. If the status is other than STARTED or STOPPED, a warning message shows. A warning message does not necessarily mean there is something wrong with your Mule app or cluster. Understanding the meaning of these messages is important, as some warnings are only temporary while others can be permanent failures. Warning messages appear with the following legend: `1 or more replicas in unexpected state:` followed by the specific description. For example: `1 or more replicas in unexpected state: [Kubernetes] Container "any point-monitoring" - PodInitializing` > [!NOTE] If a warning message persists and the related issue does not resolve automatically, work > with your IT department and developer team to check the deployment and pod status for > troubleshooting. ## Permanent versus Temporary Warning Messages Permanent warning messages usually require your action to fix the related issue. Instead, temporary warning messages disappear after some time. Check warning messages with your Kubernetes admin if they don’t disappear in a reasonable time. For example, if a node stops working, some pods might be pending temporarily. Your Kubernetes admin may need to restart that node manually, or the machine might take a long time to reboot. A Mule app deployment may return a CrashLoopBackOff warning because the Mule app fails to start due to an external dependency being down, such as a database or JMS server. The warning may fix itself when the service comes up. Though, if there is something wrong with the deployment artifact, then the warning message will be permanent. ## Warning Messages Description The following table shows a non-exhaustive list of different types of warning messages. For a complete reference, refer to the Kubernetes documentation.
Warning StatusTypeDescriptionExample

PodInitializing

Usually temporary

There is a pod initialization delay, not all containers in your Mule app pods are ready and it is usually a matter of time until the pods initialize. If there is a real problem with your deployment, this warning transitions into another state.

Link

CrashLoopBackOff

Usually permanent

There is a problem with your Mule app image and the app is crashing.

Link

Unschedulable

Usually temporary

There are no nodes available to run the requested replicas. Reasons might include:

* Nodes being down for maintenance.
* Nodes without enough resources available to assign for your deployment.
* The Enforce deploying replicas across nodes option in the Deployments Target tab of Runtime Manager is enabled but there are not enough different nodes available for the number of replicas desired.

Link

For more information on Pod Status, refer to the [Kubernetes official documentation](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime). Reach your Kubernetes administrator to inquire about whether a state should be considered critical or not and request advice on how to troubleshoot if required. ## Warning Messages Examples ### PodInitializing Example In the following example, the warning message shows because the pod is ready but is waiting to initialize: ![PodInitializing warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-deployment-example-1.png) ### CrashLoopBackOff Example In the following example, the warning message shows that there is a problem with your Mule app image because a corrupt artifact was uploaded and caused the Mule app to crash during the deployment. ![CrashLoopBackOff warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text ➜ ~ kubectl get deployments,pods --namespace 788a26d2-a837-4336-aa7b-1f367cf70d7d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 20m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-78b7ffd454-h5x5n 1/2 CrashLoopBackOff 8 (2m57s ago) 20m ``` ### Unschedulable Example In the following example, the warning message shows that 3 nodes were unschedulable because they were not available: ![Unschedulable warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 170m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-58dd54d9f-xt569 0/2 Pending 0 4s pod/omg-s1-now-6c5c5d987c-fbmbl 0/2 Pending 0 50m ``` ## App Namespaces Status States The following table lists statuses that show when there are issues with the app and authorized namespaces. They are prefixed with `[Runtime Fabric]`.
Status and descriptionType

There is an existing namespace <app_namespace> for your current environment <env_id>, please create a custom namespace with required labels to proceed with this deployment. For more information on creating custom namespaces, refer to documentation.

Permanent

Failed to select a namespace. Multiple namespaces <namespaces name> found with the same rtf.mulesoft.com/envId=<env_id> and rtf.mulesoft.com/agentNamespace=<agent_namespace> annotation. A single namespace can be annotated with the given environment id / RTF namespace pair.

Permanent

No application namespace corresponding to environment '%s' found. Please make sure to update the ConfigMap with the correct application namespace. For more information on configuring authorized namespaces, refer to documentation.

Permanent

An application namespace<app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with rtf.mulesoft.com/agentNamespace=<agent_namespace>.

Permanent

An application namespace <app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with proper rtf.mulesoft.com/envId (but was empty).

Permanent

Failed to select a namespace. Multiple namespaces found with the same rtf.mulesoft.com/envId=<env_id> annotation. A single namespace can be annotated with any given environment id.

Permanent

## See Also - [Reviewing Application Versioning on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Runtime Manager Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#status_states) --- product: Runtime Fabric version: 2.6 --- # Deployment Status Messages for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Manager shows deployment status messages when you deploy a Mule app for the first time or when you make changes to an existing Mule app deployed to Runtime Fabric: - [Application Deployment Status State](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#application_deploy_states) These statuses are related to the general application deployment, such as Deleted, Applying, Applied, Failed, or Unknown messages. - [Replica Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#replica_status_states) These statuses appear when you apply new, or changed, configurations to a deployed Mule app. - [Warning Messages Status States](#warning-status) These statuses appear when you receive a warning message while a deployment is in progress. - [App Namespaces Status States](#app-namespaces-status-states) These statuses appear when there are issues with app namespaces during deployment. ## Warning Messages Status States When you deploy a Mule app or make a change to an existing Mule app deployed to Runtime Fabric, Runtime Manager waits a minute and then begins to actively check the reported status of its replicas. If the status is other than STARTED or STOPPED, a warning message shows. A warning message does not necessarily mean there is something wrong with your Mule app or cluster. Understanding the meaning of these messages is important, as some warnings are only temporary while others can be permanent failures. Warning messages appear with the following legend: `1 or more replicas in unexpected state:` followed by the specific description. For example: `1 or more replicas in unexpected state: [Kubernetes] Container "any point-monitoring" - PodInitializing` > [!NOTE] If a warning message persists and the related issue does not resolve automatically, work > with your IT department and developer team to check the deployment and pod status for > troubleshooting. ## Permanent versus Temporary Warning Messages Permanent warning messages usually require your action to fix the related issue. Instead, temporary warning messages disappear after some time. Check warning messages with your Kubernetes admin if they don’t disappear in a reasonable time. For example, if a node stops working, some pods might be pending temporarily. Your Kubernetes admin may need to restart that node manually, or the machine might take a long time to reboot. A Mule app deployment may return a CrashLoopBackOff warning because the Mule app fails to start due to an external dependency being down, such as a database or JMS server. The warning may fix itself when the service comes up. Though, if there is something wrong with the deployment artifact, then the warning message will be permanent. ## Warning Messages Description The following table shows a non-exhaustive list of different types of warning messages. For a complete reference, refer to the Kubernetes documentation.
Warning StatusTypeDescriptionExample

PodInitializing

Usually temporary

There is a pod initialization delay, not all containers in your Mule app pods are ready and it is usually a matter of time until the pods initialize. If there is a real problem with your deployment, this warning transitions into another state.

Link

CrashLoopBackOff

Usually permanent

There is a problem with your Mule app image and the app is crashing.

Link

Unschedulable

Usually temporary

There are no nodes available to run the requested replicas. Reasons might include:

* Nodes being down for maintenance.
* Nodes without enough resources available to assign for your deployment.
* The Enforce deploying replicas across nodes option in the Deployments Target tab of Runtime Manager is enabled but there are not enough different nodes available for the number of replicas desired.

Link

For more information on Pod Status, refer to the [Kubernetes official documentation](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime). Reach your Kubernetes administrator to inquire about whether a state should be considered critical or not and request advice on how to troubleshoot if required. ## Warning Messages Examples ### PodInitializing Example In the following example, the warning message shows because the pod is ready but is waiting to initialize: ![PodInitializing warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-deployment-example-1.png) ### CrashLoopBackOff Example In the following example, the warning message shows that there is a problem with your Mule app image because a corrupt artifact was uploaded and caused the Mule app to crash during the deployment. ![CrashLoopBackOff warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text ➜ ~ kubectl get deployments,pods --namespace 788a26d2-a837-4336-aa7b-1f367cf70d7d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 20m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-78b7ffd454-h5x5n 1/2 CrashLoopBackOff 8 (2m57s ago) 20m ``` ### Unschedulable Example In the following example, the warning message shows that 3 nodes were unschedulable because they were not available: ![Unschedulable warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 170m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-58dd54d9f-xt569 0/2 Pending 0 4s pod/omg-s1-now-6c5c5d987c-fbmbl 0/2 Pending 0 50m ``` ## App Namespaces Status States The following table lists statuses that show when there are issues with the app and authorized namespaces. They are prefixed with `[Runtime Fabric]`.
Status and descriptionType

There is an existing namespace <app_namespace> for your current environment <env_id>, please create a custom namespace with required labels to proceed with this deployment. For more information on creating custom namespaces, refer to documentation.

Permanent

Failed to select a namespace. Multiple namespaces <namespaces name> found with the same rtf.mulesoft.com/envId=<env_id> and rtf.mulesoft.com/agentNamespace=<agent_namespace> annotation. A single namespace can be annotated with the given environment id / RTF namespace pair.

Permanent

No application namespace corresponding to environment '%s' found. Please make sure to update the ConfigMap with the correct application namespace. For more information on configuring authorized namespaces, refer to documentation.

Permanent

An application namespace<app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with rtf.mulesoft.com/agentNamespace=<agent_namespace>.

Permanent

An application namespace <app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with proper rtf.mulesoft.com/envId (but was empty).

Permanent

Failed to select a namespace. Multiple namespaces found with the same rtf.mulesoft.com/envId=<env_id> annotation. A single namespace can be annotated with any given environment id.

Permanent

## See Also - [Reviewing Application Versioning on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Runtime Manager Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#status_states) --- product: Runtime Fabric version: 2.7 --- # Deployment Status Messages for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Manager shows deployment status messages when you deploy a Mule app for the first time or when you make changes to an existing Mule app deployed to Runtime Fabric: - [Application Deployment Status State](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#application_deploy_states) These statuses are related to the general application deployment, such as Deleted, Applying, Applied, Failed, or Unknown messages. - [Replica Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#replica_status_states) These statuses appear when you apply new, or changed, configurations to a deployed Mule app. - [Warning Messages Status States](#warning-status) These statuses appear when you receive a warning message while a deployment is in progress. - [App Namespaces Status States](#app-namespaces-status-states) These statuses appear when there are issues with app namespaces during deployment. ## Warning Messages Status States When you deploy a Mule app or make a change to an existing Mule app deployed to Runtime Fabric, Runtime Manager waits a minute and then begins to actively check the reported status of its replicas. If the status is other than STARTED or STOPPED, a warning message shows. A warning message does not necessarily mean there is something wrong with your Mule app or cluster. Understanding the meaning of these messages is important, as some warnings are only temporary while others can be permanent failures. Warning messages appear with the following legend: `1 or more replicas in unexpected state:` followed by the specific description. For example: `1 or more replicas in unexpected state: [Kubernetes] Container "any point-monitoring" - PodInitializing` > [!NOTE] If a warning message persists and the related issue does not resolve automatically, work > with your IT department and developer team to check the deployment and pod status for > troubleshooting. ## Permanent versus Temporary Warning Messages Permanent warning messages usually require your action to fix the related issue. Instead, temporary warning messages disappear after some time. Check warning messages with your Kubernetes admin if they don’t disappear in a reasonable time. For example, if a node stops working, some pods might be pending temporarily. Your Kubernetes admin may need to restart that node manually, or the machine might take a long time to reboot. A Mule app deployment may return a CrashLoopBackOff warning because the Mule app fails to start due to an external dependency being down, such as a database or JMS server. The warning may fix itself when the service comes up. Though, if there is something wrong with the deployment artifact, then the warning message will be permanent. ## Warning Messages Description The following table shows a non-exhaustive list of different types of warning messages. For a complete reference, refer to the Kubernetes documentation.
Warning StatusTypeDescriptionExample

PodInitializing

Usually temporary

There is a pod initialization delay, not all containers in your Mule app pods are ready and it is usually a matter of time until the pods initialize. If there is a real problem with your deployment, this warning transitions into another state.

Link

CrashLoopBackOff

Usually permanent

There is a problem with your Mule app image and the app is crashing.

Link

Unschedulable

Usually temporary

There are no nodes available to run the requested replicas. Reasons might include:

* Nodes being down for maintenance.
* Nodes without enough resources available to assign for your deployment.
* The Enforce deploying replicas across nodes option in the Deployments Target tab of Runtime Manager is enabled but there are not enough different nodes available for the number of replicas desired.

Link

For more information on Pod Status, refer to the [Kubernetes official documentation](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime). Reach your Kubernetes administrator to inquire about whether a state should be considered critical or not and request advice on how to troubleshoot if required. ## Warning Messages Examples ### PodInitializing Example In the following example, the warning message shows because the pod is ready but is waiting to initialize: ![PodInitializing warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-deployment-example-1.png) ### CrashLoopBackOff Example In the following example, the warning message shows that there is a problem with your Mule app image because a corrupt artifact was uploaded and caused the Mule app to crash during the deployment. ![CrashLoopBackOff warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text ➜ ~ kubectl get deployments,pods --namespace 788a26d2-a837-4336-aa7b-1f367cf70d7d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 20m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-78b7ffd454-h5x5n 1/2 CrashLoopBackOff 8 (2m57s ago) 20m ``` ### Unschedulable Example In the following example, the warning message shows that 3 nodes were unschedulable because they were not available: ![Unschedulable warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 170m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-58dd54d9f-xt569 0/2 Pending 0 4s pod/omg-s1-now-6c5c5d987c-fbmbl 0/2 Pending 0 50m ``` ## App Namespaces Status States The following table lists statuses that show when there are issues with the app and authorized namespaces. They are prefixed with `[Runtime Fabric]`.
Status and descriptionType

There is an existing namespace <app_namespace> for your current environment <env_id>, please create a custom namespace with required labels to proceed with this deployment. For more information on creating custom namespaces, refer to documentation.

Permanent

Failed to select a namespace. Multiple namespaces <namespaces name> found with the same rtf.mulesoft.com/envId=<env_id> and rtf.mulesoft.com/agentNamespace=<agent_namespace> annotation. A single namespace can be annotated with the given environment id / RTF namespace pair.

Permanent

No application namespace corresponding to environment '%s' found. Please make sure to update the ConfigMap with the correct application namespace. For more information on configuring authorized namespaces, refer to documentation.

Permanent

An application namespace<app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with rtf.mulesoft.com/agentNamespace=<agent_namespace>.

Permanent

An application namespace <app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with proper rtf.mulesoft.com/envId (but was empty).

Permanent

Failed to select a namespace. Multiple namespaces found with the same rtf.mulesoft.com/envId=<env_id> annotation. A single namespace can be annotated with any given environment id.

Permanent

## See Also - [Reviewing Application Versioning on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Runtime Manager Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#status_states) --- product: Runtime Fabric version: 2.8 --- # Deployment Status Messages for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Manager shows deployment status messages when you deploy a Mule app for the first time or when you make changes to an existing Mule app deployed to Runtime Fabric: - [Application Deployment Status State](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#application_deploy_states) These statuses are related to the general application deployment, such as Deleted, Applying, Applied, Failed, or Unknown messages. - [Replica Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#replica_status_states) These statuses appear when you apply new, or changed, configurations to a deployed Mule app. - [Warning Messages Status States](#warning-status) These statuses appear when you receive a warning message while a deployment is in progress. - [App Namespaces Status States](#app-namespaces-status-states) These statuses appear when there are issues with app namespaces during deployment. ## Warning Messages Status States When you deploy a Mule app or make a change to an existing Mule app deployed to Runtime Fabric, Runtime Manager waits a minute and then begins to actively check the reported status of its replicas. If the status is other than STARTED or STOPPED, a warning message shows. A warning message does not necessarily mean there is something wrong with your Mule app or cluster. Understanding the meaning of these messages is important, as some warnings are only temporary while others can be permanent failures. Warning messages appear with the following legend: `1 or more replicas in unexpected state:` followed by the specific description. For example: `1 or more replicas in unexpected state: [Kubernetes] Container "any point-monitoring" - PodInitializing` > [!NOTE] If a warning message persists and the related issue does not resolve automatically, work > with your IT department and developer team to check the deployment and pod status for > troubleshooting. ## Permanent versus Temporary Warning Messages Permanent warning messages usually require your action to fix the related issue. Instead, temporary warning messages disappear after some time. Check warning messages with your Kubernetes admin if they don’t disappear in a reasonable time. For example, if a node stops working, some pods might be pending temporarily. Your Kubernetes admin may need to restart that node manually, or the machine might take a long time to reboot. A Mule app deployment may return a CrashLoopBackOff warning because the Mule app fails to start due to an external dependency being down, such as a database or JMS server. The warning may fix itself when the service comes up. Though, if there is something wrong with the deployment artifact, then the warning message will be permanent. ## Warning Messages Description The following table shows a non-exhaustive list of different types of warning messages. For a complete reference, refer to the Kubernetes documentation.
Warning StatusTypeDescriptionExample

PodInitializing

Usually temporary

There is a pod initialization delay, not all containers in your Mule app pods are ready and it is usually a matter of time until the pods initialize. If there is a real problem with your deployment, this warning transitions into another state.

Link

CrashLoopBackOff

Usually permanent

There is a problem with your Mule app image and the app is crashing.

Link

Unschedulable

Usually temporary

There are no nodes available to run the requested replicas. Reasons might include:

* Nodes being down for maintenance.
* Nodes without enough resources available to assign for your deployment.
* The Enforce deploying replicas across nodes option in the Deployments Target tab of Runtime Manager is enabled but there are not enough different nodes available for the number of replicas desired.

Link

For more information on Pod Status, refer to the [Kubernetes official documentation](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime). Reach your Kubernetes administrator to inquire about whether a state should be considered critical or not and request advice on how to troubleshoot if required. ## Warning Messages Examples ### PodInitializing Example In the following example, the warning message shows because the pod is ready but is waiting to initialize: ![PodInitializing warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-deployment-example-1.png) ### CrashLoopBackOff Example In the following example, the warning message shows that there is a problem with your Mule app image because a corrupt artifact was uploaded and caused the Mule app to crash during the deployment. ![CrashLoopBackOff warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text ➜ ~ kubectl get deployments,pods --namespace 788a26d2-a837-4336-aa7b-1f367cf70d7d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 20m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-78b7ffd454-h5x5n 1/2 CrashLoopBackOff 8 (2m57s ago) 20m ``` ### Unschedulable Example In the following example, the warning message shows that 3 nodes were unschedulable because they were not available: ![Unschedulable warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 170m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-58dd54d9f-xt569 0/2 Pending 0 4s pod/omg-s1-now-6c5c5d987c-fbmbl 0/2 Pending 0 50m ``` ## App Namespaces Status States The following table lists statuses that show when there are issues with the app and authorized namespaces. They are prefixed with `[Runtime Fabric]`.
Status and descriptionType

There is an existing namespace <app_namespace> for your current environment <env_id>, please create a custom namespace with required labels to proceed with this deployment. For more information on creating custom namespaces, refer to documentation.

Permanent

Failed to select a namespace. Multiple namespaces <namespaces name> found with the same rtf.mulesoft.com/envId=<env_id> and rtf.mulesoft.com/agentNamespace=<agent_namespace> annotation. A single namespace can be annotated with the given environment id / RTF namespace pair.

Permanent

No application namespace corresponding to environment '%s' found. Please make sure to update the ConfigMap with the correct application namespace. For more information on configuring authorized namespaces, refer to documentation.

Permanent

An application namespace<app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with rtf.mulesoft.com/agentNamespace=<agent_namespace>.

Permanent

An application namespace <app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with proper rtf.mulesoft.com/envId (but was empty).

Permanent

Failed to select a namespace. Multiple namespaces found with the same rtf.mulesoft.com/envId=<env_id> annotation. A single namespace can be annotated with any given environment id.

Permanent

## See Also - [Reviewing Application Versioning on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Runtime Manager Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#status_states) --- product: Runtime Fabric version: 2.9 --- # Deployment Status Messages for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Manager shows deployment status messages when you deploy a Mule app for the first time or when you make changes to an existing Mule app deployed to Runtime Fabric: - [Application Deployment Status State](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#application_deploy_states) These statuses are related to the general application deployment, such as Deleted, Applying, Applied, Failed, or Unknown messages. - [Replica Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#replica_status_states) These statuses appear when you apply new, or changed, configurations to a deployed Mule app. - [Warning Messages Status States](#warning-status) These statuses appear when you receive a warning message while a deployment is in progress. - [App Namespaces Status States](#app-namespaces-status-states) These statuses appear when there are issues with app namespaces during deployment. ## Warning Messages Status States When you deploy a Mule app or make a change to an existing Mule app deployed to Runtime Fabric, Runtime Manager waits a minute and then begins to actively check the reported status of its replicas. If the status is other than STARTED or STOPPED, a warning message shows. A warning message does not necessarily mean there is something wrong with your Mule app or cluster. Understanding the meaning of these messages is important, as some warnings are only temporary while others can be permanent failures. Warning messages appear with the following legend: `1 or more replicas in unexpected state:` followed by the specific description. For example: `1 or more replicas in unexpected state: [Kubernetes] Container "any point-monitoring" - PodInitializing` > [!NOTE] If a warning message persists and the related issue does not resolve automatically, work > with your IT department and developer team to check the deployment and pod status for > troubleshooting. ## Permanent versus Temporary Warning Messages Permanent warning messages usually require your action to fix the related issue. Instead, temporary warning messages disappear after some time. Check warning messages with your Kubernetes admin if they don’t disappear in a reasonable time. For example, if a node stops working, some pods might be pending temporarily. Your Kubernetes admin may need to restart that node manually, or the machine might take a long time to reboot. A Mule app deployment may return a CrashLoopBackOff warning because the Mule app fails to start due to an external dependency being down, such as a database or JMS server. The warning may fix itself when the service comes up. Though, if there is something wrong with the deployment artifact, then the warning message will be permanent. ## Warning Messages Description The following table shows a non-exhaustive list of different types of warning messages. For a complete reference, refer to the Kubernetes documentation.
Warning StatusTypeDescriptionExample

PodInitializing

Usually temporary

There is a pod initialization delay, not all containers in your Mule app pods are ready and it is usually a matter of time until the pods initialize. If there is a real problem with your deployment, this warning transitions into another state.

Link

CrashLoopBackOff

Usually permanent

There is a problem with your Mule app image and the app is crashing.

Link

Unschedulable

Usually temporary

There are no nodes available to run the requested replicas. Reasons might include:

* Nodes being down for maintenance.
* Nodes without enough resources available to assign for your deployment.
* The Enforce deploying replicas across nodes option in the Deployments Target tab of Runtime Manager is enabled but there are not enough different nodes available for the number of replicas desired.

Link

For more information on Pod Status, refer to the [Kubernetes official documentation](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime). Reach your Kubernetes administrator to inquire about whether a state should be considered critical or not and request advice on how to troubleshoot if required. ## Warning Messages Examples ### PodInitializing Example In the following example, the warning message shows because the pod is ready but is waiting to initialize: ![PodInitializing warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-deployment-example-1.png) ### CrashLoopBackOff Example In the following example, the warning message shows that there is a problem with your Mule app image because a corrupt artifact was uploaded and caused the Mule app to crash during the deployment. ![CrashLoopBackOff warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text ➜ ~ kubectl get deployments,pods --namespace 788a26d2-a837-4336-aa7b-1f367cf70d7d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 20m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-78b7ffd454-h5x5n 1/2 CrashLoopBackOff 8 (2m57s ago) 20m ``` ### Unschedulable Example In the following example, the warning message shows that 3 nodes were unschedulable because they were not available: ![Unschedulable warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 170m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-58dd54d9f-xt569 0/2 Pending 0 4s pod/omg-s1-now-6c5c5d987c-fbmbl 0/2 Pending 0 50m ``` ## App Namespaces Status States The following table lists statuses that show when there are issues with the app and authorized namespaces. They are prefixed with `[Runtime Fabric]`.
Status and descriptionType

There is an existing namespace <app_namespace> for your current environment <env_id>, please create a custom namespace with required labels to proceed with this deployment. For more information on creating custom namespaces, refer to documentation.

Permanent

Failed to select a namespace. Multiple namespaces <namespaces name> found with the same rtf.mulesoft.com/envId=<env_id> and rtf.mulesoft.com/agentNamespace=<agent_namespace> annotation. A single namespace can be annotated with the given environment id / RTF namespace pair.

Permanent

No application namespace corresponding to environment '%s' found. Please make sure to update the ConfigMap with the correct application namespace. For more information on configuring authorized namespaces, refer to documentation.

Permanent

An application namespace<app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with rtf.mulesoft.com/agentNamespace=<agent_namespace>.

Permanent

An application namespace <app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with proper rtf.mulesoft.com/envId (but was empty).

Permanent

Failed to select a namespace. Multiple namespaces found with the same rtf.mulesoft.com/envId=<env_id> annotation. A single namespace can be annotated with any given environment id.

Permanent

## See Also - [Reviewing Application Versioning on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Runtime Manager Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#status_states) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Deployment Status Messages for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Manager shows deployment status messages when you deploy a Mule app for the first time or when you make changes to an existing Mule app deployed to Runtime Fabric: - [Application Deployment Status State](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#application_deploy_states) These statuses are related to the general application deployment, such as Deleted, Applying, Applied, Failed, or Unknown messages. - [Replica Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#replica_status_states) These statuses appear when you apply new, or changed, configurations to a deployed Mule app. - [Warning Messages Status States](#warning-status) These statuses appear when you receive a warning message while a deployment is in progress. - [App Namespaces Status States](#app-namespaces-status-states) These statuses appear when there are issues with app namespaces during deployment. ## Warning Messages Status States When you deploy a Mule app or make a change to an existing Mule app deployed to Runtime Fabric, Runtime Manager waits a minute and then begins to actively check the reported status of its replicas. If the status is other than STARTED or STOPPED, a warning message shows. A warning message does not necessarily mean there is something wrong with your Mule app or cluster. Understanding the meaning of these messages is important, as some warnings are only temporary while others can be permanent failures. Warning messages appear with the following legend: `1 or more replicas in unexpected state:` followed by the specific description. For example: `1 or more replicas in unexpected state: [Kubernetes] Container "any point-monitoring" - PodInitializing` > [!NOTE] If a warning message persists and the related issue does not resolve automatically, work > with your IT department and developer team to check the deployment and pod status for > troubleshooting. ## Permanent versus Temporary Warning Messages Permanent warning messages usually require your action to fix the related issue. Instead, temporary warning messages disappear after some time. Check warning messages with your Kubernetes admin if they don’t disappear in a reasonable time. For example, if a node stops working, some pods might be pending temporarily. Your Kubernetes admin may need to restart that node manually, or the machine might take a long time to reboot. A Mule app deployment may return a CrashLoopBackOff warning because the Mule app fails to start due to an external dependency being down, such as a database or JMS server. The warning may fix itself when the service comes up. Though, if there is something wrong with the deployment artifact, then the warning message will be permanent. ## Warning Messages Description The following table shows a non-exhaustive list of different types of warning messages. For a complete reference, refer to the Kubernetes documentation.
Warning StatusTypeDescriptionExample

PodInitializing

Usually temporary

There is a pod initialization delay, not all containers in your Mule app pods are ready and it is usually a matter of time until the pods initialize. If there is a real problem with your deployment, this warning transitions into another state.

Link

CrashLoopBackOff

Usually permanent

There is a problem with your Mule app image and the app is crashing.

Link

Unschedulable

Usually temporary

There are no nodes available to run the requested replicas. Reasons might include:

* Nodes being down for maintenance.
* Nodes without enough resources available to assign for your deployment.
* The Enforce deploying replicas across nodes option in the Deployments Target tab of Runtime Manager is enabled but there are not enough different nodes available for the number of replicas desired.

Link

For more information on Pod Status, refer to the [Kubernetes official documentation](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime). Reach your Kubernetes administrator to inquire about whether a state should be considered critical or not and request advice on how to troubleshoot if required. ## Warning Messages Examples ### PodInitializing Example In the following example, the warning message shows because the pod is ready but is waiting to initialize: ![PodInitializing warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-deployment-example-1.png) ### CrashLoopBackOff Example In the following example, the warning message shows that there is a problem with your Mule app image because a corrupt artifact was uploaded and caused the Mule app to crash during the deployment. ![CrashLoopBackOff warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text ➜ ~ kubectl get deployments,pods --namespace 788a26d2-a837-4336-aa7b-1f367cf70d7d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 20m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-78b7ffd454-h5x5n 1/2 CrashLoopBackOff 8 (2m57s ago) 20m ``` ### Unschedulable Example In the following example, the warning message shows that 3 nodes were unschedulable because they were not available: ![Unschedulable warning status in Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-deployment-example-2.png) Your Kubernetes administrator can run the following command in the command line interface to get the error or warning status as well: `kubectl get deployments,pods --namespace ` For example: ```text NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 170m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-58dd54d9f-xt569 0/2 Pending 0 4s pod/omg-s1-now-6c5c5d987c-fbmbl 0/2 Pending 0 50m ``` ## App Namespaces Status States The following table lists statuses that show when there are issues with the app and authorized namespaces. They are prefixed with `[Runtime Fabric]`.
Status and descriptionType

There is an existing namespace <app_namespace> for your current environment <env_id>, please create a custom namespace with required labels to proceed with this deployment. For more information on creating custom namespaces, refer to documentation.

Permanent

Failed to select a namespace. Multiple namespaces <namespaces name> found with the same rtf.mulesoft.com/envId=<env_id> and rtf.mulesoft.com/agentNamespace=<agent_namespace> annotation. A single namespace can be annotated with the given environment id / RTF namespace pair.

Permanent

No application namespace corresponding to environment '%s' found. Please make sure to update the ConfigMap with the correct application namespace. For more information on configuring authorized namespaces, refer to documentation.

Permanent

An application namespace<app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with rtf.mulesoft.com/agentNamespace=<agent_namespace>.

Permanent

An application namespace <app_namespace> has not been labeled correctly. The namespace for the current agent deployments must be labeled with proper rtf.mulesoft.com/envId (but was empty).

Permanent

Failed to select a namespace. Multiple namespaces found with the same rtf.mulesoft.com/envId=<env_id> annotation. A single namespace can be annotated with any given environment id.

Permanent

## See Also - [Reviewing Application Versioning on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Runtime Manager Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#status_states) --- product: Runtime Fabric version: 2.10 --- # Downgrading Runtime Fabric Versions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you need to downgrade Runtime Fabric version 2.x, you must downgrade the version by patching Runtime Fabric to a lower version. - RTFCTL - Helm For Runtime Fabrics installed using `rtfctl`, use the following PATCH request to specify the agent version to be downgraded: curl -X PATCH -H 'Authorization: Bearer xxx' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics/ --data-binary '{"version":"x.x.x"}' For Runtime Fabrics installed using Helm, use the following Helm command: helm upgrade --install runtime-fabric rtf/rtf-agent -f values.yaml -n --version x.x.x If you use AM log forwarding, you must additionally perform the following steps: 1. Enable daemon-set log forwarding by calling the following API (bearer token required): curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding/appScoped?enabled=false 2. Optionally, if am-log-forwarder daemon-set is not up and running, start the service by using either any of these options: - In the Anypoint Monitoring UI (**RuntimeFabrics -→ Fabric -→ LogForwarding**), check **Show logs in Anypoint Monitoring**. - or send an API request: curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding -d '{"anypointMonitoring": true}' > [!NOTE] Mule apps redeployed while Runtime Fabric agent version was 2.x must be redeployed to > reduce the resource allocation per the downgraded rtf-agent version. --- product: Runtime Fabric version: 2.11 --- # Downgrading Runtime Fabric Versions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you need to downgrade Runtime Fabric version 2.x, you must downgrade the version by patching Runtime Fabric to a lower version. - RTFCTL - Helm For Runtime Fabrics installed using `rtfctl`, use this PATCH request to specify the agent version to be downgraded: curl -X PATCH -H 'Authorization: Bearer xxx' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics/ --data-binary '{"version":"x.x.x"}' For Runtime Fabrics installed using Helm, use this Helm command: helm upgrade --install runtime-fabric rtf/rtf-agent -f values.yaml -n --version x.x.x If you use AM log forwarding, you must additionally perform these steps: 1. Enable daemon-set log forwarding by calling this API (bearer token required): curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding/appScoped?enabled=false 2. Optionally, if am-log-forwarder daemon-set is not up and running, start the service by using either any of these options: - In the Anypoint Monitoring UI (**RuntimeFabrics -→ Fabric -→ LogForwarding**), check **Show logs in Anypoint Monitoring**. - or send an API request: curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding -d '{"anypointMonitoring": true}' > [!NOTE] Mule apps redeployed while Runtime Fabric agent version was 2.x must be redeployed to > reduce the resource allocation per the downgraded rtf-agent version. --- product: Runtime Fabric version: 2.6 --- # Downgrading Runtime Fabric Versions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you need to downgrade Runtime Fabric version 2.x, you must downgrade the version by patching Runtime Fabric to a lower version. - RTFCTL - Helm For Runtime Fabrics installed using `rtfctl`, use the following PATCH request to specify the agent version to be downgraded: curl -X PATCH -H 'Authorization: Bearer xxx' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics/ --data-binary '{"version":"x.x.x"}' For Runtime Fabrics installed using Helm, use the following Helm command: helm upgrade --install runtime-fabric rtf/rtf-agent -f values.yaml -n --version x.x.x If you use AM log forwarding, you must additionally perform the following steps: 1. Enable daemon-set log forwarding by calling the following API (bearer token required): curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding/appScoped?enabled=false 2. Optionally, if am-log-forwarder daemon-set is not up and running, start the service by using either any of these options: - In the Anypoint Monitoring UI (**RuntimeFabrics -→ Fabric -→ LogForwarding**), check **Show logs in Anypoint Monitoring**. - or send an API request: curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding -d '{"anypointMonitoring": true}' > [!NOTE] Mule apps redeployed while Runtime Fabric agent version was 2.x must be redeployed to > reduce the resource allocation per the downgraded rtf-agent version. --- product: Runtime Fabric version: 2.7 --- # Downgrading Runtime Fabric Versions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you need to downgrade Runtime Fabric version 2.x, you must downgrade the version by patching Runtime Fabric to a lower version. - RTFCTL - Helm For Runtime Fabrics installed using `rtfctl`, use the following PATCH request to specify the agent version to be downgraded: curl -X PATCH -H 'Authorization: Bearer xxx' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics/ --data-binary '{"version":"x.x.x"}' For Runtime Fabrics installed using Helm, use the following Helm command: helm upgrade --install runtime-fabric rtf/rtf-agent -f values.yaml -n --version x.x.x If you use AM log forwarding, you must additionally perform the following steps: 1. Enable daemon-set log forwarding by calling the following API (bearer token required): curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding/appScoped?enabled=false 2. Optionally, if am-log-forwarder daemon-set is not up and running, start the service by using either any of these options: - In the Anypoint Monitoring UI (**RuntimeFabrics -→ Fabric -→ LogForwarding**), check **Show logs in Anypoint Monitoring**. - or send an API request: curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding -d '{"anypointMonitoring": true}' > [!NOTE] Mule apps redeployed while Runtime Fabric agent version was 2.x must be redeployed to > reduce the resource allocation per the downgraded rtf-agent version. --- product: Runtime Fabric version: 2.8 --- # Downgrading Runtime Fabric Versions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you need to downgrade Runtime Fabric version 2.x, you must downgrade the version by patching Runtime Fabric to a lower version. - RTFCTL - Helm For Runtime Fabrics installed using `rtfctl`, use the following PATCH request to specify the agent version to be downgraded: curl -X PATCH -H 'Authorization: Bearer xxx' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics/ --data-binary '{"version":"x.x.x"}' For Runtime Fabrics installed using Helm, use the following Helm command: helm upgrade --install runtime-fabric rtf/rtf-agent -f values.yaml -n --version x.x.x If you use AM log forwarding, you must additionally perform the following steps: 1. Enable daemon-set log forwarding by calling the following API (bearer token required): curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding/appScoped?enabled=false 2. Optionally, if am-log-forwarder daemon-set is not up and running, start the service by using either any of these options: - In the Anypoint Monitoring UI (**RuntimeFabrics -→ Fabric -→ LogForwarding**), check **Show logs in Anypoint Monitoring**. - or send an API request: curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding -d '{"anypointMonitoring": true}' > [!NOTE] Mule apps redeployed while Runtime Fabric agent version was 2.x must be redeployed to > reduce the resource allocation per the downgraded rtf-agent version. --- product: Runtime Fabric version: 2.9 --- # Downgrading Runtime Fabric Versions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you need to downgrade Runtime Fabric version 2.x, you must downgrade the version by patching Runtime Fabric to a lower version. - RTFCTL - Helm For Runtime Fabrics installed using `rtfctl`, use the following PATCH request to specify the agent version to be downgraded: curl -X PATCH -H 'Authorization: Bearer xxx' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics/ --data-binary '{"version":"x.x.x"}' For Runtime Fabrics installed using Helm, use the following Helm command: helm upgrade --install runtime-fabric rtf/rtf-agent -f values.yaml -n --version x.x.x If you use AM log forwarding, you must additionally perform the following steps: 1. Enable daemon-set log forwarding by calling the following API (bearer token required): curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding/appScoped?enabled=false 2. Optionally, if am-log-forwarder daemon-set is not up and running, start the service by using either any of these options: - In the Anypoint Monitoring UI (**RuntimeFabrics -→ Fabric -→ LogForwarding**), check **Show logs in Anypoint Monitoring**. - or send an API request: curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding -d '{"anypointMonitoring": true}' > [!NOTE] Mule apps redeployed while Runtime Fabric agent version was 2.x must be redeployed to > reduce the resource allocation per the downgraded rtf-agent version. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Downgrading Runtime Fabric Versions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you need to downgrade Runtime Fabric version 2.x, you must downgrade the version by patching Runtime Fabric to a lower version. - RTFCTL - Helm For Runtime Fabrics installed using `rtfctl`, use the following PATCH request to specify the agent version to be downgraded: curl -X PATCH -H 'Authorization: Bearer xxx' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics/ --data-binary '{"version":"x.x.x"}' For Runtime Fabrics installed using Helm, use the following Helm command: helm upgrade --install runtime-fabric rtf/rtf-agent -f values.yaml -n --version x.x.x If you use AM log forwarding, you must additionally perform the following steps: 1. Enable daemon-set log forwarding by calling the following API (bearer token required): curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding/appScoped?enabled=false 2. Optionally, if am-log-forwarder daemon-set is not up and running, start the service by using either any of these options: - In the Anypoint Monitoring UI (**RuntimeFabrics -→ Fabric -→ LogForwarding**), check **Show logs in Anypoint Monitoring**. - or send an API request: curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding -d '{"anypointMonitoring": true}' > [!NOTE] Mule apps redeployed while Runtime Fabric agent version was 2.x must be redeployed to > reduce the resource allocation per the downgraded rtf-agent version. --- product: Runtime Fabric version: 2.5 --- # Enabling FIPs 140-2 on Mule Applications > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can configure Runtime Fabric to run application containers in FIPS 140-2 compliance mode. These instructions assume that you are familiar with [FIPS 140-2](https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf), the US government security standard that requires that compliant parties use only cryptographic algorithms and techniques that have been certified by NIST. ## Enable FIPS 140-2 Compliance Mode 1. Using `kubectl`, patch the `custom-properties` secret in the `rtf` namespace by setting the `FIPS_ENABLED` key to `true`: ```copy # kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS_ENABLED": "true"}}' ``` After making this change, when you deploy new applications or restart existing applications, their containers run in FIPS 140-2 compliance mode. 2. To verify an application is running in FIPS 140-2 compliance mode, review the application’s startup log: ```copy # kubectl logs -n -c app -f| grep -i fips Running in FIPS mode * Security model: fips140-2 * * - mule.security.model = fips140-2 ``` --- product: Runtime Fabric version: 2.6 --- # Enabling FIPs 140-2 on Mule Applications > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can configure Runtime Fabric to run application containers in FIPS 140-2 compliance mode. These instructions assume that you are familiar with [FIPS 140-2](https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf), the US government security standard that requires that compliant parties use only cryptographic algorithms and techniques that have been certified by NIST. ## Enable FIPS 140-2 Compliance Mode 1. Using `kubectl`, patch the `custom-properties` secret in the `rtf` namespace by setting the `FIPS_ENABLED` key to `true`: ```copy # kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS_ENABLED": "true"}}' ``` After making this change, when you deploy new applications or restart existing applications, their containers run in FIPS 140-2 compliance mode. 2. To verify an application is running in FIPS 140-2 compliance mode, review the application’s startup log: ```copy # kubectl logs -n -c app -f| grep -i fips Running in FIPS mode * Security model: fips140-2 * * - mule.security.model = fips140-2 ``` --- product: Runtime Fabric version: 2.10 --- # Enabling FIPS 140-2 on Mule Applications > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can configure Mule application containers to run in FIPS 140-2 compliance mode. These instructions assume that you are familiar with [FIPS 140-2](https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf), the US government security standard that requires that compliant parties use only cryptographic algorithms and techniques that have been certified by NIST. ## Enable FIPS 140-2 Compliance Mode 1. Using `kubectl`, patch the `custom-properties` secret in the `rtf` namespace by setting the `FIPS_ENABLED` key to `true`: ```copy # kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS_ENABLED": "true"}}' ``` After making this change, when you deploy new applications or restart existing applications, their containers run in FIPS 140-2 compliance mode. 2. To verify an application is running in FIPS 140-2 compliance mode, review the application’s startup log: ```copy # kubectl logs -n -c app -f| grep -i fips Running in FIPS mode * Security model: fips140-2 * * - mule.security.model = fips140-2 ``` --- product: Runtime Fabric version: 2.11 --- # Enabling FIPS 140-2 on Mule Applications > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can configure Mule application containers to run in FIPS 140-2 compliance mode. These instructions assume that you are familiar with [FIPS 140-2](https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf), the US government security standard that requires that compliant parties use only cryptographic algorithms and techniques that have been certified by NIST. ## Enable FIPS 140-2 Compliance Mode 1. Using `kubectl`, patch the `custom-properties` secret in the `rtf` namespace by setting the `FIPS_ENABLED` key to `true`: ```copy # kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS_ENABLED": "true"}}' ``` After making this change, when you deploy new applications or restart existing applications, their containers run in FIPS 140-2 compliance mode. 2. To verify an application is running in FIPS 140-2 compliance mode, review the application’s startup log: ```copy # kubectl logs -n -c app -f| grep -i fips Running in FIPS mode * Security model: fips140-2 * * - mule.security.model = fips140-2 ``` --- product: Runtime Fabric version: 2.7 --- # Enabling FIPS 140-2 on Mule Applications > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can configure Mule application containers to run in FIPS 140-2 compliance mode. These instructions assume that you are familiar with [FIPS 140-2](https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf), the US government security standard that requires that compliant parties use only cryptographic algorithms and techniques that have been certified by NIST. ## Enable FIPS 140-2 Compliance Mode 1. Using `kubectl`, patch the `custom-properties` secret in the `rtf` namespace by setting the `FIPS_ENABLED` key to `true`: ```copy # kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS_ENABLED": "true"}}' ``` After making this change, when you deploy new applications or restart existing applications, their containers run in FIPS 140-2 compliance mode. 2. To verify an application is running in FIPS 140-2 compliance mode, review the application’s startup log: ```copy # kubectl logs -n -c app -f| grep -i fips Running in FIPS mode * Security model: fips140-2 * * - mule.security.model = fips140-2 ``` --- product: Runtime Fabric version: 2.8 --- # Enabling FIPS 140-2 on Mule Applications > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can configure Mule application containers to run in FIPS 140-2 compliance mode. These instructions assume that you are familiar with [FIPS 140-2](https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf), the US government security standard that requires that compliant parties use only cryptographic algorithms and techniques that have been certified by NIST. ## Enable FIPS 140-2 Compliance Mode 1. Using `kubectl`, patch the `custom-properties` secret in the `rtf` namespace by setting the `FIPS_ENABLED` key to `true`: ```copy # kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS_ENABLED": "true"}}' ``` After making this change, when you deploy new applications or restart existing applications, their containers run in FIPS 140-2 compliance mode. 2. To verify an application is running in FIPS 140-2 compliance mode, review the application’s startup log: ```copy # kubectl logs -n -c app -f| grep -i fips Running in FIPS mode * Security model: fips140-2 * * - mule.security.model = fips140-2 ``` --- product: Runtime Fabric version: 2.9 --- # Enabling FIPS 140-2 on Mule Applications > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can configure Mule application containers to run in FIPS 140-2 compliance mode. These instructions assume that you are familiar with [FIPS 140-2](https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf), the US government security standard that requires that compliant parties use only cryptographic algorithms and techniques that have been certified by NIST. ## Enable FIPS 140-2 Compliance Mode 1. Using `kubectl`, patch the `custom-properties` secret in the `rtf` namespace by setting the `FIPS_ENABLED` key to `true`: ```copy # kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS_ENABLED": "true"}}' ``` After making this change, when you deploy new applications or restart existing applications, their containers run in FIPS 140-2 compliance mode. 2. To verify an application is running in FIPS 140-2 compliance mode, review the application’s startup log: ```copy # kubectl logs -n -c app -f| grep -i fips Running in FIPS mode * Security model: fips140-2 * * - mule.security.model = fips140-2 ``` --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Enabling FIPS 140-2 on Mule Applications > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can configure Mule application containers to run in FIPS 140-2 compliance mode. These instructions assume that you are familiar with [FIPS 140-2](https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf), the US government security standard that requires that compliant parties use only cryptographic algorithms and techniques that have been certified by NIST. ## Enable FIPS 140-2 Compliance Mode 1. Using `kubectl`, patch the `custom-properties` secret in the `rtf` namespace by setting the `FIPS_ENABLED` key to `true`: ```copy # kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS_ENABLED": "true"}}' ``` After making this change, when you deploy new applications or restart existing applications, their containers run in FIPS 140-2 compliance mode. 2. To verify an application is running in FIPS 140-2 compliance mode, review the application’s startup log: ```copy # kubectl logs -n -c app -f| grep -i fips Running in FIPS mode * Security model: fips140-2 * * - mule.security.model = fips140-2 ``` --- product: Runtime Fabric version: 2.10 --- # Enabling Forwarding When Using firewalld > For the full documentation index, see: https://docs.mulesoft.com/llms.txt `firewalld` is an iptables controller that defines rules for persistent network traffic. If you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system, you must enable forwarding on the docker0 device. You must also forward any packets being sent from or to the 10.0.0.0/8 subnet. ## To Determine if You Are Using firewalld To determine if your system is using firewalld, run the following command: ```copy systemctl status firewalld.service ``` If firewalld is installed, this command returns the following: ```copy $ sudo systemctl status firewalld.service * firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) ``` If \`firewalld is not installed, this command returns an error message. ## Enable Forwarding To enable forwarding on the docker0 device, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` To enable forwarding on the 10.0.0.0/8 subnet, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` ## Verify Forwarding To verify that forwarding rules are in place, run the following command: ```copy firewall-cmd --permanent --direct --get-all-rules ``` The output should look like the following example: ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' > [!IMPORTANT] These rules are node level. This means you must run and verify them on every node, > both controller and worker nodes, for Runtime Fabric to work correctly when firewalld is active. --- product: Runtime Fabric version: 2.11 --- # Enabling Forwarding When Using firewalld > For the full documentation index, see: https://docs.mulesoft.com/llms.txt `firewalld` is an iptables controller that defines rules for persistent network traffic. If you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system, you must enable forwarding on the docker0 device. You must also forward any packets being sent from or to the 10.0.0.0/8 subnet. ## To Determine if You Are Using firewalld To determine if your system is using firewalld, run this command: ```copy systemctl status firewalld.service ``` If firewalld is installed, this command returns this: ```copy $ sudo systemctl status firewalld.service * firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) ``` If \`firewalld is not installed, this command returns an error message. ## Enable Forwarding To enable forwarding on the docker0 device, run these commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` To enable forwarding on the 10.0.0.0/8 subnet, run these commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` ## Verify Forwarding To verify that forwarding rules are in place, run this command: ```copy firewall-cmd --permanent --direct --get-all-rules ``` The output should look like this example: ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' > [!IMPORTANT] These rules are node level. This means you must run and verify them on every node, > both controller and worker nodes, for Runtime Fabric to work correctly when firewalld is active. --- product: Runtime Fabric version: 2.5 --- # Enabling Forwarding When Using firewalld > For the full documentation index, see: https://docs.mulesoft.com/llms.txt `firewalld` is an iptables controller that defines rules for persistent network traffic. If you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system, you must enable forwarding on the docker0 device. You must also forward any packets being sent from or to the 10.0.0.0/8 subnet. ## To Determine if You Are Using firewalld To determine if your system is using firewalld, run the following command: ```copy systemctl status firewalld.service ``` If firewalld is installed, this command returns the following: ```copy $ sudo systemctl status firewalld.service * firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) ``` If \`firewalld is not installed, this command returns an error message. ## Enable Forwarding To enable forwarding on the docker0 device, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` To enable forwarding on the 10.0.0.0/8 subnet, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` ## Verify Forwarding To verify that forwarding rules are in place, run the following command: ```copy firewall-cmd --permanent --direct --get-all-rules ``` The output should look like the following example: ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' > [!IMPORTANT] These rules are node level. This means you must run and verify them on every node, > both controller and worker nodes, for Runtime Fabric to work correctly when firewalld is active. --- product: Runtime Fabric version: 2.6 --- # Enabling Forwarding When Using firewalld > For the full documentation index, see: https://docs.mulesoft.com/llms.txt `firewalld` is an iptables controller that defines rules for persistent network traffic. If you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system, you must enable forwarding on the docker0 device. You must also forward any packets being sent from or to the 10.0.0.0/8 subnet. ## To Determine if You Are Using firewalld To determine if your system is using firewalld, run the following command: ```copy systemctl status firewalld.service ``` If firewalld is installed, this command returns the following: ```copy $ sudo systemctl status firewalld.service * firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) ``` If \`firewalld is not installed, this command returns an error message. ## Enable Forwarding To enable forwarding on the docker0 device, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` To enable forwarding on the 10.0.0.0/8 subnet, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` ## Verify Forwarding To verify that forwarding rules are in place, run the following command: ```copy firewall-cmd --permanent --direct --get-all-rules ``` The output should look like the following example: ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' > [!IMPORTANT] These rules are node level. This means you must run and verify them on every node, > both controller and worker nodes, for Runtime Fabric to work correctly when firewalld is active. --- product: Runtime Fabric version: 2.7 --- # Enabling Forwarding When Using firewalld > For the full documentation index, see: https://docs.mulesoft.com/llms.txt `firewalld` is an iptables controller that defines rules for persistent network traffic. If you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system, you must enable forwarding on the docker0 device. You must also forward any packets being sent from or to the 10.0.0.0/8 subnet. ## To Determine if You Are Using firewalld To determine if your system is using firewalld, run the following command: ```copy systemctl status firewalld.service ``` If firewalld is installed, this command returns the following: ```copy $ sudo systemctl status firewalld.service * firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) ``` If \`firewalld is not installed, this command returns an error message. ## Enable Forwarding To enable forwarding on the docker0 device, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` To enable forwarding on the 10.0.0.0/8 subnet, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` ## Verify Forwarding To verify that forwarding rules are in place, run the following command: ```copy firewall-cmd --permanent --direct --get-all-rules ``` The output should look like the following example: ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' > [!IMPORTANT] These rules are node level. This means you must run and verify them on every node, > both controller and worker nodes, for Runtime Fabric to work correctly when firewalld is active. --- product: Runtime Fabric version: 2.8 --- # Enabling Forwarding When Using firewalld > For the full documentation index, see: https://docs.mulesoft.com/llms.txt `firewalld` is an iptables controller that defines rules for persistent network traffic. If you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system, you must enable forwarding on the docker0 device. You must also forward any packets being sent from or to the 10.0.0.0/8 subnet. ## To Determine if You Are Using firewalld To determine if your system is using firewalld, run the following command: ```copy systemctl status firewalld.service ``` If firewalld is installed, this command returns the following: ```copy $ sudo systemctl status firewalld.service * firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) ``` If \`firewalld is not installed, this command returns an error message. ## Enable Forwarding To enable forwarding on the docker0 device, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` To enable forwarding on the 10.0.0.0/8 subnet, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` ## Verify Forwarding To verify that forwarding rules are in place, run the following command: ```copy firewall-cmd --permanent --direct --get-all-rules ``` The output should look like the following example: ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' > [!IMPORTANT] These rules are node level. This means you must run and verify them on every node, > both controller and worker nodes, for Runtime Fabric to work correctly when firewalld is active. --- product: Runtime Fabric version: 2.9 --- # Enabling Forwarding When Using firewalld > For the full documentation index, see: https://docs.mulesoft.com/llms.txt `firewalld` is an iptables controller that defines rules for persistent network traffic. If you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system, you must enable forwarding on the docker0 device. You must also forward any packets being sent from or to the 10.0.0.0/8 subnet. ## To Determine if You Are Using firewalld To determine if your system is using firewalld, run the following command: ```copy systemctl status firewalld.service ``` If firewalld is installed, this command returns the following: ```copy $ sudo systemctl status firewalld.service * firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) ``` If \`firewalld is not installed, this command returns an error message. ## Enable Forwarding To enable forwarding on the docker0 device, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` To enable forwarding on the 10.0.0.0/8 subnet, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` ## Verify Forwarding To verify that forwarding rules are in place, run the following command: ```copy firewall-cmd --permanent --direct --get-all-rules ``` The output should look like the following example: ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' > [!IMPORTANT] These rules are node level. This means you must run and verify them on every node, > both controller and worker nodes, for Runtime Fabric to work correctly when firewalld is active. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Enabling Forwarding When Using firewalld > For the full documentation index, see: https://docs.mulesoft.com/llms.txt `firewalld` is an iptables controller that defines rules for persistent network traffic. If you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system, you must enable forwarding on the docker0 device. You must also forward any packets being sent from or to the 10.0.0.0/8 subnet. ## To Determine if You Are Using firewalld To determine if your system is using firewalld, run the following command: ```copy systemctl status firewalld.service ``` If firewalld is installed, this command returns the following: ```copy $ sudo systemctl status firewalld.service * firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) ``` If \`firewalld is not installed, this command returns an error message. ## Enable Forwarding To enable forwarding on the docker0 device, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` To enable forwarding on the 10.0.0.0/8 subnet, run the following commands: ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` ## Verify Forwarding To verify that forwarding rules are in place, run the following command: ```copy firewall-cmd --permanent --direct --get-all-rules ``` The output should look like the following example: ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' > [!IMPORTANT] These rules are node level. This means you must run and verify them on every node, > both controller and worker nodes, for Runtime Fabric to work correctly when firewalld is active. --- product: Runtime Fabric version: 2.10 --- # Exporting Telemetry Externally > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. You can use any Log4j appender. For information about configuring `log4j2.xml`, see the [Log4j Configuration Syntax](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax). ## Requirements and Restrictions - MuleSoft Support doesn’t assist in implementing custom logging configurations or resolving issues caused by custom logging configurations. - MuleSoft is not responsible for issues arising from misconfiguration of your Log4j appender, including these or other issues: - Lost logging data - Performance degradation - Running out of disk space - Do not use synchronous log appenders. - Do not change anything in the console appender or Anypoint Monitoring appender. You can use only asynchronous log appenders. - File appenders, such as FileAppender, RollingFileAppender, AnypointMonitoringFileAppender, and RandomAccessFileAppender, are removed automatically. - When using custom Log4j configurations, both Mule runtime engine and application logs remain available in Anypoint Monitoring. ## Enabling Log4j Custom Log4j configurations are disabled by default. When you install Runtime Fabric, the parameter is disabled (`false`) in `Values.yaml`. You must set the value to `true`. You can also enable custom Log4j configurations by running the following steps: 1. From inside your cluster, run: kubectl -n rtf patch secret custom-properties -p '{\\"data\\": {\\"CUSTOM\_LOG4J\_ENABLED\\": \\"dHJ1ZQ==\\"}}' 2. Restart the Runtime Fabric agent pod. 3. Restart the application associated with the custom Log4j configuration. > [!NOTE] Custom Log4j is only supported by Mule applications running on Mule runtime engine > instances greater than or equal to Mule version 4.3.0. The Mule image must be built after Nov > 17, 2022. For details, refer to the > [Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#november-14-2022). ## Example: Create a Log4j Configuration Using Splunk For logs to be viewable in Runtime Fabric and flow to Splunk, configure the `SplunkHttp` Log4j appender. To enable the Log4j appender: 1. Update the `log4j2.xml` configuration file with your logger settings and include the `SplunkHttp` Log4j appender. In Anypoint Studio, the `log4j2.xml` file is located in the `src/main/resources` directory. ```xml ``` 1. Ensure that the configuration includes the Splunk dependency: ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` For the latest version of Splunk, see [GitHub](https://github.com/splunk/splunk-library-javalogging/tags). After your application starts, logs start flowing to your custom Log4j appender, and you can view them on your target logging system. ## See Also - [MDC Logging](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) --- product: Runtime Fabric version: 2.11 --- # Exporting Telemetry Externally > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. You can use any Log4j appender. For information about configuring `log4j2.xml`, see the [Log4j Configuration Syntax](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax). ## Requirements and Restrictions - MuleSoft Support doesn’t assist in implementing custom logging configurations or resolving issues caused by custom logging configurations. - MuleSoft isn’t responsible for issues arising from misconfiguration of your Log4j appender, including these or other issues: - Lost logging data - Performance degradation - Running out of disk space - Don’t use synchronous log appenders. - Don’t change anything in the console appender or Anypoint Monitoring appender. You can use only asynchronous log appenders. - File appenders, such as FileAppender, RollingFileAppender, AnypointMonitoringFileAppender, and RandomAccessFileAppender, are removed automatically. - When using custom Log4j configurations, both Mule runtime engine and application logs remain available in Anypoint Monitoring. ## Enabling Log4j Custom Log4j configurations are disabled by default. When you install Runtime Fabric, the parameter is disabled (`false`) in `Values.yaml`. You must set the value to `true`. You can also enable custom Log4j configurations by running these steps: 1. From inside your cluster, run: kubectl -n rtf patch secret custom-properties -p '{\\"data\\": {\\"CUSTOM\_LOG4J\_ENABLED\\": \\"dHJ1ZQ==\\"}}' 2. Restart the Runtime Fabric agent pod. 3. Restart the application associated with the custom Log4j configuration. > [!NOTE] Custom Log4j is only supported by Mule applications running on Mule runtime engine > instances greater than or equal to Mule version 4.3.0. The Mule image must be built after Nov > 17, 2022. For details, refer to the > [Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#november-14-2022). ## Example: Create a Log4j Configuration Using Splunk For logs to be viewable in Runtime Fabric and flow to Splunk, configure the `SplunkHttp` Log4j appender. To enable the Log4j appender: 1. Update the `log4j2.xml` configuration file with your logger settings and include the `SplunkHttp` Log4j appender. In Anypoint Studio, the `log4j2.xml` file is located in the `src/main/resources` directory. ```xml ``` 1. Ensure that the configuration includes the Splunk dependency: ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` For the latest version of Splunk, see [GitHub](https://github.com/splunk/splunk-library-javalogging/tags). After your application starts, logs start flowing to your custom Log4j appender, and you can view them on your target logging system. ## See Also - [MDC Logging](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) --- product: Runtime Fabric version: 2.6 --- # Exporting Telemetry Externally > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. You can use any Log4j appender. For information about configuring `log4j2.xml`, see the [Log4j Configuration Syntax](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax). ## Requirements and Restrictions - MuleSoft Support doesn’t assist in implementing custom logging configurations or resolving issues caused by custom logging configurations. - MuleSoft is not responsible for issues arising from misconfiguration of your Log4j appender, including these or other issues: - Lost logging data - Performance degradation - Running out of disk space - Do not use synchronous log appenders. You can use only asynchronous log appenders. - File appenders, such as FileAppender, RollingFileAppender, AnypointMonitoringFileAppender, and RandomAccessFileAppender, are removed automatically. - When using custom Log4j configurations, both Mule runtime engine and application logs remain available in Anypoint Monitoring. ## Enabling Log4j Custom Log4j configurations are disabled by default. When you install Runtime Fabric, the parameter is disabled (`false`) in `Values.yaml`. You must set the value to `true`. You can also enable custom Log4j configurations by running the following steps: 1. From inside your cluster, run: kubectl -n rtf patch secret custom-properties -p '{\\"data\\": {\\"CUSTOM\_LOG4J\_ENABLED\\": \\"dHJ1ZQ==\\"}}' 2. Restart the Runtime Fabric agent pod. 3. Restart the application associated with the custom Log4j configuration. > [!NOTE] Custom Log4j is only supported by Mule applications running on Mule runtime engine > instances greater than or equal to Mule version 4.3.0. The Mule image must be built after Nov > 17, 2022. For details, refer to the > [Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#november-14-2022). ## Example: Create a Log4j Configuration Using Splunk For logs to be viewable in Runtime Fabric and flow to Splunk, configure the `SplunkHttp` Log4j appender. To enable the Log4j appender: 1. Update the `log4j2.xml` configuration file with your logger settings and include the `SplunkHttp` Log4j appender. In Anypoint Studio, the `log4j2.xml` file is located in the `src/main/resources` directory. ```xml ``` 1. Ensure that the configuration includes the Splunk dependency: ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` For the latest version of Splunk, see [GitHub](https://github.com/splunk/splunk-library-javalogging/tags). After your application starts, logs start flowing to your custom Log4j appender, and you can view them on your target logging system. ## See Also - [MDC Logging](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) --- product: Runtime Fabric version: 2.7 --- # Exporting Telemetry Externally > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. You can use any Log4j appender. For information about configuring `log4j2.xml`, see the [Log4j Configuration Syntax](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax). ## Requirements and Restrictions - MuleSoft Support doesn’t assist in implementing custom logging configurations or resolving issues caused by custom logging configurations. - MuleSoft is not responsible for issues arising from misconfiguration of your Log4j appender, including these or other issues: - Lost logging data - Performance degradation - Running out of disk space - Do not use synchronous log appenders. You can use only asynchronous log appenders. - File appenders, such as FileAppender, RollingFileAppender, AnypointMonitoringFileAppender, and RandomAccessFileAppender, are removed automatically. - When using custom Log4j configurations, both Mule runtime engine and application logs remain available in Anypoint Monitoring. ## Enabling Log4j Custom Log4j configurations are disabled by default. When you install Runtime Fabric, the parameter is disabled (`false`) in `Values.yaml`. You must set the value to `true`. You can also enable custom Log4j configurations by running the following steps: 1. From inside your cluster, run: kubectl -n rtf patch secret custom-properties -p '{\\"data\\": {\\"CUSTOM\_LOG4J\_ENABLED\\": \\"dHJ1ZQ==\\"}}' 2. Restart the Runtime Fabric agent pod. 3. Restart the application associated with the custom Log4j configuration. > [!NOTE] Custom Log4j is only supported by Mule applications running on Mule runtime engine > instances greater than or equal to Mule version 4.3.0. The Mule image must be built after Nov > 17, 2022. For details, refer to the > [Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#november-14-2022). ## Example: Create a Log4j Configuration Using Splunk For logs to be viewable in Runtime Fabric and flow to Splunk, configure the `SplunkHttp` Log4j appender. To enable the Log4j appender: 1. Update the `log4j2.xml` configuration file with your logger settings and include the `SplunkHttp` Log4j appender. In Anypoint Studio, the `log4j2.xml` file is located in the `src/main/resources` directory. ```xml ``` 1. Ensure that the configuration includes the Splunk dependency: ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` For the latest version of Splunk, see [GitHub](https://github.com/splunk/splunk-library-javalogging/tags). After your application starts, logs start flowing to your custom Log4j appender, and you can view them on your target logging system. ## See Also - [MDC Logging](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) --- product: Runtime Fabric version: 2.8 --- # Exporting Telemetry Externally > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. You can use any Log4j appender. For information about configuring `log4j2.xml`, see the [Log4j Configuration Syntax](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax). ## Requirements and Restrictions - MuleSoft Support doesn’t assist in implementing custom logging configurations or resolving issues caused by custom logging configurations. - MuleSoft is not responsible for issues arising from misconfiguration of your Log4j appender, including these or other issues: - Lost logging data - Performance degradation - Running out of disk space - Do not use synchronous log appenders. - Do not change anything in the console appender or Anypoint Monitoring appender. You can use only asynchronous log appenders. - File appenders, such as FileAppender, RollingFileAppender, AnypointMonitoringFileAppender, and RandomAccessFileAppender, are removed automatically. - When using custom Log4j configurations, both Mule runtime engine and application logs remain available in Anypoint Monitoring. ## Enable Log4j Custom Log4j configurations are disabled by default. When you install Runtime Fabric, the parameter is disabled (`false`) in `Values.yaml`. You must set the value to `true`. You can also enable custom Log4j configurations by running the following steps: 1. From inside your cluster, run: kubectl -n rtf patch secret custom-properties -p '{\\"data\\": {\\"CUSTOM\_LOG4J\_ENABLED\\": \\"dHJ1ZQ==\\"}}' 2. Restart the Runtime Fabric agent pod. 3. Restart the application associated with the custom Log4j configuration. > [!NOTE] Custom Log4j is only supported by Mule applications running on Mule runtime engine > instances greater than or equal to Mule version 4.3.0. The Mule image must be built after Nov > 17, 2022. For details, refer to the > [Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#november-14-2022). ## Example: Create a Log4j Configuration Using Splunk For logs to be viewable in Runtime Fabric and flow to Splunk, configure the `SplunkHttp` Log4j appender. To enable the Log4j appender: 1. Update the `log4j2.xml` configuration file with your logger settings and include the `SplunkHttp` Log4j appender. In Anypoint Studio, the `log4j2.xml` file is located in the `src/main/resources` directory. ```xml ``` 1. Ensure that the configuration includes the Splunk dependency: ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` For the latest version of Splunk, see [GitHub](https://github.com/splunk/splunk-library-javalogging/tags). After your application starts, logs start flowing to your custom Log4j appender, and you can view them on your target logging system. ## Disable Custom Log4j If you enabled Custom Log4j in the `values.yaml` during the installation of Runtime Fabric and you want to disable it at the Runtime Fabric cluster level, follow these steps: 1. In your cluster, run: \# kubectl -nrtf patch secret custom-properties -p '{"data":{"CUSTOM\_LOG4J\_ENABLED":""}} 2. Restart the Runtime Fabric agent pod: \# kubectl delete pod -n rtf -l app=agent 1. Restart the Mule app associated with the custom Log4j configuration. ## See Also - [MDC Logging](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) --- product: Runtime Fabric version: 2.9 --- # Exporting Telemetry Externally > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. You can use any Log4j appender. For information about configuring `log4j2.xml`, see the [Log4j Configuration Syntax](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax). ## Requirements and Restrictions - MuleSoft Support doesn’t assist in implementing custom logging configurations or resolving issues caused by custom logging configurations. - MuleSoft is not responsible for issues arising from misconfiguration of your Log4j appender, including these or other issues: - Lost logging data - Performance degradation - Running out of disk space - Do not use synchronous log appenders. - Do not change anything in the console appender or Anypoint Monitoring appender. You can use only asynchronous log appenders. - File appenders, such as FileAppender, RollingFileAppender, AnypointMonitoringFileAppender, and RandomAccessFileAppender, are removed automatically. - When using custom Log4j configurations, both Mule runtime engine and application logs remain available in Anypoint Monitoring. ## Enabling Log4j Custom Log4j configurations are disabled by default. When you install Runtime Fabric, the parameter is disabled (`false`) in `Values.yaml`. You must set the value to `true`. You can also enable custom Log4j configurations by running the following steps: 1. From inside your cluster, run: kubectl -n rtf patch secret custom-properties -p '{\\"data\\": {\\"CUSTOM\_LOG4J\_ENABLED\\": \\"dHJ1ZQ==\\"}}' 2. Restart the Runtime Fabric agent pod. 3. Restart the application associated with the custom Log4j configuration. > [!NOTE] Custom Log4j is only supported by Mule applications running on Mule runtime engine > instances greater than or equal to Mule version 4.3.0. The Mule image must be built after Nov > 17, 2022. For details, refer to the > [Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#november-14-2022). ## Example: Create a Log4j Configuration Using Splunk For logs to be viewable in Runtime Fabric and flow to Splunk, configure the `SplunkHttp` Log4j appender. To enable the Log4j appender: 1. Update the `log4j2.xml` configuration file with your logger settings and include the `SplunkHttp` Log4j appender. In Anypoint Studio, the `log4j2.xml` file is located in the `src/main/resources` directory. ```xml ``` 1. Ensure that the configuration includes the Splunk dependency: ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` For the latest version of Splunk, see [GitHub](https://github.com/splunk/splunk-library-javalogging/tags). After your application starts, logs start flowing to your custom Log4j appender, and you can view them on your target logging system. ## See Also - [MDC Logging](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Exporting Telemetry Externally > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. You can use any Log4j appender. Configure the application-level `log4j2.xml` file in your Mule project (located in `src/main/resources`) to define your appenders. For information about the configuration syntax, see the [Log4j Configuration Syntax](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax). ## Requirements and Restrictions - Only the application-level `log4j2.xml` file (located in `src/main/resources` of your Mule project) can be customized. The Mule runtime-level `log4j2.xml` file cannot be modified for Runtime Fabric deployments. - MuleSoft Support doesn’t assist in implementing custom logging configurations or resolving issues caused by custom logging configurations. - MuleSoft is not responsible for issues arising from misconfiguration of your Log4j appender, including these or other issues: - Lost logging data - Performance degradation - Running out of disk space - Do not use synchronous log appenders. - Do not change anything in the console appender or Anypoint Monitoring appender. You can use only asynchronous log appenders. - File appenders, such as FileAppender, RollingFileAppender, AnypointMonitoringFileAppender, and RandomAccessFileAppender, are removed automatically. - When using custom Log4j configurations, both Mule runtime engine and application logs remain available in Anypoint Monitoring. ## Enabling Log4j Custom Log4j configurations are disabled by default. When you install Runtime Fabric, the parameter is disabled (`false`) in `Values.yaml`. You must set the value to `true`. You can also enable custom Log4j configurations by running the following steps: 1. From inside your cluster, run: kubectl -n rtf patch secret custom-properties -p '{\\"data\\": {\\"CUSTOM\_LOG4J\_ENABLED\\": \\"dHJ1ZQ==\\"}}' 2. Restart the Runtime Fabric agent pod. 3. Restart the application associated with the custom Log4j configuration. > [!NOTE] Custom Log4j is only supported by Mule applications running on Mule runtime engine > instances greater than or equal to Mule version 4.3.0. The Mule image must be built after Nov > 17, 2022. For details, refer to the > [Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#november-14-2022). ## Example: Create a Log4j Configuration Using Splunk For logs to be viewable in Runtime Fabric and flow to Splunk, configure the `SplunkHttp` Log4j appender. To enable the Log4j appender: 1. Update the `log4j2.xml` configuration file with your logger settings and include the `SplunkHttp` Log4j appender. In Anypoint Studio, the `log4j2.xml` file is located in the `src/main/resources` directory. ```xml ``` 1. Ensure that the configuration includes the Splunk dependency: ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` For the latest version of Splunk, see [GitHub](https://github.com/splunk/splunk-library-javalogging/tags). After your application starts, logs start flowing to your custom Log4j appender, and you can view them on your target logging system. ## See Also - [MDC Logging](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Generating Apps Diagnostics and Analyzing with Einstein > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the MuleSoft diagnostics agent to troubleshoot your Mule applications deployed to Runtime Fabric. This feature leverages Einstein generative AI to automate diagnostics collection and provide intelligent, actionable insights. ## Before you Begin Before running the MuleSoft diagnostics agent: - Connect your MuleSoft organization to a Salesforce account. - Enable Agentforce for your organization. See [Enable Agentforce for Your Anypoint Platform Organization](https://docs.mulesoft.com/access-management/enabling-generative-ai#enable-einstein-anypoint). - Enable Einstein entitlement for your Anypoint Platform organization. See [Enable Einstein Entitlement and Routing in Anypoint Platform](https://help.salesforce.com/s/articleView?id=platform.mulesoft_enable_einstein_anypoint_platform.htm&type=5). - Verify that you have either the Mule Developer Generative AI User or Organization Administrator role. - Update your Mule runtime to 4.6.23 LTS, 4.9.10 LTS, 4.10 Edge, or later. - Verify that your Mule application is running. For Runtime Fabric, verify that you are running these minimum versions: - `rtf-agent` 3.0.102 - `rtf-mule-actions` 2.0.7 ## Run the MuleSoft Diagnostics Agent 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Select the app name. 3. In the navigation menu, select **Diagnostics**. 4. Select an active replica from the dropdown list. 5. Click the **Analyze & Troubleshoot** dropdown. You have these options: - Select **Generate Mule Diagnostics** to generate and download the diagnostics for manual inspection. 1. Click **Download** to download the Mule diagnostics files. - Select **Analyze with Einstein** to generate the Mule diagnostics and run the analysis simultaneously. 1. Click **View Analysis** to open the analysis page. ### Generate Mule Diagnostics If you download the generated Mule diagnostics, you receive a `.tar` archive containing two key assets: Mule Thread Dumps A thread dump is a snapshot of all the threads in a replica that shows the current state of the server. Diagnostic Information Analysis File (DIAF) The DIAF is a structured, standardized plain-text file. It centralizes diagnostic data and organizes it for improved automated and manual analysis. The DIAF captures the state of events, operations, and critical application data. See [Mule Troubleshooting Plugin](https://docs.mulesoft.com/mule-runtime/latest/mule-troubleshooting-plugin). > [!NOTE] The DIAF doesn’t replace application logs. ### Analyze with Einstein If you select **Analyze with Einstein**, the system generates the Mule diagnostics and runs the Einstein analysis simultaneously. The resulting analysis identifies root causes and recommends actions based on the DIAF file. ## Considerations and Limitations The MuleSoft diagnostics agent uses Einstein generative AI. Limits for running analyses apply per application and per organization: - 10 analyses per application, per hour - 50 analyses per organization, per hour - 50 analyses per application, per day - 200 analyses per organization, per day Runtime Fabric retains Mule diagnostics for 30 days or up to 150 MB. ## See Also - [Understanding the Diagnostic Information Analysis File (DIAF)](https://docs.mulesoft.com/mule-runtime/latest/mule-troubleshooting-plugin#understanding-diagnostic-information-analysis-file-diaf) - [Using Anypoint Monitoring with Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/use-anypoint-monitoring) --- product: Runtime Fabric version: 2.10 --- # Hardening Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Mule apps deployed to Anypoint Runtime Fabric and reduce vulnerabilities, review the following topics: - [Protecting Mule App Property Values Using Rutime Manager](https://docs.mulesoft.com/runtime-fabric/2.10/protect-app-properties) Use Anypoint Runtime Manager to protect Mule app property values by displaying the property name but not its value. - [Protecting Mule App Property Values Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.10/manage-secure-properties) Use the `rtfctl` command line tool to protect Mule app property values. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-index) - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/managing-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.11 --- # Hardening Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Mule apps deployed to Anypoint Runtime Fabric and reduce vulnerabilities, review these topics: - [Protecting Mule App Property Values Using Rutime Manager](https://docs.mulesoft.com/runtime-fabric/2.11/protect-app-properties) Use Anypoint Runtime Manager to protect Mule app property values by displaying the property name but not its value. - [Protecting Mule App Property Values Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.11/manage-secure-properties) Use the `rtfctl` command line tool to protect Mule app property values. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-index) - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/managing-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.6 --- # Hardening Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Mule apps deployed to Anypoint Runtime Fabric and reduce vulnerabilities, review the following topics: - [Protecting Mule App Property Values Using Rutime Manager](https://docs.mulesoft.com/runtime-fabric/2.6/protect-app-properties) Use Anypoint Runtime Manager to protect Mule app property values by displaying the property name but not its value. - [Protecting Mule App Property Values Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.6/manage-secure-properties) Use the `rtfctl` command line tool to protect Mule app property values. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-index) - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/managing-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.7 --- # Hardening Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Mule apps deployed to Anypoint Runtime Fabric and reduce vulnerabilities, review the following topics: - [Protecting Mule App Property Values Using Rutime Manager](https://docs.mulesoft.com/runtime-fabric/2.7/protect-app-properties) Use Anypoint Runtime Manager to protect Mule app property values by displaying the property name but not its value. - [Protecting Mule App Property Values Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.7/manage-secure-properties) Use the `rtfctl` command line tool to protect Mule app property values. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-index) - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/managing-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.8 --- # Hardening Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Mule apps deployed to Anypoint Runtime Fabric and reduce vulnerabilities, review the following topics: - [Protecting Mule App Property Values Using Rutime Manager](https://docs.mulesoft.com/runtime-fabric/2.8/protect-app-properties) Use Anypoint Runtime Manager to protect Mule app property values by displaying the property name but not its value. - [Protecting Mule App Property Values Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.8/manage-secure-properties) Use the `rtfctl` command line tool to protect Mule app property values. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-index) - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/managing-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.9 --- # Hardening Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Mule apps deployed to Anypoint Runtime Fabric and reduce vulnerabilities, review the following topics: - [Protecting Mule App Property Values Using Rutime Manager](https://docs.mulesoft.com/runtime-fabric/2.9/protect-app-properties) Use Anypoint Runtime Manager to protect Mule app property values by displaying the property name but not its value. - [Protecting Mule App Property Values Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.9/manage-secure-properties) Use the `rtfctl` command line tool to protect Mule app property values. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-index) - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/managing-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Hardening Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Mule apps deployed to Anypoint Runtime Fabric and reduce vulnerabilities, review the following topics: - [Protecting Mule App Property Values Using Rutime Manager](https://docs.mulesoft.com/runtime-fabric/latest/protect-app-properties) Use Anypoint Runtime Manager to protect Mule app property values by displaying the property name but not its value. - [Protecting Mule App Property Values Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/latest/manage-secure-properties) Use the `rtfctl` command line tool to protect Mule app property values. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-index) - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/managing-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.10 --- # Hardening Mule Runtime on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt By design, Runtime Fabric automatically applies and enables hardening measures for your Mule applications. By following containerization best practices, isolation at the Mule and application level is achieved by default. The following hardening checklist provides additional information and best practices for Mule hardening with Runtime Fabric. ## Hardening Checklist
Table 1. Mule Hardening Procedure
Hardening StepAction Required

Run Mule as a non-privileged User.

Runtime Fabric provides this functionality.

Install Mule as a Service

Runtime Fabric provides this functionality by deploying a Mule runtime engine for each application within its own container.

Configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files.

Runtime Fabric provides this functionality. Mule writes to a temporary file system that is deleted when the application terminates. Monitoring information is collected from a sidecar agent in a specific location on disk where metrics are outputted and stored. Logs are collected from standard output streams.

In some situations, you must configure usernames, passwords, and keystores on Mule. Usually, these settings are made available externally, so that DevOps can change these settings.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

Manage certificates in a keystore file.

This is supported on Runtime Fabric, but you must import the certificates into the keystore.

Use a separate property file to store usernames and passwords and secure it using file system permissions.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

--- product: Runtime Fabric version: 2.11 --- # Hardening Mule Runtime on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt By design, Runtime Fabric automatically applies and enables hardening measures for your Mule applications. By following containerization best practices, isolation at the Mule and application level is achieved by default. The following hardening checklist provides additional information and best practices for Mule hardening with Runtime Fabric. ## Hardening Checklist
Table 1. Mule Hardening Procedure
Hardening StepAction Required

Run Mule as a non-privileged User.

Runtime Fabric provides this functionality.

Install Mule as a Service

Runtime Fabric provides this functionality by deploying a Mule runtime engine for each application within its own container.

Configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files.

Runtime Fabric provides this functionality. Mule writes to a temporary file system that is deleted when the application terminates. Monitoring information is collected from a sidecar agent in a specific location on disk where metrics are outputted and stored. Logs are collected from standard output streams.

In some situations, you must configure usernames, passwords, and keystores on Mule. Usually, these settings are made available externally, so that DevOps can change these settings.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

Manage certificates in a keystore file.

This is supported on Runtime Fabric, but you must import the certificates into the keystore.

Use a separate property file to store usernames and passwords and secure it using file system permissions.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

--- product: Runtime Fabric version: 2.5 --- # Hardening Mule Runtime on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt By design, Runtime Fabric automatically applies and enables hardening measures for your Mule applications. By following containerization best practices, isolation at the Mule and application level is achieved by default. The following hardening checklist provides additional information and best practices for Mule hardening with Runtime Fabric. ## Hardening Checklist
Table 1. Mule Hardening Procedure
Hardening StepAction Required

Run Mule as a non-privileged User.

Runtime Fabric provides this functionality.

Install Mule as a Service

Runtime Fabric provides this functionality by deploying a Mule runtime engine for each application within its own container.

Configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files.

Runtime Fabric provides this functionality. Mule writes to a temporary file system that is deleted when the application terminates. Monitoring information is collected from a sidecar agent in a specific location on disk where metrics are outputted and stored. Logs are collected from standard output streams.

In some situations, you must configure usernames, passwords, and keystores on Mule. Usually, these settings are made available externally, so that DevOps can change these settings.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

Manage certificates in a keystore file.

This is supported on Runtime Fabric, but you must import the certificates into the keystore.

Use a separate property file to store usernames and passwords and secure it using file system permissions.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

--- product: Runtime Fabric version: 2.6 --- # Hardening Mule Runtime on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt By design, Runtime Fabric automatically applies and enables hardening measures for your Mule applications. By following containerization best practices, isolation at the Mule and application level is achieved by default. The following hardening checklist provides additional information and best practices for Mule hardening with Runtime Fabric. ## Hardening Checklist
Table 1. Mule Hardening Procedure
Hardening StepAction Required

Run Mule as a non-privileged User.

Runtime Fabric provides this functionality.

Install Mule as a Service

Runtime Fabric provides this functionality by deploying a Mule runtime engine for each application within its own container.

Configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files.

Runtime Fabric provides this functionality. Mule writes to a temporary file system that is deleted when the application terminates. Monitoring information is collected from a sidecar agent in a specific location on disk where metrics are outputted and stored. Logs are collected from standard output streams.

In some situations, you must configure usernames, passwords, and keystores on Mule. Usually, these settings are made available externally, so that DevOps can change these settings.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

Manage certificates in a keystore file.

This is supported on Runtime Fabric, but you must import the certificates into the keystore.

Use a separate property file to store usernames and passwords and secure it using file system permissions.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

--- product: Runtime Fabric version: 2.7 --- # Hardening Mule Runtime on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt By design, Runtime Fabric automatically applies and enables hardening measures for your Mule applications. By following containerization best practices, isolation at the Mule and application level is achieved by default. The following hardening checklist provides additional information and best practices for Mule hardening with Runtime Fabric. ## Hardening Checklist
Table 1. Mule Hardening Procedure
Hardening StepAction Required

Run Mule as a non-privileged User.

Runtime Fabric provides this functionality.

Install Mule as a Service

Runtime Fabric provides this functionality by deploying a Mule runtime engine for each application within its own container.

Configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files.

Runtime Fabric provides this functionality. Mule writes to a temporary file system that is deleted when the application terminates. Monitoring information is collected from a sidecar agent in a specific location on disk where metrics are outputted and stored. Logs are collected from standard output streams.

In some situations, you must configure usernames, passwords, and keystores on Mule. Usually, these settings are made available externally, so that DevOps can change these settings.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

Manage certificates in a keystore file.

This is supported on Runtime Fabric, but you must import the certificates into the keystore.

Use a separate property file to store usernames and passwords and secure it using file system permissions.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

--- product: Runtime Fabric version: 2.8 --- # Hardening Mule Runtime on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt By design, Runtime Fabric automatically applies and enables hardening measures for your Mule applications. By following containerization best practices, isolation at the Mule and application level is achieved by default. The following hardening checklist provides additional information and best practices for Mule hardening with Runtime Fabric. ## Hardening Checklist
Table 1. Mule Hardening Procedure
Hardening StepAction Required

Run Mule as a non-privileged User.

Runtime Fabric provides this functionality.

Install Mule as a Service

Runtime Fabric provides this functionality by deploying a Mule runtime engine for each application within its own container.

Configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files.

Runtime Fabric provides this functionality. Mule writes to a temporary file system that is deleted when the application terminates. Monitoring information is collected from a sidecar agent in a specific location on disk where metrics are outputted and stored. Logs are collected from standard output streams.

In some situations, you must configure usernames, passwords, and keystores on Mule. Usually, these settings are made available externally, so that DevOps can change these settings.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

Manage certificates in a keystore file.

This is supported on Runtime Fabric, but you must import the certificates into the keystore.

Use a separate property file to store usernames and passwords and secure it using file system permissions.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

--- product: Runtime Fabric version: 2.9 --- # Hardening Mule Runtime on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt By design, Runtime Fabric automatically applies and enables hardening measures for your Mule applications. By following containerization best practices, isolation at the Mule and application level is achieved by default. The following hardening checklist provides additional information and best practices for Mule hardening with Runtime Fabric. ## Hardening Checklist
Table 1. Mule Hardening Procedure
Hardening StepAction Required

Run Mule as a non-privileged User.

Runtime Fabric provides this functionality.

Install Mule as a Service

Runtime Fabric provides this functionality by deploying a Mule runtime engine for each application within its own container.

Configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files.

Runtime Fabric provides this functionality. Mule writes to a temporary file system that is deleted when the application terminates. Monitoring information is collected from a sidecar agent in a specific location on disk where metrics are outputted and stored. Logs are collected from standard output streams.

In some situations, you must configure usernames, passwords, and keystores on Mule. Usually, these settings are made available externally, so that DevOps can change these settings.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

Manage certificates in a keystore file.

This is supported on Runtime Fabric, but you must import the certificates into the keystore.

Use a separate property file to store usernames and passwords and secure it using file system permissions.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

--- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Hardening Mule Runtime on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt By design, Runtime Fabric automatically applies and enables hardening measures for your Mule applications. By following containerization best practices, isolation at the Mule and application level is achieved by default. The following hardening checklist provides additional information and best practices for Mule hardening with Runtime Fabric. ## Hardening Checklist
Table 1. Mule Hardening Procedure
Hardening StepAction Required

Run Mule as a non-privileged User.

Runtime Fabric provides this functionality.

Install Mule as a Service

Runtime Fabric provides this functionality by deploying a Mule runtime engine for each application within its own container.

Configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files.

Runtime Fabric provides this functionality. Mule writes to a temporary file system that is deleted when the application terminates. Monitoring information is collected from a sidecar agent in a specific location on disk where metrics are outputted and stored. Logs are collected from standard output streams.

In some situations, you must configure usernames, passwords, and keystores on Mule. Usually, these settings are made available externally, so that DevOps can change these settings.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

Manage certificates in a keystore file.

This is supported on Runtime Fabric, but you must import the certificates into the keystore.

Use a separate property file to store usernames and passwords and secure it using file system permissions.

Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.

--- product: Runtime Fabric version: 2.10 --- # Hardening Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Anypoint Runtime Fabric and reduce vulnerabilities, review the following topics: - [Securing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/secure-runtime-fabric) Secure your Runtime Fabric by learning about Runtime Fabric security architecture, configuring authorized namespaces, enabling FIPS 140-2, using a local registry, and hardening Mule runtime engine for Runtime Fabric. - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/configure-kubernetes) Review Kubernetes (K8s) best practices such as scalability benchmarks and cluster configurations. Additionally, check `rtfctl` Kubernetes permissions, review Kubernetes Hardening Guide, and customize Mule apps Kubernetes resources. - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/manage-backup-restore) Use the `rtfctl` command line tool to back up and restore Runtime Fabric services. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/setting-up-runtime-fabric) - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/manage-index) --- product: Runtime Fabric version: 2.11 --- # Hardening Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Anypoint Runtime Fabric and reduce vulnerabilities, review these topics: - [Securing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/secure-runtime-fabric) Secure your Runtime Fabric by learning about Runtime Fabric security architecture, configuring authorized namespaces, enabling FIPS 140-2, using a local registry, and hardening Mule runtime engine for Runtime Fabric. - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/configure-kubernetes) Review Kubernetes (K8s) best practices such as scalability benchmarks and cluster configurations. Additionally, check `rtfctl` Kubernetes permissions, review Kubernetes Hardening Guide, and customize Mule apps Kubernetes resources. - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/manage-backup-restore) Use the `rtfctl` command line tool to back up and restore Runtime Fabric services. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/setting-up-runtime-fabric) - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/manage-index) --- product: Runtime Fabric version: 2.6 --- # Hardening Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Anypoint Runtime Fabric and reduce vulnerabilities, review the following topics: - [Securing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/secure-runtime-fabric) Secure your Runtime Fabric by learning about Runtime Fabric security architecture, configuring authorized namespaces, enabling FIPS 140-2, using a local registry, and hardening Mule runtime engine for Runtime Fabric. - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/configure-kubernetes) Review Kubernetes (K8s) best practices such as scalability benchmarks and cluster configurations. Additionally, check `rtfctl` Kubernetes permissions, review Kubernetes Hardening Guide, and customize Mule apps Kubernetes resources. - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/manage-backup-restore) Use the `rtfctl` command line tool to back up and restore Runtime Fabric services. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/setting-up-runtime-fabric) - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/manage-index) --- product: Runtime Fabric version: 2.7 --- # Hardening Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Anypoint Runtime Fabric and reduce vulnerabilities, review the following topics: - [Securing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/secure-runtime-fabric) Secure your Runtime Fabric by learning about Runtime Fabric security architecture, configuring authorized namespaces, enabling FIPS 140-2, using a local registry, and hardening Mule runtime engine for Runtime Fabric. - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/configure-kubernetes) Review Kubernetes (K8s) best practices such as scalability benchmarks and cluster configurations. Additionally, check `rtfctl` Kubernetes permissions, review Kubernetes Hardening Guide, and customize Mule apps Kubernetes resources. - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/manage-backup-restore) Use the `rtfctl` command line tool to back up and restore Runtime Fabric services. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/setting-up-runtime-fabric) - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/manage-index) --- product: Runtime Fabric version: 2.8 --- # Hardening Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Anypoint Runtime Fabric and reduce vulnerabilities, review the following topics: - [Securing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/secure-runtime-fabric) Secure your Runtime Fabric by learning about Runtime Fabric security architecture, configuring authorized namespaces, enabling FIPS 140-2, using a local registry, and hardening Mule runtime engine for Runtime Fabric. - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/configure-kubernetes) Review Kubernetes (K8s) best practices such as scalability benchmarks and cluster configurations. Additionally, check `rtfctl` Kubernetes permissions, review Kubernetes Hardening Guide, and customize Mule apps Kubernetes resources. - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-backup-restore) Use the `rtfctl` command line tool to back up and restore Runtime Fabric services. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/setting-up-runtime-fabric) - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-index) --- product: Runtime Fabric version: 2.9 --- # Hardening Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Anypoint Runtime Fabric and reduce vulnerabilities, review the following topics: - [Securing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/secure-runtime-fabric) Secure your Runtime Fabric by learning about Runtime Fabric security architecture, configuring authorized namespaces, enabling FIPS 140-2, using a local registry, and hardening Mule runtime engine for Runtime Fabric. - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/configure-kubernetes) Review Kubernetes (K8s) best practices such as scalability benchmarks and cluster configurations. Additionally, check `rtfctl` Kubernetes permissions, review Kubernetes Hardening Guide, and customize Mule apps Kubernetes resources. - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/manage-backup-restore) Use the `rtfctl` command line tool to back up and restore Runtime Fabric services. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/setting-up-runtime-fabric) - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/manage-index) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Hardening Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enhance the security of Anypoint Runtime Fabric and reduce vulnerabilities, review the following topics: - [Securing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/secure-runtime-fabric) Secure your Runtime Fabric by learning about Runtime Fabric security architecture, configuring authorized namespaces, enabling FIPS 140-2, using a local registry, and hardening Mule runtime engine for Runtime Fabric. - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/configure-kubernetes) Review Kubernetes (K8s) best practices such as scalability benchmarks and cluster configurations. Additionally, check `rtfctl` Kubernetes permissions, review Kubernetes Hardening Guide, and customize Mule apps Kubernetes resources. - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/manage-backup-restore) Use the `rtfctl` command line tool to back up and restore Runtime Fabric services. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/setting-up-runtime-fabric) - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/manage-index) --- product: Runtime Fabric version: 2.10 --- # Install the Runtime Fabric Command Line Tool > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Install the `rtfctl` command-line tool to locally manage Runtime Fabrics. > [!NOTE] If you are using the default namespace (rtf), don’t specify the flag > `--namespace `. This flag is introduced only as of `rtfctl` version 0.4.1. ## Install RTFCTL Tool > [!IMPORTANT] Your IT administrator must perform these installation tasks. > > If you’re using Runtime Fabric for AKS and have the AKS-managed Azure AD integration enabled, this > command returns the credentials needed to run `rtfctl` commands: > > `az aks get-credentials --name --resource-group --admin` `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Perform these steps for the installation: 1. Download the `rtfctl` command-line tool by running the appropriate operating system CURL command: - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. Change the file permissions for the `rtfctl` command-line tool: chmod +x rtfctl ### Run Commands The `rtfctl` command line tool consumes kubeconfig files as described in [Organizing Cluster Access Using kubeconfig Files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Use this method to configure which cluster you want to manage. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. - Run `rtfctl` commands as a privileged user. - To list all supported commands, run `rtfctl -h`. - For more information about a specific command, run `rtfctl -h`. ### Check for Proxy Settings When you run commands, `rtfctl` checks for any proxy settings in your environment. The tool looks for a `NO_PROXY` key (in upper case) and accepts a `no_proxy` key (in lower case) if `NO_PROXY` is not used. If both keys are present, `rtfctl` uses `NO_PROXY`. The `rtfctl` tool sets the key in your local Kubernetes context to honor your proxy settings. ## Install a Mule License To install a Mule license, follow these steps: 1. Make sure to base64 encode the license. 2. Run the following command: ./rtfctl apply mule-license '' --namespace rtf1 Updating rtf namespace... OK ## Capture a Heap Dump To capture a heap dump, run this command: /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof --app-namespace bed42b62-XXXX --namespace rtf1 Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof For additional information, run the `rtfctl heapdump -h` command. ## Work with Multiple Replicas For application management commands that accept a `--pod` flag, you can obtain the list of replicas using the `describe` command: ./rtfctl describe apps hello-world --app-namespace bed42b62-XXXX --namespace rtf1 Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status --- hello-world-77f5897949-z54gb Pending ## Audit RTFCTL Operations The `rtfctl` command line tool (from v1.0.29 and above) audits the `rtfctl` operations on the cluster and it helps cluster administrators and you to track operations that impact Runtime Fabric core software. Consider the following points: - Audit logs are stored in a Kubernetes secret in the `rtfctl-audit` namespace. - Audit logs are cluster scoped and not attached to Runtime Fabric core software lifecycle. - Command executions remain operational even if the auditing process fails to audit the operation. To audit the operations, run this command: ./rtfctl audit-logs An output example: \[{"timestamp":"2023-10-26 00:52:24.446 +0000 UTC","kubeContext":"test-k8scontext","command":\["./rtfctl","restart","test-application","--app-namespace","8456f9c7-2149-4983-b02b-6b18ddd28efe","--namespace","rtf"\]}\] > [!NOTE] Currently audit logs rollover or rotation is not supported. ## Understand RTFCTL Output The `rtfctl` command line tool commonly calls other applications and system tools, and the output of those calls is sent to standard output and standard error output. This output is written in the context of each operation performed. The `rtfctl` command line tool includes a last output line on the most verbose commands to make it clear whether the operation succeed or failed. Normal operation may include some intermediate _failure_ messages, such as when a stopped system unit is attempted to be stopped again. If you are in doubt about whether a message represents a problem or not, discuss it with your system administrator or contact MuleSoft support. ## Download Previous RTFCTL CLI Versions Use the following rest API call to download different `rtfctl` tool CLI versions: curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/{version} -o rtfctl ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl) --- product: Runtime Fabric version: 2.11 --- # Install the Runtime Fabric Command Line Tool > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Install the `rtfctl` command-line tool to locally manage Runtime Fabrics. > [!NOTE] If you are using the default namespace (rtf), don’t specify the flag > `--namespace `. This flag is introduced only as of `rtfctl` version 0.4.1. ## Install RTFCTL Tool > [!IMPORTANT] Your IT administrator must perform these installation tasks. > > If you’re using Runtime Fabric for AKS and have the AKS-managed Azure AD integration enabled, this > command returns the credentials needed to run `rtfctl` commands: > > `az aks get-credentials --name --resource-group --admin` `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Perform these steps for the installation: 1. Download the `rtfctl` command-line tool by running the appropriate operating system CURL command: - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. Change the file permissions for the `rtfctl` command-line tool: chmod +x rtfctl ### Run Commands The `rtfctl` command line tool consumes kubeconfig files as described in [Organizing Cluster Access Using kubeconfig Files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Use this method to configure which cluster you want to manage. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. - Run `rtfctl` commands as a privileged user. - To list all supported commands, run `rtfctl -h`. - For more information about a specific command, run `rtfctl -h`. ### Check for Proxy Settings When you run commands, `rtfctl` checks for any proxy settings in your environment. The tool looks for a `NO_PROXY` key (in upper case) and accepts a `no_proxy` key (in lower case) if `NO_PROXY` is not used. If both keys are present, `rtfctl` uses `NO_PROXY`. The `rtfctl` tool sets the key in your local Kubernetes context to honor your proxy settings. ## Install a Mule License To install a Mule license, follow these steps: 1. Make sure to base64 encode the license. 2. Run this command: ./rtfctl apply mule-license '' --namespace rtf1 Updating rtf namespace... OK ## Capture a Heap Dump To capture a heap dump, run this command: /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof --app-namespace bed42b62-XXXX --namespace rtf1 Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof For additional information, run the `rtfctl heapdump -h` command. ## Work with Multiple Replicas For application management commands that accept a `--pod` flag, you can obtain the list of replicas using the `describe` command: ./rtfctl describe apps hello-world --app-namespace bed42b62-XXXX --namespace rtf1 Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status --- hello-world-77f5897949-z54gb Pending ## Audit RTFCTL Operations The `rtfctl` command line tool (from v1.0.29 and above) audits the `rtfctl` operations on the cluster and it helps cluster administrators and you to track operations that impact Runtime Fabric core software. Consider these points: - Audit logs are stored in a Kubernetes secret in the `rtfctl-audit` namespace. - Audit logs are cluster scoped and not attached to Runtime Fabric core software lifecycle. - Command executions remain operational even if the auditing process fails to audit the operation. To audit the operations, run this command: ./rtfctl audit-logs An output example: \[{"timestamp":"2023-10-26 00:52:24.446 +0000 UTC","kubeContext":"test-k8scontext","command":\["./rtfctl","restart","test-application","--app-namespace","8456f9c7-2149-4983-b02b-6b18ddd28efe","--namespace","rtf"\]}\] > [!NOTE] Currently audit logs rollover or rotation is not supported. ## Understand RTFCTL Output The `rtfctl` command line tool commonly calls other applications and system tools, and the output of those calls is sent to standard output and standard error output. This output is written in the context of each operation performed. The `rtfctl` command line tool includes a last output line on the most verbose commands to make it clear whether the operation succeed or failed. Normal operation may include some intermediate _failure_ messages, such as when a stopped system unit is attempted to be stopped again. If you are in doubt about whether a message represents a problem or not, discuss it with your system administrator or contact MuleSoft support. ## Download Previous RTFCTL CLI Versions Use this rest API call to download different `rtfctl` tool CLI versions: curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/{version} -o rtfctl ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl) --- product: Runtime Fabric version: 2.9 --- # Install the Runtime Fabric Command Line Tool > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Install the `rtfctl` command-line tool to locally manage Runtime Fabrics. > [!NOTE] If you are using the default namespace (rtf), don’t specify the flag > `--namespace `. This flag is introduced only as of `rtfctl` version 0.4.1. ## Install RTFCTL Tool > [!IMPORTANT] Your IT administrator must perform these installation tasks. > > If you’re using Runtime Fabric for AKS and have the AKS-managed Azure AD integration enabled, this > command returns the credentials needed to run `rtfctl` commands: > > `az aks get-credentials --name --resource-group --admin` `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Perform these steps for the installation: 1. Download the `rtfctl` command-line tool by running the appropriate operating system CURL command: - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. Change the file permissions for the `rtfctl` command-line tool: chmod +x rtfctl ### Run Commands The `rtfctl` command line tool consumes kubeconfig files as described in [Organizing Cluster Access Using kubeconfig Files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Use this method to configure which cluster you want to manage. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. - Run `rtfctl` commands as a privileged user. - To list all supported commands, run `rtfctl -h`. - For more information about a specific command, run `rtfctl -h`. ### Check for Proxy Settings When you run commands, `rtfctl` checks for any proxy settings in your environment. The tool looks for a `NO_PROXY` key (in upper case) and accepts a `no_proxy` key (in lower case) if `NO_PROXY` is not used. If both keys are present, `rtfctl` uses `NO_PROXY`. The `rtfctl` tool sets the key in your local Kubernetes context to honor your proxy settings. ## Install a Mule License To install a Mule license, follow these steps: 1. Make sure to base64 encode the license. 2. Run the following command: ./rtfctl apply mule-license '' --namespace rtf1 Updating rtf namespace... OK ## Capture a Heap Dump To capture a heap dump, run this command: /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof --app-namespace bed42b62-XXXX --namespace rtf1 Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof For additional information, run the `rtfctl heapdump -h` command. ## Work with Multiple Replicas For application management commands that accept a `--pod` flag, you can obtain the list of replicas using the `describe` command: ./rtfctl describe apps hello-world --app-namespace bed42b62-XXXX --namespace rtf1 Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status --- hello-world-77f5897949-z54gb Pending ## Audit RTFCTL Operations The `rtfctl` command line tool (from v1.0.29 and above) audits the `rtfctl` operations on the cluster and it helps cluster administrators and you to track operations that impact Runtime Fabric core software. Consider the following points: - Audit logs are stored in a Kubernetes secret in the `rtfctl-audit` namespace. - Audit logs are cluster scoped and not attached to Runtime Fabric core software lifecycle. - Command executions remain operational even if the auditing process fails to audit the operation. To audit the operations, run this command: ./rtfctl audit-logs An output example: \[{"timestamp":"2023-10-26 00:52:24.446 +0000 UTC","kubeContext":"test-k8scontext","command":\["./rtfctl","restart","test-application","--app-namespace","8456f9c7-2149-4983-b02b-6b18ddd28efe","--namespace","rtf"\]}\] > [!NOTE] Currently audit logs rollover or rotation is not supported. ## Understand RTFCTL Output The `rtfctl` command line tool commonly calls other applications and system tools, and the output of those calls is sent to standard output and standard error output. This output is written in the context of each operation performed. The `rtfctl` command line tool includes a last output line on the most verbose commands to make it clear whether the operation succeed or failed. Normal operation may include some intermediate _failure_ messages, such as when a stopped system unit is attempted to be stopped again. If you are in doubt about whether a message represents a problem or not, discuss it with your system administrator or contact MuleSoft support. ## Download Previous RTFCTL CLI Versions Use the following rest API call to download different `rtfctl` tool CLI versions: curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/{version} -o rtfctl ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Install the Runtime Fabric Command Line Tool > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Install the `rtfctl` command-line tool to locally manage Runtime Fabrics. > [!NOTE] If you are using the default namespace (rtf), don’t specify the flag > `--namespace `. This flag is introduced only as of `rtfctl` version 0.4.1. ## Install RTFCTL Tool > [!IMPORTANT] Your IT administrator must perform these installation tasks. > > If you’re using Runtime Fabric for AKS and have the AKS-managed Azure AD integration enabled, this > command returns the credentials needed to run `rtfctl` commands: > > `az aks get-credentials --name --resource-group --admin` `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Perform these steps for the installation: 1. Download the `rtfctl` command-line tool by running the appropriate operating system CURL command: - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. Change the file permissions for the `rtfctl` command-line tool: chmod +x rtfctl ### Run Commands The `rtfctl` command line tool consumes kubeconfig files as described in [Organizing Cluster Access Using kubeconfig Files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Use this method to configure which cluster you want to manage. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. - Run `rtfctl` commands as a privileged user. - To list all supported commands, run `rtfctl -h`. - For more information about a specific command, run `rtfctl -h`. ### Check for Proxy Settings When you run commands, `rtfctl` checks for any proxy settings in your environment. The tool looks for a `NO_PROXY` key (in upper case) and accepts a `no_proxy` key (in lower case) if `NO_PROXY` is not used. If both keys are present, `rtfctl` uses `NO_PROXY`. The `rtfctl` tool sets the key in your local Kubernetes context to honor your proxy settings. ## Install a Mule License To install a Mule license, follow these steps: 1. Make sure to base64 encode the license. 2. Run the following command: ./rtfctl apply mule-license '' --namespace rtf1 Updating rtf namespace... OK ## Capture a Heap Dump To capture a heap dump, run this command: /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof --app-namespace bed42b62-XXXX --namespace rtf1 Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof For additional information, run the `rtfctl heapdump -h` command. ## Work with Multiple Replicas For application management commands that accept a `--pod` flag, you can obtain the list of replicas using the `describe` command: ./rtfctl describe apps hello-world --app-namespace bed42b62-XXXX --namespace rtf1 Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status --- hello-world-77f5897949-z54gb Pending ## Audit RTFCTL Operations The `rtfctl` command line tool (from v1.0.29 and above) audits the `rtfctl` operations on the cluster and it helps cluster administrators and you to track operations that impact Runtime Fabric core software. Consider the following points: - Audit logs are stored in a Kubernetes secret in the `rtfctl-audit` namespace. - Audit logs are cluster scoped and not attached to Runtime Fabric core software lifecycle. - Command executions remain operational even if the auditing process fails to audit the operation. To audit the operations, run this command: ./rtfctl audit-logs An output example: \[{"timestamp":"2023-10-26 00:52:24.446 +0000 UTC","kubeContext":"test-k8scontext","command":\["./rtfctl","restart","test-application","--app-namespace","8456f9c7-2149-4983-b02b-6b18ddd28efe","--namespace","rtf"\]}\] > [!NOTE] Currently audit logs rollover or rotation is not supported. ## Understand RTFCTL Output The `rtfctl` command line tool commonly calls other applications and system tools, and the output of those calls is sent to standard output and standard error output. This output is written in the context of each operation performed. The `rtfctl` command line tool includes a last output line on the most verbose commands to make it clear whether the operation succeed or failed. Normal operation may include some intermediate _failure_ messages, such as when a stopped system unit is attempted to be stopped again. If you are in doubt about whether a message represents a problem or not, discuss it with your system administrator or contact MuleSoft support. ## Download Previous RTFCTL CLI Versions Use the following rest API call to download different `rtfctl` tool CLI versions: curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/{version} -o rtfctl ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl) --- product: Runtime Fabric version: 2.10 --- # Installing Multiple Instances of Runtime Fabric on a Single Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. - To use this feature, you must upgrade to the minimum version of 2.2.5 of the Runtime Fabric agent that supports multiple instances. - Agent namespaces map one-to-one to app namespaces. You cannot share app namespaces amongst multiple instances of Runtime Fabric on the same cluster. > [!NOTE] For multiple instances, the first Runtime Fabric agent installation creates a custom > resource definition (CRD) for `persistencegateways.rtf.mulesoft.com` and priority class > `rtf-components-high-priority` resources. Runtime Fabric agent doesn’t clean up these resources > when you uninstall the agent. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single BYOK (Bring Your Own Kubernetes) cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager. 2. Create a custom namespace to install the Fabric created in the previous step: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. Add the Runtime Fabric helm repository: helm repo add --username --password 5. Optionally, you can configure the shared tenancy. Refer to [Configure Authorized Namespaces](#configure-namespaces) for details. 6. Download and configure the `values.yaml` file from the Anypoint Platform UI. 7. Set the [required parameters](#required-parameters) for the `values.yaml` file. 8. Install Runtime Fabric on the cluster: helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Deploy Mule Applications 1. To deploy Mule applications, create an `app-namespace` for each of installed agent: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Create the ingress in the new ``: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: rtf-nginx rules: - host: "testrtf.com" http: paths: - pathType: Prefix path: "/app-name(/|$)(.\*)" backend: service: name: service port: name: service-port Use a different host name per ``. If multiple ingresses define different paths for the same host, the ingress controller merges the definitions. As a result, Mule applications with the same name are not accessible, which causes a k8s issue, not a Runtime Fabric issue. ## (Optional) Configure Authorized Namespaces You can optionally configure authorized namespaces, which enables you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. You must create the `authorized-namespaces` ConfigMap file before installing Runtime Fabric for the Runtime Fabric namespace. Additionally, you must name the `ConfigMap`, `authorized-namespaces`. The following example shows a `ConfigMap` file: apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION\_NAMESPACE\_1: "" APPLICATION\_NAMESPACE\_2: " The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list nodes`, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: The following example shows a ClusterRole role: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] ### Configure Additional Namespaces To configure an additional namespace for application deployments and then add the necessary labels to the namespace, follow these steps: 1. Create a YAML file with the following contents: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Apply the previously created file: kubectl apply -f .yaml 3. Repeat Steps 1 and 2 to add as many namespaces as you need. 4. Create the `RoleBinding` for the Runtime Fabric agent `ClusterRole` that includes the Runtime Fabric agent `ServiceAccount` by applying the following configuration in your additional namespace: kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-index) --- product: Runtime Fabric version: 2.11 --- # Installing Multiple Instances of Runtime Fabric on a Single Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. - To use this feature, you must upgrade to the minimum version of 2.2.5 of the Runtime Fabric agent that supports multiple instances. - Agent namespaces map one-to-one to app namespaces. You cannot share app namespaces amongst multiple instances of Runtime Fabric on the same cluster. > [!NOTE] For multiple instances, the first Runtime Fabric agent installation creates a custom > resource definition (CRD) for `persistencegateways.rtf.mulesoft.com` and priority class > `rtf-components-high-priority` resources. Runtime Fabric agent doesn’t clean up these resources > when you uninstall the agent. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single BYOK (Bring Your Own Kubernetes) cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager. 2. Create a custom namespace to install the Fabric created in the previous step: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. Add the Runtime Fabric helm repository: helm repo add --username --password 5. Optionally, you can configure the shared tenancy. Refer to [Configure Authorized Namespaces](#configure-namespaces) for details. 6. Download and configure the `values.yaml` file from the Anypoint Platform UI. 7. Set the [required parameters](#required-parameters) for the `values.yaml` file. 8. Install Runtime Fabric on the cluster: helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set these optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Deploy Mule Applications 1. To deploy Mule applications, create an `app-namespace` for each of installed agent: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Create the ingress in the new ``: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: rtf-nginx rules: - host: "testrtf.com" http: paths: - pathType: Prefix path: "/app-name(/|$)(.\*)" backend: service: name: service port: name: service-port Use a different host name per ``. If multiple ingresses define different paths for the same host, the ingress controller merges the definitions. As a result, Mule applications with the same name are not accessible, which causes a k8s issue, not a Runtime Fabric issue. ## (Optional) Configure Authorized Namespaces You can optionally configure authorized namespaces, which enables you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. You must create the `authorized-namespaces` ConfigMap file before installing Runtime Fabric for the Runtime Fabric namespace. Additionally, you must name the `ConfigMap`, `authorized-namespaces`. The following example shows a `ConfigMap` file: apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION\_NAMESPACE\_1: "" APPLICATION\_NAMESPACE\_2: " The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list nodes`, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: The following example shows a ClusterRole role: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] ### Configure Additional Namespaces To configure an additional namespace for application deployments and then add the necessary labels to the namespace, follow these steps: 1. Create a YAML file with these contents: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Apply the previously created file: kubectl apply -f .yaml 3. Repeat Steps 1 and 2 to add as many namespaces as you need. 4. Create the `RoleBinding` for the Runtime Fabric agent `ClusterRole` that includes the Runtime Fabric agent `ServiceAccount` by applying this configuration in your additional namespace: kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-index) --- product: Runtime Fabric version: 2.5 --- # Installing Multiple Instances of Runtime Fabric on a Single Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. - To use this feature, you must upgrade to the minimum version of 2.2.5 of the Runtime Fabric agent that supports multiple instances. - Agent namespaces map one-to-one to app namespaces. You cannot share app namespaces amongst multiple instances of Runtime Fabric on the same cluster. - Hazelcast clustering is not yet supported with multiple instances. > [!NOTE] For multiple instances, the first Runtime Fabric agent installation creates a custom > resource definition (CRD) for `persistencegateways.rtf.mulesoft.com` and priority class > `rtf-components-high-priority` resources. Runtime Fabric agent doesn’t clean up these resources > when you uninstall the agent. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single BYOK (Bring Your Own Kubernetes) cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager. 2. Create a custom namespace to install the Fabric created in the previous step: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. Add the Runtime Fabric helm repository: helm repo add --username --password 5. Optionally, you can configure the shared tenancy. Refer to [Configure Authorized Namespaces](#configure-namespaces) for details. 6. Download and configure the `values.yaml` file from the Anypoint Platform UI. 7. Set the [required parameters](#required-parameters) for the `values.yaml` file. 8. Install Runtime Fabric on the cluster: helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Deploy Mule Applications 1. To deploy Mule applications, create an `app-namespace` for each of installed agent: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Create the ingress in the new ``: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: rtf-nginx rules: - host: "testrtf.com" http: paths: - pathType: Prefix path: "/app-name(/|$)(.\*)" backend: service: name: service port: name: service-port Use a different host name per ``. If multiple ingresses define different paths for the same host, the ingress controller merges the definitions. As a result, Mule applications with the same name are not accessible, which causes a k8s issue, not a Runtime Fabric issue. ## (Optional) Configure Authorized Namespaces You can optionally configure authorized namespaces, which enables you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. You must create the `authorized-namespaces` ConfigMap file before installing Runtime Fabric for the Runtime Fabric namespace. Additionally, you must name the `ConfigMap`, `authorized-namespaces`. The following example shows a `ConfigMap` file: apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION\_NAMESPACE\_1: "" APPLICATION\_NAMESPACE\_2: " The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list nodes`, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: The following example shows a ClusterRole role: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] ### Configure Additional Namespaces To configure an additional namespace for application deployments and then add the necessary labels to the namespace, follow these steps: 1. Create a YAML file with the following contents: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Apply the previously created file: kubectl apply -f .yaml 3. Repeat Steps 1 and 2 to add as many namespaces as you need. 4. Create the `RoleBinding` for the Runtime Fabric agent `ClusterRole` that includes the Runtime Fabric agent `ServiceAccount` by applying the following configuration in your additional namespace: kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/install-index) --- product: Runtime Fabric version: 2.6 --- # Installing Multiple Instances of Runtime Fabric on a Single Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. - To use this feature, you must upgrade to the minimum version of 2.2.5 of the Runtime Fabric agent that supports multiple instances. - Agent namespaces map one-to-one to app namespaces. You cannot share app namespaces amongst multiple instances of Runtime Fabric on the same cluster. > [!NOTE] For multiple instances, the first Runtime Fabric agent installation creates a custom > resource definition (CRD) for `persistencegateways.rtf.mulesoft.com` and priority class > `rtf-components-high-priority` resources. Runtime Fabric agent doesn’t clean up these resources > when you uninstall the agent. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single BYOK (Bring Your Own Kubernetes) cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager. 2. Create a custom namespace to install the Fabric created in the previous step: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. Add the Runtime Fabric helm repository: helm repo add --username --password 5. Optionally, you can configure the shared tenancy. Refer to [Configure Authorized Namespaces](#configure-namespaces) for details. 6. Download and configure the `values.yaml` file from the Anypoint Platform UI. 7. Set the [required parameters](#required-parameters) for the `values.yaml` file. 8. Install Runtime Fabric on the cluster: helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Deploy Mule Applications 1. To deploy Mule applications, create an `app-namespace` for each of installed agent: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Create the ingress in the new ``: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: rtf-nginx rules: - host: "testrtf.com" http: paths: - pathType: Prefix path: "/app-name(/|$)(.\*)" backend: service: name: service port: name: service-port Use a different host name per ``. If multiple ingresses define different paths for the same host, the ingress controller merges the definitions. As a result, Mule applications with the same name are not accessible, which causes a k8s issue, not a Runtime Fabric issue. ## (Optional) Configure Authorized Namespaces You can optionally configure authorized namespaces, which enables you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. You must create the `authorized-namespaces` ConfigMap file before installing Runtime Fabric for the Runtime Fabric namespace. Additionally, you must name the `ConfigMap`, `authorized-namespaces`. The following example shows a `ConfigMap` file: apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION\_NAMESPACE\_1: "" APPLICATION\_NAMESPACE\_2: " The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list nodes`, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: The following example shows a ClusterRole role: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] ### Configure Additional Namespaces To configure an additional namespace for application deployments and then add the necessary labels to the namespace, follow these steps: 1. Create a YAML file with the following contents: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Apply the previously created file: kubectl apply -f .yaml 3. Repeat Steps 1 and 2 to add as many namespaces as you need. 4. Create the `RoleBinding` for the Runtime Fabric agent `ClusterRole` that includes the Runtime Fabric agent `ServiceAccount` by applying the following configuration in your additional namespace: kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-index) --- product: Runtime Fabric version: 2.7 --- # Installing Multiple Instances of Runtime Fabric on a Single Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. - To use this feature, you must upgrade to the minimum version of 2.2.5 of the Runtime Fabric agent that supports multiple instances. - Agent namespaces map one-to-one to app namespaces. You cannot share app namespaces amongst multiple instances of Runtime Fabric on the same cluster. > [!NOTE] For multiple instances, the first Runtime Fabric agent installation creates a custom > resource definition (CRD) for `persistencegateways.rtf.mulesoft.com` and priority class > `rtf-components-high-priority` resources. Runtime Fabric agent doesn’t clean up these resources > when you uninstall the agent. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single BYOK (Bring Your Own Kubernetes) cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager. 2. Create a custom namespace to install the Fabric created in the previous step: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. Add the Runtime Fabric helm repository: helm repo add --username --password 5. Optionally, you can configure the shared tenancy. Refer to [Configure Authorized Namespaces](#configure-namespaces) for details. 6. Download and configure the `values.yaml` file from the Anypoint Platform UI. 7. Set the [required parameters](#required-parameters) for the `values.yaml` file. 8. Install Runtime Fabric on the cluster: helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Deploy Mule Applications 1. To deploy Mule applications, create an `app-namespace` for each of installed agent: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Create the ingress in the new ``: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: rtf-nginx rules: - host: "testrtf.com" http: paths: - pathType: Prefix path: "/app-name(/|$)(.\*)" backend: service: name: service port: name: service-port Use a different host name per ``. If multiple ingresses define different paths for the same host, the ingress controller merges the definitions. As a result, Mule applications with the same name are not accessible, which causes a k8s issue, not a Runtime Fabric issue. ## (Optional) Configure Authorized Namespaces You can optionally configure authorized namespaces, which enables you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. You must create the `authorized-namespaces` ConfigMap file before installing Runtime Fabric for the Runtime Fabric namespace. Additionally, you must name the `ConfigMap`, `authorized-namespaces`. The following example shows a `ConfigMap` file: apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION\_NAMESPACE\_1: "" APPLICATION\_NAMESPACE\_2: " The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list nodes`, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: The following example shows a ClusterRole role: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] ### Configure Additional Namespaces To configure an additional namespace for application deployments and then add the necessary labels to the namespace, follow these steps: 1. Create a YAML file with the following contents: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Apply the previously created file: kubectl apply -f .yaml 3. Repeat Steps 1 and 2 to add as many namespaces as you need. 4. Create the `RoleBinding` for the Runtime Fabric agent `ClusterRole` that includes the Runtime Fabric agent `ServiceAccount` by applying the following configuration in your additional namespace: kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-index) --- product: Runtime Fabric version: 2.8 --- # Installing Multiple Instances of Runtime Fabric on a Single Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. - To use this feature, you must upgrade to the minimum version of 2.2.5 of the Runtime Fabric agent that supports multiple instances. - Agent namespaces map one-to-one to app namespaces. You cannot share app namespaces amongst multiple instances of Runtime Fabric on the same cluster. > [!NOTE] For multiple instances, the first Runtime Fabric agent installation creates a custom > resource definition (CRD) for `persistencegateways.rtf.mulesoft.com` and priority class > `rtf-components-high-priority` resources. Runtime Fabric agent doesn’t clean up these resources > when you uninstall the agent. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single BYOK (Bring Your Own Kubernetes) cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager. 2. Create a custom namespace to install the Fabric created in the previous step: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. Add the Runtime Fabric helm repository: helm repo add --username --password 5. Optionally, you can configure the shared tenancy. Refer to [Configure Authorized Namespaces](#configure-namespaces) for details. 6. Download and configure the `values.yaml` file from the Anypoint Platform UI. 7. Set the [required parameters](#required-parameters) for the `values.yaml` file. 8. Install Runtime Fabric on the cluster: helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Deploy Mule Applications 1. To deploy Mule applications, create an `app-namespace` for each of installed agent: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Create the ingress in the new ``: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: rtf-nginx rules: - host: "testrtf.com" http: paths: - pathType: Prefix path: "/app-name(/|$)(.\*)" backend: service: name: service port: name: service-port Use a different host name per ``. If multiple ingresses define different paths for the same host, the ingress controller merges the definitions. As a result, Mule applications with the same name are not accessible, which causes a k8s issue, not a Runtime Fabric issue. ## (Optional) Configure Authorized Namespaces You can optionally configure authorized namespaces, which enables you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. You must create the `authorized-namespaces` ConfigMap file before installing Runtime Fabric for the Runtime Fabric namespace. Additionally, you must name the `ConfigMap`, `authorized-namespaces`. The following example shows a `ConfigMap` file: apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION\_NAMESPACE\_1: "" APPLICATION\_NAMESPACE\_2: " The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list nodes`, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: The following example shows a ClusterRole role: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] ### Configure Additional Namespaces To configure an additional namespace for application deployments and then add the necessary labels to the namespace, follow these steps: 1. Create a YAML file with the following contents: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Apply the previously created file: kubectl apply -f .yaml 3. Repeat Steps 1 and 2 to add as many namespaces as you need. 4. Create the `RoleBinding` for the Runtime Fabric agent `ClusterRole` that includes the Runtime Fabric agent `ServiceAccount` by applying the following configuration in your additional namespace: kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-index) --- product: Runtime Fabric version: 2.9 --- # Installing Multiple Instances of Runtime Fabric on a Single Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. - To use this feature, you must upgrade to the minimum version of 2.2.5 of the Runtime Fabric agent that supports multiple instances. - Agent namespaces map one-to-one to app namespaces. You cannot share app namespaces amongst multiple instances of Runtime Fabric on the same cluster. > [!NOTE] For multiple instances, the first Runtime Fabric agent installation creates a custom > resource definition (CRD) for `persistencegateways.rtf.mulesoft.com` and priority class > `rtf-components-high-priority` resources. Runtime Fabric agent doesn’t clean up these resources > when you uninstall the agent. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single BYOK (Bring Your Own Kubernetes) cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager. 2. Create a custom namespace to install the Fabric created in the previous step: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. Add the Runtime Fabric helm repository: helm repo add --username --password 5. Optionally, you can configure the shared tenancy. Refer to [Configure Authorized Namespaces](#configure-namespaces) for details. 6. Download and configure the `values.yaml` file from the Anypoint Platform UI. 7. Set the [required parameters](#required-parameters) for the `values.yaml` file. 8. Install Runtime Fabric on the cluster: helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Deploy Mule Applications 1. To deploy Mule applications, create an `app-namespace` for each of installed agent: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Create the ingress in the new ``: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: rtf-nginx rules: - host: "testrtf.com" http: paths: - pathType: Prefix path: "/app-name(/|$)(.\*)" backend: service: name: service port: name: service-port Use a different host name per ``. If multiple ingresses define different paths for the same host, the ingress controller merges the definitions. As a result, Mule applications with the same name are not accessible, which causes a k8s issue, not a Runtime Fabric issue. ## (Optional) Configure Authorized Namespaces You can optionally configure authorized namespaces, which enables you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. You must create the `authorized-namespaces` ConfigMap file before installing Runtime Fabric for the Runtime Fabric namespace. Additionally, you must name the `ConfigMap`, `authorized-namespaces`. The following example shows a `ConfigMap` file: apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION\_NAMESPACE\_1: "" APPLICATION\_NAMESPACE\_2: " The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list nodes`, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: The following example shows a ClusterRole role: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] ### Configure Additional Namespaces To configure an additional namespace for application deployments and then add the necessary labels to the namespace, follow these steps: 1. Create a YAML file with the following contents: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Apply the previously created file: kubectl apply -f .yaml 3. Repeat Steps 1 and 2 to add as many namespaces as you need. 4. Create the `RoleBinding` for the Runtime Fabric agent `ClusterRole` that includes the Runtime Fabric agent `ServiceAccount` by applying the following configuration in your additional namespace: kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-index) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Installing Multiple Instances of Runtime Fabric on a Single Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. - To use this feature, you must upgrade to the minimum version of 2.2.5 of the Runtime Fabric agent that supports multiple instances. - Agent namespaces map one-to-one to app namespaces. You cannot share app namespaces amongst multiple instances of Runtime Fabric on the same cluster. > [!NOTE] For multiple instances, the first Runtime Fabric agent installation creates a custom > resource definition (CRD) for `persistencegateways.rtf.mulesoft.com` and priority class > `rtf-components-high-priority` resources. Runtime Fabric agent doesn’t clean up these resources > when you uninstall the agent. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single BYOK (Bring Your Own Kubernetes) cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager. 2. Create a custom namespace to install the Fabric created in the previous step: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. Add the Runtime Fabric helm repository: helm repo add --username --password 5. Optionally, you can configure the shared tenancy. Refer to [Configure Authorized Namespaces](#configure-namespaces) for details. 6. Download and configure the `values.yaml` file from the Anypoint Platform UI. 7. Set the [required parameters](#required-parameters) for the `values.yaml` file. 8. Install Runtime Fabric on the cluster: helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

  • US: rtf-runtime-registry.kprod.msap.io

  • EU: rtf-runtime-registry.kprod-eu.msap.io

  • Canada: rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net

  • Japan: rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Deploy Mule Applications 1. To deploy Mule applications, create an `app-namespace` for each of installed agent: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Create the ingress in the new ``: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: rtf-nginx rules: - host: "testrtf.com" http: paths: - pathType: Prefix path: "/app-name(/|$)(.\*)" backend: service: name: service port: name: service-port Use a different host name per ``. If multiple ingresses define different paths for the same host, the ingress controller merges the definitions. As a result, Mule applications with the same name are not accessible, which causes a k8s issue, not a Runtime Fabric issue. ## (Optional) Configure Authorized Namespaces You can optionally configure authorized namespaces, which enables you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. You must create the `authorized-namespaces` ConfigMap file before installing Runtime Fabric for the Runtime Fabric namespace. Additionally, you must name the `ConfigMap`, `authorized-namespaces`. The following example shows a `ConfigMap` file: apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION\_NAMESPACE\_1: "" APPLICATION\_NAMESPACE\_2: " The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list nodes`, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: The following example shows a ClusterRole role: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] ### Configure Additional Namespaces To configure an additional namespace for application deployments and then add the necessary labels to the namespace, follow these steps: 1. Create a YAML file with the following contents: apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. Apply the previously created file: kubectl apply -f .yaml 3. Repeat Steps 1 and 2 to add as many namespaces as you need. 4. Create the `RoleBinding` for the Runtime Fabric agent `ClusterRole` that includes the Runtime Fabric agent `ServiceAccount` by applying the following configuration in your additional namespace: kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-index) --- product: Runtime Fabric version: 2.10 --- # Installing Multiple Instances of Runtime Fabric on a Single OpenShift Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single OpenShift cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Installing Subsequent Instances of Runtime Fabric To install subsequent instances of Runtime Fabric for OpenShift, you must repeat the previous steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 5. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 6. Update your `values.yaml` file with any additional required parameters. 7. Set `authorizedNamespaces` to `true`, if you’re using authorized namespaces. 8. Set `crds.install` to `false`. 9. Click **Create**. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.10/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-index) --- product: Runtime Fabric version: 2.11 --- # Installing Multiple Instances of Runtime Fabric on a Single OpenShift Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single OpenShift cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Installing Subsequent Instances of Runtime Fabric To install subsequent instances of Runtime Fabric for OpenShift, you must repeat the previous steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 5. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 6. Update your `values.yaml` file with any additional required parameters. 7. Set `authorizedNamespaces` to `true`, if you’re using authorized namespaces. 8. Set `crds.install` to `false`. 9. Click **Create**. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.11/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note this: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with these contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply this configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply this RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run this command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set these optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-index) --- product: Runtime Fabric version: 2.5 --- # Installing Multiple Instances of Runtime Fabric on a Single OpenShift Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single OpenShift cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.5/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Installing Subsequent Instances of Runtime Fabric To install subsequent instances of Runtime Fabric for OpenShift, you must repeat the previous steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 5. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 6. In the console, click **Create Instance**, and select **Configure via form view**. 7. Add any values.yaml required parameters. 8. Set `authorizedNamespaces` to `true`, if you’re using authorized namespaces. 9. Set the value for `crds.install` to `false`. 10. Click **Create**. ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/install-index) --- product: Runtime Fabric version: 2.6 --- # Installing Multiple Instances of Runtime Fabric on a Single OpenShift Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single OpenShift cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.6/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Installing Subsequent Instances of Runtime Fabric To install subsequent instances of Runtime Fabric for OpenShift, you must repeat the previous steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 5. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 6. In the console, click **Create Instance**, and select **Configure via form view**. 7. Add any values.yaml required parameters. 8. Set `authorizedNamespaces` to `true`, if you’re using authorized namespaces. 9. Set the value for `crds.install` to `false`. 10. Click **Create**. ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-index) --- product: Runtime Fabric version: 2.7 --- # Installing Multiple Instances of Runtime Fabric on a Single OpenShift Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single OpenShift cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.7/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Installing Subsequent Instances of Runtime Fabric To install subsequent instances of Runtime Fabric for OpenShift, you must repeat the previous steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 5. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 6. In the console, click **Create Instance**, and select **Configure via form view**. 7. Add any values.yaml required parameters. 8. Set `authorizedNamespaces` to `true`, if you’re using authorized namespaces. 9. Set the value for `crds.install` to `false`. 10. Click **Create**. ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-index) --- product: Runtime Fabric version: 2.8 --- # Installing Multiple Instances of Runtime Fabric on a Single OpenShift Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single OpenShift cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Installing Subsequent Instances of Runtime Fabric To install subsequent instances of Runtime Fabric for OpenShift, you must repeat the previous steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 5. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 6. Update your `values.yaml` file with any additional required parameters. 7. Set `authorizedNamespaces` to `true`, if you’re using authorized namespaces. 8. Set `crds.install` to `false`. 9. Click **Create**. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.8/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-index) --- product: Runtime Fabric version: 2.9 --- # Installing Multiple Instances of Runtime Fabric on a Single OpenShift Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single OpenShift cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Installing Subsequent Instances of Runtime Fabric To install subsequent instances of Runtime Fabric for OpenShift, you must repeat the previous steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 5. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 6. Update your `values.yaml` file with any additional required parameters. 7. Set `authorizedNamespaces` to `true`, if you’re using authorized namespaces. 8. Set `crds.install` to `false`. 9. Click **Create**. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.9/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-index) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Installing Multiple Instances of Runtime Fabric on a Single OpenShift Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among multiple Runtime Fabrics, which helps you to use resources efficiently. ## Install Multiple Instances of Runtime Fabric To install multiple instances of Anypoint Runtime Fabric on a single OpenShift cluster, follow these steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= ## Values.yaml Reference The following is an example of the `values.yaml` file: activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## Installing Subsequent Instances of Runtime Fabric To install subsequent instances of Runtime Fabric for OpenShift, you must repeat the previous steps: 1. Create a Runtime Fabric using Runtime Manager for OpenShift. 2. Create a custom namespace to install the Runtime Fabric: kubectl create ns 3. Create a Docker pull secret to pull the Runtime Fabric component images for the previously created namespace: kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 5. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 6. Update your `values.yaml` file with any additional required parameters. 7. Set `authorizedNamespaces` to `true`, if you’re using authorized namespaces. 8. Set `crds.install` to `false`. 9. Click **Create**. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` > [!NOTE] Starting with Runtime Fabric agent version 3.0.0, the `am-log-forwarder` service > account is no longer required as log forwarding occurs exclusively through application > sidecar containers. You can omit this service account for new installations of version 3.0.0 > or higher. For more information, refer to > [Migrate Log Forwarding Before Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/migrate-log-forwarding). For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Values.yaml File Required Parameters The values for these required parameters are set when you create the Runtime Fabric instance in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation Data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

  • US: rtf-runtime-registry.kprod.msap.io

  • EU: rtf-runtime-registry.kprod-eu.msap.io

  • Canada: rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net

  • Japan: rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net

pullSecretName

Registry pull secret

rtf-pull-secret

muleLicense

Mule license for applications

Mule license key (must be Base64-encoded)

## Values.yaml Optional Parameters Set the following optional parameters as needed:
KeyDescriptionExample

authorizedNamespaces

Enables shared tenancy

authorizedNamespaces=true

crds.install

Enables installation of Crds and PriorityClass

install=true

proxy.http.proxy
proxy.http.no_proxy `

Proxy and no_proxy values

- http://<user>:<pass>@<10.0.0.1>:<8080>
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat read path

- /var/lib/docker/
- /var/log/containers
- /var/log/pods

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to > `true`. > Set `crds.install` to `false` for all the subsequent agent installations on the same cluster. ## See Also [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-index) --- product: Runtime Fabric version: 2.10 --- # Installing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To install Anypoint Runtime Fabric, choose any of the following options: - [Installing Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.10/install-self-managed) Use the `rtfctl` command line tool to install Runtime Fabric. - [Installing Runtime Fabric Using Helm](https://docs.mulesoft.com/runtime-fabric/2.10/install-helm) Use Helm package manager for Kubernetes to install Runtime Fabric. - [Installing Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.10/install-openshift) Install Runtime Fabric as a Kubernetes operator. - [Installing Multiple Instances on a Single Cluster](https://docs.mulesoft.com/runtime-fabric/2.10/install-multiple-instances) Install multiple instances of Runtime Fabric to share the same cluster among multiple Runtime Fabrics. - [Installing Multiple Instances on a Single OpenShift Cluster](https://docs.mulesoft.com/runtime-fabric/2.10/install-multiple-instances-openshift) Install multiple instances of Runtime Fabric to share the same OpenShift cluster among multiple Runtime Fabrics. ## See Also - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/uninstall-self) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/upgrade-index) --- product: Runtime Fabric version: 2.11 --- # Installing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To install Anypoint Runtime Fabric, choose any of these options: - [Installing Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.11/install-self-managed) Use the `rtfctl` command line tool to install Runtime Fabric. - [Installing Runtime Fabric Using Helm](https://docs.mulesoft.com/runtime-fabric/2.11/install-helm) Use Helm package manager for Kubernetes to install Runtime Fabric. - [Installing Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.11/install-openshift) Install Runtime Fabric as a Kubernetes operator. - [Installing Multiple Instances on a Single Cluster](https://docs.mulesoft.com/runtime-fabric/2.11/install-multiple-instances) Install multiple instances of Runtime Fabric to share the same cluster among multiple Runtime Fabrics. - [Installing Multiple Instances on a Single OpenShift Cluster](https://docs.mulesoft.com/runtime-fabric/2.11/install-multiple-instances-openshift) Install multiple instances of Runtime Fabric to share the same OpenShift cluster among multiple Runtime Fabrics. ## See Also - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/uninstall-self) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/upgrade-index) --- product: Runtime Fabric version: 2.5 --- # Installing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To install Runtime Fabric, choose from one of the following options: - [Install Runtime Fabric using rtfctl](https://docs.mulesoft.com/runtime-fabric/2.5/install-self-managed) - [Install Runtime Fabric using Helm](https://docs.mulesoft.com/runtime-fabric/2.5/install-helm) - [Install Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.5/install-openshift) --- product: Runtime Fabric version: 2.6 --- # Installing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To install Anypoint Runtime Fabric, choose any of the following options: - [Installing Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.6/install-self-managed) Use the `rtfctl` command line tool to install Runtime Fabric. - [Installing Runtime Fabric Using Helm](https://docs.mulesoft.com/runtime-fabric/2.6/install-helm) Use Helm package manager for Kubernetes to install Runtime Fabric. - [Installing Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.6/install-openshift) Install Runtime Fabric as a Kubernetes operator. - [Installing Multiple Instances on a Single Cluster](https://docs.mulesoft.com/runtime-fabric/2.6/install-multiple-instances) Install multiple instances of Runtime Fabric to share the same cluster among multiple Runtime Fabrics. - [Installing Multiple Instances on a Single OpenShift Cluster](https://docs.mulesoft.com/runtime-fabric/2.6/install-multiple-instances-openshift) Install multiple instances of Runtime Fabric to share the same OpenShift cluster among multiple Runtime Fabrics. ## See Also - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/uninstall-self) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/upgrade-index) --- product: Runtime Fabric version: 2.7 --- # Installing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To install Anypoint Runtime Fabric, choose any of the following options: - [Installing Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.7/install-self-managed) Use the `rtfctl` command line tool to install Runtime Fabric. - [Installing Runtime Fabric Using Helm](https://docs.mulesoft.com/runtime-fabric/2.7/install-helm) Use Helm package manager for Kubernetes to install Runtime Fabric. - [Installing Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.7/install-openshift) Install Runtime Fabric as a Kubernetes operator. - [Installing Multiple Instances on a Single Cluster](https://docs.mulesoft.com/runtime-fabric/2.7/install-multiple-instances) Install multiple instances of Runtime Fabric to share the same cluster among multiple Runtime Fabrics. - [Installing Multiple Instances on a Single OpenShift Cluster](https://docs.mulesoft.com/runtime-fabric/2.7/install-multiple-instances-openshift) Install multiple instances of Runtime Fabric to share the same OpenShift cluster among multiple Runtime Fabrics. ## See Also - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/uninstall-self) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/upgrade-index) --- product: Runtime Fabric version: 2.8 --- # Installing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To install Anypoint Runtime Fabric, choose any of the following options: - [Installing Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.8/install-self-managed) Use the `rtfctl` command line tool to install Runtime Fabric. - [Installing Runtime Fabric Using Helm](https://docs.mulesoft.com/runtime-fabric/2.8/install-helm) Use Helm package manager for Kubernetes to install Runtime Fabric. - [Installing Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.8/install-openshift) Install Runtime Fabric as a Kubernetes operator. - [Installing Multiple Instances on a Single Cluster](https://docs.mulesoft.com/runtime-fabric/2.8/install-multiple-instances) Install multiple instances of Runtime Fabric to share the same cluster among multiple Runtime Fabrics. - [Installing Multiple Instances on a Single OpenShift Cluster](https://docs.mulesoft.com/runtime-fabric/2.8/install-multiple-instances-openshift) Install multiple instances of Runtime Fabric to share the same OpenShift cluster among multiple Runtime Fabrics. ## See Also - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/uninstall-self) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/upgrade-index) --- product: Runtime Fabric version: 2.9 --- # Installing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To install Anypoint Runtime Fabric, choose any of the following options: - [Installing Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.9/install-self-managed) Use the `rtfctl` command line tool to install Runtime Fabric. - [Installing Runtime Fabric Using Helm](https://docs.mulesoft.com/runtime-fabric/2.9/install-helm) Use Helm package manager for Kubernetes to install Runtime Fabric. - [Installing Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.9/install-openshift) Install Runtime Fabric as a Kubernetes operator. - [Installing Multiple Instances on a Single Cluster](https://docs.mulesoft.com/runtime-fabric/2.9/install-multiple-instances) Install multiple instances of Runtime Fabric to share the same cluster among multiple Runtime Fabrics. - [Installing Multiple Instances on a Single OpenShift Cluster](https://docs.mulesoft.com/runtime-fabric/2.9/install-multiple-instances-openshift) Install multiple instances of Runtime Fabric to share the same OpenShift cluster among multiple Runtime Fabrics. ## See Also - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/uninstall-self) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/upgrade-index) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Installing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To install Anypoint Runtime Fabric, choose any of the following options: - [Installing Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed) Use the `rtfctl` command line tool to install Runtime Fabric. - [Installing Runtime Fabric Using Helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) Use Helm package manager for Kubernetes to install Runtime Fabric. - [Installing Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/latest/install-openshift) Install Runtime Fabric as a Kubernetes operator. - [Installing Multiple Instances on a Single Cluster](https://docs.mulesoft.com/runtime-fabric/latest/install-multiple-instances) Install multiple instances of Runtime Fabric to share the same cluster among multiple Runtime Fabrics. - [Installing Multiple Instances on a Single OpenShift Cluster](https://docs.mulesoft.com/runtime-fabric/latest/install-multiple-instances-openshift) Install multiple instances of Runtime Fabric to share the same OpenShift cluster among multiple Runtime Fabrics. ## See Also - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/uninstall-self) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-index) --- product: Runtime Fabric version: 2.10 --- # Installing Runtime Fabric as a Kubernetes (K8s) Operator > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can install Anypoint Runtime Fabric as a Kubernetes (K8s) operator in the following platforms: - Red Hat OpenShift Service on AWS - Microsoft Azure Red Hat OpenShift - Red Hat OpenShift Dedicated - Red Hat OpenShift on IBM Cloud - Self-managed Red Hat OpenShift editions (Platform Plus, OCP, Kubernetes engine) ## Install Runtime Fabric on Red Hat OpenShift When you install Runtime Fabric on Red Hat OpenShift, you’ll: 1. Create a Runtime Fabric using Runtime Manager 2. Create a namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure shared tenancy 5. Install and configure the Runtime Fabric operator 6. Complete the remaining installation steps to validate your Runtime Fabric and configure ingress Runtime Fabric also supports OpenShift routes, refer to [Configure OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.10/configure-openshift-routes) documentation. ## Before You Begin Before installing Runtime Fabric on Red Hat OpenShift, ensure that: - You have reviewed the architecture and requirements outlined in Runtime Fabric on Self-Managed Kubernetes - You have reviewed the network requirements - You have installed and configured a supported Red Hat OpenShift Kubernetes environment with: - A supported Kubernetes version - An ingress controller to send external requests to applications - You have privileged user permissions to complete the installation process - You have access to the following URLs needed for Red Hat OpenShift registry: - `registry.connect.redhat.com` (See the [Red Hat Container Registry Authentication](https://access.redhat.com/articles/RegistryAuthentication)) - `[https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com](https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com)` ## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric on Red Hat OpenShift, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select the Red Hat OpenShift option. 5. Review the Support responsibility disclaimer, then if you agree click **Accept**. 6. Click **Operator**. 7. Copy the activation data. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. ## Create A Namespace for Runtime Fabric In your Kubernetes cluster, create a namespace for installing Runtime Fabric. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy oc create ns ``` ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy oc create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.10/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service- apiGroup: rbac.authorization.k8s.io ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Configure the Runtime Fabric Operator To configure the Runtime Fabric operator, you supply the necessary values when prompted. 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 3. In the console, click **Create Instance**, and select **Configure via form view**. > [!WARNING] Do not change the name of the instance. Doing so can create installation errors. 4. Add any required parameters. Refer to the Installation Parameters Reference for guidance. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 5. Click **Create**. ## Installation Parameters Reference The following is an example YAML view of the installation parameters. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: custom_log4j_enabled: true muleLicense: global: authorizedNamespaces: false image: rtfRegistry: pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` ### Required Parameters The values for these required parameters are set when you create the Runtime Fabric in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters as needed.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false =======

authorizedNamespaces

Enable authorized namespaces

authorizedNamespaces:true

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key from the OpenShift Console To apply the license key from the OpenShift console, follow these steps: 1. Navigate to the Runtime Fabric operator. 2. Select the namespace in which the Runtime Fabric instance is installed. 3. Click on the **Runtime Fabric** tab. 4. Click on the **runtime-fabric** instance link. ![Runtime Fabric operator with runtime-fabric instance selected](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-license-operator-1.png) 5. Update the Runtime Fabric instance CR .yaml file by adding the `muleLicense`. ![Runtime Fabric instance with mulelicense](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-license-operator-2.png) ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Prepare for Deploying Mule Apps to Red Hat OpenShift Before you deploy any Mule applications to your Red Hat OpenShift cluster, ensure that you’ve installed your Mule license key and then, perform the following steps. Also, before attempting to deploy an Mule applications, ensure that you’ve installed your Mule license key. 1. Create a namespace for your Mule app deployments. See [Creating Application Namespaces for Application Deployments.](https://docs.mulesoft.com/runtime-fabric/2.10/create-custom-namespace) 2. From Runtime Manager, deploy a Mule app using your namespace. See [Deploy Mule Applications to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-runtime-fabric) for instructions. --- product: Runtime Fabric version: 2.11 --- # Installing Runtime Fabric as a Kubernetes (K8s) Operator > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can install Anypoint Runtime Fabric as a Kubernetes (K8s) operator in these platforms: - Red Hat OpenShift Service on AWS - Microsoft Azure Red Hat OpenShift - Red Hat OpenShift Dedicated - Red Hat OpenShift on IBM Cloud - Self-managed Red Hat OpenShift editions (Platform Plus, OCP, Kubernetes engine) ## Install Runtime Fabric on Red Hat OpenShift When you install Runtime Fabric on Red Hat OpenShift, you’ll: 1. Create a Runtime Fabric using Runtime Manager 2. Create a namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure shared tenancy 5. Install and configure the Runtime Fabric operator 6. Complete the remaining installation steps to validate your Runtime Fabric and configure ingress Runtime Fabric also supports OpenShift routes, refer to [Configure OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.11/configure-openshift-routes) documentation. ## Before You Begin Before installing Runtime Fabric on Red Hat OpenShift, ensure that: - You have reviewed the architecture and requirements outlined in Runtime Fabric on Self-Managed Kubernetes - You have reviewed the network requirements - You have installed and configured a supported Red Hat OpenShift Kubernetes environment with: - A supported Kubernetes version - An ingress controller to send external requests to applications - You have privileged user permissions to complete the installation process - You have access to these URLs needed for Red Hat OpenShift registry: - `registry.connect.redhat.com` (See the [Red Hat Container Registry Authentication](https://access.redhat.com/articles/RegistryAuthentication)) - `[https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com](https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com)` ## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric on Red Hat OpenShift, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select the Red Hat OpenShift option. 5. Review the Support responsibility disclaimer, then if you agree click **Accept**. 6. Click **Operator**. 7. Copy the activation data. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. ## Create A Namespace for Runtime Fabric In your Kubernetes cluster, create a namespace for installing Runtime Fabric. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy oc create ns ``` ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy oc create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.11/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note this: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with these contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply this configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide this. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply this RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` To use clustered apps in authorized namespaces mode, this RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service- apiGroup: rbac.authorization.k8s.io ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run this command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Configure the Runtime Fabric Operator To configure the Runtime Fabric operator, you supply the necessary values when prompted. 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 3. In the console, click **Create Instance**, and select **Configure via form view**. > [!WARNING] Do not change the name of the instance. Doing so can create installation errors. 4. Add any required parameters. Refer to the Installation Parameters Reference for guidance. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 5. Click **Create**. ## Installation Parameters Reference The following is an example YAML view of the installation parameters. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: custom_log4j_enabled: true muleLicense: global: authorizedNamespaces: false image: rtfRegistry: pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` ### Required Parameters The values for these required parameters are set when you create the Runtime Fabric in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters as needed.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false =======

authorizedNamespaces

Enable authorized namespaces

authorizedNamespaces:true

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run this command: ```copy base64 -b 0 -i ``` - On Unix, run this command: ```copy base64 -w0 ``` - On Windows, choose one of these: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use this Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key from the OpenShift Console To apply the license key from the OpenShift console, follow these steps: 1. Navigate to the Runtime Fabric operator. 2. Select the namespace in which the Runtime Fabric instance is installed. 3. Click on the **Runtime Fabric** tab. 4. Click on the **runtime-fabric** instance link. ![Runtime Fabric operator with runtime-fabric instance selected](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-license-operator-1.png) 5. Update the Runtime Fabric instance CR .yaml file by adding the `muleLicense`. ![Runtime Fabric instance with mulelicense](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-license-operator-2.png) ### Apply the License Key Using Helm To apply the license using Helm, run this command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Prepare for Deploying Mule Apps to Red Hat OpenShift Before you deploy any Mule applications to your Red Hat OpenShift cluster, ensure that you’ve installed your Mule license key and then, perform these steps. Also, before attempting to deploy an Mule applications, ensure that you’ve installed your Mule license key. 1. Create a namespace for your Mule app deployments. See [Creating Application Namespaces for Application Deployments.](https://docs.mulesoft.com/runtime-fabric/2.11/create-custom-namespace) 2. From Runtime Manager, deploy a Mule app using your namespace. See [Deploy Mule Applications to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-runtime-fabric) for instructions. --- product: Runtime Fabric version: 2.5 --- # Installing Runtime Fabric as a Kubernetes (K8s) Operator > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can install Anypoint Runtime Fabric as a Kubernetes (K8s) operator in the following platforms: - Red Hat OpenShift Service on AWS - Microsoft Azure Red Hat OpenShift - Red Hat OpenShift Dedicated - Red Hat OpenShift on IBM Cloud - Self-managed Red Hat OpenShift editions (Performance Plus, OCP, Kubernetes engine) ## Install Runtime Fabric on Red Hat OpenShift When you install Runtime Fabric on Red Hat OpenShift, you’ll: 1. Create a Runtime Fabric using Runtime Manager 2. Create a namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure shared tenancy 5. Install and configure the Runtime Fabric operator 6. Complete the remaining installation steps to validate your Runtime Fabric and configure ingress Runtime Fabric also supports OpenShift routes, refer to [Configure OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.5/configure-openshift-routes) documentation. ## Before You Begin Before installing Runtime Fabric on Red Hat OpenShift, ensure that: - You have reviewed the architecture and requirements outlined in Runtime Fabric on Self-Managed Kubernetes - You have reviewed the network requirements - You have installed and configured a supported Red Hat OpenShift Kubernetes environment with: - A supported Kubernetes version - An ingress controller to send external requests to applications - You have privileged user permissions to complete the installation process - You have access to the following URLs needed for Red Hat OpenShift registry: - `registry.connect.redhat.com` (See the [Red Hat Container Registry Authentication](https://access.redhat.com/articles/RegistryAuthentication)) - `[https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com](https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com)` ## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric on Red Hat OpenShift, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select the Red Hat OpenShift option. 5. Review the Support responsibility disclaimer, then if you agree click **Accept**. 6. Click **Operator**. 7. Copy the activation data. ## Create A Namespace for Runtime Fabric In your Kubernetes cluster, create a namespace for installing Runtime Fabric. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy oc create ns ``` ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy oc create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.5/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Configure the Runtime Fabric Operator To configure the Runtime Fabric operator, you supply the necessary values when prompted. 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 3. In the console, click **Create Instance**, and select **Configure via form view**. > [!WARNING] Do not change the name of the instance. Doing so can create installation errors. 4. Add any required parameters. Refer to the Installation Parameters Reference for guidance. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 5. Click **Create**. ## Installation Parameters Reference The following is an example YAML view of the installation parameters. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: custom_log4j_enabled: true muleLicense: global: authorizedNamespaces: false image: rtfRegistry: pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` ### Required Parameters The values for these required parameters are set when you create the Runtime Fabric in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters as needed.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false =======

authorizedNamespaces

Enable authorized namespaces

authorizedNamespaces:true

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key from the OpenShift Console To apply the license key from the OpenShift console, follow these steps: 1. Navigate to the Runtime Fabric operator. 2. Select the namespace in which the Runtime Fabric instance is installed. 3. Click on the **Runtime Fabric** tab. 4. Click on the **runtime-fabric** instance link. ![Runtime Fabric operator with runtime-fabric instance selected](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-license-operator-1.png) 5. Update the Runtime Fabric instance CR .yaml file by adding the `muleLicense`. ![Runtime Fabric instance with mulelicense](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-license-operator-2.png) ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.5/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Prepare for Deploying Mule Apps to Red Hat OpenShift Before you deploy any Mule applications to your Red Hat OpenShift cluster, ensure that you’ve installed your Mule license key and then, perform the following steps. Also, before attempting to deploy an Mule applications, ensure that you’ve installed your Mule license key. 1. Create a namespace for your Mule app deployments. See [Creating Application Namespaces for Application Deployments.](https://docs.mulesoft.com/runtime-fabric/2.5/create-custom-namespace) 2. From Runtime Manager, deploy a Mule app using your namespace. See [Deploy Mule Applications to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-to-runtime-fabric) for instructions. --- product: Runtime Fabric version: 2.6 --- # Installing Runtime Fabric as a Kubernetes (K8s) Operator > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can install Anypoint Runtime Fabric as a Kubernetes (K8s) operator in the following platforms: - Red Hat OpenShift Service on AWS - Microsoft Azure Red Hat OpenShift - Red Hat OpenShift Dedicated - Red Hat OpenShift on IBM Cloud - Self-managed Red Hat OpenShift editions (Platform Plus, OCP, Kubernetes engine) ## Install Runtime Fabric on Red Hat OpenShift When you install Runtime Fabric on Red Hat OpenShift, you’ll: 1. Create a Runtime Fabric using Runtime Manager 2. Create a namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure shared tenancy 5. Install and configure the Runtime Fabric operator 6. Complete the remaining installation steps to validate your Runtime Fabric and configure ingress Runtime Fabric also supports OpenShift routes, refer to [Configure OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.6/configure-openshift-routes) documentation. ## Before You Begin Before installing Runtime Fabric on Red Hat OpenShift, ensure that: - You have reviewed the architecture and requirements outlined in Runtime Fabric on Self-Managed Kubernetes - You have reviewed the network requirements - You have installed and configured a supported Red Hat OpenShift Kubernetes environment with: - A supported Kubernetes version - An ingress controller to send external requests to applications - You have privileged user permissions to complete the installation process - You have access to the following URLs needed for Red Hat OpenShift registry: - `registry.connect.redhat.com` (See the [Red Hat Container Registry Authentication](https://access.redhat.com/articles/RegistryAuthentication)) - `[https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com](https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com)` ## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric on Red Hat OpenShift, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select the Red Hat OpenShift option. 5. Review the Support responsibility disclaimer, then if you agree click **Accept**. 6. Click **Operator**. 7. Copy the activation data. ## Create A Namespace for Runtime Fabric In your Kubernetes cluster, create a namespace for installing Runtime Fabric. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy oc create ns ``` ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy oc create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.6/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Configure the Runtime Fabric Operator To configure the Runtime Fabric operator, you supply the necessary values when prompted. 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 3. In the console, click **Create Instance**, and select **Configure via form view**. > [!WARNING] Do not change the name of the instance. Doing so can create installation errors. 4. Add any required parameters. Refer to the Installation Parameters Reference for guidance. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 5. Click **Create**. ## Installation Parameters Reference The following is an example YAML view of the installation parameters. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: custom_log4j_enabled: true muleLicense: global: authorizedNamespaces: false image: rtfRegistry: pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` ### Required Parameters The values for these required parameters are set when you create the Runtime Fabric in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters as needed.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false =======

authorizedNamespaces

Enable authorized namespaces

authorizedNamespaces:true

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key from the OpenShift Console To apply the license key from the OpenShift console, follow these steps: 1. Navigate to the Runtime Fabric operator. 2. Select the namespace in which the Runtime Fabric instance is installed. 3. Click on the **Runtime Fabric** tab. 4. Click on the **runtime-fabric** instance link. ![Runtime Fabric operator with runtime-fabric instance selected](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-license-operator-1.png) 5. Update the Runtime Fabric instance CR .yaml file by adding the `muleLicense`. ![Runtime Fabric instance with mulelicense](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-license-operator-2.png) ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Prepare for Deploying Mule Apps to Red Hat OpenShift Before you deploy any Mule applications to your Red Hat OpenShift cluster, ensure that you’ve installed your Mule license key and then, perform the following steps. Also, before attempting to deploy an Mule applications, ensure that you’ve installed your Mule license key. 1. Create a namespace for your Mule app deployments. See [Creating Application Namespaces for Application Deployments.](https://docs.mulesoft.com/runtime-fabric/2.6/create-custom-namespace) 2. From Runtime Manager, deploy a Mule app using your namespace. See [Deploy Mule Applications to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-runtime-fabric) for instructions. --- product: Runtime Fabric version: 2.7 --- # Installing Runtime Fabric as a Kubernetes (K8s) Operator > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can install Anypoint Runtime Fabric as a Kubernetes (K8s) operator in the following platforms: - Red Hat OpenShift Service on AWS - Microsoft Azure Red Hat OpenShift - Red Hat OpenShift Dedicated - Red Hat OpenShift on IBM Cloud - Self-managed Red Hat OpenShift editions (Platform Plus, OCP, Kubernetes engine) ## Install Runtime Fabric on Red Hat OpenShift When you install Runtime Fabric on Red Hat OpenShift, you’ll: 1. Create a Runtime Fabric using Runtime Manager 2. Create a namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure shared tenancy 5. Install and configure the Runtime Fabric operator 6. Complete the remaining installation steps to validate your Runtime Fabric and configure ingress Runtime Fabric also supports OpenShift routes, refer to [Configure OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.7/configure-openshift-routes) documentation. ## Before You Begin Before installing Runtime Fabric on Red Hat OpenShift, ensure that: - You have reviewed the architecture and requirements outlined in Runtime Fabric on Self-Managed Kubernetes - You have reviewed the network requirements - You have installed and configured a supported Red Hat OpenShift Kubernetes environment with: - A supported Kubernetes version - An ingress controller to send external requests to applications - You have privileged user permissions to complete the installation process - You have access to the following URLs needed for Red Hat OpenShift registry: - `registry.connect.redhat.com` (See the [Red Hat Container Registry Authentication](https://access.redhat.com/articles/RegistryAuthentication)) - `[https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com](https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com)` ## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric on Red Hat OpenShift, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select the Red Hat OpenShift option. 5. Review the Support responsibility disclaimer, then if you agree click **Accept**. 6. Click **Operator**. 7. Copy the activation data. ## Create A Namespace for Runtime Fabric In your Kubernetes cluster, create a namespace for installing Runtime Fabric. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy oc create ns ``` ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy oc create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.7/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service- apiGroup: rbac.authorization.k8s.io ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Configure the Runtime Fabric Operator To configure the Runtime Fabric operator, you supply the necessary values when prompted. 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 3. In the console, click **Create Instance**, and select **Configure via form view**. > [!WARNING] Do not change the name of the instance. Doing so can create installation errors. 4. Add any required parameters. Refer to the Installation Parameters Reference for guidance. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 5. Click **Create**. ## Installation Parameters Reference The following is an example YAML view of the installation parameters. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: custom_log4j_enabled: true muleLicense: global: authorizedNamespaces: false image: rtfRegistry: pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` ### Required Parameters The values for these required parameters are set when you create the Runtime Fabric in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters as needed.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false =======

authorizedNamespaces

Enable authorized namespaces

authorizedNamespaces:true

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key from the OpenShift Console To apply the license key from the OpenShift console, follow these steps: 1. Navigate to the Runtime Fabric operator. 2. Select the namespace in which the Runtime Fabric instance is installed. 3. Click on the **Runtime Fabric** tab. 4. Click on the **runtime-fabric** instance link. ![Runtime Fabric operator with runtime-fabric instance selected](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-license-operator-1.png) 5. Update the Runtime Fabric instance CR .yaml file by adding the `muleLicense`. ![Runtime Fabric instance with mulelicense](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-license-operator-2.png) ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Prepare for Deploying Mule Apps to Red Hat OpenShift Before you deploy any Mule applications to your Red Hat OpenShift cluster, ensure that you’ve installed your Mule license key and then, perform the following steps. Also, before attempting to deploy an Mule applications, ensure that you’ve installed your Mule license key. 1. Create a namespace for your Mule app deployments. See [Creating Application Namespaces for Application Deployments.](https://docs.mulesoft.com/runtime-fabric/2.7/create-custom-namespace) 2. From Runtime Manager, deploy a Mule app using your namespace. See [Deploy Mule Applications to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-runtime-fabric) for instructions. --- product: Runtime Fabric version: 2.8 --- # Installing Runtime Fabric as a Kubernetes (K8s) Operator > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can install Anypoint Runtime Fabric as a Kubernetes (K8s) operator in the following platforms: - Red Hat OpenShift Service on AWS - Microsoft Azure Red Hat OpenShift - Red Hat OpenShift Dedicated - Red Hat OpenShift on IBM Cloud - Self-managed Red Hat OpenShift editions (Platform Plus, OCP, Kubernetes engine) ## Install Runtime Fabric on Red Hat OpenShift When you install Runtime Fabric on Red Hat OpenShift, you’ll: 1. Create a Runtime Fabric using Runtime Manager 2. Create a namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure shared tenancy 5. Install and configure the Runtime Fabric operator 6. Complete the remaining installation steps to validate your Runtime Fabric and configure ingress Runtime Fabric also supports OpenShift routes, refer to [Configure OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.8/configure-openshift-routes) documentation. ## Before You Begin Before installing Runtime Fabric on Red Hat OpenShift, ensure that: - You have reviewed the architecture and requirements outlined in Runtime Fabric on Self-Managed Kubernetes - You have reviewed the network requirements - You have installed and configured a supported Red Hat OpenShift Kubernetes environment with: - A supported Kubernetes version - An ingress controller to send external requests to applications - You have privileged user permissions to complete the installation process - You have access to the following URLs needed for Red Hat OpenShift registry: - `registry.connect.redhat.com` (See the [Red Hat Container Registry Authentication](https://access.redhat.com/articles/RegistryAuthentication)) - `[https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com](https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com)` ## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric on Red Hat OpenShift, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select the Red Hat OpenShift option. 5. Review the Support responsibility disclaimer, then if you agree click **Accept**. 6. Click **Operator**. 7. Copy the activation data. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. ## Create A Namespace for Runtime Fabric In your Kubernetes cluster, create a namespace for installing Runtime Fabric. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy oc create ns ``` ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy oc create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.8/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service- apiGroup: rbac.authorization.k8s.io ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Configure the Runtime Fabric Operator To configure the Runtime Fabric operator, you supply the necessary values when prompted. 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 3. In the console, click **Create Instance**, and select **Configure via form view**. > [!WARNING] Do not change the name of the instance. Doing so can create installation errors. 4. Add any required parameters. Refer to the Installation Parameters Reference for guidance. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 5. Click **Create**. ## Installation Parameters Reference The following is an example YAML view of the installation parameters. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: custom_log4j_enabled: true muleLicense: global: authorizedNamespaces: false image: rtfRegistry: pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` ### Required Parameters The values for these required parameters are set when you create the Runtime Fabric in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters as needed.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false =======

authorizedNamespaces

Enable authorized namespaces

authorizedNamespaces:true

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key from the OpenShift Console To apply the license key from the OpenShift console, follow these steps: 1. Navigate to the Runtime Fabric operator. 2. Select the namespace in which the Runtime Fabric instance is installed. 3. Click on the **Runtime Fabric** tab. 4. Click on the **runtime-fabric** instance link. ![Runtime Fabric operator with runtime-fabric instance selected](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-license-operator-1.png) 5. Update the Runtime Fabric instance CR .yaml file by adding the `muleLicense`. ![Runtime Fabric instance with mulelicense](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-license-operator-2.png) ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Prepare for Deploying Mule Apps to Red Hat OpenShift Before you deploy any Mule applications to your Red Hat OpenShift cluster, ensure that you’ve installed your Mule license key and then, perform the following steps. Also, before attempting to deploy an Mule applications, ensure that you’ve installed your Mule license key. 1. Create a namespace for your Mule app deployments. See [Creating Application Namespaces for Application Deployments.](https://docs.mulesoft.com/runtime-fabric/2.8/create-custom-namespace) 2. From Runtime Manager, deploy a Mule app using your namespace. See [Deploy Mule Applications to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-runtime-fabric) for instructions. --- product: Runtime Fabric version: 2.9 --- # Installing Runtime Fabric as a Kubernetes (K8s) Operator > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can install Anypoint Runtime Fabric as a Kubernetes (K8s) operator in the following platforms: - Red Hat OpenShift Service on AWS - Microsoft Azure Red Hat OpenShift - Red Hat OpenShift Dedicated - Red Hat OpenShift on IBM Cloud - Self-managed Red Hat OpenShift editions (Platform Plus, OCP, Kubernetes engine) ## Install Runtime Fabric on Red Hat OpenShift When you install Runtime Fabric on Red Hat OpenShift, you’ll: 1. Create a Runtime Fabric using Runtime Manager 2. Create a namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure shared tenancy 5. Install and configure the Runtime Fabric operator 6. Complete the remaining installation steps to validate your Runtime Fabric and configure ingress Runtime Fabric also supports OpenShift routes, refer to [Configure OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/2.9/configure-openshift-routes) documentation. ## Before You Begin Before installing Runtime Fabric on Red Hat OpenShift, ensure that: - You have reviewed the architecture and requirements outlined in Runtime Fabric on Self-Managed Kubernetes - You have reviewed the network requirements - You have installed and configured a supported Red Hat OpenShift Kubernetes environment with: - A supported Kubernetes version - An ingress controller to send external requests to applications - You have privileged user permissions to complete the installation process - You have access to the following URLs needed for Red Hat OpenShift registry: - `registry.connect.redhat.com` (See the [Red Hat Container Registry Authentication](https://access.redhat.com/articles/RegistryAuthentication)) - `[https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com](https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com)` ## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric on Red Hat OpenShift, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select the Red Hat OpenShift option. 5. Review the Support responsibility disclaimer, then if you agree click **Accept**. 6. Click **Operator**. 7. Copy the activation data. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. ## Create A Namespace for Runtime Fabric In your Kubernetes cluster, create a namespace for installing Runtime Fabric. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy oc create ns ``` ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy oc create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.9/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service- apiGroup: rbac.authorization.k8s.io ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 6. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Configure the Runtime Fabric Operator To configure the Runtime Fabric operator, you supply the necessary values when prompted. 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 3. In the console, click **Create Instance**, and select **Configure via form view**. > [!WARNING] Do not change the name of the instance. Doing so can create installation errors. 4. Add any required parameters. Refer to the Installation Parameters Reference for guidance. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 5. Click **Create**. ## Installation Parameters Reference The following is an example YAML view of the installation parameters. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: custom_log4j_enabled: true muleLicense: global: authorizedNamespaces: false image: rtfRegistry: pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` ### Required Parameters The values for these required parameters are set when you create the Runtime Fabric in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters as needed.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false =======

authorizedNamespaces

Enable authorized namespaces

authorizedNamespaces:true

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key from the OpenShift Console To apply the license key from the OpenShift console, follow these steps: 1. Navigate to the Runtime Fabric operator. 2. Select the namespace in which the Runtime Fabric instance is installed. 3. Click on the **Runtime Fabric** tab. 4. Click on the **runtime-fabric** instance link. ![Runtime Fabric operator with runtime-fabric instance selected](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-license-operator-1.png) 5. Update the Runtime Fabric instance CR .yaml file by adding the `muleLicense`. ![Runtime Fabric instance with mulelicense](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-license-operator-2.png) ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. Please read this link: > [KB article](https://help.salesforce.com/s/articleView?id=001116839&type=1) for more details. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Prepare for Deploying Mule Apps to Red Hat OpenShift Before you deploy any Mule applications to your Red Hat OpenShift cluster, ensure that you’ve installed your Mule license key and then, perform the following steps. Also, before attempting to deploy an Mule applications, ensure that you’ve installed your Mule license key. 1. Create a namespace for your Mule app deployments. See [Creating Application Namespaces for Application Deployments.](https://docs.mulesoft.com/runtime-fabric/2.9/create-custom-namespace) 2. From Runtime Manager, deploy a Mule app using your namespace. See [Deploy Mule Applications to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-runtime-fabric) for instructions. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Installing Runtime Fabric as a Kubernetes (K8s) Operator > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can install Anypoint Runtime Fabric as a Kubernetes (K8s) operator in the following platforms: - Red Hat OpenShift Service on AWS - Microsoft Azure Red Hat OpenShift - Red Hat OpenShift Dedicated - Red Hat OpenShift on IBM Cloud - Self-managed Red Hat OpenShift editions (Platform Plus, OCP, Kubernetes engine) ## Install Runtime Fabric on Red Hat OpenShift When you install Runtime Fabric on Red Hat OpenShift, you’ll: 1. Create a Runtime Fabric using Runtime Manager 2. Create a namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure shared tenancy 5. Install and configure the Runtime Fabric operator 6. Complete the remaining installation steps to validate your Runtime Fabric and configure ingress Runtime Fabric also supports OpenShift routes, refer to [Configure OpenShift Routes](https://docs.mulesoft.com/runtime-fabric/latest/configure-openshift-routes) documentation. ## Before You Begin Before installing Runtime Fabric on Red Hat OpenShift, ensure that: - You have reviewed the architecture and requirements outlined in Runtime Fabric on Self-Managed Kubernetes - You have reviewed the network requirements - You have installed and configured a supported Red Hat OpenShift Kubernetes environment with: - A supported Kubernetes version - An ingress controller to send external requests to applications - You have privileged user permissions to complete the installation process - You have access to the following URLs needed for Red Hat OpenShift registry: - `registry.connect.redhat.com` (See the [Red Hat Container Registry Authentication](https://access.redhat.com/articles/RegistryAuthentication)) - `[https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com](https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com)` ## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric on Red Hat OpenShift, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select the Red Hat OpenShift option. 5. Review the Support responsibility disclaimer, then if you agree click **Accept**. 6. Click **Operator**. 7. Copy the activation data. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. ## Create A Namespace for Runtime Fabric In your Kubernetes cluster, create a namespace for installing Runtime Fabric. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy oc create ns ``` ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The registry URL depends on your control plane. Refer to the [required parameters](#required-parameters) section for the `rtfRegistry` value for your region. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy oc create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy oc apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. Apply the following RoleBinding template to rtf namespace and any additional namespaces: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` > [!NOTE] Starting with Runtime Fabric agent version 3.0.0, the `am-log-forwarder` service account > is no longer required as log forwarding occurs exclusively through application sidecar containers. > You can omit this service account for new installations of version 3.0.0 or later. For more > information, refer to > [Migrate Log Forwarding Before Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/migrate-log-forwarding). To use clustered apps in authorized namespaces mode, this RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service- apiGroup: rbac.authorization.k8s.io ``` For ``, use the same template as well: ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 6. Create the `rtf-cluster-version-reader` ClusterRole and ClusterRoleBinding to allow the Runtime Fabric agent to access OpenShift cluster version information. This is required when using authorized namespaces on OpenShift. Apply this configuration: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf-cluster-version-reader rules: - apiGroups: - config.openshift.io resources: - clusterversions verbs: - get - list ``` ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: rtf-cluster-version-reader roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf-cluster-version-reader subjects: - kind: ServiceAccount name: rtf-agent namespace: ``` 7. In your cluster, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces. Note that the additional namespace mapping keys must be unique since they use the standard K8s resource (ConfigMap). There is no specific requirements on the format of the key name provided they are unique. ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 8. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy oc -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ### Install the Red Hat OpenShift Runtime Fabric Operator You install the Runtime Fabric operator (`rtf-agent-operator`) from the OperatorHub. 1. In the Red Hat OpenShift console, navigate to **Operators** > **OperatorHub**. 2. In the OperatorHub search field, search for the Runtime Fabric operator. 3. In the rtf-agent-operator dialog, click **Install**. > [!NOTE] Installing the Runtime Fabric operator requires manual approval and may take several > minutes to complete. ## Configure the Runtime Fabric Operator To configure the Runtime Fabric operator, you supply the necessary values when prompted. 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. In the console, switch the value of **Project** to the namespace you created for installing Runtime Fabric. 3. In the console, click **Create Instance**, and select **Configure via form view**. > [!WARNING] Do not change the name of the instance. Doing so can create installation errors. 4. Add any required parameters. Refer to the Installation Parameters Reference for guidance. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 5. Click **Create**. ## Installation Parameters Reference The following is an example YAML view of the installation parameters. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: custom_log4j_enabled: true muleLicense: global: authorizedNamespaces: false image: rtfRegistry: pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` ### Required Parameters The values for these required parameters are set when you create the Runtime Fabric in Runtime Manager. If you’re not using a local registry, use the default values for the registry URL and pull secret.
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

  • US: rtf-runtime-registry.kprod.msap.io

  • EU: rtf-runtime-registry.kprod-eu.msap.io

  • Canada: rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net

  • Japan: rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters as needed.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false =======

authorizedNamespaces

Enable authorized namespaces

authorizedNamespaces:true

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key from the OpenShift Console To apply the license key from the OpenShift console, follow these steps: 1. Navigate to the Runtime Fabric operator. 2. Select the namespace in which the Runtime Fabric instance is installed. 3. Click on the **Runtime Fabric** tab. 4. Click on the **runtime-fabric** instance link. ![Runtime Fabric operator with runtime-fabric instance selected](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-license-operator-1.png) 5. Update the Runtime Fabric instance CR .yaml file by adding the `muleLicense`. ![Runtime Fabric instance with mulelicense](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-license-operator-2.png) ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Prepare for Deploying Mule Apps to Red Hat OpenShift Before you deploy any Mule applications to your Red Hat OpenShift cluster, ensure that you’ve installed your Mule license key and then, perform the following steps. Also, before attempting to deploy an Mule applications, ensure that you’ve installed your Mule license key. 1. Create a namespace for your Mule app deployments. See [Creating Application Namespaces for Application Deployments.](https://docs.mulesoft.com/runtime-fabric/latest/create-custom-namespace) 2. From Runtime Manager, deploy a Mule app using your namespace. See [Deploy Mule Applications to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) for instructions. --- product: Runtime Fabric version: 2.10 --- # Installing Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) or VMware Tanzu Kubernetes Grid installation that you manage. ## Steps to Install Runtime Fabric Using Helm When you use Helm to install Runtime Fabric, you: 1. Create a Runtime Fabric using Runtime Manager 2. Create the `rtf` namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure additional authorized namespaces 5. Add the Runtime Fabric Helm repository 6. Download the `values.yml` file and install Runtime Fabric 7. Complete install steps ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure that you have: - Reviewed the architecture and requirements outlined in the [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.10/). - [Configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-self-managed-network-configuration). - Installed and configured your Kubernetes environment as follows: - Running an ACK, AKS, EKS, EKS-A, GKE, RKE, or VMware Tanzu Kubernetes environment. Other Kubernetes environments are not supported. - Running a supported Kubernetes version. - Running an ingress controller to send external requests to applications. - Installed Helm 3 or later and have privileged user permissions. > [!IMPORTANT] > > - If you use Helm to manage your Runtime Fabric installation, you can use the `rtfctl` command > line utility later to manage Mule license keys and proxies. However, you’ll need to track any > post-installation changes you make, as explained in the [upgrade documentation](https://docs.mulesoft.com/runtime-fabric/2.10/upgrade-helm). ### Helm Support Runtime Fabric supports installations, upgrades, and rollbacks using Helm for versions 1.13 and later. ## Create a Runtime Fabric Using Runtime Manager To install Runtime Fabric with Helm, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data that is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of the following options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Review the Support responsibility disclaimer, and if you agree, click **Accept**. 6. Click Helm. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. > [!NOTE] The remaining steps in the Helm-install process reference placeholder values. You can > retrieve the actual values from Runtime Manager when you create the Runtime Fabric instance. ## Create A Namespace for Runtime Fabric You must create a namespace named `rtf` in your Kubernetes cluster. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy kubectl create ns rtf ``` Using `rtf` as a namespace applies only in the case of single cluster or single instance. ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## Add the Runtime Fabric Helm Repository You need to add the Runtime Fabric Helm repo to the namespace you created. The Runtime Fabric Helm repo contains the chart needed to install Runtime Fabric. To add the Helm repo, run: ```copy helm repo add --username --password ``` > [!NOTE] If you already added the Helm repo, and you get a result that Runtime Fabric skipped > adding the repo, run `helm repo update` before installing, or upgrading to, a new Runtime Fabric > version. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.10/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy kubectl apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` 5. In the `rtf` namespace, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces: ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: ADDITIONAL_NAMESPACE_1: "additional-namespace1" ADDITIONAL_NAMESPACE_2: "additional-namespace2" ``` 6. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy kubectl -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ## Install Runtime Fabric To install Runtime Fabric, use the `values.yml` file supplied by Runtime Manager. 1. Download the `values.yml` file. 2. Add any optional parameters needed. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 3. Run the following command: ```copy helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` ## Values.yml Reference The following is an example `values.yml` file. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: muleLicense: customLog4jEnabled: false global: nodeWatcherEnabled: true deploymentRateLimitPerSecond: 1 authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kqa.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` > [!NOTE] If you are configuring a Runtime Fabric BYOK with an EU control plane, review the changes > in > [Hostname Configuration](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration#hostname-configuration) > for a correct configuration. Specifically, the property > `rtfRegistry: rtf-runtime-registry.kprod-eu.msap.io`. ### Required Parameters These required values are created and added to `values.yml` when you create the Runtime Fabric in Runtime Manager:
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters in `values.yml` as needed before installing Runtime Fabric.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false

crds.install

Enables crds installations

crds.install: true, for first Runtime Fabric installation and false for subsequent installations

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

nodeWatcherEnabled

Enables or disables node watcher for the cluster

nodeWatcherEnabled:true default value true

deploymentRateLimitPerSecond

Sets the deployment rate limit per second

deploymentRateLimitPerSecond: 1 default value 1

fipsEnabled

Enable FIPS for Helm managed Runtime Fabrics.

fipsEnabled: true default value false

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric using helm, refer to the [Helm rollback](https://helm.sh/docs/helm/helm_rollback/) documentation for the command description. ## Retrieve Helm Registry Endpoints and Credentials To obtain the Helm registry endpoints and credentials, make a request to this API endpoint using a bearer token for authentication: `[https:///runtimefabric/api/organizations//helmrepoproperties](https://\/runtimefabric/api/organizations/\/helmrepoproperties)` Replace `` with your organization’s ID, and `` with your Anypoint Platform region URL. The API response has this structure: { "RTF\_IMAGE\_REGISTRY\_ENDPOINT": "rtf-runtime-registry.kprod.msap.io", "RTF\_IMAGE\_REGISTRY\_USER": "username/us-east-1/truncated", "RTF\_IMAGE\_REGISTRY\_PASSWORD": "Truncated" } The URL for the Helm repository containing the Helm charts is constructed as follows: `{RTF_IMAGE_REGISTRY_ENDPOINT}/charts`. For example: `rtf-runtime-registry.kprod.msap.io/charts` ## See Also - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.11 --- # Installing Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) or VMware Tanzu Kubernetes Grid installation that you manage. ## Steps to Install Runtime Fabric Using Helm When you use Helm to install Runtime Fabric, you: 1. Create a Runtime Fabric using Runtime Manager 2. Create the `rtf` namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure additional authorized namespaces 5. Add the Runtime Fabric Helm repository 6. Download the `values.yml` file and install Runtime Fabric 7. Complete install steps ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure that you have: - Reviewed the architecture and requirements outlined in the [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.11/). - [Configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-self-managed-network-configuration). - Installed and configured your Kubernetes environment as follows: - Running an ACK, AKS, EKS, EKS-A, GKE, RKE, or VMware Tanzu Kubernetes environment. Other Kubernetes environments are not supported. - Running a supported Kubernetes version. - Running an ingress controller to send external requests to applications. - Installed Helm 3 or later and have privileged user permissions. > [!IMPORTANT] > > - If you use Helm to manage your Runtime Fabric installation, you can use the `rtfctl` command > line utility later to manage Mule license keys and proxies. However, you’ll need to track any > post-installation changes you make, as explained in the [upgrade documentation](https://docs.mulesoft.com/runtime-fabric/2.11/upgrade-helm). ### Helm Support Runtime Fabric supports installations, upgrades, and rollbacks using Helm for versions 1.13 and later. ## Create a Runtime Fabric Using Runtime Manager To install Runtime Fabric with Helm, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data that is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of these options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Review the Support responsibility disclaimer, and if you agree, click **Accept**. 6. Click Helm. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. > [!NOTE] The remaining steps in the Helm-install process reference placeholder values. You can > retrieve the actual values from Runtime Manager when you create the Runtime Fabric instance. ## Create A Namespace for Runtime Fabric You must create a namespace named `rtf` in your Kubernetes cluster. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy kubectl create ns rtf ``` Using `rtf` as a namespace applies only in the case of single cluster or single instance. ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## Add the Runtime Fabric Helm Repository You need to add the Runtime Fabric Helm repo to the namespace you created. The Runtime Fabric Helm repo contains the chart needed to install Runtime Fabric. To add the Helm repo, run: ```copy helm repo add --username --password ``` > [!NOTE] If you already added the Helm repo, and you get a result that Runtime Fabric skipped > adding the repo, run `helm repo update` before installing, or upgrading to, a new Runtime Fabric > version. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.11/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note this: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with these contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy kubectl apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply this configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide this. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` To use clustered apps in authorized namespaces mode, this RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` 5. In the `rtf` namespace, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces: ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: ADDITIONAL_NAMESPACE_1: "additional-namespace1" ADDITIONAL_NAMESPACE_2: "additional-namespace2" ``` 6. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run this command: ```copy kubectl -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ## Install Runtime Fabric To install Runtime Fabric, use the `values.yml` file supplied by Runtime Manager. 1. Download the `values.yml` file. 2. Add any optional parameters needed. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 3. Run this command: ```copy helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` ## Values.yml Reference The following is an example `values.yml` file. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: muleLicense: customLog4jEnabled: false global: nodeWatcherEnabled: true deploymentRateLimitPerSecond: 1 authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kqa.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` > [!NOTE] If you are configuring a Runtime Fabric BYOK with an EU control plane, review the changes > in > [Hostname Configuration](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration#hostname-configuration) > for a correct configuration. Specifically, the property > `rtfRegistry: rtf-runtime-registry.kprod-eu.msap.io`. ### Required Parameters These required values are created and added to `values.yml` when you create the Runtime Fabric in Runtime Manager:
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters in `values.yml` as needed before installing Runtime Fabric.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false

crds.install

Enables crds installations

crds.install: true, for first Runtime Fabric installation and false for subsequent installations

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

nodeWatcherEnabled

Enables or disables node watcher for the cluster

nodeWatcherEnabled:true default value true

deploymentRateLimitPerSecond

Sets the deployment rate limit per second

deploymentRateLimitPerSecond: 1 default value 1

fipsEnabled

Enable FIPS for Helm managed Runtime Fabrics.

fipsEnabled: true default value false

### Configure Core Software High Availability Parameters From Runtime Fabric version 2.11.0 onwards, you can configure these optional core software high availability parameters in the `values.yml` file. These are the default values: ```yaml global: core: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway agent: replicas: 1 app: resources: requests: cpu: 100m memory: 200Mi limits: cpu: 1000m memory: 500Mi rtfd: resources: requests: cpu: 150m memory: 200Mi limits: cpu: 200m memory: 300Mi mule-clusterip-service: replicas: 1 resources: requests: cpu: 50m memory: 100Mi limits: cpu: 500m memory: 500Mi resource-cache: replicas: 1 nginx: resources: requests: cpu: 100m memory: 50Mi limits: cpu: 500m memory: 250Mi fetcher: resources: requests: cpu: 50m memory: 50Mi limits: cpu: 50m memory: 100Mi ``` For each Runtime Fabric deployment (`agent`, `resource-cache`, and `mule-clusterip-service`), you can configure the `resources` and the number of `replicas`. In the case of `agent` deployments, having multiple replicas doesn’t increase the throughput it can manage. However, if the leading pod encounters an issue, one of the remaining replicas takes the lead and continues to serve traffic. By modifying the `topologySpreadConstraints` object, you can control how the replicas for each deployment are distributed across the cluster nodes. > [!NOTE] If you configure these values and then roll back a Runtime Fabric instance to a previous > version, the configuration isn’t applied to the older version. ## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run this command: ```copy base64 -b 0 -i ``` - On Unix, run this command: ```copy base64 -w0 ``` - On Windows, choose one of these: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use this Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run this command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run this command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric using helm, refer to the [Helm rollback](https://helm.sh/docs/helm/helm_rollback/) documentation for the command description. ## Retrieve Helm Registry Endpoints and Credentials To obtain the Helm registry endpoints and credentials, make a request to this API endpoint using a bearer token for authentication: `[https:///runtimefabric/api/organizations//helmrepoproperties](https://\/runtimefabric/api/organizations/\/helmrepoproperties)` Replace `` with your organization’s ID, and `` with your Anypoint Platform region URL. The API response has this structure: { "RTF\_IMAGE\_REGISTRY\_ENDPOINT": "rtf-runtime-registry.kprod.msap.io", "RTF\_IMAGE\_REGISTRY\_USER": "username/us-east-1/truncated", "RTF\_IMAGE\_REGISTRY\_PASSWORD": "Truncated" } The URL for the Helm repository containing the Helm charts is constructed as follows: `{RTF_IMAGE_REGISTRY_ENDPOINT}/charts`. For example: `rtf-runtime-registry.kprod.msap.io/charts` ## See Also - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.5 --- # Installing Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) or VMware Tanzu Kubernetes Grid installation that you manage. ## Steps to Install Runtime Fabric Using Helm When you use Helm to install Runtime Fabric, you: 1. Create a Runtime Fabric using Runtime Manager 2. Create the `rtf` namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure additional authorized namespaces 5. Add the Runtime Fabric Helm repository 6. Download the `values.yml` file and install Runtime Fabric 7. Complete install steps ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure that you have: - Reviewed the architecture and requirements outlined in the [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.5/). - [Configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/install-self-managed-network-configuration). - Installed and configured your Kubernetes environment as follows: - Running an ACK, AKS, EKS, EKS-A, GKE, RKE, or VMware Tanzu Kubernetes environment. Other Kubernetes environments are not supported. - Running a supported Kubernetes version. - Running an ingress controller to send external requests to applications. - Installed Helm 3 or later and have privileged user permissions. > [!IMPORTANT] > > - If you use Helm to manage your Runtime Fabric installation, you can use the `rtfctl` command > line utility later to manage Mule license keys and proxies. However, you’ll need to track any > post-installation changes you make, as explained in the [upgrade documentation](https://docs.mulesoft.com/runtime-fabric/2.5/upgrade-helm). ### Helm Support Runtime Fabric supports installations, upgrades, and rollbacks using Helm for versions 1.13 and later. ## Create a Runtime Fabric Using Runtime Manager To install Runtime Fabric with Helm, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data that is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of the following options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Review the Support responsibility disclaimer, and if you agree, click **Accept**. 6. Click Helm. > [!NOTE] The remaining steps in the Helm-install process reference placeholder values. You can > retrieve the actual values from Runtime Manager when you create the Runtime Fabric instance. ## Create A Namespace for Runtime Fabric You must create a namespace named `rtf` in your Kubernetes cluster. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy kubectl create ns rtf ``` Using `rtf` as a namespace applies only in the case of single cluster or single instance. ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## Add the Runtime Fabric Helm Repository You need to add the Runtime Fabric Helm repo to the namespace you created. The Runtime Fabric Helm repo contains the chart needed to install Runtime Fabric. To add the Helm repo, run: ```copy helm repo add --username --password ``` > [!NOTE] If you already added the Helm repo, and you get a result that Runtime Fabric skipped > adding the repo, run `helm repo update` before installing, or upgrading to, a new Runtime Fabric > version. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.5/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy kubectl apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` 5. In the `rtf` namespace, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces: ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: ADDITIONAL_NAMESPACE_1: "additional-namespace1" ADDITIONAL_NAMESPACE_2: "additional-namespace2" ``` 6. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy kubectl -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ## Install Runtime Fabric To install Runtime Fabric, use the `values.yml` file supplied by Runtime Manager. 1. Download the `values.yml` file. 2. Add any optional parameters needed. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 3. Run the following command: ```copy helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` ## Values.yml Reference The following is an example `values.yml` file. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: muleLicense: customLog4jEnabled: false global: nodeWatcherEnabled: true deploymentRateLimitPerSecond: 1 authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kqa.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` > [!NOTE] If you are configuring a Runtime Fabric BYOK with an EU control plane, review the changes > in > [Hostname Configuration](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration#hostname-configuration) > for a correct configuration. Specifically, the property > `rtfRegistry: rtf-runtime-registry.kprod-eu.msap.io`. ### Required Parameters These required values are created and added to `values.yml` when you create the Runtime Fabric in Runtime Manager:
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters in `values.yml` as needed before installing Runtime Fabric.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false

crds.install

Enables crds installations

crds.install: true, for first Runtime Fabric installation and false for subsequent installations

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

nodeWatcherEnabled

Enables or disables node watcher for the cluster

nodeWatcherEnabled:true default value true

deploymentRateLimitPerSecond

Sets the deployment rate limit per second

deploymentRateLimitPerSecond: 1 default value 1

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.5/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric using helm, refer to the [Helm rollback](https://helm.sh/docs/helm/helm_rollback/) documentation for the command description. ## Retrieve Helm Registry Endpoints and Credentials To obtain the Helm registry endpoints and credentials, make a request to this API endpoint using a bearer token for authentication: `[https:///runtimefabric/api/organizations//helmrepoproperties](https://\/runtimefabric/api/organizations/\/helmrepoproperties)` Replace `` with your organization’s ID, and `` with your Anypoint Platform region URL. The API response has this structure: { "RTF\_IMAGE\_REGISTRY\_ENDPOINT": "rtf-runtime-registry.kprod.msap.io", "RTF\_IMAGE\_REGISTRY\_USER": "username/us-east-1/truncated", "RTF\_IMAGE\_REGISTRY\_PASSWORD": "Truncated" } The URL for the Helm repository containing the Helm charts is constructed as follows: `{RTF_IMAGE_REGISTRY_ENDPOINT}/charts`. For example: `rtf-runtime-registry.kprod.msap.io/charts` ## See Also - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.6 --- # Installing Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) or VMware Tanzu Kubernetes Grid installation that you manage. ## Steps to Install Runtime Fabric Using Helm When you use Helm to install Runtime Fabric, you: 1. Create a Runtime Fabric using Runtime Manager 2. Create the `rtf` namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure additional authorized namespaces 5. Add the Runtime Fabric Helm repository 6. Download the `values.yml` file and install Runtime Fabric 7. Complete install steps ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure that you have: - Reviewed the architecture and requirements outlined in the [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.6/). - [Configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-self-managed-network-configuration). - Installed and configured your Kubernetes environment as follows: - Running an ACK, AKS, EKS, EKS-A, GKE, RKE, or VMware Tanzu Kubernetes environment. Other Kubernetes environments are not supported. - Running a supported Kubernetes version. - Running an ingress controller to send external requests to applications. - Installed Helm 3 or later and have privileged user permissions. > [!IMPORTANT] > > - If you use Helm to manage your Runtime Fabric installation, you can use the `rtfctl` command > line utility later to manage Mule license keys and proxies. However, you’ll need to track any > post-installation changes you make, as explained in the [upgrade documentation](https://docs.mulesoft.com/runtime-fabric/2.6/upgrade-helm). ### Helm Support Runtime Fabric supports installations, upgrades, and rollbacks using Helm for versions 1.13 and later. ## Create a Runtime Fabric Using Runtime Manager To install Runtime Fabric with Helm, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data that is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of the following options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Review the Support responsibility disclaimer, and if you agree, click **Accept**. 6. Click Helm. > [!NOTE] The remaining steps in the Helm-install process reference placeholder values. You can > retrieve the actual values from Runtime Manager when you create the Runtime Fabric instance. ## Create A Namespace for Runtime Fabric You must create a namespace named `rtf` in your Kubernetes cluster. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy kubectl create ns rtf ``` Using `rtf` as a namespace applies only in the case of single cluster or single instance. ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## Add the Runtime Fabric Helm Repository You need to add the Runtime Fabric Helm repo to the namespace you created. The Runtime Fabric Helm repo contains the chart needed to install Runtime Fabric. To add the Helm repo, run: ```copy helm repo add --username --password ``` > [!NOTE] If you already added the Helm repo, and you get a result that Runtime Fabric skipped > adding the repo, run `helm repo update` before installing, or upgrading to, a new Runtime Fabric > version. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.6/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy kubectl apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` 5. In the `rtf` namespace, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces: ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: ADDITIONAL_NAMESPACE_1: "additional-namespace1" ADDITIONAL_NAMESPACE_2: "additional-namespace2" ``` 6. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy kubectl -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ## Install Runtime Fabric To install Runtime Fabric, use the `values.yml` file supplied by Runtime Manager. 1. Download the `values.yml` file. 2. Add any optional parameters needed. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 3. Run the following command: ```copy helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` ## Values.yml Reference The following is an example `values.yml` file. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: muleLicense: customLog4jEnabled: false global: nodeWatcherEnabled: true deploymentRateLimitPerSecond: 1 authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kqa.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` > [!NOTE] If you are configuring a Runtime Fabric BYOK with an EU control plane, review the changes > in > [Hostname Configuration](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration#hostname-configuration) > for a correct configuration. Specifically, the property > `rtfRegistry: rtf-runtime-registry.kprod-eu.msap.io`. ### Required Parameters These required values are created and added to `values.yml` when you create the Runtime Fabric in Runtime Manager:
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters in `values.yml` as needed before installing Runtime Fabric.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false

crds.install

Enables crds installations

crds.install: true, for first Runtime Fabric installation and false for subsequent installations

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

nodeWatcherEnabled

Enables or disables node watcher for the cluster

nodeWatcherEnabled:true default value true

deploymentRateLimitPerSecond

Sets the deployment rate limit per second

deploymentRateLimitPerSecond: 1 default value 1

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric using helm, refer to the [Helm rollback](https://helm.sh/docs/helm/helm_rollback/) documentation for the command description. ## Retrieve Helm Registry Endpoints and Credentials To obtain the Helm registry endpoints and credentials, make a request to this API endpoint using a bearer token for authentication: `[https:///runtimefabric/api/organizations//helmrepoproperties](https://\/runtimefabric/api/organizations/\/helmrepoproperties)` Replace `` with your organization’s ID, and `` with your Anypoint Platform region URL. The API response has this structure: { "RTF\_IMAGE\_REGISTRY\_ENDPOINT": "rtf-runtime-registry.kprod.msap.io", "RTF\_IMAGE\_REGISTRY\_USER": "username/us-east-1/truncated", "RTF\_IMAGE\_REGISTRY\_PASSWORD": "Truncated" } The URL for the Helm repository containing the Helm charts is constructed as follows: `{RTF_IMAGE_REGISTRY_ENDPOINT}/charts`. For example: `rtf-runtime-registry.kprod.msap.io/charts` ## See Also - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.7 --- # Installing Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) or VMware Tanzu Kubernetes Grid installation that you manage. ## Steps to Install Runtime Fabric Using Helm When you use Helm to install Runtime Fabric, you: 1. Create a Runtime Fabric using Runtime Manager 2. Create the `rtf` namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure additional authorized namespaces 5. Add the Runtime Fabric Helm repository 6. Download the `values.yml` file and install Runtime Fabric 7. Complete install steps ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure that you have: - Reviewed the architecture and requirements outlined in the [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.7/). - [Configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-self-managed-network-configuration). - Installed and configured your Kubernetes environment as follows: - Running an ACK, AKS, EKS, EKS-A, GKE, RKE, or VMware Tanzu Kubernetes environment. Other Kubernetes environments are not supported. - Running a supported Kubernetes version. - Running an ingress controller to send external requests to applications. - Installed Helm 3 or later and have privileged user permissions. > [!IMPORTANT] > > - If you use Helm to manage your Runtime Fabric installation, you can use the `rtfctl` command > line utility later to manage Mule license keys and proxies. However, you’ll need to track any > post-installation changes you make, as explained in the [upgrade documentation](https://docs.mulesoft.com/runtime-fabric/2.7/upgrade-helm). ### Helm Support Runtime Fabric supports installations, upgrades, and rollbacks using Helm for versions 1.13 and later. ## Create a Runtime Fabric Using Runtime Manager To install Runtime Fabric with Helm, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data that is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of the following options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Review the Support responsibility disclaimer, and if you agree, click **Accept**. 6. Click Helm. > [!NOTE] The remaining steps in the Helm-install process reference placeholder values. You can > retrieve the actual values from Runtime Manager when you create the Runtime Fabric instance. ## Create A Namespace for Runtime Fabric You must create a namespace named `rtf` in your Kubernetes cluster. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy kubectl create ns rtf ``` Using `rtf` as a namespace applies only in the case of single cluster or single instance. ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## Add the Runtime Fabric Helm Repository You need to add the Runtime Fabric Helm repo to the namespace you created. The Runtime Fabric Helm repo contains the chart needed to install Runtime Fabric. To add the Helm repo, run: ```copy helm repo add --username --password ``` > [!NOTE] If you already added the Helm repo, and you get a result that Runtime Fabric skipped > adding the repo, run `helm repo update` before installing, or upgrading to, a new Runtime Fabric > version. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.7/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy kubectl apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` 5. In the `rtf` namespace, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces: ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: ADDITIONAL_NAMESPACE_1: "additional-namespace1" ADDITIONAL_NAMESPACE_2: "additional-namespace2" ``` 6. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy kubectl -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ## Install Runtime Fabric To install Runtime Fabric, use the `values.yml` file supplied by Runtime Manager. 1. Download the `values.yml` file. 2. Add any optional parameters needed. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 3. Run the following command: ```copy helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` ## Values.yml Reference The following is an example `values.yml` file. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: muleLicense: customLog4jEnabled: false global: nodeWatcherEnabled: true deploymentRateLimitPerSecond: 1 authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kqa.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` > [!NOTE] If you are configuring a Runtime Fabric BYOK with an EU control plane, review the changes > in > [Hostname Configuration](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration#hostname-configuration) > for a correct configuration. Specifically, the property > `rtfRegistry: rtf-runtime-registry.kprod-eu.msap.io`. ### Required Parameters These required values are created and added to `values.yml` when you create the Runtime Fabric in Runtime Manager:
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters in `values.yml` as needed before installing Runtime Fabric.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false

crds.install

Enables crds installations

crds.install: true, for first Runtime Fabric installation and false for subsequent installations

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

nodeWatcherEnabled

Enables or disables node watcher for the cluster

nodeWatcherEnabled:true default value true

deploymentRateLimitPerSecond

Sets the deployment rate limit per second

deploymentRateLimitPerSecond: 1 default value 1

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric using helm, refer to the [Helm rollback](https://helm.sh/docs/helm/helm_rollback/) documentation for the command description. ## Retrieve Helm Registry Endpoints and Credentials To obtain the Helm registry endpoints and credentials, make a request to this API endpoint using a bearer token for authentication: `[https:///runtimefabric/api/organizations//helmrepoproperties](https://\/runtimefabric/api/organizations/\/helmrepoproperties)` Replace `` with your organization’s ID, and `` with your Anypoint Platform region URL. The API response has this structure: { "RTF\_IMAGE\_REGISTRY\_ENDPOINT": "rtf-runtime-registry.kprod.msap.io", "RTF\_IMAGE\_REGISTRY\_USER": "username/us-east-1/truncated", "RTF\_IMAGE\_REGISTRY\_PASSWORD": "Truncated" } The URL for the Helm repository containing the Helm charts is constructed as follows: `{RTF_IMAGE_REGISTRY_ENDPOINT}/charts`. For example: `rtf-runtime-registry.kprod.msap.io/charts` ## See Also - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.8 --- # Installing Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) or VMware Tanzu Kubernetes Grid installation that you manage. ## Steps to Install Runtime Fabric Using Helm When you use Helm to install Runtime Fabric, you: 1. Create a Runtime Fabric using Runtime Manager 2. Create the `rtf` namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure additional authorized namespaces 5. Add the Runtime Fabric Helm repository 6. Download the `values.yml` file and install Runtime Fabric 7. Complete install steps ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure that you have: - Reviewed the architecture and requirements outlined in the [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.8/). - [Configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-self-managed-network-configuration). - Installed and configured your Kubernetes environment as follows: - Running an ACK, AKS, EKS, EKS-A, GKE, RKE, or VMware Tanzu Kubernetes environment. Other Kubernetes environments are not supported. - Running a supported Kubernetes version. - Running an ingress controller to send external requests to applications. - Installed Helm 3 or later and have privileged user permissions. > [!IMPORTANT] > > - If you use Helm to manage your Runtime Fabric installation, you can use the `rtfctl` command > line utility later to manage Mule license keys and proxies. However, you’ll need to track any > post-installation changes you make, as explained in the [upgrade documentation](https://docs.mulesoft.com/runtime-fabric/2.8/upgrade-helm). ### Helm Support Runtime Fabric supports installations, upgrades, and rollbacks using Helm for versions 1.13 and later. ## Create a Runtime Fabric Using Runtime Manager To install Runtime Fabric with Helm, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data that is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of the following options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Review the Support responsibility disclaimer, and if you agree, click **Accept**. 6. Click Helm. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. > [!NOTE] The remaining steps in the Helm-install process reference placeholder values. You can > retrieve the actual values from Runtime Manager when you create the Runtime Fabric instance. ## Create A Namespace for Runtime Fabric You must create a namespace named `rtf` in your Kubernetes cluster. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy kubectl create ns rtf ``` Using `rtf` as a namespace applies only in the case of single cluster or single instance. ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## Add the Runtime Fabric Helm Repository You need to add the Runtime Fabric Helm repo to the namespace you created. The Runtime Fabric Helm repo contains the chart needed to install Runtime Fabric. To add the Helm repo, run: ```copy helm repo add --username --password ``` > [!NOTE] If you already added the Helm repo, and you get a result that Runtime Fabric skipped > adding the repo, run `helm repo update` before installing, or upgrading to, a new Runtime Fabric > version. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.8/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy kubectl apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` 5. In the `rtf` namespace, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces: ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: ADDITIONAL_NAMESPACE_1: "additional-namespace1" ADDITIONAL_NAMESPACE_2: "additional-namespace2" ``` 6. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy kubectl -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ## Install Runtime Fabric To install Runtime Fabric, use the `values.yml` file supplied by Runtime Manager. 1. Download the `values.yml` file. 2. Add any optional parameters needed. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 3. Run the following command: ```copy helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` ## Values.yml Reference The following is an example `values.yml` file. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: muleLicense: customLog4jEnabled: false global: nodeWatcherEnabled: true deploymentRateLimitPerSecond: 1 authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kqa.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` > [!NOTE] If you are configuring a Runtime Fabric BYOK with an EU control plane, review the changes > in > [Hostname Configuration](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration#hostname-configuration) > for a correct configuration. Specifically, the property > `rtfRegistry: rtf-runtime-registry.kprod-eu.msap.io`. ### Required Parameters These required values are created and added to `values.yml` when you create the Runtime Fabric in Runtime Manager:
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters in `values.yml` as needed before installing Runtime Fabric.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false

crds.install

Enables crds installations

crds.install: true, for first Runtime Fabric installation and false for subsequent installations

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

nodeWatcherEnabled

Enables or disables node watcher for the cluster

nodeWatcherEnabled:true default value true

deploymentRateLimitPerSecond

Sets the deployment rate limit per second

deploymentRateLimitPerSecond: 1 default value 1

fipsEnabled

Enable FIPS for Helm managed Runtime Fabrics.

fipsEnabled: true default value false

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric using helm, refer to the [Helm rollback](https://helm.sh/docs/helm/helm_rollback/) documentation for the command description. ## Retrieve Helm Registry Endpoints and Credentials To obtain the Helm registry endpoints and credentials, make a request to this API endpoint using a bearer token for authentication: `[https:///runtimefabric/api/organizations//helmrepoproperties](https://\/runtimefabric/api/organizations/\/helmrepoproperties)` Replace `` with your organization’s ID, and `` with your Anypoint Platform region URL. The API response has this structure: { "RTF\_IMAGE\_REGISTRY\_ENDPOINT": "rtf-runtime-registry.kprod.msap.io", "RTF\_IMAGE\_REGISTRY\_USER": "username/us-east-1/truncated", "RTF\_IMAGE\_REGISTRY\_PASSWORD": "Truncated" } The URL for the Helm repository containing the Helm charts is constructed as follows: `{RTF_IMAGE_REGISTRY_ENDPOINT}/charts`. For example: `rtf-runtime-registry.kprod.msap.io/charts` ## See Also - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.9 --- # Installing Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) or VMware Tanzu Kubernetes Grid installation that you manage. ## Steps to Install Runtime Fabric Using Helm When you use Helm to install Runtime Fabric, you: 1. Create a Runtime Fabric using Runtime Manager 2. Create the `rtf` namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure additional authorized namespaces 5. Add the Runtime Fabric Helm repository 6. Download the `values.yml` file and install Runtime Fabric 7. Complete install steps ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure that you have: - Reviewed the architecture and requirements outlined in the [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.9/). - [Configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-self-managed-network-configuration). - Installed and configured your Kubernetes environment as follows: - Running an ACK, AKS, EKS, EKS-A, GKE, RKE, or VMware Tanzu Kubernetes environment. Other Kubernetes environments are not supported. - Running a supported Kubernetes version. - Running an ingress controller to send external requests to applications. - Installed Helm 3 or later and have privileged user permissions. > [!IMPORTANT] > > - If you use Helm to manage your Runtime Fabric installation, you can use the `rtfctl` command > line utility later to manage Mule license keys and proxies. However, you’ll need to track any > post-installation changes you make, as explained in the [upgrade documentation](https://docs.mulesoft.com/runtime-fabric/2.9/upgrade-helm). ### Helm Support Runtime Fabric supports installations, upgrades, and rollbacks using Helm for versions 1.13 and later. ## Create a Runtime Fabric Using Runtime Manager To install Runtime Fabric with Helm, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data that is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of the following options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Review the Support responsibility disclaimer, and if you agree, click **Accept**. 6. Click Helm. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. > [!NOTE] The remaining steps in the Helm-install process reference placeholder values. You can > retrieve the actual values from Runtime Manager when you create the Runtime Fabric instance. ## Create A Namespace for Runtime Fabric You must create a namespace named `rtf` in your Kubernetes cluster. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy kubectl create ns rtf ``` Using `rtf` as a namespace applies only in the case of single cluster or single instance. ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The default registry URL is `rtf-runtime-registry.kprod.msap.io`. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## Add the Runtime Fabric Helm Repository You need to add the Runtime Fabric Helm repo to the namespace you created. The Runtime Fabric Helm repo contains the chart needed to install Runtime Fabric. To add the Helm repo, run: ```copy helm repo add --username --password ``` > [!NOTE] If you already added the Helm repo, and you get a result that Runtime Fabric skipped > adding the repo, run `helm repo update` before installing, or upgrading to, a new Runtime Fabric > version. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/2.9/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy kubectl apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` 5. In the `rtf` namespace, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces: ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: ADDITIONAL_NAMESPACE_1: "additional-namespace1" ADDITIONAL_NAMESPACE_2: "additional-namespace2" ``` 6. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy kubectl -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ## Install Runtime Fabric To install Runtime Fabric, use the `values.yml` file supplied by Runtime Manager. 1. Download the `values.yml` file. 2. Add any optional parameters needed. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 3. Run the following command: ```copy helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` ## Values.yml Reference The following is an example `values.yml` file. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: muleLicense: customLog4jEnabled: false global: nodeWatcherEnabled: true deploymentRateLimitPerSecond: 1 authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kqa.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` > [!NOTE] If you are configuring a Runtime Fabric BYOK with an EU control plane, review the changes > in > [Hostname Configuration](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration#hostname-configuration) > for a correct configuration. Specifically, the property > `rtfRegistry: rtf-runtime-registry.kprod-eu.msap.io`. ### Required Parameters These required values are created and added to `values.yml` when you create the Runtime Fabric in Runtime Manager:
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters in `values.yml` as needed before installing Runtime Fabric.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false

crds.install

Enables crds installations

crds.install: true, for first Runtime Fabric installation and false for subsequent installations

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

nodeWatcherEnabled

Enables or disables node watcher for the cluster

nodeWatcherEnabled:true default value true

deploymentRateLimitPerSecond

Sets the deployment rate limit per second

deploymentRateLimitPerSecond: 1 default value 1

fipsEnabled

Enable FIPS for Helm managed Runtime Fabrics.

fipsEnabled: true default value false

## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. Please read this link: > [KB article](https://help.salesforce.com/s/articleView?id=001116839&type=1) for more details. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric using helm, refer to the [Helm rollback](https://helm.sh/docs/helm/helm_rollback/) documentation for the command description. ## Retrieve Helm Registry Endpoints and Credentials To obtain the Helm registry endpoints and credentials, make a request to this API endpoint using a bearer token for authentication: `[https:///runtimefabric/api/organizations//helmrepoproperties](https://\/runtimefabric/api/organizations/\/helmrepoproperties)` Replace `` with your organization’s ID, and `` with your Anypoint Platform region URL. The API response has this structure: { "RTF\_IMAGE\_REGISTRY\_ENDPOINT": "rtf-runtime-registry.kprod.msap.io", "RTF\_IMAGE\_REGISTRY\_USER": "username/us-east-1/truncated", "RTF\_IMAGE\_REGISTRY\_PASSWORD": "Truncated" } The URL for the Helm repository containing the Helm charts is constructed as follows: `{RTF_IMAGE_REGISTRY_ENDPOINT}/charts`. For example: `rtf-runtime-registry.kprod.msap.io/charts` ## See Also - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Installing Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Oracle Kubernetes Engine (OKE), Rancher Kubernetes Engine (RKE) or VMware Tanzu Kubernetes Grid installation that you manage. ## Steps to Install Runtime Fabric Using Helm When you use Helm to install Runtime Fabric, you: 1. Create a Runtime Fabric using Runtime Manager 2. Create the `rtf` namespace for Runtime Fabric 3. Create a Docker pull secret for pulling the Runtime Fabric component images 4. Optionally, configure additional authorized namespaces 5. Add the Runtime Fabric Helm repository 6. Download the `values.yml` file and install Runtime Fabric 7. Complete install steps ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure that you have: - Reviewed the architecture and requirements outlined in the [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/latest/). - [Configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration). - Installed and configured your Kubernetes environment as follows: - Running an ACK, AKS, EKS, EKS-A, GKE, OKE, RKE, or VMware Tanzu Kubernetes environment. Other Kubernetes environments aren’t supported. - Running a supported Kubernetes version. - Running an ingress controller to send external requests to applications. - Installed Helm 3 or later and have privileged user permissions. > [!IMPORTANT] > > - If you use Helm to manage your Runtime Fabric installation, you can use the `rtfctl` command > line utility later to manage Mule license keys and proxies. However, you’ll need to track any > post-installation changes you make, as explained in the [upgrade documentation](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-helm). ### Helm Support Runtime Fabric supports installations, upgrades, and rollbacks using Helm for versions 2.0 and later. ## Create a Runtime Fabric Using Runtime Manager To install Runtime Fabric with Helm, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data that is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of these options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine - Oracle Kubernetes Engine 5. Review the Support responsibility disclaimer, and if you agree, click **Accept**. 6. Click Helm. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. > [!NOTE] The remaining steps in the Helm-install process reference placeholder values. You can > retrieve the actual values from Runtime Manager when you create the Runtime Fabric instance. ## Create A Namespace for Runtime Fabric You must create a namespace named `rtf` in your Kubernetes cluster. This namespace is where you install Runtime Fabric components. To create the namespace, run: ```copy kubectl create ns rtf ``` Using `rtf` as a namespace applies only in the case of single cluster or single instance. ## Create A Docker Pull Secret After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric. The registry URL depends on your control plane. Refer to the [required parameters](#required-parameters) section for the `rtfRegistry` value for your region. If you’re using a local registry, specify those values here. To create the pull secret, run: ```copy kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## Add the Runtime Fabric Helm Repository You need to add the Runtime Fabric Helm repo to the namespace you created. The Runtime Fabric Helm repo contains the chart needed to install Runtime Fabric. To add the Helm repo, run: ```copy helm repo add --username --password ``` > [!NOTE] If you already added the Helm repo, and you get a result that Runtime Fabric skipped > adding the repo, run `helm repo update` before installing, or upgrading to, a new Runtime Fabric > version. ## (Optional) Configure Authorized Namespaces You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces), which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster. ### Before You Begin Before configuring authorized namespaces, note the following: - You must create the `authorized-namespaces` ConfigMap file _before_ installing Runtime Fabric. Additionally, you must name the ConfigMap, `authorized-namespaces`. - The `rtf:resource-metrics-collector` ClusterRole has cluster-wide permissions to `get` and `list` nodes, pods, and namespaces and has `watch` permissions for nodes. The role ClusterRole is defined as follows: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents: ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. Apply the file you just created: ```copy kubectl apply -f .yaml ``` 3. Repeat steps 1 and 2 to add as many namespaces as you need. 4. Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace: ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` To use clustered apps in authorized namespaces mode, the following RoleBinding must be created: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` 5. In the `rtf` namespace, create a ConfigMap file named `authorized-namespaces` and list any additional namespaces: ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: ADDITIONAL_NAMESPACE_1: "additional-namespace1" ADDITIONAL_NAMESPACE_2: "additional-namespace2" ``` 6. If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command: ```copy kubectl -nrtf delete po -l app=agent ``` After you delete the pod, Kubernetes starts a new one. ## Install Runtime Fabric To install Runtime Fabric, use the `values.yml` file supplied by Runtime Manager. 1. Download the `values.yml` file. 2. Add any optional parameters needed. If you’re using authorized namespaces, set `authorizedNamespaces` to `true`. 3. Run the following command: ```copy helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` ## Values.yml Reference The following is an example `values.yml` file. ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: muleLicense: customLog4jEnabled: false global: nodeWatcherEnabled: true deploymentRateLimitPerSecond: 1 authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kqa.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` > [!NOTE] If you are configuring a Runtime Fabric BYOK for a non-US Cloud region (EU Cloud, Canada > Cloud, Japan Cloud, India Cloud, Australia Cloud, or United Kingdom Cloud), review the changes in > [Hostname Configuration](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration#hostname-configuration) for a > correct configuration. Set the `rtfRegistry` property to the registry URL for your cloud region. ### Required Parameters These required values are created and added to `values.yml` when you create the Runtime Fabric in Runtime Manager:
KeyValueExample

activationData

Activation data

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

Registry URL

  • US: rtf-runtime-registry.kprod.msap.io

  • EU: rtf-runtime-registry.kprod-eu.msap.io

  • Canada: rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net

  • Japan: rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net

  • India Cloud: rtf-runtime-registry-mulesoft-cp.sfdc-y37hzm.svc.sfdcfc.net

  • Australia Cloud: rtf-runtime-registry-mulesoft-cp.sfdc-vwfla6.svc.sfdcfc.net

  • United Kingdom Cloud: rtf-runtime-registry-mulesoft-cp.sfdc-5pakla.svc.sfdcfc.net

pullSecretName

Registry secret

<pull_secret>

muleLicense

Mule license for applications

<mule_license_key>. Must be Base64 encoded.

### Optional Parameters Set these optional parameters in `values.yml` as needed before installing Runtime Fabric.
KeyValueExample

customLog4jEnabled

Enables or disables custom Log4j configurations

customLog4jEnabled: true, default is false

authorizedNamespaces

Enables or disables additional namespaces

authorizedNamespaces: true, default is false

crds.install

Enables crds installations

crds.install: true, for first Runtime Fabric installation and false for subsequent installations

  • proxy.http_proxy

  • proxy.http_no_proxy

Proxy and no_proxy values

proxy.monitoring_proxy

Anypoint Monitoring proxy values

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

The Filebeat read path

  • /var/lib/docker/

  • /var/log/containers

  • /var/log/pods

nodeWatcherEnabled

Enables or disables node watcher for the cluster

nodeWatcherEnabled:true default value true

deploymentRateLimitPerSecond

Sets the deployment rate limit per second

deploymentRateLimitPerSecond: 1 default value 1

fipsEnabled

Enable FIPS for Helm managed Runtime Fabrics.

fipsEnabled: true default value false

### Configure Core Software High Availability Parameters From Runtime Fabric version 2.11.0 onwards, you can configure these optional core software high availability parameters in the `values.yml` file. These are the default values: ```yaml global: core: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway agent: replicas: 1 app: resources: requests: cpu: 100m memory: 200Mi limits: cpu: 1000m memory: 500Mi rtfd: resources: requests: cpu: 150m memory: 200Mi limits: cpu: 200m memory: 300Mi mule-clusterip-service: replicas: 1 resources: requests: cpu: 50m memory: 100Mi limits: cpu: 500m memory: 500Mi resource-cache: replicas: 1 nginx: resources: requests: cpu: 100m memory: 50Mi limits: cpu: 500m memory: 250Mi fetcher: resources: requests: cpu: 50m memory: 50Mi limits: cpu: 50m memory: 100Mi ``` For each Runtime Fabric deployment (`agent`, `resource-cache`, and `mule-clusterip-service`), you can configure the `resources` and the number of `replicas`. In the case of `agent` deployments, having multiple replicas doesn’t increase the throughput it can manage. However, if the leading pod encounters an issue, one of the remaining replicas takes the lead and continues to serve traffic. By modifying the `topologySpreadConstraints` object, you can control how the replicas for each deployment are distributed across the cluster nodes. You can also use `global.core.affinity` to apply Kubernetes [affinity and anti-affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) rules to Runtime Fabric core service pods. Use this to control node affinity, pod affinity, or pod anti-affinity for Runtime Fabric components. For example, to restrict core pods to `amd64` nodes: ```yaml global: core: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/arch operator: In values: - amd64 ``` > [!NOTE] If you configure these values and then roll back a Runtime Fabric instance to a previous > version, the configuration isn’t applied to the older version. ## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric using helm, refer to the [Helm rollback](https://helm.sh/docs/helm/helm_rollback/) documentation for the command description. ## Retrieve Helm Registry Endpoints and Credentials To obtain the Helm registry endpoints and credentials, make a request to this API endpoint using a bearer token for authentication: `[https:///runtimefabric/api/organizations//helmrepoproperties](https://\/runtimefabric/api/organizations/\/helmrepoproperties)` Replace `` with your organization’s ID, and `` with your Anypoint Platform region URL. The API response has this structure: { "RTF\_IMAGE\_REGISTRY\_ENDPOINT": "rtf-runtime-registry.kprod.msap.io", "RTF\_IMAGE\_REGISTRY\_USER": "username/us-east-1/truncated", "RTF\_IMAGE\_REGISTRY\_PASSWORD": "Truncated" } The URL for the Helm repository containing the Helm charts is constructed as follows: `{RTF_IMAGE_REGISTRY_ENDPOINT}/charts`. For example: - US Cloud: `rtf-runtime-registry.kprod.msap.io/charts` - EU Cloud: `rtf-runtime-registry.kprod-eu.msap.io/charts` - Canada Cloud: `rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net/charts` - Japan Cloud: `rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net/charts` - India Cloud: `rtf-runtime-registry-mulesoft-cp.sfdc-y37hzm.svc.sfdcfc.net/charts` - Australia Cloud: `rtf-runtime-registry-mulesoft-cp.sfdc-vwfla6.svc.sfdcfc.net/charts` - United Kingdom Cloud: `rtf-runtime-registry-mulesoft-cp.sfdc-5pakla.svc.sfdcfc.net/charts` ## See Also - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.5 --- # Installing Runtime Fabric Using rtfctl > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) installation that you manage. > [!NOTE] Runtime Fabric versions 2.2.5 or later that support multiple instances require `rtfctl` > version 0.4.1 or later. > [!NOTE] `rtfctl` always installs the latest version of Runtime Fabric agent. Refer to [scalability benchmarking](https://docs.mulesoft.com/runtime-fabric/2.5/rtf-scale) to review the limits for `rtfctl`\-based deployments. For larger deployments, use Helm-based Runtime Fabric deployments so you can allocate additional resources to the agent for optimal performance. ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure: - You have reviewed the architecture and requirements outlined in [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/) - You have [configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/install-self-managed-network-configuration) - You have installed and configured your Kubernetes environment with: - An ACK, AKS, EKS, EKS-A, GKE, or RKE Kubernetes environment. Other Kubernetes environments are not supported. - A supported Kubernetes version. - An ingress controller to send external requests to applications. - You create your clusters using the latest Runtime Fabric agent version available. If you can’t do so, refer to [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1). > [!IMPORTANT] > > - If you want to use a local registry with Runtime Fabric, follow the installation instructions in > [Using a Local Registry with Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/configure-local-registry). You must set up the > local registry during installation. ## RTFCTL Versions Compatibility The following tables list the `rtfctl` versions compatibility with Runtime Fabric appliance 1.x.x agent versions and Runtime Fabric self-managed 2.x.x agent versions. ### Runtime Fabric Appliance 1.x.x The following `rtfctl` versions are compatible with all supported Runtime Fabric agents on appliance clusters:
RTF appliance 1.x.x agent versionrtfctl version

All versions

0.6.0-2.release-gravity

All versions

0.5.2-4.release-gravity

All versions

0.3.87 to 0.4.22

### Runtime Fabric Self-Managed (BYOK) 2.x.x The following `rtfctl` versions are compatible with Runtime Fabric agents in self-managed Kubernetes clusters:
RTF self-managed 2.x.x agent versionrtfctl version

2.4.0

0.4.1 or later

2.3.34

0.4.1 or later

2.3.1

0.4.1 or later

2.2.5

0.4.1 or later

2.1.30

0.3.87 to 1.0.12

2.1.0

0.3.87 to 1.0.12

2.0.0

0.3.87 to 1.0.12

## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of the following options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Click **Next**. 6. Click **rtfctl**. 7. Review the **Support responsibility** disclaimer, then if you agree click **Accept**. Runtime Manager creates the Runtime Fabric and displays the Activation State page. This page displays the activation data used to install Runtime Fabric on a Kubernetes service. Copy this data to the clipboard for use in the next section. ## Download the rtfctl Utility Runtime Fabric uses the `rtfctl` command-line utility for installation and management tasks. See [Install the Runtime Fabric Command Line Tool](https://docs.mulesoft.com/runtime-fabric/2.5/install-rtfctl). 1. Download the `rtfctl` command-line utility: `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Choose the appropriate method: - Windows ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe ``` - MacOS (Darwin) ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl ``` - Linux ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` command-line utility: ```copy chmod +x rtfctl ``` ## Install Runtime Fabric After creating a Runtime Fabric in Runtime Manager and obtaining the activation data, install Runtime Fabric into your Kubernetes service using the `rtfctl` command-line utility. If your Kubernetes configuration is not located in the `\~/.kube/config` directory, set the `KUBECONFIG` environment variable before running `rtfctl`: ```copy export KUBECONFIG= ``` 1. Validate that your Kubernetes environment is ready for installation: ```copy rtfctl validate ``` The `validate` option verifies that: - The Kubernetes environment is running. - All required components exist. - All required services are available. The `rtfctl` command-line utility outputs any incompatibilities with the Kubernetes environment. 2. Install Runtime Fabric: ```copy rtfctl install ``` `` is the activation data obtained after creating the Runtime Fabric using Runtime Manager. During installation, the `rtfctl` utility displays any errors encountered. For private registry installations, add the `--cluster-ops-image` flag and select the image version as per the release notes of the agent version to install: ```copy rtfctl install --cluster-ops-image /mulesoft/rtf-cluster-ops: ``` ## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.5/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric trigerred automatically on failed upgrade, refer to the [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1) Knowledge base article for details. ## See Also - [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.5/) - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.10 --- # Installing Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) installation that you manage. > [!NOTE] Runtime Fabric versions 2.2.5 or later that support multiple instances require `rtfctl` > version 0.4.1 or later. > [!NOTE] `rtfctl` always installs the latest version of Runtime Fabric agent. Refer to [scalability benchmarking](https://docs.mulesoft.com/runtime-fabric/2.10/rtf-scale) to review the limits for `rtfctl`\-based deployments. For larger deployments, use Helm-based Runtime Fabric deployments so you can allocate additional resources to the agent for optimal performance. ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure: - You have reviewed the architecture and requirements outlined in [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/) - You have [configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-self-managed-network-configuration) - You have installed and configured your Kubernetes environment with: - An ACK, AKS, EKS, EKS-A, GKE, or RKE Kubernetes environment. Other Kubernetes environments are not supported. - A supported Kubernetes version. - An ingress controller to send external requests to applications. - You create your clusters using the latest Runtime Fabric agent version available. If you can’t do so, refer to [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1). > [!IMPORTANT] > > - If you want to use a local registry with Runtime Fabric, follow the installation instructions in > [Using a Local Registry with Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/configure-local-registry). You must set up the > local registry during installation. ## RTFCTL Versions Compatibility The following tables list the `rtfctl` versions compatibility with Runtime Fabric appliance 1.x.x agent versions and Runtime Fabric self-managed 2.x.x agent versions. ### Runtime Fabric Appliance 1.x.x The following `rtfctl` versions are compatible with all supported Runtime Fabric agents on appliance clusters:
RTF appliance 1.x.x agent versionrtfctl version

All versions

0.6.0-2.release-gravity

All versions

0.5.2-4.release-gravity

All versions

0.3.87 to 0.4.22

### Runtime Fabric Self-Managed (BYOK) 2.x.x The following `rtfctl` versions are compatible with Runtime Fabric agents in self-managed Kubernetes clusters:
RTF self-managed 2.x.x agent versionrtfctl version

2.7.0

1.0.79 or later

2.6.52

0.4.1 or later

2.6.42

0.4.1 or later

2.6.23

0.4.1 or later

2.6.22

0.4.1 or later

2.6.2

0.4.1 or later

2.5.0

0.4.1 or later

2.4.45

0.4.1 or later

2.4.0

0.4.1 or later

2.3.34

0.4.1 or later

2.3.1

0.4.1 or later

2.2.5

0.4.1 or later

2.1.30

0.3.87 to 1.0.12

2.1.0

0.3.87 to 1.0.12

2.0.0

0.3.87 to 1.0.12

## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of the following options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Click **Next**. 6. Click **rtfctl**. 7. Review the **Support responsibility** disclaimer, then if you agree click **Accept**. Runtime Manager creates the Runtime Fabric and displays the Activation State page. This page displays the activation data used to install Runtime Fabric on a Kubernetes service. Copy this data to the clipboard for use in the next section. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. ## Download the rtfctl Utility Runtime Fabric uses the `rtfctl` command-line utility for installation and management tasks. See [Install the Runtime Fabric Command Line Tool](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl). 1. Download the `rtfctl` command-line utility: `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Choose the appropriate method: - Windows ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe ``` - MacOS (Darwin) ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl ``` - Linux ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` command-line utility: ```copy chmod +x rtfctl ``` ## Install Runtime Fabric After creating a Runtime Fabric in Runtime Manager and obtaining the activation data, install Runtime Fabric into your Kubernetes service using the `rtfctl` command-line utility. If your Kubernetes configuration is not located in the `\~/.kube/config` directory, set the `KUBECONFIG` environment variable before running `rtfctl`: ```copy export KUBECONFIG= ``` 1. Validate that your Kubernetes environment is ready for installation: ```copy rtfctl validate ``` The `validate` option verifies that: - The Kubernetes environment is running. - All required components exist. - All required services are available. The `rtfctl` command-line utility outputs any incompatibilities with the Kubernetes environment. 2. Install Runtime Fabric: ```copy rtfctl install ``` `` is the activation data obtained after creating the Runtime Fabric using Runtime Manager. During installation, the `rtfctl` utility displays any errors encountered. For private registry installations, add the `--cluster-ops-image` flag and select the image version as per the release notes of the agent version to install: ```copy rtfctl install --cluster-ops-image /mulesoft/rtf-cluster-ops: ``` ## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric trigerred automatically on failed upgrade, refer to the [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1) Knowledge base article for details. ## See Also - [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.10/) - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.11 --- # Installing Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) installation that you manage. > [!NOTE] Runtime Fabric versions 2.2.5 or later that support multiple instances require `rtfctl` > version 0.4.1 or later. > [!NOTE] `rtfctl` always installs the latest version of Runtime Fabric agent. Refer to [scalability benchmarking](https://docs.mulesoft.com/runtime-fabric/2.11/rtf-scale) to review the limits for `rtfctl`\-based deployments. For larger deployments, use Helm-based Runtime Fabric deployments so you can allocate additional resources to the agent for optimal performance. ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure: - You have reviewed the architecture and requirements outlined in [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/) - You have [configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-self-managed-network-configuration) - You have installed and configured your Kubernetes environment with: - An ACK, AKS, EKS, EKS-A, GKE, or RKE Kubernetes environment. Other Kubernetes environments are not supported. - A supported Kubernetes version. - An ingress controller to send external requests to applications. - You create your clusters using the latest Runtime Fabric agent version available. If you can’t do so, refer to [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1). > [!IMPORTANT] > > - If you want to use a local registry with Runtime Fabric, follow the installation instructions in > [Using a Local Registry with Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/configure-local-registry). You must set up the > local registry during installation. ## RTFCTL Versions Compatibility The following tables list the `rtfctl` versions compatibility with Runtime Fabric appliance 1.x.x agent versions and Runtime Fabric self-managed 2.x.x agent versions. ### Runtime Fabric Appliance 1.x.x The following `rtfctl` versions are compatible with all supported Runtime Fabric agents on appliance clusters:
RTF appliance 1.x.x agent versionrtfctl version

All versions

0.6.0-2.release-gravity

All versions

0.5.2-4.release-gravity

All versions

0.3.87 to 0.4.22

### Runtime Fabric Self-Managed (BYOK) 2.x.x The following `rtfctl` versions are compatible with Runtime Fabric agents in self-managed Kubernetes clusters:
RTF self-managed 2.x.x agent versionrtfctl version

2.7.0

1.0.79 or later

2.6.52

0.4.1 or later

2.6.42

0.4.1 or later

2.6.23

0.4.1 or later

2.6.22

0.4.1 or later

2.6.2

0.4.1 or later

2.5.0

0.4.1 or later

2.4.45

0.4.1 or later

2.4.0

0.4.1 or later

2.3.34

0.4.1 or later

2.3.1

0.4.1 or later

2.2.5

0.4.1 or later

2.1.30

0.3.87 to 1.0.12

2.1.0

0.3.87 to 1.0.12

2.0.0

0.3.87 to 1.0.12

## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of these options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Click **Next**. 6. Click **rtfctl**. 7. Review the **Support responsibility** disclaimer, then if you agree click **Accept**. Runtime Manager creates the Runtime Fabric and displays the Activation State page. This page displays the activation data used to install Runtime Fabric on a Kubernetes service. Copy this data to the clipboard for use in the next section. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. ## Download the rtfctl Utility Runtime Fabric uses the `rtfctl` command-line utility for installation and management tasks. See [Install the Runtime Fabric Command Line Tool](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl). 1. Download the `rtfctl` command-line utility: `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Choose the appropriate method: - Windows ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe ``` - MacOS (Darwin) ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl ``` - Linux ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` command-line utility: ```copy chmod +x rtfctl ``` ## Install Runtime Fabric After creating a Runtime Fabric in Runtime Manager and obtaining the activation data, install Runtime Fabric into your Kubernetes service using the `rtfctl` command-line utility. If your Kubernetes configuration is not located in the `\~/.kube/config` directory, set the `KUBECONFIG` environment variable before running `rtfctl`: ```copy export KUBECONFIG= ``` 1. Validate that your Kubernetes environment is ready for installation: ```copy rtfctl validate ``` The `validate` option verifies that: - The Kubernetes environment is running. - All required components exist. - All required services are available. The `rtfctl` command-line utility outputs any incompatibilities with the Kubernetes environment. 2. Install Runtime Fabric: ```copy rtfctl install ``` `` is the activation data obtained after creating the Runtime Fabric using Runtime Manager. During installation, the `rtfctl` utility displays any errors encountered. For private registry installations, add the `--cluster-ops-image` flag and select the image version as per the release notes of the agent version to install: ```copy rtfctl install --cluster-ops-image /mulesoft/rtf-cluster-ops: ``` ## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run this command: ```copy base64 -b 0 -i ``` - On Unix, run this command: ```copy base64 -w0 ``` - On Windows, choose one of these: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use this Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run this command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run this command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric trigerred automatically on failed upgrade, refer to the [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1) Knowledge base article for details. ## Commands for Installing, Upgrading, and Validating a Runtime Fabric with RTFCTL Use these commands to install, upgrade, and validate a Runtime Fabric.
CommandDescription

Installs Runtime Fabric

Validates the cluster for Runtime Fabric installation

Displays the Runtime Fabric version information

### `install` - Installs Runtime Fabric rtfctl install - Override the Docker image registry URL and secret rtfctl install --image-pull-registry --image-pull-secret ### `validate` Validates the cluster for a Runtime Fabric installation - Performs a validation check rtfctl validate - Performs a validation check and passes the `fabric.tf` configuration file that contains proxy settings rtfctl validate -f To validate installation with a proxy, you must specify proxy settings in your `settings` file: MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://.com: - Override the Docker image registry URL and secret rtfctl validate --image-pull-registry --image-pull-secret ### `version` Displays the Runtime Fabric version information rtfctl version --namespace ## See Also - [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.11/) - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.6 --- # Installing Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) installation that you manage. > [!NOTE] Runtime Fabric versions 2.2.5 or later that support multiple instances require `rtfctl` > version 0.4.1 or later. > [!NOTE] `rtfctl` always installs the latest version of Runtime Fabric agent. Refer to [scalability benchmarking](https://docs.mulesoft.com/runtime-fabric/2.6/rtf-scale) to review the limits for `rtfctl`\-based deployments. For larger deployments, use Helm-based Runtime Fabric deployments so you can allocate additional resources to the agent for optimal performance. ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure: - You have reviewed the architecture and requirements outlined in [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/) - You have [configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-self-managed-network-configuration) - You have installed and configured your Kubernetes environment with: - An ACK, AKS, EKS, EKS-A, GKE, or RKE Kubernetes environment. Other Kubernetes environments are not supported. - A supported Kubernetes version. - An ingress controller to send external requests to applications. - You create your clusters using the latest Runtime Fabric agent version available. If you can’t do so, refer to [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1). > [!IMPORTANT] > > - If you want to use a local registry with Runtime Fabric, follow the installation instructions in > [Using a Local Registry with Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/configure-local-registry). You must set up the > local registry during installation. ## RTFCTL Versions Compatibility The following tables list the `rtfctl` versions compatibility with Runtime Fabric appliance 1.x.x agent versions and Runtime Fabric self-managed 2.x.x agent versions. ### Runtime Fabric Appliance 1.x.x The following `rtfctl` versions are compatible with all supported Runtime Fabric agents on appliance clusters:
RTF appliance 1.x.x agent versionrtfctl version

All versions

0.6.0-2.release-gravity

All versions

0.5.2-4.release-gravity

All versions

0.3.87 to 0.4.22

### Runtime Fabric Self-Managed (BYOK) 2.x.x The following `rtfctl` versions are compatible with Runtime Fabric agents in self-managed Kubernetes clusters:
RTF self-managed 2.x.x agent versionrtfctl version

2.6.2

0.4.1 or later

2.5.0

0.4.1 or later

2.4.0

0.4.1 or later

2.3.34

0.4.1 or later

2.3.1

0.4.1 or later

2.2.5

0.4.1 or later

2.1.30

0.3.87 to 1.0.12

2.1.0

0.3.87 to 1.0.12

2.0.0

0.3.87 to 1.0.12

## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of the following options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Click **Next**. 6. Click **rtfctl**. 7. Review the **Support responsibility** disclaimer, then if you agree click **Accept**. Runtime Manager creates the Runtime Fabric and displays the Activation State page. This page displays the activation data used to install Runtime Fabric on a Kubernetes service. Copy this data to the clipboard for use in the next section. ## Download the rtfctl Utility Runtime Fabric uses the `rtfctl` command-line utility for installation and management tasks. See [Install the Runtime Fabric Command Line Tool](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl). 1. Download the `rtfctl` command-line utility: `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Choose the appropriate method: - Windows ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe ``` - MacOS (Darwin) ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl ``` - Linux ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` command-line utility: ```copy chmod +x rtfctl ``` ## Install Runtime Fabric After creating a Runtime Fabric in Runtime Manager and obtaining the activation data, install Runtime Fabric into your Kubernetes service using the `rtfctl` command-line utility. If your Kubernetes configuration is not located in the `\~/.kube/config` directory, set the `KUBECONFIG` environment variable before running `rtfctl`: ```copy export KUBECONFIG= ``` 1. Validate that your Kubernetes environment is ready for installation: ```copy rtfctl validate ``` The `validate` option verifies that: - The Kubernetes environment is running. - All required components exist. - All required services are available. The `rtfctl` command-line utility outputs any incompatibilities with the Kubernetes environment. 2. Install Runtime Fabric: ```copy rtfctl install ``` `` is the activation data obtained after creating the Runtime Fabric using Runtime Manager. During installation, the `rtfctl` utility displays any errors encountered. For private registry installations, add the `--cluster-ops-image` flag and select the image version as per the release notes of the agent version to install: ```copy rtfctl install --cluster-ops-image /mulesoft/rtf-cluster-ops: ``` ## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric trigerred automatically on failed upgrade, refer to the [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1) Knowledge base article for details. ## See Also - [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.6/) - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.7 --- # Installing Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) installation that you manage. > [!NOTE] Runtime Fabric versions 2.2.5 or later that support multiple instances require `rtfctl` > version 0.4.1 or later. > [!NOTE] `rtfctl` always installs the latest version of Runtime Fabric agent. Refer to [scalability benchmarking](https://docs.mulesoft.com/runtime-fabric/2.7/rtf-scale) to review the limits for `rtfctl`\-based deployments. For larger deployments, use Helm-based Runtime Fabric deployments so you can allocate additional resources to the agent for optimal performance. ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure: - You have reviewed the architecture and requirements outlined in [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/) - You have [configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-self-managed-network-configuration) - You have installed and configured your Kubernetes environment with: - An ACK, AKS, EKS, EKS-A, GKE, or RKE Kubernetes environment. Other Kubernetes environments are not supported. - A supported Kubernetes version. - An ingress controller to send external requests to applications. - You create your clusters using the latest Runtime Fabric agent version available. If you can’t do so, refer to [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1). > [!IMPORTANT] > > - If you want to use a local registry with Runtime Fabric, follow the installation instructions in > [Using a Local Registry with Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/configure-local-registry). You must set up the > local registry during installation. ## RTFCTL Versions Compatibility The following tables list the `rtfctl` versions compatibility with Runtime Fabric appliance 1.x.x agent versions and Runtime Fabric self-managed 2.x.x agent versions. ### Runtime Fabric Appliance 1.x.x The following `rtfctl` versions are compatible with all supported Runtime Fabric agents on appliance clusters:
RTF appliance 1.x.x agent versionrtfctl version

All versions

0.6.0-2.release-gravity

All versions

0.5.2-4.release-gravity

All versions

0.3.87 to 0.4.22

### Runtime Fabric Self-Managed (BYOK) 2.x.x The following `rtfctl` versions are compatible with Runtime Fabric agents in self-managed Kubernetes clusters:
RTF self-managed 2.x.x agent versionrtfctl version

2.7.0

1.0.79 or later

2.6.52

0.4.1 or later

2.6.42

0.4.1 or later

2.6.23

0.4.1 or later

2.6.22

0.4.1 or later

2.6.2

0.4.1 or later

2.5.0

0.4.1 or later

2.4.45

0.4.1 or later

2.4.0

0.4.1 or later

2.3.34

0.4.1 or later

2.3.1

0.4.1 or later

2.2.5

0.4.1 or later

2.1.30

0.3.87 to 1.0.12

2.1.0

0.3.87 to 1.0.12

2.0.0

0.3.87 to 1.0.12

## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of the following options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Click **Next**. 6. Click **rtfctl**. 7. Review the **Support responsibility** disclaimer, then if you agree click **Accept**. Runtime Manager creates the Runtime Fabric and displays the Activation State page. This page displays the activation data used to install Runtime Fabric on a Kubernetes service. Copy this data to the clipboard for use in the next section. ## Download the rtfctl Utility Runtime Fabric uses the `rtfctl` command-line utility for installation and management tasks. See [Install the Runtime Fabric Command Line Tool](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl). 1. Download the `rtfctl` command-line utility: `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Choose the appropriate method: - Windows ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe ``` - MacOS (Darwin) ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl ``` - Linux ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` command-line utility: ```copy chmod +x rtfctl ``` ## Install Runtime Fabric After creating a Runtime Fabric in Runtime Manager and obtaining the activation data, install Runtime Fabric into your Kubernetes service using the `rtfctl` command-line utility. If your Kubernetes configuration is not located in the `\~/.kube/config` directory, set the `KUBECONFIG` environment variable before running `rtfctl`: ```copy export KUBECONFIG= ``` 1. Validate that your Kubernetes environment is ready for installation: ```copy rtfctl validate ``` The `validate` option verifies that: - The Kubernetes environment is running. - All required components exist. - All required services are available. The `rtfctl` command-line utility outputs any incompatibilities with the Kubernetes environment. 2. Install Runtime Fabric: ```copy rtfctl install ``` `` is the activation data obtained after creating the Runtime Fabric using Runtime Manager. During installation, the `rtfctl` utility displays any errors encountered. For private registry installations, add the `--cluster-ops-image` flag and select the image version as per the release notes of the agent version to install: ```copy rtfctl install --cluster-ops-image /mulesoft/rtf-cluster-ops: ``` ## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric trigerred automatically on failed upgrade, refer to the [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1) Knowledge base article for details. ## See Also - [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.7/) - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.8 --- # Installing Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) installation that you manage. > [!NOTE] Runtime Fabric versions 2.2.5 or later that support multiple instances require `rtfctl` > version 0.4.1 or later. > [!NOTE] `rtfctl` always installs the latest version of Runtime Fabric agent. Refer to [scalability benchmarking](https://docs.mulesoft.com/runtime-fabric/2.8/rtf-scale) to review the limits for `rtfctl`\-based deployments. For larger deployments, use Helm-based Runtime Fabric deployments so you can allocate additional resources to the agent for optimal performance. ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure: - You have reviewed the architecture and requirements outlined in [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/) - You have [configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-self-managed-network-configuration) - You have installed and configured your Kubernetes environment with: - An ACK, AKS, EKS, EKS-A, GKE, or RKE Kubernetes environment. Other Kubernetes environments are not supported. - A supported Kubernetes version. - An ingress controller to send external requests to applications. - You create your clusters using the latest Runtime Fabric agent version available. If you can’t do so, refer to [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1). > [!IMPORTANT] > > - If you want to use a local registry with Runtime Fabric, follow the installation instructions in > [Using a Local Registry with Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/configure-local-registry). You must set up the > local registry during installation. ## RTFCTL Versions Compatibility The following tables list the `rtfctl` versions compatibility with Runtime Fabric appliance 1.x.x agent versions and Runtime Fabric self-managed 2.x.x agent versions. ### Runtime Fabric Appliance 1.x.x The following `rtfctl` versions are compatible with all supported Runtime Fabric agents on appliance clusters:
RTF appliance 1.x.x agent versionrtfctl version

All versions

0.6.0-2.release-gravity

All versions

0.5.2-4.release-gravity

All versions

0.3.87 to 0.4.22

### Runtime Fabric Self-Managed (BYOK) 2.x.x The following `rtfctl` versions are compatible with Runtime Fabric agents in self-managed Kubernetes clusters:
RTF self-managed 2.x.x agent versionrtfctl version

2.7.0

1.0.79 or later

2.6.52

0.4.1 or later

2.6.42

0.4.1 or later

2.6.23

0.4.1 or later

2.6.22

0.4.1 or later

2.6.2

0.4.1 or later

2.5.0

0.4.1 or later

2.4.45

0.4.1 or later

2.4.0

0.4.1 or later

2.3.34

0.4.1 or later

2.3.1

0.4.1 or later

2.2.5

0.4.1 or later

2.1.30

0.3.87 to 1.0.12

2.1.0

0.3.87 to 1.0.12

2.0.0

0.3.87 to 1.0.12

## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of the following options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Click **Next**. 6. Click **rtfctl**. 7. Review the **Support responsibility** disclaimer, then if you agree click **Accept**. Runtime Manager creates the Runtime Fabric and displays the Activation State page. This page displays the activation data used to install Runtime Fabric on a Kubernetes service. Copy this data to the clipboard for use in the next section. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. ## Download the rtfctl Utility Runtime Fabric uses the `rtfctl` command-line utility for installation and management tasks. See [Install the Runtime Fabric Command Line Tool](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl). 1. Download the `rtfctl` command-line utility: `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Choose the appropriate method: - Windows ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe ``` - MacOS (Darwin) ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl ``` - Linux ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` command-line utility: ```copy chmod +x rtfctl ``` ## Install Runtime Fabric After creating a Runtime Fabric in Runtime Manager and obtaining the activation data, install Runtime Fabric into your Kubernetes service using the `rtfctl` command-line utility. If your Kubernetes configuration is not located in the `\~/.kube/config` directory, set the `KUBECONFIG` environment variable before running `rtfctl`: ```copy export KUBECONFIG= ``` 1. Validate that your Kubernetes environment is ready for installation: ```copy rtfctl validate ``` The `validate` option verifies that: - The Kubernetes environment is running. - All required components exist. - All required services are available. The `rtfctl` command-line utility outputs any incompatibilities with the Kubernetes environment. 2. Install Runtime Fabric: ```copy rtfctl install ``` `` is the activation data obtained after creating the Runtime Fabric using Runtime Manager. During installation, the `rtfctl` utility displays any errors encountered. For private registry installations, add the `--cluster-ops-image` flag and select the image version as per the release notes of the agent version to install: ```copy rtfctl install --cluster-ops-image /mulesoft/rtf-cluster-ops: ``` ## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric trigerred automatically on failed upgrade, refer to the [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1) Knowledge base article for details. ## See Also - [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.8/) - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.9 --- # Installing Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Rancher Kubernetes Engine (RKE) installation that you manage. > [!NOTE] Runtime Fabric versions 2.2.5 or later that support multiple instances require `rtfctl` > version 0.4.1 or later. > [!NOTE] `rtfctl` always installs the latest version of Runtime Fabric agent. Refer to [scalability benchmarking](https://docs.mulesoft.com/runtime-fabric/2.9/rtf-scale) to review the limits for `rtfctl`\-based deployments. For larger deployments, use Helm-based Runtime Fabric deployments so you can allocate additional resources to the agent for optimal performance. ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure: - You have reviewed the architecture and requirements outlined in [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/) - You have [configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-self-managed-network-configuration) - You have installed and configured your Kubernetes environment with: - An ACK, AKS, EKS, EKS-A, GKE, or RKE Kubernetes environment. Other Kubernetes environments are not supported. - A supported Kubernetes version. - An ingress controller to send external requests to applications. - You create your clusters using the latest Runtime Fabric agent version available. If you can’t do so, refer to [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1). > [!IMPORTANT] > > - If you want to use a local registry with Runtime Fabric, follow the installation instructions in > [Using a Local Registry with Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/configure-local-registry). You must set up the > local registry during installation. ## RTFCTL Versions Compatibility The following tables list the `rtfctl` versions compatibility with Runtime Fabric appliance 1.x.x agent versions and Runtime Fabric self-managed 2.x.x agent versions. ### Runtime Fabric Appliance 1.x.x The following `rtfctl` versions are compatible with all supported Runtime Fabric agents on appliance clusters:
RTF appliance 1.x.x agent versionrtfctl version

All versions

0.6.0-2.release-gravity

All versions

0.5.2-4.release-gravity

All versions

0.3.87 to 0.4.22

### Runtime Fabric Self-Managed (BYOK) 2.x.x The following `rtfctl` versions are compatible with Runtime Fabric agents in self-managed Kubernetes clusters:
RTF self-managed 2.x.x agent versionrtfctl version

2.7.0

1.0.79 or later

2.6.52

0.4.1 or later

2.6.42

0.4.1 or later

2.6.23

0.4.1 or later

2.6.22

0.4.1 or later

2.6.2

0.4.1 or later

2.5.0

0.4.1 or later

2.4.45

0.4.1 or later

2.4.0

0.4.1 or later

2.3.34

0.4.1 or later

2.3.1

0.4.1 or later

2.2.5

0.4.1 or later

2.1.30

0.3.87 to 1.0.12

2.1.0

0.3.87 to 1.0.12

2.0.0

0.3.87 to 1.0.12

## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of the following options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. Click **Next**. 6. Click **rtfctl**. 7. Review the **Support responsibility** disclaimer, then if you agree click **Accept**. Runtime Manager creates the Runtime Fabric and displays the Activation State page. This page displays the activation data used to install Runtime Fabric on a Kubernetes service. Copy this data to the clipboard for use in the next section. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. ## Download the rtfctl Utility Runtime Fabric uses the `rtfctl` command-line utility for installation and management tasks. See [Install the Runtime Fabric Command Line Tool](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl). 1. Download the `rtfctl` command-line utility: `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Choose the appropriate method: - Windows ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe ``` - MacOS (Darwin) ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl ``` - Linux ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` command-line utility: ```copy chmod +x rtfctl ``` ## Install Runtime Fabric After creating a Runtime Fabric in Runtime Manager and obtaining the activation data, install Runtime Fabric into your Kubernetes service using the `rtfctl` command-line utility. If your Kubernetes configuration is not located in the `\~/.kube/config` directory, set the `KUBECONFIG` environment variable before running `rtfctl`: ```copy export KUBECONFIG= ``` 1. Validate that your Kubernetes environment is ready for installation: ```copy rtfctl validate ``` The `validate` option verifies that: - The Kubernetes environment is running. - All required components exist. - All required services are available. The `rtfctl` command-line utility outputs any incompatibilities with the Kubernetes environment. 2. Install Runtime Fabric: ```copy rtfctl install ``` `` is the activation data obtained after creating the Runtime Fabric using Runtime Manager. During installation, the `rtfctl` utility displays any errors encountered. For private registry installations, add the `--cluster-ops-image` flag and select the image version as per the release notes of the agent version to install: ```copy rtfctl install --cluster-ops-image /mulesoft/rtf-cluster-ops: ``` ## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. Please read this link: > [KB article](https://help.salesforce.com/s/articleView?id=001116839&type=1) for more details. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric trigerred automatically on failed upgrade, refer to the [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1) Knowledge base article for details. ## See Also - [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/2.9/) - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Installing Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Oracle Kubernetes Engine (OKE), Rancher Kubernetes Engine (RKE) installation that you manage. > [!NOTE] Runtime Fabric versions 2.2.5 or later that support multiple instances require `rtfctl` > version 0.4.1 or later. > [!NOTE] `rtfctl` always installs the latest version of Runtime Fabric agent. Refer to [scalability benchmarking](https://docs.mulesoft.com/runtime-fabric/latest/rtf-scale) to review the limits for `rtfctl`\-based deployments. For larger deployments, use Helm-based Runtime Fabric deployments so you can allocate additional resources to the agent for optimal performance. ## Before you Begin Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure: - You have reviewed the architecture and requirements outlined in [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/) - You have [configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration) - You have installed and configured your Kubernetes environment with: - An ACK, AKS, EKS, EKS-A, GKE, OKE, or RKE Kubernetes environment. Other Kubernetes environments aren’t supported. - A supported Kubernetes version. - An ingress controller to send external requests to applications. - You create your clusters using the latest Runtime Fabric agent version available. If you can’t do so, refer to [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1). > [!IMPORTANT] > > - If you want to use a local registry with Runtime Fabric, follow the installation instructions in > [Using a Local Registry with Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/configure-local-registry). You must set up the > local registry during installation. ## RTFCTL Versions Compatibility The following tables list the `rtfctl` versions compatibility with Runtime Fabric appliance 1.x.x agent versions and Runtime Fabric self-managed 2.x.x agent versions. ### Runtime Fabric Appliance 1.x.x The following `rtfctl` versions are compatible with all supported Runtime Fabric agents on appliance clusters:
RTF appliance 1.x.x agent versionrtfctl version

All versions

0.6.0-2.release-gravity

All versions

0.5.2-4.release-gravity

All versions

0.3.87 to 0.4.22

### Runtime Fabric Self-Managed (BYOK) 2.x.x The following `rtfctl` versions are compatible with Runtime Fabric agents in self-managed Kubernetes clusters:
RTF self-managed 2.x.x agent versionrtfctl version

3.0.1

1.0.113 or later

2.11.0

1.0.107 or later

2.10.0

1.0.98 or later

2.9.0

1.0.92 or later

2.8.0

1.0.89 or later

2.7.0

1.0.79 or later

2.6.52

0.4.1 or later

2.6.42

0.4.1 or later

2.6.23

0.4.1 or later

2.6.22

0.4.1 or later

2.6.2

0.4.1 or later

2.5.0

0.4.1 or later

## Create a Runtime Fabric using Runtime Manager To install Runtime Fabric, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data which is needed during installation. 1. From Anypoint Platform, select Runtime Manager. 2. Click **Runtime Fabrics**. 3. Click **Create Runtime Fabric**. 4. Enter the name of the new Runtime Fabric, then select one of these options: - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine - Oracle Kubernetes Engine 5. Click **Next**. 6. Click **rtfctl**. 7. Review the **Support responsibility** disclaimer, then if you agree click **Accept**. Runtime Manager creates the Runtime Fabric and displays the Activation State page. This page displays the activation data used to install Runtime Fabric on a Kubernetes service. Copy this data to the clipboard for use in the next section. When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation. ## Download the rtfctl Utility Runtime Fabric uses the `rtfctl` command-line utility for installation and management tasks. See [Install the Runtime Fabric Command Line Tool](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl). 1. Download the `rtfctl` command-line utility: `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Choose the appropriate method: - Windows ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe ``` - MacOS (Darwin) ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl ``` - Linux ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` command-line utility: ```copy chmod +x rtfctl ``` ## Install Runtime Fabric After creating a Runtime Fabric in Runtime Manager and obtaining the activation data, install Runtime Fabric into your Kubernetes service using the `rtfctl` command-line utility. If your Kubernetes configuration is not located in the `\~/.kube/config` directory, set the `KUBECONFIG` environment variable before running `rtfctl`: ```copy export KUBECONFIG= ``` 1. Validate that your Kubernetes environment is ready for installation: ```copy rtfctl validate ``` The `validate` option verifies that: - The Kubernetes environment is running. - All required components exist. - All required services are available. The `rtfctl` command-line utility outputs any incompatibilities with the Kubernetes environment. 2. Install Runtime Fabric: ```copy rtfctl install ``` `` is the activation data obtained after creating the Runtime Fabric using Runtime Manager. During installation, the `rtfctl` utility displays any errors encountered. For private registry installations, add the `--cluster-ops-image` flag and select the image version as per the release notes of the agent version to install: ```copy rtfctl install --cluster-ops-image /mulesoft/rtf-cluster-ops: ``` ## Insert the Mule License Key If you didn’t add the Mule license key during install, you can add it using the `rtfctl` command line utility or Helm. Before you install the license key, encode it to Base64 format. ### Encode the License Key - On MacOS, run the following command: ```copy base64 -b 0 -i ``` - On Unix, run the following command: ```copy base64 -w0 ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the base64.exe program included with Windows git (C:\\Program Files\\Git\\usr\\bin). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### Apply the License Key Using rtfctl 1. On the controller node acting as the leader during installation (the installer node), run the following command: ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` You can also apply the Mule license providing the file path directly: ```copy rtfctl apply mule-license --file /path/to/license.lic ``` > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to > update the values in the OpenShift console. 2. To verify the Mule license key has applied correctly, run: ```copy rtfctl get mule-license ``` ### Apply the License Key Using Helm To apply the license using Helm, run the following command: ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## Configure the Ingress Resource Template If your ingress controller requires custom annotations and ingress class definition, follow the instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration). > [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP > load balancer per application by default. ## Validate Your Runtime Fabric After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is `Active`. Before deploying an application to your Runtime Fabric: 1. Associate the Runtime Fabric with at least one Anypoint environment. 2. Review and update the Inbound Traffic settings based upon your Kubernetes environment. 3. Deploy an application to verify that Runtime Fabric is installed and configured correctly. ## Perform a Rollback To roll back to a previous version of Runtime Fabric trigerred automatically on failed upgrade, refer to the [How to Specify the RTF Agent Version in Upgrades](https://help.salesforce.com/s/articleView?id=001117134&type=1) Knowledge base article for details. ## Commands for Installing, Upgrading, and Validating a Runtime Fabric with RTFCTL Use these commands to install, upgrade, and validate a Runtime Fabric.
CommandDescription

Installs Runtime Fabric

Validates the cluster for Runtime Fabric installation

Displays the Runtime Fabric version information

### `install` - Installs Runtime Fabric rtfctl install - Override the Docker image registry URL and secret rtfctl install --image-pull-registry --image-pull-secret ### `validate` Validates the cluster for a Runtime Fabric installation - Performs a validation check rtfctl validate - Performs a validation check and passes the `fabric.tf` configuration file that contains proxy settings rtfctl validate -f To validate installation with a proxy, you must specify proxy settings in your `settings` file: MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://.com: - Override the Docker image registry URL and secret rtfctl validate --image-pull-registry --image-pull-secret ### `version` Displays the Runtime Fabric version information rtfctl version --namespace ## See Also - [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/latest/) - [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration) - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) --- product: Runtime Fabric version: 2.5 --- # Integrating with Your Logging System Using Log4j > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. You can use any Log4j appender. For information about configuring `log4j2.xml`, see the [Log4j Configuration Syntax](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax). ## Requirements and Restrictions - MuleSoft Support doesn’t assist in implementing custom logging configurations or resolving issues caused by custom logging configurations. - MuleSoft is not responsible for issues arising from misconfiguration of your Log4j appender, including these or other issues: - Lost logging data - Performance degradation - Running out of disk space - Do not use synchronous log appenders. You can use only asynchronous log appenders. - File appenders, such as FileAppender, RollingFileAppender, AnypointMonitoringFileAppender, and RandomAccessFileAppender, are removed automatically. - When using custom Log4j configurations, both Mule runtime engine and application logs remain available in Anypoint Monitoring. ## Enabling Log4j Custom Log4j configurations are disabled by default. When you install Runtime Fabric, the parameter is disabled (`false`) in `Values.yaml`. You must set the value to `true`. You can also enable custom Log4j configurations by running the following steps: 1. From inside your cluster, run: kubectl -n rtf patch secret custom-properties -p '{\\"data\\": {\\"CUSTOM\_LOG4J\_ENABLED\\": \\"dHJ1ZQ==\\"}}' 2. Restart the Runtime Fabric agent pod. 3. Restart the application associated with the custom Log4j configuration. > [!NOTE] Custom Log4j is only supported by Mule applications running on Mule runtime engine > instances greater than or equal to Mule version 4.3.0. The Mule image must be built after Nov > 17, 2022. For details, refer to the > [Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#november-14-2022). ## Example: Create a Log4j Configuration Using Splunk For logs to be viewable in Runtime Fabric and flow to Splunk, configure the `SplunkHttp` Log4j appender. To enable the Log4j appender: 1. Update the `log4j2.xml` configuration file with your logger settings and include the `SplunkHttp` Log4j appender. In Anypoint Studio, the `log4j2.xml` file is located in the `src/main/resources` directory. ```xml ``` 1. Ensure that the configuration includes the Splunk dependency: ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` For the latest version of Splunk, see [GitHub](https://github.com/splunk/splunk-library-javalogging/tags). After your application starts, logs start flowing to your custom Log4j appender, and you can view them on your target logging system. ## See Also - [MDC Logging](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) --- product: Runtime Fabric version: 2.10 --- # Kubernetes (K8s) Best Practices for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following Kubernetes best practices for Runtime Fabric. To use the complete value of Runtime Fabric, you can refer to your respective Kubernetes (K8s) provider’s configuration specification for details. - [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/2.10/rtf-scale) These scale limits define the node count and deployments per Runtime Fabric. These limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster. - [Cluster Configuration](https://docs.mulesoft.com/runtime-fabric/2.10/rtf-cluster-config) These cluster configurations help you set up your cluster for Runtime Fabric. --- product: Runtime Fabric version: 2.11 --- # Kubernetes (K8s) Best Practices for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review these Kubernetes best practices for Runtime Fabric. To use the complete value of Runtime Fabric, you can refer to your respective Kubernetes (K8s) provider’s configuration specification for details. - [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/2.11/rtf-scale) These scale limits define the node count and deployments per Runtime Fabric. These limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster. - [Cluster Configuration](https://docs.mulesoft.com/runtime-fabric/2.11/rtf-cluster-config) These cluster configurations help you set up your cluster for Runtime Fabric. --- product: Runtime Fabric version: 2.5 --- # Kubernetes (K8s) Best Practices for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following Kubernetes best practices for Runtime Fabric. To use the complete value of Runtime Fabric, you can refer to your respective Kubernetes (K8s) provider’s configuration specification for details. - [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/2.5/rtf-scale) These scale limits define the node count and deployments per Runtime Fabric. These limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster. - [Cluster Configuration](https://docs.mulesoft.com/runtime-fabric/2.5/rtf-cluster-config) These cluster configurations help you set up your cluster for Runtime Fabric. --- product: Runtime Fabric version: 2.6 --- # Kubernetes (K8s) Best Practices for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following Kubernetes best practices for Runtime Fabric. To use the complete value of Runtime Fabric, you can refer to your respective Kubernetes (K8s) provider’s configuration specification for details. - [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/2.6/rtf-scale) These scale limits define the node count and deployments per Runtime Fabric. These limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster. - [Cluster Configuration](https://docs.mulesoft.com/runtime-fabric/2.6/rtf-cluster-config) These cluster configurations help you set up your cluster for Runtime Fabric. --- product: Runtime Fabric version: 2.7 --- # Kubernetes (K8s) Best Practices for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following Kubernetes best practices for Runtime Fabric. To use the complete value of Runtime Fabric, you can refer to your respective Kubernetes (K8s) provider’s configuration specification for details. - [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/2.7/rtf-scale) These scale limits define the node count and deployments per Runtime Fabric. These limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster. - [Cluster Configuration](https://docs.mulesoft.com/runtime-fabric/2.7/rtf-cluster-config) These cluster configurations help you set up your cluster for Runtime Fabric. --- product: Runtime Fabric version: 2.8 --- # Kubernetes (K8s) Best Practices for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following Kubernetes best practices for Runtime Fabric. To use the complete value of Runtime Fabric, you can refer to your respective Kubernetes (K8s) provider’s configuration specification for details. - [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/2.8/rtf-scale) These scale limits define the node count and deployments per Runtime Fabric. These limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster. - [Cluster Configuration](https://docs.mulesoft.com/runtime-fabric/2.8/rtf-cluster-config) These cluster configurations help you set up your cluster for Runtime Fabric. --- product: Runtime Fabric version: 2.9 --- # Kubernetes (K8s) Best Practices for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following Kubernetes best practices for Runtime Fabric. To use the complete value of Runtime Fabric, you can refer to your respective Kubernetes (K8s) provider’s configuration specification for details. - [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/2.9/rtf-scale) These scale limits define the node count and deployments per Runtime Fabric. These limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster. - [Cluster Configuration](https://docs.mulesoft.com/runtime-fabric/2.9/rtf-cluster-config) These cluster configurations help you set up your cluster for Runtime Fabric. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Kubernetes (K8s) Best Practices for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following Kubernetes best practices for Runtime Fabric. To use the complete value of Runtime Fabric, you can refer to your respective Kubernetes (K8s) provider’s configuration specification for details. - [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/latest/rtf-scale) These scale limits define the node count and deployments per Runtime Fabric. These limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster. --- product: Runtime Fabric version: 2.10 --- # Kubernetes Hardening Guide > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft is committed to ensuring the highest level of security and reliability for its Mule app deployments. As part of this dedication, MuleSoft not only provides you Kubernetes Hardening guidelines as recommendations but also diligently adheres to these guidelines for their own deployments. By strictly following Kubernetes Hardening guidelines, MuleSoft reinforces the protection of its applications and infrastructure, safeguarding against potential threats and vulnerabilities, while maintaining a robust and secure environment for both its customers and internal operations. Inspired by the NSA (National Security Agency) hardening guide, we are enabling granular security controls on Runtime Fabric. The following guide describes the security opportunities associated with setting up and securing a Kubernetes cluster based on the guidelines. For complete guidance, see the [Kubernetes Hardening Guide](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF). Runtime Fabric agent is fully compliance with the policies section of the [CIS (Center for Internet Security) Kubernetes benchmark](https://downloads.cisecurity.org/#/), when you configure the agent with the following security controls. ## Common Security Concerns on a K8s Cluster Review the following common sources of compromise: - Supply chain risks: - Container build cycle - Infrastructure acquisition - Malicious threat actors: - Exploit vulnerabilities and misconfigurations - Insider threats: - Administrators, users, or cloud providers abusing their privileges ## Secure your Runtime Fabric Environment Runtime Fabric enables you to secure your environment from the previous concerns: - Enable local registry for scanning containers and pods for vulnerabilities or misconfigurations. - Review the [security architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture) and [authorized namespace](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces) containers and pods with the least privileges possible. - Review the security architecture for network isolation and secure connection. - Use firewalls to limit unneeded network connectivity and use encryption to protect confidentiality. - Use strong authentication and authorization to limit user and administrator access as well as to limit the attack surface. - Capture and monitor audit logs so that administrators can be alerted to potential malicious activity. - Periodically review all K8s settings and use vulnerability scans to ensure risks are appropriately accounted for and security patches are applied. ## Recommendations and Implementation - Kubernetes pod security: - Use containers built to run applications as non-root users: - The container image should run an app with a non-root user and a non-root group. - K8s enforces non-root containers with `SecurityContext:runAsUser` specifying non 0 users. - Use immutable container filesystems by mounting read/write filesystems for application specific directories only. - Use technical control to enforce a minimum level of security including: - Preventing privileged containers - Denying container features frequently exploited to breakout, such as hostPID, hostIPC, hostNetwork, allowedHostPath - Rejecting containers that execute as the root user or allow elevation to root - Build secure container images: - Use only trusted repositories - Scan images for vulnerabilities and misconfigurations. The scanner allows disregarding false positives. - Protect pod service account token: - Set a service account token mounted by default on every pod. - Disable with `automountServiceAccountToken: false` - If a token is needed for instance to authenticate to external service, use RBAC to restrict pod privileges in the cluster. - Authentication and authorization: - Create RBAC policies with unique roles for users, administrators, developers, service accounts, and infrastructure team. - Audit logging and threat detection: - Persist logs to ensure availability in the case of node, pod or container level failure. - Aggregate logs external to the cluster. - Network separation and hardening: - Namespaces by default are not isolated but allow applying rules via RBAC, networking policies and resource policies. - Upgrade and application security practices: - Promptly apply security patches and updates. - Uninstall and delete unused components from the environment. You can apply your security configuration for Mule application deployments by following the guidelines on how to [Customize Mule Application Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd) documentation. --- product: Runtime Fabric version: 2.11 --- # Kubernetes Hardening Guide > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft is committed to ensuring the highest level of security and reliability for its Mule app deployments. As part of this dedication, MuleSoft not only provides you Kubernetes Hardening guidelines as recommendations but also diligently adheres to these guidelines for their own deployments. By strictly following Kubernetes Hardening guidelines, MuleSoft reinforces the protection of its applications and infrastructure, safeguarding against potential threats and vulnerabilities, while maintaining a robust and secure environment for both its customers and internal operations. Inspired by the NSA (National Security Agency) hardening guide, we are enabling granular security controls on Runtime Fabric. The following guide describes the security opportunities associated with setting up and securing a Kubernetes cluster based on the guidelines. For complete guidance, see the [Kubernetes Hardening Guide](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF). Runtime Fabric agent is fully compliance with the policies section of the [CIS (Center for Internet Security) Kubernetes benchmark](https://downloads.cisecurity.org/#/), when you configure the agent with these security controls. ## Common Security Concerns on a K8s Cluster Review these common sources of compromise: - Supply chain risks: - Container build cycle - Infrastructure acquisition - Malicious threat actors: - Exploit vulnerabilities and misconfigurations - Insider threats: - Administrators, users, or cloud providers abusing their privileges ## Secure your Runtime Fabric Environment Runtime Fabric enables you to secure your environment from the previous concerns: - Enable local registry for scanning containers and pods for vulnerabilities or misconfigurations. - Review the [security architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture) and [authorized namespace](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces) containers and pods with the least privileges possible. - Review the security architecture for network isolation and secure connection. - Use firewalls to limit unneeded network connectivity and use encryption to protect confidentiality. - Use strong authentication and authorization to limit user and administrator access as well as to limit the attack surface. - Capture and monitor audit logs so that administrators can be alerted to potential malicious activity. - Periodically review all K8s settings and use vulnerability scans to ensure risks are appropriately accounted for and security patches are applied. ## Recommendations and Implementation - Kubernetes pod security: - Use containers built to run applications as non-root users: - The container image should run an app with a non-root user and a non-root group. - K8s enforces non-root containers with `SecurityContext:runAsUser` specifying non 0 users. - Use immutable container filesystems by mounting read/write filesystems for application specific directories only. - Use technical control to enforce a minimum level of security including: - Preventing privileged containers - Denying container features frequently exploited to breakout, such as hostPID, hostIPC, hostNetwork, allowedHostPath - Rejecting containers that execute as the root user or allow elevation to root - Build secure container images: - Use only trusted repositories - Scan images for vulnerabilities and misconfigurations. The scanner allows disregarding false positives. - Protect pod service account token: - Set a service account token mounted by default on every pod. - Disable with `automountServiceAccountToken: false` - If a token is needed for instance to authenticate to external service, use RBAC to restrict pod privileges in the cluster. - Authentication and authorization: - Create RBAC policies with unique roles for users, administrators, developers, service accounts, and infrastructure team. - Audit logging and threat detection: - Persist logs to ensure availability in the case of node, pod or container level failure. - Aggregate logs external to the cluster. - Network separation and hardening: - Namespaces by default are not isolated but allow applying rules via RBAC, networking policies and resource policies. - Upgrade and application security practices: - Promptly apply security patches and updates. - Uninstall and delete unused components from the environment. You can apply your security configuration for Mule application deployments by following the guidelines on how to [Customize Mule Application Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd) documentation. --- product: Runtime Fabric version: 2.5 --- # Kubernetes Hardening Guide > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft is committed to ensuring the highest level of security and reliability for its Mule app deployments. As part of this dedication, MuleSoft not only provides you Kubernetes Hardening guidelines as recommendations but also diligently adheres to these guidelines for their own deployments. By strictly following Kubernetes Hardening guidelines, MuleSoft reinforces the protection of its applications and infrastructure, safeguarding against potential threats and vulnerabilities, while maintaining a robust and secure environment for both its customers and internal operations. Inspired by the NSA (National Security Agency) hardening guide, we are enabling granular security controls on Runtime Fabric. The following guide describes the security opportunities associated with setting up and securing a Kubernetes cluster based on the guidelines. For complete guidance, see the [Kubernetes Hardening Guide](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF). Runtime fabric agent is fully compliance with the policies section of the [CIS (Center for Internet Security) Kubernetes benchmark](https://downloads.cisecurity.org/#/), when you configure the agent with the following security controls. ## Common Security Concerns on a K8s Cluster Review the following common sources of compromise: - Supply chain risks: - Container build cycle - Infrastructure acquisition - Malicious threat actors: - Exploit vulnerabilities and misconfigurations - Insider threats: - Administrators, users, or cloud providers abusing their privileges ## Secure your Runtime Fabric Environment Runtime Fabric enables you to secure your environment from the previous concerns: - Enable local registry for scanning containers and pods for vulnerabilities or misconfigurations. - Review the [security architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture) and [authorized namespace](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces) containers and pods with the least privileges possible. - Review the security architecture for network isolation and secure connection. - Use firewalls to limit unneeded network connectivity and use encryption to protect confidentiality. - Use strong authentication and authorization to limit user and administrator access as well as to limit the attack surface. - Capture and monitor audit logs so that administrators can be alerted to potential malicious activity. - Periodically review all K8s settings and use vulnerability scans to ensure risks are appropriately accounted for and security patches are applied. ## Recommendations and Implementation - Kubernetes pod security: - Use containers built to run applications as non-root users: - The container image should run an app with a non-root user and a non-root group. - K8s enforces non-root containers with `SecurityContext:runAsUser` specifying non 0 users. - Use immutable container filesystems by mounting read/write filesystems for application specific directories only. - Use technical control to enforce a minimum level of security including: - Preventing privileged containers - Denying container features frequently exploited to breakout, such as hostPID, hostIPC, hostNetwork, allowedHostPath - Rejecting containers that execute as the root user or allow elevation to root - Build secure container images: - Use only trusted repositories - Scan images for vulnerabilities and misconfigurations. The scanner allows disregarding false positives. - Protect pod service account token: - Set a service account token mounted by default on every pod. - Disable with `automountServiceAccountToken: false` - If a token is needed for instance to authenticate to external service, use RBAC to restrict pod privileges in the cluster. - Authentication and authorization: - Create RBAC policies with unique roles for users, administrators, developers, service accounts, and infrastructure team. - Audit logging and threat detection: - Persist logs to ensure availability in the case of node, pod or container level failure. - Aggregate logs external to the cluster. - Network separation and hardening: - Namespaces by default are not isolated but allow applying rules via RBAC, networking policies and resource policies. - Upgrade and application security practices: - Promptly apply security patches and updates. - Uninstall and delete unused components from the environment. You can apply your security configuration for Mule application deployments by following the guidelines on how to [Customize Mule Application Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd) documentation. --- product: Runtime Fabric version: 2.6 --- # Kubernetes Hardening Guide > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft is committed to ensuring the highest level of security and reliability for its Mule app deployments. As part of this dedication, MuleSoft not only provides you Kubernetes Hardening guidelines as recommendations but also diligently adheres to these guidelines for their own deployments. By strictly following Kubernetes Hardening guidelines, MuleSoft reinforces the protection of its applications and infrastructure, safeguarding against potential threats and vulnerabilities, while maintaining a robust and secure environment for both its customers and internal operations. Inspired by the NSA (National Security Agency) hardening guide, we are enabling granular security controls on Runtime Fabric. The following guide describes the security opportunities associated with setting up and securing a Kubernetes cluster based on the guidelines. For complete guidance, see the [Kubernetes Hardening Guide](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF). Runtime Fabric agent is fully compliance with the policies section of the [CIS (Center for Internet Security) Kubernetes benchmark](https://downloads.cisecurity.org/#/), when you configure the agent with the following security controls. ## Common Security Concerns on a K8s Cluster Review the following common sources of compromise: - Supply chain risks: - Container build cycle - Infrastructure acquisition - Malicious threat actors: - Exploit vulnerabilities and misconfigurations - Insider threats: - Administrators, users, or cloud providers abusing their privileges ## Secure your Runtime Fabric Environment Runtime Fabric enables you to secure your environment from the previous concerns: - Enable local registry for scanning containers and pods for vulnerabilities or misconfigurations. - Review the [security architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture) and [authorized namespace](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces) containers and pods with the least privileges possible. - Review the security architecture for network isolation and secure connection. - Use firewalls to limit unneeded network connectivity and use encryption to protect confidentiality. - Use strong authentication and authorization to limit user and administrator access as well as to limit the attack surface. - Capture and monitor audit logs so that administrators can be alerted to potential malicious activity. - Periodically review all K8s settings and use vulnerability scans to ensure risks are appropriately accounted for and security patches are applied. ## Recommendations and Implementation - Kubernetes pod security: - Use containers built to run applications as non-root users: - The container image should run an app with a non-root user and a non-root group. - K8s enforces non-root containers with `SecurityContext:runAsUser` specifying non 0 users. - Use immutable container filesystems by mounting read/write filesystems for application specific directories only. - Use technical control to enforce a minimum level of security including: - Preventing privileged containers - Denying container features frequently exploited to breakout, such as hostPID, hostIPC, hostNetwork, allowedHostPath - Rejecting containers that execute as the root user or allow elevation to root - Build secure container images: - Use only trusted repositories - Scan images for vulnerabilities and misconfigurations. The scanner allows disregarding false positives. - Protect pod service account token: - Set a service account token mounted by default on every pod. - Disable with `automountServiceAccountToken: false` - If a token is needed for instance to authenticate to external service, use RBAC to restrict pod privileges in the cluster. - Authentication and authorization: - Create RBAC policies with unique roles for users, administrators, developers, service accounts, and infrastructure team. - Audit logging and threat detection: - Persist logs to ensure availability in the case of node, pod or container level failure. - Aggregate logs external to the cluster. - Network separation and hardening: - Namespaces by default are not isolated but allow applying rules via RBAC, networking policies and resource policies. - Upgrade and application security practices: - Promptly apply security patches and updates. - Uninstall and delete unused components from the environment. You can apply your security configuration for Mule application deployments by following the guidelines on how to [Customize Mule Application Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd) documentation. --- product: Runtime Fabric version: 2.7 --- # Kubernetes Hardening Guide > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft is committed to ensuring the highest level of security and reliability for its Mule app deployments. As part of this dedication, MuleSoft not only provides you Kubernetes Hardening guidelines as recommendations but also diligently adheres to these guidelines for their own deployments. By strictly following Kubernetes Hardening guidelines, MuleSoft reinforces the protection of its applications and infrastructure, safeguarding against potential threats and vulnerabilities, while maintaining a robust and secure environment for both its customers and internal operations. Inspired by the NSA (National Security Agency) hardening guide, we are enabling granular security controls on Runtime Fabric. The following guide describes the security opportunities associated with setting up and securing a Kubernetes cluster based on the guidelines. For complete guidance, see the [Kubernetes Hardening Guide](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF). Runtime Fabric agent is fully compliance with the policies section of the [CIS (Center for Internet Security) Kubernetes benchmark](https://downloads.cisecurity.org/#/), when you configure the agent with the following security controls. ## Common Security Concerns on a K8s Cluster Review the following common sources of compromise: - Supply chain risks: - Container build cycle - Infrastructure acquisition - Malicious threat actors: - Exploit vulnerabilities and misconfigurations - Insider threats: - Administrators, users, or cloud providers abusing their privileges ## Secure your Runtime Fabric Environment Runtime Fabric enables you to secure your environment from the previous concerns: - Enable local registry for scanning containers and pods for vulnerabilities or misconfigurations. - Review the [security architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture) and [authorized namespace](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces) containers and pods with the least privileges possible. - Review the security architecture for network isolation and secure connection. - Use firewalls to limit unneeded network connectivity and use encryption to protect confidentiality. - Use strong authentication and authorization to limit user and administrator access as well as to limit the attack surface. - Capture and monitor audit logs so that administrators can be alerted to potential malicious activity. - Periodically review all K8s settings and use vulnerability scans to ensure risks are appropriately accounted for and security patches are applied. ## Recommendations and Implementation - Kubernetes pod security: - Use containers built to run applications as non-root users: - The container image should run an app with a non-root user and a non-root group. - K8s enforces non-root containers with `SecurityContext:runAsUser` specifying non 0 users. - Use immutable container filesystems by mounting read/write filesystems for application specific directories only. - Use technical control to enforce a minimum level of security including: - Preventing privileged containers - Denying container features frequently exploited to breakout, such as hostPID, hostIPC, hostNetwork, allowedHostPath - Rejecting containers that execute as the root user or allow elevation to root - Build secure container images: - Use only trusted repositories - Scan images for vulnerabilities and misconfigurations. The scanner allows disregarding false positives. - Protect pod service account token: - Set a service account token mounted by default on every pod. - Disable with `automountServiceAccountToken: false` - If a token is needed for instance to authenticate to external service, use RBAC to restrict pod privileges in the cluster. - Authentication and authorization: - Create RBAC policies with unique roles for users, administrators, developers, service accounts, and infrastructure team. - Audit logging and threat detection: - Persist logs to ensure availability in the case of node, pod or container level failure. - Aggregate logs external to the cluster. - Network separation and hardening: - Namespaces by default are not isolated but allow applying rules via RBAC, networking policies and resource policies. - Upgrade and application security practices: - Promptly apply security patches and updates. - Uninstall and delete unused components from the environment. You can apply your security configuration for Mule application deployments by following the guidelines on how to [Customize Mule Application Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd) documentation. --- product: Runtime Fabric version: 2.8 --- # Kubernetes Hardening Guide > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft is committed to ensuring the highest level of security and reliability for its Mule app deployments. As part of this dedication, MuleSoft not only provides you Kubernetes Hardening guidelines as recommendations but also diligently adheres to these guidelines for their own deployments. By strictly following Kubernetes Hardening guidelines, MuleSoft reinforces the protection of its applications and infrastructure, safeguarding against potential threats and vulnerabilities, while maintaining a robust and secure environment for both its customers and internal operations. Inspired by the NSA (National Security Agency) hardening guide, we are enabling granular security controls on Runtime Fabric. The following guide describes the security opportunities associated with setting up and securing a Kubernetes cluster based on the guidelines. For complete guidance, see the [Kubernetes Hardening Guide](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF). Runtime Fabric agent is fully compliance with the policies section of the [CIS (Center for Internet Security) Kubernetes benchmark](https://downloads.cisecurity.org/#/), when you configure the agent with the following security controls. ## Common Security Concerns on a K8s Cluster Review the following common sources of compromise: - Supply chain risks: - Container build cycle - Infrastructure acquisition - Malicious threat actors: - Exploit vulnerabilities and misconfigurations - Insider threats: - Administrators, users, or cloud providers abusing their privileges ## Secure your Runtime Fabric Environment Runtime Fabric enables you to secure your environment from the previous concerns: - Enable local registry for scanning containers and pods for vulnerabilities or misconfigurations. - Review the [security architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture) and [authorized namespace](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces) containers and pods with the least privileges possible. - Review the security architecture for network isolation and secure connection. - Use firewalls to limit unneeded network connectivity and use encryption to protect confidentiality. - Use strong authentication and authorization to limit user and administrator access as well as to limit the attack surface. - Capture and monitor audit logs so that administrators can be alerted to potential malicious activity. - Periodically review all K8s settings and use vulnerability scans to ensure risks are appropriately accounted for and security patches are applied. ## Recommendations and Implementation - Kubernetes pod security: - Use containers built to run applications as non-root users: - The container image should run an app with a non-root user and a non-root group. - K8s enforces non-root containers with `SecurityContext:runAsUser` specifying non 0 users. - Use immutable container filesystems by mounting read/write filesystems for application specific directories only. - Use technical control to enforce a minimum level of security including: - Preventing privileged containers - Denying container features frequently exploited to breakout, such as hostPID, hostIPC, hostNetwork, allowedHostPath - Rejecting containers that execute as the root user or allow elevation to root - Build secure container images: - Use only trusted repositories - Scan images for vulnerabilities and misconfigurations. The scanner allows disregarding false positives. - Protect pod service account token: - Set a service account token mounted by default on every pod. - Disable with `automountServiceAccountToken: false` - If a token is needed for instance to authenticate to external service, use RBAC to restrict pod privileges in the cluster. - Authentication and authorization: - Create RBAC policies with unique roles for users, administrators, developers, service accounts, and infrastructure team. - Audit logging and threat detection: - Persist logs to ensure availability in the case of node, pod or container level failure. - Aggregate logs external to the cluster. - Network separation and hardening: - Namespaces by default are not isolated but allow applying rules via RBAC, networking policies and resource policies. - Upgrade and application security practices: - Promptly apply security patches and updates. - Uninstall and delete unused components from the environment. You can apply your security configuration for Mule application deployments by following the guidelines on how to [Customize Mule Application Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd) documentation. --- product: Runtime Fabric version: 2.9 --- # Kubernetes Hardening Guide > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft is committed to ensuring the highest level of security and reliability for its Mule app deployments. As part of this dedication, MuleSoft not only provides you Kubernetes Hardening guidelines as recommendations but also diligently adheres to these guidelines for their own deployments. By strictly following Kubernetes Hardening guidelines, MuleSoft reinforces the protection of its applications and infrastructure, safeguarding against potential threats and vulnerabilities, while maintaining a robust and secure environment for both its customers and internal operations. Inspired by the NSA (National Security Agency) hardening guide, we are enabling granular security controls on Runtime Fabric. The following guide describes the security opportunities associated with setting up and securing a Kubernetes cluster based on the guidelines. For complete guidance, see the [Kubernetes Hardening Guide](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF). Runtime Fabric agent is fully compliance with the policies section of the [CIS (Center for Internet Security) Kubernetes benchmark](https://downloads.cisecurity.org/#/), when you configure the agent with the following security controls. ## Common Security Concerns on a K8s Cluster Review the following common sources of compromise: - Supply chain risks: - Container build cycle - Infrastructure acquisition - Malicious threat actors: - Exploit vulnerabilities and misconfigurations - Insider threats: - Administrators, users, or cloud providers abusing their privileges ## Secure your Runtime Fabric Environment Runtime Fabric enables you to secure your environment from the previous concerns: - Enable local registry for scanning containers and pods for vulnerabilities or misconfigurations. - Review the [security architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture) and [authorized namespace](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces) containers and pods with the least privileges possible. - Review the security architecture for network isolation and secure connection. - Use firewalls to limit unneeded network connectivity and use encryption to protect confidentiality. - Use strong authentication and authorization to limit user and administrator access as well as to limit the attack surface. - Capture and monitor audit logs so that administrators can be alerted to potential malicious activity. - Periodically review all K8s settings and use vulnerability scans to ensure risks are appropriately accounted for and security patches are applied. ## Recommendations and Implementation - Kubernetes pod security: - Use containers built to run applications as non-root users: - The container image should run an app with a non-root user and a non-root group. - K8s enforces non-root containers with `SecurityContext:runAsUser` specifying non 0 users. - Use immutable container filesystems by mounting read/write filesystems for application specific directories only. - Use technical control to enforce a minimum level of security including: - Preventing privileged containers - Denying container features frequently exploited to breakout, such as hostPID, hostIPC, hostNetwork, allowedHostPath - Rejecting containers that execute as the root user or allow elevation to root - Build secure container images: - Use only trusted repositories - Scan images for vulnerabilities and misconfigurations. The scanner allows disregarding false positives. - Protect pod service account token: - Set a service account token mounted by default on every pod. - Disable with `automountServiceAccountToken: false` - If a token is needed for instance to authenticate to external service, use RBAC to restrict pod privileges in the cluster. - Authentication and authorization: - Create RBAC policies with unique roles for users, administrators, developers, service accounts, and infrastructure team. - Audit logging and threat detection: - Persist logs to ensure availability in the case of node, pod or container level failure. - Aggregate logs external to the cluster. - Network separation and hardening: - Namespaces by default are not isolated but allow applying rules via RBAC, networking policies and resource policies. - Upgrade and application security practices: - Promptly apply security patches and updates. - Uninstall and delete unused components from the environment. You can apply your security configuration for Mule application deployments by following the guidelines on how to [Customize Mule Application Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd) documentation. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Kubernetes Hardening Guide > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft is committed to ensuring the highest level of security and reliability for its Mule app deployments. As part of this dedication, MuleSoft not only provides you Kubernetes Hardening guidelines as recommendations but also diligently adheres to these guidelines for their own deployments. By strictly following Kubernetes Hardening guidelines, MuleSoft reinforces the protection of its applications and infrastructure, safeguarding against potential threats and vulnerabilities, while maintaining a robust and secure environment for both its customers and internal operations. Inspired by the NSA (National Security Agency) hardening guide, we are enabling granular security controls on Runtime Fabric. The following guide describes the security opportunities associated with setting up and securing a Kubernetes cluster based on the guidelines. For complete guidance, see the [Kubernetes Hardening Guide](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF). Runtime Fabric agent is fully compliance with the policies section of the [CIS (Center for Internet Security) Kubernetes benchmark](https://downloads.cisecurity.org/#/), when you configure the agent with the following security controls. ## Common Security Concerns on a K8s Cluster Review the following common sources of compromise: - Supply chain risks: - Container build cycle - Infrastructure acquisition - Malicious threat actors: - Exploit vulnerabilities and misconfigurations - Insider threats: - Administrators, users, or cloud providers abusing their privileges ## Secure your Runtime Fabric Environment Runtime Fabric enables you to secure your environment from the previous concerns: - Enable local registry for scanning containers and pods for vulnerabilities or misconfigurations. - Review the [security architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture) and [authorized namespace](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces) containers and pods with the least privileges possible. - Review the security architecture for network isolation and secure connection. - Use firewalls to limit unneeded network connectivity and use encryption to protect confidentiality. - Use strong authentication and authorization to limit user and administrator access as well as to limit the attack surface. - Capture and monitor audit logs so that administrators can be alerted to potential malicious activity. - Periodically review all K8s settings and use vulnerability scans to ensure risks are appropriately accounted for and security patches are applied. ## Recommendations and Implementation - Kubernetes pod security: - Use containers built to run applications as non-root users: - The container image should run an app with a non-root user and a non-root group. - K8s enforces non-root containers with `SecurityContext:runAsUser` specifying non 0 users. - Use immutable container filesystems by mounting read/write filesystems for application specific directories only. - Use technical control to enforce a minimum level of security including: - Preventing privileged containers - Denying container features frequently exploited to breakout, such as hostPID, hostIPC, hostNetwork, allowedHostPath - Rejecting containers that execute as the root user or allow elevation to root - Build secure container images: - Use only trusted repositories - Scan images for vulnerabilities and misconfigurations. The scanner allows disregarding false positives. - Protect pod service account token: - Set a service account token mounted by default on every pod. - Disable with `automountServiceAccountToken: false` - If a token is needed for instance to authenticate to external service, use RBAC to restrict pod privileges in the cluster. - Authentication and authorization: - Create RBAC policies with unique roles for users, administrators, developers, service accounts, and infrastructure team. - Audit logging and threat detection: - Persist logs to ensure availability in the case of node, pod or container level failure. - Aggregate logs external to the cluster. - Network separation and hardening: - Namespaces by default are not isolated but allow applying rules via RBAC, networking policies and resource policies. - Upgrade and application security practices: - Promptly apply security patches and updates. - Uninstall and delete unused components from the environment. You can apply your security configuration for Mule application deployments by following the guidelines on how to [Customize Mule Application Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd) documentation. --- product: Runtime Fabric version: 2.5 --- # Managing App Schedules > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Runtime Manager to view and control the Scheduler components within the flows in your deployed applications, all without changing the running application. For example, you might want to disable a scheduled job while one of the applications is undergoing maintenance. On the **Schedules** tab, you can: - View the schedules in your running application. - Change the schedules in your application. - Run the scheduled job immediately, without changing the schedule. - Disable or enable the schedule for a flow. You configure Scheduler component types as either _fixed frequency_ to trigger at a regular interval or _cron_ to trigger at a date and time based on a specified cron expression. > [!IMPORTANT] To change a schedule type (between fixed frequency and cron or vice versa), you must > update and redeploy the app. You can’t change the schedule type on a deployed application. > [!NOTE] The minimum required Mule runtime engine version to use this feature is 4.1.2 or later, > and the minimum Runtime Fabric Agent version is 2.0.0 or later. ## Schedule Design Considerations When designing the schedule, consider the following: - The Runtime Fabric scheduler reads the job configuration every time it runs. When you update the scheduler configuration, the change takes effect the next time the scheduler runs. - Changing the schedule redeploys your application. - If a scheduled job is not triggered because the application is not running, Runtime Fabric triggers the job as soon as the app restarts. - Schedules are based in the scheduler’s defined timezone. - For multi-replica apps, Runtime Fabric runs scheduled jobs on all replicas. If you run the scheduled job immediately by clicking **Run**, the scheduler runs on a single replica. Runtime Fabric distributes multiple concurrent schedulers across replicas. - You cannot manage Runtime Fabric schedules using scripts. Use the **Schedules** tab or the Runtime Fabric API to manage Runtime Fabric schedules. - Flow names can contain only upper and lower case latters, numbers, hyphens (`-`), underscores (`_`), and periods (`.`). The following characters are invalid: `/`, `[`, `]`, `{`, `}`, and `#`. - When you create a schedule using a scheduler that has a placeholder, the value that appears when you create a schedule varies based on when the placeholder is discovered. For example: - If the value is available before the app is deployed, the value appears. - If the value is available before deployment and depends on deployment properties, an estimation of the value appears. - If the value is a placeholder (such as `${cronExpression}`) that is provided at the time of deployment, the exact value of the placeholder does not appear in the user interface. - Runtime Fabric uses a default value of `60000`. ## Before You Begin To use the scheduling feature in Runtime Manager, deploy an application that includes one or more Scheduler elements using Anypoint Studio 7.13 or later. ![Scheduler component in the Anypoint Studio canvas](/mulesoft/current/en-us/runtime-fabric/2.5/_images/ch2-scheduler-studio.png) After you deploy the app, you can manage the schedule in Runtime Manager. The app doesn’t need to be running. Use Mule Maven facade v3 when you deploy through Maven to Runtime Fabric for the schedules to show in the Runtime Manager UI. ## View and Manage Application Schedules in Runtime Manager After deploying an app to Runtime Fabric, view and manage the Scheduler elements in Runtime Manager: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. Runtime Manager lists the Scheduler elements in the order they appear in your app: ![(1) Flow name and (2) the frequency link on the Schedulers page.](/mulesoft/current/en-us/runtime-fabric/2.5/_images/ch2-scheduler-rtm.png) - The **Name** column shows the name of the flow (1) that contains the Scheduler element. - The frequency link (2) in the **Schedule** column shows the schedule for the element. 4. If you want to see more information about when the jobs started and ended, click **Logs** in the navigation menu: ![Logs option in the navigation menu.](/mulesoft/current/en-us/runtime-fabric/2.5/_images/ch2-logs-rtm.png) 5. Click the frequency link for an element to open the schedule editor. The schedule editor you see depends on the schedule type: - [Fixed frequency](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Fixed Frequency Schedule 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![Fixed frequency schedule type](/mulesoft/current/en-us/runtime-fabric/2.5/_images/ch2-scheduler-fixed-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule: ![Fixed-frequency schedule configuration](/mulesoft/current/en-us/runtime-fabric/2.5/_images/ch2-scheduler-editor-fixed.png) You can specify milliseconds, seconds, minutes, hours, or days for the frequency. The minimum recommended frequency between calls is 10 seconds. 6. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Cron Schedule With cron expressions, you can create more complex schedule frequencies, such as every 5 minutes between 9:00 am and 10:00 am on Fridays. To change the frequency of a cron schedule type: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![cron schedule type](/mulesoft/current/en-us/runtime-fabric/2.5/_images/ch2-scheduler-cron-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** (1) to disable the schedule: ![cron schedule configuration with (1) Enabled option and (2) Quick Reference link](/mulesoft/current/en-us/runtime-fabric/2.5/_images/ch2-scheduler-editor-cron.png) 6. In the schedule editor, click **Quick Reference** (2) to expand or collapse the table that lists required fields and allowed values. The cron expression in this example sets the schedule to every 10 seconds. For information about building cron triggers: 1. View the [Quartz documentation](https://www.quartz-scheduler.org/documentation/). 2. Select a version, click **Documentation > User’s Guide > Tutorial**, and then click the **CronTrigger** lesson. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ## Run a Scheduled Job Immediately If a job runs nightly but you want to debug it now, you can trigger the job while it’s running without updating the schedule in your application. When you trigger the job in between instances of the scheduler running, the timer for the indicated time period resets. > [!NOTE] If you run the scheduled job immediately, the scheduler runs on a single replica even for > multi-replica apps. To override the schedule and run the job immediately: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Run**. ## Disable or Enable a Scheduler Element You might want to disable a scheduled job if an application you are connecting to is undergoing maintenance and then reenable it after maintenance is complete. Runtime Fabric does not run the scheduled job until you reenable the Scheduler. **Known issue**: If you disable the scheduler, it still runs when starting an application. If you want to prevent the scheduler from running, set the `startdelay` property to five seconds in your app using Anypoint Studio. To disable the Scheduler element: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Disable**. You can also disable or enable the schedule by deselecting or selecting **Enabled** in the schedule editor. ![Enabled toggle in the schedule editor](/mulesoft/current/en-us/runtime-fabric/2.5/_images/ch2-scheduler-enable.png) ## See Also - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz documentation](https://www.quartz-scheduler.org/documentation/) - [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) --- product: Runtime Fabric version: 2.10 --- # Managing Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to manage Mule apps deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays details for an application

Displays disk usage for an application

Displays the JVM memory usage in a pod

Creates a debugging information package for an application

Restarts an application

Captures a JVM heap dump

Captures a JVM thread dump

## `delete` Deletes a secure property rtfctl delete secure-property -n ## `describe` Displays details for an application in a specific namespace rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ## `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ## `memory` Displays the JVM memory usage in a pod - Gets the JVM memory for each replica rtfctl memory --app-namespace --namespace - Gets the JVM memory for a particular replica rtfctl memory --pod --app-namespace --namespace ## `package` Creates a debugging information package for an application - Creates a package for an application using the first pod by default rtfctl package --app-namespace --namespace - Creates a package for an application containing the apps, policies, and `.mule` directories rtfctl package --apps --policies --dotmule --app-namespace --namespace - Creates a package for an application containing a heap dump rtfctl package --heap-dump --app-namespace --namespace ## `restart` Restarts an application rtfctl restart --app-namespace --namespace ## `heapdump` Triggers a JVM heap dump - Performs a JVM heap dump for an application, saving it as `` `/tmp/dump.hprof ``, using the first replica by default rtfctl heapdump --app-namespace --namespace - Performs a JVM heap dump for an application, saving it as `/tmp/dump.hprof`, using a specific replica rtfctl heapdump --pod --app-namespace --namespace ## `threaddump` Triggers a JVM threaddump - Performs a JVM thread dump for an application using the first replica by default rtfctl threaddump --app-namespace --namespace - Performs a JVM thread dump for an application using a specific replica rtfctl threaddump --pod --app-namespace --namespace ### See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl) --- product: Runtime Fabric version: 2.10 --- # Managing Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Mule apps deployed to Anypoint Runtime Fabric, review the following topics: - [Monitoring Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/manage-monitor-applications) Use Anypoint Monitoring to view metrics and logs of Mule apps deployed to Runtime Fabric. Additionally, you can export telemetry externally by using a Log4j appender to integrate your logging system to Mule apps deployed to Runtime Fabric. - [Managing Mule Apps Deployed to Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl#manage-rtfctl-apps) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`,and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Sending Application-to-Application Requests](https://docs.mulesoft.com/runtime-fabric/2.10/app-to-app-requests) Send a request from one Mule app to another app inside the cluster by using the Mule app name and environment ID. - [Reviewing Mule App Versioning](https://docs.mulesoft.com/runtime-fabric/2.10/app-versioning) Review deployed Mule app versioning to understand configuration changes history, roll back configurations, view Mule app statuses, and make updates to a deployed Mule app’s configuration. - [Managing Mule App Schedules](https://docs.mulesoft.com/runtime-fabric/2.10/manage-schedules) Use Runtime Manager to view and control the Scheduler components within the flows in your deployed Mule apps. - [Managing Mule Runtime Patch Updates](https://docs.mulesoft.com/runtime-fabric/2.10/runtime-patch-updates) Review the Mule runtime engine patch updates and the Mule release channels for Runtime Fabric. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-index) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.11 --- # Managing Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to manage Mule apps deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays details for an application

Displays disk usage for an application

Displays the JVM memory usage in a pod

Creates a debugging information package for an application

Restarts an application

Captures a JVM heap dump

Captures a JVM thread dump

## `delete` Deletes a secure property rtfctl delete secure-property -n ## `describe` Displays details for an application in a specific namespace rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ## `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ## `memory` Displays the JVM memory usage in a pod - Gets the JVM memory for each replica rtfctl memory --app-namespace --namespace - Gets the JVM memory for a particular replica rtfctl memory --pod --app-namespace --namespace ## `package` Creates a debugging information package for an application - Creates a package for an application using the first pod by default rtfctl package --app-namespace --namespace - Creates a package for an application containing the apps, policies, and `.mule` directories rtfctl package --apps --policies --dotmule --app-namespace --namespace - Creates a package for an application containing a heap dump rtfctl package --heap-dump --app-namespace --namespace ## `restart` Restarts an application rtfctl restart --app-namespace --namespace ## `heapdump` Triggers a JVM heap dump - Performs a JVM heap dump for an application, saving it as `` `/tmp/dump.hprof ``, using the first replica by default rtfctl heapdump --app-namespace --namespace - Performs a JVM heap dump for an application, saving it as `/tmp/dump.hprof`, using a specific replica rtfctl heapdump --pod --app-namespace --namespace ## `threaddump` Triggers a JVM threaddump - Performs a JVM thread dump for an application using the first replica by default rtfctl threaddump --app-namespace --namespace - Performs a JVM thread dump for an application using a specific replica rtfctl threaddump --pod --app-namespace --namespace ### See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl) --- product: Runtime Fabric version: 2.11 --- # Managing Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Mule apps deployed to Anypoint Runtime Fabric, review these topics: - [Monitoring Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/manage-monitor-applications) Use Anypoint Monitoring to view metrics and logs of Mule apps deployed to Runtime Fabric. Additionally, you can export telemetry externally by using a Log4j appender to integrate your logging system to Mule apps deployed to Runtime Fabric. - [Managing Mule Apps Deployed to Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.11/manage-apps-rtfctl) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`,and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Sending Application-to-Application Requests](https://docs.mulesoft.com/runtime-fabric/2.11/app-to-app-requests) Send a request from one Mule app to another app inside the cluster by using the Mule app name and environment ID. - [Reviewing Mule App Versioning](https://docs.mulesoft.com/runtime-fabric/2.11/app-versioning) Review deployed Mule app versioning to understand configuration changes history, roll back configurations, view Mule app statuses, and make updates to a deployed Mule app’s configuration. - [Managing Mule App Schedules](https://docs.mulesoft.com/runtime-fabric/2.11/manage-schedules) Use Runtime Manager to view and control the Scheduler components within the flows in your deployed Mule apps. - [Managing Mule Runtime Patch Updates](https://docs.mulesoft.com/runtime-fabric/2.11/runtime-patch-updates) Review the Mule runtime engine patch updates and the Mule release channels for Runtime Fabric. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-index) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.6 --- # Managing Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Mule apps deployed to Anypoint Runtime Fabric, review the following topics: - [Monitoring Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/manage-monitor-applications) Use Anypoint Monitoring to view metrics and logs of Mule apps deployed to Runtime Fabric. Additionally, you can export telemetry externally by using a Log4j appender to integrate your logging system to Mule apps deployed to Runtime Fabric. - [Managing Mule Apps Deployed to Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl#manage-rtfctl-apps) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`,and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Sending Application-to-Application Requests](https://docs.mulesoft.com/runtime-fabric/2.6/app-to-app-requests) Send a request from one Mule app to another app inside the cluster by using the Mule app name and environment ID. - [Reviewing Mule App Versioning](https://docs.mulesoft.com/runtime-fabric/2.6/app-versioning) Review deployed Mule app versioning to understand configuration changes history, roll back configurations, view Mule app statuses, and make updates to a deployed Mule app’s configuration. - [Managing Mule App Schedules](https://docs.mulesoft.com/runtime-fabric/2.6/manage-schedules) Use Runtime Manager to view and control the Scheduler components within the flows in your deployed Mule apps. - [Managing Mule Runtime Patch Updates](https://docs.mulesoft.com/runtime-fabric/2.6/runtime-patch-updates) Review the Mule runtime engine patch updates and the Mule release channels for Runtime Fabric. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-index) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.7 --- # Managing Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Mule apps deployed to Anypoint Runtime Fabric, review the following topics: - [Monitoring Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/manage-monitor-applications) Use Anypoint Monitoring to view metrics and logs of Mule apps deployed to Runtime Fabric. Additionally, you can export telemetry externally by using a Log4j appender to integrate your logging system to Mule apps deployed to Runtime Fabric. - [Managing Mule Apps Deployed to Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl#manage-rtfctl-apps) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`,and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Sending Application-to-Application Requests](https://docs.mulesoft.com/runtime-fabric/2.7/app-to-app-requests) Send a request from one Mule app to another app inside the cluster by using the Mule app name and environment ID. - [Reviewing Mule App Versioning](https://docs.mulesoft.com/runtime-fabric/2.7/app-versioning) Review deployed Mule app versioning to understand configuration changes history, roll back configurations, view Mule app statuses, and make updates to a deployed Mule app’s configuration. - [Managing Mule App Schedules](https://docs.mulesoft.com/runtime-fabric/2.7/manage-schedules) Use Runtime Manager to view and control the Scheduler components within the flows in your deployed Mule apps. - [Managing Mule Runtime Patch Updates](https://docs.mulesoft.com/runtime-fabric/2.7/runtime-patch-updates) Review the Mule runtime engine patch updates and the Mule release channels for Runtime Fabric. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-index) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.8 --- # Managing Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Mule apps deployed to Anypoint Runtime Fabric, review the following topics: - [Monitoring Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-monitor-applications) Use Anypoint Monitoring to view metrics and logs of Mule apps deployed to Runtime Fabric. Additionally, you can export telemetry externally by using a Log4j appender to integrate your logging system to Mule apps deployed to Runtime Fabric. - [Managing Mule Apps Deployed to Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl#manage-rtfctl-apps) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`,and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Sending Application-to-Application Requests](https://docs.mulesoft.com/runtime-fabric/2.8/app-to-app-requests) Send a request from one Mule app to another app inside the cluster by using the Mule app name and environment ID. - [Reviewing Mule App Versioning](https://docs.mulesoft.com/runtime-fabric/2.8/app-versioning) Review deployed Mule app versioning to understand configuration changes history, roll back configurations, view Mule app statuses, and make updates to a deployed Mule app’s configuration. - [Managing Mule App Schedules](https://docs.mulesoft.com/runtime-fabric/2.8/manage-schedules) Use Runtime Manager to view and control the Scheduler components within the flows in your deployed Mule apps. - [Managing Mule Runtime Patch Updates](https://docs.mulesoft.com/runtime-fabric/2.8/runtime-patch-updates) Review the Mule runtime engine patch updates and the Mule release channels for Runtime Fabric. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-index) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.9 --- # Managing Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to manage Mule apps deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays details for an application

Displays disk usage for an application

Displays the JVM memory usage in a pod

Creates a debugging information package for an application

Restarts an application

Captures a JVM heap dump

Captures a JVM thread dump

## `delete` Deletes a secure property rtfctl delete secure-property -n ## `describe` Displays details for an application in a specific namespace rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ## `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ## `memory` Displays the JVM memory usage in a pod - Gets the JVM memory for each replica rtfctl memory --app-namespace --namespace - Gets the JVM memory for a particular replica rtfctl memory --pod --app-namespace --namespace ## `package` Creates a debugging information package for an application - Creates a package for an application using the first pod by default rtfctl package --app-namespace --namespace - Creates a package for an application containing the apps, policies, and `.mule` directories rtfctl package --apps --policies --dotmule --app-namespace --namespace - Creates a package for an application containing a heap dump rtfctl package --heap-dump --app-namespace --namespace ## `restart` Restarts an application rtfctl restart --app-namespace --namespace ## `heapdump` Triggers a JVM heap dump - Performs a JVM heap dump for an application, saving it as `` `/tmp/dump.hprof ``, using the first replica by default rtfctl heapdump --app-namespace --namespace - Performs a JVM heap dump for an application, saving it as `/tmp/dump.hprof`, using a specific replica rtfctl heapdump --pod --app-namespace --namespace ## `threaddump` Triggers a JVM threaddump - Performs a JVM thread dump for an application using the first replica by default rtfctl threaddump --app-namespace --namespace - Performs a JVM thread dump for an application using a specific replica rtfctl threaddump --pod --app-namespace --namespace ### See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl) --- product: Runtime Fabric version: 2.9 --- # Managing Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Mule apps deployed to Anypoint Runtime Fabric, review the following topics: - [Monitoring Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/manage-monitor-applications) Use Anypoint Monitoring to view metrics and logs of Mule apps deployed to Runtime Fabric. Additionally, you can export telemetry externally by using a Log4j appender to integrate your logging system to Mule apps deployed to Runtime Fabric. - [Managing Mule Apps Deployed to Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl#manage-rtfctl-apps) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`,and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Sending Application-to-Application Requests](https://docs.mulesoft.com/runtime-fabric/2.9/app-to-app-requests) Send a request from one Mule app to another app inside the cluster by using the Mule app name and environment ID. - [Reviewing Mule App Versioning](https://docs.mulesoft.com/runtime-fabric/2.9/app-versioning) Review deployed Mule app versioning to understand configuration changes history, roll back configurations, view Mule app statuses, and make updates to a deployed Mule app’s configuration. - [Managing Mule App Schedules](https://docs.mulesoft.com/runtime-fabric/2.9/manage-schedules) Use Runtime Manager to view and control the Scheduler components within the flows in your deployed Mule apps. - [Managing Mule Runtime Patch Updates](https://docs.mulesoft.com/runtime-fabric/2.9/runtime-patch-updates) Review the Mule runtime engine patch updates and the Mule release channels for Runtime Fabric. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-index) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Managing Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to manage Mule apps deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays details for an application

Displays disk usage for an application

Displays the JVM memory usage in a pod

Creates a debugging information package for an application

Restarts an application

Captures a JVM heap dump

Captures a JVM thread dump

## `delete` Deletes a secure property rtfctl delete secure-property -n ## `describe` Displays details for an application in a specific namespace rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ## `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ## `memory` Displays the JVM memory usage in a pod - Gets the JVM memory for each replica rtfctl memory --app-namespace --namespace - Gets the JVM memory for a particular replica rtfctl memory --pod --app-namespace --namespace ## `package` Creates a debugging information package for an application - Creates a package for an application using the first pod by default rtfctl package --app-namespace --namespace - Creates a package for an application containing the apps, policies, and `.mule` directories rtfctl package --apps --policies --dotmule --app-namespace --namespace - Creates a package for an application containing a heap dump rtfctl package --heap-dump --app-namespace --namespace ## `restart` Restarts an application rtfctl restart --app-namespace --namespace ## `heapdump` Triggers a JVM heap dump - Performs a JVM heap dump for an application, saving it as `` `/tmp/dump.hprof ``, using the first replica by default rtfctl heapdump --app-namespace --namespace - Performs a JVM heap dump for an application, saving it as `/tmp/dump.hprof`, using a specific replica rtfctl heapdump --pod --app-namespace --namespace ## `threaddump` Triggers a JVM threaddump - Performs a JVM thread dump for an application using the first replica by default rtfctl threaddump --app-namespace --namespace - Performs a JVM thread dump for an application using a specific replica rtfctl threaddump --pod --app-namespace --namespace ### See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Managing Mule Apps Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Mule apps deployed to Anypoint Runtime Fabric, review the following topics: - [Monitoring Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/manage-monitor-applications) Use Anypoint Monitoring to view metrics and logs of Mule apps deployed to Runtime Fabric. Additionally, you can export telemetry externally by using a Log4j appender to integrate your logging system to Mule apps deployed to Runtime Fabric. - [Managing Mule Apps Deployed to Runtime Fabric Using RTFCTL](https://docs.mulesoft.com/runtime-fabric/latest/manage-apps-rtfctl) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`,and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Sending Application-to-Application Requests](https://docs.mulesoft.com/runtime-fabric/latest/app-to-app-requests) Send a request from one Mule app to another app inside the cluster by using the Mule app name and environment ID. - [Reviewing Mule App Versioning](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) Review deployed Mule app versioning to understand configuration changes history, roll back configurations, view Mule app statuses, and make updates to a deployed Mule app’s configuration. - [Managing Mule App Schedules](https://docs.mulesoft.com/runtime-fabric/latest/manage-schedules) Use Runtime Manager to view and control the Scheduler components within the flows in your deployed Mule apps. - [Managing Mule Runtime Patch Updates](https://docs.mulesoft.com/runtime-fabric/latest/runtime-patch-updates) Review the Mule runtime engine patch updates and the Mule release channels for Runtime Fabric. - [Restarting Mule Applications on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/restart-applications) Use Anypoint Runtime Manager to restart Mule applications deployed to Runtime Fabric without redeploying them. ## See Also - [Deploying Mule Apps to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-index) - [Hardening Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/hardening-apps-deployed-runtime-fabric) --- product: Runtime Fabric version: 2.10 --- # Managing Mule Apps Deployed to Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to manage Mule apps deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays details for an application

Displays disk usage for an application

Displays the JVM memory usage in a pod

Creates a debugging information package for an application

Restarts an application

Captures a JVM heap dump

Captures a JVM thread dump

## `delete` Deletes a secure property rtfctl delete secure-property -n ## `describe` Displays details for an application in a specific namespace rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ## `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ## `memory` Displays the JVM memory usage in a pod - Gets the JVM memory for each replica rtfctl memory --app-namespace --namespace - Gets the JVM memory for a particular replica rtfctl memory --pod --app-namespace --namespace ## `package` Creates a debugging information package for an application - Creates a package for an application using the first pod by default rtfctl package --app-namespace --namespace - Creates a package for an application containing the apps, policies, and `.mule` directories rtfctl package --apps --policies --dotmule --app-namespace --namespace - Creates a package for an application containing a heap dump rtfctl package --heap-dump --app-namespace --namespace ## `restart` Restarts an application rtfctl restart --app-namespace --namespace ## `heapdump` Triggers a JVM heap dump - Performs a JVM heap dump for an application, saving it as `` `/tmp/dump.hprof ``, using the first replica by default rtfctl heapdump --app-namespace --namespace - Performs a JVM heap dump for an application, saving it as `/tmp/dump.hprof`, using a specific replica rtfctl heapdump --pod --app-namespace --namespace ## `threaddump` Triggers a JVM threaddump - Performs a JVM thread dump for an application using the first replica by default rtfctl threaddump --app-namespace --namespace - Performs a JVM thread dump for an application using a specific replica rtfctl threaddump --pod --app-namespace --namespace ### See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl) --- product: Runtime Fabric version: 2.11 --- # Managing Mule Apps Deployed to Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to manage Mule apps deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays details for an application

Displays disk usage for an application

Displays the JVM memory usage in a pod

Creates a debugging information package for an application

Restarts an application

Captures a JVM heap dump

Captures a JVM thread dump

## `delete` Deletes a secure property rtfctl delete secure-property -n ## `describe` Displays details for an application in a specific namespace rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ## `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ## `memory` Displays the JVM memory usage in a pod - Gets the JVM memory for each replica rtfctl memory --app-namespace --namespace - Gets the JVM memory for a particular replica rtfctl memory --pod --app-namespace --namespace ## `package` Creates a debugging information package for an application - Creates a package for an application using the first pod by default rtfctl package --app-namespace --namespace - Creates a package for an application containing the apps, policies, and `.mule` directories rtfctl package --apps --policies --dotmule --app-namespace --namespace - Creates a package for an application containing a heap dump rtfctl package --heap-dump --app-namespace --namespace ## `restart` Restarts an application rtfctl restart --app-namespace --namespace ## `heapdump` Triggers a JVM heap dump - Performs a JVM heap dump for an application, saving it as `` `/tmp/dump.hprof ``, using the first replica by default rtfctl heapdump --app-namespace --namespace - Performs a JVM heap dump for an application, saving it as `/tmp/dump.hprof`, using a specific replica rtfctl heapdump --pod --app-namespace --namespace ## `threaddump` Triggers a JVM threaddump - Performs a JVM thread dump for an application using the first replica by default rtfctl threaddump --app-namespace --namespace - Performs a JVM thread dump for an application using a specific replica rtfctl threaddump --pod --app-namespace --namespace ### See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl) --- product: Runtime Fabric version: 2.9 --- # Managing Mule Apps Deployed to Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to manage Mule apps deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays details for an application

Displays disk usage for an application

Displays the JVM memory usage in a pod

Creates a debugging information package for an application

Restarts an application

Captures a JVM heap dump

Captures a JVM thread dump

## `delete` Deletes a secure property rtfctl delete secure-property -n ## `describe` Displays details for an application in a specific namespace rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ## `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ## `memory` Displays the JVM memory usage in a pod - Gets the JVM memory for each replica rtfctl memory --app-namespace --namespace - Gets the JVM memory for a particular replica rtfctl memory --pod --app-namespace --namespace ## `package` Creates a debugging information package for an application - Creates a package for an application using the first pod by default rtfctl package --app-namespace --namespace - Creates a package for an application containing the apps, policies, and `.mule` directories rtfctl package --apps --policies --dotmule --app-namespace --namespace - Creates a package for an application containing a heap dump rtfctl package --heap-dump --app-namespace --namespace ## `restart` Restarts an application rtfctl restart --app-namespace --namespace ## `heapdump` Triggers a JVM heap dump - Performs a JVM heap dump for an application, saving it as `` `/tmp/dump.hprof ``, using the first replica by default rtfctl heapdump --app-namespace --namespace - Performs a JVM heap dump for an application, saving it as `/tmp/dump.hprof`, using a specific replica rtfctl heapdump --pod --app-namespace --namespace ## `threaddump` Triggers a JVM threaddump - Performs a JVM thread dump for an application using the first replica by default rtfctl threaddump --app-namespace --namespace - Performs a JVM thread dump for an application using a specific replica rtfctl threaddump --pod --app-namespace --namespace ### See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Managing Mule Apps Deployed to Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to manage Mule apps deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays details for an application

Displays disk usage for an application

Displays the JVM memory usage in a pod

Creates a debugging information package for an application

Restarts an application

Captures a JVM heap dump

Captures a JVM thread dump

## `delete` Deletes a secure property rtfctl delete secure-property -n ## `describe` Displays details for an application in a specific namespace rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ## `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ## `memory` Displays the JVM memory usage in a pod - Gets the JVM memory for each replica rtfctl memory --app-namespace --namespace - Gets the JVM memory for a particular replica rtfctl memory --pod --app-namespace --namespace ## `package` Creates a debugging information package for an application - Creates a package for an application using the first pod by default rtfctl package --app-namespace --namespace - Creates a package for an application containing the apps, policies, and `.mule` directories rtfctl package --apps --policies --dotmule --app-namespace --namespace - Creates a package for an application containing a heap dump rtfctl package --heap-dump --app-namespace --namespace ## `restart` Restarts an application rtfctl restart --app-namespace --namespace ## `heapdump` Triggers a JVM heap dump - Performs a JVM heap dump for an application, saving it as `` `/tmp/dump.hprof ``, using the first replica by default rtfctl heapdump --app-namespace --namespace - Performs a JVM heap dump for an application, saving it as `/tmp/dump.hprof`, using a specific replica rtfctl heapdump --pod --app-namespace --namespace ## `threaddump` Triggers a JVM threaddump - Performs a JVM thread dump for an application using the first replica by default rtfctl threaddump --app-namespace --namespace - Performs a JVM thread dump for an application using a specific replica rtfctl threaddump --pod --app-namespace --namespace ### See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl) --- product: Runtime Fabric version: 2.10 --- # Managing Mule Apps Schedules > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view and control the Scheduler components within the flows in your deployed applications, all without changing the running application. For example, you might want to disable a scheduled job while one of the applications is undergoing maintenance. On the **Schedules** tab, you can: - View the schedules in your running application. - Change the schedules in your application. - Run the scheduled job immediately, without changing the schedule. - Disable or enable the schedule for a flow. You configure Scheduler component types as either _fixed frequency_ to trigger at a regular interval or _cron_ to trigger at a date and time based on a specified cron expression. > [!IMPORTANT] To change a schedule type (between fixed frequency and cron or vice versa), you must > update and redeploy the app. You can’t change the schedule type on a deployed application. > [!NOTE] The minimum required Mule runtime engine version to use this feature is 4.1.2 or later, > and the minimum Runtime Fabric Agent version is 2.0.0 or later. ## Schedule Design Considerations When designing the schedule, consider the following: - The Runtime Fabric scheduler reads the job configuration every time it runs. When you update the scheduler configuration, the change takes effect the next time the scheduler runs. - Changing the schedule redeploys your application. - If a scheduled job is not triggered because the application is not running, Runtime Fabric triggers the job as soon as the app restarts. - Schedules are based in the scheduler’s defined timezone. - For multi-replica apps, Runtime Fabric runs scheduled jobs on all replicas. If you run the scheduled job immediately by clicking **Run**, the scheduler runs on a single replica. Runtime Fabric distributes multiple concurrent schedulers across replicas. - You cannot manage Runtime Fabric schedules using scripts. Use the **Schedules** tab or the Runtime Fabric API to manage Runtime Fabric schedules. - Flow names can contain only upper and lower case latters, numbers, hyphens (`-`), underscores (`_`), and periods (`.`). The following characters are invalid: `/`, `[`, `]`, `{`, `}`, and `#`. - When you create a schedule using a scheduler that has a placeholder, the value that appears when you create a schedule varies based on when the placeholder is discovered. For example: - If the value is available before the app is deployed, the value appears. - If the value is available before deployment and depends on deployment properties, an estimation of the value appears. - If the value is a placeholder (such as `${cronExpression}`) that is provided at the time of deployment, the exact value of the placeholder does not appear in the user interface. - Runtime Fabric uses a default value of `60000`. ## Before You Begin To use the scheduling feature in Runtime Manager, deploy an application that includes one or more Scheduler elements using Anypoint Studio 7.13 or later. ![Scheduler component in the Anypoint Studio canvas](/mulesoft/current/en-us/runtime-fabric/2.10/_images/ch2-scheduler-studio.png) After you deploy the app, you can manage the schedule in Runtime Manager. The app doesn’t need to be running. Use Mule Maven facade v3 when you deploy through Maven to Runtime Fabric for the schedules to show in the Runtime Manager UI. ## View and Manage Application Schedules in Runtime Manager After deploying an app to Runtime Fabric, view and manage the Scheduler elements in Runtime Manager: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. Runtime Manager lists the Scheduler elements in the order they appear in your app: ![(1) Flow name and (2) the frequency link on the Schedulers page.](/mulesoft/current/en-us/runtime-fabric/2.10/_images/ch2-scheduler-rtm.png) - The **Name** column shows the name of the flow (1) that contains the Scheduler element. - The frequency link (2) in the **Schedule** column shows the schedule for the element. 4. If you want to see more information about when the jobs started and ended, click **Logs** in the navigation menu: ![Logs option in the navigation menu.](/mulesoft/current/en-us/runtime-fabric/2.10/_images/ch2-logs-rtm.png) 5. Click the frequency link for an element to open the schedule editor. The schedule editor you see depends on the schedule type: - [Fixed frequency](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Fixed Frequency Schedule 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![Fixed frequency schedule type](/mulesoft/current/en-us/runtime-fabric/2.10/_images/ch2-scheduler-fixed-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule: ![Fixed-frequency schedule configuration](/mulesoft/current/en-us/runtime-fabric/2.10/_images/ch2-scheduler-editor-fixed.png) You can specify milliseconds, seconds, minutes, hours, or days for the frequency. The minimum recommended frequency between calls is 10 seconds. > [!NOTE] By default, schedules run at the frequency defined in the application. When you change > the frequency of a schedule from Runtime Manager, the schedule runs at the frequency > configured in Runtime Manager even if you update and redeploy the same schedule in the > application JAR file. 6. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Cron Schedule With cron expressions, you can create more complex schedule frequencies, such as every 5 minutes between 9:00 am and 10:00 am on Fridays. To change the frequency of a cron schedule type: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![cron schedule type](/mulesoft/current/en-us/runtime-fabric/2.10/_images/ch2-scheduler-cron-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** (1) to disable the schedule: ![cron schedule configuration with (1) Enabled option and (2) Quick Reference link](/mulesoft/current/en-us/runtime-fabric/2.10/_images/ch2-scheduler-editor-cron.png) 6. In the schedule editor, click **Quick Reference** (2) to expand or collapse the table that lists required fields and allowed values. The cron expression in this example sets the schedule to every 10 seconds. For information about building cron triggers: 1. View the [Quartz documentation](https://www.quartz-scheduler.org/documentation/). 2. Select a version, click **Documentation > User’s Guide > Tutorial**, and then click the **CronTrigger** lesson. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ## Run a Scheduled Job Immediately If a job runs nightly but you want to debug it now, you can trigger the job while it’s running without updating the schedule in your application. When you trigger the job in between instances of the scheduler running, the timer for the indicated time period resets. > [!NOTE] If you run the scheduled job immediately, the scheduler runs on a single replica even for > multi-replica apps. To override the schedule and run the job immediately: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Run**. ## Disable or Enable a Scheduler Element You might want to disable a scheduled job if an application you are connecting to is undergoing maintenance and then reenable it after maintenance is complete. Runtime Fabric does not run the scheduled job until you reenable the Scheduler. **Known issue**: If you disable the scheduler, it still runs when starting an application. If you want to prevent the scheduler from running, set the `startdelay` property to five seconds in your app using Anypoint Studio. To disable the Scheduler element: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Disable**. You can also disable or enable the schedule by deselecting or selecting **Enabled** in the schedule editor. ![Enabled toggle in the schedule editor](/mulesoft/current/en-us/runtime-fabric/2.10/_images/ch2-scheduler-enable.png) ## See Also - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz documentation](https://www.quartz-scheduler.org/documentation/) - [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) --- product: Runtime Fabric version: 2.11 --- # Managing Mule Apps Schedules > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view and control the Scheduler components within the flows in your deployed applications, all without changing the running application. For example, you might want to disable a scheduled job while one of the applications is undergoing maintenance. On the **Schedules** tab, you can: - View the schedules in your running application. - Change the schedules in your application. - Run the scheduled job immediately, without changing the schedule. - Disable or enable the schedule for a flow. You configure Scheduler component types as either _fixed frequency_ to trigger at a regular interval or _cron_ to trigger at a date and time based on a specified cron expression. > [!IMPORTANT] To change a schedule type (between fixed frequency and cron or vice versa), you must > update and redeploy the app. You can’t change the schedule type on a deployed application. > [!NOTE] The minimum required Mule runtime engine version to use this feature is 4.1.2 or later, > and the minimum Runtime Fabric Agent version is 2.0.0 or later. ## Schedule Design Considerations When designing the schedule, consider this: - The Runtime Fabric scheduler reads the job configuration every time it runs. When you update the scheduler configuration, the change takes effect the next time the scheduler runs. - Changing the schedule redeploys your application. - If a scheduled job is not triggered because the application is not running, Runtime Fabric triggers the job as soon as the app restarts. - Schedules are based in the scheduler’s defined timezone. - For multi-replica apps, Runtime Fabric runs scheduled jobs on all replicas. If you run the scheduled job immediately by clicking **Run**, the scheduler runs on a single replica. Runtime Fabric distributes multiple concurrent schedulers across replicas. - You cannot manage Runtime Fabric schedules using scripts. Use the **Schedules** tab or the Runtime Fabric API to manage Runtime Fabric schedules. - Flow names can contain only upper and lower case latters, numbers, hyphens (`-`), underscores (`_`), and periods (`.`). The following characters are invalid: `/`, `[`, `]`, `{`, `}`, and `#`. - When you create a schedule using a scheduler that has a placeholder, the value that appears when you create a schedule varies based on when the placeholder is discovered. For example: - If the value is available before the app is deployed, the value appears. - If the value is available before deployment and depends on deployment properties, an estimation of the value appears. - If the value is a placeholder (such as `${cronExpression}`) that is provided at the time of deployment, the exact value of the placeholder does not appear in the user interface. - Runtime Fabric uses a default value of `60000`. ## Before You Begin To use the scheduling feature in Runtime Manager, deploy an application that includes one or more Scheduler elements using Anypoint Studio 7.13 or later. ![Scheduler component in the Anypoint Studio canvas](/mulesoft/current/en-us/runtime-fabric/2.11/_images/ch2-scheduler-studio.png) After you deploy the app, you can manage the schedule in Runtime Manager. The app doesn’t need to be running. Use Mule Maven facade v3 when you deploy through Maven to Runtime Fabric for the schedules to show in the Runtime Manager UI. ## View and Manage Application Schedules in Runtime Manager After deploying an app to Runtime Fabric, view and manage the Scheduler elements in Runtime Manager: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. Runtime Manager lists the Scheduler elements in the order they appear in your app: ![(1) Flow name and (2) the frequency link on the Schedulers page.](/mulesoft/current/en-us/runtime-fabric/2.11/_images/ch2-scheduler-rtm.png) - The **Name** column shows the name of the flow (1) that contains the Scheduler element. - The frequency link (2) in the **Schedule** column shows the schedule for the element. 4. If you want to see more information about when the jobs started and ended, click **Logs** in the navigation menu: ![Logs option in the navigation menu.](/mulesoft/current/en-us/runtime-fabric/2.11/_images/ch2-logs-rtm.png) 5. Click the frequency link for an element to open the schedule editor. The schedule editor you see depends on the schedule type: - [Fixed frequency](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Fixed Frequency Schedule 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![Fixed frequency schedule type](/mulesoft/current/en-us/runtime-fabric/2.11/_images/ch2-scheduler-fixed-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule: ![Fixed-frequency schedule configuration](/mulesoft/current/en-us/runtime-fabric/2.11/_images/ch2-scheduler-editor-fixed.png) You can specify milliseconds, seconds, minutes, hours, or days for the frequency. The minimum recommended frequency between calls is 10 seconds. > [!NOTE] By default, schedules run at the frequency defined in the application. When you change > the frequency of a schedule from Runtime Manager, the schedule runs at the frequency > configured in Runtime Manager even if you update and redeploy the same schedule in the > application JAR file. 6. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Cron Schedule With cron expressions, you can create more complex schedule frequencies, such as every 5 minutes between 9:00 am and 10:00 am on Fridays. To change the frequency of a cron schedule type: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![cron schedule type](/mulesoft/current/en-us/runtime-fabric/2.11/_images/ch2-scheduler-cron-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** (1) to disable the schedule: ![cron schedule configuration with (1) Enabled option and (2) Quick Reference link](/mulesoft/current/en-us/runtime-fabric/2.11/_images/ch2-scheduler-editor-cron.png) 6. In the schedule editor, click **Quick Reference** (2) to expand or collapse the table that lists required fields and allowed values. The cron expression in this example sets the schedule to every 10 seconds. For information about building cron triggers: 1. View the [Quartz documentation](https://www.quartz-scheduler.org/documentation/). 2. Select a version, click **Documentation > User’s Guide > Tutorial**, and then click the **CronTrigger** lesson. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ## Run a Scheduled Job Immediately If a job runs nightly but you want to debug it now, you can trigger the job while it’s running without updating the schedule in your application. When you trigger the job in between instances of the scheduler running, the timer for the indicated time period resets. > [!NOTE] If you run the scheduled job immediately, the scheduler runs on a single replica even for > multi-replica apps. To override the schedule and run the job immediately: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Run**. ## Disable or Enable a Scheduler Element You might want to disable a scheduled job if an application you are connecting to is undergoing maintenance and then reenable it after maintenance is complete. Runtime Fabric does not run the scheduled job until you reenable the Scheduler. **Known issue**: If you disable the scheduler, it still runs when starting an application. If you want to prevent the scheduler from running, set the `startdelay` property to five seconds in your app using Anypoint Studio. To disable the Scheduler element: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Disable**. You can also disable or enable the schedule by deselecting or selecting **Enabled** in the schedule editor. ![Enabled toggle in the schedule editor](/mulesoft/current/en-us/runtime-fabric/2.11/_images/ch2-scheduler-enable.png) ## See Also - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz documentation](https://www.quartz-scheduler.org/documentation/) - [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) --- product: Runtime Fabric version: 2.6 --- # Managing Mule Apps Schedules > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view and control the Scheduler components within the flows in your deployed applications, all without changing the running application. For example, you might want to disable a scheduled job while one of the applications is undergoing maintenance. On the **Schedules** tab, you can: - View the schedules in your running application. - Change the schedules in your application. - Run the scheduled job immediately, without changing the schedule. - Disable or enable the schedule for a flow. You configure Scheduler component types as either _fixed frequency_ to trigger at a regular interval or _cron_ to trigger at a date and time based on a specified cron expression. > [!IMPORTANT] To change a schedule type (between fixed frequency and cron or vice versa), you must > update and redeploy the app. You can’t change the schedule type on a deployed application. > [!NOTE] The minimum required Mule runtime engine version to use this feature is 4.1.2 or later, > and the minimum Runtime Fabric Agent version is 2.0.0 or later. ## Schedule Design Considerations When designing the schedule, consider the following: - The Runtime Fabric scheduler reads the job configuration every time it runs. When you update the scheduler configuration, the change takes effect the next time the scheduler runs. - Changing the schedule redeploys your application. - If a scheduled job is not triggered because the application is not running, Runtime Fabric triggers the job as soon as the app restarts. - Schedules are based in the scheduler’s defined timezone. - For multi-replica apps, Runtime Fabric runs scheduled jobs on all replicas. If you run the scheduled job immediately by clicking **Run**, the scheduler runs on a single replica. Runtime Fabric distributes multiple concurrent schedulers across replicas. - You cannot manage Runtime Fabric schedules using scripts. Use the **Schedules** tab or the Runtime Fabric API to manage Runtime Fabric schedules. - Flow names can contain only upper and lower case latters, numbers, hyphens (`-`), underscores (`_`), and periods (`.`). The following characters are invalid: `/`, `[`, `]`, `{`, `}`, and `#`. - When you create a schedule using a scheduler that has a placeholder, the value that appears when you create a schedule varies based on when the placeholder is discovered. For example: - If the value is available before the app is deployed, the value appears. - If the value is available before deployment and depends on deployment properties, an estimation of the value appears. - If the value is a placeholder (such as `${cronExpression}`) that is provided at the time of deployment, the exact value of the placeholder does not appear in the user interface. - Runtime Fabric uses a default value of `60000`. ## Before You Begin To use the scheduling feature in Runtime Manager, deploy an application that includes one or more Scheduler elements using Anypoint Studio 7.13 or later. ![Scheduler component in the Anypoint Studio canvas](/mulesoft/current/en-us/runtime-fabric/2.6/_images/ch2-scheduler-studio.png) After you deploy the app, you can manage the schedule in Runtime Manager. The app doesn’t need to be running. Use Mule Maven facade v3 when you deploy through Maven to Runtime Fabric for the schedules to show in the Runtime Manager UI. ## View and Manage Application Schedules in Runtime Manager After deploying an app to Runtime Fabric, view and manage the Scheduler elements in Runtime Manager: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. Runtime Manager lists the Scheduler elements in the order they appear in your app: ![(1) Flow name and (2) the frequency link on the Schedulers page.](/mulesoft/current/en-us/runtime-fabric/2.6/_images/ch2-scheduler-rtm.png) - The **Name** column shows the name of the flow (1) that contains the Scheduler element. - The frequency link (2) in the **Schedule** column shows the schedule for the element. 4. If you want to see more information about when the jobs started and ended, click **Logs** in the navigation menu: ![Logs option in the navigation menu.](/mulesoft/current/en-us/runtime-fabric/2.6/_images/ch2-logs-rtm.png) 5. Click the frequency link for an element to open the schedule editor. The schedule editor you see depends on the schedule type: - [Fixed frequency](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Fixed Frequency Schedule 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![Fixed frequency schedule type](/mulesoft/current/en-us/runtime-fabric/2.6/_images/ch2-scheduler-fixed-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule: ![Fixed-frequency schedule configuration](/mulesoft/current/en-us/runtime-fabric/2.6/_images/ch2-scheduler-editor-fixed.png) You can specify milliseconds, seconds, minutes, hours, or days for the frequency. The minimum recommended frequency between calls is 10 seconds. > [!NOTE] By default, schedules run at the frequency defined in the application. When you change > the frequency of a schedule from Runtime Manager, the schedule runs at the frequency > configured in Runtime Manager even if you update and redeploy the same schedule in the > application JAR file. 6. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Cron Schedule With cron expressions, you can create more complex schedule frequencies, such as every 5 minutes between 9:00 am and 10:00 am on Fridays. To change the frequency of a cron schedule type: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![cron schedule type](/mulesoft/current/en-us/runtime-fabric/2.6/_images/ch2-scheduler-cron-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** (1) to disable the schedule: ![cron schedule configuration with (1) Enabled option and (2) Quick Reference link](/mulesoft/current/en-us/runtime-fabric/2.6/_images/ch2-scheduler-editor-cron.png) 6. In the schedule editor, click **Quick Reference** (2) to expand or collapse the table that lists required fields and allowed values. The cron expression in this example sets the schedule to every 10 seconds. For information about building cron triggers: 1. View the [Quartz documentation](https://www.quartz-scheduler.org/documentation/). 2. Select a version, click **Documentation > User’s Guide > Tutorial**, and then click the **CronTrigger** lesson. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ## Run a Scheduled Job Immediately If a job runs nightly but you want to debug it now, you can trigger the job while it’s running without updating the schedule in your application. When you trigger the job in between instances of the scheduler running, the timer for the indicated time period resets. > [!NOTE] If you run the scheduled job immediately, the scheduler runs on a single replica even for > multi-replica apps. To override the schedule and run the job immediately: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Run**. ## Disable or Enable a Scheduler Element You might want to disable a scheduled job if an application you are connecting to is undergoing maintenance and then reenable it after maintenance is complete. Runtime Fabric does not run the scheduled job until you reenable the Scheduler. **Known issue**: If you disable the scheduler, it still runs when starting an application. If you want to prevent the scheduler from running, set the `startdelay` property to five seconds in your app using Anypoint Studio. To disable the Scheduler element: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Disable**. You can also disable or enable the schedule by deselecting or selecting **Enabled** in the schedule editor. ![Enabled toggle in the schedule editor](/mulesoft/current/en-us/runtime-fabric/2.6/_images/ch2-scheduler-enable.png) ## See Also - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz documentation](https://www.quartz-scheduler.org/documentation/) - [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) --- product: Runtime Fabric version: 2.7 --- # Managing Mule Apps Schedules > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view and control the Scheduler components within the flows in your deployed applications, all without changing the running application. For example, you might want to disable a scheduled job while one of the applications is undergoing maintenance. On the **Schedules** tab, you can: - View the schedules in your running application. - Change the schedules in your application. - Run the scheduled job immediately, without changing the schedule. - Disable or enable the schedule for a flow. You configure Scheduler component types as either _fixed frequency_ to trigger at a regular interval or _cron_ to trigger at a date and time based on a specified cron expression. > [!IMPORTANT] To change a schedule type (between fixed frequency and cron or vice versa), you must > update and redeploy the app. You can’t change the schedule type on a deployed application. > [!NOTE] The minimum required Mule runtime engine version to use this feature is 4.1.2 or later, > and the minimum Runtime Fabric Agent version is 2.0.0 or later. ## Schedule Design Considerations When designing the schedule, consider the following: - The Runtime Fabric scheduler reads the job configuration every time it runs. When you update the scheduler configuration, the change takes effect the next time the scheduler runs. - Changing the schedule redeploys your application. - If a scheduled job is not triggered because the application is not running, Runtime Fabric triggers the job as soon as the app restarts. - Schedules are based in the scheduler’s defined timezone. - For multi-replica apps, Runtime Fabric runs scheduled jobs on all replicas. If you run the scheduled job immediately by clicking **Run**, the scheduler runs on a single replica. Runtime Fabric distributes multiple concurrent schedulers across replicas. - You cannot manage Runtime Fabric schedules using scripts. Use the **Schedules** tab or the Runtime Fabric API to manage Runtime Fabric schedules. - Flow names can contain only upper and lower case latters, numbers, hyphens (`-`), underscores (`_`), and periods (`.`). The following characters are invalid: `/`, `[`, `]`, `{`, `}`, and `#`. - When you create a schedule using a scheduler that has a placeholder, the value that appears when you create a schedule varies based on when the placeholder is discovered. For example: - If the value is available before the app is deployed, the value appears. - If the value is available before deployment and depends on deployment properties, an estimation of the value appears. - If the value is a placeholder (such as `${cronExpression}`) that is provided at the time of deployment, the exact value of the placeholder does not appear in the user interface. - Runtime Fabric uses a default value of `60000`. ## Before You Begin To use the scheduling feature in Runtime Manager, deploy an application that includes one or more Scheduler elements using Anypoint Studio 7.13 or later. ![Scheduler component in the Anypoint Studio canvas](/mulesoft/current/en-us/runtime-fabric/2.7/_images/ch2-scheduler-studio.png) After you deploy the app, you can manage the schedule in Runtime Manager. The app doesn’t need to be running. Use Mule Maven facade v3 when you deploy through Maven to Runtime Fabric for the schedules to show in the Runtime Manager UI. ## View and Manage Application Schedules in Runtime Manager After deploying an app to Runtime Fabric, view and manage the Scheduler elements in Runtime Manager: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. Runtime Manager lists the Scheduler elements in the order they appear in your app: ![(1) Flow name and (2) the frequency link on the Schedulers page.](/mulesoft/current/en-us/runtime-fabric/2.7/_images/ch2-scheduler-rtm.png) - The **Name** column shows the name of the flow (1) that contains the Scheduler element. - The frequency link (2) in the **Schedule** column shows the schedule for the element. 4. If you want to see more information about when the jobs started and ended, click **Logs** in the navigation menu: ![Logs option in the navigation menu.](/mulesoft/current/en-us/runtime-fabric/2.7/_images/ch2-logs-rtm.png) 5. Click the frequency link for an element to open the schedule editor. The schedule editor you see depends on the schedule type: - [Fixed frequency](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Fixed Frequency Schedule 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![Fixed frequency schedule type](/mulesoft/current/en-us/runtime-fabric/2.7/_images/ch2-scheduler-fixed-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule: ![Fixed-frequency schedule configuration](/mulesoft/current/en-us/runtime-fabric/2.7/_images/ch2-scheduler-editor-fixed.png) You can specify milliseconds, seconds, minutes, hours, or days for the frequency. The minimum recommended frequency between calls is 10 seconds. > [!NOTE] By default, schedules run at the frequency defined in the application. When you change > the frequency of a schedule from Runtime Manager, the schedule runs at the frequency > configured in Runtime Manager even if you update and redeploy the same schedule in the > application JAR file. 6. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Cron Schedule With cron expressions, you can create more complex schedule frequencies, such as every 5 minutes between 9:00 am and 10:00 am on Fridays. To change the frequency of a cron schedule type: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![cron schedule type](/mulesoft/current/en-us/runtime-fabric/2.7/_images/ch2-scheduler-cron-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** (1) to disable the schedule: ![cron schedule configuration with (1) Enabled option and (2) Quick Reference link](/mulesoft/current/en-us/runtime-fabric/2.7/_images/ch2-scheduler-editor-cron.png) 6. In the schedule editor, click **Quick Reference** (2) to expand or collapse the table that lists required fields and allowed values. The cron expression in this example sets the schedule to every 10 seconds. For information about building cron triggers: 1. View the [Quartz documentation](https://www.quartz-scheduler.org/documentation/). 2. Select a version, click **Documentation > User’s Guide > Tutorial**, and then click the **CronTrigger** lesson. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ## Run a Scheduled Job Immediately If a job runs nightly but you want to debug it now, you can trigger the job while it’s running without updating the schedule in your application. When you trigger the job in between instances of the scheduler running, the timer for the indicated time period resets. > [!NOTE] If you run the scheduled job immediately, the scheduler runs on a single replica even for > multi-replica apps. To override the schedule and run the job immediately: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Run**. ## Disable or Enable a Scheduler Element You might want to disable a scheduled job if an application you are connecting to is undergoing maintenance and then reenable it after maintenance is complete. Runtime Fabric does not run the scheduled job until you reenable the Scheduler. **Known issue**: If you disable the scheduler, it still runs when starting an application. If you want to prevent the scheduler from running, set the `startdelay` property to five seconds in your app using Anypoint Studio. To disable the Scheduler element: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Disable**. You can also disable or enable the schedule by deselecting or selecting **Enabled** in the schedule editor. ![Enabled toggle in the schedule editor](/mulesoft/current/en-us/runtime-fabric/2.7/_images/ch2-scheduler-enable.png) ## See Also - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz documentation](https://www.quartz-scheduler.org/documentation/) - [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) --- product: Runtime Fabric version: 2.8 --- # Managing Mule Apps Schedules > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view and control the Scheduler components within the flows in your deployed applications, all without changing the running application. For example, you might want to disable a scheduled job while one of the applications is undergoing maintenance. On the **Schedules** tab, you can: - View the schedules in your running application. - Change the schedules in your application. - Run the scheduled job immediately, without changing the schedule. - Disable or enable the schedule for a flow. You configure Scheduler component types as either _fixed frequency_ to trigger at a regular interval or _cron_ to trigger at a date and time based on a specified cron expression. > [!IMPORTANT] To change a schedule type (between fixed frequency and cron or vice versa), you must > update and redeploy the app. You can’t change the schedule type on a deployed application. > [!NOTE] The minimum required Mule runtime engine version to use this feature is 4.1.2 or later, > and the minimum Runtime Fabric Agent version is 2.0.0 or later. ## Schedule Design Considerations When designing the schedule, consider the following: - The Runtime Fabric scheduler reads the job configuration every time it runs. When you update the scheduler configuration, the change takes effect the next time the scheduler runs. - Changing the schedule redeploys your application. - If a scheduled job is not triggered because the application is not running, Runtime Fabric triggers the job as soon as the app restarts. - Schedules are based in the scheduler’s defined timezone. - For multi-replica apps, Runtime Fabric runs scheduled jobs on all replicas. If you run the scheduled job immediately by clicking **Run**, the scheduler runs on a single replica. Runtime Fabric distributes multiple concurrent schedulers across replicas. - You cannot manage Runtime Fabric schedules using scripts. Use the **Schedules** tab or the Runtime Fabric API to manage Runtime Fabric schedules. - Flow names can contain only upper and lower case latters, numbers, hyphens (`-`), underscores (`_`), and periods (`.`). The following characters are invalid: `/`, `[`, `]`, `{`, `}`, and `#`. - When you create a schedule using a scheduler that has a placeholder, the value that appears when you create a schedule varies based on when the placeholder is discovered. For example: - If the value is available before the app is deployed, the value appears. - If the value is available before deployment and depends on deployment properties, an estimation of the value appears. - If the value is a placeholder (such as `${cronExpression}`) that is provided at the time of deployment, the exact value of the placeholder does not appear in the user interface. - Runtime Fabric uses a default value of `60000`. ## Before You Begin To use the scheduling feature in Runtime Manager, deploy an application that includes one or more Scheduler elements using Anypoint Studio 7.13 or later. ![Scheduler component in the Anypoint Studio canvas](/mulesoft/current/en-us/runtime-fabric/2.8/_images/ch2-scheduler-studio.png) After you deploy the app, you can manage the schedule in Runtime Manager. The app doesn’t need to be running. Use Mule Maven facade v3 when you deploy through Maven to Runtime Fabric for the schedules to show in the Runtime Manager UI. ## View and Manage Application Schedules in Runtime Manager After deploying an app to Runtime Fabric, view and manage the Scheduler elements in Runtime Manager: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. Runtime Manager lists the Scheduler elements in the order they appear in your app: ![(1) Flow name and (2) the frequency link on the Schedulers page.](/mulesoft/current/en-us/runtime-fabric/2.8/_images/ch2-scheduler-rtm.png) - The **Name** column shows the name of the flow (1) that contains the Scheduler element. - The frequency link (2) in the **Schedule** column shows the schedule for the element. 4. If you want to see more information about when the jobs started and ended, click **Logs** in the navigation menu: ![Logs option in the navigation menu.](/mulesoft/current/en-us/runtime-fabric/2.8/_images/ch2-logs-rtm.png) 5. Click the frequency link for an element to open the schedule editor. The schedule editor you see depends on the schedule type: - [Fixed frequency](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Fixed Frequency Schedule 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![Fixed frequency schedule type](/mulesoft/current/en-us/runtime-fabric/2.8/_images/ch2-scheduler-fixed-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule: ![Fixed-frequency schedule configuration](/mulesoft/current/en-us/runtime-fabric/2.8/_images/ch2-scheduler-editor-fixed.png) You can specify milliseconds, seconds, minutes, hours, or days for the frequency. The minimum recommended frequency between calls is 10 seconds. > [!NOTE] By default, schedules run at the frequency defined in the application. When you change > the frequency of a schedule from Runtime Manager, the schedule runs at the frequency > configured in Runtime Manager even if you update and redeploy the same schedule in the > application JAR file. 6. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Cron Schedule With cron expressions, you can create more complex schedule frequencies, such as every 5 minutes between 9:00 am and 10:00 am on Fridays. To change the frequency of a cron schedule type: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![cron schedule type](/mulesoft/current/en-us/runtime-fabric/2.8/_images/ch2-scheduler-cron-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** (1) to disable the schedule: ![cron schedule configuration with (1) Enabled option and (2) Quick Reference link](/mulesoft/current/en-us/runtime-fabric/2.8/_images/ch2-scheduler-editor-cron.png) 6. In the schedule editor, click **Quick Reference** (2) to expand or collapse the table that lists required fields and allowed values. The cron expression in this example sets the schedule to every 10 seconds. For information about building cron triggers: 1. View the [Quartz documentation](https://www.quartz-scheduler.org/documentation/). 2. Select a version, click **Documentation > User’s Guide > Tutorial**, and then click the **CronTrigger** lesson. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ## Run a Scheduled Job Immediately If a job runs nightly but you want to debug it now, you can trigger the job while it’s running without updating the schedule in your application. When you trigger the job in between instances of the scheduler running, the timer for the indicated time period resets. > [!NOTE] If you run the scheduled job immediately, the scheduler runs on a single replica even for > multi-replica apps. To override the schedule and run the job immediately: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Run**. ## Disable or Enable a Scheduler Element You might want to disable a scheduled job if an application you are connecting to is undergoing maintenance and then reenable it after maintenance is complete. Runtime Fabric does not run the scheduled job until you reenable the Scheduler. **Known issue**: If you disable the scheduler, it still runs when starting an application. If you want to prevent the scheduler from running, set the `startdelay` property to five seconds in your app using Anypoint Studio. To disable the Scheduler element: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Disable**. You can also disable or enable the schedule by deselecting or selecting **Enabled** in the schedule editor. ![Enabled toggle in the schedule editor](/mulesoft/current/en-us/runtime-fabric/2.8/_images/ch2-scheduler-enable.png) ## See Also - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz documentation](https://www.quartz-scheduler.org/documentation/) - [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) --- product: Runtime Fabric version: 2.9 --- # Managing Mule Apps Schedules > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view and control the Scheduler components within the flows in your deployed applications, all without changing the running application. For example, you might want to disable a scheduled job while one of the applications is undergoing maintenance. On the **Schedules** tab, you can: - View the schedules in your running application. - Change the schedules in your application. - Run the scheduled job immediately, without changing the schedule. - Disable or enable the schedule for a flow. You configure Scheduler component types as either _fixed frequency_ to trigger at a regular interval or _cron_ to trigger at a date and time based on a specified cron expression. > [!IMPORTANT] To change a schedule type (between fixed frequency and cron or vice versa), you must > update and redeploy the app. You can’t change the schedule type on a deployed application. > [!NOTE] The minimum required Mule runtime engine version to use this feature is 4.1.2 or later, > and the minimum Runtime Fabric Agent version is 2.0.0 or later. ## Schedule Design Considerations When designing the schedule, consider the following: - The Runtime Fabric scheduler reads the job configuration every time it runs. When you update the scheduler configuration, the change takes effect the next time the scheduler runs. - Changing the schedule redeploys your application. - If a scheduled job is not triggered because the application is not running, Runtime Fabric triggers the job as soon as the app restarts. - Schedules are based in the scheduler’s defined timezone. - For multi-replica apps, Runtime Fabric runs scheduled jobs on all replicas. If you run the scheduled job immediately by clicking **Run**, the scheduler runs on a single replica. Runtime Fabric distributes multiple concurrent schedulers across replicas. - You cannot manage Runtime Fabric schedules using scripts. Use the **Schedules** tab or the Runtime Fabric API to manage Runtime Fabric schedules. - Flow names can contain only upper and lower case latters, numbers, hyphens (`-`), underscores (`_`), and periods (`.`). The following characters are invalid: `/`, `[`, `]`, `{`, `}`, and `#`. - When you create a schedule using a scheduler that has a placeholder, the value that appears when you create a schedule varies based on when the placeholder is discovered. For example: - If the value is available before the app is deployed, the value appears. - If the value is available before deployment and depends on deployment properties, an estimation of the value appears. - If the value is a placeholder (such as `${cronExpression}`) that is provided at the time of deployment, the exact value of the placeholder does not appear in the user interface. - Runtime Fabric uses a default value of `60000`. ## Before You Begin To use the scheduling feature in Runtime Manager, deploy an application that includes one or more Scheduler elements using Anypoint Studio 7.13 or later. ![Scheduler component in the Anypoint Studio canvas](/mulesoft/current/en-us/runtime-fabric/2.9/_images/ch2-scheduler-studio.png) After you deploy the app, you can manage the schedule in Runtime Manager. The app doesn’t need to be running. Use Mule Maven facade v3 when you deploy through Maven to Runtime Fabric for the schedules to show in the Runtime Manager UI. ## View and Manage Application Schedules in Runtime Manager After deploying an app to Runtime Fabric, view and manage the Scheduler elements in Runtime Manager: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. Runtime Manager lists the Scheduler elements in the order they appear in your app: ![(1) Flow name and (2) the frequency link on the Schedulers page.](/mulesoft/current/en-us/runtime-fabric/2.9/_images/ch2-scheduler-rtm.png) - The **Name** column shows the name of the flow (1) that contains the Scheduler element. - The frequency link (2) in the **Schedule** column shows the schedule for the element. 4. If you want to see more information about when the jobs started and ended, click **Logs** in the navigation menu: ![Logs option in the navigation menu.](/mulesoft/current/en-us/runtime-fabric/2.9/_images/ch2-logs-rtm.png) 5. Click the frequency link for an element to open the schedule editor. The schedule editor you see depends on the schedule type: - [Fixed frequency](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Fixed Frequency Schedule 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![Fixed frequency schedule type](/mulesoft/current/en-us/runtime-fabric/2.9/_images/ch2-scheduler-fixed-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule: ![Fixed-frequency schedule configuration](/mulesoft/current/en-us/runtime-fabric/2.9/_images/ch2-scheduler-editor-fixed.png) You can specify milliseconds, seconds, minutes, hours, or days for the frequency. The minimum recommended frequency between calls is 10 seconds. > [!NOTE] By default, schedules run at the frequency defined in the application. When you change > the frequency of a schedule from Runtime Manager, the schedule runs at the frequency > configured in Runtime Manager even if you update and redeploy the same schedule in the > application JAR file. 6. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Cron Schedule With cron expressions, you can create more complex schedule frequencies, such as every 5 minutes between 9:00 am and 10:00 am on Fridays. To change the frequency of a cron schedule type: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![cron schedule type](/mulesoft/current/en-us/runtime-fabric/2.9/_images/ch2-scheduler-cron-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** (1) to disable the schedule: ![cron schedule configuration with (1) Enabled option and (2) Quick Reference link](/mulesoft/current/en-us/runtime-fabric/2.9/_images/ch2-scheduler-editor-cron.png) 6. In the schedule editor, click **Quick Reference** (2) to expand or collapse the table that lists required fields and allowed values. The cron expression in this example sets the schedule to every 10 seconds. For information about building cron triggers: 1. View the [Quartz documentation](https://www.quartz-scheduler.org/documentation/). 2. Select a version, click **Documentation > User’s Guide > Tutorial**, and then click the **CronTrigger** lesson. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ## Run a Scheduled Job Immediately If a job runs nightly but you want to debug it now, you can trigger the job while it’s running without updating the schedule in your application. When you trigger the job in between instances of the scheduler running, the timer for the indicated time period resets. > [!NOTE] If you run the scheduled job immediately, the scheduler runs on a single replica even for > multi-replica apps. To override the schedule and run the job immediately: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Run**. ## Disable or Enable a Scheduler Element You might want to disable a scheduled job if an application you are connecting to is undergoing maintenance and then reenable it after maintenance is complete. Runtime Fabric does not run the scheduled job until you reenable the Scheduler. **Known issue**: If you disable the scheduler, it still runs when starting an application. If you want to prevent the scheduler from running, set the `startdelay` property to five seconds in your app using Anypoint Studio. To disable the Scheduler element: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Disable**. You can also disable or enable the schedule by deselecting or selecting **Enabled** in the schedule editor. ![Enabled toggle in the schedule editor](/mulesoft/current/en-us/runtime-fabric/2.9/_images/ch2-scheduler-enable.png) ## See Also - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz documentation](https://www.quartz-scheduler.org/documentation/) - [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Managing Mule Apps Schedules > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view and control the Scheduler components within the flows in your deployed applications. Some schedule updates can redeploy the application; see [Schedule design considerations](#design-schedule). For example, you might want to disable a scheduled job while one of the applications is undergoing maintenance. On the **Schedules** tab, you can: - View the schedules in your running application. - Change the schedules in your application. - Run the scheduled job immediately, without changing the schedule. - Disable or enable the schedule for a flow. You configure Scheduler component types as either _fixed frequency_ to trigger at a regular interval or _cron_ to trigger at a date and time based on a specified cron expression. > [!IMPORTANT] To change a schedule type (between fixed frequency and cron or vice versa), you must > update and redeploy the app. You can’t change the schedule type on a deployed application. > [!NOTE] The minimum required Mule runtime engine version to use this feature is 4.1.2 or later, > and the minimum Runtime Fabric Agent version is 2.0.0 or later. ## Schedule Design Considerations When designing the schedule, consider the following: - The Runtime Fabric scheduler reads the job configuration every time it runs. When you update the scheduler configuration, the change takes effect the next time the scheduler runs. - When you update a schedule in Runtime Manager or through the Runtime Fabric API, redeployment behavior differs for fixed-frequency and cron schedules: - _Fixed frequency_: Updating the interval or enabling or disabling the schedule typically does not redeploy the application. - _Cron_: Updating the cron expression or related schedule settings can redeploy the application. A redeployment occurs when the schedule change produces a difference in the Kubernetes resources for your deployment. Runtime Fabric applies redeployment when the underlying deployment spec requires it; that outcome is determined by how the Mule application scheduling features represent the change, not by Runtime Fabric itself. - If a scheduled job is not triggered because the application is not running, Runtime Fabric triggers the job as soon as the app restarts. - Schedules are based in the scheduler’s defined timezone. - For multi-replica apps, Runtime Fabric runs scheduled jobs on all replicas. If you run the scheduled job immediately by clicking **Run**, the scheduler runs on a single replica. Runtime Fabric distributes multiple concurrent schedulers across replicas. - You cannot manage Runtime Fabric schedules using scripts. Use the **Schedules** tab or the Runtime Fabric API to manage Runtime Fabric schedules. - Flow names can contain only upper and lower case latters, numbers, hyphens (`-`), underscores (`_`), and periods (`.`). The following characters are invalid: `/`, `[`, `]`, `{`, `}`, and `#`. - When you create a schedule using a scheduler that has a placeholder, the value that appears when you create a schedule varies based on when the placeholder is discovered. For example: - If the value is available before the app is deployed, the value appears. - If the value is available before deployment and depends on deployment properties, an estimation of the value appears. - If the value is a placeholder (such as `${cronExpression}`) that is provided at the time of deployment, the exact value of the placeholder does not appear in the user interface. - Runtime Fabric uses a default value of `60000`. - If you make changes to schedulers, you should reupload the application to Exchange to ensure the expected scheduler behavior occurs. ## Before You Begin To use the scheduling feature in Runtime Manager, deploy an application that includes one or more Scheduler elements using Anypoint Studio 7.13 or later. ![Scheduler component in the Anypoint Studio canvas](/mulesoft/current/en-us/runtime-fabric/latest/_images/ch2-scheduler-studio.png) After you deploy the app, you can manage the schedule in Runtime Manager. The app doesn’t need to be running. Use Mule Maven facade v3 when you deploy through Maven to Runtime Fabric for the schedules to show in the Runtime Manager UI. ## View and Manage Application Schedules in Runtime Manager After deploying an app to Runtime Fabric, view and manage the Scheduler elements in Runtime Manager: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. Runtime Manager lists the Scheduler elements in the order they appear in your app: ![(1) Flow name and (2) the frequency link on the Schedulers page.](/mulesoft/current/en-us/runtime-fabric/latest/_images/ch2-scheduler-rtm.png) - The **Name** column shows the name of the flow (1) that contains the Scheduler element. - The frequency link (2) in the **Schedule** column shows the schedule for the element. 4. If you want to see more information about when the jobs started and ended, click **Logs** in the navigation menu: ![Logs option in the navigation menu.](/mulesoft/current/en-us/runtime-fabric/latest/_images/ch2-logs-rtm.png) 5. Click the frequency link for an element to open the schedule editor. The schedule editor you see depends on the schedule type: - [Fixed frequency](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Fixed Frequency Schedule 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![Fixed frequency schedule type](/mulesoft/current/en-us/runtime-fabric/latest/_images/ch2-scheduler-fixed-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule: ![Fixed-frequency schedule configuration](/mulesoft/current/en-us/runtime-fabric/latest/_images/ch2-scheduler-editor-fixed.png) You can specify milliseconds, seconds, minutes, hours, or days for the frequency. The minimum recommended frequency between calls is 10 seconds. > [!NOTE] By default, schedules run at the frequency defined in the application. When you change > the frequency of a schedule from Runtime Manager, the schedule runs at the frequency > configured in Runtime Manager even if you update and redeploy the same schedule in the > application JAR file. 6. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Cron Schedule With cron expressions, you can create more complex schedule frequencies, such as every 5 minutes between 9:00 am and 10:00 am on Fridays. To change the frequency of a cron schedule type: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![cron schedule type](/mulesoft/current/en-us/runtime-fabric/latest/_images/ch2-scheduler-cron-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** (1) to disable the schedule: ![cron schedule configuration with (1) Enabled option and (2) Quick Reference link](/mulesoft/current/en-us/runtime-fabric/latest/_images/ch2-scheduler-editor-cron.png) 6. In the schedule editor, click **Quick Reference** (2) to expand or collapse the table that lists required fields and allowed values. The cron expression in this example sets the schedule to every 10 seconds. For information about building cron triggers: 1. View the [Quartz documentation](https://www.quartz-scheduler.org/documentation/). 2. Select a version, click **Documentation > User’s Guide > Tutorial**, and then click the **CronTrigger** lesson. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ## Run a Scheduled Job Immediately If a job runs nightly but you want to debug it now, you can trigger the job while it’s running without updating the schedule in your application. When you trigger the job in between instances of the scheduler running, the timer for the indicated time period resets. > [!NOTE] If you run the scheduled job immediately, the scheduler runs on a single replica even for > multi-replica apps. To override the schedule and run the job immediately: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Run**. ## Disable or Enable a Scheduler Element You might want to disable a scheduled job if an application you are connecting to is undergoing maintenance and then reenable it after maintenance is complete. Runtime Fabric does not run the scheduled job until you reenable the Scheduler. **Known issue**: If you disable the scheduler, it still runs when starting an application. If you want to prevent the scheduler from running, set the `startdelay` property to five seconds in your app using Anypoint Studio. To disable the Scheduler element: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Disable**. You can also disable or enable the schedule by deselecting or selecting **Enabled** in the schedule editor. ![Enabled toggle in the schedule editor](/mulesoft/current/en-us/runtime-fabric/latest/_images/ch2-scheduler-enable.png) ## See Also - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz documentation](https://www.quartz-scheduler.org/documentation/) - [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) --- product: Runtime Fabric version: 2.10 --- # Managing Mule Runtime Patch Updates for Apps on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following provides important information about Mule runtime engine patch updates and the Mule runtime engine release channels for Anypoint Runtime Fabric. For a list of patch updates, refer to [Mule runtime patch updates for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). ## Version Rewrite Version rewrite used to override the build tag specified in a deployment request if the build tag was out of support or invalid. Starting October 3, 2023, version rewrite does not override any specified tags for any version. However, if a Mule app is deployed through the API without a build tag, the latest build is auto-selected. ## Monthly Date-Patch Updates Once per month, MuleSoft releases a _date-patch update_, which includes backward-compatible bug fixes to address any issues discovered in Mule runtime engine. The monthly date-patch update might include security patches if the scheduled date is within the security SLA. The format of the version number for these updates is: _Major_._Minor_._Patch_ - _Date_ [Mule Runtime Version Naming Changes](#mule-runtime-version) Here’s an example version number, including the patch date: `4.3.0:20210101` The monthly patches update applications only to the latest date-patch. They do not change the runtime version. ### Mule Runtime Patch Updates for Runtime Fabric Schedule Runtime Fabric runs each application and gateway deployment on a separate Mule runtime instance. By managing the containerized Mule images used for these deployments, Runtime Fabric enables you to upgrade your Mule runtime version for each deployment on the following schedule: 1. On the first full week of the month, you have access to new date-patches of updated Mule runtime instances. 2. During the next two weeks, you can redeploy your applications using the newer date-patch to validate its behavior. This is known as a _grace period_. 3. Beginning on the third full week of the month, you must select the latest date-patch of your chosen Mule runtime version when deploying a new application, or when making a change to an existing application. Starting with Mule runtime engine version 4.5, you can disable autoupgrades of your Mule apps on redeployment by passing the tag required for version pinning. During the grace period, you can select earlier date-patch versions until they are no longer available through the Runtime Manager UI but still usable through the API. Note that this behavior changes starting with Mule runtime engine version 4.5 with Edge and LTS channel releases. All build tags are available in the Runtime Manager UI and API. ### Update a Single App to the Latest Runtime Patch Release Before updating apps in the production environment, update them in the sandbox environment and run required tests. To update an app to the latest date patch: 1. In the Runtime Manager navigation menu, click **Applications**. 2. Under **Deployment Target**, from the **Runtime version** list, select the version tagged `new`: ![The new runtime version is selected](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-runtime-select-version.png) Although the version number of the update might be the same as the installed version, a later date identifies the update: ![The latest runtime version indicated by the date](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-runtime-select-latest-version.png) 3. If you want to see details about the version, click the **Read release notes** link. 4. Click **Apply Changes** to update the app. Runtime Fabric updates the app with the version you selected and displays a message indicating success or failure. 5. Redeploy your application. Mule deployments on Runtime Fabric are not automatically patched. You must redeploy your applications to apply the latest date-patch updates. ## Edge and LTS Releases for Mule Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel TypeRelease CadenceDifferentiatorsSupport Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support

If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf). > [!NOTE] For information about the monthly patch update process, see > [Update Patches to Mule](https://docs.mulesoft.com/release-notes/mule-runtime/patching-mule-versions). ## Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## Mule Runtime Release Cadence Support This table shows the Mule runtime release cadence support for each channel:
Mule VersionRelease DateJava VersionEnd of Standard SupportEnd of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024

> [!NOTE] MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility > with Java 8, 11, and 17. ## Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
ActionRuntime Fabric

Deploy net new apps

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

Auto-upgrade

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

Self-upgrade

Always available

Rollback

Available to the previously used version

Restart apps

Always

Keep running applications

Always

End of Extended Support

Cannot deploy new apps

Retirement

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

Supportability

Supported while Mule apps are within the assigned support period.

## Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 Runtime Fabric requires regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid StandaloneCloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)

The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. After you select the option **Use Edge Release Channel** in the Runtime Manager UI, the platform shows all the build tags for Edge and LTS channels. The build tag is specific to Runtime Manager and CloudHub 2.0 because the image can be built multiple times for a given Mule runtime version. The Runtime Manager UI does not show build tags for Mule runtime engine versions < 4.5 but you can still use any build through the API. ## See Also - [Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) --- product: Runtime Fabric version: 2.11 --- # Managing Mule Runtime Patch Updates for Apps on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt This provides important information about Mule runtime engine patch updates and the Mule runtime engine release channels for Anypoint Runtime Fabric. For a list of patch updates, refer to [Mule runtime patch updates for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). ## Version Rewrite Version rewrite used to override the build tag specified in a deployment request if the build tag was out of support or invalid. Starting October 3, 2023, version rewrite does not override any specified tags for any version. However, if a Mule app is deployed through the API without a build tag, the latest build is auto-selected. ## Monthly Date-Patch Updates Once per month, MuleSoft releases a _date-patch update_, which includes backward-compatible bug fixes to address any issues discovered in Mule runtime engine. The monthly date-patch update might include security patches if the scheduled date is within the security SLA. The format of the version number for these updates is: _Major_._Minor_._Patch_ - _Date_ [Mule Runtime Version Naming Changes](#mule-runtime-version) Here’s an example version number, including the patch date: `4.3.0:20210101` The monthly patches update applications only to the latest date-patch. They do not change the runtime version. ### Mule Runtime Patch Updates for Runtime Fabric Schedule Runtime Fabric runs each application and gateway deployment on a separate Mule runtime instance. By managing the containerized Mule images used for these deployments, Runtime Fabric enables you to upgrade your Mule runtime version for each deployment on this schedule: 1. On the first full week of the month, you have access to new date-patches of updated Mule runtime instances. 2. During the next two weeks, you can redeploy your applications using the newer date-patch to validate its behavior. This is known as a _grace period_. 3. Beginning on the third full week of the month, you must select the latest date-patch of your chosen Mule runtime version when deploying a new application, or when making a change to an existing application. Starting with Mule runtime engine version 4.5, you can disable autoupgrades of your Mule apps on redeployment by passing the tag required for version pinning. During the grace period, you can select earlier date-patch versions until they are no longer available through the Runtime Manager UI but still usable through the API. Note that this behavior changes starting with Mule runtime engine version 4.5 with Edge and LTS channel releases. All build tags are available in the Runtime Manager UI and API. ### Update a Single App to the Latest Runtime Patch Release Before updating apps in the production environment, update them in the sandbox environment and run required tests. To update an app to the latest date patch: 1. In the Runtime Manager navigation menu, click **Applications**. 2. Under **Deployment Target**, from the **Runtime version** list, select the version tagged `new`: ![The new runtime version is selected](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-runtime-select-version.png) Although the version number of the update might be the same as the installed version, a later date identifies the update: ![The latest runtime version indicated by the date](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-runtime-select-latest-version.png) 3. If you want to see details about the version, click the **Read release notes** link. 4. Click **Apply Changes** to update the app. Runtime Fabric updates the app with the version you selected and displays a message indicating success or failure. 5. Redeploy your application. Mule deployments on Runtime Fabric are not automatically patched. You must redeploy your applications to apply the latest date-patch updates. ## Edge and LTS Releases for Mule Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel TypeRelease CadenceDifferentiatorsSupport Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support

If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf). > [!NOTE] For information about the monthly patch update process, see > [Update Patches to Mule](https://docs.mulesoft.com/release-notes/mule-runtime/patching-mule-versions). ## Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## Mule Runtime Release Cadence Support This table shows the Mule runtime release cadence support for each channel:
Mule VersionRelease DateJava VersionEnd of Standard SupportEnd of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024

> [!NOTE] MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility > with Java 8, 11, and 17. ## Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
ActionRuntime Fabric

Deploy net new apps

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

Auto-upgrade

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

Self-upgrade

Always available

Rollback

Available to the previously used version

Restart apps

Always

Keep running applications

Always

End of Extended Support

Cannot deploy new apps

Retirement

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

Supportability

Supported while Mule apps are within the assigned support period.

## Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 Runtime Fabric requires regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid StandaloneCloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)

The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. After you select the option **Use Edge Release Channel** in the Runtime Manager UI, the platform shows all the build tags for Edge and LTS channels. The build tag is specific to Runtime Manager and CloudHub 2.0 because the image can be built multiple times for a given Mule runtime version. The Runtime Manager UI does not show build tags for Mule runtime engine versions < 4.5 but you can still use any build through the API. ## See Also - [Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) --- product: Runtime Fabric version: 2.5 --- # Managing Mule Runtime Patch Updates for Apps on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following provides important information about Mule runtime engine patch updates and the Mule runtime engine release channels for Anypoint Runtime Fabric. ## Version Rewrite Version rewrite used to override the build tag specified in a deployment request if the build tag was out of support or invalid. Starting October 3, 2023, version rewrite does not override any specified tags for any version. However, if a Mule app is deployed through the API without a build tag, the latest build is auto-selected. ## Monthly Date-Patch Updates Once per month, MuleSoft releases a _date-patch update_, which includes backward-compatible bug fixes to address any issues discovered in Mule runtime engine. The monthly date-patch update might include security patches if the scheduled date is within the security SLA. The format of the version number for these updates is: _Major_._Minor_._Patch_ - _Date_ [Mule Runtime Version Naming Changes](#mule-runtime-version) Here’s an example version number, including the patch date: `4.3.0:20210101` The monthly patches update applications only to the latest date-patch. They do not change the runtime version. ### Mule Runtime Patch Updates for Runtime Fabric Schedule Runtime Fabric runs each application and gateway deployment on a separate Mule runtime instance. By managing the containerized Mule images used for these deployments, Runtime Fabric enables you to upgrade your Mule runtime version for each deployment on the following schedule: 1. On the first full week of the month, you have access to new date-patches of updated Mule runtime instances. 2. During the next two weeks, you can redeploy your applications using the newer date-patch to validate its behavior. This is known as a _grace period_. 3. Beginning on the third full week of the month, you must select the latest date-patch of your chosen Mule runtime version when deploying a new application, or when making a change to an existing application. Starting with Mule runtime engine version 4.5, you can disable autoupgrades of your Mule apps on redeployment by passing the tag required for version pinning. During the grace period, you can select earlier date-patch versions until they are no longer available through the Runtime Manager UI but still usable through the API. Note that this behavior changes starting with Mule runtime engine version 4.5 with Edge and LTS channel releases. All build tags are available in the Runtime Manager UI and API. ### Update a Single App to the Latest Runtime Patch Release Before updating apps in the production environment, update them in the sandbox environment and run required tests. To update an app to the latest date patch: 1. In the Runtime Manager navigation menu, click **Applications**. 2. Under **Deployment Target**, from the **Runtime version** list, select the version tagged `new`: ![The new runtime version is selected](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-runtime-select-version.png) Although the version number of the update might be the same as the installed version, a later date identifies the update: ![The latest runtime version indicated by the date](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-runtime-select-latest-version.png) 3. If you want to see details about the version, click the **Read release notes** link. 4. Click **Apply Changes** to update the app. Runtime Fabric updates the app with the version you selected and displays a message indicating success or failure. 5. Redeploy your application. Mule deployments on Runtime Fabric are not automatically patched. You must redeploy your applications to apply the latest date-patch updates. ## Edge and LTS Releases for Mule Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel TypeRelease CadenceDifferentiatorsSupport Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support

If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf). > [!NOTE] For information about the monthly patch update process, see > [Update Patches to Mule](https://docs.mulesoft.com/release-notes/mule-runtime/patching-mule-versions). ## Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## Mule Runtime Release Cadence Support This table shows the Mule runtime release cadence support for each channel:
Mule VersionRelease DateJava VersionEnd of Standard SupportEnd of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024

> [!NOTE] MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility > with Java 8, 11, and 17. ## Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
ActionRuntime Fabric

Deploy net new apps

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

Auto-upgrade

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

Self-upgrade

Always available

Rollback

Available to the previously used version

Restart apps

Always

Keep running applications

Always

End of Extended Support

Cannot deploy new apps

Retirement

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

Supportability

Supported while Mule apps are within the assigned support period.

## Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 Runtime Fabric requires regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid StandaloneCloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)

The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. After you select the option **Use Edge Release Channel** in the Runtime Manager UI, the platform shows all the build tags for Edge and LTS channels. The build tag is specific to Runtime Manager and CloudHub 2.0 because the image can be built multiple times for a given Mule runtime version. The Runtime Manager UI does not show build tags for Mule runtime engine versions < 4.5 but you can still use any build through the API. ## See Also - [Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) --- product: Runtime Fabric version: 2.6 --- # Managing Mule Runtime Patch Updates for Apps on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following provides important information about Mule runtime engine patch updates and the Mule runtime engine release channels for Anypoint Runtime Fabric. For a list of patch updates, refer to [Mule runtime patch updates for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). ## Version Rewrite Version rewrite used to override the build tag specified in a deployment request if the build tag was out of support or invalid. Starting October 3, 2023, version rewrite does not override any specified tags for any version. However, if a Mule app is deployed through the API without a build tag, the latest build is auto-selected. ## Monthly Date-Patch Updates Once per month, MuleSoft releases a _date-patch update_, which includes backward-compatible bug fixes to address any issues discovered in Mule runtime engine. The monthly date-patch update might include security patches if the scheduled date is within the security SLA. The format of the version number for these updates is: _Major_._Minor_._Patch_ - _Date_ [Mule Runtime Version Naming Changes](#mule-runtime-version) Here’s an example version number, including the patch date: `4.3.0:20210101` The monthly patches update applications only to the latest date-patch. They do not change the runtime version. ### Mule Runtime Patch Updates for Runtime Fabric Schedule Runtime Fabric runs each application and gateway deployment on a separate Mule runtime instance. By managing the containerized Mule images used for these deployments, Runtime Fabric enables you to upgrade your Mule runtime version for each deployment on the following schedule: 1. On the first full week of the month, you have access to new date-patches of updated Mule runtime instances. 2. During the next two weeks, you can redeploy your applications using the newer date-patch to validate its behavior. This is known as a _grace period_. 3. Beginning on the third full week of the month, you must select the latest date-patch of your chosen Mule runtime version when deploying a new application, or when making a change to an existing application. Starting with Mule runtime engine version 4.5, you can disable autoupgrades of your Mule apps on redeployment by passing the tag required for version pinning. During the grace period, you can select earlier date-patch versions until they are no longer available through the Runtime Manager UI but still usable through the API. Note that this behavior changes starting with Mule runtime engine version 4.5 with Edge and LTS channel releases. All build tags are available in the Runtime Manager UI and API. ### Update a Single App to the Latest Runtime Patch Release Before updating apps in the production environment, update them in the sandbox environment and run required tests. To update an app to the latest date patch: 1. In the Runtime Manager navigation menu, click **Applications**. 2. Under **Deployment Target**, from the **Runtime version** list, select the version tagged `new`: ![The new runtime version is selected](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-runtime-select-version.png) Although the version number of the update might be the same as the installed version, a later date identifies the update: ![The latest runtime version indicated by the date](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-runtime-select-latest-version.png) 3. If you want to see details about the version, click the **Read release notes** link. 4. Click **Apply Changes** to update the app. Runtime Fabric updates the app with the version you selected and displays a message indicating success or failure. 5. Redeploy your application. Mule deployments on Runtime Fabric are not automatically patched. You must redeploy your applications to apply the latest date-patch updates. ## Edge and LTS Releases for Mule Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel TypeRelease CadenceDifferentiatorsSupport Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support

If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf). > [!NOTE] For information about the monthly patch update process, see > [Update Patches to Mule](https://docs.mulesoft.com/release-notes/mule-runtime/patching-mule-versions). ## Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## Mule Runtime Release Cadence Support This table shows the Mule runtime release cadence support for each channel:
Mule VersionRelease DateJava VersionEnd of Standard SupportEnd of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024

> [!NOTE] MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility > with Java 8, 11, and 17. ## Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
ActionRuntime Fabric

Deploy net new apps

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

Auto-upgrade

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

Self-upgrade

Always available

Rollback

Available to the previously used version

Restart apps

Always

Keep running applications

Always

End of Extended Support

Cannot deploy new apps

Retirement

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

Supportability

Supported while Mule apps are within the assigned support period.

## Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 Runtime Fabric requires regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid StandaloneCloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)

The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. After you select the option **Use Edge Release Channel** in the Runtime Manager UI, the platform shows all the build tags for Edge and LTS channels. The build tag is specific to Runtime Manager and CloudHub 2.0 because the image can be built multiple times for a given Mule runtime version. The Runtime Manager UI does not show build tags for Mule runtime engine versions < 4.5 but you can still use any build through the API. ## See Also - [Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) --- product: Runtime Fabric version: 2.7 --- # Managing Mule Runtime Patch Updates for Apps on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following provides important information about Mule runtime engine patch updates and the Mule runtime engine release channels for Anypoint Runtime Fabric. For a list of patch updates, refer to [Mule runtime patch updates for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). ## Version Rewrite Version rewrite used to override the build tag specified in a deployment request if the build tag was out of support or invalid. Starting October 3, 2023, version rewrite does not override any specified tags for any version. However, if a Mule app is deployed through the API without a build tag, the latest build is auto-selected. ## Monthly Date-Patch Updates Once per month, MuleSoft releases a _date-patch update_, which includes backward-compatible bug fixes to address any issues discovered in Mule runtime engine. The monthly date-patch update might include security patches if the scheduled date is within the security SLA. The format of the version number for these updates is: _Major_._Minor_._Patch_ - _Date_ [Mule Runtime Version Naming Changes](#mule-runtime-version) Here’s an example version number, including the patch date: `4.3.0:20210101` The monthly patches update applications only to the latest date-patch. They do not change the runtime version. ### Mule Runtime Patch Updates for Runtime Fabric Schedule Runtime Fabric runs each application and gateway deployment on a separate Mule runtime instance. By managing the containerized Mule images used for these deployments, Runtime Fabric enables you to upgrade your Mule runtime version for each deployment on the following schedule: 1. On the first full week of the month, you have access to new date-patches of updated Mule runtime instances. 2. During the next two weeks, you can redeploy your applications using the newer date-patch to validate its behavior. This is known as a _grace period_. 3. Beginning on the third full week of the month, you must select the latest date-patch of your chosen Mule runtime version when deploying a new application, or when making a change to an existing application. Starting with Mule runtime engine version 4.5, you can disable autoupgrades of your Mule apps on redeployment by passing the tag required for version pinning. During the grace period, you can select earlier date-patch versions until they are no longer available through the Runtime Manager UI but still usable through the API. Note that this behavior changes starting with Mule runtime engine version 4.5 with Edge and LTS channel releases. All build tags are available in the Runtime Manager UI and API. ### Update a Single App to the Latest Runtime Patch Release Before updating apps in the production environment, update them in the sandbox environment and run required tests. To update an app to the latest date patch: 1. In the Runtime Manager navigation menu, click **Applications**. 2. Under **Deployment Target**, from the **Runtime version** list, select the version tagged `new`: ![The new runtime version is selected](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-runtime-select-version.png) Although the version number of the update might be the same as the installed version, a later date identifies the update: ![The latest runtime version indicated by the date](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-runtime-select-latest-version.png) 3. If you want to see details about the version, click the **Read release notes** link. 4. Click **Apply Changes** to update the app. Runtime Fabric updates the app with the version you selected and displays a message indicating success or failure. 5. Redeploy your application. Mule deployments on Runtime Fabric are not automatically patched. You must redeploy your applications to apply the latest date-patch updates. ## Edge and LTS Releases for Mule Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel TypeRelease CadenceDifferentiatorsSupport Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support

If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf). > [!NOTE] For information about the monthly patch update process, see > [Update Patches to Mule](https://docs.mulesoft.com/release-notes/mule-runtime/patching-mule-versions). ## Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## Mule Runtime Release Cadence Support This table shows the Mule runtime release cadence support for each channel:
Mule VersionRelease DateJava VersionEnd of Standard SupportEnd of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024

> [!NOTE] MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility > with Java 8, 11, and 17. ## Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
ActionRuntime Fabric

Deploy net new apps

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

Auto-upgrade

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

Self-upgrade

Always available

Rollback

Available to the previously used version

Restart apps

Always

Keep running applications

Always

End of Extended Support

Cannot deploy new apps

Retirement

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

Supportability

Supported while Mule apps are within the assigned support period.

## Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 Runtime Fabric requires regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid StandaloneCloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)

The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. After you select the option **Use Edge Release Channel** in the Runtime Manager UI, the platform shows all the build tags for Edge and LTS channels. The build tag is specific to Runtime Manager and CloudHub 2.0 because the image can be built multiple times for a given Mule runtime version. The Runtime Manager UI does not show build tags for Mule runtime engine versions < 4.5 but you can still use any build through the API. ## See Also - [Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) --- product: Runtime Fabric version: 2.8 --- # Managing Mule Runtime Patch Updates for Apps on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following provides important information about Mule runtime engine patch updates and the Mule runtime engine release channels for Anypoint Runtime Fabric. For a list of patch updates, refer to [Mule runtime patch updates for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). ## Version Rewrite Version rewrite used to override the build tag specified in a deployment request if the build tag was out of support or invalid. Starting October 3, 2023, version rewrite does not override any specified tags for any version. However, if a Mule app is deployed through the API without a build tag, the latest build is auto-selected. ## Monthly Date-Patch Updates Once per month, MuleSoft releases a _date-patch update_, which includes backward-compatible bug fixes to address any issues discovered in Mule runtime engine. The monthly date-patch update might include security patches if the scheduled date is within the security SLA. The format of the version number for these updates is: _Major_._Minor_._Patch_ - _Date_ [Mule Runtime Version Naming Changes](#mule-runtime-version) Here’s an example version number, including the patch date: `4.3.0:20210101` The monthly patches update applications only to the latest date-patch. They do not change the runtime version. ### Mule Runtime Patch Updates for Runtime Fabric Schedule Runtime Fabric runs each application and gateway deployment on a separate Mule runtime instance. By managing the containerized Mule images used for these deployments, Runtime Fabric enables you to upgrade your Mule runtime version for each deployment on the following schedule: 1. On the first full week of the month, you have access to new date-patches of updated Mule runtime instances. 2. During the next two weeks, you can redeploy your applications using the newer date-patch to validate its behavior. This is known as a _grace period_. 3. Beginning on the third full week of the month, you must select the latest date-patch of your chosen Mule runtime version when deploying a new application, or when making a change to an existing application. Starting with Mule runtime engine version 4.5, you can disable autoupgrades of your Mule apps on redeployment by passing the tag required for version pinning. During the grace period, you can select earlier date-patch versions until they are no longer available through the Runtime Manager UI but still usable through the API. Note that this behavior changes starting with Mule runtime engine version 4.5 with Edge and LTS channel releases. All build tags are available in the Runtime Manager UI and API. ### Update a Single App to the Latest Runtime Patch Release Before updating apps in the production environment, update them in the sandbox environment and run required tests. To update an app to the latest date patch: 1. In the Runtime Manager navigation menu, click **Applications**. 2. Under **Deployment Target**, from the **Runtime version** list, select the version tagged `new`: ![The new runtime version is selected](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-runtime-select-version.png) Although the version number of the update might be the same as the installed version, a later date identifies the update: ![The latest runtime version indicated by the date](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-runtime-select-latest-version.png) 3. If you want to see details about the version, click the **Read release notes** link. 4. Click **Apply Changes** to update the app. Runtime Fabric updates the app with the version you selected and displays a message indicating success or failure. 5. Redeploy your application. Mule deployments on Runtime Fabric are not automatically patched. You must redeploy your applications to apply the latest date-patch updates. ## Edge and LTS Releases for Mule Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel TypeRelease CadenceDifferentiatorsSupport Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support

If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf). > [!NOTE] For information about the monthly patch update process, see > [Update Patches to Mule](https://docs.mulesoft.com/release-notes/mule-runtime/patching-mule-versions). ## Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## Mule Runtime Release Cadence Support This table shows the Mule runtime release cadence support for each channel:
Mule VersionRelease DateJava VersionEnd of Standard SupportEnd of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024

> [!NOTE] MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility > with Java 8, 11, and 17. ## Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
ActionRuntime Fabric

Deploy net new apps

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

Auto-upgrade

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

Self-upgrade

Always available

Rollback

Available to the previously used version

Restart apps

Always

Keep running applications

Always

End of Extended Support

Cannot deploy new apps

Retirement

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

Supportability

Supported while Mule apps are within the assigned support period.

## Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 Runtime Fabric requires regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid StandaloneCloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)

The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. After you select the option **Use Edge Release Channel** in the Runtime Manager UI, the platform shows all the build tags for Edge and LTS channels. The build tag is specific to Runtime Manager and CloudHub 2.0 because the image can be built multiple times for a given Mule runtime version. The Runtime Manager UI does not show build tags for Mule runtime engine versions < 4.5 but you can still use any build through the API. ## See Also - [Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) --- product: Runtime Fabric version: 2.9 --- # Managing Mule Runtime Patch Updates for Apps on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following provides important information about Mule runtime engine patch updates and the Mule runtime engine release channels for Anypoint Runtime Fabric. For a list of patch updates, refer to [Mule runtime patch updates for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). ## Version Rewrite Version rewrite used to override the build tag specified in a deployment request if the build tag was out of support or invalid. Starting October 3, 2023, version rewrite does not override any specified tags for any version. However, if a Mule app is deployed through the API without a build tag, the latest build is auto-selected. ## Monthly Date-Patch Updates Once per month, MuleSoft releases a _date-patch update_, which includes backward-compatible bug fixes to address any issues discovered in Mule runtime engine. The monthly date-patch update might include security patches if the scheduled date is within the security SLA. The format of the version number for these updates is: _Major_._Minor_._Patch_ - _Date_ [Mule Runtime Version Naming Changes](#mule-runtime-version) Here’s an example version number, including the patch date: `4.3.0:20210101` The monthly patches update applications only to the latest date-patch. They do not change the runtime version. ### Mule Runtime Patch Updates for Runtime Fabric Schedule Runtime Fabric runs each application and gateway deployment on a separate Mule runtime instance. By managing the containerized Mule images used for these deployments, Runtime Fabric enables you to upgrade your Mule runtime version for each deployment on the following schedule: 1. On the first full week of the month, you have access to new date-patches of updated Mule runtime instances. 2. During the next two weeks, you can redeploy your applications using the newer date-patch to validate its behavior. This is known as a _grace period_. 3. Beginning on the third full week of the month, you must select the latest date-patch of your chosen Mule runtime version when deploying a new application, or when making a change to an existing application. Starting with Mule runtime engine version 4.5, you can disable autoupgrades of your Mule apps on redeployment by passing the tag required for version pinning. During the grace period, you can select earlier date-patch versions until they are no longer available through the Runtime Manager UI but still usable through the API. Note that this behavior changes starting with Mule runtime engine version 4.5 with Edge and LTS channel releases. All build tags are available in the Runtime Manager UI and API. ### Update a Single App to the Latest Runtime Patch Release Before updating apps in the production environment, update them in the sandbox environment and run required tests. To update an app to the latest date patch: 1. In the Runtime Manager navigation menu, click **Applications**. 2. Under **Deployment Target**, from the **Runtime version** list, select the version tagged `new`: ![The new runtime version is selected](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-runtime-select-version.png) Although the version number of the update might be the same as the installed version, a later date identifies the update: ![The latest runtime version indicated by the date](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-runtime-select-latest-version.png) 3. If you want to see details about the version, click the **Read release notes** link. 4. Click **Apply Changes** to update the app. Runtime Fabric updates the app with the version you selected and displays a message indicating success or failure. 5. Redeploy your application. Mule deployments on Runtime Fabric are not automatically patched. You must redeploy your applications to apply the latest date-patch updates. ## Edge and LTS Releases for Mule Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel TypeRelease CadenceDifferentiatorsSupport Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support

If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf). > [!NOTE] For information about the monthly patch update process, see > [Update Patches to Mule](https://docs.mulesoft.com/release-notes/mule-runtime/patching-mule-versions). ## Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## Mule Runtime Release Cadence Support This table shows the Mule runtime release cadence support for each channel:
Mule VersionRelease DateJava VersionEnd of Standard SupportEnd of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024

> [!NOTE] MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility > with Java 8, 11, and 17. ## Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
ActionRuntime Fabric

Deploy net new apps

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

Auto-upgrade

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

Self-upgrade

Always available

Rollback

Available to the previously used version

Restart apps

Always

Keep running applications

Always

End of Extended Support

Cannot deploy new apps

Retirement

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

Supportability

Supported while Mule apps are within the assigned support period.

## Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 Runtime Fabric requires regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid StandaloneCloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)

The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. After you select the option **Use Edge Release Channel** in the Runtime Manager UI, the platform shows all the build tags for Edge and LTS channels. The build tag is specific to Runtime Manager and CloudHub 2.0 because the image can be built multiple times for a given Mule runtime version. The Runtime Manager UI does not show build tags for Mule runtime engine versions < 4.5 but you can still use any build through the API. ## See Also - [Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Managing Mule Runtime Patch Updates for Apps on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following provides important information about Mule runtime engine patch updates and the Mule runtime engine release channels for Anypoint Runtime Fabric. For a list of patch updates, refer to [Mule runtime patch updates for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). ## Version Rewrite Version rewrite used to override the build tag specified in a deployment request if the build tag was out of support or invalid. Starting October 3, 2023, version rewrite does not override any specified tags for any version. However, if a Mule app is deployed through the API without a build tag, the latest build is auto-selected. ## Monthly Date-Patch Updates Once per month, MuleSoft releases a _date-patch update_, which includes backward-compatible bug fixes to address any issues discovered in Mule runtime engine. The monthly date-patch update might include security patches if the scheduled date is within the security SLA. The format of the version number for these updates is: _Major_._Minor_._Patch_ - _Date_ [Mule Runtime Version Naming Changes](#mule-runtime-version) Here’s an example version number, including the patch date: `4.3.0:20210101` The monthly patches update applications only to the latest date-patch. They do not change the runtime version. ### Mule Runtime Patch Updates for Runtime Fabric Schedule Runtime Fabric runs each application and gateway deployment on a separate Mule runtime instance. By managing the containerized Mule images used for these deployments, Runtime Fabric enables you to upgrade your Mule runtime version for each deployment on the following schedule: 1. On the first full week of the month, you have access to new date-patches of updated Mule runtime instances. 2. During the next two weeks, you can redeploy your applications using the newer date-patch to validate its behavior. This is known as a _grace period_. 3. Beginning on the third full week of the month, you must select the latest date-patch of your chosen Mule runtime version when deploying a new application, or when making a change to an existing application. Starting with Mule runtime engine version 4.5, you can disable autoupgrades of your Mule apps on redeployment by passing the tag required for version pinning. During the grace period, you can select earlier date-patch versions until they are no longer available through the Runtime Manager UI but still usable through the API. Note that this behavior changes starting with Mule runtime engine version 4.5 with Edge and LTS channel releases. All build tags are available in the Runtime Manager UI and API. ### Update a Single App to the Latest Runtime Patch Release Before updating apps in the production environment, update them in the sandbox environment and run required tests. To update an app to the latest date patch: 1. In the Runtime Manager navigation menu, click **Applications**. 2. Under **Deployment Target**, from the **Runtime version** list, select the version tagged `new`: ![The new runtime version is selected](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-runtime-select-version.png) Although the version number of the update might be the same as the installed version, a later date identifies the update: ![The latest runtime version indicated by the date](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-runtime-select-latest-version.png) 3. If you want to see details about the version, click the **Read release notes** link. 4. Click **Apply Changes** to update the app. Runtime Fabric updates the app with the version you selected and displays a message indicating success or failure. 5. Redeploy your application. Mule deployments on Runtime Fabric are not automatically patched. You must redeploy your applications to apply the latest date-patch updates. ## Edge and LTS Releases for Mule Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel TypeRelease CadenceDifferentiatorsSupport Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support

If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf). > [!NOTE] For information about the monthly patch update process, see > [Update Patches to Mule](https://docs.mulesoft.com/release-notes/mule-runtime/patching-mule-versions). ## Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## Mule Runtime Release Cadence Support This table shows the Mule runtime release cadence support for each channel:
Mule VersionRelease DateJava VersionEnd of Standard SupportEnd of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024

> [!NOTE] MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility > with Java 8, 11, and 17. ## Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
ActionRuntime Fabric

Deploy net new apps

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

Auto-upgrade

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

Self-upgrade

Always available

Rollback

Available to the previously used version

Restart apps

Always

Keep running applications

Always

End of Extended Support

Cannot deploy new apps

Retirement

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

Supportability

Supported while Mule apps are within the assigned support period.

## Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 Runtime Fabric requires regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid StandaloneCloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)

The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. After you select the option **Use Edge Release Channel** in the Runtime Manager UI, the platform shows all the build tags for Edge and LTS channels. The build tag is specific to Runtime Manager and CloudHub 2.0 because the image can be built multiple times for a given Mule runtime version. The Runtime Manager UI does not show build tags for Mule runtime engine versions < 4.5 but you can still use any build through the API. ## See Also - [Runtime Fabric Runtimes Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) --- product: Runtime Fabric version: 2.5 --- # Managing Proxies on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric uses two types of proxies when running and hosting applications: - System proxies: include proxies that enable connectivity among Kubernetes cluster services, including the Docker daemon and other internal components. When using Runtime Fabric you are responsible for configuring and managing system proxies. - Application proxies: include proxies that enable connectivity to applications running on Runtime Fabric. You can configure the proxy settings used by Runtime Fabric outbound connections to the internet. This includes both HTTP proxies for connecting to the Anypoint Platform control plane and SOCKS5 proxies for sending metrics and logs to Anypoint Monitoring. You can also configure proxies for applications. ## Install rtfctl The `rtfctl` command line tool is required to manage proxy settings on Runtime Fabric. Follow the steps to [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.5/install-rtfctl) before configuring proxy settings. > [!NOTE] You can apply proxy settings during installation of Runtime Fabric if you install using > Helm. For more information, refer to the > [Installing Runtime Fabric Using Helm documentation](https://docs.mulesoft.com/runtime-fabric/2.5/install-helm). ## Configure an Anypoint Monitoring Proxy Because the monitoring agent requires a SOCKS5 proxy, you need two proxy types if you use Anypoint Monitoring. The SOCKS5 proxy must connect to Anypoint Monitoring over TCP at the following endpoints: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` 1. Log in to a node where `rtfctl` is installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" ``` - ****: the username needed to authenticate to the SOCKS5 proxy. - ****: the password needed to authenticate to the SOCKS5 proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.2>**: The IP address or hostname used to access the SOCKS5 proxy. - **<8080>**: The host port on the host where the SOCKS5 proxy is listening for requests. 1. To verify the change was successful, run the following command to output the current value of the monitoring proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy ``` The output should match the value expected. ## Configure an HTTP Proxy for Services in Runtime Fabric You can configure HTTP and HTTPS proxies so that outbound components can communicate with the control plane. Updating an HTTP proxy causes each machine in the cluster to restart all pods running on it. Although no downtime occurs if you are running multiple replicas, you should perform HTTP proxy updates during a maintenance window. - Apply the proxy values to the services running within Runtime Fabric. - If you are using Runtime Fabric installer 1.0.x, run the script on each node of your Runtime Fabric to update the cluster. 1. Log in to a node where `rtfctl` has been installed. 2. Run the following command, replacing the placeholder values with the following: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" ``` - ****: the username needed to authenticate to the HTTP proxy. - ****: the password needed to authenticate to the HTTP proxy. > [!NOTE] The password must be URL encoded. - **<10.0.0.1>**: Specifies the IP address or hostname to access the HTTP proxy. - **<8080>**: Specifies the port on the host where the HTTP proxy is listening for requests. - **<1.1.1.1:8888,2.2.2.2:9999>**: Specifies the `RTF_NO_PROXY` hosts and ports, delimited by commas. - (Optional) `--confirm`: Skips manual acknowledgement of the change. If not specified, the `rtfctl apply proxy` command prompts you to confirm the change before continuing. 1. To verify the change was successful, run the following command to output the current value of the HTTP proxy: ```copy /opt/anypoint/runtimefabric/rtfctl get http-proxy ``` The output should match the value expected. 2. To remove the proxy values, run: ```copy /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ``` ### About the HTTP\_PROXY Environment Variable After applying a proxy for services in Runtime Fabric, you could see a warning similar to: Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric generates a warning to let you know that you have not set the `HTTP_PROXY` environment variable or that the variable does not match the value used for Runtime Fabric services. The settings do not have to match, but Runtime Fabric generates the warning so you’re aware services could be impacted. Many Linux tools use the `HTTP_PROXY` environment variable to provide their proxy settings. If your environment requires a proxy for Internet access, you likely need to set the `HTTP_PROXY` environment variable for commands that require Internet access. This could affect other tools that also use HTTP or HTTPS operations but do not require Internet access, such as `kubectl`. You can use the `NO_PROXY` environment variable to establish connections that should not be proxied. Refer to the documentation for your Linux tools for more information on which environment variables affect its proxy behavior. ### About the NO\_PROXY Environment Variable By default, `NO_PROXY` is set to `0.0.0.0/0` and `.local`. These settings ensure that the proxy does not route any IPV4 destination addresses. ## Configure a Proxy for the API Manager Agent You can use a proxy to establish communication for Mule applications that you manage with API Manager. This proxy configuration must be set on each Mule application, even if you are using the same configuration for all applications. Note this setting is independent from the application-level proxy that applications use to communicate with other external endpoints. To configure a proxy for the API Manager Agent, add the following properties to the application: anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## Configure a Proxy for a Mule Application Applications deployed in Runtime Fabric inherit proxy settings from the Runtime Fabric cluster. You can also configure a proxy for each application. You can set up a proxy on each connector (such as an HTTP requestor) or set up a proxy with application properties as shown in the following example. Setting up a proxy with application properties is less work if you have a large number of connectors in an application. http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true --- product: Runtime Fabric version: 2.10 --- # Managing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Anypoint Runtime Fabric, review the following topics: - [Viewing Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.10/view-health) Use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. - [Using RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl) Use the `rtfctl` command line tool to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can manage deployed Mule apps, protect Mule app values, and install and replace Mule license keys. - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.10/replace-license-key) Use the `rtfctl` command line tool to replace an expired Mule license key. - [Downgrading Runtime Fabric Version](https://docs.mulesoft.com/runtime-fabric/2.10/downgrade-runtime-fabric) Use the `rtfctl` command line tool or Helm to downgrade Runtime Fabric versions. - [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/migrate-helm) Migrate to Helm native for Runtime Fabrics that were installed using `rtfctl`. - [Enabling Forwarding When Using firewalld](https://docs.mulesoft.com/runtime-fabric/2.10/prereq-firewalld-forwarding) Enable forwarding on the docker device, if you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/setting-up-runtime-fabric) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.11 --- # Managing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Anypoint Runtime Fabric, review these topics: - [Viewing Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.11/view-health) Use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. - [Using RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl) Use the `rtfctl` command line tool to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can manage deployed Mule apps, protect Mule app values, and install and replace Mule license keys. - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.11/replace-license-key) Use the `rtfctl` command line tool to replace an expired Mule license key. - [Downgrading Runtime Fabric Version](https://docs.mulesoft.com/runtime-fabric/2.11/downgrade-runtime-fabric) Use the `rtfctl` command line tool or Helm to downgrade Runtime Fabric versions. - [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/migrate-helm) Migrate to Helm native for Runtime Fabrics that were installed using `rtfctl`. - [Enabling Forwarding When Using firewalld](https://docs.mulesoft.com/runtime-fabric/2.11/prereq-firewalld-forwarding) Enable forwarding on the docker device, if you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/setting-up-runtime-fabric) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.5 --- # Managing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you install and configure Anypoint Runtime Fabric and deploy Mule applications and API proxies, you might need to perform additional tasks. - Monitor and View - View Runtime Fabric status. See [View Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.5/view-health). - Use Anypoint Monitoring and Anypoint Visualizer to monitor applications deployed to Runtime Fabric. See [Monitor Applications Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/manage-monitor-applications). - Monitor the performance and health of your Runtime Fabric installation. - Update - Install rtfctl to manage Runtime Fabric settings. See [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.5/install-rtfctl). - Install patches and perform other scheduled maintenance on Runtime Fabric. - Replace your Mule license key. See [Replace a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.5/replace-license-key). - Maintain - Configure proxy settings used by Runtime Fabric outbound connections. See [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/manage-proxy-self). - Manage Runtime Fabric secure properties. See [Manage Secure Properties in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/manage-secure-properties). - Enable mutual authentication. - Back up Runtime Fabric. See [Back up and Restore Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/manage-backup-restore). - Uninstall Runtime Fabric manually. See [Uninstall Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/uninstall-self). --- product: Runtime Fabric version: 2.6 --- # Managing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Anypoint Runtime Fabric, review the following topics: - [Viewing Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.6/view-health) Use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. - [Using RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl) Use the `rtfctl` command line tool to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can manage deployed Mule apps, protect Mule app values, and install and replace Mule license keys. - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.6/replace-license-key) Use the `rtfctl` command line tool to replace an expired Mule license key. - [Downgrading Runtime Fabric Version](https://docs.mulesoft.com/runtime-fabric/2.6/downgrade-runtime-fabric) Use the `rtfctl` command line tool or Helm to downgrade Runtime Fabric versions. - [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/migrate-helm) Migrate to Helm native for Runtime Fabrics that were installed using `rtfctl`. - [Enabling Forwarding When Using firewalld](https://docs.mulesoft.com/runtime-fabric/2.6/prereq-firewalld-forwarding) Enable forwarding on the docker device, if you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/setting-up-runtime-fabric) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.7 --- # Managing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Anypoint Runtime Fabric, review the following topics: - [Viewing Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.7/view-health) Use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. - [Using RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl) Use the `rtfctl` command line tool to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can manage deployed Mule apps, protect Mule app values, and install and replace Mule license keys. - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.7/replace-license-key) Use the `rtfctl` command line tool to replace an expired Mule license key. - [Downgrading Runtime Fabric Version](https://docs.mulesoft.com/runtime-fabric/2.7/downgrade-runtime-fabric) Use the `rtfctl` command line tool or Helm to downgrade Runtime Fabric versions. - [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/migrate-helm) Migrate to Helm native for Runtime Fabrics that were installed using `rtfctl`. - [Enabling Forwarding When Using firewalld](https://docs.mulesoft.com/runtime-fabric/2.7/prereq-firewalld-forwarding) Enable forwarding on the docker device, if you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/setting-up-runtime-fabric) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.8 --- # Managing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Anypoint Runtime Fabric, review the following topics: - [Viewing Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.8/view-health) Use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. - [Using RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) Use the `rtfctl` command line tool to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can manage deployed Mule apps, protect Mule app values, and install and replace Mule license keys. - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.8/replace-license-key) Use the `rtfctl` command line tool to replace an expired Mule license key. - [Downgrading Runtime Fabric Version](https://docs.mulesoft.com/runtime-fabric/2.8/downgrade-runtime-fabric) Use the `rtfctl` command line tool or Helm to downgrade Runtime Fabric versions. - [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/migrate-helm) Migrate to Helm native for Runtime Fabrics that were installed using `rtfctl`. - [Enabling Forwarding When Using firewalld](https://docs.mulesoft.com/runtime-fabric/2.8/prereq-firewalld-forwarding) Enable forwarding on the docker device, if you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/setting-up-runtime-fabric) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.9 --- # Managing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Anypoint Runtime Fabric, review the following topics: - [Viewing Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.9/view-health) Use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. - [Using RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl) Use the `rtfctl` command line tool to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can manage deployed Mule apps, protect Mule app values, and install and replace Mule license keys. - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.9/replace-license-key) Use the `rtfctl` command line tool to replace an expired Mule license key. - [Downgrading Runtime Fabric Version](https://docs.mulesoft.com/runtime-fabric/2.9/downgrade-runtime-fabric) Use the `rtfctl` command line tool or Helm to downgrade Runtime Fabric versions. - [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/migrate-helm) Migrate to Helm native for Runtime Fabrics that were installed using `rtfctl`. - [Enabling Forwarding When Using firewalld](https://docs.mulesoft.com/runtime-fabric/2.9/prereq-firewalld-forwarding) Enable forwarding on the docker device, if you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/setting-up-runtime-fabric) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/hardening-runtime-fabric) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Managing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To manage Anypoint Runtime Fabric, review the following topics: - [Viewing Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/latest/view-health) Use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. - [High Availability and Disaster Recovery](https://docs.mulesoft.com/runtime-fabric/latest/rtf-ha-dr) Design Runtime Fabric deployments to stay available during component failures and to recover from disasters while minimizing downtime and data loss. - [Using RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) Use the `rtfctl` command line tool to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can manage deployed Mule apps, protect Mule app values, and install and replace Mule license keys. - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/latest/replace-license-key) Use the `rtfctl` command line tool to replace an expired Mule license key. - [Downgrading Runtime Fabric Version](https://docs.mulesoft.com/runtime-fabric/latest/downgrade-runtime-fabric) Use the `rtfctl` command line tool or Helm to downgrade Runtime Fabric versions. - [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/migrate-helm) Migrate to Helm native for Runtime Fabrics that were installed using `rtfctl`. - [Enabling Forwarding When Using firewalld](https://docs.mulesoft.com/runtime-fabric/latest/prereq-firewalld-forwarding) Enable forwarding on the docker device, if you are using `firewalld` with a Red Hat Enterprise Linux (RHEL) 7.x operating system. ## See Also - [Setting Up Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/setting-up-runtime-fabric) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/hardening-runtime-fabric) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Managing the Agent Truststore with RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the `rtfctl agent-truststore` command group to inspect and update the certificate authority (CA) certificates that the Runtime Fabric agent uses to establish mutually authenticated TLS (mTLS) connections with the Anypoint Platform control plane. ## About the Agent Truststore The Runtime Fabric agent communicates outbound with several MuleSoft services hosted in the Anypoint Platform control plane: - Anypoint Runtime Manager: deploys and manages Mule apps and API gateways - Anypoint API Manager: applies and enforces API policies - Anypoint Monitoring: collects runtime metrics and telemetry - Configuration Resolver: provides Mule app bundles and configuration at deploy time Every one of these connections is protected by mTLS. The agent validates the server certificates against a set of trusted CA certificates stored in the agent truststore. ## Truststore Management Anypoint Platform control plane is backed by public CA root certificates, which are inherently long-lived and stable. Rotation of these certificates is infrequent. However, in cases where a rotation is required for security reasons, such as a CA compromise or a planned infrastructure change, add the new CA to the agent’s truststore before the old one is retired to maintain the mTLS connection between the Runtime Fabric agent and the control plane. The `rtfctl agent-truststore` commands provide these operations directly through `rtfctl`, without requiring any additional tooling. ## Commands
CommandDescription

Print a summary of the agent truststore and ca.pem

Download the PKCS#12 truststore from the cluster secret to a local file

Download the ca.pem bundle from the cluster secret to a local file

Add certificates from a PEM file into a local PKCS#12 truststore

Add certificates from one PEM file into another PEM bundle

Upload a local PKCS#12 truststore into the cluster secret

Upload a local PEM bundle into the cluster secret as ca.pem

Merge a PEM into the cluster truststore and ca.pem in one step

## `agent-truststore info` Prints a summary of the agent keystore secret, including all certificates loaded in the PKCS#12 truststore and ca.pem, along with their subjects, expiry dates, and days remaining. - Print a human-readable summary rtfctl agent-truststore info --namespace rtf - Print machine-readable JSON output rtfctl agent-truststore info -o json --namespace rtf ## `agent-truststore retrieve-agent-truststore` Downloads the `agent-truststore.p12` file from the cluster secret to a local file. The password is read automatically from the `truststore-password` key in the secret. rtfctl agent-truststore retrieve-agent-truststore -o agent-truststore-bk.p12 --namespace rtf - Override the secret name and the output file rtfctl agent-truststore retrieve-agent-truststore --secret agent-keystore -o agent-truststore-bk.p12 --namespace rtf ## `agent-truststore retrieve-ca-pem` Downloads the `ca.pem` bundle from the cluster secret to a local file. rtfctl agent-truststore retrieve-ca-pem -o ca-bk.pem --namespace rtf ## `agent-truststore merge-pem-into-p12` Adds the certificates from a PEM file into a local PKCS#12 truststore file (certificates-only format). Duplicate certificates are detected by subject and skipped. rtfctl agent-truststore merge-pem-into-p12 -i agent-truststore-bk.p12 -c new-ca.pem -o agent-truststore-new.p12 ## `agent-truststore merge-pem-into-pem` Merges certificates from one PEM file into another PEM bundle. Duplicate certificates are detected by subject and skipped. rtfctl agent-truststore merge-pem-into-pem -i ca-bk.pem -c new-ca.pem -o ca-new.pem ## `agent-truststore update-truststore-in-secret` Uploads a local PKCS#12 file into the agent keystore secret, replacing the `agent-truststore.p12` key. rtfctl agent-truststore update-truststore-in-secret -i agent-truststore-new.p12 --namespace rtf ## `agent-truststore update-ca-pem-in-secret` Uploads a local PEM bundle into the agent keystore secret, replacing the `ca.pem` key. rtfctl agent-truststore update-ca-pem-in-secret -i ca-new.pem --namespace rtf ## `agent-truststore refresh-secret-with-pem` Reads the current truststore and `ca.pem` from the cluster secret, merges the provided PEM into both, displays the certificate subjects to upload, and—after confirmation—patches the secret. Use `--yes` to skip the interactive prompts. - Interactive (asks for confirmation before each upload) rtfctl agent-truststore refresh-secret-with-pem -c new-ca.pem --namespace rtf - Non-interactive (suitable for automation) rtfctl agent-truststore refresh-secret-with-pem -c new-ca.pem --yes --namespace rtf ## Workflows ### Inspect the Current Truststore Before making changes, review which certificates are loaded and when they expire: rtfctl agent-truststore info --namespace rtf Use `-o json` to get machine-readable output suitable for scripting or CI checks. ### Add a New CA to the Truststore (Interactive) Use `refresh-secret-with-pem` to retrieve the current truststore from the cluster, merge a new PEM file into both the PKCS#12 and PEM stores, preview the result, and upload it back in a single step: rtfctl agent-truststore refresh-secret-with-pem -c new-ca.pem --namespace rtf The command prints the subjects of all certificates to upload and asks for confirmation before patching the secret. To skip the confirmation prompts (for example, in automation): rtfctl agent-truststore refresh-secret-with-pem -c new-ca.pem --yes --namespace rtf ### Add a New CA Manually If you prefer full control over each operation, or if you need to work with local files before uploading: 1. Download the current truststore and CA PEM from the cluster: rtfctl agent-truststore retrieve-agent-truststore -o agent-truststore-bk.p12 --namespace rtf rtfctl agent-truststore retrieve-ca-pem -o ca-bk.pem --namespace rtf 2. Merge the new CA certificates into the local files: rtfctl agent-truststore merge-pem-into-p12 -i agent-truststore-bk.p12 -c new-ca.pem -o agent-truststore-new.p12 rtfctl agent-truststore merge-pem-into-pem -i ca-bk.pem -c new-ca.pem -o ca-new.pem 3. Upload the updated files back to the cluster: rtfctl agent-truststore update-truststore-in-secret -i agent-truststore-new.p12 --namespace rtf rtfctl agent-truststore update-ca-pem-in-secret -i ca-new.pem --namespace rtf 4. Verify the result: rtfctl agent-truststore info --namespace rtf ## See Also - [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl-rtf) - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/latest/rtfctl-reference) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Migrate Log Forwarding Before Upgrading Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] If you are currently using the log forwarder DaemonSet, you must complete these steps > before upgrading Runtime Fabric to version 3.0.0. Failure to complete these steps may result in > log forwarding disruption. Starting with Runtime Fabric agent version 3.0.0, the DaemonSet-based log forwarding mechanism has been removed. Log forwarding now occurs exclusively through application sidecar containers, which provides better isolation, improved resource management, and simplified operations. If the log forwarder DaemonSet is running on your cluster, complete these steps before upgrading: 1. [Enable Application-Scoped Log Forwarding](#enable-app-scoped-log-forwarding) 2. [Redeploy Applications Using Legacy Log Forwarding](#redeploy-apps-legacy-log-forwarding) 3. [Remove the Log Forwarder DaemonSet](#remove-log-forwarder-daemonset) 4. [Verify Migration](#verify-log-forwarding-migration) ## Enable Application-Scoped Log Forwarding This setting is enabled by default on most Runtime Fabric instances. However, if it was previously disabled, you must re-enable it using the Runtime Fabric API: ```bash curl -X PATCH \ -H 'Authorization: Bearer {authToken}' \ -H 'Content-Type: application/json;charset=UTF-8' \ -H 'Accept: application/json, text/plain, */*' \ https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/fabrics/{fabricId}/logforwarding/appScoped?enabled=true ``` Replace `{authToken}`, `{orgId}`, and `{fabricId}` with your specific values. ## Redeploy Applications Using Legacy Log Forwarding All applications currently forwarding logs through the DaemonSet must be redeployed. This switches them to use the sidecar container for log forwarding. You can trigger a redeployment by making any update to the application in Runtime Manager, or by using the Runtime Manager API. ## Remove the Log Forwarder DaemonSet After all applications are using the new sidecar-based log forwarding, remove the legacy DaemonSet by calling the Runtime Fabric API: ```bash curl -X PATCH \ -H 'Authorization: Bearer {authToken}' \ -H 'Content-Type: application/json;charset=UTF-8' \ -H 'Accept: application/json, text/plain, */*' \ https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/fabrics/{fabricId}/logforwarding \ -d '{"anypointMonitoring": false}' ``` Replace `{authToken}`, `{orgId}`, and `{fabricId}` with your specific values. > [!NOTE] Disabling the DaemonSet doesn’t impact log forwarding to Anypoint Monitoring via the > sidecar containers. Your applications will continue to forward logs normally after completing > these steps. ## Verify Migration After completing the previous steps, verify that: - All applications are running and forwarding logs successfully - The `am-log-forwarder` DaemonSet is no longer present in your cluster - Application logs are visible in Anypoint Monitoring ## See Also - [Enable and Configure Log Forwarding](https://docs.mulesoft.com/runtime-fabric/latest/use-anypoint-monitoring#logs) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-index) --- product: Runtime Fabric version: 2.10 --- # Migrating to Helm Managed Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can migrate to [helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) native for Runtime Fabrics that were installed using [rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed). ## Before You Begin To perform the migration, you must consider the following: - The migration is applicable to BYOK clusters which are installed with `rtfctl` and want to migrate to helm managed. - The cluster must be on `rtf-agent` v2.2.5 or above. Note that you will first have to upgrade agent to the required version before you can initiate the migration. Additionally, you must have these details: - organizationId - fabricId - Bearer token for Anypoint user account with **manage fabric** privileges - rtfctl version >= v1.0.10 is downloaded ## Migrate rtfctl to Helm To migrate your Runtime Fabric from rtfctl to helm, run this command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` Running this command performs the following actions: - Backs up the current Runtime Fabric installation: tarball is created with input file name. - Uninstalls the current Runtime Fabric installation: running the command does not update Mule application deployments, it does not delete any of your configurations applied to the rtf namespace, it does not delete the rtf namespace, and it does not touch any other namespace than the rtf namespace. Uninstalls only the previous runtime-fabric helm chart. - Regenerates activation data for provided fabricId. - Deletes custom-properties secret in the rtf namespace, because helm managed rtf recreates the secret using values from the helm chart. - Installs Runtime Fabric with helm commands, to re-render Runtime Fabric helm chart. Running the command does not upgrade Runtime Fabric to the version other than the existing installation version. ### Command Success If running the command is successful: - You can verify that Runtime Fabric is now helm managed in the Anypoint Runtime Manager UI. - You can verify that configurations such as ingress templates, persistence gateway, custom resources and proxy values that you applied before the migration are intact. ### Command Fails If running the command fails: 1. Run `rftctl restore` command with the backup: ```copy rtfctl restore ``` 2. Re-try `rfctl migrate` command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` ## Command Help To get help with the command, run the following entry: ```copy rtfctl migrate –help ``` ## Add Annotations and Labels To add annotations or labels after the migration, run these commands: For annotations: ```copy kubectl annotate secret rtf-muleruntime-license -n rtf \ meta.helm.sh/release-name=runtime-fabric \ meta.helm.sh/release-namespace=rtf --overwrite ``` For labels: ```copy kubectl label secret rtf-muleruntime-license -n rtf \ app.kubernetes.io/managed-by=Helm --overwrite ``` --- product: Runtime Fabric version: 2.11 --- # Migrating to Helm Managed Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can migrate to [helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) native for Runtime Fabrics that were installed using [rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed). ## Before You Begin To perform the migration, you must consider this: - The migration is applicable to BYOK clusters which are installed with `rtfctl` and want to migrate to helm managed. - The cluster must be on `rtf-agent` v2.2.5 or above. Note that you will first have to upgrade agent to the required version before you can initiate the migration. Additionally, you must have these details: - organizationId - fabricId - Bearer token for Anypoint user account with **manage fabric** privileges - rtfctl version >= v1.0.10 is downloaded ## Migrate rtfctl to Helm To migrate your Runtime Fabric from rtfctl to helm, run this command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` Running this command performs these actions: - Backs up the current Runtime Fabric installation: tarball is created with input file name. - Uninstalls the current Runtime Fabric installation: running the command does not update Mule application deployments, it does not delete any of your configurations applied to the rtf namespace, it does not delete the rtf namespace, and it does not touch any other namespace than the rtf namespace. Uninstalls only the previous runtime-fabric helm chart. - Regenerates activation data for provided fabricId. - Deletes custom-properties secret in the rtf namespace, because helm managed rtf recreates the secret using values from the helm chart. - Installs Runtime Fabric with helm commands, to re-render Runtime Fabric helm chart. Running the command does not upgrade Runtime Fabric to the version other than the existing installation version. ### Command Success If running the command is successful: - You can verify that Runtime Fabric is now helm managed in the Anypoint Runtime Manager UI. - You can verify that configurations such as ingress templates, persistence gateway, custom resources and proxy values that you applied before the migration are intact. ### Command Fails If running the command fails: 1. Run `rftctl restore` command with the backup: ```copy rtfctl restore ``` 2. Re-try `rfctl migrate` command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` ## Command Help To get help with the command, run this entry: ```copy rtfctl migrate –help ``` ## Add Annotations and Labels To add annotations or labels after the migration, run these commands: For annotations: ```copy kubectl annotate secret rtf-muleruntime-license -n rtf \ meta.helm.sh/release-name=runtime-fabric \ meta.helm.sh/release-namespace=rtf --overwrite ``` For labels: ```copy kubectl label secret rtf-muleruntime-license -n rtf \ app.kubernetes.io/managed-by=Helm --overwrite ``` --- product: Runtime Fabric version: 2.5 --- # Migrating to Helm Managed Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can migrate to [helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) native for Runtime Fabrics that were installed using [rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed). ## Before You Begin To perform the migration, you must consider the following: - The migration is applicable to BYOK clusters which are installed with `rtfctl` and want to migrate to helm managed. - The cluster must be on `rtf-agent` v2.2.5 or above. Note that you will first have to upgrade agent to the required version before you can initiate the migration. Additionally, you must have these details: - organizationId - fabricId - Bearer token for Anypoint user account with **manage fabric** privileges - rtfctl version >= v1.0.10 is downloaded ## Migrate rtfctl to Helm To migrate your Runtime Fabric from rtfctl to helm, run this command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` Running this command performs the following actions: - Backs up the current Runtime Fabric installation: tarball is created with input file name. - Uninstalls the current Runtime Fabric installation: running the command does not update Mule application deployments, it does not delete any of your configurations applied to the rtf namespace, it does not delete the rtf namespace, and it does not touch any other namespace than the rtf namespace. Uninstalls only the previous runtime-fabric helm chart. - Regenerates activation data for provided fabricId. - Deletes custom-properties secret in the rtf namespace, because helm managed rtf recreates the secret using values from the helm chart. - Installs Runtime Fabric with helm commands, to re-render Runtime Fabric helm chart. Running the command does not upgrade Runtime Fabric to the version other than the existing installation version. ### Command Success If running the command is successful: - You can verify that Runtime Fabric is now helm managed in the Anypoint Runtime Manager UI. - You can verify that configurations such as ingress templates, persistence gateway, custom resources and proxy values that you applied before the migration are intact. ### Command Fails If running the command fails: 1. Run `rftctl restore` command with the backup: ```copy rtfctl restore ``` 2. Re-try `rfctl migrate` command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` ## Command Help To get help with the command, run the following entry: ```copy rtfctl migrate –help ``` --- product: Runtime Fabric version: 2.6 --- # Migrating to Helm Managed Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can migrate to [helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) native for Runtime Fabrics that were installed using [rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed). ## Before You Begin To perform the migration, you must consider the following: - The migration is applicable to BYOK clusters which are installed with `rtfctl` and want to migrate to helm managed. - The cluster must be on `rtf-agent` v2.2.5 or above. Note that you will first have to upgrade agent to the required version before you can initiate the migration. Additionally, you must have these details: - organizationId - fabricId - Bearer token for Anypoint user account with **manage fabric** privileges - rtfctl version >= v1.0.10 is downloaded ## Migrate rtfctl to Helm To migrate your Runtime Fabric from rtfctl to helm, run this command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` Running this command performs the following actions: - Backs up the current Runtime Fabric installation: tarball is created with input file name. - Uninstalls the current Runtime Fabric installation: running the command does not update Mule application deployments, it does not delete any of your configurations applied to the rtf namespace, it does not delete the rtf namespace, and it does not touch any other namespace than the rtf namespace. Uninstalls only the previous runtime-fabric helm chart. - Regenerates activation data for provided fabricId. - Deletes custom-properties secret in the rtf namespace, because helm managed rtf recreates the secret using values from the helm chart. - Installs Runtime Fabric with helm commands, to re-render Runtime Fabric helm chart. Running the command does not upgrade Runtime Fabric to the version other than the existing installation version. ### Command Success If running the command is successful: - You can verify that Runtime Fabric is now helm managed in the Anypoint Runtime Manager UI. - You can verify that configurations such as ingress templates, persistence gateway, custom resources and proxy values that you applied before the migration are intact. ### Command Fails If running the command fails: 1. Run `rftctl restore` command with the backup: ```copy rtfctl restore ``` 2. Re-try `rfctl migrate` command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` ## Command Help To get help with the command, run the following entry: ```copy rtfctl migrate –help ``` --- product: Runtime Fabric version: 2.7 --- # Migrating to Helm Managed Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can migrate to [helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) native for Runtime Fabrics that were installed using [rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed). ## Before You Begin To perform the migration, you must consider the following: - The migration is applicable to BYOK clusters which are installed with `rtfctl` and want to migrate to helm managed. - The cluster must be on `rtf-agent` v2.2.5 or above. Note that you will first have to upgrade agent to the required version before you can initiate the migration. Additionally, you must have these details: - organizationId - fabricId - Bearer token for Anypoint user account with **manage fabric** privileges - rtfctl version >= v1.0.10 is downloaded ## Migrate rtfctl to Helm To migrate your Runtime Fabric from rtfctl to helm, run this command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` Running this command performs the following actions: - Backs up the current Runtime Fabric installation: tarball is created with input file name. - Uninstalls the current Runtime Fabric installation: running the command does not update Mule application deployments, it does not delete any of your configurations applied to the rtf namespace, it does not delete the rtf namespace, and it does not touch any other namespace than the rtf namespace. Uninstalls only the previous runtime-fabric helm chart. - Regenerates activation data for provided fabricId. - Deletes custom-properties secret in the rtf namespace, because helm managed rtf recreates the secret using values from the helm chart. - Installs Runtime Fabric with helm commands, to re-render Runtime Fabric helm chart. Running the command does not upgrade Runtime Fabric to the version other than the existing installation version. ### Command Success If running the command is successful: - You can verify that Runtime Fabric is now helm managed in the Anypoint Runtime Manager UI. - You can verify that configurations such as ingress templates, persistence gateway, custom resources and proxy values that you applied before the migration are intact. ### Command Fails If running the command fails: 1. Run `rftctl restore` command with the backup: ```copy rtfctl restore ``` 2. Re-try `rfctl migrate` command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` ## Command Help To get help with the command, run the following entry: ```copy rtfctl migrate –help ``` --- product: Runtime Fabric version: 2.8 --- # Migrating to Helm Managed Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can migrate to [helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) native for Runtime Fabrics that were installed using [rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed). ## Before You Begin To perform the migration, you must consider the following: - The migration is applicable to BYOK clusters which are installed with `rtfctl` and want to migrate to helm managed. - The cluster must be on `rtf-agent` v2.2.5 or above. Note that you will first have to upgrade agent to the required version before you can initiate the migration. Additionally, you must have these details: - organizationId - fabricId - Bearer token for Anypoint user account with **manage fabric** privileges - rtfctl version >= v1.0.10 is downloaded ## Migrate rtfctl to Helm To migrate your Runtime Fabric from rtfctl to helm, run this command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` Running this command performs the following actions: - Backs up the current Runtime Fabric installation: tarball is created with input file name. - Uninstalls the current Runtime Fabric installation: running the command does not update Mule application deployments, it does not delete any of your configurations applied to the rtf namespace, it does not delete the rtf namespace, and it does not touch any other namespace than the rtf namespace. Uninstalls only the previous runtime-fabric helm chart. - Regenerates activation data for provided fabricId. - Deletes custom-properties secret in the rtf namespace, because helm managed rtf recreates the secret using values from the helm chart. - Installs Runtime Fabric with helm commands, to re-render Runtime Fabric helm chart. Running the command does not upgrade Runtime Fabric to the version other than the existing installation version. ### Command Success If running the command is successful: - You can verify that Runtime Fabric is now helm managed in the Anypoint Runtime Manager UI. - You can verify that configurations such as ingress templates, persistence gateway, custom resources and proxy values that you applied before the migration are intact. ### Command Fails If running the command fails: 1. Run `rftctl restore` command with the backup: ```copy rtfctl restore ``` 2. Re-try `rfctl migrate` command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` ## Command Help To get help with the command, run the following entry: ```copy rtfctl migrate –help ``` ## Add Annotations and Labels To add annotations or labels after the migration, run these commands: For annotations: ```copy kubectl annotate secret rtf-muleruntime-license -n rtf \ meta.helm.sh/release-name=runtime-fabric \ meta.helm.sh/release-namespace=rtf --overwrite ``` For labels: ```copy kubectl label secret rtf-muleruntime-license -n rtf \ app.kubernetes.io/managed-by=Helm --overwrite ``` --- product: Runtime Fabric version: 2.9 --- # Migrating to Helm Managed Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can migrate to [helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) native for Runtime Fabrics that were installed using [rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed). ## Before You Begin To perform the migration, you must consider the following: - The migration is applicable to BYOK clusters which are installed with `rtfctl` and want to migrate to helm managed. - The cluster must be on `rtf-agent` v2.2.5 or above. Note that you will first have to upgrade agent to the required version before you can initiate the migration. Additionally, you must have these details: - organizationId - fabricId - Bearer token for Anypoint user account with **manage fabric** privileges - rtfctl version >= v1.0.10 is downloaded ## Migrate rtfctl to Helm To migrate your Runtime Fabric from rtfctl to helm, run this command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` Running this command performs the following actions: - Backs up the current Runtime Fabric installation: tarball is created with input file name. - Uninstalls the current Runtime Fabric installation: running the command does not update Mule application deployments, it does not delete any of your configurations applied to the rtf namespace, it does not delete the rtf namespace, and it does not touch any other namespace than the rtf namespace. Uninstalls only the previous runtime-fabric helm chart. - Regenerates activation data for provided fabricId. - Deletes custom-properties secret in the rtf namespace, because helm managed rtf recreates the secret using values from the helm chart. - Installs Runtime Fabric with helm commands, to re-render Runtime Fabric helm chart. Running the command does not upgrade Runtime Fabric to the version other than the existing installation version. ### Command Success If running the command is successful: - You can verify that Runtime Fabric is now helm managed in the Anypoint Runtime Manager UI. - You can verify that configurations such as ingress templates, persistence gateway, custom resources and proxy values that you applied before the migration are intact. ### Command Fails If running the command fails: 1. Run `rftctl restore` command with the backup: ```copy rtfctl restore ``` 2. Re-try `rfctl migrate` command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` ## Command Help To get help with the command, run the following entry: ```copy rtfctl migrate –help ``` ## Add Annotations and Labels To add annotations or labels after the migration, run these commands: For annotations: ```copy kubectl annotate secret rtf-muleruntime-license -n rtf \ meta.helm.sh/release-name=runtime-fabric \ meta.helm.sh/release-namespace=rtf --overwrite ``` For labels: ```copy kubectl label secret rtf-muleruntime-license -n rtf \ app.kubernetes.io/managed-by=Helm --overwrite ``` --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Migrating to Helm Managed Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can migrate to [helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) native for Runtime Fabrics that were installed using [rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed). ## Before You Begin To perform the migration, you must consider the following: - The migration is applicable to BYOK clusters which are installed with `rtfctl` and want to migrate to helm managed. - The cluster must be on `rtf-agent` v2.2.5 or above. Note that you will first have to upgrade agent to the required version before you can initiate the migration. Additionally, you must have these details: - organizationId - fabricId - Bearer token for Anypoint user account with **manage fabric** privileges - rtfctl version >= v1.0.10 is downloaded ## Migrate rtfctl to Helm To migrate your Runtime Fabric from rtfctl to helm, run this command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` Running this command performs the following actions: - Backs up the current Runtime Fabric installation: tarball is created with input file name. - Uninstalls the current Runtime Fabric installation: running the command does not update Mule application deployments, it does not delete any of your configurations applied to the rtf namespace, it does not delete the rtf namespace, and it does not touch any other namespace than the rtf namespace. Uninstalls only the previous runtime-fabric helm chart. - Regenerates activation data for provided fabricId. - Deletes custom-properties secret in the rtf namespace, because helm managed rtf recreates the secret using values from the helm chart. - Installs Runtime Fabric with helm commands, to re-render Runtime Fabric helm chart. Running the command does not upgrade Runtime Fabric to the version other than the existing installation version. ### Command Success If running the command is successful: - You can verify that Runtime Fabric is now helm managed in the Anypoint Runtime Manager UI. - You can verify that configurations such as ingress templates, persistence gateway, custom resources and proxy values that you applied before the migration are intact. ### Command Fails If running the command fails: 1. Run `rftctl restore` command with the backup: ```copy rtfctl restore ``` 2. Re-try `rfctl migrate` command: ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` ## Command Help To get help with the command, run the following entry: ```copy rtfctl migrate –help ``` ## Add Annotations and Labels To add annotations or labels after the migration, run these commands: For annotations: ```copy kubectl annotate secret rtf-muleruntime-license -n rtf \ meta.helm.sh/release-name=runtime-fabric \ meta.helm.sh/release-namespace=rtf --overwrite ``` For labels: ```copy kubectl label secret rtf-muleruntime-license -n rtf \ app.kubernetes.io/managed-by=Helm --overwrite ``` --- product: Runtime Fabric version: 2.10 --- # Monitoring Applications Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides customers with varying observability solutions depending on their needs. ## Anypoint Monitoring Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available, as described in [Using Anypoint Monitoring](https://docs.mulesoft.com/runtime-fabric/2.10/use-anypoint-monitoring). ## Export Telemetry Externally You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. For information about configuring `log4j2.xml`, refer to the [Use Log4j Appender](https://docs.mulesoft.com/runtime-fabric/2.10/use-log4j-appender) documentation. --- product: Runtime Fabric version: 2.11 --- # Monitoring Applications Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides customers with varying observability solutions depending on their needs. ## Anypoint Monitoring Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available, as described in [Using Anypoint Monitoring](https://docs.mulesoft.com/runtime-fabric/2.11/use-anypoint-monitoring). ## Export Telemetry Externally You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. For information about configuring `log4j2.xml`, refer to the [Use Log4j Appender](https://docs.mulesoft.com/runtime-fabric/2.11/use-log4j-appender) documentation. --- product: Runtime Fabric version: 2.5 --- # Monitoring Applications Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Applications and API gateways deployed to Runtime Fabric include native support for Anypoint Monitoring to allow viewing metrics within Anypoint Platform. > [!NOTE] Runtime Fabric does not provide support for integrating third-party monitoring solutions. ## Anypoint Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) includes tools that provide feedback from Mule flows and components in your application network. Anypoint Monitoring runs as a sidecar in application deployments and gathers metrics for applications and API gateways deployed to Runtime Fabric. Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. ## Enable Anypoint Monitoring By default, Runtime Fabric is configured to send application metrics to Anypoint Monitoring. Data is securely transmitted using mutual TLS encryption. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available. If you need an outbound proxy, configure Anypoint Runtime Fabric to use a SOCKS5 proxy by following the instructions in [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/manage-proxy-self). To verify outbound network connectivity on Anypoint Runtime Fabric version 1.8.50 or later, ensure that each node in Runtime Fabric can send outbound TCP (Lumberjack) communication using port 443 to the following domains: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` > [!NOTE] If you are using a version of Anypoint Runtime Fabric older than 1.8.50, use port 5044 > instead of port 443. Use the following domains: > > - US control plane: `dias-ingestor-nginx.prod.cloudhub.io` > > - EU control plane: `dias-ingestor-nginx.prod-eu.msap.io` ## Disable Anypoint Monitoring for an Application When you deploy an application to Runtime Fabric, Anypoint Monitoring is enabled by default. To disable Anypoint Monitoring, pass the following custom property when deploying your application: ```copy anypoint.platform.config.analytics.agent.enabled=false ``` > [!NOTE] In some cases, logs with multiple lines might not be fully transmitted to Anypoint > Monitoring. This can occur if multiple lines of log output are split across two files due to log > rotation inside Runtime Fabric. > [!NOTE] Even though `anypoint.platform.config.analytics.agent.enabled` is set to false, it does > not eliminate the Anypoint Monitoring sidecar container. ## Metrics Each Mule application and API gateway replica runs a metrics agent that collects and transmits metrics data to Anypoint Monitoring via secure mutual TLS encryption. Each replica can cache up to 100 megabytes of metrics, after which the metrics data is rotated to provide storage for more recent data. In the event that metrics cannot be sent to Anypoint Monitoring, this typically provides at least 4 days worth of storage per replica. Note that custom metrics might consume more storage. > [!NOTE] Application monitoring metrics are not restored after: > > - A backup and restore of Runtime Fabric > > - An upgrade of Runtime Fabric > > - OS patching of Runtime Fabric nodes ## Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Rutime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Each Mule application and API gateway replica can store up to 450 megabytes of log data on disk, after which log data is rotated to provide storage for more recent log data. Logs generated by each replica of a Mule application and API gateway are collected and written to disk on the worker node on which they are running. Each worker node runs a single log forwarding agent, which monitors this location and transmits the log data to Anypoint Monitoring. > [!NOTE] The log forwarding agent can transmit up to 300 kilobytes of log data per second. You > should not deploy more than 50 replicas per worker node. You can enable log forwarding and set log levels when you [deploy applications in Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-to-runtime-fabric#configure-logging-and-log-levels). ### Anypoint Monitoring Log Forwarding Prerequisites The daemon-set that forwards logs to Anypoint Monitoring expects application containers to write logs to the following locations: - `/var/log/pods` - `/var/log/containers` - `/var/lib/docker/containers` The daemon-set also creates and writes on the host path `/var/lib/filebeat-data`. For log forwarding to work as expected, ensure that: - The Docker daemon config includes the `json-file` logging driver. - The Anypoint Monitoring log forwarder daemon-set container has write access to the host on the host path `/var/lib/filebeat-data`. ## Anypoint Visualizer [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/) displays views of different aspects of an application network graph. You can use the graph to explore your application network, identify problems, and make decisions. > [!WARNING] By default, Anypoint Visualizer is disabled when deploying an application to Mule > runtime 4.x. See [Enable Header Injection](https://docs.mulesoft.com/visualizer/setup#enable-header-injection) for > more information. > > Due to the impact on performance, enabling Anypoint Visualizer for application deployments with > less than 0.2 vCPU is not supported. --- product: Runtime Fabric version: 2.6 --- # Monitoring Applications Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides customers with varying observability solutions depending on their needs. ## Anypoint Monitoring Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available, as described in [Using Anypoint Monitoring](https://docs.mulesoft.com/runtime-fabric/2.6/use-anypoint-monitoring). ## Export Telemetry Externally You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. For information about configuring `log4j2.xml`, refer to the [Use Log4j Appender](https://docs.mulesoft.com/runtime-fabric/2.6/use-log4j-appender) documentation. --- product: Runtime Fabric version: 2.7 --- # Monitoring Applications Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides customers with varying observability solutions depending on their needs. ## Anypoint Monitoring Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available, as described in [Using Anypoint Monitoring](https://docs.mulesoft.com/runtime-fabric/2.7/use-anypoint-monitoring). ## Export Telemetry Externally You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. For information about configuring `log4j2.xml`, refer to the [Use Log4j Appender](https://docs.mulesoft.com/runtime-fabric/2.7/use-log4j-appender) documentation. --- product: Runtime Fabric version: 2.8 --- # Monitoring Applications Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides customers with varying observability solutions depending on their needs. ## Anypoint Monitoring Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available, as described in [Using Anypoint Monitoring](https://docs.mulesoft.com/runtime-fabric/2.8/use-anypoint-monitoring). ## Export Telemetry Externally You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. For information about configuring `log4j2.xml`, refer to the [Use Log4j Appender](https://docs.mulesoft.com/runtime-fabric/2.8/use-log4j-appender) documentation. --- product: Runtime Fabric version: 2.9 --- # Monitoring Applications Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides customers with varying observability solutions depending on their needs. ## Anypoint Monitoring Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available, as described in [Using Anypoint Monitoring](https://docs.mulesoft.com/runtime-fabric/2.9/use-anypoint-monitoring). ## Export Telemetry Externally You can export telemetry externally by using a Log4j appender to integrate your logging system with applications deployed to Runtime Fabric. For information about configuring `log4j2.xml`, refer to the [Use Log4j Appender](https://docs.mulesoft.com/runtime-fabric/2.9/use-log4j-appender) documentation. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Monitoring Applications Deployed to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides several observability options for Mule apps and API gateways. Use this table to determine which option suits your needs:
OptionDescriptionSubscriptionConfiguration

Anypoint Monitoring — metrics

CPU, memory, and throughput data for app replicas

All plans

Enabled by default. See Enable Anypoint Monitoring.

Anypoint Monitoring — logs

Application log search and retrieval in Anypoint Monitoring

Anypoint Platform Integration Advanced

See Enable and Configure Log Forwarding and Configure Logging and Log Levels.

Anypoint Monitoring — traces

Full transaction-path visibility using OpenTelemetry

Anypoint Platform Integration Advanced

See Enable Trace Data Collection.

External telemetry (Log4j)

Route logs to an external logging system using a Log4j appender

All plans

See Use Log4j Appender.

--- product: Runtime Fabric version: 2.10 --- # Mule App Deployments Kubernetes Permissions on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps deployed on the Runtime Fabric platform do not access the underlying Kubernetes API server. By default, Mule app deployments do not have RBAC configurations (`Role` and `Rolebindings`). However, if the Mule app use case requires K8s (Kubernetes) API access, you can override this behavior by enabling the `automountserviceaccounttoken` via customization CRD (custom resource definition) and attach a `Role` (customer-owned) with a `Rolebinding` (customer-owned) to the service account that Runtime Fabric core software creates per deployment. Refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.10/customize-kubernetes-crd). ## See Also - [Runtime Fabric Control Plane Permissions](https://docs.mulesoft.com/runtime-fabric/2.10/rtf-permissions) - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.10/rtfctl-permissions) - [Configuring Kubernetes for Runtime Fabric](#) --- product: Runtime Fabric version: 2.11 --- # Mule App Deployments Kubernetes Permissions on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps deployed on the Runtime Fabric platform do not access the underlying Kubernetes API server. By default, Mule app deployments do not have RBAC configurations (`Role` and `Rolebindings`). However, if the Mule app use case requires K8s (Kubernetes) API access, you can override this behavior by enabling the `automountserviceaccounttoken` via customization CRD (custom resource definition) and attach a `Role` (customer-owned) with a `Rolebinding` (customer-owned) to the service account that Runtime Fabric core software creates per deployment. Refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.11/customize-kubernetes-crd). ## See Also - [Runtime Fabric Control Plane Permissions](https://docs.mulesoft.com/runtime-fabric/2.11/rtf-permissions) - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.11/rtfctl-permissions) - [Configuring Kubernetes for Runtime Fabric](#) --- product: Runtime Fabric version: 2.6 --- # Mule App Deployments Kubernetes Permissions on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps deployed on the Runtime Fabric platform do not access the underlying Kubernetes API server. By default, Mule app deployments do not have RBAC configurations (`Role` and `Rolebindings`). However, if the Mule app use case requires K8s (Kubernetes) API access, you can override this behavior by enabling the `automountserviceaccounttoken` via customization CRD (custom resource definition) and attach a `Role` (customer-owned) with a `Rolebinding` (customer-owned) to the service account that Runtime Fabric core software creates per deployment. Refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.6/customize-kubernetes-crd). ## See Also - [Runtime Fabric Control Plane Permissions](https://docs.mulesoft.com/runtime-fabric/2.6/rtf-permissions) - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.6/rtfctl-permissions) - [Configuring Kubernetes for Runtime Fabric](#) --- product: Runtime Fabric version: 2.7 --- # Mule App Deployments Kubernetes Permissions on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps deployed on the Runtime Fabric platform do not access the underlying Kubernetes API server. By default, Mule app deployments do not have RBAC configurations (`Role` and `Rolebindings`). However, if the Mule app use case requires K8s (Kubernetes) API access, you can override this behavior by enabling the `automountserviceaccounttoken` via customization CRD (custom resource definition) and attach a `Role` (customer-owned) with a `Rolebinding` (customer-owned) to the service account that Runtime Fabric core software creates per deployment. Refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.7/customize-kubernetes-crd). ## See Also - [Runtime Fabric Control Plane Permissions](https://docs.mulesoft.com/runtime-fabric/2.7/rtf-permissions) - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.7/rtfctl-permissions) - [Configuring Kubernetes for Runtime Fabric](#) --- product: Runtime Fabric version: 2.8 --- # Mule App Deployments Kubernetes Permissions on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps deployed on the Runtime Fabric platform do not access the underlying Kubernetes API server. By default, Mule app deployments do not have RBAC configurations (`Role` and `Rolebindings`). However, if the Mule app use case requires K8s (Kubernetes) API access, you can override this behavior by enabling the `automountserviceaccounttoken` via customization CRD (custom resource definition) and attach a `Role` (customer-owned) with a `Rolebinding` (customer-owned) to the service account that Runtime Fabric core software creates per deployment. Refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.8/customize-kubernetes-crd). ## See Also - [Runtime Fabric Control Plane Permissions](https://docs.mulesoft.com/runtime-fabric/2.8/rtf-permissions) - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.8/rtfctl-permissions) - [Configuring Kubernetes for Runtime Fabric](#) --- product: Runtime Fabric version: 2.9 --- # Mule App Deployments Kubernetes Permissions on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps deployed on the Runtime Fabric platform do not access the underlying Kubernetes API server. By default, Mule app deployments do not have RBAC configurations (`Role` and `Rolebindings`). However, if the Mule app use case requires K8s (Kubernetes) API access, you can override this behavior by enabling the `automountserviceaccounttoken` via customization CRD (custom resource definition) and attach a `Role` (customer-owned) with a `Rolebinding` (customer-owned) to the service account that Runtime Fabric core software creates per deployment. Refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/2.9/customize-kubernetes-crd). ## See Also - [Runtime Fabric Control Plane Permissions](https://docs.mulesoft.com/runtime-fabric/2.9/rtf-permissions) - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.9/rtfctl-permissions) - [Configuring Kubernetes for Runtime Fabric](#) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Mule App Deployments Kubernetes Permissions on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps deployed on the Runtime Fabric platform do not access the underlying Kubernetes API server. By default, Mule app deployments do not have RBAC configurations (`Role` and `Rolebindings`). However, if the Mule app use case requires K8s (Kubernetes) API access, you can override this behavior by enabling the `automountserviceaccounttoken` via customization CRD (custom resource definition) and attach a `Role` (customer-owned) with a `Rolebinding` (customer-owned) to the service account that Runtime Fabric core software creates per deployment. Refer to [Customizing Mule App Kubernetes Resources](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd). ## See Also - [Runtime Fabric Control Plane Permissions](https://docs.mulesoft.com/runtime-fabric/latest/rtf-permissions) - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/latest/rtfctl-permissions) - [Configuring Kubernetes for Runtime Fabric](#) --- product: Runtime Fabric version: 2.10 --- # Preparing Your VM/Bare Metal Cluster for Runtime Fabric Installation > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft received customer feedback asking for rapid patching of high severity vulnerabilities in Kubernetes (K8s) and for MuleSoft to better leverage their existing K8s investments and operational practices. In response to this demand, MuleSoft partnered with industry-leading managed K8s platforms vendors such as AWS, Microsoft, Google and IBM. As a result, MuleSoft is proactively transitioning to deliver K8s to their customers via secure, highly available, and managed K8s platform from the above vendors and will stop investing in the black box approach of Runtime Fabric appliance in which you have found limited visibility and extensibility. Runtime Fabric is compatible with AWS, Google, Microsoft, and IBM RedHat Openshift solutions that deliver faster and consistent security patches. These integrations enable you to easily leverage existing investments in the Kubernetes ecosystem. Depending on your affinity to public clouds and in-house Kubernetes expertise, the following self-managed Red Hat OpenShift offerings can enable both on-premises and public cloud bare-metal solutions: - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) After you use one of these solutions to set up K8s on the cluster, proceed to the Runtime Fabric installation section to set up Runtime Fabric as you would install on an AKS or EKS. ## Change for Appliance Users Existing appliance utility users can migrate the licensed Core capacity currently allocated to a Runtime Fabric appliance deployment to any customer-hosted deployment option such as Runtime Fabric on public clouds, OpenShift, or Mule runtime standalone, subject to the total license limitations. Customers with Flexible Hybrid Deployment rights can also convert Cores to use vCores to utilize this capacity on CloudHub 2.0. ## Available Migration Options - If you are looking for an Integration Platform as a Service, [Cloudhub 2.0](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration) is the recommended offering. This Mulesoft flagship offering has the lowest operational overhead. - If you already have knowledge about public clouds and have some experience in managing a Kubernetes cluster, migrate to Runtime Fabric on public cloud Kubernetes clusters. The following clouds support Runtime Fabric: - [Runtime Fabric on AWS Elastics Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Runtime Fabric on AWS EKS-Anywhere](https://aws.amazon.com/eks/eks-anywhere/) - [Runtime Fabric on Google Kubernetes Engine](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Runtime Fabric on Microsoft Azure Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - To standardize your own bare-metal solutions using public Kubernetes distributions, follow [Runtime Fabric supported IBM Openshift offerings](https://www.youtube.com/watch?v=MYOeX5qjYew). These seven offerings include pre-built and certified assets, connectors, and operators, which enable both on-premises and public cloud bare-metal solutions. - Managed Cloud Services - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - Self-managed services - [RedHat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [RedHat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [RedHat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - If you don’t have investments in Kubernetes and must stay in your own hosted environment, Mule runtime standalone is an available option. This deployment model has reduced runtime resiliency and heavy management overhead. ## Actions Appliance Users Can Take Choose one of the previously mentioned options and migrate before the EOL deadlines. Review the [Product Versioning and Back Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf) for more details on Standard Support, Extended Support, and EOL support. --- product: Runtime Fabric version: 2.11 --- # Preparing Your VM/Bare Metal Cluster for Runtime Fabric Installation > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft received customer feedback asking for rapid patching of high severity vulnerabilities in Kubernetes (K8s) and for MuleSoft to better leverage their existing K8s investments and operational practices. In response to this demand, MuleSoft partnered with industry-leading managed K8s platforms vendors such as AWS, Microsoft, Google and IBM. As a result, MuleSoft is proactively transitioning to deliver K8s to their customers via secure, highly available, and managed K8s platform from the above vendors and will stop investing in the black box approach of Runtime Fabric appliance in which you have found limited visibility and extensibility. Runtime Fabric is compatible with AWS, Google, Microsoft, and IBM RedHat Openshift solutions that deliver faster and consistent security patches. These integrations enable you to easily leverage existing investments in the Kubernetes ecosystem. Depending on your affinity to public clouds and in-house Kubernetes expertise, these self-managed Red Hat OpenShift offerings can enable both on-premises and public cloud bare-metal solutions: - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) After you use one of these solutions to set up K8s on the cluster, proceed to the Runtime Fabric installation section to set up Runtime Fabric as you would install on an AKS or EKS. ## Change for Appliance Users Existing appliance utility users can migrate the licensed Core capacity currently allocated to a Runtime Fabric appliance deployment to any customer-hosted deployment option such as Runtime Fabric on public clouds, OpenShift, or Mule runtime standalone, subject to the total license limitations. Customers with Flexible Hybrid Deployment rights can also convert Cores to use vCores to utilize this capacity on CloudHub 2.0. ## Available Migration Options - If you are looking for an Integration Platform as a Service, [Cloudhub 2.0](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration) is the recommended offering. This Mulesoft flagship offering has the lowest operational overhead. - If you already have knowledge about public clouds and have some experience in managing a Kubernetes cluster, migrate to Runtime Fabric on public cloud Kubernetes clusters. These clouds support Runtime Fabric: - [Runtime Fabric on AWS Elastics Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Runtime Fabric on AWS EKS-Anywhere](https://aws.amazon.com/eks/eks-anywhere/) - [Runtime Fabric on Google Kubernetes Engine](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Runtime Fabric on Microsoft Azure Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - To standardize your own bare-metal solutions using public Kubernetes distributions, follow [Runtime Fabric supported IBM Openshift offerings](https://www.youtube.com/watch?v=MYOeX5qjYew). These seven offerings include pre-built and certified assets, connectors, and operators, which enable both on-premises and public cloud bare-metal solutions. - Managed Cloud Services - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - Self-managed services - [RedHat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [RedHat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [RedHat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - If you don’t have investments in Kubernetes and must stay in your own hosted environment, Mule runtime standalone is an available option. This deployment model has reduced runtime resiliency and heavy management overhead. ## Actions Appliance Users Can Take Choose one of the previously mentioned options and migrate before the EOL deadlines. Review the [Product Versioning and Back Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf) for more details on Standard Support, Extended Support, and EOL support. --- product: Runtime Fabric version: 2.5 --- # Preparing Your VM/Bare Metal Cluster for Runtime Fabric Installation > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft received customer feedback asking for rapid patching of high severity vulnerabilities in Kubernetes (K8s) and for MuleSoft to better leverage their existing K8s investments and operational practices. In response to this demand, MuleSoft partnered with industry-leading managed K8s platforms vendors such as AWS, Microsoft, Google and IBM. As a result, MuleSoft is proactively transitioning to deliver K8s to their customers via secure, highly available, and managed K8s platform from the above vendors and will stop investing in the black box approach of Runtime Fabric appliance in which you have found limited visibility and extensibility. Runtime Fabric is compatible with AWS, Google, Microsoft, and IBM RedHat Openshift solutions that deliver faster and consistent security patches. These integrations enable you to easily leverage existing investments in the Kubernetes ecosystem. Depending on your affinity to public clouds and in-house Kubernetes expertise, the following self-managed Red Hat OpenShift offerings can enable both on-premises and public cloud bare-metal solutions: - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) After you use one of these solutions to set up K8s on the cluster, proceed to the Runtime Fabric installation section to set up Runtime Fabric as you would install on an AKS or EKS. ## Change for Appliance Users Existing appliance utility users can migrate the licensed Core capacity currently allocated to a Runtime Fabric appliance deployment to any customer-hosted deployment option such as Runtime Fabric on public clouds, OpenShift, or Mule runtime standalone, subject to the total license limitations. Customers with Flexible Hybrid Deployment rights can also convert Cores to use vCores to utilize this capacity on CloudHub 2.0. ## Available Migration Options - If you are looking for an Integration Platform as a Service, [Cloudhub 2.0](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration) is the recommended offering. This Mulesoft flagship offering has the lowest operational overhead. - If you already have knowledge about public clouds and have some experience in managing a Kubernetes cluster, migrate to Runtime Fabric on public cloud Kubernetes clusters. The following clouds support Runtime Fabric: - [Runtime Fabric on AWS Elastics Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Runtime Fabric on AWS EKS-Anywhere](https://aws.amazon.com/eks/eks-anywhere/) - [Runtime Fabric on Google Kubernetes Engine](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Runtime Fabric on Microsoft Azure Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - To standardize your own bare-metal solutions using public Kubernetes distributions, follow [Runtime Fabric supported IBM Openshift offerings](https://www.youtube.com/watch?v=MYOeX5qjYew). These seven offerings include pre-built and certified assets, connectors, and operators, which enable both on-premises and public cloud bare-metal solutions. - Managed Cloud Services - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - Self-managed services - [RedHat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [RedHat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [RedHat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - If you don’t have investments in Kubernetes and must stay in your own hosted environment, Mule runtime standalone is an available option. This deployment model has reduced runtime resiliency and heavy management overhead. ## Actions Appliance Users Can Take Choose one of the previously mentioned options and migrate before the EOL deadlines. Review the [Product Versioning and Back Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf) for more details on Standard Support, Extended Support, and EOL support. --- product: Runtime Fabric version: 2.6 --- # Preparing Your VM/Bare Metal Cluster for Runtime Fabric Installation > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft received customer feedback asking for rapid patching of high severity vulnerabilities in Kubernetes (K8s) and for MuleSoft to better leverage their existing K8s investments and operational practices. In response to this demand, MuleSoft partnered with industry-leading managed K8s platforms vendors such as AWS, Microsoft, Google and IBM. As a result, MuleSoft is proactively transitioning to deliver K8s to their customers via secure, highly available, and managed K8s platform from the above vendors and will stop investing in the black box approach of Runtime Fabric appliance in which you have found limited visibility and extensibility. Runtime Fabric is compatible with AWS, Google, Microsoft, and IBM RedHat Openshift solutions that deliver faster and consistent security patches. These integrations enable you to easily leverage existing investments in the Kubernetes ecosystem. Depending on your affinity to public clouds and in-house Kubernetes expertise, the following self-managed Red Hat OpenShift offerings can enable both on-premises and public cloud bare-metal solutions: - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) After you use one of these solutions to set up K8s on the cluster, proceed to the Runtime Fabric installation section to set up Runtime Fabric as you would install on an AKS or EKS. ## Change for Appliance Users Existing appliance utility users can migrate the licensed Core capacity currently allocated to a Runtime Fabric appliance deployment to any customer-hosted deployment option such as Runtime Fabric on public clouds, OpenShift, or Mule runtime standalone, subject to the total license limitations. Customers with Flexible Hybrid Deployment rights can also convert Cores to use vCores to utilize this capacity on CloudHub 2.0. ## Available Migration Options - If you are looking for an Integration Platform as a Service, [Cloudhub 2.0](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration) is the recommended offering. This Mulesoft flagship offering has the lowest operational overhead. - If you already have knowledge about public clouds and have some experience in managing a Kubernetes cluster, migrate to Runtime Fabric on public cloud Kubernetes clusters. The following clouds support Runtime Fabric: - [Runtime Fabric on AWS Elastics Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Runtime Fabric on AWS EKS-Anywhere](https://aws.amazon.com/eks/eks-anywhere/) - [Runtime Fabric on Google Kubernetes Engine](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Runtime Fabric on Microsoft Azure Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - To standardize your own bare-metal solutions using public Kubernetes distributions, follow [Runtime Fabric supported IBM Openshift offerings](https://www.youtube.com/watch?v=MYOeX5qjYew). These seven offerings include pre-built and certified assets, connectors, and operators, which enable both on-premises and public cloud bare-metal solutions. - Managed Cloud Services - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - Self-managed services - [RedHat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [RedHat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [RedHat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - If you don’t have investments in Kubernetes and must stay in your own hosted environment, Mule runtime standalone is an available option. This deployment model has reduced runtime resiliency and heavy management overhead. ## Actions Appliance Users Can Take Choose one of the previously mentioned options and migrate before the EOL deadlines. Review the [Product Versioning and Back Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf) for more details on Standard Support, Extended Support, and EOL support. --- product: Runtime Fabric version: 2.7 --- # Preparing Your VM/Bare Metal Cluster for Runtime Fabric Installation > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft received customer feedback asking for rapid patching of high severity vulnerabilities in Kubernetes (K8s) and for MuleSoft to better leverage their existing K8s investments and operational practices. In response to this demand, MuleSoft partnered with industry-leading managed K8s platforms vendors such as AWS, Microsoft, Google and IBM. As a result, MuleSoft is proactively transitioning to deliver K8s to their customers via secure, highly available, and managed K8s platform from the above vendors and will stop investing in the black box approach of Runtime Fabric appliance in which you have found limited visibility and extensibility. Runtime Fabric is compatible with AWS, Google, Microsoft, and IBM RedHat Openshift solutions that deliver faster and consistent security patches. These integrations enable you to easily leverage existing investments in the Kubernetes ecosystem. Depending on your affinity to public clouds and in-house Kubernetes expertise, the following self-managed Red Hat OpenShift offerings can enable both on-premises and public cloud bare-metal solutions: - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) After you use one of these solutions to set up K8s on the cluster, proceed to the Runtime Fabric installation section to set up Runtime Fabric as you would install on an AKS or EKS. ## Change for Appliance Users Existing appliance utility users can migrate the licensed Core capacity currently allocated to a Runtime Fabric appliance deployment to any customer-hosted deployment option such as Runtime Fabric on public clouds, OpenShift, or Mule runtime standalone, subject to the total license limitations. Customers with Flexible Hybrid Deployment rights can also convert Cores to use vCores to utilize this capacity on CloudHub 2.0. ## Available Migration Options - If you are looking for an Integration Platform as a Service, [Cloudhub 2.0](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration) is the recommended offering. This Mulesoft flagship offering has the lowest operational overhead. - If you already have knowledge about public clouds and have some experience in managing a Kubernetes cluster, migrate to Runtime Fabric on public cloud Kubernetes clusters. The following clouds support Runtime Fabric: - [Runtime Fabric on AWS Elastics Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Runtime Fabric on AWS EKS-Anywhere](https://aws.amazon.com/eks/eks-anywhere/) - [Runtime Fabric on Google Kubernetes Engine](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Runtime Fabric on Microsoft Azure Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - To standardize your own bare-metal solutions using public Kubernetes distributions, follow [Runtime Fabric supported IBM Openshift offerings](https://www.youtube.com/watch?v=MYOeX5qjYew). These seven offerings include pre-built and certified assets, connectors, and operators, which enable both on-premises and public cloud bare-metal solutions. - Managed Cloud Services - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - Self-managed services - [RedHat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [RedHat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [RedHat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - If you don’t have investments in Kubernetes and must stay in your own hosted environment, Mule runtime standalone is an available option. This deployment model has reduced runtime resiliency and heavy management overhead. ## Actions Appliance Users Can Take Choose one of the previously mentioned options and migrate before the EOL deadlines. Review the [Product Versioning and Back Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf) for more details on Standard Support, Extended Support, and EOL support. --- product: Runtime Fabric version: 2.8 --- # Preparing Your VM/Bare Metal Cluster for Runtime Fabric Installation > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft received customer feedback asking for rapid patching of high severity vulnerabilities in Kubernetes (K8s) and for MuleSoft to better leverage their existing K8s investments and operational practices. In response to this demand, MuleSoft partnered with industry-leading managed K8s platforms vendors such as AWS, Microsoft, Google and IBM. As a result, MuleSoft is proactively transitioning to deliver K8s to their customers via secure, highly available, and managed K8s platform from the above vendors and will stop investing in the black box approach of Runtime Fabric appliance in which you have found limited visibility and extensibility. Runtime Fabric is compatible with AWS, Google, Microsoft, and IBM RedHat Openshift solutions that deliver faster and consistent security patches. These integrations enable you to easily leverage existing investments in the Kubernetes ecosystem. Depending on your affinity to public clouds and in-house Kubernetes expertise, the following self-managed Red Hat OpenShift offerings can enable both on-premises and public cloud bare-metal solutions: - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) After you use one of these solutions to set up K8s on the cluster, proceed to the Runtime Fabric installation section to set up Runtime Fabric as you would install on an AKS or EKS. ## Change for Appliance Users Existing appliance utility users can migrate the licensed Core capacity currently allocated to a Runtime Fabric appliance deployment to any customer-hosted deployment option such as Runtime Fabric on public clouds, OpenShift, or Mule runtime standalone, subject to the total license limitations. Customers with Flexible Hybrid Deployment rights can also convert Cores to use vCores to utilize this capacity on CloudHub 2.0. ## Available Migration Options - If you are looking for an Integration Platform as a Service, [Cloudhub 2.0](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration) is the recommended offering. This Mulesoft flagship offering has the lowest operational overhead. - If you already have knowledge about public clouds and have some experience in managing a Kubernetes cluster, migrate to Runtime Fabric on public cloud Kubernetes clusters. The following clouds support Runtime Fabric: - [Runtime Fabric on AWS Elastics Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Runtime Fabric on AWS EKS-Anywhere](https://aws.amazon.com/eks/eks-anywhere/) - [Runtime Fabric on Google Kubernetes Engine](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Runtime Fabric on Microsoft Azure Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - To standardize your own bare-metal solutions using public Kubernetes distributions, follow [Runtime Fabric supported IBM Openshift offerings](https://www.youtube.com/watch?v=MYOeX5qjYew). These seven offerings include pre-built and certified assets, connectors, and operators, which enable both on-premises and public cloud bare-metal solutions. - Managed Cloud Services - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - Self-managed services - [RedHat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [RedHat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [RedHat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - If you don’t have investments in Kubernetes and must stay in your own hosted environment, Mule runtime standalone is an available option. This deployment model has reduced runtime resiliency and heavy management overhead. ## Actions Appliance Users Can Take Choose one of the previously mentioned options and migrate before the EOL deadlines. Review the [Product Versioning and Back Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf) for more details on Standard Support, Extended Support, and EOL support. --- product: Runtime Fabric version: 2.9 --- # Preparing Your VM/Bare Metal Cluster for Runtime Fabric Installation > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft received customer feedback asking for rapid patching of high severity vulnerabilities in Kubernetes (K8s) and for MuleSoft to better leverage their existing K8s investments and operational practices. In response to this demand, MuleSoft partnered with industry-leading managed K8s platforms vendors such as AWS, Microsoft, Google and IBM. As a result, MuleSoft is proactively transitioning to deliver K8s to their customers via secure, highly available, and managed K8s platform from the above vendors and will stop investing in the black box approach of Runtime Fabric appliance in which you have found limited visibility and extensibility. Runtime Fabric is compatible with AWS, Google, Microsoft, and IBM RedHat Openshift solutions that deliver faster and consistent security patches. These integrations enable you to easily leverage existing investments in the Kubernetes ecosystem. Depending on your affinity to public clouds and in-house Kubernetes expertise, the following self-managed Red Hat OpenShift offerings can enable both on-premises and public cloud bare-metal solutions: - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) After you use one of these solutions to set up K8s on the cluster, proceed to the Runtime Fabric installation section to set up Runtime Fabric as you would install on an AKS or EKS. ## Change for Appliance Users Existing appliance utility users can migrate the licensed Core capacity currently allocated to a Runtime Fabric appliance deployment to any customer-hosted deployment option such as Runtime Fabric on public clouds, OpenShift, or Mule runtime standalone, subject to the total license limitations. Customers with Flexible Hybrid Deployment rights can also convert Cores to use vCores to utilize this capacity on CloudHub 2.0. ## Available Migration Options - If you are looking for an Integration Platform as a Service, [Cloudhub 2.0](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration) is the recommended offering. This Mulesoft flagship offering has the lowest operational overhead. - If you already have knowledge about public clouds and have some experience in managing a Kubernetes cluster, migrate to Runtime Fabric on public cloud Kubernetes clusters. The following clouds support Runtime Fabric: - [Runtime Fabric on AWS Elastics Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Runtime Fabric on AWS EKS-Anywhere](https://aws.amazon.com/eks/eks-anywhere/) - [Runtime Fabric on Google Kubernetes Engine](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Runtime Fabric on Microsoft Azure Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - To standardize your own bare-metal solutions using public Kubernetes distributions, follow [Runtime Fabric supported IBM Openshift offerings](https://www.youtube.com/watch?v=MYOeX5qjYew). These seven offerings include pre-built and certified assets, connectors, and operators, which enable both on-premises and public cloud bare-metal solutions. - Managed Cloud Services - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - Self-managed services - [RedHat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [RedHat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [RedHat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - If you don’t have investments in Kubernetes and must stay in your own hosted environment, Mule runtime standalone is an available option. This deployment model has reduced runtime resiliency and heavy management overhead. ## Actions Appliance Users Can Take Choose one of the previously mentioned options and migrate before the EOL deadlines. Review the [Product Versioning and Back Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf) for more details on Standard Support, Extended Support, and EOL support. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Preparing Your VM/Bare Metal Cluster for Runtime Fabric Installation > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft received customer feedback asking for rapid patching of high severity vulnerabilities in Kubernetes (K8s) and for MuleSoft to better leverage their existing K8s investments and operational practices. In response to this demand, MuleSoft partnered with industry-leading managed K8s platforms vendors such as AWS, Microsoft, Google and IBM. As a result, MuleSoft is proactively transitioning to deliver K8s to their customers via secure, highly available, and managed K8s platform from the above vendors and will stop investing in the black box approach of Runtime Fabric appliance in which you have found limited visibility and extensibility. Runtime Fabric is compatible with AWS, Google, Microsoft, and IBM RedHat Openshift solutions that deliver faster and consistent security patches. These integrations enable you to easily leverage existing investments in the Kubernetes ecosystem. Depending on your affinity to public clouds and in-house Kubernetes expertise, the following self-managed Red Hat OpenShift offerings can enable both on-premises and public cloud bare-metal solutions: - [Red Hat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) After you use one of these solutions to set up K8s on the cluster, proceed to the Runtime Fabric installation section to set up Runtime Fabric as you would install on an AKS, EKS, or OKE. ## Change for Appliance Users Existing appliance utility users can migrate the licensed Core capacity currently allocated to a Runtime Fabric appliance deployment to any customer-hosted deployment option such as Runtime Fabric on public clouds, OpenShift, or Mule runtime standalone, subject to the total license limitations. Customers with Flexible Hybrid Deployment rights can also convert Cores to use vCores to utilize this capacity on CloudHub 2.0. ## Available Migration Options - If you are looking for an Integration Platform as a Service, [Cloudhub 2.0](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration) is the recommended offering. This Mulesoft flagship offering has the lowest operational overhead. - If you already have knowledge about public clouds and have some experience in managing a Kubernetes cluster, migrate to Runtime Fabric on public cloud Kubernetes clusters. The following clouds support Runtime Fabric: - [Runtime Fabric on AWS Elastics Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Runtime Fabric on AWS EKS-Anywhere](https://aws.amazon.com/eks/eks-anywhere/) - [Runtime Fabric on Google Kubernetes Engine](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Runtime Fabric on Microsoft Azure Kubernetes Service](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Runtime Fabric on Oracle Kubernetes Engine](https://www.oracle.com/cloud/cloud-native/kubernetes-engine/) - To standardize your own bare-metal solutions using public Kubernetes distributions, follow [Runtime Fabric supported IBM Openshift offerings](https://www.youtube.com/watch?v=MYOeX5qjYew). These seven offerings include pre-built and certified assets, connectors, and operators, which enable both on-premises and public cloud bare-metal solutions. - Managed Cloud Services - [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [Red Hat OpenShift Dedicated on GCP](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/products/openshift) - Self-managed services - [RedHat OpenShift Kubernetes engine (Entry level)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [RedHat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [RedHat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - If you don’t have investments in Kubernetes and must stay in your own hosted environment, Mule runtime standalone is an available option. This deployment model has reduced runtime resiliency and heavy management overhead. ## Actions Appliance Users Can Take Choose one of the previously mentioned options and migrate before the EOL deadlines. Review the [Product Versioning and Back Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf) for more details on Standard Support, Extended Support, and EOL support. --- product: Runtime Fabric version: 2.5 --- # Protecting App Property Values with rtfctl > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Secure application properties are added in the Runtime Fabric cluster locally, stored securely, and scoped per environment. These properties are accessible in unencrypted form by Mule applications deployed in the scoped environment as custom properties. Runtime Fabric protected properties always take precedence over application-level properties. ## Install rtfctl The `rtfctl` utility is required to manage protected properties on Runtime Fabric locally. Follow the steps to [install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.5/install-rtfctl) before continuing with managing secure properties. ## Set Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to set a secure property to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****: The key for the secure property used in the Mule application to reference the value. - ****: The value for the secure property to store. - ****: The Anypoint environment to scope this secure property to. Only applications deployed to this environment have access to this secure property. - ****:System namespace scope, defaults to `rtf`. ## View Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to view the secure properties applied to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy ./rtfctl get secure-properties -n ``` - ****: The Anypoint environment ID to list the secure properties under. ## Access Secure Properties You can access secure properties from inside your Mule application using `${my.property.name}`. ## Remove Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to remove a secure property from the Runtime Fabric in a specific namespace: ```copy ./rtfctl delete secure-property -n ``` - ****: The key used in the Mule application to reference the secure property. - ****: The namespace in which the secure property applies. ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.5/install-rtfctl) - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/manage-proxy-self) --- product: Runtime Fabric version: 2.5 --- # Protecting Application Property Values in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric enables you to protect application property values by displaying the property name, but not its value, in Anypoint Runtime Manager. Additionally, a protected value is not viewable or retrievable by any user. Runtime Fabric resolves the property internally at runtime. These protected application values are encrypted and stored in the Anypoint Security secrets manager, which, in turn, is encrypted per user organization. Protected property values are separate from the encrypted Mule application properties that are stored in secure configuration files. See [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties). > [!NOTE] Runtime Manager does not support adding protected properties for API proxies or gateways. > Instead, use API Manager. > [!NOTE] Protecting API Gateway client ID and secret ID is currently supported in Runtime Fabric, > either via API or the Anypoint Runtime Manager UI. ## Protect Property Values in Runtime Manager Set protected properties via the table view for granular control over each property and value. Although you may attempt to protect a single property more than once, Runtime Manager issues a warning and only the final instance of that property is protected. 1. From Anypoint Platform, select Runtime Manager. 2. From the left menu, click **Applications**. 3. Click the application name. 4. On the **Settings** page, click the **Properties** tab. 5. Depending on how many properties you want to protect at once, take one of the following actions: - To protect properties one at a time, click **Table view**. - To protect multiple properties, use **Text view** to add the key-value pairs and then switch to **Table view**, and continue to Step 8. 6. In the **New Key** field, add a property to protect. 7. In the **New Value** field, add a value. ![Adding properties in table view](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-add-protected-properties.png) 8. Click **Protect** > **Protect value** to confirm. 9. Choose from one of the following: - If this application has already been deployed, click **Apply changes**. - If you’re ready to deploy the application, click **Deploy Application**. In the **Properties** tab, the values for properties that you just protected are now no longer visible to you or any other user. In the following example, the value for `dbPassword` is protected but those for `dbUsername` and `environment` are not: ![The value for dbpassword is shown as protected](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-view-protected-properties.png) After you commit the values and deploy the application, the protected property values don’t appear in the console and aren’t sent and received between the console and Runtime Manager. ## Replace a Protected Property Value After you protect a property value, you can’t retrieve it. However, you can replace the protected property value with a new protected value: 1. In the Table view, click the icon next to the protected value that you want to replace. 2. Click the menu icon next to the value and then click **Replace protected value**. 3. Enter a new value in the field 4. Click **Apply** > **Apply changes.** --- product: Runtime Fabric version: 2.8 --- # Protecting Mule App Property Values > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Secure application properties are added in the Runtime Fabric cluster locally, stored securely, and scoped per environment. These properties are accessible in unencrypted form by Mule applications deployed in the scoped environment as custom properties. Runtime Fabric protected properties always take precedence over application-level properties. > [!NOTE] Using secure properties outside of Runtime Manager is discouraged in favor of those > managed by Runtime Manager. ## Install rtfctl The `rtfctl` utility is required to manage protected properties on Runtime Fabric locally. Follow the steps to [install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) before continuing with managing secure properties. ## Set Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to set a secure property to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****: The key for the secure property used in the Mule application to reference the value. - ****: The value for the secure property to store. - ****: The Anypoint environment to scope this secure property to. Only applications deployed to this environment have access to this secure property. - ****:System namespace scope, defaults to `rtf`. ## View Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to view the secure properties applied to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy ./rtfctl get secure-properties -n ``` - ****: The Anypoint environment ID to list the secure properties under. ## Access Secure Properties You can access secure properties from inside your Mule application using `${my.property.name}`. ## Remove Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to remove a secure property from the Runtime Fabric in a specific namespace: ```copy ./rtfctl delete secure-property --app-namespace ``` - ****: The key used in the Mule application to reference the secure property. - ****: The namespace in which the secure property applies. ## Restore RTFCTL Managed Secure Properties `rtfctl` managed secure properties are directly configured in the cluster and are neither sent nor stored in the control plane. Due to this behavior, these secure properties are not included in the backup and restore process, so they need to be reapplied after restoration. For details, refer to [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-backup-restore). ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-proxy-self) --- product: Runtime Fabric version: 2.10 --- # Protecting Mule App Property Values in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to protect application property values by displaying the property name, but not its value, in Anypoint Runtime Manager. Additionally, a protected value is not viewable or retrievable by any user. Runtime Fabric resolves the property internally at runtime. These protected application values are encrypted and stored in the Anypoint Security secrets manager, which, in turn, is encrypted per user organization. Protected property values are separate from the encrypted Mule application properties that are stored in secure configuration files. See [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties). > [!NOTE] Runtime Manager does not support adding protected properties for API proxies or gateways. > Instead, use API Manager. > [!NOTE] Protecting API Gateway client ID and secret ID is currently supported in Runtime Fabric, > either via API or the Anypoint Runtime Manager UI. ## Protect Property Values in Runtime Manager Set protected properties via the table view for granular control over each property and value. Although you may attempt to protect a single property more than once, Runtime Manager issues a warning and only the final instance of that property is protected. 1. From Anypoint Platform, select Runtime Manager. 2. From the left menu, click **Applications**. 3. Click the application name. 4. On the **Settings** page, click the **Properties** tab. 5. Depending on how many properties you want to protect at once, take one of the following actions: - To protect properties one at a time, click **Table view**. - To protect multiple properties, use **Text view** to add the key-value pairs and then switch to **Table view**, and continue to Step 8. 6. In the **New Key** field, add a property to protect. 7. In the **New Value** field, add a value. ![Adding properties in table view](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-add-protected-properties.png) 8. Click **Protect** > **Protect value** to confirm. 9. Choose from one of the following: - If this application has already been deployed, click **Apply changes**. - If you’re ready to deploy the application, click **Deploy Application**. In the **Properties** tab, the values for properties that you just protected are now no longer visible to you or any other user. In the following example, the value for `dbPassword` is protected but those for `dbUsername` and `environment` are not: ![The value for dbpassword is shown as protected](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-view-protected-properties.png) After you commit the values and deploy the application, the protected property values don’t appear in the console and aren’t sent and received between the console and Runtime Manager. ## Replace a Protected Property Value After you protect a property value, you can’t retrieve it. However, you can replace the protected property value with a new protected value: 1. In the Table view, click the icon next to the protected value that you want to replace. 2. Click the menu icon next to the value and then click **Replace protected value**. 3. Enter a new value in the field 4. Click **Apply** > **Apply changes.** --- product: Runtime Fabric version: 2.11 --- # Protecting Mule App Property Values in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to protect application property values by displaying the property name, but not its value, in Anypoint Runtime Manager. Additionally, a protected value is not viewable or retrievable by any user. Runtime Fabric resolves the property internally at runtime. These protected application values are encrypted and stored in the Anypoint Security secrets manager, which, in turn, is encrypted per user organization. Protected property values are separate from the encrypted Mule application properties that are stored in secure configuration files. See [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties). > [!NOTE] Runtime Manager does not support adding protected properties for API proxies or gateways. > Instead, use API Manager. > [!NOTE] Protecting API Gateway client ID and secret ID is currently supported in Runtime Fabric, > either via API or the Anypoint Runtime Manager UI. ## Protect Property Values in Runtime Manager Set protected properties via the table view for granular control over each property and value. Although you may attempt to protect a single property more than once, Runtime Manager issues a warning and only the final instance of that property is protected. 1. From Anypoint Platform, select Runtime Manager. 2. From the left menu, click **Applications**. 3. Click the application name. 4. On the **Settings** page, click the **Properties** tab. 5. Depending on how many properties you want to protect at once, take one of these actions: - To protect properties one at a time, click **Table view**. - To protect multiple properties, use **Text view** to add the key-value pairs and then switch to **Table view**, and continue to Step 8. 6. In the **New Key** field, add a property to protect. 7. In the **New Value** field, add a value. ![Adding properties in table view](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-add-protected-properties.png) 8. Click **Protect** > **Protect value** to confirm. 9. Choose from one of these: - If this application has already been deployed, click **Apply changes**. - If you’re ready to deploy the application, click **Deploy Application**. In the **Properties** tab, the values for properties that you just protected are now no longer visible to you or any other user. In this example, the value for `dbPassword` is protected but those for `dbUsername` and `environment` are not: ![The value for dbpassword is shown as protected](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-view-protected-properties.png) After you commit the values and deploy the application, the protected property values don’t appear in the console and aren’t sent and received between the console and Runtime Manager. ## Replace a Protected Property Value After you protect a property value, you can’t retrieve it. However, you can replace the protected property value with a new protected value: 1. In the Table view, click the icon next to the protected value that you want to replace. 2. Click the menu icon next to the value and then click **Replace protected value**. 3. Enter a new value in the field 4. Click **Apply** > **Apply changes.** --- product: Runtime Fabric version: 2.6 --- # Protecting Mule App Property Values in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to protect application property values by displaying the property name, but not its value, in Anypoint Runtime Manager. Additionally, a protected value is not viewable or retrievable by any user. Runtime Fabric resolves the property internally at runtime. These protected application values are encrypted and stored in the Anypoint Security secrets manager, which, in turn, is encrypted per user organization. Protected property values are separate from the encrypted Mule application properties that are stored in secure configuration files. See [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties). > [!NOTE] Runtime Manager does not support adding protected properties for API proxies or gateways. > Instead, use API Manager. > [!NOTE] Protecting API Gateway client ID and secret ID is currently supported in Runtime Fabric, > either via API or the Anypoint Runtime Manager UI. ## Protect Property Values in Runtime Manager Set protected properties via the table view for granular control over each property and value. Although you may attempt to protect a single property more than once, Runtime Manager issues a warning and only the final instance of that property is protected. 1. From Anypoint Platform, select Runtime Manager. 2. From the left menu, click **Applications**. 3. Click the application name. 4. On the **Settings** page, click the **Properties** tab. 5. Depending on how many properties you want to protect at once, take one of the following actions: - To protect properties one at a time, click **Table view**. - To protect multiple properties, use **Text view** to add the key-value pairs and then switch to **Table view**, and continue to Step 8. 6. In the **New Key** field, add a property to protect. 7. In the **New Value** field, add a value. ![Adding properties in table view](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-add-protected-properties.png) 8. Click **Protect** > **Protect value** to confirm. 9. Choose from one of the following: - If this application has already been deployed, click **Apply changes**. - If you’re ready to deploy the application, click **Deploy Application**. In the **Properties** tab, the values for properties that you just protected are now no longer visible to you or any other user. In the following example, the value for `dbPassword` is protected but those for `dbUsername` and `environment` are not: ![The value for dbpassword is shown as protected](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-view-protected-properties.png) After you commit the values and deploy the application, the protected property values don’t appear in the console and aren’t sent and received between the console and Runtime Manager. ## Replace a Protected Property Value After you protect a property value, you can’t retrieve it. However, you can replace the protected property value with a new protected value: 1. In the Table view, click the icon next to the protected value that you want to replace. 2. Click the menu icon next to the value and then click **Replace protected value**. 3. Enter a new value in the field 4. Click **Apply** > **Apply changes.** --- product: Runtime Fabric version: 2.7 --- # Protecting Mule App Property Values in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to protect application property values by displaying the property name, but not its value, in Anypoint Runtime Manager. Additionally, a protected value is not viewable or retrievable by any user. Runtime Fabric resolves the property internally at runtime. These protected application values are encrypted and stored in the Anypoint Security secrets manager, which, in turn, is encrypted per user organization. Protected property values are separate from the encrypted Mule application properties that are stored in secure configuration files. See [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties). > [!NOTE] Runtime Manager does not support adding protected properties for API proxies or gateways. > Instead, use API Manager. > [!NOTE] Protecting API Gateway client ID and secret ID is currently supported in Runtime Fabric, > either via API or the Anypoint Runtime Manager UI. ## Protect Property Values in Runtime Manager Set protected properties via the table view for granular control over each property and value. Although you may attempt to protect a single property more than once, Runtime Manager issues a warning and only the final instance of that property is protected. 1. From Anypoint Platform, select Runtime Manager. 2. From the left menu, click **Applications**. 3. Click the application name. 4. On the **Settings** page, click the **Properties** tab. 5. Depending on how many properties you want to protect at once, take one of the following actions: - To protect properties one at a time, click **Table view**. - To protect multiple properties, use **Text view** to add the key-value pairs and then switch to **Table view**, and continue to Step 8. 6. In the **New Key** field, add a property to protect. 7. In the **New Value** field, add a value. ![Adding properties in table view](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-add-protected-properties.png) 8. Click **Protect** > **Protect value** to confirm. 9. Choose from one of the following: - If this application has already been deployed, click **Apply changes**. - If you’re ready to deploy the application, click **Deploy Application**. In the **Properties** tab, the values for properties that you just protected are now no longer visible to you or any other user. In the following example, the value for `dbPassword` is protected but those for `dbUsername` and `environment` are not: ![The value for dbpassword is shown as protected](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-view-protected-properties.png) After you commit the values and deploy the application, the protected property values don’t appear in the console and aren’t sent and received between the console and Runtime Manager. ## Replace a Protected Property Value After you protect a property value, you can’t retrieve it. However, you can replace the protected property value with a new protected value: 1. In the Table view, click the icon next to the protected value that you want to replace. 2. Click the menu icon next to the value and then click **Replace protected value**. 3. Enter a new value in the field 4. Click **Apply** > **Apply changes.** --- product: Runtime Fabric version: 2.8 --- # Protecting Mule App Property Values in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to protect application property values by displaying the property name, but not its value, in Anypoint Runtime Manager. Additionally, a protected value is not viewable or retrievable by any user. Runtime Fabric resolves the property internally at runtime. These protected application values are encrypted and stored in the Anypoint Security secrets manager, which, in turn, is encrypted per user organization. Protected property values are separate from the encrypted Mule application properties that are stored in secure configuration files. See [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties). > [!NOTE] Runtime Manager does not support adding protected properties for API proxies or gateways. > Instead, use API Manager. > [!NOTE] Protecting API Gateway client ID and secret ID is currently supported in Runtime Fabric, > either via API or the Anypoint Runtime Manager UI. ## Protect Property Values in Runtime Manager Set protected properties via the table view for granular control over each property and value. Although you may attempt to protect a single property more than once, Runtime Manager issues a warning and only the final instance of that property is protected. 1. From Anypoint Platform, select Runtime Manager. 2. From the left menu, click **Applications**. 3. Click the application name. 4. On the **Settings** page, click the **Properties** tab. 5. Depending on how many properties you want to protect at once, take one of the following actions: - To protect properties one at a time, click **Table view**. - To protect multiple properties, use **Text view** to add the key-value pairs and then switch to **Table view**, and continue to Step 8. 6. In the **New Key** field, add a property to protect. 7. In the **New Value** field, add a value. ![Adding properties in table view](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-add-protected-properties.png) 8. Click **Protect** > **Protect value** to confirm. 9. Choose from one of the following: - If this application has already been deployed, click **Apply changes**. - If you’re ready to deploy the application, click **Deploy Application**. In the **Properties** tab, the values for properties that you just protected are now no longer visible to you or any other user. In the following example, the value for `dbPassword` is protected but those for `dbUsername` and `environment` are not: ![The value for dbpassword is shown as protected](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-view-protected-properties.png) After you commit the values and deploy the application, the protected property values don’t appear in the console and aren’t sent and received between the console and Runtime Manager. ## Replace a Protected Property Value After you protect a property value, you can’t retrieve it. However, you can replace the protected property value with a new protected value: 1. In the Table view, click the icon next to the protected value that you want to replace. 2. Click the menu icon next to the value and then click **Replace protected value**. 3. Enter a new value in the field 4. Click **Apply** > **Apply changes.** --- product: Runtime Fabric version: 2.9 --- # Protecting Mule App Property Values in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to protect application property values by displaying the property name, but not its value, in Anypoint Runtime Manager. Additionally, a protected value is not viewable or retrievable by any user. Runtime Fabric resolves the property internally at runtime. These protected application values are encrypted and stored in the Anypoint Security secrets manager, which, in turn, is encrypted per user organization. Protected property values are separate from the encrypted Mule application properties that are stored in secure configuration files. See [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties). > [!NOTE] Runtime Manager does not support adding protected properties for API proxies or gateways. > Instead, use API Manager. > [!NOTE] Protecting API Gateway client ID and secret ID is currently supported in Runtime Fabric, > either via API or the Anypoint Runtime Manager UI. ## Protect Property Values in Runtime Manager Set protected properties via the table view for granular control over each property and value. Although you may attempt to protect a single property more than once, Runtime Manager issues a warning and only the final instance of that property is protected. 1. From Anypoint Platform, select Runtime Manager. 2. From the left menu, click **Applications**. 3. Click the application name. 4. On the **Settings** page, click the **Properties** tab. 5. Depending on how many properties you want to protect at once, take one of the following actions: - To protect properties one at a time, click **Table view**. - To protect multiple properties, use **Text view** to add the key-value pairs and then switch to **Table view**, and continue to Step 8. 6. In the **New Key** field, add a property to protect. 7. In the **New Value** field, add a value. ![Adding properties in table view](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-add-protected-properties.png) 8. Click **Protect** > **Protect value** to confirm. 9. Choose from one of the following: - If this application has already been deployed, click **Apply changes**. - If you’re ready to deploy the application, click **Deploy Application**. In the **Properties** tab, the values for properties that you just protected are now no longer visible to you or any other user. In the following example, the value for `dbPassword` is protected but those for `dbUsername` and `environment` are not: ![The value for dbpassword is shown as protected](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-view-protected-properties.png) After you commit the values and deploy the application, the protected property values don’t appear in the console and aren’t sent and received between the console and Runtime Manager. ## Replace a Protected Property Value After you protect a property value, you can’t retrieve it. However, you can replace the protected property value with a new protected value: 1. In the Table view, click the icon next to the protected value that you want to replace. 2. Click the menu icon next to the value and then click **Replace protected value**. 3. Enter a new value in the field 4. Click **Apply** > **Apply changes.** --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Protecting Mule App Property Values in Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to protect application property values by displaying the property name, but not its value, in Anypoint Runtime Manager. Additionally, a protected value is not viewable or retrievable by any user. Runtime Fabric resolves the property internally at runtime. These protected application values are encrypted and stored in the Anypoint Security secrets manager, which, in turn, is encrypted per user organization. Protected property values are separate from the encrypted Mule application properties that are stored in secure configuration files. See [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties). > [!NOTE] Runtime Manager does not support adding protected properties for API proxies or gateways. > Instead, use API Manager. > [!NOTE] Protecting API Gateway client ID and secret ID is currently supported in Runtime Fabric, > either via API or the Anypoint Runtime Manager UI. Watch this video to see how to protect property values by using Runtime Manager: ![](https://play.vidyard.com/r5qNAa7ZXFzVYPzkyb7z25.jpg) ## Protect Property Values in Runtime Manager Set protected properties via the table view for granular control over each property and value. Although you may attempt to protect a single property more than once, Runtime Manager issues a warning and only the final instance of that property is protected. 1. From Anypoint Platform, select Runtime Manager. 2. From the left menu, click **Applications**. 3. Click the application name. 4. On the **Settings** page, click the **Properties** tab. 5. Depending on how many properties you want to protect at once, take one of the following actions: - To protect properties one at a time, click **Table view**. - To protect multiple properties, use **Text view** to add the key-value pairs and then switch to **Table view**, and continue to Step 8. 6. In the **New Key** field, add a property to protect. 7. In the **New Value** field, add a value. ![Adding properties in table view](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-add-protected-properties.png) 8. Click **Protect** > **Protect value** to confirm. 9. Choose from one of the following: - If this application has already been deployed, click **Apply changes**. - If you’re ready to deploy the application, click **Deploy Application**. In the **Properties** tab, the values for properties that you just protected are now no longer visible to you or any other user. In the following example, the value for `dbPassword` is protected but those for `dbUsername` and `environment` are not: ![The value for dbpassword is shown as protected](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-view-protected-properties.png) After you commit the values and deploy the application, the protected property values don’t appear in the console and aren’t sent and received between the console and Runtime Manager. ## Replace a Protected Property Value After you protect a property value, you can’t retrieve it. However, you can replace the protected property value with a new protected value: 1. In the Table view, click the icon next to the protected value that you want to replace. 2. Click the menu icon next to the value and then click **Replace protected value**. 3. Enter a new value in the field 4. Click **Apply** > **Apply changes.** --- product: Runtime Fabric version: 2.10 --- # Protecting Mule App Property Values Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Secure application properties are added in the Runtime Fabric cluster locally, stored securely, and scoped per environment. These properties are accessible in unencrypted form by Mule applications deployed in the scoped environment as custom properties. Runtime Fabric protected properties always take precedence over application-level properties. ## Install rtfctl The `rtfctl` utility is required to manage protected properties on Runtime Fabric locally. Follow the steps to [install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl) before continuing with managing secure properties. ## Set Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to set a secure property to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****: The key for the secure property used in the Mule application to reference the value. - ****: The value for the secure property to store. - ****: The Anypoint environment to scope this secure property to. Only applications deployed to this environment have access to this secure property. - ****:System namespace scope, defaults to `rtf`. ## View Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to view the secure properties applied to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy ./rtfctl get secure-properties -n ``` - ****: The Anypoint environment ID to list the secure properties under. ## Access Secure Properties You can access secure properties from inside your Mule application using `$key`, which is the key provided in the `rtfctl apply` command. You can retrieve the key the same way you retrieve any other [configuration property](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties). ## Remove Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to remove a secure property from the Runtime Fabric in a specific namespace: ```copy ./rtfctl delete secure-property -n ``` - ****: The key used in the Mule application to reference the secure property. - ****: The namespace in which the secure property applies. ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl) - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/manage-proxy-self) --- product: Runtime Fabric version: 2.11 --- # Protecting Mule App Property Values Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Secure application properties are added in the Runtime Fabric cluster locally, stored securely, and scoped per environment. These properties are accessible in unencrypted form by Mule applications deployed in the scoped environment as custom properties. Runtime Fabric protected properties always take precedence over application-level properties. ## Install rtfctl The `rtfctl` utility is required to manage protected properties on Runtime Fabric locally. Follow the steps to [install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl) before continuing with managing secure properties. ## Set Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run this command to set a secure property to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****: The key for the secure property used in the Mule application to reference the value. - ****: The value for the secure property to store. - ****: The Anypoint environment to scope this secure property to. Only applications deployed to this environment have access to this secure property. - ****:System namespace scope, defaults to `rtf`. ## View Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run this command to view the secure properties applied to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy ./rtfctl get secure-properties -n ``` - ****: The Anypoint environment ID to list the secure properties under. ## Access Secure Properties You can access secure properties from inside your Mule application using `$key`, which is the key provided in the `rtfctl apply` command. You can retrieve the key the same way you retrieve any other [configuration property](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties). ## Remove Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run this command to remove a secure property from the Runtime Fabric in a specific namespace: ```copy ./rtfctl delete secure-property -n ``` - ****: The key used in the Mule application to reference the secure property. - ****: The namespace in which the secure property applies. ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl) - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/manage-proxy-self) --- product: Runtime Fabric version: 2.6 --- # Protecting Mule App Property Values Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Secure application properties are added in the Runtime Fabric cluster locally, stored securely, and scoped per environment. These properties are accessible in unencrypted form by Mule applications deployed in the scoped environment as custom properties. Runtime Fabric protected properties always take precedence over application-level properties. > [!NOTE] Using secure properties outside of Runtime Manager is discouraged in favor of those > managed by Runtime Manager. ## Install rtfctl The `rtfctl` utility is required to manage protected properties on Runtime Fabric locally. Follow the steps to [install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl) before continuing with managing secure properties. ## Set Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to set a secure property to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****: The key for the secure property used in the Mule application to reference the value. - ****: The value for the secure property to store. - ****: The Anypoint environment to scope this secure property to. Only applications deployed to this environment have access to this secure property. - ****:System namespace scope, defaults to `rtf`. ## View Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to view the secure properties applied to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy ./rtfctl get secure-properties -n ``` - ****: The Anypoint environment ID to list the secure properties under. ## Access Secure Properties You can access secure properties from inside your Mule application using `${my.property.name}`. ## Remove Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to remove a secure property from the Runtime Fabric in a specific namespace: ```copy ./rtfctl delete secure-property --app-namespace ``` - ****: The key used in the Mule application to reference the secure property. - ****: The namespace in which the secure property applies. ## Restore RTFCTL Managed Secure Properties `rtfctl` managed secure properties are directly configured in the cluster and are neither sent nor stored in the control plane. Due to this behavior, these secure properties are not included in the backup and restore process, so they need to be reapplied after restoration. For details, refer to [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/manage-backup-restore). ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl) - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/manage-proxy-self) --- product: Runtime Fabric version: 2.7 --- # Protecting Mule App Property Values Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Secure application properties are added in the Runtime Fabric cluster locally, stored securely, and scoped per environment. These properties are accessible in unencrypted form by Mule applications deployed in the scoped environment as custom properties. Runtime Fabric protected properties always take precedence over application-level properties. > [!NOTE] Using secure properties outside of Runtime Manager is discouraged in favor of those > managed by Runtime Manager. ## Install rtfctl The `rtfctl` utility is required to manage protected properties on Runtime Fabric locally. Follow the steps to [install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl) before continuing with managing secure properties. ## Set Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to set a secure property to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****: The key for the secure property used in the Mule application to reference the value. - ****: The value for the secure property to store. - ****: The Anypoint environment to scope this secure property to. Only applications deployed to this environment have access to this secure property. - ****:System namespace scope, defaults to `rtf`. ## View Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to view the secure properties applied to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy ./rtfctl get secure-properties -n ``` - ****: The Anypoint environment ID to list the secure properties under. ## Access Secure Properties You can access secure properties from inside your Mule application using `${my.property.name}`. ## Remove Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to remove a secure property from the Runtime Fabric in a specific namespace: ```copy ./rtfctl delete secure-property --app-namespace ``` - ****: The key used in the Mule application to reference the secure property. - ****: The namespace in which the secure property applies. ## Restore RTFCTL Managed Secure Properties `rtfctl` managed secure properties are directly configured in the cluster and are neither sent nor stored in the control plane. Due to this behavior, these secure properties are not included in the backup and restore process, so they need to be reapplied after restoration. For details, refer to [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/manage-backup-restore). ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl) - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/manage-proxy-self) --- product: Runtime Fabric version: 2.8 --- # Protecting Mule App Property Values Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Secure application properties are added in the Runtime Fabric cluster locally, stored securely, and scoped per environment. These properties are accessible in unencrypted form by Mule applications deployed in the scoped environment as custom properties. Runtime Fabric protected properties always take precedence over application-level properties. > [!NOTE] Using secure properties outside of Runtime Manager is discouraged in favor of those > managed by Runtime Manager. ## Install rtfctl The `rtfctl` utility is required to manage protected properties on Runtime Fabric locally. Follow the steps to [install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) before continuing with managing secure properties. ## Set Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to set a secure property to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****: The key for the secure property used in the Mule application to reference the value. - ****: The value for the secure property to store. - ****: The Anypoint environment to scope this secure property to. Only applications deployed to this environment have access to this secure property. - ****:System namespace scope, defaults to `rtf`. ## View Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to view the secure properties applied to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy ./rtfctl get secure-properties -n ``` - ****: The Anypoint environment ID to list the secure properties under. ## Access Secure Properties You can access secure properties from inside your Mule application using `${my.property.name}`. ## Remove Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to remove a secure property from the Runtime Fabric in a specific namespace: ```copy ./rtfctl delete secure-property --app-namespace ``` - ****: The key used in the Mule application to reference the secure property. - ****: The namespace in which the secure property applies. ## Restore RTFCTL Managed Secure Properties `rtfctl` managed secure properties are directly configured in the cluster and are neither sent nor stored in the control plane. Due to this behavior, these secure properties are not included in the backup and restore process, so they need to be reapplied after restoration. For details, refer to [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-backup-restore). ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-proxy-self) --- product: Runtime Fabric version: 2.9 --- # Protecting Mule App Property Values Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Secure application properties are added in the Runtime Fabric cluster locally, stored securely, and scoped per environment. These properties are accessible in unencrypted form by Mule applications deployed in the scoped environment as custom properties. Runtime Fabric protected properties always take precedence over application-level properties. ## Install rtfctl The `rtfctl` utility is required to manage protected properties on Runtime Fabric locally. Follow the steps to [install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl) before continuing with managing secure properties. ## Set Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to set a secure property to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****: The key for the secure property used in the Mule application to reference the value. - ****: The value for the secure property to store. - ****: The Anypoint environment to scope this secure property to. Only applications deployed to this environment have access to this secure property. - ****:System namespace scope, defaults to `rtf`. ## View Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to view the secure properties applied to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy ./rtfctl get secure-properties -n ``` - ****: The Anypoint environment ID to list the secure properties under. ## Access Secure Properties You can access secure properties from inside your Mule application using `${my.property.name}`. ## Remove Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to remove a secure property from the Runtime Fabric in a specific namespace: ```copy ./rtfctl delete secure-property -n ``` - ****: The key used in the Mule application to reference the secure property. - ****: The namespace in which the secure property applies. ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl) - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/manage-proxy-self) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Protecting Mule App Property Values Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Secure application properties are added in the Runtime Fabric cluster locally, stored securely, and scoped per environment. These properties are accessible in unencrypted form by Mule applications deployed in the scoped environment as custom properties. Runtime Fabric protected properties always take precedence over application-level properties. ## Install rtfctl The `rtfctl` utility is required to manage protected properties on Runtime Fabric locally. Follow the steps to [install rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) before continuing with managing secure properties. ## Set Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to set a secure property to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****: The key for the secure property used in the Mule application to reference the value. - ****: The value for the secure property to store. - ****: The actual namespace to scope this secure property to. Only applications deployed to this namespace have access to this secure property. - For [customized namespaces](https://docs.mulesoft.com/runtime-fabric/latest/create-custom-namespace), use the actual namespace name. - ****:System namespace scope, defaults to `rtf`. > [!NOTE] When applying secure properties to applications deployed in customized namespaces, you > must specify the actual namespace name in the `--app-namespace` parameter, not the environment ID > or the default namespace name. For example, if you created a customized namespace named > `my-custom-namespace`, use that name in the command: > > - > > ```copy > rtfctl apply secure-property --key test --value test --app-namespace my-custom-namespace --namespace rtf > ``` ## View Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to view the secure properties applied to the Runtime Fabric under a specific environment, substituting the placeholder fields: ```copy ./rtfctl get secure-properties -n ``` - ****: The Anypoint environment ID to list the secure properties under. ## Access Secure Properties You can access secure properties from inside your Mule application using `$key`, which is the key provided in the `rtfctl apply` command. You can retrieve the key the same way you retrieve any other [configuration property](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties). ## Remove Secure Properties 1. Log into a controller node where `rtfctl` is installed. 2. Run the following command to remove a secure property from the Runtime Fabric in a specific namespace: ```copy ./rtfctl delete secure-property -n ``` - ****: The key used in the Mule application to reference the secure property. - ****: The namespace in which the secure property applies. ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/manage-proxy-self) --- product: Runtime Fabric version: 2.10 --- # Replacing Mule License Keys > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When your Mule license expires, you must replace your Mule license key. Also use this procedure if you entered an incorrect license key during installation. Perform the following steps on the controller node used to start the installation. For Azure and AWS installations, this node is named `rtf-controller-1` by default. ## Install rtfctl The `rtfctl` utility is required to replace your Mule license key on Runtime Fabric. Follow the steps in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl) before continuing. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. Run `rtfctl` commands as a privileged user. ## Procedure 1. Base64 encode the new Mule `.lic` license file provided by MuleSoft: - On MacOS, run the following command in the terminal: ```copy BASE64_ENCODED_LICENSE=$(base64 -b0 -i license.lic) ``` - On Unix, run the following command: ```copy BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic) ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the `base64.exe` program included with Windows git (`C:\Program Files\Git\usr\bin`). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` 2. Use the `rtfctl` utility to apply the Base64 value of your license key. For more information on the `rtfctl` command, refer to [rtfctl commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands). ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` 3. To verify the Mule license key has applied correctly, retrieve the contents using the `rtfctl` utility: ```copy rtfctl get mule-license ``` > [!NOTE] You need to restart your Runtime Fabric Mule apps to take the latest changed license. ## Get License Expiry Date The `GET` fabric API `(/organizations/{organizationId}/fabrics/{id})` response includes an optional `licenseExpiryDate` field: { "id": "fabric\_id", "name": "anna-qa-gke-rtf-1", "region": "us-east-1", "vendor": "gke", "vendorMetadata": {}, "organizationId": "organization\_id", "version": "2.2.9", "status": "Active", "desiredVersion": "2.2.9", "availableUpgradeVersion": "2.2.29", "createdAt": 1679684859167, "secondsSinceHeartbeat": 192, "kubernetesVersion": "v1.24.11-gke.1000", "licenseExpiryDate": 1653523200000, "isManaged": false, "isHelmManaged": true, "clusterConfigurationLevel": "production", "features": { "enhancedSecurity": true, "persistentStore": false }, "ingress": { "domains": \[\] } } The Runtime Fabric **Mule License Expiry Date** is also exposed in the Runtime Manager UI, with a warning notification of **License is expiring soon**: ![Runtime Manager UI with Mule License Expiry Date warning notification](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-license-expiring.png) ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) --- product: Runtime Fabric version: 2.11 --- # Replacing Mule License Keys > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When your Mule license expires, you must replace your Mule license key. Also use this procedure if you entered an incorrect license key during installation. Perform these steps on the controller node used to start the installation. For Azure and AWS installations, this node is named `rtf-controller-1` by default. ## Install rtfctl The `rtfctl` utility is required to replace your Mule license key on Runtime Fabric. Follow the steps in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl) before continuing. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. Run `rtfctl` commands as a privileged user. ## Procedure 1. Base64 encode the new Mule `.lic` license file provided by MuleSoft: - On MacOS, run this command in the terminal: ```copy BASE64_ENCODED_LICENSE=$(base64 -b0 -i license.lic) ``` - On Unix, run this command: ```copy BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic) ``` - On Windows, choose one of these: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the `base64.exe` program included with Windows git (`C:\Program Files\Git\usr\bin`). - Use this Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` 2. Use the `rtfctl` utility to apply the Base64 value of your license key. For more information on the `rtfctl` command, refer to [rtfctl commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands). ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` 3. To verify the Mule license key has applied correctly, retrieve the contents using the `rtfctl` utility: ```copy rtfctl get mule-license ``` > [!NOTE] You need to restart your Runtime Fabric Mule apps to take the latest changed license. ## Get License Expiry Date The `GET` fabric API `(/organizations/{organizationId}/fabrics/{id})` response includes an optional `licenseExpiryDate` field: { "id": "fabric\_id", "name": "anna-qa-gke-rtf-1", "region": "us-east-1", "vendor": "gke", "vendorMetadata": {}, "organizationId": "organization\_id", "version": "2.2.9", "status": "Active", "desiredVersion": "2.2.9", "availableUpgradeVersion": "2.2.29", "createdAt": 1679684859167, "secondsSinceHeartbeat": 192, "kubernetesVersion": "v1.24.11-gke.1000", "licenseExpiryDate": 1653523200000, "isManaged": false, "isHelmManaged": true, "clusterConfigurationLevel": "production", "features": { "enhancedSecurity": true, "persistentStore": false }, "ingress": { "domains": \[\] } } The Runtime Fabric **Mule License Expiry Date** is also exposed in the Runtime Manager UI, with a warning notification of **License is expiring soon**: ![Runtime Manager UI with Mule License Expiry Date warning notification](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-license-expiring.png) ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) --- product: Runtime Fabric version: 2.5 --- # Replacing Mule License Keys > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When your Mule license expires, you must replace your Mule license key. Also use this procedure if you entered an incorrect license key during installation. Perform the following steps on the controller node used to start the installation. For Azure and AWS installations, this node is named `rtf-controller-1` by default. ## Install rtfctl The `rtfctl` utility is required to replace your Mule license key on Runtime Fabric. Follow the steps in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.5/install-rtfctl) before continuing. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. Run `rtfctl` commands as a privileged user. ## Procedure 1. Base64 encode the new Mule `.lic` license file provided by MuleSoft: - On MacOS, run the following command in the terminal: ```copy BASE64_ENCODED_LICENSE=$(base64 -b0 -i license.lic) ``` - On Unix, run the following command: ```copy BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic) ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the `base64.exe` program included with Windows git (`C:\Program Files\Git\usr\bin`). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` 2. Use the `rtfctl` utility to apply the Base64 value of your license key. For more information on the `rtfctl` command, refer to [rtfctl commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands). ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` 3. To verify the Mule license key has applied correctly, retrieve the contents using the `rtfctl` utility: ```copy rtfctl get mule-license ``` > [!NOTE] You need to restart your Runtime Fabric Mule apps to take the latest changed license. ## Get License Expiry Date The `GET` fabric API `(/organizations/{organizationId}/fabrics/{id})` response includes an optional `licenseExpiryDate` field: { "id": "fabric\_id", "name": "anna-qa-gke-rtf-1", "region": "us-east-1", "vendor": "gke", "vendorMetadata": {}, "organizationId": "organization\_id", "version": "2.2.9", "status": "Active", "desiredVersion": "2.2.9", "availableUpgradeVersion": "2.2.29", "createdAt": 1679684859167, "secondsSinceHeartbeat": 192, "kubernetesVersion": "v1.24.11-gke.1000", "licenseExpiryDate": 1653523200000, "isManaged": false, "isHelmManaged": true, "clusterConfigurationLevel": "production", "features": { "enhancedSecurity": true, "persistentStore": false }, "ingress": { "domains": \[\] } } The Runtime Fabric **Mule License Expiry Date** is also exposed in the Runtime Manager UI, with a warning notification of **License is expiring soon**: ![Runtime Manager UI with Mule License Expiry Date warning notification](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-license-expiring.png) ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) --- product: Runtime Fabric version: 2.6 --- # Replacing Mule License Keys > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When your Mule license expires, you must replace your Mule license key. Also use this procedure if you entered an incorrect license key during installation. Perform the following steps on the controller node used to start the installation. For Azure and AWS installations, this node is named `rtf-controller-1` by default. ## Install rtfctl The `rtfctl` utility is required to replace your Mule license key on Runtime Fabric. Follow the steps in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl) before continuing. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. Run `rtfctl` commands as a privileged user. ## Procedure 1. Base64 encode the new Mule `.lic` license file provided by MuleSoft: - On MacOS, run the following command in the terminal: ```copy BASE64_ENCODED_LICENSE=$(base64 -b0 -i license.lic) ``` - On Unix, run the following command: ```copy BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic) ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the `base64.exe` program included with Windows git (`C:\Program Files\Git\usr\bin`). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` 2. Use the `rtfctl` utility to apply the Base64 value of your license key. For more information on the `rtfctl` command, refer to [rtfctl commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands). ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` 3. To verify the Mule license key has applied correctly, retrieve the contents using the `rtfctl` utility: ```copy rtfctl get mule-license ``` > [!NOTE] You need to restart your Runtime Fabric Mule apps to take the latest changed license. ## Get License Expiry Date The `GET` fabric API `(/organizations/{organizationId}/fabrics/{id})` response includes an optional `licenseExpiryDate` field: { "id": "fabric\_id", "name": "anna-qa-gke-rtf-1", "region": "us-east-1", "vendor": "gke", "vendorMetadata": {}, "organizationId": "organization\_id", "version": "2.2.9", "status": "Active", "desiredVersion": "2.2.9", "availableUpgradeVersion": "2.2.29", "createdAt": 1679684859167, "secondsSinceHeartbeat": 192, "kubernetesVersion": "v1.24.11-gke.1000", "licenseExpiryDate": 1653523200000, "isManaged": false, "isHelmManaged": true, "clusterConfigurationLevel": "production", "features": { "enhancedSecurity": true, "persistentStore": false }, "ingress": { "domains": \[\] } } The Runtime Fabric **Mule License Expiry Date** is also exposed in the Runtime Manager UI, with a warning notification of **License is expiring soon**: ![Runtime Manager UI with Mule License Expiry Date warning notification](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-license-expiring.png) ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) --- product: Runtime Fabric version: 2.7 --- # Replacing Mule License Keys > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When your Mule license expires, you must replace your Mule license key. Also use this procedure if you entered an incorrect license key during installation. Perform the following steps on the controller node used to start the installation. For Azure and AWS installations, this node is named `rtf-controller-1` by default. ## Install rtfctl The `rtfctl` utility is required to replace your Mule license key on Runtime Fabric. Follow the steps in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl) before continuing. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. Run `rtfctl` commands as a privileged user. ## Procedure 1. Base64 encode the new Mule `.lic` license file provided by MuleSoft: - On MacOS, run the following command in the terminal: ```copy BASE64_ENCODED_LICENSE=$(base64 -b0 -i license.lic) ``` - On Unix, run the following command: ```copy BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic) ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the `base64.exe` program included with Windows git (`C:\Program Files\Git\usr\bin`). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` 2. Use the `rtfctl` utility to apply the Base64 value of your license key. For more information on the `rtfctl` command, refer to [rtfctl commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands). ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` 3. To verify the Mule license key has applied correctly, retrieve the contents using the `rtfctl` utility: ```copy rtfctl get mule-license ``` > [!NOTE] You need to restart your Runtime Fabric Mule apps to take the latest changed license. ## Get License Expiry Date The `GET` fabric API `(/organizations/{organizationId}/fabrics/{id})` response includes an optional `licenseExpiryDate` field: { "id": "fabric\_id", "name": "anna-qa-gke-rtf-1", "region": "us-east-1", "vendor": "gke", "vendorMetadata": {}, "organizationId": "organization\_id", "version": "2.2.9", "status": "Active", "desiredVersion": "2.2.9", "availableUpgradeVersion": "2.2.29", "createdAt": 1679684859167, "secondsSinceHeartbeat": 192, "kubernetesVersion": "v1.24.11-gke.1000", "licenseExpiryDate": 1653523200000, "isManaged": false, "isHelmManaged": true, "clusterConfigurationLevel": "production", "features": { "enhancedSecurity": true, "persistentStore": false }, "ingress": { "domains": \[\] } } The Runtime Fabric **Mule License Expiry Date** is also exposed in the Runtime Manager UI, with a warning notification of **License is expiring soon**: ![Runtime Manager UI with Mule License Expiry Date warning notification](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-license-expiring.png) ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) --- product: Runtime Fabric version: 2.8 --- # Replacing Mule License Keys > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When your Mule license expires, you must replace your Mule license key. Also use this procedure if you entered an incorrect license key during installation. Perform the following steps on the controller node used to start the installation. For Azure and AWS installations, this node is named `rtf-controller-1` by default. ## Install rtfctl The `rtfctl` utility is required to replace your Mule license key on Runtime Fabric. Follow the steps in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) before continuing. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. Run `rtfctl` commands as a privileged user. ## Procedure 1. Base64 encode the new Mule `.lic` license file provided by MuleSoft: - On MacOS, run the following command in the terminal: ```copy BASE64_ENCODED_LICENSE=$(base64 -b0 -i license.lic) ``` - On Unix, run the following command: ```copy BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic) ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the `base64.exe` program included with Windows git (`C:\Program Files\Git\usr\bin`). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` 2. Use the `rtfctl` utility to apply the Base64 value of your license key. For more information on the `rtfctl` command, refer to [rtfctl commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands). ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` 3. To verify the Mule license key has applied correctly, retrieve the contents using the `rtfctl` utility: ```copy rtfctl get mule-license ``` > [!NOTE] You need to restart your Runtime Fabric Mule apps to take the latest changed license. ## Get License Expiry Date The `GET` fabric API `(/organizations/{organizationId}/fabrics/{id})` response includes an optional `licenseExpiryDate` field: { "id": "fabric\_id", "name": "anna-qa-gke-rtf-1", "region": "us-east-1", "vendor": "gke", "vendorMetadata": {}, "organizationId": "organization\_id", "version": "2.2.9", "status": "Active", "desiredVersion": "2.2.9", "availableUpgradeVersion": "2.2.29", "createdAt": 1679684859167, "secondsSinceHeartbeat": 192, "kubernetesVersion": "v1.24.11-gke.1000", "licenseExpiryDate": 1653523200000, "isManaged": false, "isHelmManaged": true, "clusterConfigurationLevel": "production", "features": { "enhancedSecurity": true, "persistentStore": false }, "ingress": { "domains": \[\] } } The Runtime Fabric **Mule License Expiry Date** is also exposed in the Runtime Manager UI, with a warning notification of **License is expiring soon**: ![Runtime Manager UI with Mule License Expiry Date warning notification](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-license-expiring.png) ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) --- product: Runtime Fabric version: 2.9 --- # Replacing Mule License Keys > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When your Mule license expires, you must replace your Mule license key. Also use this procedure if you entered an incorrect license key during installation. Perform the following steps on the controller node used to start the installation. For Azure and AWS installations, this node is named `rtf-controller-1` by default. ## Install rtfctl The `rtfctl` utility is required to replace your Mule license key on Runtime Fabric. Follow the steps in [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl) before continuing. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. Run `rtfctl` commands as a privileged user. ## Procedure 1. Base64 encode the new Mule `.lic` license file provided by MuleSoft: - On MacOS, run the following command in the terminal: ```copy BASE64_ENCODED_LICENSE=$(base64 -b0 -i license.lic) ``` - On Unix, run the following command: ```copy BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic) ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the `base64.exe` program included with Windows git (`C:\Program Files\Git\usr\bin`). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` 2. Use the `rtfctl` utility to apply the Base64 value of your license key. For more information on the `rtfctl` command, refer to [rtfctl commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands). ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` 3. To verify the Mule license key has applied correctly, retrieve the contents using the `rtfctl` utility: ```copy rtfctl get mule-license ``` > [!NOTE] You need to restart your Runtime Fabric Mule apps to take the latest changed license. ## Get License Expiry Date The `GET` fabric API `(/organizations/{organizationId}/fabrics/{id})` response includes an optional `licenseExpiryDate` field: { "id": "fabric\_id", "name": "anna-qa-gke-rtf-1", "region": "us-east-1", "vendor": "gke", "vendorMetadata": {}, "organizationId": "organization\_id", "version": "2.2.9", "status": "Active", "desiredVersion": "2.2.9", "availableUpgradeVersion": "2.2.29", "createdAt": 1679684859167, "secondsSinceHeartbeat": 192, "kubernetesVersion": "v1.24.11-gke.1000", "licenseExpiryDate": 1653523200000, "isManaged": false, "isHelmManaged": true, "clusterConfigurationLevel": "production", "features": { "enhancedSecurity": true, "persistentStore": false }, "ingress": { "domains": \[\] } } The Runtime Fabric **Mule License Expiry Date** is also exposed in the Runtime Manager UI, with a warning notification of **License is expiring soon**: ![Runtime Manager UI with Mule License Expiry Date warning notification](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-license-expiring.png) ## See Also - [Install rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Replacing Mule License Keys > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When your Mule license expires, you must replace your Mule license key. Also use this procedure if you entered an incorrect license key during installation. The steps to replace the license key depend on how Runtime Fabric was installed using `rtfctl`, Helm, or Red Hat OpenShift. Perform the steps for your installation type in these sections. For `rtfctl`, perform the steps on the controller node used to start the installation. For Azure and AWS installations, this node is named `rtf-controller-1` by default. ## Prepare the License Key All methods require the Mule `.lic` license file to be Base64 encoded. Encode the new license file provided by MuleSoft before applying it: - On MacOS, run this command in the terminal: ```copy BASE64_ENCODED_LICENSE=$(base64 -b0 -i license.lic) ``` - On Unix, run this command: ```copy BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic) ``` - On Windows, choose one of the following: - Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command. - Use the `base64.exe` program included with Windows git (`C:\Program Files\Git\usr\bin`). - Use the following Powershell command: ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ## Replace Using `rtfctl` Use this method when Runtime Fabric was installed with `rtfctl` (VM, bare metal, or standard Kubernetes). ### Prerequisites The `rtfctl` utility is required. Follow the steps in [Install RTFCTL](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) before continuing. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. Run `rtfctl` commands as a privileged user. ### Procedure 1. Use the `rtfctl` utility to apply the Base64 value of your license key. For more information on the `rtfctl` command, refer to [RTFCTL commands](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands). ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` 2. To verify the Mule license key has been applied correctly, retrieve the contents using the `rtfctl` utility: ```copy rtfctl get mule-license ``` ## Replace Using Helm Use this method when Runtime Fabric was installed with Helm. Apply the license by running this command (ensure `$BASE64_ENCODED_LICENSE` is set from the Prepare the License Key section): ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` Replace `` with your current Runtime Fabric Helm chart version. ## Replace on Red Hat OpenShift Use this method when Runtime Fabric is installed on Red Hat OpenShift (operator-based installation). You can apply the license either from the OpenShift console (by updating the Runtime Fabric instance custom resource). Ensure you have prepared the Base64-encoded license key as described in Prepare the License Key. ### Apply the License Key from the OpenShift Console To apply the license key from the OpenShift console, follow these steps: 1. Navigate to the Runtime Fabric operator. 2. Select the namespace in which the Runtime Fabric instance is installed. 3. Click on the **Runtime Fabric** tab. 4. Click on the **runtime-fabric** instance link. ![Runtime Fabric operator with runtime-fabric instance selected](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-license-operator-1.png) 5. Update the Runtime Fabric instance CR .yaml file by adding the `muleLicense` key with your Base64-encoded license value. ![Runtime Fabric instance with mulelicense](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-license-operator-2.png) ## Get License Expiry Date The `GET` fabric API `(/organizations/{organizationId}/fabrics/{id})` response includes an optional `licenseExpiryDate` field: { "id": "fabric\_id", "name": "anna-qa-gke-rtf-1", "region": "us-east-1", "vendor": "gke", "vendorMetadata": {}, "organizationId": "organization\_id", "version": "2.2.9", "status": "Active", "desiredVersion": "2.2.9", "availableUpgradeVersion": "2.2.29", "createdAt": 1679684859167, "secondsSinceHeartbeat": 192, "kubernetesVersion": "v1.24.11-gke.1000", "licenseExpiryDate": 1653523200000, "isManaged": false, "isHelmManaged": true, "clusterConfigurationLevel": "production", "features": { "enhancedSecurity": true, "persistentStore": false }, "ingress": { "domains": \[\] } } The Runtime Fabric **Mule License Expiry Date** is also exposed in the Runtime Manager UI, with a warning notification of **License is expiring soon**: ![Runtime Manager UI with Mule License Expiry Date warning notification](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-license-expiring.png) ## See Also - [Install RTFCTL](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) - [Insert the Mule License Key](https://docs.mulesoft.com/runtime-fabric/latest/install-openshift#insert-the-mule-license-key) (OpenShift) - [Installing Runtime Fabric Using Helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm) --- product: Runtime Fabric version: 2.10 --- # Requirements and Limitations for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following requirements and limitations before installing, configuring, and managing Anypoint Runtime Fabric. ## MuleSoft License Compliance You are responsible for ensuring that you remain compliant with your MuleSoft licensing. To remain compliant, ensure one of the following: 1. The sum of CPU Limits allocated to each Mule application replica is less than or equal to the total license quantity. 2. The total CPU capacity provided by Runtime Fabric worker nodes running Mule applications is less than or equal to the licensed quantity. For Runtime Fabric usage reports, see [Runtime Fabric Compliance Tracking](https://docs.mulesoft.com/general/usage-metrics#rtf-compliance-tracking). ## Limitations The following table provides Runtime Fabric limitations.
LimitationDescription

Node types

VM-based nodes are required. For example, Fargate is not supported.

Replicas per application

The maximum number of replicas per application is 16. *

Associated environments per Runtime Fabric

You can associate a Runtime Fabric with up to 200 environments in any Business Group. For example, if you associate a development and a production environments with Org A and another development environment with Org B, that is three environment associations.

Business groups

You can create up to 50 Runtime Fabrics per org in a Business Group. Any sub org can contain up to 50 Runtime Fabrics, in addition to any shared with another sub org. For example, for a parent Org A and its child Org B, you can have 50 Runtime Fabrics in Org A and 50 in Org B. You can also share all 50 Runtime Fabrics from Org A with Org B, and as a result, you will see 100 Runtime Fabrics in total in the list view of Org B.

Runtime Fabric supports maximum 16 replicas per application in all forms except when the you use usage pricing and Horizontal Pod Autoscaling feature. In this case, the maximum number of replicas per application is still 8. ## Use of Third-Party Software within a Runtime Fabric K8s Cluster You are expected to use authorized namespaces features to ensure isolation between third-party software and Runtime Fabric software or Mule deployments. Install third-party software in non-rtf specific namespaces to ensure they do not interfere with Runtime Fabric or Mule runtime engine functionality. ## How Antivirus and DPI Software Impacts Runtime Fabric Functionality Anypoint Runtime Fabric has specific hardware and OS requirements. MuleSoft Support provides Support SLA and Severity Levels based on our validation and certification of the requirements specified in the installation prerequisites for [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/) . Some third-party software requires root access to the host. This software includes, but is not limited to, antivirus and DPI software, which has been found to interfere with the behavior and requirements of Runtime Fabric. In many support cases where MuleSoft Support has detected antivirus software, they have seen issues such as port blocking, node-to-node communication blocking, Docker default bridge deletion, and filesystem access issues that interfere with Runtime Fabric installation, upgrade, and normal operations. In the event that abnormal behavior is observed with Runtime Fabric, you may be asked to disable any running third-party software (including anti-virus or DPI software) to determine if it is the cause of the behavior. If disabling such software restores proper Runtime Fabric functionality, this would demonstrate an implicit incompatibility between that software package and Runtime Fabric, and we would consider the support case resolved. If you are strictly required to run traditional security tools that interfere with certain components of Runtime Fabric, vendors and security experts that support Kubernetes can support you in meeting this requirement. Cloud platform vendors often add cloud-centric controls that are consistent with well-known security benchmarks, such as the [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/). ## Requirements for Runtime Fabric The following descriptions provide you with the general requirements for running Anypoint Runtime Fabric. ### Kubernetes Support Runtime Fabric requires a Kubernetes cluster that is provisioned and operational. Verify whether your environment is correctly configured using the `rtfctl` command-line utility. See [Install Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-self-managed). Refer to the [release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the list of supported Kubernetes versions for your Runtime Fabric. ### Supported Architectures Anypoint Runtime Fabric requires worker nodes with the x86-64 architecture. ARM-based nodes are not supported. ### Operating Systems Anypoint Runtime Fabric works on any Linux distribution supported by: - Alibaba Cloud Container Service (ACK) - Amazon Elastics Kubernetes Service (EKS) - Amazon EKS Anywhere (EKS-A) - Google Kubernetes Engine (GKE) - Microsoft Azure Kubernetes Service (AKS) - Rancher Kubernetes Engine (RKE2) - Red Hat OpenShift - VMware Tanzu ### Nodes and Resources In general, you should follow the best practices provided by your Kubernetes vendor to ensure availability and simplify the administration of your infrastructure. To ensure optimal performance, Runtime Fabric installation requires at least two nodes each equipped with: - Minimum of two CPU cores - At least 15 GiB of RAM - At least 250 GiB of available disk space Adjust the number of nodes and amount of resources allocated according to the amount and type of workload you run on each Anypoint Runtime Fabric instance. ### Runtime Fabric Kubernetes Roles The following Runtime Fabric roles manage data stored in Kubernetes secrets: - `am-log-forwarder` - `rtf:agent` - `rtf:certificate-renewal` - `rtf-restricted` - `rtf:cluster-status` - `rtf:install` - `rtf:persistence-gateway-clro-read-only` - `rtf:upgrade` - `rtf:mule-clusterip-service` Runtime Fabric components, such as RTF agent, have a legitimate use case to consume the Kube API from the cluster where they are running to monitor or update some Kubernetes resources related to delivering Runtime Fabric features. ### Anypoint Platform Roles and Permissions To successfully use Anypoint Runtime Fabric, your Anypoint Platform account must have the following permissions: - To manage permissions for Anypoint Platform users, you must have the ability to use [Anypoint Access Management](https://docs.mulesoft.com/access-management/). - To deploy and manage applications ensure you have: - The ability to use Anypoint Runtime Manager - The Exchange Contributors permission enabled for your Anypoint Platform account - The read permissions for Applications and Runtime Fabric instances, which are needed to view applications on the Applications page in the Runtime Manager - To use Runtime Fabric, you must have the Organization Administrators permission or the Manage Runtime Fabrics permission for the corresponding environments. - To delete Runtime Fabric instances, administrators need the Manage Runtime Fabrics permission at the organization level. ### Network Configuration Anypoint Runtime Fabric requires an IT administrator to configure network ports, hostnames, and certificates to function correctly. See [Configuring Your Network to Support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-self-managed-network-configuration). ### Ingress Controller Runtime Fabric supports any ingress controller that works well in your Kubernetes environment. It also supports a deployment model with a dedicated ingress per application. Most off-the-shelf ingress controllers support this model. > [!IMPORTANT] The default behavior of the ingress controller included with GKE is to provide a > separate HTTP load balancer for each application. If you find this behavior undesirable, explore > possible solutions or consider using another ingress controller. ### Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. It is common practice for applications deployed on Runtime Fabric to log directly to `stdout`. The container runtime stores the console log in a file on disk. The storage location of this file depends on your container runtime and configuration. Refer to the documentation for your Kubernetes environment for details. ### External Log Forwarding Anypoint Runtime Fabric does not forward logs to an external system. You are responsible for installing and managing this configuration. Any external log forwarding agent compatible with your Kubernetes environment running on Amazon EKS, AKS, or GKE can be used. Commonly used log forwarding agents include: - Fluent Bit Runtime Fabric supports Log4j appenders. ### Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) provides metrics for applications and API gateways deployed to Runtime Fabric. To collect metrics, Anypoint Monitoring employs sidecar containers as part of each application deployment on Runtime Fabric. See [Monitor Applications Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/manage-monitor-applications) for details, including how to manage monitoring. Runtime Fabric does not provide support for integrating third-party monitoring solutions. --- product: Runtime Fabric version: 2.11 --- # Requirements and Limitations for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review these requirements and limitations before installing, configuring, and managing Anypoint Runtime Fabric. ## MuleSoft License Compliance You are responsible for ensuring that you remain compliant with your MuleSoft licensing. To remain compliant, ensure one of these: 1. The sum of CPU Limits allocated to each Mule application replica is less than or equal to the total license quantity. 2. The total CPU capacity provided by Runtime Fabric worker nodes running Mule applications is less than or equal to the licensed quantity. For Runtime Fabric usage reports, see [Runtime Fabric Compliance Tracking](https://docs.mulesoft.com/general/usage-metrics#rtf-compliance-tracking). ## Limitations The following table provides Runtime Fabric limitations.
LimitationDescription

Node types

VM-based nodes are required. For example, Fargate is not supported.

Replicas per application

The maximum number of replicas per application is 16. *

Associated environments per Runtime Fabric

You can associate a Runtime Fabric with up to 200 environments in any Business Group. For example, if you associate a development and a production environments with Org A and another development environment with Org B, that is three environment associations.

Business groups

You can create up to 50 Runtime Fabrics per org in a Business Group. Any sub org can contain up to 50 Runtime Fabrics, in addition to any shared with another sub org. For example, for a parent Org A and its child Org B, you can have 50 Runtime Fabrics in Org A and 50 in Org B. You can also share all 50 Runtime Fabrics from Org A with Org B, and as a result, you will see 100 Runtime Fabrics in total in the list view of Org B.

Runtime Fabric supports maximum 16 replicas per application in all forms except when the you use usage pricing and Horizontal Pod Autoscaling feature. In this case, the maximum number of replicas per application is still 8. ## Use of Third-Party Software within a Runtime Fabric K8s Cluster You are expected to use authorized namespaces features to ensure isolation between third-party software and Runtime Fabric software or Mule deployments. Install third-party software in non-rtf specific namespaces to ensure they do not interfere with Runtime Fabric or Mule runtime engine functionality. ## How Antivirus and DPI Software Impacts Runtime Fabric Functionality Anypoint Runtime Fabric has specific hardware and OS requirements. MuleSoft Support provides Support SLA and Severity Levels based on our validation and certification of the requirements specified in the installation prerequisites for [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/) . Some third-party software requires root access to the host. This software includes, but is not limited to, antivirus and DPI software, which has been found to interfere with the behavior and requirements of Runtime Fabric. In many support cases where MuleSoft Support has detected antivirus software, they have seen issues such as port blocking, node-to-node communication blocking, Docker default bridge deletion, and filesystem access issues that interfere with Runtime Fabric installation, upgrade, and normal operations. In the event that abnormal behavior is observed with Runtime Fabric, you may be asked to disable any running third-party software (including anti-virus or DPI software) to determine if it is the cause of the behavior. If disabling such software restores proper Runtime Fabric functionality, this would demonstrate an implicit incompatibility between that software package and Runtime Fabric, and we would consider the support case resolved. If you are strictly required to run traditional security tools that interfere with certain components of Runtime Fabric, vendors and security experts that support Kubernetes can support you in meeting this requirement. Cloud platform vendors often add cloud-centric controls that are consistent with well-known security benchmarks, such as the [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/). ## Requirements for Runtime Fabric The following descriptions provide you with the general requirements for running Anypoint Runtime Fabric. ### Kubernetes Support Runtime Fabric requires a Kubernetes cluster that is provisioned and operational. Verify whether your environment is correctly configured using the `rtfctl` command-line utility. See [Install Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-self-managed). Refer to the [release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the list of supported Kubernetes versions for your Runtime Fabric. ### Supported Architectures Anypoint Runtime Fabric requires worker nodes with the x86-64 architecture. ARM-based nodes are not supported. ### Operating Systems Anypoint Runtime Fabric works on any Linux distribution supported by: - Alibaba Cloud Container Service (ACK) - Amazon Elastics Kubernetes Service (EKS) - Amazon EKS Anywhere (EKS-A) - Google Kubernetes Engine (GKE) - Microsoft Azure Kubernetes Service (AKS) - Rancher Kubernetes Engine (RKE2) - Red Hat OpenShift - VMware Tanzu ### Nodes and Resources In general, you should follow the best practices provided by your Kubernetes vendor to ensure availability and simplify the administration of your infrastructure. To ensure optimal performance, Runtime Fabric installation requires at least two nodes each equipped with: - Minimum of two CPU cores - At least 15 GiB of RAM - At least 250 GiB of available disk space Adjust the number of nodes and amount of resources allocated according to the amount and type of workload you run on each Anypoint Runtime Fabric instance. ### Runtime Fabric Kubernetes Roles The following Runtime Fabric roles manage data stored in Kubernetes secrets: - `am-log-forwarder` - `rtf:agent` - `rtf:certificate-renewal` - `rtf-restricted` - `rtf:cluster-status` - `rtf:install` - `rtf:persistence-gateway-clro-read-only` - `rtf:upgrade` - `rtf:mule-clusterip-service` Runtime Fabric components, such as RTF agent, have a legitimate use case to consume the Kube API from the cluster where they are running to monitor or update some Kubernetes resources related to delivering Runtime Fabric features. ### Anypoint Platform Roles and Permissions To successfully use Anypoint Runtime Fabric, your Anypoint Platform account must have these permissions: - To manage permissions for Anypoint Platform users, you must have the ability to use [Anypoint Access Management](https://docs.mulesoft.com/access-management/). - To deploy and manage applications ensure you have: - The ability to use Anypoint Runtime Manager - The Exchange Contributors permission enabled for your Anypoint Platform account - The read permissions for Applications and Runtime Fabric instances, which are needed to view applications on the Applications page in the Runtime Manager > [!NOTE] For Runtime Fabric, the **Create application** permission in Runtime Manager is > required for PUT/PATCH application API calls. The **Manage Application Data** and **Manage > Settings** permissions apply only to CloudHub and are not available for Runtime Fabric or > CloudHub 2.0. - To use Runtime Fabric, you must have the Organization Administrators permission or the Manage Runtime Fabrics permission for the corresponding environments. - To delete Runtime Fabric instances, administrators need the Manage Runtime Fabrics permission at the organization level. ### Network Configuration Anypoint Runtime Fabric requires an IT administrator to configure network ports, hostnames, and certificates to function correctly. See [Configuring Your Network to Support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-self-managed-network-configuration). ### Ingress Controller Runtime Fabric supports any ingress controller that works well in your Kubernetes environment. It also supports a deployment model with a dedicated ingress per application. Most off-the-shelf ingress controllers support this model. > [!IMPORTANT] The default behavior of the ingress controller included with GKE is to provide a > separate HTTP load balancer for each application. If you find this behavior undesirable, explore > possible solutions or consider using another ingress controller. ### Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. It is common practice for applications deployed on Runtime Fabric to log directly to `stdout`. The container runtime stores the console log in a file on disk. The storage location of this file depends on your container runtime and configuration. Refer to the documentation for your Kubernetes environment for details. ### External Log Forwarding Anypoint Runtime Fabric does not forward logs to an external system. You are responsible for installing and managing this configuration. Any external log forwarding agent compatible with your Kubernetes environment running on Amazon EKS, AKS, or GKE can be used. Commonly used log forwarding agents include: - Fluentbit Runtime Fabric supports Log4j appenders. ### Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) provides metrics for applications and API gateways deployed to Runtime Fabric. To collect metrics, Anypoint Monitoring employs sidecar containers as part of each application deployment on Runtime Fabric. See [Monitor Applications Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/manage-monitor-applications) for details, including how to manage monitoring. Runtime Fabric does not provide support for integrating third-party monitoring solutions. --- product: Runtime Fabric version: 2.5 --- # Requirements and Limitations for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following requirements and limitations before installing, configuring, and managing Anypoint Runtime Fabric. ## Limitations The following table provides Runtime Fabric limitations.
LimitationDescription

Node types

VM-based nodes are required. For example, Fargate is not supported.

Replicas per application

The maximum number of replicas per application is 8.

Associated environments per Runtime Fabric

You can associate a Runtime Fabric with up to 200 environments in any Business Group. For example, if you associate a development and a production environments with Org A and another development environment with Org B, that is three environment associations.

Business groups

You can create up to 50 Runtime Fabrics per org in a Business Group. Any sub org can contain up to 50 Runtime Fabrics, in addition to any shared with another sub org. For example, for a parent Org A and its child Org B, you can have 50 Runtime Fabrics in Org A and 50 in Org B. You can also share all 50 Runtime Fabrics from Org A with Org B, and as a result, you will see 100 Runtime Fabrics in total in the list view of Org B.

## Use of Third-Party Software within a Runtime Fabric K8s Cluster You are expected to use authorized namespaces features to ensure isolation between third-party software and Runtime Fabric software or Mule deployments. Install third-party software in non-rtf specific namespaces to ensure they do not interfere with Runtime Fabric or Mule runtime engine functionality. ## How Antivirus and DPI Software Impacts Runtime Fabric Functionality Anypoint Runtime Fabric has specific hardware and OS requirements. MuleSoft Support provides Support SLA and Severity Levels based on our validation and certification of the requirements specified in the installation prerequisites for [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/) . Some third-party software requires root access to the host. This software includes, but is not limited to, antivirus and DPI software, which has been found to interfere with the behavior and requirements of Runtime Fabric. In many support cases where MuleSoft Support has detected antivirus software, they have seen issues such as port blocking, node-to-node communication blocking, Docker default bridge deletion, and filesystem access issues that interfere with Runtime Fabric installation, upgrade, and normal operations. In the event that abnormal behavior is observed with Runtime Fabric, you may be asked to disable any running third-party software (including anti-virus or DPI software) to determine if it is the cause of the behavior. If disabling such software restores proper Runtime Fabric functionality, this would demonstrate an implicit incompatibility between that software package and Runtime Fabric, and we would consider the support case resolved. If you are strictly required to run traditional security tools that interfere with certain components of Runtime Fabric, vendors and security experts that support Kubernetes can support you in meeting this requirement. Cloud platform vendors often add cloud-centric controls that are consistent with well-known security benchmarks, such as the [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/). ## Requirements for Runtime Fabric The following descriptions provide you with the general requirements for running Anypoint Runtime Fabric. ### Kubernetes Support Runtime Fabric requires a Kubernetes cluster that is provisioned and operational. Verify whether your environment is correctly configured using the `rtfctl` command-line utility. See [Install Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/install-self-managed). Refer to the [release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the list of supported Kubernetes versions for your Runtime Fabric. ### Supported Architectures Anypoint Runtime Fabric requires worker nodes with the x86-64 architecture. ARM-based nodes are not supported. ### Operating Systems Anypoint Runtime Fabric works on any Linux distribution supported by Amazon EKS, AKS, GKE, or RedHat OpenShift. ### Nodes and Resources In general, you should follow the best practices provided by your Kubernetes vendor to ensure availability and simplify the administration of your infrastructure. To ensure optimal performance, Runtime Fabric installation requires at least two nodes each equipped with: - Minimum of two CPU cores - At least 15 GiB of RAM - At least 250 GiB of available disk space Adjust the number of nodes and amount of resources allocated according to the amount and type of workload you run on each Anypoint Runtime Fabric instance. ### Runtime Fabric Kubernetes Roles The following Runtime Fabric roles manage data stored in Kubernetes secrets: - `am-log-forwarder` - `rtf:agent` - `rtf:certificate-renewal` - `rtf-restricted` - `rtf:cluster-status` - `rtf:install` - `rtf:persistence-gateway-clro-read-only` - `rtf:upgrade` - `rtf:mule-clusterip-service` Runtime Fabric components, such as RTF agent, have a legitimate use case to consume the Kube API from the cluster where they are running to monitor or update some Kubernetes resources related to delivering Runtime Fabric features. ### Anypoint Platform Roles and Permissions To successfully use Anypoint Runtime Fabric, your Anypoint Platform account must have the following permissions: - To manage permissions for Anypoint Platform users, you must have the ability to use [Anypoint Access Management](https://docs.mulesoft.com/access-management/). - To deploy and manage applications ensure you have: - The ability to use Anypoint Runtime Manager - The Exchange Contributors permission enabled for your Anypoint Platform account - The read permissions for Applications and Runtime Fabric instances, which are needed to view applications on the Applications page in the Runtime Manager - To use Runtime Fabric, you must have the Organization Administrators permission or the Manage Runtime Fabrics permission for the corresponding environments. - To delete Runtime Fabric instances, administrators need the Manage Runtime Fabrics permission at the organization level. ### Network Configuration Anypoint Runtime Fabric requires an IT administrator to configure network ports, hostnames, and certificates to function correctly. See [Configuring Your Network to Support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/install-self-managed-network-configuration). ### Ingress Controller Runtime Fabric supports any ingress controller that works well in your Kubernetes environment. It also supports a deployment model with a dedicated ingress per application. Most off-the-shelf ingress controllers support this model. > [!IMPORTANT] The default behavior of the ingress controller included with GKE is to provide a > separate HTTP load balancer for each application. If you find this behavior undesirable, explore > possible solutions or consider using another ingress controller. ### Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. It is common practice for applications deployed on Runtime Fabric to log directly to `stdout`. The container runtime stores the console log in a file on disk. The storage location of this file depends on your container runtime and configuration. Refer to the documentation for your Kubernetes environment for details. ### External Log Forwarding Anypoint Runtime Fabric does not forward logs to an external system. You are responsible for installing and managing this configuration. Any external log forwarding agent compatible with your Kubernetes environment running on Amazon EKS, AKS, or GKE can be used. Commonly used log forwarding agents include: - Splunk Connect for Kubernetes - Fluentbit Runtime Fabric supports Log4j appenders. ### Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) provides metrics for applications and API gateways deployed to Runtime Fabric. To collect metrics, Anypoint Monitoring employs sidecar containers as part of each application deployment on Runtime Fabric. See [Monitor Applications Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/manage-monitor-applications) for details, including how to manage monitoring. Runtime Fabric does not provide support for integrating third-party monitoring solutions. --- product: Runtime Fabric version: 2.6 --- # Requirements and Limitations for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following requirements and limitations before installing, configuring, and managing Anypoint Runtime Fabric. ## MuleSoft License Compliance You are responsible for ensuring that you remain compliant with your MuleSoft licensing. To remain compliant, ensure one of the following: 1. The sum of CPU Limits allocated to each Mule application replica is less than or equal to the total license quantity. 2. The total CPU capacity provided by Runtime Fabric worker nodes running Mule applications is less than or equal to the licensed quantity. ## Limitations The following table provides Runtime Fabric limitations.
LimitationDescription

Node types

VM-based nodes are required. For example, Fargate is not supported.

Replicas per application

The maximum number of replicas per application is 16.

Associated environments per Runtime Fabric

You can associate a Runtime Fabric with up to 200 environments in any Business Group. For example, if you associate a development and a production environments with Org A and another development environment with Org B, that is three environment associations.

Business groups

You can create up to 50 Runtime Fabrics per org in a Business Group. Any sub org can contain up to 50 Runtime Fabrics, in addition to any shared with another sub org. For example, for a parent Org A and its child Org B, you can have 50 Runtime Fabrics in Org A and 50 in Org B. You can also share all 50 Runtime Fabrics from Org A with Org B, and as a result, you will see 100 Runtime Fabrics in total in the list view of Org B.

## Use of Third-Party Software within a Runtime Fabric K8s Cluster You are expected to use authorized namespaces features to ensure isolation between third-party software and Runtime Fabric software or Mule deployments. Install third-party software in non-rtf specific namespaces to ensure they do not interfere with Runtime Fabric or Mule runtime engine functionality. ## How Antivirus and DPI Software Impacts Runtime Fabric Functionality Anypoint Runtime Fabric has specific hardware and OS requirements. MuleSoft Support provides Support SLA and Severity Levels based on our validation and certification of the requirements specified in the installation prerequisites for [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/) . Some third-party software requires root access to the host. This software includes, but is not limited to, antivirus and DPI software, which has been found to interfere with the behavior and requirements of Runtime Fabric. In many support cases where MuleSoft Support has detected antivirus software, they have seen issues such as port blocking, node-to-node communication blocking, Docker default bridge deletion, and filesystem access issues that interfere with Runtime Fabric installation, upgrade, and normal operations. In the event that abnormal behavior is observed with Runtime Fabric, you may be asked to disable any running third-party software (including anti-virus or DPI software) to determine if it is the cause of the behavior. If disabling such software restores proper Runtime Fabric functionality, this would demonstrate an implicit incompatibility between that software package and Runtime Fabric, and we would consider the support case resolved. If you are strictly required to run traditional security tools that interfere with certain components of Runtime Fabric, vendors and security experts that support Kubernetes can support you in meeting this requirement. Cloud platform vendors often add cloud-centric controls that are consistent with well-known security benchmarks, such as the [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/). ## Requirements for Runtime Fabric The following descriptions provide you with the general requirements for running Anypoint Runtime Fabric. ### Kubernetes Support Runtime Fabric requires a Kubernetes cluster that is provisioned and operational. Verify whether your environment is correctly configured using the `rtfctl` command-line utility. See [Install Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-self-managed). Refer to the [release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the list of supported Kubernetes versions for your Runtime Fabric. ### Supported Architectures Anypoint Runtime Fabric requires worker nodes with the x86-64 architecture. ARM-based nodes are not supported. ### Operating Systems Anypoint Runtime Fabric works on any Linux distribution supported by Amazon EKS, AKS, GKE, or RedHat OpenShift. ### Nodes and Resources In general, you should follow the best practices provided by your Kubernetes vendor to ensure availability and simplify the administration of your infrastructure. To ensure optimal performance, Runtime Fabric installation requires at least two nodes each equipped with: - Minimum of two CPU cores - At least 15 GiB of RAM - At least 250 GiB of available disk space Adjust the number of nodes and amount of resources allocated according to the amount and type of workload you run on each Anypoint Runtime Fabric instance. ### Runtime Fabric Kubernetes Roles The following Runtime Fabric roles manage data stored in Kubernetes secrets: - `am-log-forwarder` - `rtf:agent` - `rtf:certificate-renewal` - `rtf-restricted` - `rtf:cluster-status` - `rtf:install` - `rtf:persistence-gateway-clro-read-only` - `rtf:upgrade` - `rtf:mule-clusterip-service` Runtime Fabric components, such as RTF agent, have a legitimate use case to consume the Kube API from the cluster where they are running to monitor or update some Kubernetes resources related to delivering Runtime Fabric features. ### Anypoint Platform Roles and Permissions To successfully use Anypoint Runtime Fabric, your Anypoint Platform account must have the following permissions: - To manage permissions for Anypoint Platform users, you must have the ability to use [Anypoint Access Management](https://docs.mulesoft.com/access-management/). - To deploy and manage applications ensure you have: - The ability to use Anypoint Runtime Manager - The Exchange Contributors permission enabled for your Anypoint Platform account - The read permissions for Applications and Runtime Fabric instances, which are needed to view applications on the Applications page in the Runtime Manager - To use Runtime Fabric, you must have the Organization Administrators permission or the Manage Runtime Fabrics permission for the corresponding environments. - To delete Runtime Fabric instances, administrators need the Manage Runtime Fabrics permission at the organization level. ### Network Configuration Anypoint Runtime Fabric requires an IT administrator to configure network ports, hostnames, and certificates to function correctly. See [Configuring Your Network to Support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-self-managed-network-configuration). ### Ingress Controller Runtime Fabric supports any ingress controller that works well in your Kubernetes environment. It also supports a deployment model with a dedicated ingress per application. Most off-the-shelf ingress controllers support this model. > [!IMPORTANT] The default behavior of the ingress controller included with GKE is to provide a > separate HTTP load balancer for each application. If you find this behavior undesirable, explore > possible solutions or consider using another ingress controller. ### Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. It is common practice for applications deployed on Runtime Fabric to log directly to `stdout`. The container runtime stores the console log in a file on disk. The storage location of this file depends on your container runtime and configuration. Refer to the documentation for your Kubernetes environment for details. ### External Log Forwarding Anypoint Runtime Fabric does not forward logs to an external system. You are responsible for installing and managing this configuration. Any external log forwarding agent compatible with your Kubernetes environment running on Amazon EKS, AKS, or GKE can be used. Commonly used log forwarding agents include: - Fluentbit Runtime Fabric supports Log4j appenders. ### Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) provides metrics for applications and API gateways deployed to Runtime Fabric. To collect metrics, Anypoint Monitoring employs sidecar containers as part of each application deployment on Runtime Fabric. See [Monitor Applications Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/manage-monitor-applications) for details, including how to manage monitoring. Runtime Fabric does not provide support for integrating third-party monitoring solutions. --- product: Runtime Fabric version: 2.7 --- # Requirements and Limitations for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following requirements and limitations before installing, configuring, and managing Anypoint Runtime Fabric. ## MuleSoft License Compliance You are responsible for ensuring that you remain compliant with your MuleSoft licensing. To remain compliant, ensure one of the following: 1. The sum of CPU Limits allocated to each Mule application replica is less than or equal to the total license quantity. 2. The total CPU capacity provided by Runtime Fabric worker nodes running Mule applications is less than or equal to the licensed quantity. ## Limitations The following table provides Runtime Fabric limitations.
LimitationDescription

Node types

VM-based nodes are required. For example, Fargate is not supported.

Replicas per application

The maximum number of replicas per application is 16. *

Associated environments per Runtime Fabric

You can associate a Runtime Fabric with up to 200 environments in any Business Group. For example, if you associate a development and a production environments with Org A and another development environment with Org B, that is three environment associations.

Business groups

You can create up to 50 Runtime Fabrics per org in a Business Group. Any sub org can contain up to 50 Runtime Fabrics, in addition to any shared with another sub org. For example, for a parent Org A and its child Org B, you can have 50 Runtime Fabrics in Org A and 50 in Org B. You can also share all 50 Runtime Fabrics from Org A with Org B, and as a result, you will see 100 Runtime Fabrics in total in the list view of Org B.

Runtime Fabric supports maximum 16 replicas per application in all forms except when the you use usage pricing and Horizontal Pod Autoscaling feature. In this case, the maximum number of replicas per application is still 8. ## Use of Third-Party Software within a Runtime Fabric K8s Cluster You are expected to use authorized namespaces features to ensure isolation between third-party software and Runtime Fabric software or Mule deployments. Install third-party software in non-rtf specific namespaces to ensure they do not interfere with Runtime Fabric or Mule runtime engine functionality. ## How Antivirus and DPI Software Impacts Runtime Fabric Functionality Anypoint Runtime Fabric has specific hardware and OS requirements. MuleSoft Support provides Support SLA and Severity Levels based on our validation and certification of the requirements specified in the installation prerequisites for [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/) . Some third-party software requires root access to the host. This software includes, but is not limited to, antivirus and DPI software, which has been found to interfere with the behavior and requirements of Runtime Fabric. In many support cases where MuleSoft Support has detected antivirus software, they have seen issues such as port blocking, node-to-node communication blocking, Docker default bridge deletion, and filesystem access issues that interfere with Runtime Fabric installation, upgrade, and normal operations. In the event that abnormal behavior is observed with Runtime Fabric, you may be asked to disable any running third-party software (including anti-virus or DPI software) to determine if it is the cause of the behavior. If disabling such software restores proper Runtime Fabric functionality, this would demonstrate an implicit incompatibility between that software package and Runtime Fabric, and we would consider the support case resolved. If you are strictly required to run traditional security tools that interfere with certain components of Runtime Fabric, vendors and security experts that support Kubernetes can support you in meeting this requirement. Cloud platform vendors often add cloud-centric controls that are consistent with well-known security benchmarks, such as the [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/). ## Requirements for Runtime Fabric The following descriptions provide you with the general requirements for running Anypoint Runtime Fabric. ### Kubernetes Support Runtime Fabric requires a Kubernetes cluster that is provisioned and operational. Verify whether your environment is correctly configured using the `rtfctl` command-line utility. See [Install Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-self-managed). Refer to the [release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the list of supported Kubernetes versions for your Runtime Fabric. ### Supported Architectures Anypoint Runtime Fabric requires worker nodes with the x86-64 architecture. ARM-based nodes are not supported. ### Operating Systems Anypoint Runtime Fabric works on any Linux distribution supported by Amazon EKS, AKS, GKE, or RedHat OpenShift. ### Nodes and Resources In general, you should follow the best practices provided by your Kubernetes vendor to ensure availability and simplify the administration of your infrastructure. To ensure optimal performance, Runtime Fabric installation requires at least two nodes each equipped with: - Minimum of two CPU cores - At least 15 GiB of RAM - At least 250 GiB of available disk space Adjust the number of nodes and amount of resources allocated according to the amount and type of workload you run on each Anypoint Runtime Fabric instance. ### Runtime Fabric Kubernetes Roles The following Runtime Fabric roles manage data stored in Kubernetes secrets: - `am-log-forwarder` - `rtf:agent` - `rtf:certificate-renewal` - `rtf-restricted` - `rtf:cluster-status` - `rtf:install` - `rtf:persistence-gateway-clro-read-only` - `rtf:upgrade` - `rtf:mule-clusterip-service` Runtime Fabric components, such as RTF agent, have a legitimate use case to consume the Kube API from the cluster where they are running to monitor or update some Kubernetes resources related to delivering Runtime Fabric features. ### Anypoint Platform Roles and Permissions To successfully use Anypoint Runtime Fabric, your Anypoint Platform account must have the following permissions: - To manage permissions for Anypoint Platform users, you must have the ability to use [Anypoint Access Management](https://docs.mulesoft.com/access-management/). - To deploy and manage applications ensure you have: - The ability to use Anypoint Runtime Manager - The Exchange Contributors permission enabled for your Anypoint Platform account - The read permissions for Applications and Runtime Fabric instances, which are needed to view applications on the Applications page in the Runtime Manager - To use Runtime Fabric, you must have the Organization Administrators permission or the Manage Runtime Fabrics permission for the corresponding environments. - To delete Runtime Fabric instances, administrators need the Manage Runtime Fabrics permission at the organization level. ### Network Configuration Anypoint Runtime Fabric requires an IT administrator to configure network ports, hostnames, and certificates to function correctly. See [Configuring Your Network to Support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-self-managed-network-configuration). ### Ingress Controller Runtime Fabric supports any ingress controller that works well in your Kubernetes environment. It also supports a deployment model with a dedicated ingress per application. Most off-the-shelf ingress controllers support this model. > [!IMPORTANT] The default behavior of the ingress controller included with GKE is to provide a > separate HTTP load balancer for each application. If you find this behavior undesirable, explore > possible solutions or consider using another ingress controller. ### Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. It is common practice for applications deployed on Runtime Fabric to log directly to `stdout`. The container runtime stores the console log in a file on disk. The storage location of this file depends on your container runtime and configuration. Refer to the documentation for your Kubernetes environment for details. ### External Log Forwarding Anypoint Runtime Fabric does not forward logs to an external system. You are responsible for installing and managing this configuration. Any external log forwarding agent compatible with your Kubernetes environment running on Amazon EKS, AKS, or GKE can be used. Commonly used log forwarding agents include: - Fluent Bit Runtime Fabric supports Log4j appenders. ### Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) provides metrics for applications and API gateways deployed to Runtime Fabric. To collect metrics, Anypoint Monitoring employs sidecar containers as part of each application deployment on Runtime Fabric. See [Monitor Applications Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/manage-monitor-applications) for details, including how to manage monitoring. Runtime Fabric does not provide support for integrating third-party monitoring solutions. --- product: Runtime Fabric version: 2.8 --- # Requirements and Limitations for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following requirements and limitations before installing, configuring, and managing Anypoint Runtime Fabric. ## MuleSoft License Compliance You are responsible for ensuring that you remain compliant with your MuleSoft licensing. To remain compliant, ensure one of the following: 1. The sum of CPU Limits allocated to each Mule application replica is less than or equal to the total license quantity. 2. The total CPU capacity provided by Runtime Fabric worker nodes running Mule applications is less than or equal to the licensed quantity. For Runtime Fabric usage reports, see [Runtime Fabric Compliance Tracking](https://docs.mulesoft.com/general/usage-metrics#rtf-compliance-tracking). ## Limitations The following table provides Runtime Fabric limitations.
LimitationDescription

Node types

VM-based nodes are required. For example, Fargate is not supported.

Replicas per application

The maximum number of replicas per application is 16. *

Associated environments per Runtime Fabric

You can associate a Runtime Fabric with up to 200 environments in any Business Group. For example, if you associate a development and a production environments with Org A and another development environment with Org B, that is three environment associations.

Business groups

You can create up to 50 Runtime Fabrics per org in a Business Group. Any sub org can contain up to 50 Runtime Fabrics, in addition to any shared with another sub org. For example, for a parent Org A and its child Org B, you can have 50 Runtime Fabrics in Org A and 50 in Org B. You can also share all 50 Runtime Fabrics from Org A with Org B, and as a result, you will see 100 Runtime Fabrics in total in the list view of Org B.

Runtime Fabric supports maximum 16 replicas per application in all forms except when the you use usage pricing and Horizontal Pod Autoscaling feature. In this case, the maximum number of replicas per application is still 8. ## Use of Third-Party Software within a Runtime Fabric K8s Cluster You are expected to use authorized namespaces features to ensure isolation between third-party software and Runtime Fabric software or Mule deployments. Install third-party software in non-rtf specific namespaces to ensure they do not interfere with Runtime Fabric or Mule runtime engine functionality. ## How Antivirus and DPI Software Impacts Runtime Fabric Functionality Anypoint Runtime Fabric has specific hardware and OS requirements. MuleSoft Support provides Support SLA and Severity Levels based on our validation and certification of the requirements specified in the installation prerequisites for [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/) . Some third-party software requires root access to the host. This software includes, but is not limited to, antivirus and DPI software, which has been found to interfere with the behavior and requirements of Runtime Fabric. In many support cases where MuleSoft Support has detected antivirus software, they have seen issues such as port blocking, node-to-node communication blocking, Docker default bridge deletion, and filesystem access issues that interfere with Runtime Fabric installation, upgrade, and normal operations. In the event that abnormal behavior is observed with Runtime Fabric, you may be asked to disable any running third-party software (including anti-virus or DPI software) to determine if it is the cause of the behavior. If disabling such software restores proper Runtime Fabric functionality, this would demonstrate an implicit incompatibility between that software package and Runtime Fabric, and we would consider the support case resolved. If you are strictly required to run traditional security tools that interfere with certain components of Runtime Fabric, vendors and security experts that support Kubernetes can support you in meeting this requirement. Cloud platform vendors often add cloud-centric controls that are consistent with well-known security benchmarks, such as the [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/). ## Requirements for Runtime Fabric The following descriptions provide you with the general requirements for running Anypoint Runtime Fabric. ### Kubernetes Support Runtime Fabric requires a Kubernetes cluster that is provisioned and operational. Verify whether your environment is correctly configured using the `rtfctl` command-line utility. See [Install Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-self-managed). Refer to the [release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the list of supported Kubernetes versions for your Runtime Fabric. ### Supported Architectures Anypoint Runtime Fabric requires worker nodes with the x86-64 architecture. ARM-based nodes are not supported. ### Operating Systems Anypoint Runtime Fabric works on any Linux distribution supported by Amazon EKS, AKS, GKE, or RedHat OpenShift. ### Nodes and Resources In general, you should follow the best practices provided by your Kubernetes vendor to ensure availability and simplify the administration of your infrastructure. To ensure optimal performance, Runtime Fabric installation requires at least two nodes each equipped with: - Minimum of two CPU cores - At least 15 GiB of RAM - At least 250 GiB of available disk space Adjust the number of nodes and amount of resources allocated according to the amount and type of workload you run on each Anypoint Runtime Fabric instance. ### Runtime Fabric Kubernetes Roles The following Runtime Fabric roles manage data stored in Kubernetes secrets: - `am-log-forwarder` - `rtf:agent` - `rtf:certificate-renewal` - `rtf-restricted` - `rtf:cluster-status` - `rtf:install` - `rtf:persistence-gateway-clro-read-only` - `rtf:upgrade` - `rtf:mule-clusterip-service` Runtime Fabric components, such as RTF agent, have a legitimate use case to consume the Kube API from the cluster where they are running to monitor or update some Kubernetes resources related to delivering Runtime Fabric features. ### Anypoint Platform Roles and Permissions To successfully use Anypoint Runtime Fabric, your Anypoint Platform account must have the following permissions: - To manage permissions for Anypoint Platform users, you must have the ability to use [Anypoint Access Management](https://docs.mulesoft.com/access-management/). - To deploy and manage applications ensure you have: - The ability to use Anypoint Runtime Manager - The Exchange Contributors permission enabled for your Anypoint Platform account - The read permissions for Applications and Runtime Fabric instances, which are needed to view applications on the Applications page in the Runtime Manager - To use Runtime Fabric, you must have the Organization Administrators permission or the Manage Runtime Fabrics permission for the corresponding environments. - To delete Runtime Fabric instances, administrators need the Manage Runtime Fabrics permission at the organization level. ### Network Configuration Anypoint Runtime Fabric requires an IT administrator to configure network ports, hostnames, and certificates to function correctly. See [Configuring Your Network to Support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-self-managed-network-configuration). ### Ingress Controller Runtime Fabric supports any ingress controller that works well in your Kubernetes environment. It also supports a deployment model with a dedicated ingress per application. Most off-the-shelf ingress controllers support this model. > [!IMPORTANT] The default behavior of the ingress controller included with GKE is to provide a > separate HTTP load balancer for each application. If you find this behavior undesirable, explore > possible solutions or consider using another ingress controller. ### Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. It is common practice for applications deployed on Runtime Fabric to log directly to `stdout`. The container runtime stores the console log in a file on disk. The storage location of this file depends on your container runtime and configuration. Refer to the documentation for your Kubernetes environment for details. ### External Log Forwarding Anypoint Runtime Fabric does not forward logs to an external system. You are responsible for installing and managing this configuration. Any external log forwarding agent compatible with your Kubernetes environment running on Amazon EKS, AKS, or GKE can be used. Commonly used log forwarding agents include: - Fluent Bit Runtime Fabric supports Log4j appenders. ### Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) provides metrics for applications and API gateways deployed to Runtime Fabric. To collect metrics, Anypoint Monitoring employs sidecar containers as part of each application deployment on Runtime Fabric. See [Monitor Applications Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-monitor-applications) for details, including how to manage monitoring. Runtime Fabric does not provide support for integrating third-party monitoring solutions. --- product: Runtime Fabric version: 2.9 --- # Requirements and Limitations for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following requirements and limitations before installing, configuring, and managing Anypoint Runtime Fabric. ## MuleSoft License Compliance You are responsible for ensuring that you remain compliant with your MuleSoft licensing. To remain compliant, ensure one of the following: 1. The sum of CPU Limits allocated to each Mule application replica is less than or equal to the total license quantity. 2. The total CPU capacity provided by Runtime Fabric worker nodes running Mule applications is less than or equal to the licensed quantity. For Runtime Fabric usage reports, see [Runtime Fabric Compliance Tracking](https://docs.mulesoft.com/general/usage-metrics#rtf-compliance-tracking). ## Limitations The following table provides Runtime Fabric limitations.
LimitationDescription

Node types

VM-based nodes are required. For example, Fargate is not supported.

Replicas per application

The maximum number of replicas per application is 16. *

Associated environments per Runtime Fabric

You can associate a Runtime Fabric with up to 200 environments in any Business Group. For example, if you associate a development and a production environments with Org A and another development environment with Org B, that is three environment associations.

Business groups

You can create up to 50 Runtime Fabrics per org in a Business Group. Any sub org can contain up to 50 Runtime Fabrics, in addition to any shared with another sub org. For example, for a parent Org A and its child Org B, you can have 50 Runtime Fabrics in Org A and 50 in Org B. You can also share all 50 Runtime Fabrics from Org A with Org B, and as a result, you will see 100 Runtime Fabrics in total in the list view of Org B.

Runtime Fabric supports maximum 16 replicas per application in all forms except when the you use usage pricing and Horizontal Pod Autoscaling feature. In this case, the maximum number of replicas per application is still 8. ## Use of Third-Party Software within a Runtime Fabric K8s Cluster You are expected to use authorized namespaces features to ensure isolation between third-party software and Runtime Fabric software or Mule deployments. Install third-party software in non-rtf specific namespaces to ensure they do not interfere with Runtime Fabric or Mule runtime engine functionality. ## How Antivirus and DPI Software Impacts Runtime Fabric Functionality Anypoint Runtime Fabric has specific hardware and OS requirements. MuleSoft Support provides Support SLA and Severity Levels based on our validation and certification of the requirements specified in the installation prerequisites for [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/) . Some third-party software requires root access to the host. This software includes, but is not limited to, antivirus and DPI software, which has been found to interfere with the behavior and requirements of Runtime Fabric. In many support cases where MuleSoft Support has detected antivirus software, they have seen issues such as port blocking, node-to-node communication blocking, Docker default bridge deletion, and filesystem access issues that interfere with Runtime Fabric installation, upgrade, and normal operations. In the event that abnormal behavior is observed with Runtime Fabric, you may be asked to disable any running third-party software (including anti-virus or DPI software) to determine if it is the cause of the behavior. If disabling such software restores proper Runtime Fabric functionality, this would demonstrate an implicit incompatibility between that software package and Runtime Fabric, and we would consider the support case resolved. If you are strictly required to run traditional security tools that interfere with certain components of Runtime Fabric, vendors and security experts that support Kubernetes can support you in meeting this requirement. Cloud platform vendors often add cloud-centric controls that are consistent with well-known security benchmarks, such as the [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/). ## Requirements for Runtime Fabric The following descriptions provide you with the general requirements for running Anypoint Runtime Fabric. ### Kubernetes Support Runtime Fabric requires a Kubernetes cluster that is provisioned and operational. Verify whether your environment is correctly configured using the `rtfctl` command-line utility. See [Install Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-self-managed). Refer to the [release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the list of supported Kubernetes versions for your Runtime Fabric. ### Supported Architectures Anypoint Runtime Fabric requires worker nodes with the x86-64 architecture. ARM-based nodes are not supported. ### Operating Systems Anypoint Runtime Fabric works on any Linux distribution supported by: - Alibaba Cloud Container Service (ACK) - Amazon Elastics Kubernetes Service (EKS) - Amazon EKS Anywhere (EKS-A) - Google Kubernetes Engine (GKE) - Microsoft Azure Kubernetes Service (AKS) - Rancher Kubernetes Engine (RKE2) - Red Hat OpenShift - VMware Tanzu ### Nodes and Resources In general, you should follow the best practices provided by your Kubernetes vendor to ensure availability and simplify the administration of your infrastructure. To ensure optimal performance, Runtime Fabric installation requires at least two nodes each equipped with: - Minimum of two CPU cores - At least 15 GiB of RAM - At least 250 GiB of available disk space Adjust the number of nodes and amount of resources allocated according to the amount and type of workload you run on each Anypoint Runtime Fabric instance. ### Runtime Fabric Kubernetes Roles The following Runtime Fabric roles manage data stored in Kubernetes secrets: - `am-log-forwarder` - `rtf:agent` - `rtf:certificate-renewal` - `rtf-restricted` - `rtf:cluster-status` - `rtf:install` - `rtf:persistence-gateway-clro-read-only` - `rtf:upgrade` - `rtf:mule-clusterip-service` Runtime Fabric components, such as RTF agent, have a legitimate use case to consume the Kube API from the cluster where they are running to monitor or update some Kubernetes resources related to delivering Runtime Fabric features. ### Anypoint Platform Roles and Permissions To successfully use Anypoint Runtime Fabric, your Anypoint Platform account must have the following permissions: - To manage permissions for Anypoint Platform users, you must have the ability to use [Anypoint Access Management](https://docs.mulesoft.com/access-management/). - To deploy and manage applications ensure you have: - The ability to use Anypoint Runtime Manager - The Exchange Contributors permission enabled for your Anypoint Platform account - The read permissions for Applications and Runtime Fabric instances, which are needed to view applications on the Applications page in the Runtime Manager - To use Runtime Fabric, you must have the Organization Administrators permission or the Manage Runtime Fabrics permission for the corresponding environments. - To delete Runtime Fabric instances, administrators need the Manage Runtime Fabrics permission at the organization level. ### Network Configuration Anypoint Runtime Fabric requires an IT administrator to configure network ports, hostnames, and certificates to function correctly. See [Configuring Your Network to Support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-self-managed-network-configuration). ### Ingress Controller Runtime Fabric supports any ingress controller that works well in your Kubernetes environment. It also supports a deployment model with a dedicated ingress per application. Most off-the-shelf ingress controllers support this model. > [!IMPORTANT] The default behavior of the ingress controller included with GKE is to provide a > separate HTTP load balancer for each application. If you find this behavior undesirable, explore > possible solutions or consider using another ingress controller. See the following link: > [KB article](https://help.salesforce.com/s/articleView?id=001116839&type=1) for more details. ### Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. It is common practice for applications deployed on Runtime Fabric to log directly to `stdout`. The container runtime stores the console log in a file on disk. The storage location of this file depends on your container runtime and configuration. Refer to the documentation for your Kubernetes environment for details. ### External Log Forwarding Anypoint Runtime Fabric does not forward logs to an external system. You are responsible for installing and managing this configuration. Any external log forwarding agent compatible with your Kubernetes environment running on Amazon EKS, AKS, or GKE can be used. Commonly used log forwarding agents include: - Fluent Bit Runtime Fabric supports Log4j appenders. ### Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) provides metrics for applications and API gateways deployed to Runtime Fabric. To collect metrics, Anypoint Monitoring employs sidecar containers as part of each application deployment on Runtime Fabric. See [Monitor Applications Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/manage-monitor-applications) for details, including how to manage monitoring. Runtime Fabric does not provide support for integrating third-party monitoring solutions. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Requirements and Limitations for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Review the following requirements and limitations before installing, configuring, and managing Anypoint Runtime Fabric. ## MuleSoft License Compliance You are responsible for ensuring that you remain compliant with your MuleSoft licensing. To remain compliant, ensure one of the following: 1. The sum of CPU Limits allocated to each Mule application replica is less than or equal to the total license quantity. 2. The total CPU capacity provided by Runtime Fabric worker nodes running Mule applications is less than or equal to the licensed quantity. For Runtime Fabric usage reports, see [Runtime Fabric Compliance Tracking](https://docs.mulesoft.com/general/usage-metrics#rtf-compliance-tracking). ## Limitations The following table provides Runtime Fabric limitations.
LimitationDescription

Node types

VM-based nodes are required. For example, Fargate is not supported.

Replicas per application

Runtime Fabric supports a maximum of 16 replicas per application in all forms except when you use the usage pricing and Horizontal Pod Autoscaling feature. In this case, the maximum number of replicas per application is 8.

Associated environments per Runtime Fabric

You can associate a Runtime Fabric with up to 200 environments in any Business Group. For example, if you associate a development and a production environments with Org A and another development environment with Org B, that is three environment associations.

Business groups

You can create up to 50 Runtime Fabrics per org in a Business Group. Any sub org can contain up to 50 Runtime Fabrics, in addition to any shared with another sub org. For example, for a parent Org A and its child Org B, you can have 50 Runtime Fabrics in Org A and 50 in Org B. You can also share all 50 Runtime Fabrics from Org A with Org B, and as a result, you will see 100 Runtime Fabrics in total in the list view of Org B.

## Use of Third-Party Software within a Runtime Fabric K8s Cluster You are expected to use authorized namespaces features to ensure isolation between third-party software and Runtime Fabric software or Mule deployments. Install third-party software in non-rtf specific namespaces to ensure they do not interfere with Runtime Fabric or Mule runtime engine functionality. ## How Antivirus and DPI Software Impacts Runtime Fabric Functionality Anypoint Runtime Fabric has specific hardware and OS requirements. MuleSoft Support provides Support SLA and Severity Levels based on our validation and certification of the requirements specified in the installation prerequisites for [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/) . Some third-party software requires root access to the host. This software includes, but is not limited to, antivirus and DPI software, which has been found to interfere with the behavior and requirements of Runtime Fabric. In many support cases where MuleSoft Support has detected antivirus software, they have seen issues such as port blocking, node-to-node communication blocking, Docker default bridge deletion, and filesystem access issues that interfere with Runtime Fabric installation, upgrade, and normal operations. In the event that abnormal behavior is observed with Runtime Fabric, you may be asked to disable any running third-party software (including anti-virus or DPI software) to determine if it is the cause of the behavior. If disabling such software restores proper Runtime Fabric functionality, this would demonstrate an implicit incompatibility between that software package and Runtime Fabric, and we would consider the support case resolved. If you are strictly required to run traditional security tools that interfere with certain components of Runtime Fabric, vendors and security experts that support Kubernetes can support you in meeting this requirement. Cloud platform vendors often add cloud-centric controls that are consistent with well-known security benchmarks, such as the [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/). ## Requirements for Runtime Fabric The following descriptions provide you with the general requirements for running Anypoint Runtime Fabric. ### Kubernetes Support Runtime Fabric requires a Kubernetes cluster that is provisioned and operational. Verify whether your environment is correctly configured using the `rtfctl` command-line utility. See [Install Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed). Refer to the [release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the list of supported Kubernetes versions for your Runtime Fabric. ### Supported Architectures Anypoint Runtime Fabric requires worker nodes with the x86-64 architecture. ARM-based nodes are not supported. ### Operating Systems Anypoint Runtime Fabric works on any Linux distribution supported by: - Alibaba Cloud Container Service (ACK) - Amazon Elastics Kubernetes Service (EKS) - Amazon EKS Anywhere (EKS-A) - Google Kubernetes Engine (GKE) - Microsoft Azure Kubernetes Service (AKS) - Oracle Kubernetes Engine (OKE) - Rancher Kubernetes Engine (RKE2) - Red Hat OpenShift - VMware Tanzu Runtime Fabric agent supports most Linux distributions. However, you must conduct your own testing to ensure that Runtime Fabric is compatible with your chosen operating system. Also validate [Mule runtime engine compatibility](https://docs.mulesoft.com/on-premises/latest/hardware-and-software-requirements) and [Anypoint Monitoring compatibility](https://docs.mulesoft.com/monitoring/am-installing#os-support) with your operating system. ### Nodes and Resources In general, you should follow the best practices provided by your Kubernetes vendor to ensure availability and simplify the administration of your infrastructure. To ensure optimal performance, Runtime Fabric installation requires at least two nodes each equipped with: - Minimum of two CPU cores - At least 15 GiB of RAM - At least 250 GiB of available disk space Adjust the number of nodes and amount of resources allocated according to the amount and type of workload you run on each Anypoint Runtime Fabric instance. ### Runtime Fabric Kubernetes Roles The following Runtime Fabric roles manage data stored in Kubernetes secrets: - `rtf:agent` - `rtf:certificate-renewal` - `rtf-restricted` - `rtf:cluster-status` - `rtf:install` - `rtf:persistence-gateway-clro-read-only` - `rtf:upgrade` - `rtf:mule-clusterip-service` > [!NOTE] Starting with Runtime Fabric agent version 3.0.0, the `am-log-forwarder` role is no longer > used as log forwarding occurs exclusively through application sidecar containers. For more > information, refer to > [Migrate Log Forwarding Before Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/migrate-log-forwarding). Runtime Fabric components, such as RTF agent, have a legitimate use case to consume the Kube API from the cluster where they are running to monitor or update some Kubernetes resources related to delivering Runtime Fabric features. ### Anypoint Platform Roles and Permissions To successfully use Anypoint Runtime Fabric, your Anypoint Platform account must have the following permissions: - To manage permissions for Anypoint Platform users, you must have the ability to use [Anypoint Access Management](https://docs.mulesoft.com/access-management/). - To deploy and manage applications ensure you have: - The ability to use Anypoint Runtime Manager - The Exchange Contributors permission enabled for your Anypoint Platform account - The read permissions for Applications and Runtime Fabric instances, which are needed to view applications on the Applications page in the Runtime Manager - To use Runtime Fabric, you must have the Organization Administrators permission or the Manage Runtime Fabrics permission for the corresponding environments. - To delete Runtime Fabric instances, administrators need the Manage Runtime Fabrics permission at the organization level. ### Network Configuration Anypoint Runtime Fabric requires an IT administrator to configure network ports, hostnames, and certificates to function correctly. See [Configuring Your Network to Support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration). ### Ingress Controller Runtime Fabric supports any ingress controller that works well in your Kubernetes environment. It also supports a deployment model with a dedicated ingress per application. Most off-the-shelf ingress controllers support this model. > [!IMPORTANT] The default behavior of the ingress controller included with GKE is to provide a > separate HTTP load balancer for each application. If you find this behavior undesirable, explore > possible solutions or consider using another ingress controller. ### Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform. It is common practice for applications deployed on Runtime Fabric to log directly to `stdout`. The container runtime stores the console log in a file on disk. The storage location of this file depends on your container runtime and configuration. Refer to the documentation for your Kubernetes environment for details. ### External Log Forwarding Anypoint Runtime Fabric doesn’t forward logs to an external system. You are responsible for installing and managing this configuration. Any external log forwarding agent compatible with your Kubernetes environment running on Amazon EKS, AKS, GKE, or OKE can be used. Commonly used log forwarding agents include: - Fluentbit Runtime Fabric supports Log4j appenders. ### Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) provides metrics for applications and API gateways deployed to Runtime Fabric. To collect metrics, Anypoint Monitoring employs sidecar containers as part of each application deployment on Runtime Fabric. See [Monitor Applications Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/manage-monitor-applications) for details, including how to manage monitoring. Runtime Fabric does not provide support for integrating third-party monitoring solutions. --- product: Runtime Fabric version: 2.5 --- # Resource Allocation and Performance for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying a Mule application to Anypoint Runtime Fabric, determine the correct number of resources to allocate. Determining resource allocation is also important when configuring the internal load balancers on Anypoint Runtime Fabrics. When a Mule application is deployed to Runtime Fabric, the application is deployed with its own Mule runtime engine (Mule). The number of replicas, or instances of that application and runtime, are also specified. The resources available for each replica are determined by the values you set when deploying an application. The following performance information is based on clusters with controller nodes using custom Intel Xeon E5-2676 v3 Haswell processors. The processors run at a base clock rate of 2.4 GHz and can go as high as 3.0 GHz with Intel Turbo Boost. The load generator was hosted on a separate cluster in the same region. You can allocate the following resources when deploying an application: - vCPU cores - `Reserved vCPU` The amount of vCPU guaranteed to the application and reserved for its use. - `vCPU Limit` The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node. - Memory ## MuleSoft License Compliance You are responsible for ensuring that you remain compliant with your MuleSoft licensing. To remain compliant, ensure one of the following: 1. The sum of CPU Limits allocated to each Mule application replica is less than or equal to the total license quantity. 2. The total CPU capacity provided by Runtime Fabric worker nodes running Mule applications is less than or equal to the licensed quantity. ## vCPU Allocation When the `Reserved vCPU` and `vCPU Limit` are equal, the CPU on the worker node is allocated in a guaranteed model. The container always has the specified amount of CPU available. The vCPU is reserved for each replica of the application and is guaranteed regardless of what else is running on Runtime Fabric. Guaranteed CPU allocation allows applications to perform consistently by ensuring there is no CPU contention between other applications. It guarantees performance in all cases. When the value of `vCPU Limit` is set higher than the value of `Reserved vCPU`, the application can burst up to the either the vCPU limit value or the amount of unreserved vCPU on the worker node, whichever is less. When estimating the CPU and memory required for worker nodes, Anypoint Monitoring agent requires at least 0.05 vCPU cores and 50 Mi of memory for Anypoint Monitoring. This container is used to stream application metrics to the control plane and cannot be disabled. ## CPU Bursting When using CPU bursting, you must consider the following factors: - Minimum reserved vCPU: 0.02 vCPU. - Minimum vCPU limit: 0.07 vCPU. Resource intensive applications might require additional CPU capacity. If an application deployment fails using the minimum vCPU limit, increase the vCPU limit and redeploy the application. - The CPU limit is upper-bounded by the CPU cores provided on the worker nodes. - The maximum recommended utilization per CPU core is 20 - 25 simple applications and API gateways. More complex applications with higher usage may need more capacity. - Runtime Fabric runs a small number of services on worker nodes. These services consume between 0.3 and 0.5 vCPU, depending on whether log forwarding is enabled for Anypoint Monitoring. - Each application replica must reserve 50m CPU and 50Mi memory for the container that runs Anypoint Monitoring. This container streams application metrics to the control plane and cannot be disabled. - Applications compete for the unallocated CPU remaining on their worker node. As more applications are deployed on a worker node, less unallocated CPU is available to share with other applications and can result in poor performance. The following strategies can be considered for minimizing CPU contention with your applications: - Deploy nightly batch applications with other applications that have peak load during the day. - Deploy multiple replicas of an application so that they are distributed across worker nodes to maximize the surface area for unallocated CPU. Regardless of what approach is chosen, make sure you run tests to validate performance. ## Memory Allocation The minimum values for the amount of memory allocated to each replica of a Mule application or API gateway are the following: - 0.7 GiB memory for Mule 4 - 0.5 GiB memory for Mule 3 When Anypoint Monitoring is enabled, 50MB memory is reserved for running the Anypoint Monitoring sidecar containers, which can burst up to 70MB for each application deployed when processing metrics data. ## Calculating Memory Allocation on CloudHub and Runtime Fabric Anypoint Platform allocates native and heap memory for a deployed application. Heap memory is the portion of the total memory that is made available to the Mule runtime and the application. Heap memory is used for tasks like handling payload. Anypoint Platform allocates native memory for deployed applications through the JVM, taking into account the standard practices of Java memory management. Both CloudHub and Anypoint Runtime Fabric allocate both types of memory. However, they differ in how the memory allocation of each memory type is calculated. - Runtime Fabric lists the total memory available for an application. The available heap memory is approximately half of the total memory allocated to an application. - CloudHub describes minimum memory requirements in terms of the heap memory available to an application. ## Application Startup Times The startup time for a Mule application is correlated to the total number of vCPU cores the application has access to. The following lists approximate startup times for a simple Mule proxy application performing processing on a payload:
vCPU CoresApproximate Startup Time

1.00

Less than 1 minute

0.50

Under 2 minutes

0.10

6 to 8 minutes

0.07

10 to 14 minutes

## Application Performance The resources allocated to your Mule application determine the application’s performance. The following table lists approximate values for throughput based on the total number of vCPU cores allocated for a single Mule application performing simple processing on a 10-KB payload:
vCPU CoresConcurrent ConnectionsAvg Response Time (ms)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78

> [!NOTE] Run performance and load testing on your Mule applications to determine the number of > resources to allocate. ## CPU Requirements for Keys and Certificates Ensure that you allocate enough CPU resources to support a minmum of 10 PEM/P12 or 8 JKS/JCEKS certificates. The number of recommended cores are:
CoresPEM/P12JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8

## Key Types RSA keys are the most common type of keys. RSA keys of 2K length offer the best compromise between security and performance. > [!NOTE] RSA keys larger than 2K protect against brute force cracking and are appropriate for > certificates that have expirations of many years. However, whenever key length is doubled, for > example, from 2k to 4k, performance is reduced by a factor greater than 6. ECDSA keys are also supported. In most cases, ECDSA doubles the performance of a 2K RSA key. Supported curves are: - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (also known as prime256v1 (P-256)) ## See Also - [Deploy a Mule Application to a Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-to-runtime-fabric) - [View Runtime Fabric Health Details](https://docs.mulesoft.com/runtime-fabric/2.5/view-health) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Restarting Mule Applications on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use Anypoint Runtime Manager API to restart Mule applications. Restarting an application can help resolve issues such as memory leaks, unresponsive services, or other runtime problems without requiring a full redeployment. Restarting an application offers several benefits: - Resolve runtime issues without redeploying the application - Restart applications faster than a full redeployment cycle - Test configuration changes or clear transient issues - All restart activities are tracked in the Access Management audit log for compliance and tracking purposes > [!NOTE] The restart feature is available for Mule applications deployed to Runtime Fabric only. > This feature is not available for CloudHub 2.0 applications. ## Before You Begin Before restarting a Mule application, ensure that you have one of these permissions: - **Restart Applications** - **Manage Settings** To grant the permissions to a user: 1. Sign in to Anypoint Platform using an account that has the Organization Administrator permission. 2. Select **Access Management** from the navigation menu. 3. In the Access Management navigation menu, click **Users**. 4. Click the name of the user to assign permissions to. 5. Click the **Permissions** tab and click **Add permissions**. 6. Select **Restart Applications** or **Manage Settings** from the list of permissions and click **Next**. ![Restart Applications permission in Access Management](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-restart-permission.png) 7. Select the business groups to apply the permissions to. 8. Select the environments to apply the permission to. 9. Click **Next**. 10. Review the permissions and the business groups and environments they apply to, and then click **Add Permissions**. The user now has the permissions to restart applications in the business groups and environments you specified. > [!IMPORTANT] All application restart activities are tracked in the Access Management audit log. > You can view the audit log by navigating to **Access Management** > **Audit Log** in Anypoint > Platform. ## Restart an Application Using the Runtime Manager API Restart a Mule application programmatically using the Runtime Manager API. ### API Endpoint Specification ```yaml /organizations/{organizationId}/environments/{environmentId}/actions/restart: post: tags: - Action description: Trigger restarting mule application action parameters: - name: organizationId in: path required: true schema: type: string - name: environmentId in: path required: true schema: type: string requestBody: content: application/json: schema: $ref: "#/components/schemas/ActionExecutionRequest" required: true responses: "400": description: Bad Request "202": description: OK content: application/json: schema: $ref: "#/components/schemas/AmcActionResponse" "403": description: Forbidden "404": description: Not Found ``` Path parameters: - `organizationId` (required, string): Your organization ID - `environmentId` (required, string): The environment ID where the application is deployed Request body: ```json { "type": "RESTART_APPLICATION", "options": { "applicationName": "your-application-name", "deploymentId": "your-deployment-id" }, "selector": {} } ``` Request body schema: The request body must conform to the `ActionExecutionRequest` schema: - `type` (required, string): Must be set to `RESTART_APPLICATION` - `options` (required, object): - `applicationName` (required, string): The name of the application to restart - `deploymentId` (required, string): The deployment ID of the application - `selector` (required, object): An empty object Responses: - `202 Accepted`: The restart request was successfully accepted. Returns an `AmcActionResponse` object. - `400 Bad Request`: The request was malformed or missing required parameters - `403 Forbidden`: You don’t have permission to restart the application - `404 Not Found`: The application or deployment was not found ### Example cURL Command ```bash curl --location 'https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{organizationId}/environments/{environmentId}/actions/restart' \ --header 'Authorization: Bearer {access-token}' \ --header 'Content-Type: application/json' \ --data '{ "type": "RESTART_APPLICATION", "options": { "applicationName": "my-application", "deploymentId": "f295d257-6bb2-4b32-b47c-a4fcdbc2f196" }, "selector": {} }' ``` Replace `{organizationId}`, `{environmentId}`, `{access-token}`, and the values in the request body with your actual values. After a successful API call (202 accepted response), you can monitor the application status in Runtime Manager to confirm that the restart completed successfully. ## See Also - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/managing-apps-deployed-runtime-fabric) - [Deploying Mule Apps to Runtime Fabric Using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) - [Reviewing Mule App Versioning on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Managing Mule App Schedules](https://docs.mulesoft.com/runtime-fabric/latest/manage-schedules) - [Audit Logging](https://docs.mulesoft.com/access-management/audit-logging) --- product: Runtime Fabric version: 2.5 --- # Reviewing Application Versioning on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When an application is deployed to Runtime Fabric, Runtime Manager automatically versions the application and its configuration. Application versioning enables you to: - View the configuration change history of the application. - Roll back the configurations to an earlier version in case the currently applied configuration has issues or is unstable. - View the application status. Possible values are: - Running: At least one replica is receiving traffic (Started state). - Not running: None of the replicas are receiving traffic. - Unknown: The target is disconnected. - Make updates to a deployed application’s configuration, including: - The application package. - Application deployment package version. - Deployment target settings, such as runtime version, number of replicas, and whether the application is running in cluster mode. - Resource allocations, including number of cores and memory allocation. - Ingress and property values. ## Access the Application’s Settings Page 1. Sign into Anypoint Platform and navigate to **Runtime Manager** The **Applications** page is displayed. 2. From the **Applications** page, select an application deployed to Runtime Fabric. 3. Open the management panel on the right side. 4. On the management panel, click the **Manage Application** button. The **Settings** page displays information about the application’s status, configuration history, and other useful information about the application. In the **Config changes** tab on the application’s **Settings** page. Runtime Fabric displays each change to the successfully deployed application configuration. The last ten configuration deployments are displayed in order of their respective configuration date. Each configuration in the history has a unique hash to identify it. ![Configuration page for a Runtime Fabric application, displaying the application file, version, deployment target, runtime version, and replicas](/mulesoft/current/en-us/runtime-fabric/2.5/_images/app-versioning.png) > [!NOTE] The configuration history displays the last ten configuration deployments in order of > creation date. The **All changes** tab displays a history of versions created from the configuration deployment, and the actions performed on each version. ## Apply Configuration Changes 1. On the **Settings** page for the application, you can make the following changes to a deployed configuration: - Upload a new application package. - Make changes to the deployment target and resource allocation. - Modify values for **Ingress** and **Properties**. 2. Once your changes are made, click **Apply Changes**. At the top of the **Settings** page, a status bar appears. ![Applying configuration status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.5/_images/app-versioning-applying-config.png) 3. Click **View Status** to view the status for each replica in the deployment. Replica statuses include: - Started: The replica is receiving traffic. - Pending: The replica is waiting to start. - Starting: The replica is starting. - Deleting: The deletion of the replica is in progress. - Deleted: The replica has been deleted. - Stopping: The replica is stopping. - Stopped: The replica has stopped (is not receiving traffic). - Failed: The configuration failed to deploy. - Recovering: The replica is attempting to restart after terminating. The last successfully deployed configuration is retained until the new (desired) configuration is successfully deployed. New configurations are applied as "rolling updates." For example: - A replica is created with the desired configuration, - Once that configuration is successfully applied, the replica with the old configuration is deleted, - This process is repeated with each replica in the deployment. This model means there is zero downtime while updates are applied to the application. > [!NOTE] Since updates are applied as rolling updates, there will be different application > versions running at the same time until the update is completed, so make sure your > applications are able to run multiple versions in parallel. ![Status of replicas for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.5/_images/app-versioning-replica-status.png) Once the configuration is successfully applied and deployed, a message appears at the top of the page. ![Configuration applied successfully status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.5/_images/app-versioning-config-applied-success.png) The application status, configuration identifier, date, and other information is updated in the status box. The new configuration is displayed at the top of the **Config changes** list, along with a **Last successful** label to indicate that it’s the last configuration successfully deployed. If the updates to the configuration fail to deploy, you get an `Desired configuration wasn’t applied` message, and the **Configuration status** displays an `Update failed` label. The configuration is displayed in the **Config changes** history without a label. ![Configuration failed to apply status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.5/_images/app-versioning-update-failed.png) In cases of failure, the deployment attempts to roll back to the last successful version of the configuration, but in certain situations, the rollback may not succeed. The status of the configuration displays `Update failed`. If it’s the first deployment of the application the rollback version won’t be defined and in case of a failed deployment, it remains in the failed status. ## Roll Back to a Previous Successful Configuration If you deploy a configuration that has issues, you can roll back to a previous successful version of the configuration. 1. In the **Config changes** history, select the version to which to roll back. 2. Click **Deploy**. The configuration moves to the top of the list in the **Config changes** history and displays the new deployment date. It retains its original identifying hash. --- product: Runtime Fabric version: 2.10 --- # Reviewing Mule App Versioning on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When an application is deployed to Runtime Fabric, Runtime Manager automatically versions the application and its configuration. Application versioning enables you to: - View the configuration change history of the application. - Roll back the configurations to an earlier version in case the currently applied configuration has issues or is unstable. - View the application status. Possible values are: - Running: At least one replica is receiving traffic (Started state). - Not running: None of the replicas are receiving traffic. - Unknown: The target is disconnected. - Make updates to a deployed application’s configuration, including: - The application package. - Application deployment package version. - Deployment target settings, such as runtime version, number of replicas, and whether the application is running in cluster mode. - Resource allocations, including number of cores and memory allocation. - Ingress and property values. ## Access the Application’s Settings Page 1. Sign into Anypoint Platform and navigate to **Runtime Manager** The **Applications** page is displayed. 2. From the **Applications** page, select an application deployed to Runtime Fabric. 3. Open the management panel on the right side. 4. On the management panel, click the **Manage Application** button. The **Settings** page displays information about the application’s status, configuration history, and other useful information about the application. In the **Config changes** tab on the application’s **Settings** page. Runtime Fabric displays each change to the successfully deployed application configuration. The last ten configuration deployments are displayed in order of their respective configuration date. Each configuration in the history has a unique hash to identify it. ![Configuration page for a Runtime Fabric application, displaying the application file, version, deployment target, runtime version, and replicas](/mulesoft/current/en-us/runtime-fabric/2.10/_images/app-versioning.png) > [!NOTE] The configuration history displays the last ten configuration deployments in order of > creation date. The **All changes** tab displays a history of versions created from the configuration deployment, and the actions performed on each version. ## Apply Configuration Changes 1. On the **Settings** page for the application, you can make the following changes to a deployed configuration: - Upload a new application package. - Make changes to the deployment target and resource allocation. - Modify values for **Ingress** and **Properties**. 2. Once your changes are made, click **Apply Changes**. At the top of the **Settings** page, a status bar appears. ![Applying configuration status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.10/_images/app-versioning-applying-config.png) 3. Click **View Status** to view the status for each replica in the deployment. Replica statuses include: - Started: The replica is receiving traffic. - Pending: The replica is waiting to start. - Starting: The replica is starting. - Deleting: The deletion of the replica is in progress. - Deleted: The replica has been deleted. - Stopping: The replica is stopping. - Stopped: The replica has stopped (is not receiving traffic). - Failed: The configuration failed to deploy. - Recovering: The replica is attempting to restart after terminating. The last successfully deployed configuration is retained until the new (desired) configuration is successfully deployed. New configurations are applied as "rolling updates." For example: - A replica is created with the desired configuration, - Once that configuration is successfully applied, the replica with the old configuration is deleted, - This process is repeated with each replica in the deployment. This model means there is zero downtime while updates are applied to the application. > [!NOTE] Since updates are applied as rolling updates, there will be different application > versions running at the same time until the update is completed, so make sure your > applications are able to run multiple versions in parallel. ![Replicas status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.10/_images/app-versioning-replica-status.png) Once the configuration is successfully applied and deployed, a message appears at the top of the page. ![Configuration applied successfully status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.10/_images/app-versioning-config-applied-success.png) The application status, configuration identifier, date, and other information is updated in the status box. The new configuration is displayed at the top of the **Config changes** list, along with a **Last successful** label to indicate that it’s the last configuration successfully deployed. If the updates to the configuration fail to deploy, you get an `Desired configuration wasn’t applied` message, and the **Configuration status** displays an `Update failed` label. The configuration is displayed in the **Config changes** history without a label. ![Configuration failed to apply status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.10/_images/app-versioning-update-failed.png) In cases of failure, the deployment attempts to roll back to the last successful version of the configuration, but in certain situations, the rollback may not succeed. The status of the configuration displays `Update failed`. If it’s the first deployment of the application the rollback version won’t be defined and in case of a failed deployment, it remains in the failed status. ## Recommendations when Deploying Stateful Mule Apps - MuleSoft supports [persistent gateway](https://docs.mulesoft.com/runtime-fabric/2.10/persistence-gateway) for higher availability of applications requiring shared storage. - When using Mule [clustering](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters), a rolling update with a Mule runtime version that has a Hazelcast version change will generate a scenario when, at a certain point of time, the cluster will have more than a member with different Hazelcast versions. This may lead to application failure with a Hazelcast serialization error if the Hazelcast versions are incompatible. To prevent this kind of error, use the Recreate update strategy. ## Roll Back to a Previous Successful Configuration If you deploy a configuration that has issues, you can roll back to a previous successful version of the configuration. 1. In the **Config changes** history, select the version to which to roll back. 2. Click **Deploy**. The configuration moves to the top of the list in the **Config changes** history and displays the new deployment date. It retains its original identifying hash. --- product: Runtime Fabric version: 2.11 --- # Reviewing Mule App Versioning on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When an application is deployed to Runtime Fabric, Runtime Manager automatically versions the application and its configuration. Application versioning enables you to: - View the configuration change history of the application. - Roll back the configurations to an earlier version in case the currently applied configuration has issues or is unstable. - View the application status. Possible values are: - Running: At least one replica is receiving traffic (Started state). - Not running: None of the replicas are receiving traffic. - Unknown: The target is disconnected. - Make updates to a deployed application’s configuration, including: - The application package. - Application deployment package version. - Deployment target settings, such as runtime version, number of replicas, and whether the application is running in cluster mode. - Resource allocations, including number of cores and memory allocation. - Ingress and property values. ## Access the Application’s Settings Page 1. Sign into Anypoint Platform and navigate to **Runtime Manager** The **Applications** page is displayed. 2. From the **Applications** page, select an application deployed to Runtime Fabric. 3. Open the management panel on the right side. 4. On the management panel, click the **Manage Application** button. The **Settings** page displays information about the application’s status, configuration history, and other useful information about the application. In the **Config changes** tab on the application’s **Settings** page. Runtime Fabric displays each change to the successfully deployed application configuration. The last ten configuration deployments are displayed in order of their respective configuration date. Each configuration in the history has a unique hash to identify it. ![Configuration page for a Runtime Fabric application, displaying the application file, version, deployment target, runtime version, and replicas](/mulesoft/current/en-us/runtime-fabric/2.11/_images/app-versioning.png) > [!NOTE] The configuration history displays the last ten configuration deployments in order of > creation date. The **All changes** tab displays a history of versions created from the configuration deployment, and the actions performed on each version. ## Apply Configuration Changes 1. On the **Settings** page for the application, you can make these changes to a deployed configuration: - Upload a new application package. - Make changes to the deployment target and resource allocation. - Modify values for **Ingress** and **Properties**. 2. Once your changes are made, click **Apply Changes**. At the top of the **Settings** page, a status bar appears. ![Applying configuration status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.11/_images/app-versioning-applying-config.png) 3. Click **View Status** to view the status for each replica in the deployment. Replica statuses include: - Started: The replica is receiving traffic. - Pending: The replica is waiting to start. - Starting: The replica is starting. - Deleting: The deletion of the replica is in progress. - Deleted: The replica has been deleted. - Stopping: The replica is stopping. - Stopped: The replica has stopped (is not receiving traffic). - Failed: The configuration failed to deploy. - Recovering: The replica is attempting to restart after terminating. The last successfully deployed configuration is retained until the new (desired) configuration is successfully deployed. New configurations are applied as "rolling updates." For example: - A replica is created with the desired configuration, - Once that configuration is successfully applied, the replica with the old configuration is deleted, - This process is repeated with each replica in the deployment. This model means there is zero downtime while updates are applied to the application. > [!NOTE] Since updates are applied as rolling updates, there will be different application > versions running at the same time until the update is completed, so make sure your > applications are able to run multiple versions in parallel. ![Replicas status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.11/_images/app-versioning-replica-status.png) Once the configuration is successfully applied and deployed, a message appears at the top of the page. ![Configuration applied successfully status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.11/_images/app-versioning-config-applied-success.png) The application status, configuration identifier, date, and other information is updated in the status box. The new configuration is displayed at the top of the **Config changes** list, along with a **Last successful** label to indicate that it’s the last configuration successfully deployed. If the updates to the configuration fail to deploy, you get an `Desired configuration wasn’t applied` message, and the **Configuration status** displays an `Update failed` label. The configuration is displayed in the **Config changes** history without a label. ![Configuration failed to apply status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.11/_images/app-versioning-update-failed.png) In cases of failure, the deployment attempts to roll back to the last successful version of the configuration, but in certain situations, the rollback may not succeed. The status of the configuration displays `Update failed`. If it’s the first deployment of the application the rollback version won’t be defined and in case of a failed deployment, it remains in the failed status. ## Recommendations when Deploying Stateful Mule Apps - MuleSoft supports [persistent gateway](https://docs.mulesoft.com/runtime-fabric/2.11/persistence-gateway) for higher availability of applications requiring shared storage. - When using Mule [clustering](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters), a rolling update with a Mule runtime version that has a Hazelcast version change will generate a scenario when, at a certain point of time, the cluster will have more than a member with different Hazelcast versions. This may lead to application failure with a Hazelcast serialization error if the Hazelcast versions are incompatible. To prevent this kind of error, use the Recreate update strategy. ## Roll Back to a Previous Successful Configuration If you deploy a configuration that has issues, you can roll back to a previous successful version of the configuration. 1. In the **Config changes** history, select the version to which to roll back. 2. Click **Deploy**. The configuration moves to the top of the list in the **Config changes** history and displays the new deployment date. It retains its original identifying hash. --- product: Runtime Fabric version: 2.6 --- # Reviewing Mule App Versioning on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When an application is deployed to Runtime Fabric, Runtime Manager automatically versions the application and its configuration. Application versioning enables you to: - View the configuration change history of the application. - Roll back the configurations to an earlier version in case the currently applied configuration has issues or is unstable. - View the application status. Possible values are: - Running: At least one replica is receiving traffic (Started state). - Not running: None of the replicas are receiving traffic. - Unknown: The target is disconnected. - Make updates to a deployed application’s configuration, including: - The application package. - Application deployment package version. - Deployment target settings, such as runtime version, number of replicas, and whether the application is running in cluster mode. - Resource allocations, including number of cores and memory allocation. - Ingress and property values. ## Access the Application’s Settings Page 1. Sign into Anypoint Platform and navigate to **Runtime Manager** The **Applications** page is displayed. 2. From the **Applications** page, select an application deployed to Runtime Fabric. 3. Open the management panel on the right side. 4. On the management panel, click the **Manage Application** button. The **Settings** page displays information about the application’s status, configuration history, and other useful information about the application. In the **Config changes** tab on the application’s **Settings** page. Runtime Fabric displays each change to the successfully deployed application configuration. The last ten configuration deployments are displayed in order of their respective configuration date. Each configuration in the history has a unique hash to identify it. ![Configuration page for a Runtime Fabric application, displaying the application file, version, deployment target, runtime version, and replicas](/mulesoft/current/en-us/runtime-fabric/2.6/_images/app-versioning.png) > [!NOTE] The configuration history displays the last ten configuration deployments in order of > creation date. The **All changes** tab displays a history of versions created from the configuration deployment, and the actions performed on each version. ## Apply Configuration Changes 1. On the **Settings** page for the application, you can make the following changes to a deployed configuration: - Upload a new application package. - Make changes to the deployment target and resource allocation. - Modify values for **Ingress** and **Properties**. 2. Once your changes are made, click **Apply Changes**. At the top of the **Settings** page, a status bar appears. ![Applying configuration status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.6/_images/app-versioning-applying-config.png) 3. Click **View Status** to view the status for each replica in the deployment. Replica statuses include: - Started: The replica is receiving traffic. - Pending: The replica is waiting to start. - Starting: The replica is starting. - Deleting: The deletion of the replica is in progress. - Deleted: The replica has been deleted. - Stopping: The replica is stopping. - Stopped: The replica has stopped (is not receiving traffic). - Failed: The configuration failed to deploy. - Recovering: The replica is attempting to restart after terminating. The last successfully deployed configuration is retained until the new (desired) configuration is successfully deployed. New configurations are applied as "rolling updates." For example: - A replica is created with the desired configuration, - Once that configuration is successfully applied, the replica with the old configuration is deleted, - This process is repeated with each replica in the deployment. This model means there is zero downtime while updates are applied to the application. > [!NOTE] Since updates are applied as rolling updates, there will be different application > versions running at the same time until the update is completed, so make sure your > applications are able to run multiple versions in parallel. ![Replicas status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.6/_images/app-versioning-replica-status.png) Once the configuration is successfully applied and deployed, a message appears at the top of the page. ![Configuration applied successfully status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.6/_images/app-versioning-config-applied-success.png) The application status, configuration identifier, date, and other information is updated in the status box. The new configuration is displayed at the top of the **Config changes** list, along with a **Last successful** label to indicate that it’s the last configuration successfully deployed. If the updates to the configuration fail to deploy, you get an `Desired configuration wasn’t applied` message, and the **Configuration status** displays an `Update failed` label. The configuration is displayed in the **Config changes** history without a label. ![Configuration failed to apply status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.6/_images/app-versioning-update-failed.png) In cases of failure, the deployment attempts to roll back to the last successful version of the configuration, but in certain situations, the rollback may not succeed. The status of the configuration displays `Update failed`. If it’s the first deployment of the application the rollback version won’t be defined and in case of a failed deployment, it remains in the failed status. ## Recommendations when Deploying Stateful Mule Apps - MuleSoft supports [persistent gateway](https://docs.mulesoft.com/runtime-fabric/2.6/persistence-gateway) for higher availability of applications requiring shared storage. - When using Mule [clustering](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters), a rolling update with a Mule runtime version that has a Hazelcast version change will generate a scenario when, at a certain point of time, the cluster will have more than a member with different Hazelcast versions. This may lead to application failure with a Hazelcast serialization error if the Hazelcast versions are incompatible. To prevent this kind of error, use the Recreate update strategy. ## Roll Back to a Previous Successful Configuration If you deploy a configuration that has issues, you can roll back to a previous successful version of the configuration. 1. In the **Config changes** history, select the version to which to roll back. 2. Click **Deploy**. The configuration moves to the top of the list in the **Config changes** history and displays the new deployment date. It retains its original identifying hash. --- product: Runtime Fabric version: 2.7 --- # Reviewing Mule App Versioning on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When an application is deployed to Runtime Fabric, Runtime Manager automatically versions the application and its configuration. Application versioning enables you to: - View the configuration change history of the application. - Roll back the configurations to an earlier version in case the currently applied configuration has issues or is unstable. - View the application status. Possible values are: - Running: At least one replica is receiving traffic (Started state). - Not running: None of the replicas are receiving traffic. - Unknown: The target is disconnected. - Make updates to a deployed application’s configuration, including: - The application package. - Application deployment package version. - Deployment target settings, such as runtime version, number of replicas, and whether the application is running in cluster mode. - Resource allocations, including number of cores and memory allocation. - Ingress and property values. ## Access the Application’s Settings Page 1. Sign into Anypoint Platform and navigate to **Runtime Manager** The **Applications** page is displayed. 2. From the **Applications** page, select an application deployed to Runtime Fabric. 3. Open the management panel on the right side. 4. On the management panel, click the **Manage Application** button. The **Settings** page displays information about the application’s status, configuration history, and other useful information about the application. In the **Config changes** tab on the application’s **Settings** page. Runtime Fabric displays each change to the successfully deployed application configuration. The last ten configuration deployments are displayed in order of their respective configuration date. Each configuration in the history has a unique hash to identify it. ![Configuration page for a Runtime Fabric application, displaying the application file, version, deployment target, runtime version, and replicas](/mulesoft/current/en-us/runtime-fabric/2.7/_images/app-versioning.png) > [!NOTE] The configuration history displays the last ten configuration deployments in order of > creation date. The **All changes** tab displays a history of versions created from the configuration deployment, and the actions performed on each version. ## Apply Configuration Changes 1. On the **Settings** page for the application, you can make the following changes to a deployed configuration: - Upload a new application package. - Make changes to the deployment target and resource allocation. - Modify values for **Ingress** and **Properties**. 2. Once your changes are made, click **Apply Changes**. At the top of the **Settings** page, a status bar appears. ![Applying configuration status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.7/_images/app-versioning-applying-config.png) 3. Click **View Status** to view the status for each replica in the deployment. Replica statuses include: - Started: The replica is receiving traffic. - Pending: The replica is waiting to start. - Starting: The replica is starting. - Deleting: The deletion of the replica is in progress. - Deleted: The replica has been deleted. - Stopping: The replica is stopping. - Stopped: The replica has stopped (is not receiving traffic). - Failed: The configuration failed to deploy. - Recovering: The replica is attempting to restart after terminating. The last successfully deployed configuration is retained until the new (desired) configuration is successfully deployed. New configurations are applied as "rolling updates." For example: - A replica is created with the desired configuration, - Once that configuration is successfully applied, the replica with the old configuration is deleted, - This process is repeated with each replica in the deployment. This model means there is zero downtime while updates are applied to the application. > [!NOTE] Since updates are applied as rolling updates, there will be different application > versions running at the same time until the update is completed, so make sure your > applications are able to run multiple versions in parallel. ![Replicas status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.7/_images/app-versioning-replica-status.png) Once the configuration is successfully applied and deployed, a message appears at the top of the page. ![Configuration applied successfully status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.7/_images/app-versioning-config-applied-success.png) The application status, configuration identifier, date, and other information is updated in the status box. The new configuration is displayed at the top of the **Config changes** list, along with a **Last successful** label to indicate that it’s the last configuration successfully deployed. If the updates to the configuration fail to deploy, you get an `Desired configuration wasn’t applied` message, and the **Configuration status** displays an `Update failed` label. The configuration is displayed in the **Config changes** history without a label. ![Configuration failed to apply status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.7/_images/app-versioning-update-failed.png) In cases of failure, the deployment attempts to roll back to the last successful version of the configuration, but in certain situations, the rollback may not succeed. The status of the configuration displays `Update failed`. If it’s the first deployment of the application the rollback version won’t be defined and in case of a failed deployment, it remains in the failed status. ## Recommendations when Deploying Stateful Mule Apps - MuleSoft supports [persistent gateway](https://docs.mulesoft.com/runtime-fabric/2.7/persistence-gateway) for higher availability of applications requiring shared storage. - When using Mule [clustering](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters), a rolling update with a Mule runtime version that has a Hazelcast version change will generate a scenario when, at a certain point of time, the cluster will have more than a member with different Hazelcast versions. This may lead to application failure with a Hazelcast serialization error if the Hazelcast versions are incompatible. To prevent this kind of error, use the Recreate update strategy. ## Roll Back to a Previous Successful Configuration If you deploy a configuration that has issues, you can roll back to a previous successful version of the configuration. 1. In the **Config changes** history, select the version to which to roll back. 2. Click **Deploy**. The configuration moves to the top of the list in the **Config changes** history and displays the new deployment date. It retains its original identifying hash. --- product: Runtime Fabric version: 2.8 --- # Reviewing Mule App Versioning on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When an application is deployed to Runtime Fabric, Runtime Manager automatically versions the application and its configuration. Application versioning enables you to: - View the configuration change history of the application. - Roll back the configurations to an earlier version in case the currently applied configuration has issues or is unstable. - View the application status. Possible values are: - Running: At least one replica is receiving traffic (Started state). - Not running: None of the replicas are receiving traffic. - Unknown: The target is disconnected. - Make updates to a deployed application’s configuration, including: - The application package. - Application deployment package version. - Deployment target settings, such as runtime version, number of replicas, and whether the application is running in cluster mode. - Resource allocations, including number of cores and memory allocation. - Ingress and property values. ## Access the Application’s Settings Page 1. Sign into Anypoint Platform and navigate to **Runtime Manager** The **Applications** page is displayed. 2. From the **Applications** page, select an application deployed to Runtime Fabric. 3. Open the management panel on the right side. 4. On the management panel, click the **Manage Application** button. The **Settings** page displays information about the application’s status, configuration history, and other useful information about the application. In the **Config changes** tab on the application’s **Settings** page. Runtime Fabric displays each change to the successfully deployed application configuration. The last ten configuration deployments are displayed in order of their respective configuration date. Each configuration in the history has a unique hash to identify it. ![Configuration page for a Runtime Fabric application, displaying the application file, version, deployment target, runtime version, and replicas](/mulesoft/current/en-us/runtime-fabric/2.8/_images/app-versioning.png) > [!NOTE] The configuration history displays the last ten configuration deployments in order of > creation date. The **All changes** tab displays a history of versions created from the configuration deployment, and the actions performed on each version. ## Apply Configuration Changes 1. On the **Settings** page for the application, you can make the following changes to a deployed configuration: - Upload a new application package. - Make changes to the deployment target and resource allocation. - Modify values for **Ingress** and **Properties**. 2. Once your changes are made, click **Apply Changes**. At the top of the **Settings** page, a status bar appears. ![Applying configuration status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.8/_images/app-versioning-applying-config.png) 3. Click **View Status** to view the status for each replica in the deployment. Replica statuses include: - Started: The replica is receiving traffic. - Pending: The replica is waiting to start. - Starting: The replica is starting. - Deleting: The deletion of the replica is in progress. - Deleted: The replica has been deleted. - Stopping: The replica is stopping. - Stopped: The replica has stopped (is not receiving traffic). - Failed: The configuration failed to deploy. - Recovering: The replica is attempting to restart after terminating. The last successfully deployed configuration is retained until the new (desired) configuration is successfully deployed. New configurations are applied as "rolling updates." For example: - A replica is created with the desired configuration, - Once that configuration is successfully applied, the replica with the old configuration is deleted, - This process is repeated with each replica in the deployment. This model means there is zero downtime while updates are applied to the application. > [!NOTE] Since updates are applied as rolling updates, there will be different application > versions running at the same time until the update is completed, so make sure your > applications are able to run multiple versions in parallel. ![Replicas status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.8/_images/app-versioning-replica-status.png) Once the configuration is successfully applied and deployed, a message appears at the top of the page. ![Configuration applied successfully status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.8/_images/app-versioning-config-applied-success.png) The application status, configuration identifier, date, and other information is updated in the status box. The new configuration is displayed at the top of the **Config changes** list, along with a **Last successful** label to indicate that it’s the last configuration successfully deployed. If the updates to the configuration fail to deploy, you get an `Desired configuration wasn’t applied` message, and the **Configuration status** displays an `Update failed` label. The configuration is displayed in the **Config changes** history without a label. ![Configuration failed to apply status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.8/_images/app-versioning-update-failed.png) In cases of failure, the deployment attempts to roll back to the last successful version of the configuration, but in certain situations, the rollback may not succeed. The status of the configuration displays `Update failed`. If it’s the first deployment of the application the rollback version won’t be defined and in case of a failed deployment, it remains in the failed status. ## Recommendations when Deploying Stateful Mule Apps - MuleSoft supports [persistent gateway](https://docs.mulesoft.com/runtime-fabric/2.8/persistence-gateway) for higher availability of applications requiring shared storage. - When using Mule [clustering](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters), a rolling update with a Mule runtime version that has a Hazelcast version change will generate a scenario when, at a certain point of time, the cluster will have more than a member with different Hazelcast versions. This may lead to application failure with a Hazelcast serialization error if the Hazelcast versions are incompatible. To prevent this kind of error, use the Recreate update strategy. ## Roll Back to a Previous Successful Configuration If you deploy a configuration that has issues, you can roll back to a previous successful version of the configuration. 1. In the **Config changes** history, select the version to which to roll back. 2. Click **Deploy**. The configuration moves to the top of the list in the **Config changes** history and displays the new deployment date. It retains its original identifying hash. --- product: Runtime Fabric version: 2.9 --- # Reviewing Mule App Versioning on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When an application is deployed to Runtime Fabric, Runtime Manager automatically versions the application and its configuration. Application versioning enables you to: - View the configuration change history of the application. - Roll back the configurations to an earlier version in case the currently applied configuration has issues or is unstable. - View the application status. Possible values are: - Running: At least one replica is receiving traffic (Started state). - Not running: None of the replicas are receiving traffic. - Unknown: The target is disconnected. - Make updates to a deployed application’s configuration, including: - The application package. - Application deployment package version. - Deployment target settings, such as runtime version, number of replicas, and whether the application is running in cluster mode. - Resource allocations, including number of cores and memory allocation. - Ingress and property values. ## Access the Application’s Settings Page 1. Sign into Anypoint Platform and navigate to **Runtime Manager** The **Applications** page is displayed. 2. From the **Applications** page, select an application deployed to Runtime Fabric. 3. Open the management panel on the right side. 4. On the management panel, click the **Manage Application** button. The **Settings** page displays information about the application’s status, configuration history, and other useful information about the application. In the **Config changes** tab on the application’s **Settings** page. Runtime Fabric displays each change to the successfully deployed application configuration. The last ten configuration deployments are displayed in order of their respective configuration date. Each configuration in the history has a unique hash to identify it. ![Configuration page for a Runtime Fabric application, displaying the application file, version, deployment target, runtime version, and replicas](/mulesoft/current/en-us/runtime-fabric/2.9/_images/app-versioning.png) > [!NOTE] The configuration history displays the last ten configuration deployments in order of > creation date. The **All changes** tab displays a history of versions created from the configuration deployment, and the actions performed on each version. ## Apply Configuration Changes 1. On the **Settings** page for the application, you can make the following changes to a deployed configuration: - Upload a new application package. - Make changes to the deployment target and resource allocation. - Modify values for **Ingress** and **Properties**. 2. Once your changes are made, click **Apply Changes**. At the top of the **Settings** page, a status bar appears. ![Applying configuration status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.9/_images/app-versioning-applying-config.png) 3. Click **View Status** to view the status for each replica in the deployment. Replica statuses include: - Started: The replica is receiving traffic. - Pending: The replica is waiting to start. - Starting: The replica is starting. - Deleting: The deletion of the replica is in progress. - Deleted: The replica has been deleted. - Stopping: The replica is stopping. - Stopped: The replica has stopped (is not receiving traffic). - Failed: The configuration failed to deploy. - Recovering: The replica is attempting to restart after terminating. The last successfully deployed configuration is retained until the new (desired) configuration is successfully deployed. New configurations are applied as "rolling updates." For example: - A replica is created with the desired configuration, - Once that configuration is successfully applied, the replica with the old configuration is deleted, - This process is repeated with each replica in the deployment. This model means there is zero downtime while updates are applied to the application. > [!NOTE] Since updates are applied as rolling updates, there will be different application > versions running at the same time until the update is completed, so make sure your > applications are able to run multiple versions in parallel. ![Replicas status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.9/_images/app-versioning-replica-status.png) Once the configuration is successfully applied and deployed, a message appears at the top of the page. ![Configuration applied successfully status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.9/_images/app-versioning-config-applied-success.png) The application status, configuration identifier, date, and other information is updated in the status box. The new configuration is displayed at the top of the **Config changes** list, along with a **Last successful** label to indicate that it’s the last configuration successfully deployed. If the updates to the configuration fail to deploy, you get an `Desired configuration wasn’t applied` message, and the **Configuration status** displays an `Update failed` label. The configuration is displayed in the **Config changes** history without a label. ![Configuration failed to apply status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.9/_images/app-versioning-update-failed.png) In cases of failure, the deployment attempts to roll back to the last successful version of the configuration, but in certain situations, the rollback may not succeed. The status of the configuration displays `Update failed`. If it’s the first deployment of the application the rollback version won’t be defined and in case of a failed deployment, it remains in the failed status. ## Recommendations when Deploying Stateful Mule Apps - MuleSoft supports [persistent gateway](https://docs.mulesoft.com/runtime-fabric/2.9/persistence-gateway) for higher availability of applications requiring shared storage. - When using Mule [clustering](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters), a rolling update with a Mule runtime version that has a Hazelcast version change will generate a scenario when, at a certain point of time, the cluster will have more than a member with different Hazelcast versions. This may lead to application failure with a Hazelcast serialization error if the Hazelcast versions are incompatible. To prevent this kind of error, use the Recreate update strategy. ## Roll Back to a Previous Successful Configuration If you deploy a configuration that has issues, you can roll back to a previous successful version of the configuration. 1. In the **Config changes** history, select the version to which to roll back. 2. Click **Deploy**. The configuration moves to the top of the list in the **Config changes** history and displays the new deployment date. It retains its original identifying hash. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Reviewing Mule App Versioning on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When an application is deployed to Runtime Fabric, Runtime Manager automatically versions the application and its configuration. Application versioning enables you to: - View the configuration change history of the application. - Roll back the configurations to an earlier version in case the currently applied configuration has issues or is unstable. - View the application status. Possible values are: - Running: At least one replica is receiving traffic (Started state). - Not running: None of the replicas are receiving traffic. - Unknown: The target is disconnected. - Make updates to a deployed application’s configuration, including: - The application package. - Application deployment package version. - Deployment target settings, such as runtime version, number of replicas, and whether the application is running in cluster mode. - Resource allocations, including number of cores and memory allocation. - Ingress and property values. Watch the following video to see how to review the versioning of a Mule application deployed to Runtime Fabric by using Runtime Manager: ![](https://play.vidyard.com/bGcLD8Z7zM7H5cm7xWCw5C.jpg) ## Access the Application’s Settings Page 1. Sign into Anypoint Platform and navigate to **Runtime Manager** The **Applications** page is displayed. 2. From the **Applications** page, select an application deployed to Runtime Fabric. 3. Open the management panel on the right side. 4. On the management panel, click the **Manage Application** button. The **Settings** page displays information about the application’s status, configuration history, and other useful information about the application. In the **Config changes** tab on the application’s **Settings** page. Runtime Fabric displays each change to the successfully deployed application configuration. The last ten configuration deployments are displayed in order of their respective configuration date. Each configuration in the history has a unique hash to identify it. ![Configuration page for a Runtime Fabric application, displaying the application file, version, deployment target, runtime version, and replicas](/mulesoft/current/en-us/runtime-fabric/latest/_images/app-versioning.png) > [!NOTE] The configuration history displays the last ten configuration deployments in order of > creation date. The **All changes** tab displays a history of versions created from the configuration deployment, and the actions performed on each version. ## Apply Configuration Changes 1. On the **Settings** page for the application, you can make the following changes to a deployed configuration: - Upload a new application package. - Make changes to the deployment target and resource allocation. - Modify values for **Ingress** and **Properties**. 2. Once your changes are made, click **Apply Changes**. At the top of the **Settings** page, a status bar appears. ![Applying configuration status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/latest/_images/app-versioning-applying-config.png) 3. Click **View Status** to view the status for each replica in the deployment. Replica statuses include: - Started: The replica is receiving traffic. - Pending: The replica is waiting to start. - Starting: The replica is starting. - Deleting: The deletion of the replica is in progress. - Deleted: The replica has been deleted. - Stopping: The replica is stopping. - Stopped: The replica has stopped (is not receiving traffic). - Failed: The configuration failed to deploy. - Recovering: The replica is attempting to restart after terminating. The last successfully deployed configuration is retained until the new (desired) configuration is successfully deployed. New configurations are applied as "rolling updates." For example: - A replica is created with the desired configuration, - Once that configuration is successfully applied, the replica with the old configuration is deleted, - This process is repeated with each replica in the deployment. This model means there is zero downtime while updates are applied to the application. > [!NOTE] Since updates are applied as rolling updates, there will be different application > versions running at the same time until the update is completed, so make sure your > applications are able to run multiple versions in parallel. ![Replicas status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/latest/_images/app-versioning-replica-status.png) Once the configuration is successfully applied and deployed, a message appears at the top of the page. ![Configuration applied successfully status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/latest/_images/app-versioning-config-applied-success.png) The application status, configuration identifier, date, and other information is updated in the status box. The new configuration is displayed at the top of the **Config changes** list, along with a **Last successful** label to indicate that it’s the last configuration successfully deployed. If the updates to the configuration fail to deploy, you get an `Desired configuration wasn’t applied` message, and the **Configuration status** displays an `Update failed` label. The configuration is displayed in the **Config changes** history without a label. ![Configuration failed to apply status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/latest/_images/app-versioning-update-failed.png) In cases of failure, the deployment attempts to roll back to the last successful version of the configuration, but in certain situations, the rollback may not succeed. The status of the configuration displays `Update failed`. If it’s the first deployment of the application the rollback version won’t be defined and in case of a failed deployment, it remains in the failed status. ## Recommendations when Deploying Stateful Mule Apps - MuleSoft supports [persistent gateway](https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway) for higher availability of applications requiring shared storage. - When using Mule [clustering](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters), a rolling update with a Mule runtime version that has a Hazelcast version change will generate a scenario when, at a certain point of time, the cluster will have more than a member with different Hazelcast versions. This may lead to application failure with a Hazelcast serialization error if the Hazelcast versions are incompatible. To prevent this kind of error, use the Recreate update strategy. ## Roll Back to a Previous Successful Configuration If you deploy a configuration that has issues, you can roll back to a previous successful version of the configuration. 1. In the **Config changes** history, select the version to which to roll back. 2. Click **Deploy**. The configuration moves to the top of the list in the **Config changes** history and displays the new deployment date. It retains its original identifying hash. --- product: Runtime Fabric version: 2.10 --- # RTFCTL Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To successfully run `rtfctl` commands, you must understand and enable specific role permissions over Kubernetes resources. The following table lists the permissions that you configure using Kubernetes (K8s) RBACs ([role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)):
rtfctl CommandNamespaceAPI GroupsKubernetes ResourcesVerbs

apply

rtf

configmaps

create, get, patch, update

pods

deletecollection

<app-namespace>

secrets

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

secrets

create, get, patch, update

update

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

wait

rtf

configmaps, secret

get

rtfctl-audit

secrets

create, get, patch, update

apps

daemonsets, deployments

get, list, watch

namespaces

create

install

rtf

configmaps, pods/log

get

pods

get, list, watch

secrets

create, get

serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create

backup

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

configmaps, namespaces, secrets, serviceaccounts, services

get, list, watch

apiextensions.k8s.io

customresourcedefinitions

get

apps

daemonsets, deployments

get, list, watch

batch

cronjobs

get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

clusterrolebindings, clusterroles, rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways

get, list, watch

scheduling.k8s.io

priorityclasses

get

restore

rtf

apps

daemonsets

create, get, patch, update

batch

cronjobs

create, get, patch, update

rtf.mulesoft.com

persistencegateways

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

configmaps, namespaces, secrets, serviceaccounts, services

create, get, patch, update

apiextensions.k8s.io

customresourcedefinitions

get, patch, update

apps

deployments

create, get, patch, update

networking.k8s.io

ingresses

create, get, patch, update

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, get, patch, update

scheduling.k8s.io

priorityclasses

create, get, patch, update

validate

rtf

configmaps

get

pods

deletecollection

secrets

delete, get

batch

jobs

delete

rtf-validate

namespaces

delete, get

pods/log

get

secrets, serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

nodes, pods

get, list, watch

authorization.k8s.io

selfsubjectaccessreviews

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, delete

version

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

delete

<app-namespace>

pods

get, list, watch

secrets

get, list, patch, update, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

describe

<app-namespace>

pods

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

disk

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

memory

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

package

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

restart

<app-namespace>

pods

delete, get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

heapdump

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

threaddump

<app-namespace>

secrets

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

get

<app-namespace>

secrets

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

report

rtf

configmaps, limitranges, resourcequotas, secrets, serviceaccounts, services

get, list, watch

endpoints, pods/log

get

apps

daemonsets, deployments, replicasets

get, list, watch

batch

cronjobs

get, list, watch

batch

jobs

create, delete, get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways, kubernetestemplates

get, list, watch

kube-node-lease

coordination.k8s.io

leases

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

events, nodes, pods

get, list, watch

status

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

test

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

nodes

get, list, watch

namespaces

create

- Namespace Permissions can be role-based or cluster role-based: - Role-based: the namespace can be rtf, , rtf-validate, or kube-node-lease. - Cluster role-based: because it applies to the entire cluster, the namespace field doesn’t exist and is blank in the table. - apiGroups The API group for the K8s resources. When you create a role, each K8s resource declares its API group or uses the core API group if not specified. Refer to [API groups](https://kubernetes.io/docs/reference/using-api/#api-groups) for details. - Kubernetes Resource Type of Kubernetes resources, for example, `pods`, `services`, or `secrets` to which the permissions apply. - Verbs Actions that are allowed on the specified Kubernetes resources. ## See Also - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.10/rtf-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.11 --- # RTFCTL Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To successfully run `rtfctl` commands, you must understand and enable specific role permissions over Kubernetes resources. The following table lists the permissions that you configure using Kubernetes (K8s) RBACs ([role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)):
rtfctl CommandNamespaceAPI GroupsKubernetes ResourcesVerbs

apply

rtf

configmaps

create, get, patch, update

pods

deletecollection

<app-namespace>

secrets

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

secrets

create, get, patch, update

update

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

wait

rtf

configmaps, secret

get

rtfctl-audit

secrets

create, get, patch, update

apps

daemonsets, deployments

get, list, watch

namespaces

create

install

rtf

configmaps, pods/log

get

pods

get, list, watch

secrets

create, get

serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create

backup

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

configmaps, namespaces, secrets, serviceaccounts, services

get, list, watch

apiextensions.k8s.io

customresourcedefinitions

get

apps

daemonsets, deployments

get, list, watch

batch

cronjobs

get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

clusterrolebindings, clusterroles, rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways

get, list, watch

scheduling.k8s.io

priorityclasses

get

restore

rtf

apps

daemonsets

create, get, patch, update

batch

cronjobs

create, get, patch, update

rtf.mulesoft.com

persistencegateways

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

configmaps, namespaces, secrets, serviceaccounts, services

create, get, patch, update

apiextensions.k8s.io

customresourcedefinitions

get, patch, update

apps

deployments

create, get, patch, update

networking.k8s.io

ingresses

create, get, patch, update

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, get, patch, update

scheduling.k8s.io

priorityclasses

create, get, patch, update

validate

rtf

configmaps

get

pods

deletecollection

secrets

delete, get

batch

jobs

delete

rtf-validate

namespaces

delete, get

pods/log

get

secrets, serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

nodes, pods

get, list, watch

authorization.k8s.io

selfsubjectaccessreviews

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, delete

version

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

delete

<app-namespace>

pods

get, list, watch

secrets

get, list, patch, update, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

describe

<app-namespace>

pods

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

disk

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

memory

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

package

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

restart

<app-namespace>

pods

delete, get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

heapdump

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

threaddump

<app-namespace>

secrets

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

get

<app-namespace>

secrets

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

report

rtf

configmaps, limitranges, resourcequotas, secrets, serviceaccounts, services

get, list, watch

endpoints, pods/log

get

apps

daemonsets, deployments, replicasets

get, list, watch

batch

cronjobs

get, list, watch

batch

jobs

create, delete, get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways, kubernetestemplates

get, list, watch

kube-node-lease

coordination.k8s.io

leases

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

events, nodes, pods

get, list, watch

status

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

test

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

nodes

get, list, watch

namespaces

create

- Namespace Permissions can be role-based or cluster role-based: - Role-based: the namespace can be rtf, , rtf-validate, or kube-node-lease. - Cluster role-based: because it applies to the entire cluster, the namespace field doesn’t exist and is blank in the table. - apiGroups The API group for the K8s resources. When you create a role, each K8s resource declares its API group or uses the core API group if not specified. Refer to [API groups](https://kubernetes.io/docs/reference/using-api/#api-groups) for details. - Kubernetes Resource Type of Kubernetes resources, for example, `pods`, `services`, or `secrets` to which the permissions apply. - Verbs Actions that are allowed on the specified Kubernetes resources. ## See Also - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.11/rtf-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.5 --- # RTFCTL Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To successfully run `rtfctl` commands, you must understand and enable specific role permissions over Kubernetes resources. The following table lists the permissions that you configure using Kubernetes (K8s) RBACs ([role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)):
rtfctl CommandNamespaceAPI GroupsKubernetes ResourcesVerbs

apply

rtf

configmaps

create, get, patch, update

pods

deletecollection

<app-namespace>

secrets

get, list, watch

namespaces

get, list, watch

secrets

create, get, patch, update

update

rtf

configmaps, secrets

get

wait

rtf

configmaps, secret

get

apps

daemonsets, deployments

get, list, watch

install

rtf

configmaps, pods/log

get

pods

get, list, watch

secrets

create, get

serviceaccounts

create

batch

jobs

create, get

namespaces

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create

backup

configmaps, namespaces, secrets, serviceaccounts, services

get, list, watch

apiextensions.k8s.io

customresourcedefinitions

get

apps

daemonsets, deployments

get, list, watch

batch

cronjobs

get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

clusterrolebindings, clusterroles, rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways

get, list, watch

scheduling.k8s.io

priorityclasses

get

restore

rtf

apps

daemonsets

create, get, patch, update

batch

cronjobs

create, get, patch, update

rtf.mulesoft.com

persistencegateways

get, list, watch

configmaps, namespaces, secrets, serviceaccounts, services

create, get, patch, update

apiextensions.k8s.io

customresourcedefinitions

get, patch, update

apps

deployments

create, get, patch, update

networking.k8s.io

ingresses

create, get, patch, update

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, get, patch, update

scheduling.k8s.io

priorityclasses

create, get, patch, update

validate

rtf

configmaps

get

pods

deletecollection

secrets

delete, get

batch

jobs

delete

rtf-validate

namespaces

delete, get

pods/log

get

secrets, serviceaccounts

create

batch

jobs

create, get

namespaces

create

nodes, pods

get, list, watch

authorization.k8s.io

selfsubjectaccessreviews

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, delete

version

rtf

configmaps, secrets

get

delete

<app-namespace>

pods

get, list, watch

secrets

get, list, patch, update, watch

rtf

configmaps, secrets

get

describe

<app-namespace>

pods

get, list, watch

rtf

configmaps, secrets

get

apps

deployments

get, list, watch

disk

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

memory

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

package

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

restart

<app-namespace>

pods

delete, get, list, watch

rtf

configmaps, secrets

get

heapdump

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

threaddump

<app-namespace>

secrets

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

get

<app-namespace>

secrets

get, list, watch

rtf

configmaps, secrets

get

apps

deployments

get, list, watch

report

rtf

configmaps, limitranges, resourcequotas, secrets, serviceaccounts, services

get, list, watch

endpoints, pods/log

get

apps

daemonsets, deployments, replicasets

get, list, watch

batch

cronjobs

get, list, watch

batch

jobs

create, delete, get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

roldebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways

get, list, watch

kube-node-lease

coordination.k8s.io

leases

get

events, namespaces, nodes, pods

get, list, watch

status

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

test

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

nodes

get, list, watch

- Namespace Permissions can be role-based or cluster role-based: - Role-based: the namespace can be rtf, , rtf-validate, or kube-node-lease. - Cluster role-based: because it applies to the entire cluster, the namespace field doesn’t exist and is blank in the table. - apiGroups The API group for the K8s resources. When you create a role, each K8s resource declares its API group or uses the core API group if not specified. Refer to [API groups](https://kubernetes.io/docs/reference/using-api/#api-groups) for details. - Kubernetes Resource Type of Kubernetes resources, for example, `pods`, `services`, or `secrets` to which the permissions apply. - Verbs Actions that are allowed on the specified Kubernetes resources. --- product: Runtime Fabric version: 2.6 --- # RTFCTL Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To successfully run `rtfctl` commands, you must understand and enable specific role permissions over Kubernetes resources. The following table lists the permissions that you configure using Kubernetes (K8s) RBACs ([role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)):
rtfctl CommandNamespaceAPI GroupsKubernetes ResourcesVerbs

apply

rtf

configmaps

create, get, patch, update

pods

deletecollection

<app-namespace>

secrets

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

secrets

create, get, patch, update

update

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

wait

rtf

configmaps, secret

get

rtfctl-audit

secrets

create, get, patch, update

apps

daemonsets, deployments

get, list, watch

namespaces

create

install

rtf

configmaps, pods/log

get

pods

get, list, watch

secrets

create, get

serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create

backup

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

configmaps, namespaces, secrets, serviceaccounts, services

get, list, watch

apiextensions.k8s.io

customresourcedefinitions

get

apps

daemonsets, deployments

get, list, watch

batch

cronjobs

get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

clusterrolebindings, clusterroles, rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways

get, list, watch

scheduling.k8s.io

priorityclasses

get

restore

rtf

apps

daemonsets

create, get, patch, update

batch

cronjobs

create, get, patch, update

rtf.mulesoft.com

persistencegateways

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

configmaps, namespaces, secrets, serviceaccounts, services

create, get, patch, update

apiextensions.k8s.io

customresourcedefinitions

get, patch, update

apps

deployments

create, get, patch, update

networking.k8s.io

ingresses

create, get, patch, update

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, get, patch, update

scheduling.k8s.io

priorityclasses

create, get, patch, update

validate

rtf

configmaps

get

pods

deletecollection

secrets

delete, get

batch

jobs

delete

rtf-validate

namespaces

delete, get

pods/log

get

secrets, serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

nodes, pods

get, list, watch

authorization.k8s.io

selfsubjectaccessreviews

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, delete

version

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

delete

<app-namespace>

pods

get, list, watch

secrets

get, list, patch, update, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

describe

<app-namespace>

pods

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

disk

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

memory

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

package

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

restart

<app-namespace>

pods

delete, get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

heapdump

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

threaddump

<app-namespace>

secrets

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

get

<app-namespace>

secrets

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

report

rtf

configmaps, limitranges, resourcequotas, secrets, serviceaccounts, services

get, list, watch

endpoints, pods/log

get

apps

daemonsets, deployments, replicasets

get, list, watch

batch

cronjobs

get, list, watch

batch

jobs

create, delete, get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways

get, list, watch

kube-node-lease

coordination.k8s.io

leases

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

events, nodes, pods

get, list, watch

status

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

test

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

nodes

get, list, watch

namespaces

create

- Namespace Permissions can be role-based or cluster role-based: - Role-based: the namespace can be rtf, , rtf-validate, or kube-node-lease. - Cluster role-based: because it applies to the entire cluster, the namespace field doesn’t exist and is blank in the table. - apiGroups The API group for the K8s resources. When you create a role, each K8s resource declares its API group or uses the core API group if not specified. Refer to [API groups](https://kubernetes.io/docs/reference/using-api/#api-groups) for details. - Kubernetes Resource Type of Kubernetes resources, for example, `pods`, `services`, or `secrets` to which the permissions apply. - Verbs Actions that are allowed on the specified Kubernetes resources. ## See Also - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.6/rtf-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.7 --- # RTFCTL Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To successfully run `rtfctl` commands, you must understand and enable specific role permissions over Kubernetes resources. The following table lists the permissions that you configure using Kubernetes (K8s) RBACs ([role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)):
rtfctl CommandNamespaceAPI GroupsKubernetes ResourcesVerbs

apply

rtf

configmaps

create, get, patch, update

pods

deletecollection

<app-namespace>

secrets

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

secrets

create, get, patch, update

update

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

wait

rtf

configmaps, secret

get

rtfctl-audit

secrets

create, get, patch, update

apps

daemonsets, deployments

get, list, watch

namespaces

create

install

rtf

configmaps, pods/log

get

pods

get, list, watch

secrets

create, get

serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create

backup

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

configmaps, namespaces, secrets, serviceaccounts, services

get, list, watch

apiextensions.k8s.io

customresourcedefinitions

get

apps

daemonsets, deployments

get, list, watch

batch

cronjobs

get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

clusterrolebindings, clusterroles, rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways

get, list, watch

scheduling.k8s.io

priorityclasses

get

restore

rtf

apps

daemonsets

create, get, patch, update

batch

cronjobs

create, get, patch, update

rtf.mulesoft.com

persistencegateways

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

configmaps, namespaces, secrets, serviceaccounts, services

create, get, patch, update

apiextensions.k8s.io

customresourcedefinitions

get, patch, update

apps

deployments

create, get, patch, update

networking.k8s.io

ingresses

create, get, patch, update

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, get, patch, update

scheduling.k8s.io

priorityclasses

create, get, patch, update

validate

rtf

configmaps

get

pods

deletecollection

secrets

delete, get

batch

jobs

delete

rtf-validate

namespaces

delete, get

pods/log

get

secrets, serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

nodes, pods

get, list, watch

authorization.k8s.io

selfsubjectaccessreviews

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, delete

version

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

delete

<app-namespace>

pods

get, list, watch

secrets

get, list, patch, update, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

describe

<app-namespace>

pods

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

disk

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

memory

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

package

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

restart

<app-namespace>

pods

delete, get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

heapdump

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

threaddump

<app-namespace>

secrets

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

get

<app-namespace>

secrets

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

report

rtf

configmaps, limitranges, resourcequotas, secrets, serviceaccounts, services

get, list, watch

endpoints, pods/log

get

apps

daemonsets, deployments, replicasets

get, list, watch

batch

cronjobs

get, list, watch

batch

jobs

create, delete, get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways, kubernetestemplates

get, list, watch

kube-node-lease

coordination.k8s.io

leases

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

events, nodes, pods

get, list, watch

status

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

test

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

nodes

get, list, watch

namespaces

create

- Namespace Permissions can be role-based or cluster role-based: - Role-based: the namespace can be rtf, , rtf-validate, or kube-node-lease. - Cluster role-based: because it applies to the entire cluster, the namespace field doesn’t exist and is blank in the table. - apiGroups The API group for the K8s resources. When you create a role, each K8s resource declares its API group or uses the core API group if not specified. Refer to [API groups](https://kubernetes.io/docs/reference/using-api/#api-groups) for details. - Kubernetes Resource Type of Kubernetes resources, for example, `pods`, `services`, or `secrets` to which the permissions apply. - Verbs Actions that are allowed on the specified Kubernetes resources. ## See Also - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.7/rtf-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.8 --- # RTFCTL Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To successfully run `rtfctl` commands, you must understand and enable specific role permissions over Kubernetes resources. The following table lists the permissions that you configure using Kubernetes (K8s) RBACs ([role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)):
rtfctl CommandNamespaceAPI GroupsKubernetes ResourcesVerbs

apply

rtf

configmaps

create, get, patch, update

pods

deletecollection

<app-namespace>

secrets

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

secrets

create, get, patch, update

update

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

wait

rtf

configmaps, secret

get

rtfctl-audit

secrets

create, get, patch, update

apps

daemonsets, deployments

get, list, watch

namespaces

create

install

rtf

configmaps, pods/log

get

pods

get, list, watch

secrets

create, get

serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create

backup

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

configmaps, namespaces, secrets, serviceaccounts, services

get, list, watch

apiextensions.k8s.io

customresourcedefinitions

get

apps

daemonsets, deployments

get, list, watch

batch

cronjobs

get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

clusterrolebindings, clusterroles, rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways

get, list, watch

scheduling.k8s.io

priorityclasses

get

restore

rtf

apps

daemonsets

create, get, patch, update

batch

cronjobs

create, get, patch, update

rtf.mulesoft.com

persistencegateways

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

configmaps, namespaces, secrets, serviceaccounts, services

create, get, patch, update

apiextensions.k8s.io

customresourcedefinitions

get, patch, update

apps

deployments

create, get, patch, update

networking.k8s.io

ingresses

create, get, patch, update

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, get, patch, update

scheduling.k8s.io

priorityclasses

create, get, patch, update

validate

rtf

configmaps

get

pods

deletecollection

secrets

delete, get

batch

jobs

delete

rtf-validate

namespaces

delete, get

pods/log

get

secrets, serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

nodes, pods

get, list, watch

authorization.k8s.io

selfsubjectaccessreviews

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, delete

version

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

delete

<app-namespace>

pods

get, list, watch

secrets

get, list, patch, update, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

describe

<app-namespace>

pods

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

disk

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

memory

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

package

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

restart

<app-namespace>

pods

delete, get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

heapdump

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

threaddump

<app-namespace>

secrets

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

get

<app-namespace>

secrets

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

report

rtf

configmaps, limitranges, resourcequotas, secrets, serviceaccounts, services

get, list, watch

endpoints, pods/log

get

apps

daemonsets, deployments, replicasets

get, list, watch

batch

cronjobs

get, list, watch

batch

jobs

create, delete, get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways, kubernetestemplates

get, list, watch

kube-node-lease

coordination.k8s.io

leases

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

events, nodes, pods

get, list, watch

status

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

test

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

nodes

get, list, watch

namespaces

create

- Namespace Permissions can be role-based or cluster role-based: - Role-based: the namespace can be rtf, , rtf-validate, or kube-node-lease. - Cluster role-based: because it applies to the entire cluster, the namespace field doesn’t exist and is blank in the table. - apiGroups The API group for the K8s resources. When you create a role, each K8s resource declares its API group or uses the core API group if not specified. Refer to [API groups](https://kubernetes.io/docs/reference/using-api/#api-groups) for details. - Kubernetes Resource Type of Kubernetes resources, for example, `pods`, `services`, or `secrets` to which the permissions apply. - Verbs Actions that are allowed on the specified Kubernetes resources. ## See Also - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.8/rtf-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.9 --- # RTFCTL Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To successfully run `rtfctl` commands, you must understand and enable specific role permissions over Kubernetes resources. The following table lists the permissions that you configure using Kubernetes (K8s) RBACs ([role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)):
rtfctl CommandNamespaceAPI GroupsKubernetes ResourcesVerbs

apply

rtf

configmaps

create, get, patch, update

pods

deletecollection

<app-namespace>

secrets

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

secrets

create, get, patch, update

update

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

wait

rtf

configmaps, secret

get

rtfctl-audit

secrets

create, get, patch, update

apps

daemonsets, deployments

get, list, watch

namespaces

create

install

rtf

configmaps, pods/log

get

pods

get, list, watch

secrets

create, get

serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create

backup

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

configmaps, namespaces, secrets, serviceaccounts, services

get, list, watch

apiextensions.k8s.io

customresourcedefinitions

get

apps

daemonsets, deployments

get, list, watch

batch

cronjobs

get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

clusterrolebindings, clusterroles, rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways

get, list, watch

scheduling.k8s.io

priorityclasses

get

restore

rtf

apps

daemonsets

create, get, patch, update

batch

cronjobs

create, get, patch, update

rtf.mulesoft.com

persistencegateways

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

configmaps, namespaces, secrets, serviceaccounts, services

create, get, patch, update

apiextensions.k8s.io

customresourcedefinitions

get, patch, update

apps

deployments

create, get, patch, update

networking.k8s.io

ingresses

create, get, patch, update

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, get, patch, update

scheduling.k8s.io

priorityclasses

create, get, patch, update

validate

rtf

configmaps

get

pods

deletecollection

secrets

delete, get

batch

jobs

delete

rtf-validate

namespaces

delete, get

pods/log

get

secrets, serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

nodes, pods

get, list, watch

authorization.k8s.io

selfsubjectaccessreviews

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, delete

version

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

delete

<app-namespace>

pods

get, list, watch

secrets

get, list, patch, update, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

describe

<app-namespace>

pods

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

disk

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

memory

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

package

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

restart

<app-namespace>

pods

delete, get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

heapdump

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

threaddump

<app-namespace>

secrets

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

get

<app-namespace>

secrets

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

report

rtf

configmaps, limitranges, resourcequotas, secrets, serviceaccounts, services

get, list, watch

endpoints, pods/log

get

apps

daemonsets, deployments, replicasets

get, list, watch

batch

cronjobs

get, list, watch

batch

jobs

create, delete, get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways, kubernetestemplates

get, list, watch

kube-node-lease

coordination.k8s.io

leases

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

events, nodes, pods

get, list, watch

status

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

test

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

nodes

get, list, watch

namespaces

create

- Namespace Permissions can be role-based or cluster role-based: - Role-based: the namespace can be rtf, , rtf-validate, or kube-node-lease. - Cluster role-based: because it applies to the entire cluster, the namespace field doesn’t exist and is blank in the table. - apiGroups The API group for the K8s resources. When you create a role, each K8s resource declares its API group or uses the core API group if not specified. Refer to [API groups](https://kubernetes.io/docs/reference/using-api/#api-groups) for details. - Kubernetes Resource Type of Kubernetes resources, for example, `pods`, `services`, or `secrets` to which the permissions apply. - Verbs Actions that are allowed on the specified Kubernetes resources. ## See Also - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.9/rtf-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/rtf-mule-app-permissions) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # RTFCTL Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To successfully run `rtfctl` commands, you must understand and enable specific role permissions over Kubernetes resources. The following table lists the permissions that you configure using Kubernetes (K8s) RBACs ([role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)):
rtfctl CommandNamespaceAPI GroupsKubernetes ResourcesVerbs

apply

rtf

configmaps

create, get, patch, update

pods

deletecollection

<app-namespace>

secrets

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

secrets

create, get, patch, update

update

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

wait

rtf

configmaps, secret

get

rtfctl-audit

secrets

create, get, patch, update

apps

daemonsets, deployments

get, list, watch

namespaces

create

install

rtf

configmaps, pods/log

get

pods

get, list, watch

secrets

create, get

serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create

backup

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

configmaps, namespaces, secrets, serviceaccounts, services

get, list, watch

apiextensions.k8s.io

customresourcedefinitions

get

apps

daemonsets, deployments

get, list, watch

batch

cronjobs

get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

clusterrolebindings, clusterroles, rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways, kubernetestemplates, httproutetemplates, muleapplications

get, list, watch

scheduling.k8s.io

priorityclasses

get

restore

rtf

apps

daemonsets

create, get, patch, update

batch

cronjobs

create, get, patch, update

rtf.mulesoft.com

persistencegateways

get, list, watch

rtfctl-audit

secrets

create, get, patch, update

configmaps, namespaces, secrets, serviceaccounts, services

create, get, patch, update

apiextensions.k8s.io

customresourcedefinitions

get, patch, update

apps

deployments

create, get, patch, update

networking.k8s.io

ingresses

create, get, patch, update

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, get, patch, update

scheduling.k8s.io

priorityclasses

create, get, patch, update

validate

rtf

configmaps

get

pods

deletecollection

secrets

delete, get

batch

jobs

delete

rtf-validate

namespaces

delete, get

pods/log

get

secrets, serviceaccounts

create

batch

jobs

create, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

nodes, pods

get, list, watch

authorization.k8s.io

selfsubjectaccessreviews

create

rbac.authorization.k8s.io

clusterrolebindings, clusterroles

create, delete

version

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

delete

<app-namespace>

pods

get, list, watch

secrets

get, list, patch, update, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

describe

<app-namespace>

pods

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

disk

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

memory

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

package

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

restart

<app-namespace>

pods

delete, get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

heapdump

<app-namespace>

pods

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

threaddump

<app-namespace>

secrets

get, list, watch

pods/exec

create

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

get

<app-namespace>

secrets

get, list, watch

rtf

configmaps, secrets

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

apps

deployments

get, list, watch

report

rtf

configmaps, limitranges, resourcequotas, secrets, serviceaccounts, services

get, list, watch

endpoints, pods/log

get

apps

daemonsets, deployments, replicasets

get, list, watch

batch

cronjobs

get, list, watch

batch

jobs

create, delete, get, list, watch

networking.k8s.io

ingresses

get, list, watch

rbac.authorization.k8s.io

rolebindings, roles

get, list, watch

rtf.mulesoft.com

persistencegateways, kubernetestemplates

get, list, watch

kube-node-lease

coordination.k8s.io

leases

get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create, get, list, watch

events, nodes, pods

get, list, watch

status

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

namespaces

create

test

rtf

configmaps, pods/log, secrets

get

pods

create, delete, get, list, watch

batch

jobs

create, delete, get

rtfctl-audit

secrets

create, get, patch, update

nodes

get, list, watch

namespaces

create

- Namespace Permissions can be role-based or cluster role-based: - Role-based: the namespace can be rtf, , rtf-validate, or kube-node-lease. - Cluster role-based: because it applies to the entire cluster, the namespace field doesn’t exist and is blank in the table. - apiGroups The API group for the K8s resources. When you create a role, each K8s resource declares its API group or uses the core API group if not specified. Refer to [API groups](https://kubernetes.io/docs/reference/using-api/#api-groups) for details. - Kubernetes Resource Type of Kubernetes resources, for example, `pods`, `services`, or `secrets` to which the permissions apply. - Verbs Actions that are allowed on the specified Kubernetes resources. ## See Also - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/latest/rtf-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.10 --- # RTFCTL Reference > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use this reference for `rtfctl` commands. ## Install, Upgrade, Back up, or Restore Runtime Fabric with RTFCTL Use these commands to install, upgrade, back up or restore a Runtime Fabric.
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

### `get` Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ### `ping` Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ### `report` Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ### `status` Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ### `test` Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## Configure Runtime Fabric with RTFCTL Use these commands to configure Runtime Fabric.
CommandDescription

Applies changes to a Runtime Fabric configuration

Updates rtfctl

Waits for Runtime Fabric components to become ready

Renews an expired client certificate using a pre-downloaded package

### `apply` Applies changes to a Runtime Fabric configuration. > [!NOTE] You can use the `rtfctl apply system-configuration` command to update OpenShift > system-configuration values. Other rtfctl apply commands are not effective for OpenShift. For any > other updates, modify the values in the OpenShift console. - Applies an HTTP proxy configuration rtfctl apply http-proxy http://: --namespace - Applies an HTTP proxy configuration with hostnames bypassing the proxy rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - Applies an HTTP proxy configuration with authentication rtfctl apply http-proxy http://:@: --namespace - Clears an HTTP proxy configuration rtfctl apply http-proxy "" --no-proxy "" --namespace - Applies a secure property rtfctl apply secure-property --key --value --app-namespace --namespace - Applies a system configuration on a host node rtfctl apply system-configuration - Applies a system configuration on a host node without downloading the latest scripts rtfctl apply system-configuration --skip-download - Applies a Mule license rtfctl apply mule-license --namespace If Runtime Fabric is installed via Helm, you must update the `mule-license` property in the Helm values. - Applies a monitoring proxy rtfctl apply monitoring-proxy http://: --namespace - Clears a monitoring proxy configuration rtfctl apply monitoring-proxy "" --namespace ### `update` Updates `rtfctl`. - Updates from the US control plane rtfctl update - Updates `rtfctl` from the EU control plane rtfctl update --host eu1.anypoint.mulesoft.com ### `wait` Waits for Runtime Fabric components to become ready - Specifies the number of seconds to wait rtfctl wait --namespace - Specifies the number of seconds to pass before timing out the wait (Default is 600 seconds) rtfctl wait --timeout --namespace ### `renew` Renews an expired client certificate using a pre-downloaded package rtfctl renew-expired-client-cert ## Troubleshoot Runtime Fabric with RTFCTL Use these commands to troubleshoot Runtime Fabric.
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

### `get` Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ### `ping` Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ### `report` Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ### `status` Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ### `test` Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## Manage Mule Apps on Runtime Fabric with RTFCTL Use these commands to manage applications deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays disk usage for an application

Restarts an application

### `delete` Deletes a secure property rtfctl delete secure-property -n ### `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ### `restart` Restarts an application rtfctl restart --app-namespace --namespace ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl) --- product: Runtime Fabric version: 2.11 --- # RTFCTL Reference > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use this reference for `rtfctl` commands. ## Install, Upgrade, and Validate Runtime Fabric with RTFCTL Use these commands to install, upgrade, and validate a Runtime Fabric.
CommandDescription

Installs Runtime Fabric

Validates the cluster for Runtime Fabric installation

Displays the Runtime Fabric version information

### `install` - Installs Runtime Fabric rtfctl install - Override the Docker image registry URL and secret rtfctl install --image-pull-registry --image-pull-secret ### `validate` Validates the cluster for a Runtime Fabric installation - Performs a validation check rtfctl validate - Performs a validation check and passes the `fabric.tf` configuration file that contains proxy settings rtfctl validate -f To validate installation with a proxy, you must specify proxy settings in your `settings` file: MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://.com: - Override the Docker image registry URL and secret rtfctl validate --image-pull-registry --image-pull-secret ### `version` Displays the Runtime Fabric version information rtfctl version --namespace ## Back Up and Restore a Runtime Fabric with RTFCTL Use these commands to back up and restore a Runtime Fabric.
CommandDescription

Performs a back up of the local Runtime Fabric state

Restores local Runtime Fabric state from a backup

### `backup` Performs a back up of the local Runtime Fabric state. rtfctl backup .tar.gz --namespace ### `restore` Restores the local Runtime Fabric state from a backup rtfctl restore .tar.gz --namespace Restore only the core Runtime Fabric software components without triggering application synchronization from the control plane. rtfctl restore .tar.gz --namespace --core-software-only ## Configure Runtime Fabric with RTFCTL Use these commands to configure Runtime Fabric.
CommandDescription

Applies changes to a Runtime Fabric configuration

Updates rtfctl

Waits for Runtime Fabric components to become ready

Renews an expired client certificate using a pre-downloaded package

### `apply` Applies changes to a Runtime Fabric configuration. > [!NOTE] You can use the `rtfctl apply system-configuration` command to update OpenShift > system-configuration values. Other rtfctl apply commands are not effective for OpenShift. For any > other updates, modify the values in the OpenShift console. - Applies an HTTP proxy configuration rtfctl apply http-proxy http://: --namespace - Applies an HTTP proxy configuration with hostnames bypassing the proxy rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - Applies an HTTP proxy configuration with authentication rtfctl apply http-proxy http://:@: --namespace - Clears an HTTP proxy configuration rtfctl apply http-proxy "" --no-proxy "" --namespace - Applies a secure property rtfctl apply secure-property --key --value --app-namespace --namespace - Applies a system configuration on a host node rtfctl apply system-configuration - Applies a system configuration on a host node without downloading the latest scripts rtfctl apply system-configuration --skip-download - Applies a Mule license rtfctl apply mule-license --namespace If Runtime Fabric is installed via Helm, you must update the `mule-license` property in the Helm values. - Applies a monitoring proxy rtfctl apply monitoring-proxy http://: --namespace - Clears a monitoring proxy configuration rtfctl apply monitoring-proxy "" --namespace ### `update` Updates `rtfctl`. - Updates from the US control plane rtfctl update - Updates `rtfctl` from the EU control plane rtfctl update --host eu1.anypoint.mulesoft.com ### `wait` Waits for Runtime Fabric components to become ready - Specifies the number of seconds to wait rtfctl wait --namespace - Specifies the number of seconds to pass before timing out the wait (Default is 600 seconds) rtfctl wait --timeout --namespace ### `renew` Renews an expired client certificate using a pre-downloaded package rtfctl renew-expired-client-cert ## Troubleshoot Runtime Fabric with RTFCTL Use these commands to troubleshoot Runtime Fabric.
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

### `get` Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ### `ping` Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ### `report` Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ### `status` Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ### `test` Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## Manage Mule Apps on Runtime Fabric with RTFCTL Use these commands to manage applications deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays disk usage for an application

Restarts an application

### `delete` Deletes a secure property rtfctl delete secure-property -n ### `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ### `restart` Restarts an application rtfctl restart --app-namespace --namespace ## Uninstall Runtime Fabric with RTFCTL To uninstall Runtime Fabric using `rtfctl` commands, follow these steps: 1. Using Runtime Manager, delete all Mule app and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. In Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl) --- product: Runtime Fabric version: 2.9 --- # RTFCTL Reference > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use this reference for `rtfctl` commands. ## Install, Upgrade, Back up, or Restore Runtime Fabric with RTFCTL Use these commands to install, upgrade, back up or restore a Runtime Fabric.
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

### get Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ### ping Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ### report Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ### status Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ### test Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## Configure Runtime Fabric with RTFCTL Use these commands to configure Runtime Fabric.
CommandDescription

Applies changes to a Runtime Fabric configuration

Updates rtfctl

Waits for Runtime Fabric components to become ready

Renews an expired client certificate using a pre-downloaded package

### apply Applies changes to a Runtime Fabric configuration. > [!NOTE] You can use the `rtfctl apply system-configuration` command to update OpenShift > system-configuration values. Other rtfctl apply commands are not effective for OpenShift. For any > other updates, modify the values in the OpenShift console. - Applies an HTTP proxy configuration rtfctl apply http-proxy http://: --namespace - Applies an HTTP proxy configuration with hostnames bypassing the proxy rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - Applies an HTTP proxy configuration with authentication rtfctl apply http-proxy http://:@: --namespace - Clears an HTTP proxy configuration rtfctl apply http-proxy "" --no-proxy "" --namespace - Applies a secure property rtfctl apply secure-property --key --value --app-namespace --namespace - Applies a system configuration on a host node rtfctl apply system-configuration - Applies a system configuration on a host node without downloading the latest scripts rtfctl apply system-configuration --skip-download - Applies a Mule license rtfctl apply mule-license --namespace If Runtime Fabric is installed via Helm, you must update the `mule-license` property in the Helm values. - Applies a monitoring proxy rtfctl apply monitoring-proxy http://: --namespace - Clears a monitoring proxy configuration rtfctl apply monitoring-proxy "" --namespace ### update Updates `rtfctl`. - Updates from the US control plane rtfctl update - Updates `rtfctl` from the EU control plane rtfctl update --host eu1.anypoint.mulesoft.com ### wait Waits for Runtime Fabric components to become ready - Specifies the number of seconds to wait rtfctl wait --namespace - Specifies the number of seconds to pass before timing out the wait (Default is 600 seconds) rtfctl wait --timeout --namespace ### renew Renews an expired client certificate using a pre-downloaded package rtfctl renew-expired-client-cert ## Troubleshoot Runtime Fabric with RTFCTL Use these commands to troubleshoot Runtime Fabric.
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

### get Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ### ping Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ### report Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ### status Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ### test Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## Manage Mule Apps on Runtime Fabric with RTFCTL Use these commands to manage applications deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays disk usage for an application

Restarts an application

### delete Deletes a secure property rtfctl delete secure-property -n ### disk Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ### restart Restarts an application rtfctl restart --app-namespace --namespace ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # RTFCTL Reference > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use this reference for `rtfctl` commands. ## Install, Upgrade, and Validate Runtime Fabric with RTFCTL Use these commands to install, upgrade, and validate a Runtime Fabric.
CommandDescription

Installs Runtime Fabric

Validates the cluster for Runtime Fabric installation

Displays the Runtime Fabric version information

### `install` - Installs Runtime Fabric rtfctl install - Override the Docker image registry URL and secret rtfctl install --image-pull-registry --image-pull-secret ### `validate` Validates the cluster for a Runtime Fabric installation - Performs a validation check rtfctl validate - Performs a validation check and passes the `fabric.tf` configuration file that contains proxy settings rtfctl validate -f To validate installation with a proxy, you must specify proxy settings in your `settings` file: MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://.com: - Override the Docker image registry URL and secret rtfctl validate --image-pull-registry --image-pull-secret ### `version` Displays the Runtime Fabric version information rtfctl version --namespace ## Back Up and Restore a Runtime Fabric with RTFCTL Use these commands to back up and restore a Runtime Fabric.
CommandDescription

Performs a back up of the local Runtime Fabric state

Restores local Runtime Fabric state from a backup

### `backup` Performs a back up of the local Runtime Fabric state. rtfctl backup .tar.gz --namespace ### `restore` Restores the local Runtime Fabric state from a backup rtfctl restore .tar.gz --namespace Restore only the core Runtime Fabric software components without triggering application synchronization from the control plane. rtfctl restore .tar.gz --namespace --core-software-only ## Configure Runtime Fabric with RTFCTL Use these commands to configure Runtime Fabric.
CommandDescription

Applies changes to a Runtime Fabric configuration

Updates rtfctl

Waits for Runtime Fabric components to become ready

Renews an expired client certificate using a pre-downloaded package

### `apply` Applies changes to a Runtime Fabric configuration. > [!NOTE] You can use the `rtfctl apply system-configuration` command to update OpenShift > system-configuration values. Other rtfctl apply commands are not effective for OpenShift. For any > other updates, modify the values in the OpenShift console. - Applies an HTTP proxy configuration rtfctl apply http-proxy http://: --namespace - Applies an HTTP proxy configuration with hostnames bypassing the proxy rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - Applies an HTTP proxy configuration with authentication rtfctl apply http-proxy http://:@: --namespace - Clears an HTTP proxy configuration rtfctl apply http-proxy "" --no-proxy "" --namespace - Applies a secure property rtfctl apply secure-property --key --value --app-namespace --namespace - Applies a system configuration on a host node rtfctl apply system-configuration - Applies a system configuration on a host node without downloading the latest scripts rtfctl apply system-configuration --skip-download - Applies a Mule license rtfctl apply mule-license --namespace If Runtime Fabric is installed via Helm, you must update the `mule-license` property in the Helm values. - Applies a monitoring proxy rtfctl apply monitoring-proxy http://: --namespace - Clears a monitoring proxy configuration rtfctl apply monitoring-proxy "" --namespace ### `update` Updates `rtfctl`. - Updates `rtfctl` from the US Cloud rtfctl update - Updates `rtfctl` from the EU Cloud rtfctl update --host eu1.anypoint.mulesoft.com - Updates `rtfctl` from the Canada Cloud rtfctl update --host ca1.platform.mulesoft.com - Updates `rtfctl` from the Japan Cloud rtfctl update --host jp1.platform.mulesoft.com - Updates `rtfctl` from the India Cloud rtfctl update --host in1.platform.mulesoft.com - Updates `rtfctl` from the Australia Cloud rtfctl update --host au1.platform.mulesoft.com - Updates `rtfctl` from the United Kingdom Cloud rtfctl update --host gb1.platform.mulesoft.com ### `wait` Waits for Runtime Fabric components to become ready - Specifies the number of seconds to wait rtfctl wait --namespace - Specifies the number of seconds to pass before timing out the wait (Default is 600 seconds) rtfctl wait --timeout --namespace ### `renew` Renews an expired client certificate using a pre-downloaded package rtfctl renew-expired-client-cert ## Troubleshoot Runtime Fabric with RTFCTL Use these commands to troubleshoot Runtime Fabric.
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

### `get` Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ### `ping` Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ### `report` Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ### `status` Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ### `test` Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## Manage Mule Apps on Runtime Fabric with RTFCTL Use these commands to manage applications deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays details for an application

Displays disk usage for an application

Displays the JVM memory usage in a pod

Creates a debugging information package for an application

Restarts an application

Captures a JVM heap dump

Captures a JVM thread dump

### `delete` Deletes a secure property rtfctl delete secure-property -n ### `describe` Displays details for an application in a specific namespace rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ### `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ### `memory` Displays the JVM memory usage in a pod - Gets the JVM memory for each replica rtfctl memory --app-namespace --namespace - Gets the JVM memory for a particular replica rtfctl memory --pod --app-namespace --namespace ### `package` Creates a debugging information package for an application - Creates a package for an application using the first pod by default rtfctl package --app-namespace --namespace - Creates a package for an application containing the apps, policies, and `.mule` directories rtfctl package --apps --policies --dotmule --app-namespace --namespace - Creates a package for an application containing a heap dump rtfctl package --heap-dump --app-namespace --namespace ### `restart` Restarts an application rtfctl restart --app-namespace --namespace ### `heapdump` Triggers a JVM heap dump - Performs a JVM heap dump for an application, saving it as `` `/tmp/dump.hprof ``, using the first replica by default rtfctl heapdump --app-namespace --namespace - Performs a JVM heap dump for an application, saving it as `/tmp/dump.hprof`, using a specific replica rtfctl heapdump --pod --app-namespace --namespace ### `threaddump` Triggers a JVM threaddump - Performs a JVM thread dump for an application using the first replica by default rtfctl threaddump --app-namespace --namespace - Performs a JVM thread dump for an application using a specific replica rtfctl threaddump --pod --app-namespace --namespace ## Manage the Agent Truststore with RTFCTL Use these commands to inspect and update the CA certificates the Runtime Fabric agent uses for mTLS connections to the Anypoint control plane.
CommandDescription

Print a summary of the agent truststore and ca.pem

Download the PKCS#12 truststore from the cluster secret to a local file

Download the ca.pem bundle from the cluster secret to a local file

Add certificates from a PEM file into a local PKCS#12 truststore

Add certificates from one PEM file into another PEM bundle

Upload a local PKCS#12 truststore into the cluster secret

Upload a local PEM bundle into the cluster secret as ca.pem

Merge a PEM into the cluster truststore and ca.pem in one step

### `agent-truststore info` Prints a summary of the agent keystore secret, including all certificates loaded in the PKCS#12 truststore and ca.pem, along with their subjects, expiry dates, and days remaining. - Print a human-readable summary rtfctl agent-truststore info --namespace rtf - Print machine-readable JSON output rtfctl agent-truststore info -o json --namespace rtf ### `agent-truststore retrieve-agent-truststore` Downloads the `agent-truststore.p12` file from the cluster secret to a local file. The password is read automatically from the `truststore-password` key in the secret. rtfctl agent-truststore retrieve-agent-truststore -o agent-truststore-bk.p12 --namespace rtf - Override the secret name and the output file rtfctl agent-truststore retrieve-agent-truststore --secret agent-keystore -o agent-truststore-bk.p12 --namespace rtf ### `agent-truststore retrieve-ca-pem` Downloads the `ca.pem` bundle from the cluster secret to a local file. rtfctl agent-truststore retrieve-ca-pem -o ca-bk.pem --namespace rtf ### `agent-truststore merge-pem-into-p12` Adds the certificates from a PEM file into a local PKCS#12 truststore file (certificates-only format). Duplicate certificates are detected by subject and skipped. rtfctl agent-truststore merge-pem-into-p12 -i agent-truststore-bk.p12 -c new-ca.pem -o agent-truststore-new.p12 ### `agent-truststore merge-pem-into-pem` Merges certificates from one PEM file into another PEM bundle. Duplicate certificates are detected by subject and skipped. rtfctl agent-truststore merge-pem-into-pem -i ca-bk.pem -c new-ca.pem -o ca-new.pem ### `agent-truststore update-truststore-in-secret` Uploads a local PKCS#12 file into the agent keystore secret, replacing the `agent-truststore.p12` key. rtfctl agent-truststore update-truststore-in-secret -i agent-truststore-new.p12 --namespace rtf ### `agent-truststore update-ca-pem-in-secret` Uploads a local PEM bundle into the agent keystore secret, replacing the `ca.pem` key. rtfctl agent-truststore update-ca-pem-in-secret -i ca-new.pem --namespace rtf ### `agent-truststore refresh-secret-with-pem` Reads the current truststore and `ca.pem` from the cluster secret, merges the provided PEM into both, displays the certificate subjects to upload, and—after confirmation—patches the secret. Use `--yes` to skip the interactive prompts. - Interactive (asks for confirmation before each upload) rtfctl agent-truststore refresh-secret-with-pem -c new-ca.pem --namespace rtf - Non-interactive (suitable for automation) rtfctl agent-truststore refresh-secret-with-pem -c new-ca.pem --yes --namespace rtf ## Uninstall Runtime Fabric with RTFCTL To uninstall Runtime Fabric using `rtfctl` commands, follow these steps: 1. Using Runtime Manager, delete all Mule app and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. In Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl) --- product: Runtime Fabric version: 2.10 --- # Runtime Fabric Core Software Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following table lists the Kubernetes access permissions required by the Runtime Fabric agent. These access permissions are part of the Runtime Fabric helm chart and are automatically applied during the installation or upgrade. > [!NOTE] You can’t extend or modify any of these core software access permissions. Instead, create > and apply the `ClusterRole` and `Rolebindings` for the Runtime Fabric Authorized namespaces use > case. Refer to [Configuring Authorized Namespaces in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/authorized-namespaces).
NamespaceAPI GroupsKubernetes ResourcesVerbs

<rtf-namespace>

extensions, apps

deployments, deployments/scale, daemonsets, replicasets

*

“”

pods, pods/log, pods/portforward, pods/exec, configmaps, secrets, services, namespaces, nodes, serviceaccounts, resourcequotas, events, limitranges

*

batch

jobs, cronjobs

*

extensions

jobs

*

networking.k8s.io

networkpolicies

*

rbac.authorization.k8s.io

rolebindings, clusterroles, clusterrolebindings, roles

*

extensions,networking.k8s.io

ingresses,networkpolicies

*

rtf.mulesoft.com

persistencegateways, kubernetestemplates

*

autoscaling

horizontalpodautoscalers

*

## See Also - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.10/rtfctl-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.11 --- # Runtime Fabric Core Software Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following table lists the Kubernetes access permissions required by the Runtime Fabric agent. These access permissions are part of the Runtime Fabric helm chart and are automatically applied during the installation or upgrade. > [!NOTE] You can’t extend or modify any of these core software access permissions. Instead, create > and apply the `ClusterRole` and `Rolebindings` for the Runtime Fabric Authorized namespaces use > case. Refer to [Configuring Authorized Namespaces in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/authorized-namespaces).
NamespaceAPI GroupsKubernetes ResourcesVerbs

<rtf-namespace>

extensions, apps

deployments, deployments/scale, daemonsets, replicasets

*

“”

pods, pods/log, pods/portforward, pods/exec, configmaps, secrets, services, namespaces, nodes, serviceaccounts, resourcequotas, events, limitranges

*

batch

jobs, cronjobs

*

extensions

jobs

*

networking.k8s.io

networkpolicies

*

rbac.authorization.k8s.io

rolebindings, clusterroles, clusterrolebindings, roles

*

extensions,networking.k8s.io

ingresses,networkpolicies

*

rtf.mulesoft.com

persistencegateways, kubernetestemplates

*

autoscaling

horizontalpodautoscalers

*

high availability

leases

*

## See Also - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.11/rtfctl-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.6 --- # Runtime Fabric Core Software Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following table lists the Kubernetes access permissions required by the Runtime Fabric agent. These access permissions are part of the Runtime Fabric helm chart and are automatically applied during the installation or upgrade. > [!NOTE] You can’t extend or modify any of these core software access permissions. Instead, create > and apply the `ClusterRole` and `Rolebindings` for the Runtime Fabric Authorized namespaces use > case. Refer to [Configuring Authorized Namespaces in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/authorized-namespaces).
NamespaceAPI GroupsKubernetes ResourcesVerbs

<rtf-namespace>

extensions, apps

deployments, deployments/scale, daemonsets, replicasets

*

“”

pods, pods/log, pods/portforward, pods/exec, configmaps, secrets, services, namespaces, nodes, serviceaccounts, resourcequotas, events, limitranges

*

batch

jobs, cronjobs

*

extensions

jobs

*

networking.k8s.io

networkpolicies

*

rbac.authorization.k8s.io

rolebindings, clusterroles, clusterrolebindings, roles

*

extensions,networking.k8s.io

ingresses,networkpolicies

*

rtf.mulesoft.com

persistencegateways, kubernetestemplates

*

autoscaling

horizontalpodautoscalers

*

## See Also - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.6/rtfctl-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.7 --- # Runtime Fabric Core Software Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following table lists the Kubernetes access permissions required by the Runtime Fabric agent. These access permissions are part of the Runtime Fabric helm chart and are automatically applied during the installation or upgrade. > [!NOTE] You can’t extend or modify any of these core software access permissions. Instead, create > and apply the `ClusterRole` and `Rolebindings` for the Runtime Fabric Authorized namespaces use > case. Refer to [Configuring Authorized Namespaces in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/authorized-namespaces).
NamespaceAPI GroupsKubernetes ResourcesVerbs

<rtf-namespace>

extensions, apps

deployments, deployments/scale, daemonsets, replicasets

*

“”

pods, pods/log, pods/portforward, pods/exec, configmaps, secrets, services, namespaces, nodes, serviceaccounts, resourcequotas, events, limitranges

*

batch

jobs, cronjobs

*

extensions

jobs

*

networking.k8s.io

networkpolicies

*

rbac.authorization.k8s.io

rolebindings, clusterroles, clusterrolebindings, roles

*

extensions,networking.k8s.io

ingresses,networkpolicies

*

rtf.mulesoft.com

persistencegateways, kubernetestemplates

*

autoscaling

horizontalpodautoscalers

*

## See Also - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.7/rtfctl-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.8 --- # Runtime Fabric Core Software Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following table lists the Kubernetes access permissions required by the Runtime Fabric agent. These access permissions are part of the Runtime Fabric helm chart and are automatically applied during the installation or upgrade. > [!NOTE] You can’t extend or modify any of these core software access permissions. Instead, create > and apply the `ClusterRole` and `Rolebindings` for the Runtime Fabric Authorized namespaces use > case. Refer to [Configuring Authorized Namespaces in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/authorized-namespaces).
NamespaceAPI GroupsKubernetes ResourcesVerbs

<rtf-namespace>

extensions, apps

deployments, deployments/scale, daemonsets, replicasets

*

“”

pods, pods/log, pods/portforward, pods/exec, configmaps, secrets, services, namespaces, nodes, serviceaccounts, resourcequotas, events, limitranges

*

batch

jobs, cronjobs

*

extensions

jobs

*

networking.k8s.io

networkpolicies

*

rbac.authorization.k8s.io

rolebindings, clusterroles, clusterrolebindings, roles

*

extensions,networking.k8s.io

ingresses,networkpolicies

*

rtf.mulesoft.com

persistencegateways, kubernetestemplates

*

autoscaling

horizontalpodautoscalers

*

## See Also - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.8/rtfctl-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.9 --- # Runtime Fabric Core Software Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following table lists the Kubernetes access permissions required by the Runtime Fabric agent. These access permissions are part of the Runtime Fabric helm chart and are automatically applied during the installation or upgrade. > [!NOTE] You can’t extend or modify any of these core software access permissions. Instead, create > and apply the `ClusterRole` and `Rolebindings` for the Runtime Fabric Authorized namespaces use > case. Refer to [Configuring Authorized Namespaces in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/authorized-namespaces).
NamespaceAPI GroupsKubernetes ResourcesVerbs

<rtf-namespace>

extensions, apps

deployments, deployments/scale, daemonsets, replicasets

*

“”

pods, pods/log, pods/portforward, pods/exec, configmaps, secrets, services, namespaces, nodes, serviceaccounts, resourcequotas, events, limitranges

*

batch

jobs, cronjobs

*

extensions

jobs

*

networking.k8s.io

networkpolicies

*

rbac.authorization.k8s.io

rolebindings, clusterroles, clusterrolebindings, roles

*

extensions,networking.k8s.io

ingresses,networkpolicies

*

rtf.mulesoft.com

persistencegateways, kubernetestemplates

*

autoscaling

horizontalpodautoscalers

*

## See Also - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.9/rtfctl-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/rtf-mule-app-permissions) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Runtime Fabric Core Software Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following table lists the Kubernetes access permissions required by the Runtime Fabric agent. These access permissions are part of the Runtime Fabric helm chart and are automatically applied during the installation or upgrade. > [!NOTE] You can’t extend or modify any of these core software access permissions. Instead, create > and apply the `ClusterRole` and `Rolebindings` for the Runtime Fabric Authorized namespaces use > case. Refer to [Configuring Authorized Namespaces in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces).
NamespaceAPI GroupsKubernetes ResourcesVerbs

<rtf-namespace>

extensions, apps

deployments, deployments/scale, daemonsets, replicasets

*

“”

pods, pods/log, pods/portforward, pods/exec, configmaps, secrets, services, namespaces, nodes, serviceaccounts, resourcequotas, events, limitranges

*

batch

jobs, cronjobs

*

extensions

jobs

*

networking.k8s.io

networkpolicies

*

rbac.authorization.k8s.io

rolebindings, clusterroles, clusterrolebindings, roles

*

extensions,networking.k8s.io

ingresses,networkpolicies

*

rtf.mulesoft.com

persistencegateways, kubernetestemplates, httproutetemplates, muleapplications, muleapplications/status

*

autoscaling

horizontalpodautoscalers

*

high availability

leases

*

## See Also - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/latest/rtfctl-permissions) - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/rtf-mule-app-permissions) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Runtime Fabric High Availability and Disaster Recovery > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric runs Mule applications on a Kubernetes-based runtime plane that you operate on your own infrastructure or cloud. To keep workloads running through failures and to recover from larger disruptions, Runtime Fabric supports both high availability (HA) and disaster recovery (DR). High availability applies at two levels: - Runtime Fabric core software Runtime Fabric provides HA for its own software so that the runtime plane stays operational through node and zone failures, letting you continue deploying and managing applications. - Mule applications You configure HA for your applications separately by running multiple replicas across availability zones. You achieve disaster recovery (DR) by backing up the cluster and restoring it after a larger disruption. MuleSoft doesn’t back up your data or your cluster configuration; you own cluster backup, restore, and DR. For an overview of HA and DR across all Mule deployment models, see [High Availability and Disaster Recovery](https://docs.mulesoft.com/hosting-home/hadr-guide). ## High Availability Versus Disaster Recovery HA and DR both increase availability, but they address different kinds of failure and differ in scope: - High availability HA keeps a system accessible when an individual component fails. On Runtime Fabric, it handles routine, localized failures—such as a node or zone going down—with no loss of service. - Disaster recovery DR restores a system to an acceptable previous state after a broader disaster, such as flooding, power failures, server failures, or misconfigurations. It handles large-scale disruptions and usually incurs a brief loss of service while the DR plan runs. Two measurable objectives drive your DR plan: - Recovery Time Objective (RTO) The maximum downtime a business tolerates. RTO is the time the system takes to recover after a disruption. - Recovery Point Objective (RPO) The maximum data loss a business accepts after a disaster. RPO drives how often you back up data. ## High Availability in Runtime Fabric Runtime Fabric provides high availability for its own core software so that the runtime plane remains operational through node and zone failures. You achieve high availability for your Mule applications separately by spreading replicas across availability zones and externalizing state. - Multiple replicas Deploy each application with a minimum of two replicas. See [Deploying Mule Apps to Runtime Fabric Using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric). - Availability zones Runtime Fabric uses topology spread constraints to distribute Mule application replicas evenly across availability zones. CPU-based Horizontal Pod Autoscaling (HPA) adjusts the number of application replicas in response to load, but it doesn’t control where Kubernetes schedules them; the topology spread constraints keep the added replicas balanced across zones. HPA applies to Mule applications, not to the Runtime Fabric core software. See [Configuring Horizontal Pod Autoscaling (HPA) for Runtime Fabric Deployments](https://docs.mulesoft.com/runtime-fabric/latest/configure-horizontal-autoscaling). - Failover When a node or zone fails, Kubernetes reschedules replicas onto healthy nodes to maintain availability. - Externalized state Persist data in object storage across application replicas and restarts, so that no state is lost when a replica reschedules. ## Disaster Recovery in Runtime Fabric Runtime Fabric backs up and restores cluster services and the state that deployed applications and their configurations require. Because you operate the cluster, you own disaster recovery. - Backups Schedule regular backups with `rtfctl`, and store them on external storage outside the cluster. MuleSoft recommends hourly backups. The backup covers cluster configuration—services, secrets, ingress, and ConfigMaps—but it doesn’t cover application state, Ops Center data, or control-plane data. Application deployments aren’t part of the backup; Runtime Fabric reconciles them from the Anypoint Platform control plane on restore. See [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/manage-backup-restore). - Restore targets Restore to an existing Runtime Fabric cluster, or to a new Kubernetes cluster that uses the same configuration as the backed-up cluster. - Common scenarios Use backup and restore for major infrastructure upgrades, cluster migrations (from on-premises to cloud, or between cloud providers), and failover to a standby cluster. - Anypoint configuration Back up your own Anypoint configurations—such as VPN routes, private space firewall rules, connections, and queues—with the Anypoint CLI or Anypoint Platform APIs. MuleSoft manages the Anypoint Platform control plane. You operate the Runtime Fabric cluster, its backups, and its DR. ## Considerations and Limitations Account for these factors when you plan backup and restore for Runtime Fabric: - Concurrent instances Don’t run two concurrent instances of the same Runtime Fabric through backup and restore. Running the original and a restored copy at the same time causes deployment conflicts. - Changes after backup Application deployment changes are persisted in the Anypoint Platform control plane, not in the backup. When you restore the fabric, it synchronizes deployments from the control plane, so created and deleted applications are reconciled automatically. Changes that aren’t stored in the control plane—such as updated cluster configurations and agent upgrades—aren’t restored; reapply those manually. - Cluster and tooling consistency Restore to the same cluster that the control plane lists, and use the same `rtfctl` version that you used to create the backup. ## Best Practices - Keep your integrations stateless, and externalize state to an external store. - Run at least two replicas of each application, spread across availability zones. - Schedule regular backups, and store them on external storage. - Test your restore procedures regularly. ## See Also - [High Availability and Disaster Recovery Across Deployment Models](https://docs.mulesoft.com/hosting-home/hadr-guide) - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/manage-backup-restore) - [Configuring Horizontal Pod Autoscaling (HPA) for Runtime Fabric Deployments](https://docs.mulesoft.com/runtime-fabric/latest/configure-horizontal-autoscaling) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.10 --- # Runtime Fabric Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enable Runtime Fabric Kubernetes permissions, review the following topics. - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.10/rtf-permissions) Review the Kubernetes resource access permissions required by the Runtime Fabric agent. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.10/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/rtf-mule-app-permissions) Review Mule app deployment Kubernetes permissions configuration. ## See Also - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.11 --- # Runtime Fabric Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enable Runtime Fabric Kubernetes permissions, review these topics. - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.11/rtf-permissions) Review the Kubernetes resource access permissions required by the Runtime Fabric agent. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.11/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/rtf-mule-app-permissions) Review Mule app deployment Kubernetes permissions configuration. ## See Also - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.6 --- # Runtime Fabric Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enable Runtime Fabric Kubernetes permissions, review the following topics. - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.6/rtf-permissions) Review the Kubernetes resource access permissions required by the Runtime Fabric agent. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.6/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/rtf-mule-app-permissions) Review Mule app deployment Kubernetes permissions configuration. ## See Also - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.7 --- # Runtime Fabric Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enable Runtime Fabric Kubernetes permissions, review the following topics. - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.7/rtf-permissions) Review the Kubernetes resource access permissions required by the Runtime Fabric agent. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.7/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/rtf-mule-app-permissions) Review Mule app deployment Kubernetes permissions configuration. ## See Also - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.8 --- # Runtime Fabric Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enable Runtime Fabric Kubernetes permissions, review the following topics. - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.8/rtf-permissions) Review the Kubernetes resource access permissions required by the Runtime Fabric agent. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.8/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/rtf-mule-app-permissions) Review Mule app deployment Kubernetes permissions configuration. ## See Also - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.9 --- # Runtime Fabric Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enable Runtime Fabric Kubernetes permissions, review the following topics. - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.9/rtf-permissions) Review the Kubernetes resource access permissions required by the Runtime Fabric agent. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.9/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/rtf-mule-app-permissions) Review Mule app deployment Kubernetes permissions configuration. ## See Also - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/rtf-mule-app-permissions) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Runtime Fabric Kubernetes Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To enable Runtime Fabric Kubernetes permissions, review the following topics. - [Runtime Fabric Core Software Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/latest/rtf-permissions) Review the Kubernetes resource access permissions required by the Runtime Fabric agent. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/latest/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Mule App Deployments Kubernetes Permissions on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/rtf-mule-app-permissions) Review Mule app deployment Kubernetes permissions configuration. ## See Also - [Configuring Kubernetes for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/rtf-mule-app-permissions) --- product: Runtime Fabric version: 2.10 --- # Runtime Fabric Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - Runtime Fabric - [Runtime Fabric 3.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-3.x.x) - [Runtime Fabric 2.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) - [Runtime Fabric 1.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes) - Runtime Fabric Appliance - [Runtime Fabric Installer Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-installer-release-notes) - [Runtime Fabric Install Scripts Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-install-scripts-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes-appliance) - Mule Runtime Engine Patch Updates - [Mule Runtime Patch Updates Release Notes for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) - Runtime Fabric Mule Action Image - [Runtime Fabric Mule Action Image](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-rtf-mule-action) For versions of Runtime Fabric that have reached [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf), see the [Anypoint Runtime Fabric Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: Runtime Fabric version: 2.11 --- # Runtime Fabric Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - Runtime Fabric - [Runtime Fabric 3.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-3.x.x) - [Runtime Fabric 2.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) - [Runtime Fabric 1.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes) - Runtime Fabric Appliance - [Runtime Fabric Installer Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-installer-release-notes) - [Runtime Fabric Install Scripts Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-install-scripts-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes-appliance) - Mule Runtime Engine Patch Updates - [Mule Runtime Patch Updates Release Notes for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) - Runtime Fabric Mule Action Image - [Runtime Fabric Mule Action Image](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-rtf-mule-action) For versions of Runtime Fabric that have reached [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf), see the [Anypoint Runtime Fabric Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: Runtime Fabric version: 2.5 --- # Runtime Fabric Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - Runtime Fabric - [Runtime Fabric 3.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-3.x.x) - [Runtime Fabric 2.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) - [Runtime Fabric 1.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes) - Runtime Fabric Appliance - [Runtime Fabric Installer Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-installer-release-notes) - [Runtime Fabric Install Scripts Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-install-scripts-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes-appliance) - Mule Runtime Engine Patch Updates - [Mule Runtime Patch Updates Release Notes for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) - Runtime Fabric Mule Action Image - [Runtime Fabric Mule Action Image](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-rtf-mule-action) For versions of Runtime Fabric that have reached [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf), see the [Anypoint Runtime Fabric Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: Runtime Fabric version: 2.6 --- # Runtime Fabric Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - Runtime Fabric - [Runtime Fabric 3.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-3.x.x) - [Runtime Fabric 2.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) - [Runtime Fabric 1.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes) - Runtime Fabric Appliance - [Runtime Fabric Installer Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-installer-release-notes) - [Runtime Fabric Install Scripts Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-install-scripts-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes-appliance) - Mule Runtime Engine Patch Updates - [Mule Runtime Patch Updates Release Notes for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) - Runtime Fabric Mule Action Image - [Runtime Fabric Mule Action Image](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-rtf-mule-action) For versions of Runtime Fabric that have reached [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf), see the [Anypoint Runtime Fabric Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: Runtime Fabric version: 2.7 --- # Runtime Fabric Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - Runtime Fabric - [Runtime Fabric 3.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-3.x.x) - [Runtime Fabric 2.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) - [Runtime Fabric 1.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes) - Runtime Fabric Appliance - [Runtime Fabric Installer Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-installer-release-notes) - [Runtime Fabric Install Scripts Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-install-scripts-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes-appliance) - Mule Runtime Engine Patch Updates - [Mule Runtime Patch Updates Release Notes for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) - Runtime Fabric Mule Action Image - [Runtime Fabric Mule Action Image](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-rtf-mule-action) For versions of Runtime Fabric that have reached [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf), see the [Anypoint Runtime Fabric Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: Runtime Fabric version: 2.8 --- # Runtime Fabric Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - Runtime Fabric - [Runtime Fabric 3.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-3.x.x) - [Runtime Fabric 2.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) - [Runtime Fabric 1.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes) - Runtime Fabric Appliance - [Runtime Fabric Installer Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-installer-release-notes) - [Runtime Fabric Install Scripts Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-install-scripts-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes-appliance) - Mule Runtime Engine Patch Updates - [Mule Runtime Patch Updates Release Notes for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) - Runtime Fabric Mule Action Image - [Runtime Fabric Mule Action Image](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-rtf-mule-action) For versions of Runtime Fabric that have reached [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf), see the [Anypoint Runtime Fabric Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: Runtime Fabric version: 2.9 --- # Runtime Fabric Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - Runtime Fabric - [Runtime Fabric 3.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-3.x.x) - [Runtime Fabric 2.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) - [Runtime Fabric 1.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes) - Runtime Fabric Appliance - [Runtime Fabric Installer Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-installer-release-notes) - [Runtime Fabric Install Scripts Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-install-scripts-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes-appliance) - Mule Runtime Engine Patch Updates - [Mule Runtime Patch Updates Release Notes for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) - Runtime Fabric Mule Action Image - [Runtime Fabric Mule Action Image](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-rtf-mule-action) For versions of Runtime Fabric that have reached [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf), see the [Anypoint Runtime Fabric Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Runtime Fabric Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - Runtime Fabric - [Runtime Fabric 3.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-3.x.x) - [Runtime Fabric 2.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) - [Runtime Fabric 1.x.x Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes) - Runtime Fabric Appliance - [Runtime Fabric Installer Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-installer-release-notes) - [Runtime Fabric Install Scripts Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-install-scripts-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes-appliance) - Mule Runtime Engine Patch Updates - [Mule Runtime Patch Updates Release Notes for Runtime Fabric](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) - Runtime Fabric Mule Action Image - [Runtime Fabric Mule Action Image](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-rtf-mule-action) For versions of Runtime Fabric that have reached [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf), see the [Anypoint Runtime Fabric Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: Runtime Fabric version: 2.10 --- # Scalability Benchmarks > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric is a core Kubernetes (K8s) software and works alike in all K8s environments which comply with Runtime Fabric hardware and software requirements. ## Scale Limits The following scale limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster.
LimitationDescriptionEnforced by Runtime Fabric

Deployments per Runtime Fabric

The maximum number of deployments being managed by Runtime Fabric at any instance should not exceed 8000 for optimal performance.

Recommended

Horizontal Pod Autoscaling (HPA)

With Runtime Fabric on Amazon EKS, occasional traffic failures of approximately 0.09% may occur when scaling replicas from 1 to 8. These errors are specific to the pod scaling window, so you may experience traffic failure during scaling operations.

Runtime Fabric functionality and management of application deployments is not affected by the following: - Size of individual applications - Size of worker nodes - Number of pods running per work node Because Runtime Fabric is K8s based and uses cloud-native orchestration principals, it works according to the specified configuration of deployments. ## Benchmarked Metrics Review the following benchmarked metrics to understand various management metrics when compared between a nearly empty cluster and a cluster running 8000 deployments. The cluster configuration used is Runtime Fabric on AWS EKS cluster:
ConfigurationDescription

VPC and node groups

Default configuration done from eksctl. 3 subnets (one subnet per node group), NAT Gateway.

AWS NLB

Equipped via helm chart at nginx creation.

Node Auto Scaler

Recommended 3 GB (Memory)/200m vCore (req==limit)

Workers

m5.4x large, worker node group

Monitoring

Fixed, 1 Node, Prometheus, monitoring node group, m5.2x large

Ingress

Fixed, 2 Nodes, Nginx, ingress node group, m5.4xlarge

## Runtime Fabric Restart Latency The following graphic shows how long the Runtime Fabric agent takes to restart if invoked by the customers or cluster upgrade: ![Diagram that shows restart latency between near empty cluster and loaded cluster](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric takes approximately 190 seconds to create the apps irrespective of deployment volume. The following table shows how long it takes for a Mule app to start, stop, or delete:
App OperationsNear Empty ClusterLoaded

Start Latency

~110 seconds

158 seconds

Stop Latency

~10 seconds

20 seconds

Delete Latency

~9 seconds

~28 seconds

The following table shows how long a node cordon operation takes to restart if there is a bad node:
Node OperationEmpty ClusterLoaded Cluster

Cordon

~2 seconds

~2 seconds

Drain process

~4 seconds

~35 seconds

## Considerations Review the following scale considerations: - Runtime Fabric agent requires more than default memory and CPU to manage clusters with large-scale deployments, you can modify such values using the information in the following table. For a cluster with 8000 deployments, use at least:
Cluster RecommendationsDefault200 Node/8000 App Resource Settings

Agent Resources

Memory 200Mi request, 500Mi limit. CPU 100m request, 1vCore limit.

1000Mi (Memory)/1vCore (request == limit)

Daemon Resources

Memory 200Mi request, 300Mi limit. CPU 150m request, 200m limit.

1200Mi (Memory)/500m (request == limit)

- The default resource allocation supports up to 2K apps / 75 nodes. - The performance of large-scale deployment orchestration through Runtime Fabric is inversely proportional to the volume of deployments. - RTFCTL clusters are supported only for certain benchmarks. - Using Helm enables you to manage any cluster that requires customized resources for Runtime Fabric agent due to the size of the cluster. - When scaling up Runtime Fabric agent resource limit, consider increasing the request accordingly. - Try not to run a container unbounded by removing the limit completely. For OpenShift operators, removing the limit sets the agent to the default limit setting. - `resource-cache` and `mule-clusterip-service` services can be scaled horizontally because they are stateless. --- product: Runtime Fabric version: 2.11 --- # Scalability Benchmarks > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric is a core Kubernetes (K8s) software and works alike in all K8s environments which comply with Runtime Fabric hardware and software requirements. ## Scale Limits The following scale limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster.
LimitationDescriptionEnforced by Runtime Fabric

Deployments per Runtime Fabric

The maximum number of deployments being managed by Runtime Fabric at any instance should not exceed 8000 for optimal performance.

Recommended

Horizontal Pod Autoscaling (HPA)

With Runtime Fabric on Amazon EKS, occasional traffic failures of approximately 0.09% may occur when scaling replicas from 1 to 8. These errors are specific to the pod scaling window, so you may experience traffic failure during scaling operations.

Runtime Fabric functionality and management of application deployments is not affected by this: - Size of individual applications - Size of worker nodes - Number of pods running per work node Because Runtime Fabric is K8s based and uses cloud-native orchestration principals, it works according to the specified configuration of deployments. ## Benchmarked Metrics Review these benchmarked metrics to understand various management metrics when compared between a nearly empty cluster and a cluster running 8000 deployments. The cluster configuration used is Runtime Fabric on AWS EKS cluster:
ConfigurationDescription

VPC and node groups

Default configuration done from eksctl. 3 subnets (one subnet per node group), NAT Gateway.

AWS NLB

Equipped via helm chart at nginx creation.

Node Auto Scaler

Recommended 3 GB (Memory)/200m vCore (req==limit)

Workers

m5.4x large, worker node group

Monitoring

Fixed, 1 Node, Prometheus, monitoring node group, m5.2x large

Ingress

Fixed, 2 Nodes, Nginx, ingress node group, m5.4xlarge

## Runtime Fabric Restart Latency The following graphic shows how long the Runtime Fabric agent takes to restart if invoked by the customers or cluster upgrade: ![Diagram that shows restart latency between near empty cluster and loaded cluster](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric takes approximately 190 seconds to create the apps irrespective of deployment volume. The following table shows how long it takes for a Mule app to start, stop, or delete:
App OperationsNear Empty ClusterLoaded

Start Latency

~110 seconds

158 seconds

Stop Latency

~10 seconds

20 seconds

Delete Latency

~9 seconds

~28 seconds

The following table shows how long a node cordon operation takes to restart if there is a bad node:
Node OperationEmpty ClusterLoaded Cluster

Cordon

~2 seconds

~2 seconds

Drain process

~4 seconds

~35 seconds

## Considerations Review these scale considerations: - Runtime Fabric agent requires more than default memory and CPU to manage clusters with large-scale deployments, you can modify such values using the information in this table. For a cluster with 8000 deployments, use at least:
Cluster RecommendationsDefault200 Node/8000 App Resource Settings

Agent Resources

Memory 200Mi request, 500Mi limit. CPU 100m request, 1vCore limit.

1000Mi (Memory)/1vCore (request == limit)

Daemon Resources

Memory 200Mi request, 300Mi limit. CPU 150m request, 200m limit.

1200Mi (Memory)/500m (request == limit)

- The default resource allocation supports up to 2K apps / 75 nodes. - The performance of large-scale deployment orchestration through Runtime Fabric is inversely proportional to the volume of deployments. - RTFCTL clusters are supported only for certain benchmarks. - Using Helm enables you to manage any cluster that requires customized resources for Runtime Fabric agent due to the size of the cluster. - When scaling up Runtime Fabric agent resource limit, consider increasing the request accordingly. - Try not to run a container unbounded by removing the limit completely. For OpenShift operators, removing the limit sets the agent to the default limit setting. - `resource-cache` and `mule-clusterip-service` services can be scaled horizontally because they are stateless. --- product: Runtime Fabric version: 2.5 --- # Scalability Benchmarks > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric is a core Kubernetes (K8s) software and works alike in all K8s environments which comply with Runtime Fabric hardware and software requirements. The following scale limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster.
LimitationDescriptionEnforced by Runtime Fabric

Node count

The maximum number of nodes is 400.

Recommended

Deployments per Runtime Fabric

The maximum number of deployments being managed by Runtime Fabric at any instance should not exceed 8000 for optimal performance.

Recommended

Runtime Fabric functionality and management of application deployments is not affected by the following: - Size of individual applications - Size of worker nodes - Number of pods running per work node Because Runtime Fabric is K8s based and uses cloud-native orchestration principals, it works according to the specified configuration of deployments. Review the following benchmarked metrics to understand various management metrics when compared between a nearly empty cluster and a cluster running 8000 deployments. The cluster configuration used is Runtime Fabric on AWS EKS cluster:
ConfigurationDescription

VPC and node groups

Default configuration done from eksctl. 3 subnets (one subnet per node group), NAT Gateway.

AWS NLB

Equipped via helm chart at nginx creation.

Node Auto Scaler

Recommended 3 GB (Memory)/200m vCore (req==limit)

Workers

m5.4x large, worker node group

Monitoring

Fixed, 1 Node, Prometheus, monitoring node group, m5.2x large

Ingress

Fixed, 2 Nodes, Nginx, ingress node group, m5.4xlarge

The following graphic shows how long the Runtime Fabric agent takes to restart if invoked by the customers or cluster upgrade: ![Diagram that shows restart latency between near empty cluster and loaded cluster](/mulesoft/current/en-us/runtime-fabric/2.5/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric takes approximately 190 seconds to create the apps irrespective of deployment volume. The following table shows how long it takes for a Mule app to start, stop, or delete:
App OperationsNear Empty ClusterLoaded

Start Latency

~110 seconds

158 seconds

Stop Latency

~10 seconds

20 seconds

Delete Latency

~9 seconds

~28 seconds

The following table shows how long a node cordon operation takes to restart if there is a bad node:
Node OperationEmpty ClusterLoaded Cluster

Cordon

~2 seconds

~2 seconds

Drain process

~4 seconds

~35 seconds

Aspects to consider: - Runtime Fabric agent requires more than default memory and CPU to manage clusters with large-scale deployments, you can modify such values using the information in the following table. For a cluster with 8000 deployments, use at least:
Cluster RecommendationsDefault200 Node/8000 App Resource Settings

Agent Resources

Memory 200 mb request, 500 mb limit. CPU 100m request, 1vCore limit.

3 GB (Memory)/2vCore (request == limit)

- Note that in Helm you need to disable node watcher `nodeWatcherEnabled` explicitly when you operate at a large scale. Node watcher is always enabled by default (`nodeWatcherEnabled: true`). - The performance of large-scale deployment orchestration through Runtime Fabric is inversely proportional to the volume of deployments. - RTFCTL clusters are supported only for certain benchmarks. - Using Helm enables you to manage any cluster that requires customized resources for Runtime Fabric agent due to the size of the cluster. --- product: Runtime Fabric version: 2.6 --- # Scalability Benchmarks > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric is a core Kubernetes (K8s) software and works alike in all K8s environments which comply with Runtime Fabric hardware and software requirements. The following scale limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster.
LimitationDescriptionEnforced by Runtime Fabric

Deployments per Runtime Fabric

The maximum number of deployments being managed by Runtime Fabric at any instance should not exceed 8000 for optimal performance.

Recommended

Horizontal Pod Autoscaling (HPA)

With Runtime Fabric on Amazon EKS, occasional traffic failures of approximately 0.09% may occur when scaling replicas from 1 to 8. These errors are specific to the pod scaling window, so you may experience traffic failure during scaling operations.

Runtime Fabric functionality and management of application deployments is not affected by the following: - Size of individual applications - Size of worker nodes - Number of pods running per work node Because Runtime Fabric is K8s based and uses cloud-native orchestration principals, it works according to the specified configuration of deployments. Review the following benchmarked metrics to understand various management metrics when compared between a nearly empty cluster and a cluster running 8000 deployments. The cluster configuration used is Runtime Fabric on AWS EKS cluster:
ConfigurationDescription

VPC and node groups

Default configuration done from eksctl. 3 subnets (one subnet per node group), NAT Gateway.

AWS NLB

Equipped via helm chart at nginx creation.

Node Auto Scaler

Recommended 3 GB (Memory)/200m vCore (req==limit)

Workers

m5.4x large, worker node group

Monitoring

Fixed, 1 Node, Prometheus, monitoring node group, m5.2x large

Ingress

Fixed, 2 Nodes, Nginx, ingress node group, m5.4xlarge

The following graphic shows how long the Runtime Fabric agent takes to restart if invoked by the customers or cluster upgrade: ![Diagram that shows restart latency between near empty cluster and loaded cluster](/mulesoft/current/en-us/runtime-fabric/2.6/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric takes approximately 190 seconds to create the apps irrespective of deployment volume. The following table shows how long it takes for a Mule app to start, stop, or delete:
App OperationsNear Empty ClusterLoaded

Start Latency

~110 seconds

158 seconds

Stop Latency

~10 seconds

20 seconds

Delete Latency

~9 seconds

~28 seconds

The following table shows how long a node cordon operation takes to restart if there is a bad node:
Node OperationEmpty ClusterLoaded Cluster

Cordon

~2 seconds

~2 seconds

Drain process

~4 seconds

~35 seconds

Aspects to consider: - Runtime Fabric agent requires more than default memory and CPU to manage clusters with large-scale deployments, you can modify such values using the information in the following table. For a cluster with 8000 deployments, use at least:
Cluster RecommendationsDefault200 Node/8000 App Resource Settings

Agent Resources

Memory 200 mb request, 500 mb limit. CPU 100m request, 1vCore limit.

3 GB (Memory)/2vCore (request == limit)

- Note that in Helm you need to disable node watcher `nodeWatcherEnabled` explicitly when you operate at a large scale. Node watcher is always enabled by default (`nodeWatcherEnabled: true`). - The performance of large-scale deployment orchestration through Runtime Fabric is inversely proportional to the volume of deployments. - RTFCTL clusters are supported only for certain benchmarks. - Using Helm enables you to manage any cluster that requires customized resources for Runtime Fabric agent due to the size of the cluster. - When scaling up Runtime Fabric agent resource limit, consider increasing the request accordingly. - Try not to run a container unbounded by removing the limit completely. For OpenShift operators, removing the limit sets the agent to the default limit setting. --- product: Runtime Fabric version: 2.7 --- # Scalability Benchmarks > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric is a core Kubernetes (K8s) software and works alike in all K8s environments which comply with Runtime Fabric hardware and software requirements. > [!NOTE] These scalability benchmarks are applicable starting with Runtime Fabric 2.7.0. ## Scale Limits The following scale limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster.
LimitationDescriptionEnforced by Runtime Fabric

Deployments per Runtime Fabric

The maximum number of deployments being managed by Runtime Fabric at any instance should not exceed 8000 for optimal performance.

Recommended

Horizontal Pod Autoscaling (HPA)

With Runtime Fabric on Amazon EKS, occasional traffic failures of approximately 0.09% may occur when scaling replicas from 1 to 8. These errors are specific to the pod scaling window, so you may experience traffic failure during scaling operations.

Runtime Fabric functionality and management of application deployments is not affected by the following: - Size of individual applications - Size of worker nodes - Number of pods running per work node Because Runtime Fabric is K8s based and uses cloud-native orchestration principals, it works according to the specified configuration of deployments. ## Benchmarked Metrics Review the following benchmarked metrics to understand various management metrics when compared between a nearly empty cluster and a cluster running 8000 deployments. The cluster configuration used is Runtime Fabric on AWS EKS cluster:
ConfigurationDescription

VPC and node groups

Default configuration done from eksctl. 3 subnets (one subnet per node group), NAT Gateway.

AWS NLB

Equipped via helm chart at nginx creation.

Node Auto Scaler

Recommended 3 GB (Memory)/200m vCore (req==limit)

Workers

m5.4x large, worker node group

Monitoring

Fixed, 1 Node, Prometheus, monitoring node group, m5.2x large

Ingress

Fixed, 2 Nodes, Nginx, ingress node group, m5.4xlarge

## Runtime Fabric Restart Latency The following graphic shows how long the Runtime Fabric agent takes to restart if invoked by the customers or cluster upgrade: ![Diagram that shows restart latency between near empty cluster and loaded cluster](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric takes approximately 190 seconds to create the apps irrespective of deployment volume. The following table shows how long it takes for a Mule app to start, stop, or delete:
App OperationsNear Empty ClusterLoaded

Start Latency

~110 seconds

158 seconds

Stop Latency

~10 seconds

20 seconds

Delete Latency

~9 seconds

~28 seconds

The following table shows how long a node cordon operation takes to restart if there is a bad node:
Node OperationEmpty ClusterLoaded Cluster

Cordon

~2 seconds

~2 seconds

Drain process

~4 seconds

~35 seconds

## Considerations Review the following scale considerations: - Runtime Fabric agent requires more than default memory and CPU to manage clusters with large-scale deployments, you can modify such values using the information in the following table. For a cluster with 8000 deployments, use at least:
Cluster RecommendationsDefault200 Node/8000 App Resource Settings

Agent Resources

Memory 200Mi request, 500Mi limit. CPU 100m request, 1vCore limit.

1000Mi (Memory)/1vCore (request == limit)

Daemon Resources

Memory 200Mi request, 300Mi limit. CPU 150m request, 200m limit.

1200Mi (Memory)/500m (request == limit)

- The performance of large-scale deployment orchestration through Runtime Fabric is inversely proportional to the volume of deployments. - RTFCTL clusters are supported only for certain benchmarks. - Using Helm enables you to manage any cluster that requires customized resources for Runtime Fabric agent due to the size of the cluster. - When scaling up Runtime Fabric agent resource limit, consider increasing the request accordingly. - Try not to run a container unbounded by removing the limit completely. For OpenShift operators, removing the limit sets the agent to the default limit setting. - `resource-cache` and `mule-clusterip-service` services can be scaled horizontally because they are stateless. --- product: Runtime Fabric version: 2.8 --- # Scalability Benchmarks > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric is a core Kubernetes (K8s) software and works alike in all K8s environments which comply with Runtime Fabric hardware and software requirements. ## Scale Limits The following scale limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster.
LimitationDescriptionEnforced by Runtime Fabric

Deployments per Runtime Fabric

The maximum number of deployments being managed by Runtime Fabric at any instance should not exceed 8000 for optimal performance.

Recommended

Horizontal Pod Autoscaling (HPA)

With Runtime Fabric on Amazon EKS, occasional traffic failures of approximately 0.09% may occur when scaling replicas from 1 to 8. These errors are specific to the pod scaling window, so you may experience traffic failure during scaling operations.

Runtime Fabric functionality and management of application deployments is not affected by the following: - Size of individual applications - Size of worker nodes - Number of pods running per work node Because Runtime Fabric is K8s based and uses cloud-native orchestration principals, it works according to the specified configuration of deployments. ## Benchmarked Metrics Review the following benchmarked metrics to understand various management metrics when compared between a nearly empty cluster and a cluster running 8000 deployments. The cluster configuration used is Runtime Fabric on AWS EKS cluster:
ConfigurationDescription

VPC and node groups

Default configuration done from eksctl. 3 subnets (one subnet per node group), NAT Gateway.

AWS NLB

Equipped via helm chart at nginx creation.

Node Auto Scaler

Recommended 3 GB (Memory)/200m vCore (req==limit)

Workers

m5.4x large, worker node group

Monitoring

Fixed, 1 Node, Prometheus, monitoring node group, m5.2x large

Ingress

Fixed, 2 Nodes, Nginx, ingress node group, m5.4xlarge

## Runtime Fabric Restart Latency The following graphic shows how long the Runtime Fabric agent takes to restart if invoked by the customers or cluster upgrade: ![Diagram that shows restart latency between near empty cluster and loaded cluster](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric takes approximately 190 seconds to create the apps irrespective of deployment volume. The following table shows how long it takes for a Mule app to start, stop, or delete:
App OperationsNear Empty ClusterLoaded

Start Latency

~110 seconds

158 seconds

Stop Latency

~10 seconds

20 seconds

Delete Latency

~9 seconds

~28 seconds

The following table shows how long a node cordon operation takes to restart if there is a bad node:
Node OperationEmpty ClusterLoaded Cluster

Cordon

~2 seconds

~2 seconds

Drain process

~4 seconds

~35 seconds

## Considerations Review the following scale considerations: - Runtime Fabric agent requires more than default memory and CPU to manage clusters with large-scale deployments, you can modify such values using the information in the following table. For a cluster with 8000 deployments, use at least:
Cluster RecommendationsDefault200 Node/8000 App Resource Settings

Agent Resources

Memory 200Mi request, 500Mi limit. CPU 100m request, 1vCore limit.

1000Mi (Memory)/1vCore (request == limit)

Daemon Resources

Memory 200Mi request, 300Mi limit. CPU 150m request, 200m limit.

1200Mi (Memory)/500m (request == limit)

- The default resource allocation supports up to 2K apps / 75 nodes. - The performance of large-scale deployment orchestration through Runtime Fabric is inversely proportional to the volume of deployments. - RTFCTL clusters are supported only for certain benchmarks. - Using Helm enables you to manage any cluster that requires customized resources for Runtime Fabric agent due to the size of the cluster. - When scaling up Runtime Fabric agent resource limit, consider increasing the request accordingly. - Try not to run a container unbounded by removing the limit completely. For OpenShift operators, removing the limit sets the agent to the default limit setting. - `resource-cache` and `mule-clusterip-service` services can be scaled horizontally because they are stateless. --- product: Runtime Fabric version: 2.9 --- # Scalability Benchmarks > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric is a core Kubernetes (K8s) software and works alike in all K8s environments which comply with Runtime Fabric hardware and software requirements. ## Scale Limits The following scale limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster.
LimitationDescriptionEnforced by Runtime Fabric

Deployments per Runtime Fabric

The maximum number of deployments being managed by Runtime Fabric at any instance should not exceed 8000 for optimal performance.

Recommended

Horizontal Pod Autoscaling (HPA)

With Runtime Fabric on Amazon EKS, occasional traffic failures of approximately 0.09% may occur when scaling replicas from 1 to 8. These errors are specific to the pod scaling window, so you may experience traffic failure during scaling operations.

Runtime Fabric functionality and management of application deployments is not affected by the following: - Size of individual applications - Size of worker nodes - Number of pods running per work node Because Runtime Fabric is K8s based and uses cloud-native orchestration principals, it works according to the specified configuration of deployments. ## Benchmarked Metrics Review the following benchmarked metrics to understand various management metrics when compared between a nearly empty cluster and a cluster running 8000 deployments. The cluster configuration used is Runtime Fabric on AWS EKS cluster:
ConfigurationDescription

VPC and node groups

Default configuration done from eksctl. 3 subnets (one subnet per node group), NAT Gateway.

AWS NLB

Equipped via helm chart at nginx creation.

Node Auto Scaler

Recommended 3 GB (Memory)/200m vCore (req==limit)

Workers

m5.4x large, worker node group

Monitoring

Fixed, 1 Node, Prometheus, monitoring node group, m5.2x large

Ingress

Fixed, 2 Nodes, Nginx, ingress node group, m5.4xlarge

## Runtime Fabric Restart Latency The following graphic shows how long the Runtime Fabric agent takes to restart if invoked by the customers or cluster upgrade: ![Diagram that shows restart latency between near empty cluster and loaded cluster](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric takes approximately 190 seconds to create the apps irrespective of deployment volume. The following table shows how long it takes for a Mule app to start, stop, or delete:
App OperationsNear Empty ClusterLoaded

Start Latency

~110 seconds

158 seconds

Stop Latency

~10 seconds

20 seconds

Delete Latency

~9 seconds

~28 seconds

The following table shows how long a node cordon operation takes to restart if there is a bad node:
Node OperationEmpty ClusterLoaded Cluster

Cordon

~2 seconds

~2 seconds

Drain process

~4 seconds

~35 seconds

## Considerations Review the following scale considerations: - Runtime Fabric agent requires more than default memory and CPU to manage clusters with large-scale deployments, you can modify such values using the information in the following table. For a cluster with 8000 deployments, use at least:
Cluster RecommendationsDefault200 Node/8000 App Resource Settings

Agent Resources

Memory 200Mi request, 500Mi limit. CPU 100m request, 1vCore limit.

1000Mi (Memory)/1vCore (request == limit)

Daemon Resources

Memory 200Mi request, 300Mi limit. CPU 150m request, 200m limit.

1200Mi (Memory)/500m (request == limit)

- The default resource allocation supports up to 2K apps / 75 nodes. - The performance of large-scale deployment orchestration through Runtime Fabric is inversely proportional to the volume of deployments. - RTFCTL clusters are supported only for certain benchmarks. - Using Helm enables you to manage any cluster that requires customized resources for Runtime Fabric agent due to the size of the cluster. - When scaling up Runtime Fabric agent resource limit, consider increasing the request accordingly. - Try not to run a container unbounded by removing the limit completely. For OpenShift operators, removing the limit sets the agent to the default limit setting. - `resource-cache` and `mule-clusterip-service` services can be scaled horizontally because they are stateless. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Scalability Benchmarks > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric is a core Kubernetes (K8s) software and works alike in all K8s environments which comply with Runtime Fabric hardware and software requirements. ## Scale Limits The following scale limits are benchmarked on Amazon Elastic Kubernetes Service (Amazon EKS) cluster.
LimitationDescriptionEnforced by Runtime Fabric

Deployments per Runtime Fabric

The maximum number of deployments being managed by Runtime Fabric at any instance should not exceed 8000 for optimal performance.

Recommended

Horizontal Pod Autoscaling (HPA)

With Runtime Fabric on Amazon EKS, occasional traffic failures of approximately 0.09% may occur when scaling replicas from 1 to 8. These errors are specific to the pod scaling window, so you may experience traffic failure during scaling operations.

Runtime Fabric functionality and management of application deployments is not affected by the following: - Size of individual applications - Size of worker nodes - Number of pods running per work node Because Runtime Fabric is K8s based and uses cloud-native orchestration principals, it works according to the specified configuration of deployments. ## Benchmarked Metrics Review the following benchmarked metrics to understand various management metrics when compared between a nearly empty cluster and a cluster running 8000 deployments. The cluster configuration used is Runtime Fabric on AWS EKS cluster:
ConfigurationDescription

VPC and node groups

Default configuration done from eksctl. 3 subnets (one subnet per node group), NAT Gateway.

AWS NLB

Equipped via helm chart at nginx creation.

Node Auto Scaler

Recommended 3 GB (Memory)/200m vCore (req==limit)

Workers

m5.4x large, worker node group

Monitoring

Fixed, 1 Node, Prometheus, monitoring node group, m5.2x large

Ingress

Fixed, 2 Nodes, Nginx, ingress node group, m5.4xlarge

## Runtime Fabric Restart Latency The following graphic shows how long the Runtime Fabric agent takes to restart if invoked by the customers or cluster upgrade: ![Diagram that shows restart latency between near empty cluster and loaded cluster](/mulesoft/current/en-us/runtime-fabric/latest/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric takes approximately 190 seconds to create the apps irrespective of deployment volume. The following table shows how long it takes for a Mule app to start, stop, or delete:
App OperationsNear Empty ClusterLoaded

Start Latency

~110 seconds

158 seconds

Stop Latency

~10 seconds

20 seconds

Delete Latency

~9 seconds

~28 seconds

The following table shows how long a node cordon operation takes to restart if there is a bad node:
Node OperationEmpty ClusterLoaded Cluster

Cordon

~2 seconds

~2 seconds

Drain process

~4 seconds

~35 seconds

## Considerations Review the following scale considerations: - Runtime Fabric agent requires more than default memory and CPU to manage clusters with large-scale deployments, you can modify such values using the information in the following table. For a cluster with 8000 deployments, use at least:
Cluster RecommendationsDefault200 Node/8000 App Resource Settings

Agent Resources

Memory 200Mi request, 500Mi limit. CPU 100m request, 1vCore limit.

1000Mi (Memory)/1vCore (request == limit)

Daemon Resources

Memory 200Mi request, 300Mi limit. CPU 150m request, 200m limit.

1200Mi (Memory)/500m (request == limit)

- The default resource allocation supports up to 2K apps / 75 nodes. - The performance of large-scale deployment orchestration through Runtime Fabric is inversely proportional to the volume of deployments. - RTFCTL clusters are supported only for certain benchmarks. - Using Helm enables you to manage any cluster that requires customized resources for Runtime Fabric agent due to the size of the cluster. - When scaling up Runtime Fabric agent resource limit, consider increasing the request accordingly. - Try not to run a container unbounded by removing the limit completely. For OpenShift operators, removing the limit sets the agent to the default limit setting. - `resource-cache` and `mule-clusterip-service` services can be scaled horizontally because they are stateless. --- product: Runtime Fabric version: 2.5 --- # Secure Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To secure Anypoint Runtime Fabric, see: - [Configure Authorized Namespaces](https://docs.mulesoft.com/runtime-fabric/2.5/authorized-namespaces) - [Use a Local Registry](https://docs.mulesoft.com/runtime-fabric/2.5/configure-local-registry) - [MuleSoft Anypoint Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/2.5/security-architecture) - [Kubernetes Hardening Guide](https://docs.mulesoft.com/runtime-fabric/2.5/kubernetes-hardening-guide) --- product: Runtime Fabric version: 2.10 --- # Securing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To secure Anypoint Runtime Fabric, review the following topis: - [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/2.10/security-architecture) Understand the architecture of how Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere. - [Configuring Authorized Namespaces](https://docs.mulesoft.com/runtime-fabric/2.10/authorized-namespaces) Configure authorized namespaces to deploy Runtime Fabric alongside other services in a Kubernetes cluster. - [Enabling FIPS 140-2 Compliance Mode](https://docs.mulesoft.com/runtime-fabric/2.10/enable-fips-140-2-compliance) Configure Runtime Fabric to run application containers in FIPS 140-2 compliance mode. - [Using a Local Registry](https://docs.mulesoft.com/runtime-fabric/2.10/configure-local-registry) Use a local registry to pull and store Docker images. - [Hardening Mule Runtime](https://docs.mulesoft.com/runtime-fabric/2.10/configure-hardening) Review best practices for Mule runtime engine hardening with Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.11 --- # Securing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To secure Anypoint Runtime Fabric, review these topics: - [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/2.11/security-architecture) Understand the architecture of how Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere. - [Configuring Authorized Namespaces](https://docs.mulesoft.com/runtime-fabric/2.11/authorized-namespaces) Configure authorized namespaces to deploy Runtime Fabric alongside other services in a Kubernetes cluster. - [Enabling FIPS 140-2 Compliance Mode](https://docs.mulesoft.com/runtime-fabric/2.11/enable-fips-140-2-compliance) Configure Runtime Fabric to run application containers in FIPS 140-2 compliance mode. - [Using a Local Registry](https://docs.mulesoft.com/runtime-fabric/2.11/configure-local-registry) Use a local registry to pull and store Docker images. - [Hardening Mule Runtime](https://docs.mulesoft.com/runtime-fabric/2.11/configure-hardening) Review best practices for Mule runtime engine hardening with Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.6 --- # Securing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To secure Anypoint Runtime Fabric, review the following topis: - [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/2.6/security-architecture) Understand the architecture of how Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere. - [Configuring Authorized Namespaces](https://docs.mulesoft.com/runtime-fabric/2.6/authorized-namespaces) Configure authorized namespaces to deploy Runtime Fabric alongside other services in a Kubernetes cluster. - [Enabling FIPS 140-2 Compliance Mode](https://docs.mulesoft.com/runtime-fabric/2.6/enable-fips-140-2-compliance) Configure Runtime Fabric to run application containers in FIPS 140-2 compliance mode. - [Using a Local Registry](https://docs.mulesoft.com/runtime-fabric/2.6/configure-local-registry) Use a local registry to pull and store Docker images. - [Hardening Mule Runtime](https://docs.mulesoft.com/runtime-fabric/2.6/configure-hardening) Review best practices for Mule runtime engine hardening with Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.7 --- # Securing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To secure Anypoint Runtime Fabric, review the following topis: - [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/2.7/security-architecture) Understand the architecture of how Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere. - [Configuring Authorized Namespaces](https://docs.mulesoft.com/runtime-fabric/2.7/authorized-namespaces) Configure authorized namespaces to deploy Runtime Fabric alongside other services in a Kubernetes cluster. - [Enabling FIPS 140-2 Compliance Mode](https://docs.mulesoft.com/runtime-fabric/2.7/enable-fips-140-2-compliance) Configure Runtime Fabric to run application containers in FIPS 140-2 compliance mode. - [Using a Local Registry](https://docs.mulesoft.com/runtime-fabric/2.7/configure-local-registry) Use a local registry to pull and store Docker images. - [Hardening Mule Runtime](https://docs.mulesoft.com/runtime-fabric/2.7/configure-hardening) Review best practices for Mule runtime engine hardening with Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.8 --- # Securing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To secure Anypoint Runtime Fabric, review the following topis: - [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/2.8/security-architecture) Understand the architecture of how Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere. - [Configuring Authorized Namespaces](https://docs.mulesoft.com/runtime-fabric/2.8/authorized-namespaces) Configure authorized namespaces to deploy Runtime Fabric alongside other services in a Kubernetes cluster. - [Enabling FIPS 140-2 Compliance Mode](https://docs.mulesoft.com/runtime-fabric/2.8/enable-fips-140-2-compliance) Configure Runtime Fabric to run application containers in FIPS 140-2 compliance mode. - [Using a Local Registry](https://docs.mulesoft.com/runtime-fabric/2.8/configure-local-registry) Use a local registry to pull and store Docker images. - [Hardening Mule Runtime](https://docs.mulesoft.com/runtime-fabric/2.8/configure-hardening) Review best practices for Mule runtime engine hardening with Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.9 --- # Securing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To secure Anypoint Runtime Fabric, review the following topis: - [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/2.9/security-architecture) Understand the architecture of how Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere. - [Configuring Authorized Namespaces](https://docs.mulesoft.com/runtime-fabric/2.9/authorized-namespaces) Configure authorized namespaces to deploy Runtime Fabric alongside other services in a Kubernetes cluster. - [Enabling FIPS 140-2 Compliance Mode](https://docs.mulesoft.com/runtime-fabric/2.9/enable-fips-140-2-compliance) Configure Runtime Fabric to run application containers in FIPS 140-2 compliance mode. - [Using a Local Registry](https://docs.mulesoft.com/runtime-fabric/2.9/configure-local-registry) Use a local registry to pull and store Docker images. - [Hardening Mule Runtime](https://docs.mulesoft.com/runtime-fabric/2.9/configure-hardening) Review best practices for Mule runtime engine hardening with Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/hardening-runtime-fabric) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Securing Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To secure Anypoint Runtime Fabric, review the following topis: - [Runtime Fabric Security Architecture](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture) Understand the architecture of how Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere. - [Configuring Authorized Namespaces](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces) Configure authorized namespaces to deploy Runtime Fabric alongside other services in a Kubernetes cluster. - [Enabling FIPS 140-2 Compliance Mode](https://docs.mulesoft.com/runtime-fabric/latest/enable-fips-140-2-compliance) Configure Runtime Fabric to run application containers in FIPS 140-2 compliance mode. - [Using a Local Registry](https://docs.mulesoft.com/runtime-fabric/latest/configure-local-registry) Use a local registry to pull and store Docker images. - [Hardening Mule Runtime](https://docs.mulesoft.com/runtime-fabric/latest/configure-hardening) Review best practices for Mule runtime engine hardening with Runtime Fabric. ## See Also - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.10 --- # Sending Application-to-Application Requests in the Same Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt In an Anypoint Runtime Fabric cluster, every application replica exposes an endpoint inside the cluster. When you enable inbound traffic, that endpoint is exposed externally. Refer to [Configuring Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/custom-ingress-configuration) for additional information about servicing external requests. To send a request from one application to another application inside the cluster, use the application name and environment ID. Every application has a DNS record in the cluster internal domain. For example, the DNS record for the application `hello-world` in the `2abc2ce6-cce6-463b-afaa-a1979e3xxxxx` environment is: ```none hello-world.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 and environment ID to send a request to another application in the same cluster. If both applications are in the same namespace, you need only the application name: ```none http://hello-world:8081/api ``` If required, replace `http` with `https`. The following example sends a request from one application to an application in another namespace. In this example, `1abc2ce6-cce6-463b-afaa-a1979e3xxxxx` is another envionment in the same Runtime Fabric cluster, so this environment ID is appended to the application name: ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` --- product: Runtime Fabric version: 2.11 --- # Sending Application-to-Application Requests in the Same Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt In an Anypoint Runtime Fabric cluster, every application replica exposes an endpoint inside the cluster. When you enable inbound traffic, that endpoint is exposed externally. Refer to [Configuring Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/custom-ingress-configuration) for additional information about servicing external requests. To send a request from one application to another application inside the cluster, use the application name and environment ID. Every application has a DNS record in the cluster internal domain. For example, the DNS record for the application `hello-world` in the `2abc2ce6-cce6-463b-afaa-a1979e3xxxxx` environment is: ```none hello-world.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 and environment ID to send a request to another application in the same cluster. If both applications are in the same namespace, you need only the application name: ```none http://hello-world:8081/api ``` If required, replace `http` with `https`. The following example sends a request from one application to an application in another namespace. In this example, `1abc2ce6-cce6-463b-afaa-a1979e3xxxxx` is another envionment in the same Runtime Fabric cluster, so this environment ID is appended to the application name: ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` --- product: Runtime Fabric version: 2.5 --- # Sending Application-to-Application Requests in the Same Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt In an Anypoint Runtime Fabric cluster, every application replica exposes an endpoint inside the cluster. When you enable inbound traffic, that endpoint is exposed externally. Refer to [Configuring Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/custom-ingress-configuration) for additional information about servicing external requests. To send a request from one application to another application inside the cluster, use the application name and environment ID. Every application has a DNS record in the cluster internal domain. For example, the DNS record for the application `hello-world` in the `2abc2ce6-cce6-463b-afaa-a1979e3xxxxx` environment is: ```none hello-world.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 and environment ID to send a request to another application in the same cluster. If both applications are in the same namespace, you need only the application name: ```none http://hello-world:8081/api ``` If required, replace `http` with `https`. The following example sends a request from one application to an application in another namespace. In this example, `1abc2ce6-cce6-463b-afaa-a1979e3xxxxx` is another envionment in the same Runtime Fabric cluster, so this environment ID is appended to the application name: ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` --- product: Runtime Fabric version: 2.6 --- # Sending Application-to-Application Requests in the Same Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt In an Anypoint Runtime Fabric cluster, every application replica exposes an endpoint inside the cluster. When you enable inbound traffic, that endpoint is exposed externally. Refer to [Configuring Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/custom-ingress-configuration) for additional information about servicing external requests. To send a request from one application to another application inside the cluster, use the application name and environment ID. Every application has a DNS record in the cluster internal domain. For example, the DNS record for the application `hello-world` in the `2abc2ce6-cce6-463b-afaa-a1979e3xxxxx` environment is: ```none hello-world.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 and environment ID to send a request to another application in the same cluster. If both applications are in the same namespace, you need only the application name: ```none http://hello-world:8081/api ``` If required, replace `http` with `https`. The following example sends a request from one application to an application in another namespace. In this example, `1abc2ce6-cce6-463b-afaa-a1979e3xxxxx` is another envionment in the same Runtime Fabric cluster, so this environment ID is appended to the application name: ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` --- product: Runtime Fabric version: 2.7 --- # Sending Application-to-Application Requests in the Same Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt In an Anypoint Runtime Fabric cluster, every application replica exposes an endpoint inside the cluster. When you enable inbound traffic, that endpoint is exposed externally. Refer to [Configuring Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/custom-ingress-configuration) for additional information about servicing external requests. To send a request from one application to another application inside the cluster, use the application name and environment ID. Every application has a DNS record in the cluster internal domain. For example, the DNS record for the application `hello-world` in the `2abc2ce6-cce6-463b-afaa-a1979e3xxxxx` environment is: ```none hello-world.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 and environment ID to send a request to another application in the same cluster. If both applications are in the same namespace, you need only the application name: ```none http://hello-world:8081/api ``` If required, replace `http` with `https`. The following example sends a request from one application to an application in another namespace. In this example, `1abc2ce6-cce6-463b-afaa-a1979e3xxxxx` is another envionment in the same Runtime Fabric cluster, so this environment ID is appended to the application name: ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` --- product: Runtime Fabric version: 2.8 --- # Sending Application-to-Application Requests in the Same Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt In an Anypoint Runtime Fabric cluster, every application replica exposes an endpoint inside the cluster. When you enable inbound traffic, that endpoint is exposed externally. Refer to [Configuring Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/custom-ingress-configuration) for additional information about servicing external requests. To send a request from one application to another application inside the cluster, use the application name and environment ID. Every application has a DNS record in the cluster internal domain. For example, the DNS record for the application `hello-world` in the `2abc2ce6-cce6-463b-afaa-a1979e3xxxxx` environment is: ```none hello-world.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 and environment ID to send a request to another application in the same cluster. If both applications are in the same namespace, you need only the application name: ```none http://hello-world:8081/api ``` If required, replace `http` with `https`. The following example sends a request from one application to an application in another namespace. In this example, `1abc2ce6-cce6-463b-afaa-a1979e3xxxxx` is another envionment in the same Runtime Fabric cluster, so this environment ID is appended to the application name: ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` --- product: Runtime Fabric version: 2.9 --- # Sending Application-to-Application Requests in the Same Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt In an Anypoint Runtime Fabric cluster, every application replica exposes an endpoint inside the cluster. When you enable inbound traffic, that endpoint is exposed externally. Refer to [Configuring Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/custom-ingress-configuration) for additional information about servicing external requests. To send a request from one application to another application inside the cluster, use the application name and environment ID. Every application has a DNS record in the cluster internal domain. For example, the DNS record for the application `hello-world` in the `2abc2ce6-cce6-463b-afaa-a1979e3xxxxx` environment is: ```none hello-world.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 and environment ID to send a request to another application in the same cluster. If both applications are in the same namespace, you need only the application name: ```none http://hello-world:8081/api ``` If required, replace `http` with `https`. The following example sends a request from one application to an application in another namespace. In this example, `1abc2ce6-cce6-463b-afaa-a1979e3xxxxx` is another envionment in the same Runtime Fabric cluster, so this environment ID is appended to the application name: ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Sending Application-to-Application Requests in the Same Cluster > For the full documentation index, see: https://docs.mulesoft.com/llms.txt In an Anypoint Runtime Fabric cluster, every application replica exposes an endpoint inside the cluster. When you enable inbound traffic, that endpoint is exposed externally. Refer to [Configuring Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration) for additional information about servicing external requests. To send a request from one application to another application inside the cluster, use the application name and environment ID. Every application has a DNS record in the cluster internal domain. For example, the DNS record for the application `hello-world` in the `2abc2ce6-cce6-463b-afaa-a1979e3xxxxx` environment is: ```none hello-world.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 and environment ID to send a request to another application in the same cluster. If both applications are in the same namespace, you need only the application name: ```none http://hello-world:8081/api ``` If required, replace `http` with `https`. The following example sends a request from one application to an application in another namespace. In this example, `1abc2ce6-cce6-463b-afaa-a1979e3xxxxx` is another envionment in the same Runtime Fabric cluster, so this environment ID is appended to the application name: ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` > [!NOTE] If your Environment ID (namespace) starts with a number (0-9), you can’t use the short > hostname format previously shown (for example, `[http://my-app.569c…​](http://my-app.569c…​);`). > This results in a URI parsing error because hostnames starting with numbers don’t comply with RFC > 2396 standards. > > In these cases, you must use the Fully Qualified Domain Name (FQDN) format instead: > > ```none > http://my-app.569c2ce6-cce6-463b-afaa-a1979e3xxxxx.svc.cluster.local:8081/api > ``` --- product: Runtime Fabric version: 2.10 --- # Setting Up RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you enable `rtfctl` Kubernetes permissions and install `rtfctl` command line tool. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.10/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Installing RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl#install-rtfctl) Install the `rtfctl` command line tool to locally manage Runtime Fabrics. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 2.11 --- # Setting Up RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you enable `rtfctl` Kubernetes permissions and install `rtfctl` command line tool. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.11/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Installing RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl#install-rtfctl) Install the `rtfctl` command line tool to locally manage Runtime Fabrics. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 2.6 --- # Setting Up RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you enable `rtfctl` Kubernetes permissions and install `rtfctl` command line tool. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.6/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Installing RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl#install-rtfctl) Install the `rtfctl` command line tool to locally manage Runtime Fabrics. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/2.6/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 2.7 --- # Setting Up RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you enable `rtfctl` Kubernetes permissions and install `rtfctl` command line tool. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.7/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Installing RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl#install-rtfctl) Install the `rtfctl` command line tool to locally manage Runtime Fabrics. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/2.7/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 2.8 --- # Setting Up RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you enable `rtfctl` Kubernetes permissions and install `rtfctl` command line tool. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.8/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Installing RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl#install-rtfctl) Install the `rtfctl` command line tool to locally manage Runtime Fabrics. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/2.8/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 2.9 --- # Setting Up RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you enable `rtfctl` Kubernetes permissions and install `rtfctl` command line tool. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/2.9/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Installing RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl#install-rtfctl) Install the `rtfctl` command line tool to locally manage Runtime Fabrics. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Setting Up RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you enable `rtfctl` Kubernetes permissions and install `rtfctl` command line tool. - [Enabling RTFCTL Kubernetes Permissions](https://docs.mulesoft.com/runtime-fabric/latest/rtfctl-permissions) Enable specific role permissions over Kubernetes resources to successfully run `rtfctl` commands. - [Installing RTFCTL Tool](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#install-rtfctl) Install the `rtfctl` command line tool to locally manage Runtime Fabrics. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 2.10 --- # Setting Up Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you install, configure, uninstall, and upgrade Anypoint Runtime Fabric. - [Preparing your VM/Bare Metal Cluster for Runtime Fabric Installation](https://docs.mulesoft.com/runtime-fabric/2.10/index-vm-bare-metal) Ensure that the VM/Bare metal cluster underlying infrastructure meets the necessary hardware and networking requirements to install Runtime Fabric effectively. - [Configuring Network](https://docs.mulesoft.com/runtime-fabric/2.10/install-self-managed-network-configuration) Configure ports and hostnames correctly before installing Runtime Fabric. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-index) Install Runtime Fabric using `rtfctl`, Helm, as a Kubernetes (K8s) operator, or install multiple instances of Runtime Fabric. - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/configuring-runtime-fabric) Configure network connections, ingress, Red Hat OpenShift routes, persistence gateway, proxies, and associate business groups and environments. Additionally, you can use `rtfctl` to configure Runtime Fabric. - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/uninstall-self) Unistall Runtime Fabric using `rtfctl`, Helm, or on Red Hat OpenShift. - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/upgrade-index) Upgrade Runtime Fabric using `rtfctl`, Helm, or as a Kubernetes (K8s) operator. ## See Also - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/manage-index) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.11 --- # Setting Up Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you install, configure, uninstall, and upgrade Anypoint Runtime Fabric. - [Preparing your VM/Bare Metal Cluster for Runtime Fabric Installation](https://docs.mulesoft.com/runtime-fabric/2.11/index-vm-bare-metal) Ensure that the VM/Bare metal cluster underlying infrastructure meets the necessary hardware and networking requirements to install Runtime Fabric effectively. - [Configuring Network](https://docs.mulesoft.com/runtime-fabric/2.11/install-self-managed-network-configuration) Configure ports and hostnames correctly before installing Runtime Fabric. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-index) Install Runtime Fabric using `rtfctl`, Helm, as a Kubernetes (K8s) operator, or install multiple instances of Runtime Fabric. - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/configuring-runtime-fabric) Configure network connections, ingress, Red Hat OpenShift routes, persistence gateway, proxies, and associate business groups and environments. Additionally, you can use `rtfctl` to configure Runtime Fabric. - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/uninstall-self) Unistall Runtime Fabric using `rtfctl`, Helm, or on Red Hat OpenShift. - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/upgrade-index) Upgrade Runtime Fabric using `rtfctl`, Helm, or as a Kubernetes (K8s) operator. ## See Also - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/manage-index) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.6 --- # Setting Up Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you install, configure, uninstall, and upgrade Anypoint Runtime Fabric. - [Preparing your VM/Bare Metal Cluster for Runtime Fabric Installation](https://docs.mulesoft.com/runtime-fabric/2.6/index-vm-bare-metal) Ensure that the VM/Bare metal cluster underlying infrastructure meets the necessary hardware and networking requirements to install Runtime Fabric effectively. - [Configuring Network](https://docs.mulesoft.com/runtime-fabric/2.6/install-self-managed-network-configuration) Configure ports and hostnames correctly before installing Runtime Fabric. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-index) Install Runtime Fabric using `rtfctl`, Helm, as a Kubernetes (K8s) operator, or install multiple instances of Runtime Fabric. - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/configuring-runtime-fabric) Configure network connections, ingress, Red Hat OpeShift routes, persistence gateway, proxies, and associate business groups and environments. Additionally, you can use `rtfctl` to configure Runtime Fabric. - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/uninstall-self) Unistall Runtime Fabric using `rtfctl`, Helm, or on Red Hat OpenShift. - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/upgrade-index) Upgrade Runtime Fabric using `rtfctl`, Helm, or as a Kubernetes (K8s) operator. ## See Also - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/manage-index) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.7 --- # Setting Up Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you install, configure, uninstall, and upgrade Anypoint Runtime Fabric. - [Preparing your VM/Bare Metal Cluster for Runtime Fabric Installation](https://docs.mulesoft.com/runtime-fabric/2.7/index-vm-bare-metal) Ensure that the VM/Bare metal cluster underlying infrastructure meets the necessary hardware and networking requirements to install Runtime Fabric effectively. - [Configuring Network](https://docs.mulesoft.com/runtime-fabric/2.7/install-self-managed-network-configuration) Configure ports and hostnames correctly before installing Runtime Fabric. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-index) Install Runtime Fabric using `rtfctl`, Helm, as a Kubernetes (K8s) operator, or install multiple instances of Runtime Fabric. - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/configuring-runtime-fabric) Configure network connections, ingress, Red Hat OpeShift routes, persistence gateway, proxies, and associate business groups and environments. Additionally, you can use `rtfctl` to configure Runtime Fabric. - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/uninstall-self) Unistall Runtime Fabric using `rtfctl`, Helm, or on Red Hat OpenShift. - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/upgrade-index) Upgrade Runtime Fabric using `rtfctl`, Helm, or as a Kubernetes (K8s) operator. ## See Also - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/manage-index) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.8 --- # Setting Up Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you install, configure, uninstall, and upgrade Anypoint Runtime Fabric. - [Preparing your VM/Bare Metal Cluster for Runtime Fabric Installation](https://docs.mulesoft.com/runtime-fabric/2.8/index-vm-bare-metal) Ensure that the VM/Bare metal cluster underlying infrastructure meets the necessary hardware and networking requirements to install Runtime Fabric effectively. - [Configuring Network](https://docs.mulesoft.com/runtime-fabric/2.8/install-self-managed-network-configuration) Configure ports and hostnames correctly before installing Runtime Fabric. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-index) Install Runtime Fabric using `rtfctl`, Helm, as a Kubernetes (K8s) operator, or install multiple instances of Runtime Fabric. - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/configuring-runtime-fabric) Configure network connections, ingress, Red Hat OpenShift routes, persistence gateway, proxies, and associate business groups and environments. Additionally, you can use `rtfctl` to configure Runtime Fabric. - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/uninstall-self) Unistall Runtime Fabric using `rtfctl`, Helm, or on Red Hat OpenShift. - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/upgrade-index) Upgrade Runtime Fabric using `rtfctl`, Helm, or as a Kubernetes (K8s) operator. ## See Also - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-index) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.9 --- # Setting Up Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you install, configure, uninstall, and upgrade Anypoint Runtime Fabric. - [Preparing your VM/Bare Metal Cluster for Runtime Fabric Installation](https://docs.mulesoft.com/runtime-fabric/2.9/index-vm-bare-metal) Ensure that the VM/Bare metal cluster underlying infrastructure meets the necessary hardware and networking requirements to install Runtime Fabric effectively. - [Configuring Network](https://docs.mulesoft.com/runtime-fabric/2.9/install-self-managed-network-configuration) Configure ports and hostnames correctly before installing Runtime Fabric. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-index) Install Runtime Fabric using `rtfctl`, Helm, as a Kubernetes (K8s) operator, or install multiple instances of Runtime Fabric. - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/configuring-runtime-fabric) Configure network connections, ingress, Red Hat OpenShift routes, persistence gateway, proxies, and associate business groups and environments. Additionally, you can use `rtfctl` to configure Runtime Fabric. - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/uninstall-self) Unistall Runtime Fabric using `rtfctl`, Helm, or on Red Hat OpenShift. - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/upgrade-index) Upgrade Runtime Fabric using `rtfctl`, Helm, or as a Kubernetes (K8s) operator. ## See Also - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/manage-index) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/hardening-runtime-fabric) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Setting Up Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following topics help you install, configure, uninstall, and upgrade Anypoint Runtime Fabric. - [Preparing your VM/Bare Metal Cluster for Runtime Fabric Installation](https://docs.mulesoft.com/runtime-fabric/latest/index-vm-bare-metal) Ensure that the VM/Bare metal cluster underlying infrastructure meets the necessary hardware and networking requirements to install Runtime Fabric effectively. - [Configuring Network](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration) Configure ports and hostnames correctly before installing Runtime Fabric. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-index) Install Runtime Fabric using `rtfctl`, Helm, as a Kubernetes (K8s) operator, or install multiple instances of Runtime Fabric. - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/configuring-runtime-fabric) Configure network connections, ingress, Red Hat OpenShift routes, persistence gateway, proxies, and associate business groups and environments. Additionally, you can use `rtfctl` to configure Runtime Fabric. - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/uninstall-self) Unistall Runtime Fabric using `rtfctl`, Helm, or on Red Hat OpenShift. - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-index) Upgrade Runtime Fabric using `rtfctl`, Helm, or as a Kubernetes (K8s) operator. ## See Also - [Managing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/manage-index) - [Hardening Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/hardening-runtime-fabric) --- product: Runtime Fabric version: 2.10 --- # Troubleshooting Runtime Fabric with RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to troubleshoot Runtime Fabric. ## Commands for Troubleshooting Runtime Fabric
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

### `get` Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ### `ping` Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ### `report` Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ### `status` Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ### `test` Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl) - [Known Issues](https://help.salesforce.com/s/issues) --- product: Runtime Fabric version: 2.11 --- # Troubleshooting Runtime Fabric with RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to troubleshoot Runtime Fabric.
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

## `get` Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ## `ping` Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ## `report` Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ## `status` Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ## `test` Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl) - [Known Issues](https://help.salesforce.com/s/issues) --- product: Runtime Fabric version: 2.9 --- # Troubleshooting Runtime Fabric with RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to troubleshoot Runtime Fabric. ## Commands for Troubleshooting Runtime Fabric
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

### get Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ### ping Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ### report Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ### status Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ### test Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl) - [Known Issues](https://help.salesforce.com/s/issues) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Troubleshooting Runtime Fabric with RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these `rtfctl` commands to troubleshoot Runtime Fabric.
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

## `get` Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ## `ping` Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ## `report` Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ## `status` Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ## `test` Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl) - [Known Issues](https://help.salesforce.com/s/issues) --- product: Runtime Fabric version: 2.10 --- # Uninstall Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To uninstall Runtime Fabric using `rtfctl` commands, follow these steps: 1. Using Runtime Manager, delete all Mule app and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. In Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## See Also - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/uninstall-self) --- product: Runtime Fabric version: 2.11 --- # Uninstall Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To uninstall Runtime Fabric using `rtfctl` commands, follow these steps: 1. Using Runtime Manager, delete all Mule app and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. In Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## See Also - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/uninstall-self) --- product: Runtime Fabric version: 2.9 --- # Uninstall Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To uninstall Runtime Fabric using `rtfctl` commands, follow these steps: 1. Using Runtime Manager, delete all Mule app and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. In Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## See Also - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/uninstall-self) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Uninstall Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To uninstall Runtime Fabric using `rtfctl` commands, follow these steps: 1. Using Runtime Manager, delete all Mule app and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. In Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## See Also - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/uninstall-self) --- product: Runtime Fabric version: 2.10 --- # Uninstalling Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Depending on your installation method, you can use the Runtime Fabric command line tool (`rtfctl`) or Helm to uninstall Runtime Fabric. ## Uninstall Runtime Fabric Using RTFCTL To uninstall Runtime Fabric using `rtfctl` commands, follow these steps: 1. Using Runtime Manager, delete all Mule app and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. In Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## Uninstall Runtime Fabric Using Helm To uninstall Runtime Fabric using Helm: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. Using Runtime Manager, delete the Runtime Fabric. 4. Run the following command: ```copy helm uninstall runtime-fabric -n rtf ``` If need to uninstall due to an error in the installation process, for example, if the install did not complete correctly, run the following command: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` ## Uninstalling Runtime Fabric on Red Hat OpenShift Perform the following procedure to uninstall Runtime Fabric on Red Hat OpenShift: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify that you have removed all applications from all associated environments. 3. Using Runtime Manager, delete the Runtime Fabric. 4. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 5. Select the Runtime Fabric operator. 6. Click **Uninstall**. 7. Using the following Helm command, uninstall Runtime Fabric from the cluster: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` 8. Delete the `rtf` namespace from the cluster: ```copy oc delete ns rtf ``` ### Troubleshooting Deletion of the rtf Namespace If the command to delete the `rtf` namespace does not work, complete the following steps: 1. Run the following command: ```copy oc get ns rtf -o json > rtf.json ``` 2. Edit `rtf.json` and remove `kubernetes` from the `finalizer` array. 3. Run the following commands: ```copy oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json oc get ns ``` 4. Confirm the `rtf` namespace is no longer present. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/configuring-runtime-fabric) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/upgrade-index) --- product: Runtime Fabric version: 2.11 --- # Uninstalling Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Depending on your installation method, you can use the Runtime Fabric command line tool (`rtfctl`) or Helm to uninstall Runtime Fabric. ## Uninstall Runtime Fabric Using RTFCTL To uninstall Runtime Fabric using `rtfctl` commands, follow these steps: 1. Using Runtime Manager, delete all Mule app and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. In Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## Uninstall Runtime Fabric Using Helm To uninstall Runtime Fabric using Helm: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. Using Runtime Manager, delete the Runtime Fabric. 4. Run this command: ```copy helm uninstall runtime-fabric -n rtf ``` If need to uninstall due to an error in the installation process, for example, if the install did not complete correctly, run this command: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` ## Uninstalling Runtime Fabric on Red Hat OpenShift Perform this procedure to uninstall Runtime Fabric on Red Hat OpenShift: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify that you have removed all applications from all associated environments. 3. Using Runtime Manager, delete the Runtime Fabric. 4. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 5. Select the Runtime Fabric operator. 6. Click **Uninstall**. 7. Using this Helm command, uninstall Runtime Fabric from the cluster: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` 8. Delete the `rtf` namespace from the cluster: ```copy oc delete ns rtf ``` ### Troubleshooting Deletion of the rtf Namespace If the command to delete the `rtf` namespace does not work, complete these steps: 1. Run this command: ```copy oc get ns rtf -o json > rtf.json ``` 2. Edit `rtf.json` and remove `kubernetes` from the `finalizer` array. 3. Run these commands: ```copy oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json oc get ns ``` 4. Confirm the `rtf` namespace is no longer present. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/configuring-runtime-fabric) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/upgrade-index) --- product: Runtime Fabric version: 2.5 --- # Uninstalling Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Depending on your installation method, you can use the Runtime Fabric command line tool (`rtfctl`) or Helm to uninstall Runtime Fabric. ## Uninstall Runtime Fabric Using rtfctl To uninstall Runtime Fabric using `rtfctl`: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. Using Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## Uninstall Runtime Fabric Using Helm To uninstall Runtime Fabric using Helm: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. Using Runtime Manager, delete the Runtime Fabric. 4. Run the following command: ```copy helm uninstall runtime-fabric -n rtf ``` If need to uninstall due to an error in the installation process, for example, if the install did not complete correctly, run the following command: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` ## Uninstalling Runtime Fabric on Red Hat OpenShift Perform the following procedure to uninstall Runtime Fabric on Red Hat OpenShift: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify that you have removed all applications from all associated environments. 3. Using Runtime Manager, delete the Runtime Fabric. 4. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 5. Select the Runtime Fabric operator. 6. Click **Uninstall**. 7. Using the following Helm command, uninstall Runtime Fabric from the cluster: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` 8. Delete the `rtf` namespace from the cluster: ```copy oc delete ns rtf ``` ### Troubleshooting Deletion of the rtf Namespace If the command to delete the `rtf` namespace does not work, complete the following steps: 1. Run the following command: ```copy oc get ns rtf -o json > rtf.json ``` 2. Edit `rtf.json` and remove `kubernetes` from the `finalizer` array. 3. Run the following commands: ```copy oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json oc get ns ``` 4. Confirm the `rtf` namespace is no longer present. --- product: Runtime Fabric version: 2.6 --- # Uninstalling Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Depending on your installation method, you can use the Runtime Fabric command line tool (`rtfctl`) or Helm to uninstall Runtime Fabric. ## Uninstall Runtime Fabric Using rtfctl To uninstall Runtime Fabric using `rtfctl`: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. Using Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## Uninstall Runtime Fabric Using Helm To uninstall Runtime Fabric using Helm: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. Using Runtime Manager, delete the Runtime Fabric. 4. Run the following command: ```copy helm uninstall runtime-fabric -n rtf ``` If need to uninstall due to an error in the installation process, for example, if the install did not complete correctly, run the following command: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` ## Uninstalling Runtime Fabric on Red Hat OpenShift Perform the following procedure to uninstall Runtime Fabric on Red Hat OpenShift: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify that you have removed all applications from all associated environments. 3. Using Runtime Manager, delete the Runtime Fabric. 4. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 5. Select the Runtime Fabric operator. 6. Click **Uninstall**. 7. Using the following Helm command, uninstall Runtime Fabric from the cluster: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` 8. Delete the `rtf` namespace from the cluster: ```copy oc delete ns rtf ``` ### Troubleshooting Deletion of the rtf Namespace If the command to delete the `rtf` namespace does not work, complete the following steps: 1. Run the following command: ```copy oc get ns rtf -o json > rtf.json ``` 2. Edit `rtf.json` and remove `kubernetes` from the `finalizer` array. 3. Run the following commands: ```copy oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json oc get ns ``` 4. Confirm the `rtf` namespace is no longer present. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/configuring-runtime-fabric) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/upgrade-index) --- product: Runtime Fabric version: 2.7 --- # Uninstalling Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Depending on your installation method, you can use the Runtime Fabric command line tool (`rtfctl`) or Helm to uninstall Runtime Fabric. ## Uninstall Runtime Fabric Using rtfctl To uninstall Runtime Fabric using `rtfctl`: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. Using Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## Uninstall Runtime Fabric Using Helm To uninstall Runtime Fabric using Helm: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. Using Runtime Manager, delete the Runtime Fabric. 4. Run the following command: ```copy helm uninstall runtime-fabric -n rtf ``` If need to uninstall due to an error in the installation process, for example, if the install did not complete correctly, run the following command: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` ## Uninstalling Runtime Fabric on Red Hat OpenShift Perform the following procedure to uninstall Runtime Fabric on Red Hat OpenShift: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify that you have removed all applications from all associated environments. 3. Using Runtime Manager, delete the Runtime Fabric. 4. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 5. Select the Runtime Fabric operator. 6. Click **Uninstall**. 7. Using the following Helm command, uninstall Runtime Fabric from the cluster: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` 8. Delete the `rtf` namespace from the cluster: ```copy oc delete ns rtf ``` ### Troubleshooting Deletion of the rtf Namespace If the command to delete the `rtf` namespace does not work, complete the following steps: 1. Run the following command: ```copy oc get ns rtf -o json > rtf.json ``` 2. Edit `rtf.json` and remove `kubernetes` from the `finalizer` array. 3. Run the following commands: ```copy oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json oc get ns ``` 4. Confirm the `rtf` namespace is no longer present. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/configuring-runtime-fabric) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/upgrade-index) --- product: Runtime Fabric version: 2.8 --- # Uninstalling Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Depending on your installation method, you can use the Runtime Fabric command line tool (`rtfctl`) or Helm to uninstall Runtime Fabric. ## Uninstall Runtime Fabric Using rtfctl To uninstall Runtime Fabric using `rtfctl`: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. Using Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## Uninstall Runtime Fabric Using Helm To uninstall Runtime Fabric using Helm: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. Using Runtime Manager, delete the Runtime Fabric. 4. Run the following command: ```copy helm uninstall runtime-fabric -n rtf ``` If need to uninstall due to an error in the installation process, for example, if the install did not complete correctly, run the following command: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` ## Uninstalling Runtime Fabric on Red Hat OpenShift Perform the following procedure to uninstall Runtime Fabric on Red Hat OpenShift: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify that you have removed all applications from all associated environments. 3. Using Runtime Manager, delete the Runtime Fabric. 4. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 5. Select the Runtime Fabric operator. 6. Click **Uninstall**. 7. Using the following Helm command, uninstall Runtime Fabric from the cluster: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` 8. Delete the `rtf` namespace from the cluster: ```copy oc delete ns rtf ``` ### Troubleshooting Deletion of the rtf Namespace If the command to delete the `rtf` namespace does not work, complete the following steps: 1. Run the following command: ```copy oc get ns rtf -o json > rtf.json ``` 2. Edit `rtf.json` and remove `kubernetes` from the `finalizer` array. 3. Run the following commands: ```copy oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json oc get ns ``` 4. Confirm the `rtf` namespace is no longer present. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/configuring-runtime-fabric) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/upgrade-index) --- product: Runtime Fabric version: 2.9 --- # Uninstalling Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Depending on your installation method, you can use the Runtime Fabric command line tool (`rtfctl`) or Helm to uninstall Runtime Fabric. ## Uninstall Runtime Fabric Using RTFCTL To uninstall Runtime Fabric using `rtfctl` commands, follow these steps: 1. Using Runtime Manager, delete all Mule app and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. In Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## Uninstall Runtime Fabric Using Helm To uninstall Runtime Fabric using Helm: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. Using Runtime Manager, delete the Runtime Fabric. 4. Run the following command: ```copy helm uninstall runtime-fabric -n rtf ``` If need to uninstall due to an error in the installation process, for example, if the install did not complete correctly, run the following command: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` ## Uninstalling Runtime Fabric on Red Hat OpenShift Perform the following procedure to uninstall Runtime Fabric on Red Hat OpenShift: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify that you have removed all applications from all associated environments. 3. Using Runtime Manager, delete the Runtime Fabric. 4. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 5. Select the Runtime Fabric operator. 6. Click **Uninstall**. 7. Using the following Helm command, uninstall Runtime Fabric from the cluster: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` 8. Delete the `rtf` namespace from the cluster: ```copy oc delete ns rtf ``` ### Troubleshooting Deletion of the rtf Namespace If the command to delete the `rtf` namespace does not work, complete the following steps: 1. Run the following command: ```copy oc get ns rtf -o json > rtf.json ``` 2. Edit `rtf.json` and remove `kubernetes` from the `finalizer` array. 3. Run the following commands: ```copy oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json oc get ns ``` 4. Confirm the `rtf` namespace is no longer present. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/configuring-runtime-fabric) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/upgrade-index) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Uninstalling Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Depending on your installation method, you can use the Runtime Fabric command line tool (`rtfctl`) or Helm to uninstall Runtime Fabric. ## Uninstall Runtime Fabric Using RTFCTL To uninstall Runtime Fabric using `rtfctl` commands, follow these steps: 1. Using Runtime Manager, delete all Mule app and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. In Runtime Manager, delete the Runtime Fabric. 4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster. 5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation. 6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster. ## Uninstall Runtime Fabric Using Helm To uninstall Runtime Fabric using Helm: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify on all associated environments that you have removed all applications. 3. Using Runtime Manager, delete the Runtime Fabric. 4. Run the following command: ```copy helm uninstall runtime-fabric -n rtf ``` If need to uninstall due to an error in the installation process, for example, if the install did not complete correctly, run the following command: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` ## Uninstalling Runtime Fabric on Red Hat OpenShift Perform the following procedure to uninstall Runtime Fabric on Red Hat OpenShift: 1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric. 2. Verify that you have removed all applications from all associated environments. 3. Using Runtime Manager, delete the Runtime Fabric. 4. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 5. Select the Runtime Fabric operator. 6. Click **Uninstall**. 7. Using the following Helm command, uninstall Runtime Fabric from the cluster: ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` 8. Delete the `rtf` namespace from the cluster: ```copy oc delete ns rtf ``` ### Troubleshooting Deletion of the rtf Namespace If the command to delete the `rtf` namespace does not work, complete the following steps: 1. Run the following command: ```copy oc get ns rtf -o json > rtf.json ``` 2. Edit `rtf.json` and remove `kubernetes` from the `finalizer` array. 3. Run the following commands: ```copy oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json oc get ns ``` 4. Confirm the `rtf` namespace is no longer present. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/configuring-runtime-fabric) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-index) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Update rtfd Container Resources When Upgrading Runtime Fabric on Red Hat OpenShift > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before upgrading Runtime Fabric on Red Hat OpenShift from version 2.6.52 or earlier to version 2.7.0 or later, you must manually set the `rtfd` container resource allocations to the recommended values. This step is required because the upgrade process doesn’t automatically apply resource changes to the `rtfd` container. For additional guidance on sizing, see [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/latest/rtf-scale). To update `rtfd` container resources: 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. Select the **Runtime Fabric** operator and open the Runtime Fabric instance `.yaml` file. ![Runtime Fabric instance .yaml file.](/mulesoft/current/en-us/runtime-fabric/latest/_images/runtime-fabric-yaml.png) 3. In the `.yaml` file, go to `spec:` > `agent:` > `rtfd:`, and update the resource allocations to these recommended values: ```yaml rtfd: resources: limits: cpu: 200m memory: 300Mi requests: cpu: 150m memory: 200Mi ``` 4. Click **Save**. > [!NOTE] During a Helm-based upgrade, if you previously overrode `rtfd` container resources in the > `values.yaml` file, manually increase the allocations according to the scalability guidelines. > This manual step is required because upgrades respect pre-release overrides. ## See Also - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-index) --- product: Runtime Fabric version: 2.7 --- # Upgrade Pre-requisites > For the full documentation index, see: https://docs.mulesoft.com/llms.txt For all OpenShift upgrades from versions 2.6.52 and earlier to versions 2.7.0 and later, you must manually increase the `rtfd` container resources to the desired values. See [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/latest/rtf-scale) for guidance on `rtfd` container resource values. To update `rtfd` container resources: 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. Select the **Runtime Fabric** operator and open the Runtime Fabric instance `.yaml` file. ![Runtime Fabric instance .yaml file.](/mulesoft/current/en-us/runtime-fabric/2.7/_images/runtime-fabric-yaml.png) 3. In the `.yaml` file, go to `spec:` > `agent:` > `rtfd:`, and update the resource allocations to recommended values. ![Update rtfd resource allocations to recommended values.](/mulesoft/current/en-us/runtime-fabric/2.7/_images/rtfd-change-values.png) 4. Click **Save**. > [!NOTE] For Helm-based upgrades, if the Helm-based installations had previously overridden `rtfd` > container resources in the `values.yaml` file, then you must manually increase the allocations as > per scalability guidelines, as Helm-based upgrades respect pre-release manual overrides. --- product: Runtime Fabric version: 2.10 --- # Upgrading Pre-requisites > For the full documentation index, see: https://docs.mulesoft.com/llms.txt For all OpenShift upgrades from versions 2.6.52 and earlier to versions 2.7.0 and later, you must manually increase the `rtfd` container resources to the desired values. See [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/latest/rtf-scale) for guidance on `rtfd` container resource values. To update `rtfd` container resources: 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. Select the **Runtime Fabric** operator and open the Runtime Fabric instance `.yaml` file. ![Runtime Fabric instance .yaml file.](/mulesoft/current/en-us/runtime-fabric/2.10/_images/runtime-fabric-yaml.png) 3. In the `.yaml` file, go to `spec:` > `agent:` > `rtfd:`, and update the resource allocations to recommended values. ![Update rtfd resource allocations to recommended values.](/mulesoft/current/en-us/runtime-fabric/2.10/_images/rtfd-change-values.png) 4. Click **Save**. > [!NOTE] For Helm-based upgrades, if the Helm-based installations had previously overridden `rtfd` > container resources in the `values.yaml` file, then you must manually increase the allocations as > per scalability guidelines, as Helm-based upgrades respect pre-release manual overrides. --- product: Runtime Fabric version: 2.11 --- # Upgrading Pre-requisites > For the full documentation index, see: https://docs.mulesoft.com/llms.txt For all OpenShift upgrades from versions 2.6.52 and earlier to versions 2.7.0 and later, you must manually increase the `rtfd` container resources to the desired values. See [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/latest/rtf-scale) for guidance on `rtfd` container resource values. To update `rtfd` container resources: 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. Select the **Runtime Fabric** operator and open the Runtime Fabric instance `.yaml` file. ![Runtime Fabric instance .yaml file.](/mulesoft/current/en-us/runtime-fabric/2.11/_images/runtime-fabric-yaml.png) 3. In the `.yaml` file, go to `spec:` > `agent:` > `rtfd:`, and update the resource allocations to recommended values. ![Update rtfd resource allocations to recommended values.](/mulesoft/current/en-us/runtime-fabric/2.11/_images/rtfd-change-values.png) 4. Click **Save**. > [!NOTE] For Helm-based upgrades, if the Helm-based installations had previously overridden `rtfd` > container resources in the `values.yaml` file, then you must manually increase the allocations as > per scalability guidelines, as Helm-based upgrades respect pre-release manual overrides. --- product: Runtime Fabric version: 2.8 --- # Upgrading Pre-requisites > For the full documentation index, see: https://docs.mulesoft.com/llms.txt For all OpenShift upgrades from versions 2.6.52 and earlier to versions 2.7.0 and later, you must manually increase the `rtfd` container resources to the desired values. See [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/latest/rtf-scale) for guidance on `rtfd` container resource values. To update `rtfd` container resources: 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. Select the **Runtime Fabric** operator and open the Runtime Fabric instance `.yaml` file. ![Runtime Fabric instance .yaml file.](/mulesoft/current/en-us/runtime-fabric/2.8/_images/runtime-fabric-yaml.png) 3. In the `.yaml` file, go to `spec:` > `agent:` > `rtfd:`, and update the resource allocations to recommended values. ![Update rtfd resource allocations to recommended values.](/mulesoft/current/en-us/runtime-fabric/2.8/_images/rtfd-change-values.png) 4. Click **Save**. > [!NOTE] For Helm-based upgrades, if the Helm-based installations had previously overridden `rtfd` > container resources in the `values.yaml` file, then you must manually increase the allocations as > per scalability guidelines, as Helm-based upgrades respect pre-release manual overrides. --- product: Runtime Fabric version: 2.9 --- # Upgrading Pre-requisites > For the full documentation index, see: https://docs.mulesoft.com/llms.txt For all OpenShift upgrades from versions 2.6.52 and earlier to versions 2.7.0 and later, you must manually increase the `rtfd` container resources to the desired values. See [Scalability Benchmarks](https://docs.mulesoft.com/runtime-fabric/latest/rtf-scale) for guidance on `rtfd` container resource values. To update `rtfd` container resources: 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. Select the **Runtime Fabric** operator and open the Runtime Fabric instance `.yaml` file. ![Runtime Fabric instance .yaml file.](/mulesoft/current/en-us/runtime-fabric/2.9/_images/runtime-fabric-yaml.png) 3. In the `.yaml` file, go to `spec:` > `agent:` > `rtfd:`, and update the resource allocations to recommended values. ![Update rtfd resource allocations to recommended values.](/mulesoft/current/en-us/runtime-fabric/2.9/_images/rtfd-change-values.png) 4. Click **Save**. > [!NOTE] For Helm-based upgrades, if the Helm-based installations had previously overridden `rtfd` > container resources in the `values.yaml` file, then you must manually increase the allocations as > per scalability guidelines, as Helm-based upgrades respect pre-release manual overrides. --- product: Runtime Fabric version: 2.10 --- # Upgrading Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To upgrade Anypoint Runtime Fabric, review one of the following options: - [Upgrading Runtime Fabric using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.10/upgrade-self-managed) Use the `rtfctl` command line tool to upgrade Runtime Fabric. - [Upgrading Runtime Fabric using Helm](https://docs.mulesoft.com/runtime-fabric/2.10/upgrade-helm) Use Helm package manager to upgrade Runtime Fabric. - [Upgrading Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.10/upgrade-openshift) Use the Red Hat OpenShift console to upgrade Runtime Fabric on Red Hat OpenShift. - [Upgrading Pre-requisites](https://docs.mulesoft.com/runtime-fabric/2.10/upgrade-pre-requisites) Update the `rtfd` container values. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/uninstall-self) --- product: Runtime Fabric version: 2.11 --- # Upgrading Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To upgrade Anypoint Runtime Fabric, review one of these options: - [Upgrading Runtime Fabric using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.11/upgrade-self-managed) Use the `rtfctl` command line tool to upgrade Runtime Fabric. - [Upgrading Runtime Fabric using Helm](https://docs.mulesoft.com/runtime-fabric/2.11/upgrade-helm) Use Helm package manager to upgrade Runtime Fabric. - [Upgrading Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.11/upgrade-openshift) Use the Red Hat OpenShift console to upgrade Runtime Fabric on Red Hat OpenShift. - [Upgrading Pre-requisites](https://docs.mulesoft.com/runtime-fabric/2.11/upgrade-pre-requisites) Update the `rtfd` container values. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/uninstall-self) --- product: Runtime Fabric version: 2.5 --- # Upgrading Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To upgrade Runtime Fabric, choose from one of the following options: - [Upgrade Runtime Fabric using rtfctl](https://docs.mulesoft.com/runtime-fabric/2.5/upgrade-self-managed) - [Upgrade Runtime Fabric using Helm](https://docs.mulesoft.com/runtime-fabric/2.5/upgrade-helm) - [Upgrade Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.5/upgrade-openshift) --- product: Runtime Fabric version: 2.6 --- # Upgrading Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To upgrade Anypoint Runtime Fabric, review one of the following options: - [Upgrading Runtime Fabric using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.6/upgrade-self-managed) Use the `rtfctl` command line tool to upgrade Runtime Fabric. - [Upgrading Runtime Fabric using Helm](https://docs.mulesoft.com/runtime-fabric/2.6/upgrade-helm) Use Helm package manager to upgrade Runtime Fabric. - [Upgrading Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.6/upgrade-openshift) Use the Red Hat OpenShift console to upgrade Runtime Fabric on Red Hat OpenShift. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/uninstall-self) --- product: Runtime Fabric version: 2.7 --- # Upgrading Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To upgrade Anypoint Runtime Fabric, review one of the following options: - [Upgrading Runtime Fabric using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.7/upgrade-self-managed) Use the `rtfctl` command line tool to upgrade Runtime Fabric. - [Upgrading Runtime Fabric using Helm](https://docs.mulesoft.com/runtime-fabric/2.7/upgrade-helm) Use Helm package manager to upgrade Runtime Fabric. - [Upgrading Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.7/upgrade-openshift) Use the Red Hat OpenShift console to upgrade Runtime Fabric on Red Hat OpenShift. - [Upgrade Pre-requisites](https://docs.mulesoft.com/runtime-fabric/2.7/upgrade-pre-requisites) Update the `rtfd` container values. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/uninstall-self) --- product: Runtime Fabric version: 2.8 --- # Upgrading Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To upgrade Anypoint Runtime Fabric, review one of the following options: - [Upgrading Runtime Fabric using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.8/upgrade-self-managed) Use the `rtfctl` command line tool to upgrade Runtime Fabric. - [Upgrading Runtime Fabric using Helm](https://docs.mulesoft.com/runtime-fabric/2.8/upgrade-helm) Use Helm package manager to upgrade Runtime Fabric. - [Upgrading Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.8/upgrade-openshift) Use the Red Hat OpenShift console to upgrade Runtime Fabric on Red Hat OpenShift. - [Upgrading Pre-requisites](https://docs.mulesoft.com/runtime-fabric/2.8/upgrade-pre-requisites) Update the `rtfd` container values. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/uninstall-self) --- product: Runtime Fabric version: 2.9 --- # Upgrading Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To upgrade Anypoint Runtime Fabric, review one of the following options: - [Upgrading Runtime Fabric using RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.9/upgrade-self-managed) Use the `rtfctl` command line tool to upgrade Runtime Fabric. - [Upgrading Runtime Fabric using Helm](https://docs.mulesoft.com/runtime-fabric/2.9/upgrade-helm) Use Helm package manager to upgrade Runtime Fabric. - [Upgrading Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/2.9/upgrade-openshift) Use the Red Hat OpenShift console to upgrade Runtime Fabric on Red Hat OpenShift. - [Upgrading Pre-requisites](https://docs.mulesoft.com/runtime-fabric/2.9/upgrade-pre-requisites) Update the `rtfd` container values. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/uninstall-self) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Upgrading Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To upgrade Anypoint Runtime Fabric, review one of the following options: - [Upgrading Runtime Fabric using RTFCTL](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-self-managed) Use the `rtfctl` command line tool to upgrade Runtime Fabric. - [Upgrading Runtime Fabric using Helm](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-helm) Use Helm package manager to upgrade Runtime Fabric. - [Upgrading Runtime Fabric as a Kubernetes (K8s) Operator](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-openshift) Use the Red Hat OpenShift console to upgrade Runtime Fabric on Red Hat OpenShift. - [Update rtfd Container Resources When Upgrading Runtime Fabric on Red Hat OpenShift](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-pre-requisites) Manually update `rtfd` container resource allocations when upgrading from version 2.6.52 or earlier to version 2.7.0 or later. ## See Also - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-index) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/configuring-runtime-fabric) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/uninstall-self) --- product: Runtime Fabric version: 2.10 --- # Upgrading Runtime Fabric on Red Hat OpenShift > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Red Hat OpenShift console allows you to run upgrades automatically (default) or manually. You can change this setting in the **Subscription** tab in the Runtime Fabric Operator. Starting with Runtime Fabric agent version 2.4.0, for any new Mule app deployment, you must use a Mule runtime image built on Aug 8, 2023, or later. ## Upgrade Runtime Fabric on Red Hat OpenShift To upgrade Runtime Fabric on Red Hat OpenShift, use the Runtime Fabric operator in the Red Hat OpenShift console. 1. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 2. Select the Runtime Fabric operator. 3. Click **Upgrade**. ## Upgrade to an Intermediate Runtime Fabric on Red Hat OpenShift To upgrade to an intermediate Runtime Fabric OpenShift operator, you need to uninstall the previous version and install the intermediate version: 1. From the OpenShift console, uninstall the Runtime Fabric operator, without deleting or uninstalling Runtime Fabric instances or clusters. 2. On the OpenShift console find the Runtime Fabric operator in the Operator Hub and install the desired version. This automatically triggers the upgrade of the existing Runtime Fabric instances. ## See Also - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/upgrade-index) --- product: Runtime Fabric version: 2.11 --- # Upgrading Runtime Fabric on Red Hat OpenShift > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Red Hat OpenShift console allows you to run upgrades automatically (default) or manually. You can change this setting in the **Subscription** tab in the Runtime Fabric Operator. Starting with Runtime Fabric agent version 2.4.0, for any new Mule app deployment, you must use a Mule runtime image built on Aug 8, 2023, or later. ## Upgrade Runtime Fabric on Red Hat OpenShift To upgrade Runtime Fabric on Red Hat OpenShift, use the Runtime Fabric operator in the Red Hat OpenShift console. 1. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 2. Select the Runtime Fabric operator. 3. Click **Upgrade**. ## Upgrade to an Intermediate Runtime Fabric on Red Hat OpenShift To upgrade to an intermediate Runtime Fabric OpenShift operator, you need to uninstall the previous version and install the intermediate version: 1. From the OpenShift console, uninstall the Runtime Fabric operator, without deleting or uninstalling Runtime Fabric instances or clusters. 2. On the OpenShift console find the Runtime Fabric operator in the Operator Hub and install the desired version. This automatically triggers the upgrade of the existing Runtime Fabric instances. ## See Also - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/upgrade-index) --- product: Runtime Fabric version: 2.5 --- # Upgrading Runtime Fabric on Red Hat OpenShift > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Red Hat OpenShift console allows you to run upgrades automatically (default) or manually. You can change this setting in the **Subscription** tab in the Runtime Fabric Operator. Starting with Runtime Fabric agent version 2.4.0, for any new Mule app deployment, you must use a Mule runtime image built on Aug 8, 2023, or later. To upgrade Runtime Fabric on Red Hat OpenShift, use the Runtime Fabric operator in the Red Hat OpenShift console. 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. Select the Runtime Fabric operator. 3. Click **Upgrade**. --- product: Runtime Fabric version: 2.6 --- # Upgrading Runtime Fabric on Red Hat OpenShift > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Red Hat OpenShift console allows you to run upgrades automatically (default) or manually. You can change this setting in the **Subscription** tab in the Runtime Fabric Operator. Starting with Runtime Fabric agent version 2.4.0, for any new Mule app deployment, you must use a Mule runtime image built on Aug 8, 2023, or later. To upgrade Runtime Fabric on Red Hat OpenShift, use the Runtime Fabric operator in the Red Hat OpenShift console. 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. Select the Runtime Fabric operator. 3. Click **Upgrade**. --- product: Runtime Fabric version: 2.7 --- # Upgrading Runtime Fabric on Red Hat OpenShift > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Red Hat OpenShift console allows you to run upgrades automatically (default) or manually. You can change this setting in the **Subscription** tab in the Runtime Fabric Operator. Starting with Runtime Fabric agent version 2.4.0, for any new Mule app deployment, you must use a Mule runtime image built on Aug 8, 2023, or later. To upgrade Runtime Fabric on Red Hat OpenShift, use the Runtime Fabric operator in the Red Hat OpenShift console. 1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**. 2. Select the Runtime Fabric operator. 3. Click **Upgrade**. --- product: Runtime Fabric version: 2.8 --- # Upgrading Runtime Fabric on Red Hat OpenShift > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Red Hat OpenShift console allows you to run upgrades automatically (default) or manually. You can change this setting in the **Subscription** tab in the Runtime Fabric Operator. Starting with Runtime Fabric agent version 2.4.0, for any new Mule app deployment, you must use a Mule runtime image built on Aug 8, 2023, or later. ## Upgrade Runtime Fabric on Red Hat OpenShift To upgrade Runtime Fabric on Red Hat OpenShift, use the Runtime Fabric operator in the Red Hat OpenShift console. 1. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 2. Select the Runtime Fabric operator. 3. Click **Upgrade**. ## Upgrade to an Intermediate Runtime Fabric on Red Hat OpenShift To upgrade to an intermediate Runtime Fabric OpenShift operator, you need to uninstall the previous version and install the intermediate version: 1. From the OpenShift console, uninstall the Runtime Fabric operator, without deleting or uninstalling Runtime Fabric instances or clusters. 2. On the OpenShift console find the Runtime Fabric operator in the Operator Hub and install the desired version. This automatically triggers the upgrade of the existing Runtime Fabric instances. ## See Also - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/upgrade-index) --- product: Runtime Fabric version: 2.9 --- # Upgrading Runtime Fabric on Red Hat OpenShift > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Red Hat OpenShift console allows you to run upgrades automatically (default) or manually. You can change this setting in the **Subscription** tab in the Runtime Fabric Operator. Starting with Runtime Fabric agent version 2.4.0, for any new Mule app deployment, you must use a Mule runtime image built on Aug 8, 2023, or later. ## Upgrade Runtime Fabric on Red Hat OpenShift To upgrade Runtime Fabric on Red Hat OpenShift, use the Runtime Fabric operator in the Red Hat OpenShift console. 1. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 2. Select the Runtime Fabric operator. 3. Click **Upgrade**. ## Upgrade to an Intermediate Runtime Fabric on Red Hat OpenShift To upgrade to an intermediate Runtime Fabric OpenShift operator, you need to uninstall the previous version and install the intermediate version: 1. From the OpenShift console, uninstall the Runtime Fabric operator, without deleting or uninstalling Runtime Fabric instances or clusters. 2. On the OpenShift console find the Runtime Fabric operator in the Operator Hub and install the desired version. This automatically triggers the upgrade of the existing Runtime Fabric instances. ## See Also - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/upgrade-index) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Upgrading Runtime Fabric on Red Hat OpenShift > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Red Hat OpenShift console allows you to run upgrades automatically (default) or manually. You can change this setting in the **Subscription** tab in the Runtime Fabric Operator. Starting with Runtime Fabric agent version 2.4.0, for any new Mule app deployment, you must use a Mule runtime image built on Aug 8, 2023, or later. ## Upgrade Runtime Fabric on Red Hat OpenShift To upgrade Runtime Fabric on Red Hat OpenShift, use the Runtime Fabric operator in the Red Hat OpenShift console. 1. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**. 2. Select the Runtime Fabric operator. 3. Click **Upgrade**. ## Upgrade to an Intermediate Runtime Fabric on Red Hat OpenShift To upgrade to an intermediate Runtime Fabric OpenShift operator, you need to uninstall the previous version and install the intermediate version: 1. From the OpenShift console, uninstall the Runtime Fabric operator, without deleting or uninstalling Runtime Fabric instances or clusters. 2. On the OpenShift console find the Runtime Fabric operator in the Operator Hub and install the desired version. This automatically triggers the upgrade of the existing Runtime Fabric instances. ## See Also - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-index) --- product: Runtime Fabric version: 2.10 --- # Upgrading Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), or Google Kubernetes Engine (GKE) installation that you manage. Helm upgrades are not available for existing installations that used the `rtfctl` command line tool. When you upgrade Runtime Fabric using Helm, Runtime Manager provides the Helm command you need to run the upgrade. > [!IMPORTANT] The upgrade command supplied by Runtime Manager uses the same parameters and values > you added to the Helm command when you installed Runtime Fabric. If you changed any values after > install, such as proxy values, and want to keep those values after the upgrade, you need to add > them to the upgrade command before you run the upgrade. To upgrade Runtime Fabric Using Helm: 1. In Runtime Manager, navigate to your Runtime Fabric by selecting it on the Runtime Fabrics tab. 2. Click **Upgrade…**. 3. Run the command supplied by Runtime Manager to generate a `values.yml` file based on your existing installation. 4. Follow the prompts to generate and download the `values.yml` file. 5. In `values.yml` file, add any optional parameters needed. Refer to the [`values.yml` Reference](https://docs.mulesoft.com/runtime-fabric/2.10/install-helm#values-yml-reference) in the installation documentation for a list of optional and required parameters. 6. Update your Helm repo to ensure you have the latest Runtime Fabric agent chart: ```copy helm repo update ``` 7. To complete the upgrade, run the following command: ```copy helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` --- product: Runtime Fabric version: 2.11 --- # Upgrading Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), or Google Kubernetes Engine (GKE) installation that you manage. Helm upgrades are not available for existing installations that used the `rtfctl` command line tool. When you upgrade Runtime Fabric using Helm, Runtime Manager provides the Helm command you need to run the upgrade. > [!IMPORTANT] The upgrade command supplied by Runtime Manager uses the same parameters and values > you added to the Helm command when you installed Runtime Fabric. If you changed any values after > install, such as proxy values, and want to keep those values after the upgrade, you need to add > them to the upgrade command before you run the upgrade. To upgrade Runtime Fabric Using Helm: 1. In Runtime Manager, navigate to your Runtime Fabric by selecting it on the Runtime Fabrics tab. 2. Click **Upgrade…**. 3. Run the command supplied by Runtime Manager to generate a `values.yml` file based on your existing installation. 4. Follow the prompts to generate and download the `values.yml` file. 5. In `values.yml` file, add any optional parameters needed. Refer to the [`values.yml` Reference](https://docs.mulesoft.com/runtime-fabric/2.11/install-helm#values-yml-reference) in the installation documentation for a list of optional and required parameters. 6. Update your Helm repo to ensure you have the latest Runtime Fabric agent chart: ```copy helm repo update ``` 7. To complete the upgrade, run this command: ```copy helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` --- product: Runtime Fabric version: 2.5 --- # Upgrading Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), or Google Kubernetes Engine (GKE) installation that you manage. Helm upgrades are not available for existing installations that used the `rtfctl` command line tool. When you upgrade Runtime Fabric using Helm, Runtime Manager provides the Helm command you need to run the upgrade. > [!IMPORTANT] The upgrade command supplied by Runtime Manager uses the same parameters and values > you added to the Helm command when you installed Runtime Fabric. If you changed any values after > install, such as proxy values, and want to keep those values after the upgrade, you need to add > them to the upgrade command before you run the upgrade. To upgrade Runtime Fabric Using Helm: 1. In Runtime Manager, navigate to your Runtime Fabric by selecting it on the Runtime Fabrics tab. 2. Click **Upgrade…**. 3. Run the command supplied by Runtime Manager to generate a `values.yml` file based on your existing installation. 4. Follow the prompts to generate and download the `values.yml` file. 5. In `values.yml` file, add any optional parameters needed. Refer to the [`values.yml` Reference](https://docs.mulesoft.com/runtime-fabric/2.5/install-helm#values-yml-reference) in the installation documentation for a list of optional and required parameters. 6. Update your Helm repo to ensure you have the latest Runtime Fabric agent chart: ```copy helm repo update ``` 7. To complete the upgrade, run the following command: ```copy helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` --- product: Runtime Fabric version: 2.6 --- # Upgrading Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), or Google Kubernetes Engine (GKE) installation that you manage. Helm upgrades are not available for existing installations that used the `rtfctl` command line tool. When you upgrade Runtime Fabric using Helm, Runtime Manager provides the Helm command you need to run the upgrade. > [!IMPORTANT] The upgrade command supplied by Runtime Manager uses the same parameters and values > you added to the Helm command when you installed Runtime Fabric. If you changed any values after > install, such as proxy values, and want to keep those values after the upgrade, you need to add > them to the upgrade command before you run the upgrade. To upgrade Runtime Fabric Using Helm: 1. In Runtime Manager, navigate to your Runtime Fabric by selecting it on the Runtime Fabrics tab. 2. Click **Upgrade…**. 3. Run the command supplied by Runtime Manager to generate a `values.yml` file based on your existing installation. 4. Follow the prompts to generate and download the `values.yml` file. 5. In `values.yml` file, add any optional parameters needed. Refer to the [`values.yml` Reference](https://docs.mulesoft.com/runtime-fabric/2.6/install-helm#values-yml-reference) in the installation documentation for a list of optional and required parameters. 6. Update your Helm repo to ensure you have the latest Runtime Fabric agent chart: ```copy helm repo update ``` 7. To complete the upgrade, run the following command: ```copy helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` --- product: Runtime Fabric version: 2.7 --- # Upgrading Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), or Google Kubernetes Engine (GKE) installation that you manage. Helm upgrades are not available for existing installations that used the `rtfctl` command line tool. When you upgrade Runtime Fabric using Helm, Runtime Manager provides the Helm command you need to run the upgrade. > [!IMPORTANT] The upgrade command supplied by Runtime Manager uses the same parameters and values > you added to the Helm command when you installed Runtime Fabric. If you changed any values after > install, such as proxy values, and want to keep those values after the upgrade, you need to add > them to the upgrade command before you run the upgrade. To upgrade Runtime Fabric Using Helm: 1. In Runtime Manager, navigate to your Runtime Fabric by selecting it on the Runtime Fabrics tab. 2. Click **Upgrade…**. 3. Run the command supplied by Runtime Manager to generate a `values.yml` file based on your existing installation. 4. Follow the prompts to generate and download the `values.yml` file. 5. In `values.yml` file, add any optional parameters needed. Refer to the [`values.yml` Reference](https://docs.mulesoft.com/runtime-fabric/2.7/install-helm#values-yml-reference) in the installation documentation for a list of optional and required parameters. 6. Update your Helm repo to ensure you have the latest Runtime Fabric agent chart: ```copy helm repo update ``` 7. To complete the upgrade, run the following command: ```copy helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` --- product: Runtime Fabric version: 2.8 --- # Upgrading Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), or Google Kubernetes Engine (GKE) installation that you manage. Helm upgrades are not available for existing installations that used the `rtfctl` command line tool. When you upgrade Runtime Fabric using Helm, Runtime Manager provides the Helm command you need to run the upgrade. > [!IMPORTANT] The upgrade command supplied by Runtime Manager uses the same parameters and values > you added to the Helm command when you installed Runtime Fabric. If you changed any values after > install, such as proxy values, and want to keep those values after the upgrade, you need to add > them to the upgrade command before you run the upgrade. To upgrade Runtime Fabric Using Helm: 1. In Runtime Manager, navigate to your Runtime Fabric by selecting it on the Runtime Fabrics tab. 2. Click **Upgrade…**. 3. Run the command supplied by Runtime Manager to generate a `values.yml` file based on your existing installation. 4. Follow the prompts to generate and download the `values.yml` file. 5. In `values.yml` file, add any optional parameters needed. Refer to the [`values.yml` Reference](https://docs.mulesoft.com/runtime-fabric/2.8/install-helm#values-yml-reference) in the installation documentation for a list of optional and required parameters. 6. Update your Helm repo to ensure you have the latest Runtime Fabric agent chart: ```copy helm repo update ``` 7. To complete the upgrade, run the following command: ```copy helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` --- product: Runtime Fabric version: 2.9 --- # Upgrading Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), or Google Kubernetes Engine (GKE) installation that you manage. Helm upgrades are not available for existing installations that used the `rtfctl` command line tool. When you upgrade Runtime Fabric using Helm, Runtime Manager provides the Helm command you need to run the upgrade. > [!IMPORTANT] The upgrade command supplied by Runtime Manager uses the same parameters and values > you added to the Helm command when you installed Runtime Fabric. If you changed any values after > install, such as proxy values, and want to keep those values after the upgrade, you need to add > them to the upgrade command before you run the upgrade. To upgrade Runtime Fabric Using Helm: 1. In Runtime Manager, navigate to your Runtime Fabric by selecting it on the Runtime Fabrics tab. 2. Click **Upgrade…**. 3. Run the command supplied by Runtime Manager to generate a `values.yml` file based on your existing installation. 4. Follow the prompts to generate and download the `values.yml` file. 5. In `values.yml` file, add any optional parameters needed. Refer to the [`values.yml` Reference](https://docs.mulesoft.com/runtime-fabric/2.9/install-helm#values-yml-reference) in the installation documentation for a list of optional and required parameters. 6. Update your Helm repo to ensure you have the latest Runtime Fabric agent chart: ```copy helm repo update ``` 7. To complete the upgrade, run the following command: ```copy helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Upgrading Runtime Fabric Using Helm > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Helm to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), or Oracle Kubernetes Engine (OKE) installation that you manage. Helm upgrades are not available for existing installations that used the `rtfctl` command line tool. When you upgrade Runtime Fabric using Helm, Runtime Manager provides the Helm command you need to run the upgrade. > [!IMPORTANT] The upgrade command supplied by Runtime Manager uses the same parameters and values > you added to the Helm command when you installed Runtime Fabric. If you changed any values after > install, such as proxy values, and want to keep those values after the upgrade, you need to add > them to the upgrade command before you run the upgrade. To upgrade Runtime Fabric Using Helm: 1. In Runtime Manager, navigate to your Runtime Fabric by selecting it on the Runtime Fabrics tab. 2. Click **Upgrade…**. 3. Run the command supplied by Runtime Manager to generate a `values.yml` file based on your existing installation. 4. Follow the prompts to generate and download the `values.yml` file. 5. In `values.yml` file, add any optional parameters needed. Refer to the [`values.yml` Reference](https://docs.mulesoft.com/runtime-fabric/latest/install-helm#values-yml-reference) in the installation documentation for a list of optional and required parameters. 6. Update your Helm repo to ensure you have the latest Runtime Fabric agent chart: ```copy helm repo update ``` 7. To complete the upgrade, run the following command: ```copy helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` --- product: Runtime Fabric version: 2.5 --- # Upgrading Runtime Fabric Using rtfctl > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS) or Google Kubernetes Engine (GKE). ## About Component Upgrades Upgrading Runtime Fabric components means upgrading services that: - Facilitate communication to the control plane - Provide load balancing - Log and forward metrics When component upgrades are available, you apply the upgrades within Runtime Manager via a button that’s visible when an upgrade is available. Runtime Fabric component upgrades do not require adding a node. ### Determine the Component Versions You Are Using From a local workstation that has a `Kubeconfig` file and can access Kubernetes, or from a support bastion, run the following command: ```copy .rtfctl version ``` The output looks something like this: ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - The `rtfctl` field shows the `rtfctl` command-line utility version. - The `agent` field shows the the Runtime Fabric component version. > [!NOTE] The Runtime Fabric component version that is in use is also displayed in the **Runtime > Fabrics** tab in Runtime Manager. If an upgrade is available, Runtime Manager displays an > **Upgrade to vx.x** message. ## About rtfctl Command-Line Utility Upgrades Use the `rtfctl` command-line utility to manage Runtime Fabric and perform upgrades. Upgrade the `rtfctl` utility from the command line. Always use the most current version of the `rtfctl` command-line utility to ensure you have the latest functionality. ## Apply the Upgrades To upgrade Anypoint Runtime Fabric, you: 1. Upgrade Runtime Fabric Components 2. Upgrade the `rtfctl` command-line utility Before upgrading your production environment, perform these steps on a nonproduction Runtime Fabric instance to verify compatibility with your environment. Plan to upgrade when your team is not deploying new applications or managing existing applications on Runtime Fabric. When your nonproduction upgrade succeeds, perform these steps in your production environment. ### Upgrade Runtime Fabric Components Review the [Anypoint Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) information to learn more about the most recent component versions. 1. Navigate to your Runtime Fabric by selecting it on the **Runtime Fabrics** tab in Runtime Manager. 2. Select **Upgrade to vx.x**. The status of the Runtime Fabric is updated to show that the upgrade procedure is in progress. 3. Wait for the status to transition to **Active**. In most cases, the upgrade takes fewer than 10 minutes. When the status transitions to **Active** and the version of the Runtime Fabric reflects the new version, the component upgrade is complete. If the Runtime Fabric and Runtime Manager connection disconnects during the upgrade, connectivity is restored after the upgrade finishes. After the upgrade, it’s normal for Runtime Fabric to report as “degraded” for a few minutes as it synchronizes with the control plane. This state automatically resolves after approximately five minutes. ### Upgrade the `rtfctl` Command-Line Utility 1. From your terminal, run the following command: ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` binary: ```copy chmod +x rtfctl ``` 3. Alternatively, to update `rtfctl` in place as a user who owns the `rtfctl` binary, run: ```copy `rtfctl update` ``` --- product: Runtime Fabric version: 2.10 --- # Upgrading Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS) or Google Kubernetes Engine (GKE). ## About Component Upgrades Upgrading Runtime Fabric components means upgrading services that: - Facilitate communication to the control plane - Provide load balancing - Log and forward metrics When component upgrades are available, you apply the upgrades within Runtime Manager via a button that’s visible when an upgrade is available. Runtime Fabric component upgrades do not require adding a node. ### Determine the Component Versions You Are Using From a local workstation that has a `Kubeconfig` file and can access Kubernetes, or from a support bastion, run the following command: ```copy .rtfctl version ``` The output looks something like this: ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - The `rtfctl` field shows the `rtfctl` command-line utility version. - The `agent` field shows the Runtime Fabric component version. > [!NOTE] The Runtime Fabric component version that is in use is also displayed in the **Runtime > Fabrics** tab in Runtime Manager. If an upgrade is available, Runtime Manager displays an > **Upgrade to vx.x** message. ## About rtfctl Command-Line Utility Upgrades Use the `rtfctl` command-line utility to manage Runtime Fabric and perform upgrades. Upgrade the `rtfctl` utility from the command line. Always use the most current version of the `rtfctl` command-line utility to ensure you have the latest functionality. ## Apply the Upgrades To upgrade Anypoint Runtime Fabric, you: 1. Upgrade Runtime Fabric Components 2. Upgrade the `rtfctl` command-line utility Before upgrading your production environment, perform these steps on a nonproduction Runtime Fabric instance to verify compatibility with your environment. Plan to upgrade when your team is not deploying new applications or managing existing applications on Runtime Fabric. When your nonproduction upgrade succeeds, perform these steps in your production environment. ### Upgrade Runtime Fabric Components Review the [Anypoint Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) information to learn more about the most recent component versions. 1. Navigate to your Runtime Fabric by selecting it on the **Runtime Fabrics** tab in Runtime Manager. 2. Select **Upgrade to vx.x**. The status of the Runtime Fabric is updated to show that the upgrade procedure is in progress. 3. Wait for the status to transition to **Active**. In most cases, the upgrade takes fewer than 10 minutes. When the status transitions to **Active** and the version of the Runtime Fabric reflects the new version, the component upgrade is complete. If the Runtime Fabric and Runtime Manager connection disconnects during the upgrade, connectivity is restored after the upgrade finishes. After the upgrade, it’s normal for Runtime Fabric to report as “degraded” for a few minutes as it synchronizes with the control plane. This state automatically resolves after approximately five minutes. ### Upgrade the `rtfctl` Command-Line Utility 1. From your terminal, run the following command: ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` binary: ```copy chmod +x rtfctl ``` 3. Alternatively, to update `rtfctl` in place as a user who owns the `rtfctl` binary, run: ```copy `rtfctl update` ``` ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl) --- product: Runtime Fabric version: 2.11 --- # Upgrading Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS) or Google Kubernetes Engine (GKE). ## About Component Upgrades Upgrading Runtime Fabric components means upgrading services that: - Facilitate communication to the control plane - Provide load balancing - Log and forward metrics When component upgrades are available, you apply the upgrades within Runtime Manager via a button that’s visible when an upgrade is available. Runtime Fabric component upgrades do not require adding a node. ### Determine the Component Versions You Are Using From a local workstation that has a `Kubeconfig` file and can access Kubernetes, or from a support bastion, run this command: ```copy .rtfctl version ``` The output looks something like this: ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - The `rtfctl` field shows the `rtfctl` command-line utility version. - The `agent` field shows the Runtime Fabric component version. > [!NOTE] The Runtime Fabric component version that is in use is also displayed in the **Runtime > Fabrics** tab in Runtime Manager. If an upgrade is available, Runtime Manager displays an > **Upgrade to vx.x** message. ## About rtfctl Command-Line Utility Upgrades Use the `rtfctl` command-line utility to manage Runtime Fabric and perform upgrades. Upgrade the `rtfctl` utility from the command line. Always use the most current version of the `rtfctl` command-line utility to ensure you have the latest functionality. ## Apply the Upgrades To upgrade Anypoint Runtime Fabric, you: 1. Upgrade Runtime Fabric Components 2. Upgrade the `rtfctl` command-line utility Before upgrading your production environment, perform these steps on a nonproduction Runtime Fabric instance to verify compatibility with your environment. Plan to upgrade when your team is not deploying new applications or managing existing applications on Runtime Fabric. When your nonproduction upgrade succeeds, perform these steps in your production environment. ### Upgrade Runtime Fabric Components Review the [Anypoint Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) information to learn more about the most recent component versions. 1. Navigate to your Runtime Fabric by selecting it on the **Runtime Fabrics** tab in Runtime Manager. 2. Select **Upgrade to vx.x**. The status of the Runtime Fabric is updated to show that the upgrade procedure is in progress. 3. Wait for the status to transition to **Active**. In most cases, the upgrade takes fewer than 10 minutes. When the status transitions to **Active** and the version of the Runtime Fabric reflects the new version, the component upgrade is complete. If the Runtime Fabric and Runtime Manager connection disconnects during the upgrade, connectivity is restored after the upgrade finishes. After the upgrade, it’s normal for Runtime Fabric to report as “degraded” for a few minutes as it synchronizes with the control plane. This state automatically resolves after approximately five minutes. ### Upgrade the `rtfctl` Command-Line Utility 1. From your terminal, run this command: ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` binary: ```copy chmod +x rtfctl ``` 3. Alternatively, to update `rtfctl` in place as a user who owns the `rtfctl` binary, run: ```copy `rtfctl update` ``` ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl) --- product: Runtime Fabric version: 2.6 --- # Upgrading Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS) or Google Kubernetes Engine (GKE). ## About Component Upgrades Upgrading Runtime Fabric components means upgrading services that: - Facilitate communication to the control plane - Provide load balancing - Log and forward metrics When component upgrades are available, you apply the upgrades within Runtime Manager via a button that’s visible when an upgrade is available. Runtime Fabric component upgrades do not require adding a node. ### Determine the Component Versions You Are Using From a local workstation that has a `Kubeconfig` file and can access Kubernetes, or from a support bastion, run the following command: ```copy .rtfctl version ``` The output looks something like this: ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - The `rtfctl` field shows the `rtfctl` command-line utility version. - The `agent` field shows the the Runtime Fabric component version. > [!NOTE] The Runtime Fabric component version that is in use is also displayed in the **Runtime > Fabrics** tab in Runtime Manager. If an upgrade is available, Runtime Manager displays an > **Upgrade to vx.x** message. ## About rtfctl Command-Line Utility Upgrades Use the `rtfctl` command-line utility to manage Runtime Fabric and perform upgrades. Upgrade the `rtfctl` utility from the command line. Always use the most current version of the `rtfctl` command-line utility to ensure you have the latest functionality. ## Apply the Upgrades To upgrade Anypoint Runtime Fabric, you: 1. Upgrade Runtime Fabric Components 2. Upgrade the `rtfctl` command-line utility Before upgrading your production environment, perform these steps on a nonproduction Runtime Fabric instance to verify compatibility with your environment. Plan to upgrade when your team is not deploying new applications or managing existing applications on Runtime Fabric. When your nonproduction upgrade succeeds, perform these steps in your production environment. ### Upgrade Runtime Fabric Components Review the [Anypoint Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) information to learn more about the most recent component versions. 1. Navigate to your Runtime Fabric by selecting it on the **Runtime Fabrics** tab in Runtime Manager. 2. Select **Upgrade to vx.x**. The status of the Runtime Fabric is updated to show that the upgrade procedure is in progress. 3. Wait for the status to transition to **Active**. In most cases, the upgrade takes fewer than 10 minutes. When the status transitions to **Active** and the version of the Runtime Fabric reflects the new version, the component upgrade is complete. If the Runtime Fabric and Runtime Manager connection disconnects during the upgrade, connectivity is restored after the upgrade finishes. After the upgrade, it’s normal for Runtime Fabric to report as “degraded” for a few minutes as it synchronizes with the control plane. This state automatically resolves after approximately five minutes. ### Upgrade the `rtfctl` Command-Line Utility 1. From your terminal, run the following command: ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` binary: ```copy chmod +x rtfctl ``` 3. Alternatively, to update `rtfctl` in place as a user who owns the `rtfctl` binary, run: ```copy `rtfctl update` ``` --- product: Runtime Fabric version: 2.7 --- # Upgrading Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS) or Google Kubernetes Engine (GKE). ## About Component Upgrades Upgrading Runtime Fabric components means upgrading services that: - Facilitate communication to the control plane - Provide load balancing - Log and forward metrics When component upgrades are available, you apply the upgrades within Runtime Manager via a button that’s visible when an upgrade is available. Runtime Fabric component upgrades do not require adding a node. ### Determine the Component Versions You Are Using From a local workstation that has a `Kubeconfig` file and can access Kubernetes, or from a support bastion, run the following command: ```copy .rtfctl version ``` The output looks something like this: ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - The `rtfctl` field shows the `rtfctl` command-line utility version. - The `agent` field shows the Runtime Fabric component version. > [!NOTE] The Runtime Fabric component version that is in use is also displayed in the **Runtime > Fabrics** tab in Runtime Manager. If an upgrade is available, Runtime Manager displays an > **Upgrade to vx.x** message. ## About rtfctl Command-Line Utility Upgrades Use the `rtfctl` command-line utility to manage Runtime Fabric and perform upgrades. Upgrade the `rtfctl` utility from the command line. Always use the most current version of the `rtfctl` command-line utility to ensure you have the latest functionality. ## Apply the Upgrades To upgrade Anypoint Runtime Fabric, you: 1. Upgrade Runtime Fabric Components 2. Upgrade the `rtfctl` command-line utility Before upgrading your production environment, perform these steps on a nonproduction Runtime Fabric instance to verify compatibility with your environment. Plan to upgrade when your team is not deploying new applications or managing existing applications on Runtime Fabric. When your nonproduction upgrade succeeds, perform these steps in your production environment. ### Upgrade Runtime Fabric Components Review the [Anypoint Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) information to learn more about the most recent component versions. 1. Navigate to your Runtime Fabric by selecting it on the **Runtime Fabrics** tab in Runtime Manager. 2. Select **Upgrade to vx.x**. The status of the Runtime Fabric is updated to show that the upgrade procedure is in progress. 3. Wait for the status to transition to **Active**. In most cases, the upgrade takes fewer than 10 minutes. When the status transitions to **Active** and the version of the Runtime Fabric reflects the new version, the component upgrade is complete. If the Runtime Fabric and Runtime Manager connection disconnects during the upgrade, connectivity is restored after the upgrade finishes. After the upgrade, it’s normal for Runtime Fabric to report as “degraded” for a few minutes as it synchronizes with the control plane. This state automatically resolves after approximately five minutes. ### Upgrade the `rtfctl` Command-Line Utility 1. From your terminal, run the following command: ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` binary: ```copy chmod +x rtfctl ``` 3. Alternatively, to update `rtfctl` in place as a user who owns the `rtfctl` binary, run: ```copy `rtfctl update` ``` --- product: Runtime Fabric version: 2.8 --- # Upgrading Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS) or Google Kubernetes Engine (GKE). ## About Component Upgrades Upgrading Runtime Fabric components means upgrading services that: - Facilitate communication to the control plane - Provide load balancing - Log and forward metrics When component upgrades are available, you apply the upgrades within Runtime Manager via a button that’s visible when an upgrade is available. Runtime Fabric component upgrades do not require adding a node. ### Determine the Component Versions You Are Using From a local workstation that has a `Kubeconfig` file and can access Kubernetes, or from a support bastion, run the following command: ```copy .rtfctl version ``` The output looks something like this: ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - The `rtfctl` field shows the `rtfctl` command-line utility version. - The `agent` field shows the Runtime Fabric component version. > [!NOTE] The Runtime Fabric component version that is in use is also displayed in the **Runtime > Fabrics** tab in Runtime Manager. If an upgrade is available, Runtime Manager displays an > **Upgrade to vx.x** message. ## About rtfctl Command-Line Utility Upgrades Use the `rtfctl` command-line utility to manage Runtime Fabric and perform upgrades. Upgrade the `rtfctl` utility from the command line. Always use the most current version of the `rtfctl` command-line utility to ensure you have the latest functionality. ## Apply the Upgrades To upgrade Anypoint Runtime Fabric, you: 1. Upgrade Runtime Fabric Components 2. Upgrade the `rtfctl` command-line utility Before upgrading your production environment, perform these steps on a nonproduction Runtime Fabric instance to verify compatibility with your environment. Plan to upgrade when your team is not deploying new applications or managing existing applications on Runtime Fabric. When your nonproduction upgrade succeeds, perform these steps in your production environment. ### Upgrade Runtime Fabric Components Review the [Anypoint Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) information to learn more about the most recent component versions. 1. Navigate to your Runtime Fabric by selecting it on the **Runtime Fabrics** tab in Runtime Manager. 2. Select **Upgrade to vx.x**. The status of the Runtime Fabric is updated to show that the upgrade procedure is in progress. 3. Wait for the status to transition to **Active**. In most cases, the upgrade takes fewer than 10 minutes. When the status transitions to **Active** and the version of the Runtime Fabric reflects the new version, the component upgrade is complete. If the Runtime Fabric and Runtime Manager connection disconnects during the upgrade, connectivity is restored after the upgrade finishes. After the upgrade, it’s normal for Runtime Fabric to report as “degraded” for a few minutes as it synchronizes with the control plane. This state automatically resolves after approximately five minutes. ### Upgrade the `rtfctl` Command-Line Utility 1. From your terminal, run the following command: ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` binary: ```copy chmod +x rtfctl ``` 3. Alternatively, to update `rtfctl` in place as a user who owns the `rtfctl` binary, run: ```copy `rtfctl update` ``` --- product: Runtime Fabric version: 2.9 --- # Upgrading Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS) or Google Kubernetes Engine (GKE). ## About Component Upgrades Upgrading Runtime Fabric components means upgrading services that: - Facilitate communication to the control plane - Provide load balancing - Log and forward metrics When component upgrades are available, you apply the upgrades within Runtime Manager via a button that’s visible when an upgrade is available. Runtime Fabric component upgrades do not require adding a node. ### Determine the Component Versions You Are Using From a local workstation that has a `Kubeconfig` file and can access Kubernetes, or from a support bastion, run the following command: ```copy .rtfctl version ``` The output looks something like this: ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - The `rtfctl` field shows the `rtfctl` command-line utility version. - The `agent` field shows the Runtime Fabric component version. > [!NOTE] The Runtime Fabric component version that is in use is also displayed in the **Runtime > Fabrics** tab in Runtime Manager. If an upgrade is available, Runtime Manager displays an > **Upgrade to vx.x** message. ## About rtfctl Command-Line Utility Upgrades Use the `rtfctl` command-line utility to manage Runtime Fabric and perform upgrades. Upgrade the `rtfctl` utility from the command line. Always use the most current version of the `rtfctl` command-line utility to ensure you have the latest functionality. ## Apply the Upgrades To upgrade Anypoint Runtime Fabric, you: 1. Upgrade Runtime Fabric Components 2. Upgrade the `rtfctl` command-line utility Before upgrading your production environment, perform these steps on a nonproduction Runtime Fabric instance to verify compatibility with your environment. Plan to upgrade when your team is not deploying new applications or managing existing applications on Runtime Fabric. When your nonproduction upgrade succeeds, perform these steps in your production environment. ### Upgrade Runtime Fabric Components Review the [Anypoint Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) information to learn more about the most recent component versions. 1. Navigate to your Runtime Fabric by selecting it on the **Runtime Fabrics** tab in Runtime Manager. 2. Select **Upgrade to vx.x**. The status of the Runtime Fabric is updated to show that the upgrade procedure is in progress. 3. Wait for the status to transition to **Active**. In most cases, the upgrade takes fewer than 10 minutes. When the status transitions to **Active** and the version of the Runtime Fabric reflects the new version, the component upgrade is complete. If the Runtime Fabric and Runtime Manager connection disconnects during the upgrade, connectivity is restored after the upgrade finishes. After the upgrade, it’s normal for Runtime Fabric to report as “degraded” for a few minutes as it synchronizes with the control plane. This state automatically resolves after approximately five minutes. ### Upgrade the `rtfctl` Command-Line Utility 1. From your terminal, run the following command: ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` binary: ```copy chmod +x rtfctl ``` 3. Alternatively, to update `rtfctl` in place as a user who owns the `rtfctl` binary, run: ```copy `rtfctl update` ``` ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Upgrading Runtime Fabric Using RTFCTL > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use the Runtime Fabric command line tool, `rtfctl`, to upgrade Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), or Oracle Kubernetes Engine (OKE). ## About Component Upgrades Upgrading Runtime Fabric components means upgrading services that: - Facilitate communication to the control plane - Provide load balancing - Log and forward metrics When component upgrades are available, you apply the upgrades within Runtime Manager via a button that’s visible when an upgrade is available. Runtime Fabric component upgrades do not require adding a node. ### Determine the Component Versions You Are Using From a local workstation that has a `Kubeconfig` file and can access Kubernetes, or from a support bastion, run the following command: ```copy .rtfctl version ``` The output looks something like this: ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - The `rtfctl` field shows the `rtfctl` command-line utility version. - The `agent` field shows the Runtime Fabric component version. > [!NOTE] The Runtime Fabric component version that is in use is also displayed in the **Runtime > Fabrics** tab in Runtime Manager. If an upgrade is available, Runtime Manager displays an > **Upgrade to vx.x** message. ## About rtfctl Command-Line Utility Upgrades Use the `rtfctl` command-line utility to manage Runtime Fabric and perform upgrades. Upgrade the `rtfctl` utility from the command line. Always use the most current version of the `rtfctl` command-line utility to ensure you have the latest functionality. ## Apply the Upgrades To upgrade Anypoint Runtime Fabric, you: 1. Upgrade Runtime Fabric Components 2. Upgrade the `rtfctl` command-line utility Before upgrading your production environment, perform these steps on a nonproduction Runtime Fabric instance to verify compatibility with your environment. Plan to upgrade when your team is not deploying new applications or managing existing applications on Runtime Fabric. When your nonproduction upgrade succeeds, perform these steps in your production environment. ### Upgrade Runtime Fabric Components Review the [Anypoint Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) information to learn more about the most recent component versions. 1. Navigate to your Runtime Fabric by selecting it on the **Runtime Fabrics** tab in Runtime Manager. 2. Select **Upgrade to vx.x**. The status of the Runtime Fabric is updated to show that the upgrade procedure is in progress. 3. Wait for the status to transition to **Active**. In most cases, the upgrade takes fewer than 10 minutes. When the status transitions to **Active** and the version of the Runtime Fabric reflects the new version, the component upgrade is complete. If the Runtime Fabric and Runtime Manager connection disconnects during the upgrade, connectivity is restored after the upgrade finishes. After the upgrade, it’s normal for Runtime Fabric to report as “degraded” for a few minutes as it synchronizes with the control plane. This state automatically resolves after approximately five minutes. ### Upgrade the `rtfctl` Command-Line Utility 1. From your terminal, run the following command: ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. Change file permissions for the `rtfctl` binary: ```copy chmod +x rtfctl ``` 3. Alternatively, to update `rtfctl` in place as a user who owns the `rtfctl` binary, run: ```copy `rtfctl update` ``` ## See Also - [Using RTFCTL Tool Overview](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl) --- product: Runtime Fabric version: 2.10 --- # Using a Local Registry with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric uses its own registry to store the necessary Docker images for installing and managing Runtime Fabric and for running applications in Kubernetes. If your security policies require that you pull your Docker images from a registry under your control, you can set up a local registry to pull and store these Docker images. ## Limitations on Local Registry Support You can configure local registry across all Runtime Fabric supported platform vendors to store Mule Docker images (for use when managing application deployments) and Runtime Fabric software images (for use when updating or installing Runtime Fabric software). The following details and limitations apply to both Mule Docker images and Runtime Fabric software images. > [!IMPORTANT] You cannot use local registry for installation or management of Runtime Fabric > operator on OpenShift. - You can use [Runtime Fabric command line utility (`rtfctl`)](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl) version 0.3.150 or later. `rtfctl` installs Runtime Fabric agent to the latest version by default. - You can use Helm to install Runtime Fabric and configure your local registry. - You can use a local registry only if you create a new Runtime Fabric instance of version 1.12.0 or later. If you set up a local registry, you can upgrade to a version later than 1.12.0 without reinstalling Runtime Fabric. To add local registry to an existing Runtime Fabric instance, ensure that the installation is Helm-based [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/migrate-helm) and perform the steps on the following section to add local registry. - If you create a Runtime Fabric instance to use with a local registry, you cannot later reconfigure it to use the `rtf-runtime-registry` endpoint. To use the `rtf-runtime-registry` endpoint, you must install a new Runtime Fabric instance using the standard installation procedure. - You are responsible for synchronizing your local registry with required dependencies: - [Synchronize Runtime Fabric core software images or dependencies automatically](#synch-rtf) - [Synchronize Mule runtime images or dependencies manually](#synch-runtime) - Synchronize third party dependencies required by your application. MuleSoft doesn’t provide additional software to synchronize third party dependencies and images. Push all the dependency images for your Mule app to your local registry before you start the deployments. - If you use a local registry that needs authentication, synchronization and propagation of a pull secret between different namespaces is your responsibility. Alternatively, Runtime Fabric can synchronize your pull secret across different namespaces if your secret uses the following label: labels: rtf.mulesoft.com/synchronized: "true" - If you need to authenticate access to your local registry, ensure that the [corresponding credentials are configured as a Kubernetes secret in the `rtf` namespace](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials). You’ll need the name of the configured secret when you install Runtime Fabric. ## Synchronize Mule Runtime Dependencies and Images to Your Local Registry To synchronize in your registry the Mule runtime versions you intend to use for application deployments, refer to the [Mule runtime patch updates for Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). The location of the image follows this format: `rtf-runtime-registry.kprod.msap.io/mulesoft/`. ## Synchronize Runtime Fabric Core Software Dependencies and Images to Your Local Registry To install Runtime Fabric, you must first synchronize the dependencies images to your local registry. You can perform the synchronization by either running a script automatically or executing commands manually. - Synchronize Automatically - Synchronize Manually To synchronize the dependencies images automatically, run a bash script that uses the `docker`, `curl`, and `jq` tools. > [!NOTE] Automated registry synchronization is available from Runtime Fabric version 2.6.0 onwards. > Previous dependencies cannot be retrieved using this script. Ensure that your [Access Management permission for Runtime Manager](https://docs.mulesoft.com/access-management/permissions-by-product#runtime-manager) is set to **Read Runtime Fabric**, which enables you to query Runtime Fabrics in your organization. 1. In your Unix shell, run the following script, replacing `agent-version`, `authorization-token`, `mulesoft-docker-server`, and any other parameter value where appropriate: For non-OpenShift environments: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("generic")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ``` For OpenShift environments: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("openshift")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ```
Table 1. Script Parameters
ParametersDescription

platform-url

Anypoint Platform URL, such as https://anypoint.mulesoft.com, or https://eu1.anypoint.mulesoft.com.

agent-version

Runtime Fabric agent release version required for the synchronization.

authorization-token

Authorization token required for using connected apps to perform the synchronization. When you use this token, a link redirects to the connected apps page.

mulesoft-docker-server

MuleSoft Docker server required for the synchronization.
For the US control plane: rtf-runtime-registry.kprod.msap.io
For the EU control plane: rtf-runtime-registry.kprod-eu.msap.io

To synchronize the dependencies images manually, follow these steps: 1. Log in to your private container registry and run the following command, replacing `docker-server` where appropriate: For the US control plane: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the EU control plane: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push :5000/mulesoft/rtf-agent:v1.12.0 ``` ## Configure Your Local Registry for Runtime Fabric To configure a local registry, you must gather and add the necessary credentials to synchronize the registries. ### Before You Begin Ensure that you’ve performed the following tasks: 1. Set up, configure, and test your private Docker image registry. 2. [Synchronize](#synch-rtf) to your local registry all of the Docker images that you need to install Runtime Fabric: See the [Runtime Fabric release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the required dependencies for your Runtime Fabric version. > [!NOTE] Dependency versions are specific to the Runtime Fabric version. To install Runtime Fabric with your local registry using `rtfctl` or `helm`, select one of the following options: - RTFCTL - Helm - OpenShift 1. [Download and install the `rtfctl` command line utility](https://docs.mulesoft.com/runtime-fabric/2.10/install-self-managed#step-3-download-the-rtfctl-utility) version 0.3.150 or higher. 2. Obtain `rtf-runtime-registry` credentials: ```copy # rtfctl get registry-credentials ``` This command sets `RTF_IMAGE_REGISTRY_ENDPOINT`, `RTF_IMAGE_REGISTRY_USER`, and `RTF_IMAGE_REGISTRY_PASSWORD` in the current shell environment. 3. Run the following commands to verify that the Docker login to the `rtf-runtime-registry` succeeds: ```copy # eval $(rtfctl get registry-credentials ) # docker login $RTF_IMAGE_REGISTRY_ENDPOINT --username $RTF_IMAGE_REGISTRY_USER --password $RTF_IMAGE_REGISTRY_PASSWORD ``` You should see a message that the login was successful. 4. [Synchronize your container images](#synch-rtf) to your local registry. 5. Repeat step 3 for all the other dependency images (resourceFetcher, clusterOps etc.) based on the versions published in the Runtime Fabric release notes. 6. If you use authentication to access your registry, create the required secret in the rtf namespace: ```copy # kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf ``` 7. Finalize the Runtime Fabric installation, and configure it to pull from your local registry: ```copy # rtfctl install ‘’ --image-pull-registry ``` Alternatively, if you use authentication to access your registry, use the following command: ```copy # rtfctl install ‘’ --image-pull-registry --image-pull-secret ``` This command ensures that Runtime Fabric creates the necessary overrides for the local registry URL and `image-pull-secret` values so Runtime Fabric continues to pull images from the local registry even after an upgrade. 8. If you use authentication to access your registry, after you complete the installation, you must recreate the pull secret in the RTF namespace and in any other namespaces where you will deploy applications. 9. Refer to the [installation instructions](https://docs.mulesoft.com/runtime-fabric/2.10/install-self-managed) for further steps, such as inserting the Mule license key. The `rtfctl uninstall` command deletes any pull secret you specify during installation. When using `rtfctl` to perform a backup and restore procedure, the backups point to your local registry URL and pull secret. 1. [Synchronize your container images](#synch-rtf) to your local registry. 2. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.10/install-helm#create-a-runtime-fabric-using-runtime-manager). 3. In Runtime Manager, select the **Helm** path, and follow the instructions on the screen platform. 4. Obtain your private `docker-server`, `docker-username`, and `docker-password`. 5. Follow the **Helm** path instructions in Runtime Manager to create a secret with your docker server name, username, and password by running the following command in your Unix shell: ```copy kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 6. Follow the **Helm** path instructions to download the `values.yml` file so that you can modify its values. For the private registry configuration, update `rtfRegistry` with your local docker server, and update the `pullSecretName` parameter. . 7. Continue with the **Helm** path instructions and install Runtime Fabric in your Kubernetes cluster. 8. [Synchronize your container images](#synch-rtf) to your local registry. 9. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.10/install-helm#create-a-runtime-fabric-using-runtime-manager). 10. In Runtime Manager, follow the instructions on the screen platform. 11. Obtain your private `docker-server`, `docker-username`, and `docker-password`. 12. Follow the instructions in Runtime Manager to create a secret with your docker server name, username, and password by running the following command in your Unix shell: ```copy oc create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 13. In the OpenShift form view, set the rtfRegistry values to configure the local registry. ![OpenShift form view to add values for rtfRegistry](/mulesoft/current/en-us/runtime-fabric/2.10/_images/ocp-local-registry.png) 14. Continue with the OpenShift installation. ## See Also - [Configure values.yml Reference](https://docs.mulesoft.com/runtime-fabric/2.10/install-helm#values-yml-reference) --- product: Runtime Fabric version: 2.11 --- # Using a Local Registry with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric uses its own registry to store the necessary Docker images for installing and managing Runtime Fabric and for running applications in Kubernetes. If your security policies require that you pull your Docker images from a registry under your control, you can set up a local registry to pull and store these Docker images. ## Limitations on Local Registry Support You can configure local registry across all Runtime Fabric supported platform vendors to store Mule Docker images (for use when managing application deployments) and Runtime Fabric software images (for use when updating or installing Runtime Fabric software). The following details and limitations apply to both Mule Docker images and Runtime Fabric software images. > [!IMPORTANT] You cannot use local registry for installation or management of Runtime Fabric > operator on OpenShift. - You can use [Runtime Fabric command line utility (`rtfctl`)](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl) version 0.3.150 or later. `rtfctl` installs Runtime Fabric agent to the latest version by default. - You can use Helm to install Runtime Fabric and configure your local registry. - You can use a local registry only if you create a new Runtime Fabric instance of version 1.12.0 or later. If you set up a local registry, you can upgrade to a version later than 1.12.0 without reinstalling Runtime Fabric. To add local registry to an existing Runtime Fabric instance, ensure that the installation is Helm-based [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/migrate-helm) and perform the steps on this section to add local registry. - If you create a Runtime Fabric instance to use with a local registry, you cannot later reconfigure it to use the `rtf-runtime-registry` endpoint. To use the `rtf-runtime-registry` endpoint, you must install a new Runtime Fabric instance using the standard installation procedure. - You are responsible for synchronizing your local registry with required dependencies: - [Synchronize Runtime Fabric core software images or dependencies automatically](#synch-rtf) - [Synchronize Mule runtime images or dependencies manually](#synch-runtime) - Synchronize third party dependencies required by your application. MuleSoft doesn’t provide additional software to synchronize third party dependencies and images. Push all the dependency images for your Mule app to your local registry before you start the deployments. - If you use a local registry that needs authentication, synchronization and propagation of a pull secret between different namespaces is your responsibility. Alternatively, Runtime Fabric can synchronize your pull secret across different namespaces if your secret uses this label: labels: rtf.mulesoft.com/synchronized: "true" - If you need to authenticate access to your local registry, ensure that the [corresponding credentials are configured as a Kubernetes secret in the `rtf` namespace](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials). You’ll need the name of the configured secret when you install Runtime Fabric. ## Synchronize Mule Runtime Dependencies and Images to Your Local Registry To synchronize in your registry the Mule runtime versions you intend to use for application deployments, refer to the [Mule runtime patch updates for Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). The location of the image follows this format: `rtf-runtime-registry.kprod.msap.io/mulesoft/`. ## Synchronize Runtime Fabric Core Software Dependencies and Images to Your Local Registry To install Runtime Fabric, you must first synchronize the dependencies images to your local registry. You can perform the synchronization by either running a script automatically or executing commands manually. - Synchronize Automatically - Synchronize Manually To synchronize the dependencies images automatically, run a bash script that uses the `docker`, `curl`, and `jq` tools. > [!NOTE] Automated registry synchronization is available from Runtime Fabric version 2.6.0 onwards. > Previous dependencies cannot be retrieved using this script. Ensure that your [Access Management permission for Runtime Manager](https://docs.mulesoft.com/access-management/permissions-by-product#runtime-manager) is set to **Read Runtime Fabric**, which enables you to query Runtime Fabrics in your organization. 1. In your Unix shell, run this script, replacing `agent-version`, `authorization-token`, `mulesoft-docker-server`, and any other parameter value where appropriate: For non-OpenShift environments: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("generic")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ``` For OpenShift environments: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("openshift")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ```
Table 1. Script Parameters
ParametersDescription

platform-url

Anypoint Platform URL, such as https://anypoint.mulesoft.com, or https://eu1.anypoint.mulesoft.com.

agent-version

Runtime Fabric agent release version required for the synchronization.

authorization-token

Authorization token required for using connected apps to perform the synchronization. When you use this token, a link redirects to the connected apps page.

mulesoft-docker-server

MuleSoft Docker server required for the synchronization.
For the US control plane: rtf-runtime-registry.kprod.msap.io
For the EU control plane: rtf-runtime-registry.kprod-eu.msap.io

To synchronize the dependencies images manually, follow these steps: 1. Log in to your private container registry and run this command, replacing `docker-server` where appropriate: For the US control plane: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the EU control plane: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push :5000/mulesoft/rtf-agent:v1.12.0 ``` ## Configure Your Local Registry for Runtime Fabric To configure a local registry, you must gather and add the necessary credentials to synchronize the registries. ### Before You Begin Ensure that you’ve performed these tasks: 1. Set up, configure, and test your private Docker image registry. 2. [Synchronize](#synch-rtf) to your local registry all of the Docker images that you need to install Runtime Fabric: See the [Runtime Fabric release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the required dependencies for your Runtime Fabric version. > [!NOTE] Dependency versions are specific to the Runtime Fabric version. To install Runtime Fabric with your local registry using `rtfctl` or `helm`, select one of these options: - RTFCTL - Helm - OpenShift 1. [Download and install the `rtfctl` command line utility](https://docs.mulesoft.com/runtime-fabric/2.11/install-self-managed#step-3-download-the-rtfctl-utility) version 0.3.150 or higher. 2. Obtain `rtf-runtime-registry` credentials: ```copy # rtfctl get registry-credentials ``` This command sets `RTF_IMAGE_REGISTRY_ENDPOINT`, `RTF_IMAGE_REGISTRY_USER`, and `RTF_IMAGE_REGISTRY_PASSWORD` in the current shell environment. 3. Run these commands to verify that the Docker login to the `rtf-runtime-registry` succeeds: ```copy # eval $(rtfctl get registry-credentials ) # docker login $RTF_IMAGE_REGISTRY_ENDPOINT --username $RTF_IMAGE_REGISTRY_USER --password $RTF_IMAGE_REGISTRY_PASSWORD ``` You should see a message that the login was successful. 4. [Synchronize your container images](#synch-rtf) to your local registry. 5. Repeat step 3 for all the other dependency images (resourceFetcher, clusterOps etc.) based on the versions published in the Runtime Fabric release notes. 6. If you use authentication to access your registry, create the required secret in the rtf namespace: ```copy # kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf ``` 7. Finalize the Runtime Fabric installation, and configure it to pull from your local registry: ```copy # rtfctl install ‘’ --image-pull-registry ``` Alternatively, if you use authentication to access your registry, use this command: ```copy # rtfctl install ‘’ --image-pull-registry --image-pull-secret ``` This command ensures that Runtime Fabric creates the necessary overrides for the local registry URL and `image-pull-secret` values so Runtime Fabric continues to pull images from the local registry even after an upgrade. 8. If you use authentication to access your registry, after you complete the installation, you must recreate the pull secret in the RTF namespace and in any other namespaces where you will deploy applications. 9. Refer to the [installation instructions](https://docs.mulesoft.com/runtime-fabric/2.11/install-self-managed) for further steps, such as inserting the Mule license key. The `rtfctl uninstall` command deletes any pull secret you specify during installation. When using `rtfctl` to perform a backup and restore procedure, the backups point to your local registry URL and pull secret. 1. [Synchronize your container images](#synch-rtf) to your local registry. 2. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.11/install-helm#create-a-runtime-fabric-using-runtime-manager). 3. In Runtime Manager, select the **Helm** path, and follow the instructions on the screen platform. 4. Obtain your private `docker-server`, `docker-username`, and `docker-password`. 5. Follow the **Helm** path instructions in Runtime Manager to create a secret with your docker server name, username, and password by running this command in your Unix shell: ```copy kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 6. Follow the **Helm** path instructions to download the `values.yml` file so that you can modify its values. For the private registry configuration, update `rtfRegistry` with your local docker server, and update the `pullSecretName` parameter. . 7. Continue with the **Helm** path instructions and install Runtime Fabric in your Kubernetes cluster. 8. [Synchronize your container images](#synch-rtf) to your local registry. 9. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.11/install-helm#create-a-runtime-fabric-using-runtime-manager). 10. In Runtime Manager, follow the instructions on the screen platform. 11. Obtain your private `docker-server`, `docker-username`, and `docker-password`. 12. Follow the instructions in Runtime Manager to create a secret with your docker server name, username, and password by running this command in your Unix shell: ```copy oc create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 13. In the OpenShift form view, set the rtfRegistry values to configure the local registry. ![OpenShift form view to add values for rtfRegistry](/mulesoft/current/en-us/runtime-fabric/2.11/_images/ocp-local-registry.png) 14. Continue with the OpenShift installation. ## See Also - [Configure values.yml Reference](https://docs.mulesoft.com/runtime-fabric/2.11/install-helm#values-yml-reference) --- product: Runtime Fabric version: 2.5 --- # Using a Local Registry with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric uses its own registry to store the necessary Docker images for installing and managing Runtime Fabric and for running applications in Kubernetes. If your security policies require that you pull your Docker images from a registry under your control, you can set up a local registry to pull and store these Docker images. ## Limitations on Local Registry Support Review the following limitations on support for local registries: > [!IMPORTANT] You cannot use local registries during the installation of OpenShift operator. > However, you can use local registries with OpenShift RTF to store Mule Docker images and install > and manage Runtime Fabric for running Mule apps. - You must use [Runtime Fabric command line utility (`rtfctl`)](https://docs.mulesoft.com/runtime-fabric/2.5/install-rtfctl) version 0.3.150 or later. Note that `rtfctl` installs Runtime Fabric agent to the latest version by default. - You can use a local registry only if you create a new Runtime Fabric instance of version 1.12.0 or later. If you set up a local registry, you can upgrade to a version later than 1.12.0 without reinstalling Runtime Fabric. You cannot add a local registry to any version of an existing Runtime Fabric instance, even if you upgrade that installation to 1.12.0 or later. - If you create a Runtime Fabric instance to use with a local registry, you cannot later reconfigure it to use the `rtf-runtime-registry` endpoint. To use the `rtf-runtime-registry` endpoint, you must install a new Runtime Fabric instance using the standard installation procedure. - You’re responsible for synchronization between your registry and the Runtime Fabric registry. MuleSoft doesn’t provide additional software to synchronize images between the registries. Push all the dependency images for your version to your local registry before you start the installation. See the [Runtime Fabric release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the required dependencies for your Runtime Fabric version. - If you use a local registry that needs authentication, synchronization and propagation of a pull secret between different namespaces is your responsibility. Alternatively, Runtime Fabric can synchronize your pull secret across different namespaces if your secret uses the following label: labels: rtf.mulesoft.com/synchronized: "true" - If you need to authenticate access to your local registry, ensure that the [corresponding credentials are configured as a Kubernetes secret in the `rtf` namespace](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials). You’ll need the name of the configured secret when you install Runtime Fabric. - You also need to synchronize in your registry the Mule runtime versions you intend to use for application deployments. Refer to the [Runtime Fabric Patch Update Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) for information about the latest Mule runtime patch versions. The location of the image will follow this format: `rtf-runtime-registry.kqa.msap.io/mulesoft/poseidon-runtime-4.4.0:`. ## Configure a Local Registry for Use with Runtime Fabric To configure a local registry, you must gather and add the necessary credentials to synchronize the registries. ### Before You Begin Ensure that you’ve performed the following tasks: 1. Set up, configure, and test your private Docker image registry. 2. Synchronize to your local registry all the Docker images you need to install Runtime Fabric: See the [Runtime Fabric release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the required dependencies for your Runtime Fabric version. > [!NOTE] Dependency versions are specific to the Runtime Fabric version. 3. [Download and install the `rtfctl` command line utility](https://docs.mulesoft.com/runtime-fabric/2.5/install-self-managed#step-3-download-the-rtfctl-utility) version 0.3.150 or higher. 4. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.5/install-self-managed#step-3-download-the-rtfctl-utility), and gather the activation data. ### Configure Your Local Registry and Install Runtime Fabric 1. Obtain `rtf-runtime-registry` credentials: ```copy # rtfctl get registry-credentials ``` This command sets `RTF_IMAGE_REGISTRY_ENDPOINT`, `RTF_IMAGE_REGISTRY_USER`, and `RTF_IMAGE_REGISTRY_PASSWORD` in the current shell environment. 2. Run the following commands to verify that the Docker login to the `rtf-runtime-registry` succeeds: ```copy # eval $(rtfctl get registry-credentials ) # docker login $RTF_IMAGE_REGISTRY_ENDPOINT --username $RTF_IMAGE_REGISTRY_USER --password $RTF_IMAGE_REGISTRY_PASSWORD ``` You should see a message that the login was successful. 3. To pull and synchronize images, log in into your own private container registry and run the following command, replacing `` where appropriate: For the US control plane: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the EU control plane: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push :5000/mulesoft/rtf-agent:v1.12.0 ``` 4. Repeat step 3 for all the other dependency images (resourceFetcher, clusterOps etc.) based on the versions published in the Runtime Fabric release notes. 5. If you use authentication to access your registry, create the required secret in the rtf namespace: ```copy # kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf ``` 6. Finalize the Runtime Fabric installation, and configure it to pull from your local registry: ```copy # rtfctl install ‘’ --image-pull-registry ``` Alternatively, if you use authentication to access your registry, use the following command: ```copy # rtfctl install ‘’ --image-pull-registry --image-pull-secret ``` This command ensures that Runtime Fabric creates the necessary overrides for the local registry URL and `image-pull-secret` values so Runtime Fabric continues to pull images from the local registry even after an upgrade. 7. If you use authentication to access your registry, after you complete the installation, you must recreate the pull secret in the RTF namespace and in any other namespaces where you will deploy applications. 8. Refer to the [installation instructions](https://docs.mulesoft.com/runtime-fabric/2.5/install-self-managed) for further steps, such as inserting the Mule license key. The `rtfctl uninstall` command deletes any pull secret you specify during installation. When using `rtfctl` to perform a backup and restore procedure, the backups point to your local registry URL and pull secret. --- product: Runtime Fabric version: 2.6 --- # Using a Local Registry with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric uses its own registry to store the necessary Docker images for installing and managing Runtime Fabric and for running applications in Kubernetes. If your security policies require that you pull your Docker images from a registry under your control, you can set up a local registry to pull and store these Docker images. ## Limitations on Local Registry Support You can configure local registry across all Runtime Fabric supported platform vendors to store Mule Docker images (for use when managing application deployments) and Runtime Fabric software images (for use when updating or installing Runtime Fabric software). The following details and limitations apply to both Mule Docker images and Runtime Fabric software images. > [!IMPORTANT] You cannot use local registry for installation or management of Runtime Fabric > operator on OpenShift. - You can use [Runtime Fabric command line utility (`rtfctl`)](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl) version 0.3.150 or later. `rtfctl` installs Runtime Fabric agent to the latest version by default. - You can use Helm to install Runtime Fabric and configure your local registry. - You can use a local registry only if you create a new Runtime Fabric instance of version 1.12.0 or later. If you set up a local registry, you can upgrade to a version later than 1.12.0 without reinstalling Runtime Fabric. To add local registry to an existing Runtime Fabric instance, ensure that the installation is Helm-based [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/migrate-helm) and perform the steps on the following section to add local registry. - If you create a Runtime Fabric instance to use with a local registry, you cannot later reconfigure it to use the `rtf-runtime-registry` endpoint. To use the `rtf-runtime-registry` endpoint, you must install a new Runtime Fabric instance using the standard installation procedure. - You are responsible for synchronizing your local registry with required dependencies: - [Synchronize Runtime Fabric core software images or dependencies automatically](#synch-rtf) - [Synchronize Mule runtime images or dependencies manually](#synch-runtime) - Synchronize third party dependencies required by your application. MuleSoft doesn’t provide additional software to synchronize third party dependencies and images. Push all the dependency images for your Mule app to your local registry before you start the deployments. - If you use a local registry that needs authentication, synchronization and propagation of a pull secret between different namespaces is your responsibility. Alternatively, Runtime Fabric can synchronize your pull secret across different namespaces if your secret uses the following label: labels: rtf.mulesoft.com/synchronized: "true" - If you need to authenticate access to your local registry, ensure that the [corresponding credentials are configured as a Kubernetes secret in the `rtf` namespace](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials). You’ll need the name of the configured secret when you install Runtime Fabric. ## Synchronize Mule Runtime Dependencies and Images to Your Local Registry To synchronize in your registry the Mule runtime versions you intend to use for application deployments, refer to the [Mule runtime patch updates for Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). The location of the image follows this format: `rtf-runtime-registry.kprod.msap.io/mulesoft/`. ## Synchronize Runtime Fabric Core Software Dependencies and Images to Your Local Registry To install Runtime Fabric, you must first synchronize the dependencies images to your local registry. You can perform the synchronization by either running a script automatically or executing commands manually. - Synchronize Automatically - Synchronize Manually To synchronize the dependencies images automatically, run a bash script that uses the `docker`, `curl`, and `jq` tools. > [!NOTE] Automated registry synchronization is available from Runtime Fabric version 2.6.0 onwards. > Previous dependencies cannot be retrieved using this script. Ensure that your [Access Management permission for Runtime Manager](https://docs.mulesoft.com/access-management/permissions-by-product#runtime-manager) is set to **Read Runtime Fabric**, which enables you to query Runtime Fabrics in your organization. 1. In your Unix shell, run the following script, replacing `agent-version`, `authorization-token`, `mulesoft-docker-server`, and any other parameter value where appropriate: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("generic")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ```
Table 1. Script Parameters
ParametersDescription

platform-url

Anypoint Platform URL, such as https://anypoint.mulesoft.com, or https://eu1.anypoint.mulesoft.com.

agent-version

Runtime Fabric agent release version required for the synchronization.

authorization-token

Authorization token required for using connected apps to perform the synchronization. When you use this token, a link redirects to the connected apps page.

mulesoft-docker-server

MuleSoft Docker server required for the synchronization.
For the US control plane: rtf-runtime-registry.kprod.msap.io
For the EU control plane: rtf-runtime-registry.kprod-eu.msap.io

To synchronize the dependencies images manually, follow these steps: 1. Log in to your private container registry and run the following command, replacing `docker-server` where appropriate: For the US control plane: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the EU control plane: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push :5000/mulesoft/rtf-agent:v1.12.0 ``` ## Configure Your Local Registry for Runtime Fabric To configure a local registry, you must gather and add the necessary credentials to synchronize the registries. ### Before You Begin Ensure that you’ve performed the following tasks: 1. Set up, configure, and test your private Docker image registry. 2. [Synchronize](#synch-rtf) to your local registry all of the Docker images that you need to install Runtime Fabric: See the [Runtime Fabric release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the required dependencies for your Runtime Fabric version. > [!NOTE] Dependency versions are specific to the Runtime Fabric version. To install Runtime Fabric with your local registry using `rtfctl` or `helm`, select one of the following options: - RTFCTL - Helm 1. [Download and install the `rtfctl` command line utility](https://docs.mulesoft.com/runtime-fabric/2.6/install-self-managed#step-3-download-the-rtfctl-utility) version 0.3.150 or higher. 2. Obtain `rtf-runtime-registry` credentials: ```copy # rtfctl get registry-credentials ``` This command sets `RTF_IMAGE_REGISTRY_ENDPOINT`, `RTF_IMAGE_REGISTRY_USER`, and `RTF_IMAGE_REGISTRY_PASSWORD` in the current shell environment. 3. Run the following commands to verify that the Docker login to the `rtf-runtime-registry` succeeds: ```copy # eval $(rtfctl get registry-credentials ) # docker login $RTF_IMAGE_REGISTRY_ENDPOINT --username $RTF_IMAGE_REGISTRY_USER --password $RTF_IMAGE_REGISTRY_PASSWORD ``` You should see a message that the login was successful. 4. [Synchronize your container images](#synch-rtf) to your local registry. 5. Repeat step 3 for all the other dependency images (resourceFetcher, clusterOps etc.) based on the versions published in the Runtime Fabric release notes. 6. If you use authentication to access your registry, create the required secret in the rtf namespace: ```copy # kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf ``` 7. Finalize the Runtime Fabric installation, and configure it to pull from your local registry: ```copy # rtfctl install ‘’ --image-pull-registry ``` Alternatively, if you use authentication to access your registry, use the following command: ```copy # rtfctl install ‘’ --image-pull-registry --image-pull-secret ``` This command ensures that Runtime Fabric creates the necessary overrides for the local registry URL and `image-pull-secret` values so Runtime Fabric continues to pull images from the local registry even after an upgrade. 8. If you use authentication to access your registry, after you complete the installation, you must recreate the pull secret in the RTF namespace and in any other namespaces where you will deploy applications. 9. Refer to the [installation instructions](https://docs.mulesoft.com/runtime-fabric/2.6/install-self-managed) for further steps, such as inserting the Mule license key. The `rtfctl uninstall` command deletes any pull secret you specify during installation. When using `rtfctl` to perform a backup and restore procedure, the backups point to your local registry URL and pull secret. 1. [Synchronize your container images](#synch-rtf) to your local registry. 2. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.6/install-helm#create-a-runtime-fabric-using-runtime-manager). 3. In Runtime Manager, select the **Helm** path, and follow the instructions on the screen platform. 4. Obtain your private `docker-server`, `docker-username`, and `docker-password`. 5. Follow the **Helm** path instructions in Runtime Manager to create a secret with your docker server name, username, and password by running the following command in your Unix shell: ```copy kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 6. Follow the **Helm** path instructions to download the `values.yml` file so that you can modify its values. For the private registry configuration, update `rtfRegistry` with your local docker server, and update the `pullSecretName` parameter. . 7. Continue with the **Helm** path instructions and install Runtime Fabric in your Kubernetes cluster. ## See Also - [Configure values.yml Reference](https://docs.mulesoft.com/runtime-fabric/2.6/install-helm#values-yml-reference) --- product: Runtime Fabric version: 2.7 --- # Using a Local Registry with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric uses its own registry to store the necessary Docker images for installing and managing Runtime Fabric and for running applications in Kubernetes. If your security policies require that you pull your Docker images from a registry under your control, you can set up a local registry to pull and store these Docker images. ## Limitations on Local Registry Support You can configure local registry across all Runtime Fabric supported platform vendors to store Mule Docker images (for use when managing application deployments) and Runtime Fabric software images (for use when updating or installing Runtime Fabric software). The following details and limitations apply to both Mule Docker images and Runtime Fabric software images. > [!IMPORTANT] You cannot use local registry for installation or management of Runtime Fabric > operator on OpenShift. - You can use [Runtime Fabric command line utility (`rtfctl`)](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl) version 0.3.150 or later. `rtfctl` installs Runtime Fabric agent to the latest version by default. - You can use Helm to install Runtime Fabric and configure your local registry. - You can use a local registry only if you create a new Runtime Fabric instance of version 1.12.0 or later. If you set up a local registry, you can upgrade to a version later than 1.12.0 without reinstalling Runtime Fabric. To add local registry to an existing Runtime Fabric instance, ensure that the installation is Helm-based [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/migrate-helm) and perform the steps on the following section to add local registry. - If you create a Runtime Fabric instance to use with a local registry, you cannot later reconfigure it to use the `rtf-runtime-registry` endpoint. To use the `rtf-runtime-registry` endpoint, you must install a new Runtime Fabric instance using the standard installation procedure. - You are responsible for synchronizing your local registry with required dependencies: - [Synchronize Runtime Fabric core software images or dependencies automatically](#synch-rtf) - [Synchronize Mule runtime images or dependencies manually](#synch-runtime) - Synchronize third party dependencies required by your application. MuleSoft doesn’t provide additional software to synchronize third party dependencies and images. Push all the dependency images for your Mule app to your local registry before you start the deployments. - If you use a local registry that needs authentication, synchronization and propagation of a pull secret between different namespaces is your responsibility. Alternatively, Runtime Fabric can synchronize your pull secret across different namespaces if your secret uses the following label: labels: rtf.mulesoft.com/synchronized: "true" - If you need to authenticate access to your local registry, ensure that the [corresponding credentials are configured as a Kubernetes secret in the `rtf` namespace](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials). You’ll need the name of the configured secret when you install Runtime Fabric. ## Synchronize Mule Runtime Dependencies and Images to Your Local Registry To synchronize in your registry the Mule runtime versions you intend to use for application deployments, refer to the [Mule runtime patch updates for Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). The location of the image follows this format: `rtf-runtime-registry.kprod.msap.io/mulesoft/`. ## Synchronize Runtime Fabric Core Software Dependencies and Images to Your Local Registry To install Runtime Fabric, you must first synchronize the dependencies images to your local registry. You can perform the synchronization by either running a script automatically or executing commands manually. - Synchronize Automatically - Synchronize Manually To synchronize the dependencies images automatically, run a bash script that uses the `docker`, `curl`, and `jq` tools. > [!NOTE] Automated registry synchronization is available from Runtime Fabric version 2.6.0 onwards. > Previous dependencies cannot be retrieved using this script. Ensure that your [Access Management permission for Runtime Manager](https://docs.mulesoft.com/access-management/permissions-by-product#runtime-manager) is set to **Read Runtime Fabric**, which enables you to query Runtime Fabrics in your organization. 1. In your Unix shell, run the following script, replacing `agent-version`, `authorization-token`, `mulesoft-docker-server`, and any other parameter value where appropriate: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("openshift")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ```
Table 1. Script Parameters
ParametersDescription

platform-url

Anypoint Platform URL, such as https://anypoint.mulesoft.com, or https://eu1.anypoint.mulesoft.com.

agent-version

Runtime Fabric agent release version required for the synchronization.

authorization-token

Authorization token required for using connected apps to perform the synchronization. When you use this token, a link redirects to the connected apps page.

mulesoft-docker-server

MuleSoft Docker server required for the synchronization.
For the US control plane: rtf-runtime-registry.kprod.msap.io
For the EU control plane: rtf-runtime-registry.kprod-eu.msap.io

To synchronize the dependencies images manually, follow these steps: 1. Log in to your private container registry and run the following command, replacing `docker-server` where appropriate: For the US control plane: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the EU control plane: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push :5000/mulesoft/rtf-agent:v1.12.0 ``` ## Configure Your Local Registry for Runtime Fabric To configure a local registry, you must gather and add the necessary credentials to synchronize the registries. ### Before You Begin Ensure that you’ve performed the following tasks: 1. Set up, configure, and test your private Docker image registry. 2. [Synchronize](#synch-rtf) to your local registry all of the Docker images that you need to install Runtime Fabric: See the [Runtime Fabric release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the required dependencies for your Runtime Fabric version. > [!NOTE] Dependency versions are specific to the Runtime Fabric version. To install Runtime Fabric with your local registry using `rtfctl` or `helm`, select one of the following options: - RTFCTL - Helm 1. [Download and install the `rtfctl` command line utility](https://docs.mulesoft.com/runtime-fabric/2.7/install-self-managed#step-3-download-the-rtfctl-utility) version 0.3.150 or higher. 2. Obtain `rtf-runtime-registry` credentials: ```copy # rtfctl get registry-credentials ``` This command sets `RTF_IMAGE_REGISTRY_ENDPOINT`, `RTF_IMAGE_REGISTRY_USER`, and `RTF_IMAGE_REGISTRY_PASSWORD` in the current shell environment. 3. Run the following commands to verify that the Docker login to the `rtf-runtime-registry` succeeds: ```copy # eval $(rtfctl get registry-credentials ) # docker login $RTF_IMAGE_REGISTRY_ENDPOINT --username $RTF_IMAGE_REGISTRY_USER --password $RTF_IMAGE_REGISTRY_PASSWORD ``` You should see a message that the login was successful. 4. [Synchronize your container images](#synch-rtf) to your local registry. 5. Repeat step 3 for all the other dependency images (resourceFetcher, clusterOps etc.) based on the versions published in the Runtime Fabric release notes. 6. If you use authentication to access your registry, create the required secret in the rtf namespace: ```copy # kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf ``` 7. Finalize the Runtime Fabric installation, and configure it to pull from your local registry: ```copy # rtfctl install ‘’ --image-pull-registry ``` Alternatively, if you use authentication to access your registry, use the following command: ```copy # rtfctl install ‘’ --image-pull-registry --image-pull-secret ``` This command ensures that Runtime Fabric creates the necessary overrides for the local registry URL and `image-pull-secret` values so Runtime Fabric continues to pull images from the local registry even after an upgrade. 8. If you use authentication to access your registry, after you complete the installation, you must recreate the pull secret in the RTF namespace and in any other namespaces where you will deploy applications. 9. Refer to the [installation instructions](https://docs.mulesoft.com/runtime-fabric/2.7/install-self-managed) for further steps, such as inserting the Mule license key. The `rtfctl uninstall` command deletes any pull secret you specify during installation. When using `rtfctl` to perform a backup and restore procedure, the backups point to your local registry URL and pull secret. 1. [Synchronize your container images](#synch-rtf) to your local registry. 2. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.7/install-helm#create-a-runtime-fabric-using-runtime-manager). 3. In Runtime Manager, select the **Helm** path, and follow the instructions on the screen platform. 4. Obtain your private `docker-server`, `docker-username`, and `docker-password`. 5. Follow the **Helm** path instructions in Runtime Manager to create a secret with your docker server name, username, and password by running the following command in your Unix shell: ```copy kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 6. Follow the **Helm** path instructions to download the `values.yml` file so that you can modify its values. For the private registry configuration, update `rtfRegistry` with your local docker server, and update the `pullSecretName` parameter. . 7. Continue with the **Helm** path instructions and install Runtime Fabric in your Kubernetes cluster. ## See Also - [Configure values.yml Reference](https://docs.mulesoft.com/runtime-fabric/2.7/install-helm#values-yml-reference) --- product: Runtime Fabric version: 2.8 --- # Using a Local Registry with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric uses its own registry to store the necessary Docker images for installing and managing Runtime Fabric and for running applications in Kubernetes. If your security policies require that you pull your Docker images from a registry under your control, you can set up a local registry to pull and store these Docker images. ## Limitations on Local Registry Support You can configure local registry across all Runtime Fabric supported platform vendors to store Mule Docker images (for use when managing application deployments) and Runtime Fabric software images (for use when updating or installing Runtime Fabric software). The following details and limitations apply to both Mule Docker images and Runtime Fabric software images. > [!IMPORTANT] You cannot use local registry for installation or management of Runtime Fabric > operator on OpenShift. - You can use [Runtime Fabric command line utility (`rtfctl`)](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) version 0.3.150 or later. `rtfctl` installs Runtime Fabric agent to the latest version by default. - You can use Helm to install Runtime Fabric and configure your local registry. - You can use a local registry only if you create a new Runtime Fabric instance of version 1.12.0 or later. If you set up a local registry, you can upgrade to a version later than 1.12.0 without reinstalling Runtime Fabric. To add local registry to an existing Runtime Fabric instance, ensure that the installation is Helm-based [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/migrate-helm) and perform the steps on the following section to add local registry. - If you create a Runtime Fabric instance to use with a local registry, you cannot later reconfigure it to use the `rtf-runtime-registry` endpoint. To use the `rtf-runtime-registry` endpoint, you must install a new Runtime Fabric instance using the standard installation procedure. - You are responsible for synchronizing your local registry with required dependencies: - [Synchronize Runtime Fabric core software images or dependencies automatically](#synch-rtf) - [Synchronize Mule runtime images or dependencies manually](#synch-runtime) - Synchronize third party dependencies required by your application. MuleSoft doesn’t provide additional software to synchronize third party dependencies and images. Push all the dependency images for your Mule app to your local registry before you start the deployments. - If you use a local registry that needs authentication, synchronization and propagation of a pull secret between different namespaces is your responsibility. Alternatively, Runtime Fabric can synchronize your pull secret across different namespaces if your secret uses the following label: labels: rtf.mulesoft.com/synchronized: "true" - If you need to authenticate access to your local registry, ensure that the [corresponding credentials are configured as a Kubernetes secret in the `rtf` namespace](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials). You’ll need the name of the configured secret when you install Runtime Fabric. ## Synchronize Mule Runtime Dependencies and Images to Your Local Registry To synchronize in your registry the Mule runtime versions you intend to use for application deployments, refer to the [Mule runtime patch updates for Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). The location of the image follows this format: `rtf-runtime-registry.kprod.msap.io/mulesoft/`. ## Synchronize Runtime Fabric Core Software Dependencies and Images to Your Local Registry To install Runtime Fabric, you must first synchronize the dependencies images to your local registry. You can perform the synchronization by either running a script automatically or executing commands manually. - Synchronize Automatically - Synchronize Manually To synchronize the dependencies images automatically, run a bash script that uses the `docker`, `curl`, and `jq` tools. > [!NOTE] Automated registry synchronization is available from Runtime Fabric version 2.6.0 onwards. > Previous dependencies cannot be retrieved using this script. Ensure that your [Access Management permission for Runtime Manager](https://docs.mulesoft.com/access-management/permissions-by-product#runtime-manager) is set to **Read Runtime Fabric**, which enables you to query Runtime Fabrics in your organization. 1. In your Unix shell, run the following script, replacing `agent-version`, `authorization-token`, `mulesoft-docker-server`, and any other parameter value where appropriate: For non-OpenShift environments: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("generic")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ``` For OpenShift environments: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("openshift")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ```
Table 1. Script Parameters
ParametersDescription

platform-url

Anypoint Platform URL, such as https://anypoint.mulesoft.com, or https://eu1.anypoint.mulesoft.com.

agent-version

Runtime Fabric agent release version required for the synchronization.

authorization-token

Authorization token required for using connected apps to perform the synchronization. When you use this token, a link redirects to the connected apps page.

mulesoft-docker-server

MuleSoft Docker server required for the synchronization.
For the US control plane: rtf-runtime-registry.kprod.msap.io
For the EU control plane: rtf-runtime-registry.kprod-eu.msap.io

To synchronize the dependencies images manually, follow these steps: 1. Log in to your private container registry and run the following command, replacing `docker-server` where appropriate: For the US control plane: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the EU control plane: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push :5000/mulesoft/rtf-agent:v1.12.0 ``` ## Configure Your Local Registry for Runtime Fabric To configure a local registry, you must gather and add the necessary credentials to synchronize the registries. ### Before You Begin Ensure that you’ve performed the following tasks: 1. Set up, configure, and test your private Docker image registry. 2. [Synchronize](#synch-rtf) to your local registry all of the Docker images that you need to install Runtime Fabric: See the [Runtime Fabric release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the required dependencies for your Runtime Fabric version. > [!NOTE] Dependency versions are specific to the Runtime Fabric version. To install Runtime Fabric with your local registry using `rtfctl` or `helm`, select one of the following options: - RTFCTL - Helm - OpenShift 1. [Download and install the `rtfctl` command line utility](https://docs.mulesoft.com/runtime-fabric/2.8/install-self-managed#step-3-download-the-rtfctl-utility) version 0.3.150 or higher. 2. Obtain `rtf-runtime-registry` credentials: ```copy # rtfctl get registry-credentials ``` This command sets `RTF_IMAGE_REGISTRY_ENDPOINT`, `RTF_IMAGE_REGISTRY_USER`, and `RTF_IMAGE_REGISTRY_PASSWORD` in the current shell environment. 3. Run the following commands to verify that the Docker login to the `rtf-runtime-registry` succeeds: ```copy # eval $(rtfctl get registry-credentials ) # docker login $RTF_IMAGE_REGISTRY_ENDPOINT --username $RTF_IMAGE_REGISTRY_USER --password $RTF_IMAGE_REGISTRY_PASSWORD ``` You should see a message that the login was successful. 4. [Synchronize your container images](#synch-rtf) to your local registry. 5. Repeat step 3 for all the other dependency images (resourceFetcher, clusterOps etc.) based on the versions published in the Runtime Fabric release notes. 6. If you use authentication to access your registry, create the required secret in the rtf namespace: ```copy # kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf ``` 7. Finalize the Runtime Fabric installation, and configure it to pull from your local registry: ```copy # rtfctl install ‘’ --image-pull-registry ``` Alternatively, if you use authentication to access your registry, use the following command: ```copy # rtfctl install ‘’ --image-pull-registry --image-pull-secret ``` This command ensures that Runtime Fabric creates the necessary overrides for the local registry URL and `image-pull-secret` values so Runtime Fabric continues to pull images from the local registry even after an upgrade. 8. If you use authentication to access your registry, after you complete the installation, you must recreate the pull secret in the RTF namespace and in any other namespaces where you will deploy applications. 9. Refer to the [installation instructions](https://docs.mulesoft.com/runtime-fabric/2.8/install-self-managed) for further steps, such as inserting the Mule license key. The `rtfctl uninstall` command deletes any pull secret you specify during installation. When using `rtfctl` to perform a backup and restore procedure, the backups point to your local registry URL and pull secret. 1. [Synchronize your container images](#synch-rtf) to your local registry. 2. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.8/install-helm#create-a-runtime-fabric-using-runtime-manager). 3. In Runtime Manager, select the **Helm** path, and follow the instructions on the screen platform. 4. Obtain your private `docker-server`, `docker-username`, and `docker-password`. 5. Follow the **Helm** path instructions in Runtime Manager to create a secret with your docker server name, username, and password by running the following command in your Unix shell: ```copy kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 6. Follow the **Helm** path instructions to download the `values.yml` file so that you can modify its values. For the private registry configuration, update `rtfRegistry` with your local docker server, and update the `pullSecretName` parameter. . 7. Continue with the **Helm** path instructions and install Runtime Fabric in your Kubernetes cluster. 8. [Synchronize your container images](#synch-rtf) to your local registry. 9. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.8/install-helm#create-a-runtime-fabric-using-runtime-manager). 10. In Runtime Manager, follow the instructions on the screen platform. 11. Obtain your private `docker-server`, `docker-username`, and `docker-password`. 12. Follow the instructions in Runtime Manager to create a secret with your docker server name, username, and password by running the following command in your Unix shell: ```copy oc create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 13. In the OpenShift form view, set the rtfRegistry values to configure the local registry. ![OpenShift form view to add values for rtfRegistry](/mulesoft/current/en-us/runtime-fabric/2.8/_images/ocp-local-registry.png) 14. Continue with the OpenShift installation. ## See Also - [Configure values.yml Reference](https://docs.mulesoft.com/runtime-fabric/2.8/install-helm#values-yml-reference) --- product: Runtime Fabric version: 2.9 --- # Using a Local Registry with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Runtime Fabric uses its own registry to store the necessary Docker images for installing and managing Runtime Fabric and for running applications in Kubernetes. If your security policies require that you pull your Docker images from a registry under your control, you can set up a local registry to pull and store these Docker images. ## Limitations on Local Registry Support You can configure local registry across all Runtime Fabric supported platform vendors to store Mule Docker images (for use when managing application deployments) and Runtime Fabric software images (for use when updating or installing Runtime Fabric software). The following details and limitations apply to both Mule Docker images and Runtime Fabric software images. > [!IMPORTANT] You cannot use local registry for installation or management of Runtime Fabric > operator on OpenShift. - You can use [Runtime Fabric command line utility (`rtfctl`)](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl) version 0.3.150 or later. `rtfctl` installs Runtime Fabric agent to the latest version by default. - You can use Helm to install Runtime Fabric and configure your local registry. - You can use a local registry only if you create a new Runtime Fabric instance of version 1.12.0 or later. If you set up a local registry, you can upgrade to a version later than 1.12.0 without reinstalling Runtime Fabric. To add local registry to an existing Runtime Fabric instance, ensure that the installation is Helm-based [Migrating to Helm Managed Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/migrate-helm) and perform the steps on the following section to add local registry. - If you create a Runtime Fabric instance to use with a local registry, you cannot later reconfigure it to use the `rtf-runtime-registry` endpoint. To use the `rtf-runtime-registry` endpoint, you must install a new Runtime Fabric instance using the standard installation procedure. - You are responsible for synchronizing your local registry with required dependencies: - [Synchronize Runtime Fabric core software images or dependencies automatically](#synch-rtf) - [Synchronize Mule runtime images or dependencies manually](#synch-runtime) - Synchronize third party dependencies required by your application. MuleSoft doesn’t provide additional software to synchronize third party dependencies and images. Push all the dependency images for your Mule app to your local registry before you start the deployments. - If you use a local registry that needs authentication, synchronization and propagation of a pull secret between different namespaces is your responsibility. Alternatively, Runtime Fabric can synchronize your pull secret across different namespaces if your secret uses the following label: labels: rtf.mulesoft.com/synchronized: "true" - If you need to authenticate access to your local registry, ensure that the [corresponding credentials are configured as a Kubernetes secret in the `rtf` namespace](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials). You’ll need the name of the configured secret when you install Runtime Fabric. ## Synchronize Mule Runtime Dependencies and Images to Your Local Registry To synchronize in your registry the Mule runtime versions you intend to use for application deployments, refer to the [Mule runtime patch updates for Runtime Fabric Release Notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes). The location of the image follows this format: `rtf-runtime-registry.kprod.msap.io/mulesoft/`. ## Synchronize Runtime Fabric Core Software Dependencies and Images to Your Local Registry To install Runtime Fabric, you must first synchronize the dependencies images to your local registry. You can perform the synchronization by either running a script automatically or executing commands manually. - Synchronize Automatically - Synchronize Manually To synchronize the dependencies images automatically, run a bash script that uses the `docker`, `curl`, and `jq` tools. > [!NOTE] Automated registry synchronization is available from Runtime Fabric version 2.6.0 onwards. > Previous dependencies cannot be retrieved using this script. Ensure that your [Access Management permission for Runtime Manager](https://docs.mulesoft.com/access-management/permissions-by-product#runtime-manager) is set to **Read Runtime Fabric**, which enables you to query Runtime Fabrics in your organization. 1. In your Unix shell, run the following script, replacing `agent-version`, `authorization-token`, `mulesoft-docker-server`, and any other parameter value where appropriate: For non-OpenShift environments: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("generic")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ``` For OpenShift environments: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("openshift")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ```
Table 1. Script Parameters
ParametersDescription

platform-url

Anypoint Platform URL, such as https://anypoint.mulesoft.com, or https://eu1.anypoint.mulesoft.com.

agent-version

Runtime Fabric agent release version required for the synchronization.

authorization-token

Authorization token required for using connected apps to perform the synchronization. When you use this token, a link redirects to the connected apps page.

mulesoft-docker-server

MuleSoft Docker server required for the synchronization.
For the US control plane: rtf-runtime-registry.kprod.msap.io
For the EU control plane: rtf-runtime-registry.kprod-eu.msap.io

To synchronize the dependencies images manually, follow these steps: 1. Log in to your private container registry and run the following command, replacing `docker-server` where appropriate: For the US control plane: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` For the EU control plane: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push :5000/mulesoft/rtf-agent:v1.12.0 ``` ## Configure Your Local Registry for Runtime Fabric To configure a local registry, you must gather and add the necessary credentials to synchronize the registries. ### Before You Begin Ensure that you’ve performed the following tasks: 1. Set up, configure, and test your private Docker image registry. 2. [Synchronize](#synch-rtf) to your local registry all of the Docker images that you need to install Runtime Fabric: See the [Runtime Fabric release notes](https://docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) for the required dependencies for your Runtime Fabric version. > [!NOTE] Dependency versions are specific to the Runtime Fabric version. To install Runtime Fabric with your local registry using `rtfctl` or `helm`, select one of the following options: - RTFCTL - Helm - OpenShift 1. [Download and install the `rtfctl` command line utility](https://docs.mulesoft.com/runtime-fabric/2.9/install-self-managed#step-3-download-the-rtfctl-utility) version 0.3.150 or higher. 2. Obtain `rtf-runtime-registry` credentials: ```copy # rtfctl get registry-credentials ``` This command sets `RTF_IMAGE_REGISTRY_ENDPOINT`, `RTF_IMAGE_REGISTRY_USER`, and `RTF_IMAGE_REGISTRY_PASSWORD` in the current shell environment. 3. Run the following commands to verify that the Docker login to the `rtf-runtime-registry` succeeds: ```copy # eval $(rtfctl get registry-credentials ) # docker login $RTF_IMAGE_REGISTRY_ENDPOINT --username $RTF_IMAGE_REGISTRY_USER --password $RTF_IMAGE_REGISTRY_PASSWORD ``` You should see a message that the login was successful. 4. [Synchronize your container images](#synch-rtf) to your local registry. 5. Repeat step 3 for all the other dependency images (resourceFetcher, clusterOps etc.) based on the versions published in the Runtime Fabric release notes. 6. If you use authentication to access your registry, create the required secret in the rtf namespace: ```copy # kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf ``` 7. Finalize the Runtime Fabric installation, and configure it to pull from your local registry: ```copy # rtfctl install ‘’ --image-pull-registry ``` Alternatively, if you use authentication to access your registry, use the following command: ```copy # rtfctl install ‘’ --image-pull-registry --image-pull-secret ``` This command ensures that Runtime Fabric creates the necessary overrides for the local registry URL and `image-pull-secret` values so Runtime Fabric continues to pull images from the local registry even after an upgrade. 8. If you use authentication to access your registry, after you complete the installation, you must recreate the pull secret in the RTF namespace and in any other namespaces where you will deploy applications. 9. Refer to the [installation instructions](https://docs.mulesoft.com/runtime-fabric/2.9/install-self-managed) for further steps, such as inserting the Mule license key. The `rtfctl uninstall` command deletes any pull secret you specify during installation. When using `rtfctl` to perform a backup and restore procedure, the backups point to your local registry URL and pull secret. 1. [Synchronize your container images](#synch-rtf) to your local registry. 2. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.9/install-helm#create-a-runtime-fabric-using-runtime-manager). 3. In Runtime Manager, select the **Helm** path, and follow the instructions on the screen platform. 4. Obtain your private `docker-server`, `docker-username`, and `docker-password`. 5. Follow the **Helm** path instructions in Runtime Manager to create a secret with your docker server name, username, and password by running the following command in your Unix shell: ```copy kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 6. Follow the **Helm** path instructions to download the `values.yml` file so that you can modify its values. For the private registry configuration, update `rtfRegistry` with your local docker server, and update the `pullSecretName` parameter. . 7. Continue with the **Helm** path instructions and install Runtime Fabric in your Kubernetes cluster. 8. [Synchronize your container images](#synch-rtf) to your local registry. 9. [Create a Runtime Fabric using Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.9/install-helm#create-a-runtime-fabric-using-runtime-manager). 10. In Runtime Manager, follow the instructions on the screen platform. 11. Obtain your private `docker-server`, `docker-username`, and `docker-password`. 12. Follow the instructions in Runtime Manager to create a secret with your docker server name, username, and password by running the following command in your Unix shell: ```copy oc create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 13. In the OpenShift form view, set the rtfRegistry values to configure the local registry. ![OpenShift form view to add values for rtfRegistry](/mulesoft/current/en-us/runtime-fabric/2.9/_images/ocp-local-registry.png) 14. Continue with the OpenShift installation. ## See Also - [Configure values.yml Reference](https://docs.mulesoft.com/runtime-fabric/2.9/install-helm#values-yml-reference) --- product: Runtime Fabric version: 2.10 --- # Using Anypoint Monitoring > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps and API gateways deployed to Runtime Fabric include native support for Anypoint Monitoring that allows viewing metrics from within Anypoint Platform. ## Anypoint Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) includes tools that provide feedback from Mule flows and components in your Mule app network. Anypoint Monitoring runs as a sidecar in application deployments and gathers metrics for Mule apps and API gateways deployed to Runtime Fabric. Titanium-plan customers have access to additional capabilities, including application log retrieval and search. ## Enable Anypoint Monitoring By default, Runtime Fabric is configured to send application metrics to Anypoint Monitoring. Data is securely transmitted using mutual TLS encryption. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available. > [!NOTE] Starting with Runtime Fabric agent version 2.6.22, Anypoint Monitoring sidecar is > compatible only with HTTP-proxy instead of Monitoring SOCKS5 proxy. If you need an outbound proxy, configure Anypoint Runtime Fabric to use a SOCKS5 proxy by following the instructions in [Configuring Proxies on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/manage-proxy-self). To verify outbound network connectivity on Anypoint Runtime Fabric version 1.8.50 or later, ensure that each node in Runtime Fabric can send outbound TCP (Lumberjack) communication using port 443 to the following domains: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` > [!NOTE] If you are using a version of Anypoint Runtime Fabric older than 1.8.50, use port 5044 > instead of port 443. Use the following domains: > > - US control plane: `dias-ingestor-nginx.prod.cloudhub.io` > > - EU control plane: `dias-ingestor-nginx.prod-eu.msap.io` For further details on Anypoint Monitoring endpoints, refer to [configuring your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-self-managed-network-configuration). ## Metrics Each Mule app and API gateway replica runs a metrics agent that collects and transmits metrics data to Anypoint Monitoring via secure mutual TLS encryption. Each replica can cache up to 100 megabytes of metrics, after which the metrics data is rotated to provide storage for more recent data. If metrics can’t be sent to Anypoint Monitoring, this typically provides at least four days worth of storage per replica. Custom metrics might consume more storage. The following Anypoint Runtime Fabric updates do not impact or restore monitoring metrics of applications deployed on Runtime Fabric: - A backup and restore of Runtime Fabric - An upgrade of Runtime Fabric - OS patching of Runtime Fabric nodes ## Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Rutime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Each Mule app and API gateway replica can store up to 450 megabytes of log data on disk, after which log data is rotated to provide storage for more recent log data. Logs generated by each replica of a Mule app and API gateway are collected and written to disk on the worker node on which they are running. Each worker node runs a single log forwarding agent, which monitors this location and transmits the log data to Anypoint Monitoring. The log forwarding agent can transmit up to 300 kilobytes of log data per second. You should not deploy more than 50 replicas per worker node. In some cases, logs with multiple lines might not be fully transmitted to Anypoint Monitoring. This can occur if multiple lines of log output are split across two files due to log rotation inside Runtime Fabric. You can enable log forwarding and set log levels when you [deploy applications in Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-runtime-fabric#configure-logging-and-log-levels). ### Resource and Permission Requirements for Anypoint Monitoring Agent MuleSoft runs Anypoint Monitoring agents alongside Mule apps to send telemetry to the Anypoint control plane. For Mule apps deployed or managed using Runtime Fabric agent version 2.5.x or lower, two different agents are used as follows: - One DaemonSet per underlying node to transport logs to Anypoint monitoring control plane. - One sidecar per application replica to transporting metrics to Anypoint monitoring control plane. For optimal daemonset functionality, follow these prerequisites: 1. Check that the application containers write logs to the following locations: - `/var/log/pods` - `/var/log/containers` - `/var/lib/docker/containers` 2. Check that the DaemonSet creates and writes on the host path `/var/lib/filebeat-data`. 3. Ensure that the Docker daemon config includes the `json-file` logging driver. 4. Ensure that the Anypoint Monitoring log forwarder DaemonSet container has write access to the host on the host path `/var/lib/filebeat-data`. For applications deployed or managed using Runtime Fabric versions 2.6.x and above, MuleSoft consolidates telemetry transport to a single sidecar per application replica. Dependent on the features you use, the sidecar agent consumes corresponding resources for optimal performance: - To enable default Anypoint metrics, the sidecar agent (per application replica) requires 0.05vCPU or Core of CPU allocation and 90MiB memory allocation. - If you opt into [forwarding application logs to Anypoint Monitoring](https://docs.mulesoft.com/runtime-fabric/2.10/deploy-to-runtime-fabric#configure-logging-and-log-levels), the sidecar agent (per application replica) requires up to 30% of CPU limit configured for application replica and up to 150MiB memory allocation - If you opt into trace data generation for Mule apps, the sidecar agent (per application replica) requires up to 30% of CPU limit configured for application replica and up to 240MB memory allocation. > [!NOTE] Allocate appropriate capacity to the underlying cluster to avoid application deployment > failure. ### (Optional) Disabling Log Forwarder DeamonSet in Runtime Fabric Versions 2.6.x and Higher After you upgrade Runtime Fabric agent to version 2.6.0 or higher, all deployments use only a single sidecar for metrics and log forwarding. If you had any Mule apps running under a previous agent, redeploy them to start using the new log forwarding mechanism. Any update you perform in the control plane triggers the redeployment. After all your deployments use the new sidecar container, the `am-log-forwarder` DaemonSet just sits idle. To remove the DeamonSet completely, disable Anypoint Monitoring log forwarding using the corresponding [Anypoint Platform API call](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/runtime-fabric/minor/1.0/console/method/%232251/) sending a payload like this: \[source,json { "anypointMonitoring": false } This disabling does not impact the log forwarding to Anypoint Monitoring via the sidecar. ## Anypoint Visualizer [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/) displays views of different aspects of an application network graph. You can use the graph to explore your application network, identify problems, and make decisions. > [!WARNING] By default, Anypoint Visualizer is disabled when deploying an application to Mule > runtime 4.x. See [Enable Header Injection](https://docs.mulesoft.com/visualizer/setup#enable-header-injection) for > more information. Due to the impact on performance, enabling Anypoint Visualizer for application > deployments with less than 0.2 vCPU is not supported. ## (Optional) Disable Anypoint Monitoring for a Mule App When you deploy a Mule app to Runtime Fabric, Anypoint Monitoring is enabled by default. To disable Anypoint Monitoring, pass the following custom property when deploying your Mule app: ```copy anypoint.platform.config.analytics.agent.enabled=false ``` ## Enable Trace Data Collection > [!NOTE] This feature is available only if your organization has the Anypoint Integration Advanced > package or a Titanium subscription to Anypoint Platform. For more information, see the > [Pricing and Packaging](https://docs.mulesoft.com/general/pricing) documentation. Traces enable you to understand the path of a transaction in the MuleSoft ecosystem by providing full visibility into the execution path of API calls or application transactions. When you enable trace data collection for an app, Anypoint Platform collects and exposes tracing information from Mule runtime engine in the OpenTelemetry standard, enabling you to export it using the Anypoint Monitoring [Telemetry Exporter](https://docs.mulesoft.com/monitoring/telemetry-exporter). - You can enable trace data collection for your Runtime Fabric applications running on Mule version 4.6 or later, and the minimum Runtime Fabric agent version required is 2.6.31 or above. - You can enable trace data collection using only the Runtime Manager UI and API, but you can’t enable trace data collection using the Mule Maven plugin, Anypoint CLI, or Anypoint Studio. To enable trace data collection for an app: 1. Click the **Monitoring** tab. 2. Select the **Enable tracing** checkbox. 3. Click **Deploy Application** if you are enabling the feature for a new deployment, or **Apply Changes** if you are editing an existing application. Once you enable tracing, and redeploy your application, the Runtime Manager backend starts instrumenting traces for your application. --- product: Runtime Fabric version: 2.11 --- # Using Anypoint Monitoring > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps and API gateways deployed to Runtime Fabric include native support for Anypoint Monitoring that allows viewing metrics from within Anypoint Platform. ## Anypoint Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) includes tools that provide feedback from Mule flows and components in your Mule app network. Anypoint Monitoring runs as a sidecar in application deployments and gathers metrics for Mule apps and API gateways deployed to Runtime Fabric. Titanium-plan customers have access to additional capabilities, including application log retrieval and search. ## Enable Anypoint Monitoring By default, Runtime Fabric is configured to send application metrics to Anypoint Monitoring. Data is securely transmitted using mutual TLS encryption. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available. > [!NOTE] Starting with Runtime Fabric agent version 2.6.22, Anypoint Monitoring sidecar is > compatible only with HTTP-proxy instead of Monitoring SOCKS5 proxy. If you need an outbound proxy, configure Anypoint Runtime Fabric to use a SOCKS5 proxy by following the instructions in [Configuring Proxies on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/manage-proxy-self). To verify outbound network connectivity on Anypoint Runtime Fabric version 1.8.50 or later, ensure that each node in Runtime Fabric can send outbound TCP (Lumberjack) communication using port 443 to these domains: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` > [!NOTE] If you are using a version of Anypoint Runtime Fabric older than 1.8.50, use port 5044 > instead of port 443. Use these domains: > > - US control plane: `dias-ingestor-nginx.prod.cloudhub.io` > > - EU control plane: `dias-ingestor-nginx.prod-eu.msap.io` For further details on Anypoint Monitoring endpoints, refer to [configuring your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-self-managed-network-configuration). ## Metrics Each Mule app and API gateway replica runs a metrics agent that collects and transmits metrics data to Anypoint Monitoring via secure mutual TLS encryption. Each replica can cache up to 100 megabytes of metrics, after which the metrics data is rotated to provide storage for more recent data. If metrics can’t be sent to Anypoint Monitoring, this typically provides at least four days worth of storage per replica. Custom metrics might consume more storage. The following Anypoint Runtime Fabric updates do not impact or restore monitoring metrics of applications deployed on Runtime Fabric: - A backup and restore of Runtime Fabric - An upgrade of Runtime Fabric - OS patching of Runtime Fabric nodes ## Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Rutime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Each Mule app and API gateway replica can store up to 450 megabytes of log data on disk, after which log data is rotated to provide storage for more recent log data. Logs generated by each replica of a Mule app and API gateway are collected and written to disk on the worker node on which they are running. Each worker node runs a single log forwarding agent, which monitors this location and transmits the log data to Anypoint Monitoring. The log forwarding agent can transmit up to 300 kilobytes of log data per second. You should not deploy more than 50 replicas per worker node. In some cases, logs with multiple lines might not be fully transmitted to Anypoint Monitoring. This can occur if multiple lines of log output are split across two files due to log rotation inside Runtime Fabric. You can enable log forwarding and set log levels when you [deploy applications in Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-runtime-fabric#configure-logging-and-log-levels). ### Resource and Permission Requirements for Anypoint Monitoring Agent MuleSoft runs Anypoint Monitoring agents alongside Mule apps to send telemetry to the Anypoint control plane. For Mule apps deployed or managed using Runtime Fabric agent version 2.5.x or lower, two different agents are used as follows: - One DaemonSet per underlying node to transport logs to Anypoint monitoring control plane. - One sidecar per application replica to transporting metrics to Anypoint monitoring control plane. For optimal daemonset functionality, follow these prerequisites: 1. Check that the application containers write logs to these locations: - `/var/log/pods` - `/var/log/containers` - `/var/lib/docker/containers` 2. Check that the DaemonSet creates and writes on the host path `/var/lib/filebeat-data`. 3. Ensure that the Docker daemon config includes the `json-file` logging driver. 4. Ensure that the Anypoint Monitoring log forwarder DaemonSet container has write access to the host on the host path `/var/lib/filebeat-data`. For applications deployed or managed using Runtime Fabric versions 2.6.x and above, MuleSoft consolidates telemetry transport to a single sidecar per application replica. Dependent on the features you use, the sidecar agent consumes corresponding resources for optimal performance: - To enable default Anypoint metrics, the sidecar agent (per application replica) requires 0.05vCPU or Core of CPU allocation and 90MiB memory allocation. - If you opt into [forwarding application logs to Anypoint Monitoring](https://docs.mulesoft.com/runtime-fabric/2.11/deploy-to-runtime-fabric#configure-logging-and-log-levels), the sidecar agent (per application replica) requires up to 30% of CPU limit configured for application replica and up to 150MiB memory allocation - If you opt into trace data generation for Mule apps, the sidecar agent (per application replica) requires up to 30% of CPU limit configured for application replica and up to 240MB memory allocation. > [!NOTE] Allocate appropriate capacity to the underlying cluster to avoid application deployment > failure. ### (Optional) Disabling Log Forwarder DeamonSet in Runtime Fabric Versions 2.6.x and Higher After you upgrade Runtime Fabric agent to version 2.6.0 or higher, all deployments use only a single sidecar for metrics and log forwarding. If you had any Mule apps running under a previous agent, redeploy them to start using the new log forwarding mechanism. Any update you perform in the control plane triggers the redeployment. After all your deployments use the new sidecar container, the `am-log-forwarder` DaemonSet just sits idle. To remove the DeamonSet completely, disable Anypoint Monitoring log forwarding using the corresponding [Anypoint Platform API call](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/runtime-fabric/minor/1.0/console/method/%232251/) sending a payload like this: \[source,json { "anypointMonitoring": false } This disabling does not impact the log forwarding to Anypoint Monitoring via the sidecar. ## Anypoint Visualizer [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/) displays views of different aspects of an application network graph. You can use the graph to explore your application network, identify problems, and make decisions. > [!WARNING] By default, Anypoint Visualizer is disabled when deploying an application to Mule > runtime 4.x. See [Enable Header Injection](https://docs.mulesoft.com/visualizer/setup#enable-header-injection) for > more information. Due to the impact on performance, enabling Anypoint Visualizer for application > deployments with less than 0.2 vCPU is not supported. ## (Optional) Disable Anypoint Monitoring for a Mule App When you deploy a Mule app to Runtime Fabric, Anypoint Monitoring is enabled by default. To disable Anypoint Monitoring, pass this custom property when deploying your Mule app: ```copy anypoint.platform.config.analytics.agent.enabled=false ``` > [!NOTE] For compliance or geospecific requirements if your team or organization cannot send > metrics to Anypoint control plane, you can disable Anypoint metrics if you are not contractually > obligated to send these metrics for Anypoint usage and billing purposes. ## Enable Trace Data Collection > [!NOTE] This feature is available only if your organization has the Anypoint Integration Advanced > package or a Titanium subscription to Anypoint Platform. For more information, see the > [Pricing and Packaging](https://docs.mulesoft.com/general/pricing) documentation. Traces enable you to understand the path of a transaction in the MuleSoft ecosystem by providing full visibility into the execution path of API calls or application transactions. When you enable trace data collection for an app, Anypoint Platform collects and exposes tracing information from Mule runtime engine in the OpenTelemetry standard, enabling you to export it using the Anypoint Monitoring [Telemetry Exporter](https://docs.mulesoft.com/monitoring/telemetry-exporter). - You can enable trace data collection for your Runtime Fabric applications running on Mule version 4.6 or later, and the minimum Runtime Fabric agent version required is 2.6.31 or above. - You can enable trace data collection using only the Runtime Manager UI and API, but you can’t enable trace data collection using the Mule Maven plugin, Anypoint CLI, or Anypoint Studio. To enable trace data collection for an app: 1. Click the **Monitoring** tab. 2. Select the **Enable tracing** checkbox. 3. Click **Deploy Application** if you are enabling the feature for a new deployment, or **Apply Changes** if you are editing an existing application. Once you enable tracing, and redeploy your application, the Runtime Manager backend starts instrumenting traces for your application. --- product: Runtime Fabric version: 2.6 --- # Using Anypoint Monitoring > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps and API gateways deployed to Runtime Fabric include native support for Anypoint Monitoring that allows viewing metrics from within Anypoint Platform. ## Anypoint Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) includes tools that provide feedback from Mule flows and components in your Mule app network. Anypoint Monitoring runs as a sidecar in application deployments and gathers metrics for Mule apps and API gateways deployed to Runtime Fabric. Titanium-plan customers have access to additional capabilities, including application log retrieval and search. ## Enable Anypoint Monitoring By default, Runtime Fabric is configured to send application metrics to Anypoint Monitoring. Data is securely transmitted using mutual TLS encryption. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available. If you need an outbound proxy, configure Anypoint Runtime Fabric to use a SOCKS5 proxy by following the instructions in [Configuring Proxies on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/manage-proxy-self). To verify outbound network connectivity on Anypoint Runtime Fabric version 1.8.50 or later, ensure that each node in Runtime Fabric can send outbound TCP (Lumberjack) communication using port 443 to the following domains: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` > [!NOTE] If you are using a version of Anypoint Runtime Fabric older than 1.8.50, use port 5044 > instead of port 443. Use the following domains: > > - US control plane: `dias-ingestor-nginx.prod.cloudhub.io` > > - EU control plane: `dias-ingestor-nginx.prod-eu.msap.io` For further details on Anypoint Monitoring endpoints, refer to [configuring your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-self-managed-network-configuration). ## Metrics Each Mule app and API gateway replica runs a metrics agent that collects and transmits metrics data to Anypoint Monitoring via secure mutual TLS encryption. Each replica can cache up to 100 megabytes of metrics, after which the metrics data is rotated to provide storage for more recent data. If metrics can’t be sent to Anypoint Monitoring, this typically provides at least four days worth of storage per replica. Custom metrics might consume more storage. The following Anypoint Runtime Fabric updates do not impact or restore monitoring metrics of applications deployed on Runtime Fabric: - A backup and restore of Runtime Fabric - An upgrade of Runtime Fabric - OS patching of Runtime Fabric nodes ## Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Rutime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Each Mule app and API gateway replica can store up to 450 megabytes of log data on disk, after which log data is rotated to provide storage for more recent log data. Logs generated by each replica of a Mule app and API gateway are collected and written to disk on the worker node on which they are running. Each worker node runs a single log forwarding agent, which monitors this location and transmits the log data to Anypoint Monitoring. The log forwarding agent can transmit up to 300 kilobytes of log data per second. You should not deploy more than 50 replicas per worker node. In some cases, logs with multiple lines might not be fully transmitted to Anypoint Monitoring. This can occur if multiple lines of log output are split across two files due to log rotation inside Runtime Fabric. You can enable log forwarding and set log levels when you [deploy applications in Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-runtime-fabric#configure-logging-and-log-levels). ### Resource and Permission Requirements for Anypoint Monitoring Agent MuleSoft runs Anypoint Monitoring agents alongside Mule apps to send telemetry to the Anypoint control plane. For Mule apps deployed or managed using Runtime Fabric agent version 2.5.x or lower, two different agents are used as follows: - One DaemonSet per underlying node to transport logs to Anypoint monitoring control plane. - One sidecar per application replica to transporting metrics to Anypoint monitoring control plane. For optimal daemonset functionality, follow these prerequisites: 1. Check that the application containers write logs to the following locations: - `/var/log/pods` - `/var/log/containers` - `/var/lib/docker/containers` 2. Check that the DaemonSet creates and writes on the host path `/var/lib/filebeat-data`. 3. Ensure that the Docker daemon config includes the `json-file` logging driver. 4. Ensure that the Anypoint Monitoring log forwarder DaemonSet container has write access to the host on the host path `/var/lib/filebeat-data`. For applications deployed or managed using Runtime Fabric versions 2.6.x and above, MuleSoft consolidates telemetry transport to a single sidecar per application replica. Dependent on the features you use, the sidecar agent consumes corresponding resources for optimal performance: - To enable default Anypoint metrics, the sidecar agent (per application replica) requires 0.05vCPU or Core of CPU allocation and 90MiB memory allocation. - If you opt into [forwarding application logs to Anypoint Monitoring](https://docs.mulesoft.com/runtime-fabric/2.6/deploy-to-runtime-fabric#configure-logging-and-log-levels), the sidecar agent (per application replica) requires up to 30% of CPU limit configured for application replica and up to 150MiB memory allocation - If you opt into trace data generation for Mule apps, the sidecar agent (per application replica) requires up to 30% of CPU limit configured for application replica and up to 240MB memory allocation. > [!NOTE] Allocate appropriate capacity to the underlying cluster to avoid application deployment > failure. ### (Optional) Disabling Log Forwarder DeamonSet in Runtime Fabric Versions 2.6.x and Higher After you upgrade Runtime Fabric agent to version 2.6.0 or higher, all deployments use only a single sidecar for metrics and log forwarding. If you had any Mule apps running under a previous agent, redeploy them to start using the new log forwarding mechanism. Any update you perform in the control plane triggers the redeployment. After all your deployments use the new sidecar container, the `am-log-forwarder` DaemonSet just sits idle. To remove the DeamonSet completely, disable Anypoint Monitoring log forwarding using the corresponding [Anypoint Platform API call](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/runtime-fabric/minor/1.0/console/method/%232251/) sending a payload like this: \[source,json { "anypointMonitoring": false } This disabling does not impact the log forwarding to Anypoint Monitoring via the sidecar. ## Anypoint Visualizer [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/) displays views of different aspects of an application network graph. You can use the graph to explore your application network, identify problems, and make decisions. > [!WARNING] By default, Anypoint Visualizer is disabled when deploying an application to Mule > runtime 4.x. See [Enable Header Injection](https://docs.mulesoft.com/visualizer/setup#enable-header-injection) for > more information. Due to the impact on performance, enabling Anypoint Visualizer for application > deployments with less than 0.2 vCPU is not supported. ## (Optional) Disable Anypoint Monitoring for a Mule App When you deploy a Mule app to Runtime Fabric, Anypoint Monitoring is enabled by default. To disable Anypoint Monitoring, pass the following custom property when deploying your Mule app: ```copy anypoint.platform.config.analytics.agent.enabled=false ``` ## Enable Trace Data Collection > [!NOTE] This feature is available only if your organization has the Anypoint Integration Advanced > package or a Titanium subscription to Anypoint Platform. For more information, see the > [Pricing and Packaging](https://docs.mulesoft.com/general/pricing) documentation. Traces enable you to understand the path of a transaction in the MuleSoft ecosystem by providing full visibility into the execution path of API calls or application transactions. When you enable trace data collection for an app, Anypoint Platform collects and exposes tracing information from Mule runtime engine in the OpenTelemetry standard, enabling you to export it using the Anypoint Monitoring [Telemetry Exporter](https://docs.mulesoft.com/monitoring/telemetry-exporter). - You can enable trace data collection for your Runtime Fabric applications running on Mule version 4.6 or later, and the minimum Runtime Fabric agent version required is 2.6.31 or above. - You can enable trace data collection using only the Runtime Manager UI and API, but you can’t enable trace data collection using the Mule Maven plugin, Anypoint CLI, or Anypoint Studio. To enable trace data collection for an app: 1. Click the **Monitoring** tab. 2. Select the **Enable tracing** checkbox. 3. Click **Deploy Application** if you are enabling the feature for a new deployment, or **Apply Changes** if you are editing an existing application. Once you enable tracing, and redeploy your application, the Runtime Manager backend starts instrumenting traces for your application. --- product: Runtime Fabric version: 2.7 --- # Using Anypoint Monitoring > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps and API gateways deployed to Runtime Fabric include native support for Anypoint Monitoring that allows viewing metrics from within Anypoint Platform. ## Anypoint Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) includes tools that provide feedback from Mule flows and components in your Mule app network. Anypoint Monitoring runs as a sidecar in application deployments and gathers metrics for Mule apps and API gateways deployed to Runtime Fabric. Titanium-plan customers have access to additional capabilities, including application log retrieval and search. ## Enable Anypoint Monitoring By default, Runtime Fabric is configured to send application metrics to Anypoint Monitoring. Data is securely transmitted using mutual TLS encryption. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available. If you need an outbound proxy, configure Anypoint Runtime Fabric to use a SOCKS5 proxy by following the instructions in [Configuring Proxies on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/manage-proxy-self). To verify outbound network connectivity on Anypoint Runtime Fabric version 1.8.50 or later, ensure that each node in Runtime Fabric can send outbound TCP (Lumberjack) communication using port 443 to the following domains: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` > [!NOTE] If you are using a version of Anypoint Runtime Fabric older than 1.8.50, use port 5044 > instead of port 443. Use the following domains: > > - US control plane: `dias-ingestor-nginx.prod.cloudhub.io` > > - EU control plane: `dias-ingestor-nginx.prod-eu.msap.io` For further details on Anypoint Monitoring endpoints, refer to [configuring your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-self-managed-network-configuration). ## Metrics Each Mule app and API gateway replica runs a metrics agent that collects and transmits metrics data to Anypoint Monitoring via secure mutual TLS encryption. Each replica can cache up to 100 megabytes of metrics, after which the metrics data is rotated to provide storage for more recent data. If metrics can’t be sent to Anypoint Monitoring, this typically provides at least four days worth of storage per replica. Custom metrics might consume more storage. The following Anypoint Runtime Fabric updates do not impact or restore monitoring metrics of applications deployed on Runtime Fabric: - A backup and restore of Runtime Fabric - An upgrade of Runtime Fabric - OS patching of Runtime Fabric nodes ## Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Rutime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Each Mule app and API gateway replica can store up to 450 megabytes of log data on disk, after which log data is rotated to provide storage for more recent log data. Logs generated by each replica of a Mule app and API gateway are collected and written to disk on the worker node on which they are running. Each worker node runs a single log forwarding agent, which monitors this location and transmits the log data to Anypoint Monitoring. The log forwarding agent can transmit up to 300 kilobytes of log data per second. You should not deploy more than 50 replicas per worker node. In some cases, logs with multiple lines might not be fully transmitted to Anypoint Monitoring. This can occur if multiple lines of log output are split across two files due to log rotation inside Runtime Fabric. You can enable log forwarding and set log levels when you [deploy applications in Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-runtime-fabric#configure-logging-and-log-levels). ### Resource and Permission Requirements for Anypoint Monitoring Agent MuleSoft runs Anypoint Monitoring agents alongside Mule apps to send telemetry to the Anypoint control plane. For Mule apps deployed or managed using Runtime Fabric agent version 2.5.x or lower, two different agents are used as follows: - One DaemonSet per underlying node to transport logs to Anypoint monitoring control plane. - One sidecar per application replica to transporting metrics to Anypoint monitoring control plane. For optimal daemonset functionality, follow these prerequisites: 1. Check that the application containers write logs to the following locations: - `/var/log/pods` - `/var/log/containers` - `/var/lib/docker/containers` 2. Check that the DaemonSet creates and writes on the host path `/var/lib/filebeat-data`. 3. Ensure that the Docker daemon config includes the `json-file` logging driver. 4. Ensure that the Anypoint Monitoring log forwarder DaemonSet container has write access to the host on the host path `/var/lib/filebeat-data`. For applications deployed or managed using Runtime Fabric versions 2.6.x and above, MuleSoft consolidates telemetry transport to a single sidecar per application replica. Dependent on the features you use, the sidecar agent consumes corresponding resources for optimal performance: - To enable default Anypoint metrics, the sidecar agent (per application replica) requires 0.05vCPU or Core of CPU allocation and 90MiB memory allocation. - If you opt into [forwarding application logs to Anypoint Monitoring](https://docs.mulesoft.com/runtime-fabric/2.7/deploy-to-runtime-fabric#configure-logging-and-log-levels), the sidecar agent (per application replica) requires up to 30% of CPU limit configured for application replica and up to 150MiB memory allocation - If you opt into trace data generation for Mule apps, the sidecar agent (per application replica) requires up to 30% of CPU limit configured for application replica and up to 240MB memory allocation. > [!NOTE] Allocate appropriate capacity to the underlying cluster to avoid application deployment > failure. ### (Optional) Disabling Log Forwarder DeamonSet in Runtime Fabric Versions 2.6.x and Higher After you upgrade Runtime Fabric agent to version 2.6.0 or higher, all deployments use only a single sidecar for metrics and log forwarding. If you had any Mule apps running under a previous agent, redeploy them to start using the new log forwarding mechanism. Any update you perform in the control plane triggers the redeployment. After all your deployments use the new sidecar container, the `am-log-forwarder` DaemonSet just sits idle. To remove the DeamonSet completely, disable Anypoint Monitoring log forwarding using the corresponding [Anypoint Platform API call](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/runtime-fabric/minor/1.0/console/method/%232251/) sending a payload like this: \[source,json { "anypointMonitoring": false } This disabling does not impact the log forwarding to Anypoint Monitoring via the sidecar. ## Anypoint Visualizer [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/) displays views of different aspects of an application network graph. You can use the graph to explore your application network, identify problems, and make decisions. > [!WARNING] By default, Anypoint Visualizer is disabled when deploying an application to Mule > runtime 4.x. See [Enable Header Injection](https://docs.mulesoft.com/visualizer/setup#enable-header-injection) for > more information. Due to the impact on performance, enabling Anypoint Visualizer for application > deployments with less than 0.2 vCPU is not supported. ## (Optional) Disable Anypoint Monitoring for a Mule App When you deploy a Mule app to Runtime Fabric, Anypoint Monitoring is enabled by default. To disable Anypoint Monitoring, pass the following custom property when deploying your Mule app: ```copy anypoint.platform.config.analytics.agent.enabled=false ``` ## Enable Trace Data Collection > [!NOTE] This feature is available only if your organization has the Anypoint Integration Advanced > package or a Titanium subscription to Anypoint Platform. For more information, see the > [Pricing and Packaging](https://docs.mulesoft.com/general/pricing) documentation. Traces enable you to understand the path of a transaction in the MuleSoft ecosystem by providing full visibility into the execution path of API calls or application transactions. When you enable trace data collection for an app, Anypoint Platform collects and exposes tracing information from Mule runtime engine in the OpenTelemetry standard, enabling you to export it using the Anypoint Monitoring [Telemetry Exporter](https://docs.mulesoft.com/monitoring/telemetry-exporter). - You can enable trace data collection for your Runtime Fabric applications running on Mule version 4.6 or later, and the minimum Runtime Fabric agent version required is 2.6.31 or above. - You can enable trace data collection using only the Runtime Manager UI and API, but you can’t enable trace data collection using the Mule Maven plugin, Anypoint CLI, or Anypoint Studio. To enable trace data collection for an app: 1. Click the **Monitoring** tab. 2. Select the **Enable tracing** checkbox. 3. Click **Deploy Application** if you are enabling the feature for a new deployment, or **Apply Changes** if you are editing an existing application. Once you enable tracing, and redeploy your application, the Runtime Manager backend starts instrumenting traces for your application. --- product: Runtime Fabric version: 2.8 --- # Using Anypoint Monitoring > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps and API gateways deployed to Runtime Fabric include native support for Anypoint Monitoring that allows viewing metrics from within Anypoint Platform. ## Anypoint Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) includes tools that provide feedback from Mule flows and components in your Mule app network. Anypoint Monitoring runs as a sidecar in application deployments and gathers metrics for Mule apps and API gateways deployed to Runtime Fabric. Titanium-plan customers have access to additional capabilities, including application log retrieval and search. ## Enable Anypoint Monitoring By default, Runtime Fabric is configured to send application metrics to Anypoint Monitoring. Data is securely transmitted using mutual TLS encryption. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available. If you need an outbound proxy, configure Anypoint Runtime Fabric to use a SOCKS5 proxy by following the instructions in [Configuring Proxies on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-proxy-self). To verify outbound network connectivity on Anypoint Runtime Fabric version 1.8.50 or later, ensure that each node in Runtime Fabric can send outbound TCP (Lumberjack) communication using port 443 to the following domains: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` > [!NOTE] If you are using a version of Anypoint Runtime Fabric older than 1.8.50, use port 5044 > instead of port 443. Use the following domains: > > - US control plane: `dias-ingestor-nginx.prod.cloudhub.io` > > - EU control plane: `dias-ingestor-nginx.prod-eu.msap.io` For further details on Anypoint Monitoring endpoints, refer to [configuring your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-self-managed-network-configuration). ## Metrics Each Mule app and API gateway replica runs a metrics agent that collects and transmits metrics data to Anypoint Monitoring via secure mutual TLS encryption. Each replica can cache up to 100 megabytes of metrics, after which the metrics data is rotated to provide storage for more recent data. If metrics can’t be sent to Anypoint Monitoring, this typically provides at least four days worth of storage per replica. Custom metrics might consume more storage. The following Anypoint Runtime Fabric updates do not impact or restore monitoring metrics of applications deployed on Runtime Fabric: - A backup and restore of Runtime Fabric - An upgrade of Runtime Fabric - OS patching of Runtime Fabric nodes ## Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Rutime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Each Mule app and API gateway replica can store up to 450 megabytes of log data on disk, after which log data is rotated to provide storage for more recent log data. Logs generated by each replica of a Mule app and API gateway are collected and written to disk on the worker node on which they are running. Each worker node runs a single log forwarding agent, which monitors this location and transmits the log data to Anypoint Monitoring. The log forwarding agent can transmit up to 300 kilobytes of log data per second. You should not deploy more than 50 replicas per worker node. In some cases, logs with multiple lines might not be fully transmitted to Anypoint Monitoring. This can occur if multiple lines of log output are split across two files due to log rotation inside Runtime Fabric. You can enable log forwarding and set log levels when you [deploy applications in Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-runtime-fabric#configure-logging-and-log-levels). ### Resource and Permission Requirements for Anypoint Monitoring Agent MuleSoft runs Anypoint Monitoring agents alongside Mule apps to send telemetry to the Anypoint control plane. For Mule apps deployed or managed using Runtime Fabric agent version 2.5.x or lower, two different agents are used as follows: - One DaemonSet per underlying node to transport logs to Anypoint monitoring control plane. - One sidecar per application replica to transporting metrics to Anypoint monitoring control plane. For optimal daemonset functionality, follow these prerequisites: 1. Check that the application containers write logs to the following locations: - `/var/log/pods` - `/var/log/containers` - `/var/lib/docker/containers` 2. Check that the DaemonSet creates and writes on the host path `/var/lib/filebeat-data`. 3. Ensure that the Docker daemon config includes the `json-file` logging driver. 4. Ensure that the Anypoint Monitoring log forwarder DaemonSet container has write access to the host on the host path `/var/lib/filebeat-data`. For applications deployed or managed using Runtime Fabric versions 2.6.x and above, MuleSoft consolidates telemetry transport to a single sidecar per application replica. Dependent on the features you use, the sidecar agent consumes corresponding resources for optimal performance: - To enable default Anypoint metrics, the sidecar agent (per application replica) requires 0.05vCPU or Core of CPU allocation and 90MiB memory allocation. - If you opt into [forwarding application logs to Anypoint Monitoring](https://docs.mulesoft.com/runtime-fabric/2.8/deploy-to-runtime-fabric#configure-logging-and-log-levels), the sidecar agent (per application replica) requires up to 30% of CPU limit configured for application replica and up to 150MiB memory allocation - If you opt into trace data generation for Mule apps, the sidecar agent (per application replica) requires up to 30% of CPU limit configured for application replica and up to 240MB memory allocation. > [!NOTE] Allocate appropriate capacity to the underlying cluster to avoid application deployment > failure. ### (Optional) Disabling Log Forwarder DeamonSet in Runtime Fabric Versions 2.6.x and Higher After you upgrade Runtime Fabric agent to version 2.6.0 or higher, all deployments use only a single sidecar for metrics and log forwarding. If you had any Mule apps running under a previous agent, redeploy them to start using the new log forwarding mechanism. Any update you perform in the control plane triggers the redeployment. After all your deployments use the new sidecar container, the `am-log-forwarder` DaemonSet just sits idle. To remove the DeamonSet completely, disable Anypoint Monitoring log forwarding using the corresponding [Anypoint Platform API call](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/runtime-fabric/minor/1.0/console/method/%232251/) sending a payload like this: \[source,json { "anypointMonitoring": false } This disabling does not impact the log forwarding to Anypoint Monitoring via the sidecar. ## Anypoint Visualizer [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/) displays views of different aspects of an application network graph. You can use the graph to explore your application network, identify problems, and make decisions. > [!WARNING] By default, Anypoint Visualizer is disabled when deploying an application to Mule > runtime 4.x. See [Enable Header Injection](https://docs.mulesoft.com/visualizer/setup#enable-header-injection) for > more information. Due to the impact on performance, enabling Anypoint Visualizer for application > deployments with less than 0.2 vCPU is not supported. ## (Optional) Disable Anypoint Monitoring for a Mule App When you deploy a Mule app to Runtime Fabric, Anypoint Monitoring is enabled by default. To disable Anypoint Monitoring, pass the following custom property when deploying your Mule app: ```copy anypoint.platform.config.analytics.agent.enabled=false ``` ## Enable Trace Data Collection > [!NOTE] This feature is available only if your organization has the Anypoint Integration Advanced > package or a Titanium subscription to Anypoint Platform. For more information, see the > [Pricing and Packaging](https://docs.mulesoft.com/general/pricing) documentation. Traces enable you to understand the path of a transaction in the MuleSoft ecosystem by providing full visibility into the execution path of API calls or application transactions. When you enable trace data collection for an app, Anypoint Platform collects and exposes tracing information from Mule runtime engine in the OpenTelemetry standard, enabling you to export it using the Anypoint Monitoring [Telemetry Exporter](https://docs.mulesoft.com/monitoring/telemetry-exporter). - You can enable trace data collection for your Runtime Fabric applications running on Mule version 4.6 or later, and the minimum Runtime Fabric agent version required is 2.6.31 or above. - You can enable trace data collection using only the Runtime Manager UI and API, but you can’t enable trace data collection using the Mule Maven plugin, Anypoint CLI, or Anypoint Studio. To enable trace data collection for an app: 1. Click the **Monitoring** tab. 2. Select the **Enable tracing** checkbox. 3. Click **Deploy Application** if you are enabling the feature for a new deployment, or **Apply Changes** if you are editing an existing application. Once you enable tracing, and redeploy your application, the Runtime Manager backend starts instrumenting traces for your application. --- product: Runtime Fabric version: 2.9 --- # Using Anypoint Monitoring > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule apps and API gateways deployed to Runtime Fabric include native support for Anypoint Monitoring that allows viewing metrics from within Anypoint Platform. ## Anypoint Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) includes tools that provide feedback from Mule flows and components in your Mule app network. Anypoint Monitoring runs as a sidecar in application deployments and gathers metrics for Mule apps and API gateways deployed to Runtime Fabric. Titanium-plan customers have access to additional capabilities, including application log retrieval and search. ## Enable Anypoint Monitoring By default, Runtime Fabric is configured to send application metrics to Anypoint Monitoring. Data is securely transmitted using mutual TLS encryption. For metrics and logs to be sent to Anypoint Monitoring, outbound network connectivity must be available. > [!NOTE] Starting with Runtime Fabric agent version 2.6.22, Anypoint Monitoring sidecar is > compatible only with HTTP-proxy instead of Monitoring SOCKS5 proxy. If you need an outbound proxy, configure Anypoint Runtime Fabric to use a SOCKS5 proxy by following the instructions in [Configuring Proxies on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/manage-proxy-self). To verify outbound network connectivity on Anypoint Runtime Fabric version 1.8.50 or later, ensure that each node in Runtime Fabric can send outbound TCP (Lumberjack) communication using port 443 to the following domains: - US control plane: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU control plane: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` > [!NOTE] If you are using a version of Anypoint Runtime Fabric older than 1.8.50, use port 5044 > instead of port 443. Use the following domains: > > - US control plane: `dias-ingestor-nginx.prod.cloudhub.io` > > - EU control plane: `dias-ingestor-nginx.prod-eu.msap.io` For further details on Anypoint Monitoring endpoints, refer to [configuring your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-self-managed-network-configuration). ## Metrics Each Mule app and API gateway replica runs a metrics agent that collects and transmits metrics data to Anypoint Monitoring via secure mutual TLS encryption. Each replica can cache up to 100 megabytes of metrics, after which the metrics data is rotated to provide storage for more recent data. If metrics can’t be sent to Anypoint Monitoring, this typically provides at least four days worth of storage per replica. Custom metrics might consume more storage. The following Anypoint Runtime Fabric updates do not impact or restore monitoring metrics of applications deployed on Runtime Fabric: - A backup and restore of Runtime Fabric - An upgrade of Runtime Fabric - OS patching of Runtime Fabric nodes ## Logs Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Rutime Fabric. To access logs with Anypoint Monitoring, you need a [Titanium subscription](https://www.mulesoft.com/anypoint-pricing). Each Mule app and API gateway replica can store up to 450 megabytes of log data on disk, after which log data is rotated to provide storage for more recent log data. Logs generated by each replica of a Mule app and API gateway are collected and written to disk on the worker node on which they are running. Each worker node runs a single log forwarding agent, which monitors this location and transmits the log data to Anypoint Monitoring. The log forwarding agent can transmit up to 300 kilobytes of log data per second. You should not deploy more than 50 replicas per worker node. In some cases, logs with multiple lines might not be fully transmitted to Anypoint Monitoring. This can occur if multiple lines of log output are split across two files due to log rotation inside Runtime Fabric. You can enable log forwarding and set log levels when you [deploy applications in Runtime Manager](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-runtime-fabric#configure-logging-and-log-levels). ### Resource and Permission Requirements for Anypoint Monitoring Agent MuleSoft runs Anypoint Monitoring agents alongside Mule apps to send telemetry to the Anypoint control plane. For Mule apps deployed or managed using Runtime Fabric agent version 2.5.x or lower, two different agents are used as follows: - One DaemonSet per underlying node to transport logs to Anypoint monitoring control plane. - One sidecar per application replica to transporting metrics to Anypoint monitoring control plane. For optimal daemonset functionality, follow these prerequisites: 1. Check that the application containers write logs to the following locations: - `/var/log/pods` - `/var/log/containers` - `/var/lib/docker/containers` 2. Check that the DaemonSet creates and writes on the host path `/var/lib/filebeat-data`. 3. Ensure that the Docker daemon config includes the `json-file` logging driver. 4. Ensure that the Anypoint Monitoring log forwarder DaemonSet container has write access to the host on the host path `/var/lib/filebeat-data`. For applications deployed or managed using Runtime Fabric versions 2.6.x and above, MuleSoft consolidates telemetry transport to a single sidecar per application replica. Dependent on the features you use, the sidecar agent consumes corresponding resources for optimal performance: - To enable default Anypoint metrics, the sidecar agent (per application replica) requires 0.05vCPU or Core of CPU allocation and 90MiB memory allocation. - If you opt into [forwarding application logs to Anypoint Monitoring](https://docs.mulesoft.com/runtime-fabric/2.9/deploy-to-runtime-fabric#configure-logging-and-log-levels), the sidecar agent (per application replica) requires up to 30% of CPU limit configured for application replica and up to 150MiB memory allocation - If you opt into trace data generation for Mule apps, the sidecar agent (per application replica) requires up to 30% of CPU limit configured for application replica and up to 240MB memory allocation. > [!NOTE] Allocate appropriate capacity to the underlying cluster to avoid application deployment > failure. ### (Optional) Disabling Log Forwarder DeamonSet in Runtime Fabric Versions 2.6.x and Higher After you upgrade Runtime Fabric agent to version 2.6.0 or higher, all deployments use only a single sidecar for metrics and log forwarding. If you had any Mule apps running under a previous agent, redeploy them to start using the new log forwarding mechanism. Any update you perform in the control plane triggers the redeployment. After all your deployments use the new sidecar container, the `am-log-forwarder` DaemonSet just sits idle. To remove the DeamonSet completely, disable Anypoint Monitoring log forwarding using the corresponding [Anypoint Platform API call](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/runtime-fabric/minor/1.0/console/method/%232251/) sending a payload like this: \[source,json { "anypointMonitoring": false } This disabling does not impact the log forwarding to Anypoint Monitoring via the sidecar. ## Anypoint Visualizer [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/) displays views of different aspects of an application network graph. You can use the graph to explore your application network, identify problems, and make decisions. > [!WARNING] By default, Anypoint Visualizer is disabled when deploying an application to Mule > runtime 4.x. See [Enable Header Injection](https://docs.mulesoft.com/visualizer/setup#enable-header-injection) for > more information. Due to the impact on performance, enabling Anypoint Visualizer for application > deployments with less than 0.2 vCPU is not supported. ## (Optional) Disable Anypoint Monitoring for a Mule App When you deploy a Mule app to Runtime Fabric, Anypoint Monitoring is enabled by default. To disable Anypoint Monitoring, pass the following custom property when deploying your Mule app: ```copy anypoint.platform.config.analytics.agent.enabled=false ``` ## Enable Trace Data Collection > [!NOTE] This feature is available only if your organization has the Anypoint Integration Advanced > package or a Titanium subscription to Anypoint Platform. For more information, see the > [Pricing and Packaging](https://docs.mulesoft.com/general/pricing) documentation. Traces enable you to understand the path of a transaction in the MuleSoft ecosystem by providing full visibility into the execution path of API calls or application transactions. When you enable trace data collection for an app, Anypoint Platform collects and exposes tracing information from Mule runtime engine in the OpenTelemetry standard, enabling you to export it using the Anypoint Monitoring [Telemetry Exporter](https://docs.mulesoft.com/monitoring/telemetry-exporter). - You can enable trace data collection for your Runtime Fabric applications running on Mule version 4.6 or later, and the minimum Runtime Fabric agent version required is 2.6.31 or above. - You can enable trace data collection using only the Runtime Manager UI and API, but you can’t enable trace data collection using the Mule Maven plugin, Anypoint CLI, or Anypoint Studio. To enable trace data collection for an app: 1. Click the **Monitoring** tab. 2. Select the **Enable tracing** checkbox. 3. Click **Deploy Application** if you are enabling the feature for a new deployment, or **Apply Changes** if you are editing an existing application. Once you enable tracing, and redeploy your application, the Runtime Manager backend starts instrumenting traces for your application. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Using Anypoint Monitoring with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric includes native support for [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/), which collects and exposes metrics, logs, and traces for Mule apps and API gateways deployed to Runtime Fabric. Metrics collection is enabled by default for all plans. Log and trace collection require an [Anypoint Platform Integration Advanced](https://www.mulesoft.com/anypoint-pricing) subscription. ## Before You Begin ### Verify Network Connectivity For metrics, logs, and traces to reach Anypoint Monitoring, each node in Runtime Fabric must be able to send outbound traffic to the control plane ingestion endpoint for your region. For Runtime Fabric agent version 2.6.22 and later, the monitoring sidecar sends HTTPS traffic on TCP port 443 to these domains: - US Cloud: `us1.ingest.mulesoft.com` - EU Cloud: `eu1.ingest.mulesoft.com` - Canada Cloud (port 8443, OTEL): `ingest.ca1.platform.mulesoft.com` - Japan Cloud (port 8443, OTEL): `ingest.jp1.platform.mulesoft.com` - India Cloud (port 8443, OTEL): `ingest.in1.platform.mulesoft.com` - Australia Cloud (port 8443, OTEL): `ingest.au1.platform.mulesoft.com` - United Kingdom Cloud (port 8443, OTEL): `ingest.gb1.platform.mulesoft.com` > [!NOTE] For Runtime Fabric versions earlier than 2.6.22, the agent sends TCP (Lumberjack) traffic > on port 443 to a different domain. After you upgrade to 2.6.22 or later and redeploy all > applications, these domains are no longer used: > > - US Cloud: `dias-ingestor-router.us-east-1.prod.cloudhub.io` > > - EU Cloud: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` > > For Runtime Fabric versions earlier than 1.8.50, use port 5044 (TCP Lumberjack) and these domains: > > - US Cloud: `dias-ingestor-nginx.prod.cloudhub.io` > > - EU Cloud: `dias-ingestor-nginx.prod-eu.msap.io` For the full list of required endpoints, see [Configure Network for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration). If your cluster uses an outbound proxy, configure Runtime Fabric to route monitoring traffic through it. See [Configure Proxies on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/manage-proxy-self). > [!NOTE] Starting with Runtime Fabric agent version 2.6.22, the Anypoint Monitoring sidecar > supports HTTP proxy only. SOCKS5 proxy is not supported for monitoring traffic. ### Review Subscription Requirements
FeatureSubscription required

Metrics

All plans

Logs

Anypoint Platform Integration Advanced

Traces

Anypoint Platform Integration Advanced

## Collect Metrics Metrics collection is automatic. When a Mule app or API gateway replica is deployed to Runtime Fabric, a monitoring sidecar is deployed alongside it and begins transmitting metrics data to Anypoint Monitoring via mutual TLS encryption. Each replica caches up to 100 MB of metrics data. If the connection to Anypoint Monitoring is interrupted, the cache typically provides at least four days of storage per replica before data is rotated. Custom metrics may consume cache faster. These Runtime Fabric operations do not affect or restore existing metrics data: - Backup and restore - Runtime Fabric upgrade - OS patching of nodes ## Enable and Configure Log Forwarding Log forwarding requires an [Anypoint Platform Integration Advanced](https://www.mulesoft.com/anypoint-pricing) subscription. When enabled, Anypoint Monitoring provides access to [log data](https://docs.mulesoft.com/monitoring/logs) for applications deployed to Runtime Fabric. To enable log forwarding for a Mule app: 1. In Runtime Manager, open the application and click the **Logging** tab. 2. Select the **Enable application logs** option. 3. Select the log level from the drop-down list: - **INFO**: Informative messages - **DEBUG**: Debugging messages - **WARNING**: Warning messages - **ERROR**: Error messages, such as when an exception occurs - **FATAL**: Fatal messages for when an application fails 4. Optionally, set the log level for a specific Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key. 5. Click **Apply Changes**. ### Log Storage and Throughput Each replica stores up to 450 MB of log data on disk. When the limit is reached, older log data is rotated to make room for new entries. The log forwarding sidecar can transmit up to 300 KB of log data per second per replica. In some cases, multi-line log entries may not be fully transmitted. This can occur when multiple lines are split across two files during log rotation inside Runtime Fabric. ### Log Forwarding Architecture Starting with Runtime Fabric agent version 3.0.0, logs are forwarded exclusively through a sidecar container deployed alongside each application replica. This replaces the previous DaemonSet-based approach and provides better isolation and resource management. > [!NOTE] If you are upgrading from Runtime Fabric agent version 2.11.x or earlier, you must > complete migration steps before upgrading to version 3.0.0. See > [Migrate Log Forwarding Before Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/migrate-log-forwarding). ## Enable Trace Data Collection > [!NOTE] This feature is available only if your organization has the Anypoint Integration Advanced > package or a Titanium subscription to Anypoint Platform. For more information, see the > [Pricing and Packaging](https://docs.mulesoft.com/general/pricing) documentation. Traces provide full visibility into the execution path of API calls and application transactions. When enabled, Anypoint Platform collects tracing information from Mule runtime engine in the OpenTelemetry standard, which you can export using the Anypoint Monitoring [Telemetry Exporter](https://docs.mulesoft.com/monitoring/telemetry-exporter). ### Prerequisites for Traces - Mule runtime version 4.6 or later - Runtime Fabric agent version 2.6.31 or later - Traces can only be enabled using the Runtime Manager UI or API. The Mule Maven plugin, Anypoint CLI, and Anypoint Studio are not supported. ### Enable Tracing for an App 1. In Runtime Manager, open the application. 2. Click the **Monitoring** tab. 3. Select the **Enable tracing** checkbox. 4. Click **Deploy Application** for a new deployment, or **Apply Changes** for an existing application. After redeployment, the Runtime Manager backend begins instrumenting traces for the application. ## Allocate Resources for the Monitoring Sidecar Starting with Runtime Fabric agent version 3.0.0, all telemetry — metrics, logs, and traces — is transported through a single sidecar container deployed per application replica. Allocate cluster capacity accordingly to avoid deployment failures. Resource requirements per replica depend on which features are enabled:
FeatureCPUMemory

Metrics only

0.05 vCPU

90 MiB

Metrics + logs

Up to 30% of the app replica’s CPU limit

Up to 150 MiB

Metrics + logs + traces

Up to 30% of the app replica’s CPU limit

Up to 240 MiB

### Legacy Architecture (Runtime Fabric Agent 2.11.x and Earlier) In Runtime Fabric agent version 2.11.x and earlier, two separate agents handled telemetry: - One DaemonSet per node to forward logs - One sidecar per replica to forward metrics This architecture was replaced by the single-sidecar model in version 3.0.0. ## Disable Anypoint Monitoring Anypoint Monitoring is enabled by default. To disable it for a specific Mule app, pass this property at deployment time: ```bash anypoint.platform.config.analytics.agent.enabled=false ``` > [!NOTE] Disable monitoring only if your team or organization has compliance or geospecific > requirements that prevent sending metrics to the Anypoint control plane, and you are not > contractually obligated to send metrics for usage and billing purposes. ## See Also - [Monitoring Applications Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/manage-monitor-applications) - [Configure Logging and Log Levels](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric#configure-logging-and-log-levels) - [Migrate Log Forwarding Before Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/migrate-log-forwarding) - [Configure Network for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration) --- product: Runtime Fabric version: 2.5 --- # Using Persistence Gateway with Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric provides Persistence Gateway, which enables Mule applications deployed to a Mule runtime instance to store and share data across application replicas and restarts. > [!NOTE] You can also use the Mule Maven plugin version 3.5.4 or later to enable persistent object > stores for Runtime Fabric deployments. ## Using Persistence Gateway in a Mule Application After Persistence Gateway is configured in Anypoint Runtime Fabric, it is available for Mule applications deployed to Mule runtime engine, version 4.2.1 or later. When configured, users can select **Use Persistent Object Storage** when deploying an application using Runtime Manager. See [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-to-runtime-fabric) for more information. Mule applications use the Object Store v2 REST API via the Object Store Connector to connect to Persistence Gateway. This enables you to deploy to both Anypoint Runtime Fabric and CloudHub without having to modify your Mule application. > [!NOTE] After deleting an application, persistent data may not be deleted immediately. Runtime > Fabric cleans persistence data every 60 minutes. ## Persistent Gateway Limits The following table lists the limits on the data stored by Persistence Gateway:
LimitDescription

Maximum TTL.

The amount of time data is stored in Persistence Gateway, value is set to 30 days.

## Before You Begin Before enabling Persistence Gateway, ensure that you have: - Created a PostgreSQL database to serve as the data source for data stored by Persistence Gateway. This database must be compatible with a [supported version of PostgreSQL](https://www.postgresql.org/support/versioning/) that does not reserve the `partition` keyword. - Granted the PostgreSQL user CREATE, INSERT, SELECT, UPDATE, and DELETE privileges. > [!NOTE] Only plain text connections to the database are supported. ## Configure Persistence Gateway During configuration, Persistence Gateway creates the required database schema. Afterwards, when an application deployed to Runtime Fabric is configured to use persistent object storage, the Persistence Gateway writes the necessary rows to the database. To configure Persistence Gateway, you must create a Kubernetes custom resource that allows the cluster to connect to your persistence data store. 1. Create a Kubernetes secret: kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename' > [!IMPORTANT] > > - Do not change `--from-literal=persistence-gateway-creds`. You can replace `` > with any value you want to use for the secret. > > - Do not use the "@" character in the database username. > > - If your PostgresSQL user account password contains special characters, make sure to encode > your connection URL before pushing it as Kubernetes secret. 2. Create a custom resource for your data store: 1. Copy the custom resource template from [Kubernetes Custom Resource Template](#k8-custom-resource-template) to a file called `custom-resource.yaml`. 2. Ensure the value of `secretRef: name` matches the `name` field defined in your Kubernetes secret file. 3. Modify other fields of the custom resource template as required for your environment. 4. Run `kubectl apply -f custom-resource.yaml`. 3. Check the logs of the Persistence Gateway pod to ensure it can communicate with the database: ```copy kubectl get pods -n rtf ``` Look for pods with the name prefix `persistence-gateway` ```copy kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -n rtf ``` The output of this command should be similar to the following: 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## Persistence Gateway with Authorized Namespaces If you use [authorized namespace](https://docs.mulesoft.com/runtime-fabric/2.5/install-helm#optional-configure-authorized-namespaces) and want to use persistence gateway, edit the RoleBinding by adding a new `rtf-persistence-gateway` subject: ```copy subjects: - kind: ServiceAccount name: rtf-persistence-gateway namespace: ``` ## Kubernetes Custom Resource Template Use the example template below to create a Kubernetes custom resource. This custom resource enables the Kubernetes cluster to connect to your data store. ```yaml apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi ``` Modify the following fields based on your environment:
FieldDescriptionDefault Value

kind

The type of custom resource. The only supported value is PersistenceGateway.

PersistenceGateway

metadata.name

The internal identifier for this custom resource. The value for this field should be default.

default

metadata.namespace

The namespace where the secret is applied. The supported value is rtf.

rtf

spec.objectStore.backendDriver

The driver used by the data store. Only postgresql is supported.

postgresql

spec.objectStore.maxBackendConnectionPool

The maximum number of simultaneous open connections to the data store.

20

spec.objectStore.replicas

The number of replicas of Persistence Gateway.

2

spec.objectStore.resources.limits.cpu

The CPU resource limits for the Persistence Gateway pods.

250m

spec.objectStore.resources.limits.memory

The memory resource limits for the Persistence Gateway pods.

150Mi

spec.objectStore.resources.requests.cpu

The CPU resource requests for the Persistence Gateway pods.

200m

spec.objectStore.resources.requests.memory

The memory resource requests for the Persistence Gateway pods.

75Mi

spec.objectStore.secretRef.name

The name of the Persistence Gateway credentials defined in the Kubernetes secret file.

persistence-gateway-creds

> [!NOTE] The default CPU, memory, and limit values are based on a small number of deployed Mule > applications. Modify these values based on the requirements of your environment. ## Persistence Gateway Application Data Persistence Gateway stores application data using the following two tables: ```copy CREATE TABLE IF NOT EXISTS stores ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, org_id VARCHAR(255) NOT NULL, env_id VARCHAR(255) NOT NULL, default_ttl_seconds int NOT NULL, is_fixed_ttl bool NOT NULL, CONSTRAINT UK_stores UNIQUE (name, org_id, env_id) ); CREATE TABLE IF NOT EXISTS items ( id SERIAL PRIMARY KEY, store_id INT NOT NULL REFERENCES stores(id), key VARCHAR(255) NOT NULL, partition VARCHAR(255) NOT NULL, value_type VARCHAR(10) NOT NULL, number_value integer, string_value text, binary_value bytea, last_updated timestamp, is_fixed_ttl bool NOT NULL, ttl timestamp NOT NULL, CONSTRAINT UK_items UNIQUE (key, store_id, partition) ); CREATE INDEX IF NOT EXISTS IDX_items_ttl ON items(ttl) ; ``` To migrate the persistent data from one cluster to another, backup these two tables entirely from the source cluster and recreate them on the target one database. Do not to have applications deployed during this process on both clusters to prevent unexpected results. ## See Also - [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/deploy-to-runtime-fabric) - [Deploy Applications to Runtime Fabric Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) --- product: Runtime Fabric version: 2.10 --- # Using RTFCTL for Deployed Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can manage deployed Mule apps to Runtime Fabric using the `rtfctl` command line tool. - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl#manage-rtfctl-apps) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`, and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Protecting Mule App Property Values](https://docs.mulesoft.com/runtime-fabric/2.10/manage-secure-properties) Use the `rtfctl apply`, `get`, and `delete` commands to protect Mule app property values. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl-rtf) --- product: Runtime Fabric version: 2.11 --- # Using RTFCTL for Deployed Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can manage deployed Mule apps to Runtime Fabric using the `rtfctl` command line tool. - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/manage-apps-rtfctl) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`, and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Protecting Mule App Property Values](https://docs.mulesoft.com/runtime-fabric/2.11/manage-secure-properties) Use the `rtfctl apply`, `get`, and `delete` commands to protect Mule app property values. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl-rtf) --- product: Runtime Fabric version: 2.6 --- # Using RTFCTL for Deployed Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can manage deployed Mule apps to Runtime Fabric using the `rtfctl` command line tool. - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl#manage-rtfctl-apps) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`, and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Protecting Mule App Property Values](https://docs.mulesoft.com/runtime-fabric/2.6/manage-secure-properties) Use the `rtfctl apply`, `get`, and `delete` commands to protect Mule app property values. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/using-rtfctl-rtf) --- product: Runtime Fabric version: 2.7 --- # Using RTFCTL for Deployed Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can manage deployed Mule apps to Runtime Fabric using the `rtfctl` command line tool. - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl#manage-rtfctl-apps) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`, and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Protecting Mule App Property Values](https://docs.mulesoft.com/runtime-fabric/2.7/manage-secure-properties) Use the `rtfctl apply`, `get`, and `delete` commands to protect Mule app property values. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/using-rtfctl-rtf) --- product: Runtime Fabric version: 2.8 --- # Using RTFCTL for Deployed Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can manage deployed Mule apps to Runtime Fabric using the `rtfctl` command line tool. - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl#manage-rtfctl-apps) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`, and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Protecting Mule App Property Values](https://docs.mulesoft.com/runtime-fabric/2.8/manage-secure-properties) Use the `rtfctl apply`, `get`, and `delete` commands to protect Mule app property values. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/using-rtfctl-rtf) --- product: Runtime Fabric version: 2.9 --- # Using RTFCTL for Deployed Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can manage deployed Mule apps to Runtime Fabric using the `rtfctl` command line tool. - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl#manage-rtfctl-apps) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`, and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Protecting Mule App Property Values](https://docs.mulesoft.com/runtime-fabric/2.9/manage-secure-properties) Use the `rtfctl apply`, `get`, and `delete` commands to protect Mule app property values. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl-rtf) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Using RTFCTL for Deployed Mule Apps to Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can manage deployed Mule apps to Runtime Fabric using the `rtfctl` command line tool. - [Managing Mule Apps Deployed to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/manage-apps-rtfctl) Use the `rtfctl delete`, `describe`, `disk`, `memory`, `package`, `restart`, `heapdump`, and `threaddump` commands to manage Mule apps deployed to Runtime Fabric. - [Protecting Mule App Property Values](https://docs.mulesoft.com/runtime-fabric/latest/manage-secure-properties) Use the `rtfctl apply`, `get`, and `delete` commands to protect Mule app property values. ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl-rtf) --- product: Runtime Fabric version: 2.10 --- # Using RTFCTL for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you set up the `rtfctl` command line tool, use `rtfctl` commands to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can replace a Mule license key. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/install-self-managed) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/configure-rtf-rtfctl) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/upgrade-self-managed) - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/manage-backup-restore) - [Troubleshooting Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/troubleshoot-rtf-rtfctl) - [Uninstall Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/uninstall-rtf-rtfctl) - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.10/replace-license-key) ## See Also - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 2.11 --- # Using RTFCTL for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you set up the `rtfctl` command line tool, use `rtfctl` commands to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can replace a Mule license key. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-self-managed) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/configure-rtf-rtfctl) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/upgrade-self-managed) - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/manage-backup-restore) - [Troubleshooting Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/troubleshoot-rtf-rtfctl) - [Uninstall Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/uninstall-rtf-rtfctl) - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.11/replace-license-key) ## See Also - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 2.6 --- # Using RTFCTL for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you set up the `rtfctl` command line tool, use `rtfctl` commands to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can replace a Mule license key. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-self-managed) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl#configure-rtfctl) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/uninstall-self#unistall-rtfctl-rtf) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/upgrade-self-managed) - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/manage-backup-restore) - [Troubleshooting Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl#troubleshooting-rtfctl) - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.6/replace-license-key) ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl) - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/2.6/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 2.7 --- # Using RTFCTL for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you set up the `rtfctl` command line tool, use `rtfctl` commands to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can replace a Mule license key. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-self-managed) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl#configure-rtfctl) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/uninstall-self#unistall-rtfctl-rtf) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/upgrade-self-managed) - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/manage-backup-restore) - [Troubleshooting Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl#troubleshooting-rtfctl) - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.7/replace-license-key) ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl) - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/2.7/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 2.8 --- # Using RTFCTL for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you set up the `rtfctl` command line tool, use `rtfctl` commands to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can replace a Mule license key. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-self-managed) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl#configure-rtfctl) - [Uninstalling Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/uninstall-self#unistall-rtfctl-rtf) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/upgrade-self-managed) - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-backup-restore) - [Troubleshooting Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl#troubleshooting-rtfctl) - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.8/replace-license-key) ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/2.8/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 2.9 --- # Using RTFCTL for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you set up the `rtfctl` command line tool, use `rtfctl` commands to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can replace a Mule license key. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/install-self-managed) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/configure-rtf-rtfctl) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/upgrade-self-managed) - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/manage-backup-restore) - [Troubleshooting Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/troubleshoot-rtf-rtfctl) - [Uninstall Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/uninstall-rtf-rtfctl) - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/2.9/replace-license-key) ## See Also - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Using RTFCTL for Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you set up the `rtfctl` command line tool, use `rtfctl` commands to install, configure, upgrade, uninstall, troubleshoot, back up, and restore Runtime Fabric. Additionally, you can replace a Mule license key. - [Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed) - [Configuring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/configure-rtf-rtfctl) - [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-self-managed) - [Backing Up and Restoring Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/manage-backup-restore) - [Troubleshooting Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/troubleshoot-rtf-rtfctl) - [Uninstall Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/uninstall-rtf-rtfctl) - [Replacing a Mule License Key](https://docs.mulesoft.com/runtime-fabric/latest/replace-license-key) ## See Also - [Using RTFCTL for Deployed Mule apps](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl-mule-apps) --- product: Runtime Fabric version: 2.10 --- # Using RTFCTL Tool Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The `rtfctl` command line tool enables you to locally manage Runtime Fabrics. Using `rtfctl` you can perform the following actions: - Install, configure, and troubleshoot Runtime Fabrics - Get the status of a Runtime Fabric - Perform a heap dump or a thread dump of a running application - Display memory usage of a running Mule app - Manage proxy settings - Manage secure properties - Manage a Mule license - Manage the alert sender email address ## Before You Begin Using RTFCTL Before you start using `rtfctl`, see the following topic to enable `rtfctl` Kubernetes permissions and install the `rtfctl` command line tool. - [Setting Up RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.10/setting-up-rtfctl) ## Next Steps After you install the command line tool, you can start using `rtfctl` commands to install and manage Runtime Fabric and manage Mule apps deployed to Runtime Fabric. - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule Apps](https://docs.mulesoft.com/runtime-fabric/2.10/using-rtfctl-mule-apps) ## See Also - [Install the Runtime Fabric Command Line Tool](https://docs.mulesoft.com/runtime-fabric/2.10/install-rtfctl) --- product: Runtime Fabric version: 2.11 --- # Using RTFCTL Tool Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The `rtfctl` command line tool enables you to locally manage Runtime Fabrics. Using `rtfctl` you can perform these actions: - Install, configure, and troubleshoot Runtime Fabrics - Get the status of a Runtime Fabric - Perform a heap dump or a thread dump of a running application - Display memory usage of a running Mule app - Manage proxy settings - Manage secure properties - Manage a Mule license - Manage the alert sender email address ## Before You Begin Using RTFCTL Before you start using `rtfctl`, see this topic to enable `rtfctl` Kubernetes permissions and install the `rtfctl` command line tool. - [Setting Up RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.11/setting-up-rtfctl) ## Next Steps After you install the command line tool, you can start using `rtfctl` commands to install and manage Runtime Fabric and manage Mule apps deployed to Runtime Fabric. - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule Apps](https://docs.mulesoft.com/runtime-fabric/2.11/using-rtfctl-mule-apps) ## See Also - [Install the Runtime Fabric Command Line Tool](https://docs.mulesoft.com/runtime-fabric/2.11/install-rtfctl) --- product: Runtime Fabric version: 2.6 --- # Using RTFCTL Tool Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The `rtfctl` command line tool enables you to locally manage Runtime Fabrics. Using `rtfctl` you can perform the following actions: - Get the status of a Runtime Fabric - Perform a heap dump or a thread dump of a running application - Display memory usage of a running application - Manage proxy settings - Manage secure properties - Manage a Mule license - Manage the alert sender email address ## Before You Begin Using RTFCTL Before you start using `rtfctl`, see the following topic to enable `rtfctl` Kubernetes permissions and install the `rtfctl` command line tool. - [Setting Up RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.6/setting-up-rtfctl) ## Next Steps After you install the command line tool, you can start using `rtfctl` commands to install and manage Runtime Fabric and manage Mule apps deployed to Runtime Fabric. - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule Apps](https://docs.mulesoft.com/runtime-fabric/2.6/using-rtfctl-mule-apps) ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.6/install-rtfctl) --- product: Runtime Fabric version: 2.7 --- # Using RTFCTL Tool Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The `rtfctl` command line tool enables you to locally manage Runtime Fabrics. Using `rtfctl` you can perform the following actions: - Get the status of a Runtime Fabric - Perform a heap dump or a thread dump of a running application - Display memory usage of a running application - Manage proxy settings - Manage secure properties - Manage a Mule license - Manage the alert sender email address ## Before You Begin Using RTFCTL Before you start using `rtfctl`, see the following topic to enable `rtfctl` Kubernetes permissions and install the `rtfctl` command line tool. - [Setting Up RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.7/setting-up-rtfctl) ## Next Steps After you install the command line tool, you can start using `rtfctl` commands to install and manage Runtime Fabric and manage Mule apps deployed to Runtime Fabric. - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule Apps](https://docs.mulesoft.com/runtime-fabric/2.7/using-rtfctl-mule-apps) ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.7/install-rtfctl) --- product: Runtime Fabric version: 2.8 --- # Using RTFCTL Tool Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The `rtfctl` command line tool enables you to locally manage Runtime Fabrics. Using `rtfctl` you can perform the following actions: - Get the status of a Runtime Fabric - Perform a heap dump or a thread dump of a running application - Display memory usage of a running application - Manage proxy settings - Manage secure properties - Manage a Mule license - Manage the alert sender email address ## Before You Begin Using RTFCTL Before you start using `rtfctl`, see the following topic to enable `rtfctl` Kubernetes permissions and install the `rtfctl` command line tool. - [Setting Up RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.8/setting-up-rtfctl) ## Next Steps After you install the command line tool, you can start using `rtfctl` commands to install and manage Runtime Fabric and manage Mule apps deployed to Runtime Fabric. - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule Apps](https://docs.mulesoft.com/runtime-fabric/2.8/using-rtfctl-mule-apps) ## See Also - [RTFCTL Reference](https://docs.mulesoft.com/runtime-fabric/2.8/install-rtfctl) --- product: Runtime Fabric version: 2.9 --- # Using RTFCTL Tool Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The `rtfctl` command line tool enables you to locally manage Runtime Fabrics. Using `rtfctl` you can perform the following actions: - Install, configure, and troubleshoot Runtime Fabrics - Get the status of a Runtime Fabric - Perform a heap dump or a thread dump of a running application - Display memory usage of a running Mule app - Manage proxy settings - Manage secure properties - Manage a Mule license - Manage the alert sender email address ## Before You Begin Using RTFCTL Before you start using `rtfctl`, see the following topic to enable `rtfctl` Kubernetes permissions and install the `rtfctl` command line tool. - [Setting Up RTFCTL](https://docs.mulesoft.com/runtime-fabric/2.9/setting-up-rtfctl) ## Next Steps After you install the command line tool, you can start using `rtfctl` commands to install and manage Runtime Fabric and manage Mule apps deployed to Runtime Fabric. - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule Apps](https://docs.mulesoft.com/runtime-fabric/2.9/using-rtfctl-mule-apps) ## See Also - [Install the Runtime Fabric Command Line Tool](https://docs.mulesoft.com/runtime-fabric/2.9/install-rtfctl) --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Using RTFCTL Tool Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The `rtfctl` command line tool enables you to locally manage Runtime Fabrics. Using `rtfctl` you can perform the following actions: - Install, configure, and troubleshoot Runtime Fabrics - Get the status of a Runtime Fabric - Perform a heap dump or a thread dump of a running application - Display memory usage of a running Mule app - Manage proxy settings - Manage secure properties - Manage a Mule license - Manage the alert sender email address ## Before You Begin Using RTFCTL Before you start using `rtfctl`, see the following topic to enable `rtfctl` Kubernetes permissions and install the `rtfctl` command line tool. - [Setting Up RTFCTL](https://docs.mulesoft.com/runtime-fabric/latest/setting-up-rtfctl) ## Next Steps After you install the command line tool, you can start using `rtfctl` commands to install and manage Runtime Fabric and manage Mule apps deployed to Runtime Fabric. - [Using RTFCTL for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl-rtf) - [Using RTFCTL for Deployed Mule Apps](https://docs.mulesoft.com/runtime-fabric/latest/using-rtfctl-mule-apps) ## See Also - [Install the Runtime Fabric Command Line Tool](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) --- product: Runtime Fabric version: 2.5 --- # Using the Runtime Fabric Command Line Tool > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Install and use the `rtfctl` command line tool to locally manage Runtime Fabrics. The `rtfctl` tool supports the following actions: - Get the status of a Runtime Fabric. - Perform a heap dump or a thread dump of a running application. - Display memory usage of a running application. - Manage proxy settings. - Manage secure properties. - Manage a Mule license. - Manage the alert sender email address. If you are using the default namespace (rtf), you do not need to specify the additional flag `--namespace `. Note that this flag is introduced only as of rtfctl version 0.4.1. ## Install rtfctl > [!IMPORTANT] The tasks in the section must be performed by an IT administrator. > > If you’re using Runtime Fabric for AKS and have the AKS-managed Azure AD integration enabled, the > following command returns the credentials needed to run rtfctl commands: > > `az aks get-credentials --name --resource-group --admin` 1. Download the `rtfctl` command-line tool: `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Choose the appropriate method: - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. Change file permissions for the `rtfctl` command-line tool: chmod +x rtfctl ### Running Commands The `rtfctl` command line tool consumes kubeconfig files as described in [Organizing Cluster Access Using kubeconfig Files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Use this method to configure which cluster you want to manage. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. - Run `rtfctl` commands as a privileged user. - To list all supported commands, run `rtfctl -h`. - For more information about a specific command, run `rtfctl -h`. ### Checking for Proxy Settings When you run commands, `rtfctl` checks for any proxy settings in your environment. The tool looks for a `NO_PROXY` key (in upper case) and will accept a `no_proxy` key (in lower case) if `NO_PROXY` is not used. If both keys are present, `rtfctl` uses `NO_PROXY`. The `rtfctl` tool sets the key in your local Kubernetes context to honor your proxy settings. ## Commands for Configuring Runtime Fabric Use the following commands to configure Runtime Fabric.
CommandDescription

Applies changes to a Runtime Fabric configuration

Updates rtfctl

Waits for Runtime Fabric components to become ready

### `apply` Applies changes to a Runtime Fabric configuration. > [!NOTE] You can use the `rtfctl apply system-configuration` command to update OpenShift > system-configuration values. Other rtfctl apply commands are not effective for OpenShift. For any > other updates, modify the values in the OpenShift console. - Applies an HTTP proxy configuration rtfctl apply http-proxy http://: --namespace - Applies an HTTP proxy configuration with hostnames bypassing the proxy rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - Applies an HTTP proxy configuration with authentication rtfctl apply http-proxy http://:@: --namespace - Clears an HTTP proxy configuration rtfctl apply http-proxy "" --no-proxy "" --namespace - Applies a secure property rtfctl apply secure-property --key --value --app-namespace --namespace - Applies a system configuration on a host node rtfctl apply system-configuration - Applies a system configuration on a host node without downloading the latest scripts rtfctl apply system-configuration --skip-download - Applies a Mule license rtfctl apply mule-license --namespace - Applies a monitoring proxy rtfctl apply monitoring-proxy http://: --namespace - Clears a monitoring proxy configuration rtfctl apply monitoring-proxy "" --namespace ### `update` Updates `rtfctl`. - Updates from the US control plane rtfctl update - Updates `rtfctl` from the EU control plane rtfctl update --host eu1.anypoint.mulesoft.com ### `wait` Waits for Runtime Fabric components to become ready - Specifies the number of seconds to wait rtfctl wait --namespace - Specifies the number of seconds to pass before timing out the wait (Default is 600 seconds) rtfctl wait --timeout --namespace ## Commands for Installing and Upgrading Runtime Fabric Use the following commands when installing or upgrading Runtime Fabric, or when performing a back up or restore.
CommandDescription

Installs Runtime Fabric

Performs a back up of the local Runtime Fabric state

Restores local Runtime Fabric state from a backup

Validates the cluster for Runtime Fabric installation

Displays the Runtime Fabric version information

### `install` - Installs Runtime Fabric rtfctl install - Override the Docker image registry URL and secret rtfctl install --image-pull-registry --image-pull-secret ### `backup` Performs a back up of the local Runtime Fabric state. rtfctl backup .tar.gz --namespace ### `restore` Restores the local Runtime Fabric state from a backup rtfctl restore .tar.gz --namespace ### `validate` Validates the cluster for a Runtime Fabric installation - Performs a validation check rtfctl validate - Performs a validation check and passes the `fabric.tf` configuration file that contains proxy settings rtfctl validate -f To validate installation with a proxy, you must specify proxy settings in your `settings` file: MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://.com: - Override the Docker image registry URL and secret rtfctl validate --image-pull-registry --image-pull-secret ### `version` Displays the Runtime Fabric version information rtfctl version --namespace ## Commands for Managing Applications on Runtime Fabric Use the following commands to manage applications deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays disk usage for an application

Restarts an application

### `delete` Deletes a secure property rtfctl delete secure-property -n ### `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ### `restart` Restarts an application rtfctl restart --app-namespace --namespace ## Commands for Troubleshooting Runtime Fabric Use the following commands to troubleshoot Runtime Fabric.
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

### `get` Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ### `ping` Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ### `report` Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all ### `status` Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ### `test` Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## Usage ### Install a Mule license 1. Make sure to base64 encode the license. 2. Run the following command: ./rtfctl apply mule-license '' --namespace rtf1 Updating rtf namespace... OK ### Capture a Heap Dump /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof --app-namespace bed42b62-XXXX --namespace rtf1 Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof For additional information, run the `rtfctl heapdump -h` command. ### Working with Multiple Replicas For application management commands that accept a `--pod` flag, you can obtain the list of replicas using the `describe` command: ./rtfctl describe apps hello-world --app-namespace bed42b62-XXXX --namespace rtf1 Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status --- hello-world-77f5897949-z54gb Pending ## Auditing rtfctl Operations The `rtfctl` command line tool (from v1.0.29 and above) audits the `rtfctl` operations on the cluster and it helps cluster administrators and you to track operations that impact Runtime Fabric core software. Consider the following points: - Audit logs are stored in a Kubernetes secret in the `rtfctl-audit` namespace. - Audit logs are cluster scoped and not attached to Runtime Fabric core software lifecycle. - Command executions remain operational even if the auditing process fails to audit the operation. To audit the operations, run the following command: ./rtfctl audit-logs An output example: \[{"timestamp":"2023-10-26 00:52:24.446 +0000 UTC","kubeContext":"test-k8scontext","command":\["./rtfctl","restart","test-application","--app-namespace","8456f9c7-2149-4983-b02b-6b18ddd28efe","--namespace","rtf"\]}\] > [!NOTE] Currently audit logs rollover or rotation is not supported. ## Understanding rtfctl Output The `rtfctl` command line tool commonly calls other applications and system tools, and the output of those calls is sent to standard output and standard error output. This output is written in the context of each operation performed. The `rtfctl` command line tool includes a last output line on the most verbose commands to make it clear whether the operation succeed or failed. Normal operation may include some intermediate _failure_ messages, such as when a stopped system unit is attempted to be stopped again. If you are in doubt about whether a message represents a problem or not, discuss it with your system administrator or contact MuleSoft support. ## Download Previous rtfctl CLI Versions Use the following rest API call to download different rtfctl tool CLI versions: curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/{version} -o rtfctl ## See Also - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/manage-proxy-self) - [Manage Secure Properties in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.5/manage-secure-properties) --- product: Runtime Fabric version: 2.6 --- # Using the Runtime Fabric Command Line Tool > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Install and use the `rtfctl` command line tool to locally manage Runtime Fabrics. The `rtfctl` tool supports the following actions: - Get the status of a Runtime Fabric. - Perform a heap dump or a thread dump of a running application. - Display memory usage of a running application. - Manage proxy settings. - Manage secure properties. - Manage a Mule license. - Manage the alert sender email address. If you are using the default namespace (rtf), you do not need to specify the additional flag `--namespace `. Note that this flag is introduced only as of rtfctl version 0.4.1. ## Install rtfctl > [!IMPORTANT] The tasks in the section must be performed by an IT administrator. > > If you’re using Runtime Fabric for AKS and have the AKS-managed Azure AD integration enabled, the > following command returns the credentials needed to run rtfctl commands: > > `az aks get-credentials --name --resource-group --admin` 1. Download the `rtfctl` command-line tool: `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Choose the appropriate method: - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. Change file permissions for the `rtfctl` command-line tool: chmod +x rtfctl ### Running Commands The `rtfctl` command line tool consumes kubeconfig files as described in [Organizing Cluster Access Using kubeconfig Files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Use this method to configure which cluster you want to manage. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. - Run `rtfctl` commands as a privileged user. - To list all supported commands, run `rtfctl -h`. - For more information about a specific command, run `rtfctl -h`. ### Checking for Proxy Settings When you run commands, `rtfctl` checks for any proxy settings in your environment. The tool looks for a `NO_PROXY` key (in upper case) and will accept a `no_proxy` key (in lower case) if `NO_PROXY` is not used. If both keys are present, `rtfctl` uses `NO_PROXY`. The `rtfctl` tool sets the key in your local Kubernetes context to honor your proxy settings. ## Commands for Configuring Runtime Fabric Use the following commands to configure Runtime Fabric.
CommandDescription

Applies changes to a Runtime Fabric configuration

Updates rtfctl

Waits for Runtime Fabric components to become ready

Renews an expired client certificate using a pre-downloaded package

### `apply` Applies changes to a Runtime Fabric configuration. > [!NOTE] You can use the `rtfctl apply system-configuration` command to update OpenShift > system-configuration values. Other rtfctl apply commands are not effective for OpenShift. For any > other updates, modify the values in the OpenShift console. - Applies an HTTP proxy configuration rtfctl apply http-proxy http://: --namespace - Applies an HTTP proxy configuration with hostnames bypassing the proxy rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - Applies an HTTP proxy configuration with authentication rtfctl apply http-proxy http://:@: --namespace - Clears an HTTP proxy configuration rtfctl apply http-proxy "" --no-proxy "" --namespace - Applies a secure property rtfctl apply secure-property --key --value --app-namespace --namespace - Applies a system configuration on a host node rtfctl apply system-configuration - Applies a system configuration on a host node without downloading the latest scripts rtfctl apply system-configuration --skip-download - Applies a Mule license rtfctl apply mule-license --namespace If Runtime Fabric is installed via Helm, you must update the `mule-license` property in the Helm values. - Applies a monitoring proxy rtfctl apply monitoring-proxy http://: --namespace - Clears a monitoring proxy configuration rtfctl apply monitoring-proxy "" --namespace ### `update` Updates `rtfctl`. - Updates from the US control plane rtfctl update - Updates `rtfctl` from the EU control plane rtfctl update --host eu1.anypoint.mulesoft.com ### `wait` Waits for Runtime Fabric components to become ready - Specifies the number of seconds to wait rtfctl wait --namespace - Specifies the number of seconds to pass before timing out the wait (Default is 600 seconds) rtfctl wait --timeout --namespace ### `renew` Renews an expired client certificate using a pre-downloaded package rtfctl renew-expired-client-cert ## Commands for Installing and Upgrading Runtime Fabric Use the following commands when installing or upgrading Runtime Fabric, or when performing a back up or restore.
CommandDescription

Installs Runtime Fabric

Performs a back up of the local Runtime Fabric state

Restores local Runtime Fabric state from a backup

Validates the cluster for Runtime Fabric installation

Displays the Runtime Fabric version information

### `install` - Installs Runtime Fabric rtfctl install - Override the Docker image registry URL and secret rtfctl install --image-pull-registry --image-pull-secret ### `backup` Performs a back up of the local Runtime Fabric state. rtfctl backup .tar.gz --namespace ### `restore` Restores the local Runtime Fabric state from a backup rtfctl restore .tar.gz --namespace ### `validate` Validates the cluster for a Runtime Fabric installation - Performs a validation check rtfctl validate - Performs a validation check and passes the `fabric.tf` configuration file that contains proxy settings rtfctl validate -f To validate installation with a proxy, you must specify proxy settings in your `settings` file: MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://.com: - Override the Docker image registry URL and secret rtfctl validate --image-pull-registry --image-pull-secret ### `version` Displays the Runtime Fabric version information rtfctl version --namespace ## Commands for Managing Applications on Runtime Fabric Use the following commands to manage applications deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays disk usage for an application

Restarts an application

### `delete` Deletes a secure property rtfctl delete secure-property -n ### `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ### `restart` Restarts an application rtfctl restart --app-namespace --namespace ## Commands for Troubleshooting Runtime Fabric Use the following commands to troubleshoot Runtime Fabric.
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

### `get` Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ### `ping` Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ### `report` Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ### `status` Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ### `test` Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## Usage ### Install a Mule license 1. Make sure to base64 encode the license. 2. Run the following command: ./rtfctl apply mule-license '' --namespace rtf1 Updating rtf namespace... OK ### Capture a Heap Dump /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof --app-namespace bed42b62-XXXX --namespace rtf1 Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof For additional information, run the `rtfctl heapdump -h` command. ### Working with Multiple Replicas For application management commands that accept a `--pod` flag, you can obtain the list of replicas using the `describe` command: ./rtfctl describe apps hello-world --app-namespace bed42b62-XXXX --namespace rtf1 Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status --- hello-world-77f5897949-z54gb Pending ## Auditing rtfctl Operations The `rtfctl` command line tool (from v1.0.29 and above) audits the `rtfctl` operations on the cluster and it helps cluster administrators and you to track operations that impact Runtime Fabric core software. Consider the following points: - Audit logs are stored in a Kubernetes secret in the `rtfctl-audit` namespace. - Audit logs are cluster scoped and not attached to Runtime Fabric core software lifecycle. - Command executions remain operational even if the auditing process fails to audit the operation. To audit the operations, run the following command: ./rtfctl audit-logs An output example: \[{"timestamp":"2023-10-26 00:52:24.446 +0000 UTC","kubeContext":"test-k8scontext","command":\["./rtfctl","restart","test-application","--app-namespace","8456f9c7-2149-4983-b02b-6b18ddd28efe","--namespace","rtf"\]}\] > [!NOTE] Currently audit logs rollover or rotation is not supported. ## Understanding rtfctl Output The `rtfctl` command line tool commonly calls other applications and system tools, and the output of those calls is sent to standard output and standard error output. This output is written in the context of each operation performed. The `rtfctl` command line tool includes a last output line on the most verbose commands to make it clear whether the operation succeed or failed. Normal operation may include some intermediate _failure_ messages, such as when a stopped system unit is attempted to be stopped again. If you are in doubt about whether a message represents a problem or not, discuss it with your system administrator or contact MuleSoft support. ## Download Previous rtfctl CLI Versions Use the following rest API call to download different rtfctl tool CLI versions: curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/{version} -o rtfctl ## See Also - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/manage-proxy-self) - [Manage Secure Properties in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.6/manage-secure-properties) --- product: Runtime Fabric version: 2.7 --- # Using the Runtime Fabric Command Line Tool > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Install and use the `rtfctl` command line tool to locally manage Runtime Fabrics. The `rtfctl` tool supports the following actions: - Get the status of a Runtime Fabric. - Perform a heap dump or a thread dump of a running application. - Display memory usage of a running application. - Manage proxy settings. - Manage secure properties. - Manage a Mule license. - Manage the alert sender email address. If you are using the default namespace (rtf), you do not need to specify the additional flag `--namespace `. Note that this flag is introduced only as of rtfctl version 0.4.1. ## Install rtfctl > [!IMPORTANT] The tasks in the section must be performed by an IT administrator. > > If you’re using Runtime Fabric for AKS and have the AKS-managed Azure AD integration enabled, the > following command returns the credentials needed to run rtfctl commands: > > `az aks get-credentials --name --resource-group --admin` 1. Download the `rtfctl` command-line tool: `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Choose the appropriate method: - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. Change file permissions for the `rtfctl` command-line tool: chmod +x rtfctl ### Running Commands The `rtfctl` command line tool consumes kubeconfig files as described in [Organizing Cluster Access Using kubeconfig Files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Use this method to configure which cluster you want to manage. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. - Run `rtfctl` commands as a privileged user. - To list all supported commands, run `rtfctl -h`. - For more information about a specific command, run `rtfctl -h`. ### Checking for Proxy Settings When you run commands, `rtfctl` checks for any proxy settings in your environment. The tool looks for a `NO_PROXY` key (in upper case) and will accept a `no_proxy` key (in lower case) if `NO_PROXY` is not used. If both keys are present, `rtfctl` uses `NO_PROXY`. The `rtfctl` tool sets the key in your local Kubernetes context to honor your proxy settings. ## Commands for Configuring Runtime Fabric Use the following commands to configure Runtime Fabric.
CommandDescription

Applies changes to a Runtime Fabric configuration

Updates rtfctl

Waits for Runtime Fabric components to become ready

Renews an expired client certificate using a pre-downloaded package

### `apply` Applies changes to a Runtime Fabric configuration. > [!NOTE] You can use the `rtfctl apply system-configuration` command to update OpenShift > system-configuration values. Other rtfctl apply commands are not effective for OpenShift. For any > other updates, modify the values in the OpenShift console. - Applies an HTTP proxy configuration rtfctl apply http-proxy http://: --namespace - Applies an HTTP proxy configuration with hostnames bypassing the proxy rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - Applies an HTTP proxy configuration with authentication rtfctl apply http-proxy http://:@: --namespace - Clears an HTTP proxy configuration rtfctl apply http-proxy "" --no-proxy "" --namespace - Applies a secure property rtfctl apply secure-property --key --value --app-namespace --namespace - Applies a system configuration on a host node rtfctl apply system-configuration - Applies a system configuration on a host node without downloading the latest scripts rtfctl apply system-configuration --skip-download - Applies a Mule license rtfctl apply mule-license --namespace If Runtime Fabric is installed via Helm, you must update the `mule-license` property in the Helm values. - Applies a monitoring proxy rtfctl apply monitoring-proxy http://: --namespace - Clears a monitoring proxy configuration rtfctl apply monitoring-proxy "" --namespace ### `update` Updates `rtfctl`. - Updates from the US control plane rtfctl update - Updates `rtfctl` from the EU control plane rtfctl update --host eu1.anypoint.mulesoft.com ### `wait` Waits for Runtime Fabric components to become ready - Specifies the number of seconds to wait rtfctl wait --namespace - Specifies the number of seconds to pass before timing out the wait (Default is 600 seconds) rtfctl wait --timeout --namespace ### `renew` Renews an expired client certificate using a pre-downloaded package rtfctl renew-expired-client-cert ## Commands for Installing and Upgrading Runtime Fabric Use the following commands when installing or upgrading Runtime Fabric, or when performing a back up or restore.
CommandDescription

Installs Runtime Fabric

Performs a back up of the local Runtime Fabric state

Restores local Runtime Fabric state from a backup

Validates the cluster for Runtime Fabric installation

Displays the Runtime Fabric version information

### `install` - Installs Runtime Fabric rtfctl install - Override the Docker image registry URL and secret rtfctl install --image-pull-registry --image-pull-secret ### `backup` Performs a back up of the local Runtime Fabric state. rtfctl backup .tar.gz --namespace ### `restore` Restores the local Runtime Fabric state from a backup rtfctl restore .tar.gz --namespace ### `validate` Validates the cluster for a Runtime Fabric installation - Performs a validation check rtfctl validate - Performs a validation check and passes the `fabric.tf` configuration file that contains proxy settings rtfctl validate -f To validate installation with a proxy, you must specify proxy settings in your `settings` file: MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://.com: - Override the Docker image registry URL and secret rtfctl validate --image-pull-registry --image-pull-secret ### `version` Displays the Runtime Fabric version information rtfctl version --namespace ## Commands for Managing Applications on Runtime Fabric Use the following commands to manage applications deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays disk usage for an application

Restarts an application

### `delete` Deletes a secure property rtfctl delete secure-property -n ### `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ### `restart` Restarts an application rtfctl restart --app-namespace --namespace ## Commands for Troubleshooting Runtime Fabric Use the following commands to troubleshoot Runtime Fabric.
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

### `get` Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ### `ping` Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ### `report` Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ### `status` Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ### `test` Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## Usage ### Install a Mule license 1. Make sure to base64 encode the license. 2. Run the following command: ./rtfctl apply mule-license '' --namespace rtf1 Updating rtf namespace... OK ### Capture a Heap Dump /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof --app-namespace bed42b62-XXXX --namespace rtf1 Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof For additional information, run the `rtfctl heapdump -h` command. ### Working with Multiple Replicas For application management commands that accept a `--pod` flag, you can obtain the list of replicas using the `describe` command: ./rtfctl describe apps hello-world --app-namespace bed42b62-XXXX --namespace rtf1 Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status --- hello-world-77f5897949-z54gb Pending ## Auditing rtfctl Operations The `rtfctl` command line tool (from v1.0.29 and above) audits the `rtfctl` operations on the cluster and it helps cluster administrators and you to track operations that impact Runtime Fabric core software. Consider the following points: - Audit logs are stored in a Kubernetes secret in the `rtfctl-audit` namespace. - Audit logs are cluster scoped and not attached to Runtime Fabric core software lifecycle. - Command executions remain operational even if the auditing process fails to audit the operation. To audit the operations, run the following command: ./rtfctl audit-logs An output example: \[{"timestamp":"2023-10-26 00:52:24.446 +0000 UTC","kubeContext":"test-k8scontext","command":\["./rtfctl","restart","test-application","--app-namespace","8456f9c7-2149-4983-b02b-6b18ddd28efe","--namespace","rtf"\]}\] > [!NOTE] Currently audit logs rollover or rotation is not supported. ## Understanding rtfctl Output The `rtfctl` command line tool commonly calls other applications and system tools, and the output of those calls is sent to standard output and standard error output. This output is written in the context of each operation performed. The `rtfctl` command line tool includes a last output line on the most verbose commands to make it clear whether the operation succeed or failed. Normal operation may include some intermediate _failure_ messages, such as when a stopped system unit is attempted to be stopped again. If you are in doubt about whether a message represents a problem or not, discuss it with your system administrator or contact MuleSoft support. ## Download Previous rtfctl CLI Versions Use the following rest API call to download different rtfctl tool CLI versions: curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/{version} -o rtfctl ## See Also - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/manage-proxy-self) - [Manage Secure Properties in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.7/manage-secure-properties) --- product: Runtime Fabric version: 2.8 --- # Using the Runtime Fabric Command Line Tool > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Install and use the `rtfctl` command line tool to locally manage Runtime Fabrics. The `rtfctl` tool supports the following actions: - Get the status of a Runtime Fabric. - Manage proxy settings. - Manage secure properties. - Manage a Mule license. - Manage the alert sender email address. If you are using the default namespace (rtf), you do not need to specify the additional flag `--namespace `. Note that this flag is introduced only as of rtfctl version 0.4.1. ## Install rtfctl > [!IMPORTANT] The tasks in the section must be performed by an IT administrator. > > If you’re using Runtime Fabric for AKS and have the AKS-managed Azure AD integration enabled, the > following command returns the credentials needed to run rtfctl commands: > > `az aks get-credentials --name --resource-group --admin` 1. Download the `rtfctl` command-line tool: `rtfctl` is supported on Windows, MacOS (Darwin), and Linux. Choose the appropriate method: - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. Change file permissions for the `rtfctl` command-line tool: chmod +x rtfctl ### Running Commands The `rtfctl` command line tool consumes kubeconfig files as described in [Organizing Cluster Access Using kubeconfig Files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Use this method to configure which cluster you want to manage. Confirm that the `rtfctl` binary is present in the current working directory and in the user `$PATH`. - Run `rtfctl` commands as a privileged user. - To list all supported commands, run `rtfctl -h`. - For more information about a specific command, run `rtfctl -h`. ### Checking for Proxy Settings When you run commands, `rtfctl` checks for any proxy settings in your environment. The tool looks for a `NO_PROXY` key (in upper case) and will accept a `no_proxy` key (in lower case) if `NO_PROXY` is not used. If both keys are present, `rtfctl` uses `NO_PROXY`. The `rtfctl` tool sets the key in your local Kubernetes context to honor your proxy settings. ## Commands for Configuring Runtime Fabric Use the following commands to configure Runtime Fabric.
CommandDescription

Applies changes to a Runtime Fabric configuration

Updates rtfctl

Waits for Runtime Fabric components to become ready

Renews an expired client certificate using a pre-downloaded package

### `apply` Applies changes to a Runtime Fabric configuration. > [!NOTE] You can use the `rtfctl apply system-configuration` command to update OpenShift > system-configuration values. Other rtfctl apply commands are not effective for OpenShift. For any > other updates, modify the values in the OpenShift console. - Applies an HTTP proxy configuration rtfctl apply http-proxy http://: --namespace - Applies an HTTP proxy configuration with hostnames bypassing the proxy rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - Applies an HTTP proxy configuration with authentication rtfctl apply http-proxy http://:@: --namespace - Clears an HTTP proxy configuration rtfctl apply http-proxy "" --no-proxy "" --namespace - Applies a secure property rtfctl apply secure-property --key --value --app-namespace --namespace - Applies a system configuration on a host node rtfctl apply system-configuration - Applies a system configuration on a host node without downloading the latest scripts rtfctl apply system-configuration --skip-download - Applies a Mule license rtfctl apply mule-license --namespace If Runtime Fabric is installed via Helm, you must update the `mule-license` property in the Helm values. - Applies a monitoring proxy rtfctl apply monitoring-proxy http://: --namespace - Clears a monitoring proxy configuration rtfctl apply monitoring-proxy "" --namespace ### `update` Updates `rtfctl`. - Updates from the US control plane rtfctl update - Updates `rtfctl` from the EU control plane rtfctl update --host eu1.anypoint.mulesoft.com ### `wait` Waits for Runtime Fabric components to become ready - Specifies the number of seconds to wait rtfctl wait --namespace - Specifies the number of seconds to pass before timing out the wait (Default is 600 seconds) rtfctl wait --timeout --namespace ### `renew` Renews an expired client certificate using a pre-downloaded package rtfctl renew-expired-client-cert ## Commands for Installing and Upgrading Runtime Fabric Use the following commands when installing or upgrading Runtime Fabric, or when performing a back up or restore.
CommandDescription

Installs Runtime Fabric

Performs a back up of the local Runtime Fabric state

Restores local Runtime Fabric state from a backup

Validates the cluster for Runtime Fabric installation

Displays the Runtime Fabric version information

### `install` - Installs Runtime Fabric rtfctl install - Override the Docker image registry URL and secret rtfctl install --image-pull-registry --image-pull-secret ### `backup` Performs a back up of the local Runtime Fabric state. rtfctl backup .tar.gz --namespace ### `restore` Restores the local Runtime Fabric state from a backup rtfctl restore .tar.gz --namespace ### `validate` Validates the cluster for a Runtime Fabric installation - Performs a validation check rtfctl validate - Performs a validation check and passes the `fabric.tf` configuration file that contains proxy settings rtfctl validate -f To validate installation with a proxy, you must specify proxy settings in your `settings` file: MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://.com: - Override the Docker image registry URL and secret rtfctl validate --image-pull-registry --image-pull-secret ### `version` Displays the Runtime Fabric version information rtfctl version --namespace ## Commands for Managing Applications on Runtime Fabric Use the following commands to manage applications deployed to Runtime Fabric.
CommandDescription

Deletes a secure property

Displays disk usage for an application

Restarts an application

### `delete` Deletes a secure property rtfctl delete secure-property -n ### `disk` Displays disk usage for an application - Displays the disk usage for an application, using the first replica by default rtfctl disk --app-namespace --namespace - Displays the disk usage for an application, using a specific replica rtfctl disk --details --pod --app-namespace --namespace ### `restart` Restarts an application rtfctl restart --app-namespace --namespace ## Commands for Troubleshooting Runtime Fabric Use the following commands to troubleshoot Runtime Fabric.
CommandDescription

Displays one or more resources

Tests network connectivity

Generates a diagnostics report

Displays the status of Runtime Fabric

Verifies outbound network connectivity to the Runtime Fabric control plane

### `get` Displays one or more resources - Prints a list of all applications in all environments rtfctl get apps --namespace - Prints a list of all applications in a specific environment rtfctl get apps --app-namespace --namespace - Displays an HTTP proxy configurations rtfctl get http-proxy --namespace - Displays a monitoring proxy configuration rtfctl get monitoring-proxy --namespace - Displays secure properties rtfctl get secure-properties --app-namespace --namespace - Displays the Mule license rtfctl get mule-license --namespace - Displays Runtime Fabric registry credentials rtfctl get registry-credentials ### `ping` Tests network connectivity - Pings example.com from inside an application, using the first replica by default rtfctl ping --app-namespace --namespace - Attempts to connect to example.com on port `12345` from inside an application, using the first replica by default rtfctl ping --port --app-namespace --namespace ### `report` Generates a diagnostics report at `rtf-report.tar.gz` rtfctl report --namespace Run rtfctl report tasks in parallel by using the `workers` flag that controls the number of tasks to run in parallel. The default value is 10. rtfctl report --workers Faster compression of the tarball generated by `rtfctl report` with the `--use-fast-compression` flag. The default value is false. rtfctl report --use-fast-compression=true Select which application namespaces to include in the report besides the installation namespace by using the `--namespaces` flag. The flag controls what to include in the reports and can result in faster collection if only selected namespaces are reported. # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all Specifies the name of the helm release to support installations using custom release names. rtfctl report --release-name ### `status` Displays the status of Runtime Fabric - Displays status output in JSON rtfctl status --output json --namespace - Checks Kubernetes DNS health rtfctl status dns-check --node-label ":" ### `test` Verifies outbound network connectivity to the Runtime Fabric control plane. - Schedules a check on any nodes rtfctl test outbound-network --namespace - Schedules a check the nodes satisfying the `node-label` parameter rtfctl test outbound-network --node-label ":" --namespace - Schedules a check on all nodes rtfctl test outbound-network --all --namespace ## Usage ### Install a Mule license 1. Make sure to base64 encode the license. 2. Run the following command: ./rtfctl apply mule-license '' --namespace rtf1 Updating rtf namespace... OK ### Capture a Heap Dump /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof --app-namespace bed42b62-XXXX --namespace rtf1 Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof For additional information, run the `rtfctl heapdump -h` command. ### Working with Multiple Replicas For application management commands that accept a `--pod` flag, you can obtain the list of replicas using the `describe` command: ./rtfctl describe apps hello-world --app-namespace bed42b62-XXXX --namespace rtf1 Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status --- hello-world-77f5897949-z54gb Pending ## Auditing rtfctl Operations The `rtfctl` command line tool (from v1.0.29 and above) audits the `rtfctl` operations on the cluster and it helps cluster administrators and you to track operations that impact Runtime Fabric core software. Consider the following points: - Audit logs are stored in a Kubernetes secret in the `rtfctl-audit` namespace. - Audit logs are cluster scoped and not attached to Runtime Fabric core software lifecycle. - Command executions remain operational even if the auditing process fails to audit the operation. To audit the operations, run the following command: ./rtfctl audit-logs An output example: \[{"timestamp":"2023-10-26 00:52:24.446 +0000 UTC","kubeContext":"test-k8scontext","command":\["./rtfctl","restart","test-application","--app-namespace","8456f9c7-2149-4983-b02b-6b18ddd28efe","--namespace","rtf"\]}\] > [!NOTE] Currently audit logs rollover or rotation is not supported. ## Understanding rtfctl Output The `rtfctl` command line tool commonly calls other applications and system tools, and the output of those calls is sent to standard output and standard error output. This output is written in the context of each operation performed. The `rtfctl` command line tool includes a last output line on the most verbose commands to make it clear whether the operation succeed or failed. Normal operation may include some intermediate _failure_ messages, such as when a stopped system unit is attempted to be stopped again. If you are in doubt about whether a message represents a problem or not, discuss it with your system administrator or contact MuleSoft support. ## Download Previous rtfctl CLI Versions Use the following rest API call to download different rtfctl tool CLI versions: curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/{version} -o rtfctl ## See Also - [Manage Proxies Used by Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-proxy-self) - [Manage Secure Properties in Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.8/manage-secure-properties) --- product: Runtime Fabric version: 2.10 --- # Viewing Runtime Fabric Health Details > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. ## Health Details For Runtime Fabric version 1.5 or later: 1. Navigate to Runtime Manager and select **Runtime Fabric**. 2. Select the name of your Runtime Fabric cluster to open the management page. 3. Select **Health Details**. The **Health Details** section indicates whether your Runtime Fabric cluster configuration meets the requirements for a production environment, a development environment, or neither. If your configuration fails to meet the minimum requirements of both production and development environments, `Not supported` is displayed. --- product: Runtime Fabric version: 2.11 --- # Viewing Runtime Fabric Health Details > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. ## Health Details For Runtime Fabric version 1.5 or later: 1. Navigate to Runtime Manager and select **Runtime Fabric**. 2. Select the name of your Runtime Fabric cluster to open the management page. 3. Select **Health Details**. The **Health Details** section indicates whether your Runtime Fabric cluster configuration meets the requirements for a production environment, a development environment, or neither. If your configuration fails to meet the minimum requirements of both production and development environments, `Not supported` is displayed. --- product: Runtime Fabric version: 2.5 --- # Viewing Runtime Fabric Health Details > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. ## Health Details For Runtime Fabric version 1.5 or later: 1. Navigate to Runtime Manager and select **Runtime Fabric**. 2. Select the name of your Runtime Fabric cluster to open the management page. 3. Select **Health Details**. The **Health Details** section indicates whether your Runtime Fabric cluster configuration meets the requirements for a production environment, a development environment, or neither. If your configuration fails to meet the minimum requirements of both production and development environments, `Not supported` is displayed. --- product: Runtime Fabric version: 2.6 --- # Viewing Runtime Fabric Health Details > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. ## Health Details For Runtime Fabric version 1.5 or later: 1. Navigate to Runtime Manager and select **Runtime Fabric**. 2. Select the name of your Runtime Fabric cluster to open the management page. 3. Select **Health Details**. The **Health Details** section indicates whether your Runtime Fabric cluster configuration meets the requirements for a production environment, a development environment, or neither. If your configuration fails to meet the minimum requirements of both production and development environments, `Not supported` is displayed. --- product: Runtime Fabric version: 2.7 --- # Viewing Runtime Fabric Health Details > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. ## Health Details For Runtime Fabric version 1.5 or later: 1. Navigate to Runtime Manager and select **Runtime Fabric**. 2. Select the name of your Runtime Fabric cluster to open the management page. 3. Select **Health Details**. The **Health Details** section indicates whether your Runtime Fabric cluster configuration meets the requirements for a production environment, a development environment, or neither. If your configuration fails to meet the minimum requirements of both production and development environments, `Not supported` is displayed. --- product: Runtime Fabric version: 2.8 --- # Viewing Runtime Fabric Health Details > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. ## Health Details For Runtime Fabric version 1.5 or later: 1. Navigate to Runtime Manager and select **Runtime Fabric**. 2. Select the name of your Runtime Fabric cluster to open the management page. 3. Select **Health Details**. The **Health Details** section indicates whether your Runtime Fabric cluster configuration meets the requirements for a production environment, a development environment, or neither. If your configuration fails to meet the minimum requirements of both production and development environments, `Not supported` is displayed. --- product: Runtime Fabric version: 2.9 --- # Viewing Runtime Fabric Health Details > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. ## Health Details For Runtime Fabric version 1.5 or later: 1. Navigate to Runtime Manager and select **Runtime Fabric**. 2. Select the name of your Runtime Fabric cluster to open the management page. 3. Select **Health Details**. The **Health Details** section indicates whether your Runtime Fabric cluster configuration meets the requirements for a production environment, a development environment, or neither. If your configuration fails to meet the minimum requirements of both production and development environments, `Not supported` is displayed. --- product: Runtime Fabric version: 3.0 is-latest-version: true --- # Viewing Runtime Fabric Health Details > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use Anypoint Runtime Manager to view the health of your Anypoint Runtime Fabric clusters. ## Health Details For Runtime Fabric version 1.5 or later: 1. Navigate to Runtime Manager and select **Runtime Fabric**. 2. Select the name of your Runtime Fabric cluster to open the management page. 3. Select **Health Details**. The **Health Details** section indicates whether your Runtime Fabric cluster configuration meets the requirements for a production environment, a development environment, or neither. If your configuration fails to meet the minimum requirements of both production and development environments, `Not supported` is displayed.