Что нужно помнить о Ansible

Инвентарный файл

это то с чего надо начинать работу, по умолчанию хранится в /etc/ansible/hosts , Можно создать свой , и указать его при запуске с помощью команды-i myhosts.ini либо прописать путь к нему в конфигурационном файле inventory = ./myhosts.ini( о нем поговорим позднее ) .

в этом инвентарном файле храниться информация о хостах, с которыми мы будем работать . файл может быть в формате ini или yaml, я привык использовать формат ini . На схеме ниже приведена логика конфигурации инвентарного файла в формате ini:

создадим простой инвентарный файл myhosts.ini :

[cisco_routers]
Router1   ansible_host=10.101.101.64
Router2   ansible_host=10.101.101.63
Router3   ansible_host=10.101.101.65
[cisco_routers:vars]
ansible_connection=network_cli
ansible_network_os=ios
ansible_user=cisco
ansible_password=cisco123

Конфигурационный файл

Конфигурационный файл Ansible может храниться в разных местах (файлы перечислены в порядке уменьшения приоритета):

• ANSIBLE_CONFIG (переменная окружения)
• ansible.cfg (в текущем каталоге)
• ~/.ansible.cfg (в домашнем каталоге пользователя)
• /etc/ansible/ansible.cfg

Ansible ищет конфигурационный файл в выше приведенном порядке , и использует первый найденный, все остальные игнорируются. Ниже приведен простой конфигурационный файл :

[defaults]
inventory = ./myhosts.ini
remote_user = cisco
ask_pass = True
gathering = explicit
host_key_checking=False
interpreter_python = /usr/bin/python3

• [defaults] - эта секция конфигурации описывает общие параметры по умолчанию
• inventory = ./hosts.ini - параметр inventory позволяет указать местоположение инвентарного файла. Если настроить этот параметр, не придется указывать, где находится файл, при каждом запуске Ansible
• remote_user = cisco - от имени какого пользователя будет подключаться Ansible
• ask_pass = True - этот параметр аналогичен опции –ask-pass в командной строке. Если он выставлен в конфигурации Ansible, то уже не нужно указывать его в командной строке.
• gathering = explicit — По умолчанию Ansible собирает факты об устройствах. Факты — это информация о хостах, к которым подключается Ansible. Сбором фактов, по умолчанию, занимается модуль setup. Но для сетевого оборудования модуль setup не подходит, поэтому сбор фактов надо отключить. Это можно сделать в конфигурационном файле Ansible или в playbook.
• host_key_checking=False — Параметр отвечает за проверку ключей при подключении по SSH. Если указать в конфигурационном файле False, проверка будет отключена. Это полезно, когда с управляющего хоста Ansible надо подключиться к большому количеству устройств первый раз.

Ad Hoc команды

c помощью Ad-hoc команд — мы можем запускать различные действия из командной строки . Это самый простой и быстрый способ использования Ansible. Для начала нужно создать новый инвентарный файл, мы уже создали myhosts.ini . сейчас наша рабочая директория выглядит так :

.
├── ansible.cfg
├── myhosts.ini

теперь сделаем запрос с использованием ad-hoc команды :

ansible Router3 -i myhosts.ini -c network_cli -e ansible_network_os=ios -u cisco -k -m ios_command -a "commands='sh ip arp '"

Разберемся с параметрами команды:

• Router3 - устройство, к которому нужно применить действие

это устройство должно существовать в инвентарном файле

это может быть группа, конкретное имя или адрес

если нужно указать все хосты из файла, можно использовать значение all или *

• -i myhosts.ini - параметр -i позволяет указать инвентарный файл
• -c network_cli - параметр -c позволяет указать тип подключения. Тип network_cli подразумевает передачу команд через SSH имитируя человека. Для работы network_cli обязательно нужно указывать network_os, в данном случае, это IOS -e ansible_network_os=ios
• -u cisco - подключение выполняется от имени пользователя cisco
• -k - параметр, который нужно указать, чтобы аутентификация была по паролю, а не по ключам
• -m ios_command - параметр указывает какой модуль используется
• -a "commands='sh ip arp'" - параметр -a указывает, какую команду отправить

Большинство параметров можно указать в инвентарном файле или в файле переменных( о них еще поговорим) . В нашем инвентарном файле уже указана часть параметров, поэтому команду запроса можно сократить :

ansible Router3  -m ios_command -a "commands='sh ip arp '"

результат выполнения будет таким :

Модули

Это небольшие программы, каждый модуль выполняет конкретную задачу . Модули можно выполнять отдельно в ad-hoc командах , как мы это сделали выше, указав используемый модуль с помощью -m ios_command , затем передали этому модулю аргумент -a “commands=’sh ip arp ‘“ , в нашем случае аргумент это команда которую надо выполнить на удаленном устройстве, есть так же аргументы которые влияют на поведение модулей. Модули так же можно прописывать в Playbook . После выполнения модуль возвращает результаты в формате JSON.

В Ansible модули разделены на следующие категории :

• core — модули, которые поддерживает основная команда разработчиков Ansible.
• network — поддерживает Ansible Network Team.
• certified — поддерживают партнеры Ansible
• community — поддерживает сообщество Ansible

Playbooks

это файлы в которых прописаны сценарии действий , которые нужно выполнить с какой то группой хостов .

playbook состоит из :

• Play — набор задач которые нужно выполнить для группы хостов
• task — конкретная задача .

ниже схема простого playbook’a использующего модуль ios_command:

Мы создали playbook и назвали его playbook-1, и того в нашей рабочей директории теперь три файла :

.
├── ansible.cfg
├── myhosts.ini
└── test1-playbook.yaml

для запуска ansible с использование playbook нужно ввести ansible-playbook, затем название плейбука :

$ ansible-playbook playbook-1.yaml

вывод будет таким :

По дефолту ansible при использовании плейбука возвращает статус, корректно ли отработали сценарии плейбука. Если при вводе добавить ключ -v , то мы увидим процесс выполнения выполнения и вывод примененных команда , но он будет довольно трудным для прочтения. Чтоб вывод был более понятным используются специальные параметры register и debug , первый записывает вывод в указанную переменную , второй выводит данные переменной. В общем в плейбуке применение этих параметров будет выглядеть так :

---
- name:  show clock 
  hosts: all 
  gather_facts: false
tasks: 
   - ios_command: 
      commands: show clock
     register: sh_vr 
   - debug: var=sh_vr.stdout_lines
- name:  show arp play 
  hosts: all 
  gather_facts: false
tasks:
    - name: show arp 
      ios_command:
        commands: 
          - show arp 
          - show ip arp 
      register: sh_result
    - name: debug register 
      debug: var=sh_result.stdout_lines

результат работы такого плейбука будет довольно наглядным :

Сохранение выходных данных

Для сохранения данных используется специальный параметр copy , работает примерно так же как debug, только записывает данные в указанный файл.

---
- name:  show clock 
  hosts: all 
  gather_facts: false
tasks: 
   - ios_command: 
      commands: show clock
     register: sh_vr 
   - debug: var=sh_vr.stdout_lines
- name:  show arp play 
  hosts: all 
  gather_facts: false
tasks:
    - name: show arp 
      ios_command:
        commands: 
          - show arp 
          - show ip arp 
      register: sh_result
    - name: debug register 
      debug: var=sh_result.stdout_lines
- name: copy to file result 
      copy:
        content: "{{ sh_result.stdout_lines | to_nice_json}}"
        dest: "~/output/{{inventory_hostname}}_sh_arp.json"

после этого в указанной директории появятся файлы с выводными данными, обратите внимание на переменную inventory_hostname мы ее не где не указывали, это дефолтная переменная в которую подставляются хосты из инвентарного файла. Более сложные задачи разберем в следующих статьях .