Shulou(Shulou.com)06/02 Report--

1. Roles directory structure

2. Basic use of Roles

3. Example: use Roles to deploy httpd,memcached with one click (you can add task and the role of roles according to your needs, such as redeploying docker, and specify tags and hosts according to the tasks related to the deployment of different hosts.

This roles mainly defines the known file structure in advance by roles, and it automatically loads the contents of the file, such as the task handlers, which is automatically unloaded, that is, roles classifies and groups the known, making it easy for us to manage. Roles provides a hierarchical and hierarchical organization of your playbook, which is why we use it, unlike playbook. And roles is an organizational approach, which is also a best practice through ansible.

1. Directory structure of roles

It has a site,yaml in the directory, which is a unified entry, because it will be associated with a lot of files, so we only need to operate on this unified entry and deploy roles or functional modules, such as webservers.yaml and fooservers.yml below.

Site.yml unified entry, will be associated with a lot of files

Deployment of webservers.yml roles or functional modules

Deployment of fooservers.yml hosts roles or functional modules

Roles/ role directory, which is divided into different modules

Common/, like common and webservers, is equivalent to two modules. Common is used to store some common resources. For example, many projects may use common variables or have the same dependencies, then they can all be defined under this module of common. This module can also be called a role. There are many directories under this role, such as the following files belong to it. These directories are to distinguish between different files or different tasks.

Files/ this is the file used in role deployment, such as installing a package, installing a software may use one of its packages, then the package can be placed in this location

Templates/ is the template used in its role deployment. For example, jinja renders a configuration file, which stores some dynamically generated files and a directory for other files.

Tasks/ tasks, what exactly to do

Handlers/ processor

Variables for the vars/ role

Default variables for defaults/ roles

Some metadata defined by meta/ roles

Webservers/ belongs to the module like the common above, and the following is the file to which it belongs.

Files/ . Files used in role deployment

Templates used in templates/ role deployment

Tasks/ tasks, what exactly to do

Handlers/ processor

Variables defined by vars/

2. Basic use of Roles

Hosts: webservers host group

Roles:common module, the following can define many of its directories or different tasks nginx. Here is the deployment of a php Nginx and php website platform referencing the following variables

Define roles to define variables

Hosts: webservers

After using this roles, roles:common can also directly define the variable role: nginx vars:

Dir:'/ opt/a'

App_port: 5000role: php is used directly in this roles

Vars:

Dir:'/ opt/b'

App_port: 5001

Here we created hosts, our host list, roles needs to put our modules and different tasks in the directory, to have a site.yaml

[root@ansible roles-demo] # lshosts roles site.yaml [root@ansible roles-demo] # mkdir roles/ {common,nginx,php} / {file,templates,tasks,handlers}

Write a main yaml under each tasks, because it will look for the main under your task, that is, an entry under the tasks.

View directory tree structure

[root@ansible roles-demo] # tree.. |-- hosts |-- roles | |-- common |-- file |-- handlers |-- tasks |-- main.yaml |-- templates |-- file |-- handlers |-- tasks |-- main.yaml | |-- templates |-- php | |-- file | |-- | Handlers | |-- main.yaml | |-- tasks |-- templates- site.yaml

Check syntax, execute

[root@ansible roles-demo] # ansible-playbook site.yaml-I hosts-- syntax-check

[root@ansible roles-demo] # ansible-playbook site.yaml-I hosts

Define the newly called variable under site. This will find the corresponding task under the directory, such as the task under tasks.

-hosts: webservers gather_facts: no remote_user: root roles:-role: common-role: nginx vars: dir: / opt/an app_port: 80-role: php vars: dir: / opt/b app_port: 81

Define the task under tasks. This will find the roles under site.yaml, and then perform the operations under the relevant directory.

[root@ansible nginx] # cat tasks/main.yaml-name: nginx task test debug: msg= "nginx task test > {{dir}} {{app_port}}"

You can also write a group and define variables in the group. This all will help you give it to all groups, or you can define webservers, that is, define a single group.

[root@ansible roles-demo] # lsgroup_vars hosts roles site.yaml [root@ansible roles-demo] # cd group_vars/ [root @ ansible group_vars] # lsall [root@ansible group_vars] # cat all nginx_ver: 1.15php_ver: 5.6

If you give a single single task to this site, you can define a tag that can execute tasks under a single roles when executed.

[root@ansible roles-demo] # vim site.yaml-hosts: webservers gather_facts: root roles:-role: common-role: nginx vars: dir: / opt/an app_port: 80 tags: nginx-role: php vars: dir: / opt/b app_port: 81 tags: php [root@ansible roles-demo] # ansible-playbook site .yaml-I hosts-- tags nginxPLAY [webservers] * * TASK [nginx: nginx task test] * ok : [10.4.7.21] = > {"msg": "nginx task test > / opt/a 80 1.155.6"} ok: [10.4.7.22] = > {"msg": "nginx task test > / opt/a 80 1.155.6"} PLAY RECAP * * * 10.4.7.21: ok=1 changed=0 unreachable=0 failed=0 10.4.7.22: ok=1 changed=0 unreachable=0 failed=0

Use the register variable to get the status on the k8s-master host group

Here, you can also change it to var: test. You can get all the status. Use msg to view a certain field, and you can use msg to get that field.

The above uses the "register" keyword to write the return value of the current shell task to a variable named test, and the second debug module outputs the value of the registered variable in the first task

-name: test shell: kubectl get node register: test- name: shell debug: msg: "{{test.stdout_lines}}"

Execute a command

[root@hdss7-200test] # ansible-playbook-I hosts test.yaml PLAY [test] * * TASK [nginx: test] * * changed: [10.4.7.11] TASK [nginx: shell] * * * ok: [10.4.7.11] = > {"msg": ["NAME STATUS ROLES AGE VERSION" "k8s-master1 Ready 4h47m v1.16.0", "k8s-node1 Ready 4h47m v1.16.0" "k8s-node2 Ready 4h47m v1.16.0"]} PLAY RECAP * * * 10.4.7.11: ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ig

3. Deploy memcached and httpd with one click using the Roles role

Check my directory tree

[root@hdss7-200 test-roles] # tree.. ├── hosts ├── roles │ ├── httpd │ │ └── tasks │ │ main.yml │ └── memcached │ └── tasks │ └── main.yml └── site.yaml5 directories, 4 files

Two files and one directory.

[root@hdss7-200 test-roles] # lshosts roles site.yaml [root@hdss7-200 test-roles] # ll Total usage 8 site.yaml roles-rw-r--r-- 1 root root 146 December 5 11:18 site.yaml

Host group, you can write your host group according to which server you want to deploy to. If you want to deploy a service, deploy a service according to the tags of the role of roles.

[root@hdss7-200test-roles] # cat hosts 10.4.7.22

Unified entry, including deployed role tasks, which can define multiple roles

[root@hdss7-200test-roles] # cat site.yaml-hosts: roles gather_facts: no remote_user: root roles:-role: httpd tags: httpd-role: memcached tags: memcached

This is the task of tasks under our roles. The previous one was written in a yml. For complex tasks, we can use roles to implement them.

[root@hdss7-200test-roles] # cd roles/httpd/ memcached/ [root@hdss7-200test-roles] # cat roles/httpd/tasks/main.yml-name: install httpd yum: name=httpd state=present- name: start httpd systemd: name=httpd state=started enabled=yes- name: httpd status shell: ps-ef | grep httpd register: test- name: shell debug: msg: "{test.stdout_lines}"-name: debug: msg: "{{inventory_hostname}"

Msg is a debugging tool, in which stdout_lines is a value of the global variable. You can take var: test to get all the input, because ansible will not output the content of successful execution for us, so we need to call the variables of its system output by ourselves.

[root@hdss7-200 test-roles] # cat roles/memcached/tasks/main.yml-name: install memcached yum: name=memcached state=present- name: start memcached systemd: name=memcached state=started enabled=yes daemon_reload=yes- name: memcached status shell: ps-ef | grep memcached register: test- name: memcached ps debug: msg: {{test.stdout}}

View the overall content of the output

[root@hdss7-200test-roles] # ansible-playbook-I hosts site.yamlPLAY [roles] * * TASK [httpd: install httpd] * changed: [10.4.7.22] TASK [httpd: start httpd] * * changed: [10.4.7.22] TASK [httpd: httpd status] * * * changed: [10.4.7.22] TASK [httpd: shell] * * * ok: [10.4.7.22] = > {"msg": ["root 10375 1 3 11:28? 00:00:00 / usr/sbin/httpd-DFOREGROUND" "apache 10376 10375 0 11:28? 00:00:00 / usr/sbin/httpd-DFOREGROUND", "apache 10377 10375 0 11:28? 00:00:00 / usr/sbin/httpd-DFOREGROUND", "apache 10378 10375 0 11:28? 00:00:00 / usr/sbin/httpd-DFOREGROUND" "apache 10379 10375 0 11:28? 00:00:00 / usr/sbin/httpd-DFOREGROUND", "apache 10380 10375 0 11:28? 00:00:00 / usr/sbin/httpd-DFOREGROUND", "root 10417 10416 0 11:28 pts/1 00:00:00 / bin/sh-c ps-ef | grep httpd" "root 10419 10417 0 11:28 pts/1 00:00:00 grep httpd"]} TASK [memcached: install memcached] * * ok: [10. 4.7.22] TASK [memcached: start memcached] * ok: [10.4.7.22] TASK [memcached: memcached status] * * changed: [10.4.7.22] TASK [memcached: memcached ps] * * * ok: [10.4.7.22] = > {"msg": "memcach+ 10136 10 11:21? 00:00:00 / usr/bin/memcached-u memcached-p 11211-m 64-c 1024\ nroot 10575 10574 18 11:28 pts/1 00:00:00 / bin/sh-c ps-ef | grep memcached\ nroot 10577 10575 0 11:28 pts/1 00:00:00 grep memcached "} PLAY RECAP * * * 10.4.7.22: ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

For example, if you perform a task alone, deploy a httpd, which is very flexible. There is also a debug, that is, print the host name.

[root@hdss7-200test-roles] # ansible-playbook-I hosts site.yaml-- tags httpdPLAY [roles] * * TASK [httpd: install httpd] * * ok: [10.4.7.22] TASK [httpd: start httpd] * * * ok: [10.4.7.22] TASK [httpd: httpd status] * * changed: [10.4.7.22] TASK [httpd: shell] * * * ok: [10.4.7.22] = > {"msg": ["root 10375 10 11:28? 00:00:00 / usr/sbin/httpd-DFOREGROUND" "apache 10376 10375 0 11:28? 00:00:00 / usr/sbin/httpd-DFOREGROUND", "apache 10377 10375 0 11:28? 00:00:00 / usr/sbin/httpd-DFOREGROUND", "apache 10378 10375 0 11:28? 00:00:00 / usr/sbin/httpd-DFOREGROUND" "apache 10379 10375 0 11:28? 00:00:00 / usr/sbin/httpd-DFOREGROUND", "apache 10380 10375 0 11:28? 00:00:00 / usr/sbin/httpd-DFOREGROUND", "root 10744 10743 0 11:46 pts/1 00:00:00 / bin/sh-c ps-ef | grep httpd" "root 10746 10744 0 11:46 pts/1 00:00:00 grep httpd"]} TASK [httpd: debug] * * ok: [10.4.7.22] = > {"msg": "10.4.7.22"} PLAY RECAP * * * * 10.4.7.22: ok=4 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

You can also add some new tasks such as batch creation of files

The {{item}} loop used here reduces the need for us to write multiple name

-name: create file file: path=/tmp/ {{item}} state=touch with_items:-"1.txt"-"2.txt"-"3.txt"-"4.txt"

Execution effect

[root@hdss7-200test-roles] # ansible-playbook-I hosts site.yaml-- tags nginxPLAY [roles] * * TASK [nginx: create file] * changed: [10.4.7.22] = > (item=1.txt) changed: [10.4.7.22] = > (item=2.txt) changed: [10.4.7.22] = > (item=3.txt) changed: [10.4.7.22] = > (item=4.txt) PLAY RECAP * * * 10.4.7.22: ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.