Spec-Zone.ru › Ansible

Управление BSD-узлами с помощью Ansible

Управление компьютерами BSD отличается от управления другими Unix-подобными компьютерами. Если вы управляете узлами под управлением BSD, ознакомьтесь с этими темами.

  • Подключение к BSD-узлам
  • Начальная настройка BSD
  • Настройка интерпретатора Python

    • Пакеты и порты FreeBSD
    • INTERPRETER_PYTHON_FALLBACK
    • Отладка обнаружения Python
    • Дополнительные переменные
  • Какие модули доступны?
  • Использование BSD в качестве управляющего узла
  • Факты о BSD
  • Работа над поддержкой BSD и вклад сообщества

Подключение к BSD-узлам

По умолчанию Ansible подключается к управляемым узлам с помощью OpenSSH. Это работает в BSD, если для аутентификации используются ключи SSH. Однако при использовании паролей SSH для аутентификации Ansible полагается на sshpass. Большинство версий sshpass плохо обрабатывают приглашения BSD при входе в систему, поэтому при подключении к компьютерам BSD по паролю SSH используйте для подключения paramiko вместо OpenSSH. Это можно настроить глобально в ansible.cfg либо задать как переменную инвентаря, группы или узла. Например:

[freebsd]
myfreebsdhost ansible_connection=paramiko

Начальная настройка BSD

По умолчанию Ansible не использует агентов, однако для его работы на управляемых узлах требуется Python. Без Python работает только модуль raw. Хотя этот модуль можно использовать для начальной настройки Ansible и установки Python в вариантах BSD (см. ниже), его возможности весьма ограничены, и для полноценного использования функций Ansible требуется Python.

В следующем примере устанавливается Python, включающий библиотеку json, необходимую для полной функциональности Ansible. На управляющем компьютере для большинства версий FreeBSD можно выполнить следующую команду:

ansible -m raw -a "pkg install -y python" myfreebsdhost

Или для OpenBSD:

ansible -m raw -a "pkg_add -I python%3.11" myopenbsdhost

После этого можно использовать другие модули Ansible, помимо модуля raw.

Примечание

В этом примере для FreeBSD используется pkg, а для OpenBSD — pkg_add. Однако вместо них можно использовать соответствующий инструмент управления пакетами для вашей BSD; имя пакета также может отличаться. Точное имя пакета Python, который необходимо установить, можно найти в списке пакетов или документации используемого варианта BSD.

Настройка интерпретатора Python

Для поддержки множества Unix-подобных операционных систем и дистрибутивов Ansible не всегда может полагаться на существующее окружение или переменные env, чтобы найти нужный бинарный файл Python. По умолчанию модули используют путь /usr/bin/python, поскольку это наиболее распространённое расположение. В вариантах BSD этот путь может отличаться, поэтому рекомендуется сообщить Ansible расположение бинарного файла. См. INTERPRETER_PYTHON. Например, задайте переменную инвентаря ansible_python_interpreter:

[freebsd:vars]
ansible_python_interpreter=/usr/local/bin/python
[openbsd:vars]
ansible_python_interpreter=/usr/local/bin/python3

Пакеты и порты FreeBSD

В FreeBSD нет гарантии, что по умолчанию установлен исполняемый файл /usr/local/bin/python или ссылка на исполняемый файл. При работе с удалённым узлом Ansible рекомендуется установить как минимум версию Python, поддерживаемую Ansible, например lang/python311, а также метапорты lang/python3 и lang/python. Цитата из /usr/ports/lang/python3/pkg-descr:

This is a meta port to the Python 3.x interpreter and provides symbolic links
to bin/python3, bin/pydoc3, bin/idle3 and so on to allow compatibility with
minor version agnostic Python scripts.

Цитата из /usr/ports/lang/python/pkg-descr:

This is a meta port to the Python interpreter and provides symbolic links
to bin/python, bin/pydoc, bin/idle and so on to allow compatibility with
version agnostic python scripts.

В результате устанавливаются следующие пакеты:

shell> pkg info | grep python
python-3.11_3,2                "meta-port" for the default version of Python interpreter
python3-3_4                    Meta-port for the Python interpreter 3.x
python311-3.11.10              Interpreted object-oriented programming language

а также следующие исполняемые файлы и ссылки:

shell> ls -l /usr/local/bin/ | grep python
lrwxr-xr-x  1 root wheel       7 Nov  1 18:55 python -> python3
lrwxr-xr-x  1 root wheel      14 Nov  1 18:55 python-config -> python3-config
lrwxr-xr-x  1 root wheel      10 Oct 31 11:40 python3 -> python3.11
lrwxr-xr-x  1 root wheel      17 Oct 31 11:40 python3-config -> python3.11-config
-r-xr-xr-x  1 root wheel    4744 Oct 31 11:14 python3.11
-r-xr-xr-x  1 root wheel    3113 Oct 31 11:14 python3.11-config

INTERPRETER_PYTHON_FALLBACK

Начиная с версии 2.8 в Ansible доступна полезная переменная ansible_interpreter_python_fallback, позволяющая задать список путей для поиска Python. См. INTERPRETER_PYTHON_FALLBACK. Поиск выполняется по этому списку, и используется первый найденный элемент. Например, приведённая ниже конфигурация позволит отказаться от установки метапортов из предыдущего раздела: если метапорты Python не установлены, первые два элемента списка будут пропущены, а будет обнаружен /usr/local/bin/python3.11.

ansible_interpreter_python_fallback=['/usr/local/bin/python', '/usr/local/bin/python3', '/usr/local/bin/python3.11']

Можно использовать эту переменную, дополнив список более ранними версиями Python, и, например, поместить её в group_vars/all. Затем при необходимости переопределите её для отдельных групп в group_vars/{group1, group2, ...}, а для отдельных узлов — в host_vars/{host1, host2, ...}. См. Приоритет переменных: где следует задавать переменную?.

Отладка обнаружения Python

Например, для следующего инвентаря

shell> cat hosts
[test]
test_11
test_12
test_13

[test:vars]
ansible_connection=ssh
ansible_user=admin
ansible_become=true
ansible_become_user=root
ansible_become_method=sudo
ansible_interpreter_python_fallback=['/usr/local/bin/python', '/usr/local/bin/python3', '/usr/local/bin/python3.11']
ansible_perl_interpreter=/usr/local/bin/perl

следующий плейбук

# playbook.yml
- hosts: test_11
  gather_facts: false
  tasks:
    - command: which python
      register: result
    - debug:
        var: result.stdout
    - debug:
        msg: |-
          {% for i in _vars %}
          {{ i }}:
            {{ lookup('vars', i)|to_nice_yaml|indent(2) }}
          {% endfor %}
      vars:
        _vars: "{{ query('varnames', '.*python.*') }}"

выводит подробные сведения

shell> ANSIBLE_CALLBACK_RESULT_FORMAT=yaml ansible-playbook -i hosts playbook.yml

PLAY [test_11] *******************************************************************************

TASK [command] *******************************************************************************
[WARNING]: Platform freebsd on host test_11 is using the discovered Python interpreter at
/usr/local/bin/python, but future installation of another Python interpreter could change the
meaning of that path. See https://docs.ansible.com/ansible-
core/2.18/reference_appendices/interpreter_discovery.html for more information.
changed: [test_11]

TASK [debug] *********************************************************************************
ok: [test_11] =>
    result.stdout: /usr/local/bin/python

TASK [debug] *********************************************************************************
ok: [test_11] =>
    msg: |-
        ansible_interpreter_python_fallback:
          - /usr/local/bin/python
          - /usr/local/bin/python3
          - /usr/local/bin/python3.11

        discovered_interpreter_python:
          /usr/local/bin/python

        ansible_playbook_python:
          /usr/bin/python3

Как видно, на удалённом узле FreeBSD был обнаружен первый элемент списка ansible_interpreter_python_fallback. Переменная ansible_playbook_python содержит путь к Python на управляющем узле Linux, с которого был запущен плейбук.

Что касается предупреждения, цитата из INTERPRETER_PYTHON:

The fallback behavior will issue a warning that the interpreter
should be set explicitly (since interpreters installed later may
change which one is used). This warning behavior can be disabled by
setting auto_silent or auto_legacy_silent. ...

Можно проигнорировать это предупреждение или избавиться от него, задав переменную ansible_python_interpreter=auto_silent, поскольку именно этого и следует ожидать при использовании /usr/local/bin/python («установленные позднее интерпретаторы могут изменить, какой из них будет использоваться»). Например:

shell> cat hosts
[test]
test_11
test_12
test_13

[test:vars]
ansible_connection=ssh
ansible_user=admin
ansible_become=true
ansible_become_user=root
ansible_become_method=sudo
ansible_interpreter_python_fallback=['/usr/local/bin/python', '/usr/local/bin/python3', '/usr/local/bin/python3.11']
ansible_python_interpreter=auto_silent
ansible_perl_interpreter=/usr/local/bin/perl

См. также

  • Обнаружение интерпретатора
  • Вики FreeBSD: Ports/DEFAULT_VERSIONS

Дополнительные переменные

Если вы используете дополнительные плагины, не входящие в состав Ansible, можно задать аналогичные переменные для bash, perl или ruby — в зависимости от реализации плагина. Например:

[freebsd:vars]
ansible_python_interpreter=/usr/local/bin/python
ansible_perl_interpreter=/usr/local/bin/perl

Какие модули доступны?

Большинство основных модулей Ansible предназначены для Unix-подобных компьютеров и других служб общего назначения, поэтому они должны хорошо работать в BSD. Очевидное исключение составляют модули, рассчитанные только на технологии Linux (например, LVG).

Использование BSD в качестве управляющего узла

Чтобы использовать BSD в качестве управляющего компьютера, достаточно установить пакет Ansible для вашего варианта BSD или следовать инструкциям pip либо инструкциям по установке «из исходного кода».

Факты о BSD

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

Работа над поддержкой BSD и вклад сообщества

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

См. также

Введение в ad hoc-команды

Примеры базовых команд

Работа с плейбуками

Изучение языка управления конфигурацией Ansible

Стоит ли разрабатывать модуль?

Как писать модули

Общение

Есть вопросы? Нужна помощь? Хотите поделиться идеями? Посетите руководство по общению в сообществе Ansible

© 2012–2018 Michael DeHaan
© 2018–2025 Red Hat, Inc.
Licensed under the GNU General Public License version 3.
https://docs.ansible.com/projects/ansible/latest/os_guide/intro_bsd.html

Spec-Zone.ru

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