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