용기 안에 무엇이 있습니까?

안녕하세요
제가 Dev.to에 올린 첫 번째 댓글입니다.
이제 모든 사람이 CI/CD의 컨테이너화 솔루션을 사용하고 있습니다.
나는 항상 용기를 단독 프로세스/CPU/메모리로 호스트에서 실행하는 것이 무엇인지 알고 싶다.
다음은 나의 몇 가지 발견이다.

프로세스

컨테이너는 추가 구성된 일반 Linux 프로세스만 적용됩니다.아래의 Redis 용기를 시작하면 표지 아래에서 무슨 일이 일어났는지 볼 수 있습니다.

 docker run -d --name=db redis:alpine 

Docker 컨테이너에서 redis server라는 프로세스를 시작합니다.호스트에서 Docker가 시작한 프로세스를 포함하여 실행 중인 모든 프로세스를 볼 수 있습니다.

ps aux | grep redis-server

Docker는 다음과 같은 방법으로 PID(프로세스 ID) 및 PPID(부프로세스 ID) 등 프로세스에 대한 정보를 식별할 수 있습니다.

docker top db

PPID는 누구입니까?활용단어참조

ps aux | grep <ppid>

상위 프로세스를 찾습니다.컨테이너일 수도 있어요.
명령 pstree는 모든 하위 프로세스를 표시합니다.Docker 프로세스 트리 보기 사용

pstree -c -p -A $(pgrep dockerd)

보시다시피 Linux의 측면에서 볼 때, 이것은 표준 프로세스이며, 우리 시스템의 다른 프로세스와 같은 속성을 가지고 있습니다.

프로세스 디렉토리

Linux는 일련의 신기한 파일과 내용일 뿐, 표지 아래에서 일어나는 일을 탐색하고 탐색하여 재미있게 하고, 어떤 경우에는 내용을 바꾸어 결과를 볼 수 있다.
모든 프로세스의 설정은/proc 디렉터리에 정의됩니다.프로세스 ID를 알고 있으면 구성 디렉토리를 식별할 수 있습니다.
다음 명령은/proc의 모든 내용을 나열하고 나중에 사용할 수 있도록 Redis PID를 저장합니다.

DBPID=$(pgrep redis-server)
echo Redis is $DBPID
ls /proc

각 프로세스는 서로 다른 파일에서 자신의 설정과 안전 설정을 정의합니다.

ls /proc/$DBPID

예를 들어, 프로세스에 정의된 환경 변수를 보고 업데이트할 수 있습니다.

cat /proc/$DBPID/environ

docker exec -it db env

네임스페이스

용기의 기본 부분은 명칭 공간이다.이름 공간의 개념은 프로세스가 시스템의 일부 부분을 보고 접근할 수 있도록 제한하는 것이다. 예를 들어 다른 네트워크 인터페이스나 프로세스이다.
컨테이너가 시작되면 컨테이너가 실행될 때 (예: Docker) 샌드박스 프로세스를 위한 새 이름 공간이 생성됩니다.자신의 Pid 이름 공간에서 프로세스를 실행하면 시스템의 유일한 프로세스처럼 보입니다.
사용 가능한 네임스페이스는 다음과 같습니다.
설치(mnt)
프로세스 ID(pid)
네트워크(net)
프로세스 간 통신 (ipc)
UTS(호스트 이름)
사용자 ID(사용자)
대조 그룹(cgroup)
자세한 내용은 액세스 https://en.wikipedia.org/wiki/Linux_namespaces
Unshare에서 포함 프로세스를 시작할 수 있습니다.
Docker와 같은 실행을 사용하지 않을 때, 프로세스는 자신의 이름 공간에서 실행될 수 있습니다.유용한 도구는 unshare입니다.
공유 취소 -- 도움말
unshare를 사용하면 프로세스를 시작하고 Pid와 같은 새로운 이름 공간을 만들 수 있습니다.호스트에서 Pid 이름 공간 공유를 취소하면 bash 알림이 기계에서 실행되는 유일한 프로세스로 보입니다.

sudo unshare --fork --pid --mount-proc bash
ps
exit

우리가 명명 공간을 공유할 때 무슨 일이 일어날까요?
표지 아래에서 이름 공간은 디스크의 색인 노드 위치입니다.이것은 프로세스가 같은 이름 공간을 공유하고 다시 사용할 수 있도록 하며, 그것들이 보고 상호작용할 수 있도록 한다.
모든 이름 공간 나열

ls -lha /proc/$DBPID/ns/

다른 도구인 NSEnter는 기존 이름 공간에 프로세스를 첨부하는 데 사용됩니다.디버깅 목적에 사용됩니다.

nsenter --help

nsenter --target $DBPID --mount --uts --ipc --net --pid ps aux

Docker를 사용하여 다음 구문 컨테이너를 사용하여 이러한 네임스페이스를 공유할 수 있습니다.예를 들어, 다음 명령은 nginx를 DB 이름 공간에 연결합니다.

docker run -d --name=web --net=container:db nginx:alpine
WEBPID=$(pgrep nginx | tail -n1)
echo nginx is $WEBPID
cat /proc/$WEBPID/cgroup

네트워크가 공유되었지만 이름공간으로 나열됩니다.

ls -lha /proc/$WEBPID/ns/

그러나 두 프로세스의 네트워크 이름 공간은 같은 위치를 가리킨다.

ls -lha /proc/$WEBPID/ns/ | grep net 

ls -lha /proc/$DBPID/ns/ | grep net

Chroot 회사

컨테이너 프로세스의 중요한 부분 중 하나는 호스트와 독립된 다른 파일을 가질 수 있다는 것이다.이것이 바로 우리가 시스템에서 실행되는 서로 다른 운영체제에 따라 서로 다른 Docker 이미지를 가지고 있는 방법이다.
Chroot에서는 상위 운영 체제의 다른 루트 디렉토리에서 프로세스를 시작할 수 있습니다.이것은 루트 디렉터리에 다른 파일을 표시할 수 있도록 합니다.

C그룹(대조그룹)

cGroup은 프로세스가 소모할 수 있는 자원량을 제한합니다.이 cgroup들은/proc 디렉터리의 특정 파일에 정의된 값입니다.
맵을 보려면 명령을 실행합니다.

cat /proc/$DBPID/cgroup

이 디렉터리는 디스크의 다른 cgroup 디렉터리에 비칩니다.

ls /sys/fs/cgroup/

프로세스의 CPU 통계는 무엇입니까?
CPU 상태와 사용량도 하나의 파일에 저장됩니다!

cat /sys/fs/cgroup/cpu,cpuacct/docker/$DBID/cpuacct.stat

CPU 공유 제한도 정의되어 있습니다.

cat /sys/fs/cgroup/cpu,cpuacct/docker/$DBID/cpu.shares

컨테이너 메모리 구성의 모든 Docker cGroup은 다음과 같이 저장됩니다.

ls /sys/fs/cgroup/memory/docker/

각 디렉토리는 Docker가 할당한 컨테이너 ID에 따라 그룹화됩니다.

DBID=$(docker ps --no-trunc | grep 'db' | awk '{print $1}')
WEBID=$(docker ps --no-trunc | grep 'nginx' | awk '{print $1}')
ls /sys/fs/cgroup/memory/docker/$DBID

cGroup은 어떻게 구성합니까?
Docker의 특징 중 하나는 메모리 제한을 제어할 수 있다는 것입니다.이것은 cgroup 설정을 통해 완성된 것입니다.
기본적으로 용기는 메모리에 제한이 없습니다.우리는 dockerstats 명령을 통해 이 점을 볼 수 있다.

docker stats db --no-stream

메모리 따옴표는 메모리라는 파일에 저장됩니다._in_바이트를 제한합니다.
파일을 작성함으로써 프로세스의 제한을 변경할 수 있습니다.

echo 8000000 >/sys/fs/cgroup/memory/docker/$DBID/memory.limit_in_bytes

이 파일을 다시 읽으면 7999488로 변환되었음을 알 수 있습니다.

cat /sys/fs/cgroup/memory/docker/$DBID/memory.limit_in_bytes

Docker 통계를 다시 검사할 때 프로세스의 메모리 제한은 현재 7.629M-

docker stats db --no-stream

Seccomp/AppArmor 회사

Linux의 모든 작업은 시스템 호출을 통해 이루어집니다.커널에는 330개의 시스템 호출이 있어 파일 읽기, 핸들 닫기, 접근 권한 검사 등을 수행한다.모든 응용 프로그램은 이 시스템이 호출한 조합을 사용하여 필요한 작업을 수행합니다.
AppArmor는 프로그램이 정의한 프로필로 프로세스가 시스템에 접근할 수 있는 부분을 설명합니다.
다음 방법으로 프로세스에 할당된 현재 AppArmor 구성 파일을 볼 수 있습니다.

cat /proc/$DBPID/attr/current

Docker의 기본 AppArmor 구성 파일은 Docker default(강제)입니다.
Docker 1.13 이전에 AppArmor 구성 파일을/etc/AppArmor에 저장합니다.d/docker 기본값 (docker가 시작될 때 덮어쓰기 때문에 사용자가 수정할 수 없습니다. v1.13 이후, docker는 현재 tmpfs에서 docker 기본값을 생성합니다. apparmor\u 해상도를 사용하여 이 파일을 불러오고 삭제합니다.
템플릿 위치 https://github.com/moby/moby/blob/a575b0b1384b2ba89b79cbd7e770fbeb616758b3/profiles/apparmor/template.go
Seccomp는 내부 모듈을 설치하거나 파일 권한을 변경하지 못하도록 어떤 시스템을 호출할 수 있는지 제한하는 능력을 제공합니다.
https://github.com/moby/moby/blob/a575b0b1384b2ba89b79cbd7e770fbeb616758b3/profiles/seccomp/default.json에서 기본적으로 허용되는 Docker 호출을 찾을 수 있습니다.
프로세스에 분배될 때, 이것은 이 프로세스가 능력 시스템 호출의 서브집합으로 제한된다는 것을 의미한다.만약 그것이 막힌 시스템 호출을 호출하려고 시도한다면, 오류가 발생합니다.
SecComp 상태도 파일에 정의됩니다.

cat /proc/$DBPID/status

cat /proc/$DBPID/status | grep Seccomp

로고 의미: 0: 비활성화 1: 엄격 2: 필터링

능력

능력은 절차나 사용자가 무엇을 할 권리가 있는지에 대한 그룹이다.이러한 기능에는 시스템 시간 또는 호스트 이름 변경 등 여러 시스템 호출이나 작업이 포함될 수 있습니다.
상태 파일에는 능력 표시도 포함되어 있습니다.하나의 프로세스는 안전을 확보하기 위해 가능한 한 많은 기능을 포기할 수 있다.

cat /proc/$DBPID/status | grep ^Cap

로고는 비트 마스크로 저장되고capsh로 디코딩할 수 있습니다

capsh --decode=00000000a80425fb

네가 이 문장이 읽을 만하다고 생각하길 바란다.