Docker는 이상하다

컨테이너는 별도의 가상 머신이 아니라 제약을 적용한 프로세스이며, 호스트 커널이 실행하고 /proc에서도 찾을 수 있음 Linux에는 컨테이너라는 단일 기능이 없으며, 네임스페이스와 cgroups, 네트워크 격리 등 여러 커널 기능을 조합해 구현함 이미지는 폴더이며, Docker는 chroot 또는 pivot_root로 해당 폴더를 컨테이너 프로세스의 새 루트 디렉터리로 삼음 Go로 작성한 runc 는 멀티스레드 런타임과 단일 스레드가 필요한 시스템 호출 사이의 충돌을 우회하며, C 모듈과 자기 실행 파일 재실행을 사용함 Docker 데몬은 커널 API의 권한 요구 때문에 보통 root로 실행되며, rootless 환경에서는 특히 네트워크 기능을 구현하는 데 제약이 남아 있는 것으로 보임 컨테이너와 이미지의 실체 재미로 컨테이너 런타임을 직접 만들기 시작하면서 Docker의 작동 방식을 살펴봄 컨테이너는 VM과 달리 특별한 제약이 걸린 프로세스임 호스트 커널이 그 프로세스를 실행하며, 위치를 알면 /proc에서도 확인할 수 있음 Linux에 ‘컨테이너’라는 단일 기능은 없으며, 서로 다른 커널 기능 다섯 가지를 한데 묶은 것과 같음 네임스페이스는 호스트와 컨테이너가 볼 수 있는 대상을 제한함 cgroups는 컨테이너의 자원 사용량을 제한함 네트워크 격리에도 여러 기능이 쓰이지만, 직접 구현을 막 시작한 단계라 그 작동 방식은 아직 이해하지 못한 상태임 이미지는 폴더이며, Docker는 이를 특정 위치에 놓고 chroot 또는 pivot_root를 호출해 프로세스의 새 루트 디렉터리로 만듦 docker run -it --rm ubuntu /bin/bash를 실행하면 Docker Hub에서 Ubuntu 이미지를 내려받고, 특정 위치에 배치한 뒤 /some/weird/docker/path/bin/bash를 실행하는 흐름임 Go 런타임의 우회 구현과 root 권한 Docker의 컨테이너 런타임 runc는 Go로 작성됐지만, Go의 설계에는 컨테이너 런타임 구현을 어렵게 만드는 부분이 있음 Go 런타임은 기본적으로 멀티스레드인 반면, 컨테이너 런타임에 필요한 여러 Linux 시스템 호출은 단일 스레드 환경에서 수행해야 함 이를 위해 nsenter C 모듈이 Go 런타임 초기화 전에 실행되어 해당 시스템 호출을 처리함 Go에는 fork가 없으며, 메인 스레드만 복제하는 fork는 Go 같은 런타임에서 실수를 유발하기 쉬움...