Windows Server and IIS hosted#
It is possible to deploy and host the Command Center application in an IIS server environment.
This is a manual process that can be a bit of a hassle, since we need to manually configure this and ensure we don't override any existing configuration files.
Servers#
- IIS WebServer TAS-CC01
- ElasticSearch TAS-SQL03
- SQL Server TAS-SQL01, TAS-SQL02, TAS-SQL03
These can be Linux or Windows.
On Windows web applications and web API's are commonly hosted in IIS, there's also the option to run the applications as Windows Services. Hosting in IIS can be In-Process or Out-Of-Process, by default, the in-process hosting model is used due to better performance and diagnostics.
On Linux you can run as systemd service, and also generally have a proxy in front of the application. As a reverse proxy and load-balancing I prefer using NGINX.
You can find more on this topic @Host ASP.NET Core on Linux with Nginx and @Part 2.2 - Install Nginx and configure it as a reverse proxy server
Application#
- - BFF / Frontdoor - WebAPI - ClientApp
To quickly build and publish a version locally I added a build command.
The output can be found in artifacts/publish/
or when you need the artifacts for a different platform or runtime add --runtime win-x86
And to include all dotnet assemblies in the artifacts we can do a Self-Contained build/ publish adding --sc to the arguments
After publishing the application we can copy the content of a static website to the wwwroot of CommandCenter BFF (artifacts/publish/CommandCenter.Bff.Frontdoor/release*/wwwroot) and remove appsetting.json (and web.config) to prevent overriding them on it's destination.
CommandCenter.Bff.Frontdoor#
Configuration shouldn't have to change for local setups.
In any-case you may route configuration will move in future release to a central configuration (gui) - managed gateway or front-door application.
CommandCenter WebAPI#
Some of the settings required to make this work and when changes should be kept local and not be committed in the repository are:
{
"Elastic": {
"Host": "http://elasticsearch:9200",
"DefaultIndexName": "exceptions"
},
"AzureAd": {
"TenantId": "",
"ClientId": "",
"ClientSecret": ""
},
"ConnectionStrings": {
"DefaultConnection": "Server=host.docker.internal;Database=CommandCenterNext;TrustServerCertificate=True;User Id=docker;Password=docker"
},
"CommandCenterUrl": "https://host.docker.internal:1443/Tasper.CommandCenter/",
"ServersApiUrl": "http://commandcenter.webapi:8080/"
}
Note
The AzureAd values can be found in a file on the Development Drive (currently @) Shared drives\Development\CommandCenter\Azure AD settings.json which in Development can be put in the secrets.json file Readme/User Secrets
When running in Docker or IIS outside local Dev environment, it is recommended to set these as Environment variables of other secret manager. IIS uses the we.config to pass Environment variables.
CommandCenter ClientApp#
To publish locally you may use your favorite shell (bash, cmd, pwsh)
General Local Configuration#
On you local machine there are some basic things to setup and configure.
- Reverse Proxy - must have http port 8180 in the bindings, this is used from nginx (dmz proxy) behind traefik in docker.
- Benefit Applications - give this an http binding on port 8080 and https on port 1443
Also Application Pools can be kept to the default settings..
And CommandCenter requires access to a Versions directory, this is a ApplicationSetting in the CommandCenter database used for deploying BenefitManager. To set the permission for the Application Pool to read the directory content use this command:
Benefits is the name of the Application Pool in IIS.., and sure enough this can be done using the GUI as well.
When CommandCenter tries to connect to th BenefitManager it will create a URL and HTTP Headers based on the settings in the CommandCenter database, a combination of TblServer, TblCustomer, TblCustomerStage etc..
SELECT s.Name AS [Name]
,s.Url AS [ServerUrl]
,s.[Type] AS [ApplicationType]
,sv.VirtualDirectory AS [VirtualDirectory]
,av.Identifier AS [VersionIdentifier]
,cs.[Name] AS [StageName]
,cs.[Url] AS [RootUrl]
,cs.[Instance] AS [SqlInstance]
,cs.[Database] AS [SqlDatabase]
,cs.[Identifier] AS [Identifier]
FROM [dbo].[TblApplicationVersion] av
INNER JOIN [dbo].[TblCustomerStage] cs ON av.[Key] = cs.VersionKey
INNER JOIN [dbo].[TblServerVersion] sv ON av.[Key] = sv.VersionKey
INNER JOIN [dbo].[TblServer] s ON sv.ServerKey = s.[Key]
WHERE
AND cs.[Active] = 1 AND cs.[Online] = 1 -- customer stage
AND s.[Online] = 1 AND s.Active = 1 -- server
AND sv.Active = 1 -- server version
Since these Request are made from within the docker network, all references to the Host must be replaced with host.docker.internal.
Do not forget to change your App.user.config in your BenefitManager solution, under the 'src/common' directory, this should match your IIS setup.
After changing the App.user.config you must run the 'build - debug.bat' to ensure configuration is updated in all the projects
To Allow the CommandCenter in performing HTTP Requests on the BenefitManager we must add Allowed IP-addresses in the Settings page of the CommandCenter (or directly in the database).
To get your local IP-address open a PowerShell terminal en enter:
Biggest chance it's the DHCP address, and for local development always include 127.0.0.1
It's the third EnableToolLog having the Allowed IP Filter values in , (comma) separated format.
Requests fail in BenefitManager
This can happen even though all the above settings are correct.
It may require a iisreset to recycle the Application Pools, and clear any cached values.
About Exite Configuration#
Application in IIS that have related endpoints (WebSites) in the same IIS have similar port bindings, this is different from Docker, because in Docker every application is self-contained host with a unique DNS Name in a Docker Network.