<aside>
☁️ 클라우드웨이브 시리즈 · W03 · 5/5 · 예상 읽기 6~8분
</aside>
이번 주 학습을 정리하며 나는 healthcheck, 의존성 조건, secrets로 실행 중인 서비스의 준비 상태와 민감정보 경계를 다룬다.라는 질문에서 출발했다. 처음에는 명령을 순서대로 외우려 했지만, 실제로는 실행 단위와 데이터, 통신, 준비 상태를 분리해서 보는 편이 훨씬 명확했다.
Docker는 애플리케이션을 일관된 실행 단위로 묶는 플랫폼이다. 이미지는 실행에 필요한 파일과 설정의 템플릿이고, 컨테이너는 그 이미지를 실행한 상태다. Compose는 여러 서비스와 관계를 선언 파일로 묶는다. 이 관점은 healthcheck, 의존성 조건, secrets로 실행 중인 서비스의 준비 상태와 민감정보 경계를 다룬다.의 핵심이다.
services:
app:
image: example/app:stable
networks:
- internal
volumes:
- app-data:/var/lib/app
networks:
internal:
volumes:
app-data:
이 예시는 실제 계정, 주소, 호스트명, 비밀값을 포함하지 않는 문서용 구성이다. 설정을 읽을 때는 서비스, 이미지 또는 빌드, 포트, 데이터, 네트워크 순으로 확인한다.
컨테이너가 실행 중이라는 사실과 애플리케이션이 요청을 받을 준비가 됐다는 사실은 다르다. 데이터가 컨테이너 안에 보인다는 사실도 영속성이 보장됐다는 뜻은 아니다. 또한 네트워크에 연결됐다고 해서 외부에 공개된 것은 아니다. 이런 경계를 섞으면 설정은 동작해도 운영 이유를 설명하기 어렵다.
healthcheck는 정의한 준비 조건을 확인하고, depends_on은 그 관계를 표현한다. secrets는 비밀값을 이미지와 일반 문서에서 분리하는 경계다.
변경이 잦은 부분과 재사용할 부분을 구분했는가? 서비스가 교체돼도 남아야 할 데이터가 무엇인가? 외부에 열어야 할 경계는 어디인가? 실행 순서가 아니라 준비 상태를 어떻게 확인할 것인가? 이 질문을 리뷰 목록으로 만들면 설정 파일이 단순한 실행 명령 모음이 아니라 운영 문서가 된다.
profiles는 필요한 서비스만 조건부로 시작하게 하는 선택지이고, deploy는 서비스의 배포 관련 구성을 표현하는 영역이다. depends_on은 서비스 사이의 의존 관계를 나타내지만, 단순히 컨테이너가 먼저 시작했다는 사실과 애플리케이션이 요청을 받을 준비가 됐다는 사실은 다르다. healthcheck는 그 준비 상태를 확인하는 기준을 제공하고, 의존성 조건은 그 확인 결과를 다음 서비스의 시작 흐름과 연결한다. PostgreSQL과 pgAdmin 구성을 읽을 때도 데이터베이스 컨테이너가 만들어진 순서만 보는 것이 아니라, 실제로 필요한 서비스가 어떤 조건에서 사용 가능한지와 debug profile이 언제 포함되는지를 나누어 살펴봐야 한다.
secrets는 비밀번호처럼 민감할 수 있는 값을 일반 환경 설정이나 이미지 내용과 분리해 전달하는 경계다. 환경변수와 env_file은 실행 설정을 전달하는 방식으로 사용되지만, 그 안에 무엇을 넣을지는 공개 범위와 함께 판단해야 한다. PostgreSQL과 pgAdmin을 한 Compose 구성으로 묶으면 서비스 간 의존성, volume의 데이터 위치, healthcheck의 준비 기준을 함께 검토할 수 있다. 이때 설정 파일에 보이는 서비스 정의와 실제 비밀값을 같은 종류의 정보로 취급하지 않는 것이 핵심이다. profiles, deploy, depends_on, healthcheck, secrets를 함께 읽으면 시작 순서와 준비 상태, 설정과 비밀의 분리, 운영 준비도를 각각 질문할 수 있고, 운영 환경을 이미 달성했다고 과장하지 않으면서 어떤 확인이 더 필요한지도 남길 수 있다.