Host Planning

 

Add user account

Explain:

1. Login accounts used by operations and maintenance personnel;

2. All businesses are placed under / app / in the "home directory of yun users" to avoid the disorder of business data;

3. This user is also used by ansible because almost all production environments prohibit root from logging on remotely (so this yun user also has sudo privileges).

1 # Use a dedicated user instead of using root directly
2 # Add users, specify home directories, and specify user passwords
3 # sudo claim
4 # Allow other users to access the directory to view information
5 useradd -u 1050 -d /app yun && echo '123456' | /usr/bin/passwd --stdin yun
6 echo "yun  ALL=(ALL)       NOPASSWD: ALL" >>  /etc/sudoers
7 chmod 755 /app/

 

Ansible Configuration Inventory

The following list of host configurations follows

 1 [yun@ansi-manager ansible_info]$ pwd
 2 /app/ansible_info
 3 [yun@ansi-manager ansible_info]$ cat hosts_key 
 4 # Mode 1, Host + port + secret key
 5 [manageservers]
 6 172.16.1.180:22
 7 
 8 [proxyservers]
 9 172.16.1.18[1:2]:22
10 
11 # Mode 2: Alias + Host + port + Password
12 [webservers]
13 web01 ansible_ssh_host=172.16.1.183 ansible_ssh_port=22
14 web02 ansible_ssh_host=172.16.1.184 ansible_ssh_port=22
15 web03 ansible_ssh_host=172.16.1.185 ansible_ssh_port=22

 

Overview of Tests

Tests is an evaluation template expression in Jinja that eventually returns True or False.Jinja has its own Tests list at the following address:

http://docs.jinkan.org/docs/jinja2/templates.html#builtin-tests

 

The main difference between tests and filters is that Jinja tests are used for comparison, while filters are used for data manipulation, and they have different applications in Jinja.

As with all templates, tests are always executed on the Ansible control machine, not on the target machine of the task because they test local data.

In addition to Jinja2 tests, Ansible offers some tests, and users can easily create their own.

Test String

To match a string to a substring or regular expression, use'match','search'or'regex' filtering.

Match: must have a start match

search: substring match

regex: regular matching

Example:

 1 [yun@ansi-manager ansi_tests]$ pwd
 2 /app/ansible_info/ansi_tests
 3 [yun@ansi-manager ansi_tests]$ cat tests_str.yml 
 4 ---
 5 
 6 - hosts: manageservers
 7   vars:
 8     url: "http://example.com/users/foo/resources/bar"
 9 
10   tasks:
11     - debug:
12         msg: "matched pattern 1-1"
13       when: url is match("http://example.com/users/.*/resources/.*") # True
14 
15     - debug:
16         msg: "matched pattern 1-2"
17       when: url is match("http://example.com") # True
18 
19     - debug:
20         msg: "matched pattern 1-3"
21       when: url is match(".*://example.com") # True
22 
23     - debug:
24         msg: "matched pattern 1-4"
25       when: url is match("example.com/users/.*/resources/.*") # False
26 
27     - debug:
28         msg: "matched pattern 2-1"
29       when: url is search("/users/.*/resources/.*") # True
30 
31     - debug:
32         msg: "matched pattern 2-2"
33       when: url is search("/users/") # True
34 
35     - debug:
36         msg: "matched pattern 2-3"
37       when: url is search("/user/") # False
38 
39     - debug:
40         msg: "matched pattern 3"
41       when: url is regex("example.com/\w+/foo") # True
42 
43 [yun@ansi-manager ansi_tests]$ ansible-playbook -b -i ../hosts_key tests_str.yml  # Notice execution

 

Test Version Comparison

Use "version" for version number comparison.

"version" accepts the following operators:

<, lt, <=, le, >, gt, >=, ge, ==, =, eq, !=, <>, ne

 

"Version" also accepts the "strict" parameter, which defaults to "False". If set to "True", ansible performs a more rigorous version check:

{{ sample_version_var is version('1.0', operator='lt', strict=True) }}

 

Example:

 1 # judge ansible_python_version Is version greater than or equal to 2.7.3
 2 [yun@ansi-manager ansi_tests]$ pwd
 3 /app/ansible_info/ansi_tests
 4 [yun@ansi-manager ansi_tests]$ ll
 5 total 8
 6 drwxrwxr-x 2 yun yun  35 Sep 12 15:14 file
 7 -rw-rw-r-- 1 yun yun 209 Sep 12 15:08 tests_version.yml
 8 [yun@ansi-manager ansi_tests]$ cat file/tests_version.conf.j2   # Involving files
 9 # Jinja2 Version Test
10 
11 {% if ansible_python_version is version('2.7.3', '>=') %}
12 result True. ansible_python_version = {{ ansible_python_version }}
13 {% else %}
14 result False
15 {% endif %}
16 
17 [yun@ansi-manager ansi_tests]$ cat tests_version.yml  # playbook file involved
18 ---
19 # ansible tests Version Comparison
20 
21 - hosts: proxyservers
22 
23   tasks:
24     - name: "Tests Version Comparison"
25       template:
26         src: ./file/tests_version.conf.j2
27         dest: /tmp/tests_version.conf
28 
29 [yun@ansi-manager ansi_tests]$ ansible-playbook -b -i ../hosts_key tests_version.yml   # implement

 

Test Subset and Superset

The keywords "superset" and "subset" are used to test whether one list contains or is contained in another list

Example:

 1 [yun@ansi-manager ansi_tests]$ pwd
 2 /app/ansible_info/ansi_tests
 3 [yun@ansi-manager ansi_tests]$ cat tests_set.yml 
 4 ---
 5 # Tess Subset and Superset
 6 - hosts: manageservers
 7 
 8   vars:
 9     a: [1,2,3,4,5]
10     b: [2,3]
11   tasks:
12     - debug:
13         msg: "A includes B"
14       when: a is superset(b)
15 
16     - debug:
17         msg: "B is included in A"
18       when: b is subset(a)
19 
20 [yun@ansi-manager ansi_tests]$ ansible-playbook -b -i ../hosts_key tests_set.yml  # Notice execution

 

True or False Test List

The keywords "all" and "any" are used to check the authenticity of elements in a list, where all or any of them are true.

all: one false

any: true is true

 

 1 [yun@ansi-manager ansi_tests]$ pwd
 2 /app/ansible_info/ansi_tests
 3 [yun@ansi-manager ansi_tests]$ cat tests_list.yml 
 4 ---
 5 #  tests all any
 6 - hosts: manageservers
 7 
 8   vars:
 9     mylist:
10       - 1
11       - "{{ 3 == 3 }}"
12       - True
13     myotherlist:
14       - False
15       - True
16 
17   tasks:
18     - debug:
19         msg: "all are true!"
20       when: mylist is all
21 
22     - debug:
23         msg: "at least one is true"
24       when: myotherlist is any
25 
26 [yun@ansi-manager ansi_tests]$ ansible-playbook -b -i ../hosts_key tests_list.yml  # Notice execution

  

Test file or directory

Used to test directories, files, soft connections, existence, relative or absolute paths, and so on.

 1 [yun@ansi-manager ansi_tests]$ pwd
 2 /app/ansible_info/ansi_tests
 3 [yun@ansi-manager ansi_tests]$ cat tests_path.yml 
 4 ---
 5 - hosts: manageservers
 6 
 7   vars:
 8     # - mypath: /tmp/
 9     - mypath: /tmp/yum_hard.sh
10     - path2: /tmp/
11     # - path2: /tmp/yum_hard_2.sh
12 
13   tasks:
14     - debug:
15         msg: "path is a directory"
16       when: mypath is directory
17 
18     - debug:
19         msg: "path is a file"
20       when: mypath is file
21 
22     - debug:
23         msg: "path is a symlink"
24       when: mypath is link
25 
26     - debug:
27         msg: "path already exists"
28       when: mypath is exists
29 
30     - debug:
31         msg: "path is {{ (mypath is abs)|ternary('absolute','relative')}}"
32 
33     - debug:
34         msg: "path is the same file as path2"
35       when: mypath is same_file(path2)
36 
37     - debug:
38         msg: "path is a mount"
39       when: mypath is mount
40 
41 [yun@ansi-manager ansi_tests]$ ansible-playbook -b -i ../hosts_key tests_path.yml  # Notice execution

 

Test Task Execution Results

Test the results of task execution.

 1 [yun@ansi-manager ansi_tests]$ pwd
 2 /app/ansible_info/ansi_tests
 3 [yun@ansi-manager ansi_tests]$ cat tests_result.yml 
 4 ---
 5 - hosts: 172.16.1.180
 6 
 7   ## A test for three situations
 8   tasks:
 9     - shell: /usr/bin/foo
10     #- shell: /usr/bin/true
11     #- shell: /usr/bin/false
12       register: result
13       ignore_errors: True
14 
15     - debug:
16         msg: "{{ result }}"
17 
18     - debug:
19         msg: "it failed"
20       when: result is failed
21 
22     # in most cases you'll want a handler, but if you want to do something right now, this is nice
23     - debug:
24         msg: "it changed"
25       when: result is changed
26 
27     - debug:
28         msg: "it succeeded in Ansible >= 2.1"
29       when: result is succeeded
30 
31     - debug:
32         msg: "it succeeded"
33       when: result is success
34 
35     - debug:
36         msg: "it was skipped"
37       when: result is skipped
38 
39 [yun@ansi-manager ansi_tests]$ ansible-playbook -b -i ../hosts_key tests_result.yml  # Notice execution

 

 

 

-—END-—
If you feel good, pay attention to the next chop (-^O^-)!