[Docker] 도커 컨테이너 다루어보기

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

 

Docker

---

이번 포스팅에서는 도커 엔진의 핵심 중 하나인 도커 컨테이너를 다루는 방법에 대해 알아보도록 하자. 

1. 컨테이너 생성하기

가장 먼저 배워볼 것은 컨테이너를 생성하는 방법이다. docker run 명령어로 실행할 수 있는데, 이 명령어는 컨테이너를 생성하고 실행까지 할 수 있는 명령어이다. 명령어 형식은 아래와 같다. 공식 문서에 가면 여러가지 인자가 있긴 하지만, 여기서는 자주 쓰이며 핵심적인 명령어 인자만 알아보도록 하자.

 

$ docker run [OPTIONS] [IMAGE]

 

아래와 같이 ubuntu:20.04 이미지를 활용해서 컨테이너를 생성해보자. run 명령어로는 이미지를 pull 하는 것까지 한번에 해준다. 이전에 배웠을 때는 pull 명령어로 이미지를 다운받고, run 명령어로 컨테이너를 생성하고 실행하는 단계를 투 스텝으로 나누어서 배워서 이렇게 해야만 컨테이너가 생성되는 줄 알았다. 하지만 run 명령어 하나만 실행해주어도 최초로는 로컬 도커 엔진에 해당 이미지가 있는지 찾아보고, 없으면 도커 중앙 이미지 저장소인 도커 허브에서 자동으로 이미지를 내려받고 그 이미지를 활용해 컨테이너를 생성해준다. 아래는 run 명령어로 컨테이너를 생성 및 실행하는 예시이다.

 

ubuntu:20.04 이미지를 활용해서 컨테이너를 생성

 

위 명령어 출력화면을 보면 첫 줄에 ubuntu:20.04 라는 이미지를 local 에서 찾을 수 없어서 도커 허브에서 해당 이미지를 먼저 pull 하는 것을 볼 수 있다. 그리고 난 뒤, 프롬프트 정보를 보면 Host 이름이 [localhost ➜ 41560e9a6708] 로 바뀐 것을 볼 수 있다. 즉, 생성한 컨테이너 내부로 들어간 것을 볼 수 있다. 여기서 '41560e9a6708' 라는 호스트 이름은 무작위의 16진수 해시값이다. 이 값은 방금 생성한 컨테이너의 고유한 ID의 앞 일부분이다. 그리고 이렇게 컨테이너 내부로 들어오게 할 수 있었던 이유는 -i 와 -t 라는 옵션 덕분이다. 여기서 i는 interactive를, t는 tty로, 리눅스의 콘솔이나 터미널을 의미한다. 그리고 해당 이미지를 생성하고 바로 시작하는 명령어가 bash 셸을 활성화하도록 설정되어 있다.(이는 해당 컨테이너의 COMMANDS 항목을 보면 /bin/bash 라는 명령어가 설정되어 있기 때문) 반드시 이 3가지 조건이 모두 충족되어야 해당 컨테이너 내부로 계속 들어가 있을 수 있다.

 

그러면 들어간 컨테이너에서 빠져나오려면 어떻게 할까? 아래와 같이 2가지 방법이 있다.

 

명령어	의미
셸에 exit 입력 또는 Ctrl + D	컨테이너에서 빠져나오되 컨테이너를 정지시킴
Ctrl + P + Q	컨테이너에서 빠져나오되 컨테이너를 실행시킨 상태로 나옴 (그래서 주로 애플리케이션을 개발할 때 사용)

 

추가적으로 컨테이너와 관련된 명령어와 옵션들을 아래 표 형태로 알아보도록 하자.

 

명령어	옵션	의미	특징
docker pull [IMAGE]		이미지를 내려받을 때 사용
docker images		내려받은 이미지 목록들을 출력
docker create [OPTIONS] [IMAGE]		컨테이너를 생성	컨테이너를 생성만 할 뿐 내부로 들어가지 않음. -i, -t 옵션을 함께 사용하더라도 내부에 들어가지지 않음
docker start [CONTAINER]		생성한 컨테이너를 시작
docker attach [CONTAINER]		시작한 컨테이너 내부로 들어감
docker inspect [CONTAINER]		컨테이너의 고유한 ID를 확인
docker port [CONTAINER]		컨테이너의 PORTS 항목을 확인
docker run [OPTIONS] [IMAGE]		이미지를 다운받고 컨테이너를 생성	도커 pull, create, start 명령어 실행 후, attach가 가능한 컨테이너라면 내부로 들어가는 것을 한번에 해줌
	-i	interactive 모드
	-t	tty 터미널 활성화
	--name	생성할 컨테이너의 이름 정의
	--hostname	생성할 컨테이너의 호스트 이름 설정이 가능함
docker ps		실행중인 컨테이너를 출력
	-a	정지된 컨테이너까지 모두 출력	STATUS 값에 있는 것들 중 'Exited'는 종료된 상태를, 'Up, seconds'는 실행 중인 상태를 의미
	--format "Go template"	출력 정보를 Go template을 활용해서 원하는 형태로 출력
	-q	컨테이너 ID만 출력
docker exec [OPTIONS] [CONTAINER] [COMMAND]		해당 컨테이너가 detached 모드로 실행되었어도 해당 컨테이너 내부에서 명령어를 실행한 뒤 결과값을 반환 할 수 있음
docker rename [As-is NAME] [To-be NAME]		컨테이너의 이름을 변경

 

잠시 docker ps 명령어를 실행했을 때 나오는 결과 화면에 나오는 내용에 대해서 알아보고 가자. 아래 화면을 참고해서 하나씩 알아가보도록 하자.

 

docker ps -a 결과 화면

 

• CONTAINER ID : 컨테이너에게 자동으로 할당되는 고유한 ID
• IMAGE : 컨테이너 생성 시 활용한 이미지 이름
• COMMAND : 컨테이너가 시작될 때 실행될 명령어. 커맨드는 대부분 이미지에 미리 내장되어 있기 때문에 별도로 설정할 필요는 없다. 위 예시에서는 /bin/bash 라는 bash 셸을 활성화시키는 명령어가 입력되어 있다. 이 커맨드도 변경이 가능한데, docker run, create 명령어의 맨 끝에 입력해서 컨테이너를 생성할 때 덮어쓸 수 있다.
• CREATED: 컨테이너가 생성되고 난 뒤 흐른 시간을 의미
• STATUS : 컨테이너의 상태를 의미. Up은 실행 중을, Exited는 종료되었음을, Pause는 일시 중지된 상태를 의미
• PORTS: 컨테이너와 호스트를 연결한 포트들이 나열됨. 아무것도 없으면 연결되어 있는 포트가 없음을 의미
• NAMES : 컨테이너의 고유한 이름. --name 옵션으로 생성 시 이름을 명시해주지 않으면 도커가 임의로 랜덤한 형용사와 명사를 무작위로 조합해 설정. 위 예시에는 competent_johnson 이라는 이름으로 명시해준 것을 볼 수 있음. 컨테이너 ID와 마찬가지로 중복될 수 없음

2. 컨테이너 삭제하기

이번엔 컨테이너를 삭제하는 명령어에 대해 알아보자. 한 번 삭제한 컨테이너는 복구할 수 없기 때문에 조심해야 한다. 그리고 컨테이너를 삭제 시, 반드시 해당 컨테이너를 정지하고 삭제시켜야 한다. 물론 강제로 삭제하는 옵션을 취해줄 수도 있다. 그 이외 추가적인 삭제 관련 명령어는 아래 표를 참조하자.

 

명령어	옵션	의미	특징
docker stop [CONTAINER]		컨테이너를 정지
docker rm [CONTAINER]		정지된 컨테이너를 삭제	명령어 치환을 사용해서 가능 ex) docker rm $(docker ps -a -q)
	-f	정지 또는 실행 중인 컨테이너도 강제(force) 삭제
docker container prune		정지된 모든 컨테이너를 삭제

3. 컨테이너를 외부에 노출하기

VirtualBox에서 VM을 새로 할당받으면 가상 IP 주소가 할당된다. 이는 도커의 컨테이너도 마찬가지이다. 기본적으로 도커는 컨테이너에 $172.17.0.x$ 라는 IP 주소를 할당받는다. 끝에 $x$ 숫자가 증가하면서 순차적으로 생성되는 컨테이너에 IP 주소를 할당한다. 우선 새로운 컨테이너를 생성한 후, 해당 내부  컨테이너로 들어가 ifconfig 명령어를 통해 네트워크 인터페이스를 살펴보자.(참고로 ubuntu:20.04 이미지에는 ifconfig 명령어 파일이 존재하지 않기 때문에 ubuntu:14.04 이미지로 컨테이너를 생성했다)

 

ubuntu:14.04 이미지로 생성한 컨테이너의 네트워크 인터페이스

 

우선 크게 2가지 카테고리가 있다. eth0 과 lo 라는 인터페이스가 존재한다. eth0은 도커 컨테이너의 NAT IP인 172.17.0.2 라는 주소를 할당받았음을 보여준다. 그리고 VM의 centOS 즉, 로컬 호스트는 127.0.0.1 이라는 IP 주소를 할당 받았음을 알려주는 것이 lo 라는 인터페이스이다. 만약 아무런 설정을 해주지 않았다면 외부(도커 엔진이 설치된 CentOS 로컬 호스트가 아닌 다른 외부)에서 도커 컨테이너로 접근이 불가능할 것이다. 이 접근을 가능하게 해주기 위해서, 다시 말해 컨테이너를 외부에 노출시켜주기 위해서 eth0의 IP를 lo(로컬 호스트)의 IP와 포트에 바인딩 해주어야 한다. 이 바인딩은 docker run 명령어에 -p 라는 옵션(일명 포트 포워딩이라는 기능)을 통해 설정해줄 수 있다. 우선 -p 라는 옵션을 사용하는 명령어 형식은 아래와 같다.

 

참고로 도커 엔진이 설치된 로컬 호스트가 Mac인 경우(Docker Desktop for Mac 사용하는 경우) 도커 엔진이 설치되어있는 로컬 호스트라도 컨테이너의 IP로 접근이 불가능한 점도 참고해두자.

 

$ docker run -it -p {HOST IP}:[HOST PORT]:[CONTAINER PORT]

 

하나씩 살펴보자. 우선 로컬 호스트의 포트번호를 의미하는 HOST PORT 와 컨테이너의 포트번호를 의미하는 CONTAINER PORT 이다. 로컬 호스트의 IP 주소인 HOST IP는 생략해도 되나 생략 시에는 로컬 호스트 IP가 자동으로 설정된다. 만약 새로운 특정 IP 주소를 명시하고 싶다면 HOST IP에 해당 주소 값을 넣어주면 된다. 또한 HOST PORT도 생략이 가능하다. 단, 생략하게 되면 알아서 자동으로 로컬 호스트의 비어있는 포트에 연결을 해주는데, 연결 후 로컬 호스트의 어떤 포트로 연결했는지 살펴보기 위해서는 docker ps 명령어를 통해 나온 결과 화면중 PORTS 항목을 확인하면 된다. 그리고 만약 포트를 여러개 연결해주고 싶다고 한다면 -p 옵션을 여러번 써주어 명시해주면 된다. 아래처럼 말이다.

 

$ docker run -it -p 80:80 -p 127.0.0.1:8080:3306

 

그러면 이제 아파치 웹서버를 띄워놓을 컨테이너를 생성하고 컨테이너 포트와 로컬 호스트의 포트를 연결시켜보자. 그리고 로컬 호스트에서 아파치 웹서버에 접근이 잘되는지도 살펴보자. 우선 로컬 호스트(CentOS)에서 아래 명령어들을 입력해 컨테이너 생성하고 그 내부로 들어가서 아파치 웹서버를 설치 및 구동시켜보자.

 

$ docker run -it --name mywebserver -p 127.0.0.1:3333:80
$ apt-get update
$ apt-get install apache2 -y
$ echo "ServerName localhost" >> /etc/apache2/apache2.conf
$ service apache2 start

 

아파치 웹서버는 특이하게 무조건 80 포트 번호만 사용하기로 되어 있으므로, 반드시 컨테이너 포트 번호를 지정해줄 때 80번을 지정해주어야 함을 잊지말자. 위 명령어를 모두 실행하고 정상 동작하면 아래와 같이 웹서버가 구동되고 있다는 표준출력을 볼 수 있다.

 

아파치 웹서버를 구동 중..

 

그러면 이제 웹서버가 띄워져있는 컨테이너에서 나와 로컬 호스트에서 컨테이너에 띄워져 있는 아파치 웹서버에 접근해보도록 하자. 현재 로컬 호스트의 IP 주소의 3333 포트번호로 연결했으므로 HTTP 프로토콜을 활용해서 아래처럼 접속해보면 아파치 웹서버 화면이 보여지는 것을 볼 수 있다.(HTTPS를 활용하면 안 됨에 주의)

 

 

만약 CentOS GUI를 사용하지 않을 경우에 테스트를 해보고 싶다면 우선 컨테이너에서 로컬 호스트로 빠져 나와야 한다. 이 때, 컨테이너로 나올 때 반드시 Ctrl + P + Q를 이용해 컨테이너가 실행 중인 상태를 유지하면서 나와야 한다. 그리고 아래 처럼 curl 로 테스트를 해보면 아파치웹서버의 HTML 소스코드가 정상 반환되는 것을 볼 수 있다.(less 명령어를 활용해 스크롤로 볼 수 있는 명령어로 적어두었다)

 

$ curl http://127.0.0.1:3333 | less

 

이렇게 컨테이너를 외부에 노출시켜 로컬 호스트에서 접근이 가능하는 것도 확인하였다. 결국, 포트포워딩을 통한 컨테이너와 로컬 호스트 간의 관계를 그림으로 도식화 해보면 아래와 같다.

 

컨테이너와 로컬 호스트 간의 포트 포워딩 관계

4. 컨테이너 애플리케이션 구축

위 목차에서는 아파치 웹서버를 띄워놓는 컨테이너 1개만 생성 후 로컬 호스트와 연결해보았다. 하지만 실제 서비스는 여러개의 컨테이너를 구성하고 운영한다. 예를 들어, 웹서버를 띄워놓는 컨테이너 1개, DB 서버를 띄워놓는 컨테이너 1개, 머신러닝을 띄워놓는 컨테아너 1개 등등..이런 서비스를 컨테이너화된 서비스라고도 한다. 이렇게 하면 하나의 컨테이너에 여러개 애플리케이션을 구축하는 것보다 켄테이너 간의 독립성을 보장하면서 여러 애플리케이션의 버전 관리, 소스 코드 모듈화가 쉽게 가능해진다. 이런 구조는 한 컨테이너에는 하나의 프로세스(애플리케이션)만 실행하는 도커의 철학과 맞닿아 있다. 마치 하나의 기능엔 최소한의 1개 기능만 담는 철학을 갖고 있는 리눅스와 비슷하다.

 

이번 목차에서는 아파치 웹서버를 위한 컨테이너, MySQL DB를 위한 컨테이너 총 2개의 컨테이너를 만들고 로컬 호스트, 2개의 컨테이너들 간에 연결시키는 법에 대해 알아보도록 하자. 우선 실행해야 하는 명령어 2개 전체를 보면서 명령어에 작성된 옵션 하나하나를 뜯어보며 해석해보자.

 

$ docker run -d \
--name wordpressdb \
-e MYSQL_ROOT_PASSWORD=password \
-e MYSQL_DATABASE=wordpress \
mysql:5.7

$ docker run -d \
-e WORDPRESS_DB_HOST=mysql \
-e WORDPRESS_DB_USER=root \
-e WORDPRESS_DB_PASSWORD=password \
--name wordpress \
--link wordpressdb:mysql \
-p 80 \
wordpress

 

그러면 이제 위 명령어의 옵션에 대해 하나씩 알아보자. 주의할 점은 반드시 위에 명령어(MySQL 서버 컨테이너 생성 명렁어)부터 실행해야 한다. 왜냐하면 두 번째 명령어(wordpress 웹서버 생성 명령어)에서 MySQL 서버와 연동해야 하는 부분이 있기 때문이다.

 

옵션	의미
-d	- 컨테이너 내부로 들어가지 않는 입출력이 없는 상태 즉, detached 모드로 컨테이너를 실행. 이전에 배웠던 -it 옵션은 attached 상태로 컨테이너를 실행한 것임. detached 모드는 컨테이너를 로컬 호스트 입장에서 백그라운드 잡으로 실행시키는 것임(리눅스의 백그라운드 잡에 대해 모른다면 여기를 참조) - detached 모드는 반드시 컨테이너 안에서 프로그램이 실행되는 상태여야 하며, 컨테이너 입장에서 포그라운드 잡으로 실행되는 프로그램이 만약 없다면 즉시 컨테이너가 종료됨
-e	- 컨테이너 내부의 환경변수를 설정 - 단, 위 예시에서는 DB 비밀번호 같은 민감한 값을 환경변수로 설정했지만, 실제로는 이러한 민감한 정보를 등록해선 안된다. 이런 경우, 추후에 배울 도커 스웜 모드의 secret 이나 쿠버네티스의 secret 같은 기능을 활용해야 함
--link	- 컨테이너 A ➜ B로 접근할 때 기본적으로 도커 엔진에 NAT로 할당 받은 내부 IP 주소(172.17.0.x로 되어 있는 주소)를 활용할 수 있음. 하지만 이러한 주소는 컨테이너가 생성될 때마다 계속 바뀌기 때문에 매번 바뀌는 IP 주소를 설정해주기 까다로움 - 그래서 내부 IP 주소를 알 필요 없이 컨테이너에 IP 주소를 일종의 별명(alias)으로 붙여주어 접근할 수 있도록 설정함. 위 예시에서는 wordpressdb 라는 컨테이너의 내부 IP 주소를 mysql 이라는 별명으로 설정하였음. 다시 말해, mysql 별칭을 사용하면 wordpressdb 내부 IP로 접근이 가능하게 됨 - 단, --link 옵션에 명시해줄 컨테이너가 실행되고 있는 상태가 아니라면 동작하지 않음. 즉 컨테이너 실행 순서의 의존성도 정의해주는 셈 - 참고로 --link 옵션은 deprecated된 옵션이며 추후에 삭제될 예정임. 따라서 추후에 배울 도커 브리지(bridge) 네트워크를 사용하는 방법이 있음(추후에 배울 예정)

5. 도커 볼륨

도커 이미지로 컨테이너를 생성하게 되면 이미지는 읽기 전용이 되어서 컨테이너의 변경 사항만 별도로 저장해서 각 컨테이너의 정보를 보존한다고 배웠다. 예를 들어, 아래와 같이 MySQL 이미지를 통해 컨테이너를 생성하게 된다고 해보자.

 

도커 컨테이너는 쓰기 가능, 이미지는 읽기 전용이다

 

위처럼 컨테이너를 생성하게 되면 컨테이너 레이어에 원본 이미지에서 변경된 파일시스템, 서비스를 운영하면서 MySQL 데이터베이스에서 적재되는 데이터 등이 적재된다. 그런데 이렇게 하면 치명적인 단점이 존재한다. 만약에 위와 같은 구조의 컨테이너를 한창 운영하다가 실수로 해당 컨테이너를 삭제하게 된다면 그 때 컨테이너에 담긴 여러가지 데이터들이 삭제되게 된다. 이러한 문제를 예방하기 위해 컨테이너에 존재하는 데이터를 영속적(persistent)으로 보관하고 유지하기 위한 방법이 몇가지가 있는데, 그 중 볼륨(volume)을 활용하는 방법이 있다. 또 볼륨을 활용하는 방법에는 3가지가 존재하는데, 다음 목차부터 하나씩 알아가보도록 하자.

5-1. 호스트와 컨테이너를 직접 연결하자, 호스트 볼륨 공유

호스트 볼륨 공유란, 호스트의 디렉터리(또는 파일)를 컨테이너의 디렉터리와 연결해 공유하는 것을 의미한다. 우선 이전 목차에서 사용한 명령어와 비슷하게 MySQL DB 컨테이너를 생성해보자. 주목할 점은 MySQL DB 컨테이너를 생성하는 명령어에서 볼륨(-v 옵션)을 사용했다는 것이다.

 

$ docker run -d \
--name wordpressdb_hostvolume \
-e MYSQL_ROOT_PASSWORD=password \
-e MYSQL_DATABASE=wordpress \
-v /home/wordpress_db:/var/lib/mysql \
mysql:5.7

 

위 볼륨(-v 옵션) 옆에 명시되는 형식은 아래와 같다.

 

-v [HOST 디렉터리]:[CONTAINER 디렉터리]

 

이렇게 명시해줌으로써 호스트의 디렉터리와 컨테이너 디렉터리를 서로 공유할 수 있게 된다. 위 명령어에서 /var/lib/mysql 디렉터리는 실제 MySQL 이미지를 기반으로 컨테이너를 생성하면 MySQL이 데이터베이스의 데이터를 저장하는 기본 디렉터리로 생겨나는 것이다. 그럼 저렇게 볼륨을 통해 연결했을 경우, 호스트의 /home/wordpress_db 디렉터리에 어떤 파일이 생겼는지 아래처럼 살펴보자.(참고로, 볼륨을 통해 연결하기 전, 호스트에 wordpress_db 라는 디렉터리를 미리 생성하지 않아도 된다. 왜냐하면 볼륨로 연결할 때 도커 엔진이 자동으로 이를 생성해주기 때문)

 

호스트의 /home/wordpressdb 디렉터리에 MySQL 관련 파일이 생김

 

그러면 위 파일들의 출처인  MySQL 컨테이너를 삭제하면 어떻게 될까? 호스트의 wordpressdb 디렉터리에 있던 파일들이 삭제가 될까? 아래 명령으로 컨테이너를 삭제 후, 호스트 디렉터리를 확인해보면 여전히  파일이 존재하는 것을 알 수 있다.

 

$ docker stop wordbressdb_hostvolume
$ docker rm wordbressdb_hostvolume
$ ls /home/wordpressdb

 

이것이 바로 컨테이너의 데이터를 영속적으로 유지하기 위한 방법 중 하나로서 호스트와 컨테이너를 볼륨으로 연결해 특정 디렉터리를 공유하는 '호스트 볼륨 공유'이다. 참고로 호스트 볼륨 공유는 위에서 해본 예시처럼 디렉터리 단위 뿐만 아니라 특정 파일 단위까지도 공유가 가능하다. 그리고 -v 옵션을 연속적으로 두어서 여러개의 파일 또는 디렉터리를 공유할 수 있다.

 

$ docker run -it \
--name file_share_container \
-v /home/host_share.txt:/container_share.txt \
-v /home/host_dir:/container_dir \
ubuntu:14.04

 

그런데, MySQL 컨테이너를 생성할 때 볼륨을 활용한 예시는 데이터가 호스트에는 없고 컨테이너에만 있던 예시이다. 즉, 이 때 볼륨을 사용하게 되면 데이터가 [컨테이너 ➜ 호스트] 로 복사된다. 그렇다면 만약에 호스트에도 이미 데이터가 존재하면 어떻게 될까? 결론부터 말하면 -v 옵션을 통한 호스트 볼륨 공유는 말 그대로 호스트의 데이터를 컨테이너로 마운트하게 된다. 즉, 정리하면 아래와 같은 경우의 수들이 있고, 마운트의 주체가 다음과 같다. 참고로 이렇게 호스트 볼륨을 활용해 공유되는 호스트와 컨테이너의 두 디렉토리는 동기화되는 것이 아니라 완전히 같은 디렉터리이다. 개인적으로 책에서의 이 문장이 잘 이해가 안되어서 책 저자분께 직접 질문드려 답변을 받았는데, 여기에서 확인이 가능하다

 

volume 옵션 시, 마운트의 주체는 언제 호스트이고 언제 컨테이너일까?

5-2. 이미 볼륨으로 연결된 컨테이너로부터 볼륨하자, 볼륨 컨테이너

볼륨을 사용하는 두 번째 방법은 이미 -v 옵션으로 볼륨을 사용하는 컨테이너 즉, [목차 5-1]에서 -v 옵션으로 호스트와 연결된 컨테이너를 일종의 부모로 하여 또 다른 컨테이너를 생성하는 것이다. 이렇게 생성된, 마치 자식(Child) 같은 컨테이너는 부모가 이미 볼륨으로 호스트와 연결되어 있는 상태이기 때문에 자식 컨테이너 또한 볼륨으로 호스트와 이미 연결되어 있는 상태이다. 그래서 명령어도 --volumes-from 이라는 'from' 전치사가 들어간 명령어를 사용한다. 하지만 이는 직접 볼륨을 공유하는 것이 아니라 앞서 설명한 것처럼 이미 -v 옵션이 적용된 컨테이너를 통해 공유하는 것이기 때문에 간접 볼륨 공유라고 볼 수 있다. 이런 방법은 여러개의 컨테이너가 동일한 컨테이너에 --volumes-from 옵션을 사용함으로써 볼륨을 공유해 사용할 수 있다. 결국, 여러개의 컨테이너가 데이터를 간접적으로 공유받는 방식이다. 이를 도식화하면 아래와 같다.

 

--volumes-from 옵션을 통한 데이터 공유

5-3. 도커 자체에서 제공하는 볼륨 기능, docker volume 명령어

볼륨을 활용하는 세 번째 방법은 도커 자체에서 제공하는 볼륨 기능을 활용하는 것이다. docker volume 명령어로 볼륨을 다룰 수 있다. 먼저 볼륨을 한번 생성해보고 생성된 볼륨들을 출력해보자.

 

$ docker create volume --name my_volume
$ docker volume ls

 

생성한 볼륨을 출력

 

2개의 해쉬값으로 이루어진 또 다른 불륨들이 존재하는데, 이는 이전에 필자가 실습하면서 생성했던 볼륨이니 신경쓰지말자. 해쉬값으로 되어 있는 볼륨이름의 의미는 아래에서 알게된다. 어쨌건 my_volume 이라는 새로운 볼륨이 생성되었다. 그러면 이 볼륨을 사용하는 컨테이너를 생성해보자. 우선 아래 명령어를 사용해서 컨테이너를 만든 후, 내부로  들어가 특정 dummy 파일을 생성시켜보자.

 

$ docker run -it --name volume_container_1 \
-v myvolume:/testdir/ \
ubuntu:14.04

$ echo "Hello zedd" >> /testdir/zedd.txt

 

주의할 점은 여기서도 -v 옵션을 사용한다는 것이다. 호스트 볼륨 공유 방법에서도 -v 옵션을 사용했지만, 명시하는 인자의 의미는 그 때와 다르다.

 

# 호스트 볼륨 공유 시
-v [HOST 디렉터리]:[CONTAINER 디렉터리]

# 볼륨 활용 시
-v [VOLUME 이름]:[CONTAINER 디렉터리]

 

참고로 -v 옵션을 줄 때 명시하는 호스트, 컨테이너 디렉터리 모두 존재하지 않더라도 명령어를 수행하면서 자동으로 생성해준다. 어쨌건 위 명령어를 입력하면 /testdir/zedd.txt 라는 파일이 생긴다. 그런 다음 다시 호스트로 나와보자. 이 때 volume_container1 컨테이너로부터 빠져나올 때 해당 컨테이너를 실행시킨 채로 나오던 중지시키고 나오던 상관 없다. 그리고 아래 명령어를 사용해서 myvolume이라는 볼륨을 활용하는 또 다른 컨테이너를 생성해보자. 그리고 그 내부로 들어가 zedd.txt 라는 파일이 있는지 살펴보자.

 

$ docker run -it --name volume_container2 \
-v myvolume:/testdir2/ \
ubuntu:14.04

$ cat < /testdir2/zedd.txt

 

 

이렇게 볼륨을 활용함으로써 데이터를 여러 개의 컨테이너에 공유하여 활용할 수 있게 된다. 참고로 볼륨은 디렉터리 하나에 상응하는 단위로서 도커 엔진에서 관리하게 된다. 만약 볼륨을 활용할 때 특정 파일(예를 들어, txt 파일 확장자를 넣는다고 해도)을 명시한다고 해도 디렉터리로 간주하게 된다.(의심이가서 직접 해봄..)

 

그러면 호스트 볼륨 공유와 볼륨을 활용하는 것 간에 차이는 무엇일까? 바로 데이터가 실제로 어디에 저장되는지 알 필요가 있냐없냐는 것이다. 호스트 볼륨 공유는 -v 옵션을 사용할 때 호스트의 디렉터리를 직접 명시했다. 따라서 호스트 볼륨 공유를 사용하는 사용자는 공유되는 데이터가 호스트의 디렉터리에서 어디에서 저장되고 있는지 바로 알 수 있다. 하지만 볼륨을 활용할 때는 단지 볼륨과 컨테이너 디렉터리만 명시하기 때문에 데이터 파일이 호스트에서 실제로 어디에 저장되는지 알 필요가 없게 된다.

 

그러면 볼륨을 활용할 때 데이터 파일이 실제로 호스트의 어디에 저장되는지 알 수 없는걸까? 아니다. docker inspect 관련 명령어를 활용해서 사용하는 볼륨을 명시에 정보를 출력해볼 수 있다.

 

$ docker inspect --type volume myvolume

 

볼륨의 정보를 출력

 

위 출력화면에서 Driver는 볼륨이 쓰는 플러그인 드라이버를 의미한다. 여기서 플러그인 드라이브란, 여러 종류의 스토리지 백엔드를 쓸 수 있게 해주는 것이다. 현재 로컬 호스트 스토리지를 쓰기 때문에 local로 명시된 듯 하다. 다음은 Label이다. Label은 볼륨을 구분하는 일종의 표기를 의미하며 Mountpoint가 바로 해당 볼륨이 데이터를 실제로 호스트의 어디에 저장했는지를 의미한다. 실제로 호스트에서 해당 경로로 가보면 zedd.txt 파일이 있는 것을 알 수 있다.

 

Mountpoint 경로로 가면 호스트에 저장된 볼륨 데이터를 확인 가능

 

그리고 볼륨을 활용할 때 굳이 docker volume create 명령어를 사용하지 않고 컨테이너를 생성할 때 별도로 명시해주지 않으면 자동으로 볼륨을 생성해준다. 다만, 그렇게 생성해준 볼륨의 이름은 16진수 해쉬값으로 생성된다. 해당 컨테이너가 사용하고 있는 볼륨이 무엇인지 보려면 컨테이너 정보를 출력해주는 inspect 명령어를 입력한 후 나오는 출력에서 Source 부분을 확인하면 된다.

 

$ docker run -it --name auto_volume \
-v /autodir/ \
ubuntu:14.04

호스트로 나온 뒤
$ docker container inspect auto_volume | grep "Source"

 

Source 부분은 볼륨을 활용한 컨테이너가 호스트의 어떤 볼륨을 이용하는지 보여줌

 

이렇게 여러가지 볼륨을 생성하고 활용한 뒤 볼륨이 적용된 컨테이너를 삭제한다고 해도 그 볼륨은 자동으로 삭제되지 않는다. 따라서 더이상 사용하지 않는 볼륨을 아래 명령어로 삭제해줄 수 있다.

 

$ docker volume prune

 

참고로 도커 볼륨을 활용할 때 -v 옵션이 아닌 --mount 옵션을 사용할 수도 있는데, mount 옵션을 사용하게 되면 명시하는 방식이 약간 달라진다. 마치 프로그래밍 언어에서 함수 인자처럼 전달해주어야 하는데, type에는 마운트할 종류 즉, 여기서는 '볼륨'을 명시하고 source에는 활용할 볼륨 이름, target은 컨테이너 디렉터리를 명시해준다. mount 옵션을 활용한 예시는 아래와 같다. 그리고 만약 mount 옵션을 가지고 호스트 볼륨 공유를 하려고 한다면 type에 bind 를 명시해주면 된다.

 

$ docker run -it --name mount_container \
--mount type=volume,source=mount_volume,target=/mountdir/ \
ubuntu:14.04

$ docker run -it --name bind_container \
--mount type=bind,source=/host/dir/,taget=/container/dir/ \
ubuntu:14.04

 

(* 위 명령어에서 콤마 뒤에 공백 있어선 안됨에 주의!)

---

지금까지 컨테이너가 아닌 다른 외부에 데이터를 영속적으로 저장하고 그 컨테이너는 외부의 데이터를 공유하면서 동작하도록 하는 3가지 방법을 배웠다. 이러한 설계를 Stateless 하다고 말한다. 즉, 컨테이너 자체는 상태(State)가 없고 그 상태를 결정하는 데이터는 외부로부터 제공받는다는 의미이다. 이러한 Stateless 설계는 도커를 사용할 때 매우 권고되는 방식이다. 이와 반대로 컨테이너 내부에 데이터를 저장하고 있는 경우, 상태가 있다고 하여 Stateful 하다고 하는 점도 알아두자.

6. 도커 네트워크

다음 목차에서 알아볼 내용은 도커 네트워크이다. 목차 [3.컨테이너를 외부에 노출하기] 를 위에서 배우면서 포트 포워딩(-p 옵션)을 통해 호스트와 컨테이너 간에 통신을 가능케 했다. 그리고 [4.컨테이너 애플리케이션 구축] 목차에서 MySQL 컨테이너와 워드프레스 컨테이너를 연결할 때 --link 옵션을 사용했었다. 여기에서는 포트 포워딩을 이용하지 않고, 또 --link 옵션을 사용하지 않고 도커 네트워트 기능을 활용해서 컨테이너를 외부에 노출시키는 방법에 대해 알아보도록 하자. 그 첫 순서로 도커 네트워크의 구조부터 차근차근 배워보도록 하자.

6-1. 도커 네트워크 구조 파헤치기

도커는 컨테이너를 생성할 때마다 내부 IP를 순차적으로 할당한다고 했다. 그리고 이 IP는 컨테이너를 재시작할 때마다 변경된다고 했다. 이 내부 IP는 '외부'에 해당하는 호스트(VM 머신)과 통신을 할 필요가 있다. 그래서 컨테이너는 시작할 때마다 호스트에 'veth' 로 시작하는 가상(v=virtual) 네트워크 인터페이스를 생성하는데, 이를 통해 외부(호스트)와 통신할 수 있게 도와준다.

 

아래 명령어로 호스트에서 도커 컨테이너를 생성한 후, 호스트의 네트워크 인터페이스를 출력해보자.(단, 반드시 생성한 도커 컨테이너가 실행중인 상태여야만 호스트에 'veth'로 시작하는 네트워크 인터페이스가 생긴다)

 

$ docker run -i -t -d --name container_test ubuntu:14.04
$ ifconfig

 

 

위 출력화면은 호스트의 네트워크 인터페이스이다. 이더넷을 의미하는 enp0s3라고(CentOS에서의 eth0과 표기법만 달라짐. 자세한 것은 여기서 확인) 있는데, 이것이 공인 IP 또는 내부 IP가 할당되어 실제로 외부(호스트의 입장에서 외부니까 컨테이너 내부 IP가 될 수 있겠음)와 통신할 수 있는 호스트의 네트워크 인터페이스이다. 반면에 veth로 시작하는 인터페이스를 보면 이더넷과 연결되어 있음을 볼 수 있다. 그리고 추가적으로 볼 필요가 있는 네트워크 인터페이스가 있는데, docker0 라는 것이다. 이를 브리지 네트워크라고 부르는데, 네트워크 브리지에 대해서는 아래에서 자세히 알아본다. 어쨌건 이 docker0가 하는 역할은 veth로 시작하는 인터페이스와 바인딩되어 호스트의 enp0s3 와 연결해주는 역할을 한다. enp0s3 와 veth로 시작하는 인터페이스, docker0 간에 관계를 도식화 하면 아래와 같다.

 

도커 네트워크 구조

 

실제로 veth로 시작하는 컨테이너가 docker0 브리지와 바인딩 되어 있는지 확인하려면 리눅스의 브리지 설정 관련 명령어인 brctl를 사용해서 확인할 수도 있다.

 

$ sudo apt-get install brctl-utils
$ brctl show docker0

 

 

interfaces 항목에 있는 값이 해당 브리지와 바인딩된 네트워크 인터페이스를 의미하는데, 위 출력결과를 보면 docker0 라는 브리지가 veth로 시작하는 이름의 인터페이스와 바인딩 되어 있는 것을 볼 수 있다. 

 

그러면 이제 도커 네트워크의 기능을 활용해서 컨테이너를 외부에 노출시켜보도록 하자. 여기서 네트워크의 드라이버를 다르게 설정할 수가 있는데, 대표적인 네트워크 드라이버로는 브리지, 호스트, 논(none), 컨테이너, 오버레이가 있으며 서드파티 드라이버로는 weave, flannel, openvswitch 등이 있다고 한다. 해당 책에서는 도커 자체만으로 쉽게 사용 가능한 브리지, 호스트, 논, 컨테이너에 대해 배운다. 위에서 배운 docker0는 브리지 네트워크 드라이버에 해당하며 기본적인 네트워크 드라이버로 설정된다. 도커에서 사용할 수 있는 네트워크 드라이버가 무엇이 있는지 출력해보자.

 

bridge, host, none 네트워크 드라이버가 존재

6-2. 나만의 브리지를 생성해 연결해보자. 브리지 네트워크

브리지 네트워크는 사용자가 docker0 처럼 내가 직접 브리지 네트워크를 생성해 각 컨테이너에 연결하는 네트워크 구조이다. 이렇게 생성한 브리지 네트워크를 활용하는 여러 개의 컨테이너를 만들면 이 컨테이너들 간에 통신이 가능해진다. 우선 브리지 네트워크를 생성하는 명령어는 아래와 같다.(단, 브리지 네트워크 생성 시 서브넷, IP 범위, 게이트웨이도 맘대로 설정이 가능하다)

 

$ docker network create --driver bridge [BRIDGE NAME]
$ docker network create --driver bridge zedd_bridge

 

이제 --net 옵션으로 내가 만든 브리지 네트워크를 사용하는 컨테이너를 아래처럼 생성해보자.

 

$ docker run -it --name zedd_bridge_container \
--net zedd_bridge \
ubuntu:14.04
$ ifconfig

 

브리지 네트워크에서 한 가지 더 알아볼 것이 있다. 바로 --net-alias 옵션을 활용하는 것이다. 브리지 네트워크와 해당 옵션을 함께 사용하면 alias로 별명을 지어준 호스트 이름으로 컨테이너 여러개와 통신할 수가 있다. 우선 alias_bridge 라는 이름의 브리지 네트워크를 별도로 하나 더 생성해보자.

 

$ docker network create --driver bridge alias_bridge

 

이후, --net-alias 옵션과 alias_bridge 네트워크를 사용하는 컨테이너 3개를 생성해보자. 여기서는 alias 값으로 zedd 라는 호스트 이름으로 명시하였다.

 

$ docker run -it -d --name alias_container_v1 \
--net alias_bridge \
--net-alias zedd \
ubuntu:14.04
$ docker run -it -d --name alias_container_v2 \
--net alias_bridge \
--net-alias zedd \
ubuntu:14.04
$ docker run -it -d --name alias_container_v3 \
--net alias_bridge \
--net-alias zedd \
ubuntu:14.04

 

위 명령어로 만든 3개의 컨테이너 각각에 서로 다른 IP주소(끝자리만 값이 바뀐 채)가 할당된 것을 알 수 있다. 직접 보려면 docker container inspect [CONTAINER] 명령어를 사용하면 된다.

 

그리고 난 뒤, alias_bridge 이름의 브리지 네트워크를 사용하는 컨테이너를 또 하나 생성한 뒤, 내부로 들어가 위 3개의 컨테이너 각각에 대하여 수신받는 컴퓨터의 동작 여부 및 네트워크 상태를 파악할 수 있는 ping 요청을 전송해보자.

 

$ docker run -it --name test_alias_container \
--net alias_bridge \
ubuntu:14.04
$ ping -c 1 zedd
$ ping -c 1 zedd
$ ping -c 1 zedd

 

위에서 사용한 ping 명령어는 패킷을 1번(c=count) zedd 라는 도메인 네임을 갖는 IP 주소를 갖는 서버에 보내보는 것이다. 

 

ping 테스트 결과 화면

 

3번을 테스트 했을 때, 1번은 v2의 컨테이너에, 2번은 v1의 컨테이너에 요청을 보냈다. v3의 컨테이너는 확률적으로 선택받지 않은 것이다. zedd라는 호스트 이름에 총 3개의 컨테이너 IP 주소가 연결되어 있는데, 이 중 어떤 것을 선택할지는 특정 우선순위 없이 돌아가며 할당되는 라운드 로빈 알고리즘을 기반으로 결정된다고 한다.

 

그렇다면 zedd 라는 이름으로 alias를 시켰는데 대체 어떻게 알아서 그 IP 주소 3개를 찾아올 수 있었던 걸까? 이게 가능한 이유는 도커 DNS 서버가 내장되어 있기 때문이다. 이 도커 DNS를 이용하는 또 다른 사례는 [목차 4.컨테이너 애플리케이션 구축하기]에서 알아본 --link 옵션을 사용하면 alias를 가능하게 했던 것이 있다. 단, --net-alias 옵션과 --link 옵션 간의 차이라고 한다면 어떤 도커 DNS를 사용하느냐의 차이가 있다. --link 옵션은 기본적으로 설정된 브리지 네트워크의 컨테이너 DNS를 사용하는 것이고, --net-alias는 사용자가 만들었던 브리지 네트워크(위 예시에서는 alias_bridge가 되겠음)의 컨테이너 DNS를 사용한다. 

 

--net-alias에서 사용하는 도커 DNS 서버의 IP 주소는 $127.0.0.11$ 이다. 그럼 이제 관계를 정리해보자. 브리지 네트워크, --net-alias 옵션, 도커 DNS 서버 간의 관계는 아래와 같다.

 

 

만약 도커 내장 DNS 서버 내에 있는 호스트 네임과 매핑된 IP 주소를 눈으로 직접 확인해보고 싶다면 dig 명령어를 사용해서 확인할 수 있다. dig 명령어를 사용하기 위해 dnsutils 패키지를 설치한 후, 아래 명령어를 사용해 확인해보자. 

 

$ apt-get update; apt-get install dnstutils
$ dig zedd

 

6-3. 호스트의 네트워크 환경을 그대로 갖다 쓰자. 호스트 네트워크

이번엔 네트워크 드라이버를 호스트로 설정하는 호스트 네트워크를 활용해보자. 호스트 네트워크란, 호스트의 네트워크 환경을 컨테이너에 그대로 사용하는 것이다. 호스트 네트워크를 사용할 때는 브리지 네트워크 때처럼 docker network create 명령어를 사용해서 별도로 생성하지 않고 --net 옵션에 'host' 라는 문자를 입력해서 사용하면 된다.

 

$ docker run --it --name zedd_host_container \
--net host \
ubuntu:14.04

 

위 명령어를 입력하면 호스트 네트워크를 활용하는 컨테이너 내부로 들어가는데, 특이하게 컨테이너의 호스트 이름이 호스트의 호스트이름과 동일한 것을 볼 수 있다. 이유는 간단하다. 컨테이너가 호스트 네트워크를 그대로 갖다 사용하기 때문!

 

이렇게 호스트 네트워크를 사용하게 되면 컨테이너 생성 시 포트포워딩(-p 옵션)을 사용하지 않고도 컨테이너를 외부에 노출할 수 있다. 위 목차에서 포트 포워딩을 배울때 해보았던 실습을 똑같이 수행해보자.

 

우선, 아래 명령어로 호스트 네트워크를 활용하는 컨테이너를 생성한 후, 해당 컨테이더 내부로 들어가 아파치 웹서버를 설치한 뒤 웹서버를 실행시켜보자.

 

$ docker run -it --name host_network_container \
--net host \
ubuntu:14.04
$ docker run -it --name mywebserver -p 127.0.0.1:3333:80
$ apt-get update
$ apt-get install apache2 -y
$ echo "ServerName localhost" >> /etc/apache2/apache2.conf
$ service apache2 start

 

그리고 Ctrl+P,Q를 눌러 아파치 웹서버가 돌아가고 있는 컨테이너를 실행시켜둔 상태로 빠져나와 호스트에서 컨테이너로 curl 테스트를 날려보자. 그러면 HTML 코드가 response로 반환되는 것을 볼 수 있다.(아래 명령어의 10.0.0.2.15는 호스트의 IP 주소이며 80포트번호는 아파치 웹서버의 정해진 포트 번호이다)

 

$ curl http://10.0.0.2.15:80

6-4. 컨테이너를 외부와 단절시키기, 논(none) 네트워크

논 네트워크는 말 그대로 아무런 네트워크를 사용하지 않는다는 것을 의미한다. 즉 생성한 컨테이너와 외부간의 통신을 차단하는 셈이다. --net 옵션에 none 문자를 명시해줌으로써 설정할 수 있다. 논 네트워크를 활용해서 만든 컨테이너 내부로 들어가 ifconfig 명령어를 쳐서 네트워크 인터페이스를 살펴보면 로컬 호스트를 의미하는 lo 밖에 존재하지 않는 것을 볼 수 있다.

 

$ docker run -it --name non_container \
--net none
ubuntu:14.04
$ ifconfig

 

lo 네트워크 인터페이스 밖에 존재하지 않음

6-5. 다른 컨테이너의 네트워크 환경을 그대로 갖다 쓰자. 컨테이너 네트워크

이번엔 다른 컨테이너의 네트워크 인터페이스 환경(내부 IP 주소, Mac주소 등)을 그대로 가져와 사용하는 컨테이너 네트워크를 활용할 수 있다. --net 옵션에는 container 라는 문자와 가져와 사용할 컨테이너 이름을 명시해준다. 우선 일반적인 컨테이너를 detached 모드로 1개 생성한 후, 해당 컨테이너의 네트워크를 사용하는 또 다른 네트워크를 생성해보자.

 

$ docker run -it -d --name container_network_orig \
ubuntu:14.04
$ docker run -it --name container_network \
--net container:container_networkd_orig \
ubuntu:14.04

 

위와 같이 컨테이너 네트워크를 활용하면, container_network 이름의 컨테이너 네트워크 환경에서는 새로운 내부 IP를 할당받지 않는다. 또한 원래대로라면 컨테이너를 하나 더 생성한 것이기 때문에 그에 할당되는 veth로 시작하는 가상 네트워크 인터페이스도 호스트에 하나 더 생성되어야 하는데 이것도 생성되지 않는 것을 볼 수 있다. 왜냐하면 container_network 이름의 컨테이너container_network_orig 라는 컨테이너의 네트워크 환경을 그대로 가져다 쓰기 때문이다.

7. 컨테이너 로깅하기

애플리케이션이나 컨테이너에서 로그를 남기는 것은 서비스를 운영하는 측면에서도 중요한 요소이다. 도커 컨테이너는 자체적으로 표준 철력과 표준 에러 로그를 별도의 메타데이터인 json 포맷 형태 파일로 저장을 하고, 이를 확인하는 명령어도 제공한다. 관련 명령어는 다음과 같다.

 

명령어	옵션	의미
docker logs [CONTAINER]		특정 컨테이너 내부에서 발생하는 로그를 확인
	--tail [N]	로그의 마지막 N줄만 확인
	--since [unix timestamp|timestamp|Go time]	명시한 시간 이후의 로그만 확인(자세한 것은 여기)
	--timestamps 또는 -t [timestamp]	명시한 시간 이후의 로그만 확인
	-f	로그를 실시간으로 확인

 

그러면 MySQL 이미지를 기반으로 하는 컨테이너를 detached 모드로 실행시켜보자. 이 때, MySQL 이미지 특성 상 반드시 환경변수 옵션을 넣어주어야 실행된다. 그리고 해당 컨테이너의 로그를 확인해보자.

 

$ docker run -d --name mysql_container \
-e MYSQL_ROOT_PASSWORD=1111 \
mysql:5.7
$ docker logs --tail 10 mysql_container

 

이렇게 확인할 수 있는 로그의 json 원본은 호스트 파일시스템의 아래 경로에서 확인할 수 있다.

 

$ cat < /var/lib/docker/containers/[CONTAINER ID]/[CONTAINER ID]-json.log

 

참고로 이러한 로그 파일이 너무나 커지거나 양이 많아지면 호스트의 파일 시스템을 매우 크게 차지하는 문제가 발생하기 때문에 이를 예방하기 위해 컨테이너 생성 시 --log-opt 옵션을 주어 생성할 로그 파일의 크기 및 개수를 제한할 수 있다.

 

명령어	옵션	의미
docker run [CONTAINER]	--log-opt max-size=10k	로그 파일의 크기를 10 킬로바이트로 설정(k는 킬로바이트, m는 메가바이트, g는 기가바이트로 설정 가능)
	--log-opt max-file=3	로그 파일의 개수를 최대한 3개로 제한

 

이러한 json-file 형태로 로깅하는 것은 별다른 로깅 드라이버를 설정하지 않았다면 디폴트로 적용되는 로깅 방법이다. 대표적인 로깅 드라이버로는 syslog, journald, fluentd, awslogs 등이 있다고 한다. 로깅 드라이버를 활용한 예제는 원본 책을 참고하도록 하자.

---

지금까지 해서 도커엔진에서 컨테이너를 다루는 기본적인 방법에 대해 배워보았다. 다음 포스팅에서는 도커 이미지를 다루는 방법에 대해서 배워보도록 하자.