Asp.Net Core部署:早知道,还是docker!以及一点碎碎念
前言
AspNetCore技術棧在我們團隊里的使用也有一段時間了,之前的部署方式一直是本地編譯之后上傳可執行文件到服務器,使用supervisor來管理進程這種很原始的方式。
參考之前的文章:Asp.Net Core學習筆記:(五)構建和部署
對于小項目來說尚可,夠用,但是存在幾個問題:
每次更新花費的時間太長了,無論是Framework-Dependent還是Self-Contained,都要上傳很大的文件~
更新的時候需要在supervisor里把進程停掉,不然無法覆蓋
每次更新都是手動操作,一點也不geek
鑒于之前使用Django的項目里docker用得非常愉快,而且到處在宣傳.netcore新技術對docker的官方支持有多好多好,于是我這也不能落后,必須上docker部署啊!
更關鍵的一點理由是,最近搞了個新的小項目,用到了Redis,但服務器上沒裝Redis,作為一個被docker慣壞的人,我也不可能去安裝配置這些東西~
那就開始吧,直接從微軟官方文檔開始(MSDN真是好東西啊)
開始
事實上,我現在已經開始嘗鮮使用 .net6.0 來新建項目了,默認的項目模板中就帶有docker配置,完全是傻瓜式的,不用自己寫什么配置文件,上傳到服務器里就是docker build一把梭(或者是docker-compose up更好)
沒有的也沒事,把VS升級到最新的2022版本~~(其他版本應該也有,請自測)~~,項目右鍵添加就能選擇Docker支持了
其實Rider也可以,并且我在此前也是一直使用Rider開發的,但截至本文編寫時,Rider的2021.3版本還沒推出,尚未支持 .net6.0 ,因此我沒有使用Rider測試自動添加docker支持
不想使用傻瓜式生成dockerfile也行,下面給出我部署的這個項目的dockerfile,可以參考一下。(項目名稱為:DataMiddlePlatform)
#See?https://aka.ms/containerfastmode?to?understand?how?Visual?Studio?uses?this?Dockerfile?to?build?your?images?for?faster?debugging.FROM?mcr.microsoft.com/dotnet/aspnet:6.0?AS?base WORKDIR?/app EXPOSE?80 EXPOSE?443FROM?mcr.microsoft.com/dotnet/sdk:6.0?AS?build WORKDIR?/src COPY?["DataMiddlePlatform/DataMiddlePlatform.csproj",?"DataMiddlePlatform/"] RUN?dotnet?restore?"DataMiddlePlatform/DataMiddlePlatform.csproj" COPY?.?. WORKDIR?"/src/DataMiddlePlatform" RUN?dotnet?build?"DataMiddlePlatform.csproj"?-c?Release?-o?/app/buildFROM?build?AS?publish RUN?dotnet?publish?"DataMiddlePlatform.csproj"?-c?Release?-o?/app/publishFROM?base?AS?final WORKDIR?/app COPY?--from=publish?/app/publish?. ENTRYPOINT?["dotnet",?"DataMiddlePlatform.dll"]其實dockerfile基本可以不管的,因為 .net6.0 項目生成的時候,都會有個dockerfile,在本項目中我只修改了docker-compose.yml文件,因為要增加一個Redis容器~
以下是我的docker-compose.yml文件代碼
version:?'3.4'services:redis:image:?redisexpose:-?6379web:image:?${DOCKER_REGISTRY-}webenvironment:-?ASPNETCORE_ENVIRONMENT=Production-?ASPNETCORE_URLS=https://+:443;http://+:80build:context:?.dockerfile:?DataMiddlePlatform/Dockerfiledepends_on:-?redisports:-?"15002:80"-?"15003:443"不多解釋了,docker-compose的用法詳見官方文檔
環境切換
之前我們在docker-compose.yml里添加了Redis容器,并在web鏡像里添加了依賴,所以在Web容器里訪問Redis是用redis:6379這樣的地址,不像本地開發時一樣使用localhost:6379,如果在Django里就要在settings.py里根據環境變量判斷了(我的Django-Starter框架集成了自動識別)
而AspNetCore的基礎設施做得很完善,默認就有development、staging、production這三個環境,每個環境有對應的appsettings.json配置文件,所以只要在配置文件里區分不同的Redis地址就好了,如果是其他數據庫的配置也同理,真是方便啊~!
到本項目中就是,在appsettings.Development.json文件里,Redis的連接地址是"Connection": "127.0.0.1:6379",本地開發時使用本地安裝的Redis服務。
然后appsettings.json文件里,使用"Connection": "redis:6379",docker部署的時候,使用docker里的Redis服務~
完美
部署
既然寫完了dockerfile和docker-compose.yml,那部署這塊也沒啥好說的,就把整個代碼文件夾上傳到服務器,之后一行命令搞定:docker-compose up~
因為這AspNetCore本身性能就很可以了,小項目都不用nginx來提供靜態文件服務,方便得很~!
要更新服務的話,目前就是上傳代碼之后執行docker-compose up --build重新構建,因為只需要上傳代碼文件,這樣下來每次更新的速度快多了,而且可以寫腳本在git commit后一鍵執行更新,也…算是自動了吧…hhh
小結
微服務是發展趨勢,應用從舊的部署方式到容器化是很重要的一步,雖然我們團隊的Java還處在一個jar包丟上去supervisor運行的階段,(吐槽:后面甚至有項目都沒有掛supervisor,直接shell里執行起來,什么時候掛了都不知道)
經過這段時間的實踐下來,AspNetCore還是很可靠的扛住了不低的并發,也有比較完善的生態(雖然第三方庫比不上Java和Python,但完完全全夠好用了),開發效率高(但學習門檻也不低,至少比Django難),綜合優缺點下來,加上我自己對這框架的掌握也還很粗淺,所以只能小范圍推廣了~
我對于AspNetCore目前還處在摸索階段,好用是好用,就是在工作中用得還不夠多,不夠熟悉,加上之前折騰Django的經歷讓我嘗到了動態語言開發的甜頭,所以不會短時間把團隊的技術棧全部遷移到NetCore上去,畢竟會C#的人還是不夠多,新招進來的應屆生來現學也有不低的門檻,項目進度也禁不起這種折騰…
我還是很喜歡微軟的這套技術棧,它真的很好用,目前以及后續的小項目毫無疑問都會選擇這套東西,但對于提高多少生產力,我目前是沒多少底氣的,接下來要調研一番構建自動化、部署自動化方面的技術,哎,小團隊的基礎設施不足真是痛苦…… 難怪現在Serverless開始流行起來了,低代碼平臺也起來了,程序員終究要自己砸自己的飯碗…
參考資料
托管和部署 ASP.NET Core | Microsoft Docs
在 Docker 容器中托管 ASP.NET Core | Microsoft Docs
.NET 微服務。適用于容器化 .NET 應用程序的體系結構 | Microsoft Docs
總結
以上是生活随笔為你收集整理的Asp.Net Core部署:早知道,还是docker!以及一点碎碎念的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 阻止你变现的,从来都不是开源许可证
- 下一篇: AspNetCore在docker部署时