Tôi đã sử dụng con rối để triển khai cơ sở hạ tầng và hầu hết công việc tôi làm là với các công ty Web 2.0, những người rất muốn phát triển dựa trên thử nghiệm cho ứng dụng web của họ. Có ai ở đây sử dụng một cách tiếp cận dựa trên thử nghiệm để phát triển cấu hình máy chủ của họ không? Những công cụ nào bạn sử dụng để làm điều này? Làm thế nào sâu thử nghiệm của bạn đi?
Câu trả lời:
Tôi không nghĩ rằng bạn có thể sử dụng phát triển dựa trên thử nghiệm . Nhưng bạn chắc chắn có thể thử kiểm tra đơn vị trên các máy chủ mới.
Về cơ bản, bạn sẽ cần triển khai các máy chủ, khởi động các dịch vụ ở chế độ thử nghiệm và sau đó chạy thử nghiệm từ một máy chủ khác (hoặc loạt máy chủ) đối với các dịch vụ. Sau đó cuối cùng đưa chúng vào sản xuất.
Có thể sử dụng tập lệnh python để kết nối với cơ sở dữ liệu, trang web và dịch vụ ssh. Và sau đó trả lại PASS / FAIL. Sẽ là một khởi đầu tốt cho bạn.
Hoặc bạn có thể đưa nó vào một giải pháp giám sát, như Zenoss, Nagios hoặc Munin. Sau đó, bạn có thể kiểm tra, trong quá trình triển khai; Và theo dõi trong quá trình sản xuất.
Tôi nghĩ Joseph Kern đang đi đúng hướng với các công cụ giám sát. Chu trình TDD điển hình là: viết một bài kiểm tra mới thất bại, sau đó cập nhật hệ thống để tất cả các bài kiểm tra hiện có vượt qua. Điều này sẽ dễ dàng thích ứng với Nagios: thêm kiểm tra không thành công, định cấu hình máy chủ, chạy lại tất cả các kiểm tra. Nghĩ về nó, đôi khi tôi đã làm chính xác điều này.
Nếu bạn muốn có được cốt lõi thực sự, bạn sẽ đảm bảo viết các tập lệnh để kiểm tra mọi khía cạnh liên quan của cấu hình máy chủ. Một hệ thống giám sát như Nagios có thể không phù hợp với một số trong số họ (ví dụ: bạn có thể không "giám sát" phiên bản HĐH của mình), nhưng không có lý do gì bạn không thể kết hợp phù hợp.
Mặc dù tôi chưa thể thực hiện TDD với các biểu hiện rối, chúng tôi có một chu kỳ khá tốt để ngăn chặn các thay đổi đi vào sản xuất mà không cần thử nghiệm. Chúng tôi có hai nghệ sĩ múa rối được thành lập, một người là nghệ sĩ múa rối sản xuất và người còn lại là nghệ sĩ múa rối phát triển của chúng tôi. Chúng tôi sử dụng "môi trường" của Puppet để thiết lập các mục sau:
Các nhà phát triển ứng dụng của chúng tôi thực hiện công việc của họ trên các máy ảo có cấu hình Puppet từ môi trường "thử nghiệm" của Puppetmaster. Khi chúng tôi đang phát triển các biểu hiện rối, chúng tôi thường thiết lập VM để phục vụ như một máy khách thử nghiệm trong quá trình phát triển và hướng nó vào môi trường phát triển cá nhân của chúng tôi. Khi chúng tôi hài lòng với bảng kê khai của mình, chúng tôi đẩy chúng vào môi trường thử nghiệm nơi các nhà phát triển ứng dụng sẽ nhận được các thay đổi trên máy ảo của họ - họ thường phàn nàn lớn khi có sự cố xảy ra :-)
Trên một tập hợp con đại diện của các máy sản xuất của chúng tôi, có một con rối thứ hai chạy ở chế độ noop và chỉ vào môi trường thử nghiệm. Chúng tôi sử dụng điều này để nắm bắt các vấn đề tiềm ẩn với các biểu hiện trước khi chúng được đẩy vào sản xuất.
Khi các thay đổi đã qua, tức là chúng không phá vỡ các máy của nhà phát triển ứng dụng và chúng không tạo ra đầu ra không mong muốn trong nhật ký của quy trình bù nhìn "noop" của máy sản xuất, chúng tôi đẩy các biểu hiện mới vào sản xuất. Chúng tôi có một cơ chế rollback tại chỗ để chúng tôi có thể trở lại phiên bản trước đó.
Tôi đã làm việc trong một môi trường đang trong quá trình chuyển đổi sang mô hình hoạt động TDD. Đối với một số thứ như kịch bản giám sát điều này làm việc rất tốt. Chúng tôi đã sử dụng buildbot để thiết lập môi trường thử nghiệm và chạy thử nghiệm. Trong trường hợp này, bạn tiếp cận TDD từ góc độ "Mã kế thừa". Trong TDD "Mã kế thừa" là mã hiện có không có kiểm tra. Vì vậy, các thử nghiệm đầu tiên không thất bại, chúng xác định hoạt động chính xác (hoặc dự kiến).
Đối với nhiều công việc cấu hình, bước đầu tiên là kiểm tra xem cấu hình có thể được phân tích cú pháp bởi dịch vụ hay không. Nhiều dịch vụ cung cấp một số cơ sở để làm việc này. Nagios có chế độ preflight, cfagent không có hành động, apache, sudo, bind và nhiều thứ khác có các phương tiện tương tự. Điều này về cơ bản là một lint chạy cho các cấu hình.
Một ví dụ sẽ là nếu bạn sử dụng apache và các tệp cấu hình riêng biệt cho các phần khác nhau, bạn có thể kiểm tra các phần cũng như chỉ sử dụng tệp httpd.conf khác để bọc chúng để chạy trên máy thử nghiệm của bạn. Sau đó, bạn có thể kiểm tra rằng máy chủ web trên máy kiểm tra cho kết quả chính xác ở đó.
Mỗi bước trên đường bạn đi theo cùng một mô hình cơ bản. Viết một bài kiểm tra, thực hiện bài kiểm tra, tái cấu trúc công việc bạn đã thực hiện. Như đã đề cập ở trên, khi đi theo con đường này, các bài kiểm tra có thể không phải lúc nào cũng thất bại theo cách TDD được chấp nhận.
Rik
Tôi tin rằng các liên kết sau đây có thể được quan tâm
cucumber-nagios - dự án cho phép bạn biến bộ Cucumber của mình thành plugin Nagios và đi kèm với các định nghĩa bước cho SSH, DNS, Ping, AMQP và các loại nhiệm vụ "thực thi lệnh" chung
http://auxesis.github.com/cucumber- nagios /
http://www.sl
slideshoware.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224 http://agilesysadmin.net/cucumber-nagios
Ngoài ra còn có một số nỗ lực về phía Puppet / Python của mọi thứ http://www.devco.net/archives/2010/03/27/infr kia_testing_with_mcollective_and_cucumber.php