When using Exalogic to host an application it is fairly common to see Oracle Traffic Director (OTD) being used as a load balancer in front of the application. OTD has a rich functional set that can make it more than just a load balancer/proxy - this allows it to perform traffic management/shaping. In a recent engagement I was asked if it could perform application version management, to which the answer is yes.
The solution presented here is just one possible answer to application versioning and there are often many other approaches that should be considered.
Problem Statement
The scenario we are looking at here is a situation where a new JEE application is being deployed to an application server and the new version is to be set live on a particular date/time. Existing sessions with the old application are to carry on using the previous version of the application until their sessions expire.
There are a number of restrictions that apply:-
- No changes to the underlying application. (For example, WLS has the concept of versioning built into it but the application code - descriptors - must be altered to use this. In our scenario we are using a third party application and do not have the ability to make any changes.)
- No application down time is allowed. (App is accessed 24*7)
- Existing sessions remain on the previous version and new sessions use the new version
Solution Overview
The solution used makes use of the routing rules that are available in OTD. Essentially inspecting the HTTP requests that hit OTD and determine if the request should remain on the old application version or be routed to the new version.
The first problem is to figure out how to know if a request is to be routed to the old or new version of the application. Assuming the back end application is an application server it is very likely that a jsessionid cookie will be set for any existing client connection. If not set then we could route what will be a new session onto the new application version. The problem comes with the next request, it will have the jsessionid cookie set and we have no way of knowing if the session is to be routed to the old or the new application version. A solution to this issue is to use OTD to inject an additional cookie into the browser, this cookie can contain the time that it was created. Then we can simply inspect this cookie on each request and if the time it holds is before a cut-off date then route to the old version and if after the cut off then route to the new application.
Solution Detail
Injecting a Cookie
The first activity is to use OTD to inject a cookie into the HTTP response that goes back to the client. This can be done using the Server Application Functions (SAFs) that OTD supports, these are documented in
this link. (Although check for newer documentation releases
from here.)
In summary OTD makes use of a special file the
obj.conf file that contains a list of directives to instruct OTD how to handle incoming HTTP requests. Many of the changes done through the OTD administration console or command line end up as directives in this file. In addition to the commands that are neatly wrapped up in the console interfaces there are additional directives and functions that can be added by editing the correct
obj.conf file by hand. Inserting a cookie is one such SAF.
The first activity is to understand which file to edit. If you simply do a search from the command line under the OTD instances directory for all *.obj.conf files you will see that there are multiple copies of files held. This is because each configuration/virtual server has its own copy of the file and these are held centrally in a repository and copied out to the running instances when changes are deployed. In our scenario we are wanting to change the HTTP processing for a particular "Virtual Server" as part of an OTD configuration. The path to the file we are interested in is:-
<OTD Instance Home>/admin-server/config-store/<configuration name>/config/<virtual
server name>-obj.conf |
|
|
This resides on the server that is hosting the OTD administration server which manages all the
obj.conf files for all the configurations/virtual servers used. The <virt-server>-obj.conf file is the copy held in the repository, it can be edited to add a section that will inject the cookie. Having edited the file then either use the command line (
tadm) or the browser to deploy the configuration file. The action of deploying the config file will copy the configuration to the running instances and update them so that they use the new configuration. This update is done dynamically and does
not require any downtime of the OTD instance.
A sample directive to add the cookie is shown below:-
<Object name="default">
AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true"
NameTrans fn="assign-name" id="default-route" name="default-route"
NameTrans fn="map" from="/" to="/"
<If not defined $cookie{"MyApp"}>
ObjectType fn="set-cookie" name="MyApp" value="$time"
</If>
Service fn="proxy-retrieve" method="*"
AddLog fn="flex-log"
</Object>
<Object name="default-route">
... |
|
|
So in this case if the cookie has not been presented to OTD by the client browser then OTD will add a cookie called "MyApp" with a value of the current time. (In seconds since the epoch). The client will then present this cookie in all subsequent requests. It is possible to set additional options such as the
domain and
path which can specify when the client will send the cookie or to set a
max-age parameter which will make the cookie persistent with the browser and last for the duration specified, in seconds. In our example the
max-age is not set so the cookie will last for the duration of the session. (until the browser is shutdown)
Handy Hint
With unix it is fairly easy to get the current time in seconds since the epoch using the
# date +%s command which will simply format the current date. Or to convert from a number of seconds to a meaningful date use
# date -d @1402655677
Setting up a Routing Rule
Having added the cookie we now have something that we can easily use to route with. This can be done either by editing the
obj.conf file directly or using the browser interface which provides some help in ensuring that the syntax is correct. To add/edit routing rules simple ensure that you have selected the configuration you want to manage and then open up the virtual server in the navigation pane and it is possible to then add the routing rules.
In our scenario we are going to add a routing rule that will inspect the "MyApp" cookie and if the value is greater than a set time then route the request to the next version of the application. This could be as simple as routing to a different origin server pool if the new application has been setup in an entirely different set of WLS instances, or as in this case the rule will cause a re-write of the request to access a different URL where the two applications (new and old) are both held in the same application server but with different base URLs.
 |
| Routing rules to direct requests to the new app version |
These rules can then be deployed to the server instances which again is done dynamically with no down time. Then when the clients access the service if not present they will have the "MyApp" cookie added to their browser and each request is then checked against the cookie value and if the value is greater than the time specified in the rule then the request will be routed to the second version of the application. Sessions that started on before the cutoff time will continue to use the previous version of the application using the default rules. (or other routing rules.)
The changes to the routing rules are reflected in the obj.conf file as shown below.
#
# Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.
#
# You can edit this file, but comments and formatting changes
# might be lost when you use the administration GUI or CLI.
<Object name="default">
AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true"
<If defined $cookie{"MyApp"} and $cookie{"MyApp"} gt "1402483929">
NameTrans fn="assign-name" id="myapp-v2" name="myapp-v2"
</If>
NameTrans fn="assign-name" id="default-route" name="default-route"
NameTrans fn="map" from="/" to="/"
<If not defined $cookie{"MyApp"}>
ObjectType fn="set-cookie" name="MyApp" value="$time"
</If>
Service fn="proxy-retrieve" method="*"
AddLog fn="flex-log"
</Object>
<Object name="default-route">
Route fn="set-origin-server" origin-server-pool="origin-server-pool-1"
</Object>
<Object name="myapp-v2">
NameTrans fn="map" to="/MyApp-v2" from="/MyApp"
Route fn="set-origin-server" origin-server-pool="origin-server-pool-1"
</Object> |
|
|
Obviously once the previous application version has been fully retired then the default rule can be used to direct to the new version and this routing rule deleted. Potentially the cookie injection can also be removed.
Conclusion
With a very simple configuration consisting of a single cookie injection and a routing rule it is possible to use Traffic Director to manage different application versions.
