Toolbox: 도구 상자 컨테이너 내부의 호스트에서만 실행할 수 있는 잘 알려진 바이너리용 shim 제공

/usr/libexec/toolbox/bin 추가하고 쉘 시작 스크립트를 변경하여 $PATH 먼저 삽입하면 훨씬 간단해질 것이라고 생각합니다.

도구 상자 내에서 podman을 실행하는 것은 매우 유용할 수 있습니다. 저는 빌드 스크립트가 도커 이미지를 호출하는 많은 프로젝트에서 작업하며 도구 상자 내에서 이러한 스크립트를 실행할 수 있다는 것이 정말 유용할 수 있습니다. 툴박스가 아닌 Silverblue 호스트를 반영하는 홈 디렉토리 외부의 바인드 마운트와 관련된 문제를 감지하기 어려울 수 있습니다.

개발자 흐름에 유용한 항목 목록에 docker-compose 를 추가하겠습니다. 데이터 저장소 한두 개를 필요로 하는 항목에 대한 진입 장벽이 정말 낮기 때문에 상당한 수의 웹 앱 유형 항목이 사용합니다(오픈 소스 여부).

파생 도구 상자 FROM registry.fedoraproject.org/f31/fedora-toolbox:31 만듭니다. 이 파생 도구 상자에서 /usr/local/bin/host-runner host-runner 스크립트를 만들어 이 문제를 해결했습니다.

$ cat /usr/local/bin/host-runner 
#!/bin/bash 
executable=$(basename $0)
set -x
exec flatpak-spawn --host $executable "$@"

그런 다음 호스트 컨텍스트에서 실행하려는 모든 항목에 대해 host-runner 대한 심볼릭 링크를 만듭니다.

$ ls -l /usr/local/bin/
total 4
lrwxrwxrwx. 1 root root 13 Jan 28 14:16 chromium-browser -> ./host-runner
-rwxr-xr-x. 1 root root 89 Jan 31 10:39 host-runner
lrwxrwxrwx. 1 root root 13 Jan 29 10:51 podman -> ./host-runner
lrwxrwxrwx. 1 root root 13 Jan 28 12:39 systemctl -> ./host-runner
lrwxrwxrwx. 1 root root 13 Jan 28 12:39 virsh -> ./host-runner
lrwxrwxrwx. 1 root root 13 Jan 28 12:39 virt-install -> ./host-runner

참고 : 사용자가 호스트에 프록시하기를 원하는 명령 목록은 사용자마다 다를 수 있으므로 구성하는 일반적인 방법을 만든 다음 사용자가 직접 수행하도록 해야 합니다.

그런 다음 도구 상자 내에서 작업을 실행하지만 호스트를 통해 프록시됩니다. 유일한 추가 비트는 실행되는 실제 명령이 실행되기 전에 stderr에 인쇄된다는 것입니다. 예를 들어:

$ virsh list --all
+ exec flatpak-spawn --host virsh list --all
 Id   Name              State
----------------------------------
 43   f31_vanilla-f31   running
 47   tester            running
 -    fcos              shut off

생성된 도구 상자 컨테이너에서 이와 같은 것을 제공할 수 있습니다. 나는 아직도 이것을 조금 연마하고 있다. 아직 작동하지 않는 한 가지는 사용자가 호스트에서 sudo로 명령을 실행하려는 경우 수행해야 할 작업입니다.

복제를 시도했지만 새 이미지를 빌드하는 대신 host-runner 를 ~/.local/bin . 그리고 그렇게 게으른 결과

[user<strong i="8">@toolbox</strong> ~] podman ps
+ exec flatpak-spawn --host podman ps
+ exec flatpak-spawn --host podman ps
/var/home/user/.local/bin/podman: line 4: exec: flatpak-spawn: not found

물론 ~/.local/bin 가 호스트 및 컨테이너의 PATH에 있으므로 host-runner는 호스트에서 host-runner를 실행한 ~/.local/bin ..에서 podman 심볼릭 링크를 실행했지만 flatpak-spawn은 실행되지 않았습니다. 거기에 설치되지 않았습니다. 다음과 같은 경우 중첩 재귀가 발생했을 것이라고 감히 생각하지 않습니다.wink:

어쨌든 변경하여 해결했습니다.

executable=$(basename $0) 에서 executable=/usr/bin/$(basename $0) 까지는 현재로서는 충분합니다.

편집 : 이것은 몇 가지 다른 문제를 일으킵니다. 예를 들어 호스트에서 ~/.local/bin/podman 를 호출하려고 하면 호스트의 toolbox 가 더 이상 작동하지 않습니다. 현재 내 솔루션은 도구 상자 컨테이너의 PATH에만 추가하는 별도의 bin 경로를 갖는 것입니다.

flatpak-spawn --host 를 사용하는 것은 멋진 트릭입니다! 다음은 ~/.local/bin 에서 작동하고 실수로 명령을 직접 실행하는 경우 무한 루프를 방지하는 순수한 sh* 버전입니다.

#!/bin/sh
set -o errexit
set -o nounset

executable="$(basename "$0")"

if [ "$(basename "$(realpath "$0")")" = "${executable}" ]; then
  echo "can't run ${executable} via ${executable}" >&2
  exit 1
fi

# This seems like the best way to detect if we're inside a toolbox container.
if [ -n "${TOOLBOX_PATH:-}" ]; then
  set -x
  exec flatpak-spawn --host "${executable}" "$@"
fi

# Otherwise do a little dance to find the executable that would have run if not
# for $0 being on the path, and run that instead.
executable="$(
  # Remove this script's directory from PATH; this assumes that you'll never want
  # to run a sibling via this script.
  dir="$(dirname "$0")"
  PATH="$(echo "${PATH}" | sed "s+:${dir}:++")"
  PATH="$(echo "${PATH}" | sed "s+${dir}:++")"
  PATH="$(echo "${PATH}" | sed "s+:${dir}++")"
  command -v "${executable}"
)"

exec "${executable}" "$@"

(이것은 작동해야한다고 생각하지만 이상한 중첩 실행 사례에서 이것을 테스트하지 않았습니다.)

* realpath 을 사용할 수 있다고 가정

또 다른 옵션은 컨테이너 내의 podman이 항상 --remote 입니다. API 서버용 소켓은 도구 상자 컨테이너 내에서 보이는 것으로 보입니다.