iT邦幫忙

2017 iT 邦幫忙鐵人賽
DAY 9
0
DevOps

Container 容器三十問系列 第 9

哪些角色(可能?)比較不會受容器影響?

答案就是昨天留下的基礎設施管理員DBA,但也只是可能而已。

先講基礎設施管理員,網路、硬體負載平衡器、Hypervisor、認證授權伺服器、DNS這些都是容器所仰賴的基礎設施,因為這些基礎設施是在容器層之下,所以理論上是不會受容器影響的。

但是呢?為了要更好的運用容器,若能在基礎設施層能提供更動態的供裝及設定方式,會有利於容器的動態供裝。畢竟容器還是要倚賴這些基礎設施,容器的調整(如:搬遷)可能需要搭配基礎設施的調整,來滿足組織的資訊規範。

比方說,容器平台一般都會建議搭配軟體定義網路(SDN)來讓容器搬遷時仍能有固定的IP位址。SDN也用來提供網路隔離功能,在多租戶共用時來滿足組織對資訊安全的要求。

如果原本的基礎設施就是架構在 AWS, Azure 等成熟的公雲上,會比較能夠和容器平台整合,基礎設施管理員也比較不需要學習新的知識。但如果原本的基礎設施是自建的,就會需要不少的 workaround,尤其是這些基礎設施還分屬多個不同機構管轄的時候...

再來講DBA,DB有幾個特點會削弱容器化帶來的效益,所以有時候並不是容器化的首選。

  • 多數的RDB,若需要有Master-slave或是cluster架構,在現階段都還不適合容器化。
  • 若DB的行程和資料不能動態綁定(Ex:若一個DB行程掛掉時可以自動啟另一個DB行程綁相同的資料),也不適合容器化。
  • 若DB的效能瓶頸是在I/O且沒有內建的scale out能力,容器化可能會降低效能。

但DB容器化也不是沒有好處的,如果在開發環境中需要搭配一個single instance的DB來測試,容器化的DB還是很好用的,可以輕易的重建。現階段容器化DB是用來作為一個可拋棄式的DB,在開發測試階段都有幫助,只是可能不適合規模較大或可用性要求較高的生產環境。

所以DBA還是應該懂些容器知識,甚至可以跟Middleware/Tool/Library管理員一樣,要會做些DB容器的環境樣板。

以上說明。

不過我們似乎還漏了一個地方。我們需要一個容器平台,這個容器平台該由哪個角色來管理呢?


上一篇
容器對於開發流程中各個角色的要求?
下一篇
[小結] 組織需要導入容器嗎?
系列文
Container 容器三十問30

尚未有邦友留言

立即登入留言