GitLab은 GitOps를 위해 Flux를 통합합니다. Flux 시작하기는 GitOps를 위한 Flux 튜토리얼을 참조하세요.

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

• 시스템의 단일 진실 공급원.
• 시스템을 운영하는 단일 장소.

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#

Git 리포지터리 대신 Flux의 소스 컨트롤러로 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 웹훅을 호출할 때 에이전트는 기본적으로 Flux 부트스트랩 설치에서 설정한 기본 URL이기도 한 http://webhook-receiver.flux-system.svc.cluster.local로 설정됩니다. 사용자 정의 엔드포인트를 구성하려면 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 파이프라인에 외부 잡 상태를 등록할 수 있습니다.

Flux에서 외부 잡 상태를 가져오려면 다음을 사용할 수 있습니다:

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

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

GitLab 파이프라인에 잡으로 Flux를 통합하는 것은 이슈 405007에서 제안됩니다.

관련 주제#

• 훈련 및 데모를 위한 GitOps 실용 예시
• 자기 주도 강의실 워크샵 (AWS EKS를 사용하지만 다른 Kubernetes 클러스터에도 사용 가능)
• GitOps 워크플로우에서 Kubernetes 시크릿 관리
  • Flux에 내장된 SOPS와 함께
  • 봉인된 시크릿과 함께