[1주차] Sysbox Container Runtime : Systemd-in-Docker

CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 3기

---

 

Sysbox는 원래 Nestybox(2012년 5월 5일 Docker에 인수됨)에서 개발한 오픈소스 무료 컨테이너 런타임(전문화된 "runc")으로, 두 가지 주요 방식으로 컨테이너를 개선합니다:

🧿 컨테이너 격리를 개선합니다:

• 모든 컨테이너의 Linux 사용자 네임스페이스(컨테이너의 루트 사용자는 호스트에 대한 권한이 없음).
• 컨테이너 내부의 procfs 및 sysfs 일부를 가상화합니다.
• 컨테이너 내부의 호스트 정보를 숨깁니다.
• 컨테이너의 초기 마운트 등을 잠급니다.

🧿 컨테이너가 VM과 동일한 워크로드를 실행할 수 있도록 지원합니다:

• Sysbox를 사용하면 컨테이너는 systemd, Docker, Kubernetes, K3s, buildx, 레거시 앱 등과 같은 시스템 수준 소프트웨어를 원활하고 안전하게 실행할 수 있습니다.
• 특별한 버전의 소프트웨어(예: 루트 없는 변종)를 사용하지 않고도 수정 없이 Sysbox 컨테이너 내에서 실행할 수 있습니다.
• 권한이 있는 컨테이너, 복잡한 이미지, 까다로운 진입점, 특별한 볼륨 마운트 등이 필요하지 않습니다.

---

• " container supercharger"라고 생각하면 됩니다. 기존 컨테이너 관리자/오케스트레이터(예: 도커, 쿠버네티스 등)가 격리 기능이 강화되고 VM에서 실행되는 거의 모든 워크로드를 실행할 수 있는 컨테이너를 배포할 수 있게 해줍니다.
• Sysbox는 고급 OS 가상화 기술을 사용하여 컨테이너를 최대한 VM과 유사한 환경으로 만들어 이를 구현합니다.
• Kata 및 KubeVirt와 같은 대체 런타임과 달리 VM을 사용하지 않습니다. 따라서 사용하기 쉽지만(특히 클라우드 환경에서 중첩 가상화를 피함으로써) VM 기반 런타임만큼의 격리 수준은 제공하지 않습니다. 
• Sysbox를 활용하기 위해 새로운 도구를 배우거나 기존 컨테이너 이미지 또는 워크플로를 수정할 필요가 없습니다. 간단히 설치하고 컨테이너 관리자/오케스트레이터를 가리키기만 하면 향상된 컨테이너를 배포할 수 있습니다.
• Sysbox는 동일한 호스트에서 다른 컨테이너 런타임(예: 기본 OCI runc, Kata 등)과 나란히 실행할 수 있습니다. 필요에 따라 각각 어떤 컨테이너 또는 파드를 실행할지 쉽게 선택할 수 있습니다.

---

🧿 Sysbox는 다음과 같은 문제를 해결합니다:

• 컨테이너화된 마이크로서비스의 격리 강화(컨테이너의 루트는 호스트의 권한 없는 사용자에게 매핑됨).
• 호스트 보안을 손상시키지 않고 컨테이너 내부에서 높은 성능의 루트 사용자를 활성화할 수 있습니다.
• 안전하지 않은 권한 컨테이너나 호스트 Docker 소켓 마운트 없이 DinD(Docker-in-Docker) 또는 KinD(Kubernetes-in-Docker)를 활성화하여 CI/CD 파이프라인을 보호합니다.
• 컨테이너를 개발, 로컬 테스트, 학습 등을 위한 '가상 머신과 유사한' 환경으로 사용할 수 있으며, 강력한 격리 기능과 컨테이너 내에서 시스템드, Docker, IDE 등을 실행할 수 있는 기능을 제공합니다.
• 효율성이 떨어지는 VM 대신 컨테이너 내에서 레거시 앱 실행.
• 클라우드 환경 전반에 걸쳐 쉽게 배포할 수 있는 더 쉽고, 더 빠르고, 더 효율적이며, 이동성이 뛰어난 컨테이너 기반 대안으로 VM을 대체할 수 있습니다.
• 베어 메탈 호스트를 VM 밀도가 2배 높은 여러 개의 격리된 컴퓨팅 환경으로 파티셔닝(즉, 동일한 하드웨어에서 동일한 성능의 VM보다 2배 더 많은 VM과 유사한 컨테이너를 배포)할 수 있습니다.
• 값비싼 중첩 가상화를 사용하지 않고도 클라우드 인스턴스(예: EC2, GCP 등)를 여러 개의 격리된 컴퓨팅 환경으로 파티셔닝할 수 있습니다.

---

✅ 작동 방식

• Sysbox는 Linux 호스트(베어메탈, 가상머신, 온프레미스, 클라우드 등)에 쉽게 설치할 수 있습니다.
• 모든 주요 클라우드 기반 IaaS 및 Kubernetes 서비스(예: EC2, GCP, GKE, EKS, AKS, Rancher 등)에서 작동합니다.
• 설치되면 Sysbox는 Docker, Kubernetes 등을 사용하여 컨테이너를 배포하는 데 사용됩니다.

---

✅ 개념 및 용어

🧿 Container Runtime

• 컨테이너의 설정과 루트 파일 시스템(컨테이너의 내용을 담고 있는 디렉터리)을 받아 리눅스 커널과 상호작용하여 컨테이너를 생성하는 소프트웨어를 컨테이너 런타임이라고 합니다.
• Sysbox 와 OCI runc가 컨테이너 런타임의 예시입니다.
• 컨테이너 런타임에게 컨테이너의 설정과 루트 파일 시스템을 제공하는 주체는 일반적으로 컨테이너 매니저(예: Docker, containerd)입니다.

🧿 Container Manager

• 컨테이너 매니저는 컨테이너의 수명 주기를 관리합니다.
• 여기에는 이미지 전송 및 저장부터 컨테이너 실행(컨테이너 런타임과의 상호작용을 통해)까지의 과정이 포함됩니다.
• 예시로는 Docker, containerd 등이 있습니다.
• OCI 런타임 사양은 컨테이너 매니저와 컨테이너 런타임 간의 인터페이스를 설명합니다.

🧿 System Container

Sysbox가 배포하는 컨테이너를 시스템 컨테이너라고 부르는 이유는, 이들이 일반 컨테이너처럼 마이크로서비스뿐만 아니라 Docker, Kubernetes, Systemd, 내부 컨테이너 등과 같은 시스템 소프트웨어도 실행할 수 있기 때문입니다.전통적으로 컨테이너는 하나의 애플리케이션이나 마이크로서비스만을 패키징합니다. 이는 여러 개의 컨테이너가 애플리케이션을 구성하고, 책임을 분리하는 것이 중요한 애플리케이션 컨테이너에 적합한 방식입니다.그러나 시스템 컨테이너는 이와 약간 다릅니다. 시스템 컨테이너는 가볍고 매우 효율적인 "가상 호스트"로 사용되며, 일반적으로 여러 서비스를 함께 번들로 묶어 실행합니다.시스템 컨테이너 내에서는 Systemd, sshd, Docker 등 원하는 서비스를 실행할 수 있으며, 물리적 호스트나 VM에서처럼 (내부) 컨테이너를 실행할 수도 있습니다. 이를 "가상 호스트" 또는 "컨테이너 안의 컨테이너"라고 생각할 수 있습니다.물론, 원하는 경우 단일 서비스(예: Docker 데몬)만 패키징할 수도 있습니다. 선택은 사용자에게 달려 있습니다.시스템 컨테이너는 여러 상황에서 VM에 대한 대안을 제공하지만, 훨씬 유연하고 효율적이며 이동성이 뛰어납니다. 강력한 격리 기능을 제공하지만, 그 격리 수준은 VM보다는 약간 낮습니다(그러나 일반 Docker 컨테이너보다는 강력합니다).Sysbox는 시스템 컨테이너를 생성하는 컨테이너 런타임입니다.

🧿 Inner and Outer Containers

• 시스템 컨테이너 안에서 Docker를 실행할 때, 컨테이너가 중첩되어 용어가 혼란스러울 수 있습니다.혼란을 방지하기 위해, 우리는 컨테이너를 "외부"와 "내부" 컨테이너로 구분합니다.
• 외부 컨테이너는 시스템 컨테이너로, 호스트 수준에서 생성됩니다. 이는 Docker와 Sysbox를 사용해 실행됩니다.
• 내부 컨테이너는 애플리케이션 컨테이너로, 외부 컨테이너 안에서 생성됩니다(예: 시스템 컨테이너 안에서 실행 중인 Docker나 Kubernetes 인스턴스가 생성합니다)

 

---

✅ Sysbox 패키지로 설치

• 릴리스 페이지에서 최신 Sysbox 패키지를 다운로드

• 다운로드한 파일의 체크섬이 예상/게시된 파일과 완전히 일치하는지 확인

• 호스트에서 Docker가 실행 중인 경우 다음과 같이 모든 Docker 컨테이너를 중지하고 제거하는 것이 좋습니다(오류가 반환되면 단순히 기존 컨테이너를 찾을 수 없음을 나타냅니다):
  
  • 이 방법은 Sysbox 설치 관리자가 Docker를 구성하고 다시 시작해야 할 수 있으므로(Docker가 Sysbox를 인식하도록 하기 위해) 권장됩니다. 

• Sysbox 패키지를 설치하고 설치 관리자 지침을 따릅니다:
  • jq 도구는 Sysbox 설치 관리자에서 사용합니다.

• Sysbox 관련 데몬이 제대로 실행되고 있는지 확인

• 설치하는 동안 Sysbox 설치 관리자는 Docker가 실행 중인지 감지하고 Docker 데몬이 Sysbox 런타임을 감지하도록 재구성합니다.
  • 이를 위해 /etc/docker/daemon.json에 다음 구성을 추가하고 Docker에 신호(SIGHUP)를 전송합니다:

• 모든 것이 정상이면 Docker가 Sysbox 런타임을 인식합니다:

• docker network 대역이 기존 172.17.0.0/16 -> 172.20.0.0/16 으로 변경됨

 

---

✅ Systemd-in-Docker [ v0.1.2+ ]

• 복잡한 컨테이너 구성 없이 Docker 컨테이너 또는 K8s 포드 내에서 Systemd를 쉽게 실행할수 있습니다.
• Systemd에 의존하는 앱을 컨테이너화할 수 있습니다.
  
  
• System container 는 여러 서비스를 실행할 수 있는 가상 호스트 환경 역할을 할 수 있습니다.
• 컨테이너 안에 Systemd와 같은 프로세스 관리자를 포함하는 것이 유용합니다.
• Systemd는 서비스의 시작과 정지 순서를 관리하거나, 좀비 프로세스를 정리하는 등의 작업을 수행하는 데 도움을 줍니다.
• 많은 애플리케이션들이 제대로 작동하기 위해 Systemd에 의존합니다. 이는 특히 레거시(클라우드가 아닌) 애플리케이션뿐만 아니라 Kubernetes와 같은 클라우드 네이티브 소프트웨어에도 해당됩니다. 이러한 애플리케이션을 컨테이너에서 실행하려면 Systemd가 컨테이너 안에 있어야 합니다.

• v0.1.2 버전부터 Sysbox는 시스템 컨테이너 내에서 Systemd를 실행할 수 있는 초기 지원을 제공합니다.
• Sysbox를 사용하면 Systemd-in-Docker를 간편하고 안전하게 실행할 수 있으며, 복잡한 Docker 실행 명령이나 특수한 이미지 엔트리 포인트를 만들 필요가 없고, privileged Docker 컨테이너를 사용할 필요도 없습니다.
• Systemd를 엔트리 포인트로 설정한 시스템 컨테이너 이미지를 실행하면 Sysbox가 시스템 컨테이너를 문제없이 Systemd가 실행될 수 있도록 설정해 줍니다..

---

🧿 내부에 Systemd가 포함된 System Container 배포

System Container  내부에 Systemd를 배포하는 것은 System Container 내에서 여러 서비스를 실행하거나 가상 호스트 환경으로 사용하려는 경우에 유용합니다.
여기서는 Ubuntu Bionic + Systemd 가 포함된 System Container 이미지를 사용하겠습니다. 

이 이미지는 nestybox/ubuntu-bionic-systemd 라고 하며 Nestybox DockerHub 리포지토리에 있습니다.

 

https://github.com/nestybox/dockerfiles/blob/master/ubuntu-bionic-systemd/Dockerfile

dockerfiles/ubuntu-bionic-systemd/Dockerfile at master · nestybox/dockerfiles

 

• System Container 를 시작합니다:

docker run --runtime=sysbox-runc --rm -it --hostname=syscont nestybox/ubuntu-bionic-systemd

 

• 컨테이너에 로그인합니다:
  • System Container  이미지에서 기본 콘솔 로그인 및 비밀번호 : admin/admin

• systemd가 올바르게 실행되고 있는지 확인합니다:

$ ps -fu root
$ systemctl

 

• 시스템 컨테이너를 종료하려면 ctrl-p ctrl-q 를 눌러 System Container 를 종료할 수 있습니다. 
• 그런 다음 호스트에서 docker stop 명령을 사용하여 System Container 를 중지할 수 있습니다.