컨테이너의 세 가지 작업

저는 브라이언 홀트가 Frontend Masters의 용기에 대한 소개(이것은 paid, recorded workshop으로 구독할 만하지만 course notes are available free online)를 보고 공유해야 한다고 생각하는 용기를 알고 있습니다.
컨테이너는 다세입자 클라우드 환경을 위해 세 가지 중요한 작업을 했다.

어떤 프로세스도 이웃의

파일 시스템에 접근할 수 없습니다

이웃이 실행 중인 프로세스를 보거나 제어할 수 없습니다.

어떠한 프로세스도 이웃

의 시스템 자원(CPU, 메모리 등)을 박탈할 수 없다
만약 당신이 나와 같은 전단 개발자라면, 용기가 가상 기기보다 낫다는 모호한 생각을 가지고 있을 뿐만 아니라, serverless functions run inside containers을 알고 있을 수도 있다.가상 시스템에서 운영 체제가 있으므로 컨테이너가 가상 시스템보다 가벼워지는 방법을 보여 주는 이미지도 볼 수 있습니다.

하지만 용기가 어떻게 만들어지는지 진정으로 생각해 본 적이 없을지도 몰라!브라이언은 세미나를 시작할 때 용기를 처음부터 만드는 방법을 보여 주었다. 이것은 바로 마술을 깨뜨렸고, 왜 Docker 같은 사람이 당신을 위해 모든 세부 사항을 처리하기를 원하는지 명확하게 설명했다.

용기를 선택한 이유

브라이언은 먼저 Why Containers을 구축하기 시작했다. 그리고 왜 용기가 배치된 미래와 구름의 미래인지 은밀하게 말했다. (당신들 중 많은 사람들에게 용기는 이미 존재하고 지루하지만 미래의 분포는 고르지 않다는 것을 기억하세요!)
여기서 이해해야 할 주요 일은 우리가 (더 중요한 것은 공공 클라우드 공급업체) 여러 응용 프로그램(임차인)이 같은 기계를 공유하고 가능한 한 경제적이고 효율적으로 하기를 바라는 것이다. 이것은 우리가 기술하고자 하는 세 가지 업무의 필수 조건이다.
호스트 운영 체제에서 각 가상 시스템이 하나의 운영 체제를 실행하기 때문에 VM을 관리하는 데 비용이 많이 듭니다.따라서 우리는 이러한 응용 프로그램이 같은 운영체제에서 실행되고 안전성과 자원 격리를 동시에 가지기를 바란다.악의적인 공격자가 이웃을 엿보는 것을 방지하기 위해서일 뿐만 아니라, 다른 사람이 작성한 오류의 무한 순환에 저항하여 기계를 삼키거나 붕괴시키고 이웃의 응용 프로그램을 파괴하기 위해서이기도 하다.

예상 결과

여기에 우리가 원하는 세 가지 속성이 있습니다.

어떤 프로세스도 이웃의

파일 시스템에 접근할 수 없습니다

이웃이 실행 중인 프로세스를 보거나 제어할 수 없습니다.

어떠한 프로세스도 이웃

의 시스템 자원(CPU, 메모리 등)을 박탈할 수 없다
더 많지만, 이것들은 우리가 토론할 3대 문제이다.

작업 1: 파일 시스템 격리

No process should be able to access the filesystem of its neighbor

이곳의 해커는 the Linux chroot command을 사용한다.이것은 현재 실행 중인 프로세스의 루트 디렉터리를 제한하는 신기한 명령이기 때문에 이 범위를 초과할 수 없습니다.

mkdir my-new-root
sudo chroot my-new-root pwd
# chroot: pwd: No such file or directory

보시다시피 이것은 실행 명령처럼 간단하지 않습니다. - 일반적인 루트 경로에 있는 모든 표준 라이브러리를 복사해야 합니다. 예를 들어 ls과 bash을 복사해야 합니다. 그렇지 않으면 사용할 수 없습니다!(notes for how 참조)
이 라이브러리를 설치하려면 debootstrap을 사용하여 Debian base 시스템을 다른 설치된 시스템의 하위 디렉토리에 설치할 수 있습니다.

apt-get update -y
apt-get install debootstrap -y
debootstrap --variant=minbase bionic my-new-root


mkdir my-new-root
sudo chroot my-new-root pwd 
/           # now pwd works!

작업 2: 실행 중인 프로세스 격리

No process should be able to see or control the processes its neighbor is running

프로세스는 다른 상관없는 프로세스에 대한 통제 능력이 놀랍다.ps은 시스템에서 실행되는 다른 프로세스를 볼 수 있으며 다음 프로세스를 모두 볼 수 있습니다.

$ ps

  PID TTY           TIME CMD
16448 ttys000    0:02.56 zsh -l
57031 ttys000    0:00.19 MY_SUPER_SECRET_RUNTIME
47986 ttys003    1:38.59 /bin/zsh --login

$ kill 57031

# MY_SUPER_SECRET_RUNTIME killed

우리는 분명히 이렇게 할 수 없다.이 문제를 해결하는 데 도움을 주기 위해 2002년에 도입된 Namespaces을 입력하십시오.kill을 사용하여 이름 공간을 만들고 지정한 로고를 사용하여 unshareed 환경마다 잠길 수 있는 내용을 제어합니다.

unshare --mount --uts --ipc --net --pid --fork --user --map-root-user chroot /better-root bash # this also chroot's for us

7 kinds of namespaces명:

설치 지점(Mount)

프로세스 ID(-pid)

네트워크(-net): 모든 이름 공간에는 전용 IP 주소, 자신의 루트 테이블, 플러그인 목록, 연결 추적표, 방화벽과 다른 네트워크 관련 자원이 있습니다.

프로세스 간 통신(-ipc): 이것은 서로 다른 ipc 이름 공간에서의 프로세스 사용을 막을 수 있습니다(예를 들어) SHM 함수족이 두 프로세스 간에 일련의 공유 메모리를 만들 수 있습니다.

UTS(-UTS): UTS 네임스페이스는 하나의 시스템이 서로 다른 프로세스에 대해 서로 다른 호스트 이름과 도메인 이름을 표시할 수 있도록 합니다.

사용자 ID(-User): 관리 권한이 있는 것처럼 보이는 컨테이너를 구축하고 사용자 프로세스에 향상된 권한을 부여하지 않음

Control Group: 이거 업데이트된 것 같아요.

이것은 공격자를 방어하기 위해서이자 우리 자신을 보호하기 위해서이다.

작업 3: 시스템 리소스 격리

No process should be able to deprive system resources (CPU, memory, etc) from its neighbor

모든 고립된 환경은 서버의 모든 물리적 자원에 접근할 수 있다. 주로 CPU와 메모리이지만, 저장과 네트워크 접근과 같은 다른 것들에도 접근할 수 있다.구글 엔지니어는 2006년 control groups (cgroups)을 제기하여 자원을 각자의 절차에 격리시켰다.

# outside of unshare'd environment get the tools we'll need here
apt-get install -y cgroup-tools htop

# create new cgroups
cgcreate -g cpu,memory,blkio,devices,freezer:/sandbox

# add our unshare'd env to our cgroup
ps aux # grab the bash PID that's right after the unshare one
cgclassify -g cpu,memory,blkio,devices,freezer:sandbox <PID>

# Limit usage at 5% for a multi core system
cgset -r cpu.cfs_period_us=100000 -r cpu.cfs_quota_us=$[ 5000 * $(getconf _NPROCESSORS_ONLN) ] sandbox

# Set a limit of 80M
cgset -r memory.limit_in_bytes=80M sandbox

마찬가지로 notes on cgroups에서 더 많은 내용을 읽을 수 있습니다.

결론

용기의 유일한 일이 아닐 수도 있습니다. 브라이언이 강조한 3가지 작업일 뿐입니다. 저는 통찰력이 충분하고 여러분과 공유할 수 있다고 생각합니다.
나는 본래 이런 시스템을 그리려고 했지만, 내가 잘 그릴 줄은 생각지도 못했다. 그래서 여기에 의미 있는 도표가 있다.


물론 유사한 정보를 더 알고 싶으면 Brian Holt's Intro to Containers on Frontend Masters을 보십시오!
일단 approach technology from First Principles을 배우면 지속적인 지식을 배울 수 있고 다른 장면에서 다시 응용할 수 있으며 표면적으로 다른 사람의 생각을 보지 않고 자신의 비판적 분석 기술을 평가하는 능력을 얻을 수 있다.

부록: 폭죽과 소형 비행기

최근의 발전은 VM과 용기 사이의 경계를 모호하게 한다.Firecracker from AWS is regarded은 microVM 솔루션으로서

Until now, you needed to choose between containers with fast startup times and high density, or VMs with strong hardware-virtualization-based security and workload isolation. With Firecracker, you no longer have to choose. Firecracker enables you to deploy workloads in lightweight virtual machines, called microVMs, which provide enhanced security and workload isolation over traditional VMs, while enabling the speed and resource efficiency of containers.

폭죽에는 a paper writeup이 동봉되어 있으며, 다음은 a more digestible breakdown입니다.

At the core of Firecracker therefore is a new VMM that uses the Linux Kernel’s KVM infrastructure to provide minimal virtual machines (MicroVMs), that support modern Linux hosts, and Linux and OSv guests. It’s about 50kloc of Rust – i.e. a significantly smaller code footprint, and in a safe language. Wherever possible Firecracker makes use of components already built into Linux (e.g. for block IO, process scheduling and memory management, and the TUN/TAP virtual network interfaces). By targeting container and serverless workloads, Firecracker needs to support only a limited number of emulated devices, many less than QEMU (e.g. , no support for USB, video, and audio devices). virtio is used for network and block devices. Firecracker devices offer built-in rate limiters sufficient for AWS’ needs, although still considerably less flexible than Linux cgroups.

한층 더 읽다

https://www.docker.com/blog/intro-guide-to-dockerfile-best-practices/