「雲端原生」或簡稱「雲端」應用程式是專門為在雲端基礎架構中工作而創建的。它們通常建構成一組打包在容器中的鬆散耦合的微服務，而容器又由雲端平台進行管理。預設情況下，此類應用程式已做好應對故障的準備，這意味著即使在發生嚴重的基礎設施級故障時，它們也能可靠地工作並可擴展。硬幣的另一面是雲端平台對容器應用程式施加的一組限制（合約），以便能夠自動管理它們。
儘管充分意識到遷移到基於雲端的應用程式的必要性和重要性，但許多組織仍然不知道從哪裡開始。在這篇文章中，我們將探討一些原則，如果在開發容器化應用程式時遵循這些原則，即使在IT 基礎架構發生嚴重故障的情況下，您也可以實現雲端平台的潛力並實現應用程式的可靠運行和擴展等級。這裡概述的原則的最終目標是學習如何建立可以由 Kubernetes 等雲端平台自動管理的應用程式。
軟體設計原則
在程式設計世界中，原則是指開發軟體時必須遵循的相當普遍的規則。使用任何程式語言時都可以使用它們。每個原則都有自己的目標，實現這些目標的工具通常是模板和實踐。還有一些創建高品質軟體的基本原則，所有其他原則都源自於這些原則。以下是基本原則的一些範例：
- （保持簡單，愚蠢）－不要讓它複雜化；
- (Don't Repeat Yourself) - 不要重複自己；
- （你不會需要它） - 不要創造不是立即需要的東西；
- 關注點分離－分擔責任。
正如您所看到的，這些原則沒有設定任何具體規則，而是屬於基於實踐經驗的所謂常識性考慮的範疇，這些常識性考慮是許多開發人員所共享的，並且是他們經常參考的。
此外，還有 – 羅伯特馬丁所製定的物件導向程式設計和設計的前五個原則。 SOLID 包含廣泛的、開放式的、互補的原則，當這些原則一起應用時，有助於創建更好的軟體系統並更好地長期維護它們。
SOLID原則屬於OOP領域，以類別、介面和繼承等概念和概念的語言來表達。以此類推，雲端應用的開發原則也可以製定，只是這裡的基本元素不會是類，而是容器。透過遵循這些原則，您可以創建更好地滿足 Kubernetes 等雲端平台的目的和目標的容器化應用程式。
雲原生容器：紅帽方法
如今，幾乎所有應用程式都可以相對輕鬆地打包到容器中。但要在 Kubernetes 這樣的雲端平台中有效地自動化和編排應用程序，還需要付出額外的努力。
下面概述的想法的基礎是方法論 以及關於建立 Web 應用程式各個方面的許多其他工作，從原始碼管理到擴展模型。所描述的原則僅適用於基於微服務建置並為 Kubernetes 等雲端平台設計的容器化應用程式的開發。我們討論的基本元素是容器鏡像，目標容器運行時是容器編排平台。所提出的原則的目標是創建可以在大多數編排平台上自動執行調度、擴展和監控任務的容器。這些原則的介紹沒有特定的順序。
單一關注原則（SCP）
該原則在許多方面與單一職責原則相似。 ），它是 SOLID 集的一部分，規定每個物件必須有一個職責，並且該職責必須完全封裝在一個類別中。 SRP 的要點是，每項職責都是變更的原因，一個類別必須有且只有一個變更的原因。
在 SCP 中，我們使用「關注」一詞而不是「責任」一詞來表示與 OOP 類別相比，容器具有更高的抽象層級和更廣泛的用途。如果 SRP 的目標是只有一個改變的理由，那麼 SCP 的背後就是擴展重複使用和替換容器的能力的願望。透過遵循 SRP 並建立解決單一問題並以功能完整的方式完成它的容器，您可以增加在不同應用程式上下文中重複使用該容器映像的機會。
SCP 原則規定，每個容器應該解決一個問題並做好它。此外，容器世界中的 SCP 比 OOP 世界中的 SRP 更容易實現，因為容器通常運行一個進程，並且大多數時候該進程解決一項任務。
如果某個容器微服務必須同時解決多個問題，那麼可以將其分割成單任務容器，並使用 sidecar 和 init 容器範本組合在一個 pod（容器平台部署的單位）內。此外，SCP 可以輕鬆地將舊容器（例如 Web 伺服器或訊息代理程式）替換為解決相同問題但具有擴展功能或更好擴展性的新容器。
高可觀測原則（HOP）
當容器被用作打包和運行應用程式的統一方式時，應用程式本身被視為黑盒子。但是，如果這些是雲端容器，則它們必須向運行時提供特殊的 API 來監視容器的運作狀況，並在必要時採取適當的操作。如果沒有這一點，就不可能統一更新容器和管理其生命週期的自動化，這反過來又會惡化軟體系統的穩定性和可用性。
實際上，容器化應用程式至少應該具有用於各種類型健康檢查的 API：活性測試和就緒測試。如果應用程式聲稱要做更多事情，它必須提供其他方法來監視其狀態。例如，透過 STDERR 和 STDOUT 記錄重要事件，以便使用 Fluentd、Logstash 和其他類似工具進行日誌聚合。以及與追蹤和指標收集庫的集成，例如 OpenTracing、Prometheus 等。
一般來說，應用程式仍然可以被視為黑盒子，但必須為其提供平台所需的所有 API，以便以最佳方式對其進行監控和管理。
生命週期一致性原則 (LCP)
LCP 是 HOP 的對立面。 HOP 規定容器必須向平台公開讀取 API，而 LCP 要求應用程式能夠從平台接受資訊。此外，容器不僅必須接收事件，還必須適應事件，換句話說，對事件做出反應。因此，該原則的名稱可以被視為向平台提供編寫 API 的要求。
平台具有不同類型的事件來幫助管理容器的生命週期。但由應用程式本身決定感知其中哪些以及如何做出反應。
顯然，有些事件比其他事件更重要。例如，如果應用程式不能很好地容忍崩潰，則它必須接受訊號：終止（SIGTERM）訊息並儘快啟動其終止例程以捕獲 SIGTERM 之後出現的訊號：kill（SIGKILL）。
此外，PostStart 和 PreStop 等事件對於應用程式的生命週期也很重要。例如，啟動應用程式後，可能需要一些預熱時間才能回應請求。或者應用程式在關閉時必須以某種特殊方式釋放資源。
影像不變性原則（IIP）
人們普遍認為，容器化應用程式在建置後應該保持不變，即使它們在不同的環境中運作。這就需要在運行時外部化資料儲存（換句話說，為此使用外部工具）並依賴外部的、運行時特定的配置，而不是為每個環境修改或建立唯一的容器。對應用程式進行任何更改後，必須重新建置容器映像並將其部署到使用的所有環境。順便說一句，在管理 IT 系統時，也使用類似的原則，稱為伺服器和基礎架構的不變性原則。
IIP 的目標是防止為不同的執行時間環境建立單獨的容器映像，並在任何地方使用相同的映像以及適當的特定於環境的配置。遵循這項原則可以讓您從雲端系統自動化的角度實現應用程式更新的回滾和前滾等重要實踐。
過程一次性原則（PDP）
容器最重要的特性之一是其短暫性：容器的實例易於建立且易於銷毀，因此可以隨時輕鬆地用另一個實例替換。進行此類替換的原因可能有很多：可服務性測試失敗、應用程式擴充、轉移到另一台主機、平台資源耗盡或其他情況。
因此，容器化應用程式必須使用某些外部手段來維護其狀態，或使用具有冗餘的內部分散式方案。此外，應用程式必須快速啟動和快速關閉，並為突發的致命硬體故障做好準備。
有助於實現這一原則的一種做法是保持容器較小。雲端環境可以自動選擇主機來啟動容器實例，因此容器越小，啟動速度就越快——它只會更快地透過網路複製到目標主機。
自包含原則（S-CP）
根據這項原則，在組裝階段，所有必要的零件都包含在容器中。容器應該建立在系統只有純 Linux 核心的假設之上，因此所有必要的附加程式庫都應該放置在容器本身中。它還應該包含相應程式語言的運行時、應用程式平台（如果需要）以及容器應用程式運行時所需的其他依賴項等內容。
對於因環境而異的配置，必須在執行時提供例外情況，例如透過 Kubernetes ConfigMap。
應用程式可能包括多個容器化元件，例如容器化 Web 應用程式內的單獨 DBMS 容器。根據S-CP原則，這些容器不應該合併為一個，而是應該使得DBMS容器包含資料庫運行所需的一切，而Web應用程式容器包含Web運行所需的一切應用程序，相同的網頁伺服器。因此，在運行時，Web 應用程式容器將依賴 DBMS 容器並根據需要存取它。
運行時限制原則 (RCP)
S-CP 原則定義了容器應如何建置以及映像二進位檔案應包含什麼。但容器不只是一個只有一個特徵——檔案大小的「黑盒子」。在執行期間，容器呈現其他維度：使用的記憶體量、CPU 時間和其他系統資源。
這裡 RCP 原則就派上用場了，根據該原則，容器必須減少對系統資源的需求並將其轉移到平台。透過每個容器的資源設定檔（需要多少 CPU、記憶體、網路和磁碟資源），平台可以最佳地執行調度和自動縮放、管理 IT 容量並維護容器的 SLA 等級。
除了滿足容器的資源需求外，應用程式不要超越自身的邊界也很重要。否則，當發生資源短缺時，平台更有可能將其列入需要終止或遷移的應用程式清單中。
當我們談論雲端優先時，我們談論的是我們的工作方式。
上面，我們制定了一些通用原則，為雲端環境建立高品質的容器應用程式奠定了方法基礎。
請注意，除了這些一般原則之外，您還需要使用容器的其他進階方法和技術。此外，我們還有一些更具體的簡短建議，應根據具體情況應用（或不應用）：
- 試著縮小鏡像的大小：刪除臨時文件，不要安裝不必要的軟體包－容器大小越小，透過網路組裝並複製到目標主機的速度就越快。
- 關注任意使用者 ID：不要使用 sudo 指令或任何特殊使用者 ID 來啟動容器。
- 標記重要連接埠：您可以在運行時設定連接埠號，但最好使用 EXPOSE 命令指定它們 - 這將使其他人和程式更容易使用您的映像。
- 在磁碟區上儲存持久性資料：容器銷毀後應保留的資料應寫入磁碟區中。
- 編寫圖像元資料：標籤、標籤和註釋使圖像更易於使用 - 其他開發人員會感謝您。
- 同步主機和鏡像：一些容器化應用程式要求容器在某些屬性上與主機同步，例如時間或機器ID。
- 總而言之，我們分享模板和最佳實踐，將幫助您更有效地實施上述原則：
11 月 11.00 日 XNUMX 點
你將學到什麼：
- 不可變的紅帽企業 Linux CoreOS
- OpenShift 服務網格
- 算子框架
- Knative框架
來源： www.habr.com