[Docker] 도커 이미지 다루어보기, 그리고 Dockerfile

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.

 

Docker

---

이번 포스팅에서는 도커 이미지에 대해 알아보고, 이미지를 다루어보는 방법에 대해 알아보자. 그리고 나만의 이미지를 만드는 데 활용되는 Dockerfile에 대해서도 배워보자. 참고로 Dockerfile에 대해서는 얕게나마 생활코딩 강의를 통해 배운적이 있었다. Dockerfile이 무엇인지에 대해 모른다면 간단히 이전 포스팅을 읽고 오는 것도 좋을 듯 하다.

1. 도커 이미지를 생성하자, docker commit

리눅스 배포판 중 Ubuntu는 패키지를 apt 레포지토리에서, CentOS는 패키지를 yum 레포지토리에서 설치하는 것처럼, 또 Python의 패키지는 pypi 라는 레포지토리 또는 anaconda 레포지토리로부터 설치하는 것처럼 도커도 기본적으로 이미지를 설치받을 수 있는 레포지토리가 존재한다. 그것은 바로 Docker Hub이다. 이전 포스팅에서 잠시 다루긴 했지만, 여기서도 복습차 다시 배워보도록 하자.

 

도커 허브는 누구든지 자신만의 이미지를 만들어서 올릴 수 있다. 그래서 남이 올린 이미지를 손쉽게 다운받아 사용할 수 있다. 하지만 공식(Official) 라벨이 없는 이미지는 사용법을 찾을 수 없거나 제대로 동작하지 않을 수 있다. 도커 허브에 어떤 이미지가 있는지 확인하기 위해서는 Docker Hub 사이트에 가서 검색할 수도 있지만 도커 엔진에서도 docker search 관련 명령를 사용할 수도 있다. 참고로 search 관련 명령어는 이전에 리눅스에서 yum, apt에서도 search 명령어가 존재한다. 

 

그러면 이제 도커 이미지를 생성해보자. 도커 이미지만을 다운로드 받는 것은 docker pull 명령어로 내려받을 수 있다. 하지만 이것은 단지 정말 '이미지 만을 다운로드'받는 것만 한다. 그런데 보통 도커로 개발하는 경우에는 만든 컨테이너에 내가 제작한 애플리케이션을 구축한 후, 나만의 이미지를 직접 생성하는 경우가 흔하다. 따라서 여기서는 docker run 명령어를 사용해서 우분투 이미지를 다운받고 그 이미지로부터 나만의 컨테이너를 성생해보도록하자. 그리고 그 컨테이너 안으로 들어가서 zedd.txt 라는 파일을 하나 생성한 뒤, 다시 호스트로 빠져나와보자.

 

$ docker run -it --name create_container ubuntu:20.04
# echo "Hello zedd" >> /zedd.txt
# exit

 

이제 호스트로 나왔다면 위에서 만든 create_container 라는 이름의 나만의 컨테이너를 이미지로 만들어보자. 사용하는 명령어는 docker commit 명령어이다. commit 명령어는 다음과 같은 명령어 형식을 갖는다.

 

$ docker commit [OPIONS] CONTAINER [REPOSITORY[:TAG]]

 

위에서 [REPOSITORY:[TAG]] 라는 것은 이전 포스팅 [2-1.목차] 에서 배운적이 있으므로 설명은 생략하겠다. commit의 OPTIONS 종류에는 여러가지가 있긴 하지만, 여기서는 -a와 -m 옵션만 알아보자. -a는 해당 컨테이너를 이미지로 만든 사람이 누구인지 즉, 저자(author)가 누구인지 표시를 한다. 그리고 -m 은 git을 사용할 때 커밋 메세지를 첨언하는 것처럼, 도커 commit 에서도 메세지를 남길 수 있는 옵션이다. 그러면 호스트에서 아래 명령어를 통해 zedd_image라는 이름의 나만의 이미지를 만들어보자.

 

$ docker commit \
-a "zedd" \
-m "create zedd's own image" \
create_container \
zedd_image:v1

 

그리고 생성한 이미지 목록을 출력해보면 아래와 같이 나만의 이미지가 생성되었음을 알 수 있다.

 

zedd_image:v1 이라는 이미지가 새로 생성되었다!

2. 도커 이미지 구조 파헤치기

도커 이미지를 좀 더 효율적으로 다루기 위해서는 내가 생성한 도커 이미지가 어떤 구조로 이루어져있는지 이해할 필요가 있다. 우선 일종의 환경 세팅이 필요하다. 위에서 만든 zedd_image:v1 이라는 이미지를 기반으로 해서 컨테이너를 만들고, 이 컨테이너에 약간의 변경사항을 적용한 후 나만의 또 다른 이미지로 만들어보자. 이미지 이름은 zedd_image:v2로 생성하겠다. 1번 목차의 명령어에 이어 아래 명령어를 실행하자.

 

$ docker run -it --name create_container_v2 zedd_image:v1
# echo "Hello zedd 2" >> /zedd_v2.txt
# exit
$ docker commit \
-a "zedd" \
-m "create zedd's own second image" \
create_container_v2 \
zedd_image:v2

 

그리고 도커 이미지 목록을 출력하면 아래처럼 3개의 이미지가 존재한다.

 

 

그러면 위 3개의 이미지에 대한 메타정보 데이터를 docker inspect 명령어로 확인헤보자. 메타정보는 여러개가 있지만 우리는 그중에서 Layers에 대한 부분만 보고 싶다.(참고로 이미지는 Layer들로 구성됨) 아래의 Layer들의 구체적인 해쉬값은 실습에 따라 값이 달라질 수 있음을 알아두자.

 

3개의 이미지 각각의 Layers 구조를 보자

 

위 Layers 메타 정보를 비교해보자. 이전에 도커 컨테이너를 생성할 때 도커 이미지는 읽기 전용으로 바뀌며 컨테이너에서 변경된 사항만 별도로 저장한다고 했다. 그 의미를 여기서도 확인할 수 있다. ubuntu:14.04에서 갖고 있는 3개의 Layer 정보는 zedd_image:v1 의 Layer 중 3개를 차지하고 있음을 알 수 있다. 그리고 나머지 1개 Layer(노란색 선)가 추가되었는데, 이것은 우리가 zedd_image:v1 이미지를 생성할 때 활용했던 컨테이너에다가 zedd.txt 라는 파일을 하나 생성했던 것(변경 사항)에 대한 Layer이다. 마찬가지로 zedd_image:v2 이미지는 zedd_image:v1 이미지를 기반으로 생성된 컨테이너로부터 만들어진 것이므로 이번엔 공통적으로 4개의 Layer 정보를 갖고 있다. 그리고 zedd_2.txt 라는 파일을 생성했기 때문에 파란색 선의 Layer가 추가된 것을 볼 수 있다. 참고로 위와 같이 inspect 명령어가 아닌 history 명령어를 사용해서도 도커 이미지의 구조를 알아볼 수 있다.

 

도커 이미지 구조에서 한 가지 더 알아볼 원리가 있다. 이는 생성한 도커 이미지를 삭제하면서 이해해볼 수 있다. 우선 도커 이미지를 삭제하기 위해서는 해당 이미지를 기반으로 운용되고 있는 컨테이너들을 모두 멈추고 삭제시켜야 한다. 물론 docker rm -f 옵션을 주어 이미지를 강제로 삭제할 수도 있지만, 이는 이미지를 구성하는 레이어 파일을 실제로 삭제시키는 것이 아닌 단순히 '이미지 이름만' 삭제하기 때문에 실질적인 삭제를 수행하지는 않는다. 참고로 docker rm -f 옵션을 넣어 이미지를 삭제하면 이미지 이름이 삭제되어 이미지 이름이 <none> 으로 바뀌게 된다. 이러한 이미지들을 댕글링(dangling) 이미지라고 부른다. 만약 댕글링 이미지만을 출력해 보고 싶다면 docker images -f dangling=true 라는 명령어를 사용하면 된다.

 

그러면 이제 위 3가지 이미지 중 zedd_image:v1 이라는 이미지를 삭제시켜보자. zedd_image:v1 이미지를 삭제하기 위해서는 해당 이미지를 기반으로 돌아가고 있는 create_container_v2 라는 컨테이너를 먼저 삭제시켜야 한다.

 

$ docker rm create_contaeinr_v2
$ docker rmi zedd_image:v1

 

그러면 아래와 같이 "Untagged: ... " 라는 메세지만 발생한 것을 알 수 있다.

 

 

이 메세지만 발생했다는 것은 이미지의 실제 레이어 파일이 삭제되지는 않았다는 것을 의미한다. 왜냐하면 해당 이미지를 부모로 하고 있는 다른 이미지가 현재 존재하고 있기 때문이다. 즉, 위 예시에서는 현재 zedd_image:v2가 zedd_image:v1 이미지를 부모로 하고 있기 때문이다. 이렇게 되면 이미지에 부여된 이름만 삭제했다는 뜻이다. 

 

그러면 다음으로 zedd_image:v2 이미지를 삭제해보자. 현재 zedd_image:v2 를 부모로 하는 별도의 이미지를 생성한 적이 없기 떄문에 아래와 같이 zedd_image:v1 때와는 다른 출력 메세지가 표시되는 것을 알 수 있다.

 

이번엔 "Deleted" 라는 메세지도 출력됨

 

위처럼 "Deleted ..." 라는 출력 결과가 나오면 해당 이미지의 레이어 파일이 실제로 삭제되었음을 의미한다. 위 결과의 가장 첫번쨰 "Deleted.." 에 있는 해쉬값 ID는 zedd_image:v2를 가리키는 ID값이며, 그 밑에 3개의 해쉬값들은 해당 이미지의 실제 레이어 파일을 가리키는 ID들이다. 그런데 여기서 한 가지 주의할 점이 있다. 이번에 삭제한 zedd_image:v2 라는 이미지는 어쨌건 가장 상위 부모는 ubuntu:14.04 라는 이미지이다. 그런데 zedd_image:v2 라는 이미지를 삭제했음에도 ubuntu:14.04 이미지는 삭제되지 않았다. 왜냐하면 삭제하는 zedd_image:v2 라는 이미지를 삭제할 때 함께 삭제되는 범위에 ubuntu:14.04 이미지는 포함되지 않기 때문이다. 

 

좀 헷갈릴 수도 있는데, 특정 이미지를 삭제하려면 아래와 같이 2가지만 기억하면 된다! (https://github.com/alicek106/start-docker-kubernetes/issues/15)

 

3. 도커 이미지도 파일처럼 추출하고 로드하자

도커 이미지를 구성하는 레이어들도 실질적으로는 파일 형태로 되어 있다. 따라서 별도로 저장하거나 옮기기 위해 도커 이미지를 단일 바이너리 파일 형태로 저장할 수도 있다. docker save 명령어를 활용하면 컨테이너의 커맨드, 이미지 이름과 태그 등 이미지의 모든 메타 정보를 포함하는 하나의 파일로 추출이 가능하다. -o 옵션에는 추출하여 만들 파일 이름을 명시해주면 된다.

 

$ docker save -o [이미지 추출 파일 이름] [IMAGE]

 

이렇게 파일로 추출한 뒤, load 명령어로 도커에 다시 해당 이미지를 로드할 수 있다. -i 옵션 뒤에 추출한 파일 이름을 명시해주면 된다.

 

$ docker load -i saved_image.tar

 

save, load 명령어와 유사한 동작을 하는 명령어로, export, import 명령어도 존재한다. 하지만 차이점이 존재한다. 우선 export 명령어는 컨테이너에 대해 수행해야 한다. 왜냐하면 export는 컨테이너에 대한 메타 정보들을 모두 포함해서 저장하는 것이 아니라 단지 컨테이너의 파일시스템을 tar 파일로 추출하기 때문이다. 즉, 파일 시스템은 이미지가 아닌 컨테이너 상태에서만 존재하기 때문에 export 명령어를 컨테이너에 대해서 수행해야 한다고 한 것이다. 이제 반대로 import 명령어를 통해 export로 추출한 tar 파일을 로드할 수 있다. 단, import로 로드하고 난 뒤에는 해당 tar 파일이 컨테이너가 아닌 이미지 형태로 만들어짐을 알아두자.(사실 컨테이너 상태로 만들어질 수가 없음)

 

$ docker export -o container.tar [CONTAINER]
$ docker import container.tar [생성할 IMAGE 이름]

 

하지만 이렇게 이미지 또는 컨테이너를 단일 파일로 저장하는 것은 효율적인 방법이 아니다. 왜냐하면 추출된 이미지는 레이어 단위로 파일이 구성되어 있는 것이 아닌 단일 파일 형태로 되어 있기 때문이다. 그래서 이미지 용량을 각기 차지하게 된다. 예를 들어, 아래와 같이 3개의 이미지가 존재하고, 각각을 파일 형태로 추출한다고 가정해보자.

 

 

위 3개의 이미지는 공통적으로 Ubuntu:14.04 이미지를 모두 하나의 부모로 삼고 있기 때문에 공통적인 레이어가 존재한다. 여기서 만약 3개 이미지를 각각 파일 형태로 추출하게 되면 공통적인 레이어의 용량이 3개씩 중복되서 추출되므로 파일 용량 측면에서 비효율적임을 알 수 있다.

 

4. 나만의 이미지 배포해보기

이번 목차에서는 내가 생성한 이미지를 다른 사람들도 갖다 사용할 수 있도록 배포하는 방법을 배워보자. 바로 직전 목차에서 배운 것처럼 개인이 만든 도커 이미지를 파일 형태로 추출하여 내가 공유하고 싶은 사람들에게 전송하거나 할 수도 있겠지만, 전송해야 할 상대방 수가 많아지거나 이미지 크기가 커질수록 이러한 방법은 매우 비효율적이게 된다. 이를 손쉽게 해결하기 위해 소스코드를 무료로 Github, Gitlab 플랫폼에 올려놓고 공유하는 것처럼 도커도 그러한 방법이 존재한다.

 

첫 번째 방법으로, 도커에서 공식적으로 제공하는 이미지 저장소인 Docker Hub를 이용하는 것이다. 이에 대해서는 이전에 간단하게 배워본 적이 있다. 도커 허브는 계정 가입이 무료이며 Public한 레포지토리는 무료로 무제한으로 이용이 가능하다. 단, Private한 레포지토리는 계정 당 1개까지 무료로 만들 수 있으며 그 이상의 Private 레포지토리를 만들려고 한다면 월 당 소정의 구독료를 내야 한다.

 

두 번째 방법으로는 도커 사설 레지스트리(Docker Private Registry)를 사용하는 것이다. 즉, 개인이 Docker Hub와 같은 이미지 저장소를 서버를 운용하여 만들 수 있다. 다만, 이럴 경우 사용자가 직접 이미지 저장소로 운영할 서버, 저장 공간, API 등과 같은 것을 모두 관리해야 한다.

 

만약 개인이나 조그마한 팀 단위(사이드 프로젝트 단위)로 개발을 진행한다면 Docker Hub를 이용하는 것이 나을 수 있다. 다만, 회사의 내부망과 같은 곳에서 도커 이미지를 배포해야 한다면 두 번째 방법인 도커 사설 레지스트리를 자체 구축하여 운영하는 것이 더 좋은 방안이 될 수 있다. 실제로, 구글이 운영하는 GCP에서는 gcr.io 라는 접두어로 운영하고 있는 Container Registry 프로덕트가 있고, Github에서는 ghcr.io 라는 접두어를 사용해서 일종의 컨테이너 레지스트리를 운영할 수 있다. 그리고 한국의 카카오에서는 D2hub 이라는 이름의 사설 레지스트리를 실제로 운영하고 있다.

 

이번 포스팅에서는 첫 번째 방법인 Docker Hub에 나만의 이미지를 업로드 하고 확인해보도록 하자. 우선 Docker Hub 계정이 없다면 가입해서 계정을 생성한다. 이 때, 가입할 때 명시하는 username은 추후에 내가 만든 이미지를 업로드 할 때 명시하는 Repository 이름에 같이 명시해주어야 하므로 기억해두자. 그리고 Public한 레포지토리를 하나 아래처럼 생성해보자. 이 때 레포지토리 이름은 내가 만들 이미지의 이름이 되야 한다. 필자는 아래와 같이 레포지토리를 생성했다. username은 jo181 이고, 레포지토리 이름은 zedd이다.

 

 

그리고 이제 VM의 우분투에서 ubuntu:14.04를 이미지로 하는 나만의 컨테이너를 생성한 뒤, 더미 파일을 하나 만들고 나만의 이미지로서 만들어보자. 나만의 이미지 이름은 아래와 같은 규칙을 반드시 따라야 한다.(규칙에 사용된 Repository, Image 이름은 필자 도커 계정에 맞춰서 작성함)

 

$ docker run -it --name zedd_container ubuntu:14.04
# echo "Hello Zedd!" >> zedd.txt
# exit
$ docker commit \
-a "zedd" \
-m "my own image for pushing to Docker Hub" \
zedd_container \
docker.io/jo181/zedd:v1

 

혹시라도 위에서 commit을 할 때, 이미지 이름 규칙을 지켰어야 했는데, 잘못해서 다른 이름으로 이미지를 생성했다고 한다면 docker tag 명령어를 사용해서 이미지의 이름을 추가할 수 있다.(이름을 변경하는 것이 아닌 이름을 추가하는 것)

 

$ docker tag [기존 이미지 이름] [새로 추가할 이미지 이름]

 

이제 다음 순서는 도커 허브에 로그인을 하면 된다. docker login [DNS 또는 IP 주소] 명령어를 입력하면 되는데, DNS 또는 IP 주소를 생략하면 디폴트로 도커 허브에 로그인을 시도한다. 참고로 도커 엔진에서 로그인한 정보는 호스트의 파일 시스템의 아래 경로에 있는 json 파일에 저장이 된다.

 

/호스트 계정명/.docker/config.json

 

필자는 아래와 같이 로그인이 성공되었음을 알 수 있으며 호스트의 root 계정으로 시도했기 때문에, 아래 노란색 네모칸 경로에 도커 허브 로그인 정보가 기록되었음을 알 수 있다.

 

 

그러면 이제 push 명령어로 도커 허브에 내 이미지를 업로드시켜보도록 하자. push 명령어는 아래와 같은 형식으로 사용하면 된다. 여기서 도커 허브에서의 username과 레포지토리 이름을 반드시 명시해주어야 우리가 원하는 곳에 이미지를 잘 업로드할 수 있게 된다.

 

$ docker push [REPOSITORY[:TAG]]

 

 

그런데 특이한 점이 있다. 위 출력화면을 보아하니 해쉬값으로 표시된 레이어들 4개중 맨 상단의 1개 레이어만 제외하고 나머지는 Ubuntu 로부터 마운트되었다고 한다. 이는 이미 도커 허브에 Ubuntu:14.04 라는 이미지의 레이어들이 존재하기 때문에 내가 Ubuntu:14.04를 기반으로 만든 새로운 이미지를 push 한다고 해도 이미 존재하는 레이어들은 도커 허브에 있는 것을 가져다 쓰는 것이다! 위에서 zedd.txt 라는 파일을 생성한 후 이미지를 만들었기 때문에 맨 상단의 1개 레이어만 Push 된 것을 알 수 있다. 그렇다면 이제 잘 업로드 되었는지 도커 허브 레포지토리를 가보자.

 

 

v1 이라는 태그 이름을 가진 이미지가 업로드 된 것을 볼 수 있다! 그런다음 이제 도커 허브에 올라간 저 이미지를 누군가의 호스트 도커 엔진에서 다운받고(pull) 싶다면 아래와 같은 형식의 pull 명령어를 사용하면 된다.

 

$ docker pull docker.io/jo181/zedd:v1

 

그 이외 기타적으로 도커 허브에서는 Github처럼 조직 단위로 레포지토리를 구성할 수 있고, 조직 내에서도 팀 단위로 만들어 어떤 팀에겐 특정 권한을 주고 안주고 하는 권한 분리 및 할당도 가능하다. 또한 특정 이미지 레포지토리(저장소)에 새로운 이미지가 업로드되면 특정 URL로 http 요청을 전송하도록 하는 웹훅(WebHook)도 만들 수 있다. 

 

책에서는 도커 허브가 아닌 도커 사설 레지스트리를 만들어서 운영하는 방법도 소개한다. 책으로 읽어서 어느정도 공부하긴 했지만, nginx와 같이 필자가 접해보지 못했던 개념이 나와서 해당 포스팅에서는 담지 않고 추후에 도커 관련 실력이 많이 늘었을 때 다시 들여다보고자 한다. 만약 도커 사설 레지스트리를 만드는 방법에 대해 지금 당장 궁금하다면 책 원본을 꼭 읽어보길 권장한다.

5. 나만의 이미지를 생성하는 또 다른 방법, Dockerfile

4번 목차까지 내용으로 해서 나만의 이미지를 생성하는 방법 및 순서는 아래와 같다.

 

1. 도커 허브와 같은 레지스트리로부터 Ubuntu, CentOS와 같은 이미지를 기반으로 컨테이너를 생성
2. 생성한 컨테이너 안에 내가 구현하고자 하는 애플리케이션(소스코드 등..)을 설치
3. 해당 컨테이너를 커밋(commit) 하며 나만의 이미지로 생성

그런데 만약 이러한 방법을 사용해서 나만의 이미지를 생성한다고 하면, 매번 내가 구현시킬 애플리케이션이 동작하는 환경이나 소스코드 등을 생성한 컨테이너에 복사, 붙여넣기를 해야만 한다. 간단한 로직의 애플리케이션이면 소스코드도 적을 것이다 보니 복사, 붙여넣기 하는 데도 비교적 간단한 일일 것이다. 하지만 로직이 복잡해지며 애플리케이션이 커짐에 따라, 일일이 소스코드를 옮기는 것은 여간 피곤할 일이 아닐 것이다.

 

그래서 도커는 이러한 피곤한(?) 일련의 과정을 손쉽게 기록하고 수행할 수 있는 build 명령어가 존재한다. 이 build 명령어로 나만의 이미지를 만들기 위해 컨테이너에 설치해야 하는 패키지, 소스코드 등을 기록한 하나의 파일을 읽어들여 이미지로 만들어낼 수 있다. 그리고 이 '하나의 파일'이 바로 Dockerfile이다. 이렇게 Dockerfile과 build 명령어를 사용하게 되면 위에서 언급한 귀찮은 과정을 덜어낼 수 있으며 Git과 같은 개발 도구를 활용해서 애플리케이션의 빌드 및 배포를 자동화할 수도 있다.

 

Dockerfile은 애플리케이션 개발을 위한 용도 이외에 여러 목적으로 사용할 수 있다. 그 중 하나로, 도커 허브와 같은 레지스트리에 나만의 이미지를 배포할 때 이미지 자체를 배포하는 것 대신 그 이미지에 대한 Dockerfile 파일을 배포할 수도 있다. 그렇게 되면 또 다른 사용자는 도커 허브에 올려져 있는 Dockerfile 파일을 가지고 그 이미지를 손쉽게 만들어낼 수 있다. 보통 이렇게 Dockerfile을 이용하는 경우는 배포되는 이미지를 신뢰할 수 없수 없을 경우에 사용한다고 한다. 또한 Dockerfile 파일을 이용하면 해당 이미지를 만들기 위해 어떤 패키지 및 소스코드를 사용했는지 일종의 이미지 생성 내역을 기록할 수 있다.

5-1. Dockerfile 명령어 익혀보기

Dockerfile을 그러면 직접 작성해보면서 Dockerfile에 사용되는 명령어도 하나씩 배워보자. Dockerfile에는 컨테이너에서 수행할 작업을 한 줄씩 명령어로 명시한다. Dockerfile에서 사용되는 명령어는 단지 우리가 이전 포스팅에서 배운 것처럼 컨테이너를 CLI에서 다룰 때 사용하는 명령어를 알기 쉽게 변환한 것이다.

 

우선 도커 엔진이 설치된 호스트에서 zedd.html 이라는 파일을 임의로 하나 생성하고 아래 내용처럼 구성된 Dockerfile을 만들어보자.

 

$ mkdir dockerfile && cd dockerfile
$ echo zedd >> zedd.html

 

FROM ubuntu:14.04
MAINTAINER zedd
LABEL "purpose"="practice"
RUN apt-get update
RUN apt-get install apache2 -y
ADD zedd.html /var/www/html
WORKDIR /var/www/html
RUN ["/bin/bash", "-c", "echo zedd2 >> zedd2.html"]
EXPOSE 80
CMD apachectl -DFOREGROUND

Dockerfile 예시를 직접 입력

 

참고로 위 Dockerfile에 작성된 명령어는 소문자여도 상관없지만 관습적으로 대문자를 사용한다. 그리고 도커 엔진은 Dockerfile 파일을 읽어들일 때 기본적으로 현재 디렉터리에 있는 'Dockerfile' 이라는 이름의 파일을 읽어들인다. 다만, -f(--file) 옵션을 주어서 꼭 'Dockerfile'이 아닌 다른 이름으로 되어 있는 파일도 읽어들일 수 있도록 할 수 있다. 이에 대해서는 아래에서 배워보도록 하자.

 

명령어	의미	특징
FROM	베이스가 될 이미지를 의미	Dockerfile을 작성할 때는 반드시 한 번 이상 입력해야 함. 사용하려는 이미지가 로컬 호스트에 없다면 이미지를 다운로드(pull)함
MAINTAINER	나만의 이미지를 만든 개발자 정보를 의미	보통 이메일을 입력함. 단, 도커 1.13.0 버전 이후로는 deprecated 되었으며, 다른 명령어인 LABEL로 MAINTAINER 기능을 대체할 수 있음
LABEL	나만의 이미지에 메타데이터를 추가	메타데이터는 "key":"value" 형태로 마치 json처럼 저장이 되며 해당 이미지에 저장된 메타데이터를 살펴보기 위해서 docker inspect 명령어로 볼 수 있음 ex)예를 들어, 위에서는 "purpose"="practice" 라고 정의했는데, 이렇게 정의하면 실제 메타데이터에는 {"purpose": "practice"} 형태로 저장이 됨
RUN	나만의 이미지의 기반이 되는 컨테이너 내부에서 실행할 명령어를 의미	- 단, 특정 패키지 install 하는 명령어를 수행할 때 별도의 입력을 받아야 할 수 있기 때문에 -y 옵션을 주어야 함. 만약 별도의 입력을 받기 위해 대기해야 한다면 build 명령어가 이를 오류라고 인식함 - 단, RUN 명령어 시, JSON 배열의 형태로 명시해줄 수 있는데, Dockerfile의 명령어를 JSON 배열 형태로 명시한다면 반드시 셸을 동작시키는 명령어를 반드시 앞에 추가해야 함 ex) 예를 들어, RUN ["echo", "$MY_ENV"] 라고 하면 동작 하지 않지만, ["sh", "-c", "echo $MY_ENV"] 라고 명시하면 동작함. 위 예시 Dockerfile에서도 "/bin/bash" 로 bash 셸을 동작시키는 것을 볼 수 있음
ADD	특정 파일을 나만의 이미지에 추가	- 여기서 추가하는 파일은 기본적으로 Dockerfile이 위치한 디렉터리인 '컨텍스트(Context)'에서 가져옴 - 마찬가지로 JSON 배열 형식으로 지정할 수 있어 ADD할 여러개의 파일을 지정할 수 있음. 단, 배열의 마지막 원소가 해당 파일들을 추가할 컨테이너의 디렉토리 경로가 됨 ex) 예를 들어, ADD["zedd1.txt", "zedd2.txt", "index.html", "/zedd/test/"] 라고 한다면, 2개의 txt 파일과 1개의 html 파일을 컨테이너 내부의 "/zedd/test" 라는 디렉토리 경로에 추가함
WORKDIR	명령어를 실행할 디렉토리를 명시하고 그곳으로 이동을 의미	셸 프롬프트에서 cd(change directory) 명령어와 동일한 효과를 지님. 그래서 WORKDIR 명령어를 10번 쓰면 cd 명령어를 10번 쓰는 셈임
EXPOSE	Dockerfile 빌드로 생성한 나만의 이미지에서 노출할 포트를 의미	- 호스트 포트번호가 아닌 컨테이너 포트 번호임에 주의. 그래서 호스트의 어떤 포트번호와 바인딩되는지는 해당 명령어만 보고는 알 수 없음. - docker run 명령어에서 모든 노출된 컨테이너의 포트 즉, EXPOSE 에 명시한 모든 포트를 호스트에 각각 바인딩하는 즉, 퍼블리시하는 -P 플래그와 함께 사용
CMD	컨테이너가 시작될 때마다 실행될 명령어를 설정 (docker ps 명령어로 실행중인 컨테이너 목록 출력에서 COMMAND에 해당되는 것임)	- Dockerfile에서 한 번만 사용 가능 - CMD 명령어도 JSON 배열 형태를 인자로 받을 수 있음 - CMD는 ENTRYPOINT의 명령줄 인자로도 쓰일 수 있는데, 이는 추후에서 알아보도록 함

 

위 표 중 마지막 CMD 명령어에서 알아볼 사항이 2가지가 있다. 일단 첫 번째로, 위 예시에서 사용한 CMD apachectl -DFOREGROUND 라는 명령어의 의미이다. 해당 명령어에서 'D'는 Detached로, 백그라운드 잡으로 돌리는 것을 의미하고, FOREGROUND는 포그라운드 잡으로 돌리는 것을 의미한다. 여기서 2개가 다 같이 쓰인 이유는 '누구 입장'에서 해당 잡을 실행하느냐의 차이다. 즉, 해당 명령어를 실행하는 호스트 입장에서는 아파치 웹서버가 띄워져 있는 컨테이너를 백그라운드 잡으로 돌려야 하기 때문에 D를 붙인 반면, 컨테이너 입장에서는 아파치 웹서버가 하나의 터미널을 차지해야 하기 때문에 포그라운드 잡으로 돌려야 해서 FOREGROUND를 명시한 것이다. 

 

두번째로는 docker run 명령어를 실행할 때 이미지 이름 뒤에 커맨드와 같은 역할을 하는 것을 인자로 줄 수 있다는 것이다.(이전 포스팅에서 알아봄) 그런데 CMD 명령어가 입력된 Dockerfile로 만들어진 이미지라고 하더라도 만약 docker run 명령어를 통해 커맨드를 새롭게 입력하면 새롭게 입력한 커맨드로 덮어쓰기가 된다. 또한 애초에 베이스 이미지 예를 들어, 우분투, CentOS와 같은 공식 이미지에 내장되어 있는 COMMAND는 Dockerfile에 CMD를 명시함으로써 이미지에 내장된 COMMAND를 Dockerfile의 CMD로 덮어쓸 수가 있다.

5-2. Dockerfile 빌드하기

그러면 이제 위에서 작성한 Dockerfile 예시파일을 가지고 빌드해보자. 여기서 빌드해본다라는 것은 도커의 build 명령어를 이용해 Dockerfile에 명시된 내용을 기반으로 나만의 이미지를 만드는 것이다. 흔한 build 명령어 사용 형식은 다음과 같다.

 

$ docker build -t [repository:tag] [Dockerfile 위치 경로]

 

-t 옵션을 넣어주지 않으면 build 해서 만들 나만의 이미지 이름을 16진수의 해시값으로 자동 생성한다. 실제로 build 명령어를 수행후 이미지 목록을 출력하면 아래처럼 나오는 것을 볼 수 있다.

 

내 이미지를 빌드 명령어로 생성

 

그러면 이제 위에서 만든 나만의 이미지 즉, zedd_image:v1 이라는 이름의 이미지를 기반으로 컨테이너를 생성해보자.

 

$ docker run -d -P --name zedd_container zedd_image:v1

 

내 이미지를 기반으로 컨테이너를 생성

 

위 사진을 보면 zedd_container라는 컨테이너를 생성한 후, 실행중인 컨테이너 목록을 확인해본 결과, 하나의 컨테이너가 실행중임을 알 수 있다. 더 자세히 들여다보면 COMMAND 항목에는 우리가 Dockerfile에서 CMD 명령어에 명시해주었던 명령어가 그대로 들어있고, PORTS 항목에 보면 호스트의 32768포트 번호가 컨테이너의 80번 포트로 연결되어 있음을 알 수 있다. 이 컨테이너의 80번 포트는 바로 Dockerfile에서 EXPOSE에 명시해주었던 포트번호이다. 

 

그러면 아까 위에서 메타데이터를 LABEL로 명시해주었던 것을 찾기 위해 아래 명령어를 실행해서 찾아보자. 보통 레이블을 활용해서 이미지를 찾으려면 --filter 옵션을 넣고 label 인자와 함께 key=value 값 형태로 넣어주어 찾을 수 있다. 코드 예시는 아래와 같다.

 

$ docker images --filter "label=purpose=practice"

 

5-3. 빌드 과정 살펴보기

위 목차에서는 빌드를 직접 실행해보았다. 그렇다면 이번에는 빌드를 실행하면 내부적으로 대체 어떤 일이 발생하는지 살펴보자. 그 중에서 가장 먼저 접할 개념은 바로 빌드 컨텍스트이다.

5-3-1. 빌드 컨텍스트

build 명령어로 이미지 빌드를 시작하면 도커는 가장 먼저 빌드 컨텍스트라는 것을 읽어 들인다. 여기서 빌드 컨텍스트란, 이미지를 생성하는 데 필요한 각종 파일, 소스코드, 메타데이터 등을 담고 있는 디렉터리를 의미한다. 보통은 Dockerfile이 위치한 경로가 빌드 컨텍스트가 된다. 빌드 컨텍스트가 이미지를 생성하기 위해 필요한 여러가지 파일들을 갖고 있기 때문에 빌드될 이미지에 파일을 추가할 때 주로 사용한다. Dockerfile 명령어로는 ADD 또는 COPY 같은 명령어를 실행할 때 빌드 컨텍스트를 활용한다. 이 빌드 컨텍스트에 대한 정보는 이미지를 빌드하고 터미널에 출력되는 표준출력에서 맨 먼저 등장한다.

 

빌드 컨텍스트는 build 명령어의 맨 마지막 인자로 지정된 위치에있는 파일을 전부 포함한다. 예를 들어, 아래와 같은 명령어가 있다고 한다면 빌드 컨텍스트의 경로는 호스트 파일시스템의 /Users/zedd/Destkop 이라는 경로가 된다

 

$ docker build -t zedd_image:v1 /Users/zedd/Desktop/

 

해당 인자에는 파일시스템의 특정 경로를 입력해도 되지만 깃과 같은 외부 URL을 읽어들일 수 도 있는데, 만약 깃 레포지토리 URL을 읽어들이면 해당 레포지토리에 있는 모든 디렉토리와 파일을 빌드 컨텍스트에 포함시킨다. 그래서 보통 빌드 컨텍스트의 경로를 모든 파일의 부모 디렉토리인 root 디렉토리 같은 곳에서 이미지가 빌드되지 않도록 주의해야 한다. 왜냐하면 빌드에 불필요한 파일이 대량 포함된다면 이미지를 빌드하는 속도가 느려질 뿐만 아니라 호스트의 메모리도 지나치게 많이 차지할 수도 있기 때문이다.

 

물론 또 뛰어난 개발자들이 위와 같은 난감한 상황을 대비해 특정 파일은 빌드 컨텍스트에 포함되지 않도록 명시하는 파일을 개발하였는데, 바로 깃에서 사용하는 .gitignore 파일과 비슷한 역할을 하는 .dockerignore 파일이다. .dockerignore 파일에 명시된 파일들은 빌드 컨텍스트의 최상위 경로, 다시 말해 build 명령어에서 맨 마지막에 오는 경로이자 Dockerfile이 위치한 경로와 같은 곳에 위치해야 한다.

 

.dockerignore에 명시하는 파일 포맷으로는 모든 디렉토리 또는 파일을 의미하는 *(asterisk) 문자를 이용할 수 있다. 또한 ? 문자를 사용해서 임의의 1자리 문자가 들어가는 파일 또는 디렉토리를 필터링할 수도 있다. 마지막으로, 특수한 파일만 포함되지 않도록 설정하고 싶다고 하면 파일 또는 디렉토리 명 맨 앞에 ! 문자를 붙여주면 된다. 아래는 .dockerignore 파일 예시이다.

 

*.html
/*/*.csv
!index.html

5-3-2. Dockerfile 내부 명령어가 실행하는 컨테이너 생성과 커밋

Dockerfile을 기반으로 만들어지는 이미지는 단 하나의 컨테이너에서 생성되는 것은 아니다. 다시 말해, Dockerfile에 명시된 명령어 한줄 당 하나의 컨테이너가 생성된다. 만약 아래와 같은 Dockerfile이 있다고 가정해보자.

 

FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install apache2 -y

 

위와 같은 Dockerfile 파일을 기반으로 빌드하면 아래와 같은 방식으로 컨테이너가 생성되고 삭제되면서 이미지가 생성된다.

 

Dockerfile은 여러개의 컨테이너를 생성하면서 이미지를 완성한다

 

위 그림 예시를 보자. Step1번으로, FROM 명령어를 실행하면서 Ubuntu:14.04 라는 공식 이미지를 활용해서 컨테이너를 생성하고, 내부적으로 커밋을 하여 새로운 이미지 레이어 1을 생성한다. 그리고 Step1번으로 생성된 새로운 이미지를 기반으로 첫번째 RUN 명령어를 실행하면서 또 다른 컨테이너를 생성한다. 이렇게 계속적으로 최종 이미지를 만들 때까지 중간의 명령어 한 줄 마다 하나의 새로운 컨테이너를 생성하게 된다. 그리고 난 뒤, 최종 이미지가 완성된 후에는 중간에 생성되었던 컨테이너들을 모두 삭제한다. 결국, Dockerfile에 명시된 명령어 줄 개수만큼 새로운 이미지 레이어가 생기고 그 숫자만큼의 임시 컨테이너들이 중간에 생성되었다가 삭제된다.

5-3-3. 캐시를 이용한 빌드

도커를 이용하다보면 그 전에 사용했던 동일한 이미지를 또 생성할 때, 처음에 생성했을 때보다 엄청 빠르게 이미지가 생성되는 경험을 해본 적이 있을 것이다. 이것이 바로 캐시를 이용한 이미지 빌드이다. 캐시 이미지 빌드란, 한 번 이미지 빌드를 하고 난 뒤 다시 같은 빌드를 진행하면 이전의 이미지 빌드에서 사용했던 캐시를 그대로 사용하는 것을 의미한다. 보통 캐시를 이용하게 되면 이미지 생성 시 표준출력에 "Using cache.." 라는 내용이 나온다. 캐시를 하는 기준은 이전에 빌드할 때와 같은 명령어를 수행한 것까지 포함하여 캐시를 하게 된다.

 

참고로 도커 빌드 시 오류가 발생하면 build 명령어가 중지되면서 위 그림처럼 중간 중간 컨테이너를 생성 및 삭제하다가 마지막으로 생성된 중간 컨테이너가 삭제되지 않은 채로 남겨지게 된다. 그리고 완전한 빌드 형태가 아니기 때문에 docker build -t 옵션 다음에 넣어준 이미지 이름이 아닌 이름이 <none>:<none>인 즉, 댕글링 이미지로 남게 된다. 

 

하지만 이렇게 캐시 기능이 불편하게 느껴질 때가 있다. 일례로, Dockerfile에 특정 깃 레포지토리를 clone 하는 것이 있다. 아래 Dockerfile 예시를 보자.

 

FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install git -y
RUN git clone https://github.com/young-hun-jo/DeepLearningOnlyNumpy.git

 

그런데 최초에 빌드할 때랑 두번째 빌드할 때랑 해당 레포지토리의 소스코드에 수정(리비젼)이 생겼다고 가정해보자. 만약 이런 상황일 때 캐싱을 사용해서 빌드를 한다고 하면 수정 사항이 반영된 레포지토리의 소스코드를 가져오지 못하고 계속 이전 버전의 레포지토리만 클론하게 된다. 그래서 이에 대응하기 위해 위 Dockerfile을 docker build 로 실행하되 --no-cache 옵션을 넣어주면 된다.

 

$ docker build --no-cache -t zedd_git_image:v1 .

 

또 다른 방법으로, 특정 이미지만을 캐시를 사용해 빌드하고 싶다면 아래와 같은 명령어 포맷으로 하면 된다.

 

$ docker build --cache-from [IMAGE] -t zedd_cache_image:v1 .

5-3-4. 멀티 스테이지를 이용한 Dockerfile 빌드

멀티 스테이지 빌드는 이미지의 크기를 줄여서 이미지를 생성하는 방법이다.(단, 도커 엔진 17.05 버전 이상에서만 가능) 이를 이해하기 위해 우선 아래와 같은 간단한 Dockerfile과 main.py을 작성해보자. 

 

# main.py
def f():
    return "Hello zedd"

 

FROM python:3.10.1
ADD main.py /root
WORKDIR /root
RUN python main.py

 

위 2개의 파일을 작성한 뒤 아래 build 명령어를 실행시켜보자.

 

$ docker build -t zedd_python:v1 .

 

그리고 빌드한 이미지 즉, zedd_python:v1 이라는 이름의 이미지의 용량을 살펴보자.

 

 

이미지 사이즈가 917MB 용량이나 차지한다. 이렇게 용량이 커진 이유는 다운로드 받은 이미지가 간소화된 버전이 아닌 python:3.10.1 이미지인 이유도 있으며, 그러한 이미지는 우리가 실행하길 원하는 즉, main.py 파일을 실행하는 데 필요한 것 말고도 불필요한 각종 패키지 및 라이브러리가 들어있다는 것을 의미한다. 도커는 이렇게 큰 이미지를 기반으로 나만의 이미지를 빌드하더라도 이미지 크기를 줄일 수 있는데, 그 크기를 줄이면서 빌드하는 방법이 바로 멀티 스테이지 빌드 방법이다.

 

참고로 이미지 크기가 간소화된 python 이미지를 위해서 python:slim, python:alpine 등과 같은 최소한의 기능만 포함된 이미지를 기반으로 나만의 이미지를 생성하기도 한다.(참고로 slim은 파이썬만 실행할 수 있는 작은 이미지이고, alpine, busybox, bullseye는 일반적인 리눅스 배포판인 Ubuntu, CentOS 보다 가볍고 기능이 최소한으로만 들은 리눅스 배포판을 뜻한다)

 

그러면 이제 멀티 스테이지 빌드 방법에 대해 알아보자. 멀티 스테이지는 하나의 Dockerfile 안에 여러 개의 FROM 이미지를 정의함으로써 빌드 완료 시 최종적으로 생성될 이미지의 크기를 줄이는 역할을 한다. Dockerfile 안에 여러 개의 FROM 이미지를 정의한다니? 대체 무슨말인지 모르겠다. 일단 예시 Dockerfile 부터 살펴보자. 

 

FROM python:3.10.1
ADD main.py /root
WORKDIR /root
RUN python main.py

FROM alpine:latest
WORKDIR /root/alpine
COPY --from=0 /root /root/alpine
CMD ["/bin/sh", "-c", "python /root/alpine/main.py"]

 

위 파일 내용을 보면 2개의 FROM이 명시되었다. 첫 번째 문단에 있는 것은 위에서 실습해 본 것이랑 동일하다. 중요한 것은 두 번째 문단의 내용들이다. 일단, 두번째 문단에서는 alpine:latest 라는 이미지를 다운받는다. 그리고 해당 이미지의 /root/alpine 디렉터리를 생성 및 이동을 한다. 여기서 중요한 것은 "--from=0" 이다. 여기서 0은 첫 번째 FROM에서(첫 번째 문단에서) 빌드된 이미지의 최종상태를 의미한다. 그리고 그 최종상태의 이미지의 /root 디렉토리에 있는 파일을 두 번째 FROM 이미지인 alpine:latest 이미지의 /root/alpine 디렉터리에 복사(COPY) 한다는 의미이다. Dockerfile 내용을 다시 정리하면 아래와 같다.

 

멀티 스테이지 Dockerfile 해석

 

위 Dockerfile을 아래 명령어로 빌드한 뒤, zedd_multi_stg:v1 이라는 이미지와 zedd_python:v1 이라는 이미지의 크기 차이를 비교해보자. 똑같은 수행하는 두 개의 이미지이지만, 크기 차이가 엄청 나는 것을 볼 수 있다. 이것이 바로 멀티 스테이지 빌드의 장점인 것이다!

 

(***용량 차이 사진 첨부하기****)

 

첫 번째 FROM 이미지를 첫 번째 단계의 이미지라고도 부른다. 그런데 위에서 0이라는 숫자가 첫 번째 단계의 이미지를 가리키는 것을 다른 사용자 입장에서는 헷갈릴 수도 있다. 이를 위해서 특정 단계의 이미지 이름에 별칭(alias)을 붙일 수도 있다. 위 Dockerfile 예시를 아래처럼 바꿀 수도 있다.

 

FROM python:3.10.1 as python_3
ADD main.py /root
WORKDIR /root
RUN python main.py

FROM alpine:latest
WORKDIR /root/alpine
COPY --from=python_3 /root /root/alpine
CMD ["/bin/sh", "-c", "python /root/alpine/main.py"]

5-4. Dockerfile의 다른 명령어

이번 목차에서는 Dockerfile 파일에서 사용하는 좀 더 다양한 명령어에 대해서 알아보도록 하자. 여기서는 명령어 종류를 표 형태로 알아보고, 별도로 실습을 해보면서 이해할 명령어는 표 아래에서 배워보도록 하자.

 

명령어	의미	특징
ENV [NAME] [VALUE]	Dockerfile에서 사용될 환경변수를 지정. 보통 셸 스크립트에서 호출하는 환경변수처럼 Dockerfile에서도 #${NAME} 또는 #$NAME 처럼 사용할 수 있음	- Dockerfile에서 선언한 환경변수는 해당 Dockerfile로 만들어진 이미지애도 저장되므로 빌드된 이미지를 기반으로 컨테이너를 생성했을 때도 그 환경변수를 사용할 수 있음 - Dockerfile에서 ENV로 선언한 환경변수 값이 있는데, 만약 docker run 의 -e 옵션으로 동일한 환경변수 이름을 선언한다면 -e 옵션에서 선언한 값으로 덮어쓰기 됨 - 특정 환경변수가 설정되어 있는 경우, 있지 않은 경우에 따라 어떤 값을 사용할지도 설정할 수 있음. ex1) ${env_name: -value} ➔ env_name 이라는 이름에 환경변수 설정되어 있지 않다면 value 라는 값으로 사용 ➔ env_name 이라는 이름에 환경변수 설정이 되어 있다면 그 값을 사용 ex2) ${env_name: +value} ➔ env_name 이라는 이름에 환경변수 설정이 되어 있지 않다면 빈 문자열을 사용 ➔ env_name 이라는 이름에 환경변수 설정이 되어 있다면 value 라는 값을 사용
VOLUME [CONTAINER 경로]	Dockerfile로 빌드된 이미지로 컨테이너를 생성할 때, 호스트의 파일시스템과 공유할 컨테이너 내부의 디렉토리 경로를 설정. 즉, 호스트 볼륨을 공유할 컨테이너의 경로를 설정하는 명령어	JSON 배열 형식 또는 공백으로 구분하여 여러개의 컨테이너 경로를 명시할 수 있음
ARG [key]=[value]	build 명령어로 Dockerfile을 빌드할 때 추가로 인자를 받아 Dockerfile 내에서 사용될 변수의 값을 설정 <key>=<value> 형태로 명시함 Dockerfile 내에서는 해당 인자를 ${build_arg} 형태로 ENV 명령어 처럼 동일한 형식으로 사용함	- <value>를 명시하면 해당 인자의 디폴트 값이 명시되는 셈  - build 명령어 사용 시, 반드시 --build-arg 옵션을 주어 인자를 주어야 함 - 만약 ARG 인자로 주는 인자의 이름을 ENV로 명시하는 변수의 이름과 같게 한다면 ENV가 --build-arg 에서 명시하는 ARG의 인자값을 덮어쓰기 함에 주의
USER [username]	Dockerfile을 빌드한 이미지를 기반으로 생성된 컨테이너 내부에서 사용될 사용자 계정	- 보통 컨테이너는 root 권한으로 실행되는데, 만약 이 때, 호스트와 볼륨을 공유하게 되면 호스트의 root 권한을 가질 수 있음을 의미함. 이렇게 되면 컨테이너에서 호스트의 root 권한을 이용하여 디렉터리를 맘대로 조작할 여지가 있음 - 그래서 보통 컨테이너를 최종적으로 배포할 때는 컨테이너 내부에서 새로운 사용자를 생성해 사용하는 것을 권장함
ONBUILD [명령어]	빌드된 이미지를 부모로 하는 다른 이미지가 Dockerfile로 생성될 때 실행할 명령어	- 나중에 빌드될 이미지를 위해 미리 저장해놓을 수 있는 명령어를 명시함 - ONBUILD에 명시된 명령어는 부모 이미지에서는 실행되지 않고, 반드시 자식 이미지에서만 실행됨. 또한 자식 이미지의 자식 이미지(즉, 부모입장에선 손자 이미지)에도 ONBUILD 명령어가 실행됨
STOPSIGNAL [SIGNAL]	컨테이너가 정지될 때 사용될 시스템 콜(프로세스에게 전송하는 신호)의 종류를 지정	- 여기서 SIGNAL의 종류는 리눅스 포스팅에서 배운 것을 의미 - 디폴트 신호는 SIGTERM임 - docker run 에는 --stop-signal 옵션으로, docker stop, kill 에서는 --signal 옵션으로 개별적 명시 가능
HEALTHCHECK [OPTIONS] [ex. curl 명령어]	Dockerfile을 빌드한 이미지로부터 생성된 컨테이너 안에서 동작하는 애플리케이션이 잘 동작하는지 상태를 체크하는 명령어	- ex) HEALTHCHECK --interval=1m --timeout=3s --retries=3 [CMD curl -f https://localhost] - 위 명령어 의미는 1분 마다 3초 이상이 소요되며 3번 이상 타임아웃이 발생히면 컨테이너 상채가 unhealthy 상태가 됨 - 주기적인 상태 체크에 대한 로그 결과는 docker inspect 명령어의 결과 부분 중 "State -> Helath -> Log" 항목에서 볼 수 있음
SHELL	Dockerfile을 빌드한 이미지로부터 생성된 컨테이너 안에서 사용할 셸 종류를 명시	- Dockerfile에서 기본적으로 사용하는 셸은 sh 셸임 - 만약, bash를 사용하고 싶다면 SHELL ["/bin/bash"] 형태로 bash 명령어 파일이 있는 경로를 명시해주면 됨

5-5. ADD vs COPY 명령어 차이

Dockerfile 명령어 중에 로컬 디렉터리에서 읽어들인 빌드 컨텍스트의 파일들을 이미지에 추가하는 명령어들이 있다. 바로 ADD, COPY이다. 그렇다면 두 개의 차이점은 무엇일까? COPY는 빌드 컨텍스트에 있는 파일(또는 디렉터리)만 이미지에 추가할 수 있지만 ADD는 깃과 같은 외부 URL 및 아카이브/압축 파일인 tar 파일도 이미지에 추가할 수가 있다. 즉, COPY의 기능은 ADD의 기능 중 일부라고 할 수 있다. 특히 신기한 것은 ADD를 통해 tar 파일을 명시하면 알아서 아카이브 및 압축해제를 해주게 된다.

 

COPY는 ADD에 종속되어 있다고 할 수 있음

 

하지만 ADD 보다는 COPY를 사용할 것을 책에서는 권장한다. 왜냐하면 ADD를 사용해서 외부 URL 및 tar 파일을 이미지에 추가한다고 했을 때 해당 URL 또는 tar 파일에 정확히 어떤 파일이 있는지 모르는 상태이기 때문이다. 막말로 외부 파일에 악성코드 같은 것들이라도 심어놓는 경우엔 큰 사고가 날 수도 있기 때문이다.

5-6. ENTRYPOINT vs CMD 명령어 차이

다음으로 알아볼 두 명령어는 컨테이너가 시작될 때 실행할 명령어를 지정하는 ENTRYPOINT 와 CMD 이다. 우선 이 두 명령어는 공통적으로 컨테이너가 시작될 때 실행할 명령어를 지정한다는 점이 같지만, ENTRYPOINT는 CMD(커맨드)를 인자로 받아 사용할 수 있는 스크립트의 역할도 할 수 있다는 것이 차이점이다.

 

예를 들어, 아래와 같이 docker run 명령어의 맨뒤인 CMD(커맨드)를 명시하는 자리에 /bin/bash 를 입력함으로써 컨테이너 내부에 들어가서 bash 셸을 활성화 하도록 해보자. 

 

$ docker run -it --name cmd_container ubuntu:14.04 /bin/bash

 

그러면 아래와 같이 컨테이너 내부에서 현재 사용중인 셸을 확인할 수 있는 명령어인 echo $SHELL을 쳐보면 아래와 같은 표준출력 화면이 나오는 것을 볼 수 있다.

 

 

그렇다면 이제 docker run 명령어에서 ENTRYPOINT를 사용해보자. docker run 명령어에서는 --entrypoint 라는 옵션을 줄 수 있다. 여기서는 컨테이너 내부에 들어가 /bin/bash 셸을 활성화시키는 것이 아닌 /bin/bash 라는 출력을 보여주도록 하기 위해 echo /bin/bash 라는 명령어를 실행하도록 해보자. 명령어는 아래와 같다.

 

$ docker run -it --name entrypoint_container --entrypoint="echo" ubuntu:14.04 /bin/bash

 

위 명령어를 치면 생성한 컨테이너 안에서 echo /bin/bash 라는 명령어를 표준출력으로 내뱉어준 후, 해당 컨테이너를 멈추면서 호스트로 다시 나오는 것을 볼 수 있다.

 

 

즉, docker run 명령어에서 ENTRYPOINT는 CMD를 인자로 받아서, 위 예시에서는 CMD가 /bin/bash 이기 때문에 해당 명령어를 ENTRYPOINT의 echo 인자로 넣어주는 것이다.

 

만약 ENTRYPOINT가 설정되지 않았다면 CMD에 설정된 명령어를 그대로 실행하지만, ENTRYPOINT가 설정되어 있을 때는 CMD는 단지 ENTRYPOINT에 명시된 명령어의 인자(argument) 역할만 하는 셈이다.

 

물론 위에서 처럼 간단한 echo 명령어를 ENTRYPOINT로 활용할 수도 있겠지만 보통은 특정 스크립트를 실행하기 위해서 ENTRYPOINT와 CMD를 조합해서 많이 사용한다. 이번에는 Dockerfile에서 ENTRYPOINT와 CMD가 어떻게 사용되는지 예시를 들어 한 번 살펴보도록 하자. 먼저 아래와 같은 Dockerfile과 example.sh 이라는 셸 스크립트가 있다고 가정하자.

 

FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install apache2 -y
ADD example.sh /example.sh
RUN chmod a+x /example.sh
ENTRYPOINT ["/bin/bash", "/example.sh"]

 

#!/bin/bash
#example.sh

echo $1 $2
apachectl -DFOREGROUND

 

위 example.sh 스크립트에서 $1, $2로 해당 셸 스크립트의 인자를 받은 것을 echo로 출력하도록 했다. 혹시 셸 스크립트에서의 인자를 왜 $1, $2로 받는지 잘 모른다면 이전 리눅스 포스팅을 참조해보도록 하자.

 

위 2개의 파일을 작성한 뒤 아래 명령어를 실행하여 이미지를 빌드하고 해당 이미지를 기반으로 컨테이너를 detached(백그라운드)모드로 생성해보자.

 

$ docker build -t entrypoint:v1 .
$ docker run -d --name entrypoint_c1 entrypoint:v1 argument_1 argument_2
$ docker logs entrypoint_c1

 

마지막 docker logs 명령어를 통해 컨테이너 안에서 발생한 로그를 표준출력으로 살펴보면 셸 스크립트의 인자로 준 argument_1, argument_2가 echo 명령어를 통해 아래 화면처럼 출력된 것을 볼수 있다.

 

 

그리고 추가로 알아볼 점은 ENTRYPOINT와 CMD 명령어에서 JSON 배열 형태로 주는 것과 일반 형태로 주는 것의 차이점이다. 결론부터 말하면 일반 형태로 주게 되면 내부적으로 무조건 sh 라는 셸을 사용한다. 다시 말해, 만약 아래와 같은 CMD를 설정했다고 해보자.

 

FROM ubuntu:14.04
CMD echo "Hello world"

 

이렇게 하면 셸 프롬프트에서 명령어로 치자면 /bin/sh -c echo "Hello world" 가 수행되는 것이다. 반면에 아래와 같이 JSON 배열 형태로 명시하면 실제로 JSON 배열에 명시한 그대로 명령어를 수행한다.

 

FROM ubuntu:14.04
CMD ["/bin/bash", "echo Hello world"]

5-7. Dockerfile 빌드 시 주의점

이제 마지막으로 Dockerfile을 빌드할 때 주의할 점에 대해서 알아보고 가자. Dockerfile 과 이미지의 구조 간에 관계를 살펴봄으로써 주의해야 할 점을 배울 수 있다. 우선 하나 명심하고 아래 내용을 읽어나가보자. Dockerfile에서의 명령어 한 줄은 하나의 새로운 이미지 레이어를 생성한다!(이 내용은 위 [목차 5-3-2]에서 배웠다)

 

우선 아래와 같이 예시 Dockerfile이 있다고 가정하자. 이 Dockerfile은 ubuntu 이미지를 다운로드 받고 그 이미지의 특정 디렉토리 내에 100MB의 더미파일을 생성한 뒤 삭제하는 동작을 수행한다.(참고로 fallocate 명령어에 대해서는 이전 리눅스 포스팅 때 배운적이 있다)

 

FROM ubuntu:14.04
RUN mkdir /dummy
RUN fallocate -l 100M /dummy/dummy_file
RUN rm /dummy/dummy_file

 

$ docker run -t dummy_img:v1 .

 

ubuntu:14.04 의 이미지 용량은 대략 200MB가 안된다. 그런 상태에서 위와 같은 Dockerfile을 기반으로 이미지를 생성하면 이미지 용량이 얼마나 될까? 100MB의 더미 파일을 생성했지만 마지막에 삭제했으므로 저 이미지도 ubuntu:14.04 이미지랑 용량이 거의 비슷하지 않을까? 직접 확인해보자.

 

 

이상하게 사이즈가 301MB나 된다. 대체 왜그런 것일까? 바로 컨테이너를 이미지로 생성할 때 컨테이너에서 변경된 새로운 사항만 새로운 이미지 레이어로 생성하기 때문이다. 즉, 위 Dockerfile에서 fallocate 명령어가 있는 RUN 명령어로 100MB의 더미파일을 생성했다. 그 후에 바로 rm 명령어가 있는 RUN 명령어로 이 더미파일을 삭제한다고 한들 실제로 그 파일이 삭제되는 것이 아니라 "100MB 더미 파일을 삭제함" 이라는 변경사항만 추가로 새로운 이미지 레이어로 추가되는 것 뿐이다. 따라서 100MB의 더미파일은 이미지 레이어에 남아있게 되고 이는 불필요한 저장공간을 차지하게 된다.

 

여기서 또 한 가지 주의할 점은 그렇다고 해서 더미파일이 실물로 남아있지는 않다. 다시 말해, 해당 이미지(dummy_img:v1 이름의 이미지)로 컨테이너를 생성해서 내부로 들어가 /dummy 라는 경로에 들어가 보면 100MB의 더미 파일은 존재하지 않는 것을 알 수 있다.

 

그렇다면 이를 해결하기 위한 것은 무엇일까? 바로 Dockerfile에 쓰는 명령어를 묶을 수 있는 것들은 하나로 묶는 것이다. 그리고 그럴 때 사용하는 명령어가 && 명령어이다. 이게 가능한 이유는 RUN 명령어를 하나만 쓰고 거기에 다 몰아서 명시하기 때문에 그 하나의 RUN 명령어 당 하나의 새로운 이미지 레이어가 생성되기 때문이다. 그래서 위 Dockerfile을 개선한다면 아래와 같이 개선할 수 있다.

 

FROM ubuntu:14.04
RUN mkdir /dummy && \
fallocate -l 100M /dummy/dummy_file && \
rm /dummy/dummy_file

 

$ docker build -t dummy_img:v1 .

 

그리고 위 2개의 이미지 용량을 한번 비교해보자.

 

 

개선한 Dockerfile 파일을 기반으로 만든 dummy_img:v2 라는 이미지가 197MB로 약 100MB 더 용량이 적은 것을 알 수 있다. 

 

컨테이너를 이미지로 생성할 때 컨테이너에서 변경된 사항만 새로운 이미지 레이어로 생성하는 이 방식이 방금 단점이라고 했지만 장점으로 활용될 수도 있다.

 

예를 들어, A, B라는 두 개의 애플리케이션을 개발하려고 할 때, 두 개 모두 C라는 라이브러리를 공통적으로 사용한다. 그런데 이 C 라이브러리는 용량이 꽤 커서 약 700MB 정도로 큰 사이즈라고 가정해보자. 이 때, 우리는 각 애플리케이션을 개발할 A, B 컨테이너 각각에 C 라이브러리를 개별로 설치한다고 하면 대략적으로 최소한 1.4GB가 넘는 저장공간을 차지한다.

 

하지만 이렇게 하지 않고 C 라이브러리만 설치된 이미지를 먼저 하나 만든 다음, 이 이미지를 기반으로 A, B 컨테이너를 개발하면 우리는 대략적으로 최소한 700MB가 넘는 저장공간을 차지하게 되므로 전자의 경우보다 절반의 저장공간 효율을 얻어낼 수 있다.

---

이렇게 해서 도커 이미지에 대한 개념과 도커 이미지를 편리하게 만들고 다양한 동작을 수행할 수 있는 Dockerfile에 대해서도 여러가지 알아보았다. 다음 포스팅에서는 도커 데몬이라는 것에 대해서 알아보도록 하자.