컨테이너 리눅스

1. 개요

컨테이너 리눅스는 애플리케이션을 자체 컨테이너 내에서 실행하도록 설계된 운영 체제이다. Linux 커널의 운영 체제 수준 가상화 기능을 활용하여 여러 격리된 Linux 시스템을 생성하며, 초기에는 도커를 사용했으나 rkt로 대체되었다. 젠투 리눅스의 ebuild 스크립트를 사용하여 시스템 구성 요소를 컴파일하고, systemd를 init 시스템으로 사용한다. 2018년 레드햇에 인수된 후, Red Hat CoreOS로 통합되었고, Flatcar Container Linux와 같은 파생 제품도 존재한다. 컨테이너 리눅스는 이중 파티션 방식을 통한 자동 업데이트, etcd를 이용한 클러스터 인프라 관리, 그리고 다양한 배포 환경을 지원한다.

2. 역사

컨테이너 리눅스는 2013년 CoreOS사에 의해 처음 개발되었다. 2018년 1월, 레드햇은 CoreOS사를 인수했다.

2.1. 개발 배경

--
컨테이너 리눅스는 2013년 CoreOS사에 의해 처음 개발되었다. 초기에는 도커 컨테이너 기술을 중심으로 개발되었으나, 2014년 12월, rkt (초기 출시명 Rocket)라는 자체 컨테이너 엔진을 개발하여 도커의 대안을 제시하였다. CoreOS는 애플리케이션 컨테이너 이미지(ACI)의 필수 속성을 설명하는 앱 컨테이너(appc) 사양의 구현으로 rkt를 제공했다.

2015년에는 개방형 컨테이너 표준인 OCI (Open Container Initiative, 초기 명칭 Open Container Project)에 참여하여 컨테이너 기술 생태계 발전에 기여하였다. 컨테이너 리눅스는 젠투 리눅스의 ebuild 스크립트를 사용하여 시스템 구성 요소의 자동 컴파일을 수행하며, systemd를 주요 init 시스템으로 사용한다.

2.2. 레드햇 인수 및 파생

2018년 1월, 레드햇은 CoreOS, Inc.를 인수했다. 이후 레드햇은 CoreOS Container Linux를 자사의 Project Atomic과 통합하여 새로운 운영체제인 Red Hat CoreOS를 만들고, 상위 Fedora Project 오픈 소스 커뮤니티를 Fedora CoreOS 중심으로 정렬하여 두 기술을 결합할 것이라고 발표했다.

2018년 3월 6일, Kinvolk GmbH는 CoreOS Container Linux의 파생 제품인 [https://www.flatcar-linux.org/ Flatcar Container Linux]를 발표했다. 이는 상위 CoreOS 알파, 베타 및 안정 채널 릴리스를 추적하며, 2019년 5월에 실험적인 Edge 릴리스 채널이 추가되었다.

3. 기술적 특징

컨테이너 리눅스는 다음과 같은 기술적 특징을 가지고 있다.

* 컨테이너 기반 아키텍처: 패키지 관리자를 제공하지 않으며, 모든 애플리케이션이 자체 컨테이너 내에서 실행된다. 운영 체제 수준 가상화 기능을 사용하여 격리된 Linux 시스템으로 작동하는 여러 컨테이너를 생성하고 구성한다. 하이퍼바이저를 사용하고 완전한 가상 머신을 제공하는 대신, 여러 격리된 사용자 공간 인스턴스를 통해 컨테이너 간에 자원을 분할한다. 이 방식은 Linux 커널의 cgroups 및 네임스페이스 기능을 사용한다.

* 자동 업데이트 및 관리: 이중 파티션 방식을 사용하여 운영체제 업데이트를 더욱 안전하고 안정적으로 수행한다. 업데이트는 전체 이미지 형태로 배포되며, 재부팅 또는 kexec 시 활성화되는 보조 부트 파티션에 설치된다.

* 클러스터 인프라스트럭처: 클러스터 구성 정보를 공유하고 관리하기 위해 etcd 분산 키-값 저장소를 사용한다. etcd는 Raft 알고리즘을 기반으로 하여 데이터의 안정성과 일관성을 보장한다.

3.1. 컨테이너 기반 아키텍처

컨테이너 리눅스는 패키지 관리자를 제공하지 않으며, 모든 애플리케이션이 자체 컨테이너 내에서 실행되도록 한다. 단일 제어 호스트 역할을 하는 컨테이너 리눅스 인스턴스는 Linux 커널의 운영 체제 수준 가상화 기능을 사용하여 격리된 Linux 시스템으로 작동하는 여러 컨테이너를 생성하고 구성한다. 이러한 방식으로, 하이퍼바이저를 사용하고 완전한 가상 머신을 제공하는 대신 여러 격리된 사용자 공간 인스턴스를 통해 컨테이너 간의 자원 분할이 이루어진다. 이 접근 방식은 Linux 커널의 cgroups 및 네임스페이스 기능을 사용하며, 이는 사용자 공간 프로세스 모음에 대한 자원 사용(CPU, 메모리, 디스크 I/O)을 제한, 계산 및 격리하는 기능을 함께 제공한다.

초기에 컨테이너 리눅스는 도커를 사용하여 Linux 커널의 운영 체제 수준 가상화 기능에 대한 인터페이스를 제공하고, 애플리케이션이 다른 환경에서 실행될 수 있도록 하는 컨테이너에 대한 표준화된 형식을 제공했다. 2014년 12월, CoreOS는 도커의 대안으로 rkt (초기 출시명 Rocket)를 출시하고 지원하기 시작하여 애플리케이션 컨테이너 이미지의 또 다른 표준화된 형식, 관련 컨테이너 런타임 환경 정의, 컨테이너 이미지를 검색하고 검색하기 위한 통신 프로토콜을 제공했다. CoreOS는 앱 컨테이너 (appc) 사양의 구현으로 rkt를 제공하며, 이는 애플리케이션 컨테이너 이미지 (ACI)의 필수 속성을 설명한다. CoreOS는 appc 및 ACI를 공급업체 및 운영 체제에 독립적인 Open Container Initiative (OCI, 초기 명칭 Open Container Project (OCP)) 컨테이너화 표준의 일부가 되도록 목표로 하는 독립적인 위원회 주도 사양 세트로 만들었다. 이는 2015년 6월에 발표되었다.

3.2. 자동 업데이트 및 관리

컨테이너 리눅스는 이중 파티션 방식을 사용하여 운영체제 업데이트를 더욱 안전하고 안정적으로 수행한다. 업데이트는 전체 이미지 형태로 배포되며, 재부팅 또는 kexec 시 활성화되는 보조 부트 파티션에 설치된다. 이 방식은 운영 체제의 특정 부분만 업데이트할 때 발생할 수 있는 문제를 방지하고, 안정적인 운영 체제 버전으로 쉽게 롤백할 수 있도록 하며, 각 부트 파티션에 디지털 서명을 할 수 있도록 하여 보안을 강화한다. 루트 파티션과 루트 파일 시스템은 재부팅 시 사용 가능한 모든 디스크 공간을 채우도록 자동으로 크기가 조정된다. 루트 파티션은 읽기-쓰기 저장 공간을 제공하는 반면, 운영 체제 자체는 읽기 전용으로 마운트된다.

클러스터 환경에서 운영 체제 업데이트를 적용할 때, 클러스터의 특정 부분만 한 번에 재부팅하여 배포된 애플리케이션을 실행하는 데 필요한 리소스를 보존하기 위해 CoreOS는 컨테이너 리눅스에 대한 재부팅 관리자인 locksmith를 제공한다. Locksmith를 사용하면 업데이트 적용의 마지막 단계에서 재부팅이 수행되는 방식에 따라 서로 다른 업데이트 전략 중에서 선택할 수 있다. 예를 들어, 동시에 재부팅할 수 있는 클러스터 멤버 수를 구성할 수 있다. 내부적으로 locksmith는 클러스터 멤버에서 실행되는 데몬으로 작동하며, 명령줄 유틸리티는 구성 매개변수를 관리한다. Locksmith는 Go 언어로 작성되었으며 Apache License 2.0의 조건에 따라 배포된다.

컨테이너 리눅스에서 사용되는 업데이트 배포 시스템은 구글(Google)의 오픈 소스 Omaha 프로젝트를 기반으로 하며, 이는 업데이트 롤아웃 메커니즘과 요청-응답 프로토콜을 XML을 기반으로 제공한다. 또한 CoreOS는 클러스터 전체의 업데이트 관리를 위한 웹 기반 대시보드인 CoreUpdate를 제공한다. CoreUpdate를 통해 수행할 수 있는 작업에는 클러스터 멤버를 사용자 지정 업데이트 정책을 공유하는 다른 그룹에 할당하는 작업, 컨테이너 리눅스 버전의 클러스터 전체 분석 검토, 업데이트 중지 및 재시작, 기록된 업데이트 로그 검토 등이 있다. CoreUpdate는 또한 타사 유틸리티 또는 배포 시스템과의 통합을 허용하는 HTTP 기반 API를 제공한다.

3.3. 클러스터 인프라스트럭처

컨테이너 리눅스는 클러스터 구성 정보를 공유하고 관리하기 위해 etcd 분산 키-값 저장소를 사용한다. etcd는 Raft 알고리즘을 기반으로 하여 데이터의 안정성과 일관성을 보장한다. 저장된 데이터의 모든 변경 사항은 전체 클러스터에 반영되며, 단일 클러스터 구성원의 장애로 인한 데이터 손실을 방지한다. etcd는 구성 관리 외에도 배포된 애플리케이션이 자신과 제공하는 서비스를 알릴 수 있도록 서비스 검색 기능을 제공한다. etcd와의 통신은 REST 기반 API를 통해 이루어지며, 내부적으로는 HTTP 상에서 JSON을 사용한다. API는 curl, wget 등을 이용하거나, CoreOS에서 제공하는 `etcdctl` 유틸리티를 통해 사용할 수 있다. etcd는 쿠버네티스에서도 사용된다.

컨테이너 리눅스는 클러스터 수준에서 systemd 인스턴스를 제어하는 `fleet` 클러스터 관리자를 제공했었다. 2017년 기준으로 `fleet`는 더 이상 활발히 개발되지 않으며 쿠버네티스로 대체되었다. `fleet`를 통해 컨테이너 리눅스는 개별 systemd 인스턴스와 클러스터 전체의 etcd 배포를 연결하는 분산 초기화 시스템을 생성했다. `fleetd` 데몬은 D-Bus를 통해 로컬 systemd 인스턴스와 통신하고, 노출된 API를 통해 etcd 배포와 통신했다. `fleetd`를 사용하면 소프트웨어 컨테이너를 클러스터 전체에 단일 또는 여러 개 배포할 수 있었으며, 중복성 (공학), 페일오버, 특정 클러스터 구성원에 대한 배포, 컨테이너 간 종속성 및 컨테이너의 그룹화된 배포를 포함한 더 많은 고급 옵션을 사용할 수 있었다. `fleetctl` 유틸리티는 이 분산 초기화 시스템을 구성하고 모니터링하는 데 사용되었다.

4. 배포 및 지원

컨테이너 리눅스는 베어메탈 서버, 가상 머신, 클라우드 환경 등 다양한 플랫폼에 배포할 수 있다. Amazon EC2, 구글 컴퓨트 엔진, 마이크로소프트 애저 등 주요 클라우드 플랫폼을 지원한다. 전용 하드웨어에서 실행할 때, 컨테이너 리눅스는 SSD와 같은 로컬 저장 장치에 영구적으로 설치하거나, PXE 또는 iPXE를 사용하여 원격으로 네트워크 부팅할 수 있다.

컨테이너 리눅스는 Tectonic이라는 상용 배포판을 통해 쿠버네티스와 통합된 환경을 제공했다. 2015년 4월 기준으로, Tectonic은 일부 고객에게 베타 소프트웨어로 제공되었다. 또한, CoreOS는 쿠버네티스와의 통합에 필요한 오버레이 네트워크를 구현하는 컴포넌트인 Flannel을 제공했다. (현재 Tectonic은 레드햇 오픈시프트(Red Hat OpenShift)로 대체되었다.)