背景：我们使用docker部署环境，代码发布后会更新到机器上。然后运行脚本却发现旧代码的报错信息，Are you kidding me？？
以下是我真实的排查问题过程。
第一步：我怀疑运行的代码不是最新的。
a、登录机器检查目录下的代码，却发现不存在进程对应的目录。
系统是他人部署的，我没用过docker，只能边学习边排查。然后发现代码是通过本地目录挂载到docker里的，所以本地没有此目录，挂载的源目录存在，且确认已更新。
b、我怀疑是挂载出了问题，导致新代码未挂载成功，运行的仍然是旧代码
我百度了如何查看docker中的代码，准确地说是如何进入运行中的docker，发现docker attach [container] 可以做到。经检查，docker中挂载的目录也已经是最新的了。
第二步：我怀疑新代码发布后，进程未重启导致以上问题。
经排查发现代码发布后，机器上的进程确实已经重启。
第三步：因为2个月前我们刚换了机器，所以此时我怀疑是同事切换机器有问题，也就是当前使用的仍然是旧的机器
此时我激动的以为就要看到奇迹了，我在旧机器上reroll了一次代码，然后重新执行脚本，此时却发现问题依然没有解决。这里有个问题我发现了reroll的代码不是最新的，最后一次commit时间是2月1号，但我想这个版本的代码应该也是没问题的。
第四步：代码已经更新，进程也已经重启，此时我不得不整理一下我们系统如何搭建部署的，从中思考问题可能的原因。
代码挂载到docker中，在docker中启动我们的服务，然后问题来了，机器上的服务跟我们访问的域名是如何匹配的？
a、以为是huskar里面配置的域名和对应机器关系，经确认不是的。huskar中配置的是机器和app_id的对应关系。
b、以为是前端负责的域名跳转，经确认是运维负责这类配置。Nginx是帮助服务实现负载均衡的，运维通过nginx配置域名和机器的对应关系。
c、我们的是测试服务，也只是测试环境，没有经过运维。此时我去检查我访问的域名：
“http://consumer-1.vm.net:8080/”
很显然我访问的就是consumer-1.vm.net这个机器，并没有使用nginx配置。此时仔细看这台机器就找到问题了， 因为这明明是那台旧机器，我换用新机器同样的方式打开链接，发现新页面，经确认这里的脚本执行结果都是最新的，此时问题已确认，我就是个笑话。。。
d、接下来的问题是，就算我看的旧机器上运行的结果，可是第三步我reroll过旧机器的代码，那结果也应该更新了的，所以还需要再确认2月1号的代码版本。
用米叔电影里那句话结尾，加油。
“如果醒来不是为了实现梦想，那睡和醒有什么区别？生和死有什么区别？”
