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

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

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

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

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

 

이전 시간에는 EKS 환경에 Nginx-ingress-controller, cert-manager 및 route53으로 도메인 생성을 진행했다. (+ IAM role 설정 등)

이번 시간에는 프로젝트에 필요한 서비스들을 배포해보자.

 

Mysql

운영 환경에서 사용할 디비부터 배포해보자.

 

배포 전  고민

그전에 디비를 eks 환경에서 실행해야하는지 충분히 고민해보고 사용하도록 하자.

따로 인스턴스에 설치해서 관리해도 되고, AWS db service 사용할 수 있고, 등등 여러 경우의 수가 있으니 주어진 환경에 맞게 사용하자.

 

필자는 크게 다른 환경으로 분리할 필요성을 느끼지 못해 같은 네임스페이스 환경으로 구축하게 되었다.
분리해야할 이유가 생기면 그때 dump 떠서 백업할 예정이다. eks 리전을 변경하면서 작업해보았는데 잘 되었었다.

 

aws ebs 프로비저너 설치

대부분의 서비스들은 스토리지를 필요로 합니다.

values.yaml 에서 필요한 스토리지 크기를 지정할 수 있습니다.

지정된 크기로 스토리지 볼륨을 생성해야하는데 aws-ebs 를 설치하면 이를 관리할 수 있습니다.

 

kubernetes.io/aws-ebs는 AWS 환경에서 Kubernetes를 사용할 때 EBS 볼륨을 프로비저닝하기 위해 사용되는 내장된 스토리지 클래스 프로비저너(provisioner)입니다. 이를 통해 AWS의 Elastic Block Store(EBS) 볼륨을 동적으로 프로비저닝하고 관리할 수 있습니다.

 

aws console > eks 에 접근해서 '추가 기능' 에서 위 aws-ebs를 추가할 수 있습니다.

추가하고 나면 kube-system namespace에 ebs 관련 pod가 생겨난 것을 확인할 수 있습니다.

values.yaml

서비스 배포 설명은 helm values.yaml 파일을 기준으로 설명하려고 합니다.

global.storageClass 설정 값을 확인해야합니다.

aws 에서는 아래와 같이 storageClass 가 gp2로 정해집니다.

k9s에서 ':storageClass' 보시면 생성되어 있습니다.

위 aws-ebs 설정하였기 때문에 생겨난 storageClass 입니다.

 

storageClass가 없다면 동적으로 프로비저닝을 할 수 없기때문에 pv가 생성되지 않습니다.

그러면 pv를 필요로 하는 서비스들이 실행되지 않을 겁니다.

많이 만나보게 될 에러입니다. 만약 pod가 제대로 실행되지 않으면 k9s에서 d(description)를 명령어 입력해서 events를 확인해보며 이슈를 해결하시길 바랍니다.

global:
	storageClass: gp2

 

위 설정 이외에 따로 수정해야할 설정 포인트는 없습니다.

다만, 외부에서 접근을 원하시면 service type을 변경하든 ingress 설정하든 다른 설정이 필요할 것입니다.

필자는 외부에서 따로 접근할 필요가 없고 내부에서만 통신할 것 이기 때문에 추가 설정 없이 마무리했습니다.

 

Vault

key 관리할 vault를 배포해보자

values.yaml

vault도 마찬가지로 storageClass: gp2 인지 체크해줍니다.

그리고 대망의 ingress 설정을 해줍니다.

enabled: true 설정해주시고 cert-manager 때 등록한 clusterIssuer를 설정해줍니다.

host에는 route53으로 생성한 도메인 설정 해줍니다.

마지막으로 tls에 secret name을 설정하는 건데 이건 본인 마음대로 규칙 정해서 설정해주세요. 해당 이름으로 tls secret이 생성됩니다.

ingress:
  enabled: true
  labels: {}
  annotations:
    cert-manager.io/cluster-issuer: {이전에 등록한 cluster-Issuer name}
  ingressClassName: nginx
  pathType: Prefix
  activeService: true
  hosts:
    - host: vault.example.link
      paths: []
  extraPaths: []
  tls:
    - secretName: example-vault-cert
      hosts:
        - vault.example.link

 

위 설정대로 실행하면 (k9s) order -> challenge -> certificate 순으로 잘 생성되고 인증서 발급 신청되었는지 확인해주세요.

문제없이 잘 생성되면 challenge는 알아서 종료되고 인증서 발급될 것 입니다.

문제가 생기면(필자는 권한 이슈가 많았었다.) challenge 쪽에서 어떤 이슈때문에 막히는지 알려줄 겁니다.

 

생각보다 길어져서 CI/CD 관련 서비스들은 다음 글에서 작성하도록 하겠습니다.

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