DotNET Core與 DevOps敏捷實現(xiàn)概述

1、 .NET Core 與 DevOps敏捷實現(xiàn)概述目 錄 TOC o 1-3 h z u HYPERLINK l _Toc535517768 1.關(guān)鍵要點 PAGEREF _Toc535517768 h 3 HYPERLINK l _Toc535517769 2.NET Core 框架和 SDK PAGEREF _Toc535517769 h 5 HYPERLINK l _Toc535517770 2.1.我的 IDE 呢 PAGEREF _Toc535517770 h 8 HYPERLINK l _Toc535517771 2.2.使用IIS PAGEREF _Toc535517771 h

2、8 HYPERLINK l _Toc535517772 2.3.這與 DevOps 有什么關(guān)系 PAGEREF _Toc535517772 h 9 HYPERLINK l _Toc535517773 3.NET Core 構(gòu)建自動化 PAGEREF _Toc535517773 h 9 HYPERLINK l _Toc535517774 3.1.始終有一個可部署的構(gòu)建。 PAGEREF _Toc535517774 h 10 HYPERLINK l _Toc535517775 4.使用.NETCore 進行應用程序監(jiān)控 PAGEREF _Toc535517775 h 11 HYPERLINK l

3、_Toc535517776 5.結(jié)論 PAGEREF _Toc535517776 h 13關(guān)鍵要點無論你目前使用什么樣的技術(shù)棧，DevOps 都是值得一試的。閉源、專有軟件和構(gòu)建過程與 DevOps 實踐不兼容。.NET Core 是開源的，是基于 DevOps 構(gòu)思和構(gòu)建的。.NET Core CLI 和 Roslyn API 讓整個交付流程變得更加開放，且具有更強的適應性強。自動化是 DevOps 的重要組成部分，.NET Core 從一開始就支持自動化構(gòu)建和部署。隨著.NETCore 2.0 的發(fā)布（最初發(fā)布于 2016 年），微軟擁有了一個通用、模塊化、跨平臺和開源的平臺最新主要版本。

4、.NETCore 在當前版本的.NETFramework 中提供了很多 API。它最初是作為下一代 ASP.NET 解決方案而創(chuàng)建的，但現(xiàn)在成為很多其他場景的基礎(chǔ)，包括物聯(lián)網(wǎng)、云計算和下一代移動解決方案。在這篇文章中，我們將探討.NETCore 的更多優(yōu)勢，以及它如何在為傳統(tǒng)的.NET 開發(fā)人員帶來好處的同時，還能讓所有需要為市場帶來強大、高性能和經(jīng)濟的解決方案的技術(shù)人員受益。從.NET1.0 推出測試版開始，我就在開發(fā)軟件。我還記得當時使用.NET 感覺就像在作弊一樣。我當時想，“這不是應該很難嗎？我的 malloc 在哪里？我不需要轉(zhuǎn)換指針了嗎？這個框架類庫用來做什么的？”快進到 2018

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

6、。最近的迭代.NETCore 是最重要的。.NET Core 帶來了真正的跨平臺、現(xiàn)代 CLI、構(gòu)建系統(tǒng)和開源庫，等等。這些東西都很重要，但.NETCore 的承諾不止于此，它還涉及了軟件的開發(fā)和交付方式。我開發(fā)軟件已經(jīng)有二十多年了，所以我還記得源碼控制是為“大型”團隊而保留的?！白詣踊辈]有真正出現(xiàn)在我們的詞典中除了我們?yōu)榭蛻糇詣踊瘶I(yè)務(wù)流程。說得具體一點，就是構(gòu)建 / 編譯軟件是由人類完成的?！皹?gòu)建經(jīng)歷”會在她自己的計算機上生成二進制文件（所以生成的文件在她自己的計算機上總能正常運行）！將軟件部署到它要運行的環(huán)境中是一個脆弱的拜占庭式過程，因為需要共享驅(qū)動器、FTP 和進行手動文件復制粘貼

7、。整合開發(fā)團隊的工作是一場悲慘的死亡游行，一次又一次的回退就像玩打地鼠游戲一樣。是否可以投入生產(chǎn)？誰知道呢？軟件正在迅速建立起對世界的興趣，但開發(fā)、部署和運營基于軟件的系統(tǒng)的過程卻停留在圖靈和Hopper時代。2008 年左右發(fā)生了一場革命，這場革命被稱為 DevOps。從那時起到現(xiàn)在，這些年我們已經(jīng)看到一場運動的興起。DevOps 非常重要，它包含并可能取代之前出現(xiàn)的敏捷運動。我在 2014 年開始接觸 DevOps，當時我在一次大會上拿到了鳳凰項目這本書。當我開始如饑似渴地閱讀那本書時，我的會議計劃被我拋到腦后。這本書講的東西太多了。如果你正處在 IT 行業(yè)，即使是很短的時間，你也一定扮演

8、過那些角色。你可以試著自己代入角色。從那以后，DevOps 成了我職業(yè)生涯的焦點。DevOps 通常被認為有三個主要的“支柱”：文化、流程和技術(shù)。本文是關(guān)于 DevOps 的技術(shù)部分。具體地說，是關(guān)于.NETCore 為現(xiàn)代 DevOps 實踐帶來的技術(shù)。.NET Core 是在 DevOps 興起期間構(gòu)思出來的。微軟顯然有明確的目標，就是讓.NETCore 成為 DevOps 時代的平臺。本文將介紹.NETCore 和 DevOps 的三個主要主題：.NET Core 框架和 SDK；構(gòu)建自動化；應用程序監(jiān)控。.NET Core 框架和 SDKDevOps 并不是孤立存在的。用于生成和交付基

9、于軟件的系統(tǒng)的技術(shù)可能可以支持或者阻礙 DevOps 實踐。無論你的技術(shù)棧是怎樣的，DevOps 都是值得一試的。話雖如此，你選擇的技術(shù)棧將對你的 DevOps 實踐產(chǎn)生重大影響。閉源、專有構(gòu)建系統(tǒng)對 DevOps 來說并不友好。.NET Core 是完全開源的，用于表示項目和解決方案的文件格式也有完整的文檔化?，F(xiàn)代語言和框架（如 Node/JavaScript、Ruby 和 Python）已經(jīng)具有一些常見特性：緊湊的開源框架；命令行界面（CLI）；記錄良好的開放式構(gòu)建系統(tǒng)；支持所有主要操作系統(tǒng)。這些特性和其他更多功能在 DevOps 時代變得越來越流行，因為它們具有很強的適用性和自動化能力。

10、.NETCore 的 CLI 命令 dotnet 是.NETCore 應用程序構(gòu)建過程的單一入口點。無論是什么平臺，開發(fā)人員都可以在工作站上使用 dotnet，用于構(gòu)建代理。也就是說：我將在后續(xù)展示的所有本地開發(fā)工作都可以在 MacBook Pro 上進行。試著想象一下，這在三年前是不可能的事情！使用.NETCore 的第一步是下載它。你可以在這里下載 SDK。在我的 MBP 上有 171MB。安裝完畢后，打開你最喜歡的終端窗口（在 Windows 上我偏愛 Powershell，但在 Mac 上我使用 iTerm2）。如果你已經(jīng)很熟悉.NET 開發(fā)，那么可能已經(jīng)習慣了安裝大型框架。你習慣使用

11、 Visual Studio 來完成開發(fā)工作。如果你是.NETCore 新手，可能會覺得有點奇怪。在使用 IDE 之前，我們可以使用這 171 兆字節(jié)的東西完成很多事情。執(zhí)行：dotnet這是一個新的 CLI 命令，用于與.NETCore SDK 發(fā)生交互。讓我們來看一下。執(zhí)行：dotnet help這將列出 CLI 支持的所有命令，這個清單并不長，也沒必要很長。你可能在查找哪些是與.NETCore 框架構(gòu)建過程進行交互所需的，從一個新項目到已部署的應用程序。第一步是創(chuàng)建一個新的應用程序。讓我們來看看我們的選項。執(zhí)行：dotnet new輸出的信息將列出可用的模板。在 Visual Studi

12、o 中你可以單擊 File-New Project 來創(chuàng)建項目，但在這里我們使用命令行。我們有很多模板可選擇。我偏愛 Angular，所以讓我們從那里開始吧。執(zhí)行：dotnet new angular -o dotnet-angular這將在新目錄 dotnet-angular 中創(chuàng)建一個新的 Angular 項目。如果你愿意，可以手動創(chuàng)建目錄，只是在執(zhí)行 dotnet new 之前不要忘記更改目錄，否則將在當前目錄中創(chuàng)建項目。如果你已經(jīng)做過 Angular 開發(fā)，那么可能已經(jīng)安裝了 Node。如果沒有，請花點時間下載并安裝它。如果確實需要安裝 Node，請在安裝后關(guān)閉并重新打開終端。執(zhí)行：d

13、otnet run這個命令將編譯并運行應用程序（也可以通過執(zhí)行 dotnet build 直接完成編譯，而無需運行應用程序來）。這可能需要一兩分鐘時間，然后你將得到一些包含 URL 的輸出：Content root path: /Users/dswersky/dotnet-angular Now listening on: https:/localhost:5001將 URL 復制到 Web 瀏覽器中，然后等一會兒。你現(xiàn)在應該能看到一個在后臺運行 ASP.NETCore、在前端運行 Angular 的簡單應用程序。那么，這種體驗與昔日的.NET 開發(fā)體驗有何不同？你在幾分鐘內(nèi)就創(chuàng)建并運行了一個

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

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

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

17、 的 HTTPS 服務(wù)器上沒有外部依賴性。這與 DevOps 有什么關(guān)系自動化是 DevOps 的核心原則和實踐。.NET Core 提供的可移植性、CLI 和開源構(gòu)建系統(tǒng)對于 DevOps 實踐來說至關(guān)重要。最重要的是，它們可以輕松實現(xiàn)構(gòu)建和部署過程的自動化?？梢酝ㄟ^編寫 CLI 腳本來實現(xiàn)自動化，也可以通過編程方式直接自動化構(gòu)建系統(tǒng)。.NET Core 的這些功能使其不僅可以實現(xiàn)自動化，而且可以相對輕松地自動執(zhí)行復雜的構(gòu)建過程。我們因此能夠建立自動化和持續(xù)集成。.NET Core 構(gòu)建自動化回到 Visual SourceSafe 時代，團隊提交到存儲庫的代碼就在那里，隨時準備好進行編譯。

18、我的腦海里浮現(xiàn)出一個想法“為什么我要在我的系統(tǒng)上構(gòu)建部署，因為構(gòu)建原本可以在存儲庫中進行？”我不是唯一一個有這種想法的人，但卻沒有對此采取什么行動。真正采取行動的是那些開始著手開發(fā)持續(xù)集成（CI）系統(tǒng)的勇士們。CI 的目標說起來很簡單，但實現(xiàn)起來并不那么容易：始終有一個可部署的構(gòu)建。軟件開發(fā)是一項團隊運動。Agile/Scrum 團隊平均有三到五名全職開發(fā)人員負責貢獻代碼。為了提升效率，他們之間進行了分工。然后他們開發(fā)的代碼必須作為一個整體進行組合、構(gòu)建和測試，而且必須使用未安裝開發(fā)人員工具的系統(tǒng)進行自動化測試。理想情況下，在每次將新代碼合并到指定分支時都應該進行構(gòu)建和測試。CI 系統(tǒng)通常直接

19、與源碼控制系統(tǒng)集成，每次分支發(fā)生變更時觸發(fā)新構(gòu)建。Roslyn是一款開源的.NET 編譯器，提供了大量可直接訪問的 API。CI 系統(tǒng)開發(fā)人員使用這些編譯器 API 來構(gòu)建插件，從而自動化.NET 構(gòu)建過程。.NET Core 構(gòu)建工具提供了對構(gòu)建過程的細粒度控制。開發(fā)人員可以使用它們來調(diào)整和擴展現(xiàn)有的 CI 系統(tǒng)功能，以涵蓋幾乎任何可以想象的構(gòu)建管道用例。你可以不是 CI 系統(tǒng)開發(fā)人員，但你可以構(gòu)建插件。CI 系統(tǒng)的維護者和供應商竭盡全力使他們的系統(tǒng)易于擴展?，F(xiàn)在有很多 CI 系統(tǒng)。以下是一個簡短的示例列表：Jenkins；TFS/Visual Studio Team Services；Ci

20、rcleCI；TeamCity；GitLab。.NET Core 提供的靈活性讓它可以與任何 CI 系統(tǒng)集成，這就像使用 CLI 腳本或者使用編譯器 API 開發(fā)的插件直接自動化構(gòu)建一樣簡單。如果你目前擁有自己喜歡的 CI 系統(tǒng)，可以嘗試一下我的示例項目。這與我們之前使用 CLI 創(chuàng)建的項目是一樣的，只是多了一點東西。存儲庫包含了一個 Dockerfile，我花了大約十分鐘來創(chuàng)建一個 VSTS 構(gòu)建管道、從 Github 中拉取代碼、構(gòu)建鏡像，然后將其推送到 Azure 容器注冊表。這與 AWS 或 Google Cloud 中的 Jenkinsfile 或 GitLab 管道一樣好用。正如他

21、們所說，一切皆有可能。使用.NETCore 進行應用程序監(jiān)控軟件系統(tǒng)的運維是一項全職工作，可以讓 Ops 團隊的同事來負責。這些系統(tǒng)就像嬰兒一樣它們不斷地叫啼，需要獲得父母的關(guān)注。Ops 工作人員通常就像陷入困惑的父母一樣，不知道為什么系統(tǒng)會發(fā)生這樣那樣的問題。系統(tǒng)如何引起人們注意？這取決于你是如何照看它們的！最糟糕的系統(tǒng)監(jiān)控方式就是不進行監(jiān)控。無論你是否或者以某種方式進行監(jiān)控，在它們出現(xiàn)故障時都會被注意到。當你的客戶瘋狂地打進客服電話或者完全棄用你的服務(wù)時，你會發(fā)現(xiàn)已經(jīng)太晚了。應用程序監(jiān)控的目標是搶在客戶或最終用戶之前檢測出問題。很多公司做出錯誤的經(jīng)濟判斷，他們認為應用程序監(jiān)控過于昂貴，或者

22、認為“好的系統(tǒng)不需要監(jiān)控”。即使是最穩(wěn)定的系統(tǒng)離災難性事故也只有一步之遙。DevOps 實踐嘗試在安全性和速度之間做出平衡同時讓公司可以通過快速移動進行創(chuàng)新。我們通過密切關(guān)注系統(tǒng)的運行參數(shù)來維持這種平衡。.NET Core 的設(shè)計和架構(gòu)非常適用進行應用程序監(jiān)控。ASP.NETCore 是一個很好的例子。我們可以使用 HTTP 模塊自定義在 IIS 上運行的 ASP.NET3.x/4.x 應用程序的內(nèi)部請求和響應行為。ASP.NETCore 使用中間件改進了這種模型，中間件概念類似于 HTTP 模塊，但在實現(xiàn)方面卻非常不一樣。中間件類通過代碼進行集成，并且配置起來要簡單得多。它們形成了一個請求 / 響應管道鏈。將中間件注入 ASP.NETCore 應用程序是非常容易的。我將演示一個 Azure Application Insights 示例。我在 Azure Portal 中創(chuàng)建了一個 Application Insights 資源，然后在我的存儲庫中編