1.1 what is playbooks
Playbooks are Ansible's configuration, deployment and orchestration languages. They can be described as a scheme that requires a remote host to execute commands, or a set of commands run by a group of IT programs
At the basic level, playbooks can be used to manage configuration files for deployment to remote hosts. At a higher level, playbooks can successively perform online operations, including rolling updates, on servers in a multi-layer architecture, and delegate operations to other hosts, including interaction with monitoring servers and load balancing servers
The format of playbooks is YAM and the syntax is minimized to avoid playbooks becoming a programming language or script, but it is not a configuration model or process model
playbook consists of one or more 'plays'. Its content is a list with' plays' as the element
In play, a group of machines are mapped to defined roles. In ansible, the content of play is called tasks, that is, tasks. In basic level applications, a task is a call to ansible modules, which has been learned in the previous chapters
'plays' is like a musical note, and playbook is like a musical score composed of' plays'. Through playbook, you can arrange steps for multi machine deployment, such as running certain steps on all machines in the webservers group, then running some steps in the database server group, and finally returning to the webservers group, and then running some steps, and so on
"Games" is a sports analogy. You can tell your system to do different things through multiple games, not only to define a specific state or model. You can run different games at different times
1.2 composition of playbooks
playbooks itself consists of the following parts
- Tasks: tasks, that is, organizing multiple operations to run in a playbook by calling an ansible template through task
- Variables: Variables
- Templates: Templates
- Handlers: processor. When the changed status condition is met, (notify) triggers the operation to be executed
- Roles: roles
1.3 playbooks script example
1.3.1 modify the / etc/ansible/hosts host list first
[root@host103 ~]# vim /etc/ansible/hosts ... #Add the host ip or host name (host name mapping) to the web servers group [webservers] 192.168.23.105 ....
1.3.2 write a script to install and start the httpd service
#The script name should end with. yml or. yaml [root@host103 opt]# vim daemon1.yaml --- #Yaml file starts with three short horizontal bars --- to indicate that it is a yaml file. It can be omitted - name: first palybook # Defines the name of a play. It can be omitted gather_facts: false #Set not to collect facts information. This can speed up execution. The default is true. It can be omitted hosts: webservers #Specify the managed hosts to perform tasks. Multiple host groups are separated by colon:. remote_user: root #Specifies the user who performs tasks on the managed host tasks: #Define the task list. Each task in the task list is executed on the host defined by hosts - name: test connection #Custom task name. It can be omitted. However, it is not recommended to omit it for troubleshooting ping: #Use the format of module: [options] to define tasks. The ping module is used here - name: disable selinux command: '/sbin/setenforce 0' #command and shell modules do not need to use the mode of key=value. Quotation marks can be omitted #Ignore failed tasks. If the return value of the command is not 0, an error will be reported and playbooks will exit. Therefore, use this option to ignore failed tasks ignore_errors: true - name: disable firewalld #Use the format of module: option s to define tasks. Options use the format of key=value service: name=firewalld state=stopped enabled=no - name: install apache yum: name=httpd state=latest - name: start apache service service: name=httpd state=started enabled=yes - name: modify httpd configuration file #The / opt/httpd.conf file needs to be prepared in advance copy: src=/opt/httpd.conf dest=/etc/httpd/conf/httpd.conf #Set the trigger. If the above operation is in the change state, the handlers operation of the corresponding name will be triggered through the name specified in notify notify: "restart httpd" #Tasks are defined in handlers handlers: #Set the task name. It should be the same as the task name specified in notify - name: restart httpd #Set the action to be executed. Here, the service module is used to restart httpd service: name=httpd state=restarted #Ansible does not execute the corresponding handler immediately after executing a task, but executes the handler after all ordinary tasks in the current play. This has the advantage that notify can be triggered multiple times, but only execute the corresponding handler once in the end, so as to avoid multiple restarts.
1.3.3 prepare / opt/httpd.conf file
root@host103 opt]# vim httpd.conf #Configure the listening port and domain name (normally use port 80) 42// Listen 8080 95// ServerName www.mynet.com:8080
1.4 execute the ploybooks script
Format:
Ansible playbook script name
Supplementary parameters:
-K (- ask pass): used to enter ssh password interactively
-K (- ask come pass): used to enter sudo password interactively
-u: Designated user
#The management host executes the playbooks script [root@host103 opt]# ansible-playbook demo1.yaml #Access test [root@host105 ~]# firefox http://192.168.23.105:8080
1.5 check the yaml file and specify the task to start running
1.5.1 yaml file syntax check
#Check that the syntax of the yaml file is correct [root@host103 opt]# ansible-playbook demo1.yaml --syntax-check #Check task [root@host103 opt]# ansible-playbook demo1.yaml --list-task #Check valid hosts [root@host103 opt]# ansible-playbook demo1.yaml --list-hosts
1.5.2 specify a task to run from
#Turn on the firewalld service of the 192.168.23.105 host [root@host105 ~]# systemctl start firewalld [root@host105 ~]# systemctl is-active firewalld active #192.168.23.105 stop httpd service and remove httpd [root@host105 ~]# systemctl stop httpd [root@host105 ~]# yum -y remove httpd #Check out the tasks first [root@host103 opt]# ansible-playbook demo1.yaml --list-task playbook: demo1.yaml play #1 (webservers): first palybook TAGS: [] tasks: test connection TAGS: [] disable selinux TAGS: [] disable firewalld TAGS: [] install apache TAGS: [] start apache service TAGS: [] modify httpd configuration file TAGS: [] #Specify the task of installing Apache [root@host103 opt]# ansible-playbook demo1.yaml --start-at-task='install apache' #At this point, the 192.168.23.105 host reinstalls httpd and starts the service [root@host105 ~]# rpm -q httpd httpd-2.4.6-67.el7.centos.x86_64 [root@host105 ~]# systemctl is-active httpd active #Since the disale firewalld task precedes the install apache task, it is not executed [root@host105 ~]# systemctl is-active firewalld active
2.1 defining variables
2.1.1 legal variable name
Before using a variable, it's best to know what the legal variable name is = =. Variable names can be letters, numbers and underscores. Variables should always start with letters==
"foo_port" is a legal variable name, and so is "foo5"
"Foo port", "foo port", "foo.port" and "12" are not legal variable names
2.1.2 format of variables defined in Playbook
vars can be used to define variables. Multiple variables should form a list. The format of variables is key: value
as
- hosts: dbservers vars: - groupname: mysql #Define the variable groupname with the value of mysql - username: nginx #Define the variable username with the value of nginx
2.2 using variables
Ansible allows you to use the Jinja2 template system to reference variables in the playbook. With Jinja, you can do many complex operations,
2.2.1 substitution of variables
#In a simple template, you can operate as follows, which is also the most basic form of variable replacement My amp goes to {{ max_amp_value }} #Replace in playbook: template: src=foo.cfg.j2 dest={{ remote_install_path }}/foo.cfg #In the above example, we use variables to determine where the file is placed #In the template, you will automatically get access to all variables within the host scope
2.3 yaml trap
Ansible uses "{}" to reference variables. If a value starts with "{", YAML will consider it a dictionary, so we must reference it, such as foo: "}"
#Wrong example - hosts: app_servers vars: app_path: {{ base_path }}/22 #Correct example - hosts: app_servers vars: app_path: "{{ base_path }}/22"
2.4 information obtained using Facts
There are other places where you can get variables that are found automatically, not set by the user
Facts obtains the corresponding information by accessing the remote system. An example is the IP address or operating system of the remote host. Use the following command to view which information is available:
ansible hostname -m setup
[root@host103 opt]# ansible webservers -m setup [root@host103 opt]# ansible webservers -m setup -a 'filter=*ipv4'
2.5 defining variables on the command line
On the command line, you can use - e to specify variables. But it will overwrite the variables in playbooks
[root@host103 opt]#ansible-playbook demo1 -e "username=nginx"
2.6 variables provided by ansible
Ansible will automatically provide you with some variables, even if you have not defined them. The important variables are = = 'hostvariables' and' Group '_ Names', and 'groups'. = = because these variable names are reserved, users should not overwrite them.' environmen t 'is also reserved
2.6.1 hostvars variable
hostvars allows you to access the variables of other hosts, including the facts obtained from which hosts. If you haven't accessed that host in the current playbook or any play of a group of playbooks, you can obtain the variables, but you can't see the facts value. If the database server wants to use a 'fact' value of another node, Or an inventory variable assigned to the node. It can be easily implemented in a template or even on the command line:
{{ hostvars['test.example.com']['ansible_distribution'] }}
2.6.2 groups variable
group_names is a list (array) of all groups where the current host is located. Therefore, Jinja2 syntax can be used to make changes in the template according to the group relationship (or role) of the host:
{% if 'webserver' in group_names %} # some part of a configuration file that only applies to webservers {% endif %}
2.6.3 groups variable
Groups is a list of all groups (hosts) in the inventory. It can be used to enumerate all hosts in the group. For example:
{% for host in groups['app_servers'] %} # something that applies to all app servers. {% endfor %}
A frequently used paradigm is to find all IP addresses in the group:
{% for host in groups['app_servers'] %} {{ hostvars[host]['ansible_eth0']['ipv4']['address'] }} {% endfor %}
2.7 separation of variable files
It's a good idea to put the playbook under source control. When you may want to make the playbook source code public, you also want to keep some important variables private. Sometimes you also want to put some information in different files away from the main playbook file
You can use external variable files to implement:
--- - hosts: all remote_user: root vars: favcolor: blue vars_files: - /vars/external_vars.yml tasks: - name: this is just a placeholder command: /bin/echo foo
This ensures that you can isolate the risk of sensitive data when sharing playbook source code
The content of each variable file is a simple YAML file, as shown below:
--- # in the above example, this would be vars/external_vars.yml somevar: somevalue password: magic
2.8 priority of variables
* extra vars (Use in the command line -e)Highest priority * Then in inventory Connection variables defined in(such as ansible_ssh_user) * Then there are most other variables(Command line conversion,play Variables in,included Variable of,role Variables in) * Then in inventory Other variables defined * Then it was discovered by the system facts * And then "role Default variable", This is the default value,It's easy to lose priority
2.9 example of using playbook variable
[root@host103 opt]# vim demo2.yaml - name: second playbook #Start facts. The default value is true (or yes). If you want to close it, use false or no gather_facts: yes hosts: webservers remote_user: root #Define variables. groupname variable, the value is test; Username variable with the value zhangsan vars: - groupname: test - username: zhangsan tasks: - name: create group #Reference variable groupname group: name={} system=yes gid=1024 - name: create user for group #Reference variables username and groupname user: name={} system=yes uid=9527 group={} - name: test copy file #Reference variables from facts. However, facts must be on #ansible_defaule_ipv4 is one of the key s. copy: content="{}" dest=/opt/test.txt #Execute script [root@host103 opt]# ansible-playbook demo2.yaml
#Use the ansible setup module on 192.168.23.103 and filter the key value pair information [root@host103 opt]# ansible webservers -m setup -a 'filter=ansible_default_ipv4' #On the 192.168.23.105 host, check whether the zhangsan user is generated and whether the group is test [root@host105 opt]# id zhangsan #View / opt/test.txt [root@host105 opt]# cat /opt/test.txt
--- - hosts: dbservers remote_user: zhangsan become: yes #The parameter after version 2.6, formerly sudo, means to switch the user's operation become_user: root #Specify sudo user as root
If you need to specify the password when using sudo, you can add the option -- ask sudo pass (- K) when running the ansible playbook command. If the playbook is suspected to be suspended when using sudo, it may be stuck at sudo prompt. At this time, you can execute Control-C to kill the stuck task and run it again
When using sudo_ When user switches to a non root user, the parameters of the module will be temporarily written to a random temporary file in the / tmp directory. When the command is executed, the temporary file will be deleted immediately. This happens when ordinary users switch, such as switching from 'bob' to 'timmy', and switching to the root account, it will not happen, such as switching from 'bob' to 'root', If you don't want these data to be read (not writable) in a short time, please avoid in sudo_ Pass the unencrypted password in user. In other cases, the '/ tmp' directory is not used, which will not happen. Ansible also consciously does not record the password parameters in the log
In Ansible, the only general condition judgment provided is the when instruction. When the value of the when instruction is true, the task will be executed, otherwise the task will not be executed.
when a common application scenario is to skip a host and do not execute tasks, or only qualified hosts execute tasks
4.1 skip the host or let the qualified host perform the task
vim demo3.yaml --- - hosts: all remote_user: root tasks: - name: reboot command: /usr/sbin/shutdown -r now #The variable name in the when directive does not need to be manually added with {} #The effect of this task is: when the host bit is 192.168.23.105, execute the / usr/sbin/shutdown -r now command to restart the host when: ansible_default_ipv4.address == "192.168.23.105" or when: inventory_hostname == "<host name>" ansible-playbook demo3.yaml
4.2 iteration
Ansible provides many kinds of loop structures, which are generally named with_items, which is equivalent to a loop loop.
[root@host103 opt]# vim demo4.yaml --- - name: play4 hosts: webservers gather_facts: false tasks: - name: create directories #Create a directory. Use with for directory name_ Loop in items file: #Since the value is {....}}, double quotation marks should be added to prevent it from being considered a dictionary path: "{}" state: directory #with_ The items loop is equivalent to the loop loop with_items: - /opt/zhangsan - /opt/lisi - name: add users #Use the loop to create users and add additional groups. user: #Both of the following methods can call with_ Values in iptems name: "{}" groups: "{}" with_items: #Both of the following methods are OK - name: test01 test_groups: aaa -
#Running scripts on the hypervisor [root@host103 opt]# ansible-playbook demo4.yaml #View the execution results on the managed host [root@host105 opt]# ls lisi zhangsan [root@host105 opt]# id test01 uid=9528(test01) gid=9528(test01) group=9528(test01),2222(aaa) [root@host105 opt]# id test02 uid=9529(test02) gid=9529(test02) group=9529(test02),3333(bbb
Jinja is a Python based template engine. Template class is an important component of Jinja. It can be regarded as a compiled template file, which is used to generate target text and pass Python variables to the template to replace the tags in the template.
5.1 preparation of formwork
Prepare a template file with a. j2 suffix and set the referenced variables
[root@host103 opt]# cp httpd.conf httpd.conf.j2 [root@host103 opt]# vim httpd.conf.j2 #42 / / set the listening port as a variable. Reference variable http_ Value of port 42// Listen {} #95 / / set the domain name as the reference variable server_ Value of name 95 ServerName {} #119 / / set the website root directory to reference root_ Value of dir 119// DocumentRoot "{}" #131 / / configure directory access permissions 131// <Directory "{}">
5.2 modify the host list file
Modify the host list file and use the host variable to define a variable with the same variable name but different values
[root@host103 opt]# vim /etc/ansible/hosts #Use host variables to define variables individually [webservers] 192.168.23.105 http_port=192.168.23.105:80 server_name=www.mynet.com:80 root_dir=/opt/mynet [dbservers] 192.168.23.106 http_port=192.168.23.106:8080 server_name=www.zhi.com:8080 root_dir=/opt/zhi
5.3 writing playbook
--- - name: for diff apache hosts: webservers dbservers remote_user: root vars: - Package: httpd - Service: httpd - mynet: /opt/mynet - zhi: /opt/zhi tasks: - name: install httpd yum: name={} state=latest - name: install configure file template: src=/opt/httpd.conf.j2 dest=/etc/httpd/conf/httpd.conf notify: - restart httpd - name: create root dir for mynet file: path={} state=directory when: ansible_default_ipv4.address == "192.168.23.105" - name: for mynet index.html copy: content='this is mynet.com' dest={}/index.html when: ansible_default_ipv4.address == "192.168.23.105" - name: create root dir for zhi file: path={} state=directory when: ansible_default_ipv4.address == "192.168.23.106" - name: for zhi index.html copy: content='this is zhi.com' dest={}/index.html when: ansible_default_ipv4.address == "192.168.23.106" - name: start httpd service: name={} enabled=true state=started handlers: - name: restart httpd service: name={} state=restarted [root@host103 opt]# ansible-playbook demo5.yaml
#Access test [root@host103 opt]# curl http://192.168.23.105:80 this is mynet.com [root@host103 opt]# curl http://192.168.23.106:8080 this is zhi.com
You can define "tags" for one or some tasks in a playbook. When executing this playbook, you can run only the specified tasks by using the – tags option through the ansible playbook command.
playbook also provides a special tags for always. The function is that when always is used as the task of tasks, no matter which task is executed, the tasks with always defined will be executed.
6.1 specify tags to execute
[root@host104 opt]# vim webhosts.yaml --- - name: for test tags hosts: webservers remote_user: root tasks: - name: copy hosts file copy: src=/etc/hosts dest=/opt/hosts #Using tags to set labels tags: - only - name: touch file file: path=/opt/testhost state=touch #Use -- tags to specify the tag. [root@host104 opt]# ansible-playbook webhosts.yaml --tags="only"
[the external chain picture transfer fails. The source station may have an anti-theft chain mechanism. It is recommended to save the picture and upload it directly (img-ciP4sjyg-1635247577641)(image-20211025111004200.png)]
#View on managed host [root@host105 opt]# ls hosts
6.2 using the always tag
playbook also provides a special tags for always. The function is that when always is used as the task of tasks, no matter which task is executed, the tasks with always defined will be executed.
#First delete the replicated file hosts on the managed host [root@host105 opt]# rm -rf hosts [root@host104 opt]# vim webhosts.yaml --- - name: for test tags hosts: webservers remote_user: root tasks: - name: copy hosts file copy: src=/etc/hosts dest=/opt/hosts tags: - only - name: touch file file: path=/opt/testhost state=touch #Add tags tagalways tags: - always #It is still executed with the specified label [root@host104 opt]# ansible-playbook webhosts.yaml --tags="only"
[root@host105 opt]# ls hosts testhost
Ansible uses roles to organize playbooks hierarchically and structurally. Roles can automatically load variable files, tasks, handlers, etc. according to the hierarchical structure. In short, roles is to place variables, files, tasks, modules and processors in separate directories and easily include them. Roles are generally used in the scenario of building services based on hosts, but they can also be used in scenarios such as building daemons.
7.1 directory structure of roles
[root@host104 ansible]# cd /etc/ansible/ [root@host104 ansible]# tree roles/ #The first level directory created under roles is the role directory. #The role directory needs to contain files, templates, tasks, handlers, vars, defaults and meta directories roles/ ├── web/ │ ├── files/ │ ├── templates/ │ ├── tasks/ │ ├── handlers/ │ ├── vars/ │ ├── defaults/ │ └── meta/ └── db/ ├── files/ ├── templates/ ├── tasks/ ├── handlers/ ├── vars/ ├── defaults/ └── meta/
7.2 interpretation of roles directory
-
files
- Used to store files called by copy module or script module.
-
templates
- It is used to store jinjia2 templates. The template module will automatically find jinjia2 template files in this directory.
-
tasks
- This directory should contain a main.yml file to define the task list of this role. This file can use include to contain other task files located in this directory.
-
handlers
- This directory should contain a main.yml file that defines the actions to be performed when triggering conditions in this role.
-
vars
- This directory should contain a main.yml file that defines the variables used by this role.
-
defaults
- This directory should contain a main.yml file to set default variables for the current role.
-
meta
- This directory should contain a main.yml file that defines the special settings of this role and its dependencies.
7.3 steps of using roles in a playbook
1 create a directory named roles
#The default installed using yum is mkdir -p /etc/ansible/rules
2 create global variable directory (optional)
mkdir -p /etc/ansible/group_vars/ touch /etc/ansible/group_vars/all #The file name is defined by itself. Pay attention when referencing
3 create directories named after each role in the roles directory, such as http and mysql
mkdir /etc/ansible/roles/httpd mkdir /etc/ansible/roles/mysql
4. Create files, handlers, tasks, templates, meta, defaults and vars directories in the directory of each role command. Directories that are not used can be created as empty directories or not
mkdir /etc/ansible/roles/httpd/ mkdir /etc/ansible/roles/mysql/
5. Create the main.yml file in the handlers, tasks, meta, defaults and vars directories of each role. You must not customize the file name
touch /etc/ansible/roles/httpd//main.yml touch /etc/ansible/roles/mysql//main.yml
6. Modify the site.yml file to call different roles for different hosts
vim /etc/ansible/site.yml --- - hosts: webservers remote_user: root roles: - httpd - hosts: dbservers remote_user: root roles: - mysql
7 run ansible playbook
cd /etc/ansible ansible-playbook site.yml
7.4 examples
1 create corresponding directories and files
[root@host104 ansible]# mkdir /etc/ansible/roles/httpd/ -p[root@host104 ansible]# mkdir /etc/ansible/roles/mysql/ -p[root@host104 ansible]# mkdir /etc/ansible/roles/php/ -p [root@host104 ansible]# touch /etc/ansible/roles/httpd//main.yml [root@host104 ansible]# touch /etc/ansible/roles/mysql//main.yml [root@host104 ansible]# touch /etc/ansible/roles/php//main.yml [root@host104 ansible]# tree . ├── ansible.cfg ├── hosts └── roles ├── httpd │ ├── defaults │ │ └── main.yml │ ├── files │ ├── handlers │ │ └── main.yml │ ├── meta │ │ └── main.yml │ ├── tasks │ │ └── main.yml │ ├── templates │ └── vars │ └── main.yml ├── mysql │ ├── defaults │ │ └── main.yml │ ├── files │ ├── handlers │ │ └── main.yml │ ├── meta │ │ └── main.yml │ ├── tasks │ │ └── main.yml │ ├── templates │ └── vars │ └── main.yml └── php ├── defaults │ └── main.yml ├── files ├── handlers │ └── main.yml ├── meta │ └── main.yml ├── tasks │ └── main.yml ├── templates └── vars └── main.yml 25 directories, 17 files
2 write httpd module
#Write a simple tasks/main.yml [root@host104 ansible]# vim /etc/ansible/roles/httpd/tasks/main.yml - name: install apache yum: name={} state=latest - name: start apache service: name={} state=started enabled=yes #Define variable: it can be defined in global variables or roles variables. Generally, it is defined in role variables [root@host104 ansible]# vim /etc/ansible/roles/httpd/vars/main.yml pkg: httpd svc: httpd
3. Write mysql module
[root@host104 ansible]# vim /etc/ansible/roles/mysql/tasks/main.yml - name: install mysql yum: name={} state=latest - name: start mysql service: name={} state=started enabled=yes #Online sources are required. Therefore, the yum source for the backup is enabled - name: remove yumrepo shell: move /etc/yum.repos.d/bak/* /etc/yum.repos.d/ ignore_errors: yes [root@host104 ansible]# vim /etc/ansible/roles/mysql/vars/main.yml pkg: - mariadb - mariadb-server svc: mariadb
4 write php module
[root@host104 ansible]# vim /etc/ansible/roles/php/tasks/main.yml - name: install php yum: name={} state=latest - name: start php-fpm service: enabled=true name={} state=started [root@host104 ansible]# vim /etc/ansible/roles/php/vars/main.yml pkg: - php - php-fpm svc: php-fpm
5 write roles example
[root@host104 ansible]# vim /etc/ansible/site.yml --- - hosts: webservers remote_user: root roles: - httpd - mysql - php [root@host104 ansible]# cd /etc/ansible [root@host104 ansible]# ansible-playbook site.yml
#It can be viewed on the management host [root@host105 yum.repos.d]# systemctl is-active httpd active [root@host105 yum.repos.d]# systemctl is-active mariadb active [root@host105 yum.repos.d]# systemctl is-active php-fpm active
/etc/yum.repos.d/
ignore_errors: yes
[root@host104 ansible]# vim /etc/ansible/roles/mysql/vars/main.yml
pkg:
- mariadb
- mariadb-server
svc: mariadb
</font> <br> ### 4 write php module <font size=2> ```yaml [root@host104 ansible]# vim /etc/ansible/roles/php/tasks/main.yml - name: install php yum: name={} state=latest - name: start php-fpm service: enabled=true name={} state=started [root@host104 ansible]# vim /etc/ansible/roles/php/vars/main.yml pkg: - php - php-fpm svc: php-fpm
5 write roles example
[root@host104 ansible]# vim /etc/ansible/site.yml --- - hosts: webservers remote_user: root roles: - httpd - mysql - php [root@host104 ansible]# cd /etc/ansible [root@host104 ansible]# ansible-playbook site.yml
[external chain picture transferring... (img-3MT0HIXL-1635247577644)]
#It can be viewed on the management host [root@host105 yum.repos.d]# systemctl is-active httpd active [root@host105 yum.repos.d]# systemctl is-active mariadb active [root@host105 yum.repos.d]# systemctl is-active php-fpm active
[external chain picture transferring... (IMG jncfscdy-1635247577645)]