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

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 등의 마운트와 더불어, 도커와 컨테이너용으로 공간이 자동으로 예약되어 있다.


클러스터 전체의 컨테이너를 관리하기 위해 쿠버네티스를 사용하는 것이 한 대의 호스트 상에서 도커를 실행하는 것보다 훨씬 더 복잡하기는 하지만, 훨씬 더 큰 복잡성에 따른 훨씬 더 큰 신뢰성과 기능이 있다. 쿠버네티스를 사용하면 이 시스템이 대규모 실제 업무 환경에서 (구글에서) 실제로 시험되었다는 사실에 따른 안도감도 얻을 수 있다.

쿠버네티스 마스터(master)를 설정하기 위한 쉬운 방법은 존재하지 않는다. 문서는 여러 프로젝트 웹사이트에 산재되어 있고, 많은 경우 문서들은 세부사항을 다른 사이트로 넘기고 있기 때문에, 문서를 읽고, 추적하며, 실험하는 데 많은 시간을 소비할 각오를 해야한다. 노력의 대부분은 몇 개의 /etc 디렉토리에 흩어져있는 열두어 가지 정도의 파일을 수정하는 것이다. 물론 요령은 그런 수정사항들이 뭔지를 파악하는 것이다. 쿠버네티스는 컨테이너를 사용한 간단한 실험용으로 만들어진 것이 결코 아니다. 쿠버네티스는 진지한 실제 업무용이다.

쿠버네티스, 인증서, 서비스, 그리고 플란넬 오버레이 네트워크로 마스터를 구성한 다음, flannneld, kubelet, 그리고 Etcd를 설치한 다음에야 비로소 다섯 개의 노드로 구성된 컨테이너 클러스터를 실행할 수 있었다. 불행하게도, 이 작업은 많은 양의 메모리를 사용해서 필자는 랜처OS나 VM웨어 포톤에서 시험했던 것처럼, 단일 노드를 사용해서 시험할 수 있는 방법을 찾아내지 못했다.

이 시점에서, 서비스와 애플리케이션을 캡슐화하는 컨테이너 그룹인 팟을 실행시키고 관리하는데 쿠버네티스를 사용할 수 있다.

아토믹 호스트 스토리지와 네트워킹
대부분 컨테이너 호스트 운영체제와 마찬가지로, 아토믹 호스트는 호스트를 실행하기에 충분한 디스크 공간만이 포함된, 최소한의 접근방식을 취하고 있다. 이는 일반적인 클러스터가 실행되는 여러 개의 도커를 수용하기에는 충분하지 않은 공간만 남기게 되어서, 이 용도로 호스트에 외장 스토리지를 부착할 필요가 있다.

도커에서 이미지와 관련 파일들은 대개 /var/lib/docker에 저장되고, 대부분의 표준 운영체제에서는 스토리지를 추가하기 위해 이 시점에서 하나의 기기를 파일시스템에 그냥 마운트할 것이다. 그렇지만, 아토믹은 도커 이미지와 메타파일을 저장하기 위해 디바이스 매퍼(Device Mapper) 백엔드를 통해서 Direct LVM(Linux Volume Manager) 볼륨을 사용한다. 즉 /dev/atomicos/docker-data와 /dev/atomicos/docker-meta를 사용하는데, 이는 아토믹 호스트에 공간을 추가하기 위해서 LVM과 볼륨에 대해 조금은 공부할 필요가 있다는 의미이다.

아토믹에서 스토리지 관리의 출발점은 설정 스크립트 /etc/sysconfig/docker-storage-setup이다. 아토믹 호스트는 도커 스토리지용으로 스토리지 풀을 가지고 있어서, 여기서의 요령은 새로운 기기를 이 풀에 추가하는 것이다. 다음과 같이 파일에 기기 목록을 추가하면 된다:

DEVS="/dev/vdb /dev/vdc"

그 다음에는 헬퍼 스크립트 /usr/bin/docker-storage-setup를 실행한다. 모든 것이 제대로 진행되면, 디스크가 풀에 추가되고, 아토믹 호스트는 도커용 공간을 확보하게 된다. 실제 업무에서는 LVM이 기존 관리 도구를 사용하거나 앤서블/솔트/셰프/퍼펫(Ansible/Salt/Chef/Puppet) 스크립트 같은 것으로 관리될 것이기 때문에, 대형 데이터센터 환경에서 작업하고 있는 관리자들에게는 더 일반적으로 보일 것이라 생각한다.

프로젝트 아토믹은 Etcd를 통해서 컨테이너 오버레이 네트워크를 제공하기 위해 플란넬을 사용한다. 컬(Curl) 같은 도구를 사용해서, JSON 구성 파일을 Etcd 키-값 저장소에 넣음으로써 이 작업을 구성한다. 컨테이너에 대한 서브넷을 구성하기 위해, 다음과 같은 JSON 파일을 생성할 수 있다:

{
“Network”: “172.16.0.0/12”,
“SubnetLen”: 24,
“Backend”: {
“Type”: “vxlan”
}
}


그리고 이 파일을 Etcd 마스터에 넣기 위해, 이것을 네트워크 구성 키에 넣는다:

curl -L http://localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode value@flanneld-conf.json

다소 성가시기는 하지만, 할 수는 있다. 이런 구성 명령어들을 atomic ifconfig…, atomic route…, 등 같이 유닉스 관리자에게 좀 더 직관적으로 만들어주는 래퍼(Wrapper)가 있었으면 한다.

여기에 강조할 가치가 있는 또 다른 차이점이 있다. 팟과 서비스에 대한 쿠버네티스의 개념이 그것이다. 팟은 비교적 강하게 결합된(tightly coupled: 강결합) 컨테이너 그룹이다. 팟에 있는 모든 컨테이너는 동일한 호스트와 동일한 IP 주소를 공유하며, 동시에 생성되고 소멸한다. 사용자가 실행하고 싶은 팟의 인스턴스 개수를 지정하면, 쿠버네티스가 명령을 수행한다. 어떤 인스턴스가 중지되거나 장애를 일으키면, 원했던 상태에 일치시키기 위해 쿠버네티스가 또 다른 인스턴스를 스핀업(Spin Up)시킨다.

쿠버네티스 서비스는 논리적인 팟 세트와 팟에 액세스하는 정책을 정의하는 추상화 계층이다. 이는 (마이크로) 서비스에 팟 라이프사이클에 걸쳐 하나의 안정적인 이름과 주소를 제공한다. 더 많은 것들이 있지만, 이 정도만으로도 네트워크를 관리하기 위해 별도의 구성요소가 필요한 이유를 이해하는 데는 도움이 될 것이다. 아토믹 호스트에서는 이 구성요소가 바로 플란넬이다.

아토믹 호스트 업그레이드와 다운그레이드
아토빅 호스트는 RPM-OS트리라는 패키지 관리자를 사용하는데, 전통적인 RPM과 OS트리의 기능을 결합한 것이다. RPM-OS트리는 프로세스가 (데이터베이스에서 사용되는 단어로) “최소단위 작업(atomic)”이기 때문에, 안정적으로 작업 수행(Roll Forward) 그리고 작업 취소(Roll Backward)를 할 수 있는 역량을 제공한다. RPM-OS트리는 업데이트에 대해 안정적인 트랜잭션을 제공한다 즉, 운영하고 있는 시스템을 망가뜨릴 가능성이 없다는 의미이다. 컨테이너들에 대한 명령어들처럼, 호스트 업그레이드와 롤백은 아토믹 관리 시스템을 의미하는 atomic이란 명령어가 앞에 붙는다:

atomic host upgrade
atomic host rollback


필자는 롤백할 것이 아무것도 없어서, 롤백은 시험하지 않았음에 유의하라.

레드햇 아토믹 호스트는 레드햇 기술과 인프라에 많은 투자를 한 조직에 가장 적합하다. 다른 각도에서 시작하는 기업이라면 다른 옵션을 고려해 볼 수도 있다. 쿠버네티스가 포함되어 있고, 대규모 프로덕션 환경에서 레드햇의 이력이 갖는 영향력 때문에 아토믹 호스트는 엔터프라이즈에서 컨테이너화된 워크로드를 실행하기 위한 “낙하산 솔루션”이 될 것이 거의 확실하다. 그렇지만, 필자는 개발자들이 아토믹 호스트를 자신들이 선택한 도커 플랫폼으로 여길 거라고는 보지 않는다.  editor@itworld.co.kr