Rối rối mọi thứ hay không?


10

Lưu ý: có rất nhiều câu hỏi lý thuyết.

Gần đây tôi đang đọc về Puppet (và các hệ thống tương tự), mà - như tôi tin - có thể giúp công việc của tôi dễ dàng hơn rất nhiều. Nhưng tôi cố gắng - và thật không may - không thể hiểu tất cả những gì tôi có thể "bù nhìn". Tôi có thể tưởng tượng các "đám mây" hoặc cụm HA, nơi có cùng cấu hình trên nhiều máy chủ hơn. Nhưng những gì về máy trạm? Tôi có một máy tính (centos với kvm), một máy tính xách tay (fedora) và máy chủ cá nhân, liệu nó có thể (hoặc nên) bị rối không? (Dis) lợi thế là gì? Hoặc trong công ty của chúng tôi, chúng tôi có hàng trăm máy chủ (chủ yếu là centos), nhưng mỗi máy chủ thì khác nhau một chút. Không thể quyết định liệu có tốt hơn khi có nhiều cấu hình ở một nơi .. (Dis) không? Tôi sẽ rất vui vì tất cả các ý kiến ​​hoặc liên kết của bạn với chủ đề này.


Tôi khuyên bạn không nên cố gắng "rối" bất kỳ hệ thống Windows nào của bạn. Ồ, và đọc Câu hỏi thường gặp của chúng tôi về loại câu hỏi bạn nên hỏi ở đây.
HoplessN00b

7
Số lượng những thứ bạn rối, và chúng có bao nhiêu thứ rối phải tỷ lệ thuận với số tiền bạn quan tâm về nhiệm vụ được thực hiện cho bạn. Bắt đầu nhỏ, chỉ cần rối cấu hình ntp hoặc rsyslog. Sau đó, xây dựng từ đó nếu và khi bạn cần, khi bạn cần.
Sirex

1
Vì bạn đã có rất nhiều máy chủ ở vị trí của tôi, đề nghị của tôi là bạn bắt đầu đơn giản với các bit phổ biến trên mọi hệ thống, sau đó bắt đầu đi vào những điều chi tiết cụ thể hơn khi bạn có thời gian.
Zoredache

1
Hỗ trợ Windows đã được cải thiện đáng kể trong các phiên bản gần đây của Puppet. Tôi quản lý hàng trăm nút Windows bằng Puppet. Con rối trên các nút POSIX đơn giản và mạnh mẽ hơn nhiều, nhưng sử dụng Puppet cho ít nhất một số thứ trên Windows có thể cực kỳ hữu ích.
czervik

Câu trả lời:


16

Mức độ mà bạn có thể điều chỉnh toàn bộ môi trường phụ thuộc vào một số biến:

  • Sự sẵn sàng của các nhân viên tự động hóa để viết tự động cho mọi. ít. Điều.
  • Điều kiện văn hóa cho phép "Tôi sẽ thay đổi điều này, dù sao cũng chỉ là một lần" để biến thành "Tôi sẽ thay đổi điều này trong bản kê khai con rối này và áp dụng ngay bây giờ; . "
  • Mức độ không đồng nhất trong một môi trường.

Hoàn toàn có thể làm rối mọi thứ ****** - có thể bị rối, nhưng để đạt được điều đó cần có văn hóa và mua đúng từ mọi người có thể chạm vào thiết bị có khả năng rối. Một số thiết bị về cơ bản khó quản lý theo cách đó, những thứ như máy trạm và con rối tốt hơn là một công cụ dàn dựng hơn là một công cụ quản lý cấu hình.

Con rối thật tuyệt vời khi bạn đang quản lý một đội máy ảo, tất cả đều làm điều tương tự. Tổng số chiến thắng, và không có nhiều nỗ lực để đạt được điều đó.

Ở phía bên kia của quang phổ, bạn có những gì tôi đã có trong công việc cuối cùng của mình, đó là hơn 200 máy chủ cung cấp 130 dịch vụ và chỉ một nhóm nhỏ trong số họ làm như vậy với nhiều hơn một máy. Có những công ty hoàn toàn (và các trường đại học) đã điều chỉnh loại điều đó, nhưng đó là rất nhiều nỗ lực và mất rất nhiều tiền để mua. Nó yêu cầu bước đầu tiên của quy trình triển khai máy mới của bạn không phải là "Cài đặt hệ điều hành", mà là "tạo bảng kê khai".

Cuối cùng, đây là một nỗ lực so với vấn đề văn hóa hiệu quả mà bạn sẽ phải giải quyết trong số tất cả các nhân viên CNTT của mình.


13

PUPPET TẤT CẢ NHỮNG ĐIỀU

Bất cứ điều gì tương tự hợp lý trên tất cả các hệ thống (hoặc một tập hợp con của chúng), hoặc bạn có thể dựa trên một mẫu thực tế mà bạn có thể thoát ra facterlà trò chơi công bằng.

Những điều thực sự độc đáo có lẽ bạn không nên bận tâm và chỉ nên phục vụ các cấu hình trong một filebucket.

Những gì thuộc một trong hai loại là một quyết định mà chúng ta không thể đưa ra mà không biết môi trường của bạn một cách thân mật, vì vậy đó là để bạn tìm ra.


6

Tôi nghĩ rằng những người khác đã giải thích lý do tại sao tôi sẽ chụp ảnh như thế nào. Tôi nghĩ bằng cách hiểu làm thế nào ai đó có thể sử dụng Puppet để làm những gì bạn muốn, nó sẽ làm cho quyết định rõ ràng hơn.

Làm trường hợp cơ bản trước

Mô-đun rối cho Apache không nên làm nhiều theo mặc định. Cài đặt Apache, cấu hình nó theo tiêu chuẩn tối thiểu và bắt đầu dịch vụ. Làm cho công việc này trên tất cả các distro bạn cần hỗ trợ.

Thêm tính linh hoạt thứ hai

Chúng ta cần thêm vhost. Bạn sẽ kết thúc với một hệ thống có thể thả tệp hoặc xóa chúng khỏi một tập hợp các thư mục conf.d hoặc vhosts.d / theo những gì bạn cần. Điều tương tự với việc kích hoạt hoặc cấu hình các mô-đun.

Sử dụng các lớp vai trò hoặc nhóm máy chủ để liên kết các khối xây dựng của bạn với nhau

Tôi nghĩ cách tốt nhất để sử dụng Puppet là đảm bảo nó là phụ gia. Sử dụng các ví dụ trên, chúng ta sẽ có một mô-đun

  1. Cài đặt Apache
  2. Đặt cấu hình cơ bản
  3. Thêm vhost vào apache
  4. Định cấu hình bất kỳ cài đặt bổ sung nào
  5. Bắt đầu Apache

Thay vì quá tải mô-đun Apache mặc định của chúng tôi để thực hiện chính xác những gì chúng tôi cần cho một máy chủ hoặc nhóm cụ thể, chúng tôi nên xử lý đây là lớp vai trò hoặc lớp máy chủ.

class role::web_cust1 {
  include apache
  apache::vhost {'www.domain.com': }
  apache::vhost {'www.domain2.com': priority => '99', }
  include php
  include php-fpm
  include mysql
}

Lại thêm phụ gia.

Đặt trường hợp đặc biệt vào Hiera

Tôi là một fan hâm mộ lớn của việc để Hiera của Puppet, nghĩ về nó như một cơ sở dữ liệu cho Puppet, lưu trữ các bit đặc biệt. Nếu một máy chủ hoặc nhóm máy chủ nhất định cần một cài đặt đặc biệt, trước tiên hãy đặt mặc định lành mạnh vào mô-đun để người dùng bình thường không cần biết về nó. Sau đó chèn dữ liệu cho các máy chủ hoặc nhóm máy chủ đặc biệt đó để Hiera có thể sử dụng dữ liệu đó để chuyển cho Puppet khi cần.

Trường hợp sử dụng của tôi là cổng Nghe. Một số máy chủ có Varnish hoặc haproxy trước mặt họ. Theo mặc định, mô đun Puppet có Apache sử dụng cổng 80, nhưng nếu Hiera tìm thấy dữ liệu, nó sẽ ghi đè mặc định đó.


Tôi đã sử dụng hệ thống phân cấp mô-đun vai trò và nó hoạt động tốt. Nó giúp dễ dàng hơn để xây dựng một môi trường nơi bạn có thể có nhiều máy chủ đóng nhiều vai trò (ví dụ: một số vai trò :: máy chủ web có thể là vai trò :: lưu trữ cũng).
Andy Shinn

5

Tôi hiện đang trong quá trình chuyển đổi giữa Puppetize các hệ thống tương tự hợp lý với Puppetize mọi thứ và tin chắc rằng về lâu dài, Puppetize mọi thứ là một cách tiếp cận tốt hơn.

Nếu phiên bản của bạn kiểm soát các bảng kê rối của bạn (tất cả chúng ta đều làm điều này, phải), bạn có được tất cả các lợi ích của kiểm soát phiên bản cho cơ sở hạ tầng của bạn. Nhóm của bạn trở thành kỹ sư hoạt động. Điều này cũng quan trọng đối với các hệ thống đặc biệt, một lần như các trang trại gia súc đồng nhất. Bạn nhận được một bản ghi của người đã thay đổi một cái gì đó, khi họ thay đổi nó, sự thay đổi chính xác là gì và khả năng đẩy lùi sự thay đổi.

Cá nhân tôi cũng thấy rằng việc ép buộc bản thân thực hiện mọi thay đổi thông qua Puppet khiến tôi suy nghĩ kỹ hơn về sự thay đổi. Khi tôi viết các bảng kê khai, tôi chú ý đến từng thay đổi hơn là tôi thường hack ở dòng lệnh.

Mô-đun rối của bạn cũng sẽ trở nên tốt hơn. Bạn có nhiều hơn một mô-đun Nginx? Có lẽ điều đó có nghĩa là mô-đun Nginx của bạn không tuyệt vời như vậy và bạn cần làm cho nó đủ linh hoạt để xử lý tất cả các nhu cầu đặc biệt của bạn. Ít nhất là trừu tượng những điểm tương đồng thành một mô-đun Nginx cốt lõi mà bạn mở rộng cho các mô-đun "tùy chỉnh".

Hơn nữa, bạn tự tin đến mức nào mà bạn có thể khôi phục tất cả các máy chủ có nhu cầu đặc biệt của mình về trạng thái hiện tại (liên quan đến cấu hình) khi thảm họa xảy ra? Nếu mọi thay đổi cần thiết để đưa máy chủ Ubuntu của nhà máy vào wiki nội bộ của bạn bị rối, bạn có thể dễ dàng xây dựng lại trạng thái hiện tại của wiki, bao gồm bộ nhớ Tomcat của ngày hôm qua bởi Bob.

Cuối cùng, điều này có thể thực sự khó khăn. Việc quản lý nhiều máy chủ rất khác nhau có thể dẫn đến một số mã Puptastic nếu bạn không dành thời gian để làm việc đúng. Nếu bạn không sử dụng Puppet Enterprise, hãy xem xét hiera và / hoặc ENC như Foreman để giúp tách dữ liệu của bạn khỏi bảng kê khai của bạn. Ngày nào cũng rối một thứ khác. Có một đồng nghiệp lái xe trong khi bạn giải thích cách thức hoạt động trong Puppet. Mỗi thay đổi sẽ trở nên dễ dàng hơn.

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.