KR20190044098A - 컨테이너를 액세스하는데 사용하기 위한 방법 및 디바이스 - Google Patents

컨테이너를 액세스하는데 사용하기 위한 방법 및 디바이스 Download PDF

Info

Publication number
KR20190044098A
KR20190044098A KR1020197009003A KR20197009003A KR20190044098A KR 20190044098 A KR20190044098 A KR 20190044098A KR 1020197009003 A KR1020197009003 A KR 1020197009003A KR 20197009003 A KR20197009003 A KR 20197009003A KR 20190044098 A KR20190044098 A KR 20190044098A
Authority
KR
South Korea
Prior art keywords
container
driver
target
target container
instances
Prior art date
Application number
KR1020197009003A
Other languages
English (en)
Other versions
KR102176298B1 (ko
Inventor
창 후앙
웨이 장
Original Assignee
후아웨이 테크놀러지 컴퍼니 리미티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 후아웨이 테크놀러지 컴퍼니 리미티드 filed Critical 후아웨이 테크놀러지 컴퍼니 리미티드
Publication of KR20190044098A publication Critical patent/KR20190044098A/ko
Application granted granted Critical
Publication of KR102176298B1 publication Critical patent/KR102176298B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

본 출원은 컨테이너 액세스 방법 및 장치를 개시한다. 이러한 방법은, 컨테이너 액세스 요청을 수신하는 단계- 컨테이너 액세스 요청은 타겟 컨테이너를 액세스하라고 요청하는데 사용됨 -; 다수의 현재 실행 중인 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계- 다수의 드라이버 인스턴스들에서의 상이한 드라이버 인스턴스들은 상이한 타입들의 컨테이너들을 구동하는데 사용되고, 다수의 드라이버 인스턴스들은 동일한 프로그램을 사용하여 관리됨 -; 및 타겟 컨테이너에 대응하는 드라이버 인스턴스에 컨테이너 액세스 요청을 전송하는 단계를 포함한다. 이러한 해결책에서는, 상이한 타입들의 컨테이너들을 구동하는데 사용되는 드라이버 인스턴스들을 하나의 프로그램이 관리하므로, 사용자는 하나의 프로그램을 사용하여 상이한 타입들의 다수의 컨테이너들을 액세스할 수 있다. 이것은 상이한 타입들의 컨테이너들이 상이한 프로그램들을 사용하여 관리되는 상이한 드라이버 인스턴스들을 사용하여 액세스되는 종래 기술 문제를 회피하고, 컨테이너 엔진에서 다수의 드라이버 인스턴스들을 관리하는 프로그램의 실행 오버헤드들을 감소시킨다.

Description

컨테이너를 액세스하는데 사용하기 위한 방법 및 디바이스
본 출원은 2016년 9월 7일자로 중국 특허청에 출원되고 명칭이 "CONTAINER ACCESS METHOD AND APPARATUS"인 중국 특허 출원 제201610806797.3호에 대한 우선권을 주장하고, 이는 그 전부가 본 명세서에서 참조로 원용된다.
<기술 분야>
본 출원의 실시예들은 컴퓨터 분야에 관한 것으로, 특히, 컨테이너 액세스 방법 및 장치에 관한 것이다.
컨테이너를 관리하는데 컨테이너 엔진이 사용될 수 있다. 사용자는 하나의 컨테이너 엔진, 예를 들어, Linux 컨테이너 및 컨테이너 가상 머신을 사용하여 다수의 타입들의 컨테이너들을 실행할 수 있다. 그러나, 상이한 타입들의 다수의 컨테이너들이 하나의 컨테이너 엔진을 사용하여 관리될 때, 상이한 타입들의 컨테이너들을 구동하기 위해 사용되는 드라이버 인스턴스들은 상이한 프로그램들을 사용하여 관리될 필요가 있다. 이러한 경우, 컨테이너 엔진에서 상이한 타입들의 컨테이너들을 구동하기 위해 사용되는 드라이버 인스턴스들을 관리하는 프로그램들의 실행 오버헤드들이 증가된다. 다음은 컨테이너 엔진 Docker를 예로서 사용하여 상세한 설명들을 제공한다.
Docker는 개방-소스 컨테이너 엔진이고, 애플리케이션의 자동 배치 솔루션을 제공하도록 의도된다. Linux 컨테이너 기술에 기초하여, Docker는 다수의 기술들 및 혁신들을 조합하므로, 컨테이너의 애플리케이션이 매우 편리하고 효율적이다. Docker는 이미지(image) 및 이미지 레지스트리와 같은 개념들을 제안하므로, 애플리케이션이 편리하게 수립, 실행 및 이동될 수 있고, 주변 에코시스템이 도출되고, 애플리케이션 배치 및 배포 동안 작업 부하 및 복잡성이 매우 감소된다. Docker는 Linux 컨테이너 기술의 개발을 매우 촉진하고, 최근 수년 Linux 컨테이너 기술 애플리케이션의 모델 및 실제 산업 표준이 된다.
도 1은 Docker 아키텍처의 개략 블록도를 도시한다. Docker 데몬(Daemon)이 시작될 때, 컨테이너의 실행 드라이버(execution driver)의 타입이 명시될 필요가 있다는 점을 도 1에 도시되는 Docker 아키텍처로부터 알 수 있다. 즉, 실행 드라이버는 네이티브/컨테이너(Native/run container, Native/runc) 드라이버 인스턴스(즉, Docker에서의 디폴트 드라이버 인스턴스) 및 Linux 컨테이너(Linux Container, LXC) 드라이버 인스턴스로부터 선택될 필요가 있다. Native/runc 드라이버 인스턴스의 선택은 도 1의 설명을 위한 예로서 사용된다. Native/runc 드라이버 인스턴스가 선택된 이후에, Native/runc 드라이버 인스턴스가 초기화된다. 후속적으로 실행되는 모든 컨테이너들은 Native/runc 드라이버 인스턴스에 의해 구동되고, Native/runc 드라이버 인스턴스는 Native/runc 드라이버 인스턴스에 대응하는 단 하나의 타입의 컨테이너만 구동할 수 있다. 즉, Docker 데몬 및 실행 드라이버가 "강하게 구속하는(strongly binding)" 관계에 있기 때문에, 단 하나의 타입의 컨테이너만 호스트의 Docker 데몬 상에서 실행될 수 있다. 다른 타입의 컨테이너가 실행될 필요가 있을 때, 다른 Docker 데몬이 실행될 필요가 있다. 이러한 경우, Docker에서의 Docker 데몬의 실행 오버헤드들이 증가된다.
본 출원은, 컨테이너 엔진에서 상이한 타입들의 컨테이너들을 구동하는데 사용되는 드라이버 인스턴스들을 관리하는 프로그램의 실행 오버헤드들을 감소시키기 위한, 예를 들어, Docker에서의 Docker 데몬의 실행 오버헤드들을 감소시키기 위한, 컨테이너 액세스 방법 및 장치를 제공한다.
제1 양태에 따르면, 컨테이너 액세스 방법이 제공되고, 이는, 컨테이너 액세스 요청을 수신하는 단계- 컨테이너 액세스 요청은, 예를 들어, Docker 클라이언트(Client)에 의해 전송될 수 있고, 컨테이너 액세스 요청은 타겟 컨테이너를 액세스하라고 요청하는데 사용됨 -; 다수의 현재 실행 중인 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계- 다수의 드라이버 인스턴스들에서의 상이한 드라이버 인스턴스들은 상이한 타입들의 컨테이너들을 구동하는데 사용되고, 다수의 드라이버 인스턴스들은 동일한 프로그램을 사용하여 관리되고, 예를 들어, 다수의 드라이버 인스턴스들은 모두 Docker 데몬 Daemon을 사용하여 관리됨 -; 및 타겟 컨테이너에 대응하는 드라이버 인스턴스에 컨테이너 액세스 요청을 전송하는 단계를 포함한다.
구체적으로, 다수의 드라이버 인스턴스들 각각은 하나의 드라이버 프로그램에 대응하고, 상이한 타입들의 컨테이너들을 구동하는데 상이한 드라이버 프로그램들이 사용된다.
이러한 방법은 라우터(router)에 의해 수행될 수 있고, 이러한 라우터는 실행 드라이버에서 설정될 수 있고, 사용자에 의해 전송되는 컨테이너 액세스 요청을 스케줄링하도록 구성된다는 점이 주목되어야 한다.
다수의 드라이버 인스턴스들이 동일한 프로그램을 사용하여 관리되는 것은 다수의 드라이버 인스턴스들이 동일한 데몬을 사용하여 관리되는 것일 수 있고, 이러한 데몬은 운영 체제에서의 백그라운드 서비스 프로세스, 예를 들어, Docker에서의 Docker 데몬일 수 있다는 점이 이해되어야 한다.
이러한 해결책에서는, 상이한 타입들의 컨테이너들을 구동하는데 사용되는 드라이버 인스턴스들을 하나의 프로그램이 관리하므로, 사용자는 하나의 프로그램을 사용하여 상이한 타입들의 다수의 컨테이너들을 액세스할 수 있다. 이것은 상이한 타입들의 컨테이너들이 상이한 프로그램들을 사용하여 관리되는 상이한 드라이버 인스턴스들을 사용하여 액세스되는 종래 기술 문제를 회피하고, 컨테이너 엔진에서 다수의 드라이버 인스턴스들을 관리하는 프로그램의 실행 오버헤드들을 감소시킨다.
추가로, 컨테이너 엔진이 Docker일 때, 이러한 해결책에서는, 상이한 타입들의 컨테이너들을 구동하는데 사용되는 드라이버 인스턴스들을 하나의 Docker 데몬이 관리할 수 있으므로, 사용자는 하나의 Docker 데몬을 사용하여 상이한 타입들의 다수의 컨테이너들을 액세스할 수 있다. 이것은 상이한 타입들의 컨테이너들이 상이한 Docker 데몬들을 사용하여 관리되는 상이한 드라이버 인스턴스들을 사용하여 액세스되는 종래 기술 문제를 회피하고, Docker 시스템에서 Docker 데몬의 실행 오버헤드들을 감소시킨다.
또한, 하나의 Docker 데몬 및 하나의 세트의 Docker 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 사용하여 다수의 타입들의 컨테이너들이 액세스될 수 있으므로, Docker 데몬을 사용하여 컨테이너를 액세스하는 유연성이 증가될 수 있다.
선택적으로, 컨테이너 액세스 요청을 수신하는 단계는, Docker 데몬을 사용하여, Docker 클라이언트(Client)에 의해 전송되는 컨테이너 액세스 요청을 수신하는 단계를 추가로 포함한다.
구체적으로, 라우터가 위치되는 실행 드라이버 및 Docker 데몬이 2개의 독립적인 프로세스들일 때, 라우터는 Docker 데몬을 사용하여 컨테이너 액세스 요청을 수신할 수 있다.
이러한 해결책에서는, 라우터가 위치되는 실행 드라이버 및 Docker 데몬은 2개의 독립적인 프로세스들로 분리되어, 후속하는 사용 동안 실행 드라이버 및 Docker 데몬의 유지 보수를 용이하게 한다.
제1 양태를 참조하여, 제1 양태의 제1 가능한 구현에서, 이러한 방법은, 컨테이너 실행 요청을 수신하는 단계- 컨테이너 액세스 요청은, 예를 들어, Docker 클라이언트에 의해 전송될 수 있고, 컨테이너 실행 요청은 타겟 컨테이너에 대응하는 드라이버 인스턴스의 타입을 운반함 -; 타겟 컨테이너에 대응하는 드라이버 인스턴스의 타입에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계; 및 컨테이너 실행 요청을 타겟 컨테이너에 대응하는 드라이버 인스턴스에 전송하는 단계를 추가로 포함한다.
이러한 해결책에서는, 상이한 타입들의 컨테이너들을 구동하는데 사용되는 드라이버 인스턴스들을 하나의 프로그램이 관리하므로, 사용자는 하나의 프로그램을 사용하여 상이한 타입들의 다수의 컨테이너들을 실행할 수 있다. 이것은 상이한 타입들의 컨테이너들이 상이한 프로그램들을 사용하여 관리되는 상이한 드라이버 인스턴스들을 사용하여 액세스되는 종래 기술 문제를 회피하고, 컨테이너 엔진에서 다수의 드라이버 인스턴스들을 관리하는 프로그램의 실행 오버헤드들을 감소시킨다.
추가로, 컨테이너 엔진이 Docker일 때, 이러한 해결책에서는, 상이한 타입들의 컨테이너들을 구동하는데 사용되는 드라이버 인스턴스들을 하나의 Docker 데몬이 관리하므로, 사용자는 하나의 Docker 데몬을 사용하여 상이한 타입들의 다수의 컨테이너들을 실행할 수 있다. 이것은 상이한 타입들의 컨테이너들이 상이한 Docker 데몬들을 사용하여 관리되는 상이한 드라이버 인스턴스들을 사용하여 액세스되는 종래 기술 문제를 회피하고, Docker 시스템에서 Docker 데몬의 실행 오버헤드들을 감소시킨다.
또한, 하나의 Docker 데몬 및 하나의 세트의 Docker 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 사용하여 다수의 타입들의 컨테이너들이 실행될 수 있으므로, Docker 데몬을 사용하여 컨테이너를 관리하는 유연성이 증가된다.
선택적으로, 컨테이너 액세스 요청을 수신하는 단계는, 컨테이너 액세스 요청을 수신하는 단계- 컨테이너 액세스 요청은 타겟 컨테이너의 컨테이너 IP를 운반함 -를 포함하고; 다수의 현재 실행 중인 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계는, 타겟 컨테이너의 컨테이너 IP에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계를 포함한다.
이러한 해결책에서는, 타겟 컨테이너의 컨테이너 IP는 컨테이너 액세스 요청에서 운반되고, 타겟 컨테이너는 타겟 컨테이너의 컨테이너 IP에 따라 액세스된다.
제1 양태 또는 전술한 가능한 구현들 중 어느 하나를 참조하여, 제1 양태의 가능한 구현에서, 컨테이너 액세스 요청을 수신하는 단계는, 컨테이너 액세스 요청을 수신하는 단계- 컨테이너 액세스 요청은 타겟 컨테이너의 컨테이너 ID를 운반함 -를 포함하고; 다수의 현재 실행 중인 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계는, 타겟 컨테이너의 컨테이너 ID에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계를 포함한다.
구체적으로, 드라이버 인스턴스는, 컨테이너 액세스 요청에서 운반되는 타겟 컨테이너의 컨테이너 ID에 따라, 컨테이너 액세스 요청을 사용하여 액세스되는 타겟 컨테이너를 결정할 수 있고, 드라이버 인스턴스는 컨테이너 액세스 요청을 타겟 컨테이너에 전송한다.
이러한 해결책에서는, 타겟 컨테이너의 컨테이너 ID는 컨테이너 액세스 요청에서 운반되고, 컨테이너 액세스 요청을 사용하여 액세스되는 타겟 컨테이너는 컨테이너 ID에 따라 결정되므로, 사용자가 타겟 컨테이너를 액세스한다.
선택적으로, 컨테이너 액세스 요청은 타겟 컨테이너의 컨테이너 ID 및 타겟 컨테이너의 컨테이너 타입을 운반할 수 있고, 타겟 컨테이너에 대응하는 드라이버 인스턴스는 타겟 컨테이너의 컨테이너 타입에 따라 다수의 드라이버 인스턴스들로부터 선택될 수 있다.
구체적으로, 드라이버 인스턴스는, 컨테이너 ID에 따라, 컨테이너 액세스 요청을 사용하여 액세스될 필요가 있는 타겟 컨테이너를 결정할 수 있고, 드라이버 인스턴스는 컨테이너 액세스 요청을 타겟 컨테이너에 전송한다.
이러한 해결책에서는, 컨테이너 액세스 요청은 타겟 컨테이너의 컨테이너 타입 및 컨테이너 ID를 운반하고, 타겟 컨테이너가 액세스된다. 컨테이너 액세스 요청이 타겟 컨테이너의 컨테이너 ID만을 운반하는 실시예와 비교하여, 컨테이너 ID와 컨테이너 타입 사이의 매핑 관계를 저장하기 위해 사용되는 저장 공간(또는 컨테이너 ID와 컨테이너 타입 사이의 매핑 관계)이 컨테이너 엔진(예를 들어, Docker)에 저장된다.
제1 양태 또는 전술한 가능한 구현들 중 어느 하나를 참조하여, 제1 양태의 가능한 구현에서, 타겟 컨테이너의 컨테이너 ID에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계는, 타겟 컨테이너의 컨테이너 ID 및 컨테이너 ID와 컨테이너 타입 사이의 매핑 관계에 따라 타겟 컨테이너의 컨테이너 타입을 결정하는 단계; 및 타겟 컨테이너의 컨테이너 타입 및 컨테이너 타입과 드라이버 인스턴스 타입 사이의 매핑 관계에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계를 포함한다.
이러한 해결책에서는, 타겟 컨테이너에 대응하는 드라이버 인스턴스는 컨테이너 ID와 컨테이너 타입 사이의 매핑 관계 및 컨테이너 타입과 드라이버 인스턴스 타입 사이의 매핑 관계를 사용하여 결정되므로, 사용자는 타겟 컨테이너에 대응하는 드라이버 인스턴스를 사용하여 타겟 컨테이너를 액세스한다.
제1 양태 또는 전술한 가능한 구현들 중 어느 하나를 참조하여, 제1 양태의 가능한 구현에서, 타겟 컨테이너의 컨테이너 ID에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계는, 타겟 컨테이너의 컨테이너 ID 및 컨테이너 ID와 드라이버 인스턴스 타입 사이의 매핑 관계에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계를 포함한다.
이러한 해결책에서는, 타겟 컨테이너에 대응하는 드라이버 인스턴스는 컨테이너 ID와 드라이버 인스턴스 타입 사이의 매핑 관계를 사용하여 결정되므로, 사용자는 타겟 컨테이너에 대응하는 드라이버 인스턴스를 사용하여 타겟 컨테이너를 액세스한다.
제2 양태에 따르면, 컨테이너 액세스 장치가 제공되고, 이러한 장치는 제1 양태에서의 방법을 수행하도록 구성되는 모듈들을 포함한다.
제3 양태에 따르면, 본 출원은 컨테이너 액세스 장치를 제공하고, 이러한 장치는, 메모리, 프로세서, 입력/출력 인터페이스, 통신 인터페이스, 및 버스 시스템을 포함한다. 메모리, 프로세서, 입력/출력 인터페이스, 및 통신 인터페이스는 버스 시스템을 사용하여 서로 접속된다. 메모리는 명령어를 저장하도록 구성된다. 프로세서는 메모리에 저장되는 명령어를 실행하도록 구성된다. 명령어가 실행될 때, 프로세서는 통신 인터페이스를 사용하여 제1 양태의 방법을 실행하고, 입력 데이터 및 정보를 수신하도록 그리고 동작 결과와 같은 데이터를 출력하도록 입력/출력 인터페이스를 제어한다.
제4 양태에 따르면, 본 출원은 컴퓨터 판독 가능 저장 매체를 제공하고, 이러한 컴퓨터 판독 가능 저장 매체는 탐색 요청 전송 방법의 프로그램 코드를 저장하도록 구성되고, 이러한 프로그램 코드는 제1 양태에서의 방법 명령어를 실행하는데 사용된다.
일부 구현들에서, 드라이버 인스턴스는 실행 드라이버에서의 드라이버 서브-모듈일 수 있다.
일부 구현들에서, 다수의 드라이버 인스턴스들이 동일한 프로그램을 사용하여 관리되는 것은 다수의 드라이버 인스턴스들이 동일한 프로세스를 사용하여 관리되는 것을 포함할 수 있다.
도 1은 Docker 아키텍처의 개략 블록도를 도시한다.
도 2는 본 출원의 실시예에 따른 컨테이너 액세스 방법에서 사용되는 Docker 시스템 아키텍처의 개략 블록도를 도시한다.
도 3은 본 출원의 실시예에 따른 컨테이너 액세스 방법에서 사용되는 다른 Docker 시스템 아키텍처의 개략 블록도를 도시한다.
도 4는 본 출원의 실시예에 따른 컨테이너 액세스 방법의 개략 흐름도를 도시한다.
도 5는 본 출원의 실시예에 따른 컨테이너 액세스 장치의 개략 블록도를 도시한다.
도 6은 본 출원의 다른 실시예에 따른 컨테이너 액세스 장치의 개략 블록도를 도시한다.
다음은 첨부 도면들을 참조하여 본 출원의 기술적 해결책들을 설명한다.
Docker 아키텍처에서의 LXC 기술은 경량 가상화 기술이고, LXC 기술의 원리는 운영 체제에서의 커널에 기초하여 상이한 실행 프로세스들에 대해 상이한 시스템 뷰들을 제공하는 것이다. 이러한 격리에서, 보안성 및 효율성이 보장될 때 하드웨어 리소스에 대한 액세스가 인가될 수 있다. 현재, LXC들은 커널 네임스페이스(namespace)를 사용하여 분리된다, 즉, 다수의 LXC들이 실제로 하나의 커널을 여전히 공유한다. 종래의 가상화 기술과 비교하여, LXC 기술은 더 낮은 손실 및 더 양호한 성능을 갖지만, 불충분한 격리 및 보안성의 단점들을 갖는다. 비교적 높은 보안성 요건을 갖는 애플리케이션에 대해 서비스를 제공할 때, LXC는 애플리케이션의 보안성 요건을 충족시킬 수 없다.
따라서, 비교적 높은 보안성 요건을 갖는 애플리케이션에 대해 서비스가 제공될 때, 컨테이너 가상 머신이 선택될 수 있다. 본질적으로, 컨테이너 가상 머신은, 가상 운영 체제 시뮬레이터(QEMU)와 같은, 종래의 가상화 기술, 및 Docker 에코시스템에서의 이미지 또는 레지스트리와 같은 애플리케이션을 조합하므로, 가상 머신이 LXC처럼 사용될 수 있다. 가상 머신은 사용자에 대한 커널을 포함하는 완전한 시스템 이미지를 제공할 수 있고, 따라서 LXC와 비교하여 일부 애플리케이션들의 비교적 높은 보안성 요건들을 충족시킬 수 있다.
따라서, 애플리케이션들의 보안성 요건들에 따라 상이한 애플리케이션들에 대해 컨테이너 또는 컨테이너 가상 머신이 선택될 수 있다. 단 하나의 타입의 드라이버 인스턴스만 매번 하나의 Docker 데몬에 대해 실행될 수 있는 종래 기술에서 야기되는, 상이한 타입들의 컨테이너들이 하나의 Docker 데몬을 실행하여 액세스될 수 없다는 문제를 해결하기 위해, 본 출원의 실시예는, 상이한 타입들의 드라이버 인스턴스들이 Docker 데몬을 사용하여 관리되는 아이디어를 제안하여, 상이한 타입들의 컨테이너 인스턴스들이 하나의 Docker 데몬을 실행하여 액세스되는 해결책을 구현한다.
이해의 용이함을 위해, 본 출원의 실시예에 따른 컨테이너 액세스 방법에서 사용되는 Docker 시스템 아키텍처의 개략 블록도가 도 2를 참조하여 먼저 간단히 설명된다. 도 2에 도시되는 클라이언트는 Docker 클라이언트일 수 있고, 데몬은 Docker 데몬일 수 있고, 실행 드라이버 프로그램은 실행 드라이버일 수 있다. 실행 드라이버는 상이한 타입들의 드라이버 인스턴스들을 포함한다.
Native/runc, LXC 및 runv는 도 2에서의 설명을 위한 구체적인 드라이버 인스턴스들로서 단지 사용되고, 드라이버 인스턴스들은 다른 타입의 드라이버 인스턴스를 포함할 수 있다는 점이 이해되어야 한다. 다른 타입의 컨테이너가 또한 도 2에 도시되는 Docker 아키텍처에서 실행되고 액세스될 수 있다.
도 2는 Docker 시스템 아키텍처에서 이러한 애플리케이션에 관련된 모듈들만을 도시한다는 점이 또한 이해되어야 한다. 도 2에 도시되는 시스템 아키텍처는 Docker 시스템 아키텍처에 다른 모듈을 추가로 포함할 수 있고, 이것이 본 출원에서 구체적으로 제한되는 것은 아니다.
도 2에 도시되는 Docker 아키텍처에서, Docker 데몬, 실행 드라이버, 드라이버 인스턴스들, 및 컨테이너들은 물리적 호스트 상에 있을 수 있다는 점이 또한 이해되어야 한다. 대안적으로, Docker 데몬, 실행 드라이버, 드라이버 인스턴스들, 및 컨테이너들은 가상 머신 상에 있을 수 있다. Docker 클라이언트 및 Docker 데몬은 하나의 물리적 호스트 또는 가상 머신 상에 있을 수 있거나, 또는 상이한 물리적 호스트들 또는 상이한 가상 머신들 상에 있을 수 있고, 이것이 본 출원에서 구체적으로 제한되는 것은 아니다.
"강하게 구속하는(strongly binding)" 관계가 실행 드라이버 레이어에서 Docker 데몬과 드라이버 인스턴스 사이에 수립되지는 않지만, Docker 데몬이 실행 드라이버 레이어에서 드라이버 인스턴스들을 관리하기 위한 "관리자(manager)"로서 역할을 한다는 점을 도 2에 도시되는 Docker 아키텍처로부터 알 수 있다.
Docker 데몬은 종래 기술을 사용하여 실행 드라이버 레이어에서 드라이버 인스턴스들을 초기화거나, 실행 드라이버 레이어에서 상이한 타입들의 드라이버 인스턴스들을 순차적으로 초기화하거나, 또는 다른 방식으로 실행 드라이버 레이어에서 상이한 타입들의 드라이버 인스턴스들을 초기화할 수 있다는 점이 주목되어야 한다. 이러한 것이 본 출원에서 구체적으로 제한되는 것은 아니다.
사용자는 Docker 클라이언트를 사용하여 Docker 데몬과의 통신을 수립할 수 있고, 요청을 Docker 데몬에 전송할 수 있다. 이러한 요청은 컨테이너 액세스 요청, 컨테이너 실행 요청 등을 포함할 수 있다. Docker 시스템 아키텍처에서의 주요 부분으로서, Docker 데몬은 먼저 Docker 서버의 기능을 제공하고, Docker 클라이언트에 의해 전송되는 요청을 수신하고, 다음으로 Docker 데몬에서의 실행 엔진(Engine)에 요청을 전송할 수 있다. 이러한 엔진은 Docker에서 일련의 작업을 실행할 수 있고, 각각의 작업은 잡의 형태로 존재할 수 있다, 즉, 잡은 엔진에서 가장 기본적인 작업 실행 유닛으로서 고려될 수 있다.
엔진이 잡을 실행할 때, 그리고 컨테이너 이미지가 필요할 때, 잡은 Docker 레지스트리로부터 이미지를 다운로드하고, 다운로드된 이미지를 이미지 관리 드라이버(Graph driver)를 사용하여 이미지(a graph)의 형태로 저장할 수 있다. 네트워크 환경이 Docker에 대해 수립될 필요가 있을 때, 잡은 네트워크 관리 드라이버(network driver)를 사용하여 컨테이너의 네트워크 환경을 수립하고 구성할 수 있다. 컨테이너 실행 리소스들이 제한될 필요가 있거나 또는 사용자 명령어가 실행될 필요가 있을 때, 잡은 실행 드라이버 프로그램(Execution driver)을 실행하여 전술한 동작을 완료할 수 있다.
Docker는 립컨테이너(libcontainer), 즉, 독립적인 컨테이너 관리 패키지를 직접 호출하여, 컨테이너의 네임스페이스(namespace), 제어 그룹(control group, cgroup), 네트워크 디바이스, 방화벽 규칙 등을 최종적으로 동작시킬 수 있다.
컨테이너 실행 요청이 실행된 이후, 실제 컨테이너는 실행 상태에 있고, 이러한 컨테이너는 독립적인 파일 시스템, 독립적이고 비교적 안전한 실행 환경 등을 가질 수 있다.
도 3은 본 출원의 실시예에 따른 컨테이너 액세스 방법에서 사용되는 다른 Docker 시스템 아키텍처의 개략 블록도를 도시한다. 도 3에 도시되는 Docker 아키텍처에서의 모듈들의 기능들은 도 2에 도시되는 모듈들의 기능들과 동일하고, Docker 아키텍처에서의 본 출원에 관련된 부분들만이 도시된다는 점이 이해되어야 한다. 도시되지 않은 다른 기능 모듈은 현재 Docker 아키텍처에서의 다른 모듈과 동일할 수 있다. 간결성을 위해, 전술한 설명에 대한 참조가 이루어질 수 있고, 상세 사항들이 본 명세서에서 다시 설명되지는 않는다.
실행 드라이버 프로그램(execution driver) 레이어는 데몬에 독립적일 수 있고, 구체적인 드라이버 인스턴스들(예를 들어, 도 3에 도시되는 Native/runc, 컨테이너의 빌트-인 드라이버 인스턴스; LXC, LXC 컨테이너의 드라이버 인스턴스; runv, 컨테이너 가상 머신의 드라이버 인스턴스)이 실행 드라이버 레이어와 독립적일 수 있다는 점을 도 3에 도시되는 Docker 아키텍처로부터 알 수 있다. 독립적인 존재는 2개의 프로세스들이 상호 독립적임을 의미할 수 있다는 점이 주목되어야 한다.
도 2 및 도 3에 도시되는 아키텍처들은 추가로 변환될 수 있다는 점이 이해되어야 한다. 예를 들어, 데몬 및 실행 드라이버 프로그램은 2개의 독립적인 프로세스들일 수 있지만, 구체적인 드라이버 인스턴스는 실행 드라이버 프로그램 프로세스에서 로직의 세그먼트로서 사용될 수 있다, 즉, 구체적인 드라이버 인스턴스는 더 이상 실행 드라이버 레이어와 독립적인 것이 아니다. 도 2 및 도 3에 도시되는 Docker 아키텍처들이 본 출원에서 구체적으로 제한되는 것은 아니다.
도 4는 본 출원의 실시예에 따른 컨테이너 액세스 방법의 개략 흐름도를 도시한다. 도 4에 도시되는 방법은 도 2 또는 도 3에서의 라우터(router)에 의해 수행될 수 있다. 도 4는 컨테이너 액세스 방법의 상세한 단계들 또는 동작들을 도시하지만, 이러한 단계들 또는 동작들은 단지 예들이라는 점이 이해되어야 한다. 도 4에서의 동작들의 다른 동작 또는 변환이 본 출원의 이러한 실시예에서 실행될 수 있다. 또한, 도 4에서의 단계들은 도 4에 도시되는 것과 상이한 순서에 따라 수행될 수 있고, 도 4에서의 모든 동작들이 수행되는 것은 아닐 수 있다. 다음은 도 4에 도시되는 방법에서의 단계들을 상세히 설명한다.
410. 클라이언트가 컨테이너 액세스 요청을 라우터에 전송함- 이러한 컨테이너 액세스 요청은 타겟 컨테이너를 액세스하라고 요청하는데 사용됨 -.
구체적으로, 라우터는 사용자에 의해 전송되는 요청을 스케줄링하도록 구성되고, 이러한 요청은 컨테이너 액세스 요청 및/또는 컨테이너 실행 요청을 포함할 수 있다.
컨테이너 액세스 요청은 컨테이너 액세스 요청을 사용하여 액세스되는 타겟 컨테이너를 결정하기 위해 라우터에 의해 사용되는 타겟 컨테이너의 컨테이너 ID 또는 타겟 컨테이너의 컨테이너 IP를 운반할 수 있다는 점이 이해되어야 한다.
클라이언트는 Docker 클라이언트일 수 있고, Docker 클라이언트 및 Docker 데몬은 하나의 물리적 호스트 또는 가상 머신 상에 있을 수 있거나, 또는 상이한 물리적 호스트들 또는 상이한 가상 머신들 상에 있을 수 있다는 점이 또한 이해되어야 한다. 이러한 것이 본 출원에서 구체적으로 제한되는 것은 아니다.
라우터는 실행 드라이버에서의 로직의 세그먼트일 수 있고, 이러한 실행 드라이버는 Docker 데몬에서의 로직의 세그먼트일 수 있다는 점이 주목되어야 한다. 대안적으로, 실행 드라이버 및 Docker 데몬은 2개의 상이한 프로세스들일 수 있다.
420. 라우터가 다수의 현재 실행 중인 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택함- 다수의 드라이버 인스턴스들에서의 상이한 드라이버 인스턴스들은 상이한 타입들의 컨테이너들을 구동하는데 사용되고, 다수의 드라이버 인스턴스들은 동일한 Docker 데몬 Daemon을 사용하여 관리됨 -.
구체적으로, 다수의 드라이버 인스턴스들 각각은 하나의 드라이버 프로그램에 대응하고, 상이한 타입들의 컨테이너들을 구동하는데 상이한 드라이버 프로그램들이 사용된다.
다수의 드라이버 인스턴스들은 동일한 Docker Daemon을 사용하여 관리되고, 시동 동안, 이러한 Docker Daemon은 다수의 드라이버 인스턴스들 각각을 초기화할 수 있다.
430. 라우터가 컨테이너 액세스 요청을 타겟 컨테이너에 대응하는 드라이버 인스턴스에 전송함.
구체적으로, 라우터는 타겟 컨테이너에 대응하는 드라이버 인스턴스를 사용하여 타겟 컨테이너를 액세스할 수 있다.
이러한 해결책에서는, 상이한 타입들의 컨테이너들을 구동하는데 사용되는 드라이버 인스턴스들을 하나의 Docker 데몬이 관리할 수 있으므로, 사용자는 하나의 Docker 데몬을 사용하여 상이한 타입들의 다수의 컨테이너들을 액세스할 수 있다. 즉, Docker 데몬이 실행 드라이버에서 구체적인 드라이버 인스턴스와 "강하게 구속하는(strongly binding)" 관계에 있는 모드는 Docker 데몬이 실행 드라이버에서 다수의 구체적인 드라이버 인스턴스들을 관리하는 모드로 변경된다. 이것은 상이한 타입들의 컨테이너들이 상이한 Docker 데몬들을 사용하여 관리되는 상이한 드라이버 인스턴스들을 사용하여 액세스되는 종래 기술 문제를 회피하고, Docker 시스템에서 Docker 데몬의 실행 오버헤드들을 감소시킨다.
또한, 하나의 Docker 데몬 및 하나의 세트의 Docker 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 사용하여 다수의 타입들의 컨테이너들이 액세스될 수 있으므로, Docker 데몬을 사용하여 컨테이너를 액세스하는 유연성이 증가될 수 있다.
선택적으로, 실시예에서, 단계 410에서, 컨테이너 액세스 요청이 수신되고, 컨테이너 액세스 요청은 타겟 컨테이너의 컨테이너 ID를 운반한다. 단계 420에서, 타겟 컨테이너의 컨테이너 ID에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스가 선택된다.
구체적으로, 컨테이너 액세스 요청을 수신하는 단계는, 라우터에 의해, Docker 클라이언트에 의해 전송되는 컨테이너 액세스 요청을 수신하는 단계일 수 있고, 이러한 컨테이너 액세스 요청은 타겟 컨테이너의 컨테이너 ID를 운반할 수 있다. 라우터는, 컨테이너 ID에 따라, 타겟 컨테이너에 관련된 정보, 예를 들어, 타겟 컨테이너의 컨테이너 타입을 획득할 수 있다. 라우터는 타겟 컨테이너의 획득된 컨테이너 타입에 따라 실행 드라이버 레이어에서 상이한 타입들의 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택할 수 있다.
타겟 컨테이너의 컨테이너 ID에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 다수의 구체적인 구현들이 존재한다는 점이 이해되어야 한다. 예를 들어, 라우터는 컨테이너 ID와 드라이버 인스턴스 사이의 미리 수립된 매핑 관계를 사용하여 타겟 컨테이너의 컨테이너 ID에 따라 타겟 컨테이너에 대응하는 드라이버 인스턴스를 직접 결정할 수 있고; 대안적으로, 라우터는 컨테이너 ID와 드라이버 인스턴스 사이의 미리 수립된 매핑 관계를 사용하여 타겟 컨테이너의 컨테이너 ID에 따라 타겟 컨테이너에 대응하는 드라이버 인스턴스를 결정할 수 있다. 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 방식이 본 출원에서 구체적으로 제한되는 것은 아니다.
선택적으로, 실시예에서, 타겟 컨테이너의 컨테이너 ID에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계는, 타겟 컨테이너의 컨테이너 ID 및 컨테이너 ID와 컨테이너 타입 사이의 매핑 관계에 따라 타겟 컨테이너의 컨테이너 타입을 결정하는 단계; 및 타겟 컨테이너의 컨테이너 타입 및 컨테이너 타입과 드라이버 인스턴스 타입 사이의 매핑 관계에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계를 포함한다.
Docker 데몬에 의해 유지되는 컨테이너 정보에 필드가 추가될 수 있고, 이러한 필드는 컨테이너 ID와 컨테이너 타입 사이의 매핑 관계 및/또는 컨테이너 타입과 드라이버 인스턴스 타입 사이의 매핑 관계를 기록하는데 사용될 수 있다는 점이 주목되어야 한다.
컨테이너 ID와 컨테이너 타입 사이의 매핑 관계 및/또는 컨테이너 타입과 드라이버 인스턴스 타입 사이의 매핑 관계는 Docker 데몬의 초기화 동안 미리 수립될 수 있다는 점이 이해되어야 한다. 이러한 것이 본 출원에서 구체적으로 제한되는 것은 아니다.
선택적으로, 실시예에서, 타겟 컨테이너의 컨테이너 ID에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계는, 타겟 컨테이너의 컨테이너 ID 및 컨테이너 ID와 드라이버 인스턴스 타입 사이의 매핑 관계에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계를 포함한다.
Docker 데몬에 의해 유지되는 컨테이너 정보에 필드가 추가될 수 있고, 이러한 필드는 컨테이너 ID와 드라이버 인스턴스 타입 사이의 매핑 관계를 기록하는데 사용될 수 있다는 점이 주목되어야 한다.
컨테이너 ID와 드라이버 인스턴스 타입 사이의 매핑 관계는 Docker 데몬의 초기화 동안 미리 수립될 수 있다는 점이 이해되어야 한다. 이러한 것이 본 출원에서 구체적으로 제한되는 것은 아니다.
선택적으로, 실시예에서, 이러한 방법은, 단계 440 내지 단계 450을 추가로 포함한다.
440. 컨테이너 실행 요청을 수신함- 이러한 컨테이너 실행 요청은 타겟 컨테이너에 대응하는 드라이버 인스턴스의 타입을 운반함 -.
구체적으로, 컨테이너 실행 요청을 수신하는 단계는, 라우터에 의해, Docker 클라이언트에 의해 전송되는 컨테이너 실행 요청을 수신하는 단계일 수 있다.
이러한 컨테이너 실행 요청은 타겟 컨테이너에 대응하는 드라이버 인스턴스의 타입을 운반하다, 즉, 이러한 컨테이너 실행 요청은 컨테이너를 실행하는 것을 나타낼 수 있다.
예를 들어, 컨테이너 실행 요청은 파라미터 "-exec-driver=runv"를 운반할 수 있고, 컨테이너 실행 요청은 드라이버 인스턴스 runv를 사용하여 runv 컨테이너가 실행될 필요가 있다는 점을 표시하는데 사용될 수 있다.
450. 라우터가 타겟 컨테이너에 대응하는 드라이버 인스턴스의 타입에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 결정함.
예를 들어, Docker 클라이언트는 컨테이너 실행 요청을 라우터에 전송한다. 즉, 컨테이너 실행 요청은 실행 드라이버 레이어에서 라우터에 진입하고, 라우터는 컨테이너 실행 요청을 분석하고, 컨테이너 실행 요청에서 파라미터 "exec-driver"를 결정할 수 있다, 즉, 컨테이너 실행 요청에서 명시되는 드라이버 인스턴스의 타입을 결정할 수 있다.
다수의 현재 실행 중인 드라이버 인스턴스들은 Docker 데몬의 초기화 프로세스에서 또는 Docker 데몬이 실행된 이후에 초기화될 수 있다는 점이 주목되어야 한다. Docker 클라이언트에 의해 전송되는 컨테이너 실행/액세스 요청이 수신될 때, 그리고 실행될 필요가 있는 타겟 컨테이너의 타입이 결정된 이후에, 초기화될 필요가 있는 드라이버 인스턴스의 타입이 타겟 컨테이너의 타입에 따라 결정되고, 드라이버 인스턴스의 타입에 대응하는 드라이버 인스턴스가 초기화된다.
본 출원의 이러한 실시예에서, 컨테이너 실행 요청을 분석하는 추가된 단계는 Docker 아키텍처에서 인터페이스 및 다른 파라미터의 원래 사용을 변경하지 않는다.
460. 라우터가 컨테이너 실행 요청을 타겟 컨테이너에 대응하는 드라이버 인스턴스에 전송함.
구체적으로, 라우터는 타겟 컨테이너에 대응하는 드라이버 인스턴스를 사용하여 타겟 컨테이너를 실행할 수 있다.
이러한 해결책에서는, 상이한 타입들의 컨테이너들을 구동하는데 사용되는 드라이버 인스턴스들을 하나의 프로그램이 관리하므로, 사용자는 하나의 프로그램을 사용하여 상이한 타입들의 다수의 컨테이너들을 실행할 수 있다. 즉, Docker 데몬이 실행 드라이버에서 구체적인 드라이버 인스턴스와 "강하게 구속하는(strongly binding)" 관계에 있는 모드는 Docker 데몬이 실행 드라이버에서 다수의 구체적인 드라이버 인스턴스들을 관리하는 모드로 변경된다. 이것은 상이한 타입들의 컨테이너들이 상이한 프로그램들을 사용하여 관리되는 상이한 드라이버 인스턴스들을 사용하여 액세스되는 종래 기술 문제를 회피하고, 컨테이너 엔진에서 다수의 드라이버 인스턴스들을 관리하는 프로그램의 실행 오버헤드들을 감소시킨다.
또한, 하나의 Docker 데몬 및 하나의 세트의 Docker 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 사용하여 다수의 타입들의 컨테이너들이 실행될 수 있으므로, Docker 데몬을 사용하여 컨테이너를 관리하는 유연성이 증가된다.
도 5는 본 출원의 실시예에 따른 컨테이너 액세스 장치의 개략 블록도를 도시한다. 도 5에 도시되는 장치(500)는, 제1 수신 모듈(510), 제1 선택 모듈(520), 및 제1 송신 모듈(530)을 포함한다.
제1 수신 모듈(510)은 컨테이너 액세스 요청을 수신하도록 구성된다- 이러한 컨테이너 액세스 요청은 타겟 컨테이너를 액세스하라고 요청하는데 사용됨 -.
제1 선택 모듈(520)은 다수의 현재 실행 중인 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하도록 구성된다- 다수의 드라이버 인스턴스들에서의 상이한 드라이버 인스턴스들은 상이한 타입들의 컨테이너들을 구동하는데 사용되고, 다수의 드라이버 인스턴스들은 동일한 프로그램을 사용하여 관리됨 -.
제1 전송 모듈(530)은 컨테이너 액세스 요청을 타겟 컨테이너에 대응하고 제1 선택 모듈에 의해 선택되는 드라이버 인스턴스에 전송하도록 구성된다.
이러한 해결책에서는, 상이한 타입들의 컨테이너들을 구동하는데 사용되는 드라이버 인스턴스들을 하나의 프로그램이 관리하므로, 사용자는 하나의 프로그램을 사용하여 상이한 타입들의 다수의 컨테이너들을 액세스할 수 있다. 이것은 상이한 타입들의 컨테이너들이 상이한 프로그램들을 사용하여 관리되는 상이한 드라이버 인스턴스들을 사용하여 액세스되는 종래 기술 문제를 회피하고, 컨테이너 엔진에서 다수의 드라이버 인스턴스들을 관리하는 프로그램의 실행 오버헤드들을 감소시킨다.
추가로, 컨테이너 엔진이 Docker일 때, 다수의 드라이버 인스턴스들이 동일한 프로그램을 사용하여 관리되는 것은 다수의 드라이버 인스턴스들이 동일한 Docker 데몬을 사용하여 관리되는 것일 수 있다. 이러한 해결책에서는, 상이한 타입들의 컨테이너들을 구동하는데 사용되는 드라이버 인스턴스들을 하나의 Docker 데몬이 관리하므로, 사용자는 하나의 Docker 데몬을 사용하여 상이한 타입들의 다수의 컨테이너들을 액세스할 수 있다. 이것은 상이한 타입들의 컨테이너들이 상이한 Docker 데몬들을 사용하여 관리되는 상이한 드라이버 인스턴스들을 사용하여 액세스되는 종래 기술 문제를 회피하고, Docker 시스템에서 Docker 데몬의 실행 오버헤드들을 감소시킨다.
또한, 하나의 Docker 데몬 및 하나의 세트의 Docker 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 사용하여 다수의 타입들의 컨테이너들이 액세스될 수 있으므로, Docker 데몬을 사용하여 컨테이너를 액세스하는 유연성이 증가될 수 있다.
선택적으로, 실시예에서, 장치(500)는, 컨테이너 실행 요청을 수신하도록 구성되는 제2 수신 모듈- 컨테이너 실행 요청은 타겟 컨테이너에 대응하는 드라이버 인스턴스의 타입을 운반함 -; 타겟 컨테이너에 대응하는 드라이버 인스턴스의 타입에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하도록 구성되는 제2 선택 모듈; 및 컨테이너 실행 요청을 타겟 컨테이너에 대응하는 드라이버 인스턴스에 전송하도록 구성되는 제2 전송 모듈을 추가로 포함한다.
선택적으로, 실시예에서, 제1 수신 모듈은 컨테이너 액세스 요청을 수신하도록 구체적으로 구성되고- 컨테이너 액세스 요청은 타겟 컨테이너의 컨테이너 ID를 운반함 -; 제1 선택 모듈은 타겟 컨테이너의 컨테이너 ID에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하도록 구체적으로 구성된다.
선택적으로, 실시예에서, 제1 선택 모듈은 구체적으로, 타겟 컨테이너의 컨테이너 ID 및 컨테이너 ID와 컨테이너 타입 사이의 매핑 관계에 따라 타겟 컨테이너의 컨테이너 타입을 결정하도록; 그리고 타겟 컨테이너의 컨테이너 타입 및 컨테이너 타입과 드라이버 인스턴스 타입 사이의 매핑 관계에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하도록 추가로 구성된다.
선택적으로, 실시예에서, 제1 선택 모듈은 구체적으로 타겟 컨테이너의 컨테이너 ID 및 컨테이너 ID와 드라이버 인스턴스 타입 사이의 매핑 관계에 따라 다수의 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하도록 추가로 구성된다.
도 6은 본 출원의 다른 실시예에 따른 컨테이너 액세스 장치의 개략 블록도를 도시한다. 도 6에 도시되는 장치(600)는, 메모리(610), 프로세서(620), 입력/출력 인터페이스(630), 통신 인터페이스(640), 및 버스 시스템(650)을 포함한다. 메모리(610), 프로세서(620), 입력/출력 인터페이스(630), 및 통신 인터페이스(640)는 버스 시스템(660)을 사용하여 서로 접속된다. 메모리(610)는 명령어를 저장하도록 구성된다. 프로세서(620)는 메모리(610)에 저장되는 명령어를 실행하도록 구성되어, 입력 데이터 및 정보를 수신하도록 그리고 동작 결과와 같은 데이터를 출력하도록 입력/출력 인터페이스(630)를 제어하고, 신호를 전송하도록 통신 인터페이스(640)를 제어한다.
입력/출력 인터페이스(630)는 컨테이너 액세스 요청을 수신하도록 구성된다- 이러한 컨테이너 액세스 요청은 타겟 컨테이너를 액세스하라고 요청하는데 사용됨 -.
프로세서(620)는 다수의 현재 실행 중인 드라이버 인스턴스들로부터 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하도록 구성된다- 다수의 드라이버 인스턴스들에서의 상이한 드라이버 인스턴스들은 상이한 타입들의 컨테이너들을 구동하는데 사용되고, 다수의 드라이버 인스턴스들은 동일한 프로그램을 사용하여 관리됨 -.
입력/출력 인터페이스(630)는 컨테이너 액세스 요청을 타겟 컨테이너에 대응하는 드라이버 인스턴스에 전송하도록 구성된다.
본 출원의 이러한 실시예에서, 프로세서(620)는 범용 중앙 처리 유닛(Central Processing Unit, CPU), 마이크로프로세서, 주문형 집적 회로(Application Specific Integrated Circuit, ASIC), 또는 하나 이상의 집적 회로일 수 있고, 관련 프로그램을 실행하도록 구성되어, 본 출원의 실시예들에서 제공되는 기술적 해결책들을 구현한다는 점이 이해되어야 한다.
통신 인터페이스(640)는, 이에 제한되는 것은 아니지만 송수신기일 수 있는 송수신기 장치를 사용하여, 모바일 단말(600)과 다른 디바이스 또는 통신 네트워크 사이의 통신을 구현한다는 점이 또한 이해되어야 한다.
메모리(610)는 판독 전용 메모리 및 랜덤 액세스 메모리를 포함할 수 있고, 명령어 및 데이터를 프로세서(620)에 제공한다. 프로세서(620)의 일부는 비-휘발성 랜덤 액세스 메모리를 추가로 포함할 수 있다. 예를 들어, 프로세서(620)는 디바이스 타입에 관한 정보를 추가로 저장할 수 있다.
데이터 버스 외에도, 버스 시스템(650)은 전력 버스, 제어 버스, 상태 신호 버스 등을 포함할 수 있다. 그러나, 명확한 설명을 위해, 도면에서의 다양한 타입들의 버스들은 버스 시스템(650)으로서 마킹된다.
구현 프로세스에서, 전술한 방법에서의 단계들은 프로세서(620)에서의 하드웨어의 집적 논리 회로 또는 소프트웨어 형태인 명령어에 의해 완료될 수 있다. 본 출원의 실시예들을 참조하여 개시되는 컨테이너 액세스 방법의 단계들은 하드웨어 프로세서에 의해 직접 수행될 수 있거나, 또는 프로세서에서의 하드웨어 모듈과 소프트웨어 모듈의 조합을 사용하여 수행될 수 있다. 소프트웨어 모듈은, 랜덤 액세스 메모리, 플래시 메모리, 판독 전용 메모리, 프로그래 가능 판독 전용 메모리, 전기적 소거 가능한 프로그램 가능 메모리, 또는 레지스터와 같은, 해당 분야에서의 완성된 저장 매체에 배치될 수 있다. 저장 매체는 메모리(610)에 위치된다. 프로세서(620)는 메모리(610)에서의 정보를 판독하고, 프로세서(620)의 하드웨어와 조합하여 전술한 방법의 단계들을 완료한다. 반복을 회피하기 위해, 상세 사항들이 본 명세서에서 다시 설명되지는 않는다.
이러한 해결책에서는, 상이한 타입들의 컨테이너들을 구동하는데 사용되는 드라이버 인스턴스들을 하나의 프로그램이 관리하므로, 사용자는 하나의 프로그램을 사용하여 상이한 타입들의 다수의 컨테이너들을 액세스할 수 있다. 이것은 상이한 타입들의 컨테이너들이 상이한 프로그램들을 사용하여 관리되는 상이한 드라이버 인스턴스들을 사용하여 액세스되는 종래 기술 문제를 회피하고, 컨테이너 엔진에서 다수의 드라이버 인스턴스들을 관리하는 프로그램의 실행 오버헤드들을 감소시킨다.
추가로, 컨테이너 엔진이 Docker일 때, 다수의 드라이버 인스턴스들이 동일한 프로그램을 사용하여 관리되는 것은 다수의 드라이버 인스턴스들이 동일한 Docker 데몬을 사용하여 관리되는 것일 수 있다. 이러한 해결책에서는, 상이한 타입들의 컨테이너들을 구동하는데 사용되는 드라이버 인스턴스들을 하나의 Docker 데몬이 관리하므로, 사용자는 하나의 Docker 데몬을 사용하여 상이한 타입들의 다수의 컨테이너들을 액세스할 수 있다. 이것은 상이한 타입들의 컨테이너들이 상이한 Docker 데몬들을 사용하여 관리되는 상이한 드라이버 인스턴스들을 사용하여 액세스되는 종래 기술 문제를 회피하고, Docker 시스템에서 Docker 데몬의 실행 오버헤드들을 감소시킨다.
또한, 하나의 Docker 데몬 및 하나의 세트의 Docker 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 사용하여 다수의 타입들의 컨테이너들이 액세스될 수 있으므로, Docker 데몬을 사용하여 컨테이너를 액세스하는 유연성이 증가될 수 있다.
본 출원의 실시예들에서, "A에 대응하는 B(B corresponding to A)"는, B가 A와 연관되고, B가 A에 따라 결정될 수 있다는 것을 표시한다는 점이 이해되어야 한다. 그러나, B에 따라 A를 결정하는 것은 B가 단지 A에 따라 결정되는 것을 의미하는 것은 아니라는 점이 추가로 이해되어야 한다; 즉, B는 A 및/또는 다른 정보에 따라 또한 결정될 수 있다.
본 명세서에서 "및/또는(and/or)"이라는 용어는 연관된 객체들을 설명하기 위한 연관 관계만을 설명하고 3개의 관계들이 존재할 수 있다는 점을 나타낸다. 예를 들어, A 및/또는 B는 다음의 3개의 경우들을 나타낼 수 있다: A만 존재함, A 및 B 양자 모두 존재함, 및 B만 존재함. 또한, 본 명세서에서의 문자 "/"는 연관된 객체들 사이의 "또는(or)" 관계를 일반적으로 표시한다.
전술한 프로세스들의 시퀀스 번호들은 본 출원의 다양한 실시예들에서 실행 시퀀스들을 의미하는 것은 아니라는 점이 이해되어야 한다. 프로세스들의 실행 시퀀스들은 프로세스들의 기능들 및 내부 로직에 따라 결정되어야 하며, 본 출원의 실시예들의 구현 프로세스들에 대한 임의의 제한으로서 해석되어서는 안 된다.
본 출원에서 제공되는 몇몇 실시예들에서, 개시되는 시스템, 장치, 및 방법은 다른 방식들로 구현될 수 있다는 점이 이해되어야 한다. 예를 들어, 설명되는 장치 실시예는 단지 예이다. 예를 들어, 유닛 분할은 단지 논리적 기능 분할이고 실제 구현에서는 다른 분할일 수 있다. 예를 들어, 복수의 유닛들 또는 컴포넌트들이 조합되거나 다른 시스템 내로 집적될 수 있거나, 또는 일부 특징들이 무시되거나 또는 수행되지 않을 수 있다. 또한, 디스플레이되는 또는 논의되는 상호 연결들 또는 직접 연결들 또는 통신 접속들은 일부 인터페이스들을 사용하여 구현될 수 있다. 장치들 또는 유닛들 사이의 간접 연결들 또는 통신 접속들은 전자적, 기계적, 또는 다른 형태들로 구현될 수 있다.
별개의 부분들로서 설명되는 유닛들은 물리적으로 별개일 수 있거나 또는 그렇지 않을 수 있거나, 유닛들로서 디스플레이되는 부분들은 물리적 유닛들일 수 있거나 또는 그렇지 않을 수 있거나, 하나의 위치에 위치될 수 있거나, 또는 복수의 네트워크 유닛들 상에 분포될 수 있다. 이러한 유닛들의 일부 또는 전부는 실시예들의 해결책들의 목적들을 달성하기 위해 실제 요건들에 따라 선택될 수 있다.
또한, 본 출원의 실시예들에서의 기능 유닛들은 하나의 처리 유닛 내로 집적될 수 있거나, 또는 이러한 유닛들 각각은 단독으로 물리적으로 존재할 수 있거나, 또는 2개 이상의 유닛들이 하나의 유닛 내로 집적된다.
전술한 실시예들의 전부 또는 일부는 소프트웨어, 하드웨어, 펌웨어, 또는 이들의 임의의 조합에 의해 구현될 수 있다. 실시예들을 구현하는데 소프트웨어가 사용될 때, 실시예들은 컴퓨터 프로그램 제품의 형태로 완전히 또는 부분적으로 구현될 수 있다. 이러한 컴퓨터 프로그램 제품은 하나 이상의 컴퓨터 명령어를 포함한다. 이러한 컴퓨터 프로그램 명령어들이 컴퓨터 상에서 로딩되고 실행될 때, 본 출원의 실시예들에 따른 프로시저 또는 기능들이 모두 또는 부분적으로 생성된다. 컴퓨터는 범용 컴퓨터, 전용 컴퓨터, 컴퓨터 네트워크, 또는 다른 프로그램 가능 장치들일 수 있다. 컴퓨터 명령어들은 컴퓨터 판독 가능 저장 매체에 저장될 수 있거나 또는 컴퓨터 판독 가능 저장 매체로부터 다른 컴퓨터 판독 가능 저장 매체로 송신될 수 있다. 예를 들어, 컴퓨터 명령어들은 웹사이트, 컴퓨터, 서버, 또는 데이터 센터로부터 다른 웹사이트, 컴퓨터, 서버, 또는 데이터 센터로 유선(예를 들어, 동축 케이블, 광 섬유, 또는 DSL(digital subscriber line)) 또는 무선(예를 들어, 적외선, 라디오, 및 마이크로웨이브 등) 방식으로 송신될 수 있다. 컴퓨터 판독 가능 저장 매체는 컴퓨터에 의해 액세스 가능한 임의의 사용 가능한 매체, 또는 하나 이상의 사용 가능 매체를 집적하는, 서버 또는 데이터 센터와 같은, 데이터 저장 디바이스일 수 있다. 사용 가능 매체는 자기 매체(예를 들어, 소프트 디스크, 하드 디스크, 또는 자기 테이프), 광 매체(예를 들어, 디지털 다기능 디스크(Digital Video Disc, DVD)), 반도체 매체(예를 들어, 솔리드 스테이트 디스크(Solid State Disk, SSD)) 등일 수 있다.
전술한 설명들은 단지 본 출원의 구체적인 구현들이지, 본 출원의 보호 범위를 제한하도록 의도되는 것은 아니다. 본 출원에서 개시되는 기술적 범위 내에서 해당 분야에서의 기술자에 의해 용이하게 도출되는 임의의 변형 또는 대체는 본 출원의 보호 범위 내에 있을 것이다. 따라서, 본 출원의 보호 범위는 청구항들의 보호 범위에 종속될 것이다.

Claims (10)

  1. 컨테이너 액세스 방법으로서,
    컨테이너 액세스 요청을 수신하는 단계- 상기 컨테이너 액세스 요청은 타겟 컨테이너를 액세스하라고 요청하는데 사용됨 -;
    다수의 현재 실행 중인 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계- 상기 다수의 드라이버 인스턴스들에서의 상이한 드라이버 인스턴스들은 상이한 타입들의 컨테이너들을 구동하는데 사용되고, 상기 다수의 드라이버 인스턴스들은 동일한 프로그램을 사용하여 관리됨 -; 및
    상기 타겟 컨테이너에 대응하는 드라이버 인스턴스에 상기 컨테이너 액세스 요청을 전송하는 단계
    를 포함하는 방법.
  2. 제1항에 있어서,
    상기 방법은,
    컨테이너 실행 요청을 수신하는 단계- 상기 컨테이너 실행 요청은 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스의 타입을 운반함 -;
    상기 타겟 컨테이너에 대응하는 드라이버 인스턴스의 타입에 따라 상기 다수의 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계; 및
    상기 컨테이너 실행 요청을 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스에 전송하는 단계
    를 추가로 포함하는 방법.
  3. 제1항 또는 제2항에 있어서,
    컨테이너 액세스 요청을 수신하는 상기 단계는,
    상기 컨테이너 액세스 요청을 수신하는 단계- 상기 컨테이너 액세스 요청은 상기 타겟 컨테이너의 컨테이너 ID를 운반함 -를 포함하고;
    다수의 현재 실행 중인 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 상기 단계는,
    상기 타겟 컨테이너의 컨테이너 ID에 따라 상기 다수의 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계를 포함하는 방법.
  4. 제3항에 있어서,
    상기 타겟 컨테이너의 컨테이너 ID에 따라 상기 다수의 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 상기 단계는,
    상기 타겟 컨테이너의 컨테이너 ID 및 컨테이너 ID와 컨테이너 타입 사이의 매핑 관계에 따라 상기 타겟 컨테이너의 컨테이너 타입을 결정하는 단계; 및
    상기 타겟 컨테이너의 컨테이너 타입 및 컨테이너 타입과 드라이버 인스턴스 타입 사이의 매핑 관계에 따라 상기 다수의 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계
    를 포함하는 방법.
  5. 제3항에 있어서,
    상기 타겟 컨테이너의 컨테이너 ID에 따라 상기 다수의 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 상기 단계는,
    상기 타겟 컨테이너의 컨테이너 ID 및 컨테이너 ID와 드라이버 인스턴스 타입 사이의 매핑 관계에 따라 상기 다수의 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하는 단계를 포함하는 방법.
  6. 컨테이너 액세스 장치로서,
    컨테이너 액세스 요청을 수신하도록 구성되는 제1 수신 모듈- 상기 컨테이너 액세스 요청은 타겟 컨테이너를 액세스하라고 요청하는데 사용됨 -;
    다수의 현재 실행 중인 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하도록 구성되는 제1 선택 모듈- 상기 다수의 드라이버 인스턴스들에서의 상이한 드라이버 인스턴스들은 상이한 타입들의 컨테이너들을 구동하는데 사용되고, 상기 다수의 드라이버 인스턴스들은 동일한 프로그램을 사용하여 관리됨 -; 및
    상기 컨테이너 액세스 요청을 상기 타겟 컨테이너에 대응하고 상기 제1 선택 모듈에 의해 선택되는 드라이버 인스턴스에 전송하도록 구성되는 제1 전송 모듈
    을 포함하는 장치.
  7. 제6항에 있어서,
    상기 장치는,
    컨테이너 실행 요청을 수신하도록 구성되는 제2 수신 모듈- 상기 컨테이너 실행 요청은 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스의 타입을 운반함 -;
    상기 타겟 컨테이너에 대응하는 드라이버 인스턴스의 타입에 따라 상기 다수의 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하도록 구성되는 제2 선택 모듈; 및
    상기 컨테이너 실행 요청을 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스에 전송하도록 구성되는 제2 전송 모듈
    을 추가로 포함하는 장치.
  8. 제6항 또는 제7항에 있어서,
    상기 제1 수신 모듈은 상기 컨테이너 액세스 요청을 수신하도록 구체적으로 구성되고, 상기 컨테이너 액세스 요청은 상기 타겟 컨테이너의 컨테이너 ID를 운반하고;
    상기 제1 선택 모듈은 상기 타겟 컨테이너의 컨테이너 ID에 따라 상기 다수의 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하도록 구체적으로 구성되는 장치.
  9. 제8항에 있어서,
    상기 제1 선택 모듈은 구체적으로,
    상기 타겟 컨테이너의 컨테이너 ID 및 컨테이너 ID와 컨테이너 타입 사이의 매핑 관계에 따라 상기 타겟 컨테이너의 컨테이너 타입을 결정하도록; 그리고
    상기 타겟 컨테이너의 컨테이너 타입 및 컨테이너 타입과 드라이버 인스턴스 타입 사이의 매핑 관계에 따라 상기 다수의 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하도록
    추가로 구성되는 장치.
  10. 제8항에 있어서,
    상기 제1 선택 모듈은 구체적으로,
    상기 타겟 컨테이너의 컨테이너 ID 및 컨테이너 ID와 드라이버 인스턴스 타입 사이의 매핑 관계에 따라 상기 다수의 드라이버 인스턴스들로부터 상기 타겟 컨테이너에 대응하는 드라이버 인스턴스를 선택하도록 추가로 구성되는 장치.
KR1020197009003A 2016-09-07 2017-09-04 컨테이너를 액세스하는데 사용하기 위한 방법 및 디바이스 KR102176298B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201610806797.3A CN107797845B (zh) 2016-09-07 2016-09-07 用于访问容器的方法和装置
CN201610806797.3 2016-09-07
PCT/CN2017/100351 WO2018045926A1 (zh) 2016-09-07 2017-09-04 用于访问容器的方法和装置

Publications (2)

Publication Number Publication Date
KR20190044098A true KR20190044098A (ko) 2019-04-29
KR102176298B1 KR102176298B1 (ko) 2020-11-09

Family

ID=61529900

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020197009003A KR102176298B1 (ko) 2016-09-07 2017-09-04 컨테이너를 액세스하는데 사용하기 위한 방법 및 디바이스

Country Status (5)

Country Link
US (1) US11321109B2 (ko)
EP (1) EP3499365A4 (ko)
KR (1) KR102176298B1 (ko)
CN (1) CN107797845B (ko)
WO (1) WO2018045926A1 (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10791065B2 (en) * 2017-09-19 2020-09-29 Cisco Technology, Inc. Systems and methods for providing container attributes as part of OAM techniques
US10587412B2 (en) * 2017-11-07 2020-03-10 International Business Machines Corporation Virtual machine structure
CN117348951B (zh) * 2023-12-04 2024-02-09 北京长扬软件有限公司 应用于linux内核的容器感知装置和容器感知方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001051935A (ja) * 1999-05-28 2001-02-23 Sony Corp 情報処理装置および方法、並びに記録媒体
JP3583931B2 (ja) * 1998-01-27 2004-11-04 イーエムシー コーポレイション バスを通じたターゲット・デバイスに対するアクセスを制御する装置、方法およびコンピュータ・プログラムを記録したコンピュータ読み取り可能媒体
US20100318657A1 (en) * 2009-06-11 2010-12-16 Microsoft Corporation Educational Adaptive Provider Architecture
EP2375328A2 (en) * 2006-01-24 2011-10-12 Citrix Systems, Inc. Methods and Systems for Providing Access to a Computing Environment
US20110276720A1 (en) * 2010-05-06 2011-11-10 Microsoft Corporation Directing service requests to providers

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7584433B2 (en) * 2005-04-20 2009-09-01 Avp Ip Holding Co., Llc. Extendible and open camera connector system
US20070174429A1 (en) * 2006-01-24 2007-07-26 Citrix Systems, Inc. Methods and servers for establishing a connection between a client system and a virtual machine hosting a requested computing environment
US8856782B2 (en) * 2007-03-01 2014-10-07 George Mason Research Foundation, Inc. On-demand disposable virtual work system
US9772831B2 (en) * 2010-04-26 2017-09-26 Pivotal Software, Inc. Droplet execution engine for dynamic server application deployment
US8813065B2 (en) * 2010-04-26 2014-08-19 Vmware, Inc. Microcloud platform delivery system
CN101916208A (zh) * 2010-08-30 2010-12-15 芯通科技（成都）有限公司 一种用于多线程调用驱动模块的***及方法
US9843533B2 (en) * 2014-03-06 2017-12-12 Trilio Data Inc. Elastic compute cloud based on underutilized server resources using a distributed container system
US9760415B2 (en) * 2014-05-16 2017-09-12 Microsoft Technology Licensing, Llc Code service for language-independent dispatch
US10726119B2 (en) * 2014-12-08 2020-07-28 Vmware, Inc. Monitoring application execution in a clone of a virtual computing instance for application whitelisting
CN105022626B (zh) * 2015-05-29 2018-08-03 克拉玛依红有软件有限责任公司 基于模型驱动的利用反射机制进行动态交互的***及方法
WO2016191908A1 (en) * 2015-05-29 2016-12-08 Intel Corporation Container access to graphics processing unit resources
EP3304295B1 (en) * 2015-06-05 2024-05-29 Nutanix, Inc. Architecture for managing i/o and storage for a virtualization environment using executable containers and virtual machines
US11438278B2 (en) * 2015-06-29 2022-09-06 Vmware, Inc. Container-aware application dependency identification
CN105045656B (zh) * 2015-06-30 2018-11-30 深圳清华大学研究院 基于虚拟容器的大数据存储与管理方法
CN104951360A (zh) * 2015-06-30 2015-09-30 北京奇虎科技有限公司 基于Docker的配置管理方式及装置
US10142204B2 (en) * 2015-07-27 2018-11-27 Datagrid Systems, Inc. Techniques for evaluating server system reliability, vulnerability and component compatibility using crowdsourced server and vulnerability data
KR102294568B1 (ko) * 2015-08-19 2021-08-26 삼성에스디에스 주식회사 컨테이너 이미지 보안 검사 방법 및 그 장치
CN105099706A (zh) * 2015-08-25 2015-11-25 华为技术有限公司 一种数据通信方法、用户设备和服务器
US9934073B2 (en) * 2015-10-23 2018-04-03 Futurewei Technologies, Inc. Extension of resource constraints for service-defined containers
US9811386B2 (en) * 2015-10-23 2017-11-07 Oracle International Corporation System and method for multitenant execution of OS programs invoked from a multitenant middleware application
US10216529B1 (en) * 2015-11-19 2019-02-26 Virtuozzo International Gmbh Method and system for sharing driver pages
US9832802B2 (en) * 2015-12-15 2017-11-28 At&T Intellectual Property I, L.P. Facilitating communications via a mobile internet-enabled connection interface
CN105847045B (zh) * 2016-01-04 2019-06-18 中国电子科技网络信息安全有限公司 一种基于Docker容器的应用封装***及管理方法
US10892942B2 (en) * 2016-01-22 2021-01-12 Equinix, Inc. Container-based cloud exchange disaster recovery
US10326744B1 (en) * 2016-03-21 2019-06-18 EMC IP Holding Company LLC Security layer for containers in multi-tenant environments
US9898354B2 (en) * 2016-03-21 2018-02-20 Microsoft Technology Licensing, Llc Operating system layering
US20170371693A1 (en) * 2016-06-23 2017-12-28 Vmware, Inc. Managing containers and container hosts in a virtualized computer system
US10142109B2 (en) * 2016-08-16 2018-11-27 Hewlett Packard Enterprise Development Lp Instantiating containers

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3583931B2 (ja) * 1998-01-27 2004-11-04 イーエムシー コーポレイション バスを通じたターゲット・デバイスに対するアクセスを制御する装置、方法およびコンピュータ・プログラムを記録したコンピュータ読み取り可能媒体
JP2001051935A (ja) * 1999-05-28 2001-02-23 Sony Corp 情報処理装置および方法、並びに記録媒体
EP2375328A2 (en) * 2006-01-24 2011-10-12 Citrix Systems, Inc. Methods and Systems for Providing Access to a Computing Environment
US20100318657A1 (en) * 2009-06-11 2010-12-16 Microsoft Corporation Educational Adaptive Provider Architecture
US20110276720A1 (en) * 2010-05-06 2011-11-10 Microsoft Corporation Directing service requests to providers

Also Published As

Publication number Publication date
CN107797845B (zh) 2021-06-15
EP3499365A1 (en) 2019-06-19
WO2018045926A1 (zh) 2018-03-15
US11321109B2 (en) 2022-05-03
KR102176298B1 (ko) 2020-11-09
US20190205156A1 (en) 2019-07-04
EP3499365A4 (en) 2019-08-21
CN107797845A (zh) 2018-03-13

Similar Documents

Publication Publication Date Title
EP2862065B1 (en) Intermediary virtual machine task management
US7752635B2 (en) System and method for configuring a virtual network interface card
US10768960B2 (en) Method for affinity binding of interrupt of virtual network interface card, and computer device
US9858105B1 (en) Service for managing custom virtual machine images
US20140215465A1 (en) Traffic and/or workload processing
CN111865629B (zh) 用于配置服务实例的方法、设备和计算机程序产品
US20150370582A1 (en) At least one user space resident interface between at least one user space resident virtual appliance and at least one virtual data plane
US11321109B2 (en) Container engine for selecting driver based on container metadata
CN108322325A (zh) 一种虚拟机管理方法及装置
CN112035121B (zh) 一种边缘应用部署方法及***
US20180074839A1 (en) Device virtualization for containers
US11671379B1 (en) System and method for subscription management using dynamically composed management entities
US11119754B1 (en) Upgrading system components with forward and backward compatibility
CN114296953B (zh) 一种多云异构***及任务处理方法
US10754676B2 (en) Sharing ownership of an input/output device using a device driver partition
US11604670B2 (en) Virtual machine live migration method, apparatus, and system
US20220358055A1 (en) Method and apparatus for acquiring device information, storage medium and electronic device
US10911371B1 (en) Policy-based allocation of provider network resources
US11296929B2 (en) Methods and network systems for enabling a network service in a visited network
CN109962788B (zh) 多控制器调度方法、装置和***及计算机可读存储介质
JP2021184235A5 (ko)
CN110520842B (zh) 针对传统应用兼容性的地址空间拆分***及方法
EP4407474A1 (en) Management of network file copy operations to a new data store
CN117632350A (zh) 容器部署方法及装置
CN117632351A (zh) 容器部署方法及***

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant