Patent ID: 12236283

DETAILED DESCRIPTION

A distributed computing environment may include a first container executing on a first node and a second container executing on a second node. The first node may include a first computer architecture and the second node may include a second computer architecture. During a development process, changes may be made to the first container that may not be reflected in the second container. The development process may include adding a software package to the first container that may not be included in the second container. Alternatively, the development process may include removing a software package from the first container that may be included in the second container. It may be desirable to propagate the changes from the first container to the second container. But certain security protocols may prevent communication among the first node and the second node due to the mismatching computer architectures. This can be problematic because it can prevent the changes in the first container from being propagated to the second container. Additionally, modifications made during a development process may result in differences between a first runtime environment inside the first container and a second runtime environment inside the second container. For example, the first runtime environment may include a first set of dependencies and the second runtime environment may include a second set of dependencies. It may be desirable to synchronize the first runtime environment and the second runtime environment (e.g., so that they have the same dependencies for use in deploying the same or similar software), but the different computer architectures on the first node and the second node may make it challenging to do so.

Some examples of the present disclosure can overcome one or more of the abovementioned problems by using a sidecar container as a mechanism to transfer configuration data from the first container on the first node to the second container on the second node, thereby allowing the configuration data to be shared between the two containers. A sidecar container may be a container that is used for auxiliary tasks related to primary containers. Sidecar containers may be lightweight and may not consume many computing resources. By using the sidecar container to share configuration data, it may help resolve differences in the runtime environments of the two containers and assist in synchronizing the two containers with one another, particularly in situations where the configuration data cannot be easily transferred from the first node to the second node using conventional approaches (e.g., due to their different computer architectures).

As one example, a software application can be executing on the first node. The software application can receive a notification indicating that modifications have been made to a configuration of the first container running on the first node. In response to receiving the notification, the software application can instantiate a sidecar container on the first node. The sidecar container may be a secondary container. The software application can then issue a command to cause the first container to export its configuration data to the sidecar container. The configuration data may be stored in one or more configuration files, such as JSON files or any other suitable configuration file. After the configuration data has been exported to the sidecar container, the software application can cause the sidecar container to be migrated to the second node, on which the second container is running. Migrating the sidecar container to the second node may be possible in situations where other conventional ways of transmitting configuration data between two nodes may be limited or prevented, for example due to security restrictions.

Once the sidecar container has been migrated to the second node, the second node can extract the configuration data from the sidecar container and begin a rebuild process in relation to the second container running on the second node. The rebuilding process can involve building the image file for the second container again using some new or modified information, such as the configuration data. In some examples, the rebuild process may also involve shutting down the running second container and redeploying it using the rebuilt image file. In other examples, the rebuild process may occur during a runtime of the second container, without the second container having to be shut down. Either way, the second container can be reconfigured using the configuration data via the rebuild process. Using these techniques, the configuration of the second container can be quickly and easily synchronized with the configuration of the first container.

These illustrative examples are given to introduce the reader to the general subject matter discussed here and are not intended to limit the scope of the disclosed concepts. The following sections describe various additional features and examples with reference to the drawings in which like numerals indicate like elements but, like the illustrative examples, should not be used to limit the present disclosure.

FIG.1is a block diagram of an example of a system that can transmit configuration data between containers running on different computer architectures via a sidecar container according to some aspects of the present disclosure. The system may include a first node100and a second node120. The first node100and the second node120may be part of a distributed computing environment. The first node100and the second node120may be physical hardware devices (e.g., desktop computers, servers, laptop computers, etc.) that each have a quantity of computing resources allocated to them in the distributed computing environment.

The first node100may include a first container102, and the second node120may include a second container122. The first node100may include a first computer architecture114, and the second node120may include a second computer architecture124that is different from the first computer architecture114. Examples of computer architectures may include x32, x64, ARM, ARM64, and AArch64. The first container102may execute on top of the first computer architecture114, which may have a host operating system that is the same as or different from a guest operating system of the first container102. Similarly, the second container122may execute on top of the second computer architecture124, which may have a host operating system that is the same as or different from a guest operating system of the second container122. Certain security protocols may prevent the first container102from transmitting (e.g., directly or via an established communication pathway) configuration data106to the second container122due to a mismatch between the first computer architecture114and the second computer architecture123. For example, a port used by the first node100to transmit data to the second node120may be filtered or blocked (e.g., by a firewall or another networking device), thereby preventing the first container102from easily communicating with the second container122.

To help navigate around the abovementioned security restrictions, in some examples the first node100may include a software application115. The software application115may include an exporter sidecar service. The software application115can detect an event indicating that configuration data106is to be transferred from the first container102to the second container122. Examples of events may include receipt of a request (from a user or another software program), a configuration change to the first container102, passage of a time period, etc. The configuration data106may be stored in one or more configuration files, such as JSON or YAML files. The configuration data106can include setting values and other information characterizing the runtime environment of the first container102. In response to detecting the event, the software application115may instantiate a sidecar container104on the first node100. For example, the software application115may issue a command for causing the sidecar container104to be instantiated on the first node100. The sidecar container104may be different from the first container102and the second container122. For example, the first container102and the second container122may be primary containers. The sidecar container104may be a secondary container, such as sidecar container corresponding to a sidecar pattern. It will be appreciated that although some examples are described herein with reference to a sidecar container, any suitable type of container may be used to perform the functions described herein with respect to the sidecar container.

Once the sidecar container104has been instantiated, the software application115can initiate a process for copying the configuration data106from the first container102to the sidecar container104. For example, the software application115may transmit a command for causing the first container102to export the configuration data106to the sidecar container104. The configuration data106can be exported to the sidecar container104during the runtime of the first container102and the sidecar container104. The software application115may monitor the transfer of the configuration data106to the sidecar container104and detect when the process is complete.

After the configuration data106has been stored in the sidecar container104, the software application115can initiate a migration of the sidecar container104to the second node120. The migration may involve retrieving data from a first instance of the sidecar container104while it is running on the first node100, and using the data to instantiate a second instance of the sidecar container104on the second node120. The migration may involve shutting down the first instance of the sidecar container104once the second instance of the sidecar container104is running. Security restrictions that may prevent communication among the first node100and the second node120may not prevent the migration, as the sidecar container104may be subject to an exception to the security restrictions. In some examples, the sidecar container104or the data therein may be encrypted before it is transmitted to the second node120.

With the migration process complete, the sidecar container104may now be running on the second node120. The second node120can then transmit the configuration data106from the sidecar container104to the second container122, or otherwise use the configuration data106in the sidecar container104to reconfigure the second container122. In some examples, the second node120can initiate a rebuild of the second container122using the configuration data106. The rebuild process may involve using the configuration data106to update a configuration of the second container122(e.g., during the runtime of the second container122). In some examples, the rebuild process can include updating dependencies related to the second container122. For example, the rebuild process may include updating OS-level dependencies, such as a version of a programing language that can be used by an operating system that may execute on the second container122. The rebuild process may also include installing a software package for use by the second container122. After the rebuild process is complete, the second node120may shut down or destroy the sidecar container104.

In some examples, the sidecar container104may be used to store backups of the first container102or the second container122, additionally or alternatively to being used to transfer configuration data106between the two containers102,122. For example, the first node100can store a backup107of the first container102in the sidecar container104when it is running on the first node100. As another example, the second node120can store a backup107of the second container122in the sidecar container104when it is running on the second node120. The backup107can include data contained in the first container102or second container122, respectively. The backup107may be automatically and periodically generated from contents of the first container102or the second container122, for example in response to certain events, and stored in the sidecar container104. Thereafter, the first node100or the second node120may be redeployed or reconfigured using the backup107from the sidecar container104.

In some examples, the sidecar container104may be promoted to a primary status on the second node120and the second container122may be shut down, for example rather than rebuilding the second container122using the configuration data106. Because the sidecar container104already includes the configuration data106, the sidecar container104can serve as a properly configured replacement for the second container122. The sidecar container104may include processes or services in addition to the configuration data106, which may allow the second node120to seamlessly transition from executing processes (e.g., services) in the second container122to executing processes in the sidecar container104.

FIG.2is a block diagram of an example of a system that can transmit configuration data between containers running on different computer architectures via a sidecar container according to some aspects of the present disclosure. The system can include a first node100and a second node120, as mentioned above. The first node100can include a processor200that is communicatively coupled to a memory202. The processor200and memory202may be integrated into a single housing or may be distributed from one another.

The processor200can include one processor or multiple processors. Non-limiting examples of the processor200include a Field-Programmable Gate Array (FPGA), an application-specific integrated circuit (ASIC), a microprocessor, etc. The processor200can execute instructions209stored in the memory202to perform one or more operations. In some examples, the instructions209can include processor-specific instructions generated by a compiler or an interpreter from code written in any suitable computer-programming language, such as C, C++, C#, etc.

The memory202can include one memory device or multiple memory devices. The memory202can be volatile or non-volatile, in that the memory202can retain stored information when powered off. Non-limiting examples of the memory202include electrically erasable and programmable read-only memory (EEPROM), flash memory, or any other type of non-volatile memory. At least a portion of the memory device includes a non-transitory computer-readable medium. A computer-readable medium can include electronic, optical, magnetic, or other storage devices capable of providing the processor200with the instructions209or other program code. Non-limiting examples of a non-transitory computer-readable medium include magnetic disks, memory chips, ROM, random-access memory (RAM), an ASIC, a configured processor, optical storage, or any other medium from which a computer processor can read the instructions209.

The first node100and the second node120may be part of a distributed computing environment. The first node may include a first container102, and the second node120may include a second container122. The first node100may include a have a different computer architecture than the second node120. Certain security protocols may prevent the first container102from transmitting configuration data106to the second container122due to a mismatch between the different computer architectures.

In some examples, the processor204can provide configuration data106from the first container102to the second container122. The processor204can provide the configuration data106from the first container102to the second container122in response to a request. The processor204can also instantiate the sidecar container104on the first node100, for example in response to the request. The processor204can then transmit the configuration data106to the sidecar container104. The processor204can then migrate the sidecar container from the first node100to the second node120. The second node120may be configured to provide the configuration data106from the sidecar container104to the second container122(e.g., once the migration is complete).

FIG.3is a block diagram of an example of a system that can transmit configuration data between containers running on different computer architectures via a sidecar container according to some aspects of the present disclosure. The system can include a first node100and a second node120, as mentioned above. The first node100may have a different computer architecture from the second node120, and the second node120may have the same computer architecture as a third node300.

The first node100, second node120, and third node300may be parts of a distributed computing environment. For example, the first node100may be a first server, the second node120may be a second server, and the third node300may be a third server. Alternatively, the first node100may be part of a first distributed computing environment, and the second node120and third node300may be part of a second distributed computing environment. The first distributed computing environment and the second distributed computing environment may require their respective nodes to run on different computer architectures.

Certain security protocols may prevent the first container102from transmitting (e.g., directly or via an established communication pathway) configuration data106to the second node120due to a mismatch between their different computer architectures. The first container102may also be unable to transmit the configuration data106to the third node300based on the security protocols or for other reasons. But, the security protocols may allow the second node120to transmit the configuration data106to the third node300, which may need the configuration data106(e.g., to synchronize the first container102with the second container122thereon). So in some examples, the first node100can provide the configuration data106to the second node120via the sidecar container104, at which point the second node120can transmit the configuration data106to the third node300using means other than the sidecar container104. Through this daisy chain, the first node100can supply the third node300with the configuration data106.

The second container122may be present on the third node300. The second container122may be configured based on the configuration data106received from the second node120. The configuration data106may be stored in one or more configuration files, such as JSON or YAML files. The configuration data106can include setting values and other information characterizing the runtime environment of the first container102. The configuration data106can include values for environment variables that can modify the second container122. In some examples, the environment variables may include an amount of computing resources to allocate to the second container122, a range of ports that the second container122may use, driver options for the second container122, a memory limit for the second container, or a namespace for the second container122.

As noted above, the first node100can initiate an indirect transfer of the configuration data106to the third node300. For example, the first node100may instantiate a sidecar container104. The sidecar container104may be a secondary container. The first node100can transmit the configuration data106to the sidecar container104. The first node100can then initiate a migration of the sidecar container104to the second node120. The second node120can extract the configuration data106from the sidecar container104and transmit the configuration data106(e.g., directly) to the third node300. The third node300can then receive the configuration data106and provide it to the second container122, or otherwise use the configuration data106in relation to the second container122. Through this process, the configuration data106may be indirectly supplied from the first node100to the third node300for enabling the third node300to reconfigure the second container122.

FIG.4is a flow chart of an example of a process for transmitting configuration data between containers running on different computer architectures via a sidecar container according to some aspects of the present disclosure. WhileFIG.4depicts a certain sequence of steps for illustrative purposes, other examples can involve more steps, fewer steps, different steps, or a different order of the steps than is depicted inFIG.4. The steps ofFIG.4are described below with reference to components ofFIG.2.

At block402, a processor200instantiates a first container102and a sidecar container104on a first node100. The second node120can have a second computer architecture124that is different from a first computer architecture114of the first node100.

At block404, the processor200transmits configuration data from the first container to the sidecar container104. The configuration data106may be embedded in a markup file, such as a JSON file, a YAML file, an XML file, or any other suitable markup file. The configuration data106may correspond to a state of the first container102.

At block406, the processor200initiates a migration of the sidecar container104from the first node100to a second node120that has a different computer architecture than the first node. The second node120can provide the configuration data106from the sidecar container104to the second container122subsequent to a completion of the migration.

In some examples, the processor200may also transmit a backup107of the first container102to the sidecar container. The backup107may include the configuration data106as well as runtime data and any other data associated with the first container102. The sidecar container104is different from the first container102and the second container122. The first container102and the second container122may serve as primary containers, whereas the sidecar container104may serve as a secondary container.

In some examples, the sidecar container104may be promoted from a secondary status to a primary status on the second node120. Subsequent to promoting the sidecar container104to a primary status, the second container122may be shut down, for example rather than rebuilding the second container122using the configuration data106. Because the sidecar container104already includes the configuration data106, the sidecar container104can replace the second container122. The sidecar container104may include processes or services in addition to the configuration data106, which may allow the second node120to seamlessly transition from executing processes (e.g., services) in the second container122to executing processes in the sidecar container104.

The foregoing description of certain examples, including illustrated examples, has been presented only for the purpose of illustration and description and is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Numerous modifications, adaptations, and uses thereof will be apparent to those skilled in the art without departing from the scope of the disclosure. For instance, any examples described herein can be combined with any other examples to yield further examples.