在經歷過好多折騰後,總算是把部署走通了一遍,以前只是簡單建立個工程在linux下部署,後來一直將這件事擱置,直到最近恰好團隊入手一個小服務器,很顯然是linux的,那就沒啥說的了,Come On!html
在這個時候我挺想也秀一把命令行,什麼dotnet build啊,publish什麼的,可是仍是老老實實用個人宇宙第一神器吧。linux
右鍵工程發佈。web
這個地方我引用下官網的介紹。docker
依賴框架json
優勢:windows
缺點:centos
獨立部署api
優勢:緩存
缺點:服務器
其餘的倒沒有太多注意的地方,我這裏選擇的是依賴框架。
以後就是生成文件了,咱們來看下這一堆玩意兒。
這裏注意本身複製下April.xml這個文件,由於我沒連帶發佈,留個坑。。。
咱們來試下dotnet命令吧。
直接訪問https://localhost:5001吧,這裏沒有輸出內容。
好了,這說明發布直接在Windows運行,應該是沒啥問題。
自己想着這裏都很少說了,後來一想,算了,既然寫相關部署了,那哪能少的了這伴隨了好長時間的IIS啊。
新建網站
這裏注意下標註的模塊,IIS部署net core須要單獨安裝一個.NET Core Windows Server Hosting,而後置於sdk到這一步了應該是都安裝過了,路徑就選擇本身發佈的路徑。
而後在應用池中更改下託管。
以後運行網站就能夠了,測試這塊兒我就不放了,畢竟通常這地方沒啥問題,若是前面都能運行的話,有問題的朋友能夠私信我。
這裏我用的是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的配置這塊兒,我也是在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服務器到期了),仍是來一句結束吧,咱們老是想的太多,而卻作的太少,總覺得理所固然,可現實四處碰壁,生活在於折騰,而折騰令人進步,樹欲靜而風不止,那就可勁兒刮吧。
from:https://www.cnblogs.com/AprilBlank/p/11757027.html