大厂容器云实践之路（四）
7-爱奇艺基于 Docker 的 App Engine 实践
背景
业务上
虚机承载的业务：
后台服务：25%
worker：20%
其他：55%
技术上
2014年第三季度
出发点
目标
道路曲折
用户受益
• 资源到位快
• 部署快（上线、升级）
• 扩容快
• 自动故障转移，免运维
• 完善的监控预警
• 持续集成、发布
iQIYI App Engine 设计与实现
iQIYI App Engine (QAE)
QAE — 监控和预警
QAE — 自动扩展（Auto Scaling）
QAE — 事件总线
QAE — 服务发现
QAE — 日志
QAE — CI/CD
一些经验（坑）
容器监控 — Zabbix
• 优势
• 已有 Zabbix 基础服务
• Auto Discovery 能发现容器启动/消失事件
• 劣势
• 需要在容器内部安装 zabbix, overhead 太大
• 不是很稳定
• 数据统计比较复杂
容器监控 — cAdvisor
• 优势
• 背靠 Google 且开源
• 监控数据详尽
• 劣势
• 集群化开发成本较高，Kubernetes heapster 实现
• influxDB 而非 graphite（当时有基础服务）
容器监控 — dAdvisor
• Docker Advisor
• 采集：CPU, 内存，磁盘，网络
• 集成现有 Graphite
• 统计数据方便（Graphite 内置一些操作符）
• 呈现方便（Graphite Render URL API）
• 开发量不大
Time Series Database — Graphite
• 优势
• 老牌（Since 1999），已有服务，经过验证
• 简单、内置 aggregator，Render URL API
• 劣势
• 项目及社区已经几乎停滞
• 集群化配置复杂，需要详细规划
• 缺乏多用户认证，授权机制，黑白名单太单薄
• 数据删除缺少 API
服务发现（Service Discovery）
• 负载均衡/反向代理方案
• HAProxy：Marathon 支持，用户少
• Nginx：大量用户
• 服务发现
• Flask 推送，SSH，不可靠，不安全
• Ansible 推送，SSH，不可靠，不安全
• event bus + guardro-template
日志
• ELK (Elasticsearch + Logstash + Kibana)
• 延时较高（分钟级）
• 只支持格式化后的日志（for machine）
• 用户诉求
• 低延时（秒级），准实时
• 裸日志（for real person）
• 备份日志（Apache Flume）
现状与展望
现状
• 处于活跃开发状态
• 接入了几十个业务
• 主要业务类型：服务型，RPC，Worker
• 服务型业务 QPS 大于 10 万
• 4 个数据中心
展望
• 支持短任务
• Quota 和计费
• Web Console
• 内置典型服务（如：Tomcat）数据统计
• Docker 持久化卷和跨主机通信
• 支持更多类型服务：Cache, DB, MQ 等
8-蘑菇街基于Docker的私有云实践
做私有云的原因
1、越来越多的机器，集群管理，基础平台的建设
2、提高资源的利用率
3、服务化，平台化，可视化
4、提升发布和部署的效率
5、实现业务的弹性，水平扩展
Docker的优势
1、轻量，秒级的启动速度
2、简单，易用，活跃的社区
3、标准统一的打包/部署/运行方案
4、镜像支持增量分发，易于部署
5、易于构建，良好的REST API，也很适合自动化测试和持续集成
6、性能，尤其是内存和IO的开销
简单易用
docker run -d
--net=none
--name=$name
-h $name
-v /var -v $tmpdir/resolv.conf:/etc/resolv.conf -v $tmpdir/hosts:/etc/
hosts
--cpuset="$cpuset"
-m ${mem}m
--privileged=true
$image
劣势
1、资源调度/集群管理还在春秋战国时期
2、隔离性-仅用cgroup/namespace够吗
3、网络/存储支持完善吗
4、不支持热迁移-CRIU
5、各种坑
Docker@蘑菇街
1、2014年圣诞节期间上线，OpenStack IceHouse + Docker1.3.2。经历过5次+大促，包括双11/双12，线上运行稳定。
2、Machine Container或“胖容器”，用supervisord管理容器中的多进程。
3、每个机房一个OpenStack集群，一个Docker Registry。每个集群可以同时管理KVM，Docker。
4、支持OpenvSwitch VLAN和Linux Bridge两种网络模式，不用Docker原生的NAT网络模式，other_args="--bridge=none"。
5、自研了基于OpenStack的PaaS平台，虚拟化交付系统，虚拟化管理控制台。
为什么都把Docker当成虚拟机
只有Docker是不够的
集群管理
逻辑架构图
nova-docker
• spawn: create -> start -> post_start docker
• 容器启动前做的事情：
• 根据ip段的规则来生成容器的hostname
• 动态添加ip:hostname映射到/etc/hosts
• 启动docker实例时指定CPU set/weight
• 自定义需要mount的folder/file volume
• 扩展OpenStack API，通过cgroup限制磁盘IO和网络IO
• 和Linux bridge/Openvswitch对接网络
• 实现快照方式的冷迁移
https://github.com/openstack/nova-docker/
监控
和已有监控系统的深度集成
实时监控和阈值报警：节点存活性/语义监控，关键进程，内核日志，实时pid数量，网络连接跟踪数，容器oom报警
阈值报警：短信报警，IM报警等多种形式
健康检查：部署环境/配置的一致性检查
container-tools:
参考内核算法实现容器内load值的计算
替换了uptime，top，free，df，类似docker stats。
Container-tools
• mount /cgroup 到容器内
• 容器启动时用docker exec创建一个文件记录每个容器使用的cpuset，实例uuid等信息
• 修改uptime，top，free，df，tsar等源码，读取 /cgroup下的cpu/memory/IO值信息
• 曾经尝试过lxcfs，但问题很多，限制也很多。
实时监控和报警
网络
• NAT-20% performance lost
• Host mode? No network isolation
• Linux bridge without iptables
• OVS VLAN without iptables
• other_args="—bridge=none"
容灾
• 离线恢复docker容器中的数据的能力
• Docker实例跨物理机的冷迁移：docker commit，docker push。
• 动态的CPUٖ内存扩容：cgroup。
• 网络IO/磁盘IO的限速: cgroup/tc。
http://mogu.io/127-127
PaaS
• 目标
• 快速的系统构建
• 业务的平滑部署升级
• 自动的运维管理
• 自研的轻量PaaS，实现编排能力
• 支持基于容器的持续集成：Jenkins+Docker，从编译到构建全自动化
• 概念
• App：一个应用包含一个或多个Stack
• Stack：相同的Docker实例，一个Stack中的不同实例尽量部署在不同的物理机上
Docker Registry
基于Docker的持续集成
基于PaaS的业务平台
遇到的坑
• devicemapper中thin-provisioning的discard功能引起的kernel crash
DOCKER_STORAGE_OPTIONS="--storage-opt dm.mountopt=nodiscard --storage-opt dm.blkdiscard=false"
http://mogu.io/docker_crash-79
隔离
• 物理机上无法执行命令操作。“bash: fork: Cannot allocate memory”
• 容器内如果创建大量的进程，并且不回收，是会导致系统内核的pid_max达到上限
• ٖ内核中的pid_max(/proc/sys/kernel/pid_max)是全局共享的
• Process Number Controller:
• 仅最新的4.3-rc1支持，pid-max per containers̶
• https://www.kernel.org/doc/Documentation/cgroups/pids.txt
• 容器内的内存值计算不准确，比实际低一个量级
• /cgroup/memory/docker/id/memory.usage_in_bytes
Docker目前的局限
• 系统/内核层面的隔离性
• 缺乏成熟的集群管理（K8S/Swarm/Mesos）
• 业务无感知的升级，Docker daemon live upgrade
未来的畅想
• PaaS + App Container + CI/CD
• Kubernetes/Swarm/Mesos
• 更高效更便捷的运维
• 统一的部署方式，弹性的资源交付
• 公有云平台