Ansible. Network-scripts. RHEL8⁠⁠

Приветствую!

Практически завершил работу над ansible-хелпером "conf_int_ipv4_via_network_scripts" (репозиторий "ansible_helpers"), но "практически" означает, что совокупность скриптов и сценариев уже можно использовать в работе.

Краткая инструкция.

1. Клонируем репозиторий - git clone "https://github.com/vladimir-chursin000/ansible_helpers".

2. Переходим в директорию ".../ansible_helpers/conf_int_ipv4_via_network_scripts/rhel8_based".

3. Заполняем inventory-файл "conf_network_scripts_hosts" (не забываем про ssh-ключи на удалённых хостах).

4. Заполняем основной файл конфигурации "config" (такой вот незамысловатый нейминг). Каждая линия - настройка конкретного сетевого интерфейса на конкретном хосте. Присутствует файл со всеми возможными примерами конфигурации - "config_examples".

5. Правим дополнительные файлы конфигурации, расположенные в директории "additional_configs":

а) dns_settings (настройки DNS). По умолчанию содержит только доменные сервера Google (8.8.8.8, 8.8.4.4) в качестве общих NS (nameservers/сервера имён) для всех хостов из inventory-файла. Также присутствует возможность для отдельных хостов выставить уникальные сервера имён;

б) config_del_not_configured_ifcfg. Файл конфигурации, определяющий действия в отношении сетевых интерфейсов, отсутствующих в основном файле конфигурации (который "config"). Для inventory-хостов, вписанных в этот конфиг, действует правило - отключать сетевые интерфейсы (и удалять соответствующие ifcfg-файлы), не сконфигурированные в файле "config".

6. Запускаем скрипт "install_network_scripts_and_configure_network.sh" (если "network-scripts" не установлен) или "apply_immediately_ifcfg.sh".

Что произойдёт после запуска (если опустить часть с установкой "network-scripts"), если кратко:

1. Бэкап ifcfg-файлов с сохранением в директорию (и поддиректории) ".../playbooks/ifcfg_backup_from_remote": "history" - для хранения, "now" - для дальнейшего сравнения с ifcfg-файлами, генерация которых (на основе config-а) произойдёт на следующем этапе.

2. Запуск perl-скрипта "generate_dynamic_ifcfg.pl", которые создаёт:

а) ifcfg-файлы для каждого inventory-хоста (на основе основного конфига). Размещаются в ".../playbooks/dyn_ifcfg_playbooks/dyn_ifcfg";

б) файлы resolv-conf (на основе "dns_settings"). Директория ".../playbooks/dyn_ifcfg_playbooks/dyn_resolv_conf";

в) task-файл для каждого inventory-хоста, содержащий ansible-инструкции для реконфигурации сети (директория ".../playbooks/dyn_ifcfg_playbooks"). Важный момент - если сгенерированные ifcfg-файлы не отличаются от текущих (скопированных на первом этапе исполнения), то task-файл будет содержать только ansible-код для взаимодействия с "resolv.conf".

3. Исполнение сформированных task-файлов.

P.S. №1. Осталась самая малость - реализовать механизм временного применения сетевых настроек (о чём писал ранее).

P.S. №2. Надеюсь, кому-то результат моих изысканий поможет сэкономить время.

[моё] Разработка Программирование IT Perl Linux Shell Командная оболочка bash Ansible

Лига Сисадминов

2.4K постов18.9K подписчика

Добавить пост

Правила сообщества

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

Sonaton

1 год назад

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

раскрыть ветку (1)

VladimirChursin

1 год назад

Спасибо за развёрнутый ответ) Это редкость.
===
Справа у Вас - это, вероятно, yml с параметрами интерфейсов. Файлик там довольно объёмный. На мой взгляд, удобнее в виде таблицы.

Например, при запуске bash-скрипта "03_apply_immediately_ifcfg.sh" происходит следующее:
1) исполнение сценария бэкапа, в т.ч. файлов сетевых интерфейсов и сбор данных о мак-адресах и именах сетевых интерфейсов (знаю, что можно через gather_facts, но с мак-адресами там вроде довольно громоздко).
2) исполнение скрипта "generate_dynamic_ifcfg.pl", который читает конфиг (пример на скрине), проверяет данные конфига (в т.ч. сверяет с теми данными, которые были собраны в п.1), генерирует новые конфиги, сравнивает их с теми файлами, что были закачаны в п1., и, если, условно говоря, отличаются, то генерируется yaml с указанием на то, что необходимо переконфигурировать сетевые интерфейсы.
3) исполнение yaml, сгенерированного в п 2.
Алгоритм собираюсь пересматривать, но концепция останется той же)

показать ответы

Sonaton

1 год назад

Уверен, что любой знающий ансибл человек в этой мешанине баша, ямла и перла просто не захочет разбираться, ибо на взгляд со стороны цель "от сложного к простому" увы-провалена: огромная вложенность, самопальная структура дерева, непонятное назначение половины кода, который ссылается на одни скрипты, которые ссылаются на другие... Если хотите, могу написать Iasc на ансибле для какой-нибудь из ваших готовых "ролей" и тогда вы посмотрите со стороны, как будет проще. Сеть бы я не брал, так-как в сетях я очень не очень, да и тестить не на чем. Ну или нужно нормальное тз.

раскрыть ветку (1)

VladimirChursin

1 год назад

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

Если хотите, могу написать Iasc на ансибле для какой-нибудь из ваших готовых "ролей" и тогда вы посмотрите со стороны, как будет проще. Сеть бы я не брал, так-как в сетях я очень не очень, да и тестить не на чем. Ну или нужно нормальное тз.

А самое интересное для меня как раз - это увидеть реализованный только средствами ансибла сценарий настройки всех возможных вариантов сетевых соединений ( https://github.com/vladimir-chursin000/ansible_helpers/tree/... ) на N-ом количестве хостов, который в обслуживании был бы проще редактирования нескольких конфигов ( https://github.com/vladimir-chursin000/ansible_helpers/tree/... ) + запуска скрипта применения конфигурации.

показать ответы

Sonaton

1 год назад

А можете объяснить...концепт? Ради чего оно все именно в таком виде? Какой цели вы хотели достичь, писав этот код? Как лично я это понял: вы видимо хорошо пишите на шелле и пытаетесь с помощью ансибла упростить те вещи, которые на шелле делать долго/сложно, но делаете так, чтоб это все равно выглядело как шелл. Большинство новичков в ансибле совершает большую ошибку, думая , что ансибл- это штука, как раз типа шелла, позволяет делать скрипты автоматизации, но это не так. Ансибл- это штука, которая приводит объект к требуемому состоянию. Вы не должны делать бэкапы конфигов- конфиги должны генерироваться и валидироваться ансиблом. Вам не нужно делать кучу отдельных плейбуков для установки/удаления/проверки состояния демонов- у вас должно быть описано с помощью переменных , привязанных к хостам/группам состав и целевое состояние демонов и один простой плейбук, который приводит к нему. Я говорю условно, но мой концепт примерно таков.

раскрыть ветку (1)

VladimirChursin

1 год назад

Концепция - сведение сложного к простому для пользователя.

Внешняя оболочка = набор понятных bash-скриптов управления сетевой подсистемой (в курсе, что network-scripts deprecated. И до NetworkManager-а доберусь).

Под капотом - ansible + perl (для генерации целевых ifcfg по заданным в основном конфиге параметрам) + кое-где bash для ansible-хоста и python (via ansible) + bash на стороне управляемых хостов.

Стоит заметить, что не претендую на универсальность подхода. Просто настройка сети (со всеми возможными вариантами) только лишь средствами ansible, если подразумевается что-то сложнее "все хосты имеют один интерфейс" становится задачей не всегда тривиальной. И вот для таких случаев куда быстрее использовать чёткие и понятные конфиги, не завязанные на ansible (на мой взгляд).

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

показать ответы

MpakPM

3 года назад

Нет, я про реализацию скрипта

раскрыть ветку (1)

VladimirChursin

3 года назад

Что не так с реализацией?

alexq2

3 года назад

Готовое решение это хост варс и джинджа. То что вы делаете это какой-то трэш.

раскрыть ветку (1)

VladimirChursin

3 года назад

Буду благодарен, если Вы реализуете описанный случай каноничными средствами ansible и опубликуете ссылку на репозиторий в своём профиле (отправив публикацию в сообщество "Лига сисадминов") со ссылкой на эту публикацию.

alexq2

3 года назад

Используйте модуль nmcli https://docs.ansible.com/ansible/latest/collections/communit...

У вас везде трэш посмотрите на lxc роль и посмотрите на роль lxc в galaxy с рейтингом 3 (я не говорю про 5). У вас везде антипатерны и трэш и вы ещё это кому-то советуете. Прочтите лучше доку для начала.

раскрыть ветку (1)

VladimirChursin

3 года назад

Как в каноничном виде сконфигурировать хотя бы десяток хостов, если условие такое
===
"(хотя бы) поднять/перенастроить несколько бриджей (для одного бриджа используется сетевой интерфейс с назначенным со стороны коммутатора транковым коннектом для доступа к разным vlan-ам c разных бриджей, для другого - обычный коннект), несколько бонд-коннектов (с вланами и без оных) и пару сетевых интерфейсов. При этом каждый хост может/должен содержать различное кол-во сетевых интерфейсов/бондов/бриджей."

Покажете готовое решение?
===
Про nmcli
Публикация имеет имя "Ansible. Network-scripts. RHEL8", а не "Ansible. NetworkManager. RHEL8"

показать ответы

DELETED

3 года назад

А не проще оформить это было все в нормальную ansible role иопубликовать на galaxy ?
Ручное заполнение файла конфигурации для всех зхостов - такое себе. Черт ногу ж сломит в конфиге.
При роле же раскидал в своей репе с инфраструктурой и не паришься.
ПыСы: у себя использую debops.netplan

раскрыть ветку (1)

VladimirChursin

3 года назад

Netplan - это про Ubuntu. Тут речь про RHEL.

Представим, что Вам необходимо, допустим, на десятке хостов (хотя бы) поднять/перенастроить несколько бриджей (для одного бриджа используется сетевой интерфейс с назначенным со стороны коммутатора транковым коннектом для доступа к разным vlan-ам c разных бриджей, для другого - обычный коннект), несколько бонд-коннектов (с вланами и без оных) и пару сетевых интерфейсов. При этом каждый хост может/должен содержать различное кол-во сетевых интерфейсов/бондов/бриджей. Покажете готовое решение?

показать ответы

alexq2

3 года назад

Где роли, где джинджа, где структура?

раскрыть ветку (1)

VladimirChursin

3 года назад

Если Вы не заметили, то концепция у репозитория не относится к каноничной.
Каждый раздел (см. скрин) - это приложение, которое можно смело использовать отдельно от репозитория.

+ Вот задачу с интерфейсами (о которой речь в публикации) как бы Вы решили, используя исключительно каноничный подход? Знаете примеры реализации?)