Я использую Ansible с большим успехом уже около 3 лет для управления постоянно растущей группой Linux-систем. Прежде чем углубиться в свой вопрос, мне нужно задать некоторый контекст.
В рамках своей повседневной работы я занимаюсь проектированием, развертыванием и обслуживанием систем для различных компаний, которые работают под эгидой одного предприятия / инкубатора. Среди наших портфельных компаний наблюдается много перекрестного опыления, и поэтому мы не можем сказать, что только пользователям A, B и C потребуется доступ к системам компании X. Им также может потребоваться доступ к системам компании Y. Это осложняется тем фактом, что доступная среда каждой компании находится в разных репозиториях git. Это означает, что есть много дублирования кода для развертывания пользователей в различных системах компании. В итоге я копирую / вставляю такие блоки кода, чтобы развернуть пользователей в системах определенной компании:
- name: add several users
user: >
name={{ item.name }}
state=present
groups={{ item.groups }}
uid={{ item.uid }}
password={{ item.password }}
shell=/bin/bash
with_items:
- { name: 'user1', groups: 'ssh-access,sudo', uid: '501', password: '<redacted>' }
- { name: 'user2', groups: 'ssh-access,sudo', uid: '502', password: '<redacted>' }
tags: users
- name: authorized_keys - user1
action: authorized_key user=user1 key="{{ lookup('file', 'pubkeys/user1') }}" manage_dir=yes
tags:
- pubkeys
- users
- name: authorized_keys - user2
action: authorized_key user=user2 key="{{ lookup('file', 'pubkeys/user2') }}" manage_dir=yes
tags:
- pubkeys
- users
Это работало нормально, когда у меня было <5 пользователей для управления, но по мере роста пользовательской базы становится все более и более обременительным поддерживать актуальность с помощью ротации ключей, новых паролей и т.
С заданной предысторией и контекстом перейдем к моему вопросу:
Предполагая, что использование централизованной системы аутентификации (LDAP и т. Д.) Не является вариантом, как я мог бы заняться созданием централизованной базы данных пользователей, которую могли бы использовать различные доступные playbooks? Я хотел бы иметь возможность поддерживать единый центральный список пользователей, идентификаторов, хэшей паролей и открытых ключей, а затем иметь возможность развертывать пользователей (с индивидуальным членством в группах для каждого хоста) на хостах каждой компании.
Я представляю себе какую-то игровую структуру вроде:
- name: Deploy users
user_management:
- { name: "user1", groups: "sudo" }
- { name: "user1", groups: "sudo" }
... где uid, хэш и открытый ключ каждого пользователя будут извлечены из центрального списка и развернуты как обычно.
Итак, какие у меня есть варианты? Я долго обдумывал это и не смог придумать ничего лучше, чем то, что я уже делаю. Могу ли я что-нибудь сделать с пользовательским файлом фактов для хранения моей пользовательской базы данных?
Вам нужно разделить свои пьесы и свои данные.
У меня есть единое хранилище со всеми моими ролями, фактами и т. Д., Которое развертывается в широком диапазоне клиентских систем. Я гарантирую, что все роли могут быть восстановлены и не содержат данных. В host_vars/fqdn.yml или group_vars/customer_name.yml Я определяю данные, уникальные для этого клиента или удаленной системы.
Большинство моих ролей со временем расширяются по мере необходимости, и вместо того, чтобы делать все from roles/foo/main.yml у меня есть roles/foo/debian-foo.yml и roles/foo/openbsd-foo.yml которые включаются только при совпадении ОС или другого условия.
Упрощенный, roles/adduser/main.yml может включать это:
- user: name={{ item.name }} ...
with_items:
- customer_users
и group_vars/ACME.yml может включать это:
customer_users:
- name: sausage
uid: 32153
- name: beans
uid: 1024
В вашем случае может быть нормально иметь отдельные доступные среды в каждом их репозитории git, если папка ролей является общим подмодулем, идентичным для всех ваших клиентов.