원래는 그러고 싶었지만내 NAS에서 사용하는 Linux 배포판을 완전히 대체합니다., 동시에 기존 시스템을 최대한 수정하지 않고 기본적으로 Gentoo(또는 Arch) Linux로 보완하는 것이 더 낫다는 결론에 도달했습니다.이전 질문에 대한 제안된 답변. 따라서 현재 원본 시스템에 대한 유일한 수정 사항에는 다음 스크립트를 통해 입력한 /gentoo
디렉터리 가 포함됩니다.chroot
#!/bin/bash
set -e
cp -L /etc/resolv.conf etc/ # for internet access
cp -P /etc/localtime etc/ # to keep the timezones consistent
cp -d /etc/mtab etc/ # to check mounted systems
# cp /etc/{mdadm.conf,hosts,fstab} etc # Maybe?
mount --rbind /mnt mnt # use host's mounts
mkdir host; mount --bind / host
mount --bind /var/log var/log # or run own syslogd?
mount --bind /dev dev
mount -t devpts devpts dev/pts
mount --bind /proc proc # or mount -t procfs proc proc?
mount --bind /sys sys # or mount -t sysfs sysfs sys?
chroot . /usr/sbin/sshd -p 22222
# chroot . /bin/env -i TERM=$TERM /bin/bash
이제 ssh
포트 22222를 통해 간단히 호스트에 들어가서 chroot
기본적으로 Gentoo Linux처럼 동작하는 환경에 들어갈 수 있으며 호스트의 /etc/init.d/rcS
.
그러나 물론 나는 이 방법으로 수동으로 사용하고 싶은 모든 Gentoo 서비스를 시작하고 싶지 않습니다. 결국 이것이 OpenRC(또는 선호한다면 systemd)의 이점입니다. 그래서 내 주요 질문은
chroot
가능한 한 중단을 최소화하면서 호스트 Linux에서 Gentoo Linux를 올바르게 "부팅" 하려면 어떤 Gentoo 명령을 실행해야 합니까 ?
가능한 한 방해를 최소화한다는 것은 파일 시스템을 다시 마운트하려고 시도해서는 안 된다는 의미입니다(그러나 동시에 mount
Gentoo가 작동한다면 좋을 것입니다). 따라서 단순히 실행하는 것이 init
올바르지 않을 수도 있고 OpenRC 구성에 대한 일부 수정이 필요할 수도 있습니다. 필요하지만 어떤 것입니까?
또한, 호스트 데몬 문제도 있습니다. 이를 사용해야 할까요, 아니면 젠투가 자체 인스턴스를 실행하도록 해야 할까요( 호스트 인스턴스를 방해하지 않도록 어떻게 설정해야 할까요?), 아니면 한 단계 더 나아가야 할까요 crond
? syslogd
젠투를 완전히 가상화하시겠습니까? 상술 한 바와 같이다른 질문에젠투 인스턴스가 자체 IP를 갖고 어느 정도 독립형 시스템처럼 동작하면 좋겠지만, 반면에 시스템 리소스가 제한되어 있기 때문에 오버헤드가 최대한 적으면 좋겠습니다. 호스트 시스템은 다음 데몬과 지금까지의 내 생각을 실행하고 있습니다.
Daemon | Use Gentoo's own?
-----------------+---------------------------------------------------------------
udevd | N bind-mount /dev
klogd, k* | N using host kernel (although UML might be interesting...)
dhcpd, inetd | ? depends on using own IP or not
syslogd | ? bind-mount /var/log or use Gentoo's more versatile settings?
mdadm --monitor | ? should Gentoo bother with the RAID configuration?
smbd, nmbd | ? disable host's samba in favour of Gentoo's one? maybe with a
| maintenance-only share on the host
crond | Y to minimize interference with host's maintenance scripts
sshd | Y to directly SSH into the chrooted Gentoo system
daemonwatch | ? maybe use host instance to watch Gentoo instance?
logchkd, errormon| ? unknown
마지막으로, 종료/다시 시작 시 무엇을 고려해야 하는지 궁금합니다. 단순히 호스트의 종료 스크립트가 chroot /gentoo /bin/init shutdown
자체 시퀀스 전에 실행되도록 할 수 있습니까? 아니면 이로 인해 Gentoo의 전원이 꺼지게 됩니까?앞으로호스트의 실제 종료 순서는 무엇입니까?
답변1
chroot에서 서비스를 실행하려는 경우: 실제로 chroot의 용도는 아닙니다.
Gentoo 시스템을 한 곳에 격리하는 것이 좋습니다.루스트어바웃컨테이너.
새로운 chroot를 생성하여 Docker 이미지를 쉽게 생성할 수 있습니다.기본 이미지에서:
tar --numeric-owner -cf- /gentoo | docker import - gentoo:base
그 다음에적절한 Docker 이미지 빌드그 위에 이걸 써보세요도커파일:
FROM gentoo:base
EXPOSE 22 # make SSH accessible, repeat for any port you're running a service on in this container
ENTRYPOINT ["/usr/lib/systemd/systemd"]
이 명령을 사용하여 다음을 기반으로 적절한 컨테이너를 빌드하십시오.도커파일(이것도커파일이 명령이 실행되는 디렉터리와 동일한 디렉터리에 있어야 하며 이름을 지정해야 합니다.도커파일):
docker build -t gentoo:latest .
이제 다음 명령을 사용하여 이 컨테이너를 시작할 수 있습니다.
GENTOO_CONTAINER=$(docker run -d gentoo:base)
이제 를 사용하면 docker inspect ${GENTOO_CONTAINER}
컨테이너의 모든 세부 정보(IP, 컨테이너 내부에서 실행되는 서비스를 외부에 노출하는 데 사용되는 포트 등)를 볼 수 있습니다.
를 사용하면 docker ps
현재 실행 중인 컨테이너를 볼 수 있습니다.
docker ps -a
현재 실행 중인 컨테이너를 포함하여 지금까지 실행된 모든 컨테이너를 볼 수 있습니다 .
또한 다음을 수행하십시오.도커 튜토리얼이해하는데 정말 도움이 되네요루스트어바웃기초적인.