大資料/交付的實用DevOps
在這本書中，我們一直專注於設計工作，而大多數情況下這些工作都在我們的IDE中進行。所有分析都在開發空間中進行，而且沒有執行一行程式碼。但是，設計和開發的目的是建立一個可以在某個資料中心或基礎設施上執行的應用程式，以便我們可以使用應用程式的功能。因此，在本章中，我們將研究安裝、啟動和測試應用程式的方法和工具。
在典型的模型驅動方式中，部署模型提供了應用程式的精確表示。使用 部署特定建模方法 是一個良好的開端。部署模型包含構成應用程式的所有部分，因此我們需要能夠讀取此模型並採取步驟來設定應用程式的工具。這些工具的預期結果是模型中描述的資源的例項化，這些資源被指定為與這些資源相關聯的服務所佔用。
在獲得能夠部署應用程式的工具之前，通常還有一個步驟：將模型轉換為目標工具可理解的格式。工具通常更喜歡一種更緊湊和針對性的語言，而不是UML表示，這種語言通常被稱為領域特定語言 (DSL)，[1] 用於準備DIA的藍圖。我們將使用OASIS TOSCA，[2] 這是一種新興的行業標準，用於描述可移植且可操作管理的雲應用程式。其優點之一是它能夠靈活地使用，並且能夠擴充套件可用術語以適合特定領域，例如大資料。
我們將用於部署DIA的工具需要提供對管理部署的簡單訪問，並需要提供可重複且可靠的DIA部署操作。
DIA由許多支援服務和技術組成，我們通常在這些服務和技術之上執行一些自定義使用者程式碼。DIA設定的複雜性是應用程式本身需求的函式。但是，無論我們有一個簡單的應用程式，它只將資料儲存在NoSQL儲存中，還是一個多層構建塊堆疊，都需要有人或某些東西來安裝和啟動所有元件。在DevOps環境中，我們使用雲編排工具[3] 來自動化此過程。
單獨的開源服務和工具附帶了有關如何設定和配置服務的詳細說明。手動執行此操作需要時間和技能，而這些時間和技能通常在剛開始進入資料密集型應用程式開發世界的團隊中缺乏。學習部署服務的需要與學習如何充分利用服務本身的需要大多是正交的。因此，任何幫助加快或完全取代部署步驟的措施都可能成為主要的節約時間和成本的因素。
在DevOps中自動執行部署過程的需要帶來了基礎設施即程式碼的概念，[4] 它能夠將整個平臺的藍圖儲存在版本化儲存庫（如GIT）中。這帶來的一個巨大好處是，我們對DIA部署後的樣子有一個單一的事實來源。
用TOSCA YAML編寫的藍圖可以包含組成DIA的各個元件的任何數量的詳細資訊。但是，就像傳統的應用程式原始碼一樣，藍圖也不應該重複可以在更低抽象級別表示的概念。這些可以打包到TOSCA庫中，該庫可以作為外掛匯入到每個藍圖中。
配置和部署的自動化並不新鮮，因為各種形式的批處理指令碼已經存在了幾十年。這傳統上是配置自動化的命令式方法，其中指令碼描述了需要按順序執行的一系列指令。一種更新但已經廣泛使用的方法是使用宣告式方法，我們專注於描述系統的期望狀態。
部署複雜系統的最佳方法是將流程分解，使不同的工具專注於系統的不同級別。從基礎設施級別開始，即計算、網路和儲存資源，我們可以從許多配置管理[5] 工具中進行選擇：Chef，[6] Puppet，[7] Ansible，[8] 等等。這些工具使用cookbook、playbook等名稱的定義作為安裝和配置過程的原始碼。然後，使用者或編排器會執行這些定義的單元（例如Chef cookbook的配方）以在系統的狀態之間進行轉換。
為了管理雲應用程式（如大資料應用程式），我們需要一種更高階的方法，它採用雲編排器[3] 的形式。一些配置管理器，如Ansible或Chef，已經具有一些編排功能。這確保了相互依賴項以正確的順序設定並配置為正確地互相發現。例如，Web應用程式需要首先配置Web伺服器，然後在另一個節點上設定並執行資料庫。這是由編排器工具完成的，其代表包括Ubuntu Juju，[9] Apache Brooklyn[10] 和Cloudify。 [11]
這些工具只是交付自動化的一個部分。另一個關鍵部分是配方、playbook、外掛和藍圖型別定義。每個工具都有一個供應商自己的社群或社群對配置和編排程式碼的大型儲存庫或市場進行的貢獻。以這種方式提供的材料的質量會有所不同，並且不同配方的相容性並不總是得到保證。但這是使用技術和原型製作進行初始實驗的有價值的來源，只要我們有時間研究每個cookbook或playbook。
DICE交付流程旨在使與編排的互動儘可能簡單。我們從TOSCA YAML格式的應用程式藍圖開始。我們可以自己編寫此文件，但遵循DICE方法並將部署特定模型使用DICER轉換為等效的YAML藍圖會更好。在每種情況下，藍圖看起來都類似於以下示例
tosca_definitions_version: cloudify_dsl_1_3
imports:
- https://github.com/dice-project/DICE-Deployment-Cloudify/releases/download/0.7.2/full.yaml
node_templates:
mongo_fw:
type: dice.firewall_rules.mongo.Common
standalone_vm:
type: dice.hosts.ubuntu.Medium
relationships:
- type: dice.relationships.ProtectedBy
target: mongo_fw
standalone_mongo:
type: dice.components.mongo.Server
properties:
monitoring:
enabled: true
relationships:
- type: dice.relationships.ContainedIn
target: standalone_vm
accounts_db:
type: dice.components.mongo.DB
properties:
name: accounts
relationships:
- type: dice.relationships.ContainedIn
target: standalone_mongo
outputs:
mongo_access:
description: Mongo client connection details
value:
concat:
- "mongo --host "
- get_attribute: [ standalone_mongo, fqdn ]
- :27017
此藍圖由節點模板組成，其型別基於DICE技術庫中的定義，例如
dice.hosts.ubuntu.Medium：表示中等大小的計算主機。dice.firewall_rules.mongo.Common：一個用於定義網路安全組或防火牆的節點型別，以便只有MongoDB通訊所需的埠是可訪問的，並且這包括對等引擎服務和任何客戶端。dice.components.mongo.Server：包含所有構成獨立 MongoDB 引擎例項的 MongoDB 相關模組的元件。dice.components.mongo.DB：代表 MongoDB 引擎中的資料庫。dice.components.mongo.User：MongoDB 叢集中的使用者。
許多節點模板需要與另一個節點模板建立關係。我們使用以下關係型別來實現這一點
dice.relationships.ProtectedBy：此關係的源是計算主機，目標是定義安全組或防火牆的 dice.firewall_rules 節點模板。dice.relationships.ContainedIn：可以將與服務相關的節點模板連線到計算主機，或將資料庫連線到 MongoDB 等資料庫引擎。dice.relationships.mongo.HasRightsToUse：允許源使用者節點模板使用目標資料庫節點模板。
更多 藍圖示例 可用。
部署服務概念
[edit | edit source]部署是在目標基礎設施中例項化藍圖。雲編排器可以生成一個或多個併發或序列（即，由於建立了新的部署，因此銷燬了前一個部署）部署。為了簡化部署管理，DICE 部署服務 使用虛擬部署容器的概念。提交到特定虛擬部署容器的藍圖將導致與該虛擬部署容器關聯的部署。提交到同一虛擬部署容器的新藍圖將導致一個新部署，該部署將替換上一個部署。
如上圖所示，藍圖 B.1 之前已部署在虛擬部署容器 2 中。但隨後使用者改進了應用程式，導致藍圖 B.2 出現。將此藍圖提交到虛擬部署容器 2 後，之前的部署已被刪除，並安裝了新的部署。此更改使虛擬部署容器 1 中的部署保持不變。使用者可以根據需要建立任意數量的容器，例如用於個人試驗新技術、持續整合中的特定分支，或用於對新版本進行手動驗收測試。
DICE 部署服務 和 DICE TOSCA 技術庫的另一個功能是它能夠部署到任何支援的雲基礎設施。在藍圖中，使用者可以指定要部署到的平臺型別（例如，OpenStack 或 Amazon EC2），並且這對於藍圖中的不同元件可以不同。對於未明確指定目標平臺的節點，DICE 部署服務使用其預設目標平臺。在這種情況下，相同的藍圖可以提交到不同的雲提供商，而無需更改藍圖。在上圖中，我們將藍圖 B2 提交到兩個不同的雲提供商。如所示，任何平臺特定輸入引數均由 DICE 部署服務提供。資料中心管理員負責將其設定為正確的值。另一方面，設計人員和開發人員不需要處理此類細節。
在幕後，實際的藍圖部署將提交到 RESTful 服務，該服務使用任何平臺特定的細節來增強藍圖。然後，實際的藍圖編排由 Cloudify 執行，[11] 它負責在執行部署工作流之前拉取技術庫和 Chef 食譜的相關元素。上圖說明了使此工作流成為可能的服務的體系結構。
開放性挑戰
[edit | edit source]所呈現的部署服務和 TOSCA 技術庫的結合極大地加快了應用程式的準備和設定，這些應用程式是由支援的技術組成的。但是，許多資料密集型應用程式將結合庫中支援的元件以外的其他第一方和第三方元件。
TOSCA 技術庫透過為自定義（bash 或 Python）指令碼提供節點型別來為某些自定義元素提供快捷方式。但這些僅適用於非常簡單的自定義。由於過於簡單，使用它們無法提供 TOSCA 藍圖的全部功能。結果是，此類藍圖中更大的部分成為強制性的，而不是本來必須的。解決此類問題的更簡潔方法是在庫級別應用擴充套件和更改，但這需要使用者具備更高的技能和知識。
DICE 交付工具集的主要優勢是它提供開源解決方案的部署，作為一個易於使用的構建塊集合。但同時，這也是一個弱點，因為庫中的定義僅與其提供者對其進行的更新一樣最新。由於這不是服務的原始供應商，因此採用者面臨落後於主流大資料服務發展的風險。
應用領域：已知用途
[edit | edit source]DICE 部署服務與 DICE TOSCA 技術庫相結合，可用於各種工作流。它還可輕鬆滿足各種大資料應用程式的需求。以下是一些建議用途。
Spark 應用程式
[edit | edit source]DICE TOSCA 技術庫包含構建塊，其中包括對 Apache Spark 的支援，[12] Apache Storm，[13] Hadoop[14] 檔案系統，Hadoop Yarn，Kafka，[15] Apache Zookeeper，[16] Apache Cassandra[17] 和 MongoDB。 [18] 這意味著任何需要這些技術子集的應用程式都可以用 TOSCA 藍圖表示並自動部署。
例如，Storm 應用程式藍圖 顯示瞭如何將所有必要成分一起表示
- 目標是部署和執行包含已編譯的 WordCount 拓撲 Java 程式碼的
.jar檔案。這封裝在wordcount節點模板中。 - 執行此程式的平臺由 Storm 節點組成：Storm Nimbus 節點（由
nimbus節點模板表示）和 Storm Worker（storm節點模板）。 - 為了使 Storm 正常工作，我們還需要在叢集中使用 Zookeeper。藍圖將其定義為
zookeeper節點模板。 - 所有這些服務都需要專用的計算資源才能執行：
zookeeper_vm、nimbus_vm和storm_vm。 - 在網路資源方面，藍圖定義了哪些埠需要開啟才能使服務正常工作：
zookeeper_security_group、nimbus_security_group、storm_security_group。為了方便起見，我們還在公共網路地址上釋出 Zookeeper 和 Storm Nimbus：zookeeper_floating_ip和nimbus_floating_ip。
使用持續整合的部署
[edit | edit source]DICE 部署服務是一個 Web 服務，但它也附帶一個 命令列工具。這使得從持續整合引擎中簡單地使用成為可能。在這裡，我們展示了 Jenkins[19] 管道[20] 的示例，該管道構建並部署了 Storm 應用程式。
pipeline {
agent any
stages {
stage('build-test') {
steps {
sh 'mvn clean assembly:assembly test'
}
}
stage('deploy') {
steps {
sh '''
dice-deploy-cli deploy --config $DDS_CONFIG \
$STORM_APP_CONTAINER \
blueprint.tar.gz
dice-deploy-cli wait-deploy --config $DDS_CONFIG \
$STORM_APP_CONTAINER
'''
}
}
}
}自動化部署的主要承諾是使操作人員的生活和工作更輕鬆。這種方法的力量在於它使大多數任務能夠自動完成 - 無需系統管理員過多幹預。這對應用程式交付速度有巨大的積極影響。我們幾乎可以談論 NoOps 方法，在這種方法中，系統操作員只需要設定服務並在基礎設施的資源池中配置必要的配額。從這一點開始，開發人員或測試人員可以以自助方式使用交付工具。
此外，能夠一致且可重複地部署相同應用程式是能夠將應用程式的（重新）部署整合到更大的工作流中的重要因素。特別是，它使持續整合成為可能，在這種情況下，只要開發人員將新更新推送到儲存庫分支，應用程式就會重新部署到測試平臺。該應用程式也可以定期測試，安裝和清理都是工作流程的一部分。這為執行質量測試（如本書後面所述）和整合測試提供了許多可能性。