Spec-Zone.ru › Ansible 2.7

Лучшие практики для сети с Ansible 2.5

Обзор

В этом документе объясняются лучшие практики использования Ansible 2.5 для управления вашей сетевой инфраструктурой.

Аудитория

  • Этот пример предназначен для сетевых или системных администраторов, которые хотят понять, как использовать Ansible для управления сетевыми устройствами.

Предварительные условия

Для этого примера требуется следующее:

  • Ansible 2.5 (или выше) установлен. См. Руководство по установке для получения дополнительной информации.
  • Одно или несколько сетевых устройств, совместимых с Ansible.
  • Базовые знания YAML Синтаксис YAML.
  • Базовые знания шаблонов Jinja2. См. Шаблоны (Jinja2) для получения дополнительной информации.
  • Базовое использование командной строки Linux.
  • Базовые знания конфигурации сетевых коммутаторов и маршрутизаторов.

Концепции

Этот раздел объясняет некоторые фундаментальные концепции, которые вы должны понять при работе с Ansible Networking.

Структура

Примеры на этой странице используют следующую структуру:

.
├── facts-demo.yml
└── inventory

Инвентаризация, подключения, учетные данные: группировка устройств и переменных

Файл inventory — это конфигурационный файл, похожий на INI, который определяет отображение хостов в группы.

В нашем примере файл инвентаризации определяет группы eos, ios, vyos и «группу групп» под названием switches. Более подробные сведения о подгруппах и файлах инвентаризации можно найти в Документации по группам инвентаризации Ansible.

Поскольку Ansible — гибкий инструмент, есть несколько способов указать информацию о подключении и учетные данные. Мы рекомендуем использовать возможность [my_group:vars] в вашем файле инвентаризации. Вот как это будет выглядеть, если вы укажете свои пароли ssh (зашифрованные с помощью Ansible Vault) среди ваших переменных:

[all:vars]
# these defaults can be overridden for any group in the [group:vars] section
ansible_connection=network_cli
ansible_user=ansible

[switches:children]
eos
ios
vyos

[eos]
veos01 ansible_host=veos-01.example.net
veos02 ansible_host=veos-02.example.net
veos03 ansible_host=veos-03.example.net
veos04 ansible_host=veos-04.example.net

[eos:vars]
ansible_become=yes
ansible_become_method=enable
ansible_network_os=eos
ansible_user=my_eos_user
ansible_ssh_pass= !vault |
                  $ANSIBLE_VAULT;1.1;AES256
                  37373735393636643261383066383235363664386633386432343236663533343730353361653735
                  6131363539383931353931653533356337353539373165320a316465383138636532343463633236
                  37623064393838353962386262643230303438323065356133373930646331623731656163623333
                  3431353332343530650a373038366364316135383063356531633066343434623631303166626532
                  9562

[ios]
ios01 ansible_host=ios-01.example.net
ios02 ansible_host=ios-02.example.net
ios03 ansible_host=ios-03.example.net

[ios:vars]
ansible_become=yes
ansible_become_method=enable
ansible_network_os=ios
ansible_user=my_ios_user
ansible_ssh_pass= !vault |
                  $ANSIBLE_VAULT;1.1;AES256
                  34623431313336343132373235313066376238386138316466636437653938623965383732373130
                  3466363834613161386538393463663861636437653866620a373136356366623765373530633735
                  34323262363835346637346261653137626539343534643962376139366330626135393365353739
                  3431373064656165320a333834613461613338626161633733343566666630366133623265303563
                  8472

[vyos]
vyos01 ansible_host=vyos-01.example.net
vyos02 ansible_host=vyos-02.example.net
vyos03 ansible_host=vyos-03.example.net

[vyos:vars]
ansible_network_os=vyos
ansible_user=my_vyos_user
ansible_ssh_pass= !vault |
                  $ANSIBLE_VAULT;1.1;AES256
                  39336231636137663964343966653162353431333566633762393034646462353062633264303765
                  6331643066663534383564343537343334633031656538370a333737656236393835383863306466
                  62633364653238323333633337313163616566383836643030336631333431623631396364663533
                  3665626431626532630a353564323566316162613432373738333064366130303637616239396438
                  9853

Если вы используете ssh-agent, вам не нужны строки ansible_ssh_pass. Если вы используете ssh-ключи, но не ssh-agent, и у вас несколько ключей, укажите ключ для каждого подключения в разделе [group:vars] с ansible_ssh_private_key_file=/path/to/correct/key. Более подробную информацию о параметрах ansible_ssh_ см. в Список поведенческих параметров инвентаризации.

Предупреждение

Никогда не храните пароли в открытом виде.

Функция «Vault» Ansible позволяет хранить конфиденциальные данные, такие как пароли или ключи, в зашифрованных файлах, а не в виде открытого текста в ваших playbook или ролях. Эти файлы vault можно затем распространять или размещать в системе контроля версий. Более подробную информацию см. в Использование Vault в playbook.

ansible_connection:
Ansible использует параметр ansible-connection, чтобы определить, как подключиться к удаленному устройству. При работе с Ansible Networking установите это значение на network_cli, чтобы Ansible обрабатывал удаленный узел как сетевое устройство с ограниченной средой выполнения. Без этого параметра Ansible попытается использовать ssh для подключения к удаленному устройству и выполнить скрипт Python на сетевом устройстве, что приведет к ошибке, так как Python обычно недоступен на сетевых устройствах.
ansible_network_os:
Уведомляет Ansible, к какой сетевой платформе относятся эти хосты. Это необходимо при использовании network_cli или netconf.
ansible_user: Пользователь для подключения к удаленному устройству (коммутатору). Без этого будет использован пользователь, выполняющий ansible-playbook. Указывает пользователя на сетевом устройстве для подключения.
ansible_ssh_pass:
Соответствующий пароль для ansible_user для входа. Если не указан, используется SSH-ключ.
ansible_become: Если необходимо использовать режим повышения привилегий (режим привилегий).
ansible_become_method:
Какой тип become должен быть использован? Для network_cli единственно допустимый выбор — enable.

Повышение привилегий

Некоторые сетевые платформы, такие как eos и ios, имеют понятие различных режимов привилегий. Некоторые сетевые модули, такие как те, которые изменяют состояние системы, включая пользователей, будут работать только в режимах повышенных привилегий. В Ansible версии 2.5 добавлена поддержка become при использовании connection: network_cli. Это позволяет повышать привилегии для конкретных задач, требующих этого. Добавление become: yes и become_method: enable сообщает Ansible перейти в режим повышенных привилегий перед выполнением задачи, как показано здесь:

[eos:vars]
ansible_connection=network_cli
ansible_network_os=eos
ansible_become=yes
ansible_become_method=enable

Дополнительную информацию см. в руководстве использование become с сетевыми модулями.

Прокси-серверы

Если у контроллера Ansible нет прямого маршрута к удаленному устройству и вам необходимо использовать прокси-сервер, см. руководство Ansible Network Proxy Command для получения подробной информации о том, как это сделать.

Playbook

Сбор данных

Модули фактов Ansible собирают информацию о системе («факты»), которая доступна для остальной части вашего playbook.

Ansible Networking поставляется с рядом модулей фактов, специфичных для сети. В этом примере мы используем модули _facts eos_facts, ios_facts и vyos_facts для подключения к удаленному сетевому устройству. Поскольку учетные данные не передаются явно через аргументы модуля, Ansible использует имя пользователя и пароль из файла инвентаризации.

Модули «Факты сети» Ansible собирают информацию из системы и сохраняют результаты в фактах с префиксом ansible_net_. Сведения, собранные этими модулями, описаны в разделе Return Values документации модуля, в этом случае eos_facts и vyos_facts. Мы можем использовать факты, такие как ansible_net_version позже в задаче «Отобразить некоторые факты».

Для обеспечения вызова правильного режима (*_facts) задача выполняется условно на основе группы, определенной в файле инвентаризации. Более подробную информацию об использовании условных выражений в Ansible Playbook см. в Оператор When.

Пример

В этом примере мы создадим файл инвентаризации, содержащий некоторые сетевые коммутаторы, затем выполним playbook для подключения к сетевым устройствам и получения информации о них.

Создайте файл инвентаризации

Сначала создайте файл под названием inventory, содержащий:

[switches:children]
eos
ios
vyos

[eos]
eos01.example.net

[ios]
ios01.example.net

[vyos]
vyos01.example.net

Создайте playbook

Далее создайте файл playbook под названием facts-demo.yml с содержанием:

- name: "Demonstrate connecting to switches"
  hosts: switches
  gather_facts: no

  tasks:
    ###
    # Collect data
    #
    - name: Gather facts (eos)
      eos_facts:
      when: ansible_network_os == 'eos'

    - name: Gather facts (ops)
      ios_facts:
      when: ansible_network_os == 'ios'

    - name: Gather facts (vyos)
      vyos_facts:
      when: ansible_network_os == 'vyos'

    ###
    # Demonstrate variables
    #
    - name: Display some facts
      debug:
        msg: "The hostname is {{ ansible_net_hostname }} and the OS is {{ ansible_net_version }}"

    - name: Facts from a specific host
      debug:
        var: hostvars['vyos01.example.net']

    - name: Write facts to disk using a template
      copy:
        content: |
          #jinja2: lstrip_blocks: True
          EOS device info:
            {% for host in groups['eos'] %}
            Hostname: {{ hostvars[host].ansible_net_hostname }}
            Version: {{ hostvars[host].ansible_net_version }}
            Model: {{ hostvars[host].ansible_net_model }}
            Serial: {{ hostvars[host].ansible_net_serialnum }}
            {% endfor %}

          IOS device info:
            {% for host in groups['ios'] %}
            Hostname: {{ hostvars[host].ansible_net_hostname }}
            Version: {{ hostvars[host].ansible_net_version }}
            Model: {{ hostvars[host].ansible_net_model }}
            Serial: {{ hostvars[host].ansible_net_serialnum }}
            {% endfor %}

          VyOS device info:
            {% for host in groups['vyos'] %}
            Hostname: {{ hostvars[host].ansible_net_hostname }}
            Version: {{ hostvars[host].ansible_net_version }}
            Model: {{ hostvars[host].ansible_net_model }}
            Serial: {{ hostvars[host].ansible_net_serialnum }}
            {% endfor %}
        dest: /tmp/switch-facts
      run_once: yes

    ###
    # Get running configuration
    #

    - name: Backup switch (eos)
      eos_config:
        backup: yes
      register: backup_eos_location
      when: ansible_network_os == 'eos'

    - name: backup switch (vyos)
      vyos_config:
        backup: yes
      register: backup_vyos_location
      when: ansible_network_os == 'vyos'

    - name: Create backup dir
      file:
        path: "/tmp/backups/{{ inventory_hostname }}"
        state: directory
        recurse: yes

    - name: Copy backup files into /tmp/backups/ (eos)
      copy:
        src: "{{ backup_eos_location.backup_path }}"
        dest: "/tmp/backups/{{ inventory_hostname }}/{{ inventory_hostname }}.bck"
      when: ansible_network_os == 'eos'

    - name: Copy backup files into /tmp/backups/ (vyos)
      copy:
        src: "{{ backup_vyos_location.backup_path }}"
        dest: "/tmp/backups/{{ inventory_hostname }}/{{ inventory_hostname }}.bck"
      when: ansible_network_os == 'vyos'

Запуск playbook

Чтобы запустить playbook, выполните следующее из командной строки:

ansible-playbook -i inventory facts-demo.yml

Должен быть выведен результат, похожий на следующий:

PLAY RECAP
eos01.example.net          : ok=7    changed=2    unreachable=0    failed=0
ios01.example.net          : ok=7    changed=2    unreachable=0    failed=0
vyos01.example.net         : ok=6    changed=2    unreachable=0    failed=0

Затем посмотрите содержимое файла, который мы создали, содержащий факты коммутатора:

cat /tmp/switch-facts

Вы также можете посмотреть резервные файлы:

find /tmp/backups

Если ansible-playbook завершится с ошибкой, следуйте шагам по устранению неполадок в руководстве Руководство по отладке и устранению неполадок сети.

Примечания по реализации

Демонстрационные переменные

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

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

Дополнительную информацию см. в Доступ к информации об других хостах с помощью магических переменных.

Получение текущей конфигурации

Модули eos_config и vyos_config имеют параметр backup:, который, если задан, заставит модуль создать полную резервную копию текущей running-config с удаленного устройства перед внесением любых изменений. Резервный файл записывается в папку backup в корневой директории playbook. Если директория не существует, она создается.

Для демонстрации того, как мы можем переместить резервный файл в другое место, мы регистрируем результат и перемещаем файл в путь, указанный в backup_path. Обратите внимание, что при использовании переменных из задач таким образом мы используем двойные кавычки (") и двойные фигурные скобки ({{...}} чтобы сообщить Ansible, что это переменная.

Устранение неполадок

Если вы получаете ошибку подключения, проверьте файл инвентаризации и playbook на наличие опечаток или отсутствующих строк. Если проблема сохраняется, следуйте шагам по устранению неполадок в руководстве Руководство по отладке и устранению неполадок сети.

END_OF_DOCUMENT_MARKER

См. также

  • Ansible для автоматизации сети
  • Работа с инвентарём
  • Рекомендации по использованию Vault

© 2012–2018 Michael DeHaan
© 2018–2019 Red Hat, Inc.
Licensed under the GNU General Public License version 3.
https://docs.ansible.com/ansible/2.7/network/user_guide/network_best_practices_2.5.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API