The basic use of Ansible's playbook and Quick Start

1. What are the benefits of using the playbook
2. Recognizes playbook (automatic deployment nginx)
3.YAML grammar
4.playbook file structure
5. Perform operation (handlers) when changing
6. Mission Control (Tags)
7.playbook file debugging
8. Case : automatically deploy Tomcat
9.Playbook variable definition and use

10. playbok file multiplexing

1. What are the benefits of using the playbook

Ansible真正的能力在于使用playbook,也就称为剧本
当我们在某个目录下执行某个命令的时候，那么我们可以使用ansible的ad hoc的模式快速执行，而无不虚编写文件或者剧本，但是对于配置的管理和应用的部署，通常有很多的操作，单独的去写ad hoc命令麻烦很多，而且ad hoc适用于简单命令的执行，所以我们使用playbook去完成，如果ansible是工作中用到的工具，那么ploybook就是相当于你使用ansible的说明书，而你的主机就是原材料，写playbook就像写说明书一样，它是一个按顺序执行的一个过程，playbook和ad hoc完全不是一种模式，并且功能强大

Playbook features
易读的编排语言：它是用最主流的yaml格式去编写的来实现应用的编排，非常适合配置和应用部署，也非常适合部署复杂的任务，我们可以通过声明式的内容将复杂的工作通过playbook进行编排。

This -syntax-check is to check the syntax of the playbook

[root@ansible playbook-test]# ansible-playbook nginx.yaml   --syntax-check 

playbook: nginx.yaml
[root@ansible playbook-test]# vim nginx.yaml 
[root@ansible playbook-test]# cat nginx.yaml 

---
 - hosts: webservers
  vars:
    hello: Ansible
  tasks:
  - name: Add repo
    yum_repository:
      name: nginx
      description: nginx repo
      baseurl: http://nginx.org/packages/centos/7/$basearch/
      gpgcheck: no
      enabled: 
  - name: Install nginx
    yum:
      name: nginx
      state: latest
  - name: Copy nginx configuration file
    copy:
      src: ./site.conf
      dest: /etc/nginx/conf.d/site.conf
  - name: Start nginx
    service:
      name: nginx
      state: started
  - name: Create wwwroot directory
    file:
      dest: /var/www/html
      state: directory
  - name: Create test page index.html
shell: echo "hello {{hello}}" > /var/www/html/index.html
[root@ansible playbook-test]# ls
nginx.yaml  site.conf

[root@ansible playbook-test]# vim site.conf
server {
    listen 80;
    server_name devops;
    location / {
        root   /var/www/html;
index index.html; }
}

Execution playbook
[root@ansible playbook-test]# ansible-playbook nginx.yaml
view the process has been started

[root@ansible playbook-test]# ansible webservers -m shell -a "ps -ef |grep nginx"
10.4.7.22 | SUCCESS | rc=0 >>
root      10713      1  0 16:46 ?        00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx     10714  10713  0 16:46 ?        00:00:00 nginx: worker process
root      10849  10848 10 16:49 pts/1    00:00:00 /bin/sh -c ps -ef |grep nginx
root      10851  10849  0 16:49 pts/1    00:00:00 grep nginx

10.4.7.21 | SUCCESS | rc=0 >>
root      10953      1  0 16:46 ?        00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx     10954  10953  0 16:46 ?        00:00:00 nginx: worker process
root      11088  11087  0 16:49 pts/1    00:00:00 /bin/sh -c ps -ef |grep nginx
root      11090  11088  0 16:49 pts/1    00:00:00 grep nginx

YAML syntax
indention hierarchy
does not support tabs "tab" indents
typically begins indented two spaces
after a character indented spaces, such as colons, commas, etc.
"---" indicates YAML format, a file the beginning of the
"#" comment
perform operations (handlers) when changing the processor
is mainly used when you change out an operation, it can help you trigger another task

• hosts: webservers
  gather_facts: NO
  This information is collected by the list of hosts, will be very time-consuming, it is the general disable the swap, so would improve the efficiency of our playbook

Automatic deployment of Tomcat
1. Install the JDK
2. Download tomcat package
3. Unzip Tomcat
4. start up

Tomcat installation

---
- hosts: webservers
  gather_facts: no
  vars:
    tomcat_version: 9.0.29
    tomcat_install_dir: /usr/local

  tasks:
    - name: Install java-1.8.0-openjdk.x86_64
      shell: yum -y install java-1.8.0-openjdk.x86_64 state=present

    - name: Download tomcat
      get_url: url=http://mirrors.tuna.tsinghua.edu.cn/apache/tomcat/tomcat-9/v9.0.29/bin/apache-tomcat-9.0.29.tar.gz dest=/tmp
    - name: Unarchive tomcat-{{ tomcat_version }}.tar.gz
      unarchive:
        src: /tmp/apache-tomcat-{{ tomcat_version }}.tar.gz
        dest: "{{ tomcat_install_dir }}"
        copy: no

    - name: Start tomcat
      shell: cd {{ tomcat_install_dir }} &&
             mv apache-tomcat-{{ tomcat_version }} tomcat8 &&
             cd tomcat8/bin && nohup ./startup.sh &
[root@ansible tomcat-playbook]# ansible-playbook tomcat.yaml
[root@ansible tomcat-playbook]# ansible webservers -m shell -a "ps -ef |grep tomcat"

Playbook variable definition and use

1. Command Line
2. Defined in the inventory in
3. Defined in the playbook in
4. Defined role in
5. Register variables (register)
6. System variable information (facts)

Command line defines a variable
list the main variable information

[root@ansible tomcat-playbook]# ansible-playbook --list-tags tomcat.yaml 

playbook: tomcat.yaml

  play #1 (webservers): webservers  TAGS: []
      TASK TAGS: []
[root@ansible tomcat-playbook]# ansible-playbook --list-tasks tomcat.yaml 

playbook: tomcat.yaml

  play #1 (webservers): webservers  TAGS: []
    tasks:
      Install java-1.8.0-openjdk.x86_64 TAGS: []
      Download tomcat   TAGS: []
      Unarchive tomcat-{{ tomcat_version }}.tar.gz  TAGS: []
      Start tomcat  TAGS: []

print debug module during the execution of the statement, and can be used to debug variable or expression, without having to stop playbook.

[root@ansible tomcat-playbook]# vim 1.yaml

---
- hosts: webservers
  gather_facts: no
  remote_user: root

  tasks:
  - name: test var
    debug: msg="{{work_dir}}"
[root@ansible tomcat-playbook]# ansible-playbook 1.yaml -e work_dir=/usr/local

This variable is defined also have certain requirements, variable names beginning with the letter to

Another definition of the inventory in
the / etc / ansible / hosts to define the variables, variables passed to a set of different host or multiple hosts
may be written separately under /etc/ansible/group_vars/webservers.yml, it will default which group you read inside the variable, the model is more convenient to yml
http_port: 8090
server_name: xiabanle

[root@ansible group_vars]# ansible webservers -a "echo {{http_port}}"
10.4.7.22 | SUCCESS | rc=0 >>
8090

10.4.7.21 | SUCCESS | rc=0 >>
8090

[root@ansible group_vars]# ansible webservers -a "echo {{server_name}}"
10.4.7.22 | SUCCESS | rc=0 >>
xiabanle

10.4.7.21 | SUCCESS | rc=0 >>
xiabanle

Debug module used to define variables playbook

---
- hosts: webservers
  gather_facts: no
  remote_user: root
  vars:
    - work_dir: /usr/local
    - nginx_version: 1.16

  tasks:
  - name: Install nginx
debug: msg="{{work_dir}}/nginx/{{nginx_version}}"
[root@ansible tomcat-playbook]# ansible-playbook 1.yaml --syntax-check

playbook: 1.yaml
[root@ansible tomcat-playbook]# ansible-playbook 1.yaml

使用file模块创建文件

---
- hosts: webservers
  gather_facts: no
  remote_user: root
  vars:
    - work_dir: /opt
    - nginx_version: 1.11

  tasks:
  - name: create dir
    file: "dest={{work_dir}}/nginx/{{nginx_version}} state=directory"

Registration variable -register
register variables is to save your results to perform certain tasks in a variable, so is the ability to dynamically obtain a variable, for example, after executing a task, there is a return to state, according to the state hopes asynchronous processing, due to the variable since the previous correspondence well, it is difficult to know what the variable is acquired.
There is a special debug debugging variables, where time while dynamic definition file when the file was created
in general this is to start the two services, both services have dependencies, only the first to start a service, second one to start up, and that in this case, you can add a registered service variables in the start, if the first service starts when there will be pid, or other output then use the registry variable definition.

---
- hosts: webservers
  gather_facts: no
  remote_user: root
  vars:
    - work_dir: /opt

  tasks:
    - name: register var
      command: date +"%F %T"
      register: datetime

    - name: touch file
      #debug: msg={{datetime}}
      file: dest=/tmp/r_{{datetime.stdout}} state=touch

Information system variables (fasts )
calls to system variables hostname / IP host and create a file
that can go through the call set up, to see our ansible interface api

[root@ansible test]# ansible webservers -m setup

---
- hosts: webservers
  gather_facts: yes
  remote_user: root

  tasks:
  - name: touch file
    file: dest=/tmp/devops_{{ansible_hostname}} state=touch

playbok file reuse
our file multiplexing, you can use the playbook of incloud_tasks and import_tasks import in, this advantage is that when we go to write a bigger playbook, you can break it up into many small tasks, decomposition after it into smaller tasks, you can reference in other places, second advantage is the ability to organize playbook these functional modules, if a large write the script, possibly hundreds of lines, maintenance and management is not very good, so there include_tasks and achieve import_tasks to complete these requirements
difference Include and import of
all import file
Include (dynamic): import at runtime
 --list-tags, --list-tasks will not be displayed to the output
 can not use notify trigger from within include the name of the handler (handlers)

Import * (static): pre-import during the playbook resolved, that is, before the playbook in advance prior to import came in,
 can not be used with the cycle
time  variables for the destination file name or role, can not use the inventory (host / variable) in the host group such as
multiplexing case:
installation lnmp / lnmt
that yaml only need to use the -import calls on it

vim lnmp.yaml

---
 - import_playbook: nginx.yaml
 - import_playbook: mysql.yaml
 - import_playbook: php.yaml

vim nginx.yaml

---
- hosts: webservers
  gather_facts: no
  remote_user: root

  tasks:
  - name: Install nginx
    debug: msg="install nginx ... "  
[root@ansible web]# ansible-playbook lnmp.yaml   

Import to import a playbook, and include a task file import

[root@ansible web]# ansible-playbook test.yaml

---
- hosts: webservers
  gather_facts: no
  remote_user: root

  tasks:
  - name: task1
    debug: msg="test1"

  - name: task2
    debug: msg="test2"

But the deployment of this mission tasks, the task can be relatively long time to decompose, can be divided into separate files, for example, there are two tasks, first I will break down tasks into one file, and the second is decomposed into a file and then import into use include

vim test.yaml

---
- hosts: webservers
  gather_facts: no
  remote_user: root

  tasks:
  - include_tasks: task1.yaml
  - include_tasks: task2.yaml

vim task1.yaml

---
- name: tasks1
  debug: msg="test1"
vim task2.yaml

---
- name: tasks2
  debug: msg="test2"