We need to deploy our asp.net web site in web farm which consists of 16 web servers. Whenever we need to roll out a new release it is very time consuming and tedious as we need to deploy it first on the DR environment (16 web servers) and then on to Live environment (16 web servers).
Currently we prepare the msi on our build server and copy it on all the front end web servers which involves first FTPing the msi to a common location on hosting network and then copying from the common location to each server.
After thet we backup the existing website and then run the installer one by one on each machine.
After installing the new version we replace the web.config file with the older one as it is encrypted and hardly contains any new thing in it as part of new release. This saves us from encrypting the web.config file again.
Could somebody please suggest a better way of doing this deployement as it is really turning out to be time consuming. Previously this model was ok for us as we had only 4 web servers but not it is no longer a sutable option.
Thanks..
Take a look at the Web Farm Framework. It will handle the replication of your application across your entire farm.
Another option is to use the "Shared Configuration" option in IIS7 as well as a DFS share to replicate all of your files and metabase configuration. This just won't handle registry changes or the GAC.
Related
Is it possible to publish an ASP.NET (core) application to a running site on IIS 8 without having to stop and start the website manually?
Visual Studio 2015 keeps giving the error that a file is in use. I'm using publish to the file system, because my Web Deploy to a server in our network fails at the end with an error that it cannot authenticate on the server with port 443.
I don't mind IIS having to recycle the application pool, but when I constantly have to put the app down, publish (which takes about a minute) and restart it, it's not really good for the users.
Another option would be something like 2 websites running the same application, but only if this is automatable. Then it would put down 1 of the 2, update this, put it on, put down the second, update this and start it.
A third option is something like a hot update, where I could just update the application while it being on.
Can anyone point me in the right direction (perhaps some blog posts), because my Google searches didn't give me any good information?
If you copy a file called app_offline.htm to the application folder IIS will gracefully stop your application and start serving the contents of the app_offline.htm file. When application is stopped you can copy your files. After files are copied remove the app_offline.htm file and IIS will start your app. VS does that for you when you deploy to Azure but not when deploying to file system.
You mention "two websites running the same application". Do you mean two web servers hosting the same app?
If you already have multiple web servers (a.k.a. cluster of servers, or web farm), you can simply take some servers out of the cluster and update them. That is how we push out our updates. We use software from Citrix for managing the server farm. It also handles load balancing. This type of software allows one to monitor the servers, so you can determine when all the users have "moved" off the web servers (that were recently taken out of cluster). Then you can iisreset, deploy the new build, and move on to the next server (or set of servers, depending on your configuration). We have more than 20 virtual web servers. Typically we take down half of the servers, update them, and take the other half down as we put the first half back in the cluster/farm. This should allow for uninterrupted service. I understand you want to automate the process. I'll assume you're using Windows NLB (network load balancing). You could write a PowerShell script to automate taking down the servers. Here's a reference:
https://technet.microsoft.com/en-us/library/ee817138
I understand this may be viewed as a workaround. I'm not sure if recycling the app pool is always necessary with ASP.NET Core. I wasn't able to find a definitive answer. Most production applications should be on more than one web server anyway. Even if you don't have a lot of users, you should have multiple web servers for failover purposes.
I'm basically wondering what the best way to deploy an Asp.Net Web Site is, mostly from the point of view of security. Right now, I'm trying to publish the website using Visual Studio 2010. Could someone direct me to a good tutorial on how to do this securely? For example, can it be done over an encrypted connection via Visual Studio? Is it necessary to install any software on the server to do this? Should I use a different program to open up an SSL (TLS) connection first, and if so, which program (does it come standard with windows)?
The server is running Windows Server 2008. Development is on Vista.
Many thanks in advance for any direction in this matter!
Andrew
I would publish the site to your local machine and file copy the files across to your test/production environment. As a rule we don't publish sites straight from VS to test or production.
For example you don't want to accidentally push things straight from dev into a live environment do you?
As far as the file transfer security goes you could use SFTP.
Note: First thing is to check with the owner of the server, as they often will provide you an FTP connection and will take care of configuring IIS.
If you want to add security, make a keyfile and sign your assemblies and consider running Dotfuscator on your dlls, the community edition is included in Visual Studio. Here is an earlier question where I've put more info on Dotfuscator.
If you have to do the deployment yourself, here's a few things to consider.
XCopy (easy)
MSI (have to create a setup program, you can do this easily in Visual Studio)
There is no security advantage in deploying using Visual Studio, but you can use Visual Studio to create a small setup program. One thing you want to make sure for security is DO NOT deploy any .cs files. Prepare your files, you should compile in Release mode, make sure debug is not enabled in your config file, keep your bin and it's dll, also the aspx, asmx, ascx, svc, css, js, and config files.
XCopy: Install a small FTP server, or use one your company alreayd has, this will allow you to get your files once you are logged into the target machine. You should be able to get an administrator account for the target machine, just ask the sysadmin of the domain, then log on using remote desktop, got to your ftp site, and download your files. Open IIS on the target machine, create a virtual directory and a pool. Copy your files to the location, configure your connection string to your DB if you use one, then test your website.
MSI: same process as above, except the setup will create the virtual directory and pool for you.
Here is extra info on best practices from the official ASP.Net website.
If you have some control on the server (e.g. to configure IIS7), you might want to look into Microsoft Web Deploy (new product just been released):
http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx
Haven't tried it myself, but looks quite slick and it apparently encrypts the data being copied up, so might suit you.
How to deploy an asp.net webApp to multiple servers?
Deploy Web Applications Using the Copy Web Tool
also check thread
What method do you use to deploy ASP.Net applications to the wild?
It depends how many servers you're talking about.
For less than about 4 or 5 servers, I just zip the application, copy to each server, unzip into a new folder, and tell IIS to look at the new folder, using IIS Manager. In a load-balanced environment, it also means taking all servers except one offline, and then updating them one at a time, and bringing them back online afterwards.
For more servers than that, I prefer to use Windows Deployment Services (WDS).
I have a presentation web farm with four load-balanced servers. I have one web application with two website domains that represent that application. Rather than constantly push to two different folder locations, I figured I can push to one location and have a virtual directory on each website point to the single folder on the webserver.
Here is the setup:
The load balancer is CoyotePoint. The web framework is asp.net 3.5. IIS 6 (slowing moving to 7).
I'm concerned about performance in a production environment. Are there any ramifications to having two websites with virtual directories pointing to the same directory on disk? Should I also be worried about application pools?
I think I found what I was looking for. It's called CentralizedWebFarmManagement for IIS. Specifically, I think the Shared-configuration, and Web Deployment Tools for Web Farm is exactly what I need!
It depends on what this application is doing. If you're doing anything at all fancy with System.IO you're going to run into issues.
There are other ways to make the pushing of files easier. I highly recommend creating a quick bat file with a few robocopy commands in it.
I have been struggling with the best way to make sure that the certain XML configuration files stay synchronized between multiple servers in a Web Farm. I am not necessarily concerned about the Web.Config, as much as I am concerned about some of the other configuration files that are present in the application.
For example, we store caching policies in an external XML file, where it has its own schema, and will soon have its own tool to maintain the values. Once the changes are applied, they should be migrated across the farm.
Some scenarios that I have considered so far:
RoboCopy, replication, or equivalent. This requires that work only ever be done on a particular node of the farm. (Push to application.)
Configuration Server. All external configurations and their tools are stored on a physical instance of IIS. The application will retrieve these configuration files on application start and periodically poll for changes. (Application polls.)
Team Build. We could host the tools in-house and set up a post-build process to deploy the files. (Application polls.)
Database Storage. Applications could read and poll database for configuration. (Application polls.)
All of these scenarios have their pros and cons. I am not sure what the best solution is, although I think having the application poll for changes might be the cleanest approach. Still, the question is which way would you best consider this to be accomplished?
I have web cluster running Windows Server 2008. To keep everything synchronized I'm using a DFS share that is on each of the members. Any changes made to any of the members are replicated to the others. I'm also using the IIS "Shared Configuration" feature to store my metabase within this DFS share. That way all of the IIS settings are replicated as well.
On a project that I worked on, we used a product called ServerSync to replicate files on the farm. It works pretty good and it is -fast-.