-- 會員 / 註冊 --  
 帳號:
 密碼:
  | 註冊 | 忘記密碼
3/26 新書到! 3/19 新書到! 3/14 新書到! 12/12 新書到!
購書流程Q & A站務留言版客服信箱
3ds MaxMayaRhinoAfter EffectsSketchUpZBrushPainterUnity
PhotoShopAutoCadMasterCamSolidWorksCreoUGRevitNuke
C#CC++Java遊戲程式Linux嵌入式PLCFPGAMatlab
駭客資料庫搜索引擎影像處理FluentVR+ARANSYS深度學習
單晶片AVROpenGLArduinoRaspberry Pi電路設計CadenceProtel
HadoopPythonStm32CortexLabview手機程式AndroidiPhone
可查書名,作者,ISBN,3dwoo書號
詳細書籍分類

CoreOS實戰

( 簡體 字)
作者:[美]Matt Bailey 著 類別:1. -> 程式設計 -> 綜合
譯者:蒲成 譯
出版社:清華大學出版社CoreOS實戰 3dWoo書號: 48849
詢問書籍請說出此書號!

有庫存
NT售價: 250

出版日:2/1/2018
頁數:150
光碟數:0
站長推薦:
印刷:黑白印刷語系: ( 簡體 版 )
加入購物車 加到我的最愛
(請先登入會員)
ISBN:9787302494522
作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 
(簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證)
作者序:

譯者序:

前言:

正如《CoreOS實戰》的許多讀者一樣,我也是作為Linux和UNIX系統以及網絡的系統管理員而開啟技術行業職業生涯的。另外,就像許多人一樣,我從未對可用的自動化程度感到滿意過,也從未對其無條件信任過。我們中的一些人或多或少使用過CFEngine、Puppet和Chef來進行管理,并且使用我們的技術進行更嚴謹的工程設計和承擔較少的系統管理工作。之后容器變得流行起來,并且CoreOS的發布大規模地填平了容器與系統管理之間的溝壑。
我是在2013年末CoreOS剛剛問世時開始使用它的。它是一款大部分系統管理員都認為遲早會出現的OS。它提供了一種集成方式,以便將服務編制為從其所運行的計算資源池中提取的抽象。Manning出版社在2015年末開始聯系我,想要知道我是否有興趣編寫一本CoreOS方面的書籍,我接受了這個提議并且開始奮筆疾書。當我由于這個項目而無法在業余時間陪伴我的孩子們時,我也感到愧疚。這是我的第一《CoreOS實戰》,我發現,內容構思以及在Vim中輸入這些內容并不是最難的部分,最難的是同時找到充滿動力的書籍編寫時間和不受打擾的自由時間。而這種情況很少會同時出現,尤其是在家有幼兒的情況下。
我希望《CoreOS實戰》能夠引導讀者并且為讀者帶來一些挑戰。從某種程度上說,這《CoreOS實戰》的內容發展遵循了我職業生涯的發展軌道以及此技術領域的發展軌道。具體而言,CoreOS和類似的系統都旨在將單調乏味的運營工作轉變成軟件開發,并且將系統管理救火式的工作轉變成聲明式的工程設計。因此,《CoreOS實戰》是從基礎組成部分開始介紹的,并且以完整的軟件棧作為結束。
關于《CoreOS實戰》
《CoreOS實戰》為應用程序架構、系統管理員以及尋求如何在不犧牲開發工作流或者運營簡單性的情況下進行規模化計算的信息的人提供了一個有效資源。CoreOS及其組件套裝提供了一種切實可行的方法來進行系統設計,其中高可用性、服務發現以及容錯性變得不難實現,并且從一開始就成為核心基礎設施和應用程序架構的組成部分。CoreOS和它所倡導的概念對于開發人員和運營專家來說都是有用的,CoreOS意識到在某種程度上容器化的意圖正變得更易于投入運營、維護和迭代。
如果讀者正在閱讀《CoreOS實戰》,那么大概已經注意到了,技術領域的普遍行動就是分解豎井并且將開發和運營這兩方面結合到一起。在許多組織中,運營專家和應用程序架構師的角色正在被結合成一個角色,例如開發運營(DevOps)或者站點穩定工程(Site Reliability Engineering)。因而,一些人可能最終面臨知識缺口。有時候,《CoreOS實戰》可能看起來使用更高級的主題組合了對讀者而言顯而易見的信息,不過那是因為我在嘗試為可能不具備成功使用CoreOS所需的部分基礎知識的人提供完整的全局觀念。
《CoreOS實戰》讀者對象
《CoreOS實戰》的讀者對象是系統管理員、軟件工程師以及對構建可擴展容錯系統感興趣的人。《CoreOS實戰》研究了使用CoreOS進行運營化和構建服務的軟件架構;如果讀者有興趣了解構建可擴展的具有容錯性的系統,那么《CoreOS實戰》就是很好的資料來源。
《CoreOS實戰》中并沒有大量的功能性代碼——我基本上是在介紹配置文件以及一些用于Amazon Web Services的YAML模板。對于Bash和通用Linux系統管理的基礎理解應該就足以讓讀者入門了。在《CoreOS實戰》后面的內容中,會提供具有JavaScript前端的Node.js示例,不過JavaScript經驗并不是必要的。
在描述《CoreOS實戰》章節之前,先介紹一些技術背景知識。
背景介紹
大約從2008年開始,擴展系統以便滿足組織顧客的需要已經催生了包括服務、工具和咨詢公司的整個行業。這些行業的最終目標一直都是管理具有較少資源的更大規模的系統——并且要非常快速地進行管理。這些平臺即服務(Platform-as-a-Service,PaaS)、基礎設施即服務(Infrastructure-as-a-Service,IaaS)以及配置管理套件都旨在將系統管理的重擔轉換成自動化系統,這樣組織才能“輕易地”從規模化目標中將IT人力資源釋放出來。其理念可以用一個比喻來形容(這個比喻是由Bill Baker提出的,這是我能找到的最貼切的比喻),我們應該將基礎設施當作家畜而非寵物來對待。也就是說,計算資源單元是日用品或電器,而非具有名稱的獨立的、精心維護的服務器。當家畜出現問題時,我們會處理掉它們;而在寵物生病時,我們需要對其進行護理以便它們恢復健康。我們應該充分利用自動化,并且不應該過多關心是否必須進行重構;這樣做應該是容易并且可復制的。
不過現實情況是,嘗試達成這些可復制性和瞬時性目標通常會極其復雜。這樣做的具體方式會變成豎井邏輯和工作流的黑盒,即使是在使用廣泛引用的工具也會如此。像Chef和Puppet這樣的配置管理系統對于此復雜性而言尤其脆弱——不是因為它們的設計就是如此,而是因為組織通常會遇到阻礙(技術性和非技術性的),而這些阻礙的最終解決都是以與這些工具的最佳實踐完全無關的方式來處理的。在IaaS領域,組織通常會像處理其現場資源那樣處理其公有云計算資源,這主要是因為IaaS具有允許這樣做的靈活性,即使這樣做會導致系統不可維護。下面介紹容器。
容器
LXC是在Linux用戶空間中創建虛擬化運行時的早期實踐。與chroots和jails相比較,它是一種比較重的抽象,但又比完全虛擬化輕。在Docker于2013年推出并且圍繞LXC技術增加大量特性之前,很少有人使用過或者聽說過LXC,最終,Docker用自己的組件完全替換了LXC的組件。在我看來,大體而言,Docker和容器化解決了虛擬化打算解決的問題:關注點的簡單隔離、系統的復制以及不可變的運行時狀態。其優勢很明顯:依賴性管理變得被輕易包含其中;運行時是標準化的;并且其方法對開發人員足夠友好,開發和運營可以使用相同的工具,且每個字節都在使用同一容器。因此,我們已經越來越少地聽到“它僅對我適用,而不適用于生產”這樣的話了。CoreOS在某種程度上正是此計算模型的運營化,它利用了在通用、分布式系統模型中容器化的優勢。
《CoreOS實戰》從頭至尾都在介紹如何利用此計算模型的優勢。讀者將了解如何同時在原型環境和云端生產環境中部署和管理CoreOS。還將了解到如何設計和調整應用程序棧以便它能在此上下文中很好地運行。除了該OS,還將詳細介紹CoreOS的每個組件及其應用:etcd用于配置和發現,rkt用于另一種方式的容器運行時,fleet用于分布式服務調度,flannel用于網絡抽象。
分布式計算并非新概念;許多用于分布式系統的模型和軟件包自從計算的廣泛應用開始就已經問世了。不過這些系統中的大多數模型和軟件包都不為人所知,具有高度的專屬權,或者隔絕在像科學計算這樣的特定行業中。最老的一些設計如今仍然存在的唯一原因就是支持20世紀70年代的遺留系統,它們為大型機和小型機驅動著分布式計算。
CoreOS背后的歷史與推動因素
單系統映像(Single System Image,SSI)計算的概念是一種OS架構,自20世紀90年代以來并沒有看到它有多么活躍,它只在一些長期支持遺留系統的場景中得到了應用。SSI是一種架構,它將集群中的多臺計算機作為單一系統來提供。其中有單一的文件系統、通過共享運行時空間來共享的進程間通信(Interprocess Communication,IPC),以及進程檢查點/遷移。MOSIX/openMosix、Kerrighed、VMScluster和Plan 9(原生支持的)都是SSI系統。Plan 9上大概曾進行過大部分當前的開發活動,這應該表明了此計算模型當初的流行性。
SSI的主要缺陷在于,首先,這些系統通常難以配置和維護,并且并非旨在實現通用性。其次,該領域的發展已經明顯停滯了:SSI中沒有什么新東西出現,并且它已經無法跟上發展以用作一個流行模型。我認為這是因為科學和其他大數據計算已經擁抱了網格計算,比如像Condor、BOINC和Slurm這樣的批處理操作模型。這些工具旨在在集群中運行計算任務并且交付結果;SSI的共享IPC無法為這些應用程序提供多少好處,因為數據傳輸的(時間)成本超過了阻塞式批處理過程的成本。在應用程序服務棧的領域中,通過像HTTP這樣的協議的抽象以及分布式隊列也讓人們不再值得對共享IPC進行投入。
目前,對于分布式計算而言,問題域是如何有效管理大規模的系統。無論我們是在使用Web棧還是分布式批處理,可能都不需要共享IPC,不過SSI帶來的其他內容具有更多顯而易見的價值:共享文件系統意味著我們僅需要配置一個系統,并且進程檢查點和遷移意味著結點都是可丟棄的并且“更類似家畜”。在不使用共享IPC的情況下,這些解決方案會難以實現。一些組織轉而使用將配置應用到多臺機器的配置管理系統,或者設置復雜的具有完全自定義邏輯的監控系統。根據我的經驗來看,配置管理系統無法達成目標,因為它僅會完全確保運行時的所有狀態;在它們運行完成之后,狀態就會變成未知。這些系統更專注于可復制性而非一致性,這是一個好的目標,但無法提供通過分布式文件系統進行共享配置的可靠性。嘗試同時管理進程的監控系統通常要么特定于應用程序,要么難以實現和維護。
無論是有意或無意,像Docker這樣的容器系統都為重新利用SSI的優勢奠定了基礎,而不需要實現共享的IPC。Docker確保了運行時狀態,并且提供了從OS中抽象出來的執行模型。“不過,”大家可能會想,“這完全與SSI相反。現在每一個獨立的系統甚至都具有了更為隔離的配置和運行時,而非共享式的!”的確,此方法是不相關的,不過它實現了相同的目標。如果運行時狀態僅被定義一次(比如在Dockerfile中),并且在整個容器生命周期中都對其進行維護,那么我們就達成單點配置的目標。并且,如果可以同時遠程和獨立于其運行之上的OS與集群結點來編制獨立進程狀態的話,我們就達成通用服務在集群范圍內的進程調度這一目標。
意識到那些可能性就是需要獨立于容器化系統之外的工具的地方。這正是CoreOS及其系統套件發揮作用的地方。CoreOS提供了足夠的OS以供運行一些服務;其余的都是由etcd和fleet的編制工作來處理的—— etcd提供了分布式配置,從中容器可以定義其運行時特征,而fleet管理著分布式初始化和容器調度。從內部看,CoreOS也使用etcd來提供分布式鎖以便自動管理OS升級,這轉而又會使用fleet在整個集群中平衡服務,這樣結點就可以自行升級了。
《CoreOS實戰》路線圖
第1章首先簡要介紹CoreOS生態系統。我提供了容器OS中核心系統的一些闡釋,以及一個并非真正旨在用于執行而是揭示這些部分如何適配到一起的簡要示例。
第2章介紹設置一個本地CoreOS環境的過程,我們將在《CoreOS實戰》大部分后續內容中使用它作為沙盒。這也是人們在現實環境中使用的過程,以便為CoreOS構建組件,因此進一步關注該章的內容會是一個好的做法。
第3章講解與CoreOS容錯性和系統升級的方式有關的內容,并且介紹設置一個容錯性Web應用的處理步驟。我們在《CoreOS實戰》其余內容中基于這個“Hello World”進行構建。
第4章探討了現實世界的需求和CoreOS生產部署的目標,以及與如何處理集群中分布式文件系統選項有關的一個現實示例。
第5章會研究十二要素應用方法論以及如何將之應用到希望在CoreOS中部署的應用程序棧上。該章會以如何在第6章中應用此方法論的概述作為結束。
第6章將第3章的示例擴展成一個具有許多層的更為真實的Web應用。我們還將引入一個持久化數據庫層。
第7章使用了第6章的持久化層并且深入探究了如何讓它具有容錯性和在所有集群機器中的可擴展性。
第8章深入研究Amazon Web Services(AWS)中CoreOS的實踐部署。
第9章講解如何使用第6章和第7章中所構建的整個軟件棧,并且以自動化方式將它部署到第8章所構造的AWS環境中。
第10章通過探討CoreOS的系統管理部分總結了《CoreOS實戰》內容,其中包括日志記錄、備份、擴展以及CoreOS的新rkt容器系統。
源代碼下載
《CoreOS實戰》中所有示例的源代碼,包括一些非常長的AWS模板,都可以下載。也可掃描封底的二維碼下載源代碼。
作者簡介
Matt Bailey目前是ZeniMax的技術主管。他曾致力于高等教育行業,并且曾供職于科學計算、醫療和網絡技術公司,以及一些初創型公司。讀者可以通過在線方式聯系他。
作者在線
購買了《CoreOS實戰》的讀者可以免費訪問Manning出版社所運營的一個私有網絡論壇,讀者可以在其中對《CoreOS實戰》進行評論,提出技術問題,并且接受來自作者和其他讀者的幫助。要訪問該論壇并且進行訂閱。這個頁面提供了相關的信息,其中包括如何在注冊之后登錄該論壇,可以得到哪些幫助,以及該論壇上的行為準則。
Manning出版社對于讀者的承諾旨在提供一個場所,其中讀者與讀者之間以及讀者與作者之間可以展開有意義的對話。作者方面的參與程度是無法得到保證的,但對于作者在線的貢獻仍舊是自愿的(并且免費的)。我們建議讀者嘗試向作者提出一些具有挑戰性的問題以免他沒興趣關注!
只要《CoreOS實戰》還在印刷,就可以從出版商的網站上訪問作者在線論壇和前述探討內容的歸檔。
《CoreOS實戰》封面介紹
《CoreOS實戰》封面上的圖畫是一個“敘利亞苦行僧”。穆斯林苦行僧生活在宗教團體中,他們與世隔絕并且過著物資匱乏且冥想式的生活;他們是眾所周知的智慧、醫藥、詩歌、啟迪和妙語的源泉。該圖例來自于倫敦老邦德街的William Miller于1802年1月1日出版的奧斯曼帝國服裝圖集。該圖集的扉頁已經丟失,并且我們至今都無法找到它的下落。這《CoreOS實戰》的目錄同時使用英語和法語來標識插圖,每張插圖都有創作它的兩位藝術家的名字,他們無疑一定會為自己的作品被裝飾到200年后的一本計算機編程書籍的封面上而感到驚訝。
自那時起,衣著習慣已經改變了,當時如此豐富的地區多樣性已經逐漸消失。如今通常從衣著很難區分不同國家的居民。也許,嘗試從樂觀的角度來看,我們已經用文化和視覺上的多樣性換來了更為多樣化的個人生活——或者說是更為豐富以及有趣的知識技術生活。Manning出版社的同仁崇尚創造性、進取性,這個圖集中的圖片使得兩個世紀以前豐富多彩的地區生活躍然于紙上,以其作為圖書封面會讓計算機行業多一些趣味性。
內容簡介:

《CoreOS實戰》介紹CoreOS的生態系統與組件,如何在本地和云系統中設置CoreOS,然后逐步完善一個容器應用開發實例,最后介紹系統管理。
《CoreOS實戰》是在CoreOS Container Linux上部署基于容器的系統的清晰指南。在其中,讀者將看到一些講解如何同時在私有基礎設施和云系統中設置CoreOS的示例,并且可以使用真實的代碼來實踐常規的監控和升級技術。讀者還將探究重要的容器感知的應用程序設計,其中包括微服務、Web和大數據示例,通過真實用例將讀者所學知識轉換成自有觀點。
目錄:

第Ⅰ部分增進了解CoreOS
第1章CoreOS家族介紹3
1.1迎接CoreOS3
1.1.1CoreOS家族4
1.1.2etcd和分布式配置狀態5
1.1.3fleet和分布式服務狀態6
1.1.4充當CoreOSinit系統的systemd6
1.1.5Docker和/或rkt,容器運行時6
1.1.6使用cloud-config進行初始化配置7
1.2將核心服務裝配到一起7
1.2.1CoreOS工作流8
1.2.2創建和運行服務9
1.2.3創建單元文件10
1.2.4服務拓撲和故障轉移12
1.3本章小結14
第2章在工作站上開始研究15
2.1設置Vagrant15
2.1.1需求和設置16
2.1.2設置Vagrant并且運行它17
2.1.3讓CoreOS集群在Vagrant中運行20
2.2用于與CoreOS交互的工具21
2.2.1fleetctl22
2.2.2etcdctl26
2.2.3Toolbox容器27
2.2.4Linux管理員的概念轉換28
2.3本章小結29
第3章可預期的故障:CoreOS中的容錯31
3.1監控的當前狀態31
3.1.1有何不足32
3.1.2CoreOS的處理有何不同33
3.2服務調度與發現34
3.2.1部署生產環境NGINX和Express35
3.2.2將etcd用于配置35
3.3進行一些破壞40
3.3.1模擬機器故障40
3.3.2自修復41
3.4應用程序架構和CoreOS42
3.4.1常見陷阱42
3.4.2新項目和遺留項目43
3.4.3配置管理43
3.5本章小結43
第Ⅱ部分應用程序架構
第4章生產環境中的CoreOS47
4.1規劃和部署選項47
4.1.1AmazonWeb服務48
4.1.2使用內部VM基礎設施50
4.1.3在裸機上50
4.2與網絡有關的注意事項50
4.2.1網絡的可編程程度有多大51
4.2.2使用flannel啟動和運行52
4.3我們的大容量存儲在何處55
4.3.1數據系統背景55
4.3.2NAS和存儲外包56
4.3.3Ceph57
4.4本章小結61
第5章應用程序架構和工作流63
5.1應用程序和十二要素方法論63
5.1.1CoreOS的方法64
5.1.2架構檢查清單65
5.2軟件開發周期66
5.2.1代碼庫和依賴性66
5.2.2環境邏輯和微服務67
5.2.3應用程序外沿69
5.3本章小結69
第6章Web棧應用程序示例71
6.1示例范圍71
6.1.1這個應用程序會做些什么72
6.1.2應用架構概覽73
6.1.3目標環境74
6.2設置持久化層75
6.2.1Couchbase設置75
6.2.2設置memcached77
6.3應用程序層79
6.3.1工作線程80
6.3.2Web應用83
6.4由此向何處發展89
6.4.1對故障進行響應89
6.4.2遺漏了什么90
6.5本章小結91
第7章大數據棧93
7.1本章示例的范圍93
7.1.1架構的增加項94
7.1.2新的數據源95
7.2新的棧組件95
7.2.1Twitter數據收集器96
7.2.2編制Couchbase98
7.2.3啟動和驗證105
7.2.4啟動工作線程106
7.3破壞我們的棧108
7.3.1監測故障108
7.3.2恢復機器108
7.4本章小結109
第Ⅲ部分生產環境中的CoreOS
第8章AWS上的CoreOS113
8.1AWS背景介紹114
8.1.1AWS地區和正常運行時間114
8.1.2AWS服務115
8.1.3本章必要條件115
8.1.4CloudFormation模板116
8.1.5AWS中的云配置126
8.1.6部署129
8.2本章小結132
第9章整合到一起:部署133
9.1新的CloudFormation對象134
9.1.1參數和輸出134
9.1.2AWSLambda135
9.1.3APIGateway137
9.1.4更新棧138
9.2部署應用139
9.2.1Websidekick139
9.2.2初始化部署140
9.3自動化部署142
9.3.1DockerHub設置142
9.3.2推送變更143
9.4本章小結144
第10章系統管理145
10.1日志記錄和備份145
10.1.1設置日志146
10.1.2更新云配置146
10.1.3單元中的awslogs147
10.1.4瀏覽日志148
10.1.5備份數據149
10.2系統擴展151
10.2.1集群擴展152
10.2.2擴展分區153
10.2.3遷移服務153
10.3CoreOS展望154
10.3.1新的工具155
10.3.2rkt155
10.4本章小結159
序: