Quiz: Repository Structure and Promotion

앱 소스 코드와 배포 매니페스트를 같은 저장소에 두었을 때 CI 가 이미지 태그를 커밋하면 생기는 대표적 문제는?

• Git 저장소 용량이 급격히 커진다
• 태그 커밋이 다시 CI 를 트리거해 빌드가 무한히 반복될 수 있다
• kustomize 가 이미지 태그를 인식하지 못한다
• Argo CD 가 저장소를 클론할 수 없게 된다

환경을 브랜치로 나누는 방식(Environment per Branch)의 대표적 단점은?

• 브랜치는 Git 이 지원하지 않는 기능이라 도구가 제한된다
• 브랜치를 쓰면 Argo CD 가 폴링을 할 수 없다
• 브랜치마다 별도의 클러스터가 반드시 필요하다
• 브랜치 간 diff 에 환경 차이와 시간 차이가 섞여 보이고 cherry-pick 관리 비용이 커진다

잘 설계된 GitOps 저장소에서 stage → prod 승격 PR 의 이상적인 모습은?

• prod 오버레이 전체를 stage 오버레이 내용으로 덮어쓴다
• prod 브랜치를 stage 브랜치로 강제 리셋한다
• prod 오버레이의 이미지 태그 한 줄만 바뀐다
• prod 네임스페이스를 지우고 다시 만드는 매니페스트를 추가한다

이미지 태그로 latest 를 쓰면 어긴 것에 가장 가까운 원칙은?

• 버전 관리되고 불변 — 같은 커밋이 시점에 따라 다른 것을 실행하게 된다
• 선언적 — YAML 이 아니라 명령으로 배포하게 된다
• 자동으로 당겨짐 — 에이전트가 이미지를 가져올 수 없다
• 지속적으로 조정됨 — 조정 루프가 동작하지 않는다

app-of-apps 패턴과 ApplicationSet 의 차이로 옳은 것은?

• app-of-apps 는 멀티클러스터만 지원하고 ApplicationSet 은 단일 클러스터 전용이다
• app-of-apps 는 자식 Application 을 파일로 명시하고, ApplicationSet 은 제너레이터로 목록을 계산한다
• app-of-apps 는 Flux 전용 패턴이고 ApplicationSet 은 Argo CD 전용이다
• 둘은 완전히 동일하며 이름만 다르다

AppProject 를 두는 주된 목적은?

• Application 의 동기화 주기를 앱마다 다르게 설정하기 위해
• Helm 차트의 values 를 프로젝트 단위로 병합하기 위해
• Git 저장소의 브랜치 보호 규칙을 클러스터에 반영하기 위해
• Application 이 쓸 수 있는 소스 저장소·대상 클러스터·네임스페이스·리소스 종류를 제한하기 위해