Managed deployment scenarios
The different possible deployment scenarios for DESK Managed are detailed below. Each illustration depicts the various involved components and the required communication ports between components. The direction of arrows in the diagrams indicates which component initiates communication.
If you want your Managed Cluster to be accessible only internally, use a basic setup (Scenario 1 below). Implement a pure DESK Managed setup (Scenario 2) if you want to enable DEM services and communication from external sources. If you want to integrate DESK Managed into existing IT infrastructure, follow Scenario 3.
Scenario 1: Basic setup
Once you install DESK Managed and set up one or more cluster nodes, you get the deployment scenario illustrated below.
Without further configuration (From the CMC menu, select Settings > Public endpoints) a cluster is only accessible internally and exposes ports 443for the REST API, OneAgent traffic, and Web UI access (Cluster Management Console and environment UI). By default, remote access to Mission Control is enabled. This enables DESK to perform monitoring and health checks of your Managed clusters. Each communication channel is secured with TLS.
Scenario 2: Pure DESK Managed setup
If you want your cluster to receive monitoring data from external OneAgents, or if you want to use our Digital Experience Monitoring (DEM) services, you need to expose the cluster to external networks and configure a public IP address. The DEM services include:
- Synthetic monitoring
- Agentless Real User Monitoring
- Mobile Real User Monitoring
- Real User Monitoring via browser extension
- Communication with the DESK mobile app
Exposing the cluster directly to external networks isn't recommended for security reasons. Therefore, we suggest using one or more Cluster ActiveGates as mediating proxies for pre-processing of OneAgent and DEM traffic. Cluster ActiveGates will be recognized by the cluster and can be configured through the Cluster Management Console similar to cluster nodes. The image below shows the relevant communication ports for each case.
The Cluster ActiveGate requires:
- A publicly available IP address
- A domain name with a valid SSL certificate, since external communication is only supported in a secure manner using HTTPS (port 443). This domain must be different from the Web UI domain. You can choose to provide a domain and a SSL certificate on your own or let DESK do this for you. DESK can generate a domain and a valid SSL certificate on your behalf.
For high-load, production-ready installations with external hosts, applications, sessions, and synthetic monitoring, it's recommended that you set up two load-balanced Cluster ActiveGates with the same domain name and certificate. For smaller, low-load installations you can use only a single Cluster ActiveGate. Also, you might consider installing a separate Environment ActiveGate for each of your environments.
Because the Environment ActiveGate starts communication with the Cluster ActiveGate upon installation, the Cluster ActiveGate must be operational and available via the public IP address beforehand. As a result, if you plan to use the Environment ActiveGate, the deployment order is important:
Set up your DESK Managed Cluster.
Set up your Cluster ActiveGate and make sure that it can connect to the DESK Managed Cluster. Also, make sure that the Cluster ActiveGate has a public IP address and is accessible from outside your network.
Set up your Environment ActiveGate and provide the Cluster ActiveGate public address for external communication.
Note: Web UI traffic or cluster administration (through Cluster Management Console) should remain on-premises, within your network. The Web UI is accessed using HTTPS. As such a TLS certificate is required. It is acceptable to use a self-signed certificate, but you will likely want Web UI traffic and cluster administration to be carried out in a secure manner as well. In such cases, you can provide a domain name and a valid SSL certificate, or these can be generated automatically by DESK. By default, each cluster gets a subdomain of *.desk-managed.com with a valid certificate from Let’s Encrypt. Note also that Cluster ActiveGates don't support proxying of Web UI traffic.
Scenario 3: Integration with existing IT landscape
In a more complex scenario, you may want to embed DESK Managed into an existing IT infrastructure with a number of appliances already in place. The image below shows a customer-provided load balancer in front of the Cluster ActiveGate domain and a customer-provided proxy for outbound communication to Mission Control.
Required configuration for each traffic case
The following table sums up the required configuration for each discrete traffic case, indicating with an x whether a public IP is required, a valid SSL certificate, or both. Note that Real User Monitoring (RUM), agentless RUM, and mobile RUM normally relate to your users' traffic and browser activity, which take place outside your network. Theoretically, this traffic can also be considered as originating from inside your network, so these cases are also included in the following table.
| Traffic type | Public IP | Valid SSL certificate |
|---|---|---|
| OneAgent (on-premises) | ||
| OneAgent (external) | x | |
| RUM (on-premises) | ||
| RUM (external) | ||
| Agentless RUM (on-premises) | x | |
| Agentless RUM (external) | x | x |
| Mobile RUM (on-premises) | x | |
| Mobile RUM (external) | x | x |
| Synthetic | x |
Note: Agentless Real User Monitoring, mobile-app monitoring, and synthetic monitors all use the same endpoint to transmit monitoring data to DESK.