目前我們的.NET Core實戰項目之CMS系列教程基本走到尾聲了,通過這一系列的學習你應該能夠輕鬆應對.NET Core的日常開發了!當然這個CMS系統的一些邏輯處理還需要優化,如沒有引入日誌組件以及緩存功能,許可權目前只支持控制到菜單,卻沒有控制到具體的功能(其實這塊只是苦於樣式不會處理,不然的話 ...
目前我們的.NET Core實戰項目之CMS系列教程基本走到尾聲了,通過這一系列的學習你應該能夠輕鬆應對.NET Core的日常開發了!當然這個CMS系統的一些邏輯處理還需要優化,如沒有引入日誌組件以及緩存功能,許可權目前只支持控制到菜單,卻沒有控制到具體的功能(其實這塊只是苦於樣式不會處理,不然的話也會把功能加上),不過話又說回來,這些都是次要的,後期有時間慢慢補上吧,因為我開這個系列的初衷也是對大家入門.NET Core學習有所幫助!這一章我們將一起部署我們的一路開發過來的網站。如果你覺得文中有任何不妥的地方還請留言或者加入DotNetCore實戰千人交流群637326624跟大伙進行交流討論吧!
本文已收錄至《.NET Core實戰項目之CMS 第一章 入門篇-開篇及總體規劃》
作者:依樂祝
原文地址:https://www.cnblogs.com/yilezhu/p/10366679.html
寫在前面
既然系統開發好了,那麼肯定是要進行部署了,作為一名.NET Core研發人員如果你不會部署自己的應用的話,明顯不是一個合格的程式員。我們知道如果要進行.NET Core的開發的話就需要安裝.Net Core SDK的,如果你僅僅是在伺服器上進行.NET Core的部署的話,只需要安裝Net Core Runtime即可。
對於SDK以及Runtime的下載你可以點擊這裡進行下載。
Asp.Net Core 的部署方式
下麵我帶著大家一起總結下Asp.Net Core的幾種部署方式,平時我們使用windows伺服器比較多,所以都是iis直接部署的,但是Asp.Net Core開發的程式不僅僅能部署在windows系統的iis上,它還可以有很多其他的部署方式,下麵我就為你一一梳理下,當然這裡參考了園子裡面“幻天芒”的一篇文章,文章末尾我會給出文章鏈接。
控制台直接運行
Asp.Net Core 程式在發佈後,會產生一個入口 dll 文件,要運行該程式,只需要通過 dotnet 命令執行該 dll 文件即可。所以,第一種方式就是直接找到 dll 文件,並使用 dotnet 命令來運行。(你說 dotnet 命令哪來的?安裝了 Runtime 就有了。)當然這裡你還可以在運行的時候指定埠號
# 進行控制台執行
dotnet Czar.Cms.Admin.dll --urls=http://localhost:8099
運行結果如下圖所示:
IIS部署
用 .Net Framework 開發的應用,大家都比較熟悉用 IIS 來部署。那 .Net Core 呢?雖然兩者的運行模式並不相同,但微軟為了減少遷移難度,自然也提供了用 IIS 的部署方法。
與 Asp.Net 不同,ASP.NET Core 不再是由 IIS 工作進程(w3wp.exe)托管,而是使用自托管 Web 伺服器(Kestrel)運行,IIS 則是作為反向代理的角色轉發請求到 Kestrel 不同埠的 ASP.NET Core 程式中,隨後就將接收到的請求推送至中間件管道中去,處理完你的請求和相關業務邏輯之後再將 HTTP 響應數據重新回寫到 IIS 中,最終轉達到不同的客戶端(瀏覽器,APP,客戶端等)。
如果要使用 IIS 部署 Asp.Net Core 程式,步驟如下:
在托管系統上,創建一個文件夾以包含應用已發佈的文件夾和文件。 目錄結構主題中介紹了應用的部署佈局。
在“IIS 管理器”中,打開“連接”面板中的伺服器節點。 右鍵單擊“站點”文件夾。 選擇上下文菜單中的“添加網站”。
提供網站名稱,並將物理路徑設置為應用的部署文件夾。 提供“綁定”配置,並通過選擇“確定”創建網站:
警告
不應使用頂級通配符綁定(
http://*:80/
和http://+:80
)。 頂級通配符綁定可能會為應用帶來安全漏洞。 此行為同時適用於強通配符和弱通配符。 使用顯式主機名而不是通配符。 如果可控制整個父域(區別於易受攻擊的*.com
),則子域通配符綁定(例如,*.mysub.com
)不具有此安全風險。 有關詳細信息,請參閱 rfc7230 第 5.4 條。在伺服器節點下,選擇“應用程式池”。
右鍵單擊站點的應用池,然後從上下文菜單中選擇“基本設置”。
在“編輯應用程式池”視窗中,將“.NET CLR 版本”設置為“無托管代碼”:
ASP.NET Core 在單獨的進程中運行,並管理運行時。 ASP.NET Core 不依賴載入桌面 CLR。 將“.NET CLR 版本”設置為“無托管代碼”為可選步驟。
ASP.NET Core 2.2 或更高版本:對於使用進程內托管模型的 64 位 (x64) 獨立部署,為 32 位 (x86) 進程禁用應用池。
在 IIS 管理員的“應用程式池”的“操作”側欄中,選擇“設置應用程式池預設設置”或“高級設置”。 找到“啟用 32 位應用程式”並將值設置為
False
。 此設置不會影響針對進程外托管部署的應用。確認進程模型標識擁有適當的許可權。
如果將應用池的預設標識(“進程模型” > “標識”)從 ApplicationPoolIdentity 更改為另一標識,請驗證新標識擁有所需的許可權,可訪問應用的文件夾、資料庫和其他所需資源。 例如,應用池需要對文件夾的讀取和寫入許可權,以便應用在其中讀取和寫入文件。
瞭解更多,請參考:IIS 部署.Net Core 應用
目前我們採用的方式就是iis進行部署。
部署為 Windows Service
通過 Windows Service的部署方式,我們能夠解決上面控制台直接運行部署的開機啟動和持久運行問題,也能避開 iis部署 中的性能損失問題。具體如何做呢?如下提供一種方式(當然,也可以用其他方式來部署 Windows Service):
藉助 nssm 來管理 Windows Service,Nssm,用法,請參考:https://nssm.cc/usage
配置 Service 開機啟動。
安裝nssm,然後切換到nssm的安裝路徑,打開控制台
運行如下的命令:
nssm install <servicename>
從而打開nssm的安裝界面如下圖所示:就幾個選項,很簡單,大家安裝英文意思進行配置即可。
優勢:
- 高性能部署,穩定性好。
- 支持開機啟動。
劣勢:
- 僅能用於 Windows 伺服器。
- 引入了一個外包依賴 NSSM。
Linux 部署
由於 .Net Core 天生支持跨平臺,如果在廉價又穩定的 Linux 上部署 .Net Core 程式逐漸成為主流。對於 Linux 上的部署,和 Windows 上並沒有什麼區別。首先是安裝 Runtime 環境,然後拷貝程式,並通過命令行運行。
再進一步,可以使用後臺模式,讓程式在後臺運行。
更進一步,也可以效仿 Windows,把程式啟動管理作為一個服務,來達到開機啟動和靈活管理的目的。
Docker 部署
作為當前個人認為的最棒的 .Net Core 應用部署方式,建議大家都瞭解下。目前我們正在嘗試進行Docker化,然後用K8S來進行管理。
首先,是 Docker 的基本使用:
- 編寫 Dockerfile
- 使用
docker build
構建鏡像 - 使用
docker run
創建容器並運行
好,我們來依次說明,對於 Docker 來說,需要先安裝 Docker 環境。
接著,我們假設發佈包路徑如下:
root-folder/
app/ # 發佈包目錄
xxx.dll # 程式入口點
Dockerfile # Dockerfile文件
然後針對該程式,編寫如下 Dockerfile:
# 根鏡像
FROM microsoft/dotnet:2.2-runtime
# 拷貝程式發佈包
COPY app /app
# 設置工作目錄
WORKDIR /app
# 導出的埠
EXPOST 80
# 程式運行命令
CMD ["dotnet", "xxx.dll"]
接下來,通過在 root-folder
中執行 docker build -t xxx:0.0.1 .
來構建一個鏡像。
接著,再通過 docker run -it -p 8000:80 --name xxx-demo xxx:0.0.1
來創建並運行容器。
這樣,就可以通過 http://localhost:8000
來訪問到你的應用程式了。
此處只是大概寫下 Docker 部署的步驟,拋磚引玉。真正需要將其用於產線,還需要去學習下足夠的 Docker 知識。
額外提一下,如何選擇基礎鏡像
對於 .Net Core 來說,一般有如下幾類基礎鏡像:
- sdk -- 相信這個都比較容易理解,就是包含了 .Net Core SDK。
- runtime -- 這個也相對容易理解,包含了.Net Core Runtime。
- runtime-deps --這個就不是很好理解, runtime? deps? 什麼意思呢?就是說,這個連 Runtime都不是全的,需要你在打包的時候,選擇自寄宿模式,把Runtime也打進去。
綜上,我個人推薦大家選擇 runtime 這類作為基礎鏡像。
總結
今天給大家介紹了asp.net core的幾種部署方式希望對大家有所幫助,當然部分內容我沒有寫的很詳細,是想留給大家以思考,動手嘗試下!感謝大家的閱讀!