本周，在生产遇到一个非常诡异的问题，因整体排查过程时间较长(前后用了三个小时左右)，特进行记录和分享。
问题大概是这样，本周五10点半左右，产线在群里反馈灾备无法发布。
接到问题后，口头咨询了产线版本构建的时间是什么时候，产线反馈为前一天晚上，因目前的版本设定在第二天00:04这个时间点同步到灾备的镜像中心，所以接到问题后，立马排除了“产线版本为当天构建，没到版本同步的时间”的原因。
所以，就立马登陆到镜像中心去查看版本同步记录。
一看发现，确实版本在前一天未成功同步版本到灾备中心。
没办法，只能去看报错。但镜像中心也很诡异，竟然没有保留同步失败记录的详细日志(后来到社区查看，应该是开源产品的bug，同时，还发现了产品本身其他一些bug。orz…….)。
这就头疼了！
虽然不影响生产业务的运转，但说明容器云灾备的整个方案中，是有没考虑到的点，不禁让我陷入质疑技术人生的沉思……
还是不要多想，先动手排查起来。
其实主中心同步版本到灾备，无非就是个介质包推送的过程，而且本身基于的是docker的机制，所以从大的方案上来看，应该没什么问题。
所以，第一个想到的，是不是主中心到灾备的网络端口封闭了。立马telnet去查看，发现一切正常。
那是不是推送镜像介质有问题呢？
我立马手动用脚本push了一把，发现，确实没法push，返回的状态码是401以及x509 ipsans不存在，也就意味着主到灾备的ssl认证未通过。但事实上，因目前主备中心共用一个域名(配置同个域名，目前流量到不了灾备，所以配的是ip模式)，但是主到备我设置的是insecure ip模式，并不需要认证。
这就奇怪了！
第一，按照我司的ssl证书，也要到明年2月份左右才会过期进行更换，所以不可能这么快。虽然笃定这么觉得，但还是去灾备核实了镜像中心部署用的ssl证书，做了下ssl的检测，确实没有过期，而且用的证书本身就是从主中心V2V同步过来的；
第二，我未设置secure模式，为什么现在需要去认证呢？
思来想去，会不会因为docker认证出了问题。
首先，我先在灾备环境本地进行了镜像push，没什么问题，可以确定，ssl证书和认证是没问题的，那就是跨中心有问题。
先补充个小技术点：docker在做镜像认证的时候，为了安全性，会进行auth认证，如果认证成功，会在相关的配置文件中去写下auth的口令，以后可正常进行认证。这个口令他会以{ip/域名：{auth:“xxx”}}的形式进行保存。
我立马去翻看了文件，发现确实没有灾备ip的口令信息。
终于离真相接近了一步。因考虑到是生产，只能中午乘着午休的空隙时间去进行修复。期间，电话了厂商的技术专家，描述了问题，厂商中午也开始介入进行排查。
中午吃完饭，我立马开始进行修复，首先，更强制性地把灾备的ip在docker中设置成insecure模式(之前设置走的是镜像中心的配置)；第二，把灾备的认证口令，在主镜像中心的docker配置中进行强制纳入。
开始进行重启……….
糟糕！还是不行！确实有一种把键盘敲碎的冲动！
我和厂商做了下沟通，厂商查了很多方案，也表示无解，说确实没遇到过这个问题。
好吧，那咱们再用最后一个绝招，重启！虽然，我已经预判了这个结果肯定不行，但还是像“抓住最后一根救命稻草一样”，试试看吧。
果然不行！哈哈哈哈。
我和厂商确实都emo了…….甚至心里怀疑是不是网络发包篡改了什么。当然，我还是比较坚信我的网络知识的储备比较完善，所以打消了这个念头。
因不影响生产运行，下午上班后，就让厂商技术专家继续去内部沟通问题。我这边因有其他更紧急事情处理，就忙去了。
后来大概下午16点左右，我突然想到，灾备这边一直不让过认证，是不是灾备的镜像中心有什么问题，但中午我也在灾备中心去进行了灾备镜像的认证，也没什么问题。好像就跨中心有问题。
那到底还会因为什么呢？
没办法，因为镜像中心是开源的，只能去社区看镜像中心的源码，看能找到什么线索。
看源码，那肯定就是从源码的初始化开始着手。
突然，我发现一个小点，就是镜像中心在启动的时候首先会去获取一个cfg的配置，cfg中有一段配置，长的样子为[hostname:””]，这个配置后来证实应该与ssl证书的secure模式有关联。也就是说，要么你主机的hostname做硬性配置，它进行加载；要么你自行在配置文件中进行配置。我翻看了下灾备的cfg的配置，发现配置的就是[hostname:”镜像中心名称.xxx.com.cn”]，第一念头就是：那应该没问题啊。
再一想，不对！目前主到灾备因为配置域名流量无法到灾备，所以用的是ip的模式。那么假如去做push的时候，但对方走的是域名+证书的形式，而我走的ip的形式，导致认证没过？
基于这个猜想，我把cfg中的hostname配置改为hostname:ip的形式，然后重启。
手动进行了触发，发现可以正常同步了！
经过这两天夜里的同步观测，发现基本同步正常。
虽然，同步正常了，而且也检查了这期间的所有服务器、介质、镜像中心的运行态，都没发生重启或者其他变更，但还是有两个谜团没解开：
1、在发现问题之前，所有的镜像都正常进行了同步，否则这个方案上不了生产，但为什么又突然无法同步呢？
2、我当时明显走的是insecure模式，是跳过认证的，为什么又需要突然认证？
这两个谜团只能留待进一步去深入发现组件运行机制了。
从这个问题，有一些点还是值得后期改善：
1、不管是开源产品还是成熟产品，总归是软硬件以及人写的，人写的，就会有bug，所以在日常开发运维这些产品的时候，除了该掌握的产品业务本身外，尽量能够对产品的运行机制、技术背景等做详细了解，从而在遇到问题能够去兜底；
2、不管是开源产品还是成熟产品，一定要去尽量部署配置化与标准化，特别是对于产品产品介质的版本情况、配置情况等做好标准化，这是减少技术债的一个重要途径；
3、任何一家厂商都不是万能的，也不会时刻帮着你解决问题，更不可能解决所有的技术问题，有些时候遇到一些问题，尽量能够主动出击，逐步积累；
4、云原生技术在给企业带来便利的同时，对于云原生本身的技术是一个硬骨头，而从目前行业来看，云原生的应用基本是趋势，技术研究，有一定必要；
5、同一份介质或者软件，完整复制到另外一台进行部署运行，一定要做好技术考量是否能保证运行，因为会涉及到很多配置细节
(完)
—————–EOF——————