<div id="readability-page-1" class="page"><div>            <h2>Prologue</h2>
<p data-ke-size="size16">최근 들어, 팀 내부의 CI/CD 파이프라인을 구축하기 위해 다양한 오픈 소스 툴을 살펴보고 있습니다. ArgoCD는 CD 쪽 파트를 담당하는 훌륭한 도구입니다. 하지만 이런 도구를 활용할 때 어떻게 하면 더 효율적으로 사용할 수 있는지는 좀 더 공부가 필요한 상황입니다. 특히 오늘 포스트에서 소개하는 내용이 그러한데요. 얼마전까지는 애플리케이션의 소스 코드 레포지토리에 ArgoCD가 이용할 매니페스트 파일도 함께 관리했습니다. 하지만, 경험적으로 알게 된 사실은, 이렇게 하게 되니 매니페스트 파일만 수정했을 뿐인데도 CI가 자동으로 발생하는 상황이 벌어졌습니다...🥲 이러한 상황을 막기 위해 ArgoCD 공식 문서에서도 매니페스트 파일과 소스 코드 레포지토리를 분리할 것을 권고하고 있는데요. 오늘은 이 내용을 좀 더 자세히 알아보겠습니다. 이 포스트는 ArgoCD 공식 문서를 (발)번역한 내용입니다.</p>
<h2>Config 분리하기 vs. 소스 코드 레포지토리</h2>
<p data-ke-size="size16">여러분의 애플리케이션 소스 코드로부터 설정 파일을 분리하여 Kubernetes 매니페스트 파일을 별도의 Git 레포지토리에 보관하는 것을 다음과 같은 이유로 강력히 추천합니다.</p>
<ol data-ke-list-type="disc">
<li>이 방법을 사용하면 애플리케이션 코드와 애플리케이션 설정 파일을 깔끔하게 분리할 수 있습니다. 아마도 전체 CI 빌드 과정을 거치지 않고, 그저 매니페스트 파일만 업데이트하기를 원할 때가 있을 겁니다. 예를 들어, 빌드를 유발하지 않고 그저, Deployment의 spec에 적힌 replicas의 숫자를 늘리고 싶을 때가 이에 해당합니다.</li>
<li>이력을 더 깔끔하게 관리할 수 있습니다. 이력 관리를 목적으로 한다면, 설정 파일만 보관하고 있는 레포지토리의 Git 히스토리가 더 깔끔하게 이력을 살펴볼 수 있을 것입니다. 개발 작업에 따라 발생하는 이력이 기록되지 않기 때문이죠.</li>
<li>어쩌면, 여러분의 애플리케이션이 한 개의 유닛으로 배포되더라도, 이 애플리케이션은 여러 Git 레포지토리로부터 빌드된 여러 서비스로 구성될 수 있습니다. 종종, 마이크로서비스 애플리케이션은 서로 다른 버전, 릴리즈 사이클 등을 가진 서비스들로 구성됩니다. 예를 들자면, ELK와 Kafka + Zookeeper가 그러하죠. 당연하게도, 이렇게 구성되는 매니페스트 파일들을 랜덤하게 여러 서비스들 중 하나의 레포지토리에 보관한다는 것은 말이 되기 어렵습니다.</li>
<li>접근을 분리할 수 있습니다. 애플리케이션을 개발하는 개발자가 고의든 고의가 아니든 프로덕션 환경에 푸시할 수 있는 사람과 같을 이유가 없습니다. 레포지토리를 다르게 가져감으로써, 애플리케이션의 소스 코드에만 접근하여 커밋할 수 있도록 만들 수 있습니다.</li>
<li>만약 CI 파이프라인을 자동화하고자 한다면, 매니페스트 파일을 수정하여 같은 레포지토리에 푸시하는 행위는 빌드 작업을 무한 루프에 빠지게 만들 위험성이 있습니다. 별도의 레포지토리를 사용함으로써 이런 문제로부터 안전하게 파이프라인을 보호할 수 있습니다.</li>
</ol>
<h2>Imperativeness를 위한 여지를 남겨두기</h2>
<p data-ke-size="size16">일부의 Imperativeness (명령어를 통한 제어)와 자동화를 할 수 있는 여지를 남겨두기 위해 모든 것을 Git 매니페스트에 정의하지 않는 것을 권장합니다. 예를 들어서, Horizontal Pod Autoscaler에서 Deployment의 replicas 숫자를 관리하려면, Git 매니페스트를 통해 replicas를 추적하지 않는 것이 좋습니다.</p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  # 만약 replicas를 HPA로 관리하고 싶다면 replicas를 정의하지 마세요
  # replicas: 1
  template:
    spec:
      containers:
      - image: nginx:1.7.9
        name: nginx
        ports:
        - containerPort: 80
...</code></pre>
<h2>Git 리비전의 매니페스트가 정말 최종본인지 확인하세요</h2>
<p data-ke-size="size16">helm이나 kustomize와 같은 템플릿 도구를 사용할 때, 매니페스트의 날짜가 변동될 수 있습니다. 예를 들어, 다음과 같은 <code>kustomization.yaml</code> 파일을 생각해보세요.</p>
<pre><code>bases:
- github.com/argoproj/argo-cd//manifests/cluster-install</code></pre>
<p data-ke-size="size16">위와 같은 kustomization은 argo-cd의 레포지토리의 HEAD 리비전에 대한 원격 베이스를 이용하고 있습니다. 그러나 이는 안정적인 대상이 아니기 때문에, kustomize 애플리케이션의 매니페스트는 Git 레포지토리를 변경하지 않고도, 갑자기 그 의미가 변경될 수 있습니다. 따라서 다음과 같이 Git 태그를 사용하거나, SHA를 함께 커밋하는 것을 고려해보세요.</p>
<pre><code>bases:
- github.com/argoproj/argo-cd//manifests/cluster-install?ref=v0.11.1</code></pre>
<h2>마무리</h2>
<p data-ke-size="size16">여기까지 따라오시느라 고생 많으셨습니다. 만약 이 글이 도움이 되셨다면 글 좌측 하단의 하트❤를 눌러주시면 감사하겠습니다.</p>
<p data-ke-size="size16">혹시라도 글에 이상이 있거나, 이해가 가지 않으시는 부분, 또는 추가적으로 궁금하신 내용이 있다면 주저 마시고 댓글💬을 남겨주세요! 빠른 시간 안에 답변을 드리겠습니다 😊</p>
<h2>참고</h2>
<ul data-ke-list-type="disc">
<li><a href="https://argoproj.github.io/argo-cd/user-guide/best_practices/">https://argoproj.github.io/argo-cd/user-guide/best_practices/</a></li>
</ul>                        
</div></div>

욱이의 IT 생존일지

Jaewook Oh

Prologue
최근 들어, 팀 내부의 CI/CD 파이프라인을 구축하기 위해 다양한 오픈 소스 툴을 살펴보고 있습니다. ArgoCD는 CD 쪽 파트를 담당하는 훌륭한 도구입니다. 하지만 이런 도구를 활용할 때 어떻게 하면 더 효율적으로 사용할 수 있는지는 좀 더 공부가 필요한 상황입니다. 특히 오늘 포스트에서 소개하는 내용이 그러한데요. 얼마전까지는 애플리케이션의 소스 코드 레포지토리에 ArgoCD가 이용할 매니페스트 파일도 함께 관리했습니다. 하지만, 경험적으로 알게 된 사실은, 이렇게 하게 되니 매니페스트 파일만 수정했을 뿐인데도 CI가 자동으로 발생하는 상황이 벌어졌습니다...  이러한 상황을 막기 위해 ArgoCD 공식 문서에서도 매니페스트 파일과 소스 코드 레포지토리를 분리할 것을 권고하고 있는데요. 오늘은 이 내용을 좀 더 자세히 알아보겠습니다. 이 포스트는 ArgoCD 공식 문서를 (발)번역한 내용입니다.
Config 분리하기 vs. 소스 코드 레포지토리
여러분의 애플리케이션 소스 코드로부터 설정 파일을 분리하여 Kubernetes 매니페스트 파일을 별도의 Git 레포지토리에 보관하는 것을 다음과 같은 이유로 강력히 추천합니다.
이 방법을 사용하면 애플리케이션 코드와 애플리케이션 설정 파일을 깔끔하게 분리할 수 있습니다. 아마도 전체 CI 빌드 과정을 거치지 않고, 그저 매니페스트 파일만 업데이트하기를 원할 때가 있을 겁니다. 예를 들어, 빌드를 유발하지 않고 그저, Deployment의 spec에 적힌 replicas의 숫자를 늘리고 싶을 때가 이에 해당합니다.
이력을 더 깔끔하게 관리할 수 있습니다. 이력 관리를 목적으로 한다면, 설정 파일만 보관하고 있는 레포지토리의 Git 히스토리가 더 깔끔하게 이력을 살펴볼 수 있을 것입니다. 개발 작업에 따라 발생하는 이력이 기록되지 않기 때문이죠.
어쩌면, 여러분의 애플리케이션이 한 개의 유닛으로 배포되더라도, 이 애플리케이션은 여러 Git 레포지토리로부터 빌드된 여러 서비스로 구성될 수 있습니다. 종종, 마이크로서비스 애플리케이션은 서로 다른 버전, 릴리즈 사이클 등을 가진 서비스들로 구성됩니다. 예를 들자면, ELK와 Kafka + Zookeeper가 그러하죠. 당연하게도, 이렇게 구성되는 매니페스트 파일들을 랜덤하게 여러 서비스들 중 하나의 레포지토리에 보관한다는 것은 말이 되기 어렵습니다.
접근을 분리할 수 있습니다. 애플리케이션을 개발하는 개발자가 고의든 고의가 아니든 프로덕션 환경에 푸시할 수 있는 사람과 같을 이유가 없습니다. 레포지토리를 다르게 가져감으로써, 애플리케이션의 소스 코드에만 접근하여 커밋할 수 있도록 만들 수 있습니다.
만약 CI 파이프라인을 자동화하고자 한다면, 매니페스트 파일을 수정하여 같은 레포지토리에 푸시하는 행위는 빌드 작업을 무한 루프에 빠지게 만들 위험성이 있습니다. 별도의 레포지토리를 사용함으로써 이런 문제로부터 안전하게 파이프라인을 보호할 수 있습니다.
Imperativeness를 위한 여지를 남겨두기
일부의 Imperativeness (명령어를 통한 제어)와 자동화를 할 수 있는 여지를 남겨두기 위해 모든 것을 Git 매니페스트에 정의하지 않는 것을 권장합니다. 예를 들어서, Horizontal Pod Autoscaler에서 Deployment의 replicas 숫자를 관리하려면, Git 매니페스트를 통해 replicas를 추적하지 않는 것이 좋습니다.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  # 만약 replicas를 HPA로 관리하고 싶다면 replicas를 정의하지 마세요
  # replicas: 1
  template:
    spec:
      containers:
      - image: nginx:1.7.9
        name: nginx
        ports:
        - containerPort: 80
...
Git 리비전의 매니페스트가 정말 최종본인지 확인하세요
helm이나 kustomize와 같은 템플릿 도구를 사용할 때, 매니페스트의 날짜가 변동될 수 있습니다. 예를 들어, 다음과 같은 kustomization.yaml 파일을 생각해보세요.
bases:
- github.com/argoproj/argo-cd//manifests/cluster-install
위와 같은 kustomization은 argo-cd의 레포지토리의 HEAD 리비전에 대한 원격 베이스를 이용하고 있습니다. 그러나 이는 안정적인 대상이 아니기 때문에, kustomize 애플리케이션의 매니페스트는 Git 레포지토리를 변경하지 않고도, 갑자기 그 의미가 변경될 수 있습니다. 따라서 다음과 같이 Git 태그를 사용하거나, SHA를 함께 커밋하는 것을 고려해보세요.
bases:
- github.com/argoproj/argo-cd//manifests/cluster-install?ref=v0.11.1
마무리
여기까지 따라오시느라 고생 많으셨습니다. 만약 이 글이 도움이 되셨다면 글 좌측 하단의 하트❤를 눌러주시면 감사하겠습니다.
혹시라도 글에 이상이 있거나, 이해가 가지 않으시는 부분, 또는 추가적으로 궁금하신 내용이 있다면 주저 마시고 댓글 을 남겨주세요! 빠른 시간 안에 답변을 드리겠습니다  
참고
https://argoproj.github.io/argo-cd/user-guide/best_practices/

[DevOps] ArgoCD Best Practice

댓글