iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 4
2
DevOps

就是「懶」才更需要重視DevOps系列 第 4

Day4 該如何規劃虛擬世界的架構

經過一晚我猜可能已經有人想到昨天提的架構中,解決了哪些問題又有哪些問題沒有被解決,但是還是要長話一下,說說昨天架構的問題點在哪裡。

  • 已解決:

    • 升版容易,環境單純:
      將服務容器化後,我們不必在擔心服務是要跑在 Window、Linux(Ubuntu)、Linux(RedHat)...等不同作業系統,因為 Docker 服務就是提倡在任何環境快速佈署,讓開發人員不必在擔心作業系統、Kernel、環境等問題。版本升級方面也很容易,只需要更該「映像檔(image)」版本,即可完成版本升級。

    • 服務佈署超快速:
      假設有新進同事剛到公司報到,只需要將撰寫好的docker-compose.yml檔案提供給新同事,加上幾行指令,即可將開發中的專案跑起來,還不用擔心有任何環境問題。

    • 管理方便:
      因為每個環境的 image 跟 docker-compose.yml 佈署方式都相同(可能只會差異在環境變數),不再出現「虛擬機」安裝過程中因不同人員建制造成的差異問題,服務也已經透過虛擬機分隔開,所以在管理上更加單純簡易。

  • 尚未解決:

    • 浪費機器資源:
      因服務主要還是透過「虛擬機」進行劃分,所以還是必須要有多台「虛擬機」,因此就算在「虛擬機」上執行 container 服務,也只是縮短佈署服務的時間而已,並未真的解決資器資源問題,而解決這問題的方式,在下面的文章中,會在透過 K8S 架構的介紹,解決該問題。

    • 高成本:
      與上述相同的問題,服務主要還是透過「虛擬機」進行劃分,相對的還是得購買足夠的「實體機」數量,避免「虛擬機」數量過多,互搶「實體機」資源。


隨著 container 數量越來越多,漸漸會會感覺到難以控管,就像大量的「虛擬機」問題一樣,此刻你可能會開始尋找工具管理龐大數量的 container。(ex: docker swarm、K8S、K3S...)

可能會開始考慮使用雲端Server,例如: Google 推出的 GCP 或者 Amazon 的 AWS 雲端服務,因為這些雲端機器都已經有提供內建的 K8S 環境,讓用戶不用在為了架設 K8S 環境煩惱。

萬一團隊最後的決策是不希望將服務放置雲端機房,那有可能就衍生以下架構圖:

  • 明天會在說明該架構內容,讀者可以在思考一下還有哪些更好的架構,歡迎提出來分享。
  • 另外明天也會說明為什麼機器不再是「虛擬機」,而是直接使用「實體機」代替。

上一篇
Day3 又愛又恨的「虛擬機」
下一篇
Day5 K8S架構 & Docker 快速建立環境示範
系列文
就是「懶」才更需要重視DevOps30

1 則留言

0
alincode
iT邦新手 2 級 ‧ 2019-09-26 15:32:28

反腦 -> 煩惱

我要留言

立即登入留言