나는 사용한다아키텍처Linux주요 운영 체제로 웹 애플리케이션을 개발합니다.센토스. 처음에는 LXC Container다음을 사용하여 Arch에서 실행했습니다.센토스, 그러나 Wi-Fi 등을 통한 네트워크 구성 문제로 인해 대안을 찾기로 결정했고 누군가 chrootdirect ing이 작동할 수 있다고 제안했습니다.
현재는 LXC명령을 사용하여센토스그리고 그냥 chroot뛰어들어 일하세요. 또한 /bind, /proc및 을 /sys설치했습니다 chroot. 내 웹 응용 프로그램은 문제 없이 잘 실행됩니다.
이 접근 방식에 문제/경고가 있습니까? 나는 이와 같은 고급 것을 시도한 적이 없습니다 Java JVM. 나는 그것이 호스트 시스템의 커널을 사용한다는 것을 알고 있으며 System CallsLinux에서 이전 버전과 호환되는 것으로 추측합니다(이것이 이 아이디어가 작동하는 이유입니다). 따라서 모든 것이 예상대로 원활하게 작동해야 합니다.
사용 문제가 발생할 수 있는 상황이 있는지 아직도 궁금합니다 chroot. chroot일반 시스템처럼 작동하지 않을 수 있는 시나리오가 있습니까 ? 논리적으로 커널이 이전 버전과 호환되는 한 아무것도 표시되지 않습니다. 내가 생각할 수 있는 한 곳은 호스트 시스템의 커널이 원래 커널과 다른 구현을 가지고 있고 일반적으로 가능성이 없는 버그가 있는 경우입니다.
내가 사용할 때아치, 전체적인 견해를 듣고 싶습니다. 내 주요 아이디어는 이것을 사용하지 않는 동료에게 추천하는 것입니다.센토스여러 가지 이유로 기본 운영 체제로 사용됩니다. 64비트 시스템 대신 32비트 시스템을 사용해야 하는 몇 가지 사용 사례가 있습니다. 그들 중 다수는 가상 머신 등을 설정하는 데 많은 시간을 소비하지만, Linux가 Linux를 "가상화"하는 데 이것이 정말로 필요한가요? 저는 개인적으로 chroot이것이 단순한 디버깅 도구 이상의 역할을 한다고 생각하지만, 전문가의 의견을 듣고 싶습니다.
답변1
Chroot는 컨테이너가 아니며 단지 파일 시스템의 보기를 변경합니다. 네트워크는 여전히 동일하고 장치도 동일하며 pid도 동일하고 uid도 동일하며 루트는 여전히 루트입니다.
이는 chroot 내에서 수행된 작업이 더 넓은 시스템에 영향을 미칠 수 있음을 의미합니다. chroot에서 데몬을 시작하고 포트에 바인딩하면 chroot뿐만 아니라 전체 시스템에서 해당 포트를 차지합니다. chroot 내부에서 killlall을 사용하는 경우(또는 스크립트) chroot 외부의 프로세스도 종료됩니다.
특히, chroot에 패키지를 설치/업그레이드하면 데몬이 의도치 않게 시작되거나 데몬을 시작할 수 없어 설치 프로세스가 실패할 수 있습니다. 잘못 작성된 스크립트는 chroot에서 버전을 시작하기 전에 호스트 시스템의 데몬을 종료하여 많은 혼란을 야기할 수도 있습니다. (나는 적어도 몇 년 전에 . 이메일이 아무데도 가지 않는 것 같았고 나는 결국 "로컬 메일 전용"으로 구성된 chroot에서 MTA에 의해 처리되고 있음을 발견했습니다.
일부 배포판에는 chroot 시작 데몬에서 패키지 설치를 중지하는 메커니즘이 있지만 세부 사항은 분명히 배포판에 따라 다릅니다.
답변2
chroot컨테이너가 아니며 프로세스를 시스템의 나머지 부분과 완전히 격리하지 않습니다. chroot 디렉터리에 마운트된 경우 /proc해당 chroot에서 시작된 프로세스는 chroot 외부에서 실행 중인 프로세스를 볼 수 있습니다.
즉, 괜찮으시다면 chroot설명하신 상황을 정확하게 처리하도록 설계되었습니다. 실제로 Debian이 다중 아키텍처 지원을 제공할 때까지 64비트 시스템에서 32비트 응용 프로그램을 실행하는 권장 방법은 32비트 chroot를 만들고 최소 32비트 Debian 기반을 설치하는 것입니다.