Настройка управляющей машины
На управляющей машине устанавливаем ansible:# apt-get install ansibleВ домашнем каталоге создаём каталог, в котором будем хранить все файлы для настройки удалённых компьютеров. Если нужно работать над проектом совместно с другими системными администраторами и отслеживать изменения, сделанные ими, то лучше сразу же создать в этом каталоге git-репозиторий:
$ mkdir playbooks $ git initСоздадим файл конфигурации ansible.cfg и пропишем в него следующие настройки:
[defaults] inventory = hosts remote_user = ansible private_key_file = .ssh/id_rsaСразу же сгенерируем ssh-ключ, который будем устанавливать на удалённые системы для их настройки при помощи ansible:
$ mkdir .ssh $ ssh-keygen -f .ssh/id_rsa $ chmod go= -R .sshКаталог .ssh помещать в git-репозиторий не стоит.
Создадим файл hosts, в котором будем отмечать узлы, управляемые при помощи ansible. Например, файл с одним-единственным узлом с именем mon может выглядеть следующим образом:
mon ansible_host=169.254.252.2
Настройка управляемой машины
На управляемой машине после настройки сети и установки OpenSSH-сервера необходимо установить несколько пакетов, которые будут использоваться ansible:# apt-get install python2.7-minimal python2.7-stdlib python-minimalТакже установим sudo, чтобы при удалённой настройке можно было выполнять действия от имени пользователя root:
# apt-get install sudoДобавим учётную запись специально для удалённой настройки:
# useradd -c 'Ansible account' -m ansibleСразу же дадим возможность этой учётной записи использовать sudo для работы с правами пользователя root:
# visudoДобавляем строчки:
Defaults:ansible !requiretty ansible ALL=(root:ALL) NOPASSWD:ALLСкопируем на удалённую машину SSH-ключ:
$ ssh-copy-id -i .ssh/id_rsa.pub ansible@169.254.252.2
Первый сценарий
Для первого сценария возьмём простейшую задачу - настройки файла /etc/resolv.conf на удалённом компьютере.Создадим на управляющей машине в каталоге проекта файл сценария resolvconf.yml со следующим содержимым:
---
- name: Configure resolv.conf
hosts: mon
become: True
tasks:
- name: copy /etc/resolv.conf
template:
src: templates/resolv.conf
dest: /etc/resolv.conf
owner: root
group: root
mode: 0644Создадим каталог templates для шаблонов файлов конфигурации:$ mkdir templatesСоздадим шаблон конфигурации templates/resolv.conf для файла /etc/resolv.conf управляемого компьютера:
{% if resolvconf.domain %}
domain {{ resolvconf.domain }}
{% endif %}
{% for ip in resolvconf.nameservers %}
nameserver {{ ip }}
{% endfor %}Значения переменных хранятся в так называемом реестре ansible. Он представляет собой файл в формате YML и может находиться либо в каталоге host_vars, либо в каталоге group_vars. В каталоге host_vars хранятся настройки, специфичные для каждого отдельного управляемого узла. Внутри этого каталога создаётся фай, имя которого совпадает с указанным в файле hosts. В каталоге group_vars хранятся настройки, общие для определённой группы узлов. Внутри этого каталога создаётся файл, имя которого совпадает с именем группы, указанным в файле hosts.Создадим каталог host_vars с переменными узлов:
$ mkdir host_varsИ внутри каталога создадим файл mon со следующим содержимым:
resolvconf:
domain: stupin.su
nameservers:
- 169.254.252.1Осталось выполнить наш первый простейший сценарий. Для этого воспользуемся командой ansible-playbook:$ ansible-playbook resolvconf.yml
Переключение на непривилегированного пользователя
В прошлом сценарии имелась опция, которая заставляла выполнять действия от имени пользователя root:become: TrueВ случае, если нужно выполнять действия от имени другого, непривилегированного пользователя, можно столкнуться с проблемами. Например, администратором баз данных PostgresSQL является системный пользователь postgres. Создать нового пользователя или базу данных можно только от его имени. Поэтому, задача такого вида:
- name: createuser -P <login>
postgresql_user:
name: "{{ item.login }}"
password: "{{ item.password }}"
with_items: "{{ postgresql_databases }}"
when: postgresql_databasesЗавершится такой ошибкой:unable to connect to database: ВАЖНО: пользователь "postgres" не прошёл проверку подлинности (Peer)Однако и простого указания опций переключения на пользователя postgres оказывается недостаточно:
- name: createuser -P <login>
become: True
become_user: postgres
postgresql_user:
name: "{{ item.login }}"
password: "{{ item.password }}"
with_items: "{{ postgresql_databases }}"
when: postgresql_databasesВ этом случае попытка выполнить задачу завершается следующей ошибкой (отформатировано для наглядности):Failed to set permissions on the temporary files Ansible needs to create when becoming an unprivileged user (rc: 1, err: chown: изменение владельца '/tmp/ansible-tmp-1549203485.91-25063771984034/': Операция не позволена chown: изменение владельца '/tmp/ansible-tmp-1549203485.91-25063771984034/postgresql_user.py': Операция не позволена ). For information on working around this, see https://docs.ansible.com/ansible/become.html#becoming-an-unprivileged-userПосле доработки в соответствии с материалами по ссылке, указанной в тексте ошибки, задача приобретает следующий вид:
- name: createuser -P <login>
become: yes
become_user: postgres
vars:
ansible_ssh_pipelining: true
postgresql_user:
name: "{{ item.login }}"
password: "{{ item.password }}"
with_items: "{{ postgresql_databases }}"
when: postgresql_databasesНо и этого оказывается недостаточно, т.к. возникает следующая ошибка:failed: [mon] (item={u'login': u'zabbix', u'password': u'xxxxxxxxxxxxxxxx', u'name': u'zabbix'}) => {
"failed": true,
"item": {
"login": "zabbix",
"name": "zabbix",
"password": "xxxxxxxxxxxxxxxx"
},
"module_stderr": "sudo: a password is required\n",
"module_stdout": ""
}
MSG:
MODULE FAILUREКак видно, ansible пытается переключиться на указанного пользователя при помощи sudo. Но, когда я настраивал sudo для ansible, то указал разрешение переключаться без указания пароля только на пользователя root:ansible ALL=(root:ALL) NOPASSWD:ALLЧтобы разрешить пользователю ansible переключаться ещё и на пользователя postgres, нужно добавить через команду visudo ещё одно разрешение:
ansible ALL=(postgres:ALL) NOPASSWD:ALLПосле этого задача выполняется успешно.
Немедленный перезапуск сервиса при изменениях
Иногда отложенный перезапуск сервиса может таить в себе проблемы. Например, если в конфигурации сервиса изменился прослушиваемый им порт, новые настройки не вступят в силу, пока не будет достигнут конец сценария. В то же время, действия, выполняемые до вызова отложенного перезапуска сервиса, могут использовать новый порт для подключения к сервису, не зная, что сервис ещё не был перезапущен и его новые настройки ещё не вступили в силу.Именно так получилось у меня при подготовке роли, настраивающей сервис PostgreSQL. После изменения номера порта может потребоваться создать новые базы данных или пользователей, но пока сервис не был перезапущен, подключиться к нему по новому порту не получится, а старый может быть не известен. В таком случае можно запомнить результаты выполненных действий в переменных при помощи выражения register:
- name: vim /etc/postgresql/9.6/main/pg_hba.conf
template:
src: etc/postgresql/9.6/main/pg_hba.conf
dest: /etc/postgresql/9.6/main/pg_hba.conf
owner: postgres
group: postgres
mode: 0640
register: pg_hba
- name: vim /etc/postgresql/9.6/main/postgresql.conf
template:
src: etc/postgresql/9.6/main/postgresql.conf
dest: /etc/postgresql/9.6/main/postgresql.conf
owner: postgres
group: postgres
mode: 0644
register: postgresqlИ затем проверить результаты этих действий и немедленно перезапустить сервис, если его конфигурация была изменена:- name: systemctl restart postgresql
service:
name: postgresql
state: restarted
when: (pg_hba.changed or postgresql.changed)Использованные материалы
- Describe how to use "postgresql_user" properly with ansible >= 2.1.0.0
- Becoming an Unprivileged User
Сообщения
