什么是DevOps？一份簡單易懂的教程
DevOps是對已建立的 IT流程的簡化或者自動化。這里有一個簡短的教程來幫助你理解和開始使用 DevOps。
DevOps…CI/CD…Docker…Kubernetes…我敢肯定你在過去的一年里經常聽人說這些詞。好像全世界都在談論這些技術，以至于你覺得即將到達NoOps階段。
別擔心，在工具和各種最佳實踐的浩瀚海洋中感到迷失是正常的。是時候讓我們來分析一下DevOps到底是什么了。
這篇文章的目的，就是為你建立一個堅實的基礎。所以讓我們從一個明顯的問題開始。
什么是DevOps?
DevOps是對已建立的 IT流程的簡化或者自動化。
我見過很多人開始使用DevOps，最終卻都迷失了。這似乎是一種魔咒。
通常從一段視頻開始，講述一家高科技初創公司是如何自動化整個產品發布流程的。一旦所有測試通過，部署就會自動進行。發生故障時，可以自動回滾。同時進行A/B測試，提高了客戶參與度。
老實說吧，我們都想實現這樣的DevOps。我們都厭倦了像坐過山車一樣的發布新版本。
不幸的是，DevOps不是這樣工作的。DevOps并不是一根魔法棒，它能在一瞬間解決你所有的問題。
相反，這是一個系統性的工程，你應該使用合適的工具和技術來完成不同的任務。
所有的一切都是為了流程
具體是什么流程并不重要，只要它可以簡化應用程序的部署或者自動化測試，讓你的生活更輕松，那這就是DevOps的全部內容。
事實上，如果你的流程不能手動完成(針對較小的流程)，你可能需要重新定義你的流程。
好了，讓我們舉一個真實的例子來更好地理解“流程”。
一個真實的DevOps例子
我們舉一個，在云虛擬機上部署Nodejs應用程序的例子。
流程
我們的流程如下：
從源代碼開始(Start with the source code)：只要我們能訪問源代碼，我們就可以在任何地方運行我們的代碼。
構建制品(Build an Artifact)：然后我們打包源代碼來構建一個制品。如果是Java語言，那么JAR文件就是我們的制品。但在我們Nodejs的例子中，源代碼本身就是要發布的制品。
發布到制品倉庫(Publish to an Artifact Repository)：接下來，我們將制品推送到制品倉庫。然后我們的虛擬機就可以從制品倉庫中提取制品。我們可以直接使用Github作為我們的制品倉庫，因為我們的源代碼即制品。
拉取并運行應用程序(Pull and run your app)：最后，我們將制品拉取到虛擬機上，并通過指令npm start來啟動Nodejs進程。
我們的第一個DevOps項目
我們不會在這里做任何花哨的事情。最簡單的自動化的方式就是寫一個shell腳本，按順序順序運行所有命令。恭喜你完成了我們的第一個DevOps項目!!!
我知道shell腳本聽起來太簡單了，不值得認真對待。我懷疑你曾經也寫過這樣的腳本。但相信我，這就是DevOps!
別擔心，我們馬上就可以看到那些花哨的東西了。但重要的是要理解DevOps就是這樣工作的。
“可重復”的重復性
讓我問你一個問題。你喜歡以下哪一個?
一個在60%的時間內，能正常工作的自動化部署管道;
一個無聊的shell腳本，但是每次執行都能完成任務。
如果你曾經在半夜處理過生產故障，那么你將選擇shell腳本。
原因很簡單。可靠性遠比自動化程度更重要。換句話說，一個DevOps流程必須能夠在每次運行時產生一致的結果。
使我們的過程可重復
以我們的shell腳本為例。目前，我們的shell腳本依賴于安裝在虛擬機上的Node.js。
如果沒有在虛擬機上安裝Node.js，會發生什么?一個錯誤的Node.js版本足以使我們的應用程序不能正常運行。當我們需要在虛擬機上安裝多種語言運行時時，情況只會變得更糟。
一個簡單的解決方案是將Node.js運行時與我們的源代碼一起歸檔到zip文件中。然后可以將zip文件發送到虛擬機。這樣，虛擬機就可以使用zip文件中的本地Node.js運行時來運行我們的應用程序。
幸運的是，有一種工具可以讓我們的生活更輕松。
Docker和容器
如果你對Docker不熟悉，可以將Docker看作是一種將你的制品(artifact)及其所依賴的操作系統以及Node.js，一起打包進容器鏡像中的方法。
使用容器，我們可以在安裝了Docker的虛擬機上部署任何應用程序。
使用Docker，我們的流程將如下所示：
容器不僅僅能做到這些，但這卻是容器能如此流行的重要原因之一。
Docker對比容器
讓我澄清一下，Docker和容器并不是同一個東西。
Docker是一組實用工具，用于構建和運送容器鏡像，以及使用容器運行時(如containerd)來運行容器。
考慮到最近發生的事件，許多人對Docker的未來感到擔憂。
重要的是要明白，Docker不會立馬消失，在構建和運送容器鏡像領域，將繼續發揮重要作用。
認真對待DevOps
我們已經取得了一些重大進展。希望我們能理解Docker是如何融入DevOps流程中的。
是時候把事情推向下一個層次了。
基于事件的觸發部署
我們的腳本看起來很穩定，但仍然是手動觸發的。
如果我們能，當有人往GitHub上推送代碼時自動觸發這個腳本，那不是更好嗎?換句話說，我們希望基于事件的觸發部署。
GitHub可以在一組特定的事件上調用webhook。為了實現這一點，我們需要創建一個簡單的HTTP服務器，每當服務器接收到請求時，它就會執行shell腳本。我們可以將GitHub配置為，當發生Push事件時，觸發HTTP請求。我們將這個過程稱之為持續部署(Continuous Deployment)。
我們的新流程如下所示：
恭喜你，你剛剛成功創建了一個CD pipeline。
持續部署是一種軟件，負責將應用程序從GitHub之類的東西一直帶到最終部署的目標環境中。
這基本上就是你經常聽到的CI/CD。當人們談論像Jenkins和CircleCI這樣的工具時，他們通常指的是CI/CD。
DevOps模式
我想你已經找到了一個模式。我們從一個流程開始，找到一個我們不滿意的部分，然后引入一些軟件來簡化或自動化它。
用代碼的方式來操作流程，這就是DevOps。
引入容器編排
最后讓我們做一個小小的改進。到目前為止，我們一直將應用程序部署在單個虛擬機上。如果我們想將應用程序部署到多個虛擬機或者節點上呢?
實現這一點的最簡單方法是讓CD Server通過ssh連接到所有虛擬機，并將容器部署到每個虛擬機中。
使用這種方式時，每當虛擬機的數量發生變化時，我們就需要更改腳本。但在真實世界中，我們希望我們的應用程序是可以自動擴縮容的。
更好的方法是創建另一個HTTP服務器來跟蹤虛擬機數量的變化。我們可以稱這個服務器為“飛行員(Pilot)”。
此服務器將負責對集群中的各個虛擬機執行健康檢查，以維護活動的虛擬機列表。它甚至可以與云供應商進行通信，使事情變得更加健壯。
Pilot還將公開一個HTTP端點，以接受要生成的容器的詳細信息。然后，它可以與各個虛擬機通信以完成任務。
現在，我們的CD Server可以簡單地請求Pilot，而不是單獨與每個虛擬機通信。
我們的新流程如下所示：
我們將Pilot稱為容器編排器。其實這就是Kubernetes!你剛剛設計了一個迷你版的Kubernetes!
另外，Kubernetes在希臘語中就是Pilot的意思。這是不是巧合?
從哪里開始?
我們一起討論了不少工具。這是我的最后一點。有沒有想過為什么DevOps的空間如此分散?
如果你仔細想想，有這么多的工具，讓你很難決定：什么是正確的選擇，或者你應該從哪里開始?
每個組織都有自己的做事方式和流程，因而他們使用的工具也不同。你的工作不是找出哪種工具是最好的。你的工作就是找出最適合你的流程。一旦你明白了這一點，這些工具就只需要谷歌搜索了。
所以現在你知道從哪里開始了。不是工具。而是從了解你的公司和團隊如何做事開始。
