是DevOps還是彼此割裂?Docker、OpenStack，還有配置即服務
【原文編者的話】：
這是Mirantis.com網站系列技術連載文章的***篇，主要介紹了針對DevOps模式，OpenStack可以做哪些事情?相比Kubernetes、Mesos這些容器管理工具，通過OpenStack Heat項目所能夠實現的功能與場景。
風頭正勁的Docker和圍繞其展開的宣傳活動揭示了開發者向云轉型的一個關鍵性動機，即人們不愿意在繁瑣的配置上花費過多的精力。為應用設置網絡許可權限、操作系統的兼容性、庫對服務的依賴性、數據持久性的要求、注冊表項，以及讓Docker正常運行的各項重要參數都讓用戶感到非常頭疼。聽起來似乎OpenStack和DevOps更勝一籌。
是的，OpenStack可以提供必需的自動化，詳細易懂的ReST API能夠讓配置安全地暴露在幾乎所有的管理工具或是開發環境中。DevOps目前相處得非常融洽。找一本關于亞馬遜的DevOps書籍，讓開發人員閱讀它們。開發人員負責創建，運營人員負責管理。
讓我們仔細看一下DevOps神話將我們引入歧途的方式。這些方式包括：
- 讓開發人員從事所有軟件定義的東西;
- Docker vs DevOps;
- 編排的問題;
- OpenStack Heat項目和Murano項目是如何幫助開發者解決這一問題的;
我們是如何陷入爛攤子的?
對于開發者來說，針對底層云服務的所有優秀ReST API，似乎是一件可將OpenStack變成殺手級應用的秘密武器。選擇你的虛擬機、網絡配置、存儲(可以隨意調整它們)，選擇動態遷移，然后迅速執行。整個數據中心都是你手中的玩具。開發者可以通過軟件定義數據中心，挑選適合他們應用的資源，確保企業在軟件經濟時代能夠從IT中獲得價值。
然而不幸的是，依靠應用來決定構成主機環境的硬件和操作系統，使得“以應用為中心”的解決方案成為了導致現代企業IT陷入混亂的主要原因。通過讓開發者編寫數據中心API的方式，讓開發者去承擔軟件經濟中的競爭責任，似乎注定要以失敗收場。
為什么會如此艱難呢?每次配置一個Linux服務器來運行一個應用看起來是非常容易的。但是在第二次、第三次和第四次之后，任何稱職的開發者都希望讓管理員來接手這一工作。那么配置一個由相互關聯的虛擬機(每一臺虛擬機都運行自己的服務)組成的大型云架構，或是配置一個頻繁變化的云架構，情況又是什么樣子呢?
問題會接踵而至。正如我們所看到的一樣，讓開發者通過填寫IT表單和申請基礎設施，來解決這個問題是不會有什么效果的。(不幸的是，目前這種做法非常普遍。)這種情況需要的是一個更程序化的解決方案。這給了OpenStack一個用武之地。
DOCKER VS. DevOps
軟件定義數據中心需要多少編程工作呢?如果問一下開發者，他們的回答是寧愿沒有。編寫docker pull oraclelinux勝過詳細規定30多個啟動參數。然而，運行甲骨文的人可能未必會重新部署一個純粹基于docker的云。OpenStack不能讓這一切變得簡單起來嗎?
容器中的應用Docker化會涉及許多方面。它們的特色功能之一就是，可以通過dockerfile簡化配置。在這種比較詳細的結構中，設置運行時配置可以緩解這個問題，至少對于容器化環境是這樣的。
但是關于DevOps的討論在很大程度上被引向了一個錯誤的方向。DevOps的本意是協調開發者和運營者的利益，其中所蘊含的文化就是彼此互相尊重。但是我所聽到的這類討論似乎都是在說“運營者來自火星，而開發者來自金星”。
雙方的差異是難以調和或者是克服的。開發者是以代碼為導向，而運營者則是以腳本為導向。實現方面，OpenStack在其出現的4年半時間里，能夠克服許多差異，主要是因為開發者認為，他們能夠通過程序解決所有的運營問題。即便是Cloud Foundry這樣的PaaS環境，也必須采取一些非中立的舉措以解決簡化配置，防止開發者陷入配置混亂的困境當中。由于云原生應用12個因素(創建 SaaS應用的重要方法論)的限制，我們根本無法對其徹底重新編寫。因此IT仍然存在難以逾越的叢林地帶。
運營者從開發者那里學到的經驗是對待配置的方式。Docker通過一種很好的方式為人們帶來了希望。
#p#
不要考慮編排，要使用Heat
對于許多公司來說，尋找和部署能夠在OpenStack上運行的工作負載，存在的挑戰是——該技術存在部署的障礙。存在于現有系統中的許多企業價值(以及它們所支持的人和程序)，使得它們無法很容易地向云或是向軟件定義數據中心轉型。
在OpenStack開發者那里泊來的術語中，“編排”(Orchestration)這個詞在這里會產生很大的誤解。它們是指序列化依賴關系所產生的復雜活動順序。而Heat圍繞的不是順序，而是狀態。
我們同樣需要明確“配置”(Configuration)這一術語的含義。它們不是指一個活動，而是指一種狀態。在云基礎設施中，它們是處理配置的***方式。因為配置的初始狀態是所有應用啟動的關鍵點。這代表著一個重要變化，即在部署、配置和運營領域中有許多必需的東西。例如，Chef、 Puppet、Ansible、SaltStack等部署工具是編輯復雜操作順序的前提，目的是讓它們具有可重復性。
但是確保可重復性的最可靠辦法是——消除活動組件。OpenStack編排項目Heat被設計用于專門解決該問題。在計算術語中，Heat 編排模板(HOT，Heat Orchestration Template)為陳述性的，而非是強制性的。
Heat編排模板(HOT)不包括順序信息，相反其可被解讀為固定時間點上的一種固定狀態。在這里，“編排”更像是在音樂會中所起的作用，一方面它們有點像樂譜。它們為每個服務分配角色、價值，以及在OpenStack云中的參數。另一方面，它們又不完全像樂譜，除非整個樂隊只演奏一個音符。
Heat模板和dockerfile的角色有點相似，但是它們之間有一個關鍵性區別。那就是dockerfile的范圍為一個單個的機器鏡像，而 Heat的范圍則是一個完備的IaaS環境，其中包括豐富的網絡選項、存儲、分布式處理流程等。還有一點就是，Heat模板適用于CRUD操作，所以我們可通過版本管理對簡單配置進行前滾和后滾。
換句話說，這是“配置代碼化”(configuration as code)的一個錨點，套用時髦的話說就是“配置即服務”(configuration-as-a-service)。與dockerfile相似的地方是，Heat為運行服務所需的配置提供了一個明確的定義。Docker傳遞給DevOps世界最有價值的經驗是：每一個Docker容器都有一個確定且透明的dockerfile。對于每一個OpenStack工作負載，要有一個確定且透明的Heat模板。換而言之，應用部署要與其配置捆綁在一起。
與Docker不同的地方是，Heat從事的是多個底層服務，而不是陳述單個虛擬機的需求及其關聯性。多個Docker容器需要一個配置集嗎?正如我們之前在其他地方所說的那樣，這是PaaS要做的事情。Kubernetes能夠做這樣的工作。Mesos也能夠做這樣的工作。但總的來說，OpenStack為這些服務的運行提供了一個更加通用的平臺。
編者注：本次編譯自Mirantis.com官方網站，作者為David Fishman，編譯者范范。本系列文章所關注的下一個主題是“在OpenStack當中，與docker pull對等的東西是什么?”，該文章將于近期發布。
