[kubernates, CI/CD] 쿠버네티스 환경에서 CI/CD 구축하기-1

지난달부터 현장실습을 나왔는데, 약 한달간 쿠버네티스 공부를 하고

이번주부터 CI/CD 시스템을 구축하는 미션을 받았습니다.

 

일단 CI(지속적 통합)/CD(지속적 배포)가 무엇이냐

 

예전엔 어떤 팀이 프로그램을 개발하고 이를 실제로 배포하여 서비스를 하는 과정에서

개발자에게 많은 일이 과중되었습니다.

 

개발자가 개발을 하고 여러 개발자들이 만든 코드를 통합하고,

통합된 코드를 테스트 하고, 이를 배포하기까지 

 

정말 많은 과정을 개발자가 관여해야 했습니다.

 

그래서 이 과정을 줄일 수 있는 다양한 도구들이 나왔습니다.

대표적으로 git, jenkins, argocd...

 

그 모든 통합과 배포 도구를 이어서 자동화하는 것이 CI/CD의 실현이라고 할 수 있습니다.

 

그래서 이 CI/CD를 구축하는 것은 좋지만 어떤 도구를 이용할 것인가? 가 중요합니다.

 

멘토님이 내신 과제의 구조입니다.

1-1. gitea를 통해 코드를 수정

1-2. gitea 코드 변경을 통해 날아간 웹훅을 받은 jenkins가 해당 코드로 이미지 빌드

1-3. harbor로 push된 이미지를 argocd에 업데이트

 

2-1. 서비스를 헬름을 통해 배포

2-2. argocd가 헬름을 자동 동기화

2-3. helm차트가 수정되면 argocd가 자동으로 동기화

 

정리하면 위 과정이 되겠습니다.

 

그래서 이 시스템을 쿠버네티스상에서 구축하는게 목표입니다.

 

현재 이 과제를 사용하는 쓰는 쿠버네티스는 다음과 같습니다.

아쉽게도 환경이 그리 크지 않아서

마스터 노드 하나와 워커 노드 하나를 사용합니다.

 

이전에 위 환경을 구축하기 위해서 동적프로비저닝을 구성해야 했는데,

보시다시피 워커노드가 하나라서 기존의 노드 하나가 담당하게하는 방법이 아니라

노드내에 파드를 하나 생성해 해당 파드가 스토리지를 담당하고 파드에 PVC를 걸어 볼륨을 받는 형식입니다.

 

이 부분에 대해 별도로 글을 하나 작성할 예정입니다.

 

또한 해당 마스터 노드에 직접 접근하는 것이 아니고,

위 환경이 Openstack 에 꾸려져 있다보니, Openvpn을 통해 연결하고

로컬 환경에서 kubectl등을 통해 원격으로 작업할 계획입니다.

 

P.S.

통상적으로 마스터노드에 직접 접속하게 만드는 기업은 없습니다.

보안적으로 문제가 될 수 있기 때문에 마스터 노드의 루트 밑 .kube 디렉토리에서 

config 파일의 내용을 복사하여 로컬에서 kubectl을 통해 작업합니다.

 

P.S.2

 

일단 제 환경은 Windows로 Powershell, cmd 등을 통해 작업할 예정입니다.

로컬에 설치할 프로그램은

1. kubernates-cli >> 이게 kubectl

2. helm >> 헬름 설치 도구입니다.

3. k9s >> 쿠버네티스 환경에서 작업을 GUI느낌으로 편하게 만들어줍니다.

4. kubens >> 기본 네임스페이스를 원하는 곳으로 고정시킬 수 있어 명령어 입력량을 줄일 수 있습니다.

 

 

Jenkins helm 을 사용하기 위해 
https://artifacthub.io/

Artifact Hub

위 사이트에서 원하는 차트를 검색합니다.

일단 제가 필요한건 이 것입니다. 클릭해줍시다.

그럼 아주 친절하게 어떻게 설치하는지 알려주는 설명서가 있습니다.

 

순서대로 설치해보면,

가이드가 나옵니다.

 저 가이드는 리눅스 기준 가이드이므로 윈도우 환경의 경우
kubectl exec --namespace blog -it svc/jenkins-blog -c jenkins -- /bin/cat /run/secrets/additional/chart-admin-password
라고 입력해야합니다.

 

그럼 비밀번호가 나오고, 상단의 포트 포워드를 통해 접속하면 되지만,

이미 구성된 ingress 컨트롤러가 있으므로 바로 ingress 리소스를 구성해서 url로 접속해보겠습니다.

 

추가로 구성전에 https 접속을 활성화하기 위해 ssl 인증서와 키를 만들어보겠습니다.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=jenkins.okestro.lsw.io/O=jenkins"

위 인증서와 키를 k8s 시크릿으로 생성합니다.

kubectl create secret tls jenkins-tls --cert=tls.crt --key=tls.key -n <jenkins-namespace>

 

이제 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: jenkins-ingress
  namespace: jenkins-namespace
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: jenkins.okestro.lsw.io
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: jenkins
            port:
              number: 8080
  tls:
  - hosts:
    - jenkins.okestro.lsw.io
    secretName: jenkins-tls

ingress 생성을 해주고,

윈도우 기준 C:/Windows/System32/drivers/etc/hosts 파일을 관리자 권한 메모장으로 열고,

<IP> jenkins.okestro.lsw.io ...

이렇게 작성하면 연결됩니다.

 

이제 jenkins에서 로드밸런서를 통한 접속이 가능하게(이미 MetalLB를 구성해둔 상태입니다.)

values.yaml 파일을 만들어서 헬름을 업그레이드해줍니다.

controller:
  serviceType: LoadBalancer
  service:
    loadBalancerIP: 10.0.27.240  

ingress:
  enabled: true
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/proxy-read-timeout: "90"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "90"
  ingressClassName: nginx
  paths:
    - path: /
      pathType: Prefix
      backend:
        service:
          name: jenkins
          port:
            number: 8080
  hostName: jenkins.okestro.lsw.io
  tls:
    - secretName: jenkins-tls
      hosts:
        - jenkins.okestro.lsw.io

rbac:
  create: true

serviceAccount:
  create: true

helm upgrade jenkins-lsw jenkins/jenkins -f values.yaml -n lsw

 

이렇게 하면 jenkins에 접근가능해집니다.

젠킨스 메인화면

 

 

이제 argocd를 구성해봅시다.

비슷한 방법으로 argocd를 artifacthub에서 찾아서 설치합니다.

 

여기서 proxy를 통해 접속하는 경우 문제가 생길 수 있습니다.

일단 argocd 통신의 특징을 알아야 합니다.

argocd는 80포트로 들어온 HTTP 통신에 대해 다시 443으로 재요청을 보내 통신합니다.

 

근데 지금 사용하는 proxy를 이용하게 되면

1. 클라이언트가 80포트로 요청

2. proxy가 url에 맞춰 argocd에게 80포트로 전송

3. argocd가 요청을 받아 443포트로 재요청

4. proxy가 클라이언트에게 443포트로 요청

5. 클라이언트가 443포트로 응답

6. proxy가 url로 인해 80포트로 전송

 

이 과정에 따라 3~6이 무한으로 반복되어 argocd에 접속되지 않는 경우가 있습니다.

그래서 helm chart의 values.yaml을 수정할 필요가 있습니다.

server:
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: nginx
      nginx.ingress.kubernetes.io/ssl-redirect: "false"
    hosts:
      - argocd.okestro.lsw.io
    paths: 
      - /
    tls: []  # 이 부분을 비워둡니다.
  config:
    params:
      server.insecure: "true"

또한 argocd의 ingress를 만들어줍니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argo-lsw-argocd-ingress
  namespace: lsw
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: argocd.okestro.lsw.io
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: argo-lsw-argocd-server
            port:
              number: 80

 

helm upgrade argo-lsw argo-cd -f values.yaml -n lsw

업그레이드를 하면 

성공적으로 접속이 완료되었습니다.

 

다음 포스팅은 실제 파이프라인을 구성해 본격적으로 CI/CD를 구축해보겠습니다.