🌍

bc2_1.1. title: 연산자원 이용량을 잘 제한하고(cgroup), 파일시스템과 네트워크 인터페이스 등 시스템 자원까지 잘 분할하면(Namespace), 컨테이너 런타임을 구현할 수 있다. 즉, 컨테이너 런타임의 본질은 cgroup 과 Namespace 의 합이다.

파일시스템(from1) 접근을 적절히 제어하고(1979년 발표된 프로그램 chroot 에서 근본을 찾을 수 있다)(참고1,참고10), 연산자원의 사용량(참고5,참고12:도커에서 자원을 제한하는 예) 프로세스마다 잘 제한하고(2006년 발표된 프로그램 cgroup 이 이 기술의 근본이다)(참고2), chroot 의 파일시스템 접근 제어에 더해 네트워크 인터페이스 등(참고6) 시스템 자원까지 잘 분할(참고4:Namespace은 chroot 기능을 모두 포괄한다고 볼 수 있다)하면(2002년 발표된 프로그램 Namespace 이 이 기술의 근본이다)(참고11), 컨테이너 런타임을 구현할 수 있다(참고9).
기술 또는 개념
기능
근본
container
환경 격리
cgroup, namespace
cgroup (2006, Google)
연산 자원(CPU, RAM 등) 이용 제어
namespace (2002(참고11))
시스템 자원의 분할
Plan 9(sup3), chroot
컨테이너 기술은 가상화 기술(from3)과 함께 항상 언급된다. 컨테이너 기술의 핵심인 컨테이너 런타임의 본질(from2)은 cgroup 과 Namespace 의 합이다. 실제로 2008년 발표된 최초의 컨테이너 엔진 LXC(LinuX Containers)(참고7:LXC는 컨테이너 엔진)의 컨테이너 런타임은 OCI(Open Container Initiative)의 표준을 준수하는 RunC 컨테이너 런타임을 기반으로 구현되어 있고(참고7), RunC는 cgroup 과 Namespace 를 이용해 구현되어 있다(참고3).
parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료들.
1.
None
from : 과거의 어떤 생각이 이 생각을 만들었는가?
1.
2.
3.
supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는가?
3.
opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는가?
1.
None
to : 이 문서에 작성된 생각이 어떤 생각으로 발전되고 이어지는가?
2.
참고 : 레퍼런스
9.
10.