Да в Ansible один глобальный namespace в рамках одного хоста. Но ничего не мешает вам разделять одно пространство на множетсво — префиксами. Первый префикс — это имя вашего namespace. Удобнее всего, чтобы это было имя роли. Лично я даже создаю два namespace в одой роли: rolename_vars и _rolename_vars по аналогии с приватными полями в питоне. У меня не будет 10 переменных server_ip, потому что сначала идет название namespace. И в любом языке программирования это работает в коде также ( класс.поле = роль_переменная ). За исключением того, что в них есть локальные переменные, а в Ansible их нет. Кроме программирования эта проблема встречается везде, где есть быстрорастущее пространство имен, и везде оно решается префиксом. ( Например адреса домов: улицы везде одинаковые, но префиксы городов решают ).
В итоге правила просты ( описаны в статье ):
— Не создавайте переменных «в глобальном» namespace.
— Используйте переменные только из своего namespace или dependency.
На самом деле в статье больше акцент на разбор мест где переменные в принципе могут определяться и храниться. И поскольку их много, каждое из них можно превратить в помойку переменных со всего деплоя довольно быстро, даже если сами роли просты.
Написание кода имеет схожие проблемы независимо от языка или инструмента. Если вы начинаете дублировать самого себя (а написание ролей под каждый проект, приводит к дублированию одинаковых мест стека), будет трудно найти ошибку и трудно внести изменения — поскольку вместо одной роли вам нужно перелопатить k (количество проектов в компании) ролей. Также нарушаются принципы унификации и стандартизации.
Поэтому, так важно все же добиться изоляции, чтобы зона влияния роли не выходила за свои рамки, из-за пересечения имен переменных. Ошибки же ловятся и исправляются на тех же этапах, что и в программировании: тестирование и проверка pr. А те, что вышли в свет, оперативно исправляются поскольку ошибка локализована в коде.
Если ansible не может сделать что-то красиво из коробки, нужно делать в виде python модуля с теми же принципами заложенными ansible.
В итоге правила просты ( описаны в статье ):
— Не создавайте переменных «в глобальном» namespace.
— Используйте переменные только из своего namespace или dependency.
На самом деле в статье больше акцент на разбор мест где переменные в принципе могут определяться и храниться. И поскольку их много, каждое из них можно превратить в помойку переменных со всего деплоя довольно быстро, даже если сами роли просты.
Поэтому, так важно все же добиться изоляции, чтобы зона влияния роли не выходила за свои рамки, из-за пересечения имен переменных. Ошибки же ловятся и исправляются на тех же этапах, что и в программировании: тестирование и проверка pr. А те, что вышли в свет, оперативно исправляются поскольку ошибка локализована в коде.
Если ansible не может сделать что-то красиво из коробки, нужно делать в виде python модуля с теми же принципами заложенными ansible.