Patent Application
20250007777
The present disclosure relates generally to remote node management. More specifically, but not by way of limitation, this disclosure relates to coordinating software modifications for remote node management.
Distributed computing systems (e.g., cloud computing systems, data grids, and computing clusters) have recently grown in popularity given their ability to improve flexibility, responsiveness, and speed over conventional computing systems. In some cases, the responsiveness and speed of distributed computing systems can be further improved by employing edge-computing solutions. Edge computing is a networking philosophy focused on bringing computing power and data storage as close to the source of the data as possible to reduce latency and bandwidth usage. Edge computing solutions involve executing services on nodes (e.g., servers or virtual machines) positioned at physical edges of a computing environment that are geographically close to corresponding client devices, to reduce latency and improve a perceived quality of the services.
Configuration management and automation systems such as Ansible by Red Hat® can be used to manage nodes in an edge computing system. Such configuration management systems can enable infrastructure as code to deploy software (e.g., containers, virtual machines, applications, etc.) to multiple nodes at the same time (e.g., substantially contemporaneously). If issues arise with a node executing the software, the configuration management system can rerun the configuration file to deploy the software again and reestablish the same infrastructure. The configuration management system can also be used to apply software updates across multiple nodes. Such configuration management systems can uniformly deploy software in an “all or nothing” manner across nodes. In some cases, some individual nodes may require local adjustments to the software configuration. But such adjustments may not be replicated when subsequent updates or redeployments are performed by the configuration management system. Or, if the local adjustments are applied to the configuration management system as a whole instead of just being applied to a local node, the adjustments may be incorrectly deployed out to the entire fleet of nodes.
Some examples of the present disclosure can overcome one or more of the abovementioned problems via a conversion engine that can convert commands for adjusting software configuration on a local node to commands compatible with the software entity deployed by a configuration management system. When the configuration management system redeploys the software to nodes (including the local node with the local modification), the conversion engine can insert the converted commands into the configuration file for the software file for that particular node. Thus, the local modification can be applied to the associated node, without being applied to other nodes managed by the configuration management system. Individualized code modifications can therefore be applied in updates directly from configuration management systems, without requiring multiple steps of updating via the configuration management system and then updating configuration files for the software.
In one particular example, a control node can execute an Ansible playbook to install containers on nodes in a distributed computing environment. The Ansible playbook can define a default installation process for installing the container across the various nodes. The container itself can be installed according to a configuration file, such as a Containerfile. After the control node installs the container on the nodes, a configuration adjustment may be made to a container on one of the nodes. For example, a local system administrator may modify container code using Ansible commands to improve node performance. A conversion engine monitoring the distributed computing environment can detect the code modification and convert the Ansible commands into Containerfile compatible commands.
To use the Containerfile compatible commands in a subsequent container deployment, the conversion engine can attach metadata to the Ansible playbook to create a mapping between the Ansible playbook, the Containerfile, and the code modifications for the first node. When the control node re-executes the Ansible playbook at a subsequent time to re-deploy the container to the nodes, the metadata can be used to determine that code modifications are to be applied to the first node. For example, the code modifications (converted to be compatible with Containerfile) can be applied to the specific Containerfile used to create the container on the first node. Thus, the container can be updated directly from the Ansible playbook along with the changes previously applied to the first node.
Illustrative examples are given to introduce the reader to the general subject matter discussed herein 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, and directional descriptions are used to describe the illustrative aspects, but, like the illustrative aspects, should not be used to limit the present disclosure.
The distributed computing environment 100 can include a control node that can manage the first node 104a and the second node 104b. Examples of the nodes can include a desktop computer, a laptop computer, a server, a mobile phone, a tablet, etc. The control node 102 can control deployment of instances 106a-b of a software entity on the nodes 104a-b using a configuration management system such as Ansible by Red Hat®. For example, the control node 102 can use a first configuration file 108 (e.g., an Ansible playbook) to automate deployment of the software entity. The first configuration file 108 can include a list of tasks that the control node 102 can execute to deploy the software entity to the nodes 104a-b or to containers or virtual machines executing on the nodes 104a-b. The first configuration file 108 can also be executed to deploy updates and configure networking, security, user management, and cloud management for the distributed computing environment 100.
The control node 102 can execute the first configuration file 108 to deploy instances 106a-b of a software entity, such as a container, virtual machine, application, or any other type of software service to both of the nodes 104a-b. For example, copies of the first configuration file 108 can be pushed down to the nodes 104a-b. The first configuration file 108 can dictate that an instance 106 of a software entity is to be built according to a second configuration file 112 from a software repository 118. For example, the software entity may be a container, the second configuration file 112 may be a container specification file, and the software repository 118 may be a container registry. Instances of the same container build from the container specification file may be built on each of the first node 104a and the second node 104b. But in some examples, configuration of the first node 104a may be adjusted (e.g., manually by a user or as part of an automated process) after the first instance 106a is deployed.
For example, a copy of the first configuration file 108 (e.g., Ansible playbook) on the first node 104a may be modified to change a value in the first configuration file 108:
The above commands for the code modification 114 are written in Ansible command format, and are not compatible with the second configuration file used to build the container (e.g., Containerfile commands). Additionally, further software deployments by the control node to the nodes 104a-b may not include the code modification 114, requiring the code modification 114 to be manually applied after each software deployment. Thus, the conversion engine 110 can be used to monitor the nodes 140a-b for code modifications.
For example, the conversion engine 110 can monitor adjustments to the first configuration file 108 on the nodes 104a-b. In some examples, the conversion engine 110 may detect the code modification 114 in response to the nodes 104a-b sending an alert for the code modification 114. That is, not all code modifications 114 may be detected and addressed by the conversion engine 110, such as code modifications 114 made for security, privacy, compliance, or regulatory reasons. Thus, the nodes 104a-b may have local control over what code modifications 114 are propagated to subsequent software deployments.
After detecting the code modification 114 to the first configuration file 108, the conversion engine 110 can convert the code modification 114 from the first format 116a to a second format 116b. In the example stated above, the code modification 114 was in a first format 116a of Ansible commands. But, the second configuration file 112 may be in a different, second format 116b of Containerfile commands. Thus, the conversion engine 110 can access a lookup table that maps Ansible commands to Containerfile commands to convert to the second format 116b (e.g., by converting the Ansible replace module with a ‘sed’ Containerfile command):
Such commands in the second format 116b are compatible with the second configuration file 112. The conversion engine 110 can generate metadata 113 that can be attached to the first configuration file 108 to create a mapping between the converted code modification 114 and the second configuration file 112 for the first node 104a. For example, the metadata 113 may include a unique identifier for the container on the first node 104a. Subsequently, when the control node 102 pushes out another software deployment to the nodes 104a-b, the conversion engine 110 can detect this and can cause the code modification 114 to be applied solely to the first node 104a.
For example, after detecting that the control node 102 is executing the first configuration file 108 to redeploy instances 106a-b of the software entity, the conversion engine 110 or the control node 102 can insert the converted commands for the code modification 114 (e.g., in the second format 116b that is compatible with the second configuration file 112) into the second configuration file 112 when building the container on the first node 104a. The converted commands for the code modification 114 may not be injected into the second configuration file 112 when building the container on the second node 104b. Thus, the settings specific to the first node 104a can be maintained on the first node 104a, even for subsequent software deployments, by inserting converted commands into a specific configuration file. In other words, the first configuration file (e.g., Ansible playbook) can have exclusion capabilities to limit the code modification 114 to a subset of nodes for a software deployment.
In some examples, after the control node 102 has successfully redeployed the software entity using the code modification 114, the conversion engine 110 may update the second configuration file 112 to include the converted code modification 114. In such an example, the updated second configuration file 112 can be stored in the software repository 118 for use in subsequent deployments. Additionally, the metadata 113 indicating the code modification 114 can be discarded from the first configuration file 108. This can ensure a single source of truth for the modified container to reduce security risks and avoid conflicting instructions for implementing the code modification 114.
The next time the software entity (e.g., container) is built on the first node 104a, the changes originally made to the first configuration file 108 can be built in to the second configuration file 112. The metadata 113 can be discarded by the conversion engine 110, the control node 102, or any other entity in the distributed computing environment 100 such as a tower or a git repository. In one example, web-hooks may be used to notify when a new container with the code modification 114 has been built, prompting the update of the second configuration file 112 and removal of the metadata 113 from the first configuration file 108.
While
The processing device 202 can include one processing device or multiple processing devices. Non-limiting examples of the processing device 202 can include a Field-Programmable Gate Array (FPGA), an application-specific integrated circuit (ASIC), and a microprocessor. The processing device 202 can execute instructions 206 stored in the memory 204 to perform computing operations. In some examples, the instructions 206 can 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 memory 204 can include one memory or multiple memories. The memory 204 can be non-volatile and may include any type of memory that retains stored information when powered off. Non-limiting examples of the memory 204 include electrically erasable and programmable read-only memory (EEPROM), flash memory, or any other type of non-volatile memory. At least some of the memory 204 can include a non-transitory computer-readable medium from which the processing device 202 can read instructions 206. A computer-readable medium can include electronic, optical, magnetic, or other storage devices capable of providing the processing device 202 with computer-readable instructions or other program code. Non-limiting examples of a computer-readable medium include magnetic disk(s), memory chip(s), ROM, random-access memory (RAM), an ASIC, a configured processor, optical storage, or any other medium from which a computer processor can read the instructions 206. In some examples, the instructions 206 may correspond to the conversion engine 110 described in
In some examples, the processing device 202 can execute the instructions 206 to perform some or all of the functionality described herein. For example, the processing device 202 can detect, at a first time, a code modification 114 made to a first configuration file 108 on a particular node 210 of a plurality of nodes 212. The first configuration file 108 can be executed by a control node 102 to deploy a software entity 212 to each node of the plurality of nodes 212. The processing device 202 can convert the code modification 114 from a first format 116a associated with the control node 102 to a second format 116b associated with the software entity 212. The processing device 202 can detect, at a second time, the control node 102 executing the first configuration file 108 to deploy the software entity 212 to each node of the plurality of nodes 212 according to a second configuration file 112 for the software entity 212. The processing device 202 can apply, for the particular node 210, the code modification 114 in the second format 116b to the second configuration file 112 in response to detecting that the control node 102 is executing the first configuration file 108. The control node 102 can then deploy the software entity 212 to the particular node 210 using the code modification 114 applied to the second configuration file 112.
At block 302, the processing device 202 detects, at a first time, a code modification 114 made to a first configuration file 108 of a software entity 208 on a particular node 210 of a plurality of nodes 212. The first configuration file 108 can be infrastructure as code that can be executed by a control node 102 to deploy the software entity 208 to each node 210 of the plurality of nodes 212. In some examples, the plurality of nodes 212 can include different types of nodes. For example, the first configuration file 108 can include instructions for deploying a container to the plurality of nodes 212, which can include a virtual machine node and a server node. The virtual machine may require adjustments to the configuration of the container (e.g., the code modification 114 detected by the processing device 202).
At block 304, the processing device 202 converts the code modification 114 from a first format 116a associated with the control node 102 to a second format 116b associated with the software entity 208. The first format 116a in which the code modification 114 is made may be a format of the infrastructure as code used by the control node 102 to manage deployment of the software entity 208 (e.g., Ansible by Red Hat®, Terraform by Hashicorp, or any other suitable infrastructure as code tools). The second format 116b may be a format of a second configuration file 112 used to build the container on the plurality of nodes 212 (e.g., a Containerfile retrieved from a container registry). The processing device 202 can use a lookup table or other translation mechanism to identify first format 116a (e.g., Ansible) commands in the code modification 114 to second format 116b (e.g., Containerfile) commands. The processing device 202 can then convert the code modification 114 based on a mapping between control node commands and software entity commands.
In some examples, the processing device 202 can generate metadata 113 for the first configuration file 108 that includes a mapping between the node 210 with the code modification 114 (e.g., the virtual machine) and the code modification 114. For example, the metadata 113 can include the code modification 114 converted to the second format 116b with an indication that the converted code modification 114 is to be applied to the particular node 210.
At block 306, the processing device 202 detects, at a second time, the control node 102 executing the first configuration file 108 to deploy the software entity 208 to each node 210 of the plurality of nodes 1212 according to a second configuration file 112 for the software entity 208. The second time can be after the first time. For example, the processing device 202 may detect that the control node 102 is re-deploying the container to the virtual machine node and the server node. Or, the processing device 202 may detect that the control node 102 is deploying an update to the container to the virtual machine node and the server node. This subsequent deployment of the software entity 208 may not initially include the code modification 114.
At block 308, the processing device 202 applies, for the particular node 210, the code modification 114 in the second format 116b to the second configuration file 112. The control node 102 can deploy the software entity 208 to the particular node 210 using the code modification 114 applied to the second configuration file 112. For example, the code modification 114 can be applied in the second format 116b based on the metadata 113. The control node 102 can deploy the software entity 208 to the other nodes in the plurality of nodes 212 (e.g., a set of nodes that does not include the particular node 210) by using the second configuration file 112 without the applied code modification 114. That is, the code modification 114 may be applied only to the particular node 210 for subsequent redeployments of the software entity 208. This can avoid unnecessary application of the code modification 114 to other nodes (e.g., modified settings for a virtual machine that may not be applicable to a server).
In some examples, the processing device 202 may also generate an updated second configuration file 112 based on the first configuration file 108 and the code modification 114. For example, the processing device 202 can abstract a container configuration file from the first configuration file 108 that includes the code modification 114 to generate the updated second configuration file. This updated second configuration file can be stored in a software repository that can be used for subsequent deployments of the software entity 208 to include the code modification 114 for the particular node 210. Further, once the processing device 202 detects that the control node 102 has deployed the software entity 208 to the particular node 210 using the updated second configuration file, the processing device 202 can remove the metadata 113 associated with the code modification 114 from the first configuration file 108. Subsequent deployments of the updated second configuration file can be accessed directly from the software repository.
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.
