Примеры Ansible для сети

Ansible vault для шифрования паролей

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

Вот как это будет выглядеть, если вы указали ваши SSH-пароли (зашифрованные с помощью Ansible Vault) среди своих переменных:

ansible_connection: ansible.netcommon.network_cli
ansible_network_os: vyos.vyos.vyos
ansible_user: my_vyos_user
ansible_ssh_pass: !vault |
                  $ANSIBLE_VAULT;1.1;AES256
                  39336231636137663964343966653162353431333566633762393034646462353062633264303765
                  6331643066663534383564343537343334633031656538370a333737656236393835383863306466
                  62633364653238323333633337313163616566383836643030336631333431623631396364663533
                  3665626431626532630a353564323566316162613432373738333064366130303637616239396438
                  9853

Общие переменные инвентаризации

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

ansible_connection:

Ansible использует параметр ansible-connection для определения способа подключения к удалённому устройству. При работе с Ansible Networking установите это значение на соответствующий сетевой параметр подключения, например, ``ansible.netcommon.network_cli``, чтобы Ansible рассматривал удалённый узел как сетевое устройство с ограниченной средой выполнения. Без этого параметра Ansible попытается подключиться через ssh к удалённому узлу и выполнить Python-скрипт на сетевом устройстве, что потерпит неудачу, поскольку Python обычно недоступен на сетевых устройствах.

ansible_network_os:

Указывает Ansible, к какой сетевой платформе относятся эти хосты. Это необходимо при использовании параметров подключения ansible.netcommon.*.

ansible_user:

Пользователь, от имени которого нужно подключиться к удалённому устройству (коммутатору). Если не указано, используется пользователь, выполняющий ansible-playbook. Указывает, от имени какого пользователя на сетевом устройстве происходит подключение.

ansible_password:

Соответствующий пароль для ansible_user для входа. Если не указано, используется SSH-ключ.

ansible_become:

Если необходимо использовать режим повышения привилегий (режим с привилегиями), см. следующий раздел.

ansible_become_method:

Какой тип become должен быть использован. Для network_cli единственный допустимый выбор — enable.

Эскалация привилегий

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

[eos:vars]
ansible_connection=ansible.netcommon.network_cli
ansible_network_os=arista.eos.eos
ansible_become=yes
ansible_become_method=enable

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

Прокси-хосты

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

Шаг 1: Создание инвентаризации

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

[switches:children]
eos
ios
vyos

[eos]
eos01.example.net

[ios]
ios01.example.net

[vyos]
vyos01.example.net

Шаг 2: Создание книги задач

Далее, создайте файл книги задач с именем facts-demo.yml с содержанием:

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

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

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

    - name: Gather facts (vyos)
      vyos.vyos.vyos_facts:
      when: ansible_network_os == 'vyos.vyos.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)
      arista.eos.eos_config:
        backup: yes
      register: backup_eos_location
      when: ansible_network_os == 'arista.eos.eos'

    - name: backup switch (vyos)
      vyos.vyos.vyos_config:
        backup: yes
      register: backup_vyos_location
      when: ansible_network_os == 'vyos.vyos.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 == 'arista.eos.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.vyos.vyos'

Шаг 3: Запуск книги задач

Для запуска книги задач выполните следующую команду в командной строке:

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

Шаг 4: Проверка результатов книги задач

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

cat /tmp/switch-facts

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

find /tmp/backups

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

Пример книги задач с платформоспецифичными модулями

Этот пример предполагает три платформы: Arista EOS, Cisco NXOS и Juniper JunOS. Без платформенно-независимых модулей пример книги задач может содержать следующие три задачи с командами, специфичными для платформы:

---
- name: Run Arista command
  arista.eos.eos_command:
    commands: show ip int br
  when: ansible_network_os == 'arista.eos.eos'

- name: Run Cisco NXOS command
  cisco.nxos.nxos_command:
    commands: show ip int br
  when: ansible_network_os == 'cisco.nxos.nxos'

- name: Run Vyos command
  vyos.vyos.vyos_command:
    commands: show interface
  when: ansible_network_os == 'vyos.vyos.vyos'

Упрощённая книга задач с платформенно-независимым модулем cli_command

Вы можете заменить эти платформоспецифичные модули платформенно-независимым модулем ansible.netcommon.cli_command следующим образом:

---
- hosts: network
  gather_facts: false
  connection: ansible.netcommon.network_cli

  tasks:
    - name: Run cli_command on Arista and display results
      block:
      - name: Run cli_command on Arista
        ansible.netcommon.cli_command:
          command: show ip int br
        register: result

      - name: Display result to terminal window
        debug:
          var: result.stdout_lines
      when: ansible_network_os == 'arista.eos.eos'

    - name: Run cli_command on Cisco IOS and display results
      block:
      - name: Run cli_command on Cisco IOS
        ansible.netcommon.cli_command:
          command: show ip int br
        register: result

      - name: Display result to terminal window
        debug:
          var: result.stdout_lines
      when: ansible_network_os == 'cisco.ios.ios'

    - name: Run cli_command on Vyos and display results
      block:
      - name: Run cli_command on Vyos
        ansible.netcommon.cli_command:
          command: show interfaces
        register: result

      - name: Display result to terminal window
        debug:
          var: result.stdout_lines
      when: ansible_network_os == 'vyos.vyos.vyos'

Если вы используете группы и переменные групп по типу платформы, эту книгу задач можно ещё более упростить:

---
- name: Run command and print to terminal window
  hosts: routers
  gather_facts: false

  tasks:
    - name: Run show command
      ansible.netcommon.cli_command:
        command: "{{show_interfaces}}"
      register: command_output

Полный пример с использованием переменных групп и также пример резервного копирования конфигурации вы найдете по адресу Примеры платформенно-независимых книг задач.

Использование нескольких запросов с ansible.netcommon.cli_command

ansible.netcommon.cli_command также поддерживает несколько запросов.

---
- name: Change password to default
  ansible.netcommon.cli_command:
    command: "{{ item }}"
    prompt:
      - "New password"
      - "Retype new password"
    answer:
      - "mypassword123"
      - "mypassword123"
    check_all: True
  loop:
    - "configure"
    - "rollback"
    - "set system root-authentication plain-text-password"
    - "commit"

См. ansible.netcommon.cli_command для полной документации по этой команде.

Демо переменные

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

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

Дополнительную информацию см. в Информация об Ansible: магические переменные.

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

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

Чтобы продемонстрировать, как мы можем перенести резервный файл в другое место, мы регистрируем результат и перемещаем файл в путь, указанный в backup_path.

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