Docker

서론

Konect 프로젝트의 스테이지 분리 작업을 진행했다. 이 과정에서 도커 컴포즈를 통해 WAS와 DB를 같이 관리하자는 의견이 나왔고 해당 작업을 같이 진행했다. 이 과정에서 학습한 내용을 정리했다.

본론

도커

도커는 운영체제 수준 가상화를 사용하여 컨테이너라고 불리는 패키지로 소프트웨어를 전달하는 일련의 서비스형 제품군이다 - 위키백과 -

자바 기반 스프링 부트로 구현된 WAS가 있다고 가정하자. WAS를 실행하기 위해서는 동일한 버전의 자바가 로컬에 설치를 해야하고, 데이터베이스 연결이 필요하면 데이터베이스도 설치를 해야한다. 이런 번거로움을 덜어내고, 구현환경과 동일한 실행환경을 제공하기 위해 실행에 필요한 모든 환경을 하나로 묶어서 실행할 수 있게 해주는 도구가 도커이다.

왜 그럼 구현환경과 동일한 실행환경을 제공하는 것이 중요할까? A 개발자와 B 개발자가 있다고 가정을 하자. A 개발자 로컬 환경에서 정상적으로 실행이되고 개발 환경에 배포가 됐다. 근데, B 개발자 환경에서 실행이 안되거나 운영 환경으로 배포가 나갔는데 정상적으로 실행이 안되는 상황이 발생할 수 있다. 즉, “내 컴퓨터에서는 되는데요”를 막기 위해 구현환경과 동일한 실행환경을 제공해야 한다.

이외에도 도커를 사용했을 때의 이점은 다음과 같다.

• 각 컨테이너는 독립된 환경에서 실행되기 때문에, 하나의 서버에서 여러 애플리케이션을 서로 영향 없이 운영할 수 있다.
• 트래픽이 몰릴 때 컨테이너를 빠르게 여러 개 복제해서 띄울 수 있다.
• VM에 비해 훨씬 가볍고 실행 속도가 빠르다.
• Docker Hub와 같은 레지스트리에 도커 이미지를 올려두면, 어떤 서버에서든 해당 이미지를 통해 동일한 환경을 제공받을 수 있다. VM와 비교하는 내용은 다음 포스팅에서 더 자세히 다루겠다.

단점도 존재한다.

• 컨테이너, 이미지, 볼륨, 네트워크 등 러닝 커브가 존재한다.
• 호스트 OS의 커널을 공유하기 때문에, VM에 비해 격리 수준이 낮아 취약점이 발생할 경우 호스트 시스템 전체가 위험해질 수 있다.
• 컨테이너는 Stateless하게 설계되어 있어, 볼륨을 설정하지 않을 경우 컨테이너가 재시작 시 데이터가 날아간다.
• 컨테이너 수가 많아지면 관리가 복잡해진다. 도커와 관련된 개념은 해당 포스팅에서 다루고, VM과 관련된 내용은 다음 포스팅에서 더 자세히 다루겠다.

도커 주요 개념

도커 주요 개념에 대한 자세한 내용과 명령어 등은 별도의 포스팅에서 다루고, 여기서는 간단하게 정의만 짚고 넘어간다.

도커 엔진

도커의 런타임을 제공해주는 요소이며, 컨테이너를 생성, 실행 그리고 관리한다. 도커 엔진의 구성 요소는 다음과 같다.

• Docker CLI : 터미널에서 명령어를 입력하는 인터페이스이다. 명령을 받아 Daemon에 전달한다.
• Docker API : Daemon과 CLI 사이, 혹은 외부 도구와 Daemon 사이의 통신을 담당하는 REST API이다.
• Docker Daemon(dockerd) : 백그라운드에서 실행되는 프로세스로, 모든 도커 작업의 중심이다.

도커 파일

도커 파일은 도커 이미지를 만들기 위한 용도로 작성하는 파일이다. 도커 이미지의 설계도라고 보면 되겠다. 이미지를 어떻게 구성할지 명령어를 순서대로 작성한 텍스트 파일이며, docker build 명령어로 Dockerfile을 읽어 이미지를 생성한다. 이때 도커 파일의 이름은 Dockerfile으로 지정해야한다. WAS를 도커라이제이션하면서 작성한 도커 파일이다.

# amazoncorretto 17 버전을 베이스 이미지로 사용
FROM amazoncorretto:17-alpine  

# 작업 디렉토리 설정
WORKDIR /app  

# 보안을 위해 전용 유저/그룹 생성 (root 권한으로 실행하지 않기 위함)
RUN addgroup -S konect && adduser -S konect -G konect  

COPY build/libs/KONECT_API.jar KONECT_API.jar  

# jar 파일의 소유권을 konect 유저로 변경
RUN chown -R konect:konect KONECT_API.jar  

# 이후 명령어는 konect 유저로 실행
USER konect:konect  

EXPOSE 8080  

# 컨테이너 상태를 주기적으로 체크
HEALTHCHECK --interval=30s --timeout=3s --start-period=40s --retries=3 \  
  CMD wget --no-verbose --tries=1 --spider http://localhost:8080/actuator/health || exit 1  

ENTRYPOINT ["java", "-jar", "KONECT_API.jar"]

도커 이미지

도커 이미지는 도커 컨테이너를 생성하기 위한 템플릿이다. 위에서 언급한 도커 파일을 기반으로 생성되며, 애플리케이션 실행에 필요한 코드, 런타임, 라이브러리, 환경 설정들이 모두 포함되어 있다. 도커 이미지에서 알아야할 키워드는 레이어 구조이다. 도커 파일에 정의한 명령어가 실행될 때마다 새로운 레이어가 쌓인다. 해당 구조 덕분에 변경이 발생한 레이어부터 다시 빌드하기 때문에 빌드 속도가 빠르다. 가령, 소스 코드만 변경이 될 경우 COPY 레이어부터 다시 빌드를한다. 그렇기 때문에 도커 파일에서 명령어를 작성하는 순서가 중요하다.

도커 레지스트리

도커 이미지를 저장하고 공유하는 저장소이다. 공개 레지스트리인 Docker Hub가 대표적이다. 비공개 레지스트리로는 AWS ECR, Github Container Register 등이 있다. docker pull ~처럼 별도 주소 없이 이미지를 받을 수 있는 이유는 기본적으로 Docker Hub를 바라보고 있기 때문이다.

도커 컨테이너

도커 이미지를 실행한 인스턴스이다. 하나의 이미지로 여러 개의 컨테이너를 실행할 수 있다. 붕어빵틀과 붕어빵이라고 이해하면 될 거 같다. 각 컨테이너는 독립된 환경에서 실행되기 때문에 서로 격리되어 있다. 그렇기 때문에 컨테이너 A에서 발생한 문제가 컨테이너 B로 영향을 주지 않는다. 또한, 컨테이너는 기본적으로 Stateless이다. 그렇기에 컨테이너를 삭제하면 내부에서 발생한 데이터도 함께 삭제된다. 컨테이너에서 발생한 데이터를 영구적으로 보존하기 위해서는 뒤에서 다룰 볼륨을 사용해야 한다. 컨테이너은 VM을 다루는 포스팅에서 추가로 더 다룰 예정이다.

도커 볼륨

위에서 서술한 것처럼 컨테이너의 데이터를 영구적으로 저장하기 위한 메커니즘이다. 볼륨을 사용하는 방식은 다음과 같다.

• Volume : 도커가 직접 관리하는 저장소이다. /var/lib/docker/volumes 아래에 저장된다.
• Bind Mount : 호스트의 특정 디렉토리를 컨테이너와 직접 연결한다.
• tmpfs Mount : 메모리에 임시로 저장하는 방식이다. 컨테이너가 종료되면 데이터가 사라진다.

도커 네트워크 도커 컨테이너 간 통신을 가능하게 해주는 메커니즘이다. 위에서 서술한 것처럼 컨테이너는 격리된 환경에서 실행되기 때문에 별도의 네트워크 설정 없이는 컨테이너끼리 통신할 수 없다. 가령, WAS와 DB 각각 컨테이너로 실행된다고 가정했을 때 같은 네트워크에 연결되지 않으면 WAS에서 DB를 접근할 수 없다. 통신을 하기 위해서는 IP로 접근을 하지만, 도커에서는 컨테이너 이름으로 접근할 수 있다.

도커 컴포즈

여러 컨테이너를 하나의 파일로 정의하고 관리할 수 있는 도구이다. 네트워크, 볼륨, 컨테이너 설정 등을 docker-compose.yml이라는 파일 하나에 정의하고 명령어 한 번으로 모든 컨테이너를 실행할 수 있다. 만약 도커 컴포즈 없이 여러개의 컨테이너를 실행한다고 하면, 네트워크 생성부터 볼륨 설정 그리고 컨테이너 실행까지 많은 명령어를 CLI에 입력해야 한다. 하지만 도커 컴포즈를 사용하면 명령어 한번으로 사전에 정의된 설정들이 실행된다.

도커라이제이션

그럼 프로젝트에는 어떻게 적용을 했는지 알아보자. 먼저 인프라 구조도이다.

• Github Action에서 빌드 및 도커 이미지 생성
• 생성된 도커 이미지는 도커 허브에 푸쉬, 서버에서 도커 이미지 풀
• 배포 스크립트를 통해 블루/그린 배포 진행

도커 컴포즈로 MySQL, Redis 그리고 블루/그린 WAS를 묶었다. 블루/그린 배포의 경우 현재 띄어져있는 컨테이너를 확인 후, 반대 컨테이너를 새롭게 띄운다. 해당 컨테이너가 정상적으로 올라온 경우, 기존에 실행중인 컨테이너를 죽이는 형식으로 구현을 했다. 관련해서 차츰차즘 포스팅을 해볼 예정이다.

마무리

이번 포스팅에서는 작업 과정에서 접한 내용의 기본 정의만 짚고 넘어갔다. 포스팅을 진행하면서 세부적인 내용을 다룰 예정이다.