Làm cách nào để kiểm tra việc cung cấp và cấu hình trong thiết lập Ansible?

Nhìn vào việc cố gắng xây dựng một số khả năng phục hồi vào thiết lập Ansible của chúng tôi liên quan đến việc cung cấp và cấu hình.

Tôi hiểu một số phương pháp thử nghiệm ở khía cạnh cấu hình của mọi thứ nhưng tôi tự hỏi làm thế nào tốt nhất để thực hiện thử nghiệm ở phía cung cấp mọi thứ, và nếu có bất kỳ công cụ nào có thể giúp loại hình triển khai này.

Hiện tại rất nhiều thử nghiệm của chúng tôi được thực hiện một cách thanh thản trong suốt quá trình chơi, điều này rất có ý nghĩa đối với những thứ như "dịch vụ đã xuất hiện, vip có sẵn, nhiệm vụ không đồng bộ này đã kết thúc" nhưng điều tôi thực sự quan tâm là khả năng quản lý trôi dạt của chúng tôi cấu hình ở cả lớp ứng dụng và cung cấp (như cấu hình VM). Tôi biết Ansible không phải là công cụ tốt nhất để làm việc với cấu hình trôi nhưng tôi tò mò muốn xem ý kiến ​​của riêng bạn.

Nếu bạn có một cái gì đó để tự động hóa hoàn toàn quá trình thậm chí tốt hơn. (chúng tôi có một vài kịch bản xấu xí báo cáo lại trong tình trạng chậm chạp hàng ngày).

Lưu ý : Ngay bây giờ chúng ta có một vài điều kiện có thể xảy ra sự từ chối (ví dụ: xây dựng lại từ bản sao lưu, sự cố hệ thống quan trọng) nhưng thông thường, nó chỉ lặp qua một số tác vụ định cấu hình có thể tìm thấy và không nghĩ đến nó nữa.

Một số tùy chọn ngoài kia ..

Công cụ kiểm tra: Sắp xếp theo sao github

• Serverspec - Ruby, công cụ phổ biến nhất hiện có, được xây dựng trên rspec của ruby
• Goss - YAML, đơn giản, nhị phân độc lập <10 MB, cực kỳ nhanh, có thể tạo các thử nghiệm từ trạng thái hệ thống
• Inspec - Ruby, nghĩ về nó như một máy chủ được cải tiến, gần như cùng một cú pháp, được tạo ra bởi những người đầu bếp. Được xây dựng để dễ dàng mở rộng hơn serverpec
• Testinfra - Python, có tính năng thú vị là có thể sử dụng kho / vars của Ansible

Sự khác biệt chính giữa chúng:

Cuối cùng, tôi sẽ đề nghị dành một ngày thử nghiệm với tất cả chúng để cảm nhận về chúng trước khi quyết định cho chính mình.

• Ngoại trừ Goss, tất cả các khung có thể chạy trên một máy từ xa (ví dụ: trên ssh). Goss chỉ chạy cục bộ hoặc trong docker w / dgoss.
• Tất cả các khung có thể được chạy cục bộ trên máy chủ, nhưng yêu cầu Python hoặc Ruby phải được cài đặt hoặc nhúng. Inspec cung cấp gói <150 MB khép kín với phiên bản nhúng của ruby. Goss là một nhị phân <10 MB không có phụ thuộc bên ngoài.
• Goss đã tích hợp hỗ trợ cho đầu ra nagios / Sensu, điều này cho phép tích hợp dễ dàng hơn với các công cụ giám sát.
• Các thử nghiệm Goss có xu hướng đơn giản hơn, nhưng kém linh hoạt hơn vì nó dựa trên YAML. Các khung khác cho phép bạn tận dụng toàn bộ sức mạnh của ngôn ngữ cơ bản Python / Ruby để viết các bài kiểm tra hoặc mở rộng chức năng của công cụ. (đơn giản so với tính linh hoạt)
• Goss cho phép bạn tạo các bài kiểm tra từ trạng thái hệ thống hiện tại
• Testinfra theo hiểu biết của tôi là người duy nhất có hỗ trợ tích hợp cho hàng tồn kho và các biến có thể tìm thấy
• Inspec được hỗ trợ bởi Chef

Thử nghiệm liên tục / phân kỳ:

• Tuân thủ đầu bếp - làm việc với Inspec để liên tục kiểm tra máy chủ, sản phẩm trả phí của bạn
• Goss - Có thể dễ dàng móc vào Nagios hoặc Sensu. Ngoài ra, hỗ trợ hiển thị các bài kiểm tra máy chủ dưới dạng điểm cuối http.

Kiểm tra khai thác để phát triển:

• bếp - Công cụ khai thác thử nghiệm, khởi chạy phiên bản, chạy mã quản lý cấu hình, chạy bộ kiểm tra. Được làm bởi những người đầu bếp
• Phân tử - Tương tự như bếp thử nghiệm, nhưng được viết riêng cho ansible

Tiết lộ đầy đủ: Tôi là tác giả của tin đồn

CẬP NHẬT: InSpec 4.x trở lên sử dụng giấy phép thương mại / nguồn mở hỗn hợp - xem ý kiến.

Hai công cụ tôi đã thấy cho điều này là InSpec và ServerSpec . Serverspec là một công cụ dựa trên Ruby xây dựng trên RSpec . InSpec được lấy cảm hứng từ RSpec và ServerSpec.

Tôi đã sử dụng ServerSpec. Thật tuyệt, nhưng có thể không ổn định 100%. Tôi đã gặp vấn đề với việc kiểm tra các phiên bản phần mềm cụ thể trên Ubuntu.

Tôi đã đọc các tài liệu InSpec nhưng chưa đào sâu. Nó về cơ bản giống như Serverspec.

Đánh giá bởi các cam kết của Github, có vẻ như công việc trên ServerSpec đã giảm bớt phần nào, trong khi InSpec đang được tăng cường.

CẬP NHẬT: InSpec 4.x trở lên sử dụng giấy phép thương mại / nguồn mở hỗn hợp - xem ý kiến.

Khi sử dụng các công cụ quản lý cấu hình, như Ansible, chính công cụ đó sẽ chịu trách nhiệm ngăn chặn sự trôi cấu hình. Khi bạn đã sử dụng Ansible để đặt một cấu hình nhất định, việc thực hiện lặp lại Ansible sẽ đảm bảo cấu hình của bạn giống như bạn đã xác định. Điều này cũng yêu cầu mã Ansible của bạn phải được viết theo cách không cần thiết.

Với những điều trên, việc cung cấp thử nghiệm có thể đạt được bằng cách thực hiện các Playbook Ansible của bạn trong một vòng lặp từ một số máy chủ. Ví dụ, một công việc định kỳ, hoặc Jenkins, có thể thực hiện các vở kịch cứ sau 30 phút và báo cáo lại bất kỳ thất bại nào. Không có lỗi có nghĩa là cấu hình của bạn đang được kiểm tra, có lỗi có nghĩa là có vấn đề khi đưa máy chủ vào trạng thái mong muốn của bạn .

Trong trường hợp bạn không thể tin tưởng mã của mình được viết là idempotent và do đó bạn không thể thực sự lặp lại Ansible trong một vòng lặp từ máy chủ tự động tồn tại một cách giải quyết. Bạn có thể làm tương tự như trên (chạy Ansible trong một vòng lặp) nhưng sử dụng chế độ chạy khô của nó . Mỗi lần Ansible báo cáo các thay đổi là bắt buộc, công việc Jenkins (hoặc công việc định kỳ) có thể thông báo cho bạn rằng cấu hình được cung cấp của bạn đã bị thay đổi và máy chủ không ở trạng thái mong muốn .

Để đảm bảo rằng mã Ansible của bạn thực sự đang làm những gì bạn nghĩ nó nên làm, các giải pháp được đề cập bởi Dave Swersky áp dụng. Cả InSpec và Serverspec đều là những công cụ xác minh theo một cách khác mà playbook của bạn thực sự làm theo ý bạn. Một cách tuyệt vời để thực thi các loại công cụ này trong môi trường thử nghiệm (thậm chí cả thùng chứa docker) là sử dụng Kitchen.ci xử lý tất cả keo giữa các công cụ kiểm tra đơn vị khác nhau và thực hiện các sách / mô-đun / sách nấu ăn của bạn.

Kitchen.ci ban đầu được sử dụng để kiểm tra sách dạy nấu ăn Chef, nhưng các plugin cũng tồn tại cho Ansible và các công cụ CM khác.

Test Kitchen có một plugin cung cấp bếp-ansible để kiểm tra mã Ansible. Nó không sâu sắc như tích hợp Chef nhưng nó hoàn thành công việc trong hầu hết các trường hợp. Ngoài ra còn có dự án Molecule gần đây là một hệ thống thử nghiệm Ansible chuyên dụng.

Bạn có thể theo dõi sự khác biệt về cấu hình / cơ sở hạ tầng / trôi dạt bằng Outthentic , thật dễ dàng để tạo một bộ kiểm tra để "sửa" trạng thái mong muốn và chạy lại mỗi khi bạn cần theo dõi các thay đổi không mong muốn.