【正文】 ................................... 錯誤 !未定義書簽。 與 MapReduce 有關(guān)的地址及端口屬性 .............................. 錯誤 !未定義書簽。 8 附錄 ............................................................................................. 錯誤 !未定義書簽。 hadoop歷史 ............................................................................ 錯誤 !未定義書簽。 Hadoop大記事 ........................................................................ 錯誤 !未定義書簽。 Hadoop的幾個主要子項(xiàng)目 ...................................................... 錯誤 !未定義書簽。 官方集群搭建參考 .................................................................. 錯誤 !未定義書簽。 配置文件 ........................................................................... 錯誤 !未定義書簽。 集群配置說明 .................................................................... 錯誤 !未定義書簽。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 前言 身在 IT圈的你，可能已經(jīng)注意到了最近圈子 里的熱門詞語緊緊圍繞著以下幾個領(lǐng)域－云計(jì)算， nosql以及 DevOps, 與 Web2或者社會化網(wǎng)絡(luò)不同，上述三者并不是在網(wǎng)絡(luò)上產(chǎn)生內(nèi)容或者消費(fèi)內(nèi)容的模型，事實(shí)上，它們是關(guān)于 構(gòu)建和運(yùn)營軟件系統(tǒng) 的模型。 “生產(chǎn) ”與 “產(chǎn)品 ”便是上述三者之于 Web 2的不同。 經(jīng)過幾年的醞釀， 敏捷 和 運(yùn)維 這兩個領(lǐng)域終于各自受到了足夠的重視，并順理成章地有了交集。從 2020年起，一陣被稱為 ”DevOps”的風(fēng)潮從歐洲發(fā)端，迅速席卷了北美和澳洲 ──現(xiàn)在以 Flickr、 Twitter為代表的一干互聯(lián)網(wǎng)公司競相以快速發(fā)布、頻繁發(fā)布為榮：這廂 Flickr做個 PPT叫 ”每天 10次部署 ”，那邊 Twitter就在演講里有意無意地說 ”每天部署幾十次 ”。一說起做互聯(lián)網(wǎng)，你要是還在走倆月一個版本的發(fā)布周期呀，你都不好意思跟人打招呼 ──等你做出新版本，用戶都跑競爭對手那兒去啦。 顧名思義， ”DevOps”就是開發(fā)和運(yùn)維要搞到一塊去 ──每天部署十幾次，這兩組人是得搞到一塊去，不然光是填流程單的時間都不夠。凡是參與過流程改進(jìn)的人都知道， ”搞到一塊去 ”這事永遠(yuǎn)都是說起來容易做起來難。開發(fā)和運(yùn)維，工作的環(huán)境不同，溝通的方式不同，使用的工具不同，通常還隸屬不同部門，沒有 點(diǎn)方法套路，說一句 ”你們要緊密協(xié)作 ”半點(diǎn)用都頂不上。不過，辦法總比困難多：流程、技術(shù)、工具三管齊下，一點(diǎn)點(diǎn)改進(jìn)現(xiàn)狀，最終達(dá)到交付與運(yùn)維緊密無間的企業(yè)文化，至少已經(jīng)有先例告訴我們是可行的。 IT技術(shù)的潮流，向來是澳洲比英美慢兩三年，中國又比澳洲慢兩三年。于是很自然地，當(dāng)別人開始熱火朝天地講 DevOps，咱們這兒 ”敏捷運(yùn)維 ”還是幾家互聯(lián)網(wǎng)巨頭的王謝堂前燕。不過正因?yàn)檫@個潮流時差，也不難預(yù)測，兩三年后 ”敏捷運(yùn)維 ”一定會像今天的 ”敏捷 ”一樣飛入百姓家。所以呢，咱們得從現(xiàn)在開始早做準(zhǔn)備 ──比如看看本期《架構(gòu)師》精選的 幾篇文章，先大概了解一下這 ”敏捷運(yùn)維 ”講的到底是個啥，然后開始做一點(diǎn)思考和分享。等更多企業(yè)開始意識到敏捷運(yùn)維的重要性，咱不就已經(jīng)成竹在胸了么。 需要頻繁交付的企業(yè)可能更需要 DevOps。 Flickr發(fā)展了自己的 DevOps能力，使之能夠支撐業(yè)務(wù)部門 “每天部署 10次 ”的要求 ──如果一個組織要生產(chǎn)面向多種用戶、具備多樣功能的應(yīng)用程序，其部署周期必然會很短。 DevOps的冉冉升起主要是由于商業(yè)應(yīng)用以及運(yùn)營之間的巨大鴻溝，大程度上歸也很因于 IaaS云計(jì)算 的快速增長，在這樣的環(huán)境中，少數(shù)幾個管理員管理著成百上千的主機(jī)，而沒有自動化，這些工作是不可能完成的。未來，我希望 DevOps成為一等公民，并且逐漸在非云計(jì)算的公司普及開。 1 概述 作 什么 事情 之前，第一步是要知道 What（是什么），然后是 Why（為什么），最后才是 How 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 （怎么做）。 從而 避免 將技術(shù) 或方法論 誤用于不適合的場景 ，這一點(diǎn)非常重要 。 一個熟悉的例子：部署軟件產(chǎn)品 下面是一個大家都基本熟悉的例子：部署軟件產(chǎn)品。 【 開發(fā)部門 】 開發(fā)部門要開發(fā) 一款新產(chǎn)品。這款產(chǎn)品要使用最新最炫的技術(shù)，來保證客戶的所有花俏的需求，從而給公司帶來百萬美元的利潤。這款產(chǎn)品被要求使用最新的技術(shù)和運(yùn)行平臺，還得馬上交付。于是開發(fā)部門沒日沒夜的加班、趕代碼 (cuts code like crazy），終于如期完成了任務(wù)。然后他們把自己的 “ 杰作 ” 一股腦的甩給了運(yùn)維部門，后者還沒能完全接手，前者已經(jīng)迫不及待的開始了慶功會。 【 運(yùn)維部門 】 接到產(chǎn)品后，運(yùn)維部門每個人的心中都充滿了恐懼。 下面就是運(yùn)維部門的恐懼之源： 1) 這款優(yōu)秀的產(chǎn)品在目前的底層平臺上無法運(yùn)行，因?yàn)檫@個平臺 {太古老了 ，空間不足，不支持某某版本 } 2) 這款產(chǎn)品的體系結(jié)構(gòu)跟我們的 {存儲，網(wǎng)絡(luò)，部署，安全 }模型不匹配。 3) 這款產(chǎn)品的 { 報告，安全，監(jiān)視，備份，服務(wù)提供 } 我們搞不懂 ，所以沒法把它做成實(shí)際可用的產(chǎn)品。 盡管伴隨著不絕于耳的抱怨和咒罵，運(yùn)維部門最終還是把這款產(chǎn)品安裝好了。不幸的是，由于做了很多蹩腳的修改和不合理的強(qiáng)迫式運(yùn)行，這款產(chǎn)品的性能最后被歸結(jié)為：終極失?。?Epic Fail）。 于是非常沮喪的運(yùn)維部門開始記錄各種問題，源源不斷的給開發(fā)部門提 Issue。而開發(fā)部門的回應(yīng)基本上都是： 1) 這不是我們的錯 —— 我們的代 碼非常完美 —— 而是（運(yùn)維部門的）部署做的太差勁了。 2) 運(yùn)維部門比較笨，他們不懂新技術(shù) —— 為什么他們沒法實(shí)現(xiàn)最新的技術(shù)呢？為什么他們這么落伍呢？ 3) 在我的機(jī)器上運(yùn)行的沒問題啊 ?? 兩個部門之間的交流很快變成了一場暴風(fēng)驟雨?？蛻簦ㄒ约肮蓶|、投資方和管理層）則成了蒙受損失的失敗方。最終公司損失了無數(shù)的金錢，大家也都失業(yè)了。終極的失敗。 DevOps 就是想方設(shè)法的避免這種 “ 終極失敗 ” ，同時讓大家用更聰明更有效的方式去工作。 它是一種框架，包含了很多優(yōu)秀想法和原則，它鼓勵開發(fā)部門和運(yùn)維部門通力合作 。在 DevOps環(huán)境中 ，開發(fā)人員和系統(tǒng)管理員會構(gòu)建一些 關(guān)系 、 流程 和 工具 ，從而更好的與客戶互動，最終提供更好的服務(wù)。 什么是 DevOps？ 望文生義， 從名字上不難想到 DevOps是由 “ Development” 和 “ Operations” 兩個英文 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 單詞合并而成 ， 你也能猜個八九不離十，它就是在說 研發(fā)團(tuán)隊(duì) 與 運(yùn)維團(tuán)隊(duì) 之間的那點(diǎn)事兒。那么，到底什么是 DevOps呢？ WikiPedia上說： DevOps是軟件開發(fā)、運(yùn)維和質(zhì)量保證三個部門之間的溝通、協(xié)作和集成所采用的流程、方法和體系的一個集合。它是人們?yōu)榱思皶r生產(chǎn)軟件產(chǎn)品或服務(wù)，以 滿足某個業(yè)務(wù)目標(biāo)，對開發(fā)與運(yùn)維之間相互依存關(guān)系的一種新的理解。 DevOps并不僅僅關(guān)注軟件部署，它是部門間溝通協(xié)作的一組流程和方法。 可以把 DevOps看作 開發(fā)（軟件工程） 、 技術(shù)運(yùn)營 和 質(zhì)量保障（ QA） 三者的交集。 這恰好體現(xiàn)了精益管理中的客戶價值原則，即：以客戶的觀點(diǎn)來確定企業(yè)從設(shè)計(jì)到生產(chǎn)交付的全部過程，實(shí)現(xiàn)客戶需求的最大滿足。我們也可以把 DevOps看作是一種能力 ，在缺乏這種能力的組織中，開發(fā)與運(yùn)維之間存在著信息 鴻溝 。 與 DevOps 具有相同理念的術(shù)語很多，例如 敏捷運(yùn)維 （ Agile Operations）、 敏捷基礎(chǔ)設(shè)施（ Agile Infrastructure） 和 Dev2Ops。還有很多人雖然沒有提及 “DevOps”，但卻在遵循著類似的理念。 總之， 在思想上 ， DevOps 是敏捷理念向運(yùn)維領(lǐng)域的延伸； 在流程上 ，它是 “需求 ”到 “上線 ”全線貫通的關(guān)鍵； 在工具及技術(shù)準(zhǔn)備上 ，虛擬技術(shù)、云計(jì)算以及各類工具的日趨成熟，為這場變革奠定堅(jiān)實(shí)的基礎(chǔ)。 盡管大家對 DevOps 的看法不盡相同。但只要您把它看作是一種文化的演進(jìn)，讓交付團(tuán)隊(duì)與運(yùn)維團(tuán)隊(duì)互相學(xué)習(xí)，互相幫助，成為真正的跨功能一體化團(tuán)隊(duì)，為客戶提供更好的服務(wù)，最終也就達(dá) 到了它的目標(biāo)。 DevOps不是個技術(shù)問題，而是個業(yè)務(wù)問題 當(dāng)然， DevOps 不乏反對者。反對意見不一而足，有人認(rèn)為 DevOps 是個誤導(dǎo)（ DevOps只是系統(tǒng)管理的一個新名字而已，新瓶裝老酒），有人 對 DevOps 不屑一顧（ DevOps 只是一些瘋狂開發(fā)者的瘋狂想法，他們想擺脫運(yùn)維人員，或者， DevOps 只是一些瘋狂運(yùn)維人員的瘋狂想法，他們想像開發(fā)者一樣工作），甚至有人公開抨擊（可惜的很，他們的言論往往毫無邏輯）。 在過去的九個多月時間里，我在公共論壇和客戶公司內(nèi)部竭力推進(jìn) DevOps 運(yùn)動。正是在那段時 間里，我開始注意到人們對 DevOps 存在一些常見的誤解，我認(rèn)為正是這些誤解使得一些人在初次接觸 DevOps 時產(chǎn)生消極的反應(yīng)。在這里，我將嘗試澄清這些誤解： DevOps 不是個技術(shù)問題。 盡管在解決 DevOps 問題的方案中，技術(shù)是個關(guān)鍵的組成部分，但是， DevOps 它自己本質(zhì)上是個業(yè)務(wù)問題 。 業(yè)務(wù) 流程 與 DevOps的 關(guān) 系 在任何公司里，最根本的業(yè)務(wù)流程都是這樣： 使一個最初的想法經(jīng)過流程最終賺到錢 。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 需要各種各樣的活動組成這個業(yè)務(wù)流程，這其中一些活動是 技術(shù)驅(qū)動 的，其他一些則是人驅(qū)動 的。這里正是 IT 所有不同功能所發(fā)揮作用的地方。開發(fā)者、 QA、架構(gòu)、發(fā)布工程、安全、運(yùn)維，它們都在這一流程中發(fā)揮自己的作用。 但是如果拋開這一業(yè)務(wù)流程的上下文，看看我們還剩下什么？是的，我們有一伙人，還有一些部門，它們各自做著它們自己的分內(nèi)事。但是我們失去了真正做事的動力， 到處是效率低下的工作、浪費(fèi)、沖突和部 門間的孤立 。從表面上看，每個人都在僅僅為自己工作。 如果沒有業(yè)務(wù)流程 這一上下文，還會發(fā)生什么事呢？我們的工作將失去意義并最終消失。實(shí)現(xiàn)業(yè)務(wù)目標(biāo)是我們得到薪水和花時間做事的原因。如果沒有業(yè)務(wù)目標(biāo)或者我們所做的事情根本對實(shí)現(xiàn)業(yè)務(wù)目標(biāo)都沒有助益又會怎樣呢？糟糕， 我們所做的一切都變成了一種愛好 。想想 吧，有誰會傻到給愛好付薪水呢。 DevOps 的立足點(diǎn)正在于對市場壓力做出盡可能快速、高效和可靠的反應(yīng)，從而實(shí)現(xiàn)業(yè)務(wù)目標(biāo)。拋開業(yè)務(wù)，談?wù)?DevOps 問題毫 無意義， 更 別提花時間解決這些問題了。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 DevOps與 敏捷 的關(guān)系 如果 DevOps 和敏捷所要達(dá)到的目標(biāo)聽起來很相似，那是因?yàn)?他們的目標(biāo)就是一 致 的。但是敏捷和 DevOps 是兩個截然不同的事物。 我喜歡將敏捷和 DevOps 描述為兩個相關(guān)聯(lián)的思想，它們都有一個共同的祖先，這個祖先就是 精益 ，但是它們關(guān)注了不同的層面。敏捷深度關(guān)注于改善一個主要的 IT 功能（ 交付軟件 ），同時， DevOps 關(guān)注于對跨 IT 功能的 流程和交互 的改善（它拉伸了整個開發(fā)生命周期的長度，使其包括了運(yùn)維）。 DevOps全部是關(guān)于很酷的工具？ 技術(shù)幾乎能使所有業(yè)務(wù)流程更加高效、可擴(kuò)展和可靠。但是，我們必須記住：工具始終只是工具。如果想在改善業(yè)務(wù)流程上取得理想的效果，那么我們必須明確 為什么要使用該工具以及 如何最有效 的利用該工具。 實(shí)際上，當(dāng)我們明確我們的 DevOps 問題究竟是什么，以及如何改善流程以減少 DevOps問題時，對工具的討論往往變得非常簡單（如果還值得討論的話）。 因?yàn)樾屡d的 DevOps 運(yùn)動主要是技術(shù)人員在推動，所以很容易理解為什么人們很興奮的直接去討論工具。但是，在爭論究竟是 Puppet 好還是 Chef 更好（譯者注： Puppet、 Chef都是開源的系統(tǒng)配置管理工具），應(yīng)該圍繞文件還是圍繞包部署之前，也許我們更應(yīng)該做的是：讓所有人都知道為 什么需要這些工具以及期望中的 業(yè)務(wù)流程改進(jìn)是什么，這才是重點(diǎn)！ 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 既然 DevOps是關(guān)于業(yè)務(wù)流