Các khuyến nghị về Đầu bếp và Múa rối

Question

Tôi muốn hỏi về khi nào và trong hoàn cảnh nào bạn sẽ sử dụng con rối và khi bạn sử dụng đầu bếp. Tôi cũng đã tìm thấy rump là một loại rối độc đáo trong đó bạn lặp lại một máy chủ duy nhất để cấu hình và sau đó đẩy nó vào một loạt các máy chủ, cho phép bạn xem các thay đổi trực tiếp.

Câu hỏi của tôi: Tôi nên sử dụng điều gì ở trên và theo cách nào? Có ai có thể giúp tôi không?

Mục tiêu của tôi là trong bối cảnh tích hợp liên tục, triển khai liên tục trong môi trường mono/.Net với rake và git. Tôi muốn đóng gói, phiên bản và triển khai các ứng dụng web một cách dễ dàng và muốn sử dụng recepies cho một cân bằng tải cho nhiều máy chủ web. Có thể thực hiện những điều này một cách nhanh chóng và không có thời gian chết giữa các lần nâng cấp.

Answer 1

Tôi muốn sử dụng Puppet nhưng tôi khá là thiên vị khi tôi viết một cuốn sách về nó và làm việc ở đó. :) Ngoài Rump bạn cũng có thể sử dụng Puppet trong chế độ áp dụng của nó - đó là giống như đầu bếp-solo. Mặc dù Rump kết thúc tốt đẹp một số tốt đẹp xung quanh quá trình đó là giá trị cố gắng.

Tôi sẽ cung cấp cho Puppet một shot ở đây bằng cách sử dụng Rump như một bọc xung quanh - cả hai bạn có thể sử dụng con rối DSL hoặc Ruby DSL (Chef chỉ có một Ruby DSL). Rất dễ dàng để tạo ra "môi trường" bằng cách sử dụng Puppet và tích hợp một luồng công việc git/CI với các triển khai của bạn. Nó cũng dễ dàng tích hợp với các nhiệm vụ Rake hoặc tương tự.

Answer 2

Nếu bạn đã quen thuộc với Ruby, tôi khuyên bạn nên thử Chef hơn Puppet. Sử dụng đầu bếp & ruby, bạn có thể chạy nhiệm vụ rất phức tạp. Tuy nhiên con rối là miền sạch hơn được xác định hơn đầu bếp. Tốt hay không, tất cả lên đến công việc thực tế của bạn.

Answer 3

Có sử dụng cả hai, tôi sẽ nói rằng nó phụ thuộc vào những gì bạn tìm kiếm. Theo ý kiến ​​của tôi:

• Chef nhiều phát triển theo định hướng. Nếu bạn là một guru Ruby, bạn sẽ thích nó.

• Rối là nhiều hơn sysadmin định hướng. Nó có một DSL không ruby ​​vì vậy nó khó khăn hơn để truyền bá lỗi cho máy của bạn (imho).

Rối tạo mã dễ đọc và ổn định hơn nhưng cũng chậm triển khai các tính năng mới. Đó có lẽ là những gì bạn sẽ muốn trong một cơ cấu doanh nghiệp lớn mà tin tưởng mạnh mẽ vào công việc DevOps của bạn.

Với Đầu bếp bạn có thể đạt được các tác vụ phức tạp với ít mã, nỗ lực thời gian hơn. Bạn có thể sử dụng tất cả các phép thuật ruby ​​mà không cần phải tạo ra một cấu trúc Puppet. Điều này là tốt, ví dụ, khi Công ty của bạn không thực sự tin vào giá trị DevOps và bạn liên tục đấu tranh chống lại thời gian để chứng minh người quản lý của bạn sai :-) Cá nhân tôi tìm thấy Puppet chậm hơn một chút để thực hiện khi bạn phát triển các tính năng mới, có thể hơi đau.

Đề xuất của tôi là: nếu bạn là sysadmin với một số kỹ năng phát triển, hãy truy cập Puppet. Nếu bạn tốt với Ruby (hoặc Python), hãy vào Chef.

Tôi cũng đã thử rump và tôi đang chơi với nó.Nó giúp, nó mát mẻ, nhưng tôi vẫn không nhìn thấy một giá trị lớn, ngoại trừ gõ lười biếng của rump đi thay vì con rối áp dụng -vd - modulepath =. mô-đun/tệp kê khai/init.pp. :)

Answer 4

Cuối cùng tôi đã kết thúc với con rối + vagrant cho phép tôi để chạy/chạy lại/kiểm tra bù nhìn biểu hiện:

đầu tiên cài đặt VirtualBox, sau đó:

gem install puppet 
gem install vagrant 

thì:

vagrant box add base http://files.vagrantup.com/lucid32.box 
vagrant init 

sau đó chỉnh sửa ./Vagrantfile để nói:

Vagrant::Config.run do |config| 

    config.vm.box = "base" 
    config.vm.provision :puppet do |puppet| 
    puppet.manifests_path = "manifests" 
    puppet.module_path = "modules" 
    end 

    # rest here 
end 

sau đó thêm một định nghĩa nút để manifests/default.pp, như:

group { "puppet": 
    ensure => "present", 
} 
file { '/etc/motd': 
    content => "Welcome to your Vagrant-built virtual machine!\n" 
} 

sau đó chạy:

vagrant up 

Bây giờ bạn đã có một máy ảo rối quản lý mà bạn có thể chơi với, và bất kỳ biểu hiện mà bạn thay đổi đi vào kiểm soát nguồn. Và bạn có thể lặp lại nhanh chóng mà không cần phải nghỉ ngơi.

Answer 5

Một sự khác biệt lớn giữa Puppet và Chef chưa được nhắc đến là Puppet sẽ thực hiện tất cả việc biên dịch biểu hiện trên Server, trong khi Chef (và cfengine) sẽ thực hiện một số hoặc tất cả công việc trên máy khách.

Điều này có nghĩa là * Dấu chân CPU ít hơn trên ứng dụng khách của bạn khi chạy con rối và * Mô-đun bổ trợ được viết bằng Puppet chỉ chạy trên máy chủ.

Phần thứ hai là quan trọng, vì nó giúp dễ dàng tích hợp Puppet với kiến ​​trúc khác của bạn. Ví dụ, nếu bạn muốn lấy dữ liệu thông qua một API từ một ứng dụng khác, theo Puppet bạn chỉ cần cài đặt các mô-đun API cần thiết trên Puppetmaster, và chỉ cần cấp cho một máy chủ truy cập vào API đó. Bất kỳ thông tin cần thiết nào cũng vẫn còn trên puppetmaster - an toàn hơn nhiều.

Chúng tôi đang tích hợp Puppet and SecretServer (để tự động xoay mật khẩu gốc bằng cách sử dụng con rối và lưu trữ chúng vào SecretServer). Điều này sẽ không thể có được hoặc an toàn theo Chef, như tôi hiểu mô hình.