Docker Image
도커 이미지는 컨테이너를 만들기 위한 압축파일 개념임
이미지는 한번 만들어지면 이미지 내의 정보는 절대 변하지 않으며(불변성), 이미지를 통해 컨테이너를 만들 수 있음
이미지는 컨테이너를 만들었다고 사라지지 않고, 하나의 이미지로 여러개의 컨테이너를 만들 수 도 있음
이미지를 만들기 위해서는 dokckerfile을 작성해야 함
Layer 도입
도커 이미지는 컨테이너를 생성하기 위한 모든 정보를 갖고 있기 때문에 보통 수백MB ~ 수GB가 넘음 (VM에 비해서는 상당히 작은 용량)
그런데 기존 이미지에서 작은 변경 사항이 생겨 도커 파일에 코드 한 줄을 추가해 다시 이미지를 만들고 그 이미지를 다운로드 받는다고 가정
→ 겨우 코드 한줄 추가했는데 이미지의 불변성 때문에 수백MB ~ 수GB가 되는 이미지를 다시 다운로드 받는 것은 매우 비효율적인 방법임
→ Docker는 이러한 문제를 해결하기 위해 Layer(레이어)라는 개념을 도입함
Layer
기존 이미지에 추가적인 파일이 필요할 때 다시 다운로드 받는 방법이 아닌 해당 파일을 추가하기 위한 개념

javascript위 그림은 ubuntu와 nginx는 A B C 레이어가 동일하고 nginx 레이어만 다름 만약 ubuntu 이미지가 기존에 존재하는데 nginx 이미지를 다운 받을 경우 nginx 레이어만 다운받게게 됨
Docker 이미지는 여러 레이어로 구성되며, 각 레이어는 이전 레이어의 변경 사항을 가지고 있음
이 여러 개의 레이어에는 읽기 전용인 read only 레이어와, 새로 변경되거나 추가된 내용을 담은 새로운 레이어로 구성됨
도커 이미지에 작업이 추가되면 새로운 레이어가 생성되는 이러한 개념은 Git 레포지토리에 commit 로그를 쌓는 것과 같다고 볼 수 있음
기존에는 이미지에 변경사항이 생겨 새 이미지를 받아와야 되었음
이제는 레이어 개념을 통해 기존 레이어는 그대로 둔 채 새로 업데이트된 내용만 담고 있는 레이어만 쌓는 개념으로 관리를 하기 때문에 효율적임
업데이트된 부분만을 이미지로 생성하고 실행 시점에 기존 이미지를 바뀐 부분과 조합하기 때문에 바뀐 이미지의 크기는 큰 변화가 없음 (Git 레포지토리에서 업데이트된 코드를 pull 받는 것과 같음)
이미지를 실행하여 도커 컨테이너를 생성할 때도 레이어 방식을 사용함
컨테이너 생성 시, 기존의 읽기 전용 이미지 레이어 위에 읽기/쓰기 전용 레이어(R/W layer) 를 추가함
이미지 레이어를 그대로 불변의 레이어로 사용하면서, 컨테이너가 애플리케이션 실행 중에 생성하는 모든 파일이나 변경사항은 읽기/쓰기 전용 레이어에 저장되므로 여러 개의 컨테이너를 실행하면서이미지는 불변성을 유지할 수 있음
Docker 레이어의 특징
레이어 격리
- 각 레이어는 독립적인 파일 시스템으로, 각 레이어에 애플리케이션과 종속성에 대한 변경 사항만 포함됨
레이어 재사용
- 동일한 레이어를 여러 이미지에 공유할 수 있음
- 이를 통해 이미지 빌드 시간과 저장소 사용량을 줄일 수 있음
레이어 버전 관리
- 레이어를 생성할 때마다 새로운 버전이 만들어짐
- 이렇게 되면, 이미지 업데이트 시에도 이전 버전의 레이어를 유지할 수 있어, 애플리케이션의 변경 이력을 관리할 수 있음
Dockerfile 기반 레이어 생성
- Dockerfile에서 작성된 명령어들이 각각 실행될 때마다 새로운 레이어가 만들어짐
- 이렇게 하여 애플리케이션과 그에 상응하는 설정, 라이브러리, 종속성 등의 변경 사항을 추적할 수 있음
Docker 레이어의 작동 원리
- Docker 이미지를 생성할 때, Dockerfile을 사용하여 이미지 레시피를 정의
- Dockerfile에 기술된 명령어들이 순서대로 실행
- 각 명령어가 실행될 때마다 새로운 레이어가 생성되고, 변경 사항이 레이어에 저장
- Docker 이미지를 실행할 때, 해당 이미지의 모든 레이어가 연결되어 전체 파일 시스템을 구성
- 이렇게 하여 실행하는 컨테이너는 모든 레이어의 데이터에 액세스할 수 있음
- 컨테이너 내에서 변경해 저장한 것은 컨테이너의 최상단 레이어에 저장되며 이미지의 레이어에는 영향을 주지 않음