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.7K постов19.2K подписчиков

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

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

Вы смотрите срез комментариев. Показать все
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 придумали не просто так. Мой вам профессиональный совет: подучите ансибл, раз вы его тут используете, сотрите этого монстра и сделайте простой, понятный код. Не слушайте товарищей, которые тут предлагали писать и выкладывать коллекции - это такие же заморочки как у вас на шелле, только в стороне ансибла- не надо оно вам. Несколько простых ролей, внятные переменные в инвентори и у вас будет надёжная, функциональная, а главное- простая и понятная система. Задача- то у вас очень простая. А вы как техномант-алхимик, взяли шелл-заповеди древних предков, добавили туда новых игрушек и изобрели убер вундер вафлю, которая вам кажется простой и понятной. Но это не так.
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества