雲原生世界裡的 DevOps 編排

2019 年 12 月 24 日
筆記

目錄 1、概要 2、數字服務交付的三大支柱 3、動機 4、思考 5、主要參與者 6、主要收穫 7、附錄：企業軟體交付的歷史和基礎架構

1、概要

面對一系列的競爭，今天的企業正在打亂現在的行業，用以尋求實現與初創企業相同的利益。為此，企業正在學習如何使用數字交付服務的三大基石。

使用綜合的、可擴展的基礎設施平台，例如：公有雲
軟體部署到容器和微服務架構
使用一種協調開發和運維的敏捷方法構建軟體，稱為 DevOps

總之、這些能力使得企業能夠與雲原生創業公司直接競爭。同時，這些特性也不認為是完全陌生的，例如，微服務架構實現了企業一直以來的按模組交付軟體的目標。

沒有一種規模適用所有人，企業們也都是處在採用基於雲的模型的不同階段。這裡，我們考慮利用雲原生世界中DevOps編排的基本原理，並結合基於容器的基礎設施和微服務作為部署目標，以及開發和運維工作流程。

主要發現：

企業可以採用雲、微服務和DevOps的元素，但最大的好處是將他們聯合使用。
企業面臨著初創企業不具備的限制，包括遺留系統和架構、治理挑戰和更加傳統的思維和心態。
每一個支柱都在走向成熟，變得更加企業化，因此適合傳統業務和運營模式。
企業可以處於DevOps採用的不同階段，從處於開始階段到在某些方面已經實現，到成為真正的數字第一。
供應商的布局是複雜的，反映出不成熟和快速增長。決策者需要選擇能夠推動進度並最小化成本的工具和框架。

近年來，Kubernetes 已經成為一種日益流行的基於容器的微服務編排和管理技術。在後面的「主要參與者「章節，我們會關注為基於 Kubernetes 的環境提供特定附加值得供應商。這就排除了以 Kubernetes 為目標的供應商。我們認識到這並不是唯一的編排選項，也不是最適合每個場景。

2、數字服務交付的三大支柱

在雲原生的世界裡，我們如何定義 DevOps 編排？根據最近的研究表明，雲計算被企業視為首要任務，優先順序比也受到如此多關注的領域要高，數字化轉型。雲計算本身並不是終結，正如我們從」雲原生「定義可以看出，它為可擴展的應用程式提供了基礎。

那麼，將可伸縮的應用程式變成現實需要什麼？對於新一代的市場擾亂組織，雲原生必須是默認選項。我們可以把它看成三根柱子：

1. 基於雲的部署平台。公有雲作為一種豐富、全面和高度可擴展的基礎設施平台，使得初創企業能夠在不需要昂貴和很快過時的基礎設施情況下快速發展。許多供應商現在有了可以部署到私有雲環境的功能。

2. 利用微服務編排。微服務部署架構基於Docker容器（基本上是獨立的、單一的應用軟體模組），這些可以使用自動化、健壯和可擴展的編排機制和架構進行部署，如Kubernetes。容器的一個關鍵特徵是應用程式的可移植性，容器可以獨立於部署目標而存在。

3、DevOps軟體交付。敏捷開發最佳實踐和協作方法使得部署和運維進行更多迭代，在滿足業務和用戶需求的同時加速創新。當敏捷實踐獨立存在時，自動化工具用來支撐DevOps工作流的各個方面。

通過將這些能力組合在一起，使我們能夠繼續在數字化原生企業中看到創新，創造出許多傳統企業夢寐以求的速度和敏捷。儘管希望實現數字化轉型的企業可能會被數字優先模型所吸引，他們經常與自己的遺留系統和流程進行鬥爭。

什麼是」雲原生「技術？

雲原生技術已經由雲原生計算基金會定義為使組織能夠『在現代動態環境中構建和運行可擴展的應用程式，例如公有雲、私有雲和混合雲。容器，Service Mesh，微服務，不可變基礎設施和聲明性API就是這種方法的例子』。為了實現基於數字優先的服務交付目標，部署平台需要能夠支援微服務編排的原生能力，以及包括運維性能和服務管理的機制。

好消息是，上述每一項都在走向成熟，變得更加企業化，因此會更適用於傳統業務和運維模式。DevOps正在成長為最佳實踐採用更高級別的治理（以價值流管理趨勢為例）。今天的雲機制越來越適用於企業的公共和私有部署。Kubernetes正在成為微服務部署標準，最大限度的減少了重複創建輪子的需求。

基於容器的基礎設施和微服務為軟體部署提供了邊界。為希望提高大規模可擴展、靈活和分散式產品的企業提供了巨大可能。最近，他們開始將Kubernetes作為單一目標架構進行標準化，圍繞特定部署目標實施DevOps實踐創造機會。

因此，數字優先思維不再局限在初創企業，而在過去，像Netflix這樣的應用程式是需要訂製化的，我們現在有了一個標準的方法可以被任何規模的組織所採用。在下一節中，我們將深入研究導致這種情況的重要因素。

3、動機

企業為什麼要在雲原生世界裡採用 DevOps 編排？正如我們所討論過的，數字優先的總體戰略已經從「擁有很不錯」轉變為「必須擁有」，因為它已經成為差異化競爭的主要來源，特別是在日益增長的以用戶為中心的世界裡。例如，最近Gigaom研究表明，在涉及到採用 DevOps 時，以用戶為中心的標準是最重要的。

採用數字優先方法的廣泛好處如下：

更快的上市時間和實現新的業務價值。以數字優先的方式最大的好處是，組織可以在競爭前獲得新的未開發的資源。當你擁有了所有可能需要的雲基礎設施資源時，應用程式構建的方法成為了瓶頸，此時會關注並優化該問題。
商業平台的生態系統優勢。擁有一個新的商業平台會產生倍增的網路效應（如Airbnb,Salesforce, Uber, Amazon, Alibaba等等）。這個平台拉近了與客戶、合作夥伴和員工的距離，提升了員工的心態、協作和領導力。
操作更簡單、高效。通過部署到一個標準化的基礎架構，這個架構原則上是自我編排和管理的。企業也會降低基礎設施管理和運營的成本。
基礎設置選擇的靈活性。許多企業希望轉向基於雲的模型，但一直不願意或無法採用公有雲。通過標準的微服務，很多關於公有雲和私有雲，混合雲和多雲的討論就可以避免。

雖然總體目標可能是「像初創企業一樣」，但企業面臨著初創企業所沒有的限制，包括遺留系統和架構、治理、合規性、風險和傳統的思維和心態。組織可以處於DevOps採用的不同階段，面對自身的特殊情況，包括：

對於任何一個，或者數字優先的所有支柱來說，從戰略和戰術層面來看，首先要做的是什麼？

堅持一個企業預置環境：如何採用雲原生的DevOps編排，以及遷移至混合雲和多雲架構的長期規劃？
嘗試雲原生模型，但要麼過於架構化，要麼創建了太多級別的治理：如何簡化和釋放已經創建的任何瓶頸？
已經在DevOps開發端交付，但正在產生多個運營管理費用：如何做好運維端的工作，降低生產成本？

不管一個企業的目標是什麼，它都有必須向數字化轉型，以重複發揮這些在工作中使用到的技術的強大作用。

4、考慮

那麼，企業在實踐階段如何做才能採用DevOps編排和雲原生模型？根據最近的研究，我們可以看到 DevOps 和基礎設施直接的相互作用。以下圖表也顯示了標準化和（潛在的AI驅動）自動化的重要性。

在具體行動方面，考慮到每個企業都有自己的情況，驅動因素，動機，優先順序也各不相同，但下面的問題有助於確定切入點：

1、你是否是首席資訊官，希望實現董事會層面的數字化戰略轉型？ ①、圍繞微服務進行標準化是一個很好的起點，因為它創建了一個可管理、可實現的目標，與業務戰略相適應。它也直接適合企業應用程式開發的最佳實踐。 ②、第一步是定義一個可行的（即，符合IT戰略標準的），基於Kubernetes的體系架構目標。這可能是基於公有/私有雲，或者是基於兩者結合的多雲策略。 ③、在這個體系結構之後，可以與現有的開發工作流和管道集成。注意，這個體系架構不會對語言和工具施加約束。

2、你是否需要證明採用數字優先的方法來交付業務價值是成功的？ ①、考慮在工作流程和產生的業務影響方面能夠提供管理資訊的工具和機制。 ②、確保你有使用的運維工具，能夠主動處理性能和服務管理問題。

3、你的DevOps實踐是否還處在開發階段？ ①、首先要確保CI/CD能力可以與Kubernetes和微服務協同工作，作為一個部署目標。 ②、尋找在DevOps生命周期中能夠實現自動化測試、安全和治理方面的產品。使得在不犧牲品質的情況下提高交付速度。

4、你是否認為你的組織在DevOps方面相對成熟？ ①、尋找包含「基礎設施即程式碼」原則的產品，以便最大化的標準化和自動化。 ②、考慮能夠利用整個開發周期生成的數據的工具，例如，使用機器學習。

由於這仍然是一個不斷發展的領域，供應商的格局也是複雜的，也反映出了不成熟和快速增長。決策者需要選擇工具和框架來推動進展和最小化成本。

我們還建議任何企業都要關注新出現的框架和標準。我們並不是說Kubernetes會被淘汰，而是，我們期望一些標準和框架出現，特別是圍繞多雲管理和DevOps治理的框架。

5、主要參與者

下面的供應商之所以被選中，是因為他們提供了 DevOps 編排的好處，特彆強調 Kubernetes 上。我們認識到 Kubernetes 並不是唯一的目標；其他目標體系結構（如serverless）會有不同的優勢和限制，因此也需要不同的工具。

這份清單是不詳盡的，其他的廠商還有Canonical, Cloudbolt, Fission, GitLab, Google, Heroku, Jelastic, Kmesh, Kong, Kublr, Lightbend, Mesosphere, Mirantis, Octopus Deploy, Pivotal, Spinnaker, and Xebia Labs 但未包含在內。

Amazon EKS

考慮到AWS產品組合的廣度，毫無疑問，Kubernetes是通過Amazon Elastic Container Service for Kubernetes Service(Amazon EKS)作為目標提供的，Kubernetes 服務是Kubernetes 上游 100% 的服務。為了滿足自身客戶群的需求，AWS專註於通過諸如CodeDeploy，CodePipeline和Jenkins X等工具來改進Kubernetes的部署。

在編排和管理方面，AWS Fargate也值得一提——這是AWS的serverless 容器計算平台，它提供了一個將容器部署到環境中的介面，使工程師能夠專註於微服務，而不是底層的基礎設施堆棧。此外，AWS App Mesh有助於管理和配置在Amazon ECS,Amazon EKS, AWS Fargate, 和 Amazon EC2 上運行的應用程式的服務間流量，例如，Kubernetes Pods間的互連和通訊。

需要注意的是，EKS只是用於微服務編排的一個AWS容器目標：Amazon Elastic Container Service (ECS) 可能更適合某些工作負載———AWS的觀點是，客戶的需求不同，需要不同的選擇滿足這些需求。因此，AWS為雲原生、混合雲和介於二者之間的客戶提供了選項。同樣，AWS也有一些客戶使用CodeStar工具部署到AWS之外的Kubernetes，例如，他們自己的數據中心。

Bitnami

Bitnami圍繞應用程式打包建立了自己的商店，這個概念雖然針對未知論者，但卻巧妙的將基於微服務的部署映射到Kubernetes的目標環境中。Bitnami提供了一個開源優先的模型，以及其增值產品Stacksmith。在背後，Bitnami的主要收入來源於雲服務提供商，他們使用Bitnami預打包常見的應用程式的版本，如WordPress。

對於Kubernetes，公司維護了一系列用於Kuberetes預打包的應用程式（如 Helm charts），並提供Stacksmith，使得工程師團隊能夠配置、打包和維護自己的應用程式。他還提供了Kubeapps———一種基於web的工具，可以部署和管理部署到Kuberetes集群的應用程式。Kubeapps被廣泛使用並簡化了部署過程，但需要一定程度的體系結構專業知識。

在用例方面，公司的傳統關注點一直是將現有應用程式」重新平台化」，這是一個既適合打包概念又適合微服務方法的功能———即使是相對複雜的應用程式也可以作為一個容器進行部署，既封裝了它，又使附加功能能夠圍繞它構建。這種方法也有助於在不影響靈活性或控制的情況下，將IT環境置於管理之下。

CircleCI

CircleCI是一個持續集成、構建管理和部署的自動化平台，它不僅限於微服務，而且有一些有用的特性使得開發人員專註與目標環境。考慮到微服務部署往往以許多類似的、幾乎相同的存儲庫配置結束，CircleCI 創建了【檢查】概念——預定義的、經過認證的配置腳本，可以與程式碼一起管理。

與」配置即程式碼」一樣，供應商提供了一種靈活的分配模型，例如，開發者可以識別一個Docker鏡像，設置機器大小，並將其包含在一個大的工作流中。

CloudBees

Cloudbees是與非常流行的配置管理工具Jenkins最密切相關的供應商。公司的Jenkins企業級軟體提供了集成功能，使Kubernetes成為基於Jenkins的工作流的目標。基於Jenkins X，該公司提供基於GUI的自動化和管理工具，以使持續集成、交付、部署和存儲任務更流暢。

在企業部署方面，Cloudbees以其簡單性交付了它的能力。他們的目標是建立適當的防護措施，使軟體能夠保持持續的交付自動化和協作過程，同時仍然具有治理、可視性和洞察力。因此，Cloudbees主張採用價值流管理方法，在控制新風險的同時實現最佳效率。價值流管理是DevOps系列即將發布的報告的主題。

Codefresh

Codefresh為微服務和基於容器的應用程式提供了「從頭開始」構建的CI/CD管道工具。它的策略是幫助組織加快DevOps採用過程，更快地進入Kubernetes，最大限度地減少部署的開銷，然後管理目標環境。在雲原生組織之外，Codefresh的許多客戶都希望將遺留系統遷移到微服務體系結構。因此，功能超越了集成hooks，並面向企業意願，尤其是與安全性相關的功能，如單點登錄和基於角色的訪問。

除了無縫部署和自動化之外，支援DevOps編排的Codefresh功能還包括可由用戶修改的內置步驟和對特定處理器的支援。該公司還通過一個管理工具來提供運行中集群的概覽，其中包括運維監控。另一個好處是幫助組織「左移」——例如，使用codefresh可以啟用一次性部署進行測試，完成後關閉它；另一個例子是，在更廣泛推出前，它只能用於啟動需要測試的微服務。

Docker

Docker這家最初將我們稱之為容器的公司並沒有閑置，他們認識到容器只是拼圖中的一部分，因此提供了Docker Enterprise Platform ，將安全和治理、編排和自動化結合在一起，並支援認證功能來支援企業級應用程式的交付。例如，DockerTrusted Registry管理和保護從開發到生產的容器鏡像，Docker Universal Control Plane包括數據路由、身份驗證和部署後的功能。

通過支援一系列基礎設施，該公司擁有自己的編排產品（Swarm），但認識到Kubernetes周圍的興趣正在加速，並為其提供全面支援。例如，Docker Compose Yaml文件可以針對Swarm或Kubernetes部署；同時，Docker Desktop使工程師能夠創建本地環境，並將應用程式部署到筆記型電腦電腦上的Kubernetes。雖然Docker Enterprise Platform的大多數部署都是基於微服務的，但Docker還與希望將遺留應用程式遷移到容器的組織合作，其目標是在遷移之後「讓它們繼續存在」，或者使它們能夠作為基於微服務的應用程式進行後續的重新組合和後續開發。

HashiCorp

HashiCorp提供「API驅動的動態環境變得簡單」。HashiCorp的重點是使應用程式能夠以自助服務的方式提供到動態基礎設施上，例如支援Kubernetes的基於雲的平台。雖然HashiCorp提供了自己的基於集群的微服務編排產品Nomad（它與Kubernetes競爭，儘管它也可以調度非容器化的工作任務），但該公司表示，它並沒有區分不同的平台，其更大的目標是幫助組織採用微服務，無論它們使用哪個編排平台。

除了作為」基礎設施即程式碼」的產品TerraForm外，該公司還為密碼和密鑰等敏感數據提供保險庫，並為分散式應用程式管理和協調網路服務提供諮詢服務。這些功能共同提供微服務方法的可擴展性，以及企業所需的基於策略的治理需求。HashiCorp於2018年10月宣布了Kubernetes對這些產品的支援。

在滿足企業需求方面，HashiCorp致力於將組織從更線性、基於ITIL、構建—運營思維，向一個模型移動，在該模型中，開發、安全、網路、運營和其他團隊使用一個通用工具平台，以基於服務的方法相互協作。

Microsoft

Azure Kubernetes Service是微軟提供的幾個目標平台之一，它受益於與其他目標相同的組件，例如通過Azure Active Directory進行訪問控制、通過密鑰庫進行密鑰管理、通過Azure Container Registry進行容器鏡像管理和分發以及使用Azure Container Network Interface (CNI)進行網路策略管理。除了它自己的基礎設施即程式碼工具（Azure Resources Manager）之外，該公司還利用HasiCorp TerraForm定義和部署kubernetes集群。

正如預期的那樣，微軟的DevOps為CI/CD的開發者提供了全面的支援。這包括跨計劃和源程式碼控制、持續開發和集成、協作和資訊共享，與預期範圍的開放源程式碼和專有DevOps工作流工具集成，如用於構建管理的Jenkins、用於測試的Selenium和用於協作的Trello。同時，Azure Automation允許將」配置即程式碼」（基於PowerShell運行手冊，越來越多地與第三方平台（如Chef或Ansible）協作）進行持續部署、所需的狀態一致性檢查以及為生產中的應用程式預先定義監控標準。

Puppet

Puppet用描述目標基礎設施配置的「清單（manifests）」來表達「基礎設施即程式碼」。雖然Puppet的歷史性增長來自於網路規模的公司和初創企業，但近年來，該公司從企業公司那裡看到了更多的吸引力，因為他們希望採用DevOps和基礎設施自動化實踐，將領先的目標環境和遺留系統結合起來。

Puppet對其定義的環境不可知，這使公司在客戶尋求此類方法時，將自己的手轉向容器（以及最近的serverless方法）成為一種自然的發展，但在大型機環境中工作也同樣舒適。Puppet最初的前提是為系統管理員而不是開發人員解決問題，將系統管理員從日常操作的困境中釋放出來，以便他們能夠繼續進行更有價值的活動。因此，從本質上講，首要目標是發揮自動化的潛力。

特別關注 Kubernetes，Puppet提供了 Distelli，一個支援部署到 Kubernetes 集群和虛擬機的持續交付自動化平台。2018年12月，該公司發布了 Puppet Enterprise 產品的模組，以自動部署到 Kubernetes 和 Helm。這些都得到了 kream 開發環境的支援，使工程師能夠編寫針對 kubernetes 的 puppet 程式碼。

Red Hat/Ansible

RedHat提供了Open Shift，一個Kubernetes的目標平台，可以方便部署、運維和管理。這可以部署在內部數據中心或雲中，運行在Redhat Enterprise Linux之上。Red Hat Open Shift也可作為託管服務提供。同時，RedHat Ansible允許使用yaml對微服務容器進行打包和配置，CodeReady Workspaces提供了一個預構建的「Kubernetes原生」開發環境。

Red Hat為Knative做出了貢獻，並為其宣傳。Knative最初是一個用於部署到Kubernetes的Google雲項目，現在作為開放源程式碼提供，由Pivotal、SAP、IBM和其他公司提供支援。Knative組件管理部署期間的數據路由、工作負載伸縮和構建協調等任務。

在幫助企業實現微服務之旅方面，Red Hat與傳統組織和面向未來的組織合作。對於前一組來說，第一步是通過Ansible工具開始將」基礎設施即程式碼」方法自動化。這可以與CodeReady Workspaces 配合使用，以幫助組織將基於微服務的方法作為一種規範，而不是一種例外。

Weaveworks

Weaveworks是專門關注kubernetes編排提供商的一個子集。Weaveworks的企業Kubernetes平台改進了開發人員管道元素，確保了雲原生平台上的最佳實踐。與Prometheus一起，Weave Cloud自動部署到Kubernetes目標環境中進行應用程式性能監控，這兩個環境都作為完全管理的SaaS提供。Weaveworks提供了一個企業Kubernetes訂閱，Weave Cloud可以用於部署到其他kubernetes發行版，如Open Shift。

在企業採用方面，Weaveworks專註於加速雲原生方法，以滿足那些希望更快速地開發應用程式但具有可靠性的組織，這得益於Kubernetes的擴展能力。產品和服務面向基礎設施方面的運營商，重點關注如何將基於容器的平台的監控與現有的監控和管理功能集成在一起。在開發人員方面，公司提倡Gitops方法，即使用版本控制系統Git作為Kubernetes配置資訊的「真實來源」。

6、主要好處

儘管這一領域有明顯的複雜性，但它仍然受到一些簡單原則的支援，這些原則映射到企業需要創新、以未來安全的方式採用技術、構建靈活和可擴展的面向客戶的系統。為了幫助實現這些目標，希望採用數字優先的服務交付方法的組織可以

從新的體系結構開始。想想你正在嘗試構建的軟體，而不是你擁有的軟體。Kubernetes是一個安全的目標，所以從體系結構上來說，你要注意：如果你足夠努力，你可以使任何東西看起來像一個大型機。
不要試圖一次就做到這一點。雖然戰略可以而且應該是有遠見的，但它也應該被視為建立在成功基礎上的變革計劃。不會有一夜之間的「數字轉換」或任何其他簡單的改變。
從一開始就衡量成功。成功取決於你的組織的發展方向，所以要相應地制定成功的衡量標準。雖然您可以衡量自己是否以正確的方式運營，但更重要的衡量標準將圍繞業務價值。
將工具視為創新功能。當今的工具鏈和管道反映了市場的不成熟，因為幾乎沒有標準化，而且有大量的選擇。考慮到可能很難決定支援哪一種工具，最重要的是定義將對任何特定工具的依賴性降至最低的工作流，或者方法。

歸根結底，首先考慮一個目標體系結構為成功提供了一個起點。Kubernetes是一個快速出現的、經過大量測試的編排標準，它為那些希望首先通過流程和雲平台實現數字化的組織提供了一個極好的起點。

7、附錄：企業軟體交付的歷史和基礎架構

幾十年來，我們多次嘗試尋找應用程式單元的「goldilocks」大小。在20世紀70年代（可能更早），像Ed Yourdon這樣的行業知名人士會討論在最小化耦合的同時最大化內聚的中間環節：即，確保應用程式程式碼的「模組」是獨立的，對其他應用程式的依賴性最小。面向對象的概念也開始發揮作用，在這個過程中，Yourdon（和其他人）的概念可以與現實實體周圍的結構程式碼相一致，其結果是創建軟體單元：

易於部署
不太可能改變，就它們如何呈現給世界其他方面而言（即，它們的名字或介面而言）
能夠在不影響其他軟體單元的情況下進行更改

我們已經看到了各種迭代和嘗試，從良好的編碼實踐（例如，三層體系結構和其他設計模式）到Web Services，以及專有的解決方案，例如支援企業Java bean（EJB）的應用伺服器。

快進到90年代，我們看到摩爾定律在處理器能力方面達到了一個轉折點。

在過去的幾十年中，人們普遍認為工作負載將使用儘可能多的處理器資源：需要基本計算以外的任何東西的任務都會將單個機器推向極限。雖然不可能在千禧年之交之前在上面寫上日期，但是處理器的功能已經足夠強大，可以運行單一的，然後是多個硬體模擬器，每個模擬器都可以運行一個作業系統。這有兩種方式：第一，大型機器可以更好地利用可用的周期；第二，較小的工作負載可以更好地分布在可用的伺服器上。

一旦這種「虛擬機」模型變得流行起來，硬體和軟體都可以進行優化，以盡量減少它造成的開銷，例如，導致在晶片級別包含管理程式模型和虛擬化掛鉤。虛擬化也是雲計算的重要催化劑，它依賴於將高度標準化的硬體與運行在其上的程式碼分開的能力。

近年來，我們看到了這些需求的一些後果。隨著基於容器的軟體部署的到來，對「合適大小」的軟體單元的持續需求找到了完美的合作夥伴，這種部署很快就成為軟體分發的公認標準。開源方法的日益流行使得新的部署模型成為標準，特別是來自Google的Kubernetes。

翻譯自：DevOps Orchestration in a Cloud-Native World

來源：本文轉自公眾號 DevOps亮哥，點擊查看原文。