The modern enterprise web-services’ provision is based on 24/7 accessibility, which becomes especially important for those of them, that are dependent on frequent re-deployments (i.e. updates). Normally, at this time your server goes down, which causes not just a temporary profit loss, but also the reduction of users’ trust, which is unacceptable for any paid service.
A huge branch of tools like Capistrano, Fabric, etc can help you to solve this problem – for example, through setting multiple servers with a load-balancer as a frontend, which will update them alternately. However, all of such utilities have certain additional requirements, which results in increased expenses, and needs some time and specialist knowledge for being integrated and properly adjusted. Obviously, such implementations appear to be rather complicated and require a lot of extra resources, thus a better method is needed.
Recently, a completely new approach in this area was proposed for PHP applications, running on top of Apache, by the founder of this programming language and, simultaneously, our technical advisor – Rasmus Lerdorf. This is actively used at Etsy, and, therefore, being a battle-tested solution, it was taken as the basis for the Zero Downtime Deployment feature implementation in Jelastic. Its main idea rests on the following two points:
- each time a new deployment process is run, the corresponding app’s files are duplicated, being stored in a separate server directory (which is automatically named after its creation date/time for easy identification)
- a special requests’ redirector, called symlink (i.e. symbolic link), switches between different app versions after each update, pointing to the one that should be currently used.
In such a way, the updated project files can be seamlessly deployed, while the initial code version continues working and handling users’ sessions. And when the deployment is fully completed, the symlink instantly switches to the most recent version of the successfully deployed app, starting to redirect all the incoming requests to it. All of these together makes the deployment process fully atomic and implicit for your customers, simultaneously relieving you from performing plenty of envisioned manual operations.
Below, we’ll discover this mechanism in more detail by consequentially describing the ZDT deployment workflow and the way this functionality has been implemented at Jelastic. And in order to make sure this approach is efficient, at the very end of this article you can find the comparison of ZDT and classic deployment methods, performed through running the set of load tests with the help of JMeter.
So, let’s get started!
ZDT Deployment Workflow
First of all, we’ll consider more specifically how the above described PHP zero-downtime deployment mechanism actually works on Jelastic – let’s examine all of these processes step-by-step with a real example.
- To start with, you’ll need a PHP environment (either a new or the already existing one) – we’ll use Apache for this example:
- Next, proceed to the deployment of the required application. During this procedure, you need to tick the corresponding checkbox at the appropriate confirmation frame (depending on the project source type used) in order to enable the ZDT deployment option:
- for deployment via local file or direct URL
- During the initial deployment, a ROOT_timestamp (i.e. ROOT_year.mm.dd-hh.mm.ss) folder and a special ROOT file as a symlink to this folder are created inside the webroot directory of your application server.
As normal, the application is ready to handle requests just after the deployment process is finished.
- During the second deployment (i.e. when deploying an update), a new ROOT_timestamp folder is created – in such a way, the actual application version and customers, that are currently working with it, are not influenced.
Just after the new files are unpacked, symlink switches to this new folder, redirecting all the newly received requests to it. Herewith, the first folder is kept for processing the “old” users’ sessions (i.e. where handling started before the symlink switching).
- All the following deployments will be performed in the similar way. During each of them, the oldest project folder is removed, while a new ROOT_timestamp directory for the most recent project version is added.
In such a way, only 2 versions of a deployed application – the latest and the previous one – are stored within an app server simultaneously (however, the older one can also be easily removed manually when it is no longer needed). This ensures no extra disk space consumption.
All of the operations are fully automated, thus no additional developer’s involvement is required, while the deployment itself is performed in a “soft” mode, i.e. even without an app server restart needed and, as a result, without any application downtime.
ZDT Implementation at PHP Servers
Delving into the details of technical implementation, the zero-downtime deployment option support at Jelastic is ensured by the following adjustments, applied to the corresponding PHP instances:
- Apache PHP
The appropriate functionality is handled with the help of the mod_realdoc module, which controls the abovementioned symlink switching. It can be additionally configured (if required) through the Jelastic dashboard within the conf.d > mod_realdoc.conf file.
For more information on this module’s specifics, visit its source page.
Here, ZDT deployment is ensured by means of the in-built functionality with no additional modules inclusion – the corresponding settings can be found at the very end of the conf > nginx.conf file:
For now, as you know how all of this works, we can compare both classic and ZDT deployment methods.
Comparison and Summary
To prove the benefits of the ZDT update approach, a simple load test was run, with the following parameters as a basis:
- application – a basic version of WordPress CMS deployed (i.e. its default distribution with no heavy content comprised)
- load generation tool – Apache JMeter, configured to continuously send the required amount of concurrent requests to our application during the redeployment process
- time frame – the test starts a short time before the redeployment process is run and finishes a few seconds after it is completed
So, let’s evaluate the results for both deployment methods with the simple statistics we’ve received.
Let’s start with the most commonly used variant of the project deployment, namely – classic, i.e. installation from a single archived package with no extra options like ZDT enabled:
As you can see, we actually get pretty good results:
- quick and steady response time (the blue graph), only 1.2 seconds on average
- fast restoration to the normal operability (i.e. when all of the incoming requests are successfully processed (the green line) with no errors (the red graph) occurred) after the new package deployment
- fails to appear for two seconds only – see the red line spike (however, deploying a more heavy and content-replete project will increase this interval for certain)
Now, let’s perform the same test with the second competitor – ZDT. For a better comparison perception, we’ll keep the same color legend as before:
Response time remains stable and almost unchanged, but you can notice its slight enlargement during the update procedure, which is caused by the additional deployment process running alongside the serving of requests. Herewith, there isn’t even a single error during the whole test.
So, in such a way, we can assume that zero downtime deployment overcomes the problem of failed requests during application redeployment, simultaneously keeping the average response time on the same level. In addition, the ZDT option leaves you a possibility to save all of the user-generated content, located inside the application directory, and easily move it to the new app’s version if necessary (while the classic method normally implies just the entirely new app version deployment)
Next, let’s repeat our test for the second Jelastic deployment type (i.e. if using Git/SVN repos) in order to find out whether ZDT retains its advantages in this case. And again we’ll start with the classic method:
As the deployment sources are placed at the remote resource, this will require a little more time compared to the installation from the already uploaded archive, which, actually, helps us to clearly see the difference. The response time now has a pretty long drop down (for nearly 4 seconds in our case), caused by the unavailability of the application (you can see that incoming requests start to fail at the same time – this is shown with a spike at the errors graph). Everything else remains similar to the previous deployment type.
Finally, the last test for the ZDT deployment approach via VCS also goes in line with our expectations by bringing a stable response time with its small incrementation during the simultaneous running of such operations as users’ sessions handling and project copying/updating.
At the same time, you can see that no errors appeared and all of the incoming requests are successfully processed.
Now, when you have all the information (both raw technical and visualized in graphs practical one) on the investigation and have seen how it’s easy to use the ZDT option within Jelastic Cloud, it’s time to summarize and make a conclusion on the key benefits it brings for your PHP app’s hosting:
- ZDT doesn’t require any additional resources like separate instances/tools for being applied – all you need is just enough disk space for storing two project versions (current and the previous one). It could be considered as an almost free of charge solution, especially compared with the majority of other possible options, which may require additional app servers, balancers, external services, etc.
- the deployment remains just as simple as before – no additional configurations or human intervention is required
- the time needed for the ZDT deployment is exactly the same as for the classic method, so no delays are expected
- finally, Zero-Downtime deployment stands by its name by ensuring it’s completely implicit for your customers with an errorless updating procedure (in contrast to the classic variant, which, without being additionally improved, causes a pretty big amount of errors even in the case of a small application redeployment)
In such a way, ZDT deployment usage makes updating of your projects completely painless and invisible to customers, helping you to get the most from your application!
Stay tuned for more new cool hosting options Jelastic Cloud provides with our blog. And in case you’d like to test all of the things we are talking about in practice – don’t hesitate to create a two-week trial account at any of the available Jelastic installations and try it yourself for free!