本篇文章為大家展示了如何使用 Docker和Kubernetes及Azure DevOps實(shí)現(xiàn) DevOps，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過(guò)這篇文章的詳細(xì)介紹希望你能有所收獲。
創(chuàng)新互聯(lián)建站是一家集網(wǎng)站建設(shè),墨江企業(yè)網(wǎng)站建設(shè),墨江品牌網(wǎng)站建設(shè),網(wǎng)站定制,墨江網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,墨江網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。
我們將會(huì)分解關(guān)于你想了解的 DevOps 的所有知識(shí)，因而你可以著手構(gòu)建自己的 CI/CD 流水線。
將注意力集中于 DevOps 上。
什么是 DevOps？它跟 Agile 有什么不同？有哪些受歡迎的 DevOps 工具？在 DevOps 中，Docker、Kubernetes 和 Azure DevOps 又是充當(dāng)了什么樣的角色。讓我們從一個(gè)簡(jiǎn)單的使用場(chǎng)景開(kāi)始這次的內(nèi)容。
與圍繞軟件開(kāi)發(fā)的大多數(shù)流行語(yǔ)一樣，關(guān)于 DevOps 沒(méi)有公認(rèn)的定義。
簡(jiǎn)單來(lái)說(shuō)可以用下面這兩段文字描述，往復(fù)雜了說(shuō)足以在書里面寫一整頁(yè)。
DevOps 是文化理念、實(shí)踐、工具的組合，能夠讓一個(gè)組織提升高效交付應(yīng)用程序和服務(wù)的能力。- Amazon Web Services（AWS）
DevOps 是一個(gè)組織內(nèi)部的跨學(xué)科協(xié)作的概念，通過(guò)實(shí)現(xiàn)自動(dòng)化交付新的軟件版本，從而能夠確保它們的正確性和可靠性。- L Leite
與其嘗試對(duì)它做定義，不如讓我們來(lái)了解下軟件開(kāi)發(fā)是怎樣一步步發(fā)展到 DevOps 的。
軟件開(kāi)發(fā)的頭幾十年都是圍繞瀑布模型開(kāi)展的。
瀑布軟件開(kāi)發(fā)模型與實(shí)際開(kāi)發(fā)房地產(chǎn)項(xiàng)目有異曲同工之處 – 比如，建造一座令人驚嘆的橋梁。
你需要分多個(gè)階段構(gòu)建軟件，這些階段可以持續(xù)幾個(gè)星期到幾個(gè)月不等。
大多數(shù)的瀑布項(xiàng)目中，企業(yè)需要數(shù)月才能等到一個(gè)能運(yùn)行的應(yīng)用程序版本。
使用瀑布模型幾十年后，我們意識(shí)到開(kāi)發(fā)出色軟件的一些關(guān)鍵因素:
溝通
反饋
自動(dòng)化
軟件開(kāi)發(fā)是一項(xiàng)包含了多重技巧的跨學(xué)科的工作。
人與人之間的溝通對(duì)軟件項(xiàng)目的成功起到了至關(guān)重要的作用。
在瀑布模型當(dāng)中，我們嘗試通過(guò)準(zhǔn)備多達(dá) 1000 頁(yè)的關(guān)于需求、設(shè)計(jì)、架構(gòu)以及部署的文檔來(lái)增強(qiáng)溝通。
但是，使用一段時(shí)間后，我們體會(huì)到
團(tuán)隊(duì)內(nèi)部增強(qiáng)溝通的最好方法，是團(tuán)隊(duì)的凝聚力。以及在同一團(tuán)隊(duì)獲取一系列技能的能力。
跨部門的團(tuán)隊(duì)（有更多技能的）工作更出色。
盡快得到反饋是重要的。構(gòu)建出色的軟件就是需要盡快得到反饋。
我們開(kāi)發(fā)的軟件能夠符合市場(chǎng)的期望嗎？
你不能等好幾個(gè)月了才得到反饋。你想要盡可能快的知道。
你的應(yīng)用如果部署到生產(chǎn)環(huán)境會(huì)有問(wèn)題嗎？
你不想等過(guò)了好幾月才知道這個(gè)結(jié)果。你肯定想知道的越快越好。
盡早發(fā)現(xiàn)問(wèn)題，修復(fù)起來(lái)就越簡(jiǎn)單。
我們發(fā)現(xiàn)出色的軟件研發(fā)團(tuán)隊(duì)可以很快的得到反饋。我所開(kāi)發(fā)的功能，我需要盡可能早的知道我是否正朝著正確的方向做這些事情。
自動(dòng)化是非常重要的。軟件開(kāi)發(fā)包括了很多方面的活動(dòng)。手動(dòng)做這些事情效率低并且容易出錯(cuò)。我們了解到尋求引入自動(dòng)化的機(jī)會(huì)至關(guān)重要。
在了解了怎樣開(kāi)發(fā)出色的軟件的關(guān)鍵因素之后，讓我們看看我們是怎樣發(fā)展到 Agile 以及 DevOps 的。
Agile 是我們提升團(tuán)隊(duì)間的溝通，獲取反饋以及引入自動(dòng)化實(shí)施到我們學(xué)習(xí)內(nèi)容的第一步。
Agile 將業(yè)務(wù)與研發(fā)團(tuán)隊(duì)整合到一個(gè)團(tuán)隊(duì)當(dāng)中，在稱為 Sprint 的小型迭代過(guò)程中開(kāi)發(fā)出色的軟件。
不同于在每次開(kāi)發(fā)階段耗費(fèi)數(shù)周乃至數(shù)月，Agile 著眼于幾天甚至一天內(nèi)的整個(gè)開(kāi)發(fā)周期中處理稱為用戶故事的小需求。
Agile 將業(yè)務(wù)與研發(fā)團(tuán)隊(duì)整合到一起。
業(yè)務(wù)團(tuán)隊(duì)負(fù)責(zé)定義開(kāi)發(fā)什么樣的產(chǎn)品。有什么樣的需求？
開(kāi)發(fā)團(tuán)隊(duì)負(fù)責(zé)開(kāi)發(fā)符合這些需求的產(chǎn)品。開(kāi)發(fā)團(tuán)隊(duì)成員包括設(shè)計(jì)、編碼、測(cè)試以及打包應(yīng)用程序的人員。
在 Agile 中，業(yè)務(wù)代表即產(chǎn)品經(jīng)理，總是會(huì)出現(xiàn)在團(tuán)隊(duì)中，讓團(tuán)隊(duì)明確具體的業(yè)務(wù)目標(biāo)。
當(dāng)開(kāi)發(fā)團(tuán)隊(duì)沒(méi)有很好的理解需求或者是在一條錯(cuò)誤的方向上時(shí)，產(chǎn)品經(jīng)理會(huì)幫助他們進(jìn)行修正以幫助他們重新回到正確的軌道上。
結(jié)果: 團(tuán)隊(duì)最終開(kāi)發(fā)出來(lái)的產(chǎn)品也就是市場(chǎng)最終需要的產(chǎn)品。
另一項(xiàng)重要的因素就是 Agile 團(tuán)隊(duì)有跨功能的技能: 編碼技能（前端，API 還有數(shù)據(jù)庫(kù)）、測(cè)試技能、以及業(yè)務(wù)技能。這些促進(jìn)了需要一同工作并且開(kāi)發(fā)出色軟件的人們之間的溝通。
Agile 團(tuán)隊(duì)專注于 Automation 領(lǐng)域的哪方面呢？
軟件產(chǎn)品有多種缺陷:
功能缺陷意思就是產(chǎn)品不能如預(yù)期那樣正常運(yùn)行。
技術(shù)缺陷會(huì)造成軟件維護(hù)困難。舉個(gè)例子，代碼質(zhì)量問(wèn)題。
總的來(lái)說(shuō)，Agile 團(tuán)隊(duì)著眼于使用自動(dòng)化來(lái)盡早的發(fā)現(xiàn)技術(shù)上以及功能上的缺陷。
Agile 團(tuán)隊(duì)著眼于自動(dòng)化測(cè)試。編寫出色的單元測(cè)試來(lái)測(cè)試你的方法和類。編寫出色的集成測(cè)試來(lái)測(cè)試你的模塊和應(yīng)用。Agile 團(tuán)隊(duì)同樣非常關(guān)注代碼質(zhì)量。使用諸如 SONAR 這樣的工具可以用來(lái)評(píng)估應(yīng)用程序的代碼質(zhì)量。
如果你有出色的自動(dòng)化測(cè)試和出色的代碼質(zhì)量檢查是否就夠了呢？你可能想經(jīng)常的運(yùn)行它們。Agile 團(tuán)隊(duì)著眼于持續(xù)集成。你提交了一次變更到版本控制系統(tǒng)。運(yùn)行單元測(cè)試、自動(dòng)化測(cè)試和代碼檢查。這些都在持續(xù)集成流水線自動(dòng)運(yùn)行。在 Agile 早期階段，比較流行的 CI/CD 工具是 Jenkins。
一個(gè)重要的因素是市場(chǎng)不需要等待好幾個(gè)月看到最終產(chǎn)品。每次迭代的尾聲，會(huì)給利益相關(guān)者包括架構(gòu)和業(yè)務(wù)團(tuán)隊(duì)演示產(chǎn)品。得到的所有反饋會(huì)作為下一次迭代優(yōu)先處理的用戶故事。結(jié)果: 最終團(tuán)隊(duì)開(kāi)發(fā)的軟件就是市場(chǎng)需要的。
另外一項(xiàng)可以迅速反饋的關(guān)鍵因素是持續(xù)集成。比如我提交一些代碼到版本控制系統(tǒng)。不出 30 分鐘，如果代碼導(dǎo)致了單元測(cè)試和集成測(cè)試失敗我就可以得到反饋。對(duì)不符合代碼質(zhì)量標(biāo)準(zhǔn)或者沒(méi)有足夠單元測(cè)試代碼覆蓋率的代碼同樣我也會(huì)得到反饋。
Agile 是成功的嗎？當(dāng)然。通過(guò)專注于提升市場(chǎng)和開(kāi)發(fā)團(tuán)隊(duì)之間的溝通以及盡早發(fā)現(xiàn)問(wèn)題，Agile 將軟件開(kāi)發(fā)提升到下一個(gè)等級(jí)。
就我個(gè)人而言，在 Agile 模型中與一些讓人激動(dòng)的團(tuán)隊(duì)一起工作是一個(gè)非常美妙的體驗(yàn)。軟件工程，對(duì)我來(lái)說(shuō)意味著從需求到最終應(yīng)用程序使用中間付出的所有努力的結(jié)果，第一次，覺(jué)得編程是一種享受。
但是，發(fā)展的腳步停止了嗎？并沒(méi)有。
新的挑戰(zhàn)出現(xiàn)了。
當(dāng)我們嘗試轉(zhuǎn)向微服務(wù)架構(gòu)，我們開(kāi)始開(kāi)發(fā)一些小型 API 而不是大型的應(yīng)用程序。
帶來(lái)的新的挑戰(zhàn)是什么呢？
運(yùn)維變得更重要了。不同于一個(gè)月發(fā)布一個(gè)版本，每周都要發(fā)布上百個(gè)小型的微服務(wù)。調(diào)試微服務(wù)的問(wèn)題以及搞清楚微服務(wù)之間如何工作的變得非常重要。
那時(shí)軟件開(kāi)發(fā)誕生了一個(gè)新的流行語(yǔ)。DevOps。
DevOps 主要聚焦哪些方面呢？
DevOps 主要聚焦提升開(kāi)發(fā)團(tuán)隊(duì)與運(yùn)維團(tuán)隊(duì)之間的溝通。
我們?cè)鯓幽茏岄_(kāi)發(fā)更容易一些？
怎樣讓運(yùn)維團(tuán)隊(duì)的工作在開(kāi)發(fā)團(tuán)隊(duì)那里看起來(lái)更透明？
DevOps 拉近了運(yùn)維團(tuán)隊(duì)與開(kāi)發(fā)團(tuán)隊(duì)之間的距離。
在更成熟的公司內(nèi)，運(yùn)維與開(kāi)發(fā)團(tuán)隊(duì)如同一個(gè)團(tuán)隊(duì)。他們開(kāi)始分享共同的目標(biāo)，彼此也能了解對(duì)方面臨的挑戰(zhàn)。
一些剛開(kāi)始轉(zhuǎn)向 DevOps 的企業(yè)，運(yùn)維團(tuán)隊(duì)的代表會(huì)參與到 Sprint 中 – 站會(huì)以及回顧都會(huì)參與。
除了 Agile 專注的領(lǐng)域之外（持續(xù)集成和自動(dòng)化測(cè)試），DevOps 團(tuán)隊(duì)會(huì)專注于幫助實(shí)現(xiàn)一些運(yùn)維團(tuán)隊(duì)活動(dòng)的自動(dòng)化，比如配置服務(wù)器、服務(wù)器上配置軟件、部署應(yīng)用以及監(jiān)控生產(chǎn)環(huán)境。有一些關(guān)鍵術(shù)語(yǔ)它們是持續(xù)部署、持續(xù)交付以及基礎(chǔ)設(shè)施即代碼。
持續(xù)部署是指的在測(cè)試環(huán)境上部署新的版本。甚至在諸如 Google、Facebook 這樣成熟的公司，持續(xù)交付每天都或許可以部署上百個(gè)版本到生產(chǎn)環(huán)境當(dāng)中。
基礎(chǔ)設(shè)施即代碼則是將你的基礎(chǔ)設(shè)施同你的應(yīng)用程序代碼等同對(duì)待。你利用配置以自動(dòng)化的方式創(chuàng)建了這些基礎(chǔ)架構(gòu)（服務(wù)器、負(fù)載均衡器、還有數(shù)據(jù)庫(kù)）。你需要對(duì)你的基礎(chǔ)架構(gòu)做到版本控制，這樣你可以以后追蹤基礎(chǔ)架構(gòu)的變更。
DevOps 將運(yùn)維團(tuán)隊(duì)和開(kāi)發(fā)團(tuán)隊(duì)整合到一起。因?yàn)檫\(yùn)維和開(kāi)發(fā)團(tuán)隊(duì)是一個(gè)團(tuán)隊(duì)的組成部分，整個(gè)團(tuán)隊(duì)都能夠知曉跟運(yùn)維和開(kāi)發(fā)團(tuán)隊(duì)相關(guān)的挑戰(zhàn)。
任何操作的問(wèn)題都能得到開(kāi)發(fā)人員的注意。
上線軟件的任何挑戰(zhàn)都會(huì)盡早得到運(yùn)維團(tuán)隊(duì)的注意。
DevOps 鼓勵(lì)持續(xù)集成、持續(xù)交付以及基礎(chǔ)設(shè)施即代碼。
因?yàn)槭褂贸掷m(xù)交付，如果我產(chǎn)生了一次代碼變更或者是一次配置變更或許會(huì)阻斷測(cè)試或者是一個(gè)暫存環(huán)境，我會(huì)在幾個(gè)小時(shí)內(nèi)知道。
因?yàn)槭褂没A(chǔ)設(shè)施即代碼，開(kāi)發(fā)人員可以自行配置環(huán)境、部署代碼、在不需要運(yùn)維團(tuán)隊(duì)幫助的前提下自行發(fā)現(xiàn)問(wèn)題。
雖然我們談?wù)?Agile 和 DevOps 是讓事情變得簡(jiǎn)單的兩種不同的事物，但事實(shí)上，對(duì)于 DevOps 是什么意思仍沒(méi)有一個(gè)公認(rèn)的定義。
我把 Agile 和 DevOps 看做幫助我們提高如何開(kāi)發(fā)出色軟件的兩種階段。它們不是競(jìng)爭(zhēng)關(guān)系，但是一起使用能夠幫助我們構(gòu)建令人驚嘆的軟件產(chǎn)品。
就我而言，Agile 和 DevOps 一起使用的目的具體來(lái)說(shuō)是
提升市場(chǎng)、研發(fā)和運(yùn)維團(tuán)隊(duì)的溝通
減緩自動(dòng)化的痛點(diǎn)。在這個(gè)課程的奇妙旅程中我們將會(huì)討論單元測(cè)試、集成測(cè)試、代碼質(zhì)量檢查、持續(xù)集成、持續(xù)交付、基礎(chǔ)設(shè)施即代碼以及通過(guò)容器標(biāo)準(zhǔn)化。
話說(shuō)有這樣一個(gè)令人驚嘆的故事:
你是團(tuán)隊(duì)中的開(kāi)發(fā)之星，然后你需要快速修復(fù)一個(gè) bug。你要到 GitHub 上去看看！
快速的檢出了項(xiàng)目代碼。
快速的創(chuàng)建了本地環(huán)境。
創(chuàng)建了一個(gè)變更。也測(cè)試完了。然后更新了單元測(cè)試和自動(dòng)化測(cè)試。
提交了。
你查收到一封郵件說(shuō)是它已經(jīng)部署到了 QA。
一些集成測(cè)試在自動(dòng)運(yùn)行。
你的 QA 團(tuán)隊(duì)收到一封請(qǐng)求測(cè)試的郵件。他們開(kāi)始手工測(cè)試然后通過(guò)。
你的代碼在幾分鐘內(nèi)上線到生產(chǎn)環(huán)境。
你或許為想這事一個(gè)理想的場(chǎng)景。但是，你需要知道的是這就是在諸如 Netflix、Amazon 以及 Google 這些創(chuàng)新公司的日常！
這就是 DevOps 的故事。
DevOps 是軟件開(kāi)發(fā)的一個(gè)自然的進(jìn)化。DevOps _不僅僅_是一個(gè)工具，一個(gè)框架或者僅僅就是自動(dòng)化而已。它是這些東西的組合。
DevOps 專注于人、流程和產(chǎn)品。DevOps 中的人指的是文化以及創(chuàng)造一個(gè)出色的心態(tài) – 一種促進(jìn)開(kāi)放交流以及快速反饋的文化，一種創(chuàng)造高質(zhì)量軟件的文化。
Agile 則幫助在市場(chǎng)和開(kāi)發(fā)團(tuán)隊(duì)之間架設(shè)橋梁。開(kāi)發(fā)團(tuán)隊(duì)了解市場(chǎng)的優(yōu)先級(jí)同市場(chǎng)一道傳遞最有價(jià)值的故事。然而，Dev 和 Ops 并沒(méi)有保持一致。
他們有不同的目標(biāo)。
Dev 團(tuán)隊(duì)的目標(biāo)是將盡可能多的功能添加到產(chǎn)品中。
Ops 團(tuán)隊(duì)的目標(biāo)是保持生產(chǎn)環(huán)境越穩(wěn)定越好。
如你所見(jiàn)，如果產(chǎn)品進(jìn)入市場(chǎng)這么難的話，開(kāi)發(fā)和運(yùn)維團(tuán)隊(duì)就沒(méi)法達(dá)成一致。
DevOps 目標(biāo)是讓 Dev 和 Ops 團(tuán)隊(duì)通過(guò)一些相同的目標(biāo)凝聚到一起。
Dev 團(tuán)隊(duì)與 Ops 團(tuán)隊(duì)一同工作能夠了解和解決運(yùn)維中遇到的挑戰(zhàn)。Ops 團(tuán)隊(duì)是 Scrum 團(tuán)隊(duì)的一部分能夠了解到開(kāi)發(fā)功能的一些事情。
我們?cè)鯓幽茏屍鋵?shí)現(xiàn)呢？
打破 Dev 和 Ops 之間的隔閡！
在有成熟的 DevOps 企業(yè)里，Dev 和 Ops 作為 scrum 團(tuán)隊(duì)的組成部分彼此分擔(dān)責(zé)任。
然而，如果你處于轉(zhuǎn)至 DevOps 的初始階段，怎樣讓 Dev 和 Ops 團(tuán)隊(duì)有共同的目標(biāo)并且一起工作呢？
這里有一些你需要去做的事情:
第一件事你可以開(kāi)始著手做的就是讓運(yùn)維團(tuán)隊(duì)分享一些工作任務(wù)給開(kāi)發(fā)團(tuán)隊(duì)。例如，開(kāi)發(fā)團(tuán)隊(duì)可以負(fù)責(zé)產(chǎn)品上線的一周后新版本的發(fā)布工作。這能幫助開(kāi)發(fā)團(tuán)隊(duì)了解到運(yùn)維團(tuán)隊(duì)在上線新版本面對(duì)的挑戰(zhàn)并且可以協(xié)助他們探索更好的解決方案。
另一件你需要做的就是將一名運(yùn)維團(tuán)隊(duì)的成員參與到 Scrum 日?；顒?dòng)中。讓他們參加團(tuán)隊(duì)的站會(huì)以及總結(jié)會(huì)。
下一件你可以做的事情就是讓運(yùn)維團(tuán)隊(duì)面臨的問(wèn)題能更清晰的呈現(xiàn)給 Development 團(tuán)隊(duì)。當(dāng)你在運(yùn)維方面遇到問(wèn)題的時(shí)候，可以讓開(kāi)發(fā)團(tuán)隊(duì)中的一部分成員成為解決方案團(tuán)隊(duì)的一部分。
不管你要做哪一件事情，找到一條打破開(kāi)發(fā)和運(yùn)維團(tuán)隊(duì)共同工作的隔閡的方法。
因?yàn)樽詣?dòng)化另一個(gè)有趣的情景出現(xiàn)了。通過(guò)使用基礎(chǔ)設(shè)施即代碼以及 開(kāi)發(fā)自行配置，你可以創(chuàng)造一個(gè)不論開(kāi)發(fā)還是運(yùn)維都能理解的語(yǔ)言 - 代碼。細(xì)節(jié)會(huì)在下面的幾個(gè)步驟中再做說(shuō)明。
思考下面的圖片:
這張圖片展示了兩個(gè)簡(jiǎn)單的工作流
No 1: 使用 Terraform 和 Azure DevOps 為 Kubernetes 配置基礎(chǔ)設(shè)施即代碼。
No 2: 微服務(wù)持續(xù)部署: 使用 Azure DevOps 構(gòu)建部署微服務(wù)的 Docker 鏡像到 Kubernetes Cluster
聽(tīng)起來(lái)很復(fù)雜是嗎？
讓我們?cè)囍纸馊缓笤偃ダ斫庖幌隆?/p>
讓我們先從 No 2 – 持續(xù)部署開(kāi)始。
如果有出色的測(cè)試和代碼質(zhì)量檢查但不經(jīng)常運(yùn)行它們的話那它們還有什么用呢？
如果你有自動(dòng)部署但是不常部署軟件的話那它還有什么用呢？
只要開(kāi)發(fā)人員提交代碼到版本控制系統(tǒng)，下面的步驟就會(huì)被執(zhí)行:
單元測(cè)試。
代碼質(zhì)量檢查。
集成測(cè)試。
應(yīng)用程序打包 – 推出新的應(yīng)用程序或者上線新版本的應(yīng)用程序。
給測(cè)試團(tuán)隊(duì)發(fā)送測(cè)試應(yīng)用程序的郵件
一旦得到了測(cè)試團(tuán)隊(duì)的允許，應(yīng)用就立即部署到下一個(gè)環(huán)境。
這被稱作持續(xù)部署。如果你持續(xù)部署到生產(chǎn)環(huán)境，則稱作持續(xù)交付。
最受歡迎的 CI/CD 工具是 Azure DevOps 和 Jenkins。
過(guò)去，我們手動(dòng)創(chuàng)建環(huán)境還有部署應(yīng)用程序。
每次創(chuàng)建一個(gè)服務(wù)器，這些就需要手工做完。
如果 Java 版本需要更新怎么辦？
需要應(yīng)用一個(gè)安全補(bǔ)丁嗎？
你需要手動(dòng)做。
結(jié)果是什么呢？
非常有可能會(huì)出錯(cuò)。
復(fù)制環(huán)境非常困難。
基礎(chǔ)設(shè)施即代碼 – 將基礎(chǔ)設(shè)施等同于應(yīng)用代碼。
這里有幾個(gè)理解基礎(chǔ)設(shè)施即代碼比較重要的知識(shí)點(diǎn)
基礎(chǔ)設(shè)施團(tuán)隊(duì)專注于能夠增值的工作（而不是日常工作）。
更少的錯(cuò)誤可以更快的從失敗中恢復(fù)。
服務(wù)器是一致的（避免了 Configuration Drift）。
最受歡迎的 IaC 工具是 Ansible 和 Terraform。
一般來(lái)說(shuō)在 IaC 中有這樣幾步
從一個(gè)模板中配置服務(wù)器（通過(guò) Cloud 啟用）
安裝軟件
配置軟件
一般來(lái)說(shuō)，配置工具用在配置服務(wù)器上起到讓服務(wù)器具備網(wǎng)絡(luò)功能的作用。最受歡迎的配置工具是 CloudFormation 和 Terraform。
使用 Terraform，你可以配置服務(wù)器以及其他的基礎(chǔ)設(shè)施，比如負(fù)載均衡器、數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)配置等。你可以使用類似 Packer 和 AMI（Amazon Machine Image）工具預(yù)創(chuàng)建的鏡像創(chuàng)建服務(wù)器。
配置管理用來(lái)
安裝軟件
配置軟件
受歡迎的配置管理工具有 Chef、Puppet、Ansible 和 SaltStack。這些被設(shè)計(jì)用作在已有服務(wù)器上安裝管理軟件。
Docker 和 Kubernetes 在DevOps 起到的角色是什么樣的？
在微服務(wù)世界，一些微服務(wù)使用 Java 構(gòu)建的，一部分是用的 Python，一部分是用 JavaScript。
不同的微服務(wù)在構(gòu)建應(yīng)用程序以及部署到服務(wù)器上也是各不相同。
這就讓運(yùn)維團(tuán)隊(duì)的工作變得很困難。
我們?cè)鯓幽苷业揭粋€(gè)類似的方法可以部署多種類型的應(yīng)用程序呢？來(lái)說(shuō)說(shuō)容器和 Docker 吧。
使用 Docker，你可以構(gòu)建微服務(wù)鏡像 – 不論語(yǔ)言是什么。你可以運(yùn)行在任意基礎(chǔ)設(shè)施上使用相同的方法運(yùn)行這些鏡像。
這樣簡(jiǎn)化了操作。
Kubernetes 在這個(gè)基礎(chǔ)上添加了編排不同種類的容器和部署它們到集群的功能。
Kubernetes 同樣提供了:
服務(wù)發(fā)現(xiàn)。
負(fù)載均衡。
集中配置。
Docker 和 Kubernetes 讓 DevOps 更簡(jiǎn)單。
以下是幾個(gè)你可以在一段時(shí)間內(nèi)跟蹤和提升的比較重要的 DevOps 指標(biāo)項(xiàng)。
部署頻率 - 隔多長(zhǎng)時(shí)間就會(huì)部署一次應(yīng)用程序到生產(chǎn)環(huán)境中？
投入市場(chǎng)的時(shí)間 - 將一個(gè)特性從編碼到最終的產(chǎn)品需要耗費(fèi)多長(zhǎng)時(shí)間？
新發(fā)布版本的失敗率 - 多少個(gè)發(fā)布版本是失敗的？
修復(fù)時(shí)間 - 從需要修復(fù)產(chǎn)品問(wèn)題到發(fā)布到生產(chǎn)環(huán)境需要多長(zhǎng)時(shí)間？
平均恢復(fù)時(shí)間 - 生產(chǎn)環(huán)境從一個(gè)關(guān)鍵問(wèn)題中恢復(fù)需要多長(zhǎng)時(shí)間？
以下為一些 DevOps 的最佳實(shí)踐
標(biāo)準(zhǔn)化
有跨部門技能的團(tuán)隊(duì)
聚焦文化
自動(dòng)化，自動(dòng)化，還是自動(dòng)化
不變的基礎(chǔ)設(shè)施
開(kāi)發(fā)生產(chǎn)等同
版本控制所有事物
自行配置
應(yīng)該怎樣度量 DevOps 集成的成熟度呢？這里有一些關(guān)鍵的問(wèn)題需要解答。
每次提交都會(huì)自動(dòng)觸發(fā)自動(dòng)化測(cè)試和代碼質(zhì)量檢查嗎？
你的代碼都持續(xù)分發(fā)到生產(chǎn)環(huán)境了嗎？
你使用結(jié)對(duì)編程嗎？
你使用 TDD 和 BDD 嗎？
你是否有許多復(fù)用的模塊？
開(kāi)發(fā)團(tuán)隊(duì)可以自己配置環(huán)境嗎？
快速修復(fù)生產(chǎn)環(huán)境的問(wèn)題需要耗費(fèi)多長(zhǎng)時(shí)間？
你是否使用高質(zhì)量的類似生產(chǎn)環(huán)境的數(shù)據(jù)執(zhí)行完整的自動(dòng)化測(cè)試？
當(dāng)你的自動(dòng)化測(cè)試失敗的時(shí)候你的構(gòu)建是失敗的嗎？
你的測(cè)試周期短嗎？
你有自動(dòng) NFR 測(cè)試嗎？
你有開(kāi)發(fā)生產(chǎn)等同嗎？
你有使用 A/B 測(cè)試嗎？
你有使用金絲雀部署嗎？
你能按下按鈕就可以開(kāi)始部署嗎？
你能按下按鈕就可以執(zhí)行回滾嗎？
你能按下按鈕就可以配置和發(fā)布基礎(chǔ)架構(gòu)嗎？
你可以為你的基礎(chǔ)架構(gòu)使用 IAC 和版本控制嗎？
團(tuán)隊(duì)使用的是一個(gè)集中監(jiān)控工具嗎？
開(kāi)發(fā)團(tuán)隊(duì)可以按下按鈕就可以獲得日志嗎？
生產(chǎn)環(huán)境出現(xiàn)問(wèn)題時(shí)團(tuán)隊(duì)能自動(dòng)收到報(bào)警嗎？
團(tuán)隊(duì)看起來(lái)是持續(xù)改進(jìn)的嗎？
團(tuán)隊(duì)是否擁有業(yè)務(wù)、開(kāi)發(fā)、和運(yùn)維的全部技能？
團(tuán)隊(duì)是否跟蹤 DevOps 的關(guān)鍵指標(biāo)然后去改進(jìn)它們嗎？
你是否使用本地發(fā)現(xiàn)并用它們進(jìn)一步實(shí)現(xiàn)全球改進(jìn)的文化？
上述內(nèi)容就是如何使用 Docker和Kubernetes及Azure DevOps實(shí)現(xiàn) DevOps，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
重慶分公司
重慶分公司
