建站
咨詢
售后
建站咨詢
新聞中心
隨著計算機技術的不斷發(fā)展，應用程序的開發(fā)也愈發(fā)復雜和多樣化。許多開發(fā)者面對不同的操作系統(tǒng)、開發(fā)語言和框架，紛繁復雜的環(huán)境已經(jīng)成為開發(fā)者必須面對的問題?？缙脚_開發(fā)便是應運而生，其可以大大降低開發(fā)成本和時間，同時增加軟件的靈活性和可移植性。.NET Core是開發(fā)跨平臺應用程序的首選，其中特別是.NET Core在Linux環(huán)境下的應用更為廣泛。
創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供陽城網(wǎng)站建設、陽城做網(wǎng)站、陽城網(wǎng)站設計、陽城網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、陽城企業(yè)網(wǎng)站模板建站服務，10年陽城做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。
.NET Core，是一個免費、開源、跨平臺的框架，它可以用來構建不同類型應用，如Web應用、桌面應用、云應用等，并且支持不同類型的操作系統(tǒng)，例如Windows、Linux和macOS等。.NET Core是在一系列互聯(lián)網(wǎng)領先公司的支持下開發(fā)出來的，諸如微軟、谷歌和Facebook等，這讓.NET Core擁有許多偉大的功能和特性，還可以通過社區(qū)持續(xù)優(yōu)化成長，這給所有的開發(fā)者提供了更豐富的選擇。
在跨平臺開發(fā)中，Linux是優(yōu)秀的選擇之一，因為它具有高效、穩(wěn)定、安全和靈活的特性。Linux上的.NET Core可以滿足開發(fā)者的絕大部分需求，可以快速地構建出高性能、安全和可擴展的應用程序。此外，Linux還具有較高的自由性、開發(fā)標準、文檔和強大的社區(qū)支持，這讓開發(fā)者可以更加深入的探究.NET Core的開發(fā)和應用。
使用.NET Core開發(fā)應用程序要比傳統(tǒng)的.NET Framework更加優(yōu)秀，強大和靈活。.NET Core可以使用微軟提供的Visual Studio進行開發(fā)，還支持使用其他的代碼編輯器和開發(fā)工具，例如Visual Studio Code、 Sublime、IntelliJ等等。同時，.NET Core可以使用C#、F#等各種編程語言構建應用，這給開發(fā)者提供了更多的選擇，還可以大大簡化軟件開發(fā)流程。
.NET Core還擁有以下優(yōu)秀特性：
– 跨平臺應用程序開發(fā)
– 云端應用程序開發(fā)和實施
– 面向現(xiàn)代應用程序的微服務和容器化
– 對 WebAssembly 和拆分 ngen 支持
.NET Core Linux是現(xiàn)代應用程序開發(fā)的首選框架之一。Linux的開源和透明讓.NET Core更適用于靈活、跨平臺、高效和可拓展的開發(fā)需要。未來，.NET Core將繼續(xù)保持開源、跨平臺、安全漏洞補丁及時更新，成為開發(fā)者的首選框架之一。
相關問題拓展閱讀：
- 一文回顧.NET Core 基礎設施演進之路
- 如何系統(tǒng)地學習Docker？
一文回顧.NET Core 基礎設施演進之路
作者丨Matt Mitchell
譯者丨平川
隨著.NET Core 3.0 預覽版 6 的推出，我們認為有必要簡要回顧一下基礎設施系統(tǒng)的 歷史 ，以及在過去一年左右時間里所做的重大改進。如果你對構建基礎設施感興趣，或者希望了解如何構建像.NET Core 這樣大的產(chǎn)品，那么這篇文章將非常有趣。
從 3 年前開始，.NET Core 項目就與傳統(tǒng)的微軟項目有很大的不同。
我們早期的基礎設施決策是圍繞必要性和便利性做出的。我們使用 Jenkins 進行 GitHub PR 和 CI 驗證，因為它支持跨平臺的 OSS 開發(fā)。我們的官方構建版本位于 Azure DevOps（當時稱為 VSTS）和 TeamCity（由 ASP 使用）中，其中有簽名和其他關鍵的交付基礎設施。我們搭配使用手動更新包依賴項版本和自動化 GitHub PR 的方法將存儲庫集成在一起。團隊獨立地構建了他們需要的工具來進行打包、布局、本地化，以及在大型開發(fā)項目中出現(xiàn)的所有其他常見任務。雖然不是很理想，但在某種程度上，這在早期已經(jīng)運行得足夠好了。隨著項目從.NET Core 1.0 和 1.1 發(fā)展到 2.0 以及更高版本，我們希望投資于進一步整合的技術棧、更快的交付周期和更簡單的服務。我們希望每天多次使用最新的運行時來生成一個新的 SDK。我們希望所有這些都不降低獨立存儲庫的開發(fā)速度。
.NET Core 面臨的許多基礎設施方面的挑戰(zhàn)都源于存儲庫結構的隔離和分布式特性。盡管多年來它變化很大，但該產(chǎn)品是由 20 到 30 個獨立的 Git 存儲庫組成（ASP.NET Core 直到最近還比它多得多）。一方面，擁有許多獨立的開發(fā)豎井會使這些豎井中的開發(fā)非常高效；開發(fā)人員可以在庫中快速迭代，而不用擔心棧的其他部分。另一方面，它使得整個項目的創(chuàng)新和集成效率大大降低。下面是一些例子：
在所有這些情況下，都有可能在許多層面上出現(xiàn)失敗，從而進一步減緩進程。隨著.NET Core 3.0 計劃的正式啟動，很明顯，如果不對基礎設施進行重大更改，我們就無法創(chuàng)建所需范圍的版本。
為了減輕痛苦，我們?nèi)荦R下：
Arcade
在.NET Core 3.0 之前，有 3 到 5 種不同的工具實現(xiàn)分散在不同的存儲庫中，這和你如何計算有關。
雖然在這個世界上，每個團隊都可以定制他們的工具，只構建他們需要的東西，但這確實有一些顯著的缺點：
開發(fā)人員在存儲庫之間切換時效率更低
例如：當開發(fā)人員從 dotnet/corefx 切換到 dotnet/core-sdk 時，存儲庫的“語言”是不同的。她輸入什么來構建和測試？日志放在哪里？如果她需要在存儲庫中添加一個新項目，該如何做？
需要的每個特性都要構建 N 次
例如：.NET Core 生成了大量的 NuGet 包。雖然有一些變化（例如，共享運行時包如出自 dotnet/core-setup 的 Microsoft.NETCore.App 就與 Microsoft.AspNet.WebApi.Client 等“普通”包的構建方式不同），但生成它們的步驟非常相似。遺憾的是，由于存儲庫在布局、項目結構等方面的差異，如何實現(xiàn)這些打包任務方面也產(chǎn)生了差異。存儲庫如何定義應該生成什么包、這些包中包含什么、它們的元數(shù)據(jù)等等。如果沒有共享工具，團隊通常更容易實現(xiàn)另一個打包任務，而不是重用另一個。這當然會導致資源壓力。
借助 Arcade，我們努力使所有的存儲庫采用公共的布局、存儲庫“語言”和任務集（可能的話）。這并非沒有陷阱。任何一種共享工具最終都會解決一些“剛剛好”問題。如果共享工具過于規(guī)范，那么在任何規(guī)模的項目中進行所需的定制都將變得非常困難，并且更新該工具也將變得非常困難。使用新的更新很容易破壞存儲庫。構建工具遭受了這種痛苦。使用它的存儲庫與它緊密耦合，以至于它不僅不能用于其他存儲庫，而且對構建工具進行任何更改常常會以意想不到的方式傷害用戶。如果共享工具不夠規(guī)范，那么存儲庫在使用工具時往往會出現(xiàn)差異，并且推出更新通常需要在每個單獨的存儲庫中做大量的工作。那么，為什么要共享工具呢?
實際上，Arcade 嘗試同時使用了這兩種方法。它將公共存儲庫“語言”定義為腳本集（請參閱 eng/common）、公共存儲庫布局和作為 MSBuild SDK 推出的公共構建目標集。選擇完全采用 Arcade 的存儲庫具有可預測的行為，使得更改很容易在存儲庫之間傳播。不希望這樣做的存儲庫可以從提供基本功能（如簽名和打包）的各種 MSBuild 任務包中進行選擇，這些任務包在所有存儲庫中看起來都是一樣的。當我們對這些任務進行更改時，我們會盡力避免破壞性更改。
讓我們來看看 Arcade 提供的主要特性，以及它們?nèi)绾渭傻轿覀兏蟮幕A設施中。
Azure DevOps
如上所述，較大的團隊通過 2.2 版本使用了一個 CI 系統(tǒng)的組合：
許多差異僅僅是出于必要性。Azure DevOps 不支持公共 GitHub PR/CI 驗證，所以 ASP.NET Core 轉(zhuǎn)向 AppVeyor 和 Travis 來填補這個空白，而.NET Core 則投資于 Jenkins。經(jīng)典 Azure DevOps 對構建編排沒有太多的支持，所以 ASP.NET Core 團隊求助于 TeamCity，而.NET Core 團隊則在 Azure DevOps 之上構建了一個名為 PipeBuild 的工具來幫助克服困難。所有這些差異都是非常昂貴的，即使是以一些不明顯的方式：
當 Azure DevOps 開始推出基于 YAML 的構建管道和對公共 GitHub 項目的支持時，隨著.NET Core 3.0 的啟動，我們意識到，我們擁有一個獨特的機會。有了這種新的支持，我們可以將現(xiàn)在所有的工作流從單獨的系統(tǒng)轉(zhuǎn)移到現(xiàn)代的 Azure DevOps 中，并對我們處理正式 CI 和 PR 工作流的方式進行一些更改。我們的工作大致如下：
到目前為止，所有主要的.NET Core 3.0 存儲庫都在 Azure DevOps 上進行公共 PR 和正式 CI。一個很好的例子是 dotnet/arcade 本身的正式構建 /PR 管道。
Maestro 和依賴流
.NET Core 3.0 基礎架構的最后一塊拼圖就是我們所說的依賴流。這并不是.NET Core 獨有的概念。除非它們是完全自包含的，否則大多數(shù)軟件項目都包含對其他軟件的某種版本化引用。在.NET Core 中，這些包通常表現(xiàn)為 NuGet 包。當我們需要庫提供的新特性或修復時，我們通過更新項目中引用的版本號來獲取這些新更新。當然，這些包也可能有對其他包的版本化引用，那些其他包可能有更多的引用，等等。這就形成了一張圖。當每個存儲庫拉取其輸入依賴項的新版本時，更改將在圖中流動。
一個復雜的圖
大多數(shù)軟件項目的主要開發(fā)生命周期（開發(fā)人員經(jīng)常從事的工作）通常涉及少量相互關聯(lián)的存儲庫。輸入依賴關系通常是穩(wěn)定的，更新很少。當他們確實需要更改的時候，通常是手工操作。開發(fā)人員評估輸入包的可用版本，選擇合適的版本，然后提交更新。但在.NET Core 中并非如此。組件需要獨立，以不同的節(jié)奏交付，并具有高效的內(nèi)循環(huán)開發(fā)體驗，這導致了大量具有大量相互依賴關系的存儲庫。相互依賴關系也形成了一個相當深的圖：
Dotnet/core-sdk 存儲庫作為所有子組件的聚合點。我們提供了一個特定的 dotnet/core-sdk 構建，它描述了所有其他引用的組件。
我們還希望新的輸出能夠快速通過這個圖，以便盡可能多地驗證最終產(chǎn)品。例如，我們期望 ASP.NET Core 或.NET Core 運行時的最新片段盡可能多地在 SDK 中表現(xiàn)自己。本質(zhì)上，這意味著定期快節(jié)奏地更新每個存儲庫中的依賴項。在一個足夠大的圖中，就像.NET Core 一樣，這很快就變成了一個不可能手工完成的任務。這種規(guī)模的軟件項目可能會通過以下幾種方法來解決這個問題：
.NET Core 已經(jīng)嘗試了所有 3 種方法。我們在 1.x 的早期漂移版本。在 2.0 中實現(xiàn)了一定程度的自動化依賴流，并為 2.1 和 2.2 構建了一個復合構建。在 3.0 中，我們決定大量投資于自動化依賴流，放棄其他方法。我們想在一些重要的方面改進我們以前的 2.0 基礎設施：
這些概念的設計使得存儲庫所有者不需要棧或其他團隊流程的全局知識就可以參與依賴流。他們只需要知道三件事：
.NET Core 3 開發(fā)通道的流圖，包括.NET Core 3 Dev 流的其他通道（例如，Arcade 的“.NET Tools Latest”）。
一致和不一致
非一致性會導致哪些問題？
不一致性表示可能的錯誤狀態(tài)。舉個例子，讓我們看看 Microsoft.NETCore.App。這個包表示特定的 API 表面。雖然存儲庫依賴關系圖中可能會引用 Microsoft.NETCore.App 的多個版本，但 SDK 只提供一個。這個運行時必須滿足可在該運行時上執(zhí)行的間接引用組件（例如 WinForms 和 WPF）的所有需求。如果運行時不滿足這些需求（例如破壞性 API 變更），可能就會發(fā)生故障。在不一致的圖中，因為所有存儲庫都沒有使用相同版本的 Microsoft.NETCore.App，有可能錯過了一個破壞性的變更。
這是否意味著不一致始終是一種錯誤狀態(tài)？
不。例如，我們假設圖中 Microsoft.NETCore.App 的不一致只代表一個非破壞性 JIT Bug 修復 coreclr 中的一個變更。從技術上講，微軟沒有必要在圖中的每一點上獲取新的 Microsoft.NETCore.App。只需針對新的運行時交付相同的組件就足夠了。
如果不一致只是偶爾的問題，那么我們?yōu)槭裁催€要努力才能推出一致的產(chǎn)品呢？
因為很難確定什么時候不一致無關緊要。簡單地將一致性作為所需狀態(tài)進行交付，要比試圖理解不一致的組件之間的任何語義差異對最終產(chǎn)品所產(chǎn)生的影響更容易。這是可以做到的，但是從構建頻率來說，它是時間密集型的，并且容易出錯。強制將一致性作為默認狀態(tài)更安全。
依賴流的好處
隨著存儲庫圖越來越大，所有這些自動化和跟蹤都有許多明顯的優(yōu)勢。它為我們解決日常生活中的實際問題提供了很多可能性。雖然我們剛剛開始 探索 這個領域，但系統(tǒng)已經(jīng)可以開始回答一些有趣的問題，并處理以下場景：
隨著.NET Core 3.0 逐步結束，我們正在尋找新的領域來改進。雖然計劃仍處于（非常）初期的階段，但我們預計在以下幾個關鍵領域進行投資：
多年來，我們已經(jīng)對基礎設施進行了相當大的改進。從 Jenkins 到 Azure DevOps，從手工依賴流到 Maestro++，從許多工具實現(xiàn)到一個工具實現(xiàn)，我們對.Net Core 3.0 所做的改變是一個巨大的進步。我們已經(jīng)為開發(fā)和交付比以往任何時候都更可靠、更令人興奮的產(chǎn)品做好了準備。
原文鏈接：
如何系統(tǒng)地學習Docker？
1Docker 技術可謂是近年最火熱的技術之一，鋪天蓋地的技術論壇和各種講座，大家都在分享關于如何容器化及如何使用Docker優(yōu)化自己運維和開發(fā)流程的經(jīng)驗。隨著Docker技術的逐漸普及，使用Docker已經(jīng)不再是一個難題?，F(xiàn)在更加重要的是生產(chǎn)環(huán)境容器化的更佳實踐，段姿另外就是容器的編排框架之爭。但是，對于技術人員來說，除去Docker 外表的繁華外，什么是容器，容器到底是怎么創(chuàng)建的，容器底層的技術探秘也是非常重要的。2023年開始接觸 Docker的時候，經(jīng)歷了從最初的新奇—感嘆竟然還有Docker 這樣的好工具，到逐漸熟悉Docker的各種功能，嘗試在生產(chǎn)環(huán)境中使用Docker技術的過程。但是，每每被人問到：“Docker技術到底是怎么實現(xiàn)的呢”我只能粗粗淺淺地說：“Docker是使用Linux Kernel的Namespace 和 Cgroups實現(xiàn)的一種容器技術。”那么，什么是Namespace，什么是Cgroups，Docker是怎么使用它們的，容器到底是怎么一步步被創(chuàng)建出來的.問到這些，我就會支支吾吾地不知所以。螞橡由此可見，了解容器技術的底層技術，然后明白它們是如何工作的，尤為重要，這些才是整個容器技術的基石，掌握了這些基石才能更加容易地向上攀登。
2從docker的用途上來考慮，看docker能否解決你工作中遇到的問題。例如在實際開發(fā)過程中，經(jīng)常遇到的持續(xù)集成問題，軟件開發(fā)，測試，部署，如何做成自動化的。配合github Jenkins和docker實現(xiàn)自動化部署，系統(tǒng)持續(xù)集成。docker最重要的是編排，如何合理有效穩(wěn)定的管理各個容器，調(diào)度容器?？梢钥纯磌8s，自己動手搭建握物絕跑跑看。docker本身并沒有引入新的技術，都是在linux原有的基礎上做的融合?？梢躁P注docker源碼分析。UCloud也支持Docker，推出了UDocker產(chǎn)品。UCloud – 專業(yè)云計算服務商。
目前，騰訊云平臺支持 Docker ，以下是在騰訊云生產(chǎn)環(huán)境中體驗、使用Docker的教程，可以讓你更好地理解Docker的不同使用場景。在騰訊云服務器上體驗Docker利用 Docker 快速搭建 git 倉庫 Gitlab 與代碼審閱 Gerrit 平臺在 CVM 上使用騰訊云 Docker 鏡像加速構建Docker 部署dotnetcore此外，騰訊云還推出了容器服務CCS，可以在托管的云服務器實例集群上輕松運行應用程序。皮坦高使用該服務，您將無需安裝、運維、擴展您燃尺的集群管理基礎設施，只需進行簡單的信圓API調(diào)用，便可啟動和停止Docker應用程序，查詢集群的完整狀態(tài)，以及使用各種云服務。
關于dotnet core linux的介紹到此就結束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關注本站。
創(chuàng)新互聯(lián)成都網(wǎng)站建設公司提供專業(yè)的建站服務，為您量身定制，歡迎來電（028-86922220）為您打造專屬于企業(yè)本身的網(wǎng)絡品牌形象。
成都創(chuàng)新互聯(lián)品牌官網(wǎng)提供專業(yè)的網(wǎng)站建設、設計、制作等服務，是一家以網(wǎng)站建設為主要業(yè)務的公司，在網(wǎng)站建設、設計和制作領域具有豐富的經(jīng)驗。
新聞名稱：跨平臺編程首選——.NETCoreLinux(dotnetcorelinux)
鏈接分享：http://m.fisionsoft.com.cn/article/ccdjjgc.html
