[[252870]]

容器正在迅速成為大小企業(yè)的通用部署工具。Docker自然而然地被開發(fā)人員用于各種版本的輕松部署。

使用容器進行部署確實在過去(裸機和虛擬機(VM)世界)是一個受歡迎的過渡方式，因為小的占用空間(無論是在大小和啟動時間上)促使組織比以前更方便地實施部署?？s短版本的部署時間是任何組織都想要達成的目標，因為這可以確保新功能在實施后立即被客戶使用。

不幸的是，從VM到Docker映像的這種快速轉(zhuǎn)換，掩蓋了很少提到的容器的另一大優(yōu)勢，這就是在動態(tài)工具形式的持續(xù)集成(CI)過程中，使用容器時，對開發(fā)人員的操作有利之處。這是容器改變游戲規(guī)則的特征，可以說它比部署工件更重要。

關(guān)于如何在CI / CD(持續(xù)集成/持續(xù)部署)過程中使用容器，“采用Docker”幾乎與生產(chǎn)部署同義，但這可能不是事實。在本文中，我們將解釋為什么利用基于Docker的工具，是完整Docker采用過程中一個重要且獨立的部分。

1.使用Docker動態(tài)構(gòu)建節(jié)點

在傳統(tǒng)的CI環(huán)境中，執(zhí)行編譯的所有計算機都擁有開發(fā)人員可能需要的工具的超集。 每個節(jié)點都提供了公司采用的預安裝版本、測試和配置工具。

 

擁有同一工具的多個版本是一項巨大的挑戰(zhàn)，對于不同團隊使用多種技術(shù)的大型組織而言，維護編譯節(jié)點所需的工作很快就會失控。

容器的出現(xiàn)(以Docker的形式)向我們展示了另一種更直觀和簡化的方法 --- 動態(tài)工具。使用動態(tài)Docker工具，編譯節(jié)點從安裝Docker開始。

 

基于動態(tài)Docker的工具對于使用習慣于傳統(tǒng)靜態(tài)構(gòu)建工具的開發(fā)人員來說，就像是再生。

在構(gòu)建期間，只使用Docker容器啟動手頭構(gòu)建作業(yè)需要特定工具。 編譯完成后，編譯節(jié)點將恢復其原始狀態(tài)(即完全清空工具)。

這種方法既簡單，也強大，對開發(fā)人員和操作員都有優(yōu)勢，將在下一節(jié)中詳細介紹。

2.靜態(tài)編譯工具的黑暗時代 - 開發(fā)者的觀點

現(xiàn)在我們已經(jīng)了解了如何僅為CI過程采用Docker，而不是完整的CD，我們需要解釋基于Docker的工具的優(yōu)勢。最簡單的方法是解釋傳統(tǒng)靜態(tài)編譯方法的缺點。

 

在靜態(tài)工具平臺中，編譯節(jié)點長時間運行，只能加載部分的編譯工具。這給開發(fā)人員帶來了許多問題(和挫敗感)：

必須首先通過操作請求升級新工具，從而導致升級周期非常緩慢。

開發(fā)人員必須根據(jù)構(gòu)建節(jié)點上的可用內(nèi)容配置自己的工作站。

使用新的框架和工具創(chuàng)建一個全新的項目需要付出很多努力，因為必須升級所有編譯節(jié)點以適應它。

開發(fā)人員必須跟蹤編譯節(jié)點功能，并確保其編譯作業(yè)實際發(fā)送到滿足所有要求的節(jié)點。

在編譯節(jié)點中使用同一工具的多個版本始終是一個巨大的挑戰(zhàn)。在極端情況下，開發(fā)人員被迫更改其項目庫，只是因為編譯節(jié)點已升級/降級該版本。

 

采用基于云的體系結(jié)構(gòu)使這個問題顯得更為凸出，因為現(xiàn)在單個組織可以同時部署到多個平臺，這些平臺受外部控制。

開發(fā)人員對最終結(jié)果不滿意，因為他們認為編譯平臺對他們有影響。在編譯工具可用性方面，開發(fā)人員和操作員之間始終存在緊張關(guān)系。

3.動態(tài)Docker工具為開發(fā)人員帶來的好處

使用動態(tài)Docker工具，開發(fā)人員和操作員之間的通信變得非常容易。編譯節(jié)點只有一個硬性要求，那就是Docker本身。

 

一旦Docker安裝在構(gòu)建節(jié)點中，任何開發(fā)人員都可以使用該特定項目所需的特定工具啟動Docker鏡像。操作員不再是采用新框架和新庫的障礙。

這種方法的動態(tài)特性來自于Docker容器是短暫的。只有需要時，它們才存在。與在構(gòu)建節(jié)點中預安裝工具的傳統(tǒng)做法相比，差異巨大。

開發(fā)人員能夠愉悅的使用(并且效率更高)，因為：

• 他們可以選擇使用任何版本的框架。

• 創(chuàng)建使用全新架構(gòu)的新項目非常容易。

• 所有構(gòu)建節(jié)點都是相同的，因此，他們可以將任務發(fā)送到任何節(jié)點，如果操作者事先知道工具版本不匹配，將永遠不會執(zhí)行此操作。

• 使用同一工具的多個版本非常簡單(即使在同一個項目中)。

• 他們永遠不會被迫升級庫版本。遺留項目仍然可以使用與greenfield項目完全不同的工具版本。

• 構(gòu)建節(jié)點是“自我清理”(self-cleaning)的，因此，他們永遠不必擔心版本工具的沖突問題。

• 與操作員的溝通變得非常簡單。要討論的唯一主題是構(gòu)建節(jié)點中Docker守護程序的版本。

基于動態(tài)Docker的工具對于習慣于傳統(tǒng)靜態(tài)構(gòu)建工具方法約束的開發(fā)人員來說就像是再生。

現(xiàn)在讓我們看看操作員如何從CI中的動態(tài)工具中獲益。

4.靜態(tài)構(gòu)建工具的黑暗時代 – 操作員的觀點

傳統(tǒng)上，操作員(即系統(tǒng)管理員)需要花費大量精力來管理靜態(tài)構(gòu)建節(jié)點。他們的責任是保留一大堆工具，以確保開發(fā)人員可以使用這些工具。

 

這種方法的復雜性很快會引發(fā)矛盾，特別是在使用不同工具和技術(shù)的組織中。

為了解決多種構(gòu)建工具和版本的復雜性，操作員通常遵循以下兩種方法之一：

• 所有構(gòu)建節(jié)點都完全相同，每個節(jié)點都包含開發(fā)人員使用的項目所需的構(gòu)建工具。

• 不同的構(gòu)建節(jié)點具有不同的構(gòu)建工具集合。節(jié)點被分配了顯示其功能的特殊“標簽”。

兩種方法都有優(yōu)點和缺點。如果構(gòu)建服務器中的所有節(jié)點完全相同，則需要使用特殊機制來處理同一工具的多個版本。此外，每個構(gòu)建節(jié)點都可能很快變得過載。另一方面，這使得開發(fā)人員的工作更容易，因為他們可以為他們的構(gòu)建選擇節(jié)點。

為不同的工具使用不同的節(jié)點解決了構(gòu)建工具的版本沖突，因為每個節(jié)點可以在同一工具上具有不同的版本。但是，在這種情況下，操作員需要密切跟蹤哪個工具安裝在哪個節(jié)點上，并確保在新版本出現(xiàn)時升級所有節(jié)點。

開發(fā)人員還需要了解后一種方法，因為他們必須確保將構(gòu)建作業(yè)發(fā)送到正確的節(jié)點。例如，Python開發(fā)人員需要指定作業(yè)需要具有“python”標簽的節(jié)點，而JavaScript開發(fā)人員需要具有“javascript / npm”標簽的節(jié)點，依此類推。

總之，靜態(tài)構(gòu)建節(jié)點對于操作員來說需要耗費巨大的時間成本。實際上，有些公司在構(gòu)建節(jié)點維護上需要全職投入。

5.動態(tài)Docker工具對操作員的好處

使用動態(tài)Docker工具，操作變得非常容易。

 

所有節(jié)點都易于設(shè)置和維護，特別是如果現(xiàn)有的Kubernetes集群用于構(gòu)建，這很快就會成為一種常見做法。如前所述，每個構(gòu)建節(jié)點只需要安裝Docker，而不需要其他任何東西。其他節(jié)點也完全相同(根據(jù)定義)。

操作員通過這種直截了當?shù)姆椒?，維護已批準的工具列表，但不需要事先安裝它們;

• 不關(guān)心開發(fā)人員使用的工具的確切版本;

• 對工具升級不再負責(因為開發(fā)人員可以自己完成);

• 不再面對同一工具的多個版本的問題;

• 可以在同質(zhì)級機器上工作

• 不必管理節(jié)點的標簽，并跟蹤哪個節(jié)點具有哪個工具。

與開發(fā)人員的溝通非常簡單，因為唯一要討論的是節(jié)點的Docker版本。

圖中未顯示的另一個優(yōu)點來自Docker容器的速度和占用空間。使用傳統(tǒng)的靜態(tài)構(gòu)建方法，即使沒有開發(fā)人員需要作業(yè)的構(gòu)建內(nèi)容，操作員也必須始終準備好構(gòu)建節(jié)點，并將其用于作業(yè)。

使用基于Docker的工具，開發(fā)人員可以在幾秒鐘內(nèi)按需啟動工具。當沒有開發(fā)人員使用節(jié)點時，可以輕松地將節(jié)點重新分配給使用完全不同技術(shù)的另一個開發(fā)團隊。

總之，基于Docker的工具可以釋放操作員的手，并減輕他們的日常負擔。

6.兩種完全正交的Docker方法

本文的重點是介紹使用Docker進行動態(tài)構(gòu)建工具，這是今天在實際生產(chǎn)應用中的最佳實踐，而無需實際使用Docker本身進行生產(chǎn)部署。

Docker部署工件或構(gòu)建工具方法是完全獨立的，您可以根據(jù)組織情況，輕松有效地混合和匹配這些工具。

基本上，公司內(nèi)有4個可能的容器采用階段：

• 基于VM的工具，在VM上部署(舊方法)。

• 基于VM的工具，在容器上部署(大多數(shù)人都熟悉這種方法)。

• 基于Docker的工具，可在VM上部署(從容器中獲益的好方法)。

• 基于Docker的工具，在容器上部署(完全Docker采用)。

大多數(shù)與Docker相關(guān)的新聞都側(cè)重于基于Docker的部署，而不是基于Docker的構(gòu)建工具，這使得許多組織無視后者的好處。

 

從上圖中可以清楚地看出，基于Docker的工具可以單獨使用(而部署仍然可以針對VM /裸機)。許多組織試圖通過盲目地嘗試在生產(chǎn)部署中使用Docker，而不了解這不是唯一可能的方法來趕上容器潮流。

事實上，基于Docker的工具可以為CI / CD流程帶來更多好處，因為它解決了開發(fā)人員面臨的許多常見生產(chǎn)力問題，正如我們在前面部分中看到的那樣。

按需創(chuàng)建構(gòu)建環(huán)境而不是等待冗長的供應批準的能力是開發(fā)人員和操作人員需要經(jīng)常面對的痛點之一。

在Codefresh，我們已經(jīng)為CI / CD管道實現(xiàn)了這種方法。每個步驟都是自己的容器。想運行Node?有一個Docker鏡像。想要運行Maven?有一個Docker鏡像。想要進行 Canary rollout嗎?有一個圖像。你需要嗎?你需要Terraform嗎?基本上，作為Docker鏡像提供的所有內(nèi)容都可以用作構(gòu)建步驟。

您仍然可以使用Codefresh部署到傳統(tǒng)目標(即VM和裸機)，但構(gòu)建平臺的核心是利用工具來使用容器和Docker鏡像。

開發(fā)人員可以創(chuàng)建管道，其中每個構(gòu)建步驟都在包含所需工具的Docker鏡像的上下文中運行。版本沖突、工具升級和在不同版本上構(gòu)建節(jié)點等問題都已成為過去。

我們將動態(tài)Docker構(gòu)建工具視為一種改變開發(fā)人員和操作員操作的新方法，并希望看到它在公司和組織中獲得進一步的認可。

譯者介紹：

劉志紅，17年IT從業(yè)經(jīng)驗。曾在NTT DATA，Oracle，中鈔造幣集團，中國電信云計算分公司從事云計算等關(guān)聯(lián)IT研發(fā)工作。獨立擁有軟件著作權(quán)1件。目前就職于電子工業(yè)出版社。