개념 사전 · 프로그램

Docker Compose

는 여러 컨테이너의 서비스·네트워크·볼륨 구성을 YAML 파일로 정의하고 함께 관리하는 도구이다. 단일 컨테이너 실행 옵션을 모아 애플리케이션 구조로 표현하지만 여러 노드의 지속적인 스케줄링까지 자동 제공하는 것은 아니다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

웹·앱·DB 같은 여러 서비스의 실행 구성을 묶는다.
서비스 사이 네트워크와 지속 볼륨의 연결을 선언한다.
같은 프로젝트 구성을 반복 실행하고 변경된 서비스 상태를 관리한다.

02어떤 순서로 동작하나

구성 해석
Compose 파일에서 services·networks·volumes와 환경별 입력을 읽어 프로젝트 구성을 만든다.
자원 준비
필요한 이미지를 가져오거나 빌드하고 네트워크와 볼륨을 준비한다.
컨테이너 시작
서비스 설정에 따라 컨테이너를 생성하고 연결한다. 의존 조건은 단순 시작 순서와 실제 준비 완료를 구별하여 설정한다.
상태 관찰·변경
서비스 로그·상태를 확인하고 구성 변경에 맞춰 필요한 컨테이너를 갱신한다. 삭제 옵션에 따라 볼륨의 수명은 별도로 결정된다.

03먼저 알아둘 용어와 구성요소

: 실행할 이미지 또는 빌드 방식, 명령·환경·포트·마운트 등을 모은 애플리케이션 구성 단위다. 서비스 이름은 프로젝트 내부 통신에서 사용하는 식별자와 연결된다.
: Compose가 관련 서비스와 네트워크·볼륨을 묶어 관리하는 범위다. 프로젝트 이름이 달라지면 같은 서비스 이름도 별도 자원 집합으로 관리될 수 있다.
: 서비스끼리 통신할 연결을 선언한다. 호스트에 포트를 공개하는 설정과 컨테이너 내부 연결은 서로 다른 경계다.
: 컨테이너의 쓰기 계층과 별도로 지속할 자료를 관리한다. DB 볼륨이 남아 있다는 사실만으로 일관된 백업이 만들어지는 것은 아니다.
: 컨테이너 안의 검사 결과로 건강 상태를 보고하는 구성이다. 시작 명령이 실행됐다는 사실보다 구체적인 준비 조건을 표현할 수 있다.
: 각 층의 입력과 출력 경계를 정하면 생성 성공, 원격 접속 가능, 서비스 준비 완료라는 서로 다른 완료 기준을 명확히 할 수 있다.

LEARN THROUGH PRACTICE

호스트 9090·4651 포트와 컨테이너의 8080을 연결하기

브라우저 응답을 의 포트 공개 설정과 연결하고 서로 다른 컨테이너의 서비스를 구별한다.

실습 구성과 전제

첫 화면은 자체 Go 웹 애플리케이션, 두 번째는 Jenkins 컨테이너의 별도 실행 사례다. 같은 컨테이너의 전후 화면이 아니다.
구성 예시는 주소·이미지 이름을 재구성한다. Jenkins의 오래된 화면 버전은 관찰 자료이며 현재 설치 권장 버전으로 사용하지 않는다.

컨테이너가 수신하는 포트와 호스트 포트를 구별한다
- Go 웹 애플리케이션은 컨테이너 내부 8080에서 동작하고, 실행 설정의 -p 9090:8080이 호스트 9090을 그 포트로 연결한다. 브라우저는 호스트 주소의 9090으로 요청한다.
- run의 -t는 가상 TTY를 할당하는 옵션이다. 이미지 태그를 지정하는 옵션이 아니며, 이미지의 :태그 표기와 구별한다.
bash
```
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}"
docker port lab-web
```
lab-web은 재구성한 컨테이너 이름이다. 포트 매핑을 조회하는 명령이다.
원본 크기로 보기 ↗
- 브라우저 주소에는 호스트의 9090 포트가 사용된다.
- 본문에 Hello Docker!!가 보여 해당 웹 요청에 애플리케이션 응답이 돌아왔음을 확인할 수 있다.
확인 기준
9090 응답만으로 어떤 컨테이너가 담당하는지 확정하지 않는다. port와 실행 목록으로 매핑을 대조한다.
다른 호스트 포트에 별도 애플리케이션을 공개한다
- Jenkins 예시의 Compose 설정은 호스트 4651을 컨테이너 8080에 연결한다. 서로 다른 컨테이너는 각 네트워크 공간에서 같은 내부 포트를 사용할 수 있다.
- Jenkins의 설정 화면은 HTTP 요청 처리와 초기 설치 UI가 동작한 증거다. 빌드 작업이나 자료 영속성이 검증되었다는 뜻은 아니다.
yaml
```
services:
  app:
    image: example/lab-web:verified
    ports:
      - "127.0.0.1:9090:8080"
```
구조 설명용 재구성 설정이다. example/lab-web:verified는 준비한 실습 이미지로 바꾸며, 로컬 호스트에서만 공개하는 예다.
원본 크기로 보기 ↗
- 브라우저는 4651 포트를 사용한다.
- Jenkins의 Customize Jenkins와 플러그인 설치 선택 화면이 표시되어 첫 화면과 다른 애플리케이션임을 알 수 있다.
확인 기준
두 컨테이너가 같은 호스트 IP·포트를 동시에 점유하려 하면 충돌할 수 있다. 내부 포트가 같은 것과 호스트 공개 포트가 같은 것을 구별한다.
HTTP 성공과 컨테이너·저장 상태를 분리한다
- 실행 중 여부, 포트 공개, 의 실제 리슨, 애플리케이션 응답을 차례로 확인한다. 컨테이너가 Up이어도 서버가 다른 주소나 포트에서 기다릴 수 있다.
- Jenkins의 작업 자료를 유지하려면 별도의 또는 mount를 확인해야 한다. 화면의 설치 UI만으로 컨테이너 재생성 후 데이터 보존까지 증명되지는 않는다.
bash
```
curl -i http://127.0.0.1:9090/
docker inspect --format "{{json .NetworkSettings.Ports}}" lab-web
docker inspect --format "{{json .Mounts}}" lab-web
```
응답·포트·마운트를 서로 다른 관찰 지점에서 확인한다.
확인 기준
재구성 환경에서 curl의 응답과 inspect의 매핑·마운트를 함께 기록한다. 로그에는 초기 비밀 값이 포함될 수 있어 본문에 전재하지 않는다.

실습에서 확인한 동작 원리

HOST_PORT:CONTAINER_PORT는 요청이 어느 네트워크 경계로 전달되는지 나타낸다.
브라우저 응답, 컨테이너 실행, 초기화 완료, 자료 영속성은 각각 별도로 검증해야 한다.

관련 개념·전체 실습 화면 이어서 읽기 →

동작·명령 참고 문서

Docker · 포트 공개 ↗Docker · run의 -p와 -t ↗

04예제로 따라가기

web과 db 서비스가 내부 네트워크로 통신하고 web만 호스트 포트를 공개하면 DB를 외부에 직접 열지 않는 구조를 만들 수 있다.
db 컨테이너를 재생성해도 지정한 을 보존하면 그 저장소의 데이터는 유지할 수 있다. 볼륨 제거 옵션은 별도 판단 대상이다.
depends_on으로 실행 순서를 정해도 DB가 질의를 받을 준비까지 기다리는지는 health 조건 등 실제 설정에 따라 달라진다.

05혼동하기 쉬운 점과 확인 기준

Compose 파일의 환경 변수에 암호를 직접 넣어 저장소에 올리면 구성 재현과 동시에 비밀도 공유된다. 배포 입력과 비밀 저장을 분리한다.
Compose를 사용했다고 여러 호스트의 장애 시 자동 재스케줄링이나 데이터 복제가 생기는 것은 아니다. 단일 프로젝트의 관리 범위를 클러스터 기능과 구별한다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

IaC·Terraform과 재현 가능한 운영인프라를 코드로 관리하려면 정의뿐 아니라 버전·대상·상태·검토·복구 절차가 필요합니다. 도구마다 책임을 나누어 운영합니다.상세 노트 읽기 →컨테이너·Docker와 데이터 지속성컨테이너는 격리된 프로세스 환경입니다. 이미지, 실행 중인 컨테이너, 영속 데이터와 공개 포트를 따로 관리합니다.상세 노트 읽기 →

READ · OBSERVE · CONNECT

함께 보는 학습 자료

아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.

실습 가이드

Compose 의존 서비스의 시작과 준비 상태

Example의 web→db 의존 관계를 먼저 표시하고 Control startup의 세 condition을 비교한다. 준비 검사 성공과 단순 시작이 다른 조건임을 YAML에서 읽을 수 있다.

읽으면서 확인할 것

service_started와 service_healthy의 구별
의 interval·retries·start_period 적용 위치
depends_on의 restart와 명시적인 Compose 재시작의 관계

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.