How to deploy Asp.Net Core websites with five ways?
Written in front
Since the system is developed, it must be deployed. As a .NET Core developer, if you don’t deploy your own application, it is obviously not a qualified programmer.
We know that if you want to develop .NET Core, you need to install the .Net Core SDK. If you only deploy .NET Core on the server, you only need to install Net Core Runtime.
For the download of SDK and Runtime you can click here to download.
How to deploy Asp.Net Core
Here I take you together to summarize the several deployment methods of Asp.Net Core. Usually we use more windows servers, so they are directly deployed by iis, but the programs developed by Asp.Net Core can not only be deployed in windows system. Iis, it can also have many other deployment methods, I will sort out for you one by one, of course, here is an article in the garden, “Imaginary Tianmang”, I will give an article link at the end of the article.
Console running directly
After the Asp.Net Core program is released, it will generate an entry dll file. To run the program, you only need to execute the dll file with the dotnet command.
So the first way is to find the dll file directly and run it using the dotnet command.
(Where do you say the dotnet command? You have the Runtime installed.) Of course you can also specify the port number when you run it.
# running in console dotnet Czar.Cms.Admin.dll --urls=http://localhost:8099
The results of the operation are shown below:
For applications developed with the .Net Framework, everyone is familiar with deploying with IIS.
What about .Net Core?
Although the operating modes of the two are not the same, Microsoft naturally provides a deployment method using IIS in order to reduce the difficulty of migration.
Unlike Asp.Net, ASP.NET Core is no longer hosted by the IIS worker process (w3wp.exe), but is run using a self-hosted web server (Kestrel), and IIS is the role of a reverse proxy to forward requests to Kestrel. In the ASP.NET Core program of the port, the received request is then pushed to the middleware pipeline. After processing your request and related business logic, the HTTP response data is written back to IIS, and finally it is different. Client (browser, app, client, etc.).
If you are deploying the Asp.Net Core program using IIS, the steps are as follows:
- On the managed system, create a folder to contain the folders and files that the app has published.
The deployment layout of the application is described in the Directory Structure topic.
- In IIS Manager, open the server node in the Connections panel.
Right click on the “Sites” folder.
Select “Add Site” from the context menu.
- Provide the site name and set the physical path to the application’s deployment folder.
Provide a “bind” configuration and create a website by selecting “OK”:
Top-level wildcard bindings (
http://+:80) should not be used.
Top-level wildcard bindings can introduce security holes in your application.
This behavior applies to both strong wildcards and weak wildcards.
Use an explicit hostname instead of a wildcard.
*.comSubdomain wildcard binding (for example,
*.mysub.com) does not have this security risk if the entire parent domain can be controlled (as distinguished from vulnerable ones).See section 5.4 of rfc7230 for details.
- Under the server node, select Application Pool.
- Right-click on the application pool for your site and select Basic Settings from the context menu.
- In the Edit Application Pool window, set the .NET CLR Version to No Managed Code:
ASP.NET Core runs in a separate process and manages the runtime.
ASP.NET Core does not rely on loading the desktop CLR.
Setting the “.NET CLR version” to “no managed code” is an optional step.
ASP.NET Core 2.2 or higher:
Disables application pooling for 32-bit (x86) processes for 64-bit (x64)standalone deployments that use the in-process managed model. In the Actions side of the IIS administrator’s Application Pool, select Set Application Pool Defaults or Advanced Settings.Find “Enable 32-bit applications” and set the value to
False.This setting does not affect apps that are deployed for out-of-process hosting.
- Confirm that the process model ID has the appropriate permissions.If you change the application pool’s default identity (Process Model > Identity) from ApplicationPoolIdentity to another identity, verify that the new identity has the required permissions to access the application’s folders, databases, and other required resources.
For example, an application pool requires read and write access to a folder in which the application reads and writes files.For more information, please refer to:IIS Deployment .Net Core Application The way we currently use is iis for deployment.
Deploy as Windows Service
Through the deployment of the Windows Service, we can solve the boot-up and persistent operation problems of the direct running deployment of the above console, and also avoid the performance loss problem in the iis deployment.
How to do it?
One way is provided as follows (of course, you can also deploy Windows Service in other ways):
- Use nssm to manage Windows Service,Nssm, usage, please refer to:https://nssm.cc/usage
- Configure the Service to start up.
- Install nssm, then switch to the nssm installation path and open the console
- Run the following command:
nssm install <servicename>
Open the nssm installation interface as shown below:
- As for a few options, it is very simple, you can install the English meaning to configure.
- High performance deployment with good stability.
- Support booting.
- Can only be used with Windows servers.
- Introduced an outsourcing dependent NSSM.
Because .Net Core is inherently cross-platform, deploying .Net Core programs on cheap and stable Linux is becoming mainstream.
For deployment on Linux, there is no difference between it and Windows.
The first is to install the Runtime environment, then copy the program and run it from the command line.
Going a step further, you can use the background mode to let the program run in the background.
Further, you can follow the example of Windows and use program startup management as a service to achieve boot-up and flexible management.
As the best way to personally think of the .Net Core application deployment, I suggest everyone understand.
We are currently experimenting with Dockerization and then managing it with K8S.
First of all, it is the basic use of Docker:
- Write a Dockerfile
to create and run a container
Ok, let’s point out that for Docker, you need to install the Docker environment first.
Next, let’s assume that the distribution package path is as follows:
Root-folder/ App/ # publish package directory Xxx.dll #entry Dockerfile # Dockerfile
Then for the program, write the following Dockerfile:
# root image FROM microsoft/dotnet:2.2-runtime # copy app COPY app /app # word directory WORKDIR /app # exports port EXPOST 80 # run CMD ["dotnet", "xxx.dll"]
docker build -t xxx:0.0.1 .
to construct an image.
Next, and then through
docker run -it -p 8000:80 --name xxx-demo xxx:0.0.1
to create and run a container.
In this way, you can
have access to your application to the.
This is just a rough step in writing down the Docker deployment.
Really need to use it for the production line, but also need to learn enough Docker knowledge.
Extra mention, how to choose the base image
For .Net Core, there are generally the following types of base images:
- Sdk — I believe this is easier to understand, including the .Net Core SDK.
- Runtime — This is also relatively easy to understand, including the .Net Core Runtime.
- Runtime-deps — this is not very well understood, runtime? deps? What do you mean?
That is to say, this even Runtime is not complete, you need to choose the self-hosting mode when you package, and also run the Runtime.
In summary, I personally recommend that you choose the runtime as the base image.