Zip — это один из самых распространенных и наиболее популярных способов создания сжатых архивных файлов. Это также один из самых старых форматов архивных файлов, он был создан в 1989 году. Поскольку он широко используется, вы будете регулярно сталкиваться с zip-файлами.
В одном из предыдущих уроков я показал, как заархивировать папку в Linux. В этом кратком руководстве для начинающих я покажу вам, как распаковывать файлы в Linux. Читать
Мы рассмотрим процесс поднятия двух контейнеров с PostgreSQL и настройки репликации данных между ними. Использовать будем систему на базе Linux, однако, сам процесс настройки Docker и репликации не зависит от операционной системы.
На компьютере, где мы будем запускать наш кластер баз данных должен быть установлен Docker. Также мы сразу рассмотрим развертывание нужной нам инфраструктуры в docker-compose. Для установки необходимой одноименной платформы смотрим инструкцию Установка Docker на Linux.
После мы можем переходить к поднятию контейнеров.
Как говорилось выше, мы будем поднимать наши контейнеры с помощью docker-compose.
Создадим каталог, в котором будем работать:
mkdir -p /opt/docker/postgresql
Переходим в него:
cd /opt/docker/postgresql
Создаем файл для docker-compose:
vi docker-compose.yml
---
services:
postgresql_01:
image: postgres
container_name: postgresql_01
restart: always
volumes:
- /data/postgresql_01:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: postgres024
postgresql_02:
image: postgres
container_name: postgresql_02
restart: always
volumes:
- /data/postgresql_02/:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: postgres024
* рассмотрим некоторый опции подробнее:
Запускаем наши контейнеры:
docker-compose up -d
Мы должны увидеть:
Creating postgresql_02 ... done
Creating postgresql_01 ... done
А если вывести список контейнеров:
docker ps
… мы должны увидеть наши два.
Теперь можно переходить к настройке репликации.
Условимся, что первичный сервер или master будет в контейнере с названием postgresql_01. Вторичный — postgresql_02. Мы будем настраивать потоковую (streaming) асинхронную репликацию.
Подключаемся к контейнеру docker:
docker exec -it postgresql_01 bash
Заходим под пользователем postgres:
su - postgres
Создаем пользователя, под которым будем подключаться со стороны вторичного сервера:
createuser --replication -P repluser
* в данном примере будет создаваться учетная запись repluser с правами репликации.
Система потребует ввода пароля. Придумываем его и набираем дважды.
Выходим из-под пользователя postgres:
exit
Выходим из контейнера:
exit
Открываем конфигурационный файл postgresql.conf:
vi /data/postgresql_01/postgresql.conf
Приводим к следующием виду некоторые параметры:
wal_level = replica
max_wal_senders = 2
max_replication_slots = 2
hot_standby = on
hot_standby_feedback = on
* где
Посмотрим подсеть, которая используется для контейнеров с postgresql:
docker network inspect postgresql_default | grep Subnet
В моем случае, ответ был:
"Subnet": "172.19.0.0/16",
Теперь открываем файл:
vi /data/postgresql_01/pg_hba.conf
И добавляем строку после остальных «host replication»:
host replication all 172.19.0.0/16 md5
* в данном примере мы разрешили подключение пользователю replication из подсети 172.19.0.0/16 с проверкой подлинности по паролю.
Перезапустим докер контейнер:
docker restart postgresql_01
Выполним настройку вторичного сервера. Для начала, удалим содержимое рабочего каталога вторичной базы:
rm -r /data/postgresql_02/*
* в данном примере мы удалим все содержимое каталога /data/postgresql_02.
Мы должны быть уверены, что в базе нет ничего важного. Только после этого стоить удалять данные.
Заходим внутрь контейнера postgresql_02:
docker exec -it postgresql_02 bash
Выполняем команду:
su - postgres -c "pg_basebackup --host=postgresql_01 --username=repluser --pgdata=/var/lib/postgresql/data --wal-method=stream --write-recovery-conf"
* где postgresql_01 — наш мастер; /var/lib/postgresql/data — путь до каталога с данными слейва.
Система должна запросить пароль для пользователя repluser — вводим его. Начнется процесс репликации, продолжительность которого зависит от объема данных.
Смотрим статус работы мастера:
docker exec -it postgresql_01 su - postgres -c "psql -c 'select * from pg_stat_replication;'"
Смотрим статус работы слейва:
docker exec -it postgresql_02 su - postgres -c "psql -c 'select * from pg_stat_wal_receiver;'"
Источник: https://www.dmosk.ru/miniinstruktions.php?mini=postgresql-replication-docker
На чем было опробовано:
К примеру, нам требуется с помощью внедрения custom facts для Ansible организовать сбор версий контейнеров, запущенных на серверах, а так же сбор версий некоторого программного обеспечения на серверах, которое имеет файл с указанием версии в своём каталоге /ecp/po/version.txt.
Собранная информация должна формироваться в json-формат.
Дополнительно требуется рассмотреть средства визуализации информации в удобном виде (opensource web-приложения).
Решение будет состоять из нескольких этапов:
В системе Ansible есть возможность собирать системную информацию, которая собирается в виде фактов с помощью встроенного модуля setup.
Со сбором стандартных переменных по умолчанию всё предельно ясно, но что делать, если мы хотим сформировать наши собственные переменные на всех хостах, чтобы в дальнейшем использовать их в нашем коде?
Для этого существует возможность добавления Custom facts, что делается следующим образом:
/etc/ansible/facts.d;*.fact, например custom.fact;
Создаем инвентарь 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, то информация будет корректно визуализирована в удобно читаемом виде:
Задача выполнена!
На чем было опробовано:
Как установить и первоначально настроить Ansible описано здесь:
Ссылка: «Ansible: Часть 1. Описание, установка и первоначальная настройка.»
Так как простые задачи для Ansible реально простые, в буквальном смысле слова, то я принял решение вынести их в отдельную инструкцию:
Ссылка: «Ansible: Часть 2. Примеры простых задач.»
Рассмотрим структуру и правила написания таких сценариев более подробно.
Ссылка: «Ansible: Часть 3. Сценарии (плейбуки) — Playbooks.»
По данной ссылке я создам небольшую подборку самых интересных и типовых плейбуков, которые могут пригодиться вам в повседневной работе.
Ссылка: «Ansible: Часть 4. Практические примеры плейбуков.»
Если ваши плейбуки Ansible содержат конфиденциальные данные, такие как пароли, ключи API и учетные данные, важно обеспечить их безопасность с помощью шифрования. Ansible предоставляет ansible-vault для шифрования файлов и переменных.
Несмотря на то, что любой файл данных Ansible, а также двоичные файлы, возможно зашифровать изначально, чаще для шифрования переменных файлов, содержащих конфиденциальные данные, используется ansible-vault. После шифрования файла с помощью этого инструмента вы сможете выполнять, редактировать или просматривать его, только предоставив соответствующий пароль, указанный при первом шифровании файла.
2.1. Создание нового зашифрованного файла.
Вы можете создать новый зашифрованный файл Ansible с помощью:
# ansible-vault create credentials.yml
Эта команда выполнит следующие действия:
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. После проверки пароля откроется редактор командной строки по умолчанию с незашифрованным содержимым файла, что позволит вам внести нужные изменения. По завершении вы можете сохранить и закрыть файл, как обычно, и обновленное содержимое будет сохранено и зашифровано.
Если вы хотите навсегда расшифровать файл, ранее зашифрованный с помощью ansible-vault, вы можете сделать это с помощью следующего синтаксиса:
# ansible-vault decrypt credentials.yml
Эта команда предложит вам ввести тот пароль, который использовался при первом шифровании файла. После проверки пароля содержимое файла будет сохранено на диск в виде незашифрованных данных.
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
Если вам нужно автоматизировать процесс инициализации серверов в 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 содержит несколько примеров сценариев, которые вы можете использовать для справки при создании своего скрипта под потребности вашего проекта.
Каждый раз, когда вы запускаете плейбук, в котором используются данные, ранее зашифрованные с помощью 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
На чем было опробовано:
Для тех, кто решит изучать Ansible, данный раздел будет крайне полезен. В данном разделе соберу некоторые полезные примеры из повседневной практики, чтобы вы могли понять как работает Ansible и научиться его использовать самостоятельно.
Официальную документацию с официальными примерами всегда можно почитать на сайте разработчиков Ansible.
Ссылка: docs.ansible.com.
Раздел: «Intro to playbooks».
Как установить и первоначально настроить Ansible описано здесь:
Ссылка: «Ansible: Часть 1. Описание, установка и первоначальная настройка.»
Так как простые задачи для Ansible реально простые, в буквальном смысле слова, то я принял решение вынести их в отдельную инструкцию:
Ссылка: «Ansible: Часть 2. Примеры простых задач.»
Рассмотрим структуру и правила написания таких сценариев более подробно.
Ссылка: «Ansible: Часть 3. Сценарии (плейбуки) — Playbooks.»
Как настраивать защищенные плейбуки описано в этом разделе.
Ссылка: «Ansible: Часть 5. Настройка защищенных плейбуков.»
Пускай у нас будет вот такой стенд из 4х виртуальных машин под управлением CentOS 7:
Все сервера, в данном примере, имеют одинаковую операционную систему CentOS Linux release 7.9.2009 (Core), одинаковых пользователей root и одинаковые пароли на учетных записях root.
Задачи: для всех узлов.
Протестировать:
Условие: удалённые виртуальные машины можно настраивать только системой Ansible.
Дополнительно: еще в эту инструкцию я буду добавлять разные новые и полезные примеры, но вверху в задачах, учитывать это не буду.
Первым делом отключим на Ansible Server систему SELinux. Рамках учебного стенда она нам не нужна.
Когда вы устанавливаете CentOS 7, функция SELinux включена по умолчанию, из-за этого некоторые приложения в вашей системе могут фактически не поддерживать этот механизм безопасности. Чтобы такие приложения функционировали нормально, вам необходимо отключить SELinux.
Ссылка: «CentOS 7: Как временно или навсегда отключить SELinux».
Конечно в интернете имеется много способов настройки и эксплуатации этой системы, но в данной инструкции я, пока что, настраивать SELinux не буду.
Пожалуй, это самый суровый способ, но тоже работает.
Вводим команду:
# yum -y remove selinux*
Перезапустим Ansible Server:
# shutdown -r now
Обновим полностью операционную систему сервера Ansible:
# yum -y update && yum -y upgrade
По умолчанию 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
Ответы:
Чтобы убедиться, что 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 учебный комплекс готов!
Внимание! Почти все типовые действия, которые вам потребуются для работы с 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 не сложная задача.
Предполагаются следующие шаги:
В 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
Этот плейбук выполнит следующее:
whoami.
Применим плейбук:
# 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». Реализуем это.
По умолчанию 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.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
Ответ:
На чем было опробовано:
Официальную документацию с официальными примерами всегда можно почитать на сайте разработчиков Ansible.
Ссылка: docs.ansible.com.
Раздел: «ansible-playbook».
Как установить и первоначально настроить Ansible описано здесь:
Ссылка: «Ansible: Часть 1. Описание, установка и первоначальная настройка.»
Так как простые задачи для Ansible реально простые, в буквальном смысле слова, то я принял решение вынести их в отдельную инструкцию:
Ссылка: «Ansible: Часть 2. Примеры простых задач.»
По данной ссылке я создам небольшую подборку самых интересных и типовых плейбуков, которые могут пригодиться вам в повседневной работе.
Ссылка: «Ansible: Часть 4. Практические примеры плейбуков.»
Как настраивать защищенные плейбуки описано в этом разделе.
Ссылка: «Ansible: Часть 5. Настройка защищенных плейбуков.»
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. Практические примеры плейбуков.»
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
Допустим, что при выполнении сценария нам нужно проверять определённые переменные или состояния и, в зависимости от них, выполнять или не выполнять какие-либо задачи.
Для этого можно использовать оператор «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
В 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 — имя узла в инвентарном файле;
Обработку шаблонов и, в данном случае, генерацию конфигурационного файла выполняет модуль template; он же может задать необходимые права доступа и изменить владельца/группу:
- name: generate powerdns config
template: src=pdns.conf.j2 dest=/etc/powerdns/pdns.conf owner=powerdns group=powerdns mode=600
Внимание! Файл шаблона и файл с паролем пользователя базы данных находятся на машине управления, а результатом будет файл на удалённом узле.
Иногда требуется выполнить задачу на определённом узле, но в контексте другого узла.
Например, во время обновления узла может возникнуть необходимость отключить для него мониторинг, находящийся на отдельном сервере. Для этого используется управляющая директива 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.
Ролью называется типовой набор переменных и задач, назначаемых для одного или нескольких серверов. Если вам нужно применить к серверу или группе серверов типовой набор операций, вам достаточно просто назначить ему роль. Предварительно в проекте каталоге проекта должна быть создана соответствующая структура.
В сценариях роли назначаются следующим образом:
---
- 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
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» может добавляться опционально, но, в целом, рекомендуемый.
В этом примере первое воспроизведение предназначено для 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
По данной ссылке я создам небольшую подборку типовых плейбуков, которые могут пригодиться вам в повседневной работе.
Ссылка: «Ansible: Часть 4. Практические примеры плейбуков.»
Чтобы запустить плейбук и выполнить все определенные в нем задачи, используйте команду ansible-playbook:
# ansible-playbook myplaybook.yml
Чтобы перезаписать в плейбуке опцию hosts по умолчанию и ограничить выполнение определенной группой или узлом, включите в команду опцию -l:
# ansible-playbook -l server1 myplaybook.yml
Опция --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
Вы можете использовать опцию --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
Если ваши плейбуки Ansible содержат конфиденциальные данные, такие как пароли, ключи API и учетные данные, важно обеспечить их безопасность с помощью шифрования. Ansible предоставляет ansible-vault для шифрования файлов и переменных.
Несмотря на то, что любой файл данных Ansible, а также двоичные файлы, возможно зашифровать изначально, чаще для шифрования переменных файлов, содержащих конфиденциальные данные, используется ansible-vault. После шифрования файла с помощью этого инструмента вы сможете выполнять, редактировать или просматривать его, только предоставив соответствующий пароль, указанный при первом шифровании файла.
Ссылка: «Ansible: Часть 5. Настройка защищенных плейбуков.»