Thực hành tốt để quản lý cập nhật gói cho nhiều máy chủ CentOS

Là một phần của công việc, tôi quản lý một vài chục máy chủ CentOS 5, sử dụng con rối cho thiết lập chính. Khoảng một nửa số máy chủ của chúng tôi có một thiết lập được tiêu chuẩn hóa để lưu trữ các trang web django khác nhau, trong khi phần còn lại là một loạt các ứng dụng.

Tôi đang dần dần sắp xếp các hoạt động lưu trữ của chúng tôi và giờ tôi đã tìm ra cách quản lý các cập nhật bảo mật ở cấp độ HĐH. Tôi cảnh giác khi chỉ có một công việc định kỳ đang làm yum -y updatenhưng cũng không muốn phải đi vòng quanh từng máy chủ và xem xét mọi gói với các bản cập nhật có sẵn, vì sẽ mất một thời gian.

Vì vậy, tôi tự hỏi nếu có bất kỳ phím tắt tốt hoặc thực hành làm việc sẽ giảm thiểu rủi ro liên quan và giảm thiểu thời gian tôi cần phải dành. Hoặc nói một cách khác là có bất kỳ công cụ hoặc thực tiễn nào có thể tự động hóa rất nhiều công việc trong khi vẫn kiểm soát.

Các bước tôi đã quyết định cho đến nay:

• vô hiệu hóa tất cả các kho lưu trữ của bên thứ ba và thiết lập kho lưu trữ của riêng chúng tôi để tôi có thể kiểm soát những cập nhật nào đi qua đó.
• chúng tôi có các máy chủ dàn dựng cho (hầu hết) các máy chủ sản xuất của chúng tôi, nơi tôi có thể thực hiện thử nghiệm (nhưng thử nghiệm bao nhiêu là đủ thử nghiệm?)

Cũng lưu ý rằng tôi đã xem xét plugin bảo mật yum nhưng nó không hoạt động trên CentOS .

Vậy làm thế nào để bạn quản lý các bản cập nhật cho số lượng đáng kể các máy chủ CentOS chạy một loạt các ứng dụng không đồng nhất?

Trong hầu hết các môi trường của tôi, nó thường là một kịch bản khởi động và cài đặt sau để cài đặt hệ thống chính và cập nhật với các bản cập nhật tại thời điểm đó. Tôi thường sẽ có một repo cục bộ đồng bộ với gương CentOS hàng ngày hoặc hàng tuần. Tôi có xu hướng đóng băng gói kernel bất cứ lúc nào kể từ thời điểm cài đặt và cập nhật các gói riêng lẻ hoặc khi cần thiết. Thông thường, các máy chủ của tôi có các thiết bị ngoại vi có trình điều khiển được liên kết chặt chẽ với các phiên bản kernel, vì vậy đó là điều cần cân nhắc.

CentOS 5 đã trưởng thành đến mức không cần cập nhật liên tục. Nhưng cũng nên nhớ rằng CentOS 5 đang đi xuống. Tốc độ cập nhật đã chậm lại một chút và bản chất của các bản cập nhật là nội tuyến hơn với các lỗi và ít thay đổi về chức năng chính.

Vì vậy, trong trường hợp cụ thể này, điều đầu tiên bạn có thể làm là xây dựng một gương / repo cục bộ. Sử dụng quản lý cấu hình hiện tại của bạn để kiểm soát quyền truy cập vào repos của bên thứ ba. Có thể lên lịch chính sách để cập nhật các dịch vụ quan trọng hoặc công khai (ssh, http, ftp, dovecot, v.v.) Mọi thứ khác sẽ yêu cầu thử nghiệm, nhưng tôi có cảm giác rằng hầu hết các môi trường không chạy với các hệ thống được cập nhật / vá đầy đủ.

Có rất nhiều công cụ có thể giúp với điều này! Nó nói chung hệ thống gói và gói nào đi đâu được quản lý cấu hình. Những công cụ này thường bao gồm nhiều hơn chỉ là yum và rpms, và sẽ giúp bạn tiết kiệm thời gian và ngăn ngừa nhiều vấn đề đau đầu!

Công cụ tôi quen thuộc nhất là con rối mà tôi sử dụng để quản lý hầu như mọi cấu hình trong môi trường của mình. Dưới đây là một số ví dụ về con rối để quản lý yum cụ thể:

http://people.redhat.com/dlutter/puppet-app.html

Có một số công cụ quản lý cấu hình hiện có sẵn, chúng có các nhóm người dùng khá lớn:

• cfengine http://cfengine.com/cfengine3
• Con rối http://puppetlabs.com/puppet/puppet-difference/
• Đầu bếp http://wiki.opscode.com/display/chef/Home (Một vài người tôi biết gần đây đã thực hiện điều này và yêu thích nó)

Thực hiện những điều này trong một môi trường sẽ thêm nhiều năm vào cuộc sống của bạn. Nó làm giảm số lượng đau đầu từ các hệ thống được cấu hình kém và cho phép dễ dàng nâng cấp / cập nhật. Hầu hết các công cụ này cũng có thể cung cấp một số chức năng ở cấp độ kiểm toán, điều này có thể giúp giảm đáng kể thời gian sửa chữa cho các lỗi cấu hình.

Liên quan đến câu hỏi của bạn về thử nghiệm Tôi đã sử dụng môi trường dàn dựng mà chúng tôi hướng một số khách hàng tải đến (thường là khách hàng beta hoặc một tập hợp nhỏ lưu lượng sản xuất). Chúng tôi thường để cụm này chạy mã mới trong ít nhất một vài ngày, tối đa một tuần (tùy thuộc vào mức độ thay đổi) trước khi chúng tôi triển khai nó vào sản xuất. Thông thường tôi đã thấy thiết lập này hoạt động tốt nhất nếu bạn thử và tìm hiểu xem hầu hết các lỗi mất bao lâu để khám phá. Trong các hệ thống được sử dụng nhiều, điều này có thể là vấn đề hàng giờ, trong hầu hết các môi trường tôi đã thấy một tuần là đủ dài để khám phá ngay cả các lỗi không phổ biến trong dàn / QA.

Một phần thực sự quan trọng về thử nghiệm là sao chép dữ liệu / sử dụng. Bạn đã đề cập rằng bạn có các phiên bản dàn dựng của hầu hết các phần cứng sản xuất của bạn. Họ cũng có bản sao giống hệt của dữ liệu sản xuất? Bạn có thể phát lại bất kỳ tải sản xuất chống lại nó? Bạn thậm chí có thể làm cho nó trở thành một phần của cụm sản xuất bằng cách sử dụng phản chiếu giao thông không? Điều này thường trở thành sự đánh đổi trực tiếp giữa lượng tài nguyên mà doanh nghiệp sẵn sàng chi cho thử nghiệm / QA. Càng thử nghiệm càng tốt, cố gắng không tự giới hạn (trong lý do) và xem những gì doanh nghiệp sẽ hỗ trợ (sau đó tìm cách để làm thêm 10%).