Docker In Action 3. Software Installation Simplified
소프트웨어 식별하기
Named Repository 이름을 가진 저장소
image를 모아둔 저장소.
이미지 저장소에 대한 주소는 위 예시 처럼 url 형식으로 표현된다.
registry가 공개된 Docker Hub를 가리킬 경우 예시로 docker.io 호스트 이름을 가진다.
{RegistryHost}/{UserName}/{ShortName}:{Tags}
Tags
각 이미지에 대한 빌드 태그(이름), git의 브랜치처럼 특정 기능 혹은 날짜에 대한 별칭을 의미.
latest라는 특별 태그는 항상 최신으로 빌드된 이미지를 뜻 함.
ex) nginx:latest
어디서 설치 하는가
Repositories는 Registry에서 검색하여 이미지를 확인하고 설치할 수 있다.
Docker Inc에서 관리하는 Docker Hub는 공개된 registry로 docker pull과 docker run을 이용할 때 검색하게 되는 기본 registry이다.
도커 이미지 검색하기
docker search
검색된 이미지 이름, 설명, 받은 스타 개수, 공인 여부, 자동화된 빌드 버전 정보를 알 수 있다.
Docker Hub에서 확인하기
도커허브 레지스트리에 등록된 이미지를 공식 사이트 주소에서 확인 가능하다.
비공식 registry에서 이미지 받기
도커는 registry를 호스팅하는 소프트웨어를 제공한다. 직접 registry를 호스팅하여 자신의 이미지를 등록하여 비공개된 방식으로 이미지를 관리할 수 있다.
docker pull [REGISTRYHOST]/[USERNAME]/[NAME](:TAG)
비공식 레지스트리에서 이미지를 직접 받는 경우 필요한 정보가 담긴 repository 저장소 주소를 명시한다.
이미지를 파일로 저장하고 로드하기 save & load
- 이미지를 비디오 게임의 세이브 파일 처럼 파일로 save 및 load 하는 것이 가능하다.
docker pull busybox:latest // 공개 registry에서 busybox의 latest 태그 버전 이미지를 로컬로 가져온다.
dcoker save -o myfile.tar busybox:latest // 로컬 이미지를 myfile.tar 아카이브 파일로 내보낸다. (export)
docker rmi busybox // 로컬 이미지 삭제
docker load -i myfile.tar // 아카이브 파일로 부터 이미지를 불러온다.
docker images // 불러온 이미지 확인
Dockerfile로 부터 설치하기
docker build -t dia_ch3/dockerfile:latest ch3_dockerfile
dockerfile에 이미지 설치에 필요한 정보를 작성한다.
docker build {image_name} 명령어를 통해 도커 이미지를 설치할 수 있다.
-t 옵션은 이미지를 설치할 때 부여할 tag이다. 최종 설치되는 이미지는 [image_name]{:Tag} 로 설치된다.
어떤 파일이 설치되고 어떻게 분리되는 가
docker pull dockerinaction/ch3_myapp
docker pull dockerinaction/ch3_myotherapp
서로 다른 이미지를 설치해보자. 두번째 이미지는 첫번째 이미지를 설치할 때보다 빠르게 설치된다.
두 이미지는 모두 openjdk:11.0.4-jdk-slim image base로 사용하는데, ch3_myapp 이미지를 설치할 때 공통 부분을 설치하므로 ch3_myotherapp 이미지에서는 나머지 작은 부분만 설치되기 때문이다.
도커 이미지의 구성 Layer relationships
도커의 이미지는 layer 형식으로 이미지의 부모/자식 layer image가 있을 수 있다.
도커의 이미지는 명명된 태그 형식으로 저자가 배포 전 이름을 부여할 수 있다. (docker image -t ...)
태그가 없다면, 이미지가 생성될 때 UID가 부여되며 전체 UID 중 일부 12자를 사용한다. (도커 내부에서는 65자)
두 예시의 이미지는 모두 openjdk:11.0.4-slim를 기본 이미지로 (parent image) 한다.
컨테이너 파일 시스템 추상화와 고립
컨테이너 내부에서 실행되는 프로그램은 이미지 레이어에 대한 것과 분리한다. 도커는 union file system(UFS)를 이용하여 여러 UFS 중 호스트의 시스템에 최적화된 방법을 선택한다. UFS가 컨테이너 마다 고유의 파일 시스템을 분리하는 데 중요한 역할을 한다면, 나머지 는 MNT namespace와 chroot system call 이다.
도커는 리눅스 커널이 제공하는 MNT system의 namespace 기능을 이용하여 컨테이너를 만들고 고유의 MNT system를 갖도록 한다. 컨테이너에 고유 MNT namespace를 제공하며 마운트 지점이 생성된다.
마지막으로 chroot는 이미지 파일 시스템의 root를 container 관점에서의 root로 만든다. 이는 컨테이너가 다른 호스트 파일을 접근하지 못 하도록 한다.
union file system의 취약성
도커는 실행되는 파일 시스템에 맞는 파일 시스템을 선택하나 모든 워크로드에 완벽한 기능을 동작을 보장하지는 못 한다. 다른 파일 시스템은 속성, 사이즈, 이름, characters 등 다른 특징을 가질 수 밖에 없고 union file system은 적절한 파일 시스템간 translation을 제공해야한다. 또한 union file system은 linux 기능인 copy-on-write과 memory-mapped- files 기능을 사용하기 어렵게 한다.
도커에게 특정한 파일 시스템을 이용하는 옵션 --storage-driver를 이용하여 도커 데몬 서비스를 실행 해야할 수도 있다. UFS에 대한 쓰기 작업이 storage provider를 지정하지 않았을 때, 많은 이슈가 발생할 수 있다.
참고 : Docker In Action, 2nd Edition by Nickoloff Kuenzli