Комментарии 13
Ansible, Perl, Bash - почему нельзя сделать на чем-то одном? У вас уже есть ansible, который может и конфиги рендерить как угодно и дергать systemd. Дальше при таком подходе обычно появляются матрешки типа "bash запускает ansible, который рендерит bash, который дергает systemd". А потом приходит новый сотрудник и хватается за голову в попытке понять, что там происходит.
Ой, матрешка уже есть...
print DYN_YML "- name: copy script 'rollback_ifcfg_changes.sh' to remote\n";
print DYN_YML " ansible.builtin.copy:\n";
print DYN_YML " src: \"{{playbook_dir}}/../scripts_for_remote/rollback_ifcfg_changes.sh\"\n";
print DYN_YML " dest: \"~/rollback_ifcfg_changes.sh\"\n";
print DYN_YML " mode: '0700'\n";
print DYN_YML "\n";
print DYN_YML "######################################################\n";
print DYN_YML "\n";
Продемонстрируйте, пожалуйста, как с помощью одного ansible можно прописать уникальную конфигурацию сети для N элементов.
Вариантов много. Можно конфиги зашаблонизировать и включать отдельные блоки через if. Можно в конфиги макросы положить для генерации этих блоков по подставленным параметрам. Можно просто папки в templates наделать по отдельным хостам или группам хостов. Можно netplan воткнуть и весь конфиг описывать в ямле, ямлы складировать по хостам, внутри шаблоны опять же блоками через макросы сделать. Настройки положить в host/group_vars. Можно тем же способом systemd конфиги раскладывать:
- name: Copy netplan config
template:
src: "roles/netplan/templates/etc/netplan/95-{{ inventory_hostname }}.yaml"
dest: "/etc/netplan/95-{{ inventory_hostname }}.yaml"
1) Netplan - это не про RHEL, а про Ubuntu.
2) А вот так, чтоб через один конфиг проводить настройки, есть варианты на чистом ansible?
Я не про конкретный ansible, netplan. У меня посыл в том, что поддерживать 4 сущности в едином инструменте - перебор. Если вы взялись за perl, у вас в нем есть экспертиза, там приличный кусок кода написан и он, наверное, полезен, зачем вам там еще bash и тем более зачем из перлового скрипта генерить yaml таски для ansible, которые будут запускаться питоном? Чтобы дополнительно еще отлаживать проблемы миграции между версиями ansible и еще версиями питона на разных машинах?
Как один из вариантов на ansible (ну примесь шелла будет наверное) для хранения настроек можно взять yaml по типу конфига netplan или cloud-init. Они практически стандартные и в случае чего можно будет прямо напрямую в некоторые системы подсовывать. А для тех, где нетплана нет, сделать рендерер на ansible (собственно, чем netplan и занимается для бэкендов). Можно в один файл положить, можно разложить по отдельному файлу на хост.
host:
ethernets:
eth1:
dhcp4: no
eth2:
dhcp4: no
bonds:
bond0:
interfaces: [ eth1,eth2 ]
parameters:
mode: 802.3ad
lacp-rate: fast
mii-monitor-interval: 100
vlans:
vlan10:
id: 10
link: bond0
bridges:
br10:
interfaces: [ vlan10 ]
addresses: [ "1.2.3.4/24" ]
routes:
- to: a.b.c.d
via: "{{ common_gw_variable }}" а ее положить в group_vars/all
в ansible раскладывать конфиги так
- template: src=ifcfg-bond-template dest=ifcfg-bond-{{ item }}
with_items: тут bonds/bridges/ethernets
или в jinja шаблонах через for по листу или дикту
для манипуляций с текущими интерфейсами и адресами есть факты хоста
со всякими переменными типа ansible_eth0.ipv4.address
и фильтры типа |ipaddr()А можно вообще поставить netbox и использовать его как источник данных, хоть для ansible, хоть для perl
бэкап-возврат конфигурации можно делать по-разному, зависит от системы и желаний. Один из вариантов - переименовывать на хосте папку с конфигами целиком, класть новые конфиги, типовой скрипт по крону регулярно проверяет, не появилась ли метка на хосте (ее кладем в конце плейбука где-нибудь после проверки доступности сети), если не появилась - переименовываем обратно. Можно через симлинки придумать систему. Главное чтобы скрипт был максимально одинаковый и простой.
Ну а если у вас все равно есть рендеринг в perl, то уж копирование файлов на нем без ansible сделать проблем не должно составить. Ansible большой, тяжелый и имхо если не использовать его возможности вроде переменных, шаблонов, макросов, фильтров, то лучше вообще на него не завязываться.
А также реализовать откат конфигурации по таймауту.
Неприятный баг, созданный собственноручно (увы, недосмотрел), обнаружил сегодня (2023-02-19 21:33).
Как оказалось, в код ansible-хелпера "conf_int_ipv4_via_network_scripts" закралась ошибочка, не позволявшая корректно настраивать сетевые интерфейсы (или их сочетание), связанные с VLAN-ами.
Ошибка устранена.
Имя ansible-хелпера сменилось на "conf_ipv4_via_network_scripts_v1".
===
https://github.com/vladimir-chursin000/ansible_helpers/tree/main/conf_ipv4_via_network_scripts_v1
Разворачиваем сеть на RHEL8-based хостах