Ansible之Playbook详解、案例

绝地灬酷狼 2022-03-29 13:11 303阅读 0赞

### **playbook-剧本 介绍** ###

playbooks是 一个不同于使用Ansible命令行执行方式的模式，其功能更强大灵活。简单来说，playbook是一个非常简单的配置管理和多主机部署系统，不同于任何已经存在的模式，可作为一个适合部署复杂应用程序的基础。Playbook可以定制配置，可以按照指定的操作步骤有序执行，支持同步和异步方式。值得注意的是playbook是通过YAML格式来进行描述定义的。

*  核心元素

> Tasks：任务，由模板定义的操作列表  
> Variables：变量  
> Templates：模板，即使用模板语法的文件  
> Handlers：处理器 ，当某条件满足时，触发执行的操作  
> Roles：角色

*  **hosts和users介绍**
 *  在playbook中的每一个play都可以选择在哪些服务器和以什么用户完成，hosts一行可以是一个主机组、主机、多个主机，中间以冒号分隔，可使用通配模式。其中remote\_user表示执行的用户账号。
    
        ---
        - hosts: abc               #指定主机组，可以是一个或多个组。
            remote_user: root                #指定远程主机执行的用户名
 *  指定远程主机sudo切换用
    
        # vim ping.yml
        ---
        - hosts: abc
            remote_user: root            
            become: yes                #2.6版本以后的参数，之前是sudo，意思为切换用户运行
            become_user: mysql          #指定sudo用户为mysql
        
        执行playbook
        # ansible-playbook ping.yml -K
 *  **Tasks list 和action介绍**

> 1：Play的主体部分是task列表，task列表中的各任务按次序逐个在hosts中指定的主机上执行，即在所有主机上完成第一个任务后再开始第二个任务。  
> 在运行playbook时（从上到下执行），如果一个host执行task失败，整个tasks都会回滚，请修正playbook 中的错误，然后重新执行即可。  
> Task的目的是使用指定的参数执行模块，而在模块参数中可以使用变量，模块执行时幂等的，这意味着多次执行是安全的，因为其结果一致。  
> 2：每一个task必须有一个名称name，这样在运行playbook时，从其输出的任务执行信息中可以很好的辨别出是属于哪一个task的。如果没有定义name，‘action’的值将会用作输出信息中标记特定的task。  
> 3：定义一个task，常见的格式:”module: options” 例如：yum: name=httpd  
> 4：ansible的自带模块中，command模块和shell模块无需使用key=value格式

*  **常用命令**
 *  ansible-playbook \[yaml文件名、也可以yml结尾\]
 *  例如：ansible-playbook a.yml
 *  参数：
    
    > \-k(–ask-pass) 用来交互输入ssh密码  
    > \-K(-ask-become-pass) 用来交互输入sudo密码  
    > \-u 指定用户
    
        # ansible-playbook a.yml --syntax-check    #检查yaml文件的语法是否正确
            # ansible-playbook a.yml --list-task       #检查tasks任务
            # ansible-playbook a.yml --list-hosts      #检查生效的主机
            # ansible-playbook a.yml --start-at-task='Copy Nginx.conf'     #指定从某个task开始运行
 *  示例
    
        # vim a.yml
        ---
        - hosts: 192.168.200.129                  //指定主机
            remote_user: root                         //指定在被管理的主机上执行任务的用户
            tasks:                                            //任务列表↓
             - name: disable selinux                //任务名关闭防火墙
               command: '/sbin/setenforce 0'    //调用command模块 执行关闭防火墙命令
             - name: start httpd                         //任务名 开启httpd
               service: name=httpd state=started         //调用service模块 开启httpd 服务
        # ansible-playbook a.yml --syntax-check    #检查yaml文件的语法是否正确
        # ansible-playbook a.yml

![Ansible之Playbook详解、案例][Ansible_Playbook]  
![Ansible之Playbook详解、案例][Ansible_Playbook 1]

*  play中只要执行命令的返回值不为0，就会报错，tasks停止，可以添加下面
 *  ignore\_errors: True \#忽略错误，强制返回成功

![Ansible之Playbook详解、案例][Ansible_Playbook 2]  
![Ansible之Playbook详解、案例][Ansible_Playbook 3]

*  **Handlers介绍**
 *  andlers也是一些task的列表，和一般的task并没有什么区别。
 *  是由通知者进行的notify，如果没有被notify，则Handlers不会执行，假如被notify了，则Handlers被执行
 *  不管有多少个通知者进行了notify，等到play中的所有task执行完成之后，handlers也只会被执行一次  
     
 *  **示例**

![Ansible之Playbook详解、案例][Ansible_Playbook 4]

*  **引用变量**
 *  使用：vars: 添加变量

![Ansible之Playbook详解、案例][Ansible_Playbook 5]

*  直接引用Ansible变量
 *  ansible\_all\_ipv4\_addresses 获取IP

![Ansible之Playbook详解、案例][Ansible_Playbook 6]

*  引用主机变量
 *  在组的主机后面添加变量
    
        # vim /etc/ansible/hosts
    
    ![Ansible之Playbook详解、案例][Ansible_Playbook 7]
    
        # vim c.yml
        # ansible-playbook c.yml  //执行这个剧本

![Ansible之Playbook详解、案例][Ansible_Playbook 8]

*  查看这个生成的文件  
    ![Ansible之Playbook详解、案例][Ansible_Playbook 9]

**条件判断**

*  when的值是一个条件表达式，如果条件判断成立，这个task就执行，如果判断不成立，则task不执行
 *  如果需要根据变量、facts（setup）或此前任务的执行结果来作为某task执行与否的前提时要用到条件测试，在Playbook中条件测试使用when子句。
 *  在task后添加when子句即可使用条件测试：when子句支持jinjia2表达式或语法，例如：

![Ansible之Playbook详解、案例][Ansible_Playbook 10]

*  **多条件判断**

![Ansible之Playbook详解、案例][Ansible_Playbook 11]

*  **组条件判断**

![Ansible之Playbook详解、案例][Ansible_Playbook 12]

*  **自定义条件判断**  
    ![Ansible之Playbook详解、案例][Ansible_Playbook 13]

*  **迭代**
 *  有需要重复性执行的任务时，可以使用迭代机制。其使用格式为将需要迭代的内容定义为item变量引用，并通过with\_items语句指明迭代的元素列表即可。
 *  示例：  
    ![Ansible之Playbook详解、案例][Ansible_Playbook 14]

![Ansible之Playbook详解、案例][Ansible_Playbook 15]

*  **Templates介绍**
 *  Jinja是基于Python的模板引擎。template类是Jinja的另一个重要组件，可以看作一个编译过的模块文件，用来生产目标文本，传递Python的变量给模板去替换模板中的标记。
    
        # scp root@192.168.175.130:/etc/httpd/conf/httpd.conf ./templates      //复制被管理端的配置文件到本地
        # vim templates/httpd.conf      //在管理端讲配置文件要修改的地方定义变量
        Listen {
             {http_port}}
        ServerName {
             {server_name}}
        MaxClients {
             {access_num}}
 *  在/etc/ansible/hosts 添加变量
    
        # vim /etc/ansible/hosts
        [abc]
        192.168.200.129 http_port=192.168.200.129:80 access_num=100 server_name="www.yun.com:80"
        # vim apache.yml
        # ansible-playbook apache.yml    #然后执行脚本  然后去abc组的主机上查看下配置文件是否已经改了

![Ansible之Playbook详解、案例][Ansible_Playbook 16]

*  **Tags介绍**
 *  在一个playbook中，我们一般会定义很多个task，如果我们只想执行其中的某一个task或多个task时就可以使用tags标签功能了

![Ansible之Playbook详解、案例][Ansible_Playbook 17]

# ansible-playbook hosts.yml --tags="only"   //只执行这个标签上面的任务

*  事实上，不光可以为单个或多个task指定同一个tags。playbook还提供了一个特殊的tags为always。作用就是当使用always当tags的task时，无论执行哪一个tags时，定义有always的tags都会执行。
    
    ![Ansible之Playbook详解、案例][Ansible_Playbook 18]
    
    执行下面命令
    
        # ansible-playbook hosts.yml --tags="only"    //去被管理主机上查看文件创建情况 2个tags都会执行

[Ansible_Playbook]: /images/20220329/62f0ceae116c492fafc7a91852cbb759.png
[Ansible_Playbook 1]: /images/20220329/9e70d47ec07a47338be58c7e8d8c2d8e.png
[Ansible_Playbook 2]: /images/20220329/6e5eb7a2b2e048a5a80101e768e3c2c3.png
[Ansible_Playbook 3]: /images/20220329/82b4eb0a627a484d8a73569d7aa7b417.png
[Ansible_Playbook 4]: /images/20220329/7380188026574ca1ab4b10621544ed5c.png
[Ansible_Playbook 5]: /images/20220329/00d32b7316c143499e92e487d4f6b4d7.png
[Ansible_Playbook 6]: /images/20220329/6278c6e98f9d4612aababbfd4c36d6aa.png
[Ansible_Playbook 7]: /images/20220329/9a1c4cd7c9214d17911c4f7b90f28b05.png
[Ansible_Playbook 8]: /images/20220329/21a6d509e39d442286368b75082d4820.png
[Ansible_Playbook 9]: /images/20220329/559c90dc2925495385a25fe77faa29f2.png
[Ansible_Playbook 10]: /images/20220329/bc344eb348a24aa48a5827ff503c5ae0.png
[Ansible_Playbook 11]: /images/20220329/65edcfcc49bd44f99a65ad797e3b0966.png
[Ansible_Playbook 12]: /images/20220329/b717d816643c45458b3930972be3ed5e.png
[Ansible_Playbook 13]: /images/20220329/6bdc1c28484c44a583e802909f75a401.png
[Ansible_Playbook 14]: /images/20220329/2998ddb3f645475e920cc9bc0fdbe548.png
[Ansible_Playbook 15]: /images/20220329/a722312e6a2140a59b1095f2b995db0a.png
[Ansible_Playbook 16]: /images/20220329/edfe51fc33fb443ab65beb6d675955d4.png
[Ansible_Playbook 17]: /images/20220329/71f1f8fd22b144a8bde999c089d1e866.png
[Ansible_Playbook 18]: /images/20220329/401d2fd94a6849fe8054e4e7db4ff4f3.png