大綱

• DevOps是什么？

• 為什么我們需要DevOps？

• DevOps與敏捷開發(fā)有何不同？

• 重要的DevOps工具是什么？

• Docker如何幫助DevOps？

• Kubernetes如何幫助DevOps？

• Azure DevOps如何幫助DevOps？

• 持續(xù)集成，持續(xù)交付是什么？

• 基礎(chǔ)架構(gòu)即代碼是什么？

• Terraform和Ansible如何幫助DevOps？

DevOps是什么？

與圍繞軟件開發(fā)的大多數(shù)流行語一樣，DevOps沒有公認(rèn)的定義。

定義從簡單（如這兩個定義）到復(fù)雜（可以持續(xù)一整本書）不等。

DevOps是文化理念，實踐和應(yīng)用快速交付工具的組合–AWS

DevOps是組織內(nèi)部的跨學(xué)科協(xié)作，旨在確保軟件新版本的自動化持續(xù)交付，同時確保其正確性和可靠性 –L Leite

與其嘗試定義DevOps，不如讓我們了解軟件開發(fā)如何演變?yōu)镈evOps。

瀑布模型(Waterfall)

幾十年前，軟件開發(fā)以Waterfall模型為中心。

Waterfall模型開發(fā)，與建筑項目類似-例如，建立一座令人驚嘆的橋梁。

你將分多個階段構(gòu)建軟件，這些階段可以持續(xù)幾周到幾個月不等。

在大多數(shù)Waterfall項目中，企業(yè)要幾個月才能看到應(yīng)用程序的有效版本。

構(gòu)建優(yōu)秀軟件的關(guān)鍵要素

在瀑布模型中工作了幾十年，我了解到了開發(fā)出色軟件的一些關(guān)鍵要素：

• 溝通

• 反饋

• 自動化

溝通的重要性

軟件開發(fā)是一項涉及多種技能的跨學(xué)科工作。

人與人之間的交流對于軟件項目的成功至關(guān)重要。

在瀑布模型中，我們嘗試通過準(zhǔn)備有關(guān)需求，設(shè)計，體系結(jié)構(gòu)和部署的詳細文檔來增強交流。

但是，一段時間以來，我們了解到

• 增強團隊內(nèi)部溝通的最佳方法–使團隊團結(jié)在一起，這樣就能在同一個團隊中獲得各種技能。

• 具有多種技能的跨職能團隊，會使工作出色。

早期反饋的重要性

快速獲得反饋很重要。開發(fā)出色的軟件就是要獲得快速反饋。

我們是否正在構(gòu)建符合業(yè)務(wù)期望的應(yīng)用程序？

你不能等待幾個月才能獲得反饋。你可能想快速了解。

如果將其部署到生產(chǎn)環(huán)境中，你的應(yīng)用程序會出現(xiàn)問題嗎？

我們越早發(fā)現(xiàn)問題，越容易解決。

我們發(fā)現(xiàn)，最好的軟件團隊通常是快速反饋。幫助我們知道是否盡早在做正確的事情。

自動化的重要性

自動化至關(guān)重要。軟件開發(fā)涉及廣泛的活動。手動執(zhí)行操作速度很慢且容易出錯。

在了解了開發(fā)出色軟件的關(guān)鍵要素之后，讓我們看看我們?nèi)绾窝葑優(yōu)槊艚蓍_發(fā)和DevOps。

敏捷開發(fā)發(fā)展

如果通過加強團隊之間的溝通，獲取快速反饋和引入自動化，敏捷開發(fā)是第一步。

敏捷開發(fā)將業(yè)務(wù)團隊和開發(fā)團隊整合為一個團隊，該團隊致力于以小型迭代（稱為Sprints）構(gòu)建出色的軟件。

敏捷開發(fā)關(guān)注開發(fā)周期不是在數(shù)周或數(shù)，而是在幾天甚至一天之內(nèi)的小需求。

敏捷開發(fā)如何增強團隊之間的溝通？

敏捷開發(fā)使業(yè)務(wù)團隊和開發(fā)團隊聚集在一起。

• 業(yè)務(wù)團隊負責(zé)定義構(gòu)建什么內(nèi)容。有什么要求？

• 開發(fā)團隊負責(zé)構(gòu)建滿足要求的產(chǎn)品。開發(fā)包括與你的軟件的設(shè)計，編碼，測試和打包有關(guān)的每個人。

在敏捷開發(fā)中，業(yè)務(wù)代表（通常稱為產(chǎn)品負責(zé)人）經(jīng)常出現(xiàn)在團隊中，團隊可以清楚地了解業(yè)務(wù)目標(biāo)。

當(dāng)開發(fā)團隊對需求的理解不正確并且走錯了路時，產(chǎn)品負責(zé)人將幫助他們進行課程更正，并保持正確的道路。

結(jié)果：團隊構(gòu)建的最終產(chǎn)品是企業(yè)想要的東西。

另一個重要因素，是敏捷開發(fā)團隊具有跨職能的技能：編碼技能（前端，API和數(shù)據(jù)庫），測試技能和業(yè)務(wù)技能。

敏捷開發(fā)與自動化

敏捷開發(fā)團隊關(guān)注哪些自動化領(lǐng)域？

軟件產(chǎn)品可能具有多種缺陷：

• 功能缺陷意味著產(chǎn)品無法正常工作。

• 技術(shù)缺陷使軟件維護困難。例如，代碼質(zhì)量問題。

通常，敏捷開發(fā)團隊專注于使用自動化來盡早發(fā)現(xiàn)技術(shù)和功能缺陷。

敏捷開發(fā)團隊專注于自動化測試。編寫出色的單元測試以測試你的方法和類。編寫出色的集成測試以測試你的模塊和應(yīng)用程序。敏捷開發(fā)團隊還廣泛關(guān)注代碼質(zhì)量–使用諸如SONAR之類的工具來評估應(yīng)用程序的代碼質(zhì)量。

如果你擁有出色的自動化測試和出色的代碼質(zhì)量檢查，是否就足夠了？

你可能還希望盡可能經(jīng)常地運行它們。敏捷開發(fā)團隊專注于持續(xù)集成。提交代碼，運行單元測試，自動化測試和代碼質(zhì)量檢查。這些都是在持續(xù)集成管道中自動執(zhí)行的。在敏捷開發(fā)早期，最受歡迎的CI/CD工具是Jenkins。

敏捷開發(fā)如何促進即時反饋？

最重要的因素是，企業(yè)無需等待數(shù)月即可看到最終產(chǎn)品。在每次版本迭代結(jié)束時，都會將該產(chǎn)品演示給所有利益相關(guān)者。在優(yōu)先考慮下一次版本迭代結(jié)束時，將采納所有反饋。結(jié)果：團隊構(gòu)建的最終產(chǎn)品是企業(yè)想要的東西。

能夠立即反饋的另一個重要因素是–持續(xù)集成。假設(shè)我將一些代碼提交到版本控制中，在30分鐘內(nèi)，如果我的代碼導(dǎo)致單元測試失敗或集成測試失敗，我將獲得反饋。如果我的代碼不符合代碼質(zhì)量標(biāo)準(zhǔn)或在單元測試中沒有足夠的代碼覆蓋率，我將獲得反饋。

敏捷開發(fā)成功了嗎？是。當(dāng)然。通過專注于改善業(yè)務(wù)與開發(fā)團隊之間的溝通，并著重于盡早發(fā)現(xiàn)各種缺陷，Agile將軟件開發(fā)提升到了一個新的水平。

但是，出現(xiàn)了新的挑戰(zhàn)。

微服務(wù)架構(gòu)的演變

現(xiàn)在，我們慢慢開始轉(zhuǎn)向微服務(wù)架構(gòu)，并且開始構(gòu)建許多小型API，而不是構(gòu)建大型整體應(yīng)用程序。

新的挑戰(zhàn)是什么？

運維變得更加重要。你每周要進行數(shù)百個小型微服務(wù)發(fā)布，而不是一個月發(fā)布一個整體。調(diào)試微服務(wù)中的問題并了解微服務(wù)中發(fā)生的事情變得很重要。

是時候在軟件開發(fā)中使用新的流行語了–DevOps。

DevOps的出現(xiàn)

DevOps的重點是什么？

DevOps的重點是加強開發(fā)與運維團隊之間的溝通。

• 如何使部署更容易？

• 如何使運維團隊更加了解開發(fā)團隊做的事情？

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

DevOps使運維團隊與開發(fā)團隊更加接近。

• 在更成熟的企業(yè)中，開發(fā)團隊和運維團隊是一個團隊。他們開始共享共同的目標(biāo)，并且兩個團隊都開始了解另一個團隊面臨的挑戰(zhàn)。

DevOps團隊關(guān)注的自動化領(lǐng)域是什么？

除了敏捷開發(fā)的重點領(lǐng)域（持續(xù)集成和測試自動化）外，DevOps團隊還致力于幫助使運維團隊自動化，例如，在服務(wù)器上配置軟件，部署應(yīng)用程序以及監(jiān)視生產(chǎn)環(huán)境。一些關(guān)鍵術(shù)語是持續(xù)部署和基礎(chǔ)架構(gòu)即代碼。

持續(xù)部署就是要在測試環(huán)境上持續(xù)部署新版本的軟件。在像Google，F(xiàn)acebook這樣的更成熟的組織中，Continuous Delivery可幫助將軟件連續(xù)部署到生產(chǎn)中。

基礎(chǔ)設(shè)施即代碼就是將基礎(chǔ)設(shè)施視為應(yīng)用程序代碼。你可以使用自動化配置方式創(chuàng)建基礎(chǔ)結(jié)構(gòu)（服務(wù)器，負載平衡器和數(shù)據(jù)庫）。你將對基礎(chǔ)結(jié)構(gòu)進行版本控制-以便可以跟蹤。

DevOps如何促進即時反饋？

DevOps將運維和開發(fā)團隊召集在一起。因為運維和開發(fā)都是同一團隊的一部分，所以整個團隊都了解與運維和開發(fā)相關(guān)的挑戰(zhàn)。

• 任何運維問題都會得到開發(fā)人員的快速關(guān)注。

• 上線軟件時遇到的任何挑戰(zhàn)，都會引起運維團隊的盡早關(guān)注。

DevOps鼓勵將持續(xù)集成，持續(xù)交付和基礎(chǔ)架構(gòu)作為代碼。

• 由于持續(xù)交付，如果我進行代碼更改或配置更改破壞了測試或環(huán)境，那么我會在幾個小時內(nèi)知道。

• 由于使用“基礎(chǔ)結(jié)構(gòu)即代碼”，開發(fā)人員可以自行配置環(huán)境，部署代碼并自行查找問題，而無需運維團隊的任何幫助。

盡管我們說敏捷開發(fā)和DevOps是使事情變得簡單的兩個不同的事物，但實際上，對于DevOps的含義沒有公認(rèn)的定義。

我認(rèn)為敏捷開發(fā)和DevOps是兩個階段，可以幫助我們改善構(gòu)建出色軟件。他們不會互相競爭，但是可以一起幫助我們構(gòu)建出色的軟件產(chǎn)品。

就我而言，敏捷開發(fā)和DevOps是相輔相成

• 促進業(yè)務(wù)，開發(fā)和運維團隊之間的溝通和反饋

• 通過自動化緩解痛點。

DevOps的故事

如果你是團隊中的明星開發(fā)人員，因此軟件問題需要你快速解決。

你要 checkout 項目。

你要快速創(chuàng)建本地環(huán)境。

你要修改代碼。

你要更新單元測試和自動化測試。

你要提交提交代碼。

你會收到一封電子郵件，指出將進行質(zhì)量檢查。

一些集成測試會自動運行。

你的質(zhì)量檢查小組會收到一封電子郵件，要求你批準(zhǔn)。他們進行手動測試并批準(zhǔn)。

你的代碼將在幾分鐘內(nèi)投入生產(chǎn)。

這就是DevOps的故事。

DevOps = Development + Operations

DevOps是軟件開發(fā)的自然發(fā)展。DevOps不僅僅是工具，框架還是自動化。這是所有這些的結(jié)合。

DevOps專注于人員，流程和產(chǎn)品。DevOps的“人員”部分是關(guān)于文化和樹立良好思維模式的，這是一種促進開放式溝通并重視快速反饋的文化，一種重視高質(zhì)量軟件的文化。

敏捷開發(fā)幫助彌合了業(yè)務(wù)團隊與開發(fā)團隊之間的鴻溝。開發(fā)團隊了解業(yè)務(wù)的優(yōu)先級，并與業(yè)務(wù)合作，以提供最有價值的故事為先。但是，開發(fā)團隊和運維團隊并沒有保持一致。

他們有不同的目標(biāo)。

開發(fā)團隊的目標(biāo)是將盡可能多的新功能投入生產(chǎn)。

Ops團隊的目標(biāo)是保持生產(chǎn)環(huán)境盡可能穩(wěn)定。

如你所見，如果將產(chǎn)品投入生產(chǎn)很困難，那么開發(fā)人員和運維人員就無法保持一致。

DevOps旨在使Dev和Ops團隊實現(xiàn)共同目標(biāo)。

開發(fā)團隊與運維團隊合作，以了解和解決運維難題。Ops團隊是Scrum團隊的成員，了解開發(fā)中的功能。

我們?nèi)绾尾拍茏龅竭@一點？

打破開發(fā)人員和行運維人員之間的隔墻！

開發(fā)人員和運維人員結(jié)合-選項1

在成熟的DevOps企業(yè)中，Dev和Ops是同一Scrum團隊的一部分，彼此分擔(dān)責(zé)任。

開發(fā)人員和運維人員結(jié)合選項2

但是，如果你處在DevOps演進的早期階段，那么如何才能使Dev和Ops擁有共同的目標(biāo)并一起工作呢？

你可以執(zhí)行以下操作：

• 你可以開始做的一件事就是讓開發(fā)團隊分擔(dān)運維團隊的一些職責(zé)。例如，開發(fā)團隊可以在生產(chǎn)部署后的第一周內(nèi)負責(zé)新版本的發(fā)布。這有助于開發(fā)團隊了解在發(fā)布新版本時操作所面臨的挑戰(zhàn)，并幫助他們團結(jié)起來找到更好的解決方案。

• 你可以做的另一件事是讓運維團隊的代表參與Scrum活動。

• 接下來，你可以使開發(fā)團隊更清楚地看到運維團隊面臨的挑戰(zhàn)。當(dāng)你在運維中遇到任何挑戰(zhàn)時，請使開發(fā)團隊成為解決方案團隊的一部分。

由于自動化，出現(xiàn)了另一個有趣的選擇。通過將基礎(chǔ)結(jié)構(gòu)即代碼并為開發(fā)人員啟用預(yù)配置，你可以創(chuàng)建操作和開發(fā)團隊可以理解的通用語言-代碼。

DevOps用例

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

• No 1：使用Terraform和Azure DevOps來配置Kubernetes集群的基礎(chǔ)架構(gòu)。

• No 2 ：使用Azure DevOps持續(xù)部署微服務(wù)，以將微服務(wù)的Docker鏡像構(gòu)建和部署到Kubernetes群集中。

這聽起來復(fù)雜嗎？

讓我們分解一下，嘗試并理解它們。

讓我們從No 2開始-首先是持續(xù)部署。

No 2：使用Azure DevOps和Jenkins進行DevOps連續(xù)部署

如果你不經(jīng)常運行測試和代碼質(zhì)量檢查，這有什么用？

如果你沒有足夠頻繁地部署軟件，部署自動化有什么用？

開發(fā)人員將代碼提交到版本控制系統(tǒng)后，將立即執(zhí)行以下步驟：

• 單元測試。

• 代碼質(zhì)量檢查。

• 集成測試。

• 應(yīng)用程序打包—構(gòu)建應(yīng)用程序的可部署版本。

• 應(yīng)用程序部署-啟用新版本的應(yīng)用程序。

• 給測試團隊的電子郵件，用于測試應(yīng)用程序。

一旦獲得測試團隊的批準(zhǔn)，該應(yīng)用程序?qū)⒘⒓床渴鸬絅ext Environment。

這稱為連續(xù)部署。如果你持續(xù)部署到生產(chǎn)環(huán)境，則稱為持續(xù)交付。

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

No 1：使用Terraform實現(xiàn)DevOps中的基礎(chǔ)架構(gòu)即代碼

在過去，我們創(chuàng)建環(huán)境并手動部署應(yīng)用程序。

每次創(chuàng)建服務(wù)器時，都需要手動完成。

• 如果需要更新Java版本怎么辦？

• 是否需要應(yīng)用安全補?。?/p>

你手動進行。

這是什么結(jié)果？

• 錯誤幾率很高。

• 復(fù)制環(huán)境很困難。

基礎(chǔ)架構(gòu)即代碼

基礎(chǔ)架構(gòu)即代碼—像應(yīng)用程序代碼一樣對待基礎(chǔ)架構(gòu)

這是基礎(chǔ)架構(gòu)即代碼應(yīng)理解的一些重要事項

• 基礎(chǔ)設(shè)施團隊專注于增值工作（而不是例行工作）。

• 更少的錯誤，可以從故障中快速恢復(fù)。

• 服務(wù)器是一致的（避免配置漂移）。

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

通常，這些是IaC中的步驟

• 通過模板配置服務(wù)器（由云啟用）

• 安裝軟件

• 配置軟件

服務(wù)器配置

最受歡迎的配置工具是CloudFormation和Terraform。

使用Terraform，你可以預(yù)配置服務(wù)器和基礎(chǔ)架構(gòu)的部分，例如負載平衡器，數(shù)據(jù)庫，網(wǎng)絡(luò)配置等。你可以使用使用Packer和AMI等工具預(yù)創(chuàng)建鏡像來創(chuàng)建服務(wù)器（Amazon Machine Image）。

配置管理

配置管理工具用于

• 安裝軟件

• 配置軟件

流行的配置管理工具是Chef，Puppet，Ansible和SaltStack。這些旨在在現(xiàn)有服務(wù)器上安裝和管理軟件。

Docker和Kubernetes在DevOps中的作用

Docker和Kubernetes在DevOps中的作用是什么？

在微服務(wù)世界中，可能會使用Java構(gòu)建一些微服務(wù)，使用Python構(gòu)建一些微服務(wù)，以及使用JavaScript構(gòu)建一些微服務(wù)。

不同的微服務(wù)將具有不同的構(gòu)建和部署方式。

這使運維團隊的工作變得困難。

我們?nèi)绾斡邢嗤姆绞絹聿渴鸲喾N類型的應(yīng)用程序？容器和Docker。

使用Docker，你可以構(gòu)建微服務(wù)的鏡像-不管它們的語言如何。你可以在任何基礎(chǔ)架構(gòu)上以相同方式運行這些鏡像。

這簡化了操作。

Kubernetes通過幫助協(xié)調(diào)不同類型的容器并將其部署到集群。

Kubernetes還提供：

• 服務(wù)發(fā)現(xiàn)。

• 負載均衡。

• 集中配置。

Docker和Kubernetes使DevOps變得容易。

重要的DevOps指標(biāo)

以下是一些重要的DevOps指標(biāo)。

• 部署頻率-將應(yīng)用程序多長時間部署到生產(chǎn)一次？

• 上線時間-從編碼到投入生產(chǎn)，你需要花多長時間？

• 新版本的失敗率-新版本多少次失??？

• 修復(fù)的交付時間-你需要多長時間進行生產(chǎn)修復(fù)并將其發(fā)布到生產(chǎn)中？

• 平均恢復(fù)時間-從重大問題恢復(fù)到部署生產(chǎn)環(huán)境需要花費多長時間？

DevOps最佳做法

以下是DevOps的一些最佳做法

• 標(biāo)準(zhǔn)化

• 具有跨職能技能的團隊

• 關(guān)注團隊文化

• 自動化，自動化，自動化。

• 不變的基礎(chǔ)設(shè)施

• 開發(fā)和生產(chǎn)環(huán)境相同

• 版本控制

• 自我配置管理

如何衡量DevOps實施的成熟度

你如何衡量DevOps實施的成熟度？這里是一些重要的問題。

開發(fā)

• 每次提交都會觸發(fā)自動測試和自動代碼質(zhì)量檢查嗎？

• 你的代碼是否持續(xù)交付生產(chǎn)？

• 你使用結(jié)對編程( pair programming )嗎？

• 你使用TDD和BDD嗎？

• 你有很多可重復(fù)使用的模塊嗎？

• 開發(fā)團隊可以自我配置環(huán)境嗎？

• 快速修復(fù)生產(chǎn)需要多長時間？

測試

• 你的測試是否自動化？

• 自動化測試失敗時，構(gòu)建會失敗嗎？

• 你的測試周期短嗎？

• 你有自動NFR測試嗎？

部署方式

• 你是否具有開發(fā)和生產(chǎn)環(huán)境相同？

• 你是否使用A / B測試？

• 你是否使用金絲雀部署？

• 只需單擊一下按鈕即可部署？

• 你可以通過單擊按鈕來回滾嗎？

• 你能否通過單擊按鈕設(shè)置和釋放基礎(chǔ)結(jié)構(gòu)？

• 你是否將IAC和版本控制用于基礎(chǔ)架構(gòu)？

監(jiān)控方式

• 團隊是否使用集中監(jiān)控系統(tǒng)？

• 只需單擊一個按鈕，開發(fā)團隊就可以訪問日志嗎？

• 如果生產(chǎn)中出現(xiàn)問題，團隊是否會收到警報？

團隊與流程

• 團隊是否希望不斷改進？

• 團隊是否具備業(yè)務(wù)，開發(fā)和運維所需的全部技能？

• 團隊是否跟蹤關(guān)鍵的DevOps指標(biāo)并對其進行改進？

譯者：王延飛

原文鏈接：https:///articles/devops-tutorial-devops-with-docker-kubernetes-and#