Saya mengalami beberapa masalah aneh dengan kotak saya (gelandangan).

Semuanya bekerja kemarin dan playbook saya berfungsi dengan baik.

Hari ini, apakah mungkin untuk "mengumpulkan fakta"?

Berikut ini adalah keluaran 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'"]

Saya memiliki masalah yang sama dengan Ping kemungkinan pada Vagrant, itu tiba-tiba macet tanpa alasan dan sebelumnya bekerja dengan sangat baik. Tidak seperti masalah lain seperti ssh atau masalah ikat, itu selamanya mati tanpa batas waktu.

Satu hal yang saya lakukan untuk mengatasi masalah ini adalah membersihkan ~/.ansibledirektori dan hanya berfungsi lagi. Saya tidak bisa mencari tahu mengapa, tetapi itu bisa diselesaikan.

Jika Anda ingin mengubahnya lagi, coba bersihkan ~/.ansiblefoldernya sebelum Anda menyegarkan kembali Vagrant Anda.

Bagi saya modul pengaturan modul macet di mount NFS mati.

Jika Anda melakukan "df" pada mesin Anda dan tidak ada yang terjadi, Anda mungkin berada pada kasus yang sama.

PS: jika Anda tidak dapat melakukan umount share / mountpoint NFS, pertimbangkan untuk menggunakan "umount -l" yang salah

Kemungkinan dapat menggantung seperti ini karena sejumlah alasan, biasanya karena masalah koneksi atau karena modul pengaturan hang. Inilah cara mempersempit masalah sehingga Anda bisa menyelesaikannya.

Kemungkinan tidak dapat terhubung ke host tujuan

Masalah Host Key (known_hosts)

1) Pada versi Ansible yang lebih lama (2.1 atau lebih tua), Ansible tidak akan selalu memberi tahu Anda jika kunci host untuk tujuan tidak ada pada sumbernya, atau jika ada ketidakcocokan.

Solusi: coba buka koneksi SSH dengan parameter yang sama ke tujuan itu. Anda mungkin menemukan kesalahan SSH yang perlu Anda selesaikan, dan kemudian perintah itu akan berfungsi.

2) Terkadang Ansible menampilkan pesan koneksi SSH kepada Anda di tengah-tengah status lainnya, menyebabkan Ansible untuk "membeku" pada tugas itu:

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)?

Dalam hal ini, cukup mengetik "ya" untuk sebanyak mungkin pertanyaan SSH yang Anda minta akan memungkinkan permainan berlanjut. Setelah itu, Anda dapat memperbaiki masalah root known_hosts.

Masalah Otentikasi Kunci Pribadi

Jika menggunakan otentikasi berbasis kata kunci vs kata sandi, masalah lain termasuk:

• Kunci pribadi mungkin tidak diatur dengan benar di tujuan
• Kunci pribadi mungkin memiliki izin yang salah secara lokal (harus dapat dibaca hanya oleh pengguna yang menjalankan pekerjaan Ansible)

Solusi: coba jalankan ansible -m ping <destination> -kmelawan host masalah - jika itu tidak berhasil, coba solusi Masalah Kunci Host di atas.

Ansible tidak bisa dengan cepat mengumpulkan fakta

The setupmodul (ketika dijalankan secara otomatis pada awal suatu ansible-playbookrun, atau ketika dijalankan secara manual sebagai ansible -m setup <host>) sering dapat hang ketika mengumpulkan fakta hardware (misalnya jika mendapatkan informasi disk dari host dengan i tinggi / o, buruk me-mount entri, dll).

Solusi: coba jalankan ansible -m setup -a gather_subset=!all <destination>. Jika ini berhasil, Anda harus mempertimbangkan pengaturan baris ini di ansible.cfg Anda:

gather_subset=!hardware

Saya memiliki masalah serupa dengan Ansible hang di Gathering Facts. Saya memangkas skrip saya ke prompt tanpa tugas atau peran dan itu masih menggantung.

Saya menemukan 12 proses yang tergantung pada daftar proses saya yang telah terakumulasi sepanjang hari.

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

Begitu saya membunuh itu, mulai bekerja lagi.

Ada banyak alasan mengapa seseorang bisa digantung di pengumpulan fakta, tetapi sebelum melangkah lebih jauh, inilah ujian pertama yang harus Anda lakukan dalam situasi seperti itu:

ansible -m ping <hostname>

Tes ini hanya terhubung ke host, dan mengeksekusi kode yang cukup untuk kembali:

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

Jika ini berhasil, Anda dapat menyingkirkan masalah pengaturan atau konektivitas, karena ini membuktikan bahwa Anda dapat menyelesaikan nama host target, membuka koneksi, mengautentikasi, dan menjalankan modul yang memungkinkan dengan interpreter python jarak jauh.

Sekarang, berikut adalah daftar (tidak lengkap) hal-hal yang bisa salah di awal buku pedoman:

Perintah yang dijalankan oleh ansible sedang menunggu input interaktif

Saya dapat mengingat ini terjadi pada versi yang lebih lama, di mana perintah akan menunggu input interaktif yang tidak akan pernah datang, seperti kata sandi sudo (ketika Anda lupa -Kswitch), atau penerimaan sidik jari host ssh baru (untuk target baru tuan rumah).

Versi modern dari kemungkinan menangani kedua kasus ini dengan anggun dan segera meningkatkan kesalahan untuk penggunaan normal, jadi kecuali Anda melakukan hal-hal seperti memanggil ssh atau sudo sendiri, Anda seharusnya tidak memiliki masalah seperti ini. Dan bahkan jika Anda melakukannya, itu akan terjadi setelah pengumpulan fakta.

Koneksi master ssh mati

Ada beberapa opsi yang sangat menarik diteruskan ke klien ssh, di log debug yang diberikan di sini:

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

Opsi-opsi ini didokumentasikan dalam man ssh_config .

Secara default, ansible akan mencoba dan pandai mengenai penggunaan koneksi ssh-nya. Untuk host tertentu, alih-alih membuat koneksi baru untuk masing-masing dan setiap tugas dalam permainan, itu akan membukanya sekali, dan membuatnya tetap terbuka untuk seluruh playbook (dan bahkan di seluruh playbook).

Itu bagus, karena membuat koneksi baru jauh lebih lambat dan intensif komputasi daripada menggunakan yang sudah ada.

Dalam praktiknya, setiap koneksi ssh akan memeriksa keberadaan soket di ~/.ansible/cp/some-host-specific-path. Koneksi pertama tidak dapat menemukannya, sehingga terhubung secara normal, dan kemudian membuatnya. Setiap koneksi selanjutnya hanya akan menggunakan soket ini untuk pergi melalui koneksi yang sudah ada.

Bahkan jika koneksi yang terbentuk akhirnya mati dan menutup setelah tidak digunakan cukup lama, soketnya juga tertutup, dan kami kembali ke titik awal.

Sejauh ini bagus.

Namun kadang-kadang, koneksi benar-benar mati, tetapi klien ssh masih menganggapnya telah dibuat. Ini biasanya terjadi ketika Anda menjalankan playbook dari laptop Anda, dan Anda kehilangan koneksi WiFi Anda (atau beralih dari WiFi ke Ethernet, dll ...)

Contoh terakhir ini adalah situasi yang mengerikan: Anda dapat ssh ke mesin target dengan konfigurasi ssh default, tetapi selama koneksi Anda sebelumnya masih dianggap aktif, mungkin tidak akan mencoba membuat yang baru.

Pada titik ini, kami hanya ingin menyingkirkan soket lama ini, dan cara paling sederhana untuk melakukannya adalah menghapusnya:

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

Ini sempurna untuk perbaikan sekali pakai, tetapi jika itu terjadi terlalu sering, Anda mungkin perlu mencari perbaikan jangka panjang. Berikut adalah beberapa petunjuk yang dapat membantu mencapai tujuan ini:

• Mulai playbook dari server (dengan cara koneksi jaringan yang lebih stabil daripada laptop Anda)
• Gunakan konfigurasi yang memungkinkan , atau langsung ssh konfigurasi klien untuk menonaktifkan berbagi koneksi
• Gunakan sumber daya yang sama, tetapi untuk menyempurnakan timeout, sehingga koneksi master crash lebih cepat habis

Harap perhatikan bahwa pada saat penulisan, beberapa opsi telah berubah (misalnya, jangka terakhir saya memberi saya ControlPath=/home/toadjaune/.ansible/cp/871b533295), tetapi gagasan umum masih valid.

Pengumpulan fakta sebenarnya membutuhkan terlalu banyak waktu

Di awal setiap permainan, anonim mengumpulkan banyak informasi tentang sistem target, dan memasukkannya ke dalam Fakta . Ini adalah variabel yang dapat Anda gunakan di playbook Anda, dan biasanya sangat berguna, tetapi kadang-kadang, mendapatkan info ini bisa sangat lama (titik pemasangan yang buruk, disk dengan i / o tinggi, beban tinggi ...)

Dikatakan bahwa, Anda tidak benar - benar membutuhkan fakta untuk menjalankan buku pedoman, dan hampir pasti tidak semuanya, jadi mari kita coba nonaktifkan apa yang tidak kita butuhkan. Beberapa opsi untuk itu:

• Benar-benar menonaktifkan modul pengaturan
• Ubah konfigurasi modul pengaturan untuk hanya menyertakan bagian tertentu saja.
  • Melalui argumen baris perintah
  • Melalui file konfigurasi yang mungkin

Untuk keperluan debugging, sangat mudah untuk memanggil modul pengaturan langsung dari baris perintah:

ansible -m setup <hostname>

Perintah terakhir ini harus digantung seperti halnya buku pedoman Anda, dan akhirnya batas waktu (atau berhasil). Sekarang, mari kita jalankan modul lagi, menonaktifkan semua yang kita bisa:

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

Jika ini masih hang, Anda selalu dapat mencoba dan menonaktifkan sepenuhnya modul dalam permainan Anda, tetapi kemungkinan besar masalah Anda ada di tempat lain.

Namun, jika berfungsi dengan baik (dan cepat), lihat dokumentasi modul . Anda memiliki dua opsi:

• Batasi pengumpulan fakta untuk subset, mengecualikan apa yang tidak Anda butuhkan (lihat nilai yang mungkin untuk gather_subset)
• gather_timeout juga dapat membantu Anda memperbaiki masalah Anda, dengan memberikan lebih banyak waktu (meskipun itu akan memperbaiki kesalahan batas waktu, bukan hang)

Masalah lain

Jelas, hal-hal lain bisa salah. Beberapa petunjuk untuk membantu debugging:

• Gunakan tingkat verbositas maksimum yang dimungkinkan ( -vvvv), karena akan menampilkan setiap perintah yang dijalankan
• Gunakan pingdan setupmodul langsung dari baris perintah seperti yang dijelaskan di atas
• Cobalah ssh secara manual jika ansible -m pingtidak berhasil

Dmytro melakukan sesuatu!

Ansible menggunakan FQDN host. Jika host Anda bukan DNS yang dapat diselesaikan dan Anda tidak memiliki pemetaan yang tidak /etc/hostsmemungkinkan, DNS akan habis.

Dengan menambahkan ::1 <fqdn>file host dari mesin yang Anda sambungkan, Ansible akan segera mendapatkan FQDN tanpa melalui DNS.

Perhatikan bahwa host harus mencari host dari /etc/hosts, ini adalah default untuk sebagian besar, jika tidak semua, sistem linux tetapi jika pengeditan Anda /etc/nsswitch.confjuga yang mungkin menjadi masalah.

Saya memiliki masalah yang sama. Tidak mendapat informasi berguna dari menjalankan ansible dalam mode verbose.

Server disediakan kembali sebelum menjalankan playbook.

Menghapus server dari daftar host yang dikenal memperbaikinya menggunakan perintah di bawah ini.

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

Catatan: Anda harus menghapus nama host dan alamat ip

Saya tidak tahu apakah Anda menggunakan sudo playbook - tetapi saya tahu, dan itu tergantung pada kata sandi sudo.

Dari dokumentasi - Anda dapat mematikannya, dan kemudian menggunakannya -Kjuga.

Semoga berhasil.

Mungkin Sidik Jari sistem target Anda telah berubah, misalnya ketika Anda menginstal ulang OS server. Anda harus menghapus entri di known_hosts , ansible tidak akan memberi tahu bahwa entri yang tidak tepercaya adalah masalahnya, itu hanya akan macet persis seperti yang Anda jelaskan.

Kedengarannya tidak mungkin untuk mengotentikasi ... jadi gunakan -k untuk memungkinkan meminta kata sandi server .... seperti yang ditunjukkan di bawah ini:

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

Ketidakcocokan FQDN dan hostname juga dapat menyebabkan hangout yang mungkin terjadi. Saya telah menggunakan FQDN dengan domain berbeda dari domain hostname. Setelah membuat keduanya sama , ansible bekerja dengan sempurna. Kemungkinan memungkinkan membandingkan FQDN dan nama host sebelum menjalankan tugas pada host jarak jauh. Semoga ini bisa membantu!

Saya memecahkan masalah ini dengan mereset kotak gelandangan

vagrant destroy
vagrant up

Dalam kasus saya, mungkin berhenti bekerja di tengah-tengah tugas. Alasannya adalah karena agen ssh saya berhenti bekerja ( ssh-add -ltidak mengembalikan apa pun). Saya me-restart semuanya dan berhasil lagi. Jadi periksa apakah ssh-agent Anda berfungsi dengan baik ( ssh-add -ltidak boleh macet).

Menghapus ~/.ansiblesaja tidak melakukannya untuk saya. Jadi untuk memeriksa apa yang ada di direktori itu, saya hanya melakukan ctrl-z (meletakkan proses untuk tidur) dan memeriksa, dan kemudian melanjutkan proses yang dimungkinkan melalui fg. Saya tidak menghapus apa pun dalam kasus itu. tapi setelah itu baru dilanjutkan. Jadi saya hanya mencoba ctrl-z-> fgsendirian dan itu juga berhasil. Rasanya seperti menari hujan, tetapi jika orang lain macet, silakan juga coba itu.

Saya telah memperbaiki penyebab masalah ini dengan mengikuti saran dari Mengapa playbook saya yang hangus tergantung pada “Mengumpulkan fakta”? posting blog.

Ini dapat disederhanakan untuk:

1. Atur DEFAULT_KEEP_REMOTE_FILES=yesuntuk mempertahankan perintah dan mengaktifkan-vvvv

2. Jalankan playbook lagi.

3. Ketika drama berhenti menyalin perintah shell terakhir dicetak (bagian setelah /bin/sh -c)

4. Log on server via ssh.

5. Gunakan straceuntuk memutar ulang langkah terakhir dari permainan. Perintah langkah disalin dari -vvvoutput. Sebagai contoh:strace -f /bin/sh -c "echo BECOME-SUCCESS-ltxvshvezrnmumzdprccoiekhjheuwxt; /usr/bin/python /home/user/.ansible/tmp/ansible-tmp-1527099315.31-224479822965785/setup.py"

6. Periksa panggilan mana yang langkah "straced" macet dan perbaiki :)

Dalam kasus saya itu adalah drive jaringan yang tidak dapat diakses ...

Kata sandi Sudo adalah masalahnya. Pastikan bahwa (1) Anda dapat mengeluarkan 'sudo apapun ' pada terminal yang baru dibuka (di mana kata sandi tidak di-cache) tanpa memberikan satu (2) boneka yang tidak membalikkan perubahan 'sudoers' manual sebelumnya.