PaaS 困境
PasS(Platform as a service) 从万众瞩目到普遍质疑
-
PaaS企业⽣生存艰难
-
*AE等模式不被⼲⼴广泛接受
-
PaaS⾛走向垂直化
Docker 的优势
- 适应能⼒力强，可应⽤用到⾮非常多应⽤用场景
传统vm、快速开发环境提供、打包、隔离等
可⽆无痛运⾏行各种各样的中间件和应⽤用
- ⾃自包含self-contained
开发、测试、生产的一致性
跨不同基础设施的转移能⼒力
-
Docker 已经在开发环境赢得了开发者的拥护
-
开发环境和⽣生产环境需求不同
| 开发环境 | 生产环境 |
|---|---|
| 单机 | 集群 |
| 功能 | 性能/稳定 |
| 调试 | 维护 |
| Dev | Ops |
提纲
镜像管理
发布管理
⽇日志管理
配置管理
存储管理
⺴⽹网络管理
镜像管理
镜像存在的问题
编写Dockerfile构建镜像,调试⿇麻烦
代码发布频率⾼高，镜像更新频繁，升级⿇麻烦
Registry单点如何克服
Docker pull拉取镜像太慢如何解决
Registry如何做好权限管理
ps: 其实和 maven 包的管理非常相似。
镜像制作原则
坚持Dockerfile生产镜像的原则
镜像之间避免依赖过深，一般建议三层
基础OS镜像、中间件镜像、应⽤用镜像
坚持”所有镜像都应该有对应的Git仓库”
镜像制作⽅方法
Dockerfile调试⿇麻烦
运⾏行一个基础镜像并attach到bash
交互式进⾏行软件的安装、配置的修改
commit⽣生成镜像，指定CMD反复测试镜像
编制Dockerfile并build
运⾏行多进程，需要init进程且⽀支持SIGTERM转发
镜像更新
代码发布频率⾼高，导致镜像更新频繁
- 镜像的更新通过SCM和CI系统⾃自动触发实现⾃自动化
- 应⽤用镜像严格使⽤用Git SHA作为镜像的Tag
OS镜像和中间件镜像一般使⽤用软件版本作为tag，需要小心ImageID变化但Tag没有变化，可能会造成依赖它的应⽤用镜像故障
私有 Registry
Registry单点问题
-
存储使⽤用本地硬盘可考虑drbd，主备模式
-
后端采⽤用分布式存储，⽐比如swift等
-
如果在云端，可考虑直接使⽤用对象存储，目前阿⾥里云的OSS和新浪云存储都可以作为Registry的后端
Regitry性能问题
-
http反向代理缓存可以加速Layer的下载
-
Registry v1 Mirror 功能不⽀支持私有Registry，v2有望改进，Mirror功能可以解决⾼高可⽤用、pull性 能等问题 docker/distribution
Registry⽤用户权限
-
Docker Index是⽤用于解决Registry⽤用户管理和镜像索引的服务
-
Nginx LUA可以提供一个简单快速的实现⽅方案
发布管理
常⻅见的发布流程
备份数据
依赖检查和确认
基于package或者代码的部署
检查升级是否正常，失败回滚
- 风险
漏掉某个依赖或依赖对象不匹配；回滚考虑的细节点太多，经常导致⽆无法回滚
基于 Docker 的发布
日志管理
日志管理的问题
-
docker 作为虚拟机，日志管理没有问题
-
docker 仅运行服务
⽇日志回滚、收集更加复杂
容器销毁⽇日志消失
日志收集方案
- 日志打印到stdout/stderr
通过logspout收集转发
比如阿里云就是借助 tail 工具收集的。
- ⽇日志打印到⽂文件
日志存储到外部volume下
在Host上收集转发,建议ELK⽅方案logstash+elasticsearch
例如 filebeta 之类的工具。
- docker1.6 ⽀支持⽇日志收集，syslog
日志回滚方案
- 业务连续性要求高
直接truncate日志⽂文件
- 日志数据完整性要求高
mv logfile logfile.1
docker restart (业务瞬断)
- 日志写往/dev/log
通过syslog收集转存或转发
转存到本地需要回滚，但不需要重启容器
配置管理
配置管理的问题
-
容器里没有CM agent，无法接收CM指令
-
CM运行到Host上⽆无法管理到容器里的⽂文件
-
手工修改容器内的配置，新创建的容器仍然是旧的
当作vm没有这样处理没有问题
丧失了动态扩展的特性
配置变更建议
传统上使⽤用CM管理⼯工具管理配置的分发并保证收敛
- 服务之间连接(connect)相关的配置
使⽤用服务发现系统⾃自动适配
通过传递环境变量协调在开发和⽣生产环境的配置差异
- 一般的配置⽂文件参数
配置⽂文件和Dockerfile一起存储到一个Git仓库，修改后⾃自动build更新镜像
存储管理
数据存储的挑战
体积大，若干G
不断被修改
转移难度高
各种存储方案的优缺点
存储使用的建议
优先使用内部已有的健壮的存储，比如SAN
否则使用本地存储，做好复制和备份策略
创建data-only容器，做好命名标志，避免误删除
网络管理
Docker 支持的网络
-
Host网络，一般不推荐
-
NAT网络(默认)
-
物理网桥
-
网络虚拟化
Host 网络问题
-
容器和主机共享网络命名空间
-
不同容器需要做好端口规划，防止端口冲突
-
无法针对容器统计网络流量
Nat 网络问题
基于四层代理以及NAT技术
依赖Portmap
进出都需要转发，性能低
Host上需要做好端⼝口规划，容易搞混
物理网桥的问题
静态绑定IP到容器，不适合动态变化
动态dhcp分配IP到容器，需要管理好租期⻓长短，因为容器的生命周期比虚拟机短很多
docker build失效
不适合单主机运行超大量容器(比如1000)
网络虚拟化
基于隧道的overlay网络
目前有基于vxlan、gre、udp等不同的实现
开源方案
socketplane
weave
flannel
基于ovs的pipework
网络方案的建议
性能要求低，业务不复杂，规模不大，端口映射挺好
容器数量有限且相对静止，物理网桥方案很好
数量⼤大，动态创建销毁，建议采纳网络虚拟化
尽量固化IP和端口的分配，避免过于随机
避免使⽤用docker link，依赖陷阱，”自包含”好处失效
被依赖容器的ip和端口重启不发生变化，可以使用link
拓展阅读
参考资料
《Docker 在生产环境的挑战和应对》
