Có nhiều lý do tại sao ansible có thể bị treo khi thu thập thực tế, nhưng trước khi đi xa hơn, đây là thử nghiệm đầu tiên bạn nên thực hiện trong bất kỳ tình huống nào như vậy:
ansible -m ping <hostname>
Thử nghiệm này chỉ kết nối với máy chủ và thực thi đủ mã để trả về:
<hostname> | SUCCESS => {
"changed": false,
"ping": "pong"
}
Nếu điều này hoạt động, bạn có thể loại trừ khá nhiều vấn đề thiết lập hoặc kết nối, vì nó chứng minh rằng bạn có thể giải quyết tên máy chủ đích, mở kết nối, xác thực và thực thi mô-đun ansible với trình thông dịch python từ xa.
Bây giờ, đây là một danh sách (không đầy đủ) những điều có thể sai ở phần đầu của một cuốn sách:
Lệnh được thực thi bởi ansible đang chờ một đầu vào tương tác
Tôi có thể nhớ điều này xảy ra trên các phiên bản cũ hơn, trong đó một lệnh sẽ chờ một đầu vào tương tác sẽ không bao giờ đến, chẳng hạn như mật khẩu sudo (khi bạn quên một -Kcông tắc) hoặc chấp nhận dấu vân tay của máy chủ ssh mới (cho mục tiêu mới người dẫn chương trình).
Các phiên bản hiện đại của ansible xử lý cả hai trường hợp này một cách duyên dáng và gây ra lỗi ngay lập tức cho các ứng dụng thông thường, vì vậy trừ khi bạn làm những việc như gọi ssh hoặc sudo cho mình, bạn không nên gặp phải vấn đề này. Và ngay cả khi bạn đã làm, nó sẽ là sau khi thu thập thực tế.
Kết nối chủ ssh chết
Có một số tùy chọn rất thú vị được truyền cho máy khách ssh, trong nhật ký gỡ lỗi được đưa ra ở đây:
ControlMaster=autoControlPersist=60sControlPath=/home/vagrant/.ansible/cp/ansible-ssh-%h-%p-%r
Các tùy chọn này được ghi lại trong man ssh_config .
Theo mặc định, ansible sẽ thử và thông minh về việc sử dụng kết nối ssh của nó. Đối với một máy chủ nhất định, thay vì tạo một kết nối mới cho mỗi nhiệm vụ trong trò chơi, nó sẽ mở nó một lần và giữ cho nó mở cho toàn bộ playbook (và thậm chí trên các playbook).
Điều đó tốt, vì việc thiết lập một kết nối mới chậm hơn và chuyên sâu về tính toán hơn là sử dụng kết nối đã có sẵn.
Trong thực tế, mọi kết nối ssh sẽ kiểm tra sự tồn tại của ổ cắm tại ~/.ansible/cp/some-host-specific-path. Kết nối đầu tiên không thể tìm thấy nó, vì vậy nó kết nối bình thường, và sau đó tạo ra nó. Mọi kết nối tiếp theo sau đó sẽ chỉ sử dụng ổ cắm này để đi qua kết nối đã được thiết lập.
Ngay cả khi kết nối được thiết lập cuối cùng cũng hết và đóng lại sau khi không được sử dụng đủ lâu, ổ cắm cũng bị đóng và chúng tôi quay lại hình vuông.
Càng xa càng tốt.
Tuy nhiên, đôi khi, kết nối thực sự chết, nhưng máy khách ssh vẫn xem xét nó được thiết lập. Điều này thường xảy ra khi bạn thực hiện Playbook từ máy tính xách tay của bạn và bạn mất kết nối WiFi (hoặc chuyển từ WiFi sang Ethernet, v.v.
Ví dụ cuối cùng này là một tình huống tồi tệ: bạn có thể ssh đến máy đích với cấu hình ssh mặc định, nhưng miễn là kết nối trước đó của bạn vẫn được coi là hoạt động, ansible thậm chí sẽ không thử thiết lập máy mới.
Tại thời điểm này, chúng tôi chỉ muốn thoát khỏi ổ cắm cũ này và cách đơn giản nhất để làm điều đó là loại bỏ nó:
# 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>
Điều này là hoàn hảo cho một sửa chữa một lần, nhưng nếu nó xảy ra quá thường xuyên, bạn có thể cần phải tìm một sửa chữa dài hạn. Dưới đây là một số gợi ý có thể giúp hướng tới mục tiêu này:
- Bắt đầu chơi từ máy chủ (với cách kết nối mạng ổn định hơn so với máy tính xách tay của bạn)
- Sử dụng cấu hình ansible hoặc cấu hình máy khách ssh trực tiếp để tắt chia sẻ kết nối
- Sử dụng cùng một tài nguyên, nhưng để tinh chỉnh thời gian chờ, để sự cố kết nối chính thực sự hết thời gian nhanh hơn
Xin lưu ý rằng tại thời điểm viết, một vài tùy chọn đã thay đổi (ví dụ: lần chạy mới nhất của tôi đã cho tôi ControlPath=/home/toadjaune/.ansible/cp/871b533295), nhưng ý tưởng chung vẫn còn hiệu lực.
Thu thập thực tế mất quá nhiều thời gian
Khi bắt đầu mỗi lần chơi, ansible thu thập rất nhiều thông tin về hệ thống mục tiêu và đưa nó vào Sự kiện . Đây là các biến mà sau đó bạn có thể sử dụng trong Playbook của mình và thường rất tiện dụng, nhưng đôi khi, việc nhận thông tin này có thể rất dài (điểm gắn kết xấu, đĩa có i / o cao, tải trọng cao)
Điều này đang được nói, bạn không thực sự cần sự thật để chạy một cuốn sách và gần như chắc chắn không phải tất cả chúng, vì vậy hãy thử và vô hiệu hóa những gì chúng ta không cần. Một số tùy chọn cho điều đó:
Đối với mục đích gỡ lỗi, thật sự thuận tiện khi gọi mô đun thiết lập trực tiếp từ dòng lệnh:
ansible -m setup <hostname>
Lệnh cuối cùng này sẽ treo cũng như playbook của bạn và cuối cùng là hết thời gian (hoặc thành công). Bây giờ, hãy thực hiện lại mô-đun, vô hiệu hóa mọi thứ chúng ta có thể:
ansible -m setup -a gather_subset='!all' <hostname>
Nếu điều này vẫn bị treo, bạn luôn có thể thử và vô hiệu hóa hoàn toàn mô-đun trong trò chơi của mình, nhưng thực sự có khả năng vấn đề của bạn là ở một nơi khác.
Tuy nhiên, nếu nó hoạt động tốt (và nhanh chóng), thì hãy xem tài liệu mô-đun . Bạn có hai lựa chọn:
- Giới hạn việc thu thập thực tế vào một tập hợp con, ngoại trừ những gì bạn không cần (xem các giá trị có thể cho
gather_subset)
gather_timeout cũng có thể giúp bạn khắc phục sự cố của mình bằng cách cho phép thêm thời gian (mặc dù đó sẽ là sửa lỗi hết thời gian chờ chứ không phải treo máy)
Các vấn đề khác
Rõ ràng, những thứ khác có thể đi sai. Một vài gợi ý để giúp gỡ lỗi:
- Sử dụng mức độ dài tối đa có thể tìm thấy (
-vvvv), vì nó sẽ hiển thị cho bạn mọi lệnh được thực thi
- Sử dụng
pingvà setupmô-đun trực tiếp từ dòng lệnh như đã giải thích ở trên
- Cố gắng ssh bằng tay nếu
ansible -m pingkhông hoạt động
vagrant sshvà điều tra trong quá trình treo để xem có gì hữu ích trongpsvànetstatkhông? Ngoài ra, một trong những nghi phạm đầu tiên bị treo là DNS - kiểm tra xem DNS có phân giải được từ bên trong máy ảo không.