關(guān)鍵要點(diǎn)

• 無論你目前使用什么樣的技術(shù)棧，DevOps 都是值得一試的。

• 閉源、專有軟件和構(gòu)建過程與 DevOps 實(shí)踐不兼容。

• .NET Core 是開源的，是基于 DevOps 構(gòu)思和構(gòu)建的。

• .NET Core CLI 和 Roslyn API 讓整個(gè)交付流程變得更加開放，且具有更強(qiáng)的適應(yīng)性強(qiáng)。

• 自動化是 DevOps 的重要組成部分，.NET Core 從一開始就支持自動化構(gòu)建和部署。

隨著.NET?Core 2.0 的發(fā)布（最初發(fā)布于 2016 年），微軟擁有了一個(gè)通用、模塊化、跨平臺和開源的平臺最新主要版本。.NET?Core 在當(dāng)前版本的.NET?Framework 中提供了很多 API。它最初是作為下一代 ASP.NET 解決方案而創(chuàng)建的，但現(xiàn)在成為很多其他場景的基礎(chǔ)，包括物聯(lián)網(wǎng)、云計(jì)算和下一代移動解決方案。在這篇文章中，我們將探討.NET?Core 的更多優(yōu)勢，以及它如何在為傳統(tǒng)的.NET 開發(fā)人員帶來好處的同時(shí)，還能讓所有需要為市場帶來強(qiáng)大、高性能和經(jīng)濟(jì)的解決方案的技術(shù)人員受益。

從.NET?1.0 推出測試版開始，我就在開發(fā)軟件。我還記得當(dāng)時(shí)使用.NET 感覺就像在作弊一樣。我當(dāng)時(shí)想，“這不是應(yīng)該很難嗎？我的 malloc 在哪里？我不需要轉(zhuǎn)換指針了嗎？這個(gè)框架類庫用來做什么的？”

快進(jìn)到 2018 年，我們?nèi)匀缓軜芬庠?NET?Framework 上編寫代碼，不必為內(nèi)存分配問題而煩惱。System.Thread 為我們處理線程問題，然后是 BackgroundWorker，現(xiàn)在是 Task。原先不是線程安全的 FCL 類現(xiàn)在被標(biāo)記為線程安全的。想開發(fā)一個(gè) Web 應(yīng)用程序？它就是一個(gè)完整的框架，包含了所有必需的組件。.NET 為我們提供了很多原本需要手動完成的東西。作為開發(fā)人員，我們把更多的時(shí)間花在編寫業(yè)務(wù)邏輯代碼上。匯編 /C/C++ 擁護(hù)者可能會唏噓現(xiàn)在的一般開發(fā)人員都不需要硬核系統(tǒng)編程知識，但我不會這么抱怨！

從第一個(gè) Beta 版開始，.NET 經(jīng)歷了多次迭代，其中包括了四個(gè)主要版本。最近的迭代.NET?Core 是最重要的。.NET Core 帶來了真正的跨平臺、現(xiàn)代 CLI、構(gòu)建系統(tǒng)和開源庫，等等。這些東西都很重要，但.NETCore 的承諾不止于此，它還涉及了軟件的開發(fā)和交付方式。

我開發(fā)軟件已經(jīng)有二十多年了，所以我還記得源碼控制是為“大型”團(tuán)隊(duì)而保留的。“自動化”并沒有真正出現(xiàn)在我們的詞典中——除了我們?yōu)榭蛻糇詣踊瘶I(yè)務(wù)流程。說得具體一點(diǎn)，就是構(gòu)建 / 編譯軟件是由人類完成的。“構(gòu)建經(jīng)歷”會在她自己的計(jì)算機(jī)上生成二進(jìn)制文件（所以生成的文件在她自己的計(jì)算機(jī)上總能正常運(yùn)行）！

將軟件部署到它要運(yùn)行的環(huán)境中是一個(gè)脆弱的拜占庭式過程，因?yàn)樾枰蚕眚?qū)動器、FTP 和進(jìn)行手動文件復(fù)制粘貼。整合開發(fā)團(tuán)隊(duì)的工作是一場悲慘的死亡游行，一次又一次的回退就像玩打地鼠游戲一樣。是否可以投入生產(chǎn)？誰知道呢？

軟件正在迅速建立起對世界的興趣，但開發(fā)、部署和運(yùn)營基于軟件的系統(tǒng)的過程卻停留在圖靈和Hopper時(shí)代。2008 年左右發(fā)生了一場革命，這場革命被稱為 DevOps。

從那時(shí)起到現(xiàn)在，這些年我們已經(jīng)看到一場運(yùn)動的興起。DevOps 非常重要，它包含并可能取代之前出現(xiàn)的敏捷運(yùn)動。我在 2014 年開始接觸 DevOps，當(dāng)時(shí)我在一次大會上拿到了《鳳凰項(xiàng)目》這本書。當(dāng)我開始如饑似渴地閱讀那本書時(shí)，我的會議計(jì)劃被我拋到腦后。這本書講的東西太多了。如果你正處在 IT 行業(yè)，即使是很短的時(shí)間，你也一定扮演過那些角色。你可以試著自己代入角色。從那以后，DevOps 成了我職業(yè)生涯的焦點(diǎn)。

DevOps 通常被認(rèn)為有三個(gè)主要的“支柱”：文化、流程和技術(shù)。本文是關(guān)于 DevOps 的技術(shù)部分。具體地說，是關(guān)于.NET?Core 為現(xiàn)代 DevOps 實(shí)踐帶來的技術(shù)。.NET Core 是在 DevOps 興起期間構(gòu)思出來的。微軟顯然有明確的目標(biāo)，就是讓.NET?Core 成為 DevOps 時(shí)代的平臺。本文將介紹.NET?Core 和 DevOps 的三個(gè)主要主題：

• .NET Core 框架和 SDK；

• 構(gòu)建自動化；

• 應(yīng)用程序監(jiān)控。

.NET Core 框架和 SDK

DevOps 并不是孤立存在的。用于生成和交付基于軟件的系統(tǒng)的技術(shù)可能可以支持或者阻礙 DevOps 實(shí)踐。無論你的技術(shù)棧是怎樣的，DevOps 都是值得一試的。話雖如此，你選擇的技術(shù)棧將對你的 DevOps 實(shí)踐產(chǎn)生重大影響。

閉源、專有構(gòu)建系統(tǒng)對 DevOps 來說并不友好。.NET Core 是完全開源的，用于表示項(xiàng)目和解決方案的文件格式也有完整的文檔化。現(xiàn)代語言和框架（如 Node/JavaScript、Ruby 和 Python）已經(jīng)具有一些常見特性：

• 緊湊的開源框架；

• 命令行界面（CLI）；

• 記錄良好的開放式構(gòu)建系統(tǒng)；

• 支持所有主要操作系統(tǒng)。

這些特性和其他更多功能在 DevOps 時(shí)代變得越來越流行，因?yàn)樗鼈兙哂泻軓?qiáng)的適用性和自動化能力。.NET?Core 的 CLI 命令 dotnet 是.NET?Core 應(yīng)用程序構(gòu)建過程的單一入口點(diǎn)。無論是什么平臺，開發(fā)人員都可以在工作站上使用 dotnet，用于構(gòu)建代理。也就是說：我將在后續(xù)展示的所有本地開發(fā)工作都可以在 MacBook Pro 上進(jìn)行。試著想象一下，這在三年前是不可能的事情！

使用.NET?Core 的第一步是下載它。你可以在這里下載 SDK。在我的 MBP 上有 171MB。安裝完畢后，打開你最喜歡的終端窗口（在 Windows 上我偏愛 Powershell，但在 Mac 上我使用 iTerm2）。

如果你已經(jīng)很熟悉.NET 開發(fā)，那么可能已經(jīng)習(xí)慣了安裝大型框架。你習(xí)慣使用 Visual Studio 來完成開發(fā)工作。如果你是.NET?Core 新手，可能會覺得有點(diǎn)奇怪。在使用 IDE 之前，我們可以使用這 171 兆字節(jié)的東西完成很多事情。

執(zhí)行：

dotnet

這是一個(gè)新的 CLI 命令，用于與.NET?Core SDK 發(fā)生交互。讓我們來看一下。

執(zhí)行：

dotnet help

這將列出 CLI 支持的所有命令，這個(gè)清單并不長，也沒必要很長。你可能在查找哪些是與.NET?Core 框架構(gòu)建過程進(jìn)行交互所需的，從一個(gè)新項(xiàng)目到已部署的應(yīng)用程序。

第一步是創(chuàng)建一個(gè)新的應(yīng)用程序。讓我們來看看我們的選項(xiàng)。

執(zhí)行：

dotnet new

輸出的信息將列出可用的模板。在 Visual Studio 中你可以單擊 File-New Project 來創(chuàng)建項(xiàng)目，但在這里我們使用命令行。我們有很多模板可選擇。我偏愛 Angular，所以讓我們從那里開始吧。

執(zhí)行：

dotnet new angular -o dotnet-angular

這將在新目錄 dotnet-angular 中創(chuàng)建一個(gè)新的 Angular 項(xiàng)目。如果你愿意，可以手動創(chuàng)建目錄，只是在執(zhí)行 dotnet new 之前不要忘記更改目錄，否則將在當(dāng)前目錄中創(chuàng)建項(xiàng)目。

如果你已經(jīng)做過 Angular 開發(fā)，那么可能已經(jīng)安裝了 Node。如果沒有，請花點(diǎn)時(shí)間下載并安裝它。如果確實(shí)需要安裝 Node，請?jiān)诎惭b后關(guān)閉并重新打開終端。

執(zhí)行：

dotnet run

這個(gè)命令將編譯并運(yùn)行應(yīng)用程序（也可以通過執(zhí)行 dotnet build 直接完成編譯，而無需運(yùn)行應(yīng)用程序來）。這可能需要一兩分鐘時(shí)間，然后你將得到一些包含 URL 的輸出：

Content root path: /Users/dswersky/dotnet-angular Now listening on: https://localhost:5001

將 URL 復(fù)制到 Web 瀏覽器中，然后等一會兒。你現(xiàn)在應(yīng)該能看到一個(gè)在后臺運(yùn)行 ASP.NET?Core、在前端運(yùn)行 Angular 的簡單應(yīng)用程序。那么，這種體驗(yàn)與昔日的.NET 開發(fā)體驗(yàn)有何不同？

你在幾分鐘內(nèi)就創(chuàng)建并運(yùn)行了一個(gè).NET?Core 應(yīng)用程序（即使包括安裝.NET?Core 和 Node），你可能會想到這幾個(gè)問題：

我的 IDE 呢？

到目前為止，我們還不需要 IDE，對嗎？很顯然，如果你想編輯這段代碼，你需要使用某些工具。你可能希望使用與.NET 和 Angular 相關(guān)的工具。“沒問題”，你可能會想，“我啟動 Visual Studio Professional 就可以了”。你可以這樣做…或者你也可以下載 Visual Studio Code，它提供了很多功能，而且是免費(fèi)的。你可以使用 Visual Studio Community，它也是免費(fèi)的。關(guān)鍵在于，不再需要花費(fèi)數(shù)百美元就可以開始基于.NET?Core 的開發(fā)。

IIS 呢？

這是“遺留”.NET?Web 應(yīng)用程序開發(fā)和 ASP.NET?Core 之間的主要區(qū)別。你可以在 IIS 中運(yùn)行 ASP.NET?Core 應(yīng)用程序，但也可不必這么做。.NET Core 是跨平臺的，所以將 ASP.NET?Core 與 IIS 分離也是顯而易見的。我在這里列出的命令，包括 dotnet run，在 Windows、Mac 和 Linux 上同樣運(yùn)行良好，且效果完全相同（甚至還有一個(gè)可以在 Raspberry Pi 上運(yùn)行的 ARM 構(gòu)建命令）。這個(gè) Angular 應(yīng)用程序是“編寫一次，到處運(yùn)行”的一個(gè)很好的示例。

不使用 IIS 來托管.NET 應(yīng)用程序已經(jīng)有一段時(shí)間了。.NET Open Web Interface（OWIN）多年來一直支持“自托管”ASP.NET 應(yīng)用程序。這是通過代碼和基礎(chǔ)設(shè)施（通常稱為“Project Katana”）來實(shí)現(xiàn)的。.NET Core 使用了一個(gè)叫作Kestrel的 HTTPS 服務(wù)器。Kestrel 是一款用于.NET 應(yīng)用程序的快速、高性能、開源的 HTTPS 服務(wù)器。Kestrel 為 ASP.NET?Core 網(wǎng)站和 RESTful 服務(wù)提供 HTTPS，讓它們可以運(yùn)行在任何地方，包括 Windows、Linux 和容器協(xié)調(diào)器。Kestrel 使 ASP.NET?Core 應(yīng)用程序變得完全獨(dú)立，在基于 Windows 的 HTTPS 服務(wù)器上沒有外部依賴性。

這與 DevOps 有什么關(guān)系？

自動化是 DevOps 的核心原則和實(shí)踐。.NET Core 提供的可移植性、CLI 和開源構(gòu)建系統(tǒng)對于 DevOps 實(shí)踐來說至關(guān)重要。最重要的是，它們可以輕松實(shí)現(xiàn)構(gòu)建和部署過程的自動化。可以通過編寫 CLI 腳本來實(shí)現(xiàn)自動化，也可以通過編程方式直接自動化構(gòu)建系統(tǒng)。.NET Core 的這些功能使其不僅可以實(shí)現(xiàn)自動化，而且可以相對輕松地自動執(zhí)行復(fù)雜的構(gòu)建過程。我們因此能夠建立自動化和持續(xù)集成。

.NET Core 構(gòu)建自動化

回到 Visual SourceSafe 時(shí)代，團(tuán)隊(duì)提交到存儲庫的代碼就在那里，隨時(shí)準(zhǔn)備好進(jìn)行編譯。我的腦海里浮現(xiàn)出一個(gè)想法——“為什么我要在我的系統(tǒng)上構(gòu)建部署，因?yàn)闃?gòu)建原本可以在存儲庫中進(jìn)行？”我不是唯一一個(gè)有這種想法的人，但卻沒有對此采取什么行動。真正采取行動的是那些開始著手開發(fā)持續(xù)集成（CI）系統(tǒng)的勇士們。

CI 的目標(biāo)說起來很簡單，但實(shí)現(xiàn)起來并不那么容易：

始終有一個(gè)可部署的構(gòu)建。

軟件開發(fā)是一項(xiàng)團(tuán)隊(duì)運(yùn)動。Agile/Scrum 團(tuán)隊(duì)平均有三到五名全職開發(fā)人員負(fù)責(zé)貢獻(xiàn)代碼。為了提升效率，他們之間進(jìn)行了分工。然后他們開發(fā)的代碼必須作為一個(gè)整體進(jìn)行組合、構(gòu)建和測試，而且必須使用未安裝開發(fā)人員工具的系統(tǒng)進(jìn)行自動化測試。理想情況下，在每次將新代碼合并到指定分支時(shí)都應(yīng)該進(jìn)行構(gòu)建和測試。CI 系統(tǒng)通常直接與源碼控制系統(tǒng)集成，每次分支發(fā)生變更時(shí)觸發(fā)新構(gòu)建。

Roslyn是一款開源的.NET 編譯器，提供了大量可直接訪問的 API。CI 系統(tǒng)開發(fā)人員使用這些編譯器 API 來構(gòu)建插件，從而自動化.NET 構(gòu)建過程。.NET Core 構(gòu)建工具提供了對構(gòu)建過程的細(xì)粒度控制。開發(fā)人員可以使用它們來調(diào)整和擴(kuò)展現(xiàn)有的 CI 系統(tǒng)功能，以涵蓋幾乎任何可以想象的構(gòu)建管道用例。你可以不是 CI 系統(tǒng)開發(fā)人員，但你可以構(gòu)建插件。CI 系統(tǒng)的維護(hù)者和供應(yīng)商竭盡全力使他們的系統(tǒng)易于擴(kuò)展。

現(xiàn)在有很多 CI 系統(tǒng)。以下是一個(gè)簡短的示例列表：

• Jenkins；

• TFS/Visual Studio Team Services；

• CircleCI；

• TeamCity；

• GitLab。

.NET Core 提供的靈活性讓它可以與任何 CI 系統(tǒng)集成，這就像使用 CLI 腳本或者使用編譯器 API 開發(fā)的插件直接自動化構(gòu)建一樣簡單。

如果你目前擁有自己喜歡的 CI 系統(tǒng)，可以嘗試一下我的示例項(xiàng)目。這與我們之前使用 CLI 創(chuàng)建的項(xiàng)目是一樣的，只是多了一點(diǎn)東西。存儲庫包含了一個(gè) Dockerfile，我花了大約十分鐘來創(chuàng)建一個(gè) VSTS 構(gòu)建管道、從 Github 中拉取代碼、構(gòu)建鏡像，然后將其推送到 Azure 容器注冊表。這與 AWS 或 Google Cloud 中的 Jenkinsfile 或 GitLab 管道一樣好用。正如他們所說，一切皆有可能。

使用.NET?Core 進(jìn)行應(yīng)用程序監(jiān)控

軟件系統(tǒng)的運(yùn)維是一項(xiàng)全職工作，可以讓 Ops 團(tuán)隊(duì)的同事來負(fù)責(zé)。這些系統(tǒng)就像嬰兒一樣——它們不斷地叫啼，需要獲得父母的關(guān)注。Ops 工作人員通常就像陷入困惑的父母一樣，不知道為什么系統(tǒng)會發(fā)生這樣那樣的問題。系統(tǒng)如何引起人們注意？這取決于你是如何照看它們的！

最糟糕的系統(tǒng)監(jiān)控方式就是不進(jìn)行監(jiān)控。無論你是否或者以某種方式進(jìn)行監(jiān)控，在它們出現(xiàn)故障時(shí)都會被注意到。當(dāng)你的客戶瘋狂地打進(jìn)客服電話或者完全棄用你的服務(wù)時(shí)，你會發(fā)現(xiàn)已經(jīng)太晚了。應(yīng)用程序監(jiān)控的目標(biāo)是搶在客戶或最終用戶之前檢測出問題。很多公司做出錯誤的經(jīng)濟(jì)判斷，他們認(rèn)為應(yīng)用程序監(jiān)控過于昂貴，或者認(rèn)為“好的系統(tǒng)不需要監(jiān)控”。

即使是最穩(wěn)定的系統(tǒng)離災(zāi)難性事故也只有一步之遙。DevOps 實(shí)踐嘗試在安全性和速度之間做出平衡——同時(shí)讓公司可以通過快速移動進(jìn)行創(chuàng)新。我們通過密切關(guān)注系統(tǒng)的運(yùn)行參數(shù)來維持這種平衡。

.NET Core 的設(shè)計(jì)和架構(gòu)非常適用進(jìn)行應(yīng)用程序監(jiān)控。ASP.NET?Core 是一個(gè)很好的例子。我們可以使用 HTTP 模塊自定義在 IIS 上運(yùn)行的 ASP.NET?3.x/4.x 應(yīng)用程序的內(nèi)部請求和響應(yīng)行為。ASP.NET?Core 使用中間件改進(jìn)了這種模型，中間件概念類似于 HTTP 模塊，但在實(shí)現(xiàn)方面卻非常不一樣。中間件類通過代碼進(jìn)行集成，并且配置起來要簡單得多。它們形成了一個(gè)請求 / 響應(yīng)管道鏈。

將中間件注入 ASP.NET?Core 應(yīng)用程序是非常容易的。我將演示一個(gè) Azure Application Insights 示例。我在 Azure Portal 中創(chuàng)建了一個(gè) Application Insights 資源，然后在我的存儲庫中編輯了三個(gè)文件來啟用 Application Insights 監(jiān)控：

dotnet-angular.csproj

添加了一行來引用 Application Insights 資源（之所以需要這個(gè)手動步驟，是因?yàn)槲沂褂玫氖?Visual Studio for Mac，詳細(xì)信息請參見這里）。

appsettings.json

添加了我的 Application Insights 密鑰。

Startup.cs

Startup.cs 是配置中間件的地方。我在這里添加了 Application Insights 中間件。

完成這些工作后，我就能夠在本地進(jìn)行調(diào)試，并收集來自 Application Insights 的監(jiān)控?cái)?shù)據(jù)。你可以自己嘗試一下，只需要用你的密鑰替換 appsettings.json 中的示例密鑰即可。

當(dāng)然，Application Insights 并不是監(jiān)控應(yīng)用程序的唯一選擇。AppMetrics是一個(gè)開源監(jiān)控庫，可與 Grafana 等可視化工具集成。一些供應(yīng)商也提供了付費(fèi)選項(xiàng)。

所有這些監(jiān)控方案都提供了能夠在運(yùn)行時(shí)環(huán)境中查看應(yīng)用程序行為的透明度，這對于 DevOps 實(shí)踐來說至關(guān)重要，因?yàn)樗梢栽诓挥绊懴到y(tǒng)性能的情況下讓你驗(yàn)證對系統(tǒng)所做的更改。然后，你可以添加新功能，并確信快速變更不會破壞已有的東西。

結(jié)論

.NET Core 是在考慮 DevOps 實(shí)踐的情況下構(gòu)思和開發(fā)出來的。CLI 和開放式構(gòu)建系統(tǒng)和庫讓軟件交付過程自動化變得可能。如果你愿意，可以通過 CLI 腳本或更深入的編程集成來實(shí)現(xiàn)構(gòu)建自動化和持續(xù)集成。使用開源或付費(fèi)企業(yè)工具進(jìn)行應(yīng)用程序監(jiān)控可將你的系統(tǒng)從黑匣子轉(zhuǎn)變?yōu)橥该鞯牟ＡТ案瘛；?DevOps 實(shí)踐的.NET?Core 是現(xiàn)代軟件系統(tǒng)的一個(gè)非常具有吸引力的平臺。

關(guān)于作者

Dave Swersky，從事 IT 工作已超過 20 年，從支持工程師到軟件開發(fā)人員，再到企業(yè)架構(gòu)師。他是一個(gè)有抱負(fù)的多面手，并且對 DevOps 充滿熱情。他曾在很多與 DevOps 相關(guān)的大會上做過演講，包括 DevOps 企業(yè)峰會、CodeMash、Stir Trek 以及 KC 的本地聚會。Dave 還寫了一本關(guān)于 DevOps 的書：DevOps Katas: Hands-On DevOps。可以通過 Twitter 賬號 @dswersky 找到 Dave

原文地址：https://www.infoq.cn/article/bQglfj1OSH-UskotCXu8

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結(jié)

以上是生活随笔為你收集整理的.NET Core 和 DevOps的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。