以Docker為代表的應用程序容器方案將恒定鏡像等最佳實踐變為現實，同時允許DevOps與平臺技術團隊各自關注不同的工作重點，而這無疑將DevOps生產效率提升到了新的高度。在今天的文章中，我們將探討容器技術如何簡化全面自動化的持續交付流程，其全面涵蓋從代碼提交到生產環境下代碼運行的一切實際場景。我們還將了解跨越持續集成/持續交付流程中的容器定義與管理最佳實踐，并審視各類新型應用特性的部署、測試與發布。
容器鏡像與標簽
應用程序容器的生命周期跨越整個開發與運營流程，而容器鏡像本身相當于開發與運營之間的協議。在典型周期當中，開發階段我們需要進行代碼更新、單元測試以及容器鏡像構建等一系列任務。該容器鏡像隨后能夠被推送至中央庫當中。接下來，在執行測試或者部署應用程序的同時，容器鏡像可被隨時從中央庫中提取出來。
因此該鏡像通過進行多次更新，并根據版本迭代做出變更，從而實現高效管理。舉例來說，Docker鏡像會利用層與寫入內容復制機制以保證鏡像每次更新時只變動其中發生變更的部分。
在Docker概念當中，容器鏡像被保存在一套鏡像注冊表當中，或者簡稱為注冊表(同樣的機制亦被稱為Docker Hub、谷歌容器注冊表、Quay等等)。在一套注冊表中，每套應用程序容器都擁有自己的鏡像庫，且其中包含多個標簽。
Docker允許管理員為單一容器鏡像設定多個標簽。大家可以將這些標簽視為一個命名指針，其指向單一鏡像ID。標簽的作用是提供基元以管理整個交付流程中的各容器鏡像。
截止目前，Docker標簽具備可變屬性。這意味著一個標簽可隨時間推移指向其它不同鏡像。舉例來說，“latest”標簽通常被用于指代最新可用鏡像。盡管我們能夠很方便地變更標簽所指向的具體鏡像，但這同時也帶來了新的問題，即單一標簽往往無法保證始終指向同一鏡像。
社區方面已經就此提出要求，主張在Docker當中提供恒定標簽功能，或者允許使用者利用恒定的鏡像ID進行鏡像提取。在這些問題得到解決之前，目前的最佳實踐就是以自動化方式進行標簽管理，同時建立一套嚴格的命名機制從而將可變標簽從恒定標簽中剝離出來。
構建恒定容器鏡像
在使用應用程序容器時，開發人員通常會編寫代碼并在自己的筆記本設備上以本地方式運行單元測試。此外，開發人員還可以構建容器鏡像，但這些鏡像可能尚未做好供其他團隊成員使用的準備，因此其并不會被真正推送到鏡像注冊表當中。
目前的最佳實踐在于利用自動化步驟對應用程序進行容器化，并將其作為代碼庫中的組成部分。對于Docker而言，這些步驟會在Dockerfile當中進行定義，而Dockerfile則可同代碼一同進行檢查。當變更提交完成后，以Jenkins或者Bamboo為代表的構建編排工具能夠構建并標記容器鏡像，而后將鏡像推送至一套共享式鏡像注冊表當中。
通過這種方式，每套build能夠為我們的應用程序組件創建一個恒定鏡像，而此鏡像能夠囊括一切在任意能夠托管容器的系統之上運行該組件的必要元素。該鏡像不應要求任何其它配置管理或者安裝步驟。盡管從表面上看，為每一套build創建一套恒定鏡像似乎有點浪費資源，但像Docker這樣的容器引擎能夠優化鏡像管理，并利用按寫入復制等技術保證不同build之間只有變更內容得到更新。
盡管應用程序組件并不需要每次部署都進行重新配置，但也許部分配置數據在組件運行中有其必要作用。這種配置信息最好進行外部化，同時注入到運行時當中以支撐該容器。容器部署與運行工具應當允許這些配置信息作為環境變量進行注入，同時以動態方式注入配置信息以保障不同服務之間的運行依賴關系。舉例來說，在Nirmata中創建環境時，我們可以利用將環境變量添加至一到兩項服務當中。
容器感知部署流程
部署流程由多個步驟構成，這些步驟負責分別實現執行、構建、測試以及將代碼發布至生產環境。這些步驟亦可根據階段進行組織，而各階段則可實現全面自動化或者要求特定人工步驟介入。
一旦大家已經開始使用應用程序容器，那么整個部署流程就需要識別容器鏡像與標簽。最重要的了解容器鏡像目前正處于部署流程中的哪個階段。大家可以通過以下方式實現這項目標：
1. 在流程當中定義階段與環境類型。
2. 為恒定鏡像標簽設定一套命名規則，其將應用至由該構建工具生成的每套鏡像當中。該標簽應當始終保持不變：
例如 {YYYYMMDD}_{build number}
3. 為將被環境所接受的鏡像標簽設定命名規則：
例如 {environment name}_latest
4. 為將在部署流程當中被環境繼承至下一階段的鏡像標簽定義命名規則。
例如 {next environment name}_latest
利用這些規則，每套容器鏡像都能夠擁有至少2個標簽，這些標簽將被用于定義并追蹤對應容器鏡像在整個部署流程當中的開發進度：
當該鏡像構建完成且永不變更時，為其分配一個獨特的恒定標簽。
設定可變標簽以標記鏡像在部署流程當中所處的具體階段。
應用程序容器交付與生命周期管理工具，現在已經能夠利用這些信息以治理并管理自動化部署流程。舉例來說，在Nirmata當中大家可以定義環境類型以表明部署流程中的各個階段，而標簽命名規則則用于標記哪些標簽可被納入各個環境類型以及如何利用命名標簽實現源自環境類型的鏡像繼承。
更新應用程序容器
截至目前，我們已經討論了如何構建容器鏡像并在部署流程當中管理容器鏡像。下一步要做的就是在單一或者多套環境當中實現應用程序更新。在這一章節當中，我們將探討容器機制怎樣通過最佳實踐實現應用程序的跨環境更新。
微服務
微服務是一種架構類型，其中一款應用程序會被拆分成多項獨立服務，而每項服務在設計上具備彈性、靈活性、可組合能力、最小化以及完整性。微服務能夠隨企業與軟件代碼庫的發展實現規模化環境下的敏捷需求，同時也開始逐步成為越來越多企業應用程序的首選架構解決方案。
容器在部署與運行速度方面擁有突出優勢。由于其軟件包與系統擁有輕量化特性，因此容器就成了微服務的理想交付載體——只要該服務目前能夠運行在其容器環境中，那么每項獨立服務都擁有自己的容器鏡像與實例。
微服務類應用程序的一大優勢在于其擁有細顆度版本控制與發布管理能力，因此每項服務都能夠獨立實現版本控制與更新。在微服務方案的幫助下，相較于以往對包含大量變更內容的整體系統進行測試與重新部署，如今我們可以更加安全地為生產系統實現增量式變更。另外在合適工具的輔助下，我們也能夠同時運行同一服務的多個版本，并根據不同服務版本的實際表現管理客戶請求。
藍-綠部署
所謂藍-綠部署(有時候也被稱為紅-黑部署)是一類發布管理最佳實踐，其允許我們根據潛在問題進行快速恢復。當執行藍-綠更新時，新版本(也就是‘綠’)會在發布的同時繼續保持現有版本(也就是‘藍’)的正常運行，此外通過對上游負載均衡或者DNS服務的更新將流量轉發至“綠”版本當中。這種部署方式的優勢在于，一旦發生問題，大家可以輕松將流量重新引導至仍處于正常運行狀態的“藍”版本處。
容器技術的出現使得藍-綠部署機制速度更快且更易于執行。由于容器能夠提供恒定鏡像，因此其始終能夠保護回滾至前一鏡像版本的能力。另外，由于鏡像管理功能經過優化，我們能夠在數秒之內完成整個回滾流程。
不過，容器機制的真正價值在于大家可以將藍-綠部署方案同微服務類應用程序加以結合。如今已經有多種獨立服務能夠利用這項最佳實踐，而其也將在未來幫助更多管理員降低變更影響范疇并控制潛在錯誤。
金絲雀啟動
金絲雀啟動機制在創新方面要比藍-綠部署更進一步，其能夠為生產系統提供更為安全的變更部署效果。在使用藍-綠部署方案時，用戶通常需要從應用程序組件的藍或者綠版本中做出選擇，而金絲雀啟動則能夠同時運行新版本與舊版本，且只有指定用戶能夠接觸到其中的新版本。這就使得我們可以及時糾正新版本中存在的問題，并在確保一切正常之后才將其發送給更多用戶。
舉例來說，我們可以將某項服務升級至新版本(例如6.1版本)，但只允許內部或者測試用戶對該服務進行調用。如果該項服務的新版本擁有穩定的運行表現，那么大家能夠將一小部分生產流量引導至該版本當中。隨著時間推移，這一比例或者生產性流量總量逐步提升，而舊版本則慢慢被淘汰出局。
雖然容器本身并不是實現及管理金絲雀啟動機制的必要前提，但其確實能夠幫助我們實現更新策略的標準化與自動化。舉例來說，Nirmata允許用戶選定一套立足于不同環境基礎的服務更新處理方案。用戶也可以輕松選擇如何通知并手動觸發更新回滾，選擇添加新版本并確保其與現有版本協同運作，或者選擇通過滾動更新替代現有版本。
環境現在將以一次性方式存在
云計算令軟件定義基礎設施快速興趣，并允許我們將服務器轉化為一次性資源實體。容器則將這種趨勢推進至新的高度。容器擁有卓越的部署與啟動速度，而且在正確編排與自動化工具的輔助下，大家現在可以將整套環境視為按需與一次性功能實體。
雖然生產環境還將在相當長的歷史時期當中持續存在，但新型方案確實能夠在開發與測試環境下發揮重要優勢，且通過一鍵式操作實現重新創建。現在，部署流程可以與自動化測試機制相對接，包括其中的環境啟動、測試運行以及環境測試成功判斷等等。
總結陳詞
容器已經快速興起并成為DevOps與持續交付工作中的一項基礎性工具。伴隨著微服務類架構，容器技術能夠甚至足以幫助我們在整套交付流程中利用最佳實踐管理應用程序組件——從代碼提交至生產運行皆涵蓋于其中。
盡管容器技術能夠解決一系列關鍵性難題，但其同時也需要新的工具手段以實現應用程序的自動化與管理任務。下一代應用程序交付與管理解決方案能夠將現有容器作為一種標準化構建單元，從而將自動化全面引入應用程序生命周期。在我看來，這種不同技術成果的結合將幫助大家迎來新的生產力發展水平及更先進的軟件工程能力，從而滿足不同領域當中持續增長的軟件產品與設備需求。
京公網安備 11010502049343號