about container

[jasonjoo2010]

does the container function use AWS service?

it's better making more comments in containerize.py, thanks

[CMGS]

呀~这个是因为我们自己有一套调度系统。。。不过这一块似乎可以改成通用的

[jasonjoo2010]

我们也在研究docker, 也看到了projectEru, 正好取取经 另外我看Eru最近没什么更新了, 是比较稳定还是不开源了？

[zheplusplus]

要定制此功能, 参考 这里

[CMGS]

一代目很稳定了，然后基于CPU的分配策略有点小问题，不过不影响，目前新公司的业务基本都是这套驱动的。我们现在开发了 ERU2...在新公司这边刚上线不久，明年会继续开源吧。

[jasonjoo2010]

另外请教, eru-lb是如何处理443的？包括SNI多证书配置, 我们恰好也用的是tengine

[CMGS]

@jasonjoo2010 https 交由上一层 ULB 火车 LVS 做，ULB 就是 UCloud 自己的 LVS 啦，对内都是 http。其实对于 eru-lb 而言，443或者80只是 server 段本身的配置而已，除非说你一个域名需要不同的证书

[jasonjoo2010]

@CMGS 对的 实际的应用场景一般均采用SNI, 多域名对应不同的证书, 这个我查查资料看在server段能不能动态设置ssl_certificate, 增加此项支持.

云服务我们用阿里用伤了, 主机方面正在回归基建, lvs的fullnat也尝试过, 现在感觉必要性不是特别大了, 做好keepalive和前端分组的tengine集群基本可以替代.

目前lb项目还接受pr吗？封等Eru2的话我就在内网开分支了～

[CMGS]

@jasonjoo2010 恩，如果自建的话采用 VIP 方式其实完全够了的，我们现在也在回归自建机房，不过线上的还是在 UCloud 上。接受 PR，要不要试试我们给 eru2 搭配的更强力的 eru-lb3，支持多级过滤的那个版本？

[jasonjoo2010]

@CMGS eru2没看到项目, 不在projecteru路径下吧？

[CMGS]

@jasonjoo2010 没有，暂时我们还没放出来，晚点我要同事把 erulb3 放到 github 来再 notify 你

[jasonjoo2010]

@CMGS thanks.

另外这个不版本会影响与eru-core(eru_v1)类似系统的集成吗？刚调到lb模块正好是需要的准备demo看看

[CMGS]

@jasonjoo2010 并不影响。。lb 都是独立的模块，我们是在上层 UI 控制界面去做的整合

[jasonjoo2010]

@CMGS fine. 就是说api差不多咯 我们实际的需求是, lb分组支持, 和ssl支持, 这两方面预计顺利的话会做进一步的工作.

分组实际上是类似阿里的slb, 网站配置限定在lb组内部生效, 有安全方面的考虑也有资源隔离方面的考虑; ssl支持不用说了, 因为前面不像云一样有官方的443前端, 当然模式也是一般前443后80.

自从更了ubuntu16后常用的输入法就没全角标点了, 见谅

[CMGS]

@jasonjoo2010 恩啊，分组这个我们也做了。。。一组 ELB 一组配置

[jasonjoo2010]

@CMGS good job 那估计目前就加个ssl了

[jasonjoo2010]

@CMGS 另外顺带提一下, 关于waf以及流控相关的功能, 是集成在lb内还是另外的模块？ 这方面的功能我们也正在考虑添加, 另外流控方面貌似lua难以动态配合req_limit, 只能自己重新实现了

[CMGS]

@jasonjoo2010 WAF我们用的第三方，集成 LB 成本太高了，而且效率不一定比第三方好（就目前来看）。流控方面动态的 req_limit 基本可以不用考虑了，我们之前也有这种需求，但是尝试了现在已经有的基本都有缺陷，现在我们线上的是用另外一层专门做流控的 nginx 集群在前面解决的。但是未来来说，我们有个新的流控模块会整合进 erulb3。不过现在都在等 opm，所以也就丢在那边只跑了线下测试了。

另外我看了下你给 corvus 发的 PR，本来还想我们这边出人去搞 set remote 这个命令的，看来可以省了呀哈哈。对了参数命令行化你会不会做，我们这边容器化倒是很依赖命令行参数覆盖配置的行为。

最后这是 https://github.com/ZhangYet/erulb3 我们现在用的第三代 erulb，你可以先看看哦

[jasonjoo2010]

我们正好相反, 是抛弃了第三方的waf, 一是不开源（商业服务）, 二是配置间接, 响应断层, 三是因为不透明所以出过数次低级运维问题, 远不如自己保险靠谱.

就实现上研究后发现也是用nginx扩展实现的waf检测, 其实规则集比较简单, 目前我也是在看lua_waf, 准备集成进lb内顺便实现动态配置下发的问题, 性能方面的话, 感觉对于单独的前端来讲, 似乎没那么难以实现, 这个有待实际测试, 流控方面目前也有不少lua上的实现, 如果包含了waf功能, 流控成本其实相对来讲就没那么明显了.

对于多层, 包括淘宝的演进思路, 都是压扁, 响应链尽可能短, 毕竟多一层就多一点调试难度多一点不可靠系数多一点响应时间, 所以也在从fullnat向纯中间件VIPServer（据说这个有paper还有标题但我全网都没找到不知道是不是发到了阿里学术去了呵呵）演进, 所以综合起来考虑合并多层的角度值得一试.

容器这边刚踩了个预计中的坑, CentOS上mapper很容易busy的问题, 这个也在考虑使用Overlay替代, 参数是容器的传参吗？这个是可以直接写entrypoint来搞的吧?

https://github.com/tonicbupt/core 这个是与之配合的新版core吗？老版的core向redis写的参数应该不匹配？

[CMGS]

@jasonjoo2010 恩，我们暂时受限于 UCloud 的环境因素只能这么做，包括只能使用 ULB 接入流量，ULB 又有「可伪造」 XFF 等一些奇奇怪怪不可控的因素，所以就形成了 (WAF可选)->ULB->nginx 限流->elb 的结构。未来的话设计上会采用 （gateway + keepalive）-> elb 两级结构，WAF/逻辑限流这块做到 gateway 里面去，ELB 做业务无关的多级分流策略，如同刚给你那个项目地址所写一样。

性能上我觉得对于 openresty 而言不必太看重，其实都很快了。你像我们 erulb3 用 sharddict（垮 worker 锁）做关键性的配置和锁，一套下来也就在 8%~17%左右的性能损失，裸 nginx proxy 平均性能损失也有10%左右，所以我觉得还能接受。另外我们这边受限的一点是人力问题，大规模启用 WAF 的话规则类的东西暂时没人能接这个盘，所以有攻击的时候我们基本都是往大禹挂，通过 CNAME 切换。

CentOS 上你用 dm 么，那是一定会 busy 的，轻则 daemon 失去响应，重则 container 和 image 全丢，而且我猜你的底层文件系统是 xfs？ext4 的话会好一点点，好不太多。而且据我们和豆瓣平台组使用状况对比来看，内核小版本的变化表现出来的问题频率和状况都会不太一样。Overlay 的话性能确实好，我们之前有过测试，但是不太敢用，原因是对内核的可控性上对于我们这种小团队来说需要消耗的精力太多了，之前在芒果TV线上测试过一次，关是更新内核就特别惊悚。所以我们现在 C2 新机房的建设上使用了 LVM，目前来看暂时还是没问题的。

参数是指让 corvus 支持通过 command 的 arg 覆盖其配置参数啦，因为他们现在和 cerberus 不同的在于配置是静态化的，包括 thread 和 remote nodes。在 cerberus 中，后者是通过 set remote 命令进行动态覆盖和更新，前者是通过 cerberus -t 的命令行参数进行覆盖，使得容器化后可以在上线之后再决定线程数，而非是后者那样读取固定配置文件中的线程数。

恩，这个是新 core，我们把核心的编排和调度拿了出来，用 grpc 包装了一层。对外的 UI 层和与 App 耦合的部分则抽出来做了另外一个「App」citadel，一来可以自己部署自己，二来也解耦了 core 和 App。另外这个 core 里面实现了2套分配器，精确和超售。在目前线上使用中我们用的版本是用超售的 CPU 分配搭配精确的 MEM 分配，主要也是为了成本控制。

[jasonjoo2010]

python这几天折腾的不少库在对应系统的新套件的时候已经百坑不侵了, 不知道go会不会好些, 不过go的rpm封包一直较纠结, 这个我看一下新版的core是不是搞起来会容易些.

overlay的话, 我们目前全线向el7迁, 跳过了el6, 内核方面一般我们都是会自己打, 之前阿里曾经对我们的基于el5的3.18.16内核各种panic, 后来针对它做了优化暂时稳定, 物理机还好, overlay我看el7带的模块里面已经包含了, 应该可以一试, 据说倒不是性能更好, 这方面应该dm会更好, 但肯定能解决busy问题, aufs系统应该没有未来, 所以索性一步到位.

我们的前端目前是使用自己封的tengine包, resty里面的lua支持部分是直接拷贝库文件过去的, 因为lb打算直接集成个容器, 结果发现打完了都400M了…………还真是大, 基于alpine因为用不了我们自定义的yum源, 所以很多工作可能要重做, 暂时还没尝试这个思路. 貌似我看lb3里面已经有req_limit了, 这个倒可以搞一个开源的规则引擎, 基于apache的有, 简化一下在性能和安全中间取个平衡应该是可行的.

corvus的配置方面我搞定lb和容器的大框架后去研究下, 这个是要全定义？还是部分定义剩余采用默认值？如果是部分的话可以给出一个列表. 另外基于c的项目真的是比cpp要好维护多了, cpp我目前除了一个老版的tair在线上跑, 基本没有线上应用了, 之前cerberus还有时莫名其妙core掉, gdb也纠结.

[CMGS]

@jasonjoo2010 go 的打包简单得一逼，build 的时候 -tags netgo 把 net 模块对 cgo 的依赖一关，fpm 分分钟到 el7 的 rpm 爽得嗷嗷叫，我们现在这一步完全是用 gitlab ci 全自动打包分发。core1 的那个 python 版本安装门槛太高了，当时也有要培养新人的想法，遂推到重来。

我们倒是全 el7 的版本，之前也是因为在芒果TV 只有 el6 能用（这还是争取回来的，本来理论上只有 el5）所以心有余悸吧，当时还做了3.8 3.10 4.0 各种内核的测试和打包，反正没一个完全如意的，现在这边 UCloud 就更妖了，我们自己的内核上 UHost 机器直接 panic，所以最终我们放弃了维护自己内核的方案。不过就我们自己测试而言在数量极多的小文件随机读取性能上 overlay 确实会比 dm 好一些，直接上 overlay 的话从现在这个时间点上来看应该是没问题了。busy 那个事情真的是，至今都没精力去研究为啥2个小版本号差别的内核能在问题表现上有如此之大的差异，我们和豆瓣都遇到了，然后就都切了 LVM。

lb3 的那个 req_limit 如果我没记错应该是没启用，测试倒是过了，这一块我们倒是有计划近期重写（opm 的模块化重构计划之一）。我们现在 golang 的组件和 openresty 几乎都是 alpine，但在实际使用过程中其实并不是特别顺利，主要是 libc 和 glibc 的差异还是比较大的，比如日期格式不支持 %l 就导致我们线上核心设施崩过。不过 alpine 这幺蛾子配合 golang 的纯二进制 binary 部署起来简直快如闪电…一个镜像才几十M。

对于 corvus 而言，应该只需要 set remote 命令和增加命令行配置线程数以及是否需要 debug 就好了，行为上应该就和 cerberus 完全一致了，其他的走配置文件倒是无妨。我们之前在做 C1 到 C2切换的时候（也是 ERU1 升级到 ERU2）也是受限于 Cpp 的维护，进度一直很慢，后来总 BOSS 说话啦，反正 C1 短期内不会废掉，所有关于 cerberus/redis 的就还在 C1，C2 先把业务跑起来再说，遂放弃了对 cerberus/corvus 系统的兼容和修改。

[jasonjoo2010]

@CMGS 关于dm的busy问题, 其实这个blog说得蛮清晰了, 解决方案也有了, 然而我并不想private…………所以直接选用了overlay. http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

我本来想改下docker的service, 结果src安装下来直接测试打包都不过……一堆docker自己的库调不到, 比你那个panic妖多了, golang之前一堆坑所以一直还没正式研究过, 浪费了几小时后索性直接用daemon.json的分发先解决掉了, maybe需要一个集中的时间仔细研究下golang该死的依赖逻辑和绿色打包方法, 那个用gopath放库的逻辑真挺恶心的, 可能需要动态把源码路径加进去吧.

关于云上panic的问题, 这个一定要问好云的虚拟化方法, 有针对性地进行驱动加载, 基本上panic都是驱动加载的问题, 例如xen虚拟的内核编译时未加入xen guest支持等, 包括时钟驱动, 一般总会牵扯自编的, 小到timewait修改, 大到想在el5上运行cerberus（新socket状态支持和PORT重用）, 都需要改内核, 这个东西就是不破不立, 努力前进哈哈. 综合考虑的话估计未来还是overlay的, 开源社区的热度问题.

目前镜像大小在内网问题还不大, 毕竟本地可以缓存, 主要的影响点就是push到registry的时候, nginx的request限制需要变态地大（目前500M）, 不然推不上去……

K＆R 说过, cpp真的是聪明人玩的……

[CMGS]

@jasonjoo2010 这个倒是之前没翻到，回头找个 vm 试试耶。如果要自己 build docker 的话是非常非常非常非常恶心，我一度想给 docker 打补丁，后来因为这事放弃了。就目前来说 golang 的 package management 简直就是屎一样，我自己本地是把 src 一路 ln -s 进 gopath。在 1.6 之后 golang 启用了 vendor 的做法，但并未普及开，尤其是 docker 这种 old fashion 的。如果是新项目的话，你可以看看 gopm(https://github.com/gpmgo/gopm)，当然了想要有 virtualenv + pip 那种体验基本是不可能的。req 版本管理要么废神，要么听天由命。业内早就有 gopkg.in 这种解决方案的存在下，大多数第三方库还是走的 github 每次看着那 hashtag 做版本管理，真是药丸。

就是这个云上的虚拟技术差异啊，太费精力了，没记错的话 UHost 在不同机房上柜时间不同的机器上还走的不同的虚拟技术，所以最后的就放弃了。Overlay 现在就差一个强力的 example 了，百度据说是用过，但没太多的 detail，我们纯粹是图稳，反正有 SA 背锅侠。

镜像大小的话看你们机房多不多，没记错的话腾讯应该是做过 registry 上 CDN，为了增加分发速度。所以我们一开始都是自建 base image 所以这一块上把控的还是比较好，比起之前豆瓣动辄 3/5 G 的镜像，就算是 Java 的我们也压到了800M左右。通过 gitlab ci 的 build -> artifacts 的方法，进行二次封镜像会让整个 image 清爽很多。本地 cache 其实有时候很 evil，比如你有个什么修改，还需要上机器 remove 掉 old 的，而且有个比较蛋疼的问题是本地 cache 也占磁盘，然而 UCloud 等虚拟机磁盘又给的小，最后不 auto remove 没用的就呵呵哒了。所以你看 eru core 里面应该就有当这个 image 没任何 alive container 的情况下 auto remove 掉 image 的代码。

我知道的 cpp/cpp 11/cpp 14/cpp 17是4种不同的 cpp …… 饿了么之前也是觉得 cerberus 不好维护转 C 重写以至于今天我在复现一个现象的时候发现 corvus 和 cerberus 会有同样的表现 lol

[jasonjoo2010]

@CMGS 我还以为是我方法不对, 看来github类型的引入的确就是恶心, 不过python也不完美, 经常系统组件版本不一样了然后pip的module就不兼容了, 继而导致依赖的大组件一起升级, 然后去解决新版的适配, 典型官方pypi镜像不少软件只保留最新版, 老版的＝＝依赖都执行不了, 找个国内镜像可能会全些.

overlay的话我们先试试吧, 换lvm比较折腾, 我们用ext比较多些.

镜像的问题, 可以定期pull, 应该会像git一样自动更新, 实机的优点就是硬盘大, 阿里上也不大.

貌似一旦run起来的容器没办法改参数, 因为这点总在回滚重新打包, 我们的base要做的操作大部分比较复杂, 难以写成dockfile, 接下来就要看这种网络模型下的性能如何了, corvus那个pr已经沟通好了, 搞完elb和新的core后我就fix一个版本出来

[jasonjoo2010]

@CMGS 这个elb3貌似完成度不高？api层域名操作不完全, 当然这好像也不太安全, 准备单做一个集群管理, 但rules貌似只使用了shared, 这个多节点下如何更新？还是说这个要去设计一下？ UAcheck貌似是TODO, 不得不说注释实在太少了…………

配置更新使用subscribe怎么样

[CMGS]

@jasonjoo2010 我把那个小鬼叫过来给你人肉注释下。现在采用 API 操作是因为之前 elb 都是这样的，上层的操作者懒得动，就一直没动。说到 subscribe 啊，我倒是自己写了个版本是这样弄的，要不你参考下呗，subscribe 的问题就是你要考虑多 worker 的情况下，重连/竞争/数据可能丢这3个问题，代码在 https://github.com/projecteru/eru-lb/tree/subscribe 这个下面。

我们 elb 开发分了几个阶段，提出想法并实现的是第一版，elb v1 洪武，主要是芒果TV用。这个 subscribe 版本只在线下跑过，主要是验证 elb 分组和 pubsub 用于配置发布的功能，代号朱标。现在线上跑的带 path filter 的第二版 elb v2 建文，最之前给你的 elb v3 就是永乐了……所以对 elb v3 有任何问题都可以抓着我那小弟提需求和改改改哈哈。

[ZhangYet]

@jasonjoo2010 你好，我是现在 elb3 的主要维护者。 rules 用了 shared 和 redis 。多个节点下我们的客户端会向多个 elb3 节点写入同样的数据。如果要增加新节点，那么新节点通过读取 redis 可以得到其他 elb3 的数据(配置 ELBNAME 这个环境变量就好）。

你不介意的话，对 elb3 的讨论我们不妨在 https://github.com/ZhangYet/erulb3 开 issue 讨论？