Web Farm deployments?

Question

User-2106141979 posted

Since WFF2 has been deprecated and no longer even installs on ISS 10 without hackery there is no automatic way to distribute a web application or site to an IIS Web Farm.

The current documentation appears to suggest that:

• Web Deploy can replace Application Center in almost all scenarios. (what the hell is Application Centre though?)
• Just use a shared folder and shared config to share deployments across a web farm.

So, thinking about this: Using a shared folder means that, if/when I msdeploy to one server in my server farm, it needs to obtain a write lock to the asp.net core dll's. So it will write the appoffline.htm file. Which will take every site in the entire farm down all at once. And if any server is underperforming / stuck, a bunch of servers will go offline, and wait, while we try and figure out which servers are causing the deployment to choke.

So that article is stupid and dangerous.

The next option is to have my CI/CD publish pipeline simply msdeploy to my (for example) 3 application servers. But this means that at the point of deployment, my load balancer might split requests for a single client across servers where 1 is running v2, 1 is offline as its being updated and one is still serving v1 of the app.

So, whats the best practice way out of this hole? Which doesn't involve downtime, or serving invalid mixes of content during deployments? And is compatible with a hands-off fully automated CI/CD approach to deployments?

Answer 1

User690216013 posted

If you look for an end-to-end solution, Microsoft only has Azure Stack or the public Azure.

If you prefer a small scope solution for traditional web farms, which Microsoft no longer cares that much, you have to search for third party options or develop your own upon the basic components Microsoft provides.

Answer 2

User-2064283741 posted

There are a few ways to do these things.

Most simply the old school way. 

Let say you servers A and B in a farm

Take server A out of the farm, leaving traffic to goto server B.

Deploy (copy files) to Server A and when happy/tested/etc switch the farm so that only traffic is going to server A. Then deploy to server B.

Then add server B back to the farm.

This is the simplest way and what has been done for decades.

Now everyone wants buzz words of continuous deployment you have to make sure you software is written in such a way that it will work pushing code out at different times independently. This often means deploys can be done on just 1 box without any meaningful downtime. So no "locking" of the app of the process that you cannot deploy.

Personally unless you "NEED" to deploy dozens of times a day (and you probably don't) do the easy method once a week.

Deployment tools like Octopus, TFS, you own scripts, etc can help better ways to deploy. Maybe you want to push the code out to a new directory (some deploys can take ages if you have GBs in there)  and once copied it can update the IIS config to a new directory. Or push a simple txt file that then flag to one of the server in a farm offline (that you use in the health check)

There are many ways to do stuff and you need to work out what works best for you.

You could be a small basic little traffic/revenue with a 1 sites and a monthly deploy cycle and no budget. You could be running a multi million banking apps were even a few seconds of downtime is large amounts lost and a budget for the most simple tools.

Answer 3

User-2106141979 posted

Whether its "Continuous deployment" or simply automated, what bugs me is any kind of manual process which entails anyone accessing each server individually. The scope for taking the wrong server out the pool, or deploying in the wrong direction or some other momentary lapse is there.

Our existing corporate "solution" consists of F5(s) for nlb, octopus for deployment, and a complete division between dev, and ops

I'm architecting a new product that I want to be more devops , and am having a hard time figuring out which bits of IIS still actually work as, despite the lip service given, the product seems to have been largely abandoned, with documentation that is now frequently actively misleading.

So, I am sure there are many ways to do stuff, but I'm working in a knowledge vacuum, trying to discern best practices that actually work. I don't even know if there are dashboards or something that might be used to orchestrate these kind of deployments or if thats something i'd have to make.

Answer 4

User-2106141979 posted

@Lextm

This is not making much sense to me atm. I'm looking at web hosting on Azure and Azure seems to offer VM's. On which I would provision IIS. So, presumably, I would have to answer the same questions on, or off, Azure. Unless Microsofts real intention is to drive users to Nginx.