wordpress类似网站,国内永久crm不需要下载app,中国企业查询网官网,运营网站要多少费用本文由Markdown语法编辑器编辑完成。
1.背景#xff1a;
我们的产品是通过docker image的方式发布#xff0c;并且编排在docker-compose.yml中发布。在同一个docker-compose.yml中的服务#xff0c;相互之间#xff0c;可以通过对方的服务名和端口#xff0c;来直接访问…本文由Markdown语法编辑器编辑完成。
1.背景
我们的产品是通过docker image的方式发布并且编排在docker-compose.yml中发布。在同一个docker-compose.yml中的服务相互之间可以通过对方的服务名和端口来直接访问而无需知道对方服务的ip地址这样对于接口的url的拼接和识别带来了很大的好处。
然而当我们的产品近期在某一家医院上线后却发现了之前未曾遇到的问题就是同一个docker-compose.yml中的服务使用服务名进行访问时无法访问导致很多依赖接口的功能无法正常使用。
具体的微服务架构大致如下
fluent服务会持续地从/var/lib/docker/containers目录下读取里面的所有容器的docker日志。每一个容器会有一个hashid. 这个日志文件的名称就是以这个服务的hash id命名的。fluent采集到各个容器的json格式的日志后经过一定的筛选将符合要求的日志通过cycle提供的接口通知给cycle服务;
cycle服务, 将日志转化成dict的形式存到mongo db数据库中。每一条记录都会包含患者和检查的一些信息。
当前端需要查看某个患者或某个检查的处理记录时cycle服务从mongo-db中读取出记录并按照时间顺序将它们组成一颗树展示给运维人员。
异常情况发生
这套服务在公司的测试环境和其他医院都可以正常的工作。但是在这家医院前端根据患者ID查询时却无法正常展示。通过查看fluent服务和cycle服务的日志。
cycle服务没有出现异常的日志而fluent服务则一直在刷warn和error的日志。我对照公司的测试环境fluent服务运行时是没有出现这样的warn和error日志的。异常的日志如下图所示
它提示无法连接到cycle服务。因此即使它搜集到了日志信息但无法将日志信息通知给cycle服务。大概的报错日志和原因如下
其中比较关键的错误信息如下
[error] no upstream connection available to xxxx:1000x
[warn] [engine] failed to flush chunk xxx, retry in 7 seconds...
[warn] [net] getaddrinfo(hostxxxx, err12):Timeout while contacting DNS servers
......通过查询引起该问题的可能原因大致的回答如下
from kimi chat:这段错误信息是来自一个网络服务或应用程序的日志通常出现在尝试连接到某个服务或主机时遇到问题。具体来说getaddrinfo(hostxxxx, err12):Timeout while contacting DNS servers 表示在尝试解析主机名 xxxx 时DNS 查询超时了。这通常意味着应用程序无法在预定的时间内从DNS服务器获取到所需的IP地址信息。- getaddrinfo 是一个网络函数用于根据主机名获取其IP地址。
- hostxxxx 表示正在尝试解析的主机名。
- err12 是错误代码通常与超时有关。
- Timeout while contacting DNS servers 明确指出了问题在尝试联系DNS服务器时发生了超时。这种情况可能是由于网络连接问题、DNS服务器不可用或响应过慢等原因造成的。解决这类问题通常需要检查网络连接确认DNS服务器的可用性或者尝试更换DNS服务器。分析后大概原因是容器间通过服务名访问时docker在底层会做一个DNS的解析也就是将服务的名称解析出服务的真实ip. 因为在docker-compose.yml中每一个服务都一定会被分配一个ip. 网络请求最终其实还是通过ip:port/interface_url来完成的。
那么在确认了其他没有问题的情况下归结的原因大概是DNS解析过慢造成无法及时解析出IP导致连接超时了。
既然是因为DNS解析的速度那么我们就希望能够绕过这个DNS的解析环节。那要跳过DNS解析只有事先知道对方服务的ip和端口才可以。
因此解决问题的思路和方案大致如下 1 为cycle服务在docker-compose中指定一个固定ip地址 2 fluent服务请求cycle服务时按照cycle那里固定的ip进行访问不再通过服务名访问了。
2.问题解决
找到解决方案后接下来便是在docker-compose.yml里面给相应的docker容器赋予特定的ip了。 也就是给cycle服务一个特定的服务ip, 比如8.8.6.140; 而fluent服务在请求cycle的接口时直接通过ip:port的方式请求这样就绕过了DNS解析这步。
2.1 在docker-compose.yml中为服务设置固定ip
通过在devv.ai上面咨询如何给docker-compose.yml中的服务设置固定ip, 得到了回复。
结合以上的回答我将服务的ip设置好后重新启动服务。结果服务一直处于无法启动的状态。 要不容器的状态是Create, 要不就是Restarting …, 总之就是无法正常的工作。
连续试了好几次都无法成功。
2.2 设置固定ip后服务启动失败
正当愁眉不展时咨询了研发部经理。他也感觉到很奇怪因为修改容器的ip, 并不是什么大不了的事设置固定ip导致容器无法启动匪夷所思。
但是 在启动时docker是有一个提示的它提示Alreay in use.
后来我看经理把ip地址的最后一位设置得大了一些比如之前我设置得是140。他先是修改成180, 结果还是提示Already in use. 然后又设置成222, 这次再启动就不提示可以正常启动了。
3. 复盘
复盘一下原来是由于我们的docker-compose.yml中的服务非常多。在docker-compose up -d的时候docker会给里面的每个服务分配一个ip地址。而我提前设置好的ip地址被docker自动提前分配给了其他服务。因此当docker再启动我指定ip的服务时发现这个ip, 已经被占用了导致这个服务一直无法正常启动。
其实我觉得docker可以有一个机制就是先检测一下当前的docker-compose.yml中有没有已经被提前设置过ip的服务。如果有设置了ip地址的那么这个ip地址就要预留给这个服务而不要再分配给其他的未分配ip地址的服务。 这样可以有效地避免这个问题的发生。
希望以后高版本的docker, 可以优化这个机制。
