溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇文章為大家展示了如何使用 Docker和Kubernetes及Azure DevOps實現 DevOps，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。
我們將會分解關于你想了解的 DevOps 的所有知識，因而你可以著手構建自己的 CI/CD 流水線。
將注意力集中于 DevOps 上。
什么是 DevOps？它跟 Agile 有什么不同？有哪些受歡迎的 DevOps 工具？在 DevOps 中，Docker、Kubernetes 和 Azure DevOps 又是充當了什么樣的角色。讓我們從一個簡單的使用場景開始這次的內容。
與圍繞軟件開發的大多數流行語一樣，關于 DevOps 沒有公認的定義。
簡單來說可以用下面這兩段文字描述，往復雜了說足以在書里面寫一整頁。
DevOps 是文化理念、實踐、工具的組合，能夠讓一個組織提升高效交付應用程序和服務的能力。- Amazon Web Services（AWS）
DevOps 是一個組織內部的跨學科協作的概念，通過實現自動化交付新的軟件版本，從而能夠確保它們的正確性和可靠性。- L Leite
與其嘗試對它做定義，不如讓我們來了解下軟件開發是怎樣一步步發展到 DevOps 的。
軟件開發的頭幾十年都是圍繞瀑布模型開展的。
瀑布軟件開發模型與實際開發房地產項目有異曲同工之處 – 比如，建造一座令人驚嘆的橋梁。
你需要分多個階段構建軟件，這些階段可以持續幾個星期到幾個月不等。
大多數的瀑布項目中，企業需要數月才能等到一個能運行的應用程序版本。
使用瀑布模型幾十年后，我們意識到開發出色軟件的一些關鍵因素:
溝通
反饋
自動化
軟件開發是一項包含了多重技巧的跨學科的工作。
人與人之間的溝通對軟件項目的成功起到了至關重要的作用。
在瀑布模型當中，我們嘗試通過準備多達 1000 頁的關于需求、設計、架構以及部署的文檔來增強溝通。
但是，使用一段時間后，我們體會到
團隊內部增強溝通的最好方法，是團隊的凝聚力。以及在同一團隊獲取一系列技能的能力。
跨部門的團隊（有更多技能的）工作更出色。
盡快得到反饋是重要的。構建出色的軟件就是需要盡快得到反饋。
我們開發的軟件能夠符合市場的期望嗎？
你不能等好幾個月了才得到反饋。你想要盡可能快的知道。
你的應用如果部署到生產環境會有問題嗎？
你不想等過了好幾月才知道這個結果。你肯定想知道的越快越好。
盡早發現問題，修復起來就越簡單。
我們發現出色的軟件研發團隊可以很快的得到反饋。我所開發的功能，我需要盡可能早的知道我是否正朝著正確的方向做這些事情。
自動化是非常重要的。軟件開發包括了很多方面的活動。手動做這些事情效率低并且容易出錯。我們了解到尋求引入自動化的機會至關重要。
在了解了怎樣開發出色的軟件的關鍵因素之后，讓我們看看我們是怎樣發展到 Agile 以及 DevOps 的。
Agile 是我們提升團隊間的溝通，獲取反饋以及引入自動化實施到我們學習內容的第一步。
Agile 將業務與研發團隊整合到一個團隊當中，在稱為 Sprint 的小型迭代過程中開發出色的軟件。
不同于在每次開發階段耗費數周乃至數月，Agile 著眼于幾天甚至一天內的整個開發周期中處理稱為用戶故事的小需求。
Agile 將業務與研發團隊整合到一起。
業務團隊負責定義開發什么樣的產品。有什么樣的需求？
開發團隊負責開發符合這些需求的產品。開發團隊成員包括設計、編碼、測試以及打包應用程序的人員。
在 Agile 中，業務代表即產品經理，總是會出現在團隊中，讓團隊明確具體的業務目標。
當開發團隊沒有很好的理解需求或者是在一條錯誤的方向上時，產品經理會幫助他們進行修正以幫助他們重新回到正確的軌道上。
結果: 團隊最終開發出來的產品也就是市場最終需要的產品。
另一項重要的因素就是 Agile 團隊有跨功能的技能: 編碼技能（前端，API 還有數據庫）、測試技能、以及業務技能。這些促進了需要一同工作并且開發出色軟件的人們之間的溝通。
Agile 團隊專注于 Automation 領域的哪方面呢？
軟件產品有多種缺陷:
功能缺陷意思就是產品不能如預期那樣正常運行。
技術缺陷會造成軟件維護困難。舉個例子，代碼質量問題。
總的來說，Agile 團隊著眼于使用自動化來盡早的發現技術上以及功能上的缺陷。
Agile 團隊著眼于自動化測試。編寫出色的單元測試來測試你的方法和類。編寫出色的集成測試來測試你的模塊和應用。Agile 團隊同樣非常關注代碼質量。使用諸如 SONAR 這樣的工具可以用來評估應用程序的代碼質量。
如果你有出色的自動化測試和出色的代碼質量檢查是否就夠了呢？你可能想經常的運行它們。Agile 團隊著眼于持續集成。你提交了一次變更到版本控制系統。運行單元測試、自動化測試和代碼檢查。這些都在持續集成流水線自動運行。在 Agile 早期階段，比較流行的 CI/CD 工具是 Jenkins。
一個重要的因素是市場不需要等待好幾個月看到最終產品。每次迭代的尾聲，會給利益相關者包括架構和業務團隊演示產品。得到的所有反饋會作為下一次迭代優先處理的用戶故事。結果: 最終團隊開發的軟件就是市場需要的。
另外一項可以迅速反饋的關鍵因素是持續集成。比如我提交一些代碼到版本控制系統。不出 30 分鐘，如果代碼導致了單元測試和集成測試失敗我就可以得到反饋。對不符合代碼質量標準或者沒有足夠單元測試代碼覆蓋率的代碼同樣我也會得到反饋。
Agile 是成功的嗎？當然。通過專注于提升市場和開發團隊之間的溝通以及盡早發現問題，Agile 將軟件開發提升到下一個等級。
就我個人而言，在 Agile 模型中與一些讓人激動的團隊一起工作是一個非常美妙的體驗。軟件工程，對我來說意味著從需求到最終應用程序使用中間付出的所有努力的結果，第一次，覺得編程是一種享受。
但是，發展的腳步停止了嗎？并沒有。
新的挑戰出現了。
當我們嘗試轉向微服務架構，我們開始開發一些小型 API 而不是大型的應用程序。
帶來的新的挑戰是什么呢？
運維變得更重要了。不同于一個月發布一個版本，每周都要發布上百個小型的微服務。調試微服務的問題以及搞清楚微服務之間如何工作的變得非常重要。
那時軟件開發誕生了一個新的流行語。DevOps。
DevOps 主要聚焦哪些方面呢？
DevOps 主要聚焦提升開發團隊與運維團隊之間的溝通。
我們怎樣能讓開發更容易一些？
怎樣讓運維團隊的工作在開發團隊那里看起來更透明？
DevOps 拉近了運維團隊與開發團隊之間的距離。
在更成熟的公司內，運維與開發團隊如同一個團隊。他們開始分享共同的目標，彼此也能了解對方面臨的挑戰。
一些剛開始轉向 DevOps 的企業，運維團隊的代表會參與到 Sprint 中 – 站會以及回顧都會參與。
除了 Agile 專注的領域之外（持續集成和自動化測試），DevOps 團隊會專注于幫助實現一些運維團隊活動的自動化，比如配置服務器、服務器上配置軟件、部署應用以及監控生產環境。有一些關鍵術語它們是持續部署、持續交付以及基礎設施即代碼。
持續部署是指的在測試環境上部署新的版本。甚至在諸如 Google、Facebook 這樣成熟的公司，持續交付每天都或許可以部署上百個版本到生產環境當中。
基礎設施即代碼則是將你的基礎設施同你的應用程序代碼等同對待。你利用配置以自動化的方式創建了這些基礎架構（服務器、負載均衡器、還有數據庫）。你需要對你的基礎架構做到版本控制，這樣你可以以后追蹤基礎架構的變更。
DevOps 將運維團隊和開發團隊整合到一起。因為運維和開發團隊是一個團隊的組成部分，整個團隊都能夠知曉跟運維和開發團隊相關的挑戰。
任何操作的問題都能得到開發人員的注意。
上線軟件的任何挑戰都會盡早得到運維團隊的注意。
DevOps 鼓勵持續集成、持續交付以及基礎設施即代碼。
因為使用持續交付，如果我產生了一次代碼變更或者是一次配置變更或許會阻斷測試或者是一個暫存環境，我會在幾個小時內知道。
因為使用基礎設施即代碼，開發人員可以自行配置環境、部署代碼、在不需要運維團隊幫助的前提下自行發現問題。
雖然我們談論 Agile 和 DevOps 是讓事情變得簡單的兩種不同的事物，但事實上，對于 DevOps 是什么意思仍沒有一個公認的定義。
我把 Agile 和 DevOps 看做幫助我們提高如何開發出色軟件的兩種階段。它們不是競爭關系，但是一起使用能夠幫助我們構建令人驚嘆的軟件產品。
就我而言，Agile 和 DevOps 一起使用的目的具體來說是
提升市場、研發和運維團隊的溝通
減緩自動化的痛點。在這個課程的奇妙旅程中我們將會討論單元測試、集成測試、代碼質量檢查、持續集成、持續交付、基礎設施即代碼以及通過容器標準化。
話說有這樣一個令人驚嘆的故事:
你是團隊中的開發之星，然后你需要快速修復一個 bug。你要到 GitHub 上去看看！
快速的檢出了項目代碼。
快速的創建了本地環境。
創建了一個變更。也測試完了。然后更新了單元測試和自動化測試。
提交了。
你查收到一封郵件說是它已經部署到了 QA。
一些集成測試在自動運行。
你的 QA 團隊收到一封請求測試的郵件。他們開始手工測試然后通過。
你的代碼在幾分鐘內上線到生產環境。
你或許為想這事一個理想的場景。但是，你需要知道的是這就是在諸如 Netflix、Amazon 以及 Google 這些創新公司的日常！
這就是 DevOps 的故事。
DevOps 是軟件開發的一個自然的進化。DevOps _不僅僅_是一個工具，一個框架或者僅僅就是自動化而已。它是這些東西的組合。
DevOps 專注于人、流程和產品。DevOps 中的人指的是文化以及創造一個出色的心態 – 一種促進開放交流以及快速反饋的文化，一種創造高質量軟件的文化。
Agile 則幫助在市場和開發團隊之間架設橋梁。開發團隊了解市場的優先級同市場一道傳遞最有價值的故事。然而，Dev 和 Ops 并沒有保持一致。
他們有不同的目標。
Dev 團隊的目標是將盡可能多的功能添加到產品中。
Ops 團隊的目標是保持生產環境越穩定越好。
如你所見，如果產品進入市場這么難的話，開發和運維團隊就沒法達成一致。
DevOps 目標是讓 Dev 和 Ops 團隊通過一些相同的目標凝聚到一起。
Dev 團隊與 Ops 團隊一同工作能夠了解和解決運維中遇到的挑戰。Ops 團隊是 Scrum 團隊的一部分能夠了解到開發功能的一些事情。
我們怎樣能讓其實現呢？
打破 Dev 和 Ops 之間的隔閡！
在有成熟的 DevOps 企業里，Dev 和 Ops 作為 scrum 團隊的組成部分彼此分擔責任。
然而，如果你處于轉至 DevOps 的初始階段，怎樣讓 Dev 和 Ops 團隊有共同的目標并且一起工作呢？
這里有一些你需要去做的事情:
第一件事你可以開始著手做的就是讓運維團隊分享一些工作任務給開發團隊。例如，開發團隊可以負責產品上線的一周后新版本的發布工作。這能幫助開發團隊了解到運維團隊在上線新版本面對的挑戰并且可以協助他們探索更好的解決方案。
另一件你需要做的就是將一名運維團隊的成員參與到 Scrum 日常活動中。讓他們參加團隊的站會以及總結會。
下一件你可以做的事情就是讓運維團隊面臨的問題能更清晰的呈現給 Development 團隊。當你在運維方面遇到問題的時候，可以讓開發團隊中的一部分成員成為解決方案團隊的一部分。
不管你要做哪一件事情，找到一條打破開發和運維團隊共同工作的隔閡的方法。
因為自動化另一個有趣的情景出現了。通過使用基礎設施即代碼以及 開發自行配置，你可以創造一個不論開發還是運維都能理解的語言 - 代碼。細節會在下面的幾個步驟中再做說明。
思考下面的圖片:
這張圖片展示了兩個簡單的工作流
No 1: 使用 Terraform 和 Azure DevOps 為 Kubernetes 配置基礎設施即代碼。
No 2: 微服務持續部署: 使用 Azure DevOps 構建部署微服務的 Docker 鏡像到 Kubernetes Cluster
聽起來很復雜是嗎？
讓我們試著分解然后再去理解一下。
讓我們先從 No 2 – 持續部署開始。
如果有出色的測試和代碼質量檢查但不經常運行它們的話那它們還有什么用呢？
如果你有自動部署但是不常部署軟件的話那它還有什么用呢？
只要開發人員提交代碼到版本控制系統，下面的步驟就會被執行:
單元測試。
代碼質量檢查。
集成測試。
應用程序打包 – 推出新的應用程序或者上線新版本的應用程序。
給測試團隊發送測試應用程序的郵件
一旦得到了測試團隊的允許，應用就立即部署到下一個環境。
這被稱作持續部署。如果你持續部署到生產環境，則稱作持續交付。
最受歡迎的 CI/CD 工具是 Azure DevOps 和 Jenkins。
過去，我們手動創建環境還有部署應用程序。
每次創建一個服務器，這些就需要手工做完。
如果 Java 版本需要更新怎么辦？
需要應用一個安全補丁嗎？
你需要手動做。
結果是什么呢？
非常有可能會出錯。
復制環境非常困難。
基礎設施即代碼 – 將基礎設施等同于應用代碼。
這里有幾個理解基礎設施即代碼比較重要的知識點
基礎設施團隊專注于能夠增值的工作（而不是日常工作）。
更少的錯誤可以更快的從失敗中恢復。
服務器是一致的（避免了 Configuration Drift）。
最受歡迎的 IaC 工具是 Ansible 和 Terraform。
一般來說在 IaC 中有這樣幾步
從一個模板中配置服務器（通過 Cloud 啟用）
安裝軟件
配置軟件
一般來說，配置工具用在配置服務器上起到讓服務器具備網絡功能的作用。最受歡迎的配置工具是 CloudFormation 和 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 集成的成熟度呢？這里有一些關鍵的問題需要解答。
每次提交都會自動觸發自動化測試和代碼質量檢查嗎？
你的代碼都持續分發到生產環境了嗎？
你使用結對編程嗎？
你使用 TDD 和 BDD 嗎？
你是否有許多復用的模塊？
開發團隊可以自己配置環境嗎？
快速修復生產環境的問題需要耗費多長時間？
你是否使用高質量的類似生產環境的數據執行完整的自動化測試？
當你的自動化測試失敗的時候你的構建是失敗的嗎？
你的測試周期短嗎？
你有自動 NFR 測試嗎？
你有開發生產等同嗎？
你有使用 A/B 測試嗎？
你有使用金絲雀部署嗎？
你能按下按鈕就可以開始部署嗎？
你能按下按鈕就可以執行回滾嗎？
你能按下按鈕就可以配置和發布基礎架構嗎？
你可以為你的基礎架構使用 IAC 和版本控制嗎？
團隊使用的是一個集中監控工具嗎？
開發團隊可以按下按鈕就可以獲得日志嗎？
生產環境出現問題時團隊能自動收到報警嗎？
團隊看起來是持續改進的嗎？
團隊是否擁有業務、開發、和運維的全部技能？
團隊是否跟蹤 DevOps 的關鍵指標然后去改進它們嗎？
你是否使用本地發現并用它們進一步實現全球改進的文化？
上述內容就是如何使用 Docker和Kubernetes及Azure DevOps實現 DevOps，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
