MinTalk | 吃一堑长一智的Docker之旅

写在前面：

我已经开始了项目开发工作整整三个月了！连我自己都感到惊讶，时间居然过得这么快！更让我着急的是，我怎么觉得自己还是那么菜！

虽然只有三个月的时间，但我逐渐接触到了各种服务器端开发所使用的工具和技术，这是一件非常有趣的事情。直到现在，我依然会时不时发现，原来为了解决这个问题，有这样一个开源的工具/库，真是神奇！技术栈也是越挖越深，需要完成...

在这段时间里，我使用最多的工具非Docker莫属！特别是慢慢在开始负责做LoadTest，然后服务器压力测试之后，几乎每天都在部署服务，折腾Docker。期间，我当然也踩着坑业务，相关的就不说了，今天想和分享的是，Docker时的一些习惯上的陷阱。好的习惯是大家成功的一大半，少给自己挖坑，生活可以更美好...

01

无法还原的容器

故事

某个天朗气清，惠风和畅的下午，当我终于顺利地把服务启动起来，觉得自己已经解决了遇到的所有问题，我自信满满地删除了目前正在运行的容器之后，重新使用修改后的代码构建了一个新的镜像，作为我的最终版服务启动起来。

然而，这下面就出问题了。在之前的容器中，为了模拟线上的运行环境，我在另一台机器上使用flark搭建了一个简单的后台，只负责一个接口的一种数据返回，其他什么也做不了，但对我来说已经足够了。之后，我修改了正在搭建的服务器代码，让知道应该去最后调用的请求，发给了我的简易服务器，解决了这一步数据无法获取的问题。

然而，当我把新的容器运行起来之后，我的简易服务器就再也收不到任何请求了，请求全部都转发了！所以我百思不得其解过去，各种尝试，都无法恢复这个功能。

直到后来，当我终于搞明白我以为有用的代码修改其实毫无用处时，我才想起来，当时能成功运行，是我在之前因为之前的容器中直接修改了主机文件，硬把对着域名注册的请求，转给了我的简单服务器IP。然而，我却忘了自己有这个小手脚，事后以为自己明白了代码呢！

教训

以前火星就提醒我，用docker要多记工作日记，把家里什么都记录下来，我这时候才明白他说的意思...才docker召之即来挥之即去的任务，同时也导致了它很容易丢失数据。 cker官方的最佳实践中其实也指出了，容器的生命应该是短暂的，随时可以干掉重来才是，那么，如果在容器中做了手脚，自己又没有记录，或者及时同步到代码中，那就难免掉进同一条河里了。

毕竟，坑都是一样的，打开副本，遇到的还是一样的怪事。

02

祸害万代的BaseImage

故事

在某个天朗气清、惠风和畅的下午，我的LoadTest脚本一直卡在同一步。却翻了半天日志，发现是某事ps请求失败了，不过接收请求的服务好好地，我的服务也好好地，就是这个https请求一直失败。

在这个服务的容器里研究来研究去，服务本身好像都没有问题，接收方的容器也被查了个遍，显然也没有问题。

这时候，帮我一起查问题的LT小哥突然问我，你有没有把接收方的CACert证书，加到服务的秘钥仓库里？

我想了想，这一步应该在这个服务的baseimage里就完成了，应该没问题吧？

小哥翻了翻仓库，还真搜不出来。于是我们直接运行了一个baseimage的容器，发现从这一步就没有我们需要的证书了！原来，我以为加到了baseimage里面的功能

教训

Docker的image是一层一层构建出来的，每个image都会有一个baseimage，最基础的image也许是centos的镜像，然而，为了保证每个服务都有一些共同支持的功能，我们会在centos上面，再编译一个baseimage，在里面添加所有服务都需要有的功能，比如必须的CACert证书，数据加密的脚本等等。

不过，baseimage编译出来之后，因为其本身没有实际用途，所以我并没有对它进行验证，这就是我把自己坑得最惨的一点。一旦baseimage有问题，之后用它作为基础的image就全部都有问题了。而且因为问题出在前面一个图像，绕了一圈儿，之后问题藏得了。

及时每个图像编译完成之后，一定要验证它所应该提供的功能，否则层越盖越多，等你发现问题，已经想到很难的问题老早就出现了！

以上就是MinTalk | 吃一堑长一智的Docker之旅的详细内容，更多请关注乐哥常识网其他相关文章！