Gitops là gì? Tìm hiểu về Gitops và lợi ích của nó

Git trở thành một công cụ cho phép các công ty phần mềm quản lý toàn bộ kho công nghệ quản lý của họ. Ngày càng nhiều, các công ty đang sử dụng Git trong đó tất cả logic kinh doanh của họ sống trong Git và các quy trình tự động có thể biến kho git của họ thành phần mềm tích hợp và được triển khai.

Là một phần mở rộng tự nhiên cho (Infrastructure-as-Code) và Phân phối liên tục (Continuous Delivery), GitOps tập trung vào việc sử dụng Git làm source tin tưởng duy nhất cho hệ thống. Thay đổi về cơ sở hạ tầng và ứng dụng được thực hiện khai báo thông qua kho Git, với quy trình tự động đảm bảo trạng thái hiện tại của hệ thống phản ánh trạng thái trong repo.

Chúng ta đã bước vào thế giới của GitOps.

Gitops là gì?

GitOps là một xu hướng gần đây trong lĩnh vực triển khai liên tụcMục tiêu của nó dựa vào việc đưa các quy trình triển khai gần với các nguyên tắc phát triển phần mềm. Với một tập hợp các quy trình và công cụ được sử dụng bởi các nhà phát triển và nhóm vận hành, Gitops giúp cho việc đưa quá trình hoạt động của tổ chức đến với mục tiêu tất cả mọi thứ đều liên tục (không chỉ CI mà còn là các quá trình kiểm thử, phát hành, phát triển, phân tích, quản trị và nhiều thứ khác nữa)

Như tên gọi của nó, GitOps là tất cả về việc đặt Git làm trung tâm của các hoạt động trong đội/nhóm/doanh nghiệp.

Ý tưởng chính của GitOps là sử dụng Git để lưu trữ cấu hình toàn bộ cơ sở hạ tầng triển khai hoàn chỉnh cho một ứng dụng. Một tập hợp các file, sử dụng IAC , được sử dụng để phân bổ các tài nguyên cơ sở hạ tầng cần thiết, để định cấu hình việc triển khai và đảm bảo quá trình thực thi linh hoạt.

Điều này làm cho thông tin được lưu trữ trên Git trở thành nguồn cơ sở của toán bộ hạ tầng (source of truth) mà các ứng dụng phải tiếp cận và thực hiện xoay quanh nó.

Một ví dụ điển hình về công cụ Git Centric là Terraform của Hashicorp. Với Terraform, các nhà phát triển có thể định nghĩa toàn bộ cơ sở hạ tầng của họ dưới dạng mã code trong môi trường git của họ và quy mô các máy chủ một cách nhất quán và tự động với một bộ cấu hình nhất quán. Nó cũng giúp các nhóm phát triển hiểu các cấu hình máy chủ cơ bản bằng cách chỉ cần nhìn vào mã code và không phải đi vào bảng điều khiển console của nhà cung cấp đám mây của họ.

Các vấn đề liên quan đến Gitops

Quy trình CI và CD tách rời

Mục tiêu của phát triển của các ứng dụng mới trong hiện nay (modern application)tự động hóa hoàn toàn, đẩy DevOps lên mức tối đa, nơi các thay đổi đối với môi trường Production có thể được thực hiện một cách an toàn chỉ trong vài phút.

Mã code được đưa vào Production qua một Pipeline, được định nghĩa là một tập hợp các bước liên quan đến việc xây dựng các entity, thực hiện các bài kiểm tra testing và bảo mật, cũng như cung cấp các tài nguyên cơ bản để chạy code.
Có ba loại bước cổ điển: tích hợp (integration)phân phối (delivery) và sau đó triển khai (deployment):

  • tích hợp liên quan đến các thay đổi đối với mã, thay đổi kiểm thử vào một kho lưu trữ mã được chia sẻ
  • phân phối liên quan đến việc tải code lên các môi trường định nghĩa sẵn
  • triển khai là việc chuyển hệ thống ứng dụng sang sử dụng mã code mới được sử dụng bởi khách hàng cuối.

Cách tiếp cận GitOPs để thành công đòi hỏi phải tách riêng quá trình CI và CD, có nghĩa là việc tích hợp và phân phối (delivery)/ triển khai (deployment) được thực hiện một cách độc lập.

Khác biệt về bản chất giữa CI/CD

  • Tích hợp liên tục đòi hỏi phải hiểu cách xây dựng và biên dịch mã, chạy một số công cụ sẽ phân tích mã, thực hiện phân tích tĩnh và sáng tạo nhị phân, đồng thời đẩy mã đóng gói kết quả vào các repository. Hoạt động này không xem xét đến môi trường thực thi mục tiêu để thực thi đúng cách.
  • Ngược lại, triển khai liên tục là tất cả về việc di chuyển và thực thi các tệp nhị phân phần mềm trong một môi trường thực thi. Bước này không liên quan đến bất kỳ tạo nhị phân nào nữa nhưng yêu cầu phải biết, kết nối và tương tác với môi trường thực thi. Quá trình này có khả năng làm xáo trộn quá trình thực thi của các ứng dụng hiện có đang chạy trên cùng một môi trường, hoặc gây ra lỗi hoặc sự cố môi trường thực thi (ví dụ như do thiếu tài nguyên).

Một công cụ tích hợp liên tục ( Jenkins , CircleCI …) sẽ tập trung vào việc xây dựng các ứng dụng của bạn thành các tệp nhị phân (binary), khởi tạo một quy trình phân tích phức tạp, đảm bảo mã được phân tích kỹ lưỡng để đáp ứng các nguyên tắc bảo mật của bạn.

Mặt khác, một công cụ triển khai liên tục , như ArgoCD , Spinnaker và Flux CD sẽ tập trung vào việc triển khai hiệu quả khối lượng công việc của bạn, bao gồm các pattern triển khai nâng cao như triển khai blue/ green, canary. Các công cụ này cũng sẽ giúp bạn dễ dàng quay trở lại các lần triển khai trước đó nếu có sự cố trong quá trình thực hiện. Một công cụ CD cũng sẽ giám sát hệ thống để ngăn chặn sự trôi dạt cấu hình (configuration driff) .

Tăng tính bảo mật, bằng cách giảm nguy cơ xâm nhập.

  • Nếu CI và CD được tách biệt, Công cụ CI không cần được liên kết với môi trường đích nữa. Nó có thể tự giới hạn việc xây dựng các tệp nhị phân mà không có bất kỳ quyền nào để triển khai bất kỳ thứ gì. Điều này trái ngược với các phương pháp mà công cụ CI chịu trách nhiệm triển khai các mã nhị phân cho nền tảng mục tiêu.
  • Trong trường hợp này, nếu một quy trình nào đó bị xâm phạm (ví dụ như Jenkins được biết là có lỗ hổng), thì những kẻ tấn công cũng có thể truy cập vào hệ thống đang chạy của bạn và có khả năng gây ra thiệt hại lớn.
  • Với phân tách CI / CD, chỉ công cụ CD mới có quyền triển khai code. Điều này chắc chắn hạn chế tối thiểu quyền truy cập của người dùng.

Push và Pull

Có hai cách để triển khai quy trình CD, tùy thuộc vào người đang yêu cầu triển khai: PUSH so với PULL

Cách tiếp cận đầu tiên và đơn giản hơn là dựa trên mô hình push trong đó yêu cầu triển khai (deployment request) được tạo bởi Git. Trong mô hình này, khi kho cơ sở hạ tầng của bạn đang được thay đổi, điều này sẽ kích hoạt một tác vụ (task hoặc job) sẽ xem xét các thay đổi và triển khai hoặc loại bỏ chúng.

Quá trình này tương tự như một Công việc CI. Công việc triển khai chỉ được kích hoạt khi thực hiện thay đổi đối với kho lưu trữ.

Cách tiếp cận này sẽ hoạt động hầu hết thời gian, nhưng nó có hai sai sót:

  • việc triển khai chỉ được thực thi khi kho lưu trữ Git được sửa đổi. Nếu vì bất kỳ lý do gì, hệ thống đích đi chệch khỏi kho lưu trữ Git, điều này sẽ không được thay đổi cho đến lần commit tiếp theo trên Git.
  • về cơ bản mô hình này bắt chước một quy trình CI và thường được sử dụng khi một công cụ bên ngoài thực hiện việc triển khai. Trong trường hợp này, bạn sẽ cần cung cấp cho công cụ CD của mình tất cả thông tin đăng nhập cần thiết để triển khai ứng dụng trên hệ thống đích. Điều này có thể tạo ra một lỗ hổng bảo mật.

Sự khác biệt chính so với mô hình push là bây giờ công cụ CD sẽ theo dõi cả sự thay đổi giữa trạng thái mong muốn (trên Git repo) và trạng thái thực tế (hệ thống đích) và đảm bảo rằng trạng thái thực tế vẫn phù hợp với trạng thái mong muốn.

Điều này tránh để hệ thống đi chệch khỏi trạng thái mong muốn theo những cách không kiểm soát được. Ví dụ: nếu một nhà điều hành đang thực hiện thay đổi trực tiếp trên cơ sở hạ tầng do nhầm lẫn, điều này sẽ bị Công cụ CD xác định và chuyển trở lại trạng thái mong muốn được mô tả trong Git repo.

Về cơ bản, đây là điều làm cho một công cụ CD chuyên dụng khác với một Công cụ CI cổ điển như Jenkins chủ yếu thực hiện mô hình đẩy.

Chúng tôi đề xuất mô hình pull để nhận được đầy đủ lợi ích của GitOps:

  • khi các nền tảng thực thi có thể lập trình được sử dụng (như Kubernetes hoặc Openshift…)
  • khi bạn chọn công cụ mới như ArgoCD , Spinnaker , và FluxCD .

Tận dụng một giải pháp được sử dụng và triển khai rộng rãi hiện có, Git, đơn giản hóa việc áp dụng cách tiếp cận như vậy. Các thay đổi đối với hệ thống cuối cùng chỉ được thực hiện thông qua Git và không yêu cầu bất kỳ công cụ phức tạp nào dành riêng cho nền tảng. Điều này có khả năng tiếp cận những người trong nhóm hiện tại nhanh hơn và giảm rào cản gia nhập đối với các nhà phát triển mới.

Có toàn bộ cơ sở hạ tầng của bạn được mô tả trong máy chủ Git cũng giúp cải thiện tính portability (di động). Muốn hệ thống của bạn được triển khai đến cơ sở của khách hàng? Chỉ cần sao chép repo Git và triển khai nó ở nơi khác. Bạn muốn chuyển về quá trình triển khai trước đây? Chỉ cần kiểm tra một thẻ tag trước đây trên Git repo và bạn bắt đầu.

Cuối cùng, khi bạn tạo một đường dẫn trong đó cách duy nhất để cập nhật cơ sở hạ tầng của bạn được thực hiện thông qua Git, thì nhật ký cam kết Git của bạn sẽ trở thành dấu vết kiểm tra của bạn. Tất cả các khả năng được xây dựng xung quanh Git (so sánh lịch sử, nhật ký commit, tag, branch, v.v.) có thể được sử dụng để theo dõi các thay đổi được thực hiện đối với cơ sở hạ tầng của bạn. Điều này giúp đơn giản hóa đáng kể con đường tuân thủ của bạn, vì Git trở thành tâm điểm chú ý để thiết lập quy trình làm việc và quy tắc bảo mật.

Bằng cách biến Git trở thành trung tâm cho các hoạt động của mình, bạn cũng đang mở ra khả năng sử dụng các công cụ có thể tương tác với nó – một hệ sinh thái khổng lồ. Git giờ đã quá chuẩn hóa nên không có công cụ nào không tương thích với nó.

Git cùng với các công cụ triển khai phù hợp cho phép GitOps thực sự và mang lại cho bạn siêu năng lực bằng cách đơn giản hóa bối cảnh hoạt động.

Tham khảo:

https://ichi.pro/vi/gitops-xay-dung-cac-ung-dung-phuc-hoi-co-so-ha-tang-164633767380077#:~:text=Nh%C6%B0%20t%C3%AAn%20g%E1%BB%8Di%20c%E1%BB%A7a%20n%C3%B3,g%E1%BA%AFn%20th%E1%BA%BB%20v%C3%A0%20kh%C3%B4i%20ph%E1%BB%A5c.

Leave a Reply

Your email address will not be published. Required fields are marked *