DevOps 教程：Docker、Kubernetes 和 Azure DevOps

在這篇文章中，我們將學習有關DevOps以及它與敏捷方法論的不同之處。我們也將介紹一些熱門的DevOps工具及它們在DevOps生命週期中的角色。

您將學到

• Docker、Kubernetes和Azure DevOps是什麼
• 什麼是DevOps，為什麼我們需要它？
• DevOps與敏捷方法論有何不同？
• 一些重要的DevOps工具是什麼？
• Docker如何幫助DevOps？
• Kubernetes如何幫助DevOps？
• Azure DevOps如何幫助DevOps？
• 什麼是持續整合和持續交付（CI/CD）？
• 什麼是基礎架構即代碼？
• Terraform和Ansible如何幫助DevOps？

Docker

Docker是一個用於構建、測試和部署容器化應用程式的開源軟體工具。對了，什麼是容器化？容器化是將所有庫和文件與應用程式代碼捆綁在一個稱為“容器”的單元中的概念，從而使其可以在任何基礎架構上運行。

Kubernetes

Kubernetes是一個容器编排系统，用於管理容器化的應用程序和服務。它負責在容器化環境中執行的任務，如擴展、部署、負載平衡等。Kubernetes具有可移植性、效率高和成本效益高等特點，並提供系統集成、基於API的支持等功能。

Azure DevOps

Azure DevOps是微軟的產品，提供各種工具和功能，使軟體開發和部署過程更快速、有組織。它提供一套流程，讓軟體開發人員、專案經理和其他貢獻者共同開發軟體。它可以添加到現有的編輯器或IDE中，讓團隊能夠有效地開展各種規模的專案。 

讓我們從一個簡單的使用案例開始。

免費課程 – 以10個步驟學習

• 以10個步驟學習Docker
• 以10個步驟學習Kubernetes
• 以10個步驟學習AWS

什麼是DevOps？

與大多數軟體開發中的流行詞彙一樣，DevOps 並沒有公認的定義。

定義從簡單的（如以下定義）到複雜的（可能跨越整本書的頁面）各不相同。

DevOps 是將 文化哲學、實踐和工具 結合在一起，從而 提升 組織 交付應用程式和服務 的能力，以 高速度 進行交付——亞馬遜網路服務（AWS）

與其試圖定義 DevOps，不如了解軟體開發如何演變為 DevOps。

瀑布模型

瀑布模型 是一種遵循結構化方法的工作方法。它由六個階段組成：需求、設計、實施、測試、部署和維護。每個階段都基於前一階段的完成。它在這些階段中推進，而不會重新訪問早期的過程，這使其成為一個線性過程。

軟體開發的最初幾十年圍繞著瀑布模型展開，並且在處理軟體開發時，方法與構建房地產項目（例如，建造橋樑）相同。

您將在多個階段中構建軟體，這些階段可能持續幾週到幾個月不等。

在大多數瀑布項目中，企業在幾個月後才能看到應用程式的可工作版本。

構建優秀軟體的關鍵要素

在瀑布模型工作了幾十年後，我們了解到開發優秀軟體的一些關鍵要素：

• 溝通
• 回饋
• 自動化

溝通的重要性

人與人之間的溝通對軟體專案的成功至關重要。

在瀑布模型中，我們試圖通過準備1000頁的需求、設計、架構和部署文件來增強溝通。

但是，隨著時間的推移，我們發現：

• 增進團隊內部溝通的最佳方式是讓他們聚在一起。並在同一團隊中融入各種技能。
• 具有廣泛技能的跨職能團隊效果很好。

及早回饋的重要性

快速獲取回饋是重要的。建立優秀軟體的關鍵在於快速獲取回饋。

• 我們是否在開發符合業務期望的應用程式？
• 如果將您的應用程式部署到生產環境，是否會出現問題？

您不希望幾個月後才發現問題。您希望盡早發現，因為問題越早發現，修復起來就越容易。

我們發現最優秀的軟體團隊結構設計能夠快速獲取回饋。

自動化的重要性

自動化至關重要。軟體開發涉及各種活動。手動操作緩慢且容易出錯。我們明白尋找引入自動化機會至關重要。

了解了開發優秀軟體的關鍵要素後，讓我們來看看我們是如何演進到敏捷和DevOps的。

演進至敏捷

敏捷是一種強調增量進展、頻繁反饋以及能夠回應開發生命週期中變化需求的方法。敏捷促進跨職能團隊在短期開發循環中合作，這有助於持續改進並快速為最終用戶提供價值。這是朝向實施我們學到的知識並增強團隊間溝通、獲得反饋和引入自動化的演進的第一步。

敏捷將業務和開發團隊結合到一個團隊中，共同努力以小型迭代（稱為Sprints）來開發優秀軟體。

敏捷不再花費週或月來進行開發的每個階段，而是專注於在幾天內（有時甚至同一天內）將被稱為使用者故事的小需求通過開發週期。

敏捷如何增強團隊間溝通？

敏捷將業務和開發團隊結合在一起。

• 業務負責確定要建造什麼。需求是什麼？
• 開發負責構建符合需求的產品。開發包括參與軟體設計、編碼、測試和打包的所有人。

在敏捷開發中，來自業務部門的代表，稱為產品負責人，始終與團隊在一起，團隊清楚了解業務目標。

當開發團隊不理解需求並走錯路時，產品負責人幫助他們進行調整，讓他們保持正確的方向。

結果：團隊建立的最終產品是業務所需的。

另一個重要因素是敏捷團隊具有跨職能技能：編碼技能（前端、API 和數據庫）、測試技能和業務技能。這有助於加強需要共同合作構建優秀軟件的人員之間的溝通。

敏捷與自動化

敏捷團隊關注的自動化領域有哪些？

軟件產品可能存在各種缺陷：

• 功能缺陷意味著產品無法按預期工作。
• 技術缺陷使軟件維護變得困難。例如，代碼質量問題。

一般來說，敏捷團隊專注於盡早使用自動化工具來發現技術和功能缺陷。

敏捷團隊還極為關注代碼質量。像 SONAR 這樣的工具被用來評估應用程式的代碼質量。

擁有優秀的自動化測試和優秀的代碼質量檢查是否足夠？關鍵在於頻繁運行這些流程。敏捷團隊強調持續集成，即提交到版本控制將觸發一系列操作。這包括運行單元測試、自動化測試和代碼質量檢查，全部無縫集成到持續集成流水線中。Jenkins，在早期敏捷時代被廣泛採用的CI/CD工具，在協調這些自動化流程中發揮了關鍵作用。

敏捷如何促進即時反饋？

最重要的因素是業務不需要等待數月才能看到最終產品。在每個迭代結束時，產品會向所有利益相關者展示，包括架構和業務團隊。所有反饋都會被納入考慮，同時為下一個迭代的用戶故事排序。結果：團隊建立的最終產品是業務所需的。

促使即時反饋的另一個重要因素是持續集成。比如我提交代碼到版本控制。在30分鐘內，如果我的代碼導致單元測試失敗或集成測試失敗，我將得到反饋。如果我的代碼不符合代碼質量標準，或者單元測試中的代碼覆蓋率不足，我也會得到反饋。

敏捷成功了嗎？是的。當然。通過專注於改善業務和開發團隊之間的溝通，並專注於早期發現各種缺陷，敏捷將軟件開發推向了新的水平。

我有幸與一些出色的團隊合作，使用敏捷方法工作。對我而言，軟體工程代表了從需求到將應用程式上線的所有努力，第一次感覺像編程一樣令人愉快。

但進化難道停止了嗎？不是的。

出現了新挑戰。

微服務架構的演進

我們開始轉向微服務架構，開始建立多個小型API，而不是建立大型單體應用程式。

新的挑戰是什麼？

運營變得更為重要。現在，您每週要進行數百次小型微服務發佈，而不是每月發佈一次單體應用程式。跨微服務進行故障排除，以及瞭解微服務發生了什麼問題變得重要。

軟體開發出現了一個新的流行詞。DevOps。

DevOps的出現

DevOps的重點是什麼？

DevOps的重點是增強開發和運營團隊之間的溝通。

• 我們如何使部署更加容易？
• 如何使運營團隊的工作更能被開發團隊看到？

DevOps如何增強團隊之間的溝通？

DevOps將運營團隊拉近到開發團隊。

• 在更成熟的企業中，開發和運營團隊合作成為一個團隊。他們開始共享共同目標，兩個團隊都開始了解對方所面臨的挑戰。
• 在企業中，在 DevOps 演進的早期階段，運營團隊的代表可以參與冲刺 – 早會和回顧會議。

DevOps 團隊專注於哪些自動化領域？

除了敏捷的焦點領域 – 持續集成和測試自動化 – DevOps 團隊還專注於幫助自動化幾項運營團隊的活動，如提供伺服器、配置伺服器上的軟體、部署應用程式和監控生產環境。一些關鍵術語包括持續部署、持續交付和基礎設施即程式碼。

持續部署是指持續在測試環境部署新版本的軟體。在像 Google 和 Facebook 這樣更成熟的組織中，持續交付有助於持續將軟體部署到生產環境 – 可能每天部署數百個生產版本。

基礎設施即程式碼是指將基礎設施視為應用程式程式碼一樣對待。您可以使用配置的自動化方式創建基礎設施 – 伺服器、負載平衡器和資料庫。您應該對基礎設施進行版本控制 – 這樣您就可以跟蹤一段時間內的基礎設施變更。

DevOps 如何促進即時反饋？

DevOps將運營和開發團隊聚集在一起。由於運營和開發是同一團隊的一部分，整個團隊都了解與運營和開發相關的挑戰。

• 任何運營問題都會迅速得到開發人員的關注。
• 將軟件投入使用遇到的任何挑戰都會及早得到運營團隊的關注。

DevOps鼓勵持續集成、持續交付和基礎設施即代碼。

• 由於持續交付，如果我進行了代碼變更或配置變更可能會破壞測試或分段環境，我將在幾個小時內得知。
• 由於基礎設施即代碼，開發人員可以自行配置環境、部署代碼，並自行解決問題，無需運營團隊的幫助。

我認為敏捷和DevOps是幫助我們改進如何構建優秀軟件的兩個階段。它們並不相互競爭，而是一起幫助我們構建驚人的軟件產品。

就我個人而言，敏捷和DevOps共同的目標是做到以下幾點：

• 促進業務、開發和運營團隊之間的溝通和反饋
• 通過自動化來緩解痛點。

一個DevOps故事

以下是一個例子：

• 您是團隊中的明星開發人員，需要快速修復。
• 您前往GitHub存儲庫。
• 您迅速檢查項目。
• 您快速創建本地環境。
• 進行變更。進行測試。更新單元和自動化測試。
• 提交變更。
• 收到郵件通知已部署到 QA 環境。
• 自動運行一些整合測試。
• QA 團隊收到郵件請求批准。他們進行手動測試並批准。
• 您的程式碼在幾分鐘內已上線到生產環境。
• 您可能認為這是一個理想的情況。但是，您知道像 Netflix、Amazon 和 Google 這樣的創新企業每天都在進行這樣的操作嗎？

這就是 DevOps 的故事。

DevOps = 開發 + 運營

DevOps 是軟體開發的自然演進。DevOps 不僅僅是一個工具、一個框架或僅僅是自動化。它結合了所有這些元素。

DevOps 著重於人、流程和產品。DevOps 中的人員部分涉及文化和創建一個健康心態 – 一種促進開放溝通並重視快速反饋的文化，一種重視高質量軟體的文化。

敏捷方法有助於橋接業務和開發團隊之間的鴻溝。開發團隊了解業務的優先順序，並與業務合作，首先提供價值最大的故事；然而，開發和運營團隊之間沒有對齊。

他們有不同的目標。

• 開發團隊的目標是將尽可能多的新功能帶入生產。
• 運營團隊的目標是讓生產環境保持盡可能穩定。

正如您所看到的，如果將事物推向生產是困難的，開發和運營就無法對齊。

DevOps 的目標是通過共享目標來對齊開發和運營團隊。

開發團隊與運營團隊合作，了解並解決運營挑戰。運營團隊是 Scrum 團隊的一部分，了解正在開發中的功能。

我們如何使這成為可能？拆除開發和運營之間的障礙！

將開發和運營團隊聚在一起

選項1

在成熟的 DevOps 企業中，開發和運營作為同一 Scrum 團隊的一部分工作，分享彼此的責任。

選項2

然而，如果您處於 DevOps 演進的早期階段，如何使開發和運營具有共同的目標並共同工作呢？

以下是您可以採取的一些措施：

• 讓開發團隊分享運營團隊的一些責任。例如，開發團隊可以在生產部署後的第一周負責新版本的釋出。這有助於開發團隊了解運營在推出新版本時面臨的挑戰，並幫助他們攜手解決問題。
• 另一件事是讓運營團隊的代表參與 Scrum 活動。讓他們參與每日站立會議和回顧會議。
• 接下來您可以做的事情是讓運營團隊面臨的挑戰對開發團隊更加顯著。當您在運營中面臨任何挑戰時，讓開發團隊成為致力於解決問題的團隊的一部分。

無論您採取哪種方式，找到打破隔閡、使開發和運營團隊聚在一起的方法。

另一個有趣的選項出現是因為自動化。通過使用基礎架構即代碼並為開發人員啟用自我配置，您可以創建一種運營和開發團隊都理解的共同語言——代碼。

DevOps 使用案例

考慮下面的圖片：

這幅圖展示了兩個簡單的工作流程

1. 使用 Terraform 和 Azure DevOps 進行基礎架構即代碼，以配置 Kubernetes 集群。
2. 使用 Azure DevOps 將微服務進行持續部署，以構建和部署微服務的 Docker 映像到 Kubernetes 集群。

聽起來復雜嗎？

讓我們分解並試著理解它們。

讓我們從＃2 —— 開始連續部署。

#2: 使用 Azure DevOps 和 Jenkins 進行 DevOps 連續部署

如果您不經常運行測試和代碼質量檢查，那有很好的測試和代碼質量檢查又有什麼用呢？

如果您不經常部署軟體，那部署自動化又有什麼用呢？

一旦開發人員將代碼提交到版本控制系統中，將執行以下步驟：

• 單元測試
• 代碼質量檢查
• 整合測試
• 應用程式封裝 — 創建可部署版本的應用程式。工具 — Maven、Gradle、Docker
• 應用程式部署 — 上線新應用程式或應用程式新版本
• 發送電子郵件給測試團隊測試應用程式

一旦獲得測試團隊批准，應用程式立即部署到下一個環境中。

這被稱為持續部署。如果您持續部署至生產環境，這被稱為持續交付。

最受歡迎的CI/CD工具有Azure DevOps和Jenkins。

#1：使用Terraform的DevOps基礎設施即代碼

過去，我們習慣手動創建環境並手動部署應用程式。

每次創建伺服器都需要手動操作。

• 軟體版本需要手動更新
• 安全補丁需要手動安裝

進行手動操作，以下是結果：

• 錯誤機率高
• 複製環境困難

基礎設施即代碼

基礎設施即代碼 — 對待基礎設施與應用程式代碼相同。

以下是了解基礎設施即代碼的一些重要事項：

• 基礎設施團隊專注於增值工作（而非例行工作）
• 減少錯誤並快速復原失敗
• 伺服器保持一致（避免配置漂移）

最受歡迎的IaC工具是Ansible和Terraform。

通常 IaC 的步驟如下：

• 從模板中提供伺服器（由雲端啟用）
• 安裝軟體
• 配置軟體

伺服器提供

通常使用配置工具來提供伺服器並讓新伺服器具備網路能力。最受歡迎的配置工具是 Cloud Formation 和 Terraform。

使用 Terraform，您可以提供伺服器和其他基礎設施，如負載平衡器、資料庫、網路配置等。您可以使用像 Packer 和 AMI（Amazon Machine Image）這樣的工具來建立使用預先建立的映像的伺服器。

配置管理

配置管理工具用於：

• 安裝軟體
• 配置軟體

常見的配置管理工具有 Chef、Puppet、Ansible 和 SaltStack。這些工具旨在在現有伺服器上安裝和管理軟體。

Docker 和 Kubernetes 在 DevOps 中的角色

在微服務世界中，一些微服務可能使用 Java 構建，一些使用 Python，還有一些使用 JavaScript。

不同的微服務將有不同的構建應用程式和部署到伺服器的方式。這使運營團隊的工作變得困難。我們如何以相似的方式部署多種類型的應用程式呢？進入容器和 Docker。

使用 Docker，您可以構建微服務的映像 – 無論它們的語言如何。您可以在任何基礎設施上以相同的方式運行這些映像。這簡化了運營。

Kubernetes 通過幫助編排不同類型的容器並將它們部署到集群中來進一步擴展這一功能。

Kubernetes 還提供：

• 服務發現
• 負載平衡
• 集中式配置

Docker 和 Kubernetes 讓 DevOps 變得更容易。

重要的 DevOps 指標

以下是一些重要的 DevOps 指標，您可以在一段時間內追蹤並改進。

• 部署頻率 — 應用程序被部署到生產環境的頻率是多少？
• 上市時間 — 從編碼一個功能到將其投入生產環境需要多長時間？
• 新版本失敗率 — 你的發布版本中有多少失敗？
• 修復交付時間 — 從發現問題到修復並部署到生產環境需要多長時間？
• 平均恢復時間 — 從發生重大問題到恢復生產環境需要多長時間？

DevOps 最佳實踐

敏捷專案管理

敏捷專案管理是一種迭代開發軟體應用的方法。通過這種實踐，團隊可以提高開發速度，並對客戶需求有良好反應。敏捷方法較傳統的瀑布模型不同，瀑布模型有較長的發布週期。敏捷使用 Scrum 和 Kanban 框架來根據客戶需求交付軟體。

使用正確的工具

軟體開發人員和系統管理員需要在DevOps生命週期的每個階段挑選和使用正確的一套DevOps工具來建立高價值的應用程式。

以下是一些DevOps工程師、系統管理員和其他利害關係人可以使用的工具示例：

1. 像Jira這樣的工具可以幫助團隊將任務分為更小、更易管理的部分，從而提高團隊的生產力。
2. 像Jenkins和Bitbucket這樣的工具可以幫助您自動化從測試到部署階段的程式碼流程。
3. 像Slack、GetFeedback等工具可以幫助DevOps團隊將聊天工具與調查平台整合，以收集和審查即時反饋。

持續整合/持續交付

持續整合（CI）和持續交付（CD）是現代軟體開發實踐，幫助組織快速有效地發佈軟體。通過CI，開發人員不斷地將應用程式代碼提交到共享存儲庫多次。通過CD，程式碼會迅速和無縫地交付到生產環境。CD還確保整合不會出現延遲或故障。

整合安全性

安全性是軟體開發過程中的重要部分。在當今世界，網絡犯罪和數據洩露事件不斷增加，組織正意識到將安全性整合到系統中的重要性。過去，安全性通常在軟體開發生命週期的最後階段才被考慮，但隨著DevSecOps的出現，安全性從應用程式開發的第一天開始被考慮和整合。

可觀察性在開發使用微服務和雲架構的複雜應用程式時變得至關重要。可觀察性幫助DevOps團隊了解不同應用程式（微服務、雲應用等）的複雜結構，並有助於應對環境的未來需求。Kubernetes的可觀察性和Splunk是一些最佳的可觀察性平台。

DevOps成熟度信號

• 如何衡量您的DevOps實施的成熟度？
• 從開發過程到部署所花費的時間應該是整體滿意的
• 確定新代碼部署的頻率
• 從事件或意外事件的發生到恢復正常運行的時間（MTTR）應盡可能低成功的部署應該超過失敗的部署
• 快速且可靠的發布應該帶來高投資回報率（ROI）。

DevOps 轉型最佳實踐

• 領導層的支持至關重要
• 涉及前期成本
• 建立 COE 來幫助團隊
• 選擇適當的應用和團隊
• 從小開始
• 分享經驗（通訊、COE）
• 鼓勵人們培養探索和自動化思維
• 表彰 DevOps 團隊