介紹完了，helm value 間的上下層關係，今天來跟大家分享，我實際規劃團隊所使用的 helm 結構。不過會因為一些商業機密問題，內容會有所轉換，但會盡量呈現相近概念讓大家了解。

這邊先看一個示意圖

demo code

大家可以看到上圖，我切成兩個主要 charts ，分別為 backend & plugin ，然後 backend 下面分別有兩個 sub charts為 cart & user 。 這兩個 sub charts，又各自會需要 redis ， 所以又分別它們各有一個 sub charts。

這裡假設的情況 backend 下面的 cart & user 會需要連線共同的 mysql。那我們不可能分別在 cart & user 的 value.yaml 各別去設定 mysql 的位置。所以我在 backend 這層的 values.yaml 就會設定這樣

global:
  mysql:
    host: 127.0.0.1:3306
    user: root
    password: test4321

運用到昨天所講的 global keyword。這樣我就能往下設定兩個服務，如果需要像前幾天講的 k8s namespace 介紹，需要拆成不同站台，那我就會依照不同站台設定不同 values.yaml，如下

這時如果我需要在 QA 站做部署我只需要

$ helm install backend ./backend  -f ./backend/qa-values.yaml

要在 PROD 站做部署

$ helm install backend ./backend  -f ./backend/prod-values.yaml

這樣就很容易做到不同站別，快速部署。

裡面如果看到 image 都是拉 nginx ，是正常的，這裡純粹就是用 helm create 指令，跟小調整 deployment ，實際上並無法真實使用，純展示。

總結

導入 helm 的契機是在於，當微服務架構下，服務越拆越多，每個服務都有自己的 deployment，甚至服務之間都有相依問題，這方面的管理相當擾人。再加上我們團隊，剛開始使用 k8s 初期，常常會有人手殘把上面的服務全部刪掉，這時侯重建非常的困難....，只要一有人下錯指令，大家就要花很多時間在重建服務上面，嚴重 delay 開發進度。

有了 helm 協助下，我們不管何時何地，只要是 k8s ，我們可以在任何地方，把我們的服務『迅速』重建起來。而且所有的部署檔案，可以在很有架構的管理，再搭配 git 策略，可以說是非常強大的工具，強烈推薦有在使用 k8s 的人，一定都要了解一下 helm 這套工具。