ฉันมีปัญหาแปลก ๆ กับกล่อง ansible ของฉัน (คนพเนจร)

ทุกอย่างทำงานได้เมื่อวานและ playbook ของฉันทำงานได้ดี

ทุกวันนี้ ansible แฮงค์ที่ "รวบรวมข้อเท็จจริง"?

นี่คือผลลัพธ์ verbose:

<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'"]

ฉันมีปัญหาที่คล้ายกันกับ Ansible ping ใน Vagrant มันก็ติดอยู่โดยไม่มีเหตุผลและก่อนหน้านี้ทำงานได้ดีอย่างแน่นอน แตกต่างจากปัญหาอื่น ๆ เช่น ssh หรือปัญหาเกี่ยวกับการเชื่อมต่อมันเพียงแค่ตายตลอดกาลโดยไม่มีการหมดเวลา

สิ่งหนึ่งที่ฉันทำเพื่อแก้ไขปัญหานี้คือการล้าง~/.ansibleไดเรกทอรีและใช้งานได้อีกครั้ง ฉันหาสาเหตุไม่ได้ แต่มันก็ได้รับการแก้ไข

หากคุณได้รับการเปลี่ยนให้ลองทำความสะอาด~/.ansibleโฟลเดอร์ก่อนที่จะรีเฟรช Vagrant ของคุณ

สำหรับฉันโมดูลติดตั้งโมดูลติดอยู่บนเมาท์ 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 ให้มากที่สุดเท่าที่คุณถามจะอนุญาตให้เล่นต่อไป หลังจากนั้นคุณสามารถแก้ไขปัญหารูท known_hosts

ปัญหาการตรวจสอบคีย์ส่วนตัว

หากใช้การพิสูจน์ตัวตนแบบใช้คีย์กับรหัสผ่านปัญหาอื่น ๆ ได้แก่ :

• อาจตั้งค่ารหัสส่วนตัวไม่ถูกต้องในปลายทาง
• ไพรเวตคีย์อาจมีสิทธิ์ที่ไม่ถูกต้องภายในเครื่อง (ควรอ่านได้โดยผู้ใช้ที่รันงาน Ansible เท่านั้น)

วิธีแก้ปัญหา: ลองเรียกใช้ansible -m ping <destination> -kกับโฮสต์ปัญหา - หากยังใช้งานไม่ได้ให้ลองแก้ปัญหาปัญหาคีย์โฮสต์ด้านบน

Ansible ไม่สามารถรวบรวมข้อเท็จจริงได้อย่างรวดเร็ว

setupโมดูล (เมื่อทำงานโดยอัตโนมัติที่จุดเริ่มต้นของนั้นansible-playbookวิ่งหรือเมื่อทำงานด้วยตนเองเป็นansible -m setup <host>) มักจะวางเมื่อรวบรวมข้อเท็จจริงฮาร์ดแวร์ (เช่นถ้าได้รับข้อมูลจากดิสก์เจ้าภาพกับฉันสูง / o ติดรายการไม่ดี ฯลฯ )

การแก้ไข: ansible -m setup -a gather_subset=!all <destination>ลองใช้ หากใช้งานได้คุณควรพิจารณาตั้งค่าบรรทัดนี้ใน ansible.cfg ของคุณ:

gather_subset=!hardware

ฉันมีปัญหาคล้ายกันกับ 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 ด้วยตัวแปลภาษาไพ ธ อนระยะไกล

ตอนนี้ต่อไปนี้เป็นรายการ (ไม่ครบถ้วนสมบูรณ์) ของสิ่งต่าง ๆ ที่ผิดพลาดได้ตั้งแต่เริ่มต้นของ playbook:

คำสั่งที่ดำเนินการโดย ansible กำลังรออินพุตแบบโต้ตอบ

ฉันจำได้ว่าสิ่งนี้เกิดขึ้นกับรุ่นที่เก่ากว่าซึ่งคำสั่งจะรออินพุตอินเทอร์แอคทีฟที่จะไม่เกิดขึ้นเช่นรหัสผ่าน sudo (เมื่อคุณลืม-Kสวิตช์) หรือยอมรับลายนิ้วมือโฮสต์ ssh ใหม่ (สำหรับเป้าหมายใหม่ เป็นเจ้าภาพ)

จัดการกับ ansible รุ่นที่ทันสมัยทั้งสองกรณีเหล่านี้อย่างสง่างามและเพิ่มข้อผิดพลาดทันทีสำหรับการใช้งานปกติดังนั้นถ้าคุณไม่ทำสิ่งต่าง ๆ เช่นการโทร ssh หรือ sudo ด้วยตัวคุณเองคุณไม่ควรมีปัญหาแบบนี้ และแม้ว่าคุณจะทำมันก็จะเป็นหลังจากการรวบรวมความจริง

การเชื่อมต่อหลัก ssh ที่ตายแล้ว

มีตัวเลือกที่น่าสนใจบางอย่างที่ส่งผ่านไปยังไคลเอ็นต์ ssh ในบันทึกการแก้ปัญหาที่ให้ไว้ที่นี่:

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

ตัวเลือกเหล่านี้จะถูกบันทึกไว้ในคน ssh_config

โดยค่าเริ่มต้น ansible จะพยายามฉลาดในการใช้การเชื่อมต่อ ssh สำหรับโฮสต์ที่กำหนดแทนที่จะสร้างการเชื่อมต่อใหม่สำหรับแต่ละภารกิจในการเล่นมันจะเปิดขึ้นหนึ่งครั้งและเปิดให้เล่นตลอดทั้ง playbook (และแม้กระทั่งใน playbooks)

ดีมากเนื่องจากการสร้างการเชื่อมต่อใหม่นั้นช้ากว่ามากและใช้การคำนวณมากกว่าการใช้การเชื่อมต่อที่มีอยู่แล้ว

ในทางปฏิบัติทุกการเชื่อมต่อ SSH ~/.ansible/cp/some-host-specific-pathจะตรวจสอบสำหรับการดำรงอยู่ของซ็อกเก็ตที่ การเชื่อมต่อครั้งแรกไม่สามารถค้นหาได้ดังนั้นจึงสามารถเชื่อมต่อได้ตามปกติแล้วสร้างขึ้น ทุกการเชื่อมต่อที่ตามมาจะใช้ซ็อกเก็ตนี้เพื่อผ่านการเชื่อมต่อที่สร้างไว้แล้ว

แม้ว่าการเชื่อมต่อที่กำหนดไว้จะหมดเวลาและปิดในที่สุดหลังจากที่ไม่ได้ใช้งานนานพอซ็อกเก็ตก็ปิดเช่นกันและเราจะกลับไปที่ช่องสี่เหลี่ยม

จนถึงตอนนี้ดีมาก

อย่างไรก็ตามบางครั้งการเชื่อมต่อจะตาย แต่ลูกค้า ssh ยังคงพิจารณาว่ามันสร้างขึ้น สิ่งนี้มักจะเกิดขึ้นเมื่อคุณเรียกใช้งาน playbook จากแล็ปท็อปของคุณและคุณสูญเสียการเชื่อมต่อ WiFi (หรือเปลี่ยนจาก WiFi เป็น Ethernet ฯลฯ ... )

ตัวอย่างสุดท้ายนี้เป็นสถานการณ์ที่แย่มาก: คุณสามารถ ssh ไปยังเครื่องเป้าหมายด้วยการกำหนดค่า ssh เริ่มต้น แต่ตราบใดที่การเชื่อมต่อก่อนหน้าของคุณยังคงใช้งานอยู่ ansible จะไม่ลองสร้างใหม่

ณ จุดนี้เราแค่ต้องการกำจัดซ็อกเก็ตเก่าออกและวิธีที่ง่ายที่สุดในการทำเช่นนั้นก็คือการลบมัน:

# 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>

สิ่งนี้เหมาะสำหรับการแก้ไขแบบนัดเดียว แต่ถ้ามันเกิดขึ้นบ่อยเกินไปคุณอาจต้องมองหาการแก้ไขระยะยาว นี่คือตัวชี้บางอย่างที่อาจช่วยให้บรรลุเป้าหมายนี้:

• เริ่ม playbooks จากเซิร์ฟเวอร์ (ด้วยการเชื่อมต่อเครือข่ายที่เสถียรกว่าแล็ปท็อปของคุณ)
• ใช้การกำหนดค่า ansibleหรือการกำหนดค่าไคลเอ็นต์ sshโดยตรงเพื่อปิดใช้งานการแบ่งปันการเชื่อมต่อ
• ใช้ทรัพยากรเดียวกัน แต่เพื่อปรับการหมดเวลาเพื่อให้การเชื่อมต่อหลักล่มเร็วกว่าเดิม

โปรดทราบว่าในขณะที่เขียนมีตัวเลือกไม่กี่ตัวที่เปลี่ยนแปลง (ตัวอย่างเช่นการรันล่าสุดของฉันให้ฉันControlPath=/home/toadjaune/.ansible/cp/871b533295) แต่แนวคิดทั่วไปยังคงใช้ได้

การรวบรวมความจริงใช้เวลามากเกินไป

ที่จุดเริ่มต้นของทุกการเล่นเบิ้ลเก็บรวบรวมข้อมูลจำนวนมากในระบบเป้าหมายและทำให้มันเป็นข้อเท็จจริง นี่คือตัวแปรที่คุณสามารถใช้ใน playbook ของคุณและโดยปกติแล้วจะมีประโยชน์จริง ๆ แต่บางครั้งการได้รับข้อมูลนี้อาจยาวมาก (จุดเชื่อมต่อที่ไม่ดีดิสก์ที่มี i / o สูงโหลดสูง ... )

นี้ถูกกล่าวว่าคุณไม่เคร่งครัดต้องข้อเท็จจริงที่จะเรียกใช้ PlayBook และเกือบจะแน่นอนไม่ทั้งหมดของพวกเขาดังนั้นลองและปิดการใช้สิ่งที่เราไม่ต้องการ ตัวเลือกมากมายสำหรับการที่:

• ปิดใช้งานโมดูลการตั้งค่าโดยสมบูรณ์
• เปลี่ยนการกำหนดค่าของโมดูลการตั้งค่าเพื่อรวมบางส่วนเท่านั้น
  • ผ่านอาร์กิวเมนต์บรรทัดคำสั่ง
  • ผ่านไฟล์การกำหนดค่า ansible

สำหรับวัตถุประสงค์ในการดีบั๊กมันสะดวกมากที่จะเรียกใช้โมดูลการตั้งค่าโดยตรงจากบรรทัดคำสั่ง:

ansible -m setup <hostname>

คำสั่งสุดท้ายนี้ควรวางเช่นเดียวกับ playbook ของคุณและในที่สุดก็หมดเวลา (หรือสำเร็จ) ตอนนี้เราจะเรียกใช้งานโมดูลอีกครั้งปิดการใช้งานทุกสิ่งที่เราทำได้:

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

หากสิ่งนี้ยังคงค้างอยู่คุณสามารถลองและปิดการใช้งานโมดูลทั้งหมดในการเล่นของคุณได้ แต่เป็นไปได้ว่าปัญหาของคุณจะอยู่ที่อื่น

แต่ถ้าทำงานดี (และอย่างรวดเร็ว) จากนั้นมีลักษณะที่เป็นเอกสารโมดูล คุณมีสองทางเลือก:

• จำกัด ข้อเท็จจริงที่รวบรวมไปยังชุดย่อยยกเว้นสิ่งที่คุณไม่ต้องการ (ดูค่าที่เป็นไปได้สำหรับgather_subset)
• gather_timeout ยังสามารถช่วยคุณแก้ไขปัญหาโดยให้เวลามากขึ้น (แม้ว่าจะเป็นการแก้ไขข้อผิดพลาดการหมดเวลาไม่ใช่การแฮงค์)

ปัญหาอื่น ๆ

เห็นได้ชัดว่าสิ่งอื่น ๆ ผิดไป ตัวชี้บางอย่างเพื่อช่วยในการดีบัก:

• ใช้ระดับ verbosity สูงสุดที่เป็นไปได้ ( -vvvv) ซึ่งจะแสดงให้คุณเห็นทุกคำสั่งที่ดำเนินการ
• ใช้pingและsetupโมดูลโดยตรงจากบรรทัดคำสั่งตามที่อธิบายไว้ข้างต้น
• ลอง ssh ด้วยตนเองหากansible -m pingไม่ได้ผล

Dmytro กำลังเข้าสู่บางสิ่ง!

Ansible ใช้ FQDN ของโฮสต์ หากโฮสต์ของคุณไม่สามารถแก้ไข DNS ได้และคุณไม่มีการแมปในการตรวจสอบ/etc/hostsจะรอให้ DNS หมดเวลา

โดยการเพิ่ม::1 <fqdn>ไฟล์โฮสต์ของเครื่องที่คุณกำลังเชื่อมต่อ Ansible จะได้รับ FQDN ทันทีโดยไม่ต้องผ่าน DNS

โปรดทราบว่าโฮสต์ควรค้นหาโฮสต์จาก/etc/hostsนี่เป็นค่าเริ่มต้นสำหรับระบบ linux ส่วนใหญ่ถ้าไม่ใช่ทั้งหมด แต่หากคุณแก้ไข/etc/nsswitch.confด้วยเช่นกันซึ่งอาจเป็นปัญหา

ฉันมีปัญหาเดียวกัน ไม่มีข้อมูลที่เป็นประโยชน์จากการรัน ansible ในโหมด verbose

เซิร์ฟเวอร์ได้รับการจัดเตรียมใหม่ก่อนเรียกใช้ playbook

การลบเซิร์ฟเวอร์ออกจากรายการโฮสต์ที่รู้จักได้รับการแก้ไขโดยใช้คำสั่งด้านล่าง

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

หมายเหตุ: คุณต้องลบทั้งชื่อโฮสต์และที่อยู่ IP

ฉันไม่รู้ว่าคุณกำลังใช้งาน playbook ของ sudo หรือเปล่า แต่ฉันก็เป็นแบบนั้นและมันก็แขวนอยู่กับรหัสผ่าน sudo

จากเอกสาร - คุณสามารถฆ่ามันแล้วใช้-Kเช่นกัน

โชคดี.

บางทีลายนิ้วมือของระบบเป้าหมายของคุณเปลี่ยนไปเช่นเมื่อคุณติดตั้งระบบปฏิบัติการเซิร์ฟเวอร์ใหม่ คุณต้องลบรายการในknown_hosts , ansible จะไม่แจ้งให้ทราบว่ารายการที่ไม่น่าเชื่อถือนั้นเป็นปัญหา แต่มันก็ติดอยู่ตรงที่คุณอธิบาย

ดูเหมือนว่า ansible ไม่สามารถตรวจสอบสิทธิ์ ... ดังนั้นใช้ -k เพื่อให้ ansible ถามรหัสผ่านเซิร์ฟเวอร์ .... ดังแสดงด้านล่าง:

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

FQDN และชื่อโฮสต์ไม่ตรงกันอาจทำให้เกิดการแฮงเอาท์ได้ ฉันใช้ FQDN กับโดเมนต่างจากชื่อโฮสต์ หลังจากทำให้ทั้งสองเท่ากันแล้ว ansible ก็ทำงานได้อย่างสมบูรณ์แบบ อาจเป็นไปได้เปรียบเทียบ FQDN และชื่อโฮสต์ก่อนดำเนินการงานบนโฮสต์ระยะไกล หวังว่ามันจะช่วย!

ฉันแก้ไขปัญหานี้ได้โดยการรีเซ็ตกล่องคนพเนจร

vagrant destroy
vagrant up

ในกรณีของฉัน ansible หยุดทำงานกลางงาน เหตุผลก็เพราะตัวแทน SSH ของฉันหยุดทำงาน ( ssh-add -lไม่ได้กลับอะไร) ฉันรีสตาร์ททุกอย่างและทำงานได้อีกครั้ง ดังนั้นตรวจสอบว่า ssh-agent ทำงานถูกต้องหรือssh-add -lไม่( ไม่ควรติดขัด)

การลบ~/.ansibleเพียงอย่างเดียวไม่ได้ทำเพื่อฉัน ดังนั้นในการตรวจสอบสิ่งที่อยู่ในไดเรกทอรีที่ผมก็ไม่ได้ Ctrl-z (ใส่กระบวนการที่จะนอนหลับ) fgและการตรวจสอบและจากนั้นยังคงกระบวนการเบิ้ลผ่านทาง ฉันไม่ได้ลบอะไรเลยในกรณีนั้น แต่หลังจากนั้นก็ดำเนินต่อไป ดังนั้นฉันจึงลอง ctrl-z-> fgเพียงอย่างเดียวและมันก็ใช้ได้ รู้สึกเหมือนเต้นรำฝน แต่ถ้ามีคนติดอยู่โปรดลองทำดู

ฉันได้แก้ไขสาเหตุของปัญหานี้แล้วโดยทำตามคำแนะนำจากเพราะเหตุใดเพลย์ลิสต์ที่อ่านได้ของฉันจึงค้างอยู่ใน "การรวบรวมข้อเท็จจริง" โพสต์บล็อก.

สามารถทำให้เป็น:

1. ตั้งค่าDEFAULT_KEEP_REMOTE_FILES=yesให้รักษาคำสั่งและเปิดใช้งาน-vvvv

2. เรียกใช้ playbook อีกครั้ง

3. เมื่อ play stucks คัดลอกคำสั่ง shell ล่าสุดที่พิมพ์ (ส่วนหลัง/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. ตรวจสอบขั้นตอนการโทร "straced" ที่ติดอยู่และแก้ไข :)

ในกรณีของฉันมันเป็นไดรฟ์เครือข่ายที่ไม่สามารถเข้าถึงได้ ...

รหัสผ่านของ Sudo เป็นปัญหา ตรวจสอบให้แน่ใจว่า (1) คุณสามารถออก 'sudo อะไรก็ได้ ' บนเทอร์มินัลที่เพิ่งเปิดใหม่ (โดยที่รหัสผ่านไม่ถูกแคช) โดยไม่ได้ระบุหนึ่ง (2) ที่หุ่นไม่ได้กลับรายการการเปลี่ยนแปลง 'sudoers' ด้วยตนเอง