아래 링크의 해당 내용을 정리한 내용임을 밝힙니다.
https://www.44bits.io/ko/keyword/linux-container
컨테이너란? 리눅스의 프로세스 격리 기능
리눅스 컨테이너는 운영체제 수준의 가상화 기술로 리눅스 커널을 공유하면서 프로세스를 격리된 환경에서 실행하는 기술을 의미합니다. 하드웨어를 가상화하는 가상 머신과 달리 커널을 공유
www.44bits.io
1. 리눅스 컨테이너란?
리눅스 컨테이너는 운영체제 수준의 가상화 기술, 리눅스 커널을 공유하면서 프로세스를 격리된 환경에서 실행하는 기술입니다.
하드웨어를 가상화 하는 가상 머신과 달리 커널을 공유하는 방식이기 때문에 실행 속도가 빠르고, 성능 상의 손실이 거의 없습니다.
컨테이너로 실행된 프로세스는 커널을 공유하지만 커널 기능을 활용해 격리되어 실행됩니다.
이러한 격리 기술 덕분에 호스트 머신에게는 프로세스로 인식되지만, 컨테이너 관점에서는 독립적인 환경을 가진 가상 머신처럼 보입니다.
위의 내용을 보다 쉽게 설명하기 위해 아래의 회사 조직도를 통해 설명하겠습니다.
커널은 하드웨어와 소프트웨어를 연결하고, 운영 체제의 핵심이 되어 시스템의 모든 것을 통제하는 역할을 담당합니다.
하드웨어가 사장의 역할이라면, 커널은 아래에서 부사장의 역할을 담당하게 됩니다.
그럼 컨테이너의 경우에는 어떻게 될까요? 컨테이너의 경우에는 각 부서가 됩니다. 컨테이너가 독립적인 환경을 갖고 실행되듯, 각 부서 역시 독자적으로 운영되는 것과 유사합니다. 하지만 각 부서는 사장이 보기에는 하나의 회사와 같듯, 호스트 머신에게는 프로세스로 인식 됩니다.
즉, 회사로 정리하게 되면 다음과 유사합니다.
사장 : 하드웨어
부사장 : 커널
각각의 부서 : 각각의 컨테이너
- 컨테이너의 주요 특징
리눅스 컨테이너의 주요한 특징들은 다음과 같습니다.
1. 운영체제 수준의 가상화 : 컨테이너는 운영체제 수준의 가상화 기술입니다. 별도의 하드웨어 에뮬레이션 없이 리눅스 커널을 공유해 컨테이너를 실행하며, 게스트OS 관리가 필요하지 않습니다.
2. 빠른 속도와 효율성 : 하드웨어 에뮬레이션이 없기 때문에 컨테이너는 아주 빠르게 실행됩니다. 프로세스 격리를 위해 아주 약간의 오버헤드가 있지만 일반적인 프로세스를 실행하는 것과 거의 차이가 없습니다. 또한 하나의 머신에서 프로세스만큼 많이 실행하는 것이 가능합니다.
3. Portability (이식성) : 모든 컨테이너는 호스트의 환경이 아닌 독자적인 실행 환경을 가지고 있습니다. 이 환경은 파일들로 구성되며, 이미지 형식으로 공유될 수 있습니다. 리눅스 커널을 사용하고 같은 컨테이너 런타임을 사용할 경우 컨테이너의 실행환경을 공유하고 손쉽게 재현할 수 있습니다. 이때 컨테이너 런타임은 컨테이너를 실행하고 관리하는 도구를 말합니다.
4. Stateless (무상태) : 컨테이너가 실행되는 환경은 독립적이기 때문에, 다른 컨테이너에게 영향을 주지 않습니다. 도커와 같이 이미지 기반으로 컨테이너를 실행하는 경우 특정 실행 환경을 쉽게 재사용할 수 있습니다.
이를 위와 같이 회사에 비유해보겠습니다.
사장이 기존 회사의 부사장에게 역할을 맡길 수가 없어서, 어쩔 수 없이 또 다른 회사 B를 만들었습니다.
이렇게 되면 기존 회사를 A라고 한다면, A와 B 회사를 모두 한 명의 사장이 관리하게 됩니다.
회사 B는 마치 게스트OS와 유사합니다.
회사가 두 개 라면 기존 회사 A 내에서만 작업을 처리하는 것보다, A와 B 회사 양쪽 회사 사이에 작업이 발생할 경우, 기존보다 의견전달 등이 느려지게 되고, 비효율적으로 될 것입니다.
이를 통해 운영체제 수준의 가상화와 빠른 속도와 효율성을 쉽게 이해할 수 있습니다. 원하는 부서 내에서 부사장이 관리하게 된다면 회사 B를 설립할 필요가 없으며, 이는 (1)으로 나타낼 수 있습니다. 또한 두 회사 간 하나의 프로젝트를 진행하게 된다면, 하나의 회사가 프로젝트를 진행하는 것보다 의견전달 면에서 느려집니다. 이는 반대로 말하면 하나의 회사로 진행하면 더 빠른 속도와 효율성을 갖는다는 말이 되며 이는 (2)으로 나타낼 수 있습니다.
(3)을 살펴보게 되면 컨테이너 런타임은 컨테이너를 실행하고 관리하는 도구를 의미합니다. 위에서 각각의 부서를 각각의 컨테이너라고 표현했습니다. 그렇다면 컨테이너 런타임은 부서장, 즉 부장으로 말할 수 있습니다. 회사가 달라지더라도 부사장과 부장이 함께 움직인다면, 이전과 같은 회사를 토대로 같은 조직을 다른 회사에서 쉽게 만들 수 있습니다. 이를 (3)으로 나타낼 수 있습니다.
(4)는 간단히 각각의 부서는 독립적으로 내부적으로 운영되는 것으로 나타낼 수 있습니다.
- 컨테이너의 종류
컨테이너는 크게 시스템 컨테이너와 애플리케이션 컨테이너로 나뉩니다.
시스템 컨테이너(system container)
: 시스템 컨테이너는 컨테이너 기술들을 사용해 운영체제 위에 하드웨어 가상화 없이 운영체제를 실행합니다. 일반적인 리눅스처럼 init 프로세스 등을 사용해서 다수의 프로세스가 같은 환경을 공유하는 것을 목표로 합니다. 시스템 컨테이너를 지행하는 컨테이너 런타임으로는 대표적으로 LXC와 LXD가 있습니다.
추가로 init 프로세스는 유닉스 기반 컴퓨터 운영 체제에서 컴퓨터 시스템의 부팅 과정에서 최초의 프로세스로, 시스템이 종료될때까지 계속 실행하는 데몬 프로세스 라는 특징이 있습니다. 따라서 다른 모든 프로세스의 직간접 부모 프로세스가 되며, 고아 프로세스를 입양합니다.
애플리케이션 컨테이너(application container)
: 애플리케이션 컨테이너는 컨테이너 기술을 활용해 하나의 애플리케이션(프로세스)를 실행하는 것을 목표로 합니다. 독립적인 환경을 가진다는 점에서는 시스템 컨테이너와 동일하지만, 단 하나의 프로세스만 실행한다는 점에서 확장이 쉽고 관리 요소가 거의 없습니다. 대표적인 애플리케이션 컨테이너 런타임으로는 도커(Docker)가 있습니다.
시스템 컨테이너의 경우, 하나의 공간에서 자유롭게 점선으로 여러 특정 공간을 나누고 필요한 것이 있을 경우 새롭게 점선을 그어서 공간을 확보해나가는 형식과 유사합니다.
애플리케이션 컨테이너의 경우, 하나의 공간에서 가벽을 통해 여러 특정 공간을 나누고 필요한 것이 있을 경우 해당 특정 공간에 추가해나가는 형식과 유사합니다.
- 컨테이너를 사용해야하는 이유
2014년 애플리케이션 컨테이너 런타임인 도커(Docker)가 등장하면서 컨테이너 기술이 많은 관심을 받고 있습니다. 서버 운영 면에서 컨테이너는 서버 애플리케이션의 배포 단위를 새로 정의했고, 서비스형 인프라스트럭처(Infrastructure as a Service, Iaas_서버, 스토리지, 네트워크 기반 시설)와 클라우드 변화에 큰 변화를 가져왔습니다.
기존의 서버 운영에서는 애플리케이션을 실행하기 위해 서버 컴퓨터의 상태를 지속적으로 관리해야했지만, 컨테이너를 사용하면 애플리케이션 별로 독자적인 환경을 준비하고 관리하는 것이 가능하기 때문에 서버 컴퓨터를 관리할 필요가 적어진다는 장점이 있습니다. 이러한 장점으로 인해 컨테이너 기술의 활용은 급속하게 확산되고 있는 추세입니다.
이를 기반으로 운영하고 있는 대표적인 기업으로는 구글, 넷플릭스, 에어비엔비, 핀터레스트, 레딧, 포켓몬 고, 스포티파이, 틴더, 라이엇 게임즈 등이 있으며, 국내 기업으로는 삼성전자, 삼성SDS, 당근마켓, VCNC(타다), 우아한형제들, 엔씨소프트, 토스 등이 있습니다.
2. 컨테이너에서 사용하는 프로세스 격리 기능
컨테이너 구현에는 리눅스 네임스페이스 ,루트 디렉터리 격리, 컨트롤 그룹, 캐퍼빌리티, 유니온 마운트 외에 다양한 리눅스 커널의 기능들이 사용됩니다.
- 리눅스 네임스페이스(Linux namespace)
리눅스 네임스페이스(Linux namespace)는 특정 리눅스 리소스 접근을 제어하기 위해 사용되는 기능입니다. 네임스페이스는 리소스 별로 IPC 네임스페이스, 마운트 네임스페이스, 네트워크 네임스페이스, PID 네임스페이스, 사용자 네임스페이스, UTS 네임스페이스, 컨트롤 그룹 네임스페이스 등으로 나뉩니다. 시스템 상에서 실행되는 프로세스들은 기본적으로 init 프로세스의 네임스페이스를 공유하지만 시스템콜이나 unshare 명령어를 사용해 리소스 별로 네임스페이스를 분리하는 것이 가능합니다. 이를 차례대로 소개하면 아래와 같습니다.
IPC 네임스페이스(InterProcess Communication namespace)는 IPC는 프로세스 간 데이터를 주고 받는 경로를 의미합니다. 이때 IPC 네임스페이스는 IPC 리소스를 분할 격리시키는 역할을 합니다.
마운트 네임스페이스(Mount namespace)는 프로세스와 그 자식 프로세스가 각기 다른 파일 시스템 마운트 지점을 분할하고 격리하는 네임 스페이스입니다.
네트워크 네임스페이스(Network namespace)는 프로세스 별로 고유한 네트워크 환경을 구축할 수 있도록 도와줍니다. 프로세스에 전용 IP를 할당하거나 네트워크 인터페이스를 추가하고 설정할 수 있습니다. 네트워크 네임스페이스는 ip 명령어로 조작할 수 있습니다.
PID 네임스페이스(process ID namespace)는 프로세스의 ID를 격리할 수 있는 네임 스페이스입니다. 프로세스 ID를 격리해서 마치 컨테이너가 init 프로세스(pid)인 것처럼 실행해줍니다.
사용자 네임스페이스(User namespace)는 user와 group ID를 분할하고 격리시키는 역할을 합니다.
UTS 네임스페이스(UNIX Time Sharing)는 hostname과 NIS (Network Information Service) 도메인 이름을 격리하는 네임스페이스입니다. 네트워크 네임스페이스와 함께 사용되는 경우가 많습니다.
컨트롤 그룹 네임스페이스(Cgroup namespace)는 네임스페이스는 시스템 리소스의 격리를 제공하고 Cgroup namespace의 경우에는 해당 리소스에 대한 세분화된 제어 및 격리를 하는 역할을 합니다.
- 루트 디렉터리 격리와 chroot
컨테이너는 호스트의 파일 시스템이 아닌 별도의 실행 환경을 가지고 있습니다. 이 때 사용되는 기술이 바로 루트 디렉터리 격리 기술로 chroot, pivot_root와 같은 시스템 콜이 이용됩니다. 이를 통해 프로세스가 바라보는 루트 디렉터리를 파일 시스템 상의 특정한 디렉터리로 변경하는 것이 가능합니다. chroot는 명령어로도 사용할 수 있기 때문에 런타임 없이도 비교적 쉽게 기능을 사용해볼 수 있습니다.
chroot :
chage root 로 root 계정을 변경하는 것이 아니라 Linux 시스템의 root(/)폴더, 즉 최상위 폴더의 위치를 바꾸는 명령어
pivot_root:
호출 프로세스의 마운트 스페이스에서 루트 마운트를 바꾸는 명령어
- 컨트롤 그룹(cgroups)
컨트롤 그룹(cgroups)은 프로세스에서 사용 가능한 CPU, 메모리, 네트워크 대역폭, 디스크 I/O 등을 그룹 단위로 제어하는 리눅스 커널의 기능입니다. 원래는 프로세스 컨테이너 이름으로 제안되었지만, 나중에 컨트롤 그룹이 되었습니다. 컨트롤 그룹은 컨테이너에서만 사용되는 기능은 아니고, 리눅스 시스템에서 프로세스 관리를 위해 일반적으로 사용되고 있습니다.
- 리눅스 캐퍼빌리티(Linux capabilities)
리눅스 캐퍼빌리티(Linux capabilities)는 프로세스의 권한을 제어하는 기능입니다. 리눅스의 프로세스는 크게 루트 권한 (사용자 ID 0)으로 실행되는 특권 프로세스와 일반 사용자(사용자 ID 0 이외)가 실행하는 비특권 나뉩니다. 루트의 권한을 세분화해서 프로세스 적용할 수 있도록 만든 기능이 바로 캐퍼빌리티입니다. 컨테이너 런타임에서도 일부 루트 권한이 필요한 경우 리눅스 캐퍼빌리티를 사용해 필요한 권한을 지정하는 방식을 지원하고 있습니다.
- 유니온 마운트(Union Mount)
유니온 마운트는 계층화된 파일 시스템을 구현합니다. 컨테이너에 필수적인 기능은 아니지만, 도커에서 이미지 구현에 사용하면서 필수적인 기능으로 자리잡았습니다. 유니온 마운트를 사용해 효율적인 이미지 구현이 가능할 뿐만 아니라, 이미지 빌드 과정에서 캐시를 사용하거나, 이미지를 관리하는 데도 이점이 있습니다.
3. 컨테이너 런타임
컨테이너 런타임은 컨테이너를 실행하고 관리하는 도구 입니다. 대표적으로 도커(Docker)가 있으며 도커가 아닌 컨테이너 런타임으로는 LXC, LXD, CRI-O, 가타 컨테이너(Kata Container), 하코니와(Haconiwa) 등이 존재합니다.
- 도커(Docker)
도커(Docker)는 닷클라우드의 솔로몬 하이크가 파이콘 2013 US에서 처음 발표한 컨테이너 런타임입니다. 애플리케이션 컨테이너 런타임을 지향했으며, 처음 등장한 이후 빠르게 퍼져서 사실상 표준으로 자리 잡았습니다. 초기의 도커는 LXC를 기반으로 컨테이너를 생성하고 관리했지만, 현재는 containerd와 runc를 기반을 동작합니다. 유니온 마운트 기반으로 효율적으로 실행 환경을 이미지로 만들고 공유할 수 있다는 장점이 있습니다. 도커는 기본적으로 서버, 클라이언트 아키텍처를 가지고 있으며 REST API로 조작할 수 있습니다. 또한 CLI 명령어는 깃과 비슷해서 개발자들이 쉽게 접근할 수 있습니다.
1) 도커 허브(Docker Hub)
도커 허브(Docker Hub)는 도커에서 제공하는 공식 원격 이미지 저장소 입니다. 도커가 처음에 자리잡는 데 가장 중요한 역할을 했던 게 바로 도커 레지스트지(도커 허브의 초기 이름)입니다. 기존의 컨테이너 기술들의 접근성이 떨어졌던 이유 중 하나로 실행 환경을 공유하는 것이 쉽지 않다는 점을 꼽을 수 있습니다. 시스템 컨테이너의 경우 실행 환경이 무거울 뿐만 아니라, 변경 사항을 적절하게 저장하고 공유하는 것이 어려웠습니다. 이와 달리 도커에서는 유니온 마운트 기반의 이미지 개념을 도입해 실행 환경을 효율적으로 관리하고 적절한 단위로 공유할 수 있습니다. 도커 허브를 통해 이미지를 쉽게 전달하거나 공유할 수 있도록 함으로써 접근성을 높였습니다.
원격 이미지 저장소를 직접 설치해서 사용하는 것도 가능합니다.
클라우드 서비스들에서는 프라이빗 이미지 저장소를 서비스로 제공합니다. 대표적으로는 아마족 웹 서비의 아마존 엘라스틱 컨테이너 레지스트리, 마이크로서비스 애저의 컨테이너 레지스트리 등이 있습니다. CNCF에서 관리하고 있는 오픈소스 도커 레지스트리 프로젝트 하버도 있습니다.
참고로 CNCF는 Cloud Native Computing Foundation으로 컨테이너 기술을 발전시키고 기술 산업이 발전할 수 있도록 지원하기 위해 2015년에 설립된 Linux Foundation의 재단입니다.
2) 도커 컴포즈 (Docker Compose)
도커 컴포즈(Docker Compose)는 다수의 컨테이너를 쉽게 관리할 수 있도록 도와주는 도구입니다. 원래는 피그(Fig)라는 도커와 무관한 프로젝트였습니다만, 2014년 7월 도커 사가 인수했습니다. 도커 명령어가 주로 하나의 컨테이너를 조작하는데 사용되는 반면, 도커 컴포즈를 사용하면 YAML 형식으로 컨테이너들을 명세를 작성한 후에 컨테이너를 한꺼번에 실행하거나 종료할 수 있습니다. 도커 컴포즈는 로컬 개발 환경을 구성하는데 사용하거나, 컨테이너 오케스트레이션 구성 이전에 초기 단계의 배포 작업에 사용되곤 합니다.
YAML 형식은 아래와 같습니다.
| - name : choi position : college age : 0 - name : kim position : student age : 1 - name : park position : teacher age : 2 |
- LXC
LXC는 리눅스 컨테이너 (Linux Conatiners)의 줄임말로, OS 수준의 가상화를 구현하는 도구입니다. 주로 시스템 컨테이너를 관리하기 위해 사용되지만, 애플리케이션 컨테이너를 실행하거나 관리하는 것도 가능합니다. 도커가 처음 공개되었을 때는 내부적으로 컨테이너를 실행하는 데 사용되기도 하였습니다.
- LXD
LXD는 새로운 시스템 컨테이너를 지향하는 컨테이너 도구입니다. LXC와 마찬가지로 컨테이너를 실행하고 관리하는 도구입니다. LXC에 비해서 기능이 강화되었으며, 편리한 인터페이스를 제공하고, REST API로 조작하는 것이 가능합니다. LXD는 단순히 LXC를 개선한 도구는 아니며, 내부적으로 컨테이너를 실행할 때는 LXC를 사용합니다.
- CRI-O
크리-오(CRI-O)는 쿠버네티스를 위한 경량 컨테이너 런타임 프로젝트로 현재 CNCF(Cloud Native Computing Foundation)에서 인큐베이팅 단계로 관리하고 있습니다. 크리-오는 OCI(Open Container Initiavate) 표준을 따르는 런타임으로 쿠버네티스 CRI(Kubernetes Container Runtime Interface)를 구현하고 있습니다. 도커보다 가벼운 컨테이너 런타임으로 쿠버네티스 지원을 지향하고 있습니다.
참고로 OCI는 Open Container Initiative 로 2015년 Dcoker에서 시작한 Linux Foundation 프로젝트로 운영 체제 수준 가상화, 가장 중요한 Linux 컨테이너를 위한 개방형 표준, 즉 사용이 자유로운 것을 설계합니다.
- 가타 컨테이너(Kata Container)
카타 컨테이너(Kata Container) 는 오픈스택 재단(OpenStack Foundation)에서 개발중인 경량 VM 기반으로 컨테이너를 실행하는 런타임입니다. 컨테이너와 가상머신의 가장 중요한 차이는 호스트 머신과 커널을 공유하는지로 나눌 수 있습니다. 하지만 카타 컨테이너 전용 가상머신을 준비한다는 점에서 제 3의 접근이라고 할 수 있습니다. 경량 VM을 사용하기 때문에 일반적인 가상 머신보다 훨씬 빠르며, 가상 머신이기 때문에 커널을 공유하는 일반적인 컨테이너보다 훨씬 안전한 샌드박스를 구현하는 것이 가능합니다.
- 하코니와(Haconiwa)
하코니와(Haconiwa)는 도메인 특화 언어(DSL : Domain Specific Language)로 리눅스 컨테이너들에서 사용되는 프로세스 격리 기능들을 조합해 자신만의 컨테이너를 만들어볼 수 있는 프로젝트입니다. 리눅스 컨테이너를 구현하는데 사용되는 기술로는 앞서 설명한 리눅스 네임스페이스, 컨트롤그룹, 리눅스 캐퍼빌리티, 바잉트 마운트, chroot 등 다양한 기능들이 있습니다. 도커를 비롯한 컨테이너 런타임에서는 이러한 기능들을 하나의 세트로 제공하고, 세부적인 설정을 지원하지 않습니다. 하코니와를 사용하면 이러한 기능들을 조합해 커스텀한 컨테이너를 만들어볼 수 있습니다. 컨테이너 기술의 이해를 도와주는 프로젝트 입니다.
4. 컨테이너 오케스트레이션
컨테이너 오케스트레이션은 다수의 컨테이너를 적절하게 분산하고 스케줄링 하는 방법과 도구입니다. 대표적으로 구글이 처음에 주도하고 현재는 CNCF에서 관리하고 있는 쿠버네티스(Kubernetes)가 있습니다.
- 쿠버네티스(Kubernetes)
쿠버네티스(Kubernetes)는 구글의 엔지니어(조 베다, 브렌던 번스, 그레이그 맥룰키 등)가 주도적으로 시작한 컨테이너 오케스트레이션 도구로 2014년 중반 오픈소스로 공개되었습니다. 쿠버네티스는 컨테이너 오케스트레이션 분야에서 사실상 표준으로 자리 잡았으며, 현재는 온프레미스, 클라우드 환경 가릴 것 없이 많은 서비스들이 쿠버네티스 위에서 동작하고 있습니다.
- 아마존 ECS (Amazon ECS)
아마존 ECS(Amazon Elastic Container Service)는 아마존 웹 서비스(Amazon Web Service)에서 완전 관리형으로 제공되는 컨테이너 오케스트레이션 서비스입니다. 비교적 개념이 단순하고, 다른 AWS 서비스와 상성이 좋다는 장점이 있지만 커뮤니티가 작고 오픈소스가 아니라는 단점이 있습니다. AWS에서는 쿠버네티스 마스터 노드를 관리형으로 제공한 EKS(Elastic Kubernetes Service)를 제공하는 한편, ECS도 지속적으로 개선해나가고 있습니다.
- 랜처(Rancher)
랜처(Rancher)는 쿠버네티스 기반의 컨테이너 오케스트레이션 도구입니다. 기존의 랜처 1.0에서는 도커 기반의 컨테이너 오케스트레이션을 구현했지만, 2.0 버전은 쿠버네티스 기반으로 동작합니다.
- 노마드(Nomad)
노마드(Nomad)는 오픈소스로 인프라스트럭처 관련 도구를 만드는 하시코프(HashiCorp)에서 내놓은 컨테이너 오케스트레이션 도구입니다. 노마드는 태스크 관리와 스케줄링에 집중하고 있는 도구로 반드시 컨테이너를 사용하지 않더라고 사용할 수 있습니다. 또한 다른 도구들에 비해서 비교적 단순하다는 장점이 있습니다.
'IT > 컨테이너 & 오케스트레이션' 카테고리의 다른 글
| [대세는 쿠버네티스] 섹션 6. [중급편] 기본 오브젝트 (0) | 2023.02.09 |
|---|---|
| [컨테이너&오케스트레이션] 도커 컨테이너는 가상머신인가요? 프로세스인가요? (0) | 2022.11.19 |
