主题：发布系统演进与持续集成
内容：
-
背景介绍
-
手动发布的阶段
-
自动化阶段---脚本
-
puppet
-
自主研发支持
-
支持容器化
-
持续集成
主讲师：萝卜
-
多年 go 语言开发经验
-
从事自动化运维和基础架构相关工作
背景
管理什么？
-
用户
-
权限
-
配置文件
-
软件包
-
服务
-
机器
-
cron
特色
-
支持异构系统，linux、windows
-
支持多种语言，java、php、c++、web
-
大规模部署
-
跨 IDC
-
与其它运维工具无缝集成
-
支持全量与增量发布
-
支持健康检查
-
支持各种并发控制
-
支持各种数据统计
-
实时性要求高
手动发布阶段
人肉发布流程
人肉发布优点
-
最直接
-
简单可信赖
-
小规模，适合创业公司
-
天然支持异构环境，不同语言
人肉发布缺点
-
效率，人力浪费，(@ο@) 哇～，排队了
-
容易出错，特别是紧急上线，文件拷少了
-
Check考虑不全（经验总结自动化）
-
流程好长
-
好慢。。。
-
怎么回滚？
-
人肉并行吗？
自动化初始阶段
-
scp、rsync、python
-
依赖运维脚本，需要修改脚本？参数传少了？别人写的？
-
严重依赖中控机（ACL）
-
脚本缺乏统一管理，散落在各机器上
-
发布的中间数据、结果丢失
-
如何进行回滚、并发控制？
puppet
puppet 解决的问题
-
自动化部署
-
资源管理
-
系统初始化
puppet 架构
puppet 工作步骤
-
客户端 puppetd 调用 facter ，facter 会探测出这台主机的一些变量如主机名、内存大小、IP 地址等。然后 puppetd 把这些信息发送到服务器端。
-
服务器端的 puppetmaster 检测到客户端的主机名，然后会到manifest 里面对应的 node 配置，然后对这段内容进行解析，facter 送过来的信息可以作为变量进行处理的，node 牵涉到的代码才解析，其它的代码不不解析，解析分几个过程：语法检查、然后会生成一个中间的伪代码，然后再把伪代码发给客户机。
-
客户端接收到伪代码之后就会执行，客户端再把执行结果发送给服务器。
-
服务器再把客户端的执行结果写入日志。
问题
-
二次开发成本
-
机器数量持续增加效率
-
与其他系统集成
自主研发之路
设计考量
-
用户权限、安全管理
-
管理机器
-
管理软件包
-
跨平台支持
-
数据统计
-
并发控制、性能
-
持续集成
业务领域
基本架构
机器管理
-
运维手动添加
-
静态分配
-
按照产品线（分组）
-
权限
-
心跳、存活
-
资源
包管理
-
支持多语言
-
高可用
-
多版本
-
自动构建、打包
任务管理
-
调度系统
-
Agent 执行器
-
资源中心
-
依赖子系统
Agent 设计考量
-
分布式部署
-
自升级
-
多账号执行支持
-
任务幂等性
-
各种 agent 如何管理
容器化支持
创建服务的流程
-
docker 中部署服务构建镜像（用 docker build 构建镜像）
-
发布镜像（push 到共享的镜像仓库中）
-
下载镜像（使用者将镜像下载到客户端本地）
-
运行容器（将镜像不环境变量相结合，运行容器）
-
访问服务（通过端口映射或独立IP的方式访问服务）
步骤
-
制作镜像（打包）
-
部署服务
-
启动容器
-
健康检查
镜像
-
自动构建镜像
-
镜像仓库
-
镜像大小
健康检查
-
配置中心
-
监控告警接入
-
服务自动拉起
开源解决方案
-
Mesos+Marathon
-
Kubernetes
Mesos+Marathon解决方案
Kubernetes 方案
转发本文到朋友圈并获得50个赞及以上的即可获得我们的精美 Golang 书籍一本。（包邮到家）
（截图发小助手）
分享时间：1月 25 日晚上九点
分享方式：网络直播
参与方式：
扫码添加小助手微信，备注"公开课"，进入分享群
网友评论