Ghi chú. bản dịch.: Trong cộng đồng Kubernetes, một xu hướng có tên GitOps đang trở nên phổ biến rõ ràng, như cá nhân chúng tôi đã thấy, KubeCon Châu Âu 2019. Thuật ngữ này tương đối gần đây bởi người đứng đầu Weaworks - Alexis Richardson - và có nghĩa là việc sử dụng các công cụ quen thuộc với các nhà phát triển (chủ yếu là Git, do đó có tên) để giải quyết các vấn đề vận hành. Cụ thể, chúng ta đang nói về hoạt động của Kubernetes bằng cách lưu trữ cấu hình của nó trong Git và tự động triển khai các thay đổi đối với cụm. Matthias Jg nói về hai cách tiếp cận triển khai này trong bài viết này.
Năm ngoái, (trên thực tế, điều này chính thức xảy ra vào tháng 2017 năm XNUMX - ước chừng bản dịch) Có một cách tiếp cận mới để triển khai các ứng dụng trong Kubernetes. Nó được gọi là GitOps và dựa trên ý tưởng cơ bản là các phiên bản triển khai được theo dõi trong môi trường an toàn của kho lưu trữ Git.
Ưu điểm chính của phương pháp này như sau::
- Phiên bản triển khai và lịch sử thay đổi. Trạng thái của toàn bộ cụm được lưu trữ trong kho lưu trữ Git và việc triển khai chỉ được cập nhật thông qua các cam kết. Ngoài ra, tất cả các thay đổi có thể được theo dõi bằng lịch sử cam kết.
- Khôi phục bằng các lệnh Git quen thuộc... Trơn
git resetcho phép bạn đặt lại các thay đổi trong quá trình triển khai; các trạng thái trong quá khứ luôn có sẵn. - Kiểm soát truy cập sẵn sàng. Thông thường, một hệ thống Git chứa rất nhiều dữ liệu nhạy cảm nên hầu hết các công ty đều đặc biệt chú ý đến việc bảo vệ nó. Theo đó, biện pháp bảo vệ này cũng áp dụng cho các hoạt động có triển khai.
- Chính sách triển khai. Hầu hết các hệ thống Git về cơ bản đều hỗ trợ các chính sách theo từng nhánh—ví dụ: chỉ các yêu cầu kéo mới có thể cập nhật bản chính và các thay đổi phải được thành viên khác trong nhóm xem xét và chấp nhận. Giống như kiểm soát quyền truy cập, các chính sách tương tự cũng áp dụng cho các bản cập nhật triển khai.
Như bạn có thể thấy, phương pháp GitOps có rất nhiều lợi ích. Trong năm qua, hai cách tiếp cận đã trở nên phổ biến đặc biệt. Một cái dựa trên lực đẩy, cái còn lại dựa trên lực kéo. Trước khi xem xét chúng, trước tiên chúng ta hãy xem quá trình triển khai Kubernetes điển hình trông như thế nào.
Phương pháp triển khai
Trong những năm gần đây, Kubernetes đã thiết lập nhiều phương pháp và công cụ khác nhau để triển khai:
- Dựa trên các mẫu Kubernetes/Kustomize gốc. Đây là cách dễ nhất để triển khai ứng dụng trên Kubernetes. Nhà phát triển tạo các tệp YAML cơ bản và áp dụng chúng. Để loại bỏ việc phải liên tục viết lại các mẫu giống nhau, Kustomize đã được phát triển (nó biến các mẫu Kubernetes thành các mô-đun). Ghi chú. bản dịch.: Kustomize đã được tích hợp vào kubectl với .
- Biểu đồ Helm. Biểu đồ Helm cho phép bạn tạo các bộ mẫu, vùng chứa init, sidecar, v.v., được sử dụng để triển khai các ứng dụng với các tùy chọn tùy chỉnh linh hoạt hơn so với cách tiếp cận dựa trên mẫu. Phương pháp này dựa trên các tệp YAML theo khuôn mẫu. Helm điền vào chúng các tham số khác nhau rồi gửi chúng đến Tiller, một thành phần cụm triển khai chúng vào cụm và cho phép cập nhật cũng như khôi phục. Điều quan trọng là về cơ bản Helm chỉ chèn các giá trị mong muốn vào các mẫu và sau đó áp dụng chúng theo cách tương tự như cách thực hiện theo cách truyền thống (đọc thêm về cách hoạt động của tất cả và cách bạn có thể sử dụng nó trong - khoảng. dịch.). Có rất nhiều biểu đồ Helm được tạo sẵn bao gồm nhiều nhiệm vụ khác nhau.
- Công cụ thay thế. Có nhiều công cụ thay thế. Điểm chung của chúng là biến một số tệp mẫu thành tệp YAML có thể đọc được Kubernetes và sau đó sử dụng chúng.
Trong công việc của mình, chúng tôi liên tục sử dụng biểu đồ Helm cho các công cụ quan trọng (vì chúng đã có sẵn rất nhiều thứ, điều này giúp cuộc sống dễ dàng hơn nhiều) và các tệp Kubernetes YAML “thuần túy” để triển khai các ứng dụng của riêng chúng tôi.
Kéo và đẩy
Trong một bài viết blog gần đây của tôi, tôi đã giới thiệu công cụ , cho phép bạn cam kết các mẫu vào kho lưu trữ Git và cập nhật quá trình triển khai sau mỗi lần cam kết hoặc đẩy vùng chứa. Kinh nghiệm của tôi cho thấy rằng công cụ này là một trong những công cụ chính thúc đẩy phương pháp kéo, vì vậy tôi sẽ thường xuyên nhắc đến nó. Nếu bạn muốn biết thêm về cách sử dụng nó, ở đây .
Lưu ý! Tất cả lợi ích của việc sử dụng GitOps vẫn giống nhau cho cả hai phương pháp.
Cách tiếp cận dựa trên lực kéo
Cách tiếp cận kéo dựa trên thực tế là tất cả các thay đổi được áp dụng từ bên trong cụm. Có một nhà điều hành bên trong cụm thường xuyên kiểm tra kho lưu trữ Git và Docker Register được liên kết. Nếu có bất kỳ thay đổi nào xảy ra với chúng, trạng thái của cụm sẽ được cập nhật nội bộ. Quá trình này thường được coi là rất an toàn vì không có máy khách bên ngoài nào có quyền truy cập vào quyền quản trị viên cụm.
Ưu điểm:
- Không có khách hàng bên ngoài nào có quyền thực hiện các thay đổi đối với cụm; tất cả các bản cập nhật được triển khai từ bên trong.
- Một số công cụ cũng cho phép bạn đồng bộ hóa các cập nhật biểu đồ Helm và liên kết chúng với cụm.
- Docker Đăng ký có thể được quét để tìm phiên bản mới. Nếu có hình ảnh mới, kho lưu trữ và triển khai Git sẽ được cập nhật lên phiên bản mới.
- Các công cụ kéo có thể được phân phối trên các không gian tên khác nhau với các kho lưu trữ và quyền Git khác nhau. Nhờ đó, một mô hình nhiều người thuê có thể được sử dụng. Ví dụ: nhóm A có thể sử dụng không gian tên A, nhóm B có thể sử dụng không gian tên B và nhóm cơ sở hạ tầng có thể sử dụng không gian chung.
- Theo quy định, các công cụ này rất nhẹ.
- Kết hợp với các công cụ như toán tử , các bí mật có thể được lưu trữ dưới dạng mã hóa trong kho lưu trữ Git và được truy xuất trong cụm.
- Không có kết nối với đường dẫn CD do quá trình triển khai diễn ra trong cụm.
Nhược điểm:
- Việc quản lý các bí mật triển khai từ biểu đồ Helm khó hơn so với các biểu đồ thông thường, vì trước tiên chúng phải được tạo dưới dạng các bí mật được niêm phong, sau đó được giải mã bởi người vận hành nội bộ và chỉ sau đó chúng mới có sẵn cho công cụ kéo. Sau đó, bạn có thể chạy bản phát hành trong Helm với các giá trị trong các bí mật đã được triển khai. Cách dễ nhất là tạo một bí mật với tất cả các giá trị Helm được sử dụng để triển khai, giải mã nó và đưa nó vào Git.
- Khi bạn thực hiện phương pháp kéo, bạn sẽ bị ràng buộc với các công cụ kéo. Điều này hạn chế khả năng tùy chỉnh quy trình triển khai trong một cụm. Ví dụ: Kustomize rất phức tạp vì nó phải chạy trước khi các mẫu cuối cùng được chuyển giao cho Git. Tôi không nói rằng bạn không thể sử dụng các công cụ độc lập nhưng chúng khó tích hợp hơn vào quá trình triển khai của bạn.
Cách tiếp cận dựa trên lực đẩy
Trong phương pháp đẩy, một hệ thống bên ngoài (chủ yếu là các đường dẫn CD) sẽ triển khai các hoạt động triển khai tới cụm sau khi cam kết với kho lưu trữ Git hoặc nếu đường dẫn CI trước đó thành công. Theo cách tiếp cận này, hệ thống có quyền truy cập vào cụm.
Ưu điểm:
- Bảo mật được xác định bởi kho lưu trữ Git và đường dẫn xây dựng.
- Triển khai biểu đồ Helm dễ dàng hơn và hỗ trợ các plugin Helm.
- Bí mật dễ quản lý hơn vì bí mật có thể được sử dụng trong đường ống và cũng có thể được lưu trữ dưới dạng mã hóa trong Git (tùy thuộc vào sở thích của người dùng).
- Không có kết nối với một công cụ cụ thể vì bất kỳ loại nào cũng có thể được sử dụng.
- Cập nhật phiên bản vùng chứa có thể được bắt đầu bằng quy trình xây dựng.
Nhược điểm:
- Dữ liệu truy cập cụm nằm trong hệ thống xây dựng.
- Cập nhật vùng chứa triển khai vẫn dễ dàng hơn với quy trình kéo.
- Sự phụ thuộc nhiều vào hệ thống CD, vì các quy trình chúng tôi cần ban đầu có thể được viết cho Gitlab Runners, sau đó nhóm quyết định chuyển sang Azure DevOps hoặc Jenkins... và sẽ phải di chuyển một số lượng lớn quy trình xây dựng.
Kết quả: Đẩy hay kéo?
Như thường lệ, mỗi cách tiếp cận đều có ưu và nhược điểm. Một số nhiệm vụ dễ thực hiện hơn với nhiệm vụ này và khó khăn hơn với nhiệm vụ khác. Lúc đầu, tôi triển khai theo cách thủ công, nhưng sau khi xem một số bài viết về Weave Flux, tôi quyết định triển khai các quy trình GitOps cho tất cả các dự án. Đối với các mẫu cơ bản, điều này thật dễ dàng, nhưng sau đó tôi bắt đầu gặp khó khăn với biểu đồ Helm. Vào thời điểm đó, Weave Flux chỉ cung cấp phiên bản thô sơ của Helm Chart Operator, nhưng ngay cả bây giờ, một số nhiệm vụ còn khó khăn hơn do phải tạo bí mật và áp dụng chúng theo cách thủ công. Bạn có thể lập luận rằng phương pháp kéo an toàn hơn nhiều vì thông tin xác thực của cụm không thể truy cập được bên ngoài cụm, khiến nó an toàn hơn rất nhiều đến mức đáng để nỗ lực thêm.
Sau một hồi suy nghĩ, tôi đã đi đến một kết luận bất ngờ rằng không phải vậy. Nếu chúng ta nói về các thành phần yêu cầu bảo vệ tối đa, danh sách này sẽ bao gồm bộ lưu trữ bí mật, hệ thống CI/CD và kho lưu trữ Git. Thông tin bên trong chúng rất dễ bị tổn thương và cần được bảo vệ tối đa. Ngoài ra, nếu ai đó truy cập vào kho lưu trữ Git của bạn và có thể đẩy mã vào đó, họ có thể triển khai bất cứ thứ gì họ muốn (dù là kéo hay đẩy) và xâm nhập vào hệ thống của cụm. Do đó, các thành phần quan trọng nhất cần được bảo vệ là kho lưu trữ Git và hệ thống CI/CD chứ không phải thông tin xác thực của cụm. Nếu bạn có các chính sách và biện pháp kiểm soát bảo mật được cấu hình tốt cho các loại hệ thống này và thông tin xác thực cụm chỉ được trích xuất vào đường dẫn dưới dạng bí mật thì tính bảo mật bổ sung của phương pháp kéo có thể không có giá trị như suy nghĩ ban đầu.
Vì vậy, nếu phương pháp kéo tốn nhiều công sức hơn và không mang lại lợi ích bảo mật, thì việc chỉ sử dụng phương pháp đẩy có hợp lý không? Nhưng ai đó có thể lập luận rằng trong cách tiếp cận đẩy, bạn quá bị ràng buộc với hệ thống CD và có lẽ tốt hơn là không nên làm điều này để việc di chuyển trong tương lai sẽ dễ dàng hơn.
Theo tôi (như mọi khi), bạn nên sử dụng những gì phù hợp nhất cho một trường hợp cụ thể hoặc kết hợp. Cá nhân tôi sử dụng cả hai cách tiếp cận: Weave Flux để triển khai dựa trên kéo chủ yếu bao gồm các dịch vụ của riêng chúng tôi và cách tiếp cận đẩy với Helm và plugin, giúp dễ dàng áp dụng biểu đồ Helm cho cụm và cho phép bạn tạo bí mật một cách liền mạch. Tôi nghĩ sẽ không bao giờ có một giải pháp duy nhất phù hợp cho mọi trường hợp, bởi vì luôn có rất nhiều sắc thái và chúng phụ thuộc vào ứng dụng cụ thể. Nói như vậy, tôi thực sự khuyên dùng GitOps - nó giúp cuộc sống dễ dàng hơn rất nhiều và cải thiện tính bảo mật.
Tôi hy vọng trải nghiệm của tôi về chủ đề này sẽ giúp bạn quyết định phương pháp nào phù hợp hơn với loại hình triển khai của bạn và tôi rất vui khi nghe ý kiến của bạn.
PS Ghi chú của người dịch
Nhược điểm của mô hình kéo là khó đưa các bảng kê khai được hiển thị vào Git, nhưng không có nhược điểm nào là đường dẫn CD trong mô hình kéo tách biệt với quá trình triển khai và về cơ bản trở thành một đường dẫn danh mục Áp dụng liên tục. Do đó, sẽ cần nhiều nỗ lực hơn nữa để thu thập trạng thái của chúng từ tất cả các hoạt động triển khai và bằng cách nào đó cung cấp quyền truy cập vào nhật ký/trạng thái, tốt nhất là có tham chiếu đến hệ thống CD.
Theo nghĩa này, mô hình đẩy cho phép chúng tôi cung cấp ít nhất một số đảm bảo về quá trình triển khai, bởi vì thời gian tồn tại của quy trình có thể được coi là bằng thời gian triển khai.
Chúng tôi đã thử cả hai mô hình và đi đến kết luận giống như tác giả bài viết:
- Mô hình kéo phù hợp để chúng ta tổ chức cập nhật các thành phần hệ thống trên một số lượng lớn các cụm (xem phần XNUMX). ).
- Mô hình đẩy dựa trên GitLab CI rất phù hợp để triển khai các ứng dụng sử dụng biểu đồ Helm. Đồng thời, việc triển khai triển khai trong quy trình được giám sát bằng công cụ . Nhân tiện, trong bối cảnh dự án này của chúng tôi, chúng tôi đã nghe thấy “GitOps” liên tục khi thảo luận về các vấn đề cấp bách của các kỹ sư DevOps tại gian hàng của chúng tôi tại KubeCon Europe'19.
PPS từ người dịch
Đọc thêm trên blog của chúng tôi:
- «»;
- «»;
- «»;
- «'.
Chỉ những người dùng đã đăng ký mới có thể tham gia khảo sát. , xin vui lòng.
Bạn có đang sử dụng GitOps không?
-
Có, kéo cách tiếp cận
-
Có, đẩy
-
Có, kéo + đẩy
-
Vâng, cái gì đó khác
-
Không
30 người dùng bình chọn. 10 người dùng bỏ phiếu trắng.
Nguồn: www.habr.com