728x90
  • 읽기 전용 볼륨

바인드 마운트는 로컬의 특정 위치로 연결이 된다.

그럴 때 런타임 중에 해당 파일들을 변경할 수 없도록 해야 하는 경우가 있을 것이다.

그런 경우에 사용하는 바인드 마운트를 읽기 전용 볼륨으로 전환하는 방법을 알아보자.

 

docker run -v "{로컬의 위치:도커의 위치:ro}" {image ID || image Name}

 

그럴 때는 -v 옵션을 사용하면서 :ro read-only 옵션을 넣어준다.

 

  • Docker 볼륨 관리하기

우선 현재 도커에서 관리하고 있는 볼륨들을 먼저 확인해보자.

docker volume ls

 

현재는 익명 볼륨 2개와 이름 볼륨 1개를 사용하고 있는 것을 볼 수 있다.

당연히 바인드 마운트는 도커에 의해 관리되는 것이 아니기 때문에 여기에서 확인할 수 없다.

 

구체적으로 볼륨을 만들 수도 있다.

docker volume create {볼륨 이름}

 

많이 사용할 거 같지는 않다.

 

docker volume inspect {볼륨 이름}

 

inspect를 사용해서 해당 볼륨의 자세한 정보를 확인해볼 수 있다.

 

docker volume rm {볼륨 이름}

 

rm을 사용해서 볼륨을 제거할 수 있다.

물론 해당 볼륨을 사용하고 있는 컨테이너가 없을 때만 사용이 가능하다.

 

  • dockerignore 사용하기

COPY를 할 때 보통 모든 파일들을 복사해가지만, 복사하면 안되는 파일도 있을 것이다.

그럴 때는 .dockerignore을 사용해서 복사를 막는다.

.dockerignore에 명시한 파일, 폴더 등은 복사가 되지 않으며 사용방법은 .gitignore와 비슷하다.

 

 

  • Docker로 환경변수 작업하기

 

 

Dockerfile에 다음과 같이 작성하면 된다.

 

run 할 때 -e key=value로도 명시할 수 있다.

 

이렇게 환경변수를 사용하면 애플리케이션에서 해당 환경변수를 사용해 하드코딩할 필요 없이 유연하게 작성할 수 있다는 장점이 있다.

 

환경변수가 지정된 파일을 --env-file로 지정할 수 있다.

이렇게 key=value값이 지정되어 있는 파일을 

이렇게 docker run 할 때 지정해주면 된다.

 

'백엔드 > Docker' 카테고리의 다른 글

Docker에서의 볼륨과 바인드 마운트  (0) 2024.02.12
DockerHub 사용하기  (0) 2024.02.11
이미지와 컨테이너 관리  (1) 2024.02.11
Docker 이미지와 컨테이너  (0) 2024.02.03
Docker란?  (0) 2024.02.01
728x90
  • Docker에서의 데이터 종류

Docker에서의 데이터는 크게 3가지로 나눌 수 있다.

 

우리가 이미지를 만들고 컨테이너를 실행하는 데 필요한 데이터와 런타임 중에 임시로 생성되는 데이터, 그리고 런타임 중에 생성이 되며 영구적으로 저장해야 하는 데이터가 있다.

스프링부트를 사용하면 사용자로부터 파일 업로드를 받을 때가 있는 데, 이때 영구적인 데이터로 저장을 하는 것 같다.

이미지는 읽기 전용이기 때문에, 이 부분에 데이터를 추가할 수는 없다.

이 때는 volume을 사용해야 한다고 한다.

 

  • 기존의 방법으로 컨테이너에 데이터 저장

기존의 방식으로 런타임 도중에 파일을 저장해보도록 하자.

 

run 할 때 --rm 의 옵션을 추가했다.

이 앱을 이용해서 해당 파일을 저장한다.

 

 

이렇게 저장된 파일에 접속이 가능한 것을 볼 수 있다.

 

과연 해당 파일은 컨테이너를 재실행하더라도 접속이 가능할까?

 

재실행하고 접속을 해보았지만

접속이 불가능한 것을 확인할 수 있다.

컨테이너가 삭제되고 재실행되었기 때문에 해당 파일도 삭제되어서 그런 것임을 알 수 있다.

 

--rm을 제거하여 컨테이너를 삭제하지 않고 재실행만 해보자.

stop 후 start로 재실행하니 해당 데이터는 삭제되지 않아 다시 접속이 가능한 것을 볼 수 있다.

 

하지만 여기서 한 가지 문제를 찾을 수 있다.

해당 데이터가 컨테이너 내부에 저장이 되기 때문에 컨테이너가 제거되면 데이터도 제거가 된다.

동일한 이미지를 사용하더라도 말이다.

WAS에서는 업로드 한 데이터들을 삭제하면 안되는 경우가 생길 수도 있기 해당 데이터를 가지고 있어야 한다.

 

그렇기 때문에 Docker의 volume을 사용하여 데이터를 유지할 수 있도록 해야 한다.

 

  • volume이란?

volume은 호스트 머신의 폴더이다. 컨테이너나 이미지에 있는 것이 아니다.

volume은 도커가 인식하는 호스트 머신에 있는 폴더로서 도커 컨테이너 내부의 폴더에 매핑된다.

 

그리고 두 폴더의 변경 사항은 다른 폴더에 반영이 된다.

호스트 머신에 파일을 추가하면, 컨테이너 내부에서 액세스 할 수 있다.

컨테이너가 매핑된 경로에 파일을 추가하면, 호스트 머신에서도 사용할 수 있다.

 

이렇게 volume을 통해 데이터를 유지할 수 있다.

해당 volume은 컨테이너가 종료되더라도 유지되기 때문이다.

 

 

Docker의 volume에는 2가지 종류가 있다.

익명 volume과 명명된 volume이다.

익명 volume은 진짜 호스트 머신의 어딘가로 연결이 되며, 보통은 그 경로를 모를 것이다.

신경 쓸 필요가 없어 편하지만, 해당 익명 volume은 컨테이너가 종료된 경우에 삭제가 된다.

 

그렇기 때문에 이런 경우에는 Named volume을 사용해야 한다.

 

Named volume을 사용하는 방법은 run 할 때 -v 옵션을 사용하는 것이다.

docker run -v {volume 이름:컨테이너 내부 path} {image ID || image Name}

 

이렇게 실행을 하면 --rm 옵션으로 컨테이너를 삭제하더라도 데이터가 보존되는 것을 볼 수 있다.

 

  • 바인드 마운트

개발하는 과정에서 스프링부트의 코드가 조금이라도 변경이 된다면, 이미지를 새로 만들고 해당 이미지로 컨테이너를 만들어야 했다.

해당 과정은 시간이 굉장히 오래 걸리고, 이미지가 쌓인다는 문제가 있었다.

바인드 마운트는 volume과는 다르게 해당 위치를 개발자가 알 수 있으며, 호스트 머신 상에 매핑될 컨테이너의 경로를 설정한다.

COPY로 소스코드를 복사하는 것이 아니라, 해당 마운트의 파일을 최신버전으로 유지하면서 배포할 수 있다는 장점이 있다.

 

바인드 마운트도 -v를 사용한다.

volume과는 거꾸로 {복사하고 싶은 디렉터리 : 컨테이너 디렉터로}로 실행할 수 있다.

docker run -v {바인드 마운트 할 경로:컨테이너 내부 path} {image ID || image Name}

 

하지만 이 과정에서 덮어쓰기 때문에 필요한 종속성들이 날아갈 수 있다.

그렇기 때문에 종속성이 있는 폴더는 익명 volume으로 유지하면서 run을 하면 종속성을 유지한 채로 최신 버전으로 실행이 가능하다.

 

 

  • 컨테이너에서 데이터 관리하는 방법들 간의 비교

'백엔드 > Docker' 카테고리의 다른 글

Docker에서 볼륨과 바인드 마운트 관리하기  (0) 2024.02.12
DockerHub 사용하기  (0) 2024.02.11
이미지와 컨테이너 관리  (1) 2024.02.11
Docker 이미지와 컨테이너  (0) 2024.02.03
Docker란?  (0) 2024.02.01
728x90
  • 이미지를 공유하는 방법

이미지를 공유하는 방법에는 2가지가 있다.

1. Dockerfile을 공유한다.

2. 빌드된 이미지를 공유한다.

1번의 방법을 사용하면 받아온 후에 빌드를 해야하지만, 2번을 사용하면 빌드된 이미지를 공유하기 때문에 빌드를 할 필요도 없다.

 

  • DockerHub에 이미지를 push하기

 도커허브에 업로드 하는 방법과 개인 저장소에 업로드 하는 방법이 있지만, 우선은 도커허브에 업로드하는 방법을 사용해보도록 하자.

DockerHub에 계정을 만들고 리포지토리도 생성한다.

그리고는 로컬에 와서 push 해주도록 한다.

 

깃과 마찬가지로

docker push {이미지 이름}

 

이렇게 사용하지만, {레포지토리 이름/이미지 이름:태그}의 이름으로 이미지가 생성되어 있어야 한다.

 

물론 이것이 개인 계정이기 때문에 docker login을 해야 할 수도 있다.

 

docker login

 

해당 명령어를 이용하여 계정과 비밀번호를 입력해주면 로그인이 완료된다.

 

 

이렇게 새로운 이미지가 올라간 것을 볼 수 있다.

 

  • DockerHub에서 이미지를 pull하기

push와 반대로 올라간 이미지를 pull 할 수 있다.

docker pull {리포지토리 이름/이미지 이름:태그}

 

해당 명령어로 가져오면 된다.

 

이렇게 pull을 하면 새로운 이미지가 생성되어 있는 것을 볼 수 있다.

'백엔드 > Docker' 카테고리의 다른 글

Docker에서 볼륨과 바인드 마운트 관리하기  (0) 2024.02.12
Docker에서의 볼륨과 바인드 마운트  (0) 2024.02.12
이미지와 컨테이너 관리  (1) 2024.02.11
Docker 이미지와 컨테이너  (0) 2024.02.03
Docker란?  (0) 2024.02.01
728x90
  • 컨테이너의 중지와 재시작
docker ps

 

docker ps를 입력하면 현재 실행 중인 도커 컨테이너들을 확인할 수 있다.

 

만약 현재 실행 중인 컨테이너 외에도 중지된 컨테이너까지 확인하기 위해서는 다음 명령어를 사용하면 된다.

docker ps -a

 

이러면 현재 종료되어 있는 컨테이너도 확인할 수 있다.

 

이 종료되어 있는 컨테이너를 다시 재시작할 수도 있다.

docker run은 이미지를 기반으로 새 컨테이너를 만들지만, 변경사항이 없어서 컨테이너를 재실행하고 싶다면 docker ps -a로 컨테이너를 검색한 후

docker start {container ID || container name}

 

이렇게 종료된 컨테이너를 재실행한 것을 볼 수 있다.

 

  • Attached, Detached

방금 해보았던 docker start로 컨테이너를 실행하면, 외부에서 docker ps로 상태만 확인할 수 있었고 내부에서 작업은 하지 않았었다.

분명히 실행 중인데도 말이다.

이 전의 docker run으로 컨테이너를 실행하면, 해당 터미널에서 컨테이너가 실행되고 다른 터미널에서 상태를 확인할 수 있었다.

이제 여기서 자유롭게 attached, detached를 설정하여 작업해 보도록 하자.

우선 docker start는 detached 모드가 디폴트이며, docker run은 attached 모드가 디폴트이다.

 

docker run을 확인해보자.

이렇게 콘솔에 컨테이너의 결과가 출력되는 것을 볼 수 있다.

 

이 컨테이너를 콘솔과 연결되지 않는 detached 모드로 실행하기 위해서는, -d 옵션을 넣어주면 된다.

 

이렇게 -d 옵션을 넣어주면, 이전과는 다르게 바로 컨테이너가 실행되었다고 나오고 터미널과는 분리되는 것을 볼 수 있다.

 

분리된 컨테이너와 터미널을 다시 연결하고 싶다면, attach 명령어를 사용하면 된다.

 

docker attach {container ID || container name}

 

 

이렇게 다시 연결되어 결과가 출력되는 것을 볼 수 있다.

 

터미널과 연결시키지 않고 로그만 가져오고 싶다면, logs 명령어를 사용하면 된다.

 

이렇게 바로 출력의 결과만 가져오는 것을 볼 수 있다.

 

  • 인터렉티브 모드로 작업하기

웹서버뿐만 아니라 짠 코드를 직접 실행시킬 수도 있다.

 

작성한 파이썬 코드를 실행해보도록 하겠다.

Dockerfile은 다음과 같이 작성했다.

FROM python

WORKDIR /python

COPY . /python

CMD ["python", "rng.py"]

 

해당 Dockerfile을 바탕으로 이미지를 생성하고, 컨테이너를 실행한다.

 

그리고는 run -it를 사용하여, 인터렉티브하게 컨테이너를 실행한다.

docker run -it {image ID || image name}

 

이러면 해당 컨테이너와 상호작용하며 실행할 수 있다.

 

run이 아닌 start의 상황에서는 -ai 옵션을 사용하여 인터렉티브하게 재실행한다.

 

  • 이미지와 컨테이너 삭제하기

그 동안 생성했던 많은 이미지와 컨테이너들을 삭제해보도록 하자.

 

컨테이너를 제거할 때는 rm 명령어를 사용한다.

docker rm {container ID || container name}

당연히 실행 중인 컨테이너는 삭제할 수 없고, 현재 종료된 컨테이너만 제거가 가능하다.

 

이번에는 이미지를 삭제해보자.

이미지를 삭제할 때는 rmi 명령어를 사용한다.

docker rmi {image ID || image name}

 

 

이렇게 이미지가 삭제되는 것을 볼 수 있다.

여기서도 이미지는 해당 이미지를 사용하여 실행 중인 컨테이너가 존재하지 않을 때만 삭제가 가능하다.

 

해당 명령어를 사용하면, 삭제 가능한 모든 이미를 삭제한다.

docker image prune

 

만약 컨테이너를 종료 후 해당 컨테이너를 자동으로 제거하고 싶다면, run을 하면서 --rm 옵션을 넣어주면 된다.

docker run --rm {image ID || image name}

 

 

이렇게 종료하자마자 자동으로 삭제되는 것을 볼 수 있다.

 

  • 컨테이너에서의 파일 복사

실행 중인 컨테이너로 또는 실행 중인 컨테이너 밖으로 파일 또는 폴더를 복사할 수 있다.

해당 과정에서는 cp 명령어를 사용한다.

 

docker cp {복사하려는 파일 혹은 폴더} {container name}:{복사하려는 경로}

 

 

당연히 반대로 컨테이너에서 가져올 수도 있다.

cp 명령어를 사용하여 경로의 순서를 바꾸면 된다.

 

docker cp {container name}:{복사하려는 경로} {복사하려는 파일 혹은 폴더}

 

 

  • 컨테이너와 이미지에 이름 혹은 태그 지정하기

지금까지는 자동으로 도커에서 생성된 이름만을 사용했다.

당연히 이런 이름들도 우리가 직접 지정할 수 있다.

직접 지정하는 방법을 알아보도록 하자.

--name 옵션에 이름을 지정해주면 된다.

docker run --name {container name} {image ID || image name}

 

myapp이라는 이름이 지정된 것을 볼 수 있다.

 

이번에는 이미지에 이름을 지정해보자.

이미지의 이름을 태그라고 하며 2개로 구분할 수 있다.

이미지의 리포지토리 : 이미지의 태그 이렇게 구성이 되어 있는 데, 이렇게 만든 이유는 여러개의 특정화된 이미지 그룹을 만들 수 있기 때문이다.

이미지를 가져올 때도 태그를 지정할 수 있으며, 보통은 특정 버전의 이미지를 가져올 때 사용한다.

 

이미지의 이름을 생성할 때는 -t 옵션을 사용한다.

docker build -t {이미지의 이름}:{이미지의 태그} .

 

 

'백엔드 > Docker' 카테고리의 다른 글

Docker에서 볼륨과 바인드 마운트 관리하기  (0) 2024.02.12
Docker에서의 볼륨과 바인드 마운트  (0) 2024.02.12
DockerHub 사용하기  (0) 2024.02.11
Docker 이미지와 컨테이너  (0) 2024.02.03
Docker란?  (0) 2024.02.01
728x90
  • 이미지와 컨테이너는 무엇인가?

저번에 다루어 봤듯이 컨테이너는 애플리케이션, 애플리케이션을 실행하는 전체 환경 등등 무엇이든 포함하는 작은 패키지이다.

컨테이너에는 소프트웨어 실행 유닛이 존재하며, 우리는 그 유닛을 실행하는 것이다.

이미지는 템플릿, 컨테이너의 블루프린트이다.

이미지는 실제로 코드와 코드를 실행하는데 필요한 도구를 포함한다.

 

하나의 이미지는 하나의 컨테이너만 실행하는 것이 아니라

이미지를 기반으로 여러 컨테이너를 만들 수 있다.

이미지는 모든 설정과 코드가 포함된 공유 가능한 패키지이며, 컨테이너는 그런 이미지의 구체적인 실행 인스턴스이다.

 

  • 외부에서 이미지를 가져와 사용하기

이미지는 우리가 직접 만드는 것이 아닌, 가져와서 사용하는 방법도 존재한다.

일반적이어서 미리 구축이 되어 있는 공식 이미지들이 많이 있으며, 해당 이미지를 가져오는 것도 좋은 방법이다.

보통은 DockerHub에서 많이 찾아볼 수 있다.

https://hub.docker.com/

 

Docker Hub Container Image Library | App Containerization

Deliver your business through Docker Hub Package and publish apps and plugins as containers in Docker Hub for easy download and deployment by millions of Docker users worldwide.

hub.docker.com

 

docker run node 명령어를 실행해 보았는 데, 아래처럼 나오는 것을 볼 수 있다.

우선 local에서 node image를 찾고, 없기 때문에 원격으로 이미지를 가져오는 것을 볼 수 있다.

 

  • 이미지를 이용하여 빌드하기

커스텀 이미지를 만들기 위해서는 Dockerfile을 만들고 작성해야 한다.

우선 다음과 같이 작성한다.

FROM node

WORKDIR /app

COPY . /app

RUN npm install

EXPOSE 80

CMD ["node", "server.js"]

 

FROM은 다른 베이스 이미지 위에 현재 이미지를 생성한다는 의미이다.

물론 처음부터 만들 수는 있지만, 언제나 코드에 필요한 도구 같은 레이어가 필요하기에 보통은 추가한다.

 

WORKDIR은 도커 내부에서 해당 컨테이너를 작업할 경로를 명시한다.

/app 폴더 밑에서 작업한다는 의미이다.

 

COPY는 Dockerfile과 같은 디렉토리디렉터리 내에서 작업 디렉터리로 복사해 가져갈 파일들을 적어놓는 것이며, . 을 사용하면 현재 디렉터리에서 Dockerfile을 제외한 모든 파일을 복사한다는 의미이며, 도커 내부의 /app 폴더로 복사해 간다는 것이다.

WORKDIR에 의해 도커 내부의 경로는 상대주소를 가질 수 있지만, 보통 명확하게 하기 위해 절대경로로 하는 것을 추천한다.

 

RUN은 이미지에서 실행할 명령을 작성하는 것이다. 여기서에선 npm install을 사용해 필요한 종속성들을 설치해 주었다.

 

EXPOSE는 노출하고 싶은 포트의 주소를 명시한다.

없어도 되지만 그래도 명시하도록 하자.

 

CMD는 이미지가 빌드 될 때 실행되는 명령이 아닌, 컨테이너를 실행할 때 사용하는 명령어를 적어두면 된다.

 

이제 해당 이미지를 바탕으로 빌드해보자.

 

docker build .

 

해당 명령어를 사용하면 현재 디렉토리에 있는 Dockerfile을 사용해 이미지를 빌드한다.

 

 

Dockerfile에 있는 명령어들이 실행 된 것을 볼 수 있다.

 

해당 이미지를 바탕으로 컨테이너를 실행해본다.

docker run -p 80:80 {이미지 ID}

 

 

이렇게 접속이 되는 것을 볼 수 있다.

 

도커의 실행 상태를 보고 싶다면

docker ps 명령어를 사용하여 현재 실행 중인 컨테이너들을 볼 수 있다.

 

  • 이미지의 변경사항

이미지는 단순히 읽기를 위해서 작성한 코드이다.

무슨 말인지를 직접 보여주도록 하겠다.

이렇게 html 중간의 내용을 변경하였다.

 

이렇게 변경을 하고 도커의 컨테이너를 재실행해도

이렇게 이전 그대로 나오게 된다.

 

이는 이전에 COPY 한 내용을 바탕으로 실행이 되기 때문에 해당 COPY에서는 변경사항이 적용되지 않아 생기는 문제이다.

그렇기 위해 이미지로 빌드를 다시 해서 COPY를 다시 해야 해당 변경사항이 적용 될 것이다.

 

이미지를 다시 빌드하고 컨테이너를 실행해보니

이렇게 제대로 적용이 된 것을 볼 수 있다.

 

  • 이미지의 레이어

Docker에서 이미지를 만들 때

 

이렇게 CACHED라고 나오는 경우를 볼 수 있을 것이다.

도커는 명령어를 다시 실행했을 때의 결과가 동일하다고 판단되면, Cache를 사용한다.

모든 명령의 결과를 캐시하고, 그 캐시를 사용하는 것이다.

이것을 레이어 기반 구조라고 한다.

Dockerfile의 모든 명령어는 레이어를 나타낸다.

 

이렇게 이미지 레이어를 기반으로 컨테이너가 실행되게 된다.

 

해당 레이어에서 아무것도 변경되지 않으면, 캐시를 사용하지만

만약 코드가 변경이 된다면 캐시의 일부만 사용하고 해당 변경내용을 다시 실행하게 된다.

 

이렇게 만약 코드가 변경이 되었다면, 해당 파일을 다시 COPY하며 캐시를 사용하지 않는 것을 볼 수 있다.

그리고 그 아래의 레이어들도 모두 재실행되는 것을 볼 수 있다.

 

'백엔드 > Docker' 카테고리의 다른 글

Docker에서 볼륨과 바인드 마운트 관리하기  (0) 2024.02.12
Docker에서의 볼륨과 바인드 마운트  (0) 2024.02.12
DockerHub 사용하기  (0) 2024.02.11
이미지와 컨테이너 관리  (1) 2024.02.11
Docker란?  (0) 2024.02.01
728x90
  • 도커란?

도커는 컨테이너 기술입니다.

컨테이너를 생성하고 관리하기 위한 도구입니다.

 

이렇게 말하면 쉽게 이해가 되지 않으며, 왜 써야 하는 지도 잘 모르겠다.

 

우선 소프트웨어 개발에서 컨테이너는 표준화된 소프트웨어 유닛입니다.

아래는 구글 클라우드에서 말하는 컨테이란?입니다.

https://cloud.google.com/learn/what-are-containers?hl=ko

컨터이너는 스프링부트를 사용해 봐서 알겠지만, 해당 코드와 종속성, 코드들이 포함되어 있다.

 

도커는 결국 이러한 컨테이너의 생성 및 관리 프로세스를 도와주는 도구이다.

결국 도커로 이 컨테이너를 만들고 관리하는 것이 목표가 될 것이다.

 

  • 컨테이너가 필요한 이유

왜 이렇게 개발에서 독립적인 표준화된 애플리케이션 패키지를 원하는 것일까?

이렇게 직접 작업한 로컬의 환경과 배포에서의 환경이 다른 경우가 생긴다.

Java 11에서는 사용하지 못하는 코드들이 있다면 문제가 될 것이다.

 

이러한 문제가 있기에 같은 개발 환경을 갖는 것은 상당히 중요한 문제이다.

이것을 도커의 컨테이너로 해결하는 것이다.

 

특정 버전을 도커 컨테이너에 Lock 할 수 있으므로, 코드가 항상 정확한 버전으로 실행되도록 할 수 있다.

애플리케이션이 자체적으로 필요한 버전을 제공하는 컨테이너에서 실행되게 된다.

 

또한 팀에서 작업을 하게 된다면

팀원 간에 작업 환경이 다르게 될 수도 있다.

그런 경우에도 문제가 생기지 않도록 같은 환경에서 실행될 수 있도록 한다.

 

또한, 혼자 작업을 하는 경우에도 문제가 될 수 있다.

이렇게 가지고 있는 프로젝트마다 버전이 다른 경우이다.

 

이런 상황에서도 컨테이너에 모든 환경이 속해있기 때문에 컨테이너만 바꾸면 문제없이 동작할 수 있게 된다.

 

  • 가상 머신 VS 도커

옛날에 가상머신으로 네트워크 공부했던 거 처럼, 그냥 가상머신에 각각의 환경을 만들어서 배포를 해도 독립된 환경을 만들어 줄 수 있기는 하다.

하지만 보통은 도커를 사용하게 되는 데, 이유에 대해 알아보자.

리눅스의 가상머신을 이용한다고 해보자.

 

이렇게 각 App마다 VM을 사용하게 되고, 이 Virtual OS는 메모리, CPU등의 사용량이 높다.

때문에 VM을 많이 사용할 수록 큰 오버헤드가 발생하게 된다.

 

도커를 사용할 때를 보자.

이 컨테이너에는 중요한 도구, 런타임이 추가되어 있지만 오버헤드가 큰 운영체제 등은 들어가 있지 않다.

컨테이너 내부에 작은 레이어가 포함되어 있을 수는 있지만, VM을 설치하는 것과는 비교도 안되게 가벼울 것이다.

또한 도커를 사용하면 이미지를 만들어 다른 사람과 공유하며, 모든 사람이 자신의 시스템에서 사용한 것과 같은 환경을 제공해 줄 수 있다.

+ Recent posts