Cập nhật sản xuất hộp Ubuntu số lượng và không nên

Mỗi lần tôi thường đăng nhập vào hộp sản xuất web / db / tools và xem thông báo tiêu biểu:

30 gói có thể được cập nhật. 16 cập nhật là cập nhật bảo mật.

Câu hỏi của tôi là, làm thế nào để tất cả các bạn xử lý các bản cập nhật trên các hộp Ubuntu sản xuất của bạn? Bạn có tự động hóa các bản cập nhật này? Bạn có đặt thời gian chết cho họ không? Vấn đề là, bạn không bao giờ biết khi nào một bản cập nhật sẽ phá vỡ một cái gì đó, chẳng hạn như có thể là một tệp cấu hình hiện có, v.v.

Một phần khác của vấn đề này là, theo kịp các bản vá là "một điều tốt", nhưng các bản vá được phát hành gần như hàng ngày. Có bao nhiêu lần mất điện theo lịch trình mà một người phải thực hiện nếu có một bản vá bảo mật mới có sẵn mỗi ngày?

Tôi nghĩ rằng một chủ đề về câu trả lời như cách bạn quản lý các cập nhật của bạn sẽ rất hữu ích.

Không có gì đặc biệt về việc vá Ubuntu so với Windows, RHEL, CentOS, SuSE, debian, v.v.

Trạng thái cơ bản của tâm trí bạn cần có khi thiết kế quy trình vá lỗi của mình là giả định một cái gì đó sẽ bị phá vỡ.

Một số nguyên tắc cơ bản tôi có xu hướng sử dụng khi thiết kế thiết lập bản vá là:

• Luôn sử dụng một hệ thống cục bộ để tập trung nội bộ vào mạng của bạn, nơi các bản vá được cài đặt từ

Điều này có thể bao gồm sử dụng WSUS hoặc nhân <your_os_here>bản của máy quản lý bản vá nội bộ. Tốt nhất là có thể truy vấn tập trung và cho bạn biết trạng thái của các bản vá được cài đặt trên các máy cá nhân của bạn.

• Giai đoạn trước cài đặt - khi có thể - trên máy.

Khi có thể, khi các bản vá xuất hiện, máy chủ trung tâm sẽ sao chép chúng xuống các máy riêng lẻ. Đây thực sự chỉ là một trình tiết kiệm thời gian để bạn không phải chờ họ tải xuống VÀ cài đặt, bạn chỉ cần khởi động cài đặt trong cửa sổ vá lỗi của mình.

• Nhận một cửa sổ ngừng hoạt động để cài đặt các bản vá, bạn có thể phải khởi động lại, và một cái gì đó có thể sẽ bị hỏng. Hãy chắc chắn rằng những người nắm giữ cổ phần cho các hệ thống đó biết rằng có các bản vá đang được triển khai. Hãy chuẩn bị cho "cuộc gọi" này không hoạt động.

Theo lý thuyết cơ bản của tôi rằng các bản vá sẽ phá vỡ mọi thứ, hãy đảm bảo bạn có một cửa sổ ngừng hoạt động để áp dụng các bản vá đủ lâu để khắc phục các sự cố nghiêm trọng và có thể khôi phục lại bản vá. Bạn không cần phải có người ngồi thử nghiệm sau khi vá. Cá nhân tôi phụ thuộc rất nhiều vào các hệ thống giám sát của mình để cho tôi biết mọi thứ đang hoạt động ở mức tối thiểu mà chúng ta có thể thoát khỏi. Nhưng cũng nên chuẩn bị cho những vấn đề dai dẳng được gọi khi mọi người đi làm. Bạn nên luôn luôn có ai đó được lên lịch để sẵn sàng trả lời điện thoại - tốt nhất không phải là người thức đến 3 giờ sáng để vá các hộp.

• tự động hóa càng nhiều càng tốt

Giống như mọi thứ khác trong CNTT, kịch bản, kịch bản rồi kịch bản thêm một số. Script tải gói, bắt đầu cài đặt, nhân bản. Về cơ bản, bạn muốn biến các cửa sổ vá thành một bài tập ngồi cho em bé chỉ cần một con người ở đó trong trường hợp mọi thứ bị phá vỡ.

• Có nhiều cửa sổ mỗi tháng

Điều này cung cấp cho bạn khả năng không vá một số máy chủ nếu vì bất kỳ lý do gì chúng không thể được vá vào "đêm được chỉ định". Nếu bạn không thể thực hiện chúng vào đêm 1, yêu cầu chúng miễn phí vào đêm 2. Ngoài ra, hãy cho phép bạn giữ số lượng máy chủ được vá cùng lúc.

Quan trọng nhất là theo kịp với các bản vá! Nếu bạn không thấy mình phải làm những cửa sổ vá lớn hơn 10 giờ chỉ để quay lại điểm mà bạn bị bắt. Giới thiệu nhiều điểm hơn nữa, nơi mọi thứ có thể đi sai, và làm cho việc tìm ra bản vá nào gây ra và vấn đề khó khăn hơn nhiều.

Một phần khác của vấn đề này là, theo kịp các bản vá là "một điều tốt", nhưng các bản vá được phát hành gần như hàng ngày. Có bao nhiêu lần mất điện theo lịch trình mà một người phải thực hiện nếu có một bản vá bảo mật mới có sẵn mỗi ngày?

Vá máy chủ mỗi tháng một lần hoặc mỗi tháng một lần là - IMHO - một mục tiêu rất khả thi và có thể chấp nhận được. Hơn thế nữa, và bạn sẽ liên tục vá máy chủ, ít hơn nhiều và bạn bắt đầu gặp phải tình huống bạn có hàng trăm bản vá cần được áp dụng cho mỗi máy chủ.

Có bao nhiêu cửa sổ bạn cần một tháng? Điều đó phụ thuộc vào môi trường của bạn. Bạn có bao nhiêu máy chủ Thời gian lên cần thiết cho sever của bạn là gì?

Các môi trường nhỏ hơn 9x5 có thể có thể thoát khỏi một cửa sổ vá mỗi tháng. Cửa hàng lớn 24x7 có thể cần hai. 24x7x365 rất lớn có thể cần một cửa sổ cuộn mỗi tuần để có một bộ máy chủ khác nhau được vá mỗi tuần.

Tìm một tần số phù hợp với bạn và môi trường của bạn.

Một điều cần lưu ý là 100% cập nhật là mục tiêu không thể đạt được - đừng để bộ phận an ninh của bạn nói với bạn bằng cách khác. Làm hết sức, đừng để quá xa phía sau.

Những việc cần làm:

1. Sao lưu
2. Hãy chắc chắn rằng đó là một bản sao lưu đáng tin cậy (mặc dù, hai điều này là điểm chung)
3. Cố gắng hướng lưu lượng truy cập ra khỏi hộp sản xuất trong khi bạn nâng cấp.
4. Cố gắng có một phương thức truy cập ngoài băng trong trường hợp tất cả đều sai, KVM, bảng điều khiển nối tiếp, Truy cập cục bộ hoặc điều khiển từ xa.
5. Kiểm tra trên một máy chủ, sau đó đảm bảo mọi thứ hoạt động, trước khi triển khai các bản cập nhật lên nhiều máy chủ hơn
6. Sử dụng con rối nếu bạn có thể để đảm bảo số phiên bản giống nhau trên nhiều máy chủ. (Bạn cũng có thể sử dụng nó để buộc nâng cấp)
7. Trên máy chủ thử nghiệm, tìm các phiên bản của tệp cấu hình so với phiên bản mới (đã cài đặt bản cập nhật) và đảm bảo không có gì nghiêm trọng phá vỡ mọi thứ. Tôi dường như nhớ lại dpkg hỏi trước khi cài đặt các phiên bản mới khác với các phiên bản hiện được cài đặt.

Những điều cần tránh:

1. Thực hiện cập nhật vào giữa ngày, hoặc 09:00 vào buổi sáng thứ hai, hoặc 5 giờ chiều vào chiều thứ sáu! (cảm ơn @ 3influence!)
2. Nâng cấp MySQL trên các máy chủ cơ sở dữ liệu thực sự lớn (khởi động lại có thể mất nhiều thời gian)
3. Làm tất cả các máy chủ của bạn cùng một lúc (đặc biệt là hạt nhân)
4. Làm bất cứ điều gì có thể thay đổi / etc / mạng (vì bạn có thể mất kết nối)
5. Cập nhật tự động có thể làm như trên mà không cần bạn ở đó để kiểm tra mọi thứ đều ổn.

Một điểm đáng giá khác: Nếu bạn đã quen với Windows, bạn sẽ ngạc nhiên khi hầu hết các bản cập nhật Linux không yêu cầu thời gian chết hoặc khởi động lại. Một số làm, chẳng hạn như cập nhật kernel. Nhưng các bản cập nhật yêu cầu khởi động lại hoặc thời gian chết thường được gắn cờ như vậy và có thể được xử lý theo một lịch trình riêng.

Các máy Ubuntu của chúng tôi đều đang chạy các bản phát hành LTS.

Chúng tôi chỉ tự động cài đặt tất cả các bản cập nhật - chắc chắn đó không phải là "thực tiễn tốt nhất", nhưng chúng tôi là một cửa hàng tương đối nhỏ và không có môi trường thử nghiệm / phát triển / sản xuất cho mỗi dịch vụ. Các bản cập nhật LTS thường được kiểm tra khá tốt và ít xâm lấn nhất.

Nâng cấp lên bản phát hành mới rõ ràng là tham gia nhiều hơn một chút.

Chúng tôi xử lý các bản cập nhật theo cách sau cho các hệ thống LTS của Ubuntu:

1. Maitain một bộ các bài kiểm tra chấp nhận kiểm tra tất cả các đường dẫn quan trọng trong phần mềm của chúng tôi
2. Cài đặt nâng cấp bảo mật không giám sát vào lúc 4 giờ sáng mỗi ngày và ngay lập tức chạy thử nghiệm chấp nhận. Nếu bất cứ điều gì thất bại, một kỹ sư được phân trang và có nhiều thời gian để sửa chữa mọi thứ hoặc quay trở lại trước 9 giờ sáng. Điều này cho đến nay chỉ xảy ra hai lần trong năm năm - LTS được thử nghiệm tốt và ổn định.
3. Chúng tôi tự động triển khai lại toàn bộ cơ sở hạ tầng của mình mỗi tuần (trên Digitalocean) với các triển khai màu xanh / xanh, giữ tất cả các gói ở phiên bản mới nhất của chúng. Nếu một triển khai mới thất bại trong các thử nghiệm chấp nhận, việc triển khai bị hoãn cho đến khi một kỹ sư có thể gỡ lỗi vấn đề.

Bước hợp lý tiếp theo đối với chúng tôi là loại bỏ thông tin phiên trong bộ nhớ để chúng tôi có thể đơn giản triển khai lại cơ sở hạ tầng mỗi ngày hoặc thậm chí nhiều lần mỗi ngày mà không ảnh hưởng đến khách hàng và loại bỏ bước (2).

Cách tiếp cận này là bảo trì thấp và tránh hoàn toàn các cửa sổ bảo trì.

Một điều tôi khuyên bạn nên xử lý rollback của các gói. Xem Giao dịch và Phục hồi với Debian để biết gợi ý về cách thực hiện, vì đôi khi bạn cần một bản sửa lỗi nhanh để nâng cấp phá vỡ thứ gì đó.