一、发布web项目
- 通过命令发布：dotnet publish -c Release -o published（到程式根目录下，用cmd执行）
- 通过visual studio发布，如下图：
二、将发布好的published文件夹copy到远端服务器
接下来在此服务器进行image打包，run container等操作，即将服务运行到此物理服务器主机中。
dockerfile文件内容：
#基础镜像
FROM mcr.microsoft.com/dotnet/aspnet:5.0
#将发布好的程式拷贝到app目录，published为服务器实体路径，app为docker容器内路径
COPY published/ app/
#设定工作目录,不需要事先创建,没有则会自动新增
WORKDIR /app
#声明端口号，需要与生产环境指定端口一致
EXPOSE 5051
#运行程式
ENTRYPOINT ["dotnet", "Mitac.Net5.WepApi.dll"]
#必须设置，否则读取不到数据库数据
ENV TZ=Asia/Shanghai
#更改容器编码，防止修改appsettings时，中文乱码
ENV LANG C.UTF-8
ps：文件也可以放到published文件夹中
三、打包image镜像
在服务器执行打包指令：
docker build --no-cache -t net5api:v1 -f Dockerfile .
#--no-cache：每次打包都会更新基础镜像，不会依赖缓存
#-t：镜像名称：版本
#-f：dockerfile文件路径，当前目录则可省略
#.：镜像构建过程中的上下文环境的目录
Docker打包说明：
Docker 在运行时分为 Docker引擎（服务端守护进程） 以及 客户端工具，我们日常使用各种 docker 命令，其实就是在使用客户端工具与 Docker 引擎 进行交互。那么当我们使用 docker build 命令来构建镜像时，这个构建过程其实是在 Docker引擎 中完成的，而不是在本机环境。
那么如果在 Dockerfile 中使用了一些 COPY 等指令来操作文件，如何让 Docker引擎 获取到这些文件呢？
这里就有了一个 镜像构建上下文 的概念，当构建的时候，由用户指定构建镜像的上下文路径，而 docker build 会将这个路径下所有的文件都打包上传给 Docker 引擎，引擎内将这些内容展开后，就能获取到所有指定上下文中的文件了。
所以 docker build 最后的 . 号，其实是在指定镜像构建过程中的上下文环境的目录。
四、运行容器，启动服务
docker run -d -p 5051:5051 -v /container-data/net5api/published:/app --restart=always --name net5api net5api:v2
#-d 表示在后台以守护态（daemonized）形式运行容器
#-p 外部端口与内部容器端口映射，指定物理主机5051端口映射到docker容器5061端口
#-v 将docker容器内的app文件夹挂载到物理主机的/container-data/netapi/published路径，实现容器文件持久化，两个文件夹互相映射，谁有改变另一个也会跟着变
#--restart 指定容器开启自启动
#--name 指定容器的名称。当然可以不指定，默认会为我们创建
# 最后一个参数net5api:v1 就是我们刚创建的镜像名称
注意：
- 将docker文件夹/app中的netcore程式持久化时，用-v指令，要确保物理主机中的文件与app一致，即/container-data/net5api/published不可为空，因为映射后双方是互相映射，如果主机中文件为空，docker中的文件夹也会变空
- 必须将/container-data/net5api文件夹执行sudo chmod -R 777,否则程式的log等文件无法写入。
- 持久化处理后，可直接通过修改/container-data/net5api中的文件来控制程式
至此，服务即运行起来了，如下图，端口5051
