有關云可移植性的三個考量:一. 云原生和容器?
市面上的云服務平臺豐富各異,如何選擇最適合自己的?這往往需要慎重考慮。然而更重要的是,您考慮過云的可移植性問題嗎?您在今年根據具體需求選擇的云平臺,能否滿足以后的需求?如果不能滿足,是否可以方便快捷地將應用移植到其他平臺去?
延伸閱讀,了解 Akamai cloud-computing
出海云服務,選擇Akamai cloud-computing!
在這一系列文章中,我們將從架構、設計等不同方面來探討,在云的可移植性方面,具體都需要考慮哪些細節問題,如何最大限度避免云時代的技術鎖定,充分發揮云的靈活性優勢。
下文將簡要探討云原生和容器技術。
在云時代,諸如容器和無服務器計算這樣的云原生技術是構建高可移植性應用程序時不可或缺的。在這些技術的幫助下,我們可以設計出更具彈性和擴展性,同時適應性也更強的應用程序,從而適應不斷變化的環境。實際上,我們可以用一個詞來解釋所有這些好處:可移植性。
與日漸繁瑣并且幾乎無法管理的單體(Monolithic)模型不同,云原生微服務架構是模塊化(Modular)的。這種方法使得我們可以自由地為工作選擇適合的工具,用一個服務來執行一種特定功能,通過“專精”獲得更好的效果。云原生方法就是在這種情況下開始大放異彩的,它提供了一種有效的流程,方便我們更新和替換應用程序中的單個組件,而不會對整個工作負載產生影響。使用云原生思維進行開發,這會催生出一種聲明性(Declarative)的部署方法:分別部署應用程序、為其提供支撐的軟件棧,以及配套的系統配置。
為何使用容器?
我們可以把容器想像成一種專為執行某一種特定任務而設計的超輕量級虛擬機。容器的壽命往往很短暫,前一分鐘可能還在運行,下一分鐘就消失了,因此缺乏持久性。實際上,所需的持久性是通過綁定主機文件系統中的塊存儲或所掛載的其他存儲服務來實現的,并非通過與容器本身的綁定來實現。
通過對應用程序進行容器化改造,即可使其具備可移植性!只需準備好一個容器鏡像,就能將其部署到不同架構CPU上運行的不同操作系統中,并順序運行該容器。由于容器化應用程序是一種自包含(Self-contained)的獨立單元,其中包括了所有必須的依賴項、庫以及配置文件,因此在不同云環境中運行時完全無需更改代碼。
簡單來說,在云原生設計中,容器是通過下列方式實現可移植性的:
- 輕量級虛擬化:容器為應用程序的運行提供了一種隔離的環境,雖然共享主機操作系統內核,但會對進程、文件系統以及網絡資源進行隔離。
- 可移植且一致:容器將應用程序及其依賴項打包在一起,確保無論在開發還是生產環境中,應用程序都可以一致地運行。
- 資源效率:容器比虛擬機消耗的資源更少,因為容器會隔離進程并共享主機操作系統的內核;同時容器不需要在主機操作系統之上運行一個單獨的“來賓”操作系統,這進一步降低了開銷。
- 快速啟動和部署:容器啟動速度飛快,因為它并不需要引導完整的操作系統,因此容器成了快速部署、擴展和恢復等場景中的理想選擇。
- 不可變的基礎架構:容器在設計上是不可變(Immutable)的,這意味著容器在構建完成之后就不會再產生任何變化,這種特性簡化了容器的部署、版本控制和回滾流程,同時還有助于確保在不同環境中實現一致的行為。
何時應當考慮使用容器?
容器可以幫助我們維持一致性,同時有助于省略開發過程中的某些暫存和投產環節,例如Verbose調試輸出。開發過程中所發布的代碼將在整個測試和部署周期中保持完整。
容器在資源的使用方面非常高效,并且本身就非常輕巧。雖然上文提到容器類似于虛擬機,但容器一般只有數十MB大小,不像虛擬機那么龐大(往往有數GB大小,雖然也有更小的,但資源浪費情況更嚴重)。容器越輕巧,啟動速度就越快,從而越容易在動態的云計算環境中實現彈性和高性能的橫向擴展。容器在設計上還是不可變的。如果有什么東西需要變更,我們并不需要將變更嵌入到容器中,此時只需要銷毀舊容器,創建新容器就行了。
除此之外,在決定是否將容器作為云原生模型的一部分時,還需要注意下列因素:
- 提高部署的一致性:容器會將應用程序及其依賴項打包在一起,確保在不同環境中運行時產生一致的行為,這還有助于簡化部署過程,降低與配置相關問題所造成的風險。
- 增強可擴展性:容器可通過快速啟動新實例來應對激增的需求,借此幫助應用程序實現快速擴展,同時還可優化資源使用,改善系統整體性能。
- 經濟高效的資源利用率:容器的資源用量遠少于傳統虛擬機,企業可以在相同硬件上運行更多實例,從而節約云基礎設施的成本。
- 為開發和測試周期提速:容器促進了開發、測試和生產環境之間的無縫過渡,簡化了開發過程,加快了新功能和Bug修復的發布速度。
- 簡化應用程序管理:容器編排平臺負責管理容器化應用程序的部署、擴展和維護,可自動實現大部分運維任務,降低IT團隊的負擔。
有關容器的最佳實踐
運行容器的方法有很多,這些方法都是可以互操作的。例如,在從其他公有云平臺遷移時,只需將自己的容器鏡像重新部署到新環境即可,借此即可快速遷移工作負載。此外,我們還可以使用不同的工具和引擎來運行容器。這些方式有著不同的資源利用率和價格點。如果通過Linode(Akamai的云計算服務)進行托管,用戶可以使用Linode Kubernetes Engine(LKE)運行自己的容器,或者也可以通過虛擬機來運行Podman、HashiCorp Nomad、Docker Swarm以及Compose。
這些符合開放標準的工具可以幫助大家快速完成開發和測試工作,并且在使用LKE這樣的服務時,還可以通過簡化管理為用戶帶來更多附加值。Kubernetes會成為用戶的控制平面。用戶可將其視作一個控制臺,通過上面的各種按鈕和旋鈕控制自己的容器,并使用各種基于開放標準的工具。此外,如果決定使用各種特定平臺原生的產品,例如AWS Elastic Container Service (ECS),則需要為不同類型的利用率付費。
容器的另一個重點在于需要理解該用什么來存儲和訪問自己的容器鏡像(這個東西也被稱為容器注冊表)。通常我們會建議使用Harbor。作為一個CNCF項目,Harbor可以幫助我們運行專用的容器注冊表,從而控制相關的安全設置。
請始終記得進行測試,并準備好足夠深入的回歸測試套件,以確保自己的代碼符合最高的性能和安全性要求。容器還應該具備失敗計劃。如果一個容器失敗,此時的重試機制應該是怎樣的?該如何重新啟動?這會產生怎樣的影響?應用程序又該如何恢復?有狀態數據是否持久保留在映射卷或已綁定的掛載卷上?
在云原生開發模型中使用容器時,還需要注意下列最佳實踐:
- 使用輕量級基礎鏡像:從輕量級基礎鏡像(例如Alpine Linux或BusyBox)著手,這有助于減小容器的整體大小并最大限度減小攻擊面。
- 使用容器編排工具:使用容器編排工具(例如Kubernetes、HashiCorp Nomad、Docker Swarm或Apache Mesos)來跨越多臺主機管理和擴展容器。
- 使用容器注冊表:使用容器注冊表(例如Docker Hub、GitHub Packages registry、GitLab Container registry、Harbor等)來存儲和訪問容器鏡像。這有助于跨越多臺主機和計算環境共享和部署容器鏡像。
- 限制容器特權:限制容器所獲的的特權,只為容器提供完成預期目的所必須的特權。盡可能部署無Root容器,從而降低容器遭到破壞被濫用后所造成的風險。
- 實施資源約束:針對CPU和內存等資源設置限制約束,防止容器使用太多資源并影響到系統整體性能。
- 確保容器處于最新狀態:通過最新安全補丁和更新讓容器鏡像始終處于最新狀態,最大限度降低漏洞所造成的風險。
- 充分測試容器:在部署到生產環境前,確保容器能夠按照預期工作且不包含漏洞。使用CI管道在每個階段進行自動化測試,從而減少人為錯誤。
- 為容器實施備份和恢復機制:為容器訪問的持久數據實施備份和恢復策略,以確保在出現故障或災難后,工作負載依然可以快速恢復。
這篇文章的內容感覺還行吧?有沒有想要立即在 Linode 平臺上親自嘗試一下?別忘了,現在注冊可以免費獲得價值 100 美元的使用額度,快點自己動手體驗本文介紹的功能和服務吧↓↓↓
歡迎關注Akamai ,第一時間了解高可用的MySQL/MariaDB參考架構,以及豐富的應用程序示例