In my previous post I started a list of best practices that should be followed for
deploying applications to production systems. This is continuation of that post.
-
Create new Virtual Application in IIS
Right-click [website app will live in] > Create Application
Creating a new application provides each ASP.NET application its own sandbox environment.
The benefit to this is that site resources do not get shared between applications.
It is a requirement for all new web applications written in ASP.NET.
-
Create a new application pool for Virtual App
-
Right click on Application Pools and select Add Application Pool
-
Define name: “apAppName” - ‘ap’ followed by the Application Name
-
Set Framework version to 2.0
-
Set the Managed Pipeline mode: Most applications should use the default setting
An application pool is a distinct process running on the web server. It segregates
processes and system resources in an attempt to prevent errant web applications from
allocating all system resources. It also prevents any nasty application crashes from
taking the entire website down. It is also necessary for creating distinct security
contexts for applications. Setting this up is essential for high availability.
-
Set the memory limit for application pool
There is a finite amount of available resources on the web servers. We do not want
any one application to allocate them all. Setting a reasonable max per application
lets the core website run comfortably and allows for many applications to run at any
given time. If it is a small lightweight application, the max limit could be set lower.
-
Create and appropriately use an app_Offline.htm file
Friendlier than an ASP.NET exception screen (aka the Yellow Screen of Death)
If this file exists it will automatically stop all traffic into a web application.
Aptly named, it is best used when server updates occur that might take the application
down for an extended period of time. It should be stylized to conform to the application
style. Best practice is to keep the file in the root directory of the application renamed
to app_Online.htm, that way it can easily be found if an emergency update were to
occur.
-
Don’t use the Default Website instance
-
This should be disabled by default
-
Either create a new website instance or create a Virtual Application under existing
website instance
Numerous vulnerabilities in the wild make certain assumptions that the default website
instance is used, which creates reasonably predictable attack vectors given that default
properties exist. If we disable this instance and create new instances it will mitigate
a number of attacks immediately.
-
Create two Build Profiles
-
One for development/testing
-
One for production
Using two build profiles is very handy for managing configuration settings such as
connection strings and application keys. It lessens the manageability issues associated
with developing web applications remotely. This is not a necessity, though it does
make development easier.
-
Don’t use the wwwroot folder to host web apps
Define a root folder for all web applications other than wwwroot
As with the previous comment, there are vulnerabilities that use the default wwwroot
folder as an attack vector. A simple mitigation to this is to move the root folders
for websites to another location, preferably on a different disk than the Operating
System.
These two lists sum up what I believe to be a substantial set of best practices for
application deployments. The intent was not to create a list of best development
best practices, or which development model to follow, but as an aid in strictly deployment.
It should be left to you or your department to define development models.
