明晚九点|发布系统演进与持续集成

标签：ber   客户机   接收   vpd   调度系统   演进   分配   修改   运维工具   

内容：

• 背景介绍
• 手动发布的阶段
• 自动化阶段---脚本
• 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（进入直播分享群）

明晚九点|发布系统演进与持续集成

标签：ber   客户机   接收   vpd   调度系统   演进   分配   修改   运维工具   

原文地址：http://blog.51cto.com/51reboot/2064727