Windows의 컨테이너 플랫폼 도구

Windows 컨테이너 플랫폼이 확장되고 있습니다. Docker는 컨테이너 경험의 첫 번째 부분이며, 이제 다른 컨테이너 플랫폼 도구를 빌드하고 있습니다.

• containerd/cri - Windows Server 2019/Windows 10 1809에서 새롭게 도입된 기능입니다.
• runhcs - runc에 대응하는 Windows 컨테이너 호스트입니다.
• hcs - 호스트 컴퓨팅 서비스 + 편리한 shim을 사용하여 사용하기 쉽습니다.
  • hcsshim
  • dotnet-computevirtualization

이 문서에서는 Windows 및 Linux 컨테이너 플랫폼과 각 컨테이너 플랫폼 도구에 대해 설명합니다.

Windows 및 Linux 컨테이너 플랫폼

Linux 환경에서 Docker와 같은 컨테이너 관리 도구는 더 세분화된 컨테이너 도구 집합(runc 및 컨테이너 )을 기반으로 빌드됩니다.

runc OCI 컨테이너 런타임 사양따라 컨테이너를 만들고 실행하기 위한 Linux 명령줄 도구입니다.

containerd 컨테이너 이미지 다운로드 및 압축 풀기에서 컨테이너 실행 및 감독에 이르는 컨테이너 수명 주기를 관리하는 디먼입니다.

Windows에서는 다른 접근 방식을 사용했습니다. Windows 컨테이너를 지원하기 위해 Docker 작업을 시작했을 때 HCS(호스트 컴퓨팅 서비스)를 직접 빌드했습니다. 이 블로그 게시물 HCS를 빌드한 이유와 컨테이너에 이 접근 방식을 처음 적용한 이유에 대한 정보가 가득합니다.

Windows에서 초기 Docker 엔진 아키텍처Initial Docker Engine architecture on Windows

이 시점에서 Docker는 여전히 HCS에 직접 호출합니다. 그러나 앞으로 Windows 컨테이너 및 Windows 컨테이너 호스트를 포함하도록 확장되는 컨테이너 관리 도구는 Linux에서 컨테이너d와 runc를 호출하는 방식으로 containerd와 runhcs를 호출할 수 있습니다.

runhcs

runhcs는 runc의 포크입니다. runc마찬가지로 runhcs OCI(Open Container Initiative) 형식에 따라 패키지된 애플리케이션을 실행하기 위한 명령줄 클라이언트이며 Open Container Initiative 사양을 준수하는 구현입니다.

runc와 runhcs 간의 기능적 차이점은 다음과 같습니다.

• runhcs Windows에서 실행됩니다. 컨테이너를 만들고 관리하기 위해 HCS 통신합니다.

• runhcs 다양한 컨테이너 유형을 실행할 수 있습니다.

  • Windows 및 Linux Hyper-V 격리
  • Windows 프로세스 컨테이너(컨테이너 이미지는 컨테이너 호스트와 일치해야 합니다.)

사용량:

runhcs run [ -b bundle ] <container-id>

<container-id> 시작하는 컨테이너 인스턴스의 이름입니다. 이름은 컨테이너 호스트에서 고유해야 합니다.

번들 디렉터리(-b bundle사용)는 선택 사항입니다. runc와 마찬가지로 컨테이너는 번들을 사용하여 구성됩니다. 컨테이너의 번들은 컨테이너의 OCI 사양 파일인 "config.json"이 있는 디렉터리입니다. "번들"의 기본값은 현재 디렉터리입니다.

OCI 사양 파일 "config.json"은 올바르게 실행되려면 두 개의 필드가 필요합니다.

• 컨테이너의 스크래치 공간에 대한 경로
• 컨테이너의 계층 디렉터리에 대한 경로

Runhcs에서 사용할 수 있는 컨테이너 명령은 다음과 같습니다.

• 컨테이너를 만들고 실행하는 도구

  • 실행 컨테이너를 만들고 실행합니다.
  • 컨테이너 만들기 만들기

• 컨테이너에서 실행되는 프로세스를 관리하는 도구:

  • 시작 만든 컨테이너에서 사용자 정의 프로세스를 실행합니다.
  • exec 컨테이너 내에서 새 프로세스를 실행합니다.
  • 일시 중지 일시 중지하면 컨테이너 내의 모든 프로세스가 일시 중단됩니다.
  • 다시 시작 이전에 일시 중지된 모든 프로세스를 시작합니다.
  • ps ps는 컨테이너 내에서 실행되는 프로세스를 표시합니다.

• 컨테이너의 상태를 관리하는 도구

  • 상태 컨테이너의 상태를 출력합니다.
  • kill 지정된 신호(기본값: SIGTERM)를 컨테이너의 init 프로세스로 보냅니다.
  • 삭제 분리된 컨테이너와 함께 자주 사용되는 컨테이너에서 보유하는 리소스를 삭제합니다.

다중 컨테이너로 간주될 수 있는 유일한 명령은 목록. 지정된 루트가 있는 runhcs에서 시작된 실행 중이거나 일시 중지된 컨테이너를 나열합니다.

HCS

GitHub에서 HCS와 인터페이스할 수 있는 두 개의 래퍼가 있습니다. HCS는 C API이므로 래퍼를 사용하면 상위 수준 언어에서 HCS를 쉽게 호출할 수 있습니다.

• hcsshim - HCSShim은 Go로 작성되었으며 runhcs의 기초입니다. AppVeyor에서 최신 버전을 사용하거나 직접 빌드하세요.
• dotnet-computevirtualization - dotnet-computevirtualization은 HCS에 대한 C# 래퍼입니다.

직접 또는 래퍼를 통해 HCS를 사용하거나 HCS 주위에 Rust/Haskell/InsertYourLanguage 래퍼를 만들려는 경우 의견을 남겨 주세요.

HCS에 대해 자세히 알아보려면 John Stark의 DockerCon 프레젠테이션시청하세요.

containerd/cri

중요하다

CRI 지원은 Windows Server 2019/Windows 10 1809 이상에서만 사용할 수 있습니다.

OCI 사양은 단일 컨테이너를 정의하지만, CRI(컨테이너 런타임 인터페이스)는 Pod라는 공유 샌드박스 환경에서 컨테이너를 워크로드로 설명합니다. Pod에는 하나 이상의 컨테이너 워크로드가 포함될 수 있습니다. Pod를 사용하면 Kubernetes 및 Service Fabric Mesh와 같은 컨테이너 오케스트레이터가 메모리 및 vNET과 같은 일부 공유 리소스를 사용하여 동일한 호스트에 있어야 하는 그룹화된 워크로드를 처리할 수 있습니다.

runHCS와 컨테이너 둘 다 Windows 시스템 Server 2016 이상에서 관리할 수 있지만 Pod(컨테이너 그룹)를 지원하려면 Windows의 컨테이너 도구에 대한 호환성이 손상되는 변경이 필요했습니다. CRI 지원은 Windows Server 2019/Windows 10 1809 이상에서 사용할 수 있습니다.