☰

Docker 컨테이너 내부에서 로깅을 구성하는 방법은 무엇입니까?

tag-icon • tag-icon debian syslog docker rsyslog container
Docker 컨테이너 내부에서 로깅을 구성하는 방법은 무엇입니까?

OpenVPN 서버를 도커화(Debian 8.2로)하려고 했지만(예, 알고 있습니다. 이미 그러한 컨테이너가 있습니다) 컨테이너 내부에 문제가 발생하여 서버가 시작되지 않았습니다.

로그를 검사하기로 결정했지만 /var/log/syslog컨테이너 내부에 (여기 내 호스트 컴퓨터의 OpenVPN 로그)가 없습니다.

나는 그것이 rsyslog설치되지 않았다고 생각하고 OpenVPN 설치 전에 설치를 Dockerfile에 추가했습니다. 그러나 이것은 효과가 없었고 syslog여전히 누락되었습니다.

내 Dockerfile은 다음과 같습니다.

FROM debian:8.2
USER root
EXPOSE 53/udp
EXPOSE 1194/udp
EXPOSE 443/tcp
RUN apt-get update
RUN apt-get install -y rsyslog
RUN apt-get install -y openvpn
# ...
# Some configuration stuff
# ...
ENTRYPOINT service openvpn start && sh

질문은 다음과 같습니다

  • OpenVPN이 내 호스트 Debian 8.2에 기본 설치된 후 로그인 syslog하고 컨테이너 내부에서는 수행하지 않는 이유는 무엇입니까? OpenVPN 로그를 syslog. 이는 기본 동작이었습니다.

  • Docker 컨테이너 내에서 실행되는 OpenVPN 서버의 로깅을 어떻게 구성합니까?

답변1

OpenVPN은 시작할 것이 없기 때문에 해당 Dockerfile로 시작하지 않습니다 :-). 귀하의 진입점은 sh; 그게 전부입니다.

Docker 내에서 두 개의 데몬을 시작하려면 두 데몬을 모두 시작하는 프로그램이 진입점이어야 합니다. 많은 사람들이 supervisord이것을 위해 사용합니다. Docker는 상대적으로 독선적인 소프트웨어이며 하나의 컨테이너에서 여러 데몬을 실행하는 것은 관용적인 것으로 간주되지 않습니다.

이것이 디버깅에 관한 것이라면 문제가 없습니다. or openvpn와 함께 실행하지 마십시오 . stdout에 쓸 것입니다(아마도 stderr를 보고 놀라지는 않을 것입니다). 수동으로 시작하는 경우 디버깅에 유용합니다. 터미널에서 모든 로그 메시지를 즉시 볼 수 있습니다.--daemon--log

진입점을 설정하고 대화형 모드에서 컨테이너를 수동으로 시작하는 경우에도 마찬가지입니다. 백그라운드 컨테이너로 시작하면(모호함을 이해해 주세요) 출력은 docker logs. 이는 systemd(및 systemd "저널" 로깅 시스템)와 같은 최신 init 시스템에서 선호하는 것과 동일한 기술입니다.

원하는 대로 데몬을 설정한 후에는 다른 답변과 같이 로그 캡처를 위한 보다 사용자 정의된 시스템에 관심이 있을 수 있습니다.

Docker에는 맨페이지에 따르면 플러그 가능한 로깅 드라이버가 있습니다 docker logs. 호스트 syslog에 기록한다고 말하는 "syslog" 드라이버가 있습니다. 그것은 작동하지 않을 것이라고 말하지만 docker logs그것이 당신에게 문제가 될 것이라고는 예상하지 않습니다.

경고: docker logs저널 로깅 드라이버를 사용하면 작동합니다. 그러나 Debian 기본값에서는 재부팅 시 로그가 손실될 수 있다고 가정합니다. 데비안은 영구 저널을 설정하지 않기 때문입니다. 하지만 그것이 당신이 원하는 것이라면 변경하는 것은 어렵지 않습니다.

명령을 지원하는 다른 로깅 드라이버 docker logs는 "json-file"입니다. 나는 그것이 지속될 것으로 예상하지만 다른 솔루션 중 하나를 선호할 수도 있습니다.

"왜"라는 질문

요점은 Docker 컨테이너가 반드시 기반이 되는 OS와 동일하게 작동할 필요는 없다는 것입니다. Docker는 LXC, systemd-nspawn또는 가상 머신과 같은 OS 가상화가 아닙니다 . Docker는 에서 파생되었지만 LXC단일 프로그램을 실행하는 "애플리케이션 컨테이너"용으로 특별히 설계되었습니다.

(현재) 서버 배포판은 여러 실행 프로그램의 조합으로 설계되었습니다. 따라서 패키지를 가져와 이러한 애플리케이션 컨테이너 내에서 정확히 동일한 방식으로 작동할 것이라고 기대할 수는 없습니다.

로깅 데몬과의 통신이 좋은 예입니다. 사람들이 애플리케이션 컨테이너의 개념에 더 익숙해진다는 점을 제외하면 바뀔 것은 없습니다. 그리고 그것이 그들이 실제로 사용하고 싶은 것인지 여부 :). 나는 많은 시스템 관리자가 컨테이너 간에 패키지를 공유하기 위해 NixOS와 같은 것을 사용하는 LXC(OS 컨테이너) 매시업에 더 관심이 있을 것이라고 생각합니다. 아직 AFAIK로 작성되지 않았습니다. 아니면 그냥더 나은 LXC.

관련 정보