예제 애플리케이션 배포

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ecsdemo-nodejs
  labels:
    app: ecsdemo-nodejs
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ecsdemo-nodejs
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: ecsdemo-nodejs
    spec:
      containers:
      - image: brentley/ecsdemo-nodejs:latest
        imagePullPolicy: Always
        name: ecsdemo-nodejs
        ports:
        - containerPort: 3000
          protocol: TCP

위에 예제 파일에는 서비스(service)와 app이 어떻게 배포되는지가 기술되어 있습니다. 이 내용을 kubectl을 이용하여 쿠버네티스 API에 쓰면, 쿠버네티스는 응용 프로그램이 배포될 때에 우리의 설정에 충족시킬 것입니다.

컨테이너는 3000번 포트로 수신 대기하고, 네이티브 서비스 디스커버리는 운영중인 컨테이너를 찾고 해당 컨테이너와 통신하는데 사용합니다.

1. NODEJS 백엔드 API 배포하기

NodeJS 백엔드 API를 올려 봅시다!

다음의 명령어를 귀하의 클라우드9 워크스페이스에 복사/붙여넣기 합니다.

cd ~/environment/ecsdemo-nodejs
kubectl apply -f kubernetes/deployment.yaml
kubectl apply -f kubernetes/service.yaml

디폴로이먼트 상황을 확인하여 배포 진행 과정을 지켜 볼 수 있습니다.

kubectl get deployment ecsdemo-nodejs

2. 크리스탈 백엔드 API 배포하기

크리스탈 백엔드 API를 올려 봅시다!

다음의 명령어를 귀하의 클라우드9 워크스페이스에 복사/붙여넣기 합니다.

cd ~/environment/ecsdemo-crystal
kubectl apply -f kubernetes/deployment.yaml
kubectl apply -f kubernetes/service.yaml

디폴로이먼트 상황을 확인하여 배포 진행 과정을 지켜 볼 수 있습니다.

kubectl get deployment ecsdemo-crystal

3. 서비스(Service) 종류 확인

프론트엔드 서비스를 올리기 전에 우리가 사용할 서비스(service) 종류를 살펴봅니다. kubernetes/service.yaml은 프론트엔드 서비스를 위한 설정입니다.

apiVersion: v1
kind: Service
metadata:
  name: ecsdemo-frontend
spec:
  selector:
    app: ecsdemo-frontend
  type: LoadBalancer
  ports:
   -  protocol: TCP
      port: 80
      targetPort: 3000

type: LoadBalancer을 주목하십시오. 이는 ELB를 설정하여 서비스로 들어오는 트래픽을 처리하게 합니다.

백엔드 서비스를 위한 kubernetes/service.yaml과 비교합니다.

apiVersion: v1
kind: Service
metadata:
  name: ecsdemo-nodejs
spec:
  selector:
    app: ecsdemo-nodejs
  ports:
   -  protocol: TCP
      port: 80
      targetPort: 3000

프론트엔드와는 달리 특정 서비스 종류를 설정하지 않았습니다. 쿠버네티스 공식 문서에 따르면 기본 서비스 종류는 ClusterIP 입니다. 이는 클러스터 내부 IP를 서비스로 노출하며 이 값을 선택하면 클러스터 내부에서만 해당 서비스에 접근할 수 있습니다.

4. ELB 서비스 롤(Role) 확인

이전에 로드 밸런서를 생성하지 않은 AWS 계정인 경우, ELB의 서비스(service) 롤(role)이 아직 존재하지 않을 수 있습니다.

롤을 확인하고 누락된 경우에는 만듭니다.

다음의 명령어를 Cloud9 워크스페이스에 복사/붙여넣기 합니다.

aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing" || aws iam create-service-linked-role --aws-service-name "elasticloadbalancing.amazonaws.com"

Role이 생성된 것을 확인합니다.

5. 프론트엔드 서비스 배포하기

루비 프론트엔드를 올려 봅시다!

다음의 명령어를 귀하의 Cloud9 워크스페이스에 복사/붙여넣기 합니다.

cd ~/environment/ecsdemo-frontend
kubectl apply -f kubernetes/deployment.yaml
kubectl apply -f kubernetes/service.yaml

디폴로이먼트 상황을 확인하여 배포 진행 과정을 지켜 볼 수 있습니다.

kubectl get deployment ecsdemo-frontend

6. 서비스(Service) 주소 찾기

이제type : LoadBalancer로 실행중인 서비스(service)가 있으니, ELB의 주소를 확인해야 합니다. 이를 위해 kubectl로 get services 하면 됩니다.

kubectl get service ecsdemo-frontend

위 명령어 출력 ELB의 FQDN을 보여줄 만큼 필드가 길지 않은 경우, 아래 명령으로 출력 형식을 조정할 수 있습니다.

kubectl get service ecsdemo-frontend -o wide

이 데이터를 프로그램적으로 사용하기 원한다면, json 형식으로 출력할 수 있습니다. 다음은 json 출력을 사용하는 예제 입니다.

ELB=$(kubectl get service ecsdemo-frontend -o json | jq -r '.status.loadBalancer.ingress[].hostname')

curl -m3 -v $ELB

ELB가 준비되고 트래픽을 프론트엔드 파드로 전송하기까지는 몇십초가 걸립니다.

loadBalancer 호스트네임을 웹 브라우저에 카피/붙여넣기해서 애플리케이션이 실행중인지 확인합니다. 다음 페이지에서 서비스를 스케일 업할 때까지 이 탭을 그대로 열어둡니다.