容器協調的關鍵概念：工具的生態系統與選擇策略

容器技術的快速普及帶來了一個新的挑戰：如何有效地管理、排程和協調大量容器的運作。在這個領域中，各種容器協調工具競相爭奪市佔率，而企業和開發者則面臨著複雜的選擇。讓我們探討容器協調的現況及未來趨勢。

容器協調領域的主要競爭者

根據技術調查顯示，Kubernetes 已成為容器協調領域的領頭羊，約有39%的受訪者表示計劃在未來一年內使用此工具。這並不令人驚訝，因為 Kubernetes 提供了強大的功能集和靈活的架構，支援各種規模的佈署。

緊隨其後的是 Ansible（36%）、Mesos/Mesosphere DCOS（33%）、Amazon ECS（25%）和 Docker Swarm（23%）。這個排名反映了市場的多樣性和分散性，也顯示出不同工具在特定場景下的優勢。

當玄貓分析 Docker 相關產品的使用情況時，發現約有31%的受訪者計劃使用 Docker 公司的產品來管理容器。這個資料包含了 Docker Swarm、Docker Cloud 和 Docker Datacenter 的使用者。

不同成熟度階段的工具選擇差異

特別值得注意的是，企業對於容器協調工具的選擇與其容器使用的成熟度密切相關：

生產環境使用者：傾向於選擇已經穩定與有良好社群支援的工具，如 Kubernetes（37%）和 Mesos/Mesosphere DCOS（32%）。
測試/開發階段使用者：對 Ansible 的偏好更明顯（50%），可能是因為其設定管理的能力和與現有系統的整合性。
評估階段使用者：更可能考慮 HashiCorp 產品（如 Nomad、Terraform）和 Red Hat 的 OpenShift，這可能是因為這些使用者已經熟悉這些公司的其他產品。

Ansible 在調查中的高排名令人意外，這可能與 Red Hat 的收購有關。許多 Red Hat 客戶可能選擇 Ansible 作為一種與其他 Red Hat 產品整合的方式。這一點從選擇使用 Red Hat OpenShift 的受訪者中也有七成同時計劃使用 Ansible 的資料中得到佐證。

容器管理的專項工具選擇

容器協調涉及多個關鍵功能領域，每個領域都有專門的工具：

服務發現工具

在服務發現方面，HashiCorp 的 Consul（44.4%）、Apache ZooKeeper（41.9%）和 etcd（37.1%）是最常被使用的工具。值得注意的是，Mesos 使用 ZooKeeper 來確保高用性，這解釋了為何 ZooKeeper 在 Mesosphere 使用者中的使用率特別高。

當玄貓在金融科技領域實施容器化微服務時，發現服務發現是整個架構中最容易被低估但卻至關重要的環節。沒有可靠的服務發現機制，動態擴充套件的容器環境將變得極其脆弱。

排程工具

容器排程工具方面，Kubernetes（36%）、Marathon（31%）和 Docker Swarm（21%）是最常被使用的選項。這個領域的競爭尤為激烈，各工具都有其獨特的優勢：

Kubernetes 提供了強大的自動擴充套件和自修復功能
Marathon 與 Mesos 緊密整合，適合大規模佈署
Docker Swarm 則以其與 Docker 生態系統的原生整合為賣點

叢集管理工具

在叢集管理方面，Mesos（42%）、Kubernetes（26%）和 Docker Swarm（25%）構成了三足鼎立的局面。即使排除 Mesosphere 調查中的樣本偏差，Mesos 仍然保持強勢，這反映了其在大規模佈署中的優勢。

DevOps Weekly 訂閱者則更傾向於使用 Kubernetes（50%）和 Docker Swarm（43%），這可能表明這些工具在早期採用者社群之外的曝光度更高。

評估容器協調工具的關鍵標準

在選擇容器協調工具時，企業考慮的因素遠不止成本、效能和品牌聲譽。調查顯示，最重要的評估標準包括：

開發與維運的整合工具：58%的受訪者認為這極其重要，比其他任何標準高出至少12個百分點。這反映了DevOps文化的普及，強調開發和維運團隊之間的協作。
支援完整的應用生命週期：46%的受訪者認為這極其重要。容器協調不僅是關於執行容器，還涉及佈署、擴充套件、更新和監控整個應用生命週期。
與現有系統的整合：44%的受訪者認為與現有日誌、監控或身份管理系統的整合極其重要。這表明大多數企業不是從零開始，而是在現有基礎設施上採用容器技術。

相比之下，支援多種作業系統被視為最不重要的標準，這可能是因為大多數容器化工作負載都執行在Linux上。

容器協調的關鍵使用案例

調查還揭示了容器協調的主要使用案例及其相對重要性：

長時間執行的應用：86%的受訪者認為這至少是非常重要的，這反映了容器已經從開發環境進入了生產環境。
負載平衡：超過75%的受訪者認為這至少是非常重要的，這對於處理流量波動和確保高用性至關重要。
永續性儲存：70%的受訪者認為這至少是非常重要的，雖然這常被視為容器化的痛點。
批處理應用：僅43%的受訪者認為這至少是非常重要的，表明容器協調工具更多用於持續執行的服務。

值得注意的是，支援非容器化工作負載被視為最不重要的功能，這表明企業傾向於將傳統應用與容器化應用分開處理。

行業實踐與未來趨勢

在過去幾年中，玄貓見證了容器協調工具的快速演變。從最初的簡單排程工具，到現在的全功能平台，這些工具越來越關注使用者經驗和企業級功能。

特別是Kubernetes，從Google內部的Borg系統演變而來，現在已經發展成為一個強大的平台，支援各種外掛程式和擴充套件。隨著雲原生技術的普及，Kubernetes生態系統將繼續擴充套件，涵蓋更多功能領域。

然而，容器協調不是一個一刀切的解決方案。不同規模的組織、不同類別的應用和不同的技術堆積積疊可能需要不同的工具。小型團隊可能更喜歡Docker Swarm的簡單性，而大型企業可能需要Kubernetes或Mesos的強大功能。

容器協調工具的選擇應該根據組織的具體需求和現有基礎設施。在玄貓的經驗中，成功的容器策略通常始於小規模的試點專案，然後根據實際經驗逐步擴大範圍。這種方法允許團隊學習和適應，同時降低風險。

隨著容器技術的成熟，我們可以預期看到更多的整合和簡化。雲提供商將繼續增強其代管容器服務，使容器協調對更廣泛的使用者群體更加無縫和可存取。

容器協調工具的競爭將繼續，但最終，勝出的工具將是那些能夠平衡功能豐富性和使用者友好性的工具。在這個快速發展的領域中，保持靈活性和開放心態對於組織成功採用容器技術至關重要。

容器協調技術的演進仍在加速，組織需要在保持靈活性的同時，為特定需求選擇最合適的工具。理解不同工具的優勢和侷限性，結合具體的業務需求和技術環境，才能做出最佳的容器協調策略決策。

容器協調與生產環境的關鍵考量

容器協調能力的重要性評估

根據《The New Stack》2016年3月的調查，容器協調工具評估中最重要的需求是長時間執行的應用程式和負載平衡功能。調查顯示，68%的受訪者認為長時間執行的應用程式支援「極其重要」，而負載平衡功能則有59%的受訪者認為「極其重要」。相比之下，非容器化工作負載的重要性評分較低，只有11%的受訪者認為「極其重要」。

這些資料反映了一個關鍵趨勢：容器技術正從開發環境逐漸轉向生產環境，而穩定性和可靠性成為首要考量。在玄貓多年的容器化專案經驗中，我發現這種轉變需要更成熟的協調工具來支援。

容器協調的定義與範疇

容器協調的核心功能已達成相當共識，包括：

排程管理
叢集管理
服務發現

然而，超過半數的受訪者也認為佈建和監控屬於協調的一部分。這反映了容器管理工具正朝向整合方向發展，以滿足從開發到維運的全生命週期需求。

在技術選擇方面，Docker Swarm被公認為Docker Cloud和Docker Datacenter的底層技術。而Kubernetes雖然本身不是一個產品，卻是最常被使用的容器管理解決方案。AWS Elastic Container Service、Google Container Engine和Docker Cloud等CaaS（Container-as-a-Service）服務也獲得相當關注。

容器即服務(CaaS)與平台即服務(PaaS)

調查顯示，CaaS被認為涵蓋了軟體開發生命週期的多個部分，特別是容器協調和容器倉函式庫egistry)功能。AWS Elastic Container Service是第四個最受考慮的容器管理選項，Google Container Engine和Docker Cloud/Datacenter產品也經常被提及。

從玄貓的觀察來看，CaaS的興起反映了市場對於簡化容器管理複雜性的強烈需求。相較於自建容器基礎設施，CaaS提供了一種更為便捷的方式讓組織快速採用容器技術，同時保留一定程度的控制權。

職務角色與容器管理

容器技術的採用仍然主要集中在開發者和IT管理的交叉領域。調查中有49%的受訪者將自己描述為DevOps角色，這解釋了為什麼58%的受訪者認為開發者和IT維運的整合工具「極其重要」。

應用程式開發者更傾向於使用自訂指令碼來管理容器，並且更可能認為監控和設定管理是容器協調工具的一部分。相比之下，IT維運人員更可能使用設定管理工具來處理非生產環境中的容器實作，並且在生產環境中傾向於使用CaaS而非通用的「協調平台」。

設定管理工具的角色

設定管理是最不可能與容器協調相關聯的功能，儘管主要的設定管理供應商仍然被頻繁提及。這些工具（如Ansible、Puppet Labs、Chef和SaltStack）預期將與其他工具一起使用，而非作為主要的協調方法。

值得注意的是，Ansible在使用者計劃中的提及率與Kubernetes相當。Red Hat對Ansible的收購可能提升了其地位，因為許多人在計劃中同時提到了OpenShift和Ansible。

雲原生能力與更深入的使用者經驗

隨著基礎設施即程式碼的趨勢發展，協調基礎設施和雲端的方式已經發生了變化，排程器也有了新的形式。這個生態系統的許多變化以及工具管理方式的變化，直接影響了Cisco的容器堆積積疊解決方案Mantl。

Ken Owens（Cisco Systems雲基礎設施服務的CTO）和Ben Schumacher（Cisco Intercloud Services架構師，Mantl和Shipped專案的負責人）在討論中提到了幾個關鍵話題：

下一代雲原生架構
系統複雜性的變化
容器生態系統中工具演進的速度
當前協調平台需要的改進

生產環境中的容器考量

如果容器的採用僅限於開發和測試環境，那麼採用容器導向的開發和佈署工作流程的好處就不能完全實作。對於在生產環境中執行容器的猶豫主要源於安全性和隔離性的擔憂，以及在生產環境中管理容器的操作專業知識普遍缺乏。

容器原生應用程式

容器原生應用程式是圍繞容器生命週期設計和構建的應用程式，通常將容器視為其存在的「一等公民」。對於已經改造以適應容器的應用程式（尤其是傳統應用程式），生產環境的遷移決策通常更加困難。

生產環境工作流程影響

理解容器對組織生產環境中現有工作流程和流程的影響是執行生產容器的重要方面。可能受到容器影響的一些生產工作流程和流程包括：

將變更或功能從開發環境移至生產環境
允許終端使用者存取佈署在生產環境中的變更或功能
除錯生產中報告的問題
監控生產中的應用程式
在生產環境中更新應用程式版本
備份生成的資料
災難還原和業務連續性
生產環境容量規劃
設定主機，特別是網路和安全設定

容量規劃與基礎設施成熟度

大多數正在採用容器的組織中，不使用容器操作生產環境是常態。在這些組織中，虛擬機器可能作為佈署單元優先考慮，滿足應用程式元件的隔離和管理需求。

容器的支援者越來越提倡在裸機上執行容器化工作負載。這有助於避免使用虛擬機器時的效能損失和連貫的背景與環境切換懲罰。如果我們執行不與其他不受信任租戶分享資源的單一租戶系統，這一論點更加明顯。

處於容器採用早期階段的組織可以嘗試使用混合策略：既有容器化應用程式在虛擬機器上執行，也有一些在裸機上執行。透過一段時間分析管理和效能指標，這種組合可以被微調。當達到一定的容器操作成熟度時，一些採用者選擇僅使用裸機來執行他們的容器。

在分享生產基礎設施上執行多個應用程式時，在裸機上執行容器的決定應根據先前的經驗。更安全的選擇是讓這些多租戶包裝在虛擬機器中，並讓容器成為應用程式的執行時佈署。

基礎設施成熟度模型

從低成熟度到高成熟度的基礎設施轉變可以從兩個角度理解：

低成熟度基礎設施：租戶不分享生產基礎設施。這種隔離可以是虛擬機器或物理主機。每個租戶（A、B、C）擁有自己的虛擬機器（1、2、3）。
高成熟度基礎設施：多個租戶分享基礎設施。每個租戶應用程式的元件分散在分享基礎設施上。對於容器而言，高成熟度代表分享虛擬機器或裸機基礎設施，其中每個租戶應用程式的元件分散其中。

在高成熟度模型中，容器可以在虛擬機器或裸機上執行，每個容器（1、2、3）可能屬於不同的租戶應用程式。這種模式提供了更高的資源利用率和靈活性，但需要更強大的管理和協調能力。

容器管理的實用建議

從玄貓的實際經驗來看，容器在生產環境中的成功採用需要考慮以下幾點：

逐步過渡：從非關鍵應用開始，並逐漸擴充套件到更重要的工作負載
混合策略：對於多租戶環境，考慮虛擬機器+容器的混合方案，提供額外隔離層
監控與可觀察性：建立強大的監控系統，確保能夠快速識別和解決容器環境中的問題
自動化佈署：利用CI/CD管道自動化容器構建、測試和佈署流程
安全考量：實施容器特定的安全最佳實踐，包括映像掃描、執行時保護和網路隔離策略

容器協調和管理技術正在快速發展，組織需要根據自身的成熟度和需求選擇適當的策略。無論選擇哪種方案，重要的是確保容器基礎設施能夠支援業務需求，同時提供必要的安全性、可靠性和可擴充套件性。

在容器化過程中，理解並適應這些變化是組織實作容器技術全部價值的關鍵。隨著容器技術的不斷成熟，我們可以預期看到更多整合的解決方案，進一步簡化容器在生產環境中的管理和維運。

生產環境中的容器技術：實戰考量與最佳實踐

容器化應用的多租戶架構

在生產環境中佈署容器化應用時，多租戶隔離是一個關鍵考量。低成熟度的多租戶架構中，不同租戶的應用程式不會分享基礎設施，每個租戶可能擁有獨立的虛擬機器或實體主機。而高成熟度的架構則允許不同租戶的應用元件分散在分享基礎設施上。

在容器環境中，高成熟度代表不同租戶的應用元件可以分散在分享的虛擬機器或裸機基礎設施上，但仍需維持適當的隔離機制。通常的做法是在虛擬機器內佈署屬於同一租戶的容器，以確保租戶間的隔離。

容器化應用的生產環境發布策略

容器的短暫特性改變了傳統的應用程式更新方式。在容器世界中，更新應用程式不再是修改現有例項，而是以全新的容器例項取代舊版本。

映像檔管理與發布流程

當需要將變更推播至生產環境時，玄貓建議採用以下流程：

在持續整合(CI)流程中生成帶有新標籤的容器映像檔
將新映像檔儲存在容器映像檔登入檔中

雖然可以在所有環境（開發、測試、生產）間分享映像檔登入檔，但在某些情況下，生產環境會使用專屬的登入檔以增強安全性。此時，需要建立一個「晉升流程」，將開發/測試登入檔中的「候選」映像檔重新標記並推播至生產登入檔。這種方式能夠清晰隔離非生產環境與生產環境的映像檔。

佈署策略

容器的短暫特性對傳統使用靜態埠繫結和IP位址的做法提出了挑戰。在生產環境中發布變更，玄貓強烈推薦採用滾動升級（rolling upgrades）策略，這需要在生產環境中設定額外的基礎設施，以便在新版本容器例項啟動時修改現有的負載平衡器和代理設定。

為了在佈署容器時保持一定程度的彈性，可以利用容器執行時和平台提供的協調工具。即使只使用容器執行時而沒有任何協調工具，也應設定適當的「–restart」策略，建議在「on-failure」和「unless-stopped」之間選擇最適合環境的設定。

生產環境容器基礎設施準備

準備容器化生產環境時，需要認識到容器映像檔的「封閉」特性。容器映像檔要求標準化的基礎設施，在開發、測試和生產環境中保持相似的設定。這種標準化對於在生產環境中獲得可預測的容器執行體驗至關重要。

關鍵標準化要素

核心(kernel)版本選擇
容器執行時版本與選擇
網路存取與防火牆設定
安全加固解決方案
系統存取許可權

雖然可能會有偏離所有環境標準化的誘惑，但任何偏差都可能導致需要調查的不可預測結果。最簡單的解決方法是確保從開發到測試再到生產的每個環境都使用相同的拓撲結構。

執行時行為差異化處理

容器例項的某些執行時行為會有所不同，例如存取其他依賴服務或日誌級別。這些執行時設定可以透過各種選項傳遞給容器，最常見的方式是透過環境變數注入。環境變數可以指向服務登入檔，然後指向正確的依賴服務。etcd、ZooKeeper和Consul等工具在實作這一範例時非常有用。

如果使用現有的設定管理和佈建工具（如Chef、Puppet和Ansible）來佈建主機，那麼盡可能為所有環境使用單一設定是正確的做法。對於擴充套件基礎設施，環境之間的有限差異主要是考慮可用性和效能需求所需的例項數量。

主機偶爾也需要更新最新的核心補丁、容器執行時版本等，這些更新無法封裝在容器映像檔內。這種主機設定變更應該遵循滾動升級策略，允許分階段更新，而不是採用一次性大規模更新的方法。

最後，與主機一樣，所有環境的日誌聚合、監控、指標、服務路由和發現等支援基礎設施也需要有類別似的設定和拓撲。這確保了容器映像檔不僅與主機保持一致性，還與各自環境中的所有參與服務保持一致。

生產環境中的容器服務發現

標準化服務發現機制是容器化應用的重要考量。在容器世界中，通常一台主機上會執行多個容器，這與傳統VM應用佈署方式不同。

在使用橋接網路模式的罕見情況下，可能需要為每個容器指定靜態埠分配。這意味著預先選擇容器在主機上公開的埠，並使用該埠設定負載平衡器和代理。

如果只有限需求在主機上增加更多容器，則可能不需要重新設定負載平衡器和代理。然而，在大多數情況下，容器會根據負載透過不可變佈署或擴充套件實踐增加或移除。在這種情況下，維護一組靜態預分配的埠號將變得困難，而這正是服務發現系統發揮作用的地方。

生產環境支援：日誌聚合與監控

容器化環境與非容器化環境需要相同的支援服務，包括從容器例項捕捉日誌並將其傳送到中央日誌管理系統的方法。Docker守護程式中已內建日誌後端支援，也有自定義解決方案處理這一需求。

容器日誌管理選項

Docker預設設定將未壓縮的日誌寫入磁碟，並可選擇保留設定以限制儲存使用。在生產環境中，Docker引擎提供多種日誌驅動程式，為透明管理應用程式產生的日誌資料提供靈活選項。如果已有中央化日誌解決方案，很可能有Docker日誌驅動程式可設定以將容器日誌資料饋送到其中。

處理容器短暫特性的監控挑戰

容器的短暫狀態是容器日誌和監控中需要注意的關鍵行為。當佈署發生在生產環境時，新容器會替換舊容器。這打破了傳統假設計算單元是有狀態與長時間執行的慣例。

傳統的主機中心日誌和監控解決方案無法擴充套件到容器的複雜性。由於容器生命週期短，玄貓建議採用宣告式監控方法，並最好將它們作為一個群組進行監控，而不是監控艦隊中的每個容器。

將容器關聯到一個群組的方法之一是使用適當的元資料，如標籤。標籤指的是在生產環境中執行的「image-tag」。玄貓建議在實施時避免使用被誤解的Docker容器「latest」標籤。

容器監控策略

容器的適當監控和日誌策略是一個非侵入性解決方案，可以保持在執行容器之外，理想情況下作為「side-car」容器服務執行。容器監控工具需要了解容器，甚至瞭解容器平台。這種認知將幫助監控工具避免在報告故障時產生混淆，例如當容器平台將容器從一個主機停止並移動到另一個主機時。

容器足跡將導致監控和日誌系統收集過多資料，從而需要額外的資料管理。容器監控是一個快速發展的領域，有各種軟體即服務(SaaS)和本地佈署工具可以幫助你做出決策。

容器資料管理方法

管理容器資料的普遍建議是在生產環境中執行無狀態容器，這些容器不儲存自己的資料，純粹是交易性的。無狀態容器將處理過的資料儲存在外部，超出其容器空間範圍，最好儲存到由可靠與可用的永續性後端支援的專用儲存服務中。

對於託管儲存服務（如資料函式庫列和快取）的有狀態容器，約定的模式是使用資料容器。這些有狀態服務的執行時引擎在執行時與資料容器連結。

玄貓在實際容器佈署中發現，正確的資料管理策略對確保系統穩定性至關重要。無狀態容器雖然簡化了擴充套件和故障還原流程，但對於需要持久化資料的應用，必須精心設計儲存策略，確保資料不會因容器重啟或遷移而丟失。

在生產環境中採用容器技術需要仔細考慮多租戶架構、發布策略、基礎設施標準化、服務發現、日誌聚合與監控以及資料管理等多個方面。容器的短暫特性改變了我們對應用佈署和管理的傳統思維，要求更加靈活和自動化的方法。

透過標準化環境設定、實施滾動升級策略、採用適當的服務發現機制、建立容器感知的監控系統以及實施正確的資料管理策略，可以充分利用容器技術的優勢，同時避免其潛在的挑戰。隨著容器技術的不斷成熟，這些最佳實踐也將繼續演進，但核心原則仍將圍繞標準化、自動化和彈性設計。

容器生產環境中的關鍵挑戰與解決方案

在過去幾年協助企業匯入容器技術的過程中，我發現許多組織在將容器從開發環境遷移到生產環境時，經常面臨一系列未預期的挑戰。容器技術雖然帶來了前所未有的佈署靈活性，但同時也需要重新思考資料管理、安全性策略與映像管理等議題。

持久化資料的智慧管理

容器的本質是暫時性與不可變的，這使得資料持久化成為一個重要考量。在協助某金融科技公司建構容器化應用時，我們採取了「資料與應用分離」的核心原則：

將資料函式庫執行在容器中，但透過掛載「資料容器」作為卷宗來儲存狀態
對於叢集環境，我們實作了分散式儲存解決方案

分散式環境中，像Gluster和Ceph這類別分散式儲存解決方案尤其重要。它們能提供分享掛載點，確保當容器例項在叢集中因可用性而遷移時，資料仍然可以被存取。這種架構設計讓我們在不犧牲容器靈活性的前提下，解決了資料永續性問題。

容器安全性與金鑰管理

安全性常是多租戶環境下容器佈署的主要疑慮，特別是當多個容器例項為不同租戶在分享機器上執行時。這種擔憂源自對容器技術能否提供類別似VM級別隔離的不信任。

然而，我認為將容器視為VM的替代品是不恰當的。Docker等容器實作為應用程式提供了安全保護層，容器執行時抽象化了設定細粒度許可權的複雜性，包括使用者、網路和處理程式等不同名稱空間。

在實務應用中，若考慮在分享基礎設施上進行多租戶容器佈署，我推薦：

利用VM進行租戶分離
使用容器作為租戶應用程式元件間的隔離媒介

隨著容器佈署在社群中的普及，未來將需要避免VM隔離牆，讓所有租戶分享相同的基礎設施。

不可變容器例項的另一個關鍵考量是避免將需要保密的金鑰或憑證直接編入容器中。解決這個問題有多種方法：

透過環境變數傳遞機密
使用加密的資料容器作為掛載卷來保護機密

然而，這些技術仍然存在爭議，與容器執行時提供商尚未提供標準解決方案。在我主導的幾個大型金融機構專案中，我們建立了專用的機密管理服務，與容器協調平台整合，在執行時安全地注入機密資訊。

容器在生產環境的未來發展

讓容器在生產環境中成功採用的關鍵元素是建立一個充分了解和受過教育的社群。工具和實踐將演變至容器執行成為大多陣列織常態的狀態。在此之前，使這種採用發生的未完成戰役存在於組織內部。

使每個利益相關者，特別是營運和安全團隊，深入瞭解他們對容器的需求是一項需要大量工作的任務。容器在生產環境中的採用路徑將與VM不同，並將優先考慮開發者體驗和營運簡化，同時兼顧資源利用的好處。

透過我參與的多個容器化轉型計畫，我觀察到成功的組織通常會採取漸進式方法：先將非關鍵應用程式容器化，建立信心和經驗，再逐步擴充套件到更複雜的系統。這種策略不僅降低了風險，也給予團隊足夠時間適應新的工作模式和技術要求。

烘焙模式：容器映像與微服務的基礎

微服務和容器採用的基本要素之一是將不可變更變更封裝成容器映像的概念。容器映像格式利用持續交付(CD)的傳輸系統，提供比虛擬機器映像或AWS機器映像(AMI)更進步的模型。容器映像格式是新的可執行或構建資產，只需構建一次，然後可以在任何相容的微服務基礎設施上執行。

烘焙模式的定義

烘焙模式(Bakery)是一種基礎設施實體，體現了取得、構建和發布機器映像的過程，允許可重複佈署工作程式碼。烘焙模式的輸出是一個已烘焙的映像，用於在任何相容基礎設施中啟動機器(VM或容器)例項。

在我協助設計的一個電商平台架構中，我們實作了烘焙模式來管理數十個微服務的容器映像。這種方法不僅標準化了映像建立流程，還顯著減少了因環境差異導致的佈署問題。當映像能夠與各種類別的基礎設施相容時，烘焙模式的效益最大，減少了為每種類別構建專用映像的需求。

全域與本地烘焙標準

在任何微服務和容器的故事中，容器映像的生產和維護佔據重要地位。因此，成功的微服務和容器採用離不開對容器映像各個方面的優雅處理，包括：

基礎映像的選擇
跨多租戶/多專案的映像分享和隔離
容器映像驗證和確認
容器映像工作流程
測試容器映像
容器映像儲存和生命週期
容器映像過期和折舊

所有這些都是組織烘焙策略和實施的組成部分。

全域烘焙模式

在多專案和不同團隊的組織中，讓每個團隊選擇自己的基礎映像可能會產生不良後果。構建可分享和標準化的可信基礎映像陣列是一種可行的方法。我將此概念稱為全域烘焙(Global Bakery)—組織中專注於基礎容器映像的標準化、治理和生命週期的邏輯實體。

在我主導的一個大型金融機構容器化專案中，全域烘焙團隊負責維護一套經安全審核的基礎映像，這些映像包含了所有必要的安全監控工具和合規元件。這種集中化的方法不僅提高了安全性，還大幅減少了各團隊在基礎設施層面的重複工作。

本地烘焙模式

這些分享基礎映像可以進一步定製以滿足每個團隊的需求，並納入開發工作流程。從團隊的角度來看，重點不是團隊間分享，而是使容器映像成為有用的可佈署基礎。我將此概念稱為本地烘焙(Local Bakery)—從全域烘焙對應項繼承基礎映像，並需要在單個團隊規模上工作的實體。

本地烘焙模式允許開發團隊在標準化基礎之上增加特定於專案的設定、套件和自定義。這種方法在保持組織標準的同時，也給予團隊足夠的靈活性來滿足其獨特需求。

在工作流程中，全域和本地烘焙模式之間的互動是這樣的：

全域DevOps團隊維護基礎映像，其中包含作業系統核心、標準執行時平台、程式語言環境、資料函式庫TTP伺服器等功能
專案團隊使用這些經過信任和驗證的全域基礎映像
各專案團隊根據全域基礎映像建立自己的專案映像，增加特定於專案的設定和自定義

這種分層方法確保了基礎標準的一致性，同時為各團隊提供了所需的靈活性。

容器映像建立策略的關鍵考量

在容器映像建立方面，有兩種主要的方法：

1. 整合式映像建立方法

這種方法將應用程式碼與基礎映像一起封裝，作為構建過程的輸出。映像在應用程式特定引數方面是可設定的，這些引數可以在例項化容器時傳遞給它。這些引數可用於服務發現和其他應用程式特定切換。

這種方法要求在需要變更應用程式或應用程式拓撲時重建和重新佈署映像。在我主導的一個高頻交易平台架構中，我們採用了這種方法，因為它提供了完全可重現的佈署，並簡化了復原流程。

2. 最小化映像與動態佈署方法

這種方法主張建立最小的機器映像，只有在基礎設施、執行時或拓撲發生變化時才構建。對於大多數程式碼變更，不會重建機器映像。新的容器例項從預先存在的機器映像中生成，然後透過啟動指令碼或透過在機器例項上執行的代理佈署程式碼。

這種方法避免了持續生成新機器映像的需要，而是讓新建立的容器例項自行發現和取得變更。這要求容器例項具有自主行為。我在處理需要頻繁更新的應用程式時偏好這種方法，因為它顯著減少了映像構建時間和儲存需求。

值得注意的是，兩種方法的共同點是在傳播變更時不斷建立新的基礎設施例項，而不是依賴長時間執行的基礎設施足跡。兩種方法之間的差異在於機器映像構建過程中包含的內容範圍。

容器技術為應用程式佈署和管理帶來了革命性變化，但在生產環境中成功採用容器需要仔細考慮多個因素。從資料永續性和安全性管理到容器映像的建立和管理，每個方面都需要深思熟慮的策略。

全域和本地烘焙模式為組織提供了一個強大的框架，用於標準化和管理容器映像，同時仍然保持團隊級別的靈活性。無論選擇哪種映像建立策略，關鍵是確保它符合組織的特定需求和工作流程。

隨著容器技術的持續發展，我們可以預期看到更多創新，特別是在安全性、協調和跨雲佈署方面。保持開放的心態，不斷學習和適應這些變化，將是組織在容器時代保持競爭力的關鍵。

在容器和微服務的世界中，沒有放之四海而皆準的解決方案。每個組織都需要根據其獨特的需求、技術堆積積疊和團隊結構來調整其方法。透過採用本文討論的原則和實踐，組織可以在享受容器技術優勢的同時，最小化其挑戰。

容器世界的自動化協調：從映像工廠到微服務生態

在現代雲端架構中，容器技術已成為軟體佈署的核心根本。但真正釋放容器威力的關鍵在於自動化和協調。當我在大型金融科技公司建立微服務平台時，發現單純使用容器遠不夠—我們需要一套完整的工作流程來管理容器生命週期，從建立到佈署再到監控。

在本文中，我將分享多年實踐中發展出的容器自動化架構觀點，特別是「Bakery模型」這種高效的容器映像管理方法，以及如何透過協調技術實作真正的微服務價值。

映像工廠(Bakery)模型：容器映像與微服務的基礎

映像工廠模型將容器映像的建立分為兩層：全域工廠(Global Bakery)和本地工廠(Local Bakery)。這種分層方法讓組織能夠標準化基礎映像，同時保持服務團隊的自主性。

全域工廠與本地工廠的協作機制

全域工廠的產出是一個標準化的基礎映像池，每個映像都經過嚴格驗證後加入映像註冊函式庫些映像隨後可被服務導向組織中的所有團隊使用。而本地工廠則負責將這些基礎映像客製化，以適應個別服務堆積積疊的需求，並最終佈署到服務中。

兩種工廠都使用持續整合(CI)流程來建立和測試容器映像，然後才將它們推播到註冊函式庫實踐中，我發現一個簡單的標籤策略對確保容器映像易於搜尋和識別非常有用。通常，CI伺服器產生的建置標識被用作標籤的基礎，這有助於避免使用「latest」標籤所帶來的混淆。

映像測試與安全性實踐

基礎映像的測試對容器技術的成功採用至關重要。這些基礎映像將在整個基礎設施中傳播，並被開發者用於進一步客製化和擴充套件。

我推薦使用行為驅動開發(BDD)來測試自動化基礎設施。透過像Serverspec這樣的服務，你可以建立RSpec測試來檢查給定的伺服器是否正確設定。Serverspec指令碼可以在CI過程中對從基礎映像產生的容器執行個體進行測試。這種形式的指令碼允許對容器執行時的預設設定狀態進行驗證。

安全評估方面，基礎映像及其周圍的工作流程為進行自動化安全評估提供了良好的基礎。諸如Twistlock和Docker的Project Nautilus等工具可以與CI和佈署管道整合，對已建立的映像進行持續掃描，確保它們的安全性。

當發現並修復漏洞後，全域工廠可以生成新的基礎映像，然後傳遞給各個本地工廠。每個本地工廠隨後利用持續交付(CD)管道根據更新的基礎映像發布新容器。這允許在基礎映像中引入修復後迅速採取補救措施。

避免在容器中硬編碼機密資訊

容器生產佈署中一個常見的問題是如何儲存服務執行所需的機密資訊，如憑證和身份驗證金鑰。映像工廠可以建立管理所需機密的通用實踐。

作為治理流程的一部分，全域工廠可以將HashiCorp的Vault或Square的Keywhiz等金鑰管理解決方案整合到基礎映像中，從而為進一步建立的所有容器映像提供共同基礎。這也將消除每個執行自己本地工廠的服務團隊重新發明輪子的需要，它允許儲存和存取機密的正確實踐成為制度化。

映像工廠中的設定管理

在容器大規模採用興起之前，Ansible、Chef和Puppet等設定管理(CM)工具幫助將給定的一組機器收斂到所需的設定。然而，隨著容器映像及其極小的佔用空間的出現，這些傳統設定管理工具的假設對容器價值有限。由於容器映像需要輕量，重型的CM方法聽起來像是一種反模式。

不過，CM工具確實有序安裝的優勢。在某些情況下，映像正在使用CM工具構建，並透過Chef-solo類別的模式進行設定，無需任何外部CM伺服器。這兩種正規化如何融合或分離，取決於容器引擎在未來幾年關於設定管理的策略走向。

自動化全域映像工廠的實踐

全域工廠是一個邏輯實體，通常用於生成可由組織中每個服務團隊採用的分享基礎容器映像。全域工廠可以實作為一組自動化工具，存在於本地工廠和Docker Hub、Quay.io、IBM Containers或其他註冊服務上託管的公共容器映像之間。

在組織環境中，自動化全域工廠必須執行以下操作：

驗證來源基礎映像，檢查是否存在有效的歷史記錄
比較基礎映像的替代方案，根據映像大小和社群強度(這指的是從Docker pulls中使用該映像的人數)
執行安全評估和漏洞掃描
建立新的結果容器清單(Dockerfile)，安裝用於除錯、監控、日誌流和金鑰儲存等的管理工具
在容器清單中向結果基礎映像增加元資料
將結果容器清單推播到版本控制系統，並將生成的映像推播到註冊函式庫全域工廠儲存。這進一步被執行自己本地工廠的各個團隊使用

淘汰舊的基礎映像

基礎映像在其生命週期中會經歷多個版本，最終被棄用。新版本全域基礎映像的發布可以傳達給各個團隊，以便對本地映像進行更改。或者，每個服務團隊的CI基礎設施可以在每次迭代時檢查基礎映像的新版本，如果舊版本仍在執行，可以觸發警告。

映像工廠模型的未來

映像工廠模型對微服務基礎設施而言是一個極其重要的實體。圍繞統一內核和Docker映像更改的新舉措承諾使映像工廠模型更加有用和相關。如果有效實施，映像工廠可以讓服務團隊變得更加獨立，實作微服務的承諾。

應用程式管理的可見性與自動化

我在雲端架構領域多年的經驗告訴我，應用程式自動化和管理的真正意義必須建立在對應用程式的可見性和協調相關服務的能力之上。Apache Brooklyn的起源和自主計算管理複雜系統的理念正是源於此。

容器技術可以類別比於過去的多執行緒、平行執行和鏈處理等技術發展—雖然容器不完全相同，但容易封裝和速度的理念是相通的。我特別關注「架構中的死亡」概念、容器堆積積疊中的訊息傳遞者角色、策略建模和容器網路功能等課題。

設定管理與協調的融合

協調：現代數位服務提供方式的分水嶺

協調是區分現代數位服務提供方式與甚至五年前做法的關鍵。這個新堆積積疊的獨特之處在於工作負載的協調。我們現在可以將伺服器執行的功能視為工作負載，而不是具有品牌的應用程式，或具有黃金主機和覆防寫的虛擬機器。

就像牛頓透過將物體運動視為消耗能量並產生力的工作單位來重新定義我們對宇宙物理學的思考方式，協調假設了計算的牛頓式重新定義。正如牛頓本人的話一樣，這種正規化對某些人來說一直很困難。

啟動協調的六大核心力量

協調現象是透過多種行業趨勢演進的匯流而產生的：

虛擬化：將程式從執行它們的伺服器硬體中解放出來
Web服務：實作程式功能之間的通訊，無需中介軟體
資料儲存：將大量資料從特定應用程式的線性陣列處理中解放出來
雲端動態：使程式所需的資源能夠按需、以精確增量進行設定
容器化：將程式及其少數依賴項封裝成可由自己的操作環境託管的緊湊套件
軟體定義網路：使工作負載設定和佈署的環境成為一個可塑性強、容錯與適應工作需求的網格

這六種力量帶來了真正分散式計算的新現實。令人驚訝的是，它們並非有意為之。這六個資訊科學分支都是為了服務於自己獨特的目的而建立的。但當它們在資料中心被聚集在一起時，它們產生了一個全新的機會，可以完全圍繞可以完成的工作來構建和管理系統。

儘管如此，協調的工作負載必須與傳統應用程式，甚至是遺留軟體共存，原因可能是實質性的或微不足道的，但不可否認。尋求在其資料中心內實施工作負載協調的組織必須制定策略，使新舊系統能夠以合理的效率協同工作，不損失生產力，並且不降低安全性。

協調採用者的思維方式

設定管理(CM)是舊堆積積疊的一部分—來自1970年代和版本控制時代的工具。在那個軟體變更被視為障礙的時代，軟體設定管理(SCM)設計了檢查點來控制變更的力量。

然而，今天的CM可能在建立共存環境中發揮關鍵作用，無論是對伺服器還是管理它們的人員而言。

在傳統虛擬化環境中，CM變得無可替代。CM的基本工作是記錄託管在虛擬機器上的應用程式所需的資源，並應用這些檔案來確定同時為多個租戶執行多個應用程式所需的資源。

CM的工作通常委託給IT部門。當工具使用的清單首次演變為類別似批處理語言的指令碼，具有術語和功能時，有人提出了系統操作員和軟體開發人員正在合併為一種工作功能的概念。DevOps是CM現代演進的副產品。

在2000年代，虛擬化使得商業CM供應商必須將其工具的重點從根據行程的需求評估轉向變更管理。快速設定虛擬機器的能力促使工程師開發以更快速度發展的開放原始碼替代方案。Chef和Puppet幫助第一批DevOps團隊為企業中工作負載的佈署方式制定了強大的指導方針和原則。

持續整合(CI)和持續佈署(CD)運動源於與Puppet和Chef等CM工具相關的效率和生產力收益的發現。IT部門被賦予了以越來越小的增量自動化版本控制的任務。他們開始進行更多的測試(並承擔部分除錯工作)，應用程式效能管理(APM)工具在測量每個增量對資料中心的影響方面發揮作用。由於Jenkins、TravisCI或其商業等價物等開放原始碼工具的流行，CI/CD運動擴充套件到軟體開發人員。

Docker的變革與傳統設定管理的角色

然後Docker出現了。Docker的原生工具設計為由開發人員使用，並幫助將容器化實踐帶給不同的團隊和IT角色。至少一項來自Evans Data的最近調查顯示，多達十分之九的組織在單獨的虛擬化封套內佈署容器化環境，主要供開發人員使用，並由IT使用傳統CM進行維護。這表明即使面對技術

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。