GITOPS
Bản dịch tiếng Anh từ: https://www.gitops.tech/
Kể từ khi ra đời vào năm 2017 bởi Weaveworks, GitOps đã gây ra khá nhiều ồn ào trên Twitter và KubeCon. Bài viết này tổng hợp bản chất của GitOps để giúp giải tỏa các nhầm lẫn về chủ đề này.
GITOPS BOOK
Chúng tôi vừa phát hành cuốn sách của mình về GitOps. Tải xuống dưới dạng PDF hoặc ePub (giảm giá 50%), Kindle ebook hoặc sách giấy.
GITOPS LÀ GÌ?
GitOps là một cách thực hiện Triển khai liên tục cho các ứng dụng cloud native. Nó tập trung vào trải nghiệm lấy developer làm trung tâm khi vận hành cơ sở hạ tầng, bằng cách sử dụng các công cụ mà các developer đã quen thuộc, bao gồm các Git và Continuous Deployment.
Ý tưởng cốt lõi của GitOps là có một Git repository luôn chứa các mô tả khai báo về cơ sở hạ tầng hiện tại trong production environment và một quy trình tự động để làm cho production environment khớp với trạng thái đang được định nghĩa trong các mô tả. Nếu muốn triển khai một ứng dụng mới hoặc cập nhật một ứng dụng hiện có, bạn chỉ cần cập nhật repository – sau đó các quy trình tự động xử lý mọi thứ khác.
GitOps là một khuôn khổ hoạt động sử dụng các phương pháp hay nhất của DevOps để phát triển ứng dụng như kiểm soát phiên bản, cộng tác, tuân thủ và CI / CD để áp dụng cho việc tự động hóa cơ sở hạ tầng.
GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation.
— What is GitOps?
TẠI SAO TÔI NÊN SỬ DỤNG GITOPS?
TRIỂN KHAI NHANH HƠN THƯỜNG XUYÊN HƠN
Được rồi, công bằng mà nói, có lẽ mọi công nghệ Triển khai liên tục đều hứa hẹn giúp triển khai nhanh hơn và cho phép triển khai thường xuyên hơn. Điểm độc đáo của GitOps là bạn không phải chuyển đổi các công cụ để triển khai ứng dụng của mình. Mọi thứ xảy ra trong hệ thống kiểm soát phiên bản mà bạn sử dụng để phát triển ứng dụng.
Khi nói “nhanh hơn“, chúng tôi muốn nói rằng mọi nhóm sản phẩm có thể gửi các bản cập nhật nhiều lần một ngày một cách an toàn – triển khai ngay lập tức, quan sát kết quả trong thời gian thực và sử dụng phản hồi này để di chuyển về phía trước hoặc phía sau.
KHÔI PHỤC LỖI DỄ DÀNG VÀ NHANH CHÓNG
Ôi không! Môi trường production đang ngừng hoạt động! Với GitOps, bạn có toàn bộ lịch sử về cách môi trường thay đổi theo thời gian. Điều này giúp cho việc khôi phục lỗi trở nên dễ dàng như sử dụng git revert để giúp khôi phục môi trường về trạng thái trước khi bị lỗi.
Git record không chỉ là nhật ký commit mà còn là nhật ký giao dịch. Bạn có thể roll-back tới lui bất kỳ snapshot nào.
— Alexis Richardson
QUẢN LÝ THÔNG TIN CREDENTIAL DỄ DÀNG HƠN
GitOps cho phép quản lý việc triển khai hoàn toàn từ bên trong môi trường. Đối với điều đó, môi trường của bạn chỉ cần quyền truy cập vào repository và image registry. Không cần phải cấp cho các developer quyền truy cập trực tiếp vào môi trường.
kubectl là ssh mới. Giới hạn quyền truy cập và chỉ sử dụng nó để triển khai khi không có công cụ tốt hơn.
— Kelsey Hightower
SELF-DOCUMENTING DEPLOYMENTS
Đã bao giờ bạn SSH vào một máy chủ và tự hỏi những gì đang chạy ở đó? Với GitOps, mọi thay đổi đối với bất kỳ môi trường nào đều phải diễn ra thông qua repository. Bạn luôn có thể kiểm tra master branch và nhận được mô tả đầy đủ về những gì được triển khai cộng với lịch sử đầy đủ của mọi thay đổi từng được thực hiện đối với hệ thống.
KIẾN THỨC ĐƯỢC CHIA SẺ TRONG NHÓM
Việc sử dụng Git để lưu trữ các mô tả về cơ sở hạ tầng đang được triển khai cho phép mọi người trong nhóm kiểm tra sự phát triển của nó theo thời gian. Với các thông điệp cam kết tuyệt vời, mọi người có thể tái tạo quá trình của việc thay đổi cơ sở hạ tầng và cũng có thể dễ dàng tìm thấy các ví dụ về cách từng bước thiết lập hệ thống mới.
GitOps là thứ tốt nhất kể từ configuration as code. Git đã thay đổi cách chúng ta cộng tác, configuration as code là chìa khóa để xử lý cơ sở hạ tầng trên quy mô lớn và tạo tiền đề cho thế hệ công cụ quản lý tiếp theo.
— Kelsey Hightower
GITOPS HOẠT ĐỘNG NHƯ THẾ NÀO?
CẤU HÌNH MÔI TRƯỜNG DƯỚI DẠNG GIT REPOSITORY
GitOps tổ chức quá trình triển khai lấy repository làm trung tâm. Có ít nhất hai repository: repository cho ứng dụng (application repository) và repository cho cấu hình môi trường (environment repository). Repository ứng dụng chứa mã nguồn của ứng dụng và deployment manifests để triển khai ứng dụng. Environment repository chứa tất cả các deployment manifests của cơ sở hạ tầng được triển khai. Nó mô tả các ứng dụng và dịch vụ cơ sở hạ tầng (message broker, service mesh, monitoring tool, …) sẽ chạy với cấu hình và phiên bản nào trong môi trường đang triển khai.
PUSH-BASED VS. PULL-BASED DEPLOYMENTS
Có hai cách để thực hiện chiến lược triển khai GitOps: Push-based và Pull-based deployments. Sự khác biệt giữa hai loại triển khai là cách nó được đảm bảo, rằng môi trường triển khai thực sự giống với cơ sở hạ tầng mong muốn. Khi có thể, phương pháp tiếp cận Pull-based nên được ưu tiên hơn vì nó được coi là an toàn hơn và do đó tốt hơn để triển khai GitOps.
PUSH-BASED DEPLOYMENTS
Chiến lược triển khai Push-based được thực hiện bởi các công cụ CI / CD phổ biến như Jenkins, CircleCI hoặc Travis CI. Mã nguồn của ứng dụng nằm trong application repository cùng với các file Kubernetes YAML cần thiết để triển khai ứng dụng. Bất cứ khi nào mã ứng dụng được cập nhật, build pipeline sẽ được kích hoạt để build các các container images và cuối cùng là environment repository được cập nhật với các bộ mô tả triển khai mới.
Khi có thay đổi trong environment repository, quá trình triển khai sẽ được kích hoạt. Với cách tiếp cận này, việc cung cấp thông tin xác thực cho môi trường triển khai là không thể thiếu. Vì vậy, các pipeline đã được kích hoạt chế độ God-mode khi nắm quyền truy cập và thông tin xác thực vào các môi trường. Trong một số trường hợp, việc triển khai theo hướng Push-based là không thể tránh khỏi khi chạy cơ sở hạ tầng đám mây cung cấp tự động. Trong những trường hợp như vậy, chúng tôi khuyên bạn nên sử dụng hệ thống ủy quyền có thể cấu hình chi tiết của nhà cung cấp dịch vụ đám mây để có các quyền triển khai hạn chế hơn.
Một điều quan trọng khác cần lưu ý khi sử dụng cách tiếp cận này là deployment pipeline chỉ được kích hoạt khi environment repository thay đổi. Nó không thể tự động nhận thấy bất kỳ sai lệch nào của môi trường và trạng thái mong muốn của nó. Điều này có nghĩa là cần một số cơ chế giám sát, để có thể can thiệp nếu môi trường không khớp với những gì được mô tả trong environment repository.
Bạn muốn xem cách thiết lập nó? Xem Hướng dẫn của Google về cách thiết lập Push-based deployments với Cloud Builds và GKE.
PULL-BASED DEPLOYMENTS
Chiến lược Pull-based deployment sử dụng các khái niệm tương tự như push-based deployment nhưng khác về cách hoạt động của deployment pipeline. Các CI / CD pipeline truyền thống được kích hoạt bởi một sự kiện bên ngoài, ví dụ: khi mã nguồn mới được push lên repository. Với cách tiếp cận Pull-based deployment, có một thành phần mới gọi là operator. Operator đảm nhận vai trò của pipeline bằng cách liên tục so sánh trạng thái mong muốn trong environment repository với trạng thái thực tế trong cơ sở hạ tầng đang được triển khai. Bất cứ khi nào nhận thấy sự khác biệt, operator sẽ update lại cơ sở hạ tầng cho phù hợp với environment repository. Ngoài ra, image registry có thể được monitor để tìm các phiên bản mới của images để triển khai.
Cũng giống như push-based deployment, phương pháp này cập nhật môi trường bất cứ khi nào environment repository thay đổi. Tuy nhiên, với operator, những thay đổi cũng có thể được nhận biết theo hướng khác. Bất cứ khi nào cơ sở hạ tầng đã triển khai thay đổi theo bất kỳ cách nào không được mô tả trong environment repository, những thay đổi này sẽ được hoàn tác. Điều này đảm bảo rằng tất cả các thay đổi được thực hiện có thể theo dõi trong Git log, bằng cách không thể nào thực hiện các thay đổi trực tiếp đối với cơ sở hạ tầng.
Sự thay đổi theo hướng này giải quyết các vấn đề của push-based deployment, trong đó môi trường chỉ được cập nhật khi environment repository được cập nhật. Tuy nhiên, điều này không có nghĩa là bạn hoàn toàn có thể làm được mà không cần bất kỳ sự giám sát nào. Hầu hết các operators đều hỗ trợ gửi mail hoặc Slack notifications nếu nó không thể đưa môi trường về trạng thái mong muốn vì bất kỳ lý do gì, ví dụ như nếu nó không thể pull container image. Ngoài ra, bạn có thể nên thiết lập giám sát cho các operator, vì nếu operator không hoạt động, sẽ không còn bất kỳ quy trình triển khai tự động nào xảy ra.
Operator phải luôn hoạt động trong cùng một môi trường hoặc cụm cluster với ứng dụng cần triển khai. Điều này ngăn cản chế độ God-mode được thấy với cách tiếp cận push-based, nơi thông tin xác thực để thực hiện triển khai được nắm giữ bởi CI / CD pipeline. Khi phiên bản triển khai thực sự tồn tại bên trong cùng một môi trường, các dịch vụ bên ngoài không cần biết thông tin đăng nhập. Cơ chế Ủy quyền của nền tảng triển khai đang được sử dụng có thể được sử dụng để hạn chế quyền thực hiện việc triển khai. Điều này có ảnh hưởng rất lớn về mặt bảo mật. Khi sử dụng Kubernetes, bạn có thể sử dụng RBAC và service accounts.
Bạn muốn xem cách thiết lập nó? Xem Hướng dẫn về cách thiết lập GitOps với Pull-based Deployments trên GKE của Google bằng WeaveWorks Flux .
LÀM VIỆC VỚI NHIỀU ỨNG DỤNG VÀ MÔI TRƯỜNG
Tất nhiên làm việc với chỉ một application repository và một environment repository là không thực tế cho hầu hết các ứng dụng. Khi sử dụng kiến trúc microservices, bạn có thể muốn giữ các service trong các repository khác nhau.
GitOps cũng có thể xử lý cho các trường hợp như vậy. Luôn có thể thiết lập nhiều build pipeline để cập nhật environment repository.
Quản lý nhiều môi trường với GitOps có thể được thực hiện bằng cách chỉ sử dụng các nhánh riêng biệt trong environment repository. Bạn có thể thiết lập các operator hoặc các deployment pipeline để phản ứng với những thay đổi trên một nhánh bằng cách triển khai tới môi trường production và một nhánh khác để triển khai lên staging.
CÂU HỎI THƯỜNG GẶP
Dự án của tôi đã sẵn sàng cho GitOps chưa?
Rất có thể: Có! Điều thú vị về GitOps là bạn không cần phải viết bất kỳ đoạn code nào khác. Tất cả những gì bạn cần để bắt đầu là cơ sở hạ tầng có thể được quản lý với các công cụ Infrastructure as Code.
Tôi không sử dụng Kubernetes. Tôi vẫn có thể sử dụng GitOps?
Đúng! GitOps không giới hạn ở Kubernetes. Về nguyên tắc, bạn có thể sử dụng bất kỳ cơ sở hạ tầng nào có thể được quan sát và mô tả một cách khai báo bằng code, và có sẵn các công cụ Infrastructure as Code. Tuy nhiên, hiện tại hầu hết các operator cho GitOps cho pull-based deployment đều được triển khai với Kubernetes.
GitOps có phải là versioned Infrastructure as Code?
GitOps có phải chỉ là một tên mới của Infrastructure as Code?
Không. Cơ sở hạ tầng khai báo dưới dạng mã (Declarative Infrastructure as Code) đóng một vai trò rất lớn trong việc triển khai GitOps, nhưng không chỉ có vậy. GitOps đưa toàn bộ hệ sinh thái và công cụ xung quanh Git và áp dụng nó vào cơ sở hạ tầng. Hệ thống triển khai liên tục đảm bảo rằng trạng thái mong muốn hiện tại của cơ sở hạ tầng được triển khai trong production environment. Ngoài ra, bạn còn nhận được tất cả các lợi ích của code reviews, pull requests, và comments trên những thay đổi về cơ sở hạ tầng.
Làm thế nào để đưa secrets vào môi trường mà không cần lưu trữ chúng trong git?
Trước hết, đừng bao giờ lưu trữ secrets dưới dạng văn bản thuần túy trong git! Đừng bao giờ!
Nói như vậy, bạn có những secrets được tạo ra trong môi trường mà không bao giờ rời khỏi môi trường. Secrets vẫn chưa được biết đến và các ứng dụng nhận được những secrets mà chúng yêu cầu nhưng chúng không bị lộ ra thế giới bên ngoài. Ví dụ: bạn cung cấp một cơ sở dữ liệu bên trong một môi trường và chỉ cung cấp secrets cho các ứng dụng tương tác với cơ sở dữ liệu đó.
Một cách tiếp cận khác là dùng private key dùng một lần vào trong môi trường (có thể bởi ai đó từ ops team) và từ đó bạn có thể thêm các secrets được mã hóa bằng public key vào environment repository. Thậm chí còn có công cụ hỗ trợ cho các sealed secrets như trong hệ sinh thái của K8s.
GitOps xử lý từ DEV sang PROD như thế nào?
GitOps không cung cấp giải pháp để đưa các thay đổi từ giai đoạn này sang giai đoạn tiếp theo. Chúng tôi khuyên bạn chỉ nên sử dụng một môi trường duy nhất và tránh hoàn toàn việc triển khai từ giai đoạn này sang giai đoạn kia. Nhưng nếu cần nhiều giai đoạn (ví dụ: DEV, QA, PROD, v.v.) với một môi trường cho mỗi giai đoạn, bạn cần phải xử lý việc lan truyền bên ngoài phạm vi GitOps, chẳng hạn bằng các CI / CD pipeline.
Chúng tôi đang thực hiện DevOps. Sự khác biệt đối với GitOps là gì?
DevOps là tất cả về sự thay đổi văn hóa trong một tổ chức để làm cho mọi người làm việc tốt hơn với nhau. GitOps là một kỹ thuật để triển khai Continuous Delivery. Mặc dù DevOps và GitOps chia sẻ các nguyên tắc như tự động hóa và cơ sở hạ tầng tự phục vụ, nhưng sẽ không thực sự hợp lý khi so sánh chúng. Tuy nhiên, những nguyên tắc được chia sẻ này chắc chắn giúp bạn áp dụng quy trình làm việc GitOps dễ dàng hơn khi bạn đã tích cực sử dụng các kỹ thuật DevOps.
Vì vậy, về cơ bản GitOps có phải là NoOps không?
Có thể sử dụng GitOps để triển khai NoOps, nhưng nó không tự động làm cho tất cả các tác vụ hoạt động trở nên không cần thiết. Nếu bạn vẫn đang sử dụng tài nguyên đám mây, GitOps có thể được sử dụng để tự động hóa chúng. Tuy nhiên, thông thường, một số phần của cơ sở hạ tầng như cấu hình mạng hoặc Kubernetes cluster mà bạn sử dụng không do chính bạn quản lý một cách đàng hoàng mà được quản lý tập trung bởi một số nhóm vận hành. Vì vậy, các hoạt động không bao giờ thực sự biến mất.
Có SVNOps không?
Theo một cách nào đó, có. Về nguyên tắc, bạn có thể sử dụng bất kỳ hệ thống kiểm soát phiên bản nào bạn muốn. Một trong những ý tưởng cốt lõi của GitOps là cho phép các nhà phát triển sử dụng các công cụ mà họ quen thuộc để vận hành cơ sở hạ tầng của bạn. Nếu bạn thích SVN hơn Git, điều đó thật tuyệt! Tuy nhiên, bạn có thể cần phải nỗ lực nhiều hơn để tìm kiếm các công cụ phù hợp với mình hoặc thậm chí viết riêng cho bạn. Tất cả các operator có sẵn chỉ hoạt động với Git – xin lỗi!
Tôi có nên thuê kỹ sư GitOps cho nhóm của mình bây giờ không?
Không! Không có kỹ sư GitOps. GitOps không phải là một vai trò (và DevOps cũng vậy). GitOps là một tập hợp các thực hành. Bạn có thể tìm kiếm một developer có kinh nghiệm thực hành GitOps – hoặc đơn giản là để các developer của bạn thử các phương pháp đó.
TOOLS, ARTICLES, AND TALKS
TOOLS
- ArgoCD: A GitOps operator for Kubernetes with a web interface
- Flux: The GitOps Kubernetes operator by the creators of GitOps — Weaveworks
- Gitkube: A tool for building and deploying docker images on Kubernetes using
git push - JenkinsX: Continuous Delivery on Kubernetes with built-in GitOps
- Terragrunt: A wrapper for Terraform for keeping configurations DRY, and managing remote state
- WKSctl: A tool for Kubernetes cluster configuration management based on GitOps principles
- Helm Operator: An operator for using GitOps on K8s with Helm
- werf: A CLI tool to build images and deploy them to Kubernetes via push-based approach
Also check out Weavework’s Awesome-GitOps.
BLOG POSTS AND SOCIAL MEDIA
- An Inside Look at GitOps
- GitOps – Operations by Pull Request
- GitOps: What, Why, and How.
- What Is GitOps and Why It Might Be The Next Big Thing for DevOps
- What is GitOps Really?
- GitOps mit Helm und Kubernetes (German)
TALKS
- GitOps – Operations by Pull Request [B] – Alexis Richardson, Weaveworks & William Denniss, Google
- Tutorial: Hands-on Gitops – Brice Fernandes, Weaveworks
- What is GitOps? Next level delivery with Flux & Kubernetes by Rafał Lewandowski
Nhận xét
Đăng nhận xét