Zero down time deployment, sounds like a pretty cool jargon for me and it will impress a few people out there. However, what is it really? How do we do it? That’s the question that I was asking and what you should be asking if you are working on high availability web applications for your clients or for yourself.
In its very core, zero down time means that during any software deployment, be it a small patch or a large upgrade, we should never suffer from any down time. While it may not always possible to do so, for example during a large database upgrade where the data must-not change, we should always strife to achieve this.
Nowadays we have virtualization technologies which makes achieving zero downtime deployment slightly easier. In the past, with all of the needs to rebuild physical hardware, zero down time deployment is not so straightforward. We’ll see what l mean after the explanation.
Requirement for Zero Downtime Deployment
- Virtual private servers. This can be any VPS from any providers such as Digital Ocean or Amazon We b Services.
- Access to creating virtual machine image out of your existing machine.
- Full control of your DNS records
- Where applicable, full control of the load balancer
Today we are going over the way to do this manually without any automation. The idea is that if we understand the basics then automation can be easier.
Let’s use the following case study as our example today. I have a website with constant traffic every minute, it’s all well and good. However to ensure that I am not hitting the server limit, I would like to upgrade to a larger machine. Let’s assume that the database server is hosted separate to the web server and the server that we are upgrading is the web server.
Traditionally, if you are using a shared server or a physical server we would have to take down the website, then commence with the hardware upgrades then lastly turn the website on again.
Here’s what we can do these days:
- Create an Image out of your running web server.
- Spin up a new virtual machine instance with bigger specification, using the image from the previous step. Let’s call this server B.
- Make sure that server B was instantiated properly, check disk space, permissions, memory, etc.
- To test if the Website is configured and looking all right in server B, point your desktop’s host file into the new machine’s IP.
- Once verified, login into your DNS provider and point your domain name to your new machine.
- Alternatively, if you are using a load balancer then simply take out the old machine out off the pool and include the new one in.
That’s it! In a sense, the above steps are really the basics of zero downtime deployment. If you want to get fancy and automate then we can use something like AWS’ Cloud formation templates or create a script that calls the Apl of your hosting provider it the offer you access such as Digital Ocean.
So you have just learned about the basics of zero downtime deployment. In a follow up article, I will demonstrate this with a real test instance.
deployment, devops, server