내 상자 (방랑자)에 이상한 문제가 있습니다.

어제 모든 것이 효과가 있었고 내 플레이 북은 정상적으로 작동했습니다.

오늘, "사실 수집"에 대한 불안감이 있습니까?

자세한 출력은 다음과 같습니다.

<5.xxx.xxx.xxx> ESTABLISH CONNECTION FOR USER: deploy
<5.xxx.xxx.xxx> REMOTE_MODULE setup
<5.xxx.xxx.xxx> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-
o', 'ControlPersist=60s', '-o', 'ControlPath=/home/vagrant/.ansible/cp/ansible-s
sh-%h-%p-%r', '-o', 'Port=2221', '-o', 'KbdInteractiveAuthentication=no', '-o',
'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o
', 'PasswordAuthentication=no', '-o', 'User=deploy', '-o', 'ConnectTimeout=10',
'5.xxx.xxx.xxx', "/bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1411372677
.18-251130781588968 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1411372677.18-2
51130781588968 && echo $HOME/.ansible/tmp/ansible-tmp-1411372677.18-251130781588
968'"]

나는 Vagrant의 Ansible ping과 비슷한 문제를 겪었습니다. 아무 이유없이 갑자기 멈추었고 이전에는 절대적으로 잘 작동했습니다. ssh 또는 연결 문제와 같은 다른 문제와 달리 시간 초과없이 영원히 죽습니다.

이 문제를 해결하기 위해 한 가지 일은 ~/.ansible디렉토리 를 정리하는 것이며 다시 작동합니다. 이유를 알 수 없지만 해결되었습니다.

다시 변경하도록 변경 한 경우 ~/.ansibleVagrant를 새로 고치기 전에 폴더를 정리하십시오 .

나를 위해 설정 모듈 모듈이 죽은 NFS 마운트에 붙어있었습니다.

컴퓨터에서 "df"를 수행해도 아무 반응이 없으면 같은 상황 일 수 있습니다.

PS : NFS 공유 / 마운트 포인트를 마운트 해제 할 수없는 경우 잘못된 "umount -l"사용을 고려하십시오

일반적으로 연결 문제 또는 설정 모듈이 정지되어 여러 가지 이유로 Ansible이 이와 같이 중단 될 수 있습니다. 문제를 해결하여 해결할 수있는 방법은 다음과 같습니다.

Ansible이 대상 호스트에 연결할 수 없습니다

호스트 키 (known_hosts) 문제

1) 이전 버전의 Ansible (2.1 이상)에서 대상의 호스트 키가 소스에 존재하지 않는지 또는 일치하지 않는지 Ansible이 항상 알려주는 것은 아닙니다.

해결 방법 : 해당 대상과 동일한 매개 변수로 SSH 연결을 열어보십시오. 해결해야하는 SSH 오류를 발견하면 명령이 작동합니다.

2) 때때로 Ansible은 다른 상태에서 SSH 연결 메시지를 표시하여 Ansible이 해당 작업에서 "동결"되도록합니다.

Warning: the ECDSA host key for 'myhost' differs from the key for the IP address '10.10.1.10'
Offending key for IP in /etc/ssh/ssh_known_hosts:246
Matching host key in /etc/ssh/ssh_known_hosts:477
Are you sure you want to continue connecting (yes/no)?

이 경우 요청한 SSH 질문 수에 "yes"를 입력하면 게임을 계속할 수 있습니다. 그 후 루트 known_hosts 문제를 해결할 수 있습니다.

개인 키 인증 문제

키 기반 인증과 암호를 사용하는 경우 다른 문제는 다음과 같습니다.

• 대상에서 개인 키가 올바르게 설정되지 않았을 수 있습니다
• 개인 키에 로컬로 잘못된 권한이있을 수 있습니다 (Ansible 작업을 실행하는 사용자 만 읽을 수 있어야 함)

해결 방법 : ansible -m ping <destination> -k문제가있는 호스트에 대해 실행 해보십시오. 그래도 작동하지 않으면 위 의 호스트 키 문제 해결 방법을 시도하십시오 .

Ansible은 사실을 빨리 모을 수 없습니다

setup(AN의 시작 부분에 자동으로 실행 모듈을 ansible-playbook실행하거나 수동으로 실행하는 경우는 ansible -m setup <host>하드웨어 사실을 수집 할 때) 자주 중단 될 수 있습니다 (예를 들어, 높은 I / O, 나쁜 마운트 항목 등이있는 호스트에서 디스크 정보를 가져 오는 경우).

해결 방법 : 실행 해보십시오 ansible -m setup -a gather_subset=!all <destination>. 이것이 작동하면 ansible.cfg에서이 줄을 설정하는 것을 고려해야합니다.

gather_subset=!hardware

Gathering Facts에 Ansible 교수형과 비슷한 문제가있었습니다. 나는 작업이나 역할이없는 프롬프트로 스크립트를 파싱했지만 여전히 중단되었습니다.

프로세스 목록에서 하루 동안 누적 된 12 개의 중단 된 프로세스를 발견했습니다.

/usr/bin/python /tmp/ansible_Jfv4PA/ansible_module_setup.py
/usr/bin/python /tmp/ansible_M2T10L/ansible_module_setup.py

일단 내가 그들을 죽이면 다시 작동하기 시작했습니다.

ansible이 사실 수집에 매달릴 수있는 데는 여러 가지 이유가 있지만, 더 나아 가기 전에 이러한 상황에서해야 할 첫 번째 테스트는 다음과 같습니다.

ansible -m ping <hostname>

이 테스트는 호스트에 연결하고 리턴하기에 충분한 코드를 실행합니다.

<hostname> | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

이것이 작동하면 원격 호스트 파이썬 인터프리터로 대상 호스트 이름을 확인하고, 연결을 열고, 인증하고, 사용 가능한 모듈을 실행할 수 있음을 입증하므로 설정 또는 연결 문제를 거의 배제 할 수 있습니다.

이제, 다음은 플레이 북의 시작 부분에서 잘못 될 수있는 것들의 목록입니다.

ansible이 실행 한 명령이 대화식 입력을 기다리는 중입니다.

명령이 sudo 암호 ( -K스위치 를 잊었을 때)와 같은 대화식 입력을 기다리 거나 새로운 ssh 호스트 지문 수락 (새로운 대상의 경우)과 같은 이전의 사용 가능한 버전에서 발생하는 것을 기억할 수 있습니다. 숙주).

최신 버전의 ansible은 이러한 경우를 정상적으로 처리하고 일반적인 유스 케이스에서 즉시 오류를 발생시킵니다. 따라서 ssh 또는 sudo 호출과 같은 작업을 수행하지 않는 한 이러한 종류의 문제가 없어야합니다. 그리고 당신이하더라도 사실 수집 후에 일 것입니다.

죽은 ssh 마스터 연결

여기에 주어진 디버그 로그에 ssh 클라이언트에 전달되는 매우 흥미로운 옵션이 있습니다.

• ControlMaster=auto
• ControlPersist=60s
• ControlPath=/home/vagrant/.ansible/cp/ansible-ssh-%h-%p-%r

이 옵션은 man ssh_config에 설명되어 있습니다 .

기본적으로 ansible은 ssh 연결 사용과 관련하여 현명하고 노력합니다. 주어진 호스트에 대해, 플레이의 각각의 모든 작업에 대해 새로운 연결을 생성하는 대신, 한 번 열어서 전체 플레이 북 (및 플레이 북 전체)에 대해 열린 상태로 유지합니다.

새로운 연결을 설정하는 것이 기존 연결을 사용하는 것보다 훨씬 느리고 계산 집약적이기 때문에 좋습니다.

실제로 모든 ssh 연결은에서 소켓이 있는지 확인합니다 ~/.ansible/cp/some-host-specific-path. 첫 번째 연결은 찾을 수 없으므로 정상적으로 연결되어 만들어집니다. 이후의 모든 연결은이 소켓을 사용하여 이미 설정된 연결을 통과합니다.

설정된 연결이 오랫동안 사용되지 않으면 결국 시간 초과되어 닫히더라도 소켓도 닫히고 다시 정사각형으로 돌아갑니다.

여태까지는 그런대로 잘됐다.

그러나 때때로 연결이 실제로 끊어 지지만 ssh 클라이언트는 여전히 연결이 설정된 것으로 간주합니다. 일반적으로 랩톱에서 플레이 북을 실행할 때 WiFi 연결이 끊어집니다 (또는 WiFi에서 이더넷으로 전환하는 등).

이 마지막 예는 끔찍한 상황입니다. 기본 ssh 구성으로 대상 시스템에 ssh를 수행 할 수 있지만 이전 연결이 여전히 활성 상태 인 것으로 간주되는 경우 새로운 연결을 설정하려고 시도조차하지 않습니다.

이 시점에서, 우리는이 오래된 소켓을 제거하고 싶습니다. 가장 간단한 방법은 소켓을 제거하는 것입니다.

# Delete all the current sockets (may disrupt currently running playbooks)
rm -r ~/.ansible/cp
# Delete only the affected socket (requires to know which one it is)
rm ~/.ansible/cp/<replace-by-your-socket>

이 기능은 원샷 수정에 적합하지만 너무 자주 발생하면 장기 수정을 찾아야 할 수도 있습니다. 이 목표를 달성하는 데 도움이 될만한 몇 가지 조언은 다음과 같습니다.

• 서버에서 플레이 북 시작 (노트북보다 안정적인 네트워크 연결 방식)
• 사용 가능한 구성을 사용 하거나 직접 ssh 클라이언트 구성 을 사용하여 연결 공유를 사용하지 않도록 설정
• 동일한 리소스를 사용하지만 시간 초과를 미세 조정하여 마스터 연결 충돌이 실제로 더 빨리 시간 초과되도록

글을 쓰는 시점에서 몇 가지 옵션이 변경 ControlPath=/home/toadjaune/.ansible/cp/871b533295되었지만 (예를 들어, 최근 실행으로 나에게 주었다 ) 일반적인 아이디어는 여전히 유효합니다.

사실 시간이 너무 많이 걸리는 사실 수집

모든 플레이가 시작될 때 ansible은 대상 시스템에 대한 많은 정보를 수집하여 Facts에 넣습니다 . 이것들은 플레이 북에서 사용할 수있는 변수이며 일반적으로 매우 편리하지만 때로는이 정보를 얻는 데 시간이 오래 걸릴 수 있습니다 (잘못된 마운트 포인트, 높은 입출력이있는 디스크, 높은로드…)

이것은 당신이하지 않는 말했다되고 엄격하게 각본을 실행하는 사실을해야하고, 거의 확실히 그들 모두, 그래서 우리는 필요하지 않습니다 무엇의 시도하자 비활성화합니다. 그에 대한 몇 가지 옵션 :

• 설정 모듈을 완전히 비활성화
• 특정 부분 만 포함 하도록 설정 모듈 의 구성을 변경하십시오 .
  • 명령 줄 인수를 통해
  • 구성 가능한 구성 파일을 통해

디버깅 목적으로 명령 줄에서 직접 설정 모듈을 호출하는 것이 매우 편리합니다.

ansible -m setup <hostname>

이 마지막 명령은 플레이 북과 함께 중단되고 결국 시간 초과 (또는 성공)해야합니다. 이제 모듈을 다시 실행하여 가능한 모든 기능을 비활성화하겠습니다.

ansible -m setup -a gather_subset='!all' <hostname>

그래도 문제가 해결되지 않으면 항상 게임에서 모듈을 완전히 사용 중지 할 수 있지만 문제가 다른 곳에있을 가능성이 큽니다.

그러나 제대로 작동하면 모듈 설명서를 살펴보십시오 . 두 가지 옵션이 있습니다.

• 필요하지 않은 것을 제외하고 팩트 수집을 서브 세트로 제한하십시오 (의 가능한 값 참조 gather_subset).
• gather_timeout 더 많은 시간을 허용하여 문제를 해결하는 데 도움을 줄 수도 있습니다 (정지 시간이 아닌 오류를 수정하는 것이지만)

다른 문제

분명히 다른 일이 잘못 될 수 있습니다. 디버깅에 도움이되는 몇 가지 지침 :

• -vvvv실행 가능한 모든 명령이 표시 되므로 최대 상세 레벨 ( )을 사용하십시오.
• 위에서 설명한대로 명령 줄에서 직접 사용 ping및 setup모듈
• ansible -m ping작동하지 않으면 수동으로 ssh를 시도하십시오

Dmytro가 뭔가에 있습니다!

Ansible은 호스트의 FQDN을 사용합니다. 호스트를 DNS로 해석 할 수없고 매핑이없는 경우 /etc/hostsDNS가 시간 초과 될 때까지 기다립니다.

::1 <fqdn>연결중인 컴퓨터의 호스트 파일을 추가 하면 Ansible은 DNS를 거치지 않고 즉시 FQDN을 얻습니다.

호스트는에서 호스트를 조회해야합니다 /etc/hosts. 이것이 전부는 아니지만 대부분의 Linux 시스템의 기본값이지만 편집 /etc/nsswitch.conf은 문제가 될 수 있습니다.

나는 같은 문제가 있었다. 상세 모드에서 실행 가능한 유용한 정보가 없습니다.

플레이 북을 실행하기 전에 서버를 다시 구축했습니다.

알려진 호스트 목록에서 서버를 제거하면 아래 명령을 사용하여이 문제를 해결했습니다.

$ ssh-keygen -f "~/.ssh/known_hosts" -R <hostname>
$ ssh-keygen -f "~/.ssh/known_hosts" -R <ip_address>

참고 : 호스트 이름과 IP 주소를 모두 제거해야합니다.

나는 당신이 sudo 플레이 북을 사용하고 있는지 모르겠다. 그러나 나는 있었고 sudo 암호에 매달려 있었다.

문서에서-당신은 그것을 죽인 다음 사용할 수도 -K있습니다.

행운을 빕니다.

서버 OS를 다시 설치할 때와 같이 대상 시스템의 지문이 변경되었을 수 있습니다. known_hosts 에서 항목을 삭제해야합니다. 신뢰할 수없는 항목이 문제임을 알리지 않고 설명대로 정확하게 멈 춥니 다 .

ansible을 인증 할 수 없다고 들립니다. 따라서 -k를 사용하여 아래와 같이 서버 암호를 묻습니다.

ansible-playbook  -K -i hosts playbook.yml -vvvv

FQDN과 호스트 이름이 일치하지 않으면 행 아웃이 발생할 수 있습니다. 도메인이 호스트 이름 도메인과 다른 FQDN을 사용했습니다. 둘 다 동일하게 한 후 , ansible은 완벽하게 작동합니다. 원격 호스트에서 작업을 실행하기 전에 FQDN과 호스트 이름을 비교할 수 있습니다. 그것이 도움이되기를 바랍니다!

방랑 상자를 재설정 하여이 문제를 해결했습니다.

vagrant destroy
vagrant up

내 경우에는 작업 중간에 ansible의 작동이 중지되었습니다. 그 이유는 내 ssh-agent가 작동을 멈 췄기 때문입니다 ( ssh-add -l아무것도 반환하지 않았습니다). 나는 모든 것을 다시 시작했고 다시 작동했다. 따라서 ssh-agent가 올바르게 작동하는지 확인하십시오 (정지 ssh-add -l되지 않아야 함).

~/.ansible혼자 삭제 하는 것이 나를 위해하지 않았습니다. 그래서 그 디렉토리에 무엇이 있는지 확인하기 위해 방금 ctrl-z (프로세스를 휴면 상태로 전환)하고 확인한 다음을 통해 ansible 프로세스를 계속했습니다 fg. 이 경우 아무 것도 삭제하지 않았습니다. 그러나 방금 계속 된 후에. 그래서 나는 ctrl-z-> 만 시도했지만 fg효과가있었습니다. 비춤 같은 느낌이 들지만 다른 사람이 갇힌 경우에도 시도하십시오.

내 플레이 북이 "사실 수집"에 매달려있는 이유 의 조언에 따라이 문제의 원인을 해결했습니다 . 블로그 포스트.

다음과 같이 단순화 할 수 있습니다.

1. 설정 DEFAULT_KEEP_REMOTE_FILES=yes명령을 보존하고 활성화하려면-vvvv

2. 플레이 북을 다시 실행하십시오.

3. 재생이 멈 추면 마지막으로 인쇄 된 쉘 명령 (다음 부분 /bin/sh -c)을 복사하십시오.

4. 를 통해 서버에 로그온하십시오 ssh.

5. strace마지막 단계를 재생하는 데 사용 합니다. 단계 명령이 -vvv출력 에서 복사됩니다 . 예를 들면 다음과 같습니다.strace -f /bin/sh -c "echo BECOME-SUCCESS-ltxvshvezrnmumzdprccoiekhjheuwxt; /usr/bin/python /home/user/.ansible/tmp/ansible-tmp-1527099315.31-224479822965785/setup.py"

6. "추적 된"단계가 걸려온 호출을 확인하고 수정하십시오.

제 경우에는 액세스 할 수없는 네트워크 드라이브였습니다 ...

Sudo의 비밀번호가 문제입니다. 꼭두각시가 이전의 수동 '소도 자'변경 사항을 취소하지 않은 것을 제공하지 않고 (1) 새로 열린 터미널에서 (비밀번호가 캐시되지 않은) 'sudo anything '을 발행 할 수 있는지 확인하십시오 .