向net core 3.0進擊——多平台項目發布與部署

2019 年 10 月 29 日
筆記

前言
發布
測試
小結

前言

在經歷過好多折騰後，總算是把部署走通了一遍，之前只是簡單創建個工程在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。

配置好對應路徑之後，我們來測試下，如果沒有其他問題，應該跟我看到的介面效果一樣，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伺服器到期了），還是來一句結束吧，我們總是想的太多，而卻做的太少，總以為理所當然，可現實四處碰壁，生活在於折騰，而折騰使人進步，樹欲靜而風不止，那就可勁兒刮吧。