• Docker와 Docker Stack을 사용한 서비스 구축

Docker는 사용자가 설정한 환경에 맞춰 컨테이너를 생성해주고 관리해주는 툴입니다. 물론 리눅스에서 Docker를 사용하지 않고 직접 LXC 커맨드를 사용하여 컨테이너를 생성하고 관리할 수 있지만 매우 불편합니다. 사실 Docker 외 컨테이너를 관리해주는 여러 가지가 있지만 이번 글에서는 Docker만 사용해서 테스트를 진행하고자 합니다.

Docker의 설치 방법은 여러 가지가 있지만, Ubuntu 20.04(Focal Fossa)부터는 별도의 설정 없이 apt를 사용하여 Docker의 설치가 가능합니다.

설치 후 간단한 테스트를 위해 자신의 이름을 반환해주는 웹 서버 컨테이너를 생성하겠습니다. 컨테이너 생성 명령어는 docker run <option> [image_name] 입니다.

-p 옵션은 publish의 약자로 host(container가 실행되는 서버)와 컨테이너의 port를 연결해주는 옵션입니다. 저는 host의 8018 port를 container의 80에 연결했기 때문에 외부에서 8018 포트를 사용해 웹 서버에 접근이 가능합니다.

붉은 박스의 4379b6feab65는 컨테이너의 이름(ID)으로 docker ps 명령어를 통해 확인하실 수 있습니다.

Docker를 사용하여 손쉽게 서비스를 관리하던 중 서비스 확장으로 인해 보다 복잡한 컨테이너 구성이 요구되었습니다. docker run 명령을 통해 컨테이너를 추가로 생성할 수 있지만 컨테이너 네트워크 설정 등 여러 가지 복잡한 부분이 있습니다. 이럴 경우 docker-compose를 사용하면 간단하게 해결이 가능합니다. docker-compose를 사용해서 자신의 이름을 반환해주는 웹 서버 2개를 생성해 보겠습니다.

위 그림은 compose를 사용하기 위한 설정 파일입니다. compose에서는 컨테이너에서 실행되고 있는 애플리케이션을 서비스라는 개념으로 관리합니다. 2개의 웹 서버를 실행하기 위해 docker-compose.yaml 이라는 파일을 생성해서 위와 같이 입력합니다. server1과 server2 서비스를 정의했고 8019와 8020 port를 할당했습니다.

compose 실행 명령어는 docker-compose up -d입니다. -d 옵션을 통해 데몬 형태의 background process로 실행이 가능합니다. compose는 설정 파일 기반으로 동작하기 때문에 위에서 생성한 yaml 파일이 있는 디렉터리에서 실행해야 합니다. docker-compose -f 옵션으로 설정 파일을 지정할 수 있고, -f 옵션이 없다면 기본적으로 docker-compose.yaml 파일이 자동으로 지정됩니다. 위 그림에서는 따로 지정하지 않았기 때문에 같은 디렉터리에 있는 docker-compose.yaml을 기반으로 서비스를 생성했습니다.

docker-compose ps 명령어를 통해 생성된 서비스의 상태를 확인할 수 있습니다.

역시 docker ps를 통해서도 생성된 컨테이너를 확인할 수 있습니다. 즉, compose는 docker 툴이 가진 단일 컨테이너만 관리 가능한 불편함을 개선하여 다중 컨테이너를 한 번에 실행하고 관리할 수 있도록 만들어진 툴임을 알 수 있습니다.

각 서비스에 설정한 port로 접속해보면 두 컨테이너로 접속이 되는 것을 확인할 수 있습니다. 여러 서비스를 compose를 통해 관리하며 서비스를 하던 중 접속자가 많아져서 서비스 확장이 필요하게 되었습니다. 항상 접속자가 많다면 컨테이너의 사양을 높게 설정하면 되지만 특정 시간대에만 접속자가 집중되고 있습니다. 결국, 접속자가 많은 시간에만 컨테이너 수를 늘려서 해결을 하기로 했습니다. compose를 사용하면 여러 컨테이너를 동시에 실행하고 관리할 수 있지만 개별 서비스마다 port를 할당하여 관리해야 하는 큰 불편함이 있기 때문에 docker stack을 사용하여 서비스를 배포하겠습니다. stack을 사용하기 위해서는 docker swarm 모드를 설정해야 합니다.

docker swarm init 명령어를 통해 swarm 모드를 활성화합니다. init 명령어를 수행한 노드는 관리 노드로 할당됩니다. 만약, 다른 노드를 swarm 클러스터에 추가하고 싶다면 위 명령어 결과로 출력된 join 명령어를 해당 노드에서 입력하면 됩니다. 이 글에서는 단일 노드로 테스트를 진행합니다.

docker node ls 명령어로 클러스터에 참여한 노드들의 상태를 확인할 수 있습니다. Manager status를 보면 Leader로 표시되어 있습니다. Leader는 swarm 클러스터 내 모든 명령을 지시하고 클러스터 내 컨테이너들을 관리합니다.

하나의 포트로 다중 컨테이너를 연결하기 위해 네트워크 드라이버를 overlay로 변경했습니다. 드라이버를 overlay로 설정 시 docker의 내부 가상 네트워크를 통해 자동으로 트래픽 분배가 수행됩니다.

stack은 설정에 따라 my_servers라는 네트워크를 생성하고 server1 서비스를 생성합니다. 명령어의 맨 마지막 부분은 stack 이름으로 여러 서비스를 stack에서 식별하기 위한 접두어에 해당합니다. 즉, 하나의 설정 파일로 여러 stack을 배포할 수 있습니다. 동일한 서비스를 손쉽게 복사할 수 있기 때문에 전체 서비스에 대한 대규모 패치 시 매우 유용합니다. 실제로 저희 팀도 stack을 사용하여 (1) 서비스 복제 -> (2) 네트워크를 신규 서비스로 할당 -> (3) 서비스 테스트 -> (4) 기존 서비스 삭제의 절차로 무중단 서비스 업데이트를 진행하고 있습니다.

설정 파일에서 replicas를 4대로 지정했기 때문에 동일 기능을 수행하는 컨테이너 4대가 생성되었습니다. overlay 네트워크를 통해 8019 포트로 접속 시 4대로 트래픽이 분배됩니다. 자신이 서비스하는 컨테이너가 멈추거나 중단될 경우 트래픽 분배 대상에서 제외되며 복구 시 다시 트래픽 분배를 수행합니다.

지금까지 테스트에서 알 수 있듯이 Docker는 서비스 배포, 운영, 패치 과정에서 다양한 편리함을 제공합니다. 또한, 서버 자원을 공유함으로써 비용 절감 및 인프라 간소화의 편의성도 제공합니다. 실제로 모니터랩도 DMZ에 많은 물리적 서버를 운영하다가 Docker 도입 후 5대로 축소되어 비용이나 관리적으로 많은 이득을 얻었습니다. 만약, 이 글을 읽으시는 분이 IT 인프라 담당이시라면 한 번쯤 도입해 보시기를 추천합니다.

2부에서는 Kubernetes를 사용해서 동일하게 서비스 구성을 진행해보겠습니다.