到底應該選擇那種Linux.NET的部署方式?

    當前部署Linux.NET環境的方式可謂是五花八門,既有傳統的源碼編譯的方式、又有各式各樣的一鍵安裝腳本、還有綠色包安裝方式,而隨着Mono官方的新站上線,更增長了採用RPM包的部署方式。那對於一名Linux.NET的初學者來講,咱們又該如何選擇?下面,本文將對這幾種的安裝方式進行優缺點的比較,從而協助各位讀者選擇出最佳的部署方式。網絡

    本文中,咱們將對下列的部署方式展開討論:學習

      一、源碼編譯測試

      二、一鍵安裝腳本.net

      三、RPM包命令行

      四、綠色包繼承


1、源碼編譯教程

    經過源代碼編譯安裝部署Linux.NET可謂是最傳統而且最原始可靠的方式,經過獲取源代碼,並在物理機(虛擬機)中進行編譯,編譯器可以有針對性的給機器編譯出最適合改機器運行的二進制執行文件。同時,經過源代碼編譯的方式也是全部部署方式中最穩定靠譜的方式。同時,採用源碼編譯的方式部署也是最靈活的。要想深刻學習的讀者必需要掌握此方式部署。部署

    想要經過源碼編譯的方式安裝部署Linux.NET,咱們須要事先Get到一份源代碼,目前得到Mono源代碼的方式主要分爲兩種,一種是經過GitHub將Mono的託管代碼Pull下來執行autogen再執行make install的方式進行編譯安裝部署,另一種則是經過Mono/Source所發行的源碼包(tar.gz或者tar.bz2包)進行./Configuration再執行make install的方式編譯。get

    事實上,若是讀者們採用前者(也就是Git Pull的方式)來編譯部署環境,所獲取到的版本通常都會比從Mono/Source中發行的版本高(固然在可以編譯的狀況下),對但願可以儘快使用最高版本或者想嚐鮮的讀者,使用這種方式不失爲一個好選擇。但選擇這個方式也有必定的缺點,那就是咱們在編譯以前須要先進行Git Clone或者Git Pull代碼,這將使咱們可能面臨上G的Git代碼倉庫須要下載,同時因爲Mono中的external目錄下又包含了其餘.NET項目的GIT倉庫,執行autogen時,系統會檢查包括external目錄的代碼是否完整,所以編譯時系統也有可能再次的執行Git Pull拉去相關代碼。另外還有一點,在咱們進行Git Pull Master以後,咱們也未必能夠編譯經過。所幸的是,文章發佈以後,LexLi給予了一些提醒,經過他的思路,咱們發現了其實GitHub/Mono的Readmd中是有一盞當前代碼是否可以編譯的「提示燈」,經過觀察此「燈」所顯示的顏色咱們就能夠知道當前的代碼是否能夠編譯,另外在這裏也有一個版本編譯測試歷史記錄,咱們也能夠根據它的編譯測試記錄獲知那一個提交版本的的源碼是能夠編譯,而後只需把代碼ReSet到此版本便可再次進行編譯。編譯器

    而採用Mono/Source所發行的源碼包編譯的讀者,可靠性則大幅度提升,畢竟這個是Release版本。雖然當中有個別的發行包由於文件缺失沒法編譯,可是總得來講仍是最可靠的,而且源碼包發行版大小通常都在百兆之內,相比於Git倉庫的上G代碼可謂是小巧得多。

    最後,各位讀者不管是採用以上兩種方式中的那種,都須要花費一段或漫長或短暫的編譯等待時間,而且編譯時可能會遇到一些Make Error的現象,這都須要各位讀者本身進行克服處理。但不管怎麼樣,這仍是對想深刻學習Linux.NET的讀者要求必須掌握的部署方式。(有須要的讀者能夠參詳《Linux.NET學習手記》)

 

2、一鍵安裝腳本

    因爲採用源碼編譯方式都是直接採用Shell命令來操做,所以有很多的人士將這些Shell命令提取出來從新組裝成一個Shell腳本,只要執行該腳本便可完成環境的部署,其中更有愛好者別出心裁,在命令行的基礎上加以改進,提供相似「界面」之流的方式,給予了較好的與用戶的交互。採用腳本式部署環境是解放生產力的標誌。

    但即使如此,採用腳本安裝的方式仍然存在着至關的不足,那即是採用腳本安裝其實只是一個「禮盒」,「禮盒」裏面的內容依然是源代碼編譯方式,所以,採用腳本安裝所遇到的問題不會比採用源碼安裝的少。同時,採用腳本安裝仍然存在這「兼容性」的問題,這裏值得注意,所謂的「兼容性」並非指腳本的命令行不通用,而是由源碼編譯所「繼承」下來的「不兼容」,也就是環境的複雜性形成不一樣的Make Error所帶來的「不兼容」。此外,因爲每一個人都有本身的安裝風格,有的人可能喜歡將東西安裝在「/usr」中(像宇內、善友的教程等),有人喜歡安裝到「/usr/local/」中(個人風格,《Linux.NET學習手記》的教程路徑),也有人喜歡安裝到「/opt」中……總而言之,腳本中所編寫的安裝路徑純屬由撰寫者決定,安裝目錄可能並非各位讀者所但願的路徑,這點也有必定的不足。

 

3、RPM包

    伴隨着Mono新版官網的上線,依賴於Yum的RPM安裝方式也悄悄的出如今各位讀者的視野,一段時間以來,很多朋友開始或是爲了嚐鮮(沒辦法,體驗到Yum的甜頭以後恐怕很難回頭了)或是收到「官方」的指引紛紛採用了此種辦法部署Linux.NET環境。

    我沒有嘗試過這種方式(懶得本身添加鏡像源),不過從很多朋友反(bao)饋(yuan)回(ma)來(niang)的信息來看,這種方式彷佛是幾種方法中最殘(zi)念(sha)的了。因爲RPM包隸屬於二進制包的一種,安裝路徑已經在包中預配置,沒法更改,咱們也沒法獲知它到底安裝到哪裏(只能find了),從一些經過此方式安裝的朋友所提供的資料來看,基本上會安裝到「/opt」目錄中(不過沒有具體目錄,有「/opt/」、「/opt/mono」甚至「/opt/201408xx/」目錄)。此外,採用RPM包方式安裝還有一項很是嚴重的問題,那就是採用此種方式安裝居然沒有向環境變量註冊Mono/bin路徑,致使系統沒法找到mono。

    所以,我我的尤爲不推薦此中安裝方式。

 

4、綠色包(jws.mono)

    以上三種方式都有一個共同的特色,那就是都須要在有網絡條件的狀況下進行。而綠色包與前者不一樣,綠色包是從使用源碼編譯好的機器中進行抽取重組並進行適當的修改變成新的解壓便可運行的綠色版的Linux.NET運行環境。

    使用綠色包具備如下的幾項優勢:

      (1)、快速部署,因爲採用此方式部署僅僅須要執行一條解壓命令(有須要的可自行註冊環境變量),沒有編譯過程,大大節省了由於環境部署所須要消耗的寶貴時間。

      (2)、針對性強:因爲每一款的綠色包都是針對其標註的Linux發行版進行編譯,所以綠色包具備比較強的發行版針對性。

      (3)、精緻而不失功能:使用過綠色包的讀者可能會發現,它的打包文件大小甚至會比Mono/Source所發行的源碼包還會小,但功能卻又沒有減小。這個祕密就在於Mono與MS.NET不一樣,Mono的庫是向下兼容的,所以,在每款的綠色包中,咱們都會對「重複」的庫進行剔除,讓包變得足夠精緻。

    但金無足赤,綠色包一樣也面臨一些問題,第一就是它沒法升級(這項即將獲得改善,在下個發行包中提供可用於升級的腳本),第二就是製做發行包是一項工做量大且耗時的活。咱們須要對應編譯並製做相應發行版的包。

    不過對於初學者和須要快速部署、大規模部署的讀者來講,綠色包仍是最佳選擇,由於它足夠容易,由於它足夠快。


    固然了,仁者見仁智者見智,以上觀點乃我利用Linux.NET編譯的時間寫出的(已經失敗了差很少十次)的主觀觀點和建議,不喜勿彈哈,謝謝。

    原文首發連接:http://jhonge.net/Home/Single/3788111

相關文章
相關標籤/搜索