я собираюсь еще json из hostvars["{{ inventory_hostname }}"] | to_json вставлять в clickhouse с их auto schema json и потом уже полноценным sql диалектом клика сравнивать что-где применено или не применено.
я пришел к тому, что у меня все переменные хранятся в host_vars в файликах с названиями ролей, но там есть еще префиксы - отдельно для хранения зашифрованных переменных, отдельно для переменных, которые нежелательно перезаписывать (postgresql.conf, pg_hba.conf, patroni.yml) и сделал сначала генерировалку таких конфигов из ansible template в jinja2, но во второй итерации сделал на bash через наивный cat eof + немного логики для hba. Каждый кластер это отдельный гит репо, инвентори в нем единственный и простой - hosts.ini с условно 2-3 пг, 3 етсд и еще дблаб, то есть даже две разные среды одного логического проекта - это два репозитория. Ну вот, генерировалка генерирует проект со всеми переменными, создает гит репо и в проекты, которые уже существуют тоже может сгенерировать переменные для новых проектов или поправить те файлы, которые можно редактировать. Просто делюсь "как я решал похожую проблему". Тож столкнулся с проблемой, что мои роли воспринимают как коробку, а теперь и эти вспомогательные баш скрипты тоже так же воспринимают(
Каким образом осуществляется поддержка старых проектов? Например, сделали роль, запилили переменных, inventory housekeeper теперь для новых выкаток безупречно генерирует новые переменные, а для старых проектов как? Нужно их сгенерировать и внедрить в проект, например, захотели pgbackrest поменять на wal-g, взлетело и теперь нужно раскатить везде и переменные по-хорошему должны быть там, где готовится вскоре раскатка, но не должны быть там, где это изменение еще нужно запланировать заранее, согласовать и внедрить, например, критичный проект.
Все еще числами. Я рекомендую использовать подход с key patterns вместо баз. Чем свежее версия редис, тем больше возможностей. Например, в 7 версии можно управлять доступами, например
For a concrete example, consider a user with ACL rules +@all ~app1:* (+@read ~app2:*). This user has full access on app1:* and readonly access on app2:*. (Из документации https://redis.io/docs/management/security/acl/)
я собираюсь еще json из hostvars["{{ inventory_hostname }}"] | to_json вставлять в clickhouse с их auto schema json и потом уже полноценным sql диалектом клика сравнивать что-где применено или не применено.
занятно)
я пришел к тому, что у меня все переменные хранятся в host_vars в файликах с названиями ролей, но там есть еще префиксы - отдельно для хранения зашифрованных переменных, отдельно для переменных, которые нежелательно перезаписывать (postgresql.conf, pg_hba.conf, patroni.yml) и сделал сначала генерировалку таких конфигов из ansible template в jinja2, но во второй итерации сделал на bash через наивный cat eof + немного логики для hba. Каждый кластер это отдельный гит репо, инвентори в нем единственный и простой - hosts.ini с условно 2-3 пг, 3 етсд и еще дблаб, то есть даже две разные среды одного логического проекта - это два репозитория. Ну вот, генерировалка генерирует проект со всеми переменными, создает гит репо и в проекты, которые уже существуют тоже может сгенерировать переменные для новых проектов или поправить те файлы, которые можно редактировать. Просто делюсь "как я решал похожую проблему". Тож столкнулся с проблемой, что мои роли воспринимают как коробку, а теперь и эти вспомогательные баш скрипты тоже так же воспринимают(
Каким образом осуществляется поддержка старых проектов? Например, сделали роль, запилили переменных, inventory housekeeper теперь для новых выкаток безупречно генерирует новые переменные, а для старых проектов как? Нужно их сгенерировать и внедрить в проект, например, захотели pgbackrest поменять на wal-g, взлетело и теперь нужно раскатить везде и переменные по-хорошему должны быть там, где готовится вскоре раскатка, но не должны быть там, где это изменение еще нужно запланировать заранее, согласовать и внедрить, например, критичный проект.
Все еще числами. Я рекомендую использовать подход с key patterns вместо баз. Чем свежее версия редис, тем больше возможностей. Например, в 7 версии можно управлять доступами, например
For a concrete example, consider a user with ACL rules
+@all ~app1:* (+@read ~app2:*). This user has full access onapp1:*and readonly access onapp2:*. (Из документации https://redis.io/docs/management/security/acl/)