center-managed

저장소 전략

최소 2개 이상의 Git 저장소를 사용하는 것을 권장합니다.
- 애플리케이션 저장소: 애플리케이션 소스 코드와 애플리케이션 배포를 위한 배포 매니페스트(예: kubernetes yaml)를 포함합니다.
- 배포 환경 구성 저장소: 배포 환경에 대한 모든 매니페스트를 포함합니다.
  - 애플리케이션과 인프라 서비스(모니터링, 메시지 브로커 등)가 어떤 버전으로 어떻게 구성되어야 하는지에 대한 정보가 들어있습니다.
애플리케이션 배포 매니페스트를 별도의 깃 저장소에 보관해도 되고 템플릿 형태로만 가지고 있다가 배포 시 배포 환경 구성 저장소와 합쳐서 매니페스트를 생성하는 방식으로도 사용이 가능합니다.

배포 전략

깃옵스에서는 푸시 타입(Push Type)과 풀 타입(Pull Type), 두 가지의 배포 전략을 가이드 하고 있습니다. 두 옵션 간의 차이점은 저장소에 있는 매니페스트와 배포 환경의 상태를 일치시키는 방법입니다. 무엇을 선택해도 상관없으나 깃옵스는 보안상의 이유로 풀 타입 배포 전략을 권장하고 있습니다.

▲ Push Type

저장소에 있는 매니페스트가 변경되었을 때 배포 파이프라인을 실행시키는 구조입니다. 아키텍처가 단순하여 인기 있는 방법이며 젠킨스(Jenkins), 서클CI(CircleCI) 등의 구현에 사용할 수 있는 도구들도 다양합니다. 가장 큰 특징으로 배포 환경(Environment)의 개수에 영향을 받지 않습니다. 접속 정보를 추가하거나 수정하는 것만으로도 간단하게 배포 환경을 추가하거나 변경할 수 있습니다.

그러나 항상 연결되어 있는 상태가 아니라서 실제 배포 작업이 수행되는 시점에 실패할 수도 있습니다. 그리고 배포 환경이 손상되어 배포 환경 구성 저장소의 내용과 다를 경우 차이를 감지하고 배포 파이프라인을 다시 실행시키거나 알림을 줄 수 있는 별도의 모니터링 시스템이 필요합니다.

▲ Pull Type

배포 환경에 위치한 별도의 오퍼레이터가 배포 파이프라인을 대신합니다. 이 오퍼레이터는 저장소의 매니페스트와 배포 환경을 지속적으로 비교하다가 차이가 발생할 경우 저장소의 매니페스트를 기준으로 배포 환경을 유지시켜 줍니다. 만약 누군가가 직접 손으로(허가 받지 않은 작업) 배포 환경을 변경했을 때도 다시 되돌려지게 되는데 이는 배포 환경의 변경은 저장소의 매니페스트를 통해서만 유효하다는 것을 보장해줍니다. 다시 말해 배포 환경에 대한 모든 이력은 배포 환경 구성 저장소 즉, 깃에 존재한다는 것을 의미합니다. 이런 방식을 지원하는 도구로는 아르고CD, 젠킨스X(JenkinsX), 그리고 깃옵스라는 용어를 만든 위브웍스에서 제작한 플럭스(Flux)가 있습니다.

앞에서 보안상의 이유로 깃옵스는 풀 타입 배포 전략을 권장한다고 언급했습니다. 이는 구조적 차이에서 발생하는 것으로 푸시 타입의 경우 배포 환경에 대한 자격 증명 정보를 외부에서 관리할 수 밖에 없습니다. 배포 환경 입장에서는 배포 파이프라인 자체가 외부 도메인이기 때문입니다. 그리고 일반적으로 배포 파이프라인에게 배포 환경에 대한 읽기?쓰기 권한을 부여하기 때문에 만의 하나 노출된다면 큰 피해를 볼 수도 있습니다.

반면 풀 타입의 경우 오퍼레이터가 애플리케이션과 동일한 환경에서 동작 중이어서 자격 증명 정보가 외부에 노출될 일이 없습니다. 그리고 배포 환경에 대한 자격 증명 정보도 오퍼레이터 관리를 위한 최소한의 인력으로 한정 지을 수 있습니다. 신경 써야 할 것은 배포 환경에서 깃 저장소와 이미지 저장소로의 접근 정도입니다.

인증 및 인가

위의 push방식과 pull방식을 장황하게 설명한 이유가 git과 배포환경(예를 들어 AWS)의 인증관리의 주체를 누가 가져가느냐를 결정해야 합니다.

push
pull
oidc

git-action workflow 재사용 하기

Organization아래 하위 repo에서 cicd를 구현 하면 각 repo 마다 workflow 파일을 작성 해야 합니다. 하위 repo가 많아지면 많아 질 수록 하나씩 배포를 해야 하며 정책이나 인프라가 변경 되었을 시 마찬가지로 모든 하위 파이프라인을 일일히 변경 해야 합니다.

name: Caller Workflow

on:
  push:

jobs:
  call-workflow-1-in-local-repo:
    uses: outsideris/actions-test/.github/workflows/called.yaml@36f0d0aef48da832eb03a4d1d82e1705392bbfdb
    with:
      username: outsider
    secrets:
      SECRET_SEED: world
  call-workflow-2-in-local-repo:
    uses: ./.github/workflows/called.yaml
    with:
      username: mona
    secrets:
      SECRET_SEED: seed

Organization Secret 관리

git CLI

metadata 관리

github runner를 활용한 실행 시 인스턴스 관리

Previous[Github]Nextbitbucket

Last updated 3 months ago