DEVOPS - CI/CD 자동화

배포 자동화, CI/CD 자동화
도대체 무엇인가요

Kubernetes 기반 DevOps CI/CD 구축기

최근 DevOps에 대한 이해를 높이고 실제 환경에서 이를 구현해보기 위해, 많은 기업과 개발자들이 사용하는 CI/CD 도구들을 활용하여 배포 자동화 프로젝트를 진행했습니다. 이번 프로젝트에서는 Gitea, Jenkins, ArgoCD를 활용하여 Kubernetes(K8s) 환경에서 CI/CD 파이프라인을 구축하고, Docker 없이 Kaniko를 이용해 이미지를 빌드하는 방식으로 시스템을 구성했습니다.

 

role, secret, config 등의 관리는 최소화했고 CI/CD 파이프라인의 이해만을 목적으로 진행한 프로젝트로 최종 목적은 git push event 발생 시 harbor 에 이미지가 저장되고, 저장된 이미지를 사용한 pod 가 원하는 namespace 에 배포되는 것입니다.

프로젝트 개요

이 프로젝트는 DevOps를 실무적으로 익히기 위해 진행되었으며, 다음과 같은 목표를 가지고 수행되었습니다.

1. Gitea, Jenkins, ArgoCD를 활용한 CI/CD 파이프라인 구축
2. Kubernetes 환경에서의 자동화된 애플리케이션 배포
3. Docker가 설치되지 않은 환경에서 Kaniko를 이용한 컨테이너 이미지 빌드
4. Private Registry를 활용하여 빌드된 이미지 저장 및 관리

시스템 구성

프로젝트의 전체적인 구조는 아래와 같습니다.

• Kubernetes 클러스터:
  • 1개의 마스터 노드
  • 3개의 워커 노드
  • 1개의 Private Registry 노드 (harbor 노드에만 docker 가 설치되어 있습니다.)
• CI/CD 도구:
  • Gitea: Git 저장소 관리 및 코드 변경 사항 관리
  • Jenkins: Jenkinsfile 을 이용한 CI/CD 파이프라인 자동화
  • ArgoCD: Kubernetes 애플리케이션 배포 자동화
• 컨테이너 이미지 빌드 및 저장:
  • Kaniko: Kubernetes 환경에서 Docker 없이 컨테이너 이미지를 빌드
  • Private Registry: 빌드된 이미지를 저장하고 관리하는 역할 수행

구축 과정

1. Helm을 이용한 CI/CD 도구 배포

CI/CD 구축을 위해 Gitea, Jenkins, ArgoCD를 Kubernetes 환경에서 Helm Chart를 사용하여 설치하였습니다. 이를 통해 간편하게 배포할 수 있었으며, 각 서비스는 독립적인 네임스페이스에서 실행되도록 구성하였습니다.

또한, 외부에서 접근할 수 있도록 서비스 타입(Service Type)을 NodePort로 설정하였습니다.
(service type 은 values.yaml 로 변경했습니다.)

helm install gitea gitea/gitea --namespace gitea 
helm install jenkins jenkins/jenkins --namespace jenkins 
helm install argocd argo/argo-cd --namespace argocd 

NodePort 설정을 통해 Kubernetes 내부에서만 접근할 수 있었던 서비스를 외부에서도 접근 가능하도록 변경하였습니다.

2. Gitea와 Jenkins / Gitea와 ArgoCD Webhook 설정

Gitea를 코드 저장소로 활용하며, 코드가 변경될 때 이를 자동으로 감지하고 CI/CD 프로세스를 실행할 수 있도록 Webhook을 설정하였습니다.

Gitea에서 Jenkins와 Webhook을 연결함으로써, 코드가 푸시될 때 Jenkins에서 자동으로 빌드 및 배포 프로세스가 실행되도록 설정하였습니다. 이를 통해 수동 배포 없이 지속적인 배포가 가능해졌습니다.

 

ArgoCD 가 Gitea 의 yaml 파일들을 감지하고 있다가 변화 발생 시 SYNC 할 수 있도록 webhook 설정하였습니다.

3. Jenkins에서 Kaniko를 이용한 이미지 빌드

일반적으로 컨테이너 이미지를 빌드할 때 Docker를 사용하지만, 본 프로젝트에서는 Kubernetes 환경에서 Docker를 설치하지 않고 Kaniko를 활용하여 이미지를 빌드하는 방식을 채택하였습니다.

Jenkinsfile에서 Kaniko를 실행하는 설정을 추가하여 Gitea에 코드가 푸시되면 자동으로 이미지를 빌드하고 Private Registry에 업로드하도록 구성하였습니다.

Jenkinsfile 

pipeline {
    agent {
        kubernetes {
            yaml """
apiVersion: v1
kind: Pod
spec:
  volumes:
    - name: workspace-volume
      emptyDir: {}
    - name: kaniko-secret
      secret:
        secretName: regcred
        items:
        - key: .dockerconfigjson
          path: config.json
  containers:
    - name: kaniko
      image: gcr.io/kaniko-project/executor:debug
      command:
      - sleep
      args:
      - 9999999
      volumeMounts:
        - name: kaniko-secret
          mountPath: /kaniko/.docker
        - name: workspace-volume
          mountPath: /workspace

"""
        }
    }

    stages {
        stage("Checkout from SCM"){
              steps {
                  git branch: 'main', credentialsId: 'innoverse', url: 'http://{IP 생략}/root/fastAPI.git'
              }

        }

        stage('Build with Kaniko') {
            steps {
                container(name:'kaniko',shell:'/busybox/sh') {
                sh ''' #!/busybox/sh
                    /kaniko/executor \
                    --dockerfile=Dockerfile \
                    --context=dir:///workspace \
                    --destination={IP 생략}/kaniko/innoverse:v1.1 \
                    --skip-tls-verify \
                    --insecure
                '''
                }
            }
        }
        stage('Push Image to Registry') {
            steps {
                script {
                    echo "이미지가 성공적으로 빌드되어 푸시되었습니다."
                }
            }
        }
    }
}

이러한 설정을 통해 Jenkins는 Kaniko를 활용하여 Kubernetes 내부에서 Docker 없이 컨테이너 이미지를 빌드하고 Private Registry에 저장할 수 있도록 하였습니다.

4. ArgoCD를 이용한 배포 자동화

ArgoCD는 GitOps 방식으로 배포를 자동화하는 도구입니다. Gitea의 특정 리포지토리를 감시하고, 코드가 변경되면 Kubernetes 클러스터에 자동으로 배포를 수행하도록 설정하였습니다.

ArgoCD 배포 YAML 예제

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
  namespace: argodeploytest
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
        - name: test
          image: {IP 생략}/kaniko/innoverse:v1.1
          command: ["tail", "-f", "/dev/null"]

이 설정을 적용하면 ArgoCD는 Gitea에서 변경 사항을 감지하고, Kubernetes 클러스터에 새로운 버전의 애플리케이션을 자동으로 배포합니다.

5. 배포 확인

마지막으로, Kubernetes 클러스터에서 배포가 정상적으로 이루어졌는지 확인합니다.

kubectl get pods -n argodeploytest

위 명령어를 실행하면 배포된 애플리케이션의 파드(Pod)가 정상적으로 실행되고 있는지 확인할 수 있습니다.

결론

이번 프로젝트를 통해 Kubernetes 환경에서 DevOps를 적용하는 과정을 실습할 수 있었습니다. 특히, Docker 없이 Kaniko를 활용한 이미지 빌드, Private Registry를 통한 이미지 관리, ArgoCD를 이용한 배포 자동화 과정을 경험하면서 CI/CD 파이프라인 구축에 대한 깊은 이해를 얻을 수 있었습니다.

---

향후 개선점

• GitOps 방식을 더욱 강화하여 배포 안정성을 높이는 방안 검토
• Prometheus 및 Grafana를 활용한 모니터링 시스템 추가
• Jenkinsfile의 최적화 및 빌드 속도 개선

감사합니다.