2

I use Git to manage the development cycle of my web application, and for changes where a git pull is enough and no changes needed, I just naturally keep the site up and git pull the changes.

But I'm thinking, say I have 100 files changed, and say there was some unexpected load on the disk, what happens if someone does a request during the moment that git was committing changes on disk? Wouldn't that make my application possibly vulnerable to possible data corruption or malformed responses?

I mean this is very, very unlikely for a low traffic website, but if you get some really high traffic, and happens to be a spike server load, there's some risk.

I actually thought of a solution but it is probably not the best if I roll my own implementation and I'm rather not sure if its practical. I remember reading an article on how we do not see artifacts on our screens, basically by writing new data to an entirely different block on the GPU memory, and then just switching the up to date screen data (whatever that is called) pointer to the new block, and possibly discarding or reusing the old block in the end. This way if a GPU lags no half-written data will be shown

Would this be practical if one could implement such a similar thing?

OverCoder
  • 143
  • 1
  • 8
  • 3
    Lots of sites handle this via blue/green deployments - spool up servers with the new version of the code, then switch (at the load-balancer level) when it's all deployed and ready. – ceejayoz Jun 21 '17 at 00:26
  • Something like HA proxy? Whatever the application you run, if you want 100% uptime and no such risks you described, you need a very minimum of two servers serving the same thing. – Marco Jun 21 '17 at 00:29
  • So a load-balancer would be a requirement for this in this case? I imagine that this would very intensively slow deployments (a second to minutes maybe) since, speaking at a good scale, one can't simply keep only few of servers up and upgrade all others (because load), making me think for a really large scale different people from different countries will get changes faster than others given a lot of servers have to be upgraded. This will make automated deployment ever more trickier – OverCoder Jun 21 '17 at 00:36
  • 1
    Done properly, it doesn't add much time. Your load issue is a) not an issue if you've got an appropriate amount of capacity to handle bursts of traffic and b) trivially solved if you're on cloud hosting - you fire up new instances for the new version, i.e. you're running at *lower* load during the deploy. Unless you're running the stock market or something, it probably doesn't matter at all if some users get the changes a few seconds after others. – ceejayoz Jun 21 '17 at 00:45
  • @ceejayoz I am just starting to realize now how cloud hosting is actually more reliable and easily scalable than using dedicated servers. Good thing, I've got to make quite of a research upon soon. – OverCoder Jun 21 '17 at 00:53
  • 1
    @OverCoder "I am just starting to realize now how cloud hosting is actually more reliable and easily scalable than using dedicated servers." Lemme fix that for you: "I am just starting to realize now how cloud hosting **can be, if implemented correctly,** actually more reliable and easily scalable than using dedicated servers." – EEAA Jun 21 '17 at 21:10
  • Products like K8s, AWS ECS, etc. can help automate much of this process. We use ECS extensively, and it's a *boon* for both helping to manage high availability as well as ease of deployments. – EEAA Jun 21 '17 at 21:11
  • Question title doesn't match content. For example updating a symlink [deletes it](http://blog.moertel.com/posts/2005-08-22-how-to-change-symlinks-atomically.html) for a sub-milisecond time span, so the target is **down** but there is no risk for **inconsistency**. It's relevant as one answer proposes to symlink the entire website. – kubanczyk Jun 22 '17 at 05:06

2 Answers2

3

You will want a load balancer. It can provide rolling upgrades, high availability, and scale out.

Large, non trivial, but somehow always up websites change ever so slightly constantly. Perhaps they are rolling out a daily update, or some feature failed but things still run. They have decided that a slightly different user experience is not worth shutting down. You will need to make your own decision about if your solution includes planned downtime.

On the individual web server, certain deployment methods make for a sharper transition. Pre deploying the code and then moving it into place is a cleaner cut than updating the working copy live. Although this does not account for databases, web server updates, and other complications. You still want a load balancer to give you options.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
0

One of the canonical way to do this, irrespective of the fact you are using git or not (but using it you can implement this scheme with some of its hooks), is to have a directory on the website where you install each new "version" in its own specific directory, for example with a date/timestamp in its name. The true live currently used content by the webserver is in another path which is a symlink to one "version" directory.

After your transfer has finished, and after you have checked that everything went well (no missing files, plausible content, correct Unix rights, no dangling symlinks, etc…), you just have to change the symlink from the "production" path to your new "version" path.

Changing the symlink is almost atomic, so it would not cause any disruption.

This also allows you to easily go back: just change the symlink again.

Patrick Mevzek
  • 9,921
  • 7
  • 32
  • 43