Ansible Network FAQ

• Как улучшить производительность для playbooks сети?

  • Рассмотрите strategy: free, если вы работаете с несколькими хостами
  • Используйте show running только в крайнем случае
  • Используйте ProxyCommand только в крайнем случае
  • Установите --forks в соответствии с вашими потребностями
• Почему мой вывод иногда заменяется на ********?
• Почему модули *_config всегда возвращают changed=true с сокращенными командами?

Как улучшить производительность для playbooks сети?

Рассмотрите strategy: free, если вы работаете с несколькими хостами

Плагин strategy сообщает Ansible, как упорядочить несколько задач на нескольких хостах. Стратегия устанавливается на уровне playbook.

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

Используя стратегию free, Ansible использует доступные потоки для выполнения задач на каждом хосте как можно быстрее. Даже если более ранняя задача все еще выполняется на одном хосте, Ansible выполняет последующие задачи на других хостах. Стратегия free использует доступные потоки более эффективно. Если ваш playbook зависает на каждой задаче, ожидая одного медленного хоста, рассмотрите использование strategy: free для повышения общей производительности.

Используйте show running только в крайнем случае

Команда show running является самой ресурсоемкой для выполнения на сетевом устройстве из-за того, как обрабатываются запросы операционной системой сети. Использование этой команды в вашем playbook Ansible значительно замедлит производительность, особенно на крупных устройствах; ее повторное использование еще больше ухудшит производительность. Если ваш playbook проверяет текущую конфигурацию, затем выполняет изменения, а затем снова проверяет текущую конфигурацию, вы можете ожидать, что этот playbook будет очень медленным.

Используйте ProxyCommand только в крайнем случае

Модули сети поддерживают использование прокси или хоста перехода с параметром ProxyCommand. Однако при использовании хоста перехода Ansible должен открывать новое SSH-соединение для каждой задачи, даже если вы используете тип постоянного соединения (network_cli или netconf). Для максимального повышения эффективности типов постоянных соединений, представленных в версии 2.5, старайтесь избегать использования хостов перехода, где это возможно.

Установите --forks в соответствии с вашими потребностями

Каждый раз, когда Ansible выполняет задачу, он создает свой собственный процесс. Параметр --forks определяет количество одновременных задач — если вы сохраните значение по умолчанию, которое составляет --forks=5, а вы работаете с playbook на 10 хостах, пять из этих хостов должны будут ждать, пока станет доступен поток. Конечно, чем больше потоков вы разрешаете, тем больше памяти и процессорной мощности Ansible будет использовать. Поскольку большинство сетевых задач выполняются на хосте управления, это означает, что ваш ноутбук может быстро стать ограниченным по процессору или памяти.

Почему мой вывод иногда заменяется на ********?

Ansible заменяет любую строку, помеченную no_log, включая пароли, на ******** в выводе Ansible. Это сделано по умолчанию для защиты ваших конфиденциальных данных. Большинство пользователей рады, что их пароли заменены. Однако Ansible заменяет каждую строку, соответствующую вашему паролю, на ********. Если вы используете общее слово для своего пароля, это может стать проблемой. Например, если вы выберете Admin в качестве своего пароля, Ansible заменит каждое вхождение слова Admin на ******** в вашем выводе. Это может сделать ваш вывод труднее для чтения. Чтобы избежать этой проблемы, выберите надежный пароль, который не будет встречаться в другом месте в вашем выводе Ansible.

Почему модули *_config всегда возвращают changed=true с сокращенными командами?

При вводе команд непосредственно на сетевом устройстве вы можете использовать сокращенные команды. Например, int g1/0/11 и interface GigabitEthernet1/0/11 делают одно и то же; shut и shutdown делают одно и то же. Модули Ansible Network *_command работают с сокращениями, потому что они выполняют команды через операционную систему сети.

Однако при внесении изменений в конфигурацию операционная система сети преобразует сокращения в команды в полном формате. Используете ли вы shut или shutdown на GigabitEthernet1/0/11, результат в конфигурации будет одинаковым: shutdown.

Модули Ansible Network *_config сравнивают текст команд, которые вы указываете в lines, с текстом в конфигурации. Если вы используете shut в разделе lines вашей задачи, а конфигурация содержит shutdown, модуль возвращает changed=true, даже если конфигурация уже верна. Ваша задача будет обновлять конфигурацию каждый раз при запуске.

Чтобы избежать этой проблемы, используйте команды в полном формате с модулями *_config:

---
- hosts: all
  gather_facts: no
  tasks:
    - cisco.ios.ios_config:
        lines:
          - shutdown
        parents: interface GigabitEthernet1/0/11