최근에는 사람들이 Docker 컨테이너가 무엇인지, 더 구체적으로 말하면 Docker 컨테이너 내에서 호출하는 명령 및 프로세스와 관련하여 내부적으로 무슨 일이 일어나고 있는지에 대해 사람들이 혼란스러워한다는 말을 많이 들었습니다.
누군가 무슨 일이 일어나고 있는지에 대한 높은 수준의 개요를 제공할 수 있습니까?
답변1
Docker는 사람들이 Docker가 기본 하드웨어를 가상화했다고 생각했기 때문에 가상화 버킷에 포함되었습니다. 이는 Docker에서 사용하는 용어(주로 "컨테이너"라는 용어)에서 파생된 잘못된 이름입니다.
그러나 Docker는 시스템 하드웨어 가상화와 관련하여 마법 같은 작업을 수행하지 않습니다. 대신, 중요한 시설 주위에 "울타리"를 구축하는 Linux 커널의 기능을 활용하여 프로세스가 네트워킹, 파일 시스템 및 권한(무엇보다도)과 같은 리소스와 상호 작용할 수 있도록 하여 완전한 기능을 갖춘 시스템과 상호 작용하고 있다는 착각을 불러일으킵니다. .
아래 예에서는 Docker 컨테이너를 시작한 다음 /bin/bash.
$ docker run -it ubuntu:latest /bin/bash
root@c0c5c54062df:/#
이제 이 컨테이너 내부에서 다음을 실행하면 ps -eaf:
다른 터미널 탭으로 전환하면 Docker 컨테이너를 호스팅하는 호스트 시스템에 로그인하고 컨테이너가 "실제로" 차지하는 프로세스 공간을 볼 수 있습니다.
이제 Docker 탭으로 돌아가서 그 안에서 여러 프로세스를 시작하고 모두 백그라운드에 넣으면 원래 Docker 컨테이너로 시작되었던 기본 Bash 프로세스에서 실행되는 여러 하위 프로세스가 있음을 알 수 있습니다. .
노트:이 프로세스는 sleep 1000백그라운드에서 실행되는 4개의 명령입니다.
Docker 컨테이너 내에서 프로세스에 48-51의 프로세스 ID(PID)가 어떻게 할당되는지 확인하세요. ps -eaf출력에서도 볼 수 있습니다.
그러나 다음 이미지에서는 Docker가 수행하는 "마법"의 대부분이 드러납니다.
이 4개 sleep 1000프로세스는 실제로 원래 Bash 프로세스의 하위 프로세스인가요? 또한 원래 Docker 컨테이너는 /bin/bash실제로 Docker 데몬의 하위 프로세스라는 점에 유의하세요.
sleep 1000이제 원래 명령이 완료될 때까지 1000초 이상 기다린 후 4개의 새 명령을 실행하고 다음과 같이 다른 Docker 컨테이너를 시작하면:
$ docker run -it ubuntu:latest /bin/bash
root@450a3ce77d32:/#
호스트 시스템의 출력은 ps -eaf다음과 같습니다.
다른 Docker 컨테이너는 Docker 데몬 아래의 프로세스로만 표시됩니다.
보시다시피 Docker는 실제로 가상화가 아닙니다(전통적인 의미에서)은 다양한 커널 리소스 주위에 "울타리"를 구축하고 특정 프로세스 + 하위 프로세스의 가시성을 제한합니다.
답변2
~에컨테이너 내에서 프로세스는 격리(격리)되어야 합니다. 실제로 지정한 프로세스(적어도 셸) 외에는 어떤 프로세스도 표시되어서는 안 됩니다. "사회성" 테스트에는 적용되지 않습니다. chroot와 유일한 유사점은 호스트 커널을 사용한다는 것입니다. Docker는 무언가를 격리해야 하거나 호스트 시스템에서 실행되는 것과 다른 버전의 플랫폼 아키텍처 소프트웨어를 사용해야 하는 경우 유용합니다. (아주 오래된 Java 버전 또는 다른 Python 포크) 작업 중인 폴더 및 바이너리는 호스트 컴퓨터의 폴더 및 바이너리와 다를 수 있다는 점을 명심하십시오. 동일한 /bin 폴더 등이 아닙니다.
편집: VM 대신 chroot와 유사합니다.