各大公司容器云的技术栈对比

郑昀编著于2015/10/20

目前来看,几家历史包袱较重的公司都选择不让上层应用感知到底层是 VM 还是容器,所以都改了 docker 内核,如360、点评、汽车之家。最后附上我们的容器私有云技术栈以及系统截图。

 

点评容器技术栈

  • 2014年启动基于 docker 搭建私有云,之前谈不上使用过私有云

  • 运维工具:Puppet

  • NATS+Nginx+Zookepper:

    • 组件之间的交互使用了 NATS,通过消息的『发布-订阅』模型,将各个组件之间的耦合最小化

    • 对于Web类型的应用,通过和 Nginx 暴露的 Restful 接口交互,完成实例在集群内的注册以及注销。对于服务类型的应用,通过在 ZooKeeper 上注册和注销服务IP和端口,便于服务客户端发现和更新该服务

  • 技术改造:

    • 由于不愿意让技术人员感知到从 KVM 到 Docker 的转换,所以做了不少工作(注:主要还是不愿意影响原有业务和发布流程)

    • 更改了 Docker 底层代码,让其从推荐的微服务架构演变到目前的『虚拟机』架构。开发和运维可以通过 IP 直接访问到 Docker『虚拟机』,基于IP的应用基础架构也不需要开发和运维做剧烈的改变

  • 使用情况:

    • 基本上除搜索和数据库以外,点评现有的业务大多都有跑到容器上的

  • 监控改造:

    • 通过收集 CGroups 和容器实例的实时信息,将内存、CPU、网络等源源不断地上报到 CAT,再由 CAT 提供查询,检索和展示。也可以做报警

  • 组网:

    • Bridge Networking 工作在 level 2 的模式,使公共 IP 得以暴露出来,这部分是做了定制的

 

360容器技术栈

  • 运维工具:集群变更用 Puppet(master/slave)

  • 持续集成:jenkins(master/slave)+mesos+marathon+zookeeper

    • 360容器-持续集成

  • 技术改造:

    • docker 底层改造

      • 能够设置 btrfs 磁盘限额,网络限速,IO 限制

      • 容器独立IP

      • 容器内多进程

  • registry V2

一些优化细节:

  • 利用 Jenkins master-多个slave 缩短构建时间:

    • 分布式提高 build 性能

    • slave 记忆利用 cache

  • 利用 btrfs 和 ssd 缩短构建时间:

    • devicemapper 换成 btrfs

    • sas 硬盘换成 ssd 的

 

UCloud容器技术栈

  • docker版本:1.1.1,1.8.2

  • 发行版:centos 6.x

  • k8s版本:1.0.6

  • 实践经验:

    • docker日志:日志打印耗费性能,最好关闭 logdriver,将日志打印在后台

    • docker daemon:centos 6.3 service stop 耗时长,需要5分钟,是 init-scripts 的 bug

    • docker网络:

      • NAT模式下会启用 nf_conntrack 造成性能下降,可以调节内核参数

    • 合理设置 ulimit

    • docker镜像:

      • 制作镜像时,commit 的信息要简单明了

      • 编写 dockerfile 规范,减少镜像层数,基础部分放前面

      • 分地域部署镜像 registry

 

汽车之家容器技术栈

  • docker版本:1.6.2

  • linux发行版:centos 6.4 kernel 3.10和4.0

  • registry V2

  • 构建:

    • 有单独机器做构建

    • 基于centos:7+systemd+zabbix

      • 汽车之家-容器-构建

  • Docker Hub

    • Docker Registry 2.0

    • Registry 本身不能够高可用,Nginx 负载多个 Registry

    • 使用网络存储共享镜像

    • 配置 Mirroring,获取官网镜像

      • 汽车之家-容器-配置 Mirroring

  • Docker应用-网络问题

    • Docker 目前提供的网络模式不适合业务环境

    • --iptables =false

    • 修改 Docker 内核改成静态 IP 模式

    • IP 是通过容器名字为标识从 IP Pool 获取

    • 汽车之家-容器-IP Pool

 

蚂蚁金服PAAS docker提到的迁移问题

  • 老应用迁移的痛

    • 谁来写Dockerfile并制作应用镜像

      • 蚂蚁线上已经有上千应用,几千开发人员,很难一下推动他们都学习 docker,切换到新的研发模式下

      • 如果需要开发人员写 dockerfile,会影响推广效率

    • 蚂蚁原有的运维/监控/SCM/财务等系统都是以 vm 为纬度的

      • 基于 docker 的运维发布系统与原有系统对接比较麻烦

      • 以往运维都是先申请一批机器,测试网络正常后备用,上线前再决定跑什么应用

      • 发布应用不重启 vm,所以也不希望重启 container;

    • 怎么尽量保证开发测试环境与生产环境一致

  • 应对策略

    • 开发辅助工具帮助研发同学编译应用/自动生成 dockerfile/制作镜像并搭建测试环境

    • 把 CAAS 当作轻量级的 IAAS,让运维把 container 当作轻量级 vm 用,便于和已有系统对接

  • 使用通用的 sofa4/sofa3 container,可以不需要制作应用镜像

  • 在基础镜像中集成 sshd,运行运维 ssh 到 container 中

  • 使用 supervisor 启动应用和相关监控/运维 agent

  • 提供 webconsole 允许开发人员登录 container 查看日志/进行一定权限的 操作

  • 使用 data container 避免本地 mount

 

最后列举一下我们技术团队的容器私有云技术栈

截止到2015年9月,窝窝容器管理集群的技术栈包括以下内容:

  1. mesos(资源调度)

  2. marathon(服务编排)

  3. chronos(分布式计划任务)

  4. docker(容器引擎)

  5. consul+registrator(服务注册和发现)

  6. haproxy(负载均衡)

  7. prometheus(服务监控)(注:同时数据也会推送到天机系统的 OpenTSDB 里)

  8. nagios/zabbix(节点监控)

  9. salt(节点配置管理)

  10. cobbler(节点自动化装机)

  11. ELK(日志收集分析)

窝窝持续集成管理平台在这些技术的基础上,实现了我们的集群管理、容器管理、应用管理等业务流程。

一些系统截图如下所示:

wowo-容器-应用详情

 

wowo-容器-应用详情-日志

 

wowo-容器-主机详情-主机资源

 

wowo-容器-主机详情-容器列表

-END-

欢迎订阅我的微信订阅号『老兵笔记』,请扫描二维码关注:
老兵笔记订阅号二维码

你可能感兴趣的:(各大公司容器云的技术栈对比)