hello云胜

技术与生活

0%

ansible playbook

发表于 更新于 分类于

ansible playbook

ansible命令适合执行简单的操作。如果要完成一个复杂的部署，需要很多ansible操作，写起来会很乱。

所以有了ansible-playbook

把一件事切分成很多任务，有序的组织起来

目录结构解读

官方给的playbook工程的最佳实践

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
production                # 生产环境的服务器清单
stage                     # stage环境的服务器清单

group_vars/
   group1                 # 这里我们给特定的组赋值
   group2                 # ""
host_vars/
   hostname1              # 主机变量
   hostname2              # ""

library/                  # 如果有自定义的模块,放在这里(可选)
filter_plugins/           # 如果有自定义的过滤插件,放在这里(可选)

site.yml                  # 主 playbook文件
webservers.yml            # Web 服务器的 playbook
dbservers.yml             # 数据库服务器的 playbook

roles/ 
    common/               # 这个目录代表了一个名为common的 "role"
        tasks/            #
            main.yml      #  <-- tasks file can include smaller files if wanted
        handlers/         #
            main.yml      #  <-- handlers file
        templates/        #  <-- files for use with the template resource
            ntp.conf.j2   #  <------- templates end in .j2
        files/            #
            bar.txt       #  <-- files for use with the copy resource
            foo.sh        #  <-- script files for use with the script resource
        vars/             #
            main.yml      #  <-- variables associated with this role
        defaults/         #
            main.yml      #  <-- default lower priority variables for this role
        meta/             #
            main.yml      #  <-- role dependencies

    webserver/              # 像上面的common一样，这个目录代表了一个名为webserver的 "role"
    monitoring/           # ""
    fooapp/               # ""

第一眼看起来很乱，不要慌，我们一个一个看就清晰了。看完这几个文件，也就初步学会playbook了。

其中重点要看的是roles目录！！！

服务器清单文件

比如这里的production和stage文件。在ansible中常称为inventory file(清单文件),即服务器清单

可以自己根据需要创建。

注意：自己创建的这个清单文件在后面ansible-playbook使用时要加上 -i 指定使用

否则使用的是默认的/etc/ansible/hosts这个文件

我这里创建一个名为redis_hosts的清单文件，内容如下

1
2
[prod]
10.66.77.88

[prod]是组名，用中括号括起，组名里不要出现特殊字符，_可以用

下面是在组内的服务器地址。这是最简单的例子。

配置主机地址的写法

只写IP

这种就是上面例子中的方式。这种方式要求提前将ssh-key发送到被操作主机，保证ansible主机对被操作主机的ssh权限

IP + user

1
10.66.77.88 ansible_ssh_user=“redis” ansible_ssh_pass=“redispass”

把登录用户和密码信息配上

主机别名 + ip + user

1
redisserver ansible_ssh_host=10.66.77.88 ansible_ssh_user=“redis” ansible_ssh_pass=“redispass”

可以给服务器起一个便于识别的别名

使用ansible_ssh_pass密码这种方式不安全，通常使用的是

主机别名 + ip 方式

1
redisserver ansible_ssh_host=10.66.77.88

其他内置的登录参数

1
2
3
4
5
6
7
8
9
ansible_ssh_host 
ansible_ssh_port
ansible_ssh_user
ansible_ssh_pass
ansible_sudo_pass
ansible_connection
ansible_ssh_private_key_file
ansible_shell_type
ansible_python_interpreter

使用方式如下,比如改了ssh的端口

1
2
[prod]
redis1 ansible_ssh_host=10.66.77.88 ansible_ssh_port=50022 ansible_ssh_user=root

变量

playbook中可以使用的变量，从来源上来分，可以分为3大类

1.内置变量

ansible中有一些内置变量可供我们使用，当然，这些内置变量的变量名是被ansible保留的，我们定义变量时不能使用这些变量名

ansible_version ansible的版本号
hostvars hostvars可以在操作当前主机时获取到其他主机中的信息。 ““
inventory_hostname 被操作的当前主机的主机名称 这里所说的主机名称并不是linux系统的主机名，而是对应主机在清单中配置的名称
inventory_hostname_short 被操作的当前主机的主机的简短名称
play_hosts 当前play所操作的所有主机的主机名列表
groups 清单中”所有分组”的”分组信息
group_names 当前主机所在分组的组名
inventory_dir 清单文件的存放路径 默认的清单文件/etc/ansible/hosts

setup模块获取的fact信息，其中就包含了大量的变量，可以直接调用

Playbook在执行时默认就会收集目标主机的facts信息并存为变量，可以指定变量来直接调用。当在Playbook中使用facts变量时，就不能将gather_facts设为no。只有被收集过的facts信息才能被后面的play引用到

可以执行下setup看看,会返回超级多的信息

1
ansible hostname -m setup

2.Playbook文件中的变量

按优先级排序

命令行传入

ansible-playbook命令的命令行中的-e VARS, --extra-vars=VARS，这样就可以直接把自定义的变量传入

这里的VARS是 key=value的形式

playbook文件中指定变量文件

举例

1
2
3
- hosts: websrvs
  vars_files:
    - vars.yml

vars.yml是自己创建的一个变量文件

playbook文件中定义的变量

在playbook文件中可以通过vars关键字定义变量

举例

1
2
3
4
- hosts: websrvs
  vars:
    src_file: files/ports.conf
    dest_file: /etc/apache2/ports.conf

host_vars目录

用于存放host相关的变量

和组名同理。主机变量名和这里创建的文件名必须一致。

主机变量

在清单文件中可以给机条目上可以加变量，以便后面的playbook执行时使用，比如加一个paasword的变量

1
2
[prod]
10.66.77.88 password=UYSbdyf

group_vars目录

用于存放group相关的变量

在上面的inventory 文件中，我们定义过组变量

如果组变量可以抽取出来多个组公用，就可以放在group_vars下。

比如上面我给名叫prod的组定义过变量。现在要抽取出来，就要在group_vars目录下创建一个名为prod的文件

把变量放进去。

所以，文件名和组名是对应的。

文件内容格式如下：

1
2
---
password: UYSbdyf

另外group_vars目录下创建的名为all的文件有特殊地位。对主机清单中的所有主机有效

主机组变量

在清单文件中也可以给主机组加变量

1
2
3
4
[prod]
10.66.77.88
[prod:vars]
password=UYSbdyf

3.role的vars

在具体的roles/XXRole/ 目录下的vars目录里也可以定义变量。

roles/XXRole/ 目录下的default目录里也可以定义变量。

这两个目录的变量都是属于这个role的，只能传给这个role

playbook主文件

比如这里的site.yml

主playbook文件，我们开始执行一个playbook就是从这个主文件开始

1
ansible-playbook site.yml

这个主文件不是一定要叫site.yml。随便起名。根据你自己的业务来起名即可。比如后面的webservers.yml和dbservers.yml。

我们这里写一个redis.yml,用来部署redis

1
2
3
4
- hosts: prod
  remote_user: root
  roles:
  - redis

主文件的内容就是指定哪些主机进行什么操作。用什么用户等等。

也可以直接指定tasks

1
2
3
4
5
6
- hosts: prod
  remote_user: root
  tasks:
  	// 直接把要做的事写在这
  	// 适合比较简单的任务
  	// 不需要再去定义role
1
ansible-playbook -i redis_hosts redis.yml

roles

roles是整个playbook的重点。role可以理解为做一件事的一个角色。

roles 用于层次性、结构化地组织playbook。

roles目录下面你根据自己的业务，定义多个子目录，对应完成某件工作。

比如这里的common,webserver,monitoring,fooapp等

每个role目录下能够根据层次型结构自动装载变量文件vars、task以及handlers等

tasks目录

tasks下的文件就是完成工作的一个个具体动作，至少应该有一个名为main.yml的文件

playbook执行时默认就找这个main.yml。可以定义其他的yml文件，在main.yml引入

比如

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
---
- name: System Add group {{ redisgroup }}
  group: gid={{ usergid }} name={{ redisgroup }} state=present system=yes

- name: System Add user {{ redisuser }}
  user:
    name: '{{ redisuser }}'
    ...省略

- name: create redis database directory
  file: path='/data/redis_data' state=directory mode='0755' owner={{ redisuser }} group={{ redisgroup }}

- name: create logs directory
  file: path='/data/logs/redis' state=directory mode='0755' owner={{ redisuser }} group={{ redisgroup }}

- name: yum install {{ pkgname }}
  yum: name={{ pkgname }} state=present
  tags: install_app

- name: Template Set {{ pkgname }} Config Files
  template:  src='redis.conf.j2' dest='/etc/redis.conf' owner={{ redisuser }} group={{ redisgroup }} mode='0755'
  notify:
    - restart redis service

通过-name来说明这个动作的作用

可以看到里面使用了变量。用包围的。这些变量放在vars文件夹下。

其中的动作Action，group，user，file，yum等就是我们上一篇中说的ansible的内置模块

有时我们也会看到这样的写法

1
2
3
4
5
6
7
- name: 安装supervisor
  ansible.builtin.yum:
    name: '{{ item }}'
    state: present
  loop: 
    - epel-release
    - supervisor

其实这里的ansible.builtin.yum和yum是一样的

ansible.builtin.yum是内置yum模块的完整名称。yum是一种简写形式而已。在大多数情况下，可以互换使用，但为了确保兼容性和避免混淆，建议在编写playbook时使用完整的模块名

playbook对task的执行时从上到下按顺序一个一个执行的。执行的结果是幂等的。这个特性非常使用。

对一台客户机多次执行playbook是安全的。

为什么是幂等的呢？

仔细观察task的动作，会发现其对动作的描述都是声明式的。

比如 yum: name= state=present

有一个state值是present，表明我们期望达到的效果是安装了这个包。所以ansible会采取的操作是先检查有没有安装，没有安装才进行安装。

task中的语法

when

1
2
3
- name: install conf file to centos7
  template: src=files/nginx.conf.c7.j2
  when: ansible_distribution_major_version == "7"

循环

对迭代项的引用，固定变量名为”item”

1
2
3
4
5
6
- name: unstall web packages
  yum: name={{ item }} state=absent
  with_items:
  - httpd
  - php
  - php-mysql

字典

1
2
3
4
5
6
- name: add some users
  user: name={{ item.name }} group={{ item.group }} state=present
  with_items:
    - { name: 'user11', group: 'group11' }
    - { name: 'user12', group: 'group12' }
    - { name: 'user13', group: 'group13' }

split

通过指定分隔符和切分后的对象序号（序号从0开始），来取得变量值中需要的部分。

举例

1
2
3
- name: split
  debug:
    msg: "eth0的ipv4地址中的最后一个数字: {{ ansible_facts.eth0.ipv4.address.split('.')[-1] }}"

template

在这个例子中，还用到了template模块。它会去找templates目录下的模板文件，进行变量替换后，放到客户机指定的目录下。

notify

还有一个notify，这个特性和下面要讲到的handler有关

作用就是某任务的状态在运行后为changed时，可通过“notify”通知给相应的handlers；

比如我们这里的

1
2
3
4
- name: Template Set {{ pkgname }} Config Files
  template:  src='redis.conf.j2' dest='/etc/redis.conf' owner={{ redisuser }} group={{ redisgroup }} mode='0755'
  notify:
    - restart redis service

当运行这个task的结果是changed时，即redis.conf内容变了的情况下，就会触发restart redis service这个handler。

这个handler可以定义在handlers目录里

tags

任务可以通过“tags“打标签，而后可在ansible-playbook命令上使用-t指定进行调用；

比如上面例子中的

1
2
3
- name: yum install {{ pkgname }}
  yum: name={{ pkgname }} state=present
  tags: install_app

我们可以这样使用

1
ansible-playbook redis.yml -t install_app

就会直接只执行install_app这一步

handlers目录

应当包含一个main.yml文件，用于定义此角色用到的各handlers，

在handler中可以使用inclnude引入其它的handlers文件；

handler是干嘛的？

handler是用来描述当关注的资源的状态发生变化时要采取的操作。

直白的讲就是由特定条件触发的任务

比如main.yml中这样写

1
2
3
handlers:　　#注意，前面没有-，是两个空格
  - name: restart redis service
    service: name={{ pkgname }} state=restarted

这里的name要注意，它的值必须和上面task文件中norify的值一致！！，不是随便写的。

也就是说，当task中的redis.conf文件修改了之后，会触发notify这个名叫restart redis service的handler

这个handler执行的操作就是调用service模块，对某个service进行restart

templates目录

存放模板文件。

playbook使用jinja2模板文件。Jinja2是python的一种模板语言，以Django的模板语言为原本。

比如我们讲redis.conf作为一个模板配置文件redis.conf.j2

1
2
3
4
5
6
7
8
bind {{ bindip }}
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize {{ mode }}
...

模板文件中的变量从vars目录下取

files目录

用来存放会用到的文件。

比如script模块用到的sh脚本文件。需要copy到目标主机的安装包等。

vars目录

存在自定义的变量。

应当包含一个main.yml文件

注意，变量不能有下划线

defaults目录

应当包含一个main.yml文件,也是用于为当前role定义变量。只不过设定的是默认值。优先级低于vars。

meta目录

应当包含一个main.yml文件，用于定义此角色的特殊设定及其依赖关系；ansible1.3及其以后的版本才支持；

library 和 filter_plugins

ansible支持自定义扩展功能，新手先不用管这个

执行

执行就简单了，通过ansible-playbook redis.yaml 命令运行即可

1
2
3
4
5
6
7
8
9
10
# ansible-playbook -h
#ansible-playbook常用选项：
--check  or -C    #只检测可能会发生的改变，但不真正执行操作
--list-hosts      #列出运行任务的主机
--list-tags       #列出playbook文件中定义所有的tags
--list-tasks      #列出playbook文件中定义的所以任务集
--limit           #主机列表 只针对主机列表中的某个主机或者某个组执行
-f                #指定并发数，默认为5个
-t                #指定tags运行，运行某一个或者多个tags。（前提playbook中有定义tags）
-v                #显示过程  -vv  -vvv更详细