DevOps是對已建立的 IT流程的簡化或者自動化。這里有一個簡短的教程來幫助你理解和開始使用 DevOps。

DevOps…CI/CD…Docker…Kubernetes…我敢肯定你在過去的一年里經(jīng)常聽人說這些詞。好像全世界都在談?wù)撨@些技術(shù)，以至于你覺得即將到達(dá)NoOps階段。

別擔(dān)心，在工具和各種最佳實踐的浩瀚海洋中感到迷失是正常的。是時候讓我們來分析一下DevOps到底是什么了。

這篇文章的目的，就是為你建立一個堅實的基礎(chǔ)。所以讓我們從一個明顯的問題開始。

什么是DevOps?

DevOps是對已建立的 IT流程的簡化或者自動化。

我見過很多人開始使用DevOps，最終卻都迷失了。這似乎是一種魔咒。

通常從一段視頻開始，講述一家高科技初創(chuàng)公司是如何自動化整個產(chǎn)品發(fā)布流程的。一旦所有測試通過，部署就會自動進(jìn)行。發(fā)生故障時，可以自動回滾。同時進(jìn)行A/B測試，提高了客戶參與度。

老實說吧，我們都想實現(xiàn)這樣的DevOps。我們都厭倦了像坐過山車一樣的發(fā)布新版本。

不幸的是，DevOps不是這樣工作的。DevOps并不是一根魔法棒，它能在一瞬間解決你所有的問題。

相反，這是一個系統(tǒng)性的工程，你應(yīng)該使用合適的工具和技術(shù)來完成不同的任務(wù)。

所有的一切都是為了流程

具體是什么流程并不重要，只要它可以簡化應(yīng)用程序的部署或者自動化測試，讓你的生活更輕松，那這就是DevOps的全部內(nèi)容。

事實上，如果你的流程不能手動完成(針對較小的流程)，你可能需要重新定義你的流程。

好了，讓我們舉一個真實的例子來更好地理解“流程”。

一個真實的DevOps例子

我們舉一個，在云虛擬機(jī)上部署Nodejs應(yīng)用程序的例子。

流程

我們的流程如下：

從源代碼開始(Start with the source code)：只要我們能訪問源代碼，我們就可以在任何地方運行我們的代碼。

構(gòu)建制品(Build an Artifact)：然后我們打包源代碼來構(gòu)建一個制品。如果是Java語言，那么JAR文件就是我們的制品。但在我們Nodejs的例子中，源代碼本身就是要發(fā)布的制品。

發(fā)布到制品倉庫(Publish to an Artifact Repository)：接下來，我們將制品推送到制品倉庫。然后我們的虛擬機(jī)就可以從制品倉庫中提取制品。我們可以直接使用Github作為我們的制品倉庫，因為我們的源代碼即制品。

拉取并運行應(yīng)用程序(Pull and run your app)：最后，我們將制品拉取到虛擬機(jī)上，并通過指令npm start來啟動Nodejs進(jìn)程。

我們的第一個DevOps項目

我們不會在這里做任何花哨的事情。最簡單的自動化的方式就是寫一個shell腳本，按順序順序運行所有命令。恭喜你完成了我們的第一個DevOps項目!!!

我知道shell腳本聽起來太簡單了，不值得認(rèn)真對待。我懷疑你曾經(jīng)也寫過這樣的腳本。但相信我，這就是DevOps!

別擔(dān)心，我們馬上就可以看到那些花哨的東西了。但重要的是要理解DevOps就是這樣工作的。

“可重復(fù)”的重復(fù)性

讓我問你一個問題。你喜歡以下哪一個?

一個在60%的時間內(nèi)，能正常工作的自動化部署管道;

一個無聊的shell腳本，但是每次執(zhí)行都能完成任務(wù)。

如果你曾經(jīng)在半夜處理過生產(chǎn)故障，那么你將選擇shell腳本。

原因很簡單。可靠性遠(yuǎn)比自動化程度更重要。換句話說，一個DevOps流程必須能夠在每次運行時產(chǎn)生一致的結(jié)果。

使我們的過程可重復(fù)

以我們的shell腳本為例。目前，我們的shell腳本依賴于安裝在虛擬機(jī)上的Node.js。

如果沒有在虛擬機(jī)上安裝Node.js，會發(fā)生什么?一個錯誤的Node.js版本足以使我們的應(yīng)用程序不能正常運行。當(dāng)我們需要在虛擬機(jī)上安裝多種語言運行時時，情況只會變得更糟。

一個簡單的解決方案是將Node.js運行時與我們的源代碼一起歸檔到zip文件中。然后可以將zip文件發(fā)送到虛擬機(jī)。這樣，虛擬機(jī)就可以使用zip文件中的本地Node.js運行時來運行我們的應(yīng)用程序。

幸運的是，有一種工具可以讓我們的生活更輕松。

Docker和容器

如果你對Docker不熟悉，可以將Docker看作是一種將你的制品(artifact)及其所依賴的操作系統(tǒng)以及Node.js，一起打包進(jìn)容器鏡像中的方法。

使用容器，我們可以在安裝了Docker的虛擬機(jī)上部署任何應(yīng)用程序。

使用Docker，我們的流程將如下所示：

容器不僅僅能做到這些，但這卻是容器能如此流行的重要原因之一。

Docker對比容器

讓我澄清一下，Docker和容器并不是同一個東西。

Docker是一組實用工具，用于構(gòu)建和運送容器鏡像，以及使用容器運行時(如containerd)來運行容器。

考慮到最近發(fā)生的事件，許多人對Docker的未來感到擔(dān)憂。

重要的是要明白，Docker不會立馬消失，在構(gòu)建和運送容器鏡像領(lǐng)域，將繼續(xù)發(fā)揮重要作用。

認(rèn)真對待DevOps

我們已經(jīng)取得了一些重大進(jìn)展。希望我們能理解Docker是如何融入DevOps流程中的。

是時候把事情推向下一個層次了。

基于事件的觸發(fā)部署

我們的腳本看起來很穩(wěn)定，但仍然是手動觸發(fā)的。

如果我們能，當(dāng)有人往GitHub上推送代碼時自動觸發(fā)這個腳本，那不是更好嗎?換句話說，我們希望基于事件的觸發(fā)部署。

GitHub可以在一組特定的事件上調(diào)用webhook。為了實現(xiàn)這一點，我們需要創(chuàng)建一個簡單的HTTP服務(wù)器，每當(dāng)服務(wù)器接收到請求時，它就會執(zhí)行shell腳本。我們可以將GitHub配置為，當(dāng)發(fā)生Push事件時，觸發(fā)HTTP請求。我們將這個過程稱之為持續(xù)部署(Continuous Deployment)。

我們的新流程如下所示：

恭喜你，你剛剛成功創(chuàng)建了一個CD pipeline。

持續(xù)部署是一種軟件，負(fù)責(zé)將應(yīng)用程序從GitHub之類的東西一直帶到最終部署的目標(biāo)環(huán)境中。

這基本上就是你經(jīng)常聽到的CI/CD。當(dāng)人們談?wù)撓馢enkins和CircleCI這樣的工具時，他們通常指的是CI/CD。

DevOps模式

我想你已經(jīng)找到了一個模式。我們從一個流程開始，找到一個我們不滿意的部分，然后引入一些軟件來簡化或自動化它。

用代碼的方式來操作流程，這就是DevOps。

引入容器編排

最后讓我們做一個小小的改進(jìn)。到目前為止，我們一直將應(yīng)用程序部署在單個虛擬機(jī)上。如果我們想將應(yīng)用程序部署到多個虛擬機(jī)或者節(jié)點上呢?

實現(xiàn)這一點的最簡單方法是讓CD Server通過ssh連接到所有虛擬機(jī)，并將容器部署到每個虛擬機(jī)中。

使用這種方式時，每當(dāng)虛擬機(jī)的數(shù)量發(fā)生變化時，我們就需要更改腳本。但在真實世界中，我們希望我們的應(yīng)用程序是可以自動擴(kuò)縮容的。

更好的方法是創(chuàng)建另一個HTTP服務(wù)器來跟蹤虛擬機(jī)數(shù)量的變化。我們可以稱這個服務(wù)器為“飛行員(Pilot)”。

此服務(wù)器將負(fù)責(zé)對集群中的各個虛擬機(jī)執(zhí)行健康檢查，以維護(hù)活動的虛擬機(jī)列表。它甚至可以與云供應(yīng)商進(jìn)行通信，使事情變得更加健壯。

Pilot還將公開一個HTTP端點，以接受要生成的容器的詳細(xì)信息。然后，它可以與各個虛擬機(jī)通信以完成任務(wù)。

現(xiàn)在，我們的CD Server可以簡單地請求Pilot，而不是單獨與每個虛擬機(jī)通信。

我們的新流程如下所示：

我們將Pilot稱為容器編排器。其實這就是Kubernetes!你剛剛設(shè)計了一個迷你版的Kubernetes!

另外，Kubernetes在希臘語中就是Pilot的意思。這是不是巧合?

從哪里開始?

我們一起討論了不少工具。這是我的最后一點。有沒有想過為什么DevOps的空間如此分散?

如果你仔細(xì)想想，有這么多的工具，讓你很難決定：什么是正確的選擇，或者你應(yīng)該從哪里開始?

每個組織都有自己的做事方式和流程，因而他們使用的工具也不同。你的工作不是找出哪種工具是最好的。你的工作就是找出最適合你的流程。一旦你明白了這一點，這些工具就只需要谷歌搜索了。

所以現(xiàn)在你知道從哪里開始了。不是工具。而是從了解你的公司和團(tuán)隊如何做事開始。