EKS 구성을 완료했다면 드디어 ! 컨테이너를 배포해보자
배포한 어플리케이션의 전체 시스템 구성도는 다음과 같다.
✔️ Application 배포
Database 배포하기
만약 배포할 어플리케이션이 로컬 sqlite DB 대신 외부 RDBMS(maridDB, mysql 등) 리소스를 연동한 경우에는 쿠버네티스 위에 DB app을 배포해야한다.
배포를 위해 Deployment manifast 파일을 작성한다.
참고할 문서는 다음과 같다.
디플로이먼트에서 의도하는 상태(Desired State)를 설명하고, 디플로이먼트 컨트롤러(Controller)는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다.
* 레플리카셋은 간단하게 "지정한 pod 갯수만큼 항상 실행될 수 있도록 관리해주는 Controller"이다.
다시 말하면, 특정 Pod을 5개로 항상 유지하도록 하는 레플리카셋을 만든다면
Pod의 갯수를 모니터링 하다가, 임의의 이유로 인해 Pod가 삭제될 경우 자동으로 새로운 Pod 1개를 생성하여 5개를 유지해준다.
이를 통해, 명시된 Pod의 실행을 항상 안정적으로 유지하고, Pod의 가용성을 보증하는 역할을 한다.
✔️ Deployment Usecase
디플로이먼트의 일반적인 사용 방법은 다음과 같다.
- 레플리카셋을 롤아웃 할 디플로이먼트 생성. 레플리카셋은 백그라운드에서 파드를 생성한다. 롤아웃 상태를 체크해서 성공 여부를 확인한다.
- 디플로이먼트의 PodTemplateSpec을 업데이트해서 파드의 새로운 상태를 선언한다. 새 레플리카셋이 생성되면, 디플로이먼트는 파드를 기존 레플리카셋에서 새로운 레플리카셋으로 속도를 제어하며 이동하는 것을 관리한다. 각각의 새로운 레플리카셋은 디플로이먼트의 수정 버전에 따라 업데이트한다.
- 만약 디플로이먼트의 현재 상태가 안정적이지 않은 경우 디플로이먼트의 이전 버전으로 롤백한다. 각 롤백은 디플로이먼트의 수정 버전에 따라 업데이트한다.
- 더 많은 로드를 위해 디플로이먼트의 스케일 업.
- 디플로이먼트 롤아웃 일시 중지로 PodTemplateSpec에 여러 수정 사항을 적용하고, 재개하여 새로운 롤아웃을 시작한다.
- 롤아웃이 막혀있는지를 나타내는 디플로이먼트 상태를 이용.
- 더 이상 필요 없는 이전 레플리카셋 정리.
📌 Deployment 파일 배포
Deployment 파일을 구성하고 배포하는 방법은 1. EKS 구성하기 글에서 클러스터를 생성하는 방식과 유사하다.
내가 배포할 어플리케이션은 mysql을 사용하므로 DB app을 배포하기 위해 mysql-deployment.yaml 파일을 작성한다.
작성을 마쳤으면 아래 명령줄을 입력하여 deployment file을 배포한다.
kubectl apply -f mysql-deployment.yaml
Deployment의 정보를 확인하고 싶다면 다음 명령줄을 입력한다.
kubectl describe deployment mysql
다음과 같이 정보를 확인할 수 있다.
mysql이 정상적으로 Deploy되었다면 어플리케이션에서 mysql로 접속하기위해 Service를 Deployment에 매핑해야한다.
Deployment 파일 배포와 마찬가지로 Service 파일을 생성하고 Deployment에 매핑해준다.
kubectl apply -f mysql-service.yaml
배포가 정상적으로 완료되었다면 Pod 정보를 찾을 수 있다.
📌 APP 배포
모든 준비가 끝났다. 이제 쿠버네티스에 운용할 app을 배포해보자 APP 배포도 Deployment, service 배포 방식과 같다.
내가 배포할 Flask app을 위해 Deployment manifast 파일을 작성해준다.
kubectl apply -f flask-deployment.yaml
kubectl describe deployment cloud-flask
정상적으로 Flask app이 배포 되었다면 외부에서 flask app으로의 접속을 위해 service를 deployment에 매핑해준다.
kubectl apply -f flask-service.yaml
kubectl get pods -l app=cloud-flask
flask app의 경우는 Service 타입을 LB(LoadBalancer)로 외부 노출을 시켰으므로 LB Endpoint를 확인할 수 있다.
kubectl get svc cloud-flask-svc
마지막으로 해당 LB endpoint로 접근해 동작을 확인한다.
afed0a09c78cd466cb129d5999c09d99-461617357.ap-northeast-2.elb.amazonaws.com
✔️ Clean Up
실습 완료 후 비용 절약을 위해 실습한 EKS 리소스를 정리해준다.
eksctl delete cluster --region=ap-northeast-2 --name=[your eks cluster name]
정상적으로 삭제되었다.
'Public Cloud > AWS' 카테고리의 다른 글
[AWS] AWS CLI를 이용한 S3 버킷 다루기 (0) | 2022.03.29 |
---|---|
[AWS] AWS의 컨테이너 사용/배포 서비스 (0) | 2022.03.18 |
AWS EKS로 웹 앱을 배포해보자 ! - 1. EKS 구성하기 (0) | 2022.03.16 |
AWS EKS로 웹 앱을 배포해보자 ! - 0. 초기 설정 (0) | 2022.03.16 |
[AWS] AWS EKS란 ? (0) | 2022.03.15 |
영차영차 성장 블로그
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!