Thực hành tốt nhất để cập nhật Linux tự động

Chúng tôi đang nghiên cứu cách thực hiện cập nhật tự động cho các máy chủ dựa trên RHEL / RHEL của chúng tôi.

Ý tưởng ban đầu: Sử dụng Puppet, chúng tôi vô hiệu hóa các kho lưu trữ mặc định và trỏ đến kho của chúng tôi. Sau đó, chúng tôi sử dụng ensure => latestcho các gói chúng tôi muốn tự động cập nhật.

Vấn đề: Chúng tôi đang thấy rằng một số dịch vụ khởi động lại sau khi cập nhật (duh).

Câu hỏi: Có ai có lời khuyên nào về cách tự động hóa tốt hơn các bản cập nhật và chiến lược của Linux về giảm thiểu tự động khởi động lại dịch vụ không? Chúng tôi muốn một giải pháp bao gồm Puppet nhưng, nếu chúng tôi cần sử dụng dịch vụ khác, đó không phải là một công cụ thỏa thuận.

Biên tập

Giải pháp có thể: Tôi đã gửi một giải pháp thực hiện nhiều điều mà @ voretaq7 và @ewwhite đề xuất. Có vẻ như đây là con đường tôi đang đi trong thời gian này. Nếu bạn có đề xuất khác, xin vui lòng bình luận hoặc gửi câu trả lời.

Chiến lược cập nhật chung của bạn là âm thanh: Bạn có một repo cục bộ (mà tôi giả sử bạn kiểm tra trong môi trường dev) và bạn cập nhật mọi thứ dựa trên repo đó (tôi cho là tốt).

Điều khởi động lại dịch vụ là không thể tránh khỏi: Nếu mã cơ sở đã thay đổi, bạn cần khởi động lại dịch vụ để thay đổi đó có hiệu lực. Không làm như vậy có thể dẫn đến hậu quả tồi tệ hơn (chạy mã không đồng bộ với thư viện dùng chung dẫn đến sự cố của ứng dụng).
Trong môi trường của tôi, tôi coi các cửa sổ vá hàng quý là hàng quý "TÁI TẤT CẢ NHỮNG ĐIỀU!" cửa sổ cũng vậy. Ưu điểm của chính sách này là bạn biết rằng máy chủ của bạn sẽ hoạt động trở lại sau khi khởi động lại và bạn biết chúng sẽ hoạt động bình thường (vì bạn kiểm tra chúng thường xuyên).

Lời khuyên tốt nhất của tôi cho bạn là lên lịch phát hành phần mềm (có thể điều này có nghĩa là bạn sẽ phải kích hoạt chúng "thủ công" bằng con rối) và tư vấn cho người dùng của bạn về thời gian bảo trì / ngừng hoạt động theo kế hoạch.
Ngoài ra (hoặc là một phần của điều này), bạn có thể định cấu hình dự phòng trong môi trường của mình để bạn có thể khởi động lại một số máy hoặc dịch vụ mà vẫn cung cấp dịch vụ cho người dùng cuối. Điều này có thể không hoàn toàn loại bỏ bất kỳ sự gián đoạn nào, nhưng nó có thể giúp giảm thiểu chúng.

Sự dư thừa được thêm vào cũng bảo vệ bạn trong trường hợp xảy ra lỗi phần cứng, điều không thể tránh khỏi trên thang thời gian đủ dài.

Có nhất thiết phải có vấn đề với việc khởi động lại dịch vụ sau khi cập nhật gói không? Kiểm tra ở quy mô nhỏ trước khi bạn triển khai để xem có vấn đề gì không. Gần đây tôi có một vấn đề xấu xí với gói RPMForge của denyhosts . Nó thực sự đã thay đổi vị trí của cấu hình và thư mục công việc giữa các phiên bản từ bản cập nhật yum. Đó là hành vi hoàn toàn không mong muốn. Thông thường, trong cùng một phiên bản sửa đổi của RHEL, không có quá nhiều vấn đề, nhưng bạn không bao giờ có thể chắc chắn nếu không kiểm tra và theo dõi các hiệu ứng chặt chẽ.

Một lựa chọn khác là cập nhật có chọn lọc các dịch vụ. Bạn luôn cần các gói mới nhất, ví dụ? Điều này quay trở lại để hiểu lý do của bạn để chạy cập nhật. Mục tiêu thực sự là gì?

Ưu điểm của việc chạy repo của riêng bạn là bạn có thể phát hành giai đoạn hoặc triển khai và quản lý lịch trình. Điều gì sẽ xảy ra nếu bạn có một nhà cung cấp phần mềm hoặc thiết bị ngoại vi phần cứng yêu cầu RHEL 5.6 và sẽ phá vỡ dưới 5.7? Đó là một trong những lợi ích để quản lý các gói của riêng bạn.

@Beaming Mel-Bin

Việc đơn giản hóa sẽ loại bỏ nhu cầu sử dụng ssh cho các công cụ vòng lặp, để bắt đầu / dừng rối.

Trước hết, bạn sẽ cần thay đổi bảng kê khai của mình để bao gồm một biến gọi là "noop" có giá trị được lấy từ ENC.

Vì vậy, bạn sẽ có một cái gì đó như thế này trong một lớp:

noop => $noop_status

Nơi noop_statusđược đặt trong ENC của bạn. Khi bạn đặt giá trị noop_statusthành true, tệp kê khai sẽ chỉ chạy ở chế độ noop.

Nếu bạn có 100 hoặc 1000 máy chủ lưu trữ, bạn có thể sử dụng ENC như Bảng điều khiển hoặc Foreman cho phép bạn thay đổi hàng loạt thông số cho nhiều máy chủ, bằng cách kế thừa chúng ở cấp độ "Nhóm máy chủ" hoặc "Miền". Sau đó, bạn có thể đặt giá trị thành "false" cho một số lượng nhỏ máy chủ thử nghiệm, ghi đè giá trị Nhóm máy chủ.

Với điều này, mọi thay đổi chỉ được áp dụng cho các máy chủ được chọn.

Thay đổi một tham số ở vị trí trung tâm có thể ảnh hưởng đến bất kỳ số lượng máy chủ nào mà không cần bật / tắt rối với ssh cho các công cụ vòng lặp. Bạn có thể chia máy chủ của mình thành nhiều nhóm để đảm bảo an toàn / quản lý.

Cũng lưu ý rằng thay vì số phiên bản Gói mã hóa cứng trong bảng kê khai, bạn có thể đặt chúng vào ENC. Và cũng giống như trên, bạn có thể chọn lọc áp dụng các thay đổi và quản lý triển khai.

Nếu bạn muốn có độ chi tiết cao hơn (và độ phức tạp), bạn thậm chí có thể có mỗi tham số lớp, như thế noop_status_apacheClassvà vân vân.

Điều này có thể khó quản lý hơn nếu bạn includelớp trong các lớp khác.

Giải pháp có thể dựa trên câu trả lời của @ voretaq7:

1. Số phiên bản mã cứng của các gói trong bảng puppetkê khai và duy trì các gói trong kho lưu trữ của chúng tôi.

2. Khi chúng tôi yêu cầu một phiên bản mới của gói làm điều gì đó mà nó cung cấp (ví dụ: cải tiến bảo mật, các tính năng được khách hàng yêu cầu, v.v.), chúng tôi tải gói xuống kho lưu trữ.

3. Kiểm tra gói cập nhật trên một máy chủ thử nghiệm.

4. Sau khi cập nhật được kiểm tra, hãy sử dụng một cái gì đó như funchoặc psshtắt puppettác nhân trên các nút bị ảnh hưởng.

5. Cập nhật các bảng puppetkê khai để đảm bảo rằng phiên bản mới của gói được cài đặt trên các nút bị ảnh hưởng.

6. Cuối cùng, chạy puppet agent --onetime && reboottrên máy chủ bằng funchoặcpssh

Hãy bình luận và cho tôi biết nếu bạn phát hiện ra bất kỳ thiếu sót nào trong giải pháp này hoặc bất cứ điều gì có thể được đơn giản hóa.