Методы подключения и подробная информация

ControlPersist и paramiko

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