這是筆者這兩天發生的慘痛教訓
從幾天前起,原本每天固定執行的測試任務,突然持續失敗 ……. 由於測試的部分沒有修改,基本上就懷疑是環境問題。
但是做過最基本的檢查後,發覺環境相關的設定也沒有變化,不禁讓人覺得有點詭異了。
回報出來的錯誤是跟 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