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