도커파일부터 도커컴포즈까지

 

 

 

도커컴포즈를 배포하기 위해  백엔드와 프론트엔드를 묶은 도커컴포즈 파일을 만들었다.

 

아래는 도커파일부터 이미지 빌드 및 배포,  그리고 도커컴포즈 yml파일을 통한 실행까지의

 

과정과 트러블슈팅을 간략히 작성하였다.

 

 

---

 

Dockerfile

도커컴포즈에 필요한 이미지는 

 

MySQL

REDIS

백엔드 (스프링)

프론트엔드 

 

4개이며 DB는 공식이미지를 다운받으면 되므로

 

백엔드와 프론트엔드를 도커파일로 작성하였다.

 

 

백엔드 도커파일 

도커파일 - 빌드 실패

FROM gradle:8-jdk17-focal

LABEL purpose='Backend'  \
        version='1.0'

WORKDIR /app

COPY gradle/wrapper ./gradle/wrapper \
     src ./src \
     README.md ./README.md \
     build.gradle ./build.gradle \
     gradlew ./gradlew \
     settings.gradle ./settings.gradle

RUN chmod +x ./gradlew
RUN ./gradlew build

CMD ["java", "-jar", "build/libs/backend-0.0.1-SNAPSHOT.jar"]

FROM gradle:8-jdk17-focal AS build

WORKDIR /home/gradle/src

COPY . .

RUN gradle build --no-daemon


FROM openjdk:17.0-jdk-slim

EXPOSE 8080

RUN mkdir /app

COPY --from=build /home/gradle/src/build/libs/*.jar /app/spring-app.jar

ENTRYPOINT ["java", "-jar", "/app/spring-app.jar"]

 

일반적으로 빌드했을떄는 

RUN chmod +x ./gradlew  를 찾지못해서 이미지가 빌드되지 않았다.

그래서 COPY . . 을 하거나

RUN 레이어를 구분하거나 chmod를 변경하거나,

cd를 넣어 경로를 직접 지정해주거나 하는등
장장 5시간 동안 구글 검색에서 나오는 모든 방법을 사용해보았지만

빌드되지 않았다.

 

그래서 백엔드 대신 프론트엔드 도커파일을 먼저 만들며  적용한 멀티 스테이지 빌드를

백엔드에 적용해보았는데  이건 성공하였다.  (왜?)

 

 

 

프론트엔드 도커파일

FROM node:16 AS builder

WORKDIR /app

COPY package.json . \
     package-lock.json . 

RUN  npm install

COPY . .
RUN npm run build



FROM nginx

COPY --from=builder /app/build /usr/share/nginx/html 
     
EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

 

프론트는 딱히 큰 에러가 나지 않고 잘 빌드되었다.

 

 

 

---

 

 

Docker image

이미지는 도커파일 빌드 과정에서 환경변수를 일일이 입력해줘야했던 점과

백엔드 도커파일을 실행했을때  DB 를 실행하지 않아 스프링이 올라가던 중에 에러가 났던

두가지 트러블이 있었다.

 

하지만 간단한 트러블이었기에 빠르게 해결하고 도커 허브에 이미지를 푸시할 수 있었다.

 

 

 

---

Docker compose

도커컴포즈에서는 버전을 직접 명시하지 않아 처음에 실행되지 않았던 것

(버전 대신 latest를 입력하여서 파일을 도커허브에서 찾지 못함)

 

우분투의 IP주소 대신 localhost를 입력하여 프론트 접속이 되지 않았던 에러가 있었다.

(그러나 이미지를 사용하여 프론트엔드 컨테이너를 올렸을때는 localhost로 접속이 되었는데

아직 둘의 차이를 찾지 못함)

 

두가지 에러가 있었지만 어찌저찌 잘 해결하였다.

 

 

 

---

 

 

느낀점

왜 CICD를 하는지 알 수 있었다.

팀원들과 실시간으로 프로젝트를 진행하면서  깃허브에 merge될 때마다

도커파일을 빌드하고 다시 이미지를 버전업하여 도커허브에 푸시한 다음

도커컴포즈를 재시작하거나 docker-compose pull 을 해서 최신버전을 적용해줘야 했다.

 

이걸 겪기전까지는 CICD에서 자동으로 merge 되는 CI가 중요하다고 생각했었는데

CD가 더 중요함을 깨달을 수 있었고,  최대한 빠른 시일내로 적용할 수 있도록 해야겠다. 

 

 

 

---

 

 

인프라 남은 일정

1. Jenkins 로 CICD 

2. 엔진엑스 리버스프록시 적용  (프론트 앞에만 적용할지,  프론트와 백 사이에도 적용할지 고민)

3. 쿠버네티스 (가능?)