🥇Giới thiệu về GitOps cho OpenShift

Hôm nay chúng ta sẽ nói về các nguyên tắc và mô hình của GitOps, cũng như cách triển khai các mô hình này trên nền tảng OpenShift. Hướng dẫn tương tác về chủ đề này có sẵn по ссылке.

Tóm lại, GitOps là một tập hợp các phương pháp sử dụng yêu cầu kéo Git để quản lý cấu hình ứng dụng và cơ sở hạ tầng. Kho lưu trữ Git trong GitOps được coi là một nguồn thông tin duy nhất về trạng thái của hệ thống và mọi thay đổi đối với trạng thái này đều có thể theo dõi và kiểm tra đầy đủ.

Ý tưởng theo dõi thay đổi trong GitOps không hề mới; cách tiếp cận này từ lâu đã được sử dụng gần như phổ biến khi làm việc với mã nguồn ứng dụng. GitOps chỉ triển khai các tính năng tương tự (đánh giá, yêu cầu kéo, thẻ, v.v.) trong quản lý cấu hình ứng dụng và cơ sở hạ tầng, đồng thời cung cấp các lợi ích tương tự như trong trường hợp quản lý mã nguồn.

Không có định nghĩa học thuật hoặc bộ quy tắc nào được phê duyệt cho GitOps, chỉ có một bộ nguyên tắc làm cơ sở cho phương pháp này được xây dựng:

Mô tả khai báo của hệ thống được lưu trữ trong kho Git (cấu hình, giám sát, v.v.).
Thay đổi trạng thái được thực hiện thông qua các yêu cầu kéo.
Trạng thái của các hệ thống đang chạy được điều chỉnh phù hợp với dữ liệu trong kho lưu trữ bằng cách sử dụng yêu cầu đẩy Git.

Nguyên tắc GitOps

Định nghĩa hệ thống được mô tả dưới dạng mã nguồn

Cấu hình hệ thống được coi là mã nên có thể được lưu trữ và tạo phiên bản tự động trong kho lưu trữ Git, đóng vai trò như một nguồn thông tin đáng tin cậy duy nhất. Cách tiếp cận này giúp dễ dàng triển khai và khôi phục các thay đổi trong hệ thống.

Trạng thái và cấu hình mong muốn của hệ thống được đặt và phiên bản trong Git

Bằng cách lưu trữ và lập phiên bản trạng thái mong muốn của hệ thống trong Git, chúng tôi có thể dễ dàng triển khai và khôi phục các thay đổi đối với hệ thống và ứng dụng. Chúng tôi cũng có thể sử dụng cơ chế bảo mật của Git để kiểm soát quyền sở hữu mã và xác minh tính xác thực của mã.

Thay đổi cấu hình có thể được áp dụng tự động thông qua các yêu cầu kéo

Sử dụng yêu cầu kéo Git, chúng ta có thể dễ dàng kiểm soát cách áp dụng các thay đổi cho cấu hình trong kho lưu trữ. Ví dụ: chúng có thể được giao cho các thành viên khác trong nhóm để xem xét hoặc chạy qua các bài kiểm tra CI, v.v.

Và đồng thời, không cần phân chia quyền quản trị trái và phải. Để thực hiện thay đổi cấu hình, người dùng chỉ cần có quyền thích hợp trong kho Git nơi lưu trữ các cấu hình đó.

Sửa lỗi trôi cấu hình không kiểm soát được

Khi trạng thái mong muốn của hệ thống được lưu trữ trong kho Git, tất cả những gì chúng ta phải làm là tìm phần mềm đảm bảo rằng trạng thái hiện tại của hệ thống khớp với trạng thái mong muốn. Nếu không phải như vậy thì phần mềm này sẽ - tùy thuộc vào cài đặt - tự loại bỏ sự khác biệt hoặc thông báo cho chúng tôi về lỗi lệch cấu hình.

Mô hình GitOps cho OpenShift

Bộ điều hòa tài nguyên trên cụm

Theo mô hình này, cụm có bộ điều khiển chịu trách nhiệm so sánh tài nguyên Kubernetes (tệp YAML) trong kho Git với tài nguyên thực của cụm. Nếu phát hiện thấy sự khác biệt, bộ điều khiển sẽ gửi thông báo và có thể thực hiện hành động để khắc phục sự khác biệt. Mô hình GitOps này được sử dụng trong Quản lý cấu hình Anthos và Weaworks Flux.

Bộ điều hòa tài nguyên bên ngoài (Đẩy)

Mô hình này có thể được coi là một biến thể của mô hình trước, khi chúng ta có một hoặc nhiều bộ điều khiển chịu trách nhiệm đồng bộ hóa tài nguyên trong cặp “Git repo - Kubernetes cluster”. Sự khác biệt ở đây là mỗi cụm được quản lý không nhất thiết phải có bộ điều khiển riêng. Các cặp cụm Git - k8s thường được định nghĩa là CRD (định nghĩa tài nguyên tùy chỉnh), có thể mô tả cách bộ điều khiển thực hiện đồng bộ hóa. Trong mô hình này, bộ điều khiển so sánh kho lưu trữ Git được chỉ định trong CRD với tài nguyên cụm Kubernetes cũng được chỉ định trong CRD và thực hiện các hành động thích hợp dựa trên kết quả so sánh. Đặc biệt, mô hình GitOps này được sử dụng trong ArgoCD.

GitOps trên nền tảng OpenShift

Quản trị cơ sở hạ tầng Kubernetes đa cụm

Với sự lan rộng của Kubernetes và sự phổ biến ngày càng tăng của các chiến lược đa đám mây và điện toán biên, số lượng cụm OpenShift trung bình trên mỗi khách hàng cũng ngày càng tăng.

Ví dụ: khi sử dụng điện toán ranh giới, các cụm của một khách hàng có thể được triển khai với số lượng hàng trăm hoặc thậm chí hàng nghìn. Kết quả là anh ta buộc phải quản lý một số cụm OpenShift độc lập hoặc phối hợp trên đám mây công cộng và tại chỗ.

Trong trường hợp này, rất nhiều vấn đề phải được giải quyết, cụ thể:

Kiểm soát để đảm bảo các cụm ở trạng thái giống hệt nhau (cấu hình, giám sát, lưu trữ, v.v.)
Tạo lại (hoặc khôi phục) các cụm dựa trên trạng thái đã biết.
Tạo các cụm mới dựa trên trạng thái đã biết.
Triển khai các thay đổi cho nhiều cụm OpenShift.
Khôi phục các thay đổi trên nhiều cụm OpenShift.
Liên kết các cấu hình theo khuôn mẫu với các môi trường khác nhau.

Cấu hình ứng dụng

Trong vòng đời của chúng, các ứng dụng thường đi qua một chuỗi các cụm (nhà phát triển, giai đoạn, v.v.) trước khi kết thúc ở cụm sản xuất. Ngoài ra, do yêu cầu về tính khả dụng và khả năng mở rộng, khách hàng thường triển khai ứng dụng trên nhiều cụm tại chỗ hoặc nhiều vùng của nền tảng đám mây công cộng.

Trong trường hợp này, các nhiệm vụ sau phải được giải quyết:

Đảm bảo sự chuyển động của các ứng dụng (nhị phân, cấu hình, v.v.) giữa các cụm (dev, stage, v.v.).
Triển khai các thay đổi đối với ứng dụng (tệp nhị phân, cấu hình, v.v.) trong một số cụm OpenShift.
Khôi phục các thay đổi đối với ứng dụng về trạng thái đã biết trước đó.

Các trường hợp sử dụng OpenShift GitOps

1. Áp dụng các thay đổi từ kho Git

Quản trị viên cụm có thể lưu trữ cấu hình cụm OpenShift trong kho Git và tự động áp dụng chúng để dễ dàng tạo các cụm mới và đưa chúng về trạng thái giống hệt với trạng thái đã biết được lưu trữ trong kho Git.

2. Đồng bộ hóa với Trình quản lý bí mật

Quản trị viên cũng sẽ được hưởng lợi từ khả năng đồng bộ hóa các đối tượng bí mật OpenShift với phần mềm thích hợp như Vault để quản lý chúng bằng các công cụ được tạo đặc biệt cho việc này.

3. Kiểm soát cấu hình trôi

Quản trị viên sẽ chỉ được ưu ái nếu OpenShift GitOps tự xác định và cảnh báo về sự khác biệt giữa cấu hình thực và cấu hình được chỉ định trong kho lưu trữ, để chúng có thể nhanh chóng phản ứng với tình trạng trôi dạt.

4. Thông báo về sai lệch cấu hình

Chúng rất hữu ích trong trường hợp quản trị viên muốn tìm hiểu nhanh về các trường hợp sai lệch cấu hình để nhanh chóng tự mình đưa ra các biện pháp thích hợp.

5. Đồng bộ cấu hình thủ công khi drift

Cho phép quản trị viên đồng bộ hóa cụm OpenShift với kho lưu trữ Git trong trường hợp sai lệch cấu hình, để nhanh chóng đưa cụm về trạng thái đã biết trước đó.

6.Tự động đồng bộ cấu hình khi drift

Quản trị viên cũng có thể định cấu hình cụm OpenShift để tự động đồng bộ hóa với kho lưu trữ khi phát hiện thấy sai lệch, để cấu hình cụm luôn khớp với các cấu hình trong Git.

7. Một số cụm - một kho lưu trữ

Quản trị viên có thể lưu trữ cấu hình của một số cụm OpenShift khác nhau trong một kho lưu trữ Git và áp dụng chúng một cách có chọn lọc nếu cần.

8. Phân cấp cấu hình cụm (kế thừa)

Quản trị viên có thể thiết lập hệ thống phân cấp cấu hình cụm trong kho lưu trữ (giai đoạn, sản phẩm, danh mục ứng dụng, v.v. có tính kế thừa). Nói cách khác, nó có thể xác định xem có nên áp dụng cấu hình cho một hoặc nhiều cụm hay không.

Ví dụ: nếu quản trị viên đặt cấu trúc phân cấp “Cụm sản xuất (prod) → Cụm hệ thống X → Cụm sản xuất của hệ thống X” trong kho Git, thì sự kết hợp của các cấu hình sau sẽ được áp dụng cho cụm sản xuất của hệ thống X:

Cấu hình chung cho tất cả các cụm sản xuất.
Cấu hình cho cụm System X.
Cấu hình cho cụm sản xuất hệ thống X.

9. Mẫu và ghi đè cấu hình

Quản trị viên có thể ghi đè một tập hợp các cấu hình kế thừa và các giá trị của chúng, chẳng hạn như để tinh chỉnh cấu hình cho các cụm cụ thể mà chúng sẽ được áp dụng.

10. Bao gồm và loại trừ có chọn lọc đối với cấu hình, cấu hình ứng dụng

Quản trị viên có thể đặt điều kiện cho việc áp dụng hoặc không áp dụng các cấu hình nhất định cho các cụm có các đặc điểm nhất định.

11. Hỗ trợ mẫu

Các nhà phát triển sẽ được hưởng lợi từ khả năng chọn cách xác định tài nguyên ứng dụng (Biểu đồ Helm, Kubernetes yaml thuần túy, v.v.) để sử dụng định dạng phù hợp nhất cho từng ứng dụng cụ thể.

Các công cụ GitOps trên nền tảng OpenShift

ArgoCD

ArgoCD triển khai mô hình Điều chỉnh tài nguyên bên ngoài và cung cấp giao diện người dùng tập trung để điều phối mối quan hệ một-nhiều giữa các cụm và kho lưu trữ Git. Nhược điểm của chương trình này bao gồm không có khả năng quản lý ứng dụng khi ArgoCD không hoạt động.

Trang web chính thức

Phun ra

Flux triển khai mô hình Điều chỉnh tài nguyên trên cụm và do đó, không có sự quản lý tập trung đối với kho định nghĩa, đây là một điểm yếu. Mặt khác, chính xác là do thiếu sự tập trung nên khả năng quản lý ứng dụng vẫn được duy trì ngay cả khi một cụm bị lỗi.

Trang web chính thức

Cài đặt ArgoCD trên OpenShift

ArgoCD cung cấp giao diện dòng lệnh và bảng điều khiển web tuyệt vời, vì vậy chúng tôi sẽ không đề cập đến Flux và các lựa chọn thay thế khác ở đây.

Để triển khai ArgoCD trên nền tảng OpenShift 4, hãy làm theo các bước sau với tư cách quản trị viên cụm:

Triển khai các thành phần ArgoCD trên nền tảng OpenShift

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

Cải thiện Máy chủ ArgoCD để OpenShift Route có thể nhìn thấy nó

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

Triển khai công cụ ArgoCD Cli

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

Thay đổi mật khẩu quản trị viên ArgoCD Server

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

Sau khi hoàn thành các bước này, bạn có thể làm việc với ArgoCD Server thông qua bảng điều khiển web ArgoCD WebUI hoặc công cụ dòng lệnh ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Không bao giờ là quá muộn

“Tàu đã rời bến” - đây là những gì người ta nói về tình huống bỏ lỡ cơ hội để làm điều gì đó. Trong trường hợp của OpenShift, mong muốn bắt đầu sử dụng ngay nền tảng mới thú vị này thường tạo ra chính xác tình huống này với việc quản lý và bảo trì các tuyến, triển khai và các đối tượng OpenShift khác. Nhưng có phải cơ hội luôn bị mất hoàn toàn?

Tiếp tục series bài viết về GitOps, hôm nay chúng tôi sẽ hướng dẫn bạn cách chuyển đổi một ứng dụng thủ công và các tài nguyên của nó thành một quy trình trong đó mọi thứ đều được quản lý bằng các công cụ GitOps. Để thực hiện việc này, trước tiên chúng ta sẽ triển khai ứng dụng httpd theo cách thủ công. Ảnh chụp màn hình bên dưới cho thấy cách chúng tôi tạo không gian tên, triển khai và dịch vụ, sau đó hiển thị dịch vụ này để tạo tuyến đường.

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

Vậy là chúng ta đã có một ứng dụng thủ công. Bây giờ nó cần được chuyển dưới sự quản lý GitOps mà không bị mất tính khả dụng. Nói tóm lại, nó thực hiện điều này:

Tạo kho lưu trữ Git cho mã.
Chúng tôi xuất các đối tượng hiện tại của mình và tải chúng lên kho Git.
Lựa chọn và triển khai các công cụ GitOps.
Chúng tôi thêm kho lưu trữ của mình vào bộ công cụ này.
Chúng tôi xác định ứng dụng trong bộ công cụ GitOps của mình.
Chúng tôi thực hiện chạy thử ứng dụng bằng bộ công cụ GitOps.
Chúng tôi đồng bộ hóa các đối tượng bằng bộ công cụ GitOps.
Cho phép cắt tỉa và tự động đồng bộ hóa các đối tượng.

Như đã đề cập ở phần trước Bài viết, trong GitOps có một và chỉ một nguồn thông tin về tất cả các đối tượng trong (các) cụm Kubernetes - kho lưu trữ Git. Tiếp theo, chúng tôi tiến hành dựa trên tiền đề rằng tổ chức của bạn đã sử dụng kho lưu trữ Git. Nó có thể ở chế độ công khai hoặc riêng tư, nhưng nó phải có thể truy cập được đối với các cụm Kubernetes. Đây có thể là kho lưu trữ giống như mã ứng dụng hoặc một kho lưu trữ riêng biệt được tạo riêng cho việc triển khai. Bạn nên có các quyền nghiêm ngặt trong kho lưu trữ vì các bí mật, tuyến đường và những thứ nhạy cảm về bảo mật khác sẽ được lưu trữ ở đó.

Trong ví dụ của chúng tôi, chúng tôi sẽ tạo một kho lưu trữ công khai mới trên GitHub. Bạn có thể gọi nó là gì tùy thích, chúng tôi sử dụng tên blogpost.

Nếu các tệp đối tượng YAML không được lưu trữ cục bộ hoặc trong Git thì bạn sẽ phải sử dụng tệp nhị phân oc hoặc kubectl. Trong ảnh chụp màn hình bên dưới, chúng tôi đang yêu cầu YAML cho vùng tên, triển khai, dịch vụ và tuyến đường của chúng tôi. Trước đó, chúng tôi đã sao chép kho lưu trữ mới tạo và cd vào đó.

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

Bây giờ hãy chỉnh sửa tệp triển khai.yaml để xóa trường mà CD Argo không thể đồng bộ hóa.

sed -i '/sgeneration: .*/d' deployment.yaml

Ngoài ra, tuyến đường cần phải được thay đổi. Trước tiên, chúng ta sẽ đặt một biến nhiều dòng và sau đó thay thế ingress: null bằng nội dung của biến đó.

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

Vì vậy, chúng tôi đã sắp xếp các tệp, tất cả những gì còn lại là lưu chúng vào kho Git. Sau đó, kho lưu trữ này trở thành nguồn thông tin duy nhất và mọi thay đổi thủ công đối với các đối tượng đều bị nghiêm cấm.

git commit -am ‘initial commit of objects’
git push origin master

Hơn nữa, chúng tôi tiến hành từ thực tế là bạn đã triển khai ArgoCD (cách thực hiện việc này - xem phần trước gửi). Do đó, chúng tôi sẽ thêm vào CD Argo kho lưu trữ mà chúng tôi đã tạo, chứa mã ứng dụng từ ví dụ của chúng tôi. Chỉ cần đảm bảo rằng bạn chỉ định chính xác kho lưu trữ mà bạn đã tạo trước đó.

argocd repo add https://github.com/cooktheryan/blogpost

Bây giờ hãy tạo ứng dụng. Ứng dụng đặt các giá trị để bộ công cụ GitOps hiểu kho lưu trữ và đường dẫn nào sẽ sử dụng, OpenShift nào cần thiết để quản lý các đối tượng, nhánh cụ thể nào của kho lưu trữ là cần thiết và liệu tài nguyên có nên tự động đồng bộ hóa hay không.

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

Sau khi ứng dụng được chỉ định trong CD Argo, bộ công cụ sẽ bắt đầu kiểm tra các đối tượng đã được triển khai dựa trên các định nghĩa trong kho lưu trữ. Trong ví dụ của chúng tôi, tính năng tự động đồng bộ hóa và dọn dẹp bị tắt nên các thành phần vẫn chưa thay đổi. Xin lưu ý rằng trong giao diện Argo CD, ứng dụng của chúng tôi sẽ có trạng thái “Không đồng bộ hóa” vì không có nhãn nào mà ArgoCD cung cấp.
Đây là lý do tại sao khi chúng tôi bắt đầu đồng bộ hóa muộn hơn một chút, các đối tượng sẽ không được triển khai lại.

Bây giờ hãy chạy thử để đảm bảo không có lỗi trong tệp của chúng tôi.

argocd app sync simple-app --dry-run

Nếu không có lỗi thì bạn có thể tiến hành đồng bộ hóa.

argocd app sync simple-app

Sau khi chạy lệnh argocd get trên ứng dụng của chúng ta, chúng ta sẽ thấy trạng thái ứng dụng đã thay đổi thành Khỏe mạnh hoặc Đã đồng bộ hóa. Điều này có nghĩa là tất cả tài nguyên trong kho Git hiện tương ứng với những tài nguyên đã được triển khai.

argocd app get simple-app
Name:               simple-app
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...

Giờ đây, bạn có thể bật tính năng tự động đồng bộ hóa và dọn dẹp để đảm bảo rằng không có nội dung nào được tạo theo cách thủ công và mỗi khi một đối tượng được tạo hoặc cập nhật vào kho lưu trữ thì quá trình triển khai sẽ diễn ra.

argocd app set simple-app --sync-policy automated --auto-prune

Vì vậy, chúng tôi đã đưa thành công một ứng dụng dưới sự kiểm soát của GitOps mà ban đầu không sử dụng GitOps dưới bất kỳ hình thức nào.

Nguồn: www.habr.com

Giới thiệu về GitOps cho OpenShift