[[252870]]

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

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

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

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

1.使用Docker動態構建節點

在傳統的CI環境中，執行編譯的所有計算機都擁有開發人員可能需要的工具的超集。 每個節點都提供了公司采用的預安裝版本、測試和配置工具。

 

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

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

 

基于動態Docker的工具對于使用習慣于傳統靜態構建工具的開發人員來說，就像是再生。

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

這種方法既簡單，也強大，對開發人員和操作員都有優勢，將在下一節中詳細介紹。

2.靜態編譯工具的黑暗時代 - 開發者的觀點

現在我們已經了解了如何僅為CI過程采用Docker，而不是完整的CD，我們需要解釋基于Docker的工具的優勢。最簡單的方法是解釋傳統靜態編譯方法的缺點。

 

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

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

開發人員必須根據構建節點上的可用內容配置自己的工作站。

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

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

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

 

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

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

3.動態Docker工具為開發人員帶來的好處

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

 

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

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

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

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

• 創建使用全新架構的新項目非常容易。

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

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

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

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

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

基于動態Docker的工具對于習慣于傳統靜態構建工具方法約束的開發人員來說就像是再生。

現在讓我們看看操作員如何從CI中的動態工具中獲益。

4.靜態構建工具的黑暗時代 – 操作員的觀點

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

 

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

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

• 所有構建節點都完全相同，每個節點都包含開發人員使用的項目所需的構建工具。

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

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

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

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

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

5.動態Docker工具對操作員的好處

使用動態Docker工具，操作變得非常容易。

 

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

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

• 不關心開發人員使用的工具的確切版本;

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

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

• 可以在同質級機器上工作

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

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

圖中未顯示的另一個優點來自Docker容器的速度和占用空間。使用傳統的靜態構建方法，即使沒有開發人員需要作業的構建內容，操作員也必須始終準備好構建節點，并將其用于作業。

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

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

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

本文的重點是介紹使用Docker進行動態構建工具，這是今天在實際生產應用中的最佳實踐，而無需實際使用Docker本身進行生產部署。

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

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

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

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

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

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

大多數與Docker相關的新聞都側重于基于Docker的部署，而不是基于Docker的構建工具，這使得許多組織無視后者的好處。

 

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

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

按需創建構建環境而不是等待冗長的供應批準的能力是開發人員和操作人員需要經常面對的痛點之一。

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

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

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

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

譯者介紹：

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