컨테이너에서 systemd 실행

우리는 오랫동안 컨테이너에서 systemd를 사용하는 주제를 따라왔습니다. 2014년에 보안 엔지니어 Daniel Walsh가 기사를 썼습니다. Docker 컨테이너 내에서 systemd 실행, 그리고 몇 년 후 - 또 다른 이름은 권한이 없는 컨테이너에서 systemd 실행, 그는 상황이 크게 개선되지 않았다고 말했습니다. 특히 그는 “안타깝게도 XNUMX년이 지나도 ‘Docker system’을 구글링하면 가장 먼저 나오는 것은 똑같은 예전 글이다. 그러니 이제는 뭔가를 바꿔야 할 때입니다.” 게다가 우리는 이미 이야기했습니다. Docker와 systemd 개발자 간의 충돌.

이 기사에서는 시간이 지남에 따라 무엇이 변경되었는지, 그리고 Podman이 이 문제에 대해 어떻게 도움을 줄 수 있는지 보여줄 것입니다.

컨테이너 내부에서 systemd를 실행하는 데는 다음과 같은 여러 가지 이유가 있습니다.

1. 다중 서비스 컨테이너 – 많은 사람들이 다중 서비스 애플리케이션을 가상 머신에서 꺼내 컨테이너에서 실행하기를 원합니다. 물론 이러한 애플리케이션을 마이크로서비스로 나누는 것이 더 좋겠지만 아직 모든 사람이 이를 수행하는 방법을 알지 못하거나 시간이 없습니다. 따라서 단위 파일에서 systemd에 의해 시작된 서비스와 같은 애플리케이션을 실행하는 것이 완벽합니다.
2. 시스템 단위 파일 – 컨테이너 내부에서 실행되는 대부분의 애플리케이션은 이전에 가상 또는 물리적 머신에서 실행되었던 코드로 구축되었습니다. 이러한 애플리케이션에는 해당 애플리케이션용으로 작성된 단위 파일이 있으며 실행 방법을 이해합니다. 따라서 자체 초기화 서비스를 해킹하는 것보다 지원되는 방법을 사용하여 서비스를 시작하는 것이 더 좋습니다.
3. Systemd는 프로세스 관리자입니다. 다른 도구보다 서비스를 더 잘 관리합니다(서비스 종료, 서비스 다시 시작 또는 좀비 프로세스 종료).

즉, 컨테이너에서 systemd를 실행하지 않는 데는 여러 가지 이유가 있습니다. 가장 중요한 것은 systemd/journald가 컨테이너의 출력과 다음과 같은 도구를 제어한다는 것입니다. Kubernetes 또는 오픈시프트 컨테이너가 stdout 및 stderr에 직접 로그를 기록할 것으로 예상합니다. 따라서 위에서 언급한 것과 같은 오케스트레이션 도구를 통해 컨테이너를 관리하려는 경우 systemd 기반 컨테이너 사용을 진지하게 고려해야 합니다. 또한 Docker 및 Moby 개발자는 컨테이너에서 systemd를 사용하는 것을 강력하게 반대하는 경우가 많습니다.

포드만의 등장

마침내 상황이 진전되었음을 보고하게 되어 기쁘게 생각합니다. Red Hat에서 컨테이너 실행을 담당하는 팀은 개발하기로 결정했습니다. 나만의 컨테이너 엔진. 그 사람 이름이 있네 포드 맨 Docker와 동일한 명령줄 인터페이스(CLI)를 제공합니다. 그리고 거의 모든 Docker 명령은 Podman에서 동일한 방식으로 사용될 수 있습니다. 우리는 종종 세미나를 개최합니다. Docker를 Podman으로 변경, 그리고 쓰기를 위한 첫 번째 슬라이드 호출: alias docker=podman.

많은 사람들이 그렇게 합니다.

내 Podman과 나는 시스템 기반 컨테이너에 반대하지 않습니다. 결국 Systemd는 가장 일반적으로 사용되는 Linux init 하위 시스템이며 컨테이너에서 제대로 작동하도록 허용하지 않는다는 것은 수천 명의 사람들이 컨테이너 실행에 익숙하다는 것을 무시하는 것을 의미합니다.

Podman은 컨테이너에서 systemd가 제대로 작동하도록 하기 위해 무엇을 해야 하는지 알고 있습니다. /run 및 /tmp에 tmpfs를 마운트하는 것과 같은 것이 필요합니다. 그녀는 "컨테이너화된" 환경을 활성화하는 것을 좋아하며 cgroup 디렉토리의 일부와 /var/log/journald 폴더에 대한 쓰기 권한을 기대합니다.

첫 번째 명령이 init 또는 systemd인 컨테이너를 시작하면 Podman은 systemd가 문제 없이 시작되도록 tmpfs 및 Cgroups를 자동으로 구성합니다. 이 자동 실행 모드를 차단하려면 --systemd=false 옵션을 사용하십시오. Podman은 systemd 또는 init 명령을 실행해야 한다고 판단할 때만 systemd 모드를 사용합니다.

다음은 매뉴얼에서 발췌한 내용입니다.

남자 포드 맨 실행
...

–systemd=true|false

systemd 모드에서 컨테이너를 실행합니다. 기본적으로 활성화되어 있습니다.

컨테이너 내에서 systemd 또는 init 명령을 실행하면 Podman은 다음 디렉터리에 tmpfs 마운트 지점을 구성합니다.

/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal

또한 기본 정지 신호는 SIGRTMIN+3입니다.

이 모든 것을 통해 systemd는 수정 없이 닫힌 컨테이너에서 실행될 수 있습니다.

참고: systemd는 cgroup 파일 시스템에 쓰기를 시도합니다. 그러나 SELinux는 기본적으로 컨테이너가 이 작업을 수행하는 것을 방지합니다. 쓰기를 활성화하려면 Container_manage_cgroup 부울 매개변수를 활성화하십시오.

setsebool -P Container_manage_cgroup true

이제 Podman을 사용하여 컨테이너에서 systemd를 실행하기 위한 Dockerfile의 모습을 살펴보세요.

# cat Dockerfile

FROM fedora

RUN dnf -y install httpd; dnf clean all; systemctl enable httpd

EXPOSE 80

CMD [ "/sbin/init" ]

그게 다야.

이제 컨테이너를 조립합니다.

# podman build -t systemd .

systemd가 Cgroup 구성을 수정할 수 있도록 SELinux에 지시합니다.

# setsebool -P container_manage_cgroup true

그런데 많은 사람들이 이 단계를 잊어버립니다. 다행히 이 작업은 한 번만 수행하면 되며 시스템을 재부팅한 후에 설정이 저장됩니다.

이제 컨테이너를 시작합니다.

# podman run -ti -p 80:80 systemd

systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)

Detected virtualization container-other.

Detected architecture x86-64.

Welcome to Fedora 29 (Container Image)!

Set hostname to <1b51b684bc99>.

Failed to install release agent, ignoring: Read-only file system

File /usr/lib/systemd/system/systemd-journald.service:26 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.

Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)

[  OK ] Listening on initctl Compatibility Named Pipe.

[  OK ] Listening on Journal Socket (/dev/log).

[  OK ] Started Forward Password Requests to Wall Directory Watch.

[  OK ] Started Dispatch Password Requests to Console Directory Watch.

[  OK ] Reached target Slices.

…

[  OK ] Started The Apache HTTP Server.

이제 서비스가 실행되고 있습니다.

$ curl localhost

<html  xml_lang="en" lang="en">

…

</html>

참고: Docker에서는 이 작업을 시도하지 마세요! 데몬을 통해 이러한 종류의 컨테이너를 실행하려면 여전히 탬버린과 함께 춤을 춰야 합니다. (이 모든 것이 Docker에서 원활하게 작동하도록 하려면 추가 필드와 패키지가 필요하거나 권한 있는 컨테이너에서 실행해야 합니다. 자세한 내용은 다음을 참조하세요. 기사.)

Podman과 systemd에 관한 몇 가지 멋진 점

Podman은 시스템 단위 파일에서 Docker보다 더 잘 작동합니다.

시스템 부팅 시 컨테이너를 시작해야 하는 경우 시스템 장치 파일에 적절한 Podman 명령을 삽입하기만 하면 서비스가 시작되고 모니터링됩니다. Podman은 표준 포크 실행 모델을 사용합니다. 즉, 컨테이너 프로세스는 Podman 프로세스의 하위 프로세스이므로 systemd에서 쉽게 모니터링할 수 있습니다.

Docker는 클라이언트-서버 모델을 사용하며 Docker CLI 명령을 단위 파일에 직접 배치할 수도 있습니다. 그러나 Docker 클라이언트가 Docker 데몬에 연결되면 클라이언트(클라이언트)는 stdin 및 stdout을 처리하는 또 다른 프로세스가 됩니다. 결과적으로 systemd는 Docker 클라이언트와 Docker 데몬의 제어 하에 실행되는 컨테이너 간의 연결에 대해 전혀 모르므로 이 모델 내에서 systemd는 기본적으로 서비스를 모니터링할 수 없습니다.

소켓을 통해 systemd 활성화

Podman은 소켓을 통한 활성화를 올바르게 처리합니다. Podman은 fork-exec 모델을 사용하기 때문에 소켓을 하위 컨테이너 프로세스로 전달할 수 있습니다. Docker는 클라이언트-서버 모델을 사용하기 때문에 이를 수행할 수 없습니다.

Podman이 원격 클라이언트와 컨테이너와 통신하는 데 사용하는 varlink 서비스는 실제로 소켓을 통해 활성화됩니다. Node.js로 작성되고 조종석 프로젝트의 일부로 작성된 Cockpit-podman 패키지를 사용하면 사람들이 웹 인터페이스를 통해 Podman 컨테이너와 상호 작용할 수 있습니다. Cockpit-podman을 실행하는 웹 데몬은 systemd가 수신하는 varlink 소켓에 메시지를 보냅니다. 그런 다음 Systemd는 Podman 프로그램을 활성화하여 메시지를 수신하고 컨테이너 관리를 시작합니다. 소켓을 통해 systemd를 활성화하면 원격 API를 구현할 때 지속적으로 실행되는 데몬이 필요하지 않습니다.

또한 동일한 Podman CLI를 구현하지만 varlink를 호출하여 컨테이너를 실행하는 podman-remote라는 또 다른 Podman 클라이언트를 개발 중입니다. Podman-remote는 SSH 세션 위에서 실행될 수 있으므로 다른 시스템의 컨테이너와 안전하게 상호 작용할 수 있습니다. 시간이 지남에 따라 우리는 podman-remote를 활성화하여 Linux와 함께 MacOS 및 Windows를 지원할 계획입니다. 이를 통해 해당 플랫폼의 개발자는 Podman varlink가 실행되는 Linux 가상 머신을 실행하고 컨테이너가 로컬 머신에서 실행되는 전체 경험을 가질 수 있습니다.

SD_NOTIFY

Systemd를 사용하면 필요한 컨테이너화된 서비스가 시작될 때까지 보조 서비스의 시작을 연기할 수 있습니다. Podman은 서비스가 작동 준비가 되었음을 systemd에 알릴 수 있도록 SD_NOTIFY 소켓을 컨테이너화된 서비스로 전달할 수 있습니다. 그리고 클라이언트-서버 모델을 사용하는 Docker는 이를 수행할 수 없습니다.

계획에서

지정된 특정 컨테이너를 관리하기 위해 systemd 단위 파일을 생성하는 podman generate systemd CONTAINERID 명령을 추가할 계획입니다. 이는 권한이 없는 컨테이너에 대해 루트 및 루트 없는 모드 모두에서 작동해야 합니다. OCI 호환 systemd-nspawn 런타임에 대한 요청도 있었습니다.

결론

컨테이너에서 systemd를 실행하는 것은 이해할 수 있는 요구 사항입니다. 그리고 Podman 덕분에 마침내 systemd와 충돌하지 않으면서 사용하기 쉬운 컨테이너 런타임을 갖게 되었습니다.

출처 : habr.com