귀하의 경우 다음 해결책이 효과가 있다고 생각합니다. 중앙 백업 서버 및 여러 백업 클라이언트와 비슷한 시나리오에 사용했습니다.
연결을 수신하는 서버와 연관된 역할 (예 : " 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 키를 동적으로 생성
- 그런 다음 delegate_to 를 사용 하여 슬레이브 에서 페치 모듈 을 실행 하고 ssh pubkey를 ansible을 실행하는 호스트로 페치 하고이 작업의 결과를 변수에 저장하여 가져온 파일의 실제 목록에 액세스 할 수 있습니다
- 그 후 우리는 일반적으로 fetched ssh pubkeys (제공된 추가 pubkeys)를 authorized_keys 모듈을 사용 하여 마스터 노드에 푸시합니다 (위의 작업에서 변수에서 파일 경로를 파기 위해 두 개의 jinja2 필터를 사용합니다)
- 마지막으로 ansible을 실행하는 호스트에 로컬로 캐시 된 pubkey 파일을 제거합니다
모든 호스트에서 동일한 사용자를 갖는 제한은 해결 될 수 있지만 귀하의 질문에서 얻은 결과는 아마도 당신에게 문제가되지 않을 것입니다 (백업 시나리오와 매우 관련이 있습니다). 물론 키 유형 (rsa, dsa, ecdsa 등)을 구성 할 수도 있습니다.
업데이트 : 죄송합니다. 원래의 문제가 아닌 내 문제와 관련된 용어를 사용하여 작성했습니다 ! 이제 더 이해가 되겠습니다.