AppDynamics Application Intelligence Platform
A common data center design involves putting backend services such as the AppDynamics Controller in a network behind a DMZ. For the Controller, a network proxy residing in the DMZ acts as an end-point for the Controller by presenting a virtual IP address for the Controller, since App Agents and UI browser clients connect to the Controller through the virtual IP.
In addition to providing a security layer, a reverse proxy allows you to move a Controller to another machine or switch between high availability pairs without having to reconfigure and restart monitored applications.
In the sample scenario shown by the diagram, the reverse proxy listens for incoming requests on a given path, /controller in this case, on port 80. It forwards matching requests to the HTTP listening port of the primary Controller at appdhost1:8090. In terms of network impact in this scenario, switching active Controllers from the primary to the secondary in this scenario only requires the administrator to update the routing policy at the proxy so that traffic directed to the secondary instead of the primary.
If clients use SSL, the reverse proxy can terminate SSL connections or maintain SSL through to the Controller. Terminating SSL at the proxy removes the processing burden from the Controller machine. It can also simplify administration for the data center as a whole by centralizing SSL key management to a single point and it allows you to use alternative PKI infrastructures like OpenSSL.
There are various types of devices and software that can act as a reverse proxy. For example, Nginx, HAProxy, Apache Web Server, or an application-level load balancer such as F5's BIG-IP can all act as a reverse proxy for the Controller.
This page provides general considerations for setting up the Controller with a reverse proxy. It also provides sample configurations for a few specific types of proxies.
It is important to note that this information is intended for illustration purposes only. The configuration requirements for your own deployment is likely to vary greatly, depending on the existing environment, the applications being monitored, and the practices and policies of your organization.
While AppDynamics supports Controllers that are deployed with a reverse proxy, AppDynamics Support cannot guarantee help with specific set up questions and issues particular for your environment or the type of proxy you are using. For this type of information, please consult the documentation provided with your proxy technology. Alternatively, try posting the question to the AppDynamics community.
The following describe general requirements, considerations, and features for deploying the AppDynamics Controller and App Agents with a reverse proxy.
In the Controller configuration, add a JVM option named -Dappdynamics.controller.ui.deeplink.url to the domain configuration file, domain.xml, or using the modifyJvmOptions utility. As the value of the option, provide the hostname or virtual IP address for the Controller as exposed at the proxy. For example:
The Controller uses this value to compose the deep link URLs it exposes in the UI.
If the proxy (or other network device) needs to check for the availability of the Controller, it can use Controller REST resource at: http://<host>:<port>/controller/rest/serverstatus. If the Controller is active and if in high availability mode, is the primary, it returns an XML response similar to this one:
If the Controller is in standby Controller this resource returns an error response.
The following sections provide notes and sample configurations for a few specific types of proxies, including Nginx and Apache Web Server.
Nginx is a commonly used web server and reverse proxy available at http://nginx.org/.
To use Nginx as a reverse proxy for the Controller, simply include the Controller as the upstream server in the Nginx configuration. If deploying two Controllers in a high availability pair arrangement, include the addresses of both the primary and secondary Controllers in the upstream server definition.
The following steps walk you through the set up at a high level. It assumes you have already installed the Controller and have an Nginx instance, and you only need to modify the existing configuration to have Nginx route traffic to the Controller.
The sample network layout represented in the configuration in these steps is:
If the Controller is running, shut down the Controller.
In the configuration file, add a cluster definition the specifies each Controller as an upstream server. For example:
In the sample, the Controller resides on 127.0.15.11 and has the fully qualified domain name appdcontroller.example.com.
After the Controller starts, it should be able to receive traffic through Nginx. As an initial test of the connection, try opening the Controller UI via the proxy, that is, in a browser, go to http://<virtualip>:80/controller. For the App Agents, you'll need to configure their proxy host and port settings as described in the general guidelines above.
To use Apache as a reverse proxy, you need to make sure the appropriate Apache module is installed and enabled in your Apache instance. For HTTP proxying, this is typically mod_proxy_http. The mod_proxy_http module support proxied connections that use HTTP or HTTPS.
If the Controller is running, shut it down.
On the machine that runs Apache, check whether the required modules are already loaded by your Apache instance by running this command:
In the output, look for proxy modules as follows:
The proxy_module is a dependency for proxy_module_http.
Type the following:
Add the proxy configuration to Apache. For example, a configuration that directs clients requests to the standard web port 80 at the proxy host to the Controller could look similar to this:
Apply your configuration changes by reloading Apache modules. For example, enter:
Start the Controller.
After the Controller starts, test the connection by opening a browser to the Controller UI as exposed by the proxy. To enable AppDynamics App Agents to connect through the proxy, be sure to set the proxy host and port settings in the proxy, as described in the general guidelines above. Also be sure to apply any of the other general guidelines described in the general guidelines above.
This section describes how to set up security when the client-side connection to the proxy uses SSL that's terminated at the proxy. This assumes that the proxy and Controller are in a secured data center and the App Agents or UI browser client connections are from a potentially insecure network.
Terminating SSL at a proxy offloads the burden of SSL processing from the Controller to the proxy. This configuration is strongly recommended when deploying the Controller to large scale, high workload environments. Terminating SSL at a proxy also provides the benefit of having a central point in the data center for security certificate and key management.
This section provides an sample configuration for Nginx, but the concepts translate to other types of reverse proxies as well.
To enable SSL termination at the reverse proxy, you need to:
A complete example configuration with Nginx performing SSL termination for the Controller would look something like this:
This example builds on the configuration shown in the simple passthrough example. In this one, any request received on the non-SSL port 80 is routed to port 443. The server for port 443 contains the settings for SSL termination. The ssl_certificate_key and ssl_certificate directives should identify the location of the server security certificate and key for the proxy.
The configuration also indicates the SSL protocols and ciphers accepted for connections. The security settings need to be compatible with the AppDynamics App Agent security capabilities, as described on the Agent - Controller Compatibility Matrix page.
To work with the Controller, you must configure the Controller with a mixed-channel HTTP listener, as described in the following section, Configure the Controller for SSL Termination at the Proxy.
Be sure to set up the proxy to redirect server side traffic to the secure channel on the client side if you are performing this configuration. If you enable a mixed use channel, as described here, you need to be sure that the clients are configured to use the secure channel.
Stop the Controller application server:
Open the services-config.xml file for editing. You can find it in the following directory:
Replace the default value of the class attribute of the endpoint URL element, flex.messaging.endpoints.SecureAMFEndpoint, with a new value of flex.messaging.endpoints.AMFEndpoint. The resulting element should look like this:
Start the application server:
Have the proxy connect to the Controller with SSL requires a minor modification to the proxy configuration. Simply specify the use of HTTPS as the protocol to connect to the backend or upstream server. In other words, for the Nginx configuration, this simply requires you to modify the proxy_pass value as follows:
To complete the configuration, make sure you have configured SSL on the Controller as described in Controller SSL and Certificates.