写在前面:
我已经开始后端开发工作整整三个月了！连我自己都感到惊讶，时间竟然过得如此之快！更让我着急的是，我怎么觉得自己还是那么菜！
尽管只有三个月的时间，但我逐渐接触到了各种服务器端开发所使用的工具和技术，这是一件非常有趣的事情。直到现在，我依然会时不时发现，原来为了解决这个问题，有这样一个开源的工具/库，真是神奇！技术栈也是越挖越深，需要慢慢填补...
在这段时间里，我使用最多的工具非Docker莫属！特别是在开始负责做LoadTest，也就是服务器压力测试之后，几乎每天都在部署服务，折腾Docker。期间，我当然也踩了不少坑，业务相关的就不说了，今天想和大家分享的是，使用Docker时的一些习惯上的陷阱。好的习惯是成功的一大半，少给自己挖坑，生活可以更美好...
01
无法还原的Container
故事
某个天朗气清，惠风和畅的下午，当我终于顺利地把服务启动起来，觉得自己已经解决了之前遇到的所有问题之后，我自信满满地删除了目前正在运行的container，重新使用修改后的代码构建了一个新的image，作为我的最终版服务启动起来。
然而，这下就出问题了。在之前的container中，为了模拟线上的运行环境，我在另一台机器上使用flark搭建了一个简易后台，只负责一个接口的一种数据返回，其他什么也不能做，但这对我来说已经足够了。之后，我修改了正在搭建的服务器代码，让原本应该去远端调用的请求，发给了我的简易服务器，解决了这一步数据无法获取的问题。
然而，当我把新的container运行起来之后，我的简易服务器再也收不到任何请求了，请求全都没转发过去！于是我百思不得其解，各种尝试修改，都无法恢复这个功能。
直到后来，当我终于搞明白我以为有用的代码修改其实毫无用处时，我才想起来，之所以之前能成功运行，是因为我在之前的container中直接修改了host文件，硬把对远端域名的请求，转给了我的简易服务器IP。然而之后，我却忘了自己做过这个小手脚，还以为自己理解了代码呢！
教训
以前Mars就提醒过我，使用docker要多记工作日记，把做过什么都记录下来，我这次才明白他说的意思...docker召之即来挥之即去的轻巧，同时也导致了它很容易丢失数据。在Docker官方的最佳实践中其实也指出了，container的生命应该是短暂的，随时可以干掉重来才是，那么，如果在container中做了手脚，自己又没有记录，或者及时同步到代码中，那就难免掉进同一条河里了。
毕竟，坑都是一样的，打开副本，遇见的还是一样的怪。
02
祸害万代的BaseImage
故事
在某个天朗气清，惠风和畅的下午，我的LoadTest脚本却一直卡在同一步。翻了半天日志，发现是某个https请求失败了，然而接收请求的服务好好地，我的服务也好好地，就是这个https请求一直失败。
在这个服务的container里研究来研究去，服务本身好像都没什么问题，接收方的container也被查了个遍，貌似也没问题。这时，帮我一起查问题的LT小哥，突然问我，你有没有把接收方的CACert证书，加到服务的秘钥仓库里？
我想了想，这步应该在这个服务的baseimage里就做了，应该没问题吧？
小哥翻了翻仓库，还真搜不出来。于是我们直接运行了一个baseimage的container，发现从这一步就没有我们需要的证书！原来，我以为加到了baseimage里面的功能，根本就是无效的。
教训
Docker的image是一层一层构建出来的，每个image都会有一个baseimage，最基础的image也许是centos的镜像，然而，为了保证每个服务都有一些共同支持的功能，我们会在centos镜像之上，再编译一个baseimage，在里面添加所有服务都需要有的功能，比如必须的CACert证书，数据采集的脚本等等。
然而，baseimage编译出来之后，因为其本身没有实际用途，所以我并没有对它进行验证，这就是我把自己坑得最惨的一点。一旦baseimage有问题，之后使用它作为基础的image就全都有问题。而且因为问题出在前一个image，绕了一圈儿之后，问题藏得更深了。
每个image编译完之后，务必及时验证它所应当提供的功能，否则layer越盖越多，等你发现问题，已经很难想到问题老早就出现了！
