<aside>
☁️ 클라우드웨이브 시리즈 · W03 · 4/5 · 예상 읽기 6~8분
</aside>
이번 주 학습을 정리하며 나는 Compose에서 서비스·네트워크·볼륨을 프로젝트 단위로 묶고 최종 구성을 검토하는 방법을 정리한다.라는 질문에서 출발했다. 처음에는 명령을 순서대로 외우려 했지만, 실제로는 실행 단위와 데이터, 통신, 준비 상태를 분리해서 보는 편이 훨씬 명확했다.
Docker는 애플리케이션을 일관된 실행 단위로 묶는 플랫폼이다. 이미지는 실행에 필요한 파일과 설정의 템플릿이고, 컨테이너는 그 이미지를 실행한 상태다. Compose는 여러 서비스와 관계를 선언 파일로 묶는다. 이 관점은 Compose에서 서비스·네트워크·볼륨을 프로젝트 단위로 묶고 최종 구성을 검토하는 방법을 정리한다.의 핵심이다.
services:
app:
image: example/app:stable
networks:
- internal
volumes:
- app-data:/var/lib/app
networks:
internal:
volumes:
app-data:
이 예시는 실제 계정, 주소, 호스트명, 비밀값을 포함하지 않는 문서용 구성이다. 설정을 읽을 때는 서비스, 이미지 또는 빌드, 포트, 데이터, 네트워크 순으로 확인한다.
컨테이너가 실행 중이라는 사실과 애플리케이션이 요청을 받을 준비가 됐다는 사실은 다르다. 데이터가 컨테이너 안에 보인다는 사실도 영속성이 보장됐다는 뜻은 아니다. 또한 네트워크에 연결됐다고 해서 외부에 공개된 것은 아니다. 이런 경계를 섞으면 설정은 동작해도 운영 이유를 설명하기 어렵다.
Compose의 최상위 네트워크와 볼륨 선언은 자원을 정의하고, 서비스 아래 설정은 실제 연결 위치를 정한다. 외부 포트 공개와 내부 통신도 구분한다.
변경이 잦은 부분과 재사용할 부분을 구분했는가? 서비스가 교체돼도 남아야 할 데이터가 무엇인가? 외부에 열어야 할 경계는 어디인가? 실행 순서가 아니라 준비 상태를 어떻게 확인할 것인가? 이 질문을 리뷰 목록으로 만들면 설정 파일이 단순한 실행 명령 모음이 아니라 운영 문서가 된다.
Compose lifecycle은 파일을 읽고 서비스를 만들고 실행하며, 필요할 때 중지하거나 다시 정리하는 흐름으로 이어진다. YAML은 이 흐름에 필요한 서비스, volume, network의 관계를 선언하는 형식이다. 환경변수는 실행 시 필요한 설정을 전달하는 경계로 보고, 이미지에 포함된 내용과 분리해 확인해야 한다. 이렇게 보면 Compose 파일은 명령어 모음이 아니라 애플리케이션을 어떤 서비스 묶음으로 실행할지 설명하는 선언형 문서가 된다. 같은 파일을 검토할 때도 서비스의 책임, 데이터가 연결되는 위치, 통신이 허용되는 범위를 차례로 확인할 수 있다.
읽기 전용 볼륨은 서비스가 공유된 데이터를 볼 수는 있지만 변경하지 못하도록 책임을 제한하는 설정이다. 반대로 쓰기가 필요한 서비스는 별도의 쓰기 경계를 가져야 하므로, volume 모드만 보고 데이터 흐름을 단정하면 안 된다. external network는 현재 Compose 프로젝트가 네트워크를 새로 만드는 대신 이미 존재하는 네트워크를 참조하는 구조로 이해할 수 있다. 이 경우 네트워크의 생명주기와 서비스의 생명주기가 같지 않다는 점이 중요하다. 서비스·volume·network를 각각 선언하고 서로의 소유 범위를 구분하면, 프로젝트를 올리고 내리는 과정에서 무엇이 함께 생성되고 무엇이 외부에 남는지 설명할 수 있다.