Docker 컨테이너 내부의 프로세스는 어떻게 생겼습니까?

Docker 컨테이너가 무엇인지, 특히 Docker 컨테이너 내부에서 호출하는 명령 및 프로세스와 관련하여 Docker 컨테이너가 무엇인지 특히 혼란스러워하는 것을 들었습니다.

누군가 무슨 일이 일어나고 있는지에 대한 높은 수준의 개요를 제공 할 수 있습니까?

Docker는 사람들이 어떻게 든 하드웨어를 가상화한다고 가정하기 때문에 가상화 버킷에 던져집니다. 이것은 Docker가 주로 사용하는 용어, 주로 컨테이너라는 용어에서 스며드는 잘못된 이름입니다.

그러나 Docker는 시스템 하드웨어 가상화와 관련하여 마술적인 일을하지 않습니다. 오히려 리눅스 커널의 주요 기능을 중심으로 "울타리"를 구축하는 능력을 이용하여 프로세스가 네트워크, 파일 시스템 및 권한과 같은 리소스와 상호 작용하여 상호 작용하고 있다는 착각을 줄 수 있습니다. 모든 기능을 갖춘 시스템.

다음은 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는 실제로 가상화되지 않고 ( 전통적인 의미에서 ) 다양한 커널 리소스 주위에 "울타리"를 구성하고 주어진 프로세스 + 하위 항목에 대한 가시성을 제한합니다.

용기 내부 에서 공정을 분리해야합니다 (검토). 실제로 어떤 프로세스도 볼 수 없지만 지정한 프로세스 (적어도 쉘)는 보이지 않습니다. "연결성"테스트 용이 아닙니다. chroot와의 유일한 유사점은 호스트 커널이 사용된다는 것입니다. Docker는 무언가를 분리하거나 호스트에서 실행되는 것과 다른 버전의 플랫폼 아키텍처 소프트웨어를 사용해야하는 경우 유용합니다. (이전 버전의 Java 또는 다른 Python 포크는 말합니다). 처리중인 폴더 및 이진이 호스트의 폴더 및 이진과 동일하지 않을 수 있다는 점에 유의하십시오. 같은 / bin 폴더 등이 아닙니다.

편집 : VM이 아닌 chroot와의 유사성.