[Docker] 여러 개의 컨테이너를 하나로 묶어 관리하자, Docker Compose

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

 

Docker

---

이번 포스팅에서는 (이전에 얕게나마 배웠던) 여러 개의 컨테이너를 하나의 서비스로 정의하여 컨테이너 묶음으로 관리할 수 있도록 작업 환경을 제공하는 도커 컴포즈에 대해 배워보자.

1. 도커 컴포즈가 왜 필요할까?

도커 컴포즈를 본격적으로 배우기에 앞서 근본적인 질문부터 해보자. 도커 컴포즈를 배우고 사용해야 하는 이유는 무엇일까? 이유는 바로 하나의 애플리케이션 서비스는 보통 여러 개의 컨테이너 서비스들이 동시에 동작하는 것으로 구성되기 때문이다. 지금까지 우리는 일반적인 도커 엔진에서 컨테이너 단위로 제어할 때도, 도커 스웜을 배울 때도 하나의 어플리케이션에 대한 동작만 다룰 수 있었다. 예를 들어 MySQL DB 서버 역할을 하는 컨테이너를 생성했을 때, 우리는 MySQL 컨테이너 1개 만을 제어하거나, 도커 스웜에서 MySQL 컨테이너들로 구성된 서비스들만 제어했었다. 

 

하지만 일반적인 애플리케이션은 하나의 컨테이너가 아닌 여러 개의 서로 다른 역할을 하는 컨테이너들로 동작한다. 일례로, 워드 프레스 블로그 웹 페이지 서비스를 개발한다고 쳐도, 웹 페이지를 보여주는 웹서버 역할 컨테이너와 웹 페이지의 데이터를 가지고 있는 MySQL 서버 총 2개 종류의 컨테이너가 동시에 동작해야 한다.

 

위와 같은 상황에서 그동안은 우리는 각각의 컨테이너마다 손수 실행시켜주고 잘 동작하는지 테스트를 해보아야만 했다. 그런데 만약 구현하려는 애플리케이션이 5개, 10개, 더 나아가 10개 이상 종류의 컨테이너들 간의 동작으로 이루어진다고 한다면 그 때마다 일일이 컨테이너를 하나씩 실행시켜주고 테스트하는 것은 여간 귀찮은 작업이 아닐 것이다. 

 

이러한 문제점을 해결하기 위해 도커 컴포즈가 등장한다. 다시 말해, 도커 컴포즈는 컨테이너를 이용한 서비스의 개발과 CI(Continuous Integration, 지속적 통합)를 위한 여러 개의 컨테이너를 하나의 프로젝트로서 다룰 수 있는 작업 환경을 제공한다. 구체적으로, 도커 컴포즈는 여러 개의 컨테이너 옵션과 환경을 미리 정의해 놓은 파일(이전에 배웠던 Dockerfile 처럼)을 읽어서 컨테이너를 순차적으로 생성하여 실행시킨다. 심지어 컨테이너 실행 순서 뿐만 아니라 각 컨테이너의 의존성, 네트워크, 볼륨 등 우리가 컨테이너 다루기 포스팅에서 배웠던 여러가지 기능들도 미리 정의할 수 있다. 또한 도커 컴포즈는 미리 정의해 놓은 파일 안에 특정 서비스의 역할을 할 컨테이너 생성 개수를 지정할 수도 있기 때문에 도커 스웜처럼 여러 호스트 환경에서의 컨테이너의 수를 유동적으로 조절할 수가 있으며, 신기하게도 생성되거나 삭제하는 컨테이너를 자동으로 감지하는 작업 발견(Service Discovery)도 수행한다.

 

이 정도면 도커 컴포즈를 사용할 만한 이유를 충분히 찾은 것 같다. 이제 도커 컴포즈를 다루는 방법에 대해 배워보도록 하자. 

2. 도커 컴포즈를 사용해보자

만약 사용하고 있는 OS가 리눅스라고 한다면 도커 컴포즈를 직접 설치해주어야 한다. 윈도우나 맥의 도커 엔진을 사용하고 있다면 도커 엔진 설치 시 도커 컴포즈가 자동으로 설치되므로 맥이나 윈도우의 경우 아래 명령어를 실행해줄 필요는 없다. 참고로 책에서는 도커 컴포즈 1.11.0 버전을 기준으로 한다. 현재 공식 깃헙에 가보면 2.17.3 버전까지 나온 듯 하다.

 

$ curl -L https://github.com/docker/compose/releases/download/1.11.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
$ chmod +x /usr/local/bin/docker-compose

 

잘 설치했다면 아래 명령어를 실행해서 도커 컴포즈의 버전을 확인해보자.

 

$ docker-compose -v

 

도커 컴포즈는 컨테이너들의 설정이 정의된 YAML 파일을 읽어서 도커 엔진을 통해 컨테이너를 생성하게 된다. 이 때 YAML 파일은 (어떠한 설정도 하지 않는다면)반드시 docker-compose.yml 이라는 이름의 파일로 정의되어 있어야 한다. 참고로 YAML 파일 작성 시 들여쓰기를 할 때는 탭(Tab)을 사용해서는 안된다. 왜냐하면 도커 컴포즈가 탭을 인식하지 못하기 때문이다. 따라서 탭 대신 2개의 공백을 사용해서 하위 항목을 구분해 파일 내용을 작성하도록 하자.

 

YAML 파일을 보기 전에, 어떤 애플리케이션을 구현하려고 하는 것인지 YAML 파일 대신 docker run 명령어로 먼저 살펴보자.

 

$ docker run -d \
--name mysql \
alicek106/composetest:mysql \
mysqld

$ docker run -d \
-p 80:80 \
--link mysql:db --name web \
alicek106/composetest:web \
apachectl -DFOREGROUND

 

위 내용을 docker-compose.yml 파일 형식으로 변경하면 아래와 같다.

 

version: '3.0'
services:
  web:
    image: alicek106/composetest:web
    ports:
      - "80:80"
    links:
      - mysql:db
    command: apachectl -DFOREGROUND
  mysql:
    image: alicek106/composetest:mysql
    command: mysqld

 

위와 같은 내용의 YAML 파일을 작성하고 해당 파일이 있는 경로에서 아래 명령어를 입력해 도커 컴포즈를 실행시켜보자.

 

$ docker-compose up -d

 

그리고 docker ps 명령어를 쳐서 실행중인 컨테이너를 출력해보면 YAML 파일에서 정한 컨테이너 2개가 실행중인 것을 알 수 있다. 그러면 이제 위에서 정의한 YAML 파일 내용의 키워드 의미에 대해 간단히 알아보도록 하자.

 

키워드	의미	특징
version	YAML 파일의 포맷 버전을 의미	버전에는 1.0, 2.0, 3.0 등이 있으며 도커 컴포즈 1.8은 버전 2.0을, 도커 컴포즈 1.9는 버전 2.1을 사용. 현재 버전 1.0은 사용되지 않음
services	생성될 컨테이너를 묶어놓은 단위	서비스 하위 항목들에는 생성될 컨테이너에 적용시킬 여러가지 옵션, 설정을 명시
(위 예시에서의) web, mysql	생성될 서비스의 이름	이 키워드의 바로 하위 항목에 해당 서비스 역할을 하는 컨테이너들에 대한 설정 값을 명시할 수 있음

 

다음은 도커 컴포즈를 사용하면서 알아두어야 할 개념들 배워보도록 하자. 우선 위에서 실습을 하면서 생성된 두 컨테이너의 이름을 한 번 살펴보자. 도커 컴포즈를 활용해서 생성된 컨테이너들이라면 아래와 같은 이름으로 컨테이너가 생성되었을 것이다.

 

 

이름을 잘 보면 dockercompose_web_1 , dockercompose_mysql_1 이라는 이름으로 생성되었다. 이름은 아래와 같은 형식을 따른다.

[프로젝트 이름]_[서비스 이름]_[서비스 내 컨테이너 번호]

 

즉, 이름의 web, mysql 이라는 단어를 보면, 도커 컴포즈는 생성될 컨테이너들의 이름을 서비스 단위로 구분하여 자동생성한다. 또한 앞에 dockercompose라는 단어는 현재 YAML 파일이 있는 디렉토리 이름이다. 이를 프로젝트라고도 한다. 서비스? 프로젝트? 아니 도커 스웜일 때도 서비스라는 개념이 있었는데..? 점점 헷갈리기 시작한다.. 이 쯤에서 도커 컴포즈에서의 컨테이너 구분 단위인 프로젝트, 서비스에 대한 개념을 배워보자.

 

우선 위 예시에서는 현재 web이라는 컨테이너와 mysql 이라는 컨테이너가 1개씩 생성된 상황임을 가정하고 아래 그림을 보자.

 

docker-compose의 프로젝트, 서비스, 컨테이너 개념을 알아보자

 

우선 프로젝트, 서비스, 컨테이너 중 가장 상위(?)개념이라고 할 수 있는 것은 프로젝트이다. 프로젝트는 여러 개의 서비스들을 담고 있다. 위에서 프로젝트의 이름이 DockerCompose 라고 명시되어 있다. 위 예시에서 터미널 화면을 보면 docker-compose.yaml 파일이 존재하는 디렉토리 이름이 바로 DockerCompose이기 때문이다. 도커 컴포즈를 실행하기 위해 위에서 우리는 docker-compose up -d 라는 명령어를 입력했는데, 이 때 아무런 인자로도 프로젝트 이름을 명시해주지 않으면 기본적으로 docker-compose.yaml 파일이 있는 현재 디렉토리 또는 그 상위의 디렉토리 이름을 프로젝트 이름으로 설정한다. 여기서 상위의 디렉토리여도 도커 컴포즈가 알아서 찾는 점이 Dockerfile 때와는 차이점이 있는 듯 하다. 도커 컴포즈는 docker-compose 명령어를 실행할 때, docker-compose.yaml 파일이 반드시 하위 디렉토리에만 없으면 알아서 찾는다. 

 

이제 서비스를 알아보자. 하나의 서비스는 여러개의 컨테이너들을 담고 있다. 그리고 그 서비스 안에 담겨있는 컨테이너들은 모두 동일한 이미지를 기반으로 생성된 컨테이너들이다. 즉, 위 예시에서는 web 이라는 서비스 이름 내에 있는 컨테이너들은 모두 웹서버 역할만을 하고, mysql 이라는 서비스 이름 내에 있는 컨테이너들은 모두 DB역할 만을 한다.

 

마지막으로 컨테이너에 대해 알아보자. 컨테이너는 지금까지 우리가 배운 그 컨테이너의 개념이 맞다. 여기서는 컨테이너의 이름에 주목해보자. 위 그림에서는 컨테이너 이름이 dockercompose_web_1 이라고 되어 있다. 이제 추측할 수 있다시피 앞의 dockercompose 라는 단어는 프로젝트의 이름(프로젝트 이름에 대문자가 들어가긴 하지만 모두 소문자화되어서 컨테이너 이름에 붙음)이며 그리고 web 은 서비스의 이름이다. 마지막의 1 이라는 번호는 해당 서비스 내에 생성된 컨테이너의 번호이다. 위에서 빨간색 점선 네모칸으로 둘러싼 컨테이너 2개가 있는데, 이는 서비스 내에서 컨테이너가 여러개 생성될 수 있음을 의미한다. 그래서 만약 컨테이너가 2개 추가적으로 생성되면 각 컨테이너의 이름은 dockercompose_web_2, dockercompose_web_3 가 되겠다. 참고로 도커 스웜 때처럼 docker-compose 명령어로도 컨테이너의 숫자를 늘리거나 줄일 수도 있다.

 

$ docker-compose scale [서비스]=[컨테이너숫자]
$ docker-compose sacle web=3

 

docker-compose 관련 명령어에 대해서 추가적으로 알아볼 게 2가지 있다. 우선은 위에서 yaml 파일로 명시한 것은 총 2개 종류의 서비스를 생성하라고 되어 있지만, docker-compose 명령어로 특정 서비스만 생성할 수 있도록 할 수 도 있다.

 

$ docker-compose up -d [서비스]
$ docker-compose up -d mysql

 

두 번째로는 docker-compose 명령어도 단순한 docker 명령어처럼 run 을 붙여 특정 서비스의 컨테이너를 생성할 수 도 있다. 특징은 인터렉티브 셸로 들어가기 위해 단순 docker 명령어와는 달리 -it 옵션을 붙어주지 않아도 된다.

 

$ docker-compose run [SERVICE] [COMMAND]
$ docker-compose run web /bin/bash

 

이제 도커 컴포즈로 생성된 프로젝트를 삭제해보자. 아래 명령어를 입력하면 된다. 단, 프로젝트를 삭제한다면 해당 프로젝트의 서비스 내의 모든 컨테이너들이 모두 정지된 후 삭제됨을 알아두자.

 

$ docker-compose down
$ docker-compose down -p [PROJECT]

 

기본적으로 docker-compose down 명령어는 명령어를 실행할 때의 현재 디렉토리를 프로젝트로 간주하고 프로젝트를 삭제한다. 하지만 -p(--project-name) 옵션을 넣어주어 생성하거나 삭제할 특정 프로젝트를 명시해줄 수 있다. 이렇게 -p 옵션을 잘 활용하면 서로 다른 docker-compose.yaml 파일을 갖는 서로 다른 프로젝트들 중 내가 생성하고 삭제하고 싶은 특정 프로젝트를 제어할 수 있다. 또한 Dockerfile 때와 마찬가지로 -f(--file) 옵션을 사용하여 docker-compose.yaml 파일이 존재하는 경로를 명시해줄 수도 있다.

3. 도커 컴포즈를 제대로 활용해보기

이제 도커 컴포즈의 기본적인 사용법을 익혀보았다. 이번 목차에서 부터는 실제 환경 또는 실무에서 자주 사용될 법한 도커 컴포즈 다루는 방법에 대해 배워보도록 하자. 크게 2가지 측면에서 배워볼 예정인데, 우선 첫 번째는 YAML 파일에 좀 더 다양한 옵션 값을 설정하는 법, 두 번째는 도커 컴포즈 자체를 잘 다루는 방법이다. 

3-1. YAML 파일을 좀 더 알차게 작성하기

YAML 파일에서 명시하는 여러가지 옵션들은 단지 docker run 명령어로 컨테이너에 설정하는 명령어들을 YAML 파일에 옮겨 적는 것이라고 생각하면 된다. YAML 파일은 크게 YAML 파일의 포맷 버전 정의, 서비스 정의, 볼륨 정의, 네트워크 정의 총 4가지 항목으로 구성된다. 그 중 가장 자주 작성하는 부분은 서비스 정의 부분이다.

3-1-1. 버전 정의

여기서의 버전이라 함은 YAML 파일의 포맷 버전이다. YAML 파일의 포맷은 도커 컴포즈 버전과 호환이 되는 것이 있고 아닌 것이 있다. 따라서 사용하는 도커 컴포즈 버전과 호환이 되는 YAML 파일의 포맷 버전을 적절히 설정해주어야 할 필요가 있다.

 

# docker-compose.yaml
version: '3.0'

3-1-2. 서비스 정의

도커 컴포즈가 생성할 서비스 내의 컨테이너들에 대한 옵션을 정의해야 한다. 옵션을 서비스 단위로 구분하여 설정해주어야 한다. 왜냐하면 하나의 서비스 내에 있는 모든 컨테이너들은 동일한 이미지 즉, 동일한 역할과 설정 값을 갖고 있어야만 하기 때문이다. 항목 하나씩 살펴보자.

 

먼저 image이다. image 항목은 서비스 내의 컨테이너들을 생성할 때 기반이 되는 이미지이다. 이미지 이름 포맷은 docker가 접두어로 붙는 명령어를 활용할 때와 동일하게 명시하면 된다. 예시는 아래와 같다.

 

# docker-compose.yaml
version: '3.0'
services:
  web:
    image: httpd:latest
  mysql:
    image: mysql:latest

 

다음은 links 항목이다. 이전에 컨테이너 다루기 포스팅에서 배운 --link 옵션과 같다. 그 때 당시 --link 옵션을 사용해서 이미 실행 중인 다른 컨테이너를 특정한 별칭(alias)로 접근이 가능하게 해준다고 배웠다. 형식은 [SERVICE]:[alias] 로 정의한다.

 

# docker-compose.yaml
version: '3.0'
services:
  web:
    image: httpd:latest
    links:
      mysql:db  # mysql 서비스를 `db`라는 별칭으로 접근 가능
  mysql:
    image: mysql:latest

 

참고로 links 옵션은 위와 같이 이미 실행 중인 컨테이너에 대한 별칭을 명시하기 때문에 암묵적으로 컨테이너들 간의 실행 순서 즉, 의존성 관계를 정의해주기도 한다.

 

다음은 environment 항목이다. docker 접두어 명령어에서 -e 옵션을 준 것과 같다. YAML 파일에서는 배열 형태 또는 딕셔너리 형태로 명시가 가능하다.(만약 YAML 파일에서의 배열이 무엇인지 잘 모르면 여기를 참고하자. 설명이 잘 되어 있다)

 

# docker-compose.yaml
version: '3.0'
services:
  web:
    image: httpd:lates
    links:
      mysql:db
  mysql:
    image: mysql:latest
    environment:
      - MYSQL_ROOT_PASSWORD=1234
      - MYSQL_DATABASE_NAME=zedd_db
   (또는)
    environment:
      MYSQL_ROOT_PASSWORD : 1234
      MYSQL_DATABASE_NAME : zedd_db

 

다음은 command 항목이다. 이는 컨테이너가 실행될 때 수행하는 명령어 설정값이다. docker run 명령어의 마지막 인자에 명시하는 것처럼, 또는 Dockerfile 에서의 RUN 명령어처럼 배열 형태로 명시해주는 것도 가능하다.

 

# docker-compose.yaml
version: '3.0'
services:
  web:
    image: httpd:lates
    links:
      mysql:db
    command: /bin/bash
    (또는)
    command: [/bin/bash]
  mysql:
    image: mysql:latest
    environment:
      - MYSQL_ROOT_PASSWROD=1234
      - MYSQL_DATABASE_NAME=zedd_db

 

다음은 depends_on 항목이다. 이는 특정 컨테이너의 의존 관계를 나타낸다. 방금 위에서 살펴보았던 links 항목이 하는 역할 중 하나와 비슷하다. 즉, 컨테이너들 간의 실행 순서를 의미하기도 한다. depends_on: 뒤에 서비스 이름을 명시하면 되는데, 이는 depends_on 뒤에 나오는 서비스 내의 컨테이너들이 먼저 실행되어야 함을 의미한다. 하지만 links 항목도 마찬가지지만 depends_on도 컨테이너들 간의 실행 순서는 명시하지만 먼저 실행되어야 할 컨테이너가 정상적으로 동작하고 있는 상태인지를 보장하지는 못한다.

 

이를 예방하는 방법이 한 가지 있다. 예를 들어, A와 B라는 서비스가 있다고 가정하자. 그리고 B 서비스 항목에 아래처럼 A에 의존한다고 해보자.

 

version: '3.0'
services:
  A:
    image: mysql:latest
  B:
    image: httpd:latest
    depends_on:
      A

 

YAML 파일 정보가 위와 같다고 할 때, 방금 말한 문제를 예방하기 위해서 B 서비스 항목에 특정 셸 스크립트를 실행해주는 명령어를 entrypoint 항목에 넣어주자. 여기서 entrypoint 항목은 Dockerfile에서 배운 ENTRYPOINT와 동일한 역할을 한다. 해당 항목이 추가된 YAML 파일 예시는 아래와 같다.

 

version: '3.0'
services:
  A:
    image: mysql:latest
  B:
    image: httpd:latest
    depends_on:
      A
    entrypoint: ./sync.sh

 

위에서 명시한 sync.sh 셸 스크립트의 내용은 대충 다음과 같다. 서비스 A 컨테이너에 특정 명령어(ex. curl 과 같은)를 날려서 우리가 원하는 정상 동작 결과 값이 반환되면 그 때 부터 A 서비스와 연결하는 작업을 수행하는 것이다. sync.sh 셸 스크립트 내용은 직접 작성해주어여 하며 셸 스크립트 문법을 이용해 작성하면 된다. 이와 비슷한 방법으로 dockerize, wait-for-it.sh 셸 스크립트 도구를 이용하는 방법도 있다고 한다. 

 

참고로 위와 같이 depends_on 항목이 작성되어 있는 서비스 내에서 의존성이 없는 컨테이너로 생성하려면 --no-deps 옵션을 넣어주면 된다.

 

$ docker-compose up --no-deps [SERVICE]
$ docker-compose up --no-deps B

 

다음은 ports 항목이다. docker 접두어 명령어에서의 -p 옵션과 같은 기능 즉, 개방할 컨테이너 포트를 명시해준다. 포트를 명시해주는 방법으로는 아래와 같이 크게 3가지 종류가 있다.

 

# docker-compose.yaml
version: '3.0'
services:
  web:
    image: httpd:latest
    ports:
      - "8080"       # 컨테이너의 8080번 포트를 개방
      - "8081-8085"  # 컨테이너의 8081~8085번 포트를 개방
      - "80:80"      # 호스트의 80번 포트와 컨테이너의 80번 포트를 서로 개방해 포트 포워딩

 

위 YAML 파일 형식에서 "80:80" 처럼 호스트의 특정 포트와 컨테이너의 특정 포트를 연결하는 형식이 있다. 만약 위 YAML 파일 형식을 읽어들여서 도커 컴포즈를 수행할 환경이 단일 호스트(1개의 머신) 환경이라면 이후에 컨테이너 수를 늘리는(scale) 기능을 수행하지는 못한다. 이유는 간단하다. 하나의 호스트에서 하나의 포트번호(ex. 80번 포트)는 하나의 컨테이너만 점유만 할 수 있기 때문이다.

 

다음은 build 항목이다. build 항목에 사전에 정의한 Dockerfile을 명시하여 Dockerfile에 적혀있는 내용을 기준으로 컨테이너를 생성할 수 있도록 할 수 있다. 추가적으로 Dockerfile에서 읽어들일 빌드 컨텍스트 경로, Dockerfile 파일 이름, Dockerfile에 인자 값을 추가했다면 넘겨줄 인자 값을 설정할 수 있다. 예시는 아래와 같다.

 

# docker-compose.yaml
version: '3.0'
services:
  web:
    build: ./dockerfile_path     # Dockerfile 파일이 존재하는 경로
    context: ./dockerfile_path   # 빌드 컨텍스트 경로
    dockerfile: zeddDockerfile   # Dockerfile 파일 이름
    args:
      HOST_NAME: web_zedd
      HOST_CONFIG: web_config

 

build 항목에서 추가로 알아둘어야 할 점이 있다. 위처럼 build 항목을 생성하여 도커 컴포즈를 수행해 프로젝트를 생성한 다음, 이후에 사용한 Dockerfile 내용을 이후에 수정한 뒤 다시 프로젝트를 생성한다고 해도 이미지를 새롭게 빌드하지 않게 된다. 만약 Dockerfile에 수정을 가하고 난 다음 이미지를 새롭게 빌드하도록 하려 한다면 아래와 같은 2가지 종류의 명령어를 사용해서 프로젝트를 생성하면 된다.

 

$ docker-compose up -d --build  # --build 옵션 사용
$ docker-compose build [YAML 파일에서 빌드할 서비스 이름]

 

다음은 extends 항목이다. extends 항목은 같은 YAML 파일 또는 서로 다른 YAML 파일에서 서비스의 속성을 상속받게 할 수 있는 설정이다. 아래 그림 예시를 보자.

 

extends 항목 예시

 

위 그림을 서로 다른 YAML 파일에서 서비스의 속성을 상속받는 예시다. docker-compose.yaml 에 정의된 extends 항목을 보면 상속 받을 서비스 설정이 들어있는 YAML 파일 이름과 상속 받을 서비스의 이름을 적어주면 된다. 만약 하나의 YAML 파일 안에서 extends 항목을 사용해 상속을 받으려면 아래 예시처럼 된다.

 

# docker-compose.yaml
version: '3.0'
  services:
    web:
      extends:
        service: extend-web
    extend-web:
      image: ubuntu:14.04
      ports:
        - "80:80"

 

extends 항목을 사용하면 사전에 복잡한 설정값들로 만들어진 서비스의 속성을 한번에 상속받아 YAML 파일의 내용을 간결화시킬 수도 있다. 하지만 extends 항목이 모든 설정값을 상속받을 수 있는 것은 아니고, 대표적으로 컨테이너 사이의 의존성을 내포하고 있는 depends_on, links, volumes_from 과 같은 설정이 들어있는 서비스는 상속받지 못한다는 것을 알아두자.

3-1-3. 네트워크 정의

이번 목차에서는 YAML 파일에서 정의할 수 있는 도커 네트워크 항목에 대해 알아보자. 도커 네트워크에 대한 개념은 이전 포스팅에서 자세히 다루었으므로, 네트워크에 대한 개념은 생략하겠다. 

 

먼저 driver 항목이다. 도커 컴포즈는 프로젝트 생성 시, 생성될 컨테이너에 적용될 네트워크 드라이버로서 기본적으로 브리지 타입의 네트워크를 새롭게 생성한다. 하지만 사용자는 YAML 파일에 driver 항목을 명시함으로써 다른 네트워크 드라이버를 사용할 수 있도록 할 수 있다. 다른 네트워크 드라이버를 사용할 때 설정할 하위 항목으로는 driver_ops 항목으로 명시해주면 된다.

 

# docker-compose.yaml
version: '3.0'
services:
  myService:
    image: nginx
    networks:
      - mynetwork  # 사용할 다른 네트워크 이름
networks:
  mynetwork:
    driver: overlay
    driver_opts:
      subnet: "255.255.255.0"
      IPAdress: "10.0.0.2"

 

위 예시에서는 도커 스웜에서 작동할 수 있는 오버레이 네트워크를 생성해 적용한 예시다.

 

다음은 ipam 항목이다. ipam 이란 IP Address Manager의 줄임말로 쉽게 말하면 IP 주소를 자동으로 부여하고 쉽게 찾을 수 있도록 해주는 것이다. 이 ipam을 지원하는 네트워크 드라이버가 있는 경우, ipam 항목을 사용해서 명시할 수도 있다.

 

# docker-compose.yaml
version: '3.0'
services:
  web:
    image: nginx
    networks:
      - mynetwork
networks:
  mynetwork:
    driver: overlay
    driver_opts:
      subnet: "255.255.255.0"
      IPAdress: "10.0.0.2"
  ipam:
    driver: mydriver  # iapm을 지원하는 네트워크 드라이버임을 전제
    config:
      subnet: 172.20.0.0/16
      ip_range: 172.20.5.0/24
      gateway: 172.20.5.1

 

다음은 external 항목이다. 방금까지는 모드 프로젝트를 생성할 때마다 새로운 네트워크를 생성하는 것이였다. 하지만 기존에 이미 생성된 네트워크를 사용하는 경우도 있을 것이다. 이 때 external 항목을 사용한다. networks 항목에 사용할 기존 네트워크의 이름을 명시하고 그 하위 항목에 external 에 true 값을 주면 된다.

 

# docker-compose.yaml
version: '3.0'
services:
  web:
    image: nginx
    networks:
      - existing_network
networks:
  existing_network
    external: true

3-1-4. 볼륨 정의

다음은 컨테이너의 볼륨과 관련하여 설정하는 항목들에 대해 알아보자. 먼저 driver 항목이다. 네트워크도 그랬지만 볼륨에서도 드라이버가 존재한다. 어떠한 설정도 하지 않으면 local 이라는 드라이버를 기본적으로 사용하지만 이를 입맛에 맞게 바꿀 수도 있다. 볼륨도 마찬가지로 driver_opts 항목으로 별도로 사용할 드라이버의 하위 옵션을 설정해줄 수 있다.

 

# docker-compose.yaml
version: '3.0'
services:
  ...(생략)...
volumes:
  driver: flocker
    driver_opts:
      opt: "1"
      opt2: 2

 

다음은 external 항목이다. 볼륨도 마찬가지로 도커 컴포즈는 YAML 파일에 명시된 volume, volumes-from 항목을 보고 프로젝트를 생성할 때마다 새로운 볼륨을 생성한다. 하지만 볼륨도 네트워크 처럼 기존에 생성된 볼륨을 갖다 사용할 수도 있다. 이를 가능하게 해주는 것이 바로 external 항목이다. 예시는 아래와 같다.

 

version: '3.0'
servcies:
  web:
    image: nginx
    volumes:
      - myVolume: /container/path  # `myVolume`이라는 기존의 볼륨을 컨테이너 내부의 `/container/path` 경로에 마운트
volumes:
  myVolume:
    external: true

 

볼륨과 관련된 항목은 아니지만 마지막으로 알아볼 항목이 있다. 바로 작성한 YAML 파일의 오타나 파일 포맷이 제대로 되어 있는지 검사하는 기능이다. 이를 사용하기 위해서는 docker-compose config 명령어를 사용한다. 해당 명령어를 사용하면 기본적으로 해당 명령어를 입력한 현재 디렉토리 또는 상위 디렉토리의 docker-compose.yaml 파일을 알아서 찾아 검사를 한다. 물론 이도 마찬가지로 -f 옵션을 주어 docker-compose.yaml 파일이 있는 경로를 직접 명시해줄 수도 있다.

 

$ docker-compose config
$ docker-compose -f [YAML PATH] config

3-2. 도커 컴포즈 더 잘 사용해보기

이번엔 도커 컴포즈를 좀 더 잘 사용해볼 수 있는 내용들에 대해 배워보자. 말은 거창할 수 있지만.. 배울 내용은 2가지다. 도커 컴포즈 네트워트에 대한 내용과 도커 컴포즈와 도커 스웜 함께 사용하기이다.

3-2-1. 도커 컴포즈 네트워크

[3-1-3. 네트워크 정의] 항목에서 잠깐 도커 컴포즈가 기본적으로 어떤 네트워크를 사용하는지 알아보았다. 기본적으로 도커 컴포즈는 프로젝트를 생성할 때마다 브리지 타입의 새로운 네트워크를 생성해 적용한다. 그리고 생성된 네트워크의 이름은 [프로젝트 이름]_default 로 설정이 된다. 그리고 프로젝트를 삭제 즉, docker-compose down 명령어를 사용하면 프로젝트 내의 컨테이너를 삭제하는 것 뿐만 아니라 생성한 네트워크도 삭제시킨다. docker-compose down 명령어를 입력시키고 나오는 표준 출력에 "Removing network ... " 라는 문구가 보일 것이다.

 

프로젝트 생성 시 새롭게 생성된 브리지 타입의 네트워크는 docker-compose scale 명령어로 늘려준 컨테이너들에 의해서도 사용이 된다. 이것이 가능한 이유는 새롭게 컨테이너가 생성될 때 내부적으로 --net-alias 옵션을 사용하여 서비스 이름을 일종의 도메인 이름으로 설정하기 때문이다. --net-alias 옵션에 대해서는 컨테이너 다루기 포스팅에서 배웠으므로 자세한 설명은 생략하겠다. 기억이 나지 않는다면 다시 보고 오자. 

 

그래서 도커 컴포즈에서도 특정 서비스의 이름으로 해당 서비스 내의 모든 컨테이너들에 대해 접근이 가능하다. 이에 대한 관계를 도식화해보면 아래와 같다.

 

도커 컴포즈가 동작하는 방식

 

위처럼 mysql 이라는 도메인 이름으로 접근을 요청하면 mysql 서비스 내의 컨테이너 중 하나에 접근하도록 한다. 이 때 어떤 컨테이너를 선택할지의 방식은 기본적으로 라운드 로빈 방식을 택한다. 이처럼 도메인 이름으로 특정 서비스 내의 모든 컨테이너에 접근하는 것은 스웜 모드에서도 가능하다. 물론 구체적인 방식은 다르다. 스웜 모드에서는 기본적으로 오버레이 네트워크가 위와 같은 원리를 가능케 한다.

3-2-2. 도커 컴포즈 + 도커 스웜 사용하기

이번엔 도커 컴포즈를 도커 스웜 모드에서 사용하는 방법에 대해 알아보자. 우선 스웜모드를 활성화시켜야 하는데, 이에 대한 자세한 방법은 도커 스웜 포스팅을 참조하도록 하자.

 

도커 컴포즈 1.10 버전부터는 스웜 모드와 함께 사용할 수 있는 YAML 버전 3이 배포됨에 따라 스웜 모드와 도커 컴포즈를 함께 사용할 때 활용하는 개념인 스택(stack)이 도커 엔진 1.13 버전부터 추가가 되었다. 여기서 스택이란, YAML 파일에서 생성된 컨테이너들의 묶음을 의미하며 YAML 파일을 활용해 스택을 생성하게 되면 YAML 파일에 정의된 서비스가 스웜 모드의 클러스터 서버 내에 일괄적으로 생성이 된다. 다시 말해, YAML 파일에 정의된 서비스들이 스웜 모드에서의 서비스 개념으로 변환 되는 셈이다.

 

하지만 스택은 docker-compose가 아닌 docker stack 이라는 명령어로 제어를 해야 한다. 엄밀히 말하면 스택은 도커 컴포즈가 아닌 스웜 모드 클러스터 내의 매니저 노드에 의해 생성된 것이기 때문이다. 그래서 스택을 생성하고 삭제하는 것도 매니저 노드에서만 가능하다.

 

실습을 해보기 위해서, 도커 스웜 포스팅에서처럼 매니저 노드 1개를 위한 VM 1개, 워커 노드 2개를 위한 VM 2개를 준비해보도록 하자. 필자는 아래와 같이 준비하였다.

 

 

이제 도커 컴포즈를 스웜과 함께 사용하도록 하기 위한 YAML 파일을 아래와 같이 작성해보자.

 

version: '3.0'
services:
  web:
    command: apachectl -DFOREGROUND
    image: alicek106/composetest:web
    links:
      - mysql:db
    ports:
      - 80:80
  mysql:
    command: mysqld
    image: alicek106/composetest:mysql
networks: {}
volumes: {}

 

그리고 아래와 같은 명령어 형식을 사용하여 YAML파일을 스택으로 변환시키자.

 

$ docker stack deploy --config-file [YAML PATH] [생성할 STACK 이름]
$ docker stack deploy --config-file ./docker-compose.yaml zedd_stack

 

위 명령어를 입력하면 표준  출력의 가장 첫번째 줄에 "Ignoring unsupported options: links" 라고 발생하는데, 이는 컨테이너 간의 의존성 관계를 정의하는 links, depneds_on과 같은 항목을 스웜에서는 사용할 수 없음을 의미한다. 왜냐하면 해당 항목들을 사용하려면 서로 다른 역할을 하는 컨테이너들(위 예시에서는 web, mysql 각 서비스 내의 컨테이너)이 같은 호스트에 존재하는 환경에 있어야 하기 때문이다. 추가적으로, 스택을 제어하는 관련 명령어 종류로는 아래와 같다.

 

명령어	의미
docker stack ls	생성한 스택 정보 출력
docker stack ps [STACK]	특정 스택으로 생성한 서비스 내에 존재하는 컨테이너 정보 출력
docker stack services [STACK]	스택으로 생성된 서비스 정보 출력
docker stack rm [STACK]	특정 스택으로 생성된 서비스를 삭제

 

이렇게 스웜 모드에서 사용할 수 있는 도커 컴포즈를 활용해 서비스를 생성해보았다. 만약 특정 서비스 내의 컨테이너를 늘리거나 줄일 경우, 도커 컴포즈 관련 명령어가 아닌 스웜 관련 명령어인 docker service scale 관련 명령어를 사용해야 한다. 왜냐하면 스택은 도커 컴포즈가 아니라 스웜 킷이라는 것에 의해 생성되었기 때문이다.

 

다음은 스택 네트워크에 대해 잠시 알아보자. 위에서 스택을 활용해 서비스를 생성할 때 표준 출력을 보면 스택을 위한 네트워크를 생성한 것을 알 수가 있다.

 

 

이처럼 스택을 위한 네트워크가 존재하는데, 스택의 네트워크는 기본적으로 오버레이 네트워크 속성을 가지게 된다. 개인적인 생각으로는 스택이 도커 스웜에서 동작하기 때문에 스웜이 오버레이 네트워크를 사용하기 때문이지 않을까도 추측한다. 그리고 스택 네트워크는 실제로 스웜 클러스터에만 사용할 수 있는 네트워크 즉, SCOPE 항목이 swarm 이라는 키워드로 되어 있다.

 

 

하지만 스택 네트워크가 스웜 모드 내에서 사용하는, 구체적으로는 사용자가 정의해 사용하는 오버레이 네트워크랑은 약간 차이가 있다. 이전 포스팅에서 배웠듯이, 사용자가 정의해 사용하는 오버레이 네트워크는 생성 시 --attachable 옵션을 사용한다면 스웜 명령어가 아닌 일반적인 docker run 관련 명령어로 컨테이너를 생성할 때 해당 컨테이너가 오버레이 네트워크를 사용할 수 있도록 하는 게 가능하다. 그러나 스택 네트워크는 애초에 --attachable 옵션이 설정되어서 생성되지 않기 때문에 docker run 관련 명령어로 생성되는 컨테이너에게 스택 네트워크를 적용시킬 수가 없다.

---

이렇게 해서 책의 도커와 관련된 목차 내용은 모두 끝이 났다. 이전에 도커를 얕게나마 배웠지만 이번 기회를 통해 나름대로의 도커의 탄탄한 기초를 쌓을 수 있었다. 이제 다음 챕터부터는 대망의 쿠버네티스이다. 쿠버네티스는 우리가 이전에 배운 도커 스웜의 역할과 비슷하다고 볼 수 있다. 현재 실제 환경에서 가장 자주 사용되는 툴로서의 쿠버네티스에 대해서도 기초부터 탄탄히 배워보도록 하자!