WO2018003020A1 - 制御装置、コンテナの起動方法及びプログラム - Google Patents

制御装置、コンテナの起動方法及びプログラム Download PDF

Info

Publication number
WO2018003020A1
WO2018003020A1 PCT/JP2016/069156 JP2016069156W WO2018003020A1 WO 2018003020 A1 WO2018003020 A1 WO 2018003020A1 JP 2016069156 W JP2016069156 W JP 2016069156W WO 2018003020 A1 WO2018003020 A1 WO 2018003020A1
Authority
WO
WIPO (PCT)
Prior art keywords
image
container
information
control device
vim
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2016/069156
Other languages
English (en)
French (fr)
Inventor
麻代 大平
智仁 井口
一廣 江頭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Priority to EP16907253.5A priority Critical patent/EP3477470A4/en
Priority to PCT/JP2016/069156 priority patent/WO2018003020A1/ja
Priority to JP2018524627A priority patent/JP6763429B2/ja
Priority to US16/078,157 priority patent/US10719347B2/en
Publication of WO2018003020A1 publication Critical patent/WO2018003020A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/48—Program initiating; Program switching, e.g. by interrupt
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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/45595—Network integration; Enabling network access in virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/63—Image based installation; Cloning; Build to order

Definitions

  • the present invention relates to a control device, a container activation method, and a program.
  • the present invention relates to a control device, a container activation method and a program related to network function virtualization management orchestration.
  • NFV Network Functions Virtualization
  • VM Virtual Machine
  • Virtualization Layer Virtualization Layer
  • HV hypervisor
  • FIG. 7 is a diagram showing an outline of the network configuration of the virtual environment.
  • a VNF Virtualized Network Function
  • VM virtual machine
  • EM Element Manager: Element Management
  • EMS Element Management System
  • NFVI Network Functions Virtualization Infrastructure 21 is a virtualized computing and virtualization that virtualizes hardware resources of physical machines (physical machines; PM) such as computing, storage, and network functions in a virtualization layer such as a hypervisor. This is a platform that can be flexibly handled as virtual hardware resources such as storage and virtual networks.
  • NFV-MANO NFV Management & Orchestration
  • 10 NFV Orchestrator NFV Orchestrator: NFVO
  • 11 is the NFVI 21 resource orchestration and network service (Network Service: NS) instance life cycle management (NS) instance (Instantiation), scaling (Scaling), termination (Termination), update (Update), etc.).
  • VNF Manager VNFM
  • VNF instance life cycle management for example, instantiation, update, query, scaling, termination, etc.
  • event notification for example, instantiation, update, query, scaling, termination, etc.
  • a virtualized infrastructure manager (VIM) 13 performs NFVI 21 computing, storage, network resource management, NFVI 21 failure monitoring, NFVI 21 resource monitoring, and the like.
  • OSS Operations Support Systems
  • BSS Business Support systems
  • information systems devices, software, mechanisms, etc.
  • the VIM 13 manages image files necessary for the instantiation of the VNF 22.
  • the VIM 13 instantiates the VNF 22 by providing the image file to the NFVI 21.
  • the target software version can be specified by the software image management interface (VNF software / image / management / interface) described in “7.2.2 VNF software / image / management” in Non-Patent Document 1. ing.
  • the NFVO 11 is in accordance with a request from the transmission source.
  • the image file is provided to the VIM 13 using the software image management interface.
  • the software management interface (VNF software image management interface) is described as "Software Image Management Interface” in Chapter 7.2 of Non-Patent Document 2.
  • FIG. 7 is a virtualization technology for creating a virtual machine (VM) by a virtualization function (hypervisor) installed in a physical machine (PM).
  • VM virtual machine
  • PM physical machine
  • OS operating system
  • container engine In container-type virtualization technology, software called a container engine is used (a container engine is installed in a physical machine or a virtual machine).
  • Docker having a stack management function related to an image of an application has been published as open source and is often used as a container engine.
  • Docker has a function to manage an execution environment itself in which an application is installed as an execution image.
  • the specification of a Docker repository (also referred to as a Docker registry) for managing the image is disclosed in Non-Patent Document 3. ing.
  • Magnum is an API (Application Programming Interface) by OpenStack, and can build and operate a virtual environment by Docker with commands.
  • Non-Patent Document 4 discloses an interface by Magnum.
  • Non-Patent Document 1 It is assumed that the virtual function instance (VNF, virtual server) assumed by Non-Patent Document 1 is realized by a virtual machine (VM) using a hypervisor. In other words, Non-Patent Document 1 does not assume a container-type virtualization technology that is one of other virtualization technologies. As a result, the VIM does not have a function for managing containers and cannot use container-type virtualization technology.
  • VNF virtual function instance
  • VM virtual machine
  • Non-Patent Document 1 the VIM implemented according to the specifications defined in Non-Patent Document 1 includes an image stack management function (repository management) necessary for managing containers and a Docker allocate execution function. Therefore, container-type virtualization technology cannot be used. That is, Non-Patent Document 1 shows a means for VIM to build a virtual machine (VM) using a hypervisor, but does not define a function for VIM to manage containers. As a result, there arises a problem that the container cannot be used as the virtualization means.
  • VM virtual machine
  • the object of the present invention is to provide a control device, a container activation method, and a program that can use a container as a virtualization means.
  • a first means for managing an image that is information necessary for execution of a container a second means for requesting activation of a container corresponding to a predetermined version of the image, And a third means for instructing creation of a container corresponding to the image of the predetermined version based on an image managed by the first means in response to a request from the second means.
  • an NFVO NFV-Orchestrator
  • a VIM Virtualized Infrastructure Manager
  • the NFVO requests the VIM to start a container corresponding to a predetermined version of the image, and a request from the NFVO
  • the VIM instructs the creation of a container corresponding to the predetermined version of the image based on the image managed by the repository.
  • an NFVO NFV-Orchestrator
  • VIM Virtualized Infrastructure Manager
  • a repository for managing an image which is information necessary for execution of the image, executed by a computer mounted on a control device, wherein the NFVO starts the container corresponding to a predetermined version of the image.
  • the VIM executes a process for instructing creation of a container corresponding to the image of the predetermined version based on an image managed by the repository.
  • a program is provided. This program can be recorded on a computer-readable storage medium.
  • the storage medium may be non-transient such as a semiconductor memory, a hard disk, a magnetic recording medium, an optical recording medium, or the like.
  • the present invention can also be embodied as a computer program product.
  • control device a container activation method, and a program that contribute to making a container as a virtualization means usable.
  • FIG. 1 is a block diagram showing an example of the configuration of the control device 100 according to the first embodiment.
  • the control device 100 includes a first means 101 for managing container images, a second means 102 that is a submodule of NFVO, and a third means 103 that is a submodule of VIM. Prepare.
  • the first means 101 manages an image that is information necessary for executing the container.
  • the first means 101 is, for example, a repository that manages the image.
  • the second means 102 requests the third means 103 to start the container. Specifically, the second means 102 requests the third means 103 to start a container corresponding to a predetermined version of the image.
  • the third means 103 instructs, for example, a container manager to create a container corresponding to a predetermined version of the image based on the image managed by the first means 101. To do.
  • control device 100 The operation of the control device 100 is as shown in the flowchart of FIG.
  • an image required for container execution is prepared.
  • the prepared image is registered and managed in the first means 101 (step S01).
  • the second means 102 requests the third means 103 to start a container corresponding to a predetermined version image (step S02).
  • the third means 103 creates a container corresponding to a predetermined version of the image based on the image managed by the first means 101.
  • the manager is instructed (step S03).
  • control device 100 includes an image stack management function (repository management function; first means 101) necessary for managing containers, and a Docker allocation execution function (allocate).
  • An execution function third means 103).
  • the control device 100 according to the first embodiment can use a container as a virtualization unit in the VIM.
  • FIG. 3 is a diagram illustrating a configuration example of a communication system according to the second embodiment.
  • the communication system includes a control device 10, a Docker server 15, and a physical machine 16.
  • the control device 10 is a network function virtualization management orchestration device (NFV-MANO).
  • NFV-MANO network function virtualization management orchestration device
  • the Docker server 15 is a server on which the Magnum 221 is mounted.
  • the Docker 231 is mounted on the physical machine 16.
  • the Docker 231 provides a virtual function instance (VNF, virtual server) by starting a container and executing an application in the container based on an instruction from the Magnum 221.
  • VNF virtual function instance
  • the control device 10 includes an NFV orchestrator (NFVO) 11, a VNF manager (VNFM) 12, a virtualization infrastructure manager (VIM) 13, and a repository 14.
  • NFVO NFV orchestrator
  • VNFM VNF manager
  • VIM virtualization infrastructure manager
  • the repository 14 is a Docker repository that manages container images used in the Docker 231 of the physical machine 16.
  • the repository 14 corresponds to the first means 101 described above.
  • the NFVO11 implements network services in a virtualized environment.
  • the NFVO 11 performs a life cycle management of a network service (NS) instance.
  • the NFVO 11 includes an image registration request unit 201 and a container activation request unit 202.
  • the image registration request unit 201 has a function of requesting the VIM 13 to register a container image in the repository 14. More specifically, the image registration request unit 201 requests the VIM 13 to register a container image in the repository 14 using the above-described software image management interface defined in Non-Patent Document 1. At that time, the image registration requesting unit 201 specifies the version of the container image and requests the VIM 13 to register the container image. The image registration request unit 201 also generates and stores image management information by associating the identifier (ID; Identifier) of the container image acquired from the VIM 13 with the version information. The image management information is configured so that the container activation request unit 202 can refer to it.
  • ID identifier
  • the container activation request unit 202 has a function of requesting the VIM 13 to activate a container corresponding to a predetermined version image. More specifically, the container activation request unit 202 is based on the image management information stored in the image registration request unit 201 (correspondence between container image version information and identifiers), and the identifier of the image corresponding to the version of the container to be activated. (ID) is specified.
  • the container activation request unit 202 designates a container image by the identified identifier (ID) and requests the VIM 13 to activate the container. At that time, the container activation request unit 202 requests the VIM 13 to activate the container using the virtualized resource management interface (Virtualized Resources Management Interface) defined in “7.3.3 Virtualized resources management” of Non-Patent Document 1. .
  • the container activation request unit 202 corresponds to the second means 102 described above.
  • the virtualized resource management interface (VirtualizedVirtualResources Management Interface) is described as “Virtualized Compute Resources Management Interface” in Chapter 7.3.1 of Non-Patent Document 2.
  • VNFM 12 performs life cycle management of virtual function instances.
  • VIM 13 performs resource management and control of virtual function instances.
  • the VIM 13 includes an image registration unit 211 and a container activation unit 212.
  • the image registration unit 211 is a means for processing a container image registration request from the NFVO 11.
  • the image registration unit 211 acquires the registration request including the version information of the container image
  • the image registration unit 211 converts the version information into information suitable for the repository management interface of Docker.
  • the image registration unit 211 converts the version information of the container image into Tag information (also referred to as Tag).
  • the image registration unit 211 designates a Tag and requests the repository 14 to register the Tag. Specifically, the image registration unit 211 designates Tag and issues a command (docker.build) for registering the Docker image to the repository 14.
  • the image registration unit 211 instructs the repository 14 to manage the tag information of the container image in association with the container image to be registered.
  • the repository 14 When the repository 14 processes the request from the image registration unit 211, the repository 14 notifies the image registration unit 211 of an identifier (ID) corresponding to the registered Tag.
  • ID an identifier
  • the image registration unit 211 responds to the NFVO 11 that the registration of the container image is completed. At that time, the image registration unit 211 also notifies the NFVO 11 of the identifier (ID) notified from the repository 14. Further, the image registration unit 211 stores the Tag information notified to the repository 14 and the identifier (ID) notified from the repository in association with each other. The stored correspondence relationship is configured to be referenced by the container activation unit 212.
  • the container activation unit 212 instructs the Magnum 221 to create a container corresponding to a predetermined version image based on the request from the container activation request unit 202.
  • the container activation unit 212 corresponds to the third means 103 described above.
  • the container activation unit 212 converts the identifier (ID) acquired from the container activation request unit 202 so as to conform to the interface of the Magnum 221. Specifically, the container activation unit 212 converts the identifier (ID) into a Tag in JSON (JavaScript (registered trademark) Object Notation) format. Thereafter, the container activation unit 212 specifies a Tag corresponding to the container image to be activated in the command (magnum.pod-create) for activating the container, and instructs the Magnum 221 to activate the container.
  • JSON JavaScript (registered trademark) Object Notation
  • FIG. 4 is a block diagram illustrating an example of a hardware configuration of the control device 10 according to the second embodiment.
  • the control device 10 can be configured by an information processing device (computer) and has the configuration illustrated in FIG.
  • the control device 10 includes a CPU (Central Processing Unit) 41, a memory 42, an input / output interface 43, a NIC (Network Interface Card) 44 that is a communication unit, and the like that are connected to each other via an internal bus.
  • a CPU Central Processing Unit
  • memory 42 for example, a memory 42, an input / output interface 43, a NIC (Network Interface Card) 44 that is a communication unit, and the like that are connected to each other via an internal bus.
  • NIC Network Interface Card
  • control device 10 may include hardware (not shown).
  • number of CPUs and the like included in the control device 10 is not limited to the example illustrated in FIG. 4.
  • a plurality of CPUs may be included in the control device 10.
  • the memory 42 is a RAM (Random Access Memory), a ROM (Read Only Memory), or an auxiliary storage device (such as a hard disk).
  • RAM Random Access Memory
  • ROM Read Only Memory
  • auxiliary storage device such as a hard disk
  • the input / output interface 43 is a means to be an interface of a display device and an input device (not shown).
  • the display device is, for example, a liquid crystal display.
  • the input device is a device that accepts user operations such as a keyboard and a mouse, for example.
  • each processing module of the control device 10 is realized by the CPU 41 executing a program stored in the memory 42, for example.
  • the program can be downloaded through a network or updated using a storage medium storing the program.
  • the processing module may be realized by a semiconductor chip. That is, it is sufficient if there is a means for executing the function performed by the processing module with some hardware and / or software.
  • FIG. 5 is a sequence diagram showing an example of the operation of the communication system according to the second embodiment.
  • the NFVO 11 that has received a request for registering the container image from the OSS or the like provides the container image to the VIM 13. Specifically, the NFVO 11 requests the VIM 13 to register an image corresponding to the version while designating the version (step S101).
  • the VIM 13 converts the version information specified from the NFVO 11 into Tag information (Tag) that conforms to the repository management interface (docker.build command) in the Docker repository (step S102).
  • the VIM 13 requests the repository 14 to register the container image by the Tag converted from the version information (version character string) while providing the container image to the repository 14 (step S103).
  • the repository 14 processes the request and registers the container image. When the registration of the container image is completed, the repository 14 responds to the VIM 13 to that effect and an identifier (ID) corresponding to the registered Tag (step S104).
  • ID an identifier
  • the VIM 13 responds to the NFVO 11 that the container image registration has been completed in the repository 14 (step S105). At that time, the VIM 13 notifies the NFVO 11 of the identifier (ID).
  • the NFV O11 generates and stores image management information by associating the version information of the container image with the identifier (ID) corresponding to the version information (step S106).
  • the processing for registering the container image in the repository 14 is completed by the processing in steps S101 to S106.
  • the NFVO 11 that has received a request for starting the container from the OSS or the like requests the VIM 13 to start the container of the image corresponding to the version while designating the version (step S201). Specifically, the NFVO 11 refers to the image management information generated in step S106, and identifies the identifier (ID) of the image corresponding to the version of the container to be activated. The NFVO 11 requests the VIM 13 to start the container using the identified identifier (ID).
  • the VIM 13 In response to a request from the NFVO 11, the VIM 13 converts the specified identifier (ID) so as to be compatible with the interface of the Magnum 221 (Step S202).
  • the VIM 13 instructs the Mangum 221 to start the container using the interface of the Magnum 221 (Step S203).
  • the VIM 13 designates a tag obtained by converting the identifier (ID), and issues a predetermined command (magnum.pod-create) to the Magnum 221.
  • the Mangum 221 is operated by the above command, a container image corresponding to the designated Tag is extracted from the repository 14, and a desired container is activated.
  • an acknowledgment (ACK; ACKnowledgement) is sent from the Magnum 221 to the VIM 13 (step S204), and an acknowledgment for the container activation request is transmitted from the VIM 13 to the NFVO 11 (step S205).
  • the control device 10 converts the version information and the identifier (ID) so as to conform to the interface requested by the Docker repository (repository 14) and the Magnum 221.
  • the container as the virtualization means can be used.
  • the control device 10 can start the container by specifying the target software version according to the software image management interface defined in Non-Patent Document 1, etc., in cooperation with the image stack management function of the Docker repository.
  • control device 10 may convert version information and an identifier (ID) so as to conform to the interface of the container manager 221a and the like. .
  • the image registration unit 211 identifies a container image in which the version information notified from the image registration request unit 201 is registered so as to conform to the interface requested by the repository 14 that is the repository of the container engine 231a. To the first information. When the registration of the image corresponding to the first information is completed, the repository 14 notifies the image registration unit 211 of the second information corresponding to the first information as an identifier of the registered image. The second information is transferred to the image registration request unit 201 and managed as image management information in association with version information.
  • the container activation request unit 202 requests the container activation unit 212 to activate the container
  • the container activation request unit 202 refers to the image management information and notifies the container activation unit 212 of the second information corresponding to the image of the container to be activated.
  • the container activation unit 212 converts the second information into the first information, notifies the container manager 221a of the converted information, and instructs the container activation.
  • a container as a virtualization means can be used.
  • the repository 14 may be arranged inside the Docker server 15.
  • the Magnum 221 mounted on the Docker server 15 may be mounted on the same server as the control device 10.
  • the VIM 13 manages the resources of VNF realized on the virtual machine (VM). May be.
  • the VIM 13 manages a repository 14 for registering container images and a repository (not shown in FIG. 3 and the like) for registering virtual machine (VM) images.
  • [Appendix 1] It is as the control apparatus which concerns on the above-mentioned 1st viewpoint.
  • Appendix 2 Registration request means for requesting image registration; Registration means for registering the requested image in the first means; The control device according to appendix 1, further comprising: [Appendix 3] The registration request unit notifies the registration unit of image version information when requesting the registration unit to register an image.

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

制御装置、コンテナの起動方法及びプログラム
　本発明は、制御装置、コンテナの起動方法及びプログラムに関する。特に、ネットワーク機能仮想化管理オーケストレーションに係る制御装置、コンテナの起動方法及びプログラムに関する。
　サーバ上のハイパーバイザ（ＨｙｐｅｒＶｉｓｏｒ：ＨＶ）等の仮想化レイヤ（Ｖｉｒｔｕａｌｉｚａｔｉｏｎ　Ｌａｙｅｒ）上に実装した仮想マシン（Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ：ＶＭ）によりネットワーク機器等の機能をソフトウェア的に実現するＮＦＶ（Ｎｅｔｗｏｒｋ　Ｆｕｎｃｔｉｏｎｓ　Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）が知られている（例えば、非特許文献１参照）。
　図７は、仮想化環境のネットワーク構成の概略を示す図である。図７を参照すると、ＶＮＦ（Ｖｉｒｔｕａｌｉｚｅｄ　Ｎｅｔｗｏｒｋ　Ｆｕｎｃｔｉｏｎ）２２はサーバ上の仮想マシン（ＶＭ）で動作するアプリケーション等に対応し、ネットワーク機能をソフトウェア的に実現する。ＶＮＦ２２ごとにＥＭ（Ｅｌｅｍｅｎｔ　Ｍａｎａｇｅｒ：要素管理）２３（ＥＭＳ（Ｅｌｅｍｅｎｔ　Ｍａｎａｇｅ　Ｓｙｓｔｅｍ）ともいう）という管理機能が設けられる。
　ＮＦＶＩ（Ｎｅｔｗｏｒｋ　Ｆｕｎｃｔｉｏｎｓ　Ｖｉｒｔｕａｌｉｚａｔｉｏｎ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）２１は、コンピューティング、ストレージ、ネットワーク機能等、物理マシン（Ｐｈｙｓｉｃａｌ　Ｍａｃｈｉｎｅ；ＰＭ）のハードウェア資源をハイパーバイザ等の仮想化レイヤで仮想化した仮想化コンピューティング、仮想化ストレージ、仮想化ネットワーク等の仮想化ハードウェア資源として柔軟に扱えるようにした基盤である。
　ＮＦＶ－ＭＡＮＯ（ＮＦＶ　Ｍａｎａｇｅｍｅｎｔ　＆　Ｏｒｃｈｅｓｔｒａｔｉｏｎ）１０のＮＦＶオーケストレータ（ＮＦＶ　Ｏｒｃｈｅｓｔｒａｔｏｒ：ＮＦＶＯ）１１は、ＮＦＶＩ２１のリソースのオーケストレーション、及び、ネットワークサービス（Ｎｅｔｗｏｒｋ　Ｓｅｒｖｉｃｅ：ＮＳ）インスタンスのライフサイクル管理（ＮＳインスタンスのインスタンシエーション（Ｉｎｓｔａｎｔｉａｔｉｏｎ）、スケーリング（Ｓｃａｌｉｎｇ）、ターミネーション（Ｔｅｒｍｉｎａｔｉｏｎ）、更新（Ｕｐｄａｔｅ）等）を行う。
　ＶＮＦマネージャ（ＶＮＦ　Ｍａｎａｇｅｒ：ＶＮＦＭ）１２は、ＶＮＦインスタンスのライフサイクル管理（例えばインスタンシエーション（ｉｎｓｔａｎｔｉａｔｉｏｎ）、更新（ｕｐｄａｔｅ）、クエリ（ｑｕｅｒｙ）、スケーリング（ｓｃａｌｉｎｇ）、停止（ｔｅｒｍｉｎａｔｉｏｎ）等）およびイベント通知を行う。
　仮想化インフラストラクチャマネージャ（Ｖｉｒｔｕａｌｉｚｅｄ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ　Ｍａｎａｇｅｒ：ＶＩＭ）１３は、ＮＦＶＩ２１のコンピューティング、ストレージ、ネットワークのリソース管理、ＮＦＶＩ２１の障害監視、ＮＦＶＩ２１のリソース監視等を行う。
　ＯＳＳ／ＢＳＳ３０のうちＯＳＳ（Ｏｐｅｒａｔｉｏｎｓ　Ｓｕｐｐｏｒｔ　Ｓｙｓｔｅｍｓ）は、例えば通信事業者（キャリア）がサービスを構築し、運営していくために必要なシステム（機器やソフトウェア、仕組みなど）を総称したものである。ＢＳＳ（Ｂｕｓｉｎｅｓｓ　Ｓｕｐｐｏｒｔ　ｓｙｓｔｅｍｓ）は、例えば通信事業者（キャリア）が利用料などの課金、請求、顧客対応などのために使う情報システム（機器やソフトウェア、仕組みなど）の総称である。
　図７に示すネットワークシステムでは、ＶＮＦ２２のインスタンシエーションに必要なイメージファイルはＶＩＭ１３が管理する。ＶＩＭ１３は、イメージファイルをＮＦＶＩ２１に提供することで、ＶＮＦ２２のインスタンシエーションを行う。仮想化環境のネットワークシステムでは、非特許文献１の「7.2.2 VNF software image management」に記載されたソフトウェアイメージ管理インターフェイス（VNF software image management interface）により、対象となるソフトウェアバージョンを指定できることが定められている。より具体的には、非特許文献１の「B.2.1 On-board VNF Package flow」の「Figure B.2: VNF Package on-boarding message flow」を参照すると、送信元からの要求に従い、ＮＦＶＯ１１が、ソフトウェアイメージ管理インターフェイスを用いて、ＶＩＭ１３にイメージファイルを提供している。なお、上記ソフトウェア管理インターフェイス（VNF software image management interface）は、非特許文献２の７．２章では、「Software Image Management Interface」と記載されている。
　上記図７を用いた説明は、物理マシン（ＰＭ）に搭載された仮想化機能（ハイパーバイザ）により仮想マシン（ＶＭ）を作り出す仮想化技術である。近年では、上記仮想マシン（ＶＭ）を用いた仮想化技術に加え、コンテナを用いた仮想化技術が注目されている。コンテナ型の仮想化技術では、コンテナごとにオペレーティングシステム（ＯＳ；Operating System）を必要とせず、物理マシン（ＰＭ）上でコンテナが利用可能になるまでの時間が短い等の様々な利点が存在する。
　コンテナ型の仮想化技術では、コンテナエンジンと呼ばれるソフトウェアが用いられる（物理マシン又は仮想マシンにコンテナエンジンがインストールされる）。近年では、アプリケーション（仮想サーバ）のイメージに関するスタック管理機能を備えたＤｏｃｋｅｒがオープンソースとして公開され、コンテナエンジンとして使用されることが多い。
　Ｄｏｃｋｅｒには、アプリケーションが導入された実行環境そのものを実行イメージとして管理する機能が備わっており、当該イメージを管理するＤｏｃｋｅｒリポジトリ（Ｄｏｃｋｅｒレジストリとも称される）の仕様が非特許文献３にて公開されている。
　また、ＯｐｅｎＳｔａｃｋにおいて、Ｄｏｃｋｅｒコンテナを扱えるようにするためのフレームワークが「Ｍａｇｎｕｍ」と称され検討されている。Ｍａｇｎｕｍは、ＯｐｅｎＳｔａｃｋによるＡＰＩ（Application Programming Interface）であり、Ｄｏｃｋｅｒによる仮想化環境をコマンドで構築し、操作することができる。
　例えば、図８を参照すると、Ｄｏｃｋｅｒにより、Ｄｏｃｋｅｒイメージを生成し、リポジトリ（Repository）に登録するためのコマンド（docker.build）や、Ｄｏｃｋｅｒイメージを起動するためのコマンド（magnum.pod-create）が提供される。なお、Ｍａｇｎｕｍによるインターフェイス等が、非特許文献４にて公開されている。
ETSI GS NFV-MAN 001 V1.1.1 (2014-12)　Network Functions Virtualisation (NFV); Management and Orchestration （２０１６年６月１４日検索）＜http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf＞ ETSI GS NFV-IFA 005 V2.1.1 (2016-04)　Network Functions Virtualisation (NFV); Management and Orchestration Or-Vi reference point - Interface and Information Model Specification （２０１６年６月１４日検索）＜http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/005/02.01.01_60/gs_nfv-ifa005v020101p.pdf＞ The Docker commands （２０１６年６月１４日検索）＜https://docs.docker.com/engine/reference/commandline/＞ Developer Quick-Start （２０１６年６月１４日検索）＜http://docs.openstack.org/developer/magnum/dev/dev-quickstart.html＞
　なお、上記先行技術文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。
　非特許文献１が想定する仮想機能インスタンス（ＶＮＦ、仮想サーバ）は、ハイパーバイザを用いた仮想マシン（ＶＭ）により実現されることを想定している。換言すれば、非特許文献１では、他の仮想化技術（Ｖｉｒｔｕａｌｉｚａｔｉｏｎ技術）の１つであるコンテナ型の仮想化技術は想定されていない。その結果、ＶＩＭには、コンテナを管理する機能が備わっておらず、コンテナ型の仮想化技術を用いることができない。
　より具体的には、非特許文献１に規定された仕様により実装されたＶＩＭは、コンテナを管理するために必要なイメージのスタック管理機能（リポジトリ管理）と、Ｄｏｃｋｅｒのａｌｌｏｃａｔｅ実行機能と、を備えていないので、コンテナ型の仮想化技術を用いることができない。つまり、非特許文献１には、ＶＩＭがハイパーバイザを用いて仮想マシン（ＶＭ）を構築するための手段が示されているが、ＶＩＭがコンテナを管理する機能が規定されていない。その結果、仮想化手段としてコンテナを用いることができないという問題が生じる。
　本発明は、仮想化手段としてのコンテナを使用可能とする、制御装置、コンテナの起動方法及びプログラムを提供することを目的とする。
　本発明の第１の視点によれば、コンテナの実行に必要な情報であるイメージを管理する第１の手段と、所定のバージョンのイメージに対応するコンテナの起動を依頼する第２の手段と、前記第２の手段からの依頼に応じて、前記第１の手段が管理するイメージに基づき、前記所定のバージョンのイメージに対応するコンテナの作成を指示する第３の手段と、を備える、制御装置が提供される。
　本発明の第２の視点によれば、仮想化環境下にて、ネットワークサービスを実現するＮＦＶＯ（NFV-Orchestrator）と、仮想機能インスタンスのリソース管理と制御を行うＶＩＭ（Virtualized Infrastructure Manager）と、コンテナの実行に必要な情報であるイメージを管理するリポジトリと、を含む通信システムにおいて、前記ＮＦＶＯが、所定のバージョンのイメージに対応するコンテナの起動を前記ＶＩＭに依頼するステップと、前記ＮＦＶＯからの依頼に応じて、前記ＶＩＭが、前記リポジトリが管理するイメージに基づき、前記所定のバージョンのイメージに対応するコンテナの作成を指示するステップと、を含む、コンテナの起動方法が提供される。
　本発明の第３の視点によれば、仮想化環境下にて、ネットワークサービスを実現するＮＦＶＯ（NFV-Orchestrator）と、仮想機能インスタンスのリソース管理と制御を行うＶＩＭ（Virtualized Infrastructure Manager）と、コンテナの実行に必要な情報であるイメージを管理するリポジトリと、を含む制御装置に搭載されたコンピュータに実行させるプログラムであって、前記ＮＦＶＯが、所定のバージョンのイメージに対応するコンテナの起動を前記ＶＩＭに依頼する処理と、前記ＮＦＶＯからの依頼に応じて、前記ＶＩＭが、前記リポジトリが管理するイメージに基づき、前記所定のバージョンのイメージに対応するコンテナの作成を指示する処理と、を実行させる、プログラムが提供される。
　なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。
　本発明の各視点によれば、仮想化手段としてのコンテナを使用可能とすることに寄与する、制御装置、コンテナの起動方法及びプログラムが、提供される。
第１の実施形態に係る制御装置の構成の一例を示すブロック図である。 第１の実施形態に係る制御装置の動作の一例を示すフローチャートである。 第２の実施形態に係る通信システムの一構成例を示す図である。 第２の実施形態に係る制御装置のハードウェア構成の一例を示すブロック図である。 第２の実施形態に係る通信システムの動作の一例を示すシーケンス図である。 第３の実施形態に係る通信システムの一構成例を示す図である。 仮想化環境のネットワーク構成の概略を示す図である。 コンテナ型の仮想化技術を説明するための図である。
［第１の実施形態］
　第１の実施形態について、図面を用いてより詳細に説明する。なお、各実施形態において同一構成要素には同一の符号を付し、その説明を省略する。
　図１は、第１の実施形態に係る制御装置１００の構成の一例を示すブロック図である。図１を参照すると、制御装置１００は、コンテナイメージを管理する第１の手段１０１と、ＮＦＶＯのサブモジュールである第２の手段１０２と、ＶＩＭのサブモジュールである第３の手段１０３と、を備える。
　第１の手段１０１は、コンテナの実行に必要な情報であるイメージを管理する。第１の手段１０１は、例えば、当該イメージを管理するリポジトリである。
　第２の手段１０２は、コンテナの起動を第３の手段１０３に依頼する。具体的には、第２の手段１０２は、所定のバージョンのイメージに対応するコンテナの起動を第３の手段１０３に依頼する。
　第３の手段１０３は、第２の手段１０２からの依頼に応じて、第１の手段１０１が管理するイメージに基づき、所定のバージョンのイメージに対応するコンテナの作成を、例えば、コンテナマネージャに指示する。
　上記制御装置１００の動作は、図２に示すフローチャートのとおりとなる。
　初めに、コンテナの実行に必要なイメージが用意される。用意されたイメージは、第１の手段１０１に登録され、管理される（ステップＳ０１）。
　次に、第２の手段１０２が、所定のバージョンのイメージに対応するコンテナの起動を第３の手段１０３に依頼する（ステップＳ０２）。
　最後に、第３の手段１０３が、第２の手段１０２からの依頼に応じて、第１の手段１０１が管理するイメージに基づき、所定のバージョンのイメージに対応するコンテナの作成を、例えば、コンテナマネージャに指示する（ステップＳ０３）。
　以上のように、第１の実施形態に係る制御装置１００は、コンテナを管理するために必要なイメージのスタック管理機能（リポジトリ管理機能；第１の手段１０１）と、Ｄｏｃｋｅｒの割り当て実行機能（ａｌｌｏｃａｔｅ実行機能；第３の手段１０３）と、を備える。その結果、第１の実施形態に係る制御装置１００は、ＶＩＭにおいて仮想化手段としてのコンテナを使用することを可能とする。
［第２の実施形態］
　第２の実施形態について、図面を用いてより詳細に説明する。
　図３は、第２の実施形態に係る通信システムの一構成例を示す図である。図３を参照すると、通信システムは、制御装置１０と、Ｄｏｃｋｅｒサーバ１５と、物理マシン１６と、を含む。
　制御装置１０は、ネットワーク機能仮想化管理オーケストレーション装置（ＮＦＶ－ＭＡＮＯ）である。
　Ｄｏｃｋｅｒサーバ１５は、Ｍａｇｎｕｍ２２１が実装されたサーバである。
　物理マシン１６には、Ｄｏｃｋｅｒ２３１が実装されている。Ｄｏｃｋｅｒ２３１は、Ｍａｇｎｕｍ２２１からの指示に基づき、コンテナを起動しコンテナ内でアプリケーションを実行することで、仮想機能インスタンス（ＶＮＦ、仮想サーバ）を提供する。
　制御装置１０は、ＮＦＶオーケストレータ（ＮＦＶＯ）１１と、ＶＮＦマネージャ（ＶＮＦＭ）１２と、仮想化インフラストラクチャマネージャ（ＶＩＭ）１３と、リポジトリ１４と、を含んで構成される。
　リポジトリ１４は、物理マシン１６のＤｏｃｋｅｒ２３１にて使用されるコンテナイメージを管理するＤｏｃｋｅｒリポジトリである。リポジトリ１４は、上述の第１の手段１０１に相当する。
　ＮＦＶＯ１１は、仮想化環境下にて、ネットワークサービスを実現する。ＮＦＶＯ１１は、ネットワークサービス（Ｎｅｔｗｏｒｋ　Ｓｅｒｖｉｃｅ：ＮＳ）インスタンスのライフサイクル管理等を行う。ＮＦＶＯ１１は、イメージ登録依頼部２０１と、コンテナ起動依頼部２０２と、を含む。
　イメージ登録依頼部２０１は、コンテナイメージをリポジトリ１４に登録するようにＶＩＭ１３に依頼する機能を備える。より具体的には、イメージ登録依頼部２０１は、非特許文献１に規定された上述のソフトウェアイメージ管理インターフェイスを用いて、コンテナイメージをリポジトリ１４に登録するようにＶＩＭ１３に依頼する。その際、イメージ登録依頼部２０１は、コンテナイメージのバージョンを指定して、コンテナイメージの登録をＶＩＭ１３に依頼する。また、イメージ登録依頼部２０１は、ＶＩＭ１３から取得するコンテナイメージの識別子（ＩＤ；Identifier）とバージョン情報を対応付けて、イメージ管理情報を生成し、記憶する。なお、イメージ管理情報は、コンテナ起動依頼部２０２が参照可能に構成される。
　コンテナ起動依頼部２０２は、所定のバージョンのイメージに対応するコンテナの起動を、ＶＩＭ１３に依頼する機能を備える。より具体的には、コンテナ起動依頼部２０２は、イメージ登録依頼部２０１が記憶したイメージ管理情報（コンテナイメージのバージョン情報と識別子の対応関係）に基づき、起動するコンテナのバージョンに対応するイメージの識別子（ＩＤ）を特定する。
　コンテナ起動依頼部２０２は、当該特定した識別子（ＩＤ）によりコンテナイメージを指定し、コンテナの起動をＶＩＭ１３に依頼する。その際、コンテナ起動依頼部２０２は、非特許文献１の「7.3.3 Virtualised resources management」に規定された仮想化リソース管理インターフェイス（Virtualised Resources Management Interface）を用いて、コンテナの起動をＶＩＭ１３に依頼する。コンテナ起動依頼部２０２は、上述の第２の手段１０２に相当する。なお、上記仮想化リソース管理インターフェイス（Virtualised Resources Management Interface）は、非特許文献２の７．３．１章では、「Virtualised Compute Resources Management Interface」と記載されている。
　ＶＮＦＭ１２は、仮想機能インスタンスのライフサイクル管理等を行う。
　ＶＩＭ１３は、仮想機能インスタンスのリソース管理と制御を行う。ＶＩＭ１３は、イメージ登録部２１１と、コンテナ起動部２１２と、を含む。
　イメージ登録部２１１は、ＮＦＶＯ１１からのコンテナイメージ登録依頼を処理する手段である。イメージ登録部２１１は、コンテナイメージのバージョン情報を含む上記登録依頼を取得すると、当該バージョン情報を、Ｄｏｃｋｅｒのリポジトリ管理のインターフェイスに適合する情報に変換する。具体的には、イメージ登録部２１１は、コンテナイメージのバージョン情報をＴａｇ情報（Ｔａｇとも称する）に変換する。
　その後、イメージ登録部２１１は、Ｔａｇを指定し、当該Ｔａｇを登録するようにリポジトリ１４に依頼する。具体的には、イメージ登録部２１１は、Ｔａｇを指定し、Ｄｏｃｋｅｒイメージを登録するためのコマンド（docker.build）をリポジトリ１４に発行する。
　このように、イメージ登録部２１１は、コンテナイメージのＴａｇ情報を登録するコンテナイメージと対応付けて管理するようにリポジトリ１４に指示する。
　リポジトリ１４は、上記イメージ登録部２１１からの要求を処理すると、登録したＴａｇに対応する識別子（ＩＤ）をイメージ登録部２１１に通知する。
　その後、イメージ登録部２１１は、コンテナイメージの登録が完了した旨をＮＦＶＯ１１に応答する。その際、イメージ登録部２１１は、リポジトリ１４から通知された上記識別子（ＩＤ）も併せてＮＦＶＯ１１に通知する。さらに、イメージ登録部２１１は、リポジトリ１４に通知したＴａｇ情報と、リポジトリから通知された識別子（ＩＤ）と、を対応付けて記憶する。当該記憶された対応関係は、コンテナ起動部２１２により参照可能に構成される。
　コンテナ起動部２１２は、コンテナ起動依頼部２０２からの依頼に基づき、所定のバージョンのイメージに対応するコンテナの作成を、Ｍａｇｎｕｍ２２１に指示する。コンテナ起動部２１２は、上述の第３の手段１０３に相当する。
　具体的には、コンテナ起動部２１２は、コンテナ起動依頼部２０２から取得した識別子（ＩＤ）を、Ｍａｇｎｕｍ２２１のインターフェイスに適合するように変換する。具体的には、コンテナ起動部２１２は、上記識別子（ＩＤ）を、ＪＳＯＮ（JavaScript （登録商標） Object Notation）形式のＴａｇに変換する。その後、コンテナ起動部２１２は、コンテナを起動するためのコマンド（magnum.pod-create）において、起動するコンテナイメージに対応するＴａｇを指定し、コンテナの起動をＭａｇｎｕｍ２２１に指示する。
　次に、通信システムをなす各装置のハードウェアついて説明する。
　図４は、第２の実施形態に係る制御装置１０のハードウェア構成の一例を示すブロック図である。制御装置１０は、情報処理装置（コンピュータ）により構成可能であり、図４に例示する構成を備える。例えば、制御装置１０は、内部バスにより相互に接続される、ＣＰＵ（Central Processing Unit）４１、メモリ４２、入出力インターフェイス４３及び通信手段であるＮＩＣ（Network Interface Card）４４等を備える。
　なお、図４に示す構成は、制御装置１０のハードウェア構成を限定する趣旨ではない。制御装置１０は、図示しないハードウェアを含んでもよい。あるいは、制御装置１０に含まれるＣＰＵ等の数も図４の例示に限定する趣旨ではなく、例えば、複数のＣＰＵが制御装置１０に含まれていてもよい。
　メモリ４２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、補助記憶装置（ハードディスク等）である。
　入出力インターフェイス４３は、図示しない表示装置や入力装置のインターフェイスとなる手段である。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。
　なお、上記制御装置１０の各処理モジュールは、例えば、メモリ４２に格納されたプログラムをＣＰＵ４１が実行することで実現される。また、そのプログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。即ち、上記処理モジュールが行う機能を何らかのハードウェア、及び／又は、ソフトウェアで実行する手段があればよい。
　図３に図示するＤｏｃｋｅｒサーバ１５及び物理マシン１６のハードウェア構成も上記制御装置１０の構成と基本的に同じであり、当業者にとって明らかなものであるため、その説明を省略する。
　次に、第２の実施形態に係る通信システムの動作について説明する。
　図５は、第２の実施形態に係る通信システムの動作の一例を示すシーケンス図である。
　ＯＳＳ等からコンテナイメージの登録に係る要求を受け付けたＮＦＶＯ１１は、コンテナイメージをＶＩＭ１３に提供する。具体的には、ＮＦＶＯ１１は、バージョンを指定しつつ、当該バージョンに対応するイメージの登録をＶＩＭ１３に依頼する（ステップＳ１０１）。
　ＶＩＭ１３は、ＮＦＶＯ１１から指定されたバージョン情報を、Ｄｏｃｋｅｒリポジトリにおけるリポジトリ管理のインターフェイス（docker.buildコマンド）に適合するＴａｇ情報（Ｔａｇ）に変換する（ステップＳ１０２）。
　ＶＩＭ１３は、コンテナイメージをリポジトリ１４に提供しつつ、上記バージョン情報（バージョン文字列）が変換されたＴａｇによるコンテナイメージの登録をリポジトリ１４に対して要求する（ステップＳ１０３）。
　リポジトリ１４は、当該要求を処理し、コンテナイメージを登録する。リポジトリ１４は、コンテナイメージの登録が完了すると、その旨及び登録したＴａｇに対応する識別子（ＩＤ）をＶＩＭ１３に応答する（ステップＳ１０４）。
　ＶＩＭ１３は、リポジトリ１４にコンテナイメージの登録が完了した旨を、ＮＦＶＯ１１に応答する（ステップＳ１０５）。その際、ＶＩＭ１３は、上記識別子（ＩＤ）をＮＦＶＯ１１に通知する。
　その後、ＮＦＶ Ｏ１１は、コンテナイメージのバージョン情報と当該バージョン情報に対応する識別子（ＩＤ）を対応付けてイメージ管理情報を生成し、記憶する（ステップＳ１０６）。
　上記ステップＳ１０１～Ｓ１０６の処理により、コンテナイメージをリポジトリ１４に登録する処理が完了する。
　次に、コンテナを起動する際の動作について説明する。
　ＯＳＳ等からコンテナの起動に係る要求を受け付けたＮＦＶＯ１１は、バージョンを指定しつつ、当該バージョンに対応するイメージのコンテナを起動することを、ＶＩＭ１３に依頼する（ステップＳ２０１）。具体的には、ＮＦＶＯ１１は、上記ステップＳ１０６にて生成したイメージ管理情報を参照し、起動しようとするコンテナのバージョンに対応するイメージの識別子（ＩＤ）を特定する。ＮＦＶＯ１１は、特定した識別子（ＩＤ）を用いて、コンテナの起動をＶＩＭ１３に要求する。
　ＶＩＭ１３は、ＮＦＶＯ１１からの要求に応じて、Ｍａｇｎｕｍ２２１のインターフェイスに適合するように、指定された識別子（ＩＤ）を変換する（ステップＳ２０２）。
　その後、ＶＩＭ１３は、Ｍａｇｎｕｍ２２１のインターフェイスを用いて、コンテナの起動をＭａｎｇｕｍ２２１に指示する（ステップＳ２０３）。その際、ＶＩＭ１３は、上記識別子（ＩＤ）を変換したＴａｇを指定し、所定のコマンド（magnum.pod-create）をＭａｇｎｕｍ２２１に発行する。上記コマンドによりＭａｎｇｕｍ２２１が動作し、指定されたＴａｇに対応するコンテナイメージがリポジトリ１４から引き出され、所望のコンテナが起動する。
　コンテナの起動が完了すると、Ｍａｇｎｕｍ２２１から肯定応答（ＡＣＫ；ACKnowledgement）がＶＩＭ１３に送信され（ステップＳ２０４）、ＶＩＭ１３からＮＦＶＯ１１に対し、コンテナ起動依頼に対する肯定応答が送信される（ステップＳ２０５）。
　上記ステップＳ２０１～Ｓ２０５の処理により、物理マシン１６にコンテナを起動する処理が完了する。
　以上のように、第２の実施形態に係る制御装置１０は、Ｄｏｃｋｅｒリポジトリ（リポジトリ１４）やＭａｇｎｕｍ２２１が要求するインターフェイスに適合するように、バージョン情報や識別子（ＩＤ）を変換する。その結果、仮想化手段してのコンテナが使用可能となる。即ち、制御装置１０は、Ｄｏｃｋｅｒリポジトリのイメージスタック管理機能と連携し、非特許文献１等で定められているソフトウェアイメージ管理インターフェイスに従い、対象となるソフトウェアバージョンを指定してコンテナを起動することを可能とする。
［第３の実施形態］
　第３の実施形態について、図面を用いてより詳細に説明する。
　上記第２の実施形態では、コンテナマネージャとしてＭａｇｎｕｍを利用すること、コンテナエンジンとしてＤｏｃｋｅｒを利用することを説明した。しかし、これらは例示であって、コンテナマネージャやコンテナエンジンを限定する趣旨ではない。
　図６に示すように、他の汎用的なソフトウェア、フレームワークを用いることが可能である。この場合、制御装置１０は、リポジトリ１４にコンテナイメージを登録する際やコンテナを起動する際には、コンテナマネージャ２２１ａ等のインターフェイスに適合するように、バージョン情報、識別子（ＩＤ）を変換すればよい。
　具体的には、イメージ登録部２１１は、コンテナエンジン２３１ａのリポジトリであるリポジトリ１４が要求するインターフェイスに適合するように、イメージ登録依頼部２０１から通知されたバージョン情報を登録するコンテナイメージを識別するための第１の情報に変換する。リポジトリ１４は、当該第１の情報に対応するイメージの登録が完了すると、第１の情報に応じた第２の情報を登録したイメージの識別子としてイメージ登録部２１１に通知する。当該第２の情報は、イメージ登録依頼部２０１に転送され、イメージ管理情報として、バージョン情報と対応付けられて管理される。コンテナ起動依頼部２０２は、コンテナ起動部２１２にコンテナの起動を依頼する際、イメージ管理情報を参照し、起動するコンテナのイメージに対応する第２の情報をコンテナ起動部２１２に通知する。コンテナ起動部２１２は、第２の情報を第１の情報に変換し、当該変換した情報をコンテナマネージャ２２１ａに通知し、コンテナの起動を指示する。
　第３の実施形態によれば、汎用的なコンテナエンジン、コンテナマネージャが使用されたとしても、仮想化手段してのコンテナが使用可能となる。
　上記第１～第３の実施形態にて説明した通信システムの構成及び動作は例示であって、種々の変形が可能である。
　例えば、図３に示す通信システムでは、リポジトリ１４がＶＩＭ１３に直接接続されている例を示したが、リポジトリ１４はＤｏｃｋｅｒサーバ１５の内部に配置されていてもよい。あるいは、Ｄｏｃｋｅｒサーバ１５に実装されたＭａｇｎｕｍ２２１は、制御装置１０と同一のサーバに実装されていてもよい。
　上記実施形態では、ＮＦＶＯ１１とＶＩＭ１３の間の情報交換により、コンテナイメージの登録とコンテナを起動する場合を説明したが、ＶＮＦＭ１２を経由して、上記機能が実現されてもよい。
　また、上記実施形態では、コンテナ内で実行されるアプリケーションを仮想機能インスタンス（ＶＮＦ；仮想サーバ）とする場合を説明したが、ＶＩＭ１３は、仮想マシン（ＶＭ）上で実現されるＶＮＦのリソースを管理してもよい。この場合には、ＶＩＭ１３は、コンテナイメージを登録するリポジトリ１４と、仮想マシン（ＶＭ）のイメージを登録するリポジトリ（図３等に図示せず）と、を管理する。
　上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
　上述の第１の視点に係る制御装置のとおりである。
［付記２］
　イメージの登録を依頼する、登録依頼手段と、
　前記依頼されたイメージを前記第１の手段に登録する、登録手段と、
　をさらに備える、付記１の制御装置。
［付記３］
　前記登録依頼手段は、前記登録手段にイメージの登録を依頼する際、登録するイメージのバージョン情報を通知し、
　前記登録手段は、前記第１の手段が要求するインターフェイスに適合するように、前記通知されたバージョン情報を前記登録するイメージを識別するための第１の情報に変換する、付記２の制御装置。
［付記４］
　前記第１の手段は、前記第１の情報に対応するイメージの登録が完了すると、前記第１の情報に応じた第２の情報を、前記登録したイメージの識別子として前記登録手段に通知する、付記３の制御装置。
［付記５］
　前記登録手段は、前記第１の手段から通知された第２の情報を、前記登録依頼手段に通知する、付記４の制御装置。　
［付記６］
　前記登録依頼手段は、登録を依頼したイメージのバージョン情報と前記通知された第２の情報を対応付けて、イメージ管理情報を生成する、付記５の制御装置。
［付記７］
　前記第２の手段は、前記第３の手段にコンテナの起動を依頼する際、前記イメージ管理情報を参照し、前記起動するコンテナのイメージに対応する第２の情報を前記第３の手段に通知する、付記６の制御装置。
［付記８］
　前記第３の手段は、コンテナの作成をコンテナマネージャに指示する際、前記コンテナマネージャが要求するインターフェイスに適合するように、前記通知された第２の情報を変換する、付記７の制御装置。
［付記９］
　上述の第２の視点に係るコンテナの起動方法のとおりである。
［付記１０］
　上述の第３の視点に係るプログラムのとおりである。
　なお、付記９の形態及び付記１０の形態は、付記１の形態と同様に、付記２の形態～付記８の形態に展開することが可能である。
　なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
１０、１００　制御装置
１１　ＮＦＶＯ
１２　ＶＮＦＭ
１３　ＶＩＭ
１４　リポジトリ
１５　Ｄｏｃｋｅｒサーバ
１６　物理マシン
２１　ＮＦＶＩ
２２　ＶＮＦ
２３　ＥＭＳ
３０　ＯＳＳ／ＢＳＳ
４１　ＣＰＵ
４２　メモリ
４３　入出力インターフェイス
４４　ＮＩＣ
１０１　第１の手段
１０２　第２の手段
１０３　第３の手段
２０１　イメージ登録依頼部
２０２　コンテナ起動依頼部
２１１　イメージ登録部
２１２　コンテナ起動部
２２１　Ｍａｇｎｕｍ
２２１ａ　コンテナマネージャ
２３１　Ｄｏｃｋｅｒ
２３１ａ　コンテナエンジン

Claims (10)

  1. 　コンテナの実行に必要な情報であるイメージを管理する第１の手段と、
    　所定のバージョンのイメージに対応するコンテナの起動を依頼する第２の手段と、
    　前記第２の手段からの依頼に応じて、前記第１の手段が管理するイメージに基づき、前記所定のバージョンのイメージに対応するコンテナの作成を指示する第３の手段と、
    　を備える、制御装置。
  2. 　イメージの登録を依頼する、登録依頼手段と、
    　前記依頼されたイメージを前記第１の手段に登録する、登録手段と、
    　をさらに備える、請求項１の制御装置。
  3. 　前記登録依頼手段は、前記登録手段にイメージの登録を依頼する際、登録するイメージのバージョン情報を通知し、
    　前記登録手段は、前記第１の手段が要求するインターフェイスに適合するように、前記通知されたバージョン情報を前記登録するイメージを識別するための第１の情報に変換する、請求項２の制御装置。
  4. 　前記第１の手段は、前記第１の情報に対応するイメージの登録が完了すると、前記第１の情報に応じた第２の情報を、前記登録したイメージの識別子として前記登録手段に通知する、請求項３の制御装置。
  5. 　前記登録手段は、前記第１の手段から通知された第２の情報を、前記登録依頼手段に通知する、請求項４の制御装置。
  6. 　前記登録依頼手段は、登録を依頼したイメージのバージョン情報と前記通知された第２の情報を対応付けて、イメージ管理情報を生成する、請求項５の制御装置。
  7. 　前記第２の手段は、前記第３の手段にコンテナの起動を依頼する際、前記イメージ管理情報を参照し、前記起動するコンテナのイメージに対応する第２の情報を前記第３の手段に通知する、請求項６の制御装置。
  8. 　前記第３の手段は、コンテナの作成をコンテナマネージャに指示する際、前記コンテナマネージャが要求するインターフェイスに適合するように、前記通知された第２の情報を変換する、請求項７の制御装置。
  9. 　仮想化環境下にて、ネットワークサービスを実現するＮＦＶＯ（NFV-Orchestrator）と、
    　仮想機能インスタンスのリソース管理と制御を行うＶＩＭ（Virtualized Infrastructure Manager）と、
    　コンテナの実行に必要な情報であるイメージを管理するリポジトリと、
    　を含む通信システムにおいて、
    　前記ＮＦＶＯが、所定のバージョンのイメージに対応するコンテナの起動を前記ＶＩＭに依頼するステップと、
    　前記ＮＦＶＯからの依頼に応じて、前記ＶＩＭが、前記リポジトリが管理するイメージに基づき、前記所定のバージョンのイメージに対応するコンテナの作成を指示するステップと、
    　を含む、コンテナの起動方法。
  10. 　仮想化環境下にて、ネットワークサービスを実現するＮＦＶＯ（NFV-Orchestrator）と、
    　仮想機能インスタンスのリソース管理と制御を行うＶＩＭ（Virtualized Infrastructure Manager）と、
    　コンテナの実行に必要な情報であるイメージを管理するリポジトリと、
    　を含む制御装置に搭載されたコンピュータに実行させるプログラムであって、
    　前記ＮＦＶＯが、所定のバージョンのイメージに対応するコンテナの起動を前記ＶＩＭに依頼する処理と、
    　前記ＮＦＶＯからの依頼に応じて、前記ＶＩＭが、前記リポジトリが管理するイメージに基づき、前記所定のバージョンのイメージに対応するコンテナの作成を指示する処理と、
    　を実行させる、プログラム。
PCT/JP2016/069156 2016-06-28 2016-06-28 制御装置、コンテナの起動方法及びプログラム Ceased WO2018003020A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP16907253.5A EP3477470A4 (en) 2016-06-28 2016-06-28 CONTROL DEVICE, CONTAINER STARTING PROCEDURE AND PROGRAM
PCT/JP2016/069156 WO2018003020A1 (ja) 2016-06-28 2016-06-28 制御装置、コンテナの起動方法及びプログラム
JP2018524627A JP6763429B2 (ja) 2016-06-28 2016-06-28 制御装置、コンテナの起動方法及びプログラム
US16/078,157 US10719347B2 (en) 2016-06-28 2016-06-28 Control apparatus, container starting method, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/069156 WO2018003020A1 (ja) 2016-06-28 2016-06-28 制御装置、コンテナの起動方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2018003020A1 true WO2018003020A1 (ja) 2018-01-04

Family

ID=60786869

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/069156 Ceased WO2018003020A1 (ja) 2016-06-28 2016-06-28 制御装置、コンテナの起動方法及びプログラム

Country Status (4)

Country Link
US (1) US10719347B2 (ja)
EP (1) EP3477470A4 (ja)
JP (1) JP6763429B2 (ja)
WO (1) WO2018003020A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019133424A (ja) * 2018-01-31 2019-08-08 沖電気工業株式会社 通信システム、通信方法、管理装置、管理プログラム、管理方法、情報処理装置、情報処理プログラム、及び情報処理方法
CN114531443A (zh) * 2022-02-18 2022-05-24 京东科技信息技术有限公司 基于集群的容器控制方法及系统
US12524257B2 (en) 2021-05-20 2026-01-13 Canon Kabushiki Kaisha Information processing system including multiple storages, information processing apparatus, method of controlling the same, and storage medium

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018173741A (ja) * 2017-03-31 2018-11-08 富士通株式会社 コンテナ登録プログラム、コンテナ登録装置及びコンテナ登録方法
US10445086B2 (en) * 2017-09-28 2019-10-15 At&T Intellectual Property I, L.P. Virtualization platform for creating, deploying, modifying, and relocating applications
CN110442421B (zh) * 2019-06-28 2022-04-01 中国科学院计算技术研究所 一种基于Kubernetes的通用服务转换方法及系统
CN115617421B (zh) * 2022-12-05 2023-04-14 深圳市欧瑞博科技股份有限公司 进程智能调度方法、装置、可读存储介质及嵌入式设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016009486A (ja) * 2014-06-23 2016-01-18 インテル コーポレイション ソフトウェア確定ネットワークにおける仮想マシンと仮想化コンテナを用いたローカルサービスチェーン
US20160057102A1 (en) * 2014-08-19 2016-02-25 Futurewei Technologies, Inc. Methods and System for Allocating an IP Address for an Instance in a Network Function Virtualization (NFV) system
JP2016509412A (ja) * 2013-01-11 2016-03-24 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． ネットワークデバイスのためのネットワーク機能仮想化

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8601129B2 (en) * 2010-06-30 2013-12-03 International Business Machines Corporation Hypervisor selection for hosting a virtual machine image
US8412945B2 (en) * 2011-08-09 2013-04-02 CloudPassage, Inc. Systems and methods for implementing security in a cloud computing environment
US9075638B2 (en) * 2012-08-14 2015-07-07 Atlassian Corporation Pty Ltd. Efficient hosting of virtualized containers using read-only operating systems
US9729396B2 (en) * 2014-11-04 2017-08-08 Cisco Technology, Inc. System and method for providing dynamic radio access network orchestration
US9692666B2 (en) * 2014-12-22 2017-06-27 Rovio Entertainment Ltd. Container manager
US10032032B2 (en) * 2015-12-18 2018-07-24 Amazon Technologies, Inc. Software container registry inspection
US10353872B2 (en) * 2016-03-09 2019-07-16 Hiveio Inc. Method and apparatus for conversion of virtual machine formats utilizing deduplication metadata
US10812582B2 (en) * 2016-03-10 2020-10-20 Vmware, Inc. Management of applications across nodes using exo-clones
US10169209B2 (en) * 2016-11-04 2019-01-01 Red Hat, Inc. Container images by composition

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016509412A (ja) * 2013-01-11 2016-03-24 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． ネットワークデバイスのためのネットワーク機能仮想化
JP2016009486A (ja) * 2014-06-23 2016-01-18 インテル コーポレイション ソフトウェア確定ネットワークにおける仮想マシンと仮想化コンテナを用いたローカルサービスチェーン
US20160057102A1 (en) * 2014-08-19 2016-02-25 Futurewei Technologies, Inc. Methods and System for Allocating an IP Address for an Instance in a Network Function Virtualization (NFV) system

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"Kakugen de Kotsu Maru Wakari Server Cho Nyumon", NIKKEI LINUX, vol. 17, no. 7, 8 June 2015 (2015-06-08), pages 56 - 57, XP009512151, ISSN: 1345-0182 *
KATSUHIRO HORIBA ET AL.: "NFV ni Okeru Process-gata Software Middlebox Architecture no Teian [Process Base Software Middlebox Architecture in NFV]", THE TRANSACTIONS OF THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS B, vol. J98-B, no. 7, 1 July 2015 (2015-07-01), pages 625 - 634, XP009511141, ISSN: 0913-5715, Retrieved from the Internet <URL:http://search.ieice.org/bin/summary.php?id=j98-b_7_625&category=B&year=2015&lang=E&abst=j> *
See also references of EP3477470A4 *
TADAO GEN ET AL.: "Yasuku''Yawarakaku' 'Tsukaiyasuku ' suru Shinsedai Cloud", NIKKEI COMMUNICATIONS, vol. 617, 1 June 2015 (2015-06-01), pages 29 - 31, XP009512153, ISSN: 0910-7215 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019133424A (ja) * 2018-01-31 2019-08-08 沖電気工業株式会社 通信システム、通信方法、管理装置、管理プログラム、管理方法、情報処理装置、情報処理プログラム、及び情報処理方法
JP7151087B2 (ja) 2018-01-31 2022-10-12 沖電気工業株式会社 通信システム、通信方法、管理装置、管理プログラム、管理方法、情報処理装置、情報処理プログラム、及び情報処理方法
US12524257B2 (en) 2021-05-20 2026-01-13 Canon Kabushiki Kaisha Information processing system including multiple storages, information processing apparatus, method of controlling the same, and storage medium
CN114531443A (zh) * 2022-02-18 2022-05-24 京东科技信息技术有限公司 基于集群的容器控制方法及系统
CN114531443B (zh) * 2022-02-18 2024-05-17 京东科技信息技术有限公司 基于集群的容器控制方法及系统

Also Published As

Publication number Publication date
JPWO2018003020A1 (ja) 2019-01-24
EP3477470A4 (en) 2019-07-10
JP6763429B2 (ja) 2020-09-30
US10719347B2 (en) 2020-07-21
US20190056971A1 (en) 2019-02-21
EP3477470A1 (en) 2019-05-01

Similar Documents

Publication Publication Date Title
JP6763429B2 (ja) 制御装置、コンテナの起動方法及びプログラム
US11405274B2 (en) Managing virtual network functions
JP6677294B2 (ja) ネットワークシステム、パッチファイル適用方法、及びプログラム
CN107145380B (zh) 虚拟资源编排方法及装置
EP3913859B1 (en) Vnf life cycle management method and apparatus
US10832224B2 (en) Calendar based management of information technology (IT) tasks
EP3503472B1 (en) Method for managing slice instance and apparatus
US20140109087A1 (en) Virtual machine provisioning using replicated containers
US10728169B1 (en) Instance upgrade migration
WO2017188387A1 (ja) ネットワーク機能仮想化管理オーケストレーション装置と方法とプログラム
US11893367B2 (en) Source code conversion from application program interface to policy document
JPWO2016121754A1 (ja) システム、仮想化制御装置、仮想化制御装置の制御方法及びプログラム
US10353752B2 (en) Methods and apparatus for event-based extensibility of system logic
US11683232B2 (en) Methods and apparatus to implement cloud specific functionality in a cloud agnostic system
US10203976B2 (en) Virtual appliance management in a virtualized computing environment based on operational modes associated with virtual appliance
US12073232B2 (en) Unikernel for webassembly containers
Piras et al. Container orchestration on HPC clusters
KR20200038038A (ko) 다중 클라우드 상에서의 애플리케이션 관리 장치 및 방법
US12561160B2 (en) Using OSTree native containers to customize virtual machines for lightweight application deployment
CN105100180A (zh) 集群节点动态加载的方法、装置及系统
US10509638B1 (en) Method and system for deploying third party device services through an enclosed appliance interface using containers
US11340949B2 (en) Method and node for managing a request for hardware acceleration by means of an accelerator device
US20250036497A1 (en) Containerized microservice architecture for management applications
EP4645078A1 (en) Executing an automation system with a container engine
CN120729741A (zh) 通信方法及装置

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2018524627

Country of ref document: JP

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16907253

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2016907253

Country of ref document: EP

Effective date: 20190128