March 5, 2015 at 05:55We automate and speed up the process of setting up cloud servers with Ansible. Part 4: working with modules
In the first part, we started exploring Ansible, a popular tool for automating the configuration and deployment of IT infrastructure. Ansible was successfully installed in InfoboxCloud , the principles of work, basic setup are described. At the end of the article, we showed how to quickly install nginx on several servers.
In the second part, we figured out the output of a playbook, learned how to debug and reuse 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 serve many hosts and not write all of them in inventory, and how to group servers by cloud regions. We studied the use of Ansible variables and the inventory file.
In this part, we will learn how to use Ansible modules to configure the server: we will figure out how to run the most common scripts on remote servers, use the template for configuration files, substituting the necessary variables, and how to use version control systems to get the code to 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 arguments. Shell variables or operations (<,>, |, &) will not work with the command module, because processed by the shell. The command module accepts the following parameters:
Let's write the simplest server restart task:
This module should be used when other command modules cannot be used. This is a simple way to run remote commands to the server via SSH. This module works even on servers without Python installed.
A simple example of installing a 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 a 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 a script module looks like this:
The path to the script file is relative to the location of the file using the script module. For example, if a given task is described in a task file imported into a playbook, the location of the script is set relative to the task file, not the playbook.
As you can see from the output of the playbook execution with the output of debugging information -vv to 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 verify that httpd.conf has the correct rights and ownership:
Since Ansible scripts allow you to achieve the desired state when restarting the scripts, restarting it will allow you to verify and correct file access rights if necessary.
Let's see how symlinks are created:
Create directories recursively:
Ansible uses the 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 testfile on the servers and applied templating to it. "Ansible-for-config" is the hostname value.
The template module provides a useful validate option to check the file before copying it. A classic example is the Apache configuration file. To start 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 a playbook:
If the software you use allows you to check configurations, you can use the validate option to apply configurations more safely.
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 will look at the git module.
Install git on the server:
Now we get the repository with scripts from these articles:
Before and after the task is completed, the 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 to access the repository. If you need to use the accept_key = yes key. key_file points to the key path. If the key is in ~ / .ssh, you do not need to specify key_file.
The writing of the article was greatly helped by the book Learning Ansible and of course the official documentation .
All experiments with Ansible are conveniently carried out in InfoboxCloud , since it is possible for each virtual server to set exactly the amount of resources that is necessary for the task (CPU / Ram / disk independently of each other) or use autoscaling, rather than choosing a VM from ready-made templates. When experiments are not carried out - you can just turn off the VM and pay only the cost of the disk.
If you find a mistake in the article, the author will gladly correct it. Please write to the PM or e-mail about it. There you can ask questions about Ansible for coverage in subsequent articles.
Part 5: local_action, conditions, loops and roles of
Success!
In the second part, we figured out the output of a playbook, learned how to debug and reuse 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 serve many hosts and not write all of them in inventory, and how to group servers by cloud regions. We studied the use of Ansible variables and the inventory file.
In this part, we will learn how to use Ansible modules to configure the server: we will figure out how to run the most common scripts on remote servers, use the template for configuration files, substituting the necessary variables, and how to use version control systems to get the code to 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
The module accepts the command name and arguments. Shell variables or operations (<,>, |, &) will not work with the command module, because 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 : Removes a file.
Let's write the simplest server restart task:
- 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 way to run remote commands to the server via SSH. This module works even on servers without Python installed.
A simple example of installing a 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.
Script command module
This module is used to copy a 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 a 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 relative to the location of the file using the script module. For example, if a given task is described in a task file imported into a playbook, the location of the script is set relative to the task file, not the playbook.
As you can see from the output of the playbook execution with the output of debugging information -vv to 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 verify that httpd.conf has the correct rights and ownership:
- 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 achieve the desired state when restarting the scripts, restarting it will allow you to verify and correct file access rights 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
Template file module
Ansible uses the 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 testfile on the servers and applied templating to it. "Ansible-for-config" is the hostname value.
The template module provides a useful validate option to check the file before copying it. A classic example is the Apache configuration file. To start 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 a 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 use allows you to check configurations, you can use the validate option to apply configurations more safely.
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 will look at the git module.
Install git on the server:
- yum: name=git state=installed
sudo: yes
Now we get the 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, the 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 to access the repository. If you need to use the accept_key = yes key. key_file points to the key path. If the key is in ~ / .ssh, you do not need to specify key_file.
Conclusion
The writing of the article was greatly helped by the book Learning Ansible and of course the official documentation .
All experiments with Ansible are conveniently carried out in InfoboxCloud , since it is possible for each virtual server to set exactly the amount of resources that is necessary for the task (CPU / Ram / disk independently of each other) or use autoscaling, rather than choosing a VM from ready-made templates. When experiments are not carried out - you can just turn off the VM and pay only the cost of the disk.
If you find a mistake in the article, the author will gladly correct it. Please write to the PM or e-mail about it. There you can ask questions about Ansible for coverage in subsequent articles.
Part 5: local_action, conditions, loops and roles of
Success!