Các công cụ quản lý cấu hình có thích hợp để sử dụng làm công cụ triển khai không?

Tắt câu trả lời của tôi cho câu hỏi: Làm thế nào DevOps có thể giúp cải thiện thủ tục Ký quỹ phần mềm? Tensibai có câu hỏi:

Điều gì sẽ cần Capistrano trên đầu của con rối hoặc đầu bếp?

Câu trả lời của tôi là đăng một liên kết đến bài viết của Noah Gibbs "Chúng ta có cần cả Capistrano và Chef không?" . Cá nhân, tôi vẫn đăng ký với chế độ xem của Nô-ê rằng nó phù hợp nhất với:

• sử dụng một công cụ triển khai chuyên gia như Capistrano để triển khai.
• sử dụng một công cụ quản lý cấu hình chuyên gia như Chef để quản lý cấu hình.

Cách tiếp cận cơ bản mà mỗi loại công cụ sử dụng để hoàn thành nhiệm vụ của nó rất khác nhau:

• Các công cụ quản lý cấu hình - là về việc tạo và duy trì trạng thái mong muốn của một hệ thống, về bản chất chúng là tạm thời. Ví dụ về các công cụ quản lý cấu hình là Chef , Puppet , Ansible , PowerShell DSC , Salt Stack .

• Công cụ triển khai - là về việc cung cấp các phiên bản phần mềm vào môi trường lưu trữ, chúng cung cấp chức năng để duy trì nhiều phiên bản phần mềm trên nhiều máy và quản lý phiên bản nào là "hiện tại", về bản chất chúng là bắt buộc. Ví dụ về các công cụ triển khai là Capistrano , Octopus Deploy , Deployer và Command.io .

Tôi tin rằng Công cụ quản lý cấu hình có thể thực hiện công việc của các công cụ triển khai và trong trường hợp Cơ sở hạ tầng không thay đổi, chúng là công cụ thích hợp nhất cho công việc vì các phiên bản phần mềm trên mục tiêu không cần phải duy trì.

Câu hỏi: Các công cụ quản lý cấu hình như Chef, Ansible và Puppet đã trưởng thành đến mức chúng có khả năng đáp ứng cả các mô hình idempotent và mệnh lệnh?

Trong bối cảnh như vậy, lời khuyên điển hình nên được áp dụng ngay lập tức: sử dụng công cụ phù hợp cho công việc.

Nhưng sau đó, bạn cũng không thể bỏ qua xu hướng gần như độc hại của các công cụ phần mềm để mở rộng chức năng vào các lĩnh vực liên quan ít nhiều và thực sự trở thành bộ công cụ vì nhiều lý do: tính năng tuyệt vời để có, mở rộng cơ sở khách hàng, tăng thêm doanh thu, v.v.

Ví dụ, nhiều công cụ quản lý tệp bao gồm các tính năng xem ảnh và nhiều công cụ xử lý ảnh bao gồm các tính năng quản lý tệp. Bạn có thể di chuyển các tệp xung quanh và bạn có thể xem hình ảnh bằng một trong hai công cụ, thường là tốt như nhau.

Do đó, hoàn toàn có thể có toàn bộ các phần của quy trình phát triển phần mềm được bao phủ / chồng chéo bởi nhiều bộ công cụ ngay cả khi tính năng / khả năng chính của chúng khác nhau.

Vì vậy, nó thực sự nắm rõ chức năng chính xác mà bạn muốn đạt được trong quy trình cụ thể của mình và công cụ này hay công cụ kia hoạt động tốt như thế nào trong ngữ cảnh của bạn . Chủ quan / sở thích / tiện lợi bao gồm.

Đặt câu hỏi này chủ yếu dựa trên quan điểm;)

Các công cụ quản lý cấu hình được sử dụng để đưa một hệ thống vào trạng thái đã biết. Các công cụ triển khai triển khai các tệp chương trình mới và dữ liệu chương trình cho một hệ thống. Vào cuối ngày, cả hai loại công cụ đều thực hiện một số kết hợp:

• Xác định trạng thái hiện tại của hệ thống.
• Chuyển tập tin vào hệ thống.
• Thêm hoặc thay đổi dữ liệu liên tục (ví dụ: tệp cấu hình, dữ liệu cơ sở dữ liệu, cài đặt đăng ký)
• Bắt đầu hoặc khởi động lại chương trình.

Các công cụ quản lý cấu hình có các ngôn ngữ khai báo xác định trạng thái của hệ thống. Các công cụ triển khai có các ngôn ngữ bắt buộc bảo hệ thống thực hiện mọi việc. Một người DevOps cần phải làm cả hai.

Sử dụng công cụ triển khai Capistrano, thật vụng về khi sử dụng ngôn ngữ của nó để báo cho hệ thống để đảm bảo rằng máy chủ web đang hoạt động. Bạn phải ra lệnh khởi động lại máy chủ web và một lệnh khác để kiểm tra xem máy chủ web có hoạt động không. Đó là một loại bùn để đưa máy chủ web vào trạng thái đã biết.

Sử dụng công cụ quản lý cấu hình Ansible, thật vụng về khi khởi động lại máy chủ web. Ngôn ngữ cho phép bạn yêu cầu máy chủ web "khởi động", nhưng nếu bạn đặc biệt muốn nó được khởi động lại, bạn phải đặt trạng thái của nó thành "khởi động lại". Nhưng không có cách nào dễ dàng để kiểm tra xem máy chủ web đã được khởi động lại chưa. Đây là một loại bùn trong Ansible để cho phép các hoạt động một lần.

Một số người thích làm cả hai loại công việc với một công cụ và làm việc xung quanh các cạnh thô. Những người khác thích có hai công cụ để làm gần như cùng một thứ, nhưng không có cạnh thô. Để trả lời câu hỏi, "sự phù hợp" là vấn đề của hương vị. Câu trả lời này giải thích tại sao.

TL; DR : Chỉ cần sử dụng Ansbile, nó là cả công cụ cấu hình và triển khai :)

Có một số loại triển khai:

• Ứng dụng dựa trên (tệp, gói lưu trữ)

• Dựa trên container (bao gồm VM, Habitat, LXC, Docker)

• Chức năng dựa trên (Dịch vụ vi mô / Lambdas / Chức năng)

Tôi giả sử trong trường hợp này chúng ta chỉ nói về các bản cập nhật ứng dụng trên (các) máy chủ.

Để triển khai, bạn cần có hai điều xảy ra:

1. Các tập tin hoặc gói chính xác cần phải di chuyển đến máy chủ.
2. Cấu hình và trạng thái dịch vụ cần thay đổi.

Bây giờ cho (1) bạn có thể sử dụng nhiều chiến lược:

• Kho lưu trữ nhân tạo / đồng bộ hóa
• Gói kho / Quản lý gói
• Hệ thống kiểm soát phiên bản / Cập nhật + Biên dịch (tùy chọn)
• Giao thức truyền tệp (scp, rsync, ftp)
• Công cụ triển khai

Đối với (2) bạn có thể sử dụng:

• Công cụ quản lý cấu hình
• Công cụ triển khai

Vì vậy, trong khi Công cụ triển khai là một cách để triển khai tất cả trong một, chúng không phải luôn luôn là chiến lược tốt nhất. Đôi khi bạn muốn sử dụng kết hợp các cách này để triển khai. Bạn rất có thể đã sử dụng trình quản lý gói ít nhất trên các máy chủ của mình. Bạn rất có thể chạy các công cụ cấu hình nào. Vấn đề với một số công cụ cấu hình là sự phối hợp hợp lý giữa nhiều máy chủ, nhưng bây giờ ngay cả Chef và Puppet cũng có thể làm điều đó khá tốt. Ansible đã luôn luôn tốt trong việc này.

Từ kinh nghiệm cá nhân , tôi đã sử dụng tất cả các kết hợp, nhưng hiện tại chúng tôi sử dụng Capistrano để triển khai và đồng bộ hóa Ansible để quản lý cấu hình, và VCS và kho lưu trữ gói để chuyển tệp, nhưng có vấn đề với Capistrano và chúng tôi đang dự định chuyển từ nó sang thống nhất trên Ansible cho cả quản lý triển khai, bảo trì và cấu hình.

Triển khai ứng dụng là một điều khó khăn để xác định vì nó có rất nhiều vấn đề phụ. Các hệ thống quản lý cấu hình rất xuất sắc trong việc mô hình hóa các tác vụ hội tụ và hoạt động với "trạng thái mong muốn của hệ thống" là gì. Trong bối cảnh triển khai ứng dụng, điều này rất tốt cho những việc như triển khai bit cho máy, quản lý tệp cấu hình và thiết lập dịch vụ hệ thống. Điều cực kỳ tồi tệ là những thứ vốn dĩ mang tính thủ tục, đáng chú ý là di chuyển cơ sở dữ liệu và khởi động lại dịch vụ. Tôi thường cố gắng đưa logic hội tụ vào Chef và để một công cụ thủ tục bên ngoài (thường là Fabric trong trường hợp của tôi) xử lý một số bit còn lại cũng như giải trình tự các điểm hội tụ thực tế.

Vì vậy, về cơ bản, bạn nên sử dụng cả hai cho các phần họ giỏi nhất.

Đối với phần mềm và triển khai mã đến máy chủ hiện có hoặc bên trong bộ chứa Docker, câu trả lời tương đối đơn giản - Không, bạn không cần cả hai, nhưng bạn có thể muốn cả hai nếu một công cụ hoặc tiện ích khác tăng giá trị và là công cụ phù hợp cho công việc , tuy nhiên mọi thứ trở nên phức tạp hơn khi bạn đang triển khai các máy chủ và hệ điều hành.

Một giá trị gia tăng của tâm lý DevOps là coi cơ sở hạ tầng là mã và thường xuyên triển khai hoặc phá hủy các máy ảo hoặc thậm chí là kim loại trần trong môi trường có tính đàn hồi cao. Hệ thống quản lý cấu hình của bạn không thể dễ dàng netboot và khởi động máy chủ của bạn cho bạn và không thể quản lý kho, gói và cập nhật / vá lỗi cho bạn trong và sau khi triển khai hoặc trong một số trường hợp, cấp phép và quyền lợi.

Đối với Amazon Web Services, phần lớn các API này có thể quản lý khá thuận tiện, nhưng đối với những người trong chúng ta phải quản lý các trung tâm dữ liệu của riêng mình thì đây không phải là một tùy chọn. Vì lý do này, dự án Foreman (và Red Hat tái thương hiệu này ) đã thấy cần phải bó Katello , Candlepin và một người quản lý cấu hình như Ansible, Foreman hoặc Puppet cùng nhau khi triển khai Kịch bản Katello .

Vì vậy, trong khi bạn có thể thoát khỏi việc sử dụng các công cụ quản lý cấu hình để triển khai mã phần mềm ở phía Dev của nhà, thì ở phía Ops, có một số trường hợp câu trả lời là "không, công cụ quản lý cấu hình không thành công thích hợp để sử dụng làm công cụ triển khai "Làm như vậy sẽ đòi hỏi phải phát minh lại nghiêm trọng bánh xe và không thực tế. Thay vào đó, bạn phải sử dụng các công cụ quản lý cấu hình của mình để bắt đầu triển khai trong một công cụ khác.