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

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

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

1
Автор поста оценил этот комментарий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0
Автор поста оценил этот комментарий
Готовое решение это хост варс и джинджа. То что вы делаете это какой-то трэш.
раскрыть ветку (1)
Автор поста оценил этот комментарий

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

Иллюстрация к комментарию
0
Автор поста оценил этот комментарий

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

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

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

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

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

показать ответы
3
DELETED
Автор поста оценил этот комментарий

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

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

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

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

показать ответы
2
Автор поста оценил этот комментарий
Где роли, где джинджа, где структура?
раскрыть ветку (1)
Автор поста оценил этот комментарий

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

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

Иллюстрация к комментарию
показать ответы
5
Автор поста оценил этот комментарий
Какой трэш я увидел. Мне интересно посмотреть на результат работы тех людей что ставили плюсы.
раскрыть ветку (1)
Автор поста оценил этот комментарий

"Какой трэш" - это слишком абстрактно. Есть конкретика?

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

Темы

Политика

Теги

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

Сообщества

18+

Теги

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

Сообщества

Игры

Теги

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

Сообщества

Юмор

Теги

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

Сообщества

Отношения

Теги

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

Сообщества

Здоровье

Теги

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

Сообщества

Путешествия

Теги

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

Сообщества

Спорт

Теги

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

Сообщества

Хобби

Теги

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

Сообщества

Сервис

Теги

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

Сообщества

Природа

Теги

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

Сообщества

Бизнес

Теги

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

Сообщества

Транспорт

Теги

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

Сообщества

Общение

Теги

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

Сообщества

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

Теги

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

Сообщества

Наука

Теги

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

Сообщества

IT

Теги

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

Сообщества

Животные

Теги

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

Сообщества

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

Теги

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

Сообщества

Экономика

Теги

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

Сообщества

Кулинария

Теги

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

Сообщества

История

Теги

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

Сообщества