2019.04.20 - Docker Image와 Image layer, Image를 통해 실행할 때 발생하는 상황
1. What is image?
- 공식 설명으로는 An Image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime.
- 야매로 이해하자면 App 바이너리와 디펜던시 + 메타데이터와 이미지를 실행하는 방법을 포함하는 것이다.
- 컨테이너에서 이미지를 실행한다는 것은 VM에서 프로세스를 실행하는 것과 다르다고 했다. 컨테이너를 통해 이미지를 띄워서 실행하면 Full OS를 부팅하지 않고 커널은 호스트에서 제공한다는 점이 VM과 크게 다른 점이다.
- 그래서 컨테이너는 그냥 프로세스에 가깝다. 파일 크기는 아주 작을수도 있고 클 수도 있고!
command)
docker image ls
go to hub.docker.com -> can find the tag and you can download the image of your choice specifying the version.
(docker image pull mongo:3.6 < will download the exact one)
2. Image layer?
- 이미지라는게 하나의 거대한 바이너리들은 아니다.
- COW(copy on write) 컨셉을 사용.
COW란, write를 하는 시점에 이전에 있는 것들을 copy한다는 것인데 말 그대로 복붙하는게 아니라 기존의 자원 위에 새로운 레이어를 두고 쓴다고 생각하면 되겠다.
- 이미지 레이어 컨셉을 쓴다. 처음 업로드를 할 때 레이어가 만들어지고 그 위에 수정이 가해지면 또 이미지 레이어가 생기고. 계속계속 올라가고 생겨난다. 마치 git의 커밋 내역이 생겨난다.
- 모든 레이어는 각각의 유니크한 SHA를 가진다.
- 우분투 이미지(레이어) 위에 Apt를 설치하고 그 위에 환경변수를 바꿨다면 이 모든 것들이 하나의 이미지이다.
- 만약 하나의 이미지가 있는데 그 이미지에 수정을 가하고 싶으면 새롭게 처음부터 같은 스택을 쌓는 것이 아니고 이 전에 있던 이미지 레이어를 사용한다.
- 커스텀이미지 > 아파치 > 포트 80 오픈 > 사진 1 and 사진 2 :
사진 1,2는 두 개가 다르고 우리는 2개를 다른 서버에서 각각 서빙하고 싶다. 이 때 도커는 총 5개의 레이어만 저장된다. 사진 1, 2를 위해 이전의 스택들을 다시 저장할 필요가 없다.
3. 컨테이너에서 이미지를 실행할 때 발생하는 상황?
컨테이너에서 아파치 이미지를 실행한다 가정하면, 마치 우리 눈에는 그냥 파일들을 실행하는 것 같지만 도커는 레이어링을 한다.
아파치 이미지를 3개의 컨테이너가 실행한다 치자.
컨테이너 1,2는 그냥 돌리는데 3은 아파치 이미지 안에 있는 파일의 일부를 변경해서 실행하고 싶다하면?
-> 아파치 이미지와 컨테이너 3 사이에 어떤 레이어가 생기고 그 레이어에서 파일의 변경점을 인식해서 실행한다.
결론적으로 1,2,3은 모두 같은 이미지를 쓰지만 실행환경은 다를 수 있다는 것이다.
4. 이미지 검사하기
docker image inspect IMAGE 를 하면 해당 이미지의 메타정보가 나온다.
이미지의 구성요소 기억하는가? 이미지 파일과 디펜던시 그리고 메타정보들이었다.
이것들을 확인할 수 있다. 대표적으로 아이디, 환경변수, 실행시 기본동작하는 커맨드 등...
리뷰:
이미지는 파일시스템의 변경점과 메타데이터로 이루어져있다.
각 레이어는 유니크하게 아이덴티파이되며 호스트에 딱 한 번 저장이된다.
덕분에 push/pull하는데 시간도 적게들고 호스트 피씨의 스토리지도 적게 차지한다.
컨테이너는 그냥 하나의 read/write 레이어이고 이 레이어가 이미지 위에서 동작하는 거다.
docker image history / docker image inspect IMAGE가 관련 커맨드다.
- 공식 설명으로는 An Image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime.
- 야매로 이해하자면 App 바이너리와 디펜던시 + 메타데이터와 이미지를 실행하는 방법을 포함하는 것이다.
- 컨테이너에서 이미지를 실행한다는 것은 VM에서 프로세스를 실행하는 것과 다르다고 했다. 컨테이너를 통해 이미지를 띄워서 실행하면 Full OS를 부팅하지 않고 커널은 호스트에서 제공한다는 점이 VM과 크게 다른 점이다.
- 그래서 컨테이너는 그냥 프로세스에 가깝다. 파일 크기는 아주 작을수도 있고 클 수도 있고!
command)
docker image ls
go to hub.docker.com -> can find the tag and you can download the image of your choice specifying the version.
(docker image pull mongo:3.6 < will download the exact one)
2. Image layer?
- 이미지라는게 하나의 거대한 바이너리들은 아니다.
- COW(copy on write) 컨셉을 사용.
COW란, write를 하는 시점에 이전에 있는 것들을 copy한다는 것인데 말 그대로 복붙하는게 아니라 기존의 자원 위에 새로운 레이어를 두고 쓴다고 생각하면 되겠다.
- 이미지 레이어 컨셉을 쓴다. 처음 업로드를 할 때 레이어가 만들어지고 그 위에 수정이 가해지면 또 이미지 레이어가 생기고. 계속계속 올라가고 생겨난다. 마치 git의 커밋 내역이 생겨난다.
- 모든 레이어는 각각의 유니크한 SHA를 가진다.
- 우분투 이미지(레이어) 위에 Apt를 설치하고 그 위에 환경변수를 바꿨다면 이 모든 것들이 하나의 이미지이다.
- 만약 하나의 이미지가 있는데 그 이미지에 수정을 가하고 싶으면 새롭게 처음부터 같은 스택을 쌓는 것이 아니고 이 전에 있던 이미지 레이어를 사용한다.
- 커스텀이미지 > 아파치 > 포트 80 오픈 > 사진 1 and 사진 2 :
사진 1,2는 두 개가 다르고 우리는 2개를 다른 서버에서 각각 서빙하고 싶다. 이 때 도커는 총 5개의 레이어만 저장된다. 사진 1, 2를 위해 이전의 스택들을 다시 저장할 필요가 없다.
3. 컨테이너에서 이미지를 실행할 때 발생하는 상황?
컨테이너에서 아파치 이미지를 실행한다 가정하면, 마치 우리 눈에는 그냥 파일들을 실행하는 것 같지만 도커는 레이어링을 한다.
아파치 이미지를 3개의 컨테이너가 실행한다 치자.
컨테이너 1,2는 그냥 돌리는데 3은 아파치 이미지 안에 있는 파일의 일부를 변경해서 실행하고 싶다하면?
-> 아파치 이미지와 컨테이너 3 사이에 어떤 레이어가 생기고 그 레이어에서 파일의 변경점을 인식해서 실행한다.
결론적으로 1,2,3은 모두 같은 이미지를 쓰지만 실행환경은 다를 수 있다는 것이다.
4. 이미지 검사하기
docker image inspect IMAGE 를 하면 해당 이미지의 메타정보가 나온다.
이미지의 구성요소 기억하는가? 이미지 파일과 디펜던시 그리고 메타정보들이었다.
이것들을 확인할 수 있다. 대표적으로 아이디, 환경변수, 실행시 기본동작하는 커맨드 등...
리뷰:
이미지는 파일시스템의 변경점과 메타데이터로 이루어져있다.
각 레이어는 유니크하게 아이덴티파이되며 호스트에 딱 한 번 저장이된다.
덕분에 push/pull하는데 시간도 적게들고 호스트 피씨의 스토리지도 적게 차지한다.
컨테이너는 그냥 하나의 read/write 레이어이고 이 레이어가 이미지 위에서 동작하는 거다.
docker image history / docker image inspect IMAGE가 관련 커맨드다.
댓글
댓글 쓰기