CODEWITHSUNDEEP
angularjsamazon-web-servicesdeployment
Luca
Luca

Reputation: 281

Zero downtime deployment for angular app

I have a restful angular app that is hosted on a AWS and I'm looking for a clean and quick deployment solution to put the new site live without taking down the previous. I don't have much DevOps experience so any advice would be great. The site is full RESTFUL so its just static pages.

I was looking at setting up a dokku with AWS plugin solution but was pretty sure its overkill and may not be able to detect my app because its just static pages (no node, rails, etc).

Upvotes: 2

Views: 2606

Answers (5)

Will Hartung
Will Hartung

Reputation: 118804

The best way to do this is to reconfigure the web server on the fly to point to the new application.

Install the new version of the app to a new location, update the web server config files to point to the new location, and reload the server.

For inflight requests, they will be satisfied by the old application, and all the new requests will hit the new application, with no down time between them save for the trivial delay when refreshing the web server (don't restart it, just tickle it to reload it's configuration files).

Similarly, you can do this solely at the file system, by installing the new app in a new directory parallel to the old one. Then:

mv appdir appdir.bak
mv appdir.new appdir

But this is not zero downtime, but it is a very, very short down time as the two inodes are renamed. Just ensure that both the new and old directories are on the same filesystem, and the mv will be instantaneous. The advantage is that you can trivially "undo" the operation in the same way.

There IS a window where you have no app at all. For a fraction of a second there will be no appdir, and you will serve up 404's for those few microseconds. So, do it when the system is quiet. But it's trivial to instrument and do.

Upvotes: 2

Luca
Luca

Reputation: 281

We ended up going with TeamCity for our build/tests and deploying via Shipit.

https://github.com/shipitjs/grunt-shipit

https://www.jetbrains.com/teamcity/

Upvotes: 1

Elliot Swart
Elliot Swart

Reputation: 439

An easy solution to this is to always be running two instances, a production and a staging. These guys should be identical and interchangeable (because they are going to switch. Assign an elastic ip to your production. When it's time to update, copy the code onto the staging, make sure it's working, and then attach the elastic ip to staging. It is now production and production is now staging. This is not an ideal solution but it is very easy and the same principals apply to better solutions.

A better solution involves an elastic load balancer. Make sure you have 2 instances attached. When it is time to update, detach an instance, perform your update, make sure it is working and reattach it. Now you will have a brief point in time where the client could get either your new website or your old website. Detach the other old note, perform the update and reattach.

The fact of the matter is even if you just overwrite files on the live server there will only be a 10ms window or so where the client could get a new version of one file (e.g. the html) and the old version of another (e.g. the css). After that it will be perfect again.

Upvotes: 0

Wayne Ellery
Wayne Ellery

Reputation: 7958

A simple solution is to use a ELB. This will enable you to deploy a new instance, deploy the code, test it, update the ELB to switch traffic to the new instance and then you can then remove the old instance.

Upvotes: 0

tsdaemon
tsdaemon

Reputation: 1557

Try to use git repo for live deployment https://danbarber.me/using-git-for-deployment/

Upvotes: 0

Related Questions