На чем было опробовано:

1. Ansible 2.9.18
2. Hyper-V на Windows 10 Pro.
3. Сервер Ansible: CentOS Linux release 7.9.2009 (Core).
4. Node 1: CentOS Linux release 7.9.2009 (Core).
5. Node 2: CentOS Linux release 7.9.2009 (Core).
6. Node 3: CentOS Linux release 7.9.2009 (Core).

1. Введение.

Как установить и первоначально настроить Ansible описано здесь:

Ссылка: «Ansible: Часть 1. Описание, установка и первоначальная настройка.»

Рассмотрим структуру и правила написания таких сценариев более подробно.

Ссылка: «Ansible: Часть 3. Сценарии (плейбуки) — Playbooks.»

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

Ссылка: «Ansible: Часть 4. Практические примеры плейбуков.»

Как настраивать защищенные плейбуки описано в этом разделе.

Ссылка: «Ansible: Часть 5. Настройка защищенных плейбуков.»

2. Примеры.

Для того, чтобы понять как работают простые команды Ansible, приведу несколько простых примеров. По аналоги вы всегда сможете придумать свои команды под ваши конкретные ситуации.

2.1. Проверка связи.

С помощью Ansible можно одновременно выполнить одну задачу на целой группе серверов.

Модуль ping проверит, есть ли у вас валидные учетные данные для подключения к нодам, определенным в файле инвентаря, и может ли Ansible запускать сценарии Python на удаленном сервере от имени root пользователя.

2.1.1. Со всеми нодами.

Чтобы убедиться, что Ansible может подключаться к нодам и запускать команды и плейбуки, вы можете использовать следующую команду:

# ansible all -m ping

Ответ pong означает, что Ansible готов запускать команды и плейбуки на этой ноде.

Ответ:

2.1.2. С целевыми хостами.

Проверять с целевыми хостами можно и поштучно через их алиасы:

# ansible server1 -m ping
# ansible server2 -m ping
# ansible server3 -m ping

Ответ:

2.1.3. С целевой группой.

Попробуем, например, отправить запрос ping на серверы выбранной группы:

# ansible -m ping test_servers

Ответ:

2.2. Сбор информации о хостах.

Следующий пример соберёт информацию о хостах и выведёт её на консоль в формате JSON.

Так как список будет безумно длинный, то закажу информацию по одному целевому серверу по его алиасу server1:

# ansible server1 -m setup

Ответ:

Далее будет длинный-длинный список с перечислением параметров хоста или хостов.

2.3. Создать логический том.

А вот так можно создать логический том или, в зависимости от текущего состояния, изменить его размер с именем examplevolume в группе examplegroup:

# ansible test_servers -m lvol -a "vg=examplegroup lv=examplevolume size=1024 state=present"

Ответ:

server1 | success >> {
"changed": true,
"msg": ""
}

server2 | success >> {
"changed": false,
"msg": ""
}

server3 | success >> {
"changed": false,
"msg": ""
}

2.4. Подключение с помощью учетной записи другого пользователя.

По умолчанию Ansible пытается подключиться к нодам в качестве текущего пользователя системы через соответствующую пару ключей SSH.

Чтобы подключиться как другой пользователь, добавьте команду с флагом -u и именем нового пользователя otheruser:

# ansible all -m ping -u otheruser

То же самое относится и к ansible-playbook:

# ansible-playbook myplaybook.yml -u otheruser

В данном примере предполагается, что вы пробросили ключ данного пользователя на целевые хосты.

2.5. Настройка пользовательского ключа SSH.

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

# ansible all -m ping --private-key=~/.ssh/id_rsa

Ответ:

Эта опция также работает для ansible-playbook:

# ansible-playbook myplaybook.yml --private-key=~/.ssh/id_rsa

В данном примере предполагается, что вы пробросили ключ данного пользователя на целевые хосты.

2.6. Настойка парольной аутентификации.

Если вам нужно использовать парольную аутентификацию для подключения к нодам, добавьте опцию --ask-pass к команде Ansible.

Это заставит Ansible запросить у вас пароль пользователя на удаленном сервере, к которому вы пытаетесь подключиться:

# ansible all -m ping --ask-pass

Ответ:

Эта опция также действительна для ansible-playbook:

# ansible-playbook myplaybook.yml --ask-pass

2.7. Использование пароля sudo.

Если удаленный пользователь должен предоставить пароль для запуска команд sudo, вы можете включить опцию --ask-become-pass в команду Ansible.

Опция позволит вам ввести пароль sudo удаленного пользователя:

# ansible all -m ping --ask-become-pass

Ответ:

Эта опция также действительна для ansible-playbook:

# ansible-playbook myplaybook.yml --ask-become-pass

2.8. Запуск специальных команд.

Чтобы выполнить любую команду на ноде, используйте параметр -a, а затем укажите нужную команду в кавычках.

Например, следующая команда выполнит uname -a на всех нодах в вашем инвентаре:

# ansible all -a "uname -a"

uname – инструмент, который чаще всего используется для определения архитектуры процессора, имени хоста системы и версии ядра, работающего в системе.

Ответ:

Или удалит vim на какой-то конкретной:

# ansible server1 -a "yum -y remove vim"

Ответ:

Также с помощью опции -m можно запускать модули Ansible.

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

Это можно сделать, включив параметр --check:

# ansible server1 -m yum -a "name=vim" --check

Ответ:

Следующая команда установит пакет Midnight Commander на server1 из вашего инвентаря:

# ansible server1 -m yum -a "name=mc"

Ответ: после долгих-долгих раздумий…

2.9. Отправка сообщений.

Отправить в echo «Hello World»:

# ansible all -a '/bin/echo Hello, World!'

Ответ:

2.10. Расход памяти по хостам.

Иногда требуется узнать расход памяти по хостам:

# ansible all -m shell -a 'free -m'

Ответ:

2.11. Модуль copy.

Модуль copy позволяет копировать файл из управляющей машины Ansible Server на удаленный узел server2.

Представим, что нам нужно скопировать наш /tmp/from/file1.test в каталог /tmp/to/ узла server2.

Чтобы создать файл с именем file1.test размером 1 ГБ, вы должны выполнить последовательность действий.

Создадим каталог, из которого будем копировать целевой файл:

# mkdir -p /tmp/from/

Сгенерируем в этот каталог целевой файл:

# dd if=/dev/zero of=/tmp/from/file1.test bs=1 count=0 seek=1G

Ответ:

Создадим на удаленном узле server2 каталог, в который мы будем копировать целевой файл:

# ansible -m shell -a 'mkdir -p /tmp/to/' server2

Ответ:

Совершим копирование с Ansible Server на удаленный узел server2:

# ansible -m copy -a 'src=/tmp/from/file1.test dest=/tmp/to/' server2

Ответ:

На узле server2 появился file1.test в каталоге  /tmp/to/.

3. Оригиналы источников информации.

1. selectel.ru «Система управления конфигурацией Ansible».
2. 8host.com «Как работать с Ansible: простая удобная шпаргалка».
3. habr.com «Автоматизируем и ускоряем процесс настройки облачных серверов с Ansible. Часть 1: Введение».
4. Источник: https://hamsterden.ru/ansible-examples-of-simple-ansible-tasks/

На чем было опробовано:

1. Ansible 2.9.18
2. Hyper-V на Windows 10 Pro.
3. Сервер Ansible: CentOS Linux release 7.9.2009 (Core).
4. Node 1: CentOS Linux release 7.9.2009 (Core).
5. Node 2: CentOS Linux release 7.9.2009 (Core).
6. Node 3: CentOS Linux release 7.9.2009 (Core).

1. Введение.

Представьте себе, что вам нужно управлять парком серверов, расположенных к тому же в разных географических точках. Каждый из этих серверов требует настройки, регулярного обновления и мониторинга. Конечно, для решения этих задач можно воспользоваться самым простым способом: подключиться к каждому серверу по ssh и внести необходимые изменения. При всей своей простоте этот способ сопряжен с некоторыми трудностями: он чрезвычайно трудоемок, а на выполнение однообразных операций уходит очень много времени.

Чтобы упростить процессы настройки и конфигурирования серверов, можно также писать shell-скрипты, но и этот способ вряд ли можно назвать совершенным. Скрипты нужно постоянно изменять, подстраивая их под каждую новую задачу. При их написании необходимо учитывать различие операционных систем и версий. Не будем забывать и о том, что отладка скриптов отнимает много усилий и забирает немало времени.

Оптимальным вариантом решения описанных проблем является внедрение системы удаленного управления конфигурацией. В таких системах достаточно лишь описать нужное состояние управляемого узла. Система должна сама определить, что нужно сделать для достижения этого состояния, и осуществит все необходимые действия.

Со всеми сложностями, о которых идет речь выше, вы наверняка хорошо знакомы на собственном опыте: у вас имеется несколько десятков серверов, расположенных в разных точках планеты. На них необходимо регулярно вносить различные изменения: обновлять операционную систему, устанавливать и обновлять различное программное обеспечение, изменять конфигурацию и тому подобное.

Предлагается все эти операции автоматизировать и внедрить систему удаленного управления конфигурациями.

Так как простые задачи для Ansible реально простые, в буквальном смысле слова, то я принял решение вынести их в отдельную инструкцию:

Ссылка: «Ansible: Часть 2. Примеры простых задач.»

Рассмотрим структуру и правила написания таких сценариев более подробно.

Ссылка: «Ansible: Часть 3. Сценарии (плейбуки) — Playbooks.»

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

Ссылка: «Ansible: Часть 4. Практические примеры плейбуков.»

Как настраивать защищенные плейбуки описано в этом разделе.

Ссылка: «Ansible: Часть 5. Настройка защищенных плейбуков.»

2. Что такое Ansible?

Ansible — программное решение для удаленного управления конфигурациями, разработанное Майклом Де Хаанном в 2012 году. Название продукта взято из научно-фантастической литературы: в романах американской писательницы Урсулы Ле Гуин была такая штука, как Ansible — это устройство для оперативной космической связи.

Ansible — мощное программное обеспечение автоматизации конфигурирования, с открытым исходным кодом, управления и развертывания приложений на узлах без каких-либо простоев, для работы которого потребуется только SSH. В отличие от подобных продуктов, Ansible устанавливается на единственном хосте, который может даже быть вашей локальной машиной и использует SSH для связи с каждым удаленным узлом. Это позволяет ему быть невероятно быстрым при конфигурировании новых серверов, поскольку не требуются предварительно установленные дополнительные пакеты на каждом новом сервере.

Машина управления, где установлен Ansible и Узлы, управляемая этой машиной по SSH. Местоположение узлов определяется управляющей машиной через её инструментарий. Ansible не требует установки клиентской части или приложения, что означает отсутствие необходимости какой-либо установки агента на удаленных узлах, так что это означает, что нет каких-либо фоновых демонов или программ, выполняемых для Ansible, когда он не управляет узлами.

Другими словами, Ansible — программное обеспечение для централизованного управления конфигурациями, то есть другими операционными системами и установленными на них программами. Это современный инструмент управления конфигурацией, который облегчает задачу настройки и обслуживания удаленных серверов.

Ansible берет на себя всю работу по приведению удаленных серверов в необходимое состояние. Администратору необходимо лишь описать, как достичь этого состояния с помощью так называемых сценариев — специальных файлов «playbook».

В них описывается желаемое состояние управляемой системы, например, необходимо наличие пакета Midnight Commander. Ansible проверяет, соответствует ли удаленный компьютер описанию в плейбуке, и если это не так, приводит его в должный вид. Формат для playbook — YAML. Для описания задачи задается ее имя, используемый модуль и список параметров.

Такая технология позволяет очень быстро осуществлять переконфигурирование системы, для этого достаточно всего лишь добавить несколько новых строк в сценарий.

Пример плейбука:

---
- name: Nginx web server
  hosts: web-servers
  remote_user: root
  tasks:
  - name: Installs nginx web server
    yum:
      pkg: nginx
      state: installed
      update_cache: true
  - name: Push future default virtual host configuration
    copy:
      src: files/site.conf
      dest: /etc/nginx/conf.d/
      mode: 0640

В данном примере мы задаем 2 задачи для группы серверов web-servers — сначала необходимо установить пакет nginx, затем скопировать файл site.conf с сервера на удаленную систему в каталог /etc/nginx/conf.d.

3. Почему Ansible лучше других подобных программ?

По сравнению с другими популярными инструментами автоматизации IT-инфраструктуры, Ansible не требует установки клиентских приложений на обслуживаемые сервера, что может сократить время настройки перед развертыванием инфраструктуры. Для работы Ansible подключается к обслуживаемым серверам по SSH.

Преимущества Ansible по сравнению с другими аналогичными решениями (здесь в первую очередь следует назвать такие продукты, как Puppet, Chef и Salt) заключаются в следующем:

• на управляемые узлы не нужно устанавливать никакого дополнительного программного оборудования, всё работает через SSH (в случае необходимости дополнительные модули можно взять из официального репозитория);
• код программы, написанный на Python, очень прост;
• при необходимости написание дополнительных модулей не составляет особого труда;
• язык, на котором пишутся сценарии, также предельно прост;
• низкий порог вхождения: обучиться работе с Ansible можно за очень короткое время;
• документация к продукту написана очень подробно и вместе с тем — просто и понятно;
• документация регулярно обновляется;
• Ansible работает не только в режиме push, но и pull, как это делают большинство систем управления (Puppet, Chef);
• имеется возможность последовательного обновления состояния узлов (rolling update).

Самостоятельно ознакомиться с Puppet вы можете по моим инструкциям на этом же сайте:

Ссылка: «Puppet — система управления конфигурацией».

4. Какой метод лучше Push или pull?

“Из коробки” все сценарии и команды выполняются методом push: когда возникает необходимость, мы запускаем сценарий, и он последовательно выполняется на удалённых серверах. Однако разработчики также предусмотрели метод pull и даже написали специальное приложение для установки необходимой для этого части ansible на удалённые хосты.

5. Как работает Ansible.

Основная идея Ansible – наличие одного или нескольких управляющих серверов, из которых вы можете отправлять команды или наборы последовательных инструкций (playbooks) на удаленные сервера, подключаясь к ним по SSH.

Файл Host inventory содержит информацию об обслуживаемых серверах, где команды будут исполнены. Файл конфигурации Ansible может быть полезен для указания настроек вашего окружения.

Наборы инструкций (playbooks) состоят из одной или более задач, которые описываются с помощью функциональность модуля ядра Ansible или сторонних модулей, которые могут потребоваться в специфических ситуациях. Сами по себе наборы инструкций — последовательные наборы команд, в которых могут быть проверки условий: если условие не выполняется, определенные команды могут пропускаться.

Также вы можете использовать Ansible API для запуска скриптов. Если скрипту-обертке (wrapper) может потребоваться запуск playbook, это можно сделать через API. Сами playbooks описываются декларативно в формате YAML. Ansible поддерживает сценарии развертывания новых облачных серверов и конфигурирования их на основании ролей. Часть работы может быть проведена в локальном режиме на управляющем сервере, а остальная — на созданном сервере после его первой загрузки.

6. Краткий словарь терминов Ansible.

В этом этой инструкции широко используются такие термины Ansible:

• Control Machine или Node — ведущая система, в которой установлен Ansible и откуда он может подключаться к нодам и выполнять на них команды.
• Хост — в Ansible хост — это удаленный компьютер, которому назначены отдельные переменные, и они далее группируются вместе. У каждого хоста есть выделенное имя или уникальный IP-адрес, чтобы сделать его идентификацию легкой и быстрой. Им также может быть присвоен простой номер порта, если вам не нужно обращаться к ним через соединение ssh.
• Нода или Узел — сервер, управляемый Ansible.
• Файл инвентаря — файл, который содержит информацию о серверах, которыми управляет Ansible, обычно находится в /etc/ansible/hosts.
• Playbooks — они написаны на языке программирования YAML с минимальным синтаксисом и обычно используются для автоматизации задач при необходимости.
• Роль — коллекция плейбуков и других файлов, которые имеют отношение к цели. Например, к установке web-сервера.
• Play — полный набор инструкций Ansible. В play может быть несколько плейбуков и ролей, включенных в один плейбук, который служит точкой входа.
• Задача — каждая инструкция, определенная в книге игр, называется задачей, которая будет выполняться в дальнейшем для выполнения действия.
• Факты — они выводятся из удаленных узлов автоматически при выполнении модулей на удаленных узлах.
• Группа — это комбинация хостов, которые назначены пулу, и переменные также могут совместно использоваться.
• Инвентаризация — инвентаризация является важным компонентом ANSI удаленного механизма, который описывает хосты, группы и так далее. С помощью IP-адреса или номера порта и так далее. Таким образом, вы можете определить все хосты в одном файле для быстрого доступа.
• API — это транспортная среда для различных облачных сервисов, как частных, так и общедоступных.
• Модули — с помощью playbook модули могут быть выполнены на удаленных узлах напрямую. Кроме того, его можно использовать для управления службами, ресурсами, пакетами, файлами или командами и так далее. Модули являются основными компонентами, которые помогают устанавливать пакеты, позволяют API-интерфейсам взаимодействовать друг с другом и планировать действия для системных файлов. В Ansible есть множество модулей, которые запрограммированы для автоматизации практически всего внутри инструмента.
• Плагины — это специальные части кода, которые помогают быстро писать код. Плагины автоматизируют задачи разработки и помогают максимально ускорить работу по развертыванию. Ansible оснащен различными удобными плагинами, которые можно использовать при необходимости, чтобы упростить вам задачу.
• Оркестровка — это общий термин, который часто используется в техническом мире. Почему это важно и в Ansible? Для разных программных продуктов значение оркестровки может быть различным. Ansible использует его в качестве дирижера для управления оркестром.

7. Установка.

Обновим операционную систему:

# yum -y update && yum -y upgrade

По умолчанию Ansible нет в репозитории CentOS 7 — устанавливаем репозиторий EPEL:

# yum -y install epel-release

После устанавливаем сам сервер управления:

# yum -y install ansible

Где система автоматически обновит список пакетов с учетом нового репозитория и начнет установку Ansible.

Проверка версии установленной версии Ansible:

# rpm -qa | grep ansible

Ответ:

или

# ansible --version

Ответ:

8. Настройка Ansible.

Файл конфигурации описывается в INI–формате. Вы можете переопределить часть или всю конфигурацию в параметрах playbook или переменных окружения.

При исполнении команд Ansible проверяет наличие файла конфигурации в следующих расположениях:

• проверяется переменная окружения ANSIBLE_CONFIG, которая может указывать на файл конфигурации;
• ./ansible.cfg – в текущей директории;
• ~/.ansible.cfg — в домашней директории;
• /etc/ansible/ansible.cfg — в каталоге, сгенерированном при установке Ansible через менеджер пакетов.

9. Настройка через переменные окружения.

Большинство параметров конфигурации можно установить через переменные окружения, используя префикс ANSIBLE_ перед названием параметра конфигурации (большими буквами).

Например:

export ANSIBLE_SUDO_USER=root

После этого переменная ANSIBLE_SUDO_USER может быть использована в playbook.

10. Параметры конфигурации.

Параметров конфигурации Ansible множество.

Давайте рассмотрим некоторые из них:

• hostfile: Параметр указывает на путь к inventory file, в котором содержится список адресов хостов, к которым Ansible может подключиться.
  • Например: hostfile = /etc/ansible/hosts
• library: Путь к директории, где хранятся модули Ansible.
  • Например: library = /usr/share/ansible
• forks: Количество процессов, которые может породить Ansible. По умолчанию установлено 5 процессов.
  • Например: forks = 5
• sudo_user: Пользователь по умолчанию, от которого Ansible запускает команды на удаленных серверах.
  • Например: sudo_user = root
• remote_port: Порт для соединения по SSH (по умолчанию 22).
  • Например: remote_port = 22
• host_key_checking: Параметр позволяет отключить проверку SSH-ключа на хосте. По умолчанию проверка выполняется.
  • Например: host_key_checking = False
• timeout: Значение таймаута попытки подключения по SSH.
  • Например: timeout = 60
• log_path: Путь для хранения файлов логов. По умолчанию Ansible не хранит их совсем, но указав этот параметр можно активировать запись логов.
  • Например: log_path = /var/log/ansible.log

11. Файл конфигурации ansible.cfg.

По умолчанию список хостов/групп, к которым применяются команды содержится в файле /etc/ansible/hosts:

# grep -E '^#inventory' /etc/ansible/ansible.cfg

Ответ:

При необходимости его можно переопределить с помощью опции

--inventory-file(-i)

Пример создания кастомного файла конфигурации.

Подключитесь по SSH к созданному управляющему серверу с установленным Ansible.

Создайте директорию для экспериментов ‘ansible‘ в своём домашнем каталоге и перейдите в него:

# mkdir ~/ansible
# cd ~/ansible

Также создайте каталог для хранения модулей Ansible и каталог для хранения логов:

# mkdir ~/ansible/modules
# mkdir ~/ansible/logs

Создайте файл ansible.cfg со следующим содержимым:

[defaults]
hostfile = ~/ansible/inventory
sudo_user = root
log_path = ~/ansible/logs/ansible.log

Указываем обслуживаемые сервера в host inventory.

Для экспериментов можно упомянуть, к примеру пару серверов, которые и можно настраивать.

Нужно сообщить Ansible их адреса и сгруппировать их.

Для этого создайте файл inventory в директории ~/ansible/inventory со следующим содержимым:

[experiments]
ip_первой_машины
ip_второй_машины

12. Файл hosts.

Работа с Ansible начинается с настройки его центрального файла списка хостов — так и называется файл hosts.

По умолчанию расположение файла — /etc/ansible/hosts, но оно может также быть задано параметром окружения $ANSIBLE_HOSTS или параметром -i при запуске ansible и ansible-playbook.

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

[dbservers]
one.example.com
two.example.com
three.example.com

[dnsservers]
rs1.example.com ansible_ssh_port=5555 ansible_ssh_host=192.168.1.50
rs2.example.com
ns[01:50].example.com

Помимо списка управляемых узлов, в файле hosts могут быть указаны и другие сведения, необходимые для работы: номера портов для подключения по SSH, способ подключения, пароль для подключения по SSH, имя пользователя, объединения групп и тому подобно. В некоторых случаях — в частности, при работе с большими и сложными конфигурациями, — различные параметры можно выносить в отдельные файлы и каталоги.

Более подробно о файле hosts и правилах его написания можно почитать в официальной документации.

Ссылка: docs.ansible.com.

Раздел: «How to build your inventory».

13. Информация об узлах — Facts.

Перед внесением изменений Ansible подключается к управляемым узлам и собирает информацию о них: о сетевых интерфейсах и их состоянии, об установленной операционной системе и тому подобное. Он может делать это как с помощью собственного модуля, так и с помощью инструментов ohai и facter, если они установлены (такая возможность специально предусмотрена для пользователей, уже имеющих опыт работы с системами удаленного управления конфигурациями: ohai и facter являются библиотеками фактов для Chef и Puppet).

14. Переменные.

Во время работы, как правило, требуется не только установить какое-либо приложение, но и настроить его в соответствии с определенными параметрами на основании принадлежности к группе серверов или индивидуально (например, IP-адрес BGP-соседа и номер его AS или параметры для базы данных).

Как уже было сказано, загромождать файл hosts будет не очень красиво, поэтому разработчики Ansible пошли следующим путём:

• файлы с переменными групп хранятся в каталоге ../group_vars/имя_группы;
• файлы с переменными хостов в каталоге ../hosts_vars/имя_хоста;
• файлы с переменными роли (о них речь пойдет ниже) в директории ../имя_роли/vars/имя_задачи.yml.

Помимо пользовательских переменных можно и даже нужно использовать факты, собранные Ansible перед выполнением сценариев и отдельных задач.

15. Модули Ansible.

В состав Ansible входит огромное количество модулей для развёртывания, контроля и управления различными компонентами, которые можно условно разделить на следующие группы (в скобках приведены названия некоторых продуктов и сервисов):

• облачные ресурсы и виртуализация (Openstack, libvirt);
• базы данных (MySQL, Postgresql, Redis, Riak);
• файлы (шаблонизация, регулярные выражения, права доступа);
• мониторинг (Nagios, monit);
• оповещения о ходе выполнения сценария (Jabber, Irc, почта, MQTT, Hipchat);
• сеть и сетевая инфраструктура (Openstack, Arista);
• управление пакетами (apt, yum, rhn-channel, npm, pacman, pip, gem);
• система (LVM, Selinux, ZFS, cron, файловые системы, сервисы, модули ядра);
• работа с различными утилитами (git, hg).

О том, с чем умеет работать Ansible, можно прочитать в официальной документации. Список действительно впечатляет.

Ссылка на документацию: docs.ansible.com.

16. Начальная настройка и тестовый запуск Ansible.

Установим файловый менеджер и текстовый редактор в одном лице — Midnight Commander:

# yum -y install mc

Создадим резервную копию оригинального файла конфигурации:

# cp /etc/ansible/hosts /etc/ansible/hosts.original

Откроем на редактирование файл с серверами, которыми хотим управлять:

# mcedit /etc/ansible/hosts

и приведем его к следующему виду:

[test_servers]
server1 ansible_ssh_host=192.168.0.39 ansible_ssh_user=root
server2 ansible_ssh_host=192.168.0.30 ansible_ssh_user=root
server3 ansible_ssh_host=192.168.0.31 ansible_ssh_user=root

где

• test_servers — это группа серверов, в которую добавлены три сервера с IP-адресами 192.168.0.30, 192.168.0.31 и 192.168.0.39;
• server 1-3 — это индивидуальные алиасы каждого из серверов группыtest_servers в списке инвентаря;
• ansible_ssh_host — это специальная переменная, которая содержит IP-адрес узла, к которому будет создаваться соединение;
• ansible_ssh_user — это еще одна специальная переменная которая говорит Ansible‘у подключаться под указанным аккаунтом, то есть пользователем. По умолчанию Ansible использует ваш текущий аккаунт пользователя, или другое значение по умолчанию, указанное в ~/.ansible.cfg (remote_user).

Все сервера, в данном примере, имеют одинаковую операционную систему CentOS Linux release 7.9.2009 (Core), одинаковых пользователей root и одинаковые пароли на учетных записях root.

Открываем конфигурационный файл Ansible (выше по тексту был способ изменить место хранения файла конфигурации):

# mcedit /etc/ansible/ansible.cfg

Снимаем комментарий с опции host_key_checking, приведя ее к виду:

host_key_checking = False

Данная настройка позволит нашему серверу управления автоматически принимать ssh fingerprint, избавляя нас от необходимости постоянно вводить yes, когда мы впервые конфигурируем новый сервер.

Теперь выполним проверку доступности добавленных серверов:

# ansible -m ping test_servers -u root -kK

Данная команда проверит доступность по сети двух серверов из группы test_servers от учетной записи root.

Будет запрошен пароль от учетной записи (в нашем случае, root).

После будет запрошен пароль суперпользователя на серверах.

16.1. Если всё заработало.

На экране должно появиться, примерно, следующее:

Наш сервер управления готов к работе.

16.2. Если не заработало.

Если на экране появится ошибка, введите с сервера Ansible следующую команду:

# ssh root@192.168.0.39

В данном случае, мы пытаемся подключиться к серверу 192.168.0.39 по SSH от пользователя root.

Если подключиться к серверу 192.168.0.39 вышеописанной командой не удалось, возможно введен неправильный пароль или доступ по SSH от root запрещен. В этом случае, создайте служебную учетную запись на сервере 192.168.0.39 и используйте ее для подключения по SSH.

Например, на удаленном сервере вводим:

# useradd ansible-user

# passwd ansible-user

В этом примере мы создали учетную запись ansible-user и задали ей пароль.

Теперь вводим нашу команду для проверки:

# ansible -m ping test_servers -u ansible-user -kK

Внимание! Обратите внимание, что мы выполняем теперь запрос от пользователя ansible-user.

17. Организация RSA-ключей между серверами.

Для того, что бы Ansible хозяйничал на хостах, требуется включить на целевых для управления хостах разрешение пользоваться аутентификацией по ключам, создать пару RSA-ключей на Ansible Control Machine и копировать открытые ключи на целевые сервера, которыми планируется управлять.

Как это сделать подробно описывается в инструкции: «CentOS 7: Настройка и использование SSH — Secure Shell».

В данном руководстве я приведу краткий способ организации коммуникации между хостами.

Создаём пару RSA-ключей.

# ssh-keygen

На все вопросы жмём Enter. Нам не нужны никакие пароли и генерируем ключи мы в каталог по умолчанию.

Ответ:

Копируем открытые ключи на сервера, которыми планируем управлять.

У нас их 3 штуки, поэтому копируем на каждый:

# ssh-copy-id root@192.168.0.39
# ssh-copy-id root@192.168.0.30
# ssh-copy-id root@192.168.0.31

Ответы:

Либо средствами самого Ansible через модуль authorized_key.

Раскатаем пользователя root на все виртуальные машины, до которых может дотянуться Ansible:

# ansible all -m authorized_key -a "user=root key='{{ lookup('file', '/root/.ssh/id_rsa.pub') }}' path=/root/.ssh/authorized_keys manage_dir=no" --ask-pass

Ответ командной строки…:

SSH password:
server3 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "comment": null,
    "exclusive": false,
    "follow": false,
    "gid": 0,
    "group": "root",
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDKIz2wkoU3vrwAPKFORDfjJMw1+6G1nHASMcbUXf6rYauACbW8zSdKi4Br0Bgf+yok+79jehVMuWiiJlKfm2V2JsV/KNW+tmEwSqbuolKtjTDFnHZx/IW6yO+51qFLL152IRDk7FmNBJAZJ3NpXZnVq2OrPidEGr5j/1VbNp+0QNE8aT9Dy4V0axYXwa9/AEwXNTtclSh+zK0bwKoD978DGpGUyiOl3I9FPrz8uc/8M6xWPHLSaAvqYpc2aT5X5J0sFVMqpMKDVoLxsEM45KTci81SoAq1XlU2UCdX+LHuRhgbz0BYY/nCqJ9HWGb1CJwthuaRaVDX6dA6D1fwWHxd root@cos7serv.hamsterden.loc",
    "key_options": null,
    "keyfile": "/root/.ssh/authorized_keys",
    "manage_dir": false,
    "mode": "0600",
    "owner": "root",
    "path": "/root/.ssh/authorized_keys",
    "size": 410,
    "state": "file",
    "uid": 0,
    "user": "root",
    "validate_certs": true
}
    ... и так далее...

Проверяем вход пользователя root по SSH-ключам c сервера на узлы.

У нас их 3 штуки, поэтому тестируем вход на на каждый:

# ssh root@192.168.0.39
# ssh root@192.168.0.30
# ssh root@192.168.0.31

Ответ:

Также настроим вход с Ansible-сервера на самого себя:

# cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys

Проверяем:

# cat /root/.ssh/authorized_keys

Ответ:

18. Проверка подключения к узлам.

Чтобы убедиться, что Ansible может подключаться к узлам и запускать команды и плейбуки, вы можете использовать следующую команду:

# ansible all -m 'ping'

или, встроенной в Ansible, одноименной утилитой:

# ansible all -m ping

Модуль ping проверит, есть ли у вас учетные данные для подключения к узлам, определенным в файле инвентаря, и может ли Ansible запускать сценарии Python на удаленном сервере от имени root пользователя.

Ответ pong означает, что Ansible готов запускать команды и плейбуки на этом узле.

Ответ:

Проверять с целевыми узлами можно и поштучно через их алиасы:

# ansible server1 -m ping
# ansible server2 -m ping
# ansible server3 -m ping

Ответ:

И еще одну команду:

# ansible all -a 'uptime'

Ответ:

19. Примеры простых задач Ansible.

Так как простые задачи для Ansible реально простые, в буквальном смысле слова, то я принял решение вынести их в отдельную инструкцию:

Ссылка: «Ansible: Часть 2. Примеры простых задач.»

20. Сценарии — Playbooks.

Ansible позволяет не только выполнять единичные задачи, но и писать сценарии, которые необходимо выполнить на управляемых узлах.

Рассмотрим структуру и правила написания таких сценариев более подробно.

Ссылка: «Ansible: Часть 3. Сценарии (плейбуки) — Playbooks.»

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

Ссылка: «Ansible: Часть 4. Практические примеры плейбуков.»

Если ваши плейбуки Ansible содержат конфиденциальные данные, такие как пароли, ключи API и учетные данные, важно обеспечить их безопасность с помощью шифрования. Ansible предоставляет ansible-vault для шифрования файлов и переменных.

Несмотря на то, что любой файл данных Ansible, а также двоичные файлы, возможно зашифровать изначально, чаще для шифрования переменных файлов, содержащих конфиденциальные данные, используется ansible-vault. После шифрования файла с помощью этого инструмента вы сможете выполнять, редактировать или просматривать его, только предоставив соответствующий пароль, указанный при первом шифровании файла.

Ссылка: «Ansible: Часть 5. Настройка защищенных плейбуков.»

21. Файл инвентаря.

21.1. Пользовательский файл инвентаря.

Файл инвентаря по умолчанию обычно находится в /etc/ansible/hosts, но вы можете использовать опцию -i для указания пользовательских файлов при запуске команд и плейбуков Ansible.

Это удобный способ настройки индивидуального инвентаря для каждого проекта, который можно включить в системы контроля версий, такие как Git:

# ansible all -m ping -i my_custom_inventory

Такая опция действительна и для ansible-playbook:

# ansible-playbook myplaybook.yml -i my_custom_inventory

21.2. Динамический файл инвентаря.

Ansible поддерживает сценарии инвентаризации для создания динамических файлов. Это полезно, если ваш инвентарь часто меняется, когда серверы создаются и уничтожаются.

Вы можете найти ряд скриптов с открытым исходным кодом в официальном репозитории Ansible GitHub. После загрузки требуемого сценария на Ansible Control Machine и настройки необходимых параметров (например, учетных данных API) вы можете запустить исполняемый файл в качестве пользовательского инвентаря с любой командой Ansible, которая поддерживает эту опцию.

Следующая команда использует скрипт инвентаря my_inventory.py с командой ping для проверки подключения ко всем текущим активным серверам:

# ansible all -m ping -i my_inventory.py

За более подробной информацией о том, как использовать динамические файлы инвентаризации, пожалуйста, обратитесь к официальной документации Ansible.

Ссылка на документацию: docs.ansible.com.

22. Вызов справки по командам.

Существует еще много вариантов команд и флагов, которые могут пригодиться вам в работе с Ansible.

Чтобы получить обзор всех доступных опций, вы можете использовать команду help:

# ansible --help

Если вы хотите получить более полное представление об Ansible и всех его доступных командах и функциях, обратитесь к официальной документации Ansible.

Ссылка на документацию: docs.ansible.com.

23. Устранение неполадок.

Если вы сталкиваетесь с ошибками при выполнении команд и плейбуков, рекомендуется увеличить детализацию вывода, чтобы получить больше информации о проблеме.

Вы можете сделать это, включив в команду параметр -v:

# ansible-playbook myplaybook.yml -v

Если вам нужно больше деталей, вы можете использовать -vvv, и это увеличит детализацию вывода.

Если вы не можете подключиться к удаленным нодам через Ansible, используйте -vvvv для получения информации об отладке соединения:

# ansible-playbook myplaybook.yml -vvvv

24. Возможные ошибки.

24.1. Ошибка «[WARNING]: Updating cache and auto-installing missing dependency: python-apt».

Данная ошибка возникает во время попытки установит пакет с программным обеспечением на целевые хосты с CentOS 7:

# ansible server1 -m apt -a "name=vim"

Ответ с ошибкой:

Устранение ошибки: воспользуйтесь установщиком yum c CentOS 7 совместимых операционных систем, а не apt с Debian совместимых систем.

# ansible server1 -m yum -a "name=vim"

Вариант ответа без ошибки:

Программное обеспечение успешно установилось.

25. Оригиналы источников информации.

1. selectel.ru «Система управления конфигурацией Ansible».
2. dmosk.ru «Инструкция по установке и запуску Ansible на CentOS».
3. dmosk.ru «Что такое ansible».
4. 8host.com «Как работать с Ansible: простая удобная шпаргалка».
5. habr.com «Автоматизируем и ускоряем процесс настройки облачных серверов с Ansible. Часть 1: Введение».
6. kamaok.org.ua «Установка и использование Ansible на Centos7».
7. dataenginer.ru «Что такое Ansible? Ansible Tutorial Guide для начинающих.»
8. Источник: https://hamsterden.ru/ansible-install-setup/