다중 컨테이너를 활용한 애플리케이션의 개발 환경 구축 - 1

이 포스팅은 『따라 하며 배우는도 커와 CI 환경 』을 보고 썼다.

 

실무에서 애플리케이션 프로젝트를 진행하려면 백엔드 서버와 데이터베이스 등 많은 요소가 필요하다. 도커를 통해 이러한 앱들을 컨테이너를 통해 활용하므로 멀티 컨테이너 애플리케이션이라 부른다.

 

멀티 컨테이너 애플리케이션을 위한 전체적인 설계

엔진엑스를 사용하는 용도에 따라 두 가지 설계로 나눠보자. 첫 번째 방법은 클라이언트에서 엔진엑스로 오는 요청을 백엔드 서버와 프런트엔드 서버로 나누는 구조이다. 두 번째 방법은 엔진엑스는 프런트엔드 서버로만 사용해 클라이언트에서 정적 파일을 요구할 때 이를 제공하는 형식으로만 사용하는 구조이다. 두 가지 방법의 장단점을 살펴보자.

엔진엑스의 프록시 기능을 이용한 설계

첫 번째 설계 방식은 엔진엑스를 두 가지 역할로 이용한다. 엔진엑스에 있는 프락시 기능과 정적 파일을 제공하는 기능이다. 클라이언트에서 요청을 보낼 때 요청이 프런트엔드 서버를 위한 것이면 프런트 엔드 서버 쪽으로 보내고, 백엔드 서버를 위한 요청이면 백엔드 서버로 보낸다. 

 

이러한 설계의 장점은 다음과 같다. 요청을 보낼 때 호스트의 이름이 바뀌더라도 경로 부분(endpoint)을 변경하지 않아도 되는 점이다. 이렇게 되는 이유는 요청이 왔을 때 엔진엑스에서 프록시 기능을 이용해 프런트엔드 서버와 백엔드 서버로 라우팅을 처리하기 때문이다. 이에 대한 단점은 엔진엑스 설정 부분이 다소 복잡하며, 전체 적인 설계도 다소 복잡하다.

엔진엑스는 정적 파일만 제공하는 설계

이 방법은 엔진엑스의 프록시 기능은 이용하지 않고 클라이언트에서 프런트엔드 서버에 요청하는 정적파일만 제공하는 방식이다.

 

이 방식의 장점은 설계가 간단해서 구현하기가 더 쉽다는 점이다. 단점으로는 호스트 이름이나 포트변경이 있을 때 모든 요청의 경로를 변경해야 한다. 엔진엑스가 프락시 기능을 제공하지 않기 때문에 어디로 라우팅을 할지 엔진엑스는 모르기 때문이다.

 

리액트 애플리케이션을 위한 도커 파일 만들기

개발 환경을 위한 도커 파일 Dockerfile.dev:

FROM node:alpine

WORKDIR /app

COPU package.json ./

RUN npm install

COPU ./ ./

CMD ["npm", "run", "start"]

운영 환경을 위한 도커 파일

# 엔진엑스에 제공할 빌드 파일을 생성하는 단계
FROM node:alpine as builder
WORKDIR /app
COPY ./package.json ./
RUN npm install
COPY . .
RUN npm run build

# 엔진엑스를 가동하고 앞서 생성한 빌드 파일을 제공한다.
# default.conf에 해준 설정을 엔진엑스 컨테이너 안으로 복사한다.
FROM nginx
EXPOSE 3000
COPY ./nginx/default.conf /etc/nginx/conf.d/default.conf
COPY --from=builder /app/build /usr/share/nginx/html