AKS usecase : DevOps gitlab CI + ArgoCD

broccoli 24.01.15

3,726 8 2

facebook twitter kakao link

8 2

facebook twitter kakao link

DEVOTEE 요약: AKS 환경을 도입하여 개발자들의 서비스 배포에 드는 노력을 줄였다. CI/CD 파이프라인을 구축하고, GitLab에 소스 저장소 생성부터 ACR로의 이미지 업로드, ArgoCD를 통한 자동 배포까지의 과정을 설정하였다. 이로써 개발자는 서비스 배포에 필요한 과정을 거치지 않고, 코드 작업에만 전념할 수 있게 되었다.

DEVOTEE 추천 블로그

AKS 환경에서 DevOps 사례를 만들어 보자

AKS 를 도입하고 나서 보니 개발자들의 서비스 배포에 드는 수고가 절반은 줄어든 것으로 보인다.

기존 Azure VM 기반에서는 오토스케일링을 위해 VM 이미지 기반 배포가 요구되기 때문에 이미지 업데이트와 배포 과정에서 많은 시간이 소요되었다.

개발자 입장에서는 중요하지 않은 업무로 효율성이 떨어졌다.

AKS 도입 후 CI/CD 파이프라인을 구축하여 개발자의 수고를 줄일 수 있었다.

최근 별도의 개발 프로젝트 진행을 위해 인프라 제공이 필요했는데, AKS가 있어 어려움 없이 2일 만에 제공할 수 있었다.

CI/CD 관점으로 GitLab에 소스 저장소 생성부터 ACR로의 이미지 업로드, ArgoCD를 통한 자동 배포까지의 과정을 정리하였다

CI환경은 Gitlab CI로 구성을 할 수 있다

repo는 source-repo와 manifest-repo로 분리하여 구성한다. 2개의 repo를 그룹으로 관리할 수 있도록 gitlab의 subgroup 기능을 이용한다.

1. 개발용 그룹 생성과 repo 생성

2. 샘플 소스 작성

동작을 하기 위해 간단한 spring boot 샘플 소스를 작성한다. 간단한 웹 페이지가 보이도록 src/main/resources/static/index.html에 작성한다.

3. gitlab-runner 생성

1) gitlab-runner에 대한 이해 부터

처음에는 gitlab에 있는 runner가 CI/CD 처리를 해 주는 줄 알았다.

shared runner(공유 러너) 환경이라면 틀린 말도 아니지만 현재 우리 회사는 아래 그림처럼 shared runner를 구축하지 않았다.

그래서 프로젝트 담당자가 gitlab-runner를 구축해야 한다.

우선 gitlab에서 정의하는 runner와 실제 CI/CD 수행을 하는 gitlab-runner를 구분해서 이해하고 있어야 한다.

정의 : gitlab-runner는 gitlab의 CI/CD 파이프라인을 구동하기 위한 agent로, 코드 변경에 따른 자동화된 테스트, 빌드, 배포 등을 수행하는 도구
필요성 : gitlab에 호스팅된 프로젝트의 continuous integration/delivery를 위해 필요, 코드 변경 시 자동으로 테스트, 빌드, 배포 등을 수행할 수 있음

2) gitlab에 있는 runner 설정

repo 단위로 runner를 설정할 수도 있지만, group내에 다수 repo가 존재할 상황이라 group runner를 등록하기로 했다.

group의 Build 메뉴를 펼쳐서 'Runners' 를 클릭하면 'New group runner'를 생성할 수 있는 기능이 제공된다.

아래와 같이 tag를 입력하고 Create runner를 클릭하면 바로 생성이 된다.

Runner created. 라는 알림이 뜨고, 하단의 Go to runners page 를 클릭하면 등록된 runner를 볼 수 있다.

좀 전까지도 없었던 gorup runner가 등록된 걸 볼 수 있다. 현재 상태는 Online에 Never connected 이다. 아직 연결된 것 없다.

아직 연결 전이므로 연결이 필요하다. 실제 역할을 수행할 컴퓨팅 자원이 필요하다.

우리 프로젝트는 aks를 사용하므로 azure kubernetes에 gitlab-runner용 pod를 생성하기로 했다.

3) aks에 gitlab-runner 리소스 생성

gitlab-runner를 k8s에 생성하기 위해서는 helm 툴을 사용한다.
helm 툴로 리소스를 설치하기 위해서는 chart와 values.yaml 이 필요하다.
chart를 온라인 상으로 조회할 수 있도록 chart repo를 아래와 같이 추가한다.

helm repo add gitlab https://charts.gitlab.io

values.yaml을 작성해야 한다. values.yaml에서 핵심이자 변경이 필요한 값은 gitlabUrl 과 runnerRegistrationToken 이다.(보안성을 위해 마스킹 처리)

affinity: {}
checkInterval: 30
concurrent: 10
configMaps: {}
gitlabUrl: https://ㅇㅇㅇ    / # runner registration url
hostAliases: []
image:
  image: gitlab-org/gitlab-runner
  registry: registry.gitlab.com
imagePullPolicy: IfNotPresent
metrics:
  enabled: false
  port: 9252
  portName: metrics
  serviceMonitor:
    enabled: false
nodeSelector: {}
podAnnotations: {}
podLabels: {}
podSecurityContext:
  fsGroup: 65533
  runAsUser: 100
priorityClassName: ""
rbac:
  clusterWideAccess: false
  create: true
  podSecurityPolicy:
    enabled: false
    resourceNames:
      - gitlab-runner
  rules:
    - resources:
        - configmaps
        - pods
        - pods/attach
        - secrets
        - services
      verbs:
        - get
        - list
        - watch
        - create
        - patch
        - update
        - delete
    - apiGroups:
        - ""
      resources:
        - pods/exec
      verbs:
        - create
        - patch
        - delete
resources: {}
runnerRegistrationToken: GR13489ㅇㅇㅇ # runner registration token(마스킹 처리)
runners:
  builds: {}
  cache: {}
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:16.04"
  helpers: {}
  namespace: gitlab-runner
  services: {}
secrets: []
securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
  privileged: false
  readOnlyRootFilesystem: false
  runAsNonRoot: true
service:
  enabled: false
  type: ClusterIP
sessionServer:
  enabled: false
terminationGracePeriodSeconds: 3600
tolerations: []
volumeMounts: []
volumes: []

runner registration token 은 아래 그림처럼 복사해 올 수 있다.

작성이 되었으면 helm install 명령을 aks에 배포하면 된다.

기본형) helm install gitlab-runner -f values.yaml gitlab/gitlab-runner

예시) helm install --namespace gitlab-runner-exstudio gitlab-runner-exstudio -f gitlab-runner-exstudio.yaml gitlab/gitlab-runner

helm 으로 설치 결과를 아래와 같이 k9s로 확인해 보면 별도 프로젝트 그룹을 위한 gitlab-runner를 위한 pod생성을 확인할 수 있다.

gitlab에 가서 확인해 봐야 한다. 아래와 같이 연결이 확인 된다. 이제 gitlab에서 aks에 생성한 gitlab-runner로 CI/CD를 요청할 수 있다. (현재 개발 프로젝트에서는 gitlab은 CI만 사용)

4. CI 파일 작성

이제 파이프라인 수행에 대한 정의를 기록하는 CI 파일을 작성해야 한다.

파일명은 .gitlab-ci.yml 이며, 프로젝트 루트에 두면 된다.

핵심 내용은 빌드를 수행하는 명령어인 mvn package jib:build 이다.

참고로 jib는 구글에서 개발한 라이브러리로 spring boot 소스를 컨테이너 이미지로 생성해서 저장소까지 push를 원스톱으로 해주어서 자동화에 매우 유용하다.

stages:  
  - build

variables:

build-job:
  stage: build
  image: maven:3.8.6-openjdk-8
  before_script:
    - apt-get update && apt-get install -y curl jq
  script:
    - ACR_SERVER="ㅇㅇㅇ.azurecr.io";
      ACR_USERNAME="token-acrㅇㅇㅇ-push";
      ACR_PASSWORD="BtaWOVRbjAKJㅇㅇㅇ";
    - mvn package jib:build -Dimage.tag=$CI_COMMIT_SHORT_SHA -Dacr.server=$ACR_SERVER -Dacr.username=$ACR_USERNAME -Dacr.password=$ACR_PASSWORD
  only:
    - develop
    - /^release-.*$/
    - main
  except:
    - tags
  # when: manual  # default는 always임 
  allow_failure: false

5. pom.xml

jib 빌드와 acr정의를 위해 properties, plugins, mainClass를 추가한다.(보안성을 위해 일부 내용 마스킹 처리)

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
 
    <modelVersion>4.0.0</modelVersion>
 
    ...
 
    <properties>
        <java.version>1.8</java.version>
        <image.tag>local</image.tag>
        <acr.server>acraopdev.azurecr.io</acr.server>
        <acr.username>token-acrㅇㅇㅇ-push</acr.username>
        <acr.password>BtaWOVRbjAKJYgㅇㅇㅇ</acr.password>
    </properties>
 
    <dependencies>
        ...
    </dependencies>
 
    <build>
        <finalName>${project.artifactId}</finalName>
        <plugins>
            ...
 
            <plugin>
                <groupId>com.google.cloud.tools</groupId>
                <artifactId>jib-maven-plugin</artifactId>
                <version>3.3.2</version>
                <configuration>
                    <from>
                        <image>openjdk:8-jdk-alpine</image>
                    </from>
                    <to>
                        <image>${acr.server}/${project.artifactId}</image>
                        <tags>
                            <tag>${project.version}-${image.tag}</tag>
                        </tags>
                        <auth>
                            <username>${acr.username}</username>
                            <password>${acr.password}</password>
                        </auth>
                    </to>
                    <container>
                        <creationTime>USE_CURRENT_TIMESTAMP</creationTime>
                        <mainClass>com.exstudio.springbootex.SpringbootExApplication</mainClass>
                    </container>
                </configuration>
            </plugin>
        </plugins>
    </build>
 
</project>

6. 파이프라인 확인

이제 빌드 동작을 확인할 수 있다. pom.xml을 push 하면 빌드를 자동으로 수행한다.

일정 시간이 소요되고 빌드 작업이 아래와 같이 성공하는 것을 확인할 수 있다.

정의한 버전이 ACR에 제대로 업로드 된 것을 볼 수 있다. Repositories 메뉴를 통해 springboot-ex 패키지의 버전이 0.0.1로 업로드 되어 있다.

7. 서비스 동작 확인

ACR에 업로드한 컨테이너 이미지를 수동으로 aks에 배포할 수 있다.

우선 aks에 배포하기 위한 manifest 파일을 작성해야 한다. Deployment와 Service를 한 파일에 작성한다.
- 핵심 항목 : 컨테이너 이미지와 tag(위의 구성으로 보면 springboot-ex/0.0.1), namespace(exstudio)
- 배포 명령어 : kubectl apply -f <yaml파일명>

apiVersion: apps/v1
kind: Deployment
metadata:
  name: d-deploy-exstudio
  namespace: exstudio 
spec:
  replicas: 1
  selector:
    matchLabels:
      app: d-exstudio
  template:
    metadata:
      labels:
        app: d-exstudio
    spec:
      containers:
      - name: d-exstudio
        image: acrㅇㅇㅇ.azurecr.io/springboot-ex:0.0.1
        ports:
        - containerPort: 8080

---

apiVersion: v1  
kind: Service
metadata:
  name: d-svc-exstudio
  namespace: exstudio
spec:
  selector: 
    app: d-exstudio
  ports:
    - port: 80
      targetPort: 8080

할당한 도메인명으로 접속을 시도하니 접속을 성공한다.
- 사전에 도메인도 할당하고, ingress 설정도 아래와 같이 미리 해 두었었다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: d-ingress-exstudio
  namespace: exstudio
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/proxy-body-size: "1024m"
spec:
  ingressClassName: nginx
  rules:
  - host: exstudio.ㅇㅇㅇ.ㅇㅇㅇ  # 일부 마스킹 처리
    http: 
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: d-svc-exstudio  # aks에 생성하는 service 엔드포인드 이름과 동일해야 한다. 
            port:
              number: 80