Một so sánh về sự bình đẳng và bất biến

Nhiều người trong DevOps áp dụng tâm lý không phải vật nuôi gia súc bằng cách triển khai cơ sở hạ tầng bất biến và triển khai lại khi cần thay đổi (thay vì sửa đổi).

Quản lý cấu hình có một nguyên tắc tương tự của idempotence . Những lợi ích so sánh, điểm tương đồng và nhược điểm của sự bất biến so với bất lực và cái nào hiệu quả hơn? Chúng có thể được sử dụng một cách tổng hợp (ví dụ: xóa định kỳ và triển khai lại các máy ảo hoặc bộ chứa Docker bằng cách sử dụng quản lý cấu hình không?)

Hai thuật ngữ rất khác nhau.

Chúng ta hãy bắt đầu với immutability, có nghĩa đen là "không có đột biến" hoặc "không thay đổi". Theo nghĩa của DevOps, điều đó có nghĩa là một khi bạn đã tạo ra một vật phẩm, có thể là hình ảnh chứa hoặc hình ảnh VM hoặc có thể là một gói từ mã được biên dịch - bạn tuyên bố rằng bạn sẽ không bao giờ thay đổi nó. Thông thường nếu có bất kỳ thay đổi nào là bắt buộc, bạn tuyên bố rằng một phiên bản mới của "điều" sẽ được tạo ra thay thế.

Thuật ngữ này idempotencecó nghĩa là khi thay đổi được áp dụng nhiều lần, trạng thái bị đột biến (thay đổi) chỉ một lần . Đầu tiên, nó đã giả định rằng sẽ có những thay đổi được áp dụng, điều đó có nghĩa là bạn không thể có một cái gì đó bất biến và có những hành động bình thường được thực hiện cho nó (không có hành động nào được thực hiện theo hợp đồng).

Trong việc sử dụng các công cụ quản lý cấu hình, idempotenceđược sử dụng trong một số trường hợp khi áp dụng cùng một thay đổi nhiều lần. Giống như thêm dòng nói localhostvào /etc/hoststệp, bạn không thực sự cần nhiều dòng như vậy và nếu một dòng đã tồn tại, sẽ không an toàn khi không thử nối lại.

Cũng idempotentlà một thuật ngữ được sử dụng để mô tả các hành động cố gắng thay đổi mọi thứ, trong khi immutableđược sử dụng để mô tả các danh từ (đối tượng) được đặt chống lại các thay đổi được thực hiện cho chúng.

Tại sao một immutableđối tượng hữu ích? Bởi vì khi bạn sao chép nó xung quanh, ví dụ từ môi trường dev sang qa để sản xuất. Bạn đã biết khá nhiều (nhưng không phải tất cả mọi thứ) liên quan đến cách nó sẽ hành xử. Trong nhiều trường hợp, các bộ phận đang hoạt động sẽ nhất quán và các bộ phận bị hỏng cũng sẽ phù hợp.

Tại sao idempotentcác hành động hữu ích? Bởi vì khi bạn muốn thay đổi trạng thái của một số đối tượng, trong nhiều trường hợp, chỉ hữu ích khi xác minh rằng thay đổi đã được áp dụng và áp dụng các thay đổi chỉ trong trường hợp bắt buộc. Ví dụ: khi một mục cấu hình trong tệp bị thiếu hoặc có giá trị sai, sẽ rất hữu ích khi thêm nó chỉ một lần hoặc thay đổi nó chỉ một lần trong khi áp dụng hành động nhiều lần. Trong nhiều trường hợp khác, như các tệp nhật ký , bạn không muốn có các hành động bình thường vì bạn thường muốn nối thêm một dòng khác mỗi khi một số sự kiện xảy ra.

Cơ sở hạ tầng không thay đổi, theo tôi, là một mô hình khác với Quản lý cấu hình. Trong khi chúng có thể được sử dụng cùng nhau, chúng tiếp cận các vấn đề theo bản chất theo hai cách khác nhau.

Khái niệm về tạo tác bất biến có một lịch sử lâu dài, các hệ thống Unix đã sử dụng chúng trong nhiều thập kỷ để triển khai các gói phần mềm. Nhưng một khi chúng được triển khai, các tệp cấu hình đã được thay đổi để mọi thứ trở nên có thể thay đổi. Idempotency cung cấp một số đảm bảo tốt đẹp với các tệp có thể thay đổi, chúng ta có thể biết khi nào mọi thứ đã thay đổi và chỉ cập nhật những thứ cần cập nhật. Tuy nhiên, nó không giải quyết được tất cả các vấn đề của các đối tượng có thể thay đổi, chúng ta vẫn cần phục vụ một số lượng các trường hợp cạnh dường như vô hạn. Bởi vì mọi thứ đều có thể thay đổi và chúng tôi đang bình tĩnh, chúng tôi cần thiết lập trước những thay đổi cần thực hiện, sau đó thực hiện chúng theo một thứ tự rất cụ thể. Khi triển khai các gói phần mềm, đặc biệt là với việc triển khai không có thời gian, chúng tôi cần phối hợp cẩn thận các thay đổi để ngăn chặn mọi yêu cầu bị hủy bỏ.

Sự phức tạp này cuối cùng có thể tránh được bằng cách triển khai các tạo tác bất biến thay vì thay đổi chúng tại chỗ, bởi vì chúng ta chỉ cần thay thế một đối tượng bằng một đối tượng khác (cho dù đó là nhị phân, hoặc container hoặc Máy ảo), đưa nó vào phục vụ và rút lại cái cũ . Đây chỉ là một ví dụ về việc triển khai thời gian xuống không.

Với những tiến bộ trong công cụ cho phép chúng tôi triển khai các tạo tác bất biến cho hàng ngàn hệ thống trong một khoảng thời gian rất nhỏ mà chúng tôi đang thấy bằng cách sử dụng các công cụ bất biến để quản lý các hệ thống khả thi hơn nhiều so với quản lý cấu hình. Tuy nhiên, công cụ chưa có và vẫn còn trường hợp sử dụng cho cả hai. Tôi đã nói về chủ đề này giải thích sự tiến triển tuyến tính từ hoàn toàn có thể thay đổi thành hoàn toàn bất biến, đó là một quang phổ và mỗi công ty sẽ chọn nơi phù hợp nhất với họ.