추적 및 배포 전략
추적 및 배포 전략 (Tracking and Deployment Strategies)
Argo CD 애플리케이션은 Kubernetes 리소스 매니페스트를 추적하는 여러 방식을 지원해요. Helm·Git 각각의 버전 추적 방식과 모호한 Git 참조 처리 방법을 정리했습니다.
출처: 문서
본문
Argo CD 애플리케이션 spec은 Kubernetes 리소스 매니페스트를 추적하는 여러 가지 다른 방식을 제공합니다.
모든 추적 전략에서 앱은 자동 동기화 옵션을 가질 수 있습니다. auto-sync가 구성되면 차이가 감지되는 즉시 새 리소스 매니페스트가 자동으로 적용됩니다.
Note
모든 추적 전략에서 파라미터 오버라이드는 Git 상태보다 우선합니다.
Helm
Helm 차트 버전은 시맨틱 버전(Semantic Versions)입니다. 따라서 다음 버전 범위 중 하나를 사용할 수 있습니다:
| 사용 사례 | 방법 | 예시 |
|---|---|---|
| 버전에 고정 (예: 프로덕션) | 버전 번호 사용 | 1.2.0 |
| 패치 추적 (예: 사전 프로덕션) | 범위 사용 | 1.2.* 또는 >=1.2.0 <1.3.0 |
| 마이너 릴리스 추적 (예: QA) | 범위 사용 | 1.* 또는 >=1.0.0 <2.0.0 |
| 최신 사용 (예: 로컬 개발) | star 범위 사용 | * 또는 >=0.0.0 |
| 사전 릴리스 포함 최신 사용 | -0 접미사가 있는 star 범위 |
*-0 또는 >=0.0.0-0 |
Note
Argo CD가 저장소의 모든 기존 사전 릴리스 버전 태그를 비교 로직에 포함하려면 버전 제약에 사전 릴리스 -0 접미사를 명시적으로 추가해야 합니다. 언급했듯이 *-0은 저장소의 사전 릴리스 버전과 비교하지만 *는 비교하지 않습니다. >=1.2.2가 사전 릴리스 버전을 비교하지 않는 것처럼 다른 제약에도 동일하게 적용되며, >=1.2.2-0은 비교에 사전 릴리스 버전을 포함합니다.
Git
Git의 경우 모든 버전은 Git 참조이지만 태그도 시맨틱 버전(Semantic Versions)을 사용할 수 있습니다:
| 사용 사례 | 방법 | 비고 |
|---|---|---|
| 버전에 고정 (예: 프로덕션) | (a) 커밋에 태그를 달고(e.g. v1.2.0) 그 태그를 사용하거나, (b) 커밋 SHA 사용. |
커밋 고정 참조. |
| 패치 추적 (예: 사전 프로덕션) | 범위 사용 (예: 1.2.* 또는 >=1.2.0 <1.3.0) |
태그 추적 참조 |
| 마이너 릴리스 추적 (예: QA) | 범위 사용 (예: 1.* 또는 >=1.0.0 <2.0.0) |
태그 추적 참조 |
| 최신 사용 (예: 로컬 개발) | HEAD 또는 master 사용 (master가 master 브랜치라고 가정) |
HEAD / 브랜치 추적 참조 |
| 사전 릴리스 포함 최신 사용 | -0 접미사가 있는 star 범위 |
*-0 또는 >=0.0.0-0 |
HEAD / 브랜치 추적 (HEAD / Branch Tracking)
브랜치 이름이나 심볼릭 참조(예: HEAD)가 지정되면 Argo CD는 지정된 브랜치의 끝이나 심볼릭 참조의 해석된 커밋에 정의된 리소스 매니페스트와 라이브 상태를 지속적으로 비교합니다.
앱을 재배포하려면 매니페스트 중 (적어도) 하나를 변경하고, 커밋한 다음 추적하는 브랜치/심볼릭 참조로 push하세요. 그러면 변경이 Argo CD에 감지됩니다.
태그 추적 (Tag Tracking)
태그가 지정되면 지정된 Git 태그의 매니페스트가 동기화 비교에 사용됩니다. 이는 브랜치 추적보다 몇 가지 장점을 제공합니다. 태그는 일반적으로 더 안정적이고 덜 자주 갱신되며, 무엇이 태그를 구성하는지에 대한 수동 판단이 있기 때문입니다.
앱을 재배포하려면 사용자가 Git으로 태그를 다른 커밋 SHA에 다시 태그(재태깅)하여 태그의 의미를 변경합니다. Argo CD는 비교/동기화를 수행할 때 태그의 새 의미를 감지합니다.
하지만 시맨틱 버전을 사용한다면 서비스 리비전에 제약을 설정할 수 있으며, Argo CD는 제약 규칙을 따라 최신 버전을 가져옵니다.
Note
그리고 semver 제약(*, >, <, - 등을 포함하는 것)에는 시맨틱 버전 태그에 prefix를 사용하거나 사용하지 않을 수 있습니다. 예를 들어 >=app1/v1.0.0-0 같은 제약은 app1/v1.0.0-rc.1 같은 사전 릴리스 태그와 일치합니다.
| 저장소의 태그 | tagPrefix | targetRevision | 해석 결과 |
|---|---|---|---|
app1/v1.0.0, app1/v1.0.1 |
app1/ |
v1.0.* |
app1/v1.0.1 |
app2/v1.0.0, app2/v2.0.0 |
app2/ |
v1.* |
app2/v1.0.0 |
app1/cluster1/prod/v1.0.0 |
app1/cluster1/prod/ |
v1.* |
app1/cluster1/prod/v1.0.0 |
커밋 고정 (Commit Pinning)
Git 커밋 SHA가 지정되면 앱은 실질적으로 지정된 커밋에 정의된 매니페스트에 고정됩니다. 이는 가장 제한적인 기법이며 일반적으로 프로덕션 환경을 제어하는 데 사용됩니다.
커밋 SHA는 의미가 바뀔 수 없으므로, 커밋에 고정된 앱의 라이브 상태를 변경하는 유일한 방법은 새 매니페스트가 포함된 다른 커밋으로 애플리케이션의 추적 리비전을 갱신하는 것입니다. 리비전에 고정된 앱에도 파라미터 오버라이드를 설정할 수 있다는 점을 유의하세요.
Argo CD의 모호한 Git 참조 처리 (Handling Ambiguous Git References in Argo CD)
애플리케이션을 배포할 때 Argo CD는 targetRevision 필드에 의존해 Git 저장소의 어떤 리비전을 사용할지 결정합니다. 이는 브랜치, 태그 또는 커밋 SHA일 수 있습니다. 때때로 여러 Git 참조가 같은 이름을 가질 수 있습니다(예: 브랜치와 태그 모두 release-1.0으로 이름이 지정된 경우). 이러한 모호한 참조는 지속적인 재조정 루프 같은 예상치 못한 동작을 초래할 수 있습니다.
현재 Argo CD는 저장소에서 모든 브랜치와 태그를 가져옵니다. targetRevision이 여러 참조와 일치하면 Argo CD는 이를 해석하려 시도하고 예상과 다른 커밋을 선택할 수 있습니다. 예를 들어 저장소에 다음 참조가 있다고 가정해보세요:
refs/heads/release-1.0 -> commit B
refs/tags/release-1.0 -> commit A
위 시나리오에서 release-1.0은 브랜치(커밋 B를 가리킴)와 태그(커밋 A를 가리킴)를 모두 가리킵니다. 애플리케이션의 targetRevision이 release-1.0으로 설정되면 Argo CD는 커밋 A나 커밋 B 중 하나로 해석할 수 있습니다. 해석된 커밋이 현재 배포된 것과 다르면 Argo CD는 지속적으로 동기화를 시도해 재조정을 일으키게 됩니다. 이 모호함을 피하려면 다음 모범 사례를 따르세요:
targetRevision필드에 정규화된(fully-qualified) Git 참조를 사용하세요. 예를 들어 브랜치는refs/heads/release-1.0, 태그는refs/tags/release-1.0을 사용하세요.- Git 저장소에서 브랜치와 태그에 같은 이름을 사용하지 마세요.