Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Welcome to the cloudml wiki!
Before you start with CloudML, please have a look at the CloudML metamodel. It is the main API to use when interacting with CloudML.
CloudML allows developers to model the provisioning and deployment of a multi-cloud application at two levels of abstraction: (i) the Cloud Provider-Independent Model (CPIM), which specifies the provisioning and deployment of a multi-cloud application in a cloud provider-agnostic way ; (ii) the Cloud Provider-Specific Model (CPSM), which refines the CPIM and specifies the provisioning and deployment of a multi-cloud application in a cloud provider-specific way. This two-level approach is agnostic to any development paradigm and technology, meaning that the application developers can design and implement their applications based on their preferred paradigms and technologies.
CloudML is also inspired by component-based approaches in order to facilitate separation of concerns and reusability. In this respect, deployment models can be regarded as assemblies of components exposing ports, and bindings between these ports. To this end, CloudML implements the type-instance pattern. The figure below presents the main concepts of the type part of the metamodel. The POJO implementation of this metamodel is available here.
In the following, we provide a description of the most important classes and corresponding properties in the metamodel.
A CloudMLModel consists of CloudMLElements (these classes have been omitted from the previous Figure to increase the readability). A CloudMLElement can be associated to Property and Resources. A Resource represents an artefact (e.g., scripts, binaries, configuration files, etc.) adopted to manage the deployment life-cycle (e.g., download, configure, install, start, and stop). The three main types of CloudMLElements are Component, Relationship, and ExecutionBinding.
A Component represents a reusable type of component. A Component can be an ExternalComponent managed and provided as a service by a Provider (e.g., a Beanstalk container), or an InternalComponent managed and deployed by CloudML (e.g., a Servlet container).
A VM is a type of ExternalComponent and represents a reusable type of virtual machine (e.g., a virtual machine running Linux)
A Port represents an interface of a component. A Port can be a ProvidedPort, meaning that it supplies a feature provided by the component (e.g., the servlet provides a REST interface), or a RequiredPort, meaning that it consumes a feature (e.g., a servlet requires another servlet offering a REST interface). Only internal components can have a RequiredPort since this requires to be fully managed by CloudML. The property isMandatory represents that the internal component depends on this feature. The property isLocal represents that the component requesting the feature and the component providing the feature have to be deployed on the same external component.
An ExecutionPlatform port represents another type of interface of a component. An ExecutionPlatform can be a ProvidedExecutionPlatform, meaning that a component supplies an execution environment, or a RequiredExecutionPlatform, meaning that an internal component requires an execution platform in order to be executed. For instance, consider a Jetty container to be deployed on a VM and which will host a war application. This Jetty container should expose a providedExecutionPlatform to the application, depicting the fact that applications can be executed on it and should expose a requiredExecutionPlatform, depicting that it needs to be executed on a VM.
A Relationship represents a reusable type of relationship between ports of two internal components. A relationship can be associated to resources specifying how to configure the components in order to communicate with each other.
An ExecutionBinding represents a reusable type of binding between a required and a provided execution platform port. Resources can be associated to Execution Binding specifying how to configure the execution platform and the component to be deployed on it.
A tutorial about how to write a CloudML model is available here: https://nicolasferry.github.io/model.html
- java7 (openjdk)
- at least 2 GB RAM (better 4) or you may run into "out of memory" error during installation
You can build CloudML by using:
mvn clean install
If build fails - check this page http://goo.gl/djie05 (history of builds), find the latest successful build (green label), open it and you'll find commit ID. Then, inside cloudml folder run:
git reset --hard ID_OF_SUCCESSFUL_COMMIT mvn -q clean install
In order to use CloudML as a library by including in your path the jar file called: 'cloudml-library.jar' that has been generated in the 'facade\target' folder. If you plan to deploy your applications on AWS EC2 you should also include the ec2 driver: 'aws-ec2-1.7.2.jar'
The library can be used in two modes: local and remote. In the local mode the CloudML library is actually used to perform the deployment.
CloudML cml= Factory.getInstance().getCloudML(); CommandFactory fcommand = new CommandFactory(); CloudMlCommand load = fcommand.loadDeployment(this.jSonFile.getAbsolutePath()); CloudMlCommand deploy = fcommand.deploy(); cml.fireAndWait(load); cml.fireAndWait(deploy);
In the remote mode, the library can be used to trigger a deployment by a remote CloudML started as a service. In order to do so, you only need to change one line in your code:
CloudML cml= Factory.getInstance().getCloudML("ws://ip:port");
You can use CloudML as a service by starting the jar file called: 'cloudml-WebSocket.jar' that has been generated in the 'ui\websocket\target' folder. This jar file should be placed together with the 'lib' folder that has also been generated in 'ui\websocket\target'. The command to start the service is the following:
java -jar cloudml-WebSocket.jar
A video demonstrating how to use the CloudML as a service is available here
Finally you can use CloudML has a command line tool by starting the jar file called: 'cloudml-shell.jar' that has been generated in the 'ui\shell\target' folder. This jar file should be placed together with the 'lib' folder that has also been generated in 'ui\websocket\target'. The command to start the service is the following:
java -jar cloudml-shell.jar -i
An interactive tutorial demonstrating how to use the command line tool is available here: https://nicolasferry.github.io/shell.html
For the credentials description, please refer to the provider definition [the JSON codec] (https://github.com/SINTEF-9012/cloudml/tree/master/codecs/json).
The CloudML log file is available at the following directory: "C:\Users<your username>" on windows or "/home/yourusername" on Linux.
For now CloudML supports the following Providers and services:
- Amazon EC2
- Flexiant FCO
- Openstack nova
- Amazon Beanstalk
- Amazon RDS
- Amazon SQS
- CloudBees Application container
- CloudBees database
- Cloud Foundry v2 Public and Private clouds
API usages & Models
CloudML provides 3 ways of accessing its API in order to instantiate models:
- Programatically, as a library via [the Java API] (https://github.com/SINTEF-9012/cloudml/tree/master/facade). This API is not yet fully implemented and we envision to provide [the following commands] (https://github.com/SINTEF-9012/cloudml/wiki/API).
- From a JSON file via [the JSON codec] (https://github.com/SINTEF-9012/cloudml/tree/master/codecs/json).
- From an Ecore/XMI file via the XMI codec, which you can create in an Eclipse editor.
The enactment of CloudML models i.e. the actual deployment of services in the CloudML is realized by the CloudML engine. This engine can be accessed programatically via: