前言

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!以及一点碎碎念的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。