2017 年 10 月
第 32 卷，第 10 期
本文章是由機器翻譯。
雲端程式開發 - 建置更好的雲端程式開發：不變性的 5 個步驟
由Martin Albisetti | 2017 年 10 月
這些服務位於公用或私人雲端基礎結構上是否雲端傳遞已經成為 Web 服務部署，可接受的標準。雖然雲端承諾隨可用性、 自動化和靈活度，並非所有的 Web 服務被為了充分利用這些承諾。無法預期的雲端基礎結構和敏捷式軟體開發的 DevOps 循環已建立的隔離的軟體元件，可讓快速移動測試開發和生產環境的雲端中的 Web 服務的需求。
在 Bitnami，我們已經被住，很長的時間的軟體部署的演進，我們已大量投資在方便開發人員運用最佳的部署技術。其中一個技術是不可變的基礎結構，這是一種方法管理服務和軟體部署方式，元件會被取代，而變更的概念。作用中，應用程式或服務重新部署之後每次發生時的任何變更。
與牛寵物
袁偏差，創辦 OpenStack Foundation 的產生與此牛寵物的比喻。傳統的伺服器會視為寵物。它們有自己的信念，而且如果他們取得病假您護士及它們回到健全狀況。牛，相反地，所有相同的外觀。如果他們取得病假您只移除它們。可能要耗費更多要視為牛比來取代它們。此外，牛標尺。Farmer 將會加入群操作成長時，根據需求和預算。
雲端提供剛好足夠功能可讓您繼續您的伺服器視為寵物。問題是，它們寵物金魚。它很無趣。如果寵物取得病假時，您可以處理它，但如果您嘗試 vets 通常會在您拍手叫好。魚通常會沒有回應，並將死在任何時間，而不發出警告。
這就是為什麼不變 （或映像為基礎） 部署和使用公用或私人雲端通常一起移。如果您想要有信心地生產等級的 Web 服務在雲端中執行，它會是安排寵物的擁有權和部署基礎結構和可以輕鬆地重現或取代的軟體的時間。像牛。
若要了解細微差異，在這種方法，讓我們考慮使用雲端的優缺點。雲端提供用於會極為耗費資源，達到與私用的基礎結構的優點。除了世界各地備援性和快速傳遞提供地理接近使用者的內容，雲端部署，請啟用彈性。IT 組織可以呼叫於資源，如有需求，只支付它們在任何時候使用。這個視模型也可輕鬆地試驗新技術，以及沒有並不容易學習、 前期投資的拓撲。
另外還有好處隨附"的所有項目 」-為--服務模型。雲端提供大部分的通用的服務，您會想在新式 Web 軟體，包括資料庫 （SQL 和 NoSQL） HTTP 前端、 負載平衡器、 DNS、 區塊存放裝置、 物件儲存體、 記錄分析、 監視、 佇列、 AI 等等。清單會隨著每個月。和雲端可以讓您專注在核心業務上，方法是卸載至提供者的通用服務。
當然，所有項目會產生成本。採用視基礎結構表示放棄可靠性保證。在雲端執行個體可能會消失，或在任何時間，而不發出警告重新開機。同樣地，失敗模式可以是難以重現。也可能不穩定的行為。比方說的新執行個體可能會開機失敗或緩慢的磁碟 IO 或峰值 CPU 負載、 使用不明確的原因，可能會遇到的伺服器。
上面的雲端
不可變服務提供的優點和雲端部署的挑戰，就是完美的調整。主要優點：
- 如預期般將完全相同的位元組世界中的所有的部署。
- 啟動數十、 數百或甚至數千個新的執行個體以回應要求，具有少量或沒有準備。
- 在部署中建置自動錯誤復原。經過執行個體可以自動關閉或移除從服務要求和左的更新版本的檢查和新的權數，啟動可能發生方式偵錯，只要方便而非中斷的中間。
- 將部署自動化採用沒有開機後要轉換的映像。
之外也使用雲端，有許多優點 immutably 部署您的服務，而是從降低的複雜性及加快部署，以提升的安全性與相容性。
降低複雜性如果您有一組基本的三種服務，每個都有四個執行個體，平均您快速地得到 12 寵物。這是大量的摘要寵物 ！您可能會認為，四個執行個體完全相同的可能方式啟動，關閉，但您可以查看如何的六個月內每個執行個體將會升級，偵錯並會以不同的方式，恢復不再保證它們實際上相同不再。
相反地，不可變的方式表示您有一個映像。每四個執行個體將包含完全相同的程式碼，在部署階段，設定完全相同的方式。除非您之後變更的項目，您只需要了解及擔心映像的三個不同的變化。此外，任何在生產環境中，就會發生的漂移將每個後續的部署上重設。
加快部署不可變的部署轉移至組建階段中，將時間加入至部署這個階段，但防止在生產環境中失敗的許多繁重的工作 （包括下載、 編譯及驗證）。
一旦建立映像，部署會一樣快因為您必須將伺服器上特定的雲端，包括回復有問題的變更。此外，部署會變成有效不可部分完成，可讓您執行循環或叢集延展部署，同時確保任何特定的伺服器上有無半狀態。
更簡單的試驗與回復每個部署的單一映像表示您可以建立存留較短的實驗，並完成之後損毀。實驗也較低，因為您知道您從執行中的最後一個位元組到實際執行環境中的相同的基底開始。這可讓您更輕鬆地追蹤您嘗試進行的變更。
更好的重現不變性可確保，相同的程式碼會傳回相同的輸出中每個膝上型電腦、 每個持續整合 (CI) 和每一部伺服器。沒有任何不確定性對於正在使用程式碼和組態的組合。如果您有變更的環境或執行映像，您可以輕鬆地重新部署從相同的映像，若要返回以已知的良好狀態。假設每次進行變更，影像本身所產生，這會提供 「 類似實際執行環境 」 最接近的動作。
更嚴格的安全性與相容性透過每次將映像，您會知道完全執行的項目在任何時間點的任何伺服器上的時間，可讓您稽核單一成品，並確保這是執行的項目每個地方。在極端的情況下，您可以使用資源，例如 Docker 唯讀模式，以確保任何後續變更執行個體正在執行時。
改進災害復原建立不可變的基礎結構，則必須先在您的部署中的自動化的最低層級。當 （除非） 您的基礎結構會摺疊，這項改進可讓您復原以分鐘為單位而不是小時、 天或週。
升高不可變的階梯
建立不可變的服務不一定很容易，尤其是您的專案的建置基礎，假設通用的傳統資料中心，例如能夠寫入檔案系統上的任何位置，或覆寫現有檔案的快速就地升級。不過，您可以在不可變的服務在五步驟中，向述圖 1，透過提供具體的優點的每個步驟。
.png "不變性的 5 個步驟")
圖 1 5 步驟不變性
直到不可變的階梯爬升需要投資與耐心，但您會看到早期的好處，甚至是與做小幅變更。讓我們來探索不可變的服務工作中的步驟。
步驟 0:初始 Disentanglement
這個步驟是許多 disentangling 發生的位置。所花的時間才能看到新的處理程序，指令碼及範本深彼此結合，您可以透過具有更可重現的部署策略享有許多的不變性優點：
- 禁止就地升級您的程式碼的不可變的部署。
- 選擇最快的路徑，讓映像為基礎的部署，而不是就地升級。有數個方法來處理此：您目前的 VM 和使用做為基底映像並取代每個部署的執行個體，或您的程式碼將可以調整組態管理軟體的完整設定的香草映像，您可以快照集。
- 新的模型中，您會將每個執行個體部署為新的映像。這表示您必須能夠切換至 DNS 層級或 HTTP 前端中的新執行個體的流量，可能是負載平衡器，HTTP 伺服器快取層級或類似。
- 重要的資料必須儲存映像檔案系統中，外部或掛接的磁碟區。這將會繼續所有後續步驟中的需求。
在這個階段，許多項目可能會失敗，例如，您可能無法下載系統的封裝相依性或系統可能無法正確設定，因為競爭條件或扭曲預期的版本。重建整個映像中的一種方法或另一個每當，通常會花費很長的時間。
步驟 1：與作業系統的隔離
一旦您已經完成步驟 0 下, 一個目標就是清理自行從作業系統層。如此一來，可讓您從相同，這是已知的最起碼的映像啟動許多不同的服務和部署。它也可減少 im 年齡正加以維護，並加快建置程序的數目。除了謹記在心方面：
- 開始移動所有您從系統目錄的相依性。
- 程式設計語言和架構非常通常適合在此步驟中所需的區隔。如測驗 ple、 Python 的 Virtualenv、 Ruby 的 Gemfiles 而且 PHP 的編輯器都有隔離於系統的其餘部分的相依性，將它們儲存在預設情況下使用相對路徑的簡單方法。
- 已編譯的相依性可以更容易處理，因為它們通常預期在特定的系統路徑上尋找其相依性。
- 在這個階段來取代整個伺服器上每個部署，因此您必須先確定您未擲出重要的資料。請務必系統層級記錄檔會儲存外部的執行個體。
步驟 2：從執行階段隔離
因此，您已 untangled 從基礎作業系統服務。現在您需要確定您的語言執行階段的可預測且可靠。回復到您的基底映像的程式語言執行平台，包括您可能需要依預設，設定任何語言組態選項，而且您會知道可以依賴從它在每個執行個體相同的行為：
- 由於執行階段是 trivial 更新。它們不常變更，且可輕鬆地保持最新狀態，即使回復成基底映像。
- 復原到基底映像的執行階段可讓您控制時進行更新，這很重要，因為更新可以中斷相容性，並強制要求您的應用程式移植。
- 隔離的執行階段可以消除 baffling 微小的設定差異，所產生像 8MB 的大小和 memory_limit 64 MB 之間的實際執行挑戰。
- 在這個步驟中的不變性就仍然可以輕易達到由於 OS 和語言執行平台都適合隔離，亦即，在系統上的其他項目。
步驟 3：從 Framework 隔離
如果您有這個步驟中，您可能有這不變性東西的停止回應。您可以開始查看不可變的階梯值得上升狀況的原因。步驟 3 中，與您的承諾將取得測試，做為唯一的一些挑戰起始以顯示本身時使用的架構。這些技術包括：
- 架構變更位元頻率比執行階段，所以您需要更常更新基底映像。話雖如此，能夠管理自己的排程上的架構更新為重要的是，即使次要更新可能會破壞相容性。
- 架構通常會呈現多個安全性問題，因為他們的受攻擊面廣，通常只公開到網際網路。比方說，Python 會產生 26 常見弱點與揭露 (CVE) 與 48 CVEs Django。
- 因為架構傾向於認為它們 disentangling 部署取得堅固在這個階段，正在您的程式碼的組件的基底。您必須進一步了解您的架構，以了解最佳的方式來管理程式碼和架構之間的分離的內部運作方式。
步驟 4：每個部署的完全出爐映像
您所做的爬升 ！這是您的目的地。當您的映像開機時，它們已準備好進行動作。沒有任何下載、 初始化或主要設定的映像中的任何軟體。需要調整在這個階段的唯一項目是次要 perinstance 值，例如 IP 位址或執行個體名稱：
- 您的應用程式程式碼和資料的完全不同的基礎 OS、 執行階段和架構。試這些三個基本項目吃到基底的映像，而且您可以獨立更新程式碼和資料。
- 您不需要重建您的服務，從這裡，取得可用，但可能需要一些額外的工作，以確保您只能撰寫在特定位置。
- 當您已受管理的所有項目設定以符合此步驟中時，您可以使用自動調整規模啟動映像的方案啟動或關閉快速且可靠地。
獎金端步驟：不可變 + 無狀態
並非所有的服務將放入此模型。不過，如果您有無狀態服務的背景工作伺服器陣列，快取系統或靜態的網站，例如這種方法可讓您保留本身的映像中的所有資料。這種安排可提供直接從執行個體，可降低您的部署的複雜性，而且適用於：
- 唯讀資料，例如靜態網站 （在生產環境中沒有執行階段）。
- 背景工作，以處理資料，以及伺服器陣列，佇列 （相同的執行階段、 沒有本機狀態）。
不可變的階梯
現在，您的基礎結構不變，開發到生產週期將會最佳化，順暢且更流暢的是中, 所示圖 2。
.png "最佳化的生產週期")
圖 2 最佳化的生產週期
通常是較不可靠的資料中心，比，因為它們可能有很多雜訊的鄰近項目與共用基礎資源建立公用雲端。在 exchange 中，您可以自動調整規模並關閉變更要求的回應中的資源。這種排列方式表示您應該針對最佳化關閉並取代的執行個體。多執行個體比例，更多的投資自動化上表現卓著，因為您將需要更頻繁地備妥執行個體。您會發現最佳化您的執行個體變得更順暢的程序，讓您專注於對內 opment，而不是 handholding 部署。
電影"摘要巴波亞 」 中引用 Sylvester Stallone 如下：「 它都會損及現在...但是，一天，它會是您暖機 up 」。 當您開始的不可變的階梯步驟 0 時，您可能提醒自己痛苦值得改善。但是將會提升相當大。不可變的方法可讓您以確定項目運作之前它們移至生產環境中，而不是架構的 Os 後探索問題執行階段和應用程式的程式碼有機會針對每個其他適用於即時觸發部署。現在可以探索並處理 」 上地面 」 再進行部署，而不是在空中您的環境已啟動並執行詳細的失敗。
3 層
一旦您要產生每個部署的映像，您會想要考慮您的系統架構，為具有三個層級： 變動性的圖層、 永續性資料層和路由的圖層。在 Bitnami，我們花許多時間思考這些層級以及它們如何影響每個開放原始碼應用程式，特別是那些通常用於做為開放原始碼的建置組塊，例如資料庫和語言架構。
第 1 層：Volatile部署現在是可處置的映像，也可以取得被丟棄在每個部署，並取代成一個全新的內建。這使您的程式碼和寫入的所有資料在本機的可處置。您應該準備好刪除並取代任何這些執行個體的任何一點的時間。這些有效地變成無狀態伺服器。
第 2 層：永續性資料這是您要在其中儲存重要資料庫、 使用者檔案、 工作階段狀態和其他任何項目周圍讓相當重要。您要儲存的符合性與進行偵錯，以及這一層的服務和系統記錄檔。很難確保沒有單一失敗點存在於這一層，因此軟體做為服務的雲端解決方案，可以派上用場來解決這些問題。此層應該要很穩固，高可用性和完整備份。
第 3 層：路由volatile 層之後，您需要可預測和可定址的圖層，外部使用者及其他服務來存取您的服務。您必須擁有可預測的公用 IP 位址和網域名稱，從執行您的程式碼的動態伺服器分離，而且要能將要求轉送到伺服器的彈性集區。
總結
切記適用於開發人員會很明確：建置和執行不可變的服務提供極大的優點跨越管線就會從開發和建置到生產環境。使用每個對不可變的階梯採取的步驟，將現有的服務取得額外的優點和優點。
不可變的基礎結構，其核心即將部署和強制執行的處理序，可保證完整的自動化功能，可能最大範圍 — 在伺服器上執行的項目。步驟 0 是可以從這裡開始。即使您只會向上之第一個步驟，您的雲端工作負載會在更佳的情況下比之前。
Martin AlbisettiBitnami 資深建構人員，且先前已導向器的工程於 Canonical (Ubuntu)。Albisetti 花他使用其雙手鄉村烏拉圭，他所在他系列中的可用時間。您可以在 Twitter 上找到他： @beuno。
非常感謝下列 Microsoft 技術專家檢閱這篇文章：James McCaffrey