Practical Asp.Net Core: Deploying Apps
At some point, you have written the .Net Core program. What else can you do next? That is the deployment.
As a development engineer, this is not complete if you don’t deploy your own applications. Next, let’s talk about how to deploy our .Net Core application (mainly the Asp.Net Core application).
2. How to deploy Asp.Net Core
For the language executed in the virtual machine, the Metropolis has an SDK (Software Development Kit) and an XRE (X Runtime Environment). For C#, it is no exception. In C#, the difference between the two is:
- The .Net Core SDK is used by developers to build apps with a lot of development-related toolkits (actually, the SDK also contains Runtime)
- The .Net Core Runtime is only used as a runtime, does not include a development kit, and is small.
Since you want to deploy Asp.Net Core, you can’t do without Runtime (if you can also run the SDK, it is not recommended to install the SDK in the running environment). The premise of the following deployment methods is that the Runtime environment has been installed.
Download address: https://dotnet.microsoft.com/download
2.1, the console runs 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 through 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 installed Runtime.)
- Simple enough to copy the file and open it.
- Compatible with multi-platform deployments.
- Imagine if the console is turned off and what happens when the server is rebooted? At this point you need to manually re-execute. (You said, can you set it to boot? If you create a batch, put it in the startup item, you can still do it)
2.2, IIS deployment
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:
- First, you need to install the .Net Core managed bundle, click here to download the bundle.
- Take the IIS console and make sure the AspNetCoreModule managed module is found in the module. (If you performed step 1, you did not find it, you can try the console to execute
- Create an application in the same way that you regularly deploy the .Net Framework program. When selecting an application pool, be sure to select it No Managed code, as shown in the figure:
- At this point, even if the deployment is successful.
- Learning costs are low and remain similar to how .Net Framework applications are deployed.
- Can automatically boot from the start.
- You can configure port domain name binding in the visual interface.
- This method can only be used on a Windows server.
- There is a performance penalty when bridging a layer through IIS.
For more information, please refer to: IIS Deployment .Net Core Application
2.3. Deploy as Windows Service
In the deployment of 2.2, the bigger drawback is the performance loss. So, is there any way to avoid this problem? . The answer is Windows Service. With Windows Service, we can solve the problem of booting and persistent running in 2.1, and can avoid the performance loss in 2.2. 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.
- High performance deployment with good stability.
- Support booting.
- Can only be used with Windows servers.
- Introduced an outsourcing dependent NSSM.
2.4, Linux deployment
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.
2.5, Docker deployment
As the best way to personally think of the .Net Core application deployment, I suggest everyone understand.
First of all, it is the basic use of Docker:
- Write a Dockerfile
docker buildbuild Mirror
docker runto 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/ # Dir xxx.dll # Main Dockerfile # Dockerfile
Then for the program, write the following Dockerfile:
# root FROM microsoft/dotnet:2.2-runtime # copy app COPY app /app # work dir WORKDIR /app # 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.1to create and run a container.
In this way, you can
http://localhost:8000have 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 all, 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.