(AWS기초)초보자를 위한 컨테이너 시작하기

컨테이너를 왜 사용하는가?

표준화 이전의 운송: 중구난방식, 공간 낭비, 관리 불편

컨테이너: 표준화된 스토리지 단위

 

컨테이너란? : 가상머신에서 운영체제가 빠진 것, 운영체제는 공유해서 쓰되 나머지 부분(격리된 환경의 구성, 설정(config), 코드, 종속성, 환경, 라이브러리, 런타임 엔진 등)을 하나의 패키지로 만든 다음 컨테이너들을 배포하는 것

 

컨테이너의 장점? : 하나의 이미지를 가지고 반복적으로 컨테이너를 만들 수 있음, 독립적인 환경 유지 가능, VM보다 더 빠른 가동/중단 속도(배포되는 데 대부분 2~3초면 실행 가능(이미지를 다운받았다는 전제 하에), 이미지 다운 속도 포함 10초 이내, 중단도 5초 이내), 이동성, 확장성

 

컨테이너가 각광받는 이유? : Micro Service Architecture

- 기존의 모놀리식 애플리케이션: 서로 연관되지 않은 여러 서비스를 하나의 애플리케이션에 통채로 담아 여러 서버에 배포했음, 특정 서비스에 장애가 생기면 전체 서비스가 장애가 생기게 됨, 일정 복잡도를 넘어가면 개발/운영 시에 굉장한 부담이 됨

- 마이크로서비스는 여러 서비스를 각각 나누고, 개발 및 유지보수 환경도 공유하지 않음, 환경과 기능을 쪼개어 종속성이 없도록 만듦

 

가상화 플랫폼인 Docker 

- 경량 컨테이너 가상화 플랫

- 컨테이너를 생성, 저장, 관리 및 실행할 수 있는 도구 제공

- 자동화된 구축, 테스트 및 배포 파이프라인과 쉽게 통합

- Docker 컨테이너를 사용하기 위해서는: Docker 이미지를 만들고, Docker file을 정의해야 함

1. 파이썬 3.7 알파인 리눅스 이미지를 다운받음

2. Working directory로 /app을 사용함

3. ADD는 현재 디렉토리에 있는 것들을 /app에 복사하겠다는 것

4. Run - pip install -r requirements.txt

5. 80번 포트를 오픈

6. CMD gunicon(파이썬의 wsgi라는 서버)를 설치해서 서버를 운영함

 

위 방법으로 이미지를 만들면 레지스트리에 업로드해서 사용하게 됨

레지스트리의 종류는 여러가지가 있지만, 여기서는 Amazon에서 제공하는 private한 레지스트리를 사용

 

Amazon ECR(Elastic Container Registry)

• 사용자/주제/메시지 등의 애플리케이션들을 컨테이너로(마이크로서비스 아키텍쳐로) 만드는 것
• 환경 공유 X, 서로 따로 이미지를 만들어 레지스트리에 저장

 

처음에는 하나의 컨테이너로 시작, 사용자가 늘어남에 따라 컨테이너가 늘어남

자동화를 위해 오케스트레이션 도구들을 사용해야 함

 

1. Amazon ECS(Elastic Container Service)
2. Amazon EKS(Elastic Kuberenetes Service)

- 실제 시장에서 가장 자주 씀, 실습에서 사용할 오케스트레이션 도구

 

Kubernetes 컨트롤 플레인과 데이터 플레인

- 이용자가 Kubernetes를 직접 설치하려면 온프레미스로 서버를 설치하거나, 직접 인스턴스를 만들어 직접 설치하는 경우, 직접 관리해야 함

- Kubernetes는 컨트롤플레인과 데이터플레인으로 이루어져 있음, 이 두개를 다 합쳐 Kubernetes 전체를 Cluster라고 함

 

 

컨트롤 플레인

- 컨트롤 플레인이 하는 일은 Kuberenetes 전체를 관리, 명령어는 컨트롤 플레인에 전달

- 명령어를 받아 저장하고, 컨테이너 배포에 대한 스케줄링, 컨테이너 유지를 위한 컨트롤러 확인 등을 함

- 대부분의 Cluster 내에서의 관리를 함

- 직접 설치의 경우 고가용성을 위해 일반적으로 테스트를 위해 3대에 설치하게 됨

- 안에 있는 데이터들을 백업, 복구해야 하는 등(노드라고 함) 관리해야 할 일이 많음

 

 

데이터 플레인

- 실제 컨테이너를 배포하는 곳은 데이터 플레인

 

EKS, ECS를 왜 사용하는가?

EKS를 사용하여 Kubernetes에 클러스터를 구축하게 될 경우 

1. 컨트롤 플레인은 관리하지 않아도 됨(완전 자동 관리)

2. 데이터 플레인의 경우 관리형 노드그룹으로 사용하게 되면 AWS가 오토스케일링 등으로 어느 정도는 자동화해주나, 완전 자동화는 아님, AWS는 인스턴스라고 부르고 Kubernetes는 노드라고 부르는 관리형 노드들은 직접 관리가 필요함

3. 데이터 플레인까지 자동화하여 좀 더 편하게 사용하기 위해서는 Fargate를 사용함

Fargate를 왜 사용하는가?

AWS Fargate: 완전 자동으로 관리해주는 데이터플레인, 서버리스, 모든 Kubernetes의 오브젝트들을 배포할 수 있는 것은 아니고, 제한사항이 몇 가지 있음, Fargate만으로는 실제 운영은 불가, 관리형 노드 그룹과 Fargate를 같이 사용함

- 컨테이너에 적합한 서버리스 컴퓨팅

- 빠르고 간편한 배포 가능

- 적정 크기로 자동으로 맞춰 배포

- 하나의 노드에 하나의 pod이 배포됨(pod == 컨테이너)

- 완전 관리형

- 자동 최적화

 

Kubernetes Object

1. Pod

- 쿠버네티스에서 생성하고 관리할 수 있는 배포가능한 가장 작은 컴퓨팅 단위(하나 이상의 컨테이너 그룹)

- 아래 사진은 선언형으로 명령어를 통해 배포(kubeCTL로 제어)

- ex) run first --image =ubuntu (ubuntu 이미지를 받아 first란 이름으로 pod을 만들어줌)

- 아래 코드 경우는 yaml(들여쓰기 문법), 대소문자를 가리기 때문에 Pod을 꼭 대문자로, 콜론 뒤에는 꼭 띄어쓰기!

apiVersion: 쿠버네티스에서 제공해주는 버전 그대로 씀

kind: Pod을 만들겠다는 것

metadata:

    name: pod-example - 팟의 이름

spec: - 컨테이너를 정의하는 부분

    containers:

    -    name: ubuntu - 컨테이너에는 반드시 이름이 필요함

         image: ubuntu:18.04

 

kubectl apply -f first.yaml 명령어로 배포 - Pod이 만들어짐

- 선언형으로 관리하는 것이 편함, 명령어는 불가피할 때(두 방식을 함께 씀)

 

 

2. Replicaset(레플리카셋)

- 팟들을 관리해주는 역할, 논리적으로 팟들을 묶은 다음 팟들이 장애가 났을 경우 자동으로 지우고 다시 만들어주는 등, 개수를 유지해 주는 역할

spec:

    replicas: 3 - Pods의 갯수를 3개로 유지해준다는 것

    selector: - 중요!

        matchLabels:

            app: ubuntu - app 중 ubuntu라는 레이블이 들어간 것을 선택한다는 뜻, 컨테이너들을 만드는 작업을 하면서 오른쪽 이미지처럼 컨테이너들을 만들고 포트 등을 정의해준 다음, 컨테이너 기준으로 만들어진 Pod들에게 template의 label을 붙여 줌, 그 다음 셀렉터로 세 개를 논리적으로 그루핑을 함, 하나의 앱처럼 레플리카셋이 운영되게 됨

    

* 레플리카셋 운영 중 ubuntu의 버전 업데이트 등이 발생했을 경우

- 새로운 버전을 배포할 때는 레플리카셋을 하나 더 만들어 레플리카셋의 v2를 만들어 트래픽을 변경해주는 식으로 배포,

- 이것을 쉽게 해주기 위해 Deployment라는 오브젝트를 사용

 

3.Deployment

 

 

대부분 업데이트를 할 경우 레플리카셋보다는 디플로이먼트를 이용해 배포하게 됨

 

 

 

4. Service

- 디플로이먼트는 사용자들이 만든 애플리케이션, 외부 접속을 하도록 노출시키지 않으면 접속 불가

kind: Service 사용하겠다는 것, 

metadata의 name: 이름

spect의 type: LoadBalancer: 트래픽들을 전달해주는 작업을 함 nodePod/clusterIP(팟들에게 트래픽을 분산하는 역할) 등이 자동으로 만들어짐

spec의 selector의 matchLabels의 app: 앞서 만든 팟들의 app: ubuntu로 레이블되어 있는 팟들을 선택하여 외부에 노출하겠다는 것 

 

실제 개발자들이 하는 일은 서비스 배포, 디플로이먼트 배포'