小编点评

## Containerized Application Deployment with .NET Framework This document outlines two different deployment methods for a .NET Framework application: **Method 1: No Runtime Installation** * Use Docker to build a base image that contains the .NET runtime and your application. * Copy your application code and necessary dependencies to the Docker image. * Build the image with the `docker build` command. * Push the image to a Docker registry (e.g., Docker Hub). * Run the image on your production server. **Method 2: Runtime Installation** * Use Docker to build an image that contains the .NET runtime and your application. * Create a `dockerfile` that builds the image using the base image from method 1. * Define the startup command for your application within the Dockerfile. * Push the image to a Docker registry. * Run the image on your production server. **Benefits of Method 1:** * No need to install the .NET runtime on the production server. * Can be deployed quickly and easily. * More secure, as it reduces the attack surface by not exposing the .NET runtime directly. **Benefits of Method 2:** * Can be used for complex applications with multiple dependencies. * More control over the runtime version and versioning. * Can be updated independently from the application code. **Choosing the Right Method:** * Use **Method 1** if your application is simple and only needs basic runtime support. * Use **Method 2** if your application has multiple dependencies, requires a specific runtime version, or needs independent updates. **Additional Notes:** * Remember to configure your Dockerfile to provide the necessary runtime dependencies. * Use a tool like `docker-compose` to manage your containerized application. * Ensure your production server has Docker installed and configured to use a Docker registry.

正文

前言

之前我写过一篇使用 docker 部署 AspNetCore 应用的文章，这种方式搭配 CICD 非常方便， build 之后 push 到私有的 dockerhub ，在生产服务器上 pull 下来镜像就可以直接运行了。

然而，有时需要一种更传统的部署方式，比如在本地打包可执行文件之后直接放到服务器上执行。

.NetCore 打包可执行文件有两种方式

• 独立可执行文件 - 不依赖任何运行时环境，直接执行就可以启动
• 框架依赖 - 需要先安装对应版本的 dotnet-runtime 才可以运行

前者虽然方便，但打包出来比较大，据说在 .net8 版本会有优化，但后面的事后面再说，本文记录第二种方式，框架依赖，搭配 docker 部署，这样就无需在服务器上安装 runtime 了。

（PS：有点Java部署内味了）

这种方式配置完成之后，每次更新只需要重新本地重新 publish 后把可执行文件上传覆盖服务器上的版本即可，非常方便~

不生成 PDB

每次打包会生成一堆 pdb 调试文件，但部署的时候我们不需要这些文件，可以通过配置 .csproj 文件关闭。

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
  <DebugType>none</DebugType>
  <DebugSymbols>false</DebugSymbols>
</PropertyGroup>

更好的方式是在解决方案的目录下创建 common.props 文件，把以上配置放在这个文件中，然后每个 .csproj 都引用这个文件，具体路径根据实际情况而定。

<Import Project="../../common.props" />

打包

使用以下命令打包

dotnet publish -f net7.0 -c Release -p:PublishSingleFile=true

打包之后生成一个需要依赖 runtime 运行的可执行文件，接下来准备一下 docker 的配置。

dockerfile

官方的 dockerfile 包含从源码构建到部署的整个流程，我们这里只需要 base 和 final ，也就是把可执行文件放进去微软的基础镜像里运行。

FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM base AS final
WORKDIR /app
COPY . .
ENTRYPOINT ["./AIHub.Blazor"]

docker-compose

不想每次都打一堆 docker 的命令，或者不想写 bash 脚本的话，docker-compose 是最好的选择，还可以很方便的和其他容器编排使用。

version: '3.6'

services:
  web:
    image: ${DOCKER_REGISTRY-}web
    container_name: aihub
    restart: always
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
      - ASPNETCORE_URLS=http://+:80
    build:
      context: .
    volumes:
      - .:/app
    ports:
      - "12001:80"
    networks:
      - default
      - swag

networks:
  swag:
    name: swag
    external: true
  default:
    name: aihub

补充：

• ports 节点映射了容器内的 80 端口
• 我使用了 swag 来提供 web 服务，所以其实不需要使用 ports 映射端口
• 后续再试用 candy / traefik 来替代 nginx （本项目没有nginx，直接用 kestrel）

启动！

使用命令行启动！

docker compose up

如果没有映射端口的话，还需要接着配置一下反向代理。

swag配置

直接上配置

/path/to/swag/config/nginx/proxy-confs/aihub.subdomain.conf

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name aihub.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    # enable for Authelia
    #include /config/nginx/authelia-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /ldaplogin;

        # enable for Authelia
        #include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;

        set $upstream_app aihub;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_hide_header X-Frame-Options; # Possibly not needed after Portainer 1.20.0
    }
}