Способы и детали подключения

В этом разделе показано, как расширить и уточнить методы подключения, используемые Ansible для вашего инвентаря.

ControlPersist и paramiko

По умолчанию Ansible использует собственный OpenSSH, поскольку он поддерживает ControlPersist (функцию повышения производительности), Kerberos и параметры в ~/.ssh/config, такие как настройка Jump Host. Если ваш управляющий узел использует более старую версию OpenSSH, которая не поддерживает ControlPersist, Ansible переключится на Python-реализацию OpenSSH под названием «paramiko».

Установка удалённого пользователя

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

---
- name: update webservers
  hosts: webservers
  remote_user: admin

  tasks:
  - name: thing to do first in this playbook
  . . .

в качестве переменной хоста в инвентаре:

other1.example.com     ansible_connection=ssh        ansible_user=myuser
other2.example.com     ansible_connection=ssh        ansible_user=myotheruser

или как переменную группы в инвентаре:

cloud:
  hosts:
    cloud1: my_backup.cloud.com
    cloud2: my_backup2.cloud.com
  vars:
    ansible_user: admin

Настройка SSH-ключей

По умолчанию Ansible предполагает, что вы используете SSH-ключи для подключения к удалённым машинам. Использование SSH-ключей рекомендуется, но вы можете использовать аутентификацию по паролю, если необходимо, с опцией --ask-pass. Если вам нужно указать пароль для повышения привилегий (sudo, pbrun и так далее), используйте --ask-become-pass.

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

$ ssh-agent bash
$ ssh-add ~/.ssh/id_rsa

В зависимости от вашей настройки, вы можете использовать командную опцию Ansible --private-key, чтобы указать файл pem вместо этого. Вы также можете добавить файл закрытого ключа:

$ ssh-agent bash
$ ssh-add ~/.ssh/keypair.pem

Другой способ добавить файлы закрытых ключей без использования ssh-agent — использование ansible_ssh_private_key_file в файле инвентаря, как описано здесь: Как создать ваш инвентарь.

Работа с localhost

Вы можете запускать команды на управляющем узле, используя «localhost» или «127.0.0.1» в качестве имени сервера:

$ ansible localhost -m ping -e 'ansible_python_interpreter="/usr/bin/env python"'

Вы можете явно указать localhost, добавив это в ваш файл инвентаря:

localhost ansible_connection=local ansible_python_interpreter="/usr/bin/env python"

Управление проверкой ключа хоста

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

Если хост переустановлен и имеет другой ключ в «known_hosts», это приведет к сообщению об ошибке, пока проблема не будет исправлена. Если новый хост отсутствует в «known_hosts», ваш управляющий узел может запросить подтверждение ключа, что приводит к интерактивному опыту при использовании Ansible, например, из cron. Возможно, вам этого не нужно.

Если вы понимаете последствия и хотите отключить это поведение, вы можете сделать это, отредактировав /etc/ansible/ansible.cfg или ~/.ansible.cfg.

[defaults]
host_key_checking = False

В качестве альтернативы это можно установить переменной среды ANSIBLE_HOST_KEY_CHECKING:

$ export ANSIBLE_HOST_KEY_CHECKING=False

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

Другие способы подключения

Ansible может использовать различные способы подключения помимо SSH. Вы можете выбрать любой плагин подключения, включая локальное управление и управление контейнерами chroot, lxc и jail. Режим «ansible-pull» также может инвертировать систему и заставить системы «обращаться в центр» через запланированные git-проверки, чтобы получать директивы конфигурации из центрального репозитория.