Automate and speed up the process of setting up cloud servers with Ansible. Part 4: working with modules
In the first part, we began the study of Ansible, a popular tool for automating the configuration and deployment of IT infrastructure. Ansible was successfully installed in InfoboxCloud , described the principles of operation, the basic setting. At the end of the article we showed how to quickly install nginx on multiple servers.
In the second part, we sorted out the output of the playbook, learned how to debug and reuse the Ansible scripts.
In the third part, we learned how to write a single Ansible playbook for different operating systems (for example, with rpm and deb), how to maintain multiple hosts and not write them all in inventory, and how to group servers by cloud regions. The use of the Ansible variables and the inventory file was examined.
')
In this part, we will learn how to use Ansible modules to configure the server: let's look at how to run the most common scripts on remote servers, use templating for configuration files, substituting the necessary variables, and how to use version control systems to get the code on the server.
Ansible provides more than 200 modules, such as System, Network, Database, Files, and so on. You can use modules to configure your IT infrastructure.
The module accepts the command name and the arguments Shell variables or operations (<,>, |, &) will not work with the command module, since processed by the shell. The command module accepts the following parameters:
Let's write the simplest task of rebooting the server:
This module should be used when other command modules cannot be used. This is a simple launch of remote commands to the server via SSH. This module even works on servers without Python installed.
A simple example of installing vim package:
You can see that the package is installed, but the task will not be marked as changed. It is better not to use the raw module when possible.
This module is used to copy the script to a remote machine and execute it. The module supports the creates and removes options .
Let's write a script to view the number of directories in / etc and run it on remote servers (~ / ansible / playbooks / scripts / list_number_of_directories.sh ):
A task using the script module looks like this:
The path to the script file is set relative to the location of the file using the script module. For example, if this task is described in a task file imported into a playbook, the location of the script is relative to the task file, not the playbook.
As can be seen from the output of the playbook version with the debugging information output -vv in the / etc 91 directory.
The key difference between the shell module and the command module is that it uses / bin / sh by default to run commands. You can use shell variables and other shell functions.
The file module allows you to change file attributes. You can create a file, create or delete directories recursively, create or delete a symbolic link.
Let's check that httpd.conf has the right permissions and owner:
Since Ansible scripts allow you to reach the desired state even when restarting the scripts - restarting will make sure and correct the right of access to files if necessary.
Let's see how symlinks are created:
Create directories recursively:
Ansible uses Jinja2 template language to create templates. The template module also allows you to create a file on the server.
Let's create a simple template (~ / ansible / playbooks / templates / ansible_hostname ).
The task will look like this:
Ansible created a file testfile on the servers and applied template to it. "Ansible-for-config" is the hostname value.
The template module provides a useful validate option that allows you to check a file before copying it. A classic example is the Apache configuration file. To run the syntax check, use the command:
If everything is OK, you will see “Syntax OK”. If not, you will see an error.
Let's see how to do the same check in the playbook:
If the software you are using allows you to verify configurations, you can use the validate option to use configurations safer.
Using the copy module, you can copy files to the server.
Ansible has support for various version control systems (svn, bzr, hg and others), but we’ll look at the git module.
Install git on the server:
Now we will get a repository with scripts from these articles:
Before and after the task is completed, SHA is considered, which allows you to understand whether the repository has been updated.
If you receive files via SSH, use the accept_key and key_file parameters to set the key for accessing the repository. If you need to use the key accept_key = yes. key_file points to the key path. If the key is in ~ / .ssh, you do not need to specify key_file.
The book " Learning Ansible " and of course the official documentation helped a lot in writing the article.
It is convenient to conduct all experiments with Ansible in InfoboxCloud , since there is an opportunity for each virtual server to set the exact amount of resources needed for the task (CPU / Ram / disk independently of each other) or to use autoscaling, and not to choose VM from ready-made templates. When experiments are not conducted - you can simply turn off the VM and pay only the cost of the disk.
If you find an error in the article, the author will gladly correct it. Please write in the LAN or in the mail about it. There you can also ask questions about Ansible for coverage in subsequent articles.
Part 5: local_action, conditions, cycles and roles
Successful work!
In the second part, we sorted out the output of the playbook, learned how to debug and reuse the Ansible scripts.
In the third part, we learned how to write a single Ansible playbook for different operating systems (for example, with rpm and deb), how to maintain multiple hosts and not write them all in inventory, and how to group servers by cloud regions. The use of the Ansible variables and the inventory file was examined.
')
In this part, we will learn how to use Ansible modules to configure the server: let's look at how to run the most common scripts on remote servers, use templating for configuration files, substituting the necessary variables, and how to use version control systems to get the code on the server.
Modules in Ansible
Ansible provides more than 200 modules, such as System, Network, Database, Files, and so on. You can use modules to configure your IT infrastructure.
Command module command
The module accepts the command name and the arguments Shell variables or operations (<,>, |, &) will not work with the command module, since processed by the shell. The command module accepts the following parameters:
- chdir : Used to change the current directory in which the command is executed
- creates : creates a file
- removes : deletes file
Let's write the simplest task of rebooting the server:
- name: Reboot machine command: /sbin/shutdown -r now sudo: yes Raw command module
This module should be used when other command modules cannot be used. This is a simple launch of remote commands to the server via SSH. This module even works on servers without Python installed.
A simple example of installing vim package:
- name: Install vim raw: yum -y install vim-common sudo: yes You can see that the package is installed, but the task will not be marked as changed. It is better not to use the raw module when possible.
Command script script
This module is used to copy the script to a remote machine and execute it. The module supports the creates and removes options .
Let's write a script to view the number of directories in / etc and run it on remote servers (~ / ansible / playbooks / scripts / list_number_of_directories.sh ):
#/bin/bash ls -l /etc | egrep '^d' | wc -l A task using the script module looks like this:
- name: List directories in /etc script: ~/ansible/playbooks/scripts/list_number_of_directories.sh /etc sudo: yes The path to the script file is set relative to the location of the file using the script module. For example, if this task is described in a task file imported into a playbook, the location of the script is relative to the task file, not the playbook.
As can be seen from the output of the playbook version with the debugging information output -vv in the / etc 91 directory.
Shell command module
The key difference between the shell module and the command module is that it uses / bin / sh by default to run commands. You can use shell variables and other shell functions.
File module: file
The file module allows you to change file attributes. You can create a file, create or delete directories recursively, create or delete a symbolic link.
Let's check that httpd.conf has the right permissions and owner:
- name: Ensure httpd conf has right permissions and owner/group file: path=/etc/httpd/conf/httpd.conf owner=root group=root mode=0644 sudo: yes Since Ansible scripts allow you to reach the desired state even when restarting the scripts - restarting will make sure and correct the right of access to files if necessary.
Let's see how symlinks are created:
- name: Create a symlink in /tmp for httpd.conf file: src=/etc/httpd/conf/httpd.conf dest=/tmp/httpd.conf owner=root group=root state=link sudo: yes Create directories recursively:
- name: Create recursive directories file: path=/tmp/dir1/dir2/dir3 owner=root group=root mode=0777 sudo: yes File module template
Ansible uses Jinja2 template language to create templates. The template module also allows you to create a file on the server.
Let's create a simple template (~ / ansible / playbooks / templates / ansible_hostname ).
This is a test file on {{ ansible_hostname }} The task will look like this:
- name: Create a test template template: src=test dest=/tmp/testfile mode=644 Ansible created a file testfile on the servers and applied template to it. "Ansible-for-config" is the hostname value.
The template module provides a useful validate option that allows you to check a file before copying it. A classic example is the Apache configuration file. To run the syntax check, use the command:
httpd -t -f /etc/httpd/httpd.conf If everything is OK, you will see “Syntax OK”. If not, you will see an error.
Let's see how to do the same check in the playbook:
– name: Create a virtual host template: src=test.conf dest=test.conf mode=644 validate='httpd -t -f %s' sudo: yes If the software you are using allows you to verify configurations, you can use the validate option to use configurations safer.
Copy file module
Using the copy module, you can copy files to the server.
- name: Copy file remotely copy: src=test2.conf dest=/etc/test2.conf owner=root group=root mode=0644 sudo: yes Git version control system module
Ansible has support for various version control systems (svn, bzr, hg and others), but we’ll look at the git module.
Install git on the server:
- yum: name=git state=installed sudo: yes Now we will get a repository with scripts from these articles:
- name: Checkout ansible–playground repository git: repo=https://github.com/trukhinyuri/ansible-playground.git dest=~/checkout sudo: yes Before and after the task is completed, SHA is considered, which allows you to understand whether the repository has been updated.
If you receive files via SSH, use the accept_key and key_file parameters to set the key for accessing the repository. If you need to use the key accept_key = yes. key_file points to the key path. If the key is in ~ / .ssh, you do not need to specify key_file.
Conclusion
The book " Learning Ansible " and of course the official documentation helped a lot in writing the article.
It is convenient to conduct all experiments with Ansible in InfoboxCloud , since there is an opportunity for each virtual server to set the exact amount of resources needed for the task (CPU / Ram / disk independently of each other) or to use autoscaling, and not to choose VM from ready-made templates. When experiments are not conducted - you can simply turn off the VM and pay only the cost of the disk.
If you find an error in the article, the author will gladly correct it. Please write in the LAN or in the mail about it. There you can also ask questions about Ansible for coverage in subsequent articles.
Part 5: local_action, conditions, cycles and roles
Successful work!
Source: https://habr.com/ru/post/252239/
All Articles