It's mind blowing to me that people still ship software by copying a file to a machine and restarting a service.
I'm very unfamiliar with IIS hosting though, does it support any kind of containerisation/deployment immutability at all?
I'm very unfamiliar with IIS hosting though, does it support any kind of containerisation/deployment immutability at all?
So while this is absolutely ancient tech and process by most means, it has been a huge step up from copying files over to machines by hand through RDP connections.
And also, our apps have no problems having even a few minutes' downtime, so cold restarts are absolutely fine for us.
While I would absolutely like to get into containerized zero downtime deployments, from where we're actually standing now, those don't seem to be offer much in the way of ROI.
And please, if anyone has a more suitable process in mind, please let me know!
Otherwise, on our fleet of hundreds of IIS, we've had success just pointing IIS to a hardlink, deploying the new version to a new folder and updating the hardlink - from memory this does trigger an app pool restart but its super fast, lets you go back and forth very easily.
Some random IIS capabilities include:
- You can edit any part of the IIS configuration live, and this won't require a service restart. You can even edit .NET application code and configuration files live, and changes can take effect non-disruptively even if a process restart is required for the virtual app. IIS will buffer requests and overlap the new process with the old one. https://learn.microsoft.com/en-us/previous-versions/iis/6.0-...
- Web Deploy is basically just a zip file of a web application that can be produced by Visual Studio, vaguely similar to packaging up a site and its config with Docker: https://www.iis.net/downloads/microsoft/web-deploy
- Visual Studio integrates directly with IIS using "publish" settings that can target an IIS server and be used to deploy a complete web app with a button-press from the IDE: https://learn.microsoft.com/en-us/visualstudio/deployment/tu...
- The volume shadow service can be utilised by IIS to create backups of its entire configuration including all files on a schedule: https://usavps.com/blog/13597/
- Shared configuration allows scale-out web farms to be created. The key IIS config files and web content are moved to a UNC file share and then the workers just "point" at this. With an external load balancer that supports traffic draining this allows for seamless OS reboots, upgrades, etc... There's even a trick where SMB Caching is used to automatically and transparently create a local disk cache of the shared content, allowing IOPS to scale with web farm server instances without any manual deploy or sync operations. https://learn.microsoft.com/en-us/iis/web-hosting/configurin...
- The above goes hand-in-hand with Centralized SSL Certificate Support: https://learn.microsoft.com/en-us/iis/get-started/whats-new-...
If you want to use container technology on Windows for web apps, you can do that too. Windows Server supports Windows Containers, and ASP.NET Core has excellent support with a whole bunch of pre-prepared base container images for both Windows and Linux hosts.
If you have many such sites on a Windows web host, you would use the IIS Application Request Routing reverse proxy to add HTTPS to back-end containers running on HTTP. That, or just use Azure App Service, or YARP, or...
Personally, if I had to run a large-scale IIS web farm again, I would keep things simple and just use the Azure DevOps agent with the IISWebAppDeploymentOnMachineGroup task: https://learn.microsoft.com/en-us/azure/devops/pipelines/tas...
The last time I hosted a web app on it was... sucks breath.. wow... before NGINX existed!
In any case, it doesn't matter now, Windows Server is on maintenance mode and Microsoft is clearly done except for cashing licensing checks. Linux is the (web) server future.
Unix got it right, text config, sighup the processes to pick up any config changes and away you go. Requires more work from Admins, much cleaner in the long run.