土豆不好吃

使用docker scale时遇到的一点小问题

今天在使用docker-compose时,突然发现有一个command叫做scale,感觉有点像kubernetes的replica,于是试了一下

-> # docker-compose scale yyets-web=5
WARNING: The scale command is deprecated. Use the up command with the --scale flag instead.
Starting websiterunner_yyets-web_1 ... done
Creating websiterunner_yyets-web_2 ... done
Creating websiterunner_yyets-web_3 ... done
Creating websiterunner_yyets-web_4 ... done
Creating websiterunner_yyets-web_5 ... done

果真是这个样子的,那么从其他容器访问这个container,用的是什么负载均衡算法呢?猜测应该是最简单也是最常见的round robin吧?在nginx里pingcurl试了一下,果真是的,每次解析的IP地址都会变化:

然后看了一下log,发现请求全部落在了1上,而没有平均到其他4个container

但是我如果在nginx里curl,却可以看到请求是均匀分布在5个container里的。

什么鬼嘛,怎么会这样,从外部过来的请求不过是经过了nginx proxy_pass,这和我在nginx container里直接curl有什么差别嘛。

后来吃饭的时候想到,难道是因为,我是后scale的,而nginx是早就启动的,所以nginx启动时把配置文件中的域名解析到了一个固定的IP。而我在container中curl每次都是重新解析的,所以每次解析的结果都是round robin的

于是重启了一下nginx

docker-compose restart nginx

看起来破案了,请求均匀分布到了5个container中。

感谢techmoe指出,其实应该不是固定的,文档说nginx默认的resolver是遵循DNS record的TTL值的,对nginx进程reload应该就可以刷新缓存,让nginx重新解析。

那么问题来了,在单机上scale,是否有必要?

从我个人的角度来讲,意义似乎不太大。我觉得,如果单个容器(进程)存在性能瓶颈,比如说单进程/单线程,只能用一个CPU宿主机有恰巧是多核心,多个进程可以明显提升性能,那么scale一下还是可以的。举个例子,万一我傻了吧唧的这么写的代码:

class ResourceHandler(BaseHandler):
    executor = ThreadPoolExecutor(5)

    @run_on_executor()....

那么scale一下,还是有很大希望的。

不过我当然没这么傻,所以这里scale对我可能用处不太大。

当然了,还是用kubernetes最爽:-)可惜俺并不会也没那么多机器去搞:-(


文章版权归原作者所有丨本站默认采用CC-BY-NC-SA 4.0协议进行授权|
转载必须包含本声明,并以超链接形式注明原作者和本文原始地址:
https://dmesg.app/docker-scale.html
退出移动版