-1

I have a small AngularJS web application that runs in kiosks in an intranet network. I've been tasked to make deployments without downtime and in an automated way that can be controlled remotely with a web interface. Since it's a small application, we do not have load balancers or similar setups. I've looked at two options,

Option 1: Download versions of the application in a folder and change the Virtual Directory's Physical Path to the folder path of a new version, this is achievable using Microsoft.Web.Administration library with the following code,

            ServerManager sm = new ServerManager();
            Site site = sm.Sites["Default Web Site"];            
            site.Applications[virtualDirectory].VirtualDirectories["/"].PhysicalPath = newPath;
            sm.CommitChanges();

In this approach,

  1. How quickly will the switch be reflected?
  2. What are the chances that some of the kiosks still working with the older version of the application?
  3. Is there any chance for a downtime in between the short period of time the switch is made?
  4. Will any requests made to IIS in this period time return errors?

Option 2: Using IIS' URL Rewrite feature. Basically I'll be programmatically adding new rewrite rules to the application's web.config to redirect to a different subfolder which will be the newer version of the application.

In this approach,

  1. How quickly will the URL rewrite rule reflect and the rewrite begin?
  2. What are the chances that some of the kiosks still working with the older version of the application
  3. Is there any chance for a downtime in between the period of time when the rewrite rule is added to the web.config?
  4. Will any requests made to IIS in this period time return errors?
  5. Will there be any performance cost for the URL rewrite?

Kindly help me out. Are both of these approaches not suited for my task? Are there any other alternatives to this requirement?

user1890098
  • 99
  • 1
  • Do these kiosks require 24/7 365 availability? If not, you don't need 0 downtime, just a time you can deploy. Regardless of what Lex Li says, you can use MSDeploy to do what you are asking if you eliminate the 0 downtime part. You just have to understand how to use it first. If you truly need 0 downtime, then you'll need something to manage this, be it another website within IIS and switching between them or a device to handle it for you. URL Rewrite works by changing web.config. Changing web.config restarts the site's app pool, which will lead to downtime, albeit, very short downtime. – DubStep Aug 21 '20 at 20:21
  • Actually, I can think of a way to do this too. Deploying your updated version of the app to a new physical path, then switching the physical path of the virtual directory. That will still recycle the site (you can't get around that) but it should be fairly transparent on the user side. Instead of an error, there will be a loading delay while the app pool recycles. At least I don't think there would be a 503 error, since the app pool technically never stops. You should test that theory out though if that isn't obvious. – DubStep Aug 21 '20 at 21:26

1 Answers1

-1

MSDeploy should be able to handle the automated and remote deployment part. If you don't have another server or another way to send application traffic to a different virtual directory in an automated fashion, no downtime is not a practical request. It's like saying I have 1 car, but I want to be able to keep driving it while it is in the shop. If you want a car to drive while your car is in the shop, you'll need another car, temporary or otherwise.

DubStep
  • 270
  • 2
  • 9
  • Though it is kind of a bad question above, this answer does not look good enough. MSDeploy can lead to significant downtime for a single server setup, which can be improved by using other approaches. – Lex Li Aug 19 '20 at 21:31
  • @lex li what other approaches can I look at? I've looked at the Blue Green approach using ARR. Will that be a viable solution? – user1890098 Aug 20 '20 at 04:52
  • @LexLi I said that MSDeploy would handle the automated and remote deployment parts, not the no downtime part. You can't really accomplish that with a single server setup, because you are likely using a web.config file, and modifying that file causes an app pool recycle. That's why I stated zero downtime isn't really practical with a single server setup in IIS alone. I think you said exactly what I said with less detail. If you are down voting anything, it should be the question and not my answer. – DubStep Aug 21 '20 at 18:51
  • I commented and down-voted because even the options in the question body are better than what you proposed as an answer. – Lex Li Aug 21 '20 at 19:13
  • @LexLi that is certainly your opinion, I just disagree that options in the question are better. They are based on a single server setup, and talk about 0 downtime, which is an issue within itself. You say MSDeploy can lead to significant downtime, without explicitly explain why. MSDeploy itself is not bad. Not understanding how to use it can certainly lead to mistakes. But on that same token, that can apply to anything. Deleting a folder could lead to significant downtime for example. That is why test environments exist. Doing any of this without one is asking for trouble. – DubStep Aug 21 '20 at 20:14
  • @LexLi care to give an example of how MSDeploy can leave to significant downtime or provide one of these "other approaches" you mention? I guess this also means I should answer less questions on here, since someone can down vote without even explaining anything, or even answering the question, while at the same time criticizing the answer someone gives and saying there is a better way to do it, but not providing them even after OP asks. – DubStep Aug 21 '20 at 21:34
  • 2
    An app pool recycle doesn't cause downtime. The new app instance is brought up, and only once that instance is ready to handle requests, the old one stops accepting requests, and once the old one's outstanding requests are completed only then is it terminated. – Mark Sowul Sep 03 '21 at 14:13
  • @MarkSowul It depends on what we define as downtime. While modifying web.config causes a recycle in the form you stated, if you have session state managed in the IIS worker process (in-proc session state management) for example, that recycle isn't going to cause downtime per say, but it will cause those sessions to be invalidated, so an unwanted user experience at best. Which end users will likely call down. – DubStep Sep 08 '21 at 22:05
  • That there exist scenarios where it's not possible (e.g. in-process session state) doesn't mean it's not a practical request. I am poking around this topic because I'm wondering if e.g. setting an increased system.web/httpRuntime - waitChangeNotification can let me leverage the shadow copying feature to just replace the files and finally the web.config and have it get updated while it's running and automatically recycle to the new version – Mark Sowul Sep 17 '21 at 21:28
  • It's important to distinguish these. It's all solvable, but separately (it's not an "either/or"). Session state is an architectural consideration of the web app itself. Deployments aren't the only time a recycle can happen: updates, various config changes, or manually by a server admin (might be memory/resource issues or a stuck worker process). If an app needs to handle those situations (which most should, IMO), it needs to change the way it's tracking "session state", which is within the developer's domain. (there's various options, but my point is that's *unrelated* to how you deploy) – DotNetSparky Sep 23 '21 at 04:02