CLM 설치 - Reverse Proxy 구성 이유

출처 : https://jazz.net/library/article/744

One crucial piece to a successful deployment of the reverse proxy configuration is understanding what you are going to accomplish and what problems this will not solve for you. First and formost the benefit of using a reverse proxy is the ability to mask the complexity of the underlying deployment from your end users.

Figure 1: Fully distributed CLM enterprise topology example¹

In order to fully distribute your deployment we have added some complexity in that a user of the CLM solution needs to connect to 4+ different servers, as well as manage the different ports and context roots involved. The benefit here is the simplicity of the deployment, we allow for a fully distributed topology the deployment details are transparent to the user and there is a minimum amount of complexity in how to connect the applications together. The big downside is that the implementation details have become part of the deployment, this may include ports and machine names that are not standard and with the underlying requirement to never change the Public URL2 this can make infrastructure level changes difficult tasks.


One alternative approach is to use a Reverse Proxy server to "listen" on your Public URL and allow for the underlying deployment to vary. This is a common technique for hosting applications for security and load balancing reasons and a standard feature of the IBM WebSphere and HTTP Server plugin architecture that we will look at a bit further on in the article.

Figure 2: Using a reverse proxy in your topology³

Now this approach gives the deployment more flexibility at the added complexity of managing an additional system to host the reverse proxy itself. The added complexity is has been the main stubmling point for many clients who have avoided this type of deployment, this article is intended to provide some additional to help overcome the intial hurdles to a successful reverse proxy deployment.