2017.09.08

리뷰 : 레드햇 아토믹 호스트 “도커를 해결하는 수준 높지만 어려운 방법”

Steven Nunez | InfoWorld

프로젝트 아토믹(Project Atomic)은 쿠버네티스(Kubernetes)와 레드햇의 엔지니어링 역량을 최첨단 컨테이너 호스트에 쏟아 부었다. 하지만 사용자는 소매를 걷어붙일 준비를 해야 할 것이다.

레드햇의 프로젝트 아토믹은 리눅스 컨테이너를 실행하는 위한 독창적인 방법이다. 아토믹 호스트 운영체제에는 도커(Docker, 컨테이너), 플란넬(Flannel, 네트워킹), OS트리(OSTree, 호스트 관리), Etcd(분산키 저장소)가 따라오며, 쿠버네티스(오케스트레이션)가 사전 설치되어 있다.

이로써 “모든 것을 갖췄다”고 말할 수도 있지만, 그에 따른 추가적인 복잡성과 관리 오버헤드가 있다.

쿠버네티스는 여러 대의 아토믹 호스트에 걸쳐 “팟(Pod)”의 생성을 조율한다. 팟이란 하나의 애플리케이션에 있는 서비스들을 논리적으로 분리시키는 도커 컨테이너들의 그룹을 지칭한다. 하나의 팟에 있는 컨테이너는 IP 주소를 공유하고 내부접속(localhost)을 통해서 통신한다.

플란넬은 아토믹 호스트들을 위한 오버레이 네트워크를 제공해 클러스터에 있는 모든 팟이 해당 클러스터 내부의 다른 모든 팟 또는 서비스와 통신할 수 있게 해준다. 이 오버레이 네트워크는 컨테이너 네트워킹용으로만 사용된다. 쿠버네티스 프록시 서비스(Proxy Service)는 호스트 IP 공간에 대한 액세스를 제공한다.

Etdc는 클러스터에 있는 모든 호스트 전체에 대해 쿠버네티스와 플란넬의 모두에 대한 구성을 저장하는 데 사용된다.

아토믹 컨테이너 클러스터는 쿠버네티스 때문에 몇 가지 가정을 두는데, 관리자들은 아토믹에 대해서 실제로 선택의 여지가 없다: 쿠버네티스를 사용하거나 아니면 다른 컨테이너 OS를 찾거나.

“관습에 의한 설계”로 짜증이 나고 컨테이너 호스트에 대해 더 많은 자유로움과 유연성을 원한다면, 랜처OS(RancherOS)나 VMware 포톤(Photon)을 고려해 볼 수도 있다. 하지만 최종 목표가 여러 대의 호스트 상에서 여러 대의 컨테이너를 실행하는 것이라면, 아토믹 호스트와 쿠버네티스 등등이 안성맞춤의 해결책이 될 수 있다.

Image Credit : GettyImagesBank

아토믹 호스트 시스템 관리
실제 docker 명령어를 /bin/docker에서 사용할 수도 있지만, 아토믹 호스트(Atomic Host)는 자체 버전의 docker 명령어, atomic을 사용한다. /bin이란 위치는 아토믹 OS를 컨테이너용으로 만들기 위해 RHEL(Red Hat Enterprise Linux)/센트OS(CentOS)/페도라(Fedora)에 대해 몇 가지 재작업이 수행되었음을 암시한다. 통상적으로 중요한 시스템 바이너리 파일들만이 /bin에 저장된다.

사용자는 두 개의 서브시스템을 통해서 아토믹 호스트를 관리한다. RPM-OS트리는 호스트 시스템의 배포와 업데이트를 처리하는 한편, 도커는 실행중인 서비스와 애플리케이션에 대한 컨테이너 프로비저닝을 처리한다. 이 두 가지 서브시스템 모두 /usr/bin에 있는 atomic 명령어로 관리한다.

RPM-OS트리는 아토믹 파일시스템을 불변으로 만든다. 즉, /var와 /etc를 제외하고 파일시스템은 읽기 전용이다. /var/lib/docker 디렉토리는 모든 도커 관련 파일과 이미지들이 저장된 장소이고, /etc에는 모든 구성 파일이 보관되어 있다. 나중에 보겠지만, 이는 호스트에 대한 업그레이드와 다운그레이드를 더 간단하고 안전하게 만들어주며, 클러스터에 있는 잠재적으로 수천 대에 이르는 컨테이너 호스트를 관리할 때 필수 요건이다.

atomic 명령어는 컨테이너 서브시스템에 대한 단일 진입점이다. 즉 호스트 운영을 포함해서 컨테이너의 모든 것에 대한 포괄적인 명령어이다. atomic 명령어는 모양이나 느낌이 docker 명령어와 비슷해 보이지만, 모든 컨테이너 호스트 운영체제가 공유하고 있는 근본적인 문제를 해결한다. 부팅 시간에 Systemd 유닛 파일(Unit Files)를 사용해서, 믿을 수 있고 투명한 방식으로, 컨테이너에서 시스템 차원의 서비스를 시작시킨다.

아토믹에서 이 작업은 SPC(Super-privileged Container)라는 것을 사용해서 수행되며, SPC는 호스트 자체를 보고 조작할 수 있는 능력을 가지고 있따. 그래서, atomic이 표준 도커 명령어처럼 보이기는 하지만, 이 명령어는 컨테이너 기반 애플리케이션의 신뢰성 있는 배포를 가능케 하기 위해 도커와 RPM-OS트리 간의 공백을 채워준다. 설치 스크립트 구성, 서비스 설정, 적합한 권한 할당 등을 처리한다.

한마디로, atomic 명령어는 사용자가 애플리케이션을 실행하기 위해 기반 호스트 인프라(cgroups, namespaces, SELinux 등)를 조작할 수 있게 해준다. 예를 들어, 호스트의 시스템 시간을 수정하기 우해 SYS_TIME 기능을 필요로 하는 ntpd(NTP: Network Time Protocol) 컨테이너 애플리케이션을 구축했다고 가정하자. 다음가 같은 명령을 사용해서 컨테이너 이미지에 메타데이터를 추가함으로써 이를 구성할 수 있다:

LABEL RUN /usr/bin/docker run -d -cap-add=SYS_TYPE ntpd

그런 다음 컨테이너(atomic run ntpd)를 실행하면, 시스템이 메타데이터를 읽고 컨테이너에 대한 SYS_TIME 기능과 다른 자원들을 구성할 것이다.

아토믹 호스트 설치와 구성
필자가 보기에 문서가 체계적이지 않고 혼란스러웠기 때문에 설치가 어려웠다. 문서는 대부분 사용자가 가지고 있지 않을, 레드햇 생태계에 대한 높은 수준의 지식을 전제로 하고 있다. 몇 차례의 잘못된 시도 끝에, 마침내 베어 메탈 ISO로 간신히 설치할 수 있었다. 가상머신 설치에 대한 지원이라고는 virt-manager 밖에 없어서 고통스러웠다. 아토믹 호스트는 이런 점에서 확실하게 윈도우나 맥 친화적이지 않다.

센트OS 설치에 친숙한 사람에게는 베어 메탈 절차가 쉬울 것이다. 눈에 띄는 유일한 차이점은 디스크 배치로, 컨테이너 OS 설치에 수반되는 지나치게 많은 횟수의 SELinux, cgroups 등의 마운트와 더불어, 도커와 컨테이너용으로 공간이 자동으로 예약되어 있다.



2017.09.08

리뷰 : 레드햇 아토믹 호스트 “도커를 해결하는 수준 높지만 어려운 방법”

Steven Nunez | InfoWorld

프로젝트 아토믹(Project Atomic)은 쿠버네티스(Kubernetes)와 레드햇의 엔지니어링 역량을 최첨단 컨테이너 호스트에 쏟아 부었다. 하지만 사용자는 소매를 걷어붙일 준비를 해야 할 것이다.

레드햇의 프로젝트 아토믹은 리눅스 컨테이너를 실행하는 위한 독창적인 방법이다. 아토믹 호스트 운영체제에는 도커(Docker, 컨테이너), 플란넬(Flannel, 네트워킹), OS트리(OSTree, 호스트 관리), Etcd(분산키 저장소)가 따라오며, 쿠버네티스(오케스트레이션)가 사전 설치되어 있다.

이로써 “모든 것을 갖췄다”고 말할 수도 있지만, 그에 따른 추가적인 복잡성과 관리 오버헤드가 있다.

쿠버네티스는 여러 대의 아토믹 호스트에 걸쳐 “팟(Pod)”의 생성을 조율한다. 팟이란 하나의 애플리케이션에 있는 서비스들을 논리적으로 분리시키는 도커 컨테이너들의 그룹을 지칭한다. 하나의 팟에 있는 컨테이너는 IP 주소를 공유하고 내부접속(localhost)을 통해서 통신한다.

플란넬은 아토믹 호스트들을 위한 오버레이 네트워크를 제공해 클러스터에 있는 모든 팟이 해당 클러스터 내부의 다른 모든 팟 또는 서비스와 통신할 수 있게 해준다. 이 오버레이 네트워크는 컨테이너 네트워킹용으로만 사용된다. 쿠버네티스 프록시 서비스(Proxy Service)는 호스트 IP 공간에 대한 액세스를 제공한다.

Etdc는 클러스터에 있는 모든 호스트 전체에 대해 쿠버네티스와 플란넬의 모두에 대한 구성을 저장하는 데 사용된다.

아토믹 컨테이너 클러스터는 쿠버네티스 때문에 몇 가지 가정을 두는데, 관리자들은 아토믹에 대해서 실제로 선택의 여지가 없다: 쿠버네티스를 사용하거나 아니면 다른 컨테이너 OS를 찾거나.

“관습에 의한 설계”로 짜증이 나고 컨테이너 호스트에 대해 더 많은 자유로움과 유연성을 원한다면, 랜처OS(RancherOS)나 VMware 포톤(Photon)을 고려해 볼 수도 있다. 하지만 최종 목표가 여러 대의 호스트 상에서 여러 대의 컨테이너를 실행하는 것이라면, 아토믹 호스트와 쿠버네티스 등등이 안성맞춤의 해결책이 될 수 있다.

Image Credit : GettyImagesBank

아토믹 호스트 시스템 관리
실제 docker 명령어를 /bin/docker에서 사용할 수도 있지만, 아토믹 호스트(Atomic Host)는 자체 버전의 docker 명령어, atomic을 사용한다. /bin이란 위치는 아토믹 OS를 컨테이너용으로 만들기 위해 RHEL(Red Hat Enterprise Linux)/센트OS(CentOS)/페도라(Fedora)에 대해 몇 가지 재작업이 수행되었음을 암시한다. 통상적으로 중요한 시스템 바이너리 파일들만이 /bin에 저장된다.

사용자는 두 개의 서브시스템을 통해서 아토믹 호스트를 관리한다. RPM-OS트리는 호스트 시스템의 배포와 업데이트를 처리하는 한편, 도커는 실행중인 서비스와 애플리케이션에 대한 컨테이너 프로비저닝을 처리한다. 이 두 가지 서브시스템 모두 /usr/bin에 있는 atomic 명령어로 관리한다.

RPM-OS트리는 아토믹 파일시스템을 불변으로 만든다. 즉, /var와 /etc를 제외하고 파일시스템은 읽기 전용이다. /var/lib/docker 디렉토리는 모든 도커 관련 파일과 이미지들이 저장된 장소이고, /etc에는 모든 구성 파일이 보관되어 있다. 나중에 보겠지만, 이는 호스트에 대한 업그레이드와 다운그레이드를 더 간단하고 안전하게 만들어주며, 클러스터에 있는 잠재적으로 수천 대에 이르는 컨테이너 호스트를 관리할 때 필수 요건이다.

atomic 명령어는 컨테이너 서브시스템에 대한 단일 진입점이다. 즉 호스트 운영을 포함해서 컨테이너의 모든 것에 대한 포괄적인 명령어이다. atomic 명령어는 모양이나 느낌이 docker 명령어와 비슷해 보이지만, 모든 컨테이너 호스트 운영체제가 공유하고 있는 근본적인 문제를 해결한다. 부팅 시간에 Systemd 유닛 파일(Unit Files)를 사용해서, 믿을 수 있고 투명한 방식으로, 컨테이너에서 시스템 차원의 서비스를 시작시킨다.

아토믹에서 이 작업은 SPC(Super-privileged Container)라는 것을 사용해서 수행되며, SPC는 호스트 자체를 보고 조작할 수 있는 능력을 가지고 있따. 그래서, atomic이 표준 도커 명령어처럼 보이기는 하지만, 이 명령어는 컨테이너 기반 애플리케이션의 신뢰성 있는 배포를 가능케 하기 위해 도커와 RPM-OS트리 간의 공백을 채워준다. 설치 스크립트 구성, 서비스 설정, 적합한 권한 할당 등을 처리한다.

한마디로, atomic 명령어는 사용자가 애플리케이션을 실행하기 위해 기반 호스트 인프라(cgroups, namespaces, SELinux 등)를 조작할 수 있게 해준다. 예를 들어, 호스트의 시스템 시간을 수정하기 우해 SYS_TIME 기능을 필요로 하는 ntpd(NTP: Network Time Protocol) 컨테이너 애플리케이션을 구축했다고 가정하자. 다음가 같은 명령을 사용해서 컨테이너 이미지에 메타데이터를 추가함으로써 이를 구성할 수 있다:

LABEL RUN /usr/bin/docker run -d -cap-add=SYS_TYPE ntpd

그런 다음 컨테이너(atomic run ntpd)를 실행하면, 시스템이 메타데이터를 읽고 컨테이너에 대한 SYS_TIME 기능과 다른 자원들을 구성할 것이다.

아토믹 호스트 설치와 구성
필자가 보기에 문서가 체계적이지 않고 혼란스러웠기 때문에 설치가 어려웠다. 문서는 대부분 사용자가 가지고 있지 않을, 레드햇 생태계에 대한 높은 수준의 지식을 전제로 하고 있다. 몇 차례의 잘못된 시도 끝에, 마침내 베어 메탈 ISO로 간신히 설치할 수 있었다. 가상머신 설치에 대한 지원이라고는 virt-manager 밖에 없어서 고통스러웠다. 아토믹 호스트는 이런 점에서 확실하게 윈도우나 맥 친화적이지 않다.

센트OS 설치에 친숙한 사람에게는 베어 메탈 절차가 쉬울 것이다. 눈에 띄는 유일한 차이점은 디스크 배치로, 컨테이너 OS 설치에 수반되는 지나치게 많은 횟수의 SELinux, cgroups 등의 마운트와 더불어, 도커와 컨테이너용으로 공간이 자동으로 예약되어 있다.



X