26

Ansible. Network-scripts. RHEL8

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. Надеюсь, кому-то результат моих изысканий поможет сэкономить время.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

раскрыть ветку (3)
1
Автор поста оценил этот комментарий

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

Иллюстрация к комментарию
раскрыть ветку (2)
0
Автор поста оценил этот комментарий

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

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

Иллюстрация к комментарию
раскрыть ветку (1)
0
Автор поста оценил этот комментарий
1.Бекапы не нужны- вы генерируете конфиги на основе настроек, которые храните в ансибле. Если внесли неправильные настройки- откатите изменения и сгенерируйте предыдущий конфиг.
2. не нужно генерировать конфиг скриптом- есть встроенный шаблонизатор. Вы итак это максимально усложнили процесс и разбили на миллион файлов один шаблон.
3. не надо "генерировать yaml, с указанием что надо переконфигурировать интерфейсы". Зачем? Для этого давно придумали хэндлеры. Если мало- ну регистрируйте выход генерации конфига и добавьте новые шаги с условием when: config.changed

В погрязли в шелл скриптинге. Лет 10-15 назад это еще было бы актуально. Тогда я встречал и похлещще мешанину. Но сейчас давно уже изобрели гораздо более удобные инструменты и практики. Вы узнали про ансибл и решили интегрировать в вашего киборга новую, блестящую детальку, но функциональнее и красивее он от этого не стал. Best practice придумали не просто так. Мой вам профессиональный совет: подучите ансибл, раз вы его тут используете, сотрите этого монстра и сделайте простой, понятный код. Не слушайте товарищей, которые тут предлагали писать и выкладывать коллекции - это такие же заморочки как у вас на шелле, только в стороне ансибла- не надо оно вам. Несколько простых ролей, внятные переменные в инвентори и у вас будет надёжная, функциональная, а главное- простая и понятная система. Задача- то у вас очень простая. А вы как техномант-алхимик, взяли шелл-заповеди древних предков, добавили туда новых игрушек и изобрели убер вундер вафлю, которая вам кажется простой и понятной. Но это не так.
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку