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

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).
7. Node 4: CentOS Linux release 7.9.2009 (Core).

1. Задача.

К примеру, нам требуется с помощью внедрения custom facts для Ansible организовать сбор версий контейнеров, запущенных на серверах, а так же сбор версий некоторого программного обеспечения на серверах, которое имеет файл с указанием версии в своём каталоге /ecp/po/version.txt.

Собранная информация должна формироваться в json-формат.

Дополнительно требуется рассмотреть средства визуализации информации в удобном виде (opensource web-приложения).

2. Решение задачи.

Решение будет состоять из нескольких этапов:

• загрузка и выполнение скрипта на узлах с целью получить json файлы;
• выгрузка файлов json с узлов;
• склеивание узловых файлов json в один сводный файл;
• просмотр сводного файла.

В системе Ansible есть возможность собирать системную информацию, которая собирается в виде фактов с помощью встроенного модуля setup.

Со сбором стандартных переменных по умолчанию всё предельно ясно, но что делать, если мы хотим сформировать наши собственные переменные на всех хостах, чтобы в дальнейшем использовать их в нашем коде?

Для этого существует возможность добавления Custom facts, что делается следующим образом:

• на любом хосте, контролируемом Ansible, создаётся каталог /etc/ansible/facts.d;
• внутри каталога размещаются один либо несколько файлов с расширением *.fact, например custom.fact;
• файлы возвращают данные в формате json.

Создаем инвентарь test-servers.inventory на 4 тестовых сервера:

# mcedit /ansible/test-servers.inventory

С таким содержимым:

[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
emachines ansible_ssh_host=192.168.0.12 ansible_ssh_user=root

Создаем специальный custom.fact файл для загрузки на узлы, который, по сути, является скриптом для выполнения некоторого комплекса действий на удалённом узле.

По замыслу будут собираться некоторые переменные и заворачиваться в разметку json.

#!/bin/bash

file_po="/etc/po/version.txt"
host_name=$(hostname)
ecp_ver=$(awk -F: '/rel_ver/{print $2}' $file_po)
docker_info=$(docker ps --format ' {{json .Names}}: {{json .Image}}, ' | paste -sd'n' | sed '$ s/.$//')
jp="/$host_name.json"

echo "{" > $jp
echo ""Информация об узлах": {" >> $jp
echo ""$host_name": {" >> $jp
if test -f "$file_po"; then
    echo ""Софт": {" >> $jp
    echo ""Версия чего-то": "$ecp_ver"" >> $jp
    echo "}" >> $jp
    echo "," >> $jp
fi
echo ""Докеры на узле": {" >> $jp
echo "$docker_info" >> $jp
echo "}" >> $jp
echo "}" >> $jp
echo "}" >> $jp
echo "}" >> $jp

Создаём специальный playbook custom-facts-fetch.yml, содержащий сценарий /ansible/files/custom.fact для узла, возвращающий некоторый файл json на Ansible master сервер с каждого узла:

---
- name: "Cбор Ansible custom facts"
  hosts: all

  tasks:
  - name: "Удаление предыдущей версии Ansible custom facts файлов на узле"
    file:
      state: "absent"
      path: "/etc/ansible/facts.d/"

  - name: "Создание Ansible custom fact каталога"
    file:
      path: "/etc/ansible/facts.d"
      state: "directory"
      mode: 0766

  - name: "Загрузка на узлы Ansible custom fact файлов"
    copy:
      src: "/ansible/files/custom.fact"
      dest: "/etc/ansible/facts.d/custom.fact"
      mode: +x

  - name: "Объявление служебной переменной для Ansible custom fact"
    debug: "var=ansible_local"
    notify:
    - reload facts

  - name: "Перезагрузка facts"
    setup: "filter=ansible_local"

  - name: "Подготовка списка файлов *.json для выгрузки с узла"
    find:
      paths: "/"
      recurse: "no"
      patterns: "*.json"
    register: "files_to_copy"

  - name: "Выгрузка файлов *.json с узла на Ansible master сервер"
    fetch:
      src: "{{ item.path }}"
      dest: "/ansible/json"
    with_items: "{{ files_to_copy.files }}"

Напишем скрипт custom-facts-fetch-PLAY.sh для запуска playbook на целевом inventory:

#!/bin/bash.

ansible-playbook /ansible/custom-facts-fetch.yml -i /ansible/test-servers.inventory

Сделаем файл скрипта исполняемым:

# chmod +x custom-facts-fetch-PLAY.sh

И запустим его.

Ответ:

После успешной отработки playbook на сервере Ansible master появится каталог /ansible/json с подкаталогами ‘имя_узла‘:

В каждом из которых будет находиться json файл вида имя_узла.json:

Содержимое json файла первого узла emachines:

Содержимое json файла второго узла server1:

Содержимое json файла третьего узла server2:

Содержимое json файла четвертого узла server3:

Получилось несколько файлов json, по файлу с каждого целевого узла.

Сколько узлов мы задействовали для Ansible custom facts, столько и json файлов и будет.

В первом файле emachines.hamsterden.loc.json не имеется фрагмент с названием «Версия чего-то‘, по втором файле cos7client1.hamsterden.loc.json такой фрагмент имеется, а так как в custom.fact реализована проверка на фактическое наличия файла /ecp/po/version.txt.

К примеру, наличие файла /ecp/po/version.txt бывает только у серверов типа «web-server». Так как скрипт «сам учитывает» тип сервера, то можно смело применять custom.fact на все целевые серверы и файл json всегда будет генерироваться корректно для каждого типа серверов.

Для создание сводного json файла по всем файлам со всех узлам, воспользуемся утилитой jq.

Ссылка на официальный сайт утилиты: https://stedolan.github.io/jq/.

Установка утилиты:

# yum install jq -y

План работ с файлами:

file1.json + file3.json + file3.json + file4.json = final_result_po.json

Создадим make-final-json-file.sh скрипт:

# mcedit /ansible/make-final-json-file.sh

#!/bin/bash

#создание каталогов для обработки файлов
mkdir -p /ansible/json/temp
mkdir -p /ansible/json-ready

#каталог куда Ansible кладет скачанные json файлы с узлов
ja="/ansible/json"

#временный каталог куда Ansible складывает все json файлы из всех каталогов узлов перед сведением информации в единый файл json
jrt="/ansible/json/temp"

#каталог куда Ansible помещает сводный json файл со всей добытой информацией по узлам
jr="/ansible/json-ready"

#обработка файлов и удаление временных промежуточных результатов
cp -i $(find /$ja -iname "*.json") $jrt
cd $jrt
jq -s '.[0] * .[1] * .[2] * .[3]' *.json > "$jrt"/temp.json
cat "$jrt"/temp.json | sed 's/{}/"нет докеров"/' > "$jr"/final_result_po.json

#удаление временных каталогов и файлов
rm -rf $jrt
rm -rf $ja

Сделаем файл скрипта исполняемым:

# chmod +x /ansible/make-final-json-file.sh

Результатом работы скрипта будет сводный json файл всех четырёх final_result_po.json в каталоге /ansible/json_ready на Ansible master сервере:

Текстовый файл:

{
  "Информация об узлах": {
    "cos7client1.hamsterden.loc": {
      "Софт": {
        "Версия чего-то": "9.11.2"
      },
      "Докеры на узле": {
        "wordpress-compose_nginx_1": "nginx:latest",
        "wordpress-compose_wordpress_1": "wordpress:php7.4-fpm-alpine",
        "wordpress-compose_pma_1": "phpmyadmin/phpmyadmin",
        "wordpress-compose_mysql_1": "mariadb"
      }
    },
    "cos7client2.hamsterden.loc": {
      "Софт": {
        "Версия чего-то": "10.2.1"
      },
      "Докеры на узле": "нет докеров"
    },
    "cos7client3.hamsterden.loc": {
      "Софт": {
        "Версия чего-то": "9.3.4"
      },
      "Докеры на узле": "нет докеров"
    },
    "emachines.hamsterden.loc": {
      "Докеры на узле": {
        "onlyoffice": "onlyoffice/documentserver",
        "funny_heisenberg": "onlyoffice/documentserver"
      }
    }
  }
}

Если открыть final_result_po.json файл в браузере Mozilla Firefox, то информация будет корректно визуализирована в удобно читаемом виде:

Задача выполнена!

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

1. golinuxcloud.com «Working with Ansible facts | Create custom facts with examples».
2. github.com «Ansible local fact example».
3. medium.com «Custom facts for Ansible».
4. otus.ru «Ansible: формируем переменные на всех хостах с Custom facts».
5. mydailytutorials.com «Working with Ansible facts – retrieving facts».
6. adyxax.org «Ansible custom factsAnsible custom facts».
7. Источник: https://hamsterden.ru/ansible-collecting-arbitrary-information-on-all-hosts-with-custom-facts/

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

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 реально простые, в буквальном смысле слова, то я принял решение вынести их в отдельную инструкцию:

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

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

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

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

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

2. Ansible Vault для хранения конфиденциальных данных.

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

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

2.1. Создание нового зашифрованного файла.

Вы можете создать новый зашифрованный файл Ansible с помощью:

# ansible-vault create credentials.yml

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

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

2.2. Шифрование существующего файла.

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

# ansible-vault encrypt credentials.yml

Эта команда запросит у вас пароль, который вам нужно будет вводить при каждом доступе к файлу credentials.yml.

2.3. Просмотр содержимого зашифрованного файла.

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

# ansible-vault view credentials.yml

Она предложит вам указать пароль, который вы выбрали при первом шифровании файла с помощью ansible-vault.

2.4. Редактирование зашифрованного файла.

Чтобы изменить содержимое файла, который ранее был зашифрован с помощью ansible-vault, выполните:

# ansible-vault edit credentials.yml

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

2.5. Расшифровка файлов.

Если вы хотите навсегда расшифровать файл, ранее зашифрованный с помощью ansible-vault, вы можете сделать это с помощью следующего синтаксиса:

# ansible-vault decrypt credentials.yml

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

3. Использование нескольких паролей.

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

Чтобы создать новый зашифрованный файл с пользовательским идентификатором хранилища, включите параметр --vault-id вместе с меткой и расположением, где ansible-vault может найти пароль для этого хранилища. Метка может быть любой, а расположение может быть либо prompt (что означает, что команда должна предложить вам ввести пароль), либо путь к файлу паролей.

# ansible-vault create --vault-id dev@prompt credentials_dev.yml

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

# ansible-vault create --vault-id prod@prompt credentials_prod.yml

Мы использовали dev и prod в качестве идентификаторов хранилищ, чтобы продемонстрировать, как вы можете создавать отдельные хранилища для каждой среды. Самостоятельно вы можете создать столько хранилищ, сколько захотите, и использовать любой ID.

Теперь, чтобы просмотреть, отредактировать или расшифровать эти файлы, вам необходимо предоставить тот же ID хранилища и источник пароля вместе с командой ansible-vault:

# ansible-vault edit credentials_dev.yml --vault-id dev@prompt

4. Использование файла паролей.

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

Файл паролей может быть простым текстовым файлом или исполняемым скриптом. Если файл является исполняемым, выходные данные, созданные ним, будут использоваться в качестве пароля хранилища. В противном случае в качестве пароля хранилища будет использоваться необработанное содержимое файла.

Чтобы применить файл паролей в ansible-vault, необходимо указать путь к файлу паролей при выполнении любой из команд vault:

# ansible-vault create --vault-id dev@path/to/passfile credentials_dev.yml

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

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

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

5. Запуск плейбука с зашифрованными данными.

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

Если вы использовали параметры по умолчанию и prompt при шифровании данных плейбука, вы можете использовать опцию --ask-vault-pass, чтобы Ansible запрашивал пароль:

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

Если вы использовали файл пароля вместо prompt, вы должны использовать опцию --vault-password-file:

# ansible-playbook myplaybook.yml --vault-password-file my_vault_password.py

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

# ansible-playbook myplaybook.yml --vault-id dev@prompt

Если вы используете файл пароля с ID, вы должны указать метку, а затем полный путь к файлу пароля в качестве источника:

# ansible-playbook myplaybook.yml --vault-id dev@vault_password.py

Если ваш play использует несколько хранилищ, вы должны добавить параметр --vault-id для каждого из них в произвольном порядке:

# ansible-playbook myplaybook.yml --vault-id dev@vault_password.py --vault-id test@prompt --vault-id ci@prompt

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

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. Источник: https://hamsterden.ru/ansible-vault-playbooks/

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

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 и научиться его использовать самостоятельно.

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

Ссылка: docs.ansible.com.
Раздел: «Intro to playbooks».

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

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

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

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

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

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

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

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

2. Схема учебного стенда.

Пускай у нас будет вот такой стенд из 4х виртуальных машин под управлением CentOS 7:

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

Задачи: для всех узлов.

• отключить SELinux и перезагрузить узлы;
• обновить операционную систему;
• установить на всех узлах группу полезных программ Midnight Commander, wget, tar;
• настроить межсетевой экран узлов на разрешение соединяться с 80 и 443 портами;
• установить web-сервер Nginx и протестировать отдачу тестовой страницы, пробросить готовую композицию HTML5 на узлы;
• добавить пользователей myrzik и barsik и настроить режим sudo для них;
• удалить пользователей myrzik и barsik;
• выполнить некоторые произвольные команды для консоли на всех узлах дистанционно.

Протестировать:

• зайти на виртуальные машины под условными пользователями и переключиться в root;
• зайти на каждую виртуальную машину по http и увидеть заставку Nginx.

Условие: удалённые виртуальные машины можно настраивать только системой Ansible.

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

3. Подготовка сервера Ansible.

Первым делом отключим на Ansible Server систему SELinux. Рамках учебного стенда она нам не нужна.

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

Ссылка: «CentOS 7: Как временно или навсегда отключить SELinux».

3.1. Отключение SELinux.

Конечно в интернете имеется много способов настройки и эксплуатации этой системы, но в данной инструкции я, пока что, настраивать SELinux не буду.

Пожалуй, это самый суровый способ, но тоже работает.

Вводим команду:

# yum -y remove selinux*

Перезапустим Ansible Server:

# shutdown -r now

3.2. Обновление системы.

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

# yum -y update && yum -y upgrade

3.3. Установка Ansible.

По умолчанию Ansible нет в репозитории CentOS 7.

Подключим дополнительный репозиторий EPEL:

# yum -y install epel-release

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

# yum -y install ansible

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

# rpm -qa | grep ansible

Ответ:

или вот так:

# ansible --version

Ответ:

Отлично! Теперь у нас есть сервер Ansible.

3.4. Создание файла инвентаря.

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

# yum -y install mc

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

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

Создадим свой файл нашего инвентаря:

# cd ~
# mkdir -p ~/ansible-inventory
# cd ~/ansible-inventory
# touch my-test-servers.inventory

Откроем наш файл инвентаря:

# mcedit /root/ansible-inventory/my-test-servers.inventory

Создадим такой файл inventory вот с таким наполнением:

[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).

3.5. Генерация ключей пользователя root.

Создаём пару RSA-ключей для пользователя root на Ansible сервере:

# ssh-keygen

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

Ответ:

3.6. Проброс root-ключей на узлы.

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

Выполним команду автоматической установки публичного ключа пользователя root на все узлы с авторизацией по паролю, до которых может дотянутся Ansible по списку инвентаря my-test-servers.inventory.

# 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 -i /root/ansible-inventory/my-test-servers.inventory

Ответ: длинный список изменений на каждом узле.

Конечно можно было и вручную всё распространить, у нас узлов 3 штуки, а представьте, если их было бы 10-20 штук:

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

Ответы:

3.7. Проверка связи с узлами.

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

# ansible -m ping test_servers -i /root/ansible-inventory/my-test-servers.inventory

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

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

Ответ:

Выполним простую команду 'uptime' для проверки возможности управления узлами:

# ansible -a 'uptime' test_servers -i /root/ansible-inventory/my-test-servers.inventory

Ответ:

3.8. Настройка входа Ansible на самого себя.

Также настроим вход по ключу Ansible Server на самого себя:

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

Проверяем:

# cat /root/.ssh/authorized_keys

Ответ:

К началу работы с Ansible учебный комплекс готов!

4. Выполнение учебных задач на узлах.

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

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

4.1. Отключение SELinux и перезагрузка узлов.

Когда вы устанавливаете CentOS 7, функция SELinux включена по умолчанию, из-за этого некоторые приложения в вашей системе могут фактически не поддерживать этот механизм безопасности. Чтобы такие приложения функционировали нормально, вам необходимо отключить SELinux. Рамках учебного стенда она нам не нужна.

Ссылка: «CentOS 7: Как временно или навсегда отключить SELinux».

Посмотрим и убедимся, что на всех узлах, стоит SELinux:

# ansible -m shell -a 'rpm -qa | grep selinux' test_servers -i /root/ansible-inventory/my-test-servers.inventory

Ответ:

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

Воспользуемся готовым решением selinux от создателей Ansible по дезактивации SELinux на узлах.

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

Раздел: «selinux — Change policy and state of SELinux».

Создадим плейбук для дезактивации SELinux на узлах с помощью Ansible Server:

# mcedit /root/ansible-playbooks/01-pb-selinux-disable.yml

Записываем в него содержимое:

---
- name: Операции с SELinux
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Отключаем SELinux
    selinux:
      state: disabled

Проверим синтаксис плейбука 01-pb-selinux-disable.yml специальной утилитой --syntax-check от Ansible:

# ansible-playbook /root/ansible-playbooks/01-pb-selinux-disable.yml --syntax-check

Ответ:

Проверка синтаксиса пройдена.

Примечание! Я заранее проверил состояние SELinux на узлах. Он активен и работает.

# sestatus

Ответ:

Применим плейбук на узлы и посмотрим что будет с SELinux:

# ansible-playbook /root/ansible-playbooks/01-pb-selinux-disable.yml -i /root/ansible-inventory/my-test-servers.inventory

Ответ:

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

Предполагаются следующие шаги:

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

В Ansible версии 2.7 или выше. 2.7 ввели модуль перезагрузки – reboot.

Ссылка: docs.ansible.com.
Раздел: «ansible.builtin.reboot».

Теперь все, что вам нужно сделать, это добавить это в свой плейбук:

---
- name: Перезагрузка серверов
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Перезагрузка хостов и ожидание их перезагрузки
    reboot:
      msg: "Reboot initiated by Ansible"
      connect_timeout: 5
      reboot_timeout: 600
      pre_reboot_delay: 0
      post_reboot_delay: 30
      test_command: whoami

Этот плейбук выполнит следующее:

• Перезагрузит узел.
• Подождет 30 секунд.
• Попытается подключиться через SSH и запустить whoami.
• Отключится через 5 секунд, если не сработает ssh.
• Будет продолжать пытаться подключиться в течение 10 минут (600 секунд).

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

# ansible-playbook /root/ansible-playbooks/02-pb-reboot.yml -i /root/ansible-inventory/my-test-servers.inventory

Ответ:

Примечание! После перезагрузки узлов я проверил состояние SELinux на узлах:

# sestatus

Ответ:

Как видно SELinux отключен на всех узлах дистанционно с помощью Ansible.

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

Добавьте директиву:

notify: Reboot host and wait for it to restart

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

Раздел: «Execute Ansible ‘actions’».

Примечание! Если вам нужно перезагрузиться на полпути через playbook вы можете заставить все задачи выполниться с помощью команды:

- name: Reboot if necessary
  meta: flush_handlers

Иногда это можно сделать, чтобы что-то изменить, заставить сервер перезагрузиться, а затем проверить, что изменения вступили в силу и все в том же playbook.

4.2. Обновление операционных систем на узлах.

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

Воспользуемся готовым решением ansible.builtin.yum от создателей Ansible по обновлению программного обеспечения на узлах.

Ссылка: docs.ansible.com.
Раздел: «Manages packages with the yum package manager».

Создаем файл плейбука:

# mcedit /root/ansible-playbooks/03-pb-upgrade-all-packages.yml

Записываем в него содержимое:

---
- name: Обновление всех пакетов на узлах
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Обновить все пакеты
    yum:
      name: '*'
      state: latest

Проверим синтаксис плейбука 03-pb-upgrade-all-packages.yml специальной утилитой --syntax-check от Ansible:

# ansible-playbook /root/ansible-playbooks/03-pb-upgrade-all-packages.yml --syntax-check

Ответ:

Проверка синтаксиса пройдена.

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

# ansible-playbook /root/ansible-playbooks/03-pb-upgrade-all-packages.yml -i /root/ansible-inventory/my-test-servers.inventory

Долго-долго ждём, особенно если это самое первое обновление после установки узловых систем и они ни разу еще не обновлялись до этого.

После некоторого всплеска активности CPU на узлах Ansible всё завершилось.

Ответ:

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

4.3. Установка группы полезных программ.

Про учебному сценарию требуется установить пакет программного обеспечения, который состоит из традиционного набора программ для многих серверов: mc, wget, tar.

Снова воспользуемся готовым решением ansible.builtin.yum от создателей Ansible по установке программного обеспечения mc, wget, tar на узлах.

Ссылка: docs.ansible.com.
Раздел: «Manages packages with the yum package manager».

Создаем файл плейбука:

# mcedit /root/ansible-playbooks/04-pb-progs-install.yml

Записываем в него содержимое:

---
- name: Установка полезных программ на всех узлах
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Установить группу программ
    yum:
      name: "{{ package }}"
    vars:
      package:
      - mc
      - wget
      - tar
      state: latest

Проверим синтаксис плейбука 04-pb-progs-install.yml специальной утилитой --syntax-check от Ansible:

# ansible-playbook /root/ansible-playbooks/04-pb-progs-install.yml --syntax-check

Ответ:

Проверка синтаксиса пройдена.

Применим плейбук на узлы и посмотрим как установится группа программного обеспечения:

# ansible-playbook /root/ansible-playbooks/04-pb-progs-install.yml -i /root/ansible-inventory/my-test-servers.inventory

Некоторое время ждём.

Ответ:

Все пакеты на узлах успешно установлены программы mc, wget, tar из доступных узлам репозиториев.

4.4. Настройка межсетевого экрана.

Для успешной и безопасной работы любого сервера первым делом требуется настраивать его сетевую безопасность. Настроим разрешение обращаться к узлам по 80 порту и 443 порту.

Воспользуемся готовым решением ansible.posix.firewalld от создателей Ansible по настройке межсетевого экрана firewalld на узлах.

Ссылка: docs.ansible.com.
Раздел: «ansible.posix.firewalld – Manage arbitrary ports/services with firewalld».

Отдельно установим модуль ansible.posix.firewalld на Ansible сервер:

# ansible-galaxy collection install ansible.posix

Ответ:

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

В этом перезапуске службы межсетевого экрана нам поможет модуль ansible.builtin.service от создателей Ansible.

Ссылка: docs.ansible.com.
Раздел: «ansible.builtin.service – Manage services».

Создаем файл плейбука:

# mcedit /root/ansible-playbooks/05-pb-http-https.yml

Записываем в него содержимое:

--
- name: Разрешение 80 и 443 порта - firewalld
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Разрешим 80 порт
    ansible.posix.firewalld:
      service: http
      permanent: yes
      state: enabled
  - name: Разрешим 443 порт
    ansible.posix.firewalld:
      service: https
      permanent: yes
      state: enabled
  - name: Перезапустим service firewalld на всех узлах
    ansible.builtin.service:
      name: firewalld
      state: restarted

Проверим синтаксис плейбука 05-pb-http-https.yml специальной утилитой --syntax-check от Ansible:

# ansible-playbook /root/ansible-playbooks/05-pb-http-https.yml --syntax-check

Ответ:

Проверка синтаксиса пройдена.

Примечание! Перед запуском плейбука проверим состояние межсетевого экрана на любом из узле.

# firewall-cmd --list-all

Ответ:

Как видно — порты 80 и 443 закрыты, то есть отсутствуют с списке разрешенных.

Применим плейбук на узлы разрешим узлам соединения по 80 и 443 порту:

# ansible-playbook /root/ansible-playbooks/05-pb-http-https.yml -i /root/ansible-inventory/my-test-servers.inventory

Некоторое время ждём.

Ответ:

Примечание! Проверим состояние межсетевого экрана на любом из узле.

# firewall-cmd --list-all

Ответ:

Как видно — порты 80 и 443 открыты, то есть отсутствуют с списке разрешенных.

Все узлы успешно получили разрешение на использование 80 и 443 порта.

Чтобы открыть какой-либо конкретный порт, сделайте по аналогии:

---
- name: Разрешение в firewalld порта 10051 для zabbix-agent на узлах
  hosts:
    cos7client1
    cos7client2
    cos7client3
    cos7gla
  become_method: sudo
  become_user: root

  tasks:
  - name: Открыть порт 10051 по UDP
    firewalld:
      port: 10051/udp
      permanent: yes
      state: enabled

  - name: Открыть порт 10051 по TCP
    firewalld:
      port: 10051/tcp
      permanent: yes
      state: enabled

  - name: Перезапустим firewalld на всех узлах
    ansible.builtin.service:
      name: firewalld
      state: restarted

4.5. Установка web-сервера Nginx и тестирование отдачи тестовой страницы.

Для тестовых узлов я выбрал Nginx в качестве учебного web-сервера. Его и установим.

Снова воспользуемся готовым решением ansible.builtin.yum от создателей Ansible по установке web-сервера Nginx на узлах.

Ссылка: docs.ansible.com.
Раздел: «Manages packages with the yum package manager».

Создаем файл плейбука:

# mcedit /root/ansible-playbooks/06-pb-nginx-install.yml

Записываем в него содержимое:

---
- name: Установка web-сервера Nginx на всех узлах
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Создаем файл nginx.repo оригинального репозитория Nginx на узлах
    copy:
      content: "[nginx-mainline]nname=nginx mainline reponbaseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/ngpgcheck=1nenabled=1ngpgkey=https://nginx.org/keys/nginx_signing.keynmodule_hotfixes=true"
      dest: "/etc/yum.repos.d/nginx.repo"
      backup: yes
      owner: root
      group: root
      mode: 0644
  - name: Установим Nginx на узлы
    yum:
      name: nginx
      state: latest
  - name: Запустим Nginx на узлах
    ansible.builtin.service:
      name: nginx
      state: started

Проверим синтаксис плейбука 06-pb-nginx-install.yml специальной утилитой --syntax-check от Ansible:

# ansible-playbook /root/ansible-playbooks/06-pb-nginx-install.yml --syntax-check

Ответ:

Проверка синтаксиса пройдена.

Применим плейбук на узлы и посмотрим как установится web-сервера Nginx на узлах:

# ansible-playbook /root/ansible-playbooks/06-pb-nginx-install.yml -i /root/ansible-inventory/my-test-servers.inventory

Некоторое время ждём.

Ответ:

Проверим доступность демонстрационной страницы HTML web-сервера на узлах Ansible.

Наберем в браузере адрес какого-нибудь узла:

# http://192.168.0.30

Ответ на всех узлах будет одинаковый:

Web-сервер Nginx развернут. Можете использовать его в своих целях.

Что еще интересного можно сделать:

• поменять на готовую страничку приветствия, через проброс файла;
• написать свою страничку на HTML5 и подбросить её в виде текстовой строки через плейбук;
• восстановить копию баз данных, подкинуть файлы хостинга и конфигурации Nginx;
• и так далее.

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

Вот описание замысла: инструкция «Nginx: Модификация базовой страницы приветствия. Заглушка на HTML5». Реализуем это.

По умолчанию index.html — заставка Nginx, хранится в каталоге /usr/share/nginx/html на узлах, значит, если её принудительно заменить на что-то другое, то Nginx это будет добросовестно показывать.

В копировании содержимого Ansible каталога в другой каталог узлов, поможет модуль ansible.builtin.copy.

Ссылка: docs.ansible.com.
Раздел: «Copy files to remote locations».

Создадим каталог /root/ansible-files/nginx/ntml5/zastavka для хранения содержимого заглушки на HTML5.

# mkdir -p /root/ansible-files/nginx/html5/zastavka

Заранее скачайте заставку на HTML5 и распакуйте её в каталог /root/ansible-files/nginx/ntml5/zastavka. Будем копировать содержимое этого каталога на узлы Ansible.

Создаем файл плейбука:

# mcedit /root/ansible-playbooks/07-pb-nginx-html5.yml

Записываем в него содержимое:

--
- name: Копирование каталогов Ansible в каталог узлов
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
# Копируйте дважды, так как иногда файлы пропускаются (в основном только один файл пропускается из папки, если папка не существует).
  - name: Копирование из каталога в каталог
    copy:
      src: "/root/ansible-files/nginx/html5/zastavka/"
      dest: "/usr/share/nginx/html/"
      owner: root
      group: root
      mode: 0644
      backup: yes
    ignore_errors: true

Примечание: Если вы передаете несколько путей с помощью переменной, тогда:

src: "/ корень / {{элемент}}"

Примечание: Если вы передаете путь, используя переменную для разных элементов, тогда:

src: "/ root / {{item.source_path}}"

Проверим синтаксис плейбука 07-pb-nginx-html5.yml специальной утилитой --syntax-check от Ansible:

# ansible-playbook /root/ansible-playbooks/07-pb-nginx-html5.yml --syntax-check

Ответ:

Проверка синтаксиса пройдена.

Применим плейбук на узлы и посмотрим как измениться страница приветствия web-сервера Nginx на узлах:

# ansible-playbook /root/ansible-playbooks/07-pb-nginx-html5.yml -i /root/ansible-inventory/my-test-servers.inventory

Некоторое время ждём.

Ответ:

Проверим доступность новой демонстрационной страницы HTML web-сервера на узлах Ansible.

Наберем в браузере адрес какого-нибудь узла:

# http://192.168.0.39

Ответ на всех узлах одинаковый:

Web-сервер получил новую заглушку HTML5 и Nginx поменял страничку приветствия, которая была по умолчанию.

4.6. Добавить пользователей с sudo.

Для обслуживания тестовых серверов создадим пару учетных записей для самых трудолюбивых сотрудников, которые будут работать не покладая лапок. Учетный записи для пользователей: Мурзик и Барсик.

Создадим на самом сервере Ansible двух пользователей: myrzik и barsik. Генерируем для них ключи. Можно и готовые ключи использовать для установки на узлах, но у меня их нет. Барсик с Мурзиком не прислали ключи.

Создание:

# adduser myrzik
# adduser barsik

Установка паролей, чтобы они могли заходить на сервер Ansible:

# passwd myrzik
# passwd barsik

Генерируем для них ключи:

# su myrzik
# ssh-keygen

На все вопросы для myrzik просто жмём Enter.

# su barsik
# ssh-keygen

На все вопросы для barsik просто жмём Enter.

Теперь у нас на сервере Ansible появилось две учетные записи для наших пушистых коллег.

Добавим на узлы с помощью Ansible учетные записи пользователей myrzik и barsik вход по ключам, а так же режим sudo без пароля для них.

В работе Ansible с учетными записями пользователей поможет модуль ansible.builtin.user.

Ссылка: docs.ansible.com.
Раздел: «Manage user accounts».

Создаем файл плейбука:

# mcedit /root/ansible-playbooks/08-pb-sudo-users.yml

Записываем в него содержимое:

--
- name: Дистанционно добавление произвольных учетных записей с Ansible на узлы
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Убедимся, что у нас на узлах есть группа "wheel"
    group:
      name: wheel
      state: present

  - name: Разрешим пользователям группы "wheel" иметь sudo без пароля
    lineinfile:
      dest: /etc/sudoers
      state: present
      regexp: '^%wheel'
      line: '%wheel ALL=(ALL) NOPASSWD: ALL'
      validate: visudo -cf %s

  - name: Создадим пользователя myrzik и поместим его в группу "wheel"
    ansible.builtin.user:
      name: myrzik
      comment: Cat Myrzik
      group: wheel

  - name: Пробросим публичный ключ пользователя myrzik с Ansible
    authorized_key:
      user: myrzik
      state: present
      key: "{{ lookup('file', '/home/myrzik/.ssh/id_rsa.pub') }}"
      path: /home/myrzik/.ssh/authorized_keys

  - name: Создадим пользователя barsik и поместим его в группу "wheel"
    ansible.builtin.user:
      name: barsik
      comment: Cat Barsik
      group: wheel

  - name: Пробросим публичный ключ пользователя barsik с Ansible
    authorized_key:
      user: barsik
      state: present
      key: "{{ lookup('file', '/home/barsik/.ssh/id_rsa.pub') }}"
      path: /home/barsik/.ssh/authorized_keys

Проверим синтаксис плейбука 08-pb-sudo-users.yml специальной утилитой --syntax-check от Ansible:

# ansible-playbook /root/ansible-playbooks/08-pb-sudo-users.yml --syntax-check

Ответ:

Проверка синтаксиса пройдена.

Применим плейбук на узлы и посмотрим что будет с обновление программного обеспечения:

# ansible-playbook /root/ansible-playbooks/08-pb-sudo-users.yml -i /root/ansible-inventory/my-test-servers.inventory

Ответ:

На все узлы были добавлены учетные записи myrzik и barsik с входом по ключу и sudo возможностями.

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

# su myrzik

# ssh myrzik@192.168.0.39

# sudo su

Мы стали root.

Вернёмся обратно на Ansible сервер:

# exit

# exit

# exit

Ответы:

Для учетной записи barsik аналогично, у него тоже лапки:

Всё работает исправно!

4.7. Удаление учетных записей пользователей.

Так как пользователи Мурзик и Барсик, начали хулиганить на узлах и ронять сервера своими лапками, срочно удалим их учетные записи со всех узлов!

Для удаления учетных записей воспользуемся готовым решением ansible.builtin.user от создателей Ansible.

Ссылка: docs.ansible.com.
Раздел: «Manage user accounts».

Создаем файл плейбука:

# mcedit /root/ansible-playbooks/09-pb-users-del.yml

Записываем в него содержимое:

---
- name: Дистанционно удалим произвольные учетные записи на всех узлах
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Удалим учетную запись myrzik на узлах
    ansible.builtin.user:
      name: myrzik
      state: absent
      remove: yes

  - name: Удалим учетную запись barsik на узлах
    ansible.builtin.user:
      name: barsik
      state: absent
      remove: yes

Проверим синтаксис плейбука 09-pb-users-del.yml специальной утилитой --syntax-check от Ansible:

# ansible-playbook /root/ansible-playbooks/09-pb-users-del.yml --syntax-check

Ответ:

Проверка синтаксиса пройдена.

Применим плейбук на узлы и посмотрим как удалятся учетные записи:

# ansible-playbook /root/ansible-playbooks/09-pb-users-del.yml -i /root/ansible-inventory/my-test-servers.inventory

Некоторое время ждём.

Ответ:

Указанные в плейбуке учетные на узлах Ansible удалены.

4.8. Запуск консольных команд.

Иногда на узлах требуется запускать простые банальные консольные команды.

Воспользуемся модулем ansible.builtin.shell от создателей Ansible.

Ссылка: docs.ansible.com.
Раздел: «Execute shell commands on targets».

Создаем файл плейбука:

# mcedit /root/ansible-playbooks/10-pb-shell.yml

Записываем в него содержимое:

---
- name: Запустим с помощью Ansible команду для командной строки на узлах
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Запустим дистанционно запись генерированной строки в файл
    ansible.builtin.shell: openssl rand -base64 32 >> somefile.txt
    args:
      chdir: /root
      creates: somefile.txt
  - name: Скопируем полученный файл внутри каталога
    ansible.builtin.shell: cp /root/somefile.txt /root/somefile2.txt

Проверим синтаксис плейбука 10-pb-shell.yml специальной утилитой --syntax-check от Ansible:

# ansible-playbook /root/ansible-playbooks/10-pb-shell.yml --syntax-check

Ответ:

Применим плейбук на узлы и посмотрим как удалятся учетные записи:

# ansible-playbook /root/ansible-playbooks/10-pb-shell.yml -i /root/ansible-inventory/my-test-servers.inventory

Некоторое время ждём.

Ответ:

Команда для командной строки на узлах Ansible исполнена.

Есть еще способы запустить консольную команду:

---
- name: Установка zabbix-agent на узлах
  hosts:
    cos7client1
    cos7client2
    cos7client3
  become_method: sudo
  become_user: root

  tasks:
  - name: Установка репозитория docker и установка docker на узлы
    ansible.builtin.shell: "curl -fsSL https://get.docker.com/ | sh"

  - name: Поставим в автозапуск docker на узлах
    ansible.builtin.service:
      name: docker
      enabled: yes

  - name: Запустим docker на узлах
    ansible.builtin.service:
      name: docker
      state: started

  - name: Версия docker на узлах
    ansible.builtin.shell: docker info

  - name: Executing a Command Using Shell Module
    shell: docker info

  - name: Executing a command using command module
    command: docker info

Для того, что бы увидеть что выводит команда в консоль узла, введите ключ -vvv:

# ansible-playbook /ansible/roles/docker-install.yml -i /ansible/hosts/pb-zs-stend.yaml -l cos7client1 -vvv

4.9. Объединение плейбуков в Основную книгу.

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

Например:

---
- import_playbook: A-systemd-networkd.yml
- import_playbook: B-fail2ban-ssh.yml
- import_playbook: C-enable-watchdog.yml

Создадим Основную книгу:

# mcedit /root/ansible-playbooks/my-main-book.yml

Вот такой вот будет Основная книга нашем в учебном варианте:

---
- name: Запустим с помощью Ansible сборник плейбуков - Основная книга
  hosts: test_servers
  become_method: sudo
  become_user: root

- import_playbook: 01-pb-selinux-disable.yml
- import_playbook: 02-pb-reboot.yml
- import_playbook: 03-pb-upgrade-all-packages.yml
- import_playbook: 04-pb-progs-install.yml
- import_playbook: 05-pb-http-https.yml
- import_playbook: 06-pb-nginx-install.yml
- import_playbook: 07-pb-nginx-html5.yml
- import_playbook: 08-pb-sudo-users.yml
- import_playbook: 09-pb-users-del.yml
- import_playbook: 10-pb-shell.yml

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

# ansible-playbook /root/ansible-playbooks/my-main-book.yml --syntax-check

Ответ:

Применим Основную книгу на узлы и посмотрим как по экрану поползет длинная вереница событий на узлах:

# ansible-playbook /root/ansible-playbooks/my-main-book.yml -i /root/ansible-inventory/my-test-servers.inventory

Некоторое время ждём.

Ответ:

Все задачи во всех плейбуках успешно выполнены!

5. Прочие операции с плейбуками.

5.1. Проверка синтаксиса плейбука:

# ansible-playbook /root/ansible-playbooks/01-pb-selinux-disable.yml --syntax-check

Ответ:

5.2. Просмотр задач, которые будут выполнены в плейбуке:

# ansible-playbook /root/ansible-playbooks/01-pb-selinux-disable.yml --list-tasks

Ответ:

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

# ansible-playbook /root/ansible-playbooks/01-pb-selinux-disable.yml --list-hosts

Ответ:

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

1. kamaok.org.ua «Установка и использование Ansible на Centos7».
2. oblako.kz «Установка Ansible на Centos 7.3».
3. tproger.ru «Что такое Ansible и как его использовать».
4. habr.com «Пособие по Ansible».
5. stackru.com «Можно ли записать эти команды в Ansible Playbook?»
6. habr.com «Заметка по ansible. Server reboot.»
7. itisgood.ru «Перезагрузка хоста с помощью Ansible».
8. codeby.net «Как создать новый файл config в Ansible playbook».
9. qastack.ru «Скопируйте несколько файлов с помощью Ansible».
10. qastack.ru «Как создать каталог с помощью Ansible».
11. docs.ansible.com «selinux — Change policy and state of SELinux».
12. docs.ansible.com «ansible.builtin.meta – Execute Ansible ‘actions’».
13. docs.ansible.com «ansible.builtin.yum — Manages packages with the yum package manager».
14. docs.ansible.com «ansible.posix.firewalld – Manage arbitrary ports/services with firewalld».
15. docs.ansible.com «ansible.builtin.service — Manage services».
16. docs.ansible.com «ansible.builtin.copy — Copy files to remote locations».
17. docs.ansible.com «ansible.builtin.user — Manage user accounts».
18. docs.ansible.com «ansible.builtin.shell – Execute shell commands on targets».
19. docs.ansible.com «ansible.builtin.reboot – Reboot a machine».
20. sprosi.pro «Как запустить несколько playbooks в соответствии с Ansible?»
21. Источник: https://hamsterden.ru/practical-examples-of-playbooks/

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

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.

Ссылка: docs.ansible.com.
Раздел: «ansible-playbook».

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

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

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

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

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

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

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

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

2. Сценарии — playbooks.

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

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

Все сценарии в Ansible пишутся на YAML — это удобный для человека формат данных, гораздо более простой, чем XML или JSON.

Чтобы выполнить сценарий используется команда ansible-playbook со следующим синтаксисом:

# ansible-playbook <имя_файла_сценария.yml> ... [другие параметры]

Для Ansible практически каждый YAML файл начинается со списка. Каждый элемент списка — список пар «ключ-значение», часто называемая словарем.

В начале сценария обязательно должна присутствовать последовательность символов ‘---‘ (так в YAML обозначается начало документа).

Перед каждым новым разделом списка ставится дефис ( - ):

---
- name: Операции с SELinux
  hosts: webservers
  become_method: sudo
  become_user: root

  tasks:
  - name: Отключаем SELinux
    selinux:
      state: disabled

Основными параметрами/группами простого сценария являются:

• hosts — в нем указываются управляемые узлы или группы узлов, к которым нужно применить изменения;
• tasks — здесь описывается состояние, в которое необходимо привести управляемый узел, альтернативой этому могут служить роли;

Также в сценарии перед непосредственным описанием задач могут быть указаны следующие параметры или группы параметров:

• gather_facts — собирать или нет информацию об узлах перед выполнением задач, по умолчанию — да;
• vars — в нем указываются различные переменные, которые будут использованы при выполнении сценария;
• connection — можно указать метод соединения с узлами: pure ssh, paramiko, fireball, chroot, jail, local, accelerate (применимо также для выполнения отдельного модуля);
• sudo — после установления соединения выполнять задачу с привилегиями другого пользователя, по умолчанию другой пользователь — root;
• sudo_user — в сочетании с предыдущим параметром можно указать с привилегиями какого именно пользователя будет выполнена задача;
• vars_prompt — перед выполнением плейбука Ansible в интерактивном режиме может уточнить указанные в этом разделе параметры;
• remote_user (в предыдущих версиях — просто user) — имя пользователя для авторизации на удалённом узле.

Рассмотрим все эти разделы более подробно.

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

Так, строка формата:

hosts: webservers

Это означает, что изменения будут применены к узлам из группы webservers.

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

В следующем примере авторизация на узле будет произведена с именем yourname, но задачи будут выполняться от имени пользователя root (если, конечно, этому пользователю это разрешено):

---
- name: Операции с SELinux
  hosts: webservers
  become_method: sudo
  become_user: yourname

Если добавить параметр ‘user: postgres‘, то все действия будут выполняться с привилегиями пользователя postgres.

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

- hosts: webservers
  vars:
     http_port: 80
     max_clients: 200

Список изменений, которые необходимо произвести на управляемом узле, приводится в разделе tasks. Каждой задаче (task) присваивается имя (name).

Далее указываются модули Ansible, которые будут задействованы при ее выполнении:

---
- hosts: webservers
  user: yourname
  tasks:
  - service:
      name: nginx
      state: started

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

---
- hosts: webservers
  user: yourname
  tasks:
  - service:
      name: nginx
      state: started
    sudo: yes

Еще некоторые примеры.

Все члены списка должны находится с одинаковым отступом от начала строки, и должны начинаться с пробела или «-». Комментарии начинаются с «#».

Например:

---
# Message
- Hosting
  Cloud

Словарь представлен в виде «ключ:» (двоеточие и пробел) «значение»:

---
# Message
site: habr
blog: infobox

При необходимости словари могут быть представлены в сокращенной форме:

--
# Comment
{site: habr, blog: infobox}

Можно указать логические значение (истина/ложь) так:

---
need_access: no
use_service: yes
file_conf: TRUE
read_value: True
kill_process: false

Целиком наш пример YAML–файла будет выглядеть так:

---
# About blog
site: hamstersen.ru
blog: infobox
must_read: true
themes:
- hosting
- cloud
- it
- geeks
  brands:
  - infobox
  - infoboxcloud

Для переменных Ansible использует «{{ var }}». Если значение после двоеточия начинается с «{», то YAML будет думать, что это словарь.

Для использования переменных нужно заключить скобки в кавычки:

word: "{{ variable }}"

Этого достаточно для начала написания playbooks.

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

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

3. Обработчики событий — handlers.

Ansible не просто выполняет задачи в указанном порядке, но и проверяет их состояние на наличие изменений. Если при выполнении сценария требовалось, например, добавить строку в конфигурационный файл, и в результате выполнения он изменился (необходимой строки действительно не было), то Ansible может выполнить специальную задачу, описанную как обработчик события (handler). Если при выполнении строка уже была в конфигурационном файле, то обработчик выполнен не будет. Обработчики событий описываются в конце сценария. В описании задачи они указываются через параметр notify.

Приведём пример:

---
- hosts: webservers
  vars:
    max_clients: 200

  tasks:
  # генерируем файл конфигурации на основе шаблона
  # и укажем, что требуется выполнить задачу “restart apache”
  # если файл изменился
  - name: write the apache config file
    template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf
    notify:
    - restart apache
  - name: ensure apache is running
    service: 
      name: httpd
      state: started
# раздел описания обработчиков
  handlers:
    - name: restart apache
    # используем модуль service для перезапуска веб-сервера
      service:
        name: httpd
        state: restarted

4. Контроль выполнения.

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

Для этого можно использовать оператор «when»:

tasks:
    # сохраняем файл шаблона и сохраняем результат задачи
    # в переменную last_result
    - template:
        src: /templates/foo.j2
        dest: /etc/foo.conf
      register: last_result
    # проверяем переменную last_result.changed и если она имеет
    # значение true - задача будет выполнена, иначе - будет пропущена
    - command:
        echo 'the file has changed'
        when: last_result.changed

5. Шаблонизация.

В Ansible используется шаблонизатор Jinja2.

Приведём пример шаблона (часть конфигурации powerdns):

# пароль для подключения к базе данных
gpgsql-password={{ lookup('password', 'credentials/' + inventory_hostname + '/postgresql/powerdns', length=15) }}

# IPv4-адрес, который будет “слушать” powerdns
local-address={{ ansible_default_ipv4.address }}

# IPv6-адрес, который будет “слушать” powerdns
local-ipv6={{ ansible_default_ipv6.address }}

# nsid dns-сервера (EDNS option 3, rfc5001)
server-id={{ ansible_hostname }}

В приведённом примере мы подставляем в шаблон следующие значения:

• из заранее собранных фактов об узле:
  • ansible_default_ipv4.address — основной IPv4-адрес узла;
  • ansible_default_ipv6.address — основной IPv6-адрес узла;
  • ansible_hostname — имя узла (результат выполнения команды hostname).
• inventory_hostname — имя узла в инвентарном файле;
• пароль пользователя powerdns из внешнего источника данных (в данном случае файл) для подключения к базе Postgresql , полученный с помощью lookup-плагина password из стандартной поставке. Особенность некоторых lookup-плагинов — если данных нет, то они могут их генерировать и сохранить для последующего использования.

Обработку шаблонов и, в данном случае, генерацию конфигурационного файла выполняет модуль template; он же может задать необходимые права доступа и изменить владельца/группу:

- name: generate powerdns config
template: src=pdns.conf.j2 dest=/etc/powerdns/pdns.conf owner=powerdns group=powerdns mode=600

Внимание! Файл шаблона и файл с паролем пользователя базы данных находятся на машине управления, а результатом будет файл на удалённом узле.

6. Делегирование задачи другому узлу.

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

Например, во время обновления узла может возникнуть необходимость отключить для него мониторинг, находящийся на отдельном сервере. Для этого используется управляющая директива delegate_to.

Приведём пример:

- name: disable nagios alerts for this host webserver service
  nagios:
    action: disable_alerts
    host: {{inventory_hostname}}
    services: dnsserver
  delegate_to: mon_host.example.com

Результатом выполнения этой задачи будет отключение сообщений для сервиса dnsserver в Nagios.

7. Роли.

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

В сценариях роли назначаются следующим образом:

---
- name: check and apply basic configuration to all hosts
   hosts: all
   roles:
     - common

- name: check and apply configuration to group1
   hosts: group1
   roles:
     - pgsql

- name: check and apply configuration to group2
   hosts: group2
   roles:
     - fooapp

8. Структура проекта.

9. Пишем первые playbook’и.

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

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

В качестве другого примера давайте рассмотрим процесс установки nginx.

Создадим директорию, где будут хранится playbooks:

# mkdir ~/ansible/playbooks

Создадим файл setup_nginx.yml в директории playbooks со следующим содержанием:

---
- hosts: experiments
  tasks:
  - name: Install nginx package
    apt: 
      name: nginx
      update_cache: yes
    sudo: yes
  - name Starting nginx service
    service:
      name: nginx
      state: started
    sudo: yes

Давайте рассмотрим содержимое:

• hosts: Список узлов или группа, на которой вы запускаете задачу.

Это поле обязательное и каждый playbook должен иметь его, за исключением ролей. Если указана узловая-группа, сначала Ansible ее ищет в playbook, а затем в файле inventory.

Узнать, на каких узлах будет происходить работа, можно командой:

# ansible-playbook --list-host

где – путь к вашему playbook (playbooks/setup_nginx.yml).

• tasks: Задачи. Все playbooks содержат задачи.

Задача — это список действий, которые вы хотите выполнить. Поле задачи содержит имя задачи (справочная информация о задаче для пользователя playbook), модуль, который должен быть выполнен и аргументы, требуемые для модуля. Параметр «name» может добавляться опционально, но, в целом,  рекомендуемый.

10. Пример сценария.

В этом примере первое воспроизведение предназначено для web-серверов, а второе — для серверов баз данных:

Пример сценария:

---
- name: update web servers
  hosts: webservers
  remote_user: root

  tasks:
  - name: ensure apache is at the latest version
    yum:
      name: httpd
      state: latest
  - name: write the apache config file
    template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf

- name: update db servers
  hosts: databases
  remote_user: root

  tasks:
  - name: ensure postgresql is at the latest version
    yum:
      name: postgresql
      state: latest
  - name: ensure that postgresql is started
    service:
      name: postgresql
      state: started

11. Практические примеры плейбуков.

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

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

12. Запуск плейбуков.

Чтобы запустить плейбук и выполнить все определенные в нем задачи, используйте команду ansible-playbook:

# ansible-playbook myplaybook.yml

Чтобы перезаписать в плейбуке опцию hosts по умолчанию и ограничить выполнение определенной группой или узлом, включите в команду опцию -l:

# ansible-playbook -l server1 myplaybook.yml

13. Запрос информации о play.

Опция --list-tasks используется для перечисления всех задач, которые будут выполнены в play, при этом не внося никаких изменений на удаленные серверы:

# ansible-playbook myplaybook.yml --list-tasks

Точно так же можно запросить все узлы, которые будут затронуты выполнением play, без запуска каких-либо задач на удаленных серверах:

# ansible-playbook myplaybook.yml --list-hosts

Вы можете использовать теги, чтобы ограничить выполнение play.

Чтобы вывести список всех тегов, доступных в play, используйте параметр --list-tags:

# ansible-playbook myplaybook.yml --list-tags

14. Управление выполнением плейбука.

Вы можете использовать опцию --start-at-task, чтобы определить новую точку входа вашего плейбука. Затем Ansible пропустит все, что предшествует указанной задаче, выполнив оставшуюся часть play с заданного момента.

Эта опция в качестве аргумента требует правильное имя задачи:

# ansible-playbook myplaybook.yml --start-at-task="Set Up Nginx"

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

Например, если вы хотите выполнить только задачи, помеченные как nginx или mysql, вы можете использовать:

# ansible-playbook myplaybook.yml --tags=mysql,nginx

Если вы хотите пропустить все задачи, которые находятся под определенными тегами, используйте --skip-tags.

Следующая команда будет выполнять myplaybook.yml, пропуская все задачи, помеченные как mysql:

# ansible-playbook myplaybook.yml --skip-tags=mysql

15. Настройка защищенных плейбуков.

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

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

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

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

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. Источник: https://hamsterden.ru/ansible-playbooks/

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

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