TIL

Chapter 01 컨테이너 개요

1-1 컨테이너 기술

서버 가상화와 컨테이너

• 컨테이너
  • 다른 프로세스와 격리된 상태로 OS에서 소프트웨어를 실행하는 기술
  • 컨테이너 내 소프트웨어에서 보면 독립된 OS 환경을 점유하고 있는 것처럼 보인다.
  • 게스트 OS별로 커널을 점유하는 서버 가상화와 달리 OS와 커널을 공유하고 프로세스를 분리하는 구조다.

컨테이너의 장점

• 환경 의존에서의 해방
  • 애플리케이션 가동에 필요한 런타임과 라이브러리를 한 패키지로 묶음어로써 애플리케이션 의존 관계를 컨테이너 안에 집약할 수 있다.
  • 컨테이너는 의존 존관계가 포함된 패키지가 바로 배포 단위
  • 한 번 빌드한 이미지는 컨테이너의 런타임상에서 동일한 동작을 하기에 라이브러리와 관련된 환경 의존을 고려하지 않아도 된다.
• 환경 구축 및 테스트에 필요한 시간 감소
  • 모든 의존관계가 컨테이너 안에서 완결되므로 애플리케이션 배포나 마이그레이션 업무가 단순해진다.
  • 컨테이너는 로컬, 온프레미스나 퍼블릭 클라우드에서 동일하게 동작한다.
• 자원 효율
  • 컨테이너는 게스트 OS와 하드웨어 에뮬레이트를 하지 않아도 되기에 서버 가상화에 비해 컴퓨팅 자원의 소비가 적다.
  • 프로세스 단위로 동작하기에 애플리케이션의 기동도 빠르다.

1-2 도커란

도커 개요

• 도커란 컨테이너 라이프사이클을 관리하기 위한 플랫폼이다.
  • 도커사의 슬로건: ‘Build, Ship, Run’
• Dockerfile
  • 이미지를 생성하기 위한 텍스트 파일
  • 애플리케이션에 필요한 라이브러리를 설치하거나 컨테이너 환경 변수를 지정한다.
• 이미지
  • 컨테이너를 실행하기 위해 필요한 빌드된 패키지
• 태그
  • 이미지에 할당한 라벨
  • 이미지 버전 관리 용도
• 레지스트리
  • 이미지를 보관하기 위한 서비스
  • 도커 레지스트리는 여러 개의 레포지토리로 구성되지만 public과 private으로 구분된다.
• 컨테이너
  • 이미지로부터 생성된 실행 주체
  • 애플리케이션 및 의존 라이브러리를 포함한 형태

알아둬야 할 기본 도커 조작

• 이미지 생성
  • docker image build
  • 애플리케이션 소스 코드와 Dockerfile로 이미지를 만드는 경우
• 이미지 목록 표시
  • docker image ls
• 이미지 삭제
  • docker image rm
• 이미지 태그 추가
  • docker image tag
• 레지스트리에 이미지 업로드
  • docker image push
  • 실제 운영 시 push하려면 사전에 저장소에 로그인하고 특정 규칙에 따라 이미지 이름을 붙여야 한다.
• 레지스트리에서 이미지 취득
  • docker image pull
• 컨테이너 실행
  • docker contaner run
  • 실행한 컨테이너 기동 상태는 docker container ls로 확인 가능
• 로그 확인
  • docker contaner logs
• 실행 중인 컨테이너에 명령 전달
  • docker container exec
• 컨테이너 정지
  • docker container stop

도커 명령어 체계

• 도커는 버전 1.13부터 docker [무엇을] [어떻게 한다] 형식의 명령 체계로 바뀌었다.
  • ex) 이미지 생성을 docker build로 하던 것에서 docker image build로 바뀌었다.
• 도커사는 새로운 체계 명령을 사용할 것을 추천하고 있다.
  • 업데이트된 내용을 올바르게 쓴다는 의미에서

1-3 오케스트레이터란

컨테이너를 운용할 때의 과제

• 여러 컨테이너를 가동시키려면 단일 호스트가 아닌 여러 호스트로 이루어진 클러스터를 구성해야 한다.
  • 클러스터 환경에서 컨테이너의 부하 분산
  • 다운 타임을 최소화하기 위한 업데이트 방법
• 이러한 과제를 해결하기 위해 컨테이너 그룹을 관리하는 서비스인 오케스트레이터가 등장한다.

오케스트레이터가 해결할 수 있는 것

• 컨테이너 배치 관리
  • 컨테이너의 배치 관리를 자동 제어가 가능하다.
  • 각 컨테이너가 호스트에 균등하게 부하 분산 + 장애 시 컨테이너 복구 등
• 컨테이너 부하 분산
  • 오케스트레이터와 로드밸런서를 조합하여 컨테이너의 부하 분산 처리를 구현할 수 있다.
• 컨테이너 상태 감시 및 자동 복구
  • 사전에 정해둔 컨테이너 수를 유지하도록 자동 제어할 수 있다.
• 컨테이너 배포
  • 애플리케이션을 가동 중인 상태로 컨테이너를 자동으로 교체할 수 있다.

대표적인 컨테이너 오케스트레이터

• 쿠버네티스 (Kubernetes)
  • 사실상 표준으로 자리잡고 있는 오케스트레이터
• 쿠버네티스를 기반으로 한 각종 컨테이너 오케스트레이터
  • 도커 스웜 (Docker Swarm)
  • AWS EKS
  • 구글 클라우드의 GKE
• 클라우드 서비스가 제공하는 오케스트레이터
  • AWS가 제공하는 독자적인 컨테이너 오케스트레이터인 Amazon ECS
  • ECS는 많은 기업과 스타트업에서 중요 기술로 사용되고 있다.

1-4 컨테이너 기술을 도입하기 위해 고려해야 할 것

컨테이너를 전제로 하는 애플리케이션을 개발하는 방법

• 클라우드에서 컨테이너 기반 분산 시스템을 전제로 한다면 컨테이너 간 느슨한 결합성과 이식성을 고려한 방식을 검토해야 한다.
  • 컨테이너를 다루는 애플리케이션 설계는 기존 온프레미스 환경에서 서버를 다루는 경우와 다른 방식
  • 컨테이너 디스크 영역을 휘발성이고 컨테이너 파기와 동시 내부 데이터는 사라진다.

컨테이너 설계, 운용에 임하는 자세

• 컨테이너는 그에 맞는 새로운 운용도 발생한다.
  • 저장소의 이미지 라이프사이클 관리 및 이미지 보호
  • 빌드에서 배포까지의 흐름
  • 컨테이너 오케스트레이션 권한 제어, 정의 관리, 보안 설계 등
• 클라우드를 이용해도 기존 서버 구성에서 필요했던 비기능 관련 부분은 변함 없이 중요하다.

개발 팀 역할 분담 개편

• 온프레미스와 IaaS 중심의 시스템 운용에선 개발팀과 인프라 팀이 나눠 업무를 하는 경우가 많았다.
  • 개발 팀은 애플리케이션 개발에 주력
  • 인프라 팀은 미들웨어, OS 설정 및 차이브러리 준비 등에 주력
• 컨테이너화가 진행되면 이런 업무 형태에도 변화가 생긴다.
  • 애플리케이션 가동에 필요한 OS 라이브러리, 미들웨어, 언어별 라이브러리 등을 개발팀에서 관리
  • 개발 팀이 인프라 팀에서 관리했던 패키지 영역까지 수행
• 컨테이너 중심의 팀에서도 개발 팀과 인프라 팀이 서로 역할 분담을 재검토해 나가는 자세가 중요