The Cloud Driver
The Cloudify cloud driver is Cloudify’s abstraction layer for the underlying cloud environment. It is responsible for interfacing with the cloud infrastructure to provide the on-demand compute resources that Cloudify requires for running applications.
How Compute Resources are Provisioned
Cloudify uses agentless-installation to install Cloudify, meaning that it does not require any Cloudify software (agent) to be preinstalled on newly allocated machines before starting the installation process. The Cloudify controller simply connects to to newly allocated machines over SSH, installs the required Cloudify components, and connects it to the Cloudify cluster.
As a result, other than meeting the minimum requirements for images, special machine images are not required. Any *nix or Windows image can be used, whether virtual or physical. Additionally, provisioning does not necessarily have to use a real “cloud”, you can use an arbitrary set of non-virtualized hosts to create BYON or local cloud environments.
When the Cloud Driver Is Used
The cloud driver is loaded and used by the following Cloudify components:
- The Cloudify shell loads an instance of the cloud driver when provisioning or unprovisioning machines when the following commands are run, and is then discarded:
bootstrap-cloud,teardown-cloud(management machines)install-application,uninstall-application(application machines)
- The ESM will load one instance of the cloud driver for each deployed service. Each instance is responsible for scaling out/in the specified service. At all times, there can only be one instance of the ESM in a cluster, running zero or more instances of the cloud driver.
Modifying the cloud driver has an effect only before the bootstrapping.
How It Works
The cloud driver is a Java POJO that uses a configuration file. When defining a cloud’s configuration file, you must define its class name in its cloud driver configuration file (<cloudifyRoot>/tools/cli/plugins/esc/<cloudName>/<cloudName>-cloud.groovy). Cloudify will instantiate this class (using the no-arg constructor) as required, and delegate scale out/in requests to it.
When scaling-out, the driver is responsible for allocating the machine, verifying that SSH is enabled on it, and returning the machine details to Cloudify. The returned details include the machine’s Host/IP address and the login credentials required to access the machine. When scaling-in, the driver is responsible for shutting down the machine and releasing it to the pool of available machines. In virtualized environments (including most IaaS clouds), this usually means shutting down the virtual machine itself. In contrast, in physical environments, this means either shutting down the machine itself, or simplay stopping the Cloudify agent running on the machine.
Dealing with Provisioning Errors
Cloud providers and APIs are not perfect. In large-scale distributed environments, errors can and do occur. It is important to remember that the cloud driver infrastructure is NOT “transactional”. It is the cloud driver implementation’s responsibility to properly handle any errors from cloud environment. Most importantly, it is the cloud driver’s responsibility to properly release resources if an error has occurred while provisioning a machine.
For instance, if a cloud driver requests a machine from the cloud and then waits for the machine to become available, the machine may take too long to start, exceeding the required timeout. In this case, it is the responsibility of the cloud driver to shut down the machine before throwing a TimeoutException to the cloud driver infrastructure.
If a TimeouotException occurs, Cloudify will re-issue the request for the new machine.
The Cloud Driver API
The cloud driver implementation class implements the following org.cloudifysource.esc.driver.provisioning.ProvisioningDriver interface:
The Cloud Driver Configuration File
The implementing class of the cloud driver, along with any required cloud configuration information, is specified in a Groovy DSL based configuration file. This information is used to populate the cloud configuration object whose type is org.cloudifysource.dsl.cloud.Cloud. This object is passed to the cloud driver instance in the setConfig() call.
The following example shows a sample configuration file:
Setting OS variables in the Cloud Driver Configuration.
You can set or override any OS variable, by specifying it in an env section in a template, as shown in the following example:
Parameterization of the Cloud Driver Configuration.
You can use Groovy GString expressions in the cloud driver DSL, thus you can easily set the values you need in the DSL using a simple properties file with a naming convention as shown in the following example:
Set the following values in ec2-cloud.properties :
And then you’ll be able to use them in ec2-cloud.groovy:
In order for this to work, you must maintain a naming convention: The cloud driver should be named yourcloudprovider-cloud.groovy and the properites file must be named yourcloudprovider-cloud.properties
Custom script or code in the Cloud Driver Configuration.
You can script inline or point to an uploaded script as shown in the following example:
The Default Cloud Driver
Cloudify comes with a built-in cloud driver implementation that is based on the popular jclouds framework. This cloud driver enables you to deploy Cloudify services for many cloud providers and APIs. For a full listing of supported clouds, see jclouds : Supported Providers.
The default cloud driver can be used as-is, or as the basis for an extension that suits your requirements.