Computer implementation methods, computer systems, computer programs (rapid migration of containers and data to new servers)

Abstract

This invention provides a computer implementation method, computer system, and program for rapid container migration. [Solution] The method involves extracting image metadata from the image of a container being migrated from the old server to the new server, extracting container migration-related information from the image metadata, analyzing the extracted information, creating a new manifest containing migration information based on the analyzed extracted information, analyzing the container metadata, generating a new startup command by combining the analyzed container metadata with other container metadata, new service port information, and disk usage information, uploading the media containing the disk and image to a directory on the new server based on the analyzed container metadata, and executing the new startup command to start the service on the new server and verify the startup of the container on the new server.

Description

Technical Field

[0001] The present invention relates to containers, and more specifically, to migrating container applications to a new server.

Summary of the Invention

Problems to be Solved by the Invention

[0002] When using known migration methods in cases where the startup command or startup document of a container has been lost because the container was created a long time ago, it is impossible to quickly start the container in a new environment and migrate the dataset through the docker compose command.

Means for Solving the Problems

[0003] In one embodiment, the present invention provides a computer implementation method. The method comprises the step of extracting image metadata from an image of a container to be migrated from an old server to a new server. The method further comprises the step of extracting information from the extracted image metadata, wherein the extracted information relates to migrating the container. The method further comprises the step of analyzing the extracted information. The method further comprises the step of creating a new manifest containing migration information based on the analyzed extracted information. The method further comprises the step of analyzing the metadata of the container. The method further comprises the step of generating a new startup command by combining the analyzed metadata of the container with other metadata of the container, new service port information, and disk usage information. The method further comprises the step of uploading media, including disks and images, to a directory in the new server based on the analyzed metadata of the container. The method further comprises the step of starting a service in the new server by executing the new startup command. The method further comprises the step of verifying the startup of the container in the new server, wherein the startup includes the step of starting the service.

[0004] Computer systems and computer program products corresponding to the computer implementation methods summarized above are also described herein. [Brief explanation of the drawing]

[0005] [Figure 1] This is a block diagram of a system for rapidly migrating containers and data to a new server according to an embodiment of the present invention.

[0006] [Figure 2] This is a block diagram of a module included in the code included in the system shown in Figure 1, according to an embodiment of the present invention.

[0007] [Figure 3]This is a flowchart of a process for rapidly migrating containers and data to a new server according to an embodiment of the present invention, where the operation of this flowchart is performed by the module shown in Figure 2.

[0008] [Figure 4] This is a block diagram of the overall workflow that performs the operations in the process shown in Figure 3 using the module shown in Figure 2, according to an embodiment of the present invention.

[0009] [Figure 5] This is an example of a special data structure used to create a new manifest in the process shown in Figure 3, according to an embodiment of the present invention.

[0010] [Figure 6] This is an example of an operation performed by the container analysis module included in the module shown in Figure 2, according to an embodiment of the present invention, where the operation is included in the process shown in Figure 3.

[0011] [Figure 7] This is an example of an operation performed by the container migration module included in the module shown in Figure 2, according to an embodiment of the present invention, where the operation is included in the process shown in Figure 3.

[0012] [Figure 8] This is an example of additional details of the operation performed by the container migration module in Figure 7 according to an embodiment of the present invention.

[0013] [Figure 9] This is an example of an operation performed by the container verification module included in the module shown in Figure 2, according to an embodiment of the present invention, where the operation is included in the process shown in Figure 3. [Modes for carrying out the invention]

[0014] overview Due to server system upgrades, data center migrations, and / or other reasons, system obsolescence necessitates migrating container applications from the original server to a new server. When using known migration methods, if the container's startup command or documentation is lost due to its age, it becomes impossible to quickly start the container in the new environment and migrate the dataset via the docker compose command. Therefore, traditional methods require manual migration, which involves a significant amount of time to synchronize and locate the container application's startup configuration parameters. Furthermore, version mismatches can lead to migration failures, preventing the new service from successfully starting and running within the system.

[0015] Embodiments of the present invention address the aforementioned specific challenges by (i) intelligently analyzing and organizing container metadata information, (ii) automatically generating relevant migration configuration information and relationship mappings, and (iii) migrating relevant container dependencies, thereby rapidly migrating containers and data to a new server and completing the migration of old containers containing data to the new server.

[0016] In one embodiment, rapid migration of containers and data comprises: (i) collecting migration-related information (e.g., port mapping, volume mapping, images, image versions, etc.) and creating a new manifest containing the migration information; (ii) analyzing container metadata and automatically generating a docker run startup command by combining the analyzed container metadata with other container metadata, new service port information, and disk usage information; (iii) using the analysis results to automatically upload relevant media such as disks and images to a directory on the new server; (iv) automatically creating a new directory modified to match the manifest, where the creation of the new directory is based on analyzing directory conflicts and starting services with the new startup command generated through the manifest; (v) validating the new server through a reliable validation method; and (vi) completing the migration of old containers with data to the new server.

[0017] In one embodiment, the container analysis, container migration, and container validation module (i) analyzes and expands the docker manifest file, (ii) automatically migrates images, containers, and data from the old server to the new server, and (iii) validates the migration by using container probes to confirm the validity of the new server. Computing environment

[0018] Various aspects of this disclosure are described by explanatory text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of computer program products (CPPs). With respect to any flowchart, depending on the technology involved, operations may be performed in a different order than those shown in a given flowchart. For example, also depending on the technology involved, two operations shown in consecutive blocks of a flowchart may be performed in reverse order, as a single integrated step, simultaneously, or with at least partial time overlap.

[0019] Embodiments of a computer program product ("CPP Embodiment" or "CPP") are terms used in this disclosure to describe any set of one or more computer-readable storage media ("mediums") that collectively comprise a set of one or more storage devices and collectively comprise machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. "Storage device" is any tangible device capable of holding and storing instructions for use by a computer processor. Computer-readable storage media may, but are not limited to, electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any preferred combination thereof. Some known types of storage devices, including these media, include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices (such as pits / lands formed on the main surface of a punch card or disk), or any suitable combination of those described above. When the term "computer-readable storage medium" is used in this disclosure, it shall not be interpreted as storage in the form of a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses passing through optical fiber cables, electrical signals communicated through wires, and / or other transmission media.As will be understood by those skilled in the art, data is typically moved at various irregular points during the normal operation of a memory device, such as during access, defragmentation, or garbage collection, but since the data is not transient while it is stored, this does not cause the memory device to be considered transient.

[0020] FIG. 1 is a block diagram of a system for quickly migrating containers and data to a new server according to an embodiment of the present invention. Computing environment 100 includes an example of an environment for executing at least a portion of computer code involved in performing the method of the present invention, such as code 200 for quickly migrating containers and data from an old server to a new server. The computer code described above is also referred to herein as computer-readable code, computer-readable program code, and machine-readable code. In addition to block 200, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes a processor set 110 (including processing circuit 120 and cache 121), communication fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and block 200 identified above), a set of peripheral devices 114 (including user interface (UI), device set 123, storage 124, and Internet of Things (IoT) sensor set 125), and network module 115. Remote server 104 includes remote database 130. Public cloud 105 includes gateway 140, cloud orchestration module 141, host physical machine set 142, virtual machine set 143, and container set 144.

[0021] Computer 101 can take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch, or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device that is currently known or will be developed in the future and can execute programs, access networks, or query databases such as remote database 130. As is well understood in the field of computer technology and depending on the technology, the execution of computer implementation methods can be distributed among multiple computers and / or multiple locations. On the other hand, in this presentation of computing environment 100, for the sake of keeping the presentation as simple as possible, the detailed discussion focuses on a single computer, specifically computer 101. Although computer 101 is not shown within the cloud in FIG. 1, it can be located within the cloud. On the other hand, computer 101 does not need to exist within the cloud except within any arbitrarily shown range.

[0022] Processor set 110 includes one or more computer processors of any type that are currently known or will be developed in the future. Processing circuit 120 can be distributed across multiple packages, such as multiple integrated circuit chips that have been adjusted. Processing circuit 120 can implement multiple processor threads and / or multiple processor cores. Cache 121 is a memory located within a processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 110. Cache memory is typically organized into multiple levels according to its relative proximity to the processing circuit. Alternatively, some or all of the cache for the processor set can be located "off-chip". In some computing environments, processor set 110 can be designed to operate using qubits and execute quantum computing.

[0023] Computer-readable program instructions are typically loaded onto computer 101, causing the processor set 110 of computer 101 to execute a series of operational steps, thereby enabling the computer implementation method. As a result, the instructions thus executed instantiate the method specified in the flowcharts and / or descriptions of the computer implementation method contained herein (collectively referred to as the "Method of the Invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by the processor set 110 to control and direct the execution of the Method of the Invention. In computing environment 100, at least some of the instructions for executing the Method of the Invention may be stored in blocks 200 in persistent storage 113.

[0024] The communication fabric 111 is a signal conduction path that enables various components of the computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive paths, such as buses, bridges, physical input / output ports, and similar components. Other types of signal communication paths, such as optical fiber communication paths and / or wireless communication paths, may be used.

[0025] Volatile memory 112 is any type of volatile memory currently known or to be developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory 112 is characterized by random access, but this is not required unless explicitly stated. In computer 101, volatile memory 112 is located in a single package and resides inside computer 101, but alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally to computer 101.

[0026] The persistent storage 113 is any form of non-volatile storage for a computer that is currently known or may be developed in the future. The non-volatility of this storage means that the stored data is maintained regardless of whether power is supplied to the computer 101 and / or directly to the persistent storage 113. The persistent storage 113 may be read-only memory (ROM), but typically at least a portion of the persistent storage allows for writing, deleting, and rewriting of data. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. The operating system 122 can take multiple forms, such as various known proprietary operating systems or open-source portable operating system interface type operating systems that employ a kernel. The code contained in block 200 typically includes at least a portion of computer code involved in performing the method of the present invention.

[0027] The peripheral device set 114 includes a set of peripheral devices for the computer 101. Data communication connections between the computer 101's peripheral devices and other components can be implemented in various ways, including Bluetooth® connections, Near-Field Communication (NFC) connections, connections made by cables (such as universal serial bus (USB) type cables), insert-type connections (e.g., secure digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the internet. In various embodiments, the UI device set 123 may include components such as a display screen, speaker, microphone, wearable devices (such as goggles and smartwatches), keyboard, mouse, printer, touchpad, game controller, and haptic devices. Storage 124 is external storage such as an external hard drive, or insertable storage such as an SD card. Storage 124 may be persistent and / or volatile. In some embodiments, storage 124 may take the form of a quantum computing memory device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (for example, when computer 101 locally stores and manages a large database), this storage may be provided by peripheral storage devices designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 125 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another may be a motion detector.

[0028] The network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers via the WAN 102. The network module 115 may include hardware such as a modem or Wi-Fi® signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of the network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of the network module 115 are performed on physically separate devices, such that the control function manages multiple different network hardware devices. Computer-readable program instructions for performing the method of the present invention can typically be downloaded to computer 101 from an external computer or external storage device via a network adapter card or network interface included in the network module 115.

[0029] WAN102 is any wide area network (e.g., the Internet) that can transmit computer data over non-local distances using any currently known or future-developed technology for transmitting computer data. In some embodiments, WAN102 may be replaced and / or supplemented by a local area network (LAN), such as a Wi-Fi network, designed to transmit data between devices located in a local area. WANs and / or LANs typically include computer hardware such as copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0030] An end-user device (EUD) 103 is any computer system used and controlled by an end-user (e.g., a customer of the company operating computer 101) and can take any of the forms discussed above in relation to computer 101. EUD 103 typically receives useful and valuable data from the operation of computer 101. For example, in a hypothetical case where computer 101 is designed to provide recommendations to an end-user, these recommendations would typically be communicated from computer 101's network module 115 to EUD 103 via WAN 102. In this way, EUD 103 can display or otherwise present recommendations to the end-user. In some embodiments, EUD 103 may be a client device such as a thin client, heavy client, mainframe computer, desktop computer, and similar.

[0031] The remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. The remote server 104 may be controlled and used by the same entity that operates computer 101. The remote server 104 represents a machine that collects and stores useful and valuable data for use by other computers, such as computer 101. For example, in a hypothetical case where computer 101 is designed and programmed to provide recommendations based on historical data, this historical data may be provided to computer 101 from the remote database 130 of the remote server 104.

[0032] The public cloud 105 is any computer system available for use by multiple entities, providing on-demand availability of computer system resources and / or other computer functions, particularly data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of the computing resources of the public cloud 105 is performed by the computer hardware and / or software of the cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that make up the host physical machine set 142, which is the universe of physical computers within and / or available in the public cloud 105. The virtual computing environment (VCE) typically takes the form of virtual machines from the virtual machine set 143 and / or containers from the container set 144. These VCEs can be stored as images and transferred between and between various physical machine hosts, either as images or after VCE instantiation. The cloud orchestration module 141 manages the transfer and storage of images, deploys new VCE instantiations, and manages active instantiations of VCE deployments. The gateway 140 is a collection of computer software, hardware, and firmware that enables the public cloud 105 to communicate through the WAN 102.

[0033] Here, some further explanation of virtualized computing environments (VCEs) is provided. A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from an image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature where the kernel allows for the existence of multiple isolated user-space instances called containers. These isolated user-space instances typically behave like actual computers in terms of the programs running within them. Computer programs running on a normal operating system can utilize all of that computer's resources, including connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and the devices allocated to the container; this feature is known as containerization.

[0034] The private cloud 106 is similar to the public cloud 105, except that its computing resources are available only for use by a single enterprise. While the private cloud 106 is shown as being in communication with the WAN 102, in other embodiments, the private cloud may be completely isolated from the internet and accessible only through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains a separate, discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple configuration clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0035] Cloud computing services and / or microservices (not shown separately in Figure 1): Private and public clouds 106 are programmed and configured to deliver cloud computing services and / or microservices (unless otherwise indicated, the term “microservices” should be interpreted as including larger “services” of any size). Cloud services are typically infrastructure, platforms, or software hosted by a third-party provider and made available to users over the internet. Cloud services facilitate the flow of user data from front-end clients (e.g., user-side servers, tablets, desktops, laptops) to the provider’s systems over the internet and vice versa. In some embodiments, cloud services may be configured and orchestrated according to the “as a service” technology paradigm, where something is presented to internal or external customers in the form of cloud computing services. The as a service offering typically provides endpoints that various customers interface with. These endpoints are typically based on a set of APIs. One category of as-a-service offerings is Platform as a Service (PaaS), where a service provider provisions, instantiates, runs, and manages modular bundles of code that customers can use to instantiate a computing platform and one or more applications without the complexity of building and maintaining the infrastructure typically associated with them. Another category is Software as a Service (SaaS), where software is centrally hosted and allocated on a subscription basis. SaaS is also known as on-demand software, web-based software, or web-hosted software.The four technical subfields involved in cloud services are: deployment, integration, on-demand, and virtual private networks. Systems and processes for rapid migration of containers and data from old servers to new servers

[0036] Figure 2 is a block diagram of modules included in the code included in the system of Figure 1, according to an embodiment of the present invention. Code 200 includes a container analysis module 202, a container migration module 204, and a container verification module 206.

[0037] The container analysis module 202 is configured to extract image metadata information from the images of containers being migrated from the first server (i.e., the old server) to the second server (i.e., the new server). In one embodiment, the container analysis module 202 is configured to execute the docker inspect command and extract the image metadata contained in the output of the docker inspect command.

[0038] The container analysis module 202 is further configured to extract and analyze information relating to the migration of containers (also referred to herein as migration-related information), where the migration-related information is extracted from the extracted image metadata. In one embodiment, the extracted migration-related information includes configuration information relating to the base image, volume mounts, ports, image versions, port mappings, volume mappings, volume permissions, etc.

[0039] The container analysis module 202 is further configured to create a new manifest (i.e., a migration manifest) containing migration information based on the extracted and analyzed migration-related information. For example, the migration information included in the new manifest may include details about volumes, ports, images, application versions, volume permissions, and probes required for container migration.

[0040] The container migration module 204 is configured to automatically generate a startup command (e.g., a docker run command) by analyzing the metadata of the container to be migrated and combining the analyzed metadata with other metadata of the container provided by the new manifest, new service port information, and disk usage information.

[0041] The container migration module 204 is further configured to detect port or mounted volume (i.e., disk) conflicts associated with the container migration. In response to a conflict being detected, the container migration module 204 is configured to automatically find available ports or mounted volumes in the new server.

[0042] The container migration module 204 is further configured to detect the software version (i.e., the application version or image version) in cases where a previous software version is being updated, and to add a new tag to the image parameters of the startup command (e.g., the docker run command), where the new tag indicates the detected updated software version (e.g., a tag in the format <old hostname>-<application version>).

[0043] Container migration module 204 is further configured to automatically upload associated media such as disks and images to directories on the new server based on the analyzed metadata of the container. If directory conflicts exist, container migration module 204 automatically creates a new directory and modifies the manifest to include that new directory.

[0044] The container migration module 204 is further configured to start the service on the new server by executing the startup command described above (for example, the docker run command).

[0045] The container verification module 206 is configured to automatically verify the legacy server through the use of probes such as httpGet liveProbe, tcpSocket probes, and predefined exec commands. In one embodiment, the container verification module 206 verifies the legacy server by performing a probe verification method using software-based probes. The container verification module 206 uses the probes to determine whether the migrated container is running successfully (i.e., the container is operational and healthy). If the migrated container is running successfully, the container verification module 206 determines that the migration was successful and the migrated container is ready for testing or use.

[0046] In one embodiment, the container verification module 206 verifies the old server to determine that the container is running successfully by (1) using httpGet liveProbe on the container if an outbound port exists on the old server, and then using a tcpSocket probe on the container if httpGet liveProbe fails; or (2) using a predefined exec command if an outbound port does not exist on the old server.

[0047] The container verification module 206 is further configured to automatically select a probe verification method that is deemed highly reliable based on the fact that the probe verification method successfully determined that the container is operational and healthy (i.e., has passed probe verification).

[0048] The container validation module 206 is further configured to validate the new server through a reliable validation method (e.g., a probe validation method determined to be highly reliable). If the validation of the new server fails, an abnormal container startup within the new server is indicated, and the container migration module 204 and the container validation module 206 repeat the migration and validation steps for the containers, respectively.

[0049] The functions of the modules included in Code 200 are described in more detail in the discussion presented below in relation to Figures 3, 4, 5, 6, 7, 8, and 9.

[0050] Figure 3 is a flowchart of a process for rapidly migrating containers and data to a new server according to an embodiment of the present invention, where the operation of the flowchart is performed by the module in Figure 2. The process in Figure 3 starts at the starting node 300. Containers are running on the old server, and the old server needs to be shut down or moved to another location. Therefore, services running within the containers on the old server need to be moved from the old server to the new server via the migration of the containers to the new server. Before step 302, the containers to be migrated from the old server to the new server are generated by a compose command (e.g., the docker compose command), or by another command, or by a configuration file that specifies the configuration and startup method of the containers, and further specifies the sequence in which multiple containers are started. Furthermore, the compose file obtained as a result of executing the compose command, or the aforementioned configuration file, is missing and inaccessible at the time the container migration is required. Therefore, the missing compose file or configuration file is not used for the migration of containers from the old server to the new server; instead, the novel method described in the process of Figure 3 is used.

[0051] In step 302, the container analysis module 202 extracts image metadata from the images of containers being migrated from the old server to the new server.

[0052] In step 304, the container analysis module 202 extracts and analyzes information from the image metadata retrieved in step 302, where the extracted information is related to container migration.

[0053] In step 306, the container analysis module 202 creates a new manifest containing migration information based on the information extracted and analyzed in step 304.

[0054] In step 308, the container migration module 204 analyzes the metadata of the container to be migrated and generates a new startup command (e.g., a docker run command) by combining the analyzed metadata with other metadata of the container, new service port information, and disk usage information.

[0055] In step 308, the container migration module 204 also detects any existing conflicts, where a conflict indicates that a port or disk used on the old server is already occupied on the new server before the container migration to the new server is complete. If the container migration module 204 detects that a conflict exists, it automatically finds a new port or disk that is available on the new server and can be used to complete the migration of the container.

[0056] In step 308, the container migration module 204 also detects the software version of the image of the container to be migrated and automatically adds a new tag to the image parameters of the new startup command, where the new tag indicates the detected software version.

[0057] In step 310, the container migration module 204 uploads media, including disks and images, to a directory on the new server based on the container metadata analyzed in step 308. The container migration module 204 determines whether directory conflicts exist, and if so, automatically creates a new directory and modifies the manifest using the newly created directory.

[0058] In step 312, the container migration module 204 starts the service on the new server by executing a new startup command generated via the new manifest.

[0059] In step 314, the container verification module 206 verifies the startup of containers in the new server, where starting the server in step 312 is included in the startup to be verified. In step 314, the container verification module 206 automatically verifies the old server through the use of a software-based probe that implements the following verification rules.

[0060] (1) If an outbound port exists, validate the container using httpGet liveProbe, and then use tcpSocket probe if httpGet liveProbe fails.

[0061] (2) If no outbound port exists, the container's validity is verified using a predefined exec command.

[0062] In step 314, the container validation module 206 automatically selects a probe validation method. If the probe validation is successful, this is an indicator of the reliability of the validation method.

[0063] In step 314, the container validation module 206 validates the new server through a reliable validation method. If validation fails, an abnormal container startup is indicated, and the container migration module 204 and the container validation module 206 repeat the container migration and validation, respectively.

[0064] In response to the container verification module confirming the validity of the services provided by the migrated containers in the new server, the computer system, including modules 202, 204, and 206, safely shuts down the old server. The computer system then invokes the migrated containers in the new server to provide the aforementioned services to the user.

[0065] Figure 4 is a block diagram of an overall workflow 400 that performs the operations in the process of Figure 3 using the modules in Figure 2, according to an embodiment of the present invention. Workflow 400 includes a container analysis module 202, a container migration module 204, and a container validation module 206. The container analysis module 202 receives a docker manifest 402 (for example, a JavaScript® Object Notation (JSON) file that stores metadata about a group of files containing a container image). JavaScript is a registered trademark of Oracle America, Inc., Redwood Shores, California.

[0066] The container analysis module 202 generates a Docker migration manifest 404 (also referred to herein as a new manifest) by using the Docker manifest 402.

[0067] The container migration module 204 analyzes metadata from the Docker migration manifest 404, which includes information about the old server 406, image 408 (i.e., the image of the container on the old server), and volume 410 (i.e., the volume specified by the container on the old server). Using the old server 406, image 408, and volume 410 received from the migration manifest, detection of any conflicts in ports or volumes, determination of updated software versions for the image, and generation of tags indicating the updated software versions, the container migration module 204 generates the new server 412, tagged image 414, and volume 416 with a new path. The new server 412 is the server to which the containers are migrated. The tagged image 414 is the identifier of the image of the container on the new server 412, combined with a tag indicating the updated software version. Volume 416 with a new path specifies a new path for the volume on the new server 412 that resolves previously detected volume conflicts.

[0068] The container verification module 206 verifies container 418 on the old server 406 using probe 420 and determines a reliable verification method. The container verification module 206 then verifies the validity of container 424 in the new server 412 using a reliable verification method that employs probe 422 (which is included in probe 420).

[0069] Figure 5 shows an example of a special data structure 500 used as a new image manifest in the process of Figure 3 according to an embodiment of the present invention. The special data structure 500 is the result of an inspect command (e.g., the docker inspect command or the podman inspect command) and includes a new migration section 502 containing new parameters that specify the following information necessary for container migration: volume mapping, port mapping, image mapping, application version mapping, volume permission mapping, and probes. The new parameters in Figure 5 are not included in conventional manifest files. example

[0070] Figure 6 shows an example 600 of the operation performed by the container analysis module included in the module in Figure 2, according to an embodiment of the present invention, where the operation is included in the process in Figure 3. The container analysis module 202 extracts image metadata information 602 from the docker inspect image command. The container analysis module 202 extracts and analyzes migration-related information 604 from the metadata information 602. The migration-related information 604 includes mapped port 606, port 608, mapped volume 610, volume 612, image 614, volume permissions 616, application version 618, and probe 620. The container analysis module 202 creates a new manifest containing migration information based on the extracted migration-related information 604 by using the docker or podman manifest inspect imageA:1.1 command 622, resulting in the data structure shown in Figure 5.

[0071] Figure 7 shows an example 700 of an operation performed by the container migration module included in the module in Figure 2, according to an embodiment of the present invention, where the operation is included in the process in Figure 3. Example 700 includes an old server 702 (also referred to as server 1) and a new server 704 (also referred to as server 2). The old server 702 includes container 706 (also referred to as container 1 in old server 702), container 708 (also referred to as container 2), and container 710 (also referred to as container 3). The new server 704 includes container 712 (also referred to as container 1 in new server 704), which is the result of migrating container 706 from old server 702 to new server 704.

[0072] Container 706 was originally generated by the docker compose command, but at the time the migration is required, the docker compose file for container 706 is missing and inaccessible, and therefore it cannot be used to migrate container 706 to the new server 704. Container migration module 204 analyzes the container metadata and automatically generates the docker run command (i.e., the startup command). The analysis of the container metadata includes detecting conflicts associated with ports and / or disks (for example, a port or volume identifier used by container 706 in the old server 702 is unavailable on the new server 704 because that identifier is already being used by another container on the new server 704). The analysis of the container metadata further includes detecting updated software versions for the container image. By analyzing the metadata within container 706, container migration module 204 determines that there is one conflict with port 9080 and another conflict with volume / xxx-vol2 (i.e., port 9080 and volume / xxx-vol2 already exist in the new server 704 before the migration of container 706 and are occupied by other services). Furthermore, container migration module 204 determines that port 8080 and volume / xxx-vol, which are included in the metadata of container 706, do not already exist in the new server 704 and are therefore available for use by container 712 after the migration. Container migration module 204 automatically determines that port 9081 is available in the new server 704, so container 712 exposes its services via port 9081 instead of port 9080 after the migration. Additionally, container migration module 204 automatically determines that volume / xxx-vol2-vol is available in the new server 704 for use by container 712 after the migration, instead of the already occupied / xxx-vol2. Furthermore, container migration module 204 determines the updated software version of his-ser-1.3.4.After metadata analysis, container migration module 204 generates a docker run command using port 9081, volume / xxx-vol2-vol, and software version his-ser-1.3.4, as shown in bold in the command presented below.

[0073] docker run--name xproject-nginx-v / xxx-vol: / home:ro-v / xxx-vol2-vol: / config-p9081:8080-d nginx:his-ser-1.3.4

[0074] Figure 8 is an example 800 of additional details of the operation performed by the container migration module in Figure 7 according to an embodiment of the present invention. As described above in the discussion of Figure 7, example 800 includes an old server 702, a new server 704, a container 706, and a container 712. Example 800 also includes mapping data that maps volumes 802, 804, and image 806 to volumes 808, 810, and image 812, respectively. This is so that the container migration module 204 can determine that there is no conflict with respect to volume / xxx-vol (i.e., at the start of the migration of container 706, the directory name / xxx-vol is available in the new server 704). Furthermore, as part of migrating container 706 from old server 702 to new server 704 so that it becomes the migrated container 712, container migration module 204 uses the Secure Copy Protocol (SCP) to copy the data in directory / xxx-vol on old server 702 to a directory with the same name on new server 704 (i.e., directory / xxx-vol on new server 704).

[0075] Container migration module 204 determines that a conflict exists regarding / xxx-vol2 (i.e., the directory name / xxx-vol2 is already in use on the new server 704 before and at the start of the migration of container 706). Therefore, container migration module 204 identifies the directory / xxx-vol2-vol as an available directory on the new server 704, and as a result, / xxx-vol2 is mapped to / xxx-vol2-vol. As part of migrating container 706 to the new server 704 to become the migrated container 712, container migration module 204 uses scp to copy the data in the directory / xxx-vol2 on the old server 702 to the directory / xxx-vol2-vol on the new server 704. Furthermore, container migration module 204 automatically updates the metadata from / xxx-vol2 in container 706 to / xxx-vol2-vol in the migrated container 712.

[0076] Container migration module 204 also updates the image by using scp to copy image 806 to image 812 in the new server 704 and replacing "latest" with "his-ser-1.3.4" (i.e., a new tag automatically provided by container migration module 204). Furthermore, container migration module 204 automatically updates the metadata from "nginx:latest" in container 706 to "nginx:his-ser-1.3.4" in the migrated container 712.

[0077] The container migration module 204 includes updated metadata within the run command, as indicated by the bold type in the docker run command shown in Figure 8. The container migration module 204 executes the aforementioned run command to start the migrated container 712 on the new server 704.

[0078] Figure 9 shows an example 900 of an operation performed by the container verification module included in the module in Figure 2, according to an embodiment of the present invention, where the operation is included in the process in Figure 3. As described above in the discussion of Figure 7, example 900 includes an old server 702, a new server 704, a container 706, and a container 712. After the container migration module 204 starts the migrated container 712 in the new server 704 by executing the docker run command shown in Figure 8, the container verification module 206 automatically selects a verification method using a software-based probe 902 and verifies the validity of the new server 704 by performing a reliable validation method.

[0079] The container verification module 206 automatically verifies the old server 702 by selecting (for example, randomly selecting) a service within container 706 running within the old server 702, testing the selected service using probe 902, and applying verification rules. In one embodiment, probe 902 and verification rules are employed by the container verification module 206 as described above in the discussion of Figures 2 and 3. Based on the determination that the probe verification passed (i.e., that container 706 is operational and normal), the container verification module 206 automatically selects a probe verification method that is determined to be highly reliable. The container verification module 206 verifies the validity of the new server 704 by using a highly reliable validation method on a service running within container 712 that is identical to the selected service within container 706. The container verification module 206 executes the highly reliable validation method and determines that the behavior of the service within container 712 is consistent with the behavior of the selected service within container 706.

[0080] In other embodiments, the container verification module 306 uses other probes in addition to, or instead of, the probes listed in probe 902.

[0081] While various embodiments of the present invention have been presented herein for illustrative purposes, they are not intended to be comprehensive or to limit the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been selected to best describe the principles, practical applications, or technical improvements to the technologies available on the market, or to enable other those skilled in the art to understand the embodiments disclosed herein.

Claims

1. A computer implementation method, The stage of extracting image metadata from container images being migrated from the old server to the new server; The step of extracting information regarding container migration from the extracted image metadata and analyzing the extracted information; The next step is to create a new manifest containing migration information based on the previously analyzed and extracted information; A step of analyzing the metadata of the container and generating a new startup command by combining the analyzed metadata of the container with other metadata of the container, new service port information, and disk usage; The step of uploading media, including disks and images, to a directory in the new server based on the analyzed metadata of the container; The step of starting the service within the new server by executing the new startup command; and The step of verifying the startup of the container in the new server, where the step of starting the service is included in the startup, A method for providing this.

2. The method according to claim 1, wherein the steps of extracting the image metadata, extracting the information relating to migrating the container, creating the new manifest, analyzing the extracted information, analyzing the metadata of the container, generating the new startup command, uploading the media, starting the service, and verifying the startup of the container provide completion of the migration of the container from the old server to the new server without using and having access to the compose file associated with the old server, wherein the compose file includes information relating to configuring the container in the old server and information relating to starting the container in the old server in a specified sequence.

3. A step of detecting a conflict between the old server and the new server by determining, based on the analyzed metadata, that a port used by a service provided by the container in the old server has an identifier that was already in use by another service in the new server before the migration of the container from the old server to the new server; and In response to the step of detecting the aforementioned conflict, the step of automatically identifying another available port within the new server, wherein the step of generating the new startup command includes the step of inserting the identified other port into the new startup command. The method according to claim 1, further comprising:

4. A step of detecting a conflict between the old server and the new server by determining, based on the analyzed metadata, that a mounted volume used by the service provided by the container in the old server has an identifier that was already in use by another service in the new server before the migration of the container from the old server to the new server; and In response to the step of detecting the aforementioned conflict, the step of automatically identifying another mount volume available within the new server, wherein the step of generating the new boot command includes the step of inserting the identified other mount volume into the new boot command. The method according to claim 1, further comprising:

5. Based on the analyzed metadata, the step of detecting updates to the software versions used by the services provided by the containers in the old server; and In response to the step of detecting the update, a step of automatically identifying a new tag specifying the update of the software version, wherein the step of generating the new startup command includes a step of inserting the new tag for specifying the update of the software version. The method according to claim 1, further comprising:

6. (i) a step of automatically verifying the container in the old server by using httpGet liveProbe if an outbound port exists in the old server, and using a tcp socket probe if httpGet liveProbe fails, or (ii) using a predefined exec command; and Based on the step of verifying the container in the old server, there is a step of automatically selecting a probe verification method, where the step of verifying the startup of the container in the new server includes a step of confirming the validity of the new server by using the selected probe verification method. The method according to claim 1, further comprising:

7. The steps for verifying the validity of the new server are as follows: The selected probe verification method determines that the validation of the new server has failed, and that the failure of the validation is an indicator that the startup of the container in the new server is abnormal; and In response to the indicator that the startup of the container in the new server is abnormal, the process of migrating the container and verifying its validity is repeated. The method according to claim 6, including the method described in claim 6.

8. Processor set; One or more computer-readable storage media; and Program instructions stored on one or more computer-readable storage media The program instructions are provided to the processor set: Procedure for extracting image metadata from container images being migrated from the old server to the new server; A procedure for extracting information regarding container migration from the extracted image metadata and analyzing the extracted information; A procedure for creating a new manifest containing migration information based on the previously analyzed and extracted information; A procedure for generating a new startup command by analyzing the metadata of the container and combining the analyzed metadata of the container with other metadata of the container, new service port information, and disk usage; A procedure for uploading media, including disks and images, to a directory on the new server based on the analyzed metadata of the container; The procedure for starting the service within the new server by executing the aforementioned new startup command; and A procedure for verifying the startup of the container in the new server, wherein the procedure for starting the service is included in the startup. A computer system that causes an operation to be performed.

9. The computer system according to claim 8, wherein the steps of extracting the image metadata, extracting the information relating to migrating the container, creating the new manifest, analyzing the extracted information, analyzing the metadata of the container, generating the new startup command, uploading the media, starting the service, and verifying the startup of the container provide the completion of the migration of the container from the old server to the new server without using and having access to the compose file associated with the old server, wherein the compose file includes information relating to configuring the container in the old server and information relating to starting the container in the old server in a specified sequence.

10. The aforementioned operation is: A procedure for detecting a conflict between the old server and the new server by determining, based on the analyzed metadata, that a port used by a service provided by the container in the old server has an identifier that was already in use by another service in the new server before the migration of the container from the old server to the new server; and A procedure for automatically identifying another available port within the new server in response to the procedure for detecting the aforementioned conflict, wherein the procedure for generating the new startup command includes a procedure for inserting the other identified port into the new startup command. The computer system according to claim 8, further comprising:

11. The aforementioned operation is: A procedure for detecting a conflict between the old server and the new server by determining, based on the analyzed metadata, that a mounted volume used by the service provided by the container in the old server has an identifier that was already in use by another service in the new server before the migration of the container from the old server to the new server; and A procedure for automatically identifying another mount volume available within the new server in response to the procedure for detecting the aforementioned conflict, wherein the procedure for generating the new boot command includes a procedure for inserting the identified other mount volume into the new boot command. The computer system according to claim 8, further comprising:

12. The aforementioned operation is: A procedure for detecting updates to the software versions used by the services provided by the containers in the old server, based on the analyzed metadata; and A procedure for automatically identifying a new tag specifying the update of the software version in response to the procedure for detecting the update, wherein the procedure for generating the new startup command includes a procedure for inserting the new tag for specifying the update of the software version. The computer system according to claim 8, further comprising:

13. The aforementioned operation is: A procedure for automatically verifying the container in the old server by (i) using httpGet liveProbe if an outbound port exists in the old server, and using a tcp socket probe if httpGet liveProbe fails, or (ii) using a predefined exec command; and A procedure for automatically selecting a probe verification method based on the procedure for verifying the container in the old server, wherein the procedure for verifying the startup of the container in the new server includes a procedure for confirming the validity of the new server by using the selected probe verification method. The computer system according to claim 8, further comprising:

14. The procedure for verifying the validity of the new server is as follows: A procedure for determining that the validation of the new server has failed by using the selected probe validation method, the failure of the validation being an indicator that the startup of the container in the new server is abnormal; and A procedure to repeat the migration and validation of the container in response to the indicator that the startup of the container in the new server is abnormal. The computer system according to claim 13, including the computer system according to claim 13.

15. To the processor: Procedure for extracting image metadata from container images being migrated from the old server to the new server; A procedure for extracting information regarding container migration from the extracted image metadata and analyzing the extracted information; A procedure for creating a new manifest containing migration information based on the previously analyzed and extracted information; A procedure for generating a new startup command by analyzing the metadata of the container and combining the analyzed metadata of the container with other metadata of the container, new service port information, and disk usage; A procedure for uploading media, including disks and images, to a directory on the new server based on the analyzed metadata of the container; The procedure for starting the service within the new server by executing the aforementioned new startup command; and A procedure for verifying the startup of the container in the new server, wherein the procedure for starting the service is included in the startup. A computer program designed to execute something.

16. The computer program according to claim 15, wherein the steps of extracting the image metadata, extracting the information relating to migrating the container, creating the new manifest, analyzing the extracted information, analyzing the metadata of the container, generating the new startup command, uploading the media, starting the service, and verifying the startup of the container provide the completion of the migration of the container from the old server to the new server without using and having access to the compose file associated with the old server, wherein the compose file includes information relating to configuring the container in the old server and information relating to starting the container in the old server in a specified sequence.

17. To the aforementioned processor: A procedure for detecting a conflict between the old server and the new server by determining, based on the analyzed metadata, that a port used by a service provided by the container in the old server has an identifier that was already in use by another service in the new server before the migration of the container from the old server to the new server; and A procedure for automatically identifying another available port within the new server in response to the procedure for detecting the aforementioned conflict, wherein the procedure for generating the new startup command includes a procedure for inserting the other identified port into the new startup command. The computer program according to claim 15, which further executes the following.

18. To the aforementioned processor: A procedure for detecting a conflict between the old server and the new server by determining, based on the analyzed metadata, that a mounted volume used by the service provided by the container in the old server has an identifier that was already in use by another service in the new server before the migration of the container from the old server to the new server; and A procedure for automatically identifying another mount volume available within the new server in response to the procedure for detecting the aforementioned conflict, wherein the procedure for generating the new boot command includes a procedure for inserting the identified other mount volume into the new boot command. The computer program according to claim 15, which further executes the following.

19. To the aforementioned processor: A procedure for detecting updates to the software versions used by the services provided by the containers in the old server, based on the analyzed metadata; and A procedure for automatically identifying a new tag specifying the update of the software version in response to the procedure for detecting the update, wherein the procedure for generating the new startup command includes a procedure for inserting the new tag for specifying the update of the software version. The computer program according to claim 15, which further executes the following.

20. To the aforementioned processor: A procedure for automatically verifying the container in the old server by (i) using httpGet liveProbe if an outbound port exists in the old server, and using a tcp socket probe if httpGet liveProbe fails, or (ii) using a predefined exec command; and A procedure for automatically selecting a probe verification method based on the procedure for verifying the container in the old server, wherein the procedure for verifying the startup of the container in the new server includes a procedure for confirming the validity of the new server by using the selected probe verification method. The computer program according to claim 15, which further executes the following.

Images