playbook
本文已参与「新人创作礼」活动，一起开启掘金创作之路。
1. 什么是playbook
playbook是一个不同于使用anisble命令行执行任务的模式，其功能更强大灵活。简单来说，playbook是一个非常简单的配置管理和多主机部署系统，不同于任何已经存在的模式，可作为一个适合部署复杂应用程序的基础。playbook可以定制配置，可以按照指定的操作步骤有序执行，支持同步和异步方式。值得注意的是playbook是通过YAML格式来进行描述定义的。
1.1 核心元素
- tasks：任务，由模板定义的操作列表
- variables：变量
- templates： 模板
- handlers：处理器
- roles：角色
1.2 主机与用户
你可以为 playbook中的每一个任务选择操作的目标主机是哪些，以哪个用户身份去完成要执行的任务。
hosts行的内容是一个或多个主机组或主机的名字，以逗号为分隔符 remoute_user是用户名
---
- hosts: httpd,mysql,php
remoute_user: root
或者可以在每一个task中定义自己的远程用户
---
- hosts: httpd
remote_user: root
tasks:
- name: test
ping:
remoute_user: sq
1.3 tasks列表
-
Play的主体部分是task列表，task列表中的各任务按次序逐个在hosts中指定的主机上执行，即在所有主机上完成第一个任务后再开始第二个任务。 在运行playbook时（从上到下执行），如果一个host执行task失败，整个tasks都会回滚，请修正playbook 中的错误，然后重新执行即可。 Task的目的是使用指定的参数执行模块，而在模块参数中可以使用变量.
-
每一个task必须有一个名称
name，这样在运行playbook时，从其输出的任务执行信息中可以很好的辨别出是属于哪一个task的。如果没有定义name，‘action’的值将会用作输出信息中标记特定的task。 -
定义一个task，常见的格式:”module: options” 例如：yum: name=httpd
[root@node1 test]# vim test.yml
[root@node1 test]#
[root@node1 test]# cat test.yml
---
- hosts: 192.168.100.110
remote_user: root
tasks:
- name: test
ping:
[root@node1 test]# ansible-playbook test.yml --syntax-check //测试语法是否正确
playbook: test.yml
[root@node1 test]# ansible-playbook test.yml
PLAY [192.168.100.110] *********************************************************
TASK [Gathering Facts] *********************************************************
ok: [192.168.100.110]
TASK [test] ********************************************************************
ok: [192.168.100.110]
PLAY RECAP *********************************************************************
192.168.100.110 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
2. playbook写法
2.1 编写playbook应遵循以下规则：
- 大小写敏感
- 使用缩进表示层级关系
- 缩进时不允许使用tab键，只能使用空格
- 缩进的空格数目不重要，只要相同层级的元素左侧对其即可
- #表示注释，从这个字符一直到行尾，都会被解释器忽略
- 用---开头
2.2 YAML支持三种数据结构
- 对象：键值对的集合，用冒号: 作为键值分隔
- 数组：一组按次序排列的值，用减号-作为标识
- 纯量：单个的、不可再分的值，如字符串，数值，日期等
2.3 注意事项
-
yaml文件以
---开头，以表明这是一个yaml文件，就像xml文件在开头使用<?xml version="1.0" encoding="utf-8"?>宣称它是xml文件一样。但即使没有使用---开头，也不会有什么影响。 -
yaml中使用"#"作为注释符，可以注释整行，也可以注释行内从"#"开始的内容。
-
yaml中的字符串通常不用加任何引号，即使它包含了某些特殊字符。但有些情况下，必须加引号，最常见的是在引用变量的时候。具体见后文。
-
关于布尔值的书写格式，即true/false的表达方式。其实playbook中的布尔值类型非常灵活，可分为两种情况：
-
模块的参数： 这时布尔值作为字符串被ansible解析。接受yes/on/1/true/no/off/0/false，这时被ansible解析。例如上面示例中的
update_cache=yes。 -
非模块的参数： 这时布尔值被yaml解释器解析，完全遵循yaml语法。接受不区分大小写的true/yes/on/y/false/no/off/n。例如上面的
gpgcheck=no和enabled=True。建议遵循ansible的官方规范，模块的布尔参数采用yes/no，非模块的布尔参数采用True/False。
3. playbook简单示例
3.1 第一个示例
[root@node1 test]# cat test1.yml
- host: all //在所有受管主机上执行
tasks:
- name: install httpd
yum: //使用yum模块
name: httpd //使用yum安装名为httpd的服务
state: present //状态是安装
3.2 第二个示例
[root@node1 test]# vim test2.yml
[root@node1 test]# cat test2.yml
- hosts: 192.168.100.110 //操作对象是192.168.100.110
name: enabled httpd
tasks:
- name: enabled httpd
service: //使用了service模块
nema: httpd //对httpd服务进行操作
state: started //状态是开启
enabled=yes //设置开机自启
每日一问
运维发布方式有哪些，有什么区别？
线上平稳发布手段：
- 蓝绿部署
- 灰度发布(金丝雀发布)
- 滚动发布
蓝绿部署
首先，这是用于0 downtime应用上线时的一套部署策略。
其次，要知道蓝绿部署无需停机，不停止老版，额外搞一套新版本，等测试发现新版本OK后，删除老版本。
再次，说明下流量管理，在部署新版本之前，需要将部署新版本的流量掐断，全部打到ok的老版本上。
最后，点一下注意使用条件，需要有两倍的机器资源。
Tag: 全量切换
灰度发布(金丝雀发布)
大致过程简述
- 掐断“金丝雀”服务器的流量；
- “金丝雀”服务器更新升级到新版本；
- 在“金丝雀”服务器上对应用进行自动化测试。
- 将“金丝雀”服务器重新配置到LB中（连通性和健康检查）。
- 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
因此，它是对某一产品的发布逐步扩大使用群体范围的一种发布方式，让用户尽早参与，获取用户反馈，完善产品功能，提升产品质量。
对于这个，我比较关注灰度发布如何落地。其实可以归纳为流量控制和数据收集。这样既能做风控又能辅助产品做决策。
-
精确的流量分发控制
需要有确切的策略保证某特征用户访问新版本，某特征用户访问老版本。从产品角度看要做A/B test，必须控制测试样本。
-
做监控
运维: 错误率，吞吐量，延迟，cpu内存消耗 PM: pv, uv
-
需要灵活发布应用
周期可能会持续很久，所以新旧版本会并存。同时，还有可能各个版本需要各自迭代。版本之间能够区分对应的监控日志信息。
Tag: 小批次切换
滚动发布
比蓝绿部署节约资源，但是服务器节点数量多，会很慢。
部署过程简述：
- 发布一台金丝雀，主要做流量验证。
- 需要准备好发布工具和智能LB，平滑的版本替换和流量的拉入拉出。
- 每次发布先将老版本V1流量从LB移除，然后清楚老版本，发新版本V2，再将LB流量接入新版本。
- 一次滚动式发布一般由若干个发布批次组成，每批次发布数量可配置。并且每批次之间有时间间隔，所以导致滚动发布过程比较缓慢。
- 回退，发布的逆过程，所以一样缓慢。
tag: 批量切换
