這是筆者這兩天發生的慘痛教訓
從幾天前起，原本每天固定執行的測試任務，突然持續失敗 ……. 由於測試的部分沒有修改，基本上就懷疑是環境問題。
但是做過最基本的檢查後，發覺環境相關的設定也沒有變化，不禁讓人覺得有點詭異了。
回報出來的錯誤是跟 MySQL 有關的，測試的任務則是在 Kubernetes 裡，起一個 Pod ，透過一個測試程序 Conatiner 跟一個 MySQL Container 做測試。為了能夠觀察狀況，筆者試著在自己的本地端開發環境，用 Docker 起了相應版本的 Container ，運行同樣的測試，想試著重現問題。
這時候 ……更神奇的事情就發生了！在本地端完全無法重現這個錯誤，在本地端運行是一切正常的。於是就更仔細地比較了，本地端環境跟 Kubernetes 的環境設定上的差異，也確認過數次，並沒有差異。
「如果測試源碼沒有更動，那除非 MySQL的版本改變，不然不應該有行為差異」可是早已確認數次， MySQL 的版本都指定為 5.7 ；突然筆者靈光一閃，到 Kubernetes 環境的 Docker Engine 中，列出了所有的 MySQL Docker image。赫然發現 …….該環境上的 MySQL 5.7 的 Docker Image ID 跟筆者本地端的 MySQL 5.7 的 Docker Image ID 是不一樣的 …….
換言之，雖然都是 MySQL 5.7 卻不是同一個 Image ……. 在本地端，重新進行 docker pull mysql 5.7 後，就會發覺 docker image 更新到 跟 5.7.26 同樣的版本了
原來是前幾天 MySQL 5.7 發布了新的 Docker Image 5.7.26 ，結果也把 5.7 的 Docker Image更新了 …….
本地端不會出現錯誤，是因為我們通常會直接使用已有的 Docker Image ，而不會每次都 Docker Pull 更新 ……所以會使用舊版的。
結論：不要相信 Docker Image Tag ，要記得注意 Docker Image ID
