前言
在經歷過好多折騰后，總算是把部署走通了一遍，之前只是簡單創建個工程在linux下部署，后來一直將這件事擱置，直到最近剛好團隊入手一個小服務器，很顯然是linux的，那就沒啥說的了，Come On！
發布
在這個時候我挺想也秀一把命令行，什么dotnet build啊，publish什么的，但是還是老老實實用我的宇宙第一神器吧。
右鍵工程發布。
這個地方我引用下官網的介紹。
依賴框架
優點：
- 不需要設置部署的系統，因為都是通用的pe文件，這就是跨平台很嗨皮的地方
- 部署包小
- 允許程序使用net core最新的runtime
- 多應用可通用一個net core類庫
缺點：
- 主機系統必須安裝當前程序net core版本或更高的版本
- 如果net core高版本砍掉部分使用的功能，那升級可能就會有問題
獨立部署
優點：
- 可以單獨維護當前使用的net core
- 目標系統也可以運行你的net core
缺點：
- 需要提前選擇你部署的系統
- 部署包大，因為獨立嘛
- 每個應用自己本身都會帶個net core，重復率，emm
其他的倒沒有太多注意的地方，我這里選擇的是依賴框架。
之后就是生成文件了，我們來看下這一堆玩意兒。
這里注意自己復制下April.xml這個文件，因為我沒連帶發布，留個坑。。。
測試
Windows
我們來試下dotnet命令吧。
直接訪問https://localhost:5001吧，這里沒有輸出內容。
好了，這說明發布直接在Windows運行，應該是沒啥問題。
IIS部署
本身想着這里都不多說了，后來一想，算了，既然寫相關部署了，那哪能少的了這伴隨了好長時間的IIS啊。
新建網站
這里注意下標注的模塊，IIS部署net core需要單獨安裝一個.NET Core Windows Server Hosting，然后置於sdk到這一步了應該是都安裝過了，路徑就選擇自己發布的路徑。
然后在應用池中更改下托管。
之后運行網站就可以了，測試這塊兒我就不放了，畢竟一般這地方沒啥問題，如果前面都能運行的話，有問題的朋友可以私信我。
Linux
這里我用的是Centos 7（虛擬機Vmware），相關的安裝軟件什么的我在之前新手向相關的也已經介紹過了，這里不多說了，直接開始吧。
首先我們把publish下發布的文件打包上傳到linux，我這里放的目錄是/www/april-webapi/，這里我們直接運行的話，是不行的，畢竟linux下我們還沒有安裝dotnet相關的環境，已經安裝的忽視。
一個是運行庫dotnet，一個是運行時庫runtime，這個都可以通過官網來下載的，當然可以直接通過docker（直接跳過這塊兒往下看），但是我這里只是把我自己趟的一遍復述下而已。
$ sudo rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm
$ sudo yum install dotnet-sdk-3.0
$ sudo rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm
$ sudo yum install aspnetcore-runtime-3.0
ok，小等會兒就可以安裝完了，完成之后，我們來切到工程目錄下。
$ cd /www/april-webapi/publish/
來試下dotnet的命令吧。
$ dotnet April.WebApi.dll
運行之后，如果不出意外，我們會看到下面這個錯誤，當然如果你的工程比較簡潔（什么引用都沒有，就是個空工程），那這個地方你就完全運行了，但是那樣的工程除了demo毫無卵用（就像我當年那么天真以為走一遍新建工程發布就已經大結局了一樣）。
好了，不扯了，我們來看下這個問題，提示我們在對應lib/xxx路徑下找不到xxx.dll，但是為何我們windows就可以了呢，這是因為類庫緩存，在你運行程序的時候這些類庫已經有了，默認會從net core的安裝目錄也就是系統盤下對應的不知道哪個文件夾下/lib/netstandardx.x/xxx.dll，所以windows下就沒有報錯。
這里我第一反應就是，那既然這樣我就把需要的dll文件都放過來，然后路徑換換不就得了（不得不說確實好麻煩），於是就這樣一通操作，把類庫都單獨放到一個文件夾，其實發布之后的工程已然包含這些類庫了，對April.WebApi.deps.json這個文件修改路徑之后（我是全改成/lib/netcore-libs/xxx.dll），我們運行之后還是提示找不到。
對於這種現象，我只能說，世界之大~，然后繼續查資料吧，最終在一個 Nate McMaster的博客中找到了這個問題的解決方法，原來還有這個April.WebApi.runtimeconfig.json的屬性additionalProbingPaths配置，這種要不是深入還真是不行啊，國外的鑽研精神不得不說，值得學習，看過之后也發現，原來發布的文件夾中有一個這種寫法的配置，注意看April.WebApi.runtimeconfig.dev.json，下面是我改動之后的April.WebApi.runtimeconfig.json。
{
"runtimeOptions": {
"tfm": "netcoreapp3.0",
"framework": {
"name": "Microsoft.AspNetCore.App",
"version": "3.0.0"
},
"configProperties": {
"System.GC.Server": true
},
"additionalProbingPaths": [
"/lib/netcore-libs/"
]
}
}
配置好對應路徑之后，我們來測試下，如果沒有其他問題，應該跟我看到的界面效果一樣，ok，那這樣不就已經結束了。
Docker
docker的配置這塊兒，我也是在Linux配置部署_新手向（五）——Docker的安裝與使用簡單的介紹了，包括基本用到的命令語句什么的。
這里直接來個Dockerfile吧，這里也只是簡單寫下需要的環境，端口，路徑等基礎配置。
FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
COPY . /app
ENTRYPOINT ["dotnet", "April.WebApi.dll"]
然后我們在當前目錄下，運行以下命令生成鏡像，注意末尾，還有個點，意思就是當前目錄。
$ docker build -t april-webapi .
稍等一會兒（網速不好的話可能很長時間），提示完成的時候，我們來看下鏡像。
$ docker images
看到有鏡像那就說明走了一大半了，然后我們只需要運行鏡像創建容器就行了。
$ docker run --name april-webapi-demo -d -p 8080:80 april-webapi
$ docker ps -a
指定8080來接收80端口，指定名字叫april-webapi-demo，然后看下運行容器的情況。
這里我們看到已經創建了容器，但是注意狀態EXIT(140)，這很明顯我們的程序跑了但是沒有持久，emm，不持久可不行。
看下日志是咋回事吧。
$ docker logs april-webapi-demo
一看，喲，又是同樣的錯誤，但是我們的路徑已經指向絕對路徑了，為啥還錯呢，這里注意下，我們的類庫是在linux下的根目錄下的指定文件夾，但是docker呢，可以理解為單獨的虛擬機，那很顯然docker當中沒有這個路徑下的文件，那既然這樣，我們就好解決了，因為Dockerfile中我們的WorkingDir是/app，那么我們是不是只要指定到這個目錄下就可以了呢？Let's 踹踹。
首先我們在publish下創建個packages，然后把類庫包復制到文件夾下，之后替換April.WebApi.deps.json中/lib/netcore-libs/為/app/packages/，這里說下為啥是/app/xxx呢，因為Dockerfile中配置的工作區為app。
一番替換之后，我們來重新走一遍build，這次改個名字（當然可以刪除之前的無效鏡像跟容器），重新運行下我們再看容器的狀態，咦好像是可以了，那我們來訪問下，這次用主機訪問這個地址，看到這個界面之后，不禁感慨，路漫漫啊。
小結
這篇同樣沒有測試，因為一路都捎帶着測試，所有的走完一遍之后，我在想，為何會這么麻煩，按說通用的話，一個文件夾移哪都能用才對，至於相對路徑我也是試過，但是沒有效果，應該還是那個配置查找路徑的屬性問題，我們還是需要先指明從哪讀類庫，后續看看有啥新進展的話，我還是會繼續更新的。
在net core剛開始的時候，我們都已經知道這是一個要跨平台的，但是直到現在我才開始鼓搗linux下部署，實在是慚愧，一直在windows下讓我有點兒過於舒適（當然還是因為windows服務器到期了），還是來一句結束吧，我們總是想的太多，而卻做的太少，總以為理所當然，可現實四處碰壁，生活在於折騰，而折騰使人進步，樹欲靜而風不止，那就可勁兒刮吧。