[[354158]]

 Spinnaker是最初由Netflix設計和開發的開源多云連續交付工具。它有助于將應用程序部署到各種云提供商，例如Google Cloud Platform(GCP)，Amazon Web Services(AWS)和Microsoft Azure。

該博客的目的是幫助開發人員，架構師和商業從業人員了解采用Kubernetes環境時使用Spinnaker的重要性。您將了解：

• Spinnaker在Kubernetes環境中的作用
• 在Kubernetes環境中使用Spinnaker
• 了解Spinnaker的架構
• 使用Spinnaker設計持續交付管道
• 解釋Spinnaker管道工作流程
• 使用Spinnaker設計持續交付管道的最佳實踐

Spinnaker在Kubernetes環境中的作用

由于其在管理多容器環境中的簡便性，各種組織都采用Kubernetes。但是，Kubernetes不是像Jenkins或Spinnaker這樣的持續交付或部署工具。早期，Kubernetes生態系統缺少一個簡單的持續交付工具來自動構建Kubernetes清單，測試這些工件并部署這些工件。Jenkins支持在Kubernetes集群上持續交付應用程序，但是增加了復雜性。

Spinnaker支持在Kubernetes集群上部署應用程序。它簡化了此過程，并幫助組織在Kubernetes集群上部署了生產級的構建工件。

Spinnaker還通過其圖形用戶界面(GUI)用于管理Kubernetes集群上部署的應用程序。可以編輯和更新Kubernetes清單文件，以提供動態編輯Kubernetes特定屬性的功能。借助Spinnaker GUI，您還可以監控Kubernetes對象的運行狀況。

在Kubernetes環境中使用Spinnaker

Spinnaker得到了各種云提供商的支持，例如App Engine，Amazon Web Services(AWS)，Azure，Google Cloud Platform(GCP)，Cloud Foundry，Oracle和Kubernetes。在云上將Spinnaker與Kubernetes一起安裝時，它將提供Kubernetes本機，基于清單的部署。Spinnaker使用一個帳戶對Kubernetes集群進行身份驗證。

在Kubernetes環境中Spinnaker的關鍵功能是應用程序管理和應用程序部署。應用程序管理功能有助于管理和查看Kubernetes集群對象。可以使用Spinnaker在Kubernetes對象上執行各種操作，例如擴展，縮小，回滾和前進。Spinnaker的此功能有助于從單個點(即Spinnaker GUI)管理多個Kubernetes集群。

Spinnaker的應用程序部署功能用于在Kubernetes集群中部署各種對象。Spinnaker在Kubernetes集群中部署應用程序時支持各種部署策略，例如Blue/Green，滾動更新，canary部署等。要執行應用程序部署，Spinnaker使用管道和階段。借助Spinnaker管道，您可以創建持續的交付流程，以將代碼從源代碼管理工具自動部署到Kubernetes集群。您還可以使用Spinnaker階段在將任何內容部署到生產Kubernetes集群上之前執行代碼驗證。

了解Spinnaker的架構

Spinnaker由獨立的微服務組件組成。下面提到其中一些組件：

• Deck：提供與Spinnaker工具交互的用戶界面。
• Gate：充當API網關。它將所有API請求傳遞給服務。
• Orca：處理各種臨時操作并管理管道及其階段。
• Clouddriver：云提供商。充當Spinnaker與云提供商之間的集成點。
• Front50：保留應用程序，管道和項目的元數據。
• Rosco：烘焙映像，然后將其部署在各種云提供商上。
• Igor：通過諸如Jenkins和Travis CI的持續集成平臺觸發管道。
• Echo：通過電子郵件，短信和Slack發送通知。它還負責傳入的Webhooks，例如Github Webhooks和Jenkins Webhooks。
• Fiat：充當Spinnaker的授權服務。
• Kayenta：為Spinnaker提供自動化的金絲雀分析。
• Halyard：一種配置服務，用于安裝，更新和配置Spinnaker。

使用Spinnaker設計持續交付管道

創建了一個持續交付管道，以在兩個不同的Kubernetes命名空間(即DEV和UAT)上部署Kubernetes清單和應用程序構建(docker鏡像)。要創建一個持續交付管道，您需要一個Helm Charts作為Kubernetes清單文件的模板，Spinnaker正在使用該清單創建最終可部署的Kubernetes清單工件。

您可以創建五個單獨的Spinnaker管道，如下所述：

1. DEV-Kubernetes集群的YAML文件更改部署流水線：此管道用于在Kubernetes集群的DEV名稱空間上部署，觸發條件是Kubernetes清單文件發生了更改(dev.yaml)。
2. UAT-Kubernetes集群的YAML文件更改部署流水線：此管道用于在Kubernetes集群的UAT名稱空間上部署，觸發條件是Kubernetes清單文件發生了更改(uat.yaml)。
3. DEV – Docker鏡像–應用程序部署流水線：此管道用于代碼更改后構建Docker鏡像并部署在Kubernetes集群的DEV名稱空間上。
4. UAT – Docker鏡像–應用程序部署流水線：此管道用于代碼更改后構建Docker鏡像并部署在Kubernetes集群的UAT名稱空間上。
5. UAT-Jenkins手動Docker鏡像部署流水線：此管道用于代碼更改后構建Docker鏡像并手動部署在Kubernetes集群的UAT命名空間上。它使用戶可以在UAT名稱空間上手動部署所需的應用程序代碼(Docker鏡像)。上面提到的兩個Spinnaker管道分別在DEV和UAT名稱空間上自動部署代碼。它使用戶可以控制在UAT名稱空間上部署的應用程序代碼(Docker鏡像)。

 解釋Spinnaker管道的工作流程

計劃部署的Kubernetes清單文件和應用程序代碼(Docker鏡像)現在應該推送到GitHub存儲庫。

• 在GitHub上配置Webhook，自動將更改通知推送到Jenkins，Jenkins配置有作業以自動檢測GitHub中的應用程序代碼更改。
• Jenkins作業獲取最新的應用程序代碼更改并構建Docker鏡像。使用Docker插件或者是原生的dockerCLI指令，Jenkins將新創建的鏡像推送到Docker Hub。
• 相應的Spinnaker管道在自動觸發器的幫助下持續監視Docker Hub注冊表。
• 在Docker Hub注冊表中獲取到最新的Docker鏡像后，您可以執行Spinnaker管道觸發器并將相應的應用程序代碼(Docker鏡像)部署在Kubernetes集群的DEV/UAT名稱空間上。

讓我們詳細討論每個管道。

用于DEV和UAT的Kubernetes集群管道的YAML文件更改部署流水線

該Spinnaker管道包括四個階段-配置、Jenkins、Bake(清單)和Deploy(清單)。

• 配置階段是一個自動觸發器，配置為檢測dev.yml 或者 uat.yml文件中的提交更改。如果這些文件中有更改，則將開始執行此管道。
• Jenkins階段向Jenkins作業發送觸發器，該作業在現有的Kubernetes集群上執行一組Linux命令(構建鏡像指令)，以檢測最近部署的Docker鏡像標簽。此階段確保不使用latest的Docker鏡像標記和更新現有的Docker鏡像。之后，Jenkins階段將現有的Docker映像標簽記錄在一個文本文件中(例如，build_uat_yml.properties)。 

稍后，文本文件將傳遞到下一個Spinnaker階段，即Bake(清單)。

• 此階段配置有一個模板，該模板包含鏡像標簽的變量為“ {{.Values.image.tag}}”。spinnaker用build_uat_yml.properties/ build_dev_yml.properties文件中存在的鍵值替換此變量值。

然后，Spinnaker創建一個最終的構建工件，其中包含清單值和Jenkins作業記錄的Docker鏡像標簽值。

• 部署(清單)階段使用此最終工件，并將此清單構建工件部署在DEV/UAT名稱空間上，而無需更新現有Docker鏡像標簽。

DEV – Docker鏡像-應用程序部署管道

此Spinnaker管道包括三個階段：配置，烘焙(清單)和部署(清單)。

• Configure階段配置有自動觸發器，以在Docker Hub注冊表中檢測新推送的Docker映像。
• Bake(Manifest)階段用于根據現有的Helm模板和已定義的dev.yml值文件創建Kubernetes清單文件。最終工件是使用帶有“最新”標簽的Docker鏡像創建的。
• 部署(清單)階段使用最終工件，并將其部署在已配置的Kubernetes集群的DEV名稱空間中。

UAT – Docker鏡像-應用程序部署管道

該管道使用與上述相同的流程從現有的Helm模板和已定義的uat.yml值文件創建最終工件。唯一的區別是，在此階段，將自動觸發器配置為“ DEV – Docker鏡像–應用程序部署”管道的執行結果。“ DEV – Docker鏡像–應用程序部署”管道的成功執行/完成將開始管道的執行。如果“ DEV-Docker鏡像-應用程序部署”管道的執行進入失敗狀態，則該管道將永遠不會開始執行，這將防止在Kubernetes集群的UAT名稱空間中部署失敗的工件。

UAT-Jenkins手動Docker鏡像部署管道

該管道可幫助用戶根據需要在UAT名稱空間中部署舊的Docker鏡像工件。用戶提供所需的Docker鏡像標簽，該標簽將通過參數化的Jenkins作業進行部署，該作業會創建文本文件(例如build.properties)，并將用戶提供的Docker鏡像作為內容。例如– IMAGE_TAG = v15。這里，v15是用戶提供的鏡像標簽。

將build.properties文件作為輸入傳遞到Spinnaker管道。

• 烘烤(清單)階段配置有一個模板，該模板包含鏡像標簽的變量為“ {{.Values.image.tag}}”。Spinnaker將該變量值替換為build-properties文件中存在的鍵值。然后，Spinnaker將創建最終的構建工件，其中包含清單值和用戶傳遞的Docker鏡像標簽值。
• 部署(清單)階段使用此最終工件，并通過使用提到的標簽拉出相應的Docker鏡像，將該清單構建工件部署在UAT名稱空間上。

使用Spinnaker設計持續交付管道的最佳實踐

• Spinnaker提供的GUI允許用戶執行應用程序管理，例如通過GUI直接編輯Kubernetes對象YAML定義文件。但是大多數時候，源代碼管理工具用于存儲和版本化Kubernetes對象YAML定義文件。在這種情況下，通過Spinnaker GUI完成的任何YAML文件更改都將在下一次管道部署期間被覆蓋。因此，強烈建議對存儲在源代碼管理工具中的YAML文件進行更改，而不是直接通過Spinnaker GUI編輯YAML文件。
• 使用Docker鏡像推送而不是GitHub推送觸發器或Jenkins作業觸發器配置Spinnaker管道觸發器。這種做法避免了構建和驗證系統的重組。
• 不要在Docker鏡像中烘焙Secrets。應在運行時使用云提供商的密鑰管理服務加載機密。
• 使用審核日志來確定已執行的操作，執行的時間以及執行的人。最佳實踐是通過將Spinnaker與GCP Stackdriver和AWS CloudWatch等云監控服務集成來生成Spinnaker審核日志。
• 通過Kubernetes對象YAML文件在Kubernetes集群上部署Docker鏡像。在YAML文件中定義Docker鏡像有兩種方法，即通過定義鏡像標簽或定義鏡像摘要。最佳實踐是通過摘要在YAML文件中定義Docker鏡像。這種方法將確保部署的Docker鏡像始終指向相同的內容。

Spinnaker是一個強大的持續交付工具，用于自動在Kubernetes集群上部署應用程序。Spinnaker管道也可以配置為在執行實際部署之前對構建工件執行單元測試和功能測試。因此，Spinnaker可以幫助組織更快地將代碼獲取到生產環境。