WO2016207520A1 - Technique de reconfiguration d'un modele d'application pour un deploiement d'une application logicielle - Google Patents

Technique de reconfiguration d'un modele d'application pour un deploiement d'une application logicielle Download PDF

Info

Publication number
WO2016207520A1
WO2016207520A1 PCT/FR2016/051466 FR2016051466W WO2016207520A1 WO 2016207520 A1 WO2016207520 A1 WO 2016207520A1 FR 2016051466 W FR2016051466 W FR 2016051466W WO 2016207520 A1 WO2016207520 A1 WO 2016207520A1
Authority
WO
WIPO (PCT)
Prior art keywords
component
model
application
deployment
configurator
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2016/051466
Other languages
English (en)
Inventor
Xavier ETCHEVERS
Thierry Coupaye
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of WO2016207520A1 publication Critical patent/WO2016207520A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances

Definitions

  • the invention relates to the general field of software applications.
  • It relates more particularly to a technique for reconfiguring a software application deployed in an execution environment.
  • the invention applies to software applications deployed in a computer system in the cloud also more commonly called “cloud” in English.
  • the Infrastructure as a Service (IaaS) level is intended to provide access to virtual hardware (computing, storage, network) resources based on a set of physical hardware resources.
  • the Software as a Service (SaaS) layer aims to expose software applications to end users.
  • the Platform as a Service (PaaS) middle layer provides a set of tools and runtime environments to manage the application lifecycle. This lifecycle includes the phases of design, development, deployment and more generally application administration (load management, fault tolerance, security, etc.).
  • each virtual machine is generally the subject of a dynamic configuration phase finalizing the configuration of the distributed application.
  • a virtualized resource is a software artifact whose purpose is the dematerialization of a physical (or real) resource. For this, it reproduces the behaviors and characteristics to the identical.
  • a virtual machine is characterized by the number of processors, the amount of memory, the storage units and the network interfaces that it has. In addition, it works identically to any real machine. Virtualization of physical resources is not limited to servers and also concerns storage entities and network devices.
  • One of the main interests of virtualization is to allow the consolidation of material resources by pooling. This consists in simultaneously implementing a set of virtualized hardware resources at the level of a common physical hardware infrastructure (ie several virtual machines running on the same physical machine).
  • the architecture of an application corresponds to the modeling, on the one hand, of all the software elements (eg executable and data) and hardware (eg machines) necessary for the functioning of the application and, on the other hand, on the other hand, to all the constraints (or dependencies) that link these elements to each other.
  • the nature of these dependencies is variable. They can especially concern dependencies:
  • the next step is to use a component-based application model to describe the software components that make up an application and project them onto an execution infrastructure, as well as the dependencies that bind them to the application.
  • application architecture A software application is thus modeled by an application model comprising at least one component administering a software element and deployment constraints.
  • reconfiguring an application consists of changing its architecture.
  • the reconfiguration includes basic operations of adding, deleting and / or modifying the software elements and dependencies between elements that make up the application architecture.
  • One of the aims of the invention is to remedy the shortcomings / disadvantages of the state of the art and / or to make improvements thereto.
  • the subject of the invention is a method of reconfiguring an application model for a deployment of a software application.
  • An application model includes at least one application component and deployment constraints and a current application model, called runtime model, is deployed on a virtual machine infrastructure based on at least one physical machine.
  • the method comprises:
  • target application model a new application model, called target application model
  • a deployment command of an intermediate model comprising said at least one component of the model at runtime and wherein a component present in the runtime model and absent from the target application model is deleted, and a component present in the runtime model and stopped in the target application model is indicated to stop;
  • the target application model becomes the run-time model when deployed on the infrastructure.
  • the intermediate template sent is determined by the deployment manager.
  • a synchronization is introduced at the end of the first phase, once the intermediate model has been deployed.
  • the reconfiguration solution is based on the model of the current application, the target model of the application to implement and a two-phase asynchronous protocol, decentralized and reliable, able to evolve the current instance from the application to the target architecture while respecting the associated dependencies (ie configuration, placement and activation).
  • the first phase of this protocol focuses on the removal and shutdown of application components.
  • the second phase is aimed at adding, configuring and activating application components.
  • the triggering of the second phase is conditioned by the complete finalization of the first thanks to a synchronization point provided at the end of the first phase.
  • the reconfiguration technique also makes it possible to complete, in a finite time and in the presence of a finite number of free faults of the application execution infrastructure (for example the virtual machines) a reconfiguration operation. The architectural coherence is also maintained due to the respect of dependencies including activation between the various elements.
  • the reconfiguration technique makes it possible to adapt to the requirements of the user the quantity and the configuration of the hardware and software resources necessary for the implementation of the application.
  • the reconfiguration method comprises prior to sending the target application model, when a component requires the implementation of an unpublished software element in a software image, a generation of less a new software image needed to implement the new component, publish and instantiate as a virtual machine infrastructure.
  • an ordered stamp is associated with an application template sent to a configurator.
  • the ordered stamping of the sent application model makes it possible to carry out local synchronizations between two configurators. This is particularly advantageous in terms of performance and execution speed with respect to modes of operation where the deployment manager centralizes and synchronizes the execution of the reconfiguration operations.
  • This stamping mechanism makes it possible to maintain the execution in parallel, asynchronously, of the configurators.
  • the reconfiguration method comprises:
  • a deployment command of an intermediate model comprising the at least one component of the model at runtime and in which a component present in the run-time model and missing from the target application model is removed and a component present in the run-time model and stopped in the target application model is shown to stop;
  • an action said action belonging to a group comprising a removal of a component when said component is absent from the intermediate model, a stop of a component when said component is indicated to stop, a shutdown of the component when said component includes a server interface linked by a mandatory link to a client interface of another component missing from the intermediate model;
  • an action belonging to a group comprising a creation of a new component, a modification of a component, an activation of a stopped component when said component comprises a server interface connected by a mandatory link to a client interface of a new component;
  • a message sent to a configurator responsible for a linked component includes a received stamp with an application template.
  • Configurators can be synchronized in pairs without the need for centralized synchronization.
  • an action for deleting or stopping an application component is performed when said component has no server interface connected by a binding link to a client interface of another application component.
  • An application component can not stop or be deleted as long as it has a server interface connected by a binding link to a client interface of another application component. This ensures that this other application component will not continue to run without receiving the data necessary for its execution.
  • the architectural coherence of the application is thus maintained thanks to the respect of dependencies.
  • the configurator responsible for said component when executing the action of deleting or stopping an application component, sends a notification stop message for a client interface connected by a link to an application component. a server interface of another component.
  • An application component when it stops or when it is deleted signals this stop for a client interface connected to a server interface of another component. This allows this other component to stop without creating a malfunction in the execution of the application.
  • the architectural coherence of the application is thus maintained thanks to the respect of dependencies.
  • the invention furthermore relates to a device implementing a deployment manager executing on a virtual machine hosted by the device, said deployment manager comprising for reconfiguring an application model for a deployment of a software application, an application model comprising at least one application component and deployment constraints, a current application model, called a runtime model, being deployed on a virtual machine infrastructure based on at least one physical machine:
  • control module arranged to control the sending module to send the determined intermediate model and when the intermediate model is deployed on the infrastructure, to activate the generation / instantiation module and to control the sending module to send the target application model.
  • the generation module is activated to generate a new software image when a component requires the implementation of an unpublished software element in a software image.
  • the invention also relates to a device implementing a configurator executing on a virtual machine hosted by the device, said configurator comprising for reconfiguring an application model for a deployment of a software application, a model application model comprising at least one application component and deployment constraints, a current application model, called a runtime model, being deployed on a virtual machine infrastructure based on at least one physical machine:
  • a module for executing an action said action belonging to a group comprising a deletion of a component when said component is absent from the model to be applied, a shutdown of a component when said component is indicated to stop, a stop of a component when said component comprises a server interface connected by a mandatory link to a client interface of another component not present in the model to be applied, a creation of a new component, a modifying a component, activating a stopped component when said component comprises a server interface connected by a mandatory link to a client interface of a new component;
  • a module for sending the deployment manager a notification of a change of state of the component a module for sending the deployment manager a notification of a change of state of the component.
  • the invention further relates to a program for a device, comprising program code instructions for controlling the execution of the steps of the method of reconfiguration according to the first aspect implemented by the device, when this program is executed by this device and a recording medium readable by a device on which a program for a device is recorded.
  • the invention further relates to a program for a device, comprising program code instructions for controlling the execution of the steps of the reconfiguration method according to the second aspect implemented by the device, when this program is executed by this device and a recording medium readable by a device on which a program for a device is recorded.
  • FIG. 1 represents an environment in which the reconfiguration method is implemented in a particular embodiment
  • FIG. 2a schematically represents a first example of a software application deployed according to a particular embodiment
  • Figure 2b schematically shows a second example of a software application deployed according to a particular embodiment
  • FIG. 3 illustrates steps of a reconfiguration method implemented by a deployment manager according to a particular embodiment
  • FIGS. 4a and 4b illustrate steps of a reconfiguration method implemented by a configurator according to a particular embodiment
  • FIG. 5 schematically shows a device implementing a deployment manager in a particular embodiment
  • FIG. 6 schematically represents a device implementing a configurator in a particular embodiment.
  • FIG. 1 represents, in its environment, a system 200 for managing a configuration of machines for the deployment of a software application APP in a particular embodiment.
  • the system 200 makes it possible to manage virtual resources necessary for the execution of an APP software application. The configuration and sizing of these virtual resources have been previously determined. Once this configuration is deployed, the software application can be run in a real execution environment.
  • APP software application can be an application allowing access to or the generation of multimedia content, the referencing of products, access to remote equipment, etc.
  • the APP software application is intended to be deployed (ie production) in a cloud or cloud computing system (not shown), on a configuration of virtual machines (or servers) hosted by the cloud.
  • the shared resources can be of different natures: they can be in particular resources of the processor or CPU type of virtual and / or physical machines (or servers), memory resources (eg RAM, disk, etc.), or even network resources (eg network connectors, etc.).
  • An APP software application includes a set of software elements 240 that provide services and interact with each other to produce the application features in an application plan. These software elements are distributed within an execution infrastructure composed of a set of virtual machines 22 (denoted VM for "Virtual Machine”). Beyond the software elements that compose it, a software application is also defined using the deployment constraints (or dependencies) that link these software elements together. There are three types of dependencies:
  • an element A has a configuration dependency on element B, if element A must have information on element B in order to be able to configure and interact with it (eg the IP address of the element B, identifiers of connection to a database, etc.)
  • activation dependencies an A element has an activation dependence on a B element, if the start of element A is conditioned by that of element B. In such a case, in In the rest of the document, such a dependence also induces the reciprocal, namely that such a dependence implies that the stopping of element B is conditioned by that of element A.
  • VAMP Virtual Application Management Platform
  • the VAMP platform is a software framework (or "framework" software) that allows the deployment of arbitrary applications in a cloud or cloud computing system on a configuration of virtual machines (or servers) hosted by the cloud.
  • VAMP provides standalone, generic, and reliable deployment of any distributed application in a cloud computing environment.
  • Such a VAMP platform is described in X.
  • a VAMP platform includes:
  • a VAMP platform is based on a composite application model:
  • a virtual machine is seen as the aggregation of a set of processors, a quantity of disks, network interfaces, and disks. Each disk is characterized by a size and an image can be associated with it. The content of an image is represented by means of an operating system, a set of middleware and user data that can be both binaries and application data.
  • a virtualization or hypervisor module refers to a runtime environment that can create, activate, migrate, stop, and destroy virtual machines. The hypervisor manages the allocation of hardware resources between different instances of virtual machines and provides virtual machines with these virtualized resources.
  • a VAMP Manager 100 is the single point of access to the Deployment Service. As shown in Figure 1, it is installed on a virtual machine 10. No limitation is attached to this representation, the VAMP manager can also be installed on a physical machine. VAMP 100 is primarily responsible for processing software application deployment requests from users. For each new request, it dynamically instantiates a new deployment manager 210 in a new virtual machine 21 and sends it the associated deployment request. In addition to this role, the VAMP Manager 100 also allows a user to obtain a status of the deployment of his application.
  • VAMP defines a layered architecture that groups together a set of control entities in an administrative plan:
  • a communication model ensuring the exchanges between these control entities, by means of messages exchanged via a decentralized bus (ie communication in point-to-point mode), asynchronous (ie no active waiting in the sending of a message) and reliable (ie delivery guarantee of each message sent).
  • a decentralized bus ie communication in point-to-point mode
  • asynchronous ie no active waiting in the sending of a message
  • reliable ie delivery guarantee of each message sent.
  • a configurator has the particular function of:
  • each of the configurators present on each of the application virtual machines acts independently of the others;
  • the deployment manager 210 running in a virtual machine 21 is dedicated to the deployment of the APP application; the configurator 220 running in a virtual machine 22 supports the deployment of the component 230 of the APP application.
  • the component 230 comprises a software element 240 located on the virtual machine 22 and executing in the application plane.
  • a configurator and the component for which it is responsible are co-located on the same virtual machine.
  • the configurator 220 can also support the deployment of other components of the APP application. Their number varies for each APP application. Other configurators responsible for APP application components can also be deployed to other virtual machines.
  • the deployment manager 210 and the configurator 220 may also be co-located on the same virtual machine. As depicted virtual machines 21 and 22 are co-located on a physical machine 20. There is no limitation attached to this representation, virtual machines being deployable on separate physical machines.
  • the deployment manager 210 and the configurator (s) 220 responsible for application components form a system for managing a configuration 200 of a virtualized application.
  • a component is an administration entity of the underlying software element. Each component exposes:
  • an interface is a point of interconnection between components.
  • An interface can be a client or a server, respectively corresponding to the notion of required service and service provided.
  • a placement property of the software element within the application execution infrastructure e.g., virtual machines.
  • a link is used to interconnect the client interface of a component A to the server interface of a component B, thus indicating that A depends on B from a point of view of its configuration and / or its activation.
  • a binding is said to be mandatory when the client interface of component A considered must be linked to a server interface of component B, through this link, so that component A can be activated. Otherwise, that is when component A can be activated regardless of whether or not there is a link between the client interface of component A and a server interface of component B, the connection is optional .
  • Fractal components are implemented using "wrappers", or components.
  • a "wrapper” is a Java object (POJO for Plain Old Java Object) that implements the behavior of the component through an interface that includes basic administrative operations:
  • start I stop I restart start / stop / restart operations of the underlying software element.
  • a "wrapper" thus corresponds to a real instance of a component. Subsequently, the term component is used.
  • the deployment manager 210 Upon receipt of a deployment request, the deployment manager 210 performs the following processing based on the information contained in the request:
  • PI Generate, if necessary, software images (ie, software stacks) needed to implement the application.
  • Each virtual image consists of an operating system, a set of middleware (or “middleware") as well as binaries and application data.
  • Each image corresponds to the main disk of one (or more) of the virtual machines that make up the execution infrastructure of the application to be deployed.
  • the Deployment Manager inserts into each software stack the binaries of a configurator as well as a set of components.
  • IaaS Infrastructure as a Service
  • P3 Simultaneous instantiation (i.e. in parallel) of all the application virtual machines within the target IaaS platform (s). Therefore, each of these virtual machines is initialized (or "boot”) independently of others, asynchronously.
  • a configurator 220 is inserted into a virtual image by the deployment manager 210 during the processing Pl.
  • the configurator 220 is then activated automatically after the startup of the virtual machine 21.
  • the configurator 220 then performs, independently of the other configurators, the following processes: Al-Bus Record: The configurator 220 contacts the deployment manager 210 to indicate that it wishes to register in the message bus as a new agent. At the end of this registration phase, the deployment manager 210 transmits to the configurator the model of the application to be deployed.
  • Component instantiation from the model of the application to be deployed received, the configurator 220 locally creates and configures the components 230 for which it is responsible and which correspond to the software elements 240 located on the virtual machine 21 where it is located. find. A3- resolution of the remote configuration constraints: for each component for which it is responsible, the configurator 220 determines from the model of the application, whether it is necessary to transmit configuration information to components located on d. other application virtual machines. In other words, the configurator 220 lists the local components that expose a server interface and for each of them, it issues a RemoteBindingNotification message containing the associated configuration information to the configurator (s) responsible for the (or ) components that have a client interface connected to the server interface.
  • the configurator 220 activates the components that can be: these are the components of which all the client interfaces that participate in a binding link are connected. to the server interface of a component already started. When a component is started, the configurator 220 sends a StartNotification message to all the configurators of which at least one component depends on the newly activated component.
  • each configurator 220 can receive messages from other configurators.
  • a configurator receives a RemoteBindingNotification message, it passes it on to the recipient component of the message and the message recipient proceeds with the configuration operations relating to the information contained in the message.
  • a configurator receives a StartNotification message, it determines whether the component (s) impacted by that start can be started in their turn.
  • the configurator 220 For each component for which it is responsible, the configurator 220 sends the deployment manager 210 a status change notification once the component has started.
  • the deployment manager 210 determines whether the deployment of the application as a whole is complete.
  • the initial deployment process is also reliable vis-à-vis the frank failures of the execution infrastructure (ie virtual machines, network, ). Indeed, when creating a virtual machine, the deployment manager arms a timer corresponding to a maximum boot time of a virtual machine. If this timer expires, the Deployment Manager again requests the creation of a new virtual machine while taking care to request the eventual destruction of the previous instance (case of false positives). This operation is based on the fact that the cloud infrastructure is itself reliable. Moreover, as soon as it is instantiated, each configurator initiates a "heart beat" type mechanism by sending at regular intervals a proof of life signal to the deployment manager.
  • this signal proceeds to replace the failed virtual machine with a replacement instance.
  • This replacement is accompanied by the elimination of possible "false positive" cases.
  • All configurators participating in the deployment of the application are informed during a failure of a virtual machine and therefore a configurator. Therefore, the neighboring configurators, in terms of configuration and activation dependencies, reissue the messages they had already sent to the previous instance.
  • a component upon receipt of a RemoteBindingNotification message (respectively a StartNotification message) from the replacement instance, a component performs a reconfiguration operation (respectively restart).
  • FIGS 2a and 2b schematically show two applications deployed on an IaaS infrastructure.
  • FIG. 2a corresponds to an application comprising three components CO, Cl, C2 respectively deployed on virtual machines VMO, VM1, VM2.
  • the component C2 comprises a single interface, which is a server interface intended to be connected to a client interface of the component C1 by a mandatory link. This link is denoted L12.
  • the component C1 comprises two interfaces: a server interface intended to be connected to a client interface of the component C0 by a mandatory connection (denoted LOI) and the client interface intended to be connected to the server interface of the component C2 (link L12) .
  • the component C0 comprises a single interface, which is the client interface intended to be connected to the server interface of the component C1.
  • the configurator responsible for the component C2 issues a RemoteBindingNotification message containing the information of associated configuration to the configurator responsible for the component C1 whose client interface is connected to the server interface it proposes. Since component C2 does not have a client interface participating in a binding, the configurator responsible for component C2 starts component C2 and sends a StartNotification message to the configurator responsible for component Cl.
  • the configurator responsible for the component Cl issues a RemoteBindingNotification message containing the associated configuration information to the configurator responsible for the component C0 whose client interface is connected to the server interface it proposes. Since the component C1 has a client interface participating in a binding, the configurator responsible for the component Cl checks whether the component C2 has started. Yes this is the case, the configurator responsible for the component Cl starts the component Cl and sends a StartNotification message to the configurator responsible for the component C0.
  • the configurator responsible for the component C0 checks whether the component Cl has started. If this is the case, the configurator responsible for the component C0 starts the component C0 and sends a StartNotification message to the configurator responsible for the component Cl.
  • component C2 the components start in the following order: component C2, component C1, component C0.
  • component C0 the components start in the following order: component C2, component C1, component C0.
  • FIG. 2b corresponds to a more complex application, comprising three components C0, C1, C2 respectively located on three virtual machines VMO, VM1, VM2.
  • Each of the components C0, C1, C2 has two client interfaces and two server interfaces.
  • the first client interface of the component C0 is connected to a first server interface of the component C1 by an LOI connection.
  • the second client interface of the component C0 is connected to a first server interface of the component C2 by a link L02.
  • the first server interface of the component C0 is connected to a first client interface of the component C1 via a binding L10 which is mandatory.
  • the second server interface of the component C0 is connected to a first client interface of the component C2 via a binding L20 that is mandatory.
  • the second client interface of the component C1 is connected to a second server interface of the component C2 via an L12 link.
  • the second server interface of the component C1 is connected to a second client interface of the component C2 via a binding L21 which is mandatory.
  • L21 which is mandatory.
  • to start the component C2 it is necessary that the components C0 and Cl are started, and to start the component Cl, it is necessary that the component C0 is started. It can be seen in this example that the components start in the following order: component C0, component C1, component C2.
  • the deployment manager 210 stores a MOD_Ex execution model (or model @ runtime), representing the current deployment state of the application.
  • This run-time model includes the model of the deployed application, or current application model, and information related to the instance of the application such as:
  • a deployment state of the application components that reflects the progress of the configuration and activation operations of the underlying software elements
  • IP addresses network addresses
  • This model at runtime MOD_Ex is built from the model of the application contained in the deployment request issued by the user of the VAMP system as well as by the information sent during the deployment by each configurator.
  • the deployment manager 210 thus has a current global view of the progress of the deployment of the application.
  • this runtime model is updated:
  • FIG. 3 represents steps of the reconfiguration method implemented by a deployment manager 210.
  • the deployment manager 210 receives a request to modify the model at runtime to a target model MOD_T.
  • This target model corresponds to a new model to be applied and describes a new architecture of the APP application.
  • This deployment request is received directly from a VAMP system user or through the VAMP manager.
  • elements can be deleted, elements can be stopped (for example due to a maintenance operation), elements can be created or modified.
  • the deployment manager 210 determines an intermediate model MOD_Int. More precisely, the deployment manager 210 determines by comparison between the model at the execution MOD_Ex and the target model MOD_T the elements to be deleted or the elements to be stopped.
  • the term element refers to VM virtual machines, software stacks, components, and bindings.
  • the deployment manager 210 stores the elements of the model at runtime that are not to be deleted or stopped in the intermediate model MOD_Int. Thus, this intermediate model contains neither the elements to be added nor the configuration modifications to be made on existing elements as defined in the target model.
  • the deployment manager 210 transmits to configurators 220 the intermediate model MOD_Int for deployment.
  • the deployment manager 210 waits for confirmation from each of the configurators that the intermediate model MOD_Int has been applied. More specifically, the confirmation corresponds to a receipt of a notification of change of state sent by the configurator 220 for each component concerned. Once all status change notifications have been received, the items that were to be deleted are no longer present on the virtual machines, the elements that were to stop were and elements impacted by deleting or stopping another element were stopped.
  • the first phase ⁇ is then terminated, the elements absent from the target application model having been deleted from the runtime model and the elements stopped in the target application model having been stopped in the runtime model.
  • the intermediate model becomes the new model at runtime.
  • the deployment manager 210 then proceeds by comparison between the model at the execution MOD_Ex and the target model MOD_T, at the generation, when a component requires the implementation of a software element not published in a software image, new software images (ie software stacks) necessary for the implementation of the application (PI processing previously described), the publication of these new virtual images (P2 treatment previously described), and the reconfiguration of properties relating to existing virtual machines (modification of a virtual machine) and the instantiation of all new application virtual machines (P3 processing described above).
  • new software images ie software stacks
  • the deployment manager 210 then transmits the target model to the configurators 220, so that the latter perform the addition, activation and modification operations on the application components.
  • the deployment manager 210 waits for confirmation from each of the configurators that the target model MOD_T has been applied. More specifically, the confirmation corresponds to a receipt of a notification of change of state sent by the configurator 220 for each component concerned. Once all the notifications of change of state received, the elements to be added were created on the virtual machines, the elements to be activated were it and the elements to be modified were updated. This ends the second phase ⁇ 2.
  • FIG. 4a illustrates steps of a method for reconfiguring a model at the MOD_Ex execution to a model to be applied implemented by a configurator 220 of the APP application.
  • a step F1 the configurator 220 receives a template to be applied.
  • the configurator 220 determines, according to the model at the execution MOD_Ex, one or more actions to be performed to obtain the model to be applied received. These actions correspond, if necessary, to a component deletion, a component shutdown, a component activation, a component modification or a component addition.
  • a component must be stopped when it depends as a client of a component to be deleted or stopped through a binding.
  • a client interface to a component that is bound by a binding to a server interface of another component must be deconfigured when that other component is to be removed, and this must be done prior to the deletion of that other component. Deleting a component includes uninstalling the corresponding software, freeing resources, and cleaning up the data.
  • a step F3 the configurator 220 executes, as the case may be, the action or the actions determined in the step F2. During the execution of this step F3, the configurator 220 sends the deployment manager 210 a status change notification for each component concerned.
  • steps Fl to F3 are implemented during a reconfiguration of a model at runtime to a target model, a first time with the intermediate model MOD_Int determined by the deployment manager in step E2 and a second time. with the MOD_T target model transmitted by the deployment manager in step E6.
  • FIG. 4b more precisely represents the step F3 implemented by the configurator
  • the configurator 220 checks whether it has one or more actions to perform.
  • step F3 is completed.
  • the configurator 220 determines whether action belongs to a group comprising a deletion or a stop of a component 230. If this is the case, in a step F32, the configurator 220 checks whether there is a server interface of the component 230 connected by a mandatory link to a client interface of another component. If this is the case, the component 230 can not be stopped immediately, in a step F320, the configurator 220 is placed then waiting to receive a stop notification notification StopNotification from the configurator responsible for this other component . Such a message is received in a step F321.
  • the configurator 220 updates its local representation of the model at runtime based on this received message.
  • the configurator 220 again implements the verification step F32 if there is a server interface of the component 230 connected by a mandatory link to a client interface of another component.
  • step F32 If it is verified in step F32 that there is no server interface of the component 230 connected by a mandatory connection to a client interface of another component, the component 230 is stopped because it does not play a server role vis-à-vis one of the other components of the application.
  • the configurator 220 sends a stop notification message StopNotification for a client interface connected by a link to a server interface of another component if it exists. More precisely, this notification stop message is sent to the configurators responsible for these other components.
  • the configurator 220 executes the action to be performed.
  • the action is a shutdown of the component
  • the configurator 220 stops the execution of the component 230 and changes a state of the component to "stopped”.
  • the configurator 220 stops the execution of the component 230, releases the resources used by this component and modifies a state of the component to "deleted”.
  • the configurator 220 stores in its local representation of the model at runtime the new state, "stopped” or “deleted", of the component 230.
  • the configurator 220 sends the deployment manager 210 a status change notification, including the new state of the component 230.
  • the configurator 220 executes again the step F30, in order to check whether it still has one or more actions to perform.
  • step F31 If it is verified in step F31 that the action does not correspond to a deletion or a shutdown of a component 230, this action then belongs to a group comprising a creation, an activation or a modification of the component 230.
  • the configurator 220 executes the processing A2 described above. More specifically, if it is a creation of a component, the configurator 220 creates the corresponding component. In both cases, creation and modification, the configurator 220 locally configures the corresponding component.
  • the configurator 220 executes the processing A3 described above. Specifically, the configurator 220 lists the local components that expose a server interface and for each of them, it issues a RemoteBindingNotification message containing the associated configuration information to the configurator (s) responsible for the component (s) ( s) whose client interface is connected to the server interface in question. If this is only a change to a component's configuration property, there is no RemoteBindingNotification message broadcast.
  • the configurator 220 executes the A4 processing described above. More precisely, the configurator 220 activates the component whose set of client interfaces that participate in a binding link are connected to the server interface of a component already started. When a component is started, the configurator 220 sends a StartNotification message to all the configurators of which at least one component depends on the newly activated or modified component.
  • a step F314 the configurator 220 changes the state of the component to "started”.
  • the configurator 220 stores in its local representation of the model at runtime the new state, "started", of the component 230.
  • the configurator 220 then executes the step F325, previously described, of sending to the deployment manager 210 a notification of the new state of the component 230.
  • step F3 when an intermediate model is received, the steps F32x are notably implemented for stopping or deleting a component and when receiving the target model.
  • the steps F31x are notably implemented for the creation, activation or modification of a component.
  • the component C1 is no longer present in the target model.
  • the component C0 must be stopped because one of its client interfaces is connected by a mandatory connection LOI to a server interface of the component Cl.
  • the Cl component must be removed.
  • the component C2 is not modified because it does not have a client interface linked by a binding link to a server interface of the component Cl.
  • the C0 component configurator determines that this component should be stopped. He verifies
  • step F32 that it has no server interface connected by a mandatory link to a client interface of another component. It sends (step F322) a Stop Notification notification message to the configurator responsible for the component Cl. Then it stops the component C0 (step F323).
  • the Cl component configurator determines that this component should be removed. It verifies (step F32) that it has a server interface connected by a mandatory link to a client interface of the component C0. As long as the component C0 is active, it is placed on hold (step F320). Once the StopNotification notification stop message has been received (step F321) from the component C0, since it no longer has a server interface linked by a binding link to a client interface of another component (step F32), it sends (step F322) a Stop Notification notification message to the configurator responsible for the component C2. Then it stops and removes the component Cl (step F323).
  • the C2 component configurator determines that it has no action to perform. On receipt of the stop notification message StopNotification from the component Cl, it updates its local representation of the model at runtime. It is thus found that it is not possible to delete the component C1 until the component C0 is stopped.
  • step E2 determines (step E2) an intermediate model, in which the component C1 is no longer present.
  • the component C0 is not modified because none of its client interfaces is connected by a binding link to a server interface of the Cl component (the LOI link is optional).
  • the Cl component must be removed.
  • the component C2 is to stop because it has a client interface connected by a binding L21 to a server interface of the component Cl.
  • the configurator of the C0 component determines that there is no action to perform.
  • the Cl component configurator determines that this component should be removed. It verifies (step F32) that it has a server interface connected by a binding link L21 to a client interface of the component C2 (LOI is an optional link). As long as the component C2 is active, it goes on standby (step F320). Once the StopNotification notification stop message has been received (step F321) from the component C2, since it no longer has a server interface linked by a binding link to a client interface of another component (step F32), it sends (step F322) a StopNotification notification stop message to the configurators responsible for the components C0 and C2. Then it stops and removes the component Cl (step F323).
  • the C2 component configurator determines that this component should be stopped. It verifies (step F32) that it does not have a server interface connected by a mandatory link to a client interface of another component (L02 and L12 are optional links). It sends (step F322) a Stop Notification notification message to the configurators responsible for the components C0 and C1. Then it stops (step F323) the component C2.
  • the configurators responsible for components C0 and C1 Upon receipt of the Stop Notification notification message from component C2, the configurators responsible for components C0 and C1 update their local representation of the model at runtime. On receipt of the stop notification message StopNotification from the component Cl, the configurators responsible for the components C0 and C2 update their local representation of the model at runtime. It can be seen that it is not possible to delete the component C1 until the component C2 is stopped.
  • the deployment manager 210 receives (step E4) the status change notifications from the configurators responsible for the components C1 ("deleted” state) and C2 ("stopped” state). The first phase ⁇ is thus completed.
  • the deployment manager 210 proceeds (step E5), by comparison between the run-time model and the target model, the generation of the new software image of the component C4, the publication of this new virtual image and the update. existing virtual machine properties and instantiating the new virtual machine.
  • the deployment manager 210 transmits (step E6) the target model to the configurators 220, so that the latter perform the necessary operations on the application components.
  • the configurator 220 is for example in charge of the creation of the component C4.
  • the configurator 220 creates and configures (step F311) locally the corresponding component C4.
  • the configurator 220 transmits (step F312) a RemoteBindingNotification message containing the configuration information associated to the (s) configurator s) responsible for the component (s) whose client interface is connected to the server interface considered.
  • the configurator 220 activates the component whose set of client interfaces that participate in a binding link are connected to the server interface of a component already started.
  • the C0 component is already started.
  • the C2 component must be restarted.
  • the configurator of component C2 sends a StartNotification message to components C0 and C4.
  • the state of component C2 becomes "started".
  • the configurator 220 sends a StartNotification message to the components C0 and C2.
  • the state of component C4 becomes "started".
  • the deployment manager 210 receives (step E4) the status change notifications from the configurators responsible for the components C4 ("started” state) and C2 ("started” state). This second phase ⁇ 2 is thus completed.
  • the target model has been deployed and the application is operational again.
  • the two-phase reconfiguration process is asynchronous, distributed and reliable. It is based on the following elements:
  • defining and storing a current representation of the deployed application i.e. the runtime model. It allows the deployment manager to make comparisons between the target application model to be deployed and a current application state and calculate the actions to be performed in terms of reconfiguration.
  • a stamp is representative of a version of the application model to be deployed.
  • This stamp is associated with the template sent to the configurators.
  • the messages sent by the configurators include this stamp, in order to refer to the version of the application template.
  • the stamps are ordered, absolutely, in time. It is therefore possible, from these stamps, to classify the versions of the application model.
  • This stamp can be for example temporal.
  • the runtime model within the deployment manager as well as at each configurator has the timestamp value associated with it.
  • a configurator When sending a message of type RemoteBindingNotification, StartNotification, or StopNotification, a configurator enriches the message with the stamp value that it knows about. Symmetrically, when a configurator receives a message of type RemoteBindingNotification, StartNotification or StopNotification, it proceeds as follows: if the stamp contained in the received message is earlier than the current stamp of the configurator (ie ie the one associated with the last template it has received), it does not perform any operation and destroys the message, the latter being considered out of date.
  • the message is put on hold, until the stamp of the configurator is equal (following receipt of a model update ) the stamp of the received message.
  • the message is then processed.
  • the message is processed immediately.
  • This stamp mechanism makes it possible to take into account the asynchronism in the execution of the different configurators. It can be seen as a two-to-two synchronization mechanism between configurators.
  • the stamp of a configurator is updated when it receives from the deployment manager a new version of the application model to be deployed.
  • the deployment manager stamp is incremented with each new deployment operation.
  • FIG. 5 represents a device implementing a deployment manager in a particular embodiment.
  • the deployment manager includes:
  • a processor 211 for executing software module code instructions
  • a memory zone 212 arranged to store an application that includes code instructions for implementing the steps of the reconfiguration method
  • a storage memory not shown, arranged to store data used during the implementation of the reconfiguration method
  • a module 215 for sending to a configurator responsible for an application component, a deployment command for a model to be applied;
  • a module 216 for generating at least one new software image necessary for the implementation of a new component, and instantiation in the form of a virtual machine of the infrastructure; a control module 217, arranged to control the sending module to send the determined intermediate model and when the intermediate model is deployed on the infrastructure, to activate the generation / instantiation module and to control the sending module for send the target application template.
  • the generation module 216 is activated when a component requires the implementation of an unpublished software element in a software image.
  • FIG. 6 represents a device implementing a configurator in a particular embodiment.
  • the configurator includes:
  • a memory zone 222 arranged to store an application that includes code instructions for implementing the steps of the reconfiguration method
  • a storage memory not shown, arranged to store data used during the implementation of the reconfiguration method
  • an execution module 224 of an action said action belonging to a group comprising a deletion of a component when said component is absent from the model to be applied, a judgment of a component when said component is indicated to stop in the model to be applied, a shutdown of a component when said component comprises a server interface connected by a mandatory link to a client interface of another component not present in the model to be applied, a creation of a new component, a modification of a component, an activation of a stopped component when said component comprises a server interface connected by a mandatory link to a client interface of a new component;
  • a sending module 225 to the deployment manager of a status change notification of the component.
  • processors and memories are material resources that belong to a physical machine. These resources are intended to be virtualized by the hypervisor and made available to the virtual machines.
  • the invention also relates to a computer program on one or more recording medium (s), this program being capable of being implemented in a configuration management system or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a reconfiguration process as described above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the deployment manager 210 is arranged to implement the previously described reconfiguration method. It is preferably a software module comprising software instructions for executing those of the steps of the reconfiguration method described above, implemented by a computer.
  • the invention therefore also relates to:
  • a program for a deployment manager comprising program code instructions intended to control the execution of the steps of the reconfiguration method described above, when said program is executed by this computer;
  • a computer-readable recording medium on which the program is recorded for a deployment manager.
  • the configurator 220 is arranged to implement the previously described reconfiguration method. It is preferably a software module comprising software instructions for executing those of the steps of the reconfiguration method described above, implemented by a computer.
  • the invention therefore also relates to:
  • a program for a configurator comprising program code instructions intended to control the execution of the steps of the reconfiguration method described above, when said program is executed by this computer;
  • a recording medium readable by a computer on which the program for a configurator is recorded.
  • the software modules can be stored in or transmitted by a recording medium.
  • the recording medium may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program can be downloaded in particular on an Internet type network.
  • the recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the reconfiguration technique has been described for implementation in a VAMP compliant platform. This technique can also be transposed to other virtual environments, in which a software application is represented as an application model modeling model entity dependencies, including application components and deployment constraints, and the deployment is decentralized.

Landscapes

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

Abstract

L'invention concerne une technique de reconfiguration d'un modèle d'application pour un déploiement d'une application logicielle. Un modèle d'application comprend au moins un composant applicatif et des contraintes de déploiement. Un modèle d'application courant, dit modèle à l'exécution, est déployé sur une infrastructure de machines virtuelles. Le gestionnaire envoie à un configurateur responsable d'un composant applicatif une commande de déploiement d'un modèle intermédiaire, comprenant ledit au moins un composant du modèle à l'exécution et dans lequel, un composant présent dans le modèle à l'exécution et absent d'un modèle d'application cible est supprimé, et un composant présent dans le modèle à l'exécution et arrêté dans le modèle d'application cible est indiqué à arrêter. Lorsque le modèle intermédiaire est déployé sur l'infrastructure, le gestionnaire envoie alors à un configurateur responsable d'un composant applicatif une commande de déploiement du modèle d'application cible. Le modèle d'application cible devient le modèle à l'exécution une fois déployé sur l'infrastructure.

Description

Technique de reconfiguration d'un modèle d'application pour un déploiement d'une application logicielle
L'invention se rapporte au domaine général des applications logicielles.
Elle concerne plus particulièrement une technique de reconfiguration d'une application logicielle déployée dans un environnement d'exécution.
L'invention s'applique à des applications logicielles déployées dans un système informatique dans le nuage aussi plus communément appelé « cloud » en anglais.
Les environnements de type informatique dans le nuage se déclinent en trois grands niveaux d'offre selon le type de ressource mis à disposition. Le niveau « Infrastructure as a Service » (IaaS) a pour but de permettre d'accéder à des ressources matérielles (calcul, stockage, réseau) virtualisées s 'appuyant sur un ensemble de ressources matérielles physiques. La couche « Software as a Service » (SaaS) vise à exposer des applications logicielles à destination des utilisateurs finaux. La couche intermédiaire « Platform as a Service » (PaaS) offre un ensemble d'outils et d'environnements d'exécution qui permettent de gérer le cycle de vie des applications. Ce cycle de vie comprend notamment les phases de conception, développement, déploiement et plus généralement d'administration des applications (gestion de la charge, de la tolérance aux pannes, de la sécurité, etc.).
Pour déployer une application logicielle dans un environnement virtualisé de type informatique dans le nuage, il est nécessaire de générer des images virtuelles qui vont être instanciées sous forme de machines virtuelles pour supporter l'exécution de l'application sur une plate -forme de type IaaS. Chaque image logicielle se compose de briques techniques (système d'exploitation et intergiciels) et de briques fonctionnelles (données et logiciels applicatifs). Une fois instanciée, chaque machine virtuelle fait généralement l'objet d'une phase de configuration dynamique finalisant le paramétrage de l'application répartie.
Une ressource virtualisée désigne un artefact logiciel dont la finalité est la dématérialisation d'une ressource physique (ou réelle). Pour cela, elle en reproduit les comportements et les caractéristiques à l'identique. Ainsi, de manière comparable à une machine physique, une machine virtuelle est caractérisée par le nombre de processeurs, la quantité de mémoire, les unités de stockage et les interfaces réseaux dont elle dispose. En outre, elle fonctionne de façon identique à n'importe quelle machine réelle. La virtualisation des ressources physiques ne se limite pas aux serveurs et concerne également les entités de stockage et les équipements réseaux.
L'un des principaux intérêts de la virtualisation est de permettre la consolidation des ressources matérielles par mutualisation. Cela consiste à mettre en œuvre simultanément un ensemble de ressources matérielles virtualisées au niveau d'une infrastructure matérielle physique commune (i.e. plusieurs machines virtuelles s'exécutant sur une même machine physique). L'architecture d'une application correspond à la modélisation, d'une part, de l'ensemble des éléments logiciels (ex. exécutables et données) et matériels (ex. machines) nécessaires au fonctionnement de l'application et, d'autre part, à l'ensemble des contraintes (ou dépendances) qui lient ces éléments entre eux. La nature de ces dépendances est variable. Elles peuvent notamment concerner des dépendances :
- de placement d'un élément logiciel par rapport à un autre (i.e. co-localisation, non-co-localisation au sein d'une machine virtuelle) ;
- de configuration entre deux éléments logiciels;
- d'activation / désactivation d'un élément logiciel par rapport à un autre.
On se place par la suite dans le cadre d'un modèle d'application reposant sur des composants permettant de décrire les éléments logiciels qui constituent une application et leur projection sur une infrastructure d'exécution ainsi que les dépendances qui les lient au sein de l'architecture applicative. Une application logicielle est ainsi modélisée par un modèle d'application comprenant au moins un composant administrant un élément logiciel et des contraintes de déploiement.
De façon générale, reconfigurer une application consiste à faire évoluer son architecture. La reconfiguration comprend des opérations élémentaires d'ajout, de suppression et/ou de modification des éléments logiciels et des dépendances entre éléments qui composent l'architecture applicative.
Dans une approche décentralisée, où les configurations des machines virtuelles s'exécutent indépendamment les unes des autres, il existe un risque d'apparition d'incohérences dans les états des composants administrant les éléments logiciels lors de la reconfiguration de l'application. A titre d'exemple illustratif, dans une nouvelle configuration, un composant A doit se connecter à un composant à créer B sur une autre machine virtuelle. Lorsque le composant A essaie de se connecter, le composant B n'est pas encore créé. La reconfiguration de l'application échoue.
Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.
Selon un premier aspect, l'invention a pour objet un procédé de reconfiguration d'un modèle d'application pour un déploiement d'une application logicielle. Un modèle d'application comprend au moins un composant applicatif et des contraintes de déploiement et un modèle d'application courant, dit modèle à l'exécution, est déployé sur une infrastructure de machines virtuelles reposant sur au moins une machine physique. Le procédé comprend :
- obtention par un gestionnaire de déploiement d'un nouveau modèle d'application, dit modèle d'application cible ;
- envoi, par le gestionnaire de déploiement à un configurateur responsable d'un composant applicatif, d'une commande de déploiement d'un modèle intermédiaire, comprenant ledit au moins un composant du modèle à l'exécution et dans lequel, un composant présent dans le modèle à l'exécution et absent du modèle d'application cible est supprimé, et un composant présent dans le modèle à l'exécution et arrêté dans le modèle d'application cible est indiqué à arrêter ;
- lorsque le modèle intermédiaire est déployé sur l'infrastructure, envoi par le gestionnaire de déploiement à un configurateur responsable d'un composant applicatif, d'une commande de déploiement du modèle d'application cible,
le modèle d'application cible devenant le modèle à l'exécution une fois déployé sur l'infrastructure.
Plus précisément, le modèle intermédiaire envoyé est déterminé par le gestionnaire de déploiement.
Ainsi, par la décomposition de la reconfiguration en deux phases, il est possible de gérer correctement les états des composants, sans risque d'apparition d'incohérence. Une synchronisation est introduite à la fin de la première phase, une fois le modèle intermédiaire déployé.
A partir de la description exhaustive d'une architecture applicative cible fournie par l'administrateur de l'application, il est possible de mettre en œuvre, en deux phases, les actions de reconfiguration permettant de faire évoluer le modèle courant de l'application, dit modèle à l'exécution, vers le nouveau modèle. Pour cela, la solution de reconfiguration s'appuie sur le modèle de l'application courant, le modèle cible de l'application à mettre en place et un protocole en deux phases asynchrones, décentralisé et fiable, capable de faire évoluer l'instance courante de l'application vers l'architecture cible tout en respectant les dépendances associées (i.e. de configuration, de placement et d'activation). La première phase de ce protocole se concentre sur les opérations de suppression et d'arrêt de composants applicatifs. La seconde phase vise à procéder aux opérations d'ajout, de configuration et d'activation de composants applicatifs. Le déclenchement de la seconde phase est conditionné par la finalisation complète de la première grâce à un point de synchronisation prévu en fin de première phase.
On bénéficie ainsi des avantages associés à la mise en œuvre d'une méthode décentralisée et asynchrone. Il est ainsi possible de reconfigurer tout type d'application, indépendamment de son architecture, des technologies sur lesquelles elle s'appuie ou du domaine métier qu'elle prend en charge. Il est également possible de reconfigurer tout type d'application, indépendamment de l'infrastructure d'exécution (e.g. couche IaaS) sur laquelle est instanciée l'application. Les reconfigurations ne se restreignent pas à une reconfiguration d'une machine virtuelle mais permettent également de modifier n'importe quel sous-ensemble applicatif, sans restriction de nature ou de taille. La technique de reconfiguration permet également de mener à son terme, dans un temps fini et en présence d'un nombre fini de pannes franches de l'infrastructure d'exécution de l'application (par exemple les machines virtuelles) une opération de reconfiguration. La cohérence architecturale est par ailleurs maintenue du fait du respect des dépendances notamment d'activation entre les différents éléments. La technique de reconfiguration permet d'adapter aux exigences de l'utilisateur la quantité et la configuration des ressources matérielles et logicielles nécessaires à la mise en œuvre de l'application.
Dans un mode de réalisation particulier, le procédé de reconfiguration comprend préalablement à l'envoi du modèle d'application cible, lorsqu'un composant nécessite la mise en œuvre d'un élément logiciel non publié dans une image logicielle, une génération d'au moins une nouvelle image logicielle nécessaire à la mise en œuvre du nouveau composant, publication et instanciation sous forme d'une machine virtuelle de l'infrastructure.
Ainsi, un nouveau composant peut être créé.
Dans un mode de réalisation particulier, une estampille ordonnée est associée à un modèle d'application envoyé à un configurateur.
L'estampillage ordonné du modèle d'application envoyé permet de procéder à des synchronisations locales entre deux configurateurs. Ceci est particulièrement avantageux en termes de performance et de vitesse d'exécution par rapport à des modes de fonctionnement où le gestionnaire de déploiement centralise et synchronise l'exécution des opérations de reconfiguration. Ce mécanisme d'estampillage permet de maintenir l'exécution en parallèle, de façon asynchrone, des configurateurs.
Selon un deuxième aspect, au niveau d'un configurateur responsable d'un composant, le procédé de reconfiguration comprend :
- réception, par un configurateur responsable d'un composant applicatif en provenance d'un gestionnaire de déploiement, d'une commande de déploiement d'un modèle intermédiaire, comprenant ledit au moins un composant du modèle à l'exécution et dans lequel un composant présent dans le modèle à l'exécution et absent du modèle d'application cible est supprimé et un composant présent dans le modèle à l'exécution et arrêté dans le modèle d'application cible est indiqué à arrêter ;
- exécution d'une action, ladite action appartenant à un groupe comprenant une suppression d'un composant lorsque ledit composant est absent du modèle intermédiaire, un arrêt d'un composant lorsque ledit composant est indiqué à arrêter, un arrêt du composant lorsque ledit composant comprend une interface serveur reliée par une liaison obligatoire à une interface client d'un autre composant absent du modèle intermédiaire ;
- envoi au gestionnaire de déploiement d'une notification de changement d'état du composant ;
- réception, par un configurateur responsable d'un composant applicatif en provenance d'un gestionnaire de déploiement, d'une commande de déploiement du modèle d'application cible ;
- exécution d'une action, ladite action appartenant à un groupe comprenant une création d'un nouveau composant, une modification d'un composant, une activation d'un composant arrêté lorsque ledit composant comprend une interface serveur reliée par une liaison obligatoire à une interface client d'un nouveau composant ;
- envoi au gestionnaire de déploiement d'une notification de changement d'état du composant.
Les avantages énoncés pour le procédé de reconfiguration selon le premier aspect sont également applicables lorsque ce procédé est mis en œuvre par un configurateur.
Dans un mode de réalisation particulier, un message envoyé à un configurateur responsable d'un composant lié comprend une estampille reçue avec un modèle d'application.
Les configurateurs peuvent ainsi être synchronisés deux à deux sans nécessiter de synchronisation centralisée.
Dans un mode de réalisation particulier, une action de suppression ou d'arrêt d'un composant applicatif est effectuée lorsque ledit composant n'a pas d'interface serveur reliée par une liaison obligatoire à une interface client d'un autre composant applicatif.
Un composant applicatif ne peut pas s'arrêter ou être supprimé tant qu'il a une interface serveur reliée par une liaison obligatoire à une interface client d'un autre composant applicatif. Ceci permet de garantir que cet autre composant applicatif ne va pas continuer à s'exécuter sans recevoir les données nécessaires à son exécution. La cohérence architecturale de l'application est ainsi maintenue grâce au respect des dépendances.
Dans un mode de réalisation particulier, lors de l'exécution de l'action de suppression ou d'arrêt d'un composant applicatif, le configurateur responsable dudit composant envoie un message d'arrêt de notification pour une interface client reliée par une liaison à une interface serveur d'un autre composant.
Un composant applicatif lorsqu'il s'arrête ou lorsqu'il va être supprimé signale cet arrêt pour une interface client reliée à une interface serveur d'un autre composant. Ceci permet à cet autre composant de s'arrêter sans créer de disfonctionnement dans l'exécution de l'application. La cohérence architecturale de l'application est ainsi maintenue grâce au respect des dépendances.
Selon un troisième aspect, l'invention concerne en outre un dispositif mettant en œuvre un gestionnaire de déploiement s 'exécutant sur une machine virtuelle hébergée par le dispositif, ledit gestionnaire de déploiement comprenant pour reconfigurer un modèle d'application pour un déploiement d'une application logicielle, un modèle d'application comprenant au moins un composant applicatif et des contraintes de déploiement, un modèle d'application courant, dit modèle à l'exécution, étant déployé sur une infrastructure de machines virtuelles reposant sur au moins une machine physique :
- un module d'obtention d'un nouveau modèle d'application, dit modèle d'application cible ; - un module de détermination d'un modèle intermédiaire, comprenant ledit au moins un composant du modèle à l'exécution et dans lequel un composant présent dans le modèle à l'exécution et absent du modèle d'application cible est supprimé et un composant présent dans le modèle à l'exécution et arrêté dans le modèle d'application cible est indiqué à arrêter ;
- un module d'envoi à un configurateur responsable d'un composant applicatif, d'une commande de déploiement d'un modèle à appliquer ;
- un module de génération d'au moins une nouvelle image logicielle nécessaire à la mise en œuvre d'un nouveau composant, et d'instanciation sous forme d'une machine virtuelle de l'infrastructure ;
- un module de commande, agencé pour commander le module d'envoi pour envoyer le modèle intermédiaire déterminé et lorsque le modèle intermédiaire est déployé sur l'infrastructure, pour activer le module de génération/instanciation et pour commander le module d'envoi pour envoyer le modèle d'application cible.
Les avantages énoncés pour le procédé de reconfiguration selon le premier aspect sont transposables directement au dispositif mettant en œuvre un gestionnaire de déploiement.
Dans un mode de réalisation particulier du dispositif mettant en œuvre un gestionnaire de déploiement, le module de génération est activé pour générer une nouvelle image logicielle lorsqu'un composant nécessite la mise en œuvre d'un élément logiciel non publié dans une image logicielle.
Selon un quatrième aspect, l'invention concerne également un dispositif mettant en œuvre un configurateur s 'exécutant sur une machine virtuelle hébergée par le dispositif, ledit configurateur comprenant pour reconfigurer un modèle d'application pour un déploiement d'une application logicielle, un modèle d' application comprenant au moins un composant applicatif et des contraintes de déploiement, un modèle d'application courant, dit modèle à l'exécution, étant déployé sur une infrastructure de machines virtuelles reposant sur au moins une machine physique :
- un module de réception en provenance d'un gestionnaire de déploiement, d'une commande de déploiement d'un modèle à appliquer, ce modèle correspondant au modèle cible ou à un modèle intermédiaire comprenant ledit au moins un composant du modèle à l'exécution et dans lequel, un composant présent dans le modèle à l'exécution et absent du modèle d'application cible est supprimé, et un composant présent dans le modèle à l'exécution et arrêté dans le modèle d' application cible est indiqué à arrêter ;
- un module d'exécution d'une action, ladite action appartenant à un groupe comprenant une suppression d'un composant lorsque ledit composant est absent du modèle à appliquer, un arrêt d'un composant lorsque ledit composant est indiqué à arrêter, un arrêt d'un composant lorsque ledit composant comprend une interface serveur reliée par une liaison obligatoire à une interface client d'un autre composant absent du modèle à appliquer, une création d'un nouveau composant, une modification d'un composant, une activation d'un composant arrêté lorsque ledit composant comprend une interface serveur reliée par une liaison obligatoire à une interface client d'un nouveau composant ;
- un module d'envoi au gestionnaire de déploiement d'une notification de changement d'état du composant.
Les avantages énoncés pour le procédé de reconfiguration selon le deuxième aspect sont transposables directement au dispositif mettant en œuvre un configurateur.
Selon un cinquième aspect, l'invention concerne en outre un programme pour un dispositif, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de reconfiguration selon le premier aspect mises en œuvre par le dispositif, lorsque ce programme est exécuté par ce dispositif et un support d'enregistrement lisible par un dispositif sur lequel est enregistré un programme pour un dispositif.
Les avantages énoncés pour le procédé de reconfiguration selon le premier aspect sont transposables directement au programme pour un dispositif et au support d'enregistrement.
Selon un sixième aspect, l'invention concerne en outre un programme pour un dispositif, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de reconfiguration selon le deuxième aspect mises en œuvre par le dispositif, lorsque ce programme est exécuté par ce dispositif et un support d'enregistrement lisible par un dispositif sur lequel est enregistré un programme pour un dispositif.
Les avantages énoncés pour le procédé de reconfiguration selon le deuxième aspect sont transposables directement au programme pour un dispositif et au support d'enregistrement.
La technique de reconfiguration sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels :
- la figure 1 représente un environnement dans lequel est mis en œuvre le procédé de de reconfiguration dans un mode de réalisation particulier ;
la figure 2a représente schématiquement un premier exemple d'une application logicielle déployée selon un mode particulier de réalisation ;
la figure 2b représente schématiquement un deuxième exemple d'une application logicielle déployée selon un mode particulier de réalisation ;
la figure 3 illustre des étapes d'un procédé de reconfiguration mises en œuvre par un gestionnaire de déploiement selon un mode particulier de réalisation ; les figures 4a et 4b illustrent des étapes d'un procédé de reconfiguration mises en œuvre par un configurateur selon un mode particulier de réalisation ;
- la figure 5 représente schématiquement un dispositif mettant en œuvre un gestionnaire de déploiement dans un mode particulier de réalisation ; la figure 6 représente schématiquement un dispositif mettant en œuvre un configurateur dans un mode particulier de réalisation.
La figure 1 représente, dans son environnement, un système 200 de gestion d'une configuration de machines pour le déploiement d'une application logicielle APP dans un mode particulier de réalisation. Le système 200 permet de gérer des ressources virtuelles nécessaires à l'exécution d'une application logicielle APP. La configuration et le dimensionnement de ces ressources virtuelles ont été déterminées préalablement. Une fois cette configuration déployée, l'application logicielle peut être exécutée dans un environnement réel d'exécution.
Aucune limitation n'est attachée à la nature de l'application logicielle APP. Il peut s'agir d'une application permettant l'accès à ou la génération de contenus multimédia, le référencement de produits, l'accès à des équipements distants, etc.
Dans l'exemple envisagé ici, l'application logicielle APP est destinée à être déployée (i.e. mise en production) dans un système informatique en nuage ou cloud (non représenté), sur une configuration de machines (ou serveurs) virtuelles hébergées par le cloud. Les ressources partagées peuvent être de différentes natures : il peut s'agir notamment de ressources de type processeur ou CPU de machines (ou serveurs) virtuelles et/ou physiques, de ressources mémoires (ex. RAM, disque, etc.), ou encore de ressources réseaux (ex. connecteurs réseaux, etc.).
Une application logicielle APP comprend un ensemble d'éléments logiciels 240 qui fournissent des services et qui interagissent entre eux pour produire les fonctionnalités de l'application dans un plan applicatif. Ces éléments logiciels sont répartis au sein d'une infrastructure d'exécution composée d'un ensemble de machines virtuelles 22 (notées VM pour « Virtual Machine »). Au-delà des éléments logiciels qui la composent, une application logicielle est également définie à l'aide des contraintes de déploiement (ou dépendances) qui lient ces éléments logiciels entre eux. Il existe trois types de dépendances :
- les dépendances de configuration : un élément A a une dépendance de configuration vis-à-vis d'un élément B, si l'élément A doit disposer d'informations relatives à l'élément B pour pouvoir être configuré et interagir avec lui (e. g. l'adresse IP de l'élément B, des identifiants de connexion à une base de données, etc.)
les dépendances d'activation : un élément A a une dépendance d'activation vis-à-vis d'un élément B, si le démarrage de l'élément A est conditionné par celui de l'élément B. Dans un tel cas, dans la suite du document, une telle dépendance induit également la réciproque, à savoir qu'une telle dépendance implique que l'arrêt de l'élément B est conditionné par celui de l'élément A.
les dépendances de placement : les éléments A et B ont une dépendance de placement, si les éléments A et B doivent être co-localisés (respectivement non co-localisés) au sein de l'infrastructure d'exécution (i. e. sur une même machine virtuelle). On se place par la suite dans le cas particulier d'une application logicielle APP qui est mise en œuvre dans une plateforme VAMP (pour « Virtual Application Management Platform »). La plateforme VAMP est une structure logicielle (ou « framework » logiciel) qui permet un déploiement d' applications arbitraires dans un système informatique en nuage ou cloud sur une configuration de machines (ou serveurs) virtuelles hébergées par le cloud. VAMP permet d' assurer le déploiement autonome, générique et fiable de toute application répartie dans un environnement de type informatique dans le nuage. Une telle plateforme VAMP est décrite dans l'article « Configuration of Distributed Applications in the Cloud » de X. Etchevers et publié dans les actes de la conférence IEEE Cloud 2011 , 668-675. Une application est dite arbitraire si aucune hypothèse n'est faite quant à son architecture (i. e. l'organisation des éléments logiciels qui la composent), des technologies sur lesquelles elle repose ou des domaines métiers qu'elle prend en charge. Par la suite, le terme application logicielle désigne une application arbitraire. Un déploiement initial de cette application logicielle APP a été effectué conformément à l'article « Automated Configuration of Legacy Applications in the Cloud » de X. Etchevers et al, publié dans les actes de la conférence UCC 2011 , 170-177.
Une plateforme VAMP comprend :
- un modèle à base de composants permettant de décrire les éléments logiciels qui constituent une application et leur projection sur une infrastructure d'exécution ainsi que les dépendances qui les lient au sein de l'architecture applicative ;
- un protocole asynchrone, réparti et fiable d'auto-configuration et d'auto-activation de l' application ;
- des mécanismes visant à fiabiliser le système VAMP lui-même.
Une plateforme VAMP s'appuie sur un modèle d' application composé :
- d'un modèle d'architecture basée sur le modèle à composant Fractal (défini par le consortium OW2, Fractal ADL, disponible sur le site Web http://fractal.ow2.org/fractaladl/) et permettant de définir l'organisation d'une application logicielle répartie selon un ensemble d'unités d'exécution, et
- d'un modèle de machine virtuelle, qui modélise l'infrastructure matérielle et logicielle sur laquelle l' application va être projetée et qui introduit deux extensions au formalisme défini par la spécification OVF (pour « Open Virtualization Format »).
Une machine virtuelle est vue comme l'agrégation d'un ensemble de processeurs, d'une quantité de disques, d'interfaces réseaux et de disques. Chaque disque se caractérise par une taille et une image peut lui être associée. Le contenu d'une image est représenté au moyen d'un système d'exploitation, d'un ensemble d'intergiciels ( ou « middleware ») et de données utilisateur qui peuvent aussi bien être des binaires que des données applicatives. Un module de virtualisation ou hyperviseur désigne un environnement d'exécution capable de créer, activer, migrer, stopper et détruire des machines virtuelles. L'hyperviseur gère l'allocation des ressources matérielles entre les différentes instances de machines virtuelles et met à disposition des machines virtuelles ces ressources virtualisées.
Un gestionnaire VAMP 100 constitue le point d'accès unique au service de déploiement. Tel que représenté sur la figure 1, il est installé sur une machine virtuelle 10. Aucune limitation n'est attachée à cette représentation, le gestionnaire VAMP pouvant également être installé sur une machine physique. Le gestionnaire VAMP 100 a pour principale mission de traiter les requêtes de déploiement d'application logicielle provenant des utilisateurs. Pour chaque nouvelle requête, il instancie dynamiquement un nouveau gestionnaire de déploiement 210 dans une nouvelle machine virtuelle 21 et il lui transmet la requête de déploiement associée. Outre ce rôle, le gestionnaire VAMP 100 permet également à un utilisateur d'obtenir un état d'avancement du déploiement de son application.
VAMP définit une architecture en couche regroupant un ensemble d'entités de contrôle situées dans un plan d'administration :
- les gestionnaires de déploiement qui procèdent à la mise en œuvre des phases du processus de déploiement comprises entre la génération des images et leur instanciation au sein de machines virtuelles. Dans un souci de fiabilisation et d'isolation des problématiques de déploiement, il existe un gestionnaire dédié au déploiement de chaque application.
- des agents de configuration ou configurateurs qui coopèrent entre eux pour parvenir à la finalisation du processus de déploiement (i.e. post -configuration et démarrage).
- des composants qui encapsulent les éléments logiciels qui composent l'application à déployer, afin d'en proposer une abstraction uniforme de contrôle et de supervision, répondant ainsi aux objectifs de généricité.
- un modèle de communication assurant les échanges entre ces entités de contrôle, au moyen de messages échangés au travers d'un bus décentralisé (i.e. communication en mode point à point), asynchrone (i.e. pas d'attente active dans l'envoi d'un message) et fiable (i.e. garantie de délivrance de chaque message envoyé).
Un configurateur a notamment pour fonction de :
- créer et configurer localement les composants dont il a la responsabilité, c'est-à-dire ceux associés à des éléments logiciels applicatifs déployés dans la machine virtuelle. Lors de cette première étape, chacun des configurateurs présents sur chacune des machines virtuelles applicatives agit indépendamment des autres ;
- interagir, dans un second temps, avec les configurateurs des autres machines virtuelles applicatives pour réaliser la configuration globale, c'est-à-dire l'établissement des liaisons entre composants distants, puis l'activation de l'application conformément à l'ordre de démarrage décrit par l'utilisateur. Tel que représenté sur la figure 1 , le gestionnaire de déploiement 210 s 'exécutant dans une machine virtuelle 21 est dédié au déploiement de l' application APP ; le configurateur 220 s 'exécutant dans une machine virtuelle 22 prend en charge le déploiement du composant 230 de l' application APP. Le composant 230 comprend un élément logiciel 240 localisé sur la machine virtuelle 22 et s 'exécutant dans le plan applicatif. Un configurateur et le composant dont il est responsable sont co-localisés sur la même machine virtuelle.
Aucune limitation n'est attachée à cette représentation. En effet, le configurateur 220 peut également prendre en charge le déploiement d'autres composants de l'application APP. Leur nombre varie pour chaque application APP. D' autres configurateurs responsables de composants de l' application APP peuvent également être déployés sur d'autres machines virtuelles. Le gestionnaire de déploiement 210 et le configurateur 220 peuvent également être co-localisés sur une même machine virtuelle. Tels que représentées les machines virtuelles 21 et 22 sont co- localisées sur une machine physique 20. Aucune limitation n'est également attachée à cette représentation, les machines virtuelles pouvant être déployées sur des machines physiques distinctes.
Le gestionnaire de déploiement 210 et le ou les configurateurs 220 responsables de composants applicatifs forment un système de gestion d'une configuration 200 d'une application virtualisée.
Un composant est une entité d'administration de l'élément logiciel sous-jacent. Chaque composant expose :
tout ou partie des propriétés de configuration de l'élément logiciel applicatif, accessibles en lecture et/ou en écriture ;
des interfaces : une interface correspond à un point d'interconnexion entre composants. Une interface peut être cliente ou serveur, correspondant respectivement à la notion de service requis et de service fourni.
une propriété de placement de l'élément logiciel au sein de l'infrastructure d'exécution de l'application (i. e. les machines virtuelles).
Les dépendances de configuration et d' activation entre éléments logiciels sont capturées au sein de cette architecture applicative à l'aide de liaisons. Une liaison permet d'interconnecter l'interface client d'un composant A à l'interface serveur d'un composant B, indiquant ainsi que A dépend de B d'un point de vue de sa configuration et/ou de son activation. Une liaison est dite obligatoire lorsque l'interface client du composant A considérée doit être liée à une interface serveur du composant B, au travers de cette liaison, pour que le composant A puisse être activé. Dans le cas contraire, c'est-à-dire quand le composant A peut être activé indépendamment du fait qu'il existe ou non une liaison entre l'interface client du composant A et une interface serveur du composant B, la liaison est optionnelle. Dans le système VAMP, les composants Fractal sont implémentés à l'aide de « wrappers » (conteneurs), ou composants. Un « wrapper » est un objet Java (POJO pour « Plain Old Java Object ») qui implémente le comportement du composant au travers d'une interface incluant des opérations d' administration élémentaires :
- export : émission des attributs de configuration de l'élément logiciel encapsulé, relatives à une interface serveur du composant ;
bind : configuration de l'élément logiciel encapsulé lors de la réception d'attributs émis par un autre composant, relativement à une interface client du composant ;
unbind : destruction de la liaison entre l'interface client du composant et l'interface serveur d'un autre composant à laquelle elle était associée ;
start I stop I restart : opérations de démarrage / arrêt / redémarrage de l'élément logiciel sous- jacent.
Un « wrapper » correspond ainsi à une instance réelle d'un composant. Par la suite, on utilise le terme composant.
Sur réception d'une requête de déploiement, le gestionnaire de déploiement 210 effectue les traitements suivants en fonction des informations contenues dans la requête :
PI : génération, si nécessaire, des images logicielles (i. e. piles logicielles) nécessaires à la mise en œuvre de l'application. Chaque image virtuelle est constituée d'un système d'exploitation, d'un ensemble d'intergiciels (ou « middleware ») ainsi que de binaires et de données applicatifs. Chaque image correspond au disque principal d'une (ou de plusieurs) des machines virtuelles qui composent l'infrastructure d'exécution de l' application à déployer. Outre ces éléments, le gestionnaire de déploiement insère dans chaque pile logicielle les binaires d'un configurateur ainsi que d'un ensemble de composants.
P2 : publication des images virtuelles dans l'ensemble des plates-formes IaaS (« Infrastructure as a Service ») requises pour effectuer le déploiement de l' application. Il s' agit de les enregistrer dans le système de stockage de la plate-forme et de les rendre accessibles au travers de son répertoire d'images. Plus précisément, chaque image est publiée en fonction des besoins d'instanciation des machines virtuelles qui composent l'application.
P3 : instanciation simultanée (i.e. en parallèle) de l'ensemble des machines virtuelles applicatives au sein du ou des plate(s)-forme(s) IaaS cible(s). Dès lors, chacune de ces machines virtuelles s'initialise (ou « boot ») indépendamment des autres, de façon asynchrone.
Lors de la phase de génération, un configurateur 220 est inséré dans une image virtuelle par le gestionnaire de déploiement 210 lors du traitement Pl . Le configurateur 220 est ensuite activé automatiquement à l'issue du démarrage de la machine virtuelle 21.
Le configurateur 220 effectue alors, de manière indépendante vis-à-vis des autres configurateurs, les traitements suivants : Al- enregistrement dans le bus : le configurateur 220 contacte le gestionnaire de déploiement 210 pour indiquer qu'il souhaite s'enregistrer dans le bus à messages en tant que nouvel agent. Au terme de cette phase d'enregistrement, le gestionnaire de déploiement 210 transmet au configurateur le modèle de l'application à déployer.
- A2- instanciation des composants : à partir du modèle de l' application à déployer reçu, le configurateur 220 crée et configure localement les composants 230 dont il a la responsabilité et qui correspondent aux éléments logiciels 240 situés sur la machine virtuelle 21 où il se trouve. A3- résolution des contraintes de configuration distante : pour chaque composant dont il a la responsabilité, le configurateur 220 détermine à partir du modèle de l'application, s'il est nécessaire de transmettre des informations de configuration à destination de composants situés sur d'autres machines virtuelles applicatives. En d' autres termes, le configurateur 220 répertorie les composants locaux qui exposent une interface serveur et pour chacun d'eux, il émet un message RemoteBindingNotification contenant les informations de configuration associées vers le(s) configurateur(s) responsable du (ou des) composants dont une interface client est connectée à l'interface serveur considérée.
A4- résolution des contraintes d' activation : une fois les dépendances de configuration résolues, le configurateur 220 active les composants qui peuvent l'être : il s'agit des composants dont l'ensemble des interfaces client qui participent à une liaison obligatoire sont reliées à l'interface serveur d'un composant déjà démarré. Lorsqu'un composant est démarré, le configurateur 220 envoie un message StartNotification à l'ensemble des configurateurs dont au moins un composant dépend du composant nouvellement activé.
A5- réaction à la réception d'événements : une fois ces étapes effectuées, chaque configurateur 220 peut recevoir des messages issus d'autres configurateurs. Lorsqu'un configurateur reçoit un message RemoteBindingNotification, il le transmet au composant destinataire du message et celui-ci procède aux opérations de configuration relatives aux informations contenues dans le message. Lorsqu'un configurateur reçoit un message StartNotification, il détermine si le(s) composant(s) impacté(s) par ce démarrage peut (peuvent) à leur tour être démarré(s).
Pour chaque composant dont il a la charge, le configurateur 220 envoie au gestionnaire de déploiement 210 une notification de changement d'état, une fois le composant démarré.
A chaque réception d'une notification de changement d'état par le gestionnaire de déploiement 210, ce dernier détermine si le déploiement de l'application dans son ensemble est terminé.
Le procédé de déploiement initial est également fiable vis-à-vis des pannes franches de l'infrastructure d'exécution (i.e. machines virtuelles, réseau, .. .). En effet, lors de la création d'une machine virtuelle, le gestionnaire de déploiement arme une temporisation correspondant à une durée maximale de démarrage d'une machine virtuelle. Si cette temporisation arrive à expiration, le gestionnaire de déploiement demande de nouveau la création d'une nouvelle machine virtuelle tout en prenant soin de demander la destruction éventuelle de l'instance précédente (cas des faux positifs). Cette opération repose sur le fait que l'infrastructure de cloud est elle-même fiable. De plus, dès son instanciation, chaque configurateur initie un mécanisme de type « heart beat » par un envoi à intervalles réguliers d'un signal d'une preuve de vie à destination du gestionnaire de déploiement. Si ce signal, émis régulièrement, ne parvient pas dans un délai maximum au gestionnaire de déploiement, celui-ci procède au remplacement de la machine virtuelle défaillante par une instance de remplacement. Ce remplacement s'accompagne de l'élimination d'éventuels cas « faux positifs ». Tous les configurateurs qui participent au déploiement de l'application sont informés lors d'une panne d'une machine virtuelle et donc d'un configurateur. Dès lors, les configurateurs voisins, en termes de dépendances de configuration et d'activation, réémettent les messages qu'ils avaient déjà émis en direction de l'instance précédente. Symétriquement, à réception d'un message RemoteBindingNotification (respectivement d'un message StartNotification) de l'instance de remplacement, un composant procède à une opération de reconfiguration (respectivement de redémarrage).
Les figures 2a et 2b représentent schématiquement deux applications déployées sur une infrastructure IaaS.
La figure 2a correspond à une application comprenant trois composants CO, Cl, C2 respectivement déployés sur des machines virtuelles VMO, VM1, VM2. Le composant C2 comprend une unique interface, qui est une interface serveur destinée à être reliée à une interface client du composant Cl par une liaison obligatoire. Cette liaison est notée L12. Le composant Cl comprend deux interfaces : une interface serveur destinée à être reliée à une interface client du composant C0 par une liaison obligatoire (notée LOI) et l'interface client destinée à être reliée à l'interface serveur du composant C2 (liaison L12). Le composant C0 comprend une unique interface, qui est l'interface client destinée à être reliée à l'interface serveur du composant Cl. Une fois enregistré sur le bus à messages, le configurateur responsable du composant C2 émet un message RemoteBindingNotification contenant les informations de configuration associées vers le configurateur responsable du composant Cl dont l'interface client est connectée à l'interface serveur qu'il propose. Le composant C2 ne disposant pas d'une interface client participant à une liaison obligatoire, le configurateur responsable du composant C2 démarre le composant C2 et envoie un message StartNotification au configurateur responsable du composant Cl.
Le configurateur responsable du composant Cl émet un message RemoteBindingNotification contenant les informations de configuration associées vers le configurateur responsable du composant C0 dont l'interface client est connectée à l'interface serveur qu'il propose. Le composant Cl disposant d'une interface client participant à une liaison obligatoire, le configurateur responsable du composant Cl vérifie si le composant C2 a démarré. Si tel est le cas, le configurateur responsable du composant Cl démarre le composant Cl et envoie un message StartNotification au configurateur responsable du composant C0.
Le configurateur responsable du composant C0, ce dernier disposant d'une interface client participant à une liaison obligatoire, vérifie si le composant Cl a démarré. Si tel est le cas, le configurateur responsable du composant C0 démarre le composant C0 et envoie un message StartNotification au configurateur responsable du composant Cl.
On constate sur cet exemple que les composants démarrent dans l'ordre suivant : composant C2, composant Cl, composant C0. En effet, par exemple si le composant C0 démarrait avant les deux autres composants, l'application ne pourrait s'exécuter et rendre le service attendu à un utilisateur.
La figure 2b correspond à une application plus complexe, comprenant trois composants C0, Cl, C2 respectivement localisés sur trois machines virtuelles VMO, VM1, VM2. Chacun des composants C0, Cl, C2 dispose de deux interfaces client et de deux interfaces serveur. La première interface client du composant C0 est reliée à une première interface serveur du composant Cl par une liaison LOI. La deuxième interface client du composant C0 est reliée à une première interface serveur du composant C2 par une liaison L02. La première interface serveur du composant C0 est reliée à une première interface client du composant Cl par une liaison L10 obligatoire. La deuxième interface serveur du composant C0 est reliée à une première interface client du composant C2 par une liaison L20 obligatoire. La deuxième interface client du composant Cl est reliée à une deuxième interface serveur du composant C2 par une liaison L12. La deuxième interface serveur du composant Cl est reliée à une deuxième interface client du composant C2 par une liaison L21 obligatoire. Dans cet exemple, pour démarrer le composant C2, il est nécessaire que les composants C0 et Cl soient démarrés, et pour démarrer le composant Cl, il est nécessaire que le composant C0 soit démarré. On constate sur cet exemple que les composants démarrent dans l'ordre suivant : composant C0, composant Cl, composant C2.
Une fois le déploiement réalisé, le gestionnaire de déploiement 210 mémorise un modèle à l'exécution MOD_Ex (ou model@ runtime), représentant l'état de déploiement courant de l'application. Ce modèle à l'exécution comprend le modèle de l'application déployée, ou modèle d'application courant, et des informations liées à l'instance de l'application telles que :
- un état d'avancement du déploiement des machines virtuelles applicatives ;
un état de déploiement des composants applicatifs qui traduit l'avancement des opérations de configuration et d'activation des éléments logiciels sous-jacents ;
un état d'avancement dans l'établissement des liaisons entre composants applicatifs ;
un état de génération des piles logicielles (i.e. images logicielles) associées aux machines virtuelles applicatives ; un ensemble d'informations contextuelles tels que les adresses réseaux (adresses IP) des machines virtuelles applicatives, leur identifiant dans la plate-forme d'IaaS dans laquelle elles sont instanciées, etc.
Ce modèle à l'exécution MOD_Ex est construit à partir du modèle de l'application contenu dans la requête de déploiement émise par l'utilisateur du système VAMP ainsi que par les informations remontées au cours du déploiement par chaque configurateur. Le gestionnaire de déploiement 210 dispose ainsi d'une vue globale courante de l'avancement du déploiement de l'application.
Au niveau de chaque configurateur 220, ce modèle à l'exécution est mis à jour :
- soit par le configurateur lui-même, pour les éléments locaux à la machine virtuelle considérée ; soit par des mises à jour émises par le gestionnaire de déploiement 210.
La figure 3 représente des étapes du procédé de reconfiguration mis en œuvre par un gestionnaire de déploiement 210.
Dans une étape El, le gestionnaire de déploiement 210 reçoit une demande de modification du modèle à l'exécution vers un modèle cible MOD_T. Ce modèle cible correspond à un nouveau modèle à appliquer et décrit une nouvelle architecture de l'application APP. Cette demande de déploiement est reçue directement d'un utilisateur du système VAMP ou par l'intermédiaire du gestionnaire VAMP. Dans ce modèle cible, des éléments peuvent être supprimés, des éléments peuvent être arrêtés (par exemple en raison d'une opération de maintenance), des éléments peuvent être créés ou modifiés.
Dans une première phase φΐ, dans une étape E2, le gestionnaire de déploiement 210 détermine un modèle intermédiaire MOD_Int. Plus précisément, le gestionnaire de déploiement 210 détermine par comparaison entre le modèle à l'exécution MOD_Ex et le modèle cible MOD_T les éléments à supprimer ou les éléments à arrêter. Le terme élément désigne aussi bien les machines virtuelles VM, les piles logicielles, les composants et les liaisons. Le gestionnaire de déploiement 210 mémorise les éléments du modèle à l'exécution qui ne sont pas à supprimer ou à arrêter dans le modèle intermédiaire MOD_Int. Ainsi, ce modèle intermédiaire ne contient ni les éléments à ajouter ni les modifications de configuration à effectuer sur des éléments existants tels que définis dans le modèle cible.
Dans une étape E3, le gestionnaire de déploiement 210 transmet aux configurateurs 220 le modèle intermédiaire MOD_Int pour déploiement.
Dans une étape E4, le gestionnaire de déploiement 210 attend une confirmation de chacun des configurateurs que le modèle intermédiaire MOD_Int a bien été appliqué. Plus précisément, la confirmation correspond à une réception d'une notification de changement d'état envoyée par le configurateur 220 pour chaque composant concerné. Une fois toutes les notifications de changement d'état reçues, les éléments qui étaient à supprimer ne sont plus présents sur les machines virtuelles, les éléments qui étaient à arrêter l'ont été et les éléments impactés par la suppression ou l'arrêt d'un autre élément ont été arrêtés. La première phase φΐ est alors terminée, les éléments absents du modèle d'application cible ayant été supprimés du modèle à l'exécution et les éléments arrêtés dans le modèle d'application cible ayant été arrêtés dans le modèle à l'exécution. Le modèle intermédiaire devient le nouveau modèle à l'exécution.
Dans une deuxième phase φ2, dans une étape E5, le gestionnaire de déploiement 210 procède alors par comparaison entre le modèle à l'exécution MOD_Ex et le modèle cible MOD_T, à la génération, lorsqu'un composant nécessite la mise en œuvre d'un élément logiciel non publié dans une image logicielle, des nouvelles images logicielles (i. e. piles logicielles) nécessaires à la mise en œuvre de l'application (traitement PI décrit précédemment), à la publication de ces nouvelles images virtuelles (traitement P2 décrit précédemment), et à la reconfiguration des propriétés relatives à des machines virtuelles existantes (modification d'une machine virtuelle) et à l'instanciation de l'ensemble des nouvelles machines virtuelles applicatives (traitement P3 décrit précédemment).
Dans une étape E6, le gestionnaire de déploiement 210 transmet alors le modèle cible aux configurateurs 220, afin que ces derniers effectuent les opérations d'ajout, d'activation et de modification sur les composants applicatifs.
Dans une étape E7, le gestionnaire de déploiement 210 attend une confirmation de chacun des configurateurs que le modèle cible MOD_T a bien été appliqué. Plus précisément, la confirmation correspond à une réception d'une notification de changement d'état envoyée par le configurateur 220 pour chaque composant concerné. Une fois toutes les notifications de changement d'état reçues, les éléments à ajouter ont été créés sur les machines virtuelles, les éléments à activer l'ont été et les éléments à modifier ont été mis à jour. Ceci termine la deuxième phase φ2.
Ainsi, par la mise en œuvre de ces deux phases, la reconfiguration du modèle à l'exécution vers le modèle cible MOD_T a été effectuée sans nécessiter un nouveau déploiement complet de l'application sur les machines virtuelles et sans créer d'incohérences d'état entre les différents composants. La cohérence architecturale de l'application a été maintenue.
La figure 4a illustre des étapes d'un procédé de reconfiguration d'un modèle à l'exécution MOD_Ex vers un modèle à appliquer mises en œuvre par un configurateur 220 de l'application APP.
Dans une étape Fl, le configurateur 220 reçoit un modèle à appliquer.
Dans une étape F2, le configurateur 220 détermine en fonction du modèle à l'exécution MOD_Ex une ou des actions à effectuer pour obtenir le modèle à appliquer reçu. Ces actions correspondent le cas échéant à une suppression de composant, un arrêt de composant, une activation de composant, une modification de composant ou un ajout de composant. Un composant doit être arrêté lorsqu'il dépend en tant que client d'un composant à supprimer ou à arrêter au travers d'une liaison obligatoire. Une interface client d'un composant relié par une liaison obligatoire à une interface serveur d'un autre composant doit être déconfigurée lorsque cet autre composant est à supprimer et ceci doit être effectué préalablement à la suppression de cet autre composant. Une suppression d'un composant correspond notamment à une désinstallation du logiciel correspondant, à une libération des ressources et à un nettoyage des données.
Dans une étape F3, le configurateur 220 exécute le cas échéant l'action ou les actions déterminées à l'étape F2. Au cours de l'exécution de cette étape F3, le configurateur 220 envoie au gestionnaire de déploiement 210 une notification de changement d'état pour chaque composant concerné.
Ces étapes Fl à F3 sont mises en œuvre lors d'une reconfiguration d'un modèle à l'exécution vers un modèle cible, une première fois avec le modèle intermédiaire MOD_Int déterminé par le gestionnaire de déploiement à l'étape E2 et une deuxième fois avec le modèle cible MOD_T transmis par le gestionnaire de déploiement à l'étape E6.
La figure 4b représente plus précisément l'étape F3 mise en œuvre par le configurateur
220.
Dans une étape F30, le configurateur 220 vérifie s'il a une ou plusieurs actions à effectuer.
S'il n'a pas d'action à effectuer, l'étape F3 est terminée.
Si le configurateur 220 a au moins une action à effectuer, dans une étape F31, le configurateur 220 détermine si action appartient à un groupe comprenant une suppression ou un arrêt d'un composant 230. Si tel est le cas, dans une étape F32, le configurateur 220 vérifie s'il existe une interface serveur du composant 230 reliée par une liaison obligatoire à une interface client d'un autre composant. Si tel est le cas, le composant 230 ne pouvant pas être arrêté immédiatement, dans une étape F320, le configurateur 220 se place alors en attente de réception d'un message d'arrêt de notification StopNotification en provenance du configurateur responsable de cet autre composant. Un tel message est reçu dans une étape F321. Toujours dans cette étape F321, le configurateur 220 met à jour sa représentation locale du modèle à l'exécution en fonction de ce message reçu. Le configurateur 220 met de nouveau en œuvre l'étape F32 de vérification s'il existe une interface serveur du composant 230 reliée par une liaison obligatoire à une interface client d'un autre composant.
S'il est vérifié à l'étape F32 qu'il n'existe pas d'interface serveur du composant 230 reliée par une liaison obligatoire à une interface client d'un autre composant, le composant 230 est arrêté car il ne joue pas un rôle de serveur vis-à-vis d'un des autres composants de l'application. Dans une étape F322, le configurateur 220 envoie un message d'arrêt de notification StopNotification pour une interface client reliée par une liaison à une interface serveur d'un autre composant s'il en existe. Plus précisément, ce message d' arrêt de notification est envoyé aux configurateurs responsables de ces autres composants.
Dans une étape F323, le configurateur 220 exécute l'action à effectuer. Lorsque l'action est un arrêt du composant, le configurateur 220 arrête l'exécution du composant 230 et modifie un état du composant à « stopped ». Lorsque l' action est une suppression du composant, le configurateur 220 arrête l'exécution du composant 230, relâche les ressources utilisées par ce composant et modifie un état du composant à « deleted ».
Dans une étape F324, le configurateur 220 mémorise dans sa représentation locale du modèle à l'exécution le nouvel état, « stopped » ou « deleted », du composant 230.
Dans une étape F325, le configurateur 220 envoie au gestionnaire de déploiement 210 une notification de changement d'état, comprenant le nouvel état du composant 230.
Le configurateur 220 exécute de nouveau l'étape F30, afin de vérifier s'il a encore une ou plusieurs actions à effectuer.
S'il est vérifié à l'étape F31 que l'action ne correspond pas à une suppression ou un arrêt d'un composant 230, cette action appartient alors à un groupe comprenant une création, une activation ou une modification du composant 230.
Dans une étape F311 , le configurateur 220 exécute le traitement A2 décrit précédemment. Plus précisément, s'il s'agit d'une création d'un composant, le configurateur 220 crée le composant correspondant. Dans les deux cas, création et modification, le configurateur 220 configure localement le composant correspondant.
Dans une étape F312, le configurateur 220 exécute le traitement A3 décrit précédemment. Plus précisément, le configurateur 220 répertorie les composants locaux qui exposent une interface serveur et pour chacun d'eux, il émet un message RemoteBindingNotification contenant les informations de configuration associées vers le(s) configurateur(s) responsable du (ou des) composant(s) dont une interface client est connectée à l'interface serveur considérée. S'il s'agit uniquement d'une modification d'une propriété de configuration d'un composant, il n'y a pas d'émission de message RemoteBindingNotification.
Dans une étape F313, le configurateur 220 exécute le traitement A4 décrit précédemment. Plus précisément, le configurateur 220 active le composant dont l'ensemble des interfaces client qui participent à une liaison obligatoire sont reliées à l'interface serveur d'un composant déjà démarré. Lorsqu'un composant est démarré, le configurateur 220 envoie un message StartNotification à l'ensemble des configurateurs dont au moins un composant dépend du composant nouvellement activé ou modifié.
Dans une étape F314, le configurateur 220 modifie l'état du composant à « started ». Dans une étape F315, le configurateur 220 mémorise dans sa représentation locale du modèle à l'exécution le nouvel état, « started », du composant 230. Le configurateur 220 exécute alors l'étape F325, précédemment décrite, d'envoi au gestionnaire de déploiement 210 d'une notification du nouvel état du composant 230.
On comprend de cette description de l'étape F3, que lors de la réception d'un modèle intermédiaire, les étapes F32x sont notamment mises en œuvre pour l'arrêt ou la suppression d'un composant et lors de la réception du modèle cible, les étapes F31x sont notamment mises en œuvre pour la création, l'activation ou la modification d'un composant.
De retour à l'exemple de la figure 2a, on se place dans le cas où le composant Cl n'est plus présent dans le modèle cible. Le composant C0 doit être arrêté car une de ses interfaces client est reliée par une liaison obligatoire LOI à une interface serveur du composant Cl . Le composant Cl doit être supprimé. Le composant C2 n'est pas modifié car il n'a pas d'interface client reliée par une liaison obligatoire à une interface serveur du composant Cl .
La description qui suit est effectuée de manière séquentielle. Il est ici souligné qu'il s' agit d'une question de lisibilité et que les différents configurateurs travaillent en parallèle et de manière asynchrone.
Le configurateur du composant C0 détermine que ce composant doit être arrêté. Il vérifie
(étape F32) qu'il n'a pas d'interface serveur reliée par une liaison obligatoire à une interface client d'un autre composant. Il envoie (étape F322) un message d'arrêt de notification StopNotification au configurateur responsable du composant Cl . Puis il arrête le composant C0 (étape F323).
Le configurateur du composant Cl détermine que ce composant doit être supprimé. Il vérifie (étape F32) qu'il a une interface serveur reliée par une liaison obligatoire à une interface client du composant C0. Tant que le composant C0 est actif, il se place en attente (étape F320). Une fois le message d'arrêt de notification StopNotification reçu (étape F321) en provenance du composant C0, comme il n' a plus d'interface serveur reliée par une liaison obligatoire à une interface client d'un autre composant (étape F32), il envoie (étape F322) un message d'arrêt de notification StopNotification au configurateur responsable du composant C2. Puis il arrête et supprime le composant Cl (étape F323).
Le configurateur du composant C2 détermine qu'il n'a pas d' action à effectuer. Sur réception du message d'arrêt de notification StopNotification en provenance du composant Cl , il met à jour sa représentation locale du modèle à l'exécution. On constate ainsi qu'il n'est pas possible de supprimer le composant Cl tant que le composant C0 n'est pas arrêté.
De retour à l'exemple de la figure 2b, on se place dans le cas où dans le modèle cible le composant Cl doit être supprimé et remplacé par un composant C4. Ce composant C4 s 'interface avec les composants C0 et C2 par des liaisons similaires à celles du composant Cl avec les composants C0 et C2. Le gestionnaire de déploiement 210 détermine (étape E2) un modèle intermédiaire, dans lequel le composant Cl n'est plus présent. Le composant C0 n'est pas modifié car aucune de ses interfaces client n'est reliée par une liaison obligatoire à une interface serveur du composant Cl (la liaison LOI est optionnelle). Le composant Cl doit être supprimé. Le composant C2 est à arrêter car il a une interface client reliée par une liaison obligatoire L21 à une interface serveur du composant Cl .
Le configurateur du composant C0 détermine qu'il n' a pas d' action à effectuer.
Le configurateur du composant Cl détermine que ce composant doit être supprimé. Il vérifie (étape F32) qu'il a une interface serveur reliée par une liaison obligatoire L21 à une interface client du composant C2 (LOI est une liaison optionnelle). Tant que le composant C2 est actif, il se place en attente (étape F320). Une fois le message d'arrêt de notification StopNotification reçu (étape F321) en provenance du composant C2, comme il n' a plus d'interface serveur reliée par une liaison obligatoire à une interface client d'un autre composant (étape F32), il envoie (étape F322) un message d' arrêt de notification StopNotification aux configurateurs responsables des composants C0 et C2. Puis il arrête et supprime le composant Cl (étape F323).
Le configurateur du composant C2 détermine que ce composant doit être arrêté. Il vérifie (étape F32) qu'il n'a pas d'interface serveur reliée par une liaison obligatoire à une interface client d'un autre composant (L02 et L12 sont des liaisons optionnelles). Il envoie (étape F322) un message d'arrêt de notification StopNotification aux configurateurs responsables des composants C0 et Cl . Puis il arrête (étape F323) le composant C2.
Sur réception du message d' arrêt de notification StopNotification en provenance du composant C2, les configurateurs responsables des composants C0 et Cl mettent à jour leur représentation locale du modèle à l'exécution. Sur réception du message d'arrêt de notification StopNotification en provenance du composant Cl , les configurateurs responsables des composants C0 et C2 mettent à jour leur représentation locale du modèle à l'exécution. On constate ainsi qu'il n'est pas possible de supprimer le composant Cl tant que le composant C2 n'est pas arrêté.
Le gestionnaire de déploiement 210 reçoit (étape E4) les notifications de changement d'état en provenance des configurateurs responsables des composants Cl (état « deleted ») et C2 (état « stopped »). La première phase φΐ est ainsi terminée.
Le gestionnaire de déploiement 210 procède (étape E5), par comparaison entre le modèle à l'exécution et le modèle cible, à la génération de la nouvelle image logicielle du composant C4, à la publication de cette nouvelle image virtuelle et à la mise à jour des propriétés relatives aux machines virtuelles existantes et à instanciation de la nouvelle machine virtuelle. Le gestionnaire de déploiement 210 transmet (étape E6) le modèle cible aux configurateurs 220, afin que ces derniers effectuent les opérations nécessaires sur les composants applicatifs.
Le configurateur 220 est par exemple en charge de la création du composant C4.
Le configurateur 220 crée et configure (étape F311) localement le composant C4 correspondant. Lorsque le composant C4 expose une interface serveur, le configurateur 220 émet (étape F312) un message RemoteBindingNotification contenant les informations de configuration associées vers le(s) configurateur s) responsable du (ou des) composant dont une interface client est connectée à l'interface serveur considérée.
Le configurateur 220 active le composant dont l'ensemble des interfaces client qui participent à une liaison obligatoire sont reliées à l'interface serveur d'un composant déjà démarré.
Le composant C0 est déjà démarré.
Le composant C2 doit être redémarré. Le configurateur du composant C2 envoie un message StartNotification aux composants C0 et C4. L'état du composant C2 devient « started ».
Lorsque le composant C4 est démarré, le configurateur 220 envoie un message StartNotification aux composants C0 et C2. L'état du composant C4 devient « started ».
Le gestionnaire de déploiement 210 reçoit (étape E4) les notifications de changement d'état en provenance des configurateurs responsables des composants C4 (état « started ») et C2 (état « started »). Cette deuxième phase φ2 est ainsi terminée. Le modèle cible a été déployé et l' application est de nouveau opérationnelle.
Le procédé de reconfiguration en deux phases est asynchrone, réparti et fiable. Il s'appuie sur les éléments suivants :
la définition et la mémorisation d'une représentation courante de l' application déployée (i.e. le modèle à l'exécution). Il permet au gestionnaire de déploiement de procéder à des comparaisons entre le modèle d'application cible à déployer et un état courant de application et de calculer les actions à effectuer en termes de reconfiguration.
- la comparaison entre deux versions du modèle d'application qui permet de déterminer les éléments (i.e. machines virtuelles, images, composants et liaisons) à modifier, à supprimer, à arrêter ou à ajouter.
l' arrêt d'un composant applicatif, qui procède de façon symétrique à son activation en s'appuyant sur la définition des contraintes d'activation au moyen des liaisons.
Dans un mode de réalisation particulier, un estampillage est représentatif d'une version du modèle d' application à déployer. Cet estampillage est associé au modèle envoyé aux configurateurs. Les messages envoyés par les configurateurs incluent cet estampillage, afin de faire référence à la version du modèle d' application. Les estampilles sont ordonnées, de façon absolue, dans le temps. Il est donc possible, à partir de ces estampilles, de classer les versions du modèle d' application. Cette estampille peut être par exemple temporelle. Le modèle à l'exécution au sein du gestionnaire de déploiement ainsi qu'au niveau de chaque configurateur dispose de la valeur d'estampille qui lui est associé.
Lorsqu'il émet un message de type RemoteBindingNotification, StartNotification ou StopNotification, un configurateur enrichit le message de la valeur d'estampille dont il a connaissance. De manière symétrique, lorsqu'un configurateur reçoit un message de type RemoteBindingNotification, StartNotification ou StopNotification, il procède de la façon suivante : si l'estampille contenue dans le message reçu est antérieure à l'estampille courante du configurateur (c'est-à-dire celle associée au dernier modèle qu'il a reçu), il n'effectue aucune opération et détruit le message, ce dernier étant considéré comme périmé.
si l'estampille contenue dans le message est postérieure à l'estampille courante du configurateur, le message est mis en attente, jusqu'à ce que l'estampille du configurateur soit égale (suite à la réception d'une mise à jour du modèle) à l'estampille du message reçu. Le message est alors traité.
- si l'estampille du message et celle du configurateur sont égales, le message est traité immédiatement.
Ce mécanisme d'estampille permet de prendre en compte l'asynchronisme dans l'exécution des différents configurateurs. Il peut être vu comme un mécanisme de synchronisation deux à deux entre configurateurs.
L'estampille d'un configurateur est mise à jour lorsqu'il reçoit du gestionnaire de déploiement une nouvelle version du modèle d'application à déployer.
L'estampille du gestionnaire de déploiement est incrémentée à chaque nouvelle opération de déploiement.
Cet estampillage permet de garantir une synchronisation entre les différents composants. La figure 5 représente un dispositif mettant en œuvre un gestionnaire de déploiement dans un mode particulier de réalisation. Le gestionnaire de déploiement comprend notamment :
- un processeur 211 pour exécuter des instructions de code de modules logiciels ;
- une zone mémoire 212, agencée pour mémoriser une application qui comprend des instructions de code pour mettre en œuvre les étapes du procédé de reconfiguration ;
- une mémoire de stockage, non représentée, agencée pour stocker des données utilisées lors de la mise en œuvre du procédé de reconfiguration ;
- un module 213 d'obtention d'un nouveau modèle d'application, dit modèle d'application cible ;
- un module 214 de détermination d'un modèle intermédiaire, dans lequel un composant présent dans le modèle à l'exécution et absent du modèle d'application cible est supprimé et un composant présent dans le modèle à l'exécution et arrêté dans le modèle d'application cible est indiqué à arrêter ;
- un module 215 d'envoi à un configurateur responsable d'un composant applicatif, d'une commande de déploiement d'un modèle à appliquer ;
- un module 216 de génération d'au moins une nouvelle image logicielle nécessaire à la mise en œuvre d'un nouveau composant, et d'instanciation sous forme d'une machine virtuelle de l'infrastructure ; - un module 217 de commande, agencé pour commander le module d'envoi pour envoyer le modèle intermédiaire déterminé et lorsque le modèle intermédiaire est déployé sur l'infrastructure, pour activer le module de génération/instanciation et pour commander le module d'envoi pour envoyer le modèle d'application cible.
Dans un mode de réalisation particulier, le module 216 de génération est activé lorsqu'un composant nécessite la mise en œuvre d'un élément logiciel non publié dans une image logicielle.
La figure 6 représente un dispositif mettant en œuvre un configurateur dans un mode particulier de réalisation. Le configurateur comprend notamment :
- un processeur 221 pour exécuter des instructions de code de modules logiciels ;
- une zone mémoire 222, agencée pour mémoriser une application qui comprend des instructions de code pour mettre en œuvre les étapes du procédé de reconfiguration ;
- une mémoire de stockage, non représentée, agencée pour stocker des données utilisées lors de la mise en œuvre du procédé de reconfiguration ;
- un module de réception 223 en provenance d'un gestionnaire de déploiement, d'une commande de déploiement d'un modèle à appliquer, ce modèle correspondant au modèle cible ou à un modèle intermédiaire dans lequel un composant présent dans le modèle à l'exécution et absent du modèle d'application cible est supprimé et un composant présent dans le modèle à l'exécution et arrêté dans le modèle d'application cible est indiqué à arrêter ;
- un module d'exécution 224 d'une action, ladite action appartenant à un groupe comprenant une suppression d'un composant lorsque ledit composant est absent du modèle à appliquer, un arrêt d'un composant lorsque ledit composant est indiqué à arrêter dans le modèle à appliquer, un arrêt d'un composant lorsque ledit composant comprend une interface serveur reliée par une liaison obligatoire à une interface client d'un autre composant absent du modèle à appliquer, une création d'un nouveau composant, une modification d'un composant, une activation d'un composant arrêté lorsque ledit composant comprend une interface serveur reliée par une liaison obligatoire à une interface client d'un nouveau composant ;
- un module d'envoi 225 au gestionnaire de déploiement d'une notification de changement d'état du composant.
On comprend que les processeurs et les mémoires sont des ressources matérielles qui appartiennent à une machine physique. Ces ressources sont destinées à être virtualisées par l'hyperviseur et mises à disposition des machines virtuelles.
L'invention vise également un programme d'ordinateur sur un ou plusieurs support(s) d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un système de gestion de configuration ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de reconfiguration tel que décrit précédemment. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
Dans un mode de réalisation particulier, le gestionnaire de déploiement 210 est agencé pour mettre en œuvre le procédé de reconfiguration précédemment décrit. Il s'agit de préférence d'un module logiciel comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé de reconfiguration précédemment décrit, mises en œuvre par un ordinateur. L'invention concerne donc aussi :
- un programme pour un gestionnaire de déploiement, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de reconfiguration précédemment décrit, lorsque ledit programme est exécuté par cet ordinateur ;
- un support d'enregistrement lisible par un ordinateur sur lequel est enregistré le programme pour un gestionnaire de déploiement.
Dans un mode de réalisation particulier, le configurateur 220 est agencé pour mettre en œuvre le procédé de reconfiguration précédemment décrit. Il s'agit de préférence d'un module logiciel comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé de reconfiguration précédemment décrit, mises en œuvre par un ordinateur. L'invention concerne donc aussi :
- un programme pour un configurateur, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de reconfiguration précédemment décrit, lorsque ledit programme est exécuté par cet ordinateur ;
- un support d'enregistrement lisible par un ordinateur sur lequel est enregistré le programme pour un configurateur.
Les modules logiciels peuvent être stockés dans ou transmis par un support d'enregistrement. Le support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur. D'autre part, le support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
La technique de reconfiguration a été décrite pour une mise en œuvre dans une plateforme conforme à VAMP. Cette technique peut également être transposée à d'autres environnements virtuels, dans lesquels une application logicielle est représentée sous la forme d'un modèle d'application modélisant des dépendances entre entités du modèle, comprenant des composants applicatifs et des contraintes de déploiement, et le déploiement s'effectue de manière décentralisée.

Claims

REVENDICATIONS
1. Procédé de reconfiguration d'un modèle d'application pour un déploiement d'une application logicielle, un modèle d'application comprenant au moins un composant applicatif et des contraintes de déploiement, un modèle d' application courant, dit modèle à l'exécution, étant déployé sur une infrastructure de machines virtuelles (21 , 22) reposant sur au moins une machine physique (20), le procédé comprenant :
- obtention (El) par un gestionnaire de déploiement (210) d'un nouveau modèle d' application, dit modèle d'application cible ;
- détermination (E2) par le gestionnaire de déploiement d'un modèle intermédiaire dans lequel, un composant présent dans le modèle à l'exécution et absent du modèle d' application cible est supprimé, et un composant présent dans le modèle à l'exécution et arrêté dans le modèle d' application cible est indiqué à arrêter ;
- envoi (E3), par le gestionnaire de déploiement à un configurateur (220) responsable d'un composant applicatif (230), d'une commande de déploiement d'un modèle intermédiaire, comprenant ledit au moins un composant du modèle à l'exécution ;
- lorsqu'une notification de changement d'état a été reçue (E4) en provenance du configurateur pour chaque composant concerné par le déploiement du modèle intermédiaire sur l'infrastructure, envoi (E6) par le gestionnaire de déploiement à un configurateur responsable d'un composant applicatif, d'une commande de déploiement du modèle d' application cible,
le modèle d' application cible devenant le modèle à l'exécution une fois déployé sur l'infrastructure.
2. Procédé de reconfiguration selon la revendication 1 , comprenant préalablement à l'envoi du modèle d' application cible, lorsqu'un composant nécessite la mise en œuvre d'un élément logiciel non publié dans une image logicielle, une génération (E5) d' au moins une nouvelle image logicielle nécessaire à la mise en œuvre du nouveau composant, publication et instanciation (E5) sous forme d'une machine virtuelle de l'infrastructure.
3. Procédé de reconfiguration selon la revendication 1 , dans lequel une estampille ordonnée est associée à un modèle d'application envoyé à un configurateur.
4. Procédé de reconfiguration d'un modèle d'application pour un déploiement d'une application logicielle, un modèle d'application comprenant au moins un composant applicatif et des contraintes de déploiement, un modèle d'application courant, dit modèle à 'exécution, étant déployé sur une infrastructure de machines virtuelles (21 , 22) reposant sur au moins une machine physique (20), le procédé comprenant : - réception (Fl), par un configurateur (220) responsable d'un composant applicatif (230) en provenance d'un gestionnaire de déploiement (210), d'une commande de déploiement d'un modèle intermédiaire, comprenant ledit au moins un composant du modèle à l'exécution et dans lequel un composant présent dans le modèle à l'exécution et absent du modèle d' application cible est supprimé et un composant présent dans le modèle à l'exécution et arrêté dans le modèle d' application cible est indiqué à arrêter ;
- exécution (F3, F323) d'une action, ladite action appartenant à un groupe comprenant une suppression d'un composant lorsque ledit composant est absent du modèle intermédiaire, un arrêt d'un composant lorsque ledit composant est indiqué à arrêter, un arrêt du composant lorsque ledit composant comprend une interface serveur reliée par une liaison obligatoire à une interface client d'un autre composant absent du modèle intermédiaire ;
- envoi (F3, F325) au gestionnaire de déploiement d'une notification de changement d'état du composant ;
- réception (Fl), par un configurateur responsable d'un composant applicatif en provenance d'un gestionnaire de déploiement, d'une commande de déploiement du modèle d'application cible ;
- exécution (F3, F314) d'une action, ladite action appartenant à un groupe comprenant une création d'un nouveau composant, une modification d'un composant, une activation d'un composant arrêté lorsque ledit composant comprend une interface serveur reliée par une liaison obligatoire à une interface client d'un nouveau composant ;
- envoi (F3, F325) au gestionnaire de déploiement d'une notification de changement d'état du composant.
5. Procédé de reconfiguration selon la revendication 4, dans lequel un message envoyé à un configurateur responsable d'un composant lié comprend une estampille reçue avec un modèle d' application.
6. Procédé de reconfiguration selon la revendication 4, dans lequel une action de suppression ou d' arrêt d'un composant applicatif est effectuée lorsque ledit composant n'a pas d'interface serveur reliée par une liaison obligatoire à une interface client d'un autre composant applicatif.
7. Procédé de reconfiguration selon la revendication 4, dans lequel lors de l'exécution de l'action de suppression ou d'arrêt d'un composant applicatif, le configurateur responsable dudit composant envoie (F322) un message d' arrêt de notification pour une interface client reliée par une liaison à une interface serveur d'un autre composant.
8. Dispositif (20) mettant en œuvre un gestionnaire de déploiement (210) s 'exécutant sur une machine virtuelle (21) hébergée par le dispositif (20), ledit gestionnaire de déploiement comprenant pour reconfigurer un modèle d'application pour un déploiement d'une application logicielle, un modèle d'application comprenant au moins un composant applicatif et des contraintes de déploiement, un modèle d'application courant, dit modèle à l'exécution, étant déployé sur une infrastructure de machines virtuelles (21 , 22) reposant sur au moins une machine physique :
- un module (213) d'obtention d'un nouveau modèle d'application, dit modèle d' application cible ;
- un module (214) de détermination d'un modèle intermédiaire, comprenant ledit au moins un composant du modèle à l'exécution et dans lequel un composant présent dans le modèle à l'exécution et absent du modèle d'application cible est supprimé et un composant présent dans le modèle à l'exécution et arrêté dans le modèle d'application cible est indiqué à arrêter ;
- un module (215) d'envoi à un configurateur (220) responsable d'un composant applicatif (230), d'une commande de déploiement d'un modèle à appliquer ;
- un module (216) de génération d' au moins une nouvelle image logicielle nécessaire à la mise en œuvre d'un nouveau composant, et d'instanciation sous forme d'une machine virtuelle de l'infrastructure ;
- un module (217) de commande, agencé pour commander le module d'envoi pour envoyer le modèle intermédiaire déterminé et lorsqu'une notification de changement d'état a été reçue en provenance du configurateur pour chaque composant concerné par le déploiement du modèle intermédiaire sur l'infrastructure, pour activer le module de génération/instanciation et pour commander le module d'envoi pour envoyer le modèle d'application cible.
9. Dispositif selon la revendication 8, dans lequel le module de génération est activé pour générer une nouvelle image logicielle lorsqu'un composant nécessite la mise en œuvre d'un élément logiciel non publié dans une image logicielle.
10. Dispositif (20) mettant en œuvre un configurateur (220) s 'exécutant sur une machine virtuelle (22) hébergée par le dispositif (20), ledit configurateur comprenant pour reconfigurer un modèle d' application pour un déploiement d'une application logicielle, un modèle d'application comprenant au moins un composant applicatif et des contraintes de déploiement, un modèle d' application courant, dit modèle à l'exécution, étant déployé sur une infrastructure de machines virtuelles (21 , 22) reposant sur au moins une machine physique :
- un module de réception (223) en provenance d'un gestionnaire de déploiement (210), d'une commande de déploiement d'un modèle à appliquer, ce modèle correspondant au modèle cible ou à un modèle intermédiaire comprenant ledit au moins un composant du modèle à l'exécution et dans lequel, un composant présent dans le modèle à l'exécution et absent du modèle d'application cible est supprimé, et un composant présent dans le modèle à l'exécution et arrêté dans le modèle d'application cible est indiqué à arrêter ;
- un module d'exécution (224) d'une action, ladite action appartenant à un groupe comprenant une suppression d'un composant lorsque ledit composant est absent du modèle à appliquer, un arrêt d'un composant lorsque ledit composant est indiqué à arrêter, un arrêt d'un composant lorsque ledit composant comprend une interface serveur reliée par une liaison obligatoire à une interface client d'un autre composant absent du modèle à appliquer, une création d'un nouveau composant, une modification d'un composant, une activation d'un composant arrêté lorsque ledit composant comprend une interface serveur reliée par une liaison obligatoire à une interface client d'un nouveau composant ;
- un module d'envoi (225) au gestionnaire de déploiement d'une notification de changement d'état du composant.
11 Programme pour un dispositif, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé reconfiguration selon l'une des revendications 1 à 3 mises en œuvre par le dispositif, lorsque ledit programme est exécuté par ledit dispositif.
12. Support d'enregistrement lisible par un dispositif sur lequel est enregistré le programme selon la revendication 11.
13. Programme pour un dispositif, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé reconfiguration selon l'une des revendications 4 à 7 mises en œuvre par le dispositif, lorsque ledit programme est exécuté par ledit dispositif.
14. Support d'enregistrement lisible par un dispositif sur lequel est enregistré le programme selon la revendication 13.
PCT/FR2016/051466 2015-06-26 2016-06-16 Technique de reconfiguration d'un modele d'application pour un deploiement d'une application logicielle Ceased WO2016207520A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1555936A FR3038088A1 (fr) 2015-06-26 2015-06-26 Technique de reconfiguration d'un modele d'application pour un deploiement d'une application logicielle
FR1555936 2015-06-26

Publications (1)

Publication Number Publication Date
WO2016207520A1 true WO2016207520A1 (fr) 2016-12-29

Family

ID=55072757

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/051466 Ceased WO2016207520A1 (fr) 2015-06-26 2016-06-16 Technique de reconfiguration d'un modele d'application pour un deploiement d'une application logicielle

Country Status (2)

Country Link
FR (1) FR3038088A1 (fr)
WO (1) WO2016207520A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111240698A (zh) * 2020-01-14 2020-06-05 北京三快在线科技有限公司 模型部署的方法、装置、存储介质及电子设备
CN114625486A (zh) * 2022-05-12 2022-06-14 武汉四通信息服务有限公司 Iso介质管理系统、方法、装置、信服易云及存储介质

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
ABID RIM ET AL: "Verification of a Dynamic Management Protocol for Cloud Applications", 15 October 2013, CORRECT SYSTEM DESIGN; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER INTERNATIONAL PUBLISHING, CHAM, PAGE(S) 178 - 192, ISBN: 978-3-642-28871-5, ISSN: 0302-9743, XP047040181 *
LOIC LETONDEUR: "Planication pour la gestion autonomique de l'élasticité d'applications dans le cloud", THÈSE DE L'UNIVERSITÉ DE GRENOBLE, L'ÉCOLE DOCTORALE MATHÉMATIQUES, SCIENCES ET TECHNOLOGIES DE L'INFORMATION, INFORMATIQUE, 7 April 2015 (2015-04-07), pages 1 - 221, XP055261089, Retrieved from the Internet <URL:https://hal.archives-ouvertes.fr/tel-01140128/document> [retrieved on 20160324] *
MARC LÃ CR GER ET AL: "Reliable Dynamic Reconfigurations in a Reflective Component Model", 23 June 2010, COMPONENT-BASED SOFTWARE ENGINEERING, SPRINGER BERLIN HEIDELBERG, BERLIN, HEIDELBERG, PAGE(S) 74 - 92, ISBN: 978-3-642-13237-7, XP019142813 *
X. ETCHEVERS ET AL.: "Automated Configuration of Legacy Applications in the Cloud", ACTES DE LA CONFÉRENCE UCC, vol. 2011, pages 170 - 177, XP032090829, DOI: doi:10.1109/UCC.2011.32
X. ETCHEVERS: "Configuration of Distributed Applications in the Cloud", CONFÉRENCE IEEE CLOUD, 2011, pages 668 - 675, XP031934649, DOI: doi:10.1109/CLOUD.2011.65
XAVIER ETCHEVERS ET AL: "Automated Configuration of Legacy Applications in the Cloud", UTILITY AND CLOUD COMPUTING (UCC), 2011 FOURTH IEEE INTERNATIONAL CONFERENCE ON, IEEE, 5 December 2011 (2011-12-05), pages 170 - 177, XP032090829, ISBN: 978-1-4577-2116-8, DOI: 10.1109/UCC.2011.32 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111240698A (zh) * 2020-01-14 2020-06-05 北京三快在线科技有限公司 模型部署的方法、装置、存储介质及电子设备
CN114625486A (zh) * 2022-05-12 2022-06-14 武汉四通信息服务有限公司 Iso介质管理系统、方法、装置、信服易云及存储介质

Also Published As

Publication number Publication date
FR3038088A1 (fr) 2016-12-30

Similar Documents

Publication Publication Date Title
CN112214330B (zh) 集群中主节点的部署方法、装置及计算机可读存储介质
CN111654531B (zh) 一种基于容器的镜像更新发布方法及装置
JP6329547B2 (ja) クラウドコンピューティング環境で使用するサービス管理エンジンを提供するためのシステムおよび方法
CN101840346B (zh) 云主机部署的方法及系统
US20100192143A1 (en) Consistent operating system servicing for distributed nodes
Kumar Serverless architectures review, future trend and the solutions to open problems
US10380365B2 (en) Choreographed distributed execution of programs
US10585785B2 (en) Preservation of modifications after overlay removal from a container
CN107783816A (zh) 虚拟机的创建方法及装置、大数据集群创建的方法及装置
Kolb et al. Unified cloud application management
FR3013866A1 (fr) Procede, programme d&#39;ordinateur et dispositif de configuration ou de maintenance d&#39;un systeme informatique dans un cluster
US20190146833A1 (en) Managing a Lifecycle of a Software Container
CN105404530A (zh) 一种实现简易部署和使用私有云的系统及方法
WO2016207520A1 (fr) Technique de reconfiguration d&#39;un modele d&#39;application pour un deploiement d&#39;une application logicielle
Klarl et al. Helena@ work: Modeling the science cloud platform
CN114035890A (zh) 一种基于容器技术的ci/cd服务部署方法、装置、设备及介质
CN113821303A (zh) 一种部署harbor集群的方法、装置及可读存储介质
CN115048113B (zh) 一种镜像生成方法、装置、服务器及存储介质
Truyen et al. Aspects for run-time component integration
Vohra Docker Management Design Patterns
Pietschmann et al. A thin-server runtime platform for composite web applications
KR102435357B1 (ko) 블록체인 네트워크 트윈을 이용한 블록체인 통합 개발 및 관리 방법 및 시스템
Kamdi et al. A Study on Developing an Image Upload/Download System Using Cloud Services and Integration with an iOS Mobile Application
EP3144812A1 (fr) Architecture client/serveur pour l administration d&#39;un supercalculateur
Karppinen Distributed architecture with Kubernetes

Legal Events

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

Ref document number: 16736527

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16736527

Country of ref document: EP

Kind code of ref document: A1