# 컨테이너 내부에서 컨테이너 빌드하기
번거로운 과정없이 바로 자바 소스를 컨테이너 이미지에서 빌드해보자.
도커파일 작성 > 도커파일 빌드 > 빌드완료
1. 파일 살펴보기
FROM openjdk:8
LABEL description="Echo IP Java Application"
EXPOSE 60433
RUN git clone <https://github.com/iac-source/inbuilder.git>
WORKDIR inbuilder
RUN chmod 700 mvnw
RUN ./mvnw clean package
RUN mv target/app-in-host.jar /opt/app-in-image.jar
WORKDIR /opt
ENTRYPOINT [ "java", "-jar", "app-in-image.jar" ]
- FROM openjdk:8
- 자바 개발 도구가 포함된 이미지
- EXPOSE 60433
- 노출되는 포트의 중복을 피하려고 변경
- RUN git clone https://github.com/iac-source/inbuilder.git
- RUN으로 이미지 내부에서 소스코드 실행
- WORKDIR inbuilder
- git clone 으로 내려받은 디렉토리를 현재 작업 공간으로 설정
- RUN chmod 700 mvnw
- mvnw에 실행 권한 설정
- RUN ./mvnw clean package
- 메이븐 래퍼로 JAR 빌드
- RUN mv target/app-in-host.jar /opt/app-in-image.jar
- 빌드된 JAR을 /opt/app-in-image.jar로 옮김
2. inbuilder 저장소 구조 확인
이미지를 빌드하기 전에 이미지 내부에 내려받은 inbuilder 저장소가 어떤 구조인지 확인한다.
확인해 보면 주요 파일은 모두 같다.
3. Dockerfile을 호출해서 컨테이너 이미지를 빌드한다.
$ docker build -t nohost-img .
4. 기존 이미지와 비교
$ docker images | head -n 4
새로 빌드한 컨테이너 이미지를 기존 이미지들과 비교한다. 새로 생성된 nohost-img가 이미지 중에서 가장 용량이 크다. nohost-img는 컨테이너 내부에서 빌드를 진행하기 때문에 빌드 중간에 생성한 파일들과 내려밪은 라이브러리캐시들이 최종 이미지인 nohost-img에 그대로 남는다. 따라서 빌드 최종 결과물만 전달했던 basic-img 보다 커지게된다.
5. 컨테이너 작동 확인
# 컨테이너 실행
$ docker run -d -p 60433:80 --name nohost-run --restart always nohost-img
# 외부 요청 응답 확인
$ curl 127.0.0.1:60433
6. 컨테이너 삭제
$ docker rm -f nohost-run
openjdk 이미지를 기초 이미지로 컨테이너 내부에서 자바 소스를 빌드한 결과, 가장 큰 컨테이너 이미지를 얻었다. 컨테이너 이미지는 커지면 커질수록 비효율적으로 작동할 수 밖에 없다. 따라서 openjdk 로 컨테이너 내부에서 컨테이너를 빌드하는것은 좋지 않은 방법이다. 하지만 Dickerfile 하나만 빌드하면 컨테이너가 바로 생성되는 편리함을 포기할 순 없다. 다른 방법이 없을까?
https://dodo-devops.tistory.com/23
출처:
"컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 - 조훈,심근우,문성주 지음/길벗출판사" 책을 기반으로 실습한 내용입니다.
'DevOps > 도커(Docker)' 카테고리의 다른 글
쿠버네티스에서 도커 이미지 구동하기 (0) | 2022.06.13 |
---|---|
도커 컨테이너 이미지 만들기 4 - 멀티 스테이지 빌드 (0) | 2022.06.13 |
도커 컨테이너 이미지 만들기 2 - 컨테이너 용량 줄여 빌드하기 (0) | 2022.06.13 |
도커 컨테이너 이미지 만들기 1 - 기본 방법으로 빌드하기 (1) | 2022.06.03 |
도커 컨테이너/이미지 정지하고 삭제하기 (0) | 2022.06.03 |