• NCP(Naver Cloud Platform) 을 사용하여 GitLab 과 ArgoCD 연동!

    2026. 5. 27.

    by. Daramu

    이전 포스팅에서 argoCD를 설치하고,

    또 과거 포스팅에서 GitLab를 구축하고 gitlab runner를 통해 CI까지 진행하였다.

     

    아직 구축되지 않았다면 아래 링크를 통해 구축 가능하다.

    GitLab 구축 :: Daramu

     

    GitLab 구축

    소스코드 저장소에서 전 세계적으로 가장 유명하며 많이 사용하는 곳은 GitHub일 것이다.하지만 GitHub의 데이터 자체는 외부에 있으므로, 보안에 민감하거나 코드 저장소를 국내에 한정해야 하는

    daramu.tistory.com

     

    NCP(Naver Cloud Platform)을 활용하여 GitLab Runner로 CI/CD 구축 :: Daramu

     

    NCP(Naver Cloud Platform)을 활용하여 GitLab Runner로 CI/CD 구축

    GitLab은 단순 코드 저장소로 사용할 수 있지만, GitLab Runner를 통해 CI/CD를 구현할 수도 있다. 물론 Jenkins, ArgoCD, NCP의 Source 시리즈 등 여러 가지 CI/CD 도구가 있지만, GitLab으로 CI/CD를 구축하였을 경

    daramu.tistory.com

     

     

    설정까지 했다면, 현재 두개의 프로젝트(레포지토리)가 있을 것이다.

    스프링 부트(코드)와 Dockerfile, 그리고 gitlab-ci.yml 이 있는 프로젝트 한개,

    그리고 k8s의 정의(manifest file)가 있는 k8s 두개다.

     

    이전 gitlab-ci.yml을 통해 설정한 CI를 잘 생각해보면 backend에 push -> gitlab runner 작동 -> k8s 프로젝트의 이미지 태그 update가 되는 것을 알 수 있을 것이다.

     

    update-manifest:
      stage: update-manifest
      image: alpine/git:latest
      script:
        - IMAGE_TAG="${CI_COMMIT_SHORT_SHA}-${CI_PIPELINE_IID}"
        - git clone http://${GIT_USER}:${GIT_TOKEN}@172.16.211.6/root/cicd-demo-k8s.git
        - cd cicd-demo-k8s
        - |
          sed -i "s|image: ${REGISTRY}/${IMAGE_NAME}:.*|image: ${REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG}|g" ${MANIFEST_PATH}
        - git config user.email "gitlab-ci@cicd.com"
        - git config user.name "GitLab CI"
        - git add ${MANIFEST_PATH}
        - git commit -m "update image to ${IMAGE_TAG}"
        - git push http://${GIT_USER}:${GIT_TOKEN}@172.16.211.6/root/cicd-demo-k8s.git main
      only:
        - main

     

    위의 git clone을 통해 k8s자원을 가져오고, 해당 자원 안에 cicid-demo-k8s라는 폴더에 들어가(cd) sed를 통해 이미지 태그를 변경하고, 변경한 값을 push 한다.

    그렇기에 GIT_token등의 발행을 진행했었다.

     

    여기서 ArgoCD는 manifest파일을 감시하고 있다가, 변경이 감지되면 재실행 시켜주는 오픈소스다.

    이미 gitlab CI를 통해 k8s자원에 대한 update까지 이어지고 있으니, argoCD와 k8s자원을 연결만 시켜주면 된다.

     

    설치된 argoCD와 gitlab을 연동하기 위해, 우선 SSH 키를 생성한다.

    어떠한 장소에서 해도 상관없이 두개의 키 쌍이 중요하니 로컬에서 생성하겠다.

    #Powershell
    ssh-keygen -t ed25519 -C "argocd" -f argocd_key

     

     

    위에 명령어를 쳤다면 명령어를 친 디렉토리에 바로 "argocd_key" 와 "argocd_key.pub" 가 생성됬을 것이다.

    이제 .pub가 붙은 Public Key는 gitlab에 등록하고, 아무것도 안붙은 Private키는 argoCD에 등록할 것이다.

     

    이전 구축했던 두개의 repo중에 k8s 프로젝트로 진입하여 왼쪽 Settings -> Repository 로 들어간다.

     

    그 중 Deploy keys라는 부분에 Title을 입력하고, key에 바로 위에서 생성했던 Public Key를 복붙한다.

    argoCD는 변화를 감지(읽기)때문에 굳이 write권한은 필요 없으니 "Grant write(읽기권한)" 은 선택 사항이다.

     

    키를 저장했다면 이제 Private Key를 argoCD에 넣으면 된다.

     

    argoCD에서 Settings -> Repositories -> +Connect Repo로 repository 연결 페이지에 진입한다.

     

     

    연결 페이지에서 connection method는 SSH이며, 붉은 네모칸 안에는 방금 생성했던 Private Key를 집어넣는다.

    그리고 Repository URL은 각기 생성된 repo이름으로 하면 된다.

    git@{gitlab_IP}:{repo_path} 가 규칙이다. 주의할 것은 ip와 path사이에 슬래시(/)가 아닌 콜론(:)이다.

     

    그리고 Skip server vertification을 체크해서 SSH known_hosts를 건너뛴다.

     

     

     

    연결이 되었다면 이렇게 Successful이라고 나온다.

     

    마지막으로 pulling 방식에 대해 말을 해야한다.

    argoCD는 기본적으로 2분 간격으로 풀링을 진행하며, 변경사항이 있을경우 이를 수정한다.

     

    2분의 간격이 싫다면 webhook을 연결해야 하지만, argoCD는 https만 받기 때문에 테스트 환경에서는 자체 인증서를 발급하는 등의 작업이 필요하다.

     

    허나 그 구성이 너무 오래 걸리고, 테스트 환경 특성상 https로 webhook연결 보다는 풀링 간격 조정을 통해 빠른 적용을 테스트 하겠다.

     

    Bastion에서 kubectl edit을 통해 configmap수정으로 풀링 간격을 1분으로 수정한다.

    kubectl edit configmap argocd-cm -n argocd
    
    # 기본 120s → 60s로 단축
    data:
      timeout.reconciliation: 60s

     

     

    모든 연결이 되었다면 application yaml파일을 작성한다.

    Bastion 서버에서 아래 yaml파일을 작성하는데, 자신의 상황에 따라 수정이 필요하다.

    1. repoURL: repo URL

    2. path: repo 안에 폴더명

    3. namespace: 배포할 namespace(예시 yaml의 default 부분)

    4. targetRevision: 브런치가 main이 맞는지

     

    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: cicd-demo-backend
      namespace: argocd
    spec:
      project: default
      source:
        repoURL: git@172.16.211.6:root/cicd-demo-k8s.git
        targetRevision: main
        path: cicd-demo-backend
      destination:
        server: https://kubernetes.default.svc
        namespace: default
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true

     

    모두 생성했다면 kubectl apply -f {name}으로 적용한다.

     

    적용 했다면 argoCD 웹페이지의 Application 쪽에 설정 중인걸 볼 수 있다.

    (Progressing 부분은 시간이 지나면 Healthy로 변한다.)

    아니면 쿠버네티스에서 아래 명령어로 application 상태를 볼 수 있다.

    kubectl get application -A

     

    kubectl get pod 결과, pod도 정상적으로 올라왔다.

     

     

    결과적으로 다음과 같은 순서를 따르게 된다.

     

    backend로 코드 push

    -> gitlab CI(GitLab Runner): 이미지 build & NCP Container Registry push

    -> gitlab CI(GitLab Runner): k8s 프로젝트의 manifest 이미지 태그 업데이트(commit & push)

    -> ArgoCD: manifest 업데이트 확인 후 클러스터 자동 배포

     

    그럼 위의 순서가 제대로 돌아가는지 알기 위해, backend에 다시 push 이벤트를 발행하겠다.

     

     

    backend로 코드 push

     

    gitlab CI(GitLab Runner): 이미지 build & NCP Container Registry push

     

    gitlab CI(GitLab Runner): k8s 프로젝트의 manifest 이미지 태그 업데이트(commit & push)

    (위와 동일한 그림이지만, 실제 push 확인을 위해 ncp continaer registry와 gitlab 화면으로 대체)

     

    위의 그림에서 [main d..] 부분에 update image to 88cdc98a-3 을 볼 수 있다.

    gitlab runner가 스스로 이미지 태그를 만들어 push 하였다는 의미다.

     

    아래 그림은 순서대로 NCP Container Registry, Gitlab 프로젝트(repo) 이다. 이미지 저장소와 코드 저장소에 모두 정상적으로 GitLab CI의 이름으로 push 되었다.

     

     

    ArgoCD: manifest 업데이트 확인 후 클러스터 자동 배포

    kubectl edit pod 로 확인된 실제 pod의 images로, 잘 사용하고 있음을 확인할 수 있다.

     

     

    물론 argoCD UI에서도 Healthy 로 잘 표기되어있다.

    붉은 네모칸을 보면 동일하게 GitLab CI의 이름으로 push하여 88cdc98a-3로 수정되었던 것을 감지하여 동기화한걸 알 수 있다.

     

     

    만약 추가적인 도메인(서비스)를 업데이트 한다면,

    동일한 Application에서 관리하는게 아니라 여러개의 pplication을 만들어야 한다.

    (k8s 레포는 한개여도, 그 안에 디렉토리(path)로 나누어, argoCD에 그 path에 맞는 Application을 생성해야한다는 의미다.)

     

    ex:

    Application: cicid-demo-backend -> Path: cicid-demo-backend

    Application: cicid-demo-frontend -> Path: cicid-demo-frontend

     

    argoCD는 기본적으로 Application 1개 = 서비스 1개 단위로 관리하는게 일반적이니, 이 점을 기억하고 있으면 된다.

     

     

    댓글