GitLab은 GitOps를 위해 Flux를 통합합니다. Flux를 시작하려면 GitOps를 위한 Flux 튜토리얼을 참고합니다.

GitOps를 사용하면 다음과 같은 Git 리포지터리에서 컨테이너화된 클러스터와 애플리케이션을 관리할 수 있습니다:

• 시스템의 단일 진실 공급원(Single Source Of Truth, SSOT)인 리포지터리.
• 시스템을 운영하는 단일 장소인 리포지터리.

GitLab, Kubernetes, GitOps를 결합하면 다음을 갖출 수 있습니다:

• GitOps 오퍼레이터로서의 GitLab.
• 자동화 및 수렴 시스템으로서의 Kubernetes.
• 지속적 통합을 위한 GitLab CI/CD.
• 지속적 배포와 클러스터 관측을 담당하는 에이전트.
• 기본으로 제공되는 자동 드리프트 교정.
• 여러 주체의 필드 관리를 투명하게 다루는 서버 사이드 적용 기반 리소스 관리.

배포 순서#

다음 다이어그램은 GitOps 배포의 리포지터리와 주요 주체를 보여 줍니다:

%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
accTitle: Deployment sequence
accDescr: Shows the repositories and main actors in a GitOps deployment.
participant D as Developer
participant A as Application code repository
participant M as Deployment repository
participant R as OCI registry
participant C as Agent configuration repository
participant K as GitLab agent
participant F as Flux
loop Regularly
K-->>C: Grab the configuration
end
D->>+A: Pushing code changes
A->>M: Updating manifest
M->>R: Build an OCI artifact
M->>K: Notify
K->>F: Notify and watch sync
R-->>F: Pulling and applying changes
K->>M: Notify after sync

GitOps 배포에는 Flux와 agentk를 함께 사용해야 합니다. Flux는 클러스터 상태를 소스와 동기화된 상태로 유지하고, agentk는 Flux 설정을 단순화하고 클러스터와 GitLab 사이의 액세스 관리를 제공하며 GitLab UI에서 클러스터 상태를 시각화합니다.

소스 제어를 위한 OCI#

Flux의 소스 컨트롤러로는 Git 리포지터리 대신 OCI 이미지를 사용해야 합니다. GitLab 컨테이너 레지스트리는 OCI 이미지를 지원합니다.

리포지터리 구조#

구성을 단순하게 유지하려면 팀마다 전달 리포지터리를 하나씩 둡니다. 전달 리포지터리는 애플리케이션별로 여러 OCI 이미지로 패키징할 수 있습니다.

리포지터리 구조에 대한 추가 권장 사항은 Flux 문서를 참고합니다.

즉각적인 Git 리포지터리 조정#

보통 Flux 소스 컨트롤러는 구성된 간격으로 Git 리포지터리를 조정합니다. 그래서 git push와 클러스터 상태 조정 사이에 지연이 생길 수 있고, GitLab에서 불필요한 풀이 발생합니다.

Kubernetes용 에이전트는 자신이 연결된 인스턴스의 GitLab 프로젝트를 참조하는 Flux GitRepository 객체를 자동으로 탐지하고, 그 인스턴스에 대한 Receiver를 구성합니다. Kubernetes용 에이전트가 액세스할 수 있는 리포지터리로의 git push를 탐지하면 Receiver가 트리거되고, Flux는 해당 리포지터리의 변경 사항에 맞춰 클러스터를 조정합니다.

즉각적인 Git 리포지터리 조정을 사용하려면 다음이 실행되는 Kubernetes 클러스터가 있어야 합니다:

• Kubernetes용 에이전트.
• Flux source-controller 및 notification-controller.

즉각적인 Git 리포지터리 조정은 푸시와 조정 사이의 시간을 줄일 수 있지만, 모든 git push 이벤트가 수신된다고 보장하지는 않습니다. 따라서 GitRepository.spec.interval은 계속 적절한 값으로 설정해야 합니다.

사용자 정의 웹훅 엔드포인트#

Kubernetes용 에이전트가 Receiver 웹훅을 호출할 때 에이전트는 기본적으로 http://webhook-receiver.flux-system.svc.cluster.local을 사용하며, 이 값은 Flux 부트스트랩 설치가 설정하는 기본 URL이기도 합니다. 사용자 정의 엔드포인트를 구성하려면 flux.webhook_receiver_url을 에이전트가 확인할 수 있는 URL로 설정합니다. 예를 들면 다음과 같습니다:

flux:
  webhook_receiver_url: http://webhook-receiver.another-flux-namespace.svc.cluster.local

다음 형식으로 구성된 서비스 프록시 URL은 별도로 처리됩니다: /api/v1/namespaces/[^/]+/services/[^/]+/proxy. 예를 들면 다음과 같습니다:

flux:
  webhook_receiver_url: /api/v1/namespaces/flux-system/services/http:webhook-receiver:80/proxy

이 경우 Kubernetes용 에이전트는 사용 가능한 Kubernetes 구성과 컨텍스트를 사용해 API 엔드포인트에 연결합니다. 클러스터 외부에서 에이전트를 실행하면서 Flux 알림 컨트롤러에 대해 Ingress를 구성하지 않은 경우 이 방식을 사용할 수 있습니다.

토큰 관리#

일부 Flux 기능을 사용하려면 여러 액세스 토큰이 필요할 수 있습니다. 또한 같은 결과를 얻는 데 여러 토큰 유형을 사용할 수 있습니다.

이 절에서는 필요할 수 있는 토큰에 대한 지침을 제시하고, 가능한 경우 토큰 유형을 권장합니다.

Flux의 GitLab 액세스#

GitLab 컨테이너 레지스트리나 Git 리포지터리에 액세스할 때 Flux는 다음을 사용할 수 있습니다:

• 프로젝트 또는 그룹 배포 토큰.
• 프로젝트 또는 그룹 배포 키.
• 프로젝트 또는 그룹 액세스 토큰.
• 개인 액세스 토큰.

이 토큰에는 쓰기 액세스 권한이 필요하지 않습니다.

http 액세스가 가능하다면 프로젝트 배포 토큰을 사용해야 합니다. git+ssh 액세스가 필요하다면 배포 키를 사용해야 합니다. 배포 키와 배포 토큰을 비교하려면 배포 키를 참고합니다.

배포 토큰 생성, 교체, 보고를 자동화하는 지원은 이슈 389393에 제안돼 있습니다.

Flux에서 GitLab 알림#

Git 소스에서 동기화하도록 Flux를 구성하면 Flux가 GitLab 파이프라인에 외부 job 상태를 등록할 수 있습니다.

Flux에서 외부 job 상태를 받으려면 다음을 사용할 수 있습니다:

• 프로젝트 또는 그룹 배포 토큰.
• 프로젝트 또는 그룹 액세스 토큰.
• 개인 액세스 토큰.

이 토큰에는 api 스코프가 필요합니다. 토큰이 유출됐을 때의 공격 범위를 최소화하려면 프로젝트 액세스 토큰을 사용해야 합니다.

Flux를 job으로 GitLab 파이프라인에 통합하는 방안은 이슈 405007에 제안돼 있습니다.

관련 주제#

• 교육 및 데모용 GitOps 실습 예제
• 자기 주도형 강의 워크숍 (AWS EKS를 사용하지만 다른 Kubernetes 클러스터에도 활용할 수 있습니다)
• GitOps 워크플로에서 Kubernetes 시크릿 관리
  • Flux에 내장된 SOPS 사용
  • Sealed Secrets 사용