ansible学习

Posted 2021-02-01

ansible

与salt对比

• 相同
  • 都是为了同时在多台机器上执行相同的命令
  • 都是python开发
• 不同
  • agent（saltstack需要安装、ansible不需要）
  • 配置（salt配置麻烦，ansible基本不用配置）
  • 学习路线（salt比较陡峭，ansible比较平缓）
  • 第三方工具（salt比较少）
  • 开源社区的对接（salt比较少）
  • 现有用户（salt还是ansible少一些）
  • 二次开发扩展的能力（ansible比较差，尤其是2.0以后）
  • 大规模并发（200以内一样，200以上salt会好一些，当然我们也可以对ansible做一些配置使其在200以上追上salt）
  • Windows的支持(salt会好很多)

安装

yum install -y ansible

查看ansible生成的命令，用到的命令

ansible            
ansible-doc        
ansible-galaxy（下载第三方插件）        
 ansible-playbook

查看ansible 安装生成的

rpm -ql ansible |more
/etc/ansible
/etc/ansible/ansible.cfg #配置文件
/etc/ansible/hosts #主要文件

hosts文件详解

cat /etc/ansible/hosts
# This is the default ansible ‘hosts‘ file.
#
# It should live in /etc/ansible/hosts
#
#   - Comments begin with the ‘#‘ character #注释为#
#   - Blank lines are ignored #空白行被忽略
#   - Groups of hosts are delimited by [header] elements #主机组名被写在[]里面
#   - You can enter hostnames or ip addresses #你可以写ip地址也可以写hostnames
#   - A hostname/ip can be a member of multiple groups #一个主机可以被多个主机组包含

可以在hosts文件中填写的内容

 ansible_ssh_host
  ansible通过ssh连接的IP或者FQDN
ansible_ssh_port
  SSH连接端口
ansible_ssh_user
  默认SSH连接用户
ansible_ssh_pass
  SSH连接的密码（这是不安全的，ansible极力推荐使用--ask-pass选项或使用SSH keys）
ansible_sudo_pass
  sudo用户的密码
ansible_connection
  SSH连接的类型：local,ssh,paramiko，在ansible 1.2之前默认是paramiko，后来智能选择，优先使用基于ControlPersist的ssh（支持的前提）
ansible_ssh_private_key_file
  SSH连接的公钥文件

查看ansible的命令帮助

ansible <host-pattern> [options]

-a MODULE_ARGS 模块参数
-m MODULE_NAME 模块名称

-f forks 指定一次执行的机器

-C 测试

--list-hosts 查看运行的机器

-v 输出详细信息

第一个ansible程序

ansible test -m ping

获取文档

ansible-doc --help
-s 指定模块名称
-l 列出所有的模块

操作日志

/var/log/message

命令相关

shell command script
command模块 [执行远程命令]
    ansible all -a ‘echo "hello world"‘
    ansible all -a ‘pwd‘
    ansible all -a ‘echo "oldboy"|passwd --stdin user1‘ #直接输出结果
script模块 [在远程主机执行主控端的shell/python脚本 ]  （使用相对路径）
ansible all -m script -a ‘a.sh‘  #执行本地脚本
ansible all -a ‘ls /‘       #查看文件目录
shell模块 [执行远程主机的shell/python脚本,支持管道]
ansible all -m shell -a ‘echo oldboy|passwd --stdin user1‘  #设置密码
ansible all -m shell -a ‘cat /etc/shadow|grep user1‘    #查看用户
ansible all -m shell -a ‘python a.py‘  #执行远程脚本

文件相关

copy
  dest 目标地址
  src 本地地址  
  mode 权限 wrx/755
  owner  属主
  group  属组
  backup
  content   直接写内容，可以用转移符号
    ansible all -m copy -a ‘dest=/data src=/data/a.txt‘   #复制单个文件
    ansible all -m copy -a ‘src=/etc/init.d dest=/data/‘   
    ansible all -m copy -a ‘src=/etc/init.d/ dest=/data‘  #如果带/则复制里面的内容，不带/则复制目录，如果是目录的话，则会递归复制
    ansible all -m copy -a ‘content="hello world" dest=/data/test.txt‘ 直接输入内容
file
  path
  src
  state
    file file代表拷贝后是文件
    link link代表最终是个软链接
    directory directory代表文件夹
    hard hard代表硬链接
    touch touch代表生成一个空文件
    absent absent代表删除
        ansible all -m file -a ‘dest=/data/html state=directory‘   #创建目录
        ansible all -m file -a ‘dest=/data/html2 state=link src=/etc‘  #创建软链接
        ansible all -m file -a ‘dest=/data/a.txt state=touch‘
        ansible all -m file -a ‘dest=/data/a.txt state=absent‘ 删除
fetch   #远程主机复制到本地,不能指定多个
    dest
    src
    ansible 10.211.55.14 -m fetch -a ‘src=/data/test.txt dest=/data‘

软件相关

pip
ansible all -m pip -a ‘name=django==1.11‘
yum
 name
 state
    absent  #卸载
    installed  #安装
    latest     #安装最新的版本
    present    #安装
    removed    #卸载
        ansible all -m yum -a ‘name=python-pip state=latest‘
        ansible all -m yum -a ‘name=nginx state=latest‘
        ansible all -m yum -a ‘name=nginx state=absent‘

service

name
state
 ansible all -m service -a ‘name=nginx state=started‘
 ansible all -m service -a ‘name=nginx state=stopped‘

cron

name
weekday 周
hour 时
day 天
minute 分钟
month 月
job
state
  absent  #删除
  present  #创建
ansible all -m cron -a ‘name=testjob  minute=1 job=ntpdate‘
ansible all -m cron -a ‘name=testjob  state=absent‘

user

name
password
shell
state
uid
group
groups
update_password 
home
ansible all -m user -a ‘name=usertest‘
ansible all -m user -a ‘name=usertest state=absent‘

group

gid
name
state  #present 创建  absent 删除
system #是否是系统组
ansible all -m group -a ‘name=usertest ‘
ansible all -m group -a ‘name=usertest state=absent‘

playbook 剧本（注意空格）先收集主机

Playbooks 与 ad-hoc 相比,是一种完全不同的运用 ansible 的方式,是非常之强大的.

简单来说,playbooks 是一种简单的配置管理系统与多机器部署系统的基础.与现有的其他系统有不同之处,且非常适合于复杂应用的部署.

Playbooks 可用于声明配置,更强大的地方在于,在 playbooks 中可以编排有序的执行过程,甚至于做到在多组机器间,来回有序的执行特别指定的步骤.并且可以同步或异步的发起任务.

---
- hosts: webservers
  remote_user: root

  tasks:
  - name: ensure apache is at the latest version
    yum:
      name: httpd
      state: latest
  - name: write the apache config file
    template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf

- hosts: databases
  remote_user: root

  tasks:
  - name: ensure postgresql is at the latest version
    yum:
      name: postgresql
      state: latest
  - name: ensure that postgresql is started
    service:
      name: postgresql
      state: started

主机与用户

你可以为 playbook 中的每一个 play,个别地选择操作的目标机器是哪些,以哪个用户身份去完成要执行的步骤（called tasks）

---
- hosts: webservers
  remote_user: root

task list

每一个 play 包含了一个 task 列表（任务列表）.一个 task 在其所对应的所有主机上（通过 host pattern 匹配的所有主机）执行完毕之后,下一个 task 才会执行.有一点需要明白的是（很重要）,在一个 play 之中,所有 hosts 会获取相同的任务指令,这是 play 的一个目的所在,也就是将一组选出的 hosts 映射到 task.
在运行 playbook 时（从上到下执行）,如果一个 host 执行 task 失败,这个 host 将会从整个 playbook 的 rotation 中移除. 如果发生执行失败的情况,请修正 playbook 中的错误,然后重新执行即可.
每个 task 的目标在于执行一个 moudle, 通常是带有特定的参数来执行.在参数中可以使用变量（variables）.
modules 具有”幂等”性,意思是如果你再一次地执行 moudle（译者注:比如遇到远端系统被意外改动,需要恢复原状）,moudle 只会执行必要的改动,只会改变需要改变的地方.所以重复多次执行 playbook 也很安全.
每一个 task 必须有一个名称 name,这样在运行 playbook 时,从其输出的任务执行信息中可以很好的辨别出是属于哪一个 task 的. 如果没有定义 name,‘action’ 的值将会用作输出信息中标记特定的 task.

tasks:
  - name: make sure apache is running
    service: name=httpd state=running

比较特别的两个 modudle 是 command 和 shell ,它们不使用 key=value 格式的参数,而是这样:

tasks:
  - name: disable selinux
    command: /sbin/setenforce 0

使用 command module 和 shell module 时,我们需要关心返回码信息,如果有一条命令,它的成功执行的返回码不是0, 你或许希望这样做:

tasks:
  - name: run this command and ignore the result
    shell: /usr/bin/somecommand || /bin/true

tasks:
  - name: run this command and ignore the result
    shell: /usr/bin/somecommand
    ignore_errors: True

如果 action 行看起来太长,你可以使用 space（空格） 或者 indent（缩进） 隔开连续的一行:

tasks:
  - name: Copy ansible inventory file to client
    copy: src=/etc/ansible/hosts dest=/etc/ansible/hosts
            owner=root group=root mode=0644

在 action 行中可以使用变量.假设在 ‘vars’ 那里定义了一个变量 ‘vhost’ ,可以这样使用它:

tasks:
  - name: create a virtual host file for {{ vhost }}
    template: src=somefile.j2 dest=/etc/httpd/conf.d/{{ vhost }}

检查语法错误

--syntax-check

tags

tags：install

在anible-playbook -t 指定tag

Handlers: 在发生改变时执行的操作

上面我们曾提到过,module 具有”幂等”性,所以当远端系统被人改动时,可以重放 playbooks 达到恢复的目的. playbooks 本身可以识别这种改动,并且有一个基本的 event system（事件系统）,可以响应这种改动.

（当发生改动时）’notify’ actions 会在 playbook 的每一个 task 结束时被触发,而且即使有多个不同的 task 通知改动的发生, ‘notify’ actions 只会被触发一次.

举例来说,比如多个 resources 指出因为一个配置文件被改动,所以 apache 需要重新启动,但是重新启动的操作只会被执行一次.

- name: template configuration file
  template: src=template.j2 dest=/etc/foo.conf
  notify:
     - restart memcached
     - restart apache

‘notify’ 下列出的即是 handlers.
Handlers 也是一些 task 的列表,通过名字来引用,它们和一般的 task 并没有什么区别.Handlers 是由通知者进行 notify, 如果没有被 notify,handlers 不会执行.不管有多少个通知者进行了 notify,等到 play 中的所有 task 执行完成之后,handlers 也只会被执行一次.

handlers:
    - name: restart memcached
      service:  name=memcached state=restarted
    - name: restart apache
      service: name=apache state=restarted

ansible2.2以后可以写listen，我们来监听一个时间，

handlers:
    - name: restart memcached
      service:
        name: memcached
        state: restarted
      listen: "restart web services"
    - name: restart apache
      service:
        name: apache
        state:restarted
      listen: "restart web services"

tasks:
    - name: restart everything
      command: echo "this task will restart the web services"
      notify: "restart web services"

执行一个playbook

ansible-playbook playbook.yml -f 10

Include

Include 指令看起来像下面这样，在一个 playbook 中，Include 指令可以跟普通的 task 混合在一起使用:

tasks:
  - include: tasks/foo.yml

变量

变量命名规则

变量名可以为字母,数字以及下划线.变量始终应该以字母开头

还有其它地方可以获取变量,这些变量是自动发现的,而不是用户自己设置的.

Facts通过访问远程系统获取相应的信息. 一个例子就是远程主机的IP地址或者操作系统是什么. 使用以下命令可以查看哪些信息是可用的:

ansible hostname -m setup

{{ ansible_nodename }}

注册变量

变量的另一个主要用途是在运行命令时,把命令结果存储到一个变量中.不同模块的执行结果是不同的.运行playbook时使用-v选项可以看到可能的结果值.

• • 
    hosts: web_servers
    tasks:

  • shell: /usr/bin/foo
    register: foo_result
    ignore_errors: True
  • shell: /usr/bin/bar
    when: foo_result.rc == 5

命令行中传递变量

除了vars_prompt和vars_files也可以通过Ansible命令行发送变量.如果你想编写一个通用的发布playbook时则特别有用,你可以传递应用的版本以便部署:

ansible-playbook release.yml --extra-vars "version=1.23.45 other_variable=foo"

其它场景中也很有用,比如为playbook设置主机群组或用户.

---

- hosts: ‘{{ hosts }}‘
  remote_user: ‘{{ user }}‘

  tasks:
     - ...

ansible-playbook release.yml --extra-vars "hosts=vipers user=starbuck"

变量的来源

• 通过setup获取

• 用户自定义

  • 通过命令行传递 -e

  • playbook传递

  • 
    vars:

  • name:name-value
    name2:name2-value

  hosts配置文件中定义

  ? 直接在主机后面定义

  [hostgourpname:vars]
  name:name-value

访问复杂变量数据

有些提供的facts,比如网络信息等,是一个嵌套的数据结构.访问它们使用简单的 {{ foo }} 语法并不够用,当仍然很容易.如下所示:

{{ ansible_eth0["ipv4"]["address"] }}
{{ ansible_eth0.ipv4.address }}

条件判断

when: 条件==“条件”

循环

通常你想在一个任务中干很多事,比如创建一群用户,安装很多包,或者重复一个轮询步骤直到收到某个特定结果.

标准循环

为了保持简洁,重复的任务可以用以下简写的方式:

- name: add several users
  user: name={{ item }} state=present groups=wheel
  with_items:
     - testuser1
     - testuser2

嵌套循环

- hosts: all
  remote_user: root
  tasks:
  - name: add user
    user: name={{ item[0] }} groups={{ item[1] }}
    with_nested:
    - ["old1","old2"]
    - ["nginx,docker"]

Ansible Galaxy

Ansible Galaxy 是一个自由网站，网站提供所有类型的由社区开发的 roles，这对于实现你的自动化项目是一个很好的参考。网站提供这些 roles 的排名、查找以及下载。

应用实例

你现在已经学过 tasks 和 handlers，那怎样组织 playbook 才是最好的方式呢？简单的回答就是：使用 roles ! Roles 基于一个已知的文件结构，去自动的加载某些 vars_files，tasks 以及 handlers。基于 roles 对内容进行分组，使得我们可以容易地与其他用户分享 roles 。
如果 roles/x/tasks/main.yml 存在, 其中列出的 tasks 将被添加到 play 中
如果 roles/x/handlers/main.yml 存在, 其中列出的 handlers 将被添加到 play 中
如果 roles/x/vars/main.yml 存在, 其中列出的 variables 将被添加到 play 中
如果 roles/x/meta/main.yml 存在, 其中列出的 “角色依赖” 将被添加到 roles 列表中 (1.3 and later)
所有 copy tasks 可以引用 roles/x/files/ 中的文件，不需要指明文件的路径。
所有 script tasks 可以引用 roles/x/files/ 中的脚本，不需要指明文件的路径。
所有 template tasks 可以引用 roles/x/templates/ 中的文件，不需要指明文件的路径。
所有 include tasks 可以引用 roles/x/tasks/ 中的文件，不需要指明文件的路径。

production                # inventory file for production servers 关于生产环境服务器的清单文件
stage                     # inventory file for stage environment 关于 stage 环境的清单文件

group_vars/
   group1                 # here we assign variables to particular groups 这里我们给特定的组赋值
   group2                 # ""
host_vars/
   hostname1              # if systems need specific variables, put them here 如果系统需要特定的变量,把它们放置在这里.
   hostname2              # ""

library/                  # if any custom modules, put them here (optional) 如果有自定义的模块,放在这里(可选)
filter_plugins/           # if any custom filter plugins, put them here (optional) 如果有自定义的过滤插件,放在这里(可选)

site.yml                  # master playbook 主 playbook
webservers.yml            # playbook for webserver tier Web 服务器的 playbook
dbservers.yml             # playbook for dbserver tier 数据库服务器的 playbook

roles/
    common/               # this hierarchy represents a "role" 这里的结构代表了一个 "role"
        tasks/            #
            main.yml      #  <-- tasks file can include smaller files if warranted
        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

    webtier/              # same kind of structure as "common" was above, done for the webtier role
    monitoring/           # ""
    fooapp/               # ""

site.yml

在 site.yml 中,我们包含了一个定义了整个基础设施的 playbook.注意这个 playbook 是非常短的, 因为它仅仅包含了其他 playbooks.记住, playbook 不过就是一系列的 plays:

---
# file: site.yml
- include: webservers.yml
- include: dbservers.yml

在诸如 like webservers.yml 的文件中(同样也在顶层结构),我们仅仅将 Web 服务器组与对应的 role 行为做映射.同样值得注意的是这也非常的短小精悍.例如:

---
# file: webservers.yml
- hosts: webservers
  roles:
    - common
    - webtier

理念是我们能够通过 “运行”(running) site.yml 来选择整个基础设施的配置.或者我们能够通过运行其子集 webservers.yml 来配置. 这与 Ansible 的 “–limit” 类似,而且相对的更为显式:

ansible-playbook site.yml --limit webservers
ansible-playbook webservers.yml

接下来的示例任务文件展示了一个 role 是如何工作的.我们这里的普通 role 仅仅用来配置 NTP,但是如果我们想的话,它可以做更多:

---
# file: roles/common/tasks/main.yml

- name: be sure ntp is installed
  yum: pkg=ntp state=installed
  tags: ntp

- name: be sure ntp is configured
  template: src=ntp.conf.j2 dest=/etc/ntp.conf
  notify:
    - restart ntpd
  tags: ntp

- name: be sure ntpd is running and enabled
  service: name=ntpd state=running enabled=yes
  tags: ntp

这是个处理文件样例.作为一种审核,它只有当特定的任务报告发生变化时会被触发,并在每个 play 结束时运行:

---
# file: roles/common/handlers/main.yml
- name: restart ntpd
  service: name=ntpd state=restarted