<aside>
☁️ 클라우드웨이브 시리즈 · W03 · 2/5 · 예상 읽기 6~8분
</aside>
이번 주 학습을 정리하며 나는 컨테이너 수명과 데이터 수명을 분리하고, 볼륨·바인드 마운트·사용자 정의 네트워크를 연결한다.라는 질문에서 출발했다. 처음에는 명령을 순서대로 외우려 했지만, 실제로는 실행 단위와 데이터, 통신, 준비 상태를 분리해서 보는 편이 훨씬 명확했다.
Docker는 애플리케이션을 일관된 실행 단위로 묶는 플랫폼이다. 이미지는 실행에 필요한 파일과 설정의 템플릿이고, 컨테이너는 그 이미지를 실행한 상태다. Compose는 여러 서비스와 관계를 선언 파일로 묶는다. 이 관점은 컨테이너 수명과 데이터 수명을 분리하고, 볼륨·바인드 마운트·사용자 정의 네트워크를 연결한다.의 핵심이다.
services:
app:
image: example/app:stable
networks:
- internal
volumes:
- app-data:/var/lib/app
networks:
internal:
volumes:
app-data:
이 예시는 실제 계정, 주소, 호스트명, 비밀값을 포함하지 않는 문서용 구성이다. 설정을 읽을 때는 서비스, 이미지 또는 빌드, 포트, 데이터, 네트워크 순으로 확인한다.
컨테이너가 실행 중이라는 사실과 애플리케이션이 요청을 받을 준비가 됐다는 사실은 다르다. 데이터가 컨테이너 안에 보인다는 사실도 영속성이 보장됐다는 뜻은 아니다. 또한 네트워크에 연결됐다고 해서 외부에 공개된 것은 아니다. 이런 경계를 섞으면 설정은 동작해도 운영 이유를 설명하기 어렵다.
볼륨은 Docker가 관리하는 저장 공간이고 바인드 마운트는 호스트 경로를 연결하는 방식이다. 서비스 통신은 임시 IP보다 네트워크 안의 이름을 기준으로 설계한다.
변경이 잦은 부분과 재사용할 부분을 구분했는가? 서비스가 교체돼도 남아야 할 데이터가 무엇인가? 외부에 열어야 할 경계는 어디인가? 실행 순서가 아니라 준비 상태를 어떻게 확인할 것인가? 이 질문을 리뷰 목록으로 만들면 설정 파일이 단순한 실행 명령 모음이 아니라 운영 문서가 된다.
registry는 이미지를 보관하고 가져오는 경계이며, 컨테이너의 실행 상태나 애플리케이션 데이터 자체를 대신 보존하는 공간과는 구분된다. named volume은 Docker가 관리하는 이름 있는 저장 공간으로 컨테이너의 수명과 데이터를 분리할 때 사용하고, bind mount는 호스트의 특정 경로를 컨테이너에 연결해 파일을 직접 공유하는 방식으로 이해할 수 있다. 같은 볼륨이라는 말로 묶어도 관리 주체와 경로의 의미가 다르므로, 설정을 읽을 때는 이미지가 어디에서 오는지와 데이터가 어디에 남는지를 따로 확인해야 한다.
Docker bridge network는 같은 네트워크에 연결된 컨테이너 사이의 통신 범위를 만들고, alias는 그 안에서 서비스를 식별할 이름을 제공한다. 따라서 FastAPI 컨테이너를 구성할 때는 실행 중인 프로세스의 상태, registry에서 가져온 배포물, 다른 컨테이너와 통신하는 경계를 한 덩어리로 보지 않는 것이 중요하다. 포트를 외부에 공개하는 설정과 내부 네트워크에서 이름으로 연결하는 설정도 서로 다른 책임이다. 실습에서 볼륨과 네트워크를 함께 다룬 이유는 데이터의 지속 위치와 요청의 이동 경로를 각각 확인하면서, 컨테이너를 교체해도 무엇이 남고 무엇이 다시 연결되어야 하는지 설명하기 위해서다.