container 는 왜 고안되었나 ?

가상화(VM) 의 단점

• 자원 손실
  • 경유지(Hypervisor)가 있으면 무조건 자원이 손실되기 마련
• Guest OS 가 무거움
  • 시간이 오래걸림 (올릴때, 내릴때, 생성할때, 부팅할때)
  • 자원을 차지함. 보통 한 번 띄우면 계속 띄어놓으니까

아이디어

state-less 한 Process 는 계속 자원을 차지하고 있을 필요가 없잖아? 작업을 할 때 띄우고, 작업이 끝나면 내려서 즉시 자원을 반환하자
stateful 한 Process 는 원래 할당되어 있어야 하는거고!
이를 실현할 수 있는 VM 대체 형태는 어때야할까?

VM 의 대체 Container 란?

특징

• Guest OS 없음 (가볍기 때문에 띄우고 내리는게 초 단위)
  • 위의 아이디어 대로 자원을 할당하고 반환하는 작업이 반복되려면 가벼워야함
• kernel 없음 (문제)
  • OS 가 없어서 kernel (OS 의 핵심 프로그램) 도 없음 ㅎ
  • SO, 물리단계의 OS kernel 을 호출하는 agent 존재
• 이미지(스냅샷) 으로 관리 (like VM)

Docker

• 한 개의 Container 에 대해서만 명령이 잘 되어 있음
• tool 로서 훌륭함
• 이미지 빌드(Containerize) 기능 최고
  • 빌드
  • 풀
  • 푸쉬
• 이미지
  • 컨테이너에 올라갈 app 들
  • 내부 file system 경로
  • 세팅값
  • Libs
• Deployment / Stateful Set
  • Core 한 것은 늘 띄워놓음 오히려 퍼포먼스를 위해서

컨테이너의 혜택

기민한 애플리케이션 생성과 배포
VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.

지속적인 개발, 통합 및 배포
안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.

개발과 운영의 관심사 분리
배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.

가시성(observability)
OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.

개발, 테스팅 및 운영 환경에 걸친 일관성
랩탑에서도 클라우드에서와 동일하게 구동된다.

클라우드 및 OS 배포판 간 이식성
Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.

애플리케이션 중심 관리
(가상 하드웨어 상에서 OS를 실행하는 수준) -> (논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준)으로 추상화 수준이 높아진다.

느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스
애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.

리소스 격리
애플리케이션 성능을 예측할 수 있다.

자원/리소스 사용량
고효율 고집적.