Virtualization 2

 

 

Virtual Machine

 

Pros

- full autonomy

- very secure

-lower costs

- used by all cloud providers for on demand server instance

 

Cons

- VM 사이즈 크기 때문에 휴대성 안 좋음(encapsulate)

- VM overhead

 

=> Container로 보완

 

Container

 

 

VM이 하드웨어적으로 virtualization하는 테크닉이라면,

container은 OS level의 virtualization 테크닉으로, 더 간편하다.

 

머신러닝 app이 있다고 할 때 이 app을 운영하기 위해서 PyTorch, TF 와 같은 프로그램에 의존한다.

app과 PyTorch를 하나의 unit에 포장해서 기계에 주는 거다.

그러면 받은 기기에서는 그 unit의 독립된 환경을 조성해 보관하며 코드를 실행할 때 꺼내 쓴다.

 

Characteristics

 

- Lightweight: 컨테이너는 OS를 따로 지니고 있지 않기 때문에 기기의 host OS를 빌려 쓴다.

=> VM보다 가벼움

- Portability: 한 번 컨테이너가 만들어지면 컨테이너의 이미지는 다른 기기에 줘도 그대로 계속 같음

- Isolation: 모든 컨테이너는 자신의 공간을 가지고 같은 기기라 하더라도 다른 컨테이너와 모르는 사이

* user 공간, memory 공간 등 process가 분리되어있는 것임 <-> VM은 하드웨어 자체가 분리되어 있음

 

 

Namespaces and Cgroups

 

- Namespaces

: 프로세스들이 자신의 자원만을 볼 수 있도록 시스템 자원을 분리한 Linux kernel 특징

: PID, Mount, UTS, IPC, Network, User namespaces 포함

 

- Cgroups

: 프로세스별로 자신의 자원만을 사용할 수 있도록 각자의 자원(CPU, memory, disk I/O 등)을 고립시킴

 

 

- container images

EC2에 비유해보자.

 

Instance가 container라면,

AMI가 container image

 

- image registries

: container image를 위한 storage & distribution system

ex. Docker Hub

 

image cirle에 circle-app code, dependencies, OS constructs를 빌드해놓으면

그 image circle이 여러 image를 Docker Hub에 종류별로 넣어둠

유저들이 사용하고 싶은 image 가져다가 container를 만드는 데 씀

 

Container runtime

 

: host OS에서 컨테이너를 운영하기 위해 필요

 

container engine은 VM에서의 hypervisor라고 보면 된다.

container engine은 container를 대신하여 OS와 소통

container은 공유 라이브러리를 쓰는 대신 자신 속에 library를 따로 두어 engine의 자리 확보

 

Docker Engine

: 가장 널리 사용되는 container runtime

: containerization을 처음 시작할 때부터 사용됨

 

OCI(Open Container Initiative)

: 컨테이너의 format과 runtime 표준을 만드는 데 필요한 오픈된 관리 구조

 

 

Docker

 

가장 널리 사용되는 container engine

 

Client

 

세 개의 주요 docker commands

 

- docker build: 이미지 빌드하는 명령어

* docker daemon로 가서 docker file 에 이미지 생성 가능 

- docker pull: 다운로드하는 명령어

* docker daemon이 명령어 받음 -> docke daemon이 registry로부터 해당 이미지 가져옴

- docker run: 이미지 밖에서 컨테이너 실행

* daemon이 명령어 받음 -> 이미지 사용해 container 만듦

 

 

DOCKER_HOST

 

- docker daemon

- containers

- images

 

대부분의 경우 client와 docker host가 모두 사용자의 기기에 있어 동일시되지만

docker host를 remote 서버로 보면 분리 가능하다. 서버 안에서 container가 실행된다고 보는 거다.

 

Registry

 

이미 누군가에 의해 만들어진 docker image가 저장돼 있다. 

 

Docker Flow

 

1. Dockerfile을 build하면 

* Dockerfile: docker image를 디자인하는 데 사용되는 텍스트파일

2. Docker Image가 생성되고 이것을 run하면

3. Docker Container가 만들어짐

 

실제로 리눅스 환경에서 다음과 같이 교수님처럼 run해볼 수 있다. 

 

containerization 과정을 좀 더 자세히 살펴보자.

 

1. Create a Dockerfile

 

- FROM

: demon에게 어떤 base 이미지를 사용할 것인가 알려주고 새로운 이미지 만들고 싶다면 만듦

: registry로부터 이미지 끌어와 쓸 수도 있음

 

- WORKDIR

: docker image 속 basic working space

 

- COPY

 

- RUN

: 이미지를 만들고, docker demon에게 입력된 명령어를 실행하도록 함

=> 이미지를 만들 때 실행된다는 점에서 CMD와 다름

이미지 만들 때 dependency를 넣음

 

- CMD

: container가 실행되는 동안 디폴트 명령어와 parameter를 세팅함

=> container를 만들 때 실행된다는 점에서 RUN과 다름

 

FROM python: 3.8-slim
WORKDIR /app
COPY ./app
RUN pip install -r requirements.txt
CMD ["python", "app.py"]