Ghi chú. bản dịch.: Sau lần xuất bản gần đây về các phương pháp kéo và đẩy trong GitOps, chúng tôi nhận thấy sự quan tâm đến mô hình này nói chung, nhưng có rất ít ấn phẩm bằng tiếng Nga về chủ đề này (đơn giản là không có ấn phẩm nào về Habré). Vì vậy, chúng tôi rất vui được cung cấp cho bạn bản dịch của một bài viết khác - mặc dù đã gần một năm trước! — từ Weaworks, người đứng đầu công ty này đã đặt ra thuật ngữ “GitOps”. Văn bản giải thích bản chất của phương pháp tiếp cận và những khác biệt chính so với những phương pháp hiện có.
Một năm trước chúng tôi đã xuất bản . Trước đó, chúng tôi đã chia sẻ cách nhóm Weaworks khởi chạy SaaS hoàn toàn dựa trên Kubernetes và phát triển một tập hợp các biện pháp thực hành tốt nhất mang tính quy định để triển khai, quản lý và giám sát trong môi trường gốc đám mây.
Bài báo đã trở nên phổ biến. Những người khác bắt đầu nói về GitOps và bắt đầu xuất bản các công cụ mới cho , , , , và như thế. Đã xuất hiện trên trang web của chúng tôi các ấn phẩm và trường hợp sử dụng GitOps. Nhưng một số người vẫn còn thắc mắc. Mô hình này khác với mô hình truyền thống như thế nào? và giao hàng liên tục ()? Có cần thiết phải sử dụng Kubernetes không?
Chúng tôi sớm nhận ra rằng cần có một mô tả mới, cung cấp:
- Một số lượng lớn các ví dụ và câu chuyện;
- Định nghĩa cụ thể về GitOps;
- So sánh với phân phối liên tục truyền thống.
Trong bài viết này, chúng tôi đã cố gắng đề cập đến tất cả các chủ đề này. Nó cung cấp phần giới thiệu cập nhật về GitOps cũng như quan điểm của nhà phát triển và CI/CD. Chúng tôi chủ yếu tập trung vào Kubernetes, mặc dù mô hình này có thể được khái quát hóa.
Gặp gỡ GitOps
Hãy tưởng tượng Alice. Cô điều hành Bảo hiểm Gia đình, chuyên cung cấp bảo hiểm sức khỏe, ô tô, nhà ở và du lịch cho những người quá bận rộn không thể tự mình tìm hiểu các nội dung chi tiết của hợp đồng. Công việc kinh doanh của cô bắt đầu như một dự án phụ khi Alice đang làm việc tại một ngân hàng với tư cách là nhà khoa học dữ liệu. Một ngày nọ, cô nhận ra rằng mình có thể sử dụng các thuật toán máy tính tiên tiến để phân tích dữ liệu và xây dựng các gói bảo hiểm hiệu quả hơn. Các nhà đầu tư đã tài trợ cho dự án và hiện công ty của cô mang về hơn 20 triệu USD mỗi năm và đang phát triển nhanh chóng. Hiện tại, công ty có 180 người ở nhiều vị trí khác nhau. Điều này bao gồm một nhóm công nghệ phát triển, duy trì trang web, cơ sở dữ liệu và phân tích cơ sở khách hàng. Đội ngũ gồm 60 người được lãnh đạo bởi Bob, giám đốc kỹ thuật của công ty.
Nhóm của Bob triển khai hệ thống sản xuất trên đám mây. Các ứng dụng cốt lõi của họ chạy trên GKE, tận dụng Kubernetes trên Google Cloud. Ngoài ra, họ còn sử dụng nhiều công cụ phân tích và dữ liệu khác nhau trong công việc của mình.
Bảo hiểm Gia đình không bắt đầu sử dụng container mà bị thu hút bởi sự nhiệt tình của Docker. Công ty sớm phát hiện ra rằng GKE khiến việc triển khai các cụm để thử nghiệm các tính năng mới trở nên dễ dàng. Jenkins cho CI và Quay đã được thêm vào để tổ chức đăng ký container, các tập lệnh được viết cho Jenkins để đẩy các container và cấu hình mới lên GKE.
Một thời gian đã trôi qua. Alice và Bob thất vọng với hiệu quả của phương pháp họ đã chọn cũng như tác động của nó đối với hoạt động kinh doanh. Việc sử dụng container không cải thiện năng suất nhiều như nhóm đã mong đợi. Đôi khi quá trình triển khai bị gián đoạn và không rõ liệu việc thay đổi mã có phải là nguyên nhân hay không. Hóa ra cũng khó theo dõi các thay đổi cấu hình. Thông thường, cần phải tạo một cụm mới và di chuyển các ứng dụng sang cụm đó vì đây là cách dễ nhất để loại bỏ tình trạng lộn xộn mà hệ thống đã trở thành. Alice lo sợ rằng tình hình sẽ trở nên tồi tệ hơn khi ứng dụng được phát triển (ngoài ra, một dự án mới dựa trên học máy đang được thực hiện). Bob đã tự động hóa hầu hết công việc và không hiểu tại sao quy trình vẫn không ổn định, quy mô không tốt và cần phải can thiệp thủ công định kỳ?
Sau đó, họ tìm hiểu về GitOps. Quyết định này hóa ra chính xác là những gì họ cần để tự tin tiến về phía trước.
Alice và Bob đã nghe nói về Git, DevOps và cơ sở hạ tầng dưới dạng quy trình làm việc mã trong nhiều năm. Điều độc đáo ở GitOps là nó mang đến một tập hợp các phương pháp thực hành tốt nhất—cả dứt khoát và chuẩn mực—để triển khai những ý tưởng này trong bối cảnh Kubernetes. Chủ đề này , bao gồm trong .
Bảo hiểm Gia đình quyết định triển khai GitOps. Công ty hiện có mô hình hoạt động tự động tương thích với Kubernetes và kết hợp tốc độ với sự ổn địnhvì họ:
- nhận thấy năng suất của nhóm tăng gấp đôi mà không có ai phát điên;
- đã ngừng phục vụ các tập lệnh. Thay vào đó, giờ đây họ có thể tập trung vào các tính năng mới và cải tiến các phương pháp kỹ thuật - ví dụ: giới thiệu các đợt triển khai canary và cải thiện hoạt động thử nghiệm;
- chúng tôi đã cải thiện quy trình triển khai để hiếm khi xảy ra sự cố;
- có cơ hội khôi phục hoạt động triển khai sau khi xảy ra lỗi một phần mà không cần can thiệp thủ công;
- mua đã qua sử dụngоNiềm tin lớn hơn vào hệ thống phân phối. Alice và Bob phát hiện ra rằng họ có thể chia nhóm thành các nhóm microservice hoạt động song song;
- có thể thực hiện 30-50 thay đổi cho dự án mỗi ngày thông qua nỗ lực của mỗi nhóm và thử nghiệm các kỹ thuật mới;
- thật dễ dàng để thu hút các nhà phát triển mới vào dự án, những người có cơ hội tung ra các bản cập nhật cho quá trình sản xuất bằng cách sử dụng các yêu cầu kéo trong vòng vài giờ;
- dễ dàng vượt qua kiểm toán trong khuôn khổ SOC2 (để tuân thủ các yêu cầu của nhà cung cấp dịch vụ về quản lý dữ liệu an toàn; đọc thêm, ví dụ: - khoảng. dịch.).
Chuyện gì đã xảy ra thế?
GitOps có hai thứ:
- Mô hình hoạt động cho Kubernetes và Cloud Native. Nó cung cấp một tập hợp các biện pháp thực hành tốt nhất để triển khai, quản lý và giám sát các cụm và ứng dụng được chứa trong vùng chứa. Định nghĩa thanh lịch trong hình thức từ :
- Con đường tạo ra môi trường quản lý ứng dụng lấy nhà phát triển làm trung tâm. Chúng tôi áp dụng quy trình làm việc Git cho cả hoạt động và phát triển. Xin lưu ý rằng đây không chỉ là về việc đẩy Git mà còn về việc tổ chức toàn bộ bộ công cụ CI/CD và UI/UX.
Một vài lời về Git
Nếu bạn không quen với các hệ thống kiểm soát phiên bản và quy trình làm việc dựa trên Git, chúng tôi khuyên bạn nên tìm hiểu về chúng. Làm việc với các nhánh và yêu cầu kéo lúc đầu có vẻ giống như ma thuật đen, nhưng lợi ích rất đáng để bạn nỗ lực. Đây để bắt đầu.
Kubernetes hoạt động như thế nào
Trong câu chuyện của chúng tôi, Alice và Bob đã chuyển sang GitOps sau khi làm việc với Kubernetes một thời gian. Thật vậy, GitOps có liên quan chặt chẽ với Kubernetes - đây là mô hình hoạt động cho cơ sở hạ tầng và ứng dụng dựa trên Kubernetes.
Kubernetes mang lại cho người dùng những gì?
Dưới đây là một số tính năng chính:
- Trong mô hình Kubernetes, mọi thứ đều có thể được mô tả ở dạng khai báo.
- Máy chủ API Kubernetes lấy phần khai báo này làm đầu vào, sau đó liên tục cố gắng đưa cụm về trạng thái được mô tả trong phần khai báo.
- Các khai báo là đủ để mô tả và quản lý nhiều loại khối lượng công việc khác nhau— “ứng dụng”.
- Do đó, những thay đổi đối với ứng dụng và cụm xảy ra do:
- thay đổi hình ảnh vùng chứa;
- thay đổi đặc tả khai báo;
- lỗi trong môi trường - ví dụ: sự cố vùng chứa.
Khả năng hội tụ tuyệt vời của Kubernetes
Khi quản trị viên thực hiện thay đổi cấu hình, bộ điều phối Kubernetes sẽ áp dụng chúng cho cụm miễn là trạng thái của nó là sẽ không đến gần với cấu hình mới. Mô hình này hoạt động với mọi tài nguyên Kubernetes và có thể mở rộng bằng Định nghĩa tài nguyên tùy chỉnh (CRD). Do đó, việc triển khai Kubernetes có các đặc tính tuyệt vời sau:
- Tự động hóa: Các bản cập nhật Kubernetes cung cấp cơ chế tự động hóa quá trình áp dụng các thay đổi một cách khéo léo và kịp thời.
- Sự hội tụ: Kubernetes sẽ tiếp tục thử cập nhật cho đến khi thành công.
- sự bình thường: Ứng dụng hội tụ lặp đi lặp lại dẫn đến cùng một kết quả.
- Chủ nghĩa quyết định: Khi đủ tài nguyên, trạng thái của cụm cập nhật chỉ phụ thuộc vào trạng thái mong muốn.
Cách thức hoạt động của GitOps
Chúng ta đã tìm hiểu đủ về Kubernetes để giải thích cách GitOps hoạt động.
Hãy quay lại với nhóm dịch vụ vi mô của Bảo hiểm Gia đình. Họ thường phải làm gì? Hãy xem danh sách bên dưới (nếu có bất kỳ mục nào trong đó có vẻ lạ hoặc không quen thuộc, vui lòng ngừng chỉ trích và ở lại với chúng tôi). Đây chỉ là ví dụ về quy trình làm việc dựa trên Jenkins. Có nhiều quy trình khác khi làm việc với các công cụ khác.
Điều chính là chúng tôi thấy rằng mỗi bản cập nhật đều kết thúc bằng những thay đổi đối với tệp cấu hình và kho Git. Những thay đổi này đối với Git khiến "toán tử GitOps" cập nhật cụm:
1.Quy trình làm việc: "Bản dựng Jenkins - nhánh chính'.
Danh sach cong viec:
- Jenkins đẩy các hình ảnh được gắn thẻ tới Quay;
- Jenkins đẩy biểu đồ cấu hình và Helm vào nhóm lưu trữ chính;
- Chức năng đám mây sao chép cấu hình và biểu đồ từ nhóm lưu trữ chính sang kho lưu trữ Git chính;
- Toán tử GitOps cập nhật cụm.
2. Bản dựng Jenkins - nhánh phát hành hoặc hotfix:
- Jenkins đẩy những hình ảnh không được gắn thẻ đến Quay;
- Jenkins đẩy biểu đồ cấu hình và Helm vào nhóm lưu trữ dàn dựng;
- Chức năng đám mây sao chép cấu hình và biểu đồ từ nhóm lưu trữ dàn dựng sang kho lưu trữ Git dàn dựng;
- Toán tử GitOps cập nhật cụm.
3. Xây dựng Jenkins - phát triển hoặc nhánh tính năng:
- Jenkins đẩy những hình ảnh không được gắn thẻ đến Quay;
- Jenkins đẩy biểu đồ cấu hình và Helm vào nhóm lưu trữ phát triển;
- Chức năng đám mây sao chép cấu hình và biểu đồ từ nhóm lưu trữ phát triển sang kho lưu trữ Git phát triển;
- Toán tử GitOps cập nhật cụm.
4. Thêm một khách hàng mới:
- Người quản lý hoặc quản trị viên (LCM/ops) gọi Gradle để triển khai và đặt cấu hình ban đầu cho bộ cân bằng tải mạng (NLB);
- LCM/ops cam kết một cấu hình mới để chuẩn bị triển khai các bản cập nhật;
- Toán tử GitOps cập nhật cụm.
Mô tả ngắn gọn về GitOps
- Mô tả trạng thái mong muốn của toàn bộ hệ thống bằng cách sử dụng các thông số kỹ thuật khai báo cho từng môi trường (trong câu chuyện của chúng tôi, nhóm của Bob xác định toàn bộ cấu hình hệ thống trong Git).
- Kho lưu trữ Git là nguồn thông tin chính xác duy nhất về trạng thái mong muốn của toàn bộ hệ thống.
- Tất cả các thay đổi về trạng thái mong muốn được thực hiện thông qua các cam kết trong Git.
- Tất cả các tham số cụm mong muốn cũng có thể được quan sát trong chính cụm đó. Bằng cách này chúng ta có thể xác định liệu chúng có trùng nhau hay không (hội tụ, tụ lại) hoặc khác nhau (phân kỳ, phân ra) trạng thái mong muốn và quan sát được.
- Nếu trạng thái mong muốn và trạng thái quan sát khác nhau thì:
- Có một cơ chế hội tụ sớm hay muộn sẽ tự động đồng bộ hóa mục tiêu và trạng thái được quan sát. Bên trong cụm, Kubernetes thực hiện việc này.
- Quá trình bắt đầu ngay lập tức với cảnh báo “đã cam kết thay đổi”.
- Sau một khoảng thời gian có thể định cấu hình, cảnh báo "khác" có thể được gửi nếu các trạng thái khác nhau.
- Bằng cách này, tất cả các cam kết trong Git đều tạo ra các cập nhật có thể kiểm chứng và bình thường cho cụm.
- Rollback là sự hội tụ về trạng thái mong muốn trước đó.
- Sự hội tụ là cuối cùng. Sự xuất hiện của nó được chỉ định bởi:
- Không có cảnh báo khác biệt trong một khoảng thời gian nhất định.
- cảnh báo "hội tụ" (ví dụ: webhook, sự kiện ghi lại Git).
sự khác biệt là gì?
Hãy lặp lại một lần nữa: tất cả các thuộc tính cụm mong muốn phải có thể quan sát được trong chính cụm đó.
Một số ví dụ về sự khác biệt:
- Thay đổi tệp cấu hình do hợp nhất các nhánh trong Git.
- Thay đổi trong tệp cấu hình do cam kết Git được thực hiện bởi máy khách GUI.
- Nhiều thay đổi về trạng thái mong muốn do PR trong Git, sau đó là xây dựng các thay đổi về hình ảnh và cấu hình vùng chứa.
- Sự thay đổi trạng thái của cụm do lỗi, xung đột tài nguyên dẫn đến "hành vi xấu" hoặc đơn giản là sai lệch ngẫu nhiên so với trạng thái ban đầu.
Cơ chế hội tụ là gì?
Một vài ví dụ:
- Đối với các container và cluster, cơ chế hội tụ được cung cấp bởi Kubernetes.
- Cơ chế tương tự có thể được sử dụng để quản lý các ứng dụng và thiết kế dựa trên Kubernetes (chẳng hạn như Istio và Kubeflow).
- Cơ chế quản lý tương tác hoạt động giữa Kubernetes, kho hình ảnh và Git cung cấp , đó là một phần .
- Đối với các máy cơ sở, cơ chế hội tụ phải có tính khai báo và tự trị. Từ kinh nghiệm của chính mình, chúng ta có thể nói rằng gần nhất với định nghĩa này nhưng vẫn cần có sự kiểm soát của con người. Theo nghĩa này, GitOps mở rộng truyền thống Cơ sở hạ tầng dưới dạng Mã.
GitOps kết hợp Git với công cụ hội tụ tuyệt vời của Kubernetes để cung cấp mô hình khai thác.
GitOps cho phép chúng tôi nói: Chỉ những hệ thống có thể được mô tả và quan sát mới có thể được tự động hóa và kiểm soát.
GitOps dành cho toàn bộ ngăn xếp gốc trên đám mây (ví dụ: Terraform, v.v.)
GitOps không chỉ là Kubernetes. Chúng tôi muốn toàn bộ hệ thống được điều khiển theo cách khai báo và sử dụng sự hội tụ. Theo toàn bộ hệ thống, chúng tôi muốn nói đến một tập hợp các môi trường hoạt động với Kubernetes - ví dụ: “dev cluster 1”, “production”, v.v. Mỗi môi trường bao gồm máy móc, cụm, ứng dụng cũng như giao diện cho các dịch vụ bên ngoài cung cấp dữ liệu, giám sát và v.v.
Lưu ý tầm quan trọng của Terraform đối với vấn đề khởi động trong trường hợp này. Kubernetes phải được triển khai ở đâu đó và sử dụng Terraform có nghĩa là chúng ta có thể áp dụng các quy trình làm việc GitOps tương tự để tạo lớp điều khiển làm nền tảng cho Kubernetes và ứng dụng. Đây là một thực hành tốt nhất hữu ích.
Có sự tập trung mạnh mẽ vào việc áp dụng các khái niệm GitOps cho các lớp trên Kubernetes. Hiện tại, có các giải pháp kiểu GitOps cho Istio, Helm, Ksonnet, OpenFaaS và Kubeflow, cũng như cho Pulumi, chẳng hạn, tạo ra một lớp để phát triển ứng dụng cho nền tảng đám mây.
Kubernetes CI/CD: so sánh GitOps với các phương pháp khác
Như đã nêu, GitOps có hai thứ:
- Mô hình hoạt động cho Kubernetes và Cloud Native được mô tả ở trên.
- Con đường dẫn đến môi trường quản lý ứng dụng lấy nhà phát triển làm trung tâm.
Đối với nhiều người, GitOps chủ yếu là một quy trình làm việc dựa trên các lần đẩy Git. Chúng tôi cũng thích anh ấy. Nhưng đó chưa phải là tất cả: bây giờ chúng ta hãy xem xét các quy trình CI/CD.
GitOps cho phép triển khai liên tục (CD) cho Kubernetes
GitOps cung cấp cơ chế triển khai liên tục giúp loại bỏ nhu cầu về “hệ thống quản lý triển khai” riêng biệt. Kubernetes thực hiện tất cả công việc cho bạn.
- Cập nhật ứng dụng yêu cầu cập nhật trong Git. Đây là một bản cập nhật giao dịch đến trạng thái mong muốn. Sau đó, việc "Triển khai" được chính Kubernetes thực hiện trong cụm dựa trên mô tả được cập nhật.
- Do tính chất hoạt động của Kubernetes nên các bản cập nhật này mang tính hội tụ. Điều này cung cấp một cơ chế triển khai liên tục trong đó tất cả các bản cập nhật đều mang tính nguyên tử.
- Lưu ý: cung cấp toán tử GitOps tích hợp Git và Kubernetes, đồng thời cho phép thực hiện CD bằng cách điều hòa trạng thái mong muốn và trạng thái hiện tại của cụm.
Không có kubectl và script
Bạn nên tránh sử dụng Kubectl để cập nhật cụm của mình và đặc biệt tránh sử dụng tập lệnh để nhóm các lệnh kubectl. Thay vào đó, với quy trình GitOps, người dùng có thể cập nhật cụm Kubernetes của họ thông qua Git.
Lợi ích bao gồm:
- Phải. Một nhóm các bản cập nhật có thể được áp dụng, hội tụ và cuối cùng được xác thực, đưa chúng ta đến gần hơn với mục tiêu triển khai nguyên tử. Ngược lại, việc sử dụng tập lệnh không mang lại bất kỳ sự đảm bảo nào về sự hội tụ (xem thêm về điều này bên dưới).
- Безопасность. Kelsey Hightower: “Hạn chế quyền truy cập vào cụm Kubernetes của bạn đối với các công cụ tự động hóa và quản trị viên chịu trách nhiệm gỡ lỗi hoặc bảo trì cụm đó.” Xem thêm về sự an toàn và tuân thủ các thông số kỹ thuật, cũng như bằng cách đánh cắp thông tin xác thực từ một tập lệnh Jenkins được viết một cách bất cẩn.
- Kinh nghiệm người dùng. Kubectl trình bày cơ chế của mô hình đối tượng Kubernetes khá phức tạp. Lý tưởng nhất là người dùng nên tương tác với hệ thống ở mức độ trừu tượng cao hơn. Ở đây tôi sẽ lại nhắc đến Kelsey và khuyên bạn nên xem .
Sự khác biệt giữa CI và CD
GitOps cải thiện các mô hình CI/CD hiện có.
Máy chủ CI hiện đại là một công cụ điều phối. Đặc biệt, nó là một công cụ để điều phối các đường ống CI. Chúng bao gồm xây dựng, kiểm tra, hợp nhất vào đường trục, v.v. Máy chủ CI tự động hóa việc quản lý các quy trình nhiều bước phức tạp. Một cách phổ biến là viết kịch bản cho một tập hợp các bản cập nhật Kubernetes và chạy nó như một phần của quy trình để đẩy các thay đổi đến cụm. Thực tế, đây là điều mà nhiều chuyên gia đã làm. Tuy nhiên, điều này không tối ưu và đây là lý do tại sao.
CI nên được sử dụng để đẩy các bản cập nhật lên đường trục và cụm Kubernetes sẽ tự thay đổi dựa trên các bản cập nhật đó để quản lý CD nội bộ. Chúng ta gọi nó , không giống như mô hình đẩy CI. CD là một phần điều phối thời gian chạy.
Tại sao máy chủ CI không nên tạo đĩa CD thông qua cập nhật trực tiếp trong Kubernetes
Không sử dụng máy chủ CI để sắp xếp các bản cập nhật trực tiếp lên Kubernetes dưới dạng một tập hợp các công việc CI. Đây là mô hình phản đối mà chúng ta đang nói đến trên blog của bạn.
Hãy quay trở lại với Alice và Bob.
Họ đã gặp phải những vấn đề gì? Máy chủ CI của Bob áp dụng các thay đổi cho cụm, nhưng nếu nó gặp sự cố trong quá trình này, Bob sẽ không biết cụm đó đang ở trạng thái (hoặc phải như thế nào) hoặc cách khắc phục nó. Điều tương tự cũng đúng trong trường hợp thành công.
Giả sử nhóm của Bob đã xây dựng một hình ảnh mới rồi vá lỗi triển khai của họ để triển khai hình ảnh đó (tất cả đều từ quy trình CI).
Nếu hình ảnh được xây dựng bình thường nhưng đường ống bị lỗi, nhóm sẽ phải tìm ra:
- Bản cập nhật đã được tung ra chưa?
- Chúng ta có đang tung ra một bản dựng mới không? Điều này có dẫn đến những tác dụng phụ không cần thiết - với khả năng có hai bản dựng của cùng một hình ảnh bất biến không?
- Chúng ta có nên đợi bản cập nhật tiếp theo trước khi chạy bản dựng không?
- Chính xác thì điều gì đã xảy ra? Những bước nào cần được lặp lại (và những bước nào an toàn để lặp lại)?
Việc thiết lập quy trình làm việc dựa trên Git không đảm bảo rằng nhóm của Bob sẽ không gặp phải những vấn đề này. Họ vẫn có thể mắc lỗi với lệnh đẩy cam kết, thẻ hoặc một số tham số khác; tuy nhiên, cách tiếp cận này vẫn gần hơn với cách tiếp cận tất cả hoặc không có gì rõ ràng.
Tóm lại, đây là lý do tại sao máy chủ CI không nên xử lý CD:
- Các tập lệnh cập nhật không phải lúc nào cũng mang tính quyết định; Rất dễ mắc sai lầm ở họ.
- Máy chủ CI không hội tụ về mô hình cụm khai báo.
- Rất khó để đảm bảo sự bình thường. Người dùng phải hiểu ngữ nghĩa sâu sắc của hệ thống.
- Việc phục hồi sau sự cố một phần sẽ khó khăn hơn.
Lưu ý về Helm: Nếu bạn muốn sử dụng Helm, chúng tôi khuyên bạn nên kết hợp nó với toán tử GitOps như . Điều này sẽ giúp đảm bảo sự hội tụ. Bản thân Helm không mang tính quyết định hay nguyên tử.
GitOps là cách tốt nhất để triển khai Phân phối liên tục cho Kubernetes
Nhóm của Alice và Bob triển khai GitOps và phát hiện ra rằng việc làm việc với các sản phẩm phần mềm đã trở nên dễ dàng hơn nhiều, duy trì hiệu suất cao và ổn định. Hãy kết thúc bài viết này bằng một minh họa cho thấy cách tiếp cận mới của họ trông như thế nào. Hãy nhớ rằng chúng ta chủ yếu nói về các ứng dụng và dịch vụ, nhưng GitOps có thể được sử dụng để quản lý toàn bộ nền tảng.
Mô hình hoạt động cho Kubernetes
Nhìn vào sơ đồ sau. Nó trình bày Git và kho lưu trữ hình ảnh vùng chứa dưới dạng tài nguyên được chia sẻ cho hai vòng đời được sắp xếp:
- Một đường dẫn tích hợp liên tục đọc và ghi tệp vào Git và có thể cập nhật kho lưu trữ hình ảnh vùng chứa.
- Quy trình GitOps thời gian chạy kết hợp triển khai với quản lý và khả năng quan sát. Nó đọc và ghi tập tin vào Git và có thể tải xuống hình ảnh vùng chứa.
Những phát hiện chính là gì?
- Tách biệt mối quan tâm: Xin lưu ý rằng cả hai đường dẫn chỉ có thể giao tiếp bằng cách cập nhật Git hoặc kho lưu trữ hình ảnh. Nói cách khác, có một tường lửa giữa CI và môi trường thời gian chạy. Chúng tôi gọi nó là "tường lửa bất biến" (tường lửa bất biến), vì tất cả các bản cập nhật kho lưu trữ đều tạo ra phiên bản mới. Để biết thêm thông tin về chủ đề này, hãy tham khảo slide 72-87 .
- Bạn có thể sử dụng bất kỳ máy chủ CI và Git nào: GitOps hoạt động với mọi thành phần. Bạn có thể tiếp tục sử dụng máy chủ CI và Git, kho lưu trữ hình ảnh và bộ thử nghiệm yêu thích của mình. Hầu như tất cả các công cụ Phân phối liên tục khác trên thị trường đều yêu cầu máy chủ CI/Git hoặc kho lưu trữ hình ảnh riêng. Điều này có thể trở thành một yếu tố hạn chế trong sự phát triển của Cloud Native. Với GitOps, bạn có thể sử dụng các công cụ quen thuộc.
- Sự kiện như một công cụ tích hợp: Ngay sau khi dữ liệu trong Git được cập nhật, Weave Flux (hoặc toán tử Weave Cloud) sẽ thông báo thời gian chạy. Bất cứ khi nào Kubernetes chấp nhận một bộ thay đổi, Git sẽ được cập nhật. Điều này cung cấp một mô hình tích hợp đơn giản để tổ chức quy trình làm việc cho GitOps, như hiển thị bên dưới.
Kết luận
GitOps cung cấp các đảm bảo cập nhật mạnh mẽ được yêu cầu bởi bất kỳ công cụ CI/CD hiện đại nào:
- tự động hóa;
- sự hội tụ;
- sự bình thường;
- chủ nghĩa quyết định.
Điều này rất quan trọng vì nó cung cấp mô hình hoạt động cho các nhà phát triển bản địa trên nền tảng đám mây.
- Các công cụ truyền thống để quản lý và giám sát hệ thống được liên kết với các nhóm vận hành hoạt động trong một sổ quản lý (một tập hợp các thủ tục và hoạt động thông thường - khoảng. bản dịch.), gắn liền với một triển khai cụ thể.
- Trong quản lý gốc trên nền tảng đám mây, các công cụ có thể quan sát là cách tốt nhất để đo lường kết quả triển khai để nhóm phát triển có thể phản hồi nhanh chóng.
Hãy tưởng tượng nhiều cụm nằm rải rác trên các đám mây khác nhau và nhiều dịch vụ với các nhóm và kế hoạch triển khai riêng. GitOps cung cấp một mô hình bất biến quy mô để quản lý tất cả sự phong phú này.
Tái bút 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ó biết về GitOps trước khi hai bản dịch này xuất hiện trên Habré không?
-
Vâng, tôi đã biết mọi thứ
-
Chỉ bề ngoài thôi
-
Không
35 người dùng bình chọn. 10 người dùng bỏ phiếu trắng.
Nguồn: www.habr.com