.NET Core 和 DevOps
關鍵要點
無論你目前使用什么樣的技術棧，DevOps 都是值得一試的。
閉源、專有軟件和構建過程與 DevOps 實踐不兼容。
.NET Core 是開源的，是基于 DevOps 構思和構建的。
.NET Core CLI 和 Roslyn API 讓整個交付流程變得更加開放，且具有更強的適應性強。
自動化是 DevOps 的重要組成部分，.NET Core 從一開始就支持自動化構建和部署。
隨著.NET?Core 2.0 的發布（最初發布于 2016 年），微軟擁有了一個通用、模塊化、跨平臺和開源的平臺最新主要版本。.NET?Core 在當前版本的.NET?Framework 中提供了很多 API。它最初是作為下一代 ASP.NET 解決方案而創建的，但現在成為很多其他場景的基礎，包括物聯網、云計算和下一代移動解決方案。在這篇文章中，我們將探討.NET?Core 的更多優勢，以及它如何在為傳統的.NET 開發人員帶來好處的同時，還能讓所有需要為市場帶來強大、高性能和經濟的解決方案的技術人員受益。
從.NET?1.0 推出測試版開始，我就在開發軟件。我還記得當時使用.NET 感覺就像在作弊一樣。我當時想，“這不是應該很難嗎？我的 malloc 在哪里？我不需要轉換指針了嗎？這個框架類庫用來做什么的？”
快進到 2018 年，我們仍然很樂意在.NET?Framework 上編寫代碼，不必為內存分配問題而煩惱。System.Thread 為我們處理線程問題，然后是 BackgroundWorker，現在是 Task。原先不是線程安全的 FCL 類現在被標記為線程安全的。想開發一個 Web 應用程序？它就是一個完整的框架，包含了所有必需的組件。.NET 為我們提供了很多原本需要手動完成的東西。作為開發人員，我們把更多的時間花在編寫業務邏輯代碼上。匯編 /C/C++ 擁護者可能會唏噓現在的一般開發人員都不需要硬核系統編程知識，但我不會這么抱怨！
從第一個 Beta 版開始，.NET 經歷了多次迭代，其中包括了四個主要版本。最近的迭代.NET?Core 是最重要的。.NET Core 帶來了真正的跨平臺、現代 CLI、構建系統和開源庫，等等。這些東西都很重要，但.NETCore 的承諾不止于此，它還涉及了軟件的開發和交付方式。
我開發軟件已經有二十多年了，所以我還記得源碼控制是為“大型”團隊而保留的。“自動化”并沒有真正出現在我們的詞典中——除了我們為客戶自動化業務流程。說得具體一點，就是構建 / 編譯軟件是由人類完成的。“構建經歷”會在她自己的計算機上生成二進制文件（所以生成的文件在她自己的計算機上總能正常運行）！
將軟件部署到它要運行的環境中是一個脆弱的拜占庭式過程，因為需要共享驅動器、FTP 和進行手動文件復制粘貼。整合開發團隊的工作是一場悲慘的死亡游行，一次又一次的回退就像玩打地鼠游戲一樣。是否可以投入生產？誰知道呢？
軟件正在迅速建立起對世界的興趣，但開發、部署和運營基于軟件的系統的過程卻停留在圖靈和Hopper時代。2008 年左右發生了一場革命，這場革命被稱為 DevOps。
從那時起到現在，這些年我們已經看到一場運動的興起。DevOps 非常重要，它包含并可能取代之前出現的敏捷運動。我在 2014 年開始接觸 DevOps，當時我在一次大會上拿到了《鳳凰項目》這本書。當我開始如饑似渴地閱讀那本書時，我的會議計劃被我拋到腦后。這本書講的東西太多了。如果你正處在 IT 行業，即使是很短的時間，你也一定扮演過那些角色。你可以試著自己代入角色。從那以后，DevOps 成了我職業生涯的焦點。
DevOps 通常被認為有三個主要的“支柱”：文化、流程和技術。本文是關于 DevOps 的技術部分。具體地說，是關于.NET?Core 為現代 DevOps 實踐帶來的技術。.NET Core 是在 DevOps 興起期間構思出來的。微軟顯然有明確的目標，就是讓.NET?Core 成為 DevOps 時代的平臺。本文將介紹.NET?Core 和 DevOps 的三個主要主題：
.NET Core 框架和 SDK；
構建自動化；
應用程序監控。
.NET Core 框架和 SDK
DevOps 并不是孤立存在的。用于生成和交付基于軟件的系統的技術可能可以支持或者阻礙 DevOps 實踐。無論你的技術棧是怎樣的，DevOps 都是值得一試的。話雖如此，你選擇的技術棧將對你的 DevOps 實踐產生重大影響。
閉源、專有構建系統對 DevOps 來說并不友好。.NET Core 是完全開源的，用于表示項目和解決方案的文件格式也有完整的文檔化。現代語言和框架（如 Node/JavaScript、Ruby 和 Python）已經具有一些常見特性：
緊湊的開源框架；
命令行界面（CLI）；
記錄良好的開放式構建系統；
支持所有主要操作系統。
這些特性和其他更多功能在 DevOps 時代變得越來越流行，因為它們具有很強的適用性和自動化能力。.NET?Core 的 CLI 命令 dotnet 是.NET?Core 應用程序構建過程的單一入口點。無論是什么平臺，開發人員都可以在工作站上使用 dotnet，用于構建代理。也就是說：我將在后續展示的所有本地開發工作都可以在 MacBook Pro 上進行。試著想象一下，這在三年前是不可能的事情！
使用.NET?Core 的第一步是下載它。你可以在這里下載 SDK。在我的 MBP 上有 171MB。安裝完畢后，打開你最喜歡的終端窗口（在 Windows 上我偏愛 Powershell，但在 Mac 上我使用 iTerm2）。
如果你已經很熟悉.NET 開發，那么可能已經習慣了安裝大型框架。你習慣使用 Visual Studio 來完成開發工作。如果你是.NET?Core 新手，可能會覺得有點奇怪。在使用 IDE 之前，我們可以使用這 171 兆字節的東西完成很多事情。
執行：
dotnet
這是一個新的 CLI 命令，用于與.NET?Core SDK 發生交互。讓我們來看一下。
執行：
dotnet help
這將列出 CLI 支持的所有命令，這個清單并不長，也沒必要很長。你可能在查找哪些是與.NET?Core 框架構建過程進行交互所需的，從一個新項目到已部署的應用程序。
第一步是創建一個新的應用程序。讓我們來看看我們的選項。
執行：
dotnet new
輸出的信息將列出可用的模板。在 Visual Studio 中你可以單擊 File-New Project 來創建項目，但在這里我們使用命令行。我們有很多模板可選擇。我偏愛 Angular，所以讓我們從那里開始吧。
執行：
dotnet new angular -o dotnet-angular
這將在新目錄 dotnet-angular 中創建一個新的 Angular 項目。如果你愿意，可以手動創建目錄，只是在執行 dotnet new 之前不要忘記更改目錄，否則將在當前目錄中創建項目。
如果你已經做過 Angular 開發，那么可能已經安裝了 Node。如果沒有，請花點時間下載并安裝它。如果確實需要安裝 Node，請在安裝后關閉并重新打開終端。
執行：
dotnet run
這個命令將編譯并運行應用程序（也可以通過執行 dotnet build 直接完成編譯，而無需運行應用程序來）。這可能需要一兩分鐘時間，然后你將得到一些包含 URL 的輸出：
Content root path: /Users/dswersky/dotnet-angular Now listening on: https://localhost:5001
將 URL 復制到 Web 瀏覽器中，然后等一會兒。你現在應該能看到一個在后臺運行 ASP.NET?Core、在前端運行 Angular 的簡單應用程序。那么，這種體驗與昔日的.NET 開發體驗有何不同？
你在幾分鐘內就創建并運行了一個.NET?Core 應用程序（即使包括安裝.NET?Core 和 Node），你可能會想到這幾個問題：
我的 IDE 呢？
到目前為止，我們還不需要 IDE，對嗎？很顯然，如果你想編輯這段代碼，你需要使用某些工具。你可能希望使用與.NET 和 Angular 相關的工具。“沒問題”，你可能會想，“我啟動 Visual Studio Professional 就可以了”。你可以這樣做…或者你也可以下載 Visual Studio Code，它提供了很多功能，而且是免費的。你可以使用 Visual Studio Community，它也是免費的。關鍵在于，不再需要花費數百美元就可以開始基于.NET?Core 的開發。
IIS 呢？
這是“遺留”.NET?Web 應用程序開發和 ASP.NET?Core 之間的主要區別。你可以在 IIS 中運行 ASP.NET?Core 應用程序，但也可不必這么做。.NET Core 是跨平臺的，所以將 ASP.NET?Core 與 IIS 分離也是顯而易見的。我在這里列出的命令，包括 dotnet run，在 Windows、Mac 和 Linux 上同樣運行良好，且效果完全相同（甚至還有一個可以在 Raspberry Pi 上運行的 ARM 構建命令）。這個 Angular 應用程序是“編寫一次，到處運行”的一個很好的示例。
不使用 IIS 來托管.NET 應用程序已經有一段時間了。.NET Open Web Interface（OWIN）多年來一直支持“自托管”ASP.NET 應用程序。這是通過代碼和基礎設施（通常稱為“Project Katana”）來實現的。.NET Core 使用了一個叫作Kestrel的 HTTPS 服務器。Kestrel 是一款用于.NET 應用程序的快速、高性能、開源的 HTTPS 服務器。Kestrel 為 ASP.NET?Core 網站和 RESTful 服務提供 HTTPS，讓它們可以運行在任何地方，包括 Windows、Linux 和容器協調器。Kestrel 使 ASP.NET?Core 應用程序變得完全獨立，在基于 Windows 的 HTTPS 服務器上沒有外部依賴性。
這與 DevOps 有什么關系？
自動化是 DevOps 的核心原則和實踐。.NET Core 提供的可移植性、CLI 和開源構建系統對于 DevOps 實踐來說至關重要。最重要的是，它們可以輕松實現構建和部署過程的自動化。可以通過編寫 CLI 腳本來實現自動化，也可以通過編程方式直接自動化構建系統。.NET Core 的這些功能使其不僅可以實現自動化，而且可以相對輕松地自動執行復雜的構建過程。我們因此能夠建立自動化和持續集成。
.NET Core 構建自動化
回到 Visual SourceSafe 時代，團隊提交到存儲庫的代碼就在那里，隨時準備好進行編譯。我的腦海里浮現出一個想法——“為什么我要在我的系統上構建部署，因為構建原本可以在存儲庫中進行？”我不是唯一一個有這種想法的人，但卻沒有對此采取什么行動。真正采取行動的是那些開始著手開發持續集成（CI）系統的勇士們。
CI 的目標說起來很簡單，但實現起來并不那么容易：
始終有一個可部署的構建。
軟件開發是一項團隊運動。Agile/Scrum 團隊平均有三到五名全職開發人員負責貢獻代碼。為了提升效率，他們之間進行了分工。然后他們開發的代碼必須作為一個整體進行組合、構建和測試，而且必須使用未安裝開發人員工具的系統進行自動化測試。理想情況下，在每次將新代碼合并到指定分支時都應該進行構建和測試。CI 系統通常直接與源碼控制系統集成，每次分支發生變更時觸發新構建。
Roslyn是一款開源的.NET 編譯器，提供了大量可直接訪問的 API。CI 系統開發人員使用這些編譯器 API 來構建插件，從而自動化.NET 構建過程。.NET Core 構建工具提供了對構建過程的細粒度控制。開發人員可以使用它們來調整和擴展現有的 CI 系統功能，以涵蓋幾乎任何可以想象的構建管道用例。你可以不是 CI 系統開發人員，但你可以構建插件。CI 系統的維護者和供應商竭盡全力使他們的系統易于擴展。
現在有很多 CI 系統。以下是一個簡短的示例列表：
Jenkins；
TFS/Visual Studio Team Services；
CircleCI；
TeamCity；
GitLab。
.NET Core 提供的靈活性讓它可以與任何 CI 系統集成，這就像使用 CLI 腳本或者使用編譯器 API 開發的插件直接自動化構建一樣簡單。
如果你目前擁有自己喜歡的 CI 系統，可以嘗試一下我的示例項目。這與我們之前使用 CLI 創建的項目是一樣的，只是多了一點東西。存儲庫包含了一個 Dockerfile，我花了大約十分鐘來創建一個 VSTS 構建管道、從 Github 中拉取代碼、構建鏡像，然后將其推送到 Azure 容器注冊表。這與 AWS 或 Google Cloud 中的 Jenkinsfile 或 GitLab 管道一樣好用。正如他們所說，一切皆有可能。
使用.NET?Core 進行應用程序監控
軟件系統的運維是一項全職工作，可以讓 Ops 團隊的同事來負責。這些系統就像嬰兒一樣——它們不斷地叫啼，需要獲得父母的關注。Ops 工作人員通常就像陷入困惑的父母一樣，不知道為什么系統會發生這樣那樣的問題。系統如何引起人們注意？這取決于你是如何照看它們的！
最糟糕的系統監控方式就是不進行監控。無論你是否或者以某種方式進行監控，在它們出現故障時都會被注意到。當你的客戶瘋狂地打進客服電話或者完全棄用你的服務時，你會發現已經太晚了。應用程序監控的目標是搶在客戶或最終用戶之前檢測出問題。很多公司做出錯誤的經濟判斷，他們認為應用程序監控過于昂貴，或者認為“好的系統不需要監控”。
即使是最穩定的系統離災難性事故也只有一步之遙。DevOps 實踐嘗試在安全性和速度之間做出平衡——同時讓公司可以通過快速移動進行創新。我們通過密切關注系統的運行參數來維持這種平衡。
.NET Core 的設計和架構非常適用進行應用程序監控。ASP.NET?Core 是一個很好的例子。我們可以使用 HTTP 模塊自定義在 IIS 上運行的 ASP.NET?3.x/4.x 應用程序的內部請求和響應行為。ASP.NET?Core 使用中間件改進了這種模型，中間件概念類似于 HTTP 模塊，但在實現方面卻非常不一樣。中間件類通過代碼進行集成，并且配置起來要簡單得多。它們形成了一個請求 / 響應管道鏈。
將中間件注入 ASP.NET?Core 應用程序是非常容易的。我將演示一個 Azure Application Insights 示例。我在 Azure Portal 中創建了一個 Application Insights 資源，然后在我的存儲庫中編輯了三個文件來啟用 Application Insights 監控：
dotnet-angular.csproj
添加了一行來引用 Application Insights 資源（之所以需要這個手動步驟，是因為我使用的是 Visual Studio for Mac，詳細信息請參見這里）。
appsettings.json
添加了我的 Application Insights 密鑰。
Startup.cs
Startup.cs 是配置中間件的地方。我在這里添加了 Application Insights 中間件。
完成這些工作后，我就能夠在本地進行調試，并收集來自 Application Insights 的監控數據。你可以自己嘗試一下，只需要用你的密鑰替換 appsettings.json 中的示例密鑰即可。
當然，Application Insights 并不是監控應用程序的唯一選擇。AppMetrics是一個開源監控庫，可與 Grafana 等可視化工具集成。一些供應商也提供了付費選項。
所有這些監控方案都提供了能夠在運行時環境中查看應用程序行為的透明度，這對于 DevOps 實踐來說至關重要，因為它可以在不影響系統性能的情況下讓你驗證對系統所做的更改。然后，你可以添加新功能，并確信快速變更不會破壞已有的東西。
結論
.NET Core 是在考慮 DevOps 實踐的情況下構思和開發出來的。CLI 和開放式構建系統和庫讓軟件交付過程自動化變得可能。如果你愿意，可以通過 CLI 腳本或更深入的編程集成來實現構建自動化和持續集成。使用開源或付費企業工具進行應用程序監控可將你的系統從黑匣子轉變為透明的玻璃窗格。基于 DevOps 實踐的.NET?Core 是現代軟件系統的一個非常具有吸引力的平臺。
關于作者
Dave Swersky，從事 IT 工作已超過 20 年，從支持工程師到軟件開發人員，再到企業架構師。他是一個有抱負的多面手，并且對 DevOps 充滿熱情。他曾在很多與 DevOps 相關的大會上做過演講，包括 DevOps 企業峰會、CodeMash、Stir Trek 以及 KC 的本地聚會。Dave 還寫了一本關于 DevOps 的書：DevOps Katas: Hands-On DevOps。可以通過 Twitter 賬號 @dswersky 找到 Dave
原文地址：https://www.infoq.cn/article/bQglfj1OSH-UskotCXu8
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的.NET Core 和 DevOps的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： NumSharp v0.6 科学计算库发
- 下一篇： .NET Core开发日志——结构化日志