[AWS] EKS CI/CD부터 서비스 배포까지 - (4)

AWS 환경에서 CICD를 구축하는 미션을 맡게 되었다. 
목표는 AWS EKS, CI/CD, 배포할 서비스, 그리고 Helm을 사용해 전체 시스템을 구성하는 것이다. 

이번 CI/CD 구축에서는 GitLab, Argo CD, Nexus(docker registry), MySQL, Vault, Cert-Manager 등을 활용할 예정이다.

이 글에서는 세부적인 화면 캡처나 단계별 설명을 제공하지 않을 것이다. 그러나 시간이 지나면서 익숙해지다 보면 자연스럽게 이해할 수 있을 것이다. (참고로, 필자는 이 과정을 익히는 데 한 달이 걸렸다.)

이 과정에서 직면했던 여러 가지 이슈들을 공유하고 기록함으로써, 이 글이 누군가에게 도움이 되기를 바란다.

이전 시간에는 서비스에 필요한 DB와 vault를 배포해보았습니다.

이번 시간에는 CI/CD 서비스들을 배포해보자.

 

GitLab

gitlab은 코드 관리와 배포 파이프라인 기능을 제공해준다.

gitlab 배포 시 관련 서비스들을 여러개 추가로 배포해야한다. helm chart에서 모두 제공한다.

필자는 gitlab 관련 서비스로 gitlay, minio, postgresql, redis, registry, sidekiq, toolbox, webservice 가 실행되고 있습니다.

 

계속해서 반복되는 설정값들은 언급만 드리고 생략하도록 하겠습니다. (직접 설정값 변경해가며 helm upgrade 해보는 것이 실력 향상..)

- namespace 설정

- ingress 설정 (cert-manager 연동하여 인증서도 자동 발급)

- storageClass : gp2 -> 동적 프로비저닝

위 설정이 크게 중요한 부분이고 각 서비스들 enable 설정 확인하며 필요한 서비스들을 실행시킵니다.

 

배포하며 발생한 이슈에 대해 정리해보겠습니다.

pv 생성 안되는 이슈

이유로는 IAM 권한으로 ec2 권한이 없어서 pv를 생성하지 못할 수 있습니다. 노드 권한에 AmazonEC2FullAccess 를 추가합니다.

 

또 다른 이유로는 이전에 설치한 EBS CSI driver가 없어서 프로비저닝 기능을 제공하지 못해서 그렇습니다.

mysql 설정할때 설치 진행하여 문제없을 것입니다. ebs-csi 잘 설치하면 gp2라는 이름으로 storageClass가 생성되고 요녀석이 동적으로 프로비저닝 진행해주는 것으로 알고 있습니다.

 

마지막으로 기본 노드 인스턴스 사양이 낮으면 많은 서비스들을 실행하기 부족한 여건으로 실행되지 않을 수 있습니다.

각 서비스마다 resources에 필요한 cpu와 memory 값을 조절하거나 aws eks 노드 인스턴스를 t3.xlarge정도로 사용하면 됩니다.

 

GitLab-runner

gitlab 을 정상적으로 실행하면 배포 파이프라인을 실행시킬 gitlab-runner가 필요합니다.

gitlab-runner도 마찬가지로 helm chart가 있습니다.

values.yaml로 설정할 수 있었지만 필자는 helm chart에 직접 접근해서 실행시켜줬습니다.

이유는.. gitlab-runner가 뻑이 나면 gitlab-runner만 내리고 싶은데 gitlab까지 모두 내려야하는 불상사가 발생했습니다.

gitlab으로 통합해서 올린 다음 gitlab-runner만 update하고 싶어도 모두 영향이 갈수도 있고 되게 무겁다고 판단돼서 분리했습니다.

 

values.yaml에서 중요 수정 부분은 다음과 같습니다.

gitlabUrl: gitlab-webservice-default.{namespace}.svc.cluster.local:8080

runnerToken: {gitlab-project-runner 생성 후 받은 id값}

runners:
  config: |
    [[runners]]
      name = "Kubernetes Runner"
      executor = "kubernetes"
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:20.04"
        privileged = true
        [[runners.kubernetes.volumes.empty_dir]]
          name = "docker-certs"
          mount_path = "/certs/client"
          medium = "Memory"

gitlab으로 통신을 클러스터 내부에서 진행하기 때문에 k8s dns service 주소로 설정했습니다.

runnerToken은 gitlab > project > runner 생성 > runner id 발급됩니다. 발급된 id 입력하시면 됩니다.

이제 helm으로 실행시키면 runner가 생성되고 gitlab에서 runner가 생성되었다고 축하한다는 멘트가 나옵니다.

(축하 멘트가 보이면 감동 받게 됩니다..많은 삽질을 곁들인..)

 

runners config 설정은 runner가 배포를 진행할때 새로운 pod가 생성됩니다.

새로운 pod가 부모 pod의 docker를 사용할 수 있도록 docker-in-docker (dind) 할 수 있도록 설정이 필요합니다.

gitlab-ci.yaml 파일에도 관련 설정이 필요합니다. 아래 글 참고해서 잘 설정하길 바랍니다!

https://docs.gitlab.com/runner/executors/kubernetes/#using-docker-in-builds

default:
  image: docker:24.0.5
  services:
    - docker:24.0.5-dind
  before_script:
    - docker info
    
variables:
  DOCKER_HOST: tcp://docker:2376
  ...

 

gitlab-ci.yaml 까지 설명하진 않겠습니다! gpt와 구글링을 사용해서 잘 설정해봅시다.

gitlab-ci 대로 pipeline 만들고 커밋 또는 태그 푸시로 gitlab 배포를 진행합니다.

 

이렇게 gitlab과 gitlab-runner 배포를 성공적으로 마무리했습니다.

다음 시간에는 argo-cd와 argo-rollouts에 대해 포스팅해보겠습니다.

엇 nexus도 해야합니다.. ㅎ.ㅎ