[翻譯]DevOps with k8s 1-1 Introduction to DevOps

軟件交付週期愈來愈短，而另外一方面，應用程序的規模愈來愈大。軟件開發人員和IT運營商面臨着找到解決此問題的壓力。而有一個全新的角色，叫作DevOps，它致力於支持軟件構建和交付。

本章包括如下主題：

• 軟件交付方法是如何改變的？
• 什麼是微服務，爲何人們採用這種架構？
• DevOps如何支持構建應用程序並將其交付給用戶？

Software delivery challenges

(軟件交付挑戰)

構建一個計算機應用程序並將其交付給客戶，已通過了充分的論證，而且隨着時間的推移不斷演變。它與軟件開發生命週期（SDLC）息息相關；有這麼幾種經典

的演變過程、方法論和發展歷史，在本節中，咱們將詳細描述它。

Waterfall and physical delivery

（瀑布模型與物理交付）

早在20世紀90年代，軟件交付就採用了物理方法，如軟盤或CD-ROM。所以，SDLC是一個很是長期的計劃，由於它不容易（從新）交付給客戶。

當時，一個主要的軟件開發方法是瀑布模型，它有需求/設計/實現/驗證/維護階段，以下圖所示：

在這種狀況下，咱們不能回到前一個階段。例如，在開始或完成實現階段以後，不容許返回到設計階段（例如，查找技術可擴展性問題），由於這將會影響到進度和成本，項目傾向於繼續並完成發佈，而後進入下一個發佈週期，包括新的設計。

它與物理軟件交付徹底匹配，由於它須要與物流管理部門協調，後者向用戶發佈軟盤/光盤。過去，瀑布模型和實物交付須要一年到幾年的時間。

Agile and electrical delivery

(敏捷與電子交付)

幾年後，互聯網被普遍接受，隨後軟件交付方式也從物理方式轉變爲電子方式，如在線下載。所以，許多軟件公司（也被稱爲網絡公司）試圖找出如何縮短SDLC流程，以便交付可以擊敗競爭對手的軟件。

許多開發人員開始採用新的方法，如增量、迭代或敏捷模型，而後更快地交付給客戶，這樣即便發現了新的缺陷，也更容易更新並經過電子交付做爲補丁交付給客戶，Microsoft Windows update也從Windows 98開始引入的。

在這種狀況下，軟件開發人員只編寫一個小邏輯或模塊，而不是一次性地編寫整個應用程序。隨後它便被交付給QA，開發人員繼續添加一個新模塊，而後再次交付給QA。

當所需的模塊或功能準備就緒時，將按下圖所示進行發佈：

該模型使得SDLC週期和軟件交付速度更快，而且在過程當中易於調整，由於整個週期縮短至幾周到幾個月，能夠快速調整。

儘管這種模式目前受到大多數人的青睞，但在當時，應用軟件交付意味着軟件二進制，例如設計用於在客戶PC上安裝和運行的EXE程序。另外一方面，基礎設施（如服務器和網絡）幾乎是靜態的，而且須要預先設置好。所以，SDLC還不打算將這些基礎設施也歸入其中。

Software delivery on the cloud

（雲軟件交付）

又過了幾年，智能手機（如iPhone）和無線技術（如Wi-Fi和4G網絡）被普遍接受，軟件應用也從二進制變成了在線服務。web瀏覽器是應用軟件的接口，再也不須要安裝。另外一方面，基礎設施變得動態，由於應用程序需求不斷變化，生產效率也須要提升。

虛擬化技術和軟件定義網絡（SDN）使服務器機器具備動態性。如今，Amazon Web services（AWS）和Google cloud Platform（GCP）等雲服務能夠很容易地建立和管理動態基礎設施。

如今，基礎設施是軟件開發交付週期的一個重要組成部分，由於應用程序是在服務器端而不是在客戶機上安裝和運行的。

正由於如此，軟件和服務交付週期如今只須要幾天到幾周的時間。

Continuous Integration

（持續集成）

如前所述，軟件交付環境不斷變化；然而，交付週期愈來愈短。爲了實現更高質量的快速交付，開發人員和QA開始採用一些自動化技術。持續集成（CI）是目前流行的自動化技術之一。CI包含一些工具的組合，如版本控制系統（VCS）、構建服務器和測試自動化工具。

VCS幫助開發人員在中央服務器上維護程序源代碼。它能夠防止重寫或與其餘開發人員的代碼衝突，還能夠保留歷史記錄。所以，保持源代碼的一致性並將其傳遞到下一個週期變得更容易。

與VCS同樣，有一個集中的構建服務器，它鏈接VCS，以便在開發人員將代碼更新到VCS時按期或自動檢索源代碼，同時觸發新的構建。若是構建失敗，它會及時通知開發人員。所以，，它能夠幫助開發人員避免將有BUG的代碼提交到VCS。

測試自動化工具還與構建服務器進行集成測試，後者在構建成功後調用單元測試程序，而後將結果通知開發人員和QA。它有助於識別什麼時候有人編寫了錯誤代碼並存儲到VCS中。

CI的整個流程以下圖所示：

CI不只能夠幫助開發人員和QA提升質量，還能夠縮短應用程序或模塊包的歸檔週期。在向客戶提供電子交付的時代，CI已經足夠了。可是如今則遠遠不夠，由於在當前，交付給客戶意味着部署到服務器。

Continuous Delivery

（持續交付）

CI plus部署自動化是服務器應用程序向客戶提供服務的理想過程。然而，還有一些技術挑戰須要解決。如何向服務器交付軟件？如何優雅地關閉現有應用程序？如何替換和回滾應用程序？若是系統庫也須要更改，如何升級或替換？如何根據須要修改操做系統中的用戶和組設置？等等。

由於基礎設施包括服務器和網絡，因此它都依賴於諸如Dev/QA/staging/production這樣的環境。每一個環境都有不一樣的服務器配置和IP地址。

持續交付（CD）是一種能夠實現的實踐；它是CI工具、配置管理工具和編排工具的組合：

Configuration management

（配置管理）

配置管理工具備助於配置一個操做系統，包括用戶、組和系統庫，還能夠管理多個服務器，若是替換服務器，這些服務器將與所需的狀態或配置保持一致。

它不是腳本語言，由於腳本語言執行基於腳本的命令。若是咱們執行兩次腳本，可能會致使一些錯誤，例如，嘗試建立同一個用戶兩次。另外一方面，配置管理會查看狀態，所以若是已經建立了用戶，配置管理工具不會執行任何操做。可是，若是咱們意外或故意刪除用戶，配置管理工具將再次建立該用戶。

它還支持將應用程序部署或安裝到服務器。若是告訴配置管理工具下載應用程序，而後設置它並運行它，它會嘗試去運行這些步驟。

此外，若是告訴配置管理工具關閉應用程序，而後下載並替換到新的軟件包（若是可用），而後從新啓動應用程序，它將保持最新版本。

固然，有些用戶只想在須要時更新應用程序，例如藍綠部署。配置管理工具也容許您手動觸發執行。

tips

藍綠部署是一種準備兩組應用程序棧的技術，而後只有一個環境（例如：Blue）爲生產服務。而後，當須要部署新版本的應用程序時，部署到另外一側（例如：Green），而後執行最終測試。若是工做正常，更改負載均衡器或路由器設置，將網絡流從Blue切換到Green。而後，Green變爲生產，而Blue變爲休眠狀態，等待下一個版本的部署。

Infrastructure as code

基礎設施即代碼

配置管理工具不只支持操做系統或虛擬機，還支持雲基礎設施。若是須要在雲上建立和配置網絡、存儲和虛擬機，則須要一些雲平臺操做。

但配置管理工具備助於經過配置文件自動設置雲基礎設施，以下圖所示：

配置管理相對於維護操做手冊標準操做程序（SOP）有一些優點。例如，使用Git等VCS控制軟件維護配置文件，能夠跟蹤環境設置如何更改的歷史記錄。

複製環境也很容易。例如，您須要在雲上的其餘環境，若是遵循傳統方法（即讀取SOP文檔以操做雲），則它始終會存在潛在的人爲錯誤和操做錯誤。另外一方面，咱們能夠執行配置管理工具，該工具能夠快速、自動地在雲上建立環境。

Orchestration

(編排)

編排工具也被歸類爲配置管理工具之一。可是，在配置和分配雲資源時，它更加智能和動態。例如，編排工具管理多個服務器資源和網絡，而後當管理員但願增長應用程序實例時，編排工具能夠肯定可用的服務器，而後自動部署和配置應用程序和網絡。

儘管編排工具超出了SDLC的範圍，但當須要擴展應用程序和重構基礎設施資源時，它有助於持續交付。

總的來講，SDLC已經經過幾個過程、工具和方法來實現快速交付。最終，軟件（服務）交付只須要幾個小時到一天的時間。同時，爲了實現更大型和更豐富的應用，軟件體系結構和設計也在不斷髮展。