Cách tiếp cận IaC (Cơ sở hạ tầng dưới dạng mã) không chỉ bao gồm mã được lưu trữ trong kho lưu trữ mà còn bao gồm con người và quy trình xung quanh mã này. Có thể sử dụng lại các phương pháp tiếp cận từ phát triển phần mềm đến quản lý và mô tả cơ sở hạ tầng không? Sẽ là một ý tưởng tốt nếu bạn ghi nhớ ý tưởng này khi đọc bài viết.

Đây là bản ghi của tôi biểu diễn trên DevopsConf 2019-05-28.

Trang trình bày và video

phiên bản Angielski
Phiên bản tiếng Nga
Chạy thử 2019-04-24 spbLUG
Video(RU) từ DevopsConf 2019-05-28
Video(RU) từ DINS DevOps BUỔI TỐI 2019-06-20
Slides

Cơ sở hạ tầng như lịch sử bash

Giả sử bạn đến với một dự án mới và họ nói với bạn: “chúng tôi có Cơ sở hạ tầng như Mã". Trên thực tế hóa ra Cơ sở hạ tầng như lịch sử bash hoặc ví dụ Tài liệu dưới dạng lịch sử bash. Đây là một tình huống rất thực tế, ví dụ, một trường hợp tương tự đã được Denis Lysenko mô tả trong một bài phát biểu Làm thế nào để thay thế toàn bộ cơ sở hạ tầng và bắt đầu ngủ yên, anh ấy kể về cách họ có được cơ sở hạ tầng mạch lạc cho dự án từ lịch sử bash.

Với một chút mong muốn, chúng ta có thể nói rằng Cơ sở hạ tầng như lịch sử bash cái này giống như mã:

Khả năng tái lập: Bạn có thể lấy lịch sử bash, chạy các lệnh từ đó và nhân tiện, bạn có thể lấy một cấu hình hoạt động làm đầu ra.
phiên bản: bạn biết ai đã đến và họ đã làm gì, một lần nữa, thực tế không phải là điều này sẽ dẫn bạn đến cấu hình hoạt động ở lối ra.
lịch sử: câu chuyện về ai đã làm gì. chỉ có điều bạn sẽ không thể sử dụng nó nếu mất máy chủ.

Phải làm gì?

Cơ sở hạ tầng như Mã

Ngay cả một trường hợp kỳ lạ như Cơ sở hạ tầng như lịch sử bash bạn có thể kéo nó bằng tai Cơ sở hạ tầng như Mã, nhưng khi chúng ta muốn làm điều gì đó phức tạp hơn máy chủ LAMP cũ tốt, chúng ta sẽ đi đến kết luận rằng mã này cần phải được sửa đổi, thay đổi, cải thiện bằng cách nào đó. Tiếp theo chúng ta muốn xem xét sự tương đồng giữa Cơ sở hạ tầng như Mã và phát triển phần mềm.

KHÔ

Trong một dự án phát triển hệ thống lưu trữ có một nhiệm vụ con định cấu hình SDS định kỳ: chúng tôi đang phát hành một bản phát hành mới - nó cần được triển khai để thử nghiệm thêm. Nhiệm vụ cực kỳ đơn giản:

đăng nhập vào đây qua ssh và thực hiện lệnh.
sao chép tập tin ở đó.
sửa cấu hình ở đây.
bắt đầu dịch vụ ở đó
...
LỢI NHUẬN!

Đối với logic được mô tả, bash là quá đủ, đặc biệt là trong giai đoạn đầu của dự án, khi nó mới bắt đầu. Cái này không tệ khi bạn sử dụng bash, nhưng theo thời gian, có những yêu cầu triển khai thứ gì đó tương tự nhưng hơi khác một chút. Điều đầu tiên bạn nghĩ đến là sao chép-dán. Và bây giờ chúng tôi đã có hai tập lệnh rất giống nhau và thực hiện hầu hết các công việc giống nhau. Theo thời gian, số lượng tập lệnh ngày càng tăng và chúng tôi phải đối mặt với thực tế là có một logic nghiệp vụ nhất định để triển khai cài đặt cần được đồng bộ hóa giữa các tập lệnh khác nhau, điều này khá phức tạp.

Hóa ra có một phương pháp như DRY (Đừng lặp lại chính mình). Ý tưởng là sử dụng lại mã hiện có. Nghe có vẻ đơn giản nhưng chúng ta chưa đi đến vấn đề này ngay lập tức. Trong trường hợp của chúng tôi, đó là một ý tưởng tầm thường: tách cấu hình khỏi tập lệnh. Những thứ kia. logic nghiệp vụ về cách cài đặt được triển khai riêng biệt, cấu hình riêng biệt.

RẮN cho CFM

Theo thời gian dự án đã phát triển và sự tiếp diễn tự nhiên là sự xuất hiện của Ansible. Lý do chính cho sự xuất hiện của nó là có chuyên môn trong nhóm và bash đó không được thiết kế cho logic phức tạp. Ansible cũng bắt đầu chứa logic phức tạp. Để ngăn logic phức tạp trở nên hỗn loạn, có những nguyên tắc tổ chức mã trong phát triển phần mềm CHẤT RẮN Ngoài ra, chẳng hạn, Grigory Petrov trong báo cáo “Tại sao một chuyên gia CNTT cần một thương hiệu cá nhân” đã đặt ra câu hỏi rằng một người được thiết kế sao cho anh ta dễ dàng hoạt động hơn với một số thực thể xã hội, trong quá trình phát triển phần mềm, những thực thể này là những đồ vật Nếu chúng ta kết hợp hai ý tưởng này và tiếp tục phát triển chúng, chúng ta sẽ nhận thấy rằng chúng ta cũng có thể sử dụng CHẤT RẮN để giúp việc duy trì và sửa đổi logic này dễ dàng hơn trong tương lai.

Nguyên tắc trách nhiệm duy nhất

Mỗi lớp chỉ thực hiện một nhiệm vụ.

Không cần phải trộn mã và tạo ra những con quái vật spaghetti thần thánh nguyên khối. Cơ sở hạ tầng nên bao gồm những viên gạch đơn giản. Hóa ra nếu bạn chia playbook Ansible thành nhiều phần nhỏ, đọc các vai trò của Ansible thì chúng sẽ dễ bảo trì hơn.

Nguyên tắc Mở Đóng

Nguyên lý đóng/mở.

Mở rộng: có nghĩa là hành vi của một thực thể có thể được mở rộng bằng cách tạo các loại thực thể mới.
Đóng để thay đổi: Do việc mở rộng hành vi của một thực thể, không nên thực hiện thay đổi nào đối với mã sử dụng các thực thể đó.

Ban đầu, chúng tôi đã triển khai cơ sở hạ tầng thử nghiệm trên các máy ảo, nhưng do logic kinh doanh của việc triển khai tách biệt với quá trình triển khai nên chúng tôi đã thêm việc triển khai sang baremetall mà không gặp bất kỳ sự cố nào.

Nguyên lý thay thế Liskov

Nguyên lý thay thế của Barbara Liskov. các đối tượng trong một chương trình phải có thể thay thế được bằng các thể hiện của kiểu con của chúng mà không làm thay đổi cách thực thi chính xác của chương trình

Nếu nhìn rộng hơn thì đó không phải là đặc điểm của bất kỳ dự án cụ thể nào có thể áp dụng được ở đó CHẤT RẮN, nói chung là về CFM, chẳng hạn, trong một dự án khác, cần phải triển khai một ứng dụng Java đóng hộp trên nhiều Java, máy chủ ứng dụng, cơ sở dữ liệu, HĐH, v.v. Sử dụng ví dụ này, tôi sẽ xem xét thêm các nguyên tắc CHẤT RẮN

Trong trường hợp của chúng tôi, có một thỏa thuận trong nhóm cơ sở hạ tầng rằng nếu chúng tôi đã cài đặt vai trò imbjava hoặc oraclejava thì chúng tôi sẽ có một tệp thực thi nhị phân java. Điều này là cần thiết bởi vì Các vai trò thượng nguồn phụ thuộc vào hành vi này; họ mong đợi java. Đồng thời, điều này cho phép chúng tôi thay thế một phiên bản/triển khai java này bằng một phiên bản/triển khai java khác mà không thay đổi logic triển khai ứng dụng.

Vấn đề ở đây nằm ở chỗ không thể triển khai điều này trong Ansible, do đó một số thỏa thuận xuất hiện trong nhóm.

Nguyên tắc phân tách giao diện

Nguyên tắc tách biệt giao diện: “Nhiều giao diện dành riêng cho khách hàng sẽ tốt hơn một giao diện có mục đích chung.

Ban đầu, chúng tôi đã cố gắng đưa tất cả các biến thể của việc triển khai ứng dụng vào một Playbook Ansible, nhưng rất khó hỗ trợ và cách tiếp cận khi chúng tôi có giao diện bên ngoài được chỉ định (khách hàng mong đợi cổng 443), thì cơ sở hạ tầng có thể được lắp ráp từ từng cá nhân. brick để thực hiện cụ thể.

Nguyên tắc đảo ngược phụ thuộc

Nguyên tắc đảo ngược phụ thuộc. Các mô-đun ở cấp độ cao hơn không nên phụ thuộc vào các mô-đun ở cấp độ thấp hơn. Cả hai loại mô-đun phải phụ thuộc vào sự trừu tượng. Sự trừu tượng không nên phụ thuộc vào chi tiết. Chi tiết phải phụ thuộc vào sự trừu tượng.

Ở đây ví dụ sẽ dựa trên một mẫu phản mẫu.

Một trong những khách hàng đã có một đám mây riêng.
Chúng tôi đã đặt hàng các máy ảo bên trong đám mây.
Nhưng do tính chất của đám mây, việc triển khai ứng dụng bị ràng buộc với trình ảo hóa máy ảo đang chạy.

Những thứ kia. Logic triển khai ứng dụng cấp cao cùng với các phần phụ thuộc được chuyển sang các cấp độ thấp hơn của bộ điều khiển ảo hóa và điều này có nghĩa là sẽ có vấn đề khi sử dụng lại logic này. Không được làm như thế.

Tương tác

Cơ sở hạ tầng dưới dạng mã không chỉ là mã mà còn là mối quan hệ giữa mã và con người, về sự tương tác giữa các nhà phát triển cơ sở hạ tầng.

Yếu tố xe buýt

Giả sử rằng bạn có Vasya trong dự án của mình. Vasya biết mọi thứ về cơ sở hạ tầng của bạn, điều gì sẽ xảy ra nếu Vasya đột nhiên biến mất? Đây là một tình huống rất thực tế, vì anh ấy có thể bị xe buýt đâm. Đôi khi nó xảy ra. Nếu điều này xảy ra và kiến thức về mã, cấu trúc, cách thức hoạt động, hình thức và mật khẩu không được phân bổ trong nhóm thì bạn có thể gặp phải một số tình huống khó chịu. Để giảm thiểu những rủi ro này và phân phối kiến thức trong nhóm, bạn có thể sử dụng nhiều phương pháp khác nhau

Ghép đôi

Nó không thích như một trò đùa, rằng quản trị viên đã uống bia, thay đổi mật khẩu và tương tự như lập trình cặp đôi. Những thứ kia. hai kỹ sư ngồi xuống một máy tính, một bàn phím và bắt đầu cùng nhau thiết lập cơ sở hạ tầng của bạn: thiết lập máy chủ, viết vai trò Ansible, v.v. Nghe có vẻ hay đấy, nhưng nó không có tác dụng với chúng tôi. Nhưng những trường hợp đặc biệt của phương pháp này đã có tác dụng. Một nhân viên mới đến, người cố vấn của anh ta cùng anh ta đảm nhận một nhiệm vụ thực sự, làm việc và truyền đạt kiến thức.

Một trường hợp đặc biệt khác là cuộc gọi sự cố. Trong một vấn đề, một nhóm những người đang làm nhiệm vụ và những người liên quan tập hợp lại, một người lãnh đạo được chỉ định, người này chia sẻ quan điểm của mình và lên tiếng về luồng suy nghĩ. Những người tham gia khác theo dõi suy nghĩ của người lãnh đạo, theo dõi các thủ thuật từ bảng điều khiển, kiểm tra xem họ có bỏ sót dòng nào trong nhật ký hay không và tìm hiểu những điều mới về hệ thống. Cách tiếp cận này hiệu quả thường xuyên hơn không.

Đánh giá mã

Về mặt chủ quan, việc phổ biến kiến thức về cơ sở hạ tầng và cách thức hoạt động của cơ sở hạ tầng bằng cách sử dụng đánh giá mã sẽ hiệu quả hơn:

Cơ sở hạ tầng được mô tả bằng mã trong kho lưu trữ.
Những thay đổi xảy ra trong một nhánh riêng biệt.
Trong yêu cầu hợp nhất, bạn có thể thấy mức độ thay đổi trong cơ sở hạ tầng.

Điểm nổi bật ở đây là những người đánh giá được chọn từng người một, theo một lịch trình, tức là. với một mức độ xác suất nào đó, bạn sẽ leo lên một phần cơ sở hạ tầng mới.

Kiểu mã

Theo thời gian, những tranh cãi bắt đầu xuất hiện trong quá trình đánh giá, bởi vì... người đánh giá có phong cách riêng của họ và việc luân chuyển người đánh giá xếp chúng theo các kiểu khác nhau: 2 dấu cách hoặc 4, CamelCase hoặc snake_case. Không thể thực hiện điều này ngay lập tức.

Ý tưởng đầu tiên là khuyên bạn nên sử dụng kẻ nói dối, xét cho cùng, mọi người đều là kỹ sư, mọi người đều thông minh. Nhưng các trình soạn thảo, hệ điều hành khác nhau không thuận tiện
Điều này đã phát triển thành một bot viết thư để xử lý từng cam kết có vấn đề và đính kèm đầu ra nói dối. Nhưng trong hầu hết các trường hợp, có nhiều việc quan trọng hơn phải làm và mã vẫn chưa được sửa.

Bậc thầy xây dựng xanh

Thời gian trôi qua và chúng tôi đi đến kết luận rằng những cam kết không vượt qua một số bài kiểm tra nhất định sẽ không được phép vào bản gốc. Thì đấy! Chúng tôi đã phát minh ra Green Build Master, giải pháp đã được áp dụng từ lâu trong phát triển phần mềm:

Sự phát triển đang được tiến hành trong một chi nhánh riêng biệt.
Các thử nghiệm đang chạy trên chủ đề này.
Nếu kiểm tra thất bại, mã sẽ không được đưa vào bản gốc.

Đưa ra quyết định này rất đau đớn, bởi vì... gây ra rất nhiều tranh cãi, nhưng nó đáng giá, bởi vì... Các bài đánh giá bắt đầu nhận được yêu cầu sáp nhập mà không có sự khác biệt về phong cách và theo thời gian, số lượng các vấn đề bắt đầu giảm đi.

Kiểm tra IaC

Ngoài việc kiểm tra kiểu, bạn có thể sử dụng những thứ khác, chẳng hạn như để kiểm tra xem cơ sở hạ tầng của bạn có thực sự có thể triển khai hay không. Hoặc kiểm tra xem những thay đổi về cơ sở hạ tầng có dẫn đến mất tiền hay không. Tại sao điều này có thể cần thiết? Câu hỏi rất phức tạp và mang tính triết học, tốt hơn hết bạn nên trả lời bằng một câu chuyện rằng bằng cách nào đó có một trình tự động mở rộng quy mô trên Powershell không kiểm tra các điều kiện biên => nhiều máy ảo được tạo ra hơn mức cần thiết => khách hàng đã chi nhiều tiền hơn dự định. Điều này không mấy dễ chịu nhưng hoàn toàn có thể mắc phải lỗi này ở giai đoạn trước.

Người ta có thể hỏi, tại sao lại làm cho cơ sở hạ tầng phức tạp trở nên phức tạp hơn? Kiểm tra cơ sở hạ tầng, giống như kiểm tra mã, không nhằm mục đích đơn giản hóa mà là để biết cơ sở hạ tầng của bạn sẽ hoạt động như thế nào.

Kim tự tháp thử nghiệm IaC

Kiểm tra IaC: Phân tích tĩnh

Nếu bạn triển khai toàn bộ cơ sở hạ tầng cùng một lúc và kiểm tra xem nó có hoạt động hay không, bạn có thể thấy rằng việc này tốn rất nhiều thời gian và đòi hỏi nhiều thời gian. Vì vậy, cơ sở phải là thứ gì đó hoạt động nhanh chóng, có rất nhiều và bao gồm rất nhiều chỗ nguyên thủy.

Bash thật khó khăn

Hãy xem xét một ví dụ tầm thường. chọn tất cả các tệp trong thư mục hiện tại và sao chép sang vị trí khác. Điều đầu tiên tôi nghĩ đến:

for i in * ; do 
    cp $i /some/path/$i.bak
done

Điều gì sẽ xảy ra nếu có khoảng trắng trong tên tệp? Được rồi, chúng tôi thông minh, chúng tôi biết cách sử dụng dấu ngoặc kép:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

Làm tốt? KHÔNG! Điều gì sẽ xảy ra nếu không có gì trong thư mục, tức là. toàn cầu hóa sẽ không hoạt động.

find . -type f -exec mv -v {} dst/{}.bak ;

Bây giờ làm tốt chưa? Không... Quên nội dung có thể có trong tên tệp n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

Công cụ phân tích tĩnh

Vấn đề ở bước trước có thể được phát hiện khi chúng ta quên dấu ngoặc kép, vì vấn đề này về bản chất có rất nhiều biện pháp khắc phục Kiểm tra vỏ, nói chung là có rất nhiều trong số chúng và rất có thể bạn có thể tìm thấy kẻ nói dối cho ngăn xếp của mình trong IDE.

Ngôn ngữ
Công cụ

bash
Kiểm tra vỏ

hồng ngọc
RuboCop

mãng xà
lửa thiêu

ansible
Ansible Lint

Kiểm tra IaC: Kiểm tra đơn vị

Như chúng ta đã thấy từ ví dụ trước, linters không phải là người toàn năng và không thể chỉ ra tất cả các vấn đề. Hơn nữa, bằng cách tương tự với thử nghiệm trong phát triển phần mềm, chúng ta có thể nhớ lại các thử nghiệm đơn vị. Điều bạn nghĩ ngay đến là shunt, quân đội, thông số kỹ thuật, người khó tính. Nhưng phải làm gì với ansible, Chef, Saltstack và những thứ tương tự như vậy?

Lúc đầu chúng tôi đã nói về CHẤT RẮN và cơ sở hạ tầng của chúng ta nên bao gồm những viên gạch nhỏ. Thời của họ đã đến.

Cơ sở hạ tầng được chia thành các khối nhỏ, ví dụ như các vai trò Ansible.
Một số loại môi trường được triển khai, có thể là docker hoặc VM.
Chúng tôi áp dụng vai trò Ansible của mình cho môi trường thử nghiệm này.
Chúng tôi kiểm tra xem mọi thứ có hoạt động như chúng tôi mong đợi không (chúng tôi chạy thử nghiệm).
Chúng tôi quyết định ổn hay không ổn.

Kiểm tra IaC: Công cụ kiểm tra đơn vị

Câu hỏi, các bài kiểm tra CFM là gì? Bạn có thể chỉ cần chạy tập lệnh hoặc có thể sử dụng các giải pháp có sẵn cho việc này:

Quản lý rừng cộng đồng
Công cụ

Có khả năng
thử nghiệm

Đầu bếp
kiểm tra

Đầu bếp
Thông số máy chủ

bao muối
chuyện tầm phào

Ví dụ về testinfra, kiểm tra xem người dùng test1, test2 tồn tại và ở trong một nhóm sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

Chọn cái gì? Câu hỏi phức tạp và mơ hồ, đây là ví dụ về những thay đổi trong các dự án trên github cho năm 2018-2019:

Khung kiểm tra IaC

Câu hỏi đặt ra: làm thế nào để kết hợp tất cả lại với nhau và khởi động nó? Có thể lấy nó và tự làm nếu có đủ số lượng kỹ sư. Hoặc bạn có thể sử dụng các giải pháp làm sẵn, mặc dù số lượng giải pháp đó không nhiều:

Quản lý rừng cộng đồng
Công cụ

Có khả năng
Phân tử

Đầu bếp
Nhà bếp thử nghiệm

Terraform
Khủng khiếp nhất

Ví dụ về những thay đổi trong dự án trên github năm 2018-2019:

Phân tử vs. Bếp thử nghiệm

Ban đầu chúng tôi đã thử sử dụng testkitchen:

Tạo một VM song song.
Áp dụng vai trò Ansible.
Chạy kiểm tra.

Đối với 25-35 vai trò, thời gian làm việc là 40-70 phút, một khoảng thời gian dài.

Bước tiếp theo là chuyển sang jenkins/docker/ansible/molecule. Về mặt tư tưởng thì mọi thứ đều giống nhau

Sách hướng dẫn Lint.
Sắp xếp các vai trò.
Khởi động vùng chứa
Áp dụng vai trò Ansible.
Chạy testinfra.
Kiểm tra tính bình thường.

Lining cho 40 vai trò và kiểm tra hàng chục vai trò bắt đầu mất khoảng 15 phút.

Việc chọn gì phụ thuộc vào nhiều yếu tố, chẳng hạn như ngăn xếp được sử dụng, chuyên môn trong nhóm, v.v. ở đây mọi người tự quyết định cách đóng câu hỏi Unit test

Kiểm tra IaC: Kiểm tra tích hợp

Bước tiếp theo trong kim tự tháp thử nghiệm cơ sở hạ tầng sẽ là thử nghiệm tích hợp. Chúng tương tự như các bài kiểm tra Đơn vị:

Cơ sở hạ tầng được chia thành các khối nhỏ, ví dụ như các vai trò Ansible.
Một số loại môi trường được triển khai, có thể là docker hoặc VM.
Đối với môi trường thử nghiệm này, hãy áp dụng nhiều Vai trò ansible.
Chúng tôi kiểm tra xem mọi thứ có hoạt động như chúng tôi mong đợi không (chúng tôi chạy thử nghiệm).
Chúng tôi quyết định ổn hay không ổn.

Nói một cách đại khái, chúng tôi không kiểm tra hiệu suất của một thành phần riêng lẻ của hệ thống như trong các thử nghiệm đơn vị, chúng tôi kiểm tra cách cấu hình toàn bộ máy chủ.

Kiểm tra IaC: Kiểm tra từ đầu đến cuối

Ở đỉnh kim tự tháp, chúng ta được chào đón bởi các bài kiểm tra End to End. Những thứ kia. Chúng tôi không kiểm tra hiệu suất của một máy chủ riêng biệt, một tập lệnh riêng biệt hoặc một khối cơ sở hạ tầng riêng biệt của chúng tôi. Chúng tôi kiểm tra xem có nhiều máy chủ được kết nối với nhau không, cơ sở hạ tầng của chúng tôi có hoạt động như chúng tôi mong đợi hay không. Thật không may, tôi chưa bao giờ thấy các giải pháp đóng hộp làm sẵn, có lẽ bởi vì... Cơ sở hạ tầng thường độc đáo và khó tạo khuôn mẫu cũng như tạo khuôn khổ để thử nghiệm. Kết quả là mọi người đều tạo ra giải pháp của riêng mình. Có yêu cầu nhưng không có câu trả lời. Vì vậy, tôi sẽ cho bạn biết có những gì để thúc đẩy người khác phát ra những suy nghĩ hoặc xoa mũi tôi vì thực tế là mọi thứ đã được phát minh ra từ rất lâu trước chúng ta.

Một dự án có bề dày lịch sử. Nó được sử dụng trong các tổ chức lớn và có lẽ mỗi bạn đã gián tiếp sử dụng nó. Ứng dụng hỗ trợ nhiều cơ sở dữ liệu, tích hợp, v.v. Biết cơ sở hạ tầng trông như thế nào là rất nhiều tệp soạn thảo docker và biết thử nghiệm nào sẽ chạy trong môi trường nào là Jenkins.

Kế hoạch này đã hoạt động trong một thời gian khá dài, cho đến khi trong khuôn khổ nghiên cứu chúng tôi chưa thử chuyển cái này sang Openshift. Các thùng chứa vẫn giữ nguyên, nhưng môi trường khởi chạy đã thay đổi (xin chào lại DRY).

Ý tưởng nghiên cứu đã đi xa hơn và trong openshift, họ đã tìm thấy một thứ như APB (Ansible Playbook Bundle), cho phép bạn gói gọn kiến thức về cách triển khai cơ sở hạ tầng vào một vùng chứa. Những thứ kia. có một điểm kiến thức có thể lặp lại, có thể kiểm tra được về cách triển khai cơ sở hạ tầng.

Tất cả điều này nghe có vẻ ổn cho đến khi chúng tôi gặp phải một cơ sở hạ tầng không đồng nhất: chúng tôi cần Windows để thử nghiệm. Kết quả là kiến thức về cái gì, ở đâu, cách triển khai và kiểm tra đều có trong jenkins.

Kết luận

Cơ sở hạ tầng như Mã là

Mã trong kho lưu trữ.
Sự tương tác của con người.
Thử nghiệm cơ sở hạ tầng.

liên kết

Nguồn: www.habr.com

Tôi học được gì từ việc thử nghiệm 200 dòng mã cơ sở hạ tầng