Khắc phục lỗi Ansible 'dict object has no attribute rc' trong các Task bị bỏ qua

Lỗ hổng logic: Tại sao các tác vụ bị bỏ qua lại làm hỏng Playbook

Hãy tưởng tượng bạn đang thực hiện một nửa quá trình triển khai môi trường production thì playbook dừng lại đột ngột. Điều này không phải do máy chủ bị sập hay sự cố mạng, mà là một trường hợp biên về logic. Bạn có một tác vụ lưu kết quả vào một biến, nhưng vì tác vụ đó bị bỏ qua, bước tiếp theo sẽ thất bại khi cố gắng đọc dữ liệu không tồn tại.

Lỗi này thường xuất hiện khi bạn kết hợp câu lệnh register với điều kiện when. Nếu điều kiện sai, tác vụ sẽ bị bỏ qua. Do đó, biến được đăng ký sẽ thiếu các key tiêu chuẩn như rc (Mã trả về), stdout hoặc stderr.

Kịch bản vấn đề

- name: Kiểm tra xem dịch vụ tùy chỉnh có đang chạy không
  command: systemctl is-active my-service
  register: service_check
  when: check_service_health | default(false)
  ignore_errors: yes

- name: Khởi động lại dịch vụ nếu kiểm tra thất bại
  service:
    name: my-service
    state: restarted
  when: service_check.rc != 0

Nếu check_service_health là false, tác vụ đầu tiên sẽ bị bỏ qua. Ansible vẫn khởi tạo biến service_check để theo dõi trạng thái, nhưng nó chỉ chứa siêu dữ liệu cơ bản:

{
    "skipped": true,
    "changed": false
}

Khi tác vụ thứ hai cố gắng truy cập service_check.rc, nó sẽ gặp trở ngại. Vì không có key rc trong kết quả bị bỏ qua, Jinja2 sẽ báo lỗi:

The conditional check 'service_check.rc != 0' failed. The error was: 'dict object' has no attribute 'rc'

Tại sao Ansible lại hoạt động như vậy

Từ khóa register của Ansible có tính bền vững. Nó tạo ra biến ngay cả khi module không bao giờ thực thi. Đây là thiết kế có chủ đích; nó cho phép bạn kiểm tra variable.skipped trong các tác vụ sau đó. Tuy nhiên, các giá trị trả về cụ thể của một module—như mã trả về 0 hoặc 1 từ một lệnh shell—chỉ tồn tại nếu lệnh đó thực sự được chạy.

Trong thế giới của Jinja2, việc truy cập một key dictionary không tồn tại là một lỗi nghiêm trọng. Playbook của bạn sẽ dừng lại ngay lập tức để ngăn chặn các hành vi không lường trước được.

Giải pháp 1: Filter 'default' (Sửa nhanh)

Để giải quyết vấn đề này nhanh chóng, hãy sử dụng filter default của Jinja2. Điều này cung cấp một giá trị dự phòng để phép so sánh có dữ liệu làm việc, ngay cả khi tác vụ đã bị bỏ qua.

- name: Khởi động lại dịch vụ nếu kiểm tra thất bại
  service:
    name: my-service
    state: restarted
  when: (service_check.rc | default(0)) != 0

Bằng cách sử dụng default(0), chúng ta giả định trạng thái "thành công" nếu việc kiểm tra chưa bao giờ diễn ra. Vì 0 != 0 là sai, tác vụ khởi động lại sẽ được bỏ qua một cách an toàn mà không gây treo chương trình.

Giải pháp 2: Logic chặt chẽ với kiểm tra bỏ qua

Việc phụ thuộc vào các giá trị mặc định đôi khi có thể che lấp các lỗi thực tế. Một cách tiếp cận chuyên nghiệp hơn là kiểm tra rõ ràng xem tác vụ có bị bỏ qua hay không trước khi đánh giá kết quả của nó.

Kiểm tra bỏ qua rõ ràng

- name: Khởi động lại dịch vụ nếu kiểm tra thất bại
  service:
    name: my-service
    state: restarted
  when: 
    - service_check is not skipped
    - service_check.rc != 0

Ansible đánh giá các danh sách when theo thứ tự. Nếu service_check is not skipped là sai, Ansible sẽ dừng lại ngay tại đó. Nó thậm chí sẽ không cố gắng tìm thuộc tính rc ở dòng thứ hai, từ đó tránh được lỗi một cách hiệu quả.

Sử dụng kiểm tra 'is defined'

Nếu bạn muốn an toàn tối đa, hãy xác minh xem thuộc tính đó có tồn tại hay không:

- name: Khởi động lại dịch vụ nếu kiểm tra thất bại
  service:
    name: my-service
    state: restarted
  when: service_check.rc is defined and service_check.rc != 0

Xác minh: Kiểm tra bản sửa lỗi

Đừng đợi đến khi chạy trên môi trường production mới xem logic của bạn có ổn không. Bạn có thể mô phỏng việc bỏ qua một cách dễ dàng.

• Kích hoạt việc bỏ qua: Chạy playbook của bạn với việc ghi đè biến: -e "check_service_health=false".
• Kiểm tra JSON: Thêm một tác vụ debug để xem chính xác những gì Ansible thấy:

- name: Debug kết quả kiểm tra dịch vụ
  debug:
    var: service_check

• Chạy với chế độ Verbosity: Sử dụng cờ -v. Bạn sẽ thấy đầu ra của tác vụ là skipping thay vì fatal. Điều này xác nhận rằng logic điều kiện của bạn hiện đang xử lý các thuộc tính bị thiếu một cách trơn tru.

Những điểm chính cần lưu ý

• Tính bền vững của biến: Các biến được đăng ký luôn được tạo nếu tác vụ được tiếp cận, bất kể nó có thực thi hay không.
• Nội dung một phần: Dictionary của một tác vụ bị bỏ qua gần như trống rỗng, thường chỉ chứa skipped: true.
• Tham chiếu an toàn: Luôn sử dụng | default() hoặc is not skipped khi lấy dữ liệu từ các tác vụ có điều kiện when riêng.
• Đánh giá lười biếng (Lazy Evaluation): Trong một danh sách các điều kiện, Ansible sẽ dừng lại ở giá trị false đầu tiên. Hãy đặt các kiểm tra sự tồn tại lên trước.