Cơ sở hạ tầng dưới dạng mã và TDD

Cơ sở hạ tầng dưới dạng mã cho chúng tôi sử dụng các công cụ tự động hóa các bản dựng của bạn. Tuyệt quá. Các công cụ như ansible , đầu bếp , con rối , ngăn xếp muối và những thứ khác thúc đẩy chúng ta hướng tới việc viết cơ sở hạ tầng trông như thế nào, trong khi giải quyết sự khác biệt.

Trong Salt Stack các bit đó được gọi là trạng thái . Nếu trạng thái không phù hợp với thực tế, công cụ sẽ giải quyết nó cho chúng tôi. Nói cách khác - chúng tôi đang viết một bài kiểm tra cho cơ sở hạ tầng của chúng tôi và nếu thử nghiệm thất bại, công cụ sẽ tự sửa nó. Ít nhất đó là ý tưởng.

XP dạy chúng ta sử dụng TDD và câu hỏi là nó có áp dụng được với cơ sở hạ tầng không? Các dụng cụ cho thấy nó là.

Tôi có thể tưởng tượng vài loại bài kiểm tra có thể rất hữu ích.

Chúng tôi viết các bài kiểm tra khói đi kèm với dịch vụ đã triển khai để đảm bảo rằng dịch vụ được triển khai từ đầu đến cuối hoạt động và chạy như mong đợi. Đây sẽ là một lệnh gọi API hoặc / và kiểm tra systemctl để đảm bảo những gì chúng ta vừa triển khai hoạt động. Rất nhiều chức năng này có thể được đề cập trong cùng một trạng thái vì các công cụ như ansible có các trạng thái để đảm bảo dịch vụ đang chạy.

Có phân tử dự án cho phép chạy các vai trò riêng lẻ (như gọi là trạng thái của nó) chống lại docker hoặc một công cụ ảo hóa tạm thời khác. Điều này buộc phải tách rời các vai trò và cho phép thực hiện chúng một cách tách biệt khỏi vở kịch trong khi làm việc với chúng. Các thử nghiệm chủ yếu cho phép chế nhạo các biến mà vai trò được cho là hoạt động. Các ví dụ khác có vẻ như là một bản sao của công cụ ansible (khẳng định một tệp thuộc về người dùng ...).

Radar công nghệ Th thinkWorks ngay bây giờ ca ngợi các công cụ như Inspec , serverpec hoặc goss để xác nhận rằng máy chủ đáp ứng thông số kỹ thuật. Nhưng chúng tôi đang viết một thông số, phải không?

Vì vậy, có một điểm trong thử nghiệm cơ sở hạ tầng nếu chúng ta đang mô tả cơ sở hạ tầng ở các trạng thái / vai trò? Tôi có thể nghi ngờ điều này trở nên bắt buộc hơn trong các tổ chức lớn hơn, nơi một nhóm cung cấp thông số kỹ thuật và các nhóm khác theo sau, hoặc nếu có một nhóm vai trò lớn có thể bạn muốn chạy một tập hợp con trong số đó và nhận được lợi ích tốc độ từ các bài kiểm tra? Tôi đang đấu tranh để xem tại sao bạn sẽ viết một bài kiểm tra nếu bạn có thể có một vai trò / trạng thái cho cùng một câu hỏi trong đầu.

Nói tóm lại, tôi thấy hai loại thử nghiệm cho cơ sở hạ tầng của bạn: 1) nó có mọi thứ bạn cần để chạy ứng dụng của bạn không và 2) nó không có bất kỳ thứ gì thừa thãi.

Trước hết, bạn có thể coi bộ kiểm thử của phần mềm thực tế của mình như một loại "kiểm tra meta" cho cơ sở hạ tầng của bạn. Miễn là bạn tạo cơ sở hạ tầng từ đầu cho mỗi lần chạy thử và bộ kiểm tra chạy hoàn toàn trên cơ sở hạ tầng đó (nghĩa là không sử dụng các dịch vụ bên ngoài), thực tế là toàn bộ bộ phần mềm có nghĩa là cơ sở hạ tầng được mã hóa của bạn cũng đủ .

Thứ hai, đặc biệt là từ góc độ bảo mật, bạn có thể viết các bài kiểm tra đối với cơ sở hạ tầng của mình. Tức là, nếu một phần trong cơ sở hạ tầng của bạn là VM chạy Linux, bạn có thể viết một bài kiểm tra quét cổng với VM đó, để đảm bảo rằng không có cổng nào vô tình mở, có thể đã được cài đặt bởi apt-get installhiệu ứng phụ ngoài ý muốn . Hoặc bạn có thể viết các bài kiểm tra để kiểm tra xem có bất kỳ tệp không mong muốn nào được thay đổi sau khi bộ kiểm tra phù hợp của bạn đã hoàn thành hay không. Hoặc bạn có thể kiểm tra pskết quả đầu ra của máy chứa VM hoặc Docker để biết các quy trình không mong muốn và như vậy, xây dựng danh sách trắng, v.v., và do đó nhận được thông báo tự động nếu một số gói bên thứ 3 thay đổi theo cách không được ghi nhận (hoặc không được chú ý) trong một số nâng cấp.

Theo cách nào đó, các loại thử nghiệm thứ hai này, tương tự như những gì bạn sẽ làm trong cài đặt op cổ điển, nghĩa là, làm cứng máy chủ của bạn và kiểm tra sự xâm nhập, tránh nguồn gốc đầy đủ và như vậy.

IMHO khá dư thừa để viết các bài kiểm tra TDD cho các mục hoàn toàn được quy định trong đặc tả trạng thái IaaC. Làm như vậy ngụ ý rằng tính hiệu quả của IaaC là đáng nghi ngờ - tại sao bạn sẽ sử dụng nó nếu vậy?

Nhìn vào nó từ một IaaC tương lai khác (nếu / khi được thực hiện đúng cách) kết hợp các khả năng đã được kiểm tra và được coi là hoạt động đáng tin cậy. Đó là những gì làm cho nó hấp dẫn và làm cho việc viết các bài kiểm tra khớp TDD trở nên dư thừa.

Ví dụ: cấu hình IaaC chỉ định một hệ thống có SSH được cài đặt đã kết hợp kiểm tra đáng tin cậy để SSH được cài đặt chính xác và, nếu không, các cơ chế để cài đặt đúng hệ thống. Việc kiểm tra TDD để kiểm tra xem SSH có được cài đặt dự phòng không. Nếu cấu hình IaaC của bạn cũng chỉ định sshd sẽ được khởi động và nghe trên một cổng cụ thể thì TDD sẽ kiểm tra sshd chạy và nghe cổng tương ứng cũng sẽ là dự phòng.

Lưu ý rằng câu trả lời của tôi không nhắm mục tiêu TDD hoặc bất kỳ loại thử nghiệm nào khác để kiểm tra xem toàn bộ cấu hình IaaC của bạn có phù hợp với một mục đích nhất định không. Điều đó vẫn còn hiệu lực và có thể được sử dụng trong TDD, CI hoặc các kiểm tra tương tự trong quá trình phát triển đặc tả IaaC đó - Tôi tin rằng câu trả lời của @ AnoE có thể áp dụng trong trường hợp đó.

Có vẻ như mọi người ở đây đều cho rằng một công cụ IAC luôn chạy như mong đợi, nhưng tôi có thể nói (từ kinh nghiệm của bản thân mình) điều này không phải lúc nào cũng vậy, nếu không thì kiểm tra đơn vị sẽ thực sự vô dụng.

Tôi nhớ một bức ảnh có nội dung "Ansible playbook đã chạy, mọi thứ đều ổn" với một tòa nhà đang cháy ở phía sau ...

Chạy một trạng thái khai báo và có máy chủ ở trạng thái khai báo thực tế này là 2 điều khác nhau theo quan điểm và kinh nghiệm của tôi ít nhất.

Một môi trường rộng lớn và không đồng nhất, trải rộng trên nhiều DC, có thể truy cập thông qua mạng công cộng, v.v ... Có nhiều lý do mà một trạng thái không thể được áp dụng, hoàn toàn hoặc một phần.

Vì tất cả những lý do này, có chỗ để kiểm tra đơn vị cho phép một người có được ảnh chụp nhanh về trạng thái máy chủ thực tế, một lần nữa, có thể khác với trạng thái được nhắm.

Vì vậy, tôi muốn nói có, kiểm tra đơn vị rất hữu ích ngay cả trong môi trường được quản lý IAC.

BIÊN TẬP

Điều gì về phía không hồi quy của nhánh dev của cơ sở mã IaC? Vì vậy, bạn sẽ thay đổi mã của mình trong nhánh dev và hợp nhất nó với nhánh prod với hy vọng không phá vỡ mọi thứ? kiểm tra đơn vị rất có giá trị và thường đơn giản để thực hiện Tôi không hiểu tại sao người ta sẽ viết mã mà không có tính năng này.

Tham khảo (bằng tiếng Pháp xin lỗi vì điều đó): https://fr.sl slideshoware.net/logilab/testinfra-pyconfr-2017

Theo kinh nghiệm của tôi, một trong những khác biệt chính giữa Dev và Ops là "sự phụ thuộc thời gian nặng nề". Việc cài đặt các gói phụ thuộc rất nhiều vào kho lưu trữ, mạng hoặc khóa hợp lệ hoặc giả sử khởi tạo một máy chủ đám mây mới - tùy thuộc vào tài nguyên nhà cung cấp của bạn.

Về mặt cung cấp máy chủ ngay cả khi bạn không thay đổi mã cung cấp, hình ảnh của bạn sẽ có hiệu lực trong hầu hết các lần nhưng đôi khi thì không. Vì vậy, tôi nghĩ rằng thử nghiệm là thực sự cần thiết để cung cấp hình ảnh làm việc.

Nếu bạn đi máy chủ đơn lẻ, mọi thứ thậm chí còn tệ hơn ... làm thế nào bạn sẽ kiểm tra khả năng tiếp cận trong toàn bộ thiết lập mạng? Bao gồm độ phân giải DNS, định tuyến và tường lửa? Ngay cả khi API nhà cung cấp IaaC của bạn hoạt động như mong đợi (Tôi đã thấy các sự cố có dây trong lĩnh vực này) Tôi thực sự thích TDD trong trường hợp này.

Vì tôi không tìm thấy bất kỳ công cụ kiểm tra nào trong lĩnh vực này, chúng tôi đã viết một công cụ trong thời gian rảnh: https://github.com/DomainDrivenArch architecture / dda -serverspec- crate

Vì vậy, tôi nghĩ TDD thực sự quan trọng trong thế giới DevOps!