給系統(tǒng)管理員們的節(jié)日禮物
原創(chuàng)上周五是7月的最后一個星期五，同時也是全世界系統(tǒng)管理員們的節(jié)日——系統(tǒng)管理員日。11年前，美國的IT系統(tǒng)管理員Ted Kekatos發(fā)起了這個節(jié)日，希望能與全世界那些不善言詞，默默付出，卻總是被遺忘在網(wǎng)絡(luò)線堆的技術(shù)好人們共同慶祝，讓人們在這一天想起還有這樣一群默默付出的人。
鑒于系統(tǒng)管理員日的到來，國外的各個服務(wù)器相關(guān)的技術(shù)站點都展開了不同的活動慶祝。本文是Linux.com的Mark Hinkle獻上的禮物，這個禮物是一組叫做“系統(tǒng)管理員工具箱”的系列技術(shù)文章。
另一方面，51CTO操作系統(tǒng)頻道也在一直籌備給系統(tǒng)管理員們的禮物，那就是名叫運維的工作到底啥樣兒的專題。這個專題將澄清有關(guān)系統(tǒng)管理員很閑、系統(tǒng)管理員沒前景等各種傳聞，并向所有讀者們展示系統(tǒng)管理員們真實的生活。系統(tǒng)管理員和運維們也可以通過這個專題，看看國內(nèi)外的同行們都是怎樣工作的。這個專題目前仍在建設(shè)中，如果你有興趣跟51CTO的朋友們分享經(jīng)驗，可以進入這個帖子參與討論；如果您有意參與更多建設(shè)或進行投稿，可以直接與本專題的編輯聯(lián)系：yangsai#51cto.com。
下面請系統(tǒng)管理員們先打開這份由Linux.com制造、51CTO翻譯加工的禮物：《面向Linux系統(tǒng)管理員的開源工具鏈》
【51CTO 8月2日外電頭條】今天的系統(tǒng)管理有兩大明顯趨勢，它們是DevOps和進展稍微遲緩的敏捷運維運動。這些措施流行于許多Web 2.0和云計算公司，比如Twitter、谷歌還有雅虎，當(dāng)然也不乏像Facebook這樣其產(chǎn)品高度依賴IT技術(shù)的公司。但是，實際上這種做法也同樣非常適合傳統(tǒng)企業(yè)中的IT管理員們，這些企業(yè)往往都有大規(guī)模的基礎(chǔ)架構(gòu)和不切實際的工作負荷，需要提高工作效率來達成其業(yè)務(wù)目標(biāo)。
DevOps鼓勵與開發(fā)者們共同進行產(chǎn)品研發(fā)。系統(tǒng)管理員的角色經(jīng)歷了不斷的變化，已經(jīng)從被動執(zhí)行重復(fù)系統(tǒng)建設(shè)任務(wù)的基礎(chǔ)架構(gòu)維護者演變成現(xiàn)在的系統(tǒng)設(shè)計和建設(shè)工程師。在過去，系統(tǒng)管理員可能在一批隨機的腳本中搜集他們的專業(yè)領(lǐng)域知識；但是現(xiàn)在，精明的系統(tǒng)工程師們已經(jīng)開始編寫基礎(chǔ)架構(gòu)，并可以確保對于這些編碼的理解和制度化能夠遍及整個公司。（參考閱讀：系統(tǒng)管理員與開發(fā)者界限日漸模糊）
據(jù)Red Monk的分析師Michael Coté說，“虛擬化和云計算總是在強調(diào)優(yōu)化架構(gòu)，讓IT管理員們的工作更為簡單，為公司節(jié)約開支。在此基礎(chǔ)上，DevOps的理念是運用云技術(shù)來改善應(yīng)用交付的過程，這將為整個應(yīng)用程序注入敏捷軟件開發(fā)和常用功能交付的概念。這一小小的目標(biāo)需要進行可觀的技術(shù)和文化重構(gòu)，但是為了達到提高終端用戶體驗?zāi)康模@絕對值得一試。”
你可以找三個熟知自己行業(yè)條款的從業(yè)者，去問問他們?nèi)绾味x這些條款，得到的三個答案可能會略有不同。DevOps和Agile并不被定義為是一次技術(shù)性改變，而是專業(yè)和文化上的改變。它們重新定義了IT管理員的職能：從系統(tǒng)和IT架構(gòu)維護（傳統(tǒng)系統(tǒng)管理員），向管理和定義可復(fù)制的、有彈性的和高度可用的IT系統(tǒng)轉(zhuǎn)變（系統(tǒng)工程師）。
這一變化勢必會帶來一些戰(zhàn)術(shù)上的改善，用以達成更高的可用性和工作效率。以下做法是敏捷系統(tǒng)工程師們最常使用的辦法。（不了解敏捷的讀者們可以參考51CTO開發(fā)頻道的專題：初探敏捷開發(fā)）
- 基礎(chǔ)架構(gòu)自動化——相比起執(zhí)行重復(fù)任務(wù)而言，管理員們需要創(chuàng)建機械化進程，讓它們有效的使用工具。這些工具可以用來生成一致的結(jié)果并被團隊中的其他成員所分享。
- 服務(wù)器版本控制——任何變化并不直接應(yīng)用到服務(wù)器上，而是應(yīng)用到一個中央版本庫內(nèi)。所有改變從中央版本庫推送到服務(wù)器上，從而在出現(xiàn)錯誤的時候會有一個返回機制。
- 頻繁的改進和發(fā)布/更新——舊的思維方式是，盡可能減少對服務(wù)器和架構(gòu)進行改變（無論是次數(shù)還是規(guī)模）來降低風(fēng)險。而敏捷的運維思路是，通過頻繁的微小變化來改善服務(wù)器的性能，而由于每次的變化都很小，當(dāng)出現(xiàn)問題的時候，他們可以輕易地跟蹤那些影響架構(gòu)的不利變化。
為了實現(xiàn)這些目標(biāo)，系統(tǒng)工程師需要一個更強大的工具包。幸運的是，開源界為了這一目標(biāo)已經(jīng)研發(fā)了大量的工具。
#p#
開源工具鏈
軟件開發(fā)者們對于工具鏈相當(dāng)熟悉：一個程序的輸出構(gòu)成了另一個程序的錄入，從而組成了一系列程序。比如說，使用GNU Emacs編輯器，GNU bin-utils和GNU編譯器集（GCC）的組合。軟件開發(fā)者們編寫很多在其它程序中調(diào)用的程序與流程，而不是將同一段代碼在所有的地方都重復(fù)一遍。
有了新生的DevOps和敏捷運維運動，運維人員們組成了社區(qū)，幫助人們用自己所喜愛的工具來定義屬于自己的工具鏈。DevOps的工具鏈項目就是這些社區(qū)當(dāng)中的一員。
正如軟件開發(fā)商有不同的專用工具來串聯(lián)成一條軟件工具鏈（比如編輯、編譯、構(gòu)建腳本等），系統(tǒng)管理員也可以運用由這些能夠?qū)崿F(xiàn)自動管理功能和維護Linux服務(wù)器的工具組成的工具鏈。它們可以分為三大類：預(yù)備、配置管理和監(jiān)控。
圖1.1開源工具所適合的開源工具鏈
- 預(yù)備類工具可以使Linux服務(wù)器上的軟件安裝包自動化。它們借助服務(wù)器上的軟件包系統(tǒng)比如rpm或者apt來安裝軟件包，有些甚至?xí)鲆恍┐致缘呐渲霉ぷ鳌?/li>
- 配置管理和自動化是用來設(shè)置參數(shù)或者開啟一個新服務(wù)器上的服務(wù)。它們也可以用來把系統(tǒng)還原到遇到錯誤之前的狀態(tài)。
- 監(jiān)控工具用來收集服務(wù)器數(shù)據(jù)，從而生成可用性、性能和其它系統(tǒng)狀態(tài)的報告。
整合系統(tǒng)管理工具
開源工具鏈對于維護高服務(wù)水平而言可以說是一件很好的禮物，因為自動化和準(zhǔn)確無誤的運作比手動解決問題更快、更有效率。如果你想保持五個九的可用服務(wù)水平（99.999%的正常運行時間的超低容錯率系統(tǒng)），那么為了讓服務(wù)水平不受影響，你在每一年中只允許有5分15秒的停機時間。對于一個管理員而言，這樣的時間甚至來不及接收錯誤報告頁，更不用說登陸到服務(wù)器進行問題診斷了。另外，除了通過監(jiān)控和管理服務(wù)對問題作出及時反應(yīng)與修復(fù)，也可以制定一種防止故障發(fā)生的機制。
構(gòu)建工具鏈可以從使用服務(wù)器自動構(gòu)建工具開始。服務(wù)器自動構(gòu)建工具可以加速部署速度，并可以在短時間內(nèi)大規(guī)模部署服務(wù)器，同時也可以讓構(gòu)建過程更容易復(fù)制。在發(fā)生嚴(yán)重故障時，還可以重建架構(gòu)。
在早期，Linux用戶可能會整理出一個軟件包列表，發(fā)至rpm進行批量軟件安裝，這就是一個非常簡單的工具鏈。后來，我們用Kickstart來執(zhí)行無人值守的Linux安裝。現(xiàn)在，Cobbler把這個功能提升到了一個新的高度：它實現(xiàn)了物理機與虛擬機的并行系統(tǒng)構(gòu)建，并且可以進行DHCP和DNS的配置。
Cobbler還集成了其它的工具，比如用于配置管理自動化的Puppet等軟件。這個工具可以在系統(tǒng)安裝完畢后進行服務(wù)的自動更新。
PuppetLabs的創(chuàng)始人Luke Kanies指出，“無論是何種規(guī)模的公司，都可以使用Puppet來管理機器。從最初的安裝到最后的使用壽命終止，所有構(gòu)建服務(wù)器或者部署新應(yīng)用版本的時候都可以完全避免人工干預(yù)。”
開源工具鏈的另外一個例子是集預(yù)備、配置和自動化工具于一身，比如由紅帽資助的Genome項目。Genome是一系列用于維持云架構(gòu)的工具。Genome可以部署多層次的網(wǎng)絡(luò)應(yīng)用，包括Apache反向代理層，JBoss應(yīng)用服務(wù)器層，以及PostgresSQL數(shù)據(jù)庫層。
圖1.2 Genome架構(gòu)
上述大部分工具都是實時的，可以用來進行變動并執(zhí)行某些任務(wù)。然而，它們卻缺乏關(guān)于當(dāng)前系統(tǒng)狀況的信息，于是監(jiān)控工具就有了用武之地。對于傳統(tǒng)的系統(tǒng)管理員而言，監(jiān)控?zé)o非是在發(fā)生錯誤的時候通過一個頁面或者一封郵件提醒他們。但是，監(jiān)控工具（比如Nagios、OpenNMS和Zenoss Core）能夠提供更為完善的服務(wù)器性能檢測。這些信息告訴管理員們有關(guān)運行中的工具正處在怎樣的狀態(tài)下。它們中的一些甚至可以提供在其它工具中開啟程序的界面。例如，Zenoss Core可以在一個檢測狀態(tài)臺上通過Cfengine、Chef或者Puppet來重新配置服務(wù)。
在一次O’Reilly Velovity的會議上，我們曾經(jīng)進行過一次叫做DevOps GameDay的演示。這次演示由一個同時托管于東部和西部海岸的亞馬遜EC2數(shù)據(jù)中心的網(wǎng)絡(luò)應(yīng)用程序組成。在西海岸的管理員制造了一些服務(wù)器故障，Zenoss Core對架構(gòu)進行了監(jiān)測，發(fā)現(xiàn)了故障并且通知OpsCode的Chef采取行動。Chef隨后通過Dynect API更新了Dynect平臺上的服務(wù)，從而恢復(fù)了向東海岸設(shè)備的正常數(shù)據(jù)傳輸。每次在新的服務(wù)器上線時，Chef都能夠?qū)⑿虑闆r推送至Zenoss，并開始在補救架構(gòu)中對它們進行監(jiān)測。
圖1.3 網(wǎng)絡(luò)應(yīng)用程序故障工具鏈?zhǔn)纠?/p>
這次演示讓大家認識到架構(gòu)自動化改進系統(tǒng)恢復(fù)的能力。在這種情況下，系統(tǒng)能夠保持內(nèi)置冗余和多個網(wǎng)路服務(wù)器以及DNS之間的平衡。當(dāng)系統(tǒng)發(fā)現(xiàn)了故障時，架構(gòu)可以在90秒內(nèi)進行自動恢復(fù)。此外，雖然這只是一個簡單的演示，但是同樣的設(shè)計可以運用到其它的工具和情景中去。
總結(jié)
多年以來，專有軟件管理廠商一直在嘗試通過廣泛的管理套件來提供完整的服務(wù)周期管理。這些產(chǎn)品通常在一個秘密環(huán)境下進行研發(fā)，然后通過收購規(guī)模較小的公司的技術(shù)來進行不斷地補充。這種東拼西湊的方式往往讓他們出售給大多數(shù)用戶的產(chǎn)品有著一長串的功能，但事實上總是效果少于承諾。
開源工具對于管理架構(gòu)的好處不言而喻。首先，它們?yōu)橛脩籼峁┝诉x擇余地。其次，技術(shù)得到了開放的發(fā)展，而終端用戶能夠更好的詮釋功能集成軟件的發(fā)展。第三，開源工具促進創(chuàng)新，并且極具包容性，它鼓勵大家的參與，因為使用它們很少會受到限制，這將有利于它們的發(fā)展。最后，開源軟件的氛圍利于開放標(biāo)準(zhǔn)、互操作性和開放API，這使得集成變得更為簡單。
Opescode公司服務(wù)部副總裁John M.Willis說到，“在云中，架構(gòu)管理可以不再依賴節(jié)奏緩慢的非集成遺留軟件。在Opscode，我們把開源軟件、自動化架構(gòu)和系統(tǒng)集成看做是高度可擴展系統(tǒng)的最后路程。今天的架構(gòu)需要快速、頻繁、靈活的管理。依賴于非集成的封閉方案不可能跟上不斷變化的IT世界的步伐。開放API和單觸摸點交易是高度可擴展操作的新標(biāo)準(zhǔn)。”
無論你的基礎(chǔ)架構(gòu)如何，都可以試試看使用開源工具創(chuàng)建屬于你自己的工具鏈，也許會有想象不到的收獲。
【51CTO.com譯稿，轉(zhuǎn)載請注明原文作譯者和出處?！?/p>
【編輯推薦】
