主题：发布系统演进与持续集成
内容：
- 背景介绍
- 手动发布的阶段
- 自动化阶段---脚本
- 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 方案
加小助手微信：1902433859（进入直播分享群）
原文地址：http://blog.51cto.com/51reboot/2064727
时间： 2024-11-02 14:05:51