☰

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

문제는 다음과 같습니다

  • 내 호스트 Debian 8.2에 기본 설치한 후 OpenVPN에 로그인 syslog하지만 컨테이너 내부에는 로그인하지 않는 이유는 무엇입니까? OpenVPN 로깅을 강제로 수행하도록 호스트에 아무것도 구성하지 않았습니다 syslog. 이는 기본 동작입니다.

  • Docker 컨테이너 내에서 실행되는 OpenVPN 서버에 대한 로깅을 구성하는 방법은 무엇입니까?

답변1

OpenVPN은 시작할 것이 없기 때문에 이 Dockerfile에서 시작되지 않습니다 :-). 진입점은 입니다 sh. 이것이 실행되는 전부입니다.

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

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

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

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

에 따르면 docker logs호스트 시스템 로그에 기록하는 "syslog" 드라이버가 있습니다.docker logs작동하지 않는다고 하는데 , 내 생각엔 그게 당신에게 문제가 되지 않을 것 같아요.

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

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

"왜"라는 질문

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

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

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

관련 정보