Virtual Machine의 문제점
1) 성능 오버헤드
- 하이퍼바이저를 거쳐야 하므로 베어메탈 방식에 비해 부가적인 시간이 필요함
2) 자원 낭비
- Guest OS 실행을 위한 자원이 필요함
3) 거대한 이미지 사이즈
- VM 이미지에는 애플리케이션, 필수 라이브러리, 바이너리 및 Guest OS가 포함됨
- 이미지의 사이즈가 커서 VM Migration(이동복사)이 느림
4) 느린 시작 시간
- CPU, 메모리, 하드디스크 등의 하드웨어를 가상화하고 있어 Guest OS를 부팅해야 사용할 수 있음
컨테이너 특징
1) 운영체제 수준의 가상화
- 운영체제 커널에서 제공하는 기능을 활용해 여러 애플리케이션 간에 하나의 커널을 공유함
- Guest OS를 관리할 필요 없음
2) 빠른 속도
- 하드웨어 가상화가 필요없기 때문에 하이퍼바이저 실행과 관련된 오버헤드가 발생하지 않음
3) 높은 효율성
- Guest OS를 위한 자원낭비가 없음
- 하나의 물리 서버에서 프로세스만큼이나 많은 애플리케이션을 실행할 수 있음
4) 높은 이식성
- 이미지에 애플리케이션이나 라이브러리가 포함되어 있기 때문에 환경에 의한 문제는 거의 일어나지 않음
- 호환되는 컨테이너 런타임 환경을 지원하는 OS 커널 환경이라면 실행 가능함 (윈도우 컨테이너는 리눅스에서 실행 불가능)
컨테이너 관련 기술
1) chroot : 기본 Root 디렉토리 변경
- / : 파일 시스템의 최상위를 의미함
- 모든 디렉토리와 파일은 루트 디렉토리 아래에 존재함
2) namespace : 네임스페이스별로 독립적인 공간을 제공함
- mnt(파일시스템 마운트)
- pid(프로세스)
- net(네트워크)
- ipc(SystemV IPC)
- uts(hostname)
- user(UID)
3) cgroup : 리소스 사용량을 계측하고 제한함
- 메모리, CPU, I/O, 네트워크 등등
- 유저 프로세스의 리소스 사용을 분리하여 관리함
도커
- Go 언어로 개발됨
- Docker Engine + Docker hub
- 애플리케이션 배포에 초점을 둠 (기존 컨테이너를 다른 환경에서 동작 시키는 데에 중점을 둠)
도커를 사용해야 하는 이유
1) 환경 차이로 인한 문제 방지
- 라이브러리가 서버마다 다를 때, 서버 상태를 똑같이 유지할 수 있음
- 애플리케이션의 종속성(서버, 라이브러리, 운영체제, 컴파일러, 패키지)
- Snowflake Servers : 서버들도 제각기 다른 상태
- IaC(코드로 관리하는 인프라) : 서버 구성, 라이브러리와 도구를 코드로 정의함
- 불변 인프라 : 어떤 시점의 서버 상태를 이미지로 저장할 수 있음
Docker = Dockerfile + Docker Image
2) 편리한 서버 세팅과 배포
- Immutable Infrastructure
- 서비스 운영환경을 이미지로 생성한 뒤 서버에 배포하여 실행
- 서버가 업데이트되면 운영환경 자체를 변경하지 않고, 이미지를 새로 생성하여 배포 - 이미지 버전 관리를 제공함
- 중앙저장소(Docker hub)에 이미지를 올리고 받을 수 있음
- 다양한 API를 제공하여 원하는 만큼 자동화가 가능함 - 확장 가능
- 이미지 하나로 컨테이너를 계속 찍어낼 수 있음
- 클라우드 플랫폼의 자동 확장(Auto Scaling) 기능과 연동하여 서비스 확장
도커 이미지와 컨테이너
1) 이미지와 컨테이너
- 저장소에 올리고 받는 것은 이미지(Push/Pull)
- 컨테이너는
이미지를 실행한 상태임 - 이미지는 실행파일 & 컨테이너는 프로세스
2) 이미지 처리방식 (이미지의 바뀐 부분은 어떻게 처리하나?)
- 베이스 이미지에서 바뀐 부분만 이미지로 생성됨
- 컨테이너로 실행될 때는
베이스 부분과 바뀐 부분을 합쳐서 실행함 - Docker hub나 개인 저장소에서 이미지를 공유할 때에는
바뀐 부분만 주고 받음
DevOps, 코딩 기록