郑昀编著于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
-
-
技术改造:
-
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,获取官网镜像
-
-
-
Docker应用-网络问题
-
Docker 目前提供的网络模式不适合业务环境
-
--iptables =false
-
修改 Docker 内核改成静态 IP 模式
-
IP 是通过容器名字为标识从 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月,窝窝容器管理集群的技术栈包括以下内容:
-
mesos(资源调度)
-
marathon(服务编排)
-
chronos(分布式计划任务)
-
docker(容器引擎)
-
consul+registrator(服务注册和发现)
-
haproxy(负载均衡)
-
prometheus(服务监控)(注:同时数据也会推送到天机系统的 OpenTSDB 里)
-
nagios/zabbix(节点监控)
-
salt(节点配置管理)
-
cobbler(节点自动化装机)
-
ELK(日志收集分析)
窝窝持续集成管理平台在这些技术的基础上,实现了我们的集群管理、容器管理、应用管理等业务流程。
一些系统截图如下所示:
-END-
![老兵笔记订阅号二维码](https://i-blog.csdnimg.cn/blog_migrate/7dd6060b91010c290ab9c32f1cec73d3.jpeg)