Reputation: 177
We currently deploy our ASP.NET Core products to:
We have a single "Site" with multiple applications under it. Each application uses its own application pool and is mapped to a different physical folder path location.
Each application is represented by its own source code ASP.NET Core Server project
IIS Structure
We use Jenkins for our CI/CD, and this cannot be changed. We have Powershell scripts to interact with IIS
There is no IIS command to stop an Application, only a Site, but we ideally do not want to bring down the site when publishing a new version of a single Application. We only want to bring down that specific Application.
We attempted this by stopping the WebAppPool associated with the application, and then waiting (2 minutes .. then 5 minutes). But even after that the application files are still locked.
We end up shutting down the WebAppPool and the Site to release the files so they can be replaced.
I know there has to be a better way to do this. How can we shut down an individual app, and prevent new requests from reaching it so we can replace the files and then restart it? All while the "SITE" and any other App under it not being updated is still running. I don't mind down time for the App being updated.
Update 6/8/2022
Found this: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/app-offline?view=aspnetcore-6.0
Going to see if this can solve my problem.
Upvotes: 8
Views: 5172
Reputation: 2888
I highly recommend using web deploy with IIS. There are a couple of steps to set it up, but once configured it really works great.
If you publish this way, it will automatically do the following:
This solution enables you to deploy new versions with no perceivable interruption to your service while other solutions may render your service unreachable during publish.
I have only used the publish menu from Visual Studio but it should be possible to make it work from a CI/CD script calling msbuild.exe as described here. (link descibes soultion for TeamCity but should be possible to adapt to Jenkins)
Upvotes: 0
Reputation: 798
Here's how I do it using a blue/green strategy:
First, I created this folder structure on the server:
D:\inetpub\wwwroot\MyAppPath\ Staging Green Blue
Next, in IIS, I pointed my application's physical path to D:\inetpub\wwwroot\MyAppPath\Green
Then I created D:\inetpub\wwwroot\MyAppPath\SetAppPath.ps1
($curPath = Get-WebFilePath -PSPath "IIS:\Sites\www.example.com\MyApp")
if ($curPath -like "*Blue*") {
Copy-Item -Path "D:\inetpub\wwwroot\MyAppPath\Staging\*" -Destination "D:\inetpub\wwwroot\MyAppPath\Green" -Recurse -Force
Set-ItemProperty IIS:\Sites\www.example.com\MyApp -name physicalPath -value "D:\inetpub\wwwroot\MyAppPath\Green"
} else {
Copy-Item -Path "D:\inetpub\wwwroot\MyAppPath\Staging\*" -Destination "D:\inetpub\wwwroot\MyAppPath\Blue" -Recurse -Force
Set-ItemProperty IIS:\Sites\www.example.com\MyApp -name physicalPath -value "D:\inetpub\wwwroot\MyAppPath\Blue"
}
Then, I created a Task (SetMyAppPath) without triggers that runs SetAppPath.ps1
On my development workstation, I created deploy.ps1 in the project root:
param ($buildType)
net use r: /delete
dotnet publish --configuration $buildType
net use R: "\\111.222.333.444\d`$" /user:"MyAdminUser" "MyAdminPassword"
Copy-Item -Path "C:\Users\MyUser\Dir1\Dir2\Dir3\MyProject\bin\$buildType\netcoreapp3.1\publish\*" -Exclude web.config,appsettings.json,appsettings.Development.json -Destination "R:\inetpub\wwwroot\MyAppPath\Staging" -Recurse -Force
schtasks /RUN /S \\111.222.333.444 /U MyAdminUser /P MyAdminPassword /tn SetMyAppPath
net use r: /delete
Then, to deploy, I run .\Deploy Debug or .\Deploy Release
So, when I have a new version I'm ready to deploy, the files are copied to the staging folder on the server. Then, the task on the server is triggered, which copies the staging files to the green or blue folder, which ever is not the current folder.
Finally, the app path is updated to the green or blue folder, which ever is not the current folder.
Works like a charm.
Upvotes: 3
Reputation: 1
I've previously had success with pointing the Site in IIS to a symlink. The symlink then in turn pointed to a folder that held the contents of the webpage.
Whenever I had to update the webpage, I would then create a new folder, lets call it webpage_date, then update the symlink and point it to the new folder. Lastly I recycled the AppPool that was responsible for the webpage.
So it would go:
symlink -> webpage_1
Put folder with updated webpage next to it, call it webpage_2. Point symlink to it:
symlink -> webpage_2
Then recycle AppPool.
This made it possible to have a pretty low downtime.
Powershell command to Restart-WebAppPool:
Restart-WebAppPool -Name "YourAppPool"
Restart-WebAppPool documentation
Symlinks can be created with
New-Item -ItemType SymbolicLink -Path .\link -Target .\Notice.txt
Powershell New-Item Symlink documentation
Upvotes: 0
Reputation: 1171
Adding a file named app_offline.htm in the root folder of your application should force ASP.NET Core Module to shutdown the app and stop processing incoming requests. You should then be able to deploy new file with no impact on the the other applications.
Upvotes: 10