Monday, March 18, 2013
Zero Down Time Deployment Technique: Versioned Re-Deployment
Recently we tried out an experiment about Web Logic's production redeployment strategy involves deploying an updated version of an application alongside an older version of that same application in Local Server.
Scenario:
Consider the following scenario, we have an Monitoring_Application which used to monitor weblogic servers, terracotta servers and Unix Servers.
Which have two versions,
Monitoring_Application(v1) -> Gold1 Color Background -> Old Version
Monitoring_Application(v2) -> Cadet Blue4 Color Background -> New Version
Simple flow of Versioned Redeployment:
![clip_image002[4]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh8vNnILY9ZkO6uolFO7Tr3VitTGAnaglohKSSr2X8Xj5ksDo74ar4TSZLcSpWtaXWSJ5eQYyZ4Garn__m88GbwQjORtFMBfknHs88qgK8WM4N_nnmN_ymr5xUgap55jMNLA3foix6rDbUL/?imgmax=800 "clip_image002[4]")
WebLogic Server automatically manages client connections so that only new client requests are directed to the new version of the application. Clients already connected to the application (clients that already have an HTTP Session object) during the redeployment continue to use the older version of the application until they complete their work, at which point WebLogic Server automatically retires the older application.
Versioned Deployment (V1):Gold 1 Background
![clip_image002[8]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhK9sj1Tag1_EwPHvnY26hU-QzON2HQw8tHlMKKT9DRdNme1Q0CKcUhvnpCthmPW6r26rm-kVeLmAFZ2cpO5e6fCCTelAgYWJDXnhyT74JgVdARrtmoKl3GvtvSDrNWL7OEkwxldphAW778/?imgmax=800 "clip_image002[8]")
Accessing the Versioned Deployment(V1):(Gold 1 Background)
![clip_image002[10]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvEVh1El06Nb9CNbGwlUpFToaYljJnZ7veP_velNpNoeKPelnSs-j9gLBqxetBl2Yh129a_B7spH2w9t43Tp0QtDBIJPQT8o5wiYBCrhnOXEr_C86PxBg0fKFb6DJ5zMbBxW2owESquaVj/?imgmax=800 "clip_image002[10]")
Versioned Deployment (V2):(Cadet Blue4 Color Background )
When we deploy the Version 2 of Monitoring_Application initially it will go to prepared state as usual and once we start "Servicing all requests" then,
V1 -> Go to Stop running state
V2 -> Go to Active State
![clip_image002[12]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiw3HVksLcSVs_OQDKVPEzneHuWUCb-J-gc6DUZPmyR0yv5oCYcrpWHy-LnZfag-MvihIGzBMXFL1N7BOsLZnpRvohkYoww7vuoa_jGRzDXRe8Mp1FQrBtgFhvaPMhvieqqlIS4Do3e9wY2/?imgmax=800 "clip_image002[12]")
In Firefox:
Browser Firefox which having the HTTP Session object ,still serve the V1 Monitoring_Application.
![clip_image002[14]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRI_RlqKgV-pIHA6yAmuTh9GV_y1hF8Rb22d8n5856tDJ2-UFLXefmO70SHUWhCInX5HwvXPm-KEYy33Ht1XNcFdnQ3uS5FRGNL_U6rRt6QCePA3Qs86Y65qeNf9wTm8FVXjJOdqnkCz2_/?imgmax=800 "clip_image002[14]")
In Internet Explorer:
At the same moment if we opened the same URL in some other browser like(IE), we could able to access the V2 Monitoring_Application.
![clip_image002[16]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYCNUBO4dpw5hKXlP5ss3nDXwBRQ1MrCQjjyjxLuEPsg-GSYhDxbJ2TZhu54DY1ixpSHmg9VH-Y007bnlb7rcLfieGcXJWc-3RmldNkflaYw6GhP52P09cGQ409i-9kLL_cLhdx0IoYmz4/?imgmax=800 "clip_image002[16]")
Retired Stage:
Once all the HTTP Session object cleared, then the old application automatically goto retired state.
![clip_image004[6]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKb_Vf9URv8m-KSgc1RVPuvsVD22QlU4hTXZ2d6Q_WHpJO24k049PrO77VpWVL1gSwTzQgsn0KLL2QeW_H2niTlvNqSF6nPBFVpMWlkSgyJ1m9GftoDscyrCzKTTrFy069gxQ93hvWh5PK/?imgmax=800 "clip_image004[6]")
Remove Old Version:
Once the old(v1) Monitoring_Application moved retired state then we can remove it from console.
This is an excellent feature from Oracle, I thoroughly enjoyed implementing it in one of our application.
If there is a need then you can implement it in your application to.
Scenario:
Consider the following scenario, we have an Monitoring_Application which used to monitor weblogic servers, terracotta servers and Unix Servers.
Which have two versions,
Monitoring_Application(v1) -> Gold1 Color Background -> Old Version
Monitoring_Application(v2) -> Cadet Blue4 Color Background -> New Version
Simple flow of Versioned Redeployment:
![clip_image002[4]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqxlY8bsqjQXQvI1W_Sw6wpIr3gUQ8zbsk4l0w1FIFIRAI2Yw9cdsozsFEn15RTFQaLTa8PdvutNVayzDy-hyydViOG_REnRHdTOl_3FRAdjrGumv9EB59sLLIbn04MOHGGCaxJv4Ex0vA/s1600-h/clip_image002%25255B4%25255D%25255B3%25255D.gif "clip_image002[4]")
WebLogic Server automatically manages client connections so that only new client requests are directed to the new version of the application. Clients already connected to the application (clients that already have an HTTP Session object) during the redeployment continue to use the older version of the application until they complete their work, at which point WebLogic Server automatically retires the older application.
Versioned Deployment (V1):Gold 1 Background
![clip_image002[8]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqHMWKyPFTL5aaBvqG6Offc51LexVzh_kmcooxVA17rGLo5V5u03psbPSelUojO9QA1kAKdE9_0lLKtdrA2KtfXeXiWL3UlyNnldCfJpT9vSO8yop8wNiK6Yn5XPEYVsJQYKT4DpTondeY/s1600-h/clip_image002%25255B8%25255D%25255B5%25255D.gif "clip_image002[8]")
Accessing the Versioned Deployment(V1):(Gold 1 Background)
![clip_image002[10]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJQCLm93hFvsYU5Ot3z7hMVLVIJmquywOvbHuQV0_YBxJPoWeGyTta8_6RN_mCWn9RsEvaZuNRW2l6LaLXb-YZRCsmBd4uonJ7lxMyWbwX17PbShEqScJC93Hp8svbSHxDlgRnA0r1kFFO/s1600-h/clip_image002%25255B10%25255D%25255B3%25255D.gif "clip_image002[10]")
Versioned Deployment (V2):(Cadet Blue4 Color Background )
When we deploy the Version 2 of Monitoring_Application initially it will go to prepared state as usual and once we start "Servicing all requests" then,
V1 -> Go to Stop running state
V2 -> Go to Active State
![clip_image002[12]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjW4cxLGtdNCtiOU7J9zyP0pZt3UQ_uC_y7_Dd7PmSVbz2E2vV0Gt2kI_wvS8l9oTma3xLMKPv6E35mVYmo1mXI25lP-bDSYytPNxne1K4dAM8yLaLeR-lARr2N655vI6sdhDVsfcARbTOR/s1600-h/clip_image002%25255B12%25255D%25255B5%25255D.gif "clip_image002[12]")
In Firefox:
Browser Firefox which having the HTTP Session object ,still serve the V1 Monitoring_Application.
![clip_image002[14]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8W-C66JBNLCGX2ubl428BkzBeNAhfXATBSz6FKilsozIWomE5-vEy8JCawCcqjJFs0CZ6DcasWoZDr7IUayCLFEqk3qebOyr7GU15mX-nBf1y3aG7oeSlSQxG6-O0K_aHKhUz5J65Bpgg/s1600-h/clip_image002%25255B14%25255D%25255B3%25255D.gif "clip_image002[14]")
In Internet Explorer:
At the same moment if we opened the same URL in some other browser like(IE), we could able to access the V2 Monitoring_Application.
![clip_image002[16]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcUmegMDC4_HWXG2ZIdMg-N9kLSreulpL2UEyDVyk7XDNI9SxRoF8wUmJzhQD5sY9VDkrGFCRzqTnpAULqASddp9zSphXTSL3zWJWziNJntKevfczDe8GcGl7Z-cVwf6JLulQiOtJKFx3-/s1600-h/clip_image002%25255B16%25255D%25255B3%25255D.gif "clip_image002[16]")
Retired Stage:
Once all the HTTP Session object cleared, then the old application automatically goto retired state.
![clip_image004[6]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6v8HnB1KtwXPgYo-jmulnSZC0v3Ww7PK-mqw_JDMmzxC6k0xJ21pMXrPOtqj4MpSRRh4eFWk4QTtgOoYc0gHVZJpnTOCvt0kdb1yXmEkfwDbcc_UqNuAp7vyqYmiWfZ3oGbl_7n95tKj_/s1600-h/clip_image004%25255B6%25255D%25255B3%25255D.gif "clip_image004[6]")
Remove Old Version:
Once the old(v1) Monitoring_Application moved retired state then we can remove it from console.
This is an excellent feature from Oracle, I thoroughly enjoyed implementing it in one of our application.
If there is a need then you can implement it in your application to.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment