Soft Relaunch with Nginx Fallbacks

by|inArticles||2 min read
Nginx Fallbacks
Nginx Fallbacks

Recently I was replacing a module of our company page. I changed a lot of things below regarding content management. Besides this all other modules remained the same. To split things up in a more clear way, I decided to move the new module (CMS) to an own repository. As well I used a slightly different approach by using Servant instead of Yesod.

The most part of the content relates to blog posts. Unfortunately the old and new structure of the content below is not compatible. Furthermore — since the old content has been written to the database in HTML and the new content in JSON — I was not able to just port all posts automatically. Or, let’s say I wanted to go post by post, rewrite and correct things left and right on top. I’m sure there would have been ways to script things.

If you choose this kind of approach, where you can not just do a “big bang” release, you need to find a solution to go step by step. Especially since all blog posts are indexed in search engines and it would be a pity to loose this.

So, what I came up with is a fallback in Nginx which works like this:

  1. Switch the default upstream server for blog urls to the new module
  2. If the module delivers a 404 (meaning the blog post was not ported yet) fall back to the origin blog post from the old module

So let’s see how the definition looked like before (I will use upstream and upstream-v2 as host names for the applications behind):

location / {
  ...
  proxy_pass http://upstream:3000;
  ...
}

We will keep this entry and add the blog route above it:

location /blog {
  proxy_pass http://upstream-v2:8888;
  
  # if v2 app location returns a 404, then use the fallback
  proxy_intercept_errors on;
  error_page 404 = @fallback;
}
location / {
  ...
  proxy_pass http://upstream:3000;
  ...
}

As you can see we added the fallback location in case of a 404 page. So, the only thing left to do is adding this location, which points to the origin application (v1). I will set a custom header as well so we can see each time Nginx is falling back from the v2 version.

location @fallback {
  proxy_set_header X-App-Fallback "v2";
  proxy_pass https://upstream:3000;
}

And that’s it. Rewritten blog posts are now served from our new application. Old blog posts are still there. No changes in URL structure has been done.

Thank you for reading this far! Let’s connect. You can @ me on X (@debilofant) with comments, or feel free to follow. Please like/share this article so that it reaches others as well.

Related Articles

© Copyright 2024 - ersocon.net - All rights reservedVer. 415