Автоматизируем и ускоряем процесс настройки облачных серверов с Ansible. Часть 4: работаем с модулями

    В первой части мы начали изучение Ansible, популярного инструмента для автоматизации настройки и развертывания ИТ-инфраструктуры. Ansible был успешно установлен в InfoboxCloud, описаны принципы работы, базовая настройка. В завершении статьи мы показали как быстро установить nginx на несколько серверов.

    Во второй части мы разобрались в выводе playbook, научились отлаживать и повторно использовать скрипты Ansible.

    В третьей части мы узнали как написать единый Ansible playbook для разных ОС (например с rpm и deb), как обслуживать множество хостов и не писать их все в inventory, и как сгруппировать сервера по регионам облака. Было изучено использование переменных Ansible и файла inventory.



    В этой части мы научимся использовать модули Ansible для настройки сервера: разберемся, как запускать самые обычные скрипты на удаленных серверах, использовать шаблонизацию для файлов конфигурации, подставляя необходимые переменные, и как использовать системы управления версиями для получения кода на сервер.

    Модули в Ansible


    Ansible предоставляет более 200 модулей, таких как System, Network, Database, Files и так далее. Вы можете использовать модули для настройки своей IT-инфраструктуры.

    Командный модуль command

    Модуль принимает имя команды и армументы. Переменные оболочки или операции (<,>,|,&) не будут работать с модулем command, т.к. обрабатываются оболочкой. Модуль command принимает следующие параметры:
    • chdir: Используется для изменения текущей директории, в которой исполняется команда
    • creates: Создает файл
    • removes: Удаляет файл

    Давайте напишем простейшую задачу перезагрузки сервера:
    - name: Reboot machine
      command: /sbin/shutdown -r now
      sudo: yes
    



    Командный модуль raw

    Этот модуль следует использовать, когда другие командные модули использовать не удается. Это простой запуск удаленных команд серверу по SSH. Данный модуль работает даже на серверах без установленного Python.

    Простой пример установки пакета vim:
    - name: Install vim
      raw: yum -y install vim-common
      sudo: yes
    



    Вы сможете увидеть, что пакет установлен, но задача не будет помечена как changed. Лучше не использовать raw модуль когда возможно.

    Командный модуль script

    Этот модуль используется для копирования скрипта на удаленную машину и исполнения его. Модуль поддерживает параметры creates и removes.

    Давайте напишем скрипт для просмотра количества директорий в /etc и запустим его на удаленных серверах (~/ansible/playbooks/scripts/list_number_of_directories.sh):
    #/bin/bash
    ls -l /etc | egrep '^d' | wc -l
    

    Задача, использующая модуль script выглядит так:
    - name: List directories in /etc
     script: ~/ansible/playbooks/scripts/list_number_of_directories.sh /etc
     sudo: yes
    

    Путь к файлу скрипта задается относительно месторасположения файла, использующего модуль script. Например, если данная задача описана в файле задачи, импортированном в playbook, расположение скрипта задается относительно файла задачи, а не playbook.



    Как видно из вывода исполнения playbook с выводом отладочной информации -vv в /etc 91 директория.

    Командный модуль shell

    Ключевое отличие модуля shell от модуля command в том, что он использует /bin/sh по умолчанию для запуска команд. Вы можете использовать переменные оболочки и другие функции оболочки.

    Файловый модуль: file

    Модуль file позволяет вам изменять атрибуты файла. Вы можете создать файл, создать или удалить директории рекурсивно, создать или удалить символическую ссылку.

    Давайте проверим, что httpd.conf имеет правильные права и владельца:
     - 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
    

    Так как скрипты Ansible позволяют достичь нужного состояния и при перезапуске скриптов — повторный запуск позволит убедиться и поправить при необходимости права на доступ к файлам.

    Посмотрим, как создаются симлинки:
     - 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
    

    Создадим директории рекурсивно:
     - name: Create recursive directories
      file: path=/tmp/dir1/dir2/dir3 owner=root group=root mode=0777
      sudo: yes
    

    Файловый модуль template

    Для создания шаблонов Ansible использует язык шаблонизации Jinja2. Модуль template позволяет также создавать файл на сервере.

    Давайте создадим простейший шаблон (~/ansible/playbooks/templates/ansible_hostname).
    This is a test file on {{ ansible_hostname }}
    

    Задача будет выглядеть так:
     - name: Create a test template
       template: src=test dest=/tmp/testfile mode=644
    



    Ansible создала файл testfile на серверах и применила шаблонизацию к нему. «ansible-for-config» – значение hostname.



    Модуль template предоставляет полезную опцию validate, позволяющую проверить файл до его копирования. Классический пример — файл конфигурации Apache. Для запуска проверки синтаксиса используется команда:
    httpd -t -f /etc/httpd/httpd.conf
    

    Если все ОК — вы увидите «Syntax OK». Если нет — вы увидите ошибку.

    Давайте посмотрим, как сделать такую же проверку в playbook:
     – name: Create a virtual host
      template: src=test.conf dest=test.conf mode=644 validate='httpd -t -f %s'
      sudo: yes
    

    Если используемое ПО позволяет делать проверку конфигураций, вы с помощью опции validate сможете безопаснее применять конфигурации.

    Файловый модуль copy

    С помощью модуля copy можно копировать файлы на сервер.
     - name: Copy file remotely
      copy: src=test2.conf dest=/etc/test2.conf owner=root group=root mode=0644
      sudo: yes
    

    Модуль системы управления версиями git

    В Ansible есть поддержка различных систем управления версиями (svn, bzr, hg и другие), но мы рассмотрим модуль git.

    Установим git на сервера:
     - yum: name=git state=installed
      sudo: yes
    

    Теперь получим репозиторий со скриптами из этих статей:
    - name: Checkout ansible–playground repository
      git: repo=https://github.com/trukhinyuri/ansible-playground.git dest=~/checkout
      sudo: yes
    



    До и после выполнения задачи считается SHA, который позволяет понять, был ли репозиторий обновлен.

    Если вы получаете файлы по SSH – используйте параметры accept_key и key_file для установки ключа для доступа к репозиторию. Если нужно использовать ключ accept_key=yes. key_file указывает на путь к ключу. Если ключ находится в ~/.ssh – указывать key_file не нужно.

    Заключение


    В написании статьи очень помогла книга "Learning Ansible" и конечно официальная документация.

    Все эксперименты с Ansible удобно проводить в InfoboxCloud, так как имеется возможность для каждого виртуального сервера установить именно то количество ресурсов, которое необходимо для задачи (CPU/Ram/диск независимо друг от друга) или использовать автомасштабирование, а не выбирать VM из готовых шаблонов. Когда эксперименты не проводятся — можно просто выключить VM и оплачивать только стоимость диска.

    Если вы обнаружили ошибку в статье, автор ее с удовольствием исправит. Пожалуйста напишите в ЛС или на почту о ней. Туда же можно задавать вопросы по Ansible для освещения в последующих статьях.

    Часть 5: local_action, условия, циклы и роли

    Успешной работы!
    Infobox
    34.76
    Company
    Share post

    Comments 12

      +3
      Перевод официальной документации мало кому интересен. Таких статей в интернете и так уже достаточно. Даже на хабре. Гораздо более интересен реальный опыт продакшна, реальные проблемы, возникшие в процессе работы и реальные способы их решения.
        0
        Во-первых это все же не перевод официальной документации. А во-вторых мы хотим в статьях активно использовать ansible, но практика показала, что используется он не так широко, как хотелось бы. Поэтому сначала надо рассказать пользователям о том, как вообще читать и писать скрипты Ansible, а потом уже показывать реальное применение. Дойдем и до него.
          0
          А зачем писать скрипты ансибла, когда 90% работы с ним — это использование galaxy?
            0
            Чтобы использовать инструмент, понимая как он работает. Это важно даже если вы решаете стандартные задачи (хотя практика показывает, что задачи пользователей далеко не всегда стандартные). Запускать чужие скрипты без понимания что происходит — путь к проблемам.
              0
              Старинный подход. Вы всё равно не понимаете, как оно работает, просто можете знать чуть больше или чуть меньше. А дальше там только практика.

              От того, что новичок будет отлично знать как правильно делать conditionals, но ни в зуб ногой как правильно чужие роли использовать, ему легче не станет.

              Процесс обучения, стимулирующий к «написанию своего» — это прямое противоречие с идеологией любой системы управления конфигурациями «меньше пиши, больше делай в единицу времени».
                0
                Запуск чужого — только одна часть системы управления конфигурациями. Пиши свое, запускай много раз и развертывай где угодно — это вторая часть решаемых задач.
              0
              Наверное затем, что чтение исходников тех ролей, что стянуты с галактики, оставляет в глубокой грусти и раздумьях. Ну, по крайней мере меня.

              Человек правильно пишет, что ансибль крайне прост для понимания и quickstart-а, но сложности возникают, когда пытаешься применить на практике. И этого в официальной документации просто не было, когда последний раз смотрел.
          +1
          А в есть, собственно, модули ansible для работы с вашим облаком?
            0
            Особой необходимости в них пока не было — можно использовать ansible и в режиме local_action отдавать команды утилите для работы с облаком из командной строки github.com/tsukaeru/pacicli. Так например можно создавать новые сервера с ansible–сервера. Адрес управляющего API сервера: ciapi.pa.infobox.ru:4464. Если будут запросы от пользователей — можно сделать и модуль для ansible.
            0
            Смотрел как-то на Ansible — не понравилось наличие gui только в коммерческой версии, и отсутствие opensource альтернатив.
            + зачаточная поддержка Windows (поддерживаем зоопарк)… Расскажите, как сейчас обстоят дела с этими двумя вещами?
              0
              awx доступен в бесплатной версии для 10 серверов. Поддержка win серверов есть, сами юзаем.
                0
                Я не говорю что поддержки совсем нет. В случае с puppet и chef windows уже достаточно хорошо поддерживается на уровне функционала модулей. IIs сайты конфигурируется из коробки, пакеты ставятся через chocolatey, и тому подобное…
                Про GUI — по мне, 10 нод это смешно… Мы используем theforeman, похоже недавно появилась интеграция с ansible, посмотрите.
                Кстати, TheForeman это не только внешний классификатор для puppet/chef/ansible/salt..., но и прекрасный инструмент управления полным циклом жизни (lifecycle) машины. Успешно используется как интегрированная среда для гибридного ЦОД (AWS/BareMetal/VmWare).

            Only users with full accounts can post comments. Log in, please.