1. 학습 주제
Dockerfile로 애플리케이션 이미지를 만들고, Docker Compose로 여러 컨테이너를 함께 실행하는 흐름을 학습했다.
추가로 AWS EC2 같은 클라우드 서버에 파일을 올리고, 서버에서 Docker 이미지로 실행하는 기본 배포 흐름도 정리했다.
핵심 내용은 다음과 같다.
- Dockerfile
- Docker 이미지와 컨테이너
- JRE와 JDK 차이
- Spring Boot JAR Docker 이미지 생성
- scp로 EC2 서버에 파일 전송
- EC2 방화벽 설정
- Docker Compose
- Docker Network
- Docker Volume
- Cloud, IaaS, PaaS, SaaS
- AWS 주요 서비스
2. Dockerfile이란?
Dockerfile은 Docker 이미지를 만들기 위한 설명서이다.
이미지를 만들 때 필요한 실행 환경, 파일, 명령어, 실행 순서를 적어둔다.
FROM eclipse-temurin:21-jre
ARG JAR_FILE=build/libs/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]
각 줄의 의미는 다음과 같다.
| 명령어 | 의미 |
| FROM | 어떤 기본 이미지에서 시작할지 지정 |
| ARG | 이미지 빌드 시 사용할 변수 |
| COPY | 로컬 파일을 이미지 안으로 복사 |
| ENTRYPOINT | 컨테이너가 실행될 때 실행할 명령어 |
즉, 위 Dockerfile은 다음 흐름이다.
JRE 21 환경 준비
-> build/libs/*.jar 파일을 app.jar로 복사
-> java -jar /app.jar 실행
3. JRE와 JDK 차이
Java 애플리케이션을 실행할 때 JRE와 JDK를 구분해야 한다.
| 구분 | 의미 |
| JRE | Java 애플리케이션 실행 환경 |
| JDK | JRE + 개발 도구 |
JRE는 이미 만들어진 .jar 파일을 실행하는 데 충분하다.
JDK는 Java 코드를 컴파일하고 개발할 때 필요하다.
이번 Dockerfile은 이미 빌드된 Spring Boot JAR를 실행하는 목적이므로 JDK가 아니라 JRE 이미지를 사용했다.
FROM eclipse-temurin:21-jre
정리하면 다음과 같다.
개발/빌드 필요 -> JDK
실행만 필요 -> JRE
4. Spring Boot 앱 Docker 이미지 만들기
Spring Boot 프로젝트는 먼저 JAR 파일로 빌드한다.
./gradlew build
그 다음 Dockerfile이 있는 위치에서 이미지를 만든다.
docker build -t namhyerhin/dockertest .
여기서 -t는 이미지 이름과 태그를 붙이는 옵션이다.
docker build -t 이미지이름 .
마지막의 .은 현재 디렉터리의 Dockerfile과 파일들을 build context로 사용한다는 뜻이다.
5. 이미지와 컨테이너
Docker에서 이미지는 실행을 위한 템플릿이고, 컨테이너는 이미지를 실제로 실행한 상태이다.
| 개념 | 의미 |
| 이미지 | 실행 환경, 코드, 라이브러리를 묶은 것 |
| 컨테이너 | 이미지를 실행한 프로세스 |
비유하면 다음과 같다.
이미지 = 설계도
컨테이너 = 설계도로 실행된 실제 프로그램
하나의 이미지로 여러 컨테이너를 만들 수 있다.
6. EC2 서버로 파일 전송
로컬에서 빌드한 JAR 파일이나 Dockerfile을 EC2 서버로 올릴 때 scp를 사용할 수 있다.
JAR 파일 전송:
scp -i "/System/Volumes/Data/Users/hyerhin/ubuntu-server.pem" -r /Users/hyerhin/Desktop/hyerhin/Study/lecture/13_AWS/dockerpro/build/libs/dockerpro-0.0.1-SNAPSHOT.jar ubuntu@13.125.208.6:~
Dockerfile 전송:
scp -i "/System/Volumes/Data/Users/hyerhin/ubuntu-server.pem" -r /Users/hyerhin/Desktop/hyerhin/Study/lecture/13_AWS/dockerpro/Dockerfile ubuntu@13.125.208.6:~
흐름은 다음과 같다.
로컬에서 JAR 빌드
-> scp로 EC2에 JAR와 Dockerfile 업로드
-> EC2에서 docker build
-> 컨테이너 실행
-> EC2 보안 그룹에서 포트 오픈
서버에서 애플리케이션을 띄웠더라도 EC2 방화벽, 즉 보안 그룹에서 해당 포트를 열지 않으면 외부에서 접속할 수 없다.
7. 포트 확인과 프로세스 종료
특정 포트를 어떤 프로세스가 사용 중인지 확인할 때 lsof를 사용할 수 있다.
lsof -i :8080
프로세스를 종료할 때는 PID를 확인한 뒤 종료한다.
kill [PID]
예를 들어 8080 포트를 이미 다른 프로세스가 사용 중이면 Spring Boot나 Docker 컨테이너가 같은 포트로 실행되지 않을 수 있다.
8. Docker Compose란?
Docker Compose는 여러 컨테이너를 한 번에 정의하고 실행하는 도구이다.
이번 예제에서는 Node.js 앱과 Redis를 함께 실행했다.
services:
app:
build: .
ports:
- "3000:3000"
depends_on:
- redis
redis:
image: redis:alpine
구조는 다음과 같다.
app 컨테이너
-> Node.js Express 서버
redis 컨테이너
-> Redis 저장소
depends_on은 app 컨테이너가 redis 컨테이너에 의존한다는 뜻이다.
9. Compose에서 컨테이너끼리 통신
Node.js 코드에서는 Redis에 다음 주소로 접속한다.
const client = redis.createClient({ url: 'redis://redis:6379' });
여기서 redis는 localhost가 아니라 Compose 서비스 이름이다.
redis:
image: redis:alpine
Docker Compose 안에서는 같은 네트워크에 있는 서비스끼리 서비스 이름으로 접근할 수 있다.
app 컨테이너
-> redis:6379
-> redis 컨테이너
10. Docker Compose 명령어
자주 사용하는 명령어는 다음과 같다.
docker-compose up
서비스들을 실행한다.
docker-compose down
서비스를 중지하고 생성된 컨테이너와 네트워크를 정리한다.
docker-compose logs -f
실행 중인 로그를 계속 확인한다.
docker-compose config
Compose 설정 파일이 어떻게 해석되는지 확인한다.
docker-compose run [service]
특정 서비스 컨테이너를 일회성으로 실행한다.
11. Docker Network
Docker Network는 컨테이너들이 서로 통신할 수 있게 해주는 가상 네트워크이다.
네트워크 목록은 다음 명령어로 확인할 수 있다.
docker network ls
대표적인 네트워크 드라이버는 다음과 같다.
| 드라이버 | 설명 |
| bridge | 기본 네트워크. 같은 호스트 안의 컨테이너를 격리된 가상 LAN에 연결 |
| host | 컨테이너가 호스트 네트워크를 그대로 사용 |
| overlay | 여러 Docker 호스트 간 컨테이너 연결 |
| macvlan | 컨테이너에 별도 MAC 주소를 부여해 물리 네트워크에 직접 연결 |
| none | 네트워크 없이 컨테이너 실행 |
보통 단일 서버에서 Compose를 사용할 때는 기본적으로 bridge 계열 네트워크가 만들어진다.
12. Docker Volume
Docker Volume은 컨테이너가 삭제되어도 데이터를 유지하거나, 호스트와 컨테이너 사이에 데이터를 공유하기 위해 사용한다.
컨테이너 내부 파일은 컨테이너를 삭제하면 함께 사라질 수 있다.
하지만 Volume을 사용하면 데이터가 컨테이너 생명주기와 분리된다.
컨테이너 삭제
-> 컨테이너 내부 파일은 사라질 수 있음
-> Volume 데이터는 유지 가능
대표적인 방식은 다음과 같다.
| 방식 | 의미 |
| Volume | Docker가 관리하는 저장 공간 |
| Bind Mount | 호스트의 특정 경로를 컨테이너에 직접 연결 |
개발 중에는 로컬 폴더를 바로 연결하는 Bind Mount가 편할 수 있고, 운영에서는 Docker Volume을 사용하는 경우가 많다.
13. 클라우드 서버란?
클라우드 서버는 물리 서버를 직접 구매하지 않고, 클라우드 제공자가 제공하는 가상 서버를 빌려 사용하는 방식이다.
장점은 다음과 같다.
- 초기 비용을 줄일 수 있다.
- 필요한 만큼 서버를 늘리거나 줄일 수 있다.
- 장애 대응과 인프라 관리 기능을 활용할 수 있다.
- 지역, 네트워크, 저장소 같은 자원을 쉽게 선택할 수 있다.
14. Hypervisor
Hypervisor는 가상 머신을 생성하고 실행해주는 기술이다.
VirtualBox도 Hypervisor의 한 종류로 볼 수 있다.
| 타입 | 설명 |
| Type 1 | 하드웨어 위에서 직접 실행 |
| Type 2 | 기존 운영체제 위에서 실행 |
VirtualBox는 일반적으로 내 OS 위에서 실행되므로 Type 2 방식에 가깝다.
15. IaaS, PaaS, SaaS
클라우드 서비스 모델은 보통 IaaS, PaaS, SaaS로 구분한다.
| 구분 | 의미 | 예시 느낌 |
| IaaS | 서버, 네트워크, 스토리지 같은 인프라 제공 | EC2 |
| PaaS | 애플리케이션 실행 플랫폼 제공 | 앱 배포 플랫폼 |
| SaaS | 완성된 소프트웨어 제공 | 네이버 클라우드, Gmail 같은 서비스 |
정리하면 다음과 같다.
IaaS = 가상 서버를 빌림
PaaS = 실행 플랫폼을 빌림
SaaS = 완성된 서비스를 사용
16. AWS 주요 서비스
AWS에는 다양한 인프라 서비스가 있다.
| 서비스 | 역할 |
| EC2 | 가상 서버 제공 |
| S3 | 이미지, 문서, 동영상 같은 객체 스토리지 |
| VPC | AWS 내부 네트워크 구성 |
| IAM | 사용자와 권한 관리 |
| Route 53 | DNS 서비스 |
| ECS | Docker 컨테이너 실행 관리 |
| EKS | Kubernetes 기반 컨테이너 실행 관리 |
| SQS | 메시지 큐 서비스 |
| Lambda | 서버 없이 함수 단위 코드 실행 |
이번 흐름에서는 EC2가 가장 직접적으로 연결된다.
EC2에 Ubuntu 서버를 만들고, 그 위에서 Docker를 설치해 애플리케이션 컨테이너를 실행할 수 있다.
17. IAM 계정
IAM은 AWS 리소스에 대한 접근 권한을 관리하는 서비스이다.
누가
어떤 리소스에
어떤 작업을 할 수 있는지
정하는 보안 시스템
예를 들어 어떤 사용자는 EC2 조회만 가능하고, 어떤 사용자는 S3 업로드까지 가능하게 권한을 나눌 수 있다.
실무에서는 루트 계정을 직접 쓰기보다 IAM 사용자나 역할을 만들어 권한을 제한해서 사용하는 것이 안전하다.
18. 핵심 정리
- Dockerfile은 Docker 이미지를 만들기 위한 실행 환경과 순서를 적는 파일이다.
- docker build -t 이미지명 .으로 현재 디렉터리의 Dockerfile을 기준으로 이미지를 만들 수 있다.
- JRE는 Java 실행 환경이고, JDK는 JRE에 개발 도구까지 포함한 것이다.
- 이미 빌드된 Spring Boot JAR 실행만 필요하면 JRE 이미지로 충분하다.
- 이미지는 실행 템플릿이고, 컨테이너는 이미지를 실행한 상태이다.
- scp를 사용하면 로컬 파일을 EC2 서버로 전송할 수 있다.
- EC2에서 서버를 띄워도 보안 그룹에서 포트를 열어야 외부 접속이 가능하다.
- lsof -i :8080으로 특정 포트를 사용하는 프로세스를 확인할 수 있다.
- Docker Compose는 여러 컨테이너를 한 번에 정의하고 실행하는 도구이다.
- Compose 안에서는 서비스 이름으로 컨테이너끼리 통신할 수 있다.
- Docker Network는 컨테이너 간 통신을 위한 가상 네트워크이다.
- Docker Volume은 컨테이너 삭제와 무관하게 데이터를 유지하거나 공유하기 위해 사용한다.
- Cloud는 서버와 인프라 자원을 직접 소유하지 않고 빌려 쓰는 방식이다.
- IaaS는 인프라, PaaS는 플랫폼, SaaS는 완성된 소프트웨어를 제공한다.
- AWS EC2는 가상 서버, S3는 객체 저장소, IAM은 접근 권한 관리 서비스이다.
'TIL > [TIL]' 카테고리의 다른 글
| [TIL]CI/CD, GitHub Actions, Argo CD, Jenkins, Kubernetes, AWS 배포 (0) | 2026.08.05 |
|---|---|
| [TIL]Linux, Ubuntu, Vim, Docker 기초 (0) | 2026.08.03 |
| [TIL]LangSmith로 Workflow 추적과 평가하기 (0) | 2026.07.31 |
| [TIL]Agent Safety와 Plan-Execute-Replan Workflow (0) | 2026.07.30 |
| [TIL]Agentic AI, Tool Calling, ReAct, Agent Memory (0) | 2026.07.29 |