Kubernetes 實現(xiàn)灰度和藍綠發(fā)布

1. Kubernetes 中的部署策略

在本文中，我們將學(xué)習(xí)使用 Kubernetes 容器編排系統(tǒng)部署容器時的部署策略。在本文的最后，我們將學(xué)習(xí)如何在 Kubernetes 集群中使用不同的方式進行部署。如果您覺得這個話題很有趣，請繼續(xù)閱讀！本教程的代碼可在 Github上找到。

2. Kubernetes 快速介紹

容器化隨著時間的推移越來越流行，并徹底改變了構(gòu)建、傳輸和維護應(yīng)用程序的過程，因此需要有效地管理這些容器。引入了許多容器編排工具來管理這些容器在大型系統(tǒng)中的生命周期。

Kubernetes 就是這樣一種編排工具，它負責(zé)配置和部署、資源分配、負載平衡、服務(wù)發(fā)現(xiàn)、提供高可用性以及任何系統(tǒng)的其他重要方面。有了這個平臺，我們可以在開發(fā)的同時將我們的應(yīng)用程序分解成更小的系統(tǒng)（稱為微服務(wù)）；然后，我們可以在部署時組合（或編排）這些系統(tǒng)。

云原生方法的采用增加了基于微服務(wù)架構(gòu)的應(yīng)用程序的開發(fā)。對于此類應(yīng)用程序，組織面臨的最大挑戰(zhàn)之一是部署。在部署方面有一個適當(dāng)?shù)牟呗允潜匾?。?Kubernetes 中，有多種發(fā)布應(yīng)用程序的方式；在應(yīng)用程序部署或更新期間，有必要選擇正確的策略來使您的基礎(chǔ)設(shè)施可靠。例如，在生產(chǎn)環(huán)境中，始終需要確保最終用戶不會遇到任何停機時間。在 Kubernetes 編排中，正確的策略確保正確管理不同版本的容器鏡像。綜上所述，本文將主要圍繞Kubernetes中的不同部署策略展開。

3. 先決條件

為了繼續(xù)閱讀本文，我們需要一些之前使用 Kubernetes 的經(jīng)驗。如果不熟悉此平臺，請查看基本 Kubernetes 概念教程的分步介紹。在那里，您可以按照此處的說明學(xué)習(xí)所需的一切。如果需要，我們還建議您閱讀Kubernetes 文檔。

除此之外，我們還需要 kubectl，這是一個命令行界面 (CLI) 工具，使我們能夠從終端控制您的集群。如果您沒有此工具，請查看安裝 Kube Control (kubectl) 中的說明。我們還需要對 Linux 和 YAML 有基本的了解。

4. Kubernetes 中的部署是什么？

Deployment 是 Kubernetes 中的一個資源對象，它為我們的程序定義了所需的狀態(tài)。部署是聲明性的，這意味著我們不規(guī)定如何實現(xiàn)狀態(tài)。相反，我們聲明所需的狀態(tài)并允許deployment控制器以最有效的方式自動達到最終目標。deployment允許我們描述應(yīng)用程序的生命周期，例如應(yīng)用程序使用哪些Image，應(yīng)該有多少 pod，以及應(yīng)該更新它們的方式。

5. 使用 Kubernetes 部署的好處

手動更新容器化應(yīng)用程序的過程可能既耗時又乏味。Kubernetes deployment使此過程自動化且可重復(fù)。部署完全由 Kubernetes 后端管理，整個更新過程在服務(wù)器端執(zhí)行，無需客戶端交互。

此外，Kubernetes deployment controller始終監(jiān)控 Pod 和節(jié)點的健康狀況。它可以替換出現(xiàn)故障的 pod以及跳過故障的節(jié)點，確保關(guān)鍵應(yīng)用程序的連續(xù)性。

6. 部署策略

滾動更新部署Rolling Update

滾動部署是 Kubernetes 中的默認部署策略。它用新版本的 pod 一個一個地替換我們應(yīng)用程序的先前版本的 pod，而沒有任何集群停機時間。滾動部署緩慢地用新版本應(yīng)用程序的實例替換之前版本的應(yīng)用程序?qū)嵗?/p>

使用 RollingUpdate 策略時，還有兩個選項可以讓我們微調(diào)更新過程：

1. maxSurge：更新期間可以創(chuàng)建的 pod 數(shù)量超過所需的 pod 數(shù)量。這可以是副本計數(shù)的絕對數(shù)量或百分比。默認值為 25%。

2. maxUnavailable：更新過程中可能不可用的 Pod 數(shù)。這可以是副本計數(shù)的絕對數(shù)量或百分比；默認值為 25%。

首先，我們創(chuàng)建rollingupdate.yaml部署模板。在下面的模板中，我們將maxSurge設(shè)置為 2，將maxUnavailable 設(shè)置為 1。

apiVersion:?apps/v1??
kind:?Deployment??
metadata:??
??name:?rollingupdate-strategy??
??version:?nanoserver-1709??
spec:??
??strategy:??
????type:?RollingUpdate??
????rollingUpdate:??
??????maxSurge:?2??
??????maxUnavailable:?1??
??selector:??
????matchLabels:??
??????app:?web-app-rollingupdate-strategy??
??????version:?nanoserver-1709??
??replicas:?3??
??template:??
????metadata:??
??????labels:??
????????app:?web-app-rollingupdate-strategy??
????????version:?nanoserver-1709??
????spec:??
??????containers:??
????????-?name:?web-app-rollingupdate-strategy??
??????????image:?hello-world:nanoserver-1709??

然后我們可以使用 kubectl 命令創(chuàng)建部署。

$?kubectl?apply?-f?rollingupdate.yaml??

一旦我們有了deployments模板，我們就可以通過創(chuàng)建服務(wù)來提供一種訪問部署實例的方法。請注意，我們正在使用版本nanoserver-1709部署映像hello-world。因此，在這種情況下，我們有兩個label，name= web-app-rollingupdate-strategy和version= nanoserver-1709。我們將這些設(shè)置為下面服務(wù)的標簽選擇器。將此保存到“ service.yaml ”文件。

apiVersion:?v1??
kind:?Service??
metadata:???
??name:?web-app-rollingupdate-strategy??
??labels:???
????name:?web-app-rollingupdate-strategy??
????version:?nanoserver-1709??
spec:??
??ports:??
????-?name:?http??
??????port:?80??
??????targetPort:?80??
??selector:???
????name:?web-app-rollingupdate-strategy??
????version:?nanoserver-1709??
??type:?LoadBalancer??

現(xiàn)在創(chuàng)建服務(wù),將創(chuàng)建一個可在集群外訪問的負載均衡器。

$?kubectl?apply?-f?service.yaml??

運行“kubectl get deployments”檢查是否創(chuàng)建了 Deployment。如果 Deployment 仍在創(chuàng)建中，則輸出應(yīng)類似于以下內(nèi)容：

$?kubectl?get?deployments??
??
NAME?????????????????????????????READY???UP-TO-DATE???AVAILABLE???AGE??
rollingupdate-strategy???0/3?????0????????????0???????????1s??

如果我們幾秒鐘后再次運行" kubectl get 部署 "。輸出應(yīng)與此類似：

$?kubectl?get?deployments??
??
NAME?????????????????????????????READY???UP-TO-DATE???AVAILABLE???AGE??
rollingupdate-strategy???3/3?????0????????????0???????????7s??

要查看 Deployment 創(chuàng)建的 ReplicaSet (rs)，請運行kubectl get rs。輸出應(yīng)與此類似：

$?kubectl?get?rs??
??
NAME????????????????????????????????????DESIRED???CURRENT???READY???AGE??
rollingupdate-strategy-87875f5897???3?????????3?????????3???????18s??

要查看為部署運行的 3 個 pod，請運行kubectl get pods。創(chuàng)建的 ReplicaSet 確保有三個 Pod 在運行。輸出應(yīng)類似于以下內(nèi)容。

$?kubectl?get?pods??
??
NAME??????????????????????????????????????READY?????STATUS????RESTARTS???AGE?????????
rollingupdate-strategy-87875f5897-55i7o???1/1???????Running???0??????????12s?????????
rollingupdate-strategy-87875f5897-abszs???1/1???????Running???0??????????12s?????????
rollingupdate-strategy-87875f5897-qazrt???1/1???????Running???0??????????12s??

讓我們更新rollingupdate.yaml部署模板以使用hello-world:nanoserver-1809鏡像而不是hello-world:nanoserver-1709鏡像。然后使用 kubectl 命令更新現(xiàn)有運行部署的鏡像。

$?kubectl?set?image?deployment/rollingupdate-strategy?web-app-rollingupdate-strategy=hello-world:nanoserver-1809?--record??

輸出類似于以下內(nèi)容。

deployment.apps/rollingupdate-strategy?image?updated

我們現(xiàn)在正在使用版本nanoserver-1809部署映像hello-world。因此，在這種情況下，我們將不得不更新“service.yaml”中的標簽。標簽將更新為“version= nanoserver-1809 ”。我們將再次運行以下 kubectl 命令來更新服務(wù)，以便它可以選擇在新鏡像上運行的新 pod。

$?kubectl?apply?-f?service.yaml

要查看deployment的狀態(tài)，請運行下面的 kubectl 命令。

$?kubectl?rollout?status?deployment/rollingupdate-strategy??
??
Waiting?for?rollout?to?finish:?2?out?of?3?new?replicas?have?been?updated...??

再次運行以驗證部署是否成功。

$?kubectl?rollout?status?deployment/rollingupdate-strategy??
??
deployment?"rollingupdate-strategy"?successfully?rolled?out?

部署成功后，我們可以通過運行命令kubectl get deployments來查看Deployment。輸出類似于：

$?kubectl?get?deployments??
??
NAME?????????????????????????????READY???UP-TO-DATE???AVAILABLE???AGE??
rollingupdate-strategy???3/3?????0????????????0???????????7s

運行kubectl get rs以查看Deployment是否已更新。新的 Pod 在一個新的 ReplicaSet 中創(chuàng)建并擴展到 3 個副本。舊的 ReplicaSet 縮減為 0 個副本。

$?kubectl?get?rs??
??
NAME????????????????????????????????????DESIRED???CURRENT???READY???AGE??
rollingupdate-strategy-87875f5897???3?????????3?????????3???????55s??
rollingupdate-strategy-89999f7895???0?????????0?????????0???????12s??

運行kubectl get pods它現(xiàn)在應(yīng)該只顯示新ReplicaSet中的新Pod。

$?kubectl?get?pods??
??
NAME??????????????????????????????????????READY?????STATUS????RESTARTS???AGE?????????
rollingupdate-strategy-89999f7895-55i7o???1/1???????Running???0??????????12s?????????
rollingupdate-strategy-89999f7895-abszs???1/1???????Running???0??????????12s?????????
rollingupdate-strategy-89999f7895-qazrt???1/1???????Running???0??????????12s??

kubectl 的 rollout 命令在這里非常有用。我們可以用它來檢查我們的部署是如何進行的。默認情況下，該命令會等待部署中的所有 Pod 成功啟動。當(dāng)部署成功時，命令退出并返回代碼為零以表示成功。如果部署失敗，該命令將以非零代碼退出。

$?kubectl?rollout?status?deployment?rollingupdate-strategy??
??
Waiting?for?deployment?"rollingupdate-strategy"?rollout?to?finish:?0?of?3?updated?replicas?are?available…??
Waiting?for?deployment?"rollingupdate-strategy"?rollout?to?finish:?1?of?3?updated?replicas?are?available…??
Waiting?for?deployment?"rollingupdate-strategy"?rollout?to?finish:?2?of?3?updated?replicas?are?available…??
??
deployment?"rollingupdate-strategy"?successfully?rolled?out??

如果在 Kubernetes 中部署失敗，部署過程會停止，但失敗部署中的 pod 會保留下來。在部署失敗時，我們的環(huán)境可能包含來自舊部署和新部署的 pod。為了恢復(fù)到穩(wěn)定的工作狀態(tài)，我們可以使用 rollout undo 命令來恢復(fù)工作 pod 并清理失敗的部署。

$?kubectl?rollout?undo?deployment?rollingupdate-strategy??
??
deployment.extensions/rollingupdate-strategy??

然后我們將再次驗證部署的狀態(tài)。

$?kubectl?rollout?status?deployment?rollingupdate-strategy??
??
deployment?"rollingupdate-strategy"?successfully?rolled?out??

為了讓 Kubernetes 知道應(yīng)用程序何時準備就緒，它需要應(yīng)用程序的一些幫助。Kubernetes 使用就緒探針來檢查應(yīng)用程序的運行情況。一旦應(yīng)用程序?qū)嵗_始以肯定響應(yīng)響應(yīng)就緒探測，該實例就被認為可以使用了。就緒探針會告訴 Kubernetes 應(yīng)用程序何時準備就緒，但不會告訴 Kubernetes 應(yīng)用程序是否準備就緒。如果應(yīng)用程序不斷失敗，它可能永遠不會對 Kubernetes 做出積極響應(yīng)。

滾動部署通常會在縮小舊組件之前通過就緒檢查等待新 Pod 準備就緒。如果發(fā)生重大問題，可以中止?jié)L動部署。如果出現(xiàn)問題，可以中止?jié)L動更新或部署，而無需關(guān)閉整個集群。

重新創(chuàng)建部署

在重新創(chuàng)建部署中，我們在擴展新應(yīng)用程序版本之前完全縮減現(xiàn)有應(yīng)用程序版本。在下圖中，版本 1 表示當(dāng)前應(yīng)用程序版本，版本 2 表示新應(yīng)用程序版本。在更新當(dāng)前應(yīng)用程序版本時，我們首先將版本 1 的現(xiàn)有副本縮減為零，然后與新版本并發(fā)部署副本。

下面的模板顯示了使用重新創(chuàng)建策略的部署：首先，我們通過將以下 yaml 保存到文件 recreate.yaml 來創(chuàng)建我們的重新創(chuàng)建部署

apiVersion:?apps/v1??
kind:?Deployment??
metadata:??
??name:?recreate-strategy??
spec:??
??strategy:??
????type:?Recreate??
??selector:??
????matchLabels:??
??????app:?web-app-recreate-strategy??
??????version:?nanoserver-1809??
??replicas:?3??
??template:??
????metadata:??
??????labels:??
????????app:?web-app-recreate-strategy??
????spec:??
??????containers:??
????????-?name:?web-app-recreate-strategy??
??????????image:?hello-world:nanoserver-1809??

然后我們可以使用 kubectl 命令創(chuàng)建部署。

$?kubectl?apply?-f?recreate.yaml??

一旦我們有了部署模板，我們就可以通過創(chuàng)建服務(wù)來提供一種訪問部署實例的方法。請注意，我們正在使用版本nanoserver-1809部署映像hello-world。所以在這種情況下，我們有兩個標簽，“name= web-app-recreate-strategy ”和“version= nanoserver-1809 ”。我們將這些設(shè)置為下面服務(wù)的標簽選擇器。將其保存到service.yaml文件中。

apiVersion:?v1??
kind:?Service??
metadata:???
??name:?web-app-recreate-strategy??
??labels:???
????name:?web-app-recreate-strategy??
????version:?nanoserver-1809??
spec:??
??ports:??
????-?name:?http??
??????port:?80??
??????targetPort:?80??
??selector:???
????name:?web-app-recreate-strategy??
????version:?nanoserver-1809??
??type:?LoadBalancer??

現(xiàn)在創(chuàng)建服務(wù)將創(chuàng)建一個可在集群外訪問的負載均衡器。

$?kubectl?apply?-f?service.yaml??

重新創(chuàng)建方法在更新過程中涉及一些停機時間。對于可以處理維護窗口或中斷的應(yīng)用程序，停機時間不是問題。但是，如果存在具有高服務(wù)級別協(xié)議 (SLA) 和可用性要求的關(guān)鍵任務(wù)應(yīng)用程序，則選擇不同的部署策略將是正確的方法。Recreate 部署一般用于開發(fā)者的開發(fā)階段，因為它易于設(shè)置，并且應(yīng)用程序狀態(tài)會隨著新版本完全更新。此外，我們不必并行管理多個應(yīng)用程序版本，因此我們避免了數(shù)據(jù)和應(yīng)用程序的向后兼容性挑戰(zhàn)。

藍綠部署

在藍/綠部署策略（有時也稱為紅/黑）中，藍色代表當(dāng)前應(yīng)用版本，綠色代表新應(yīng)用版本。在這種情況下，一次只有一個版本處于活動狀態(tài)。在創(chuàng)建和測試綠色部署時，流量被路由到藍色部署。完成測試后，我們將流量路由到新版本。

部署成功后，我們可以保留藍色部署以備回滾或者回退?；蛘?，可以在這些實例上部署較新版本的應(yīng)用程序。在這種情況下，當(dāng)前（藍色）環(huán)境用作下一個版本的暫存區(qū)。

這種技術(shù)可以消除我們在重新創(chuàng)建部署策略中遇到的停機時間。此外，藍綠部署降低了風(fēng)險：如果我們在 Green 上的新版本發(fā)生意外，我們可以通過切換回 Blue 立即回滾到上一個版本。我們還可以避免版本問題；整個應(yīng)用程序狀態(tài)在一次部署中更改。

藍綠部署成本高昂，因為它需要雙倍的資源。在將其發(fā)布到生產(chǎn)環(huán)境之前，應(yīng)對整個平臺進行適當(dāng)?shù)臏y試。此外，處理有狀態(tài)的應(yīng)用程序很困難。

首先，我們通過將以下 yaml 保存到“blue.yaml”文件來創(chuàng)建藍色部署：

apiVersion:?apps/v1??
kind:?Deployment??
metadata:??
??name:?blue-deployment??
spec:??
??selector:??
????matchLabels:??
??????app:?blue-deployment??
??????version:?nanoserver-1709??
??replicas:?3??
??template:??
????metadata:??
??????labels:??
????????app:?blue-deployment??
????????version:?nanoserver-1709??
????spec:??
??????containers:??
????????-?name:?blue-deployment??
??????????image:?hello-world:nanoserver-1709??

然后我們可以使用 kubectl 命令創(chuàng)建部署。

$?kubectl?apply?-f?blue.yaml

一旦我們有了部署模板，我們就可以通過創(chuàng)建服務(wù)來提供一種訪問部署實例的方法。請注意，我們正在使用版本nanoserver-1809部署映像hello-world。所以在這種情況下，我們有兩個標簽，“name= blue-deployment ”和“ version= nanoserver-1709 ”。我們將這些設(shè)置為下面服務(wù)的標簽選擇器。將其保存到service.yaml文件中。

apiVersion:?v1??
kind:?Service??
metadata:???
??name:?blue-green-service??
??labels:???
????name:?blue-deployment??
????version:?nanoserver-1709??
spec:??
??ports:??
????-?name:?http??
??????port:?80??
??????targetPort:?80??
??selector:???
????name:?blue-deployment??
????version:?nanoserver-1709??
??type:?LoadBalancer??

現(xiàn)在創(chuàng)建服務(wù)將創(chuàng)建一個可在集群外訪問的負載均衡器。

$?kubectl?apply?-f?service.yaml??

我們現(xiàn)在有以下設(shè)置。

對于綠色部署，我們將在_藍色_部署的同時部署一個新部署。下面的模板是文件的內(nèi)容：green.yaml

apiVersion:?apps/v1??
kind:?Deployment??
metadata:??
??name:?green-deployment??
spec:??
??selector:??
????matchLabels:??
??????app:?green-deployment??
??????version:?nanoserver-1809??
??replicas:?3??
??template:??
????metadata:??
??????labels:??
????????app:?green-deployment??
????????version:?nanoserver-1809??
????spec:??
??????containers:??
????????-?name:?green-deployment??
??????????image:?hello-world:nanoserver-1809??

請注意，鏡像hello-world:nanoserver-1809標記名稱已更改為 2。因此我們使用兩個標簽進行了單獨部署，名稱= green-deployment和 version= nanoserver-1809。

$?kubectl?apply?-f?green.yaml??

為了切換到_綠色_部署，我們將更新現(xiàn)有服務(wù)的選擇器。編輯 service.yaml 并將選擇器版本更改為_2_并將名稱更改為green-deployemnt。這將使它與綠色“部署”上的 pod 相匹配。

apiVersion:?v1??
kind:?Service??
metadata:???
??name:?blue-green-service??
??labels:???
????name:?green-deployment??
????version:?nanoserver-1809??
spec:??
??ports:??
????-?name:?http??
??????port:?80??
??????targetPort:?80??
??selector:???
????name:?green-deployment??
????version:?nanoserver-1809??
??type:?LoadBalancer??

我們使用 kubectl 命令再次創(chuàng)建服務(wù)：

$?kubectl?apply?-f?service.yaml??

因此得出結(jié)論，我們可以看到藍綠部署是全有或全無，不像滾動更新部署，我們無法逐步推出新版本。所有用戶將同時收到更新，但允許現(xiàn)有會話在舊實例上完成他們的工作。因此，一旦我們啟動更改，風(fēng)險就比一切都應(yīng)該工作的要高一些。它還需要分配更多的服務(wù)器資源，因為我們需要運行每個 Pod 的兩個副本。

幸運的是，回滾過程同樣簡單：我們只需再次撥動開關(guān)，先前的版本就被換回原位。那是因為舊版本仍在舊 Pod 上運行。只是流量不再被路由到他們。當(dāng)我們確信新版本會繼續(xù)存在時，我們應(yīng)該停用這些 pod。

金絲雀部署

Canary 更新策略是一個部分更新過程，它允許我們在真實用戶群上測試我們的新程序版本，而無需承諾全面推出。類似于藍/綠部署，但它們更受控制，并且它們使用更漸進的交付方式，其中部署是分階段進行的。有許多策略屬于金絲雀的保護傘，包括暗發(fā)布或 A/B 測試。

在金絲雀部署中，新版本的應(yīng)用程序逐漸部署到Kubernetes集群，同時獲得極少量的實時流量（即，一部分實時用戶正在連接到新版本，而其余的仍在使用以前的版本） .在這種方法中，我們有兩個幾乎相同的服務(wù)器：一個用于所有當(dāng)前活躍用戶，另一個帶有新功能，用于向一部分用戶推出然后進行比較。當(dāng)沒有錯誤報告并且信心增加時，新版本可以逐漸推廣到基礎(chǔ)架構(gòu)的其余部分。最后，所有實時流量都流向金絲雀，使金絲雀版本成為新的生產(chǎn)版本。

下圖顯示了進行金絲雀部署的最直接和最簡單的方法。新版本部署到服務(wù)器的子集。

在發(fā)生這種情況時，我們會觀察升級后的機器的運行情況。我們檢查錯誤和性能問題，并聽取用戶反饋。隨著我們對金絲雀越來越有信心，我們繼續(xù)在其余機器上安裝它，直到它們都運行最新版本。

在規(guī)劃金絲雀部署時，我們必須考慮各種因素：

1. 階段：我們將首先向金絲雀發(fā)送多少用戶，以及在多少階段。

2. 持續(xù)時間：我們計劃運行金絲雀多久？Canary 版本不同，因為我們必須等待足夠多的客戶端更新才能評估結(jié)果。這可能會在幾天甚至幾周內(nèi)發(fā)生。

3. 指標：記錄哪些指標以分析進度，包括應(yīng)用程序性能和錯誤報告？精心選擇的參數(shù)對于成功部署 Canary 至關(guān)重要。例如，衡量部署的一種非常簡單的方法是通過 HTTP 狀態(tài)代碼。我們可以有一個簡單的 ping 服務(wù)，當(dāng)部署成功時返回 200。如果部署中存在問題，它將返回服務(wù)器端錯誤 (5xx)。

4. 評估：我們將使用什么標準來確定金絲雀是否成功

Canary 用于我們必須在應(yīng)用程序后端測試新功能的場景。當(dāng)我們對新版本不是 100% 有信心時，應(yīng)該使用 Canary 部署；我們預(yù)測我們失敗的可能性很小。當(dāng)我們進行重大更新時，通常會使用此策略，例如添加新功能或?qū)嶒炐怨δ堋?/p>

7.K8s 部署策略總結(jié)

總而言之，部署應(yīng)用程序有多種不同的方式；當(dāng)發(fā)布到開發(fā)/暫存環(huán)境時，重新創(chuàng)建或升級部署通常是一個不錯的選擇。在生產(chǎn)方面，藍/綠部署通常很合適，但需要對新平臺進行適當(dāng)?shù)臏y試。如果我們對平臺的穩(wěn)定性以及發(fā)布新軟件版本可能產(chǎn)生的影響沒有信心，那么金絲雀版本應(yīng)該是我們要走的路。通過這樣做，我們讓消費者測試應(yīng)用程序及其與平臺的集成。在本文中，我們只觸及了 Kubernetes 部署功能的皮毛。通過將部署與所有其他 Kubernetes 功能相結(jié)合，用戶可以創(chuàng)建更強大的容器化應(yīng)用程序以滿足任何需求。

文章轉(zhuǎn)載：DevOps技術(shù)棧
（版權(quán)歸原作者所有，侵刪）