[Docker] 도커 시작하며 사전 조사했던 내용

리눅스, 윈도우, macos 지원

컨테이너 격리 기술

https://www.youtube.com/watch?v=uE2MTTTG8uc&t=16s

9:59초

리눅스의 네임 스페이스와 cgroups와 같은 커널 기능을 사용하여 가상화

• macos는 unix 계열이라 가능하다 치더라도 그럼 윈도우는 어떻게 격리가 가능한거지??

네임스페이스

• 각 프로세스가 파일시스템 마운트, 네트워크, 유저(uid), 호스트 네임(uts)등에 대해 시스템에 독립 뷰를 제공

컨트롤그룹

• 프로세스로 소비할 수 있는 리소스 양(cpu, memory, i/o, 네트워크 대역대, device 노드 등)을 제한

---

container 격리 기술 발전 과정

container 발전 1 (PYRASIS 중간쯤)

• chroot jail
  • chroot라는 명령어로 파일시스템에서 루트 디렉터리를 변경할 수 있음
  • 디렉터리를 격리하기 때문에 서버 정보 유출과 피해를 최소화 하는데 주로 사용됨
  • 실행 파일과 공유 라이브러리를 직접 준비해야 하고 설정 방법이 복잡.
  • 완벽한 가상 환경이 아니기 때문에 각종 제약이 많음
    • 프로세스가 액세스 할 수 있는 디렉터리를 제한하거나 시스템 라이브러리와 관련된 라이브러리를 로드할 수 있음
    • 파일이나 디렉터리에 대한 엑세스 권한만 제어할 분 네트워크 및 프로세스 등을 컨트롤 할 수 없음 (단점)
• LXC(LinuX Container)
  • 리눅스 커널의 cgoups, namespaces를 사용한 격리(isolate)된 가상공간 제공
  • cgroups (Control Groups) : CPU, 메모리, 디스크, 네트워크 자원을 할당
  • namespaces (Namespace isolation) : 프로세스 트리, 사용자 계정, 파일시스템, IPC등을 격리시켜 호스트와 별개의 공간을 만듬
• Docker
  • LXC는 격리된 공간만 제공할 뿐 개발 및 서버 운영에 필요한 부가 기능 부족
  • cgroups, namespaces를 기반으로 이미지, 컨테이너 생성 및 관리 기능과 다양한 부기 기능 제공
  • LXC기반으로 구현을 하였지만 Docker v0.9 부터 LXC를 대신하는 libcontainer를 개발하여 사용
  • 실행 드라이버(exec driver)라 불리는 lxc(LXC), native(libcontainer)는 실행 옵션에 따라 LXC, libcontainer 선택가능

container 발전 2 (opennaru 년도별로 container 기술요약되어 있음 - 추천)

• 1979년 chroot (change root) 발표
  • chroot라는 명령어로 파일 시스템에서 루트 디렉터리를 변경할 수 있음
  • 디렉터리를 격리하기 때문에 서버 정보 유출과 피해를 최소화 하는데 주로 사용됨
  • 프로세스가 액세스 할 수 있는 디렉터리를 제한하거나 시스템 라이브러리와 관련된 라이브러리를 로드할 수 있음
  • 파일이나 디렉터리에 대한 엑세스 권한만 제어할 분 네트워크 및 프로세스 등을 컨트롤 할 수 없음 (단점)
• 2000년 FreedBSD Jail
  • Unix OS인 FreeBSD에서 OS가상화 기능인 FreeBSD Jail 발표
  • chroot와 달리 호스트 OS와 Jail 이라는 OS 가상화 환경에서 파일 시스템, 프로세스, 네트워크를 분리할 수 있는 기술 제공
  • 이것이 컨테이너의 시작
  • Jail을 통해 사용자 별로 환경을 분리하여 안전성을 확보하며 임대 서버나 호스팅 등의 서비스에 활용됨
• 2001년 Linux-Vserver
  • Linux에도 커널에 Linux-Vserver 라는 기능을 추가하여 OS 가상화 환경을 이용할 수 있게됨
  • 이 후 2004년 상용 Unix OS인 Solaris 에서도 Solaris Zone 이라는 OS 가상화 기능 제공
• 2006년 Process Containers
  • Google은 Process Containers라는 프로세스 자원 이용량을 제어하는 기능을 발표
  • 이듬해 이 기능은 **cgroup (controll groups)**으로 이름이 변경됨
• 2008년 RedHat에서 논리적으로 시스템 자원을 분할하는 Namespace를 발표
  • 비슷한 시기에 IBM에서 LXC(Linux Containers)를 발표
  • LXC가 cgroups, Namespace를 사용하여 구현한 초최의 Linux 컨테이너 엔진
  • LXC는 이후 컨테이너 엔진 형태를 갖추며 현재 컨테이너 기술의 시초역할
  • Sun Microsystems (현재 Oracle)의 UNIX OS인 Solaris 10에 탐재 된 Zone 이라는 기능에 의해 처음으로 구현됨
  • 이 기술은 Parallels의 "Parallels Virtuozzo Containers"라는 형태로 x86용 Linux와 Windows로 전파됨
  • 현재 OpenVZ라는 Linux용 오픈 소스 버전으로 오픈소스 소프트웨어 (FLOSS)커뮤니티에 의해 개발중
  • 컨테이너화 기술은 오픈소스 소프트웨어로 LXC(Linux Containers)와 Docker를 기반으로 함

물음?

• cgroup, namespace 확인하는 방법은?
• native로 실행할 때에도 cgroup, namespace는 여전히 사용되는가?
• 사용중인 실행드라이버의 확인은? (lxc or native)
• lxc, native 차이점은?
• lxc, native 선택 방법은?

RunC

container-shim

containerd

rkt = dockerd없이 linux의 systemd를 통해 container를 관리한다.

여러 컨테이너 종류가 있는데 이 규격이 OCI

docker, rkt 등 여러 방식으로 container를 실행할 수 있다

• 그러면 이미지는 각각 다르고 컨테이너만 동일하다는 뜻인가? 호환성은?

---

Docker 이미지와 컨테이너

이미지와 컨테이너 개념

• 이미지 = 실행파일
• 컨테이너 = 프로세스

이미지는

• 베이스 이미지와 개발자가 만든 어플리케이션 파일의 조합으로 구성
  • 베이스 이미지 : 리눅스 배포판 + 최소 실행 파일들 (유저랜드만 설치된 파일)
    • 마치 아무것도 설치되지 않은 비어있는 OS
  • 어플리케이션 : 리눅스에서 실행시킬 프로그램
• 생성된 이미지는 읽기전용 상태 입니다
  • 이미지는 언제 사용 되더라도 항상 동일한 내용을 포함해야 합니다.
  • 변경사항이 생기면 이미지를 수정하지 않고, 쓰기 이미지를 생성하여 내용을 기록합니다.
    • 이러한 방식을 Union mount라고 하며
    • 이를 지원하는 파일시스템을 Union File System 이라고 합니다.

유저랜드 설명링크

• 보통 리눅스 배포판에서 유저랜드는 부팅에 필요한 실행 파일과 라이브러리 그리고 고유의 패키징 시스템을 뜻함
  • OS는 메모리 사용을 기준으로 커널공간, 유저공간 으로 나눌 수 있음
  • 유저공간에서 실행되는 실행파일과 라이브러리를 유저랜드라 함
  • 리눅스는 커널만으로 부팅할 수 없음
  • 부팅에 필요한 최소 실행파일과 라이브러리 조합을 뜻하기도 함

Docker Image Layer

• Docker Image는 16진수로 된 ID로 구분되고, 각 이미지는 독립적
• 베이스 이미지에 A에 필요한 프로그램 설치한 뒤 이미지를 생성하면 myimage:1 이미지가 생성됨
  • layer 0 베이스 이미지
  • layer 1 설치한 프로그램
• 설치한 프로그램에 변경사항이 있어 다시 빌드 하면 myimage:2 이미지가 생성됩니다.
  • layer0의 베이스 이미지는 재사용
  • layer 1 부분이 새로 포함됨

[출처] pyrasis.com

 

 

컨테이너는

• 이미지를 실행 시킨 상태
• 하나의 이미지로 여러 컨테이너 실행 가능
• 이미 실행된 컨테이너에서 변경된 부분을 이미지로 생성할 수 있음

패키지???

리눅스/유닉스 계열은 파일 실행에 필요한 모든 구성요소가 잘게 쪼개어져 있습니다.

시스템 구조가 단순해지고 명확해지는 장점이 있지만

의존성 관계를 해결하기가 어려워지는 단점이 있습니다.

그래서 리눅스 배포판 별로 미리 컴파일된 패키지 (rpm, deb 등)라는 시스템이 나왔습니다.

하지만 서버를 실행할 때마다 일일이 소스를 컴파일 하거나 패키지를 설치하고, 설정하려면 상당히 귀찮습니다.

Docker 이미지를 사용하면 실행할 서버가 몇 개가 되든 손쉽게 해결할 수 있습니다.

패키지

• Debian 계열 (Debian, Ubuntu 등) : .deb 파일
• RedHat 계열 (RedHat, Fedora, CentOS) : .rpm 파일
• openSUSE 계열 : openSUSE를 위해 특별히 빌드된 .rpm 파일

ubuntu 에서는 /var/cache/apt/archives 디렉터리에 다양한 .deb 파일들이 보관되어 있습니다.

이러한 패키지를 관리하기 위해선 패키지 관리 도구를 사용하는데, 일반적으로 다음 두 유형의 패키지 관리 도구가 사용됩니다.

1. 저수준 툴 (low0level tools) : 실제 패키지의 설치, 업데이트, 삭제 등을 수행
2. 고수준 툴 (high-level tools) : 의존성의 해결, 패키지 검색 등의 기능을 제공

Debian and derivatives	dpkg	apt-get /aptitude
CentOS	rpm	yum
openSUSE	rpm	zypper

이중 Debian을 예로 들여다 보면

• dpkg
  • Debian 기반의 리눅스에서 사용되는 저수준 패키지 관리자 (low-level package manager)
  • .dev 패키지의 설치와 삭제 기능
  • 패키지를 자동으로 다운로드 하거나 의존성을 해결해 주지 않음
• apt-get / apt-cache / apt
  • Debian 기반의 리눅스에서 사용되는 고수준 패키지 관리자 (high-level package manager)
  • 패키지를 검색, 다운로드, 설치, 의존성 해결
  • 최근 Debian 기반의 리눅스 배포판에는 apt-get과 apt-cache 기능을 통합한 apt 명령이 설치되어 있음
• aptitude
  • Debian 기반 리눅스의 또 다른 high-level package manager
  • apt-get 보다 좀 더 개선된 기능을 제공

물음?

• 나중에 docker image 최적화(크기를 최소화 하는) 작업이 필요하게 되면 low-level package manager를 사용해야 할 수 있겠네
• low-level package manager를 통한 Docker Image만들기도 해볼만 할 듯