理解
大家最受影响的就是一半时间开发, 一半时间运维的这个问题. 利用一个成熟的配置文件, 快速部署起自己需要的环境, 而不是一步步通过页面控制点击, 这是一个很省力的事情. 将运维中与部署相关的事情通过一些成熟的模板化的配置文件来提供, 最好不过了.
ansible比较大的几个优点
- 由于是开源框架, 基于ansible的针对其他开源软件的配套代价较多
- 比如集成钉钉等
- 配置文件化管理部署成熟
- 可针对不同的环境, 使用不同的配置文件快速部署
- 可以使用开源插件快捷对接配置管理服务
- 因为 Ansible2.0以上的版本已经原生集成了consule: consul_module
不建议的操作
建议遵循unix
思想, 一个工具只做该做的事情, ansible虽然提供了能力, 但是能由脚本来完成的事情, 没必要在ansible中进行处理 根据[^10]终于意识到我现在所处理的最别扭的地方在哪里了...这篇文章中说了下述几点.
- 在 ansible 中使用复杂的语法规则
- 更推荐直接封装成脚本, 由脚本来进行这些操作.但是脚本的粒度拆分, 什么应该让ansible来操作, 什么应该让脚本来处理, 是个边界.
- 明明几行 Shell 就可以搞定的事情,为什么一定要使用 Ansible 来做呢?
- 明明一个 Shell 脚本就可以完成的环境监察,为什么一定要使用 Ansible Playbook 来做呢?要知道 Playbook 编写语法虽然是 YAML,但是使用起来并不简单,有很多特殊的语法需要去注意,完全没有必要花费精力去学习一个新的工具去完成。
- 如果脚本中存在较多判断,不宜使用 Playbook 实现逻辑
- 如果脚本中存在部分参数解析功能,不宜使用 Playbook 实现逻辑
- 不要过度拆分 task,保证每个 task 完整性
从个人使用上来说,Ansible 还是很好用的,至少它无需 Agent,SSH 连接等特性,使用起来很友好。
但是我们也不应该过分使用 Playbook,编写 Playbook 解析 json 花费了不少的时间,远不如直接在被执行脚本中完成的成本低。
tidb开发计划
deploy.yml 用来部署集群。执行 deploy 操作会自动将配置文件、binary 等分发到对应的节点上;如果是已经存在的集群,执行时会对比配置文件、binary 等信息,如果有变更就会覆盖原来的文件并且将原来的文件备份到 backup(默认) 目录。
start.yml 用来启动集群。注意:这个操作只是 start 集群,不会对配置等信息做任何更改
stop.yml 用来停止集群。与 start 一样,不会对配置等做任何修改。
rolling_update.yml 用来逐个更新集群内的节点。此操作会按 PD、TiKV、TiDB 的顺序以 1 并发对集群内的节点逐个做 stop → deploy → start 操作,其中对 PD 和 TiKV 操作时会先迁移掉 leader,将对集群的影响降到最低。一般用来对集群做配置更新或者升级。
rolling_update_monitor.yml 用来逐个更新监控组件,与 rolling_update.yml 功能一样,面向的组件有区别。
unsafe_cleanup.yml 用来清掉整个集群。这个操作会先将整个集群停掉服务,然后删除掉相关的目录,操作不可逆,需要谨慎。
unsafe_cleanup_data.yml 用来清理掉 PD、TiKV、TiDB 的数据。执行时会先将对应服务停止,然后再清理数据,操作不可逆,需要谨慎。这个操作不涉及监控。
并行任务引擎
作业编排:可以自由选择相应的原子化操作,编排和发布新的作业流程
可视化: 通过拖拽鼠标编排作业流程和参数表单,作业运行与任务的状态可视化
并行调度: 同一个作业中的任务支持并行执行,在很多场景下能极大的缩短执行时间
实时监控: 任务的运行状态在页面上实时更新
断点执行: 执行错误的任务在修复错误后可以继续执行,不需要重新执行整个作业
任务回滚: 遇到错误,可以支持回滚作业中已经执行过的任务,恢复执行环境
作业模板: 可定制作业模板,用模板创建作业实例,避免重复工作
任务组: 在作业模板中把任务分组,在创建任务实例时候可以动态的复制任务组,相似的作业使用同样的模板,但又不限制于模板
计算表达式: 使用表达式动态的计算任务的参数值,能够极大的简化重复参数的输入以及复杂参数的拼接
动态参数:前面任务的输出作为后续任务的输入参数
同类比较
- fabric
- 快速入门使用
- puppet
- C/S架构
- 大部分付费功能
- Chef
- ansible
- 语义多层架构
- 基于ssh, push/pull均支持
- cephadm是使用工具的配置语法进行部署后, 为了更强程度的自定义而进阶开发的产物.
- TODO:设计角度, 为什么cephadm用了docker?
- 另外, cephadm支持所有业务的部署能力是否和这个有关?
- SaltStack
- 基于python的开源CM工具
- CS架构
- 学习曲线低
- cephadm之后有配套saltstack的
- Kolla-ansible?
- 应该是openstack用的
- 苏宁的产品化Hull思路
- 基于上面的, 设计标准的RESTAPI
- 定义Workflow
- 可视化安装
- 增加Data Center, cluster, region等逻辑概念, 更好的满足用户的部署需求.
最佳实践
重试逻辑 --start-at-task
这里采用的方案是自定义一个callback
的插件, 将failed
的task
记录下来,见callback, 然后封装一个CLI
, 在下次执行的时候增加--start-at-task {task_name}
来进行调度. ### 优化方案 和一开始调研时的目的有点不一样, 现在发现的主要问题在于ansible做的预处理的逻辑太多了, 而且主要框架严重依赖单独的ssd和shell, 这样带来的问题你就是部署的性能较差.
需要找一些优化的方案
- facts收集
- 关闭
- 设置缓存
- 增加并发
- 修改运行策略为free等.
- ssd长连接
- 开启pipelining.
- 原本的逻辑是将library,role等生成一个脚本, 复制到远程主机上, 再执行. 现在改为通过pipe直接传递给ssh会话.
- 开启accelerate模式, 是需要对面的远程服务, 预计是通过rpc类似?
- 通过poll设置一段时间后再来查询, 不阻塞着等待了.
插件开发
callback
主要目的是支持可以解析出当前失败的任务, 然后给另一个进行重试的接口进行使用.
rolling upgrade什么意思
好像应该叫做rolling update模型, 哦,滚动升级
哦, 忽然明白为什么是loop结合delegate_to了, 因为要的不是并发,而是滚动操作.
继承的方法
- v2_runner_on_failed
- runner_on_failed
这俩函数有什么区别呢? 目前看起来v2版本并没有加强多少? 那就随意使用了先.
理解开发方式
感觉[^3]这种插件的阅读方式能提供一些参考.
python调用ansible
python3.8 调用ansible 2.9.4 api | 经验分享&服务器代维
ansible使用
开源许可证
根据GPL license implies that my plugins are also GPL (MPD's note: it does not) · Issue #8864 · ansible/ansible可知, 虽然ansible
是GPL 3.0
, 但是由于我们编写的部署脚本是被ansible
读取执行, 并非链接. 因此可自行决定使用的许可证.
调试方式
- epdb
- -vvvvvv
- 虽然文档中只写了
-vvv
, 但是实际上代码里有一部分写了vvvvvv
的函数. - 达到这个等级的时候, library里写的logging日志就能输出了.
- 虽然文档中只写了
- 设置ANSIBLE_KEEP_REMOTTE_FILES=1, 然后再运行Ansbile命令
- ansible运行前生成的临时脚本就会保存下来, 不会被删除了.
- 有时候还是用syslog比较省事
- 其次这次说的raise Exception, 像是facts/system/distribution.py里的依旧没打印出来, 看着像是被拦截直接跳过的