We 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.

    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 ):
    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.


    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


    Also popular now: