Kubernetes Tips系列 - 合理設計你的鏡像名稱及tag

開源項目推薦

Pepper Metrics是我與同事開發的一個開源工具(github.com/zrbcool/pep…)，其經過收集jedis/mybatis/httpservlet/dubbo/motan的運行性能統計，並暴露成prometheus等主流時序數據庫兼容數據，經過grafana展現趨勢。其插件化的架構也很是方便使用者擴展並集成其餘開源組件。
請你們給個star，同時歡迎你們成爲開發者提交PR一塊兒完善項目。

前言

容器化給咱們帶來不少好處，好比鏡像交付的不可變性，交付物的標準化，使得CICD的能力可以進一步提高。合理的設計好鏡像名稱更加可以在管理鏡像及出問題的時候事半功倍。

一個栗子

咱們使用阿里雲的容器鏡像服務託管鏡像，鏡像的名字是這樣的格式：registry.cn-qingdao.aliyuncs.com/[namespace]/[imageName]:[buildNumber]-[gitCommitHash]

registry.cn-qingdao.aliyuncs.com

這部分是描述鏡像倉庫，沒什麼可說的

imageName

鏡像的名字，以咱們的經驗是{appName}-{category}-{env}，appName跟category還好理解，一個是應用名字，一個是分類，例如是frontend的http服務仍是backend的rpc服務，見名知意，那這個env是什麼呢？說好的鏡像不可變呢，爲啥又跟環境扯上了關係。
這個就要說下咱們的開發流程了，按照標準最簡單的CICD流程

全部的開發人員從master分支checkout獨立的featureBranch，在各自的featureBranch上進行開發 開完畢後merge到master分支進行構建鏡像測試，而後預發，而後發佈到線上

可是現實老是殘酷的，咱們做爲一個創業公司，不可避免的要提升開發效率，多個版本並行，跨迭代測試，功能先測後上是常有的事，那麼這個如何解決呢？ 通過咱們的討論，咱們這樣設計的，開發人員在各自的featureBranch上進行開發，開發完畢在DEV環境自測，測試完畢後merge到Test分支，測試環境用Test分支進行測試。
可是發佈的時候就有所不一樣，發佈的話是用master分支進行發佈須要上線的功能merge到master分支進行發佈，因此測試同窗測試的分支未必是發佈的分支，這樣是否會有問題？實際上是有問題的，可是在效率面前，咱們承擔了風險，爲了使風險最低，鏡像不會直接上線，而是走預發流程在staging進行基本的驗證，重要服務可能還會導入小量的流量驗證，真正上線的時候，還有金絲雀發佈來進一步保證。咱們用master構建出的鏡像爲了與測試分支區分，就標註了prod字樣，意思是線上鏡像。這樣就解釋了爲何鏡像名字當中含有環境的信息。

buildNumber

這個是咱們jenkins系統此次構建的構建號，經過構建號可以找到構建日誌信息

gitCommitHash

這個是git的短hash，在git當中能夠經過這個hash值找到提交點的各類詳細信息，甚至提交點被合併到了哪些分支等等的信息，咱們能夠經過提交點來回退版本，更精準。