写在前面:
开始后端开发工作已经3个月了！连我自己都好惊讶，时间居然过得这么快！关键，我怎么觉得自己还是那么菜！着急ing
不过，虽然只有三个月时间，但渐渐开始接触各种服务器端开发所使用的工具和技术，也是一件很有意思的事情。直到现在，我依然会时不时发现，原来为了解决这个问题，有这样一个开源的工具/库，好神奇~技术栈也是越挖越深，有待慢慢填补...
这其中目前用的最多的，当属Docker了！特别是开始负责做LoadTest，也就是服务器压力测试这块之后，几乎每天都在部署服务，折腾Docker。期间，也少不了踩了各种坑，业务相关的坑就不谈了，今天想和大家分享的，算是使用Docker的习惯上的坑吧。好的习惯是成功的一大半半，少给自己挖坑，生活可以更美好...
01
无法还原的Container
故事
某个天朗气清，惠风和畅的下午，当我终于顺利的把服务起起来，觉得自己已经刚清楚了之前遇到的所有问题之后，我自信满满地删掉了目前正在运行的container，重新使用修改之后的代码build了一个新的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越盖越多，等你发现问题，已经很难想到问题老早就出现了！
以上，就是我目前感觉最需要注意的俩问题，也是我花了最长时间爬出来的坑...别小看细节，到头来最费时间的，往往都是些细枝末节的小事儿。前端的UI问题显而易见，而后端的服务器问题，牵扯的原因千千万万，一个不注意给自己埋的坑，要花成倍的时间去解决，得不偿失。
路漫漫其修远兮，学习的路还贼长，共勉~
Schönes Wochenende!
我的2019周更计划已完成：37/52
[********............]
