이번 커밋은 LearningCollector 뿐만 아니라 my-blog 백엔드 및 프론트엔드 로그에 대한 볼륨 마운트 설정을 추가하여 Docker Compose 파일을 업데이트했습니다. 이를 통해 각 서비스의 로그를 더 효율적으로 관리하고 접근할 수 있게 되었습니다.

monitoring: LearningCollector 및 my-blog 로그 볼륨 마운트 설정 변경

요약

이번 작업은 docker-compose.yml 파일을 수정하여 LearningCollector의 로그 볼륨 마운트 설정을 최적화하고, my-blog 백엔드 및 프론트엔드 서비스의 로그도 동일하게 마운트할 수 있도록 설정을 추가하는 내용입니다. 총 4라인이 추가되고 1라인이 삭제되었습니다. 작업은 2026년 2월 8일에 이루어졌으며, monitoring 레포지토리의 main 브랜치에서 진행되었습니다.

배경 및 목적

기존에는 LearningCollector 서비스만 특정 로그 경로를 호스트 파일 시스템에 마운트하여 관리하고 있었습니다. 하지만 서비스가 확장됨에 따라 my-blog 백엔드와 프론트엔드 서비스의 로그도 통합적으로 관리하고, 필요에 따라 빠르게 접근하여 분석해야 할 필요성이 생겼습니다. 이 작업의 목적은 Docker Compose 설정을 통해 세 가지 서비스의 로그 볼륨을 효율적으로 관리하고, 개발 및 운영 중 발생하는 문제를 신속하게 파악할 수 있도록 환경을 구축하는 것입니다.

구현 내용

주요 변경사항은 docker-compose.yml 파일 내 services 섹션의 promtail 서비스 설정 부분입니다.

변경된 파일 목록

docker-compose.yml

코드 변경 규모

추가 라인: 4
삭제 라인: 1

핵심 코드 설명

docker-compose.yml 파일의 promtail 서비스 설정 부분에서 다음과 같은 변경이 이루어졌습니다.

--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -53,8 +53,11 @@
       - /var/lib/docker/containers:/var/lib/docker/containers:ro
       - /var/run/docker.sock:/var/run/docker.sock
       - ./volumes/promtail-positions:/tmp
-      - /home/jcw/LearningCollector_v1.0/log:/app/LearningCollector/log:ro
       - ./config/promtail/config.yml:/etc/promtail/config.yml
+      # 아래는 호스트fs의 앱의 로그 폴더 마운트
+      - /home/jcw/LearningCollector_v1.0/log:/app/LearningCollector/log:ro
+      - /home/jcw/my-blog/backend/logs:/app/my-blog/backend/logs:ro
+      - /home/jcw/my-blog/frontend/logs:/app/my-blog/frontend/logs:ro
     command: -config.file=/etc/promtail/config.yml
     networks:
       - monitoring

기존에는 LearningCollector의 로그 경로만 마운트하고 있었으나, 이번 변경으로 my-blog 백엔드와 프론트엔드의 로그 경로도 호스트 파일 시스템에서 promtail 컨테이너로 마운트되도록 설정되었습니다. 주석을 통해 이 부분이 "호스트fs의 앱의 로그 폴더 마운트"임을 명확히 했습니다.

기술적 의사결정

이번 작업은 Docker Compose의 볼륨 마운트 기능을 활용하여 로그 파일을 컨테이너 내부에서 접근 가능하도록 설정하는 것입니다. 별도의 새로운 기술이나 라이브러리를 도입한 것은 아니지만, 기존 설정을 확장하는 과정에서 몇 가지 고려사항이 있었습니다.

선택: Docker Compose의 volumes 키를 사용하여 호스트 파일 시스템의 특정 디렉토리를 컨테이너 내부의 디렉토리에 매핑하는 방식을 그대로 사용했습니다.
이유: 이미 LearningCollector의 로그 마운트에 사용되고 있던 안정적이고 검증된 방식입니다. 각 서비스의 로그를 중앙에서 수집하고 관리하는 Promtail과 같은 로깅 에이전트를 사용할 때 일반적으로 사용되는 패턴이기도 합니다.
다른 대안:
- Docker Volumes: Docker 관리 볼륨을 사용하는 방법도 고려할 수 있었지만, 개발 환경에서 호스트 파일 시스템의 경로를 직접 지정하는 것이 로그 파일을 직접 확인하고 수정하기에 더 직관적이라고 판단했습니다.
- Logging Drivers: Docker의 자체 로깅 드라이버를 설정하여 로그를 외부 시스템으로 전달하는 방법도 있지만, 이는 컨테이너 내부에 로그 파일을 직접적으로 마운트하는 것과는 목적이 다릅니다. 이번 작업은 로그 파일 자체에 대한 직접적인 접근성을 높이는 데 초점을 맞추었습니다.
장단점:
- 장점: 설정이 간단하고 직관적이며, 호스트 파일 시스템의 로그를 쉽게 확인하고 편집할 수 있습니다.
- 단점: 호스트 파일 시스템의 경로에 의존적이므로, 컨테이너를 다른 환경으로 이전하거나 배포할 때 경로 설정에 주의가 필요합니다. 또한, 직접적인 파일 마운트는 I/O 성능에 영향을 줄 수 있습니다.

배운 점 및 개선점

이번 작업을 통해 Docker Compose의 volumes 설정을 활용하여 여러 서비스의 로그를 통합적으로 관리하는 방법을 다시 한번 명확히 할 수 있었습니다. 특히, 각 서비스별로 로그 파일이 저장되는 경로를 정확히 파악하고 이를 Docker Compose 설정에 반영하는 것이 중요하다는 것을 깨달았습니다.

앞으로 개선할 점

경로 관리 자동화: 호스트의 로그 경로를 직접 입력하는 대신, 환경 변수 등을 활용하여 설정을 좀 더 유연하게 관리할 수 있도록 개선할 수 있습니다.
로깅 스키마 통일: 각 서비스에서 생성하는 로그 메시지의 형식을 통일하여 Promtail 등에서 파싱하고 분석하기 더 용이하게 만들 수 있습니다.
보안 고려: 민감한 정보가 로그에 포함되지 않도록 주의하고, 필요하다면 로그 마스킹이나 필터링 설정을 추가할 수 있습니다.

다음 단계 계획

Promtail 설정을 업데이트하여 새로 마운트된 my-blog 로그를 정상적으로 수집하도록 구성합니다.
실제로 로그가 잘 수집되고 있는지 모니터링하며, 문제가 발생할 경우 즉시 해결합니다.
장기적으로는 로그 관리 및 분석 파이프라인 전반에 대한 점검 및 개선 작업을 진행할 계획입니다.

참고 자료

Docker Compose volumes documentation