Supported Languages, Databases and Clouds

1.Supported Cloud Providers #

Cloudesire currently supports the following Cloud Providers:

Name Linux Stacks .NET (Windows) Notes
Amazon AWS VPC instances not yet supported
Digital Ocean No additional data disks available
Enter the Cloud
Google Compute
HPCloud
IBM Softlayer
Joyent
Microsoft Azure
Rackspace Data disk minimun size 100 GB

2.Supported Languages #

In this section you will find the list of the languages that Cloudesire currently supports. Vendors can use these languages during the onboarding of ZIP packaged applications.

2.1..NET #

The ZIP should contains a folder named aspnet-app, containing the code of an application supporting .NET framework 4.0 or compatible (with the default packages available on Windows Server 2012).

The folder aspnet-app should contains the main configuration file named Web.config.template. Here an example of its content:

<?xml version="1.0" encoding="utf-8"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=152368
  -->
<configuration>
  <connectionStrings>
    <add name="$$$ENVIRONMENT_VARIABLE$$$"
      connectionString="Server=%DB_HOST%;Database=%DB_NAME%;User Id=%DB_USER%;Password=%DB_PASS%;"
      providerName="System.Data.SqlClient"/>
  </connectionStrings>
</configuration>
<?xml version="1.0" encoding="utf-8"?>

This file will be parsed at deploy time, $$$ENVIRONMENT_VARIABLE$$$ will be substituted with the actual value of the referred environment variables and %PLACEHOLDER% will be substituted with our autogenerated values for the database.

Environment variables are also replaced in the sql/init.sql file if exists. If necessary you can use additional placeholders in the sql/init.sql file to manage the DB’s Data/Index/Log paths. These placeholders are %DB_INDEX_PATH%, %DB_DATA_PATH%, %DB_LOG_PATH% and they will be replaced with preconfigured paths that exist on the filesystem.

A simple usage could be:

:setvar DefaultIndexPath "%DB_INDEX_PATH%"
:setvar DefaultDataPath "%DB_DATA_PATH%"
:setvar DefaultLogPath "%DB_LOG_PATH%"

FTP access

An FTP server is automatically configured, and you can access the application code once deployed by using the Administrator account details, with the unique particularity that the username should be hostname|Administrator.

2.2.CGI #

The ZIP should contains a folder named cgibin-app containing the CGI application(s), that should be compatible with the currently supported Ubuntu server.

All the CGI executable files should have a .cgi extension to be recognized as CGI executable by the http server.

2.3.Django #

The ZIP should contains a folder named django-app containing the application source code.

The application should use the dj-database-url package in order to retrieve the database connection informations, so it should have default database defined in settings.py like:

DATABASES = {
  'default': dj_database_url.config(),
}

It is also expected that content that needs to be served by the webserver itself (e.g. static files) are placed and referred to either in /static or /media folders from the application root.

The application is expected to be able to be served by gunicorn, and it can have its migrations handled by south library.

For having everything hooked-in, the requirements.txt should contains something like:

Django==1.6.2
South==0.8.4
dj-database-url==0.2.2
dj-static==0.0.5
gunicorn==18.0

2.4.Java #

The ZIP should contains a folder named java-app containing the web application WAR and it should be using the JNDI resource named jdbc/datasource to be able to retrieve a connection for the current database. It is expected that the application can run under Tomcat.

Please note that the WAR filename must be identical to his containing application module name. For instance, if the module name is “Backend” the WAR filename must be “Backend.war”.

2.5.PHP #

The ZIP should contains a folder named php-app containing the application source code.

Database connection details

You have to use the following environment variables so Cloudesire will be able to automatically supply database connection information to your application:

  • CLOUDESIRE_DB_USER: username to connect to the database;
  • CLOUDESIRE_DB_PASS: password to connect to the database;
  • CLOUDESIRE_DB_NAME: name of the available database;
  • CLOUDESIRE_DB_HOST: hostname of the database;

For MongoDB database, just CLOUDESIRE_DB_NAME is required, since authentication is off as per default configuration.

Follows a snippet of a generic config.php:

define('db_name', getenv('CLOUDESIRE_DB_NAME'));
define('db_username', getenv('CLOUDESIRE_DB_USER'));
define('db_password', getenv('CLOUDESIRE_DB_PASS'));

VirtualHost

For each application you have the following environment variables:

  • CLOUDESIRE_VHOST: dns used for the application (without the http:// part)
  • CLOUDESIRE_APPLICATION_PATH: the absolute path of the current application

Follows a snippet:

$site_url = 'http://' . getenv('CLOUDESIRE_VHOST');
$app_absolute_path = getenv('CLOUDESIRE_APPLICATION_PATH');

More available Environment Variables are described in this section.

2.6.NodeJS #

The ZIP should contains a folder named nodejs-app containing the application code. The application is required to use the NODE_PORT environment variable when choosing on which port the application should listen to (using process.env.NODE_PORT). It is assumed that a node.js application is built on express or a compatible framework, and uses npm to handle dependencies.

2.7.Ruby #

The ZIP should contains a folder named rails-app containing the application source code. The database configuration file config/database.yml will be automatically generated. Mind that database schema can be handled both via migrations and/or sql folder.

Rack applications

While it is a common practice to make use of the Rails framework when choosing Ruby, any other framework or absence thereof is supported as long as:

  • Database connection data is read from the file config/database.yml (either by hand or with the aid of ActiveRecord);
  • The application supports Rack, and is therefore interfaceable with Passenger;
  • Gem dependencies are handled with Bundler;
  • The application includes a JS runtime in its dependencies (e.g.: //gem ‘therubyracer’//); “`

3.Supported Databases #

In this section you will find the list of the databases that Cloudesire currently supports on the marketplace. Vendors can use these databases during the onboarding of ZIP packaged applications.

3.1.ODBC Support #

In order to provide connections to mySQL and PostgreSQL databases, a unixODBC support is available on each running VM.
If you are interested to use it, you need to specify the application module name as DSN.

3.2.MongoDB 2.x #

MongoDB will run on the default port with no authentication and the database name is preserved on the binary dump, so no further configuration should be necessary on the application.

A database dump should be gathered with mongodump utility. At the first run, it will be imported using mongorestore utility.

3.3.MySQL 5.x #

The script should be in the standard .sql format, e.g.: generated via mysqldump tool. It should not contains any administrative command, like CREATE DATABASE or GRANT PRIVILEGES.

ODBC support is provided to connect to MySQL databases. More info in this section.

3.4.PostgreSQL 9.x #

Only plain-text SQL dumps are supported. Due to the limitations of this format in regards to PostgreSQL dumps must be made so that object ownership is not preserved, and data is loaded via INSERT rather than COPY.

For example, if you use pg_dump, you would run:

pg_dump -O --inserts --column-inserts my_database_name > V1__init.sql

ODBC support is provided to connect to PostgreSQL databases. More info in this section.

3.5.MSSQL Server #

The available SQL Server version is SQL Server 2012 Standard Edition available on Windows Server 2012.

Your application Web.config file should contains an entry like:

<connectionStrings configSource="Connections.config"/>

You should include in the archive a CD-Connections.config file in the same directory, that will be used as a template during the generation of the real Connections.config file., e.g.:

<?xml version="1.0" encoding="utf-8"?>
<connectionStrings>
    <add name="ClouDesireDB"
      connectionString="Server=%DB_HOST%;Database=%DB_NAME%;User Id=%DB_USER%;Password=%DB_PASS%;"
      providerName="System.Data.SqlClient"/>
</connectionStrings>

The %placeholder% occurrences will be replaced by the proper database connection details managed by the platform, while other things will be left untouched.

The initial dump of the database should be placed in the sql folder as V1__init.sql (flyway support will arrive sooner).

Help Guide Powered by Documentor
Suggest Edit