我相信以下解决方案应适合您的情况。我在具有中央备份服务器和多个备份客户端的类似情况下一直使用它。
我有一个角色(让我们说“ db_replication_master ”)与接收连接的服务器相关联:
- role: db_replication_master
db_slaves: ['someserver', 'someotherserver']
db_slave_user: 'someuser' # in case you have different users
db_master_user: 'someotheruser'
extra_pubkeys: ['files/id_rsa.pub'] # other keys that need access to master
然后,我们在db_replication_master角色中创建实际任务:
- name: create remote accounts ssh keys
user:
name: "{{ db_slave_user }}"
generate_ssh_key: yes
delegate_to: "{{ item }}"
with_items: db_slaves
- name: fetch pubkeys from remote users
fetch:
dest: "tmp/db_replication_role/{{ item }}.pub"
src: "~{{db_slave_user}}/.ssh/id_rsa.pub"
flat: yes
delegate_to: "{{ item }}"
with_items: db_slaves
register: remote_pubkeys
changed_when: false # we remove them in "remove temp local pubkey copies" below
- name: add pubkeys to master server
authorized_key:
user: "{{ db_master_user }}"
key: "{{ lookup('file', item) }}"
with_flattened:
- extra_pubkeys
- "{{ remote_pubkeys.results | default({}) | map(attribute='dest') | list }}"
- name: remove temp local pubkey copies
local_action: file dest="tmp/db_replication_role" state=absent
changed_when: false
所以我们基本上是:
- 在仍然没有它们的奴隶上动态创建ssh-key
- 然后我们使用委托 _在从属服务器上运行fetch模块,并将其ssh pubkey提取到运行ansible的主机,还将此操作的结果保存在变量中,以便我们可以访问提取文件的实际列表
- 之后,我们通常使用authorized_keys模块将获取的ssh pubkey(以及提供的任何其他附加的pubkey)正常推送到主节点(我们使用几个jinja2过滤器从上述任务中的变量中找出文件路径)
- 最后,我们删除在运行ansible的主机上本地缓存的pubkey文件
在所有主机上拥有相同用户的限制可能可以解决,但是从您的问题中得到的信息来看,这可能对您来说不是问题(这与我的备份方案更为相关)。您当然也可以使密钥类型(rsa,dsa,ecdsa等)可配置。
更新:糟糕,我最初使用的是针对我的问题的术语,而不是您的问题!现在应该更有意义。