Khi nào thì thích hợp để sử dụng trình quản lý cấu hình (ví dụ: Puppet / Chef / Ansible)?


17

Tại nơi làm việc hiện tại của tôi, tôi chăm sóc hai máy chủ VMware, một máy vật lý OpenBSD, ba máy ảo Debian và sáu máy chủ Windows Server VM (2008/2012).

Tôi đang xem xét triển khai một công cụ quản lý cấu hình như Puppet hoặc Chef. Điều này có hợp lý không, hay chi phí học tập của công cụ sẽ lớn hơn lợi ích? Đâu là điểm bùng phát giữa khả năng quản lý và chi phí thực hiện?


1
Điều đó "phù hợp" ngay khi bạn cần quản lý cấu hình - cần khôi phục sau thảm họa? Cần phải chuyển đến một trung tâm dữ liệu mới? Cần mở rộng theo chiều ngang? Nếu bạn đang làm bằng tay, bạn đang làm sai . " Làm điều đó hai lần? Viết nó xuống. "
warren

1
Nó phụ thuộc vào những gì bạn cần làm để / với các hệ thống này.
ewwhite

Câu trả lời:


25

IMHO đáng để học hỏi ngay cả khi bạn chỉ quản lý một máy chủ duy nhất,

Vâng, sẽ có một đường cong học tập. Vâng, bạn sẽ nhận được thất vọng. Tuy nhiên, đối với các chi phí đó, bạn sẽ được trả lại nhiều lần thông qua các triển khai đáng tin cậy, nhất quán, chỉ bằng một cú nhấp chuột, cấu hình máy chủ kiểm soát phiên bản, dễ dàng thiết lập môi trường thử nghiệm / dev, v.v.

Ngoài những lợi ích cho công việc hiện tại của bạn, có thể thêm một hệ thống CM vào sơ yếu lý lịch của bạn là một chiến thắng lớn. Các hệ thống hiện đại dự kiến ​​sẽ có ít nhất tiếp xúc với hệ thống quản lý cấu hình, nếu không thành thạo.

(Sidenote: cũng xem xét Ansible. Đó là CM ưa thích của tôi, và rất dễ dàng để bắt đầu và chạy với - dễ dàng hơn nhiều so với Puppet hoặc Chef.


5
Nói hay lắm. Tôi cuối cùng sử dụng Ansible cho những việc nhỏ nhặt như thiết lập một quả mâm xôi tại nhà vì đó là cách thuận tiện để tôi ghi lại quá trình.
tedder42

2
Chắc chắn rồi! Vào Chef là một chiến thắng lớn trong sự nghiệp của tôi. Đây là điều có thật: trong một vài năm nữa, CM sẽ chỉ là về yêu cầu / dự kiến ​​cho tất cả các công việc trừ SysAd cơ sở.
gWaldo

2
Hoàn toàn đồng ý. Quá nhiều sự tập trung vào tự động hóa cài đặt chỉ là một phần của hệ thống CM. Mọi người quên những gì M là viết tắt của - quản lý. Làm thế nào để bạn theo dõi các thay đổi cấu hình khác nhau mà bạn thực hiện cho 1 máy chủ. Số lượng máy chủ không quan trọng. Khi 1 máy chủ đó chết, bạn rất vui khi có thể xây dựng lại chính xác mà không nghi ngờ gì.
ETL

5

Tôi đang xem xét triển khai một công cụ quản lý cấu hình như Puppet hoặc Chef. Điều này có hợp lý không, hay chi phí học tập của công cụ sẽ lớn hơn lợi ích?

Điều này là hợp lý tùy thuộc vào số tiền và thời gian bạn phải đốt, và đó có phải là tiền của bạn mà bạn đang đốt hay không.

Một công cụ quản lý cấu hình (bất kỳ trong số chúng) đang trở thành một kỹ năng có giá trị trong thị trường ngày nay.

Dành thời gian để tìm hiểu và triển khai một công cụ CM có thể không phải là điều hiệu quả nhất để làm theo quan điểm của doanh nghiệp hoặc môi trường của bạn, nhưng từ kỹ năng của bạn, nó có thể đáng giá.

Đâu là điểm bùng phát giữa khả năng quản lý và chi phí thực hiện?

Hầu hết các công cụ quản lý cấu hình đều có sẵn miễn phí với sự cảnh báo rằng chúng khó cài đặt và hoạt động hơn.

Câu hỏi này hơi khó trả lời vì nó thực sự phụ thuộc vào những gì bạn đang làm hàng ngày để quản lý các máy chủ này. Nếu bạn không cần phải làm gì nhiều, thì một công cụ quản lý cấu hình có thể là quá mức cần thiết.

Nếu bạn chỉ thực sự cần phải thực thi cơ sở hạ tầng của mình ở trạng thái cơ bản và có thể dự đoán được, thì có thể không có hại gì khi chọn những điều cơ bản của một cái gì đó như SaltStack hoặc Ansible.

Theo kinh nghiệm cá nhân của tôi, Salt rất dễ dàng để khởi động và khởi động vào máy chủ và có thể được sử dụng để thực hiện và báo cáo từ xa rất cơ bản, có thể hữu ích nếu bạn chưa thực hiện nó trong môi trường của mình.

Hãy ghi nhớ, tôi thiên vị. Bạn nên tự đánh giá từng công cụ CM.


4

Giống như @EEAA đã nói - số lượng máy chủ không liên quan. Bạn có thể gặt hái những lợi ích của việc sử dụng quản lý cấu hình với một máy duy nhất:

  • thiết lập tài liệu (tài liệu thông qua các tập lệnh CM)
  • triển khai đáng tin cậy (bạn có thể [tái] triển khai bạn thiết lập nhiều lần
  • khả năng phục hồi của thiết lập (máy chủ hiện tại bị trục trặc - tăng tốc độ mới)
  • tái sử dụng (khi bạn đến một điểm có máy chủ thứ hai - bạn đã có các tập lệnh CM bạn có thể tái chế từ cái đầu tiên)
  • nâng cấp (giống như một thiết lập mới, chỉ ở trên một nền tảng khác)

Tôi có thể nói rằng tôi đã phải triển khai CM cho tất cả các máy chủ cá nhân của mình khi tôi làm việc ở đó không thường xuyên và quên tất cả các chi tiết nhỏ. Có các tập lệnh CM trong khi có vẻ tốn thời gian (đó là) việc hoàn vốn là hoàn toàn xứng đáng. Về lâu dài, bạn sẽ tiết kiệm được nhiều thời gian hơn mà bạn sẽ dành để thiết lập mọi thứ.


3

Tôi có kinh nghiệm với Puppet và Ansible. Ansible là IMO đơn giản hơn, vì nó là thủ tục, trong khi Puppet là khai báo. Có những ưu và nhược điểm cho cả hai, nhưng tôi đã nhổ tóc đủ do lỗi khó hiểu của Puppet.

Cả hai đều đòi hỏi rất nhiều công việc nếu bạn muốn tạo cấu hình sạch và có thể tái sử dụng. Các chi phí bắt đầu thực sự trả hết nếu bạn có ít nhất hai máy chủ rất giống nhau, ví dụ: đám mây hoặc cụm.

Tuy nhiên, nó có một số sử dụng ngay cả đối với các máy chủ độc lập - bạn có thể thiết lập người dùng quản trị, cấu hình chuẩn (với các biến thể cục bộ) sshd, postfix hoặc snmpd và cũng sử dụng chúng để thu thập thông tin đơn giản, như tuân thủ chính sách hoặc kiểm tra lỗ hổng shellshock.

Ngoài ra, như EEAA đã đề cập, nó có giá trị để ghi lại quá trình thiết lập nếu bạn xác minh rằng nó thực sự đưa máy chủ từ trạng thái cơ bản sang trạng thái chạy. Thật tốt khi kết hợp nó với hệ thống kiểm soát phiên bản (git), để những thay đổi bạn thực hiện được phiên bản và ghi lại. Điều đó rất có giá trị nếu bạn có một đội ngũ quản trị viên.


1

Con rối hoặc bất kỳ hệ thống quản lý nào khác đều mang lại những lợi ích to lớn mà tất cả đã được nhấn mạnh bằng các câu trả lời khác ở đây, nhưng không có viên đạn bạc nào khi nói đến quản lý.

Ví dụ: tạo các lớp rối cho các hệ thống phức tạp tốn nhiều thời gian và công sức và đôi khi rơi nước mắt vì có nhiều cạm bẫy và thông báo lỗi không phải lúc nào cũng rõ ràng 100% và khi nâng cấp phần mềm, bạn phải đầu tư thời gian để điều chỉnh các lớp rối của mình để phù hợp với bất kỳ đặc điểm kỹ thuật mới nào hoặc thủ tục và tìm ra cách tiếp cận nào phù hợp nhất cho việc này (ví dụ như con rối khai báo và nâng cấp thường là thủ tục)

Ngoài ra, bạn cần tìm ra cách bạn dự định đưa ra các thay đổi được thực hiện cho các lớp của mình một cách có kiểm soát và cách duy trì các phiên bản khác nhau của bảng kê khai.

Bạn cũng nên xem xét cách nâng cấp giải pháp quản lý của mình khi đến lúc đó.

Nếu bạn dành một lượng thời gian đáng kể để viết ví dụ các lớp múa rối thì bạn sẽ phải thực hiện rất nhiều cài đặt bằng một cú nhấp chuột để gặt hái bất kỳ lợi ích thực sự nào.

Tôi khuyên bạn nên khám phá tĩnh và khi thích hợp, tức là phân phối tệp cấu hình có thể là một nơi tốt để bắt đầu và lấy nó từ đó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.