PaaS實現與運維管理：基於Mesos +Docker+ELK的實戰指南

第一部分概念模型
第1章分布式PaaS平台介紹2
1.1什麼是PaaS2
1.1.1開發與運維之間的困局2
1.1.2DevOps的自動化3
1.1.3雲計算的IaaS4
1.1.4PaaS的到來4
1.1.5PaaS的約束與開放4
1.1.6PaaS解決的具體問題5
1.2什麼是分布式計算6
1.2.1分布式計算與PaaS6
1.2.2分布式平台的挑戰7
第2章PaaS模型與特征10
2.1主流PaaS平台架構10
2.1.1谷歌GAE10
2.1.2AEB11
2.1.3CloudFoundry13
2.1.4Heroku14
2.2PaaS與12—Factor15
2.2.1基准代碼（Codebase）15
2.2.2依賴（Dependency）16
2.2.3配置（Config）17
2.2.4后端服務（BackingServices）18
2.2.5構建（Build）、發布（Release）、運行（Run）19
2.2.6進程（Process）20
2.2.7端口綁定（PortBinding）21
2.2.8並發（Concurrency）21
2.2.9快捷性（Disposable）22
2.2.10開發／生產環境等價（Dev／ProdParity）23
2.2.11日志（Log）24
2.2.12管理進程（AdminProcess）25
2.3PaaS與Reaction宣言26
2.3.1響應（Responsive）26
2.3.2韌性（Resilient）26
2.3.3彈性（Elastic）27
2.3.4消息驅動（MessageDriven）28
第二部分基礎原理
第3章計算資源30
3.1圖靈機與馮•諾伊曼模型30
3.2服務器的種類34
3.3一切都是二進制37
3.3.1整數表示法38
3.3.2文本表示法39
3.3.3音頻信息表示法41
3.4操作系統——計算機系統的指揮官42
3.4.1操作系統解決的問題42
3.4.2企業級操作系統43
3.4.3服務器虛擬化47
3.5進程——資源聚合的抽象體49
3.5.1計算單元的構建49
3.5.2計算請求的拆解51
第4章網絡資源53
4.1協議分層53
4.1.1OSI網絡體系模型54
4.1.2OSI與TCP／IP協議簇55
4.1.3交換、選路與傳輸56
4.2網絡物理設備58
4.2.1連線與接口59
4.2.2二層交換機62
4.2.3路由及三層交換63
4.2.4四～七層網絡設備64
4.2.5現實網絡構成65
4.3網絡邏輯拓撲65
4.4對網絡拓撲的考慮66
4.5對物理布線的考慮67
4.6網絡虛擬化與SDN70
第5章存儲資源73
5.1俯瞰存儲系統73
5.1.1數據存儲功能分類73
5.1.2文件存儲的三個層級74
5.2磁盤與磁盤陣列77
5.2.1硬盤的物理構造77
5.2.2磁盤陣列79
5.2.3SCSI協議81
5.3存儲、計算分離82
5.3.1磁盤櫃與盤陣82
5.3.2FC存儲網絡83
5.3.3FC協議棧86
5.3.4FC尋址過程87
5.3.5FC交換機與適配器88
5.3.6FCoE與iSCSI89
5.4存儲訪問類型90
5.4.1NAS與SAN90
5.4.2分布式存儲92
第三部分平台實現
第6章平台功能與架構96
6.1平台運維需求96
6.1.1軟件配置96
6.1.2服務部署97
6.1.3服務發現97
6.1.4監控恢復97
6.2平台功能划分97
6.3平台高階架構100
6.4企業應用遷移102
6.4.1企業應用很「厚重」102
6.4.2應用部署架構102
6.4.3企業應用調整104
第7章計算單元Docker108
7.1Docker介紹108
7.1.1Docker是什麼108
7.1.2Docker術語109
7.1.3Docker安裝111
7.2Docker容器命令112
7.2.1run命令112
7.2.2start命令115
7.2.3stop命令116
7.2.4restart命令116
7.2.5attach命令116
7.2.6ps命令116
7.2.7inspect命令117
7.3Docker鏡像命令119
7.3.1search、pull、push命令120
7.3.2commit命令120
7.3.3image、diff、rmi命令121
7.3.4save、load、export、import命令121
7.4Docker網絡與鏈接122
7.4.1Docker網絡模式122
7.4.2pipework管理網絡125
7.4.3容器鏈接與數據卷127
7.5Dockerfile129
7.5.1基本指令集130
7.5.2環境指令集131
7.5.3數據指令集132
7.5.4ENTRYPOINT指令132
第8章分布式協調ZooKeeper134
8.1ZooKeeper介紹134
8.1.1ZooKeeper是什麼134
8.1.2ZooKeeper架構135
8.1.3數據模型136
8.1.4監聽與通知139
8.1.5API集合139
8.1.6會話140
8.1.7觀察者141
8.2ZooKeeper使用141
8.2.1快速安裝141
8.2.2基本操作143
8.2.3配置參數145
8.2.4動態重配置149
8.2.5監控152
8.3ZooKeeper進階157
8.3.1分組與權重158
8.3.2Paxos算法159
8.3.3ZAB協議163
8.3.4分布式協調場景165
第9章資源管理Mesos167
9.1Mesos介紹167
9.1.1資源管理需求167
9.1.2Mesos的起源169
9.2Mesos架構與工作流169
9.2.1Mesos架構組件169
9.2.2Mesos資源管理的工作流程170
9.3Mesos安裝配置172
9.3.1安裝預先准備172
9.3.2構建Mesos173
9.3.3啟動Mesos174
9.3.4高可用Mesos178
9.3.5Slave移除限速182
9.4Mesos運維183
9.4.1認證管理183
9.4.2監控管理186
9.4.3容器網絡限速192
9.4.4FrameworkAPI限速194
9.4.5Restful接口195
9.4.6配置參數196
9.5Mesos資源分配197
9.5.1DRF算法197
9.5.2DRF權重199
第10章服務調度框架Marathon200
10.1Marathon介紹200
10.1.1服務調度平台200
10.1.2Marathon實體模型201
10.2Marathon使用203
10.2.1安裝啟動203
10.2.2運行Shell程序204
10.2.3運行遠程資源208
10.2.4ArtifactStore209
10.3Docker容器運行211
10.3.1前提准備條件211
10.3.2端口資源分配212
10.3.3容器端口分配215
10.3.4其他使用方法216
10.4Marathon管理217
10.4.1應用組217
10.4.2策略約束219
10.4.3健康檢查221
10.4.4應用部署223
10.4.5事件總線227
10.4.6命令行參數229
10.5服務發現231
10.5.1服務發現方法231
10.5.2Marathon方案232
10.5.3Mesos—DNS235
10.5.4Bamboo239
10.6Chronos作業調度241
10.6.1作業調度框架241
10.6.2安裝運行241
10.6.3作業示例242
10.6.4RESTAPI243
第11章大數據調度框架Spark245
11.1ApacheSpark介紹245
11.1.1ApacheSpark是什麼245
11.1.2Lambda架構246
11.1.3Spark生態系統247
11.2Spark數據處理248
11.2.1Spark運行模式248
11.2.2SparkStandalone模式252
11.2.3SparkonMesos255
11.2.4SparkStreaming257
第12章日志集中管理ELK261
12.1日志集中261
12.1.1日志集中介紹261
12.1.2日志集中架構262
12.1.3日志集中框架264
12.2Logstash266
12.2.1Logstash介紹266
12.2.2快速安裝267
12.2.3配置說明269
12.2.4部署架構282
12.2.5處理流程285
12.2.6input插件286
12.2.7output插件292
12.2.8filter插件296
12.2.9codec插件299
12.3Elasticsearch300
12.3.1基本概念300
12.3.2安裝與使用304
12.3.3RESTAPI305
12.3.4集群設置309
12.3.5備份恢復314
12.3.6監控管理315
12.4Kibana317
12.4.1Kibana介紹317
12.4.2discover功能319
12.4.3visualize功能324
12.4.4Dashboard功能327
第四部分運維管理
第13章配置管理330
13.1配置管理系統分析331
13.1.1服務模型進行分層331
13.1.2各IDC團隊發現CI332
13.1.3IDC管理團隊定義CI屬性333
13.1.4確定CI之間的關聯336
13.2配置管理系統設計338
13.2.1用戶界面設計339
13.2.2權限控制、規則定義和OPENAPI341
13.2.3數據模型的設計343
13.3配置管理數據准確性的保證345
13.3.1識別CI的OWNER345
13.3.2識別CI的生命周期、關聯運維流程346
13.3.3數據有效性的審計346
第14章監控管理348
14.1運維監控管理的問題與價值348
14.1.1監控管理的無形價值349
14.1.2監控平台建立的基礎350
14.1.3監控管理的WANT原則350
14.2對運維監控平台的需求分析352
14.2.1一次監控過程，調度、規則、告警352
14.2.2數據圖形化：百分位裁剪、趨勢分析、正態分布358
14.2.3開源的借鑒與選擇：Zabbix和Nagios361
14.2.4商業與開源：最后的決策372
14.3JMX監控原理解析373
14.3.1JMX的體系結構374
14.3.2一個完整的JMX體系架構實例376
14.3.3通過JMX訪問WebLogicServerMBean379
14.4SNMP監控原理解析383
14.4.1SNMP協議解析：MIB庫與消息類型383
14.4.2使用SNMP4J實現服務器監控386
14.4.3Linux下的監控實現：NET—SNMP390
14.4.4MIB庫瀏覽工具：ManageEngine391
第15章運維管理392
15.1服務級別管理，IT與業務的一致性392
15.1.1客戶滿意度與期望393
15.1.2服務目錄——IT服務的菜譜396
15.1.3從宏觀到可操作性的服務397
15.2變更管理，使服務有效傳遞399
15.2.1變更控制的角色、階段399
15.2.2變更管理的六個原則401
15.2.3變更分類與風險定級402
15.2.4表單、步驟、模板與日歷405
15.3事件管理409
15.3.1分類管理與評價體系409
15.3.2任務分發、協同與時效411
15.3.3內部上報要求412
15.3.4重大事件處理413
15.4人員管理：開放與分享415
15.4.1企業社交管理415
15.4.2目標管理，做好績效417
15.4.3知識管理，人員成長417
15.4.4時間管理，個人效率420
15.5PaaS下的運維發展之路421

古往今來隨風去，書劍相伴兩袖空
筆者在運維領域耕耘十余載。2007年加入平安集團旗下的科技公司，2011年主導了業內最大的應用遷徙與架構變更，2012年開展IT運維管理變革，打通橫向條線，實現了技能融合。光陰荏苒，日月如梭，運維往事歷歷在目，我們流過汗，熬過夜，攤過事，也拿過獎，運維是一個從無到有、日積月累、不斷提升的過程，也是一個需要耐得住寂寞，頂得住壓力的行當，在此與正奮斗在運維一線的伙伴們共勉。
平安IT經歷了企業信息管理部、國際領先IT服務公司、互聯網金融三個歷史階段，每一次蛻變都緊隨時代步伐，擁抱技術革新，創造業務價值。從企業ERP、PC互聯、移動互聯、雲計算到大數據，運維人一直在奔襲，從未停歇。

企業信息管理時期的運維人飛行於各大城市的上空，每一次發版、變更就是一次長途遠行，分散的管理模式簡單直接，但隨着業務發展、規模擴大，企業對系統穩定性、運營成本控制的要求越來越高，隨之而來的是IT集中管理時期，這個時期追求一流的國際IT服務管理水平，構建獨立數據中心，實現開發架構、安全標准與運營規范的全面統一，該時期形成的IT管理實踐堪稱行業標桿。2013年全面進入互聯網金融時期，移動互聯、雲計算、大數據的火熱發展，業務渠道、流量入口、用戶終端的改變，促使我們又一次站在了歷史的新起點。

互聯網金融在運維方面上演了一場「雙城記」。一邊是充滿貴族氣質、為榮譽而戰的「英倫君主立憲」，在這個領域內嚴格執行IT管理規范，穩若磐石，滴水不漏，保證絕對穩定與安全；而另一邊是自由、民主喧嘩下的「法國大革命」，為了滿足互聯網下業務系統的高並發、高吞吐、版本多變的需求，應用不再拘泥於一致框架、規范與准則，多樣選擇，以快為先。

本書的核心內容就是在這樣的背景下誕生的，我們無法「一刀切」地構建承載所有應用類型的基礎環境，只有准確定義應用標准，以一種兼容並存的方式在應用架構上迭代地朝輕量級、微模塊方向發展，通過技術、管理雙層標准來調和「君主立憲」與「民主共和」之間的矛盾，轉化成優勢互補、經驗傳承、全面共贏，最終完成新時期的歷史使命。這個過程是無法一步到位、一蹴而就的，而是以一種螺旋式形態探索前進的，除了在原有管理規范上引入新技術探究，還需要開發同步配合在應用架構上進行改造，基礎架構將從環境運維逐漸轉變成平台研發，以提供功能粒度細、服務自助化的運維平台來滿足上層應用需求。

通明大道去浮華，千辛歷盡回本真
PaaS並不能解決IT運維的所有問題，它對應了「民主共和」的部分，提供了一個用戶自助的開放形式平台來滿足部分應用需求。PaaS也不是從一開始就從解決異地容災、流量切換等數據中心級別功能上設計的，而是在兼容當前企業應用架構、滿足資源分配、計算單元打包、版本發布控制等基礎功能后，再做進一步功能延伸的。PaaS並不是一種新興技術，而是對以往運維經驗的總結，利用容器等技術對開發、運維工作流的重新編排。

IT技術更新發展快，新詞匯層出不盡，特別是在雲計算、大數據、移動互聯下衍生了大量的產品，讓運維人應接不暇，剛剛掌握Hadoop，又出Spark，才標准化ActiveMQ，又有Kafka，OpenStack的IaaS體系才得以了解，又有各種平台下的PaaS……如果要熟練掌握每一門技藝，則將是一個疲於奔命的過程，而這個過程大部分都是表面的產品架構與配置，我們會發現一旦深入其中，所有技術卻看似一致。對於運維人員來說，亘古不變的始終是底層的三大基礎資源計算、存儲、網絡，這些知識包括：程序的鏈接、加載與運行；操作系統下的CPU、內存、I/O資源管理；基本的TCP/IP協議棧等。隨着技術層級越多、復雜性越高，運維人員只有透過眼花繚亂的「新技術」看到其內在一致的本質，在底層長期沉淀，理解好程序是如何調用三大基礎資源，找到運維技術的本真，才可以做到最終的不變應萬變，這也印證了運維是一個要耐得住寂寞的行當。

最后讓我們回到運維管理上，今年國內互聯網上發生了幾起影響比較嚴重的運維故障，一時間在圈內引起關於「再流弊的技術，也抵不過一次事故」等的科技雜談，可見管理在運維上的重要性。管理是一門藝術，而這門藝術在運維上並不是形而上學、趨於神秘主義的，也不是絕對的「封」「殺」「控」，以懷疑主義、不信任方式來管控的。

運維管理是人、流程與工具三方面的有機結合。「民主共和」型運維管理往往依賴於人的自覺性，而「君主立憲」則重在流程管控，朝兩個極端偏倚而忽視它們與工具的結合都將不能從根本上解決問題。我們會發現越是技術實力強、自信的人越容易犯運維錯誤，而再完善的流程制度，如果煩瑣到讓人感覺「無意義」，那也就無從執行了。

工具是人與流程之間的橋梁，但一定要注意這個工具不是管控的「枷鎖」，而是在滿足運維管理需求下關注一線運維人員用戶體驗的「幫手」。對於管理層，它是上層意志的體現，但對於一線運維人員，它是一個效率工具，除了包含精准配置信息、標准變更步驟，還要囊括人性的知識分享、社交互動等功能，它是為一線運維人員服務、以人為本的。

內容大綱
本書分為四大部分，分別是概念模型、基礎資源、平台實現與運維管理，共十五章。各部分之間沒有必然聯系，讀者可依據關注點和個人興趣來閱讀。對於需要系統化理解運維及PaaS的讀者，建議遵循本書的章節順序閱讀。

第一部分——概念模型：闡述了運維與開發之間的關系、這層關系存在的矛盾，以及PaaS是如何有效緩解其矛盾的。這部分介紹了公有PaaS平台的特征，以及其開放性與約束性，列出12-Factor規范來說明應用系統應當遵循的規則，這樣才能適應於在PaaS上運行。

第二部分——基礎資源：勾勒出了數據中心的計算、網絡、存儲三大資源的主干，避免讓人陷入上層的種種產品中。對於已熟悉數據中心三大資源的運維人員來說，本部分是資源的總體概述，讓你重拾內在本質。若你是一名運維新兵，則請以此為綱要尋找外部資源來繼續深入學習；開發人員可通過本部分了解到日常運維工作所管理對象的基本內容。

第三部分——平台實現：通過開源產品來構建一個完整的PaaS平台，包括資源管理、任務調度、計算單元打包、分布式協調、日志集中等。通過學習本部分的內容，讀者可以實現一個可擴展、自定義的開放PaaS平台，這個擴展部分包括了各自企業內部的集成部署流程、應用灰度發布、平台門戶管理等方方面面的內容。

第四部分——運維管理：對運維管理進行了實踐。運維管理的核心是配置管理，一個好用、易用的配置管理系統將直接影響上層監控管理、變更管理及事件管理，決定一個企業運維品質的好壞。

感謝
首先特別感謝我的太太李嘉，在過去一年里，寫作幾乎占用了我所有的周末及其他休息時間，你承擔起了家務，並對我與余多多悉心照顧，沒有你的理解、寬容與支持，本書無法完成。感謝姐夫喻立新、姐姐何碧，你們在本書插圖上給予了我很大的幫助。特別感謝饒琛琳、楊永幫利用周末進行審訂稿件，感謝梁山在12-Factor上對我的幫助，感謝策划編輯孫學瑛老師對我的鼓勵，感謝責任編輯蝦米（張國霞）的校對、排版與指導。

感謝我的公司平安科技，給予了我一個更大的平台，讓我馳騁在IT運維大草原上得以一覽全貌。感謝我的上級胡瑋、朱永忠、李毅對我工作的支持，感謝我的同事王欣、於泳、宋楹柯、藍景全、江銳、常明、黃文建、唐文祥、陳順星、彭俊清、陳春潤對我的幫助。感謝事件處理組的小伙伴們：王耀武、莫廣華、陳秋浩、鄭司營、趙寶磊、吳磊、林國峰、張浙棟、夏永燕、孟佩佩、羅穎勝、倪沛榆、丁江，感謝基礎架構籃球隊。感謝所有在互聯網上幫助過我的朋友們。
余何
2015年11月