기술을 왜 써야하는지 논리를 갖고 사용해야 함!

1. Container

  • container
    • code
    • dependencies
    • runtime

  • 그냥 EC2에 올려서 써도 되는데, 왜 컨테이너를 써야하는가

  • 여러 모듈, 환경들을 내 로컬에 설치해서 개발을 하게 될 것
  • 내가 개발한 결과 파일을 배포할 것
    • 서버 개수가 적다면 서버 환경을 내 로컬과 똑같이 맞춰줄 수 있음
    • 그렇지만 서버마다 환경을 모두 맞출 수 없음, 다 맞춰줘도 안되는 서버들이 있을 수 있음
    • 다른 개발자, 어플리케이션 등의 영향을 받을 수 있기 때문
  • 실패 요인
    • 리눅스 버전
    • 라이브러리 버전
    • 빌드 환경
    • JVM 환경 등등
  • 내 환경 그대로 배포하면 좋겠다! -> 컨테이너
  • 현재 추세는 MSA화

AWS Container services

스크린샷 2023-12-03 오전 11 32 24

  • ECS에 docker 파일만 업로드하면 쉽게 배포할 수 있음
    • docker -> 필요한 애플리케이션만
  • 많아진 컨테이너 관리를 위해 필요한 기술이 K8s -> EKS로 관리 (serverless)

Docker

  • Image
    • 컨테이너를 생성할 때 필요한 요소
    • 컨테이너의 목적에 맞는 binary와 dependencies가 설치되어 있음
    • 여러 개의 계층으로 된 바이너리 파일 존재
  • Container
    • 호스트와 다른 컨테이너들로부터 격리된 시스템 자원과 네트워크를 사용하는 프로세스
    • 이미지는 읽기 전용으로 사용하여 변경사항은 컨테이너 계층에 저장
    • 컨테이너에서 무엇을 하든 이미지는 영향 받지 않음
  • Docker File -[build]-> Docker Image -[run]-> Docker Container


DockerFile 예시

# base image로 python runtime 사용
FROM python:3.7-alpine

# working directory를 /app으로 설정
WORKDIR /app

# 현재 디렉토리의 컨텐츠들을 /app에 컨테이너로 복사
ADD . /app

# requirements.txt에 있는 필요한 패키지들 설치
# RUN: 이미지가 올라갔을 때 수행되는 명령어들
RUN pip install -r requirements.txt

# apache는 기본적으로 80포트 사용
# apache server로 접근 가능하게 함
EXPOSE 80

# 컨테이너가 론치될 때 gunicorn 실행
CMD gunicorn -w 4 app:app -b 0.0.0.0:80

Kubernetes

  • 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장 가능한 오픈소스 프로그램
  • 선언적 구성과 자동화를 모두 용이하게 해주는 컨테이너 오케스트레이션 툴


  • 서비스 디스커버리와 로드밸런싱
    • DNS를 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있음
    • 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있음
  • 자동화된 롤아웃과 롤백
    • 배포된 컨테이너의 원하는 새로운 버전으로 배포하는 롤아웃과 이전 버전으로 되돌리는 롤백 기능 제공
  • 자동화된 복구
    • 실패한 컨테이너를 다시 시작하고 컨테이너를 교체함
    • 서비스 준비가 끝날 때까지 이상이 있는 클라이언트에 서비스하지 않음
  • 스토리지 오케스트레이션
    • 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재


스크린샷 2023-12-07 오후 2 40 59

  • Control-plane: 중앙 컨트롤
    • API Server : 클러스터의 API를 사용할 수 있도록 하는 컨트롤 플레인 컴포넌트
      • Kubectl 명령어는 이 API Server를 호출
      • 관리해야 할 컨테이너, 이미지 등을 주기적으로 모니터링하면서 노드를 관리함!
    • Scheduler : 클러스터의 자원 할당이 가능한 노드 중 알맞은 노드를 선택해서 새로운 파드를 실행해줌
    • Controller Manager : 노드 유지, 파드 유지, 클라우드 서비스 생성 및 삭제 등
  • Data-plane: 컨테이너 이미지들이 들어있는 노드들


스크린샷 2023-12-03 오전 11 43 55 서비스 배포 -> 각 노드들로 들어가게 됨 (이미지)

스크린샷 2023-12-03 오전 11 48 19 pod 중심으로 돌아감

스크린샷 2023-12-07 오후 2 53 03

Amazon EKS

스크린샷 2023-12-07 오후 2 54 13


  • 설치 방법
    • AWS Console
    • AWS CLI
    • eksctl
    • Terraform
  • eksctl
eksctl create cluster \
    --name eks-test \
    --region ap-southeast-1 \
    --version 1.14 \
    --managed \
    --asg-access


스크린샷 2023-12-07 오후 2 57 26

스크린샷 2023-12-07 오후 2 57 55 Node group에 대해 어떻게 관리할건지만 등록해주면 간단하게 사용 가능!


스크린샷 2023-12-07 오후 2 58 58 EKS가 control-plane이 되는 느낌

2. IAM

스크린샷 2023-12-03 오전 11 55 25

  • 역할: 정책의 묶음
  • 정책은 사용자나 그룹에 부여

  • 역할은 서비스에 부여

  • 서비스 사용을 위해 IAM 정책을 부여해야 함!!
    • 많이 발생하는 에러 중 하나


  • IAM 사용자
    • 실 사용자 기준으로 통제할 때
    • IAM 사용자 (상시 자격증명)으로 인증
    • 주로 IAM Group으로 관리
  • IAM 역할
    • 자동화된 프로세스에서
    • AWS 서비스들에서
    • 인증 연계된 외부 사용자들이
    • 임시 자격증명으로 인증

정책 구성 요소

스크린샷 2023-12-03 오후 12 00 20

스크린샷 2023-12-07 오후 3 18 39

3. Cloud 9

  • 브라우저만으로 코드를 작성, 실행 및 디버깅할 수 있는 클라우드 기반 IDE
  • 코드 편집기, 디버거, 터미널이 포함되어 있음
    • 새로운 프로젝트를 시작하기 위해 파일을 설치하거나 개발 머신을 구성할 필요가 없음