![[도서 리뷰] 그림으로 배우는 도커 (Docker, Dockerfile, docker-compose)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2F3vw9m%2FbtsNw3g1go5%2FGA4VvPXBIhisgXyknkkpR1%2Fimg.jpg)

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다
도서 정보
https://www.hanbit.co.kr/store/books/look.php?p_code=B6249658359
그림으로 배우는 도커
도커의 기본부터 고급 활용까지 쉽게 배우는 단계별 가이드
www.hanbit.co.kr
📋 목차
- 1부 가상화와 도커 기본 지식
- 2부 도커 컨테이너 활용법
- 3부 도커 이미지 활용법
- 4부 도커 파일 활용법
- 5부 고급 도커 컨테이너 활용법
- 6부 고급 도커 컨테이너 활용법
- 7부 운영시 주의할 점과 트러블 슈팅
📋 목차 내용 요약
1부 ~ 3부
도커의 등장 배경부터 도커가 왜 필요한지 설명하며, 이미지, 컨테이너, 볼륨 등 기본 개념과 컨테이너 관련 명령어를 실습 중심으로 배워갑니다. 처음 접하는 입문자도 흐름을 쉽게 따라갈 수 있도록 그림, 표와 함께 정리되어 있습니다.
4부
Dockerfile의 구조와 기본 명령어(FROM, RUN, COPY, CMD, ENV 등)를 소개하고, 우분투 베이스 이미지에 vi 패키지를 설치하는 실습을 통해 이미지 빌드 과정을 익힙니다.
5부 ~ 6부
실습 예제로 DB, 웹 서버, 메일 서버 컨테이너 서비스를 직접 명령어로 구성해보고, 이를 docker-compose로 변환하는 방법을 배웁니다. 활용도가 높은 docker-compose 작성하는 방법을 익히는데 유용합니다.
7부
도커 플랜부터 시작해 .env, .dockerignore 파일, 간단한 트러블슈팅 방법 등 도커 운영 시 알아두면 좋은 팁들이 정리되어 있습니다. (기본적인 내용만 다루기 때문에 운영환경에서 .env을 관리하는 방법, 컨테이너 확장 전략 등은 다루지 않습니다)
리뷰
📘 그림으로 배우는 도커는 기초 개념부터 시작해 Dockerfile, 도커 컴포즈까지 단계별로 설명해 주기 때문에, 도커를 처음 접하는 분들에게는 기본기를 다지기에 좋고, 이미 실무를 경험한 입장에서는 스스로의 부족한 부분을 점검하고 보완하기에 적절한 책이라고 느꼈습니다.
특히 인상 깊었던 건 “COLUMN. 비슷하지만 다른 것” 시리즈였습니다. 이 섹션에서는 평소 헷갈리기 쉬운 명령어나 개념들을 비교 중심으로 깔끔하게 정리해 줘서 이해도를 높이는 데 큰 도움이 되었고, 실무에서도 바로 사용할 수 있을 만큼 실용성도 있었습니다. 실무에선 늘 시간이 부족해 정리하지 못했던 개념들이 마음 한켠에 있었는데, 도서를 통해 정리할 수 있어서 개인적으로 유익했습니다.
📋 Docker
🐳 도커(Docker)는 애플리케이션을 실행하는데 필요한 시스템 도구, 환경 설정, 라이브러리, 의존성 등을 하나의 작은 소프트웨어 단위인 컨테이너(Container) 안에 패키징할 수 있게 하는 도구입니다. 어디서든 안정적으로 실행하고 배포할 수 있도록 도와주는 도구이면서, 컨테이너 안에는 단순히 애플리케이션 코드 뿐만 아니라 런타임 환경 설정, 라이브러리, 필요한 리소스까지 함께 포함되어 개발 환경과 운영 환경 간의 차이로 인한 문제를 최소화합니다.
과거에는 가상 머신(Virtual Machine, 예로 VMWare, VirtualBox 등)을 사용해 환경을 분리했습니다. VM은 Hypervisor라는 가상화 소프트웨어 위에 운영체제(OS) 전체를 올리는 방식이라, 운영 체제가 포함된 만큼 무겁고, 실행 속도도 느리며, 시스템 자원을 많이 사용했습니다. (참고. Virtualized Deployment)
반면, 컨테이너는 Host OS(ex. 내 컴퓨터, 로컬)에 컨테이너 엔진(Container Engine, 예로 Docker)을 설치한 뒤 필요한 소프트웨어를 OS 없이 컨테이너로 실행합니다. Host OS 운영 체제를 공유하는 것을 Container Engine이 처리해주기 때문에 VM보다 훨씬 가볍고 빠르며, 효율적입니다. (참고. Container Deployment)
컨테이너 엔진 중 가장 널리 사용되고, 커뮤니티의 사랑을 받는 대표적인 도구가 바로 🐳 도커(Docker) 입니다.
대표적인 컨테이너 엔진으로는 Docker, containerd, CRI-O 등이 있으며, 최근에는 OCI(Open Container Initiative) 표준을 준수하는 런타임들이 많이 사용되고 있습니다
참고. 널널한 개발자님 유튜브 영상
https://www.youtube.com/watch?v=zh0OMXg2Kog
도커의 네트워크, 볼륨과 마운트를 제대로 이해 못하고 사용했었는데, 이번 기회를 통해 개념을 정리하고 이해할 수 있었습니다.
📋 네트워크
- 도커에서 컨테이너 간 통신은 네트워크를 통해 이루어집니다.
- 특별한 설정이 없다면, 도커는 기본적으로 bridge라는 기본 브릿지 네트워크를 사용합니다.
- 하지만, 기본 브릿지는 DNS 기반 컨테이너 이름 통신이 되지 않거나, 연결이 제한되기 때문에 사용자 정의 브릿지 네트워크(user-defined bridge network)를 사용하는 것이 일반적입니다.
- 기본 브릿지를 사용하는 경우 컨테이너마다 IP로 접속해야 하는데 재시작시 IP가 변경됨 ☠️
- 사용자 정의 브릿지 네트워크를 형성하게 되면 hostname 통해 쉽게 컨테이너간 통신 가능 👍
- 사용자 정의 네트워크를 사용하면 컨테이너 간 이름으로 통신이 가능하고, 격리성 및 구성 유연성이 좋아집니다.
서비스명을 hostname으로 하여 mybridge 네트워크에서 컨테이너간 통신을 할 수 있습니다.
services:
app:
image: myapp
networks:
- mybridge
db:
image: mysql
networks:
- mybridge
networks:
mybridge:
driver: bridge
📋 볼륨과 바인드 마운트
볼륨(volume)
- 데이터를 지속적으로 보존하고, 여러 컨테이너에서 공유하거나 복구 가능한 형태로 사용합니다.
- 도커가 직접 관리하는 내부 디렉터리(/var/lib/docker/volumes/...)에 데이터를 저장합니다.
- 컨테이너를 삭제하더라도 볼륨은 삭제되지 않으며, 필요시 재사용이 가능합니다.
하위 명령어 | 설명 |
ls | 목록을 표시합니다 |
inspect | 상세 내용을 표시합니다 |
create | 볼륨을 작성합니다 |
rm | 볼륨을 삭제합니다 |
prune | 모든 미사용 볼륨을 삭제합니다 |
✅ --mount옵션으로 볼륨 마운트하는 경우
docker run \
--name mysql-container \
--mount type=volume,source=db-data,target=/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=1234 \
-d mysql:8
- type=volume: Docker 관리 볼륨 사용
- source=db-data: 볼륨 이름 (미리 만들어지지 않았다면 자동 생성됨)
- target=/var/lib/mysql: 컨테이너 내부에 마운트할 경로
✅ 도커 컴포즈로 볼륨 마운트 하는 경우
services:
db:
image: mysql:8
environment:
- MYSQL_ROOT_PASSWORD=1234
volumes:
- db-data:/var/lib/mysql
volumes:
db-data:
db-data 볼륨으로, 데이터베이스 파일들이 외부에 보존됩니다.
바인드 마운트 (bind mount)
- 호스트 머신의 특정 디렉터리를 컨테이너 내부 경로에 연결합니다.
- 컨테이너와 호스트 간의 파일 실시간 동기화가 필요할 때 사용합니다.
- 예를 들어 로컬 소스 코드를 컨테이너에서 바로 실행하거나 로그를 외부에서 바로 확인할 때 유용합니다.
<key> | <value> | 설명 |
type | bind | 바인트 마운트라면 bind |
source | "${pwd}" | 마운트 원본, pwd 명령어로 디렉터리의 전체 경로 지정 |
destination | /my-work | 마운트 대상 경로 지정 |
✅ --mount옵션으로 바인트 마운트하는 경우
docker run \
--name nginx-container \
--mount type=bind,source="$(pwd)/nginx.conf",target=/etc/nginx/nginx.conf \
-p 8080:80 \
-d nginx
- type=bind: 호스트 디렉터리 또는 파일 마운트
- source="$(pwd)/nginx.conf": 현재 디렉터리의 파일을 마운트 (경로는 절대경로로 해석됨)
- target=/etc/nginx/nginx.conf: 컨테이너 내부에서 참조할 경로
✅ 도커 컴포즈로 바인드 마운트하는 경우
services:
app:
image: nginx
volumes:
- type: bind
source: ./nginx.conf
target: /etc/nginx/nginx.conf
📋 새롭게 알게 된 사실들
“COLUMN. 비슷하지만 다른 것” 시리즈를 통해서 실무에서 모호했던 명령어를 비교, 정리할 수 있는 좋은 기회가 되었습니다. 특히, PID1(Process ID)과 레이어라는 개념을 처음 접하게 되었는데, 학습한 이후 도커 명령어의 동작 원리를 이해하고 사용할 수 있게 되어서 좋았습니다.
🎯 도커 컨테이너와 PID1
- 리눅스 시스템에서 모든 프로세스의 부모는 PID1이며, 일반적으로는 systemd와 같은 초기화 프로세스가 담당합니다.
- 도커 컨테이너 내부에서도 마찬가지로 PID1은 특수한 의미를 가집니다. 컨테이너에서 가장 먼저 실행된 프로세스가 PID 1이 되며, 그 이후의 모든 프로세스는 이 프로세스의 자식으로 실행됩니다.
- 예로 docker exec 명령어로 ls, top 등의 명령을 실행하면, 각 명령이 별도의 컨텍스트에서 PID1로 실행되고 종료됩니다.
🎯 도커 이미지와 레이어
- 도커 이미지란 여러 개의 레이어(layer)로 구성된 읽기 전용 파일 시스템입니다.
- 각 레이어는 tar 아카이브 형태로 저장되며, 베이스 이미지(예. Ubuntu)에 추가 설정이나 패키지를 덧붙이는 방식으로 구성됩니다. (예를 들면, 우분투 레이어 + PHP 설치 레이어 + 설정 파일 레이어처럼 누적되는 구조)
- 이처럼 레이어는 변경된 부분만 추가로 기록되며, 이전 레이어와 중첩되어 하나의 통합된 파일 시스템을 구성합니다.
- Dockerfile은 레이어를 정의하는 설정 스크립트 파일로, 각 명령어(FROM, COPY, RUN 등)가 하나의 레이어를 생성합니다.
🔎 COLUMN, 기존 명령어와 새로운 명령어의 호환성 문제
새로운 명령어 | 기본 명령어 |
docker container ls | docker ps |
docker image ls | docker images |
docker image rm | docker rmi |
- Docker 1.13 부터 모든 명령어를 그룹화 (🔗공식 링크)
- 2025.04.22 기준 최신 버전은 4.40.0
🔎 COLUMN, 비슷하지만 다른 것#1 - container exec와 container attach와 container run
docker container exec [OPTIONS] CONTAINER COMMAND [ARG...]
- 가동 중인 컨테이너에서 PID1이 아닌 새로운 프로세스를 실행
- ls 명령어를 실행하면 ls 명령어의 프로세스가 실행되고 종료
- bash 명령어를 실행하면 exit 하기 전까지 종료하지 않음
- 참고. docker container exec🔗
docker container attach [OPTIONS] CONTAINER
- 컨테이너의 PID1의 입출력을 호스트머신 터미널 입출력에 연결
- container attach는 PID1에 접속하므로 연결 중인 터미널에 [Ctrl + C]를 실행하면 PID1 종료 시그널을 전달
- PID1이 종료되면 컨테이너도 종료
- 참고. docker container attach🔗
docker container run [OPTIONS] IMAGE [COMMAND] [ARG...]
- container run은 container create + container start + container attach에 해당하는 명령어
- 참고. docker container run🔗
🔎 COLUMN, 비슷하지만 다른 것#2 - ENV와 container run --env
ENV 명령은 Dockerfile에서 컨테이너 환경 변수 설정시 사용합니다
# Dockerfile
FROM ubuntu:22.04
ENV TZ=Asia/Seoul
✅ 장점
- 환경변수가 이미지 안에 고정되므로, 배포 실수 없이 일관된 설정 보장
- 실행할 때 옵션 없이도 설정 적용 (관리 편리)
⚠️ 단점
- Dockerfile을 열어보기 전까지 어떤 환경 변수가 설정되어 있는지 알기 어려움
- 환경 변수를 바꾸려면 이미지를 다시 빌드
- Dockerfile 명령에 대한 러닝 커브
container run --env는 터미널에서 CLI 명령어로 환경 변수를 지정하여 컨테이너 가동시 사용합니다
docker container run --env TZ=Asia/Seoul ubuntu:22.04
✅ 장점
- 컨테이너 단위로 설정 가능하므로 가동할 때마다 유연하게 지정할 수 있음
⚠️ 단점
- container run 명령어가 길어지고, 환경 변수를 직접 타이핑하므로 실수 가능성 존재
- 공유/재사용이 어렵고, 문서화하지 않으면 어떤 설정으로 실행했는지 추적이 힘듦
🔎 COLUMN, 비슷하지만 다른 것#4 - 바인드 마운트와 COPY
바인드 마운트는 컨테이너 명령어 실행시 호스트 머신의 디렉터리를 컨테이너에 마운트(연결)합니다
docker run --mount type=bind,source=/home/user/app,target=/app my-image
✅ 장점
- 실시간으로 명령어 수정 가능
- 이미지 빌드 없이 바로 반영 가능 (개발 및 테스트 용이)
⚠️ 단점
- 호스트 디렉터리에 대한 의존성 존재
- 호스트와 컨테이너의 파일 또는 디렉터리가 연결되어 있어 실수로 수정/삭제 가능
COPY 명령 은 Dockerfile에서 이미지에 파일을 복사할 때 사용합니다
# Dockerfile
COPY ./config/nginx.conf /etc/nginx/nginx.conf
✅ 장점
- 이미지 내에 파일을 고정적으로 포함
- 배포 환경에서 일관성을 보장
⚠️ 단점
- 이미지가 고정되므로 수정하려면 빌드 및 재실행 필요
- 명령어 대비 실시간 변경이 불가능
📄 Dockerfile이란?
도커파일(Dockerfile)은 컨테이너 이미지를 만들기 위한 설정 스크립트 파일입니다. 필요한 패키지 설치, 환경 변수 설정, 파일 복사, 실행 명령 등을 기록해두면 빌드시 베이스 이미지에 각 레이어를 차곡차곡 쌓아 올려줍니다. 책에서는 Dockerfile을 처음 접하는 독자들을 위해 FROM, RUN, ENV, COPY, CMD 같은 기본 명령어를 중심으로 설명하고, 직접 우분투 베이스 이미지에 vi 패키지를 설치하는 실습을 다룹니다. 실습은 간단하기 때문에 리뷰에서는 다루지 않으며, 대신 실무에서 직접 작성해 본 Dockerfile을 간단히 공유해보겠습니다.
🔎 명령어 관련 목차
17.1 베이스 이미지 지정하기 FROM
FROM 명령은 기본이 되는 이미지를 지정합니다.
FROM [--platform=<platform>] <image> [AS <name>]
17.3 명령어를 실행해서 레이어 확정하기 RUN
- RUN 명령은 리눅스 명령어를 실행하고 그 결과를 레이어로 확장합니다.
- RUN 명령 작성시 && 기호 통해 리눅스 명령어를 연결할 수 있습니다
- 예시. RUN apt-get update && apt-get install -y vim
- 앞의 apt-get update 명령어가 성공했을때 뒤의 apt-get install -y vim 명령어를 실행합니다
- 명령어를 전부 &&로 연결하면 아무리 많은 명령어를 실행해도 레이어 1개로 만들어집니다. (*이미지 용량을 줄임)
RUN <COMMAND>
18.1 이미지 환경 변수 지정하기 ENV
ENV 명령은 메타데이터에 환경 변수를 추가합니다
ENV <key>=<value> ...
18.2 호스트머신의 파일을 이미지에 추가하기 COPY
- COPY 명령은 호스트머신(로컬, 내 컴퓨터)의 파일을 이미지에 복사해서 레이어를 작성합니다
- COPY는 <src>... <dest> 형식으로 지정해서 호스트머신의 원본 파일을 이미지 내부에 복사합니다
- 호스트머신의 상대 경로는 image build의 PATH | URL | - 매개변수로 지정한 컨텍스트가 기준점입니다
COPY [--chown=<user>:<group>] [--chmod=<perms>] <src>... <dest>
직접 활용해 본 Dockerfile
실무에서 AWS ECS 컨테이너 서비스 이관하면서 Dockerfile을 작성했습니다. 아래 전체 Flow 중 ②번에서 사용되었고, Dockerfile 빌드하여 이미지를 생성한 후 배포하게 됩니다. AWS ECR은 AWS에서 제공하는 도커 허브(저장소)에 해당합니다. AWS ECS에서는 설정된 AWS ECR에서 최신 이미지를 가져와 사용자 정의에 따라 컨테이너 서비스를 롤링 방식(default)으로 배포합니다.
참고. Flow
① 작업 완료 후 Bitbucket에 깃 이력을 커밋 (release branch로 배포)
② Jenkins에서 CI/CD
- release branch의 이벤트 감지
- maven build 실행 (./target/*.war 생성)
- 🎯 docker image build 실행 ( 이때 {project root}/Dockerfile 위치)
③ 지정한 AWS ECR로 docker image push
④ AWS ECS Service에 배포 요청 (AWS CLI 명령어로 실행)
⑤ Task Definition 설정에 따라 연결된 AWS ECR에서 최신 image 가져와 컨테이너 실행
⑥ AWS Secrets Manager 호출해 어플리케이션 실행에 필요한 운영 환경 변수 주입
책에서는 다루지 않은 WORKDIR, ARG, ENTRYPOINT를 사용했는데 표 설명 첨부해두었기 때문에 이해하는데 어렵지 않으실거라 생각합니다. 요약하자면 Jenkins에서 Maven 빌드한 결과 *.war 파일을 베이스 이미지(openjdk:8-jre)에 복사해서 컨테이너 시작될 때 실행하게 됩니다. Dockerfile을 사용한 덕분에 컨테이너 이미지를 관리하거나 배포하기 유용했습니다.
# Dockerfile
FROM openjdk:8-jre
WORKDIR /app
ARG WAR_FILE=target/*.war
COPY $WAR_FILE /app/package.war
ARG JAVA_OPTS=-Dspring.profiles.active=default
ENV TZ="Asia/Seoul"
ENV JAVA_OPTS=$JAVA_OPTS
ENTRYPOINT ["sh", "-c", "java -Djava.security.egd=file:/dev/./urandom $JAVA_OPTS -jar /app/package.war"]
FROM | 베이스 이미지를 openjdk:8-jre로 지정합니다. (운영 환경이기 때문에 jre 사용) |
WORKDIR | 컨테이너 내부에서 작업할 디렉터리를 설정합니다. 이후 명령어들을 /app을 기준으로 실행됩니다. |
ARG | 이미지 빌드시 사용할 변수(인자)를 정의합니다. WAR_FILE, JAVA_OPTS가 해당되고 빌드 타임에 외부에서 유연하게 주입할 수 있도록 설정했습니다. |
ENV | 컨테니어가 실행될 때 사용할 환경 변수를 설정합니다. |
COPY | 호스트 머신의 파일을 컨테이너로 복사합니다. 여기서는 *.war 파일을 /app/pacakge.war로 복사합니다. |
ENTRYPOINT | 컨테이너가 시작될 때 실행할 명령을 정의합니다. 여기서는 스프링 기반 java 어플리케이션을 실행합니다. |
📄 docker-compose 란?
도커 컴포즈(docker-compose)는 다수의 컨테이너를 정의하고 일괄적으로 실행, 관리할 수 있는 도구입니다. YAML 형식으로 컨테이너의 이미지, 네트워크, 볼륨 등을 정의하며, docker-compose up 명령 하나로 여러 컨테이너를 함께 실행할 수 있습니다. 또한, 도커 컴포즈는 Dockerfile을 통해 이미지를 직접 빌드할 수도 있습니다. 이 경우 build: 옵션을 사용하여 소스 디렉토리(context)와 사용할 도커파일을 지정하면, 컴포즈가 자동으로 이미지를 빌드한 뒤 컨테이너를 실행합니다. 즉, 도커 컴포즈는 미리 빌드된 이미지 사용과 Dockerfile을 통한 이미지 빌드 후 실행을 모두 지원합니다.
개인적으로 도커 컴포즈 사용할 경우 도커 허브의 오픈 소스 이미지를 주로 사용했는데, Dockerfile 빌드도 같이 사용할 수 있다는 걸 알게 되어 인상적이었습니다.
services:
app:
build:
context: .
dockerfile: Dockerfile
🔎 YAML 파일명
공식적으로 추천하는 이름은 compose.yaml 입니다. docker-compose.yaml과 docker-compose.yml은 기존 버전 호환성을 위해 지원합니다. 파일을 작성한다면 compose.yaml을 사용하는 것을 권장합니다.
- compose.yaml (✨ 공식적으로 추천하는 이름 )
- docker-compose.yaml
- docker-compose.yml
🔎 compose.yaml (도서 실습 예제 中)
- 도커 컴포즈는 컨테이너를 서비스(servicce)로 다룹니다
- compose.yaml 파일의 루트에 services 속성을 정의하고, 그 아래에 컨테이너마다 서비스를 정의합니다
- services 속성 바로 다음 단계에 정의한 속성은 서비스 식별자가 됩니다 (예. app, db, mail)
services:
app:
생략
db:
environment:
- MYSQL_ROOT_PASSWORD=secret
- MYSQL_USER=app
- MYSQL_PASSWORD=pass1234
- MYSQL_DATABASE=sample
- TZ=Asia/Seoul
ports:
- "3306:3306"
volumes:
- type: volume
source: db-compose-volume
target: /var/lib/mysql
- type: bind
source: ./docker/db/init
target: /docker-entrypoint-initdb.d
image: mysql:8.4.2
mail:
생략
volumes:
db-compose-volume:
mail-compose-volume:
db 서비스의 하위 속성에 대해
- environment : 환경 변수 설정 (관리자 및 기본 사용자 설정, 기본 데이터베이스, 타임존 설정)
- ports : 로컬 호스트의 3306 포트와 컨테이너의 3306 포트를 맵핑
- volumes : 컨테이너 엔진에서 관리하는 volume 통해 db 정보 저장, bind의 경우 호스트 OS에 있는 db 초기화 디렉터리를 연결
- image : mysql:8.4.2 이미지를 내려받아 컨테이너 실행합니다
만약 도커 컴포즈를 사용하지 않았다면 아래와 같이 직접 CLI 명령어를 매번 입력해야 합니다. 실수하기 딱 좋습니다☠️
참고. 직접 CLI 명령어로 입력하는 경우
$ docker container run
\ --name db
\ --rm
\ --detach
\ --env MYSQL_ROOT_PASSWORD=secret
\ --env MYSQL_USER=app
\ --env MYSQL_PASSWORD=pass1234
\ --env MYSQL_DATABASE=sample
\ --env TZ=Asia/Seoul
\ --publish 3306:3306
\ --mount
\ type=volume,source=work-db-volume,dst=/var/lib/mysql
\ --mount
\ type=bind,source="${pwd}"/docker/db/init,dst=/docker-entrypoint-initdb.d
\ mysql:8.4.2
직접 활용해 본 docker-compose
토이 프로젝트에서 모니터링 환경을 구축하기 위해 Prometheus와 Grafana를 도입했습니다. 초기에는 각각의 컨테이너를 수동으로 명령어로 실행하고 설정을 관리했지만, 반복적이고 불편함이 커서 docker-compose로 구성 방식을 전환했습니다. docker-compose.yml 파일을 작성하면서, 네트워크를 직접 정의하고, 설정 파일과 데이터를 마운트하여 구성 요소들을 코드로 관리할 수 있게 되었고, 프로젝트 공유 시 다른 사람들도 쉽게 실행 환경을 구성할 수 있어 매우 유용했습니다.
또한, 네트워크를 명시적으로 정의(mybridge)함으로써 Prometheus와 Grafana 간의 통신 안정성을 높일 수 있었고, 호스트 포트 매핑을 통해 브라우저에서 바로 각 대시보드에 접근할 수 있어 테스트 및 모니터링이 수월해졌습니다. 결과적으로 도커 컴포즈를 활용한 이 경험은 컨테이너 환경의 일관성 유지, 재현성, 공유 편의성 측면에서 큰 이점을 느끼게 해주었습니다.
docker-compose.yml
services:
prometheus:
image: prom/prometheus-linux-amd64
container_name: prome
hostname: prome
volumes:
- ./prometheus/config:/etc/prometheus
- ./prometheus/data:/data
ports:
- 9090:9090
networks:
- mybridge
grafana:
image: grafana/grafana
container_name: grafana
hostname: grafana
ports:
- 3000:3000
networks:
- mybridge
networks:
mybridge:
driver: bridge
터미널을 켜고 도커 컴포즈 파일 위치한 경로에서 명령어를 실행하면 도커 컴포즈에서 관리하는 서비스 컨테이너가 함께 시작/종료됩니다
# 컨테이너 실행
docker-compose up -d
# 종료
docker-compose down
웹 브라우저 통해 Prometheus와 Grafana 콘솔창에 접속하여 모니터링할 수 있었습니다 🎉
*Prometheus
*Grafana
🎉 마치면서
그림으로 배우는 도커🐳 를 읽고 난 후 앞으로 도커를 좀 더 잘 다룰 수 있을 거라는 자신감이 생겼습니다. 마치 기출 요약 문제집을 보는 것과 같이 도커의 기본기를 탄탄히 다지면서 부족했던 부분을 찾아 정리할 수 있었고, 공식 문서를 찾아보는 습관을 기를 수 있었던 것도 성과였습니다. 실무에서 빠르게 일을 쳐내다 보면 결과물을 만들어야 하다 보니 공식 문서를 잘 안 보게 되었는데, 이번 기회에 반성할 수 있었습니다. 도커를 실무에만 얕게 써본 분이라면, 이 책을 통해 개념부터 다지면서 명령어를 왜 그렇게 쓰는지 이해할 기회가 될 거라 생각합니다. 전체 400p를 읽는데 3일 정도 걸렸는데, 도커를 사용하면서 저와 비슷한 고민을 했다거나 책을 구매하기 망설이는 분에게 도움이 되길 바라면 리뷰를 마무리하겠습니다. 감사합니다
Reference
'독서 > 📚' 카테고리의 다른 글
[개발 도서] 리팩터링 2판 - 스터디 회고 (Java, JUnit5) (0) | 2025.04.07 |
---|---|
[도서 리뷰] 자바 코드의 품질을 높이는 100가지 방법, 자바 베테랑이 전하는 실전 오류 패턴과 해법 (0) | 2025.03.07 |
[도서 리뷰] 그로킹 알고리즘(개정판) (1) | 2025.02.21 |
[도서 리뷰] 단위 테스트의 기술 (Jest, JavaScript, TypeScript, 1~5장) (1) | 2025.01.25 |
[도서] 만화로 배우는 리눅스 시스템 관리1 - 요약 정리 (4) | 2025.01.21 |

포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!