최종 프로젝트 인프라 구축⑬ - 서비스 EKS 적용과 HTTPS ALB 연결

지난시간에 이어서

지난 시간에는 EKS 내 ArgoCD를 만들고, Argo 콘솔에 접근하기 위한 ALB 엔드포인트를 생성했었다.

이번에는 ArgoCD를 사용해 백엔드 서비스들을 EKS에 올리고, HTTPS가 적용된 ALB 엔드포인트를 만들어 볼 것이다.

ArgoCD로 백엔드 서비스 배포

일단 ArgoCD와 배포yaml이 담긴 깃허브 레포를 연결해 줘야 하니, 아르고 콘솔의 Settings→Repositories 탭에서 Connect Repo 버튼을 누르고, 위 사진처럼 등록해 주자.

참고로 누차 강조했지만 Password는 깃허브 비밀번호가 아닌 개인 토큰 값이다!

이렇게 Successful이 나오면 정상~ 안되면 보안 그룹 등 네트워크 연결을 체크해 보세요

서비스 배포도 귀찮으니 그냥 콘솔에서 진행해 버리자. Applications 탭→New App을 클릭하고, Edit As yaml 버턴을 눌러서

예전에 로컬에서 했었던 yaml파일을 그대로 붙여넣으면 되는데…

Prod CI 환경 구성 때 배포 레포에 서비스별로 values-prod.yaml 운영환경 변수를 추가했으니 valueFiles를 바꿔줘야 한다.

아무튼 이렇게 서비스별로 배포해서 모든 서비스를 올리면 된다.

막간-배포용 레포지토리 공유

여기서 공유합니다.

테라폼과 마찬가지로 민감 정보(aws 키, db 접속주소 등) 검열된 레포지토리입니다.

각 서비스별로 configmap, secret, service, deployment1가 구성되어 있고, values-dev 및 values-prod 파일로 관리합니다.

실제 서비스에 적용하기 보다는, ‘이렇게 구성하면 되구나~’라는 식으로 참고만 해 주세요 ^^

HTTPS ALB 엔드포인트 만들기

개발환경 때처럼 api gateway가 요청을 받아 각 서비스들로 전달해주는데,
ArgoCD 때와 마찬가지로 api gateway 서비스를 노드포트로 여는 게 아닌 잉그레스로 ALB를 만들어 줘야 한다.

이건 아르고CD와 달리 핵심(?) 서비스이므로, HTTPS를 적용해야 한다.

사실은 CloudFront로 올린 웹 클라이언트가 HTTPS 기반이라, api 호출을 HTTP로 하면 안 되기 때문인데…

막간 2-S3와 CloudFront로 프론트 배포

Amazon CloudFront를 사용하면 손쉽게 웹 서버를 배포할 수 있다. 방법은

우선 S3 버켓을 생성합니다.

버켓 설정에서 정적 웹 호스팅 활성화를 해 줍니다.

프론트 파일을 npm build하고, build 폴더 안의 내용물을 버켓에 넣어 줍니다.

CloudFront 콘솔에 들어가, 위 사진처럼 생성해 줍니다. 아까 만든 버켓을 선택하는 것이 중요!

만들어진 CloudFront의 배포 도메인로 접속해서 화면이 나오면 성공!

아무튼 다시 HTTPS로 넘어가

HTTPS를 만들려면 도메인과 인증서가 필요하다.

인증서는 Amazon Certificate Manager(ACM)에서 간편하게 만들 수 있다.

ACM 콘솔에 들어가 인증서 요청을 클릭하고

1단계 인증서 유형에 퍼블릭 인증서 요청을 선택한 다음

2단계 도메인 설정에 도메인을 입력해줘야 한다…

당직(当職)은 여기서 공짜 도메인을 만들 수 있었다.

나머지 설정은 다 그대로 두고…

인증서가 만들어지면 나오는 CNAME 이름과 CNAME 값을 도메인의 CNAME 항목에 넣어줘야 한다.

여기서 주의할 점으로, 위 싸이트에서 넣을 때 CNAME 이름은 도메인 주소를 제외한 값을, CNAME 값은 맨 뒤의 점(.)을 빼고 넣어줘야 한다.

이렇게 넣고 조금 기다리다 보면 인증서 상태가 발급됨으로 나와야 성공이다.

이제 이 인증서의 ARN 주소를 복사해서 ALB설정에 집어넣어야 한다.

HTTPS가 적용된 ALB 생성

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-gateway-ingress
  namespace: default
  annotations:
    alb.ingress.kubernetes.io/healthcheck-path: (헬스체크 엔드포인트)
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
    alb.ingress.kubernetes.io/certificate-arn: (ARN 주소)
    
spec:
  ingressClassName: alb
  rules:
    - host: (도메인 이름)
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: (연결할 서비스 이름)
                port:
                  number: (연결할 서비스의 포트)
  tls:
    - hosts:
        - (도메인 이름)
      secretName: dummy-tls-secret

저번 시간의 ArgoCD와 비슷하게 잉그레스 yaml을 만들되, 도메인이 적용되었기 때문에 host 값이 추가되었고,

annotations 항목에서 alb.ingress.kubernetes.io/certificate-arn을 추가하고, 이 값을 아까 복사한 ARN 주소로 넣어줘야 한다.

alb.ingress.kubernetes.io/actions.ssl-redirect와 alb.ingress.kubernetes.io/listen-ports도 마찬가지로 HTTPS 포트(443)을 추가해 주고

이 파일을 kubectl apply 하면…

생성된 LB의 리스너에 HTTPS가 있고, 헬스체크가 정상이면 끝이다!
참고로 위 yaml에서는 헬스체크를 위해 HTTP 접속도 설정했는데, 각자의 사정에 따라 없애줘도 무방하다.

마지막 작업이다. 마찬가지로 kubectl ingress를 하면 LB의 엔드포인트가 나오는데, 이놈을 도메인과 최종적으로 연결해주기 위해

도메인 설정의 CNAME 항목에 값만 추가해줘야 한다.

이러고 프론트의 api 호출 엔드포인트를 이 도메인으로 바꿔 주면 완벽한 HTTPS 기반 웹서비스가 완성된다!!

프로젝트를 마치며

이 편을 끝으로 장장 2달에 거친 인프라 구성이 완료되었다.

프로젝트를 회고해 보면서, 엉성하게 만든 부분도 있고 공을 들여 만든 부분도 있고 했지만

kubeadm을 통한 쿠버 클러스터 구축, Jenkinsfile 제작법, Terraform IaC와 같이 현업 때는 써보기만 했던 기술들을 직접 만들 수 있었고

무엇보다 그 때 ‘클라우드 설계를 한 사람이 했다’라는 풍문에서 결심한 ‘혼자 시스템 설계를 할 수 있는 사람’을, 이런 프로젝트에서나마 이루었다는 점이 대단했다!

사실 이 시리즈를 쓴 것도 시간이 많이 갔지만, 이렇게라도 안 하면 또 잊어버릴 것 같아 최대한 자세하게 작성했다.

미래의 당직이 이 시리즈를 보고 부디 초심을 되찾았으면 하길 바란다…