以Docker為代表的應(yīng)用程序容器方案將恒定鏡像等最佳實(shí)踐變?yōu)楝F(xiàn)實(shí)，同時(shí)允許DevOps與平臺(tái)技術(shù)團(tuán)隊(duì)各自關(guān)注不同的工作重點(diǎn)，而這無疑將DevOps生產(chǎn)效率提升到了新的高度。在今天的文章中，我們將探討容器技術(shù)如何簡(jiǎn)化全面自動(dòng)化的持續(xù)交付流程，其全面涵蓋從代碼提交到生產(chǎn)環(huán)境下代碼運(yùn)行的一切實(shí)際場(chǎng)景。我們還將了解跨越持續(xù)集成/持續(xù)交付流程中的容器定義與管理最佳實(shí)踐，并審視各類新型應(yīng)用特性的部署、測(cè)試與發(fā)布。

[[162791]]

容器鏡像與標(biāo)簽

應(yīng)用程序容器的生命周期跨越整個(gè)開發(fā)與運(yùn)營(yíng)流程，而容器鏡像本身相當(dāng)于開發(fā)與運(yùn)營(yíng)之間的協(xié)議。在典型周期當(dāng)中，開發(fā)階段我們需要進(jìn)行代碼更新、單元測(cè)試以及容器鏡像構(gòu)建等一系列任務(wù)。該容器鏡像隨后能夠被推送至中央庫(kù)當(dāng)中。接下來，在執(zhí)行測(cè)試或者部署應(yīng)用程序的同時(shí)，容器鏡像可被隨時(shí)從中央庫(kù)中提取出來。

因此該鏡像通過進(jìn)行多次更新，并根據(jù)版本迭代做出變更，從而實(shí)現(xiàn)高效管理。舉例來說，Docker鏡像會(huì)利用層與寫入內(nèi)容復(fù)制機(jī)制以保證鏡像每次更新時(shí)只變動(dòng)其中發(fā)生變更的部分。

在Docker概念當(dāng)中，容器鏡像被保存在一套鏡像注冊(cè)表當(dāng)中，或者簡(jiǎn)稱為注冊(cè)表(同樣的機(jī)制亦被稱為Docker Hub、谷歌容器注冊(cè)表、Quay等等)。在一套注冊(cè)表中，每套應(yīng)用程序容器都擁有自己的鏡像庫(kù)，且其中包含多個(gè)標(biāo)簽。

Docker允許管理員為單一容器鏡像設(shè)定多個(gè)標(biāo)簽。大家可以將這些標(biāo)簽視為一個(gè)命名指針，其指向單一鏡像ID。標(biāo)簽的作用是提供基元以管理整個(gè)交付流程中的各容器鏡像。

截止目前，Docker標(biāo)簽具備可變屬性。這意味著一個(gè)標(biāo)簽可隨時(shí)間推移指向其它不同鏡像。舉例來說，“latest”標(biāo)簽通常被用于指代最新可用鏡像。盡管我們能夠很方便地變更標(biāo)簽所指向的具體鏡像，但這同時(shí)也帶來了新的問題，即單一標(biāo)簽往往無法保證始終指向同一鏡像。

社區(qū)方面已經(jīng)就此提出要求，主張?jiān)贒ocker當(dāng)中提供恒定標(biāo)簽功能，或者允許使用者利用恒定的鏡像ID進(jìn)行鏡像提取。在這些問題得到解決之前，目前的最佳實(shí)踐就是以自動(dòng)化方式進(jìn)行標(biāo)簽管理，同時(shí)建立一套嚴(yán)格的命名機(jī)制從而將可變標(biāo)簽從恒定標(biāo)簽中剝離出來。

構(gòu)建恒定容器鏡像

在使用應(yīng)用程序容器時(shí)，開發(fā)人員通常會(huì)編寫代碼并在自己的筆記本設(shè)備上以本地方式運(yùn)行單元測(cè)試。此外，開發(fā)人員還可以構(gòu)建容器鏡像，但這些鏡像可能尚未做好供其他團(tuán)隊(duì)成員使用的準(zhǔn)備，因此其并不會(huì)被真正推送到鏡像注冊(cè)表當(dāng)中。

目前的最佳實(shí)踐在于利用自動(dòng)化步驟對(duì)應(yīng)用程序進(jìn)行容器化，并將其作為代碼庫(kù)中的組成部分。對(duì)于Docker而言，這些步驟會(huì)在Dockerfile當(dāng)中進(jìn)行定義，而Dockerfile則可同代碼一同進(jìn)行檢查。當(dāng)變更提交完成后，以Jenkins或者Bamboo為代表的構(gòu)建編排工具能夠構(gòu)建并標(biāo)記容器鏡像，而后將鏡像推送至一套共享式鏡像注冊(cè)表當(dāng)中。

通過這種方式，每套build能夠?yàn)槲覀兊膽?yīng)用程序組件創(chuàng)建一個(gè)恒定鏡像，而此鏡像能夠囊括一切在任意能夠托管容器的系統(tǒng)之上運(yùn)行該組件的必要元素。該鏡像不應(yīng)要求任何其它配置管理或者安裝步驟。盡管從表面上看，為每一套build創(chuàng)建一套恒定鏡像似乎有點(diǎn)浪費(fèi)資源，但像Docker這樣的容器引擎能夠優(yōu)化鏡像管理，并利用按寫入復(fù)制等技術(shù)保證不同build之間只有變更內(nèi)容得到更新。

盡管應(yīng)用程序組件并不需要每次部署都進(jìn)行重新配置，但也許部分配置數(shù)據(jù)在組件運(yùn)行中有其必要作用。這種配置信息最好進(jìn)行外部化，同時(shí)注入到運(yùn)行時(shí)當(dāng)中以支撐該容器。容器部署與運(yùn)行工具應(yīng)當(dāng)允許這些配置信息作為環(huán)境變量進(jìn)行注入，同時(shí)以動(dòng)態(tài)方式注入配置信息以保障不同服務(wù)之間的運(yùn)行依賴關(guān)系。舉例來說，在Nirmata中創(chuàng)建環(huán)境時(shí)，我們可以利用將環(huán)境變量添加至一到兩項(xiàng)服務(wù)當(dāng)中。

容器感知部署流程

部署流程由多個(gè)步驟構(gòu)成，這些步驟負(fù)責(zé)分別實(shí)現(xiàn)執(zhí)行、構(gòu)建、測(cè)試以及將代碼發(fā)布至生產(chǎn)環(huán)境。這些步驟亦可根據(jù)階段進(jìn)行組織，而各階段則可實(shí)現(xiàn)全面自動(dòng)化或者要求特定人工步驟介入。

一旦大家已經(jīng)開始使用應(yīng)用程序容器，那么整個(gè)部署流程就需要識(shí)別容器鏡像與標(biāo)簽。最重要的了解容器鏡像目前正處于部署流程中的哪個(gè)階段。大家可以通過以下方式實(shí)現(xiàn)這項(xiàng)目標(biāo)：

1. 在流程當(dāng)中定義階段與環(huán)境類型。

2. 為恒定鏡像標(biāo)簽設(shè)定一套命名規(guī)則，其將應(yīng)用至由該構(gòu)建工具生成的每套鏡像當(dāng)中。該標(biāo)簽應(yīng)當(dāng)始終保持不變：

例如 {YYYYMMDD}_{build number}

3. 為將被環(huán)境所接受的鏡像標(biāo)簽設(shè)定命名規(guī)則：

例如 {environment name}_latest

4. 為將在部署流程當(dāng)中被環(huán)境繼承至下一階段的鏡像標(biāo)簽定義命名規(guī)則。

例如 {next environment name}_latest

利用這些規(guī)則，每套容器鏡像都能夠擁有至少2個(gè)標(biāo)簽，這些標(biāo)簽將被用于定義并追蹤對(duì)應(yīng)容器鏡像在整個(gè)部署流程當(dāng)中的開發(fā)進(jìn)度：

1. 當(dāng)該鏡像構(gòu)建完成且永不變更時(shí)，為其分配一個(gè)獨(dú)特的恒定標(biāo)簽。
2. 設(shè)定可變標(biāo)簽以標(biāo)記鏡像在部署流程當(dāng)中所處的具體階段。

應(yīng)用程序容器交付與生命周期管理工具，現(xiàn)在已經(jīng)能夠利用這些信息以治理并管理自動(dòng)化部署流程。舉例來說，在Nirmata當(dāng)中大家可以定義環(huán)境類型以表明部署流程中的各個(gè)階段，而標(biāo)簽命名規(guī)則則用于標(biāo)記哪些標(biāo)簽可被納入各個(gè)環(huán)境類型以及如何利用命名標(biāo)簽實(shí)現(xiàn)源自環(huán)境類型的鏡像繼承。

更新應(yīng)用程序容器

截至目前，我們已經(jīng)討論了如何構(gòu)建容器鏡像并在部署流程當(dāng)中管理容器鏡像。下一步要做的就是在單一或者多套環(huán)境當(dāng)中實(shí)現(xiàn)應(yīng)用程序更新。在這一章節(jié)當(dāng)中，我們將探討容器機(jī)制怎樣通過最佳實(shí)踐實(shí)現(xiàn)應(yīng)用程序的跨環(huán)境更新。

微服務(wù)

微服務(wù)是一種架構(gòu)類型，其中一款應(yīng)用程序會(huì)被拆分成多項(xiàng)獨(dú)立服務(wù)，而每項(xiàng)服務(wù)在設(shè)計(jì)上具備彈性、靈活性、可組合能力、最小化以及完整性。微服務(wù)能夠隨企業(yè)與軟件代碼庫(kù)的發(fā)展實(shí)現(xiàn)規(guī)?；h(huán)境下的敏捷需求，同時(shí)也開始逐步成為越來越多企業(yè)應(yīng)用程序的首選架構(gòu)解決方案。

容器在部署與運(yùn)行速度方面擁有突出優(yōu)勢(shì)。由于其軟件包與系統(tǒng)擁有輕量化特性，因此容器就成了微服務(wù)的理想交付載體——只要該服務(wù)目前能夠運(yùn)行在其容器環(huán)境中，那么每項(xiàng)獨(dú)立服務(wù)都擁有自己的容器鏡像與實(shí)例。

微服務(wù)類應(yīng)用程序的一大優(yōu)勢(shì)在于其擁有細(xì)顆度版本控制與發(fā)布管理能力，因此每項(xiàng)服務(wù)都能夠獨(dú)立實(shí)現(xiàn)版本控制與更新。在微服務(wù)方案的幫助下，相較于以往對(duì)包含大量變更內(nèi)容的整體系統(tǒng)進(jìn)行測(cè)試與重新部署，如今我們可以更加安全地為生產(chǎn)系統(tǒng)實(shí)現(xiàn)增量式變更。另外在合適工具的輔助下，我們也能夠同時(shí)運(yùn)行同一服務(wù)的多個(gè)版本，并根據(jù)不同服務(wù)版本的實(shí)際表現(xiàn)管理客戶請(qǐng)求。

藍(lán)-綠部署

所謂藍(lán)-綠部署(有時(shí)候也被稱為紅-黑部署)是一類發(fā)布管理最佳實(shí)踐，其允許我們根據(jù)潛在問題進(jìn)行快速恢復(fù)。當(dāng)執(zhí)行藍(lán)-綠更新時(shí)，新版本(也就是‘綠’)會(huì)在發(fā)布的同時(shí)繼續(xù)保持現(xiàn)有版本(也就是‘藍(lán)’)的正常運(yùn)行，此外通過對(duì)上游負(fù)載均衡或者DNS服務(wù)的更新將流量轉(zhuǎn)發(fā)至“綠”版本當(dāng)中。這種部署方式的優(yōu)勢(shì)在于，一旦發(fā)生問題，大家可以輕松將流量重新引導(dǎo)至仍處于正常運(yùn)行狀態(tài)的“藍(lán)”版本處。

容器技術(shù)的出現(xiàn)使得藍(lán)-綠部署機(jī)制速度更快且更易于執(zhí)行。由于容器能夠提供恒定鏡像，因此其始終能夠保護(hù)回滾至前一鏡像版本的能力。另外，由于鏡像管理功能經(jīng)過優(yōu)化，我們能夠在數(shù)秒之內(nèi)完成整個(gè)回滾流程。

不過，容器機(jī)制的真正價(jià)值在于大家可以將藍(lán)-綠部署方案同微服務(wù)類應(yīng)用程序加以結(jié)合。如今已經(jīng)有多種獨(dú)立服務(wù)能夠利用這項(xiàng)最佳實(shí)踐，而其也將在未來幫助更多管理員降低變更影響范疇并控制潛在錯(cuò)誤。

金絲雀啟動(dòng)

金絲雀啟動(dòng)機(jī)制在創(chuàng)新方面要比藍(lán)-綠部署更進(jìn)一步，其能夠?yàn)樯a(chǎn)系統(tǒng)提供更為安全的變更部署效果。在使用藍(lán)-綠部署方案時(shí)，用戶通常需要從應(yīng)用程序組件的藍(lán)或者綠版本中做出選擇，而金絲雀啟動(dòng)則能夠同時(shí)運(yùn)行新版本與舊版本，且只有指定用戶能夠接觸到其中的新版本。這就使得我們可以及時(shí)糾正新版本中存在的問題，并在確保一切正常之后才將其發(fā)送給更多用戶。

舉例來說，我們可以將某項(xiàng)服務(wù)升級(jí)至新版本(例如6.1版本)，但只允許內(nèi)部或者測(cè)試用戶對(duì)該服務(wù)進(jìn)行調(diào)用。如果該項(xiàng)服務(wù)的新版本擁有穩(wěn)定的運(yùn)行表現(xiàn)，那么大家能夠?qū)⒁恍〔糠稚a(chǎn)流量引導(dǎo)至該版本當(dāng)中。隨著時(shí)間推移，這一比例或者生產(chǎn)性流量總量逐步提升，而舊版本則慢慢被淘汰出局。

雖然容器本身并不是實(shí)現(xiàn)及管理金絲雀啟動(dòng)機(jī)制的必要前提，但其確實(shí)能夠幫助我們實(shí)現(xiàn)更新策略的標(biāo)準(zhǔn)化與自動(dòng)化。舉例來說，Nirmata允許用戶選定一套立足于不同環(huán)境基礎(chǔ)的服務(wù)更新處理方案。用戶也可以輕松選擇如何通知并手動(dòng)觸發(fā)更新回滾，選擇添加新版本并確保其與現(xiàn)有版本協(xié)同運(yùn)作，或者選擇通過滾動(dòng)更新替代現(xiàn)有版本。

環(huán)境現(xiàn)在將以一次性方式存在

云計(jì)算令軟件定義基礎(chǔ)設(shè)施快速興趣，并允許我們將服務(wù)器轉(zhuǎn)化為一次性資源實(shí)體。容器則將這種趨勢(shì)推進(jìn)至新的高度。容器擁有卓越的部署與啟動(dòng)速度，而且在正確編排與自動(dòng)化工具的輔助下，大家現(xiàn)在可以將整套環(huán)境視為按需與一次性功能實(shí)體。

雖然生產(chǎn)環(huán)境還將在相當(dāng)長(zhǎng)的歷史時(shí)期當(dāng)中持續(xù)存在，但新型方案確實(shí)能夠在開發(fā)與測(cè)試環(huán)境下發(fā)揮重要優(yōu)勢(shì)，且通過一鍵式操作實(shí)現(xiàn)重新創(chuàng)建?，F(xiàn)在，部署流程可以與自動(dòng)化測(cè)試機(jī)制相對(duì)接，包括其中的環(huán)境啟動(dòng)、測(cè)試運(yùn)行以及環(huán)境測(cè)試成功判斷等等。

總結(jié)陳詞

容器已經(jīng)快速興起并成為DevOps與持續(xù)交付工作中的一項(xiàng)基礎(chǔ)性工具。伴隨著微服務(wù)類架構(gòu)，容器技術(shù)能夠甚至足以幫助我們?cè)谡捉桓读鞒讨欣米罴褜?shí)踐管理應(yīng)用程序組件——從代碼提交至生產(chǎn)運(yùn)行皆涵蓋于其中。

盡管容器技術(shù)能夠解決一系列關(guān)鍵性難題，但其同時(shí)也需要新的工具手段以實(shí)現(xiàn)應(yīng)用程序的自動(dòng)化與管理任務(wù)。下一代應(yīng)用程序交付與管理解決方案能夠?qū)F(xiàn)有容器作為一種標(biāo)準(zhǔn)化構(gòu)建單元，從而將自動(dòng)化全面引入應(yīng)用程序生命周期。在我看來，這種不同技術(shù)成果的結(jié)合將幫助大家迎來新的生產(chǎn)力發(fā)展水平及更先進(jìn)的軟件工程能力，從而滿足不同領(lǐng)域當(dāng)中持續(xù)增長(zhǎng)的軟件產(chǎn)品與設(shè)備需求。

原文標(biāo)題：Continuous Delivery for Containerized Applications

【51CTO.com獨(dú)家譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明來源】