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

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/