OpenShift용 GitOps 소개

오늘은 GitOps의 원칙과 모델, 그리고 이러한 모델이 OpenShift 플랫폼에서 구현되는 방법에 대해 이야기하겠습니다. 이 주제에 대한 대화형 가이드를 사용할 수 있습니다. 링크.

간단히 말해서 GitOps는 Git 풀 요청을 사용하여 인프라 및 애플리케이션 구성을 관리하기 위한 일련의 사례입니다. GitOps의 Git 저장소는 시스템 상태에 대한 단일 정보 소스로 처리되며 이 상태에 대한 모든 변경 사항은 완전히 추적 및 감사 가능합니다.

GitOps의 변경 사항 추적 아이디어는 결코 새로운 것이 아니며, 이 접근 방식은 오랫동안 애플리케이션 소스 코드 작업 시 거의 보편적으로 사용되어 왔습니다. GitOps는 인프라 및 애플리케이션 구성 관리에서 유사한 기능(검토, 풀 요청, 태그 등)을 단순히 구현하고 소스 코드 관리의 경우와 유사한 이점을 제공합니다.

GitOps에 대한 학문적 정의나 승인된 규칙 세트는 없으며, 이 관행이 구축된 원칙 세트만 있습니다.

• 시스템에 대한 선언적 설명은 Git 저장소(구성, 모니터링 등)에 저장됩니다.
• 상태 변경은 풀 요청을 통해 이루어집니다.
• 실행 중인 시스템의 상태는 Git 푸시 요청을 사용하여 저장소의 데이터와 일치하게 됩니다.

GitOps 원칙

• 시스템 정의는 소스 코드로 설명됩니다.

시스템 구성은 코드로 처리되므로 단일 정보 소스 역할을 하는 Git 저장소에 저장되고 자동으로 버전이 지정될 수 있습니다. 이 접근 방식을 사용하면 시스템의 변경 사항을 쉽게 롤아웃하고 롤백할 수 있습니다.

• 원하는 시스템 상태와 구성이 Git에서 설정되고 버전이 지정됩니다.

Git에 원하는 시스템 상태를 저장하고 버전 관리함으로써 시스템과 애플리케이션에 대한 변경 사항을 쉽게 롤아웃하고 롤백할 수 있습니다. 또한 Git의 보안 메커니즘을 사용하여 코드 소유권을 제어하고 코드의 진위 여부를 확인할 수도 있습니다.

• 풀 요청을 통해 구성 변경 사항을 자동으로 적용할 수 있습니다.

Git 풀 요청을 사용하면 저장소의 구성에 변경 사항이 적용되는 방식을 쉽게 제어할 수 있습니다. 예를 들어 검토를 위해 다른 팀 구성원에게 제공하거나 CI 테스트 등을 실행할 수 있습니다.

동시에 관리 권한을 좌우로 분배할 필요도 없습니다. 구성 변경 사항을 커밋하려면 해당 구성이 저장된 Git 저장소에 대한 적절한 권한만 사용자에게 필요합니다.

• 제어되지 않는 구성 드리프트 문제 해결

원하는 시스템 상태가 Git 저장소에 저장되면 우리가 해야 할 일은 시스템의 현재 상태가 원하는 상태와 일치하도록 보장하는 소프트웨어를 찾는 것뿐입니다. 그렇지 않은 경우 이 소프트웨어는 설정에 따라 자체적으로 불일치를 제거하거나 구성 드리프트에 대해 알려야 합니다.

OpenShift용 GitOps 모델

클러스터 내 리소스 조정자

이 모델에 따르면 클러스터에는 Git 리포지토리의 Kubernetes 리소스(YAML 파일)를 클러스터의 실제 리소스와 비교하는 일을 담당하는 컨트롤러가 있습니다. 불일치가 감지되면 컨트롤러는 알림을 보내고 불일치를 수정하기 위한 조치를 취할 수도 있습니다. 이 GitOps 모델은 Anthos Config Management 및 Weaveworks Flux에서 사용됩니다.

외부 자원 조정자(푸시)

이 모델은 "Git 저장소 - Kubernetes 클러스터" 쌍에서 리소스 동기화를 담당하는 하나 이상의 컨트롤러가 있는 경우 이전 모델의 변형으로 간주될 수 있습니다. 여기서 차이점은 관리되는 각 클러스터가 반드시 자체 별도의 컨트롤러를 가질 필요는 없다는 것입니다. Git - k8s 클러스터 쌍은 컨트롤러가 동기화를 수행하는 방법을 설명할 수 있는 CRD(사용자 정의 리소스 정의)로 정의되는 경우가 많습니다. 이 모델 내에서 컨트롤러는 CRD에 지정된 Git 저장소를 CRD에도 지정된 Kubernetes 클러스터 리소스와 비교하고 비교 결과에 따라 적절한 작업을 수행합니다. 특히 이 GitOps 모델은 ArgoCD에서 사용됩니다.

OpenShift 플랫폼의 GitOps

멀티 클러스터 Kubernetes 인프라 관리

Kubernetes의 확산과 멀티 클라우드 전략 및 엣지 컴퓨팅의 인기가 높아짐에 따라 고객당 평균 OpenShift 클러스터 수도 증가하고 있습니다.

예를 들어 엣지 컴퓨팅을 사용하면 한 고객의 클러스터가 수백 또는 수천 개로 배포될 수 있습니다. 결과적으로 그는 퍼블릭 클라우드와 온프레미스에서 여러 개의 독립적이거나 조정된 OpenShift 클러스터를 관리해야 합니다.

이 경우 특히 다음과 같은 많은 문제를 해결해야 합니다.

• 클러스터가 동일한 상태(구성, 모니터링, 스토리지 등)에 있는지 제어합니다.
• 알려진 상태를 기반으로 클러스터를 다시 생성(또는 복원)합니다.
• 알려진 상태를 기반으로 새 클러스터를 만듭니다.
• 여러 OpenShift 클러스터에 변경 사항을 롤아웃합니다.
• 여러 OpenShift 클러스터에서 변경 사항을 롤백합니다.
• 템플릿 구성을 다양한 환경에 연결합니다.

애플리케이션 구성

수명 주기 동안 애플리케이션은 프로덕션 클러스터에 도달하기 전에 클러스터 체인(개발, 단계 등)을 통과하는 경우가 많습니다. 또한 가용성 및 확장성 요구 사항으로 인해 고객은 여러 온프레미스 클러스터 또는 퍼블릭 클라우드 플랫폼의 여러 지역에 애플리케이션을 배포하는 경우가 많습니다.

이 경우 다음 작업을 해결해야 합니다.

• 클러스터(개발, 단계 등) 간 애플리케이션(바이너리, 구성 등)의 이동을 보장합니다.
• 여러 OpenShift 클러스터의 애플리케이션(바이너리, 구성 등)에 대한 변경 사항을 롤아웃합니다.
• 애플리케이션의 변경 사항을 이전에 알려진 상태로 롤백합니다.

OpenShift GitOps 사용 사례

1. Git 저장소의 변경 사항 적용

클러스터 관리자는 OpenShift 클러스터 구성을 Git 저장소에 저장하고 이를 자동으로 적용하여 손쉽게 새 클러스터를 생성하고 Git 저장소에 저장된 알려진 상태와 동일한 상태로 만들 수 있습니다.

2. Secret Manager와의 동기화

또한 관리자는 OpenShift 비밀 개체를 Vault와 같은 적절한 소프트웨어와 동기화하여 이를 위해 특별히 제작된 도구를 사용하여 관리할 수 있는 기능의 이점을 누릴 수 있습니다.

3. 드리프트 구성 제어

관리자는 OpenShift GitOps 자체가 실제 구성과 저장소에 지정된 구성 간의 불일치를 식별하고 경고하여 드리프트에 신속하게 대응할 수 있는 경우에만 선호합니다.

4. 구성 드리프트에 대한 알림

관리자가 스스로 적절한 조치를 신속하게 취하기 위해 구성 드리프트 사례를 신속하게 파악하려는 경우에 유용합니다.

5. 드리프트 시 구성 수동 동기화

구성 드리프트가 발생하는 경우 관리자가 OpenShift 클러스터를 Git 저장소와 동기화하여 클러스터를 알려진 이전 상태로 빠르게 되돌릴 수 있습니다.

6. 드리프트 시 구성 자동 동기화

또한 관리자는 드리프트가 감지되면 저장소와 자동으로 동기화되도록 OpenShift 클러스터를 구성하여 클러스터 구성이 항상 Git의 구성과 일치하도록 할 수도 있습니다.

7. 여러 클러스터 - 하나의 저장소

관리자는 여러 OpenShift 클러스터의 구성을 하나의 Git 저장소에 저장하고 필요에 따라 선택적으로 적용할 수 있습니다.

8. 클러스터 구성 계층 구조(상속)

관리자는 저장소(상속이 포함된 스테이지, 프로덕션, 앱 포트폴리오 등)에서 클러스터 구성의 계층 구조를 설정할 수 있습니다. 즉, 구성을 하나 이상의 클러스터에 적용해야 하는지 여부를 결정할 수 있습니다.

예를 들어, 관리자가 Git 리포지토리에서 "프로덕션 클러스터(프로덕션) → 시스템 X 클러스터 → 시스템 X의 프로덕션 클러스터" 계층 구조를 설정하면 다음 구성의 조합이 시스템 X의 프로덕션 클러스터에 적용됩니다.

• 모든 프로덕션 클러스터에 공통적인 구성입니다.
• System X 클러스터에 대한 구성입니다.
• X 시스템 프로덕션 클러스터에 대한 구성입니다.

9. 템플릿 및 구성 재정의

관리자는 상속된 구성 집합과 해당 값을 재정의하여 적용할 특정 클러스터에 대한 구성을 미세 조정할 수 있습니다.

10. 구성, 애플리케이션 구성에 대한 선택적 포함 및 제외

관리자는 특정 특성을 가진 클러스터에 대해 특정 구성을 적용하거나 적용하지 않는 조건을 설정할 수 있습니다.

11. 템플릿 지원

개발자는 각 특정 애플리케이션에 가장 적합한 형식을 사용하기 위해 애플리케이션 리소스를 정의하는 방법(Helm Chart, 순수 Kubernetes yaml 등)을 선택할 수 있는 기능의 이점을 누릴 수 있습니다.

OpenShift 플랫폼의 GitOps 도구

아르고CD

ArgoCD는 외부 리소스 조정 모델을 구현하고 클러스터와 Git 리포지토리 간의 일대다 관계를 조정하기 위한 중앙 집중식 UI를 제공합니다. 이 프로그램의 단점은 ArgoCD가 작동하지 않을 때 응용 프로그램을 관리할 수 없다는 것입니다.

공식 웹 사이트

유량

Flux는 On-Cluster Resource Reconcile 모델을 구현하므로 약점인 정의 저장소에 대한 중앙 집중식 관리가 없습니다. 반면, 중앙 집중화가 부족하기 때문에 클러스터 하나가 실패하더라도 애플리케이션을 관리하는 능력은 그대로 유지됩니다.

공식 웹 사이트

OpenShift에 ArgoCD 설치

ArgoCD는 뛰어난 명령줄 인터페이스와 웹 콘솔을 제공하므로 여기에서는 Flux 및 기타 대안을 다루지 않습니다.

OpenShift 4 플랫폼에 ArgoCD를 배포하려면 클러스터 관리자로서 다음 단계를 수행하십시오.

OpenShift 플랫폼에 ArgoCD 구성요소 배포

# 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}')

OpenShift Route에서 볼 수 있도록 ArgoCD 서버 개선

# 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

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

ArgoCD 서버 관리자 비밀번호 변경

# 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

이러한 단계를 완료한 후 ArgoCD WebUI 웹 콘솔 또는 ArgoCD Cli 명령줄 도구를 통해 ArgoCD 서버로 작업할 수 있습니다.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - 너무 늦지 않았습니다

“기차가 떠났다” – 이것은 무언가를 할 기회를 놓친 상황에 대해 말하는 것입니다. OpenShift의 경우 이 멋진 새 플랫폼을 즉시 사용하려는 욕구로 인해 경로, 배포 및 기타 OpenShift 개체의 관리 및 유지 관리와 함께 바로 이러한 상황이 발생하는 경우가 많습니다. 하지만 기회는 언제나 완전히 사라지는 걸까요?

에 관한 일련의 기사를 계속합니다. GitOps, 오늘은 직접 만든 애플리케이션과 해당 리소스를 모든 것이 GitOps 도구로 관리되는 프로세스로 변환하는 방법을 보여 드리겠습니다. 이를 위해 먼저 httpd 애플리케이션을 수동으로 배포합니다. 아래 스크린샷은 네임스페이스, 배포 및 서비스를 생성한 다음 이 서비스를 노출하여 경로를 생성하는 방법을 보여줍니다.

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

그래서 우리는 손으로 만든 응용 프로그램을 가지고 있습니다. 이제 가용성 손실 없이 GitOps 관리 하에 전송되어야 합니다. 간단히 말해서 다음과 같은 작업을 수행합니다.

• 코드에 대한 Git 저장소를 만듭니다.
• 현재 개체를 내보내고 Git 저장소에 업로드합니다.
• GitOps 도구 선택 및 배포.
• 이 툴킷에 저장소를 추가합니다.
• GitOps 툴킷에서 애플리케이션을 정의합니다.
• GitOps 툴킷을 사용하여 애플리케이션의 테스트 실행을 수행합니다.
• GitOps 툴킷을 사용하여 객체를 동기화합니다.
• 객체 정리 및 자동 동기화를 활성화합니다.

이전에 언급했듯이 기사, GitOps에는 Kubernetes 클러스터의 모든 객체에 대한 정보 소스가 Git 저장소뿐입니다. 다음으로, 귀하의 조직이 이미 Git 리포지토리를 사용하고 있다는 전제에서 진행합니다. 공개 또는 비공개일 수 있지만 Kubernetes 클러스터에서 액세스할 수 있어야 합니다. 이는 애플리케이션 코드와 동일한 리포지토리이거나 배포용으로 특별히 생성된 별도의 리포지토리일 수 있습니다. 저장소에는 비밀, 경로 및 기타 보안에 민감한 내용이 저장되므로 엄격한 권한을 갖는 것이 좋습니다.

이 예에서는 GitHub에 새로운 공개 저장소를 만듭니다. 원하는 대로 부르시면 됩니다. 우리는 blogpost라는 이름을 사용합니다.

YAML 객체 파일이 로컬로 또는 Git에 저장되지 않은 경우 oc 또는 kubectl 바이너리를 사용해야 합니다. 아래 스크린샷에서는 네임스페이스, 배포, 서비스 및 경로에 대해 YAML을 요청하고 있습니다. 그 전에 새로 생성된 저장소를 복제하고 여기에 CD를 넣었습니다.

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

이제 Argo CD가 동기화할 수 없는 필드를 제거하기 위해 development.yaml 파일을 편집해 보겠습니다.

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

또한 경로를 변경해야 합니다. 먼저 여러 줄의 변수를 설정한 다음 ingress: null을 해당 변수의 내용으로 바꿉니다.

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

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

이제 파일을 정리했으니 이제 Git 저장소에 저장하는 일만 남았습니다. 그 후에는 이 저장소가 유일한 정보 소스가 되며 개체에 대한 수동 변경은 엄격히 금지됩니다.

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

또한 ArgoCD를 이미 배포했다는 사실부터 진행합니다(이를 수행하는 방법 - 이전 참조). 게시). 따라서 우리는 예제의 애플리케이션 코드를 포함하여 우리가 생성한 저장소를 Argo CD에 추가할 것입니다. 이전에 생성한 정확한 저장소를 지정했는지 확인하세요.

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

이제 애플리케이션을 만들어 보겠습니다. GitOps 툴킷이 사용할 저장소와 경로, 객체 관리에 필요한 OpenShift, 저장소의 특정 분기가 필요한지, 리소스가 자동 동기화되어야 하는지 여부를 이해할 수 있도록 애플리케이션은 값을 설정합니다.

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

Argo CD에 애플리케이션이 지정되면 툴킷은 저장소의 정의와 비교하여 이미 배포된 개체를 확인하기 시작합니다. 이 예에서는 자동 동기화 및 정리가 비활성화되어 있으므로 요소가 아직 변경되지 않습니다. ArgoCD가 제공하는 레이블이 없기 때문에 Argo CD 인터페이스에는 애플리케이션이 "동기화되지 않음" 상태가 됩니다.
이것이 바로 우리가 조금 후에 동기화를 시작하면 객체가 재배포되지 않는 이유입니다.

이제 테스트를 실행하여 파일에 오류가 없는지 확인하겠습니다.

argocd app sync simple-app --dry-run

오류가 없으면 동기화를 진행할 수 있습니다.

argocd app sync simple-app

애플리케이션에서 argocd get 명령을 실행한 후 애플리케이션 상태가 Healthy 또는 Synced로 변경된 것을 확인해야 합니다. 이는 이제 Git 저장소의 모든 리소스가 이미 배포된 리소스에 해당함을 의미합니다.

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
...   

이제 자동 동기화 및 정리를 활성화하여 수동으로 아무것도 생성되지 않고 객체가 생성되거나 리포지토리에 업데이트될 때마다 배포가 발생하도록 할 수 있습니다.

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

따라서 우리는 처음에는 어떤 방식으로든 GitOps를 사용하지 않았던 애플리케이션을 GitOps 제어 하에 성공적으로 가져왔습니다.

출처 : habr.com